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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <aXHlHyba_kkqnQPP@smile.fi.intel.com>
Date: Thu, 22 Jan 2026 10:51:43 +0200
From: Andy Shevchenko <andriy.shevchenko@...ux.intel.com>
To: Sui Jingfeng <sui.jingfeng@...ux.dev>
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>,
	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>,
	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
Subject: Re: [PATCH v3 03/14] software node: Implement device_get_match_data
 fwnode callback

On Wed, Jan 14, 2026 at 11:21:59AM +0800, Sui Jingfeng wrote:
> On 2026/1/12 15:56, 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.
> 
> It is a *fact* that the broken swnode lacks an implementation for the .device_get_match_data stub.

No need to re-create board files when it's not needed or doesn't fit.

> Otherwise, If it is really done *on purpose*, the maintainers of swnode
> backend could/shall document it in the source file *explicitly*.

Probably it should be spoken in a better way.

> > Have you thought about this aspect?
> 
> If you are sure, then stop telling us something start with "Maybe ..."

I wasn't the author of the swnode idea I can't read their minds. Please,
ask the respective people about this directly.

> > > This makes it difficult to use(and/or test) a few drivers that originates
> > > from DT world on the non-DT platform.
> > How difficult?
> 
> The emphasis isn't on the 'difficult', it means that not convenient
> 
> > DSA implementation went to the way of taking DT overlay
> > approach.
> 
> Software node can do the same implementation just as what ACPI fwnode backend does.
> 
> > Why that one can't be applied here?
> 
> DT overlay requires the OS distribution(such as ubuntu) has theDT overlay
> config option selected.  this is introduce extra overhead/side effects on the
> non-DT systems.

If we have hotpluggable or runtime reconfigurable devices this is the expected
option to support them. I don't see a problem here.

> > > 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
> 
> Whatever!
> 
> Then just stop the endless, bruth-force ranting on such a straight-forward thing.
> 
> > without very good justification
> 
> Justifications has been provided over and over again.
> 
> > (note, there were at least two attempts in the past
> 
> This exactly saying that the implementation is missing.

Now you count a third one for your pleasure :-)

P.S.
We already had this discussion in the past and this attitude won't help
moving forward.

-- 
With Best Regards,
Andy Shevchenko