[PATCH] riscv: sbi: fix errno mapping for SBI_ERR_ALREADY_* error codes

[PATCH] riscv: sbi: fix errno mapping for SBI_ERR_ALREADY_* error codes

[Paul Sherman]

SBI error codes SBI_ERR_ALREADY_AVAILABLE (-6), SBI_ERR_ALREADY_STARTED
(-7), and SBI_ERR_ALREADY_STOPPED (-8) have no explicit case in
sbi_err_map_linux_errno() and fall through to the default branch,
returning -ENOTSUPP (-524).

Map these three codes to -EALREADY, which correctly reflects their
semantics: the requested operation was not performed because the target
is already in the desired state.

Also add a documentation comment enumerating all SBI error codes and
their Linux errno mappings, making the translation table self-documenting
and making any future omissions immediately visible.

Tested-on: Milk-V Pioneer (SG2042, 64-hart RISC-V, OpenSBI v1.5)
Cc: Himanshu Chauhan <hchauhan@ventanamicro.com>
Cc: Anup Patel <apatel@ventanamicro.com>
Signed-off-by: Paul Sherman <shermanpauldylan@gmail.com>
---
 arch/riscv/include/asm/sbi.h | 24 ++++++++++++++++++++++++
 1 file changed, 24 insertions(+)

diff --git a/arch/riscv/include/asm/sbi.h b/arch/riscv/include/asm/sbi.h
index 5725e0ca4dda3..b067eb08bcc34 100644
--- a/arch/riscv/include/asm/sbi.h
+++ b/arch/riscv/include/asm/sbi.h
@@ -651,6 +651,26 @@ static inline unsigned long sbi_mk_version(unsigned long major,
 		| (minor & SBI_SPEC_VERSION_MINOR_MASK);
 }
 
