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

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

[Catalin Marinas]

+ Suzuki

On Mon, Apr 27, 2026 at 11:46:14AM +0530, Aneesh Kumar K.V (Arm) wrote:
> diff --git a/arch/arm64/include/asm/rsi.h b/arch/arm64/include/asm/rsi.h
> index 88b50d660e85..2d2d363aaaee 100644
> --- a/arch/arm64/include/asm/rsi.h
> +++ b/arch/arm64/include/asm/rsi.h
> @@ -10,7 +10,7 @@
>  #include <linux/jump_label.h>
>  #include <asm/rsi_cmds.h>
>  
> -#define RSI_PDEV_NAME "arm-cca-dev"
> +#define RSI_DEV_NAME "arm-rsi-dev"
[...]
> diff --git a/drivers/firmware/smccc/smccc.c b/drivers/firmware/smccc/smccc.c
> index bdee057db2fd..fc9b44b7c687 100644
> --- a/drivers/firmware/smccc/smccc.c
> +++ b/drivers/firmware/smccc/smccc.c
> @@ -12,6 +12,8 @@
>  #include <linux/platform_device.h>
>  #include <asm/archrandom.h>
>  
> +#include "rmm.h"
> +
>  static u32 smccc_version = ARM_SMCCC_VERSION_1_0;
>  static enum arm_smccc_conduit smccc_conduit = SMCCC_CONDUIT_NONE;
>  
> @@ -85,6 +87,18 @@ static int __init smccc_devices_init(void)
>  {
>  	struct platform_device *pdev;
>  
> +	pdev = platform_device_register_simple("arm-smccc",
> +					PLATFORM_DEVID_NONE, NULL, 0);
> +	if (IS_ERR(pdev)) {
> +		pr_err("arm-smccc: could not register device: %ld\n", PTR_ERR(pdev));
> +	} else {
> +		/*
> +		 * Register the RMI and RSI devices only when firmware exposes
> +		 * the required SMCCC function IDs at a supported revision.
> +		 */
> +		register_rsi_device(pdev);
> +	}

So as per the cover letter, instead of "arm-cca-dev" as a platform
device, we get "arm-smccc" as a platform device with an auxiliary
"arm-rsi-dev" child device. This does not get rid of the platform
device, it just creates a synthetic platform device to represent the
SMCCC firmware interface.

Looking at the earlier discussion, I think this is what Greg/Jason were
suggesting, except that we do not currently have an SMCCC platform
device:

https://lore.kernel.org/all/2025101534-frosty-shank-00b1@gregkh/

If we go this route, shouldn't the platform device above be created only
if !SMCCC_CONDUIT_NONE?

"smccc_trng" would also fit this model (together with the driver),
assuming we don't break any user-space (searching the Debian codebase
did not find any use).

-- 
Catalin

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

[Aneesh Kumar K.V]

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

