Hi, I write: > Peter Chen writes: >>> Felipe Balbi writes: >>> > Kai Ruhnau <kai.ruhnau@xxxxxxxxxxxxx> writes: >>> >>> Which peripheral controller is this board using? Is it chipidea? dwc2? >>> >>> dwc3? High Speed or Super Speed? >>> >> >>> >> According to the device tree it's 'fsl,imx6sx-usb' driven by >>> >> chipidea/ci_hdrc_imx.c When connecting to Windows, the dmesg shows: >>> >> configfs-gadget gadget: high-speed config #2: c >>> > >>> > Okay, adding Peter (chipidea maintainer) to the loop here. There are >>> > a few changes on UDC side of chipidea between 4.9 and 5.1: >>> > >>> > Peter, have you seen the problem described before? >>> >>> Findings today: >>> >>> The "Lost carrier" message comes when the 4.9 kernel enters runtime suspend (ci_controller_suspend). >>> >>> With kernel 4.19, that function is called once during boot with a matching ci_controller_resume when I activate the configfs configuration. After that, the chip does not enter runtime suspend when I pull the USB cable, but does with 4.9. >>> >> Do you mean at v4.9, the ci_controller_suspend is called even you plug in the cable to host? But this does not happen for newer kernel. > > No: With 4.9, I disconnect the USB cable and a few seconds later ci_controller_suspend is called. With 4.19 or 5.1, this doesn't happen anymore (at least in a timely manner). When I came back this morning, I noticed that the kernel log did in fact contain my printk in ci_controller_suspend. However, this was generated more than 14 hours after I disconnected the USB cable. I disconnected the USB connection yesterday between 15:46:56 UTC and 15:51:21 UTC (no syslog entries are in-between those two timestamps) and the printk in ci_controller_suspend was generated at 06:32:19 UTC the today. > > I have rebooted with 4.9: > [ 0.658594] ci_hdrc ci_hdrc.0: entering suspend > # ConfigFS setup in userspace > [ 9.925361] ci_hdrc ci_hdrc.0: leaving suspend > [ 12.081571] ci_hdrc ci_hdrc.0: entering suspend > # Attach a cable > [ 37.869333] ci_hdrc ci_hdrc.0: leaving suspend > # Detach a cable > [ 49.196610] ci_hdrc ci_hdrc.0: entering suspend With 4.9, there are two ci_irq interrupts with OTGSC_BSVIS set (b_sess_valid_event), one when attaching the cable, one when detaching the cable. > And with 4.19: > [ 0.176297] ci_hdrc ci_hdrc.0: entering suspend > # ConfigFS setup in userspace > [ 9.034493] ci_hdrc ci_hdrc.0: leaving suspend > [ 11.128469] ci_hdrc ci_hdrc.0: entering suspend > # Attach a cable > [ 178.712206] ci_hdrc ci_hdrc.0: leaving suspend > # Detach the cable and nothing happens With 4.19, there's only one ci_irq interrupt with OTGSC_BSVIS set (b_sess_valid_event): The one when attaching the cable. There is no IRQ when detaching the cable. >> Besides, what's your expectation for rndis behaviors for both windows and mac > > Going back to the original mail: In my application, I want to detect on my gadget when the USB cable is pulled from or connected to the host. With Kernel 4.9 I am using the carrier state change of the RNDIS or ECM network interface through systemd-networkd. With 4.19 and 5.1 (the two versions I had tested), I get the "Gained carrier" message when I connect for the first time, but after disconnecting, the "Lost carrier" message doesn't appear as with 4.9. In the one test where it appeared, it took over 14 hours... Cheers, Kai
