From: andre.przywara@arm•com (Andre Przywara)
To: linux-arm-kernel@lists•infradead.org
Subject: breaking DT compatibility
Date: Wed, 10 Feb 2016 16:14:34 +0000 [thread overview]
Message-ID: <56BB61EA.1030805@arm.com> (raw)
In-Reply-To: <20160210143755.GE31506@lukather>
Hi,
On 10/02/16 14:37, Maxime Ripard wrote:
> Hi Rob,
>
> 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@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?
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).
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.
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.
>> 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.
> It also seems that even on well documented platforms, supported by the
> vendors, the stable ABI dream is not going to happen:
> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/Documentation/arm/Atmel/README#n105
> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/Documentation/devicetree/bindings/arm/marvell,berlin.txt#n4
I find those two statements really unfortunate ...
> If it makes things clearer, I can also add such a statement.
and would rather see us referring solely to this document instead:
Documentation/devicetree/bindings/ABI.txt
Cheers,
Andre.
>>> Also I think one needs ACKs from DT maintainers before merging something
>>> in the respective directories, which I don't see here.
>>
>> It can go in with subsystem maintainers ack, but there are problems
>> with this one regardless of compatibility.
>>
>>> As I am somewhat blocked on that patch, I'd like to have some discussion
>>> on the list.
>>>
>>> Thanks,
>>> Andre.
>>>
>>> On 05/02/16 17:59, Andre Przywara wrote:
>>>> Hi Maxime,
>>>>
>>>> just found this while looking at your current git branch, so sorry for
>>>> the late reply.
>>>>
>>>> CC:ing DT people, since you touch both existing DTs(!) and the binding doc.
>>>>
>>>> On 01/02/16 20:20, Maxime Ripard wrote:
>>>>> Remove the fixed dividers from the PLL6 driver to be able to have a
>>>>> reusable driver that can be used across several SoCs that share the same
>>>>> controller, but don't have the same set of dividers for this clock, and to
>>>>> also be reused multiple times in the same SoC, since we're droping the
>>>>> clock name.
>>
>> Removing a compatible name or not has nothing to do with sharing code.
>
> This was not about the compatible name, but the hardcoded name in our
> structure associated to that compatible. And since we can't register
> two clocks with the same name, we couldn't use the same compatible
> several times.
>
> Maxime
>
next prev parent reply other threads:[~2016-02-10 16:14 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-02-01 20:20 [PATCH v4] clk: sunxi: Refactor A31 PLL6 so that it can be reused Maxime Ripard
2016-02-04 12:05 ` Maxime Ripard
2016-02-04 15:25 ` Jean-Francois Moine
2016-02-10 12:53 ` Maxime Ripard
2016-02-10 17:04 ` Jean-Francois Moine
2016-02-11 9:53 ` Maxime Ripard
2016-02-05 17:59 ` Andre Przywara
2016-02-10 12:30 ` breaking DT compatibility (was: Re: [PATCH v4] clk: sunxi: Refactor A31 PLL6 so that it can be reused) Andre Przywara
2016-02-10 13:42 ` Rob Herring
2016-02-10 14:37 ` Maxime Ripard
2016-02-10 14:45 ` Arnd Bergmann
2016-02-10 16:14 ` Andre Przywara [this message]
2016-02-11 10:16 ` breaking DT compatibility Maxime Ripard
2016-02-10 16:30 ` breaking DT compatibility (was: Re: [PATCH v4] clk: sunxi: Refactor A31 PLL6 so that it can be reused) Mark Rutland
2016-02-11 10:00 ` Maxime Ripard
2016-02-11 11:44 ` Mark Rutland
2016-02-11 12:29 ` breaking DT compatibility Andre Przywara
2016-02-11 17:08 ` breaking DT compatibility (was: Re: [PATCH v4] clk: sunxi: Refactor A31 PLL6 so that it can be reused) Maxime Ripard
2016-02-12 9:40 ` Lucas Stach
2016-02-16 8:44 ` Maxime Ripard
2016-02-16 19:40 ` Michael Turquette
2016-02-11 14:51 ` Richard Cochran
2016-02-11 15:16 ` breaking DT compatibility Andre Przywara
2016-02-11 21:46 ` breaking DT compatibility (was: Re: [PATCH v4] clk: sunxi: Refactor A31 PLL6 so that it can be reused) Rob Herring
2016-02-10 12:59 ` [PATCH v4] clk: sunxi: Refactor A31 PLL6 so that it can be reused Maxime Ripard
2016-02-10 14:02 ` Rob Herring
2016-02-11 9:41 ` Maxime Ripard
2016-02-10 18:41 ` Mark Rutland
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=56BB61EA.1030805@arm.com \
--to=andre.przywara@arm$(echo .)com \
--cc=linux-arm-kernel@lists$(echo .)infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox