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

Message-ID: <2025052139-credibly-dealt-c8aa@gregkh>
Date: Wed, 21 May 2025 12:51:41 +0200
From: Greg KH <gregkh@...uxfoundation.org>
To: Zongmin Zhou <min_halo@....com>
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 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.

hope this helps,

greg k-h