Re: [PATCH v1 1/1] arm64: dts: qcom: hamoa: Move PCIe PERST and Wake GPIOs to port nodes

[Bjorn Helgaas]

On Sat, Mar 14, 2026 at 07:50:50PM +0530, Manivannan Sadhasivam wrote:
> On Fri, Mar 13, 2026 at 11:45:42AM -0500, Bjorn Helgaas wrote:
> > On Fri, Mar 13, 2026 at 05:46:18PM +0800, Ziyue Zhang wrote:
> > > Commit 960609b22be5 ("arm64: dts: qcom: hamoa: Move PHY, PERST, and Wake
> > > GPIOs to PCIe port nodes and add port Nodes for all PCIe ports") did not
> > > convert all Hamoa‑based platforms to the new method of defining PERST and
> > > Wake GPIOs in the PCIe root port nodes.
> > > 
> > > Without the change PCIe probe will fail. The probe failure happens because
> > > the PHY stays in the controller node while the PERST/Wake GPIOs were moved
> > > to the port nodes.
> > > 
> > > This fixes probe failures seen on the following platforms:
> > >  - x1-hp-omnibook-x14
> > >  - x1-microsoft-denali
> > >  - x1e80100-lenovo-yoga-slim7x
> > >  - x1e80100-medion-sprchrgd-14-s1
> > >  - x1p42100-lenovo-thinkbook-16
> > >  - x1-asus-zenbook-a14
> > >  - x1-crd
> > >  - x1-dell-thena
> > > 
> > > Fixes: 960609b22be5 ("arm64: dts: qcom: hamoa: Move PHY, PERST, and Wake GPIOs to PCIe port nodes and add port Nodes for all PCIe ports")
> > 
> > Are you saying that DTs in the field broke because of some kernel
> > change?  That's not supposed to happen.  Even though PHY, PERST, and
> > Wake GPIOs should be described in Root Port nodes instead of the Root
> > Complex node in *future* DTs, the kernel is still supposed to accept
> > the old style with them described in the Root Complex node.
> 
> This is not related to the driver change. The driver correctly
> parses all Root Port properties either in the Root Complex node (old
> binding) or Root Port node (new binding). But commit 960609b22be5,
> left converting mentioned board DTS to the new binding, leaving
> those affected platforms in a half baked state i.e., some properties
> in RC node and some in Root Port node. Driver cannot parse such
> combinations, so it fails correctly so.

The commit log mentions probe failures on some machines.  I'd like it
to be more clear about who is affected and what they need to do to fix
their machines.  If it only affects developers who generated DTs based
on 960609b22be5 for internal testing, we should say that so it's clear
that no end users will see any regressions or boot failures.

Is there some way to verify that after this patch, none of the
generated DTBs are in this half-baked situation?  Some kind of
automated DTB checker?