No carrier lost information with gadget RNDIS/ECM

No carrier lost information with gadget RNDIS/ECM

[Kai Ruhnau]

Hi,

On my i.MX6 SoloX, I have configured one of the OTG ports for a combined RNDIS/ECM gadget. After boot, I have two network interfaces (usb0 and usb1) which are managed by systemd-networkd.

With kernel 4.9.153, systemd-networkd reports an immediate carrier loss when I pull the USB cable from a Windows or macOS host. With 4.19.53 or 5.1.15 that carrier loss is only reported when I re-attach the cable, meaning there is a "Lost carrier" for the last used interface immediately followed by a "Gained carrier" for the newly connected interface.

I have activated CONFIG_USB_GADGET_DEBUG_FILES, and the contents of /proc/driver/rndis-000 don't change when I pull the cable:
Config Nr. 0
used      : y
state     : RNDIS_DATA_INITIALIZED
medium    : 0x00000000
speed     : 425984000
cable     : connected
vendor ID : 0x00000000
vendor    : (null)

Only when changing the host to a Mac, it's different:
Config Nr. 0
used      : y
state     : RNDIS_UNINITIALIZED
medium    : 0x00000000
speed     : 425984000
cable     : connected
vendor ID : 0x00000000
vendor    : (null)

Thanks for any help.

Cheers,
Kai

Re: No carrier lost information with gadget RNDIS/ECM

[Felipe Balbi]

Hi,

Kai Ruhnau <kai.ruhnau@target-sg.com> writes:
> On my i.MX6 SoloX, I have configured one of the OTG ports for a
> combined RNDIS/ECM gadget. After boot, I have two network interfaces
> (usb0 and usb1) which are managed by systemd-networkd.
>
> With kernel 4.9.153, systemd-networkd reports an immediate carrier
> loss when I pull the USB cable from a Windows or macOS host. With
> 4.19.53 or 5.1.15 that carrier loss is only reported when I re-attach
> the cable, meaning there is a "Lost carrier" for the last used
> interface immediately followed by a "Gained carrier" for the newly
> connected interface.

First of all, thanks for actually testing the most recent stable
kernels. Much appreciated :-)

> I have activated CONFIG_USB_GADGET_DEBUG_FILES, and the contents of
> /proc/driver/rndis-000 don't change when I pull the cable:
>
> Config Nr. 0
> used      : y
> state     : RNDIS_DATA_INITIALIZED
> medium    : 0x00000000
> speed     : 425984000
> cable     : connected
> vendor ID : 0x00000000
> vendor    : (null)
>
> Only when changing the host to a Mac, it's different:
> Config Nr. 0
> used      : y
> state     : RNDIS_UNINITIALIZED
> medium    : 0x00000000
> speed     : 425984000
> cable     : connected
> vendor ID : 0x00000000
> vendor    : (null)
>
> Thanks for any help.

Which peripheral controller is this board using? Is it chipidea? dwc2?
dwc3? High Speed or Super Speed?

-- 
balbi

RE: No carrier lost information with gadget RNDIS/ECM

[Kai Ruhnau]

Hi,

Felipe Balbi writes:
> Kai Ruhnau <kai.ruhnau@target-sg.com> writes:
>> On my i.MX6 SoloX, I have configured one of the OTG ports for a 
>> combined RNDIS/ECM gadget. After boot, I have two network interfaces
>> (usb0 and usb1) which are managed by systemd-networkd.
>>
>> With kernel 4.9.153, systemd-networkd reports an immediate carrier 
>> loss when I pull the USB cable from a Windows or macOS host. With
>> 4.19.53 or 5.1.15 that carrier loss is only reported when I re-attach 
>> the cable, meaning there is a "Lost carrier" for the last used 
>> interface immediately followed by a "Gained carrier" for the newly 
>> connected interface.
>
> First of all, thanks for actually testing the most recent stable kernels. Much appreciated :-)

Sure. Having so much support for the i.MX6 in mainline helps a lot :)

