On Wed, 10 Feb 2021, Song Bao Hua (Barry Song) wrote:
On Tue, 9 Feb 2021, Song Bao Hua (Barry Song) wrote:
sonic_interrupt() uses an irq lock within an interrupt handler to avoid issues relating to this. This kind of locking may be needed in the drivers you are trying to patch. Or it might not. Apparently, no-one has looked.
Is the comment in sonic_interrupt() outdated according to this: m68k: irq: Remove IRQF_DISABLED https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?i... http://lkml.iu.edu/hypermail/linux/kernel/1109.2/01687.html
The removal of IRQF_DISABLED isn't relevant to this driver. Commit 77a42796786c ("m68k: Remove deprecated IRQF_DISABLED") did not disable interrupts, it just removed some code to enable them.
The code and comments in sonic_interrupt() are correct. You can confirm this for yourself quite easily using QEMU and a cross-compiler.
and this: genirq: Warn when handler enables interrupts https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?i...
wouldn't genirq report a warning on m68k?
There is no warning from m68k builds. That's because arch_irqs_disabled() returns true when the IPL is non-zero.
So for m68k, the case is arch_irqs_disabled() is true, but interrupts can still come?
Then it seems it is very confusing. If prioritized interrupts can still come while arch_irqs_disabled() is true,
Yes, on m68k CPUs, an IRQ having a priority level higher than the present priority mask will get serviced.
Non-Maskable Interrupt (NMI) is not subject to this rule and gets serviced regardless.
how could spin_lock_irqsave() block the prioritized interrupts?
It raises the the mask level to 7. Again, please see arch/m68k/include/asm/irqflags.h
Isn't arch_irqs_disabled() a status reflection of irq disable API?
Why not?
Are all interrupts (including NMI) masked whenever arch_irqs_disabled() returns true on your platforms?
Thanks Barry