From: Frank Rowand <frowand.list@gmail.com>
To: Pantelis Antoniou <pantelis.antoniou@konsulko.com>
Cc: Rob Herring <robherring2@gmail.com>,
Matt Porter <mporter@konsulko.com>,
Grant Likely <grant.likely@secretlab.ca>,
Koen Kooi <koen@dominion.thruhere.net>,
Guenter Roeck <linux@roeck-us.net>, Marek Vasut <marex@denx.de>,
Devicetree List <devicetree@vger.kernel.org>,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH v2 0/6] of: overlays: New target methods
Date: Fri, 27 May 2016 13:35:28 -0700 [thread overview]
Message-ID: <5748AF90.3090607@gmail.com> (raw)
In-Reply-To: <70AB0C5B-737D-41B9-8D21-4205379ABDB7@konsulko.com>
On 5/27/2016 7:46 AM, Pantelis Antoniou wrote:
> Hi Frank,
>
>> On May 27, 2016, at 00:15 , Frank Rowand <frowand.list@gmail.com> wrote:
>>
>> On 5/16/2016 1:18 PM, Pantelis Antoniou wrote:
>>> This patchset implements two new target methods.
>>>
>>> A target index method which allows selecting different
>>> targets according to an argument using an extended API and
>>> a target root method that fences the target only
>>> to a specific given root.
>>>
>>> Documentation and unit-tests are included.
>>
>> I think you are attacking the problem the wrong way.
>>
>> If I understand correctly, the problem statement is:
>>
>> In some cases, a devicetree overlay is meant to describe
>> a pluggable piece of hardware, which may be plugged into
>> various locations on a platform. It should be possible
>> to apply a single devicetree to one or more locations
>> on a given platform.
>>
>> If that is the case, then putting the locations where the
>> overlay can be applied into the devicetree is not the
>> approach that I would use. It seems it would be better
>> to specify the target location as a separate item from
>> the overlay to the method that applies the devicetree.
>> In that case, I would put the node(s) describing the
>> pluggable hardware in the root node of the overlay
>> devicetree (dtc expects a root node). The apply
>> method can easily find the node(s) and relocate them
>> to the appropriate location in the platform's
>> devicetree.
>>
>
> It’s a bit more complicated. This was considered initially
> but we ended up with the targets on the overlay.
>
> It can work either way, but the problem with storing the
> indirect targets in the base tree is that there is no
> change in the bindings of the targets.
I am not suggesting putting the targets in the base tree.
I do not know where it should be. Still thinking about
that part.
>
> Putting things in the overlay seemed like it would have
> no effect on the base tree whatsoever.
>
>
>> -Frank
>>
>
> Regards
>
> — Pantelis
>
>
prev parent reply other threads:[~2016-05-27 20:35 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-05-16 20:18 [PATCH v2 0/6] of: overlays: New target methods Pantelis Antoniou
2016-05-16 20:18 ` [PATCH v2 1/6] of: overlay: Implement target index support Pantelis Antoniou
2016-05-16 20:18 ` [PATCH v2 2/6] of: unittest: Add indirect overlay target test Pantelis Antoniou
2016-05-16 20:18 ` [PATCH v2 3/6] doc: dt: Document the indirect overlay method Pantelis Antoniou
2016-05-16 20:18 ` [PATCH v2 4/6] of: overlay: Introduce target root capability Pantelis Antoniou
2016-05-16 20:18 ` [PATCH v2 5/6] of: unittest: Unit-tests for target root overlays Pantelis Antoniou
[not found] ` <1463429892-3369-6-git-send-email-pantelis.antoniou-OWPKS81ov/FWk0Htik3J/w@public.gmane.org>
2016-05-17 12:37 ` Geert Uytterhoeven
2016-05-17 12:37 ` Geert Uytterhoeven
2016-05-16 20:18 ` [PATCH v2 6/6] doc: dt: Document the target root overlay method Pantelis Antoniou
[not found] ` <1463429892-3369-7-git-send-email-pantelis.antoniou-OWPKS81ov/FWk0Htik3J/w@public.gmane.org>
2016-05-17 12:58 ` Rob Herring
2016-05-17 12:58 ` Rob Herring
[not found] ` <CAL_JsqKX1m-gKBGUcxaHJm-ih-QHhHbpHBqMJbb5KXeG9eStQQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2016-05-17 16:02 ` Pantelis Antoniou
2016-05-17 16:02 ` Pantelis Antoniou
2016-05-26 21:15 ` [PATCH v2 0/6] of: overlays: New target methods Frank Rowand
2016-05-27 14:46 ` Pantelis Antoniou
2016-05-27 20:35 ` Frank Rowand [this message]
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=5748AF90.3090607@gmail.com \
--to=frowand.list@gmail.com \
--cc=devicetree@vger.kernel.org \
--cc=grant.likely@secretlab.ca \
--cc=koen@dominion.thruhere.net \
--cc=linux-kernel@vger.kernel.org \
--cc=linux@roeck-us.net \
--cc=marex@denx.de \
--cc=mporter@konsulko.com \
--cc=pantelis.antoniou@konsulko.com \
--cc=robherring2@gmail.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.