linux-kernel - Re: [PATCH v2 0/6] of: overlays: New target methods

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <70AB0C5B-737D-41B9-8D21-4205379ABDB7@konsulko.com>
Date:	Fri, 27 May 2016 17:46:04 +0300
From:	Pantelis Antoniou <pantelis.antoniou@...sulko.com>
To:	frowand.list@...il.com
Cc:	Rob Herring <robherring2@...il.com>,
	Matt Porter <mporter@...sulko.com>,
	Grant Likely <grant.likely@...retlab.ca>,
	Koen Kooi <koen@...inion.thruhere.net>,
	Guenter Roeck <linux@...ck-us.net>,
	Marek Vasut <marex@...x.de>,
	Devicetree List <devicetree@...r.kernel.org>,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH v2 0/6]  of: overlays: New target methods

Hi Frank,

> On May 27, 2016, at 00:15 , Frank Rowand <frowand.list@...il.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.

Putting things in the overlay seemed like it would have
no effect on the base tree whatsoever.


> -Frank
> 

Regards

— Pantelis