[PATCH v4 0/2] Switch Arm CCA to use an auxiliary device instead of a platform device

[PATCH v4 0/2] Switch Arm CCA to use an auxiliary device instead of a platform device

[Aneesh Kumar K.V (Arm)]

As discussed here:
https://lore.kernel.org/all/20250728135216.48084-12-aneesh.kumar@kernel.org

The general feedback was that a platform device should not be used when
there is no underlying platform resource to represent. The existing CCA
support uses a platform device solely to anchor the TSM interface in the
device hierarchy, which is not an appropriate use of a platform device.
Use an auxiliary device instead to track CCA support.

The TSM framework uses the device abstraction to provide cross-architecture
TSM and TEE I/O functionality, including enumerating available platform TEE
I/O capabilities and provisioning connections between the platform TSM and
device DSMs.

For the CCA platform, the resulting device hierarchy appears as follows.
Note that the auxiliary device is still parented by the arm-smccc platform
device, so the sysfs path remains under /devices/platform/arm-smccc/:

$ cd /sys/class/tsm/
$ ls -al
total 0
drwxr-xr-x    2 root     root             0 Jan  1 00:02 .
drwxr-xr-x   23 root     root             0 Jan  1 00:00 ..
lrwxrwxrwx    1 root     root             0 Jan  1 00:03 tsm0 -> ../../devices/platform/arm-smccc/arm_cca_guest.arm-rsi-dev.0/tsm/tsm0
$

Changes from v3:
https://lore.kernel.org/all/20260309100507.2303361-1-aneesh.kumar@kernel.org
* Rebased onto the latest kernel
* Drop pr_fmt() from drivers/firmware/smccc/rmm.c

Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Greg KH <gregkh@linuxfoundation.org>
Cc: Jeremy Linton <jeremy.linton@arm.com>
Cc: Jonathan Cameron <jic23@kernel.org>
Cc: Lorenzo Pieralisi <lpieralisi@kernel.org>
Cc: Mark Rutland <mark.rutland@arm.com>
Cc: Sudeep Holla <sudeep.holla@arm.com>
Cc: Will Deacon <will@kernel.org>

Aneesh Kumar K.V (Arm) (2):
  firmware: smccc: coco: Manage arm-smccc platform device and CCA
    auxiliary drivers
  coco: guest: arm64: Drop dummy RSI platform device stub

 arch/arm64/include/asm/rsi.h                  |  2 +-
 arch/arm64/kernel/rsi.c                       | 15 -----
 drivers/firmware/smccc/Kconfig                |  1 +
 drivers/firmware/smccc/Makefile               |  1 +
 drivers/firmware/smccc/rmm.c                  | 23 ++++++++
 drivers/firmware/smccc/rmm.h                  | 17 ++++++
 drivers/firmware/smccc/smccc.c                | 14 +++++
 drivers/virt/coco/arm-cca-guest/Kconfig       |  1 +
 drivers/virt/coco/arm-cca-guest/Makefile      |  2 +
 .../{arm-cca-guest.c => arm-cca.c}            | 59 +++++++++----------
 10 files changed, 89 insertions(+), 46 deletions(-)
 create mode 100644 drivers/firmware/smccc/rmm.c
 create mode 100644 drivers/firmware/smccc/rmm.h
 rename drivers/virt/coco/arm-cca-guest/{arm-cca-guest.c => arm-cca.c} (84%)

-- 
2.43.0

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

[Aneesh Kumar K.V (Arm)]

Make the SMCCC driver responsible for registering the arm-smccc platform
device and after confirming the relevant SMCCC function IDs, create
the arm_cca_guest auxiliary device.

Also update the arm-cca-guest driver to use the auxiliary device
interface instead of the platform device (arm-cca-dev). The removal of
the platform device registration will follow in a subsequent patch,
allowing this change to be applied without immediately breaking existing
userspace dependencies [1].

[1] https://lore.kernel.org/all/4a7d84b2-2ec4-4773-a2d5-7b63d5c683cf@arm.com

