Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1330485 > unrolled thread

[PATCH 0/3] usb: USB Type-C Class and driver for UCSI

Back to article view | Back to linux.kernel

Contents

  [PATCH 0/3] usb: USB Type-C Class and driver for UCSI Heikki Krogerus <heikki.krogerus@linux.intel.com> - 2016-02-09 18:10 +0100
    [PATCH 2/3] usb: type-c: USB Type-C Connector System Software Interface Heikki Krogerus <heikki.krogerus@linux.intel.com> - 2016-02-09 18:10 +0100
      Re: [PATCH 2/3] usb: type-c: USB Type-C Connector System Software  Interface Greg KH <gregkh@linuxfoundation.org> - 2016-02-09 19:30 +0100
        Re: [PATCH 2/3] usb: type-c: USB Type-C Connector System Software  Interface Heikki Krogerus <heikki.krogerus@linux.intel.com> - 2016-02-10 11:40 +0100
          Re: [PATCH 2/3] usb: type-c: USB Type-C Connector System Software  Interface Greg KH <gregkh@linuxfoundation.org> - 2016-02-10 18:30 +0100
            Re: [PATCH 2/3] usb: type-c: USB Type-C Connector System Software  Interface Heikki Krogerus <heikki.krogerus@linux.intel.com> - 2016-02-11 15:10 +0100
              Re: [PATCH 2/3] usb: type-c: USB Type-C Connector System Software  Interface Oliver Neukum <oneukum@suse.com> - 2016-02-15 16:40 +0100
                Re: [PATCH 2/3] usb: type-c: USB Type-C Connector System Software  Interface Heikki Krogerus <heikki.krogerus@linux.intel.com> - 2016-02-16 10:30 +0100
                  Re: [PATCH 2/3] usb: type-c: USB Type-C Connector System Software  Interface Oliver Neukum <oneukum@suse.com> - 2016-02-16 14:50 +0100
                    Re: [PATCH 2/3] usb: type-c: USB Type-C Connector System Software  Interface Heikki Krogerus <heikki.krogerus@linux.intel.com> - 2016-02-17 09:00 +0100
                      Re: [PATCH 2/3] usb: type-c: USB Type-C Connector System Software  Interface Oliver Neukum <oneukum@suse.com> - 2016-02-17 10:10 +0100
                        Re: [PATCH 2/3] usb: type-c: USB Type-C Connector System Software Interface Felipe Balbi <balbif@gmail.com> - 2016-02-17 11:40 +0100
                          Re: [PATCH 2/3] usb: type-c: USB Type-C Connector System Software  Interface Oliver Neukum <oneukum@suse.com> - 2016-02-17 11:40 +0100
                            Re: [PATCH 2/3] usb: type-c: USB Type-C Connector System Software  Interface Heikki Krogerus <heikki.krogerus@linux.intel.com> - 2016-02-17 12:20 +0100
                              Re: [PATCH 2/3] usb: type-c: USB Type-C Connector System Software Interface Felipe Balbi <balbi@kernel.org> - 2016-02-17 14:40 +0100
                                Re: [PATCH 2/3] usb: type-c: USB Type-C Connector System Software  Interface Heikki Krogerus <heikki.krogerus@linux.intel.com> - 2016-02-17 15:30 +0100
                                  Re: [PATCH 2/3] usb: type-c: USB Type-C Connector System Software  Interface Peter Chen <hzpeterchen@gmail.com> - 2016-02-18 10:20 +0100
                                    Re: [PATCH 2/3] usb: type-c: USB Type-C Connector System Software  Interface Heikki Krogerus <heikki.krogerus@linux.intel.com> - 2016-02-18 11:50 +0100
                                  Re: [PATCH 2/3] usb: type-c: USB Type-C Connector System Software Interface Rajaram R <rajaram.officemail@gmail.com> - 2016-02-18 11:40 +0100
                                    Re: [PATCH 2/3] usb: type-c: USB Type-C Connector System Software  Interface Heikki Krogerus <heikki.krogerus@linux.intel.com> - 2016-02-18 11:50 +0100
                                      Re: [PATCH 2/3] usb: type-c: USB Type-C Connector System Software Interface Rajaram R <rajaram.officemail@gmail.com> - 2016-02-18 12:10 +0100
                            Re: [PATCH 2/3] usb: type-c: USB Type-C Connector System Software Interface Felipe Balbi <balbi@kernel.org> - 2016-02-17 14:40 +0100
                              Re: [PATCH 2/3] usb: type-c: USB Type-C Connector System Software  Interface Oliver Neukum <oneukum@suse.com> - 2016-02-17 15:00 +0100
                                Re: [PATCH 2/3] usb: type-c: USB Type-C Connector System Software Interface Felipe Balbi <balbif@gmail.com> - 2016-02-18 08:10 +0100
                                  Re: [PATCH 2/3] usb: type-c: USB Type-C Connector System Software  Interface Oliver Neukum <oneukum@suse.com> - 2016-02-18 11:30 +0100
                                    Re: [PATCH 2/3] usb: type-c: USB Type-C Connector System Software Interface Felipe Balbi <balbif@gmail.com> - 2016-02-18 11:40 +0100
                                      Re: [PATCH 2/3] usb: type-c: USB Type-C Connector System Software  Interface Oliver Neukum <oneukum@suse.com> - 2016-02-18 11:50 +0100
          Re: [PATCH 2/3] usb: type-c: USB Type-C Connector System Software  Interface Peter Chen <hzpeterchen@gmail.com> - 2016-02-18 10:40 +0100
            Re: [PATCH 2/3] usb: type-c: USB Type-C Connector System Software  Interface Oliver Neukum <oneukum@suse.com> - 2016-02-18 10:50 +0100
      Re: [PATCH 2/3] usb: type-c: USB Type-C Connector System Software  Interface Oliver Neukum <oneukum@suse.com> - 2016-02-10 12:30 +0100
        Re: [PATCH 2/3] usb: type-c: USB Type-C Connector System Software  Interface Heikki Krogerus <heikki.krogerus@linux.intel.com> - 2016-02-10 13:10 +0100
      Re: [PATCH 2/3] usb: type-c: USB Type-C Connector System Software Interface Andy Shevchenko <andy.shevchenko@gmail.com> - 2016-02-10 13:00 +0100
        Re: [PATCH 2/3] usb: type-c: USB Type-C Connector System Software  Interface Oliver Neukum <oneukum@suse.com> - 2016-02-10 14:30 +0100
          Re: [PATCH 2/3] usb: type-c: USB Type-C Connector System Software Interface Andy Shevchenko <andy.shevchenko@gmail.com> - 2016-02-10 15:10 +0100
            Re: [PATCH 2/3] usb: type-c: USB Type-C Connector System Software Interface Bjørn Mork <bjorn@mork.no> - 2016-02-10 16:20 +0100
              Re: [PATCH 2/3] usb: type-c: USB Type-C Connector System Software Interface Andy Shevchenko <andy.shevchenko@gmail.com> - 2016-02-11 09:30 +0100
                Re: [PATCH 2/3] usb: type-c: USB Type-C Connector System Software Interface Bjørn Mork <bjorn@mork.no> - 2016-02-11 10:10 +0100
        Re: [PATCH 2/3] usb: type-c: USB Type-C Connector System Software  Interface Oliver Neukum <oneukum@suse.com> - 2016-02-10 15:20 +0100
          Re: [PATCH 2/3] usb: type-c: USB Type-C Connector System Software Interface Andy Shevchenko <andy.shevchenko@gmail.com> - 2016-02-10 15:30 +0100
            Re: [PATCH 2/3] usb: type-c: USB Type-C Connector System Software  Interface Oliver Neukum <oneukum@suse.de> - 2016-02-10 16:20 +0100
              Fwd: [PATCH 2/3] usb: type-c: USB Type-C Connector System Software Interface Andy Shevchenko <andy.shevchenko@gmail.com> - 2016-02-11 09:20 +0100
                Re: Fwd: [PATCH 2/3] usb: type-c: USB Type-C Connector System  Software Interface Heikki Krogerus <heikki.krogerus@linux.intel.com> - 2016-02-11 15:20 +0100
      Re: [PATCH 2/3] usb: type-c: USB Type-C Connector System Software  Interface Oliver Neukum <oneukum@suse.com> - 2016-02-10 14:10 +0100
        Re: [PATCH 2/3] usb: type-c: USB Type-C Connector System Software  Interface Heikki Krogerus <heikki.krogerus@linux.intel.com> - 2016-02-11 15:10 +0100
    [PATCH 3/3] usb: type-c: UCSI ACPI driver Heikki Krogerus <heikki.krogerus@linux.intel.com> - 2016-02-09 18:10 +0100
      Re: [PATCH 3/3] usb: type-c: UCSI ACPI driver Greg KH <gregkh@linuxfoundation.org> - 2016-02-09 19:30 +0100
        Re: [PATCH 3/3] usb: type-c: UCSI ACPI driver Heikki Krogerus <heikki.krogerus@linux.intel.com> - 2016-02-10 11:30 +0100
    Re: [PATCH 0/3] usb: USB Type-C Class and driver for UCSI Oliver Neukum <oneukum@suse.com> - 2016-02-17 20:00 +0100
      Re: [PATCH 0/3] usb: USB Type-C Class and driver for UCSI Heikki Krogerus <heikki.krogerus@linux.intel.com> - 2016-02-18 10:30 +0100
    Re: [PATCH 0/3] usb: USB Type-C Class and driver for UCSI Rajaram R <rajaram.officemail@gmail.com> - 2016-02-17 20:40 +0100
      Re: [PATCH 0/3] usb: USB Type-C Class and driver for UCSI Heikki Krogerus <heikki.krogerus@linux.intel.com> - 2016-02-18 12:10 +0100
        Re: [PATCH 0/3] usb: USB Type-C Class and driver for UCSI Oliver Neukum <oneukum@suse.com> - 2016-02-18 12:20 +0100

