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.