devicetree-compiler.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Vincent Pelletier <plr.vincent-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
To: devicetree-compiler-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
Subject: dtc 1.6.0 overlay full-path reference in array produces broken property names
Date: Mon, 27 Sep 2021 14:04:56 +0000	[thread overview]
Message-ID: <20210927140456.4e45f05b@gmail.com> (raw)

(please keep me cc'ed in replies)

Hello,

I suspect this may be a dtc bug, but I am not too familiar with
devicetree specs to tell.

Here is a simplified example reproducing this issue:

(SNIP)
/dts-v1/;
/plugin/;

/ {
  compatible = "foo";
};

&{/soc/gpio@7e200000} {
    status = "okay";
};

&{/soc/spi@7e204000} {
    cs-gpios = <&{/soc/gpio@7e200000} 8 0x01>;
};
(SNIP)

This code builds fine:
  $ dtc -I dts -O dtb -o test.dtbo test.dts
  $
But then when disassembling the output, I get:
  $ dtc -I dtb -O dts test.dtbo
  <stdout>: ERROR (property_name_chars): /__fixups__:/soc/gpio@7e200000: Bad character '/' in property name
  ERROR: Input tree has errors, aborting (use -f to force output)
And forcing output:
  $ dtc -I dtb -O dts -f test.dtbo
  <stdout>: ERROR (property_name_chars): /__fixups__:/soc/gpio@7e200000: Bad character '/' in property name
  Warning: Input tree has errors, output forced
  /dts-v1/;

  / {
          compatible = "foo";

          fragment@0 {
                  target-path = "/soc/gpio@7e200000";

                  __overlay__ {
                          status = "okay";
                  };
          };

          fragment@1 {
                  target-path = "/soc/spi@7e204000";

                  __overlay__ {
                          cs-gpios = <0xffffffff 0x08 0x01>;
                  };
          };

          __fixups__ {
                  /soc/gpio@7e200000 = "/fragment@1/__overlay__:cs-gpios:0";
          };
  };

Indeed, the node in __fixups__ has an invalid name.

I suspect this is uncommon because:
- it probably only occurs in overlays and not in self-contained trees,
  as a self-contained tree would likely produce an internal phandle and
  never store the full path anywhere.
- ...which does not attach to labels but full paths
  Labels being (probably ?) valid node names, they would avoid the issue.
- ...in arrays
  In a node overlay, the full path ends up as a quoted string, not as a
  name, so it is safe.

Is this a dtc bug ?


I came up with the following workaround which gets me what I need, but
it is not very nice (extract):

  &{/soc} {
    gpio: gpio@7e200000 {
      #gpio-cells = <0x02>;
    };
    spi: spi@7e204000 {
      #address-cells = <1>;
      #size-cells = <0>;
    };
  };
  ...
  &spi {
      cs-gpios = <&gpio 8 0x01>;
  };

IOW:
- overlay the parent of the nodes I am interested in, just to declare
  labels
- ...while at it, repeat a few of the #... properties, which seem magic
  (this is where my devicetree knowledge ends, really)
- and go on implementing the actual overlays I want, using the
  just-defined labels.

Regards,
-- 
Vincent Pelletier
GPG fingerprint 983A E8B7 3B91 1598 7A92 3845 CAC9 3691 4257 B0C1

             reply	other threads:[~2021-09-27 14:04 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-09-27 14:04 Vincent Pelletier [this message]
     [not found] ` <20210927140456.4e45f05b-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2021-09-28 11:28   ` dtc 1.6.0 overlay full-path reference in array produces broken property names Vincent Pelletier
     [not found]     ` <20210928112859.79b55d5a-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2021-09-29  1:40       ` David Gibson
2021-11-01  6:19   ` David Gibson
2022-07-31 12:12     ` David Gibson

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=20210927140456.4e45f05b@gmail.com \
    --to=plr.vincent-re5jqeeqqe8avxtiumwx3w@public.gmane.org \
    --cc=devicetree-compiler-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).