Re: [PATCH v2 3/3] reset: spacemit: fix auxiliary device id

[Alex Elder <elder@riscstar.com>]

On 12/30/25 8:09 PM, Yixun Lan wrote:
> Hi Alex,
> 
> On 18:50 Mon 29 Dec     , Alex Elder wrote:
>> On 12/26/25 12:55 AM, Yixun Lan wrote:
>>> Due to the auxiliary register procedure moved to ccu common module,
>>> the auxiliary device id need to be adjusted, otherwise reset driver
>>> will fail to probe.
>>>
>>> Signed-off-by: Yixun Lan <dlan@gentoo.org>
>>> ---
>>>    drivers/reset/reset-spacemit.c | 2 +-
>>>    1 file changed, 1 insertion(+), 1 deletion(-)
>>>
>>> diff --git a/drivers/reset/reset-spacemit.c b/drivers/reset/reset-spacemit.c
>>> index e1272aff28f7..8922e14fa836 100644
>>> --- a/drivers/reset/reset-spacemit.c
>>> +++ b/drivers/reset/reset-spacemit.c
>>> @@ -278,7 +278,7 @@ static int spacemit_reset_probe(struct auxiliary_device *adev,
>>>    
>>>    #define K1_AUX_DEV_ID(_unit) \
>>>    	{ \
>>> -		.name = "spacemit_ccu_k1." #_unit "-reset", \
>>> +		.name = "spacemit_ccu." _K_RST(_unit), \
>>>    		.driver_data = (kernel_ulong_t)&k1_ ## _unit ## _reset_data, \
>>>    	}
>>
>> The above macro is named K1_AUX_DEV_ID().  Why don't you
>> define K3_AUX_DEV_ID(), which could use "k3" in its name?
>>
> that should also works, the idea of using same macro '_K_RST()' here
> is trying to explictly tell users the clock and reset shares same name

You mean like "spacemit,k1-syscon-mpmu" is used, and you'd rather
name the reset "spacemit.k1-mpmu-reset" because it sort of matches
a little better than "spacemit_ccu_k1.mpmu-reset"?

Anyway, when K1_AUX_DEV_ID() was defined, it was named that way
to suggest a pattern that would mean K3_AUX_DEV_ID() would also
be defined.

I don't really care where the "k1"/"k3" goes, before or after the
period.  But I think the "k1" could be encoded explicitly here
rather than doing it with _K_RST() (i.e., don't even use a macro).

					-Alex
> 
>> Anyway, if you go this route I suggest you drop "K1_" from the
>> name of this macro.
>>
> or could further refactor the code, to make K1/K3 drivers share same macro
> 
> anyway I don't want to change this patch, my goal here is tring to fix
> reset driver after clock common driver refactored plus the modularization
> introduced, it's more proper to leave those refactor work up to Guodong,
> since he did a lot adjustment to add reset support for K3 SoC
>