[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20250410084809.1829dc65@windsurf>
Date: Thu, 10 Apr 2025 08:48:09 +0200
From: Thomas Petazzoni <thomas.petazzoni@...tlin.com>
To: Andrew Lunn <andrew@...n.ch>
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 Wed, 9 Apr 2025 17:03:45 +0200
Andrew Lunn <andrew@...n.ch> wrote:
> So it only supports a single .dtbo. In its current form it does not
> scale to multiple .dtso files for multiple different boards built
> around the PCIe chip.
>
> At the moment, that is not really an issue, but when the second board
> comes along, some refactoring will be needed.
Indeed, but that's really an implementation detail. It doesn't change
anything to the overall approach. The only thing that would have to
change is how the driver gets the .dtbo. We could bundle several .dtbos
in the driver, we could fall back to request_firmware(), etc.
Best regards,
Thomas
--
Thomas Petazzoni, co-owner and CEO, Bootlin
Embedded Linux and Kernel engineering and training
https://bootlin.com
Powered by blists - more mailing lists