Signed-off-by: Aneesh Kumar K.V (Arm) <aneesh.kumar@kernel.org>
---
 arch/arm64/include/asm/rsi.h                  |  2 +-
 arch/arm64/kernel/rsi.c                       |  2 +-
 drivers/firmware/smccc/Kconfig                |  1 +
 drivers/firmware/smccc/Makefile               |  1 +
 drivers/firmware/smccc/rmm.c                  | 23 ++++++++
 drivers/firmware/smccc/rmm.h                  | 17 ++++++
 drivers/firmware/smccc/smccc.c                | 14 +++++
 drivers/virt/coco/arm-cca-guest/Kconfig       |  1 +
 drivers/virt/coco/arm-cca-guest/Makefile      |  2 +
 .../{arm-cca-guest.c => arm-cca.c}            | 59 +++++++++----------
 10 files changed, 90 insertions(+), 32 deletions(-)
 create mode 100644 drivers/firmware/smccc/rmm.c
 create mode 100644 drivers/firmware/smccc/rmm.h
 rename drivers/virt/coco/arm-cca-guest/{arm-cca-guest.c => arm-cca.c} (84%)

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"
 
 DECLARE_STATIC_KEY_FALSE(rsi_present);
 
diff --git a/arch/arm64/kernel/rsi.c b/arch/arm64/kernel/rsi.c
index 9e846ce4ef9c..8380e5ba88d2 100644
--- a/arch/arm64/kernel/rsi.c
+++ b/arch/arm64/kernel/rsi.c
@@ -161,7 +161,7 @@ void __init arm64_rsi_init(void)
 }
 
 static struct platform_device rsi_dev = {
-	.name = RSI_PDEV_NAME,
+	.name = "arm-cca-dev",
 	.id = PLATFORM_DEVID_NONE
 };
 
diff --git a/drivers/firmware/smccc/Kconfig b/drivers/firmware/smccc/Kconfig
index 15e7466179a6..2b6984757241 100644
--- a/drivers/firmware/smccc/Kconfig
+++ b/drivers/firmware/smccc/Kconfig
@@ -8,6 +8,7 @@ config HAVE_ARM_SMCCC
 config HAVE_ARM_SMCCC_DISCOVERY
 	bool
 	depends on ARM_PSCI_FW
+	select AUXILIARY_BUS
 	default y
 	help
 	 SMCCC v1.0 lacked discoverability and hence PSCI v1.0 was updated
diff --git a/drivers/firmware/smccc/Makefile b/drivers/firmware/smccc/Makefile
index 40d19144a860..146dc3c03c20 100644
--- a/drivers/firmware/smccc/Makefile
+++ b/drivers/firmware/smccc/Makefile
@@ -2,3 +2,4 @@
 #
 obj-$(CONFIG_HAVE_ARM_SMCCC_DISCOVERY)	+= smccc.o kvm_guest.o
 obj-$(CONFIG_ARM_SMCCC_SOC_ID)	+= soc_id.o
