linux-kernel - Re: Implementation of fwnode_operations :: device_get_match

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Wed, 1 Mar 2023 17:25:27 +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: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.

> 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?