On Wed, Apr 16, 2025 at 11:18:19AM +0200, Herve Codina wrote: > Hi Thomas, Andrew, > > On Thu, 10 Apr 2025 08:48:09 +0200 > Thomas Petazzoni <thomas.petazzoni@xxxxxxxxxxx> wrote: > > > On Wed, 9 Apr 2025 17:03:45 +0200 > > Andrew Lunn <andrew@xxxxxxx> 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. > > > > Not sure we need to split right now the existing dtso file nor rename it > even if it is updated in the series. > > This could be done later when an other user of the LAN996x PCI chip is > there. > > Doing something right now will probably need other modification when this > potential other user comes in. Indeed, depending on specificities of this > future user, what is done now could not match the need of this future user. > > Any opinion? I agree support for multiple .dtso can be done later. But i would do the split between the .dtsi file for the PCIe device, and the .dtso file for the board now. That is a pretty fundamental concept in Linux DT support. Andrew
