- Linux-stable-mirror - lists.linaro.org

FAILED: patch "[PATCH] arm64: dts: qcom: x1e78100-t14s: mark l12b and l15b always-on" 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 673fa129e558c5f1196adb27d97ac90ddfe4f19c # <resolve conflicts, build, test, etc.> git commit -s git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2025060255-dislike-elaborate-1e0f@gregkh' --subject-prefix 'PATCH 6.12.y' HEAD^.. Possible dependencies: thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From 673fa129e558c5f1196adb27d97ac90ddfe4f19c Mon Sep 17 00:00:00 2001 From: Johan Hovold <johan+linaro(a)kernel.org> Date: Fri, 14 Mar 2025 15:54:34 +0100 Subject: [PATCH] arm64: dts: qcom: x1e78100-t14s: mark l12b and l15b always-on The l12b and l15b supplies are used by components that are not (fully) described (and some never will be) and must never be disabled. Mark the regulators as always-on to prevent them from being disabled, for example, when consumers probe defer or suspend. Fixes: 7d1cbe2f4985 ("arm64: dts: qcom: Add X1E78100 ThinkPad T14s Gen 6") Cc: stable(a)vger.kernel.org # 6.12 Reviewed-by: Konrad Dybcio <konrad.dybcio(a)oss.qualcomm.com> Signed-off-by: Johan Hovold <johan+linaro(a)kernel.org> Link: https://lore.kernel.org/r/20250314145440.11371-3-johan+linaro@kernel.org Signed-off-by: Bjorn Andersson <andersson(a)kernel.org> diff --git a/arch/arm64/boot/dts/qcom/x1e78100-lenovo-thinkpad-t14s.dtsi b/arch/arm64/boot/dts/qcom/x1e78100-lenovo-thinkpad-t14s.dtsi index eff0e73640bc..160c052db1ec 100644 --- a/arch/arm64/boot/dts/qcom/x1e78100-lenovo-thinkpad-t14s.dtsi +++ b/arch/arm64/boot/dts/qcom/x1e78100-lenovo-thinkpad-t14s.dtsi @@ -456,6 +456,7 @@ vreg_l12b_1p2: ldo12 { regulator-min-microvolt = <1200000>; regulator-max-microvolt = <1200000>; regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>; + regulator-always-on; }; vreg_l13b_3p0: ldo13 { @@ -477,6 +478,7 @@ vreg_l15b_1p8: ldo15 { regulator-min-microvolt = <1800000>; regulator-max-microvolt = <1800000>; regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>; + regulator-always-on; }; vreg_l17b_2p5: ldo17 {

1 month, 1 week

1
0
0 0

FAILED: patch "[PATCH] arm64: dts: qcom: x1e78100-t14s: mark l12b and l15b always-on" failed to apply to 6.14-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 6.14-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.14.y git checkout FETCH_HEAD git cherry-pick -x 673fa129e558c5f1196adb27d97ac90ddfe4f19c # <resolve conflicts, build, test, etc.> git commit -s git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2025060254-fling-reflex-4a17@gregkh' --subject-prefix 'PATCH 6.14.y' HEAD^.. Possible dependencies: thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From 673fa129e558c5f1196adb27d97ac90ddfe4f19c Mon Sep 17 00:00:00 2001 From: Johan Hovold <johan+linaro(a)kernel.org> Date: Fri, 14 Mar 2025 15:54:34 +0100 Subject: [PATCH] arm64: dts: qcom: x1e78100-t14s: mark l12b and l15b always-on The l12b and l15b supplies are used by components that are not (fully) described (and some never will be) and must never be disabled. Mark the regulators as always-on to prevent them from being disabled, for example, when consumers probe defer or suspend. Fixes: 7d1cbe2f4985 ("arm64: dts: qcom: Add X1E78100 ThinkPad T14s Gen 6") Cc: stable(a)vger.kernel.org # 6.12 Reviewed-by: Konrad Dybcio <konrad.dybcio(a)oss.qualcomm.com> Signed-off-by: Johan Hovold <johan+linaro(a)kernel.org> Link: https://lore.kernel.org/r/20250314145440.11371-3-johan+linaro@kernel.org Signed-off-by: Bjorn Andersson <andersson(a)kernel.org> diff --git a/arch/arm64/boot/dts/qcom/x1e78100-lenovo-thinkpad-t14s.dtsi b/arch/arm64/boot/dts/qcom/x1e78100-lenovo-thinkpad-t14s.dtsi index eff0e73640bc..160c052db1ec 100644 --- a/arch/arm64/boot/dts/qcom/x1e78100-lenovo-thinkpad-t14s.dtsi +++ b/arch/arm64/boot/dts/qcom/x1e78100-lenovo-thinkpad-t14s.dtsi @@ -456,6 +456,7 @@ vreg_l12b_1p2: ldo12 { regulator-min-microvolt = <1200000>; regulator-max-microvolt = <1200000>; regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>; + regulator-always-on; }; vreg_l13b_3p0: ldo13 { @@ -477,6 +478,7 @@ vreg_l15b_1p8: ldo15 { regulator-min-microvolt = <1800000>; regulator-max-microvolt = <1800000>; regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>; + regulator-always-on; }; vreg_l17b_2p5: ldo17 {

1 month, 1 week

1
0
0 0

FAILED: patch "[PATCH] arm64: dts: qcom: x1e78100-t14s: mark l12b and l15b always-on" failed to apply to 6.15-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 6.15-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.15.y git checkout FETCH_HEAD git cherry-pick -x 673fa129e558c5f1196adb27d97ac90ddfe4f19c # <resolve conflicts, build, test, etc.> git commit -s git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2025060254-gong-slimy-ea8d@gregkh' --subject-prefix 'PATCH 6.15.y' HEAD^.. Possible dependencies: thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From 673fa129e558c5f1196adb27d97ac90ddfe4f19c Mon Sep 17 00:00:00 2001 From: Johan Hovold <johan+linaro(a)kernel.org> Date: Fri, 14 Mar 2025 15:54:34 +0100 Subject: [PATCH] arm64: dts: qcom: x1e78100-t14s: mark l12b and l15b always-on The l12b and l15b supplies are used by components that are not (fully) described (and some never will be) and must never be disabled. Mark the regulators as always-on to prevent them from being disabled, for example, when consumers probe defer or suspend. Fixes: 7d1cbe2f4985 ("arm64: dts: qcom: Add X1E78100 ThinkPad T14s Gen 6") Cc: stable(a)vger.kernel.org # 6.12 Reviewed-by: Konrad Dybcio <konrad.dybcio(a)oss.qualcomm.com> Signed-off-by: Johan Hovold <johan+linaro(a)kernel.org> Link: https://lore.kernel.org/r/20250314145440.11371-3-johan+linaro@kernel.org Signed-off-by: Bjorn Andersson <andersson(a)kernel.org> diff --git a/arch/arm64/boot/dts/qcom/x1e78100-lenovo-thinkpad-t14s.dtsi b/arch/arm64/boot/dts/qcom/x1e78100-lenovo-thinkpad-t14s.dtsi index eff0e73640bc..160c052db1ec 100644 --- a/arch/arm64/boot/dts/qcom/x1e78100-lenovo-thinkpad-t14s.dtsi +++ b/arch/arm64/boot/dts/qcom/x1e78100-lenovo-thinkpad-t14s.dtsi @@ -456,6 +456,7 @@ vreg_l12b_1p2: ldo12 { regulator-min-microvolt = <1200000>; regulator-max-microvolt = <1200000>; regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>; + regulator-always-on; }; vreg_l13b_3p0: ldo13 { @@ -477,6 +478,7 @@ vreg_l15b_1p8: ldo15 { regulator-min-microvolt = <1800000>; regulator-max-microvolt = <1800000>; regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>; + regulator-always-on; }; vreg_l17b_2p5: ldo17 {

1 month, 1 week

1
0
0 0

FAILED: patch "[PATCH] arm64: dts: qcom: x1e78100-t14s: fix missing HID supplies" 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 55e52d055393f11ba0193975d3db87af36f4b273 # <resolve conflicts, build, test, etc.> git commit -s git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2025060246-overstock-thumping-600e@gregkh' --subject-prefix 'PATCH 6.12.y' HEAD^.. Possible dependencies: thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From 55e52d055393f11ba0193975d3db87af36f4b273 Mon Sep 17 00:00:00 2001 From: Johan Hovold <johan+linaro(a)kernel.org> Date: Fri, 14 Mar 2025 15:54:40 +0100 Subject: [PATCH] arm64: dts: qcom: x1e78100-t14s: fix missing HID supplies Add the missing HID supplies to avoid relying on other consumers to keep them on. This also avoids the following warnings on boot: i2c_hid_of 0-0010: supply vdd not found, using dummy regulator i2c_hid_of 0-0010: supply vddl not found, using dummy regulator i2c_hid_of 1-0015: supply vdd not found, using dummy regulator i2c_hid_of 1-002c: supply vdd not found, using dummy regulator i2c_hid_of 1-0015: supply vddl not found, using dummy regulator i2c_hid_of 1-002c: supply vddl not found, using dummy regulator i2c_hid_of 1-003a: supply vdd not found, using dummy regulator i2c_hid_of 1-003a: supply vddl not found, using dummy regulator Note that VCC3B is also used for things like the modem which are not yet described so mark the regulator as always-on for now. Fixes: 7d1cbe2f4985 ("arm64: dts: qcom: Add X1E78100 ThinkPad T14s Gen 6") Cc: stable(a)vger.kernel.org # 6.12 Reviewed-by: Konrad Dybcio <konrad.dybcio(a)oss.qualcomm.com> Signed-off-by: Johan Hovold <johan+linaro(a)kernel.org> Link: https://lore.kernel.org/r/20250314145440.11371-9-johan+linaro@kernel.org Signed-off-by: Bjorn Andersson <andersson(a)kernel.org> diff --git a/arch/arm64/boot/dts/qcom/x1e78100-lenovo-thinkpad-t14s.dtsi b/arch/arm64/boot/dts/qcom/x1e78100-lenovo-thinkpad-t14s.dtsi index 160c052db1ec..962fb050c55c 100644 --- a/arch/arm64/boot/dts/qcom/x1e78100-lenovo-thinkpad-t14s.dtsi +++ b/arch/arm64/boot/dts/qcom/x1e78100-lenovo-thinkpad-t14s.dtsi @@ -9,6 +9,7 @@ #include <dt-bindings/gpio/gpio.h> #include <dt-bindings/input/gpio-keys.h> #include <dt-bindings/input/input.h> +#include <dt-bindings/pinctrl/qcom,pmic-gpio.h> #include <dt-bindings/regulator/qcom,rpmh-regulator.h> #include "x1e80100.dtsi" @@ -169,6 +170,23 @@ vreg_edp_3p3: regulator-edp-3p3 { regulator-boot-on; }; + vreg_misc_3p3: regulator-misc-3p3 { + compatible = "regulator-fixed"; + + regulator-name = "VCC3B"; + regulator-min-microvolt = <3300000>; + regulator-max-microvolt = <3300000>; + + gpio = <&pm8550ve_8_gpios 6 GPIO_ACTIVE_HIGH>; + enable-active-high; + + pinctrl-0 = <&misc_3p3_reg_en>; + pinctrl-names = "default"; + + regulator-boot-on; + regulator-always-on; + }; + vreg_nvme: regulator-nvme { compatible = "regulator-fixed"; @@ -692,6 +710,9 @@ touchpad@15 { hid-descr-addr = <0x1>; interrupts-extended = <&tlmm 3 IRQ_TYPE_LEVEL_LOW>; + vdd-supply = <&vreg_misc_3p3>; + vddl-supply = <&vreg_l12b_1p2>; + wakeup-source; }; @@ -703,6 +724,9 @@ touchpad@2c { hid-descr-addr = <0x20>; interrupts-extended = <&tlmm 3 IRQ_TYPE_LEVEL_LOW>; + vdd-supply = <&vreg_misc_3p3>; + vddl-supply = <&vreg_l12b_1p2>; + wakeup-source; }; @@ -714,6 +738,9 @@ keyboard@3a { hid-descr-addr = <0x1>; interrupts-extended = <&tlmm 67 IRQ_TYPE_LEVEL_LOW>; + vdd-supply = <&vreg_misc_3p3>; + vddl-supply = <&vreg_l15b_1p8>; + pinctrl-0 = <&kybd_default>; pinctrl-names = "default"; @@ -896,6 +923,9 @@ touchscreen@10 { hid-descr-addr = <0x1>; interrupts-extended = <&tlmm 51 IRQ_TYPE_LEVEL_LOW>; + vdd-supply = <&vreg_misc_3p3>; + vddl-supply = <&vreg_l15b_1p8>; + pinctrl-0 = <&ts0_default>; pinctrl-names = "default"; }; @@ -1037,6 +1067,19 @@ usb0_3p3_reg_en: usb0-3p3-reg-en-state { }; }; +&pm8550ve_8_gpios { + misc_3p3_reg_en: misc-3p3-reg-en-state { + pins = "gpio6"; + function = "normal"; + bias-disable; + drive-push-pull; + input-disable; + output-enable; + power-source = <1>; /* 1.8 V */ + qcom,drive-strength = <PMIC_GPIO_STRENGTH_LOW>; + }; +}; + &pm8550ve_9_gpios { usb0_1p8_reg_en: usb0-1p8-reg-en-state { pins = "gpio8";

1 month, 1 week

1
0
0 0

FAILED: patch "[PATCH] arm64: dts: qcom: x1e78100-t14s: fix missing HID supplies" failed to apply to 6.14-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 6.14-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.14.y git checkout FETCH_HEAD git cherry-pick -x 55e52d055393f11ba0193975d3db87af36f4b273 # <resolve conflicts, build, test, etc.> git commit -s git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2025060244-reconvene-uncork-b34c@gregkh' --subject-prefix 'PATCH 6.14.y' HEAD^.. Possible dependencies: thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From 55e52d055393f11ba0193975d3db87af36f4b273 Mon Sep 17 00:00:00 2001 From: Johan Hovold <johan+linaro(a)kernel.org> Date: Fri, 14 Mar 2025 15:54:40 +0100 Subject: [PATCH] arm64: dts: qcom: x1e78100-t14s: fix missing HID supplies Add the missing HID supplies to avoid relying on other consumers to keep them on. This also avoids the following warnings on boot: i2c_hid_of 0-0010: supply vdd not found, using dummy regulator i2c_hid_of 0-0010: supply vddl not found, using dummy regulator i2c_hid_of 1-0015: supply vdd not found, using dummy regulator i2c_hid_of 1-002c: supply vdd not found, using dummy regulator i2c_hid_of 1-0015: supply vddl not found, using dummy regulator i2c_hid_of 1-002c: supply vddl not found, using dummy regulator i2c_hid_of 1-003a: supply vdd not found, using dummy regulator i2c_hid_of 1-003a: supply vddl not found, using dummy regulator Note that VCC3B is also used for things like the modem which are not yet described so mark the regulator as always-on for now. Fixes: 7d1cbe2f4985 ("arm64: dts: qcom: Add X1E78100 ThinkPad T14s Gen 6") Cc: stable(a)vger.kernel.org # 6.12 Reviewed-by: Konrad Dybcio <konrad.dybcio(a)oss.qualcomm.com> Signed-off-by: Johan Hovold <johan+linaro(a)kernel.org> Link: https://lore.kernel.org/r/20250314145440.11371-9-johan+linaro@kernel.org Signed-off-by: Bjorn Andersson <andersson(a)kernel.org> diff --git a/arch/arm64/boot/dts/qcom/x1e78100-lenovo-thinkpad-t14s.dtsi b/arch/arm64/boot/dts/qcom/x1e78100-lenovo-thinkpad-t14s.dtsi index 160c052db1ec..962fb050c55c 100644 --- a/arch/arm64/boot/dts/qcom/x1e78100-lenovo-thinkpad-t14s.dtsi +++ b/arch/arm64/boot/dts/qcom/x1e78100-lenovo-thinkpad-t14s.dtsi @@ -9,6 +9,7 @@ #include <dt-bindings/gpio/gpio.h> #include <dt-bindings/input/gpio-keys.h> #include <dt-bindings/input/input.h> +#include <dt-bindings/pinctrl/qcom,pmic-gpio.h> #include <dt-bindings/regulator/qcom,rpmh-regulator.h> #include "x1e80100.dtsi" @@ -169,6 +170,23 @@ vreg_edp_3p3: regulator-edp-3p3 { regulator-boot-on; }; + vreg_misc_3p3: regulator-misc-3p3 { + compatible = "regulator-fixed"; + + regulator-name = "VCC3B"; + regulator-min-microvolt = <3300000>; + regulator-max-microvolt = <3300000>; + + gpio = <&pm8550ve_8_gpios 6 GPIO_ACTIVE_HIGH>; + enable-active-high; + + pinctrl-0 = <&misc_3p3_reg_en>; + pinctrl-names = "default"; + + regulator-boot-on; + regulator-always-on; + }; + vreg_nvme: regulator-nvme { compatible = "regulator-fixed"; @@ -692,6 +710,9 @@ touchpad@15 { hid-descr-addr = <0x1>; interrupts-extended = <&tlmm 3 IRQ_TYPE_LEVEL_LOW>; + vdd-supply = <&vreg_misc_3p3>; + vddl-supply = <&vreg_l12b_1p2>; + wakeup-source; }; @@ -703,6 +724,9 @@ touchpad@2c { hid-descr-addr = <0x20>; interrupts-extended = <&tlmm 3 IRQ_TYPE_LEVEL_LOW>; + vdd-supply = <&vreg_misc_3p3>; + vddl-supply = <&vreg_l12b_1p2>; + wakeup-source; }; @@ -714,6 +738,9 @@ keyboard@3a { hid-descr-addr = <0x1>; interrupts-extended = <&tlmm 67 IRQ_TYPE_LEVEL_LOW>; + vdd-supply = <&vreg_misc_3p3>; + vddl-supply = <&vreg_l15b_1p8>; + pinctrl-0 = <&kybd_default>; pinctrl-names = "default"; @@ -896,6 +923,9 @@ touchscreen@10 { hid-descr-addr = <0x1>; interrupts-extended = <&tlmm 51 IRQ_TYPE_LEVEL_LOW>; + vdd-supply = <&vreg_misc_3p3>; + vddl-supply = <&vreg_l15b_1p8>; + pinctrl-0 = <&ts0_default>; pinctrl-names = "default"; }; @@ -1037,6 +1067,19 @@ usb0_3p3_reg_en: usb0-3p3-reg-en-state { }; }; +&pm8550ve_8_gpios { + misc_3p3_reg_en: misc-3p3-reg-en-state { + pins = "gpio6"; + function = "normal"; + bias-disable; + drive-push-pull; + input-disable; + output-enable; + power-source = <1>; /* 1.8 V */ + qcom,drive-strength = <PMIC_GPIO_STRENGTH_LOW>; + }; +}; + &pm8550ve_9_gpios { usb0_1p8_reg_en: usb0-1p8-reg-en-state { pins = "gpio8";

1 month, 1 week

1
0
0 0

FAILED: patch "[PATCH] arm64: dts: qcom: x1e78100-t14s: fix missing HID supplies" failed to apply to 6.15-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 6.15-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.15.y git checkout FETCH_HEAD git cherry-pick -x 55e52d055393f11ba0193975d3db87af36f4b273 # <resolve conflicts, build, test, etc.> git commit -s git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2025060243-cheese-yield-b572@gregkh' --subject-prefix 'PATCH 6.15.y' HEAD^.. Possible dependencies: thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From 55e52d055393f11ba0193975d3db87af36f4b273 Mon Sep 17 00:00:00 2001 From: Johan Hovold <johan+linaro(a)kernel.org> Date: Fri, 14 Mar 2025 15:54:40 +0100 Subject: [PATCH] arm64: dts: qcom: x1e78100-t14s: fix missing HID supplies Add the missing HID supplies to avoid relying on other consumers to keep them on. This also avoids the following warnings on boot: i2c_hid_of 0-0010: supply vdd not found, using dummy regulator i2c_hid_of 0-0010: supply vddl not found, using dummy regulator i2c_hid_of 1-0015: supply vdd not found, using dummy regulator i2c_hid_of 1-002c: supply vdd not found, using dummy regulator i2c_hid_of 1-0015: supply vddl not found, using dummy regulator i2c_hid_of 1-002c: supply vddl not found, using dummy regulator i2c_hid_of 1-003a: supply vdd not found, using dummy regulator i2c_hid_of 1-003a: supply vddl not found, using dummy regulator Note that VCC3B is also used for things like the modem which are not yet described so mark the regulator as always-on for now. Fixes: 7d1cbe2f4985 ("arm64: dts: qcom: Add X1E78100 ThinkPad T14s Gen 6") Cc: stable(a)vger.kernel.org # 6.12 Reviewed-by: Konrad Dybcio <konrad.dybcio(a)oss.qualcomm.com> Signed-off-by: Johan Hovold <johan+linaro(a)kernel.org> Link: https://lore.kernel.org/r/20250314145440.11371-9-johan+linaro@kernel.org Signed-off-by: Bjorn Andersson <andersson(a)kernel.org> diff --git a/arch/arm64/boot/dts/qcom/x1e78100-lenovo-thinkpad-t14s.dtsi b/arch/arm64/boot/dts/qcom/x1e78100-lenovo-thinkpad-t14s.dtsi index 160c052db1ec..962fb050c55c 100644 --- a/arch/arm64/boot/dts/qcom/x1e78100-lenovo-thinkpad-t14s.dtsi +++ b/arch/arm64/boot/dts/qcom/x1e78100-lenovo-thinkpad-t14s.dtsi @@ -9,6 +9,7 @@ #include <dt-bindings/gpio/gpio.h> #include <dt-bindings/input/gpio-keys.h> #include <dt-bindings/input/input.h> +#include <dt-bindings/pinctrl/qcom,pmic-gpio.h> #include <dt-bindings/regulator/qcom,rpmh-regulator.h> #include "x1e80100.dtsi" @@ -169,6 +170,23 @@ vreg_edp_3p3: regulator-edp-3p3 { regulator-boot-on; }; + vreg_misc_3p3: regulator-misc-3p3 { + compatible = "regulator-fixed"; + + regulator-name = "VCC3B"; + regulator-min-microvolt = <3300000>; + regulator-max-microvolt = <3300000>; + + gpio = <&pm8550ve_8_gpios 6 GPIO_ACTIVE_HIGH>; + enable-active-high; + + pinctrl-0 = <&misc_3p3_reg_en>; + pinctrl-names = "default"; + + regulator-boot-on; + regulator-always-on; + }; + vreg_nvme: regulator-nvme { compatible = "regulator-fixed"; @@ -692,6 +710,9 @@ touchpad@15 { hid-descr-addr = <0x1>; interrupts-extended = <&tlmm 3 IRQ_TYPE_LEVEL_LOW>; + vdd-supply = <&vreg_misc_3p3>; + vddl-supply = <&vreg_l12b_1p2>; + wakeup-source; }; @@ -703,6 +724,9 @@ touchpad@2c { hid-descr-addr = <0x20>; interrupts-extended = <&tlmm 3 IRQ_TYPE_LEVEL_LOW>; + vdd-supply = <&vreg_misc_3p3>; + vddl-supply = <&vreg_l12b_1p2>; + wakeup-source; }; @@ -714,6 +738,9 @@ keyboard@3a { hid-descr-addr = <0x1>; interrupts-extended = <&tlmm 67 IRQ_TYPE_LEVEL_LOW>; + vdd-supply = <&vreg_misc_3p3>; + vddl-supply = <&vreg_l15b_1p8>; + pinctrl-0 = <&kybd_default>; pinctrl-names = "default"; @@ -896,6 +923,9 @@ touchscreen@10 { hid-descr-addr = <0x1>; interrupts-extended = <&tlmm 51 IRQ_TYPE_LEVEL_LOW>; + vdd-supply = <&vreg_misc_3p3>; + vddl-supply = <&vreg_l15b_1p8>; + pinctrl-0 = <&ts0_default>; pinctrl-names = "default"; }; @@ -1037,6 +1067,19 @@ usb0_3p3_reg_en: usb0-3p3-reg-en-state { }; }; +&pm8550ve_8_gpios { + misc_3p3_reg_en: misc-3p3-reg-en-state { + pins = "gpio6"; + function = "normal"; + bias-disable; + drive-push-pull; + input-disable; + output-enable; + power-source = <1>; /* 1.8 V */ + qcom,drive-strength = <PMIC_GPIO_STRENGTH_LOW>; + }; +}; + &pm8550ve_9_gpios { usb0_1p8_reg_en: usb0-1p8-reg-en-state { pins = "gpio8";

1 month, 1 week

1
0
0 0

FAILED: patch "[PATCH] arm64: dts: qcom: x1-crd: Fix vreg_l2j_1p2 voltage" 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 5ce920e6a8db40e4b094c0d863cbd19fdcfbbb7a # <resolve conflicts, build, test, etc.> git commit -s git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2025060236-resale-proactive-e484@gregkh' --subject-prefix 'PATCH 6.12.y' HEAD^.. Possible dependencies: thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From 5ce920e6a8db40e4b094c0d863cbd19fdcfbbb7a Mon Sep 17 00:00:00 2001 From: Stephan Gerhold <stephan.gerhold(a)linaro.org> Date: Wed, 23 Apr 2025 09:30:07 +0200 Subject: [PATCH] arm64: dts: qcom: x1-crd: Fix vreg_l2j_1p2 voltage In the ACPI DSDT table, PPP_RESOURCE_ID_LDO2_J is configured with 1256000 uV instead of the 1200000 uV we have currently in the device tree. Use the same for consistency and correctness. Cc: stable(a)vger.kernel.org Fixes: bd50b1f5b6f3 ("arm64: dts: qcom: x1e80100: Add Compute Reference Device") Signed-off-by: Stephan Gerhold <stephan.gerhold(a)linaro.org> Reviewed-by: Johan Hovold <johan+linaro(a)kernel.org> Reviewed-by: Abel Vesa <abel.vesa(a)linaro.org> Reviewed-by: Konrad Dybcio <konrad.dybcio(a)oss.qualcomm.com> Link: https://lore.kernel.org/r/20250423-x1e-vreg-l2j-voltage-v1-1-24b6a2043025@l… Signed-off-by: Bjorn Andersson <andersson(a)kernel.org> diff --git a/arch/arm64/boot/dts/qcom/x1-crd.dtsi b/arch/arm64/boot/dts/qcom/x1-crd.dtsi index f73f053a46a0..dbdf542c7ce5 100644 --- a/arch/arm64/boot/dts/qcom/x1-crd.dtsi +++ b/arch/arm64/boot/dts/qcom/x1-crd.dtsi @@ -846,8 +846,8 @@ vreg_l1j_0p8: ldo1 { vreg_l2j_1p2: ldo2 { regulator-name = "vreg_l2j_1p2"; - regulator-min-microvolt = <1200000>; - regulator-max-microvolt = <1200000>; + regulator-min-microvolt = <1256000>; + regulator-max-microvolt = <1256000>; regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>; };

1 month, 1 week

1
0
0 0

FAILED: patch "[PATCH] arm64: dts: qcom: x1-crd: Fix vreg_l2j_1p2 voltage" failed to apply to 6.15-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 6.15-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.15.y git checkout FETCH_HEAD git cherry-pick -x 5ce920e6a8db40e4b094c0d863cbd19fdcfbbb7a # <resolve conflicts, build, test, etc.> git commit -s git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2025060236-coat-unsterile-20f5@gregkh' --subject-prefix 'PATCH 6.15.y' HEAD^.. Possible dependencies: thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From 5ce920e6a8db40e4b094c0d863cbd19fdcfbbb7a Mon Sep 17 00:00:00 2001 From: Stephan Gerhold <stephan.gerhold(a)linaro.org> Date: Wed, 23 Apr 2025 09:30:07 +0200 Subject: [PATCH] arm64: dts: qcom: x1-crd: Fix vreg_l2j_1p2 voltage In the ACPI DSDT table, PPP_RESOURCE_ID_LDO2_J is configured with 1256000 uV instead of the 1200000 uV we have currently in the device tree. Use the same for consistency and correctness. Cc: stable(a)vger.kernel.org Fixes: bd50b1f5b6f3 ("arm64: dts: qcom: x1e80100: Add Compute Reference Device") Signed-off-by: Stephan Gerhold <stephan.gerhold(a)linaro.org> Reviewed-by: Johan Hovold <johan+linaro(a)kernel.org> Reviewed-by: Abel Vesa <abel.vesa(a)linaro.org> Reviewed-by: Konrad Dybcio <konrad.dybcio(a)oss.qualcomm.com> Link: https://lore.kernel.org/r/20250423-x1e-vreg-l2j-voltage-v1-1-24b6a2043025@l… Signed-off-by: Bjorn Andersson <andersson(a)kernel.org> diff --git a/arch/arm64/boot/dts/qcom/x1-crd.dtsi b/arch/arm64/boot/dts/qcom/x1-crd.dtsi index f73f053a46a0..dbdf542c7ce5 100644 --- a/arch/arm64/boot/dts/qcom/x1-crd.dtsi +++ b/arch/arm64/boot/dts/qcom/x1-crd.dtsi @@ -846,8 +846,8 @@ vreg_l1j_0p8: ldo1 { vreg_l2j_1p2: ldo2 { regulator-name = "vreg_l2j_1p2"; - regulator-min-microvolt = <1200000>; - regulator-max-microvolt = <1200000>; + regulator-min-microvolt = <1256000>; + regulator-max-microvolt = <1256000>; regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>; };

1 month, 1 week

1
0
0 0

FAILED: patch "[PATCH] arm64: dts: qcom: x1-crd: Fix vreg_l2j_1p2 voltage" failed to apply to 6.14-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 6.14-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.14.y git checkout FETCH_HEAD git cherry-pick -x 5ce920e6a8db40e4b094c0d863cbd19fdcfbbb7a # <resolve conflicts, build, test, etc.> git commit -s git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2025060236-swimming-deodorize-a6f9@gregkh' --subject-prefix 'PATCH 6.14.y' HEAD^.. Possible dependencies: thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From 5ce920e6a8db40e4b094c0d863cbd19fdcfbbb7a Mon Sep 17 00:00:00 2001 From: Stephan Gerhold <stephan.gerhold(a)linaro.org> Date: Wed, 23 Apr 2025 09:30:07 +0200 Subject: [PATCH] arm64: dts: qcom: x1-crd: Fix vreg_l2j_1p2 voltage In the ACPI DSDT table, PPP_RESOURCE_ID_LDO2_J is configured with 1256000 uV instead of the 1200000 uV we have currently in the device tree. Use the same for consistency and correctness. Cc: stable(a)vger.kernel.org Fixes: bd50b1f5b6f3 ("arm64: dts: qcom: x1e80100: Add Compute Reference Device") Signed-off-by: Stephan Gerhold <stephan.gerhold(a)linaro.org> Reviewed-by: Johan Hovold <johan+linaro(a)kernel.org> Reviewed-by: Abel Vesa <abel.vesa(a)linaro.org> Reviewed-by: Konrad Dybcio <konrad.dybcio(a)oss.qualcomm.com> Link: https://lore.kernel.org/r/20250423-x1e-vreg-l2j-voltage-v1-1-24b6a2043025@l… Signed-off-by: Bjorn Andersson <andersson(a)kernel.org> diff --git a/arch/arm64/boot/dts/qcom/x1-crd.dtsi b/arch/arm64/boot/dts/qcom/x1-crd.dtsi index f73f053a46a0..dbdf542c7ce5 100644 --- a/arch/arm64/boot/dts/qcom/x1-crd.dtsi +++ b/arch/arm64/boot/dts/qcom/x1-crd.dtsi @@ -846,8 +846,8 @@ vreg_l1j_0p8: ldo1 { vreg_l2j_1p2: ldo2 { regulator-name = "vreg_l2j_1p2"; - regulator-min-microvolt = <1200000>; - regulator-max-microvolt = <1200000>; + regulator-min-microvolt = <1256000>; + regulator-max-microvolt = <1256000>; regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>; };

1 month, 1 week

1
0
0 0

FAILED: patch "[PATCH] arm64: dts: ti: k3-am65-main: Add missing taps to sdhci0" failed to apply to 5.15-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 5.15-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-5.15.y git checkout FETCH_HEAD git cherry-pick -x f55c9f087cc2e2252d44ffd9d58def2066fc176e # <resolve conflicts, build, test, etc.> git commit -s git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2025060219-mustang-rocker-6ae2@gregkh' --subject-prefix 'PATCH 5.15.y' HEAD^.. Possible dependencies: thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From f55c9f087cc2e2252d44ffd9d58def2066fc176e Mon Sep 17 00:00:00 2001 From: Judith Mendez <jm(a)ti.com> Date: Tue, 29 Apr 2025 12:30:08 -0500 Subject: [PATCH] arm64: dts: ti: k3-am65-main: Add missing taps to sdhci0 For am65x, add missing ITAPDLYSEL values for Default Speed and High Speed SDR modes to sdhci0 node according to the device datasheet [0]. [0] https://www.ti.com/lit/gpn/am6548 Fixes: eac99d38f861 ("arm64: dts: ti: k3-am654-main: Update otap-del-sel values") Cc: stable(a)vger.kernel.org Signed-off-by: Judith Mendez <jm(a)ti.com> Reviewed-by: Moteen Shah <m-shah(a)ti.com> Link: https://lore.kernel.org/r/20250429173009.33994-1-jm@ti.com Signed-off-by: Nishanth Menon <nm(a)ti.com> diff --git a/arch/arm64/boot/dts/ti/k3-am65-main.dtsi b/arch/arm64/boot/dts/ti/k3-am65-main.dtsi index 6d3c467d7038..b085e7361116 100644 --- a/arch/arm64/boot/dts/ti/k3-am65-main.dtsi +++ b/arch/arm64/boot/dts/ti/k3-am65-main.dtsi @@ -449,6 +449,8 @@ sdhci0: mmc@4f80000 { ti,otap-del-sel-mmc-hs = <0x0>; ti,otap-del-sel-ddr52 = <0x5>; ti,otap-del-sel-hs200 = <0x5>; + ti,itap-del-sel-legacy = <0xa>; + ti,itap-del-sel-mmc-hs = <0x1>; ti,itap-del-sel-ddr52 = <0x0>; dma-coherent; status = "disabled";

1 month, 1 week

1
0
0 0

FAILED: patch "[PATCH] arm64: dts: ti: k3-am62-main: Set eMMC clock parent to" 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 3a71cdfec94436079513d9adf4b1d4f7a7edd917 # <resolve conflicts, build, test, etc.> git commit -s git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2025060230-demote-sappiness-b940@gregkh' --subject-prefix 'PATCH 6.6.y' HEAD^.. Possible dependencies: thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From 3a71cdfec94436079513d9adf4b1d4f7a7edd917 Mon Sep 17 00:00:00 2001 From: Judith Mendez <jm(a)ti.com> Date: Tue, 29 Apr 2025 11:33:35 -0500 Subject: [PATCH] arm64: dts: ti: k3-am62-main: Set eMMC clock parent to default Set eMMC clock parents to the defaults which is MAIN_PLL0_HSDIV5_CLKOUT for eMMC. This change is necessary since DM is not implementing the correct procedure to switch PLL clock source for eMMC and MMC CLK mux is not glich-free. As a preventative action, lets switch back to the defaults. Fixes: c37c58fdeb8a ("arm64: dts: ti: k3-am62: Add more peripheral nodes") Cc: stable(a)vger.kernel.org Signed-off-by: Judith Mendez <jm(a)ti.com> Acked-by: Udit Kumar <u-kumar1(a)ti.com> Acked-by: Bryan Brattlof <bb(a)ti.com> Link: https://lore.kernel.org/r/20250429163337.15634-2-jm@ti.com Signed-off-by: Nishanth Menon <nm(a)ti.com> diff --git a/arch/arm64/boot/dts/ti/k3-am62-main.dtsi b/arch/arm64/boot/dts/ti/k3-am62-main.dtsi index 7d355aa73ea2..0c286f600296 100644 --- a/arch/arm64/boot/dts/ti/k3-am62-main.dtsi +++ b/arch/arm64/boot/dts/ti/k3-am62-main.dtsi @@ -552,8 +552,6 @@ sdhci0: mmc@fa10000 { power-domains = <&k3_pds 57 TI_SCI_PD_EXCLUSIVE>; clocks = <&k3_clks 57 5>, <&k3_clks 57 6>; clock-names = "clk_ahb", "clk_xin"; - assigned-clocks = <&k3_clks 57 6>; - assigned-clock-parents = <&k3_clks 57 8>; bus-width = <8>; mmc-ddr-1_8v; mmc-hs200-1_8v;

1 month, 1 week

1
0
0 0

FAILED: patch "[PATCH] arm64: dts: qcom: x1e80100: Add GPU cooling" 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 5ba21fa11f473c9827f378ace8c9f983de9e0287 # <resolve conflicts, build, test, etc.> git commit -s git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2025060212-chamomile-scorecard-ba20@gregkh' --subject-prefix 'PATCH 6.12.y' HEAD^.. Possible dependencies: thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From 5ba21fa11f473c9827f378ace8c9f983de9e0287 Mon Sep 17 00:00:00 2001 From: Stephan Gerhold <stephan.gerhold(a)linaro.org> Date: Wed, 19 Feb 2025 12:36:20 +0100 Subject: [PATCH] arm64: dts: qcom: x1e80100: Add GPU cooling MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Unlike the CPU, the GPU does not throttle its speed automatically when it reaches high temperatures. With certain high GPU loads it is possible to reach the critical hardware shutdown temperature of 120°C, endangering the hardware and making it impossible to run certain applications. Set up GPU cooling similar to the ACPI tables, by throttling the GPU speed when reaching 95°C and polling every 200ms. Cc: stable(a)vger.kernel.org Fixes: 721e38301b79 ("arm64: dts: qcom: x1e80100: Add gpu support") Signed-off-by: Stephan Gerhold <stephan.gerhold(a)linaro.org> Reviewed-by: Johan Hovold <johan+linaro(a)kernel.org> Reviewed-by: Konrad Dybcio <konrad.dybcio(a)oss.qualcomm.com> Link: https://lore.kernel.org/r/20250219-x1e80100-thermal-fixes-v1-3-d110e44ac3f9… Signed-off-by: Bjorn Andersson <andersson(a)kernel.org> diff --git a/arch/arm64/boot/dts/qcom/x1e80100.dtsi b/arch/arm64/boot/dts/qcom/x1e80100.dtsi index e0ef5665f862..9382a2fce2f3 100644 --- a/arch/arm64/boot/dts/qcom/x1e80100.dtsi +++ b/arch/arm64/boot/dts/qcom/x1e80100.dtsi @@ -20,6 +20,7 @@ #include <dt-bindings/soc/qcom,gpr.h> #include <dt-bindings/soc/qcom,rpmh-rsc.h> #include <dt-bindings/sound/qcom,q6dsp-lpass-ports.h> +#include <dt-bindings/thermal/thermal.h> / { interrupt-parent = <&intc>; @@ -9372,24 +9373,25 @@ nsp3-critical { }; gpuss-0-thermal { - polling-delay-passive = <10>; + polling-delay-passive = <200>; thermal-sensors = <&tsens3 5>; + cooling-maps { + map0 { + trip = <&gpuss0_alert0>; + cooling-device = <&gpu THERMAL_NO_LIMIT THERMAL_NO_LIMIT>; + }; + }; + trips { - trip-point0 { - temperature = <85000>; + gpuss0_alert0: trip-point0 { + temperature = <95000>; hysteresis = <1000>; type = "passive"; }; - trip-point1 { - temperature = <90000>; - hysteresis = <1000>; - type = "hot"; - }; - - trip-point2 { + gpu-critical { temperature = <115000>; hysteresis = <1000>; type = "critical"; @@ -9398,24 +9400,25 @@ trip-point2 { }; gpuss-1-thermal { - polling-delay-passive = <10>; + polling-delay-passive = <200>; thermal-sensors = <&tsens3 6>; + cooling-maps { + map0 { + trip = <&gpuss1_alert0>; + cooling-device = <&gpu THERMAL_NO_LIMIT THERMAL_NO_LIMIT>; + }; + }; + trips { - trip-point0 { - temperature = <85000>; + gpuss1_alert0: trip-point0 { + temperature = <95000>; hysteresis = <1000>; type = "passive"; }; - trip-point1 { - temperature = <90000>; - hysteresis = <1000>; - type = "hot"; - }; - - trip-point2 { + gpu-critical { temperature = <115000>; hysteresis = <1000>; type = "critical"; @@ -9424,24 +9427,25 @@ trip-point2 { }; gpuss-2-thermal { - polling-delay-passive = <10>; + polling-delay-passive = <200>; thermal-sensors = <&tsens3 7>; + cooling-maps { + map0 { + trip = <&gpuss2_alert0>; + cooling-device = <&gpu THERMAL_NO_LIMIT THERMAL_NO_LIMIT>; + }; + }; + trips { - trip-point0 { - temperature = <85000>; + gpuss2_alert0: trip-point0 { + temperature = <95000>; hysteresis = <1000>; type = "passive"; }; - trip-point1 { - temperature = <90000>; - hysteresis = <1000>; - type = "hot"; - }; - - trip-point2 { + gpu-critical { temperature = <115000>; hysteresis = <1000>; type = "critical"; @@ -9450,24 +9454,25 @@ trip-point2 { }; gpuss-3-thermal { - polling-delay-passive = <10>; + polling-delay-passive = <200>; thermal-sensors = <&tsens3 8>; + cooling-maps { + map0 { + trip = <&gpuss3_alert0>; + cooling-device = <&gpu THERMAL_NO_LIMIT THERMAL_NO_LIMIT>; + }; + }; + trips { - trip-point0 { - temperature = <85000>; + gpuss3_alert0: trip-point0 { + temperature = <95000>; hysteresis = <1000>; type = "passive"; }; - trip-point1 { - temperature = <90000>; - hysteresis = <1000>; - type = "hot"; - }; - - trip-point2 { + gpu-critical { temperature = <115000>; hysteresis = <1000>; type = "critical"; @@ -9476,24 +9481,25 @@ trip-point2 { }; gpuss-4-thermal { - polling-delay-passive = <10>; + polling-delay-passive = <200>; thermal-sensors = <&tsens3 9>; + cooling-maps { + map0 { + trip = <&gpuss4_alert0>; + cooling-device = <&gpu THERMAL_NO_LIMIT THERMAL_NO_LIMIT>; + }; + }; + trips { - trip-point0 { - temperature = <85000>; + gpuss4_alert0: trip-point0 { + temperature = <95000>; hysteresis = <1000>; type = "passive"; }; - trip-point1 { - temperature = <90000>; - hysteresis = <1000>; - type = "hot"; - }; - - trip-point2 { + gpu-critical { temperature = <115000>; hysteresis = <1000>; type = "critical"; @@ -9502,24 +9508,25 @@ trip-point2 { }; gpuss-5-thermal { - polling-delay-passive = <10>; + polling-delay-passive = <200>; thermal-sensors = <&tsens3 10>; + cooling-maps { + map0 { + trip = <&gpuss5_alert0>; + cooling-device = <&gpu THERMAL_NO_LIMIT THERMAL_NO_LIMIT>; + }; + }; + trips { - trip-point0 { - temperature = <85000>; + gpuss5_alert0: trip-point0 { + temperature = <95000>; hysteresis = <1000>; type = "passive"; }; - trip-point1 { - temperature = <90000>; - hysteresis = <1000>; - type = "hot"; - }; - - trip-point2 { + gpu-critical { temperature = <115000>; hysteresis = <1000>; type = "critical"; @@ -9528,24 +9535,25 @@ trip-point2 { }; gpuss-6-thermal { - polling-delay-passive = <10>; + polling-delay-passive = <200>; thermal-sensors = <&tsens3 11>; + cooling-maps { + map0 { + trip = <&gpuss6_alert0>; + cooling-device = <&gpu THERMAL_NO_LIMIT THERMAL_NO_LIMIT>; + }; + }; + trips { - trip-point0 { - temperature = <85000>; + gpuss6_alert0: trip-point0 { + temperature = <95000>; hysteresis = <1000>; type = "passive"; }; - trip-point1 { - temperature = <90000>; - hysteresis = <1000>; - type = "hot"; - }; - - trip-point2 { + gpu-critical { temperature = <115000>; hysteresis = <1000>; type = "critical"; @@ -9554,24 +9562,25 @@ trip-point2 { }; gpuss-7-thermal { - polling-delay-passive = <10>; + polling-delay-passive = <200>; thermal-sensors = <&tsens3 12>; + cooling-maps { + map0 { + trip = <&gpuss7_alert0>; + cooling-device = <&gpu THERMAL_NO_LIMIT THERMAL_NO_LIMIT>; + }; + }; + trips { - trip-point0 { - temperature = <85000>; + gpuss7_alert0: trip-point0 { + temperature = <95000>; hysteresis = <1000>; type = "passive"; }; - trip-point1 { - temperature = <90000>; - hysteresis = <1000>; - type = "hot"; - }; - - trip-point2 { + gpu-critical { temperature = <115000>; hysteresis = <1000>; type = "critical";

1 month, 1 week

1
0
0 0

FAILED: patch "[PATCH] arm64: dts: qcom: x1e80100: Apply consistent critical thermal" 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 03f2b8eed73418269a158ccebad5d8d8f2f6daa1 # <resolve conflicts, build, test, etc.> git commit -s git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2025060201-critter-racoon-92e9@gregkh' --subject-prefix 'PATCH 6.12.y' HEAD^.. Possible dependencies: thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From 03f2b8eed73418269a158ccebad5d8d8f2f6daa1 Mon Sep 17 00:00:00 2001 From: Stephan Gerhold <stephan.gerhold(a)linaro.org> Date: Wed, 19 Feb 2025 12:36:19 +0100 Subject: [PATCH] arm64: dts: qcom: x1e80100: Apply consistent critical thermal shutdown MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit The firmware configures the TSENS controller with a maximum temperature of 120°C. When reaching that temperature, the hardware automatically triggers a reset of the entire platform. Some of the thermal zones in x1e80100.dtsi use a critical trip point of 125°C. It's impossible to reach those. It's preferable to shut down the system cleanly before reaching the hardware trip point. Make the critical temperature trip points consistent by setting all of them to 115°C and apply a consistent hysteresis. The ACPI tables also specify 115°C as critical shutdown temperature. Cc: stable(a)vger.kernel.org Fixes: 4e915987ff5b ("arm64: dts: qcom: x1e80100: Enable tsens and thermal zone nodes") Signed-off-by: Stephan Gerhold <stephan.gerhold(a)linaro.org> Reviewed-by: Johan Hovold <johan+linaro(a)kernel.org> Reviewed-by: Konrad Dybcio <konrad.dybcio(a)oss.qualcomm.com> Link: https://lore.kernel.org/r/20250219-x1e80100-thermal-fixes-v1-2-d110e44ac3f9… Signed-off-by: Bjorn Andersson <andersson(a)kernel.org> diff --git a/arch/arm64/boot/dts/qcom/x1e80100.dtsi b/arch/arm64/boot/dts/qcom/x1e80100.dtsi index 7d750a899e80..e0ef5665f862 100644 --- a/arch/arm64/boot/dts/qcom/x1e80100.dtsi +++ b/arch/arm64/boot/dts/qcom/x1e80100.dtsi @@ -8470,8 +8470,8 @@ trip-point0 { }; aoss0-critical { - temperature = <125000>; - hysteresis = <0>; + temperature = <115000>; + hysteresis = <1000>; type = "critical"; }; }; @@ -8496,7 +8496,7 @@ trip-point1 { }; cpu-critical { - temperature = <110000>; + temperature = <115000>; hysteresis = <1000>; type = "critical"; }; @@ -8522,7 +8522,7 @@ trip-point1 { }; cpu-critical { - temperature = <110000>; + temperature = <115000>; hysteresis = <1000>; type = "critical"; }; @@ -8548,7 +8548,7 @@ trip-point1 { }; cpu-critical { - temperature = <110000>; + temperature = <115000>; hysteresis = <1000>; type = "critical"; }; @@ -8574,7 +8574,7 @@ trip-point1 { }; cpu-critical { - temperature = <110000>; + temperature = <115000>; hysteresis = <1000>; type = "critical"; }; @@ -8600,7 +8600,7 @@ trip-point1 { }; cpu-critical { - temperature = <110000>; + temperature = <115000>; hysteresis = <1000>; type = "critical"; }; @@ -8626,7 +8626,7 @@ trip-point1 { }; cpu-critical { - temperature = <110000>; + temperature = <115000>; hysteresis = <1000>; type = "critical"; }; @@ -8652,7 +8652,7 @@ trip-point1 { }; cpu-critical { - temperature = <110000>; + temperature = <115000>; hysteresis = <1000>; type = "critical"; }; @@ -8678,7 +8678,7 @@ trip-point1 { }; cpu-critical { - temperature = <110000>; + temperature = <115000>; hysteresis = <1000>; type = "critical"; }; @@ -8696,8 +8696,8 @@ trip-point0 { }; cpuss2-critical { - temperature = <125000>; - hysteresis = <0>; + temperature = <115000>; + hysteresis = <1000>; type = "critical"; }; }; @@ -8714,8 +8714,8 @@ trip-point0 { }; cpuss2-critical { - temperature = <125000>; - hysteresis = <0>; + temperature = <115000>; + hysteresis = <1000>; type = "critical"; }; }; @@ -8732,7 +8732,7 @@ trip-point0 { }; mem-critical { - temperature = <125000>; + temperature = <115000>; hysteresis = <0>; type = "critical"; }; @@ -8750,7 +8750,7 @@ trip-point0 { }; video-critical { - temperature = <125000>; + temperature = <115000>; hysteresis = <1000>; type = "critical"; }; @@ -8768,8 +8768,8 @@ trip-point0 { }; aoss0-critical { - temperature = <125000>; - hysteresis = <0>; + temperature = <115000>; + hysteresis = <1000>; type = "critical"; }; }; @@ -8794,7 +8794,7 @@ trip-point1 { }; cpu-critical { - temperature = <110000>; + temperature = <115000>; hysteresis = <1000>; type = "critical"; }; @@ -8820,7 +8820,7 @@ trip-point1 { }; cpu-critical { - temperature = <110000>; + temperature = <115000>; hysteresis = <1000>; type = "critical"; }; @@ -8846,7 +8846,7 @@ trip-point1 { }; cpu-critical { - temperature = <110000>; + temperature = <115000>; hysteresis = <1000>; type = "critical"; }; @@ -8872,7 +8872,7 @@ trip-point1 { }; cpu-critical { - temperature = <110000>; + temperature = <115000>; hysteresis = <1000>; type = "critical"; }; @@ -8898,7 +8898,7 @@ trip-point1 { }; cpu-critical { - temperature = <110000>; + temperature = <115000>; hysteresis = <1000>; type = "critical"; }; @@ -8924,7 +8924,7 @@ trip-point1 { }; cpu-critical { - temperature = <110000>; + temperature = <115000>; hysteresis = <1000>; type = "critical"; }; @@ -8950,7 +8950,7 @@ trip-point1 { }; cpu-critical { - temperature = <110000>; + temperature = <115000>; hysteresis = <1000>; type = "critical"; }; @@ -8976,7 +8976,7 @@ trip-point1 { }; cpu-critical { - temperature = <110000>; + temperature = <115000>; hysteresis = <1000>; type = "critical"; }; @@ -8994,8 +8994,8 @@ trip-point0 { }; cpuss2-critical { - temperature = <125000>; - hysteresis = <0>; + temperature = <115000>; + hysteresis = <1000>; type = "critical"; }; }; @@ -9012,8 +9012,8 @@ trip-point0 { }; cpuss2-critical { - temperature = <125000>; - hysteresis = <0>; + temperature = <115000>; + hysteresis = <1000>; type = "critical"; }; }; @@ -9030,8 +9030,8 @@ trip-point0 { }; aoss0-critical { - temperature = <125000>; - hysteresis = <0>; + temperature = <115000>; + hysteresis = <1000>; type = "critical"; }; }; @@ -9056,7 +9056,7 @@ trip-point1 { }; cpu-critical { - temperature = <110000>; + temperature = <115000>; hysteresis = <1000>; type = "critical"; }; @@ -9082,7 +9082,7 @@ trip-point1 { }; cpu-critical { - temperature = <110000>; + temperature = <115000>; hysteresis = <1000>; type = "critical"; }; @@ -9108,7 +9108,7 @@ trip-point1 { }; cpu-critical { - temperature = <110000>; + temperature = <115000>; hysteresis = <1000>; type = "critical"; }; @@ -9134,7 +9134,7 @@ trip-point1 { }; cpu-critical { - temperature = <110000>; + temperature = <115000>; hysteresis = <1000>; type = "critical"; }; @@ -9160,7 +9160,7 @@ trip-point1 { }; cpu-critical { - temperature = <110000>; + temperature = <115000>; hysteresis = <1000>; type = "critical"; }; @@ -9186,7 +9186,7 @@ trip-point1 { }; cpu-critical { - temperature = <110000>; + temperature = <115000>; hysteresis = <1000>; type = "critical"; }; @@ -9212,7 +9212,7 @@ trip-point1 { }; cpu-critical { - temperature = <110000>; + temperature = <115000>; hysteresis = <1000>; type = "critical"; }; @@ -9238,7 +9238,7 @@ trip-point1 { }; cpu-critical { - temperature = <110000>; + temperature = <115000>; hysteresis = <1000>; type = "critical"; }; @@ -9256,8 +9256,8 @@ trip-point0 { }; cpuss2-critical { - temperature = <125000>; - hysteresis = <0>; + temperature = <115000>; + hysteresis = <1000>; type = "critical"; }; }; @@ -9274,8 +9274,8 @@ trip-point0 { }; cpuss2-critical { - temperature = <125000>; - hysteresis = <0>; + temperature = <115000>; + hysteresis = <1000>; type = "critical"; }; }; @@ -9292,8 +9292,8 @@ trip-point0 { }; aoss0-critical { - temperature = <125000>; - hysteresis = <0>; + temperature = <115000>; + hysteresis = <1000>; type = "critical"; }; }; @@ -9310,8 +9310,8 @@ trip-point0 { }; nsp0-critical { - temperature = <125000>; - hysteresis = <0>; + temperature = <115000>; + hysteresis = <1000>; type = "critical"; }; }; @@ -9328,8 +9328,8 @@ trip-point0 { }; nsp1-critical { - temperature = <125000>; - hysteresis = <0>; + temperature = <115000>; + hysteresis = <1000>; type = "critical"; }; }; @@ -9346,8 +9346,8 @@ trip-point0 { }; nsp2-critical { - temperature = <125000>; - hysteresis = <0>; + temperature = <115000>; + hysteresis = <1000>; type = "critical"; }; }; @@ -9364,8 +9364,8 @@ trip-point0 { }; nsp3-critical { - temperature = <125000>; - hysteresis = <0>; + temperature = <115000>; + hysteresis = <1000>; type = "critical"; }; }; @@ -9390,7 +9390,7 @@ trip-point1 { }; trip-point2 { - temperature = <125000>; + temperature = <115000>; hysteresis = <1000>; type = "critical"; }; @@ -9416,7 +9416,7 @@ trip-point1 { }; trip-point2 { - temperature = <125000>; + temperature = <115000>; hysteresis = <1000>; type = "critical"; }; @@ -9442,7 +9442,7 @@ trip-point1 { }; trip-point2 { - temperature = <125000>; + temperature = <115000>; hysteresis = <1000>; type = "critical"; }; @@ -9468,7 +9468,7 @@ trip-point1 { }; trip-point2 { - temperature = <125000>; + temperature = <115000>; hysteresis = <1000>; type = "critical"; }; @@ -9494,7 +9494,7 @@ trip-point1 { }; trip-point2 { - temperature = <125000>; + temperature = <115000>; hysteresis = <1000>; type = "critical"; }; @@ -9520,7 +9520,7 @@ trip-point1 { }; trip-point2 { - temperature = <125000>; + temperature = <115000>; hysteresis = <1000>; type = "critical"; }; @@ -9546,7 +9546,7 @@ trip-point1 { }; trip-point2 { - temperature = <125000>; + temperature = <115000>; hysteresis = <1000>; type = "critical"; }; @@ -9572,7 +9572,7 @@ trip-point1 { }; trip-point2 { - temperature = <125000>; + temperature = <115000>; hysteresis = <1000>; type = "critical"; }; @@ -9591,7 +9591,7 @@ trip-point0 { camera0-critical { temperature = <115000>; - hysteresis = <0>; + hysteresis = <1000>; type = "critical"; }; }; @@ -9609,7 +9609,7 @@ trip-point0 { camera0-critical { temperature = <115000>; - hysteresis = <0>; + hysteresis = <1000>; type = "critical"; }; };

1 month, 1 week

1
0
0 0

FAILED: patch "[PATCH] arm64: dts: rockchip: fix internal USB hub instability on" failed to apply to 5.4-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 5.4-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-5.4.y git checkout FETCH_HEAD git cherry-pick -x d7cc532df95f7f159e40595440e4e4b99481457b # <resolve conflicts, build, test, etc.> git commit -s git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2025060238-graffiti-woof-6b4f@gregkh' --subject-prefix 'PATCH 5.4.y' HEAD^.. Possible dependencies: thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From d7cc532df95f7f159e40595440e4e4b99481457b Mon Sep 17 00:00:00 2001 From: Lukasz Czechowski <lukasz.czechowski(a)thaumatec.com> Date: Fri, 25 Apr 2025 17:18:08 +0200 Subject: [PATCH] arm64: dts: rockchip: fix internal USB hub instability on RK3399 Puma MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Currently, the onboard Cypress CYUSB3304 USB hub is not defined in the device tree, and hub reset pin is provided as vcc5v0_host regulator to usb phy. This causes instability issues, as a result of improper reset duration. The fixed regulator device requests the GPIO during probe in its inactive state (except if regulator-boot-on property is set, in which case it is requested in the active state). Considering gpio is GPIO_ACTIVE_LOW for Puma, it means it’s driving it high. Then the regulator gets enabled (because regulator-always-on property), which drives it to its active state, meaning driving it low. The Cypress CYUSB3304 USB hub actually requires the reset to be asserted for at least 5 ms, which we cannot guarantee right now since there's no delay in the current config, meaning the hub may sometimes work or not. We could add delay as offered by fixed-regulator but let's rather fix this by using the proper way to model onboard USB hubs. Define hub_2_0 and hub_3_0 nodes, as the onboard Cypress hub consist of two 'logical' hubs, for USB2.0 and USB3.0. Use the 'reset-gpios' property of hub to assign reset pin instead of using regulator. Rename the vcc5v0_host regulator to cy3304_reset to be more meaningful. Pin is configured to output-high by default, which sets the hub in reset state during pin controller initialization. This allows to avoid double enumeration of devices in case the bootloader has setup the USB hub before the kernel. The vdd-supply and vdd2-supply properties in hub nodes are added to provide correct dt-bindings, although power supplies are always enabled based on HW design. Fixes: 2c66fc34e945 ("arm64: dts: rockchip: add RK3399-Q7 (Puma) SoM") Cc: stable(a)vger.kernel.org # 6.6 Cc: stable(a)vger.kernel.org # Backport of the patch in this series fixing product ID in onboard_dev_id_table in drivers/usb/misc/onboard_usb_dev.c driver Signed-off-by: Lukasz Czechowski <lukasz.czechowski(a)thaumatec.com> Link: https://lore.kernel.org/r/20250425-onboard_usb_dev-v2-3-4a76a474a010@thauma… Signed-off-by: Heiko Stuebner <heiko(a)sntech.de> diff --git a/arch/arm64/boot/dts/rockchip/rk3399-puma.dtsi b/arch/arm64/boot/dts/rockchip/rk3399-puma.dtsi index e00fbaa8acc1..314d9dfdba57 100644 --- a/arch/arm64/boot/dts/rockchip/rk3399-puma.dtsi +++ b/arch/arm64/boot/dts/rockchip/rk3399-puma.dtsi @@ -60,16 +60,6 @@ vcc3v3_sys: regulator-vcc3v3-sys { vin-supply = <&vcc5v0_sys>; }; - vcc5v0_host: regulator-vcc5v0-host { - compatible = "regulator-fixed"; - gpio = <&gpio4 RK_PA3 GPIO_ACTIVE_LOW>; - pinctrl-names = "default"; - pinctrl-0 = <&vcc5v0_host_en>; - regulator-name = "vcc5v0_host"; - regulator-always-on; - vin-supply = <&vcc5v0_sys>; - }; - vcc5v0_sys: regulator-vcc5v0-sys { compatible = "regulator-fixed"; regulator-name = "vcc5v0_sys"; @@ -527,10 +517,10 @@ pmic_int_l: pmic-int-l { }; }; - usb2 { - vcc5v0_host_en: vcc5v0-host-en { + usb { + cy3304_reset: cy3304-reset { rockchip,pins = - <4 RK_PA3 RK_FUNC_GPIO &pcfg_pull_none>; + <4 RK_PA3 RK_FUNC_GPIO &pcfg_output_high>; }; }; @@ -597,7 +587,6 @@ u2phy1_otg: otg-port { }; u2phy1_host: host-port { - phy-supply = <&vcc5v0_host>; status = "okay"; }; }; @@ -609,6 +598,29 @@ &usbdrd3_1 { &usbdrd_dwc3_1 { status = "okay"; dr_mode = "host"; + pinctrl-names = "default"; + pinctrl-0 = <&cy3304_reset>; + #address-cells = <1>; + #size-cells = <0>; + + hub_2_0: hub@1 { + compatible = "usb4b4,6502", "usb4b4,6506"; + reg = <1>; + peer-hub = <&hub_3_0>; + reset-gpios = <&gpio4 RK_PA3 GPIO_ACTIVE_HIGH>; + vdd-supply = <&vcc1v2_phy>; + vdd2-supply = <&vcc3v3_sys>; + + }; + + hub_3_0: hub@2 { + compatible = "usb4b4,6500", "usb4b4,6504"; + reg = <2>; + peer-hub = <&hub_2_0>; + reset-gpios = <&gpio4 RK_PA3 GPIO_ACTIVE_HIGH>; + vdd-supply = <&vcc1v2_phy>; + vdd2-supply = <&vcc3v3_sys>; + }; }; &usb_host1_ehci {

1 month, 1 week

1
0
0 0

FAILED: patch "[PATCH] arm64: dts: rockchip: fix internal USB hub instability on" failed to apply to 5.10-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 5.10-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-5.10.y git checkout FETCH_HEAD git cherry-pick -x d7cc532df95f7f159e40595440e4e4b99481457b # <resolve conflicts, build, test, etc.> git commit -s git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2025060237-cactus-anew-7019@gregkh' --subject-prefix 'PATCH 5.10.y' HEAD^.. Possible dependencies: thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From d7cc532df95f7f159e40595440e4e4b99481457b Mon Sep 17 00:00:00 2001 From: Lukasz Czechowski <lukasz.czechowski(a)thaumatec.com> Date: Fri, 25 Apr 2025 17:18:08 +0200 Subject: [PATCH] arm64: dts: rockchip: fix internal USB hub instability on RK3399 Puma MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Currently, the onboard Cypress CYUSB3304 USB hub is not defined in the device tree, and hub reset pin is provided as vcc5v0_host regulator to usb phy. This causes instability issues, as a result of improper reset duration. The fixed regulator device requests the GPIO during probe in its inactive state (except if regulator-boot-on property is set, in which case it is requested in the active state). Considering gpio is GPIO_ACTIVE_LOW for Puma, it means it’s driving it high. Then the regulator gets enabled (because regulator-always-on property), which drives it to its active state, meaning driving it low. The Cypress CYUSB3304 USB hub actually requires the reset to be asserted for at least 5 ms, which we cannot guarantee right now since there's no delay in the current config, meaning the hub may sometimes work or not. We could add delay as offered by fixed-regulator but let's rather fix this by using the proper way to model onboard USB hubs. Define hub_2_0 and hub_3_0 nodes, as the onboard Cypress hub consist of two 'logical' hubs, for USB2.0 and USB3.0. Use the 'reset-gpios' property of hub to assign reset pin instead of using regulator. Rename the vcc5v0_host regulator to cy3304_reset to be more meaningful. Pin is configured to output-high by default, which sets the hub in reset state during pin controller initialization. This allows to avoid double enumeration of devices in case the bootloader has setup the USB hub before the kernel. The vdd-supply and vdd2-supply properties in hub nodes are added to provide correct dt-bindings, although power supplies are always enabled based on HW design. Fixes: 2c66fc34e945 ("arm64: dts: rockchip: add RK3399-Q7 (Puma) SoM") Cc: stable(a)vger.kernel.org # 6.6 Cc: stable(a)vger.kernel.org # Backport of the patch in this series fixing product ID in onboard_dev_id_table in drivers/usb/misc/onboard_usb_dev.c driver Signed-off-by: Lukasz Czechowski <lukasz.czechowski(a)thaumatec.com> Link: https://lore.kernel.org/r/20250425-onboard_usb_dev-v2-3-4a76a474a010@thauma… Signed-off-by: Heiko Stuebner <heiko(a)sntech.de> diff --git a/arch/arm64/boot/dts/rockchip/rk3399-puma.dtsi b/arch/arm64/boot/dts/rockchip/rk3399-puma.dtsi index e00fbaa8acc1..314d9dfdba57 100644 --- a/arch/arm64/boot/dts/rockchip/rk3399-puma.dtsi +++ b/arch/arm64/boot/dts/rockchip/rk3399-puma.dtsi @@ -60,16 +60,6 @@ vcc3v3_sys: regulator-vcc3v3-sys { vin-supply = <&vcc5v0_sys>; }; - vcc5v0_host: regulator-vcc5v0-host { - compatible = "regulator-fixed"; - gpio = <&gpio4 RK_PA3 GPIO_ACTIVE_LOW>; - pinctrl-names = "default"; - pinctrl-0 = <&vcc5v0_host_en>; - regulator-name = "vcc5v0_host"; - regulator-always-on; - vin-supply = <&vcc5v0_sys>; - }; - vcc5v0_sys: regulator-vcc5v0-sys { compatible = "regulator-fixed"; regulator-name = "vcc5v0_sys"; @@ -527,10 +517,10 @@ pmic_int_l: pmic-int-l { }; }; - usb2 { - vcc5v0_host_en: vcc5v0-host-en { + usb { + cy3304_reset: cy3304-reset { rockchip,pins = - <4 RK_PA3 RK_FUNC_GPIO &pcfg_pull_none>; + <4 RK_PA3 RK_FUNC_GPIO &pcfg_output_high>; }; }; @@ -597,7 +587,6 @@ u2phy1_otg: otg-port { }; u2phy1_host: host-port { - phy-supply = <&vcc5v0_host>; status = "okay"; }; }; @@ -609,6 +598,29 @@ &usbdrd3_1 { &usbdrd_dwc3_1 { status = "okay"; dr_mode = "host"; + pinctrl-names = "default"; + pinctrl-0 = <&cy3304_reset>; + #address-cells = <1>; + #size-cells = <0>; + + hub_2_0: hub@1 { + compatible = "usb4b4,6502", "usb4b4,6506"; + reg = <1>; + peer-hub = <&hub_3_0>; + reset-gpios = <&gpio4 RK_PA3 GPIO_ACTIVE_HIGH>; + vdd-supply = <&vcc1v2_phy>; + vdd2-supply = <&vcc3v3_sys>; + + }; + + hub_3_0: hub@2 { + compatible = "usb4b4,6500", "usb4b4,6504"; + reg = <2>; + peer-hub = <&hub_2_0>; + reset-gpios = <&gpio4 RK_PA3 GPIO_ACTIVE_HIGH>; + vdd-supply = <&vcc1v2_phy>; + vdd2-supply = <&vcc3v3_sys>; + }; }; &usb_host1_ehci {

1 month, 1 week

1
0
0 0

FAILED: patch "[PATCH] arm64: dts: rockchip: fix internal USB hub instability on" failed to apply to 5.15-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 5.15-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-5.15.y git checkout FETCH_HEAD git cherry-pick -x d7cc532df95f7f159e40595440e4e4b99481457b # <resolve conflicts, build, test, etc.> git commit -s git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2025060236-cone-armory-06ea@gregkh' --subject-prefix 'PATCH 5.15.y' HEAD^.. Possible dependencies: thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From d7cc532df95f7f159e40595440e4e4b99481457b Mon Sep 17 00:00:00 2001 From: Lukasz Czechowski <lukasz.czechowski(a)thaumatec.com> Date: Fri, 25 Apr 2025 17:18:08 +0200 Subject: [PATCH] arm64: dts: rockchip: fix internal USB hub instability on RK3399 Puma MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Currently, the onboard Cypress CYUSB3304 USB hub is not defined in the device tree, and hub reset pin is provided as vcc5v0_host regulator to usb phy. This causes instability issues, as a result of improper reset duration. The fixed regulator device requests the GPIO during probe in its inactive state (except if regulator-boot-on property is set, in which case it is requested in the active state). Considering gpio is GPIO_ACTIVE_LOW for Puma, it means it’s driving it high. Then the regulator gets enabled (because regulator-always-on property), which drives it to its active state, meaning driving it low. The Cypress CYUSB3304 USB hub actually requires the reset to be asserted for at least 5 ms, which we cannot guarantee right now since there's no delay in the current config, meaning the hub may sometimes work or not. We could add delay as offered by fixed-regulator but let's rather fix this by using the proper way to model onboard USB hubs. Define hub_2_0 and hub_3_0 nodes, as the onboard Cypress hub consist of two 'logical' hubs, for USB2.0 and USB3.0. Use the 'reset-gpios' property of hub to assign reset pin instead of using regulator. Rename the vcc5v0_host regulator to cy3304_reset to be more meaningful. Pin is configured to output-high by default, which sets the hub in reset state during pin controller initialization. This allows to avoid double enumeration of devices in case the bootloader has setup the USB hub before the kernel. The vdd-supply and vdd2-supply properties in hub nodes are added to provide correct dt-bindings, although power supplies are always enabled based on HW design. Fixes: 2c66fc34e945 ("arm64: dts: rockchip: add RK3399-Q7 (Puma) SoM") Cc: stable(a)vger.kernel.org # 6.6 Cc: stable(a)vger.kernel.org # Backport of the patch in this series fixing product ID in onboard_dev_id_table in drivers/usb/misc/onboard_usb_dev.c driver Signed-off-by: Lukasz Czechowski <lukasz.czechowski(a)thaumatec.com> Link: https://lore.kernel.org/r/20250425-onboard_usb_dev-v2-3-4a76a474a010@thauma… Signed-off-by: Heiko Stuebner <heiko(a)sntech.de> diff --git a/arch/arm64/boot/dts/rockchip/rk3399-puma.dtsi b/arch/arm64/boot/dts/rockchip/rk3399-puma.dtsi index e00fbaa8acc1..314d9dfdba57 100644 --- a/arch/arm64/boot/dts/rockchip/rk3399-puma.dtsi +++ b/arch/arm64/boot/dts/rockchip/rk3399-puma.dtsi @@ -60,16 +60,6 @@ vcc3v3_sys: regulator-vcc3v3-sys { vin-supply = <&vcc5v0_sys>; }; - vcc5v0_host: regulator-vcc5v0-host { - compatible = "regulator-fixed"; - gpio = <&gpio4 RK_PA3 GPIO_ACTIVE_LOW>; - pinctrl-names = "default"; - pinctrl-0 = <&vcc5v0_host_en>; - regulator-name = "vcc5v0_host"; - regulator-always-on; - vin-supply = <&vcc5v0_sys>; - }; - vcc5v0_sys: regulator-vcc5v0-sys { compatible = "regulator-fixed"; regulator-name = "vcc5v0_sys"; @@ -527,10 +517,10 @@ pmic_int_l: pmic-int-l { }; }; - usb2 { - vcc5v0_host_en: vcc5v0-host-en { + usb { + cy3304_reset: cy3304-reset { rockchip,pins = - <4 RK_PA3 RK_FUNC_GPIO &pcfg_pull_none>; + <4 RK_PA3 RK_FUNC_GPIO &pcfg_output_high>; }; }; @@ -597,7 +587,6 @@ u2phy1_otg: otg-port { }; u2phy1_host: host-port { - phy-supply = <&vcc5v0_host>; status = "okay"; }; }; @@ -609,6 +598,29 @@ &usbdrd3_1 { &usbdrd_dwc3_1 { status = "okay"; dr_mode = "host"; + pinctrl-names = "default"; + pinctrl-0 = <&cy3304_reset>; + #address-cells = <1>; + #size-cells = <0>; + + hub_2_0: hub@1 { + compatible = "usb4b4,6502", "usb4b4,6506"; + reg = <1>; + peer-hub = <&hub_3_0>; + reset-gpios = <&gpio4 RK_PA3 GPIO_ACTIVE_HIGH>; + vdd-supply = <&vcc1v2_phy>; + vdd2-supply = <&vcc3v3_sys>; + + }; + + hub_3_0: hub@2 { + compatible = "usb4b4,6500", "usb4b4,6504"; + reg = <2>; + peer-hub = <&hub_2_0>; + reset-gpios = <&gpio4 RK_PA3 GPIO_ACTIVE_HIGH>; + vdd-supply = <&vcc1v2_phy>; + vdd2-supply = <&vcc3v3_sys>; + }; }; &usb_host1_ehci {

1 month, 1 week

1
0
0 0

FAILED: patch "[PATCH] arm64: dts: rockchip: fix internal USB hub instability on" 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 d7cc532df95f7f159e40595440e4e4b99481457b # <resolve conflicts, build, test, etc.> git commit -s git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2025060235-unroll-candy-0261@gregkh' --subject-prefix 'PATCH 6.1.y' HEAD^.. Possible dependencies: thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From d7cc532df95f7f159e40595440e4e4b99481457b Mon Sep 17 00:00:00 2001 From: Lukasz Czechowski <lukasz.czechowski(a)thaumatec.com> Date: Fri, 25 Apr 2025 17:18:08 +0200 Subject: [PATCH] arm64: dts: rockchip: fix internal USB hub instability on RK3399 Puma MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Currently, the onboard Cypress CYUSB3304 USB hub is not defined in the device tree, and hub reset pin is provided as vcc5v0_host regulator to usb phy. This causes instability issues, as a result of improper reset duration. The fixed regulator device requests the GPIO during probe in its inactive state (except if regulator-boot-on property is set, in which case it is requested in the active state). Considering gpio is GPIO_ACTIVE_LOW for Puma, it means it’s driving it high. Then the regulator gets enabled (because regulator-always-on property), which drives it to its active state, meaning driving it low. The Cypress CYUSB3304 USB hub actually requires the reset to be asserted for at least 5 ms, which we cannot guarantee right now since there's no delay in the current config, meaning the hub may sometimes work or not. We could add delay as offered by fixed-regulator but let's rather fix this by using the proper way to model onboard USB hubs. Define hub_2_0 and hub_3_0 nodes, as the onboard Cypress hub consist of two 'logical' hubs, for USB2.0 and USB3.0. Use the 'reset-gpios' property of hub to assign reset pin instead of using regulator. Rename the vcc5v0_host regulator to cy3304_reset to be more meaningful. Pin is configured to output-high by default, which sets the hub in reset state during pin controller initialization. This allows to avoid double enumeration of devices in case the bootloader has setup the USB hub before the kernel. The vdd-supply and vdd2-supply properties in hub nodes are added to provide correct dt-bindings, although power supplies are always enabled based on HW design. Fixes: 2c66fc34e945 ("arm64: dts: rockchip: add RK3399-Q7 (Puma) SoM") Cc: stable(a)vger.kernel.org # 6.6 Cc: stable(a)vger.kernel.org # Backport of the patch in this series fixing product ID in onboard_dev_id_table in drivers/usb/misc/onboard_usb_dev.c driver Signed-off-by: Lukasz Czechowski <lukasz.czechowski(a)thaumatec.com> Link: https://lore.kernel.org/r/20250425-onboard_usb_dev-v2-3-4a76a474a010@thauma… Signed-off-by: Heiko Stuebner <heiko(a)sntech.de> diff --git a/arch/arm64/boot/dts/rockchip/rk3399-puma.dtsi b/arch/arm64/boot/dts/rockchip/rk3399-puma.dtsi index e00fbaa8acc1..314d9dfdba57 100644 --- a/arch/arm64/boot/dts/rockchip/rk3399-puma.dtsi +++ b/arch/arm64/boot/dts/rockchip/rk3399-puma.dtsi @@ -60,16 +60,6 @@ vcc3v3_sys: regulator-vcc3v3-sys { vin-supply = <&vcc5v0_sys>; }; - vcc5v0_host: regulator-vcc5v0-host { - compatible = "regulator-fixed"; - gpio = <&gpio4 RK_PA3 GPIO_ACTIVE_LOW>; - pinctrl-names = "default"; - pinctrl-0 = <&vcc5v0_host_en>; - regulator-name = "vcc5v0_host"; - regulator-always-on; - vin-supply = <&vcc5v0_sys>; - }; - vcc5v0_sys: regulator-vcc5v0-sys { compatible = "regulator-fixed"; regulator-name = "vcc5v0_sys"; @@ -527,10 +517,10 @@ pmic_int_l: pmic-int-l { }; }; - usb2 { - vcc5v0_host_en: vcc5v0-host-en { + usb { + cy3304_reset: cy3304-reset { rockchip,pins = - <4 RK_PA3 RK_FUNC_GPIO &pcfg_pull_none>; + <4 RK_PA3 RK_FUNC_GPIO &pcfg_output_high>; }; }; @@ -597,7 +587,6 @@ u2phy1_otg: otg-port { }; u2phy1_host: host-port { - phy-supply = <&vcc5v0_host>; status = "okay"; }; }; @@ -609,6 +598,29 @@ &usbdrd3_1 { &usbdrd_dwc3_1 { status = "okay"; dr_mode = "host"; + pinctrl-names = "default"; + pinctrl-0 = <&cy3304_reset>; + #address-cells = <1>; + #size-cells = <0>; + + hub_2_0: hub@1 { + compatible = "usb4b4,6502", "usb4b4,6506"; + reg = <1>; + peer-hub = <&hub_3_0>; + reset-gpios = <&gpio4 RK_PA3 GPIO_ACTIVE_HIGH>; + vdd-supply = <&vcc1v2_phy>; + vdd2-supply = <&vcc3v3_sys>; + + }; + + hub_3_0: hub@2 { + compatible = "usb4b4,6500", "usb4b4,6504"; + reg = <2>; + peer-hub = <&hub_2_0>; + reset-gpios = <&gpio4 RK_PA3 GPIO_ACTIVE_HIGH>; + vdd-supply = <&vcc1v2_phy>; + vdd2-supply = <&vcc3v3_sys>; + }; }; &usb_host1_ehci {

1 month, 1 week

1
0
0 0

FAILED: patch "[PATCH] arm64: dts: rockchip: fix internal USB hub instability on" 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 d7cc532df95f7f159e40595440e4e4b99481457b # <resolve conflicts, build, test, etc.> git commit -s git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2025060233-umpire-askew-5f0b@gregkh' --subject-prefix 'PATCH 6.6.y' HEAD^.. Possible dependencies: thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From d7cc532df95f7f159e40595440e4e4b99481457b Mon Sep 17 00:00:00 2001 From: Lukasz Czechowski <lukasz.czechowski(a)thaumatec.com> Date: Fri, 25 Apr 2025 17:18:08 +0200 Subject: [PATCH] arm64: dts: rockchip: fix internal USB hub instability on RK3399 Puma MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Currently, the onboard Cypress CYUSB3304 USB hub is not defined in the device tree, and hub reset pin is provided as vcc5v0_host regulator to usb phy. This causes instability issues, as a result of improper reset duration. The fixed regulator device requests the GPIO during probe in its inactive state (except if regulator-boot-on property is set, in which case it is requested in the active state). Considering gpio is GPIO_ACTIVE_LOW for Puma, it means it’s driving it high. Then the regulator gets enabled (because regulator-always-on property), which drives it to its active state, meaning driving it low. The Cypress CYUSB3304 USB hub actually requires the reset to be asserted for at least 5 ms, which we cannot guarantee right now since there's no delay in the current config, meaning the hub may sometimes work or not. We could add delay as offered by fixed-regulator but let's rather fix this by using the proper way to model onboard USB hubs. Define hub_2_0 and hub_3_0 nodes, as the onboard Cypress hub consist of two 'logical' hubs, for USB2.0 and USB3.0. Use the 'reset-gpios' property of hub to assign reset pin instead of using regulator. Rename the vcc5v0_host regulator to cy3304_reset to be more meaningful. Pin is configured to output-high by default, which sets the hub in reset state during pin controller initialization. This allows to avoid double enumeration of devices in case the bootloader has setup the USB hub before the kernel. The vdd-supply and vdd2-supply properties in hub nodes are added to provide correct dt-bindings, although power supplies are always enabled based on HW design. Fixes: 2c66fc34e945 ("arm64: dts: rockchip: add RK3399-Q7 (Puma) SoM") Cc: stable(a)vger.kernel.org # 6.6 Cc: stable(a)vger.kernel.org # Backport of the patch in this series fixing product ID in onboard_dev_id_table in drivers/usb/misc/onboard_usb_dev.c driver Signed-off-by: Lukasz Czechowski <lukasz.czechowski(a)thaumatec.com> Link: https://lore.kernel.org/r/20250425-onboard_usb_dev-v2-3-4a76a474a010@thauma… Signed-off-by: Heiko Stuebner <heiko(a)sntech.de> diff --git a/arch/arm64/boot/dts/rockchip/rk3399-puma.dtsi b/arch/arm64/boot/dts/rockchip/rk3399-puma.dtsi index e00fbaa8acc1..314d9dfdba57 100644 --- a/arch/arm64/boot/dts/rockchip/rk3399-puma.dtsi +++ b/arch/arm64/boot/dts/rockchip/rk3399-puma.dtsi @@ -60,16 +60,6 @@ vcc3v3_sys: regulator-vcc3v3-sys { vin-supply = <&vcc5v0_sys>; }; - vcc5v0_host: regulator-vcc5v0-host { - compatible = "regulator-fixed"; - gpio = <&gpio4 RK_PA3 GPIO_ACTIVE_LOW>; - pinctrl-names = "default"; - pinctrl-0 = <&vcc5v0_host_en>; - regulator-name = "vcc5v0_host"; - regulator-always-on; - vin-supply = <&vcc5v0_sys>; - }; - vcc5v0_sys: regulator-vcc5v0-sys { compatible = "regulator-fixed"; regulator-name = "vcc5v0_sys"; @@ -527,10 +517,10 @@ pmic_int_l: pmic-int-l { }; }; - usb2 { - vcc5v0_host_en: vcc5v0-host-en { + usb { + cy3304_reset: cy3304-reset { rockchip,pins = - <4 RK_PA3 RK_FUNC_GPIO &pcfg_pull_none>; + <4 RK_PA3 RK_FUNC_GPIO &pcfg_output_high>; }; }; @@ -597,7 +587,6 @@ u2phy1_otg: otg-port { }; u2phy1_host: host-port { - phy-supply = <&vcc5v0_host>; status = "okay"; }; }; @@ -609,6 +598,29 @@ &usbdrd3_1 { &usbdrd_dwc3_1 { status = "okay"; dr_mode = "host"; + pinctrl-names = "default"; + pinctrl-0 = <&cy3304_reset>; + #address-cells = <1>; + #size-cells = <0>; + + hub_2_0: hub@1 { + compatible = "usb4b4,6502", "usb4b4,6506"; + reg = <1>; + peer-hub = <&hub_3_0>; + reset-gpios = <&gpio4 RK_PA3 GPIO_ACTIVE_HIGH>; + vdd-supply = <&vcc1v2_phy>; + vdd2-supply = <&vcc3v3_sys>; + + }; + + hub_3_0: hub@2 { + compatible = "usb4b4,6500", "usb4b4,6504"; + reg = <2>; + peer-hub = <&hub_2_0>; + reset-gpios = <&gpio4 RK_PA3 GPIO_ACTIVE_HIGH>; + vdd-supply = <&vcc1v2_phy>; + vdd2-supply = <&vcc3v3_sys>; + }; }; &usb_host1_ehci {

1 month, 1 week

1
0
0 0

FAILED: patch "[PATCH] arm64: dts: rockchip: fix internal USB hub instability on" 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 d7cc532df95f7f159e40595440e4e4b99481457b # <resolve conflicts, build, test, etc.> git commit -s git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2025060232-saga-chatty-ea5b@gregkh' --subject-prefix 'PATCH 6.12.y' HEAD^.. Possible dependencies: thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From d7cc532df95f7f159e40595440e4e4b99481457b Mon Sep 17 00:00:00 2001 From: Lukasz Czechowski <lukasz.czechowski(a)thaumatec.com> Date: Fri, 25 Apr 2025 17:18:08 +0200 Subject: [PATCH] arm64: dts: rockchip: fix internal USB hub instability on RK3399 Puma MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Currently, the onboard Cypress CYUSB3304 USB hub is not defined in the device tree, and hub reset pin is provided as vcc5v0_host regulator to usb phy. This causes instability issues, as a result of improper reset duration. The fixed regulator device requests the GPIO during probe in its inactive state (except if regulator-boot-on property is set, in which case it is requested in the active state). Considering gpio is GPIO_ACTIVE_LOW for Puma, it means it’s driving it high. Then the regulator gets enabled (because regulator-always-on property), which drives it to its active state, meaning driving it low. The Cypress CYUSB3304 USB hub actually requires the reset to be asserted for at least 5 ms, which we cannot guarantee right now since there's no delay in the current config, meaning the hub may sometimes work or not. We could add delay as offered by fixed-regulator but let's rather fix this by using the proper way to model onboard USB hubs. Define hub_2_0 and hub_3_0 nodes, as the onboard Cypress hub consist of two 'logical' hubs, for USB2.0 and USB3.0. Use the 'reset-gpios' property of hub to assign reset pin instead of using regulator. Rename the vcc5v0_host regulator to cy3304_reset to be more meaningful. Pin is configured to output-high by default, which sets the hub in reset state during pin controller initialization. This allows to avoid double enumeration of devices in case the bootloader has setup the USB hub before the kernel. The vdd-supply and vdd2-supply properties in hub nodes are added to provide correct dt-bindings, although power supplies are always enabled based on HW design. Fixes: 2c66fc34e945 ("arm64: dts: rockchip: add RK3399-Q7 (Puma) SoM") Cc: stable(a)vger.kernel.org # 6.6 Cc: stable(a)vger.kernel.org # Backport of the patch in this series fixing product ID in onboard_dev_id_table in drivers/usb/misc/onboard_usb_dev.c driver Signed-off-by: Lukasz Czechowski <lukasz.czechowski(a)thaumatec.com> Link: https://lore.kernel.org/r/20250425-onboard_usb_dev-v2-3-4a76a474a010@thauma… Signed-off-by: Heiko Stuebner <heiko(a)sntech.de> diff --git a/arch/arm64/boot/dts/rockchip/rk3399-puma.dtsi b/arch/arm64/boot/dts/rockchip/rk3399-puma.dtsi index e00fbaa8acc1..314d9dfdba57 100644 --- a/arch/arm64/boot/dts/rockchip/rk3399-puma.dtsi +++ b/arch/arm64/boot/dts/rockchip/rk3399-puma.dtsi @@ -60,16 +60,6 @@ vcc3v3_sys: regulator-vcc3v3-sys { vin-supply = <&vcc5v0_sys>; }; - vcc5v0_host: regulator-vcc5v0-host { - compatible = "regulator-fixed"; - gpio = <&gpio4 RK_PA3 GPIO_ACTIVE_LOW>; - pinctrl-names = "default"; - pinctrl-0 = <&vcc5v0_host_en>; - regulator-name = "vcc5v0_host"; - regulator-always-on; - vin-supply = <&vcc5v0_sys>; - }; - vcc5v0_sys: regulator-vcc5v0-sys { compatible = "regulator-fixed"; regulator-name = "vcc5v0_sys"; @@ -527,10 +517,10 @@ pmic_int_l: pmic-int-l { }; }; - usb2 { - vcc5v0_host_en: vcc5v0-host-en { + usb { + cy3304_reset: cy3304-reset { rockchip,pins = - <4 RK_PA3 RK_FUNC_GPIO &pcfg_pull_none>; + <4 RK_PA3 RK_FUNC_GPIO &pcfg_output_high>; }; }; @@ -597,7 +587,6 @@ u2phy1_otg: otg-port { }; u2phy1_host: host-port { - phy-supply = <&vcc5v0_host>; status = "okay"; }; }; @@ -609,6 +598,29 @@ &usbdrd3_1 { &usbdrd_dwc3_1 { status = "okay"; dr_mode = "host"; + pinctrl-names = "default"; + pinctrl-0 = <&cy3304_reset>; + #address-cells = <1>; + #size-cells = <0>; + + hub_2_0: hub@1 { + compatible = "usb4b4,6502", "usb4b4,6506"; + reg = <1>; + peer-hub = <&hub_3_0>; + reset-gpios = <&gpio4 RK_PA3 GPIO_ACTIVE_HIGH>; + vdd-supply = <&vcc1v2_phy>; + vdd2-supply = <&vcc3v3_sys>; + + }; + + hub_3_0: hub@2 { + compatible = "usb4b4,6500", "usb4b4,6504"; + reg = <2>; + peer-hub = <&hub_2_0>; + reset-gpios = <&gpio4 RK_PA3 GPIO_ACTIVE_HIGH>; + vdd-supply = <&vcc1v2_phy>; + vdd2-supply = <&vcc3v3_sys>; + }; }; &usb_host1_ehci {

1 month, 1 week

1
0
0 0

[PATCH 6.1.y v2] selftests/vm: fix split huge page tests

by Guangming Wang

From: Zi Yan <ziy(a)nvidia.com> [ upstream commit dd63bd7df41a8f9393a2e3ff9157a441c08eb996 ] Fix two inputs to check_anon_huge() and one if condition, so the tests work as expected. Steps to reproduce the issue. make headers make -C tools/testing/selftests/vm Before patching:test fails with a non-zero exit code ~/linux$ sudo tools/testing/selftests/vm/split_huge_page_test \ > /dev/null 2>&1;echo $? 1 ~/linux$ ./split_huge_page_test No THP is allocated After patching: ~/linux$ sudo tools/testing/selftests/vm/split_huge_page_test \ > /dev/null 2>&1;echo $? 0 ~/linux$ sudo tools/testing/selftests/vm/split_huge_page_test Split huge pages successful ... Link: https://lkml.kernel.org/r/20230306160907.16804-1-zi.yan@sent.com Fixes: c07c343cda8e ("selftests/vm: dedup THP helpers") Cc: stable(a)vger.kernel.org Signed-off-by: Zi Yan <ziy(a)nvidia.com> Reviewed-by: Zach O'Keefe <zokeefe(a)google.com> Tested-by: Zach O'Keefe <zokeefe(a)google.com> Acked-by: David Hildenbrand <david(a)redhat.com> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> Signed-off-by: Guangming Wang <guangming.wang(a)windriver.com> --- tools/testing/selftests/vm/split_huge_page_test.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/tools/testing/selftests/vm/split_huge_page_test.c b/tools/testing/selftests/vm/split_huge_page_test.c index 76e1c36dd..b8558c7f1 100644 --- a/tools/testing/selftests/vm/split_huge_page_test.c +++ b/tools/testing/selftests/vm/split_huge_page_test.c @@ -106,7 +106,7 @@ void split_pmd_thp(void) for (i = 0; i < len; i++) one_page[i] = (char)i; - if (!check_huge_anon(one_page, 1, pmd_pagesize)) { + if (!check_huge_anon(one_page, 4, pmd_pagesize)) { printf("No THP is allocated\n"); exit(EXIT_FAILURE); } @@ -122,7 +122,7 @@ void split_pmd_thp(void) } - if (check_huge_anon(one_page, 0, pmd_pagesize)) { + if (!check_huge_anon(one_page, 0, pmd_pagesize)) { printf("Still AnonHugePages not split\n"); exit(EXIT_FAILURE); } @@ -169,7 +169,7 @@ void split_pte_mapped_thp(void) for (i = 0; i < len; i++) one_page[i] = (char)i; - if (!check_huge_anon(one_page, 1, pmd_pagesize)) { + if (!check_huge_anon(one_page, 4, pmd_pagesize)) { printf("No THP is allocated\n"); exit(EXIT_FAILURE); } -- 2.34.1

1 month, 1 week

3
2
0 0

[PATCH v2] mm: userfaultfd: fix race of userfaultfd_move and swap cache

by Kairui Song

From: Kairui Song <kasong(a)tencent.com> On seeing a swap entry PTE, userfaultfd_move does a lockless swap cache lookup, and try to move the found folio to the faulting vma when. Currently, it relies on the PTE value check to ensure the moved folio still belongs to the src swap entry, which turns out is not reliable. While working and reviewing the swap table series with Barry, following existing race is observed and reproduced [1]: ( move_pages_pte is moving src_pte to dst_pte, where src_pte is a swap entry PTE holding swap entry S1, and S1 isn't in the swap cache.) CPU1 CPU2 userfaultfd_move move_pages_pte() entry = pte_to_swp_entry(orig_src_pte); // Here it got entry = S1 ... < Somehow interrupted> ... <swapin src_pte, alloc and use folio A> // folio A is just a new allocated folio // and get installed into src_pte <frees swap entry S1> // src_pte now points to folio A, S1 // has swap count == 0, it can be freed // by folio_swap_swap or swap // allocator's reclaim. <try to swap out another folio B> // folio B is a folio in another VMA. <put folio B to swap cache using S1 > // S1 is freed, folio B could use it // for swap out with no problem. ... folio = filemap_get_folio(S1) // Got folio B here !!! ... < Somehow interrupted again> ... <swapin folio B and free S1> // Now S1 is free to be used again. <swapout src_pte & folio A using S1> // Now src_pte is a swap entry pte // holding S1 again. folio_trylock(folio) move_swap_pte double_pt_lock is_pte_pages_stable // Check passed because src_pte == S1 folio_move_anon_rmap(...) // Moved invalid folio B here !!! The race window is very short and requires multiple collisions of multiple rare events, so it's very unlikely to happen, but with a deliberately constructed reproducer and increased time window, it can be reproduced [1]. It's also possible that folio (A) is swapped in, and swapped out again after the filemap_get_folio lookup, in such case folio (A) may stay in swap cache so it needs to be moved too. In this case we should also try again so kernel won't miss a folio move. Fix this by checking if the folio is the valid swap cache folio after acquiring the folio lock, and checking the swap cache again after acquiring the src_pte lock. SWP_SYNCRHONIZE_IO path does make the problem more complex, but so far we don't need to worry about that since folios only might get exposed to swap cache in the swap out path, and it's covered in this patch too by checking the swap cache again after acquiring src_pte lock. Testing with a simple C program to allocate and move several GB of memory did not show any observable performance change. Cc: <stable(a)vger.kernel.org> Fixes: adef440691ba ("userfaultfd: UFFDIO_MOVE uABI") Closes: https://lore.kernel.org/linux-mm/CAMgjq7B1K=6OOrK2OUZ0-tqCzi+EJt+2_K97TPGoS… [1] Signed-off-by: Kairui Song <kasong(a)tencent.com> --- V1: https://lore.kernel.org/linux-mm/20250530201710.81365-1-ryncsn@gmail.com/ Changes: - Check swap_map instead of doing a filemap lookup after acquiring the PTE lock to minimize critical section overhead [ Barry Song, Lokesh Gidra ] mm/userfaultfd.c | 27 +++++++++++++++++++++++++-- 1 file changed, 25 insertions(+), 2 deletions(-) diff --git a/mm/userfaultfd.c b/mm/userfaultfd.c index bc473ad21202..a74ede04996c 100644 --- a/mm/userfaultfd.c +++ b/mm/userfaultfd.c @@ -1084,8 +1084,11 @@ static int move_swap_pte(struct mm_struct *mm, struct vm_area_struct *dst_vma, pte_t orig_dst_pte, pte_t orig_src_pte, pmd_t *dst_pmd, pmd_t dst_pmdval, spinlock_t *dst_ptl, spinlock_t *src_ptl, - struct folio *src_folio) + struct folio *src_folio, + struct swap_info_struct *si) { + swp_entry_t entry; + double_pt_lock(dst_ptl, src_ptl); if (!is_pte_pages_stable(dst_pte, src_pte, orig_dst_pte, orig_src_pte, @@ -1102,6 +1105,16 @@ static int move_swap_pte(struct mm_struct *mm, struct vm_area_struct *dst_vma, if (src_folio) { folio_move_anon_rmap(src_folio, dst_vma); src_folio->index = linear_page_index(dst_vma, dst_addr); + } else { + /* + * Check if the swap entry is cached after acquiring the src_pte + * lock. Or we might miss a new loaded swap cache folio. + */ + entry = pte_to_swp_entry(orig_src_pte); + if (si->swap_map[swp_offset(entry)] & SWAP_HAS_CACHE) { + double_pt_unlock(dst_ptl, src_ptl); + return -EAGAIN; + } } orig_src_pte = ptep_get_and_clear(mm, src_addr, src_pte); @@ -1409,10 +1422,20 @@ static int move_pages_pte(struct mm_struct *mm, pmd_t *dst_pmd, pmd_t *src_pmd, folio_lock(src_folio); goto retry; } + /* + * Check if the folio still belongs to the target swap entry after + * acquiring the lock. Folio can be freed in the swap cache while + * not locked. + */ + if (unlikely(!folio_test_swapcache(folio) || + entry.val != folio->swap.val)) { + err = -EAGAIN; + goto out; + } } err = move_swap_pte(mm, dst_vma, dst_addr, src_addr, dst_pte, src_pte, orig_dst_pte, orig_src_pte, dst_pmd, dst_pmdval, - dst_ptl, src_ptl, src_folio); + dst_ptl, src_ptl, src_folio, si); } out: -- 2.49.0

1 month, 1 week

3
3
0 0

[PATCH] mm: Fix vmstat after removing NR_BOUNCE

by Kirill A. Shutemov

Hongyu noticed that the nr_unaccepted counter kept growing even in the absence of unaccepted memory on the machine. This happens due to a commit that removed NR_BOUNCE: it removed the counter from the enum zone_stat_item, but left it in the vmstat_text array. As a result, all counters below nr_bounce in /proc/vmstat are shifted by one line, causing the numa_hit counter to be labeled as nr_unaccepted. To fix this issue, remove nr_bounce from the vmstat_text array. Signed-off-by: Kirill A. Shutemov <kirill.shutemov(a)linux.intel.com> Reported-by: Hongyu Ning <hongyu.ning(a)linux.intel.com> Fixes: 194df9f66db8 ("mm: remove NR_BOUNCE zone stat") Cc: stable(a)vger.kernel.org Cc: Christoph Hellwig <hch(a)lst.de> Cc: Hannes Reinecke <hare(a)suse.de> Cc: Johannes Thumshirn <johannes.thumshirn(a)wdc.com> Cc: Jens Axboe <axboe(a)kernel.dk> --- mm/vmstat.c | 1 - 1 file changed, 1 deletion(-) diff --git a/mm/vmstat.c b/mm/vmstat.c index 4c268ce39ff2..ae9882063d89 100644 --- a/mm/vmstat.c +++ b/mm/vmstat.c @@ -1201,7 +1201,6 @@ const char * const vmstat_text[] = { "nr_zone_unevictable", "nr_zone_write_pending", "nr_mlock", - "nr_bounce", #if IS_ENABLED(CONFIG_ZSMALLOC) "nr_zspages", #endif -- 2.47.2

1 month, 1 week

8
11
0 0

Re: [PATCH v4] virtio_blk: Fix disk deletion hang on device surprise removal

by ALOK TIWARI

On 31-05-2025 11:03, Parav Pandit wrote: > + if (!virtqueue_is_broken(vblk->vqs[0].vq)) is it call, if the virtqueue is not broken ? > + virtblk_cleanup_broken_device(vblk); > + > del_gendisk(vblk->disk); > blk_mq_free_tag_set(&vblk->tag_set); Thanks, Alok

1 month, 1 week

2
1
0 0

[PATCH AUTOSEL 5.4 01/22] drm/amdgpu/gfx6: fix CSIB handling

by Sasha Levin

From: Alex Deucher <alexander.deucher(a)amd.com> [ Upstream commit 8307ebc15c1ea98a8a0b7837af1faa6c01514577 ] We shouldn't return after the last section. We need to update the rest of the CSIB. Reviewed-by: Rodrigo Siqueira <siqueira(a)igalia.com> Signed-off-by: Alex Deucher <alexander.deucher(a)amd.com> Signed-off-by: Sasha Levin <sashal(a)kernel.org> --- Now let me understand what the bug is. Looking at the original code: ```c for (sect = adev->gfx.rlc.cs_data; sect->section != NULL; ++sect) { for (ext = sect->section; ext->extent != NULL; ++ext) { if (sect->id == SECT_CONTEXT) { // process SECT_CONTEXT sections } else { return; // BUG: This returns early, skipping remaining code } } } // Important code that should always run: buffer[count++] = cpu_to_le32(PACKET3(PACKET3_SET_CONTEXT_REG, 1)); buffer[count++] = cpu_to_le32(mmPA_SC_RASTER_CONFIG - PACKET3_SET_CONTEXT_REG_START); // ... more important buffer initialization ``` The fix removes the early return so that all sections are processed and the important buffer initialization at the end always runs. **YES** This commit should be backported to stable kernel trees for the following reasons: 1. **Clear Bug Fix**: The commit fixes a clear logic error where an early return statement prevents critical buffer initialization code from executing. The original code would return immediately when encountering a non- SECT_CONTEXT section, skipping the important packet commands that should always be written to the buffer (PACKET3_SET_CONTEXT_REG, PACKET3_PREAMBLE_END_CLEAR_STATE, PACKET3_CLEAR_STATE). 2. **Functional Impact**: This bug affects the Clear State Indirect Buffer (CSIB) handling in AMD GPU driver for GFX6 hardware. The incomplete buffer initialization could lead to: - Incorrect GPU state during graphics operations - Potential rendering issues or GPU hangs - Inconsistent hardware behavior 3. **Small and Contained Fix**: The fix is minimal - it simply removes two lines (the else block with return statement). This is a low-risk change that doesn't introduce new functionality or alter the architecture. 4. **Hardware-Specific Bug**: This affects real users with GFX6 AMD GPUs. The bug prevents proper initialization of the GPU's clear state buffer, which is essential for correct GPU operation. 5. **Similar to Historical Backports**: Looking at commit 4 in the similar commits (marked as YES for backporting), which also fixed preamble handling issues in the AMD GPU driver, this follows a similar pattern of fixing command buffer handling bugs. The commit message clearly indicates this is a bug fix ("We shouldn't return after the last section. We need to update the rest of the CSIB"), and the code change confirms that critical buffer initialization was being skipped due to the premature return. drivers/gpu/drm/amd/amdgpu/gfx_v6_0.c | 2 -- 1 file changed, 2 deletions(-) diff --git a/drivers/gpu/drm/amd/amdgpu/gfx_v6_0.c b/drivers/gpu/drm/amd/amdgpu/gfx_v6_0.c index 7f0a63628c43a..eac329fe27902 100644 --- a/drivers/gpu/drm/amd/amdgpu/gfx_v6_0.c +++ b/drivers/gpu/drm/amd/amdgpu/gfx_v6_0.c @@ -2901,8 +2901,6 @@ static void gfx_v6_0_get_csb_buffer(struct amdgpu_device *adev, buffer[count++] = cpu_to_le32(ext->reg_index - 0xa000); for (i = 0; i < ext->reg_count; i++) buffer[count++] = cpu_to_le32(ext->extent[i]); - } else { - return; } } } -- 2.39.5

1 month, 1 week

1
21
0 0

[PATCH AUTOSEL 5.10 01/34] drm/amdgpu/gfx6: fix CSIB handling

by Sasha Levin

From: Alex Deucher <alexander.deucher(a)amd.com> [ Upstream commit 8307ebc15c1ea98a8a0b7837af1faa6c01514577 ] We shouldn't return after the last section. We need to update the rest of the CSIB. Reviewed-by: Rodrigo Siqueira <siqueira(a)igalia.com> Signed-off-by: Alex Deucher <alexander.deucher(a)amd.com> Signed-off-by: Sasha Levin <sashal(a)kernel.org> --- Now let me understand what the bug is. Looking at the original code: ```c for (sect = adev->gfx.rlc.cs_data; sect->section != NULL; ++sect) { for (ext = sect->section; ext->extent != NULL; ++ext) { if (sect->id == SECT_CONTEXT) { // process SECT_CONTEXT sections } else { return; // BUG: This returns early, skipping remaining code } } } // Important code that should always run: buffer[count++] = cpu_to_le32(PACKET3(PACKET3_SET_CONTEXT_REG, 1)); buffer[count++] = cpu_to_le32(mmPA_SC_RASTER_CONFIG - PACKET3_SET_CONTEXT_REG_START); // ... more important buffer initialization ``` The fix removes the early return so that all sections are processed and the important buffer initialization at the end always runs. **YES** This commit should be backported to stable kernel trees for the following reasons: 1. **Clear Bug Fix**: The commit fixes a clear logic error where an early return statement prevents critical buffer initialization code from executing. The original code would return immediately when encountering a non- SECT_CONTEXT section, skipping the important packet commands that should always be written to the buffer (PACKET3_SET_CONTEXT_REG, PACKET3_PREAMBLE_END_CLEAR_STATE, PACKET3_CLEAR_STATE). 2. **Functional Impact**: This bug affects the Clear State Indirect Buffer (CSIB) handling in AMD GPU driver for GFX6 hardware. The incomplete buffer initialization could lead to: - Incorrect GPU state during graphics operations - Potential rendering issues or GPU hangs - Inconsistent hardware behavior 3. **Small and Contained Fix**: The fix is minimal - it simply removes two lines (the else block with return statement). This is a low-risk change that doesn't introduce new functionality or alter the architecture. 4. **Hardware-Specific Bug**: This affects real users with GFX6 AMD GPUs. The bug prevents proper initialization of the GPU's clear state buffer, which is essential for correct GPU operation. 5. **Similar to Historical Backports**: Looking at commit 4 in the similar commits (marked as YES for backporting), which also fixed preamble handling issues in the AMD GPU driver, this follows a similar pattern of fixing command buffer handling bugs. The commit message clearly indicates this is a bug fix ("We shouldn't return after the last section. We need to update the rest of the CSIB"), and the code change confirms that critical buffer initialization was being skipped due to the premature return. drivers/gpu/drm/amd/amdgpu/gfx_v6_0.c | 2 -- 1 file changed, 2 deletions(-) diff --git a/drivers/gpu/drm/amd/amdgpu/gfx_v6_0.c b/drivers/gpu/drm/amd/amdgpu/gfx_v6_0.c index 79c52c7a02e3a..d447b2416b98b 100644 --- a/drivers/gpu/drm/amd/amdgpu/gfx_v6_0.c +++ b/drivers/gpu/drm/amd/amdgpu/gfx_v6_0.c @@ -2896,8 +2896,6 @@ static void gfx_v6_0_get_csb_buffer(struct amdgpu_device *adev, buffer[count++] = cpu_to_le32(ext->reg_index - 0xa000); for (i = 0; i < ext->reg_count; i++) buffer[count++] = cpu_to_le32(ext->extent[i]); - } else { - return; } } } -- 2.39.5

1 month, 1 week

1
33
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror