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: <977d29f6-4157-4fdb-b0d6-c24def482c06@linux.dev>
Date: Wed, 14 Jan 2026 11:40:51 +0800
From: Sui Jingfeng <sui.jingfeng@...ux.dev>
To: Andy Shevchenko <andriy.shevchenko@...ux.intel.com>,
 manivannan.sadhasivam@....qualcomm.com
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>,
 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, linux-pci@...r.kernel.org
Subject: Re: [PATCH v3 03/14] software node: Implement device_get_match_data
 fwnode callback



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.


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

Have you thought about this aspect?
> 

If it is sure thing, then it shouldn't start with "Maybe ..."


>> 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' word, it means 'inconvenience'

> DSA implementation went to the way of taking DT overlay
> approach. Why that one can't be applied here?


Software node as an complement of ACPI, Therefore should do the same.



DT overlay introduce extra overhead/side effects on the non-DT systems.

Besides, DT overlay requires the OS distribution(such as ubuntu) has the 
DT overlay config option selected.



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

You can do that by dropping the maintainer-ship.

Your endless, bruth-force ranting on such a straight-forward thing 
doesn't make much sense, because that waste everybody's time.

> without very good justification


Justifications has been provided over and over again.

> (note, there were at least two attempts in the past to add this stuff

This exactly saying that the implementation is missing.

>   and no-one was merged, 

That's the reason why you see it at least the second time.

have you studied those cases?).
> 

The first one is not 100% correct.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