Linux-ARM-Kernel Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: Greg KH <gregkh@linuxfoundation.org>
To: "Aneesh Kumar K.V" <aneesh.kumar@kernel.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 09:11:17 +0200	[thread overview]
Message-ID: <2026051352-albatross-contents-7113@gregkh> (raw)
In-Reply-To: <yq5a7bp7u77f.fsf@kernel.org>

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


  reply	other threads:[~2026-05-13  7:12 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-04-27  6:16 [PATCH v4 0/2] Switch Arm CCA to use an auxiliary device instead of a platform device Aneesh Kumar K.V (Arm)
2026-04-27  6:16 ` [PATCH v4 1/2] firmware: smccc: coco: Manage arm-smccc platform device and CCA auxiliary drivers Aneesh Kumar K.V (Arm)
2026-05-12 14:36   ` Catalin Marinas
2026-05-13  6:56     ` Aneesh Kumar K.V
2026-05-13 10:47       ` Catalin Marinas
2026-04-27  6:16 ` [PATCH v4 2/2] coco: guest: arm64: Drop dummy RSI platform device stub Aneesh Kumar K.V (Arm)
2026-05-12 14:38   ` Catalin Marinas
2026-05-13  6:58     ` Aneesh Kumar K.V
2026-05-13  7:11       ` Greg KH [this message]
2026-05-13  8:53         ` Aneesh Kumar K.V
2026-05-13  9:51           ` Aneesh Kumar K.V
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=2026051352-albatross-contents-7113@gregkh \
    --to=gregkh@linuxfoundation.org \
    --cc=Suzuki.Poulose@arm.com \
    --cc=aneesh.kumar@kernel.org \
    --cc=catalin.marinas@arm.com \
    --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