+obj-$(CONFIG_ARM64) += rmm.o
diff --git a/drivers/firmware/smccc/rmm.c b/drivers/firmware/smccc/rmm.c
new file mode 100644
index 000000000000..2a6187df3285
--- /dev/null
+++ b/drivers/firmware/smccc/rmm.c
@@ -0,0 +1,23 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * Copyright (C) 2026 Arm Limited
+ */
+
+#include <linux/auxiliary_bus.h>
+#include "rmm.h"
+
+void __init register_rsi_device(struct platform_device *pdev)
+{
+	unsigned long ret;
+	unsigned long ver_lower, ver_higher;
+
+	if (arm_smccc_1_1_get_conduit() != SMCCC_CONDUIT_SMC)
+		return;
+
+	ret = rsi_request_version(RSI_ABI_VERSION, &ver_lower, &ver_higher);
+	if (ret != RSI_SUCCESS)
+		return;
+
+	__devm_auxiliary_device_create(&pdev->dev,
+				       "arm_cca_guest", RSI_DEV_NAME, NULL, 0);
+}
diff --git a/drivers/firmware/smccc/rmm.h b/drivers/firmware/smccc/rmm.h
new file mode 100644
index 000000000000..a47a650d4f51
--- /dev/null
+++ b/drivers/firmware/smccc/rmm.h
@@ -0,0 +1,17 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+#ifndef _SMCCC_RMM_H
+#define _SMCCC_RMM_H
+
+#include <linux/platform_device.h>
+
+#ifdef CONFIG_ARM64
+#include <asm/rsi_cmds.h>
+void __init register_rsi_device(struct platform_device *pdev);
+#else
+
+static void __init register_rsi_device(struct platform_device *pdev)
+{
+
+}
+#endif
+#endif
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);
+	}
+
 	if (smccc_trng_available) {
 		pdev = platform_device_register_simple("smccc_trng", -1,
 						       NULL, 0);
diff --git a/drivers/virt/coco/arm-cca-guest/Kconfig b/drivers/virt/coco/arm-cca-guest/Kconfig
index 3f0f013f03f1..a42359a90558 100644
--- a/drivers/virt/coco/arm-cca-guest/Kconfig
+++ b/drivers/virt/coco/arm-cca-guest/Kconfig
@@ -2,6 +2,7 @@ config ARM_CCA_GUEST
 	tristate "Arm CCA Guest driver"
 	depends on ARM64
 	select TSM_REPORTS
+	select AUXILIARY_BUS
 	help
 	  The driver provides userspace interface to request and
 	  attestation report from the Realm Management Monitor(RMM).
diff --git a/drivers/virt/coco/arm-cca-guest/Makefile b/drivers/virt/coco/arm-cca-guest/Makefile
index 69eeba08e98a..75a120e24fda 100644
--- a/drivers/virt/coco/arm-cca-guest/Makefile
+++ b/drivers/virt/coco/arm-cca-guest/Makefile
@@ -1,2 +1,4 @@
 # SPDX-License-Identifier: GPL-2.0-only
 obj-$(CONFIG_ARM_CCA_GUEST) += arm-cca-guest.o
+
+arm-cca-guest-y +=  arm-cca.o
diff --git a/drivers/virt/coco/arm-cca-guest/arm-cca-guest.c b/drivers/virt/coco/arm-cca-guest/arm-cca.c
similarity index 84%
rename from drivers/virt/coco/arm-cca-guest/arm-cca-guest.c
rename to drivers/virt/coco/arm-cca-guest/arm-cca.c
index 0c9ea24a200c..7daada072cc0 100644
--- a/drivers/virt/coco/arm-cca-guest/arm-cca-guest.c
+++ b/drivers/virt/coco/arm-cca-guest/arm-cca.c
@@ -3,6 +3,7 @@
  * Copyright (C) 2023 ARM Ltd.
  */
 
+#include <linux/auxiliary_bus.h>
 #include <linux/arm-smccc.h>
 #include <linux/cc_platform.h>
 #include <linux/kernel.h>
@@ -181,52 +182,50 @@ static int arm_cca_report_new(struct tsm_report *report, void *data)
 	return ret;
 }
 
