Switch Arm CCA to use an auxiliary device instead of a platform device

arch/arm64/include/asm/rsi.h +1 -1

index 88b50d660e85..2d2d363aaaee 100644
@@ -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"

drivers/firmware/smccc/smccc.c +3 -0

index bdee057db2fd..fc9b44b7c687 100644
@@ -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",

+ Suzuki

Quoted 10 lines · Aneesh Kumar K.V (Arm)

arch/arm64/include/asm/rsi.h +1 -1

index 88b50d660e85..2d2d363aaaee 100644
@@ -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"

[...]

Quoted 18 lines

drivers/firmware/smccc/smccc.c +3 -0

index bdee057db2fd..fc9b44b7c687 100644
@@ -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",

drivers/firmware/smccc/smccc.c static int __init smccc_devices_init(void) · line 100

Quoted 10 lines

drivers/firmware/smccc/smccc.c +10 -0

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

Quoted 53 lines · Catalin Marinas

Quoted 10 lines · Aneesh Kumar K.V (Arm)

arch/arm64/include/asm/rsi.h +1 -1

index 88b50d660e85..2d2d363aaaee 100644
@@ -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"

[...]

Quoted 18 lines

drivers/firmware/smccc/smccc.c +3 -0

index bdee057db2fd..fc9b44b7c687 100644
@@ -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",

drivers/firmware/smccc/smccc.c static int __init smccc_devices_init(void) · line 100

Quoted 10 lines

drivers/firmware/smccc/smccc.c +10 -0

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

Quoted 3 lines

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;

The SMCCC firmware driver now creates the arm-smccc platform device and also creates the CCA auxiliary devices once the RSI ABI is discovered. This makes the arch-specific arm64_create_dummy_rsi_dev() helper redundant. Remove the arm-cca-dev platform device registration and let the SMCCC probe manage the RSI device.

systemd match on platform:arm-cca-dev for confidential vm detection [1]. Losing the platform device registration can break that. Keeping this removal in its own change makes it easy to revert if that regression blocks the rollout.

[1] https://lore.kernel.org/all/[email protected]

+ Suzuki again

Quoted 11 lines · Aneesh Kumar K.V (Arm)

The SMCCC firmware driver now creates the arm-smccc platform device and also creates the CCA auxiliary devices once the RSI ABI is discovered. This makes the arch-specific arm64_create_dummy_rsi_dev() helper redundant. Remove the arm-cca-dev platform device registration and let the SMCCC probe manage the RSI device.

systemd match on platform:arm-cca-dev for confidential vm detection [1]. Losing the platform device registration can break that. Keeping this removal in its own change makes it easy to revert if that regression blocks the rollout.

Quoted 1 line

[1] https://lore.kernel.org/all/[email protected]

I wouldn't merge this now given that systemd checks this file. Could we have a symbolic link instead for some time until systemd eventually gets updated (years?).

Quoted 14 lines · Catalin Marinas

+ Suzuki again

Quoted 11 lines · Aneesh Kumar K.V (Arm)

The SMCCC firmware driver now creates the arm-smccc platform device and also creates the CCA auxiliary devices once the RSI ABI is discovered. This makes the arch-specific arm64_create_dummy_rsi_dev() helper redundant. Remove the arm-cca-dev platform device registration and let the SMCCC probe manage the RSI device.

systemd match on platform:arm-cca-dev for confidential vm detection [1]. Losing the platform device registration can break that. Keeping this removal in its own change makes it easy to revert if that regression blocks the rollout.

Quoted 6 lines

Quoted 1 line

[1] https://lore.kernel.org/all/[email protected]

I wouldn't merge this now given that systemd checks this file. Could we have a symbolic link instead for some time until systemd eventually gets updated (years?).

I’ll add this in the next revision.

static int create_rsi_compat_link(struct device *target_dev)

