arm64: arch_timer: Add device tree binding for hisilicon-161x01 erratum
PATCH 1/3 arm64: arch_timer: Add device tree binding for hisilicon-161x01 erratum
This erratum describes a bug in logic outside the core, so MIDR can't be used to identify its presence, and reading an SoC-specific revision register from common arch timer code would be awkward. So, describe it in the device tree.
--- Documentation/devicetree/bindings/arm/arch_timer.txt | 6 ++++++ 1 file changed, 6 insertions(+)
Documentation/devicetree/bindings/arm/arch_timer.txt +6 -0
@@ -31,6 +31,12 @@ to deliver its interrupts via SPIs. This also affects writes to the tval register, due to the implicit counter read. +- hisilicon,erratum-161x01 : A boolean property. Indicates the presence of + QorIQ erratum 161201, which says that reading the counter is + unreliable unless the small range of value is returned by back-to-back reads. + This also affects writes to the tval register, due to the implicit + counter read. + ** Optional properties: - arm,cpu-registers-not-fw-configured : Firmware does not initialize
Signature · 1 line
1.9.0
PATCH 1/3 arm64: arch_timer: Add device tree binding for hisilicon-161x01 erratum
Quoted 15 lines · Ding Tianhong
This erratum describes a bug in logic outside the core, so MIDR can't be used to identify its presence, and reading an SoC-specific revision register from common arch timer code would be awkward. So, describe it in the device tree.
Signed-off-by Ding Tianhong <[email protected]>--- Documentation/devicetree/bindings/arm/arch_timer.txt | 6 ++++++ 1 file changed, 6 insertions(+)Documentation/devicetree/bindings/arm/arch_timer.txt +0
-0
Documentation/devicetree/bindings/arm/arch_timer.txt to deliver its interrupts via SPIs. · line 35
Quoted 5 lines
Documentation/devicetree/bindings/arm/arch_timer.txt +2
-0@@ -31,6 +31,12 @@ to deliver its interrupts via SPIs. This also affects writes to the tval register, due to the implicit counter read. +- hisilicon,erratum-161x01 : A boolean property. Indicates the presence of + QorIQ erratum 161201, which says that reading the counter is
QorIQ is a Freescale/NXP specific name, and shouldn't be there.
Shawn
Quoted 16 lines
Documentation/devicetree/bindings/arm/arch_timer.txt +4
-0+ unreliable unless the small range of value is returned by back-to-back reads. + This also affects writes to the tval register, due to the implicit + counter read. + ** Optional properties: - arm,cpu-registers-not-fw-configured : Firmware does not initializeSignature · 8 lines
1.9.0 _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel at lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
PATCH 1/3 arm64: arch_timer: Add device tree binding for hisilicon-161x01 erratum
Quoted 19 lines · Shawn Guo
Quoted 18 lines · Ding Tianhong
This erratum describes a bug in logic outside the core, so MIDR can't be used to identify its presence, and reading an SoC-specific revision register from common arch timer code would be awkward. So, describe it in the device tree.
Signed-off-by Ding Tianhong <[email protected]>--- Documentation/devicetree/bindings/arm/arch_timer.txt | 6 ++++++ 1 file changed, 6 insertions(+)Documentation/devicetree/bindings/arm/arch_timer.txt +0
-0@@ -31,6 +31,12 @@ to deliver its interrupts via SPIs. This also affects writes to the tval register, due to the implicit counter read.
Quoted 7 lines
Documentation/devicetree/bindings/arm/arch_timer.txt to deliver its interrupts via SPIs. · line 35
Quoted 2 lines
Documentation/devicetree/bindings/arm/arch_timer.txt +2
-0+- hisilicon,erratum-161x01 : A boolean property. Indicates the presence of + QorIQ erratum 161201, which says that reading the counter isQorIQ is a Freescale/NXP specific name, and shouldn't be there.
Shawn
Got it, will wait other feedback and fix them together, thanks.
Ding
Quoted 19 lines
Quoted 16 lines
Documentation/devicetree/bindings/arm/arch_timer.txt +4
-0+ unreliable unless the small range of value is returned by back-to-back reads. + This also affects writes to the tval register, due to the implicit + counter read. + ** Optional properties: - arm,cpu-registers-not-fw-configured : Firmware does not initializeSignature · 8 lines
1.9.0 _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel at lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel.
PATCH 1/3 arm64: arch_timer: Add device tree binding for hisilicon-161x01 erratum
In reply to Ding TianhongQuoted 15 lines · Ding Tianhong
This erratum describes a bug in logic outside the core, so MIDR can't be used to identify its presence, and reading an SoC-specific revision register from common arch timer code would be awkward. So, describe it in the device tree.
Signed-off-by Ding Tianhong <[email protected]>--- Documentation/devicetree/bindings/arm/arch_timer.txt | 6 ++++++ 1 file changed, 6 insertions(+)Documentation/devicetree/bindings/arm/arch_timer.txt +0
-0
Documentation/devicetree/bindings/arm/arch_timer.txt to deliver its interrupts via SPIs. · line 35
Quoted 5 lines
Documentation/devicetree/bindings/arm/arch_timer.txt +2
-0@@ -31,6 +31,12 @@ to deliver its interrupts via SPIs. This also affects writes to the tval register, due to the implicit counter read. +- hisilicon,erratum-161x01 : A boolean property. Indicates the presence of + QorIQ erratum 161201, which says that reading the counter is
Other than the copy/paste of the FSL erratum, please document the actual erratum number. Is that 161x01 or 161201?
Documentation/devicetree/bindings/arm/arch_timer.txt to deliver its interrupts via SPIs. · line 36
Quoted 1 line
Documentation/devicetree/bindings/arm/arch_timer.txt +1
-0+ unreliable unless the small range of value is returned by back-to-back reads.
That's a detail that doesn't belong in the DT, but that would be much better next to the code doing the actual handling.
Documentation/devicetree/bindings/arm/arch_timer.txt to deliver its interrupts via SPIs. · line 42
Quoted 7 lines
Documentation/devicetree/bindings/arm/arch_timer.txt +3
-0+ This also affects writes to the tval register, due to the implicit + counter read. + ** Optional properties: - arm,cpu-registers-not-fw-configured : Firmware does not initialize
Thanks,
M.
Signature · 1 line
Jazz is not dead. It just smells funny...
PATCH 1/3 arm64: arch_timer: Add device tree binding for hisilicon-161x01 erratum
Quoted 19 lines · Marc Zyngier
Quoted 18 lines · Ding Tianhong
This erratum describes a bug in logic outside the core, so MIDR can't be used to identify its presence, and reading an SoC-specific revision register from common arch timer code would be awkward. So, describe it in the device tree.
Signed-off-by Ding Tianhong <[email protected]>--- Documentation/devicetree/bindings/arm/arch_timer.txt | 6 ++++++ 1 file changed, 6 insertions(+)Documentation/devicetree/bindings/arm/arch_timer.txt +0
-0@@ -31,6 +31,12 @@ to deliver its interrupts via SPIs. This also affects writes to the tval register, due to the implicit counter read.
Quoted 6 lines
Documentation/devicetree/bindings/arm/arch_timer.txt to deliver its interrupts via SPIs. · line 35
Quoted 2 lines
Documentation/devicetree/bindings/arm/arch_timer.txt +2
-0+- hisilicon,erratum-161x01 : A boolean property. Indicates the presence of + QorIQ erratum 161201, which says that reading the counter isOther than the copy/paste of the FSL erratum, please document the actual erratum number. Is that 161x01 or 161201?
Sorry for the lazy behavior.
Quoted 5 lines
Documentation/devicetree/bindings/arm/arch_timer.txt to deliver its interrupts via SPIs. · line 36
Quoted 1 line
Documentation/devicetree/bindings/arm/arch_timer.txt +1
-0+ unreliable unless the small range of value is returned by back-to-back reads.That's a detail that doesn't belong in the DT, but that would be much better next to the code doing the actual handling.
Got it.
Thanks
Ding
Quoted 12 lines
Documentation/devicetree/bindings/arm/arch_timer.txt to deliver its interrupts via SPIs. · line 42
Quoted 7 lines
Documentation/devicetree/bindings/arm/arch_timer.txt +3
-0+ This also affects writes to the tval register, due to the implicit + counter read. + ** Optional properties: - arm,cpu-registers-not-fw-configured : Firmware does not initializeThanks,
M.
PATCH 1/3 arm64: arch_timer: Add device tree binding for hisilicon-161x01 erratum
In reply to Ding TianhongDocumentation/devicetree/bindings/arm/arch_timer.txt to deliver its interrupts via SPIs. · line 38
Quoted 5 lines · Ding Tianhong
+- hisilicon,erratum-161x01 : A boolean property. Indicates the presence of
Documentation/devicetree/bindings/arm/arch_timer.txt +4
-0+ QorIQ erratum 161201, which says that reading the counter is + unreliable unless the small range of value is returned by back-to-back reads. + This also affects writes to the tval register, due to the implicit + counter read.
Is "161x01" the *exact* erratum number, or is the 'x' a wildcard? Please use the *exact* erratum number, even if that means we have to list several.
Is "161x01" an *erratum* number, or the *part* number of affected devices?
Thanks,
Mark.
PATCH 1/3 arm64: arch_timer: Add device tree binding for hisilicon-161x01 erratum
Quoted 11 lines · Mark Rutland
Documentation/devicetree/bindings/arm/arch_timer.txt to deliver its interrupts via SPIs. · line 38
Quoted 5 lines · Ding Tianhong
+- hisilicon,erratum-161x01 : A boolean property. Indicates the presence of
Documentation/devicetree/bindings/arm/arch_timer.txt +4
-0+ QorIQ erratum 161201, which says that reading the counter is + unreliable unless the small range of value is returned by back-to-back reads. + This also affects writes to the tval register, due to the implicit + counter read.Is "161x01" the *exact* erratum number, or is the 'x' a wildcard? Please use the *exact* erratum number, even if that means we have to list several.
Hi Mark:
The 'x' is a wildcard, it will cover 161001 to 161601 several numbers, I will discuss to the chip develop and get a exact erratum number.
Thanks.
Ding
Quoted 8 lines
Is "161x01" an *erratum* number, or the *part* number of affected devices?
Thanks,
Mark..
PATCH 1/3 arm64: arch_timer: Add device tree binding for hisilicon-161x01 erratum
Quoted 4 lines · Ding Tianhong
Quoted 1 line · Mark Rutland
Is "161x01" the *exact* erratum number, or is the 'x' a wildcard?
The 'x' is a wildcard, it will cover 161001 to 161601 several numbers,
Given you're using a wildcard, I take it that this is a *part* number?
Thanks,
Mark.
PATCH 1/3 arm64: arch_timer: Add device tree binding for hisilicon-161x01 erratum
Quoted 8 lines · Mark Rutland
Quoted 4 lines · Ding Tianhong
Quoted 1 line · Mark Rutland
Is "161x01" the *exact* erratum number, or is the 'x' a wildcard?
The 'x' is a wildcard, it will cover 161001 to 161601 several numbers,
Given you're using a wildcard, I take it that this is a *part* number?
Yes, I was doubt how to fix this, should I choose a better erratum number?
Quoted 5 lines
Thanks,
Mark..
PATCH 1/3 arm64: arch_timer: Add device tree binding for hisilicon-161x01 erratum
Quoted 10 lines · Ding Tianhong
Quoted 7 lines · Mark Rutland
Quoted 4 lines · Ding Tianhong
Quoted 1 line · Mark Rutland
Is "161x01" the *exact* erratum number, or is the 'x' a wildcard?
The 'x' is a wildcard, it will cover 161001 to 161601 several numbers,
Given you're using a wildcard, I take it that this is a *part* number?
Yes, I was doubt how to fix this, should I choose a better erratum number?
Typically, we expect that each vendor has some central database of their errata, with each having a unique ID.
If Huawei do not have such a database, I do not think that we should invent an erratum number here.
Thanks,
Mark.
PATCH 1/3 arm64: arch_timer: Add device tree binding for hisilicon-161x01 erratum
Quoted 10 lines · Mark Rutland
Quoted 9 lines · Ding Tianhong
Quoted 7 lines · Mark Rutland
Quoted 4 lines · Ding Tianhong
Quoted 1 line · Mark Rutland
Is "161x01" the *exact* erratum number, or is the 'x' a wildcard?
The 'x' is a wildcard, it will cover 161001 to 161601 several numbers,
Given you're using a wildcard, I take it that this is a *part* number?
Quoted 8 lines
Quoted 1 line
Yes, I was doubt how to fix this, should I choose a better erratum number?
Typically, we expect that each vendor has some central database of their errata, with each having a unique ID.
If Huawei do not have such a database, I do not think that we should invent an erratum number here.
Hi Marko<
After discussion with our chip developer, we decide the 161601 as the *exact* erratum number for this chip to cover all the problem and register this in our company's database, thanks.
Ding
Quoted 5 lines
Thanks,
Mark..