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

[Michael Walle]

Am 2021-09-01 14:57, schrieb 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?

I said eventually. My fear is that otherwise it will slowly diverge
again, because nobody really cares to keep them in sync.
Like once, I've tried to make the sl28 board dts look the same in
u-boot and linux, but as soon as I saw how different they were, I just
changed it like u-boot was expecting it.
IMHO it's the small things that get bigger and bigger. I suspect
the device tree for the LS1028A looked very similar in linux and u-boot
in the beginning. It's just that the main development was going on
in linux and nobody cared to bring that back into u-boot.

Until there is something severly different we should have a greater
goal to keep things the same and for uboot specifics we have 
-u-boot.dtsi.
It's not that device trees are changed very often once there is has
binding documentation.

> 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?

That's not what I have in mind. No one is keeping you sending the
patch to both. Or maybe just to u-boot but you'd have to keep in mind
that it might be lost on a next sync if you didn't care to bring
it into linux - or if changes were suggested in linux, you'd need
to adapt u-boot afterwards.

-michael