Message-ID: <CACRMN=eu7n+wCD3vRY-7GSKpqf3VG=oyDoQdeauiEHGK-q9pPg@mail.gmail.com>
Date: Sat, 7 Feb 2026 17:27:21 -0800
From: Saravana Kannan <saravanak@...nel.org>
To: Manivannan Sadhasivam <manivannan.sadhasivam@....qualcomm.com>
Cc: Konrad Dybcio <konrad.dybcio@....qualcomm.com>, robh@...nel.org, saravanak@...nel.org, 
	andersson@...nel.org, devicetree@...r.kernel.org, 
	linux-kernel@...r.kernel.org, linux-arm-msm@...r.kernel.org, 
	qiang.yu@....qualcomm.com
Subject: Re: [PATCH] of: property: Create devlink between PCI Host bridge and
 Root Port suppliers

On Thu, Feb 5, 2026 at 1:01 AM Manivannan Sadhasivam
<manivannan.sadhasivam@....qualcomm.com> wrote:
>
> On Thu, Feb 05, 2026 at 09:50:20AM +0100, Konrad Dybcio wrote:
> > On 2/5/26 8:06 AM, Manivannan Sadhasivam wrote:
> > > In the recent times, devicetree started to represent the PCI Host bridge
> > > supplies like PHY in the Root Port nodes as seen in commit 38fcbfbd4207
> > > ("dt-bindings: PCI: qcom: Move PHY & reset GPIO to Root Port node"). But
> > > the Host bridge drivers still need to control these supplies as a part of
> > > their controller initialization/deinitialization sequence.
> > >
> > > So the Host bridge drivers end up parsing the Root Port supplies in their
> > > probe() and controlled them. A downside to this approach is that the
> > > devlink dependency between the suppliers and Host bridge is completely
> > > broken. Due to this, the driver core probes the Host bridge drivers even if
> > > the suppliers are not ready, causing probe deferrals and setup teardowns in
> > > probe().
> > >
> > > These probe deferrals sometime happen over 1000 times (as reported in Qcom
> > > Glymur platform) leading to a waste of CPU resources and increase in boot
> > > time. So to fix these unnecessary deferrals, create devlink between the
> > > Host bridge and Root Port suppliers in of_fwnode_add_links(). This will
> > > allow the driver core to probe the Host bridge drivers only when all Root
> > > Port suppliers are available.
> > >
> > > Reported-by: Bjorn Andersson <andersson@...nel.org>
> > > Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@....qualcomm.com>
> > > ---
> >

100% NACK to this patch. You are touching a core part of the
fw_devlink code to fix it for one specific case. This is not the place
to special case for a property or a framework.

Please fix it on the PCI framework level please. Couple of options:
1. Revert the original patch causing the issue. The patch was from
Qualcomm and they didn't test it on their own devices?

2. PCI does this weird thing of setting the of_node of two different
devices to the same of_node. Now that you have this new node, I think
fixing that behavior to use different of_nodes for the two devices
might be a solution that might work here. I forget the technical terms
used in the PCI framework, but I think one was a the bus device and
the other was the root node.

3. Just create device links if you know you have a weird case of
dependency that fw_devlink doesn't pick up? It's generally more
painful to get fw_devlink to ignore what it thinks is a dependency,
but thankfully that's not the case here.

Please continue cc'ing me in future patches trying to address this.
I'm happy to give guidance if you get stuck.

-Saravana

> > [...]
> >
> > This is not 'required' in bindings and device_type="pci" doesn't uniquely
> > identify root complexes (as can be seen below).. but I suppose this is the
> > best delimiter we've got
> >
>
> Yeah. There is no way to uniquely identify the Host bridges in DT. So I had to
> settle for this.
>
> Maybe I can check for 'device_type', but that will create devlink between switch
> port supplies and Root Ports.
>
> > Perhaps it could be made 'required'?
> >
>
> Nah. Linux will generate domain numbers on its own. Also, this is a Linux
> specific property, so we cannot make it mandatory in dtschema.
>
> - Mani
>
> --
> மணிவண்ணன் சதாசிவம்

Powered by blists - more mailing lists