On Wed, Oct 18, 2017 at 10:12 AM, Alan Tull [off-list ref] wrote:

On Tue, Oct 17, 2017 at 6:51 PM, Frank Rowand [off-list ref] wrote:

quoted

On 10/17/17 14:46, Rob Herring wrote:

quoted

On Tue, Oct 17, 2017 at 4:32 PM, Alan Tull [off-list ref] wrote:

quoted

On Mon, Aug 21, 2017 at 10:16 AM, Rob Herring [off-list ref] wrote:

Hi Rob,

quoted

With dependencies on a statically allocated full path name converted to
use %pOF format specifier, we can store just the basename of node, and
the unflattening of the FDT can be simplified.

This commit will affect the remaining users of full_name. After
analyzing these users, the remaining cases should only change some print
messages. The main users of full_name are providing a name for struct
resource. The resource names shouldn't be important other than providing
/proc/iomem names.

We no longer distinguish between pre and post 0x10 dtb formats as either
a full path or basename will work. However, less than 0x10 formats have
been broken since the conversion to use libfdt (and no one has cared).
The conversion of the unflattening code to be non-recursive also broke
pre 0x10 formats as the populate_node function would return 0 in that
case.

Signed-off-by: Rob Herring <robh@kernel.org>
---
v2:
- rebase to linux-next

 drivers/of/fdt.c | 69 +++++++++-----------------------------------------------
 1 file changed, 11 insertions(+), 58 deletions(-)

I've just updated to the latest next branch and am finding problems
applying overlays.   Reverting this commit alleviates things.  The
errors I get are:

[   88.498704] OF: overlay: Failed to apply prop @/__symbols__/clk_0
[   88.513447] OF: overlay: apply failed '/__symbols__'
[   88.518423] create_overlay: Failed to create overlay (err=-12)

Frank's series with overlay updates should fix this.

Yes, it does:

  [PATCH v3 11/12] of: overlay: remove a dependency on device node full_name

Thanks for the fast response.  I fetched the dt/next branch to test
this but there are sufficient changes that Pantelis' "OF: DT-Overlay
configfs interface (v7)" is broken now.  I've been adding that
downstream since 4.4.  We're using it as an interface for applying
overlays to program FPGAs.  If we fix it again, is there any chance
that can go upstream now?

With a drive-by posting once every few years, no.

The issue remains that the kernel is not really setup to deal with any
random property or node to be changed at any point in run-time. I
think there needs to be some restrictions around what the overlays can
touch. We can't have it be wide open and then lock things down later
and break users. One example of what you could do is you can only add
sub-trees to whitelisted nodes. That's probably acceptable for your
usecase.

Rob