linux-kernel - Re: [PATCH 2/3] usb: type-c: USB Type-C Connector System Software Interface

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: <20160211135011.GA32213@kuha.fi.intel.com>
Date:	Thu, 11 Feb 2016 15:50:11 +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

Hi Greg,

> > 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?
> 
> No, I don't agree.  It's still unknown if userspace can react fast
> though to these types of "policy" changes.  I've heard from some
> manufacturers that the response time needed is something that we can't
> leave to userspace.

There are no restrictions on when role swapping could to be executed
or when an alt mode can be entered after the connection is made and
an initial role and mode are set. The timing constraints these guys
are most likely talking about are related to the USB PD functions that
need to be executed, for example DR_Swap when the data role swap is
requested and so on. But those are a problem for the drivers that
implement the dr_swap, pr_swap and set_alt_mode, or more likely the
PD stack, and indeed happen inside kernel.

This is probable just a misunderstand. I'm not talking about USB PD
Policy, Device Manager, System Policy Manager or anything else USB PD
spec defines. Those things will indeed happen inside kernel.

My little class is just a high level interface that allows userspace
to request kernel to do things which then end up being executed inside
kernel. There really should not be any problem here.

> And along those lines, do you have a working userspace user of this
> interface?  We don't create interfaces without a user, especially given
> that it takes a long time to ensure that a user/kernel api actually is
> correct.  We would need to see that to ensure that this kernel
> implementation is "correct" and working properly.

No users (well, let me get back on this). I want to force peoples hand
with this early because, if we exclude details about the cable, which
I don't see of any interest to the userspace, the functions and
features USB Type-C spec defines are what I'm presenting, and that's
it. Unless newer versions of USB Type-C connectors bring something
different to the table, the interface is solid. We just need to fine
tune it, agree on what are proper names for the files, etc.

There is just one function that USB Type-C spec has defined that I
have left out of the interface. That is VCONN swapping. I left it out
on purpose as it is cable specific, but I'm now thinking about adding
that as well. It's not like you have to use it, so why not.

> > 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?
> 
> Why is unplugging somehow required?

Because USB Type-C ports (DRP ones) will select the data role randomly
when you connect (to an other DRP port). USB Type-C spec defines that
you can "prefer" host mode, but when both ends prefer host mode, it's
+-0.

Thanks,

-- 
heikki