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

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/[email protected]

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

---
  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                  | 24 ++++++++
  drivers/firmware/smccc/rmm.h                  | 17 ++++++
  drivers/firmware/smccc/smccc.c                | 17 ++++++
  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, 94 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%)

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"
 
  DECLARE_STATIC_KEY_FALSE(rsi_present);
 

arch/arm64/kernel/rsi.c +1 -1

index 9e846ce4ef9c..8380e5ba88d2 100644
@@ -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
  };
 

drivers/firmware/smccc/Kconfig +1 -0

index 15e7466179a6..2b6984757241 100644
@@ -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

drivers/firmware/smccc/Makefile +1 -0

index 40d19144a860..146dc3c03c20 100644
@@ -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

drivers/firmware/smccc/rmm.c new file +24 -0

new file mode 100644
index 000000000000..728338cb5a22
@@ -0,0 +1,24 @@
+// 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);
+}

drivers/firmware/smccc/rmm.h new file +17 -0

new file mode 100644
index 000000000000..a47a650d4f51
@@ -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

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

index bdee057db2fd..eb077b9aa6da 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,21 @@ static int __init smccc_devices_init(void)
  {
  	struct platform_device *pdev;
 
+	if (smccc_conduit == SMCCC_CONDUIT_NONE)
+		return 0;
+
+	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);

drivers/virt/coco/arm-cca-guest/Kconfig +1 -0

index 3f0f013f03f1..a42359a90558 100644
@@ -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).

drivers/virt/coco/arm-cca-guest/Makefile +2 -0

index 69eeba08e98a..75a120e24fda 100644
@@ -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

drivers/virt/coco/arm-cca-guest/arm-cca.c renamed from drivers/virt/coco/arm-cca-guest/arm-cca-guest.c +2 -7

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

drivers/virt/coco/arm-cca-guest/arm-cca.c renamed from drivers/virt/coco/arm-cca-guest/arm-cca-guest.c +11 -12

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

drivers/virt/coco/arm-cca-guest/arm-cca.c renamed from drivers/virt/coco/arm-cca-guest/arm-cca-guest.c +8 -1

