linux-kernel - Re: [PATCH 1/2] driver core:add device's platform

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] [day] [month] [year] [list]

Message-ID: <98542eca-d5ba-470e-b6af-990dda167cec@163.com>
Date: Wed, 28 May 2025 17:21:23 +0800
From: Zongmin Zhou <min_halo@....com>
To: Greg KH <gregkh@...uxfoundation.org>
Cc: rafael@...nel.org, dakr@...nel.org, markgross@...nel.org, arnd@...db.de,
 eric.piel@...mplin-utc.net, valentina.manea.m@...il.com, shuah@...nel.org,
 i@...ithal.me, linux-usb@...r.kernel.org, linux-kernel@...r.kernel.org,
 Zongmin Zhou <zhouzongmin@...inos.cn>
Subject: Re: [PATCH 1/2] driver core:add device's platform_data set for faux
 device


On 2025/5/21 18:51, Greg KH wrote:
> On Fri, May 09, 2025 at 10:41:11AM +0800, Zongmin Zhou wrote:
>> On 2025/5/8 17:45, Greg KH wrote:
>>> On Thu, May 08, 2025 at 05:11:47PM +0800, Zongmin Zhou wrote:
>>>> From: Zongmin Zhou <zhouzongmin@...inos.cn>
>>>>
>>>> Most drivers based on platform bus may have specific data
>>>> for the device.And will get this specific data to use
>>>> after device added.
>>>> So keep the setting for device's platform_data is necessary
>>>> for converting platform device to faux device.
>>> I do not understand, why not just use the platform_data field directly
>>> in the faux device structure?  Why change all callers to now have to
>>> keep track of an additional pointer in these create functions?  That
>>> just adds complexity for everyone when almost no one will need it.
>> In fact, I have tried other approaches.
>> However, I found that it must be set after creating faux_dev and before
>> calling the device_add() function.
>>
>> Because the execution of the driver init and the device probe function is
>> asynchronous,
>> and the actual test shows that the probe function is executed
>> before faux_device_create_with_groups () returns faux_device for the caller.
>> But the probe and related functions may need to get plat_data.If plat_data
>> is set after
>> faux_device_create_with_groups() is completed and fdev is returned, the
>> probe function will get NULL.
>>
>> Take vhci-hcd as an example:
>> vhci_hcd_init() calls faux_device_create_with_groups(),
>> Once device_add() is called, vhci_hcd_probe() will be executed immediately.
>> Therefore, the probe function will attempt to obtain plat_data
>> before vhci_hcd_init() receives the return value of faux_device.
>> It's too late to set plat_data after get the return value of faux_device.
>>
>> If there is anything not clearly or other good ways to handle this, please
>> let me know.
> I think you need to unwind the "probe" logic here as it's not needed at
> all.  After you create the faux device, then continue on with the logic
> that is currently in the probe callback.  No need to split this out at
> all, it's the same device being used/handled here, just unwind the logic
> a bit and you should be ok.
I'm very sorry for the late reply.

Yes,actually vhci_hcd_init() can call probe directly without
by the faux_probe call it automatically.
I can make this change for vhci-hcd driver.

Thanks for your suggestion.
>
> hope this helps,
>
> greg k-h