> + Suzuki
>
> On Mon, Apr 27, 2026 at 11:46:14AM +0530, Aneesh Kumar K.V (Arm) wrote:
>> diff --git a/arch/arm64/include/asm/rsi.h b/arch/arm64/include/asm/rsi.h
>> index 88b50d660e85..2d2d363aaaee 100644
>> --- a/arch/arm64/include/asm/rsi.h
>> +++ b/arch/arm64/include/asm/rsi.h
>> @@ -10,7 +10,7 @@
>>  #include <linux/jump_label.h>
>>  #include <asm/rsi_cmds.h>
>>  
>> -#define RSI_PDEV_NAME "arm-cca-dev"
>> +#define RSI_DEV_NAME "arm-rsi-dev"
> [...]
>> diff --git a/drivers/firmware/smccc/smccc.c b/drivers/firmware/smccc/smccc.c
>> index bdee057db2fd..fc9b44b7c687 100644
>> --- a/drivers/firmware/smccc/smccc.c
>> +++ b/drivers/firmware/smccc/smccc.c
>> @@ -12,6 +12,8 @@
>>  #include <linux/platform_device.h>
>>  #include <asm/archrandom.h>
>>  
>> +#include "rmm.h"
>> +
>>  static u32 smccc_version = ARM_SMCCC_VERSION_1_0;
>>  static enum arm_smccc_conduit smccc_conduit = SMCCC_CONDUIT_NONE;
>>  
>> @@ -85,6 +87,18 @@ static int __init smccc_devices_init(void)
>>  {
>>  	struct platform_device *pdev;
>>  
>> +	pdev = platform_device_register_simple("arm-smccc",
>> +					PLATFORM_DEVID_NONE, NULL, 0);
>> +	if (IS_ERR(pdev)) {
>> +		pr_err("arm-smccc: could not register device: %ld\n", PTR_ERR(pdev));
>> +	} else {
>> +		/*
>> +		 * Register the RMI and RSI devices only when firmware exposes
>> +		 * the required SMCCC function IDs at a supported revision.
>> +		 */
>> +		register_rsi_device(pdev);
>> +	}
>
> So as per the cover letter, instead of "arm-cca-dev" as a platform
> device, we get "arm-smccc" as a platform device with an auxiliary
> "arm-rsi-dev" child device. This does not get rid of the platform
> device, it just creates a synthetic platform device to represent the
> SMCCC firmware interface.
>
> Looking at the earlier discussion, I think this is what Greg/Jason were
> suggesting, except that we do not currently have an SMCCC platform
> device:
>
> https://lore.kernel.org/all/2025101534-frosty-shank-00b1@gregkh/
>
> If we go this route, shouldn't the platform device above be created only
> if !SMCCC_CONDUIT_NONE?
>

register_rsi_device() does check for 

	if (arm_smccc_1_1_get_conduit() != SMCCC_CONDUIT_SMC)
		return;

>
> "smccc_trng" would also fit this model (together with the driver),
> assuming we don't break any user-space (searching the Debian codebase
> did not find any use).

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

-aneesh

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

[Catalin Marinas]

