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,
};
---
Changes in v3:
- Correct commit message.
- Link to v2: https://lore.kernel.org/r/20240823-fix_have_async-v2-1-ed1039527365@quicinc.com

Changes in v2:
- Remove both fix and stable tag
- Correct both title and commit messages
- Link to v1: https://lore.kernel.org/r/20240823-fix_have_async-v1-1-43a354b6614b@quicinc.com
---
 drivers/base/dd.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/base/dd.c b/drivers/base/dd.c
index a7cc7ff0923b..9e8596773e7f 100644
--- a/drivers/base/dd.c
+++ b/drivers/base/dd.c
@@ -1021,6 +1021,7 @@ static int __device_attach(struct device *dev, bool allow_async)
 			.dev = dev,
 			.check_async = allow_async,
 			.want_async = false,
+			.have_async = false,
 		};
 
 		if (dev->parent)

---
base-commit: efb0b309fa0d8a92f9b303d292944cda08349eed
change-id: 20240823-fix_have_async-3a135618d91b

Best regards,
-- 
Zijun Hu <quic_zijuhu@quicinc.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

On 2024/9/14 01:39, Dmitry Torokhov wrote:
> 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.

sorry, not follow you here

the 2nd instance in __device_attach_async_helper() is good as explained
below:
	struct device_attach_data data = {
		.dev		= dev,
		.check_async	= true,
		.want_async	= true,
	};

1) it is a normal usage to ONLY explicitly initialize these fields that
can't be implicitly initialized by compiler.

2) user does not care about @data.have_async, namely, it is NOT used
later to decide later logic for 2nd instance.

> 
> Thanks.
>