Re: [PATCH v2] scmi: reset: validate number of reset domains

[Cristian Marussi <cristian.marussi@arm.com>]

On Mon, Nov 03, 2025 at 07:10:43PM +0300, Artem Shimko wrote:
> Add validation to reject zero reset domains during protocol initialization.
> 

Hi Artem,

> The fix adds an explicit check for zero domains in
> scmi_reset_protocol_init(), returning -EINVAL early during protocol
> initialization. This prevents the driver from proceeding with a
> non-functional state and avoids potential kernel panics in functions
> like scmi_reset_domain_reset() and scmi_reset_notify_supported() that
> assume dom_info is always valid.

Indeed, this was alreay spotted/reported/fixed in other protocols, but
the preferred solution is NOT to bail-out when there are ZERO domains,
but to carry-on WITHOUT crashing of course: the reason for this is
testing scenarios in which you can have a platform/FW reply with ZERO
domains.

> 
> The change is minimal and safe, affecting only the error case while
> preserving all existing functionality for valid configurations.
> The existing -ENOMEM handling for memory allocation remains unchanged
> and sufficient.
>

In fact if you look at the code there are already a lot of places in
reset.c where the code path is anyway guarded by num_domains so it is
NOT problematic.

There are, though, other places where the dom-> dereference is NOT
protected and those could be probelematic.

Have you seen any crash related to this for real when zero num_domains
are reported ?

Anyway, it would be good to harden the protocol code as already done
a bit in other protocols in the past, but I advise you to lookup in
perf.c the scmi_perf_domain_lookup() helper as an example and see
how it used across perf to address a similar scenario and adopt the
same solution for reset in order to harden the code while preserving
the possibility to initialize the protocol even with ZERO domains for
testing purposes.

Thanks,
Cristian