On Wed, Sep 12, 2018 at 03:14:21PM +0200, Fredrik Markström wrote:
> Ok, I got it. My patch breaks path references which shouldn't be
> resolved locally. I was made aware of your commit below. I'll send a
> PATCH v2 shortly.
Actually, I'd forgotten about that problem, but yes, that's certainly
a problem.
>
> /Fredrik
>
> commit 8f1b35f88395adea01ce1100c5faa27dacbc8410
> Author: David Gibson <david@xxxxxxxxxxxxxxxxxxxxx>
> Date: Tue Mar 6 13:27:53 2018 +1100
>
> Correct overlay syntactic sugar for generating target-path fragments
>
>
> /Fredrik
> On Wed, Sep 12, 2018 at 10:52 AM Fredrik Markström
> <fredrik.markstrom@xxxxxxxxx> wrote:
> >
> > Hello and thanks for the quick response, my comments below.
> >
> > On Tue, Sep 11, 2018 at 8:14 AM David Gibson
> > <david@xxxxxxxxxxxxxxxxxxxxx> wrote:
> > >
> > > On Mon, Sep 10, 2018 at 11:55:10PM +0200, Fredrik Markstrom wrote:
> > > > This patch makes it possible to use references to labels in plugins
> > > > without creating additional fragments.
> > > >
> > > > Previously the dts below would generate two fragments:
> > > >
> > > > /dts-v1/;
> > > > /plugin/;
> > > > &x { a: a@0 {};};
> > > > &a { b {}; };
> > > >
> > > > Signed-off-by: Fredrik Markstrom <fredrik.markstrom@xxxxxxxxx>
> > >
> > > I've considered a change like this before, and it might be a good
> > > idea. I'm not certain though, because it does make the mapping
> > > between what appears in the dts and the dtbo a bit less obvious than
> > > it might be otherwise.
> > >
> > > Do you have a concrete reason to prefer this approach?
> >
> > I left it out the first time because I'm not sure our use case is 100%
> > spot on :)
> >
> > The short story is that a lot of dtsi:s (which we want to reuse)
> > written for non-overlays are on this form (starting with a reference)
> > and the kernel (at least 4.1) doesn't seem to be able to resolve
> > dependencies between fragments.
> >
> > The long story is: Basically we have a huge and deep device tree (lots
> > of fpga:s) and each major part of the tree is
> > kept in it's own dtsi in which starts with a reference to where it's
> > supposed to be inserted
> > (like most (or at least a lot) of the dtsi:s in mainline). We now want
> > to break things out and load
> > fpga:s and device trees from user-space.
> >
> > I'm not sure I understand what the drawback is.
> >
> > /Fredrik
> >
> > >
> > > > ---
> > > > dtc-parser.y | 12 ++++++------
> > > > 1 file changed, 6 insertions(+), 6 deletions(-)
> > > >
> > > > diff --git a/dtc-parser.y b/dtc-parser.y
> > > > index dd70ebf..4f2f6dd 100644
> > > > --- a/dtc-parser.y
> > > > +++ b/dtc-parser.y
> > > > @@ -196,13 +196,13 @@ devicetree:
> > > > * versioninfo plugindecl memreserves devicetree
> > > > * so $-1 is what we want (plugindecl)
> > > > */
> > > > - if ($<flags>-1 & DTSF_PLUGIN) {
> > > > - add_orphan_node($1, $3, $2);
> > > > - } else {
> > > > - struct node *target = get_node_by_ref($1, $2);
> > > > + struct node *target = get_node_by_ref($1, $2);
> > > >
> > > > - if (target)
> > > > - merge_nodes(target, $3);
> > > > + if (target)
> > > > + merge_nodes(target, $3);
> > > > + else {
> > > > + if ($<flags>-1 & DTSF_PLUGIN)
> > > > + add_orphan_node($1, $3, $2);
> > > > else
> > > > ERROR(&@2, "Label or path %s not found", $2);
> > > > }
> > >
> >
> >
> >
>
>
>
--
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
Attachment:
signature.asc
Description: PGP signature