{
	struct kobject *platform_kobj;
	/*
	 * target_dev is:
	 * /sys/devices/platform/arm-smccc/arm_cca_guest.arm-rsi-dev.0
	 * Create compat link /sys/devices/platform/arm-cca-dev
	 */
	platform_kobj = target_dev->kobj.parent->parent;

	return sysfs_create_link(platform_kobj,
				 &target_dev->kobj,
				 "arm-cca-dev");

Quoted 26 lines · Aneesh Kumar K.V

Quoted 14 lines · Catalin Marinas

+ Suzuki again

Quoted 11 lines · Aneesh Kumar K.V (Arm)

The SMCCC firmware driver now creates the arm-smccc platform device and also creates the CCA auxiliary devices once the RSI ABI is discovered. This makes the arch-specific arm64_create_dummy_rsi_dev() helper redundant. Remove the arm-cca-dev platform device registration and let the SMCCC probe manage the RSI device.

systemd match on platform:arm-cca-dev for confidential vm detection [1]. Losing the platform device registration can break that. Keeping this removal in its own change makes it easy to revert if that regression blocks the rollout.

Quoted 6 lines

Quoted 1 line

[1] https://lore.kernel.org/all/[email protected]

I wouldn't merge this now given that systemd checks this file. Could we have a symbolic link instead for some time until systemd eventually gets updated (years?).

I’ll add this in the next revision.

static int create_rsi_compat_link(struct device *target_dev)

Quoted 8 lines

{
	struct kobject *platform_kobj;
	/*
	 * target_dev is:
	 * /sys/devices/platform/arm-smccc/arm_cca_guest.arm-rsi-dev.0
	 * Create compat link /sys/devices/platform/arm-cca-dev
	 */
	platform_kobj = target_dev->kobj.parent->parent;

What? That is crazy, you don't know that is always going to be ok.

Quoted 3 lines

	return sysfs_create_link(platform_kobj,
				 &target_dev->kobj,
				 "arm-cca-dev");

No, don't do that, if a driver calls a sysfs* function, something is almost always wrong. Don't be making random sysfs symlinks please.

If userspace can not find the device anymore, that's fine, that's how sysfs works, devices move around all the time. Especially platform devices as those are almost always not supposed to be platform devices :)

thanks,

greg k-h

Quoted 36 lines · Greg KH

Quoted 26 lines · Aneesh Kumar K.V

Quoted 14 lines · Catalin Marinas

+ Suzuki again

Quoted 11 lines · Aneesh Kumar K.V (Arm)

The SMCCC firmware driver now creates the arm-smccc platform device and also creates the CCA auxiliary devices once the RSI ABI is discovered. This makes the arch-specific arm64_create_dummy_rsi_dev() helper redundant. Remove the arm-cca-dev platform device registration and let the SMCCC probe manage the RSI device.

systemd match on platform:arm-cca-dev for confidential vm detection [1]. Losing the platform device registration can break that. Keeping this removal in its own change makes it easy to revert if that regression blocks the rollout.

Quoted 6 lines

Quoted 1 line

[1] https://lore.kernel.org/all/[email protected]

I wouldn't merge this now given that systemd checks this file. Could we have a symbolic link instead for some time until systemd eventually gets updated (years?).

I’ll add this in the next revision.

static int create_rsi_compat_link(struct device *target_dev)

Quoted 8 lines

{
	struct kobject *platform_kobj;
	/*
	 * target_dev is:
	 * /sys/devices/platform/arm-smccc/arm_cca_guest.arm-rsi-dev.0
	 * Create compat link /sys/devices/platform/arm-cca-dev
	 */
	platform_kobj = target_dev->kobj.parent->parent;

Quoted 9 lines

What? That is crazy, you don't know that is always going to be ok.

Quoted 3 lines

	return sysfs_create_link(platform_kobj,
				 &target_dev->kobj,
				 "arm-cca-dev");

No, don't do that, if a driver calls a sysfs* function, something is almost always wrong. Don't be making random sysfs symlinks please.

Sure, but could you explain why this is wrong? Below is the full version of the updated patch.

coco: guest: arm64 Replace RSI platform device with compat symlink

The SMCCC firmware driver now creates the arm-smccc platform device and registers the RSI device as an auxiliary device once the RSI ABI has been discovered. This makes the arch-specific arm64 arm-cca-dev platform device redundant.

Remove the arm64 platform device stub and let the SMCCC core manage RSI device creation.

This changes the real device location from the old platform device path to:

/sys/devices/platform/arm-smccc/arm_cca_guest.arm-rsi-dev.0

Keep userspace compatibility by creating a sysfs symlink at the old path:

/sys/devices/platform/arm-cca-dev

A Debian Code Search check found systemd matching on the old platform:arm-cca-dev device path for confidential VM detection. No other userspace dependency on the old platform device path was found, but keeping the compatibility symlink avoids breaking existing systemd-based detection [1].

[1] https://lore.kernel.org/all/[email protected]

Signed-off-by Aneesh Kumar K.V (Arm) <[email protected]>

modified arch/arm64/kernel/rsi.c

arch/arm64/kernel/rsi.c +0 -15

@@ -159,18 +159,3 @@ void __init arm64_rsi_init(void)
 
 	static_branch_enable(&rsi_present);
 }
-
-static struct platform_device rsi_dev = {
-	.name = "arm-cca-dev",
-	.id = PLATFORM_DEVID_NONE
-};
-
-static int __init arm64_create_dummy_rsi_dev(void)
-{
-	if (is_realm_world() &&
-	    platform_device_register(&rsi_dev))
-		pr_err("failed to register rsi platform device\n");
-	return 0;
-}
-
-arch_initcall(arm64_create_dummy_rsi_dev)

modified drivers/firmware/smccc/rmm.c

(quoted diff) +18 -0

@@ -4,13 +4,31 @@
  */
 
 #include <linux/auxiliary_bus.h>
+#include <linux/sysfs.h>
+#include <linux/device.h>
 
 #include "rmm.h"
 
+static int create_rsi_compat_link(struct device *target_dev)
+{
+	struct kobject *platform_kobj;
+	/*
+	 * target_dev is:
+	 * /sys/devices/platform/arm-smccc/arm_cca_guest.arm-rsi-dev.0
+	 * Create compat link /sys/devices/platform/arm-cca-dev
+	 */
+	platform_kobj = target_dev->kobj.parent->parent;
+
+	return sysfs_create_link(platform_kobj,
+				 &target_dev->kobj,
+				 "arm-cca-dev");
+}
+
 void __init register_rsi_device(struct platform_device *pdev)
 {
 	unsigned long ret;
 	unsigned long ver_lower, ver_higher;
+	struct auxiliary_device *adev;
 
 	if (arm_smccc_1_1_get_conduit() != SMCCC_CONDUIT_SMC)
 		return;

@@ -19,6 +37,10 @@ void __init register_rsi_device(struct platform_device *pdev)
 	if (ret != RSI_SUCCESS)
 		return;

Quoted 10 lines

If userspace can not find the device anymore, that's fine, that's how sysfs works, devices move around all the time. Especially platform devices as those are almost always not supposed to be platform devices :)

thanks,

greg k-h

Quoted 36 lines · Greg KH

Quoted 26 lines · Aneesh Kumar K.V

Quoted 14 lines · Catalin Marinas

+ Suzuki again

Quoted 11 lines · Aneesh Kumar K.V (Arm)

The SMCCC firmware driver now creates the arm-smccc platform device and also creates the CCA auxiliary devices once the RSI ABI is discovered. This makes the arch-specific arm64_create_dummy_rsi_dev() helper redundant. Remove the arm-cca-dev platform device registration and let the SMCCC probe manage the RSI device.

systemd match on platform:arm-cca-dev for confidential vm detection [1]. Losing the platform device registration can break that. Keeping this removal in its own change makes it easy to revert if that regression blocks the rollout.

Quoted 6 lines

Quoted 1 line

[1] https://lore.kernel.org/all/[email protected]

I wouldn't merge this now given that systemd checks this file. Could we have a symbolic link instead for some time until systemd eventually gets updated (years?).

I’ll add this in the next revision.

static int create_rsi_compat_link(struct device *target_dev)

Quoted 8 lines

{
	struct kobject *platform_kobj;
	/*
	 * target_dev is:
	 * /sys/devices/platform/arm-smccc/arm_cca_guest.arm-rsi-dev.0
	 * Create compat link /sys/devices/platform/arm-cca-dev
	 */
	platform_kobj = target_dev->kobj.parent->parent;

Quoted 9 lines

What? That is crazy, you don't know that is always going to be ok.

Quoted 3 lines

	return sysfs_create_link(platform_kobj,
				 &target_dev->kobj,
				 "arm-cca-dev");

No, don't do that, if a driver calls a sysfs* function, something is almost always wrong. Don't be making random sysfs symlinks please.

Sure, but could you explain why this is wrong? Below is the full version of the updated patch.

coco: guest: arm64 Replace RSI platform device with compat symlink

The SMCCC firmware driver now creates the arm-smccc platform device and registers the RSI device as an auxiliary device once the RSI ABI has been discovered. This makes the arch-specific arm64 arm-cca-dev platform device redundant.

Remove the arm64 platform device stub and let the SMCCC core manage RSI device creation.

This changes the real device location from the old platform device path to:

/sys/devices/platform/arm-smccc/arm_cca_guest.arm-rsi-dev.0

Keep userspace compatibility by creating a sysfs symlink at the old path:

/sys/devices/platform/arm-cca-dev

A Debian Code Search check found systemd matching on the old platform:arm-cca-dev device path for confidential VM detection. No other userspace dependency on the old platform device path was found, but keeping the compatibility symlink avoids breaking existing systemd-based detection [1].

[1] https://lore.kernel.org/all/[email protected]

Quoted 69 lines · Aneesh Kumar K.V

Quoted 36 lines · Greg KH

Quoted 26 lines · Aneesh Kumar K.V

Quoted 14 lines · Catalin Marinas

+ Suzuki again

Quoted 11 lines · Aneesh Kumar K.V (Arm)

The SMCCC firmware driver now creates the arm-smccc platform device and also creates the CCA auxiliary devices once the RSI ABI is discovered. This makes the arch-specific arm64_create_dummy_rsi_dev() helper redundant. Remove the arm-cca-dev platform device registration and let the SMCCC probe manage the RSI device.

systemd match on platform:arm-cca-dev for confidential vm detection [1]. Losing the platform device registration can break that. Keeping this removal in its own change makes it easy to revert if that regression blocks the rollout.

Quoted 6 lines

Quoted 1 line

[1] https://lore.kernel.org/all/[email protected]

I wouldn't merge this now given that systemd checks this file. Could we have a symbolic link instead for some time until systemd eventually gets updated (years?).

I’ll add this in the next revision.

static int create_rsi_compat_link(struct device *target_dev)

Quoted 8 lines

{
	struct kobject *platform_kobj;
	/*
	 * target_dev is:
	 * /sys/devices/platform/arm-smccc/arm_cca_guest.arm-rsi-dev.0
	 * Create compat link /sys/devices/platform/arm-cca-dev
	 */
	platform_kobj = target_dev->kobj.parent->parent;

Quoted 9 lines

What? That is crazy, you don't know that is always going to be ok.

Quoted 3 lines

	return sysfs_create_link(platform_kobj,
				 &target_dev->kobj,
				 "arm-cca-dev");

No, don't do that, if a driver calls a sysfs* function, something is almost always wrong. Don't be making random sysfs symlinks please.

Sure, but could you explain why this is wrong? Below is the full version of the updated patch.

coco: guest: arm64 Replace RSI platform device with compat symlink

The SMCCC firmware driver now creates the arm-smccc platform device and registers the RSI device as an auxiliary device once the RSI ABI has been discovered. This makes the arch-specific arm64 arm-cca-dev platform device redundant.

Remove the arm64 platform device stub and let the SMCCC core manage RSI device creation.

This changes the real device location from the old platform device path to:

/sys/devices/platform/arm-smccc/arm_cca_guest.arm-rsi-dev.0

Keep userspace compatibility by creating a sysfs symlink at the old path:

/sys/devices/platform/arm-cca-dev

Quoted 7 lines

A Debian Code Search check found systemd matching on the old platform:arm-cca-dev device path for confidential VM detection. No other userspace dependency on the old platform device path was found, but keeping the compatibility symlink avoids breaking existing systemd-based detection [1].

[1] https://lore.kernel.org/all/[email protected]

Don't attempt to put symlinks between random devices in sysfs, that way lies madness and you will never get anything fixed.

Just fix userspace, it shouldn't have hard-coded a device path in the first place, and you are thinking it would now use a different hard-coded device path? Please do this properly.

Again, there should never be any hard-coded device paths, they are free to move around and be renamed at any time. Use the correct apis instead (walking all bus devices, looking at userspace attributes of classes, etc.)

So your patch is ok, if you remove the symlink stuff.