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
next prev parent 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