Pawel Wojcik wrote: > 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.
Sure. The driver has to ensure against such race conditions in the usual way. _______________________________________________ driver-discuss mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/driver-discuss
