Re: [linux-usb-devel] USB glitches after suspend on ppc
On Thu, 07 Apr 2005 09:02:57 +1000 Benjamin Herrenschmidt <[EMAIL PROTECTED]> wrote: > > Interesting. Looks like pci_enable_wake(dev, state, 0) isn't > > actually disabling wakeup on your hardware. (Assuming > > CONFIG_USB_SUSPEND=n; if not, then it's odd that the system went > > back to sleep!) Do you think that might be related to those calls > > manipulating the Apple ASICs being in the OHCI layer rather than up > > nearer the generic PCI glue? (I still think they don't belong in > > USB code -- ohci or usbcore -- at all. If the platform-specific > > PCI hooks don't suffice, they need fixing.) > > There are no platform hooks in the right place for now afaik. Nope, not in upstream, but I used the ohci patch from Paul Mackerras previously. > Anyway, I think Colin's controller is an OHCI/EHCI NEC chip, so not > an Apple ASIC, it's not doing anything in those calls. -- Colin - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [linux-usb-devel] USB glitches after suspend on ppc
On Wed, 6 Apr 2005 13:11:53 -0700 David Brownell <[EMAIL PROTECTED]> wrote: > Interesting. Looks like pci_enable_wake(dev, state, 0) isn't actually > disabling wakeup on your hardware. (Assuming CONFIG_USB_SUSPEND=n; if > not, then it's odd that the system went back to sleep!) Yes, CONFIG_USB_SUSPEND is disabled here. > Do you think > that might be related to those calls manipulating the Apple ASICs > being in the OHCI layer rather than up nearer the generic PCI glue? To be honest, I don't really know :) > Thanks for the testing update. I'm glad to know that there seems to > be only one (minor) glitch that's PPC-specific! Yup, me too, I consider it working quite well now :) > OK, I just posted the patch cleaning up EHCI port power switching; > that should remove the need for that separate patch. (As well as > fixing some minor annoyances.) Seen that, thanks. -- Colin - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [linux-usb-devel] USB glitches after suspend on ppc
On Wed, 6 Apr 2005 13:11:53 -0700 David Brownell [EMAIL PROTECTED] wrote: Interesting. Looks like pci_enable_wake(dev, state, 0) isn't actually disabling wakeup on your hardware. (Assuming CONFIG_USB_SUSPEND=n; if not, then it's odd that the system went back to sleep!) Yes, CONFIG_USB_SUSPEND is disabled here. Do you think that might be related to those calls manipulating the Apple ASICs being in the OHCI layer rather than up nearer the generic PCI glue? To be honest, I don't really know :) Thanks for the testing update. I'm glad to know that there seems to be only one (minor) glitch that's PPC-specific! Yup, me too, I consider it working quite well now :) OK, I just posted the patch cleaning up EHCI port power switching; that should remove the need for that separate patch. (As well as fixing some minor annoyances.) Seen that, thanks. -- Colin - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [linux-usb-devel] USB glitches after suspend on ppc
On Thu, 07 Apr 2005 09:02:57 +1000 Benjamin Herrenschmidt [EMAIL PROTECTED] wrote: Interesting. Looks like pci_enable_wake(dev, state, 0) isn't actually disabling wakeup on your hardware. (Assuming CONFIG_USB_SUSPEND=n; if not, then it's odd that the system went back to sleep!) Do you think that might be related to those calls manipulating the Apple ASICs being in the OHCI layer rather than up nearer the generic PCI glue? (I still think they don't belong in USB code -- ohci or usbcore -- at all. If the platform-specific PCI hooks don't suffice, they need fixing.) There are no platform hooks in the right place for now afaik. Nope, not in upstream, but I used the ohci patch from Paul Mackerras previously. Anyway, I think Colin's controller is an OHCI/EHCI NEC chip, so not an Apple ASIC, it's not doing anything in those calls. -- Colin - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [linux-usb-devel] USB glitches after suspend on ppc
On Wednesday 06 April 2005 4:50 pm, Benjamin Herrenschmidt wrote: > On Wed, 2005-04-06 at 16:28 -0700, David Brownell wrote: > > On Wednesday 06 April 2005 4:02 pm, Benjamin Herrenschmidt wrote: > > > > > > > Thanks for the testing update. I'm glad to know that there seems to > > > > be only one (minor) glitch that's PPC-specific! > > > > > > Which is just an off-the-shelves NEC EHCI chip. > > > > The wakeup-after-suspend hasn't been reported by anyone else. > > Looks like the root hub is set for triggering wakeups on connect, isn't > that just a setting in there ? The old Apple ASIC had a bit somewhere to > control that, but I don't know about the NEC The NEC chip uses PME# for PCI wakeup, which pci_enable_wake(..., 0) is supposed to have disabled. If it's not disabling PME#, that's a bug in the PCI infrastructure on that platform. If some other signal is causing a wakeup, that's a different platform-specific issue. :) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [linux-usb-devel] USB glitches after suspend on ppc
On Wed, 2005-04-06 at 16:28 -0700, David Brownell wrote: > On Wednesday 06 April 2005 4:02 pm, Benjamin Herrenschmidt wrote: > > > > > Thanks for the testing update. I'm glad to know that there seems to > > > be only one (minor) glitch that's PPC-specific! > > > > Which is just an off-the-shelves NEC EHCI chip. > > The wakeup-after-suspend hasn't been reported by anyone else. Looks like the root hub is set for triggering wakeups on connect, isn't that just a setting in there ? The old Apple ASIC had a bit somewhere to control that, but I don't know about the NEC Ben. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [linux-usb-devel] USB glitches after suspend on ppc
On Wednesday 06 April 2005 4:02 pm, Benjamin Herrenschmidt wrote: > > > Thanks for the testing update. I'm glad to know that there seems to > > be only one (minor) glitch that's PPC-specific! > > Which is just an off-the-shelves NEC EHCI chip. The wakeup-after-suspend hasn't been reported by anyone else. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [linux-usb-devel] USB glitches after suspend on ppc
> Interesting. Looks like pci_enable_wake(dev, state, 0) isn't actually > disabling wakeup on your hardware. (Assuming CONFIG_USB_SUSPEND=n; if > not, then it's odd that the system went back to sleep!) Do you think > that might be related to those calls manipulating the Apple ASICs being > in the OHCI layer rather than up nearer the generic PCI glue? (I still > think they don't belong in USB code -- ohci or usbcore -- at all. If > the platform-specific PCI hooks don't suffice, they need fixing.) There are no platform hooks in the right place for now afaik. Anyway, I think Colin's controller is an OHCI/EHCI NEC chip, so not an Apple ASIC, it's not doing anything in those calls. > Thanks for the testing update. I'm glad to know that there seems to > be only one (minor) glitch that's PPC-specific! Which is just an off-the-shelves NEC EHCI chip. > > - once out of two resumes, resume leaves the ports unpowered; so I still > > need my usb-ehci-power.patch that re-powers ports unconditionnaly. > > OK, I just posted the patch cleaning up EHCI port power switching; > that should remove the need for that separate patch. (As well as > fixing some minor annoyances.) > > - Dave > > -- Benjamin Herrenschmidt <[EMAIL PROTECTED]> - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [linux-usb-devel] USB glitches after suspend on ppc
On Wednesday 06 April 2005 10:20 am, Colin Leroy wrote: > On 05 Apr 2005 at 13h04, David Brownell wrote: > > > > > > What kind of work on these is needed so that they get in? > > > > Briefly, given 2.6.12-rc2 plus the patches mentioned above, > > find out what else is needed. > > ... > > How's that sound? > > Nice :) > > Ok, here are the results of my tests with 2.6.12-rc2 and the patches > you sent me applied: > > - plug USB device, sleep, unplug USB device, resume: no more oops > - sleep, plug in USB device: no oops, but it wakes the laptop up for a > few seconds; then, it goes back to sleep. No oops on second resume. I > can live with that :) Interesting. Looks like pci_enable_wake(dev, state, 0) isn't actually disabling wakeup on your hardware. (Assuming CONFIG_USB_SUSPEND=n; if not, then it's odd that the system went back to sleep!) Do you think that might be related to those calls manipulating the Apple ASICs being in the OHCI layer rather than up nearer the generic PCI glue? (I still think they don't belong in USB code -- ohci or usbcore -- at all. If the platform-specific PCI hooks don't suffice, they need fixing.) Thanks for the testing update. I'm glad to know that there seems to be only one (minor) glitch that's PPC-specific! > - once out of two resumes, resume leaves the ports unpowered; so I still > need my usb-ehci-power.patch that re-powers ports unconditionnaly. OK, I just posted the patch cleaning up EHCI port power switching; that should remove the need for that separate patch. (As well as fixing some minor annoyances.) - Dave - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [linux-usb-devel] USB glitches after suspend on ppc
On 05 Apr 2005 at 13h04, David Brownell wrote: Hi, > > There are known issues with USB after suspend/resume (D3 hot) on > > powerpc. > > Also known fixes to some of them, which haven't yet been merged. > I'll repost these as followups to this message, to linux-usb-devel > and CC Colin. They're in the 2.6.12-rc2-mm1 patchset. > > To my understanding, such issues have been around for some time > now, although recent kernels have tossed monkey wrenches into > several other cases that previously worked just fine. (Ergo those > nyet-merged patches...) > > > > For example, plugging or unplugging devices during sleep > > results in oopses at resume; and one time out of two, the USB ports > > are unpowered on resume (because the registers think they are, and > > linux doesn't repower them. but they're not). > > > > Both of these issues have patches available, patches that can be > > found there for example: > > > > http://colino.net/ibookg4/usb-ohci-fixes.patch > > http://colino.net/ibookg4/usb-ehci-power.patch > > > > What kind of work on these is needed so that they get in? > > Briefly, given 2.6.12-rc2 plus the patches mentioned above, > find out what else is needed. > > * The first of them is Paul's patch, and I never got a >response to the questions I asked him about it. > > - 2.6.12-rc2 does have the fix to check for HC_STATE_QUIESCING, >which should supplant the need for a new "suspending" quirk. > > - And the first of those patches waiting merge does update the >handling of IRQs in the PCI-to-USB glue. > > - So the main change from that patch which is unresolved is >moving the PMAC-specific stuff up from the OHCI code into >into the the usb/core/hcd-pci code. Presumably you could >do that? I assume that it really is needed at that layer, >though it'll only relate to OHCI cells on Apple ASICs. > > * As for the second, that looks to be a hardware-specfic issue >that just wouldn't reproduce with the controllers I was using >for PM testing. What I'll do is wrap up an equivalent fix with >some related EHCI updates for power switching, post that, and >ask you to verify that it works (probably simplest to do that >with OHCI non-modular and not loaded). > > How's that sound? Nice :) Ok, here are the results of my tests with 2.6.12-rc2 and the patches you sent me applied: - plug USB device, sleep, unplug USB device, resume: no more oops - sleep, plug in USB device: no oops, but it wakes the laptop up for a few seconds; then, it goes back to sleep. No oops on second resume. I can live with that :) - once out of two resumes, resume leaves the ports unpowered; so I still need my usb-ehci-power.patch that re-powers ports unconditionnaly. -- Colin - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [linux-usb-devel] USB glitches after suspend on ppc
On 05 Apr 2005 at 13h04, David Brownell wrote: Hi, There are known issues with USB after suspend/resume (D3 hot) on powerpc. Also known fixes to some of them, which haven't yet been merged. I'll repost these as followups to this message, to linux-usb-devel and CC Colin. They're in the 2.6.12-rc2-mm1 patchset. To my understanding, such issues have been around for some time now, although recent kernels have tossed monkey wrenches into several other cases that previously worked just fine. (Ergo those nyet-merged patches...) For example, plugging or unplugging devices during sleep results in oopses at resume; and one time out of two, the USB ports are unpowered on resume (because the registers think they are, and linux doesn't repower them. but they're not). Both of these issues have patches available, patches that can be found there for example: http://colino.net/ibookg4/usb-ohci-fixes.patch http://colino.net/ibookg4/usb-ehci-power.patch What kind of work on these is needed so that they get in? Briefly, given 2.6.12-rc2 plus the patches mentioned above, find out what else is needed. * The first of them is Paul's patch, and I never got a response to the questions I asked him about it. - 2.6.12-rc2 does have the fix to check for HC_STATE_QUIESCING, which should supplant the need for a new suspending quirk. - And the first of those patches waiting merge does update the handling of IRQs in the PCI-to-USB glue. - So the main change from that patch which is unresolved is moving the PMAC-specific stuff up from the OHCI code into into the the usb/core/hcd-pci code. Presumably you could do that? I assume that it really is needed at that layer, though it'll only relate to OHCI cells on Apple ASICs. * As for the second, that looks to be a hardware-specfic issue that just wouldn't reproduce with the controllers I was using for PM testing. What I'll do is wrap up an equivalent fix with some related EHCI updates for power switching, post that, and ask you to verify that it works (probably simplest to do that with OHCI non-modular and not loaded). How's that sound? Nice :) Ok, here are the results of my tests with 2.6.12-rc2 and the patches you sent me applied: - plug USB device, sleep, unplug USB device, resume: no more oops - sleep, plug in USB device: no oops, but it wakes the laptop up for a few seconds; then, it goes back to sleep. No oops on second resume. I can live with that :) - once out of two resumes, resume leaves the ports unpowered; so I still need my usb-ehci-power.patch that re-powers ports unconditionnaly. -- Colin - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [linux-usb-devel] USB glitches after suspend on ppc
On Wednesday 06 April 2005 10:20 am, Colin Leroy wrote: On 05 Apr 2005 at 13h04, David Brownell wrote: What kind of work on these is needed so that they get in? Briefly, given 2.6.12-rc2 plus the patches mentioned above, find out what else is needed. ... How's that sound? Nice :) Ok, here are the results of my tests with 2.6.12-rc2 and the patches you sent me applied: - plug USB device, sleep, unplug USB device, resume: no more oops - sleep, plug in USB device: no oops, but it wakes the laptop up for a few seconds; then, it goes back to sleep. No oops on second resume. I can live with that :) Interesting. Looks like pci_enable_wake(dev, state, 0) isn't actually disabling wakeup on your hardware. (Assuming CONFIG_USB_SUSPEND=n; if not, then it's odd that the system went back to sleep!) Do you think that might be related to those calls manipulating the Apple ASICs being in the OHCI layer rather than up nearer the generic PCI glue? (I still think they don't belong in USB code -- ohci or usbcore -- at all. If the platform-specific PCI hooks don't suffice, they need fixing.) Thanks for the testing update. I'm glad to know that there seems to be only one (minor) glitch that's PPC-specific! - once out of two resumes, resume leaves the ports unpowered; so I still need my usb-ehci-power.patch that re-powers ports unconditionnaly. OK, I just posted the patch cleaning up EHCI port power switching; that should remove the need for that separate patch. (As well as fixing some minor annoyances.) - Dave - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [linux-usb-devel] USB glitches after suspend on ppc
Interesting. Looks like pci_enable_wake(dev, state, 0) isn't actually disabling wakeup on your hardware. (Assuming CONFIG_USB_SUSPEND=n; if not, then it's odd that the system went back to sleep!) Do you think that might be related to those calls manipulating the Apple ASICs being in the OHCI layer rather than up nearer the generic PCI glue? (I still think they don't belong in USB code -- ohci or usbcore -- at all. If the platform-specific PCI hooks don't suffice, they need fixing.) There are no platform hooks in the right place for now afaik. Anyway, I think Colin's controller is an OHCI/EHCI NEC chip, so not an Apple ASIC, it's not doing anything in those calls. Thanks for the testing update. I'm glad to know that there seems to be only one (minor) glitch that's PPC-specific! Which is just an off-the-shelves NEC EHCI chip. - once out of two resumes, resume leaves the ports unpowered; so I still need my usb-ehci-power.patch that re-powers ports unconditionnaly. OK, I just posted the patch cleaning up EHCI port power switching; that should remove the need for that separate patch. (As well as fixing some minor annoyances.) - Dave -- Benjamin Herrenschmidt [EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [linux-usb-devel] USB glitches after suspend on ppc
On Wednesday 06 April 2005 4:02 pm, Benjamin Herrenschmidt wrote: Thanks for the testing update. I'm glad to know that there seems to be only one (minor) glitch that's PPC-specific! Which is just an off-the-shelves NEC EHCI chip. The wakeup-after-suspend hasn't been reported by anyone else. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [linux-usb-devel] USB glitches after suspend on ppc
On Wed, 2005-04-06 at 16:28 -0700, David Brownell wrote: On Wednesday 06 April 2005 4:02 pm, Benjamin Herrenschmidt wrote: Thanks for the testing update. I'm glad to know that there seems to be only one (minor) glitch that's PPC-specific! Which is just an off-the-shelves NEC EHCI chip. The wakeup-after-suspend hasn't been reported by anyone else. Looks like the root hub is set for triggering wakeups on connect, isn't that just a setting in there ? The old Apple ASIC had a bit somewhere to control that, but I don't know about the NEC Ben. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [linux-usb-devel] USB glitches after suspend on ppc
On Wednesday 06 April 2005 4:50 pm, Benjamin Herrenschmidt wrote: On Wed, 2005-04-06 at 16:28 -0700, David Brownell wrote: On Wednesday 06 April 2005 4:02 pm, Benjamin Herrenschmidt wrote: Thanks for the testing update. I'm glad to know that there seems to be only one (minor) glitch that's PPC-specific! Which is just an off-the-shelves NEC EHCI chip. The wakeup-after-suspend hasn't been reported by anyone else. Looks like the root hub is set for triggering wakeups on connect, isn't that just a setting in there ? The old Apple ASIC had a bit somewhere to control that, but I don't know about the NEC The NEC chip uses PME# for PCI wakeup, which pci_enable_wake(..., 0) is supposed to have disabled. If it's not disabling PME#, that's a bug in the PCI infrastructure on that platform. If some other signal is causing a wakeup, that's a different platform-specific issue. :) - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [linux-usb-devel] USB glitches after suspend on ppc
On Tuesday 05 April 2005 11:44 am, Colin Leroy wrote: > Hi, > > There are known issues with USB after suspend/resume (D3 hot) on > powerpc. Also known fixes to some of them, which haven't yet been merged. I'll repost these as followups to this message, to linux-usb-devel and CC Colin. They're in the 2.6.12-rc2-mm1 patchset. To my understanding, such issues have been around for some time now, although recent kernels have tossed monkey wrenches into several other cases that previously worked just fine. (Ergo those nyet-merged patches...) > For example, plugging or unplugging devices during sleep > results in oopses at resume; and one time out of two, the USB ports are > unpowered on resume (because the registers think they are, and > linux doesn't repower them. but they're not). > > Both of these issues have patches available, patches that can be found > there for example: > > http://colino.net/ibookg4/usb-ohci-fixes.patch > http://colino.net/ibookg4/usb-ehci-power.patch > > What kind of work on these is needed so that they get in? Briefly, given 2.6.12-rc2 plus the patches mentioned above, find out what else is needed. * The first of them is Paul's patch, and I never got a response to the questions I asked him about it. - 2.6.12-rc2 does have the fix to check for HC_STATE_QUIESCING, which should supplant the need for a new "suspending" quirk. - And the first of those patches waiting merge does update the handling of IRQs in the PCI-to-USB glue. - So the main change from that patch which is unresolved is moving the PMAC-specific stuff up from the OHCI code into into the the usb/core/hcd-pci code. Presumably you could do that? I assume that it really is needed at that layer, though it'll only relate to OHCI cells on Apple ASICs. * As for the second, that looks to be a hardware-specfic issue that just wouldn't reproduce with the controllers I was using for PM testing. What I'll do is wrap up an equivalent fix with some related EHCI updates for power switching, post that, and ask you to verify that it works (probably simplest to do that with OHCI non-modular and not loaded). How's that sound? - Dave - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [linux-usb-devel] USB glitches after suspend on ppc
On Tuesday 05 April 2005 11:44 am, Colin Leroy wrote: Hi, There are known issues with USB after suspend/resume (D3 hot) on powerpc. Also known fixes to some of them, which haven't yet been merged. I'll repost these as followups to this message, to linux-usb-devel and CC Colin. They're in the 2.6.12-rc2-mm1 patchset. To my understanding, such issues have been around for some time now, although recent kernels have tossed monkey wrenches into several other cases that previously worked just fine. (Ergo those nyet-merged patches...) For example, plugging or unplugging devices during sleep results in oopses at resume; and one time out of two, the USB ports are unpowered on resume (because the registers think they are, and linux doesn't repower them. but they're not). Both of these issues have patches available, patches that can be found there for example: http://colino.net/ibookg4/usb-ohci-fixes.patch http://colino.net/ibookg4/usb-ehci-power.patch What kind of work on these is needed so that they get in? Briefly, given 2.6.12-rc2 plus the patches mentioned above, find out what else is needed. * The first of them is Paul's patch, and I never got a response to the questions I asked him about it. - 2.6.12-rc2 does have the fix to check for HC_STATE_QUIESCING, which should supplant the need for a new suspending quirk. - And the first of those patches waiting merge does update the handling of IRQs in the PCI-to-USB glue. - So the main change from that patch which is unresolved is moving the PMAC-specific stuff up from the OHCI code into into the the usb/core/hcd-pci code. Presumably you could do that? I assume that it really is needed at that layer, though it'll only relate to OHCI cells on Apple ASICs. * As for the second, that looks to be a hardware-specfic issue that just wouldn't reproduce with the controllers I was using for PM testing. What I'll do is wrap up an equivalent fix with some related EHCI updates for power switching, post that, and ask you to verify that it works (probably simplest to do that with OHCI non-modular and not loaded). How's that sound? - Dave - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