Page 1 of 3  [1] 2 3  Next page →

#1330485 — [PATCH 0/3] usb: USB Type-C Class and driver for UCSI

Hi,

The OS, or more precisely the user space, needs to be able to control
a few things regarding USB Type-C ports. The first thing that must be
allowed to be controlled is the data role. USB Type-C ports will
select the data role randomly with DRP ports. When USB PD is
supported, also independent (from data role) power role swapping can
be supported together with Alternate Mode control.

I'm proposing with this set a Class for the Type-C connectors that
gives the user space control over those things on top of getting basic
details about the USB Type-C connectors and also partners. The details
include the capabilities of the port, the supported data and power
roles, supported accessories (audio and debug), supported Alternate
Modes, USB PD support and of course the type of the partner (USB, Alt
Mode, Accessory or Charger), and more or less the same details about
the partner.

I'm not considering cables with this Class, and I have deliberately
left out some more technical details, like cable orientation, firstly
because I did not see much use for the user space from knowing that
an secondly because that kind of details are not always available for
example with UCSI.

So the interface to the user space is kept as simple as I dared to
make it.

NOTE: In case there is somebody wondering, this is not adding USB PD
support to Linux kernel. This is just about USB Type-C.


Heikki Krogerus (3):
  usb: USB Type-C Connector Class
  usb: type-c: USB Type-C Connector System Software Interface
  usb: type-c: UCSI ACPI driver

 drivers/usb/Kconfig            |   2 +
 drivers/usb/Makefile           |   2 +
 drivers/usb/type-c/Kconfig     |  25 +++
 drivers/usb/type-c/Makefile    |   3 +
 drivers/usb/type-c/typec.c     | 446 ++++++++++++++++++++++++++++++++++++++++
 drivers/usb/type-c/ucsi.c      | 450 +++++++++++++++++++++++++++++++++++++++++
 drivers/usb/type-c/ucsi.h      | 219 ++++++++++++++++++++
 drivers/usb/type-c/ucsi_acpi.c | 133 ++++++++++++
 include/linux/usb/typec.h      | 114 +++++++++++
 9 files changed, 1394 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 drivers/usb/type-c/ucsi.c
 create mode 100644 drivers/usb/type-c/ucsi.h
 create mode 100644 drivers/usb/type-c/ucsi_acpi.c
 create mode 100644 include/linux/usb/typec.h

-- 
2.7.0

[toc] | [next] | [standalone]

#1330489 — [PATCH 2/3] usb: type-c: USB Type-C Connector System Software Interface

USB Type-C Connector System Software Interface (UCSI) is a
specification that defines registers and data structures
used to interface with the USB Type-C connectors on a system.

The specification is public and available at:
http://www.intel.com/content/www/us/en/io/universal-serial-bus/usb-type-c-ucsi-spec.html

Signed-off-by: Heikki Krogerus <heikki.krogerus@linux.intel.com>
---
 drivers/usb/type-c/Kconfig  |   8 +
 drivers/usb/type-c/Makefile |   1 +
 drivers/usb/type-c/ucsi.c   | 450 ++++++++++++++++++++++++++++++++++++++++++++
 drivers/usb/type-c/ucsi.h   | 219 +++++++++++++++++++++
 4 files changed, 678 insertions(+)
 create mode 100644 drivers/usb/type-c/ucsi.c
 create mode 100644 drivers/usb/type-c/ucsi.h

diff --git a/drivers/usb/type-c/Kconfig b/drivers/usb/type-c/Kconfig
index b229fb9..02abd74 100644
--- a/drivers/usb/type-c/Kconfig
+++ b/drivers/usb/type-c/Kconfig
@@ -4,4 +4,12 @@ menu "USB PD and Type-C drivers"
 config TYPEC
 	tristate
 
+config TYPEC_UCSI
+	tristate "USB Type-C Connector System Software Interface"
+	select TYPEC
+	help
+	  USB Type-C Connector System Software Interface (UCSI) describes the
+	  registers and data structures used to interface with the USB Type-C
+	  connectors on a system.
+
 endmenu
diff --git a/drivers/usb/type-c/Makefile b/drivers/usb/type-c/Makefile
index 1012a8b..ab974ba 100644
--- a/drivers/usb/type-c/Makefile
+++ b/drivers/usb/type-c/Makefile
@@ -1 +1,2 @@
 obj-$(CONFIG_TYPEC)		+= typec.o
