[PATCH] riscv: dts: k210: fix broken IRQs on hart1

[PATCH] riscv: dts: k210: fix broken IRQs on hart1

[Niklas Cassel]

From: Niklas Cassel <niklas.cassel@wdc.com>

Commit 67d96729a9e7 ("riscv: Update Canaan Kendryte K210 device tree")
incorrectly removed two entries from the PLIC interrupt-controller node's
interrupts-extended property.

The PLIC driver cannot know the mapping between hart contexts and hart ids,
so this information has to be provided by device tree, as specified by the
PLIC device tree binding.

The PLIC driver uses the interrupts-extended property, and initializes the
hart context registers in the exact same order as provided by the
interrupts-extended property.

In other words, if we don't specify the S-mode interrupts, the PLIC driver
will simply initialize the hart0 S-mode hart context with the hart1 M-mode
configuration. It is therefore essential to specify the S-mode IRQs even
though the system itself will only ever be running in M-mode.

Re-add the S-mode interrupts, so that we get working IRQs on hart1 again.

Cc: <stable@vger.kernel.org>
Fixes: 67d96729a9e7 ("riscv: Update Canaan Kendryte K210 device tree")
Signed-off-by: Niklas Cassel <niklas.cassel@wdc.com>
---
 arch/riscv/boot/dts/canaan/k210.dtsi | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/arch/riscv/boot/dts/canaan/k210.dtsi b/arch/riscv/boot/dts/canaan/k210.dtsi
index 56f57118c633..44d338514761 100644
--- a/arch/riscv/boot/dts/canaan/k210.dtsi
+++ b/arch/riscv/boot/dts/canaan/k210.dtsi
@@ -113,7 +113,8 @@ plic0: interrupt-controller@c000000 {
 			compatible = "canaan,k210-plic", "sifive,plic-1.0.0";
 			reg = <0xC000000 0x4000000>;
 			interrupt-controller;
-			interrupts-extended = <&cpu0_intc 11>, <&cpu1_intc 11>;
+			interrupts-extended = <&cpu0_intc 11>, <&cpu0_intc 9>,
+					      <&cpu1_intc 11>, <&cpu1_intc 9>;
 			riscv,ndev = <65>;
 		};
 
-- 
2.35.1

Re: [PATCH] riscv: dts: k210: fix broken IRQs on hart1

[Damien Le Moal]

On 2022/03/01 2:44, Niklas Cassel wrote:
> From: Niklas Cassel <niklas.cassel@wdc.com>
> 
> Commit 67d96729a9e7 ("riscv: Update Canaan Kendryte K210 device tree")
> incorrectly removed two entries from the PLIC interrupt-controller node's
> interrupts-extended property.
> 
> The PLIC driver cannot know the mapping between hart contexts and hart ids,
> so this information has to be provided by device tree, as specified by the
> PLIC device tree binding.
> 
> The PLIC driver uses the interrupts-extended property, and initializes the
> hart context registers in the exact same order as provided by the
> interrupts-extended property.
> 
> In other words, if we don't specify the S-mode interrupts, the PLIC driver
> will simply initialize the hart0 S-mode hart context with the hart1 M-mode
> configuration. It is therefore essential to specify the S-mode IRQs even
> though the system itself will only ever be running in M-mode.
> 
> Re-add the S-mode interrupts, so that we get working IRQs on hart1 again.
> 
> Cc: <stable@vger.kernel.org>
> Fixes: 67d96729a9e7 ("riscv: Update Canaan Kendryte K210 device tree")
> Signed-off-by: Niklas Cassel <niklas.cassel@wdc.com>
> ---
>  arch/riscv/boot/dts/canaan/k210.dtsi | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/arch/riscv/boot/dts/canaan/k210.dtsi b/arch/riscv/boot/dts/canaan/k210.dtsi
> index 56f57118c633..44d338514761 100644
> --- a/arch/riscv/boot/dts/canaan/k210.dtsi
> +++ b/arch/riscv/boot/dts/canaan/k210.dtsi
> @@ -113,7 +113,8 @@ plic0: interrupt-controller@c000000 {
>  			compatible = "canaan,k210-plic", "sifive,plic-1.0.0";
>  			reg = <0xC000000 0x4000000>;
>  			interrupt-controller;
> -			interrupts-extended = <&cpu0_intc 11>, <&cpu1_intc 11>;
> +			interrupts-extended = <&cpu0_intc 11>, <&cpu0_intc 9>,
> +					      <&cpu1_intc 11>, <&cpu1_intc 9>;
>  			riscv,ndev = <65>;
>  		};
>  

