Re: Usability of the device-tree property "external-facing" for PCIe root ports

Re: Usability of the device-tree property "external-facing" for PCIe root ports

[Vidya Sagar]

On 5/10/2022 2:07 AM, Rob Herring wrote:
> External email: Use caution opening links or attachments
> 
> 
> On Sat, May 7, 2022 at 2:18 AM Vidya Sagar <vidyas@nvidia.com> wrote:
>>
>> Hi folks,
> 
> Why send a private email to 4 people to answer on an entirely generic
> subject when you could send it to maillists where anyone besides the 4
> of us could answer and have the answer archived for eternity?
Apologies for not including the mailing list.
I actually wanted to do that but forgot in the end.
Adding Rajat (Based on the offline reply from Bjorn) and mailing list to CC.

> 
>> Given the current implementation of pci_set_bus_of_node() API at
>> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/pci/of.c#n36
>> , it looks like it can be used only for the cases where a PCIe host
>> bridge is specified in the DT along with the root ports it contains
>> (Ex:-
>> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/arm64/boot/dts/nvidia/tegra186.dtsi#n1313
>> ) and not really for a design where the root ports are directly
>> specified in the DT (Ex:-
>> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/arm64/boot/dts/nvidia/tegra194.dtsi#n2418
>> )
>> Is this behavior by design?
> 
> It should work in either case. The code matches PCI devices to DT
> nodes and the hierarchies have to match. If you don't have a DT node
> link/ptr for the PCI device and you think you should, then there's an
> error in your hierarchy. There's no error messages because not having
> a node is not an error.
Currently, I don't have an explicit root port (something like below) 
mentioned under the host bridge device.

pci@0,0 {
         #address-cells = <3>;
         #size-cells = <2>;
         reg = <0 0 0 0 0>;
         ranges;
};

  I would welcome code that checks for DT nodes
> present which have no PCI device created. That's a first step to
> supporting devices which need some setup from DT first to be
> discoverable.
> 
> Most PCIe hosts only have a single root port with BDF 0:0:0, so the
> root port is often not described and any properties of the RP end up
> described in the host bridge node. That's not too bad as 'if not found
> in your node, check the parent node' is a common DT pattern.
Exactly. It is because of this understanding that I have, I specified 
the 'external-facing' property as part of the host bridge node itself 
and expecting the sub-system to apply it for RP also, but it didn't.
If I create an explicit entry for the root port like above and then add 
'external-facing' property as part of that, then, things are working as 
expected.
So, could it be the reason that a host bridge can/may have more than one 
root port and since only a root port can own a slot/port, 
'external-facing' property should be explicitly specified at a root port 
level (in the DT) and not at host bridge level?

Thanks,
Vidya Sagar
> 
> Rob
> 
> P.S. If you want further replies, please add maillists to this discussion.
>