linux-kernel - Re: [PATCH v3 04/14] software node: Add software_node_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: <aWTXwSaNEVZsNxip@smile.fi.intel.com>
Date: Mon, 12 Jan 2026 13:15:13 +0200
From: Andy Shevchenko <andriy.shevchenko@...ux.intel.com>
To: Bartosz Golaszewski <brgl@...nel.org>
Cc: 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>,
	Manivannan Sadhasivam <mani@...nel.org>,
	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>, 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, manivannan.sadhasivam@....qualcomm.com
Subject: Re: [PATCH v3 04/14] software node: Add software_node_match_device()
 API

On Mon, Jan 12, 2026 at 06:03:34AM -0500, Bartosz Golaszewski wrote:
> On Mon, 12 Jan 2026 09:31:44 +0100, Andy Shevchenko
> <andriy.shevchenko@...ux.intel.com> said:
> > On Sat, Jan 10, 2026 at 12:26:22PM +0530, Manivannan Sadhasivam via B4 Relay wrote:
> >
> >> Add software_node_match_device() API to match the swnode device with the
> >> swnode driver. The matching is based on the compatible property in the
> >> device and the driver's of_match_table.
> >
> > NAK. swnodes != real firmware nodes.
> 
> While I'm not arguing that this is *the* solution, I think it warrants
> a discussion on proper matching of devices that are only backed by a software
> node - for instance a serdev device on the auxiliary bus. I understand what
> software nodes were historically but perhaps it's time to extend their role as
> a full-blown firmware node allowing matching with drivers.
> 
> Reusing existing OF IDs is just one way, we could potentially think about a
> high-level fwnode-based device to driver matching?

There is already proposed and agree way to do that via DT overlays.
If one needs to describe the (PnP or hotpluggable) hardware, it's
the way to go as the HW maybe much complex than the just one small UART
appendix.

As per auxdevice, this should not be enumerable by compatible. The auxdevice
usually are created by other devices (from real ones) that _know_ the topology.
I don't see why we need to open the can of worms with the software nodes
to enumerate them as real ones.

P.S. Collect others' opinions (esp. device property reviewers and maintainers)
and we will see. But I do not see any even looking good justification for that.
It might be that I didn't get fully the use case and the other means can not
be used. But taking into account history of the rejection of the matching against
OF compatible string in swnodes suggests that this will stay the way it's now.

-- 
With Best Regards,
Andy Shevchenko