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

[Sergey Shtylyov <s.shtylyov@auroraos.dev>]

On 9/21/26 9:36 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...

> 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)...

>> Found by Linux Verification Center (linuxtesting.org) with the Svace
>> static analysis tool.
>>
>> Fixes: 7c696693a4f5 ("soc: rockchip: power-domain: Add power domain driver")
>> Signed-off-by: Sergey Shtylyov <s.shtylyov@auroraos.dev>

[...]

MBR, Sergey