Looks good to me.

Reviewed-by: Damien Le Moal <damien.lemoal@wdc.com>

-- 
Damien Le Moal
Western Digital Research

Re: [PATCH] riscv: dts: k210: fix broken IRQs on hart1

[Palmer Dabbelt]

On Thu, 03 Mar 2022 09:59:31 PST (-0800), Damien.LeMoal@wdc.com wrote:
> On 2022/03/01 2:44, Niklas Cassel wrote:
>> From: Niklas Cassel <niklas.cassel@wdc.com>
>> 
>> Commit 67d96729a9e7 ("riscv: Update Canaan Kendryte K210 device tree")
>> incorrectly removed two entries from the PLIC interrupt-controller node's
>> interrupts-extended property.
>> 
>> The PLIC driver cannot know the mapping between hart contexts and hart ids,
>> so this information has to be provided by device tree, as specified by the
>> PLIC device tree binding.
>> 
>> The PLIC driver uses the interrupts-extended property, and initializes the
>> hart context registers in the exact same order as provided by the
>> interrupts-extended property.
>> 
>> In other words, if we don't specify the S-mode interrupts, the PLIC driver
>> will simply initialize the hart0 S-mode hart context with the hart1 M-mode
>> configuration. It is therefore essential to specify the S-mode IRQs even
>> though the system itself will only ever be running in M-mode.
>> 
>> Re-add the S-mode interrupts, so that we get working IRQs on hart1 again.
>> 
>> Cc: <stable@vger.kernel.org>
>> Fixes: 67d96729a9e7 ("riscv: Update Canaan Kendryte K210 device tree")
>> Signed-off-by: Niklas Cassel <niklas.cassel@wdc.com>
>> ---
>>  arch/riscv/boot/dts/canaan/k210.dtsi | 3 ++-
>>  1 file changed, 2 insertions(+), 1 deletion(-)
>> 
>> diff --git a/arch/riscv/boot/dts/canaan/k210.dtsi b/arch/riscv/boot/dts/canaan/k210.dtsi
>> index 56f57118c633..44d338514761 100644
>> --- a/arch/riscv/boot/dts/canaan/k210.dtsi
>> +++ b/arch/riscv/boot/dts/canaan/k210.dtsi
>> @@ -113,7 +113,8 @@ plic0: interrupt-controller@c000000 {
>>  			compatible = "canaan,k210-plic", "sifive,plic-1.0.0";
>>  			reg = <0xC000000 0x4000000>;
>>  			interrupt-controller;
>> -			interrupts-extended = <&cpu0_intc 11>, <&cpu1_intc 11>;
>> +			interrupts-extended = <&cpu0_intc 11>, <&cpu0_intc 9>,
>> +					      <&cpu1_intc 11>, <&cpu1_intc 9>;
>>  			riscv,ndev = <65>;
>>  		};
>>  
> 
> Looks good to me.
> 
> Reviewed-by: Damien Le Moal <damien.lemoal@wdc.com>

Thanks, this is on fixes.

Just FIY: A bunch of WDC email is getting munged on my end.  I wouldn't 
be surprised if it was my fault (my email client is a broken mess), but 
it does seem to be specific to this use case.