optee.c has several switch statements over integer-valued OP-TEE fields
without a default label, and two default clauses that only contain
break. This triggers MISRA C Rule 16.4 findings.

Add explicit default labels to all reported switches and document the
intentional no-op defaults with rationale comments. The new default
paths preserve the existing behavior:
- unsupported parameter attribute types are ignored;
- non-handled RPC commands require no post-processing in Xen;
- unknown RPC function IDs are resumed unchanged.

No functional changes.

Signed-off-by: Bertrand Marquis <bertrand.marquis@arm.com>
---
 xen/arch/arm/tee/optee.c | 11 +++++++++++
 1 file changed, 11 insertions(+)

diff --git a/xen/arch/arm/tee/optee.c b/xen/arch/arm/tee/optee.c
index f719d9d767ab..3d2633237074 100644
--- a/xen/arch/arm/tee/optee.c
+++ b/xen/arch/arm/tee/optee.c
@@ -897,6 +897,9 @@ static int translate_params(struct optee_domain *ctx,
         case OPTEE_MSG_ATTR_TYPE_RMEM_OUTPUT:
         case OPTEE_MSG_ATTR_TYPE_RMEM_INOUT:
             continue;
+        default:
+            /* Ignore unsupported parameter type. */
+            continue;
         }
     }
 
@@ -1027,6 +1030,9 @@ static void copy_std_request_back(struct optee_domain *ctx,
         case OPTEE_MSG_ATTR_TYPE_RMEM_INPUT:
         case OPTEE_MSG_ATTR_TYPE_TMEM_INPUT:
             continue;
+        default:
+            /* No output fields to copy for unsupported parameter type. */
+            continue;
         }
     }
 
@@ -1050,6 +1056,7 @@ static void free_shm_buffers(struct optee_domain *ctx,
             free_optee_shm_buf(ctx, arg->params[i].u.tmem.shm_ref);
             break;
         default:
+            /* No temporary SHM buffer to free for other parameter types. */
             break;
         }
     }
@@ -1503,6 +1510,7 @@ static void handle_rpc_cmd(struct optee_domain *ctx, struct cpu_user_regs *regs,
         case OPTEE_RPC_CMD_SHM_FREE:
             break;
         default:
+            /* Other RPC commands need no Xen-side post-processing here. */
             break;
         }
     }
@@ -1591,6 +1599,9 @@ static void handle_rpc(struct optee_domain *ctx, struct cpu_user_regs *regs)
     case OPTEE_SMC_RPC_FUNC_CMD:
         handle_rpc_cmd(ctx, regs, call);
         return;
+    default:
+        /* Resume the call unchanged for unknown RPC function IDs. */
+        break;
     }
 
     do_call_with_arg(ctx, call, regs, OPTEE_SMC_CALL_RETURN_FROM_RPC,
-- 
2.52.0

Hi Bertrand,

On Fri, Mar 20, 2026 at 10:07 AM Bertrand Marquis
<bertrand.marquis@arm.com> wrote:
>
> optee.c has several switch statements over integer-valued OP-TEE fields
> without a default label, and two default clauses that only contain
> break. This triggers MISRA C Rule 16.4 findings.
>
> Add explicit default labels to all reported switches and document the
> intentional no-op defaults with rationale comments. The new default
> paths preserve the existing behavior:
> - unsupported parameter attribute types are ignored;
> - non-handled RPC commands require no post-processing in Xen;
> - unknown RPC function IDs are resumed unchanged.
>
> No functional changes.
>
> Signed-off-by: Bertrand Marquis <bertrand.marquis@arm.com>
> ---
>  xen/arch/arm/tee/optee.c | 11 +++++++++++
>  1 file changed, 11 insertions(+)

Looks good.

Reviewed-by: Jens Wiklander <jens.wiklander@linaro.org>

Cheers,
Jens

On 20/03/2026 10:07, Bertrand Marquis wrote:
> optee.c has several switch statements over integer-valued OP-TEE fields
> without a default label, and two default clauses that only contain
> break. This triggers MISRA C Rule 16.4 findings.
> 
> Add explicit default labels to all reported switches and document the
> intentional no-op defaults with rationale comments. The new default
> paths preserve the existing behavior:
> - unsupported parameter attribute types are ignored;
> - non-handled RPC commands require no post-processing in Xen;
> - unknown RPC function IDs are resumed unchanged.
> 
> No functional changes.
> 
> Signed-off-by: Bertrand Marquis <bertrand.marquis@arm.com>
Reviewed-by: Michal Orzel <michal.orzel@amd.com>

~Michal