[PATCH] pmdomain: rockchip: fix domain check in rockchip_pm_add_one_domain()
Sergey Shtylyov
s.shtylyov at auroraos.dev
Mon Sep 21 09:13:03 PDT 2026
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 at auroraos.dev>
[...]
MBR, Sergey
More information about the linux-arm-kernel
mailing list