summaryrefslogtreecommitdiff
path: root/drivers
AgeCommit message (Collapse)AuthorFilesLines
2022-10-05drm/i915/gem: Really move i915_gem_context.link under ref protectionChris Wilson1-4/+4
commit d119888b09bd567e07c6b93a07f175df88857e02 upstream. i915_perf assumes that it can use the i915_gem_context reference to protect its i915->gem.contexts.list iteration. However, this requires that we do not remove the context from the list until after we drop the final reference and release the struct. If, as currently, we remove the context from the list during context_close(), the link.next pointer may be poisoned while we are holding the context reference and cause a GPF: [ 4070.573157] i915 0000:00:02.0: [drm:i915_perf_open_ioctl [i915]] filtering on ctx_id=0x1fffff ctx_id_mask=0x1fffff [ 4070.574881] general protection fault, probably for non-canonical address 0xdead000000000100: 0000 [#1] PREEMPT SMP [ 4070.574897] CPU: 1 PID: 284392 Comm: amd_performance Tainted: G E 5.17.9 #180 [ 4070.574903] Hardware name: Intel Corporation NUC7i5BNK/NUC7i5BNB, BIOS BNKBL357.86A.0052.2017.0918.1346 09/18/2017 [ 4070.574907] RIP: 0010:oa_configure_all_contexts.isra.0+0x222/0x350 [i915] [ 4070.574982] Code: 08 e8 32 6e 10 e1 4d 8b 6d 50 b8 ff ff ff ff 49 83 ed 50 f0 41 0f c1 04 24 83 f8 01 0f 84 e3 00 00 00 85 c0 0f 8e fa 00 00 00 <49> 8b 45 50 48 8d 70 b0 49 8d 45 50 48 39 44 24 10 0f 85 34 fe ff [ 4070.574990] RSP: 0018:ffffc90002077b78 EFLAGS: 00010202 [ 4070.574995] RAX: 0000000000000002 RBX: 0000000000000002 RCX: 0000000000000000 [ 4070.575000] RDX: 0000000000000001 RSI: ffffc90002077b20 RDI: ffff88810ddc7c68 [ 4070.575004] RBP: 0000000000000001 R08: ffff888103242648 R09: fffffffffffffffc [ 4070.575008] R10: ffffffff82c50bc0 R11: 0000000000025c80 R12: ffff888101bf1860 [ 4070.575012] R13: dead0000000000b0 R14: ffffc90002077c04 R15: ffff88810be5cabc [ 4070.575016] FS: 00007f1ed50c0780(0000) GS:ffff88885ec80000(0000) knlGS:0000000000000000 [ 4070.575021] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 4070.575025] CR2: 00007f1ed5590280 CR3: 000000010ef6f005 CR4: 00000000003706e0 [ 4070.575029] Call Trace: [ 4070.575033] <TASK> [ 4070.575037] lrc_configure_all_contexts+0x13e/0x150 [i915] [ 4070.575103] gen8_enable_metric_set+0x4d/0x90 [i915] [ 4070.575164] i915_perf_open_ioctl+0xbc0/0x1500 [i915] [ 4070.575224] ? asm_common_interrupt+0x1e/0x40 [ 4070.575232] ? i915_oa_init_reg_state+0x110/0x110 [i915] [ 4070.575290] drm_ioctl_kernel+0x85/0x110 [ 4070.575296] ? update_load_avg+0x5f/0x5e0 [ 4070.575302] drm_ioctl+0x1d3/0x370 [ 4070.575307] ? i915_oa_init_reg_state+0x110/0x110 [i915] [ 4070.575382] ? gen8_gt_irq_handler+0x46/0x130 [i915] [ 4070.575445] __x64_sys_ioctl+0x3c4/0x8d0 [ 4070.575451] ? __do_softirq+0xaa/0x1d2 [ 4070.575456] do_syscall_64+0x35/0x80 [ 4070.575461] entry_SYSCALL_64_after_hwframe+0x44/0xae [ 4070.575467] RIP: 0033:0x7f1ed5c10397 [ 4070.575471] Code: 3c 1c e8 1c ff ff ff 85 c0 79 87 49 c7 c4 ff ff ff ff 5b 5d 4c 89 e0 41 5c c3 66 0f 1f 84 00 00 00 00 00 b8 10 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d a9 da 0d 00 f7 d8 64 89 01 48 [ 4070.575478] RSP: 002b:00007ffd65c8d7a8 EFLAGS: 00000246 ORIG_RAX: 0000000000000010 [ 4070.575484] RAX: ffffffffffffffda RBX: 0000000000000006 RCX: 00007f1ed5c10397 [ 4070.575488] RDX: 00007ffd65c8d7c0 RSI: 0000000040106476 RDI: 0000000000000006 [ 4070.575492] RBP: 00005620972f9c60 R08: 000000000000000a R09: 0000000000000005 [ 4070.575496] R10: 000000000000000d R11: 0000000000000246 R12: 000000000000000a [ 4070.575500] R13: 000000000000000d R14: 0000000000000000 R15: 00007ffd65c8d7c0 [ 4070.575505] </TASK> [ 4070.575507] Modules linked in: nls_ascii(E) nls_cp437(E) vfat(E) fat(E) i915(E) x86_pkg_temp_thermal(E) intel_powerclamp(E) crct10dif_pclmul(E) crc32_pclmul(E) crc32c_intel(E) aesni_intel(E) crypto_simd(E) intel_gtt(E) cryptd(E) ttm(E) rapl(E) intel_cstate(E) drm_kms_helper(E) cfbfillrect(E) syscopyarea(E) cfbimgblt(E) intel_uncore(E) sysfillrect(E) mei_me(E) sysimgblt(E) i2c_i801(E) fb_sys_fops(E) mei(E) intel_pch_thermal(E) i2c_smbus(E) cfbcopyarea(E) video(E) button(E) efivarfs(E) autofs4(E) [ 4070.575549] ---[ end trace 0000000000000000 ]--- v3: fix incorrect syntax of spin_lock() replacing spin_lock_irqsave() v2: irqsave not required in a worker, neither conversion to irq safe elsewhere (Tvrtko), - perf: it's safe to call gen8_configure_context() even if context has been closed, no need to check, - drop unrelated cleanup (Andi, Tvrtko) Reported-by: Mark Janes <mark.janes@intel.com> Closes: https://gitlab.freedesktop.org/drm/intel/issues/6222 References: a4e7ccdac38e ("drm/i915: Move context management under GEM") Fixes: f8246cf4d9a9 ("drm/i915/gem: Drop free_work for GEM contexts") Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Andi Shyti <andi.shyti@linux.intel.com> Signed-off-by: Janusz Krzysztofik <janusz.krzysztofik@linux.intel.com> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Cc: <stable@vger.kernel.org> # v5.12+ Signed-off-by: Andi Shyti <andi.shyti@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220916092403.201355-3-janusz.krzysztofik@linux.intel.com (cherry picked from commit ad3aa7c31efa5a09b0dba42e66cfdf77e0db7dc2) Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> [janusz: backport] Signed-off-by: Janusz Krzysztofik <janusz.krzysztofik@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-10-05clk: iproc: Do not rely on node name for correct PLL setupFlorian Fainelli1-4/+8
[ Upstream commit 1b24a132eba7a1c19475ba2510ec1c00af3ff914 ] After commit 31fd9b79dc58 ("ARM: dts: BCM5301X: update CRU block description") a warning from clk-iproc-pll.c was generated due to a duplicate PLL name as well as the console stopped working. Upon closer inspection it became clear that iproc_pll_clk_setup() used the Device Tree node unit name as an unique identifier as well as a parent name to parent all clocks under the PLL. BCM5301X was the first platform on which that got noticed because of the DT node unit name renaming but the same assumptions hold true for any user of the iproc_pll_clk_setup() function. The first 'clock-output-names' property is always guaranteed to be unique as well as providing the actual desired PLL clock name, so we utilize that to register the PLL and as a parent name of all children clock. Fixes: 5fe225c105fd ("clk: iproc: add initial common clock support") Signed-off-by: Florian Fainelli <f.fainelli@gmail.com> Acked-by: Rafał Miłecki <rafal@milecki.pl> Link: https://lore.kernel.org/r/20220905161504.1526-1-f.fainelli@gmail.com Signed-off-by: Stephen Boyd <sboyd@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2022-10-05clk: imx: imx6sx: remove the SET_RATE_PARENT flag for QSPI clocksHan Xu1-2/+2
[ Upstream commit b1ff1bfe81e763420afd5f3f25f0b3cbfd97055c ] There is no dedicate parent clock for QSPI so SET_RATE_PARENT flag should not be used. For instance, the default parent clock for QSPI is pll2_bus, which is also the parent clock for quite a few modules, such as MMDC, once GPMI NAND set clock rate for EDO5 mode can cause system hang due to pll2_bus rate changed. Fixes: f1541e15e38e ("clk: imx6sx: Switch to clk_hw based API") Signed-off-by: Han Xu <han.xu@nxp.com> Link: https://lore.kernel.org/r/20220915150959.3646702-1-han.xu@nxp.com Tested-by: Fabio Estevam <festevam@denx.de> Reviewed-by: Abel Vesa <abel.vesa@linaro.org> Signed-off-by: Stephen Boyd <sboyd@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2022-10-05vdpa/ifcvf: fix the calculation of queuepairAngus Chen1-2/+2
[ Upstream commit db5db1a00d0816207be3a0166fcb4f523eaf3b52 ] The q_pair_id to address a queue pair in the lm bar should be calculated by queue_id / 2 rather than queue_id / nr_vring. Fixes: 2ddae773c93b ("vDPA/ifcvf: detect and use the onboard number of queues directly") Signed-off-by: Angus Chen <angus.chen@jaguarmicro.com> Reviewed-by: Jason Wang <jasowang@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Acked-by: Zhu Lingshan <lingshan.zhu@intel.com> Message-Id: <20220923091013.191-1-angus.chen@jaguarmicro.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2022-10-05net: phy: Don't WARN for PHY_UP state in mdio_bus_phy_resume()Lukas Wunner1-4/+6
[ Upstream commit ea64cdfad124922c931633e39287c5a31a9b14a1 ] Commit 744d23c71af3 ("net: phy: Warn about incorrect mdio_bus_phy_resume() state") introduced a WARN() on resume from system sleep if a PHY is not in PHY_HALTED state. Commit 6dbe852c379f ("net: phy: Don't WARN for PHY_READY state in mdio_bus_phy_resume()") added an exemption for PHY_READY state from the WARN(). It turns out PHY_UP state needs to be exempted as well because the following may happen on suspend: mdio_bus_phy_suspend() phy_stop_machine() phydev->state = PHY_UP # if (phydev->state >= PHY_UP) Fixes: 744d23c71af3 ("net: phy: Warn about incorrect mdio_bus_phy_resume() state") Reported-by: Marek Szyprowski <m.szyprowski@samsung.com> Tested-by: Marek Szyprowski <m.szyprowski@samsung.com> Link: https://lore.kernel.org/netdev/2b1a1588-505e-dff3-301d-bfc1fb14d685@samsung.com/ Signed-off-by: Lukas Wunner <lukas@wunner.de> Acked-by: Florian Fainelli <f.fainelli@gmail.com> Cc: Xiaolei Wang <xiaolei.wang@windriver.com> Link: https://lore.kernel.org/r/8128fdb51eeebc9efbf3776a4097363a1317aaf1.1663905575.git.lukas@wunner.de Signed-off-by: Paolo Abeni <pabeni@redhat.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2022-10-05net: stmmac: power up/down serdes in stmmac_open/releaseJunxiao Chang1-10/+13
[ Upstream commit 49725ffc15fc4e9fae68c55b691fd25168cbe5c1 ] This commit fixes DMA engine reset timeout issue in suspend/resume with ADLink I-Pi SMARC Plus board which dmesg shows: ... [ 54.678271] PM: suspend exit [ 54.754066] intel-eth-pci 0000:00:1d.2 enp0s29f2: PHY [stmmac-3:01] driver [Maxlinear Ethernet GPY215B] (irq=POLL) [ 54.755808] intel-eth-pci 0000:00:1d.2 enp0s29f2: Register MEM_TYPE_PAGE_POOL RxQ-0 ... [ 54.780482] intel-eth-pci 0000:00:1d.2 enp0s29f2: Register MEM_TYPE_PAGE_POOL RxQ-7 [ 55.784098] intel-eth-pci 0000:00:1d.2: Failed to reset the dma [ 55.784111] intel-eth-pci 0000:00:1d.2 enp0s29f2: stmmac_hw_setup: DMA engine initialization failed [ 55.784115] intel-eth-pci 0000:00:1d.2 enp0s29f2: stmmac_open: Hw setup failed ... The issue is related with serdes which impacts clock. There is serdes in ADLink I-Pi SMARC board ethernet controller. Please refer to commit b9663b7ca6ff78 ("net: stmmac: Enable SERDES power up/down sequence") for detial. When issue is reproduced, DMA engine clock is not ready because serdes is not powered up. To reproduce DMA engine reset timeout issue with hardware which has serdes in GBE controller, install Ubuntu. In Ubuntu GUI, click "Power Off/Log Out" -> "Suspend" menu, it disables network interface, then goes to sleep mode. When it wakes up, it enables network interface again. Stmmac driver is called in this way: 1. stmmac_release: Stop network interface. In this function, it disables DMA engine and network interface; 2. stmmac_suspend: It is called in kernel suspend flow. But because network interface has been disabled(netif_running(ndev) is false), it does nothing and returns directly; 3. System goes into S3 or S0ix state. Some time later, system is waken up by keyboard or mouse; 4. stmmac_resume: It does nothing because network interface has been disabled; 5. stmmac_open: It is called to enable network interace again. DMA engine is initialized in this API, but serdes is not power on so there will be DMA engine reset timeout issue. Similarly, serdes powerdown should be added in stmmac_release. Network interface might be disabled by cmd "ifconfig eth0 down", DMA engine, phy and mac have been disabled in ndo_stop callback, serdes should be powered down as well. It doesn't make sense that serdes is on while other components have been turned off. If ethernet interface is in enabled state(netif_running(ndev) is true) before suspend/resume, the issue couldn't be reproduced because serdes could be powered up in stmmac_resume. Because serdes_powerup is added in stmmac_open, it doesn't need to be called in probe function. Fixes: b9663b7ca6ff78 ("net: stmmac: Enable SERDES power up/down sequence") Signed-off-by: Junxiao Chang <junxiao.chang@intel.com> Reviewed-by: Voon Weifeng <weifeng.voon@intel.com> Tested-by: Jimmy JS Chen <jimmyjs.chen@adlinktech.com> Tested-by: Looi, Hong Aun <hong.aun.looi@intel.com> Link: https://lore.kernel.org/r/20220923050448.1220250-1-junxiao.chang@intel.com Signed-off-by: Paolo Abeni <pabeni@redhat.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2022-10-05nvme: Fix IOC_PR_CLEAR and IOC_PR_RELEASE ioctls for nvme devicesMichael Kelley1-3/+3
[ Upstream commit c292a337d0e45a292c301e3cd51c35aa0ae91e95 ] The IOC_PR_CLEAR and IOC_PR_RELEASE ioctls are non-functional on NVMe devices because the nvme_pr_clear() and nvme_pr_release() functions set the IEKEY field incorrectly. The IEKEY field should be set only when the key is zero (i.e, not specified). The current code does it backwards. Furthermore, the NVMe spec describes the persistent reservation "clear" function as an option on the reservation release command. The current implementation of nvme_pr_clear() erroneously uses the reservation register command. Fix these errors. Note that NVMe version 1.3 and later specify that setting the IEKEY field will return an error of Invalid Field in Command. The fix will set IEKEY when the key is zero, which is appropriate as these ioctls consider a zero key to be "unspecified", and the intention of the spec change is to require a valid key. Tested on a version 1.4 PCI NVMe device in an Azure VM. Fixes: 1673f1f08c88 ("nvme: move block_device_operations and ns/ctrl freeing to common code") Fixes: 1d277a637a71 ("NVMe: Add persistent reservation ops") Signed-off-by: Michael Kelley <mikelley@microsoft.com> Signed-off-by: Christoph Hellwig <hch@lst.de> Signed-off-by: Sasha Levin <sashal@kernel.org>
2022-10-05net/mlxbf_gige: Fix an IS_ERR() vs NULL bug in mlxbf_gige_mdio_probePeng Wu1-2/+2
[ Upstream commit 4774db8dfc6a2e6649920ebb2fc8e2f062c2080d ] The devm_ioremap() function returns NULL on error, it doesn't return error pointers. Fixes: 3a1a274e933f ("mlxbf_gige: compute MDIO period based on i1clk") Signed-off-by: Peng Wu <wupeng58@huawei.com> Link: https://lore.kernel.org/r/20220923023640.116057-1-wupeng58@huawei.com Signed-off-by: Jakub Kicinski <kuba@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2022-10-05cxgb4: fix missing unlock on ETHOFLD desc collect fail pathRafael Mendonca1-9/+19
[ Upstream commit c635ebe8d911a93bd849a9419b01a58783de76f1 ] The label passed to the QDESC_GET for the ETHOFLD TXQ, RXQ, and FLQ, is the 'out' one, which skips the 'out_unlock' label, and thus doesn't unlock the 'uld_mutex' before returning. Additionally, since commit 5148e5950c67 ("cxgb4: add EOTID tracking and software context dump"), the access to these ETHOFLD hardware queues should be protected by the 'mqprio_mutex' instead. Fixes: 2d0cb84dd973 ("cxgb4: add ETHOFLD hardware queue support") Fixes: 5148e5950c67 ("cxgb4: add EOTID tracking and software context dump") Signed-off-by: Rafael Mendonca <rafaelmendsr@gmail.com> Reviewed-by: Rahul Lakkireddy <rahul.lakkireddy@chelsio.com> Link: https://lore.kernel.org/r/20220922175109.764898-1-rafaelmendsr@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2022-10-05usbnet: Fix memory leak in usbnet_disconnect()Peilin Ye1-1/+6
[ Upstream commit a43206156263fbaf1f2b7f96257441f331e91bb7 ] Currently usbnet_disconnect() unanchors and frees all deferred URBs using usb_scuttle_anchored_urbs(), which does not free urb->context, causing a memory leak as reported by syzbot. Use a usb_get_from_anchor() while loop instead, similar to what we did in commit 19cfe912c37b ("Bluetooth: btusb: Fix memory leak in play_deferred"). Also free urb->sg. Reported-and-tested-by: syzbot+dcd3e13cf4472f2e0ba1@syzkaller.appspotmail.com Fixes: 69ee472f2706 ("usbnet & cdc-ether: Autosuspend for online devices") Fixes: 638c5115a794 ("USBNET: support DMA SG") Signed-off-by: Peilin Ye <peilin.ye@bytedance.com> Link: https://lore.kernel.org/r/20220923042551.2745-1-yepeilin.cs@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2022-10-05gpio: mvebu: Fix check for pwm support on non-A8K platformsPali Rohár1-9/+6
[ Upstream commit 4335417da2b8d6d9b2d4411b5f9e248e5bb2d380 ] pwm support incompatible with Armada 80x0/70x0 API is not only in Armada 370, but also in Armada XP, 38x and 39x. So basically every non-A8K platform. Fix check for pwm support appropriately. Fixes: 85b7d8abfec7 ("gpio: mvebu: add pwm support for Armada 8K/7K") Signed-off-by: Pali Rohár <pali@kernel.org> Signed-off-by: Bartosz Golaszewski <brgl@bgdev.pl> Signed-off-by: Sasha Levin <sashal@kernel.org>
2022-10-05Input: melfas_mip4 - fix return value check in mip4_probe()Yang Yingliang1-1/+1
[ Upstream commit a54dc27bd25f20ee3ea2009584b3166d25178243 ] devm_gpiod_get_optional() may return ERR_PTR(-EPROBE_DEFER), add a minus sign to fix it. Fixes: 6ccb1d8f78bd ("Input: add MELFAS MIP4 Touchscreen driver") Signed-off-by: Yang Yingliang <yangyingliang@huawei.com> Link: https://lore.kernel.org/r/20220924030715.1653538-1-yangyingliang@huawei.com Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2022-10-05Revert "drm: bridge: analogix/dp: add panel prepare/unprepare in ↵Brian Norris1-13/+0
suspend/resume time" [ Upstream commit cc62d98bd56d45de4531844ca23913a15136c05b ] This reverts commit 211f276ed3d96e964d2d1106a198c7f4a4b3f4c0. For quite some time, core DRM helpers already ensure that any relevant connectors/CRTCs/etc. are disabled, as well as their associated components (e.g., bridges) when suspending the system. Thus, analogix_dp_bridge_{enable,disable}() already get called, which in turn call drm_panel_{prepare,unprepare}(). This makes these drm_panel_*() calls redundant. Besides redundancy, there are a few problems with this handling: (1) drm_panel_{prepare,unprepare}() are *not* reference-counted APIs and are not in general designed to be handled by multiple callers -- although some panel drivers have a coarse 'prepared' flag that mitigates some damage, at least. So at a minimum this is redundant and confusing, but in some cases, this could be actively harmful. (2) The error-handling is a bit non-standard. We ignored errors in suspend(), but handled errors in resume(). And recently, people noticed that the clk handling is unbalanced in error paths, and getting *that* right is not actually trivial, given the current way errors are mostly ignored. (3) In the particular way analogix_dp_{suspend,resume}() get used (e.g., in rockchip_dp_*(), as a late/early callback), we don't necessarily have a proper PM relationship between the DP/bridge device and the panel device. So while the DP bridge gets resumed, the panel's parent device (e.g., platform_device) may still be suspended, and so any prepare() calls may fail. So remove the superfluous, possibly-harmful suspend()/resume() handling of panel state. Fixes: 211f276ed3d9 ("drm: bridge: analogix/dp: add panel prepare/unprepare in suspend/resume time") Link: https://lore.kernel.org/all/Yv2CPBD3Picg%2FgVe@google.com/ Signed-off-by: Brian Norris <briannorris@chromium.org> Reviewed-by: Douglas Anderson <dianders@chromium.org> Signed-off-by: Douglas Anderson <dianders@chromium.org> Link: https://patchwork.freedesktop.org/patch/msgid/20220822180729.1.I8ac5abe3a4c1c6fd5c061686c6e883c22f69022c@changeid Signed-off-by: Sasha Levin <sashal@kernel.org>
2022-10-05drm/bridge: lt8912b: fix corrupted image outputFrancesco Dolcini1-1/+1
[ Upstream commit 051ad2788d35ca07aec8402542e5d38429f2426a ] Correct I2C address for the register list in lt8912_write_lvds_config(), these registers are on the first I2C address (0x48), the current function is just writing garbage to the wrong registers and this creates multiple issues (artifacts and output completely corrupted) on some HDMI displays. Correct I2C address comes from Lontium documentation and it is the one used on other out-of-tree LT8912B drivers [1]. [1] https://github.com/boundarydevices/linux/blob/boundary-imx_5.10.x_2.0.0/drivers/video/lt8912.c#L296 Fixes: 30e2ae943c26 ("drm/bridge: Introduce LT8912B DSI to HDMI bridge") Signed-off-by: Francesco Dolcini <francesco.dolcini@toradex.com> Signed-off-by: Philippe Schenker <philippe.schenker@toradex.com> Acked-by: Adrien Grassein <adrien.grassein@gmail.com> Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org> Link: https://patchwork.freedesktop.org/patch/msgid/20220922124306.34729-4-dev@pschenker.ch Signed-off-by: Sasha Levin <sashal@kernel.org>
2022-10-05drm/bridge: lt8912b: set hdmi or dvi modePhilippe Schenker1-0/+2
[ Upstream commit 6dd1de12e1243f2013e4fabf31e99e63b1a860d0 ] The Lontium LT8912 does have a setting for DVI or HDMI. This patch reads from EDID what the display needs and sets it accordingly. Fixes: 30e2ae943c26 ("drm/bridge: Introduce LT8912B DSI to HDMI bridge") Signed-off-by: Philippe Schenker <philippe.schenker@toradex.com> Acked-by: Adrien Grassein <adrien.grassein@gmail.com> Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org> Link: https://patchwork.freedesktop.org/patch/msgid/20220922124306.34729-3-dev@pschenker.ch Signed-off-by: Sasha Levin <sashal@kernel.org>
2022-10-05drm/bridge: lt8912b: add vsync hsyncPhilippe Schenker1-1/+8
[ Upstream commit da73a94fa282f78d485bd0aab36c8ac15b6f792c ] Currently the bridge driver does not take care whether or not the display needs positive/negative vertical/horizontal syncs. Pass these two flags to the bridge from the EDID that was read out from the display. Fixes: 30e2ae943c26 ("drm/bridge: Introduce LT8912B DSI to HDMI bridge") Signed-off-by: Philippe Schenker <philippe.schenker@toradex.com> Acked-by: Adrien Grassein <adrien.grassein@gmail.com> Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org> Link: https://patchwork.freedesktop.org/patch/msgid/20220922124306.34729-2-dev@pschenker.ch Signed-off-by: Sasha Levin <sashal@kernel.org>
2022-10-05soc: sunxi: sram: Fix debugfs info for A64 SRAM CSamuel Holland1-2/+2
[ Upstream commit e3c95edb1bd8b9c2cb0caa6ae382fc8080f6a0ed ] The labels were backward with respect to the register values. The SRAM is mapped to the CPU when the register value is 1. Fixes: 5e4fb6429761 ("drivers: soc: sunxi: add support for A64 and its SRAM C") Acked-by: Jernej Skrabec <jernej.skrabec@gmail.com> Signed-off-by: Samuel Holland <samuel@sholland.org> Signed-off-by: Jernej Skrabec <jernej.skrabec@gmail.com> Link: https://lore.kernel.org/r/20220815041248.53268-7-samuel@sholland.org Signed-off-by: Sasha Levin <sashal@kernel.org>
2022-10-05soc: sunxi: sram: Fix probe function ordering issuesSamuel Holland1-8/+5
[ Upstream commit 49fad91a7b8941979c3e9a35f9894ac45bc5d3d6 ] Errors from debugfs are intended to be non-fatal, and should not prevent the driver from probing. Since debugfs file creation is treated as infallible, move it below the parts of the probe function that can fail. This prevents an error elsewhere in the probe function from causing the file to leak. Do the same for the call to of_platform_populate(). Finally, checkpatch suggests an octal literal for the file permissions. Fixes: 4af34b572a85 ("drivers: soc: sunxi: Introduce SoC driver to map SRAMs") Fixes: 5828729bebbb ("soc: sunxi: export a regmap for EMAC clock reg on A64") Reviewed-by: Jernej Skrabec <jernej.skrabec@gmail.com> Signed-off-by: Samuel Holland <samuel@sholland.org> Tested-by: Heiko Stuebner <heiko@sntech.de> Signed-off-by: Jernej Skrabec <jernej.skrabec@gmail.com> Link: https://lore.kernel.org/r/20220815041248.53268-6-samuel@sholland.org Signed-off-by: Sasha Levin <sashal@kernel.org>
2022-10-05soc: sunxi_sram: Make use of the helper function ↵Cai Huoqing1-3/+1
devm_platform_ioremap_resource() [ Upstream commit 1f3753a5f042fea6539986f9caf2552877527d8a ] Use the devm_platform_ioremap_resource() helper instead of calling platform_get_resource() and devm_ioremap_resource() separately Signed-off-by: Cai Huoqing <caihuoqing@baidu.com> Signed-off-by: Maxime Ripard <maxime@cerno.tech> Link: https://lore.kernel.org/r/20210908071716.772-1-caihuoqing@baidu.com Stable-dep-of: 49fad91a7b89 ("soc: sunxi: sram: Fix probe function ordering issues") Signed-off-by: Sasha Levin <sashal@kernel.org>
2022-10-05soc: sunxi: sram: Prevent the driver from being unboundSamuel Holland1-3/+2
[ Upstream commit 90e10a1fcd9b24b4ba8c0d35136127473dcd829e ] This driver exports a regmap tied to the platform device (as opposed to a syscon, which exports a regmap tied to the OF node). Because of this, the driver can never be unbound, as that would destroy the regmap. Use builtin_platform_driver_probe() to enforce this limitation. Fixes: 5828729bebbb ("soc: sunxi: export a regmap for EMAC clock reg on A64") Reviewed-by: Jernej Skrabec <jernej.skrabec@gmail.com> Signed-off-by: Samuel Holland <samuel@sholland.org> Reviewed-by: Heiko Stuebner <heiko@sntech.de> Tested-by: Heiko Stuebner <heiko@sntech.de> Signed-off-by: Jernej Skrabec <jernej.skrabec@gmail.com> Link: https://lore.kernel.org/r/20220815041248.53268-5-samuel@sholland.org Signed-off-by: Sasha Levin <sashal@kernel.org>
2022-10-05soc: sunxi: sram: Actually claim SRAM regionsSamuel Holland1-0/+1
[ Upstream commit fd362baad2e659ef0fb5652f023a606b248f1781 ] sunxi_sram_claim() checks the sram_desc->claimed flag before updating the register, with the intent that only one device can claim a region. However, this was ineffective because the flag was never set. Fixes: 4af34b572a85 ("drivers: soc: sunxi: Introduce SoC driver to map SRAMs") Reviewed-by: Jernej Skrabec <jernej.skrabec@gmail.com> Signed-off-by: Samuel Holland <samuel@sholland.org> Reviewed-by: Heiko Stuebner <heiko@sntech.de> Tested-by: Heiko Stuebner <heiko@sntech.de> Signed-off-by: Jernej Skrabec <jernej.skrabec@gmail.com> Link: https://lore.kernel.org/r/20220815041248.53268-4-samuel@sholland.org Signed-off-by: Sasha Levin <sashal@kernel.org>
2022-10-05reset: imx7: Fix the iMX8MP PCIe PHY PERST supportRichard Zhu1-0/+1
[ Upstream commit 051d9eb403887bb11852b7a4f744728a6a4b1b58 ] On i.MX7/iMX8MM/iMX8MQ, the initialized default value of PERST bit(BIT3) of SRC_PCIEPHY_RCR is 1b'1. But i.MX8MP has one inversed default value 1b'0 of PERST bit. And the PERST bit should be kept 1b'1 after power and clocks are stable. So fix the i.MX8MP PCIe PHY PERST support here. Fixes: e08672c03981 ("reset: imx7: Add support for i.MX8MP SoC") Signed-off-by: Richard Zhu <hongxing.zhu@nxp.com> Reviewed-by: Philipp Zabel <p.zabel@pengutronix.de> Tested-by: Marek Vasut <marex@denx.de> Tested-by: Richard Leitner <richard.leitner@skidata.com> Tested-by: Alexander Stein <alexander.stein@ew.tq-group.com> Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de> Link: https://lore.kernel.org/r/1661845564-11373-5-git-send-email-hongxing.zhu@nxp.com Signed-off-by: Sasha Levin <sashal@kernel.org>
2022-10-05media: v4l2-compat-ioctl32.c: zero buffer passed to v4l2_compat_get_array_args()Hans Verkuil1-0/+2
commit 4e768c8e34e639cff66a0f175bc4aebf472e4305 upstream. The v4l2_compat_get_array_args() function can leave uninitialized memory in the buffer it is passed. So zero it before copying array elements from userspace into the buffer. Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Reported-by: syzbot+ff18193ff05f3f87f226@syzkaller.appspotmail.com Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-10-05media: rkvdec: Disable H.264 error detectionNicolas Dufresne1-2/+2
commit 3a99c4474112f49a5459933d8758614002ca0ddc upstream. Quite often, the HW get stuck in error condition if a stream error was detected. As documented, the HW should stop immediately and self reset. There is likely a problem or a miss-understanding of the self reset mechanism, as unless we make a long pause, the next command will then report an error even if there is no error in it. Disabling error detection fixes the issue, and let the decoder continue after an error. This patch is safe for backport into older kernels. Fixes: cd33c830448b ("media: rkvdec: Add the rkvdec driver") Signed-off-by: Nicolas Dufresne <nicolas.dufresne@collabora.com> Reviewed-by: Brian Norris <briannorris@chromium.org> Tested-by: Brian Norris <briannorris@chromium.org> Reviewed-by: Ezequiel Garcia <ezequiel@vanguardiasur.com.ar> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-10-05media: dvb_vb2: fix possible out of bound accessHangyu Hua1-0/+11
commit 37238699073e7e93f05517e529661151173cd458 upstream. vb2_core_qbuf and vb2_core_querybuf don't check the range of b->index controlled by the user. Fix this by adding range checking code before using them. Fixes: 57868acc369a ("media: videobuf2: Add new uAPI for DVB streaming I/O") Signed-off-by: Hangyu Hua <hbh25y@gmail.com> Reviewed-by: Sergey Senozhatsky <senozhatsky@chromium.org> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-10-05mmc: hsq: Fix data stomping during mmc recoveryWenchao Chen1-1/+1
commit e7afa79a3b35a27a046a2139f8b20bd6b98155c2 upstream. The block device uses multiple queues to access emmc. There will be up to 3 requests in the hsq of the host. The current code will check whether there is a request doing recovery before entering the queue, but it will not check whether there is a request when the lock is issued. The request is in recovery mode. If there is a request in recovery, then a read and write request is initiated at this time, and the conflict between the request and the recovery request will cause the data to be trampled. Signed-off-by: Wenchao Chen <wenchao.chen@unisoc.com> Fixes: 511ce378e16f ("mmc: Add MMC host software queue support") Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/20220916090506.10662-1-wenchao.chen666@gmail.com Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-10-05mmc: moxart: fix 4-bit bus width and remove 8-bit bus widthSergei Antonov1-14/+3
commit 35ca91d1338ae158f6dcc0de5d1e86197924ffda upstream. According to the datasheet [1] at page 377, 4-bit bus width is turned on by bit 2 of the Bus Width Register. Thus the current bitmask is wrong: define BUS_WIDTH_4 BIT(1) BIT(1) does not work but BIT(2) works. This has been verified on real MOXA hardware with FTSDC010 controller revision 1_6_0. The corrected value of BUS_WIDTH_4 mask collides with: define BUS_WIDTH_8 BIT(2). Additionally, 8-bit bus width mode isn't supported according to the datasheet, so let's remove the corresponding code. [1] https://bitbucket.org/Kasreyn/mkrom-uc7112lx/src/master/documents/FIC8120_DS_v1.2.pdf Fixes: 1b66e94e6b99 ("mmc: moxart: Add MOXA ART SD/MMC driver") Signed-off-by: Sergei Antonov <saproj@gmail.com> Cc: Jonas Jensen <jonas.jensen@gmail.com> Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/20220907205753.1577434-1-saproj@gmail.com Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-10-05libata: add ATA_HORKAGE_NOLPM for Pioneer BDR-207M and BDR-205Niklas Cassel1-0/+4
commit ea08aec7e77bfd6599489ec430f9f859ab84575a upstream. Commit 1527f69204fe ("ata: ahci: Add Green Sardine vendor ID as board_ahci_mobile") added an explicit entry for AMD Green Sardine AHCI controller using the board_ahci_mobile configuration (this configuration has later been renamed to board_ahci_low_power). The board_ahci_low_power configuration enables support for low power modes. This explicit entry takes precedence over the generic AHCI controller entry, which does not enable support for low power modes. Therefore, when commit 1527f69204fe ("ata: ahci: Add Green Sardine vendor ID as board_ahci_mobile") was backported to stable kernels, it make some Pioneer optical drives, which was working perfectly fine before the commit was backported, stop working. The real problem is that the Pioneer optical drives do not handle low power modes correctly. If these optical drives would have been tested on another AHCI controller using the board_ahci_low_power configuration, this issue would have been detected earlier. Unfortunately, the board_ahci_low_power configuration is only used in less than 15% of the total AHCI controller entries, so many devices have never been tested with an AHCI controller with low power modes. Fixes: 1527f69204fe ("ata: ahci: Add Green Sardine vendor ID as board_ahci_mobile") Cc: stable@vger.kernel.org Reported-by: Jaap Berkhout <j.j.berkhout@staalenberk.nl> Signed-off-by: Niklas Cassel <niklas.cassel@wdc.com> Reviewed-by: Mario Limonciello <mario.limonciello@amd.com> Signed-off-by: Damien Le Moal <damien.lemoal@opensource.wdc.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-10-05vduse: prevent uninitialized memory accessesMaxime Coquelin1-2/+7
commit 46f8a29272e51b6df7393d58fc5cb8967397ef2b upstream. If the VDUSE application provides a smaller config space than the driver expects, the driver may use uninitialized memory from the stack. This patch prevents it by initializing the buffer passed by the driver to store the config value. This fix addresses CVE-2022-2308. Cc: stable@vger.kernel.org # v5.15+ Fixes: c8a6153b6c59 ("vduse: Introduce VDUSE - vDPA Device in Userspace") Reviewed-by: Xie Yongji <xieyongji@bytedance.com> Acked-by: Jason Wang <jasowang@redhat.com> Signed-off-by: Maxime Coquelin <maxime.coquelin@redhat.com> Message-Id: <20220831154923.97809-1-maxime.coquelin@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com> Reviewed-by: Chaitanya Kulkarni <kch@nvidia.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-10-05drm/amdgpu: Add amdgpu suspend-resume code path under SRIOVBokun Zhang2-1/+30
commit 3b7329cf5a767c1be38352d43066012e220ad43c upstream. - Under SRIOV, we need to send REQ_GPU_FINI to the hypervisor during the suspend time. Furthermore, we cannot request a mode 1 reset under SRIOV as VF. Therefore, we will skip it as it is called in suspend_noirq() function. - In the resume code path, we need to send REQ_GPU_INIT to the hypervisor and also resume PSP IP block under SRIOV. Signed-off-by: Bokun Zhang <Bokun.Zhang@amd.com> Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-10-05drm/i915/gt: Restrict forced preemption to the active contextChris Wilson2-1/+35
commit 6ef7d362123ecb5bf6d163bb9c7fd6ba2d8c968c upstream. When we submit a new pair of contexts to ELSP for execution, we start a timer by which point we expect the HW to have switched execution to the pending contexts. If the promotion to the new pair of contexts has not occurred, we declare the executing context to have hung and force the preemption to take place by resetting the engine and resubmitting the new contexts. This can lead to an unfair situation where almost all of the preemption timeout is consumed by the first context which just switches into the second context immediately prior to the timer firing and triggering the preemption reset (assuming that the timer interrupts before we process the CS events for the context switch). The second context hasn't yet had a chance to yield to the incoming ELSP (and send the ACk for the promotion) and so ends up being blamed for the reset. If we see that a context switch has occurred since setting the preemption timeout, but have not yet received the ACK for the ELSP promotion, rearm the preemption timer and check again. This is especially significant if the first context was not schedulable and so we used the shortest timer possible, greatly increasing the chance of accidentally blaming the second innocent context. Fixes: 3a7a92aba8fb ("drm/i915/execlists: Force preemption") Fixes: d12acee84ffb ("drm/i915/execlists: Cancel banned contexts on schedule-out") Reported-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Cc: Andi Shyti <andi.shyti@linux.intel.com> Reviewed-by: Andrzej Hajda <andrzej.hajda@intel.com> Tested-by: Andrzej Hajda <andrzej.hajda@intel.com> Cc: <stable@vger.kernel.org> # v5.5+ Signed-off-by: Andi Shyti <andi.shyti@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220921135258.1714873-1-andrzej.hajda@intel.com (cherry picked from commit 107ba1a2c705f4358f2602ec2f2fd821bb651f42) Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-10-05Revert "firmware: arm_scmi: Add clock management to the SCMI power domain"Ulf Hansson1-26/+0
commit 3c6656337852e9f1a4079d172f3fddfbf00868f9 upstream. This reverts commit a3b884cef873 ("firmware: arm_scmi: Add clock management to the SCMI power domain"). Using the GENPD_FLAG_PM_CLK tells genpd to gate/ungate the consumer device's clock(s) during runtime suspend/resume through the PM clock API. More precisely, in genpd_runtime_resume() the clock(s) for the consumer device would become ungated prior to the driver-level ->runtime_resume() callbacks gets invoked. This behaviour isn't a good fit for all platforms/drivers. For example, a driver may need to make some preparations of its device in its ->runtime_resume() callback, like calling clk_set_rate() before the clock(s) should be ungated. In these cases, it's easier to let the clock(s) to be managed solely by the driver, rather than at the PM domain level. For these reasons, let's drop the use GENPD_FLAG_PM_CLK for the SCMI PM domain, as to enable it to be more easily adopted across ARM platforms. Fixes: a3b884cef873 ("firmware: arm_scmi: Add clock management to the SCMI power domain") Cc: Nicolas Pitre <npitre@baylibre.com> Cc: stable@vger.kernel.org Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org> Tested-by: Peng Fan <peng.fan@nxp.com> Acked-by: Sudeep Holla <sudeep.holla@arm.com> Link: https://lore.kernel.org/r/20220919122033.86126-1-ulf.hansson@linaro.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-10-05net: mt7531: only do PLL once after the resetAlexander Couzens1-6/+9
commit 42bc4fafe359ed6b73602b7a2dba0dd99588f8ce upstream. Move the PLL init of the switch out of the pad configuration of the port 6 (usally cpu port). Fix a unidirectional 100 mbit limitation on 1 gbit or 2.5 gbit links for outbound traffic on port 5 or port 6. Fixes: c288575f7810 ("net: dsa: mt7530: Add the support of MT7531 switch") Cc: stable@vger.kernel.org Signed-off-by: Alexander Couzens <lynxis@fe80.eu> Signed-off-by: Jakub Kicinski <kuba@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-10-05clk: ingenic-tcu: Properly enable registers before accessing timersAidan MacDonald1-10/+5
commit 6726d552a6912e88cf63fe2bda87b2efa0efc7d0 upstream. Access to registers is guarded by ingenic_tcu_{enable,disable}_regs() so the stop bit can be cleared before accessing a timer channel, but those functions did not clear the stop bit on SoCs with a global TCU clock gate. Testing on the X1000 has revealed that the stop bits must be cleared _and_ the global TCU clock must be ungated to access timer registers. This appears to be the norm on Ingenic SoCs, and is specified in the documentation for the X1000 and numerous JZ47xx SoCs. If the stop bit isn't cleared, register writes don't take effect and the system can be left in a broken state, eg. the watchdog timer may not run. The bug probably went unnoticed because stop bits are zeroed when the SoC is reset, and the kernel does not set them unless a timer gets disabled at runtime. However, it is possible that a bootloader or a previous kernel (if using kexec) leaves the stop bits set and we should not rely on them being cleared. Fixing this is easy: have ingenic_tcu_{enable,disable}_regs() always clear the stop bit, regardless of the presence of a global TCU gate. Reviewed-by: Paul Cercueil <paul@crapouillou.net> Tested-by: Paul Cercueil <paul@crapouillou.net> Fixes: 4f89e4b8f121 ("clk: ingenic: Add driver for the TCU clocks") Cc: stable@vger.kernel.org Signed-off-by: Aidan MacDonald <aidanmacdonald.0x0@gmail.com> Link: https://lore.kernel.org/r/20220617122254.738900-1-aidanmacdonald.0x0@gmail.com Signed-off-by: Stephen Boyd <sboyd@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-10-05can: c_can: don't cache TX messages for C_CAN coresMarc Kleine-Budde2-8/+20
commit 81d192c2ce74157e717e1fc4b68791f82f7499d4 upstream. As Jacob noticed, the optimization introduced in 387da6bc7a82 ("can: c_can: cache frames to operate as a true FIFO") doesn't properly work on C_CAN, but on D_CAN IP cores. The exact reasons are still unknown. For now disable caching if CAN frames in the TX path for C_CAN cores. Fixes: 387da6bc7a82 ("can: c_can: cache frames to operate as a true FIFO") Link: https://lore.kernel.org/all/20220928083354.1062321-1-mkl@pengutronix.de Link: https://lore.kernel.org/all/15a8084b-9617-2da1-6704-d7e39d60643b@gmail.com Reported-by: Jacob Kroon <jacob.kroon@gmail.com> Tested-by: Jacob Kroon <jacob.kroon@gmail.com> Cc: stable@vger.kernel.org # v5.15 Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-10-05Input: snvs_pwrkey - fix SNVS_HPVIDR1 register addressSebastian Krzyszkowiak1-1/+1
commit e62563db857f81d75c5726a35bc0180bed6d1540 upstream. Both i.MX6 and i.MX8 reference manuals list 0xBF8 as SNVS_HPVIDR1 (chapters 57.9 and 6.4.5 respectively). Without this, trying to read the revision number results in 0 on all revisions, causing the i.MX6 quirk to apply on all platforms, which in turn causes the driver to synthesise power button release events instead of passing the real one as they happen even on platforms like i.MX8 where that's not wanted. Fixes: 1a26c920717a ("Input: snvs_pwrkey - send key events for i.MX6 S, DL and Q") Tested-by: Martin Kepplinger <martin.kepplinger@puri.sm> Signed-off-by: Sebastian Krzyszkowiak <sebastian.krzyszkowiak@puri.sm> Reviewed-by: Mattijs Korpershoek <mkorpershoek@baylibre.com> Cc: <stable@vger.kernel.org> Link: https://lore.kernel.org/r/4599101.ElGaqSPkdT@pliszka Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-10-05net: usb: qmi_wwan: Add new usb-id for Dell branded EM7455Frank Wunderlich1-0/+1
commit 797666cd5af041ffb66642fff62f7389f08566a2 upstream. Add support for Dell 5811e (EM7455) with USB-id 0x413c:0x81c2. Signed-off-by: Frank Wunderlich <frank-w@public-files.de> Cc: stable@vger.kernel.org Acked-by: Bjørn Mork <bjorn@mork.no> Link: https://lore.kernel.org/r/20220926150740.6684-3-linux@fw-web.de Signed-off-by: Jakub Kicinski <kuba@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-10-05thunderbolt: Explicitly reset plug events delay back to USB4 spec valueMario Limonciello1-0/+1
commit 31f87f705b3c1635345d8e8a493697099b43e508 upstream. If any software has interacted with the USB4 registers before the Linux USB4 CM runs, it may have modified the plug events delay. It has been observed that if this value too large, it's possible that hotplugged devices will negotiate a fallback mode instead in Linux. To prevent this, explicitly align the plug events delay with the USB4 spec value of 10ms. Cc: stable@vger.kernel.org Signed-off-by: Mario Limonciello <mario.limonciello@amd.com> Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-10-05usb: typec: ucsi: Remove incorrect warningHeikki Krogerus1-2/+0
commit 415ba26cb73f7d22a892043301b91b57ae54db02 upstream. Sink only devices do not have any source capabilities, so the driver should not warn about that. Also DRP (Dual Role Power) capable devices, such as USB Type-C docking stations, do not return any source capabilities unless they are plugged to a power supply themselves. Fixes: 1f4642b72be7 ("usb: typec: ucsi: Retrieve all the PDOs instead of just the first 4") Reported-by: Paul Menzel <pmenzel@molgen.mpg.de> Cc: <stable@vger.kernel.org> Signed-off-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> Link: https://lore.kernel.org/r/20220922145924.80667-1-heikki.krogerus@linux.intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-10-05uas: ignore UAS for Thinkplus chipsHongling Zeng1-0/+7
commit 0fb9703a3eade0bb84c635705d9c795345e55053 upstream. The UAS mode of Thinkplus(0x17ef, 0x3899) is reported to influence performance and trigger kernel panic on several platforms with the following error message: [ 39.702439] xhci_hcd 0000:0c:00.3: ERROR Transfer event for disabled endpoint or incorrect stream ring [ 39.702442] xhci_hcd 0000:0c:00.3: @000000026c61f810 00000000 00000000 1b000000 05038000 [ 720.545894][13] Workqueue: usb_hub_wq hub_event [ 720.550971][13] ffff88026c143c38 0000000000016300 ffff8802755bb900 ffff880 26cb80000 [ 720.559673][13] ffff88026c144000 ffff88026ca88100 0000000000000000 ffff880 26cb80000 [ 720.568374][13] ffff88026cb80000 ffff88026c143c50 ffffffff8186ae25 ffff880 26ca880f8 [ 720.577076][13] Call Trace: [ 720.580201][13] [<ffffffff8186ae25>] schedule+0x35/0x80 [ 720.586137][13] [<ffffffff8186b0ce>] schedule_preempt_disabled+0xe/0x10 [ 720.593623][13] [<ffffffff8186cb94>] __mutex_lock_slowpath+0x164/0x1e0 [ 720.601012][13] [<ffffffff8186cc3f>] mutex_lock+0x2f/0x40 [ 720.607141][13] [<ffffffff8162b8e9>] usb_disconnect+0x59/0x290 Falling back to USB mass storage can solve this problem, so ignore UAS function of this chip. Acked-by: Alan Stern <stern@rowland.harvard.edu> Cc: stable <stable@kernel.org> Signed-off-by: Hongling Zeng <zenghongling@kylinos.cn> Link: https://lore.kernel.org/r/1663902249837086.19.seg@mailgw Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-10-05usb-storage: Add Hiksemi USB3-FW to IGNORE_UASHongling Zeng1-0/+7
commit e00b488e813f0f1ad9f778e771b7cd2fe2877023 upstream. The UAS mode of Hiksemi USB_HDD is reported to fail to work on several platforms with the following error message, then after re-connecting the device will be offlined and not working at all. [ 592.518442][ 2] sd 8:0:0:0: [sda] tag#17 uas_eh_abort_handler 0 uas-tag 18 inflight: CMD [ 592.527575][ 2] sd 8:0:0:0: [sda] tag#17 CDB: Write(10) 2a 00 03 6f 88 00 00 04 00 00 [ 592.536330][ 2] sd 8:0:0:0: [sda] tag#0 uas_eh_abort_handler 0 uas-tag 1 inflight: CMD [ 592.545266][ 2] sd 8:0:0:0: [sda] tag#0 CDB: Write(10) 2a 00 07 44 1a 88 00 00 08 00 These disks have a broken uas implementation, the tag field of the status iu-s is not set properly,so we need to fall-back to usb-storage. Acked-by: Alan Stern <stern@rowland.harvard.edu> Cc: stable <stable@kernel.org> Signed-off-by: Hongling Zeng <zenghongling@kylinos.cn> Link: https://lore.kernel.org/r/1663901185-21067-1-git-send-email-zenghongling@kylinos.cn Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-10-05uas: add no-uas quirk for Hiksemi usb_diskHongling Zeng1-0/+7
commit a625a4b8806cc1e928b7dd2cca1fee709c9de56e upstream. The UAS mode of Hiksemi is reported to fail to work on several platforms with the following error message, then after re-connecting the device will be offlined and not working at all. [ 592.518442][ 2] sd 8:0:0:0: [sda] tag#17 uas_eh_abort_handler 0 uas-tag 18 inflight: CMD [ 592.527575][ 2] sd 8:0:0:0: [sda] tag#17 CDB: Write(10) 2a 00 03 6f 88 00 00 04 00 00 [ 592.536330][ 2] sd 8:0:0:0: [sda] tag#0 uas_eh_abort_handler 0 uas-tag 1 inflight: CMD [ 592.545266][ 2] sd 8:0:0:0: [sda] tag#0 CDB: Write(10) 2a 00 07 44 1a 88 00 00 08 00 These disks have a broken uas implementation, the tag field of the status iu-s is not set properly,so we need to fall-back to usb-storage. Acked-by: Alan Stern <stern@rowland.harvard.edu> Cc: stable <stable@kernel.org> Signed-off-by: Hongling Zeng <zenghongling@kylinos.cn> Link: https://lore.kernel.org/r/1663901173-21020-1-git-send-email-zenghongling@kylinos.cn Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-09-28devdax: Fix soft-reservation memory descriptionDan Williams1-0/+1
commit 67feaba413ec68daf4124e9870878899b4ed9a0e upstream. The "hmem" platform-devices that are created to represent the platform-advertised "Soft Reserved" memory ranges end up inserting a resource that causes the iomem_resource tree to look like this: 340000000-43fffffff : hmem.0 340000000-43fffffff : Soft Reserved 340000000-43fffffff : dax0.0 This is because insert_resource() reparents ranges when they completely intersect an existing range. This matters because code that uses region_intersects() to scan for a given IORES_DESC will only check that top-level 'hmem.0' resource and not the 'Soft Reserved' descendant. So, to support EINJ (via einj_error_inject()) to inject errors into memory hosted by a dax-device, be sure to describe the memory as IORES_DESC_SOFT_RESERVED. This is a follow-on to: commit b13a3e5fd40b ("ACPI: APEI: Fix _EINJ vs EFI_MEMORY_SP") ...that fixed EINJ support for "Soft Reserved" ranges in the first instance. Fixes: 262b45ae3ab4 ("x86/efi: EFI soft reservation to E820 enumeration") Reported-by: Ricardo Sandoval Torres <ricardo.sandoval.torres@intel.com> Tested-by: Ricardo Sandoval Torres <ricardo.sandoval.torres@intel.com> Cc: <stable@vger.kernel.org> Cc: Tony Luck <tony.luck@intel.com> Cc: Omar Avelar <omar.avelar@intel.com> Cc: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Cc: Mark Gross <markgross@kernel.org> Link: https://lore.kernel.org/r/166397075670.389916.7435722208896316387.stgit@dwillia2-xfh.jf.intel.com Signed-off-by: Dan Williams <dan.j.williams@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-09-28drm/amdgpu: don't register a dirty callback for non-atomicAlex Deucher1-1/+10
[ Upstream commit abbc7a3dafb91b9d4ec56b70ec9a7520f8e13334 ] Some asics still support non-atomic code paths. Fixes: 66f99628eb2440 ("drm/amdgpu: use dirty framebuffer helper") Reported-by: Arthur Marsh <arthur.marsh@internode.on.net> Reviewed-by: Hamza Mahfooz <hamza.mahfooz@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2022-09-28i2c: mlxbf: Fix frequency calculationAsmaa Mnebhi1-40/+23
[ Upstream commit 37f071ec327b04c83d47637c5e5c2199b39899ca ] The i2c-mlxbf.c driver is currently broken because there is a bug in the calculation of the frequency. core_f, core_r and core_od are components read from hardware registers and are used to compute the frequency used to compute different timing parameters. The shifting mechanism used to get core_f, core_r and core_od is wrong. Use FIELD_GET to mask and shift the bitfields properly. Fixes: b5b5b32081cd206b (i2c: mlxbf: I2C SMBus driver for Mellanox BlueField SoC) Reviewed-by: Khalil Blaiech <kblaiech@nvidia.com> Signed-off-by: Asmaa Mnebhi <asmaa@nvidia.com> Signed-off-by: Wolfram Sang <wsa@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2022-09-28i2c: mlxbf: prevent stack overflow in mlxbf_i2c_smbus_start_transaction()Asmaa Mnebhi1-0/+3
[ Upstream commit de24aceb07d426b6f1c59f33889d6a964770547b ] memcpy() is called in a loop while 'operation->length' upper bound is not checked and 'data_idx' also increments. Fixes: b5b5b32081cd206b ("i2c: mlxbf: I2C SMBus driver for Mellanox BlueField SoC") Reviewed-by: Khalil Blaiech <kblaiech@nvidia.com> Signed-off-by: Asmaa Mnebhi <asmaa@nvidia.com> Signed-off-by: Wolfram Sang <wsa@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2022-09-28i2c: mlxbf: incorrect base address passed during io writeAsmaa Mnebhi1-1/+1
[ Upstream commit 2a5be6d1340c0fefcee8a6489cff7fd88a0d5b85 ] Correct the base address used during io write. This bug had no impact over the overall functionality of the read and write transactions. MLXBF_I2C_CAUSE_OR_CLEAR=0x18 so writing to (smbus->io + 0x18) instead of (mst_cause->ioi + 0x18) actually writes to the sc_low_timeout register which just sets the timeout value before a read/write aborts. Fixes: b5b5b32081cd206b (i2c: mlxbf: I2C SMBus driver for Mellanox BlueField SoC) Reviewed-by: Khalil Blaiech <kblaiech@nvidia.com> Signed-off-by: Asmaa Mnebhi <asmaa@nvidia.com> Signed-off-by: Wolfram Sang <wsa@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2022-09-28i2c: imx: If pm_runtime_get_sync() returned 1 device access is possibleUwe Kleine-König1-1/+1
[ Upstream commit 085aacaa73163f4b8a89dec24ecb32cfacd34017 ] pm_runtime_get_sync() returning 1 also means the device is powered. So resetting the chip registers in .remove() is possible and should be done. Reported-by: Dan Carpenter <dan.carpenter@oracle.com> Fixes: d98bdd3a5b50 ("i2c: imx: Make sure to unregister adapter on remove()") Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Acked-by: Oleksij Rempel <o.rempel@pengutronix.de> Signed-off-by: Wolfram Sang <wsa@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2022-09-28drm/rockchip: Fix return type of cdn_dp_connector_mode_validNathan Huckleberry1-2/+3
[ Upstream commit b0b9408f132623dc88e78adb5282f74e4b64bb57 ] The mode_valid field in drm_connector_helper_funcs is expected to be of type: enum drm_mode_status (* mode_valid) (struct drm_connector *connector, struct drm_display_mode *mode); The mismatched return type breaks forward edge kCFI since the underlying function definition does not match the function hook definition. The return type of cdn_dp_connector_mode_valid should be changed from int to enum drm_mode_status. Reported-by: Dan Carpenter <error27@gmail.com> Link: https://github.com/ClangBuiltLinux/linux/issues/1703 Cc: llvm@lists.linux.dev Signed-off-by: Nathan Huckleberry <nhuck@google.com> Reviewed-by: Nathan Chancellor <nathan@kernel.org> Signed-off-by: Heiko Stuebner <heiko@sntech.de> Link: https://patchwork.freedesktop.org/patch/msgid/20220913205555.155149-1-nhuck@google.com Signed-off-by: Sasha Levin <sashal@kernel.org>
2022-09-28drm/amd/display: Mark dml30's UseMinimumDCFCLK() as noinline for stack usageNathan Chancellor1-2/+1
[ Upstream commit 41012d715d5d7b9751ae84b8fb255e404ac9c5d0 ] This function consumes a lot of stack space and it blows up the size of dml30_ModeSupportAndSystemConfigurationFull() with clang: drivers/gpu/drm/amd/amdgpu/../display/dc/dml/dcn30/display_mode_vba_30.c:3542:6: error: stack frame size (2200) exceeds limit (2048) in 'dml30_ModeSupportAndSystemConfigurationFull' [-Werror,-Wframe-larger-than] void dml30_ModeSupportAndSystemConfigurationFull(struct display_mode_lib *mode_lib) ^ 1 error generated. Commit a0f7e7f759cf ("drm/amd/display: fix i386 frame size warning") aimed to address this for i386 but it did not help x86_64. To reduce the amount of stack space that dml30_ModeSupportAndSystemConfigurationFull() uses, mark UseMinimumDCFCLK() as noinline, using the _for_stack variant for documentation. While this will increase the total amount of stack usage between the two functions (1632 and 1304 bytes respectively), it will make sure both stay below the limit of 2048 bytes for these files. The aforementioned change does help reduce UseMinimumDCFCLK()'s stack usage so it should not be reverted in favor of this change. Link: https://github.com/ClangBuiltLinux/linux/issues/1681 Reported-by: "Sudip Mukherjee (Codethink)" <sudipm.mukherjee@gmail.com> Tested-by: Maíra Canal <mairacanal@riseup.net> Reviewed-by: Rodrigo Siqueira <Rodrigo.Siqueira@amd.com> Signed-off-by: Nathan Chancellor <nathan@kernel.org> Signed-off-by: Rodrigo Siqueira <Rodrigo.Siqueira@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
generated by cgit v1.2.3 (git 2.39.0) at 2026-05-11 16:19:30 +0300