kernel
/
dtc
mirror of https://git.kernel.org/pub/scm/utils/dtc/dtc.git
1
0
Fork 0
Code Issues Projects Releases Wiki Activity
You can not select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
944 Commits
2 Branches
23 Tags
1.7 MiB
Tree: 3d522abc75
Branches Tags
${ item.name }
Create tag ${ searchTerm }
Create branch ${ searchTerm }
from '3d522abc75'
${ noResults }
dtc/tests/type-preservation.dts

29 lines
754 B
Raw Normal View History Unescape

Preserve datatype markers when emitting dts format 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>
7 years ago
/dts-v1/;
/ {
Revert dts output formatting changes of spaces around brackets Commit 32b9c6130762 ("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: 32b9c6130762 ("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>
6 years ago
#address-cells = <0x01>;
#size-cells = <0x00>;
Preserve datatype markers when emitting dts format 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>
7 years ago
sub1: subnode@1 {
prop_label: compatible = value_label: "subnode1";
Revert dts output formatting changes of spaces around brackets Commit 32b9c6130762 ("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: 32b9c6130762 ("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>
6 years ago
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:;
Revert dts output formatting changes of spaces around brackets Commit 32b9c6130762 ("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: 32b9c6130762 ("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>
6 years ago
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:;
Preserve datatype markers when emitting dts format 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>
7 years ago
a-string-with-nulls = "foo\0bar", "baz";
subsub1: subsubnode {
compatible = "subsubnode1", "subsubnode";
subsubsub1: subsubsubnode {
Revert dts output formatting changes of spaces around brackets Commit 32b9c6130762 ("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: 32b9c6130762 ("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>
6 years ago
compatible = "subsubsubnode1", <0x1234>, valuea: valueb: "subsubsubnode";
Preserve datatype markers when emitting dts format 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>
7 years ago
};
};
};
};