Re: [PATCH v4 1/2] firmware: smccc: coco: Manage arm-smccc platform device and CCA auxiliary drivers

[Catalin Marinas <catalin.marinas@arm.com>]

+ Suzuki

On Mon, Apr 27, 2026 at 11:46:14AM +0530, Aneesh Kumar K.V (Arm) wrote:
> diff --git a/arch/arm64/include/asm/rsi.h b/arch/arm64/include/asm/rsi.h
> index 88b50d660e85..2d2d363aaaee 100644
> --- a/arch/arm64/include/asm/rsi.h
> +++ b/arch/arm64/include/asm/rsi.h
> @@ -10,7 +10,7 @@
>  #include <linux/jump_label.h>
>  #include <asm/rsi_cmds.h>
>  
> -#define RSI_PDEV_NAME "arm-cca-dev"
> +#define RSI_DEV_NAME "arm-rsi-dev"
[...]
> diff --git a/drivers/firmware/smccc/smccc.c b/drivers/firmware/smccc/smccc.c
> index bdee057db2fd..fc9b44b7c687 100644
> --- a/drivers/firmware/smccc/smccc.c
> +++ b/drivers/firmware/smccc/smccc.c
> @@ -12,6 +12,8 @@
>  #include <linux/platform_device.h>
>  #include <asm/archrandom.h>
>  
> +#include "rmm.h"
> +
>  static u32 smccc_version = ARM_SMCCC_VERSION_1_0;
>  static enum arm_smccc_conduit smccc_conduit = SMCCC_CONDUIT_NONE;
>  
> @@ -85,6 +87,18 @@ static int __init smccc_devices_init(void)
>  {
>  	struct platform_device *pdev;
>  
> +	pdev = platform_device_register_simple("arm-smccc",
> +					PLATFORM_DEVID_NONE, NULL, 0);
> +	if (IS_ERR(pdev)) {
> +		pr_err("arm-smccc: could not register device: %ld\n", PTR_ERR(pdev));
> +	} else {
> +		/*
> +		 * Register the RMI and RSI devices only when firmware exposes
> +		 * the required SMCCC function IDs at a supported revision.
> +		 */
> +		register_rsi_device(pdev);
> +	}

So as per the cover letter, instead of "arm-cca-dev" as a platform
device, we get "arm-smccc" as a platform device with an auxiliary
"arm-rsi-dev" child device. This does not get rid of the platform
device, it just creates a synthetic platform device to represent the
SMCCC firmware interface.

Looking at the earlier discussion, I think this is what Greg/Jason were
suggesting, except that we do not currently have an SMCCC platform
device:

https://lore.kernel.org/all/2025101534-frosty-shank-00b1@gregkh/

If we go this route, shouldn't the platform device above be created only
if !SMCCC_CONDUIT_NONE?

"smccc_trng" would also fit this model (together with the driver),
assuming we don't break any user-space (searching the Debian codebase
did not find any use).

-- 
Catalin