+obj-$(CONFIG_TYPEC_UCSI)	+= ucsi.o
diff --git a/drivers/usb/type-c/ucsi.c b/drivers/usb/type-c/ucsi.c
new file mode 100644
index 0000000..0107a85
--- /dev/null
+++ b/drivers/usb/type-c/ucsi.c
@@ -0,0 +1,450 @@
+/*
+ * ucsi.c - USB Type-C Connector System Software Interface
+ *
+ * Copyright (C) 2016, Intel Corporation
+ * Author: Heikki Krogerus <heikki.krogerus@linux.intel.com>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include <linux/completion.h>
+#include <linux/device.h>
+#include <linux/module.h>
+#include <linux/slab.h>
+#include <linux/usb/typec.h>
+
+#include "ucsi.h"
+
+#define UCSI_ERROR 1
+#define UCSI_BUSY 2
+
+#define to_ucsi_connector(_port_) container_of(_port_->cap,                    \
+					       struct ucsi_connector,          \
+					       typec_cap)
+
+#define cci_to_connector(_ucsi_, cci) (_ucsi_->connector +		       \
+					UCSI_CCI_CONNECTOR_CHANGE(cci) - 1)
+
+struct ucsi_connector {
+	unsigned num;
+	struct ucsi *ucsi;
+	struct work_struct work;
+	struct typec_port *port;
+	struct typec_capability typec_cap;
+	struct ucsi_connector_capability cap;
+};
+
+struct ucsi {
+	struct device *dev;
+	struct ucsi_ppm *ppm;
+
+	int status;
+	struct completion complete;
+	struct ucsi_capability cap;
+	struct ucsi_connector *connector;
+};
+
+static int ucsi_ack(struct ucsi *ucsi, u8 cmd)
+{
+	struct ucsi_control *ctrl = (void *)&ucsi->ppm->data->control;
+	int ret;
+
+	ucsi->ppm->data->control = 0;
+	ctrl->cmd = UCSI_ACK_CC_CI;
+	ctrl->data = cmd;
+
+	ret = ucsi->ppm->cmd(ucsi->ppm);
+	if (ret)
+		return ret;
+
+	/* Waiting for ACK also with ACK CMD for now */
+	wait_for_completion(&ucsi->complete);
+	return 0;
+}
+
+static int ucsi_run_cmd(struct ucsi *ucsi, void *data, size_t size)
+{
+	int status;
+	int ret;
+
+	dev_vdbg(ucsi->dev, "%s control 0x%llx\n", __func__,
+		 ucsi->ppm->data->control);
+
+	ret = ucsi->ppm->cmd(ucsi->ppm);
+	if (ret)
+		return ret;
+
+	/* REVISIT: We may need to set UCSI_CCI_CMD_COMPLETE flag here */
+	wait_for_completion(&ucsi->complete);
+
+	status = ucsi->status;
+	if (status != UCSI_ERROR && size)
+		memcpy(data, ucsi->ppm->data->message_in, size);
+
+	ret = ucsi_ack(ucsi, UCSI_ACK_CMD);
+	if (ret)
+		goto out;
+
+	if (status == UCSI_ERROR) {
+		u16 error;
+
+		ucsi->ppm->data->control = UCSI_GET_ERROR_STATUS;
+		ret = ucsi->ppm->cmd(ucsi->ppm);
+		if (ret)
+			goto out;
+
+		wait_for_completion(&ucsi->complete);
+
+		/* Something has really gone wrong */
+		if (ucsi->status == UCSI_ERROR) {
+			ret = -ENODEV;
+			goto out;
+		}
+
+		memcpy(&error, ucsi->ppm->data->message_in, sizeof(error));
+
+		ret = ucsi_ack(ucsi, UCSI_ACK_CMD);
+		if (ret)
+			goto out;
+
+		switch (error) {
+		case UCSI_ERROR_INVALID_CON_NUM:
+			ret = -ENXIO;
+			break;
+		case UCSI_ERROR_INCOMPATIBLE_PARTNER:
+		case UCSI_ERROR_CC_COMMUNICATION_ERR:
+		case UCSI_ERROR_CONTRACT_NEGOTIATION_FAIL:
+			ret = -EIO;
+			break;
+		case UCSI_ERROR_DEAD_BATTERY:
+			dev_warn(ucsi->dev, "Dead Battery Condition!\n");
+			ret = -EPERM;
+			break;
+		case UCSI_ERROR_UNREGONIZED_CMD:
+		case UCSI_ERROR_INVALID_CMD_ARGUMENT:
+		default:
+			ret = -EINVAL;
+			break;
+		}
+	}
+out:
+	ucsi->ppm->data->control = 0;
+	return ret;
+}
+
+static int ucsi_dr_swap(struct typec_port *port)
+{
+	struct ucsi_connector *con = to_ucsi_connector(port);
+	struct ucsi_uor_cmd *ctrl = (void *)&con->ucsi->ppm->data->control;
+
+	ctrl->cmd = UCSI_SET_UOR;
+	ctrl->con_num = con->num;
+	ctrl->role = port->data_role == TYPEC_HOST ?
+			UCSI_UOR_ROLE_UFP : UCSI_UOR_ROLE_DFP;
+	if (port->cap->type == TYPEC_PORT_DRP)
+		ctrl->role |= UCSI_UOR_ROLE_DRP;
+
+	return ucsi_run_cmd(con->ucsi, NULL, 0);
+}
+
+static int ucsi_pr_swap(struct typec_port *port)
+{
+	struct ucsi_connector *con = to_ucsi_connector(port);
+	struct ucsi_uor_cmd *ctrl = (void *)&con->ucsi->ppm->data->control;
+
+	/* The command structure is identical to SET_UOR command structure */
+	ctrl->cmd = UCSI_SET_PDR;
+	ctrl->con_num = con->num;
+	ctrl->role = port->pwr_role == TYPEC_PWR_SOURCE ?
+			UCSI_UOR_ROLE_UFP : UCSI_UOR_ROLE_DFP;
+	/* Always accepting power swap requests from partner for now */
+	ctrl->role |= UCSI_UOR_ROLE_DRP;
+
+	return ucsi_run_cmd(con->ucsi, NULL, 0);
+}
+
+static int ucsi_get_constat(struct ucsi_connector *con,
+			    struct ucsi_connector_status *constat)
+{
+	struct ucsi_control *ctrl = (void *)&con->ucsi->ppm->data->control;
+
+	ctrl->cmd = UCSI_GET_CONNECTOR_STATUS;
+	ctrl->data = con->num;
+
+	return ucsi_run_cmd(con->ucsi, constat, sizeof(*constat));
+}
+
+static int
+ucsi_connect(struct ucsi_connector *con, struct ucsi_connector_status *constat)
+{
+	struct typec_port *port = con->port;
+
+	port->connected = true;
+
+	if (constat->partner_flags & UCSI_CONSTAT_PARTNER_FLAG_ALT_MODE)
+		port->partner_type = TYPEC_PARTNER_ALTMODE;
+	else
+		port->partner_type = TYPEC_PARTNER_USB;
+
+	switch (constat->partner_type) {
+	case UCSI_CONSTAT_PARTNER_TYPE_CABLE_NO_UFP:
+		/* REVISIT: We don't care about just the cable for now */
+		return 0;
+	case UCSI_CONSTAT_PARTNER_TYPE_DFP:
+	case UCSI_CONSTAT_PARTNER_TYPE_CABLE_AND_UFP:
+		port->pwr_role = TYPEC_PWR_SINK;
+		port->data_role = TYPEC_DEVICE;
+		break;
+	case UCSI_CONSTAT_PARTNER_TYPE_UFP:
+		port->pwr_role = TYPEC_PWR_SOURCE;
+		port->data_role = TYPEC_HOST;
+		break;
+	case UCSI_CONSTAT_PARTNER_TYPE_DEBUG:
+		port->partner_type = TYPEC_PARTNER_DEBUG;
+		goto out;
+	case UCSI_CONSTAT_PARTNER_TYPE_AUDIO:
+		port->partner_type = TYPEC_PARTNER_AUDIO;
+		goto out;
+	}
+
+	switch (constat->pwr_op_mode) {
+	case UCSI_CONSTAT_PWR_OPMODE_NONE:
+	case UCSI_CONSTAT_PWR_OPMODE_DEFAULT:
+		port->pwr_opmode = TYPEC_PWR_MODE_USB;
+		break;
+	case UCSI_CONSTAT_PWR_OPMODE_BC:
+		port->partner_type = TYPEC_PARTNER_CHARGER;
+		port->pwr_opmode = TYPEC_PWR_MODE_BC1_2;
+		break;
+	case UCSI_CONSTAT_PWR_OPMODE_PD:
+		port->pwr_opmode = TYPEC_PWR_MODE_PD;
+		break;
+	case UCSI_CONSTAT_PWR_OPMODE_TYPEC1_3:
+		port->pwr_opmode = TYPEC_PWR_MODE_1_5A;
+		break;
+	case UCSI_CONSTAT_PWR_OPMODE_TYPEC3_0:
+		port->pwr_opmode = TYPEC_PWR_MODE_3_0A;
+		break;
+	default:
+		break;
+	}
+out:
+	return typec_connect(port);
+}
+
+static void ucsi_disconnect(struct ucsi_connector *con)
+{
+	con->port->partner_type = TYPEC_PARTNER_NONE;
+	con->port->connected = false;
+	typec_disconnect(con->port);
+}
+
+static void ucsi_connector_change(struct work_struct *work)
+{
+	struct ucsi_connector *con = container_of(work, struct ucsi_connector,
+						  work);
+	struct ucsi_connector_status constat;
+
+	ucsi_ack(con->ucsi, UCSI_ACK_EVENT);
+
+	if (WARN_ON(ucsi_get_constat(con, &constat) != 0))
+		return;
+
+	if (constat.constat_change & UCSI_CONSTAT_CONNECT_CHANGE) {
+		if (constat.connected)
+			ucsi_connect(con, &constat);
+		else
+			ucsi_disconnect(con);
+	}
+}
+
+/**
+ * ucsi_interrupt - UCSI Notification Handler
+ * @ucsi: Source UCSI Interface for the notifications
+ *
+ * Handle notifications from @ucsi.
+ */
+int ucsi_interrupt(struct ucsi *ucsi)
+{
+	u32 cci = ucsi->ppm->data->cci;
+
+	if (!cci)
+		return 0;
+
+	if (UCSI_CCI_CONNECTOR_CHANGE(cci)) {
+		struct ucsi_connector *con = cci_to_connector(ucsi, cci);
+
+		schedule_work(&con->work);
+		return 1;
+	}
+
+	ucsi->status = 0;
+
+	/* REVISIT: We don't actually do anything with this for now */
+	if (cci & UCSI_CCI_BUSY)
+		ucsi->status = UCSI_BUSY;
+
+	if (cci & UCSI_CCI_ERROR)
+		ucsi->status = UCSI_ERROR;
+
+	if (cci & UCSI_CCI_ACK_CMD || cci & UCSI_CCI_CMD_COMPLETED)
+		complete(&ucsi->complete);
+
+	return 1;
+}
+EXPORT_SYMBOL_GPL(ucsi_interrupt);
+
+/**
+ * ucsi_init - Initialize an UCSI Interface
+ * @ucsi: The UCSI Interface
+ *
+ * Registers all the USB Type-C ports governed by the PPM of @ucsi and enables
+ * all the notifications from the PPM.
+ */
+int ucsi_init(struct ucsi *ucsi)
+{
+	struct ucsi_control *ctrl = (void *)&ucsi->ppm->data->control;
+	struct ucsi_connector *con;
+	int ret;
+	int i;
+
+	/* Enable basic notifications */
+	ctrl->cmd = UCSI_SET_NOTIFICATION_ENABLE;
+	ctrl->data = UCSI_ENABLE_NTFY_CMD_COMPLETE | UCSI_ENABLE_NTFY_ERROR;
+	ret = ucsi_run_cmd(ucsi, NULL, 0);
+	if (ret)
+		return ret;
+
+	/* Get PPM capabilities */
+	ctrl->cmd = UCSI_GET_CAPABILITY;
+	ret = ucsi_run_cmd(ucsi, &ucsi->cap, sizeof(ucsi->cap));
+	if (ret)
+		return ret;
+
+	ucsi->connector = kcalloc(ucsi->cap.num_connectors,
+				  sizeof(struct ucsi_connector), GFP_KERNEL);
+	if (!ucsi->connector)
+		return -ENOMEM;
+
+	for (i = 0, con = ucsi->connector; i < ucsi->cap.num_connectors;
+	     i++, con++) {
+		struct typec_capability *cap = &con->typec_cap;
+		struct ucsi_connector_status constat;
+
+		/* Get connector capability */
+		ctrl->cmd = UCSI_GET_CONNECTOR_CAPABILITY;
+		ctrl->data = i + 1;
+		ret = ucsi_run_cmd(ucsi, &con->cap, sizeof(con->cap));
+		if (ret)
+			goto err;
+
+		/* Register the connector */
+
+		if (con->cap.op_mode & UCSI_CONCAP_OPMODE_DRP)
+			cap->type = TYPEC_PORT_DRP;
+		else if (con->cap.op_mode & UCSI_CONCAP_OPMODE_DFP)
+			cap->type = TYPEC_PORT_DFP;
+		else if (con->cap.op_mode & UCSI_CONCAP_OPMODE_UFP)
+			cap->type = TYPEC_PORT_UFP;
+
+		cap->usb_pd = !!(ucsi->cap.attributes &
+				       UCSI_CAP_ATTR_USB_PD);
+		cap->audio_accessory = !!(con->cap.op_mode &
+					  UCSI_CONCAP_OPMODE_AUDIO_ACCESSORY);
+		cap->debug_accessory = !!(con->cap.op_mode &
+					  UCSI_CONCAP_OPMODE_DEBUG_ACCESSORY);
+
+		/* TODO: Alt modes */
+
+		cap->dr_swap = ucsi_dr_swap;
+		cap->pr_swap = ucsi_pr_swap;
+
+		con->port = typec_register_port(ucsi->dev, cap);
+		if (IS_ERR(con->port)) {
+			ret = PTR_ERR(con->port);
+			goto err;
+		}
+
+		con->num = i + 1;
+		con->ucsi = ucsi;
+		INIT_WORK(&con->work, ucsi_connector_change);
+
+		/* Check if the connector is connected */
+		if (WARN_ON(ucsi_get_constat(con, &constat) != 0))
+			continue;
+
+		if (constat.connected)
+			ucsi_connect(con, &constat);
+	}
+
+	/* Enable all notifications */
+	ctrl->cmd = UCSI_SET_NOTIFICATION_ENABLE;
+	ctrl->data = UCSI_ENABLE_NTFY_ALL;
+	ret = ucsi_run_cmd(ucsi, NULL, 0);
+	if (ret)
+		goto err;
+
+	return 0;
+err:
+	if (i > 0)
+		for (; i >= 0; i--, con--)
+			typec_unregister_port(con->port);
+
+	kfree(ucsi->connector);
+	return ret;
+}
+EXPORT_SYMBOL(ucsi_init);
+
+/**
+ * ucsi_register_ppm - Register UCSI PPM Interface
+ * @dev: Device interface to the PPM
+ * @ppm: The PPM interface
+ *
+ * Allocates an UCSI instance, associates it with @ppm and returns it to the
+ * caller.
+ */
+struct ucsi *ucsi_register_ppm(struct device *dev, struct ucsi_ppm *ppm)
+{
+	struct ucsi *ucsi;
+
+	ucsi = kzalloc(sizeof(*ucsi), GFP_KERNEL);
+	if (!ucsi)
+		return ERR_PTR(-ENOMEM);
+
+	init_completion(&ucsi->complete);
+	ucsi->dev = dev;
+	ucsi->ppm = ppm;
+
+	return ucsi;
+}
+EXPORT_SYMBOL_GPL(ucsi_register_ppm);
+
+/**
+ * ucsi_unregister_ppm - Unregister UCSI PPM Interface
+ * @ucsi: struct ucsi associated with the PPM
+ *
+ * Unregister an UCSI PPM that was created with ucsi_register().
+ */
+void ucsi_unregister_ppm(struct ucsi *ucsi)
+{
+	struct ucsi_connector *con;
+	int i;
+
+	/* Disable all notifications */
+	ucsi->ppm->data->control = UCSI_SET_NOTIFICATION_ENABLE;
+	ucsi->ppm->cmd(ucsi->ppm);
+
+	for (i = 0, con = ucsi->connector; i < ucsi->cap.num_connectors;
+	     i++, con++)
+		typec_unregister_port(con->port);
+
+	kfree(ucsi->connector);
+	kfree(ucsi);
+}
+EXPORT_SYMBOL_GPL(ucsi_unregister_ppm);
+
+MODULE_AUTHOR("Heikki Krogerus <heikki.krogerus@linux.intel.com>");
+MODULE_LICENSE("GPL v2");
+MODULE_DESCRIPTION("USB Type-C System Software Interface driver");
diff --git a/drivers/usb/type-c/ucsi.h b/drivers/usb/type-c/ucsi.h
new file mode 100644
index 0000000..0ec6366
--- /dev/null
+++ b/drivers/usb/type-c/ucsi.h
@@ -0,0 +1,219 @@
+
+#include <linux/types.h>
+
+/* -------------------------------------------------------------------------- */
+
+struct ucsi_data {
+	__u16 version;
+	__u16 RESERVED;
+	__u32 cci;
+	__u64 control;
+	__u32 message_in[4];
+	__u32 message_out[4];
+} __packed;
+
+struct ucsi_control {
+	__u8 cmd;
+	__u8 length;
+	__u64 data:48;
+} __packed;
+
+/* Command Status and Connector Change Indication (CCI) bits */
+#define UCSI_CCI_CONNECTOR_CHANGE(c)	((c >> 1) & 0x7f)
+#define UCSI_CCI_DATA_LENGTH(c)		((c >> 8) & 0xff)
+#define UCSI_CCI_NOT_SUPPORTED		BIT(25)
+#define UCSI_CCI_CANCEL_CMD		BIT(26)
+#define UCSI_CCI_RESET_CMD		BIT(27)
+#define UCSI_CCI_BUSY			BIT(28)
+#define UCSI_CCI_ACK_CMD		BIT(29)
+#define UCSI_CCI_ERROR			BIT(30)
+#define UCSI_CCI_CMD_COMPLETED		BIT(31)
+
+/* Commands */
+#define UCSI_PPM_RESET			0x01
+#define UCSI_CANCEL			0x02
+#define UCSI_CONNECTOR_RESET		0x03
+#define UCSI_ACK_CC_CI			0x04
+#define UCSI_SET_NOTIFICATION_ENABLE	0x05
+#define UCSI_GET_CAPABILITY		0x06
+#define UCSI_GET_CONNECTOR_CAPABILITY	0x07
+#define UCSI_SET_UOM			0x08
+#define UCSI_SET_UOR			0x09
+#define UCSI_SET_PDM			0x0A
+#define UCSI_SET_PDR			0x0B
+#define UCSI_GET_ALTERNATE_MODES	0x0C
+#define UCSI_GET_CAM_SUPPORTED		0x0D
+#define UCSI_GET_CURRENT_CAM		0x0E
+#define UCSI_SET_NEW_CAM		0x0F
+#define UCSI_GET_PDOS			0x10
+#define UCSI_GET_CABLE_PROPERTY		0x11
+#define UCSI_GET_CONNECTOR_STATUS	0x12
+#define UCSI_GET_ERROR_STATUS		0x13
+
+/* ACK_CC_CI commands */
+#define UCSI_ACK_EVENT			1
+#define UCSI_ACK_CMD			2
+
+/* Bits for SET_NOTIFICATION_ENABLE command */
+#define UCSI_ENABLE_NTFY_CMD_COMPLETE		BIT(0)
+#define UCSI_ENABLE_NTFY_EXT_PWR_SRC_CHANGE	BIT(1)
+#define UCSI_ENABLE_NTFY_PWR_OPMODE_CHANGE	BIT(2)
+#define UCSI_ENABLE_NTFY_CAP_CHANGE		BIT(5)
+#define UCSI_ENABLE_NTFY_PWR_LEVEL_CHANGE	BIT(6)
+#define UCSI_ENABLE_NTFY_PD_RESET_COMPLETE	BIT(7)
+#define UCSI_ENABLE_NTFY_CAM_CHANGE		BIT(8)
+#define UCSI_ENABLE_NTFY_BAT_STATUS_CHANGE	BIT(9)
+#define UCSI_ENABLE_NTFY_PARTNER_CHANGE		BIT(11)
+#define UCSI_ENABLE_NTFY_PWR_DIR_CHANGE		BIT(12)
+#define UCSI_ENABLE_NTFY_CONNECTOR_CHANGE	BIT(14)
+#define UCSI_ENABLE_NTFY_ERROR			BIT(15)
+#define UCSI_ENABLE_NTFY_ALL			0xdbf3
+
+/* Error information returned by PPM in response to GET_ERROR_STATUS command. */
+#define UCSI_ERROR_UNREGONIZED_CMD		BIT(0)
+#define UCSI_ERROR_INVALID_CON_NUM		BIT(1)
+#define UCSI_ERROR_INVALID_CMD_ARGUMENT		BIT(2)
+#define UCSI_ERROR_INCOMPATIBLE_PARTNER		BIT(3)
+#define UCSI_ERROR_CC_COMMUNICATION_ERR		BIT(4)
+#define UCSI_ERROR_DEAD_BATTERY			BIT(5)
+#define UCSI_ERROR_CONTRACT_NEGOTIATION_FAIL	BIT(6)
+
+/* Set USB Operation Role Command structure */
+struct ucsi_uor_cmd {
+	__u8 cmd;
+	__u8 length;
+	__u8 con_num:7;
+	__u64 role:3;
+#define UCSI_UOR_ROLE_DFP			BIT(0)
+#define UCSI_UOR_ROLE_UFP			BIT(1)
+#define UCSI_UOR_ROLE_DRP			BIT(2)
+	__u64 data:38;
+} __packed;
+
+/* Data structure filled by PPM in response to GET_CAPABILITY command. */
+struct ucsi_capability {
+	__u32 attributes;
+#define UCSI_CAP_ATTR_DISABLE_STATE		BIT(0)
+#define UCSI_CAP_ATTR_BATTERY_CHARGING		BIT(1)
+#define UCSI_CAP_ATTR_USB_PD			BIT(2)
+#define UCSI_CAP_ATTR_TYPEC_CURRENT		BIT(6)
+#define UCSI_CAP_ATTR_POWER_AC_SUPPLY		BIT(8)
+#define UCSI_CAP_ATTR_POWER_OTHER		BIT(10)
+#define UCSI_CAP_ATTR_POWER_VBUS		BIT(14)
+	__u8 num_connectors;
+	__u32 features:24;
+#define UCSI_CAP_SET_UOM			BIT(0)
+#define UCSI_CAP_SET_PDM			BIT(1)
+#define UCSI_CAP_ALT_MODE_DETAILS		BIT(2)
+#define UCSI_CAP_ALT_MODE_OVERRIDE		BIT(3)
+#define UCSI_CAP_PDO_DETAILS			BIT(4)
+#define UCSI_CAP_CABLE_DETAILS			BIT(5)
+#define UCSI_CAP_EXT_SUPPLY_NOTIFICATIONS	BIT(6)
+#define UCSI_CAP_PD_RESET			BIT(7)
+	__u8 num_alt_modes;
+	__u8 RESERVED;
+	__u16 bc_version;
+	__u16 pd_version;
+	__u16 typec_version;
+} __packed;
+
+/* Data structure filled by PPM in response to GET_CONNECTOR_CAPABILITY cmd. */
+struct ucsi_connector_capability {
+	__u8 op_mode;
+#define UCSI_CONCAP_OPMODE_DFP			BIT(0)
+#define UCSI_CONCAP_OPMODE_UFP			BIT(1)
+#define UCSI_CONCAP_OPMODE_DRP			BIT(2)
+#define UCSI_CONCAP_OPMODE_AUDIO_ACCESSORY	BIT(3)
+#define UCSI_CONCAP_OPMODE_DEBUG_ACCESSORY	BIT(4)
+#define UCSI_CONCAP_OPMODE_USB2			BIT(5)
+#define UCSI_CONCAP_OPMODE_USB3			BIT(6)
+#define UCSI_CONCAP_OPMODE_ALT_MODE		BIT(7)
+	__u8 provider:1;
+	__u8 consumer:1;
+} __packed;
+
+/* Data structure filled by PPM in response to GET_ALTERNATE_MODES command. */
+struct ucsi_alt_modes {
+	__u32 svid0;
+	__u16 mid0;
+	__u32 svid1;
+	__u16 mid1;
+} __packed;
+
+/* Data structure filled by PPM in response to GET_CABLE_PROPERTY command. */
+struct ucsi_cable_property {
+	__u16 speed_supported;
+	__u8 current_capability;
+	__u8 vbus_in_cable:1;
+	__u8 active_cable:1;
+	__u8 directionality:1;
+	__u8 plug_type:2;
+#define UCSI_CABLE_PROPERTY_PLUG_TYPE_A		0
+#define UCSI_CABLE_PROPERTY_PLUG_TYPE_B		1
+#define UCSI_CABLE_PROPERTY_PLUG_TYPE_C		2
+#define UCSI_CABLE_PROPERTY_PLUG_OTHER		3
+	__u8 mode_support:1;
+	__u8 RESERVED_2:2;
+	__u8 latency:4;
+	__u8 RESERVED_4:4;
+} __packed;
+
+/* Data structure filled by PPM in response to GET_CONNECTOR_STATUS command. */
+struct ucsi_connector_status {
+	__u16 constat_change;
+#define UCSI_CONSTAT_EXT_SUPPLY_CHANGE		BIT(1)
+#define UCSI_CONSTAT_POWER_OPMODE_CHANGE	BIT(2)
+#define UCSI_CONSTAT_PDOS_CHANGE		BIT(5)
+#define UCSI_CONSTAT_POWER_LEVEL_CHANGE		BIT(6)
+#define UCSI_CONSTAT_PD_RESET_COMPLETE		BIT(7)
+#define UCSI_CONSTAT_CAM_CHANGE			BIT(8)
+#define UCSI_CONSTAT_BC_CHANGE			BIT(9)
+#define UCSI_CONSTAT_PARTNER_CHANGE		BIT(11)
+#define UCSI_CONSTAT_POWER_DIR_CHANGE		BIT(12)
+#define UCSI_CONSTAT_CONNECT_CHANGE		BIT(14)
+#define UCSI_CONSTAT_ERROR			BIT(15)
+	__u16 pwr_op_mode:3;
+#define UCSI_CONSTAT_PWR_OPMODE_NONE		0
+#define UCSI_CONSTAT_PWR_OPMODE_DEFAULT		1
+#define UCSI_CONSTAT_PWR_OPMODE_BC		2
+#define UCSI_CONSTAT_PWR_OPMODE_PD		3
+#define UCSI_CONSTAT_PWR_OPMODE_TYPEC1_3	4
+#define UCSI_CONSTAT_PWR_OPMODE_TYPEC3_0	5
+	__u16 connected:1;
+	__u16 pwr_dir:1;
+	__u16 partner_flags:8;
+#define UCSI_CONSTAT_PARTNER_FLAG_USB		BIT(0)
+#define UCSI_CONSTAT_PARTNER_FLAG_ALT_MODE	BIT(1)
+	__u16 partner_type:3;
+#define UCSI_CONSTAT_PARTNER_TYPE_DFP		1
+#define UCSI_CONSTAT_PARTNER_TYPE_UFP		2
+#define UCSI_CONSTAT_PARTNER_TYPE_CABLE_NO_UFP	3 /* Powered Cable */
+#define UCSI_CONSTAT_PARTNER_TYPE_CABLE_AND_UFP	4 /* Powered Cable */
+#define UCSI_CONSTAT_PARTNER_TYPE_DEBUG		5
+#define UCSI_CONSTAT_PARTNER_TYPE_AUDIO		6
+	__u32 request_data_obj;
+	__u8 bc_status;
+#define UCSI_CONSTAT_BC_NOT_CHARGING		0
+#define UCSI_CONSTAT_BC_NOMINAL_CHARGING	1
+#define UCSI_CONSTAT_BC_SLOW_CHARGING		2
+#define UCSI_CONSTAT_BC_TRICLE_CHARGING		3
+} __packed;
+
+/* -------------------------------------------------------------------------- */
+
+struct ucsi;
+
+/*
+ * struct ucsi_ppm - Interface to an UCSI Platform Policy Manager
+ * @data: memory location to the UCSI data structures
+ * @cmd: UCSI command execution routine
+ */
+struct ucsi_ppm {
+	struct ucsi_data *data;
+	int (*cmd)(struct ucsi_ppm *);
+};
+
+struct ucsi *ucsi_register_ppm(struct device *, struct ucsi_ppm *);
+void ucsi_unregister_ppm(struct ucsi *);
+int ucsi_init(struct ucsi *);
+int ucsi_interrupt(struct ucsi *);
-- 
2.7.0

