Message-ID: <20250703104636.5012907d@bootlin.com>
Date: Thu, 3 Jul 2025 10:46:36 +0200
From: Herve Codina <herve.codina@...tlin.com>
To: Rob Herring <robh@...nel.org>, Pengutronix Kernel Team
 <kernel@...gutronix.de>
Cc: Andrew Lunn <andrew@...n.ch>, 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>, 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>, 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>, Davidlohr Bueso
 <dave@...olabs.net>, Dave Jiang <dave.jiang@...el.com>, Alison Schofield
 <alison.schofield@...el.com>, Vishal Verma <vishal.l.verma@...el.com>, Ira
 Weiny <ira.weiny@...el.com>, Dan Williams <dan.j.williams@...el.com>,
 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, linux-cxl@...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 v3 00/28] lan966x pci device: Add support for SFPs

Hi Rob,

On Fri, 27 Jun 2025 10:58:37 -0500
Rob Herring <robh@...nel.org> wrote:

> On Fri, Jun 13, 2025 at 03:47:40PM +0200, Herve Codina wrote:
> > Hi,
> > 
> > This series add support for SFPs ports available on the LAN966x PCI
> > device. In order to have the SFPs supported, additional devices are
> > needed such as clock controller and I2C.
> > 
> > As a reminder, the LAN966x PCI device driver use a device-tree overlay
> > to describe devices available on the PCI board. Adding support for SFPs
> > ports consists in adding more devices in the already existing
> > device-tree overlay.
> > 
> > With those devices added, the device-tree overlay is more complex and
> > some consumer/supplier relationship are needed in order to remove
> > devices in correct order when the LAN966x PCI driver is removed.
> > 
> > Those links are typically provided by fw_devlink and we faced some
> > issues with fw_devlink and overlays.
> > 
> > This series gives the big picture related to the SFPs support from
> > fixing issues to adding new devices. Of course, it can be split if
> > needed.
> > 
> > The first part of the series (patch 1, 2 and 3) fixes fw_devlink when it
> > is used with overlay. Patches 1 and 3 were previously sent by Saravana
> > [0]. I just rebased them on top of v6.15-rc1 and added patch 2 in order
> > to take into account feedback received on the series sent by Saravana.
> > 
> > Those modification were not sufficient in our case and so, on top of
> > that, patch 4 and 5 fix some more issues related to fw_devlink.
> > 
> > Patches 6 to 12 introduce and use fw_devlink_set_device() in already
> > existing code.
> > 
> > Patches 13 and 14 are related also to fw_devlink but specific to PCI and
> > the device-tree nodes created during enumeration.
> > 
> > Patches 15, 15 and 17 are related fw_devlink too but specific to I2C
> > muxes. Patches purpose is to correctly set a link between an adapter
> > supplier and its consumer. Indeed, an i2c mux adapter's parent is not
> > the i2c mux supplier but the adapter the i2c mux is connected to. Adding
> > a new link between the adapter supplier involved when i2c muxes are used
> > avoid a freeze observed during device removal.
> > 
> > Patch 18 adds support for fw_delink on x86. fw_devlink is needed to have
> > the consumer/supplier relationship between devices in order to ensure a
> > correct device removal order. Adding fw_devlink support for x86 has been
> > tried in the past but was reverted [1] because it broke some systems.
> > Instead of enabling fw_devlink on *all* x86 system or on *all* x86
> > system except on those where it leads to issue, enable it only on system
> > where it is needed.
> > 
> > Patches 19 and 20 allow to build clock and i2c controller used by the
> > LAN966x PCI device when the LAN966x PCI device is enabled.
> > 
> > Patches 21 to 25 are specific to the LAN966x. They touch the current
> > dtso, split it in dtsi/dtso files, rename the dtso and improve the
> > driver to allow easier support for other boards.
> > 
> > The next patch (patch 26) update the LAN966x device-tree overlay itself
> > to have the SPF ports and devices they depends on described.
> > 
> > The last two patches (patches 27 and 28) sort the existing drivers in
> > the needed driver list available in the Kconfig help and add new drivers
> > in this list keep the list up to date with the devices described in the
> > device-tree overlay.
> > 
> > Once again, this series gives the big picture and can be split if
> > needed. Let me know.  
> 
> Please suggest how you think this should get merged? There's 8 
> maintainer trees involved here. Some parts can be merged independently? 
> We need to spread over 2 cycles? Greg just takes it all?
> 
> Rob

I will add this information in the next iteration.

I think, the merge strategy could be the following:
 - patches 1 to 14 could be merged by driver core maintainers in cycle N

 - patches 15 to 17 and 20 could be merged by I2C maintainers in cycle N
   without any dependency issues against other patches.

 - patch 18 could be merged by OF maintainers in cycle N without any
   dependency issues

 - patch 19 could be merged by clock maintainers in cycle N without any
   dependency issues.

 - patch 21 to 25 could be merged by misc maintainers in cycle N without any
   dependency issues.

 - patch 26 to 28, even if there is no compilation dependencies with other
   patches, they need the other patches applied to have a working system and
   so they could be merged in cycle N+1.

Also, as the big picture and the goal of this series has been shown, I can
extract patches from this series and send them alone depending on maintainers
preferences.

Maintainers, just tell me.

Best regards,
Hervé

Powered by blists - more mailing lists