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

[Michael Walle]

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 yes, if you mean that by textual consistency, I care
about that.

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

-michael