[toc] | [prev] | [next] | [standalone]

#1330566 — Re: [PATCH 2/3] usb: type-c: USB Type-C Connector System Software Interface

On Tue, Feb 09, 2016 at 07:01:22PM +0200, Heikki Krogerus wrote:
> USB Type-C Connector System Software Interface (UCSI) is a
> specification that defines registers and data structures
> used to interface with the USB Type-C connectors on a system.
> 
> The specification is public and available at:
> http://www.intel.com/content/www/us/en/io/universal-serial-bus/usb-type-c-ucsi-spec.html
> 

What does this driver / code actually do?  Why is it needed?  What
interface to the rest of the kernel / userspace does it provide?

Why would we care about this?


You need to describe this a lot better than you did...

thanks,

greg k-h

[toc] | [prev] | [next] | [standalone]

#1331047 — Re: [PATCH 2/3] usb: type-c: USB Type-C Connector System Software Interface

On Tue, Feb 09, 2016 at 10:21:55AM -0800, Greg KH wrote:
> On Tue, Feb 09, 2016 at 07:01:22PM +0200, Heikki Krogerus wrote:
> > USB Type-C Connector System Software Interface (UCSI) is a
> > specification that defines registers and data structures
> > used to interface with the USB Type-C connectors on a system.
> > 
> > The specification is public and available at:
> > http://www.intel.com/content/www/us/en/io/universal-serial-bus/usb-type-c-ucsi-spec.html
> > 
> 
> What does this driver / code actually do?  Why is it needed?  What
> interface to the rest of the kernel / userspace does it provide?

