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

On Tue, Sep 22, 2026 at 02:20:20PM +0200, David Hildenbrand (Arm) wrote:

On 9/20/26 11:19, Cristian Marussi wrote:

quoted

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

quoted

Reviewed-by: Jonathan Cameron <redacted>
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