Hi,

Rob Weber <rob@gnarbox.com> writes:
>> > If not, is there some mechanism we could implement to reset the
>> > dwc3 when we enter compliance mode? I attempted some sort of mechanism
>> > to reset the link state, but it does not seem to help the issue. I've
>> > attached my patch and the trace events for my attempted workaround to
>> > this email. My initial approach was to transition the link from
>> > Compliance -> SS.Disabled -> Rx.Detect when we detect we've entered
>> > compliance mode. The traces show that the dwc3 just enters LFPS.Polling
>> > and subsequently enters compliance mode, despite the link being reset.
>> 
>> I think you would have to go through the entire Power On Reset
>> sequence, but that's likely to be flakey.
>
> Okay, good to know. I am not confident in this approach as well because of
> the state management / recovery we might have to perform.
>
> I wanted to explain our goal a little bit more in depth in case some
> other apprach might come to mind. Our product supports 3 ways in which
> the user can work with the USB port: Host mode, Mass Storage Mode, and
> Ethernet Mode. Host mode is pretty straightforward. Users will generally
> work with USB mass storage devices and USB-Ethernet adapters in host
> mode. Mass storage mode exposes an internal user data partition using
> f_mass_storage and configfs so the user can connect our product to their
> host computer for backing up data. Ethernet uses the f_ecm and f_rndis
> functions creating an ethernet connection with USB hosts, particularly
> mobile devices, to interact with our mobile applications and servers
> through a wired connection.
>
> We control this functionality through a userspace application written in Go
> that creates the gadget/function configuration in configfs. Given this
> background information, are there any approaches that come to mind, such
> as reconfiguring the gadget? Thanks in advance for your input.

Not really, if it goes into compliance mode, the only way to get it out
of there is with a power-on reset. You can't even change link state back
to U0 as that will just tell dwc3 to walk through the compliance
patterns :-p

I think our best bet is understanding why we're transitioning to
compliance and preventing that.

One question comes to mind: Does this happen *only* with the ethernet
gadget? Does it happen with *all* hosts or just a particular host?

Any chance you can capture a full session with both CATC or Beagle 5000
analyzer and dwc3 tracepoints and send it to me?

>> >           <idle>-0     [003] dNs2   184.588232: dwc3_core: Compliance Mode detected. Attempting recovery routine
>> 
>> Don't we get an interrupt for Compliance mode entry?
>
> Not that I've seen, surprisingly. My compliance mode recovery mechanism
> looks for both compliance mode and loopback mode, neither of which I
> have ever seen in the link state change events.

That's odd, I would expect it to still give the event. Oh well, moving
on :-)

-- 
balbi