I will fix this describe these things in the commit message. I'll just
but some UCSI background in case somebody is interested. So UCSI is in
practice a standard for USB Type-C controllers..

UCSI is the control interface for USB Type-C connectors (regardless
was USB PD supported or not) in MS Windows, so most likely all new HW
platforms designed to work also with Windows that are equipped with
USB Type-C will have UCSI device for controlling the USB Type-C ports.
In some cases the hardware for Type-C will be just a PHY like fusb30x
on these platforms (it's cheaper then USB PD or complete USB Type-C
controller), but in those cases the PHY is probable attached to an EC
or is completely controlled by system FW like BIOS together with any
USB PD communication in cases where USB PD is supported, and is in any
case not visible to the OS. Instead UCSI device is exposed to the OS
to give it means to apply its policies to the USB Type-C port.

> Why would we care about this?

I'll try to explain why it's important to export the control of USB
Type-C ports to the user space in my answer to your comments to the
first patch of this series, the one introducing the class.

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? 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?

> You need to describe this a lot better than you did...

Sure thing. I'm sorry about the poor description. I send these out too
hastily.


Thanks,

-- 
heikki

[toc] | [prev] | [next] | [standalone]

#1331352 — Re: [PATCH 2/3] usb: type-c: USB Type-C Connector System Software Interface

On Wed, Feb 10, 2016 at 12:30:42PM +0200, Heikki Krogerus wrote:
> On Tue, Feb 09, 2016 at 10:21:55AM -0800, Greg KH wrote:
> > On Tue, Feb 09, 2016 at 07:01:22PM +0200, Heikki Krogerus wrote:
> > > USB Type-C Connector System Software Interface (UCSI) is a
> > > specification that defines registers and data structures
> > > used to interface with the USB Type-C connectors on a system.
> > > 
> > > The specification is public and available at:
> > > http://www.intel.com/content/www/us/en/io/universal-serial-bus/usb-type-c-ucsi-spec.html
> > > 
> > 
> > What does this driver / code actually do?  Why is it needed?  What
> > interface to the rest of the kernel / userspace does it provide?
> 
> I will fix this describe these things in the commit message. I'll just
> but some UCSI background in case somebody is interested. So UCSI is in
> practice a standard for USB Type-C controllers..
> 
> UCSI is the control interface for USB Type-C connectors (regardless
> was USB PD supported or not) in MS Windows, so most likely all new HW
> platforms designed to work also with Windows that are equipped with
> USB Type-C will have UCSI device for controlling the USB Type-C ports.