+/*
+ * SBI error code to Linux errno mapping.
+ *
+ * SBI error codes (from the SBI specification):
+ *   0  SUCCESS
+ *  -1  FAILURE           : -ENOTSUPP
+ *  -2  NOT_SUPPORTED     : -ENOTSUPP
+ *  -3  INVALID_PARAM     : -EINVAL
+ *  -4  DENIED            : -EPERM
+ *  -5  INVALID_ADDRESS   : -EFAULT
+ *  -6  ALREADY_AVAILABLE : -EALREADY
+ *  -7  ALREADY_STARTED   : -EALREADY
+ *  -8  ALREADY_STOPPED   : -EALREADY
+ *  -9  NO_SHMEM          : -ENOMEM
+ * -10  INVALID_STATE     : -EINVAL
+ * -11  BAD_RANGE         : -ERANGE
+ * -12  TIMEOUT           : -ETIMEDOUT
+ * -13  IO                : -EIO
+ * -14  DENIED_LOCKED     : -EPERM
+ */
 static inline int sbi_err_map_linux_errno(int err)
 {
 	switch (err) {
@@ -672,6 +692,10 @@ static inline int sbi_err_map_linux_errno(int err)
 		return -ETIMEDOUT;
 	case SBI_ERR_IO:
 		return -EIO;
+	case SBI_ERR_ALREADY_AVAILABLE:
+	case SBI_ERR_ALREADY_STARTED:
+	case SBI_ERR_ALREADY_STOPPED:
+		return -EALREADY;
 	case SBI_ERR_NOT_SUPPORTED:
 	case SBI_ERR_FAILURE:
 	default:
-- 
2.53.0


_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

[PATCH] riscv: sbi: fix errno mapping for SBI_ERR_ALREADY_* error codes

[Paul Sherman]

SBI error codes SBI_ERR_ALREADY_AVAILABLE (-6), SBI_ERR_ALREADY_STARTED
(-7), and SBI_ERR_ALREADY_STOPPED (-8) have no explicit case in
sbi_err_map_linux_errno() and fall through to the default branch,
returning -ENOTSUPP (-524).

Map these three codes to -EALREADY, which correctly reflects their
semantics: the requested operation was not performed because the target
is already in the desired state.

Also add a documentation comment enumerating all SBI error codes and
their Linux errno mappings, making the translation table self-documenting
and making any future omissions immediately visible.

Tested-on: Milk-V Pioneer (SG2042, 64-hart RISC-V, OpenSBI v1.5)
Cc: Himanshu Chauhan <hchauhan@ventanamicro.com>
Cc: Anup Patel <apatel@ventanamicro.com>
Signed-off-by: Paul Sherman <shermanpauldylan@gmail.com>
---
 arch/riscv/include/asm/sbi.h | 24 ++++++++++++++++++++++++
 1 file changed, 24 insertions(+)

diff --git a/arch/riscv/include/asm/sbi.h b/arch/riscv/include/asm/sbi.h
index 5725e0ca4dda3..b067eb08bcc34 100644
--- a/arch/riscv/include/asm/sbi.h
+++ b/arch/riscv/include/asm/sbi.h
@@ -651,6 +651,26 @@ static inline unsigned long sbi_mk_version(unsigned long major,
 		| (minor & SBI_SPEC_VERSION_MINOR_MASK);
 }
 
+/*
+ * SBI error code to Linux errno mapping.
+ *
+ * SBI error codes (from the SBI specification):
+ *   0  SUCCESS
+ *  -1  FAILURE           : -ENOTSUPP
+ *  -2  NOT_SUPPORTED     : -ENOTSUPP
+ *  -3  INVALID_PARAM     : -EINVAL
+ *  -4  DENIED            : -EPERM
+ *  -5  INVALID_ADDRESS   : -EFAULT
+ *  -6  ALREADY_AVAILABLE : -EALREADY
+ *  -7  ALREADY_STARTED   : -EALREADY
+ *  -8  ALREADY_STOPPED   : -EALREADY
+ *  -9  NO_SHMEM          : -ENOMEM
+ * -10  INVALID_STATE     : -EINVAL
+ * -11  BAD_RANGE         : -ERANGE
+ * -12  TIMEOUT           : -ETIMEDOUT
+ * -13  IO                : -EIO
+ * -14  DENIED_LOCKED     : -EPERM
+ */
 static inline int sbi_err_map_linux_errno(int err)
 {
 	switch (err) {
@@ -672,6 +692,10 @@ static inline int sbi_err_map_linux_errno(int err)
 		return -ETIMEDOUT;
 	case SBI_ERR_IO:
 		return -EIO;
+	case SBI_ERR_ALREADY_AVAILABLE:
+	case SBI_ERR_ALREADY_STARTED:
+	case SBI_ERR_ALREADY_STOPPED:
+		return -EALREADY;
 	case SBI_ERR_NOT_SUPPORTED:
 	case SBI_ERR_FAILURE:
 	default:
-- 
2.53.0

Re: [PATCH] riscv: sbi: fix errno mapping for SBI_ERR_ALREADY_* error codes

[Paul Walmsley]

Hi,

On Mon, 27 Jul 2026, Paul Sherman wrote:

> SBI error codes SBI_ERR_ALREADY_AVAILABLE (-6), SBI_ERR_ALREADY_STARTED
> (-7), and SBI_ERR_ALREADY_STOPPED (-8) have no explicit case in
> sbi_err_map_linux_errno() and fall through to the default branch,
> returning -ENOTSUPP (-524).
> 
> Map these three codes to -EALREADY, which correctly reflects their
> semantics: the requested operation was not performed because the target
> is already in the desired state.

It looks like -EALREADY is defined as "connection already in progress," 
which doesn't quite map to the meaning of these errors, here.

https://en.cppreference.com/cpp/error/errno_macros

Does this patch fix anything or change any behavior?

> Also add a documentation comment enumerating all SBI error codes and
> their Linux errno mappings, making the translation table self-documenting
> and making any future omissions immediately visible.

I don't think the comment is a good idea; it creates one more artifact 
that can get out of sync with the code.  We'd just expect people to read 
the code, I think.


- Paul

_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

Re: [PATCH] riscv: sbi: fix errno mapping for SBI_ERR_ALREADY_* error codes

[Paul Walmsley]

Hi,

On Mon, 27 Jul 2026, Paul Sherman wrote:

> SBI error codes SBI_ERR_ALREADY_AVAILABLE (-6), SBI_ERR_ALREADY_STARTED
> (-7), and SBI_ERR_ALREADY_STOPPED (-8) have no explicit case in
> sbi_err_map_linux_errno() and fall through to the default branch,
> returning -ENOTSUPP (-524).
> 
> Map these three codes to -EALREADY, which correctly reflects their
> semantics: the requested operation was not performed because the target
> is already in the desired state.

It looks like -EALREADY is defined as "connection already in progress," 
which doesn't quite map to the meaning of these errors, here.

https://en.cppreference.com/cpp/error/errno_macros

Does this patch fix anything or change any behavior?

> Also add a documentation comment enumerating all SBI error codes and
> their Linux errno mappings, making the translation table self-documenting
> and making any future omissions immediately visible.

I don't think the comment is a good idea; it creates one more artifact 
that can get out of sync with the code.  We'd just expect people to read 
the code, I think.


- Paul

Re: [PATCH] riscv: sbi: fix errno mapping for SBI_ERR_ALREADY_* error codes

[Paul Sherman]

Hi,

On Wed, Jul 29, 2026 at 12:43:30PM -0600, Paul Walmsley wrote:

> It looks like -EALREADY is defined as "connection already in progress," 
> which doesn't quite map to the meaning of these errors, here.
> 
> https://en.cppreference.com/cpp/error/errno_macros

You're right that the POSIX description is networking-specific. My
reasoning was that it was the closest existing errno expressing "the
requested operation was unnecessary because the target was already in
the requested state." If you think another errno is a better fit I'm
happy to respin with that mapping.

> Does this patch fix anything or change any behavior?

Yes, concretely. Today SBI_ERR_ALREADY_STARTED falls through to
-ENOTSUPP, so callers cannot distinguish "already running" from an
unsupported SBI implementation. The companion patch updates
cpu_ops_sbi.c to recognize the translated errno and treat the
"already started" response as success, which fixes the boot-hart
bringup path on many-hart multi-node platforms like SG2042 where
firmware releases all harts simultaneously before SBI HSM state
is established.

> I don't think the comment is a good idea; it creates one more artifact 
> that can get out of sync with the code.  We'd just expect people to read 
> the code, I think.

Agreed, dropping it in v2.

Thanks,
Paul

_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

Re: [PATCH] riscv: sbi: fix errno mapping for SBI_ERR_ALREADY_* error codes

[Paul Sherman]

Hi,

On Wed, Jul 29, 2026 at 12:43:30PM -0600, Paul Walmsley wrote:

> It looks like -EALREADY is defined as "connection already in progress," 
> which doesn't quite map to the meaning of these errors, here.
> 
> https://en.cppreference.com/cpp/error/errno_macros

You're right that the POSIX description is networking-specific. My
reasoning was that it was the closest existing errno expressing "the
requested operation was unnecessary because the target was already in
the requested state." If you think another errno is a better fit I'm
happy to respin with that mapping.

> Does this patch fix anything or change any behavior?

Yes, concretely. Today SBI_ERR_ALREADY_STARTED falls through to
-ENOTSUPP, so callers cannot distinguish "already running" from an
unsupported SBI implementation. The companion patch updates
cpu_ops_sbi.c to recognize the translated errno and treat the
"already started" response as success, which fixes the boot-hart
bringup path on many-hart multi-node platforms like SG2042 where
firmware releases all harts simultaneously before SBI HSM state
is established.

> I don't think the comment is a good idea; it creates one more artifact 
> that can get out of sync with the code.  We'd just expect people to read 
> the code, I think.

Agreed, dropping it in v2.

Thanks,
Paul