On Tue, Mar 17, 2020 at 08:12:30AM -0700, Doug Anderson wrote: > On Tue, Mar 17, 2020 at 5:10 AM Mark Brown <broonie@xxxxxxxxxx> wrote: > > On Mon, Mar 16, 2020 at 03:20:01PM -0700, Douglas Anderson wrote: > > > > Does this mean that there was an actual concrete message of type > > CMD_NONE or does it mean that there was no message waiting? If there > > was no message then isn't the interrupt spurious? > There is no message of type "CMD_NONE". The "cur_mcmd" field is > basically where in the software state machine we're at: ... > ...so certainly if we see "cur_mcmd == CMD_NONE" in the interrupt > handler we're in an unexpected situation. We don't expect interrupts > while idle. I wouldn't necessarily say it was a spurious interrupt, > though. To say that I'd rather look at the result of this line in the > IRQ handler: > m_irq = readl(se->base + SE_GENI_M_IRQ_STATUS); > ...if that line returns 0 then I would be willing to say it is a > spurious interrupt. Right, that should return IRQ_NONE if there's nothing actually asserted. I think you're right about the state machine though. > C) Do we care to try to detect spurious interrupts (by checking > SE_GENI_M_IRQ_STATUS) and return IRQ_NONE? Right now a spurious > interrupt will be harmless because all of the logic in geni_spi_isr() > doesn't do anything if SE_GENI_M_IRQ_STATUS has no bits set. ...but > it will still return IRQ_HANDLED. I can't imagine anyone ever putting > this device on a shared interrupt, but if it's important I can detect > this and return IRQ_NONE in this case in a v2 of this patch. It's a good idea to return IRQ_NONE not just for the shared interrupt case but also because it lets the error handling code in the genirq core do it's thing and detect bugs - as seems to have happened here. This one was fairly benign but you can also see things like interrupts that are constantly asserted by the hardware where we end up spinning in interrupt handlers.
Attachment:
signature.asc
Description: PGP signature
