Re: [PATCH v12 01/25] firmware: arm_scmi: Add new SCMIv4.0 error codes definitions

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

On Tue, Sep 22, 2026 at 02:20:20PM +0200, David Hildenbrand (Arm) wrote:
> On 9/20/26 11:19, Cristian Marussi wrote:
> > SCMIv4.0 introduces a couple of new possible protocol error codes: add
> > the needed definitions and mappings to Linux error values.

Hi David,

thanks for having a look...

> > 
> > Reviewed-by: Jonathan Cameron <jonathan.cameron@oss.qualcomm.com>
> > Signed-off-by: Cristian Marussi <cristian.marussi@arm.com>
> > ---
> > v4 --> v5
> >  - map SCMI_ERR_IN_USE to EBUSY as natural
> > ---
> >  drivers/firmware/arm_scmi/common.h | 4 ++++
> >  1 file changed, 4 insertions(+)
> > 
> > diff --git a/drivers/firmware/arm_scmi/common.h b/drivers/firmware/arm_scmi/common.h
> > index fe8c22cfb9f7..6f89ba96493d 100644
> > --- a/drivers/firmware/arm_scmi/common.h
> > +++ b/drivers/firmware/arm_scmi/common.h
> > @@ -48,6 +48,8 @@ enum scmi_error_codes {
> >  	SCMI_ERR_GENERIC = -8,	/* Generic Error */
> >  	SCMI_ERR_HARDWARE = -9,	/* Hardware Error */
> >  	SCMI_ERR_PROTOCOL = -10,/* Protocol Error */
> > +	SCMI_ERR_IN_USE = -11,  /* In Use Error */
> > +	SCMI_ERR_PARTIAL = -12, /* Partial Error */
> >  };
> >  
> >  static const int scmi_linux_errmap[] = {
> > @@ -63,6 +65,8 @@ static const int scmi_linux_errmap[] = {
> >  	-EIO,			/* SCMI_ERR_GENERIC */
> >  	-EREMOTEIO,		/* SCMI_ERR_HARDWARE */
> >  	-EPROTO,		/* SCMI_ERR_PROTOCOL */
> > +	-EBUSY,			/* SCMI_ERR_IN_USE */
> > +	-EINVAL,		/* SCMI_ERR_PARTIAL */
> >  };
> >  
> >  static inline int scmi_to_linux_errno(int errno)
> 
> So far we had unique mappings. Now EBUSY and EINVAL could be due to two SCMI_ERR
> each.
> 
> I assume in the later usage there is no need to distinguish them for now? Might
> be worth stating that in the patch description.

Mmmm....indeed this was added to the spec last minute and while
ERR_IN_USE (probably) does NOT necessarily need special treatment (so it
can share -EBUSY), PARTIAL_ERROR must definitely be handled specially ...

Good catch...

I am indeed already handling properly the side-effects of PARTIAL-ERROR
but I will have to properly handle the status code itself in READING_COMPLETE
and in the NOTIFICATION....as a consequence it needs to be distinguishable...

Problem is...there are NOT so many not-already-used error-codes that could
signify such an ambiguos error condition, by the spec:

"The platform returns PARTIAL_ERROR to indicate that some of the telemetry
data could not be collected."

I will use -EBADMSG (but any other advice is welcome) and fix its usage where
needed for DRESP and NOTIF in v13.

Thanks,
Cristian