linux-kernel - Re: [PATCH v2] 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]

Date: Wed, 24 Apr 2024 20:21:30 +0800
From: Sui Jingfeng <sui.jingfeng@...ux.dev>
To: Dmitry Baryshkov <dmitry.baryshkov@...aro.org>
Cc: Andy Shevchenko <andriy.shevchenko@...ux.intel.com>,
 dri-devel@...ts.freedesktop.org, linux-acpi@...r.kernel.org,
 linux-kernel@...r.kernel.org, Daniel Scally <djrscally@...il.com>,
 Heikki Krogerus <heikki.krogerus@...ux.intel.com>,
 Sakari Ailus <sakari.ailus@...ux.intel.com>,
 Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
 "Rafael J. Wysocki" <rafael@...nel.org>
Subject: Re: [PATCH v2] software node: Implement device_get_match_data fwnode
 callback

Hi,

On 2024/4/24 16:39, Dmitry Baryshkov wrote:
>>> Sui, if that fits your purpose,
>> That doesn't fits my purpose, please stop the recommendation, thanks.
>>
>>
>>> please make sure that with your patch
>>> (or the next iteration of it) you can get driver_data from the matched
>>> platform_device_id.
>> No, that's a another problem.
>>
>> The 'platform_get_device_id(pdev)->driver_data' you mentioned is completely
>> off the domain of fwnode API framework. You are completely deviate what we
>> are currently talking about.
>>
>> What we are talking about is something within the fwnode API framework.
>>
>> You can hack the device_get_match_data() function to call platform_get_device_id()
>> as a fallback code path when the fwnode subsystem couldn't return a match data to
>> you. But this is another problem.
> No. I was using this as a pointer for having non-DT driver data.

Whatever.

Whatever how does it going to be used by you, or whatever data the pointer you use to point to.
Just remember one thing, it is not relevant to my patch itself.

> As I
> wrote several paragraphs above, other subsystems use their own
> driver-specific match structures.

Fine, but on the DT systems, they mostly probed via DT.
Thus, the so-called driver-specific match structures won't be used.

> Reworking subsystems one-by-one to
> be able to use generic codepath sounds to me like a way to go.

Fine, you are encouraged to do whatever you like, you don't have to told me.

> Adding
> "compatible" property doesn't.

As I have told you several times, software node is kind of complement to ACPI, it's
definitely need to follow the style of ACPI counterpart. Software node can be secondary
node of the primary ACPI device node. With this understood, please read the implementation
of acpi_of_match_device() before express objection. Or you can read several relevant commit
such as 4222f38ca3b7a ('ACPI / bus: Do not traverse through non-existed device table')
for knowing some extra background.

Beside, users of the software node backend itself can do whatever they like.
The value of the "compatible" property is *just* string, programmers
are free to name their string property in their driver. It is not you to say no though.

No offensive here, I means that both of us are not good at this domain. Especially me,
but at the very least, I'm willing to listen to what expects in ACPI/swnode domain say.
One day, you become the top maintainer of specific domain, and when I go to contribute
then, I will also read to you reviews message carefully.

Back to the technical itself, the "compatible" property is a standard property
of ACPI _DSD object. This is written into the ACPI Spec. The value of the "compatible"
property is just string, store it at 'platform_get_device_id(pdev)->driver_data' or in
'of_device_id->compatible' or some other places doesn't really changes much in semantic.

A device driver can be platform probed, DT probed, ACPI probed, I2C probed, SPI probed...
Take the driver of I2C slave display bridge as an example, it can platform probed, DT probed,
I2C probed, in the future, there may have programmers want to add acpi_device_id, then, it will
gain the 'ACPI probed'.

If each of them introduce a driver-specific match structure. Then, that going to introduce
very heavy maintain overhead to the maintainers, not to mention to achieve your cheap slogan:
"Unifying DT and non-DT paths via generic property / fwnode code".

-- 
Best regards,
Sui