The handling of "type preservation" dts output is based on the idea of
"phandles with arguments" in properties, which isn't really a thing, other
than a fairly common convention about how bindings are written. There's
nothing preventing a binding which freely mixes phandles and other integers
in an array of cells.
Currently write_propval() handles this incorrectly: specifically the case
of a phandle which follows a regular integer in a 32-bit cell array, but
without a new '< >' delimited causing an extra TYPE_UINT32 marker to be
inserted. In this case it omits the necessary space between the integer
and the phandle reference, leading to output which can't be sent back into
dtc and parsed.
Correct this, and update tests to match. I think this is more or less
correct for now, but really write_propval() is a big mess :(.
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
The dts output will just output phandle integer values, but often the
necessary markers are present with path or label references. Improve the
output and maintain phandle label or path references when present in dts
output.
Signed-off-by: Rob Herring <robh@kernel.org>
Message-Id: <20210727183023.3212077-6-robh@kernel.org>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
When there is a label inside a sequence of ints at the end of a
property, an assertion is hit because write_propval() expects all the
labels to be at the very end of the property data. This is clearly wrong
behaviour.
To reproduce run: "dtc -O dts tests/label01.dts". dtc fails on property
/randomnode/blob.
Fix by reworking the write_propval() loop to remove the separate
iterating over label markers. Instead handle the label markers as part
of the main marker iteration loop. This guarantees that each label
marker is handled at the right location, even if all the data markers
have already been handled, and has the added advantage of making the
code simpler.
However, a side effect of this code is that a label at the very end of
an int sequence will be emitted outside the sequence delimiters. For
example:
Input: intprop = < 1 2 L1: >, L2: < 3 4 L3: > L4:;
Output: intprop = < 1 2 >, L1: L2: < 3 4 > L3: L4:;
The two representations are equivalent in the data model, but the
current test case was looking for the former, but needed to be modified
to look for the later. The alternative would be to render labels before
closing the sequence, but that makes less sense syntactically because
labels between sequences are normally to point at the next one, not the
former. For example:
Input: intprop = < 1 2 L1: >, L2: < 3 4 L3: > L4:;
Output: intprop = < 1 2 L1: L2: >, < 3 4 L3: L4: >;
DTC doesn't current have the information to know if the label should be
inside or outside the sequence, but in common usage, it is more likely
that L1 & L2 refer to the second sequence, not the end of the first.
Fixes: 32b9c61307 ("Preserve datatype markers when emitting dts
format")
Reported-by: Łukasz Dobrowolski <lukasz.dobrowolski@nokia.com>
Signed-off-by: Grant Likely <grant.likely@arm.com>
Cc: David Gibson <david@gibson.dropbear.id.au>
Cc: Rob Herring <robh@kernel.org>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Commit 32b9c61307 ("Preserve datatype markers when emitting dts format")
add spaces between <> and [] and the encapsulated numbers. Fix this to
keep the prior formatting and not break some users needlessly.
Fixes: 32b9c61307 ("Preserve datatype markers when emitting dts format")
Reported-by: Stewart Smith <stewart@linux.ibm.com>
Signed-off-by: Rob Herring <robh@kernel.org>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
If datatype markers are present in the property value, use them to
output the data in the correct format instead of trying to guess the
datatype. This also will preserve data grouping, such as in an
interrupts list.
This is a step forward for preserving and using datatype information
when processing DTS/DTB files. Schema validation tools can use the
datatype information to make sure a DT is correctly formed and
intepreted.
Signed-off-by: Grant Likely <grant.likely@arm.com>
[robh: rework marker handling and fix label output]
Signed-off-by: Rob Herring <robh@kernel.org>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
David Gibson