-static const struct tsm_report_ops arm_cca_tsm_ops = {
+static const struct tsm_report_ops arm_cca_tsm_report_ops = {
 	.name = KBUILD_MODNAME,
 	.report_new = arm_cca_report_new,
 };
 
-/**
- * arm_cca_guest_init - Register with the Trusted Security Module (TSM)
- * interface.
- *
- * Return:
- * * %0        - Registered successfully with the TSM interface.
- * * %-ENODEV  - The execution context is not an Arm Realm.
- * * %-EBUSY   - Already registered.
- */
-static int __init arm_cca_guest_init(void)
+static void unregister_cca_tsm_report(void *data)
+{
+	tsm_report_unregister(&arm_cca_tsm_report_ops);
+}
+
+static int cca_devsec_tsm_probe(struct auxiliary_device *adev,
+		const struct auxiliary_device_id *id)
 {
 	int ret;
 
 	if (!is_realm_world())
 		return -ENODEV;
 
-	ret = tsm_report_register(&arm_cca_tsm_ops, NULL);
-	if (ret < 0)
-		pr_err("Error %d registering with TSM\n", ret);
+	ret = tsm_report_register(&arm_cca_tsm_report_ops, NULL);
+	if (ret < 0) {
+		dev_err_probe(&adev->dev, ret, "Error registering with TSM\n");
+		return ret;
+	}
 
-	return ret;
-}
-module_init(arm_cca_guest_init);
+	ret = devm_add_action_or_reset(&adev->dev, unregister_cca_tsm_report, NULL);
+	if (ret < 0) {
+		dev_err_probe(&adev->dev, ret, "Error registering devm action\n");
+		return ret;
+	}
 
-/**
- * arm_cca_guest_exit - unregister with the Trusted Security Module (TSM)
- * interface.
- */
-static void __exit arm_cca_guest_exit(void)
-{
-	tsm_report_unregister(&arm_cca_tsm_ops);
+	return 0;
 }
-module_exit(arm_cca_guest_exit);
 
-/* modalias, so userspace can autoload this module when RSI is available */
-static const struct platform_device_id arm_cca_match[] __maybe_unused = {
-	{ RSI_PDEV_NAME, 0},
-	{ }
+static const struct auxiliary_device_id cca_devsec_tsm_id_table[] = {
+	{ .name =  KBUILD_MODNAME "." RSI_DEV_NAME },
+	{}
 };
+MODULE_DEVICE_TABLE(auxiliary, cca_devsec_tsm_id_table);
 
-MODULE_DEVICE_TABLE(platform, arm_cca_match);
+static struct auxiliary_driver cca_devsec_tsm_driver = {
+	.probe = cca_devsec_tsm_probe,
+	.id_table = cca_devsec_tsm_id_table,
+};
+module_auxiliary_driver(cca_devsec_tsm_driver);
 MODULE_AUTHOR("Sami Mujawar <sami.mujawar@arm.com>");
 MODULE_DESCRIPTION("Arm CCA Guest TSM Driver");
 MODULE_LICENSE("GPL");
-- 
2.43.0

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

[Catalin Marinas]

+ 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

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

[Aneesh Kumar K.V]

Catalin Marinas <catalin.marinas@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

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

[Catalin Marinas]

On Wed, May 13, 2026 at 12:26:13PM +0530, Aneesh Kumar K.V wrote:
> Catalin Marinas <catalin.marinas@arm.com> writes:
> > 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;

Yes but I meant for the "arm-smccc" platform device, not the rsi one.
You don't want it create if SMCCC_CONDUIT_NONE.

-- 
Catalin

[PATCH v4 2/2] coco: guest: arm64: Drop dummy RSI platform device stub

[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.

[1] https://lore.kernel.org/all/4a7d84b2-2ec4-4773-a2d5-7b63d5c683cf@arm.com

Reviewed-by: Jonathan Cameron <jonathan.cameron@huawei.com>
Signed-off-by: Aneesh Kumar K.V (Arm) <aneesh.kumar@kernel.org>
---
 arch/arm64/kernel/rsi.c | 15 ---------------
 1 file changed, 15 deletions(-)

diff --git a/arch/arm64/kernel/rsi.c b/arch/arm64/kernel/rsi.c
index 8380e5ba88d2..9ba29e832685 100644
--- a/arch/arm64/kernel/rsi.c
+++ b/arch/arm64/kernel/rsi.c
@@ -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)
-- 
2.43.0

Re: [PATCH v4 2/2] coco: guest: arm64: Drop dummy RSI platform device stub

[Catalin Marinas]

+ Suzuki again

On Mon, Apr 27, 2026 at 11:46:15AM +0530, Aneesh Kumar K.V (Arm) wrote:
> 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/4a7d84b2-2ec4-4773-a2d5-7b63d5c683cf@arm.com

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

-- 
Catalin

Re: [PATCH v4 2/2] coco: guest: arm64: Drop dummy RSI platform device stub

[Aneesh Kumar K.V]

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

> + Suzuki again
>
> On Mon, Apr 27, 2026 at 11:46:15AM +0530, Aneesh Kumar K.V (Arm) wrote:
>> 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/4a7d84b2-2ec4-4773-a2d5-7b63d5c683cf@arm.com
>
> 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");
}

-aneesh

Re: [PATCH v4 2/2] coco: guest: arm64: Drop dummy RSI platform device stub

[Greg KH]

On Wed, May 13, 2026 at 12:28:12PM +0530, Aneesh Kumar K.V wrote:
> Catalin Marinas <catalin.marinas@arm.com> writes:
> 
> > + Suzuki again
> >
> > On Mon, Apr 27, 2026 at 11:46:15AM +0530, Aneesh Kumar K.V (Arm) wrote:
> >> 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/4a7d84b2-2ec4-4773-a2d5-7b63d5c683cf@arm.com
> >
> > 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;

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

> 	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

Re: [PATCH v4 2/2] coco: guest: arm64: Drop dummy RSI platform device stub

[Aneesh Kumar K.V]

Greg KH <gregkh@linuxfoundation.org> writes:

> On Wed, May 13, 2026 at 12:28:12PM +0530, Aneesh Kumar K.V wrote:
>> Catalin Marinas <catalin.marinas@arm.com> writes:
>> 
>> > + Suzuki again
>> >
>> > On Mon, Apr 27, 2026 at 11:46:15AM +0530, Aneesh Kumar K.V (Arm) wrote:
>> >> 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/4a7d84b2-2ec4-4773-a2d5-7b63d5c683cf@arm.com
>> >
>> > 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;
>
> What?  That is crazy, you don't know that is always going to be ok.
>
>> 	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/4a7d84b2-2ec4-4773-a2d5-7b63d5c683cf@arm.com

Signed-off-by: Aneesh Kumar K.V (Arm) <aneesh.kumar@kernel.org>

modified   arch/arm64/kernel/rsi.c
@@ -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
@@ -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;
 
-	__devm_auxiliary_device_create(&pdev->dev,
-				       "arm_cca_guest", RSI_DEV_NAME, NULL, 0);
+	adev = __devm_auxiliary_device_create(&pdev->dev,
+				"arm_cca_guest", RSI_DEV_NAME, NULL, 0);
+	if (!adev)
+		return;
+
+	create_rsi_compat_link(&adev->dev);
 }


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


