Message-ID: <aWSwgRiEkT9unYw9@smile.fi.intel.com>
Date: Mon, 12 Jan 2026 10:27:45 +0200
From: Andy Shevchenko <andriy.shevchenko@...ux.intel.com>
To: Manivannan Sadhasivam <mani@...nel.org>
Cc: Dmitry Torokhov <dmitry.torokhov@...il.com>,
	manivannan.sadhasivam@....qualcomm.com,
	Rob Herring <robh@...nel.org>,
	Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
	Jiri Slaby <jirislaby@...nel.org>,
	Nathan Chancellor <nathan@...nel.org>,
	Nicolas Schier <nicolas.schier@...ux.dev>,
	Hans de Goede <hansg@...nel.org>,
	Ilpo Järvinen <ilpo.jarvinen@...ux.intel.com>,
	Mark Pearson <mpearson-lenovo@...ebb.ca>,
	"Derek J. Clark" <derekjohn.clark@...il.com>,
	Krzysztof Kozlowski <krzk+dt@...nel.org>,
	Conor Dooley <conor+dt@...nel.org>,
	Marcel Holtmann <marcel@...tmann.org>,
	Luiz Augusto von Dentz <luiz.dentz@...il.com>,
	Bartosz Golaszewski <brgl@...ev.pl>,
	Daniel Scally <djrscally@...il.com>,
	Heikki Krogerus <heikki.krogerus@...ux.intel.com>,
	Sakari Ailus <sakari.ailus@...ux.intel.com>,
	"Rafael J. Wysocki" <rafael@...nel.org>,
	Danilo Krummrich <dakr@...nel.org>,
	Bartosz Golaszewski <brgl@...nel.org>, linux-serial@...r.kernel.org,
	linux-kernel@...r.kernel.org, linux-kbuild@...r.kernel.org,
	platform-driver-x86@...r.kernel.org, linux-pci@...r.kernel.org,
	devicetree@...r.kernel.org, linux-arm-msm@...r.kernel.org,
	linux-bluetooth@...r.kernel.org, linux-pm@...r.kernel.org,
	Stephan Gerhold <stephan.gerhold@...aro.org>,
	Dmitry Baryshkov <dmitry.baryshkov@....qualcomm.com>,
	linux-acpi@...r.kernel.org, Sui Jingfeng <sui.jingfeng@...ux.dev>
Subject: Re: [PATCH v3 03/14] software node: Implement device_get_match_data
 fwnode callback

On Mon, Jan 12, 2026 at 01:49:54PM +0530, Manivannan Sadhasivam wrote:
> + Dmitry Torokhov (who was against this patch previously)
> 
> On Mon, Jan 12, 2026 at 09:56:06AM +0200, Andy Shevchenko wrote:
> > On Sat, Jan 10, 2026 at 12:26:21PM +0530, Manivannan Sadhasivam via B4 Relay wrote:
> > 
> > > Because the software node backend of the fwnode API framework lacks an
> > > implementation for the .device_get_match_data function callback.
> > 
> > Maybe this is done on purpose. Have you thought about this aspect?
> 
> IMO, software nodes were introduced to add sub-properties to the existing
> firmware nodes, but it has usecase/potential to go beyond that. More below.

Potential doesn't mean the necessity.

> > > This makes it difficult to use(and/or test) a few drivers that originates
> > > from DT world on the non-DT platform.
> > 
> > How difficult? DSA implementation went to the way of taking DT overlay
> > approach. Why that one can't be applied here?
> 
> Sometimes you do not have any DT node at all.

Yes, that is exactly the case I have referred to. The PCI core (in Linux)
is able to create DT subtree on non-OF based platforms.

> For example, in this series, the
> M.2 pwrseq driver creates the serdev software device for the M.2 BT card to
> match it with the existing OF based BT driver (for non-M2 device). From the
> driver's point of view, a BT device attached to the M.2 slot and over custom
> connectors are both the same. Only difference is that, in the case of custom
> connectors, the bluetooth DT node will have the BT device described and in the
> case of M.2, the device won't get described, but just the connector [1].

So, what's the problem to add such a description? (Assuming you want a customisation
it can be done at run-time, correct?)

> But for the driver to identify the device (since it cannot enumerate it),
> either it has to rely on DT/ACPI or some other means.

Yes.

> In the previous version of this series [2], I used the serdev ID based on the
> product name for creating the serdev device and added a new id_table for serdev
> driver to match with the device [3]. This almost duplicated the existing OF
> match logic.

That's how we do when we want to add a board file, but thing is that we do not
want board files (only in the cases when other ways are impossible or make less
sense).

> Then Bartosz suggested to use swnode approach [4], to get rid of
> the custom serdev ID based matching. When I prototyped, it mostly worked well,

I know that Bart is fan of swnodes, but it should not be used as a silver
bullet, really.

> except that swnode needed to have its own .device_get_match_data(), match() and
> uevent/modalias functions. And if the swnode reused the existing DT compatible
> string, it can work with the existing BT driver without modifications. And this
> approach can also be extended to devices instantiated from the board specific
> drivers.

DT overlay should work without even modifications done to swnode code, right?

> [1] https://lore.kernel.org/all/20260110-pci-m2-e-v3-10-4faee7d0d5ae@oss.qualcomm.com/
> [2] https://lore.kernel.org/all/20251125-pci-m2-e-v2-0-32826de07cc5@oss.qualcomm.com/
> [3] https://lore.kernel.org/all/20251125-pci-m2-e-v2-2-32826de07cc5@oss.qualcomm.com/
> [4] https://lore.kernel.org/all/CAMRc=Mc-WebsQZ3jt2xirioNMticiWj9PJ3fsPTXGCeJ1iTLRg@mail.gmail.com/
> 
> > > Implement the .device_get_match_data fwnode callback, which helps to keep
> > > the three backends of the fwnode API aligned as much as possible. This is
> > > also a fundamental step to make a few drivers OF-independent truely
> > > possible.
> > > 
> > > Device drivers or platform setup codes are expected to provide a software
> > > node string property, named as "compatible". At this moment, the value of
> > > this string property is being used to match against the compatible entries
> > > in the of_device_id table. It can be extended in the future though.
> > 
> > I really do not want to see this patch without very good justification
> > (note, there were at least two attempts in the past to add this stuff
> >  and no-one was merged, have you studied those cases?).
> 
> Yes I did. I didn't put the above justification in the cover letter, as it was
> already overwhelmed with too much information regarding the connector node.
> Maybe I should've added it in the comments section of this patch. But I didn't
> know how to do that with b4.

Then you missed it. The cover letter for such a change is way too short.

-- 
With Best Regards,
Andy Shevchenko

Powered by blists - more mailing lists