linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
To: Andrew Lunn <andrew@lunn.ch>
Cc: Antoine Tenart <antoine.tenart@free-electrons.com>,
	zmxu@marvell.com, jszhang@marvell.com, mturquette@linaro.org,
	sboyd@codeaurora.org, linux-kernel@vger.kernel.org,
	linux-arm-kernel@lists.infradead.org,
	sebastian.hesselbarth@gmail.com
Subject: Re: [PATCH 0/7] ARM: berlin: refactor the clock
Date: Fri, 13 Feb 2015 19:19:28 +0100	[thread overview]
Message-ID: <20150213191928.20f79ebf@free-electrons.com> (raw)
In-Reply-To: <20150213173121.GG26475@lunn.ch>

Dear Andrew Lunn,

On Fri, 13 Feb 2015 18:31:21 +0100, Andrew Lunn wrote:

> Something which needs to be discussed for both this patchset and the
> previous one, is backwards compatibility of the device tree.
> 
> As far as i can see, these changes are not backwards compatible.
> Somebody trying to boot a new kernel with a old DT blob is going to
> have trouble.
> 
> How do we want to handle this?

I think one thing that should really be taken into account here is that
we have basically no usable datasheet for those SoCs. We only have very
partial datasheets, and only fairly a vendor kernel tree. This makes it
nearly impossible to have from the start up a clear picture of the
hardware layout and how it should be represented in the DT. Antoine,
and I guess Sebastian as well, are discovering progressively the layout
of the registers, their functionality, depending on the features that
are enabled.

The DT backward compatibility requirement essentially requires either:

 * A very clear picture of the hardware from the beginning, so that we
   can be pretty sure when designing the first DT binding, that it is
   going to be alright. This is clearly not something we have for the
   Marvell Berlin platforms.

 * Keep vast amount of legacy code to support old DTs, which nobody is
   every going to test, which means that such code is guaranteed to
   bitrot within 2 or 3 kernel releases, if not earlier.

Instead, since I believe at this point Marvell doesn't care about DT
backward compatibility for its platforms, could we instead declare the
DT bindings of this platform as "unstable", just like the AT91 guys did
for their DT bindings
(http://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/tree/Documentation/arm/Atmel/README#n100) ?

Best regards,

Thomas Petazzoni
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

  parent reply	other threads:[~2015-02-13 18:19 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-02-13 16:42 [PATCH 0/7] ARM: berlin: refactor the clock Antoine Tenart
2015-02-13 16:42 ` [PATCH 1/7] clk: convert clock mux to accept regmap Antoine Tenart
2015-02-13 16:42 ` [PATCH 2/7] clk: convert clock gate " Antoine Tenart
2015-02-13 16:42 ` [PATCH 3/7] clk: berlin: use regmap Antoine Tenart
2015-02-13 16:42 ` [PATCH 4/7] Documentation: bindings: move the Berlin clock documentation Antoine Tenart
2015-02-13 16:42 ` [PATCH 5/7] ARM: berlin: rework the clock node for BG2 Antoine Tenart
2015-02-13 16:43 ` [PATCH 6/7] ARM: berlin: rework the clock node for BG2CD Antoine Tenart
2015-02-13 16:43 ` [PATCH 7/7] ARM: berlin: rework the clock node for BG2Q Antoine Tenart
2015-02-13 17:31 ` [PATCH 0/7] ARM: berlin: refactor the clock Andrew Lunn
2015-02-13 18:04   ` Antoine Tenart
2015-02-13 18:19   ` Thomas Petazzoni [this message]
2015-02-13 18:33     ` Sebastian Hesselbarth
2015-02-13 19:22       ` Andrew Lunn
2015-02-16  3:37 ` Jisheng Zhang
2015-02-16  3:46   ` Jisheng Zhang
2015-02-16 11:05   ` Sebastian Hesselbarth

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=20150213191928.20f79ebf@free-electrons.com \
    --to=thomas.petazzoni@free-electrons.com \
    --cc=andrew@lunn.ch \
    --cc=antoine.tenart@free-electrons.com \
    --cc=jszhang@marvell.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mturquette@linaro.org \
    --cc=sboyd@codeaurora.org \
    --cc=sebastian.hesselbarth@gmail.com \
    --cc=zmxu@marvell.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
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;
as well as URLs for NNTP newsgroup(s).