On Tue, Mar 6, 2018 at 8:07 AM, David Gibson
<david@xxxxxxxxxxxxxxxxxxxxx> wrote:
> On Tue, Mar 06, 2018 at 01:30:05PM +0100, Geert Uytterhoeven wrote:
>> Hi David,
>>
>> On Tue, Mar 6, 2018 at 4:54 AM, David Gibson
>> <david@xxxxxxxxxxxxxxxxxxxxx> wrote:
>> > On Fri, Feb 23, 2018 at 09:05:24AM +0100, Geert Uytterhoeven wrote:
>> >> On Fri, Feb 23, 2018 at 3:38 AM, Frank Rowand <frowand.list@xxxxxxxxx> wrote:
>> >> > I was hoping to be able to convert the .dts files to use sugar syntax
>> >> > instead of hand coding the fragment nodes, but for this specific set
>> >> > of files I failed, since the labels that would have been required do
>> >> > not already exist in the base .dts files that that overlays would be
>> >> > applied against.
>> >>
>> >> Indeed, hence the fixup overlays use "target-path".
>> >>
>> >> BTW, is there any specific reason there is no sugar syntax support in dtc
>> >> for absolute target paths? I guess to prevent adding stuff to a random
>> >> existing node, and to encourage people to use a "connector" API defined in
>> >> term of labels?
>> >
>> > Only because it hasn't been implemented. Using &{/whatever} should
>> > IMO generate a target-path and the fact it doesn't is a bug.
>> >
>> >> I'm also in the process of converting my collection of DT overlays to sugar
>> >> syntax, and lack of support for "target-path" is the sole thing that holds
>> >> me back from completing this. So for now I use a mix of sugar and
>> >> traditional overlay syntax.
>> >>
>> >> In particular, I need "target-path" for two things:
>> >> 1. To refer to the root node, for adding devices that should live at
>> >> (a board subnode of) the root node, like:
>> >> - devices connected to GPIO controllers provided by other base or
>> >> overlay devices (e.g. LEDs, displays, buttons, ...),
>> >> - clock providers for other overlays devices (e.g. fixed-clock).
>>
>> >> The former is the real blocker for me.
>>
>> > Below is draft patch adding target-path support. The pretty minimal
>> > test examples do include a case using &{/}
>> >
>> > From 8f1b35f88395adea01ce1100c5faa27dacbc8410 Mon Sep 17 00:00:00 2001
>> > From: David Gibson <david@xxxxxxxxxxxxxxxxxxxxx>
>> > Date: Tue, 6 Mar 2018 13:27:53 +1100
>> > Subject: [PATCH] Correct overlay syntactic sugar for generating target-path
>> > fragments
>> >
>> > We've recently added "syntactic sugar" support to generate runtime dtb
>> > overlays using similar syntax to the compile time overlays we've had for
>> > a while. This worked with the &label { ... } syntax, adjusting an existing
>> > labelled node, but would fail with the &{/path} { ... } syntax attempting
>> > to adjust an existing node referenced by its path.
>> >
>> > The previous code would always try to use the "target" property in the
>> > output overlay, which needs to be fixed up, and __fixups__ can only encode
>> > symbols, not paths, so the result could never work properly.
>> >
>> > This adds support for the &{/path} syntax for overlays, translating it into
>> > the "target-path" encoding in the output. It also changes existing
>> > behaviour a little because we now unconditionally one fragment for each
>> > overlay section in the source. Previously we would only create a fragment
>> > if we couldn't locally resolve the node referenced. We need this for
>> > path references, because the path is supposed to be referencing something
>> > in the (not yet known) base tree, rather than the overlay tree we are
>> > working with now. In particular one useful case for path based overlays
>> > is using &{/} - but the constructed overlay tree will always have a root
>> > node, meaning that without the change that would attempt to resolve the
>> > fragment locally, which is not what we want.
>> >
>> > Signed-off-by: David Gibson <david@xxxxxxxxxxxxxxxxxxxxx>
>>
>> Thank you, seems to work fine on dtc.git.
>>
>> Note that while the dtc part applies on the in-kernel copy of dtc, it
>> doesn't work there: "&{/}" behaves the same as "/" (i.e. no overlay
>> fragment is generated), but "&{/foo}" does create the overlay fragment.
>> Merging in Rob's for-next branch to upgrade Linux' copy of dtc fixes
>> that.
>
> I think that'll be because the kernel makefiles (at least by default)
> use a pre-generated version of the parser, rather than running bison.
Just FYI, as of that branch, that is no longer true. We now run bison.
> Since there were changes in the .y file, those will be missing which
> would cause the error you describe.
>
> --
> David Gibson | I'll have my music baroque, and my code
> david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
> | _way_ _around_!
> http://www.ozlabs.org/~dgibson
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
