Switch Arm SMCCC firmware services to an SMCCC bus

Reviewed-by Sudeep Holla <[email protected]>

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

---
 drivers/firmware/smccc/Makefile     |   2 +-
 drivers/firmware/smccc/bus.c        | 151 ++++++++++++++++++++++++++++
 include/linux/arm-smccc-bus.h       |  48 +++++++++
 include/linux/device-id/arm_smccc.h |  19 ++++
 include/linux/mod_devicetable.h     |   1 +
 scripts/mod/devicetable-offsets.c   |   3 +
 scripts/mod/file2alias.c            |   8 ++
 7 files changed, 231 insertions(+), 1 deletion(-)
 create mode 100644 drivers/firmware/smccc/bus.c
 create mode 100644 include/linux/arm-smccc-bus.h
 create mode 100644 include/linux/device-id/arm_smccc.h

drivers/firmware/smccc/Makefile +1 -1

index 40d19144a860..68bbff1407b8 100644
@@ -1,4 +1,4 @@
 # SPDX-License-Identifier: GPL-2.0
 #
-obj-$(CONFIG_HAVE_ARM_SMCCC_DISCOVERY)	+= smccc.o kvm_guest.o
+obj-$(CONFIG_HAVE_ARM_SMCCC_DISCOVERY)	+= bus.o smccc.o kvm_guest.o
 obj-$(CONFIG_ARM_SMCCC_SOC_ID)	+= soc_id.o

drivers/firmware/smccc/bus.c new file +151 -0

151 lines not on this page · raw message

include/linux/arm-smccc-bus.h new file +48 -0

48 lines not on this page · raw message

include/linux/device-id/arm_smccc.h new file +19 -0

new file mode 100644
index 000000000000..a8579832fc1c
@@ -0,0 +1,19 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+#ifndef __LINUX_DEVICE_ID_ARM_SMCCC_H
+#define __LINUX_DEVICE_ID_ARM_SMCCC_H
+
+#ifdef __KERNEL__
+#include <linux/types.h>
+#endif
+
+#define ARM_SMCCC_MODULE_PREFIX "arm_smccc:"
+
+/**
+ * struct arm_smccc_device_id - Arm SMCCC bus device identifier
+ * @func_id: SMCCC function identifier
+ */
+struct arm_smccc_device_id {
+	__u32 func_id;
+};
+
+#endif /* __LINUX_DEVICE_ID_ARM_SMCCC_H */

include/linux/mod_devicetable.h +1 -0

index a397213bedac..318c4b5c3451 100644
@@ -16,6 +16,7 @@
 #include "device-id/amba.h"
 #include "device-id/ap.h"
 #include "device-id/apr.h"
+#include "device-id/arm_smccc.h"
 #include "device-id/auxiliary.h"
 #include "device-id/bcma.h"
 #include "device-id/ccw.h"

scripts/mod/devicetable-offsets.c +3 -0

index b4178c42d08f..1492e9fdc7cb 100644
@@ -254,6 +254,9 @@ int main(void)
 	DEVID(auxiliary_device_id);
 	DEVID_FIELD(auxiliary_device_id, name);
 
+	DEVID(arm_smccc_device_id);
+	DEVID_FIELD(arm_smccc_device_id, func_id);
+
 	DEVID(ssam_device_id);
 	DEVID_FIELD(ssam_device_id, match_flags);
 	DEVID_FIELD(ssam_device_id, domain);

scripts/mod/file2alias.c +8 -0

index 8d36c74dec2d..980d7da456bb 100644
@@ -1349,6 +1349,13 @@ static void do_auxiliary_entry(struct module *mod, void *symval)
 	module_alias_printf(mod, false, AUXILIARY_MODULE_PREFIX "%s", *name);
 }
 
+static void do_arm_smccc_entry(struct module *mod, void *symval)
+{
+	DEF_FIELD(symval, arm_smccc_device_id, func_id);
+
+	module_alias_printf(mod, false, ARM_SMCCC_MODULE_PREFIX "f%08X", func_id);
+}
+
 /*
  * Looks like: ssam:dNcNtNiNfN
  *

@@ -1519,6 +1526,7 @@ static const struct devtable devtable[] = {
 	{"mhi", SIZE_mhi_device_id, do_mhi_entry},
 	{"mhi_ep", SIZE_mhi_device_id, do_mhi_ep_entry},
 	{"auxiliary", SIZE_auxiliary_device_id, do_auxiliary_entry},
+	{"arm_smccc", SIZE_arm_smccc_device_id, do_arm_smccc_entry},
 	{"ssam", SIZE_ssam_device_id, do_ssam_entry},
 	{"dfl", SIZE_dfl_device_id, do_dfl_entry},
 	{"ishtp", SIZE_ishtp_device_id, do_ishtp_entry},

Signature · 1 line

2.43.0

Catalin Marinas

maintainer Reviewed-by on v11 1/7

2026-09-14 13:04 UTC #2 lore raw

Re: [PATCH v11 1/7] firmware: smccc: Add an Arm SMCCC bus

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

SMCCC-discovered firmware services are currently represented by separate platform devices, such as smccc_trng and arm-cca-dev. Those devices do not represent independent DT/ACPI-described platform resources; they are features of the SMCCC firmware interface.
Add an Arm SMCCC bus for services discovered through the SMCCC firmware interface. The bus provides SMCCC device and driver registration helpers, name-based matching, modalias generation, and a sysfs modalias attribute so

Nit: "name-based matching" is no longer true. The latest series uses function ID.

Jonathan Cameron

Reviewed-by on v11 1/7

2026-09-14 20:32 UTC #3 lore raw

Re: [PATCH v11 1/7] firmware: smccc: Add an Arm SMCCC bus

Quoted 11 lines · On Mon, 14 Sep 2026 11:35:05 +0530 "Aneesh Kumar K.V (Arm)"…

SMCCC-discovered firmware services are currently represented by separate platform devices, such as smccc_trng and arm-cca-dev. Those devices do not represent independent DT/ACPI-described platform resources; they are features of the SMCCC firmware interface.
Add an Arm SMCCC bus for services discovered through the SMCCC firmware interface. The bus provides SMCCC device and driver registration helpers, name-based matching, modalias generation, and a sysfs modalias attribute so SMCCC service drivers can bind to discovered firmware services and autoload as modules.

Quoted 4 lines

Follow-up changes can then register SMCCC firmware services as arm-smccc devices instead of creating independent per-feature platform devices.
Based on arm_ffa code

That code has the same issue as below and for bonus points doesn't check if dev_set_name() succeeds or not.

Quoted 4 lines

Reviewed-by Jason Gunthorpe <[email protected]>
Reviewed-by Sudeep Holla <[email protected]>
Signed-off-by Aneesh Kumar K.V (Arm) <[email protected]>

On tiny bit of fragility inline that I'd suggestion avoiding now rather than later. Down to dev_set_name() doing allocations in some cases under the hood that are tricky to tidy up with device_register() being used.

With that tidied up

Quoted 14 lines

drivers/firmware/smccc/bus.c new file +8 -0

new file mode 100644
index 000000000000..caba1a03c997
 
+
+struct arm_smccc_device *arm_smccc_device_register(const char *name, u32 func_id)
+{
+	int ret;
+	struct arm_smccc_device *smccc_dev;
+
+	if (!name)
+		return ERR_PTR(-EINVAL);

drivers/firmware/smccc/bus.c line 122

Quoted 10 lines

drivers/firmware/smccc/bus.c new file +10 -0

+
+	smccc_dev = kzalloc_obj(*smccc_dev);
+	if (!smccc_dev)
+		return ERR_PTR(-ENOMEM);
+
+	smccc_dev->func_id = func_id;
+	smccc_dev->dev.bus = &arm_smccc_bus_type;
+	smccc_dev->dev.release = arm_smccc_release_device;
+
+	ret = dev_set_name(&smccc_dev->dev, "%s", name);

Does protecting the string defeat the nice underlying const handling? e.g.

	ret = dev_set_name(&smccc_dev->dev, name);

might be better. Not particular important - I only noticed because you'd often see this between an device_initialize() and device_add() and then we'd be relying on the device_put() to clean it up.

So as this stands this is fragile as any error paths that later get added...

drivers/firmware/smccc/bus.c line 127

Quoted 5 lines

drivers/firmware/smccc/bus.c new file +5 -0
+	if (ret) {
+		kfree(smccc_dev);
+		return ERR_PTR(ret);
+	}
+

here can't free the name allocation.

So I'd just switch this to a split device setup - something like...

	smccc_dev = kzalloc_obj(*smccc_dev);
	if (!smccc_dev)
		return ERR_PTR(-ENOMEM);

	smccc_dev->func_id = func_id;
	smccc_dev->dev.bus = &arm_smccc_bus_type;
	smccc_dev->dev.release = arm_smccc_release_device;

	device_initialize(&smccc_dev->dev);
	ret = dev_set_name(&smccc_dev->dev, "%s", name);

//up to you whether you care about const string handling.

	if (ret) {
		put_device(&smcc_dev->dev);
		return ret;
	}

	ret = device_register(&smccc_dev->dev);
	if (ret) {
		put_device(&smccc_dev->dev);
		return ERR_PTR(ret);
	}

	return smccc_dev;

Quoted 24 lines

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

+	ret = device_register(&smccc_dev->dev);
+	if (ret) {
+		put_device(&smccc_dev->dev);
+		return ERR_PTR(ret);
+	}
+
+	return smccc_dev;
+}
+EXPORT_SYMBOL_GPL(arm_smccc_device_register);
+
+void arm_smccc_device_unregister(struct arm_smccc_device *smccc_dev)
+{
+	if (!smccc_dev)
+		return;
+
+	device_unregister(&smccc_dev->dev);
+}
+EXPORT_SYMBOL_GPL(arm_smccc_device_unregister);
+
+static int __init arm_smccc_bus_init(void)
+{
+	return bus_register(&arm_smccc_bus_type);
+}
+subsys_initcall(arm_smccc_bus_init);

Jason Gunthorpe

2026-09-14 22:28 UTC #4 lore raw

Re: [PATCH v11 1/7] firmware: smccc: Add an Arm SMCCC bus

Quoted 20 lines · Jonathan Cameron

Quoted 7 lines

drivers/firmware/smccc/bus.c new file +7 -0

+struct arm_smccc_device *arm_smccc_device_register(const char *name, u32 func_id)
+{
+	int ret;
+	struct arm_smccc_device *smccc_dev;
+
+	if (!name)
+		return ERR_PTR(-EINVAL);

drivers/firmware/smccc/bus.c line 122

Quoted 10 lines

drivers/firmware/smccc/bus.c new file +10 -0

+
+	smccc_dev = kzalloc_obj(*smccc_dev);
+	if (!smccc_dev)
+		return ERR_PTR(-ENOMEM);
+
+	smccc_dev->func_id = func_id;
+	smccc_dev->dev.bus = &arm_smccc_bus_type;
+	smccc_dev->dev.release = arm_smccc_release_device;
+
+	ret = dev_set_name(&smccc_dev->dev, "%s", name);

Does protecting the string defeat the nice underlying const handling? e.g.

Quoted 2 lines

	ret = dev_set_name(&smccc_dev->dev, name);

might be better.

Pedenatically the %s is better as it doesn't restrict name to not include % characters.

Quoted 5 lines

you'd often see this between an device_initialize() and device_add() and then we'd be relying on the device_put() to clean it up.
So as this stands this is fragile as any error paths that later get added...

Yes, but as written it is OK, and this is a common pattern in the kernel. I agree it is fragile tricky..

Still it isn't an urgent reason to change it around, but the best pattern is to put the allocate, dev.release=, and device_initialize() in one 'alloc' function. Then the other function calls it and always unwinds with put_device. Use device_add().

This avoids mixing the different kfree/put_device error unwind regimes into the same function..

Quoted 7 lines

drivers/firmware/smccc/bus.c line 127
Quoted 5 lines
drivers/firmware/smccc/bus.c new file +5 -0
+	if (ret) {
+		kfree(smccc_dev);
+		return ERR_PTR(ret);
+	}
+
here can't free the name allocation.

The funky reasoning is since name failed there is no name allocation to free

And then device_register() failure must always be done with put_device, so it will capture the name. As long as name/register are a pair with nothing between it is "fine".

Jason

Aneesh Kumar K.V

author

2026-09-15 09:22 UTC #5 lore raw

Re: [PATCH v11 1/7] firmware: smccc: Add an Arm SMCCC bus

Quoted 36 lines · Jason Gunthorpe

Quoted 20 lines · Jonathan Cameron
Quoted 7 lines
drivers/firmware/smccc/bus.c new file +7 -0
+struct arm_smccc_device *arm_smccc_device_register(const char *name, u32 func_id)
+{
+	int ret;
+	struct arm_smccc_device *smccc_dev;
+
+	if (!name)
+		return ERR_PTR(-EINVAL);
drivers/firmware/smccc/bus.c line 122
Quoted 10 lines
drivers/firmware/smccc/bus.c new file +10 -0
+
+	smccc_dev = kzalloc_obj(*smccc_dev);
+	if (!smccc_dev)
+		return ERR_PTR(-ENOMEM);
+
+	smccc_dev->func_id = func_id;
+	smccc_dev->dev.bus = &arm_smccc_bus_type;
+	smccc_dev->dev.release = arm_smccc_release_device;
+
+	ret = dev_set_name(&smccc_dev->dev, "%s", name);
Does protecting the string defeat the nice underlying const handling? e.g.
Quoted 2 lines
	ret = dev_set_name(&smccc_dev->dev, name);
might be better.
Pedenatically the %s is better as it doesn't restrict name to not include % characters.
Quoted 5 lines
you'd often see this between an device_initialize() and device_add() and then we'd be relying on the device_put() to clean it up.
So as this stands this is fragile as any error paths that later get added...
Yes, but as written it is OK, and this is a common pattern in the kernel. I agree it is fragile tricky..

Quoted 8 lines

Still it isn't an urgent reason to change it around, but the best pattern is to put the allocate, dev.release=, and device_initialize() in one 'alloc' function. Then the other function calls it and always unwinds with put_device. Use device_add().
This avoids mixing the different kfree/put_device error unwind regimes into the same function..

Something like

+static struct arm_smccc_device *arm_smccc_device_alloc(u32 func_id) +{
+ struct arm_smccc_device *smccc_dev;
+
+ smccc_dev = kzalloc_obj(*smccc_dev);
+ if (!smccc_dev)
+ return NULL;
+
+ smccc_dev->func_id = func_id;
+ smccc_dev->dev.bus = &arm_smccc_bus_type;
+ smccc_dev->dev.release = arm_smccc_release_device;
+ device_initialize(&smccc_dev->dev);
+
+ return smccc_dev;
+}
+
struct arm_smccc_device *arm_smccc_device_register(const char *name, u32 func_id) {
+ struct arm_smccc_device *smccc_dev;
int ret;
- struct arm_smccc_device *smccc_dev;

if (!name)
return ERR_PTR(-EINVAL);

- smccc_dev = kzalloc_obj(*smccc_dev);
+ smccc_dev = arm_smccc_device_alloc(func_id);
if (!smccc_dev)
return ERR_PTR(-ENOMEM);

- smccc_dev->func_id = func_id;
- smccc_dev->dev.bus = &arm_smccc_bus_type;
- smccc_dev->dev.release = arm_smccc_release_device;
-
ret = dev_set_name(&smccc_dev->dev, "%s", name);
- if (ret) {
- kfree(smccc_dev);
- return ERR_PTR(ret);
- }
+ if (ret)
+ goto err_put_device;

- ret = device_register(&smccc_dev->dev);
- if (ret) {
- put_device(&smccc_dev->dev);
- return ERR_PTR(ret);
- }
+ ret = device_add(&smccc_dev->dev);
+ if (ret)
+ goto err_put_device;

return smccc_dev;
+
+err_put_device:
+ put_device(&smccc_dev->dev);
+ return ERR_PTR(ret);
}
EXPORT_SYMBOL_GPL(arm_smccc_device_register);

Jason Gunthorpe

2026-09-15 11:46 UTC #6 lore raw

Re: [PATCH v11 1/7] firmware: smccc: Add an Arm SMCCC bus

Quoted 8 lines · Aneesh Kumar K.V

Quoted 8 lines
Yes, but as written it is OK, and this is a common pattern in the kernel. I agree it is fragile tricky..
Still it isn't an urgent reason to change it around, but the best pattern is to put the allocate, dev.release=, and device_initialize() in one 'alloc' function. Then the other function calls it and always unwinds with put_device. Use device_add().

Quoted 5 lines

Quoted 3 lines
This avoids mixing the different kfree/put_device error unwind regimes into the same function..
Something like

Yeah, this is the safest way I know to use these interfaces

Jason

Jonathan Cameron

2026-09-23 16:43 UTC #7 lore raw

Re: [PATCH v11 1/7] firmware: smccc: Add an Arm SMCCC bus

Quoted 10 lines · On Tue, 15 Sep 2026 08:46:01 -0300 Jason Gunthorpe <[email protected]> wrote:

Quoted 8 lines · Aneesh Kumar K.V
Quoted 8 lines
Yes, but as written it is OK, and this is a common pattern in the kernel. I agree it is fragile tricky..
Still it isn't an urgent reason to change it around, but the best pattern is to put the allocate, dev.release=, and device_initialize() in one 'alloc' function. Then the other function calls it and always unwinds with put_device. Use device_add().

Quoted 8 lines

Quoted 5 lines
Quoted 3 lines
This avoids mixing the different kfree/put_device error unwind regimes into the same function..
Something like
Yeah, this is the safest way I know to use these interfaces

Agreed.

Quoted 1 line

Jason

Aneesh Kumar K.V (Arm)

author

2026-09-14 06:05 UTC #8 lore raw

PATCH v11 2/7 firmware: hwrng: arm_smccc_trng: Register as an SMCCC device

The SMCCC TRNG interface is a firmware-provided SMCCC service rather than a standalone platform device. Now that the SMCCC core has an SMCCC bus, create an arm-smccc-trng device for the discovered TRNG service and convert the hwrng driver to an SMCCC driver.

The SMCCC id table preserves module autoloading for systems where the TRNG driver is built as a module.

The sysfs device path changes from the old smccc_trng platform-device path to an arm-smccc device path. No known userspace dependency on the old path was found; a Debian Code Search lookup for the existing platform-device name/path did not find any users.

Tested-by Andre Przywara <[email protected]>

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

---
 arch/arm/include/asm/archrandom.h       |  2 +-
 arch/arm64/include/asm/archrandom.h     |  2 +-
 drivers/char/hw_random/arm_smccc_trng.c | 32 ++++++++-----
 drivers/firmware/smccc/smccc.c          | 62 +++++++++++++++++++++----
 4 files changed, 76 insertions(+), 22 deletions(-)

arch/arm/include/asm/archrandom.h +1 -1

index cc4714eb1a75..ee39a03ddf8a 100644
@@ -2,7 +2,7 @@
 #ifndef _ASM_ARCHRANDOM_H
 #define _ASM_ARCHRANDOM_H
 
-static inline bool __init smccc_probe_trng(void)
+static inline bool smccc_probe_trng(void)
 {
 	return false;
 }

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

index 8babfbe31f95..7605dd81bd1e 100644
@@ -12,7 +12,7 @@
 
 extern bool smccc_trng_available;
 
-static inline bool __init smccc_probe_trng(void)
+static inline bool smccc_probe_trng(void)
 {
 	struct arm_smccc_res res;

drivers/char/hw_random/arm_smccc_trng.c +21 ~~-11~~

index dcb8e7f37f25..01c1a30cbab8 100644
@@ -16,8 +16,10 @@
 #include <linux/device.h>
 #include <linux/hw_random.h>
 #include <linux/module.h>
-#include <linux/platform_device.h>
 #include <linux/arm-smccc.h>
+#include <linux/arm-smccc-bus.h>
+
+#include <asm/archrandom.h>
 
 #ifdef CONFIG_ARM64
 #define ARM_SMCCC_TRNG_RND	ARM_SMCCC_TRNG_RND64

@@ -94,29 +96,37 @@ static int smccc_trng_read(struct hwrng *rng, void *data, size_t max, bool wait)
 	return copied;
 }
 
-static int smccc_trng_probe(struct platform_device *pdev)
+static int smccc_trng_probe(struct arm_smccc_device *sdev)
 {
 	struct hwrng *trng;
 
-	trng = devm_kzalloc(&pdev->dev, sizeof(*trng), GFP_KERNEL);
+	/* validate the minimum version requirement */
+	if (!smccc_probe_trng())
+		return -ENODEV;
+
+	trng = devm_kzalloc(&sdev->dev, sizeof(*trng), GFP_KERNEL);
 	if (!trng)
 		return -ENOMEM;
 
 	trng->name = "smccc_trng";
 	trng->read = smccc_trng_read;
 