+	{ .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 <[email protected]>");
  MODULE_DESCRIPTION("Arm CCA Guest TSM Driver");
  MODULE_LICENSE("GPL");

Hi Aneesh

Quoted 4 lines · 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.

There are a few changes squashed in to this patch.

Please could we split the patch in the following order ?

1. Add platform device for arm-smccc
2. Move TRNG to Auxilliary Device - (Even though it is a later patch, move it before the RSI changes)
3. Move RSI dev as Auxilliary
4. Add the firmware sysfs ABI.

That way, first two could be merged while we figure out (3) and (4)

Hi Aneesh

Quoted 4 lines · 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.

There are a few changes squashed in to this patch. Please could we split the patch in the following order ?

1. Add platform device for arm-smccc

2. Move TRNG to Auxilliary Device - (Even though it is a later patch, move it before the RSI changes)

Quoted 9 lines · Suzuki K Poulose

Quoted 4 lines · 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.

There are a few changes squashed in to this patch. Please could we split the patch in the following order ?

Quoted 1 line

1. Add platform device for arm-smccc

Do not make any more "fake" platform devices please.

Quoted 2 lines

2. Move TRNG to Auxilliary Device - (Even though it is a later patch, move it before the RSI changes)

No, move it to the faux api please.

Quoted 17 lines · Greg Kroah-Hartman

Quoted 10 lines · Suzuki K Poulose

Quoted 4 lines · 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.

There are a few changes squashed in to this patch. Please could we split the patch in the following order ?

1. Add platform device for arm-smccc

Do not make any more "fake" platform devices please.

Quoted 2 lines

2. Move TRNG to Auxilliary Device - (Even though it is a later patch, move it before the RSI changes)

Quoted 1 line

No, move it to the faux api please.

So should we end up with:

/sys/devices/faux/arm-smccc/
smccc_trng/
arm-rsi-dev/

Quoted 20 lines · Catalin Marinas

Quoted 18 lines · Greg Kroah-Hartman

Quoted 10 lines · Suzuki K Poulose

Quoted 4 lines · 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.

There are a few changes squashed in to this patch. Please could we split the patch in the following order ?

1. Add platform device for arm-smccc

Do not make any more "fake" platform devices please.

Quoted 2 lines

2. Move TRNG to Auxilliary Device - (Even though it is a later patch, move it before the RSI changes)

No, move it to the faux api please.

Quoted 5 lines

So should we end up with:

/sys/devices/faux/arm-smccc/
smccc_trng/
arm-rsi-dev/

What types are these child devices? Also faux ones?

Quoted 27 lines · Greg Kroah-Hartman

Quoted 25 lines · Catalin Marinas

Quoted 10 lines · Greg Kroah-Hartman

Quoted 9 lines · Suzuki K Poulose

Quoted 4 lines · 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.

There are a few changes squashed in to this patch. Please could we split the patch in the following order ?

Quoted 8 lines

Quoted 1 line

1. Add platform device for arm-smccc

Do not make any more "fake" platform devices please.

Quoted 2 lines

2. Move TRNG to Auxilliary Device - (Even though it is a later patch, move it before the RSI changes)

No, move it to the faux api please.

So should we end up with:

/sys/devices/faux/arm-smccc/
smccc_trng/
arm-rsi-dev/

Quoted 1 line

What types are these child devices? Also faux ones?

They'd also be faux devices with this structure (in practice they are firmware interfaces that may be backed by some hardware like in the TRNG case, though not directly accessible to Linux).

Quoted 10 lines · Greg Kroah-Hartman

Quoted 9 lines · Suzuki K Poulose

Quoted 4 lines · 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.

There are a few changes squashed in to this patch. Please could we split the patch in the following order ?

Quoted 8 lines

Quoted 1 line

1. Add platform device for arm-smccc

Do not make any more "fake" platform devices please.

Quoted 2 lines

2. Move TRNG to Auxilliary Device - (Even though it is a later patch, move it before the RSI changes)

No, move it to the faux api please.

So should we end up with:

/sys/devices/faux/arm-smccc/
smccc_trng/
arm-rsi-dev/
tsm/tsm0

/sys/class/tsm/tsm0

    -> ../../devices/faux/arm-smccc/arm-rsi-dev/tsm/tsm0

/sys/firmware/cca/
realm_guest

Quoted 30 lines · Catalin Marinas

Quoted 10 lines · Greg Kroah-Hartman

Quoted 9 lines · Suzuki K Poulose

Quoted 4 lines · 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.

There are a few changes squashed in to this patch. Please could we split the patch in the following order ?

Quoted 8 lines

Quoted 1 line

1. Add platform device for arm-smccc

Do not make any more "fake" platform devices please.

Quoted 2 lines

2. Move TRNG to Auxilliary Device - (Even though it is a later patch, move it before the RSI changes)

No, move it to the faux api please.

So should we end up with:

/sys/devices/faux/arm-smccc/
smccc_trng/
arm-rsi-dev/
tsm/tsm0

/sys/class/tsm/tsm0

    -> ../../devices/faux/arm-smccc/arm-rsi-dev/tsm/tsm0

Quoted 2 lines

/sys/firmware/cca/
realm_guest

But we need the ability to autoload different TSM backend drivers based on the support/availability of these SMCCC function-id ranges. faux device don't support that.

Quoted 30 lines · Catalin Marinas

Quoted 10 lines · Greg Kroah-Hartman

Quoted 9 lines · Suzuki K Poulose

Quoted 4 lines · 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.

There are a few changes squashed in to this patch. Please could we split the patch in the following order ?

Quoted 8 lines

Quoted 1 line

1. Add platform device for arm-smccc

Do not make any more "fake" platform devices please.

Quoted 2 lines

2. Move TRNG to Auxilliary Device - (Even though it is a later patch, move it before the RSI changes)

No, move it to the faux api please.

So should we end up with:

/sys/devices/faux/arm-smccc/
smccc_trng/
arm-rsi-dev/
tsm/tsm0

/sys/class/tsm/tsm0

    -> ../../devices/faux/arm-smccc/arm-rsi-dev/tsm/tsm0

Quoted 2 lines

/sys/firmware/cca/
realm_guest

But we need the ability to autoload different TSM backend drivers based on the support/availability of these SMCCC function-id ranges. faux device don't support that.

Quoted 11 lines · Suzuki K Poulose

Hi Aneesh

Quoted 4 lines · 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.

There are a few changes squashed in to this patch. Please could we split the patch in the following order ?

Quoted 1 line

1. Add platform device for arm-smccc

Do not make any more "fake" platform devices please.

Quoted 2 lines

2. Move TRNG to Auxilliary Device - (Even though it is a later patch, move it before the RSI changes)

No, move it to the faux api please.

Quoted 12 lines · Greg KH

Quoted 11 lines · Suzuki K Poulose

Hi Aneesh

Quoted 4 lines · 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.

There are a few changes squashed in to this patch. Please could we split the patch in the following order ?

Quoted 9 lines

Quoted 1 line

1. Add platform device for arm-smccc

Do not make any more "fake" platform devices please.

Quoted 2 lines

2. Move TRNG to Auxilliary Device - (Even though it is a later patch, move it before the RSI changes)

No, move it to the faux api please.

Maybe I was not complete in my previous reply. I did not want to repeat the entire thread, so I quoted the lore link for more details.

1. We have platform firmware-provided SMCCC interfaces. Based on the support/availability of these function IDs, we want to load multiple drivers.
2. This patch series adds a platform device to represent the firmware-provided SMCCC resource.
3. Different SMCCC ranges are now represented as auxiliary devices.
4. Different subsystems, such as TSM, can autoload their backend drivers based on the availability of these SMCCC ranges, which are now represented as auxiliary devices.

You had agreed to all of this in the previous discussion here:
https://lore.kernel.org/all/2025101516-handbook-hyphen-62ec@gregkh

Quoted 38 lines · Aneesh Kumar K.V

Quoted 12 lines · Greg KH

Quoted 11 lines · Suzuki K Poulose

Hi Aneesh

Quoted 4 lines · 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.

There are a few changes squashed in to this patch. Please could we split the patch in the following order ?

Quoted 9 lines

Quoted 1 line

1. Add platform device for arm-smccc

Do not make any more "fake" platform devices please.

Quoted 2 lines

2. Move TRNG to Auxilliary Device - (Even though it is a later patch, move it before the RSI changes)

No, move it to the faux api please.

Maybe I was not complete in my previous reply. I did not want to repeat the entire thread, so I quoted the lore link for more details.

1. We have platform firmware-provided SMCCC interfaces. Based on the support/availability of these function IDs, we want to load multiple drivers.
2. This patch series adds a platform device to represent the firmware-provided SMCCC resource.
3. Different SMCCC ranges are now represented as auxiliary devices.
4. Different subsystems, such as TSM, can autoload their backend drivers based on the availability of these SMCCC ranges, which are now represented as auxiliary devices.

Quoted 2 lines

You had agreed to all of this in the previous discussion here:
https://lore.kernel.org/all/2025101516-handbook-hyphen-62ec@gregkh

Then why did someone say "this is a fake platform device with no actual resources"? That's what I was triggering off of.

Again, if you have actual platform resources, GREAT, use a platform device and aux. If you do not, then do NOT use a platform device.

totally confused,

greg k-h

Quoted 45 lines · Greg KH

Quoted 38 lines · Aneesh Kumar K.V

Quoted 12 lines · Greg KH

Quoted 11 lines · Suzuki K Poulose

Hi Aneesh

Quoted 4 lines · 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.

There are a few changes squashed in to this patch. Please could we split the patch in the following order ?

Quoted 9 lines

Quoted 1 line

1. Add platform device for arm-smccc

Do not make any more "fake" platform devices please.

Quoted 2 lines

2. Move TRNG to Auxilliary Device - (Even though it is a later patch, move it before the RSI changes)

No, move it to the faux api please.

Maybe I was not complete in my previous reply. I did not want to repeat the entire thread, so I quoted the lore link for more details.

1. We have platform firmware-provided SMCCC interfaces. Based on the support/availability of these function IDs, we want to load multiple drivers.
2. This patch series adds a platform device to represent the firmware-provided SMCCC resource.
3. Different SMCCC ranges are now represented as auxiliary devices.
4. Different subsystems, such as TSM, can autoload their backend drivers based on the availability of these SMCCC ranges, which are now represented as auxiliary devices.

Quoted 2 lines

You had agreed to all of this in the previous discussion here:
https://lore.kernel.org/all/2025101516-handbook-hyphen-62ec@gregkh

Then why did someone say "this is a fake platform device with no actual resources"? That's what I was triggering off of.

Quoted 6 lines

Again, if you have actual platform resources, GREAT, use a platform device and aux. If you do not, then do NOT use a platform device.

totally confused,

greg k-h

I have now rewritten the cover letter as below. Let me know if this helps.

Switch Arm SMCCC firmware services to auxiliary devices

As discussed here:
https://lore.kernel.org/all/[email protected]

The earlier CCA guest support used an arm-cca-dev platform device as a pure software anchor for the TSM class device. That platform device did not correspond to a DT/ACPI described device, MMIO range, interrupt, or other platform resource; it existed only to make the CCA guest driver bind and to place the resulting TSM device in the driver model. The same pattern also exists for smccc_trng. Creating separate platform devices for such SMCCC-discovered features is misleading, because those features are not independent platform devices.

This series changes the model so that there is a single arm-smccc platform device representing the SMCCC firmware interface itself. The firmware interface, including its discoverable SMCCC function space, is the
resource: after PSCI/SMCCC conduit discovery, the kernel can query SMCCC function IDs and determine whether optional firmware services are present. Services such as SMCCC TRNG and Realm Services Interface (RSI) are therefore represented as children of the arm-smccc device, and are created only when the required SMCCC function IDs and ABI checks succeed.

The child devices use the auxiliary bus deliberately: they are intended to bind independent feature drivers, not just to provide a driverless object for sysfs or other class-device anchoring. They are firmware-provided functions of the parent SMCCC interface that are consumed by separate kernel drivers in different subsystems, such as hwrng and virt/coco/TSM. Those drivers need normal driver-core matching, probe/remove lifetime, and module autoloading based on the discovered firmware feature. The auxiliary bus provides a MODALIAS and id-table based binding model for that case, while keeping the feature drivers off the platform bus. A faux device was considered, but not used because it is suited for simple software objects that do not need independent bus/driver binding. The faux bus has no feature-driver id-table or MODALIAS matching, so it would not preserve the module-autoload flow that the current platform-device based users rely on.

In other words, the parent arm-smccc device represents the firmware resource exposed through the SMCCC conduit, and each auxiliary child represents one discovered firmware service of that parent. This removes the unnecessary per-feature platform devices while retaining automatic loading and independent subsystem drivers for the SMCCC services.

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 Arm CCA, the RSI auxiliary device continues to provide the device anchor used by the CCA guest TSM provider.

For the CCA platform, the resulting device hierarchy appears as follows. Note that the auxiliary device is 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
$

The series also replaces the old arm-cca-dev userspace-visible dummy device with /sys/firmware/cca/realm_guest for detecting whether the kernel is running in a Realm. This keeps the guest-state ABI under /sys/firmware and separates it from the internal driver-binding device used by the CCA guest TSM provider.

-aneesh

drivers/firmware/smccc/rmm.h new file +2 -0

new file mode 100644
index 000000000000..a47a650d4f51
@@ -0,0 +1,17 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+#ifndef _SMCCC_RMM_H

As discussed here:
https://lore.kernel.org/all/[email protected]

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.

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

As discussed here:
https://lore.kernel.org/all/[email protected]

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.

Why an aux device? If this has no platform resources, please use the faux bus support instead, that is what it is there for. aux devices are used when you are sharing a real resource among different "child" drivers, and need some way to coordinate that sharing. If you have no resources, there's nothing to share, so no need for the complexity that aux gives you, just use faux instead.

Quoted 10 lines · Greg KH

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

As discussed here:
https://lore.kernel.org/all/[email protected]

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.

Quoted 7 lines

Why an aux device? If this has no platform resources, please use the faux bus support instead, that is what it is there for. aux devices are used when you are sharing a real resource among different "child" drivers, and need some way to coordinate that sharing. If you have no resources, there's nothing to share, so no need for the complexity that aux gives you, just use faux instead.

We did discuss between faux an auxiliary devices early here
https://lore.kernel.org/all/[email protected]

To summarize auxiliary device was choosen so that we can do module autoloading.