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:	Thu, 18 Feb 2016 17:29:55 +0800
From:	Peter Chen <hzpeterchen@...il.com>
To:	Heikki Krogerus <heikki.krogerus@...ux.intel.com>
Cc:	Greg KH <gregkh@...uxfoundation.org>, 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 Wed, Feb 10, 2016 at 12:30:42PM +0200, Heikki Krogerus wrote:
> 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..
> 

Does this UCSI spec has some similar things with USB Type-C Port
Controller Interface Spec at usb.org? If not, how to co-work
together in future?

Peter

> 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
> --
> To unsubscribe from this list: send the line "unsubscribe linux-usb" in
> the body of a message to majordomo@...r.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

-- 

Best Regards,
Peter Chen

Powered by blists - more mailing lists