Documentation/driver-api/usb/typec.rst

   1
   2 USB Type-C connector class
   3 ==========================
   4
   5 Introduction
   6 ------------
   7
   8 The typec class is meant for describing the USB Type-C ports in a system to the
   9 user space in unified fashion. The class is designed to provide nothing else
  10 except the user space interface implementation in hope that it can be utilized
  11 on as many platforms as possible.
  12
  13 The platforms are expected to register every USB Type-C port they have with the
  14 class. In a normal case the registration will be done by a USB Type-C or PD PHY
  15 driver, but it may be a driver for firmware interface such as UCSI, driver for
  16 USB PD controller or even driver for Thunderbolt3 controller. This document
  17 considers the component registering the USB Type-C ports with the class as "port
  18 driver".
  19
  20 On top of showing the capabilities, the class also offer user space control over
  21 the roles and alternate modes of ports, partners and cable plugs when the port
  22 driver is capable of supporting those features.
  23
  24 The class provides an API for the port drivers described in this document. The
  25 attributes are described in Documentation/ABI/testing/sysfs-class-typec.
  26
  27 User space interface
  28 --------------------
  29 Every port will be presented as its own device under /sys/class/typec/. The
  30 first port will be named "port0", the second "port1" and so on.
  31
  32 When connected, the partner will be presented also as its own device under
  33 /sys/class/typec/. The parent of the partner device will always be the port it
  34 is attached to. The partner attached to port "port0" will be named
  35 "port0-partner". Full path to the device would be
  36 /sys/class/typec/port0/port0-partner/.
  37
  38 The cable and the two plugs on it may also be optionally presented as their own
  39 devices under /sys/class/typec/. The cable attached to the port "port0" port
  40 will be named port0-cable and the plug on the SOP Prime end (see USB Power
  41 Delivery Specification ch. 2.4) will be named "port0-plug0" and on the SOP
  42 Double Prime end "port0-plug1". The parent of a cable will always be the port,
  43 and the parent of the cable plugs will always be the cable.
  44
  45 If the port, partner or cable plug supports Alternate Modes, every supported
  46 Alternate Mode SVID will have their own device describing them. Note that the
  47 Alternate Mode devices will not be attached to the typec class. The parent of an
  48 alternate mode will be the device that supports it, so for example an alternate
  49 mode of port0-partner will be presented under /sys/class/typec/port0-partner/.
  50 Every mode that is supported will have its own group under the Alternate Mode
  51 device named "mode<index>", for example /sys/class/typec/port0/<alternate
  52 mode>/mode1/. The requests for entering/exiting a mode can be done with "active"
  53 attribute file in that group.
  54
  55 Driver API
  56 ----------
  57
  58 Registering the ports
  59 ~~~~~~~~~~~~~~~~~~~~~
  60
  61 The port drivers will describe every Type-C port they control with struct
  62 typec_capability data structure, and register them with the following API:
  63
  64 .. kernel-doc:: drivers/usb/typec/class.c
  65    :functions: typec_register_port typec_unregister_port
  66
  67 When registering the ports, the prefer_role member in struct typec_capability
  68 deserves special notice. If the port that is being registered does not have
  69 initial role preference, which means the port does not execute Try.SNK or
  70 Try.SRC by default, the member must have value TYPEC_NO_PREFERRED_ROLE.
  71 Otherwise if the port executes Try.SNK by default, the member must have value
  72 TYPEC_DEVICE, and with Try.SRC the value must be TYPEC_HOST.
  73
  74 Registering Partners
  75 ~~~~~~~~~~~~~~~~~~~~
  76
  77 After successful connection of a partner, the port driver needs to register the
  78 partner with the class. Details about the partner need to be described in struct
  79 typec_partner_desc. The class copies the details of the partner during
  80 registration. The class offers the following API for registering/unregistering
  81 partners.
  82
  83 .. kernel-doc:: drivers/usb/typec/class.c
  84    :functions: typec_register_partner typec_unregister_partner
  85
  86 The class will provide a handle to struct typec_partner if the registration was
  87 successful, or NULL.
  88
  89 If the partner is USB Power Delivery capable, and the port driver is able to
  90 show the result of Discover Identity command, the partner descriptor structure
  91 should include handle to struct usb_pd_identity instance. The class will then
  92 create a sysfs directory for the identity under the partner device. The result
  93 of Discover Identity command can then be reported with the following API:
  94
  95 .. kernel-doc:: drivers/usb/typec/class.c
  96    :functions: typec_partner_set_identity
  97
  98 Registering Cables
  99 ~~~~~~~~~~~~~~~~~~
 100
 101 After successful connection of a cable that supports USB Power Delivery
 102 Structured VDM "Discover Identity", the port driver needs to register the cable
 103 and one or two plugs, depending if there is CC Double Prime controller present
 104 in the cable or not. So a cable capable of SOP Prime communication, but not SOP
 105 Double Prime communication, should only have one plug registered. For more
 106 information about SOP communication, please read chapter about it from the
 107 latest USB Power Delivery specification.
 108
 109 The plugs are represented as their own devices. The cable is registered first,
 110 followed by registration of the cable plugs. The cable will be the parent device
 111 for the plugs. Details about the cable need to be described in struct
 112 typec_cable_desc and about a plug in struct typec_plug_desc. The class copies
 113 the details during registration. The class offers the following API for
 114 registering/unregistering cables and their plugs:
 115
 116 .. kernel-doc:: drivers/usb/typec/class.c
 117    :functions: typec_register_cable typec_unregister_cable typec_register_plug typec_unregister_plug
 118
 119 The class will provide a handle to struct typec_cable and struct typec_plug if
 120 the registration is successful, or NULL if it isn't.
 121
 122 If the cable is USB Power Delivery capable, and the port driver is able to show
 123 the result of Discover Identity command, the cable descriptor structure should
 124 include handle to struct usb_pd_identity instance. The class will then create a
 125 sysfs directory for the identity under the cable device. The result of Discover
 126 Identity command can then be reported with the following API:
 127
 128 .. kernel-doc:: drivers/usb/typec/class.c
 129    :functions: typec_cable_set_identity
 130
 131 Notifications
 132 ~~~~~~~~~~~~~
 133
 134 When the partner has executed a role change, or when the default roles change
 135 during connection of a partner or cable, the port driver must use the following
 136 APIs to report it to the class:
 137
 138 .. kernel-doc:: drivers/usb/typec/class.c
 139    :functions: typec_set_data_role typec_set_pwr_role typec_set_vconn_role typec_set_pwr_opmode
 140
 141 Alternate Modes
 142 ~~~~~~~~~~~~~~~
 143
 144 USB Type-C ports, partners and cable plugs may support Alternate Modes. Each
 145 Alternate Mode will have identifier called SVID, which is either a Standard ID
 146 given by USB-IF or vendor ID, and each supported SVID can have 1 - 6 modes. The
 147 class provides struct typec_mode_desc for describing individual mode of a SVID,
 148 and struct typec_altmode_desc which is a container for all the supported modes.
 149
 150 Ports that support Alternate Modes need to register each SVID they support with
 151 the following API:
 152
 153 .. kernel-doc:: drivers/usb/typec/class.c
 154    :functions: typec_port_register_altmode
 155
 156 If a partner or cable plug provides a list of SVIDs as response to USB Power
 157 Delivery Structured VDM Discover SVIDs message, each SVID needs to be
 158 registered.
 159
 160 API for the partners:
 161
 162 .. kernel-doc:: drivers/usb/typec/class.c
 163    :functions: typec_partner_register_altmode
 164
 165 API for the Cable Plugs:
 166
 167 .. kernel-doc:: drivers/usb/typec/class.c
 168    :functions: typec_plug_register_altmode
 169
 170 So ports, partners and cable plugs will register the alternate modes with their
 171 own functions, but the registration will always return a handle to struct
 172 typec_altmode on success, or NULL. The unregistration will happen with the same
 173 function:
 174
 175 .. kernel-doc:: drivers/usb/typec/class.c
 176    :functions: typec_unregister_altmode
 177
 178 If a partner or cable plug enters or exits a mode, the port driver needs to
 179 notify the class with the following API:
 180
 181 .. kernel-doc:: drivers/usb/typec/class.c
 182    :functions: typec_altmode_update_active
 183
 184 Multiplexer/DeMultiplexer Switches
 185 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 186
 187 USB Type-C connectors may have one or more mux/demux switches behind them. Since
 188 the plugs can be inserted right-side-up or upside-down, a switch is needed to
 189 route the correct data pairs from the connector to the USB controllers. If
 190 Alternate or Accessory Modes are supported, another switch is needed that can
 191 route the pins on the connector to some other component besides USB. USB Type-C
 192 Connector Class supplies an API for registering those switches.
 193
 194 .. kernel-doc:: drivers/usb/typec/mux.c
 195    :functions: typec_switch_register typec_switch_unregister typec_mux_register typec_mux_unregister
 196
 197 In most cases the same physical mux will handle both the orientation and mode.
 198 However, as the port drivers will be responsible for the orientation, and the
 199 alternate mode drivers for the mode, the two are always separated into their
 200 own logical components: "mux" for the mode and "switch" for the orientation.
 201
 202 When a port is registered, USB Type-C Connector Class requests both the mux and
 203 the switch for the port. The drivers can then use the following API for
 204 controlling them:
 205
 206 .. kernel-doc:: drivers/usb/typec/class.c
 207    :functions: typec_set_orientation typec_set_mode
 208
 209 If the connector is dual-role capable, there may also be a switch for the data
 210 role. USB Type-C Connector Class does not supply separate API for them. The
 211 port drivers can use USB Role Class API with those.
 212
 213 Illustration of the muxes behind a connector that supports an alternate mode::
 214
 215                      ------------------------
 216                      |       Connector      |
 217                      ------------------------
 218                             |         |
 219                      ------------------------
 220                       \     Orientation    /
 221                        --------------------
 222                                 |
 223                        --------------------
 224                       /        Mode        \
 225                      ------------------------
 226                          /              \
 227       ------------------------        --------------------
 228       |       Alt Mode       |       /      USB Role      \
 229       ------------------------      ------------------------
 230                                          /            \
 231                      ------------------------      ------------------------
 232                      |       USB Host       |      |       USB Device     |
 233                      ------------------------      ------------------------