linux-kernel - Re: [PATCH] software node: Implement 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: Fri, 22 Mar 2024 18:14:11 +0200
From: Andy Shevchenko <andriy.shevchenko@...ux.intel.com>
To: Sui Jingfeng <sui.jingfeng@...ux.dev>
Cc: "Rafael J . Wysocki" <rafael@...nel.org>,
	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>,
	linux-acpi@...r.kernel.org, dri-devel@...ts.freedesktop.org,
	linux-kernel@...r.kernel.org,
	Vladimir Oltean <vladimir.oltean@....com>
Subject: Re: [PATCH] software node: Implement device_get_match_data fwnode
 callback

On Fri, Mar 22, 2024 at 05:00:05PM +0800, Sui Jingfeng wrote:
> On 2024/3/21 04:28, Andy Shevchenko wrote:

..

> > > > > By replacing it with device_get_match_data() and creating a software
> > > > > graph that mimics the OF graph, everything else works fine, except that
> > > > > there isn't an out-of-box replacement for the of_device_get_match_data()
> > > > > function. Because the software node backend of the fwnode framework lacks
> > > > > an implementation for the device_get_match_data callback.
> > > > .device_get_match_data
> > > > 
> > > > > Implement device_get_match_data fwnode callback fwnode callback to fill
> > > > .device_get_match_data
> > > OK, thanks a lot.
> > > 
> > > > > this gap. Device drivers or platform setup codes are expected to provide
> > > > > a "compatible" string property. The value of this string property is used
> > > > > to match against the compatible entries in the of_device_id table. Which
> > > > > is consistent with the original usage style.
> > > > Why do you need to implement the graph in the board file?
> > > It can be inside the chip, there is no clear cut.\
> > Which chip? Flash memory / ROM or you meant something like FPGA here?
> > For the latter there is another discussion on how to use DT overlays
> > in ACPI-enabled environments for the FPGA configurations.
> 
> There are some hardware resource or software entity is created on the
> driver runtime. But DT or DT overlays are compiled before device driver
> get loaded. GPIO-emulated-I2C is just an example, this is kind of driver
> level knowledge on the runtime. With the GPIO or programmable some
> hardware IP unit, device driver authors can change the connection relationship
> at their will at the runtime. While with DT, every thing has to be sure
> before the compile time.
> 
> DT overlays can be a alternative solution, but this doesn't conflict with
> this patch. This patch won't assume how device drives go to use it, and
> allow device driver creating device instead enumerating by DT. In one
> word: "flexibility".

Software nodes in general for the device driver / platform quirks.
They are not designed for what you are talking about here.

Consider using SSDT / DT overlays instead.

-- 
With Best Regards,
Andy Shevchenko