Hi Dhruva,

The fundamental problem here is that uintptr_t is specifically portable storage of object pointers, not function pointers - MISRA is just reflecting that limitation of the language. From §7.18.1.4:

The following type designates an unsigned integer type with the property that any valid pointer to void can be converted to this type, then converted back to pointer to void, and the result will compare equal to the original pointer:

uintptr_t

However, a pointer-to-function cannot be converted to a pointer-to-void (from §6.3.2.3):

1. A pointer to void may be converted to or from a pointer to any incomplete or object type. A pointer to any incomplete or object type may be converted to a pointer to void and back again; the result shall compare equal to the original pointer.

I think the canonical fix in both instances that you referenced is to ensure that the entrypoints are represented using compatible function pointer types (presumably void *(void)), rather than uintptr_t.

Additionally, while pure AArch64 does not architecturally specify a difference between function pointers and object pointers, this is not the case for platforms like Morello where function pointers can encode different capabilities, so this MISRA rule is handy for ensuring these casts do not occur.

Regards,
Chris

From: Dhruva Gole via TF-A <tf-a@lists.trustedfirmware.org>
Date: Tuesday, 8 July 2025 at 12:53
To: tf-a@lists.trustedfirmware.org <tf-a@lists.trustedfirmware.org>
Cc: Boyan Karatotev <Boyan.Karatotev@arm.com>
Subject: [TF-A] MISRA Compliance: Request to consider filing deviation for 11.1 (Function Pointer Conversions) in TF-A

Hello,

Background & Justification:
MISRA C:2012 Rule 11.1 forbids the conversion from a function pointer to any
other type.
However, in the context of TF-A, we encounter scenarios where this conversion
is necessary and performed with full knowledge of the target architecture and
toolchain behavior. A prominent example is in low-level platform code, such as
transferring control between bootloader stages or passing function entry points
for CPU/core bring-up, where the conversion is unavoidable and well-understood.

One such example is the K3 PSCI driver [1] where we pass the k3_sec_entrypoint
which is of type uintptr_t, to the ti_sci_proc_set_boot_cfg
function where the parameter is of type uint64_t.
Another place that triggered the discussions behind this MISRA C issue
was the TI AM62L PSCI driver [2] that needs a 16b aligned function pointer.

We don't have to go into specific case by case discussion of solving these issues,
but just wanted to share example use cases of function pointer conversion.

Request:
I propose we formally document a project-wide MISRA C:2012 Rule 11.1 deviation,
reflecting current and future usage throughout the TF-A codebase. This deviation
allows us to balance MISRA objectives with the practical and architectural
necessities of TF-A development.

Rationale:
* Conversions between function pointers and other types are essential in several
parts of the TF-A codebase, not limited to one module or file.
* Platform-specific code (e.g., power management, bootloader hand-offs) relies
on this pattern for correct operation.

References:
[1] https://github.com/ARM-software/arm-trusted-firmware/blob/master/plat/ti/k3/common/k3_psci.c#L24
[2] https://github.com/ARM-software/arm-trusted-firmware/blob/master/plat/ti/k3low/common/am62l_psci.c#L130

--
Best regards,
Dhruva Gole
Texas Instruments Incorporated
--
TF-A mailing list -- tf-a@lists.trustedfirmware.org
To unsubscribe send an email to tf-a-leave@lists.trustedfirmware.org