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.