There's many millions of devices with type-C without Windows on them, so
don't count on this being everywhere :)

> In some cases the hardware for Type-C will be just a PHY like fusb30x
> on these platforms (it's cheaper then USB PD or complete USB Type-C
> controller), but in those cases the PHY is probable attached to an EC
> or is completely controlled by system FW like BIOS together with any
> USB PD communication in cases where USB PD is supported, and is in any
> case not visible to the OS. Instead UCSI device is exposed to the OS
> to give it means to apply its policies to the USB Type-C port.
> 
> > Why would we care about this?
> 
> I'll try to explain why it's important to export the control of USB
> Type-C ports to the user space in my answer to your comments to the
> first patch of this series, the one introducing the class.
> 
> 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.

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.

> 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?

thanks,

greg k-h

[toc] | [prev] | [next] | [standalone]

#1331982 — 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

[toc] | [prev] | [next] | [standalone]

#1334534 — Re: [PATCH 2/3] usb: type-c: USB Type-C Connector System Software Interface

On Thu, 2016-02-11 at 15:50 +0200, Heikki Krogerus wrote:
> 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.

That question has not been answered. It would be awkward for the OS
to find itself in the slave role, which it is ill equipped for. So
the data role should be switched before the new device is announced
to user space. How is that handled?

	Regards
		Oliver

[toc] | [prev] | [next] | [standalone]

#1335210 — Re: [PATCH 2/3] usb: type-c: USB Type-C Connector System Software Interface

Hi,

On Mon, Feb 15, 2016 at 04:30:18PM +0100, Oliver Neukum wrote:
> On Thu, 2016-02-11 at 15:50 +0200, Heikki Krogerus wrote:
> > 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.
> 
> That question has not been answered. It would be awkward for the OS
> to find itself in the slave role, which it is ill equipped for. So
> the data role should be switched before the new device is announced
> to user space. How is that handled?

In the class driver, once we add support for preselecting the role,
when the connection happens we compare the initial role to the
preselected one and execute swap if it differs. Only after that we
notify userspace.


Thanks,

-- 
heikki

[toc] | [prev] | [next] | [standalone]

#1335391 — Re: [PATCH 2/3] usb: type-c: USB Type-C Connector System Software Interface

On Tue, 2016-02-16 at 11:22 +0200, Heikki Krogerus wrote:
> > That question has not been answered. It would be awkward for the OS
> > to find itself in the slave role, which it is ill equipped for. So
> > the data role should be switched before the new device is announced
> > to user space. How is that handled?
> 
> In the class driver, once we add support for preselecting the role,
> when the connection happens we compare the initial role to the
> preselected one and execute swap if it differs. Only after that we
> notify userspace.

Yes, but we need an API. We can't keep adding to it. So if that
is to be supported, it needs to be defined now.

	Regards
		Oliver

[toc] | [prev] | [next] | [standalone]

#1336119 — Re: [PATCH 2/3] usb: type-c: USB Type-C Connector System Software Interface

On Tue, Feb 16, 2016 at 02:39:47PM +0100, Oliver Neukum wrote:
> On Tue, 2016-02-16 at 11:22 +0200, Heikki Krogerus wrote:
> > > That question has not been answered. It would be awkward for the OS
> > > to find itself in the slave role, which it is ill equipped for. So
> > > the data role should be switched before the new device is announced
> > > to user space. How is that handled?
> > 
> > In the class driver, once we add support for preselecting the role,
> > when the connection happens we compare the initial role to the
> > preselected one and execute swap if it differs. Only after that we
> > notify userspace.
> 
> Yes, but we need an API. We can't keep adding to it. So if that
> is to be supported, it needs to be defined now.

When you say API, do you mean the API the class provides to the
drivers? Or did you mean ABI which would be the sysfs in this case?

For the sysfs I would image we can manage with the current files,
current_data_role and current_power_role. If somebody writes to them
when we are disconnected, we still callback the dr_swap or pr_swap
hooks, and make a rule that when disconnected, it means we are
setting the "preferred" roles.

Would that be OK? Or did I still misunderstood your question?


Thanks,

-- 
heikki

[toc] | [prev] | [next] | [standalone]

#1336152 — Re: [PATCH 2/3] usb: type-c: USB Type-C Connector System Software Interface

On Wed, 2016-02-17 at 09:58 +0200, Heikki Krogerus wrote:
> On Tue, Feb 16, 2016 at 02:39:47PM +0100, Oliver Neukum wrote:
> > On Tue, 2016-02-16 at 11:22 +0200, Heikki Krogerus wrote:
> > > > That question has not been answered. It would be awkward for the OS
> > > > to find itself in the slave role, which it is ill equipped for. So
> > > > the data role should be switched before the new device is announced
> > > > to user space. How is that handled?
> > > 
> > > In the class driver, once we add support for preselecting the role,
> > > when the connection happens we compare the initial role to the
> > > preselected one and execute swap if it differs. Only after that we
> > > notify userspace.
> > 
> > Yes, but we need an API. We can't keep adding to it. So if that
> > is to be supported, it needs to be defined now.
> 
> When you say API, do you mean the API the class provides to the
> drivers? Or did you mean ABI which would be the sysfs in this case?

The API to user space. That is the point. We cannot break user space.
Once this sysfs API is upstream we are stuck with it.

> For the sysfs I would image we can manage with the current files,
> current_data_role and current_power_role. If somebody writes to them
> when we are disconnected, we still callback the dr_swap or pr_swap
> hooks, and make a rule that when disconnected, it means we are
> setting the "preferred" roles.
> 
> Would that be OK? Or did I still misunderstood your question?

That would be absolutely OK, but that function needs to be decided on
and documented as all files in sysfs are. And likewise it needs to be
documented that alternate modes behave differently.

	Regards
		Oliver

[toc] | [prev] | [next] | [standalone]

#1336227 — Re: [PATCH 2/3] usb: type-c: USB Type-C Connector System Software Interface

[Multipart message — attachments visible in raw view] — view raw

Hi,

Oliver Neukum <oneukum@suse.com> writes:
> On Wed, 2016-02-17 at 09:58 +0200, Heikki Krogerus wrote:
>> On Tue, Feb 16, 2016 at 02:39:47PM +0100, Oliver Neukum wrote:
>> > On Tue, 2016-02-16 at 11:22 +0200, Heikki Krogerus wrote:
>> > > > That question has not been answered. It would be awkward for the OS
>> > > > to find itself in the slave role, which it is ill equipped for. So
>> > > > the data role should be switched before the new device is announced
>> > > > to user space. How is that handled?
>> > > 
>> > > In the class driver, once we add support for preselecting the role,
>> > > when the connection happens we compare the initial role to the
>> > > preselected one and execute swap if it differs. Only after that we
>> > > notify userspace.
>> > 
>> > Yes, but we need an API. We can't keep adding to it. So if that
>> > is to be supported, it needs to be defined now.
>> 
>> When you say API, do you mean the API the class provides to the
>> drivers? Or did you mean ABI which would be the sysfs in this case?
>
> The API to user space. That is the point. We cannot break user space.
> Once this sysfs API is upstream we are stuck with it.

yeah, in fact I have been wondering if sysfs is the best interface to
userspace. I talked with Heikki a few days back about this; I was
wondering if something like what the NFC folks did with netlink would be
better here.

-- 
balbi

[toc] | [prev] | [next] | [standalone]

#1336233 — Re: [PATCH 2/3] usb: type-c: USB Type-C Connector System Software Interface

On Wed, 2016-02-17 at 12:29 +0200, Felipe Balbi wrote:
> Hi,
> 
> Oliver Neukum <oneukum@suse.com> writes:
> > On Wed, 2016-02-17 at 09:58 +0200, Heikki Krogerus wrote:
> >> On Tue, Feb 16, 2016 at 02:39:47PM +0100, Oliver Neukum wrote:

> >> > Yes, but we need an API. We can't keep adding to it. So if that
> >> > is to be supported, it needs to be defined now.
> >> 
> >> When you say API, do you mean the API the class provides to the
> >> drivers? Or did you mean ABI which would be the sysfs in this case?
> >
> > The API to user space. That is the point. We cannot break user space.
> > Once this sysfs API is upstream we are stuck with it.
> 
> yeah, in fact I have been wondering if sysfs is the best interface to

That is the discussion we must have.

> userspace. I talked with Heikki a few days back about this; I was
> wondering if something like what the NFC folks did with netlink would be
> better here.

I doubt that, because the main user is likely to be udev scripts.
They can easily deal with sysfs attributes.

	Regards
		Oliver

[toc] | [prev] | [next] | [standalone]

#1336262 — Re: [PATCH 2/3] usb: type-c: USB Type-C Connector System Software Interface

