On Thu, 2023-03-09 at 19:56 +0000, Thinh Nguyen wrote: > On Thu, Mar 09, 2023, Joakim Tjernlund wrote: > > On Thu, 2023-03-09 at 17:32 +0100, Joakim Tjernlund wrote: > > > On Wed, 2023-03-08 at 22:26 +0100, Joakim Tjernlund wrote: > > > > On Wed, 2023-03-08 at 19:58 +0100, gregkh@xxxxxxxxxxxxxxxxxxx wrote: > > > > > On Wed, Mar 08, 2023 at 06:12:51PM +0000, Joakim Tjernlund wrote: > > > > > > On Wed, 2023-03-08 at 18:25 +0100, Greg KH wrote: > > > > > > > On Wed, Mar 08, 2023 at 05:10:17PM +0000, Joakim Tjernlund wrote: > > > > > > > > we are using fsl-ls1043a-rdb based design but with a ls1023a SOC and > > > > > > > > use USB0 in gadget mode running either NCM or RNDIS ethernet on top. > > > > > > > > > > > > > > > > When we connect the gadget to a PC(Linux of Windows) over an USB2 hub, > > > > > > > > networking(NCM or RNDIS) works well. > > > > > > > > > > > > > > > > However, when we connect the gadget directly to the PC/laptop which uses USB3 > > > > > > > > we see something odd: > > > > > > > > Ping from PC to gadget works. > > > > > > > > Ping from gadget to laptop does not. However if we also ping from PC at the same time we > > > > > > > > see gadget to PC start working. > > > > > > > > Seems like ping from the PC tiggers the gadget to see incoming pkgs somehow. > > > > > > > > > > > > > > > > Any idea what might be wrong or how to debug this? > > > > > > > > Kernel 5.15.87 > > > > > > > > > > > > > > 5.15.y is very old, does this also happen on 6.2? > > > > > > > > > > > > > > > > > > > I just tried 6.1.15 and the problem remains, I hope that is close enough ? > > > > > > > > > > It's good enough :) > > > > > > > > > > Have any logs at all that show any problems? > > > > > > > > > No, don't know where to start. There are no errors logged. > > > > > > > > > Also, you might want to > > > > > cc: the dwc3 maintainer... > > > > > > > > I thought I did but that look like old info, added Thinh Nguyen now, thanks > > > > > > > > Jocke > > > > > > > > > > > > > > thanks, > > > > > > > > > > greg k-hj > > > > > > > > > > Found and USBC Dock and connected that between gadget an PC and this also works well. > > > Seems like a hub, regardless of USB2/USB3, make the usb network function in both directions. > > > > > > Found out something interesting, on PC: > > > cd /sys/devices/pci0000:00/0000:00:14.0/usb1/1-1/power # Where my gadget is connected > > > echo 0 > usb2_hardware_lpm > > > > > > Now ping works normally. > > > > > > So LPM does not seem to work properly on gadget. Can I disable LPM somehow > > > on gadget side? > > > > > There's no option in gadget configfs to allow you to do that at the > moment. You can disable LPM in dwc3 controller in the devicetree with > "snps,dis_enblslpm_quirk" instead. Yes, I found that. Thanks. > > If the host puts the gadget in suspend, the gadget won't be able to > communicate with the host until the host wakes the gadget up and starts > talking to the gadget again. The gadget may be able to signal the host > to wakeup via remote wakeup. Did you check if the device is in suspend? > If it's in suspend, is the gadget enabled with remote wakeup? Did the > NCM driver sent a remote wakeup signal to the host? I didn't verify, but > I suspect the NCM gadget driver isn't configured/implemented with remote > wakeup. Then maybe NCM/RNDIS should inform/disable LPM in the device driver? One cannot have half an impl. of this feature. > > You can work around this by disabling LPM, which removes any power > saving as you've tested. Yes, we don't require LPM so this will work for us. > > BR, > Thinh > > > > Jocke > > > > Found some DTS quirks to disable LPM, work fine :) > > One observation: > > > > ping over NCM to Linux PC: > > PING 169.254.100.102 (169.254.100.102): 56 data bytes > > 64 bytes from 169.254.100.102: seq=0 ttl=64 time=2.166 ms > > 64 bytes from 169.254.100.102: seq=1 ttl=64 time=2.168 ms > > 64 bytes from 169.254.100.102: seq=2 ttl=64 time=2.333 ms > > > > ping over NCM to Windows 10 PC: > > PING 169.254.100.102 (169.254.100.102): 56 data bytes > > 64 bytes from 169.254.100.102: seq=0 ttl=128 time=0.921 ms > > 64 bytes from 169.254.100.102: seq=1 ttl=128 time=0.963 ms > > 64 bytes from 169.254.100.102: seq=2 ttl=128 time=1.143 ms > > 64 bytes from 169.254.100.102: seq=3 ttl=128 time=1.161 ms > > > > NCM to Windows appears to have much lower latency. > >
