[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <574EE452.3000805@roeck-us.net>
Date: Wed, 1 Jun 2016 06:34:10 -0700
From: Guenter Roeck <linux@...ck-us.net>
To: Oliver Neukum <oneukum@...e.com>,
Heikki Krogerus <heikki.krogerus@...ux.intel.com>
Cc: 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 02:04 AM, Oliver Neukum wrote:
> On Wed, 2016-06-01 at 11:23 +0300, Heikki Krogerus wrote:
>> I think we can still add them later if they are still seen as
>> necessity later on, tough I seriously doubt it. It would not be
>> ideal, but adding an attribute should not really break anything,
>> right? Removing would.
>
> However, how do we learn that the other side has triggered a reset?
>
USB PD specification, section 6.8.2.2 (Modal Operation and Hard Reset):
A Hard Reset shall cause all Active Modes to be exited by both Port Partners
and any Cable Plugs (see Section 6.4.4.3.4).
Section 6.4.4.3.4 (Enter Mode Command):
The following events shall also cause the Port Partners and Cable Plug(s) to exit all Active Modes:
- A PD Hard Reset
- The Port Partners or Cable Plug(s) are Detached
- A Cable Reset (only exits the Cable Plug’s Active Modes)
The class code would not explicitly learn about the reset,
but it would be informed about the exited modes.
Guenter
Powered by blists - more mailing lists