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

[Vladimir Oltean]

On Wed, Sep 01, 2021 at 02:38:15PM +0200, Michael Walle wrote:
> Am 2021-09-01 14:21, schrieb Vladimir Oltean:
> > 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.
> 
> Ok, I see. But shouldn't be the goal to make things easy and just copy
> the device tree to u-boot once in a while? Otherwise, we will eventually
> end up in the same mess as it is right now. Because well if they are
> different anyway, then "we can just add another small thing right here
> and there".

So if we "just add another small thing here and there", where that thing
is a comment, or a 'status = "disabled"' structured differently but to
the same result, does that land us in the "same mess" where half of the
peripherals, and networking, would not work in Linux with the U-Boot
provided DT?

> So yes, if you mean that by textual consistency, I care about that.

Okay.

> And about the lost/wrong comments. We should "fix"/add/reword them in
> linux, no?

In the case of SMMU ICIDs, it is a matter of perspective (bootloader vs
kernel). If the phrasing is generic enough to cover both perspectives,
I've no problem. In this case, after the initial reaction, I might even
be ok with the current phrasing of "/* fixed up by bootloader */". It is
not very clarifying, but not outright wrong either.
My larger point was that if we now swing in the opposite direction,
and can't make a common-sense decision before making it in Linux first,
and then waiting for the next merge window, that's.. strange?

Anyway, quite a storm in a teacup.