From: Jason Gunthorpe <jgg@nvidia.com>
To: "Aneesh Kumar K.V" <aneesh.kumar@kernel.org>
Cc: linux-coco@lists.linux.dev, linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org,
Catalin Marinas <catalin.marinas@arm.com>,
Greg KH <gregkh@linuxfoundation.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>,
Steven Price <steven.price@arm.com>,
Suzuki K Poulose <Suzuki.Poulose@arm.com>,
Andre Przywara <andre.przywara@arm.com>
Subject: Re: [PATCH v9 2/7] firmware: hwrng: arm_smccc_trng: Register as an SMCCC device
Date: Sat, 29 Aug 2026 16:11:43 -0300 [thread overview]
Message-ID: <20260829191143.GC4157646@nvidia.com> (raw)
In-Reply-To: <yq5atsodtqt5.fsf@kernel.org>
On Sat, Aug 29, 2026 at 11:24:14AM +0530, Aneesh Kumar K.V wrote:
> Jason Gunthorpe <jgg@nvidia.com> writes:
>
> >> [ ... 58 lines skipped ... ]
> >> @@ -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;
> >
> > It feels like slightly poor practice to do this.. It is doing three
> > things:
> >
> > 1) ARM32 disables this entirely for some reason, shouldn't the bus do
> > it? Maybe it already does?
> >
>
> Why? The bus only checks whether the firmware function is supported and
> creates the device if it is. Further validation should be the driver's
> responsibility, shouldn't it?
I assume the reason is because the SMCCC call can't work at all on
ARM64? Like sashiko suggested perhaps? If so that is definately bus
code responsibility to filter out uncallable SMCCC's.
> > 3) Checks the version number
> >
> > Maybe the bus should capture the version output and pass it in as an
> > argument to probe so the driver can do the min version check directly?
>
> One of the earlier discussions suggested that the bus should only check
> whether the function ID is supported, rather than checking for an
> expected version or anything similar.
I'm not sure about that. If the versions are actually so different
that you want different drivers then having -v1/-v2 in the device
match is a reasonable design. ARM has made major ABI breakages before
like RMM v1/v2 that could motivate a two driver design like that.
> The other alternative discussed was a device-specific callback that
> would perform additional validation and create the device only when
> those conditions were met. It was dropped in favor of the simpler bus
> code above.
I wouldn't do that.. If the API allows capturing generically the
suported version then it could be passed in so it doesn't have to be
queried again. And maybe it could be used in a match someday if
necessary.
But it is no big deal, something to think about.
Jason
next prev parent reply other threads:[~2026-08-29 19:11 UTC|newest]
Thread overview: 31+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-05 6:32 [PATCH v9 0/7] Switch Arm SMCCC firmware services to an SMCCC bus Aneesh Kumar K.V (Arm)
2026-08-05 6:32 ` [PATCH v9 1/7] firmware: smccc: Add an Arm " Aneesh Kumar K.V (Arm)
2026-08-28 19:34 ` Jason Gunthorpe
2026-08-05 6:32 ` [PATCH v9 2/7] firmware: hwrng: arm_smccc_trng: Register as an SMCCC device Aneesh Kumar K.V (Arm)
2026-08-05 11:08 ` Catalin Marinas
2026-08-28 19:34 ` Jason Gunthorpe
2026-08-29 5:54 ` Aneesh Kumar K.V
2026-08-29 19:11 ` Jason Gunthorpe [this message]
2026-08-05 6:32 ` [PATCH v9 3/7] firmware: arm_rmm: Move RSI support out of arch/arm64 Aneesh Kumar K.V (Arm)
2026-08-05 11:21 ` Catalin Marinas
2026-08-05 13:05 ` Aneesh Kumar K.V
2026-08-10 10:03 ` Suzuki K Poulose
2026-08-28 19:34 ` Jason Gunthorpe
2026-08-29 5:58 ` Aneesh Kumar K.V
2026-08-05 6:32 ` [PATCH v9 4/7] arm64: realm: Move Realm memory encryption ops to RSI code Aneesh Kumar K.V (Arm)
2026-08-10 10:12 ` Suzuki K Poulose
2026-08-10 12:15 ` Aneesh Kumar K.V
2026-08-05 6:32 ` [PATCH v9 5/7] virt: coco: arm-cca-guest: Rename TSM report source file Aneesh Kumar K.V (Arm)
2026-08-28 19:34 ` Jason Gunthorpe
2026-08-29 6:02 ` Aneesh Kumar K.V
2026-08-29 19:07 ` Jason Gunthorpe
2026-08-05 6:32 ` [PATCH v9 6/7] firmware: smccc: arm-cca-guest: Bind the TSM provider to an SMCCC device Aneesh Kumar K.V (Arm)
2026-08-28 19:34 ` Jason Gunthorpe
2026-08-29 6:12 ` Aneesh Kumar K.V
2026-08-29 19:13 ` Jason Gunthorpe
2026-08-05 6:32 ` [PATCH v9 7/7] coco: guest: arm64: Replace dummy CCA device with sysfs ABI Aneesh Kumar K.V (Arm)
2026-08-28 19:34 ` Jason Gunthorpe
2026-08-05 9:51 ` [PATCH v9 0/7] Switch Arm SMCCC firmware services to an SMCCC bus Catalin Marinas
2026-08-05 12:22 ` Aneesh Kumar K.V
2026-08-10 9:35 ` Aneesh Kumar K.V
2026-08-10 10:24 ` Will Deacon
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=20260829191143.GC4157646@nvidia.com \
--to=jgg@nvidia.com \
--cc=Suzuki.Poulose@arm.com \
--cc=andre.przywara@arm.com \
--cc=aneesh.kumar@kernel.org \
--cc=catalin.marinas@arm.com \
--cc=gregkh@linuxfoundation.org \
--cc=jeremy.linton@arm.com \
--cc=jic23@kernel.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-coco@lists.linux.dev \
--cc=linux-kernel@vger.kernel.org \
--cc=lpieralisi@kernel.org \
--cc=mark.rutland@arm.com \
--cc=steven.price@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