mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Zongmin Zhou <min_halo@163.com>
To: Greg KH <gregkh@linuxfoundation.org>
Cc: rafael@kernel.org, dakr@kernel.org, markgross@kernel.org,
	arnd@arndb.de, eric.piel@tremplin-utc.net,
	valentina.manea.m@gmail.com, shuah@kernel.org, i@zenithal.me,
	linux-usb@vger.kernel.org, linux-kernel@vger.kernel.org,
	Zongmin Zhou <zhouzongmin@kylinos.cn>
Subject: Re: [PATCH 1/2] driver core:add device's platform_data set for faux device
Date: Fri, 9 May 2025 10:41:11 +0800	[thread overview]
Message-ID: <0ef733c0-a945-4eae-8af2-2fe7bb60ed92@163.com> (raw)
In-Reply-To: <2025050854-breeching-had-c9b3@gregkh>


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@kylinos.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.

Thanks very much.

>
> thanks,
>
> greg k-h


  reply	other threads:[~2025-05-09  2:42 UTC|newest]

Thread overview: 33+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-05-08  9:11 [PATCH 0/2] some changes based on faux bus Zongmin Zhou
2025-05-08  9:11 ` [PATCH 1/2] driver core:add device's platform_data set for faux device Zongmin Zhou
2025-05-08  9:45   ` Greg KH
2025-05-09  2:41     ` Zongmin Zhou [this message]
2025-05-21 10:51       ` Greg KH
2025-05-28  9:21         ` Zongmin Zhou
2025-05-08  9:11 ` [PATCH 2/2] usbip: convert to use faux_device Zongmin Zhou
2025-05-09 10:42   ` kernel test robot
2025-06-04  6:54   ` [PATCH v2] " Zongmin Zhou
2025-06-10 15:15     ` Shuah Khan
2025-06-19 11:02       ` Greg KH
2025-06-19 11:01     ` Greg KH
2025-06-20  2:16       ` Zongmin Zhou
2025-06-20  4:29         ` Greg KH
2025-06-20  9:19           ` Zongmin Zhou
2025-06-20  9:27             ` Greg KH
2025-06-20 17:26               ` Shuah Khan
2025-06-24  3:21                 ` Zongmin Zhou
2025-07-01 22:56                   ` Shuah Khan
2025-07-02  2:12                     ` Zongmin Zhou
2025-07-02 23:54                       ` Shuah Khan
2025-07-03  6:04                         ` Zongmin Zhou
2025-07-08 18:16                           ` Shuah Khan
2025-07-09  9:07                             ` Zongmin Zhou
2025-07-09 10:06                               ` Greg KH
2025-07-09 14:20                                 ` Alan Stern
2025-07-09 21:49                                   ` Shuah Khan
2025-07-09 21:57                                     ` Shuah Khan
2025-07-10 14:06                                       ` Alan Stern
2025-07-10 20:33                                         ` Shuah Khan
2025-07-11  5:56                                           ` Greg KH
2025-07-14  5:31                                           ` Zongmin Zhou
2025-07-09 21:33                               ` Shuah Khan

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=0ef733c0-a945-4eae-8af2-2fe7bb60ed92@163.com \
    --to=min_halo@163.com \
    --cc=arnd@arndb.de \
    --cc=dakr@kernel.org \
    --cc=eric.piel@tremplin-utc.net \
    --cc=gregkh@linuxfoundation.org \
    --cc=i@zenithal.me \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-usb@vger.kernel.org \
    --cc=markgross@kernel.org \
    --cc=rafael@kernel.org \
    --cc=shuah@kernel.org \
    --cc=valentina.manea.m@gmail.com \
    --cc=zhouzongmin@kylinos.cn \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®