Re: [PATCH 10/18] arm64: Introduce FIQ support

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 07/02/2021 00.37, Marc Zyngier wrote:
See my digression in patch 8. I really wonder what the benefit is to
treat FIQ independently of IRQ, and we might as well generalise
this. We could always panic on getting a FIQ on platforms that don't
expect one.

It'd be good to rope in the other interested parties (Mark for the
early entry code, James for RAS and SError handling).

CCing Mark and James: TL;DR what do you think about unconditionally keeping DAIF.I == DAIF.F, would this break other platforms with spurious FIQs or conversely mask FIQs when we don't want to in some cases? The FIQ vector would remain a panic except on platforms that require using it, via an alternatives patch.

  	kernel_ventry	1, sync				// Synchronous EL1h
  	kernel_ventry	1, irq				// IRQ EL1h
-	kernel_ventry	1, fiq_invalid			// FIQ EL1h
+							// FIQ EL1h
+	kernel_ventry	1, fiq_invalid, 64, irq, ARM64_NEEDS_FIQ

It could be better to create a set of first class FIQ handlers rather
than this alternative target macro. I quickly hacked this instead,
which I find more readable.

I think I ended up with the macro change to keep it 1:1 with IRQ, vs a separate branch... but I didn't think of the fallthrough-with-nop trick, neat. It is definitely is more readable. Are you OK with me pulling this patch in for v2, with your name on it?

-	kernel_ventry	0, fiq_invalid_compat, 32	// FIQ 32-bit EL0
+	kernel_ventry	0, fiq, 32			// FIQ 32-bit EL0

fiq_compat here, right?

--
Hector Martin "marcan" (marcan@xxxxxxxxx)
Public Key: https://mrcn.st/pub



[Index of Archives]     [Device Tree Compilter]     [Device Tree Spec]     [Linux Driver Backports]     [Video for Linux]     [Linux USB Devel]     [Linux PCI Devel]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [XFree86]     [Yosemite Backpacking]


  Powered by Linux