-aneesh

Re: [PATCH v4 2/2] coco: guest: arm64: Drop dummy RSI platform device stub

[Aneesh Kumar K.V]

Aneesh Kumar K.V <aneesh.kumar@kernel.org> writes:

> Greg KH <gregkh@linuxfoundation.org> writes:
>
>> On Wed, May 13, 2026 at 12:28:12PM +0530, Aneesh Kumar K.V wrote:
>>> Catalin Marinas <catalin.marinas@arm.com> writes:
>>> 
>>> > + Suzuki again
>>> >
>>> > On Mon, Apr 27, 2026 at 11:46:15AM +0530, Aneesh Kumar K.V (Arm) wrote:
>>> >> 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/4a7d84b2-2ec4-4773-a2d5-7b63d5c683cf@arm.com
>>> >
>>> > 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;
>>
>> What?  That is crazy, you don't know that is always going to be ok.
>>
>>> 	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/4a7d84b2-2ec4-4773-a2d5-7b63d5c683cf@arm.com
>
> Signed-off-by: Aneesh Kumar K.V (Arm) <aneesh.kumar@kernel.org>
>
> modified   arch/arm64/kernel/rsi.c
> @@ -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
> @@ -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;
>  
> -	__devm_auxiliary_device_create(&pdev->dev,
> -				       "arm_cca_guest", RSI_DEV_NAME, NULL, 0);
> +	adev = __devm_auxiliary_device_create(&pdev->dev,
> +				"arm_cca_guest", RSI_DEV_NAME, NULL, 0);
> +	if (!adev)
> +		return;
> +
> +	create_rsi_compat_link(&adev->dev);
>  }

To make this clear, the above implies that adev parent is a platform
device and hence target_dev->kobj.parent->parent should be platform
kobject?

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

-aneesh

Re: [PATCH v4 2/2] coco: guest: arm64: Drop dummy RSI platform device stub

[Greg KH]

On Wed, May 13, 2026 at 02:23:01PM +0530, Aneesh Kumar K.V wrote:
> Greg KH <gregkh@linuxfoundation.org> writes:
> 
> > On Wed, May 13, 2026 at 12:28:12PM +0530, Aneesh Kumar K.V wrote:
> >> Catalin Marinas <catalin.marinas@arm.com> writes:
> >> 
> >> > + Suzuki again
> >> >
> >> > On Mon, Apr 27, 2026 at 11:46:15AM +0530, Aneesh Kumar K.V (Arm) wrote:
> >> >> 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/4a7d84b2-2ec4-4773-a2d5-7b63d5c683cf@arm.com
> >> >
> >> > 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;
> >
> > What?  That is crazy, you don't know that is always going to be ok.
> >
> >> 	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/4a7d84b2-2ec4-4773-a2d5-7b63d5c683cf@arm.com

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.

thanks,

greg k-h