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

[Manivannan Sadhasivam]

On Tue, Mar 17, 2026 at 12:13:19PM -0500, Bjorn Helgaas wrote:
> 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.

There is already a list of affected machines mentioned in the commit message.

And for fix, they just need to apply this patch. Or once this patch gets merged
into v7.0-rcS, v7.0 will have no issue.

>  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.
> 

Whoever have included commit 960609b22be5 in their kernel and using the above
mentioned machines will see the failure. But looks like no one really tested
v7.0-rcS on these machines as we haven't gotten any reports so far.

> 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?

I sent out a DT binding series [1] that was supposed to catch these issues
during DTB validation phase, but unfortunately it got stuck in the review. I'll
try to stir things up.

- Mani

[1] https://lore.kernel.org/linux-pci/20251106-pci-binding-v2-0-bebe9345fc4b@xxxxxxxxxxxxxxxx
-- 
மணிவண்ணன் சதாசிவம்