March 2025 - Linux-stable-mirror

FAILED: patch "[PATCH] arm64: dts: rockchip: Add missing PCIe supplies to RockPro64" failed to apply to 6.6-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 6.6-stable tree. If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <stable(a)vger.kernel.org>. To reproduce the conflict and resubmit, you may use the following commands: git fetch https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/ linux-6.6.y git checkout FETCH_HEAD git cherry-pick -x ffcef3df680c437ca33ff434be18ec24d72907c2 # <resolve conflicts, build, test, etc.> git commit -s git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2025032627-unlit-moaning-6815@gregkh' --subject-prefix 'PATCH 6.6.y' HEAD^.. Possible dependencies: thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From ffcef3df680c437ca33ff434be18ec24d72907c2 Mon Sep 17 00:00:00 2001 From: Dragan Simic <dsimic(a)manjaro.org> Date: Sun, 2 Mar 2025 19:48:04 +0100 Subject: [PATCH] arm64: dts: rockchip: Add missing PCIe supplies to RockPro64 board dtsi Add missing "vpcie0v9-supply" and "vpcie1v8-supply" properties to the "pcie0" node in the Pine64 RockPro64 board dtsi file. This eliminates the following warnings from the kernel log: rockchip-pcie f8000000.pcie: supply vpcie1v8 not found, using dummy regulator rockchip-pcie f8000000.pcie: supply vpcie0v9 not found, using dummy regulator These additions improve the accuracy of hardware description of the RockPro64 and, in theory, they should result in no functional changes to the way board works after the changes, because the "vcca_0v9" and "vcca_1v8" regulators are always enabled. [1][2] However, extended reliability testing, performed by Chris, [3] has proven that the age-old issues with some PCI Express cards, when used with a Pine64 RockPro64, are also resolved. Those issues were already mentioned in the commit 43853e843aa6 (arm64: dts: rockchip: Remove unsupported node from the Pinebook Pro dts, 2024-04-01), together with a brief description of the out-of-tree enumeration delay patch that reportedly resolves those issues. In a nutshell, booting a RockPro64 with some PCI Express cards attached to it caused a kernel oops. [4] Symptomatically enough, to the commit author's best knowledge, only the Pine64 RockPro64, out of all RK3399-based boards and devices supported upstream, has been reported to suffer from those PCI Express issues, and only the RockPro64 had some of the PCI Express supplies missing in its DT. Thus, perhaps some weird timing issues exist that caused the "vcca_1v8" always-on regulator, which is part of the RK808 PMIC, to actually not be enabled before the PCI Express is initialized and enumerated on the RockPro64, causing oopses with some PCIe cards, and the aforementioned enumeration delay patch [4] probably acted as just a workaround for the underlying timing issue. Admittedly, the Pine64 RockPro64 is a bit specific board by having a standard PCI Express slot, allowing use of various standard cards, but pretty much standard PCI Express cards have been attached to other RK3399 boards as well, and the commit author is unaware ot such issues reported for them. It's quite hard to be sure that the PCI Express issues are fully resolved by these additions to the DT, without some really extensive and time-consuming testing. However, these additions to the DT can result in good things and improvements anyway, making them perfectly safe from the standpoint of being unable to do any harm or cause some unforeseen regressions. These changes apply to the both supported hardware revisions of the Pine64 RockPro64, i.e. to the production-run revisions 2.0 and 2.1. [1][2] [1] https://files.pine64.org/doc/rockpro64/rockpro64_v21-SCH.pdf [2] https://files.pine64.org/doc/rockpro64/rockpro64_v20-SCH.pdf [3] https://z9.de/hedgedoc/s/nF4d5G7rg#reboot-tests-for-PCIe-improvements [4] https://lore.kernel.org/lkml/20230509153912.515218-1-vincenzopalazzodev@gma… Fixes: bba821f5479e ("arm64: dts: rockchip: add PCIe nodes on rk3399-rockpro64") Cc: stable(a)vger.kernel.org Cc: Vincenzo Palazzo <vincenzopalazzodev(a)gmail.com> Cc: Peter Geis <pgwipeout(a)gmail.com> Cc: Bjorn Helgaas <helgaas(a)kernel.org> Reported-by: Diederik de Haas <didi.debian(a)cknow.org> Tested-by: Chris Vogel <chris(a)z9.de> Signed-off-by: Dragan Simic <dsimic(a)manjaro.org> Tested-by: Diederik de Haas <didi.debian(a)cknow.org> Link: https://lore.kernel.org/r/b39cfd7490d8194f053bf3971f13a43472d1769e.17409410… Signed-off-by: Heiko Stuebner <heiko(a)sntech.de> diff --git a/arch/arm64/boot/dts/rockchip/rk3399-rockpro64.dtsi b/arch/arm64/boot/dts/rockchip/rk3399-rockpro64.dtsi index 47dc198706c8..51c6aa26d828 100644 --- a/arch/arm64/boot/dts/rockchip/rk3399-rockpro64.dtsi +++ b/arch/arm64/boot/dts/rockchip/rk3399-rockpro64.dtsi @@ -673,6 +673,8 @@ &pcie0 { num-lanes = <4>; pinctrl-names = "default"; pinctrl-0 = <&pcie_perst>; + vpcie0v9-supply = <&vcca_0v9>; + vpcie1v8-supply = <&vcca_1v8>; vpcie12v-supply = <&vcc12v_dcin>; vpcie3v3-supply = <&vcc3v3_pcie>; status = "okay";

3 months, 1 week

1
0
0 0

