-----Original Message-----
From: Finn Thain [mailto:fthain@xxxxxxxxxxxxxxxxxxx]
Sent: Sunday, February 14, 2021 6:11 PM
To: Song Bao Hua (Barry Song) <song.bao.hua@xxxxxxxxxxxxx>
Cc: Arnd Bergmann <arnd@xxxxxxxxxx>; tglx@xxxxxxxxxxxxx;
gregkh@xxxxxxxxxxxxxxxxxxx; arnd@xxxxxxxx; geert@xxxxxxxxxxxxxx;
funaho@xxxxxxxxx; philb@xxxxxxx; corbet@xxxxxxx; mingo@xxxxxxxxxx;
linux-m68k@xxxxxxxxxxxxxxxxxxxx; linux-kernel@xxxxxxxxxxxxxxx
Subject: RE: [RFC] IRQ handlers run with some high-priority interrupts(not NMI)
enabled on some platform
On Sat, 13 Feb 2021, Song Bao Hua (Barry Song) wrote:
So what is really confusing and a pain to me is that:
For years people like me have been writing device drivers
with the idea that irq handlers run with interrupts
disabled after those commits in genirq. So I don't need
to care about if some other IRQs on the same cpu will
jump out to access the data the current IRQ handler
is accessing.
but it turns out the assumption is not true on some platform.
So should I start to program devices driver with the new idea
interrupts can actually come while irqhandler is running?
That's the question which really bothers me.
That scenario seems a little contrived to me (drivers for two or more
devices sharing state through their interrupt handlers). Is it real?
I suppose every platform has its quirks. The irq lock in sonic_interrupt()
is only there because of a platform quirk (the same device can trigger
either of two IRQs). Anyway, no-one expects all drivers to work on all
platforms; I don't know why it bothers you so much when platforms differ.
Basically, we wrote drivers with the assumption that this driver will
be cross-platform. (Of course there are some drivers which can only work
on one platform, for example, if the IP of the device is only used in
one platform as an internal component of a specific SoC.)
So once a device has two or more interrupts, we need to consider one
interrupt might preempt another one on m68k on the same cpu if we also
want to support this driver on m68k. this usually doesn't matter on
other platforms.
on the other hand, there are more than 400 irqs_disabled() in kernel,
I am really not sure if they are running with the knowledge that
the true irqs_disabled() actually means some interrupts are off
and some others are still open on m68k. Or they are running with
the assumption that the true irqs_disabled() means IRQ is totally
quiet? If the latter is true, those drivers might fail to work on
m68k as well.
Thanks
Barry
