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

[Tom Rini]

On Wed, Sep 01, 2021 at 03:30:59PM +0200, Michael Walle wrote:
> 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.

It doesn't have to, especially if we get things in proper sync now.
There's a number of platforms that do regularly re-sync with the kernel.
It's also something that with a bit of CI work, we could also make sure
doesn't regress as well.  But that'll take some binding documentation
work to start with, along with updating / adding bindings upstream too.
But again, just doing an every kernel release re-sync to keep things
together is quite doable.

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 659 bytes
Desc: not available
URL: <https://lists.denx.de/pipermail/u-boot/attachments/20210901/807761ea/attachment.sig>