[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <19f1a382-1b6b-42bd-a548-a1a5644c9a1b@lunn.ch>
Date: Mon, 7 Apr 2025 22:05:31 +0200
From: Andrew Lunn <andrew@...n.ch>
To: Herve Codina <herve.codina@...tlin.com>
Cc: 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>,
Thomas Petazzoni <thomas.petazzoni@...tlin.com>
Subject: Re: [PATCH 15/16] misc: lan966x_pci: Add dtso nodes in order to
support SFPs
On Mon, Apr 07, 2025 at 04:55:44PM +0200, Herve Codina wrote:
> Add device-tree nodes needed to support SFPs.
> Those nodes are:
> - the clock controller
> - the i2c controller
> - the i2c mux
> - the SFPs themselves and their related ports in the switch
>
> Signed-off-by: Herve Codina <herve.codina@...tlin.com>
> ---
> drivers/misc/lan966x_pci.dtso | 111 ++++++++++++++++++++++++++++++++++
> 1 file changed, 111 insertions(+)
>
> diff --git a/drivers/misc/lan966x_pci.dtso b/drivers/misc/lan966x_pci.dtso
> index 94a967b384f3..a2015b46cd44 100644
> --- a/drivers/misc/lan966x_pci.dtso
> +++ b/drivers/misc/lan966x_pci.dtso
What exactly does this DTSO file represent?
> @@ -47,6 +47,47 @@ sys_clk: clock-15625000 {
> clock-frequency = <15625000>; /* System clock = 15.625MHz */
> };
>
> + i2c0_emux: i2c0-emux {
> + compatible = "i2c-mux-pinctrl";
> + #address-cells = <1>;
> + #size-cells = <0>;
> + i2c-parent = <&i2c0>;
> + pinctrl-names = "i2c102", "i2c103", "idle";
> + pinctrl-0 = <&i2cmux_0>;
> + pinctrl-1 = <&i2cmux_1>;
> + pinctrl-2 = <&i2cmux_pins>;
> +
> + i2c102: i2c@0 {
> + reg = <0>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> + };
> +
> + i2c103: i2c@1 {
> + reg = <1>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> + };
> + };
> +
> + sfp2: sfp2 {
> + compatible = "sff,sfp";
> + i2c-bus = <&i2c102>;
> + tx-disable-gpios = <&gpio 0 GPIO_ACTIVE_HIGH>;
> + los-gpios = <&gpio 25 GPIO_ACTIVE_HIGH>;
> + mod-def0-gpios = <&gpio 18 GPIO_ACTIVE_LOW>;
> + tx-fault-gpios = <&gpio 2 GPIO_ACTIVE_HIGH>;
DT files are generally hierarchical. There is a soc .dtsi file which
describes everything internal to the SoC. And then we have .dts file
which describes the board the SoC is placed on.
We have a slightly different setup here. A PCI chip instead of a SoC.
And a PCI card in a slot, which could be seen as the board.
The SFP cage is on the board. How the GPIOs and i2c busses are wired
to the SFP cage is a board property, not a SoC/PCI chip
property. Different boards could wire them up differently. So to me,
it seems wrong these nodes are here. They should be in a dtso file
which represents the PCIe board in the slot, and that .dtso file
imports the .dtso file which represents the PCIe chip.
I suppose this comes down to, what do the PCIe IDs represent, since
that is what is used for probing? The PCIe chip, or the board as a
whole. When somebody purchases the chips from Microchip, and builds
their own board, are they required to have their own PCIe IDs, and a
.dtso file representing their board design? The PCIe chip part should
be reusable, so we are talking about stacked dtso files, or at least
included .dtso files.
Andrew
Powered by blists - more mailing lists