On Wed, Feb 17, 2016 at 11:36:52AM +0100, Oliver Neukum wrote:
> On Wed, 2016-02-17 at 12:29 +0200, Felipe Balbi wrote:
> > Hi,
> > 
> > Oliver Neukum <oneukum@suse.com> writes:
> > > On Wed, 2016-02-17 at 09:58 +0200, Heikki Krogerus wrote:
> > >> On Tue, Feb 16, 2016 at 02:39:47PM +0100, Oliver Neukum wrote:
> 
> > >> > Yes, but we need an API. We can't keep adding to it. So if that
> > >> > is to be supported, it needs to be defined now.
> > >> 
> > >> When you say API, do you mean the API the class provides to the
> > >> drivers? Or did you mean ABI which would be the sysfs in this case?
> > >
> > > The API to user space. That is the point. We cannot break user space.
> > > Once this sysfs API is upstream we are stuck with it.
> > 
> > yeah, in fact I have been wondering if sysfs is the best interface to
> 
> That is the discussion we must have.
> 
> > userspace. I talked with Heikki a few days back about this; I was
> > wondering if something like what the NFC folks did with netlink would be
> > better here.
> 
> I doubt that, because the main user is likely to be udev scripts.
> They can easily deal with sysfs attributes.

IMHO for high level interface like this, sysfs is ideal because of the
simple fact that you only need a shell to access the files. netlink
would make us depend on custom software, no?

I'm not against using netlink, but what would be the benefit from it
in this case?


Thanks,

-- 
heikki

[toc] | [prev] | [next] | [standalone]

#1336424 — Re: [PATCH 2/3] usb: type-c: USB Type-C Connector System Software Interface

[Multipart message — attachments visible in raw view] — view raw

Hi,

Heikki Krogerus <heikki.krogerus@linux.intel.com> writes:
> On Wed, Feb 17, 2016 at 11:36:52AM +0100, Oliver Neukum wrote:
>> On Wed, 2016-02-17 at 12:29 +0200, Felipe Balbi wrote:
>> > Hi,
>> > 
>> > Oliver Neukum <oneukum@suse.com> writes:
>> > > On Wed, 2016-02-17 at 09:58 +0200, Heikki Krogerus wrote:
>> > >> On Tue, Feb 16, 2016 at 02:39:47PM +0100, Oliver Neukum wrote:
>> 
>> > >> > Yes, but we need an API. We can't keep adding to it. So if that
>> > >> > is to be supported, it needs to be defined now.
>> > >> 
>> > >> When you say API, do you mean the API the class provides to the
>> > >> drivers? Or did you mean ABI which would be the sysfs in this case?
>> > >
>> > > The API to user space. That is the point. We cannot break user space.
>> > > Once this sysfs API is upstream we are stuck with it.
>> > 
>> > yeah, in fact I have been wondering if sysfs is the best interface to
>> 
>> That is the discussion we must have.
>> 
>> > userspace. I talked with Heikki a few days back about this; I was
>> > wondering if something like what the NFC folks did with netlink would be
>> > better here.
>> 
>> I doubt that, because the main user is likely to be udev scripts.
>> They can easily deal with sysfs attributes.
>
> IMHO for high level interface like this, sysfs is ideal because of the
> simple fact that you only need a shell to access the files. netlink
> would make us depend on custom software, no?
>
> I'm not against using netlink, but what would be the benefit from it
> in this case?

With HW we see nowadays, CC stack is hidden on some microcontroller, but
is it too far-fetched to consider a system where this is not the case ?

Specially when we consider things like power delivery which, I know, you
wanted to keep it out of this interface, however we would have two
'stacks' competing for access to the same pins, right ?

IIRC mode and role negotiation goes via CC pins using the power delivery
protocol. If I misunderstand anything, let me know.

-- 
balbi

[toc] | [prev] | [next] | [standalone]

#1336473 — Re: [PATCH 2/3] usb: type-c: USB Type-C Connector System Software Interface

On Wed, Feb 17, 2016 at 03:36:46PM +0200, Felipe Balbi wrote:
> 
> Hi,
> 
> Heikki Krogerus <heikki.krogerus@linux.intel.com> writes:
> > On Wed, Feb 17, 2016 at 11:36:52AM +0100, Oliver Neukum wrote:
> >> On Wed, 2016-02-17 at 12:29 +0200, Felipe Balbi wrote:
> >> > Hi,
> >> > 
> >> > Oliver Neukum <oneukum@suse.com> writes:
> >> > > On Wed, 2016-02-17 at 09:58 +0200, Heikki Krogerus wrote:
> >> > >> On Tue, Feb 16, 2016 at 02:39:47PM +0100, Oliver Neukum wrote:
> >> 
> >> > >> > Yes, but we need an API. We can't keep adding to it. So if that
> >> > >> > is to be supported, it needs to be defined now.
> >> > >> 
> >> > >> When you say API, do you mean the API the class provides to the
> >> > >> drivers? Or did you mean ABI which would be the sysfs in this case?
> >> > >
> >> > > The API to user space. That is the point. We cannot break user space.
> >> > > Once this sysfs API is upstream we are stuck with it.
> >> > 
> >> > yeah, in fact I have been wondering if sysfs is the best interface to
> >> 
> >> That is the discussion we must have.
> >> 
> >> > userspace. I talked with Heikki a few days back about this; I was
> >> > wondering if something like what the NFC folks did with netlink would be
> >> > better here.
> >> 
> >> I doubt that, because the main user is likely to be udev scripts.
> >> They can easily deal with sysfs attributes.
> >
> > IMHO for high level interface like this, sysfs is ideal because of the
> > simple fact that you only need a shell to access the files. netlink
> > would make us depend on custom software, no?
> >
> > I'm not against using netlink, but what would be the benefit from it
> > in this case?
> 
> With HW we see nowadays, CC stack is hidden on some microcontroller, but
> is it too far-fetched to consider a system where this is not the case ?

There already are several USB PD stacks out there, like also Greg
pointed out.

> Specially when we consider things like power delivery which, I know, you
> wanted to keep it out of this interface, however we would have two
> 'stacks' competing for access to the same pins, right ?

No. This class would be the top layer for the coming stack, where ever
it ends up coming. The class is only the interface to the user space
and nothing else.

By saying we need to keep USB Type-C separate from USB PD I meant that
the userspace access can not be mixed somewhere in layers of the USB
PD/CC stack like it has been in the USB PD stacks I've seen so far.
They assume that we always use the software USB PD stack with USB
Type-C, which as we can see is not true when the stack is implemented
in EC or firmware or some complex USB PD controller or what ever.
However, the operations the userspace needs to do are exactly the same
in both cases.

- data role swapping
- power role swapping (depends on USB PD)
- Alternate Modes (depends on USB PD)

And we really should not forget that we actually also have USB Type-C
PHYs that can't do any USB PD communication over the CC pin, so USB PD
is simply not always going to be available. But the data role swapping
and also accessories are still available with them, as the do not need
USB PD.

This was the whole point with the class. It allows the different ways
of dealing with Type-C ports to be exposed to userspace in the same
way.

> IIRC mode and role negotiation goes via CC pins using the power delivery
> protocol. If I misunderstand anything, let me know.

The data role swap with USB Type-C connectors is in no way tied to USB
Power Delivery. The USB Type-C spec defines that when USB PD is
available, DR_Swap USB PD function is used to swap the role, otherwise
emulated disconnect will do the trick.

Data role swapping is a must thing to have with USB Type-C connectors
because of the fact that the role is selected randomly. Regardless was
USB PD supported or not.


Thanks,

-- 
heikki

[toc] | [prev] | [next] | [standalone]

#1337181 — Re: [PATCH 2/3] usb: type-c: USB Type-C Connector System Software Interface

On Wed, Feb 17, 2016 at 04:28:16PM +0200, Heikki Krogerus wrote:
> On Wed, Feb 17, 2016 at 03:36:46PM +0200, Felipe Balbi wrote:
> > 
> > Hi,
> > 
> 
> > IIRC mode and role negotiation goes via CC pins using the power delivery
> > protocol. If I misunderstand anything, let me know.
> 
> The data role swap with USB Type-C connectors is in no way tied to USB
> Power Delivery. The USB Type-C spec defines that when USB PD is
> available, DR_Swap USB PD function is used to swap the role, otherwise
> emulated disconnect will do the trick.
> 

I am interested in how you design role swap on the fly without USB PD.
Do you follow the spec like USB OTG 3.0 RSP (Role Swap Protocol) or
just echo the /sys to give up current role, and swap to another?

-- 

Best Regards,
Peter Chen

[toc] | [prev] | [next] | [standalone]

#1337260 — Re: [PATCH 2/3] usb: type-c: USB Type-C Connector System Software Interface

Hi Peter,

On Thu, Feb 18, 2016 at 05:07:04PM +0800, Peter Chen wrote:
> On Wed, Feb 17, 2016 at 04:28:16PM +0200, Heikki Krogerus wrote:
> > On Wed, Feb 17, 2016 at 03:36:46PM +0200, Felipe Balbi wrote:
> > > IIRC mode and role negotiation goes via CC pins using the power delivery
> > > protocol. If I misunderstand anything, let me know.
> > 
> > The data role swap with USB Type-C connectors is in no way tied to USB
> > Power Delivery. The USB Type-C spec defines that when USB PD is
> > available, DR_Swap USB PD function is used to swap the role, otherwise
> > emulated disconnect will do the trick.
> 
> I am interested in how you design role swap on the fly without USB PD.
> Do you follow the spec like USB OTG 3.0 RSP (Role Swap Protocol) or
> just echo the /sys to give up current role, and swap to another?

No OTG with USB Type-C. You echo the wanted role to the
/sys/class/type-C/usbcN/data_role.

This operation from userspace is the same regardless was USB PD
supported or not. The actual operations needed for the role swap are
of course platform specific, and the responsibility of the drivers
that register the ports with type-c class.


Thanks,

-- 
heikki

[toc] | [prev] | [next] | [standalone]

#1337254 — Re: [PATCH 2/3] usb: type-c: USB Type-C Connector System Software Interface

