Re: [PATCH v6 00/27] lan966x pci device: Add support for SFPs

[Rob Herring]

On Tue, Apr 7, 2026 at 1:03 PM Rob Herring <robh@xxxxxxxxxx> wrote:
>
> On Wed, Mar 25, 2026 at 03:35:27PM +0100, 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 and 2 ) fixes fw_devlink when it
> > is used with overlay. Those patches were previously sent by Saravana
> > [0]. I rebased them on top of v7.0-rc1.
> >
> > Also I added a call to driver_deferred_probe_trigger() in Saravana's
> > patch (patch 2) to ensure that probes are retried after the modification
> > performed on the dangling consumers. This allows to fix issues reported
> > by Matti and Geert [2] with the previous iteration patches.
> >
> > Those modification were not sufficient in our case and so, on top of
> > that, patches 3 to 5 fix some more issues related to fw_devlink.
> >
> > Patches 6 to 11 introduce and use fw_devlink_set_device() in already
> > existing code.
> >
> > Patches 12 and 13 are related also to fw_devlink but specific to PCI and
> > the device-tree nodes created during enumeration.
> >
> > Patches 14, 15 and 16 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 17 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, enable it on *all*
> > x86 except on those where it leads to issue.
> >
> > Patches 18 and 19 allow to build clock and i2c controller used by the
> > LAN966x PCI device when the LAN966x PCI device is enabled.
> >
> > Patches 20 to 24 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 25) update the LAN966x device-tree overlay itself
> > to have the SPF ports and devices they depends on described.
> >
> > The last two patches (patches 26 and 27) 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.
> >
> > We believe some items from the above list can be merged separately, with
> > no build dependencies. We expect:
> >
> >  - Patches 1 to 5 to be taken by driver core maintainers
>
> From a quick look, can't the first 2 DT patches be taken by me?

Err, I guess patch 2 is really more driver core than DT.

Rob