/bits/ encoding

/bits/ encoding

[Rob Herring]

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)? I don't think such a
thing exists in the wild, 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.

Rob

Re: /bits/ encoding

[David Gibson]

[-- 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 --]