commit 014862eecf03f58066a957027dde73cbecdf4395 Author: Greg Kroah-Hartman Date: Wed Oct 5 10:38:43 2022 +0200 Linux 5.10.147 Link: https://lore.kernel.org/r/20221003070718.687440096@linuxfoundation.org Tested-by: Jon Hunter Tested-by: Pavel Machek (CIP) Tested-by: Allen Pais Tested-by: Guenter Roeck Tested-by: Florian Fainelli Tested-by: Slade Watkins Tested-by: Linux Kernel Functional Testing Tested-by: Sudip Mukherjee Signed-off-by: Greg Kroah-Hartman commit 98f722cc2438d16b8949fdce712feb1fbf9699e8 Author: Kai Vehmanen Date: Thu Apr 14 18:05:16 2022 +0300 ALSA: hda/hdmi: fix warning about PCM count when used with SOF commit c74193787b2f683751a67603fb5f15c7584f355f upstream. With commit 13046370c4d1 ("ALSA: hda/hdmi: let new platforms assign the pcm slot dynamically"), old behaviour to consider the HDA pin number, when choosing PCM to assign, was dropped. Build on this change and limit the number of PCMs created to number of converters (= maximum number of concurrent display/receivers) when "mst_no_extra_pcms" and "dyn_pcm_no_legacy" quirks are both set. Fix the check in hdmi_find_pcm_slot() to ensure only spec->pcm_used entries are considered in the search. Elsewhere in the driver spec->pcm_used is already checked properly. Doing this avoids following warning at SOF driver probe for multiple machine drivers: [ 112.425297] sof_sdw sof_sdw: hda_dsp_hdmi_build_controls: no PCM in topology for HDMI converter 4 [ 112.425298] sof_sdw sof_sdw: hda_dsp_hdmi_build_controls: no PCM in topology for HDMI converter 5 [ 112.425299] sof_sdw sof_sdw: hda_dsp_hdmi_build_controls: no PCM in topology for HDMI converter 6 Fixes: 13046370c4d1 ("ALSA: hda/hdmi: let new platforms assign the pcm slot dynamically") BugLink: https://github.com/thesofproject/linux/issues/2573 Signed-off-by: Kai Vehmanen Link: https://lore.kernel.org/r/20220414150516.3638283-1-kai.vehmanen@linux.intel.com Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit b12d0489e4021220b3341a95a6be37c5ff14729e Author: Nadav Amit Date: Wed Sep 21 18:09:32 2022 +0000 x86/alternative: Fix race in try_get_desc() commit efd608fa7403ba106412b437f873929e2c862e28 upstream. I encountered some occasional crashes of poke_int3_handler() when kprobes are set, while accessing desc->vec. The text poke mechanism claims to have an RCU-like behavior, but it does not appear that there is any quiescent state to ensure that nobody holds reference to desc. As a result, the following race appears to be possible, which can lead to memory corruption. CPU0 CPU1 ---- ---- text_poke_bp_batch() -> smp_store_release(&bp_desc, &desc) [ notice that desc is on the stack ] poke_int3_handler() [ int3 might be kprobe's so sync events are do not help ] -> try_get_desc(descp=&bp_desc) desc = __READ_ONCE(bp_desc) if (!desc) [false, success] WRITE_ONCE(bp_desc, NULL); atomic_dec_and_test(&desc.refs) [ success, desc space on the stack is being reused and might have non-zero value. ] arch_atomic_inc_not_zero(&desc->refs) [ might succeed since desc points to stack memory that was freed and might be reused. ] Fix this issue with small backportable patch. Instead of trying to make RCU-like behavior for bp_desc, just eliminate the unnecessary level of indirection of bp_desc, and hold the whole descriptor as a global. Anyhow, there is only a single descriptor at any given moment. Fixes: 1f676247f36a4 ("x86/alternatives: Implement a better poke_int3_handler() completion scheme") Signed-off-by: Nadav Amit Signed-off-by: Peter Zijlstra (Intel) Cc: stable@kernel.org Link: https://lkml.kernel.org/r/20220920224743.3089-1-namit@vmware.com Signed-off-by: Greg Kroah-Hartman commit 374d4c307534c5fdd56aa7f1eb2cba67160ac9a2 Author: Jim Mattson Date: Thu Sep 22 16:18:54 2022 -0700 KVM: x86: Hide IA32_PLATFORM_DCA_CAP[31:0] from the guest [ Upstream commit aae2e72229cdb21f90df2dbe4244c977e5d3265b ] The only thing reported by CPUID.9 is the value of IA32_PLATFORM_DCA_CAP[31:0] in EAX. This MSR doesn't even exist in the guest, since CPUID.1:ECX.DCA[bit 18] is clear in the guest. Clear CPUID.9 in KVM_GET_SUPPORTED_CPUID. Fixes: 24c82e576b78 ("KVM: Sanitize cpuid") Signed-off-by: Jim Mattson Message-Id: <20220922231854.249383-1-jmattson@google.com> Signed-off-by: Paolo Bonzini Signed-off-by: Sasha Levin commit a8e6cde5062fb2aff81f86cc0770591714bee545 Author: Florian Fainelli Date: Mon Sep 5 09:15:03 2022 -0700 clk: iproc: Do not rely on node name for correct PLL setup [ 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 Acked-by: Rafał Miłecki Link: https://lore.kernel.org/r/20220905161504.1526-1-f.fainelli@gmail.com Signed-off-by: Stephen Boyd Signed-off-by: Sasha Levin commit cf41711aa4a7000fead6c9e8c088e4fd4fc02316 Author: Han Xu Date: Thu Sep 15 10:09:59 2022 -0500 clk: imx: imx6sx: remove the SET_RATE_PARENT flag for QSPI clocks [ 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 Link: https://lore.kernel.org/r/20220915150959.3646702-1-han.xu@nxp.com Tested-by: Fabio Estevam Reviewed-by: Abel Vesa Signed-off-by: Stephen Boyd Signed-off-by: Sasha Levin commit 83db457b41a821b39e0e7988341a9341b5848f08 Author: Wang Yufen Date: Fri Sep 23 15:02:37 2022 +0800 selftests: Fix the if conditions of in test_extra_filter() [ Upstream commit bc7a319844891746135dc1f34ab9df78d636a3ac ] The socket 2 bind the addr in use, bind should fail with EADDRINUSE. So if bind success or errno != EADDRINUSE, testcase should be failed. Fixes: 3ca8e4029969 ("soreuseport: BPF selection functional test") Signed-off-by: Wang Yufen Link: https://lore.kernel.org/r/1663916557-10730-1-git-send-email-wangyufen@huawei.com Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit 84cab3531ff77583ef7e76cff025e76e2a748f3f Author: Junxiao Chang Date: Fri Sep 23 13:04:48 2022 +0800 net: stmmac: power up/down serdes in stmmac_open/release [ 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 Reviewed-by: Voon Weifeng Tested-by: Jimmy JS Chen Tested-by: Looi, Hong Aun Link: https://lore.kernel.org/r/20220923050448.1220250-1-junxiao.chang@intel.com Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit 743a6e53cf1c19786144d4268f7e445403fb86f1 Author: Michael Kelley Date: Thu Sep 22 21:49:09 2022 -0700 nvme: Fix IOC_PR_CLEAR and IOC_PR_RELEASE ioctls for nvme devices [ 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 Signed-off-by: Christoph Hellwig Signed-off-by: Sasha Levin commit 469dc5fd9a58e8111a9163083a87a940bb2ee20d Author: Chaitanya Kulkarni Date: Sun Feb 28 18:06:11 2021 -0800 nvme: add new line after variable declatation [ Upstream commit f1c772d581843e3a14bbd62ef7e40b56fc307f27 ] Add a new line in functions nvme_pr_preempt(), nvme_pr_clear(), and nvme_pr_release() after variable declaration which follows the rest of the code in the nvme/host/core.c. No functional change(s) in this patch. Signed-off-by: Chaitanya Kulkarni Signed-off-by: Christoph Hellwig Stable-dep-of: c292a337d0e4 ("nvme: Fix IOC_PR_CLEAR and IOC_PR_RELEASE ioctls for nvme devices") Signed-off-by: Sasha Levin commit 2c248c4681620e76d42ef16a14050e26bd07702d Author: Rafael Mendonca Date: Thu Sep 22 14:51:08 2022 -0300 cxgb4: fix missing unlock on ETHOFLD desc collect fail path [ 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 Reviewed-by: Rahul Lakkireddy Link: https://lore.kernel.org/r/20220922175109.764898-1-rafaelmendsr@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit fde656dbc3720f1991631eb678087c6af7a4461b Author: Hangyu Hua Date: Fri Sep 23 10:00:46 2022 +0800 net: sched: act_ct: fix possible refcount leak in tcf_ct_init() [ Upstream commit 6e23ec0ba92d426c77a73a9ccab16346e5e0ef49 ] nf_ct_put need to be called to put the refcount got by tcf_ct_fill_params to avoid possible refcount leak when tcf_ct_flow_table_get fails. Fixes: c34b961a2492 ("net/sched: act_ct: Create nf flow table per zone") Signed-off-by: Hangyu Hua Link: https://lore.kernel.org/r/20220923020046.8021-1-hbh25y@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit fa065e60811a689601924e8ade4a81a90468e204 Author: Peilin Ye Date: Thu Sep 22 21:25:51 2022 -0700 usbnet: Fix memory leak in usbnet_disconnect() [ 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 Link: https://lore.kernel.org/r/20220923042551.2745-1-yepeilin.cs@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 57959392f7f00db2c2b82be8e3624810b7e0c59f Author: Yang Yingliang Date: Sat Sep 24 11:07:15 2022 +0800 Input: melfas_mip4 - fix return value check in mip4_probe() [ 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 Link: https://lore.kernel.org/r/20220924030715.1653538-1-yangyingliang@huawei.com Signed-off-by: Dmitry Torokhov Signed-off-by: Sasha Levin commit 330b77578168ae6b83fe783d797a86b139cdc4f4 Author: Brian Norris Date: Mon Aug 22 18:08:04 2022 -0700 Revert "drm: bridge: analogix/dp: add panel prepare/unprepare in 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 Reviewed-by: Douglas Anderson Signed-off-by: Douglas Anderson Link: https://patchwork.freedesktop.org/patch/msgid/20220822180729.1.I8ac5abe3a4c1c6fd5c061686c6e883c22f69022c@changeid Signed-off-by: Sasha Levin commit 359e73edd3be51d192923a90f2f2d44dd6a7c131 Author: Martin Povišer Date: Mon Sep 19 19:34:53 2022 +0200 ASoC: tas2770: Reinit regcache on reset [ Upstream commit 0a0342ede303fc420f3a388e1ae82da3ae8ff6bd ] On probe of the ASoC component, the device is reset but the regcache is retained. This means the regcache gets out of sync if the codec is rebound to a sound card for a second time. Fix it by reinitializing the regcache to defaults after the device is reset. Fixes: b0bcbe615756 ("ASoC: tas2770: Fix calling reset in probe") Signed-off-by: Martin Povišer Link: https://lore.kernel.org/r/20220919173453.84292-1-povik+lin@cutebit.org Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 8884a192f95e6f845d11d039b1bc0ca0c368737f Author: Samuel Holland Date: Sun Aug 14 23:12:43 2022 -0500 soc: sunxi: sram: Fix debugfs info for A64 SRAM C [ 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 Signed-off-by: Samuel Holland Signed-off-by: Jernej Skrabec Link: https://lore.kernel.org/r/20220815041248.53268-7-samuel@sholland.org Signed-off-by: Sasha Levin commit 4e2ede7cb9b5d4950d8e837d50a480250752f2d1 Author: Samuel Holland Date: Sun Aug 14 23:12:42 2022 -0500 soc: sunxi: sram: Fix probe function ordering issues [ 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 Signed-off-by: Samuel Holland Tested-by: Heiko Stuebner Signed-off-by: Jernej Skrabec Link: https://lore.kernel.org/r/20220815041248.53268-6-samuel@sholland.org Signed-off-by: Sasha Levin commit 50fbc81f80d2d7eefca6992190b07a1285fdcf95 Author: Cai Huoqing Date: Wed Sep 8 15:17:15 2021 +0800 soc: sunxi_sram: Make use of the helper function 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 Signed-off-by: Maxime Ripard 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 commit 0fdc3ab9b4386b73b47e55d06f4b6c3888da7246 Author: Samuel Holland Date: Sun Aug 14 23:12:41 2022 -0500 soc: sunxi: sram: Prevent the driver from being unbound [ 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 Signed-off-by: Samuel Holland Reviewed-by: Heiko Stuebner Tested-by: Heiko Stuebner Signed-off-by: Jernej Skrabec Link: https://lore.kernel.org/r/20220815041248.53268-5-samuel@sholland.org Signed-off-by: Sasha Levin commit 3e0405c69bc9e3717f247c1849a31545098997c1 Author: Samuel Holland Date: Sun Aug 14 23:12:40 2022 -0500 soc: sunxi: sram: Actually claim SRAM regions [ 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 Signed-off-by: Samuel Holland Reviewed-by: Heiko Stuebner Tested-by: Heiko Stuebner Signed-off-by: Jernej Skrabec Link: https://lore.kernel.org/r/20220815041248.53268-4-samuel@sholland.org Signed-off-by: Sasha Levin commit a658f0bc72cb4e9189ced0713da5b6f536f6941b Author: Richard Zhu Date: Tue Aug 30 15:46:01 2022 +0800 reset: imx7: Fix the iMX8MP PCIe PHY PERST support [ 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 Reviewed-by: Philipp Zabel Tested-by: Marek Vasut Tested-by: Richard Leitner Tested-by: Alexander Stein Signed-off-by: Philipp Zabel Link: https://lore.kernel.org/r/1661845564-11373-5-git-send-email-hongxing.zhu@nxp.com Signed-off-by: Sasha Levin commit 8934aea1a46c7f41e713613cbc865c135838ab54 Author: YuTong Chang Date: Mon Jun 20 05:41:46 2022 -0700 ARM: dts: am33xx: Fix MMCHS0 dma properties [ Upstream commit 2eb502f496f7764027b7958d4e74356fed918059 ] According to technical manual(table 11-24), the DMA of MMCHS0 should be direct mapped. Fixes: b5e509066074 ("ARM: DTS: am33xx: Use the new DT bindings for the eDMA3") Signed-off-by: YuTong Chang Message-Id: <20220620124146.5330-1-mtwget@gmail.com> Acked-by: Krzysztof Kozlowski Signed-off-by: Tony Lindgren Signed-off-by: Sasha Levin commit cce5dc03338e25e910fb5a2c4f2ce8a79644370f Author: Yu Kuai Date: Tue Sep 27 21:01:16 2022 +0800 scsi: hisi_sas: Revert "scsi: hisi_sas: Limit max hw sectors for v3 HW" This reverts commit 24cd0b9bfdff126c066032b0d40ab0962d35e777. 1) commit 4e89dce72521 ("iommu/iova: Retry from last rb tree node if iova search fails") tries to fix that iova allocation can fail while there are still free space available. This is not backported to 5.10 stable. 2) commit fce54ed02757 ("scsi: hisi_sas: Limit max hw sectors for v3 HW") fix the performance regression introduced by 1), however, this is just a temporary solution and will cause io performance regression because it limit max io size to PAGE_SIZE * 32(128k for 4k page_size). 3) John Garry posted a patchset to fix the problem. 4) The temporary solution is reverted. It's weird that the patch in 2) is backported to 5.10 stable alone, while the right thing to do is to backport them all together. Signed-off-by: Yu Kuai Reviewed-by: John Garry Signed-off-by: Greg Kroah-Hartman commit 625899cd06e1b4a12b374b09354404e52457da6a Author: Tianyu Lan Date: Tue May 10 10:21:09 2022 -0400 swiotlb: max mapping size takes min align mask into account commit 82806744fd7dde603b64c151eeddaa4ee62193fd upstream. swiotlb_find_slots() skips slots according to io tlb aligned mask calculated from min aligned mask and original physical address offset. This affects max mapping size. The mapping size can't achieve the IO_TLB_SEGSIZE * IO_TLB_SIZE when original offset is non-zero. This will cause system boot up failure in Hyper-V Isolation VM where swiotlb force is enabled. Scsi layer use return value of dma_max_mapping_size() to set max segment size and it finally calls swiotlb_max_mapping_size(). Hyper-V storage driver sets min align mask to 4k - 1. Scsi layer may pass 256k length of request buffer with 0~4k offset and Hyper-V storage driver can't get swiotlb bounce buffer via DMA API. Swiotlb_find_slots() can't find 256k length bounce buffer with offset. Make swiotlb_max_mapping _size() take min align mask into account. Signed-off-by: Tianyu Lan Signed-off-by: Christoph Hellwig Signed-off-by: Rishabh Bhatnagar Signed-off-by: Greg Kroah-Hartman commit 6f478fe8c3fbdfd82249bad762b0ffa7a551389f Author: Nicolas Dufresne Date: Fri Jun 10 13:52:11 2022 +0100 media: rkvdec: Disable H.264 error detection 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 Reviewed-by: Brian Norris Tested-by: Brian Norris Reviewed-by: Ezequiel Garcia Signed-off-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Greg Kroah-Hartman commit ac828e2416911b27e78663c32a8c168a40549103 Author: Hangyu Hua Date: Thu May 19 03:17:43 2022 +0100 media: dvb_vb2: fix possible out of bound access 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 Reviewed-by: Sergey Senozhatsky Signed-off-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Greg Kroah-Hartman commit be2cd261ca510be5cb51b198c602c516207dd32b Author: Minchan Kim Date: Thu Sep 8 08:12:04 2022 -0700 mm: fix madivse_pageout mishandling on non-LRU page commit 58d426a7ba92870d489686dfdb9d06b66815a2ab upstream. MADV_PAGEOUT tries to isolate non-LRU pages and gets a warning from isolate_lru_page below. Fix it by checking PageLRU in advance. ------------[ cut here ]------------ trying to isolate tail page WARNING: CPU: 0 PID: 6175 at mm/folio-compat.c:158 isolate_lru_page+0x130/0x140 Modules linked in: CPU: 0 PID: 6175 Comm: syz-executor.0 Not tainted 5.18.12 #1 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.13.0-1ubuntu1.1 04/01/2014 RIP: 0010:isolate_lru_page+0x130/0x140 Link: https://lore.kernel.org/linux-mm/485f8c33.2471b.182d5726afb.Coremail.hantianshuo@iie.ac.cn/ Link: https://lkml.kernel.org/r/20220908151204.762596-1-minchan@kernel.org Fixes: 1a4e58cce84e ("mm: introduce MADV_PAGEOUT") Signed-off-by: Minchan Kim Reported-by: 韩天ç`• Suggested-by: Yang Shi Acked-by: Yang Shi Cc: Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman commit 1002d5fef406c8dc685679aedb16938ad57d968c Author: Alistair Popple Date: Fri Sep 2 10:35:51 2022 +1000 mm/migrate_device.c: flush TLB while holding PTL commit 60bae73708963de4a17231077285bd9ff2f41c44 upstream. When clearing a PTE the TLB should be flushed whilst still holding the PTL to avoid a potential race with madvise/munmap/etc. For example consider the following sequence: CPU0 CPU1 ---- ---- migrate_vma_collect_pmd() pte_unmap_unlock() madvise(MADV_DONTNEED) -> zap_pte_range() pte_offset_map_lock() [ PTE not present, TLB not flushed ] pte_unmap_unlock() [ page is still accessible via stale TLB ] flush_tlb_range() In this case the page may still be accessed via the stale TLB entry after madvise returns. Fix this by flushing the TLB while holding the PTL. Fixes: 8c3328f1f36a ("mm/migrate: migrate_vma() unmap page from vma while collecting pages") Link: https://lkml.kernel.org/r/9f801e9d8d830408f2ca27821f606e09aa856899.1662078528.git-series.apopple@nvidia.com Signed-off-by: Alistair Popple Reported-by: Nadav Amit Reviewed-by: "Huang, Ying" Acked-by: David Hildenbrand Acked-by: Peter Xu Cc: Alex Sierra Cc: Ben Skeggs Cc: Felix Kuehling Cc: huang ying Cc: Jason Gunthorpe Cc: John Hubbard Cc: Karol Herbst Cc: Logan Gunthorpe Cc: Lyude Paul Cc: Matthew Wilcox Cc: Paul Mackerras Cc: Ralph Campbell Cc: Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman commit a54fc536911371bd5863afdcb2418ab948484b75 Author: Maurizio Lombardi Date: Fri Jul 15 14:50:13 2022 +0200 mm: prevent page_frag_alloc() from corrupting the memory commit dac22531bbd4af2426c4e29e05594415ccfa365d upstream. A number of drivers call page_frag_alloc() with a fragment's size > PAGE_SIZE. In low memory conditions, __page_frag_cache_refill() may fail the order 3 cache allocation and fall back to order 0; In this case, the cache will be smaller than the fragment, causing memory corruptions. Prevent this from happening by checking if the newly allocated cache is large enough for the fragment; if not, the allocation will fail and page_frag_alloc() will return NULL. Link: https://lkml.kernel.org/r/20220715125013.247085-1-mlombard@redhat.com Fixes: b63ae8ca096d ("mm/net: Rename and move page fragment handling from net/ to mm/") Signed-off-by: Maurizio Lombardi Reviewed-by: Alexander Duyck Cc: Chen Lin Cc: Jakub Kicinski Cc: Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman commit 466a26af2d105666a427e4892b2be67cfcc55f4f Author: Mel Gorman Date: Wed Aug 24 12:14:50 2022 +0100 mm/page_alloc: fix race condition between build_all_zonelists and page allocation commit 3d36424b3b5850bd92f3e89b953a430d7cfc88ef upstream. Patrick Daly reported the following problem; NODE_DATA(nid)->node_zonelists[ZONELIST_FALLBACK] - before offline operation [0] - ZONE_MOVABLE [1] - ZONE_NORMAL [2] - NULL For a GFP_KERNEL allocation, alloc_pages_slowpath() will save the offset of ZONE_NORMAL in ac->preferred_zoneref. If a concurrent memory_offline operation removes the last page from ZONE_MOVABLE, build_all_zonelists() & build_zonerefs_node() will update node_zonelists as shown below. Only populated zones are added. NODE_DATA(nid)->node_zonelists[ZONELIST_FALLBACK] - after offline operation [0] - ZONE_NORMAL [1] - NULL [2] - NULL The race is simple -- page allocation could be in progress when a memory hot-remove operation triggers a zonelist rebuild that removes zones. The allocation request will still have a valid ac->preferred_zoneref that is now pointing to NULL and triggers an OOM kill. This problem probably always existed but may be slightly easier to trigger due to 6aa303defb74 ("mm, vmscan: only allocate and reclaim from zones with pages managed by the buddy allocator") which distinguishes between zones that are completely unpopulated versus zones that have valid pages not managed by the buddy allocator (e.g. reserved, memblock, ballooning etc). Memory hotplug had multiple stages with timing considerations around managed/present page updates, the zonelist rebuild and the zone span updates. As David Hildenbrand puts it memory offlining adjusts managed+present pages of the zone essentially in one go. If after the adjustments, the zone is no longer populated (present==0), we rebuild the zone lists. Once that's done, we try shrinking the zone (start+spanned pages) -- which results in zone_start_pfn == 0 if there are no more pages. That happens *after* rebuilding the zonelists via remove_pfn_range_from_zone(). The only requirement to fix the race is that a page allocation request identifies when a zonelist rebuild has happened since the allocation request started and no page has yet been allocated. Use a seqlock_t to track zonelist updates with a lockless read-side of the zonelist and protecting the rebuild and update of the counter with a spinlock. [akpm@linux-foundation.org: make zonelist_update_seq static] Link: https://lkml.kernel.org/r/20220824110900.vh674ltxmzb3proq@techsingularity.net Fixes: 6aa303defb74 ("mm, vmscan: only allocate and reclaim from zones with pages managed by the buddy allocator") Signed-off-by: Mel Gorman Reported-by: Patrick Daly Acked-by: Michal Hocko Reviewed-by: David Hildenbrand Cc: [4.9+] Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman commit 9b751b4dc350a5ba836fb33518da1daac5b4a205 Author: Wenchao Chen Date: Fri Sep 16 17:05:06 2022 +0800 mmc: hsq: Fix data stomping during mmc recovery 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 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 Signed-off-by: Greg Kroah-Hartman commit 36b10cde0c440ccd57ad3c99f6279f38f35705a5 Author: Sergei Antonov Date: Wed Sep 7 23:57:53 2022 +0300 mmc: moxart: fix 4-bit bus width and remove 8-bit bus width 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 Cc: Jonas Jensen Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/20220907205753.1577434-1-saproj@gmail.com Signed-off-by: Ulf Hansson Signed-off-by: Greg Kroah-Hartman commit 02d55a837e1ae2d59955dbe8dbc9b6ff8d5cf7c9 Author: Niklas Cassel Date: Mon Sep 26 18:38:09 2022 +0000 libata: add ATA_HORKAGE_NOLPM for Pioneer BDR-207M and BDR-205 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 Signed-off-by: Niklas Cassel Reviewed-by: Mario Limonciello Signed-off-by: Damien Le Moal Signed-off-by: Greg Kroah-Hartman commit e72a435fa30cd96a917ce2be112a4ea0a536aeca Author: Alexander Couzens Date: Sat Sep 17 02:07:33 2022 +0200 net: mt7531: only do PLL once after the reset 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 Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit a48daecd0994d9d5dc512302412880fe0f5613f4 Author: ChenXiaoSong Date: Tue Aug 9 14:47:30 2022 +0800 ntfs: fix BUG_ON in ntfs_lookup_inode_by_name() commit 1b513f613731e2afc05550e8070d79fac80c661e upstream. Syzkaller reported BUG_ON as follows: ------------[ cut here ]------------ kernel BUG at fs/ntfs/dir.c:86! invalid opcode: 0000 [#1] PREEMPT SMP KASAN PTI CPU: 3 PID: 758 Comm: a.out Not tainted 5.19.0-next-20220808 #5 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014 RIP: 0010:ntfs_lookup_inode_by_name+0xd11/0x2d10 Code: ff e9 b9 01 00 00 e8 1e fe d6 fe 48 8b 7d 98 49 8d 5d 07 e8 91 85 29 ff 48 c7 45 98 00 00 00 00 e9 5a fb ff ff e8 ff fd d6 fe <0f> 0b e8 f8 fd d6 fe 0f 0b e8 f1 fd d6 fe 48 8b b5 50 ff ff ff 4c RSP: 0018:ffff888079607978 EFLAGS: 00010293 RAX: 0000000000000000 RBX: 0000000000008000 RCX: 0000000000000000 RDX: ffff88807cf10000 RSI: ffffffff82a4a081 RDI: 0000000000000003 RBP: ffff888079607a70 R08: 0000000000000001 R09: ffff88807a6d01d7 R10: ffffed100f4da03a R11: 0000000000000000 R12: ffff88800f0fb110 R13: ffff88800f0ee000 R14: ffff88800f0fb000 R15: 0000000000000001 FS: 00007f33b63c7540(0000) GS:ffff888108580000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f33b635c090 CR3: 000000000f39e005 CR4: 0000000000770ee0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 PKRU: 55555554 Call Trace: load_system_files+0x1f7f/0x3620 ntfs_fill_super+0xa01/0x1be0 mount_bdev+0x36a/0x440 ntfs_mount+0x3a/0x50 legacy_get_tree+0xfb/0x210 vfs_get_tree+0x8f/0x2f0 do_new_mount+0x30a/0x760 path_mount+0x4de/0x1880 __x64_sys_mount+0x2b3/0x340 do_syscall_64+0x38/0x90 entry_SYSCALL_64_after_hwframe+0x63/0xcd RIP: 0033:0x7f33b62ff9ea Code: 48 8b 0d a9 f4 0b 00 f7 d8 64 89 01 48 83 c8 ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 49 89 ca b8 a5 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d 76 f4 0b 00 f7 d8 64 89 01 48 RSP: 002b:00007ffd0c471aa8 EFLAGS: 00000202 ORIG_RAX: 00000000000000a5 RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007f33b62ff9ea RDX: 0000000020000000 RSI: 0000000020000100 RDI: 00007ffd0c471be0 RBP: 00007ffd0c471c60 R08: 00007ffd0c471ae0 R09: 00007ffd0c471c24 R10: 0000000000000000 R11: 0000000000000202 R12: 000055bac5afc160 R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000 Modules linked in: ---[ end trace 0000000000000000 ]--- Fix this by adding sanity check on extended system files' directory inode to ensure that it is directory, just like ntfs_extend_init() when mounting ntfs3. Link: https://lkml.kernel.org/r/20220809064730.2316892-1-chenxiaosong2@huawei.com Signed-off-by: ChenXiaoSong Cc: Anton Altaparmakov Cc: Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman commit 1d71422bd4837a6a880a32bc03299ed04caaff83 Author: Linus Walleij Date: Mon Sep 19 11:26:08 2022 +0200 ARM: dts: integrator: Tag PCI host with device_type commit 4952aa696a9f221c5e34e5961e02fca41ef67ad6 upstream. The DT parser is dependent on the PCI device being tagged as device_type = "pci" in order to parse memory ranges properly. Fix this up. Signed-off-by: Linus Walleij Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/20220919092608.813511-1-linus.walleij@linaro.org' Signed-off-by: Arnd Bergmann Signed-off-by: Greg Kroah-Hartman commit dab144c5dd075cfeba3c8ad1e975b30bfd22f0c9 Author: Aidan MacDonald Date: Fri Jun 17 13:22:54 2022 +0100 clk: ingenic-tcu: Properly enable registers before accessing timers 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 Tested-by: Paul Cercueil Fixes: 4f89e4b8f121 ("clk: ingenic: Add driver for the TCU clocks") Cc: stable@vger.kernel.org Signed-off-by: Aidan MacDonald Link: https://lore.kernel.org/r/20220617122254.738900-1-aidanmacdonald.0x0@gmail.com Signed-off-by: Stephen Boyd Signed-off-by: Greg Kroah-Hartman commit 6c5742372b2d5d36de129439e26eda05aab54652 Author: Sebastian Krzyszkowiak Date: Tue Sep 27 07:15:45 2022 -0700 Input: snvs_pwrkey - fix SNVS_HPVIDR1 register address 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 Signed-off-by: Sebastian Krzyszkowiak Reviewed-by: Mattijs Korpershoek Cc: Link: https://lore.kernel.org/r/4599101.ElGaqSPkdT@pliszka Signed-off-by: Dmitry Torokhov Signed-off-by: Greg Kroah-Hartman commit 8cf377baf0c32eca34bd8bda4798f1e934fe199f Author: Frank Wunderlich Date: Mon Sep 26 17:07:40 2022 +0200 net: usb: qmi_wwan: Add new usb-id for Dell branded EM7455 commit 797666cd5af041ffb66642fff62f7389f08566a2 upstream. Add support for Dell 5811e (EM7455) with USB-id 0x413c:0x81c2. Signed-off-by: Frank Wunderlich Cc: stable@vger.kernel.org Acked-by: Bjørn Mork Link: https://lore.kernel.org/r/20220926150740.6684-3-linux@fw-web.de Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 0695e590de3c0ccec993430458728e748c27eb30 Author: Mario Limonciello Date: Wed Sep 21 09:54:32 2022 -0500 thunderbolt: Explicitly reset plug events delay back to USB4 spec value 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 Signed-off-by: Mika Westerberg Signed-off-by: Greg Kroah-Hartman commit efdff533946284ed013f8e062be66e57463304bf Author: Heikki Krogerus Date: Thu Sep 22 17:59:24 2022 +0300 usb: typec: ucsi: Remove incorrect warning 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 Cc: Signed-off-by: Heikki Krogerus Link: https://lore.kernel.org/r/20220922145924.80667-1-heikki.krogerus@linux.intel.com Signed-off-by: Greg Kroah-Hartman commit e5ee7b77ac9b1fe459eba7a389b80b1feb527334 Author: Hongling Zeng Date: Fri Sep 23 10:46:35 2022 +0800 uas: ignore UAS for Thinkplus chips 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] [] schedule+0x35/0x80 [ 720.586137][13] [] schedule_preempt_disabled+0xe/0x10 [ 720.593623][13] [] __mutex_lock_slowpath+0x164/0x1e0 [ 720.601012][13] [] mutex_lock+0x2f/0x40 [ 720.607141][13] [] 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 Cc: stable Signed-off-by: Hongling Zeng Link: https://lore.kernel.org/r/1663902249837086.19.seg@mailgw Signed-off-by: Greg Kroah-Hartman commit 5f91ceea6c146ea78c25a45fefa0b361410b1f99 Author: Hongling Zeng Date: Fri Sep 23 10:46:25 2022 +0800 usb-storage: Add Hiksemi USB3-FW to IGNORE_UAS 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 Cc: stable Signed-off-by: Hongling Zeng Link: https://lore.kernel.org/r/1663901185-21067-1-git-send-email-zenghongling@kylinos.cn Signed-off-by: Greg Kroah-Hartman commit 1e4b856fc0bba4cebea5a7ab3ed2de52bcaf91cb Author: Hongling Zeng Date: Fri Sep 23 10:46:13 2022 +0800 uas: add no-uas quirk for Hiksemi usb_disk 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 Cc: stable Signed-off-by: Hongling Zeng Link: https://lore.kernel.org/r/1663901173-21020-1-git-send-email-zenghongling@kylinos.cn Signed-off-by: Greg Kroah-Hartman commit 6ac5b52e3f352f9cb270c89e6e1d4dadb564ddb8 Author: Filipe Manana Date: Thu Sep 8 12:31:51 2022 +0100 btrfs: fix hang during unmount when stopping a space reclaim worker [ Upstream commit a362bb864b8db4861977d00bd2c3222503ccc34b ] Often when running generic/562 from fstests we can hang during unmount, resulting in a trace like this: Sep 07 11:52:00 debian9 unknown: run fstests generic/562 at 2022-09-07 11:52:00 Sep 07 11:55:32 debian9 kernel: INFO: task umount:49438 blocked for more than 120 seconds. Sep 07 11:55:32 debian9 kernel: Not tainted 6.0.0-rc2-btrfs-next-122 #1 Sep 07 11:55:32 debian9 kernel: "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. Sep 07 11:55:32 debian9 kernel: task:umount state:D stack: 0 pid:49438 ppid: 25683 flags:0x00004000 Sep 07 11:55:32 debian9 kernel: Call Trace: Sep 07 11:55:32 debian9 kernel: Sep 07 11:55:32 debian9 kernel: __schedule+0x3c8/0xec0 Sep 07 11:55:32 debian9 kernel: ? rcu_read_lock_sched_held+0x12/0x70 Sep 07 11:55:32 debian9 kernel: schedule+0x5d/0xf0 Sep 07 11:55:32 debian9 kernel: schedule_timeout+0xf1/0x130 Sep 07 11:55:32 debian9 kernel: ? lock_release+0x224/0x4a0 Sep 07 11:55:32 debian9 kernel: ? lock_acquired+0x1a0/0x420 Sep 07 11:55:32 debian9 kernel: ? trace_hardirqs_on+0x2c/0xd0 Sep 07 11:55:32 debian9 kernel: __wait_for_common+0xac/0x200 Sep 07 11:55:32 debian9 kernel: ? usleep_range_state+0xb0/0xb0 Sep 07 11:55:32 debian9 kernel: __flush_work+0x26d/0x530 Sep 07 11:55:32 debian9 kernel: ? flush_workqueue_prep_pwqs+0x140/0x140 Sep 07 11:55:32 debian9 kernel: ? trace_clock_local+0xc/0x30 Sep 07 11:55:32 debian9 kernel: __cancel_work_timer+0x11f/0x1b0 Sep 07 11:55:32 debian9 kernel: ? close_ctree+0x12b/0x5b3 [btrfs] Sep 07 11:55:32 debian9 kernel: ? __trace_bputs+0x10b/0x170 Sep 07 11:55:32 debian9 kernel: close_ctree+0x152/0x5b3 [btrfs] Sep 07 11:55:32 debian9 kernel: ? evict_inodes+0x166/0x1c0 Sep 07 11:55:32 debian9 kernel: generic_shutdown_super+0x71/0x120 Sep 07 11:55:32 debian9 kernel: kill_anon_super+0x14/0x30 Sep 07 11:55:32 debian9 kernel: btrfs_kill_super+0x12/0x20 [btrfs] Sep 07 11:55:32 debian9 kernel: deactivate_locked_super+0x2e/0xa0 Sep 07 11:55:32 debian9 kernel: cleanup_mnt+0x100/0x160 Sep 07 11:55:32 debian9 kernel: task_work_run+0x59/0xa0 Sep 07 11:55:32 debian9 kernel: exit_to_user_mode_prepare+0x1a6/0x1b0 Sep 07 11:55:32 debian9 kernel: syscall_exit_to_user_mode+0x16/0x40 Sep 07 11:55:32 debian9 kernel: do_syscall_64+0x48/0x90 Sep 07 11:55:32 debian9 kernel: entry_SYSCALL_64_after_hwframe+0x63/0xcd Sep 07 11:55:32 debian9 kernel: RIP: 0033:0x7fcde59a57a7 Sep 07 11:55:32 debian9 kernel: RSP: 002b:00007ffe914217c8 EFLAGS: 00000246 ORIG_RAX: 00000000000000a6 Sep 07 11:55:32 debian9 kernel: RAX: 0000000000000000 RBX: 00007fcde5ae8264 RCX: 00007fcde59a57a7 Sep 07 11:55:32 debian9 kernel: RDX: 0000000000000000 RSI: 0000000000000000 RDI: 000055b57556cdd0 Sep 07 11:55:32 debian9 kernel: RBP: 000055b57556cba0 R08: 0000000000000000 R09: 00007ffe91420570 Sep 07 11:55:32 debian9 kernel: R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000 Sep 07 11:55:32 debian9 kernel: R13: 000055b57556cdd0 R14: 000055b57556ccb8 R15: 0000000000000000 Sep 07 11:55:32 debian9 kernel: What happens is the following: 1) The cleaner kthread tries to start a transaction to delete an unused block group, but the metadata reservation can not be satisfied right away, so a reservation ticket is created and it starts the async metadata reclaim task (fs_info->async_reclaim_work); 2) Writeback for all the filler inodes with an i_size of 2K starts (generic/562 creates a lot of 2K files with the goal of filling metadata space). We try to create an inline extent for them, but we fail when trying to insert the inline extent with -ENOSPC (at cow_file_range_inline()) - since this is not critical, we fallback to non-inline mode (back to cow_file_range()), reserve extents, create extent maps and create the ordered extents; 3) An unmount starts, enters close_ctree(); 4) The async reclaim task is flushing stuff, entering the flush states one by one, until it reaches RUN_DELAYED_IPUTS. There it runs all current delayed iputs. After running the delayed iputs and before calling btrfs_wait_on_delayed_iputs(), one or more ordered extents complete, and btrfs_add_delayed_iput() is called for each one through btrfs_finish_ordered_io() -> btrfs_put_ordered_extent(). This results in bumping fs_info->nr_delayed_iputs from 0 to some positive value. So the async reclaim task blocks at btrfs_wait_on_delayed_iputs() waiting for fs_info->nr_delayed_iputs to become 0; 5) The current transaction is committed by the transaction kthread, we then start unpinning extents and end up calling btrfs_try_granting_tickets() through unpin_extent_range(), since we released some space. This results in satisfying the ticket created by the cleaner kthread at step 1, waking up the cleaner kthread; 6) At close_ctree() we ask the cleaner kthread to park; 7) The cleaner kthread starts the transaction, deletes the unused block group, and then calls kthread_should_park(), which returns true, so it parks. And at this point we have the delayed iputs added by the completion of the ordered extents still pending; 8) Then later at close_ctree(), when we call: cancel_work_sync(&fs_info->async_reclaim_work); We hang forever, since the cleaner was parked and no one else can run delayed iputs after that, while the reclaim task is waiting for the remaining delayed iputs to be completed. Fix this by waiting for all ordered extents to complete and running the delayed iputs before attempting to stop the async reclaim tasks. Note that we can not wait for ordered extents with btrfs_wait_ordered_roots() (or other similar functions) because that waits for the BTRFS_ORDERED_COMPLETE flag to be set on an ordered extent, but the delayed iput is added after that, when doing the final btrfs_put_ordered_extent(). So instead wait for the work queues used for executing ordered extent completion to be empty, which works because we do the final put on an ordered extent at btrfs_finish_ordered_io() (while we are in the unmount context). Fixes: d6fd0ae25c6495 ("Btrfs: fix missing delayed iputs on unmount") CC: stable@vger.kernel.org # 5.15+ Reviewed-by: Josef Bacik Signed-off-by: Filipe Manana Signed-off-by: David Sterba Signed-off-by: Sasha Levin commit 29d849c3de5775185bddfce7fd7c57b7c37c2e7d Author: Mohan Kumar Date: Tue Sep 13 12:28:18 2022 +0530 ALSA: hda: Fix Nvidia dp infoframe [ Upstream commit f89e409402e2aeb3bc3aa44d2b7a597959e4e6af ] Nvidia HDA HW expects infoframe data bytes order same for both HDMI and DP i.e infoframe data starts from 5th bytes offset. As dp infoframe structure has 4th byte as valid infoframe data, use hdmi infoframe structure for nvidia dp infoframe to match HW behvaior. Signed-off-by: Mohan Kumar Cc: Link: https://lore.kernel.org/r/20220913065818.13015-1-mkumard@nvidia.com Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit 24070d32c6ecec3a008553ca56e6a03ffa2aee89 Author: Hui Wang Date: Mon Mar 1 19:12:02 2021 +0800 ALSA: hda/hdmi: let new platforms assign the pcm slot dynamically [ Upstream commit 13046370c4d143b629adc1a51659a8a6497fbbe6 ] If the platform set the dyn_pcm_assign to true, it will call hdmi_find_pcm_slot() to find a pcm slot when hdmi/dp monitor is connected and need to create a pcm. So far only intel_hsw_common_init() and patch_nvhdmi() set the dyn_pcm_assign to true, here we let tgl platforms assign the pcm slot dynamically first, if the driver runs for a period of time and there is no regression reported, we could set no_fixed_assgin to true in the intel_hsw_common_init(), and then set it to true in the patch_nvhdmi(). This change comes from the discussion between Takashi and Kai Vehmanen. Please refer to: https://github.com/alsa-project/alsa-lib/pull/118 Suggested-and-reviewed-by: Takashi Iwai Suggested-and-reviewed-by: Kai Vehmanen Signed-off-by: Hui Wang Link: https://lore.kernel.org/r/20210301111202.2684-1-hui.wang@canonical.com Signed-off-by: Takashi Iwai Stable-dep-of: f89e409402e2 ("ALSA: hda: Fix Nvidia dp infoframe") Signed-off-by: Sasha Levin commit c1256c531d6733bda3397e7428bcef2a9ad9dd1a Author: Dmitry Osipenko Date: Wed Jan 20 03:31:50 2021 +0300 ALSA: hda/tegra: Reset hardware [ Upstream commit 87f0e46e7559beb6f1d1ff99f8f48b1b9d86db52 ] Reset hardware on RPM-resume in order to bring it into a predictable state. Tested-by: Peter Geis # Ouya T30 audio works Tested-by: Matt Merhar # Ouya T30 boot-tested Tested-by: Nicolas Chauvet # TK1 boot-tested Signed-off-by: Dmitry Osipenko Link: https://lore.kernel.org/r/20210120003154.26749-3-digetx@gmail.com Signed-off-by: Takashi Iwai Stable-dep-of: f89e409402e2 ("ALSA: hda: Fix Nvidia dp infoframe") Signed-off-by: Sasha Levin commit ded9e8964d0020bad431d8f1a7cc9a776a9ff5dc Author: Dmitry Osipenko Date: Wed Jan 20 03:31:49 2021 +0300 ALSA: hda/tegra: Use clk_bulk helpers [ Upstream commit 3a465f027a33cbd2af74f882ad41729583195e8f ] Use clk_bulk helpers to make code cleaner. Note that this patch changed the order in which clocks are enabled to make code look nicer, but this doesn't matter in terms of hardware. Tested-by: Peter Geis # Ouya T30 audio works Tested-by: Matt Merhar # Ouya T30 boot-tested Tested-by: Nicolas Chauvet # TK1 boot-tested Acked-by: Thierry Reding Signed-off-by: Dmitry Osipenko Link: https://lore.kernel.org/r/20210120003154.26749-2-digetx@gmail.com Signed-off-by: Takashi Iwai Stable-dep-of: f89e409402e2 ("ALSA: hda: Fix Nvidia dp infoframe") Signed-off-by: Sasha Levin commit b2ad53fbc0e16771f393cb14ca0aeb25101eae60 Author: Gil Fine Date: Thu Sep 8 13:43:20 2022 +0300 thunderbolt: Add support for Intel Maple Ridge single port controller [ Upstream commit 14c7d905283744809e6b82efae2f490660a11cda ] Add support for Maple Ridge discrete USB4 host controller from Intel which has a single USB4 port (versus the already supported dual port Maple Ridge USB4 host controller). Cc: stable@vger.kernel.org Signed-off-by: Gil Fine Signed-off-by: Mika Westerberg Signed-off-by: Sasha Levin commit 53e6282dde62be35ed311a41bbdf2372aedc8430 Author: Mika Westerberg Date: Fri Jan 31 19:24:30 2020 +0300 thunderbolt: Add support for Intel Maple Ridge [ Upstream commit db0746e3399ee87ee5f957880811da16faa89fb8 ] Maple Ridge is first discrete USB4 host controller from Intel. It comes with firmware based connection manager and the flows are similar as used in Intel Titan Ridge. Signed-off-by: Mika Westerberg Stable-dep-of: 14c7d9052837 ("thunderbolt: Add support for Intel Maple Ridge single port controller") Signed-off-by: Sasha Levin