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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20160621213721.GA27840@roeck-us.net>
Date:	Tue, 21 Jun 2016 14:37:21 -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 Tue, Jun 21, 2016 at 09:43:20PM +0200, Oliver Neukum wrote:
> On Tue, 2016-06-21 at 06:24 -0700, Guenter Roeck wrote:
> > On 06/21/2016 06:08 AM, Oliver Neukum wrote:
> > > On Thu, 2016-05-19 at 15:44 +0300, Heikki Krogerus wrote:
> > >> The purpose of this class is to provide unified interface for user
> > >> space to get the status and basic information about USB Type-C
> > >> Connectors in the system, control data role swapping, and when USB PD
> > >> is available, also power role swapping and Alternate Modes.
> > >
> > > This raises two more questions.
> > >
> > > 1. Booting
> > >
> > > It is possible that our only display and, worse, our source
> > > of power is a display that can be used only in an alternate mode
> > > and is connected via a type C connector.
> > >
> > > We need some kind of boot time support for alternate modes.
> > >
> > > The firmware will surely want to display something. So it is possible
> > > that we start the OS will a valid power contract. How do we deal
> > > with that? Renegotiate?
> > >
> > 
> > In one of my drivers, the PD protocol is running on an EC and the Linux
> 
> Is that code public?
> 
Pretty much, though it is not always up to date. It isn't pushed into an
official chromiumos kernel branch yet, but it is available in the repository
if one knows what to look for.

Unfortunately, it looks like I lost permission to create a sandbox in the
repository. I'll see what I can do to get that fixed.

> > driver is just interfacing it to the typec class. I don't do any renegotiating
> > but just report the port state to the class. What is wrong with that, and why
> > would it not work ?
> 
> It is not wrong. But it is unclear how it would work if we pass control
> between boot loader and OS. If I read the spec for TCPM and TCPC
> correctly, we can read back the voltage, but not the agreed currents,
> maximum currents and suspend rules. Yet we need those for power
> budgeting.
> 
The TCPC would not (necessarily) know that information, unfortunately.
I am not even sure about the negotiated voltage - are you sure the TCPC
would know it ?

> We could reset, but then we leave the alternate mode.
> 
Correct. I wasn't able to find a solution for that problem (yet). Going forward,
I can see that being an issue, for example if the BIOS/ROMMON negotiates a
contract but the TCPM running in the kernel doesn't know about it and thus has
to disconnect and reconnect the port.

Guenter