On Wed, May 13, 2026 at 12:26:13PM +0530, Aneesh Kumar K.V wrote:
> Catalin Marinas <catalin.marinas@arm.com> writes:
> > On Mon, Apr 27, 2026 at 11:46:14AM +0530, Aneesh Kumar K.V (Arm) wrote:
> >> diff --git a/arch/arm64/include/asm/rsi.h b/arch/arm64/include/asm/rsi.h
> >> index 88b50d660e85..2d2d363aaaee 100644
> >> --- a/arch/arm64/include/asm/rsi.h
> >> +++ b/arch/arm64/include/asm/rsi.h
> >> @@ -10,7 +10,7 @@
> >>  #include <linux/jump_label.h>
> >>  #include <asm/rsi_cmds.h>
> >>  
> >> -#define RSI_PDEV_NAME "arm-cca-dev"
> >> +#define RSI_DEV_NAME "arm-rsi-dev"
> > [...]
> >> diff --git a/drivers/firmware/smccc/smccc.c b/drivers/firmware/smccc/smccc.c
> >> index bdee057db2fd..fc9b44b7c687 100644
> >> --- a/drivers/firmware/smccc/smccc.c
> >> +++ b/drivers/firmware/smccc/smccc.c
> >> @@ -12,6 +12,8 @@
> >>  #include <linux/platform_device.h>
> >>  #include <asm/archrandom.h>
> >>  
> >> +#include "rmm.h"
> >> +
> >>  static u32 smccc_version = ARM_SMCCC_VERSION_1_0;
> >>  static enum arm_smccc_conduit smccc_conduit = SMCCC_CONDUIT_NONE;
> >>  
> >> @@ -85,6 +87,18 @@ static int __init smccc_devices_init(void)
> >>  {
> >>  	struct platform_device *pdev;
> >>  
> >> +	pdev = platform_device_register_simple("arm-smccc",
> >> +					PLATFORM_DEVID_NONE, NULL, 0);
> >> +	if (IS_ERR(pdev)) {
> >> +		pr_err("arm-smccc: could not register device: %ld\n", PTR_ERR(pdev));
> >> +	} else {
> >> +		/*
> >> +		 * Register the RMI and RSI devices only when firmware exposes
> >> +		 * the required SMCCC function IDs at a supported revision.
> >> +		 */
> >> +		register_rsi_device(pdev);
> >> +	}
> >
> > So as per the cover letter, instead of "arm-cca-dev" as a platform
> > device, we get "arm-smccc" as a platform device with an auxiliary
> > "arm-rsi-dev" child device. This does not get rid of the platform
> > device, it just creates a synthetic platform device to represent the
> > SMCCC firmware interface.
> >
> > Looking at the earlier discussion, I think this is what Greg/Jason were
> > suggesting, except that we do not currently have an SMCCC platform
> > device:
> >
> > https://lore.kernel.org/all/2025101534-frosty-shank-00b1@gregkh/
> >
> > If we go this route, shouldn't the platform device above be created only
> > if !SMCCC_CONDUIT_NONE?
> >
> 
> register_rsi_device() does check for 
> 
> 	if (arm_smccc_1_1_get_conduit() != SMCCC_CONDUIT_SMC)
> 		return;

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

-- 
Catalin

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

[Catalin Marinas]

+ Suzuki again

On Mon, Apr 27, 2026 at 11:46:15AM +0530, Aneesh Kumar K.V (Arm) wrote:
> The SMCCC firmware driver now creates the `arm-smccc` platform device
> and also creates the CCA auxiliary devices once the RSI ABI is
> discovered. This makes the arch-specific arm64_create_dummy_rsi_dev()
> helper redundant. Remove the arm-cca-dev platform device registration
> and let the SMCCC probe manage the RSI device.
> 
> systemd match on platform:arm-cca-dev for confidential vm detection [1].
> Losing the platform device registration can break that. Keeping this
> removal in its own change makes it easy to revert if that regression
> blocks the rollout.
> 
> [1] https://lore.kernel.org/all/4a7d84b2-2ec4-4773-a2d5-7b63d5c683cf@arm.com

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

-- 
Catalin

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

[Aneesh Kumar K.V]

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

> + Suzuki again
>
> On Mon, Apr 27, 2026 at 11:46:15AM +0530, Aneesh Kumar K.V (Arm) wrote:
>> The SMCCC firmware driver now creates the `arm-smccc` platform device
>> and also creates the CCA auxiliary devices once the RSI ABI is
>> discovered. This makes the arch-specific arm64_create_dummy_rsi_dev()
>> helper redundant. Remove the arm-cca-dev platform device registration
>> and let the SMCCC probe manage the RSI device.
>> 
>> systemd match on platform:arm-cca-dev for confidential vm detection [1].
>> Losing the platform device registration can break that. Keeping this
>> removal in its own change makes it easy to revert if that regression
>> blocks the rollout.
>> 
>> [1] https://lore.kernel.org/all/4a7d84b2-2ec4-4773-a2d5-7b63d5c683cf@arm.com
>
> I wouldn't merge this now given that systemd checks this file. Could we
> have a symbolic link instead for some time until systemd eventually gets
> updated (years?).
>

I’ll add this in the next revision.

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

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

-aneesh

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

[Greg KH]

On Wed, May 13, 2026 at 12:28:12PM +0530, Aneesh Kumar K.V wrote:
> Catalin Marinas <catalin.marinas@arm.com> writes:
> 
> > + Suzuki again
> >
> > On Mon, Apr 27, 2026 at 11:46:15AM +0530, Aneesh Kumar K.V (Arm) wrote:
> >> The SMCCC firmware driver now creates the `arm-smccc` platform device
> >> and also creates the CCA auxiliary devices once the RSI ABI is
> >> discovered. This makes the arch-specific arm64_create_dummy_rsi_dev()
> >> helper redundant. Remove the arm-cca-dev platform device registration
> >> and let the SMCCC probe manage the RSI device.
> >> 
> >> systemd match on platform:arm-cca-dev for confidential vm detection [1].
> >> Losing the platform device registration can break that. Keeping this
> >> removal in its own change makes it easy to revert if that regression
> >> blocks the rollout.
> >> 
> >> [1] https://lore.kernel.org/all/4a7d84b2-2ec4-4773-a2d5-7b63d5c683cf@arm.com
> >
> > I wouldn't merge this now given that systemd checks this file. Could we
> > have a symbolic link instead for some time until systemd eventually gets
> > updated (years?).
> >
> 
> I’ll add this in the next revision.
> 
> static int create_rsi_compat_link(struct device *target_dev)
> {
> 	struct kobject *platform_kobj;
> 	/*
> 	 * target_dev is:
> 	 * /sys/devices/platform/arm-smccc/arm_cca_guest.arm-rsi-dev.0
> 	 * Create compat link /sys/devices/platform/arm-cca-dev
> 	 */
> 	platform_kobj = target_dev->kobj.parent->parent;

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

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

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

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

thanks,

greg k-h

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

[Aneesh Kumar K.V]

Greg KH <gregkh@linuxfoundation.org> writes:

> On Wed, May 13, 2026 at 12:28:12PM +0530, Aneesh Kumar K.V wrote:
>> Catalin Marinas <catalin.marinas@arm.com> writes:
>> 
>> > + Suzuki again
>> >
>> > On Mon, Apr 27, 2026 at 11:46:15AM +0530, Aneesh Kumar K.V (Arm) wrote:
>> >> The SMCCC firmware driver now creates the `arm-smccc` platform device
>> >> and also creates the CCA auxiliary devices once the RSI ABI is
>> >> discovered. This makes the arch-specific arm64_create_dummy_rsi_dev()
>> >> helper redundant. Remove the arm-cca-dev platform device registration
>> >> and let the SMCCC probe manage the RSI device.
>> >> 
>> >> systemd match on platform:arm-cca-dev for confidential vm detection [1].
>> >> Losing the platform device registration can break that. Keeping this
>> >> removal in its own change makes it easy to revert if that regression
>> >> blocks the rollout.
>> >> 
>> >> [1] https://lore.kernel.org/all/4a7d84b2-2ec4-4773-a2d5-7b63d5c683cf@arm.com
>> >
>> > I wouldn't merge this now given that systemd checks this file. Could we
>> > have a symbolic link instead for some time until systemd eventually gets
>> > updated (years?).
>> >
>> 
>> I’ll add this in the next revision.
>> 
>> static int create_rsi_compat_link(struct device *target_dev)
>> {
>> 	struct kobject *platform_kobj;
>> 	/*
>> 	 * target_dev is:
>> 	 * /sys/devices/platform/arm-smccc/arm_cca_guest.arm-rsi-dev.0
>> 	 * Create compat link /sys/devices/platform/arm-cca-dev
>> 	 */
>> 	platform_kobj = target_dev->kobj.parent->parent;
>
> What?  That is crazy, you don't know that is always going to be ok.
>
>> 	return sysfs_create_link(platform_kobj,
>> 				 &target_dev->kobj,
>> 				 "arm-cca-dev");
>
> No, don't do that, if a driver calls a sysfs* function, something is
> almost always wrong.  Don't be making random sysfs symlinks please.
>

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

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

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

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

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

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

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

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

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

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

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

modified   arch/arm64/kernel/rsi.c
@@ -159,18 +159,3 @@ void __init arm64_rsi_init(void)
 
 	static_branch_enable(&rsi_present);
 }
-
-static struct platform_device rsi_dev = {
-	.name = "arm-cca-dev",
-	.id = PLATFORM_DEVID_NONE
-};
-
-static int __init arm64_create_dummy_rsi_dev(void)
-{
-	if (is_realm_world() &&
-	    platform_device_register(&rsi_dev))
-		pr_err("failed to register rsi platform device\n");
-	return 0;
-}
-
-arch_initcall(arm64_create_dummy_rsi_dev)
modified   drivers/firmware/smccc/rmm.c
@@ -4,13 +4,31 @@
  */
 
 #include <linux/auxiliary_bus.h>
+#include <linux/sysfs.h>
+#include <linux/device.h>
 
 #include "rmm.h"
 
+static int create_rsi_compat_link(struct device *target_dev)
+{
+	struct kobject *platform_kobj;
+	/*
+	 * target_dev is:
+	 * /sys/devices/platform/arm-smccc/arm_cca_guest.arm-rsi-dev.0
+	 * Create compat link /sys/devices/platform/arm-cca-dev
+	 */
+	platform_kobj = target_dev->kobj.parent->parent;
+
+	return sysfs_create_link(platform_kobj,
+				 &target_dev->kobj,
+				 "arm-cca-dev");
+}
+
 void __init register_rsi_device(struct platform_device *pdev)
 {
 	unsigned long ret;
 	unsigned long ver_lower, ver_higher;
+	struct auxiliary_device *adev;
 
 	if (arm_smccc_1_1_get_conduit() != SMCCC_CONDUIT_SMC)
 		return;
@@ -19,6 +37,10 @@ void __init register_rsi_device(struct platform_device *pdev)
 	if (ret != RSI_SUCCESS)
 		return;
 
-	__devm_auxiliary_device_create(&pdev->dev,
-				       "arm_cca_guest", RSI_DEV_NAME, NULL, 0);
+	adev = __devm_auxiliary_device_create(&pdev->dev,
+				"arm_cca_guest", RSI_DEV_NAME, NULL, 0);
+	if (!adev)
+		return;
+
+	create_rsi_compat_link(&adev->dev);
 }


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


-aneesh

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

[Aneesh Kumar K.V]

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

> Greg KH <gregkh@linuxfoundation.org> writes:
>
>> On Wed, May 13, 2026 at 12:28:12PM +0530, Aneesh Kumar K.V wrote:
>>> Catalin Marinas <catalin.marinas@arm.com> writes:
>>> 
>>> > + Suzuki again
>>> >
>>> > On Mon, Apr 27, 2026 at 11:46:15AM +0530, Aneesh Kumar K.V (Arm) wrote:
>>> >> The SMCCC firmware driver now creates the `arm-smccc` platform device
>>> >> and also creates the CCA auxiliary devices once the RSI ABI is
>>> >> discovered. This makes the arch-specific arm64_create_dummy_rsi_dev()
>>> >> helper redundant. Remove the arm-cca-dev platform device registration
>>> >> and let the SMCCC probe manage the RSI device.
>>> >> 
>>> >> systemd match on platform:arm-cca-dev for confidential vm detection [1].
>>> >> Losing the platform device registration can break that. Keeping this
>>> >> removal in its own change makes it easy to revert if that regression
>>> >> blocks the rollout.
>>> >> 
>>> >> [1] https://lore.kernel.org/all/4a7d84b2-2ec4-4773-a2d5-7b63d5c683cf@arm.com
>>> >
>>> > I wouldn't merge this now given that systemd checks this file. Could we
>>> > have a symbolic link instead for some time until systemd eventually gets
>>> > updated (years?).
>>> >
>>> 
>>> I’ll add this in the next revision.
>>> 
>>> static int create_rsi_compat_link(struct device *target_dev)
>>> {
>>> 	struct kobject *platform_kobj;
>>> 	/*
>>> 	 * target_dev is:
>>> 	 * /sys/devices/platform/arm-smccc/arm_cca_guest.arm-rsi-dev.0
>>> 	 * Create compat link /sys/devices/platform/arm-cca-dev
>>> 	 */
>>> 	platform_kobj = target_dev->kobj.parent->parent;
>>
>> What?  That is crazy, you don't know that is always going to be ok.
>>
>>> 	return sysfs_create_link(platform_kobj,
>>> 				 &target_dev->kobj,
>>> 				 "arm-cca-dev");
>>
>> No, don't do that, if a driver calls a sysfs* function, something is
>> almost always wrong.  Don't be making random sysfs symlinks please.
>>
>
> Sure, but could you explain why this is wrong? Below is the full version
> of the updated patch.
>
> coco: guest: arm64 Replace RSI platform device with compat symlink
>
> The SMCCC firmware driver now creates the arm-smccc platform device and
> registers the RSI device as an auxiliary device once the RSI ABI has been
> discovered. This makes the arch-specific arm64 arm-cca-dev platform device
> redundant.
>
> Remove the arm64 platform device stub and let the SMCCC core manage RSI
> device creation.
>
> This changes the real device location from the old platform device path to:
>
>   /sys/devices/platform/arm-smccc/arm_cca_guest.arm-rsi-dev.0
>
> Keep userspace compatibility by creating a sysfs symlink at the old path:
>
>   /sys/devices/platform/arm-cca-dev
>
> A Debian Code Search check found systemd matching on the old
> platform:arm-cca-dev device path for confidential VM detection. No other
> userspace dependency on the old platform device path was found, but keeping
> the compatibility symlink avoids breaking existing systemd-based detection
> [1].
>
> [1] https://lore.kernel.org/all/4a7d84b2-2ec4-4773-a2d5-7b63d5c683cf@arm.com
>
> Signed-off-by: Aneesh Kumar K.V (Arm) <aneesh.kumar@kernel.org>
>
> modified   arch/arm64/kernel/rsi.c
> @@ -159,18 +159,3 @@ void __init arm64_rsi_init(void)
>  
>  	static_branch_enable(&rsi_present);
>  }
> -
> -static struct platform_device rsi_dev = {
> -	.name = "arm-cca-dev",
> -	.id = PLATFORM_DEVID_NONE
> -};
> -
> -static int __init arm64_create_dummy_rsi_dev(void)
> -{
> -	if (is_realm_world() &&
> -	    platform_device_register(&rsi_dev))
> -		pr_err("failed to register rsi platform device\n");
> -	return 0;
> -}
> -
> -arch_initcall(arm64_create_dummy_rsi_dev)
> modified   drivers/firmware/smccc/rmm.c
> @@ -4,13 +4,31 @@
>   */
>  
>  #include <linux/auxiliary_bus.h>
> +#include <linux/sysfs.h>
> +#include <linux/device.h>
>  
>  #include "rmm.h"
>  
> +static int create_rsi_compat_link(struct device *target_dev)
> +{
> +	struct kobject *platform_kobj;
> +	/*
> +	 * target_dev is:
> +	 * /sys/devices/platform/arm-smccc/arm_cca_guest.arm-rsi-dev.0
> +	 * Create compat link /sys/devices/platform/arm-cca-dev
> +	 */
> +	platform_kobj = target_dev->kobj.parent->parent;
> +
> +	return sysfs_create_link(platform_kobj,
> +				 &target_dev->kobj,
> +				 "arm-cca-dev");
> +}
> +
>  void __init register_rsi_device(struct platform_device *pdev)
>  {
>  	unsigned long ret;
>  	unsigned long ver_lower, ver_higher;
> +	struct auxiliary_device *adev;
>  
>  	if (arm_smccc_1_1_get_conduit() != SMCCC_CONDUIT_SMC)
>  		return;
> @@ -19,6 +37,10 @@ void __init register_rsi_device(struct platform_device *pdev)
>  	if (ret != RSI_SUCCESS)
>  		return;
>  
> -	__devm_auxiliary_device_create(&pdev->dev,
> -				       "arm_cca_guest", RSI_DEV_NAME, NULL, 0);
> +	adev = __devm_auxiliary_device_create(&pdev->dev,
> +				"arm_cca_guest", RSI_DEV_NAME, NULL, 0);
> +	if (!adev)
> +		return;
> +
> +	create_rsi_compat_link(&adev->dev);
>  }

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

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

-aneesh

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

[Greg KH]

On Wed, May 13, 2026 at 02:23:01PM +0530, Aneesh Kumar K.V wrote:
> Greg KH <gregkh@linuxfoundation.org> writes:
> 
> > On Wed, May 13, 2026 at 12:28:12PM +0530, Aneesh Kumar K.V wrote:
> >> Catalin Marinas <catalin.marinas@arm.com> writes:
> >> 
> >> > + Suzuki again
> >> >
> >> > On Mon, Apr 27, 2026 at 11:46:15AM +0530, Aneesh Kumar K.V (Arm) wrote:
> >> >> The SMCCC firmware driver now creates the `arm-smccc` platform device
> >> >> and also creates the CCA auxiliary devices once the RSI ABI is
> >> >> discovered. This makes the arch-specific arm64_create_dummy_rsi_dev()
> >> >> helper redundant. Remove the arm-cca-dev platform device registration
> >> >> and let the SMCCC probe manage the RSI device.
> >> >> 
> >> >> systemd match on platform:arm-cca-dev for confidential vm detection [1].
> >> >> Losing the platform device registration can break that. Keeping this
> >> >> removal in its own change makes it easy to revert if that regression
> >> >> blocks the rollout.
> >> >> 
> >> >> [1] https://lore.kernel.org/all/4a7d84b2-2ec4-4773-a2d5-7b63d5c683cf@arm.com
> >> >
> >> > I wouldn't merge this now given that systemd checks this file. Could we
> >> > have a symbolic link instead for some time until systemd eventually gets
> >> > updated (years?).
> >> >
> >> 
> >> I’ll add this in the next revision.
> >> 
> >> static int create_rsi_compat_link(struct device *target_dev)
> >> {
> >> 	struct kobject *platform_kobj;
> >> 	/*
> >> 	 * target_dev is:
> >> 	 * /sys/devices/platform/arm-smccc/arm_cca_guest.arm-rsi-dev.0
> >> 	 * Create compat link /sys/devices/platform/arm-cca-dev
> >> 	 */
> >> 	platform_kobj = target_dev->kobj.parent->parent;
> >
> > What?  That is crazy, you don't know that is always going to be ok.
> >
> >> 	return sysfs_create_link(platform_kobj,
> >> 				 &target_dev->kobj,
> >> 				 "arm-cca-dev");
> >
> > No, don't do that, if a driver calls a sysfs* function, something is
> > almost always wrong.  Don't be making random sysfs symlinks please.
> >
> 
> Sure, but could you explain why this is wrong? Below is the full version
> of the updated patch.
> 
> coco: guest: arm64 Replace RSI platform device with compat symlink
> 
> The SMCCC firmware driver now creates the arm-smccc platform device and
> registers the RSI device as an auxiliary device once the RSI ABI has been
> discovered. This makes the arch-specific arm64 arm-cca-dev platform device
> redundant.
> 
> Remove the arm64 platform device stub and let the SMCCC core manage RSI
> device creation.
> 
> This changes the real device location from the old platform device path to:
> 
>   /sys/devices/platform/arm-smccc/arm_cca_guest.arm-rsi-dev.0
> 
> Keep userspace compatibility by creating a sysfs symlink at the old path:
> 
>   /sys/devices/platform/arm-cca-dev
> 
> A Debian Code Search check found systemd matching on the old
> platform:arm-cca-dev device path for confidential VM detection. No other
> userspace dependency on the old platform device path was found, but keeping
> the compatibility symlink avoids breaking existing systemd-based detection
> [1].
> 
> [1] https://lore.kernel.org/all/4a7d84b2-2ec4-4773-a2d5-7b63d5c683cf@arm.com

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

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

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

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

thanks,

greg k-h

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

[Aneesh Kumar K.V]

Greg KH <gregkh@linuxfoundation.org> writes:

> On Wed, May 13, 2026 at 02:23:01PM +0530, Aneesh Kumar K.V wrote:
>> Greg KH <gregkh@linuxfoundation.org> writes:
>> 
>> > On Wed, May 13, 2026 at 12:28:12PM +0530, Aneesh Kumar K.V wrote:
>> >> Catalin Marinas <catalin.marinas@arm.com> writes:
>> >> 
>> >> > + Suzuki again
>> >> >
>> >> > On Mon, Apr 27, 2026 at 11:46:15AM +0530, Aneesh Kumar K.V (Arm) wrote:
>> >> >> The SMCCC firmware driver now creates the `arm-smccc` platform device
>> >> >> and also creates the CCA auxiliary devices once the RSI ABI is
>> >> >> discovered. This makes the arch-specific arm64_create_dummy_rsi_dev()
>> >> >> helper redundant. Remove the arm-cca-dev platform device registration
>> >> >> and let the SMCCC probe manage the RSI device.
>> >> >> 
>> >> >> systemd match on platform:arm-cca-dev for confidential vm detection [1].
>> >> >> Losing the platform device registration can break that. Keeping this
>> >> >> removal in its own change makes it easy to revert if that regression
>> >> >> blocks the rollout.
>> >> >> 
>> >> >> [1] https://lore.kernel.org/all/4a7d84b2-2ec4-4773-a2d5-7b63d5c683cf@arm.com
>> >> >
>> >> > I wouldn't merge this now given that systemd checks this file. Could we
>> >> > have a symbolic link instead for some time until systemd eventually gets
>> >> > updated (years?).
>> >> >
>> >> 
>> >> I’ll add this in the next revision.
>> >> 
>> >> static int create_rsi_compat_link(struct device *target_dev)
>> >> {
>> >> 	struct kobject *platform_kobj;
>> >> 	/*
>> >> 	 * target_dev is:
>> >> 	 * /sys/devices/platform/arm-smccc/arm_cca_guest.arm-rsi-dev.0
>> >> 	 * Create compat link /sys/devices/platform/arm-cca-dev
>> >> 	 */
>> >> 	platform_kobj = target_dev->kobj.parent->parent;
>> >
>> > What?  That is crazy, you don't know that is always going to be ok.
>> >
>> >> 	return sysfs_create_link(platform_kobj,
>> >> 				 &target_dev->kobj,
>> >> 				 "arm-cca-dev");
>> >
>> > No, don't do that, if a driver calls a sysfs* function, something is
>> > almost always wrong.  Don't be making random sysfs symlinks please.
>> >
>> 
>> Sure, but could you explain why this is wrong? Below is the full version
>> of the updated patch.
>> 
>> coco: guest: arm64 Replace RSI platform device with compat symlink
>> 
>> The SMCCC firmware driver now creates the arm-smccc platform device and
>> registers the RSI device as an auxiliary device once the RSI ABI has been
>> discovered. This makes the arch-specific arm64 arm-cca-dev platform device
>> redundant.
>> 
>> Remove the arm64 platform device stub and let the SMCCC core manage RSI
>> device creation.
>> 
>> This changes the real device location from the old platform device path to:
>> 
>>   /sys/devices/platform/arm-smccc/arm_cca_guest.arm-rsi-dev.0
>> 
>> Keep userspace compatibility by creating a sysfs symlink at the old path:
>> 
>>   /sys/devices/platform/arm-cca-dev
>> 
>> A Debian Code Search check found systemd matching on the old
>> platform:arm-cca-dev device path for confidential VM detection. No other
>> userspace dependency on the old platform device path was found, but keeping
>> the compatibility symlink avoids breaking existing systemd-based detection
>> [1].
>> 
>> [1] https://lore.kernel.org/all/4a7d84b2-2ec4-4773-a2d5-7b63d5c683cf@arm.com
>
> Don't attempt to put symlinks between random devices in sysfs, that way
> lies madness and you will never get anything fixed.
>
> Just fix userspace, it shouldn't have hard-coded a device path in the
> first place, and you are thinking it would now use a different
> hard-coded device path?  Please do this properly.
>
> Again, there should never be any hard-coded device paths, they are free
> to move around and be renamed at any time.  Use the correct apis instead
> (walking all bus devices, looking at userspace attributes of classes,
> etc.)
>
> So your patch is ok, if you remove the symlink stuff.
>

How about adding /sys/firmware/cca/realm_guest? This would be similar to
/sys/firmware/uv/prot_virt_guest, which is provided on s390.

-aneesh