The Linux Kernel Mailing List
 help / color / mirror / Atom feed
From: Aneesh Kumar K.V <aneesh.kumar@kernel.org>
To: Greg KH <gregkh@linuxfoundation.org>
Cc: Catalin Marinas <catalin.marinas@arm.com>,
	linux-kernel@vger.kernel.org,
	linux-arm-kernel@lists.infradead.org,
	Jeremy Linton <jeremy.linton@arm.com>,
	Jonathan Cameron <jic23@kernel.org>,
	Lorenzo Pieralisi <lpieralisi@kernel.org>,
	Mark Rutland <mark.rutland@arm.com>,
	Sudeep Holla <sudeep.holla@arm.com>,
	Will Deacon <will@kernel.org>,
	Jonathan Cameron <jonathan.cameron@huawei.com>,
	Suzuki K Poulose <Suzuki.Poulose@arm.com>
Subject: Re: [PATCH v4 2/2] coco: guest: arm64: Drop dummy RSI platform device stub
Date: Wed, 13 May 2026 15:21:12 +0530	[thread overview]
Message-ID: <yq5azf23skmn.fsf@kernel.org> (raw)
In-Reply-To: <yq5a4ikbu1w2.fsf@kernel.org>

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

  reply	other threads:[~2026-05-13  9:51 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20260427061615.905018-1-aneesh.kumar@kernel.org>
     [not found] ` <20260427061615.905018-2-aneesh.kumar@kernel.org>
2026-05-12 14:36   ` [PATCH v4 1/2] firmware: smccc: coco: Manage arm-smccc platform device and CCA auxiliary drivers Catalin Marinas
2026-05-13  6:56     ` Aneesh Kumar K.V
2026-05-13 10:47       ` Catalin Marinas
     [not found] ` <20260427061615.905018-3-aneesh.kumar@kernel.org>
2026-05-12 14:38   ` [PATCH v4 2/2] coco: guest: arm64: Drop dummy RSI platform device stub Catalin Marinas
2026-05-13  6:58     ` Aneesh Kumar K.V
2026-05-13  7:11       ` Greg KH
2026-05-13  8:53         ` Aneesh Kumar K.V
2026-05-13  9:51           ` Aneesh Kumar K.V [this message]
2026-05-13  9:59           ` Greg KH

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=yq5azf23skmn.fsf@kernel.org \
    --to=aneesh.kumar@kernel.org \
    --cc=Suzuki.Poulose@arm.com \
    --cc=catalin.marinas@arm.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=jeremy.linton@arm.com \
    --cc=jic23@kernel.org \
    --cc=jonathan.cameron@huawei.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=lpieralisi@kernel.org \
    --cc=mark.rutland@arm.com \
    --cc=sudeep.holla@arm.com \
    --cc=will@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox