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

Aneesh Kumar K.V aneesh.kumar at kernel.org
Tue May 12 23:56:13 PDT 2026


Catalin Marinas <catalin.marinas at arm.com> writes:

> + 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?
>

register_rsi_device() does check for 

	if (arm_smccc_1_1_get_conduit() != SMCCC_CONDUIT_SMC)
		return;

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

Will switch smccc_trng to an auxiliary device in the next revision.

-aneesh



More information about the linux-arm-kernel mailing list