Re: [RFC PATCHv2] usb: USB Type-C Connector Class

[Guenter Roeck <linux@roeck-us.net>]

On Tue, May 31, 2016 at 11:31:21AM +0300, Heikki Krogerus wrote:
> Hi Oliver,
> 
> On Mon, May 30, 2016 at 03:59:27PM +0200, Oliver Neukum wrote:
> > On Mon, 2016-05-30 at 16:19 +0300, Heikki Krogerus wrote:
> > > Hi guys,
> > > 
> > > I'm attaching a diff instead of full v3. I'm not yet adding attributes
> > > for the reset and cable_reset. I still don't understand what is the
> > > case where the userspace would need to be able to tricker reset? Why
> > > isn't it enough for the userspace to be able to enter/exit modes?
> > > Oliver! Can you please comment?
> > 
> > 1. Because we need error handling.
> >    Devices crash. Cables will crash. We will get out of sync.
> >    You never put yourself in a place where you cannot handle an
> >    IO error.
> > 2. Because it is in the spec. We do not second guess the spec.
> >    We implement it.
> 
> Error conditions and crashes are the responsibility of the USB PD
> stack, not userspace. In those cases the stack can not wait for a
> command from the userspace. So for example if a timer like
> NoResponseTimer times out, the stack an its state machines will have
> to take care of the reset quite independently.
> 
Agreed.

> If you get out of sync with an alternate mode, you reset that specific
> alternate mode by exiting and re-entering it, and you do not reset the
> entire PD connection, port, partner or cable.
> 
> The resets from userspace would be purely unsolicited. What would the
> cases where we would need to tricker a reset like that?
> 
> I want to be careful with exposing reset to userspace. Reset in USB PD
> is not just an IO related thing. When you tricker a reset with USB PD,
> even if it's a soft reset, it may lead into hard reset, which may

It may also lead to and trigger error recovery, which is pretty much
similar to physical disconnect and reconnect.

> potentially lead into sudden voltage and current drop, which may lead
> into the entire system crashing. We really need to understand the
> cases where it would be necessary to tricker a reset from userspace.
> Right now I don't see any.
> 
Me not either, really. Error conditions are notoriously difficult to handle.
I can get devices with external power into a state where even error recovery
doesn't bring the USB-PD connection back to operational mode - it is sometimes
necessary to disconnect power. With that in mind, not only is a reset from user
space risky, it may actually make the situation worse. That will hopefully
change over time, as the protocol implementations stabilize, but right now I am
very hesitant to add another variable into the picture - especially if the
benefits are not clear.

Thanks,
Guenter