[PATCH] pmdomain: rockchip: fix domain check in rockchip_pm_add_one_domain()

[Sergey Shtylyov]

On 9/22/26 3:47 AM, Shawn Lin wrote:

[...]

>>>> In rockchip_pm_add_one_domain(), there's the check (most probably for
>>>> the case where the "reg" prop has an unexpected value?) which doesn't
>>>
>>> Agreed that check indeed makes little sense. But "most probably for the
>>> case where the reg prop has an unexpected value" does not hold: an
>>
>>     I tried to guess what the check in question was actually intended for
>> (despite making a little sense as it is now)...
>>
>>> out-of-range reg value is already rejected by the "id >= pmu->info-
>>>> num_domains" check above, and num_domains equals
>>
>>     I noticed. :-)
>>
>>> ARRAY_SIZE(domain_info) for every SoC, so there are no holes in the
>>> table that the new check could catch with the current data. AFAICT, this
>>
>>     Oh, there are holes! :-)
>>     If you look at (and behind) the indexed initializers of *_pm_domains[],
>> you'll see that the indexes don't always start at 0, and so the arrays are
>> actually sparse...
> 
> Looked more closely by each one, you're right.

   Perhaps I just should've been more verbose in the patch description...

>>> patch does not change any runtime behaviour; it only turns dead code
>>> into a defensive check on the match-data tables.
>>
>>     I hope you see now that this defensive check makes a bit more sense...
>>
>>>> make much sense as the variable pd_info will be NULL iff pmu->info->
>>>> domain_info is NULL and the variable id is 0.  What does make sense
>>>> there is checking pd_info->pwr_mask and pd_info->req_mask which (as
>>>> seems to follow from the code) can't both be 0 for a valid domain...
>>>
>>> That means there is no bug being fixed here, should we drop the fixes tag?
>>
>>     I'd like to keep it (but that's up to the maintainers, of course)...
> 
> Sure, it's  Ulf's call. Anyway, feel free to add
> 
> Reviewed-by: Shawn Lin <shawn.lin at rock-chips.com>

   Thank you!

[...]

MBR, Sergey