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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Tue, 9 Aug 2022 17:25:28 +0000
From:   <Conor.Dooley@...rochip.com>
To:     <robh@...nel.org>
CC:     <jrtc27@...c27.com>, <tglx@...utronix.de>, <maz@...nel.org>,
        <krzysztof.kozlowski+dt@...aro.org>, <palmer@...belt.com>,
        <paul.walmsley@...ive.com>, <aou@...s.berkeley.edu>,
        <daniel.lezcano@...aro.org>, <anup@...infault.org>,
        <guoren@...nel.org>, <sagar.kadam@...ive.com>,
        <linux-kernel@...r.kernel.org>, <devicetree@...r.kernel.org>,
        <linux-riscv@...ts.infradead.org>, <qemu-riscv@...gnu.org>
Subject: Re: [PATCH 0/3] Fix dt-validate issues on qemu dtbdumps due to
 dt-bindings

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