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