[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Conor.Dooley
Subject: Re: [PATCH 0/3] Fix dt-validate issues on qemu dtbdumps due to dt-bindings
Date: Tue, 9 Aug 2022 17:25:28 +0000
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.11.0

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.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]