Re: [PATCH v3] driver core: Explicitly initialize struct member @data.have_async in __device_attach()

[Dmitry Torokhov <dmitry.torokhov@gmail.com>]

Hi,

On Fri, Sep 13, 2024 at 10:05:38PM +0800, Zijun Hu wrote:
> From: Zijun Hu <quic_zijuhu@quicinc.com>
> 
> __device_attach() defines struct device_attach_data @data as auto
> variable and needs to use both @data.want_async and @data.have_async
> but it explicitly initializes the former and leaves compiler implicitly
> initialize the later, that does not have an elegant look, solved by
> explicitly initializing the later member as well that also makes @data
> have full initialization.
> 
> Signed-off-by: Zijun Hu <quic_zijuhu@quicinc.com>
> ---
> IMO, this change still has a little bit of value as explained below:
> 
> - Looks at below similar commit:
> Commit: 8f45f5071ad2 ("gpu: host1x: Explicitly initialize host1x_info structures")
> 
> - This change's initialization way is obvious better than
> 
> struct device_attach_data data = {
> 	.dev = dev,
> 	.check_async = allow_async,
> };
> 
> which is better than current
> 
> struct device_attach_data data = {
> 	.dev = dev,
> 	.check_async = allow_async,
> 	.want_async = false,
> };

Unlike host1x_info structure from commit 8f45f5071ad2 that you
referenced, which sole purpose is to describe hardware, this is an
internal structure in drivers/base/dd.c that mixes together scan
parameters and internal state/result. The scan parameters are
initialized explicitly to convey the exact request (i.e.  for given
device we want to try to attach a driver synchronously, but also we
might be interested in knowing if there is a matching driver that
supports asynchronous probe), the state is not mentioned not to draw
attention from the particulars of the request.

I'll leave this to Greg to decide if we wants to apply this change (I
would not), but if you are doing this you need to make similar change
for the 2nd instance of struct device_attach_data.

Thanks.

-- 
Dmitry