-	return devm_hwrng_register(&pdev->dev, trng);
+	return devm_hwrng_register(&sdev->dev, trng);
 }
 
-static struct platform_driver smccc_trng_driver = {
-	.driver = {
-		.name		= "smccc_trng",
-	},
-	.probe		= smccc_trng_probe,
+static const struct arm_smccc_device_id smccc_trng_id_table[] = {
+	{ .func_id = ARM_SMCCC_TRNG_VERSION },
+	{}
+};
+MODULE_DEVICE_TABLE(arm_smccc, smccc_trng_id_table);
+
+static struct arm_smccc_driver smccc_trng_driver = {
+	.name	  = KBUILD_MODNAME,
+	.probe	  = smccc_trng_probe,
+	.id_table = smccc_trng_id_table,
 };
-module_platform_driver(smccc_trng_driver);
+module_arm_smccc_driver(smccc_trng_driver);
 
-MODULE_ALIAS("platform:smccc_trng");
 MODULE_AUTHOR("Andre Przywara");
 MODULE_DESCRIPTION("Arm SMCCC TRNG firmware interface support");
 MODULE_LICENSE("GPL");

drivers/firmware/smccc/smccc.c +53 -9

76 lines not on this page · raw message

Signature · 1 line

2.43.0

Catalin Marinas

maintainer Reviewed-by on v11 2/7

2026-09-14 13:14 UTC #9 lore raw

Re: [PATCH v11 2/7] firmware: hwrng: arm_smccc_trng: Register as an SMCCC device

You still haven't copied Olivia and Herbert for the hw_random bits.

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

The SMCCC TRNG interface is a firmware-provided SMCCC service rather than a standalone platform device. Now that the SMCCC core has an SMCCC bus, create an arm-smccc-trng device for the discovered TRNG service and convert the hwrng driver to an SMCCC driver.
The SMCCC id table preserves module autoloading for systems where the TRNG driver is built as a module.

Quoted 8 lines

The sysfs device path changes from the old smccc_trng platform-device path to an arm-smccc device path. No known userspace dependency on the old path was found; a Debian Code Search lookup for the existing platform-device name/path did not find any users.
Reviewed-by Jason Gunthorpe <[email protected]>
Tested-by Andre Przywara <[email protected]>
Signed-off-by Aneesh Kumar K.V (Arm) <[email protected]>

Quoted 181 lines

---
 arch/arm/include/asm/archrandom.h       |  2 +-
 arch/arm64/include/asm/archrandom.h     |  2 +-
 drivers/char/hw_random/arm_smccc_trng.c | 32 ++++++++-----
 drivers/firmware/smccc/smccc.c          | 62 +++++++++++++++++++++----
 4 files changed, 76 insertions(+), 22 deletions(-)

arch/arm/include/asm/archrandom.h +1 -1

index cc4714eb1a75..ee39a03ddf8a 100644
@@ -2,7 +2,7 @@
 #ifndef _ASM_ARCHRANDOM_H
 #define _ASM_ARCHRANDOM_H
 
-static inline bool __init smccc_probe_trng(void)
+static inline bool smccc_probe_trng(void)
 {
 	return false;
 }

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

index 8babfbe31f95..7605dd81bd1e 100644
@@ -12,7 +12,7 @@
 
 extern bool smccc_trng_available;
 
-static inline bool __init smccc_probe_trng(void)
+static inline bool smccc_probe_trng(void)
 {
 	struct arm_smccc_res res;

drivers/char/hw_random/arm_smccc_trng.c +21 ~~-11~~

index dcb8e7f37f25..01c1a30cbab8 100644
@@ -16,8 +16,10 @@
 #include <linux/device.h>
 #include <linux/hw_random.h>
 #include <linux/module.h>
-#include <linux/platform_device.h>
 #include <linux/arm-smccc.h>
+#include <linux/arm-smccc-bus.h>
+
+#include <asm/archrandom.h>
 
 #ifdef CONFIG_ARM64
 #define ARM_SMCCC_TRNG_RND	ARM_SMCCC_TRNG_RND64

@@ -94,29 +96,37 @@ static int smccc_trng_read(struct hwrng *rng, void *data, size_t max, bool wait)
 	return copied;
 }
 
-static int smccc_trng_probe(struct platform_device *pdev)
+static int smccc_trng_probe(struct arm_smccc_device *sdev)
 {
 	struct hwrng *trng;
 
-	trng = devm_kzalloc(&pdev->dev, sizeof(*trng), GFP_KERNEL);
+	/* validate the minimum version requirement */
+	if (!smccc_probe_trng())
+		return -ENODEV;
+
+	trng = devm_kzalloc(&sdev->dev, sizeof(*trng), GFP_KERNEL);
 	if (!trng)
 		return -ENOMEM;
 
 	trng->name = "smccc_trng";
 	trng->read = smccc_trng_read;
 
-	return devm_hwrng_register(&pdev->dev, trng);
+	return devm_hwrng_register(&sdev->dev, trng);
 }
 
-static struct platform_driver smccc_trng_driver = {
-	.driver = {
-		.name		= "smccc_trng",
-	},
-	.probe		= smccc_trng_probe,
+static const struct arm_smccc_device_id smccc_trng_id_table[] = {
+	{ .func_id = ARM_SMCCC_TRNG_VERSION },
+	{}
+};
+MODULE_DEVICE_TABLE(arm_smccc, smccc_trng_id_table);
+
+static struct arm_smccc_driver smccc_trng_driver = {
+	.name	  = KBUILD_MODNAME,
+	.probe	  = smccc_trng_probe,
+	.id_table = smccc_trng_id_table,
 };
-module_platform_driver(smccc_trng_driver);
+module_arm_smccc_driver(smccc_trng_driver);
 
-MODULE_ALIAS("platform:smccc_trng");
 MODULE_AUTHOR("Andre Przywara");
 MODULE_DESCRIPTION("Arm SMCCC TRNG firmware interface support");
 MODULE_LICENSE("GPL");

drivers/firmware/smccc/smccc.c +53 -9

index bdee057db2fd..756c79204e44 100644
@@ -9,7 +9,8 @@
 #include <linux/init.h>
 #include <linux/arm-smccc.h>
 #include <linux/kernel.h>
-#include <linux/platform_device.h>
+#include <linux/arm-smccc-bus.h>
+
 #include <asm/archrandom.h>
 
 static u32 smccc_version = ARM_SMCCC_VERSION_1_0;

@@ -81,16 +82,59 @@ bool arm_smccc_hypervisor_has_uuid(const uuid_t *hyp_uuid)
 }
 EXPORT_SYMBOL_GPL(arm_smccc_hypervisor_has_uuid);
 
+struct smccc_device_info {
+	u32 func_id;
+	bool requires_smc;
+	const char *device_name;
+};
+
+static const struct smccc_device_info smccc_devices[] __initconst = {
+	{
+		.func_id        = ARM_SMCCC_TRNG_VERSION,
+		.requires_smc   = false,
+		.device_name    = "arm-smccc-trng",
+	},
+};
+
+static bool __init smccc_probe_smccc_device(const struct smccc_device_info *smccc_dev)
+{
+	int ret;
+	struct arm_smccc_res res = {};
+
+	if (smccc_conduit == SMCCC_CONDUIT_NONE)
+		return false;
+
+	if (smccc_dev->requires_smc && smccc_conduit != SMCCC_CONDUIT_SMC)
+		return false;
+
+	if (IS_ENABLED(CONFIG_ARM) && ARM_SMCCC_IS_64(smccc_dev->func_id))
+		return false;
+
+	arm_smccc_1_1_invoke(smccc_dev->func_id,
+			     0, 0, 0, 0, 0, 0, 0, &res);
+	ret = res.a0;
+
+	if (ret == SMCCC_RET_NOT_SUPPORTED)
+		return false;
+
+	return true;
+}
+
 static int __init smccc_devices_init(void)
 {
-	struct platform_device *pdev;
-
-	if (smccc_trng_available) {
-		pdev = platform_device_register_simple("smccc_trng", -1,
-						       NULL, 0);
-		if (IS_ERR(pdev))
-			pr_err("smccc_trng: could not register device: %ld\n",
-			       PTR_ERR(pdev));
+	struct arm_smccc_device *sdev;
+	const struct smccc_device_info *smccc_dev;
+
+	for (int i = 0; i < ARRAY_SIZE(smccc_devices); i++) {
+		smccc_dev = &smccc_devices[i];
+
+		if (!smccc_probe_smccc_device(smccc_dev))
+			continue;
+
+		sdev = arm_smccc_device_register(smccc_dev->device_name, smccc_dev->func_id);
+		if (IS_ERR(sdev))
+			pr_err("%s: could not register device: %ld\n",
+			       smccc_dev->device_name, PTR_ERR(sdev));
 	}
 
 	return 0;

Signature · 1 line

2.43.0

Jonathan Cameron

Reviewed-by on v11 2/7

2026-09-14 20:39 UTC #10 lore raw

Re: [PATCH v11 2/7] firmware: hwrng: arm_smccc_trng: Register as an SMCCC device

Quoted 8 lines · On Mon, 14 Sep 2026 11:35:06 +0530 "Aneesh Kumar K.V (Arm)"…

The SMCCC TRNG interface is a firmware-provided SMCCC service rather than a standalone platform device. Now that the SMCCC core has an SMCCC bus, create an arm-smccc-trng device for the discovered TRNG service and convert the hwrng driver to an SMCCC driver.
The SMCCC id table preserves module autoloading for systems where the TRNG driver is built as a module.

Quoted 8 lines

The sysfs device path changes from the old smccc_trng platform-device path to an arm-smccc device path. No known userspace dependency on the old path was found; a Debian Code Search lookup for the existing platform-device name/path did not find any users.
Reviewed-by Jason Gunthorpe <[email protected]>
Tested-by Andre Przywara <[email protected]>
Signed-off-by Aneesh Kumar K.V (Arm) <[email protected]>

Trivial stuff inline - nothing that needs changes

drivers/firmware/smccc/smccc.c bool arm_smccc_hypervisor_has_uuid(const uuid_t *hyp_uuid) · line 91

Quoted 7 lines

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

index bdee057db2fd..756c79204e44 100644
 
+
+static const struct smccc_device_info smccc_devices[] __initconst = {

Ah. With __init_const I suspect the string constant stuff I mentioned in previous patch won't work anyway.

Quoted 13 lines

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

+	{
+		.func_id        = ARM_SMCCC_TRNG_VERSION,
+		.requires_smc   = false,
+		.device_name    = "arm-smccc-trng",
+	},
+};
+
+static bool __init smccc_probe_smccc_device(const struct smccc_device_info *smccc_dev)
+{
+	int ret;
+	struct arm_smccc_res res = {};
+
+	if (smccc_conduit == SMCCC_CONDUIT_NONE)

drivers/firmware/smccc/smccc.c bool arm_smccc_hypervisor_has_uuid(const uuid_t *hyp_uuid) · line 114

Quoted 10 lines

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

+		return false;
+
+	if (smccc_dev->requires_smc && smccc_conduit != SMCCC_CONDUIT_SMC)
+		return false;
+
+	if (IS_ENABLED(CONFIG_ARM) && ARM_SMCCC_IS_64(smccc_dev->func_id))
+		return false;
+
+	arm_smccc_1_1_invoke(smccc_dev->func_id,
+			     0, 0, 0, 0, 0, 0, 0, &res);

Fits on one line. Up to you though as maybe it's cleaner to have all the numbers start on a new row.

Quoted 21 lines

drivers/firmware/smccc/smccc.c +11 -8

+	ret = res.a0;
+
+	if (ret == SMCCC_RET_NOT_SUPPORTED)
+		return false;
+
+	return true;
+}
+
 static int __init smccc_devices_init(void)
 {
-	struct platform_device *pdev;
-
-	if (smccc_trng_available) {
-		pdev = platform_device_register_simple("smccc_trng", -1,
-						       NULL, 0);
-		if (IS_ERR(pdev))
-			pr_err("smccc_trng: could not register device: %ld\n",
-			       PTR_ERR(pdev));
+	struct arm_smccc_device *sdev;
+	const struct smccc_device_info *smccc_dev;
+

drivers/firmware/smccc/smccc.c bool arm_smccc_hypervisor_has_uuid(const uuid_t *hyp_uuid) · line 137

Quoted 10 lines

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

+	for (int i = 0; i < ARRAY_SIZE(smccc_devices); i++) {
+		smccc_dev = &smccc_devices[i];
+
+		if (!smccc_probe_smccc_device(smccc_dev))
+			continue;
+
+		sdev = arm_smccc_device_register(smccc_dev->device_name, smccc_dev->func_id);
+		if (IS_ERR(sdev))
+			pr_err("%s: could not register device: %ld\n",
+			       smccc_dev->device_name, PTR_ERR(sdev));

Could be friendly to anyone reading this and use %pe. Up to you.

Quoted 3 lines

drivers/firmware/smccc/smccc.c +0 -0
 	}
 
 	return 0;

Sudeep Holla

maintainer Reviewed-by on v11 2/7

2026-09-24 12:23 UTC #11 lore raw

Re: [PATCH v11 2/7] firmware: hwrng: arm_smccc_trng: Register as an SMCCC device

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

The SMCCC TRNG interface is a firmware-provided SMCCC service rather than a standalone platform device. Now that the SMCCC core has an SMCCC bus, create an arm-smccc-trng device for the discovered TRNG service and convert the hwrng driver to an SMCCC driver.
The SMCCC id table preserves module autoloading for systems where the TRNG driver is built as a module.
The sysfs device path changes from the old smccc_trng platform-device path to an arm-smccc device path. No known userspace dependency on the old path was found; a Debian Code Search lookup for the existing platform-device name/path did not find any users.
Reviewed-by Jason Gunthorpe <[email protected]>
Tested-by Andre Przywara <[email protected]>
Signed-off-by Aneesh Kumar K.V (Arm) <[email protected]>
---

[...]

Quoted 1 line

 drivers/firmware/smccc/smccc.c          | 62 +++++++++++++++++++++----

Reviewed-by Sudeep Holla <[email protected]>

Signature · 2 lines

Regards,
Sudeep

Aneesh Kumar K.V (Arm)

author

2026-09-14 06:05 UTC #12 lore raw

PATCH v11 3/7 firmware: arm_rmm: Move RSI support out of arch/arm64

[1] https://lore.kernel.org/all/agsNO9cc7H-b0H8L@willie-the-truck

The RSI SMCCC function IDs describe a firmware ABI and are not arm64 architecture specific definitions. Follow-up changes need to use them from non-arch code, including drivers/firmware/smccc and the Arm CCA guest driver.

Move the complete Realm Service Interface (RSI) implementation from arch/arm64 to drivers/firmware/arm_rmm. The RSI SMCCC definitions and command helpers are also moved to include/linux so they can be shared by architecture code and firmware or driver code. This also keeps the firmware interface outside architecture code, as requested [1].

Acked-by Suzuki K Poulose <[email protected]>

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

---
 arch/arm64/Kconfig                            |  1 +
 arch/arm64/include/asm/io.h                   |  2 +-
 arch/arm64/include/asm/mem_encrypt.h          |  2 +-
 arch/arm64/include/asm/pgtable-prot.h         |  2 +-
 arch/arm64/include/asm/rsi.h                  | 70 -----------------
 arch/arm64/kernel/Makefile                    |  2 +-
 arch/arm64/kernel/setup.c                     |  2 +-
 arch/arm64/mm/init.c                          |  3 +-
 drivers/firmware/Kconfig                      |  1 +
 drivers/firmware/Makefile                     |  1 +
 drivers/firmware/arm_rmm/Kconfig              | 17 ++++
 drivers/firmware/arm_rmm/Makefile             |  2 +
 .../kernel => drivers/firmware/arm_rmm}/rsi.c |  2 +-
 drivers/virt/coco/arm-cca-guest/Kconfig       |  2 +-
 .../virt/coco/arm-cca-guest/arm-cca-guest.c   |  5 +-
 .../linux/arm-rsi-cmds.h                      | 77 +++++++++++++++++--
 .../linux/arm-smccc-rsi.h                     |  6 +-
 17 files changed, 108 insertions(+), 89 deletions(-)
 delete mode 100644 arch/arm64/include/asm/rsi.h
 create mode 100644 drivers/firmware/arm_rmm/Kconfig
 create mode 100644 drivers/firmware/arm_rmm/Makefile
 rename {arch/arm64/kernel => drivers/firmware/arm_rmm}/rsi.c (99%)
 rename arch/arm64/include/asm/rsi_cmds.h => include/linux/arm-rsi-cmds.h (69%)
 rename arch/arm64/include/asm/rsi_smc.h => include/linux/arm-smccc-rsi.h (98%)

arch/arm64/Kconfig +1 -0

index b5a51b0ef944..ff9565d3ffa5 100644
@@ -38,6 +38,7 @@ config ARM64
 	select ARCH_HAS_MEMBARRIER_SYNC_CORE
 	select ARCH_HAS_MEM_ENCRYPT
 	select ARCH_SUPPORTS_MSEAL_SYSTEM_MAPPINGS
+	select ARCH_SUPPORTS_RMM
 	select ARCH_HAS_NMI_SAFE_THIS_CPU_OPS
 	select ARCH_HAS_NON_OVERLAPPING_ADDRESS_SPACE
 	select ARCH_HAS_NONLEAF_PMD_YOUNG if ARM64_HAFT

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

index 49a7002661a9..1620537f0332 100644
@@ -8,6 +8,7 @@
 #ifndef __ASM_IO_H
 #define __ASM_IO_H
 
+#include <linux/arm-rsi-cmds.h>
 #include <linux/types.h>
 #include <linux/pgtable.h>

@@ -17,7 +18,6 @@
 #include <asm/early_ioremap.h>
 #include <asm/alternative.h>
 #include <asm/cpufeature.h>
-#include <asm/rsi.h>
 
 /*
  * Generic IO read/write.  These perform native-endian accesses.

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

index 636f45b4d8af..f03b9d7b83b4 100644
@@ -2,8 +2,8 @@
 #ifndef __ASM_MEM_ENCRYPT_H
 #define __ASM_MEM_ENCRYPT_H
 
+#include <linux/arm-rsi-cmds.h>
 #include <asm/hypervisor.h>
-#include <asm/rsi.h>
 
 struct device;

arch/arm64/include/asm/pgtable-prot.h +1 -1

index 09d7c00cf405..58e71e592175 100644
@@ -66,9 +66,9 @@
 
 #ifndef __ASSEMBLER__
 
+#include <linux/arm-rsi-cmds.h>
 #include <asm/cpufeature.h>
 #include <asm/pgtable-types.h>
-#include <asm/rsi.h>
 
 extern bool arm64_use_ng_mappings;
 extern unsigned long prot_ns_shared;

arch/arm64/include/asm/rsi.h deleted +0 ~~-70~~

70 lines not on this page · raw message

arch/arm64/kernel/Makefile +1 -1

index d2690c3ec528..21fc3a3d25c9 100644
@@ -34,7 +34,7 @@ obj-y			:= debug-monitors.o entry.o irq.o fpsimd.o		\
 			   cpufeature.o alternative.o cacheinfo.o		\
 			   smp.o smp_spin_table.o topology.o smccc-call.o	\
 			   syscall.o proton-pack.o idle.o patching.o pi/	\
-			   rsi.o jump_label.o
+			   jump_label.o
 
 obj-$(CONFIG_COMPAT)			+= sys32.o signal32.o			\
 					   sys_compat.o

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

index 29c6100f0c50..a707deba6ae7 100644
@@ -7,6 +7,7 @@
  */
 
 #include <linux/acpi.h>
+#include <linux/arm-rsi-cmds.h>
 #include <linux/export.h>
 #include <linux/kernel.h>
 #include <linux/stddef.h>

@@ -43,7 +44,6 @@
 #include <asm/cpu_ops.h>
 #include <asm/kasan.h>
 #include <asm/numa.h>
-#include <asm/rsi.h>
 #include <asm/scs.h>
 #include <asm/sections.h>
 #include <asm/setup.h>

arch/arm64/mm/init.c +2 -1

index fbf215ecc7d0..2a8de20d2b44 100644
@@ -34,6 +34,8 @@
 #include <linux/acpi_iort.h>
 #include <linux/kmemleak.h>
 #include <linux/execmem.h>
+#include <linux/arm-rsi-cmds.h>
+
 
 #include <asm/boot.h>
 #include <asm/fixmap.h>

@@ -43,7 +45,6 @@
 #include <asm/kvm_host.h>
 #include <asm/memory.h>
 #include <asm/numa.h>
-#include <asm/rsi.h>
 #include <asm/sections.h>
 #include <asm/setup.h>
 #include <linux/sizes.h>

drivers/firmware/Kconfig +1 -0

index b7cc11e4fbfa..62660bf520a8 100644
@@ -310,5 +310,6 @@ source "drivers/firmware/samsung/Kconfig"
 source "drivers/firmware/smccc/Kconfig"
 source "drivers/firmware/tegra/Kconfig"
 source "drivers/firmware/xilinx/Kconfig"
+source "drivers/firmware/arm_rmm/Kconfig"
 
 endmenu

drivers/firmware/Makefile +1 -0

index be46f1e1dc77..196a650ccf02 100644
@@ -39,3 +39,4 @@ obj-y				+= samsung/
 obj-y				+= smccc/
 obj-y				+= tegra/
 obj-y				+= xilinx/
+obj-y				+= arm_rmm/

drivers/firmware/arm_rmm/Kconfig new file +17 -0

new file mode 100644
index 000000000000..e981e12fdbe6
@@ -0,0 +1,17 @@
+
+config ARCH_SUPPORTS_RMM
+	bool
+
+config ARM_RMM_RSI
+	bool "Realm Service Interface (RSI) Support"
+	depends on ARCH_SUPPORTS_RMM
+	default y
+	help
+	  Enable support for running Linux as a Realm guest under a Realm
+	  Management Monitor (RMM), as defined by the Arm Confidential
+	  Compute Architecture.
+
+	  The RMM exposes the Realm Service Interface (RSI) to Realm guests.
+	  Linux uses RSI to negotiate the interface version, obtain the Realm
+	  configuration, and manage the protected or shared state of guest
+	  memory.

drivers/firmware/arm_rmm/Makefile new file +2 -0

new file mode 100644
index 000000000000..3708b37a9aaf
@@ -0,0 +1,2 @@
+
+obj-$(CONFIG_ARM_RMM_RSI)	= rsi.o

drivers/firmware/arm_rmm/rsi.c renamed from arch/arm64/kernel/rsi.c +1 -1

similarity index 99%
rename from arch/arm64/kernel/rsi.c
rename to drivers/firmware/arm_rmm/rsi.c
index 25ca75ce1a4d..8e716f1c1e31 100644
@@ -8,11 +8,11 @@
 #include <linux/psci.h>
 #include <linux/swiotlb.h>
 #include <linux/platform_device.h>
+#include <linux/arm-rsi-cmds.h>
 
 #include <asm/io.h>
 #include <asm/mem_encrypt.h>
 #include <asm/pgtable.h>
-#include <asm/rsi.h>
 
 static struct realm_config config;

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

index 3f0f013f03f1..2582ebb36922 100644
@@ -1,6 +1,6 @@
 config ARM_CCA_GUEST
 	tristate "Arm CCA Guest driver"
-	depends on ARM64
+	depends on ARM_RMM_RSI
 	select TSM_REPORTS
 	help
 	  The driver provides userspace interface to request and

drivers/virt/coco/arm-cca-guest/arm-cca-guest.c +2 -3

index 0eeddd1ff05b..b741643d1364 100644
@@ -3,7 +3,8 @@
  * Copyright (C) 2023 ARM Ltd.
  */
 
-#include <linux/arm-smccc.h>
+#include <linux/arm-rsi-cmds.h>
+#include <linux/arm-smccc-rsi.h>
 #include <linux/cc_platform.h>
 #include <linux/kernel.h>
 #include <linux/device-id/platform.h>

@@ -12,8 +13,6 @@
 #include <linux/tsm.h>
 #include <linux/types.h>
 
-#include <asm/rsi.h>
-
 /**
  * struct arm_cca_token_info - a descriptor for the token buffer.
  * @granule:		PA of the granule to which the token will be written

include/linux/arm-rsi-cmds.h renamed from arch/arm64/include/asm/rsi_cmds.h +72 -5

96 lines not on this page · raw message

include/linux/arm-smccc-rsi.h renamed from arch/arm64/include/asm/rsi_smc.h +3 -3

similarity index 98%
rename from arch/arm64/include/asm/rsi_smc.h
rename to include/linux/arm-smccc-rsi.h
index e19253f96c94..fddb77986f70 100644
@@ -3,8 +3,8 @@
  * Copyright (C) 2023 ARM Ltd.
  */
 
-#ifndef __ASM_RSI_SMC_H_
-#define __ASM_RSI_SMC_H_
+#ifndef __LINUX_ARM_SMCCC_RSI_H_
+#define __LINUX_ARM_SMCCC_RSI_H_
 
 #include <linux/arm-smccc.h>

@@ -190,4 +190,4 @@ struct realm_config {
  */
 #define SMC_RSI_HOST_CALL			SMC_RSI_FID(0x199)
 
-#endif /* __ASM_RSI_SMC_H_ */
+#endif /* __LINUX_ARM_SMCCC_RSI_H_ */

Signature · 1 line

2.43.0

Catalin Marinas

maintainer Reviewed-by on v11 3/7

2026-09-14 13:18 UTC #13 lore raw

Re: [PATCH v11 3/7] firmware: arm_rmm: Move RSI support out of arch/arm64

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

The RSI SMCCC function IDs describe a firmware ABI and are not arm64 architecture specific definitions. Follow-up changes need to use them from non-arch code, including drivers/firmware/smccc and the Arm CCA guest driver.
Move the complete Realm Service Interface (RSI) implementation from arch/arm64 to drivers/firmware/arm_rmm. The RSI SMCCC definitions and command helpers are also moved to include/linux so they can be shared by architecture code and firmware or driver code. This also keeps the firmware interface outside architecture code, as requested [1].

Quoted 5 lines

[1] https://lore.kernel.org/all/agsNO9cc7H-b0H8L@willie-the-truck
Reviewed-by Jason Gunthorpe <[email protected]>
Acked-by Suzuki K Poulose <[email protected]>
Signed-off-by Aneesh Kumar K.V (Arm) <[email protected]>

The patch looks alright but always wondered why this and the following two patches are not first in the series. They look like some almost independent cleanup randomly in the middle of the SMCCC bus series.

Otherwise,

Jonathan Cameron

Reviewed-by on v11 3/7

2026-09-14 20:46 UTC #14 lore raw

Re: [PATCH v11 3/7] firmware: arm_rmm: Move RSI support out of arch/arm64

Quoted 11 lines · On Mon, 14 Sep 2026 11:35:07 +0530 "Aneesh Kumar K.V (Arm)"…

The RSI SMCCC function IDs describe a firmware ABI and are not arm64 architecture specific definitions. Follow-up changes need to use them from non-arch code, including drivers/firmware/smccc and the Arm CCA guest driver.
Move the complete Realm Service Interface (RSI) implementation from arch/arm64 to drivers/firmware/arm_rmm. The RSI SMCCC definitions and command helpers are also moved to include/linux so they can be shared by architecture code and firmware or driver code. This also keeps the firmware interface outside architecture code, as requested [1].

Quoted 5 lines

[1] https://lore.kernel.org/all/agsNO9cc7H-b0H8L@willie-the-truck
Reviewed-by Jason Gunthorpe <[email protected]>
Acked-by Suzuki K Poulose <[email protected]>
Signed-off-by Aneesh Kumar K.V (Arm) <[email protected]>

Moving the code makes sense and indeed that is what the patch does so

Trivial gripe about the original code inline.

Quoted 8 lines

include/linux/arm-rsi-cmds.h renamed from arch/arm64/include/asm/rsi_cmds.h +0 -0
similarity index 69%
rename from arch/arm64/include/asm/rsi_cmds.h
rename to include/linux/arm-rsi-cmds.h
index c1fab41f671e..9e8a8c189ca1 100644
 

include/linux/arm-rsi-cmds.h static inline long rsi_set_addr_range_state(phys_addr_t start, · line 121

Quoted 10 lines

include/linux/arm-rsi-cmds.h renamed from arch/arm64/include/asm/rsi_cmds.h +9 -0

 
+static inline int rsi_set_memory_range(phys_addr_t start, phys_addr_t end,
+				       enum ripas state, unsigned long flags)
+{
+	unsigned long ret;
+	phys_addr_t top;
+
+	while (start != end) {
+		ret = rsi_set_addr_range_state(start, end, state, flags, &top);
+		if (ret || top < start || top > end)

Obviously this is just code movement, but why eat the error value that rsi_set_addr_range_state() returns?

Quoted 6 lines

include/linux/arm-rsi-cmds.h renamed from arch/arm64/include/asm/rsi_cmds.h +6 -0
+			return -EINVAL;
+		start = top;
+	}
+
+	return 0;
+}

Catalin Marinas

maintainer

2026-09-16 10:58 UTC #15 lore raw

Re: [PATCH v11 3/7] firmware: arm_rmm: Move RSI support out of arch/arm64

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

The RSI SMCCC function IDs describe a firmware ABI and are not arm64 architecture specific definitions. Follow-up changes need to use them from non-arch code, including drivers/firmware/smccc and the Arm CCA guest driver.
Move the complete Realm Service Interface (RSI) implementation from arch/arm64 to drivers/firmware/arm_rmm. The RSI SMCCC definitions and command helpers are also moved to include/linux so they can be shared by architecture code and firmware or driver code. This also keeps the firmware interface outside architecture code, as requested [1].
[1] https://lore.kernel.org/all/agsNO9cc7H-b0H8L@willie-the-truck
Reviewed-by Jason Gunthorpe <[email protected]>
Acked-by Suzuki K Poulose <[email protected]>
Signed-off-by Aneesh Kumar K.V (Arm) <[email protected]>
---
 arch/arm64/Kconfig                            |  1 +
 arch/arm64/include/asm/io.h                   |  2 +-
 arch/arm64/include/asm/mem_encrypt.h          |  2 +-
 arch/arm64/include/asm/pgtable-prot.h         |  2 +-
 arch/arm64/include/asm/rsi.h                  | 70 -----------------
 arch/arm64/kernel/Makefile                    |  2 +-
 arch/arm64/kernel/setup.c                     |  2 +-
 arch/arm64/mm/init.c                          |  3 +-
 drivers/firmware/Kconfig                      |  1 +
 drivers/firmware/Makefile                     |  1 +
 drivers/firmware/arm_rmm/Kconfig              | 17 ++++
 drivers/firmware/arm_rmm/Makefile             |  2 +
 .../kernel => drivers/firmware/arm_rmm}/rsi.c |  2 +-
 drivers/virt/coco/arm-cca-guest/Kconfig       |  2 +-
 .../virt/coco/arm-cca-guest/arm-cca-guest.c   |  5 +-
 .../linux/arm-rsi-cmds.h                      | 77 +++++++++++++++++--

Quoted 8 lines

 .../linux/arm-smccc-rsi.h                     |  6 +-
 17 files changed, 108 insertions(+), 89 deletions(-)
 delete mode 100644 arch/arm64/include/asm/rsi.h
 create mode 100644 drivers/firmware/arm_rmm/Kconfig
 create mode 100644 drivers/firmware/arm_rmm/Makefile
 rename {arch/arm64/kernel => drivers/firmware/arm_rmm}/rsi.c (99%)
 rename arch/arm64/include/asm/rsi_cmds.h => include/linux/arm-rsi-cmds.h (69%)
 rename arch/arm64/include/asm/rsi_smc.h => include/linux/arm-smccc-rsi.h (98%)

BTW, can you also add the new files under the ARM64 PORT in MAINTAINERS, similar to arm-cca-guest?

Thanks.

Signature · 1 line

Catalin

Aneesh Kumar K.V (Arm)

author

2026-09-14 06:05 UTC #16 lore raw

PATCH v11 4/7 arm64: realm: Move Realm memory encryption ops to RSI code

Realm memory encryption callbacks are CCA-specific. Keep the Realm callback registration with the RSI initialization code instead of pageattr.c, which only needs to provide the low-level page-attribute transition helper.

Export __set_memory_enc_dec() within arm64 so the RSI code can wrap it with the Realm-specific encrypt/decrypt callbacks and warning policy.

No functional changes in this patch.

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

---
 arch/arm64/include/asm/mem_encrypt.h |  3 +--
 arch/arm64/mm/pageattr.c             | 38 +---------------------------
 drivers/firmware/arm_rmm/rsi.c       | 34 +++++++++++++++++++++++++
 3 files changed, 36 insertions(+), 39 deletions(-)

arch/arm64/include/asm/mem_encrypt.h +1 -2

index f03b9d7b83b4..ef8b8463e52b 100644
@@ -16,8 +16,7 @@ int arm64_mem_crypt_ops_register(const struct arm64_mem_crypt_ops *ops);
 
 int set_memory_encrypted(unsigned long addr, int numpages);
 int set_memory_decrypted(unsigned long addr, int numpages);
-
-int realm_register_memory_enc_ops(void);
+int __set_memory_enc_dec(unsigned long addr, int numpages, bool encrypt);
 
 static inline bool force_dma_unencrypted(struct device *dev)
 {

arch/arm64/mm/pageattr.c +1 ~~-37~~

index bbe98ac9ad8c..14b2a3801f40 100644
@@ -275,9 +275,7 @@ int set_direct_map_default_noflush(struct page *page)
 				 PAGE_SIZE, set_mask, clear_mask);
 }
 
-static int __set_memory_enc_dec(unsigned long addr,
-				int numpages,
-				bool encrypt)
+int __set_memory_enc_dec(unsigned long addr, int numpages, bool encrypt)
 {
 	unsigned long set_prot = 0, clear_prot = 0;
 	phys_addr_t start, end;

@@ -321,40 +319,6 @@ static int __set_memory_enc_dec(unsigned long addr,
 				      __pgprot(PTE_PRESENT_INVALID));
 }
 
-static int realm_set_memory_encrypted(unsigned long addr, int numpages)
-{
-	int ret = __set_memory_enc_dec(addr, numpages, true);
-
-	/*
-	 * If the request to change state fails, then the only sensible cause
-	 * of action for the caller is to leak the memory
-	 */
-	WARN(ret, "Failed to encrypt memory, %d pages will be leaked",
-	     numpages);
-
-	return ret;
-}
-
-static int realm_set_memory_decrypted(unsigned long addr, int numpages)
-{
-	int ret = __set_memory_enc_dec(addr, numpages, false);
-
-	WARN(ret, "Failed to decrypt memory, %d pages will be leaked",
-	     numpages);
-
-	return ret;
-}
-
-static const struct arm64_mem_crypt_ops realm_crypt_ops = {
-	.encrypt = realm_set_memory_encrypted,
-	.decrypt = realm_set_memory_decrypted,
-};
-
-int realm_register_memory_enc_ops(void)
-{
-	return arm64_mem_crypt_ops_register(&realm_crypt_ops);
-}
-
 int set_direct_map_valid_noflush(struct page *page, unsigned nr, bool valid)
 {
 	unsigned long addr = (unsigned long)page_address(page);

drivers/firmware/arm_rmm/rsi.c +34 -0

index 8e716f1c1e31..ada139d0e344 100644
@@ -127,6 +127,40 @@ static int realm_ioremap_hook(phys_addr_t phys, size_t size, pgprot_t *prot)
 	return 0;
 }
 
+static int realm_set_memory_encrypted(unsigned long addr, int numpages)
+{
+	int ret = __set_memory_enc_dec(addr, numpages, true);
+
+	/*
+	 * If the request to change state fails, then the only sensible cause
+	 * of action for the caller is to leak the memory
+	 */
+	WARN(ret, "Failed to encrypt memory, %d pages will be leaked",
+	     numpages);
+
+	return ret;
+}
+
+static int realm_set_memory_decrypted(unsigned long addr, int numpages)
+{
+	int ret = __set_memory_enc_dec(addr, numpages, false);
+
+	WARN(ret, "Failed to decrypt memory, %d pages will be leaked",
+	     numpages);
+
+	return ret;
+}
+
+static const struct arm64_mem_crypt_ops realm_crypt_ops = {
+	.encrypt = realm_set_memory_encrypted,
+	.decrypt = realm_set_memory_decrypted,
+};
+
+static int realm_register_memory_enc_ops(void)
+{
+	return arm64_mem_crypt_ops_register(&realm_crypt_ops);
+}
+
 void __init arm64_rsi_init(void)
 {
 	if (arm_smccc_1_1_get_conduit() != SMCCC_CONDUIT_SMC)

Signature · 1 line

2.43.0

Catalin Marinas

maintainer Reviewed-by on v11 4/7

2026-09-14 13:20 UTC #17 lore raw

Re: [PATCH v11 4/7] arm64: realm: Move Realm memory encryption ops to RSI code

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

Realm memory encryption callbacks are CCA-specific. Keep the Realm callback registration with the RSI initialization code instead of pageattr.c, which only needs to provide the low-level page-attribute transition helper.
Export __set_memory_enc_dec() within arm64 so the RSI code can wrap it with the Realm-specific encrypt/decrypt callbacks and warning policy.

Suzuki commented on v9 I think not to expose this function but I don't see a nice way around since we now moved the realm_crypt_ops out of pageattr.c (so we'd have to export something out of that file).

Suzuki K Poulose

2026-09-14 14:50 UTC #18 lore raw

Re: [PATCH v11 4/7] arm64: realm: Move Realm memory encryption ops to RSI code

Quoted 11 lines · Catalin Marinas

Quoted 6 lines · Aneesh Kumar K.V (Arm)
Realm memory encryption callbacks are CCA-specific. Keep the Realm callback registration with the RSI initialization code instead of pageattr.c, which only needs to provide the low-level page-attribute transition helper.
Export __set_memory_enc_dec() within arm64 so the RSI code can wrap it with the Realm-specific encrypt/decrypt callbacks and warning policy.
Suzuki commented on v9 I think not to expose this function but I don't see a nice way around since we now moved the realm_crypt_ops out of pageattr.c (so we'd have to export something out of that file).

Yep, you are right. Thats the conclusion we reached to.

Quoted 2 lines

Reviewed-by Catalin Marinas <[email protected]>

Thanks
Suzuki

Suzuki K Poulose

Reviewed-by on v11 4/7

2026-09-16 15:22 UTC #19 lore raw

Re: [PATCH v11 4/7] arm64: realm: Move Realm memory encryption ops to RSI code

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

Realm memory encryption callbacks are CCA-specific. Keep the Realm callback registration with the RSI initialization code instead of pageattr.c, which only needs to provide the low-level page-attribute transition helper.
Export __set_memory_enc_dec() within arm64 so the RSI code can wrap it with the Realm-specific encrypt/decrypt callbacks and warning policy.
No functional changes in this patch.
Reviewed-by Jason Gunthorpe <[email protected]>
Signed-off-by Aneesh Kumar K.V (Arm) <[email protected]>

Reviewed-by Suzuki K Poulose <[email protected]>

Aneesh Kumar K.V (Arm)

author

2026-09-14 06:05 UTC #20 lore raw

PATCH v11 5/7 virt: coco: arm-cca-guest: Rename TSM report source file

The Arm CCA guest driver currently only implements TSM report support, but follow-up changes will add more TSM-related functionality to the same module.

Rename arm-cca-guest.c to main.c and build it as an object of the arm-cca-guest module. This leaves room for the module to grow additional source files.

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

---
 drivers/virt/coco/arm-cca-guest/Makefile                    | 2 ++
 drivers/virt/coco/arm-cca-guest/{arm-cca-guest.c => main.c} | 6 +++---
 2 files changed, 5 insertions(+), 3 deletions(-)
 rename drivers/virt/coco/arm-cca-guest/{arm-cca-guest.c => main.c} (97%)

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

index 69eeba08e98a..7564f4fcc4a4 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 += main.o

drivers/virt/coco/arm-cca-guest/main.c renamed from drivers/virt/coco/arm-cca-guest/arm-cca-guest.c +3 -3

similarity index 97%
rename from drivers/virt/coco/arm-cca-guest/arm-cca-guest.c
rename to drivers/virt/coco/arm-cca-guest/main.c
index b741643d1364..80659f0885e9 100644
@@ -156,7 +156,7 @@ 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,
 };

@@ -177,7 +177,7 @@ static int __init arm_cca_guest_init(void)
 	if (!is_realm_world())
 		return -ENODEV;
 
-	ret = tsm_report_register(&arm_cca_tsm_ops, NULL);
+	ret = tsm_report_register(&arm_cca_tsm_report_ops, NULL);
 	if (ret < 0)
 		pr_err("Error %d registering with TSM\n", ret);

@@ -191,7 +191,7 @@ module_init(arm_cca_guest_init);
  */
 static void __exit arm_cca_guest_exit(void)
 {
-	tsm_report_unregister(&arm_cca_tsm_ops);
+	tsm_report_unregister(&arm_cca_tsm_report_ops);
 }
 module_exit(arm_cca_guest_exit);

Signature · 1 line

2.43.0

Catalin Marinas

maintainer Reviewed-by on v11 5/7

2026-09-14 13:23 UTC #21 lore raw

Re: [PATCH v11 5/7] virt: coco: arm-cca-guest: Rename TSM report source file

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

The Arm CCA guest driver currently only implements TSM report support, but follow-up changes will add more TSM-related functionality to the same module.
Rename arm-cca-guest.c to main.c and build it as an object of the arm-cca-guest module. This leaves room for the module to grow additional source files.
Reviewed-by Jason Gunthorpe <[email protected]>
Signed-off-by Aneesh Kumar K.V (Arm) <[email protected]>

Suzuki K Poulose

Reviewed-by on v11 5/7

2026-09-14 15:07 UTC #22 lore raw

Re: [PATCH v11 5/7] virt: coco: arm-cca-guest: Rename TSM report source file

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

The Arm CCA guest driver currently only implements TSM report support, but follow-up changes will add more TSM-related functionality to the same module.
Rename arm-cca-guest.c to main.c and build it as an object of the arm-cca-guest module. This leaves room for the module to grow additional source files.
Reviewed-by Jason Gunthorpe <[email protected]>
Signed-off-by Aneesh Kumar K.V (Arm) <[email protected]>

Reviewed-by Suzuki K Poulose <[email protected]>

Jonathan Cameron

2026-09-14 20:48 UTC #23 lore raw

Re: [PATCH v11 5/7] virt: coco: arm-cca-guest: Rename TSM report source file

Quoted 7 lines · On Mon, 14 Sep 2026 11:35:09 +0530 "Aneesh Kumar K.V (Arm)"…

The Arm CCA guest driver currently only implements TSM report support, but follow-up changes will add more TSM-related functionality to the same module.
Rename arm-cca-guest.c to main.c and build it as an object of the arm-cca-guest module. This leaves room for the module to grow additional source files.

Should probably mention the structure renames that you have in here. I wasn't expecting to see anything other than build system changes and a file rename.

Jonathan

Quoted 52 lines

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

---
 drivers/virt/coco/arm-cca-guest/Makefile                    | 2 ++
 drivers/virt/coco/arm-cca-guest/{arm-cca-guest.c => main.c} | 6 +++---
 2 files changed, 5 insertions(+), 3 deletions(-)
 rename drivers/virt/coco/arm-cca-guest/{arm-cca-guest.c => main.c} (97%)

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

index 69eeba08e98a..7564f4fcc4a4 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 += main.o

drivers/virt/coco/arm-cca-guest/main.c renamed from drivers/virt/coco/arm-cca-guest/arm-cca-guest.c +3 -3

similarity index 97%
rename from drivers/virt/coco/arm-cca-guest/arm-cca-guest.c
rename to drivers/virt/coco/arm-cca-guest/main.c
index b741643d1364..80659f0885e9 100644
@@ -156,7 +156,7 @@ 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,
 };

@@ -177,7 +177,7 @@ static int __init arm_cca_guest_init(void)
 	if (!is_realm_world())
 		return -ENODEV;
 
-	ret = tsm_report_register(&arm_cca_tsm_ops, NULL);
+	ret = tsm_report_register(&arm_cca_tsm_report_ops, NULL);
 	if (ret < 0)
 		pr_err("Error %d registering with TSM\n", ret);

@@ -191,7 +191,7 @@ module_init(arm_cca_guest_init);
  */
 static void __exit arm_cca_guest_exit(void)
 {
-	tsm_report_unregister(&arm_cca_tsm_ops);
+	tsm_report_unregister(&arm_cca_tsm_report_ops);
 }
 module_exit(arm_cca_guest_exit);

Aneesh Kumar K.V (Arm)

author

2026-09-14 06:06 UTC #24 lore raw

PATCH v11 6/7 firmware: smccc: arm-cca-guest: Bind the TSM provider to an SMCCC device

The Arm CCA guest TSM provider currently binds through the arm-cca-dev platform device. Like arm-smccc-trng, this device is not an independent platform resource; it is a software representation of the RSI firmware service discovered through SMCCC.

Move RSI discovery into the SMCCC firmware driver. When the SMCCC conduit is SMC and if RSI ABI version call is supported, create an arm-rsi-dev SMCCC device. Convert the Arm CCA guest TSM provider to an SMCCC driver so it binds to that discovered RSI service and keeps module autoloading through the SMCCC device id table.

Keep the old arm-cca-dev platform-device registration for now. Userspace has used that device as a Realm-guest indicator, so removing it is left to a follow-up patch that adds a replacement sysfs ABI.

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

---
 drivers/firmware/arm_rmm/rsi.c          |  2 +-
 drivers/firmware/smccc/smccc.c          |  6 ++++
 drivers/virt/coco/arm-cca-guest/Kconfig |  1 +
 drivers/virt/coco/arm-cca-guest/main.c  | 44 +++++++++++--------------
 include/linux/arm-rsi-cmds.h            |  1 -
 5 files changed, 27 insertions(+), 27 deletions(-)

drivers/firmware/arm_rmm/rsi.c +1 -1

index ada139d0e344..2dd69febedbd 100644
@@ -183,7 +183,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/smccc.c +6 -0

index 756c79204e44..e1b16a09a265 100644
@@ -10,6 +10,7 @@
 #include <linux/arm-smccc.h>
 #include <linux/kernel.h>
 #include <linux/arm-smccc-bus.h>
+#include <linux/arm-smccc-rsi.h>
 
 #include <asm/archrandom.h>

@@ -94,6 +95,11 @@ static const struct smccc_device_info smccc_devices[] __initconst = {
 		.requires_smc   = false,
 		.device_name    = "arm-smccc-trng",
 	},
+	{
+		.func_id        = SMC_RSI_ABI_VERSION,
+		.requires_smc   = true,
+		.device_name    = "arm-rsi",
+	},
 };
 
 static bool __init smccc_probe_smccc_device(const struct smccc_device_info *smccc_dev)

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

