ARM64: gic: Do not allow bypass FIQ signals to reach to processor
Subsystems (2)
PATCH 1/1 ARM64: gic: Do not allow bypass FIQ signals to reach to processor
In some case few signals of an IP(like PMU Overflow in APM88xx0x) can be mapped to nLEGACYFIQ, ie nFIQ of CPU. Until ARM64 supports FIQ handling, we will get nice "Bad mode in FIQ handler detected"
Therefore force FIQBypDisGrp1 to '1', so that bypass FIQ signal is not signaled to the processor.
--- drivers/irqchip/irq-gic.c | 9 ++++++++- include/linux/irqchip/arm-gic.h | 1 + 2 files changed, 9 insertions(+), 1 deletion(-)
drivers/irqchip/irq-gic.c +8 -1
@@ -362,7 +362,14 @@ static void gic_cpu_if_up(void)*/ bypass =readl (cpu_base +GIC_CPU_CTRL ); bypass &=GICC_DIS_BYPASS_MASK ; - +#ifdef CONFIG_ARM64 +/* FIXME: when ARM64 starts supporting FIQ mode. +* +* Until ARM64 supports FIQ handling, force FIQBypDisGrp1 to +* '1', so that bypass FIQ signal is not signaled to the processor. +*/ + bypass |=GICC_DIS_BYPASS_FIQ_TO_CPU ; +#endif writel_relaxed (bypass |GICC_ENABLE , cpu_base +GIC_CPU_CTRL ); }
include/linux/irqchip/arm-gic.h +1 -0
@@ -25,6 +25,7 @@#define GICC_INT_PRI_THRESHOLD 0xf0#define GICC_IAR_INT_ID_MASK 0x3ff#define GICC_INT_SPURIOUS 1023 +#define GICC_DIS_BYPASS_FIQ_TO_CPU (1 << 5)#define GICC_DIS_BYPASS_MASK 0x1e0#define GIC_DIST_CTRL 0x000
Signature · 1 line
2.1.0
PATCH 1/1 ARM64: gic: Do not allow bypass FIQ signals to reach to processor
Hi Jason,
Quoted 7 lines · Pratyush Anand
In some case few signals of an IP(like PMU Overflow in APM88xx0x) can be mapped to nLEGACYFIQ, ie nFIQ of CPU. Until ARM64 supports FIQ handling, we will get nice "Bad mode in FIQ handler detected"
Therefore force FIQBypDisGrp1 to '1', so that bypass FIQ signal is not signaled to the processor.
Please review this patch.
~Pratyush
Quoted 39 lines
Signed-off-by Pratyush Anand <[email protected]>--- drivers/irqchip/irq-gic.c | 9 ++++++++- include/linux/irqchip/arm-gic.h | 1 + 2 files changed, 9 insertions(+), 1 deletion(-)drivers/irqchip/irq-gic.c +8
-1@@ -362,7 +362,14 @@ static void gic_cpu_if_up(void)*/ bypass =readl (cpu_base +GIC_CPU_CTRL ); bypass &=GICC_DIS_BYPASS_MASK ; - +#ifdef CONFIG_ARM64 +/* FIXME: when ARM64 starts supporting FIQ mode. +* +* Until ARM64 supports FIQ handling, force FIQBypDisGrp1 to +* '1', so that bypass FIQ signal is not signaled to the processor. +*/ + bypass |=GICC_DIS_BYPASS_FIQ_TO_CPU ; +#endif writel_relaxed (bypass |GICC_ENABLE , cpu_base +GIC_CPU_CTRL ); }include/linux/irqchip/arm-gic.h +1
-0@@ -25,6 +25,7 @@#define GICC_INT_PRI_THRESHOLD 0xf0#define GICC_IAR_INT_ID_MASK 0x3ff#define GICC_INT_SPURIOUS 1023 +#define GICC_DIS_BYPASS_FIQ_TO_CPU (1 << 5)#define GICC_DIS_BYPASS_MASK 0x1e0#define GIC_DIST_CTRL 0x000
PATCH 1/1 ARM64: gic: Do not allow bypass FIQ signals to reach to processor
Quoted 7 lines · Pratyush Anand
Hi Jason,
Quoted 4 lines · Pratyush Anand
In some case few signals of an IP(like PMU Overflow in APM88xx0x) can be mapped to nLEGACYFIQ, ie nFIQ of CPU. Until ARM64 supports FIQ handling, we will get nice "Bad mode in FIQ handler detected"
Quoted 5 lines
Quoted 3 lines
Therefore force FIQBypDisGrp1 to '1', so that bypass FIQ signal is not signaled to the processor.
Please review this patch.
ping
Quoted 43 lines
~Pratyush
Quoted 40 lines
Signed-off-by Pratyush Anand <[email protected]>--- drivers/irqchip/irq-gic.c | 9 ++++++++- include/linux/irqchip/arm-gic.h | 1 + 2 files changed, 9 insertions(+), 1 deletion(-)drivers/irqchip/irq-gic.c +8
-1@@ -362,7 +362,14 @@ static void gic_cpu_if_up(void)*/ bypass =readl (cpu_base +GIC_CPU_CTRL ); bypass &=GICC_DIS_BYPASS_MASK ; - +#ifdef CONFIG_ARM64 +/* FIXME: when ARM64 starts supporting FIQ mode. +* +* Until ARM64 supports FIQ handling, force FIQBypDisGrp1 to +* '1', so that bypass FIQ signal is not signaled to the processor. +*/ + bypass |=GICC_DIS_BYPASS_FIQ_TO_CPU ; +#endif writel_relaxed (bypass |GICC_ENABLE , cpu_base +GIC_CPU_CTRL ); }include/linux/irqchip/arm-gic.h +1
-0@@ -25,6 +25,7 @@#define GICC_INT_PRI_THRESHOLD 0xf0#define GICC_IAR_INT_ID_MASK 0x3ff#define GICC_INT_SPURIOUS 1023 +#define GICC_DIS_BYPASS_FIQ_TO_CPU (1 << 5)#define GICC_DIS_BYPASS_MASK 0x1e0#define GIC_DIST_CTRL 0x000
PATCH 1/1 ARM64: gic: Do not allow bypass FIQ signals to reach to processor
Quoted 35 lines · Pratyush Anand
Quoted 7 lines · Pratyush Anand
Hi Jason,
Quoted 4 lines · Pratyush Anand
In some case few signals of an IP(like PMU Overflow in APM88xx0x) can be mapped to nLEGACYFIQ, ie nFIQ of CPU. Until ARM64 supports FIQ handling, we will get nice "Bad mode in FIQ handler detected"
Quoted 5 lines
Quoted 3 lines
Therefore force FIQBypDisGrp1 to '1', so that bypass FIQ signal is not signaled to the processor.
Please review this patch.
ping
Quoted 18 lines
~Pratyush
Quoted 15 lines
Signed-off-by Pratyush Anand <[email protected]>--- drivers/irqchip/irq-gic.c | 9 ++++++++- include/linux/irqchip/arm-gic.h | 1 + 2 files changed, 9 insertions(+), 1 deletion(-)drivers/irqchip/irq-gic.c +0
-1@@ -362,7 +362,14 @@ static void gic_cpu_if_up(void)*/ bypass =readl (cpu_base +GIC_CPU_CTRL ); bypass &=GICC_DIS_BYPASS_MASK ; -
Quoted 8 lines
Quoted 8 lines
drivers/irqchip/irq-gic.c static void gic_cpu_if_up(void) · line 372
Quoted 8 lines
drivers/irqchip/irq-gic.c +8
-0+#ifdef CONFIG_ARM64 +/* FIXME: when ARM64 starts supporting FIQ mode. +* +* Until ARM64 supports FIQ handling, force FIQBypDisGrp1 to +* '1', so that bypass FIQ signal is not signaled to the processor. +*/ + bypass |=GICC_DIS_BYPASS_FIQ_TO_CPU ; +#endif
This doesn't feel like the right approach at all. We have a bypass mask already, for the same HW.
But more importantly, FIQBypDisGrp0 is only available in secure mode, while the arm64 kernel only runs in non-secure. I understand that the APM HW doesn't have a secure mode, but the GIC definitely has.
I suggest you move that change to your firmware, and make sure that the kernel is only presented the non-secure version of the CPU interface.
Thanks,
M.
Quoted 18 lines
Quoted 17 lines
Quoted 17 lines
drivers/irqchip/irq-gic.c +0
-0writel_relaxed (bypass |GICC_ENABLE , cpu_base +GIC_CPU_CTRL ); }include/linux/irqchip/arm-gic.h +1
-0@@ -25,6 +25,7 @@#define GICC_INT_PRI_THRESHOLD 0xf0#define GICC_IAR_INT_ID_MASK 0x3ff#define GICC_INT_SPURIOUS 1023 +#define GICC_DIS_BYPASS_FIQ_TO_CPU (1 << 5)#define GICC_DIS_BYPASS_MASK 0x1e0#define GIC_DIST_CTRL 0x000
Signature · 1 line
Jazz is not dead. It just smells funny...
PATCH 1/1 ARM64: gic: Do not allow bypass FIQ signals to reach to processor
Quoted 48 lines · Marc Zyngier
Quoted 35 lines · Pratyush Anand
Quoted 7 lines · Pratyush Anand
Hi Jason,
Quoted 4 lines · Pratyush Anand
In some case few signals of an IP(like PMU Overflow in APM88xx0x) can be mapped to nLEGACYFIQ, ie nFIQ of CPU. Until ARM64 supports FIQ handling, we will get nice "Bad mode in FIQ handler detected"
Quoted 5 lines
Quoted 3 lines
Therefore force FIQBypDisGrp1 to '1', so that bypass FIQ signal is not signaled to the processor.
Please review this patch.
ping
Quoted 18 lines
~Pratyush
Quoted 15 lines
Signed-off-by Pratyush Anand <[email protected]>--- drivers/irqchip/irq-gic.c | 9 ++++++++- include/linux/irqchip/arm-gic.h | 1 + 2 files changed, 9 insertions(+), 1 deletion(-)drivers/irqchip/irq-gic.c +0
-1@@ -362,7 +362,14 @@ static void gic_cpu_if_up(void)*/ bypass =readl (cpu_base +GIC_CPU_CTRL ); bypass &=GICC_DIS_BYPASS_MASK ; -Quoted 8 lines
Quoted 8 lines
drivers/irqchip/irq-gic.c static void gic_cpu_if_up(void) · line 372
Quoted 8 lines
drivers/irqchip/irq-gic.c +8
-0+#ifdef CONFIG_ARM64 +/* FIXME: when ARM64 starts supporting FIQ mode. +* +* Until ARM64 supports FIQ handling, force FIQBypDisGrp1 to +* '1', so that bypass FIQ signal is not signaled to the processor. +*/ + bypass |=GICC_DIS_BYPASS_FIQ_TO_CPU ; +#endif This doesn't feel like the right approach at all. We have a bypass mask already, for the same HW.
Quoted 7 lines
But more importantly, FIQBypDisGrp0 is only available in secure mode, while the arm64 kernel only runs in non-secure. I understand that the APM HW doesn't have a secure mode, but the GIC definitely has.
I suggest you move that change to your firmware, and make sure that the kernel is only presented the non-secure version of the CPU interface.
Thanks Marc for your input.
~Pratyush