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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <c14dd5c6-2dae-4398-89a9-342e7a25bb30@lunn.ch>
Date: Tue, 8 Apr 2025 17:38:17 +0200
From: Andrew Lunn <andrew@...n.ch>
To: Thomas Petazzoni <thomas.petazzoni@...tlin.com>
Cc: Herve Codina <herve.codina@...tlin.com>,
	Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
	"Rafael J. Wysocki" <rafael@...nel.org>,
	Danilo Krummrich <dakr@...nel.org>, Shawn Guo <shawnguo@...nel.org>,
	Sascha Hauer <s.hauer@...gutronix.de>,
	Pengutronix Kernel Team <kernel@...gutronix.de>,
	Fabio Estevam <festevam@...il.com>,
	Michael Turquette <mturquette@...libre.com>,
	Stephen Boyd <sboyd@...nel.org>, Andi Shyti <andi.shyti@...nel.org>,
	Wolfram Sang <wsa+renesas@...g-engineering.com>,
	Peter Rosin <peda@...ntia.se>,
	Derek Kiernan <derek.kiernan@....com>,
	Dragan Cvetic <dragan.cvetic@....com>,
	Arnd Bergmann <arnd@...db.de>, Rob Herring <robh@...nel.org>,
	Saravana Kannan <saravanak@...gle.com>,
	Bjorn Helgaas <bhelgaas@...gle.com>,
	Mark Brown <broonie@...nel.org>, Len Brown <lenb@...nel.org>,
	Andy Shevchenko <andriy.shevchenko@...ux.intel.com>,
	Daniel Scally <djrscally@...il.com>,
	Heikki Krogerus <heikki.krogerus@...ux.intel.com>,
	Sakari Ailus <sakari.ailus@...ux.intel.com>,
	Wolfram Sang <wsa@...nel.org>,
	Geert Uytterhoeven <geert+renesas@...der.be>,
	linux-kernel@...r.kernel.org, imx@...ts.linux.dev,
	linux-arm-kernel@...ts.infradead.org, linux-clk@...r.kernel.org,
	linux-i2c@...r.kernel.org, devicetree@...r.kernel.org,
	linux-pci@...r.kernel.org, linux-spi@...r.kernel.org,
	linux-acpi@...r.kernel.org,
	Allan Nielsen <allan.nielsen@...rochip.com>,
	Horatiu Vultur <horatiu.vultur@...rochip.com>,
	Steen Hegelund <steen.hegelund@...rochip.com>,
	Luca Ceresoli <luca.ceresoli@...tlin.com>
Subject: Re: [PATCH 15/16] misc: lan966x_pci: Add dtso nodes in order to
 support SFPs

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