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.
