Re: [PATCH v2 8/9] arm: dts: ls1028a: sync the fsl-ls1028a.dtsi with linux

From: Vladimir Oltean <vladimir.oltean@nxp.com>
To: Michael Walle <michael@walle.cc>
Cc: "u-boot@lists.denx.de" <u-boot@lists.denx.de>,
	Jagan Teki <jagan@amarulasolutions.com>,
	Priyanka Jain <priyanka.jain@nxp.com>,
	Tom Rini <trini@konsulko.com>,
	Peter Griffin <peter.griffin@linaro.org>,
	Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
Subject: Re: [PATCH v2 8/9] arm: dts: ls1028a: sync the fsl-ls1028a.dtsi with linux
Date: Wed, 1 Sep 2021 12:21:50 +0000	[thread overview]
Message-ID: <20210901122149.bpufsq7gzo3n73mk@skbuf> (raw)
In-Reply-To: <248b3bb606fa9a073a98adc0748656ad@walle.cc>

On Wed, Sep 01, 2021 at 02:05:34PM +0200, Michael Walle wrote:
> Am 2021-09-01 13:55, schrieb Vladimir Oltean:
> > On Wed, Sep 01, 2021 at 01:51:53PM +0200, Michael Walle wrote:
> > > Yes but that is on purpose. In the current u-boot device tree, it was
> > > disabled, but the boards reenabled them again. So it didn't matter.
> > > 
> > > I want to have a specific sync point (that is the v5.14 tag) for the
> > > .dtsi. At least where possible; for phy-mode and so on I needed to to
> > > take additional patches which weren't picked up in linux yet, but
> > > these just affect the sl28 board device trees.
> > 
> > Binary compatibility is one thing and I can understand it.
> > Textual compatibility, down to label names, and where the device is
> > being disabled from? Hmmmm, I'm having a hard time saying yes to that.
> 
> It's a step back, yes. But only until v5.16 (I don't think the changes
> will make it during the merge window). I guess you are concerned because
> of your vendor fork? Mh, well actually I don't understand your concert,
> because your tree isn't compatible anyway if we change the labels.

No, I don't care about "our vendor fork", it's been years since I've
stopped using that.

> We'd trade the clear information where the device tree is from for
> something that - in my opinion - is not worth it. I mean the device
> tree (source) is used just here in u-boot for these three boards and
> all have the usb nodes enabled.

My concern was actually much simpler: your v1 conversion of the label
names was buggy (see the LS1028A-QDS build breakage). You deleted a
bunch of comments which U-Boot had but Linux did not (luckily they did
not provide a lot of useful information anyway). You introduced some
comments which do not make sense for the U-Boot tree, because they were
in Linux: the ICIDs in the iommu-map being fixed up by the bootloader
(you can instead say that "we will fix these up for the operating system").
Again, not big issues, but if it would boil down to my common sense,
I'd focus more on the binary compatibility (after all, there will still
be U-Boot specifics, which will constitute textual differences, but
Linux will gladly ignore them, because this is what binary compatibility
is about), and if it is preferable to have status = 'disabled' in the
dtsi, and a patch was already sent to Linux but not yet accepted, I
would have kept U-Boot the way it was, and follow a model of
"eventual consistency".

If you still care more about textual consistency, I went through the patches
once already, so it's not like changing things now will make things easier,
or matter.