FAILED: patch "[PATCH] arm64: dts: rockchip: Add missing PCIe supplies to RockPro64" failed to apply to 6.1-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 6.1-stable tree. If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <stable(a)vger.kernel.org>. To reproduce the conflict and resubmit, you may use the following commands: git fetch https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/ linux-6.1.y git checkout FETCH_HEAD git cherry-pick -x ffcef3df680c437ca33ff434be18ec24d72907c2 # <resolve conflicts, build, test, etc.> git commit -s git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2025032628-fiction-upcoming-5d09@gregkh' --subject-prefix 'PATCH 6.1.y' HEAD^.. Possible dependencies: thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From ffcef3df680c437ca33ff434be18ec24d72907c2 Mon Sep 17 00:00:00 2001 From: Dragan Simic <dsimic(a)manjaro.org> Date: Sun, 2 Mar 2025 19:48:04 +0100 Subject: [PATCH] arm64: dts: rockchip: Add missing PCIe supplies to RockPro64 board dtsi Add missing "vpcie0v9-supply" and "vpcie1v8-supply" properties to the "pcie0" node in the Pine64 RockPro64 board dtsi file. This eliminates the following warnings from the kernel log: rockchip-pcie f8000000.pcie: supply vpcie1v8 not found, using dummy regulator rockchip-pcie f8000000.pcie: supply vpcie0v9 not found, using dummy regulator These additions improve the accuracy of hardware description of the RockPro64 and, in theory, they should result in no functional changes to the way board works after the changes, because the "vcca_0v9" and "vcca_1v8" regulators are always enabled. [1][2] However, extended reliability testing, performed by Chris, [3] has proven that the age-old issues with some PCI Express cards, when used with a Pine64 RockPro64, are also resolved. Those issues were already mentioned in the commit 43853e843aa6 (arm64: dts: rockchip: Remove unsupported node from the Pinebook Pro dts, 2024-04-01), together with a brief description of the out-of-tree enumeration delay patch that reportedly resolves those issues. In a nutshell, booting a RockPro64 with some PCI Express cards attached to it caused a kernel oops. [4] Symptomatically enough, to the commit author's best knowledge, only the Pine64 RockPro64, out of all RK3399-based boards and devices supported upstream, has been reported to suffer from those PCI Express issues, and only the RockPro64 had some of the PCI Express supplies missing in its DT. Thus, perhaps some weird timing issues exist that caused the "vcca_1v8" always-on regulator, which is part of the RK808 PMIC, to actually not be enabled before the PCI Express is initialized and enumerated on the RockPro64, causing oopses with some PCIe cards, and the aforementioned enumeration delay patch [4] probably acted as just a workaround for the underlying timing issue. Admittedly, the Pine64 RockPro64 is a bit specific board by having a standard PCI Express slot, allowing use of various standard cards, but pretty much standard PCI Express cards have been attached to other RK3399 boards as well, and the commit author is unaware ot such issues reported for them. It's quite hard to be sure that the PCI Express issues are fully resolved by these additions to the DT, without some really extensive and time-consuming testing. However, these additions to the DT can result in good things and improvements anyway, making them perfectly safe from the standpoint of being unable to do any harm or cause some unforeseen regressions. These changes apply to the both supported hardware revisions of the Pine64 RockPro64, i.e. to the production-run revisions 2.0 and 2.1. [1][2] [1] https://files.pine64.org/doc/rockpro64/rockpro64_v21-SCH.pdf [2] https://files.pine64.org/doc/rockpro64/rockpro64_v20-SCH.pdf [3] https://z9.de/hedgedoc/s/nF4d5G7rg#reboot-tests-for-PCIe-improvements [4] https://lore.kernel.org/lkml/20230509153912.515218-1-vincenzopalazzodev@gma… Fixes: bba821f5479e ("arm64: dts: rockchip: add PCIe nodes on rk3399-rockpro64") Cc: stable(a)vger.kernel.org Cc: Vincenzo Palazzo <vincenzopalazzodev(a)gmail.com> Cc: Peter Geis <pgwipeout(a)gmail.com> Cc: Bjorn Helgaas <helgaas(a)kernel.org> Reported-by: Diederik de Haas <didi.debian(a)cknow.org> Tested-by: Chris Vogel <chris(a)z9.de> Signed-off-by: Dragan Simic <dsimic(a)manjaro.org> Tested-by: Diederik de Haas <didi.debian(a)cknow.org> Link: https://lore.kernel.org/r/b39cfd7490d8194f053bf3971f13a43472d1769e.17409410… Signed-off-by: Heiko Stuebner <heiko(a)sntech.de> diff --git a/arch/arm64/boot/dts/rockchip/rk3399-rockpro64.dtsi b/arch/arm64/boot/dts/rockchip/rk3399-rockpro64.dtsi index 47dc198706c8..51c6aa26d828 100644 --- a/arch/arm64/boot/dts/rockchip/rk3399-rockpro64.dtsi +++ b/arch/arm64/boot/dts/rockchip/rk3399-rockpro64.dtsi @@ -673,6 +673,8 @@ &pcie0 { num-lanes = <4>; pinctrl-names = "default"; pinctrl-0 = <&pcie_perst>; + vpcie0v9-supply = <&vcca_0v9>; + vpcie1v8-supply = <&vcca_1v8>; vpcie12v-supply = <&vcc12v_dcin>; vpcie3v3-supply = <&vcc3v3_pcie>; status = "okay";

3 months, 1 week

1
0
0 0

