Re: [RFC PATCHv2] usb: USB Type-C Connector Class
From: Oliver Neukum
Date: Thu May 19 2016 - 10:50:52 EST
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.
>
> Signed-off-by: Heikki Krogerus <heikki.krogerus@xxxxxxxxxxxxxxx>
> ---
> drivers/usb/Kconfig | 2 +
> drivers/usb/Makefile | 2 +
> drivers/usb/type-c/Kconfig | 7 +
> drivers/usb/type-c/Makefile | 1 +
> drivers/usb/type-c/typec.c | 957 ++++++++++++++++++++++++++++++++++++++++++++
> include/linux/usb/typec.h | 230 +++++++++++
> 6 files changed, 1199 insertions(+)
> create mode 100644 drivers/usb/type-c/Kconfig
> create mode 100644 drivers/usb/type-c/Makefile
> create mode 100644 drivers/usb/type-c/typec.c
> create mode 100644 include/linux/usb/typec.h
>
> Hi,
>
> 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.
>
> As you can see, the Alternate Modes are handled completely differently
> compared to the original proposal. Every Alternate Mode will have
> their own device instance (which will be then later bound to an
> Alternate Mode specific driver once we have the bus), but also every
> partner, cable and cable plug will have their own device instances
> representing them.
That raises a question. If I read the standard correctly, alternate
modes could be combinable. So how do you represent that.
> An other change is that the data role is now handled in two ways.
> The current_data_role file will represent static mode of the port, and
> it will use the names for the roles as they are defined in the spec:
> DFP, UFP and DRP. This file should be used if the port needs to be
> fixed to one specific role with DRP ports. So this approach will
> replace the suggestions for "preferred" data role we had. The
> current_usb_data_role will use values "host" and "device" and it will
> be used for data role swapping when already connected.
Please explain. How does that express DRP but prefered master?
> I Hope I remembered to CC everybody interested.
Alternate modes can be left involuntarily. So we need a method of
notification.
Regards
Oliver