On Tue, Sep 06, 2011 at 10:36:33PM +0200, Sebastian Andrzej Siewior wrote: > * Greg KH | 2011-09-06 11:26:04 [-0700]: > > >On Tue, Sep 06, 2011 at 08:06:30PM +0200, Sebastian Andrzej Siewior wrote: > >> According to Andiry's earlier postings there are some devices which > >> support LPM and it works on xhci core from vendor A but it fails on a > >> xhci core from vendor B. Another device works fine on both cores. > >> As of now the root cause for this anomaly remains unknown. > > > >Ok, then how would a user, or a distro, know if it was safe or not to > >enable this? > > Yes, the user should enable on per-device policy and he should know what > he does. Something like powertop could help. If I put my hid-mouse in > suspend then the mouse is dead :) True, but one would hope that the USB industry didn't make the same power management mistakes they did in the past which caused these input devices to fail. But, yeah, I know, real world... > >> The alternative to this approach (user knows best) is to enable LPM for > >> every device uppon connect and every device which failed this test would > >> be added to a per-xhci-hcd black list. > > > >blacklists are a pain to maintain and if at all possible, not something > >you ever want to do. > > The black list is created at runtime after a test failed. So you plug in > the device, the LPM "test" is executed, test fails, device is added on a > black list so it is not re-tested again after the USB reset is > performed. A dynamic blacklist is fine, I just don't want a blacklist that has to be constantly updated with source changes, like we have for some drivers today (usb-storage is an example), if at all possible. > >> I did not like the auto-test beacause of the additional memory over head > >> and the additonal time it takes on every plug. > > > >How much memory and time is this? > > I don't remeber exactly but I think it was u32 for the device identifier > and a list_head for each black list entry. > It is not that much but not necessary. I suggested keeping tree u32 > identifier which would be overwritte after a while but Andiry did not > want to re-test a device which already failed. If the test is automated, that would be good to do, as long as it doesn't take a long time. greg k-h -- 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
