On Wed, Mar 01, 2023 at 07:18:45PM +0200, Vladimir Oltean wrote: > On Wed, Mar 01, 2023 at 05:34:44PM +0200, Andy Shevchenko wrote: > > On Wed, Mar 01, 2023 at 05:25:27PM +0200, Vladimir Oltean wrote: > > > On Wed, Mar 01, 2023 at 05:09:41PM +0200, Andy Shevchenko wrote: > > > > With overlays you can create the proper DT description stanza and end user's > > > > job is to just put it somewhere and upload via precoded script or so [1]. > > > > > > > > [1]:https://docs.kernel.org/devicetree/overlay-notes.html > > > > > > Ah, okay, no, that's already a no-go, since existing device tree blobs > > > aren't compiled with the dtc "-@" flag which would generate the __symbols__ > > > node necessary for DT overlays to be applied over them. > > > > > > That, and it's clunky and uncalled for in general, both from my > > > perspective as a driver developer and that of a random user, if a driver > > > would just start requiring device tree overlays for more functionality. > > > Overlays address none of the complaints I had with large DT bindings > > > being large in general. They are still equally large, but now, they are > > > also spread into multiple files. > > > > But isn't it what you would like to have working for your case? > > > > Even taking into account the fixed HW layout, it would make sense to have more > > flexible approach to describe it, no? > > Not really, no... > What I would like to have is a (partially) auto- (and dynamically-) generated > firmware description. > > I'd need that in order to have a cleaner separation between the device > drivers for the various peripherals on that Ethernet switch SoC. > Currently, there's a lot of monolithic code to drive those peripherals > that lives in drivers/net/dsa/ but would belong to drivers/net/mdio, > drivers/irqchip/, drivers/gpio/, things like that. > > What I want is the logic that gets me there, with none of the complications > for things I don't need. > > > > > For the second one I'm not really the expert. But either FPGA framework (if > > > > they have anything working for this), or you also may look at Thunderbolt / > > > > USB4 which uses similar approach while being PCIe devices. Okay, the latter > > > > (USB4) is the PCIe topology, while FPGA is whatever behind the PCI switch. > > > > Meaning that FPGA case from HW p.o.v. is closer to your case. > > > > > > A quick glance at Documentation/driver-api/fpga/ shows that it is a > > > framework for dealing with reprogrammable hardware, and has infra to > > > reprogram it. My hardware is fixed-function and doesn't need any of that. > > > > > > Are you suggesting that I should look at reusing some common infra with > > > the fpga subsystem instead? A quick grep for device_add in drivers/fpga/ > > > shows a bunch of open-coded device_add() and platform_device_add() calls. > > > Is this what you wanted me to see or is there something else? > > > > Ah, so they don't have a mechanism on how to describe the hardware inside > > FPGA _after_ reconfiguration and apply it to the system? That's what I meant > > when referred to it. > > Reading Documentation/devicetree/bindings/fpga/fpga-region.txt (with my > limited and ultra-superficial understanding), I guess that they still > use overlays to describe what should be probed on the reprogrammed regions. Yes, that's why I remember overlays approach and FPGA case. I guess you have very similar requirements to get this done: your case is a particular one for FPGA, i.e. (re-)loading the same HW layout over and over. I believe it should be discussed with them being involved. We don't want to have two approaches of similar things in the kernel. -- With Best Regards, Andy Shevchenko
