On Thu, Jul 30, 2009 at 02:57:48PM -0400, Alan Stern wrote: > > event, even though port0en and port1n are set in USB_RES. Is there any > > way to get UHCI to do this? I'm guessing that the power is being cut to > > the port when it suspends with no device connected. > > No, that doesn't sound right. On the other hand, there's only one way > to find out for certain. Voltmeters do come in handy at times... Thinking about it, I get plug events from EHCI, so it can't be that the port is powered down. Maybe it's something to do with the port switching logic. > UHCI isn't very flexible or configurable. It doesn't sound like > there's anything more you can do about this. Which possibly rules out the ability to do this. > > I've thought of a way that this could be made to work, but it's kind of > > hacky. A generic GPE handler could be registered and then scan all PCIe > > devices for a raised PME bit. > > Something like that is probably needed anyway -- for all PCI devices, > not just PCIe. You have to do this on systems that support PCI-PM but > don't have ACPI. Yes, they'll need to have their own platform hook into this. > > Anyone have any ideas? I've attached the current version of my code, > > which is hacked up in various ways as I try to understand what's going > > on but should give some idea what I'm trying. > > Ugh... Hacked is right. I can't comment on the ACPI stuff, but the > USB parts are a mess. You put stuff in the USB core that really > belongs in the PCI core and you put stuff in the kernel that belongs in > userspace. Of course, there's nothing wrong with doing this as part of > a "proof-of-principle" thing. Yes, I guess the correct model is for this to be in PCI and have the USB code do nothing other than indicate that the PCI device is now idle. -- Matthew Garrett | mjg59@xxxxxxxxxxxxx -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