FAILED: patch "[PATCH] arm64: dts: rockchip: Add missing PCIe supplies to RockPro64" failed to apply to 6.12-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 6.12-stable tree. If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <stable(a)vger.kernel.org>. To reproduce the conflict and resubmit, you may use the following commands: git fetch https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/ linux-6.12.y git checkout FETCH_HEAD git cherry-pick -x ffcef3df680c437ca33ff434be18ec24d72907c2 # <resolve conflicts, build, test, etc.> git commit -s git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2025032627-charm-hesitancy-d3bf@gregkh' --subject-prefix 'PATCH 6.12.y' HEAD^.. Possible dependencies: thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From ffcef3df680c437ca33ff434be18ec24d72907c2 Mon Sep 17 00:00:00 2001 From: Dragan Simic <dsimic(a)manjaro.org> Date: Sun, 2 Mar 2025 19:48:04 +0100 Subject: [PATCH] arm64: dts: rockchip: Add missing PCIe supplies to RockPro64 board dtsi Add missing "vpcie0v9-supply" and "vpcie1v8-supply" properties to the "pcie0" node in the Pine64 RockPro64 board dtsi file. This eliminates the following warnings from the kernel log: rockchip-pcie f8000000.pcie: supply vpcie1v8 not found, using dummy regulator rockchip-pcie f8000000.pcie: supply vpcie0v9 not found, using dummy regulator These additions improve the accuracy of hardware description of the RockPro64 and, in theory, they should result in no functional changes to the way board works after the changes, because the "vcca_0v9" and "vcca_1v8" regulators are always enabled. [1][2] However, extended reliability testing, performed by Chris, [3] has proven that the age-old issues with some PCI Express cards, when used with a Pine64 RockPro64, are also resolved. Those issues were already mentioned in the commit 43853e843aa6 (arm64: dts: rockchip: Remove unsupported node from the Pinebook Pro dts, 2024-04-01), together with a brief description of the out-of-tree enumeration delay patch that reportedly resolves those issues. In a nutshell, booting a RockPro64 with some PCI Express cards attached to it caused a kernel oops. [4] Symptomatically enough, to the commit author's best knowledge, only the Pine64 RockPro64, out of all RK3399-based boards and devices supported upstream, has been reported to suffer from those PCI Express issues, and only the RockPro64 had some of the PCI Express supplies missing in its DT. Thus, perhaps some weird timing issues exist that caused the "vcca_1v8" always-on regulator, which is part of the RK808 PMIC, to actually not be enabled before the PCI Express is initialized and enumerated on the RockPro64, causing oopses with some PCIe cards, and the aforementioned enumeration delay patch [4] probably acted as just a workaround for the underlying timing issue. Admittedly, the Pine64 RockPro64 is a bit specific board by having a standard PCI Express slot, allowing use of various standard cards, but pretty much standard PCI Express cards have been attached to other RK3399 boards as well, and the commit author is unaware ot such issues reported for them. It's quite hard to be sure that the PCI Express issues are fully resolved by these additions to the DT, without some really extensive and time-consuming testing. However, these additions to the DT can result in good things and improvements anyway, making them perfectly safe from the standpoint of being unable to do any harm or cause some unforeseen regressions. These changes apply to the both supported hardware revisions of the Pine64 RockPro64, i.e. to the production-run revisions 2.0 and 2.1. [1][2] [1] https://files.pine64.org/doc/rockpro64/rockpro64_v21-SCH.pdf [2] https://files.pine64.org/doc/rockpro64/rockpro64_v20-SCH.pdf [3] https://z9.de/hedgedoc/s/nF4d5G7rg#reboot-tests-for-PCIe-improvements [4] https://lore.kernel.org/lkml/20230509153912.515218-1-vincenzopalazzodev@gma… Fixes: bba821f5479e ("arm64: dts: rockchip: add PCIe nodes on rk3399-rockpro64") Cc: stable(a)vger.kernel.org Cc: Vincenzo Palazzo <vincenzopalazzodev(a)gmail.com> Cc: Peter Geis <pgwipeout(a)gmail.com> Cc: Bjorn Helgaas <helgaas(a)kernel.org> Reported-by: Diederik de Haas <didi.debian(a)cknow.org> Tested-by: Chris Vogel <chris(a)z9.de> Signed-off-by: Dragan Simic <dsimic(a)manjaro.org> Tested-by: Diederik de Haas <didi.debian(a)cknow.org> Link: https://lore.kernel.org/r/b39cfd7490d8194f053bf3971f13a43472d1769e.17409410… Signed-off-by: Heiko Stuebner <heiko(a)sntech.de> diff --git a/arch/arm64/boot/dts/rockchip/rk3399-rockpro64.dtsi b/arch/arm64/boot/dts/rockchip/rk3399-rockpro64.dtsi index 47dc198706c8..51c6aa26d828 100644 --- a/arch/arm64/boot/dts/rockchip/rk3399-rockpro64.dtsi +++ b/arch/arm64/boot/dts/rockchip/rk3399-rockpro64.dtsi @@ -673,6 +673,8 @@ &pcie0 { num-lanes = <4>; pinctrl-names = "default"; pinctrl-0 = <&pcie_perst>; + vpcie0v9-supply = <&vcca_0v9>; + vpcie1v8-supply = <&vcca_1v8>; vpcie12v-supply = <&vcc12v_dcin>; vpcie3v3-supply = <&vcc3v3_pcie>; status = "okay";

3 months, 1 week

1
0
0 0

