On Wed, Nov 08, 2023 at 06:23:37AM -0800, Heinrich Schuchardt wrote: > 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.
My current thoughts are that in this case we could use U_BOOT_DRVINFO() like today and then have riscv_zkr_probe() be what checks the riscv,isa-extensions property for an appropriate match? This would mean we don't need any new nodes/compatibles/etc, and possibly not need any bootph- properties added either? I assume we don't need the RNG so early as for that to be an issue. -- Tom
signature.asc
Description: PGP signature
