summaryrefslogtreecommitdiff
path: root/drivers
AgeCommit message (Collapse)Author
2020-05-13net: broadcom: Select BROADCOM_PHY for BCMGENETFlorian Fainelli
The GENET controller on the Raspberry Pi 4 (2711) is typically interfaced with an external Broadcom PHY via a RGMII electrical interface. To make sure that delays are properly configured at the PHY side, ensure that we the dedicated Broadcom PHY driver (CONFIG_BROADCOM_PHY) is enabled for this to happen. Fixes: 402482a6a78e ("net: bcmgenet: Clear ID_MODE_DIS in EXT_RGMII_OOB_CTRL when not needed") Reported-by: Marek Szyprowski <m.szyprowski@samsung.com> Signed-off-by: Florian Fainelli <f.fainelli@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2020-05-13s390/ism: fix error return code in ism_probe()Wei Yongjun
Fix to return negative error code -ENOMEM from the smcd_alloc_dev() error handling case instead of 0, as done elsewhere in this function. Fixes: 684b89bc39ce ("s390/ism: add device driver for internal shared memory") Reported-by: Hulk Robot <hulkci@huawei.com> Signed-off-by: Wei Yongjun <weiyongjun1@huawei.com> Signed-off-by: Ursula Braun <ubraun@linux.ibm.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2020-05-13hwmon: (da9052) Synchronize access with mfdSamu Nuutamo
When tsi-as-adc is configured it is possible for in7[0123]_input read to return an incorrect value if a concurrent read to in[456]_input is performed. This is caused by a concurrent manipulation of the mux channel without proper locking as hwmon and mfd use different locks for synchronization. Switch hwmon to use the same lock as mfd when accessing the TSI channel. Fixes: 4f16cab19a3d5 ("hwmon: da9052: Add support for TSI channel") Signed-off-by: Samu Nuutamo <samu.nuutamo@vincit.fi> [rebase to current master, reword commit message slightly] Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com> Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2020-05-13hwmon: (nct7904) Fix incorrect range of temperature limit registersAmy Shih
The format of temperature limitation registers are 8-bit 2's complement and the range is -128~127. Converts the reading value to signed char to fix the incorrect range of temperature limitation registers. Signed-off-by: Amy Shih <amy.shih@advantech.com.tw> Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2020-05-13hwmon: (nct7904) Read all SMI status registers in probe functionAmy Shih
When nct7904 power up, it compares current sensor readings against the default threshold immediately. This results in false alarms on startup. Read all SMI status registers in probe function to clear the alarms. Signed-off-by: Amy Shih <amy.shih@advantech.com.tw> [groeck: Reworded description] Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2020-05-13usb: typec: mux: intel: Fix DP_HPD_LVL bit fieldPrashant Malani
According to the PMC Type C Subsystem (TCSS) Mux programming guide rev 0.6, the PMC HPD request LVL bit field is bit 4. Fix the definition here to match the programming guide. Since this bit field is changing, explicitly define a field for the HPD_HIGH mode data bit. Signed-off-by: Prashant Malani <pmalani@chromium.org> Fixes: 6701adfa9693 ("usb: typec: driver for Intel PMC mux control") Reviewed-by: Benson Leung <bleung@chromium.org> Acked-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> Link: https://lore.kernel.org/r/20200511091837.102508-1-pmalani@chromium.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-05-13Merge tag 'fixes-for-v5.7-rc5' of ↵Greg Kroah-Hartman
git://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb into usb-linus Felipe writes: USB: fixes for v5.7-rc5 Fixing raw-gadget's IOCTL return value. Enabling EXTCON for Intel Merrifield. Couple leaks have been plugged in net2272 and twl6030-usb. Returning an error code when things fail in cdc and ncm legacy gadgets. An old bug on dwc3 regarding HWO bit handling has been fixed. Apart from these, some minor fixes. Signed-off-by: Felipe Balbi <balbi@kernel.org> * tag 'fixes-for-v5.7-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb: usb: raw-gadget: fix return value of ep read ioctls usb: dwc3: select USB_ROLE_SWITCH usb: gadget: legacy: fix error return code in gncm_bind() usb: gadget: legacy: fix error return code in cdc_bind() usb: gadget: legacy: fix redundant initialization warnings usb: gadget: tegra-xudc: Fix idle suspend/resume usb: gadget: net2272: Fix a memory leak in an error handling path in 'net2272_plat_probe()' usb: phy: twl6030-usb: Fix a resource leak in an error handling path in 'twl6030_usb_probe()' usb: cdns3: gadget: prev_req->trb is NULL for ep0 usb: gadget: audio: Fix a missing error return value in audio_bind() usb: dwc3: pci: Enable extcon driver for Intel Merrifield dwc3: Remove check for HWO flag in dwc3_gadget_ep_reclaim_trb_sg()
2020-05-13staging: wfx: unlock on error pathDan Carpenter
We need to release the tx_lock on the error path before returning. Fixes: d1c015b4ef6f ("staging: wfx: rewrite wfx_hw_scan()") Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> Cc: stable <stable@vger.kernel.org> Reviewed-by: Jérôme Pouiller <jerome.pouiller@silabs.com> Link: https://lore.kernel.org/r/20200512083656.GA251760@mwanda Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-05-13staging: greybus: Fix uninitialized scalar variableOscar Carter
In the "gb_tty_set_termios" function the "newline" variable is declared but not initialized. So the "flow_control" member is not initialized and the OR / AND operations with itself results in an undefined value in this member. The purpose of the code is to set the flow control type, so remove the OR / AND self operator and set the value directly. Addresses-Coverity-ID: 1374016 ("Uninitialized scalar variable") Fixes: e55c25206d5c9 ("greybus: uart: Handle CRTSCTS flag in termios") Signed-off-by: Oscar Carter <oscar.carter@gmx.com> Cc: stable <stable@vger.kernel.org> Link: https://lore.kernel.org/r/20200510101426.23631-1-oscar.carter@gmx.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-05-13staging: kpc2000: fix error return code in kp2000_pcie_probe()Wei Yongjun
Fix to return a negative error code from the error handling case instead of 0, as done elsewhere in this function. Also removed var 'rv' since we can use 'err' instead. Fixes: 7dc7967fc39a ("staging: kpc2000: add initial set of Daktronics drivers") Signed-off-by: Wei Yongjun <weiyongjun1@huawei.com> Cc: stable <stable@vger.kernel.org> Reviewed-by: Dan Carpenter <dan.carpenter@oracle.com> Link: https://lore.kernel.org/r/20200506134735.102041-1-weiyongjun1@huawei.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-05-13dmaengine: dmatest: Restore default for channelVladimir Murzin
In case of dmatest is built-in and no channel was configured test doesn't run with: dmatest: Could not start test, no channels configured Even though description to "channel" parameter claims that default is any. Add default channel back as it used to be rather than reject test with no channel configuration. Fixes: d53513d5dc285d9a95a534fc41c5c08af6b60eac ("dmaengine: dmatest: Add support for multi channel testing) Reported-by: Dijil Mohan <Dijil.Mohan@arm.com> Signed-off-by: Vladimir Murzin <vladimir.murzin@arm.com> Link: https://lore.kernel.org/r/20200429071522.58148-1-vladimir.murzin@arm.com Signed-off-by: Vinod Koul <vkoul@kernel.org>
2020-05-13drm/meson: pm resume add return errno branchBernard Zhao
pm_resump api did not handle drm_mode_config_helper_resume error. This change add handle to return drm_mode_config_helper_resume`s error number. This code logic is aligned with api pm_suspend. After this change, the code maybe a bit readable. Signed-off-by: Bernard Zhao <bernard@vivo.com> Signed-off-by: Neil Armstrong <narmstrong@baylibre.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200428131747.2099-1-bernard@vivo.com
2020-05-13iommu/amd: Fix get_acpihid_device_id()Raul E Rangel
acpi_dev_hid_uid_match() expects a null pointer for UID if it doesn't exist. The acpihid_map_entry contains a char buffer for holding the UID. If no UID was provided in the IVRS table, this buffer will be zeroed. If we pass in a null string, acpi_dev_hid_uid_match() will return false because it will try and match an empty string to the ACPI UID of the device. Fixes: ae5e6c6439c3 ("iommu/amd: Switch to use acpi_dev_hid_uid_match()") Suggested-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Raul E Rangel <rrangel@chromium.org> Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com> Link: https://lore.kernel.org/r/20200511103229.v2.1.I6f1b6f973ee6c8af1348611370c73a0ec0ea53f1@changeid Signed-off-by: Joerg Roedel <jroedel@suse.de>
2020-05-13iommu/amd: Fix over-read of ACPI UID from IVRS tableAlexander Monakov
IVRS parsing code always tries to read 255 bytes from memory when retrieving ACPI device path, and makes an assumption that firmware provides a zero-terminated string. Both of those are bugs: the entry is likely to be shorter than 255 bytes, and zero-termination is not guaranteed. With Acer SF314-42 firmware these issues manifest visibly in dmesg: AMD-Vi: ivrs, add hid:AMDI0020, uid:\_SB.FUR0\xf0\xa5, rdevid:160 AMD-Vi: ivrs, add hid:AMDI0020, uid:\_SB.FUR1\xf0\xa5, rdevid:160 AMD-Vi: ivrs, add hid:AMDI0020, uid:\_SB.FUR2\xf0\xa5, rdevid:160 AMD-Vi: ivrs, add hid:AMDI0020, uid:\_SB.FUR3>\x83e\x8d\x9a\xd1... The first three lines show how the code over-reads adjacent table entries into the UID, and in the last line it even reads garbage data beyond the end of the IVRS table itself. Since each entry has the length of the UID (uidl member of ivhd_entry struct), use that for memcpy, and manually add a zero terminator. Avoid zero-filling hid and uid arrays up front, and instead ensure the uid array is always zero-terminated. No change needed for the hid array, as it was already properly zero-terminated. Fixes: 2a0cb4e2d423c ("iommu/amd: Add new map for storing IVHD dev entry type HID") Signed-off-by: Alexander Monakov <amonakov@ispras.ru> Cc: Joerg Roedel <joro@8bytes.org> Cc: iommu@lists.linux-foundation.org Link: https://lore.kernel.org/r/20200511102352.1831-1-amonakov@ispras.ru Signed-off-by: Joerg Roedel <jroedel@suse.de>
2020-05-12clk: ti: clkctrl: convert subclocks to use proper names alsoTero Kristo
Addition of the new internal API to get the clkctrl names missed adding the same conversion in place for the subclocks. This leads into missed parent/child relationships (i.e. orphaned clocks) with mixed node name handling, for example with omap4/omap5 where the l4_per clocks are using new naming, but rest are using old. Fix by converting the subclock registration to pick correct names for the clocks also. Fixes: 6c3090520554 ("clk: ti: clkctrl: Fix hidden dependency to node name") Signed-off-by: Tero Kristo <t-kristo@ti.com> Link: https://lkml.kernel.org/r/20200430083451.8562-1-t-kristo@ti.com Acked-by: Tony Lindgren <tony@atomide.com> Signed-off-by: Stephen Boyd <sboyd@kernel.org>
2020-05-12clk: ti: am33xx: fix RTC clock parentTero Kristo
Right now, trying to use RTC purely with the ti-sysc / clkctrl framework fails to enable the RTC module properly. Based on experimentation, this appears to be because RTC is sourced from the clkdiv32k optional clock. TRM is not very clear on this topic, but fix the RTC to use the proper source clock nevertheless. Reported-by: Tony Lindgren <tony@atomide.com> Signed-off-by: Tero Kristo <t-kristo@ti.com> Link: https://lkml.kernel.org/r/20200424152301.4018-1-t-kristo@ti.com Acked-by: Tony Lindgren <tony@atomide.com> Signed-off-by: Stephen Boyd <sboyd@kernel.org>
2020-05-12clk: ti: clkctrl: Fix Bad of_node_put within clkctrl_get_nameTero Kristo
clkctrl_get_name incorrectly calls of_node_put when it is not really doing of_node_get. This causes a boot time warning later on: [ 0.000000] OF: ERROR: Bad of_node_put() on /ocp/interconnect@4a000000/segmen t@0/target-module@5000/cm_core_aon@0/ipu-cm@500/ipu1-clkctrl@20 Fix by dropping the of_node_put from the function. Reported-by: Naresh Kamboju <naresh.kamboju@linaro.org> Fixes: 6c3090520554 ("clk: ti: clkctrl: Fix hidden dependency to node name") Signed-off-by: Tero Kristo <t-kristo@ti.com> Link: https://lkml.kernel.org/r/20200424124725.9895-1-t-kristo@ti.com Acked-by: Tony Lindgren <tony@atomide.com> Signed-off-by: Stephen Boyd <sboyd@kernel.org>
2020-05-12Merge tag 'v5.7-rockchip-clk-fixes1' of ↵Stephen Boyd
git://git.kernel.org/pub/scm/linux/kernel/git/mmind/linux-rockchip into clk-fixes Pull one Rockchip clk fix from Heiko Stuebner: - Fix for wrongly defines rk3228 aclk_gpu* * tag 'v5.7-rockchip-clk-fixes1' of git://git.kernel.org/pub/scm/linux/kernel/git/mmind/linux-rockchip: clk: rockchip: fix incorrect configuration of rk3228 aclk_gpu* clocks
2020-05-12clk: tegra: Fix initial rate for pll_a on Tegra124Thierry Reding
pll_a_out0 and the I2S clocks are already configured to default to rates corresponding to a 44.1 kHz sampling rate, but the pll_a configuration was set to a default that is not listed in the frequency table, which caused the PLL code to compute an invalid configuration. As a result of this invalid configuration, Jetson TK1 fails to resume from suspend. This used to get papered over because the ASoC driver would force audio clocks to a 44.1 kHz configuration on boot. However, that's not really necessary and was hence removed in commit ff5d18cb04f4 ("ASoC: tegra: Enable audio mclk during tegra_asoc_utils_init()"). Fix the initial rate for pll_a so that it matches the 44.1 kHz entry in the pll_a frequency table. Fixes: ff5d18cb04f4 ("ASoC: tegra: Enable audio mclk during tegra_asoc_utils_init()") Signed-off-by: Thierry Reding <treding@nvidia.com> Link: https://lkml.kernel.org/r/20200505071655.644773-1-thierry.reding@gmail.com Signed-off-by: Stephen Boyd <sboyd@kernel.org>
2020-05-12RDMA/uverbs: Move IB_EVENT_DEVICE_FATAL to destroy_uobjJason Gunthorpe
When multiple async FDs were allowed to exist the idea was for all broadcast events to be delivered to all async FDs, however IB_EVENT_DEVICE_FATAL was missed. Instead of having ib_uverbs_free_hw_resources() special case the global async_fd, have it cause the event during the uobject destruction. Every async fd is now a uobject so simply generate the IB_EVENT_DEVICE_FATAL while destroying the async fd uobject. This ensures every async FD gets a copy of the event. Fixes: d680e88e2013 ("RDMA/core: Add UVERBS_METHOD_ASYNC_EVENT_ALLOC") Link: https://lore.kernel.org/r/20200507063348.98713-3-leon@kernel.org Signed-off-by: Yishai Hadas <yishaih@mellanox.com> Signed-off-by: Leon Romanovsky <leonro@mellanox.com> Signed-off-by: Jason Gunthorpe <jgg@mellanox.com>
2020-05-12RDMA/uverbs: Do not discard the IB_EVENT_DEVICE_FATAL eventJason Gunthorpe
The commit below moved all of the destruction to the disassociate step and cleaned up the event channel during destroy_uobj. However, when ib_uverbs_free_hw_resources() pushes IB_EVENT_DEVICE_FATAL and then immediately goes to destroy all uobjects this causes ib_uverbs_free_event_queue() to discard the queued event if userspace hasn't already read() it. Unlike all other event queues async FD needs to defer the ib_uverbs_free_event_queue() until FD release. This still unregisters the handler from the IB device during disassociation. Fixes: 3e032c0e92aa ("RDMA/core: Make ib_uverbs_async_event_file into a uobject") Link: https://lore.kernel.org/r/20200507063348.98713-2-leon@kernel.org Signed-off-by: Yishai Hadas <yishaih@mellanox.com> Signed-off-by: Leon Romanovsky <leonro@mellanox.com> Signed-off-by: Jason Gunthorpe <jgg@mellanox.com>
2020-05-12net: ethernet: ti: Remove TI_CPTS_MOD workaroundClay McClure
My recent commit b6d49cab44b5 ("net: Make PTP-specific drivers depend on PTP_1588_CLOCK") exposes a missing dependency in defconfigs that select TI_CPTS without selecting PTP_1588_CLOCK, leading to linker errors of the form: drivers/net/ethernet/ti/cpsw.o: in function `cpsw_ndo_stop': cpsw.c:(.text+0x680): undefined reference to `cpts_unregister' ... That's because TI_CPTS_MOD (which is the symbol gating the _compilation_ of cpts.c) now depends on PTP_1588_CLOCK, and so is not enabled in these configurations, but TI_CPTS (which is the symbol gating _calls_ to the cpts functions) _is_ enabled. So we end up compiling calls to functions that don't exist, resulting in the linker errors. This patch fixes build errors and restores previous behavior by: - ensure PTP_1588_CLOCK=y in TI specific configs and CPTS will be built - remove TI_CPTS_MOD and, instead, add dependencies from CPTS in TI_CPSW/TI_KEYSTONE_NETCP/TI_CPSW_SWITCHDEV as below: config TI_CPSW_SWITCHDEV ... depends on TI_CPTS || !TI_CPTS which will ensure proper dependencies PTP_1588_CLOCK -> TI_CPTS -> TI_CPSW/TI_KEYSTONE_NETCP/TI_CPSW_SWITCHDEV and build type selection. Note. For NFS boot + CPTS all of above configs have to be built-in. Cc: Arnd Bergmann <arnd@arndb.de> Cc: Dan Murphy <dmurphy@ti.com> Cc: Tony Lindgren <tony@atomide.com> Fixes: b6d49cab44b5 ("net: Make PTP-specific drivers depend on PTP_1588_CLOCK") Reported-by: kbuild test robot <lkp@intel.com> Signed-off-by: Clay McClure <clay@daemons.net> [grygorii.strashko@ti.com: rewording, add deps cpsw/netcp from cpts, drop IS_REACHABLE] Signed-off-by: Grygorii Strashko <grygorii.strashko@ti.com> Reviewed-by: Arnd Bergmann <arnd@arndb.de> Tested-by: Tony Lindgren <tony@atomide.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2020-05-12ionic: call ionic_port_init after fw-upgradeShannon Nelson
Since the fw has been re-inited, we need to refresh the port information dma address so we can see fresh port information. Let's call ionic_port_init again, and tweak it to allow for a call to simply refresh the existing dma address. Fixes: c672412f6172 ("ionic: remove lifs on fw reset") Signed-off-by: Shannon Nelson <snelson@pensando.io> Signed-off-by: David S. Miller <davem@davemloft.net>
2020-05-12ionic: leave netdev mac alone after fw-upgradeShannon Nelson
When running in a bond setup, or some other potential configurations, the netdev mac may have been changed from the default device mac. Since the userland doesn't know about the changes going on under the covers in a fw-upgrade it doesn't know the re-push the mac filter. The driver needs to leave the netdev mac filter alone when rebuilding after the fw-upgrade. Fixes: c672412f6172 ("ionic: remove lifs on fw reset") Signed-off-by: Shannon Nelson <snelson@pensando.io> Signed-off-by: David S. Miller <davem@davemloft.net>
2020-05-12Merge tag 'gpio-v5.7-2' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-gpio Pull GPIO fixes from Linus Walleij: "Some GPIO fixes for v5.7, slightly overdue. Been learning MMUs and KASan that is why it's late. Bartosz helped me out, luckily! - Fix pin configuration in the PCA953x driver - Ruggedize the watch/unwatch ioctl() - Possible call to a sleeping function when holding a spinlock, avoid this - Fix UML builds with DT overlays - Mask Tegra GPIO IRQs during shutdown()" * tag 'gpio-v5.7-2' of git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-gpio: gpio: tegra: mask GPIO IRQs during IRQ shutdown gpio: of: Build fails if CONFIG_OF_DYNAMIC enabled without CONFIG_OF_GPIO gpiolib: don't call sleeping functions with a spinlock taken gpiolib: improve the robustness of watch/unwatch ioctl() gpio: pca953x: Fix pca953x_gpio_set_config
2020-05-12nvme-pci: dma read memory barrier for completionsKeith Busch
Control dependencies do not guarantee load order across the condition, allowing a CPU to predict and speculate memory reads. Commit 324b494c2862 inlined verifying a new completion with its handling. At least one architecture was observed to access the contents out of order, resulting in the driver using stale data for the completion. Add a dma read barrier before reading the completion queue entry and after the condition its contents depend on to ensure the read order is determinsitic. Reported-by: John Garry <john.garry@huawei.com> Suggested-by: Will Deacon <will@kernel.org> Signed-off-by: Keith Busch <kbusch@kernel.org> Tested-by: John Garry <john.garry@huawei.com> Acked-by: Will Deacon <will@kernel.org> Reviewed-by: Sagi Grimberg <sagi@grimberg.me> Signed-off-by: Christoph Hellwig <hch@lst.de>
2020-05-12RDMA/iw_cxgb4: Fix incorrect function parametersPotnuri Bharat Teja
While reading the TCB field in t4_tcb_get_field32() the wrong mask is passed as a parameter which leads the driver eventually to a kernel panic/app segfault from access to an illegal SRQ index while flushing the SRQ completions during connection teardown. Fixes: 11a27e2121a5 ("iw_cxgb4: complete the cached SRQ buffers") Link: https://lore.kernel.org/r/20200511185608.5202-1-bharat@chelsio.com Signed-off-by: Potnuri Bharat Teja <bharat@chelsio.com> Signed-off-by: Jason Gunthorpe <jgg@mellanox.com>
2020-05-12RDMA/core: Fix double put of resourceMaor Gottlieb
Do not decrease the reference count of resource tracker object twice in the error flow of res_get_common_doit. Fixes: c5dfe0ea6ffa ("RDMA/nldev: Add resource tracker doit callback") Link: https://lore.kernel.org/r/20200507062942.98305-1-leon@kernel.org Signed-off-by: Maor Gottlieb <maorg@mellanox.com> Signed-off-by: Leon Romanovsky <leonro@mellanox.com> Signed-off-by: Jason Gunthorpe <jgg@mellanox.com>
2020-05-12IB/core: Fix potential NULL pointer dereference in pkey cacheJack Morgenstein
The IB core pkey cache is populated by procedure ib_cache_update(). Initially, the pkey cache pointer is NULL. ib_cache_update allocates a buffer and populates it with the device's pkeys, via repeated calls to procedure ib_query_pkey(). If there is a failure in populating the pkey buffer via ib_query_pkey(), ib_cache_update does not replace the old pkey buffer cache with the updated one -- it leaves the old cache as is. Since initially the pkey buffer cache is NULL, when calling ib_cache_update the first time, a failure in ib_query_pkey() will cause the pkey buffer cache pointer to remain NULL. In this situation, any calls subsequent to ib_get_cached_pkey(), ib_find_cached_pkey(), or ib_find_cached_pkey_exact() will try to dereference the NULL pkey cache pointer, causing a kernel panic. Fix this by checking the ib_cache_update() return value. Fixes: 8faea9fd4a39 ("RDMA/cache: Move the cache per-port data into the main ib_port_data") Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Link: https://lore.kernel.org/r/20200507071012.100594-1-leon@kernel.org Signed-off-by: Jack Morgenstein <jackm@dev.mellanox.co.il> Signed-off-by: Leon Romanovsky <leonro@mellanox.com> Signed-off-by: Jason Gunthorpe <jgg@mellanox.com>
2020-05-12IB/hfi1: Fix another case where pq is left on waitlistMike Marciniszyn
The commit noted below fixed a case where a pq is left on the sdma wait list. It however missed another case. user_sdma_send_pkts() has two calls from hfi1_user_sdma_process_request(). If the first one fails as indicated by -EBUSY, the pq will be placed on the waitlist as by design. If the second call then succeeds, the pq is still on the waitlist setting up a race with the interrupt handler if a subsequent request uses a different SDMA engine Fix by deleting the first call. The use of pcount and the intent to send a short burst of packets followed by the larger balance of packets was never correctly implemented, because the two calls always send pcount packets no matter what. A subsequent patch will correct that issue. Fixes: 9a293d1e21a6 ("IB/hfi1: Ensure pq is not left on waitlist") Link: https://lore.kernel.org/r/20200504130917.175613.43231.stgit@awfm-01.aw.intel.com Cc: <stable@vger.kernel.org> Reviewed-by: Kaike Wan <kaike.wan@intel.com> Signed-off-by: Mike Marciniszyn <mike.marciniszyn@intel.com> Signed-off-by: Jason Gunthorpe <jgg@mellanox.com>
2020-05-12IB/i40iw: Remove bogus call to netdev_master_upper_dev_get()Denis V. Lunev
Local variable netdev is not used in these calls. It should be noted, that this change is required to work in bonded mode. Otherwise we would get the following assert: "RTNL: assertion failed at net/core/dev.c (5665)" With the calltrace as follows: dump_stack+0x19/0x1b netdev_master_upper_dev_get+0x61/0x70 i40iw_addr_resolve_neigh+0x1e8/0x220 i40iw_make_cm_node+0x296/0x700 ? i40iw_find_listener.isra.10+0xcc/0x110 i40iw_receive_ilq+0x3d4/0x810 i40iw_puda_poll_completion+0x341/0x420 i40iw_process_ceq+0xa5/0x280 i40iw_ceq_dpc+0x1e/0x40 tasklet_action+0x83/0x140 __do_softirq+0x125/0x2bb call_softirq+0x1c/0x30 do_softirq+0x65/0xa0 irq_exit+0x105/0x110 do_IRQ+0x56/0xf0 common_interrupt+0x16a/0x16a ? cpuidle_enter_state+0x57/0xd0 cpuidle_idle_call+0xde/0x230 arch_cpu_idle+0xe/0xc0 cpu_startup_entry+0x14a/0x1e0 start_secondary+0x1f7/0x270 start_cpu+0x5/0x14 Link: https://lore.kernel.org/r/20200428131511.11049-1-den@openvz.org Signed-off-by: Denis V. Lunev <den@openvz.org> Acked-by: Shiraz Saleem <shiraz.saleem@intel.com> Signed-off-by: Jason Gunthorpe <jgg@mellanox.com>
2020-05-12IB/mlx4: Test return value of calls to ib_get_cached_pkeyJack Morgenstein
In the mlx4_ib_post_send() flow, some functions call ib_get_cached_pkey() without checking its return value. If ib_get_cached_pkey() returns an error code, these functions should return failure. Fixes: 1ffeb2eb8be9 ("IB/mlx4: SR-IOV IB context objects and proxy/tunnel SQP support") Fixes: 225c7b1feef1 ("IB/mlx4: Add a driver Mellanox ConnectX InfiniBand adapters") Fixes: e622f2f4ad21 ("IB: split struct ib_send_wr") Link: https://lore.kernel.org/r/20200426075921.130074-1-leon@kernel.org Signed-off-by: Jack Morgenstein <jackm@dev.mellanox.co.il> Signed-off-by: Leon Romanovsky <leonro@mellanox.com> Signed-off-by: Jason Gunthorpe <jgg@mellanox.com>
2020-05-12RDMA/rxe: Always return ERR_PTR from rxe_create_mmap_info()Sudip Mukherjee
The commit below modified rxe_create_mmap_info() to return ERR_PTR's but didn't update the callers to handle them. Modify rxe_create_mmap_info() to only return ERR_PTR and fix all error checking after rxe_create_mmap_info() is called. Ensure that all other exit paths properly set the error return. Fixes: ff23dfa13457 ("IB: Pass only ib_udata in function prototypes") Link: https://lore.kernel.org/r/20200425233545.17210-1-sudipm.mukherjee@gmail.com Link: https://lore.kernel.org/r/20200511183742.GB225608@mwanda Cc: stable@vger.kernel.org [5.4+] Signed-off-by: Sudip Mukherjee <sudipm.mukherjee@gmail.com> Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by: Jason Gunthorpe <jgg@mellanox.com>
2020-05-12drm/amd/amdgpu: Update update_config() logicLeo (Hanghong) Ma
[Why] For MST case: when update_config is called to disable a stream, this clears the settings for all the streams on that link. We should only clear the settings for the stream that was disabled. [How] Clear the settings after the call to remove display is called. Reviewed-by: Harry Wentland <harry.wentland@amd.com> Reviewed-by: Bhawanpreet Lakha <Bhawanpreet.Lakha@amd.com> Signed-off-by: Leo (Hanghong) Ma <hanghong.ma@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2020-05-12drm/amd/amdgpu: add raven1 part to the gfxoff quirk listTom St Denis
On my raven1 system (rev c6) with VBIOS 113-RAVEN-114 GFXOFF is not stable (resulting in large block tiling noise in some applications). Disabling GFXOFF via the quirk list fixes the problems for me. Signed-off-by: Tom St Denis <tom.stdenis@amd.com> Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Cc: stable@vger.kernel.org
2020-05-12pinctrl: qcom: Add affinity callbacks to msmgpio IRQ chipVenkata Narendra Kumar Gutta
Wakeup capable GPIO IRQs routed via PDC are not being migrated when a CPU is hotplugged. Add affinity callbacks to msmgpio IRQ chip to update the affinity of wakeup capable IRQs. Fixes: e35a6ae0eb3a ("pinctrl/msm: Setup GPIO chip in hierarchy") Signed-off-by: Venkata Narendra Kumar Gutta <vnkgutta@codeaurora.org> [mkshah: updated commit text and minor code fixes] Signed-off-by: Maulik Shah <mkshah@codeaurora.org> Tested-by: Douglas Anderson <dianders@chromium.org> Reviewed-by: Stephen Boyd <swboyd@chromium.org> Link: https://lore.kernel.org/r/1588314617-4556-1-git-send-email-mkshah@codeaurora.org Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2020-05-12efi/earlycon: Fix early printk for wider fontsDave Young
When I play with terminus fonts I noticed the efi early printk does not work because the earlycon code assumes font width is 8. Here add the code to adapt with larger fonts. Tested with all kinds of kernel built-in fonts on my laptop. Also tested with a local draft patch for 14x28 !bold terminus font. Signed-off-by: Dave Young <dyoung@redhat.com> Link: https://lore.kernel.org/r/20200412024927.GA6884@dhcp-128-65.nay.redhat.com Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
2020-05-11Merge tag 'gvt-fixes-2020-05-12' of https://github.com/intel/gvt-linux into ↵Rodrigo Vivi
drm-intel-fixes gvt-fixes-2020-05-12 - Correct transcoder and DPLL initial clock to fix recent guest display probe failure. (Colin) - Fix kernel oops on older guest using aliasing ppgtt. (Zhenyu) Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> From: Zhenyu Wang <zhenyuw@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200512024803.GQ18545@zhen-hp.sh.intel.com
2020-05-11scsi: pm: Balance pm_only counter of request queue during system resumeCan Guo
During system resume, scsi_resume_device() decreases a request queue's pm_only counter if the scsi device was quiesced before. But after that, if the scsi device's RPM status is RPM_SUSPENDED, the pm_only counter is still held (non-zero). Current SCSI resume hook only sets the RPM status of the scsi_device and its request queue to RPM_ACTIVE, but leaves the pm_only counter unchanged. This may make the request queue's pm_only counter remain non-zero after resume hook returns, hence those who are waiting on the mq_freeze_wq would never be woken up. Fix this by calling blk_post_runtime_resume() if a sdev's RPM status was RPM_SUSPENDED. (struct request_queue)0xFFFFFF815B69E938 pm_only = (counter = 2), rpm_status = 0, dev = 0xFFFFFF815B0511A0, ((struct device)0xFFFFFF815B0511A0)).power is_suspended = FALSE, runtime_status = RPM_ACTIVE, (struct scsi_device)0xffffff815b051000 request_queue = 0xFFFFFF815B69E938, sdev_state = SDEV_RUNNING, quiesced_by = 0x0, B::v.f_/task_0xFFFFFF810C246940 -000|__switch_to(prev = 0xFFFFFF810C246940, next = 0xFFFFFF80A49357C0) -001|context_switch(inline) -001|__schedule(?) -002|schedule() -003|blk_queue_enter(q = 0xFFFFFF815B69E938, flags = 0) -004|generic_make_request(?) -005|submit_bio(bio = 0xFFFFFF80A8195B80) Link: https://lore.kernel.org/r/1588740936-28846-1-git-send-email-cang@codeaurora.org Reviewed-by: Bart Van Assche <bvanassche@acm.org> Signed-off-by: Can Guo <cang@codeaurora.org> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
2020-05-11scsi: qla2xxx: Do not log message when reading port speed via sysfsEwan D. Milne
Calling ql_log() inside qla2x00_port_speed_show() is causing messages to be output to the console for no particularly good reason. The sysfs read routine should just return the information to userspace. The only reason to log a message is when the port speed actually changes, and this already occurs elsewhere. Link: https://lore.kernel.org/r/20200504175416.15417-1-emilne@redhat.com Fixes: 4910b524ac9e ("scsi: qla2xxx: Add support for setting port speed") Cc: <stable@vger.kernel.org> # v5.1+ Reviewed-by: Lee Duncan <lduncan@suse.com> Reviewed-by: Laurence Oberman <loberman@redhat.com> Reviewed-by: Himanshu Madhani <himanshu.madhani@oracle.com> Signed-off-by: Ewan D. Milne <emilne@redhat.com> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
2020-05-11net: ipa: use tag process on modem crashAlex Elder
One part of recovering from a modem crash is performing a "tag sequence" of several IPA immediate commands, to clear the hardware pipeline. The sequence ends with a data transfer request on the command endpoint (which is not otherwise done). Unfortunately, attempting to do the data transfer led to a hang, so that request plus two other commands were commented out. The previous commit fixes the bug that was causing that hang. And with that bug fixed we can properly issue the tag sequence when the modem crashes, to return the hardware to a known state. Signed-off-by: Alex Elder <elder@linaro.org> Signed-off-by: David S. Miller <davem@davemloft.net>
2020-05-11net: ipa: set DMA length in gsi_trans_cmd_add()Alex Elder
When a command gets added to a transaction for the AP->command channel we set the DMA address of its scatterlist entry, but not its DMA length. Fix this bug. Signed-off-by: Alex Elder <elder@linaro.org> Signed-off-by: David S. Miller <davem@davemloft.net>
2020-05-11drm/i915: Mark concurrent submissions with a weak-dependencyChris Wilson
We recorded the dependencies for WAIT_FOR_SUBMIT in order that we could correctly perform priority inheritance from the parallel branches to the common trunk. However, for the purpose of timeslicing and reset handling, the dependency is weak -- as we the pair of requests are allowed to run in parallel and not in strict succession. The real significance though is that this allows us to rearrange groups of WAIT_FOR_SUBMIT linked requests along the single engine, and so can resolve user level inter-batch scheduling dependencies from user semaphores. Fixes: c81471f5e95c ("drm/i915: Copy across scheduler behaviour flags across submit fences") Testcase: igt/gem_exec_fence/submit Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Cc: <stable@vger.kernel.org> # v5.6+ Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200507155109.8892-1-chris@chris-wilson.co.uk (cherry picked from commit 6b6cd2ebd8d071e55998e32b648bb8081f7f02bb) Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2020-05-11drm/i915: Propagate error from completed fencesChris Wilson
We need to preserve fatal errors from fences that are being terminated as we hook them up. Fixes: ef4688497512 ("drm/i915: Propagate fence errors") Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Cc: Matthew Auld <matthew.auld@intel.com> Reviewed-by: Matthew Auld <matthew.auld@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200506162136.3325-1-chris@chris-wilson.co.uk (cherry picked from commit 24fe5f2ab2478053d50a3bc629ada895903a5cbc) Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2020-05-11vdpasim: remove unused variable 'ret'YueHaibing
drivers/vdpa/vdpa_sim/vdpa_sim.c:92:6: warning: variable ‘ret’ set but not used [-Wunused-but-set-variable] Signed-off-by: YueHaibing <yuehaibing@huawei.com> Link: https://lore.kernel.org/r/20200410115422.42308-1-yuehaibing@huawei.com Signed-off-by: Michael S. Tsirkin <mst@redhat.com> Acked-by: Jason Wang <jasowang@redhat.com>
2020-05-11drm/i915/gvt: Fix kernel oops for 3-level ppgtt guestZhenyu Wang
As i915 won't allocate extra PDP for current default PML4 table, so for 3-level ppgtt guest, we would hit kernel pointer access failure on extra PDP pointers. So this trys to bypass that now. It won't impact real shadow PPGTT setup, so guest context still works. This is verified on 4.15 guest kernel with i915.enable_ppgtt=1 to force on old aliasing ppgtt behavior. Fixes: 4f15665ccbba ("drm/i915: Add ppgtt to GVT GEM context") Reviewed-by: Xiong Zhang <xiong.y.zhang@intel.com> Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20200506095918.124913-1-zhenyuw@linux.intel.com
2020-05-11mmc: sdhci-acpi: Add SDHCI_QUIRK2_BROKEN_64_BIT_DMA for AMDI0040Raul E Rangel
The AMD eMMC 5.0 controller does not support 64 bit DMA. Fixes: 34597a3f60b1 ("mmc: sdhci-acpi: Add support for ACPI HID of AMD Controller with HS400") Signed-off-by: Raul E Rangel <rrangel@chromium.org> Link: https://marc.info/?l=linux-mmc&m=158879884514552&w=2 Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Acked-by: Adrian Hunter <adrian.hunter@intel.com> Link: https://lore.kernel.org/r/20200508165344.1.Id5bb8b1ae7ea576f26f9d91c761df7ccffbf58c5@changeid Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2020-05-11ACPI: EC: PM: Avoid premature returns from acpi_s2idle_wake()Rafael J. Wysocki
If the EC GPE status is not set after checking all of the other GPEs, acpi_s2idle_wake() returns 'false', to indicate that the SCI event that has just triggered is not a system wakeup one, but it does that without canceling the pending wakeup and re-arming the SCI for system wakeup which is a mistake, because it may cause s2idle_loop() to busy spin until the next valid wakeup event. [If that happens, the first spurious wakeup is still pending after acpi_s2idle_wake() has returned, so s2idle_enter() does nothing, acpi_s2idle_wake() is called again and it sees that the SCI has triggered, but no GPEs are active, so 'false' is returned again, and so on.] Fix that by moving all of the GPE checking logic from acpi_s2idle_wake() to acpi_ec_dispatch_gpe() and making the latter return 'true' only if a non-EC GPE has triggered and 'false' otherwise, which will cause acpi_s2idle_wake() to cancel the pending SCI wakeup and re-arm the SCI for system wakeup regardless of the EC GPE status. This also addresses a lockup observed on an Elitegroup EF20EA laptop after attempting to wake it up from suspend-to-idle by a key press. Fixes: d5406284ff80 ("ACPI: PM: s2idle: Refine active GPEs check") Link: https://bugzilla.kernel.org/show_bug.cgi?id=207603 Reported-by: Todd Brandt <todd.e.brandt@linux.intel.com> Fixes: fdde0ff8590b ("ACPI: PM: s2idle: Prevent spurious SCIs from waking up the system") Link: https://lore.kernel.org/linux-acpi/CAB4CAwdqo7=MvyG_PE+PGVfeA17AHF5i5JucgaKqqMX6mjArbQ@mail.gmail.com/ Reported-by: Chris Chiu <chiu@endlessm.com> Tested-by: Chris Chiu <chiu@endlessm.com> Cc: 5.4+ <stable@vger.kernel.org> # 5.4+ Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2020-05-10hinic: fix a bug of ndo_stopLuo bin
if some function in ndo_stop interface returns failure because of hardware fault, must go on excuting rest steps rather than return failure directly, otherwise will cause memory leak.And bump the timeout for SET_FUNC_STATE to ensure that cmd won't return failure when hw is busy. Otherwise hw may stomp host memory if we free memory regardless of the return value of SET_FUNC_STATE. Fixes: 51ba902a16e6 ("net-next/hinic: Initialize hw interface") Signed-off-by: Luo bin <luobin9@huawei.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2020-05-10Merge tag 'iommu-fixes-v5.7-rc4' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/joro/iommu Pull iommu fixes from Joerg Roedel: - Race condition fixes for the AMD IOMMU driver. These are five patches fixing two race conditions around increase_address_space(). The first race condition was around the non-atomic update of the domain page-table root pointer and the variable containing the page-table depth (called mode). This is fixed now be merging page-table root and mode into one 64-bit field which is read/written atomically. The second race condition was around updating the page-table root pointer and making it public before the hardware caches were flushed. This could cause addresses to be mapped and returned to drivers which are not reachable by IOMMU hardware yet, causing IO page-faults. This is fixed too by adding the necessary flushes before a new page-table root is published. Related to the race condition fixes these patches also add a missing domain_flush_complete() barrier to update_domain() and a fix to bail out of the loop which tries to increase the address space when the call to increase_address_space() fails. Qian was able to trigger the race conditions under high load and memory pressure within a few days of testing. He confirmed that he has seen no issues anymore with the fixes included here. - Fix for a list-handling bug in the VirtIO IOMMU driver. * tag 'iommu-fixes-v5.7-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/joro/iommu: iommu/virtio: Reverse arguments to list_add iommu/amd: Do not flush Device Table in iommu_map_page() iommu/amd: Update Device Table in increase_address_space() iommu/amd: Call domain_flush_complete() in update_domain() iommu/amd: Do not loop forever when trying to increase address space iommu/amd: Fix race in increase_address_space()/fetch_pte()
generated by cgit (git 2.34.1) at 2025-09-11 16:44:36 +0000