Garrett 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.
That is, removing the interrupt handler on suspend and reinstalling on
resume isn't necessary?
> Most of them do, I think.
ohci doesn't.
And ehci apparently has the same problem.
uhci has no suspend/resume support at this time.
Changing ohci like this enables suspend for ohci on my ASUS P2B-LS box,
so that the box does not hang any more on a suspend attempt:
diff -r 5e2f30c0e8dc usr/src/uts/common/io/usb/hcd/openhci/ohci.c
--- a/usr/src/uts/common/io/usb/hcd/openhci/ohci.c Tue Nov 06 02:08:12
2007
-0800
+++ b/usr/src/uts/common/io/usb/hcd/openhci/ohci.c Thu Nov 08 18:14:30
2007
+0100
@@ -7625,6 +7634,12 @@ ohci_intr(caddr_t arg1, caddr_t arg2)
"ohci_intr: Interrupt occurred, arg1 0x%p arg2 0x%p", arg1, arg2);
mutex_enter(&ohcip->ohci_int_mutex);
+
+ /* Don't touch a suspended device */
+ if (ohcip->ohci_hc_soft_state == OHCI_CTLR_SUSPEND_STATE) {
+ mutex_exit(&ohcip->ohci_int_mutex);
+ return (DDI_INTR_UNCLAIMED);
+ }
/*
* Suppose if we switched to the polled mode from the normal
_______________________________________________
driver-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/driver-discuss
