Re: [PATCH v3 06/15] Introduce structured tag value definition
From: David Gibson <hidden>
Date: 2026-09-10 04:51:20
Also in:
lkml
On Wed, Aug 26, 2026 at 10:31:37AM +0200, Herve Codina wrote:
The goal of structured tag values is to ease the introduction of new tags in future releases with the capability for an already existing release to ignore those structured tags. In order to do that data length related to the unknown tag needs to be identified. Also add a flag to tell an old release if this tag can be simply skipped or must lead to an error.
I suggested/insisted on this in the past, but I've since realised this isn't actually useful. The "structured tag" format is only useful because it allows you to skip over unknown tags, which means there's no point using it for ags that can't be skipped. If we need new tags that can't be safely skipped, they can be added as old-style tags instead. In which case "old style" versus "new style" is no longer a good characterization: they would exist side by side, so the distinction is more "skippable" versus "non skippable" tags. Which suggests that "skippable tags" or "metadata tags" might be a better term than "structured tags" - that would focus more on the why than the how.
Structured tag value is defined on 32bit and is defined as follow:
Bits | 31 | 30 | 29 28 | 27 0|
------+----+-----------+-------------------+--------+
Fields| 1 | SKIP_SAFE | DATA_LEN_ENCODING | TAG_ID |
------+----+-----------+-------------------+--------+
Bit 31 is always set to 1 to identify a structured tag value.
Bit 30 (SKIP_SAFE) is set to 1 if the tag can be safely ignored when its
TAG_ID value is not a known value (unknown tag). If the SKIP_SAFE bit is
set to 0 this tag must not be ignored and an error should be reported
when its TAG_ID value is not a known value (unknown tag).
Bits 29..28 (DATA_LEN_ENCODING) indicates the length of the data related
to the tag. Following values are possible:
- 0b00: No data.
The tag is followed by the next tag value.I think "next tag." would be clearer than "next tag value." - "next tag value" could be confused as meaning the data that comes after the tag.
- 0b01: 1 cell data
The tag is followed by a 1 cell (u32) data. The next tag is
available after this cell.Remove "available", it doesn't add any information.
- 0b10: 2 cells data
The tag is followed by a 2 cells (2 * u32) data. The next tag
is available after those two cells.Ditto.
- 0b11: Data length encoding
The tag is followed by a cell (u32) indicating the size of the
data. This size is given in bytes. Data are available right
after this cell.
The next tag is available after the data. Padding is present
after the data in order to have the next tag aligned on 32bits.
This padding is not included in the size of the data.I'm guessing the 1 & 2 cell cases are pretty common so it saves a moderate amount of dtb size to have this encoding. However, it does come at the cost of greater code complexity. Is it worth it? I'm willing to believe it is, but I think the case needs to be made. I'd also avoid the term "cell" here. To me a "cell" is specifically a term applying to a 32-bit value _within a device tree property_. These are 32-bits, but not part of a property. Plus if Segher reappears, he'll complain that in the old days of OF, a cell wasn't necessarily 32-bits :).
quoted hunk ↗ jump to hunk
Bits 27..0 (TAG_ID) is the tag identifier defining a specific tag. Introduce the structured tag values definition and some specific tags reserved for tests based on this structure definition. Signed-off-by: Herve Codina <herve.codina@bootlin.com> Reviewed-by: Frank Li <Frank.Li@nxp.com> --- libfdt/fdt.h | 23 +++++++++++++++++++++++ 1 file changed, 23 insertions(+)diff --git a/libfdt/fdt.h b/libfdt/fdt.h index a07abfcc..f41a355f 100644 --- a/libfdt/fdt.h +++ b/libfdt/fdt.h@@ -49,6 +49,7 @@ struct fdt_property { #define FDT_MAGIC 0xd00dfeed /* 4: version, 4: total size */ #define FDT_TAGSIZE sizeof(fdt32_t) +#define FDT_CELLSIZE sizeof(fdt32_t)
I'd avoid creating this constant for similar reasons to avoid the term "cell" above.
quoted hunk ↗ jump to hunk
#define FDT_BEGIN_NODE 0x1 /* Start node: full name */ #define FDT_END_NODE 0x2 /* End node */@@ -57,6 +58,28 @@ struct fdt_property { #define FDT_NOP 0x4 /* nop */ #define FDT_END 0x9 +/* Tag values flags */ +#define FDT_TAG_STRUCTURED (1U<<31) +#define FDT_TAG_SKIP_SAFE (1U<<30) +#define FDT_TAG_DATA_MASK (3U<<28) +#define FDT_TAG_DATA_NONE (0U<<28) +#define FDT_TAG_DATA_1CELL (1U<<28) +#define FDT_TAG_DATA_2CELLS (2U<<28) +#define FDT_TAG_DATA_VARLEN (3U<<28) + +#define FDT_TAG_NO_SKIP(tag_data, tag_id) \ + (FDT_TAG_STRUCTURED | tag_data | tag_id) + +#define FDT_TAG_CAN_SKIP(tag_data, tag_id) \ + (FDT_TAG_STRUCTURED | FDT_TAG_SKIP_SAFE | tag_data | tag_id) + +/* Tests reserved tags */ +#define FDT_TEST_NONE_CAN_SKIP FDT_TAG_CAN_SKIP(FDT_TAG_DATA_NONE, 0) +#define FDT_TEST_1CELL_CAN_SKIP FDT_TAG_CAN_SKIP(FDT_TAG_DATA_1CELL, 0) +#define FDT_TEST_2CELLS_CAN_SKIP FDT_TAG_CAN_SKIP(FDT_TAG_DATA_2CELLS, 0) +#define FDT_TEST_VARLEN_CAN_SKIP FDT_TAG_CAN_SKIP(FDT_TAG_DATA_VARLEN, 0) +#define FDT_TEST_NONE_NO_SKIP FDT_TAG_NO_SKIP(FDT_TAG_DATA_NONE, 0) + #define FDT_V1_SIZE (7*sizeof(fdt32_t)) #define FDT_V2_SIZE (FDT_V1_SIZE + sizeof(fdt32_t)) #define FDT_V3_SIZE (FDT_V2_SIZE + sizeof(fdt32_t))-- 2.55.0
-- David Gibson (he or they) | 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
Attachments
- signature.asc [application/pgp-signature] 833 bytes