dt-bindings: arm, gic-v3: require that reserved cells are always 0
PATCH 1/1 dt-bindings: arm, gic-v3: require that reserved cells are always 0
The arm,gic-v3 binding was written with good intentions and doesn't enforce interrupt-cells to be 3, therefore making it easy to extend the irq description in future if necessary:
Quoted 1 line
Cells 4 and beyond are reserved for future use.
Unfortunately, this sentence is immediately followed up with:
Quoted 3 lines
When the 1st cell has a value of 0 or 1, cells 4 and beyond act as padding, and may be ignored. It is recommended that padding cells have a value of 0.
Consequently, any extensions to the PPI or SPI interrupt specifiers must be able to work with random crap from legacy DTs, effectively necessitating a new interrupt type in the first cell. Sigh.
This patch fixes the text so that additional, reserved cells are required to be zero. This looks like a reasonable thing to require and is already satisifed by the .dts files in-tree.
--- .../devicetree/bindings/interrupt-controller/arm,gic-v3.txt | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-)
Documentation/devicetree/bindings/interrupt-controller/arm,gic-v3.txt +2 -3
@@ -24,9 +24,8 @@ Main node required properties: 1 = edge triggered 4 = level triggered - Cells 4 and beyond are reserved for future use. When the 1st cell - has a value of 0 or 1, cells 4 and beyond act as padding, and may be - ignored. It is recommended that padding cells have a value of 0. + Cells 4 and beyond are reserved for future use and must have a value + of 0 if present. - reg : Specifies base physical address(s) and size of the GIC registers, in the following order:
Signature · 1 line
2.1.4
PATCH 1/1 dt-bindings: arm, gic-v3: require that reserved cells are always 0
Quoted 16 lines · Will Deacon
The arm,gic-v3 binding was written with good intentions and doesn't enforce interrupt-cells to be 3, therefore making it easy to extend the irq description in future if necessary:
Quoted 1 line
Cells 4 and beyond are reserved for future use.
Unfortunately, this sentence is immediately followed up with:
Quoted 3 lines
When the 1st cell has a value of 0 or 1, cells 4 and beyond act as padding, and may be ignored. It is recommended that padding cells have a value of 0.
Consequently, any extensions to the PPI or SPI interrupt specifiers must be able to work with random crap from legacy DTs, effectively necessitating a new interrupt type in the first cell. Sigh.
Quoted 7 lines
This patch fixes the text so that additional, reserved cells are required to be zero. This looks like a reasonable thing to require and is already satisifed by the .dts files in-tree.
Cc Mark Rutland <[email protected]>Cc Marc Zyngier <[email protected]>Signed-off-by Will Deacon <[email protected]>
M.
Signature · 1 line
Jazz is not dead. It just smells funny...
PATCH 1/1 dt-bindings: arm, gic-v3: require that reserved cells are always 0
In reply to Will DeaconQuoted 11 lines · Will Deacon
The arm,gic-v3 binding was written with good intentions and doesn't enforce interrupt-cells to be 3, therefore making it easy to extend the irq description in future if necessary:
Quoted 1 line
Cells 4 and beyond are reserved for future use.
Unfortunately, this sentence is immediately followed up with:
Quoted 3 lines
When the 1st cell has a value of 0 or 1, cells 4 and beyond act as padding, and may be ignored. It is recommended that padding cells have a value of 0.
The initial intention of this was to allow for new, longer entries which were identified by a new value in cell 1.
Regardless, I agree that it should be a requirement that padding cells must be zero.
Quoted 3 lines
Consequently, any extensions to the PPI or SPI interrupt specifiers must be able to work with random crap from legacy DTs, effectively necessitating a new interrupt type in the first cell. Sigh.
I'm not sure that's true if we allocate a new value for the 1st cell for "extended" PPI or SPI interrupt-sepcficiers (which presumably add restrictions). That would also allow old kernels to safely skip such interrupts rather than mis-parsing them.
Quoted 7 lines
This patch fixes the text so that additional, reserved cells are required to be zero. This looks like a reasonable thing to require and is already satisifed by the .dts files in-tree.
Cc Mark Rutland <[email protected]>Cc Marc Zyngier <[email protected]>Signed-off-by Will Deacon <[email protected]>
This patch itself makes sense, so FWIW:
Any proposed extention to the binding requires its own discussion.
Thanks,
Mark.
Quoted 23 lines
--- .../devicetree/bindings/interrupt-controller/arm,gic-v3.txt | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-)Documentation/devicetree/bindings/interrupt-controller/arm,gic-v3.txt +2
-3@@ -24,9 +24,8 @@ Main node required properties: 1 = edge triggered 4 = level triggered - Cells 4 and beyond are reserved for future use. When the 1st cell - has a value of 0 or 1, cells 4 and beyond act as padding, and may be - ignored. It is recommended that padding cells have a value of 0. + Cells 4 and beyond are reserved for future use and must have a value + of 0 if present. - reg : Specifies base physical address(s) and size of the GIC registers, in the following order:Signature · 1 line
2.1.4
PATCH 1/1 dt-bindings: arm, gic-v3: require that reserved cells are always 0
Quoted 9 lines · Mark Rutland
Quoted 3 lines · Will Deacon
Consequently, any extensions to the PPI or SPI interrupt specifiers must be able to work with random crap from legacy DTs, effectively necessitating a new interrupt type in the first cell. Sigh.
I'm not sure that's true if we allocate a new value for the 1st cell for "extended" PPI or SPI interrupt-sepcficiers (which presumably add restrictions). That would also allow old kernels to safely skip such interrupts rather than mis-parsing them.
Right, that's what I said :)
Quoted 8 lines
Quoted 7 lines
This patch fixes the text so that additional, reserved cells are required to be zero. This looks like a reasonable thing to require and is already satisifed by the .dts files in-tree.
Cc Mark Rutland <[email protected]>Cc Marc Zyngier <[email protected]>Signed-off-by Will Deacon <[email protected]>
Quoted 5 lines
This patch itself makes sense, so FWIW:
Acked-by Mark Rutland <[email protected]>Any proposed extention to the binding requires its own discussion.
Yup.
Marc -- can you queue this please?
Will