All of lore.kernel.org
 help / color / mirror / Atom feed
From: Rob Herring <robherring2@gmail.com>
To: Frank Rowand <frowand.list@gmail.com>
Cc: Pantelis Antoniou <pantelis.antoniou@konsulko.com>,
	Grant Likely <grant.likely@secretlab.ca>,
	"devicetree@vger.kernel.org" <devicetree@vger.kernel.org>,
	Tony Lindgren <tony@atomide.com>,
	Koen Kooi <koen@dominion.thruhere.net>,
	Nicolas Ferre <nicolas.ferre@atmel.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Ludovic Desroches <ludovic.desroches@atmel.com>,
	"linux-arm-kernel@lists.infradead.org" 
	<linux-arm-kernel@lists.infradead.org>,
	Pantelis Antoniou <panto@antoniou-consulting.com>,
	Matt Porter <matt.porter@linaro.org>,
	Guenter Roeck <linux@roeck-us.net>
Subject: Re: [PATCH 2/4] of: DT quirks infrastructure
Date: Thu, 19 Feb 2015 12:01:14 -0600	[thread overview]
Message-ID: <CAL_JsqKT3+URcad6X=i+73NLRnVstbpvFJxxT=ru7KJmp_XuVQ@mail.gmail.com> (raw)
In-Reply-To: <54E54586.5070602@gmail.com>

On Wed, Feb 18, 2015 at 8:08 PM, Frank Rowand <frowand.list@gmail.com> wrote:
> On 2/18/2015 6:59 AM, Pantelis Antoniou wrote:
>> Implement a method of applying DT quirks early in the boot sequence.
>>
>> A DT quirk is a subtree of the boot DT that can be applied to
>> a target in the base DT resulting in a modification of the live
>> tree. The format of the quirk nodes is that of a device tree overlay.
>
> The use of the word "quirk" is a different mental model for me than what
> this patch series appears to be addressing.  I would suggest totally
> removing the word "quirk" from this proposal to avoid confusing the
> mental models of future generations of kernel folks.

This comes from me as quirks are a different usecase I had in mind,
but one that could use a similar mechanism. Although, in the case of
quirks, I would expect them to be overlays built into the kernel. It
would be more a way to update old dtbs.

> What this patch series seems to be proposing is a method to apply DT
> overlays as soon as unflatten_device_tree() completes.  In other words,
> making the device tree a dynamic object, that is partially defined by
> the kernel during boot.  Well, to be fair, the kernel chooses among
> several possible alternatives encoded in the DT blob.  So the device
> tree is no longer a static object that describes the hardware of the
> system.  It may not sound like a big deal, but it seems to me to be
> a fundamental shift in what the device tree blob is.  Something that
> should be thought about carefully and not just applied as a patch to
> solve a point problem.

I agree. I would not want to see every board for an SOC become an
overlay for example. I think it has to be limited to truly plugable
h/w (e.g. capes) or minor changes. We just have to define what is
minor. :)

Rob

WARNING: multiple messages have this Message-ID (diff)
From: Rob Herring <robherring2-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
To: Frank Rowand <frowand.list-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Cc: Pantelis Antoniou
	<pantelis.antoniou-OWPKS81ov/FWk0Htik3J/w@public.gmane.org>,
	Grant Likely
	<grant.likely-s3s/WqlpOiPyB63q8FvJNQ@public.gmane.org>,
	"devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org"
	<devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
	Tony Lindgren <tony-4v6yS6AI5VpBDgjK7y7TUQ@public.gmane.org>,
	Koen Kooi
	<koen-QLwJDigV5abLmq1fohREcCpxlwaOVQ5f@public.gmane.org>,
	Nicolas Ferre
	<nicolas.ferre-AIFe0yeh4nAAvxtiuMwx3w@public.gmane.org>,
	"linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org"
	<linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
	Ludovic Desroches
	<ludovic.desroches-AIFe0yeh4nAAvxtiuMwx3w@public.gmane.org>,
	"linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org"
	<linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org>,
	Pantelis Antoniou
	<panto-wVdstyuyKrO8r51toPun2/C9HSW9iNxf@public.gmane.org>,
	Matt Porter <matt.porter-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>,
	Guenter Roeck <linux-0h96xk9xTtrk1uMJSBkQmQ@public.gmane.org>
Subject: Re: [PATCH 2/4] of: DT quirks infrastructure
Date: Thu, 19 Feb 2015 12:01:14 -0600	[thread overview]
Message-ID: <CAL_JsqKT3+URcad6X=i+73NLRnVstbpvFJxxT=ru7KJmp_XuVQ@mail.gmail.com> (raw)
In-Reply-To: <54E54586.5070602-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>

