Re: [PATCH 15/16] misc: lan966x_pci: Add dtso nodes in order to support SFPs

[Andrew Lunn <andrew@lunn.ch>]

On Tue, Apr 08, 2025 at 05:13:54PM +0200, Thomas Petazzoni wrote:
> Andrew, Hervé,
> 
> On Tue Apr 8, 2025 at 4:26 PM CEST, Herve Codina wrote:
> 
> >> What exactly does this DTSO file represent?
> >
> > The dsto represents de board connected to the PCI slot and identified
> > by its PCI vendor/device IDs.
> 
> If I may extend on that by providing what I believe is a more
> accurate/precise definition.
> 
> The DTSO doesn't represent the board, rather it describes the HW
> topology of the devices inside the PCI endpoint. Indeed, the PCI
> endpoint is a full-blown SoC with lots of different HW blocks that
> already have drivers in the kernel (because the same chip can be used
> with Linux running on an ARM core embedded in the SoC, rather than
> access as a PCI endpoint). So the DTSO describes the full topology of
> the HW blocks inside this complex PCI endpoint, just like the DTS
> describes the full topology of the HW blocks inside an SoC.

"HW blocks inside an SoC." That would be the SoC .dtsi file. Anything
outside of the SoC is in the .dts file. OEM vendors take the SoC,
build a board around it, and name there .dts file after the board,
describing how the board components are connected to the SoC.

So..

So by PCI endpoint, you mean the PCIe chip? So it sounds like there
should be a .dtsi file describing the chip.

Everything outside of the chip, like the SFP cages, are up to the
vendor building the board. I would say that should be described in a
.dtso file, which describes how the board components are connected to
the PCIe chip? And that .dtso file should be named after the board,
since there are going to many of them, from different OEM vendors.

	Andrew