index 2582ebb36922..0d4ce72e2d86 100644
@@ -1,6 +1,7 @@
 config ARM_CCA_GUEST
 	tristate "Arm CCA Guest driver"
 	depends on ARM_RMM_RSI
+	depends on HAVE_ARM_SMCCC_DISCOVERY
 	select TSM_REPORTS
 	help
 	  The driver provides userspace interface to request and

drivers/virt/coco/arm-cca-guest/main.c +19 ~~-25~~

71 lines not on this page · raw message

include/linux/arm-rsi-cmds.h +0 -1

index 9e8a8c189ca1..3f7a6a833993 100644
@@ -11,7 +11,6 @@
 #include <linux/string.h>
 #include <asm/memory.h>
 
-#define RSI_PDEV_NAME "arm-cca-dev"
 #ifdef CONFIG_ARM_RMM_RSI
 DECLARE_STATIC_KEY_FALSE(rsi_present);

Signature · 1 line

2.43.0

Catalin Marinas

maintainer Reviewed-by on v11 6/7

2026-09-14 13:43 UTC #25 lore raw

Re: [PATCH v11 6/7] firmware: smccc: arm-cca-guest: Bind the TSM provider to an SMCCC device

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

The Arm CCA guest TSM provider currently binds through the arm-cca-dev platform device. Like arm-smccc-trng, this device is not an independent platform resource; it is a software representation of the RSI firmware service discovered through SMCCC.
Move RSI discovery into the SMCCC firmware driver. When the SMCCC conduit is SMC and if RSI ABI version call is supported, create an arm-rsi-dev