On Wed, Feb 18, 2015 at 8:08 PM, Frank Rowand <frowand.list-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> On 2/18/2015 6:59 AM, Pantelis Antoniou wrote:
>> Implement a method of applying DT quirks early in the boot sequence.
>>
>> A DT quirk is a subtree of the boot DT that can be applied to
>> a target in the base DT resulting in a modification of the live
>> tree. The format of the quirk nodes is that of a device tree overlay.
>
> The use of the word "quirk" is a different mental model for me than what
> this patch series appears to be addressing.  I would suggest totally
> removing the word "quirk" from this proposal to avoid confusing the
> mental models of future generations of kernel folks.

This comes from me as quirks are a different usecase I had in mind,
but one that could use a similar mechanism. Although, in the case of
quirks, I would expect them to be overlays built into the kernel. It
would be more a way to update old dtbs.

> What this patch series seems to be proposing is a method to apply DT
> overlays as soon as unflatten_device_tree() completes.  In other words,
> making the device tree a dynamic object, that is partially defined by
> the kernel during boot.  Well, to be fair, the kernel chooses among
> several possible alternatives encoded in the DT blob.  So the device
> tree is no longer a static object that describes the hardware of the
> system.  It may not sound like a big deal, but it seems to me to be
> a fundamental shift in what the device tree blob is.  Something that
> should be thought about carefully and not just applied as a patch to
> solve a point problem.

I agree. I would not want to see every board for an SOC become an
overlay for example. I think it has to be limited to truly plugable
h/w (e.g. capes) or minor changes. We just have to define what is
minor. :)

Rob
--
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

WARNING: multiple messages have this Message-ID (diff)
From: robherring2@gmail.com (Rob Herring)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 2/4] of: DT quirks infrastructure
Date: Thu, 19 Feb 2015 12:01:14 -0600	[thread overview]
Message-ID: <CAL_JsqKT3+URcad6X=i+73NLRnVstbpvFJxxT=ru7KJmp_XuVQ@mail.gmail.com> (raw)
In-Reply-To: <54E54586.5070602@gmail.com>

On Wed, Feb 18, 2015 at 8:08 PM, Frank Rowand <frowand.list@gmail.com> wrote:
> On 2/18/2015 6:59 AM, Pantelis Antoniou wrote:
>> Implement a method of applying DT quirks early in the boot sequence.
>>
>> A DT quirk is a subtree of the boot DT that can be applied to
>> a target in the base DT resulting in a modification of the live
>> tree. The format of the quirk nodes is that of a device tree overlay.
>
> The use of the word "quirk" is a different mental model for me than what
> this patch series appears to be addressing.  I would suggest totally
> removing the word "quirk" from this proposal to avoid confusing the
> mental models of future generations of kernel folks.

This comes from me as quirks are a different usecase I had in mind,
but one that could use a similar mechanism. Although, in the case of
quirks, I would expect them to be overlays built into the kernel. It
would be more a way to update old dtbs.

> What this patch series seems to be proposing is a method to apply DT
> overlays as soon as unflatten_device_tree() completes.  In other words,
> making the device tree a dynamic object, that is partially defined by
> the kernel during boot.  Well, to be fair, the kernel chooses among
> several possible alternatives encoded in the DT blob.  So the device
> tree is no longer a static object that describes the hardware of the
> system.  It may not sound like a big deal, but it seems to me to be
> a fundamental shift in what the device tree blob is.  Something that
> should be thought about carefully and not just applied as a patch to
> solve a point problem.

I agree. I would not want to see every board for an SOC become an
overlay for example. I think it has to be limited to truly plugable
h/w (e.g. capes) or minor changes. We just have to define what is
minor. :)

Rob

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

