From: Frank Rowand <frowand.list@gmail.com> To: Pantelis Antoniou <pantelis.antoniou@konsulko.com> Cc: Grant Likely <grant.likely@secretlab.ca>, 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, Ludovic Desroches <ludovic.desroches@atmel.com>, linux-arm-kernel@lists.infradead.org, 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 08:40:32 -0800 [thread overview] Message-ID: <54E61200.4010002@gmail.com> (raw) In-Reply-To: <23825C6A-7FF1-4D06-8802-F6964F71B97C@konsulko.com> On 2/19/2015 6:41 AM, Pantelis Antoniou wrote: > Hi Frank, > >> On Feb 19, 2015, at 04:08 , 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. >> > > Naming things is hard to do. Suggestions? You are inviting me to bikeshed. I'll leave that to you. > >> 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. >> > > There is a fundamental shift going on about what hardware is. It is nowhere > as static as it used to be. It is time for the kernel to keep up. Run time overlays do that. The problem you seem to be dealing with here is that you want a single DT blob that can be installed on many different _physical_ boards. > >> The stated use of this proposal is to create dynamic DT blobs that can >> describe many similar variants of a given system instead of creating >> unique DT blobs for each different system. >> > > Yes. > >> I obviously have not thought through the architectural implications yet, >> but just a quick example. One of the issues we have been trying to fix >> is device tree validation. The not yet existent (except as a few proof >> of concept attempts) validator would need to validate a device tree >> for each dynamic variant. Probably not a big deal, but an example of >> the ripple effects this conceptual change implies. >> > > I don’t see what the big problem with the validator is. The ‘quirk’ > are easily identified by the presence of the __overlay__ nodes and > the validator can apply each overlay and perform the validation check > at each resultant tree. I said "not a big deal". I was trying to make people think about the bigger picture. Defending that this is a non-issue for the validator is totally missing my point. Step back and think architecturally about the big picture. I do _not_ know if this is a problem, but they will be ripples from this proposal. > >> A second function that this patch is proposing is a method to enable >> or disable devices via command line options. If I understand >> correctly, this is meant to solve a problem with run time overlays >> that require disabling a device previously enabled by the DT blob. >> If so, it seems like it could easily be implemented in a simpler >> generic way than in the board specific code in this patch series. >> > > Disabling a device is the most common case, but other options are desired > too. For instance changing OPPs by a command line option, etc. The device tree is supposed to describe what the hardware is. Why would you want a command line option to change what OPPs are possible for the hardware? > >> I share the concerns that Mark Rutland has expressed in his comments >> about this series. >> >> < snip > >> >> I have read through the patches and will have comments on the code >> later if this proposal is seen as a good idea. >> > > OK > >> -Frank > > Regards > > — Pantelis > >
WARNING: multiple messages have this Message-ID (diff)
From: frowand.list@gmail.com (Frank Rowand) To: linux-arm-kernel@lists.infradead.org Subject: [PATCH 2/4] of: DT quirks infrastructure Date: Thu, 19 Feb 2015 08:40:32 -0800 [thread overview] Message-ID: <54E61200.4010002@gmail.com> (raw) In-Reply-To: <23825C6A-7FF1-4D06-8802-F6964F71B97C@konsulko.com> On 2/19/2015 6:41 AM, Pantelis Antoniou wrote: > Hi Frank, > >> On Feb 19, 2015, at 04:08 , 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. >> > > Naming things is hard to do. Suggestions? You are inviting me to bikeshed. I'll leave that to you. > >> 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. >> > > There is a fundamental shift going on about what hardware is. It is nowhere > as static as it used to be. It is time for the kernel to keep up. Run time overlays do that. The problem you seem to be dealing with here is that you want a single DT blob that can be installed on many different _physical_ boards. > >> The stated use of this proposal is to create dynamic DT blobs that can >> describe many similar variants of a given system instead of creating >> unique DT blobs for each different system. >> > > Yes. > >> I obviously have not thought through the architectural implications yet, >> but just a quick example. One of the issues we have been trying to fix >> is device tree validation. The not yet existent (except as a few proof >> of concept attempts) validator would need to validate a device tree >> for each dynamic variant. Probably not a big deal, but an example of >> the ripple effects this conceptual change implies. >> > > I don?t see what the big problem with the validator is. The ?quirk? > are easily identified by the presence of the __overlay__ nodes and > the validator can apply each overlay and perform the validation check > at each resultant tree. I said "not a big deal". I was trying to make people think about the bigger picture. Defending that this is a non-issue for the validator is totally missing my point. Step back and think architecturally about the big picture. I do _not_ know if this is a problem, but they will be ripples from this proposal. > >> A second function that this patch is proposing is a method to enable >> or disable devices via command line options. If I understand >> correctly, this is meant to solve a problem with run time overlays >> that require disabling a device previously enabled by the DT blob. >> If so, it seems like it could easily be implemented in a simpler >> generic way than in the board specific code in this patch series. >> > > Disabling a device is the most common case, but other options are desired > too. For instance changing OPPs by a command line option, etc. The device tree is supposed to describe what the hardware is. Why would you want a command line option to change what OPPs are possible for the hardware? > >> I share the concerns that Mark Rutland has expressed in his comments >> about this series. >> >> < snip > >> >> I have read through the patches and will have comments on the code >> later if this proposal is seen as a good idea. >> > > OK > >> -Frank > > Regards > > ? Pantelis > >
next prev parent reply other threads:[~2015-02-19 16:40 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 [this message] 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 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=54E61200.4010002@gmail.com \ --to=frowand.list@gmail.com \ --cc=devicetree@vger.kernel.org \ --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=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: linkBe 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.