> > > Just to simplify, in this situation, if I had an usb mouse attached to > > > this usb controller and removed the mouse while suspended, would the > > > laptop wakeup? > > > > If the USB controller was enabled for wakeup and was working correctly, > > it would wake up the laptop. USB wakeup events are defined as: new > > connection, disconnection, overcurrent, plus any wakeup requests > > received from devices on the USB bus. > > > > > If so that's not what I most probably want. :) You have a workaround in hand to achieve what you want. > > Maybe we should change the kernel so that the default wakeup setting > > for USB controllers is disabled. I'd rather not go that route. It may well be that there's something odd in the current handling of wakeup events with EHCI. I've not personally touched that particular code in several years now, and a lot of code round it has changed since then. Plus of course, problems that don't reproduce on my hardware can't get much attention from me ... there's something like a factor of ten or more in terms of effort to do that sort of remote debugging. > > Then people would have to enable > > wakeup explicitly if they wanted to be able to start up their system by > > typing on a USB keyboard, for instance. > > Don't know, I guess this could be easy automated in userspace actually. > But if connect/disconnect are wakeup events my vote goes to default to > disabled for usb controllers and manage selective enable with some nice > userspace tool. Not that my opinion counts that much :) A userspace tool would certainly be doable. That's part of why the sysfs wakeup attributes exist: to cope with hardware oddities the kernel doesn't know about, or to cope with user preferences. - Dave - To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
