devicetree-compiler.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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 --]

      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).