summaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2023-03-30ARM: dts: imx6sll: e60k02: fix usbotg1 pinctrlPeng Fan1-0/+1
[ Upstream commit 957c04e9784c7c757e8cc293d7fb2a60cdf461b6 ] usb@2184000: 'pinctrl-0' is a dependency of 'pinctrl-names' Signed-off-by: Peng Fan <peng.fan@nxp.com> Fixes: c100ea86e6ab ("ARM: dts: add Netronix E60K02 board common file") Signed-off-by: Shawn Guo <shawnguo@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-03-30ARM: dts: imx6sll: e70k02: fix usbotg1 pinctrlPeng Fan1-0/+1
[ Upstream commit 3d37f7685d525e58674c23d607020e66d501dcd1 ] usb@2184000: 'pinctrl-0' is a dependency of 'pinctrl-names' Signed-off-by: Peng Fan <peng.fan@nxp.com> Fixes: 3bb3fd856505 ("ARM: dts: add Netronix E70K02 board common file") Signed-off-by: Shawn Guo <shawnguo@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-03-30arm64: dts: imx8dxl-evk: Fix eqos phy reset gpioAndrew Halaney1-2/+3
[ Upstream commit feafeb53140af3cde3fba46b292b15b3a0c0635c ] The deprecated property is named snps,reset-gpio, but this devicetree used snps,reset-gpios instead which results in the reset not being used and the following make dtbs_check error: ./arch/arm64/boot/dts/freescale/imx8dxl-evk.dtb: ethernet@5b050000: 'snps,reset-gpio' is a dependency of 'snps,reset-delays-us' From schema: ./Documentation/devicetree/bindings/net/snps,dwmac.yaml Use the preferred method of defining the reset gpio in the phy node itself. Note that this drops the 10 us pre-delay, but prior this wasn't used at all and a pre-delay doesn't make much sense in this context so it should be fine. Fixes: 8dd495d12374 ("arm64: dts: freescale: add support for i.MX8DXL EVK board") Signed-off-by: Andrew Halaney <ahalaney@redhat.com> Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Signed-off-by: Shawn Guo <shawnguo@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-03-30arm64: dts: imx8dxl-evk: Disable hibernation mode of AR8031 for EQOSWei Fang1-0/+1
[ Upstream commit 0deefb5bd1382aae0aed7c8b266d5088a5308a26 ] The hibernation mode of AR8031 PHY defaults to be enabled after hardware reset. When the cable is unplugged, the PHY will enter hibernation mode after about 10 senconds and the PHY clocks will be stopped to save power. However, due to the design of EQOS, the mac needs the RX_CLK of PHY for software reset to complete. Otherwise the software reset of EQOS will be failed and do not work correctly. The only way is to disable hibernation mode of AR8031 PHY for EQOS, the "qca,disable-hibernation-mode" property is used for this purpose and has already been submitted to the upstream, for more details please refer to the below link: https://lore.kernel.org/netdev/20220818030054.1010660-2-wei.fang@nxp.com/ This issue is easy to reproduce, just unplug the cable and "ifconfig eth0 down", after about 10 senconds, then "ifconfig eth0 up", you will see failure log on the serial port. The log is shown as following: root@imx8dxlevk:~# [34.941970] imx-dwmac 5b050000.ethernet eth0: Link is Down root@imx8dxlevk:~# ifconfig eth0 down [35.437814] imx-dwmac 5b050000.ethernet eth0: FPE workqueue stop [35.507913] imx-dwmac 5b050000.ethernet eth0: PHY [stmmac-1:00] driver [Qualcomm Atheros AR8031/AR8033] (irq=POLL) [35.518613] imx-dwmac 5b050000.ethernet eth0: configuring for phy/rgmii-id link mode root@imx8dxlevk:~# ifconfig eth0 up [71.143044] imx-dwmac 5b050000.ethernet eth0: Register MEM_TYPE_PAGE_POOL RxQ-0 [71.215855] imx-dwmac 5b050000.ethernet eth0: PHY [stmmac-1:00] driver [Qualcomm Atheros AR8031/AR8033] (irq=POLL) [72.230417] imx-dwmac 5b050000.ethernet: Failed to reset the dma [72.236512] imx-dwmac 5b050000.ethernet eth0: stmmac_hw_setup: DMA engine initialization failed [72.245258] imx-dwmac 5b050000.ethernet eth0: __stmmac_open: Hw setup failed SIOCSIFFLAGS: Connection timed out After applying this patch, the software reset of EQOS will be successful. And the log is shown as below. root@imx8dxlevk:~# ifconfig eth0 up [96.114344] imx-dwmac 5b050000.ethernet eth0: Register MEM_TYPE_PAGE_POOL RxQ-0 [96.171466] imx-dwmac 5b050000.ethernet eth0: PHY [stmmac-1:00] driver [Qualcomm Atheros AR8031/AR8033] (irq=POLL) [96.188883] imx-dwmac 5b050000.ethernet eth0: No Safety Features support found [96.196221] imx-dwmac 5b050000.ethernet eth0: IEEE 1588-2008 Advanced Timestamp supported [96.204846] imx-dwmac 5b050000.ethernet eth0: registered PTP clock [96.225558] imx-dwmac 5b050000.ethernet eth0: FPE workqueue start [96.236858] imx-dwmac 5b050000.ethernet eth0: configuring for phy/rgmii-id link mode [96.249358] 8021q: adding VLAN 0 to HW filter on device eth0 Signed-off-by: Wei Fang <wei.fang@nxp.com> Reviewed-by: Clark Wang <xiaoning.wang@nxp.com> Signed-off-by: Shawn Guo <shawnguo@kernel.org> Stable-dep-of: feafeb53140a ("arm64: dts: imx8dxl-evk: Fix eqos phy reset gpio") Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-03-30efi: earlycon: Reprobe after parsing config tablesArd Biesheuvel3-3/+17
[ Upstream commit 8b3a149db461d3286d1e211112de3b44ccaeaf71 ] Commit 732ea9db9d8a ("efi: libstub: Move screen_info handling to common code") reorganized the earlycon handling so that all architectures pass the screen_info data via a EFI config table instead of populating struct screen_info directly, as the latter is only possible when the EFI stub is baked into the kernel (and not into the decompressor). However, this means that struct screen_info may not have been populated yet by the time the earlycon probe takes place, and this results in a non-functional early console. So let's probe again right after parsing the config tables and populating struct screen_info. Note that this means that earlycon output starts a bit later than before, and so it may fail to capture issues that occur while doing the early EFI initialization. Fixes: 732ea9db9d8a ("efi: libstub: Move screen_info handling to common code") Reported-by: Shawn Guo <shawn.guo@linaro.org> Tested-by: Shawn Guo <shawn.guo@linaro.org> Signed-off-by: Ard Biesheuvel <ardb@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-03-30wifi: mt76: connac: do not check WED status for non-mmio devicesLorenzo Bianconi1-0/+3
[ Upstream commit 5683e1488aa9b0805a9403d215e48fed29d6d923 ] WED is supported just for mmio devices, so do not check it for usb or sdio devices. This patch fixes the crash reported below: [ 21.946627] wlp0s3u1i3: authenticate with c4:41:1e:f5:2b:1d [ 22.525298] wlp0s3u1i3: send auth to c4:41:1e:f5:2b:1d (try 1/3) [ 22.548274] wlp0s3u1i3: authenticate with c4:41:1e:f5:2b:1d [ 22.557694] wlp0s3u1i3: send auth to c4:41:1e:f5:2b:1d (try 1/3) [ 22.565885] wlp0s3u1i3: authenticated [ 22.569502] wlp0s3u1i3: associate with c4:41:1e:f5:2b:1d (try 1/3) [ 22.578966] wlp0s3u1i3: RX AssocResp from c4:41:1e:f5:2b:1d (capab=0x11 status=30 aid=3) [ 22.579113] wlp0s3u1i3: c4:41:1e:f5:2b:1d rejected association temporarily; comeback duration 1000 TU (1024 ms) [ 23.649518] wlp0s3u1i3: associate with c4:41:1e:f5:2b:1d (try 2/3) [ 23.752528] wlp0s3u1i3: RX AssocResp from c4:41:1e:f5:2b:1d (capab=0x11 status=0 aid=3) [ 23.797450] wlp0s3u1i3: associated [ 24.959527] kernel tried to execute NX-protected page - exploit attempt? (uid: 0) [ 24.959640] BUG: unable to handle page fault for address: ffff88800c223200 [ 24.959706] #PF: supervisor instruction fetch in kernel mode [ 24.959788] #PF: error_code(0x0011) - permissions violation [ 24.959846] PGD 2c01067 P4D 2c01067 PUD 2c02067 PMD c2a8063 PTE 800000000c223163 [ 24.959957] Oops: 0011 [#1] PREEMPT SMP [ 24.960009] CPU: 0 PID: 391 Comm: wpa_supplicant Not tainted 6.2.0-kvm #18 [ 24.960089] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.1-2.fc37 04/01/2014 [ 24.960191] RIP: 0010:0xffff88800c223200 [ 24.960446] RSP: 0018:ffffc90000ff7698 EFLAGS: 00010282 [ 24.960513] RAX: ffff888028397010 RBX: ffff88800c26e630 RCX: 0000000000000058 [ 24.960598] RDX: ffff88800c26f844 RSI: 0000000000000006 RDI: ffff888028397010 [ 24.960682] RBP: ffff88800ea72f00 R08: 18b873fbab2b964c R09: be06b38235f3c63c [ 24.960766] R10: 18b873fbab2b964c R11: be06b38235f3c63c R12: 0000000000000001 [ 24.960853] R13: ffff88800c26f84c R14: ffff8880063f0ff8 R15: ffff88800c26e644 [ 24.960950] FS: 00007effcea327c0(0000) GS:ffff88807dc00000(0000) knlGS:0000000000000000 [ 24.961036] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 24.961106] CR2: ffff88800c223200 CR3: 000000000eaa2000 CR4: 00000000000006b0 [ 24.961190] Call Trace: [ 24.961219] <TASK> [ 24.961245] ? mt76_connac_mcu_add_key+0x2cf/0x310 [ 24.961313] ? mt7921_set_key+0x150/0x200 [ 24.961365] ? drv_set_key+0xa9/0x1b0 [ 24.961418] ? ieee80211_key_enable_hw_accel+0xd9/0x240 [ 24.961485] ? ieee80211_key_replace+0x3f3/0x730 [ 24.961541] ? crypto_shash_setkey+0x89/0xd0 [ 24.961597] ? ieee80211_key_link+0x2d7/0x3a0 [ 24.961664] ? crypto_aead_setauthsize+0x31/0x50 [ 24.961730] ? sta_info_hash_lookup+0xa6/0xf0 [ 24.961785] ? ieee80211_add_key+0x1fc/0x250 [ 24.961842] ? rdev_add_key+0x41/0x140 [ 24.961882] ? nl80211_parse_key+0x6c/0x2f0 [ 24.961940] ? nl80211_new_key+0x24a/0x290 [ 24.961984] ? genl_rcv_msg+0x36c/0x3a0 [ 24.962036] ? rdev_mod_link_station+0xe0/0xe0 [ 24.962102] ? nl80211_set_key+0x410/0x410 [ 24.962143] ? nl80211_pre_doit+0x200/0x200 [ 24.962187] ? genl_bind+0xc0/0xc0 [ 24.962217] ? netlink_rcv_skb+0xaa/0xd0 [ 24.962259] ? genl_rcv+0x24/0x40 [ 24.962300] ? netlink_unicast+0x224/0x2f0 [ 24.962345] ? netlink_sendmsg+0x30b/0x3d0 [ 24.962388] ? ____sys_sendmsg+0x109/0x1b0 [ 24.962388] ? ____sys_sendmsg+0x109/0x1b0 [ 24.962440] ? __import_iovec+0x2e/0x110 [ 24.962482] ? ___sys_sendmsg+0xbe/0xe0 [ 24.962525] ? mod_objcg_state+0x25c/0x330 [ 24.962576] ? __dentry_kill+0x19e/0x1d0 [ 24.962618] ? call_rcu+0x18f/0x270 [ 24.962660] ? __dentry_kill+0x19e/0x1d0 [ 24.962702] ? __x64_sys_sendmsg+0x70/0x90 [ 24.962744] ? do_syscall_64+0x3d/0x80 [ 24.962796] ? exit_to_user_mode_prepare+0x1b/0x70 [ 24.962852] ? entry_SYSCALL_64_after_hwframe+0x46/0xb0 [ 24.962913] </TASK> [ 24.962939] Modules linked in: [ 24.962981] CR2: ffff88800c223200 [ 24.963022] ---[ end trace 0000000000000000 ]--- [ 24.963087] RIP: 0010:0xffff88800c223200 [ 24.963323] RSP: 0018:ffffc90000ff7698 EFLAGS: 00010282 [ 24.963376] RAX: ffff888028397010 RBX: ffff88800c26e630 RCX: 0000000000000058 [ 24.963458] RDX: ffff88800c26f844 RSI: 0000000000000006 RDI: ffff888028397010 [ 24.963538] RBP: ffff88800ea72f00 R08: 18b873fbab2b964c R09: be06b38235f3c63c [ 24.963622] R10: 18b873fbab2b964c R11: be06b38235f3c63c R12: 0000000000000001 [ 24.963705] R13: ffff88800c26f84c R14: ffff8880063f0ff8 R15: ffff88800c26e644 [ 24.963788] FS: 00007effcea327c0(0000) GS:ffff88807dc00000(0000) knlGS:0000000000000000 [ 24.963871] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 24.963941] CR2: ffff88800c223200 CR3: 000000000eaa2000 CR4: 00000000000006b0 [ 24.964018] note: wpa_supplicant[391] exited with irqs disabled Fixes: d1369e515efe ("wifi: mt76: connac: introduce mt76_connac_mcu_sta_wed_update utility routine") Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org> Acked-by: Felix Fietkau <nbd@nbd.name> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/c42168429453474213fa8244bf4b069de4531f40.1678124335.git.lorenzo@kernel.org Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-03-30wifi: mt76: do not run mt76_unregister_device() on unregistered hwLorenzo Bianconi2-0/+9
[ Upstream commit 41130c32f3a18fcc930316da17f3a5f3bc326aa1 ] Trying to probe a mt7921e pci card without firmware results in a successful probe where ieee80211_register_hw hasn't been called. When removing the driver, ieee802111_unregister_hw is called unconditionally leading to a kernel NULL pointer dereference. Fix the issue running mt76_unregister_device routine just for registered hw. Link: https://bugs.debian.org/1029116 Link: https://bugs.kali.org/view.php?id=8140 Reported-by: Stuart Hayhurst <stuart.a.hayhurst@gmail.com> Fixes: 1c71e03afe4b ("mt76: mt7921: move mt7921_init_hw in a dedicated work") Tested-by: Helmut Grohne <helmut@freexian.com> Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/be3457d82f4e44bb71a22b2b5db27b644a37b1e1.1677107277.git.lorenzo@kernel.org Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-03-30power: supply: da9150: Fix use after free bug in da9150_charger_remove due ↵Zheng Wang1-0/+1
to race condition [ Upstream commit 06615d11cc78162dfd5116efb71f29eb29502d37 ] In da9150_charger_probe, &charger->otg_work is bound with da9150_charger_otg_work. da9150_charger_otg_ncb may be called to start the work. If we remove the module which will call da9150_charger_remove to make cleanup, there may be a unfinished work. The possible sequence is as follows: Fix it by canceling the work before cleanup in the da9150_charger_remove CPU0 CPUc1 |da9150_charger_otg_work da9150_charger_remove | power_supply_unregister | device_unregister | power_supply_dev_release| kfree(psy) | | | power_supply_changed(charger->usb); | //use Fixes: c1a281e34dae ("power: Add support for DA9150 Charger") Signed-off-by: Zheng Wang <zyytlz.wz@163.com> Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-03-30power: supply: bq24190: Fix use after free bug in bq24190_remove due to race ↵Zheng Wang1-0/+1
condition [ Upstream commit 47c29d69212911f50bdcdd0564b5999a559010d4 ] In bq24190_probe, &bdi->input_current_limit_work is bound with bq24190_input_current_limit_work. When external power changed, it will call bq24190_charger_external_power_changed to start the work. If we remove the module which will call bq24190_remove to make cleanup, there may be a unfinished work. The possible sequence is as follows: CPU0 CPUc1 |bq24190_input_current_limit_work bq24190_remove | power_supply_unregister | device_unregister | power_supply_dev_release| kfree(psy) | | | power_supply_get_property_from_supplier | //use Fix it by finishing the work before cleanup in the bq24190_remove Fixes: 97774672573a ("power_supply: Initialize changed_work before calling device_add") Signed-off-by: Zheng Wang <zyytlz.wz@163.com> Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-03-30arm64: dts: qcom: sm8450: Mark UFS controller as cache coherentManivannan Sadhasivam1-0/+1
[ Upstream commit 8ba961d4339c5db0e69ff6627606fe1f34c838e5 ] The UFS controller on SM8450 supports cache coherency, hence add the "dma-coherent" property to mark it as such. Fixes: 07fa917a335e ("arm64: dts: qcom: sm8450: add ufs nodes") Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org> Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org> Signed-off-by: Bjorn Andersson <andersson@kernel.org> Link: https://lore.kernel.org/r/20230307153201.180626-2-manivannan.sadhasivam@linaro.org Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-03-30arm64: dts: qcom: sm8450: correct WSA2 assigned clocksKrzysztof Kozlowski1-2/+2
[ Upstream commit 6df6fab9320bc9ebdf50136a01e7bf0ee5984c62 ] The WSA2 assigned-clocks were copied from WSA, but the WSA2 uses its own. Fixes: 14341e76dbc7 ("arm64: dts: qcom: sm8450: add Soundwire and LPASS") Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Reviewed-by: Konrad Dybcio <konrad.dybcio@linaro.org> Signed-off-by: Bjorn Andersson <andersson@kernel.org> Link: https://lore.kernel.org/r/20230308123129.232642-1-krzysztof.kozlowski@linaro.org Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-03-30arm64: dts: qcom: sm6375: Add missing power-domain-named to CDSPKonrad Dybcio1-0/+1
[ Upstream commit 11d5e41f5e129e39bddedc7244a0946a802d2e8e ] This was omitted when first introducing the node. Fix it. Fixes: fe6fd26aeddf ("arm64: dts: qcom: sm6375: Add ADSP&CDSP") Signed-off-by: Konrad Dybcio <konrad.dybcio@linaro.org> Signed-off-by: Bjorn Andersson <andersson@kernel.org> Link: https://lore.kernel.org/r/20230109135647.339224-5-konrad.dybcio@linaro.org Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-03-30arm64: dts: qcom: sc8280xp: Add label property to vadc channel nodesManivannan Sadhasivam1-0/+13
[ Upstream commit 8013295662f55696e5953ef14c31ba03721adf8f ] For uniquely identifying the vadc channels, label property has to be used. The initial commit adding vadc support assumed that the driver will use the unit address along with the node name to identify the channels. But this assumption is now broken by, commit 701c875aded8 ("iio: adc: qcom-spmi-adc5: Fix the channel name") that stripped unit address from channel names. This results in probe failure of the vadc driver: [ 8.380370] iio iio:device0: tried to double register : in_temp_pmic-die-temp_input [ 8.380383] qcom-spmi-adc5 c440000.spmi:pmic@0:adc@3100: Failed to register sysfs interfaces [ 8.380386] qcom-spmi-adc5: probe of c440000.spmi:pmic@0:adc@3100 failed with error -16 Hence, let's get rid of the assumption about drivers and rely on label property to uniquely identify the channels. The labels are derived from the schematics for each PMIC. For internal adc channels such as die and xo, the PMIC names are used as a prefix. Fixes: 7c0151347401 ("arm64: dts: qcom: sc8280xp-x13s: Add PM8280_{1/2} ADC_TM5 channels") Fixes: 9d41cd17394a ("arm64: dts: qcom: sc8280xp-x13s: Add PMR735A VADC channel") Fixes: 3375151a7185 ("arm64: dts: qcom: sc8280xp-x13s: Add PM8280_{1/2} VADC channels") Fixes: 9a6b3042c533 ("arm64: dts: qcom: sc8280xp-x13s: Add PMK8280 VADC channels") Reported-by: Steev Klimaszewski <steev@kali.org> Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org> Signed-off-by: Bjorn Andersson <andersson@kernel.org> Link: https://lore.kernel.org/r/20230211052415.14581-1-manivannan.sadhasivam@linaro.org Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-03-30arm64: dts: freescale: imx8-ss-lsio: Fix flexspi clock orderAlexander Stein1-1/+1
[ Upstream commit fd4334a06d452ce89a0bb831b03130c51331d927 ] The correct clock order is "fspi_en" and "fspi". As they are identical just reordering the names is sufficient. Fixes: 6276d66984e9 ("arm64: dts: imx8dxl: add flexspi0 support") Signed-off-by: Alexander Stein <alexander.stein@ew.tq-group.com> Signed-off-by: Shawn Guo <shawnguo@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-03-30drm/amd/display: Fix DP MST sinks removal issueCruise Hung1-0/+9
[ Upstream commit cbd6c1b17d3b42b7935526a86ad5f66838767d03 ] [Why] In USB4 DP tunneling, it's possible to have this scenario that the path becomes unavailable and CM tears down the path a little bit late. So, in this case, the HPD is high but fails to read any DPCD register. That causes the link connection type to be set to sst. And not all sinks are removed behind the MST branch. [How] Restore the link connection type if it fails to read DPCD register. Cc: stable@vger.kernel.org Cc: Mario Limonciello <mario.limonciello@amd.com> Reviewed-by: Wenjing Liu <Wenjing.Liu@amd.com> Acked-by: Qingqing Zhuo <qingqing.zhuo@amd.com> Signed-off-by: Cruise Hung <Cruise.Hung@amd.com> Tested-by: Daniel Wheeler <daniel.wheeler@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> (cherry picked from commit cbd6c1b17d3b42b7935526a86ad5f66838767d03) Modified for stable backport as a lot of the code in this file was moved in 6.3 to drivers/gpu/drm/amd/display/dc/link/link_detection.c. Signed-off-by: Mario Limonciello <mario.limonciello@amd.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-03-30drm/amd/display: Remove OTG DIV register write for Virtual signals.Saaem Rizvi1-1/+1
[ Upstream commit 709671ffb15dcd1b4f6afe2a9d8c67c7c4ead4a1 ] [WHY] Hot plugging and then hot unplugging leads to k1 and k2 values to change, as signal is detected as a virtual signal on hot unplug. Writing these values to OTG_PIXEL_RATE_DIV register might cause primary display to blank (known hw bug). [HOW] No longer write k1 and k2 values to register if signal is virtual, we have safe guards in place in the case that k1 and k2 is unassigned so that an unknown value is not written to the register either. Cc: stable@vger.kernel.org Cc: Mario Limonciello <mario.limonciello@amd.com> Reviewed-by: Samson Tam <Samson.Tam@amd.com> Reviewed-by: Alvin Lee <Alvin.Lee2@amd.com> Acked-by: Qingqing Zhuo <qingqing.zhuo@amd.com> Signed-off-by: Saaem Rizvi <SyedSaaem.Rizvi@amd.com> Tested-by: Daniel Wheeler <daniel.wheeler@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-03-30drm/amd/display: fix k1 k2 divider programming for phantom streamsAurabindo Pillai1-2/+2
[ Upstream commit 3b214bb7185d8284d7d4c53e15127f69a375abf6 ] [Why & How] When k1 and k2 divider programming logic is executed for a phantom stream, the corresponding master stream should be used for the calculation. Fix the if condition to use the master stream for checking signal type instead of the phantom stream. Reviewed-by: Alvin Lee <Alvin.Lee2@amd.com> Acked-by: Qingqing Zhuo <qingqing.zhuo@amd.com> Signed-off-by: Aurabindo Pillai <aurabindo.pillai@amd.com> Tested-by: Daniel Wheeler <daniel.wheeler@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Stable-dep-of: 709671ffb15d ("drm/amd/display: Remove OTG DIV register write for Virtual signals.") Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-03-30tracing/hwlat: Replace sched_setaffinity with set_cpus_allowed_ptrCosta Shulyupin1-2/+2
[ Upstream commit 71c7a30442b724717a30d5e7d1662ba4904eb3d4 ] There is a problem with the behavior of hwlat in a container, resulting in incorrect output. A warning message is generated: "cpumask changed while in round-robin mode, switching to mode none", and the tracing_cpumask is ignored. This issue arises because the kernel thread, hwlatd, is not a part of the container, and the function sched_setaffinity is unable to locate it using its PID. Additionally, the task_struct of hwlatd is already known. Ultimately, the function set_cpus_allowed_ptr achieves the same outcome as sched_setaffinity, but employs task_struct instead of PID. Test case: # cd /sys/kernel/tracing # echo 0 > tracing_on # echo round-robin > hwlat_detector/mode # echo hwlat > current_tracer # unshare --fork --pid bash -c 'echo 1 > tracing_on' # dmesg -c Actual behavior: [573502.809060] hwlat_detector: cpumask changed while in round-robin mode, switching to mode none Link: https://lore.kernel.org/linux-trace-kernel/20230316144535.1004952-1-costa.shul@redhat.com Cc: Masami Hiramatsu <mhiramat@kernel.org> Fixes: 0330f7aa8ee63 ("tracing: Have hwlat trace migrate across tracing_cpumask CPUs") Signed-off-by: Costa Shulyupin <costa.shul@redhat.com> Acked-by: Daniel Bristot de Oliveira <bristot@kernel.org> Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-03-30perf: fix perf_event_context->timeSong Liu1-1/+1
[ Upstream commit baf1b12a67f5b24f395baca03e442ce27cab0c18 ] Time readers rely on perf_event_context->[time|timestamp|timeoffset] to get accurate time_enabled and time_running for an event. The difference between ctx->timestamp and ctx->time is the among of time when the context is not enabled. __update_context_time(ctx, false) is used to increase timestamp, but not time. Therefore, it should only be called in ctx_sched_in() when EVENT_TIME was not enabled. Fixes: 09f5e7dc7ad7 ("perf: Fix perf_event_read_local() time") Signed-off-by: Song Liu <song@kernel.org> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Acked-by: Namhyung Kim <namhyung@kernel.org> Link: https://lkml.kernel.org/r/20230313171608.298734-1-song@kernel.org Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-03-30perf/core: Fix perf_output_begin parameter is incorrectly invoked in ↵Yang Jihong1-1/+1
perf_event_bpf_output [ Upstream commit eb81a2ed4f52be831c9fb879752d89645a312c13 ] syzkaller reportes a KASAN issue with stack-out-of-bounds. The call trace is as follows: dump_stack+0x9c/0xd3 print_address_description.constprop.0+0x19/0x170 __kasan_report.cold+0x6c/0x84 kasan_report+0x3a/0x50 __perf_event_header__init_id+0x34/0x290 perf_event_header__init_id+0x48/0x60 perf_output_begin+0x4a4/0x560 perf_event_bpf_output+0x161/0x1e0 perf_iterate_sb_cpu+0x29e/0x340 perf_iterate_sb+0x4c/0xc0 perf_event_bpf_event+0x194/0x2c0 __bpf_prog_put.constprop.0+0x55/0xf0 __cls_bpf_delete_prog+0xea/0x120 [cls_bpf] cls_bpf_delete_prog_work+0x1c/0x30 [cls_bpf] process_one_work+0x3c2/0x730 worker_thread+0x93/0x650 kthread+0x1b8/0x210 ret_from_fork+0x1f/0x30 commit 267fb27352b6 ("perf: Reduce stack usage of perf_output_begin()") use on-stack struct perf_sample_data of the caller function. However, perf_event_bpf_output uses incorrect parameter to convert small-sized data (struct perf_bpf_event) into large-sized data (struct perf_sample_data), which causes memory overwriting occurs in __perf_event_header__init_id. Fixes: 267fb27352b6 ("perf: Reduce stack usage of perf_output_begin()") Signed-off-by: Yang Jihong <yangjihong1@huawei.com> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Link: https://lkml.kernel.org/r/20230314044735.56551-1-yangjihong1@huawei.com Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-03-30interconnect: qcom: qcm2290: Fix MASTER_SNOC_BIMC_NRTKonrad Dybcio1-2/+2
[ Upstream commit 633a12fda6536a1a17bcea29502e777e86a4547e ] Due to what seems to be a copy-paste error, the _NRT master was identical to the _RT master, which should not be the case.. Fix it using the values available from the downstream kernel [1]. [1] https://android.googlesource.com/kernel/msm-extra/devicetree/+/refs/heads/android-msm-bramble-4.19-android11-qpr1/qcom/scuba-bus.dtsi#127 Fixes: 1a14b1ac3935 ("interconnect: qcom: Add QCM2290 driver support") Signed-off-by: Konrad Dybcio <konrad.dybcio@linaro.org> Acked-by: Shawn Guo <shawn.guo@linaro.org> Link: https://lore.kernel.org/r/20230103142120.15605-1-konrad.dybcio@linaro.org Signed-off-by: Georgi Djakov <djakov@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-03-30interconnect: qcom: sm8450: switch to qcom_icc_rpmh_* functionDmitry Baryshkov1-96/+2
[ Upstream commit 87e8fab1917a2b3f6e3dedfd1cdf22a1416e6676 ] Change sm8450 interconnect driver to use generic qcom_icc_rpmh_* functions rather than embedding a copy of thema. This also fixes an overallocation of memory for icc_onecell_data structure. Fixes: fafc114a468e ("interconnect: qcom: Add SM8450 interconnect provider driver") Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Link: https://lore.kernel.org/r/20230105002221.1416479-3-dmitry.baryshkov@linaro.org Signed-off-by: Georgi Djakov <djakov@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-03-30interconnect: qcom: osm-l3: fix icc_onecell_data allocationDmitry Baryshkov1-1/+1
[ Upstream commit f77ebdda0ee652124061c2ac42399bb6c367e729 ] This is a struct with a trailing zero-length array of icc_node pointers but it's allocated as if it were a single array of icc_nodes instead. Fortunately this overallocates memory rather then allocating less memory than required. Fix by replacing devm_kcalloc() with devm_kzalloc() and struct_size() macro. Fixes: 5bc9900addaf ("interconnect: qcom: Add OSM L3 interconnect provider support") Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Link: https://lore.kernel.org/r/20230105002221.1416479-2-dmitry.baryshkov@linaro.org Signed-off-by: Georgi Djakov <djakov@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-03-22Linux 6.2.8v6.2.8Greg Kroah-Hartman1-1/+1
Link: https://lore.kernel.org/r/20230320145513.305686421@linuxfoundation.org Tested-by: Chris Paterson (CIP) <chris.paterson2@renesas.com> Tested-by: Ronald Warsow <rwarsow@gmx.de> Tested-by: Florian Fainelli <f.fainelli@gmail.com> Tested-by: Shuah Khan <skhan@linuxfoundation.org> Tested-by: Allen Pais <apais@linux.microsoft.com> Tested-by: Bagas Sanjaya <bagasdotme@gmail.com> Tested-by: Ron Economos <re@w6rz.net> Tested-by: Conor Dooley <conor.dooley@microchip.com> Tested-by: Jon Hunter <jonathanh@nvidia.com> Link: https://lore.kernel.org/r/20230321080604.493429263@linuxfoundation.org Tested-by: Markus Reichelt <lkt+2023@mareichelt.com> Tested-by: Ronald Warsow <rwarsow@gmx.de> Tested-by: Justin M. Forbes <jforbes@fedoraproject.org> Tested-by: Slade Watkins <srw@sladewatkins.net> Link: https://lore.kernel.org/r/20230321180749.921141176@linuxfoundation.org Tested-by: Ronald Warsow <rwarsow@gmx.de> Tested-by: Florian Fainelli <f.fainelli@gmail.com> Tested-by: Ron Economos <re@w6rz.net> Tested-by: Bagas Sanjaya <bagasdotme@gmail.com> Tested-by: Chris Paterson (CIP) <chris.paterson2@renesas.com> Tested-by: Linux Kernel Functional Testing <lkft@linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2023-03-22powerpc/64: Replace -mcpu=e500mc64 by -mcpu=e5500Christophe Leroy1-1/+1
commit 77e82fa1f9781a958a6ea4aed7aec41239a5a22f upstream. E500MC64 is a processor pre-dating E5500 that has never been commercialised. Use -mcpu=e5500 for E5500 core. More details at https://gcc.gnu.org/PR108149 Signed-off-by: Christophe Leroy <christophe.leroy@csgroup.eu> Acked-by: Pali Rohár <pali@kernel.org> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Link: https://lore.kernel.org/r/fa71ed20d22c156225436374f0ab847daac893bc.1671475543.git.christophe.leroy@csgroup.eu Cc: Naresh Kamboju <naresh.kamboju@linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2023-03-22powerpc: Disable CPU unknown by CLANG when CC_IS_CLANGChristophe Leroy1-0/+8
commit 4b10306e98456aed03cad75ce467e8b1efdccca0 upstream. CLANG only knows the following CPUs: generic, 440, 450, 601, 602, 603, 603e, 603ev, 604, 604e, 620, 630, g3, 7400, g4, 7450, g4+, 750, 8548, 970, g5, a2, e500, e500mc, e5500, power3, pwr3, power4, pwr4, power5, pwr5, power5x, pwr5x, power6, pwr6, power6x, pwr6x, power7, pwr7, power8, pwr8, power9, pwr9, power10, pwr10, powerpc, ppc, ppc32, powerpc64, ppc64, powerpc64le, ppc64le, futur Disable other ones when CC_IS_CLANG. Signed-off-by: Christophe Leroy <christophe.leroy@csgroup.eu> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Link: https://lore.kernel.org/r/e62892e32c14a7a5738c597e39e0082cb0abf21c.1675335659.git.christophe.leroy@csgroup.eu Cc: Nick Desaulniers <ndesaulniers@google.com> Cc: Naresh Kamboju <naresh.kamboju@linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2023-03-22perf: Fix check before add_event_to_groups() in perf_group_detach()Budimir Markovic1-1/+1
commit fd0815f632c24878e325821943edccc7fde947a2 upstream. Events should only be added to a groups rb tree if they have not been removed from their context by list_del_event(). Since remove_on_exec made it possible to call list_del_event() on individual events before they are detached from their group, perf_group_detach() should check each sibling's attach_state before calling add_event_to_groups() on it. Fixes: 2e498d0a74e5 ("perf: Add support for event removal on exec") Signed-off-by: Budimir Markovic <markovicbudimir@gmail.com> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Link: https://lkml.kernel.org/r/ZBFzvQV9tEqoHEtH@gentoo Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2023-03-22virt/coco/sev-guest: Add throttling awarenessDionna Glaze3-2/+24
commit 72f7754dcf31c87c92c0c353dcf747814cc5ce10 upstream. A potentially malicious SEV guest can constantly hammer the hypervisor using this driver to send down requests and thus prevent or at least considerably hinder other guests from issuing requests to the secure processor which is a shared platform resource. Therefore, the host is permitted and encouraged to throttle such guest requests. Add the capability to handle the case when the hypervisor throttles excessive numbers of requests issued by the guest. Otherwise, the VM platform communication key will be disabled, preventing the guest from attesting itself. Realistically speaking, a well-behaved guest should not even care about throttling. During its lifetime, it would end up issuing a handful of requests which the hardware can easily handle. This is more to address the case of a malicious guest. Such guest should get throttled and if its VMPCK gets disabled, then that's its own wrongdoing and perhaps that guest even deserves it. To the implementation: the hypervisor signals with SNP_GUEST_REQ_ERR_BUSY that the guest requests should be throttled. That error code is returned in the upper 32-bit half of exitinfo2 and this is part of the GHCB spec v2. So the guest is given a throttling period of 1 minute in which it retries the request every 2 seconds. This is a good default but if it turns out to not pan out in practice, it can be tweaked later. For safety, since the encryption algorithm in GHCBv2 is AES_GCM, control must remain in the kernel to complete the request with the current sequence number. Returning without finishing the request allows the guest to make another request but with different message contents. This is IV reuse, and breaks cryptographic protections. [ bp: - Rewrite commit message and do a simplified version. - The stable tags are supposed to denote that a cleanup should go upfront before backporting this so that any future fixes to this can preserve the sanity of the backporter(s). ] Fixes: d5af44dde546 ("x86/sev: Provide support for SNP guest request NAEs") Signed-off-by: Dionna Glaze <dionnaglaze@google.com> Co-developed-by: Borislav Petkov (AMD) <bp@alien8.de> Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de> Reviewed-by: Tom Lendacky <thomas.lendacky@amd.com> Cc: <stable@kernel.org> # d6fd48eff750 ("virt/coco/sev-guest: Check SEV_SNP attribute at probe time") Cc: <stable@kernel.org> # 970ab823743f (" virt/coco/sev-guest: Simplify extended guest request handling") Cc: <stable@kernel.org> # c5a338274bdb ("virt/coco/sev-guest: Remove the disable_vmpck label in handle_guest_request()") Cc: <stable@kernel.org> # 0fdb6cc7c89c ("virt/coco/sev-guest: Carve out the request issuing logic into a helper") Cc: <stable@kernel.org> # d25bae7dc7b0 ("virt/coco/sev-guest: Do some code style cleanups") Cc: <stable@kernel.org> # fa4ae42cc60a ("virt/coco/sev-guest: Convert the sw_exit_info_2 checking to a switch-case") Link: https://lore.kernel.org/r/20230214164638.1189804-2-dionnaglaze@google.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2023-03-22virt/coco/sev-guest: Convert the sw_exit_info_2 checking to a switch-caseBorislav Petkov (AMD)1-5/+11
commit fa4ae42cc60a7dea30e8f2db444b808d80862345 upstream. snp_issue_guest_request() checks the value returned by the hypervisor in sw_exit_info_2 and returns a different error depending on it. Convert those checks into a switch-case to make it more readable when more error values are going to be checked in the future. No functional changes. Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de> Reviewed-by: Tom Lendacky <thomas.lendacky@amd.com> Link: https://lore.kernel.org/r/20230307192449.24732-8-bp@alien8.de Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2023-03-22virt/coco/sev-guest: Do some code style cleanupsBorislav Petkov (AMD)1-6/+2
commit d25bae7dc7b0668cb2a1325c64eb32d5fea4e5a9 upstream. Remove unnecessary linebreaks, make the code more compact. No functional changes. Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de> Reviewed-by: Tom Lendacky <thomas.lendacky@amd.com> Link: https://lore.kernel.org/r/20230307192449.24732-7-bp@alien8.de Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2023-03-22virt/coco/sev-guest: Carve out the request issuing logic into a helperBorislav Petkov (AMD)1-17/+27
commit 0fdb6cc7c89cb5e0cbc45dbdbafb8e3fb92ddc95 upstream. This makes the code flow a lot easier to follow. No functional changes. [ Tom: touchups. ] Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de> Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com> Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de> Link: https://lore.kernel.org/r/20230307192449.24732-6-bp@alien8.de Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2023-03-22virt/coco/sev-guest: Remove the disable_vmpck label in handle_guest_request()Borislav Petkov (AMD)1-6/+4
commit c5a338274bdb894f088767bea856be344d0ccaef upstream. Call the function directly instead. No functional changes. Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de> Reviewed-by: Tom Lendacky <thomas.lendacky@amd.com> Link: https://lore.kernel.org/r/20230307192449.24732-5-bp@alien8.de Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2023-03-22virt/coco/sev-guest: Simplify extended guest request handlingBorislav Petkov (AMD)2-27/+32
commit 970ab823743fb54b42002ec76c51481f67436444 upstream. Return a specific error code - -ENOSPC - to signal the too small cert data buffer instead of checking exit code and exitinfo2. While at it, hoist the *fw_err assignment in snp_issue_guest_request() so that a proper error value is returned to the callers. [ Tom: check override_err instead of err. ] Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de> Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com> Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de> Link: https://lore.kernel.org/r/20230307192449.24732-4-bp@alien8.de Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2023-03-22virt/coco/sev-guest: Check SEV_SNP attribute at probe timeBorislav Petkov (AMD)2-3/+3
commit d6fd48eff7506bb866a54e40369df8899f2078a9 upstream. No need to check it on every ioctl. And yes, this is a common SEV driver but it does only SNP-specific operations currently. This can be revisited later, when more use cases appear. No functional changes. Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de> Reviewed-by: Tom Lendacky <thomas.lendacky@amd.com> Link: https://lore.kernel.org/r/20230307192449.24732-3-bp@alien8.de Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2023-03-22powerpc: Pass correct CPU reference to assemblerChristophe Leroy1-4/+0
commit bfb03af71a3798b5a88a945a9c19ad67e1c4986d upstream. Jan-Benedict reported issue with building ppc64e_defconfig with mainline GCC work: powerpc64-linux-gcc -Wp,-MMD,arch/powerpc/kernel/vdso/.gettimeofday-64.o.d -nostdinc -I./arch/powerpc/include -I./arch/powerpc/include/generated -I./include -I./arch/powerpc/include/uapi -I./arch/powerpc/include/generated/uapi -I./include/uapi -I./include/generated/uapi -include ./include/linux/compiler-version.h -include ./include/linux/kconfig.h -D__KERNEL__ -I ./arch/powerpc -DHAVE_AS_ATHIGH=1 -fmacro-prefix-map=./= -D__ASSEMBLY__ -fno-PIE -m64 -Wl,-a64 -mabi=elfv1 -Wa,-me500 -Wa,-me500mc -mabi=elfv1 -mbig-endian -Wl,-soname=linux-vdso64.so.1 -D__VDSO64__ -s -c -o arch/powerpc/kernel/vdso/gettimeofday-64.o arch/powerpc/kernel/vdso/gettimeofday.S arch/powerpc/kernel/vdso/gettimeofday.S: Assembler messages: arch/powerpc/kernel/vdso/gettimeofday.S:72: Error: unrecognized opcode: `stdu' arch/powerpc/kernel/vdso/gettimeofday.S:72: Error: unrecognized opcode: `stdu' arch/powerpc/kernel/vdso/gettimeofday.S:72: Error: unrecognized opcode: `std' arch/powerpc/kernel/vdso/gettimeofday.S:72: Error: unrecognized opcode: `std' arch/powerpc/kernel/vdso/gettimeofday.S:72: Error: unrecognized opcode: `ld' arch/powerpc/kernel/vdso/gettimeofday.S:72: Error: unrecognized opcode: `ld' ... make[1]: *** [arch/powerpc/kernel/vdso/Makefile:76: arch/powerpc/kernel/vdso/gettimeofday-64.o] Error 1 make: *** [arch/powerpc/Makefile:387: vdso_prepare] Error 2 This is due to assembler being called with -me500mc which is a 32 bits target. The problem comes from the fact that CONFIG_PPC_E500MC is selected for both the e500mc (32 bits) and the e5500 (64 bits), and therefore the following makefile rule is wrong: cpu-as-$(CONFIG_PPC_E500MC) += $(call as-option,-Wa$(comma)-me500mc) Today we have CONFIG_TARGET_CPU which provides the identification of the expected CPU, it is used for GCC. Once GCC knows the target CPU, it adds the correct CPU option to assembler, no need to add it explicitly. With that change (And also commit 45f7091aac35 ("powerpc/64: Set default CPU in Kconfig")), it now is: powerpc64-linux-gcc -Wp,-MMD,arch/powerpc/kernel/vdso/.gettimeofday-64.o.d -nostdinc -I./arch/powerpc/include -I./arch/powerpc/include/generated -I./include -I./arch/powerpc/include/uapi -I./arch/powerpc/include/generated/uapi -I./include/uapi -I./include/generated/uapi -include ./include/linux/compiler-version.h -include ./include/linux/kconfig.h -D__KERNEL__ -I ./arch/powerpc -DHAVE_AS_ATHIGH=1 -fmacro-prefix-map=./= -D__ASSEMBLY__ -fno-PIE -m64 -Wl,-a64 -mabi=elfv1 -mcpu=e500mc64 -mabi=elfv1 -mbig-endian -Wl,-soname=linux-vdso64.so.1 -D__VDSO64__ -s -c -o arch/powerpc/kernel/vdso/gettimeofday-64.o arch/powerpc/kernel/vdso/gettimeofday.S Reported-by: Jan-Benedict Glaw <jbglaw@lug-owl.de> Signed-off-by: Christophe Leroy <christophe.leroy@csgroup.eu> Acked-by: Pali Rohár <pali@kernel.org> [mpe: Retain -Wa,-mpower4 -Wa,-many for Book3S 64 builds for now] Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Link: https://lore.kernel.org/r/758ad54128fa9dd2fdedc4c511592111cbded900.1671475543.git.christophe.leroy@csgroup.eu Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2023-03-22x86/resctrl: Clear staged_config[] before and after it is usedShawn Wang3-9/+24
commit 0424a7dfe9129b93f29b277511a60e87f052ac6b upstream. As a temporary storage, staged_config[] in rdt_domain should be cleared before and after it is used. The stale value in staged_config[] could cause an MSR access error. Here is a reproducer on a system with 16 usable CLOSIDs for a 15-way L3 Cache (MBA should be disabled if the number of CLOSIDs for MB is less than 16.) : mount -t resctrl resctrl -o cdp /sys/fs/resctrl mkdir /sys/fs/resctrl/p{1..7} umount /sys/fs/resctrl/ mount -t resctrl resctrl /sys/fs/resctrl mkdir /sys/fs/resctrl/p{1..8} An error occurs when creating resource group named p8: unchecked MSR access error: WRMSR to 0xca0 (tried to write 0x00000000000007ff) at rIP: 0xffffffff82249142 (cat_wrmsr+0x32/0x60) Call Trace: <IRQ> __flush_smp_call_function_queue+0x11d/0x170 __sysvec_call_function+0x24/0xd0 sysvec_call_function+0x89/0xc0 </IRQ> <TASK> asm_sysvec_call_function+0x16/0x20 When creating a new resource control group, hardware will be configured by the following process: rdtgroup_mkdir() rdtgroup_mkdir_ctrl_mon() rdtgroup_init_alloc() resctrl_arch_update_domains() resctrl_arch_update_domains() iterates and updates all resctrl_conf_type whose have_new_ctrl is true. Since staged_config[] holds the same values as when CDP was enabled, it will continue to update the CDP_CODE and CDP_DATA configurations. When group p8 is created, get_config_index() called in resctrl_arch_update_domains() will return 16 and 17 as the CLOSIDs for CDP_CODE and CDP_DATA, which will be translated to an invalid register - 0xca0 in this scenario. Fix it by clearing staged_config[] before and after it is used. [reinette: re-order commit tags] Fixes: 75408e43509e ("x86/resctrl: Allow different CODE/DATA configurations to be staged") Suggested-by: Xin Hao <xhao@linux.alibaba.com> Signed-off-by: Shawn Wang <shawnwang@linux.alibaba.com> Signed-off-by: Reinette Chatre <reinette.chatre@intel.com> Signed-off-by: Dave Hansen <dave.hansen@linux.intel.com> Tested-by: Reinette Chatre <reinette.chatre@intel.com> Cc:stable@vger.kernel.org Link: https://lore.kernel.org/all/2fad13f49fbe89687fc40e9a5a61f23a28d1507a.1673988935.git.reinette.chatre%40intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2023-03-22x86/mm: Fix use of uninitialized buffer in sme_enable()Nikita Zhandarovich1-1/+2
commit cbebd68f59f03633469f3ecf9bea99cd6cce3854 upstream. cmdline_find_option() may fail before doing any initialization of the buffer array. This may lead to unpredictable results when the same buffer is used later in calls to strncmp() function. Fix the issue by returning early if cmdline_find_option() returns an error. Found by Linux Verification Center (linuxtesting.org) with static analysis tool SVACE. Fixes: aca20d546214 ("x86/mm: Add support to make use of Secure Memory Encryption") Signed-off-by: Nikita Zhandarovich <n.zhandarovich@fintech.ru> Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de> Acked-by: Tom Lendacky <thomas.lendacky@amd.com> Cc: <stable@kernel.org> Link: https://lore.kernel.org/r/20230306160656.14844-1-n.zhandarovich@fintech.ru Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2023-03-22x86/mce: Make sure logged MCEs are processed after sysfs updateYazen Ghannam1-0/+1
commit 4783b9cb374af02d49740e00e2da19fd4ed6dec4 upstream. A recent change introduced a flag to queue up errors found during boot-time polling. These errors will be processed during late init once the MCE subsystem is fully set up. A number of sysfs updates call mce_restart() which goes through a subset of the CPU init flow. This includes polling MCA banks and logging any errors found. Since the same function is used as boot-time polling, errors will be queued. However, the system is now past late init, so the errors will remain queued until another error is found and the workqueue is triggered. Call mce_schedule_work() at the end of mce_restart() so that queued errors are processed. Fixes: 3bff147b187d ("x86/mce: Defer processing of early errors") Signed-off-by: Yazen Ghannam <yazen.ghannam@amd.com> Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de> Reviewed-by: Tony Luck <tony.luck@intel.com> Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/20230301221420.2203184-1-yazen.ghannam@amd.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2023-03-22ASoC: qcom: q6prm: fix incorrect clk_root passed to ADSPKrzysztof Kozlowski1-2/+2
commit 65882134bc622a1e57bd5928ac588855ea2e3ddd upstream. The second to last argument is clk_root (root of the clock), however the code called q6prm_request_lpass_clock() with clk_attr instead (copy-paste error). This effectively was passing value of 1 as root clock which worked on some of the SoCs (e.g. SM8450) but fails on others, depending on the ADSP. For example on SM8550 this "1" as root clock is not accepted and results in errors coming from ADSP. Fixes: 2f20640491ed ("ASoC: qdsp6: qdsp6: q6prm: handle clk disable correctly") Cc: <stable@vger.kernel.org> Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Reviewed-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Tested-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Link: https://lore.kernel.org/r/20230302122908.221398-1-krzysztof.kozlowski@linaro.org Signed-off-by: Mark Brown <broonie@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2023-03-22ASoC: Intel: soc-acpi: fix copy-paste issue in topology namesPierre-Louis Bossart1-1/+1
commit 858a438a6cf919e5727d2a0f5f3f0e68b2d5354e upstream. For some reason the convention for topology names was not followed and the name inspired by another unrelated hardware configuration. As a result, the kernel will request a non-existent topology file. Link: https://github.com/thesofproject/sof/pull/6878 Fixes: 2ec8b081d59f ("ASoC: Intel: soc-acpi: Add entry for sof_es8336 in ADL match table") Cc: stable@vger.kernel.org Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Reviewed-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com> Reviewed-by: Bard Liao <yung-chuan.liao@linux.intel.com> Reviewed-by: Péter Ujfalusi <peter.ujfalusi@linux.intel.com> Signed-off-by: Peter Ujfalusi <peter.ujfalusi@linux.intel.com> Link: https://lore.kernel.org/r/20230307100733.15025-1-peter.ujfalusi@linux.intel.com Signed-off-by: Mark Brown <broonie@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2023-03-22cpuidle: psci: Iterate backwards over list in psci_pd_remove()Shawn Guo1-1/+2
commit 6b0313c2fa3d2cf991c9ffef6fae6e7ef592ce6d upstream. In case that psci_pd_init_topology() fails for some reason, psci_pd_remove() will be responsible for deleting provider and removing genpd from psci_pd_providers list. There will be a failure when removing the cluster PD, because the cpu (child) PDs haven't been removed. [ 0.050232] CPUidle PSCI: init PM domain cpu0 [ 0.050278] CPUidle PSCI: init PM domain cpu1 [ 0.050329] CPUidle PSCI: init PM domain cpu2 [ 0.050370] CPUidle PSCI: init PM domain cpu3 [ 0.050422] CPUidle PSCI: init PM domain cpu-cluster0 [ 0.050475] PM: genpd_remove: unable to remove cpu-cluster0 [ 0.051412] PM: genpd_remove: removed cpu3 [ 0.051449] PM: genpd_remove: removed cpu2 [ 0.051499] PM: genpd_remove: removed cpu1 [ 0.051546] PM: genpd_remove: removed cpu0 Fix the problem by iterating the provider list reversely, so that parent PD gets removed after child's PDs like below. [ 0.029052] CPUidle PSCI: init PM domain cpu0 [ 0.029076] CPUidle PSCI: init PM domain cpu1 [ 0.029103] CPUidle PSCI: init PM domain cpu2 [ 0.029124] CPUidle PSCI: init PM domain cpu3 [ 0.029151] CPUidle PSCI: init PM domain cpu-cluster0 [ 0.029647] PM: genpd_remove: removed cpu0 [ 0.029666] PM: genpd_remove: removed cpu1 [ 0.029690] PM: genpd_remove: removed cpu2 [ 0.029714] PM: genpd_remove: removed cpu3 [ 0.029738] PM: genpd_remove: removed cpu-cluster0 Fixes: a65a397f2451 ("cpuidle: psci: Add support for PM domains by using genpd") Reviewed-by: Sudeep Holla <sudeep.holla@arm.com> Reviewed-by: Ulf Hansson <ulf.hansson@linaro.org> Signed-off-by: Shawn Guo <shawn.guo@linaro.org> Cc: 5.10+ <stable@vger.kernel.org> # 5.10+ Signed-off-by: Rafael J. Wysocki <rjw@rjwysocki.net> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2023-03-22io_uring/msg_ring: let target know allocated indexPavel Begunkov1-1/+3
commit 5da28edd7bd5518f97175ecea77615bb729a7a28 upstream. msg_ring requests transferring files support auto index selection via IORING_FILE_INDEX_ALLOC, however they don't return the selected index to the target ring and there is no other good way for the userspace to know where is the receieved file. Return the index for allocated slots and 0 otherwise, which is consistent with other fixed file installing requests. Cc: stable@vger.kernel.org # v6.0+ Fixes: e6130eba8a848 ("io_uring: add support for passing fixed file descriptors") Signed-off-by: Pavel Begunkov <asml.silence@gmail.com> Link: https://github.com/axboe/liburing/issues/809 Signed-off-by: Jens Axboe <axboe@kernel.dk> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2023-03-22RISC-V: mm: Support huge page in vmalloc_fault()Dylan Jhong1-0/+5
commit 47dd902aaee9b9341808a3a994793199e7eddb88 upstream. Since RISC-V supports ioremap() with huge page (pud/pmd) mapping, However, vmalloc_fault() assumes that the vmalloc range is limited to pte mappings. To complete the vmalloc_fault() function by adding huge page support. Fixes: 310f541a027b ("riscv: Enable HAVE_ARCH_HUGE_VMAP for 64BIT") Cc: stable@vger.kernel.org Signed-off-by: Dylan Jhong <dylan@andestech.com> Reviewed-by: Alexandre Ghiti <alexghiti@rivosinc.com> Link: https://lore.kernel.org/r/20230310075021.3919290-1-dylan@andestech.com Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2023-03-22fbdev: Fix incorrect page mapping clearance at fb_deferred_io_release()Takashi Iwai2-4/+14
commit fe9ae05cfbe587dda724fcf537c00bc2f287da62 upstream. The recent fix for the deferred I/O by the commit 3efc61d95259 ("fbdev: Fix invalid page access after closing deferred I/O devices") caused a regression when the same fb device is opened/closed while it's being used. It resulted in a frozen screen even if something is redrawn there after the close. The breakage is because the patch was made under a wrong assumption of a single open; in the current code, fb_deferred_io_release() cleans up the page mapping of the pageref list and it calls cancel_delayed_work_sync() unconditionally, where both are no correct behavior for multiple opens. This patch adds a refcount for the opens of the device, and applies the cleanup only when all files get closed. As both fb_deferred_io_open() and _close() are called always in the fb_info lock (mutex), it's safe to use the normal int for the refcounting. Also, a useless BUG_ON() is dropped. Fixes: 3efc61d95259 ("fbdev: Fix invalid page access after closing deferred I/O devices") Cc: <stable@vger.kernel.org> Signed-off-by: Takashi Iwai <tiwai@suse.de> Reviewed-by: Patrik Jakobsson <patrik.r.jakobsson@gmail.com> Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Link: https://patchwork.freedesktop.org/patch/msgid/20230308105012.1845-1-tiwai@suse.de Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2023-03-22net: phy: nxp-c45-tja11xx: fix MII_BASIC_CONFIG_REV bitRadu Pirea (OSS)1-1/+1
commit 8ba572052a4b8fe5b205854d27e54e3486049b71 upstream. According to the TJA1103 user manual, the bit for the reversed role in MII or RMII modes is bit 4. Cc: <stable@vger.kernel.org> # 5.15+ Fixes: b050f2f15e04 ("phy: nxp-c45: add driver for tja1103") Signed-off-by: Radu Pirea (OSS) <radu-nicolae.pirea@oss.nxp.com> Link: https://lore.kernel.org/r/20230309100111.1246214-1-radu-nicolae.pirea@oss.nxp.com Signed-off-by: Jakub Kicinski <kuba@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2023-03-22ACPI: PPTT: Fix to avoid sleep in the atomic context when PPTT is absentSudeep Holla1-1/+4
commit 91d7b60a65d9f71230ea09b86d2058a884a3c2af upstream. Commit 0c80f9e165f8 ("ACPI: PPTT: Leave the table mapped for the runtime usage") enabled to map PPTT once on the first invocation of acpi_get_pptt() and never unmapped the same allowing it to be used at runtime with out the hassle of mapping and unmapping the table. This was needed to fetch LLC information from the PPTT in the cpuhotplug path which is executed in the atomic context as the acpi_get_table() might sleep waiting for a mutex. However it missed to handle the case when there is no PPTT on the system which results in acpi_get_pptt() being called from all the secondary CPUs attempting to fetch the LLC information in the atomic context without knowing the absence of PPTT resulting in the splat like below: | BUG: sleeping function called from invalid context at kernel/locking/semaphore.c:164 | in_atomic(): 1, irqs_disabled(): 1, non_block: 0, pid: 0, name: swapper/1 | preempt_count: 1, expected: 0 | RCU nest depth: 0, expected: 0 | no locks held by swapper/1/0. | irq event stamp: 0 | hardirqs last enabled at (0): 0x0 | hardirqs last disabled at (0): copy_process+0x61c/0x1b40 | softirqs last enabled at (0): copy_process+0x61c/0x1b40 | softirqs last disabled at (0): 0x0 | CPU: 1 PID: 0 Comm: swapper/1 Not tainted 6.3.0-rc1 #1 | Call trace: | dump_backtrace+0xac/0x138 | show_stack+0x30/0x48 | dump_stack_lvl+0x60/0xb0 | dump_stack+0x18/0x28 | __might_resched+0x160/0x270 | __might_sleep+0x58/0xb0 | down_timeout+0x34/0x98 | acpi_os_wait_semaphore+0x7c/0xc0 | acpi_ut_acquire_mutex+0x58/0x108 | acpi_get_table+0x40/0xe8 | acpi_get_pptt+0x48/0xa0 | acpi_get_cache_info+0x38/0x140 | init_cache_level+0xf4/0x118 | detect_cache_attributes+0x2e4/0x640 | update_siblings_masks+0x3c/0x330 | store_cpu_topology+0x88/0xf0 | secondary_start_kernel+0xd0/0x168 | __secondary_switched+0xb8/0xc0 Update acpi_get_pptt() to consider the fact that PPTT is once checked and is not available on the system and return NULL avoiding any attempts to fetch PPTT and thereby avoiding any possible sleep waiting for a mutex in the atomic context. Fixes: 0c80f9e165f8 ("ACPI: PPTT: Leave the table mapped for the runtime usage") Reported-by: Aishwarya TCV <aishwarya.tcv@arm.com> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com> Tested-by: Pierre Gondois <pierre.gondois@arm.com> Cc: 6.0+ <stable@vger.kernel.org> # 6.0+ Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2023-03-22trace/hwlat: Do not start per-cpu thread if it is already runningTero Kristo1-0/+4
commit 08697bca9bbba15f2058fdbd9f970bd5f6a8a2e8 upstream. The hwlatd tracer will end up starting multiple per-cpu threads with the following script: #!/bin/sh cd /sys/kernel/debug/tracing echo 0 > tracing_on echo hwlat > current_tracer echo per-cpu > hwlat_detector/mode echo 100000 > hwlat_detector/width echo 200000 > hwlat_detector/window echo 1 > tracing_on To fix the issue, check if the hwlatd thread for the cpu is already running, before starting a new one. Along with the previous patch, this avoids running multiple instances of the same CPU thread on the system. Link: https://lore.kernel.org/all/20230302113654.2984709-1-tero.kristo@linux.intel.com/ Link: https://lkml.kernel.org/r/20230310100451.3948583-3-tero.kristo@linux.intel.com Cc: stable@vger.kernel.org Fixes: f46b16520a087 ("trace/hwlat: Implement the per-cpu mode") Signed-off-by: Tero Kristo <tero.kristo@linux.intel.com> Acked-by: Daniel Bristot de Oliveira <bristot@kernel.org> Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2023-03-22trace/hwlat: Do not wipe the contents of per-cpu thread dataTero Kristo1-3/+0
commit 4c42f5f0d1dd20bddd9f940beb1e6ccad60c4498 upstream. Do not wipe the contents of the per-cpu kthread data when starting the tracer, as this will completely forget about already running instances and can later start new additional per-cpu threads. Link: https://lore.kernel.org/all/20230302113654.2984709-1-tero.kristo@linux.intel.com/ Link: https://lkml.kernel.org/r/20230310100451.3948583-2-tero.kristo@linux.intel.com Cc: stable@vger.kernel.org Fixes: f46b16520a087 ("trace/hwlat: Implement the per-cpu mode") Signed-off-by: Tero Kristo <tero.kristo@linux.intel.com> Acked-by: Daniel Bristot de Oliveira <bristot@kernel.org> Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2023-03-22fbdev: stifb: Provide valid pixelclock and add fb_check_var() checksHelge Deller1-0/+27
commit 203873a535d627c668f293be0cb73e26c30f9cc7 upstream. Find a valid modeline depending on the machine graphic card configuration and add the fb_check_var() function to validate Xorg provided graphics settings. Signed-off-by: Helge Deller <deller@gmx.de> Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2023-03-22mmc: sdhci_am654: lower power-on failed message severityFrancesco Dolcini1-1/+1
commit 11440da77d6020831ee6f9ce4551b545dea789ee upstream. Lower the power-on failed message severity from warn to info when the controller does not power-up. It's normal to have this situation when the SD card slot is empty, therefore we should not warn the user about it. Fixes: 7ca0f166f5b2 ("mmc: sdhci_am654: Add workaround for card detect debounce timer") Signed-off-by: Francesco Dolcini <francesco.dolcini@toradex.com> Acked-by: Adrian Hunter <adrian.hunter@intel.com> Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/20230306162751.163369-1-francesco@dolcini.it Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
generated by cgit v1.2.3 (git 2.39.0) at 2025-02-01 17:15:41 +0300