FAILED: patch "[PATCH] arm64: dts: rockchip: Add missing PCIe supplies to RockPro64" failed to apply to 6.13-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 6.13-stable tree. If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <stable(a)vger.kernel.org>. To reproduce the conflict and resubmit, you may use the following commands: git fetch https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/ linux-6.13.y git checkout FETCH_HEAD git cherry-pick -x ffcef3df680c437ca33ff434be18ec24d72907c2 # <resolve conflicts, build, test, etc.> git commit -s git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2025032626-glare-splotchy-ee9a@gregkh' --subject-prefix 'PATCH 6.13.y' HEAD^.. Possible dependencies: thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From ffcef3df680c437ca33ff434be18ec24d72907c2 Mon Sep 17 00:00:00 2001 From: Dragan Simic <dsimic(a)manjaro.org> Date: Sun, 2 Mar 2025 19:48:04 +0100 Subject: [PATCH] arm64: dts: rockchip: Add missing PCIe supplies to RockPro64 board dtsi Add missing "vpcie0v9-supply" and "vpcie1v8-supply" properties to the "pcie0" node in the Pine64 RockPro64 board dtsi file. This eliminates the following warnings from the kernel log: rockchip-pcie f8000000.pcie: supply vpcie1v8 not found, using dummy regulator rockchip-pcie f8000000.pcie: supply vpcie0v9 not found, using dummy regulator These additions improve the accuracy of hardware description of the RockPro64 and, in theory, they should result in no functional changes to the way board works after the changes, because the "vcca_0v9" and "vcca_1v8" regulators are always enabled. [1][2] However, extended reliability testing, performed by Chris, [3] has proven that the age-old issues with some PCI Express cards, when used with a Pine64 RockPro64, are also resolved. Those issues were already mentioned in the commit 43853e843aa6 (arm64: dts: rockchip: Remove unsupported node from the Pinebook Pro dts, 2024-04-01), together with a brief description of the out-of-tree enumeration delay patch that reportedly resolves those issues. In a nutshell, booting a RockPro64 with some PCI Express cards attached to it caused a kernel oops. [4] Symptomatically enough, to the commit author's best knowledge, only the Pine64 RockPro64, out of all RK3399-based boards and devices supported upstream, has been reported to suffer from those PCI Express issues, and only the RockPro64 had some of the PCI Express supplies missing in its DT. Thus, perhaps some weird timing issues exist that caused the "vcca_1v8" always-on regulator, which is part of the RK808 PMIC, to actually not be enabled before the PCI Express is initialized and enumerated on the RockPro64, causing oopses with some PCIe cards, and the aforementioned enumeration delay patch [4] probably acted as just a workaround for the underlying timing issue. Admittedly, the Pine64 RockPro64 is a bit specific board by having a standard PCI Express slot, allowing use of various standard cards, but pretty much standard PCI Express cards have been attached to other RK3399 boards as well, and the commit author is unaware ot such issues reported for them. It's quite hard to be sure that the PCI Express issues are fully resolved by these additions to the DT, without some really extensive and time-consuming testing. However, these additions to the DT can result in good things and improvements anyway, making them perfectly safe from the standpoint of being unable to do any harm or cause some unforeseen regressions. These changes apply to the both supported hardware revisions of the Pine64 RockPro64, i.e. to the production-run revisions 2.0 and 2.1. [1][2] [1] https://files.pine64.org/doc/rockpro64/rockpro64_v21-SCH.pdf [2] https://files.pine64.org/doc/rockpro64/rockpro64_v20-SCH.pdf [3] https://z9.de/hedgedoc/s/nF4d5G7rg#reboot-tests-for-PCIe-improvements [4] https://lore.kernel.org/lkml/20230509153912.515218-1-vincenzopalazzodev@gma… Fixes: bba821f5479e ("arm64: dts: rockchip: add PCIe nodes on rk3399-rockpro64") Cc: stable(a)vger.kernel.org Cc: Vincenzo Palazzo <vincenzopalazzodev(a)gmail.com> Cc: Peter Geis <pgwipeout(a)gmail.com> Cc: Bjorn Helgaas <helgaas(a)kernel.org> Reported-by: Diederik de Haas <didi.debian(a)cknow.org> Tested-by: Chris Vogel <chris(a)z9.de> Signed-off-by: Dragan Simic <dsimic(a)manjaro.org> Tested-by: Diederik de Haas <didi.debian(a)cknow.org> Link: https://lore.kernel.org/r/b39cfd7490d8194f053bf3971f13a43472d1769e.17409410… Signed-off-by: Heiko Stuebner <heiko(a)sntech.de> diff --git a/arch/arm64/boot/dts/rockchip/rk3399-rockpro64.dtsi b/arch/arm64/boot/dts/rockchip/rk3399-rockpro64.dtsi index 47dc198706c8..51c6aa26d828 100644 --- a/arch/arm64/boot/dts/rockchip/rk3399-rockpro64.dtsi +++ b/arch/arm64/boot/dts/rockchip/rk3399-rockpro64.dtsi @@ -673,6 +673,8 @@ &pcie0 { num-lanes = <4>; pinctrl-names = "default"; pinctrl-0 = <&pcie_perst>; + vpcie0v9-supply = <&vcca_0v9>; + vpcie1v8-supply = <&vcca_1v8>; vpcie12v-supply = <&vcc12v_dcin>; vpcie3v3-supply = <&vcc3v3_pcie>; status = "okay";

3 months, 1 week

1
0
0 0

[PATCH 1/5] usb: misc: onboard_usb_dev: fix support for Cypress HX3 hubs

by Lukasz Czechowski

