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

[Heikki Krogerus <heikki.krogerus@linux.intel.com>]

Hi Oliver,

On Fri, May 20, 2016 at 04:19:59PM +0200, Oliver Neukum wrote:
> On Thu, 2016-05-19 at 15:44 +0300, Heikki Krogerus wrote:
> > Like I've told some of you guys, I'm trying to implement a bus for
> > the Alternate Modes, but I'm still nowhere near finished with that
> > one, so let's just get the class ready now. The altmode bus should in
> > any case not affect the userspace interface proposed in this patch.
> 
> Is this strictly divorced from USB PD?

The bus can not be tied to the USB PD stack we will have in the
kernel completely, or there is no change of using it with things like
UCSI. It's going to be difficult to achieve that in any case as we
simply won't be able to send and rescieve the VDMs with things like
UCSI, but let's see.

> How do you trigger a cable reset or a USB PD reset?

There needs to be an API, but I'm sure that's not going to be a
problem. The bus and the altmode specific drivers will reside inside
kernel.

But I'm getting the sense that you are thinking about having some
responsibility of USB PD in userspace. Please correct me if I'm wrong.
I don't think it will be possible. I think the role of userspace can
only be the source for high level requests via this interface, like
enter/exit mode and swap role, and receiving the status and details of
the ports, but any knowledge about the requirements regarding those
steps belongs to the kernel. This includes also the knowledge about
stuff like mode dependencies, for example if cable plug has to be in a
certain mode in order for the partner to be able to enter some
specific mode, etc.


Thanks.

-- 
heikki