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

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

 



On 07/02/2021 01.22, Arnd Bergmann wrote:
* In the fiq handler code, check if normal interrupts were enabled
   when the fiq hit. Normally they are enabled, so just proceed to
   handle the timer and ipi directly

* if irq was disabled, defer the handling by doing a self-ipi
   through the aic's ipi method, and handle it from there
   when dealing with the next interrupt once interrupts get
   enabled.

This would be similar to the soft-disable feature on powerpc, which
never actually turns off interrupts from regular kernel code but
just checks a flag in local_irq_enable that gets set when a
hardirq happened.

Case #2 seems messy. In AIC, we'd have to either:

* Disable FIQs, and hope that doesn't confuse any save/restore code going on, then set a flag and check it in *both* the IRQ and FIQ path since either might trigger depending on what happens next, or * Mask the relevant timer, which we'd then need to make sure does not confuse the timer code (Unmask it again when we fire the interrupt? But what if the timer code intended to mask it in the interim?)

Neither sounds particularly clean to me... if we had FIQ status masking registers this would be more reasonable, but I'm not sure I'd want the AIC driver to mess with neither DAIF nor the timer registers. It's bad enough that it has to read the latter already (and I hope I can find a better way of doing that...).

Plus I don't know if the vector entry code and other scaffolding between the vector and the AIC driver would be happy with, effectively, recursive interrupts. This could work with a carefully controlled path to make sure it doesn't break things, but I'm not so sure about the current "just point FIQ and IRQ to the same place" approach here.

--
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