Re: [PATCH] of: property: Create devlink between PCI Host bridge and Root Port suppliers

[Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>]

On 2/8/26 2:27 AM, Saravana Kannan wrote:
> On Thu, Feb 5, 2026 at 1:01 AM Manivannan Sadhasivam
> <manivannan.sadhasivam@oss.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@kernel.org>
>>>> Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@oss.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.

I think the issue runs deeper. There are multiple cases where an
OF node has children which represents sub-blocks of a hw block, and
those may house e.g. a phy reference within. I'm not sure the code can
handle this today.

Konrad