Message-ID: <6l3rs5pv6xnrbygpvqrdxqoqtybjyefsltk5bl4336q56rfoza@ejo3sxuufghe>
Date: Mon, 12 Jan 2026 13:49:54 +0530
From: Manivannan Sadhasivam <mani@...nel.org>
To: Andy Shevchenko <andriy.shevchenko@...ux.intel.com>, 
	Dmitry Torokhov <dmitry.torokhov@...il.com>
Cc: 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

+ 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.

> > 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. 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]. 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.

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. 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,
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.

[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.

- Mani

-- 
மணிவண்ணன் சதாசிவம்

Powered by blists - more mailing lists