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: Mon, 25 Mar 2024 16:16:27 +0100
From: Herve Codina <herve.codina@...tlin.com>
To: Vladimir Oltean <vladimir.oltean@....com>
Cc: Andy Shevchenko <andriy.shevchenko@...ux.intel.com>, Sui Jingfeng
 <sui.jingfeng@...ux.dev>, Jonathan Cameron <Jonathan.Cameron@...wei.com>,
 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, Rob Herring
 <robh@...nel.org>, Lizhi Hou <lizhi.hou@....com>, Luca Ceresoli
 <luca.ceresoli@...tlin.com>
Subject: Re: Implementation of fwnode_operations :: device_get_match_data()
 for software nodes?

Hi Vladimir,

+Cc: Rob, Lizhi and Luca.

On Mon, 25 Mar 2024 15:41:19 +0200
Andy Shevchenko <andriy.shevchenko@...ux.intel.com> wrote:

> +Cc: people who might be also interested in this topic.
> 
..
> > 
> > I agree we don't want to have multiple approaches of doing the same thing,
> > but I debate whether I am really doing the same thing?
> > 
> > If software nodes are not designed to be a good fit for my kind of use
> > case, then what are they designed for?  
> 
> I think the hardware should be described in the respective format. Yet, you
> have a point that it's too verbose to the cases when we know the layout of
> the attached (not-hotpluggable) devices.
> 
> There are discussions [1,2] on how to enable DT for the cases when
> non-discoverable HW needs to be detected and enumerated.
> 
> I don't know which solution will eventually be accepted, but my personal
> opinion here that we would like to distantiate from board files as much
> as possible.
> 
> Btw, for the internal (board files) code we may also use property to
> go with (see how spi-pxa2xx uses that) to distinguish configurations.
> But it might be not that straight as with driver data.
> 
> So far, I haven't seen the code (am I mistaken?) which makes use of driver data
> for software nodes.
> 
> [1]: https://lore.kernel.org/lkml/20231128084236.157152-1-wenst@chromium.org/
> [2]: https://lore.kernel.org/lkml/1692120000-46900-1-git-send-email-lizhi.hou@amd.com/
> 
> Aux topics which might not directly be related (in order of declining relevance
> from my p.o.v.):
> https://lore.kernel.org/lkml/20231130165700.685764-1-herve.codina@bootlin.com/
> https://lore.kernel.org/lkml/DM6PR12MB3993D5ECA50B27682AEBE19FCD67A@DM6PR12MB3993.namprd12.prod.outlook.com/
> https://lore.kernel.org/lkml/20240217010557.2381548-1-sboyd@kernel.org/
> 

I work on PCI DT overlay support.
The idea is to have a PCI driver that loads a DT overlay to describe the
hardware embedded in the related PCI device. Some features related to this
topic are already upstream.

Rob did a presentation of this topic at the Linux Plumber conference last
year (https://www.youtube.com/watch?v=MVGElnZW7BQ).

IMHO, your use-case is pretty much the same. Of course it is not a PCI
device but a SPI device. Even if the device beyond the SPI bus cannot be
memory mapped, the idea seems pretty much the same: describe the hardware
embedded in a specific device.

You mentioned that you need the '-@' option when you compile your base dtb.
In fact, it depends on the resources you need to reference from your overlay.
On my case (DT overlay to describe a PCI device), I don't need any references
to a base dtb from the overlay. I don't need to use the '-@' option.
Even more, I started (not yet upstream) to use all of this feature on an ACPI
base system and it works.

My PCI device is a Microchip LAN9662 PCI device.
The Microchip LAN9962 can be a "traditional" SoC with CPU cores and several
IPs but also a PCI device.
When provided as a PCI device, the internal CPU cores are no more available
and replaced by a PCI endpoint IP.
All the accesses done by the SoC CPU cores are replaced by accesses done by
the host PCI system through the PCI endpoint.
Drivers were already present upstream (traditional SoC platform driver such
as i2c mdio, clock, switch, ...) and are used without any modifications for
the PCI device.
All the wiring (mapping) between the PCI world and the internal device
hardware is done using a DT overlay.

Best regards,
Hervé

-- 
Hervé Codina, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com