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]
Date:	Tue, 21 Jun 2016 21:43:20 +0200
From:	Oliver Neukum <oneukum@...e.com>
To:	Guenter Roeck <linux@...ck-us.net>
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, 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?

> 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.

We could reset, but then we leave the alternate mode.

	Regards
		Oliver


Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