Dan Mick wrote: > Pawel Wojcik wrote: > >> Dan Mick wrote: >> >>> Juergen Keil wrote: >>> >>> >>> >>>> How is a driver supposed to behave in such a case, when it has >>>> sucessfully >>>> suspended the device but the interrupt handler is still invoked >>>> because it >>>> is sharing the interrupt with some other device that is not yet >>>> suspended? >>>> >>>> Shouldn't ohci set some flag in its softstate when >>>> ohci_detach(DDI_SUSPEND) >>>> has run, and just return with DDI_INTR_UNCLAIMED from ohci_intr() when >>>> ohci_intr is invoked for such a suspended device? >>>> >>> >>> >>> Certainly return without doing damage, yes, and DDI_INTR_UNCLAIMED >>> seems like the best possible way... >>> >>> I'm surprised suspendable drivers don't do this as a matter of course. >>> >> >> If there is no one actually handling the interrupt, i.e. clearing the >> interrupt on the hardware that is asserting it, wouldn't it cause an >> endless invocation of the interrupt? > > > The scenario is that one driver/device on a shared interrupt has been > quiesced, and can't be causing an interrupt; however, another device > is causing an interrupt; because of the shared-interrupt structure in > Solaris, the suspended device's ISR will be called. It needs to > assert that it can't possibly be causing the interrupt, and allow the > real interrupting device/driver to dispose of it. > > This is the normal "shared path", except that device A is suspended, > and so can't be the cause of the interrupt...but it has to know that > rather than trying to read device registers to figure it out, since > the device reads may not work. > Yes, I understand this scenario. But I was thinking more about the race condition, when the driver is *being* suspended, the hardware generates interrupt before interrupt generation is disabled and the driver interrupt routine was not called yet. Such window may be very small, but I would think it is possible. Rejecting such interrupt with DDI_INTR_UNCLAIMED would cause continuous interrupt calls.
-Pawel _______________________________________________ driver-discuss mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/driver-discuss
