Messages in this thread | | | Date | Tue, 30 May 2017 16:20:00 -0700 | From | Brian Norris <> | Subject | Re: [PATCH] genirq: Check irq disabled & masked states in irq_shutdown |
| |
Hi,
To address a tangent brought up here:
On Sat, May 27, 2017 at 10:16:37AM +0200, Thomas Gleixner wrote: > On Sat, 27 May 2017, jeffy wrote: > > for example when a driver(drivers/net/wireless/marvell/mwifiex/main.c) try to > > do these: > > > > devm_request_irq->irq_startup->irq_enable > > disable_irq <-- disabled and masked > > devm_free_irq->irq_shutdown <-- disable it again > > This driver is broken as hell.
No argument on the general statement :)
> It requests the interrupt _BEFORE_ the whole > thing is initialized. If there is a pending interrupt on that line, it will > explode nicely before it is able to disable the irq. But that's a different > problem.
For that particular interrupt, it's mostly an informational interrupt regarding wakeups. We don't do anything that could blow up there, except report a (spurious) wakeup event. (And this spurious wakeup event only occurs because the Wifi firmware may toggle its "wake" pin even when the system is already awake. A weird behavior...)
So yes, the pattern isn't great, but no, it's not going to blow up, AFAIK.
However, if you were to look at the same driver's .../mwifiex/pcie.c, you would see a similar problem, and you *would* be right if you claimed that things could blow up badly there! mwifiex_pcie_request_irq() is called much too early, and if an interrupt gets queued up at the wrong time, we won't handle it very nicely.
Anyway, I just thought I'd mention it, in case someone else following this thread is curious. Coincidentally, I'm already working on patching this on linux-wireless@.
Side note: for issues like the first problem above, I wonder why there isn't a flag that once could pass to request_irq() that suggests the IRQ should be initially disabled? I know this wouldn't work for shared interrupts (but request_irq() could reject that combination, no?), but it seems like there are plenty of cases where it might be useful. Some devices simply don't have a device-level interrupt mask, and always expect to have a dedicated interrupt. With the status quo, a driver for such a device has to defer their request_irq() until sometimes-inconvient times [1], or else accept some subpar behavior (see above "spurious wakeup reporting").
Regards, Brian
[1] Note that, for one, request_irq() can fail, whereas enable_irq() cannot.
| |