Re: [PATCH 0/3] Fix dt-validate issues on qemu dtbdumps due to dt-bindings

[Rob Herring]

On Mon, Aug 08, 2022 at 10:01:11PM +0000, Conor.Dooley@xxxxxxxxxxxxx wrote:
> On 08/08/2022 22:34, Jessica Clarke wrote:
> > On Fri, Aug 05, 2022 at 05:28:42PM +0100, Conor Dooley wrote:
> >> From: Conor Dooley <conor.dooley@xxxxxxxxxxxxx>
> >>
> >> The device trees produced automatically for the virt and spike machines
> >> fail dt-validate on several grounds. Some of these need to be fixed in
> >> the linux kernel's dt-bindings, but others are caused by bugs in QEMU.
> >>
> >> Patches been sent that fix the QEMU issues [0], but a couple of them
> >> need to be fixed in the kernel's dt-bindings. The first patches add
> >> compatibles for "riscv,{clint,plic}0" which are present in drivers and
> >> the auto generated QEMU dtbs.
> > 
> > IMO the correct thing is to have QEMU use a qemu,plicX rather than to
> > weaken the requirement that a non-generic compatible be used. Otherwise
> > you end up with QEMU using something that's marked as deprecated and
> > either the warning remains and annoys people still or it becomes too
> > weak and people ignore it when creating real hardware.
> 
> It's already in a driver so I figure it should be in the bindings too.
> 
> In arm's virt.c they use the generic gic compatible & I don't see any
> evidence of other archs using "qemu,foo" bindings. I suppose there's
> always the option of just removing the "riscv,plic0" from the riscv's
> virt.c

I think we're pretty much stuck with what's in use already.

I'm on the fence whether to mark it deprecated though if there is no 
plan to 'fix' it. Doesn't really matter until the tools can selectively 
remove deprecated properties from validation.

> >> The final patch adds some new ISA strings
> >> which needs scruitiny from someone with more knowledge about what ISA
> >> extension strings should be reported in a dt than I have.
> > 
> > Listing every possible ISA string supported by the Linux kernel really
> > is not going to scale...

How does the kernel scale? (No need to answer)

> Yeah, totally correct there. Case for adding a regex I suppose, but I
> am not sure how to go about handling the multi-letter extensions or
> if parsing them is required from a binding compliance point of view.
> Hoping for some input from Palmer really.

Yeah, looks like a regex pattern is needed.

Rob