breaking DT compatibility

[Maxime Ripard]

On Wed, Feb 10, 2016 at 04:14:34PM +0000, Andre Przywara wrote:
> > On Wed, Feb 10, 2016 at 07:42:02AM -0600, Rob Herring wrote:
> >> On Wed, Feb 10, 2016 at 6:30 AM, Andre Przywara <andre.przywara at arm.com> wrote:
> >>> Hi,
> >>>
> >>> just a ping:
> >>>
> >>> Are we really OK with breaking existing DTs in 4.6? (per the code in
> >>> -next: f7d372ba54ea04d528a291b8dbe34716507bb60b, which is this patch).
> >>
> >> I only warn and make sure people are aware of the issue. I leave that
> >> up to platform maintainers to decide. It depends on the maturity of
> >> the platform and users.
> > 
> > The impacted SoCs support is really partial. For the most supported
> > one, big things like display or sound are totally missing, and we
> > still update them on a regular basis to add support for new
> > devices. As such, users are very likely to upgrade the DT from one
> > version to another just because there's new devices available to
> > them. And the newest SoC impacted just got introduced in 4.5, and only
> > has the UART and MMC devices available.
> 
> But I still don't see why we have to break things - can't we just
> improve support _without_ breaking compatibility? For instance keeping
> the old behaviour around? I can dig out my old x86 hat and find a
> _compatible_ solution for this, if you prefer ;-)
> Actually doesn't Jean-Francois' patch fixes the PLL8 issue without
> breaking anything?

Are you convinced that merging code that is not going to be used or
tested (and thus maintained) by anyone is a good idea?

Using X86 as an example is quite funny, since I remember on a few
occasions having to reflash my BIOS/UEFI to fix some issues in Linux
(and as it turns out, the last occurence was two weeks ago).

> Also were do you want to draw the line for "partial support"? The
> sun6i-a31.dtsi is around since 3.12, which was released more than 2
> years ago.
> If we want to wait for "stabilization", we will probably wait forever. I
> find discussions about DT stabilization going back to the very beginning
> of DT for ARM - as well as the request for moving the DT bindings out of
> the kernel (which I think we should really eventually do now).

I'd say when we have merged everything that makes it work as it was
intented to?

In this case, it's a multimedia SoCs. So I'd draw the line at once we
had display, sound and VPU. Display is coming, sound seems to be
gaining traction lately, so that doesn't sound that far off.

> Frankly I don't care so much about these particular boards, but just
> want avoid to set a bad example for the future - in particular sneaking
> this behaviour into the arm64 world, where DTs _really_ come with the
> board or are even generated by the (UEFI-)firmware.

Ok, that's a good thing to know, and we'll make sure it won't
happen. What's the policy when the provided DT comes from a vendor in
that case?

> U-Boot already can embed a device tree, sounds like a perfect place to
> have it stored for me - as long as there is _one_ best version of it.

So far, they've been using their own, with some custom properties that
were rejected last time they were submitted.

http://lists.infradead.org/pipermail/linux-rpi-kernel/2015-August/002122.html

So I'm a bit pessimistic about that.

> >> If people complain about it then it's their mess. For platforms
> >> supported in distros such as debian or fedora, I would strongly
> >> recommend against breaking compatibility.
> > 
> > None of them are officially supported:
> > https://www.debian.org/releases/stable/armhf/ch02s01.html.en
> > https://fedoraproject.org/wiki/Architectures/ARM#Fedora_23
> > 
> > Only the older one are, and they are not affected by this patch.
> > 
> >> They do ship dtbs, but it's a chicken and egg problem. If dtbs were
> >> stable and provided by firmware, then they wouldn't have to provide
> >> them. If dtbs are unstable, then they have no choice.
> > 
> > And while it might work great on platforms that have all the needed
> > documentation, or a perfect one, which is our case. Almost each
> > release, we discover that something is not working as it was
> > documented, when it was documented in the first place.
> 
> I understand that it's not an ideal situation for those Allwinner
> chips - but nevertheless I would like us to at least _try_ to comply
> with this idea. As said before: this patch is a nice rework/cleanup
> - but definitely not a good reason to break compatibility.

To be fair, I really want to tend to keep a DT ABI as stable as
possible. I just don't want to commit to it. If it comes in the way of
a nice rework/cleanup, then it shouldn't matter.

But that doesn't make me want to break everything every kernel release
either.

Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20160211/02d8c8a3/attachment.sig>