usb: gadget: Add support for disabling U1 and U2 entries
Get series with b4
b4 am [email protected]Versions newest first
- v1 Latest0 of 3 patches 0 repliesNew
Patches in v1 No applies recorded yet
None of the 3 patches the cover letter announces are in this archive.
Reviews trailers per patch
No Reviewed-by, Acked-by or Tested-by trailers for v1 yet.
Cover letter [0/3] usb: gadget: Add support for disabling U1 and U2 entries
Hi Anurag
Quoted 2 lines · Anurag Kumar Vulisha
Hi Claus,
Thanks for testing and voting for this patch.
I have first tested your patches today. My test setup is a ZynqMP device, running kernel 4.14 (Xilinx version) with your patches. I then create an overlay for the devicetree with the new parameters, and unbind/bind the dwc3 driver.
Next I have a host running Windows 10 and a MacBook pro with Type-C ports. For logging the communication I use a Total Phase Beagle USB3 5000 V2 analyzer.
The test showed that OS-X does as expected. When BOS descriptor (bU1DevExtLat and bU2DevExtLat) returns 0, it does not enable LPM.
Windows 10 on the other hand does not, and even though it received 0 as bU1DevExtLat and bU2DevExtLat it send Set Sel with U1SEL 85 us, U1PEL 0 us, U2SEL 85 us and U2PEL 0 us.
Next the Windows 10 host sends the U1 Enable and the U2 enable as Set Device Feature, resulting in the system entering U2.
Quoted 27 lines
Quoted 10 lines
Just today I was making another solution for this feature, using the
configfs instead of the devicetree. Though thinks your solution is better, as it uses the U1DevExitLat and U2DevExitLat instead. I just
added my solution to the bottem of the mail for reference.Your approach below is also good, but you are just avoiding the gadget dwc3
controller from entering into U1 and U2 states by disabling the ACCEPTU1ENA
and ACCEPTU2ENA bits in DCTL but not preventing the host from sending theLG0_U1andLGO_U2link command signaling to the gadget. The host will keep
on trying to get the link into U1 or U2 by sendingLGO_U1orLGO_U2and the
gadget rejects these signals by sending LXU link command. To avoid this extra
overhead I thought that sending zero value in the BOS descriptor's U1DevExitLat and U2DevExitLat fields would be the best option. Host on seeing
U 1 & U2 Exit Latencies doesn't initiate LPM U1 and U2 commands.
Quoted 2 lines
Thanks,
Anurag Kumar Vulisha
Correct that it does not prevent the host from sending LG0_U1 and LG0_U2, and there is your solution better on hosts using the BOS descriptor for disabling LPM. So based on my test with Windows 10, I think we should combine the solutions. To prevent LG0_U1/LG0_U2 when possible and still being able to completely disable U1/U2.
Regarding interface for controlling it. I am very novice regarding Linux kernel development, but would think the BOS descriptor control would be better from a configfs interface then devicetree as I don't see BOS descriptor as hardware specific. I am more in doubt about the forcing of U1/U2 as I did with setting hardware registers, as it control hardware registers. So will like to hear from other more experienced developers.
Regards
Claus