From: Bartosz Golaszewski bgolaszewski@baylibre.com
The timer interrupts specified in commit 3652e2741f42 ("ARM: dts: da850: Add clocks") are wrong but since the current timer code hard-codes them, the bug was never spotted.
This patch must go into stable since, once we introduce a proper clocksource driver, devices with buggy device tree will stop booting.
Fixes: 3652e2741f42 ("ARM: dts: da850: Add clocks") Cc: stable@vger.kernel.org Signed-off-by: Bartosz Golaszewski bgolaszewski@baylibre.com --- arch/arm/boot/dts/da850.dtsi | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/da850.dtsi b/arch/arm/boot/dts/da850.dtsi index 47aa53ba6b92..559659b399d0 100644 --- a/arch/arm/boot/dts/da850.dtsi +++ b/arch/arm/boot/dts/da850.dtsi @@ -476,7 +476,7 @@ clocksource: timer@20000 { compatible = "ti,da830-timer"; reg = <0x20000 0x1000>; - interrupts = <12>, <13>; + interrupts = <21>, <22>; interrupt-names = "tint12", "tint34"; clocks = <&pll0_auxclk>; };
On 11/01/19 10:51 PM, Bartosz Golaszewski wrote:
From: Bartosz Golaszewski bgolaszewski@baylibre.com
The timer interrupts specified in commit 3652e2741f42 ("ARM: dts: da850: Add clocks") are wrong but since the current timer code hard-codes them, the bug was never spotted.
This patch must go into stable since, once we introduce a proper clocksource driver, devices with buggy device tree will stop booting.
Is this the case where someone uses device-tree from a stable tree and kernel from latest mainline?
I have added it to my fixes branch for v5.0 anyway.
Thanks, Sekhar
czw., 17 sty 2019 o 15:23 Sekhar Nori nsekhar@ti.com napisaĆ(a):
On 11/01/19 10:51 PM, Bartosz Golaszewski wrote:
From: Bartosz Golaszewski bgolaszewski@baylibre.com
The timer interrupts specified in commit 3652e2741f42 ("ARM: dts: da850: Add clocks") are wrong but since the current timer code hard-codes them, the bug was never spotted.
This patch must go into stable since, once we introduce a proper clocksource driver, devices with buggy device tree will stop booting.
Is this the case where someone uses device-tree from a stable tree and kernel from latest mainline?
Well, if someone wants to use an old device tree and a newer kernel, then it'll be broken anyway. If we get it to stable then at least the fixed device tree will work in the future. That was my reasoning.
Bart
linux-stable-mirror@lists.linaro.org