Nit: "arm-rsi". Or did you mean to actually user "arm-rsi-dev" below?

Quoted 9 lines

SMCCC device. Convert the Arm CCA guest TSM provider to an SMCCC driver so it binds to that discovered RSI service and keeps module autoloading through the SMCCC device id table.
Keep the old arm-cca-dev platform-device registration for now. Userspace has used that device as a Realm-guest indicator, so removing it is left to a follow-up patch that adds a replacement sysfs ABI.
Signed-off-by Aneesh Kumar K.V (Arm) <[email protected]>

[...]

drivers/firmware/smccc/smccc.c static const struct smccc_device_info smccc_devices[] __initconst = { · line 103

Quoted 10 lines

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

@@ -94,6 +95,11 @@ static const struct smccc_device_info smccc_devices[] __initconst = {
 		.requires_smc   = false,
 		.device_name    = "arm-smccc-trng",
 	},
+	{
+		.func_id        = SMC_RSI_ABI_VERSION,
+		.requires_smc   = true,
+		.device_name    = "arm-rsi",
+	},
 };

Jonathan Cameron

Reviewed-by on v11 6/7

2026-09-14 20:51 UTC #26 lore raw

Re: [PATCH v11 6/7] firmware: smccc: arm-cca-guest: Bind the TSM provider to an SMCCC device