Thread overview: 150+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-02-18 14:59 [PATCH 0/4] Device Tree Quirks & the Beaglebone Pantelis Antoniou
2015-02-18 14:59 ` Pantelis Antoniou
2015-02-18 14:59 ` Pantelis Antoniou
2015-02-18 14:59 ` [PATCH 1/4] arm: of: Add a DT quirk method after unflattening Pantelis Antoniou
2015-02-18 14:59   ` Pantelis Antoniou
2015-02-18 14:59 ` [PATCH 2/4] of: DT quirks infrastructure Pantelis Antoniou
2015-02-18 14:59   ` Pantelis Antoniou
2015-02-18 15:41   ` Mark Rutland
2015-02-18 15:41     ` Mark Rutland
2015-02-18 15:41     ` Mark Rutland
2015-02-18 15:53     ` Pantelis Antoniou
2015-02-18 15:53       ` Pantelis Antoniou
2015-02-18 15:53       ` Pantelis Antoniou
2015-02-18 16:32       ` Ludovic Desroches
2015-02-18 16:32         ` Ludovic Desroches
2015-02-18 16:32         ` Ludovic Desroches
2015-02-18 16:39         ` Pantelis Antoniou
2015-02-18 16:39           ` Pantelis Antoniou
2015-02-18 16:39           ` Pantelis Antoniou
2015-02-18 16:47           ` Ludovic Desroches
2015-02-18 16:47             ` Ludovic Desroches
2015-02-18 16:47             ` Ludovic Desroches
2015-02-18 16:46       ` Matt Porter
2015-02-18 16:46         ` Matt Porter
2015-02-18 16:46         ` Matt Porter
2015-02-18 17:31       ` Mark Rutland
2015-02-18 17:31         ` Mark Rutland
2015-02-18 17:31         ` Mark Rutland
2015-02-18 19:32         ` Guenter Roeck
2015-02-18 19:32           ` Guenter Roeck
2015-02-18 19:32           ` Guenter Roeck
2015-02-19 14:29         ` Pantelis Antoniou
2015-02-19 14:29           ` Pantelis Antoniou
2015-02-19 14:29           ` Pantelis Antoniou
2015-02-19 16:48           ` Frank Rowand
2015-02-19 16:48             ` Frank Rowand
2015-02-19 16:48             ` Frank Rowand
2015-02-19 17:00             ` Pantelis Antoniou
2015-02-19 17:00               ` Pantelis Antoniou
2015-02-19 17:00               ` Pantelis Antoniou
2015-02-19 17:30               ` Frank Rowand
2015-02-19 17:30                 ` Frank Rowand
2015-02-19 17:30                 ` Frank Rowand
2015-02-19 17:38                 ` Pantelis Antoniou
2015-02-19 17:38                   ` Pantelis Antoniou
2015-02-19 17:38                   ` Pantelis Antoniou
2015-02-19 18:01                   ` Maxime Bizon
2015-02-19 18:01                     ` Maxime Bizon
2015-02-19 18:01                     ` Maxime Bizon
2015-02-19 18:12                     ` Sylvain Rochet
2015-02-19 18:12                       ` Sylvain Rochet
2015-02-19 18:12                       ` Sylvain Rochet
2015-02-19 18:22                       ` Maxime Bizon
2015-02-19 18:22                         ` Maxime Bizon
2015-02-19 18:22                         ` Maxime Bizon
2015-02-20 14:21                   ` Peter Hurley
2015-02-20 14:21                     ` Peter Hurley
2015-02-20 14:21                     ` Peter Hurley
2015-02-20 14:35                     ` Ludovic Desroches
2015-02-20 14:35                       ` Ludovic Desroches
2015-02-20 14:35                       ` Ludovic Desroches
2015-02-20 15:00                       ` Peter Hurley
2015-02-20 15:00                         ` Peter Hurley
2015-02-20 15:00                         ` Peter Hurley
2015-02-20 15:02                         ` Pantelis Antoniou
2015-02-20 15:02                           ` Pantelis Antoniou
2015-02-20 15:02                           ` Pantelis Antoniou
2015-02-20 15:24                           ` Peter Hurley
2015-02-20 15:24                             ` Peter Hurley
2015-02-20 15:24                             ` Peter Hurley
2015-02-20 15:38                             ` Pantelis Antoniou
2015-02-20 15:38                               ` Pantelis Antoniou
2015-02-20 15:38                               ` Pantelis Antoniou
2015-02-20 16:34                               ` Peter Hurley
2015-02-20 16:34                                 ` Peter Hurley
2015-02-20 16:34                                 ` Peter Hurley
2015-02-20 16:49                                 ` Pantelis Antoniou
2015-02-20 16:49                                   ` Pantelis Antoniou
2015-02-20 16:49                                   ` Pantelis Antoniou
2015-02-20 17:30                       ` Rob Herring
2015-02-20 17:30                         ` Rob Herring
2015-02-20 17:30                         ` Rob Herring
2015-02-20 17:37                         ` Pantelis Antoniou
2015-02-20 17:37                           ` Pantelis Antoniou
2015-02-20 17:37                           ` Pantelis Antoniou
2015-02-23  7:00                         ` Ludovic Desroches
2015-02-23  7:00                           ` Ludovic Desroches
2015-02-23  7:00                           ` Ludovic Desroches
2015-02-20 14:38                     ` Pantelis Antoniou
2015-02-20 14:38                       ` Pantelis Antoniou
2015-02-20 14:38                       ` Pantelis Antoniou
2015-02-20 16:47                     ` Guenter Roeck
2015-02-20 16:47                       ` Guenter Roeck
2015-02-20 16:47                       ` Guenter Roeck
2015-02-20 18:09                       ` Peter Hurley
2015-02-20 18:09                         ` Peter Hurley
2015-02-20 18:09                         ` Peter Hurley
2015-02-20 18:48                         ` Guenter Roeck
2015-02-20 18:48                           ` Guenter Roeck
2015-02-20 18:48                           ` Guenter Roeck
2015-02-23  7:30                           ` Ludovic Desroches
2015-02-23  7:30                             ` Ludovic Desroches
2015-02-23  7:30                             ` Ludovic Desroches
2015-02-20  8:04                 ` Ludovic Desroches
2015-02-20  8:04                   ` Ludovic Desroches
2015-02-20  8:04                   ` Ludovic Desroches
2015-02-19  2:08   ` Frank Rowand
2015-02-19  2:08     ` Frank Rowand
2015-02-19 14:41     ` Pantelis Antoniou
2015-02-19 14:41       ` Pantelis Antoniou
2015-02-19 16:40       ` Frank Rowand
2015-02-19 16:40         ` Frank Rowand
2015-02-19 16:51         ` Frank Rowand
2015-02-19 16:51           ` Frank Rowand
2015-02-19 16:51           ` Frank Rowand
2015-02-20 13:23       ` Peter Hurley
2015-02-20 13:23         ` Peter Hurley
2015-02-19 18:01     ` Rob Herring [this message]
2015-02-19 18:01       ` Rob Herring
2015-02-19 18:01       ` Rob Herring
2015-02-19 18:12       ` Guenter Roeck
2015-02-19 18:12         ` Guenter Roeck
2015-02-19 18:12         ` Guenter Roeck
2015-02-20  8:16       ` Ludovic Desroches
2015-02-20  8:16         ` Ludovic Desroches
2015-02-20  8:16         ` Ludovic Desroches
2015-02-18 14:59 ` [PATCH 3/4] arm: am33xx: DT quirks for am33xx based beaglebone variants Pantelis Antoniou
2015-02-18 14:59   ` Pantelis Antoniou
2015-02-19 18:16   ` Tony Lindgren
2015-02-19 18:16     ` Tony Lindgren
2015-02-19 18:16     ` Tony Lindgren
2015-02-19 18:28     ` Pantelis Antoniou
2015-02-19 18:28       ` Pantelis Antoniou
2015-02-19 18:36       ` Tony Lindgren
2015-02-19 18:36         ` Tony Lindgren
2015-02-19 18:36         ` Tony Lindgren
2015-02-19 18:44         ` Pantelis Antoniou
2015-02-19 18:44           ` Pantelis Antoniou
2015-02-19 18:44           ` Pantelis Antoniou
2015-02-23 18:39           ` Peter Hurley
2015-02-23 18:39             ` Peter Hurley
2015-02-23 18:48             ` Pantelis Antoniou
2015-02-23 18:48               ` Pantelis Antoniou
2015-02-19 18:57         ` Guenter Roeck
2015-02-19 18:57           ` Guenter Roeck
2015-02-20 16:13       ` Jon Hunter
2015-02-20 16:13         ` Jon Hunter
2015-02-18 14:59 ` [PATCH 4/4] arm: dts: Common Black/White Beaglebone DTS using quirks Pantelis Antoniou
2015-02-18 14:59   ` Pantelis Antoniou
2015-02-18 14:59   ` Pantelis Antoniou

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='CAL_JsqKT3+URcad6X=i+73NLRnVstbpvFJxxT=ru7KJmp_XuVQ@mail.gmail.com' \
    --to=robherring2@gmail.com \
    --cc=devicetree@vger.kernel.org \
    --cc=frowand.list@gmail.com \
    --cc=grant.likely@secretlab.ca \
    --cc=koen@dominion.thruhere.net \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux@roeck-us.net \
    --cc=ludovic.desroches@atmel.com \
    --cc=matt.porter@linaro.org \
    --cc=nicolas.ferre@atmel.com \
    --cc=pantelis.antoniou@konsulko.com \
    --cc=panto@antoniou-consulting.com \
    --cc=tony@atomide.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 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.