Date:   Wed, 1 Mar 2023 19:18:45 +0200
From:   Vladimir Oltean <vladimir.oltean@....com>
To:     Andy Shevchenko <andriy.shevchenko@...ux.intel.com>
Cc:     Daniel Scally <djrscally@...il.com>,
        Heikki Krogerus <heikki.krogerus@...ux.intel.com>,
        Sakari Ailus <sakari.ailus@...ux.intel.com>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        "Rafael J. Wysocki" <rafael@...nel.org>,
        linux-acpi@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: Implementation of fwnode_operations :: device_get_match_data()
 for software nodes?

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.

Powered by blists - more mailing lists