[RFC PATCH 5/5] doc: Add a document for non-compliant DT node/property removal

[Ilias Apalodimas]

Hi Simon,

On Thu, 31 Aug 2023 at 05:50, Simon Glass <sjg at chromium.org> wrote:
>
> Hi Ilias,
>
> On Wed, 30 Aug 2023 at 01:25, Ilias Apalodimas
> <ilias.apalodimas at linaro.org> wrote:
> >
> > Hi Tom
> >
> > On Mon, 28 Aug 2023 at 21:39, Tom Rini <trini at konsulko.com> wrote:
> > >
> > > On Tue, Aug 29, 2023 at 12:04:53AM +0530, Sughosh Ganu wrote:

[...]

> > > >
> > > > Please re-read the document including the last link [1]. If you go
> > > > through that entire thread, you will notice that this is precisely
> > > > what Linaro was trying to do here -- upstream the binding for the
> > > > fwu-mdata node. It is only based on the feedback of the devicetree
> > > > maintainers that this patchset was required.
> > > >
> > > > -sughosh
> > > >
> > > > [1] - https://lore.kernel.org/u-boot/CAL_JsqJN4FeHomL7z3yj0WJ9bpx1oSE7zf26L_GV2oS6cg-5qg@mail.gmail.com/#t
> > >
> > > Please note that this right here, that the explanation of why we need to
> > > delete this node, not being a bright shiny visible object is one of the
> > > big problems with this patchset and implementation. It cannot be
> > > footnotes in email threads as to why such-and-such node/property isn't
> > > upstream, it needs to be documented and visible in the code base /
> > > documentation and an obvious you must do this for future cases.
> >
> > I thought we agreed that deleting nodes that won't be accepted
> > upstream is the right approach since that would break the systemready
> > 2.0 compatibility.
>
> Isn't that controlled by ARM/Linaros, as are the devicetree bindings?

The device tree validation happens through the dt schema validation.
You can read a bit more here [0]

> What am I missing? Let's just fix the bindings so they can be
> accepted.

I can go through the mailing lists, but I am pretty sure you've been
trying to do this for a number of years and got pushback for many of
those bindings.  Has that changed?  Can you guarantee to all the
vendors that all the bindings will get merged and they won't have a
problem getting their boards certified?

> What we decide here will have enormous repercussions in the
> future. SoC vendors are watching to see whether they should bother to
> upstream bindings or not.

How is that remotely relevant to the discussion we have here?  If it's
hardware that the OS has to use they *will* have to upstream it,
otherwise their device won't work with upstream kernels (not that they
care, I am just pointing it out).  If it's an internal thing they need
to perform an X action in U-Boot and the OS has no interest in that
property  (e.g. the driver model nodes), they can just get rid of it.

>
> >
> > Yes, it can't be footnotes or hidden links, but this is totally
> > different than what I am reading on this thread.
>
> Regards,
> Simon

[0] https://www.linaro.org/blog/tips-and-tricks-for-validating-devicetree-sources-with-the-devicetree-schema/

Thanks
/Ilias