On Wed, Feb 17, 2016 at 7:58 PM, Heikki Krogerus
<heikki.krogerus@linux.intel.com> wrote:
> On Wed, Feb 17, 2016 at 03:36:46PM +0200, Felipe Balbi wrote:
>>
>> Hi,
>>
>> Heikki Krogerus <heikki.krogerus@linux.intel.com> writes:
>> > On Wed, Feb 17, 2016 at 11:36:52AM +0100, Oliver Neukum wrote:
>> >> On Wed, 2016-02-17 at 12:29 +0200, Felipe Balbi wrote:
>> >> > Hi,
>> >> >
>> >> > Oliver Neukum <oneukum@suse.com> writes:
>> >> > > On Wed, 2016-02-17 at 09:58 +0200, Heikki Krogerus wrote:
>> >> > >> On Tue, Feb 16, 2016 at 02:39:47PM +0100, Oliver Neukum wrote:
>> >>
>> >> > >> > Yes, but we need an API. We can't keep adding to it. So if that
>> >> > >> > is to be supported, it needs to be defined now.
>> >> > >>
>> >> > >> When you say API, do you mean the API the class provides to the
>> >> > >> drivers? Or did you mean ABI which would be the sysfs in this case?
>> >> > >
>> >> > > The API to user space. That is the point. We cannot break user space.
>> >> > > Once this sysfs API is upstream we are stuck with it.
>> >> >
>> >> > yeah, in fact I have been wondering if sysfs is the best interface to
>> >>
>> >> That is the discussion we must have.
>> >>
>> >> > userspace. I talked with Heikki a few days back about this; I was
>> >> > wondering if something like what the NFC folks did with netlink would be
>> >> > better here.
>> >>
>> >> I doubt that, because the main user is likely to be udev scripts.
>> >> They can easily deal with sysfs attributes.
>> >
>> > IMHO for high level interface like this, sysfs is ideal because of the
>> > simple fact that you only need a shell to access the files. netlink
>> > would make us depend on custom software, no?
>> >
>> > I'm not against using netlink, but what would be the benefit from it
>> > in this case?
>>
>> With HW we see nowadays, CC stack is hidden on some microcontroller, but
>> is it too far-fetched to consider a system where this is not the case ?
>
> There already are several USB PD stacks out there, like also Greg
> pointed out.
>
>> Specially when we consider things like power delivery which, I know, you
>> wanted to keep it out of this interface, however we would have two
>> 'stacks' competing for access to the same pins, right ?
>
> No. This class would be the top layer for the coming stack, where ever
> it ends up coming. The class is only the interface to the user space
> and nothing else.
>
> By saying we need to keep USB Type-C separate from USB PD I meant that
> the userspace access can not be mixed somewhere in layers of the USB
> PD/CC stack like it has been in the USB PD stacks I've seen so far.
> They assume that we always use the software USB PD stack with USB
> Type-C, which as we can see is not true when the stack is implemented
> in EC or firmware or some complex USB PD controller or what ever.
> However, the operations the userspace needs to do are exactly the same
> in both cases.
>
> - data role swapping
> - power role swapping (depends on USB PD)
> - Alternate Modes (depends on USB PD)
>
> And we really should not forget that we actually also have USB Type-C
> PHYs that can't do any USB PD communication over the CC pin, so USB PD
> is simply not always going to be available. But the data role swapping
> and also accessories are still available with them, as the do not need
> USB PD.
>
> This was the whole point with the class. It allows the different ways
> of dealing with Type-C ports to be exposed to userspace in the same
> way.
>
>> IIRC mode and role negotiation goes via CC pins using the power delivery
>> protocol. If I misunderstand anything, let me know.
>
> The data role swap with USB Type-C connectors is in no way tied to USB
> Power Delivery. The USB Type-C spec defines that when USB PD is

Its not data role swap i guess its dual role, A Data role swap is tied
with USB PD,

> available, DR_Swap USB PD function is used to swap the role, otherwise
> emulated disconnect will do the trick.

I doubt a USB host with no device capability implement DRP ?? Also
emulated trick(??) is not spec requirement rt ?

>
> Data role swapping is a must thing to have with USB Type-C connectors

I guess you are referring to Dual role (DRP) and not data role (DRD).

> because of the fact that the role is selected randomly. Regardless was
> USB PD supported or not.
>
>
> Thanks,
>
> --
> heikki
> --
> To unsubscribe from this list: send the line "unsubscribe linux-usb" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

[toc] | [prev] | [next] | [standalone]

#1337261 — Re: [PATCH 2/3] usb: type-c: USB Type-C Connector System Software Interface

On Thu, Feb 18, 2016 at 04:07:54PM +0530, Rajaram R wrote:
> On Wed, Feb 17, 2016 at 7:58 PM, Heikki Krogerus
> <heikki.krogerus@linux.intel.com> wrote:
> > On Wed, Feb 17, 2016 at 03:36:46PM +0200, Felipe Balbi wrote:
> >>
> >> Hi,
> >>
> >> Heikki Krogerus <heikki.krogerus@linux.intel.com> writes:
> >> > On Wed, Feb 17, 2016 at 11:36:52AM +0100, Oliver Neukum wrote:
> >> >> On Wed, 2016-02-17 at 12:29 +0200, Felipe Balbi wrote:
> >> >> > Hi,
> >> >> >
> >> >> > Oliver Neukum <oneukum@suse.com> writes:
> >> >> > > On Wed, 2016-02-17 at 09:58 +0200, Heikki Krogerus wrote:
> >> >> > >> On Tue, Feb 16, 2016 at 02:39:47PM +0100, Oliver Neukum wrote:
> >> >>
> >> >> > >> > Yes, but we need an API. We can't keep adding to it. So if that
> >> >> > >> > is to be supported, it needs to be defined now.
> >> >> > >>
> >> >> > >> When you say API, do you mean the API the class provides to the
> >> >> > >> drivers? Or did you mean ABI which would be the sysfs in this case?
> >> >> > >
> >> >> > > The API to user space. That is the point. We cannot break user space.
> >> >> > > Once this sysfs API is upstream we are stuck with it.
> >> >> >
> >> >> > yeah, in fact I have been wondering if sysfs is the best interface to
> >> >>
> >> >> That is the discussion we must have.
> >> >>
> >> >> > userspace. I talked with Heikki a few days back about this; I was
> >> >> > wondering if something like what the NFC folks did with netlink would be
> >> >> > better here.
> >> >>
> >> >> I doubt that, because the main user is likely to be udev scripts.
> >> >> They can easily deal with sysfs attributes.
> >> >
> >> > IMHO for high level interface like this, sysfs is ideal because of the
> >> > simple fact that you only need a shell to access the files. netlink
> >> > would make us depend on custom software, no?
> >> >
> >> > I'm not against using netlink, but what would be the benefit from it
> >> > in this case?
> >>
> >> With HW we see nowadays, CC stack is hidden on some microcontroller, but
> >> is it too far-fetched to consider a system where this is not the case ?
> >
> > There already are several USB PD stacks out there, like also Greg
> > pointed out.
> >
> >> Specially when we consider things like power delivery which, I know, you
> >> wanted to keep it out of this interface, however we would have two
> >> 'stacks' competing for access to the same pins, right ?
> >
> > No. This class would be the top layer for the coming stack, where ever
> > it ends up coming. The class is only the interface to the user space
> > and nothing else.
> >
> > By saying we need to keep USB Type-C separate from USB PD I meant that
> > the userspace access can not be mixed somewhere in layers of the USB
> > PD/CC stack like it has been in the USB PD stacks I've seen so far.
> > They assume that we always use the software USB PD stack with USB
> > Type-C, which as we can see is not true when the stack is implemented
> > in EC or firmware or some complex USB PD controller or what ever.
> > However, the operations the userspace needs to do are exactly the same
> > in both cases.
> >
> > - data role swapping
> > - power role swapping (depends on USB PD)
> > - Alternate Modes (depends on USB PD)
> >
> > And we really should not forget that we actually also have USB Type-C
> > PHYs that can't do any USB PD communication over the CC pin, so USB PD
> > is simply not always going to be available. But the data role swapping
> > and also accessories are still available with them, as the do not need
> > USB PD.
> >
> > This was the whole point with the class. It allows the different ways
> > of dealing with Type-C ports to be exposed to userspace in the same
> > way.
> >
> >> IIRC mode and role negotiation goes via CC pins using the power delivery
> >> protocol. If I misunderstand anything, let me know.
> >
> > The data role swap with USB Type-C connectors is in no way tied to USB
> > Power Delivery. The USB Type-C spec defines that when USB PD is
> 
> Its not data role swap i guess its dual role, A Data role swap is tied
> with USB PD,
> 
> > available, DR_Swap USB PD function is used to swap the role, otherwise
> > emulated disconnect will do the trick.
> 
> I doubt a USB host with no device capability implement DRP ?? Also
> emulated trick(??) is not spec requirement rt ?
> 
> >
> > Data role swapping is a must thing to have with USB Type-C connectors
> 
> I guess you are referring to Dual role (DRP) and not data role (DRD).

There is no term "DRD" in USB Type-C spec. A quote from Type-C spec
ch. 2.3.3:

"Two methods are defined to allow a USB Type-C DRP to functionally
swap data roles, one managed using USB PD DR_Swap and the other
emulating a disconnect/reconnect sequence (see Figure 4-16)"


Thanks,

-- 
heikki

[toc] | [prev] | [next] | [standalone]

Page 1 of 3  [1] 2 3  Next page →

Back to top | Article view | linux.kernel

csiph-web