linux-kernel - Re: [PATCH v3 03/14] 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]
Message-ID: <6peb6afhpm4l7opxbdt3b5sx32longevwds5c3dlqji2hr5dlh@kxuvj55jkqgi>
Date: Mon, 12 Jan 2026 14:32:04 +0530
From: Manivannan Sadhasivam <mani@...nel.org>
To: Andy Shevchenko <andriy.shevchenko@...ux.intel.com>
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 10:27:45AM +0200, Andy Shevchenko wrote:
> 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.
> 

Maybe I should look into creating dynamic DT node for the device and insert it
to the uart node. Theoretically it should work.

> > 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?
> 

Not from the overlay binaries (.dtbo), but adding dynamic BT node for the device
based on the enumerated PCI device should work.

- Mani

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