On Mon, Jun 10, 2024 at 09:38:06AM -0700, Charlie Jenkins wrote: > On Mon, Jun 10, 2024 at 05:29:23PM +0100, Conor Dooley wrote: > > On Sun, Jun 09, 2024 at 09:45:07PM -0700, Charlie Jenkins wrote: > > > Add a property analogous to the vlenb CSR so that software can detect > > > the vector length of each CPU prior to it being brought online. > > > Currently software has to assume that the vector length read from the > > > boot CPU applies to all possible CPUs. On T-Head CPUs implementing > > > pre-ratification vector, reading the th.vlenb CSR may produce an illegal > > > instruction trap, so this property is required on such systems. > > > > > > Signed-off-by: Charlie Jenkins <charlie@xxxxxxxxxxxx> > > > --- > > > Documentation/devicetree/bindings/riscv/thead.yaml | 7 +++++++ > > > 1 file changed, 7 insertions(+) > > > > > > diff --git a/Documentation/devicetree/bindings/riscv/thead.yaml b/Documentation/devicetree/bindings/riscv/thead.yaml > > > index 301912dcd290..5e578df36ac5 100644 > > > --- a/Documentation/devicetree/bindings/riscv/thead.yaml > > > +++ b/Documentation/devicetree/bindings/riscv/thead.yaml > > > @@ -28,6 +28,13 @@ properties: > > > - const: sipeed,lichee-module-4a > > > - const: thead,th1520 > > > > > > +thead,vlenb: > > > > This needs to move back into cpus.yaml, this file documents root node > > compatibles (boards and socs etc) and is not for CPUs. If you want to > > restrict this to T-Head CPUs only, it must be done in cpus.yaml with > > a conditional `if: not: ... then: properties: thead,vlenb: false`. > > > > Please test your bindings. > > Now that I know `make dt_binding_check` exists I will use that in the > future! And in this case dtbs_check would also complain about riscv,vlenb being undocumented - and complain about thead,vlenb not being a permitted cpu property either. Thanks, Conor.
Attachment:
signature.asc
Description: PGP signature