Re: [PATCH v9 2/7] firmware: hwrng: arm_smccc_trng: Register as an SMCCC device

[Jason Gunthorpe]

On Sat, Aug 29, 2026 at 11:24:14AM +0530, Aneesh Kumar K.V wrote:
> Jason Gunthorpe <jgg@xxxxxxxxxx> 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