>> I have activated CONFIG_USB_GADGET_DEBUG_FILES, and the contents of
>> /proc/driver/rndis-000 don't change when I pull the cable:
>>
>> Config Nr. 0
>> used      : y
>> state     : RNDIS_DATA_INITIALIZED
>> medium    : 0x00000000
>> speed     : 425984000
>> cable     : connected
>> vendor ID : 0x00000000
>> vendor    : (null)
>>
>> Only when changing the host to a Mac, it's different:
>> Config Nr. 0
>> used      : y
>> state     : RNDIS_UNINITIALIZED
>> medium    : 0x00000000
>> speed     : 425984000
>> cable     : connected
>> vendor ID : 0x00000000
>> vendor    : (null)
>>
>> Thanks for any help.
>
> 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

Cheers,
Kai

RE: No carrier lost information with gadget RNDIS/ECM

[Felipe Balbi]

Hi,

Kai Ruhnau <kai.ruhnau@target-sg.com> writes:
>>> I have activated CONFIG_USB_GADGET_DEBUG_FILES, and the contents of
>>> /proc/driver/rndis-000 don't change when I pull the cable:
>>>
>>> Config Nr. 0
>>> used      : y
>>> state     : RNDIS_DATA_INITIALIZED
>>> medium    : 0x00000000
>>> speed     : 425984000
>>> cable     : connected
>>> vendor ID : 0x00000000
>>> vendor    : (null)
>>>
>>> Only when changing the host to a Mac, it's different:
>>> Config Nr. 0
>>> used      : y
>>> state     : RNDIS_UNINITIALIZED
>>> medium    : 0x00000000
>>> speed     : 425984000
>>> cable     : connected
>>> vendor ID : 0x00000000
>>> vendor    : (null)
>>>
>>> Thanks for any help.
>>
>> 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:

$ git --no-pager log --no-merges --oneline v4.9..v5.1 -- drivers/usb/chipidea/udc.c
16caf1fa37db usb: chipidea: Add dynamic pinctrl selection
51b751f112dc USB: chipidea: Remove redundant license text
5fd54ace4721 USB: add SPDX identifiers to all remaining files in drivers/usb/
fc5b920c3b9b usb: chipidea: do charger detection in vbus session
581821ae7f7e usb: chipidea: udc: Support SKB alignment quirk
734c58aefcc4 usb: chipidea: udc: compress return logic into line
aa1f058d7d92 usb: chipidea: udc: fix NULL pointer dereference if udc_start failed
a932a8041ff9 usb: chipidea: core: add sysfs group
aeb78cda5100 usb: chipidea: use bus->sysdev for DMA configuration
4f4555cfe704 usb: chipidea: udc: update gadget state after bus resume
afff6067b305 usb: chipidea: Drop lock across event_notify during gadget stop
732a4af85e87 usb: chipidea: Remove locking in ci_udc_start()
34445fb4333f usb: chipidea: Properly mark little endian descriptors
63b9e901e461 usb: chipidea: udc: remove unnecessary & operation
a98e25e71d11 usb: chipidea: udc: make use of new usb_endpoint_maxp_mult()

Peter, have you seen the problem described before?

-- 
balbi

RE: No carrier lost information with gadget RNDIS/ECM

[Kai Ruhnau]

Hi,

Felipe Balbi writes:
> Kai Ruhnau <kai.ruhnau@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_runtime_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.

Cheers,
Kai

Re: No carrier lost information with gadget RNDIS/ECM

[Peter Chen]

> Felipe Balbi writes:
> > Kai Ruhnau <kai.ruhnau@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_runtime_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.
>
Hi Kai,

Thanks for reporting that.

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.
Besides, what's your expectation for rndis behaviors for both windows and mac?

Peter

RE: No carrier lost information with gadget RNDIS/ECM

[Kai Ruhnau]

Hi Peter,

Peter Chen writes:
>> Felipe Balbi writes:
>> > Kai Ruhnau <kai.ruhnau@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

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
 
> 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

RE: No carrier lost information with gadget RNDIS/ECM

[Kai Ruhnau]

Hi,

I write:
> Peter Chen writes:
>>> Felipe Balbi writes:
>>> > Kai Ruhnau <kai.ruhnau@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

RE: No carrier lost information with gadget RNDIS/ECM

[Peter Chen]

 
> > 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.
> 

That's very strange, that means the SoC doesn't know VBUS fails down after detaching from the host.
You could measure the VBUS value at the board, then read the VBUS value at register to confirm it.
 I just tried my board (imx6sx-sdb), it worked OK at at v5.2-rc5. If you have
memtool (the tool to read physical memory), you could read register OTGSC
at that time using below command:

The value should like below, bit 9 - bit 11 stands for VBUS value.
# cable attach
root@imx6qpdlsolox:~# /unit_tests/memtool 0x21841a4 1
E
Reading 0x1 count starting at address 0x021841A4

0x021841A4:  09242F20

# cable detach
root@imx6qpdlsolox:~# /unit_tests/memtool 0x21841a4 1
E
Reading 0x1 count starting at address 0x021841A4

0x021841A4:  09341120

If you read the register after detaching the cable, please disable runtime pm using below commands:

for i in $(find /sys -name control | grep usb);do echo on > $i;echo "echo on > $i";done;

> >> 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...
> 
 
You could poll the /sys/class/udc/ci_hdrc.0/state to know the connection.

root@imx6qpdlsolox:~# [  230.074850] configfs-gadget gadget: high-speed config #1: c

root@imx6qpdlsolox:~# cat /sys/class/udc/ci_hdrc.0/state  <=== cable attached
configured
root@imx6qpdlsolox:~# cat /sys/class/udc/ci_hdrc.0/state  <=== cable detached
not attached

Peter

RE: No carrier lost information with gadget RNDIS/ECM

[Kai Ruhnau]

[-- Attachment #1: Type: text/plain, Size: 1400 bytes --]

Hi,

Peter Chen writes:
> That's very strange, that means the SoC doesn't know VBUS fails down after detaching from the host.
> You could measure the VBUS value at the board, then read the VBUS value at register to confirm it.

I have put a scope on VBUS. With kernel 4.9 after detaching, it discharges all the way down to about 500 mV, with 4.19 this discharging stops after about 4 seconds at about 2.4V and remains there.

> I just tried my board (imx6sx-sdb), it worked OK at at v5.2-rc5. If you have
> memtool (the tool to read physical memory), you could read register OTGSC
> at that time using below command:

It's already part of /sys/kernel/debug/ci_hdrc.0/registers, but reading from its memory address works equally well.
> 0x021841A4:  09242F20
Yup, I have 021841a4: 09240f20, which only differs by TOG_1MS.

> # cable detach
> 0x021841A4:  09341120
021841a4: 09340d20
With BSV reflecting the stopped discharge.

> You could poll the /sys/class/udc/ci_hdrc.0/state to know the connection.
>
> root@imx6qpdlsolox:~# [  230.074850] configfs-gadget gadget: high-speed config #1: c
>
> root@imx6qpdlsolox:~# cat /sys/class/udc/ci_hdrc.0/state  <=== cable attached
> configured
> root@imx6qpdlsolox:~# cat /sys/class/udc/ci_hdrc.0/state  <=== cable detached
> not attached

Good to know. The latter turns out as "suspended", though.

Thanks and cheers
Kai


[-- Attachment #2: kernel-4.9-vbus.PNG --]
[-- Type: image/png, Size: 4043 bytes --]

[-- Attachment #3: kernel-4.19-vbus.PNG --]
[-- Type: image/png, Size: 3786 bytes --]

RE: No carrier lost information with gadget RNDIS/ECM

[Peter Chen]

 
> Peter Chen writes:
> > That's very strange, that means the SoC doesn't know VBUS fails down after
> detaching from the host.
> > You could measure the VBUS value at the board, then read the VBUS value at
> register to confirm it.
> 
> I have put a scope on VBUS. With kernel 4.9 after detaching, it discharges all the
> way down to about 500 mV, with 4.19 this discharging stops after about 4 seconds
> at about 2.4V and remains there.
> 

I suspect it is not related to USB, would you please disable USB node at DTS to
measure again?

> > I just tried my board (imx6sx-sdb), it worked OK at at v5.2-rc5. If
> > you have memtool (the tool to read physical memory), you could read
> > register OTGSC at that time using below command:
> 
> It's already part of /sys/kernel/debug/ci_hdrc.0/registers, but reading from its
> memory address works equally well.
> > 0x021841A4:  09242F20
> Yup, I have 021841a4: 09240f20, which only differs by TOG_1MS.
> 
> > # cable detach
> > 0x021841A4:  09341120
> 021841a4: 09340d20
> With BSV reflecting the stopped discharge.
> 
> > You could poll the /sys/class/udc/ci_hdrc.0/state to know the connection.
> >
> > root@imx6qpdlsolox:~# [  230.074850] configfs-gadget gadget:
> > high-speed config #1: c
> >
> > root@imx6qpdlsolox:~# cat /sys/class/udc/ci_hdrc.0/state  <=== cable
> > attached configured root@imx6qpdlsolox:~# cat
> > /sys/class/udc/ci_hdrc.0/state  <=== cable detached not attached
> 
> Good to know. The latter turns out as "suspended", though.
> 

Yes, the bus is "suspended" due to there is no SoF within 3ms, but the disconnection is
not detected due to VBUS is still higher than BSV.

Peter

RE: No carrier lost information with gadget RNDIS/ECM

[Kai Ruhnau]

Hi,

Peter Chen writes: 
>> Peter Chen writes:
>>> That's very strange, that means the SoC doesn't know VBUS fails down 
>>> after detaching from the host.
>>> You could measure the VBUS value at the board, then read the VBUS 
>>> value at register to confirm it.
>> 
>> I have put a scope on VBUS. With kernel 4.9 after detaching, it 
>> discharges all the way down to about 500 mV, with 4.19 this 
>> discharging stops after about 4 seconds at about 2.4V and remains there.
>> 
>
> I suspect it is not related to USB, would you please disable USB node at DTS to measure again?

With USB disabled (&usbotg1 and &usbotg2), VBUS is available when I connect to the host and properly discharged when I disconnect.
I also tried the OTG's host mode yesterday. When I attach a Micro-B plug to A-receptable adapter (and no actual gadget), the GPIO-controlled regulator is turned on and drives VBUS. When I detach it and the board switches back to gadget, the regulator is turned off and VBUS is properly drained.

Cheers,
Kai

RE: No carrier lost information with gadget RNDIS/ECM

[Peter Chen]

 
> >
> > I suspect it is not related to USB, would you please disable USB node at DTS to
> measure again?
> 
> With USB disabled (&usbotg1 and &usbotg2), VBUS is available when I connect to
> the host and properly discharged when I disconnect.
> I also tried the OTG's host mode yesterday. When I attach a Micro-B plug to A-
> receptable adapter (and no actual gadget), the GPIO-controlled regulator is turned
> on and drives VBUS. When I detach it and the board switches back to gadget, the
> regulator is turned off and VBUS is properly drained.
> 

Would you please try disabling charger detection to see if it anything changes?
Do you have any components at VBUS?

diff --git a/drivers/usb/chipidea/udc.c b/drivers/usb/chipidea/udc.c
index 6a5ee8e6da10..70f07a81daa4 100644
--- a/drivers/usb/chipidea/udc.c
+++ b/drivers/usb/chipidea/udc.c
@@ -1524,9 +1524,11 @@ static int ci_udc_vbus_session(struct usb_gadget *_gadget, int is_active)
                gadget_ready = 1;
        spin_unlock_irqrestore(&ci->lock, flags);
 
+       /*
        if (ci->usb_phy)
                usb_phy_set_charger_state(ci->usb_phy, is_active ?
                        USB_CHARGER_PRESENT : USB_CHARGER_ABSENT);
+                       */
 
        if (gadget_ready) {
                if (is_active) {

Peter

RE: No carrier lost information with gadget RNDIS/ECM

[Kai Ruhnau]

Hi Peter,

>> > I suspect it is not related to USB, would you please disable USB 
>> > node at DTS to
>> measure again?
>> 
>> With USB disabled (&usbotg1 and &usbotg2), VBUS is available when I 
>> connect to the host and properly discharged when I disconnect.
>> I also tried the OTG's host mode yesterday. When I attach a Micro-B 
>> plug to A- receptable adapter (and no actual gadget), the 
>> GPIO-controlled regulator is turned on and drives VBUS. When I detach 
>> it and the board switches back to gadget, the regulator is turned off and VBUS is properly drained.
>> 
>
> Would you please try disabling charger detection to see if it anything changes?

No changes. I had already reverted fc5b920c3b9bbe9bf05aeb1c497643608ecb656b for testing.

> Do you have any components at VBUS?

There were ESD protection diodes that connected D+/D- with VBUS.  We removed those from the PCB and the problem is gone meaning VBUS discharges as expected, the controller runtime-suspends and ultimately systemd-networkd reports a lost carrier.
Those diodes haven't been a problem with 4.9, though. Did something change here? I superficially looked at SRP, HNP and ADP, but nothing caught my eye...

Cheers,
Kai

RE: No carrier lost information with gadget RNDIS/ECM

[Peter Chen]

 
> 
> > Do you have any components at VBUS?
> 
> There were ESD protection diodes that connected D+/D- with VBUS.  We removed
> those from the PCB and the problem is gone meaning VBUS discharges as
> expected, the controller runtime-suspends and ultimately systemd-networkd reports
> a lost carrier.
> Those diodes haven't been a problem with 4.9, though. Did something change here?
> I superficially looked at SRP, HNP and ADP, but nothing caught my eye...
> 
 
You need to disable OTG stuffs at dts if OTG and OTG_FSM are enabled at configuration.
See below:

 655 &usbotg1 {
 656         vbus-supply = <&reg_usb_otg1_vbus>;
 657         pinctrl-names = "default";
 658         pinctrl-0 = <&pinctrl_usb_otg1_id>;
 659         srp-disable;
 660         hnp-disable;
 661         adp-disable;
 662         status = "okay";
 663 };

Is it available to share your USB part schematic?

Peter 

RE: No carrier lost information with gadget RNDIS/ECM

[Kai Ruhnau]

Hi Peter,

>> 
>> > Do you have any components at VBUS?
>> 
>> There were ESD protection diodes that connected D+/D- with VBUS.  We 
>> removed those from the PCB and the problem is gone meaning VBUS 
>> discharges as expected, the controller runtime-suspends and ultimately 
>> systemd-networkd reports a lost carrier.
>> Those diodes haven't been a problem with 4.9, though. Did something change here?
>> I superficially looked at SRP, HNP and ADP, but nothing caught my eye...
>> 
> 
> You need to disable OTG stuffs at dts if OTG and OTG_FSM are enabled at configuration.
> See below:
>
> 655 &usbotg1 {
> 656         vbus-supply = <&reg_usb_otg1_vbus>;
> 657         pinctrl-names = "default";
> 658         pinctrl-0 = <&pinctrl_usb_otg1_id>;
> 659         srp-disable;
> 660         hnp-disable;
> 661         adp-disable;
> 662         status = "okay";
> 663 };
>
> Is it available to share your USB part schematic?

We have decided to create a hardware revision. Things like the "USB Plugged-In Detector" that drive DP and DN high will charge up VBUS in our current design and are likely one of the (if not "the") contributing factors to the issue. I will ping back when we have the necessary components to test.

Thanks for your help, Peter!

Cheers,
Kai