|
|
|
|
/dts-v1/;
|
|
|
|
|
|
|
|
|
|
/ {
|
|
|
|
|
#address-cells = <0x01>;
|
|
|
|
|
#size-cells = <0x00>;
|
|
|
|
|
|
|
|
|
|
sub1: subnode@1 {
|
|
|
|
|
prop_label: compatible = value_label: "subnode1";
|
|
|
|
|
reg = <0x01>;
|
|
|
|
|
int-array = <0x00 0x01>, int_value_label: <0x02 0x03>;
|
|
|
|
|
int8 = [56];
|
Fix missing labels when emitting dts format
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: 32b9c6130762 ("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>
6 years ago
|
|
|
int8-array = [00 12 34 56] label:;
|
|
|
|
|
int16 = /bits/ 16 <0x3210>;
|
|
|
|
|
int16-array = /bits/ 16 <0x1234 0x5678 0x90ab 0xcdef>;
|
|
|
|
|
int16-matrix = /bits/ 16 <0x1234 0x5678>, <0x90ab 0xcdef>;
|
|
|
|
|
int64 = /bits/ 64 <0x200000000>;
|
Fix missing labels when emitting dts format
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: 32b9c6130762 ("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>
6 years ago
|
|
|
int64-array = /bits/ 64 <0x100000000 0x00> int64_array_label_end:;
|
|
|
|
|
a-string-with-nulls = "foo\0bar", "baz";
|
|
|
|
|
a-phandle = <&subsub1>;
|
|
|
|
|
a-phandle-with-args = <&subsub1 0x00 0x01>, <&subsub1 0x02 0x03>;
|
|
|
|
|
mixed-ints-and-phandles = <0x01 &subsub1 0x02 &subsub1>;
|
|
|
|
|
|
|
|
|
|
subsub1: subsubnode {
|
|
|
|
|
compatible = "subsubnode1", "subsubnode";
|
|
|
|
|
phandle = <0x01>;
|
|
|
|
|
|
|
|
|
|
subsubsub1: subsubsubnode {
|
|
|
|
|
compatible = "subsubsubnode1", <0x1234>, valuea: valueb: "subsubsubnode";
|
|
|
|
|
};
|
|
|
|
|
};
|
|
|
|
|
};
|
|
|
|
|
};
|
