Received-SPF: pass (google.com: domain of linux-kernel+bounces-117422-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:40f1:3f00::1 as permitted sender) client-ip=2604:1380:40f1:3f00::1;
Date: Mon, 25 Mar 2024 16:57:03 +0100
From: Herve Codina <herve.codina@bootlin.com>
To: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Cc: Vladimir Oltean <vladimir.oltean@nxp.com>, Sui Jingfeng
 <sui.jingfeng@linux.dev>, Jonathan Cameron <Jonathan.Cameron@huawei.com>,
 Daniel Scally <djrscally@gmail.com>, Heikki Krogerus
 <heikki.krogerus@linux.intel.com>, Sakari Ailus
 <sakari.ailus@linux.intel.com>, Greg Kroah-Hartman
 <gregkh@linuxfoundation.org>, "Rafael J. Wysocki" <rafael@kernel.org>,
 linux-acpi@vger.kernel.org, linux-kernel@vger.kernel.org, Rob Herring
 <robh@kernel.org>, Lizhi Hou <lizhi.hou@amd.com>, Luca Ceresoli
 <luca.ceresoli@bootlin.com>
Subject: Re: Implementation of fwnode_operations :: device_get_match_data()
 for software nodes?
Message-ID: <20240325165703.7486eac2@bootlin.com>
In-Reply-To: <ZgGal-SJGWvn80Uk@smile.fi.intel.com>
References: <Y/9iLBWAO37y6lZZ@smile.fi.intel.com>
	<20230301143625.7kdnzujlv4psbhla@skbuf>
	<Y/9qtT0vckSikOKJ@smile.fi.intel.com>
	<20230301152527.khyzifds4w3rkebt@skbuf>
	<Y/9wlDkuh39auAgF@smile.fi.intel.com>
	<20230301171845.oliqbso7v2vmyqr3@skbuf>
	<Y/+MaRO4vrCRFXE8@smile.fi.intel.com>
	<20230301174309.5nqul7vg5uygwtpy@skbuf>
	<ZgF-_ww5k3h9pvEm@smile.fi.intel.com>
	<20240325161627.1c0fc955@bootlin.com>
	<ZgGal-SJGWvn80Uk@smile.fi.intel.com>
Organization: Bootlin
Precedence: bulk
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Hi Andy,

On Mon, 25 Mar 2024 17:39:03 +0200
Andy Shevchenko <andriy.shevchenko@linux.intel.com> wrote:

> On Mon, Mar 25, 2024 at 04:16:27PM +0100, Herve Codina wrote:
> > On Mon, 25 Mar 2024 15:41:19 +0200
> > Andy Shevchenko <andriy.shevchenko@linux.intel.com> wrote:  
> 
> ...
> 
> > > > 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.  
> 
> Thank you, Herve, for looking into this. As far as I understood, slowly but
> successfully the required changes for your use case are being landed. If so,
> it makes driver data for software nodes approach even lower priority.
> 

Yeah, some more changes are still needed to fully support my use case but
everything is on the right track.

Best regards,
Hervé