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

[Conor.Dooley]

On 09/08/2022 15:14, Rob Herring wrote:
> EXTERNAL EMAIL: Do not click links or open attachments unless you know the 
> content is safe
> 
> On Mon, Aug 08, 2022 at 10:01:11PM +0000, Conor.Dooley@microchip.com 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@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
> 
> 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.
> 

I guess I had considered "deprecated" to mean "don't use it in new
device trees" rather than "don't use it at all". I am not sure how it
could be "fixed" if it is potentially used by who-tf-knows-what.

I do think that adding the deprecated flag adds information in the
absence of tooling that responds to the property.

Thanks,
Conor.