The Cypress HX3 USB3.0 hubs use different PID values depending on the product variant. The comment in compatibles table is misleading, as the currently used PIDs (0x6504 and 0x6506 for USB 3.0 and USB 2.0, respectively) are defaults for the CYUSB331x, while CYUSB330x and CYUSB332x variants use different values. Based on the datasheet [1], update the compatible usb devices table to handle different types of the hub. The change also includes vendor mode PIDs, which are used by the hub in I2C Master boot mode, if connected EEPROM contains invalid signature or is blank. This allows to correctly boot the hub even if the EEPROM will have broken content. Number of vcc supplies and timing requirements are the same for all HX variants, so reuse existing onboard_hub_pdata. [1] https://www.infineon.com/dgdl/Infineon-HX3_USB_3_0_Hub_Consumer_Industrial-… Table 9. PID Values Fixes: b43cd82a1a40 ("usb: misc: onboard-hub: add support for Cypress HX3 USB 3.0 family") Cc: stable(a)vger.kernel.org Signed-off-by: Lukasz Czechowski <lukasz.czechowski(a)thaumatec.com> --- drivers/usb/misc/onboard_usb_dev.c | 10 ++++++++-- drivers/usb/misc/onboard_usb_dev.h | 6 ++++++ 2 files changed, 14 insertions(+), 2 deletions(-) diff --git a/drivers/usb/misc/onboard_usb_dev.c b/drivers/usb/misc/onboard_usb_dev.c index 75ac3c6aa92d..f5372dfa241a 100644 --- a/drivers/usb/misc/onboard_usb_dev.c +++ b/drivers/usb/misc/onboard_usb_dev.c @@ -569,8 +569,14 @@ static void onboard_dev_usbdev_disconnect(struct usb_device *udev) } static const struct usb_device_id onboard_dev_id_table[] = { - { USB_DEVICE(VENDOR_ID_CYPRESS, 0x6504) }, /* CYUSB33{0,1,2}x/CYUSB230x 3.0 HUB */ - { USB_DEVICE(VENDOR_ID_CYPRESS, 0x6506) }, /* CYUSB33{0,1,2}x/CYUSB230x 2.0 HUB */ + { USB_DEVICE(VENDOR_ID_CYPRESS, 0x6500) }, /* CYUSB330x 3.0 HUB */ + { USB_DEVICE(VENDOR_ID_CYPRESS, 0x6502) }, /* CYUSB330x 2.0 HUB */ + { USB_DEVICE(VENDOR_ID_CYPRESS, 0x6503) }, /* CYUSB33{0,1}x 2.0 HUB, Vendor Mode */ + { USB_DEVICE(VENDOR_ID_CYPRESS, 0x6504) }, /* CYUSB331x 3.0 HUB */ + { USB_DEVICE(VENDOR_ID_CYPRESS, 0x6506) }, /* CYUSB331x 2.0 HUB */ + { USB_DEVICE(VENDOR_ID_CYPRESS, 0x6507) }, /* CYUSB332x 2.0 HUB, Vendor Mode */ + { USB_DEVICE(VENDOR_ID_CYPRESS, 0x6508) }, /* CYUSB332x 3.0 HUB */ + { USB_DEVICE(VENDOR_ID_CYPRESS, 0x650a) }, /* CYUSB332x 2.0 HUB */ { USB_DEVICE(VENDOR_ID_CYPRESS, 0x6570) }, /* CY7C6563x 2.0 HUB */ { USB_DEVICE(VENDOR_ID_GENESYS, 0x0608) }, /* Genesys Logic GL850G USB 2.0 HUB */ { USB_DEVICE(VENDOR_ID_GENESYS, 0x0610) }, /* Genesys Logic GL852G USB 2.0 HUB */ diff --git a/drivers/usb/misc/onboard_usb_dev.h b/drivers/usb/misc/onboard_usb_dev.h index 317b3eb99c02..17696f7c5e43 100644 --- a/drivers/usb/misc/onboard_usb_dev.h +++ b/drivers/usb/misc/onboard_usb_dev.h @@ -104,8 +104,14 @@ static const struct of_device_id onboard_dev_match[] = { { .compatible = "usb451,8027", .data = &ti_tusb8020b_data, }, { .compatible = "usb451,8140", .data = &ti_tusb8041_data, }, { .compatible = "usb451,8142", .data = &ti_tusb8041_data, }, + { .compatible = "usb4b4,6500", .data = &cypress_hx3_data, }, + { .compatible = "usb4b4,6502", .data = &cypress_hx3_data, }, + { .compatible = "usb4b4,6503", .data = &cypress_hx3_data, }, { .compatible = "usb4b4,6504", .data = &cypress_hx3_data, }, { .compatible = "usb4b4,6506", .data = &cypress_hx3_data, }, + { .compatible = "usb4b4,6507", .data = &cypress_hx3_data, }, + { .compatible = "usb4b4,6508", .data = &cypress_hx3_data, }, + { .compatible = "usb4b4,650a", .data = &cypress_hx3_data, }, { .compatible = "usb4b4,6570", .data = &cypress_hx2vl_data, }, { .compatible = "usb5e3,608", .data = &genesys_gl850g_data, }, { .compatible = "usb5e3,610", .data = &genesys_gl852g_data, }, -- 2.43.0

3 months, 1 week

1
0
0 0

[PATCH] drm/xe: Fix an out-of-bounds shift when invalidating TLB

by Thomas Hellström

When the size of the range invalidated is larger than U64_MAX / 2 + 1, The function roundup_pow_of_two(length) will hit an out-of-bounds shift. Use a full TLB invalidation for such cases. [ 39.202421] ------------[ cut here ]------------ [ 39.202657] UBSAN: shift-out-of-bounds in ./include/linux/log2.h:57:13 [ 39.202673] shift exponent 64 is too large for 64-bit type 'long unsigned int' [ 39.202688] CPU: 8 UID: 0 PID: 3129 Comm: xe_exec_system_ Tainted: G U 6.14.0+ #10 [ 39.202690] Tainted: [U]=USER [ 39.202690] Hardware name: ASUS System Product Name/PRIME B560M-A AC, BIOS 2001 02/01/2023 [ 39.202691] Call Trace: [ 39.202692] <TASK> [ 39.202695] dump_stack_lvl+0x6e/0xa0 [ 39.202699] ubsan_epilogue+0x5/0x30 [ 39.202701] __ubsan_handle_shift_out_of_bounds.cold+0x61/0xe6 [ 39.202705] xe_gt_tlb_invalidation_range.cold+0x1d/0x3a [xe] [ 39.202800] ? find_held_lock+0x2b/0x80 [ 39.202803] ? mark_held_locks+0x40/0x70 [ 39.202806] xe_svm_invalidate+0x459/0x700 [xe] [ 39.202897] drm_gpusvm_notifier_invalidate+0x4d/0x70 [drm_gpusvm] [ 39.202900] __mmu_notifier_release+0x1f5/0x270 [ 39.202905] exit_mmap+0x40e/0x450 [ 39.202912] __mmput+0x45/0x110 [ 39.202914] exit_mm+0xc5/0x130 [ 39.202916] do_exit+0x21c/0x500 [ 39.202918] ? lockdep_hardirqs_on_prepare+0xdb/0x190 [ 39.202920] do_group_exit+0x36/0xa0 [ 39.202922] get_signal+0x8f8/0x900 [ 39.202926] arch_do_signal_or_restart+0x35/0x100 [ 39.202930] syscall_exit_to_user_mode+0x1fc/0x290 [ 39.202932] do_syscall_64+0xa1/0x180 [ 39.202934] ? do_user_addr_fault+0x59f/0x8a0 [ 39.202937] ? lock_release+0xd2/0x2a0 [ 39.202939] ? do_user_addr_fault+0x5a9/0x8a0 [ 39.202942] ? trace_hardirqs_off+0x4b/0xc0 [ 39.202944] ? clear_bhb_loop+0x25/0x80 [ 39.202946] ? clear_bhb_loop+0x25/0x80 [ 39.202947] ? clear_bhb_loop+0x25/0x80 [ 39.202950] entry_SYSCALL_64_after_hwframe+0x76/0x7e [ 39.202952] RIP: 0033:0x7fa945e543e1 [ 39.202961] Code: Unable to access opcode bytes at 0x7fa945e543b7. [ 39.202962] RSP: 002b:00007ffca8fb4170 EFLAGS: 00000293 [ 39.202963] RAX: 000000000000003d RBX: 0000000000000000 RCX: 00007fa945e543e3 [ 39.202964] RDX: 0000000000000000 RSI: 00007ffca8fb41ac RDI: 00000000ffffffff [ 39.202964] RBP: 00007ffca8fb4190 R08: 0000000000000000 R09: 00007fa945f600a0 [ 39.202965] R10: 0000000000000000 R11: 0000000000000293 R12: 0000000000000000 [ 39.202966] R13: 00007fa9460dd310 R14: 00007ffca8fb41ac R15: 0000000000000000 [ 39.202970] </TASK> [ 39.202970] ---[ end trace ]--- Fixes: 332dd0116c82 ("drm/xe: Add range based TLB invalidations") Cc: Matthew Brost <matthew.brost(a)intel.com> Cc: Rodrigo Vivi <rodrigo.vivi(a)intel.com> Cc: <stable(a)vger.kernel.org> # v6.8+ Signed-off-by: Thomas Hellström <thomas.hellstrom(a)linux.intel.com> --- drivers/gpu/drm/xe/xe_gt_tlb_invalidation.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/xe/xe_gt_tlb_invalidation.c b/drivers/gpu/drm/xe/xe_gt_tlb_invalidation.c index 03072e094991..79f8fe127867 100644 --- a/drivers/gpu/drm/xe/xe_gt_tlb_invalidation.c +++ b/drivers/gpu/drm/xe/xe_gt_tlb_invalidation.c @@ -346,6 +346,7 @@ int xe_gt_tlb_invalidation_range(struct xe_gt *gt, struct xe_device *xe = gt_to_xe(gt); #define MAX_TLB_INVALIDATION_LEN 7 u32 action[MAX_TLB_INVALIDATION_LEN]; + u64 length = end - start; int len = 0; xe_gt_assert(gt, fence); @@ -358,11 +359,10 @@ int xe_gt_tlb_invalidation_range(struct xe_gt *gt, action[len++] = XE_GUC_ACTION_TLB_INVALIDATION; action[len++] = 0; /* seqno, replaced in send_tlb_invalidation */ - if (!xe->info.has_range_tlb_invalidation) { + if (!xe->info.has_range_tlb_invalidation || length > (U64_MAX >> 1) + 1) { action[len++] = MAKE_INVAL_OP(XE_GUC_TLB_INVAL_FULL); } else { u64 orig_start = start; - u64 length = end - start; u64 align; if (length < SZ_4K) -- 2.48.1

3 months, 1 week

2
2
0 0

[PATCH] powerpc64/bpf: fix JIT code size calculation of bpf trampoline

by Hari Bathini

The JIT compile of ldimm instructions can be anywhere between 1-5 instructions long depending on the value being loaded. arch_bpf_trampoline_size() provides JIT size of the BPF trampoline before the buffer for JIT'ing it is allocated. BPF trampoline JIT code has ldimm instructions that need to load the value of pointer to struct bpf_tramp_image. But this pointer value is not same while calling arch_bpf_trampoline_size() & arch_prepare_bpf_trampoline(). So, the size arrived at using arch_bpf_trampoline_size() can vary from the size needed in arch_prepare_bpf_trampoline(). When the number of ldimm instructions emitted in arch_bpf_trampoline_size() is less than the number of ldimm instructions emitted during the actual JIT compile of trampoline, the below warning is produced: WARNING: CPU: 8 PID: 204190 at arch/powerpc/net/bpf_jit_comp.c:981 __arch_prepare_bpf_trampoline.isra.0+0xd2c/0xdcc which is: /* Make sure the trampoline generation logic doesn't overflow */ if (image && WARN_ON_ONCE(&image[ctx->idx] > (u32 *)rw_image_end - BPF_INSN_SAFETY)) { Pass NULL as the first argument to __arch_prepare_bpf_trampoline() call from arch_bpf_trampoline_size() function, to differentiate it from how arch_prepare_bpf_trampoline() calls it and ensure maximum possible instructions are emitted in arch_bpf_trampoline_size() for ldimm instructions that load a different value during the actual JIT compile of BPF trampoline. Fixes: d243b62b7bd3 ("powerpc64/bpf: Add support for bpf trampolines") Reported-by: Venkat Rao Bagalkote <venkat88(a)linux.ibm.com> Closes: https://lore.kernel.org/all/6168bfc8-659f-4b5a-a6fb-90a916dde3b3@linux.ibm.… Cc: stable(a)vger.kernel.org # v6.13+ Signed-off-by: Hari Bathini <hbathini(a)linux.ibm.com> --- arch/powerpc/net/bpf_jit_comp.c | 31 ++++++++++++++++++++++++------- 1 file changed, 24 insertions(+), 7 deletions(-) diff --git a/arch/powerpc/net/bpf_jit_comp.c b/arch/powerpc/net/bpf_jit_comp.c index 2991bb171a9b..49d7e9a8d17c 100644 --- a/arch/powerpc/net/bpf_jit_comp.c +++ b/arch/powerpc/net/bpf_jit_comp.c @@ -686,7 +686,7 @@ static int __arch_prepare_bpf_trampoline(struct bpf_tramp_image *im, void *rw_im * [ ] -- * LR save area [ r0 save (64-bit) ] | header * [ r0 save (32-bit) ] | - * dummy frame for unwind [ back chain 1 ] -- + /* dummy frame for unwind [ back chain 1 ] -- * [ padding ] align stack frame * r4_off [ r4 (tailcallcnt) ] optional - 32-bit powerpc * alt_lr_off [ real lr (ool stub)] optional - actual lr @@ -833,7 +833,12 @@ static int __arch_prepare_bpf_trampoline(struct bpf_tramp_image *im, void *rw_im EMIT(PPC_RAW_STL(_R26, _R1, nvr_off + SZL)); if (flags & BPF_TRAMP_F_CALL_ORIG) { - PPC_LI_ADDR(_R3, (unsigned long)im); + /* + * Emit maximum possible instructions while getting the size of + * bpf trampoline to ensure trampoline JIT code doesn't overflow. + */ + PPC_LI_ADDR(_R3, im ? (unsigned long)im : + (unsigned long)(~(1UL << (BITS_PER_LONG - 1)))); ret = bpf_jit_emit_func_call_rel(image, ro_image, ctx, (unsigned long)__bpf_tramp_enter); if (ret) @@ -889,7 +894,8 @@ static int __arch_prepare_bpf_trampoline(struct bpf_tramp_image *im, void *rw_im bpf_trampoline_restore_tail_call_cnt(image, ctx, func_frame_offset, r4_off); /* Reserve space to patch branch instruction to skip fexit progs */ - im->ip_after_call = &((u32 *)ro_image)[ctx->idx]; + if (im) + im->ip_after_call = &((u32 *)ro_image)[ctx->idx]; EMIT(PPC_RAW_NOP()); } @@ -912,8 +918,14 @@ static int __arch_prepare_bpf_trampoline(struct bpf_tramp_image *im, void *rw_im } if (flags & BPF_TRAMP_F_CALL_ORIG) { - im->ip_epilogue = &((u32 *)ro_image)[ctx->idx]; - PPC_LI_ADDR(_R3, im); + if (im) + im->ip_epilogue = &((u32 *)ro_image)[ctx->idx]; + /* + * Emit maximum possible instructions while getting the size of + * bpf trampoline to ensure trampoline JIT code doesn't overflow. + */ + PPC_LI_ADDR(_R3, im ? (unsigned long)im : + (unsigned long)(~(1UL << (BITS_PER_LONG - 1)))); ret = bpf_jit_emit_func_call_rel(image, ro_image, ctx, (unsigned long)__bpf_tramp_exit); if (ret) @@ -972,7 +984,6 @@ static int __arch_prepare_bpf_trampoline(struct bpf_tramp_image *im, void *rw_im int arch_bpf_trampoline_size(const struct btf_func_model *m, u32 flags, struct bpf_tramp_links *tlinks, void *func_addr) { - struct bpf_tramp_image im; void *image; int ret; @@ -988,7 +999,13 @@ int arch_bpf_trampoline_size(const struct btf_func_model *m, u32 flags, if (!image) return -ENOMEM; - ret = __arch_prepare_bpf_trampoline(&im, image, image + PAGE_SIZE, image, + /* + * Pass NULL as bpf_tramp_image pointer to differentiate the intent to get the + * buffer size for trampoline here. This differentiation helps in accounting for + * maximum possible instructions if the JIT code size is likely to vary during + * the actual JIT compile of the trampoline. + */ + ret = __arch_prepare_bpf_trampoline(NULL, image, image + PAGE_SIZE, image, m, flags, tlinks, func_addr); bpf_jit_free_exec(image); -- 2.48.1

3 months, 1 week

1
1
0 0

[PATCH] firmware: stratix10-svc: Add of_platform_default_populate()

by Dinh Nguyen

From: Mahesh Rao <mahesh.rao(a)intel.com> Add of_platform_default_populate() to stratix10-svc driver as the firmware/svc node was moved out of soc. This fixes the failed probing of child drivers of svc node. Cc: stable(a)vger.kernel.org Fixes: 23c3ebed382a ("arm64: dts: socfpga: agilex: move firmware out of soc node") Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski(a)linaro.org> Reviewed-by: Xu Yilun <yilun.xu(a)intel.com> Signed-off-by: Mahesh Rao <mahesh.rao(a)intel.com> Signed-off-by: Dinh Nguyen <dinguyen(a)kernel.org> --- drivers/firmware/stratix10-svc.c | 14 +++++++++++--- 1 file changed, 11 insertions(+), 3 deletions(-) diff --git a/drivers/firmware/stratix10-svc.c b/drivers/firmware/stratix10-svc.c index 3c52cb73237a..e3f990d888d7 100644 --- a/drivers/firmware/stratix10-svc.c +++ b/drivers/firmware/stratix10-svc.c @@ -1224,22 +1224,28 @@ static int stratix10_svc_drv_probe(struct platform_device *pdev) if (!svc->intel_svc_fcs) { dev_err(dev, "failed to allocate %s device\n", INTEL_FCS); ret = -ENOMEM; - goto err_unregister_dev; + goto err_unregister_rsu_dev; } ret = platform_device_add(svc->intel_svc_fcs); if (ret) { platform_device_put(svc->intel_svc_fcs); - goto err_unregister_dev; + goto err_unregister_rsu_dev; } + ret = of_platform_default_populate(dev_of_node(dev), NULL, dev); + if (ret) + goto err_unregister_fcs_dev; + dev_set_drvdata(dev, svc); pr_info("Intel Service Layer Driver Initialized\n"); return 0; -err_unregister_dev: +err_unregister_fcs_dev: + platform_device_unregister(svc->intel_svc_fcs); +err_unregister_rsu_dev: platform_device_unregister(svc->stratix10_svc_rsu); err_free_kfifo: kfifo_free(&controller->svc_fifo); @@ -1253,6 +1259,8 @@ static void stratix10_svc_drv_remove(struct platform_device *pdev) struct stratix10_svc *svc = dev_get_drvdata(&pdev->dev); struct stratix10_svc_controller *ctrl = platform_get_drvdata(pdev); + of_platform_depopulate(ctrl->dev); + platform_device_unregister(svc->intel_svc_fcs); platform_device_unregister(svc->stratix10_svc_rsu); -- 2.42.0.411.g813d9a9188

3 months, 1 week

1
0
0 0

[PATCH] arm64: mops: Do not dereference src reg for a set operation

by Keir Fraser

The source register is not used for SET* and reading it can result in a UBSAN out-of-bounds array access error, specifically when the MOPS exception is taken from a SET* sequence with XZR (reg 31) as the source. Architecturally this is the only case where a src/dst/size field in the ESR can be reported as 31. Prior to 2de451a329cf662b the code in do_el0_mops() was benign as the use of pt_regs_read_reg() prevented the out-of-bounds access. Fixes: 2de451a329cf662b ("KVM: arm64: Add handler for MOPS exceptions") Cc: Kristina Martsenko <kristina.martsenko(a)arm.com> Cc: Catalin Marinas <catalin.marinas(a)arm.com> Cc: Mark Rutland <mark.rutland(a)arm.com> Cc: Will Deacon <will(a)kernel.org> Cc: stable(a)vger.kernel.org Reviewed-by: Marc Zyngier <maz(a)kernel.org> Signed-off-by: Keir Fraser <keirf(a)google.com> --- arch/arm64/include/asm/traps.h | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/arch/arm64/include/asm/traps.h b/arch/arm64/include/asm/traps.h index d780d1bd2eac..82cf1f879c61 100644 --- a/arch/arm64/include/asm/traps.h +++ b/arch/arm64/include/asm/traps.h @@ -109,10 +109,9 @@ static inline void arm64_mops_reset_regs(struct user_pt_regs *regs, unsigned lon int dstreg = ESR_ELx_MOPS_ISS_DESTREG(esr); int srcreg = ESR_ELx_MOPS_ISS_SRCREG(esr); int sizereg = ESR_ELx_MOPS_ISS_SIZEREG(esr); - unsigned long dst, src, size; + unsigned long dst, size; dst = regs->regs[dstreg]; - src = regs->regs[srcreg]; size = regs->regs[sizereg]; /* @@ -129,6 +128,7 @@ static inline void arm64_mops_reset_regs(struct user_pt_regs *regs, unsigned lon } } else { /* CPY* instruction */ + unsigned long src = regs->regs[srcreg]; if (!(option_a ^ wrong_option)) { /* Format is from Option B */ if (regs->pstate & PSR_N_BIT) { -- 2.49.0.395.g12beb8f557-goog

3 months, 1 week

2
1
0 0

[PATCH] arm64: mops: Do not dereference src reg for a set operation

by Keir Fraser

The register is not defined and reading it can result in a UBSAN out-of-bounds array access error, specifically when the srcreg field value is 31. Cc: Kristina Martsenko <kristina.martsenko(a)arm.com> Cc: Catalin Marinas <catalin.marinas(a)arm.com> Cc: Mark Rutland <mark.rutland(a)arm.com> Cc: Will Deacon <will(a)kernel.org> Cc: Marc Zyngier <maz(a)kernel.org> Cc: stable(a)vger.kernel.org Signed-off-by: Keir Fraser <keirf(a)google.com> --- arch/arm64/include/asm/traps.h | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/arch/arm64/include/asm/traps.h b/arch/arm64/include/asm/traps.h index d780d1bd2eac..82cf1f879c61 100644 --- a/arch/arm64/include/asm/traps.h +++ b/arch/arm64/include/asm/traps.h @@ -109,10 +109,9 @@ static inline void arm64_mops_reset_regs(struct user_pt_regs *regs, unsigned lon int dstreg = ESR_ELx_MOPS_ISS_DESTREG(esr); int srcreg = ESR_ELx_MOPS_ISS_SRCREG(esr); int sizereg = ESR_ELx_MOPS_ISS_SIZEREG(esr); - unsigned long dst, src, size; + unsigned long dst, size; dst = regs->regs[dstreg]; - src = regs->regs[srcreg]; size = regs->regs[sizereg]; /* @@ -129,6 +128,7 @@ static inline void arm64_mops_reset_regs(struct user_pt_regs *regs, unsigned lon } } else { /* CPY* instruction */ + unsigned long src = regs->regs[srcreg]; if (!(option_a ^ wrong_option)) { /* Format is from Option B */ if (regs->pstate & PSR_N_BIT) { -- 2.49.0.395.g12beb8f557-goog

3 months, 1 week

3
3
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror March 2025