[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <574FD43E.9080305@roeck-us.net>
Date: Wed, 1 Jun 2016 23:37:50 -0700
From: Guenter Roeck <linux@...ck-us.net>
To: Oliver Neukum <oneukum@...e.com>
Cc: Heikki Krogerus <heikki.krogerus@...ux.intel.com>,
Andy Shevchenko <andy.shevchenko@...il.com>,
Rajaram R <rajaram.officemail@...il.com>,
Felipe Balbi <felipe.balbi@...ux.intel.com>,
Mathias Nyman <mathias.nyman@...ux.intel.com>,
Greg KH <gregkh@...uxfoundation.org>,
linux-kernel@...r.kernel.org, linux-usb@...r.kernel.org
Subject: Re: [RFC PATCHv2] usb: USB Type-C Connector Class
On 06/01/2016 11:24 PM, Oliver Neukum wrote:
> On Wed, 2016-06-01 at 06:34 -0700, Guenter Roeck wrote:
>> The class code would not explicitly learn about the reset,
>> but it would be informed about the exited modes.
>
> That has drawbacks
>
Playing devils advocate a bit here
> - it doesn't tell you what caused the mode to be left (if you
> UFP, it may be the regular command)
Does it matter ?
> - it is a race against your own command
It is my understanding that races have to be resolved by the drivers,
since the typec code does not do any locking. This is quite similar
to handling, say, a request to change the vconn source or to change
the power role. Am I missing something ?
> - it does not work if you are in basic USB mode
>
Would alternate modes be active in that case ?
Thanks,
Guenter
Powered by blists - more mailing lists