Re: Implementation of fwnode_operations :: device_get_match_data() for software nodes?

[Andy Shevchenko]

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