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

[Manivannan Sadhasivam <mani@kernel.org>]

On Thu, Mar 19, 2026 at 02:50:37PM +0100, Tobias Heider wrote:
> Resending because the previous mail ended up being HTML (sorry)
> 
> On Thu, Mar 19, 2026 at 6:39 AM Manivannan Sadhasivam <mani@kernel.org> wrote:
> >
> > On Wed, Mar 18, 2026 at 09:42:56PM -0500, Bjorn Andersson wrote:
> > > On Mon, Mar 16, 2026 at 08:50:12AM +0530, Manivannan Sadhasivam wrote:
> > > > On Sun, Mar 15, 2026 at 09:53:33PM -0500, Bjorn Andersson 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.
> > > > > >
> > > > >
> > > > > Are you saying that above listed machines has broken PCIe support in
> > > > > v7.0-rc?
> > > > >
> > > >
> > > > I haven't verified it, but I'm pretty sure PCIe is broken on these platforms.
> > > >
> > >
> > > In line with Bjorn's request, we shouldn't have to guess.
> > >
> > > > > It seems this is a (partial) revert of 960609b22be5, is this actually
> > > > > fixing that change, or is it only applicable once some other changes are
> > > > > applied?
> > > > >
> > > >
> > > > This change is fixing the issue in the respective board DTS and is a standalone
> > > > fix on top of v7.0-rc1.
> > > >
> > >
> > > So 960609b22be5 was broken when I merged it?
> > >
> >
> > Broken on the machines mentioned in the commit message, not for all Hamoa
> > platforms.
> >
> > > The commit message says that the commit was incomplete, in that it
> > > didn't fully convert from the old to the new style, so it sounds like
> > > the offending commit was incomplete - but I believe the offending commit
> > > was a workaround for the new solution not being in place and this commit
> > > mostly reverts the changes in the offending commit.
> > >
> >
> > So 960609b22be5 was supposed to move all the platforms from old PCIe binding to
> > new for greater good, but it apparently decided to do so only for a subset of
> > the platforms for some reason which  don't know. But the problem arises due to
> > 960609b22be5 changing the hamoa.dtsi to the new binding which also warrants the
> > platform DTS to also be changed to the new binding. If we only have either dtsi
> > or dts converted and not both to the new binding, the driver will get confused
> > and fail. And this is what exactly happended for below machines:
> >
> >  - 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
> 
> I can confirm the breakage for (some of) the listed devices on Ubuntu.
> We are experimenting with 7.0-rcs ahead of our 26.04 release.
> 
> I'll try to collect some test feedback for the fix.
> I'd certainly appreciate this being included as an rc fix since
> currently half of
> the x1 laptop devices are broken.
> 

Thanks for the report. We will try to get this patch into v7.0-rcS.

It'd be appreciated if you can test this patch and give your tested-by tag.

- Mani

-- 
மணிவண்ணன் சதாசிவம்