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:	Wed, 10 Feb 2016 12:30:42 +0200
From:	Heikki Krogerus <heikki.krogerus@...ux.intel.com>
To:	Greg KH <gregkh@...uxfoundation.org>
Cc:	linux-usb@...r.kernel.org, linux-kernel@...r.kernel.org,
	Mathias Nyman <mathias.nyman@...ux.intel.com>,
	Felipe Balbi <balbi@...nel.org>
Subject: Re: [PATCH 2/3] usb: type-c: USB Type-C Connector System Software
 Interface

On Tue, Feb 09, 2016 at 10:21:55AM -0800, Greg KH wrote:
> On Tue, Feb 09, 2016 at 07:01:22PM +0200, Heikki Krogerus wrote:
> > USB Type-C Connector System Software Interface (UCSI) is a
> > specification that defines registers and data structures
> > used to interface with the USB Type-C connectors on a system.
> > 
> > The specification is public and available at:
> > http://www.intel.com/content/www/us/en/io/universal-serial-bus/usb-type-c-ucsi-spec.html
> > 
> 
> What does this driver / code actually do?  Why is it needed?  What
> interface to the rest of the kernel / userspace does it provide?

I will fix this describe these things in the commit message. I'll just
but some UCSI background in case somebody is interested. So UCSI is in
practice a standard for USB Type-C controllers..

UCSI is the control interface for USB Type-C connectors (regardless
was USB PD supported or not) in MS Windows, so most likely all new HW
platforms designed to work also with Windows that are equipped with
USB Type-C will have UCSI device for controlling the USB Type-C ports.
In some cases the hardware for Type-C will be just a PHY like fusb30x
on these platforms (it's cheaper then USB PD or complete USB Type-C
controller), but in those cases the PHY is probable attached to an EC
or is completely controlled by system FW like BIOS together with any
USB PD communication in cases where USB PD is supported, and is in any
case not visible to the OS. Instead UCSI device is exposed to the OS
to give it means to apply its policies to the USB Type-C port.

> Why would we care about this?

I'll try to explain why it's important to export the control of USB
Type-C ports to the user space in my answer to your comments to the
first patch of this series, the one introducing the class.

But surely everybody agrees that decision about the policies regarding
USB Type-C ports, like which data role to use, do we charge or are we
letting the other end charge, etc., belongs to the user? If you plug
your phone to your desktop, I would imagine that you want to see the
phone primarily as the USB device and the desktop as host, and to
achieve the device role, you don't want to be forced to unplug/replug
your phone from the desktop until you achieve device role, right?

> You need to describe this a lot better than you did...

Sure thing. I'm sorry about the poor description. I send these out too
hastily.


Thanks,

-- 
heikki

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