Re: [PATCH v2 4/8] hw/arm/virt: Fix devicetree warning about the gpio-key node

From: Peter Maydell <peter.maydell@linaro.org>
To: Rob Herring <robh+dt@kernel.org>
Cc: Jean-Philippe Brucker <jean-philippe@linaro.org>,
	qemu-arm@nongnu.org,  QEMU Developers <qemu-devel@nongnu.org>
Subject: Re: [PATCH v2 4/8] hw/arm/virt: Fix devicetree warning about the gpio-key node
Date: Fri, 14 Oct 2022 12:37:48 +0100	[thread overview]
Message-ID: <CAFEAcA9OWDiWh3S=0Co7Z27EtOp-1B9H7FxyQy1T2sFnTyNdqA@mail.gmail.com> (raw)
In-Reply-To: <CAL_Jsq+nw2g4fDr4-G3g2OL_mUkAGvNM0DJjuKqzFUijut1Hsw@mail.gmail.com>

On Thu, 13 Oct 2022 at 22:47, Rob Herring <robh+dt@kernel.org> wrote:
>
> On Tue, Sep 27, 2022 at 6:56 AM Peter Maydell <peter.maydell@linaro.org> wrote:
> > Please don't retrospectively make perfectly valid working DTs
> > non-valid. I don't see any reason to change QEMU here.
> >
> > More generally, the set of things you might want the
> > validator to warn about for a fresh new human-written DTB
> > doesn't necessarily correspond to the set of things you want
> > to enforce for a pre-existing code-generated DTB. For the
> > former it makes much more sense to impose "coding style"
> > and "naming convention" type rules.
>
> I too would like to distinguish that, but haven't come up with a way
> to do that in json-schema yet. The way schemas are applied
> independently makes that a challenge. So far it's been low on the
> priority list as any platforms with few enough warnings to get to 0
> haven't been a problem to fix (in a few cases we do end up relaxing
> the schemas).
>
> On the flip side, even existing things eventually get updated for
> coding style or evolving conventions. As long as we don't break ABIs,
> the same should apply to DT.

Yeah, but from QEMU's point of view pretty much the whole DT
*is* ABI, because we have no idea what the guest will be
doing with it, whether it is looking for things in the
"correct" way or if it happens to have hard-coded a node
name or similar: and the guest could be any of a wide
variety of operating systems or custom code, and including
pretty old versions of OSes as well as the latest-and-greatest.
This is different from Linux's handwritten device trees,
which only need to work with Linux and only with the associated
Linux version, at that. So the set of things I'm happy changing
tends to be more restricted than the set of things it's worth
cleaning up in the dt sources that ship with the kernel.

thanks
-- PMM