[PATCH v3 0/2] rng: Provide a RNG based on the RISC-V Zkr ISA extension

[Heinrich Schuchardt]

On 11/7/23 16:34, Tom Rini wrote:
> On Wed, Nov 08, 2023 at 12:29:03AM +0000, Conor Dooley wrote:
>> On Tue, Nov 07, 2023 at 06:23:05PM -0500, Tom Rini wrote:
> [snip]
>>> Thanks. Setting aside Simon's follow-up, this is what I was looking for.
>>> We might have to wait for Heinrich to return from the conference to have
>>> time to look at how to utilize the above and see what we can do from
>>> there.
>>
>> I did read that, but I don't think most of it is relevant to the binding
>> itself. His five things were:
>> | - U-Boot models hardware (and other things) as devices in driver model [1]
>>
>> This I think should be satisfied. The Zkr CSR is a property of the CPU,
>> and shouldn't have its own DT node IMO. Is it problematic for U-Boot to
>> populate multiple devices for its driver model based on one DT node?

Devices in U-Boot are bound on the basis of a compatible string. All 
RISC-V CPU nodes have a compatible string 'riscv' but that does not 
provide any information about the existence of the Zkr extension. That 
information is in the 'riscv,isa-extensions' property of the cpu nodes 
(see Documentation/devicetree/bindings/riscv/cpus.yaml).

>> I know in Linux that I can create devices using something like
>> platform_device_register(), does U-Boot have a similar facility?

This is what the U_BOOT_DRVINFO() macro in my driver does and which 
Simon discourages.

The discussion boils down to whether U-Boot can force every M-mode 
firmware invoking it to provide a compatible string for Zkr if the 
extension is provided (or to be more restrictive if mseccfg.sseed is set 
to 1).

I would prefer to avoid duplicate encoding of RISC-V extensions in the 
device-tree.

>> https://elixir.bootlin.com/linux/latest/source/drivers/base/platform.c#L767
>>
>> | - U-Boot requires devices to be in the devicetree, with very limited
>> | exceptions [2]
>>
>> | - Where multiple devices exist in a uclass, it is desirable to be able
>> | to number them [3]
>>
>> I'm not sure really how this one ties in. Do you need a number for each
>> CPU that supports Zkr, since a system may be heterogeneous? I think that
>> how you treat things like that is beyond communicating support via DT
>> though, IMO the job of the DT is just to tell U-Boot on which CPUs it
>> can access the seed CSR.

U-Boot only uses a single hart. It is for this specific hart that we 
need to find out if the seed register provided by the Zkr extension is 
readable. The register is only readable if additionally the 
mseccfg.sseed bit is set by machine mode firmware.

Thus any additional device-tree node related to the Zkr extension would 
have to be provided per Zkr enabled 'cpu' device-tree node.

Best regards

Heinrich

>>
>> | - Similarly it is useful to be able select a particular device, e.g.
>> | with a phandle [4]
>>
>> I suppose a phandle to the CPU would work in this case.
>>
>> | - U-Boot uses devicetree for configuration as it has no userspace
> 
> I mean, the reason I was setting aside Simon's question is that in my
> mind, we (U-Boot) need to think about what we're declaring as a MUST
> because the constant feedback that we get is "No, why does that need to
> get added to DT? Can't you just use ... ?". So I do find your answers
> above enlightening in that regard.
>