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] [day] [month] [year] [list]
Message-ID: <20251114174844.GA3792362-robh@kernel.org>
Date: Fri, 14 Nov 2025 11:48:44 -0600
From: Rob Herring <robh@...nel.org>
To: Herve Codina <herve.codina@...tlin.com>
Cc: Andrew Lunn <andrew@...n.ch>, Krzysztof Kozlowski <krzk+dt@...nel.org>,
	Conor Dooley <conor+dt@...nel.org>,
	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>, Arnd Bergmann <arnd@...db.de>,
	Saravana Kannan <saravanak@...gle.com>,
	Bjorn Helgaas <bhelgaas@...gle.com>,
	Charles Keepax <ckeepax@...nsource.cirrus.com>,
	Richard Fitzgerald <rf@...nsource.cirrus.com>,
	David Rhodes <david.rhodes@...rus.com>,
	Linus Walleij <linus.walleij@...aro.org>,
	Ulf Hansson <ulf.hansson@...aro.org>,
	Mark Brown <broonie@...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>,
	Len Brown <lenb@...nel.org>, Davidlohr Bueso <dave@...olabs.net>,
	Jonathan Cameron <jonathan.cameron@...wei.com>,
	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>,
	Geert Uytterhoeven <geert+renesas@...der.be>,
	Wolfram Sang <wsa@...nel.org>, devicetree@...r.kernel.org,
	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, linux-pci@...r.kernel.org,
	linux-sound@...r.kernel.org, patches@...nsource.cirrus.com,
	linux-gpio@...r.kernel.org, linux-pm@...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 v4 00/29] lan966x pci device: Add support for SFPs

On Wed, Oct 15, 2025 at 09:13:47AM +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.18-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, patches 4 to 7 fix some more issues related to fw_devlink.
> 
> Patches 8 to 13 introduce and use fw_devlink_set_device() in already
> existing code.
> 
> Patches 14 and 15 are related also to fw_devlink but specific to PCI and
> the device-tree nodes created during enumeration.
> 
> Patches 16, 17 and 18 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 19 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 20 and 21 allow to build clock and i2c controller used by the
> LAN966x PCI device when the LAN966x PCI device is enabled.
> 
> Patches 22 to 26 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 27) update the LAN966x device-tree overlay itself
> to have the SPF ports and devices they depends on described.
> 
> The last two patches (patches 28 and 29) 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 7 to be taken by driver core maintainers
> 
>  - Patches 8 to 13 to be taken by driver core maintainers
> 
>  - Patches 14 and 15 to be taken by driver core or PCI maintainers
>   (depend on patch 8)
> 
>  - Patches 16 to 18 to be taken by I2C maintainers
> 
>  - Patch 19 to be taken by driver core or OF maintainers
> 
>  - Patch 20 to be taken by clock maintainers
> 
>  - Patch 21 to be taken by I2C maintainers
> 
>  - Patches 22 to 29 to be taken by misc maintainers

I don't think this is going to land in 6.19, so I've applied patches 1 
and 3.

Rob

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