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

[Conor.Dooley]

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@microchip.com>
>>
>> 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

> 
>> 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...

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.

Thanks,
Conor.