devicetree.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Thierry Reding <thierry.reding-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
To: Grant Likely <grant.likely-s3s/WqlpOiPyB63q8FvJNQ@public.gmane.org>
Cc: Wolfram Sang <wsa-z923LK4zBo2bacvFa/9K2g@public.gmane.org>,
	Stephen Warren <swarren-3lzwWm7+Weoh9ZMKESR00Q@public.gmane.org>,
	devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	ksummit-2013-discuss-cunTk1MwBs98uUxBSJOaYoYkZiVZrdSR2LY78lusg7I@public.gmane.org,
	linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org
Subject: Re: [Ksummit-2013-discuss] [RFC] of: Allow for experimental device tree bindings
Date: Thu, 24 Oct 2013 10:50:38 +0200	[thread overview]
Message-ID: <20131024085037.GA10650@ulmo.nvidia.com> (raw)
In-Reply-To: <20131024083459.48FE3C4039D-WNowdnHR2B42iJbIjFUEsiwD8/FfD2ys@public.gmane.org>

[-- Attachment #1: Type: text/plain, Size: 2519 bytes --]

On Thu, Oct 24, 2013 at 09:34:59AM +0100, Grant Likely wrote:
> On Wed, 23 Oct 2013 18:20:02 +0100, Wolfram Sang <wsa-z923LK4zBo2bacvFa/9K2g@public.gmane.org> wrote:
> > 
> > > Do we really want to polute the drivers and DT files with a ! in the
> > > compatible values? I thought we'd considered that, but chosen having the
> > > drivers that use unstable bindings depend on a Kconfig option as an
> > > alternative, not an additional step?
> > 
> > I'd even go further and use "unstable-" as the prefix instead of "!"
> > which is way more explicit.
> > 
> > 
> > > The one issue with doing this is that if a binding is thought to be
> > > unstable, but becomes stable later without any changes, we'll have to do
> > > busy-work to remove the ! in all the DT files, thus artificially
> > > introducing an incompatibility. Perhaps that's fine though?
> > 
> > I'd say yes. Going from unstable to stable is quite a step for a binding
> > and that should be visible and worth a patch IMO. Also, when looking at
> > a DTS file or some driver code, it will avoid
> > confusion/misinterpretation if one can see immediately the status of a
> > binding.
> 
> No, it shouldn't. Going from unstable to stable is not a large step,
> rather it is coming to the point of looking around and realizing that
> the binding is working quite well.

Yes, the difference between the unstable binding before it is declared
stable and the stable one shouldn't be big. In fact it should be no
different at all.

However the decision is still a conscious one. And it is a big step,
because when you declare it stable you assert that it will never change
in an incompatible way.

> I don't think the solution is to put this into the kernel to be checked
> at runtime. The better solution is to put it into DTC and make it
> complain (either warn or error; depending on build config?) about usage
> of compatible strings that are marked in the binding documentation as
> unstable.

Perhaps. Doing it in the kernel seemed easier. Furthermore not every
user might generate their own DTB and whoever generates the DTB may not
make the same choice as every user might have made. Granted, that might
be a little far fetched.

I personally don't mind where exactly it is checked for, as long as we
can settle on something. What I'm primarily concerned about is that the
current situation hinders progress and early adoption, which I consider
both essential for upstream Linux development.

Thierry

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

  parent reply	other threads:[~2013-10-24  8:50 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-10-23 15:06 [RFC] of: Allow for experimental device tree bindings Thierry Reding
2013-10-23 16:05 ` [Ksummit-2013-discuss] " David Woodhouse
     [not found]   ` <1382544332.8522.40.camel-Fexsq3y4057IgHVZqg5X0TlWvGAXklZc@public.gmane.org>
2013-10-23 16:55     ` Guenter Roeck
     [not found]       ` <20131023165512.GB22394-0h96xk9xTtrk1uMJSBkQmQ@public.gmane.org>
2013-10-23 17:05         ` David Woodhouse
     [not found]           ` <1382547916.8522.42.camel-Fexsq3y4057IgHVZqg5X0TlWvGAXklZc@public.gmane.org>
2013-10-23 18:56             ` Thierry Reding
2013-10-23 18:51     ` Thierry Reding
     [not found]       ` <20131023185114.GA7863-AwZRO8vwLAwmlAP/+Wk3EA@public.gmane.org>
2013-10-24 22:26         ` Stephen Warren
     [not found]           ` <52699E8B.3000305-3lzwWm7+Weoh9ZMKESR00Q@public.gmane.org>
2013-10-25  8:22             ` Thierry Reding
     [not found]               ` <20131025082229.GD19622-AwZRO8vwLAwmlAP/+Wk3EA@public.gmane.org>
2013-10-25  8:45                 ` Stephen Warren
     [not found] ` <1382540779-6334-1-git-send-email-treding-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
2013-10-23 16:33   ` Stephen Warren
     [not found]     ` <5267FA58.9050002-3lzwWm7+Weoh9ZMKESR00Q@public.gmane.org>
2013-10-23 17:20       ` [Ksummit-2013-discuss] " Wolfram Sang
2013-10-23 18:59         ` Thierry Reding
     [not found]           ` <20131023185909.GC7863-AwZRO8vwLAwmlAP/+Wk3EA@public.gmane.org>
2013-10-23 19:34             ` Jason Gunthorpe
     [not found]               ` <20131023193450.GE32563-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org>
2013-10-23 19:58                 ` Thierry Reding
2013-10-23 21:08                   ` Jason Gunthorpe
     [not found]                     ` <20131023210849.GB2912-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org>
2013-10-24  8:04                       ` Thierry Reding
2013-10-24 17:32                         ` Jason Gunthorpe
2013-10-23 21:13                   ` Andy Lutomirski
2013-10-23 19:40             ` Wolfram Sang
2013-10-23 20:05               ` Thierry Reding
2013-10-24  8:34         ` Grant Likely
     [not found]           ` <20131024083459.48FE3C4039D-WNowdnHR2B42iJbIjFUEsiwD8/FfD2ys@public.gmane.org>
2013-10-24  8:50             ` Thierry Reding [this message]
2013-10-24 20:26             ` Matt Sealey
2013-10-24 22:29             ` Stephen Warren
2013-10-24 18:39   ` jonsmirl-Re5JQEeQqe8AvxtiuMwx3w

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=20131024085037.GA10650@ulmo.nvidia.com \
    --to=thierry.reding-re5jqeeqqe8avxtiumwx3w@public.gmane.org \
    --cc=devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    --cc=grant.likely-s3s/WqlpOiPyB63q8FvJNQ@public.gmane.org \
    --cc=ksummit-2013-discuss-cunTk1MwBs98uUxBSJOaYoYkZiVZrdSR2LY78lusg7I@public.gmane.org \
    --cc=linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org \
    --cc=swarren-3lzwWm7+Weoh9ZMKESR00Q@public.gmane.org \
    --cc=wsa-z923LK4zBo2bacvFa/9K2g@public.gmane.org \
    /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).