Quoted 11 lines · On Mon, 14 Sep 2026 11:35:10 +0530 "Aneesh Kumar K.V (Arm)"…

The Arm CCA guest TSM provider currently binds through the arm-cca-dev platform device. Like arm-smccc-trng, this device is not an independent platform resource; it is a software representation of the RSI firmware service discovered through SMCCC.
Move RSI discovery into the SMCCC firmware driver. When the SMCCC conduit is SMC and if RSI ABI version call is supported, create an arm-rsi-dev SMCCC device. Convert the Arm CCA guest TSM provider to an SMCCC driver so it binds to that discovered RSI service and keeps module autoloading through the SMCCC device id table.

Quoted 5 lines

Keep the old arm-cca-dev platform-device registration for now. Userspace has used that device as a Realm-guest indicator, so removing it is left to a follow-up patch that adds a replacement sysfs ABI.
Signed-off-by Aneesh Kumar K.V (Arm) <[email protected]>

One minor thing inline.

drivers/virt/coco/arm-cca-guest/main.c

Quoted 4 lines

drivers/virt/coco/arm-cca-guest/main.c +0 -0
index 80659f0885e9..7b1fa008a8f4 100644

drivers/virt/coco/arm-cca-guest/main.c static int __init arm_cca_guest_init(void) · line 175

Quoted 13 lines

drivers/virt/coco/arm-cca-guest/main.c +4 -2

+static int cca_tsm_probe(struct arm_smccc_device *sdev)
 {
 	int ret;

@@ -178,30 +170,32 @@ static int __init arm_cca_guest_init(void)
 		return -ENODEV;
 
 	ret = tsm_report_register(&arm_cca_tsm_report_ops, NULL);
-	if (ret < 0)
-		pr_err("Error %d registering with TSM\n", ret);
+	if (ret < 0) {
+		dev_err_probe(&sdev->dev, ret, "Error registering with TSM\n");
+		return ret;

		return dev_err_probe();

Having that on one line is one of the nicest things about dev_err_probe()

Quoted 6 lines

drivers/virt/coco/arm-cca-guest/main.c +2 -2
+	}
 
-	return ret;
+	return 0;
 }
-module_init(arm_cca_guest_init);

Jason Gunthorpe

Reviewed-by on v11 6/7

2026-09-16 12:46 UTC #27 lore raw

Re: [PATCH v11 6/7] firmware: smccc: arm-cca-guest: Bind the TSM provider to an SMCCC device

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

The Arm CCA guest TSM provider currently binds through the arm-cca-dev platform device. Like arm-smccc-trng, this device is not an independent platform resource; it is a software representation of the RSI firmware service discovered through SMCCC.

Quoted 7 lines

Move RSI discovery into the SMCCC firmware driver. When the SMCCC conduit is SMC and if RSI ABI version call is supported, create an arm-rsi-dev SMCCC device. Convert the Arm CCA guest TSM provider to an SMCCC driver so it binds to that discovered RSI service and keeps module autoloading through the SMCCC device id table.
[...]

Signature · 1 line

Jason

Sudeep Holla

maintainer Reviewed-by on v11 6/7

2026-09-24 12:24 UTC #28 lore raw

Re: [PATCH v11 6/7] firmware: smccc: arm-cca-guest: Bind the TSM provider to an SMCCC device

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

The Arm CCA guest TSM provider currently binds through the arm-cca-dev platform device. Like arm-smccc-trng, this device is not an independent platform resource; it is a software representation of the RSI firmware service discovered through SMCCC.
Move RSI discovery into the SMCCC firmware driver. When the SMCCC conduit is SMC and if RSI ABI version call is supported, create an arm-rsi-dev SMCCC device. Convert the Arm CCA guest TSM provider to an SMCCC driver so it binds to that discovered RSI service and keeps module autoloading through the SMCCC device id table.
Keep the old arm-cca-dev platform-device registration for now. Userspace has used that device as a Realm-guest indicator, so removing it is left to a follow-up patch that adds a replacement sysfs ABI.
Signed-off-by Aneesh Kumar K.V (Arm) <[email protected]>
---

[...]

Quoted 1 line

 drivers/firmware/smccc/smccc.c          |  6 ++++

Reviewed-by Sudeep Holla <[email protected]>

Signature · 2 lines

Regards,
Sudeep

Aneesh Kumar K.V (Arm)

author

2026-09-14 06:06 UTC #29 lore raw

PATCH v11 7/7 coco: guest: arm64: Replace dummy CCA device with sysfs ABI

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

The SMCCC firmware driver now creates the arm-smccc platform device and instantiates the CCA RSI auxiliary devices once the RSI ABI is discovered. The arm64-specific arm-cca-dev platform device stub is therefore no longer needed.

However, userspace has used the arm-cca-dev platform device to detect Arm CCA Realm guests [1]. Removing it without a replacement would break that detection and would also leave userspace depending on kernel device-model details.

Add /sys/firmware/cca/realm_guest as a stable, architecture-provided ABI for detecting whether the kernel is running as an Arm CCA Realm guest. The file returns 1 in Realm world and 0 otherwise, similar to the existing s390 /sys/firmware/uv/prot_virt_guest interface for protected virtualization guests.

Remove the dummy arm-cca-dev registration now that userspace has a dedicated CCA Realm guest indicator, and document the new ABI in Documentation/ABI/testing/sysfs-firmware-cca.

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

---
 Documentation/ABI/testing/sysfs-firmware-cca | 10 +++++
 drivers/firmware/arm_rmm/rsi.c               | 42 +++++++++++++++-----
 2 files changed, 42 insertions(+), 10 deletions(-)
 create mode 100644 Documentation/ABI/testing/sysfs-firmware-cca

Documentation/ABI/testing/sysfs-firmware-cca new file +10 -0

new file mode 100644
index 000000000000..bf177d636b92
@@ -0,0 +1,10 @@
+What:		/sys/firmware/cca/realm_guest
+Date:		May 2026
+Contact:	Linux ARM Kernel Mailing list <[email protected]>
+Description:	Read-only. Indicates whether the kernel is running as an
+		Arm Confidential Compute Architecture (CCA) Realm guest.
+
+		The value is one of:
+
+		0: the kernel is not running as a Realm guest
+		1: the kernel is running as a Realm guest

drivers/firmware/arm_rmm/rsi.c +32 ~~-10~~

61 lines not on this page · raw message

Signature · 1 line

2.43.0

Catalin Marinas

maintainer Reviewed-by on v11 7/7

2026-09-14 13:49 UTC #30 lore raw

Re: [PATCH v11 7/7] coco: guest: arm64: Replace dummy CCA device with sysfs ABI

Quoted 1 line · Aneesh Kumar K.V (Arm)

The SMCCC firmware driver now creates the arm-smccc platform device and

Nit: we now have devices on an arm_smccc bus, so this first line doesn't make sense.

Quoted 8 lines

instantiates the CCA RSI auxiliary devices once the RSI ABI is discovered. The arm64-specific arm-cca-dev platform device stub is therefore no longer needed.
However, userspace has used the arm-cca-dev platform device to detect Arm CCA Realm guests [1]. Removing it without a replacement would break that detection and would also leave userspace depending on kernel device-model details.

Well, removing it would break the ABI even if you replace it with something else. But I think we agreed it wasn't great for systemd to depend on the old interface either. Assuming systemd can be fixed (and the fix backported) and no production deployments are affected, I'm fine with this.

Jonathan Cameron

Reviewed-by on v11 7/7

2026-09-14 21:00 UTC #31 lore raw

Re: [PATCH v11 7/7] coco: guest: arm64: Replace dummy CCA device with sysfs ABI

Quoted 16 lines · On Mon, 14 Sep 2026 11:35:11 +0530 "Aneesh Kumar K.V (Arm)"…

The SMCCC firmware driver now creates the arm-smccc platform device and instantiates the CCA RSI auxiliary devices once the RSI ABI is discovered. The arm64-specific arm-cca-dev platform device stub is therefore no longer needed.
However, userspace has used the arm-cca-dev platform device to detect Arm CCA Realm guests [1]. Removing it without a replacement would break that detection and would also leave userspace depending on kernel device-model details.
Add /sys/firmware/cca/realm_guest as a stable, architecture-provided ABI for detecting whether the kernel is running as an Arm CCA Realm guest. The file returns 1 in Realm world and 0 otherwise, similar to the existing s390 /sys/firmware/uv/prot_virt_guest interface for protected virtualization guests.

Quoted 3 lines

Remove the dummy arm-cca-dev registration now that userspace has a dedicated CCA Realm guest indicator, and document the new ABI in Documentation/ABI/testing/sysfs-firmware-cca.

My gut feeling would be to split this in to the new stuff in first patch and the removal in second. That would make a revert simpler should it turn out that someone has userspace that will actually notice and can't be easily updated. I'm not that bothered though as it will be your problem not mine (hopefully!) ;)

Quoted 2 lines

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

Could make that a link tag.

Link https://lore.kernel.org/all/[email protected] #[1] open here

Quoted 2 lines

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

One trivial thing inline.

Quoted 26 lines

---
 Documentation/ABI/testing/sysfs-firmware-cca | 10 +++++
 drivers/firmware/arm_rmm/rsi.c               | 42 +++++++++++++++-----
 2 files changed, 42 insertions(+), 10 deletions(-)
 create mode 100644 Documentation/ABI/testing/sysfs-firmware-cca

Documentation/ABI/testing/sysfs-firmware-cca new file +10 -0

new file mode 100644
index 000000000000..bf177d636b92
@@ -0,0 +1,10 @@
+What:		/sys/firmware/cca/realm_guest
+Date:		May 2026
+Contact:	Linux ARM Kernel Mailing list <[email protected]>
+Description:	Read-only. Indicates whether the kernel is running as an
+		Arm Confidential Compute Architecture (CCA) Realm guest.
+
+		The value is one of:
+
+		0: the kernel is not running as a Realm guest
+		1: the kernel is running as a Realm guest

drivers/firmware/arm_rmm/rsi.c +0 -0

index 2dd69febedbd..52f40256bd78 100644

drivers/firmware/arm_rmm/rsi.c void __init arm64_rsi_init(void) · line 199

Quoted 4 lines

drivers/firmware/arm_rmm/rsi.c +3 -0

 
+static const struct attribute *cca_realm_attrs[] = {
+	&cca_realm_guest.attr,
+	NULL,

Given we don't want anything added after this, no comma ideally.

Quoted 1 line

};

Catalin Marinas

maintainer

2026-09-16 10:57 UTC #32 lore raw

Re: [PATCH v11 7/7] coco: guest: arm64: Replace dummy CCA device with sysfs ABI