From: David Gibson <david-xT8FGy+AXnRB3Ne2BGzF6laj5H9X9Tb+@public.gmane.org>
To: Rob Herring <robherring2-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Cc: Devicetree Compiler
<devicetree-compiler-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
Andrei Ziureaev <andrei.ziureaev-5wv7dgnIgG8@public.gmane.org>
Subject: Re: /bits/ encoding
Date: Sat, 13 Jun 2020 17:10:08 +1000 [thread overview]
Message-ID: <20200613071008.GC5861@umbus.fritz.box> (raw)
In-Reply-To: <CAL_JsqLsT=HBTdRzEg4k6jOHDYkELj4cLXDjX8+9mdc1fNk0RQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 2074 bytes --]
On Fri, Jun 12, 2020 at 02:02:55PM -0600, Rob Herring wrote:
> What's the expected property length in these 2 cases?:
>
> prop = /bits/ 16 <0x1234 0x5678>, <0x9abc 0xdef0>;
> prop = /bits/ 16 <0x1234 0x5678 0x9abc 0xdef0>;
>
> For 32-bit sizes, the <> don't matter. I had assumed /bits/ applied to
> the whole property value and the <> don't matter in that case either.
> But that's not the case in dtc. In the 1st example, the last 2 values
> are 32-bit. In order to make all values in the 1st example 16-bit, we
> have to do:
>
> prop = /bits/ 16 <0x1234 0x5678>, /bits/ 16 <0x9abc 0xdef0>;
>
> That also means one could do:
>
> prop = /bits/ 16 <0x1234 0x5678>, /bits/ 8 <0x9a 0xbc 0xde 0xf0>;
>
> Something we want to support (it already works)?
Allowing that was my intention when I added this code.
> I don't think such a
> thing exists in the wild,
Well, arrays of 16-bit or 8-bit values in the tree are pretty rare to
begin with. The reason I wanted to allow mixed things here is that
properties with mixed types of data absolutely do exist in bindings
out there. Note that I suspect there could well be some examples out
there with mixed 64-bit and 32-bit values, which could also this
form if it's useful to do so. e.g. 'reg' of nodes on a bus with
#address-cells = 2 and #size-cells = 1 could be like that.
> the kernel's array parsing doesn't expect
> it, and I haven't encountered a use for it. Given the non-existent
> type information in FDT, that doesn't seem like a great idea.
Hrm. To me, it's this way precisely *because* there's no type
information. Properties are bytestrings, any internal structure is
added by bindings. dtc's job here isn't to impose a structure that
doesn't exist onto properties, just to provide tools to let people
build those bytestrings in the most convenient possible way.
--
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 #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
prev parent reply other threads:[~2020-06-13 7:10 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-06-12 20:02 /bits/ encoding Rob Herring
[not found] ` <CAL_JsqLsT=HBTdRzEg4k6jOHDYkELj4cLXDjX8+9mdc1fNk0RQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2020-06-13 7:10 ` David Gibson [this message]
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=20200613071008.GC5861@umbus.fritz.box \
--to=david-xt8fgy+axnrb3ne2bgzf6laj5h9x9tb+@public.gmane.org \
--cc=andrei.ziureaev-5wv7dgnIgG8@public.gmane.org \
--cc=devicetree-compiler-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=robherring2-Re5JQEeQqe8AvxtiuMwx3w@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 NNTP newsgroup(s).