On Tue, 2011-09-06 at 20:06 +0200, Sebastian Andrzej Siewior wrote: > * Greg KH | 2011-09-06 08:27:13 [-0700]: > > >> + When a USB2 device which support LPM is plugged to a > >> + xHCI host root hub which support software LPM, the > >> + host will run a software LPM test for it; if the device > >> + enters L1 state and resume successfully and the host > >> + supports USB2 hardware LPM, it will enable hardware LPM > >> + for the device and the file shows "enable", otherwise > >> + it shows "disable". You can write those words to the > >> + file to enable/disable USB2 hardware LPM manually only > >> + if the device can perform LPM and the host supports > >> + hardware LPM. When driver suspend the port into U3 > >> + state, it will disable hardware LPM first. > > > >This file should only show up if the device supports this, not for all > >devices like this patch has. > > > >And why would you not enable this for a device that supports this? > > 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. > After re-test I fail to reproduce this symptom... Not sure why, maybe because I tested many devices on two hosts and mixed up the test result somehow. Now all the devices I have show same behavior on the two hosts with different vendor IP. > 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. > That it's what this patchset does. > I did not like the auto-test beacause of the additional memory over head > and the additonal time it takes on every plug. > Every test takes 20ms, plus memory of a u32 and a list_head structure. I think it's OK since even a port reset takes much more time than this. Thanks, Andiry -- 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
