Hi Andy, On Mon, 25 Mar 2024 17:39:03 +0200 Andy Shevchenko <andriy.shevchenko@xxxxxxxxxxxxxxx> wrote: > On Mon, Mar 25, 2024 at 04:16:27PM +0100, Herve Codina wrote: > > On Mon, 25 Mar 2024 15:41:19 +0200 > > Andy Shevchenko <andriy.shevchenko@xxxxxxxxxxxxxxx> wrote: > > ... > > > > > I agree we don't want to have multiple approaches of doing the same thing, > > > > but I debate whether I am really doing the same thing? > > > > > > > > If software nodes are not designed to be a good fit for my kind of use > > > > case, then what are they designed for? > > > > > > I think the hardware should be described in the respective format. Yet, you > > > have a point that it's too verbose to the cases when we know the layout of > > > the attached (not-hotpluggable) devices. > > > > > > There are discussions [1,2] on how to enable DT for the cases when > > > non-discoverable HW needs to be detected and enumerated. > > > > > > I don't know which solution will eventually be accepted, but my personal > > > opinion here that we would like to distantiate from board files as much > > > as possible. > > > > > > Btw, for the internal (board files) code we may also use property to > > > go with (see how spi-pxa2xx uses that) to distinguish configurations. > > > But it might be not that straight as with driver data. > > > > > > So far, I haven't seen the code (am I mistaken?) which makes use of driver data > > > for software nodes. > > > > > > [1]: https://lore.kernel.org/lkml/20231128084236.157152-1-wenst@xxxxxxxxxxxx/ > > > [2]: https://lore.kernel.org/lkml/1692120000-46900-1-git-send-email-lizhi.hou@xxxxxxx/ > > > > > > Aux topics which might not directly be related (in order of declining relevance > > > from my p.o.v.): > > > https://lore.kernel.org/lkml/20231130165700.685764-1-herve.codina@xxxxxxxxxxx/ > > > https://lore.kernel.org/lkml/DM6PR12MB3993D5ECA50B27682AEBE19FCD67A@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx/ > > > https://lore.kernel.org/lkml/20240217010557.2381548-1-sboyd@xxxxxxxxxx/ > > > > > > > I work on PCI DT overlay support. > > The idea is to have a PCI driver that loads a DT overlay to describe the > > hardware embedded in the related PCI device. Some features related to this > > topic are already upstream. > > > > Rob did a presentation of this topic at the Linux Plumber conference last > > year (https://www.youtube.com/watch?v=MVGElnZW7BQ). > > > > IMHO, your use-case is pretty much the same. Of course it is not a PCI > > device but a SPI device. Even if the device beyond the SPI bus cannot be > > memory mapped, the idea seems pretty much the same: describe the hardware > > embedded in a specific device. > > > > You mentioned that you need the '-@' option when you compile your base dtb. > > In fact, it depends on the resources you need to reference from your overlay. > > On my case (DT overlay to describe a PCI device), I don't need any references > > to a base dtb from the overlay. I don't need to use the '-@' option. > > Even more, I started (not yet upstream) to use all of this feature on an ACPI > > base system and it works. > > > > My PCI device is a Microchip LAN9662 PCI device. > > The Microchip LAN9962 can be a "traditional" SoC with CPU cores and several > > IPs but also a PCI device. > > When provided as a PCI device, the internal CPU cores are no more available > > and replaced by a PCI endpoint IP. > > All the accesses done by the SoC CPU cores are replaced by accesses done by > > the host PCI system through the PCI endpoint. > > Drivers were already present upstream (traditional SoC platform driver such > > as i2c mdio, clock, switch, ...) and are used without any modifications for > > the PCI device. > > All the wiring (mapping) between the PCI world and the internal device > > hardware is done using a DT overlay. > > Thank you, Herve, for looking into this. As far as I understood, slowly but > successfully the required changes for your use case are being landed. If so, > it makes driver data for software nodes approach even lower priority. > Yeah, some more changes are still needed to fully support my use case but everything is on the right track. Best regards, Hervé
