From: swarren@wwwdotorg.org (Stephen Warren)
To: linux-arm-kernel@lists.infradead.org
Subject: [Ksummit-2013-discuss] [RFC] of: Allow for experimental device tree bindings
Date: Thu, 24 Oct 2013 23:26:19 +0100 [thread overview]
Message-ID: <52699E8B.3000305@wwwdotorg.org> (raw)
In-Reply-To: <20131023185114.GA7863@ulmo.nvidia.com>
On 10/23/2013 07:51 PM, Thierry Reding wrote:
> On Wed, Oct 23, 2013 at 05:05:32PM +0100, David Woodhouse wrote:
>> On Wed, 2013-10-23 at 17:06 +0200, Thierry Reding wrote:
>>> + /* check if binding is experimental */
>>> + if (dev != device || drv != driver) {
>>> + pr_warn("of: device %s (%s) uses an experimental binding\n",
>>> + np->name, np->full_name);
>>> +
>>
>> In the discussions earlier I think we decided that this should set a
>> taint flag too.
>
> A taint flag seems somewhat drastic. It's not like using an experimental
> binding should have an influence on the stability of the running kernel.
> I always thought that taint flags were supposed to flag conditions where
> code of unknown origin or code known to be broken was being executed
> because they may destabilize the running kernel.
>
> The worst that should happen if you run an experimental binding is that
> some part of the system will just not come up.
IIRC, the purpose of the taint flag was to make it clear that the kernel
or DT was not expected to function in the future, so don't be surpised
if you upgrade it, and it stops working, without you taking explicit
action, such as revising your DT to match the new kernel or vice-versa.
WARNING: multiple messages have this Message-ID (diff)
From: Stephen Warren <swarren-3lzwWm7+Weoh9ZMKESR00Q@public.gmane.org>
To: Thierry Reding
<thierry.reding-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>,
David Woodhouse <dwmw2-wEGCiKHe2LqWVfeAwA7xHQ@public.gmane.org>
Cc: 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 23:26:19 +0100 [thread overview]
Message-ID: <52699E8B.3000305@wwwdotorg.org> (raw)
In-Reply-To: <20131023185114.GA7863-AwZRO8vwLAwmlAP/+Wk3EA@public.gmane.org>
On 10/23/2013 07:51 PM, Thierry Reding wrote:
> On Wed, Oct 23, 2013 at 05:05:32PM +0100, David Woodhouse wrote:
>> On Wed, 2013-10-23 at 17:06 +0200, Thierry Reding wrote:
>>> + /* check if binding is experimental */
>>> + if (dev != device || drv != driver) {
>>> + pr_warn("of: device %s (%s) uses an experimental binding\n",
>>> + np->name, np->full_name);
>>> +
>>
>> In the discussions earlier I think we decided that this should set a
>> taint flag too.
>
> A taint flag seems somewhat drastic. It's not like using an experimental
> binding should have an influence on the stability of the running kernel.
> I always thought that taint flags were supposed to flag conditions where
> code of unknown origin or code known to be broken was being executed
> because they may destabilize the running kernel.
>
> The worst that should happen if you run an experimental binding is that
> some part of the system will just not come up.
IIRC, the purpose of the taint flag was to make it clear that the kernel
or DT was not expected to function in the future, so don't be surpised
if you upgrade it, and it stops working, without you taking explicit
action, such as revising your DT to match the new kernel or vice-versa.
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
next prev parent reply other threads:[~2013-10-24 22:26 UTC|newest]
Thread overview: 50+ 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 15:06 ` Thierry Reding
2013-10-23 16:05 ` [Ksummit-2013-discuss] " David Woodhouse
2013-10-23 16:05 ` David Woodhouse
2013-10-23 16:55 ` Guenter Roeck
2013-10-23 16:55 ` Guenter Roeck
2013-10-23 17:05 ` David Woodhouse
2013-10-23 17:05 ` David Woodhouse
2013-10-23 18:56 ` Thierry Reding
2013-10-23 18:56 ` Thierry Reding
2013-10-23 18:51 ` Thierry Reding
2013-10-23 18:51 ` Thierry Reding
2013-10-24 22:26 ` Stephen Warren [this message]
2013-10-24 22:26 ` Stephen Warren
2013-10-25 8:22 ` Thierry Reding
2013-10-25 8:22 ` Thierry Reding
2013-10-25 8:45 ` Stephen Warren
2013-10-25 8:45 ` Stephen Warren
2013-10-23 16:33 ` Stephen Warren
2013-10-23 16:33 ` Stephen Warren
2013-10-23 17:20 ` [Ksummit-2013-discuss] " Wolfram Sang
2013-10-23 17:20 ` Wolfram Sang
2013-10-23 18:59 ` Thierry Reding
2013-10-23 18:59 ` Thierry Reding
2013-10-23 19:34 ` Jason Gunthorpe
2013-10-23 19:34 ` Jason Gunthorpe
2013-10-23 19:58 ` Thierry Reding
2013-10-23 19:58 ` Thierry Reding
2013-10-23 21:08 ` Jason Gunthorpe
2013-10-23 21:08 ` Jason Gunthorpe
2013-10-24 8:04 ` Thierry Reding
2013-10-24 8:04 ` Thierry Reding
2013-10-24 17:32 ` Jason Gunthorpe
2013-10-24 17:32 ` Jason Gunthorpe
2013-10-23 21:13 ` Andy Lutomirski
2013-10-23 21:13 ` Andy Lutomirski
2013-10-23 19:40 ` Wolfram Sang
2013-10-23 19:40 ` Wolfram Sang
2013-10-23 20:05 ` Thierry Reding
2013-10-23 20:05 ` Thierry Reding
2013-10-24 8:34 ` Grant Likely
2013-10-24 8:34 ` Grant Likely
2013-10-24 8:50 ` Thierry Reding
2013-10-24 8:50 ` Thierry Reding
2013-10-24 20:26 ` Matt Sealey
2013-10-24 20:26 ` Matt Sealey
2013-10-24 22:29 ` Stephen Warren
2013-10-24 22:29 ` Stephen Warren
2013-10-24 18:39 ` jonsmirl at gmail.com
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=52699E8B.3000305@wwwdotorg.org \
--to=swarren@wwwdotorg.org \
--cc=linux-arm-kernel@lists.infradead.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.