Hi, I write: > Peter Chen writes: >>> Felipe Balbi writes: >>> > Kai Ruhnau <kai.ruh...@target-sg.com> 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
