- Linux-stable-mirror - lists.linaro.org

Patch "ACPI / PMIC: xpower: Fix power_table addresses" has been added to the 4.9-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled ACPI / PMIC: xpower: Fix power_table addresses to the 4.9-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: acpi-pmic-xpower-fix-power_table-addresses.patch and it can be found in the queue-4.9 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Thu Mar 22 14:40:23 CET 2018 From: Hans de Goede <hdegoede(a)redhat.com> Date: Fri, 21 Apr 2017 13:48:08 +0200 Subject: ACPI / PMIC: xpower: Fix power_table addresses From: Hans de Goede <hdegoede(a)redhat.com> [ Upstream commit 2bde7c32b1db162692f05c6be066b5bcd3d9fdbe ] The power table addresses should be contiguous, but there was a hole where 0x34 was missing. On most devices this is not a problem as addresses above 0x34 are used for the BUC# convertors which are not used in the DSDTs I've access to but after the BUC# convertors there is a field named GPI1 in the DSTDs, which does get used in some cases and ended up turning BUC6 on and off due to the wrong addresses, resulting in turning the entire device off (or causing it to reboot). Removing the hole in the addresses fixes this, fixing one of my Bay Trail tablets turning off while booting the mainline kernel. While at it add comments with the field names used in the DSDTs to make it easier to compare the register and bits used at each address with the datasheet. Signed-off-by: Hans de Goede <hdegoede(a)redhat.com> Reviewed-by: Andy Shevchenko <andriy.shevchenko(a)linux.intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki(a)intel.com> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/acpi/pmic/intel_pmic_xpower.c | 50 +++++++++++++++++----------------- 1 file changed, 25 insertions(+), 25 deletions(-) --- a/drivers/acpi/pmic/intel_pmic_xpower.c +++ b/drivers/acpi/pmic/intel_pmic_xpower.c @@ -28,97 +28,97 @@ static struct pmic_table power_table[] = .address = 0x00, .reg = 0x13, .bit = 0x05, - }, + }, /* ALD1 */ { .address = 0x04, .reg = 0x13, .bit = 0x06, - }, + }, /* ALD2 */ { .address = 0x08, .reg = 0x13, .bit = 0x07, - }, + }, /* ALD3 */ { .address = 0x0c, .reg = 0x12, .bit = 0x03, - }, + }, /* DLD1 */ { .address = 0x10, .reg = 0x12, .bit = 0x04, - }, + }, /* DLD2 */ { .address = 0x14, .reg = 0x12, .bit = 0x05, - }, + }, /* DLD3 */ { .address = 0x18, .reg = 0x12, .bit = 0x06, - }, + }, /* DLD4 */ { .address = 0x1c, .reg = 0x12, .bit = 0x00, - }, + }, /* ELD1 */ { .address = 0x20, .reg = 0x12, .bit = 0x01, - }, + }, /* ELD2 */ { .address = 0x24, .reg = 0x12, .bit = 0x02, - }, + }, /* ELD3 */ { .address = 0x28, .reg = 0x13, .bit = 0x02, - }, + }, /* FLD1 */ { .address = 0x2c, .reg = 0x13, .bit = 0x03, - }, + }, /* FLD2 */ { .address = 0x30, .reg = 0x13, .bit = 0x04, - }, + }, /* FLD3 */ { - .address = 0x38, + .address = 0x34, .reg = 0x10, .bit = 0x03, - }, + }, /* BUC1 */ { - .address = 0x3c, + .address = 0x38, .reg = 0x10, .bit = 0x06, - }, + }, /* BUC2 */ { - .address = 0x40, + .address = 0x3c, .reg = 0x10, .bit = 0x05, - }, + }, /* BUC3 */ { - .address = 0x44, + .address = 0x40, .reg = 0x10, .bit = 0x04, - }, + }, /* BUC4 */ { - .address = 0x48, + .address = 0x44, .reg = 0x10, .bit = 0x01, - }, + }, /* BUC5 */ { - .address = 0x4c, + .address = 0x48, .reg = 0x10, .bit = 0x00 - }, + }, /* BUC6 */ }; /* TMP0 - TMP5 are the same, all from GPADC */ Patches currently in stable-queue which might be from hdegoede(a)redhat.com are queue-4.9/power-supply-bq24190_charger-limit-over-under-voltage-fault-logging.patch queue-4.9/acpi-pmic-xpower-fix-power_table-addresses.patch queue-4.9/acpi-power-delay-turning-off-unused-power-resources-after-suspend.patch queue-4.9/rtc-cmos-do-not-assume-irq-8-for-rtc-when-there-are-no-legacy-irqs.patch queue-4.9/genirq-use-irqd_get_trigger_type-to-compare-the-trigger-type-for-shared-irqs.patch queue-4.9/power-supply-bq24190_charger-add-disable-reset-device-property.patch queue-4.9/x86-i8259-export-legacy_pic-symbol.patch

7 years, 3 months

1
0
0 0

[GIT PULL] commits for Linux 4.14

by Sasha Levin

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Hi Greg, Pleae pull commits for Linux 4.14 . I've sent a review request for all commits over a week ago and all comments were addressed. Thanks, Sasha ===== The following changes since commit 267ef1d332845c1d361ff3fd1d346613a12db773: Linux 4.14.23 (2018-02-28 10:19:45 +0100) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/sashal/linux-stable.git tags/for-greg-4.14-19032018 for you to fetch changes up to 548224ecd13182106bf7f21f480e2762e95a700b: dmaengine: ti-dma-crossbar: Fix event mapping for TPCC_EVT_MUX_60_63 (2018-03-19 11:26:14 -0400) - ---------------------------------------------------------------- for-greg-4.14-19032018 - ---------------------------------------------------------------- Alexandre Belloni (1): rtc: ac100: Fix multiple race conditions Alexey Kodanev (1): ip6_vti: adjust vti mtu according to mtu of lower device Anton Vasilyev (1): RDMA/ocrdma: Fix permissions for OCRDMA_RESET_STATS Arnd Bergmann (1): cros_ec: fix nul-termination for firmware build info Artemy Kovalyov (1): IB/umem: Fix use of npages/nmap fields Balaji Pothunoori (1): ath10k: handling qos at STA side based on AP WMM enable/disable Benjamin Coddington (1): nfsd4: permit layoutget of executable-only files Bharat Potnuri (1): iser-target: avoid reinitializing rdma contexts for isert commands Bjorn Helgaas (1): vgacon: Set VGA struct resource types BjÃ¸rn Mork (1): qmi_wwan: set FLAG_SEND_ZLP to avoid network initiated disconnect Brian Norris (1): pinctrl: rockchip: enable clock when reading pin direction register Christophe JAILLET (1): media: bt8xx: Fix err 'bt878_probe()' Daniel Drake (1): mmc: avoid removing non-removable hosts during suspend Erez Shitrit (1): IB/ipoib: Avoid memory leak if the SA returns a different DGID Florian Fainelli (1): pinctrl: Really force states during suspend/resume Geert Uytterhoeven (3): RDMA/iwpm: Fix uninitialized error code in iwpm_send_mapinfo() spi: sh-msiof: Avoid writing to registers from spi_master.setup() PCI: rcar: Handle rcar_pcie_parse_request_of_pci_ranges() failures Guenter Roeck (2): watchdog: Fix potential kref imbalance when opening watchdog watchdog: Fix kref imbalance seen if handle_boot_enabled=0 Gustavo A. R. Silva (1): media: c8sectpfe: fix potential NULL pointer dereference in c8sectpfe_timer_interrupt H. Nikolaus Schaller (1): omapdrm: panel: fix compatible vendor string for td028ttec1 Haishuang Yan (2): ip_gre: fix error path when erspan_rcv failed ip_gre: fix potential memory leak in erspan_rcv Haiyang Zhang (2): hv_netvsc: Fix the receive buffer size limit hv_netvsc: Fix the TX/RX buffer default sizes James Smart (2): scsi: lpfc: Fix SCSI LUN discovery when SCSI and NVME enabled scsi: lpfc: Fix issues connecting with nvme initiator Jerome Brunet (1): net: phy: meson-gxl: check phy_write return value Jerry Snitselaar (1): iommu/vt-d: clean up pr_irq if request_threaded_irq fails Joel Stanley (1): ARM: dts: aspeed-evb: Add unit name to memory node Johan Hovold (1): soc: qcom: smsm: fix child-node lookup Kedareswara rao Appana (1): dmaengine: zynqmp_dma: Fix race condition in the probe Kees Cook (1): /dev/mem: Add bounce buffer for copy-out Kishon Vijay Abraham I (1): PCI: designware-ep: Fix ->get_msi() to check MSI_EN bit Lars Persson (1): crypto: artpec6 - set correct iv size for gcm(aes) Lars-Peter Clausen (1): clk: axi-clkgen: Correctly handle nocount bit in recalc_rate() Liu, Changcheng (1): mmc: block: fix logical error to avoid memory leak Logan Gunthorpe (1): drm/tilcdc: ensure nonatomic iowrite64 is not used Loic Poulain (2): Bluetooth: hci_qca: Avoid setup failure on missing rampatch Bluetooth: btqcomsmd: Fix skb double free corruption Mauro Carvalho Chehab (1): media: davinci: fix a debug printk NeilBrown (1): dm: ensure bio submission follows a depth-first tree walk Nicolas Iooss (1): rtlwifi: always initialize variables given to RT_TRACE() Niklas Cassel (1): PCI: endpoint: Fix find_first_zero_bit() usage Parav Pandit (1): RDMA/cma: Use correct size when writing netlink stats Peter Ujfalusi (1): drm/omap: DMM: Check for DMM readiness after successful transaction commit Prakash Kamliya (1): drm/msm: fix leak in failed get_pages Richard Leitner (1): net: fec: add phy_reset_after_clk_enable() support Robert Walker (1): coresight: Fix disabling of CoreSight TPIU Romain Izard (1): clk: at91: pmc: Wait for clocks when resuming Ron Economos (1): media: [RESEND] media: dvb-frontends: Add delay to Si2168 restart Russell King (2): sfp: fix EEPROM reading in the case of non-SFF8472 SFPs sfp: fix non-detection of PHY Sahara (1): pty: cancel pty slave port buf's work in tty_release Sebastian Andrzej Siewior (1): tty: goldfish: Enable 'earlycon' only if built-in Sergej Sawazki (1): clk: si5351: Rename internal plls to avoid name collisions Shawn Nematbakhsh (1): platform/chrome: Use proper protocol transfer function Shuah Khan (1): media: s5p-mfc: Fix lock contention - request_firmware() once Stefan Potyra (1): serial: 8250_dw: Disable clock on error Stephen Boyd (1): clk: Don't touch hardware when reparenting during registration Tsang-Shian Lin (1): rtlwifi: rtl_pci: Fix the bug when inactiveps is enabled. Vignesh R (1): dmaengine: ti-dma-crossbar: Fix event mapping for TPCC_EVT_MUX_60_63 Viresh Kumar (1): cpufreq: longhaul: Revert transition_delay_us to 200 ms Zhoujie Wu (1): mmc: sdhci-xenon: wait 5ms after set 1.8V signal enable .../{toppoly,td028ttec1.txt => tpo,td028ttec1.txt} | 4 +- arch/alpha/kernel/console.c | 1 + arch/arm/boot/dts/aspeed-ast2500-evb.dts | 2 +- drivers/bluetooth/btqcomsmd.c | 3 +- drivers/bluetooth/hci_qca.c | 3 ++ drivers/char/mem.c | 27 +++++++++--- drivers/clk/at91/pmc.c | 24 +++++++---- drivers/clk/clk-axi-clkgen.c | 29 ++++++++++--- drivers/clk/clk-si5351.c | 2 +- drivers/clk/clk.c | 7 ++- drivers/cpufreq/longhaul.c | 2 +- drivers/crypto/axis/artpec6_crypto.c | 5 ++- drivers/dma/ti-dma-crossbar.c | 10 ++++- drivers/dma/xilinx/zynqmp_dma.c | 3 +- drivers/gpu/drm/msm/msm_gem.c | 14 ++++-- .../drm/omapdrm/displays/panel-tpo-td028ttec1.c | 3 ++ drivers/gpu/drm/omapdrm/omap_dmm_tiler.c | 5 +++ drivers/gpu/drm/tilcdc/tilcdc_regs.h | 2 +- drivers/hwtracing/coresight/coresight-tpiu.c | 13 ++++-- drivers/infiniband/core/cma.c | 2 +- drivers/infiniband/core/iwpm_util.c | 1 + drivers/infiniband/core/umem.c | 2 +- drivers/infiniband/hw/ocrdma/ocrdma_stats.c | 2 +- drivers/infiniband/ulp/ipoib/ipoib_main.c | 16 +++++++ drivers/infiniband/ulp/isert/ib_isert.c | 7 +++ drivers/infiniband/ulp/isert/ib_isert.h | 1 + drivers/iommu/intel-svm.c | 9 ++-- drivers/md/dm.c | 33 ++++++++++---- drivers/media/dvb-frontends/si2168.c | 3 ++ drivers/media/pci/bt8xx/bt878.c | 3 +- drivers/media/platform/davinci/vpif_capture.c | 4 +- drivers/media/platform/s5p-mfc/s5p_mfc.c | 6 +++ drivers/media/platform/s5p-mfc/s5p_mfc_common.h | 3 ++ drivers/media/platform/s5p-mfc/s5p_mfc_ctrl.c | 5 +++ .../media/platform/sti/c8sectpfe/c8sectpfe-core.c | 4 +- drivers/mmc/core/block.c | 1 + drivers/mmc/core/core.c | 8 ++++ drivers/mmc/host/sdhci-xenon.c | 7 +++ drivers/net/ethernet/freescale/fec_main.c | 20 +++++++++ drivers/net/hyperv/hyperv_net.h | 19 ++++++-- drivers/net/hyperv/netvsc.c | 5 +++ drivers/net/hyperv/netvsc_drv.c | 4 -- drivers/net/phy/meson-gxl.c | 50 ++++++++++++++++------ drivers/net/phy/sfp.c | 15 +++---- drivers/net/usb/qmi_wwan.c | 4 +- drivers/net/wireless/ath/ath10k/mac.c | 2 +- drivers/net/wireless/realtek/rtlwifi/base.c | 2 +- drivers/net/wireless/realtek/rtlwifi/pci.c | 7 +++ drivers/pci/dwc/pcie-designware-ep.c | 12 ++---- drivers/pci/dwc/pcie-designware.h | 1 + drivers/pci/endpoint/pci-ep-cfs.c | 5 ++- drivers/pci/host/pcie-rcar.c | 5 ++- drivers/pinctrl/core.c | 24 ++++++++--- drivers/pinctrl/pinctrl-rockchip.c | 8 ++++ drivers/platform/chrome/cros_ec_proto.c | 8 ++-- drivers/platform/chrome/cros_ec_sysfs.c | 2 +- drivers/rtc/rtc-ac100.c | 19 +++++--- drivers/scsi/lpfc/lpfc_ct.c | 1 + drivers/scsi/lpfc/lpfc_els.c | 30 ++++++++----- drivers/scsi/lpfc/lpfc_nportdisc.c | 34 +++++++-------- drivers/soc/qcom/smsm.c | 6 ++- drivers/spi/spi-sh-msiof.c | 35 ++++++++++----- drivers/tty/Kconfig | 6 ++- drivers/tty/goldfish.c | 2 + drivers/tty/serial/8250/8250_dw.c | 3 +- drivers/tty/tty_io.c | 2 + drivers/video/console/vgacon.c | 34 +++++++++++---- .../omap2/omapfb/displays/panel-tpo-td028ttec1.c | 3 ++ drivers/watchdog/watchdog_dev.c | 17 ++++---- fs/nfsd/nfs4proc.c | 6 +-- net/ipv4/ip_gre.c | 6 ++- net/ipv6/ip6_vti.c | 20 +++++++++ security/Kconfig | 1 + 73 files changed, 512 insertions(+), 182 deletions(-) rename Documentation/devicetree/bindings/display/panel/{toppoly,td028ttec1.txt => tpo,td028ttec1.txt} (84%) -----BEGIN PGP SIGNATURE----- iQIcBAEBCAAGBQJar9lzAAoJEN6mb/eXdyzcSf8QAIcKmpDULDdSpczh7OmsuEHN PvN+cDGHyDkiNn1DVxzYNlw+Vl3+DGE463bxv1L15nsVGyh2jKHDrmDQ16QfCYHN P8W9R3o0RaVXdhLohUCZYk+Z9RXsVgOPmDFo51p7v5X9cLcTLtfalb5rMmkyt+/b PjMYupI9LDq8EkwP28EGanuiS10qNzDwoo+fMxwr/ox8cZkbJMCCuRNBJ5You8x5 QIhLopdJQYSoBBuMnF3ojSOWyEeIDg4kNGorYRFvTjxc+1Z+QUt8/WKKC82uESqw DqwJezhBCUwY9Rgpl+X05mFFXoiOVtbL8JjB1Vdl1QHOdQrTHtnc7aMar+xhEbxi vW3Cl9eyaXIf+OXJzETyywFwbSFPGpiaI0r8cXAlmpo0h2XRcd5n+Vf5HeR/joRk LBEqVMMStZQxGaUdowaB+dLGY3xyn3/zpmNdUmu8fIXHcXQW+3g0fyVcPV8rzamn gdFZiugaP8vbSnINcl45cFKABGt1S/sxrKjCUl/r5k4+4+6ZkPm16Mkt7kFCv1s6 ZqFj3gEmOVVRlb7Tyt9NLP0lNhagIOiOkuG4+/aSUpR9AHqup/r78gOqgWVVg5pv hllygJXdx11vWLEeuWHKI0Dc2nSG6VW0LzpOD2V4j5SH/UgSdNsgVGh5Mopnsuw+ 6XLPeoQqFminp4i7T2JO =6egy -----END PGP SIGNATURE-----

