lkml.org 
[lkml]   [2016]   [May]   [19]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    SubjectRe: [RFC PATCHv2] usb: USB Type-C Connector Class
    From
    Date
    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@linux.intel.com>
    > ---
    > 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


    \
     
     \ /
      Last update: 2016-05-19 17:21    [W:4.085 / U:0.244 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site