* 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 :) >It sounds like the root cause needs to be figured out here before we >allow users to start breaking their systems, right? I would prefer that, yes. If we know this we could avoid the black / white listing and make it default on system we know to work fine. >> 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. >> 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. >thanks, > >greg k-h Sebastian -- 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