7 years, 3 months

2
1
0 0

Patch "watchdog: Fix potential kref imbalance when opening watchdog" has been added to the 4.14-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled watchdog: Fix potential kref imbalance when opening watchdog to the 4.14-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: watchdog-fix-potential-kref-imbalance-when-opening-watchdog.patch and it can be found in the queue-4.14 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Thu Mar 22 14:26:48 CET 2018 From: Guenter Roeck <linux(a)roeck-us.net> Date: Mon, 25 Sep 2017 09:17:01 -0700 Subject: watchdog: Fix potential kref imbalance when opening watchdog From: Guenter Roeck <linux(a)roeck-us.net> [ Upstream commit 4bcd615fad6adddc68b058d498b30a9e0e0db77a ] If a watchdog driver's open function sets WDOG_HW_RUNNING with the expectation that the watchdog can not be stopped, but then stops the watchdog anyway in its stop function, kref_get() wil not be called in watchdog_open(). If the watchdog then stops on close, WDOG_HW_RUNNING will be cleared and kref_put() will be called, causing a kref imbalance. As result the character device data structure will be released, which in turn will cause the system to crash on the next call to watchdog_open(). Fixes: ee142889e32f5 ("watchdog: Introduce WDOG_HW_RUNNING flag") Signed-off-by: Guenter Roeck <linux(a)roeck-us.net> Signed-off-by: Wim Van Sebroeck <wim(a)iguana.be> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/watchdog/watchdog_dev.c | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) --- a/drivers/watchdog/watchdog_dev.c +++ b/drivers/watchdog/watchdog_dev.c @@ -768,6 +768,7 @@ static int watchdog_open(struct inode *i { struct watchdog_core_data *wd_data; struct watchdog_device *wdd; + bool hw_running; int err; /* Get the corresponding watchdog device */ @@ -787,7 +788,8 @@ static int watchdog_open(struct inode *i * If the /dev/watchdog device is open, we don't want the module * to be unloaded. */ - if (!watchdog_hw_running(wdd) && !try_module_get(wdd->ops->owner)) { + hw_running = watchdog_hw_running(wdd); + if (!hw_running && !try_module_get(wdd->ops->owner)) { err = -EBUSY; goto out_clear; } @@ -798,7 +800,7 @@ static int watchdog_open(struct inode *i file->private_data = wd_data; - if (!watchdog_hw_running(wdd)) + if (!hw_running) kref_get(&wd_data->kref); /* dev/watchdog is a virtual (and thus non-seekable) filesystem */ Patches currently in stable-queue which might be from linux(a)roeck-us.net are queue-4.14/watchdog-fix-potential-kref-imbalance-when-opening-watchdog.patch queue-4.14/watchdog-fix-kref-imbalance-seen-if-handle_boot_enabled-0.patch

7 years, 3 months

1
0
0 0

Patch "watchdog: Fix kref imbalance seen if handle_boot_enabled=0" has been added to the 4.14-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled watchdog: Fix kref imbalance seen if handle_boot_enabled=0 to the 4.14-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: watchdog-fix-kref-imbalance-seen-if-handle_boot_enabled-0.patch and it can be found in the queue-4.14 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Thu Mar 22 14:26:48 CET 2018 From: Guenter Roeck <linux(a)roeck-us.net> Date: Mon, 25 Sep 2017 09:17:02 -0700 Subject: watchdog: Fix kref imbalance seen if handle_boot_enabled=0 From: Guenter Roeck <linux(a)roeck-us.net> [ Upstream commit 914d65f3f013ba2556c7beec5d3baac7b3292504 ] If handle_boot_enabled is set to 0, the watchdog driver module use counter will not be increased and kref_get() will not be called when registering the watchdog. Subsequently, on open, this does not happen either because the code believes that it was already done because the hardware watchdog is marked as running. We could introduce a state variable to indicate this state, but let's just increase the module use counter and call kref_get() unconditionally if the hardware watchdog is running when a driver is registering itself to keep the code simple. Fixes: 2501b015313fe ("watchdog: core: add option to avoid early ...") Cc: Sebastian Reichel <sebastian.reichel(a)collabora.co.uk> Signed-off-by: Guenter Roeck <linux(a)roeck-us.net> Signed-off-by: Wim Van Sebroeck <wim(a)iguana.be> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/watchdog/watchdog_dev.c | 11 +++++------ 1 file changed, 5 insertions(+), 6 deletions(-) --- a/drivers/watchdog/watchdog_dev.c +++ b/drivers/watchdog/watchdog_dev.c @@ -966,14 +966,13 @@ static int watchdog_cdev_register(struct * and schedule an immediate ping. */ if (watchdog_hw_running(wdd)) { - if (handle_boot_enabled) { - __module_get(wdd->ops->owner); - kref_get(&wd_data->kref); + __module_get(wdd->ops->owner); + kref_get(&wd_data->kref); + if (handle_boot_enabled) queue_delayed_work(watchdog_wq, &wd_data->work, 0); - } else { + else pr_info("watchdog%d running and kernel based pre-userspace handler disabled\n", - wdd->id); - } + wdd->id); } return 0; Patches currently in stable-queue which might be from linux(a)roeck-us.net are queue-4.14/watchdog-fix-potential-kref-imbalance-when-opening-watchdog.patch queue-4.14/watchdog-fix-kref-imbalance-seen-if-handle_boot_enabled-0.patch

7 years, 3 months

1
0
0 0

Patch "vgacon: Set VGA struct resource types" has been added to the 4.14-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled vgacon: Set VGA struct resource types to the 4.14-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: vgacon-set-vga-struct-resource-types.patch and it can be found in the queue-4.14 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Thu Mar 22 14:26:48 CET 2018 From: Bjorn Helgaas <bhelgaas(a)google.com> Date: Fri, 1 Dec 2017 11:06:39 -0600 Subject: vgacon: Set VGA struct resource types From: Bjorn Helgaas <bhelgaas(a)google.com> [ Upstream commit c82084117f79bcae085e40da526253736a247120 ] Set the resource type when we reserve VGA-related I/O port resources. The resource code doesn't actually look at the type, so it inserts resources without a type in the tree correctly even without this change. But if we ever print a resource without a type, it looks like this: vga+ [??? 0x000003c0-0x000003df flags 0x0] Setting the type means it will be printed correctly as: vga+ [io 0x000003c0-0x000003df] Signed-off-by: Bjorn Helgaas <bhelgaas(a)google.com> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- arch/alpha/kernel/console.c | 1 + drivers/video/console/vgacon.c | 34 ++++++++++++++++++++++++++-------- 2 files changed, 27 insertions(+), 8 deletions(-) --- a/arch/alpha/kernel/console.c +++ b/arch/alpha/kernel/console.c @@ -21,6 +21,7 @@ struct pci_controller *pci_vga_hose; static struct resource alpha_vga = { .name = "alpha-vga+", + .flags = IORESOURCE_IO, .start = 0x3C0, .end = 0x3DF }; --- a/drivers/video/console/vgacon.c +++ b/drivers/video/console/vgacon.c @@ -422,7 +422,10 @@ static const char *vgacon_startup(void) vga_video_port_val = VGA_CRT_DM; if ((screen_info.orig_video_ega_bx & 0xff) != 0x10) { static struct resource ega_console_resource = - { .name = "ega", .start = 0x3B0, .end = 0x3BF }; + { .name = "ega", + .flags = IORESOURCE_IO, + .start = 0x3B0, + .end = 0x3BF }; vga_video_type = VIDEO_TYPE_EGAM; vga_vram_size = 0x8000; display_desc = "EGA+"; @@ -430,9 +433,15 @@ static const char *vgacon_startup(void) &ega_console_resource); } else { static struct resource mda1_console_resource = - { .name = "mda", .start = 0x3B0, .end = 0x3BB }; + { .name = "mda", + .flags = IORESOURCE_IO, + .start = 0x3B0, + .end = 0x3BB }; static struct resource mda2_console_resource = - { .name = "mda", .start = 0x3BF, .end = 0x3BF }; + { .name = "mda", + .flags = IORESOURCE_IO, + .start = 0x3BF, + .end = 0x3BF }; vga_video_type = VIDEO_TYPE_MDA; vga_vram_size = 0x2000; display_desc = "*MDA"; @@ -454,15 +463,21 @@ static const char *vgacon_startup(void) vga_vram_size = 0x8000; if (!screen_info.orig_video_isVGA) { - static struct resource ega_console_resource - = { .name = "ega", .start = 0x3C0, .end = 0x3DF }; + static struct resource ega_console_resource = + { .name = "ega", + .flags = IORESOURCE_IO, + .start = 0x3C0, + .end = 0x3DF }; vga_video_type = VIDEO_TYPE_EGAC; display_desc = "EGA"; request_resource(&ioport_resource, &ega_console_resource); } else { - static struct resource vga_console_resource - = { .name = "vga+", .start = 0x3C0, .end = 0x3DF }; + static struct resource vga_console_resource = + { .name = "vga+", + .flags = IORESOURCE_IO, + .start = 0x3C0, + .end = 0x3DF }; vga_video_type = VIDEO_TYPE_VGAC; display_desc = "VGA+"; request_resource(&ioport_resource, @@ -494,7 +509,10 @@ static const char *vgacon_startup(void) } } else { static struct resource cga_console_resource = - { .name = "cga", .start = 0x3D4, .end = 0x3D5 }; + { .name = "cga", + .flags = IORESOURCE_IO, + .start = 0x3D4, + .end = 0x3D5 }; vga_video_type = VIDEO_TYPE_CGA; vga_vram_size = 0x2000; display_desc = "*CGA"; Patches currently in stable-queue which might be from bhelgaas(a)google.com are queue-4.14/vgacon-set-vga-struct-resource-types.patch

7 years, 3 months

1
0
0 0

Patch "tty: goldfish: Enable 'earlycon' only if built-in" has been added to the 4.14-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled tty: goldfish: Enable 'earlycon' only if built-in to the 4.14-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: tty-goldfish-enable-earlycon-only-if-built-in.patch and it can be found in the queue-4.14 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Thu Mar 22 14:26:48 CET 2018 From: Sebastian Andrzej Siewior <bigeasy(a)linutronix.de> Date: Thu, 30 Nov 2017 09:16:31 +0100 Subject: tty: goldfish: Enable 'earlycon' only if built-in From: Sebastian Andrzej Siewior <bigeasy(a)linutronix.de> [ Upstream commit 6a28fd2bbc94bfca105632e5ef8a9dbe63ba0b39 ] Commit 3840ed9548f7 ("tty: goldfish: Implement support for kernel 'earlycon' parameter") breaks an allmodconfig config on x86: | LD vmlinux.o | MODPOST vmlinux.o |drivers/tty/serial/earlycon.o: In function `parse_options': |drivers/tty/serial/earlycon.c:97: undefined reference to `uart_parse_earlycon' |Makefile:1005: recipe for target 'vmlinux' failed earlycon.c::parse_options() invokes uart_parse_earlycon() from serial_core.c which is compiled=m because GOLDFISH_TTY itself (and most others) are =m. To avoid that, I'm adding the _CONSOLE config option which is selected if the GOLDFISH module itself is =y since it doesn't need the early bits for the =m case (other drivers do the same dance). The alternative would be to move uart_parse_earlycon() from serial_core.c to earlycon.c (we don't have that many users of that function). Fixes: 3840ed9548f7 ("tty: goldfish: Implement support for kernel 'earlycon' parameter") Signed-off-by: Sebastian Andrzej Siewior <bigeasy(a)linutronix.de> Reviewed-by: Miodrag Dinic <miodrag.dinic(a)mips.com> Acked-by: Miodrag Dinic <miodrag.dinic(a)mips.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/tty/Kconfig | 6 +++++- drivers/tty/goldfish.c | 2 ++ 2 files changed, 7 insertions(+), 1 deletion(-) --- a/drivers/tty/Kconfig +++ b/drivers/tty/Kconfig @@ -394,10 +394,14 @@ config GOLDFISH_TTY depends on GOLDFISH select SERIAL_CORE select SERIAL_CORE_CONSOLE - select SERIAL_EARLYCON help Console and system TTY driver for the Goldfish virtual platform. +config GOLDFISH_TTY_EARLY_CONSOLE + bool + default y if GOLDFISH_TTY=y + select SERIAL_EARLYCON + config DA_TTY bool "DA TTY" depends on METAG_DA --- a/drivers/tty/goldfish.c +++ b/drivers/tty/goldfish.c @@ -442,6 +442,7 @@ static int goldfish_tty_remove(struct pl return 0; } +#ifdef CONFIG_GOLDFISH_TTY_EARLY_CONSOLE static void gf_early_console_putchar(struct uart_port *port, int ch) { __raw_writel(ch, port->membase); @@ -465,6 +466,7 @@ static int __init gf_earlycon_setup(stru } OF_EARLYCON_DECLARE(early_gf_tty, "google,goldfish-tty", gf_earlycon_setup); +#endif static const struct of_device_id goldfish_tty_of_match[] = { { .compatible = "google,goldfish-tty", }, Patches currently in stable-queue which might be from bigeasy(a)linutronix.de are queue-4.14/tty-goldfish-enable-earlycon-only-if-built-in.patch

7 years, 3 months

1
0
0 0

Patch "spi: sh-msiof: Avoid writing to registers from spi_master.setup()" has been added to the 4.14-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled spi: sh-msiof: Avoid writing to registers from spi_master.setup() to the 4.14-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: spi-sh-msiof-avoid-writing-to-registers-from-spi_master.setup.patch and it can be found in the queue-4.14 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Thu Mar 22 14:26:48 CET 2018 From: Geert Uytterhoeven <geert+renesas(a)glider.be> Date: Wed, 13 Dec 2017 20:05:10 +0100 Subject: spi: sh-msiof: Avoid writing to registers from spi_master.setup() From: Geert Uytterhoeven <geert+renesas(a)glider.be> [ Upstream commit 7ff0b53c4051145d1cf992d2f60987e6447eed4f ] The spi_master.setup() callback must not change configuration registers, as that could corrupt I/O that is in progress for other SPI slaves. The only exception is the configuration of the native chip select polarity in SPI master mode, as a wrong chip select polarity will cause havoc during all future transfers to any other SPI slave. Hence stop writing to registers in sh_msiof_spi_setup(), unless it is the first call for a controller using a native chip select, or unless native chip select polarity has changed (note that you'll loose anyway if I/O is in progress). Even then, only do what is strictly necessary, instead of calling sh_msiof_spi_set_pin_regs(). Signed-off-by: Geert Uytterhoeven <geert+renesas(a)glider.be> Signed-off-by: Mark Brown <broonie(a)kernel.org> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/spi/spi-sh-msiof.c | 35 ++++++++++++++++++++++++----------- 1 file changed, 24 insertions(+), 11 deletions(-) --- a/drivers/spi/spi-sh-msiof.c +++ b/drivers/spi/spi-sh-msiof.c @@ -55,6 +55,8 @@ struct sh_msiof_spi_priv { void *rx_dma_page; dma_addr_t tx_dma_addr; dma_addr_t rx_dma_addr; + bool native_cs_inited; + bool native_cs_high; bool slave_aborted; }; @@ -528,8 +530,7 @@ static int sh_msiof_spi_setup(struct spi { struct device_node *np = spi->master->dev.of_node; struct sh_msiof_spi_priv *p = spi_master_get_devdata(spi->master); - - pm_runtime_get_sync(&p->pdev->dev); + u32 clr, set, tmp; if (!np) { /* @@ -539,19 +540,31 @@ static int sh_msiof_spi_setup(struct spi spi->cs_gpio = (uintptr_t)spi->controller_data; } - /* Configure pins before deasserting CS */ - sh_msiof_spi_set_pin_regs(p, !!(spi->mode & SPI_CPOL), - !!(spi->mode & SPI_CPHA), - !!(spi->mode & SPI_3WIRE), - !!(spi->mode & SPI_LSB_FIRST), - !!(spi->mode & SPI_CS_HIGH)); - - if (spi->cs_gpio >= 0) + if (spi->cs_gpio >= 0) { gpio_set_value(spi->cs_gpio, !(spi->mode & SPI_CS_HIGH)); + return 0; + } + + if (spi_controller_is_slave(p->master)) + return 0; + if (p->native_cs_inited && + (p->native_cs_high == !!(spi->mode & SPI_CS_HIGH))) + return 0; + /* Configure native chip select mode/polarity early */ + clr = MDR1_SYNCMD_MASK; + set = MDR1_TRMD | TMDR1_PCON | MDR1_SYNCMD_SPI; + if (spi->mode & SPI_CS_HIGH) + clr |= BIT(MDR1_SYNCAC_SHIFT); + else + set |= BIT(MDR1_SYNCAC_SHIFT); + pm_runtime_get_sync(&p->pdev->dev); + tmp = sh_msiof_read(p, TMDR1) & ~clr; + sh_msiof_write(p, TMDR1, tmp | set); pm_runtime_put(&p->pdev->dev); - + p->native_cs_high = spi->mode & SPI_CS_HIGH; + p->native_cs_inited = true; return 0; } Patches currently in stable-queue which might be from geert+renesas(a)glider.be are queue-4.14/spi-sh-msiof-avoid-writing-to-registers-from-spi_master.setup.patch queue-4.14/pci-rcar-handle-rcar_pcie_parse_request_of_pci_ranges-failures.patch

7 years, 3 months

1
0
0 0

Patch "soc: qcom: smsm: fix child-node lookup" has been added to the 4.14-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled soc: qcom: smsm: fix child-node lookup to the 4.14-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: soc-qcom-smsm-fix-child-node-lookup.patch and it can be found in the queue-4.14 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Thu Mar 22 14:26:48 CET 2018 From: Johan Hovold <johan(a)kernel.org> Date: Wed, 15 Nov 2017 12:07:24 +0100 Subject: soc: qcom: smsm: fix child-node lookup From: Johan Hovold <johan(a)kernel.org> [ Upstream commit 8804517e9fc16c10081ff5e42e7d80704973a8e2 ] Fix child-node lookup during probe, which ended up searching the whole device tree depth-first starting at the parent rather than just matching on its children. Note that the original premature free of the parent node has already been fixed separately. Also note that this pattern of looking up the first child node with a given property is rare enough that a generic helper is probably not warranted. Fixes: c97c4090ff72 ("soc: qcom: smsm: Add driver for Qualcomm SMSM") Fixes: 3e8b55411468 ("soc: qcom: smsm: fix of_node refcnting problem") Cc: Bjorn Andersson <bjorn.andersson(a)linaro.org> Cc: Rob Clark <robdclark(a)gmail.com> Signed-off-by: Johan Hovold <johan(a)kernel.org> Reviewed-by: Bjorn Andersson <bjorn.andersson(a)linaro.org> Signed-off-by: Andy Gross <andy.gross(a)linaro.org> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/soc/qcom/smsm.c | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) --- a/drivers/soc/qcom/smsm.c +++ b/drivers/soc/qcom/smsm.c @@ -496,8 +496,10 @@ static int qcom_smsm_probe(struct platfo if (!smsm->hosts) return -ENOMEM; - local_node = of_find_node_with_property(of_node_get(pdev->dev.of_node), - "#qcom,smem-state-cells"); + for_each_child_of_node(pdev->dev.of_node, local_node) { + if (of_find_property(local_node, "#qcom,smem-state-cells", NULL)) + break; + } if (!local_node) { dev_err(&pdev->dev, "no state entry\n"); return -EINVAL; Patches currently in stable-queue which might be from johan(a)kernel.org are queue-4.14/soc-qcom-smsm-fix-child-node-lookup.patch

7 years, 3 months

1
0
0 0

Patch "sfp: fix non-detection of PHY" has been added to the 4.14-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled sfp: fix non-detection of PHY to the 4.14-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: sfp-fix-non-detection-of-phy.patch and it can be found in the queue-4.14 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Thu Mar 22 14:26:48 CET 2018 From: Russell King <rmk+kernel(a)armlinux.org.uk> Date: Fri, 15 Dec 2017 16:09:36 +0000 Subject: sfp: fix non-detection of PHY From: Russell King <rmk+kernel(a)armlinux.org.uk> [ Upstream commit 20b56ed9f8adfb9a7fb1c878878c54aa4ed645c1 ] The detection of a PHY changed in commit e98a3aabf85f ("mdio_bus: don't return NULL from mdiobus_scan()") which now causes sfp to print an error message. Update for this change. Fixes: 73970055450e ("sfp: add SFP module support") Signed-off-by: Russell King <rmk+kernel(a)armlinux.org.uk> Signed-off-by: David S. Miller <davem(a)davemloft.net> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/net/phy/sfp.c | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) --- a/drivers/net/phy/sfp.c +++ b/drivers/net/phy/sfp.c @@ -318,12 +318,12 @@ static void sfp_sm_probe_phy(struct sfp msleep(T_PHY_RESET_MS); phy = mdiobus_scan(sfp->i2c_mii, SFP_PHY_ADDR); - if (IS_ERR(phy)) { - dev_err(sfp->dev, "mdiobus scan returned %ld\n", PTR_ERR(phy)); + if (phy == ERR_PTR(-ENODEV)) { + dev_info(sfp->dev, "no PHY detected\n"); return; } - if (!phy) { - dev_info(sfp->dev, "no PHY detected\n"); + if (IS_ERR(phy)) { + dev_err(sfp->dev, "mdiobus scan returned %ld\n", PTR_ERR(phy)); return; } Patches currently in stable-queue which might be from rmk+kernel(a)armlinux.org.uk are queue-4.14/sfp-fix-non-detection-of-phy.patch queue-4.14/sfp-fix-eeprom-reading-in-the-case-of-non-sff8472-sfps.patch

7 years, 3 months

1
0
0 0

Patch "sfp: fix EEPROM reading in the case of non-SFF8472 SFPs" has been added to the 4.14-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled sfp: fix EEPROM reading in the case of non-SFF8472 SFPs to the 4.14-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: sfp-fix-eeprom-reading-in-the-case-of-non-sff8472-sfps.patch and it can be found in the queue-4.14 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Thu Mar 22 14:26:48 CET 2018 From: Russell King <rmk+kernel(a)armlinux.org.uk> Date: Fri, 15 Dec 2017 16:09:41 +0000 Subject: sfp: fix EEPROM reading in the case of non-SFF8472 SFPs From: Russell King <rmk+kernel(a)armlinux.org.uk> [ Upstream commit 2794ffc441dde3109804085dc745e8014a4de224 ] The EEPROM reading was trying to read from the second EEPROM address if we requested the last byte from the SFF8079 EEPROM, which caused a failure when the second EEPROM is not present. Discovered with a S-RJ01 SFP module. Fix this. Fixes: 73970055450e ("sfp: add SFP module support") Signed-off-by: Russell King <rmk+kernel(a)armlinux.org.uk> Signed-off-by: David S. Miller <davem(a)davemloft.net> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/net/phy/sfp.c | 7 +++---- 1 file changed, 3 insertions(+), 4 deletions(-) --- a/drivers/net/phy/sfp.c +++ b/drivers/net/phy/sfp.c @@ -667,20 +667,19 @@ static int sfp_module_eeprom(struct sfp len = min_t(unsigned int, last, ETH_MODULE_SFF_8079_LEN); len -= first; - ret = sfp->read(sfp, false, first, data, len); + ret = sfp_read(sfp, false, first, data, len); if (ret < 0) return ret; first += len; data += len; } - if (first >= ETH_MODULE_SFF_8079_LEN && - first < ETH_MODULE_SFF_8472_LEN) { + if (first < ETH_MODULE_SFF_8472_LEN && last > ETH_MODULE_SFF_8079_LEN) { len = min_t(unsigned int, last, ETH_MODULE_SFF_8472_LEN); len -= first; first -= ETH_MODULE_SFF_8079_LEN; - ret = sfp->read(sfp, true, first, data, len); + ret = sfp_read(sfp, true, first, data, len); if (ret < 0) return ret; } Patches currently in stable-queue which might be from rmk+kernel(a)armlinux.org.uk are queue-4.14/sfp-fix-non-detection-of-phy.patch queue-4.14/sfp-fix-eeprom-reading-in-the-case-of-non-sff8472-sfps.patch

7 years, 3 months

1
0
0 0

Patch "serial: 8250_dw: Disable clock on error" has been added to the 4.14-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled serial: 8250_dw: Disable clock on error to the 4.14-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: serial-8250_dw-disable-clock-on-error.patch and it can be found in the queue-4.14 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Thu Mar 22 14:26:48 CET 2018 From: Stefan Potyra <Stefan.Potyra(a)elektrobit.com> Date: Wed, 6 Dec 2017 16:46:12 +0100 Subject: serial: 8250_dw: Disable clock on error From: Stefan Potyra <Stefan.Potyra(a)elektrobit.com> [ Upstream commit 8af016aa5a27c6a2505460eb4d83f1e70c38dc43 ] If there is no clock rate for uartclk defined, disable the previously enabled clock again. Found by Linux Driver Verification project (linuxtesting.org). Fixes: 23f5b3fdd04e serial: 8250_dw: only get the clock rate in one place Signed-off-by: Stefan Potyra <Stefan.Potyra(a)elektrobit.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/tty/serial/8250/8250_dw.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) --- a/drivers/tty/serial/8250/8250_dw.c +++ b/drivers/tty/serial/8250/8250_dw.c @@ -513,7 +513,8 @@ static int dw8250_probe(struct platform_ /* If no clock rate is defined, fail. */ if (!p->uartclk) { dev_err(dev, "clock rate not defined\n"); - return -EINVAL; + err = -EINVAL; + goto err_clk; } data->pclk = devm_clk_get(dev, "apb_pclk"); Patches currently in stable-queue which might be from Stefan.Potyra(a)elektrobit.com are queue-4.14/serial-8250_dw-disable-clock-on-error.patch

7 years, 3 months

1
0
0 0

Patch "scsi: lpfc: Fix SCSI LUN discovery when SCSI and NVME enabled" has been added to the 4.14-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled scsi: lpfc: Fix SCSI LUN discovery when SCSI and NVME enabled to the 4.14-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: scsi-lpfc-fix-scsi-lun-discovery-when-scsi-and-nvme-enabled.patch and it can be found in the queue-4.14 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Thu Mar 22 14:26:48 CET 2018 From: James Smart <jsmart2021(a)gmail.com> Date: Fri, 8 Dec 2017 17:18:07 -0800 Subject: scsi: lpfc: Fix SCSI LUN discovery when SCSI and NVME enabled From: James Smart <jsmart2021(a)gmail.com> [ Upstream commit 9de416ac67b54d666327ba927a190f4b7259f4a0 ] When enabled for both SCSI and NVME support, and connected pt2pt to a SCSI only target, the driver nodelist entry for the remote port is left in PRLI_ISSUE state and no SCSI LUNs are discovered. Works fine if only configured for SCSI support. Error was due to some of the prli points still reflecting the need to send only 1 PRLI. On a lot of fabric configs, targets were NVME only, which meant the fabric-reported protocol attributes were only telling the driver one protocol or the other. Thus things worked fine. With pt2pt, the driver must send a PRLI for both protocols as there are no hints on what the target supports. Thus pt2pt targets were hitting the multiple PRLI issues. Complete the dual PRLI support. Track explicitly whether scsi (fcp) or nvme prli's have been sent. Accurately track protocol support detected on each node as reported by the fabric or probed by PRLI traffic. Signed-off-by: Dick Kennedy <dick.kennedy(a)broadcom.com> Signed-off-by: James Smart <james.smart(a)broadcom.com> Reviewed-by: Hannes Reinecke <hare(a)suse.com> Signed-off-by: Martin K. Petersen <martin.petersen(a)oracle.com> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/scsi/lpfc/lpfc_ct.c | 1 + drivers/scsi/lpfc/lpfc_els.c | 30 ++++++++++++++++++++---------- drivers/scsi/lpfc/lpfc_nportdisc.c | 30 +++++++++++++----------------- 3 files changed, 34 insertions(+), 27 deletions(-) --- a/drivers/scsi/lpfc/lpfc_ct.c +++ b/drivers/scsi/lpfc/lpfc_ct.c @@ -471,6 +471,7 @@ lpfc_prep_node_fc4type(struct lpfc_vport "Parse GID_FTrsp: did:x%x flg:x%x x%x", Did, ndlp->nlp_flag, vport->fc_flag); + ndlp->nlp_fc4_type &= ~(NLP_FC4_FCP | NLP_FC4_NVME); /* By default, the driver expects to support FCP FC4 */ if (fc4_type == FC_TYPE_FCP) ndlp->nlp_fc4_type |= NLP_FC4_FCP; --- a/drivers/scsi/lpfc/lpfc_els.c +++ b/drivers/scsi/lpfc/lpfc_els.c @@ -2088,6 +2088,10 @@ lpfc_cmpl_els_prli(struct lpfc_hba *phba ndlp = (struct lpfc_nodelist *) cmdiocb->context1; spin_lock_irq(shost->host_lock); ndlp->nlp_flag &= ~NLP_PRLI_SND; + + /* Driver supports multiple FC4 types. Counters matter. */ + vport->fc_prli_sent--; + ndlp->fc4_prli_sent--; spin_unlock_irq(shost->host_lock); lpfc_debugfs_disc_trc(vport, LPFC_DISC_TRC_ELS_CMD, @@ -2095,9 +2099,6 @@ lpfc_cmpl_els_prli(struct lpfc_hba *phba irsp->ulpStatus, irsp->un.ulpWord[4], ndlp->nlp_DID); - /* Ddriver supports multiple FC4 types. Counters matter. */ - vport->fc_prli_sent--; - /* PRLI completes to NPort <nlp_DID> */ lpfc_printf_vlog(vport, KERN_INFO, LOG_ELS, "0103 PRLI completes to NPort x%06x " @@ -2111,7 +2112,6 @@ lpfc_cmpl_els_prli(struct lpfc_hba *phba if (irsp->ulpStatus) { /* Check for retry */ - ndlp->fc4_prli_sent--; if (lpfc_els_retry(phba, cmdiocb, rspiocb)) { /* ELS command is being retried */ goto out; @@ -2190,6 +2190,15 @@ lpfc_issue_els_prli(struct lpfc_vport *v ndlp->nlp_fc4_type |= NLP_FC4_NVME; local_nlp_type = ndlp->nlp_fc4_type; + /* This routine will issue 1 or 2 PRLIs, so zero all the ndlp + * fields here before any of them can complete. + */ + ndlp->nlp_type &= ~(NLP_FCP_TARGET | NLP_FCP_INITIATOR); + ndlp->nlp_type &= ~(NLP_NVME_TARGET | NLP_NVME_INITIATOR); + ndlp->nlp_fcp_info &= ~NLP_FCP_2_DEVICE; + ndlp->nlp_flag &= ~NLP_FIRSTBURST; + ndlp->nvme_fb_size = 0; + send_next_prli: if (local_nlp_type & NLP_FC4_FCP) { /* Payload is 4 + 16 = 20 x14 bytes. */ @@ -2298,6 +2307,13 @@ lpfc_issue_els_prli(struct lpfc_vport *v elsiocb->iocb_cmpl = lpfc_cmpl_els_prli; spin_lock_irq(shost->host_lock); ndlp->nlp_flag |= NLP_PRLI_SND; + + /* The vport counters are used for lpfc_scan_finished, but + * the ndlp is used to track outstanding PRLIs for different + * FC4 types. + */ + vport->fc_prli_sent++; + ndlp->fc4_prli_sent++; spin_unlock_irq(shost->host_lock); if (lpfc_sli_issue_iocb(phba, LPFC_ELS_RING, elsiocb, 0) == IOCB_ERROR) { @@ -2308,12 +2324,6 @@ lpfc_issue_els_prli(struct lpfc_vport *v return 1; } - /* The vport counters are used for lpfc_scan_finished, but - * the ndlp is used to track outstanding PRLIs for different - * FC4 types. - */ - vport->fc_prli_sent++; - ndlp->fc4_prli_sent++; /* The driver supports 2 FC4 types. Make sure * a PRLI is issued for all types before exiting. --- a/drivers/scsi/lpfc/lpfc_nportdisc.c +++ b/drivers/scsi/lpfc/lpfc_nportdisc.c @@ -390,6 +390,11 @@ lpfc_rcv_plogi(struct lpfc_vport *vport, break; } + ndlp->nlp_type &= ~(NLP_FCP_TARGET | NLP_FCP_INITIATOR); + ndlp->nlp_type &= ~(NLP_NVME_TARGET | NLP_NVME_INITIATOR); + ndlp->nlp_fcp_info &= ~NLP_FCP_2_DEVICE; + ndlp->nlp_flag &= ~NLP_FIRSTBURST; + /* Check for Nport to NPort pt2pt protocol */ if ((vport->fc_flag & FC_PT2PT) && !(vport->fc_flag & FC_PT2PT_PLOGI)) { @@ -742,9 +747,6 @@ lpfc_rcv_prli(struct lpfc_vport *vport, lp = (uint32_t *) pcmd->virt; npr = (PRLI *) ((uint8_t *) lp + sizeof (uint32_t)); - ndlp->nlp_type &= ~(NLP_FCP_TARGET | NLP_FCP_INITIATOR); - ndlp->nlp_fcp_info &= ~NLP_FCP_2_DEVICE; - ndlp->nlp_flag &= ~NLP_FIRSTBURST; if ((npr->prliType == PRLI_FCP_TYPE) || (npr->prliType == PRLI_NVME_TYPE)) { if (npr->initiatorFunc) { @@ -769,8 +771,12 @@ lpfc_rcv_prli(struct lpfc_vport *vport, * type. Target mode does not issue gft_id so doesn't get * the fc4 type set until now. */ - if ((phba->nvmet_support) && (npr->prliType == PRLI_NVME_TYPE)) + if (phba->nvmet_support && (npr->prliType == PRLI_NVME_TYPE)) { ndlp->nlp_fc4_type |= NLP_FC4_NVME; + lpfc_nlp_set_state(vport, ndlp, NLP_STE_UNMAPPED_NODE); + } + if (npr->prliType == PRLI_FCP_TYPE) + ndlp->nlp_fc4_type |= NLP_FC4_FCP; } if (rport) { /* We need to update the rport role values */ @@ -1552,7 +1558,6 @@ lpfc_rcv_prli_reglogin_issue(struct lpfc if (ndlp->nlp_flag & NLP_RPI_REGISTERED) { lpfc_rcv_prli(vport, ndlp, cmdiocb); lpfc_els_rsp_prli_acc(vport, cmdiocb, ndlp); - lpfc_nlp_set_state(vport, ndlp, NLP_STE_UNMAPPED_NODE); } else { /* RPI registration has not completed. Reject the PRLI * to prevent an illegal state transition when the @@ -1568,6 +1573,7 @@ lpfc_rcv_prli_reglogin_issue(struct lpfc stat.un.b.lsRjtRsnCodeExp = LSEXP_CMD_IN_PROGRESS; lpfc_els_rsp_reject(vport, stat.un.lsRjtError, cmdiocb, ndlp, NULL); + return ndlp->nlp_state; } } else { /* Initiator mode. */ @@ -1922,13 +1928,6 @@ lpfc_cmpl_prli_prli_issue(struct lpfc_vp return ndlp->nlp_state; } - /* Check out PRLI rsp */ - ndlp->nlp_type &= ~(NLP_FCP_TARGET | NLP_FCP_INITIATOR); - ndlp->nlp_fcp_info &= ~NLP_FCP_2_DEVICE; - - /* NVME or FCP first burst must be negotiated for each PRLI. */ - ndlp->nlp_flag &= ~NLP_FIRSTBURST; - ndlp->nvme_fb_size = 0; if (npr && (npr->acceptRspCode == PRLI_REQ_EXECUTED) && (npr->prliType == PRLI_FCP_TYPE)) { lpfc_printf_vlog(vport, KERN_INFO, LOG_NVME_DISC, @@ -1945,8 +1944,6 @@ lpfc_cmpl_prli_prli_issue(struct lpfc_vp if (npr->Retry) ndlp->nlp_fcp_info |= NLP_FCP_2_DEVICE; - /* PRLI completed. Decrement count. */ - ndlp->fc4_prli_sent--; } else if (nvpr && (bf_get_be32(prli_acc_rsp_code, nvpr) == PRLI_REQ_EXECUTED) && @@ -1991,8 +1988,6 @@ lpfc_cmpl_prli_prli_issue(struct lpfc_vp be32_to_cpu(nvpr->word5), ndlp->nlp_flag, ndlp->nlp_fcp_info, ndlp->nlp_type); - /* PRLI completed. Decrement count. */ - ndlp->fc4_prli_sent--; } if (!(ndlp->nlp_type & NLP_FCP_TARGET) && (vport->port_type == LPFC_NPIV_PORT) && @@ -2016,7 +2011,8 @@ out_err: ndlp->nlp_prev_state = NLP_STE_PRLI_ISSUE; if (ndlp->nlp_type & (NLP_FCP_TARGET | NLP_NVME_TARGET)) lpfc_nlp_set_state(vport, ndlp, NLP_STE_MAPPED_NODE); - else + else if (ndlp->nlp_type & + (NLP_FCP_INITIATOR | NLP_NVME_INITIATOR)) lpfc_nlp_set_state(vport, ndlp, NLP_STE_UNMAPPED_NODE); } else lpfc_printf_vlog(vport, Patches currently in stable-queue which might be from jsmart2021(a)gmail.com are queue-4.14/scsi-lpfc-fix-scsi-lun-discovery-when-scsi-and-nvme-enabled.patch queue-4.14/scsi-lpfc-fix-issues-connecting-with-nvme-initiator.patch

7 years, 3 months

1
0
0 0

Patch "scsi: lpfc: Fix issues connecting with nvme initiator" has been added to the 4.14-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled scsi: lpfc: Fix issues connecting with nvme initiator to the 4.14-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: scsi-lpfc-fix-issues-connecting-with-nvme-initiator.patch and it can be found in the queue-4.14 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Thu Mar 22 14:26:48 CET 2018 From: James Smart <jsmart2021(a)gmail.com> Date: Fri, 8 Dec 2017 17:18:08 -0800 Subject: scsi: lpfc: Fix issues connecting with nvme initiator From: James Smart <jsmart2021(a)gmail.com> [ Upstream commit e06351a002214d152142906a546006e3446d1ef7 ] In the lpfc discovery engine, when as a nvme target, where the driver was performing mailbox io with the adapter for port login when a NVME PRLI is received from the host. Rather than queue and eventually get back to sending a response after the mailbox traffic, the driver rejected the io with an error response. Turns out this particular initiator didn't like the rejection values (unable to process command/command in progress) so it never attempted a retry of the PRLI. Thus the host never established nvme connectivity with the lpfc target. By changing the rejection values (to Logical Busy/nothing more), the initiator accepted the response and would retry the PRLI, resulting in nvme connectivity. Signed-off-by: Dick Kennedy <dick.kennedy(a)broadcom.com> Signed-off-by: James Smart <james.smart(a)broadcom.com> Reviewed-by: Hannes Reinecke <hare(a)suse.com> Signed-off-by: Martin K. Petersen <martin.petersen(a)oracle.com> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/scsi/lpfc/lpfc_nportdisc.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) --- a/drivers/scsi/lpfc/lpfc_nportdisc.c +++ b/drivers/scsi/lpfc/lpfc_nportdisc.c @@ -1569,8 +1569,8 @@ lpfc_rcv_prli_reglogin_issue(struct lpfc ndlp->nlp_rpi, ndlp->nlp_state, ndlp->nlp_flag); memset(&stat, 0, sizeof(struct ls_rjt)); - stat.un.b.lsRjtRsnCode = LSRJT_UNABLE_TPC; - stat.un.b.lsRjtRsnCodeExp = LSEXP_CMD_IN_PROGRESS; + stat.un.b.lsRjtRsnCode = LSRJT_LOGICAL_BSY; + stat.un.b.lsRjtRsnCodeExp = LSEXP_NOTHING_MORE; lpfc_els_rsp_reject(vport, stat.un.lsRjtError, cmdiocb, ndlp, NULL); return ndlp->nlp_state; Patches currently in stable-queue which might be from jsmart2021(a)gmail.com are queue-4.14/scsi-lpfc-fix-scsi-lun-discovery-when-scsi-and-nvme-enabled.patch queue-4.14/scsi-lpfc-fix-issues-connecting-with-nvme-initiator.patch

7 years, 3 months

1
0
0 0

Patch "rtlwifi: rtl_pci: Fix the bug when inactiveps is enabled." has been added to the 4.14-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled rtlwifi: rtl_pci: Fix the bug when inactiveps is enabled. to the 4.14-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: rtlwifi-rtl_pci-fix-the-bug-when-inactiveps-is-enabled.patch and it can be found in the queue-4.14 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Thu Mar 22 14:26:48 CET 2018 From: Tsang-Shian Lin <thlin(a)realtek.com> Date: Sat, 9 Dec 2017 11:37:10 -0600 Subject: rtlwifi: rtl_pci: Fix the bug when inactiveps is enabled. From: Tsang-Shian Lin <thlin(a)realtek.com> [ Upstream commit b7573a0a27bfa8270dea9b145448f6884b7cacc1 ] Reset the driver current tx read/write index to zero when inactiveps nic out of sync with HW state. Wrong driver tx read/write index will cause Tx fail. Signed-off-by: Tsang-Shian Lin <thlin(a)realtek.com> Signed-off-by: Ping-Ke Shih <pkshih(a)realtek.com> Signed-off-by: Larry Finger <Larry.Finger(a)lwfinger.net> Cc: Yan-Hsuan Chuang <yhchuang(a)realtek.com> Cc: Birming Chiu <birming(a)realtek.com> Cc: Shaofu <shaofu(a)realtek.com> Cc: Steven Ting <steventing(a)realtek.com> Signed-off-by: Kalle Valo <kvalo(a)codeaurora.org> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/net/wireless/realtek/rtlwifi/pci.c | 7 +++++++ 1 file changed, 7 insertions(+) --- a/drivers/net/wireless/realtek/rtlwifi/pci.c +++ b/drivers/net/wireless/realtek/rtlwifi/pci.c @@ -1568,7 +1568,14 @@ int rtl_pci_reset_trx_ring(struct ieee80 dev_kfree_skb_irq(skb); ring->idx = (ring->idx + 1) % ring->entries; } + + if (rtlpriv->use_new_trx_flow) { + rtlpci->tx_ring[i].cur_tx_rp = 0; + rtlpci->tx_ring[i].cur_tx_wp = 0; + } + ring->idx = 0; + ring->entries = rtlpci->txringcount[i]; } } spin_unlock_irqrestore(&rtlpriv->locks.irq_th_lock, flags); Patches currently in stable-queue which might be from thlin(a)realtek.com are queue-4.14/rtlwifi-rtl_pci-fix-the-bug-when-inactiveps-is-enabled.patch

7 years, 3 months

1
0
0 0

Patch "rtlwifi: always initialize variables given to RT_TRACE()" has been added to the 4.14-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled rtlwifi: always initialize variables given to RT_TRACE() to the 4.14-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: rtlwifi-always-initialize-variables-given-to-rt_trace.patch and it can be found in the queue-4.14 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Thu Mar 22 14:26:48 CET 2018 From: Nicolas Iooss <nicolas.iooss_linux(a)m4x.org> Date: Sun, 10 Dec 2017 20:51:59 +0100 Subject: rtlwifi: always initialize variables given to RT_TRACE() From: Nicolas Iooss <nicolas.iooss_linux(a)m4x.org> [ Upstream commit e4779162f7377baa9fb9a044555ecaae22c3f125 ] In rtl_rx_ampdu_apply(), when rtlpriv->cfg->ops->get_btc_status() returns false, RT_TRACE() is called with the values of variables reject_agg and agg_size, which have not been initialized. Always initialize these variables in order to prevent using uninitialized values. This issue has been found with clang. The compiler reported: drivers/net/wireless/realtek/rtlwifi/base.c:1665:6: error: variable 'agg_size' is used uninitialized whenever 'if' condition is false [-Werror,-Wsometimes-uninitialized] if (rtlpriv->cfg->ops->get_btc_status()) ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ drivers/net/wireless/realtek/rtlwifi/base.c:1671:31: note: uninitialized use occurs here reject_agg, ctrl_agg_size, agg_size); ^~~~~~~~ drivers/net/wireless/realtek/rtlwifi/base.c:1665:6: error: variable 'reject_agg' is used uninitialized whenever 'if' condition is false [-Werror,-Wsometimes-uninitialized] if (rtlpriv->cfg->ops->get_btc_status()) ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ drivers/net/wireless/realtek/rtlwifi/base.c:1671:4: note: uninitialized use occurs here reject_agg, ctrl_agg_size, agg_size); ^~~~~~~~~~ Fixes: 2635664e6e4a ("rtlwifi: Add rx ampdu cfg for btcoexist.") Signed-off-by: Nicolas Iooss <nicolas.iooss_linux(a)m4x.org> Signed-off-by: Kalle Valo <kvalo(a)codeaurora.org> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/net/wireless/realtek/rtlwifi/base.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/drivers/net/wireless/realtek/rtlwifi/base.c +++ b/drivers/net/wireless/realtek/rtlwifi/base.c @@ -1664,7 +1664,7 @@ int rtl_tx_agg_oper(struct ieee80211_hw void rtl_rx_ampdu_apply(struct rtl_priv *rtlpriv) { struct rtl_btc_ops *btc_ops = rtlpriv->btcoexist.btc_ops; - u8 reject_agg, ctrl_agg_size = 0, agg_size; + u8 reject_agg = 0, ctrl_agg_size = 0, agg_size = 0; if (rtlpriv->cfg->ops->get_btc_status()) btc_ops->btc_get_ampdu_cfg(rtlpriv, &reject_agg, Patches currently in stable-queue which might be from nicolas.iooss_linux(a)m4x.org are queue-4.14/rtlwifi-always-initialize-variables-given-to-rt_trace.patch

7 years, 3 months

1
0
0 0

Patch "rtc: ac100: Fix multiple race conditions" has been added to the 4.14-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled rtc: ac100: Fix multiple race conditions to the 4.14-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: rtc-ac100-fix-multiple-race-conditions.patch and it can be found in the queue-4.14 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Thu Mar 22 14:26:48 CET 2018 From: Alexandre Belloni <alexandre.belloni(a)free-electrons.com> Date: Mon, 4 Dec 2017 14:58:33 +0100 Subject: rtc: ac100: Fix multiple race conditions From: Alexandre Belloni <alexandre.belloni(a)free-electrons.com> [ Upstream commit 994ec64c0a193940be7a6fd074668b9446d3b6c3 ] The probe function is not allowed to fail after registering the RTC because the following may happen: CPU0: CPU1: sys_load_module() do_init_module() do_one_initcall() cmos_do_probe() rtc_device_register() __register_chrdev() cdev->owner = struct module* open("/dev/rtc0") rtc_device_unregister() module_put() free_module() module_free(mod->module_core) /* struct module *module is now freed */ chrdev_open() spin_lock(cdev_lock) cdev_get() try_module_get() module_is_live() /* dereferences already freed struct module* */ Also, the interrupt handler: ac100_rtc_irq() is dereferencing chip->rtc but this may still be NULL when it is called, resulting in: Unable to handle kernel NULL pointer dereference at virtual address 00000194 pgd = (ptrval) [00000194] *pgd=00000000 Internal error: Oops: 5 [#1] SMP ARM Modules linked in: CPU: 0 PID: 72 Comm: irq/71-ac100-rt Not tainted 4.15.0-rc1-next-20171201-dirty #120 Hardware name: Allwinner sun8i Family task: (ptrval) task.stack: (ptrval) PC is at mutex_lock+0x14/0x3c LR is at ac100_rtc_irq+0x38/0xc8 pc : [<c06543a4>] lr : [<c04d9a2c>] psr: 60000053 sp : ee9c9f28 ip : 00000000 fp : ee9adfdc r10: 00000000 r9 : c0a04c48 r8 : c015ed18 r7 : ee9bd600 r6 : ee9c9f28 r5 : ee9af590 r4 : c0a04c48 r3 : ef3cb3c0 r2 : 00000000 r1 : ee9af590 r0 : 00000194 Flags: nZCv IRQs on FIQs off Mode SVC_32 ISA ARM Segment none Control: 10c5387d Table: 4000406a DAC: 00000051 Process irq/71-ac100-rt (pid: 72, stack limit = 0x(ptrval)) Stack: (0xee9c9f28 to 0xee9ca000) 9f20: 00000000 7c2fd1be c015ed18 ee9adf40 ee9c0400 ee9c0400 9f40: ee9adf40 c015ed34 ee9c8000 ee9adf64 ee9c0400 c015f040 ee9adf80 00000000 9f60: c015ee24 7c2fd1be ee9adfc0 ee9adf80 00000000 ee9c8000 ee9adf40 c015eef4 9f80: ef1eba34 c0138f14 ee9c8000 ee9adf80 c0138df4 00000000 00000000 00000000 9fa0: 00000000 00000000 00000000 c01010e8 00000000 00000000 00000000 00000000 9fc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 9fe0: 00000000 00000000 00000000 00000000 00000013 00000000 ffffffff ffffffff [<c06543a4>] (mutex_lock) from [<c04d9a2c>] (ac100_rtc_irq+0x38/0xc8) [<c04d9a2c>] (ac100_rtc_irq) from [<c015ed34>] (irq_thread_fn+0x1c/0x54) [<c015ed34>] (irq_thread_fn) from [<c015f040>] (irq_thread+0x14c/0x214) [<c015f040>] (irq_thread) from [<c0138f14>] (kthread+0x120/0x150) [<c0138f14>] (kthread) from [<c01010e8>] (ret_from_fork+0x14/0x2c) Solve both issues by moving to devm_rtc_allocate_device()/rtc_register_device() Reported-by: Quentin Schulz <quentin.schulz(a)free-electrons.com> Tested-by: Quentin Schulz <quentin.schulz(a)free-electrons.com> Signed-off-by: Alexandre Belloni <alexandre.belloni(a)free-electrons.com> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/rtc/rtc-ac100.c | 19 ++++++++++++------- 1 file changed, 12 insertions(+), 7 deletions(-) --- a/drivers/rtc/rtc-ac100.c +++ b/drivers/rtc/rtc-ac100.c @@ -567,6 +567,12 @@ static int ac100_rtc_probe(struct platfo return chip->irq; } + chip->rtc = devm_rtc_allocate_device(&pdev->dev); + if (IS_ERR(chip->rtc)) + return PTR_ERR(chip->rtc); + + chip->rtc->ops = &ac100_rtc_ops; + ret = devm_request_threaded_irq(&pdev->dev, chip->irq, NULL, ac100_rtc_irq, IRQF_SHARED | IRQF_ONESHOT, @@ -586,17 +592,16 @@ static int ac100_rtc_probe(struct platfo /* clear counter alarm pending interrupts */ regmap_write(chip->regmap, AC100_ALM_INT_STA, AC100_ALM_INT_ENABLE); - chip->rtc = devm_rtc_device_register(&pdev->dev, "rtc-ac100", - &ac100_rtc_ops, THIS_MODULE); - if (IS_ERR(chip->rtc)) { - dev_err(&pdev->dev, "unable to register device\n"); - return PTR_ERR(chip->rtc); - } - ret = ac100_rtc_register_clks(chip); if (ret) return ret; + ret = rtc_register_device(chip->rtc); + if (ret) { + dev_err(&pdev->dev, "unable to register device\n"); + return ret; + } + dev_info(&pdev->dev, "RTC enabled\n"); return 0; Patches currently in stable-queue which might be from alexandre.belloni(a)free-electrons.com are queue-4.14/clk-at91-pmc-wait-for-clocks-when-resuming.patch queue-4.14/rtc-ac100-fix-multiple-race-conditions.patch

7 years, 3 months

1
0
0 0

Patch "RDMA/ocrdma: Fix permissions for OCRDMA_RESET_STATS" has been added to the 4.14-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled RDMA/ocrdma: Fix permissions for OCRDMA_RESET_STATS to the 4.14-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: rdma-ocrdma-fix-permissions-for-ocrdma_reset_stats.patch and it can be found in the queue-4.14 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Thu Mar 22 14:26:48 CET 2018 From: Anton Vasilyev <vasilyev(a)ispras.ru> Date: Tue, 8 Aug 2017 18:56:37 +0300 Subject: RDMA/ocrdma: Fix permissions for OCRDMA_RESET_STATS From: Anton Vasilyev <vasilyev(a)ispras.ru> [ Upstream commit 744820869166c8c78be891240cf5f66e8a333694 ] Debugfs file reset_stats is created with S_IRUSR permissions, but ocrdma_dbgfs_ops_read() doesn't support OCRDMA_RESET_STATS, whereas ocrdma_dbgfs_ops_write() supports only OCRDMA_RESET_STATS. The patch fixes misstype with permissions. Found by Linux Driver Verification project (linuxtesting.org). Signed-off-by: Anton Vasilyev <vasilyev(a)ispras.ru> Acked-by: Selvin Xavier <selvin.xavier(a)broadcom.com> Signed-off-by: Jason Gunthorpe <jgg(a)mellanox.com> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/infiniband/hw/ocrdma/ocrdma_stats.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/drivers/infiniband/hw/ocrdma/ocrdma_stats.c +++ b/drivers/infiniband/hw/ocrdma/ocrdma_stats.c @@ -834,7 +834,7 @@ void ocrdma_add_port_stats(struct ocrdma dev->reset_stats.type = OCRDMA_RESET_STATS; dev->reset_stats.dev = dev; - if (!debugfs_create_file("reset_stats", S_IRUSR, dev->dir, + if (!debugfs_create_file("reset_stats", 0200, dev->dir, &dev->reset_stats, &ocrdma_dbg_ops)) goto err; Patches currently in stable-queue which might be from vasilyev(a)ispras.ru are queue-4.14/rdma-ocrdma-fix-permissions-for-ocrdma_reset_stats.patch

7 years, 3 months

1
0
0 0

Patch "RDMA/iwpm: Fix uninitialized error code in iwpm_send_mapinfo()" has been added to the 4.14-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled RDMA/iwpm: Fix uninitialized error code in iwpm_send_mapinfo() to the 4.14-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: rdma-iwpm-fix-uninitialized-error-code-in-iwpm_send_mapinfo.patch and it can be found in the queue-4.14 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Thu Mar 22 14:26:48 CET 2018 From: Geert Uytterhoeven <geert(a)linux-m68k.org> Date: Wed, 29 Nov 2017 09:47:33 +0100 Subject: RDMA/iwpm: Fix uninitialized error code in iwpm_send_mapinfo() From: Geert Uytterhoeven <geert(a)linux-m68k.org> [ Upstream commit 302d6424e4a293a5761997e6c9fc3dfb1e4c355f ] With gcc-4.1.2: drivers/infiniband/core/iwpm_util.c: In function ‘iwpm_send_mapinfo’: drivers/infiniband/core/iwpm_util.c:647: warning: ‘ret’ may be used uninitialized in this function Indeed, if nl_client is not found in any of the scanned has buckets, ret will be used uninitialized. Preinitialize ret to -EINVAL to fix this. Fixes: 30dc5e63d6a5ad24 ("RDMA/core: Add support for iWARP Port Mapper user space service") Signed-off-by: Geert Uytterhoeven <geert(a)linux-m68k.org> Reviewed-by: Tatyana Nikolova <tatyana.e.nikolova(a)intel.com> Signed-off-by: Jason Gunthorpe <jgg(a)mellanox.com> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/infiniband/core/iwpm_util.c | 1 + 1 file changed, 1 insertion(+) --- a/drivers/infiniband/core/iwpm_util.c +++ b/drivers/infiniband/core/iwpm_util.c @@ -654,6 +654,7 @@ int iwpm_send_mapinfo(u8 nl_client, int } skb_num++; spin_lock_irqsave(&iwpm_mapinfo_lock, flags); + ret = -EINVAL; for (i = 0; i < IWPM_MAPINFO_HASH_SIZE; i++) { hlist_for_each_entry(map_info, &iwpm_hash_bucket[i], hlist_node) { Patches currently in stable-queue which might be from geert(a)linux-m68k.org are queue-4.14/rdma-iwpm-fix-uninitialized-error-code-in-iwpm_send_mapinfo.patch

7 years, 3 months

1
0
0 0

Patch "RDMA/cma: Use correct size when writing netlink stats" has been added to the 4.14-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled RDMA/cma: Use correct size when writing netlink stats to the 4.14-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: rdma-cma-use-correct-size-when-writing-netlink-stats.patch and it can be found in the queue-4.14 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Thu Mar 22 14:26:48 CET 2018 From: Parav Pandit <parav(a)mellanox.com> Date: Tue, 14 Nov 2017 14:51:55 +0200 Subject: RDMA/cma: Use correct size when writing netlink stats From: Parav Pandit <parav(a)mellanox.com> [ Upstream commit 7baaa49af3716fb31877c61f59b74d029ce15b75 ] The code was using the src size when formatting the dst. They are almost certainly the same value but it reads wrong. Fixes: ce117ffac2e9 ("RDMA/cma: Export AF_IB statistics") Signed-off-by: Parav Pandit <parav(a)mellanox.com> Reviewed-by: Daniel Jurgens <danielj(a)mellanox.com> Signed-off-by: Leon Romanovsky <leon(a)kernel.org> Signed-off-by: Jason Gunthorpe <jgg(a)mellanox.com> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/infiniband/core/cma.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/drivers/infiniband/core/cma.c +++ b/drivers/infiniband/core/cma.c @@ -4436,7 +4436,7 @@ static int cma_get_id_stats(struct sk_bu RDMA_NL_RDMA_CM_ATTR_SRC_ADDR)) goto out; if (ibnl_put_attr(skb, nlh, - rdma_addr_size(cma_src_addr(id_priv)), + rdma_addr_size(cma_dst_addr(id_priv)), cma_dst_addr(id_priv), RDMA_NL_RDMA_CM_ATTR_DST_ADDR)) goto out; Patches currently in stable-queue which might be from parav(a)mellanox.com are queue-4.14/rdma-cma-use-correct-size-when-writing-netlink-stats.patch

7 years, 3 months

1
0
0 0

Patch "qmi_wwan: set FLAG_SEND_ZLP to avoid network initiated disconnect" has been added to the 4.14-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled qmi_wwan: set FLAG_SEND_ZLP to avoid network initiated disconnect to the 4.14-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: qmi_wwan-set-flag_send_zlp-to-avoid-network-initiated-disconnect.patch and it can be found in the queue-4.14 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Thu Mar 22 14:26:48 CET 2018 From: "Bjørn Mork" <bjorn(a)mork.no> Date: Thu, 14 Dec 2017 19:55:50 +0100 Subject: qmi_wwan: set FLAG_SEND_ZLP to avoid network initiated disconnect From: "Bjørn Mork" <bjorn(a)mork.no> [ Upstream commit 245d21190aec547c0de64f70c0e6de871c185a24 ] It has been reported that the dummy byte we add to avoid ZLPs can be forwarded by the modem to the PGW/GGSN, and that some operators will drop the connection if this happens. In theory, QMI devices are based on CDC ECM and should as such both support ZLPs and silently ignore the dummy byte. The latter assumption failed. Let's test out the first. Signed-off-by: BjÃ¸rn Mork <bjorn(a)mork.no> Signed-off-by: David S. Miller <davem(a)davemloft.net> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/net/usb/qmi_wwan.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) --- a/drivers/net/usb/qmi_wwan.c +++ b/drivers/net/usb/qmi_wwan.c @@ -826,7 +826,7 @@ err: static const struct driver_info qmi_wwan_info = { .description = "WWAN/QMI device", - .flags = FLAG_WWAN, + .flags = FLAG_WWAN | FLAG_SEND_ZLP, .bind = qmi_wwan_bind, .unbind = qmi_wwan_unbind, .manage_power = qmi_wwan_manage_power, @@ -835,7 +835,7 @@ static const struct driver_info qmi_wwan static const struct driver_info qmi_wwan_info_quirk_dtr = { .description = "WWAN/QMI device", - .flags = FLAG_WWAN, + .flags = FLAG_WWAN | FLAG_SEND_ZLP, .bind = qmi_wwan_bind, .unbind = qmi_wwan_unbind, .manage_power = qmi_wwan_manage_power, Patches currently in stable-queue which might be from bjorn(a)mork.no are queue-4.14/qmi_wwan-set-flag_send_zlp-to-avoid-network-initiated-disconnect.patch

7 years, 3 months

1
0
0 0

Patch "pty: cancel pty slave port buf's work in tty_release" has been added to the 4.14-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled pty: cancel pty slave port buf's work in tty_release to the 4.14-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: pty-cancel-pty-slave-port-buf-s-work-in-tty_release.patch and it can be found in the queue-4.14 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Thu Mar 22 14:26:48 CET 2018 From: Sahara <keun-o.park(a)darkmatter.ae> Date: Wed, 13 Dec 2017 09:10:48 +0400 Subject: pty: cancel pty slave port buf's work in tty_release From: Sahara <keun-o.park(a)darkmatter.ae> [ Upstream commit 2b022ab7542df60021ab57854b3faaaf42552eaf ] In case that CONFIG_SLUB_DEBUG is on and pty is used, races between release_one_tty and flush_to_ldisc work threads may happen and lead to use-after-free condition on tty->link->port. Because SLUB_DEBUG is turned on, freed tty->link->port is filled with POISON_FREE value. So far without SLUB_DEBUG, port was filled with zero and flush_to_ldisc could return without a problem by checking if tty is NULL. CPU 0 CPU 1 ----- ----- release_tty pty_write cancel_work_sync(tty) to = tty->link tty_kref_put(tty->link) tty_schedule_flip(to->port) << workqueue >> ... release_one_tty ... pty_cleanup ... kfree(tty->link->port) << workqueue >> flush_to_ldisc tty = READ_ONCE(port->itty) tty is 0x6b6b6b6b6b6b6b6b !!PANIC!! access tty->ldisc Unable to handle kernel paging request at virtual address 6b6b6b6b6b6b6b93 pgd = ffffffc0eb1c3000 [6b6b6b6b6b6b6b93] *pgd=0000000000000000, *pud=0000000000000000 ------------[ cut here ]------------ Kernel BUG at ffffff800851154c [verbose debug info unavailable] Internal error: Oops - BUG: 96000004 [#1] PREEMPT SMP CPU: 3 PID: 265 Comm: kworker/u8:9 Tainted: G W 3.18.31-g0a58eeb #1 Hardware name: Qualcomm Technologies, Inc. MSM 8996pro v1.1 + PMI8996 Carbide (DT) Workqueue: events_unbound flush_to_ldisc task: ffffffc0ed610ec0 ti: ffffffc0ed624000 task.ti: ffffffc0ed624000 PC is at ldsem_down_read_trylock+0x0/0x4c LR is at tty_ldisc_ref+0x24/0x4c pc : [<ffffff800851154c>] lr : [<ffffff800850f6c0>] pstate: 80400145 sp : ffffffc0ed627cd0 x29: ffffffc0ed627cd0 x28: 0000000000000000 x27: ffffff8009e05000 x26: ffffffc0d382cfa0 x25: 0000000000000000 x24: ffffff800a012f08 x23: 0000000000000000 x22: ffffffc0703fbc88 x21: 6b6b6b6b6b6b6b6b x20: 6b6b6b6b6b6b6b93 x19: 0000000000000000 x18: 0000000000000001 x17: 00e80000f80d6f53 x16: 0000000000000001 x15: 0000007f7d826fff x14: 00000000000000a0 x13: 0000000000000000 x12: 0000000000000109 x11: 0000000000000000 x10: 0000000000000000 x9 : ffffffc0ed624000 x8 : ffffffc0ed611580 x7 : 0000000000000000 x6 : ffffff800a42e000 x5 : 00000000000003fc x4 : 0000000003bd1201 x3 : 0000000000000001 x2 : 0000000000000001 x1 : ffffff800851004c x0 : 6b6b6b6b6b6b6b93 Signed-off-by: Sahara <keun-o.park(a)darkmatter.ae> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/tty/tty_io.c | 2 ++ 1 file changed, 2 insertions(+) --- a/drivers/tty/tty_io.c +++ b/drivers/tty/tty_io.c @@ -1481,6 +1481,8 @@ static void release_tty(struct tty_struc if (tty->link) tty->link->port->itty = NULL; tty_buffer_cancel_work(tty->port); + if (tty->link) + tty_buffer_cancel_work(tty->link->port); tty_kref_put(tty->link); tty_kref_put(tty); Patches currently in stable-queue which might be from keun-o.park(a)darkmatter.ae are queue-4.14/pty-cancel-pty-slave-port-buf-s-work-in-tty_release.patch

7 years, 3 months

1
0
0 0

Patch "platform/chrome: Use proper protocol transfer function" has been added to the 4.14-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled platform/chrome: Use proper protocol transfer function to the 4.14-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: platform-chrome-use-proper-protocol-transfer-function.patch and it can be found in the queue-4.14 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Thu Mar 22 14:26:48 CET 2018 From: Shawn Nematbakhsh <shawnn(a)chromium.org> Date: Fri, 8 Sep 2017 13:50:11 -0700 Subject: platform/chrome: Use proper protocol transfer function From: Shawn Nematbakhsh <shawnn(a)chromium.org> [ Upstream commit d48b8c58c57f6edbe2965f0a5f62c5cf9593ca96 ] pkt_xfer should be used for protocol v3, and cmd_xfer otherwise. We had one instance of these functions correct, but not the second, fall-back case. We use the fall-back only when the first command returns an IN_PROGRESS status, which is only used on some EC firmwares where we don't want to constantly poll the bus, but instead back off and sleep/retry for a little while. Fixes: 2c7589af3c4d ("mfd: cros_ec: add proto v3 skeleton") Signed-off-by: Shawn Nematbakhsh <shawnn(a)chromium.org> Signed-off-by: Brian Norris <briannorris(a)chromium.org> Reviewed-by: Javier Martinez Canillas <javier(a)osg.samsung.com> Signed-off-by: Benson Leung <bleung(a)chromium.org> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/platform/chrome/cros_ec_proto.c | 8 +++++--- 1 file changed, 5 insertions(+), 3 deletions(-) --- a/drivers/platform/chrome/cros_ec_proto.c +++ b/drivers/platform/chrome/cros_ec_proto.c @@ -60,12 +60,14 @@ static int send_command(struct cros_ec_d struct cros_ec_command *msg) { int ret; + int (*xfer_fxn)(struct cros_ec_device *ec, struct cros_ec_command *msg); if (ec_dev->proto_version > 2) - ret = ec_dev->pkt_xfer(ec_dev, msg); + xfer_fxn = ec_dev->pkt_xfer; else - ret = ec_dev->cmd_xfer(ec_dev, msg); + xfer_fxn = ec_dev->cmd_xfer; + ret = (*xfer_fxn)(ec_dev, msg); if (msg->result == EC_RES_IN_PROGRESS) { int i; struct cros_ec_command *status_msg; @@ -88,7 +90,7 @@ static int send_command(struct cros_ec_d for (i = 0; i < EC_COMMAND_RETRIES; i++) { usleep_range(10000, 11000); - ret = ec_dev->cmd_xfer(ec_dev, status_msg); + ret = (*xfer_fxn)(ec_dev, status_msg); if (ret < 0) break; Patches currently in stable-queue which might be from shawnn(a)chromium.org are queue-4.14/platform-chrome-use-proper-protocol-transfer-function.patch

7 years, 3 months

1
0
0 0

Patch "pinctrl: rockchip: enable clock when reading pin direction register" has been added to the 4.14-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled pinctrl: rockchip: enable clock when reading pin direction register to the 4.14-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: pinctrl-rockchip-enable-clock-when-reading-pin-direction-register.patch and it can be found in the queue-4.14 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Thu Mar 22 14:26:48 CET 2018 From: Brian Norris <briannorris(a)chromium.org> Date: Tue, 12 Dec 2017 09:43:43 -0800 Subject: pinctrl: rockchip: enable clock when reading pin direction register From: Brian Norris <briannorris(a)chromium.org> [ Upstream commit 5c9d8c4f6b8168738a26bcf288516cc3a0886810 ] We generally leave the GPIO clock disabled, unless an interrupt is requested or we're accessing IO registers. We forgot to do this for the ->get_direction() callback, which means we can sometimes [1] get incorrect results [2] from, e.g., /sys/kernel/debug/gpio. Enable the clock, so we get the right results! [1] Sometimes, because many systems have 1 or mor interrupt requested on each GPIO bank, so they always leave their clock on. [2] Incorrect, meaning the register returns 0, and so we interpret that as "input". Signed-off-by: Brian Norris <briannorris(a)chromium.org> Reviewed-by: Heiko Stuebner <heiko(a)sntech.de> Signed-off-by: Linus Walleij <linus.walleij(a)linaro.org> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/pinctrl/pinctrl-rockchip.c | 8 ++++++++ 1 file changed, 8 insertions(+) --- a/drivers/pinctrl/pinctrl-rockchip.c +++ b/drivers/pinctrl/pinctrl-rockchip.c @@ -1989,8 +1989,16 @@ static int rockchip_gpio_get_direction(s { struct rockchip_pin_bank *bank = gpiochip_get_data(chip); u32 data; + int ret; + ret = clk_enable(bank->clk); + if (ret < 0) { + dev_err(bank->drvdata->dev, + "failed to enable clock for bank %s\n", bank->name); + return ret; + } data = readl_relaxed(bank->reg_base + GPIO_SWPORT_DDR); + clk_disable(bank->clk); return !(data & BIT(offset)); } Patches currently in stable-queue which might be from briannorris(a)chromium.org are queue-4.14/pinctrl-rockchip-enable-clock-when-reading-pin-direction-register.patch queue-4.14/platform-chrome-use-proper-protocol-transfer-function.patch

7 years, 3 months

1
0
0 0

Patch "pinctrl: Really force states during suspend/resume" has been added to the 4.14-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled pinctrl: Really force states during suspend/resume to the 4.14-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: pinctrl-really-force-states-during-suspend-resume.patch and it can be found in the queue-4.14 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Thu Mar 22 14:26:48 CET 2018 From: Florian Fainelli <f.fainelli(a)gmail.com> Date: Wed, 1 Mar 2017 10:32:57 -0800 Subject: pinctrl: Really force states during suspend/resume From: Florian Fainelli <f.fainelli(a)gmail.com> [ Upstream commit 981ed1bfbc6c4660b2ddaa8392893e20a6255048 ] In case a platform only defaults a "default" set of pins, but not a "sleep" set of pins, and this particular platform suspends and resumes in a way that the pin states are not preserved by the hardware, when we resume, we would call pinctrl_single_resume() -> pinctrl_force_default() -> pinctrl_select_state() and the first thing we do is check that the pins state is the same as before, and do nothing. In order to fix this, decouple the actual state change from pinctrl_select_state() and move it pinctrl_commit_state(), while keeping the p->state == state check in pinctrl_select_state() not to change the caller assumptions. pinctrl_force_sleep() and pinctrl_force_default() are updated to bypass the state check by calling pinctrl_commit_state(). [Linus Walleij] The forced pin control states are currently only used in some pin controller drivers that grab their own reference to their own pins. This is equal to the pin control hogs: pins taken by pin control devices since there are no corresponding device in the Linux device hierarchy, such as memory controller lines or unused GPIO lines, or GPIO lines that are used orthogonally from the GPIO subsystem but pincontrol-wise managed as hogs (non-strict mode, allowing simultaneous use by GPIO and pin control). For this case forcing the state from the drivers' suspend()/resume() callbacks makes sense and should semantically match the name of the function. Fixes: 6e5e959dde0d ("pinctrl: API changes to support multiple states per device") Signed-off-by: Florian Fainelli <f.fainelli(a)gmail.com> Reviewed-by: Andy Shevchenko <andy.shevchenko(a)gmail.com> Signed-off-by: Linus Walleij <linus.walleij(a)linaro.org> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/pinctrl/core.c | 24 +++++++++++++++++------- 1 file changed, 17 insertions(+), 7 deletions(-) --- a/drivers/pinctrl/core.c +++ b/drivers/pinctrl/core.c @@ -1189,19 +1189,16 @@ struct pinctrl_state *pinctrl_lookup_sta EXPORT_SYMBOL_GPL(pinctrl_lookup_state); /** - * pinctrl_select_state() - select/activate/program a pinctrl state to HW + * pinctrl_commit_state() - select/activate/program a pinctrl state to HW * @p: the pinctrl handle for the device that requests configuration * @state: the state handle to select/activate/program */ -int pinctrl_select_state(struct pinctrl *p, struct pinctrl_state *state) +static int pinctrl_commit_state(struct pinctrl *p, struct pinctrl_state *state) { struct pinctrl_setting *setting, *setting2; struct pinctrl_state *old_state = p->state; int ret; - if (p->state == state) - return 0; - if (p->state) { /* * For each pinmux setting in the old state, forget SW's record @@ -1265,6 +1262,19 @@ unapply_new_state: return ret; } + +/** + * pinctrl_select_state() - select/activate/program a pinctrl state to HW + * @p: the pinctrl handle for the device that requests configuration + * @state: the state handle to select/activate/program + */ +int pinctrl_select_state(struct pinctrl *p, struct pinctrl_state *state) +{ + if (p->state == state) + return 0; + + return pinctrl_commit_state(p, state); +} EXPORT_SYMBOL_GPL(pinctrl_select_state); static void devm_pinctrl_release(struct device *dev, void *res) @@ -1430,7 +1440,7 @@ void pinctrl_unregister_map(const struct int pinctrl_force_sleep(struct pinctrl_dev *pctldev) { if (!IS_ERR(pctldev->p) && !IS_ERR(pctldev->hog_sleep)) - return pinctrl_select_state(pctldev->p, pctldev->hog_sleep); + return pinctrl_commit_state(pctldev->p, pctldev->hog_sleep); return 0; } EXPORT_SYMBOL_GPL(pinctrl_force_sleep); @@ -1442,7 +1452,7 @@ EXPORT_SYMBOL_GPL(pinctrl_force_sleep); int pinctrl_force_default(struct pinctrl_dev *pctldev) { if (!IS_ERR(pctldev->p) && !IS_ERR(pctldev->hog_default)) - return pinctrl_select_state(pctldev->p, pctldev->hog_default); + return pinctrl_commit_state(pctldev->p, pctldev->hog_default); return 0; } EXPORT_SYMBOL_GPL(pinctrl_force_default); Patches currently in stable-queue which might be from f.fainelli(a)gmail.com are queue-4.14/pinctrl-really-force-states-during-suspend-resume.patch

7 years, 3 months

1
0
0 0

Patch "PCI: rcar: Handle rcar_pcie_parse_request_of_pci_ranges() failures" has been added to the 4.14-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled PCI: rcar: Handle rcar_pcie_parse_request_of_pci_ranges() failures to the 4.14-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: pci-rcar-handle-rcar_pcie_parse_request_of_pci_ranges-failures.patch and it can be found in the queue-4.14 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Thu Mar 22 14:26:48 CET 2018 From: Geert Uytterhoeven <geert+renesas(a)glider.be> Date: Thu, 7 Dec 2017 11:15:20 +0100 Subject: PCI: rcar: Handle rcar_pcie_parse_request_of_pci_ranges() failures From: Geert Uytterhoeven <geert+renesas(a)glider.be> [ Upstream commit 83c75ddd816e979802bd244ad494139f28152921 ] rcar_pcie_parse_request_of_pci_ranges() can fail and return an error code, but this is not checked nor handled. Fix this by adding the missing error handling. Fixes: 5d2917d469faab72 ("PCI: rcar: Convert to DT resource parsing API") Signed-off-by: Geert Uytterhoeven <geert+renesas(a)glider.be> Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi(a)arm.com> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/pci/host/pcie-rcar.c | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) --- a/drivers/pci/host/pcie-rcar.c +++ b/drivers/pci/host/pcie-rcar.c @@ -1141,7 +1141,9 @@ static int rcar_pcie_probe(struct platfo INIT_LIST_HEAD(&pcie->resources); - rcar_pcie_parse_request_of_pci_ranges(pcie); + err = rcar_pcie_parse_request_of_pci_ranges(pcie); + if (err) + goto err_free_bridge; err = rcar_pcie_get_resources(pcie); if (err < 0) { @@ -1196,6 +1198,7 @@ err_pm_disable: err_free_resource_list: pci_free_resource_list(&pcie->resources); +err_free_bridge: pci_free_host_bridge(bridge); return err; Patches currently in stable-queue which might be from geert+renesas(a)glider.be are queue-4.14/spi-sh-msiof-avoid-writing-to-registers-from-spi_master.setup.patch queue-4.14/pci-rcar-handle-rcar_pcie_parse_request_of_pci_ranges-failures.patch

7 years, 3 months

1
0
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror