arch/arm64/boot/dts/qcom/x1-crd.dtsi | 1 + arch/arm64/boot/dts/qcom/x1e001de-devkit.dts | 3 ++- arch/arm64/boot/dts/qcom/x1e78100-lenovo-thinkpad-t14s.dtsi | 1 + arch/arm64/boot/dts/qcom/x1e80100-dell-xps13-9345.dts | 1 + arch/arm64/boot/dts/qcom/x1e80100-honor-magicbook-art-14.dts | 3 ++- arch/arm64/boot/dts/qcom/x1e80100-lenovo-yoga-slim7x.dts | 1 + arch/arm64/boot/dts/qcom/x1e80100-medion-sprchrgd-14-s1.dts | 1 + arch/arm64/boot/dts/qcom/x1e80100-microsoft-romulus.dtsi | 1 + arch/arm64/boot/dts/qcom/x1e80100-qcp.dts | 1 + 9 files changed, 11 insertions(+), 2 deletions(-)
GPIO 65 from TLMM is used by the embedded controller as its reset line on
these boards. Reserve it to prevent Linux from requesting or reconfiguring it.
I was only able to confirm that this GPIO is actually connected to the
EC reset on the CRD, QCP, xps13 and t14s. But it seems like it is
recurring them shared between all Hamoa based devices, so I reserved it
on all.
Signed-off-by: Abel Vesa <abel.vesa@oss.qualcomm.com>
---
Abel Vesa (9):
arm64: dts: qcom: x1-crd: Mark the EC reset gpio as reserved
arm64: dts: qcom: x1e001de-devkit: Mark the EC reset gpio as reserved
arm64: dts: qcom: x1e78100-t14s: Mark the EC reset gpio as reserved
arm64: dts: qcom: x1e80100-dell-xps13-9345: Mark the EC reset gpio as reserved
arm64: dts: qcom: honor-magicbook-art-14: Mark the EC reset gpio as reserved
arm64: dts: qcom: x1e80100-yoga-slim7x: Mark the EC reset gpio as reserved
arm64: dts: qcom: medion-sprchrgd-14-s1: Mark the EC reset gpio as reserved
arm64: dts: qcom: microsoft-romulus: Mark the EC reset gpio as reserved
arm64: dts: qcom: x1e80100-qcp: Mark the EC reset gpio as reserved
arch/arm64/boot/dts/qcom/x1-crd.dtsi | 1 +
arch/arm64/boot/dts/qcom/x1e001de-devkit.dts | 3 ++-
arch/arm64/boot/dts/qcom/x1e78100-lenovo-thinkpad-t14s.dtsi | 1 +
arch/arm64/boot/dts/qcom/x1e80100-dell-xps13-9345.dts | 1 +
arch/arm64/boot/dts/qcom/x1e80100-honor-magicbook-art-14.dts | 3 ++-
arch/arm64/boot/dts/qcom/x1e80100-lenovo-yoga-slim7x.dts | 1 +
arch/arm64/boot/dts/qcom/x1e80100-medion-sprchrgd-14-s1.dts | 1 +
arch/arm64/boot/dts/qcom/x1e80100-microsoft-romulus.dtsi | 1 +
arch/arm64/boot/dts/qcom/x1e80100-qcp.dts | 1 +
9 files changed, 11 insertions(+), 2 deletions(-)
---
base-commit: e30626823a406725ce29bc75cb8ec467d3e1e326
change-id: 20260831-dts-qcom-hamoa-reserve-ec-reset-gpio-0bf57fbd24e7
Best regards,
--
Abel Vesa <abel.vesa@oss.qualcomm.com>
On 26-08-31 12:54:40, Abel Vesa wrote: > GPIO 65 from TLMM is used by the embedded controller as its reset line on > these boards. Reserve it to prevent Linux from requesting or reconfiguring it. > > I was only able to confirm that this GPIO is actually connected to the > EC reset on the CRD, QCP, xps13 and t14s. But it seems like it is > recurring them shared between all Hamoa based devices, so I reserved it > on all. > > Signed-off-by: Abel Vesa <abel.vesa@oss.qualcomm.com> > --- > Abel Vesa (9): > arm64: dts: qcom: x1-crd: Mark the EC reset gpio as reserved > arm64: dts: qcom: x1e001de-devkit: Mark the EC reset gpio as reserved > arm64: dts: qcom: x1e78100-t14s: Mark the EC reset gpio as reserved > arm64: dts: qcom: x1e80100-dell-xps13-9345: Mark the EC reset gpio as reserved > arm64: dts: qcom: honor-magicbook-art-14: Mark the EC reset gpio as reserved > arm64: dts: qcom: x1e80100-yoga-slim7x: Mark the EC reset gpio as reserved > arm64: dts: qcom: medion-sprchrgd-14-s1: Mark the EC reset gpio as reserved > arm64: dts: qcom: microsoft-romulus: Mark the EC reset gpio as reserved > arm64: dts: qcom: x1e80100-qcp: Mark the EC reset gpio as reserved > > arch/arm64/boot/dts/qcom/x1-crd.dtsi | 1 + > arch/arm64/boot/dts/qcom/x1e001de-devkit.dts | 3 ++- > arch/arm64/boot/dts/qcom/x1e78100-lenovo-thinkpad-t14s.dtsi | 1 + > arch/arm64/boot/dts/qcom/x1e80100-dell-xps13-9345.dts | 1 + > arch/arm64/boot/dts/qcom/x1e80100-honor-magicbook-art-14.dts | 3 ++- > arch/arm64/boot/dts/qcom/x1e80100-lenovo-yoga-slim7x.dts | 1 + > arch/arm64/boot/dts/qcom/x1e80100-medion-sprchrgd-14-s1.dts | 1 + > arch/arm64/boot/dts/qcom/x1e80100-microsoft-romulus.dtsi | 1 + > arch/arm64/boot/dts/qcom/x1e80100-qcp.dts | 1 + > 9 files changed, 11 insertions(+), 2 deletions(-) Urgh, just realized that there way more that need to be addressed. Will do that in v2, after I get some reviews.
On Mon, Aug 31, 2026 at 01:12:38PM +0300, Abel Vesa wrote: > On 26-08-31 12:54:40, Abel Vesa wrote: > > GPIO 65 from TLMM is used by the embedded controller as its reset line on > > these boards. Reserve it to prevent Linux from requesting or reconfiguring it. > > > > I was only able to confirm that this GPIO is actually connected to the > > EC reset on the CRD, QCP, xps13 and t14s. But it seems like it is > > recurring them shared between all Hamoa based devices, so I reserved it > > on all. > > > > Signed-off-by: Abel Vesa <abel.vesa@oss.qualcomm.com> > > --- > > Abel Vesa (9): > > arm64: dts: qcom: x1-crd: Mark the EC reset gpio as reserved > > arm64: dts: qcom: x1e001de-devkit: Mark the EC reset gpio as reserved > > arm64: dts: qcom: x1e78100-t14s: Mark the EC reset gpio as reserved > > arm64: dts: qcom: x1e80100-dell-xps13-9345: Mark the EC reset gpio as reserved > > arm64: dts: qcom: honor-magicbook-art-14: Mark the EC reset gpio as reserved > > arm64: dts: qcom: x1e80100-yoga-slim7x: Mark the EC reset gpio as reserved > > arm64: dts: qcom: medion-sprchrgd-14-s1: Mark the EC reset gpio as reserved > > arm64: dts: qcom: microsoft-romulus: Mark the EC reset gpio as reserved > > arm64: dts: qcom: x1e80100-qcp: Mark the EC reset gpio as reserved > > > > arch/arm64/boot/dts/qcom/x1-crd.dtsi | 1 + > > arch/arm64/boot/dts/qcom/x1e001de-devkit.dts | 3 ++- > > arch/arm64/boot/dts/qcom/x1e78100-lenovo-thinkpad-t14s.dtsi | 1 + > > arch/arm64/boot/dts/qcom/x1e80100-dell-xps13-9345.dts | 1 + > > arch/arm64/boot/dts/qcom/x1e80100-honor-magicbook-art-14.dts | 3 ++- > > arch/arm64/boot/dts/qcom/x1e80100-lenovo-yoga-slim7x.dts | 1 + > > arch/arm64/boot/dts/qcom/x1e80100-medion-sprchrgd-14-s1.dts | 1 + > > arch/arm64/boot/dts/qcom/x1e80100-microsoft-romulus.dtsi | 1 + > > arch/arm64/boot/dts/qcom/x1e80100-qcp.dts | 1 + > > 9 files changed, 11 insertions(+), 2 deletions(-) > > Urgh, just realized that there way more that need to be addressed. > I'm not able to guess what you're referring to here. More devices or more problems to fix? If more devices, why would that warrant a v2? > Will do that in v2, after I get some reviews. Regards, Bjorn
On 26-08-31 10:04:41, Bjorn Andersson wrote: > On Mon, Aug 31, 2026 at 01:12:38PM +0300, Abel Vesa wrote: > > On 26-08-31 12:54:40, Abel Vesa wrote: > > > GPIO 65 from TLMM is used by the embedded controller as its reset line on > > > these boards. Reserve it to prevent Linux from requesting or reconfiguring it. > > > > > > I was only able to confirm that this GPIO is actually connected to the > > > EC reset on the CRD, QCP, xps13 and t14s. But it seems like it is > > > recurring them shared between all Hamoa based devices, so I reserved it > > > on all. > > > > > > Signed-off-by: Abel Vesa <abel.vesa@oss.qualcomm.com> > > > --- > > > Abel Vesa (9): > > > arm64: dts: qcom: x1-crd: Mark the EC reset gpio as reserved > > > arm64: dts: qcom: x1e001de-devkit: Mark the EC reset gpio as reserved > > > arm64: dts: qcom: x1e78100-t14s: Mark the EC reset gpio as reserved > > > arm64: dts: qcom: x1e80100-dell-xps13-9345: Mark the EC reset gpio as reserved > > > arm64: dts: qcom: honor-magicbook-art-14: Mark the EC reset gpio as reserved > > > arm64: dts: qcom: x1e80100-yoga-slim7x: Mark the EC reset gpio as reserved > > > arm64: dts: qcom: medion-sprchrgd-14-s1: Mark the EC reset gpio as reserved > > > arm64: dts: qcom: microsoft-romulus: Mark the EC reset gpio as reserved > > > arm64: dts: qcom: x1e80100-qcp: Mark the EC reset gpio as reserved > > > > > > arch/arm64/boot/dts/qcom/x1-crd.dtsi | 1 + > > > arch/arm64/boot/dts/qcom/x1e001de-devkit.dts | 3 ++- > > > arch/arm64/boot/dts/qcom/x1e78100-lenovo-thinkpad-t14s.dtsi | 1 + > > > arch/arm64/boot/dts/qcom/x1e80100-dell-xps13-9345.dts | 1 + > > > arch/arm64/boot/dts/qcom/x1e80100-honor-magicbook-art-14.dts | 3 ++- > > > arch/arm64/boot/dts/qcom/x1e80100-lenovo-yoga-slim7x.dts | 1 + > > > arch/arm64/boot/dts/qcom/x1e80100-medion-sprchrgd-14-s1.dts | 1 + > > > arch/arm64/boot/dts/qcom/x1e80100-microsoft-romulus.dtsi | 1 + > > > arch/arm64/boot/dts/qcom/x1e80100-qcp.dts | 1 + > > > 9 files changed, 11 insertions(+), 2 deletions(-) > > > > Urgh, just realized that there way more that need to be addressed. > > > > I'm not able to guess what you're referring to here. More devices or > more problems to fix? If more devices, why would that warrant a v2? IMO, the fact that the comment is under a bunch of filenames, should be pretty obvious that there are more devices, especially since this entire patchset is fixing same kind of problem for all of these boards. Anyway, will be more explicit next time. As for v2, it doesn't warrant one, but I was telling reviewers that I realized that there are more than just these devices that need this fixed, basically promising to fix all and include them in v2, if a respin is necessary. Which it might, if you merge Alex's EC XPS13 patchset first. Thanks for reviewing! Abel
On Mon, Aug 31, 2026 at 12:54:40PM +0300, Abel Vesa wrote: > GPIO 65 from TLMM is used by the embedded controller as its reset line on > these boards. Reserve it to prevent Linux from requesting or reconfiguring it. > > I was only able to confirm that this GPIO is actually connected to the > EC reset on the CRD, QCP, xps13 and t14s. But it seems like it is > recurring them shared between all Hamoa based devices, so I reserved it > on all. Such leaps of faith comes down to risk vs reward; the risk seems reasonable, but your commit message just states a fact not a problem - so there's no documented reward... Regards, Bjorn > > Signed-off-by: Abel Vesa <abel.vesa@oss.qualcomm.com> > --- > Abel Vesa (9): > arm64: dts: qcom: x1-crd: Mark the EC reset gpio as reserved > arm64: dts: qcom: x1e001de-devkit: Mark the EC reset gpio as reserved > arm64: dts: qcom: x1e78100-t14s: Mark the EC reset gpio as reserved > arm64: dts: qcom: x1e80100-dell-xps13-9345: Mark the EC reset gpio as reserved > arm64: dts: qcom: honor-magicbook-art-14: Mark the EC reset gpio as reserved > arm64: dts: qcom: x1e80100-yoga-slim7x: Mark the EC reset gpio as reserved > arm64: dts: qcom: medion-sprchrgd-14-s1: Mark the EC reset gpio as reserved > arm64: dts: qcom: microsoft-romulus: Mark the EC reset gpio as reserved > arm64: dts: qcom: x1e80100-qcp: Mark the EC reset gpio as reserved > > arch/arm64/boot/dts/qcom/x1-crd.dtsi | 1 + > arch/arm64/boot/dts/qcom/x1e001de-devkit.dts | 3 ++- > arch/arm64/boot/dts/qcom/x1e78100-lenovo-thinkpad-t14s.dtsi | 1 + > arch/arm64/boot/dts/qcom/x1e80100-dell-xps13-9345.dts | 1 + > arch/arm64/boot/dts/qcom/x1e80100-honor-magicbook-art-14.dts | 3 ++- > arch/arm64/boot/dts/qcom/x1e80100-lenovo-yoga-slim7x.dts | 1 + > arch/arm64/boot/dts/qcom/x1e80100-medion-sprchrgd-14-s1.dts | 1 + > arch/arm64/boot/dts/qcom/x1e80100-microsoft-romulus.dtsi | 1 + > arch/arm64/boot/dts/qcom/x1e80100-qcp.dts | 1 + > 9 files changed, 11 insertions(+), 2 deletions(-) > --- > base-commit: e30626823a406725ce29bc75cb8ec467d3e1e326 > change-id: 20260831-dts-qcom-hamoa-reserve-ec-reset-gpio-0bf57fbd24e7 > > Best regards, > -- > Abel Vesa <abel.vesa@oss.qualcomm.com> >
On 26-08-31 10:07:31, Bjorn Andersson wrote: > On Mon, Aug 31, 2026 at 12:54:40PM +0300, Abel Vesa wrote: > > GPIO 65 from TLMM is used by the embedded controller as its reset line on > > these boards. Reserve it to prevent Linux from requesting or reconfiguring it. > > > > I was only able to confirm that this GPIO is actually connected to the > > EC reset on the CRD, QCP, xps13 and t14s. But it seems like it is > > recurring them shared between all Hamoa based devices, so I reserved it > > on all. > > Such leaps of faith comes down to risk vs reward; the risk seems > reasonable, but your commit message just states a fact not a problem - > so there's no documented reward... So I actually considered adding a sentence that would mention that on some of these devices, if you play with EC reset gpio, you might have to disassemble the device and unplug the battery, in order to be able to use it again. But I'm not sure that is applicable to all devices. All I know, from someone else's experience, is that we should not be controlling that from linux. Therefore, the commit message did not make any assumptions about what the "reward" is. However, I can add such a line if you still think it is worth it.
© 2016 - 2026 Red Hat, Inc.