[PATCH v2 00/12] staging: typec: tcpci: move out of staging

[PATCH v2 00/12] staging: typec: tcpci: move out of staging

[Li Jun]

This patch set attempts to move the tcpci driver out of staging by fix
some tcpci driver issues and verified on NXP PTN5110, which is a standard
tcpci typec port controller device with power delivery support, tested
power source and sink with drp config.

Main changes for v2:
- Typec properties are based on general usb connector bindings[1] proposed
  by Andrzej Hajda, use the standard unit suffixes as defined in
  property-units.txt.
- Add 2 infra APIs to get power sink and source config from dt.
- Don't change the set_cc api, to keep the uncontacted cc line open,
  set cc1/cc2 to be open in tcpci driver when set polarity.
- Directly enable vbus detect in tcpci driver rather than add a API.
- Details added in each patch.
 
[1] https://patchwork.kernel.org/patch/10231447/

Li Jun (12):
  usb: typec: add API to get port type and preferred role
  usb: typec: add API to get sink and source config
  staging: typec: tcpci: support port config passed via dt
  staging: typec: tcpci: register port before request irq
  staging: typec: tcpci: enable vbus detection
  typec: tcpm: add starting value for drp toggling
  staging: typec: tcpci: correct drp toggling
  staging: typec: tcpci: keep the uncontact cc line open
  staging: typec: tcpci: Only touch target bit when enable vconn
  dt-bindings: connector: add properties for typec power delivery
  dt-bindings: usb: add documentation for typec port controller(TCPCI)
  staging: typec: tcpci: move tcpci driver out of staging

 .../bindings/connector/usb-connector.txt           |  43 +++++++
 .../devicetree/bindings/usb/typec-tcpci.txt        |  35 ++++++
 drivers/staging/Kconfig                            |   2 -
 drivers/staging/Makefile                           |   1 -
 drivers/staging/typec/Kconfig                      |  14 ---
 drivers/staging/typec/Makefile                     |   1 -
 drivers/staging/typec/TODO                         |   5 -
 drivers/usb/typec/Kconfig                          |   7 ++
 drivers/usb/typec/Makefile                         |   1 +
 drivers/{staging => usb}/typec/tcpci.c             | 127 ++++++++++++++++++---
 drivers/{staging => usb}/typec/tcpci.h             |   0
 drivers/usb/typec/tcpm.c                           |  53 ++++++++-
 drivers/usb/typec/typec.c                          |  46 ++++++++
 include/linux/usb/tcpm.h                           |   8 +-
 include/linux/usb/typec.h                          |   2 +
 15 files changed, 295 insertions(+), 50 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/usb/typec-tcpci.txt
 delete mode 100644 drivers/staging/typec/Kconfig
 delete mode 100644 drivers/staging/typec/Makefile
 delete mode 100644 drivers/staging/typec/TODO
 rename drivers/{staging => usb}/typec/tcpci.c (81%)
 rename drivers/{staging => usb}/typec/tcpci.h (100%)

-- 
2.7.4

[PATCH v2 01/12] usb: typec: add API to get port type and preferred role

[Li Jun]

This patch add 2 APIs to get port type and preferred role from firmware
description.

Signed-off-by: Li Jun <jun.li@nxp.com>

---
change for v2
- Change the 2 APIs name and input para to be device_node pointer.

 drivers/usb/typec/typec.c | 46 ++++++++++++++++++++++++++++++++++++++++++++++
 include/linux/usb/typec.h |  2 ++
 2 files changed, 48 insertions(+)

diff --git a/drivers/usb/typec/typec.c b/drivers/usb/typec/typec.c
index 735726c..e7b2802 100644
--- a/drivers/usb/typec/typec.c
+++ b/drivers/usb/typec/typec.c
@@ -9,6 +9,7 @@
 #include <linux/device.h>
 #include <linux/module.h>
 #include <linux/mutex.h>
+#include <linux/of.h>
 #include <linux/slab.h>
 #include <linux/usb/typec.h>
 
@@ -1246,6 +1247,51 @@ void typec_set_pwr_opmode(struct typec_port *port,
 }
 EXPORT_SYMBOL_GPL(typec_set_pwr_opmode);
 
+/**
+ * typec_of_get_port_type - Get the typec port type
+ * @np: device node from which the property value is to be read.
+ *
+ * This routine is used by typec hardware driver to read property port type
+ * from the device firmware description.
+ *
+ * Returns typec_port_type if success, otherwise negative error code.
+ */
+int typec_of_get_port_type(struct device_node *np)
+{
+	const char *type_str;
+	int ret;
+
+	ret = of_property_read_string(np, "port-type", &type_str);
+	if (ret < 0)
+		return ret;
+
+	return match_string(typec_port_types, ARRAY_SIZE(typec_port_types),
+								 type_str);
+}
+EXPORT_SYMBOL_GPL(typec_get_port_type);
+
+/**
+ * typec_of_get_preferred_role - Get the typec preferred role
+ * @np: device node from which the property value is to be read.
+ *
+ * This routine is used by typec hardware driver to read property default role
+ * from the device firmware description.
+ *
+ * Returns typec_role if success, otherwise negative error code.
+ */
+int typec_of_get_preferred_role(struct device_node *np)
+{
+	const char *power_str;
+	int ret;
+
+	ret = of_property_read_string(np, "default-role", &power_str);
+	if (ret < 0)
+		return ret;
+
+	return match_string(typec_roles, ARRAY_SIZE(typec_roles), power_str);
+}
+EXPORT_SYMBOL_GPL(typec_get_preferred_role);
+
 /* --------------------------------------- */
 
 /**
diff --git a/include/linux/usb/typec.h b/include/linux/usb/typec.h
index 0d44ce6..f2a581a 100644
--- a/include/linux/usb/typec.h
+++ b/include/linux/usb/typec.h
@@ -244,5 +244,7 @@ void typec_set_data_role(struct typec_port *port, enum typec_data_role role);
 void typec_set_pwr_role(struct typec_port *port, enum typec_role role);
 void typec_set_vconn_role(struct typec_port *port, enum typec_role role);
 void typec_set_pwr_opmode(struct typec_port *port, enum typec_pwr_opmode mode);
+int typec_of_get_port_type(struct device_node *np);
+int typec_of_get_preferred_role(struct device_node *np);
 
 #endif /* __LINUX_USB_TYPEC_H */
-- 
2.7.4

[v2,01/12] usb: typec: add API to get port type and preferred role

[Jun Li]

This patch add 2 APIs to get port type and preferred role from firmware
description.

Signed-off-by: Li Jun <jun.li@nxp.com>
---
change for v2
- Change the 2 APIs name and input para to be device_node pointer.

 drivers/usb/typec/typec.c | 46 ++++++++++++++++++++++++++++++++++++++++++++++
 include/linux/usb/typec.h |  2 ++
 2 files changed, 48 insertions(+)

diff --git a/drivers/usb/typec/typec.c b/drivers/usb/typec/typec.c
index 735726c..e7b2802 100644
--- a/drivers/usb/typec/typec.c
+++ b/drivers/usb/typec/typec.c
@@ -9,6 +9,7 @@
 #include <linux/device.h>
 #include <linux/module.h>
 #include <linux/mutex.h>
+#include <linux/of.h>
 #include <linux/slab.h>
 #include <linux/usb/typec.h>
 
@@ -1246,6 +1247,51 @@ void typec_set_pwr_opmode(struct typec_port *port,
 }
 EXPORT_SYMBOL_GPL(typec_set_pwr_opmode);
 
+/**
+ * typec_of_get_port_type - Get the typec port type
+ * @np: device node from which the property value is to be read.
+ *
+ * This routine is used by typec hardware driver to read property port type
+ * from the device firmware description.
+ *
+ * Returns typec_port_type if success, otherwise negative error code.
+ */
+int typec_of_get_port_type(struct device_node *np)
+{
+	const char *type_str;
+	int ret;
+
+	ret = of_property_read_string(np, "port-type", &type_str);
+	if (ret < 0)
+		return ret;
+
+	return match_string(typec_port_types, ARRAY_SIZE(typec_port_types),
+								 type_str);
+}
+EXPORT_SYMBOL_GPL(typec_get_port_type);
+
+/**
+ * typec_of_get_preferred_role - Get the typec preferred role
+ * @np: device node from which the property value is to be read.
+ *
+ * This routine is used by typec hardware driver to read property default role
+ * from the device firmware description.
+ *
+ * Returns typec_role if success, otherwise negative error code.
+ */
+int typec_of_get_preferred_role(struct device_node *np)
+{
+	const char *power_str;
+	int ret;
+
+	ret = of_property_read_string(np, "default-role", &power_str);
+	if (ret < 0)
+		return ret;
+
+	return match_string(typec_roles, ARRAY_SIZE(typec_roles), power_str);
+}
+EXPORT_SYMBOL_GPL(typec_get_preferred_role);
+
 /* --------------------------------------- */
 
 /**
diff --git a/include/linux/usb/typec.h b/include/linux/usb/typec.h
index 0d44ce6..f2a581a 100644
--- a/include/linux/usb/typec.h
+++ b/include/linux/usb/typec.h
@@ -244,5 +244,7 @@ void typec_set_data_role(struct typec_port *port, enum typec_data_role role);
 void typec_set_pwr_role(struct typec_port *port, enum typec_role role);
 void typec_set_vconn_role(struct typec_port *port, enum typec_role role);
 void typec_set_pwr_opmode(struct typec_port *port, enum typec_pwr_opmode mode);
+int typec_of_get_port_type(struct device_node *np);
+int typec_of_get_preferred_role(struct device_node *np);
 
 #endif /* __LINUX_USB_TYPEC_H */

[PATCH v2 02/12] usb: typec: add API to get sink and source config

[Li Jun]

This patch add 2 APIs to get sink and source power config from firmware
description.

Signed-off-by: Li Jun <jun.li@nxp.com>
---
 drivers/usb/typec/tcpm.c | 43 +++++++++++++++++++++++++++++++++++++++++++
 include/linux/usb/tcpm.h |  2 ++
 2 files changed, 45 insertions(+)

diff --git a/drivers/usb/typec/tcpm.c b/drivers/usb/typec/tcpm.c
index f4d563e..409f1d0 100644
--- a/drivers/usb/typec/tcpm.c
+++ b/drivers/usb/typec/tcpm.c
@@ -12,6 +12,7 @@
 #include <linux/kernel.h>
 #include <linux/module.h>
 #include <linux/mutex.h>
+#include <linux/of.h>
 #include <linux/proc_fs.h>
 #include <linux/sched/clock.h>
 #include <linux/seq_file.h>
@@ -3589,6 +3590,48 @@ static int tcpm_copy_vdos(u32 *dest_vdo, const u32 *src_vdo,
 	return nr_vdo;
 }
 
+int tcpm_of_get_src_config(struct device_node *np, struct tcpc_config *tcfg)
+{
+	int ret;
+
+	ret = of_property_read_variable_u32_array(np, "src-pdos",
+				tcfg->src_pdo, 1, PDO_MAX_OBJECTS);
+	if (ret > 0)
+		tcfg->nr_src_pdo = ret;
+
+	return ret;
+}
+EXPORT_SYMBOL_GPL(tcpm_of_get_pdos);
+
+int tcpm_of_get_snk_config(struct device_node *np, struct tcpc_config *tcfg)
+{
+	int ret;
+
+	ret = of_property_read_variable_u32_array(np, "snk-pdos",
+				tcfg->snk_pdo, 1, PDO_MAX_OBJECTS);
+	if (ret > 0)
+		tcfg->nr_snk_pdo = ret;
+	else
+		return ret;
+
+	ret = of_property_read_u32(np, "max-snk-microvolt", &tcfg->max_snk_mv);
+	if (ret)
+		return ret;
+
+	ret = of_property_read_u32(np, "max-snk-microamp", &tcfg->max_snk_ma);
+	if (ret)
+		return ret;
+
+	ret = of_property_read_u32(np, "max-snk-microwatt-hours",
+				   &tcfg->max_snk_mw);
+	if (ret)
+		return ret;
+
+	return of_property_read_u32(np, "op-snk-microwatt-hours",
+				    &tcfg->operating_snk_mw);
+}
+EXPORT_SYMBOL_GPL(tcpm_of_get_pdos);
+
 int tcpm_update_source_capabilities(struct tcpm_port *port, const u32 *pdo,
 				    unsigned int nr_pdo)
 {
diff --git a/include/linux/usb/tcpm.h b/include/linux/usb/tcpm.h
index ca1c0b5..962eff1 100644
--- a/include/linux/usb/tcpm.h
+++ b/include/linux/usb/tcpm.h
@@ -191,6 +191,8 @@ int tcpm_update_sink_capabilities(struct tcpm_port *port, const u32 *pdo,
 				  unsigned int max_snk_ma,
 				  unsigned int max_snk_mw,
 				  unsigned int operating_snk_mw);
+int tcpm_of_get_src_config(struct device_node *np, struct tcpc_config *tcfg);
+int tcpm_of_get_snk_config(struct device_node *np, struct tcpc_config *tcfg);
 
 void tcpm_vbus_change(struct tcpm_port *port);
 void tcpm_cc_change(struct tcpm_port *port);
-- 
2.7.4

[v2,02/12] usb: typec: add API to get sink and source config

[Jun Li]

This patch add 2 APIs to get sink and source power config from firmware
description.

Signed-off-by: Li Jun <jun.li@nxp.com>
---
 drivers/usb/typec/tcpm.c | 43 +++++++++++++++++++++++++++++++++++++++++++
 include/linux/usb/tcpm.h |  2 ++
 2 files changed, 45 insertions(+)

diff --git a/drivers/usb/typec/tcpm.c b/drivers/usb/typec/tcpm.c
index f4d563e..409f1d0 100644
--- a/drivers/usb/typec/tcpm.c
+++ b/drivers/usb/typec/tcpm.c
@@ -12,6 +12,7 @@
 #include <linux/kernel.h>
 #include <linux/module.h>
 #include <linux/mutex.h>
+#include <linux/of.h>
 #include <linux/proc_fs.h>
 #include <linux/sched/clock.h>
 #include <linux/seq_file.h>
@@ -3589,6 +3590,48 @@ static int tcpm_copy_vdos(u32 *dest_vdo, const u32 *src_vdo,
 	return nr_vdo;
 }
 
+int tcpm_of_get_src_config(struct device_node *np, struct tcpc_config *tcfg)
+{
+	int ret;
+
+	ret = of_property_read_variable_u32_array(np, "src-pdos",
+				tcfg->src_pdo, 1, PDO_MAX_OBJECTS);
+	if (ret > 0)
+		tcfg->nr_src_pdo = ret;
+
+	return ret;
+}
+EXPORT_SYMBOL_GPL(tcpm_of_get_pdos);
+
+int tcpm_of_get_snk_config(struct device_node *np, struct tcpc_config *tcfg)
+{
+	int ret;
+
+	ret = of_property_read_variable_u32_array(np, "snk-pdos",
+				tcfg->snk_pdo, 1, PDO_MAX_OBJECTS);
+	if (ret > 0)
+		tcfg->nr_snk_pdo = ret;
+	else
+		return ret;
+
+	ret = of_property_read_u32(np, "max-snk-microvolt", &tcfg->max_snk_mv);
+	if (ret)
+		return ret;
+
+	ret = of_property_read_u32(np, "max-snk-microamp", &tcfg->max_snk_ma);
+	if (ret)
+		return ret;
+
+	ret = of_property_read_u32(np, "max-snk-microwatt-hours",
+				   &tcfg->max_snk_mw);
+	if (ret)
+		return ret;
+
+	return of_property_read_u32(np, "op-snk-microwatt-hours",
+				    &tcfg->operating_snk_mw);
+}
+EXPORT_SYMBOL_GPL(tcpm_of_get_pdos);
+
 int tcpm_update_source_capabilities(struct tcpm_port *port, const u32 *pdo,
 				    unsigned int nr_pdo)
 {
diff --git a/include/linux/usb/tcpm.h b/include/linux/usb/tcpm.h
index ca1c0b5..962eff1 100644
--- a/include/linux/usb/tcpm.h
+++ b/include/linux/usb/tcpm.h
@@ -191,6 +191,8 @@ int tcpm_update_sink_capabilities(struct tcpm_port *port, const u32 *pdo,
 				  unsigned int max_snk_ma,
 				  unsigned int max_snk_mw,
 				  unsigned int operating_snk_mw);
+int tcpm_of_get_src_config(struct device_node *np, struct tcpc_config *tcfg);
+int tcpm_of_get_snk_config(struct device_node *np, struct tcpc_config *tcfg);
 
 void tcpm_vbus_change(struct tcpm_port *port);
 void tcpm_cc_change(struct tcpm_port *port);

[PATCH v2 03/12] staging: typec: tcpci: support port config passed via dt

[Li Jun]

User can define the typec port properties in tcpci node to setup
the port config.

Signed-off-by: Li Jun <jun.li@nxp.com>
---
Changes for v2:
- Use infra APIs to get sink and source config.
- Improve the error message.

 drivers/staging/typec/tcpci.c | 70 ++++++++++++++++++++++++++++++++++++++-----
 include/linux/usb/tcpm.h      |  6 ++--
 2 files changed, 66 insertions(+), 10 deletions(-)

diff --git a/drivers/staging/typec/tcpci.c b/drivers/staging/typec/tcpci.c
index b6abaf7..be6ed16 100644
--- a/drivers/staging/typec/tcpci.c
+++ b/drivers/staging/typec/tcpci.c
@@ -426,17 +426,73 @@ static const struct regmap_config tcpci_regmap_config = {
 	.max_register = 0x7F, /* 0x80 .. 0xFF are vendor defined */
 };
 
-static const struct tcpc_config tcpci_tcpc_config = {
-	.type = TYPEC_PORT_DFP,
-	.default_role = TYPEC_SINK,
-};
-
+/* Populate struct tcpc_config from device-tree */
 static int tcpci_parse_config(struct tcpci *tcpci)
 {
+	struct tcpc_config *tcfg;
+	struct device_node *child;
+	int ret = -EINVAL;
+
 	tcpci->controls_vbus = true; /* XXX */
 
-	/* TODO: Populate struct tcpc_config from ACPI/device-tree */
-	tcpci->tcpc.config = &tcpci_tcpc_config;
+	tcpci->tcpc.config = devm_kzalloc(tcpci->dev, sizeof(*tcfg),
+					  GFP_KERNEL);
+	if (!tcpci->tcpc.config)
+		return -ENOMEM;
+
+	tcfg = tcpci->tcpc.config;
+
+	child = of_get_child_by_name(tcpci->dev->of_node, "connector");
+	if (!child) {
+		dev_err(tcpci->dev, "failed to get connector node.\n");
+		return -EINVAL;
+	}
+
+	/* Get port-type */
+	ret = typec_of_get_port_type(child);
+	if (ret < 0) {
+		dev_err(tcpci->dev, "failed to get correct port type.\n");
+		return ret;
+	}
+	tcfg->type = ret;
+
+	if (tcfg->type == TYPEC_PORT_UFP)
+		goto sink;
+
+	tcfg->src_pdo = devm_kcalloc(tcpci->dev, PDO_MAX_OBJECTS,
+				     sizeof(*tcfg->src_pdo), GFP_KERNEL);
+	if (!tcfg->src_pdo)
+		return -ENOMEM;
+
+	/* Get source capability */
+	ret = tcpm_of_get_src_config(child, tcfg);
+	if (ret <= 0) {
+		dev_err(tcpci->dev, "failed to get source pdo %d\n", ret);
+		return -EINVAL;
+	}
+
+	if (tcfg->type == TYPEC_PORT_DFP)
+		return 0;
+
+	/* Get the preferred power role for drp */
+	ret = typec_of_get_preferred_role(child);
+	if (ret < 0) {
+		dev_err(tcpci->dev, "failed to get correct preferred role.\n");
+		return ret;
+	}
+	tcfg->default_role = ret;
+sink:
+	tcfg->snk_pdo = devm_kcalloc(tcpci->dev, PDO_MAX_OBJECTS,
+				     sizeof(*tcfg->snk_pdo), GFP_KERNEL);
+	if (!tcfg->snk_pdo)
+		return -ENOMEM;
+
+	/* Get power sink config */
+	ret = tcpm_of_get_snk_config(child, tcfg);
+	if (ret < 0) {
+		dev_err(tcpci->dev, "failed to get sink configs %d\n", ret);
+		return -EINVAL;
+	}
 
 	return 0;
 }
diff --git a/include/linux/usb/tcpm.h b/include/linux/usb/tcpm.h
index 962eff1..8e9edb4 100644
--- a/include/linux/usb/tcpm.h
+++ b/include/linux/usb/tcpm.h
@@ -76,10 +76,10 @@ enum tcpm_transmit_type {
  * @alt_modes:	List of supported alternate modes
  */
 struct tcpc_config {
-	const u32 *src_pdo;
+	u32 *src_pdo;
 	unsigned int nr_src_pdo;
 
-	const u32 *snk_pdo;
+	u32 *snk_pdo;
 	unsigned int nr_snk_pdo;
 
 	const u32 *snk_vdo;
@@ -154,7 +154,7 @@ struct tcpc_mux_dev {
  * @mux:	Pointer to multiplexer data
  */
 struct tcpc_dev {
-	const struct tcpc_config *config;
+	struct tcpc_config *config;
 
 	int (*init)(struct tcpc_dev *dev);
 	int (*get_vbus)(struct tcpc_dev *dev);
-- 
2.7.4

[v2,03/12] staging: typec: tcpci: support port config passed via dt

[Jun Li]

User can define the typec port properties in tcpci node to setup
the port config.

Signed-off-by: Li Jun <jun.li@nxp.com>
---
Changes for v2:
- Use infra APIs to get sink and source config.
- Improve the error message.

 drivers/staging/typec/tcpci.c | 70 ++++++++++++++++++++++++++++++++++++++-----
 include/linux/usb/tcpm.h      |  6 ++--
 2 files changed, 66 insertions(+), 10 deletions(-)

diff --git a/drivers/staging/typec/tcpci.c b/drivers/staging/typec/tcpci.c
index b6abaf7..be6ed16 100644
--- a/drivers/staging/typec/tcpci.c
+++ b/drivers/staging/typec/tcpci.c
@@ -426,17 +426,73 @@ static const struct regmap_config tcpci_regmap_config = {
 	.max_register = 0x7F, /* 0x80 .. 0xFF are vendor defined */
 };
 
-static const struct tcpc_config tcpci_tcpc_config = {
-	.type = TYPEC_PORT_DFP,
-	.default_role = TYPEC_SINK,
-};
-
+/* Populate struct tcpc_config from device-tree */
 static int tcpci_parse_config(struct tcpci *tcpci)
 {
+	struct tcpc_config *tcfg;
+	struct device_node *child;
+	int ret = -EINVAL;
+
 	tcpci->controls_vbus = true; /* XXX */
 
-	/* TODO: Populate struct tcpc_config from ACPI/device-tree */
-	tcpci->tcpc.config = &tcpci_tcpc_config;
+	tcpci->tcpc.config = devm_kzalloc(tcpci->dev, sizeof(*tcfg),
+					  GFP_KERNEL);
+	if (!tcpci->tcpc.config)
+		return -ENOMEM;
+
+	tcfg = tcpci->tcpc.config;
+
+	child = of_get_child_by_name(tcpci->dev->of_node, "connector");
+	if (!child) {
+		dev_err(tcpci->dev, "failed to get connector node.\n");
+		return -EINVAL;
+	}
+
+	/* Get port-type */
+	ret = typec_of_get_port_type(child);
+	if (ret < 0) {
+		dev_err(tcpci->dev, "failed to get correct port type.\n");
+		return ret;
+	}
+	tcfg->type = ret;
+
+	if (tcfg->type == TYPEC_PORT_UFP)
+		goto sink;
+
+	tcfg->src_pdo = devm_kcalloc(tcpci->dev, PDO_MAX_OBJECTS,
+				     sizeof(*tcfg->src_pdo), GFP_KERNEL);
+	if (!tcfg->src_pdo)
+		return -ENOMEM;
+
+	/* Get source capability */
+	ret = tcpm_of_get_src_config(child, tcfg);
+	if (ret <= 0) {
+		dev_err(tcpci->dev, "failed to get source pdo %d\n", ret);
+		return -EINVAL;
+	}
+
+	if (tcfg->type == TYPEC_PORT_DFP)
+		return 0;
+
+	/* Get the preferred power role for drp */
+	ret = typec_of_get_preferred_role(child);
+	if (ret < 0) {
+		dev_err(tcpci->dev, "failed to get correct preferred role.\n");
+		return ret;
+	}
+	tcfg->default_role = ret;
+sink:
+	tcfg->snk_pdo = devm_kcalloc(tcpci->dev, PDO_MAX_OBJECTS,
+				     sizeof(*tcfg->snk_pdo), GFP_KERNEL);
+	if (!tcfg->snk_pdo)
+		return -ENOMEM;
+
+	/* Get power sink config */
+	ret = tcpm_of_get_snk_config(child, tcfg);
+	if (ret < 0) {
+		dev_err(tcpci->dev, "failed to get sink configs %d\n", ret);
+		return -EINVAL;
+	}
 
 	return 0;
 }
diff --git a/include/linux/usb/tcpm.h b/include/linux/usb/tcpm.h
index 962eff1..8e9edb4 100644
--- a/include/linux/usb/tcpm.h
+++ b/include/linux/usb/tcpm.h
@@ -76,10 +76,10 @@ enum tcpm_transmit_type {
  * @alt_modes:	List of supported alternate modes
  */
 struct tcpc_config {
-	const u32 *src_pdo;
+	u32 *src_pdo;
 	unsigned int nr_src_pdo;
 
-	const u32 *snk_pdo;
+	u32 *snk_pdo;
 	unsigned int nr_snk_pdo;
 
 	const u32 *snk_vdo;
@@ -154,7 +154,7 @@ struct tcpc_mux_dev {
  * @mux:	Pointer to multiplexer data
  */
 struct tcpc_dev {
-	const struct tcpc_config *config;
+	struct tcpc_config *config;
 
 	int (*init)(struct tcpc_dev *dev);
 	int (*get_vbus)(struct tcpc_dev *dev);

[PATCH v2 04/12] staging: typec: tcpci: register port before request irq

[Li Jun]

With that we can clear any pending events and the port is registered
so driver can be ready to handle typec events once we request irq.

Signed-off-by: Peter Chen <peter.chen@nxp.com>
Signed-off-by: Li Jun <jun.li@nxp.com>
---
 drivers/staging/typec/tcpci.c | 11 +++++++----
 1 file changed, 7 insertions(+), 4 deletions(-)

diff --git a/drivers/staging/typec/tcpci.c b/drivers/staging/typec/tcpci.c
index be6ed16..1db67f0 100644
--- a/drivers/staging/typec/tcpci.c
+++ b/drivers/staging/typec/tcpci.c
@@ -534,15 +534,18 @@ static int tcpci_probe(struct i2c_client *client,
 	/* Disable chip interrupts */
 	tcpci_write16(tcpci, TCPC_ALERT_MASK, 0);
 
+	tcpci->port = tcpm_register_port(tcpci->dev, &tcpci->tcpc);
+	if (IS_ERR(tcpci->port))
+		return PTR_ERR(tcpci->port);
+
 	err = devm_request_threaded_irq(tcpci->dev, client->irq, NULL,
 					tcpci_irq,
 					IRQF_ONESHOT | IRQF_TRIGGER_LOW,
 					dev_name(tcpci->dev), tcpci);
-	if (err < 0)
-		return err;
+	if (err)
+		tcpm_unregister_port(tcpci->port);
 
-	tcpci->port = tcpm_register_port(tcpci->dev, &tcpci->tcpc);
-	return PTR_ERR_OR_ZERO(tcpci->port);
+	return err;
 }
 
 static int tcpci_remove(struct i2c_client *client)
-- 
2.7.4

[v2,04/12] staging: typec: tcpci: register port before request irq

[Jun Li]

With that we can clear any pending events and the port is registered
so driver can be ready to handle typec events once we request irq.

Signed-off-by: Peter Chen <peter.chen@nxp.com>
Signed-off-by: Li Jun <jun.li@nxp.com>
---
 drivers/staging/typec/tcpci.c | 11 +++++++----
 1 file changed, 7 insertions(+), 4 deletions(-)

diff --git a/drivers/staging/typec/tcpci.c b/drivers/staging/typec/tcpci.c
index be6ed16..1db67f0 100644
--- a/drivers/staging/typec/tcpci.c
+++ b/drivers/staging/typec/tcpci.c
@@ -534,15 +534,18 @@ static int tcpci_probe(struct i2c_client *client,
 	/* Disable chip interrupts */
 	tcpci_write16(tcpci, TCPC_ALERT_MASK, 0);
 
+	tcpci->port = tcpm_register_port(tcpci->dev, &tcpci->tcpc);
+	if (IS_ERR(tcpci->port))
+		return PTR_ERR(tcpci->port);
+
 	err = devm_request_threaded_irq(tcpci->dev, client->irq, NULL,
 					tcpci_irq,
 					IRQF_ONESHOT | IRQF_TRIGGER_LOW,
 					dev_name(tcpci->dev), tcpci);
-	if (err < 0)
-		return err;
+	if (err)
+		tcpm_unregister_port(tcpci->port);
 
-	tcpci->port = tcpm_register_port(tcpci->dev, &tcpci->tcpc);
-	return PTR_ERR_OR_ZERO(tcpci->port);
+	return err;
 }
 
 static int tcpci_remove(struct i2c_client *client)

[PATCH v2 05/12] staging: typec: tcpci: enable vbus detection

[Li Jun]

TCPCI implementation may need SW to enable VBUS detection to generate
power status events.

Signed-off-by: Li Jun <jun.li@nxp.com>
---
Change for v2:
- Directly enable vbus detect in tcpci_init rather than adding a API.

 drivers/staging/typec/tcpci.c | 6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/drivers/staging/typec/tcpci.c b/drivers/staging/typec/tcpci.c
index 1db67f0..953fc97 100644
--- a/drivers/staging/typec/tcpci.c
+++ b/drivers/staging/typec/tcpci.c
@@ -345,6 +345,12 @@ static int tcpci_init(struct tcpc_dev *tcpc)
 	if (ret < 0)
 		return ret;
 
+	/* Enable Vbus detection */
+	ret = regmap_write(tcpci->regmap, TCPC_COMMAND,
+			   TCPC_CMD_ENABLE_VBUS_DETECT);
+	if (ret < 0)
+		return ret;
+
 	reg = TCPC_ALERT_TX_SUCCESS | TCPC_ALERT_TX_FAILED |
 		TCPC_ALERT_TX_DISCARDED | TCPC_ALERT_RX_STATUS |
 		TCPC_ALERT_RX_HARD_RST | TCPC_ALERT_CC_STATUS;
-- 
2.7.4

[v2,05/12] staging: typec: tcpci: enable vbus detection

[Jun Li]

TCPCI implementation may need SW to enable VBUS detection to generate
power status events.

Signed-off-by: Li Jun <jun.li@nxp.com>
---
Change for v2:
- Directly enable vbus detect in tcpci_init rather than adding a API.

 drivers/staging/typec/tcpci.c | 6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/drivers/staging/typec/tcpci.c b/drivers/staging/typec/tcpci.c
index 1db67f0..953fc97 100644
--- a/drivers/staging/typec/tcpci.c
+++ b/drivers/staging/typec/tcpci.c
@@ -345,6 +345,12 @@ static int tcpci_init(struct tcpc_dev *tcpc)
 	if (ret < 0)
 		return ret;
 
+	/* Enable Vbus detection */
+	ret = regmap_write(tcpci->regmap, TCPC_COMMAND,
+			   TCPC_CMD_ENABLE_VBUS_DETECT);
+	if (ret < 0)
+		return ret;
+
 	reg = TCPC_ALERT_TX_SUCCESS | TCPC_ALERT_TX_FAILED |
 		TCPC_ALERT_TX_DISCARDED | TCPC_ALERT_RX_STATUS |
 		TCPC_ALERT_RX_HARD_RST | TCPC_ALERT_CC_STATUS;

[PATCH v2 06/12] typec: tcpm: add starting value for drp toggling

[Li Jun]

As DRP port autonomously toggles the Rp/Rd need a start value to
begin with, so add one parameter for it in tcpm_start_drp_toggling.

Signed-off-by: Li Jun <jun.li@nxp.com>
---
 drivers/usb/typec/tcpm.c | 10 +++++-----
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/drivers/usb/typec/tcpm.c b/drivers/usb/typec/tcpm.c
index 409f1d0..488a252 100644
--- a/drivers/usb/typec/tcpm.c
+++ b/drivers/usb/typec/tcpm.c
@@ -1985,15 +1985,15 @@ static int tcpm_set_charge(struct tcpm_port *port, bool charge)
 	return 0;
 }
 
-static bool tcpm_start_drp_toggling(struct tcpm_port *port)
+static bool tcpm_start_drp_toggling(struct tcpm_port *port,
+				    enum typec_cc_status cc)
 {
 	int ret;
 
 	if (port->tcpc->start_drp_toggling &&
 	    port->port_type == TYPEC_PORT_DRP) {
 		tcpm_log_force(port, "Start DRP toggling");
-		ret = port->tcpc->start_drp_toggling(port->tcpc,
-						     tcpm_rp_cc(port));
+		ret = port->tcpc->start_drp_toggling(port->tcpc, cc);
 		if (!ret)
 			return true;
 	}
@@ -2302,7 +2302,7 @@ static void run_state_machine(struct tcpm_port *port)
 		if (!port->non_pd_role_swap)
 			tcpm_swap_complete(port, -ENOTCONN);
 		tcpm_src_detach(port);
-		if (tcpm_start_drp_toggling(port)) {
+		if (tcpm_start_drp_toggling(port, tcpm_rp_cc(port))) {
 			tcpm_set_state(port, DRP_TOGGLING, 0);
 			break;
 		}
@@ -2474,7 +2474,7 @@ static void run_state_machine(struct tcpm_port *port)
 		if (!port->non_pd_role_swap)
 			tcpm_swap_complete(port, -ENOTCONN);
 		tcpm_snk_detach(port);
-		if (tcpm_start_drp_toggling(port)) {
+		if (tcpm_start_drp_toggling(port, TYPEC_CC_RD)) {
 			tcpm_set_state(port, DRP_TOGGLING, 0);
 			break;
 		}
-- 
2.7.4

[v2,06/12] typec: tcpm: add starting value for drp toggling

[Jun Li]

As DRP port autonomously toggles the Rp/Rd need a start value to
begin with, so add one parameter for it in tcpm_start_drp_toggling.

Signed-off-by: Li Jun <jun.li@nxp.com>
---
 drivers/usb/typec/tcpm.c | 10 +++++-----
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/drivers/usb/typec/tcpm.c b/drivers/usb/typec/tcpm.c
index 409f1d0..488a252 100644
--- a/drivers/usb/typec/tcpm.c
+++ b/drivers/usb/typec/tcpm.c
@@ -1985,15 +1985,15 @@ static int tcpm_set_charge(struct tcpm_port *port, bool charge)
 	return 0;
 }
 
-static bool tcpm_start_drp_toggling(struct tcpm_port *port)
+static bool tcpm_start_drp_toggling(struct tcpm_port *port,
+				    enum typec_cc_status cc)
 {
 	int ret;
 
 	if (port->tcpc->start_drp_toggling &&
 	    port->port_type == TYPEC_PORT_DRP) {
 		tcpm_log_force(port, "Start DRP toggling");
-		ret = port->tcpc->start_drp_toggling(port->tcpc,
-						     tcpm_rp_cc(port));
+		ret = port->tcpc->start_drp_toggling(port->tcpc, cc);
 		if (!ret)
 			return true;
 	}
@@ -2302,7 +2302,7 @@ static void run_state_machine(struct tcpm_port *port)
 		if (!port->non_pd_role_swap)
 			tcpm_swap_complete(port, -ENOTCONN);
 		tcpm_src_detach(port);
-		if (tcpm_start_drp_toggling(port)) {
+		if (tcpm_start_drp_toggling(port, tcpm_rp_cc(port))) {
 			tcpm_set_state(port, DRP_TOGGLING, 0);
 			break;
 		}
@@ -2474,7 +2474,7 @@ static void run_state_machine(struct tcpm_port *port)
 		if (!port->non_pd_role_swap)
 			tcpm_swap_complete(port, -ENOTCONN);
 		tcpm_snk_detach(port);
-		if (tcpm_start_drp_toggling(port)) {
+		if (tcpm_start_drp_toggling(port, TYPEC_CC_RD)) {
 			tcpm_set_state(port, DRP_TOGGLING, 0);
 			break;
 		}

[PATCH v2 07/12] staging: typec: tcpci: correct drp toggling

[Li Jun]

Per tcpci spec 4.4.5.2 ROLE_CONTROL description: "the TCPM shall
write B6 (DRP) =1b and the starting value of Rp/Rd to B3..0 (CC1/CC2)
to indicate DRP autonomous toggling mode to the TCPC", so add CC1/CC2
setting, also we should issue COMMAND.Look4Connection to start it.

Signed-off-by: Li Jun <jun.li@nxp.com>
---
 drivers/staging/typec/tcpci.c | 15 ++++++++++++++-
 1 file changed, 14 insertions(+), 1 deletion(-)

diff --git a/drivers/staging/typec/tcpci.c b/drivers/staging/typec/tcpci.c
index 953fc97..530a5d7 100644
--- a/drivers/staging/typec/tcpci.c
+++ b/drivers/staging/typec/tcpci.c
@@ -109,6 +109,7 @@ static int tcpci_start_drp_toggling(struct tcpc_dev *tcpc,
 {
 	struct tcpci *tcpci = tcpc_to_tcpci(tcpc);
 	unsigned int reg = TCPC_ROLE_CTRL_DRP;
+	int ret;
 
 	switch (cc) {
 	default:
@@ -126,7 +127,19 @@ static int tcpci_start_drp_toggling(struct tcpc_dev *tcpc,
 		break;
 	}
 
-	return regmap_write(tcpci->regmap, TCPC_ROLE_CTRL, reg);
+	if (cc == TYPEC_CC_RD)
+		reg |= (TCPC_ROLE_CTRL_CC_RD << TCPC_ROLE_CTRL_CC1_SHIFT) |
+			(TCPC_ROLE_CTRL_CC_RD << TCPC_ROLE_CTRL_CC2_SHIFT);
+	else
+		reg |= (TCPC_ROLE_CTRL_CC_RP << TCPC_ROLE_CTRL_CC1_SHIFT) |
+			(TCPC_ROLE_CTRL_CC_RP << TCPC_ROLE_CTRL_CC2_SHIFT);
+
+	ret = regmap_write(tcpci->regmap, TCPC_ROLE_CTRL, reg);
+	if (ret < 0)
+		return ret;
+
+	return regmap_write(tcpci->regmap, TCPC_COMMAND,
+				TCPC_CMD_LOOK4CONNECTION);
 }
 
 static enum typec_cc_status tcpci_to_typec_cc(unsigned int cc, bool sink)
-- 
2.7.4

[v2,07/12] staging: typec: tcpci: correct drp toggling

[Jun Li]

Per tcpci spec 4.4.5.2 ROLE_CONTROL description: "the TCPM shall
write B6 (DRP) =1b and the starting value of Rp/Rd to B3..0 (CC1/CC2)
to indicate DRP autonomous toggling mode to the TCPC", so add CC1/CC2
setting, also we should issue COMMAND.Look4Connection to start it.

Signed-off-by: Li Jun <jun.li@nxp.com>
---
 drivers/staging/typec/tcpci.c | 15 ++++++++++++++-
 1 file changed, 14 insertions(+), 1 deletion(-)

diff --git a/drivers/staging/typec/tcpci.c b/drivers/staging/typec/tcpci.c
index 953fc97..530a5d7 100644
--- a/drivers/staging/typec/tcpci.c
+++ b/drivers/staging/typec/tcpci.c
@@ -109,6 +109,7 @@ static int tcpci_start_drp_toggling(struct tcpc_dev *tcpc,
 {
 	struct tcpci *tcpci = tcpc_to_tcpci(tcpc);
 	unsigned int reg = TCPC_ROLE_CTRL_DRP;
+	int ret;
 
 	switch (cc) {
 	default:
@@ -126,7 +127,19 @@ static int tcpci_start_drp_toggling(struct tcpc_dev *tcpc,
 		break;
 	}
 
-	return regmap_write(tcpci->regmap, TCPC_ROLE_CTRL, reg);
+	if (cc == TYPEC_CC_RD)
+		reg |= (TCPC_ROLE_CTRL_CC_RD << TCPC_ROLE_CTRL_CC1_SHIFT) |
+			(TCPC_ROLE_CTRL_CC_RD << TCPC_ROLE_CTRL_CC2_SHIFT);
+	else
+		reg |= (TCPC_ROLE_CTRL_CC_RP << TCPC_ROLE_CTRL_CC1_SHIFT) |
+			(TCPC_ROLE_CTRL_CC_RP << TCPC_ROLE_CTRL_CC2_SHIFT);
+
+	ret = regmap_write(tcpci->regmap, TCPC_ROLE_CTRL, reg);
+	if (ret < 0)
+		return ret;
+
+	return regmap_write(tcpci->regmap, TCPC_COMMAND,
+				TCPC_CMD_LOOK4CONNECTION);
 }
 
 static enum typec_cc_status tcpci_to_typec_cc(unsigned int cc, bool sink)

[PATCH v2 08/12] staging: typec: tcpci: keep the uncontact cc line open

[Li Jun]

While set polarity, we should keep the disconnected cc line to be
open when attached.

Signed-off-by: Li Jun <jun.li@nxp.com>
---
Change for v2:
- Set the uncontact cc line to be open when set polarity, this way,
  we don't need change set_cc api.

 drivers/staging/typec/tcpci.c | 15 +++++++++++++++
 1 file changed, 15 insertions(+)

diff --git a/drivers/staging/typec/tcpci.c b/drivers/staging/typec/tcpci.c
index 530a5d7..7145771 100644
--- a/drivers/staging/typec/tcpci.c
+++ b/drivers/staging/typec/tcpci.c
@@ -184,6 +184,7 @@ static int tcpci_set_polarity(struct tcpc_dev *tcpc,
 			      enum typec_cc_polarity polarity)
 {
 	struct tcpci *tcpci = tcpc_to_tcpci(tcpc);
+	unsigned int reg;
 	int ret;
 
 	ret = regmap_write(tcpci->regmap, TCPC_TCPC_CTRL,
@@ -192,6 +193,20 @@ static int tcpci_set_polarity(struct tcpc_dev *tcpc,
 	if (ret < 0)
 		return ret;
 
+	ret = regmap_read(tcpci->regmap, TCPC_ROLE_CTRL, &reg);
+	if (ret < 0)
+		return ret;
+
+	if (polarity == TYPEC_POLARITY_CC2)
+		ret = TCPC_ROLE_CTRL_CC1_SHIFT;
+	else
+		ret = TCPC_ROLE_CTRL_CC2_SHIFT;
+	reg |= TCPC_ROLE_CTRL_CC_OPEN << ret;
+	reg &= ~TCPC_ROLE_CTRL_DRP;
+	ret = regmap_write(tcpci->regmap, TCPC_ROLE_CTRL, reg);
+	if (ret < 0)
+		return ret;
+
 	return 0;
 }
 
-- 
2.7.4

[v2,08/12] staging: typec: tcpci: keep the uncontact cc line open

[Jun Li]

While set polarity, we should keep the disconnected cc line to be
open when attached.

Signed-off-by: Li Jun <jun.li@nxp.com>
---
Change for v2:
- Set the uncontact cc line to be open when set polarity, this way,
  we don't need change set_cc api.

 drivers/staging/typec/tcpci.c | 15 +++++++++++++++
 1 file changed, 15 insertions(+)

diff --git a/drivers/staging/typec/tcpci.c b/drivers/staging/typec/tcpci.c
index 530a5d7..7145771 100644
--- a/drivers/staging/typec/tcpci.c
+++ b/drivers/staging/typec/tcpci.c
@@ -184,6 +184,7 @@ static int tcpci_set_polarity(struct tcpc_dev *tcpc,
 			      enum typec_cc_polarity polarity)
 {
 	struct tcpci *tcpci = tcpc_to_tcpci(tcpc);
+	unsigned int reg;
 	int ret;
 
 	ret = regmap_write(tcpci->regmap, TCPC_TCPC_CTRL,
@@ -192,6 +193,20 @@ static int tcpci_set_polarity(struct tcpc_dev *tcpc,
 	if (ret < 0)
 		return ret;
 
+	ret = regmap_read(tcpci->regmap, TCPC_ROLE_CTRL, &reg);
+	if (ret < 0)
+		return ret;
+
+	if (polarity == TYPEC_POLARITY_CC2)
+		ret = TCPC_ROLE_CTRL_CC1_SHIFT;
+	else
+		ret = TCPC_ROLE_CTRL_CC2_SHIFT;
+	reg |= TCPC_ROLE_CTRL_CC_OPEN << ret;
+	reg &= ~TCPC_ROLE_CTRL_DRP;
+	ret = regmap_write(tcpci->regmap, TCPC_ROLE_CTRL, reg);
+	if (ret < 0)
+		return ret;
+
 	return 0;
 }
 

[PATCH v2 09/12] staging: typec: tcpci: Only touch target bit when enable vconn

[Li Jun]

We need regmap_update_bits to avoid touch any other bits when
enable or disable vconn.

Signed-off-by: Li Jun <jun.li@nxp.com>
---
 drivers/staging/typec/tcpci.c | 10 +++-------
 1 file changed, 3 insertions(+), 7 deletions(-)

diff --git a/drivers/staging/typec/tcpci.c b/drivers/staging/typec/tcpci.c
index 7145771..27d53c6 100644
--- a/drivers/staging/typec/tcpci.c
+++ b/drivers/staging/typec/tcpci.c
@@ -213,14 +213,10 @@ static int tcpci_set_polarity(struct tcpc_dev *tcpc,
 static int tcpci_set_vconn(struct tcpc_dev *tcpc, bool enable)
 {
 	struct tcpci *tcpci = tcpc_to_tcpci(tcpc);
-	int ret;
 
-	ret = regmap_write(tcpci->regmap, TCPC_POWER_CTRL,
-			   enable ? TCPC_POWER_CTRL_VCONN_ENABLE : 0);
-	if (ret < 0)
-		return ret;
-
-	return 0;
+	return regmap_update_bits(tcpci->regmap, TCPC_POWER_CTRL,
+				TCPC_POWER_CTRL_VCONN_ENABLE,
+				enable ? TCPC_POWER_CTRL_VCONN_ENABLE : 0);
 }
 
 static int tcpci_set_roles(struct tcpc_dev *tcpc, bool attached,
-- 
2.7.4

[v2,09/12] staging: typec: tcpci: Only touch target bit when enable vconn

[Jun Li]

We need regmap_update_bits to avoid touch any other bits when
enable or disable vconn.

Signed-off-by: Li Jun <jun.li@nxp.com>
---
 drivers/staging/typec/tcpci.c | 10 +++-------
 1 file changed, 3 insertions(+), 7 deletions(-)

diff --git a/drivers/staging/typec/tcpci.c b/drivers/staging/typec/tcpci.c
index 7145771..27d53c6 100644
--- a/drivers/staging/typec/tcpci.c
+++ b/drivers/staging/typec/tcpci.c
@@ -213,14 +213,10 @@ static int tcpci_set_polarity(struct tcpc_dev *tcpc,
 static int tcpci_set_vconn(struct tcpc_dev *tcpc, bool enable)
 {
 	struct tcpci *tcpci = tcpc_to_tcpci(tcpc);
-	int ret;
 
-	ret = regmap_write(tcpci->regmap, TCPC_POWER_CTRL,
-			   enable ? TCPC_POWER_CTRL_VCONN_ENABLE : 0);
-	if (ret < 0)
-		return ret;
-
-	return 0;
+	return regmap_update_bits(tcpci->regmap, TCPC_POWER_CTRL,
+				TCPC_POWER_CTRL_VCONN_ENABLE,
+				enable ? TCPC_POWER_CTRL_VCONN_ENABLE : 0);
 }
 
 static int tcpci_set_roles(struct tcpc_dev *tcpc, bool attached,

[PATCH v2 10/12] dt-bindings: connector: add properties for typec power delivery

[Li Jun]

In case of usb-c-connector with power delivery support, add bingdings
supported by current typec driver, so user can pass all those properties
via dt.

Signed-off-by: Li Jun <jun.li@nxp.com>
---
Changes for v2:
- Added typec properties are based on general usb connector bindings[1]
  proposed by Andrzej Hajda.
- Use the standard unit suffixes as defined in property-units.txt.

[1] https://patchwork.kernel.org/patch/10231447/

 .../bindings/connector/usb-connector.txt           | 43 ++++++++++++++++++++++
 1 file changed, 43 insertions(+)

diff --git a/Documentation/devicetree/bindings/connector/usb-connector.txt b/Documentation/devicetree/bindings/connector/usb-connector.txt
index e1463f1..242f6df 100644
--- a/Documentation/devicetree/bindings/connector/usb-connector.txt
+++ b/Documentation/devicetree/bindings/connector/usb-connector.txt
@@ -15,6 +15,30 @@ Optional properties:
 - type: size of the connector, should be specified in case of USB-A, USB-B
   non-fullsize connectors: "mini", "micro".
 
+Required properties for usb-c-connector with power delivery support:
+- port-type: should be one of "source", "sink" or "dual".
+- default-role: preferred power role if port-type is "dual"(drp), should be
+  "sink" or "source".
+- src-pdos: An array of u32 with each entry providing supported power
+  source data object(PDO), the detailed bit definitions of PDO can be found
+  in "Universal Serial Bus Power Delivery Specification" chapter 6.4.1.2
+  Source_Capabilities Message, the order of each entry(PDO) should follow
+  the PD spec chapter 6.4.1. Required for power source and power dual role.
+- snk-pdos: An array of u32 with each entry providing supported power
+  sink data object(PDO), the detailed bit definitions of PDO can be found in
+  "Universal Serial Bus Power Delivery Specification" chapter 6.4.1.3 Sink
+  Capabilities Message, the order of each entry(PDO) should follow the PD
+  spec chapter 6.4.1. Required for power sink and power dual role.
+- max-snk-microvolt: The max voltage the sink can support in micro volts,
+  required for power sink and power dual role.
+- max-snk-microamp: The max current the sink can support in micro amps,
+  required for power sink and power dual role.
+- max-snk-microwatt-hours: The max power the sink can support in micro
+  Watt-hours, required for power sink and power dual role.
+- op-snk-microwatt-hours: Sink required operating power in micro Watt-hours,
+  if source offered power is less then it, Capability Mismatch is set,
+  required for power sink and power dual role.
+
 Required nodes:
 - any data bus to the connector should be modeled using the OF graph bindings
   specified in bindings/graph.txt, unless the bus is between parent node and
@@ -73,3 +97,22 @@ ccic: s2mm005@33 {
 		};
 	};
 };
+
+3. USB-C connector attached to a typec port controller(ptn5110), which has
+power delivery support and enables drp.
+
+typec: ptn5110@50 {
+	...
+	usb_con: connector {
+		compatible = "usb-c-connector";
+		label = "USB-C";
+		port-type = "dual";
+		default-role = "sink";
+		src-pdos = <0x380190c8>;
+		snk-pdos = <0x380190c8 0x3802d0c8>;
+		max-snk-microvolt = <9000>;
+		max-snk-microamp = <2000>;
+		max-snk-microwatt-hours = <18000>;
+		op-snk-microwatt-hours = <9000>;
+	};
+};
-- 
2.7.4

[v2,10/12] dt-bindings: connector: add properties for typec power delivery

[Jun Li]

In case of usb-c-connector with power delivery support, add bingdings
supported by current typec driver, so user can pass all those properties
via dt.

Signed-off-by: Li Jun <jun.li@nxp.com>
---
Changes for v2:
- Added typec properties are based on general usb connector bindings[1]
  proposed by Andrzej Hajda.
- Use the standard unit suffixes as defined in property-units.txt.

[1] https://patchwork.kernel.org/patch/10231447/

 .../bindings/connector/usb-connector.txt           | 43 ++++++++++++++++++++++
 1 file changed, 43 insertions(+)

diff --git a/Documentation/devicetree/bindings/connector/usb-connector.txt b/Documentation/devicetree/bindings/connector/usb-connector.txt
index e1463f1..242f6df 100644
--- a/Documentation/devicetree/bindings/connector/usb-connector.txt
+++ b/Documentation/devicetree/bindings/connector/usb-connector.txt
@@ -15,6 +15,30 @@ Optional properties:
 - type: size of the connector, should be specified in case of USB-A, USB-B
   non-fullsize connectors: "mini", "micro".
 
+Required properties for usb-c-connector with power delivery support:
+- port-type: should be one of "source", "sink" or "dual".
+- default-role: preferred power role if port-type is "dual"(drp), should be
+  "sink" or "source".
+- src-pdos: An array of u32 with each entry providing supported power
+  source data object(PDO), the detailed bit definitions of PDO can be found
+  in "Universal Serial Bus Power Delivery Specification" chapter 6.4.1.2
+  Source_Capabilities Message, the order of each entry(PDO) should follow
+  the PD spec chapter 6.4.1. Required for power source and power dual role.
+- snk-pdos: An array of u32 with each entry providing supported power
+  sink data object(PDO), the detailed bit definitions of PDO can be found in
+  "Universal Serial Bus Power Delivery Specification" chapter 6.4.1.3 Sink
+  Capabilities Message, the order of each entry(PDO) should follow the PD
+  spec chapter 6.4.1. Required for power sink and power dual role.
+- max-snk-microvolt: The max voltage the sink can support in micro volts,
+  required for power sink and power dual role.
+- max-snk-microamp: The max current the sink can support in micro amps,
+  required for power sink and power dual role.
+- max-snk-microwatt-hours: The max power the sink can support in micro
+  Watt-hours, required for power sink and power dual role.
+- op-snk-microwatt-hours: Sink required operating power in micro Watt-hours,
+  if source offered power is less then it, Capability Mismatch is set,
+  required for power sink and power dual role.
+
 Required nodes:
 - any data bus to the connector should be modeled using the OF graph bindings
   specified in bindings/graph.txt, unless the bus is between parent node and
@@ -73,3 +97,22 @@ ccic: s2mm005@33 {
 		};
 	};
 };
+
+3. USB-C connector attached to a typec port controller(ptn5110), which has
+power delivery support and enables drp.
+
+typec: ptn5110@50 {
+	...
+	usb_con: connector {
+		compatible = "usb-c-connector";
+		label = "USB-C";
+		port-type = "dual";
+		default-role = "sink";
+		src-pdos = <0x380190c8>;
+		snk-pdos = <0x380190c8 0x3802d0c8>;
+		max-snk-microvolt = <9000>;
+		max-snk-microamp = <2000>;
+		max-snk-microwatt-hours = <18000>;
+		op-snk-microwatt-hours = <9000>;
+	};
+};

[PATCH v2 11/12] dt-bindings: usb: add documentation for typec port controller(TCPCI)

[Li Jun]

TCPCI stands for typec port controller interface, its implementation
has full typec port control with power delivery support, it's a
standard i2c slave with GPIO input as irq interface, detail see spec
"Universal Serial Bus Type-C Port Controller Interface Specification
Revision 1.0, Version 1.1"

Signed-off-by: Li Jun <jun.li@nxp.com>
---
Change for v2:
- Use usb connector sub-node accordingly to specify typec properties.

 .../devicetree/bindings/usb/typec-tcpci.txt        | 35 ++++++++++++++++++++++
 1 file changed, 35 insertions(+)

diff --git a/Documentation/devicetree/bindings/usb/typec-tcpci.txt b/Documentation/devicetree/bindings/usb/typec-tcpci.txt
new file mode 100644
index 0000000..318bf01
--- /dev/null
+++ b/Documentation/devicetree/bindings/usb/typec-tcpci.txt
@@ -0,0 +1,35 @@
+TCPCI(Typec port cotroller interface) binding
+---------------------------------------------
+
+Required properties:
+- compatible:       should be "usb,tcpci".
+- reg:              the i2c slave address of typec port controller device.
+- interrupt-parent: the phandle to the interrupt controller which provides
+                    the interrupt.
+- interrupts:       interrupt specification for tcpci alert.
+
+Required sub-node:
+- connector: The "usb-c-connector" attached to the tcpci chip, the bindings
+  of connector node are specified in
+  Documentation/devicetree/bindings/connector/usb-connector.txt
+
+Example:
+
+ptn5110@50 {
+	compatible = "usb,tcpci";
+	reg = <0x50>;
+	interrupt-parent = <&gpio3>;
+	interrupts = <3 IRQ_TYPE_LEVEL_LOW>;
+
+	usb_con: connector {
+		compatible = "usb-c-connector";
+		label = "USB-C";
+		port-type = "dual";
+		default-role = "sink";
+		src-pdos = <0x380190c8>;
+		snk-pdos = <0x380190c8 0x3802d0c8>;
+		max-snk-mv = <9000>;
+		max-snk-ma = <1000>;
+		op-snk-mw = <9000>;
+	};
+};
-- 
2.7.4

[v2,11/12] dt-bindings: usb: add documentation for typec port controller(TCPCI)

[Jun Li]

TCPCI stands for typec port controller interface, its implementation
has full typec port control with power delivery support, it's a
standard i2c slave with GPIO input as irq interface, detail see spec
"Universal Serial Bus Type-C Port Controller Interface Specification
Revision 1.0, Version 1.1"

Signed-off-by: Li Jun <jun.li@nxp.com>
---
Change for v2:
- Use usb connector sub-node accordingly to specify typec properties.

 .../devicetree/bindings/usb/typec-tcpci.txt        | 35 ++++++++++++++++++++++
 1 file changed, 35 insertions(+)

diff --git a/Documentation/devicetree/bindings/usb/typec-tcpci.txt b/Documentation/devicetree/bindings/usb/typec-tcpci.txt
new file mode 100644
index 0000000..318bf01
--- /dev/null
+++ b/Documentation/devicetree/bindings/usb/typec-tcpci.txt
@@ -0,0 +1,35 @@
+TCPCI(Typec port cotroller interface) binding
+---------------------------------------------
+
+Required properties:
+- compatible:       should be "usb,tcpci".
+- reg:              the i2c slave address of typec port controller device.
+- interrupt-parent: the phandle to the interrupt controller which provides
+                    the interrupt.
+- interrupts:       interrupt specification for tcpci alert.
+
+Required sub-node:
+- connector: The "usb-c-connector" attached to the tcpci chip, the bindings
+  of connector node are specified in
+  Documentation/devicetree/bindings/connector/usb-connector.txt
+
+Example:
+
+ptn5110@50 {
+	compatible = "usb,tcpci";
+	reg = <0x50>;
+	interrupt-parent = <&gpio3>;
+	interrupts = <3 IRQ_TYPE_LEVEL_LOW>;
+
+	usb_con: connector {
+		compatible = "usb-c-connector";
+		label = "USB-C";
+		port-type = "dual";
+		default-role = "sink";
+		src-pdos = <0x380190c8>;
+		snk-pdos = <0x380190c8 0x3802d0c8>;
+		max-snk-mv = <9000>;
+		max-snk-ma = <1000>;
+		op-snk-mw = <9000>;
+	};
+};

[PATCH v2 12/12] staging: typec: tcpci: move tcpci driver out of staging

[Li Jun]

Move TCPCI(Typec port controller interface) driver out of staging.

Signed-off-by: Li Jun <jun.li@nxp.com>
---
 drivers/staging/Kconfig                |  2 --
 drivers/staging/Makefile               |  1 -
 drivers/staging/typec/Kconfig          | 14 --------------
 drivers/staging/typec/Makefile         |  1 -
 drivers/staging/typec/TODO             |  5 -----
 drivers/usb/typec/Kconfig              |  7 +++++++
 drivers/usb/typec/Makefile             |  1 +
 drivers/{staging => usb}/typec/tcpci.c |  0
 drivers/{staging => usb}/typec/tcpci.h |  0
 9 files changed, 8 insertions(+), 23 deletions(-)

diff --git a/drivers/staging/Kconfig b/drivers/staging/Kconfig
index 5546839..1e3d5d0 100644
--- a/drivers/staging/Kconfig
+++ b/drivers/staging/Kconfig
@@ -112,8 +112,6 @@ source "drivers/staging/vc04_services/Kconfig"
 
 source "drivers/staging/ccree/Kconfig"
 
-source "drivers/staging/typec/Kconfig"
-
 source "drivers/staging/vboxvideo/Kconfig"
 
 source "drivers/staging/pi433/Kconfig"
diff --git a/drivers/staging/Makefile b/drivers/staging/Makefile
index 6e53602..ba69c52 100644
--- a/drivers/staging/Makefile
+++ b/drivers/staging/Makefile
@@ -2,7 +2,6 @@
 # Makefile for staging directory
 
 obj-y				+= media/
-obj-y				+= typec/
 obj-$(CONFIG_IRDA)		+= irda/net/
 obj-$(CONFIG_IRDA)		+= irda/drivers/
 obj-$(CONFIG_PRISM2_USB)	+= wlan-ng/
diff --git a/drivers/staging/typec/Kconfig b/drivers/staging/typec/Kconfig
deleted file mode 100644
index 5359f55..0000000
--- a/drivers/staging/typec/Kconfig
+++ /dev/null
@@ -1,14 +0,0 @@
-menu "USB Power Delivery and Type-C drivers"
-
-if TYPEC_TCPM
-
-config TYPEC_TCPCI
-	tristate "Type-C Port Controller Interface driver"
-	depends on I2C
-	select REGMAP_I2C
-	help
-	  Type-C Port Controller driver for TCPCI-compliant controller.
-
-endif
-
-endmenu
diff --git a/drivers/staging/typec/Makefile b/drivers/staging/typec/Makefile
deleted file mode 100644
index 53d649a..0000000
--- a/drivers/staging/typec/Makefile
+++ /dev/null
@@ -1 +0,0 @@
-obj-$(CONFIG_TYPEC_TCPCI)	+= tcpci.o
diff --git a/drivers/staging/typec/TODO b/drivers/staging/typec/TODO
deleted file mode 100644
index 53fe2f7..0000000
--- a/drivers/staging/typec/TODO
+++ /dev/null
@@ -1,5 +0,0 @@
-tcpci:
-- Test with real hardware
-
-Please send patches to Guenter Roeck <linux@roeck-us.net> and copy
-Heikki Krogerus <heikki.krogerus@linux.intel.com>.
diff --git a/drivers/usb/typec/Kconfig b/drivers/usb/typec/Kconfig
index bcb2744..711f7ee 100644
--- a/drivers/usb/typec/Kconfig
+++ b/drivers/usb/typec/Kconfig
@@ -54,6 +54,13 @@ config TYPEC_TCPM
 
 if TYPEC_TCPM
 
+config TYPEC_TCPCI
+	tristate "Type-C Port Controller Interface driver"
+	depends on I2C
+	select REGMAP_I2C
+	help
+	  Type-C Port Controller driver for TCPCI-compliant controller.
+
 source "drivers/usb/typec/fusb302/Kconfig"
 
 config TYPEC_WCOVE
diff --git a/drivers/usb/typec/Makefile b/drivers/usb/typec/Makefile
index bb3138a..59c88b4 100644
--- a/drivers/usb/typec/Makefile
+++ b/drivers/usb/typec/Makefile
@@ -5,3 +5,4 @@ obj-y				+= fusb302/
 obj-$(CONFIG_TYPEC_WCOVE)	+= typec_wcove.o
 obj-$(CONFIG_TYPEC_UCSI)	+= ucsi/
 obj-$(CONFIG_TYPEC_TPS6598X)	+= tps6598x.o
+obj-$(CONFIG_TYPEC_TCPCI)	+= tcpci.o
diff --git a/drivers/staging/typec/tcpci.c b/drivers/usb/typec/tcpci.c
similarity index 100%
rename from drivers/staging/typec/tcpci.c
rename to drivers/usb/typec/tcpci.c
diff --git a/drivers/staging/typec/tcpci.h b/drivers/usb/typec/tcpci.h
similarity index 100%
rename from drivers/staging/typec/tcpci.h
rename to drivers/usb/typec/tcpci.h
-- 
2.7.4

[v2,12/12] staging: typec: tcpci: move tcpci driver out of staging

[Jun Li]

Move TCPCI(Typec port controller interface) driver out of staging.

Signed-off-by: Li Jun <jun.li@nxp.com>
---
 drivers/staging/Kconfig                |  2 --
 drivers/staging/Makefile               |  1 -
 drivers/staging/typec/Kconfig          | 14 --------------
 drivers/staging/typec/Makefile         |  1 -
 drivers/staging/typec/TODO             |  5 -----
 drivers/usb/typec/Kconfig              |  7 +++++++
 drivers/usb/typec/Makefile             |  1 +
 drivers/{staging => usb}/typec/tcpci.c |  0
 drivers/{staging => usb}/typec/tcpci.h |  0
 9 files changed, 8 insertions(+), 23 deletions(-)

diff --git a/drivers/staging/Kconfig b/drivers/staging/Kconfig
index 5546839..1e3d5d0 100644
--- a/drivers/staging/Kconfig
+++ b/drivers/staging/Kconfig
@@ -112,8 +112,6 @@ source "drivers/staging/vc04_services/Kconfig"
 
 source "drivers/staging/ccree/Kconfig"
 
-source "drivers/staging/typec/Kconfig"
-
 source "drivers/staging/vboxvideo/Kconfig"
 
 source "drivers/staging/pi433/Kconfig"
diff --git a/drivers/staging/Makefile b/drivers/staging/Makefile
index 6e53602..ba69c52 100644
--- a/drivers/staging/Makefile
+++ b/drivers/staging/Makefile
@@ -2,7 +2,6 @@
 # Makefile for staging directory
 
 obj-y				+= media/
-obj-y				+= typec/
 obj-$(CONFIG_IRDA)		+= irda/net/
 obj-$(CONFIG_IRDA)		+= irda/drivers/
 obj-$(CONFIG_PRISM2_USB)	+= wlan-ng/
diff --git a/drivers/staging/typec/Kconfig b/drivers/staging/typec/Kconfig
deleted file mode 100644
index 5359f55..0000000
--- a/drivers/staging/typec/Kconfig
+++ /dev/null
@@ -1,14 +0,0 @@
-menu "USB Power Delivery and Type-C drivers"
-
-if TYPEC_TCPM
-
-config TYPEC_TCPCI
-	tristate "Type-C Port Controller Interface driver"
-	depends on I2C
-	select REGMAP_I2C
-	help
-	  Type-C Port Controller driver for TCPCI-compliant controller.
-
-endif
-
-endmenu
diff --git a/drivers/staging/typec/Makefile b/drivers/staging/typec/Makefile
deleted file mode 100644
index 53d649a..0000000
--- a/drivers/staging/typec/Makefile
+++ /dev/null
@@ -1 +0,0 @@
-obj-$(CONFIG_TYPEC_TCPCI)	+= tcpci.o
diff --git a/drivers/staging/typec/TODO b/drivers/staging/typec/TODO
deleted file mode 100644
index 53fe2f7..0000000
--- a/drivers/staging/typec/TODO
+++ /dev/null
@@ -1,5 +0,0 @@
-tcpci:
-- Test with real hardware
-
-Please send patches to Guenter Roeck <linux@roeck-us.net> and copy
-Heikki Krogerus <heikki.krogerus@linux.intel.com>.
diff --git a/drivers/usb/typec/Kconfig b/drivers/usb/typec/Kconfig
index bcb2744..711f7ee 100644
--- a/drivers/usb/typec/Kconfig
+++ b/drivers/usb/typec/Kconfig
@@ -54,6 +54,13 @@ config TYPEC_TCPM
 
 if TYPEC_TCPM
 
+config TYPEC_TCPCI
+	tristate "Type-C Port Controller Interface driver"
+	depends on I2C
+	select REGMAP_I2C
+	help
+	  Type-C Port Controller driver for TCPCI-compliant controller.
+
 source "drivers/usb/typec/fusb302/Kconfig"
 
 config TYPEC_WCOVE
diff --git a/drivers/usb/typec/Makefile b/drivers/usb/typec/Makefile
index bb3138a..59c88b4 100644
--- a/drivers/usb/typec/Makefile
+++ b/drivers/usb/typec/Makefile
@@ -5,3 +5,4 @@ obj-y				+= fusb302/
 obj-$(CONFIG_TYPEC_WCOVE)	+= typec_wcove.o
 obj-$(CONFIG_TYPEC_UCSI)	+= ucsi/
 obj-$(CONFIG_TYPEC_TPS6598X)	+= tps6598x.o
+obj-$(CONFIG_TYPEC_TCPCI)	+= tcpci.o
diff --git a/drivers/staging/typec/tcpci.c b/drivers/usb/typec/tcpci.c
similarity index 100%
rename from drivers/staging/typec/tcpci.c
rename to drivers/usb/typec/tcpci.c
diff --git a/drivers/staging/typec/tcpci.h b/drivers/usb/typec/tcpci.h
similarity index 100%
rename from drivers/staging/typec/tcpci.h
rename to drivers/usb/typec/tcpci.h

Re: [PATCH v2 01/12] usb: typec: add API to get port type and preferred role

[Heikki Krogerus]

On Mon, Feb 26, 2018 at 07:49:08PM +0800, Li Jun wrote:
> This patch add 2 APIs to get port type and preferred role from firmware
> description.
> 
> Signed-off-by: Li Jun <jun.li@nxp.com>
> 
> ---
> change for v2
> - Change the 2 APIs name and input para to be device_node pointer.

Why?

You are only dealing with device properties here, so please move back
to using the unified device property API.

>  drivers/usb/typec/typec.c | 46 ++++++++++++++++++++++++++++++++++++++++++++++
>  include/linux/usb/typec.h |  2 ++
>  2 files changed, 48 insertions(+)
> 
> diff --git a/drivers/usb/typec/typec.c b/drivers/usb/typec/typec.c
> index 735726c..e7b2802 100644
> --- a/drivers/usb/typec/typec.c
> +++ b/drivers/usb/typec/typec.c
> @@ -9,6 +9,7 @@
>  #include <linux/device.h>
>  #include <linux/module.h>
>  #include <linux/mutex.h>
> +#include <linux/of.h>

No need for that.

>  #include <linux/slab.h>
>  #include <linux/usb/typec.h>
>  
> @@ -1246,6 +1247,51 @@ void typec_set_pwr_opmode(struct typec_port *port,
>  }
>  EXPORT_SYMBOL_GPL(typec_set_pwr_opmode);
>  
> +/**
> + * typec_of_get_port_type - Get the typec port type
> + * @np: device node from which the property value is to be read.
> + *
> + * This routine is used by typec hardware driver to read property port type
> + * from the device firmware description.
> + *
> + * Returns typec_port_type if success, otherwise negative error code.
> + */
> +int typec_of_get_port_type(struct device_node *np)

int typec_get_port_type(struct device *dev)

I would expect you to have the function like that even if you really
were calling of_* functions in it so we would not need to change the
API later once support for ACPI or some other type of FW interface is
added. But as said, that will not be the case, and you need to use
device_property_* functions instead.

> +{
> +	const char *type_str;
> +	int ret;
> +
> +	ret = of_property_read_string(np, "port-type", &type_str);

ret = device_property_read_string(dev, "port-type", &type_str);

> +	if (ret < 0)
> +		return ret;
> +
> +	return match_string(typec_port_types, ARRAY_SIZE(typec_port_types),
> +								 type_str);
> +}
> +EXPORT_SYMBOL_GPL(typec_get_port_type);

Note that you are still exporting the old function name, but that's
fine. Just change the function name back to the original.

> +/**
> + * typec_of_get_preferred_role - Get the typec preferred role
> + * @np: device node from which the property value is to be read.
> + *
> + * This routine is used by typec hardware driver to read property default role
> + * from the device firmware description.
> + *
> + * Returns typec_role if success, otherwise negative error code.
> + */
> +int typec_of_get_preferred_role(struct device_node *np)

int typec_get_preferred_role(struct device dev)

> +{
> +	const char *power_str;
> +	int ret;
> +
> +	ret = of_property_read_string(np, "default-role", &power_str);

ret = device_property_read_string(dev, "default-role", &type_str);

> +	if (ret < 0)
> +		return ret;
> +
> +	return match_string(typec_roles, ARRAY_SIZE(typec_roles), power_str);
> +}
> +EXPORT_SYMBOL_GPL(typec_get_preferred_role);
> +
>  /* --------------------------------------- */

Thanks,

-- 
heikki

[v2,01/12] usb: typec: add API to get port type and preferred role

[Heikki Krogerus]

On Mon, Feb 26, 2018 at 07:49:08PM +0800, Li Jun wrote:
> This patch add 2 APIs to get port type and preferred role from firmware
> description.
> 
> Signed-off-by: Li Jun <jun.li@nxp.com>
> 
> ---
> change for v2
> - Change the 2 APIs name and input para to be device_node pointer.

Why?

You are only dealing with device properties here, so please move back
to using the unified device property API.

>  drivers/usb/typec/typec.c | 46 ++++++++++++++++++++++++++++++++++++++++++++++
>  include/linux/usb/typec.h |  2 ++
>  2 files changed, 48 insertions(+)
> 
> diff --git a/drivers/usb/typec/typec.c b/drivers/usb/typec/typec.c
> index 735726c..e7b2802 100644
> --- a/drivers/usb/typec/typec.c
> +++ b/drivers/usb/typec/typec.c
> @@ -9,6 +9,7 @@
>  #include <linux/device.h>
>  #include <linux/module.h>
>  #include <linux/mutex.h>
> +#include <linux/of.h>

No need for that.

>  #include <linux/slab.h>
>  #include <linux/usb/typec.h>
>  
> @@ -1246,6 +1247,51 @@ void typec_set_pwr_opmode(struct typec_port *port,
>  }
>  EXPORT_SYMBOL_GPL(typec_set_pwr_opmode);
>  
> +/**
> + * typec_of_get_port_type - Get the typec port type
> + * @np: device node from which the property value is to be read.
> + *
> + * This routine is used by typec hardware driver to read property port type
> + * from the device firmware description.
> + *
> + * Returns typec_port_type if success, otherwise negative error code.
> + */
> +int typec_of_get_port_type(struct device_node *np)

int typec_get_port_type(struct device *dev)

I would expect you to have the function like that even if you really
were calling of_* functions in it so we would not need to change the
API later once support for ACPI or some other type of FW interface is
added. But as said, that will not be the case, and you need to use
device_property_* functions instead.

> +{
> +	const char *type_str;
> +	int ret;
> +
> +	ret = of_property_read_string(np, "port-type", &type_str);

ret = device_property_read_string(dev, "port-type", &type_str);

> +	if (ret < 0)
> +		return ret;
> +
> +	return match_string(typec_port_types, ARRAY_SIZE(typec_port_types),
> +								 type_str);
> +}
> +EXPORT_SYMBOL_GPL(typec_get_port_type);

Note that you are still exporting the old function name, but that's
fine. Just change the function name back to the original.

> +/**
> + * typec_of_get_preferred_role - Get the typec preferred role
> + * @np: device node from which the property value is to be read.
> + *
> + * This routine is used by typec hardware driver to read property default role
> + * from the device firmware description.
> + *
> + * Returns typec_role if success, otherwise negative error code.
> + */
> +int typec_of_get_preferred_role(struct device_node *np)

int typec_get_preferred_role(struct device dev)

> +{
> +	const char *power_str;
> +	int ret;
> +
> +	ret = of_property_read_string(np, "default-role", &power_str);

ret = device_property_read_string(dev, "default-role", &type_str);

> +	if (ret < 0)
> +		return ret;
> +
> +	return match_string(typec_roles, ARRAY_SIZE(typec_roles), power_str);
> +}
> +EXPORT_SYMBOL_GPL(typec_get_preferred_role);
> +
>  /* --------------------------------------- */

Thanks,

Re: [PATCH v2 02/12] usb: typec: add API to get sink and source config

[Heikki Krogerus]

Hi,

On Mon, Feb 26, 2018 at 07:49:09PM +0800, Li Jun wrote:
> This patch add 2 APIs to get sink and source power config from firmware
> description.
> 
> Signed-off-by: Li Jun <jun.li@nxp.com>
> ---
>  drivers/usb/typec/tcpm.c | 43 +++++++++++++++++++++++++++++++++++++++++++
>  include/linux/usb/tcpm.h |  2 ++
>  2 files changed, 45 insertions(+)
> 
> diff --git a/drivers/usb/typec/tcpm.c b/drivers/usb/typec/tcpm.c
> index f4d563e..409f1d0 100644
> --- a/drivers/usb/typec/tcpm.c
> +++ b/drivers/usb/typec/tcpm.c
> @@ -12,6 +12,7 @@
>  #include <linux/kernel.h>
>  #include <linux/module.h>
>  #include <linux/mutex.h>
> +#include <linux/of.h>

No need for that. There is nothing DT only specific here.

As in 01/12, you only have device properties here, so use the unified
device property API instead of of_property_* functions.

>  #include <linux/proc_fs.h>
>  #include <linux/sched/clock.h>
>  #include <linux/seq_file.h>
> @@ -3589,6 +3590,48 @@ static int tcpm_copy_vdos(u32 *dest_vdo, const u32 *src_vdo,
>  	return nr_vdo;
>  }
>  
> +int tcpm_of_get_src_config(struct device_node *np, struct tcpc_config *tcfg)
> +{
> +	int ret;
> +
> +	ret = of_property_read_variable_u32_array(np, "src-pdos",
> +				tcfg->src_pdo, 1, PDO_MAX_OBJECTS);
> +	if (ret > 0)
> +		tcfg->nr_src_pdo = ret;
> +
> +	return ret;
> +}
> +EXPORT_SYMBOL_GPL(tcpm_of_get_pdos);
> +
> +int tcpm_of_get_snk_config(struct device_node *np, struct tcpc_config *tcfg)
> +{
> +	int ret;
> +
> +	ret = of_property_read_variable_u32_array(np, "snk-pdos",
> +				tcfg->snk_pdo, 1, PDO_MAX_OBJECTS);
> +	if (ret > 0)
> +		tcfg->nr_snk_pdo = ret;
> +	else
> +		return ret;
> +
> +	ret = of_property_read_u32(np, "max-snk-microvolt", &tcfg->max_snk_mv);
> +	if (ret)
> +		return ret;
> +
> +	ret = of_property_read_u32(np, "max-snk-microamp", &tcfg->max_snk_ma);
> +	if (ret)
> +		return ret;
> +
> +	ret = of_property_read_u32(np, "max-snk-microwatt-hours",
> +				   &tcfg->max_snk_mw);
> +	if (ret)
> +		return ret;
> +
> +	return of_property_read_u32(np, "op-snk-microwatt-hours",
> +				    &tcfg->operating_snk_mw);
> +}
> +EXPORT_SYMBOL_GPL(tcpm_of_get_pdos);
> +
>  int tcpm_update_source_capabilities(struct tcpm_port *port, const u32 *pdo,
>  				    unsigned int nr_pdo)
>  {
> diff --git a/include/linux/usb/tcpm.h b/include/linux/usb/tcpm.h
> index ca1c0b5..962eff1 100644
> --- a/include/linux/usb/tcpm.h
> +++ b/include/linux/usb/tcpm.h
> @@ -191,6 +191,8 @@ int tcpm_update_sink_capabilities(struct tcpm_port *port, const u32 *pdo,
>  				  unsigned int max_snk_ma,
>  				  unsigned int max_snk_mw,
>  				  unsigned int operating_snk_mw);
> +int tcpm_of_get_src_config(struct device_node *np, struct tcpc_config *tcfg);
> +int tcpm_of_get_snk_config(struct device_node *np, struct tcpc_config *tcfg);
>  
>  void tcpm_vbus_change(struct tcpm_port *port);
>  void tcpm_cc_change(struct tcpm_port *port);

Thanks,

-- 
heikki

[v2,02/12] usb: typec: add API to get sink and source config

[Heikki Krogerus]

Hi,

On Mon, Feb 26, 2018 at 07:49:09PM +0800, Li Jun wrote:
> This patch add 2 APIs to get sink and source power config from firmware
> description.
> 
> Signed-off-by: Li Jun <jun.li@nxp.com>
> ---
>  drivers/usb/typec/tcpm.c | 43 +++++++++++++++++++++++++++++++++++++++++++
>  include/linux/usb/tcpm.h |  2 ++
>  2 files changed, 45 insertions(+)
> 
> diff --git a/drivers/usb/typec/tcpm.c b/drivers/usb/typec/tcpm.c
> index f4d563e..409f1d0 100644
> --- a/drivers/usb/typec/tcpm.c
> +++ b/drivers/usb/typec/tcpm.c
> @@ -12,6 +12,7 @@
>  #include <linux/kernel.h>
>  #include <linux/module.h>
>  #include <linux/mutex.h>
> +#include <linux/of.h>

No need for that. There is nothing DT only specific here.

As in 01/12, you only have device properties here, so use the unified
device property API instead of of_property_* functions.

>  #include <linux/proc_fs.h>
>  #include <linux/sched/clock.h>
>  #include <linux/seq_file.h>
> @@ -3589,6 +3590,48 @@ static int tcpm_copy_vdos(u32 *dest_vdo, const u32 *src_vdo,
>  	return nr_vdo;
>  }
>  
> +int tcpm_of_get_src_config(struct device_node *np, struct tcpc_config *tcfg)
> +{
> +	int ret;
> +
> +	ret = of_property_read_variable_u32_array(np, "src-pdos",
> +				tcfg->src_pdo, 1, PDO_MAX_OBJECTS);
> +	if (ret > 0)
> +		tcfg->nr_src_pdo = ret;
> +
> +	return ret;
> +}
> +EXPORT_SYMBOL_GPL(tcpm_of_get_pdos);
> +
> +int tcpm_of_get_snk_config(struct device_node *np, struct tcpc_config *tcfg)
> +{
> +	int ret;
> +
> +	ret = of_property_read_variable_u32_array(np, "snk-pdos",
> +				tcfg->snk_pdo, 1, PDO_MAX_OBJECTS);
> +	if (ret > 0)
> +		tcfg->nr_snk_pdo = ret;
> +	else
> +		return ret;
> +
> +	ret = of_property_read_u32(np, "max-snk-microvolt", &tcfg->max_snk_mv);
> +	if (ret)
> +		return ret;
> +
> +	ret = of_property_read_u32(np, "max-snk-microamp", &tcfg->max_snk_ma);
> +	if (ret)
> +		return ret;
> +
> +	ret = of_property_read_u32(np, "max-snk-microwatt-hours",
> +				   &tcfg->max_snk_mw);
> +	if (ret)
> +		return ret;
> +
> +	return of_property_read_u32(np, "op-snk-microwatt-hours",
> +				    &tcfg->operating_snk_mw);
> +}
> +EXPORT_SYMBOL_GPL(tcpm_of_get_pdos);
> +
>  int tcpm_update_source_capabilities(struct tcpm_port *port, const u32 *pdo,
>  				    unsigned int nr_pdo)
>  {
> diff --git a/include/linux/usb/tcpm.h b/include/linux/usb/tcpm.h
> index ca1c0b5..962eff1 100644
> --- a/include/linux/usb/tcpm.h
> +++ b/include/linux/usb/tcpm.h
> @@ -191,6 +191,8 @@ int tcpm_update_sink_capabilities(struct tcpm_port *port, const u32 *pdo,
>  				  unsigned int max_snk_ma,
>  				  unsigned int max_snk_mw,
>  				  unsigned int operating_snk_mw);
> +int tcpm_of_get_src_config(struct device_node *np, struct tcpc_config *tcfg);
> +int tcpm_of_get_snk_config(struct device_node *np, struct tcpc_config *tcfg);
>  
>  void tcpm_vbus_change(struct tcpm_port *port);
>  void tcpm_cc_change(struct tcpm_port *port);

Thanks,

Re: [PATCH v2 03/12] staging: typec: tcpci: support port config passed via dt

[Heikki Krogerus]

Hi,

On Mon, Feb 26, 2018 at 07:49:10PM +0800, Li Jun wrote:
> User can define the typec port properties in tcpci node to setup
> the port config.
> 
> Signed-off-by: Li Jun <jun.li@nxp.com>
> ---
> Changes for v2:
> - Use infra APIs to get sink and source config.
> - Improve the error message.
> 
>  drivers/staging/typec/tcpci.c | 70 ++++++++++++++++++++++++++++++++++++++-----
>  include/linux/usb/tcpm.h      |  6 ++--
>  2 files changed, 66 insertions(+), 10 deletions(-)
> 
> diff --git a/drivers/staging/typec/tcpci.c b/drivers/staging/typec/tcpci.c
> index b6abaf7..be6ed16 100644
> --- a/drivers/staging/typec/tcpci.c
> +++ b/drivers/staging/typec/tcpci.c
> @@ -426,17 +426,73 @@ static const struct regmap_config tcpci_regmap_config = {
>  	.max_register = 0x7F, /* 0x80 .. 0xFF are vendor defined */
>  };
>  
> -static const struct tcpc_config tcpci_tcpc_config = {
> -	.type = TYPEC_PORT_DFP,
> -	.default_role = TYPEC_SINK,
> -};
> -
> +/* Populate struct tcpc_config from device-tree */
>  static int tcpci_parse_config(struct tcpci *tcpci)
>  {
> +	struct tcpc_config *tcfg;
> +	struct device_node *child;
> +	int ret = -EINVAL;
> +
>  	tcpci->controls_vbus = true; /* XXX */
>  
> -	/* TODO: Populate struct tcpc_config from ACPI/device-tree */
> -	tcpci->tcpc.config = &tcpci_tcpc_config;
> +	tcpci->tcpc.config = devm_kzalloc(tcpci->dev, sizeof(*tcfg),
> +					  GFP_KERNEL);
> +	if (!tcpci->tcpc.config)
> +		return -ENOMEM;
> +
> +	tcfg = tcpci->tcpc.config;
> +
> +	child = of_get_child_by_name(tcpci->dev->of_node, "connector");
> +	if (!child) {
> +		dev_err(tcpci->dev, "failed to get connector node.\n");
> +		return -EINVAL;
> +	}

Why do you need separate child node for the connector? You will always
have only one connector per tcpc, i.e. the tcpci already represents the
connector and all its capabilities.


Thanks,

-- 
heikki

[v2,03/12] staging: typec: tcpci: support port config passed via dt

[Heikki Krogerus]

Hi,

On Mon, Feb 26, 2018 at 07:49:10PM +0800, Li Jun wrote:
> User can define the typec port properties in tcpci node to setup
> the port config.
> 
> Signed-off-by: Li Jun <jun.li@nxp.com>
> ---
> Changes for v2:
> - Use infra APIs to get sink and source config.
> - Improve the error message.
> 
>  drivers/staging/typec/tcpci.c | 70 ++++++++++++++++++++++++++++++++++++++-----
>  include/linux/usb/tcpm.h      |  6 ++--
>  2 files changed, 66 insertions(+), 10 deletions(-)
> 
> diff --git a/drivers/staging/typec/tcpci.c b/drivers/staging/typec/tcpci.c
> index b6abaf7..be6ed16 100644
> --- a/drivers/staging/typec/tcpci.c
> +++ b/drivers/staging/typec/tcpci.c
> @@ -426,17 +426,73 @@ static const struct regmap_config tcpci_regmap_config = {
>  	.max_register = 0x7F, /* 0x80 .. 0xFF are vendor defined */
>  };
>  
> -static const struct tcpc_config tcpci_tcpc_config = {
> -	.type = TYPEC_PORT_DFP,
> -	.default_role = TYPEC_SINK,
> -};
> -
> +/* Populate struct tcpc_config from device-tree */
>  static int tcpci_parse_config(struct tcpci *tcpci)
>  {
> +	struct tcpc_config *tcfg;
> +	struct device_node *child;
> +	int ret = -EINVAL;
> +
>  	tcpci->controls_vbus = true; /* XXX */
>  
> -	/* TODO: Populate struct tcpc_config from ACPI/device-tree */
> -	tcpci->tcpc.config = &tcpci_tcpc_config;
> +	tcpci->tcpc.config = devm_kzalloc(tcpci->dev, sizeof(*tcfg),
> +					  GFP_KERNEL);
> +	if (!tcpci->tcpc.config)
> +		return -ENOMEM;
> +
> +	tcfg = tcpci->tcpc.config;
> +
> +	child = of_get_child_by_name(tcpci->dev->of_node, "connector");
> +	if (!child) {
> +		dev_err(tcpci->dev, "failed to get connector node.\n");
> +		return -EINVAL;
> +	}

Why do you need separate child node for the connector? You will always
have only one connector per tcpc, i.e. the tcpci already represents the
connector and all its capabilities.


Thanks,

RE: [PATCH v2 03/12] staging: typec: tcpci: support port config passed via dt

[Jun Li]

Hi
> -----Original Message-----
> From: linux-usb-owner@vger.kernel.org
> [mailto:linux-usb-owner@vger.kernel.org] On Behalf Of Heikki Krogerus
> Sent: 2018年2月26日 22:06
> To: Jun Li <jun.li@nxp.com>
> Cc: gregkh@linuxfoundation.org; robh+dt@kernel.org; linux@roeck-us.net;
> a.hajda@samsung.com; mark.rutland@arm.com; yueyao@google.com;
> Peter Chen <peter.chen@nxp.com>; garsilva@embeddedor.com;
> o_leveque@orange.fr; shufan_lee@richtek.com; linux-usb@vger.kernel.org;
> devicetree@vger.kernel.org; dl-linux-imx <linux-imx@nxp.com>
> Subject: Re: [PATCH v2 03/12] staging: typec: tcpci: support port config
> passed via dt
> 
> Hi,
> 
> On Mon, Feb 26, 2018 at 07:49:10PM +0800, Li Jun wrote:
> > User can define the typec port properties in tcpci node to setup the
> > port config.
> >
> > Signed-off-by: Li Jun <jun.li@nxp.com>
> > ---
> > Changes for v2:
> > - Use infra APIs to get sink and source config.
> > - Improve the error message.
> >
> >  drivers/staging/typec/tcpci.c | 70
> ++++++++++++++++++++++++++++++++++++++-----
> >  include/linux/usb/tcpm.h      |  6 ++--
> >  2 files changed, 66 insertions(+), 10 deletions(-)
> >
> > diff --git a/drivers/staging/typec/tcpci.c
> > b/drivers/staging/typec/tcpci.c index b6abaf7..be6ed16 100644
> > --- a/drivers/staging/typec/tcpci.c
> > +++ b/drivers/staging/typec/tcpci.c
> > @@ -426,17 +426,73 @@ static const struct regmap_config
> tcpci_regmap_config = {
> >  	.max_register = 0x7F, /* 0x80 .. 0xFF are vendor defined */  };
> >
> > -static const struct tcpc_config tcpci_tcpc_config = {
> > -	.type = TYPEC_PORT_DFP,
> > -	.default_role = TYPEC_SINK,
> > -};
> > -
> > +/* Populate struct tcpc_config from device-tree */
> >  static int tcpci_parse_config(struct tcpci *tcpci)  {
> > +	struct tcpc_config *tcfg;
> > +	struct device_node *child;
> > +	int ret = -EINVAL;
> > +
> >  	tcpci->controls_vbus = true; /* XXX */
> >
> > -	/* TODO: Populate struct tcpc_config from ACPI/device-tree */
> > -	tcpci->tcpc.config = &tcpci_tcpc_config;
> > +	tcpci->tcpc.config = devm_kzalloc(tcpci->dev, sizeof(*tcfg),
> > +					  GFP_KERNEL);
> > +	if (!tcpci->tcpc.config)
> > +		return -ENOMEM;
> > +
> > +	tcfg = tcpci->tcpc.config;
> > +
> > +	child = of_get_child_by_name(tcpci->dev->of_node, "connector");
> > +	if (!child) {
> > +		dev_err(tcpci->dev, "failed to get connector node.\n");
> > +		return -EINVAL;
> > +	}
> 
> Why do you need separate child node for the connector? You will always
> have only one connector per tcpc, i.e. the tcpci already represents the
> connector and all its capabilities.
> 
This is my original idea, my understanding is Rob expects those properties should
apply for a common usb connector node[1], that way I need add a child node for it,
sorry I didn't make the dt-binding patches come first in this series, please see
patch 10,11.

[1] https://patchwork.kernel.org/patch/10231447/

thanks
Li Jun
> 
> 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
> https://emea01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fvger
> .kernel.org%2Fmajordomo-info.html&data=02%7C01%7Cjun.li%40nxp.com
> %7Ce39f8cdcff664858d9ea08d57d221b7a%7C686ea1d3bc2b4c6fa92cd99c5
> c301635%7C0%7C1%7C636552507819862496&sdata=SgStkXiqwV7RIfXcReB
> vIZpOyLEXKNhvH%2FB6p4KXxsA%3D&reserved=0

[v2,03/12] staging: typec: tcpci: support port config passed via dt

[Jun Li]

Hi
> -----Original Message-----
> From: linux-usb-owner@vger.kernel.org
> [mailto:linux-usb-owner@vger.kernel.org] On Behalf Of Heikki Krogerus
> Sent: 2018年2月26日 22:06
> To: Jun Li <jun.li@nxp.com>
> Cc: gregkh@linuxfoundation.org; robh+dt@kernel.org; linux@roeck-us.net;
> a.hajda@samsung.com; mark.rutland@arm.com; yueyao@google.com;
> Peter Chen <peter.chen@nxp.com>; garsilva@embeddedor.com;
> o_leveque@orange.fr; shufan_lee@richtek.com; linux-usb@vger.kernel.org;
> devicetree@vger.kernel.org; dl-linux-imx <linux-imx@nxp.com>
> Subject: Re: [PATCH v2 03/12] staging: typec: tcpci: support port config
> passed via dt
> 
> Hi,
> 
> On Mon, Feb 26, 2018 at 07:49:10PM +0800, Li Jun wrote:
> > User can define the typec port properties in tcpci node to setup the
> > port config.
> >
> > Signed-off-by: Li Jun <jun.li@nxp.com>
> > ---
> > Changes for v2:
> > - Use infra APIs to get sink and source config.
> > - Improve the error message.
> >
> >  drivers/staging/typec/tcpci.c | 70
> ++++++++++++++++++++++++++++++++++++++-----
> >  include/linux/usb/tcpm.h      |  6 ++--
> >  2 files changed, 66 insertions(+), 10 deletions(-)
> >
> > diff --git a/drivers/staging/typec/tcpci.c
> > b/drivers/staging/typec/tcpci.c index b6abaf7..be6ed16 100644
> > --- a/drivers/staging/typec/tcpci.c
> > +++ b/drivers/staging/typec/tcpci.c
> > @@ -426,17 +426,73 @@ static const struct regmap_config
> tcpci_regmap_config = {
> >  	.max_register = 0x7F, /* 0x80 .. 0xFF are vendor defined */  };
> >
> > -static const struct tcpc_config tcpci_tcpc_config = {
> > -	.type = TYPEC_PORT_DFP,
> > -	.default_role = TYPEC_SINK,
> > -};
> > -
> > +/* Populate struct tcpc_config from device-tree */
> >  static int tcpci_parse_config(struct tcpci *tcpci)  {
> > +	struct tcpc_config *tcfg;
> > +	struct device_node *child;
> > +	int ret = -EINVAL;
> > +
> >  	tcpci->controls_vbus = true; /* XXX */
> >
> > -	/* TODO: Populate struct tcpc_config from ACPI/device-tree */
> > -	tcpci->tcpc.config = &tcpci_tcpc_config;
> > +	tcpci->tcpc.config = devm_kzalloc(tcpci->dev, sizeof(*tcfg),
> > +					  GFP_KERNEL);
> > +	if (!tcpci->tcpc.config)
> > +		return -ENOMEM;
> > +
> > +	tcfg = tcpci->tcpc.config;
> > +
> > +	child = of_get_child_by_name(tcpci->dev->of_node, "connector");
> > +	if (!child) {
> > +		dev_err(tcpci->dev, "failed to get connector node.\n");
> > +		return -EINVAL;
> > +	}
> 
> Why do you need separate child node for the connector? You will always
> have only one connector per tcpc, i.e. the tcpci already represents the
> connector and all its capabilities.
> 
This is my original idea, my understanding is Rob expects those properties should
apply for a common usb connector node[1], that way I need add a child node for it,
sorry I didn't make the dt-binding patches come first in this series, please see
patch 10,11.

[1] https://patchwork.kernel.org/patch/10231447/

thanks
Li Jun
> 
> 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
> https://emea01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fvger
> .kernel.org%2Fmajordomo-info.html&data=02%7C01%7Cjun.li%40nxp.com
> %7Ce39f8cdcff664858d9ea08d57d221b7a%7C686ea1d3bc2b4c6fa92cd99c5
> c301635%7C0%7C1%7C636552507819862496&sdata=SgStkXiqwV7RIfXcReB
> vIZpOyLEXKNhvH%2FB6p4KXxsA%3D&reserved=0

Re: [PATCH v2 10/12] dt-bindings: connector: add properties for typec power delivery

[Andrzej Hajda]

On 26.02.2018 12:49, Li Jun wrote:
> In case of usb-c-connector with power delivery support, add bingdings
> supported by current typec driver, so user can pass all those properties
> via dt.
>
> Signed-off-by: Li Jun <jun.li@nxp.com>
> ---
> Changes for v2:
> - Added typec properties are based on general usb connector bindings[1]
>   proposed by Andrzej Hajda.
> - Use the standard unit suffixes as defined in property-units.txt.
>
> [1] https://patchwork.kernel.org/patch/10231447/
>
>  .../bindings/connector/usb-connector.txt           | 43 ++++++++++++++++++++++
>  1 file changed, 43 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/connector/usb-connector.txt b/Documentation/devicetree/bindings/connector/usb-connector.txt
> index e1463f1..242f6df 100644
> --- a/Documentation/devicetree/bindings/connector/usb-connector.txt
> +++ b/Documentation/devicetree/bindings/connector/usb-connector.txt
> @@ -15,6 +15,30 @@ Optional properties:
>  - type: size of the connector, should be specified in case of USB-A, USB-B
>    non-fullsize connectors: "mini", "micro".
>  
> +Required properties for usb-c-connector with power delivery support:
> +- port-type: should be one of "source", "sink" or "dual".
> +- default-role: preferred power role if port-type is "dual"(drp), should be
> +  "sink" or "source".

Since port carries data and power, it would be better to explicitly
mention it in names of properties which can be ambiguous.
Maybe instead of 'port-type' you can use 'power-role', for example.
Other thing is that default-role is required only in case of DRP, so
maybe better would be to squash it in power-role, for example:
    power-role: should be on of "source", "sink", "dual-source",
"dual-sink", in case of dual roles suffix determines preferred role.


> +- src-pdos: An array of u32 with each entry providing supported power
> +  source data object(PDO), the detailed bit definitions of PDO can be found
> +  in "Universal Serial Bus Power Delivery Specification" chapter 6.4.1.2
> +  Source_Capabilities Message, the order of each entry(PDO) should follow
> +  the PD spec chapter 6.4.1. Required for power source and power dual role.
> +- snk-pdos: An array of u32 with each entry providing supported power
> +  sink data object(PDO), the detailed bit definitions of PDO can be found in
> +  "Universal Serial Bus Power Delivery Specification" chapter 6.4.1.3 Sink
> +  Capabilities Message, the order of each entry(PDO) should follow the PD
> +  spec chapter 6.4.1. Required for power sink and power dual role.

We should avoid magic numbers, magic numbers are bad :)
If we really need to use PDOs here, I think we can re-use PDO_* macros
[1] - DTC should be able to parse it, maybe some lifting will be necessary.

[1]:
https://elixir.bootlin.com/linux/v4.16-rc3/source/include/linux/usb/pd.h#L161
> +- max-snk-microvolt: The max voltage the sink can support in micro volts,
> +  required for power sink and power dual role.
> +- max-snk-microamp: The max current the sink can support in micro amps,
> +  required for power sink and power dual role.
> +- max-snk-microwatt-hours: The max power the sink can support in micro
> +  Watt-hours, required for power sink and power dual role.
> +- op-snk-microwatt-hours: Sink required operating power in micro Watt-hours,
> +  if source offered power is less then it, Capability Mismatch is set,
> +  required for power sink and power dual role.

What is the relation between above properties and PDOs specified earlier?
Are you sure all these props are required?

And general remark regarding all above properties. For me, most of them
are specific not to the port but to devices responsible for power
management: chargers, pmics,....
In many cases these properties are redundant with devices capabilities.
On the other side I guess in many cases it may be convenient to put them
here, so I am not sure what is better :)

Regards
Andrzej

> +
>  Required nodes:
>  - any data bus to the connector should be modeled using the OF graph bindings
>    specified in bindings/graph.txt, unless the bus is between parent node and
> @@ -73,3 +97,22 @@ ccic: s2mm005@33 {
>  		};
>  	};
>  };
> +
> +3. USB-C connector attached to a typec port controller(ptn5110), which has
> +power delivery support and enables drp.
> +
> +typec: ptn5110@50 {
> +	...
> +	usb_con: connector {
> +		compatible = "usb-c-connector";
> +		label = "USB-C";
> +		port-type = "dual";
> +		default-role = "sink";
> +		src-pdos = <0x380190c8>;
> +		snk-pdos = <0x380190c8 0x3802d0c8>;
> +		max-snk-microvolt = <9000>;
> +		max-snk-microamp = <2000>;
> +		max-snk-microwatt-hours = <18000>;
> +		op-snk-microwatt-hours = <9000>;
> +	};
> +};

[v2,10/12] dt-bindings: connector: add properties for typec power delivery

[Andrzej Hajda]

On 26.02.2018 12:49, Li Jun wrote:
> In case of usb-c-connector with power delivery support, add bingdings
> supported by current typec driver, so user can pass all those properties
> via dt.
>
> Signed-off-by: Li Jun <jun.li@nxp.com>
> ---
> Changes for v2:
> - Added typec properties are based on general usb connector bindings[1]
>   proposed by Andrzej Hajda.
> - Use the standard unit suffixes as defined in property-units.txt.
>
> [1] https://patchwork.kernel.org/patch/10231447/
>
>  .../bindings/connector/usb-connector.txt           | 43 ++++++++++++++++++++++
>  1 file changed, 43 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/connector/usb-connector.txt b/Documentation/devicetree/bindings/connector/usb-connector.txt
> index e1463f1..242f6df 100644
> --- a/Documentation/devicetree/bindings/connector/usb-connector.txt
> +++ b/Documentation/devicetree/bindings/connector/usb-connector.txt
> @@ -15,6 +15,30 @@ Optional properties:
>  - type: size of the connector, should be specified in case of USB-A, USB-B
>    non-fullsize connectors: "mini", "micro".
>  
> +Required properties for usb-c-connector with power delivery support:
> +- port-type: should be one of "source", "sink" or "dual".
> +- default-role: preferred power role if port-type is "dual"(drp), should be
> +  "sink" or "source".

Since port carries data and power, it would be better to explicitly
mention it in names of properties which can be ambiguous.
Maybe instead of 'port-type' you can use 'power-role', for example.
Other thing is that default-role is required only in case of DRP, so
maybe better would be to squash it in power-role, for example:
    power-role: should be on of "source", "sink", "dual-source",
"dual-sink", in case of dual roles suffix determines preferred role.


> +- src-pdos: An array of u32 with each entry providing supported power
> +  source data object(PDO), the detailed bit definitions of PDO can be found
> +  in "Universal Serial Bus Power Delivery Specification" chapter 6.4.1.2
> +  Source_Capabilities Message, the order of each entry(PDO) should follow
> +  the PD spec chapter 6.4.1. Required for power source and power dual role.
> +- snk-pdos: An array of u32 with each entry providing supported power
> +  sink data object(PDO), the detailed bit definitions of PDO can be found in
> +  "Universal Serial Bus Power Delivery Specification" chapter 6.4.1.3 Sink
> +  Capabilities Message, the order of each entry(PDO) should follow the PD
> +  spec chapter 6.4.1. Required for power sink and power dual role.

We should avoid magic numbers, magic numbers are bad :)
If we really need to use PDOs here, I think we can re-use PDO_* macros
[1] - DTC should be able to parse it, maybe some lifting will be necessary.

[1]:
https://elixir.bootlin.com/linux/v4.16-rc3/source/include/linux/usb/pd.h#L161
> +- max-snk-microvolt: The max voltage the sink can support in micro volts,
> +  required for power sink and power dual role.
> +- max-snk-microamp: The max current the sink can support in micro amps,
> +  required for power sink and power dual role.
> +- max-snk-microwatt-hours: The max power the sink can support in micro
> +  Watt-hours, required for power sink and power dual role.
> +- op-snk-microwatt-hours: Sink required operating power in micro Watt-hours,
> +  if source offered power is less then it, Capability Mismatch is set,
> +  required for power sink and power dual role.

What is the relation between above properties and PDOs specified earlier?
Are you sure all these props are required?

And general remark regarding all above properties. For me, most of them
are specific not to the port but to devices responsible for power
management: chargers, pmics,....
In many cases these properties are redundant with devices capabilities.
On the other side I guess in many cases it may be convenient to put them
here, so I am not sure what is better :)

Regards
Andrzej

> +
>  Required nodes:
>  - any data bus to the connector should be modeled using the OF graph bindings
>    specified in bindings/graph.txt, unless the bus is between parent node and
> @@ -73,3 +97,22 @@ ccic: s2mm005@33 {
>  		};
>  	};
>  };
> +
> +3. USB-C connector attached to a typec port controller(ptn5110), which has
> +power delivery support and enables drp.
> +
> +typec: ptn5110@50 {
> +	...
> +	usb_con: connector {
> +		compatible = "usb-c-connector";
> +		label = "USB-C";
> +		port-type = "dual";
> +		default-role = "sink";
> +		src-pdos = <0x380190c8>;
> +		snk-pdos = <0x380190c8 0x3802d0c8>;
> +		max-snk-microvolt = <9000>;
> +		max-snk-microamp = <2000>;
> +		max-snk-microwatt-hours = <18000>;
> +		op-snk-microwatt-hours = <9000>;
> +	};
> +};
---
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

Re: [PATCH v2 03/12] staging: typec: tcpci: support port config passed via dt

[Heikki Krogerus]

Hi,

On Mon, Feb 26, 2018 at 02:30:53PM +0000, Jun Li wrote:
> > > +	child = of_get_child_by_name(tcpci->dev->of_node, "connector");
> > > +	if (!child) {
> > > +		dev_err(tcpci->dev, "failed to get connector node.\n");
> > > +		return -EINVAL;
> > > +	}
> > 
> > Why do you need separate child node for the connector? You will always
> > have only one connector per tcpc, i.e. the tcpci already represents the
> > connector and all its capabilities.
> > 
> This is my original idea, my understanding is Rob expects those properties should
> apply for a common usb connector node[1], that way I need add a child node for it,
> sorry I didn't make the dt-binding patches come first in this series, please see
> patch 10,11.
> 
> [1] https://patchwork.kernel.org/patch/10231447/

But was the idea really to put properties like the TCPC capabilities
under the usb connector child node? That will force us to extract
the same properties in two different methods in every USB Type-C
driver. One extracting them from DT, and another from other FW
interfaces and build-in properties.

To avoid that, let's just expect to get these properties in the node
for tcpc, not the usb connector child.


Thanks,

-- 
heikki

[v2,03/12] staging: typec: tcpci: support port config passed via dt

[Heikki Krogerus]

Hi,

On Mon, Feb 26, 2018 at 02:30:53PM +0000, Jun Li wrote:
> > > +	child = of_get_child_by_name(tcpci->dev->of_node, "connector");
> > > +	if (!child) {
> > > +		dev_err(tcpci->dev, "failed to get connector node.\n");
> > > +		return -EINVAL;
> > > +	}
> > 
> > Why do you need separate child node for the connector? You will always
> > have only one connector per tcpc, i.e. the tcpci already represents the
> > connector and all its capabilities.
> > 
> This is my original idea, my understanding is Rob expects those properties should
> apply for a common usb connector node[1], that way I need add a child node for it,
> sorry I didn't make the dt-binding patches come first in this series, please see
> patch 10,11.
> 
> [1] https://patchwork.kernel.org/patch/10231447/

But was the idea really to put properties like the TCPC capabilities
under the usb connector child node? That will force us to extract
the same properties in two different methods in every USB Type-C
driver. One extracting them from DT, and another from other FW
interfaces and build-in properties.

To avoid that, let's just expect to get these properties in the node
for tcpc, not the usb connector child.


Thanks,

Re: [PATCH v2 10/12] dt-bindings: connector: add properties for typec power delivery

[Rob Herring]

On Mon, Feb 26, 2018 at 07:49:17PM +0800, Li Jun wrote:
> In case of usb-c-connector with power delivery support, add bingdings
> supported by current typec driver, so user can pass all those properties
> via dt.
> 
> Signed-off-by: Li Jun <jun.li@nxp.com>
> ---
> Changes for v2:
> - Added typec properties are based on general usb connector bindings[1]
>   proposed by Andrzej Hajda.
> - Use the standard unit suffixes as defined in property-units.txt.
> 
> [1] https://patchwork.kernel.org/patch/10231447/
> 
>  .../bindings/connector/usb-connector.txt           | 43 ++++++++++++++++++++++
>  1 file changed, 43 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/connector/usb-connector.txt b/Documentation/devicetree/bindings/connector/usb-connector.txt
> index e1463f1..242f6df 100644
> --- a/Documentation/devicetree/bindings/connector/usb-connector.txt
> +++ b/Documentation/devicetree/bindings/connector/usb-connector.txt
> @@ -15,6 +15,30 @@ Optional properties:
>  - type: size of the connector, should be specified in case of USB-A, USB-B
>    non-fullsize connectors: "mini", "micro".
>  
> +Required properties for usb-c-connector with power delivery support:
> +- port-type: should be one of "source", "sink" or "dual".
> +- default-role: preferred power role if port-type is "dual"(drp), should be
> +  "sink" or "source".
> +- src-pdos: An array of u32 with each entry providing supported power
> +  source data object(PDO), the detailed bit definitions of PDO can be found
> +  in "Universal Serial Bus Power Delivery Specification" chapter 6.4.1.2
> +  Source_Capabilities Message, the order of each entry(PDO) should follow
> +  the PD spec chapter 6.4.1. Required for power source and power dual role.
> +- snk-pdos: An array of u32 with each entry providing supported power

Abbreviating sink to snk doesn't buy much. I'd also just do source 
instead of src.

> +  sink data object(PDO), the detailed bit definitions of PDO can be found in
> +  "Universal Serial Bus Power Delivery Specification" chapter 6.4.1.3 Sink
> +  Capabilities Message, the order of each entry(PDO) should follow the PD
> +  spec chapter 6.4.1. Required for power sink and power dual role.
> +- max-snk-microvolt: The max voltage the sink can support in micro volts,
> +  required for power sink and power dual role.
> +- max-snk-microamp: The max current the sink can support in micro amps,
> +  required for power sink and power dual role.
> +- max-snk-microwatt-hours: The max power the sink can support in micro
> +  Watt-hours, required for power sink and power dual role.
> +- op-snk-microwatt-hours: Sink required operating power in micro Watt-hours,
> +  if source offered power is less then it, Capability Mismatch is set,
> +  required for power sink and power dual role.

None of these properties are part of the PDO?

> +
>  Required nodes:
>  - any data bus to the connector should be modeled using the OF graph bindings
>    specified in bindings/graph.txt, unless the bus is between parent node and
> @@ -73,3 +97,22 @@ ccic: s2mm005@33 {
>  		};
>  	};
>  };
> +
> +3. USB-C connector attached to a typec port controller(ptn5110), which has
> +power delivery support and enables drp.
> +
> +typec: ptn5110@50 {
> +	...
> +	usb_con: connector {
> +		compatible = "usb-c-connector";
> +		label = "USB-C";
> +		port-type = "dual";
> +		default-role = "sink";
> +		src-pdos = <0x380190c8>;
> +		snk-pdos = <0x380190c8 0x3802d0c8>;
> +		max-snk-microvolt = <9000>;
> +		max-snk-microamp = <2000>;
> +		max-snk-microwatt-hours = <18000>;
> +		op-snk-microwatt-hours = <9000>;
> +	};
> +};
> -- 
> 2.7.4
> 
> --
> To unsubscribe from this list: send the line "unsubscribe devicetree" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

[v2,10/12] dt-bindings: connector: add properties for typec power delivery

[Rob Herring]

On Mon, Feb 26, 2018 at 07:49:17PM +0800, Li Jun wrote:
> In case of usb-c-connector with power delivery support, add bingdings
> supported by current typec driver, so user can pass all those properties
> via dt.
> 
> Signed-off-by: Li Jun <jun.li@nxp.com>
> ---
> Changes for v2:
> - Added typec properties are based on general usb connector bindings[1]
>   proposed by Andrzej Hajda.
> - Use the standard unit suffixes as defined in property-units.txt.
> 
> [1] https://patchwork.kernel.org/patch/10231447/
> 
>  .../bindings/connector/usb-connector.txt           | 43 ++++++++++++++++++++++
>  1 file changed, 43 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/connector/usb-connector.txt b/Documentation/devicetree/bindings/connector/usb-connector.txt
> index e1463f1..242f6df 100644
> --- a/Documentation/devicetree/bindings/connector/usb-connector.txt
> +++ b/Documentation/devicetree/bindings/connector/usb-connector.txt
> @@ -15,6 +15,30 @@ Optional properties:
>  - type: size of the connector, should be specified in case of USB-A, USB-B
>    non-fullsize connectors: "mini", "micro".
>  
> +Required properties for usb-c-connector with power delivery support:
> +- port-type: should be one of "source", "sink" or "dual".
> +- default-role: preferred power role if port-type is "dual"(drp), should be
> +  "sink" or "source".
> +- src-pdos: An array of u32 with each entry providing supported power
> +  source data object(PDO), the detailed bit definitions of PDO can be found
> +  in "Universal Serial Bus Power Delivery Specification" chapter 6.4.1.2
> +  Source_Capabilities Message, the order of each entry(PDO) should follow
> +  the PD spec chapter 6.4.1. Required for power source and power dual role.
> +- snk-pdos: An array of u32 with each entry providing supported power

Abbreviating sink to snk doesn't buy much. I'd also just do source 
instead of src.

> +  sink data object(PDO), the detailed bit definitions of PDO can be found in
> +  "Universal Serial Bus Power Delivery Specification" chapter 6.4.1.3 Sink
> +  Capabilities Message, the order of each entry(PDO) should follow the PD
> +  spec chapter 6.4.1. Required for power sink and power dual role.
> +- max-snk-microvolt: The max voltage the sink can support in micro volts,
> +  required for power sink and power dual role.
> +- max-snk-microamp: The max current the sink can support in micro amps,
> +  required for power sink and power dual role.
> +- max-snk-microwatt-hours: The max power the sink can support in micro
> +  Watt-hours, required for power sink and power dual role.
> +- op-snk-microwatt-hours: Sink required operating power in micro Watt-hours,
> +  if source offered power is less then it, Capability Mismatch is set,
> +  required for power sink and power dual role.

None of these properties are part of the PDO?

> +
>  Required nodes:
>  - any data bus to the connector should be modeled using the OF graph bindings
>    specified in bindings/graph.txt, unless the bus is between parent node and
> @@ -73,3 +97,22 @@ ccic: s2mm005@33 {
>  		};
>  	};
>  };
> +
> +3. USB-C connector attached to a typec port controller(ptn5110), which has
> +power delivery support and enables drp.
> +
> +typec: ptn5110@50 {
> +	...
> +	usb_con: connector {
> +		compatible = "usb-c-connector";
> +		label = "USB-C";
> +		port-type = "dual";
> +		default-role = "sink";
> +		src-pdos = <0x380190c8>;
> +		snk-pdos = <0x380190c8 0x3802d0c8>;
> +		max-snk-microvolt = <9000>;
> +		max-snk-microamp = <2000>;
> +		max-snk-microwatt-hours = <18000>;
> +		op-snk-microwatt-hours = <9000>;
> +	};
> +};
> -- 
> 2.7.4
> 
> --
> To unsubscribe from this list: send the line "unsubscribe devicetree" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
---
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

Re: [PATCH v2 10/12] dt-bindings: connector: add properties for typec power delivery

[Rob Herring]

On Tue, Feb 27, 2018 at 09:41:19AM +0100, Andrzej Hajda wrote:
> On 26.02.2018 12:49, Li Jun wrote:
> > In case of usb-c-connector with power delivery support, add bingdings
> > supported by current typec driver, so user can pass all those properties
> > via dt.
> >
> > Signed-off-by: Li Jun <jun.li@nxp.com>
> > ---
> > Changes for v2:
> > - Added typec properties are based on general usb connector bindings[1]
> >   proposed by Andrzej Hajda.
> > - Use the standard unit suffixes as defined in property-units.txt.
> >
> > [1] https://patchwork.kernel.org/patch/10231447/
> >
> >  .../bindings/connector/usb-connector.txt           | 43 ++++++++++++++++++++++
> >  1 file changed, 43 insertions(+)
> >
> > diff --git a/Documentation/devicetree/bindings/connector/usb-connector.txt b/Documentation/devicetree/bindings/connector/usb-connector.txt
> > index e1463f1..242f6df 100644
> > --- a/Documentation/devicetree/bindings/connector/usb-connector.txt
> > +++ b/Documentation/devicetree/bindings/connector/usb-connector.txt
> > @@ -15,6 +15,30 @@ Optional properties:
> >  - type: size of the connector, should be specified in case of USB-A, USB-B
> >    non-fullsize connectors: "mini", "micro".
> >  
> > +Required properties for usb-c-connector with power delivery support:
> > +- port-type: should be one of "source", "sink" or "dual".
> > +- default-role: preferred power role if port-type is "dual"(drp), should be
> > +  "sink" or "source".
> 
> Since port carries data and power, it would be better to explicitly
> mention it in names of properties which can be ambiguous.
> Maybe instead of 'port-type' you can use 'power-role', for example.
> Other thing is that default-role is required only in case of DRP, so
> maybe better would be to squash it in power-role, for example:
> ��� power-role: should be on of "source", "sink", "dual-source",
> "dual-sink", in case of dual roles suffix determines preferred role.
> 
> 
> > +- src-pdos: An array of u32 with each entry providing supported power
> > +  source data object(PDO), the detailed bit definitions of PDO can be found
> > +  in "Universal Serial Bus Power Delivery Specification" chapter 6.4.1.2
> > +  Source_Capabilities Message, the order of each entry(PDO) should follow
> > +  the PD spec chapter 6.4.1. Required for power source and power dual role.
> > +- snk-pdos: An array of u32 with each entry providing supported power
> > +  sink data object(PDO), the detailed bit definitions of PDO can be found in
> > +  "Universal Serial Bus Power Delivery Specification" chapter 6.4.1.3 Sink
> > +  Capabilities Message, the order of each entry(PDO) should follow the PD
> > +  spec chapter 6.4.1. Required for power sink and power dual role.
> 
> We should avoid magic numbers, magic numbers are bad :)

I don't mind if there's a defined format for the data.

> If we really need to use PDOs here, I think we can re-use PDO_* macros
> [1] - DTC should be able to parse it, maybe some lifting will be necessary.
> 
> [1]:
> https://elixir.bootlin.com/linux/v4.16-rc3/source/include/linux/usb/pd.h#L161
> > +- max-snk-microvolt: The max voltage the sink can support in micro volts,
> > +  required for power sink and power dual role.
> > +- max-snk-microamp: The max current the sink can support in micro amps,
> > +  required for power sink and power dual role.
> > +- max-snk-microwatt-hours: The max power the sink can support in micro
> > +  Watt-hours, required for power sink and power dual role.
> > +- op-snk-microwatt-hours: Sink required operating power in micro Watt-hours,
> > +  if source offered power is less then it, Capability Mismatch is set,
> > +  required for power sink and power dual role.
> 
> What is the relation between above properties and PDOs specified earlier?
> Are you sure all these props are required?
> 
> And general remark regarding all above properties. For me, most of them
> are specific not to the port but to devices responsible for power
> management: chargers, pmics,....
> In many cases these properties are redundant with devices capabilities.
> On the other side I guess in many cases it may be convenient to put them
> here, so I am not sure what is better :)

I debated that too, but decided if you had 2 connectors connected to a 
single power controller, then you'd want these in the connector.

Rob

[v2,10/12] dt-bindings: connector: add properties for typec power delivery

[Rob Herring]

On Tue, Feb 27, 2018 at 09:41:19AM +0100, Andrzej Hajda wrote:
> On 26.02.2018 12:49, Li Jun wrote:
> > In case of usb-c-connector with power delivery support, add bingdings
> > supported by current typec driver, so user can pass all those properties
> > via dt.
> >
> > Signed-off-by: Li Jun <jun.li@nxp.com>
> > ---
> > Changes for v2:
> > - Added typec properties are based on general usb connector bindings[1]
> >   proposed by Andrzej Hajda.
> > - Use the standard unit suffixes as defined in property-units.txt.
> >
> > [1] https://patchwork.kernel.org/patch/10231447/
> >
> >  .../bindings/connector/usb-connector.txt           | 43 ++++++++++++++++++++++
> >  1 file changed, 43 insertions(+)
> >
> > diff --git a/Documentation/devicetree/bindings/connector/usb-connector.txt b/Documentation/devicetree/bindings/connector/usb-connector.txt
> > index e1463f1..242f6df 100644
> > --- a/Documentation/devicetree/bindings/connector/usb-connector.txt
> > +++ b/Documentation/devicetree/bindings/connector/usb-connector.txt
> > @@ -15,6 +15,30 @@ Optional properties:
> >  - type: size of the connector, should be specified in case of USB-A, USB-B
> >    non-fullsize connectors: "mini", "micro".
> >  
> > +Required properties for usb-c-connector with power delivery support:
> > +- port-type: should be one of "source", "sink" or "dual".
> > +- default-role: preferred power role if port-type is "dual"(drp), should be
> > +  "sink" or "source".
> 
> Since port carries data and power, it would be better to explicitly
> mention it in names of properties which can be ambiguous.
> Maybe instead of 'port-type' you can use 'power-role', for example.
> Other thing is that default-role is required only in case of DRP, so
> maybe better would be to squash it in power-role, for example:
>     power-role: should be on of "source", "sink", "dual-source",
> "dual-sink", in case of dual roles suffix determines preferred role.
> 
> 
> > +- src-pdos: An array of u32 with each entry providing supported power
> > +  source data object(PDO), the detailed bit definitions of PDO can be found
> > +  in "Universal Serial Bus Power Delivery Specification" chapter 6.4.1.2
> > +  Source_Capabilities Message, the order of each entry(PDO) should follow
> > +  the PD spec chapter 6.4.1. Required for power source and power dual role.
> > +- snk-pdos: An array of u32 with each entry providing supported power
> > +  sink data object(PDO), the detailed bit definitions of PDO can be found in
> > +  "Universal Serial Bus Power Delivery Specification" chapter 6.4.1.3 Sink
> > +  Capabilities Message, the order of each entry(PDO) should follow the PD
> > +  spec chapter 6.4.1. Required for power sink and power dual role.
> 
> We should avoid magic numbers, magic numbers are bad :)

I don't mind if there's a defined format for the data.

> If we really need to use PDOs here, I think we can re-use PDO_* macros
> [1] - DTC should be able to parse it, maybe some lifting will be necessary.
> 
> [1]:
> https://elixir.bootlin.com/linux/v4.16-rc3/source/include/linux/usb/pd.h#L161
> > +- max-snk-microvolt: The max voltage the sink can support in micro volts,
> > +  required for power sink and power dual role.
> > +- max-snk-microamp: The max current the sink can support in micro amps,
> > +  required for power sink and power dual role.
> > +- max-snk-microwatt-hours: The max power the sink can support in micro
> > +  Watt-hours, required for power sink and power dual role.
> > +- op-snk-microwatt-hours: Sink required operating power in micro Watt-hours,
> > +  if source offered power is less then it, Capability Mismatch is set,
> > +  required for power sink and power dual role.
> 
> What is the relation between above properties and PDOs specified earlier?
> Are you sure all these props are required?
> 
> And general remark regarding all above properties. For me, most of them
> are specific not to the port but to devices responsible for power
> management: chargers, pmics,....
> In many cases these properties are redundant with devices capabilities.
> On the other side I guess in many cases it may be convenient to put them
> here, so I am not sure what is better :)

I debated that too, but decided if you had 2 connectors connected to a 
single power controller, then you'd want these in the connector.

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

Re: [PATCH v2 11/12] dt-bindings: usb: add documentation for typec port controller(TCPCI)

[Rob Herring]

On Mon, Feb 26, 2018 at 07:49:18PM +0800, Li Jun wrote:
> TCPCI stands for typec port controller interface, its implementation
> has full typec port control with power delivery support, it's a
> standard i2c slave with GPIO input as irq interface, detail see spec
> "Universal Serial Bus Type-C Port Controller Interface Specification
> Revision 1.0, Version 1.1"
> 
> Signed-off-by: Li Jun <jun.li@nxp.com>
> ---
> Change for v2:
> - Use usb connector sub-node accordingly to specify typec properties.
> 
>  .../devicetree/bindings/usb/typec-tcpci.txt        | 35 ++++++++++++++++++++++
>  1 file changed, 35 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/usb/typec-tcpci.txt b/Documentation/devicetree/bindings/usb/typec-tcpci.txt
> new file mode 100644
> index 0000000..318bf01
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/usb/typec-tcpci.txt
> @@ -0,0 +1,35 @@
> +TCPCI(Typec port cotroller interface) binding
> +---------------------------------------------
> +
> +Required properties:
> +- compatible:       should be "usb,tcpci".

usb is not a vendor. I'd do "usb-tcpci".

This will need chip specific compatible strings too.

> +- reg:              the i2c slave address of typec port controller device.
> +- interrupt-parent: the phandle to the interrupt controller which provides
> +                    the interrupt.
> +- interrupts:       interrupt specification for tcpci alert.
> +
> +Required sub-node:
> +- connector: The "usb-c-connector" attached to the tcpci chip, the bindings
> +  of connector node are specified in
> +  Documentation/devicetree/bindings/connector/usb-connector.txt
> +
> +Example:
> +
> +ptn5110@50 {
> +	compatible = "usb,tcpci";
> +	reg = <0x50>;
> +	interrupt-parent = <&gpio3>;
> +	interrupts = <3 IRQ_TYPE_LEVEL_LOW>;
> +
> +	usb_con: connector {
> +		compatible = "usb-c-connector";
> +		label = "USB-C";
> +		port-type = "dual";
> +		default-role = "sink";
> +		src-pdos = <0x380190c8>;
> +		snk-pdos = <0x380190c8 0x3802d0c8>;
> +		max-snk-mv = <9000>;
> +		max-snk-ma = <1000>;
> +		op-snk-mw = <9000>;
> +	};
> +};
> -- 
> 2.7.4
> 
> --
> To unsubscribe from this list: send the line "unsubscribe devicetree" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

[v2,11/12] dt-bindings: usb: add documentation for typec port controller(TCPCI)

[Rob Herring]

On Mon, Feb 26, 2018 at 07:49:18PM +0800, Li Jun wrote:
> TCPCI stands for typec port controller interface, its implementation
> has full typec port control with power delivery support, it's a
> standard i2c slave with GPIO input as irq interface, detail see spec
> "Universal Serial Bus Type-C Port Controller Interface Specification
> Revision 1.0, Version 1.1"
> 
> Signed-off-by: Li Jun <jun.li@nxp.com>
> ---
> Change for v2:
> - Use usb connector sub-node accordingly to specify typec properties.
> 
>  .../devicetree/bindings/usb/typec-tcpci.txt        | 35 ++++++++++++++++++++++
>  1 file changed, 35 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/usb/typec-tcpci.txt b/Documentation/devicetree/bindings/usb/typec-tcpci.txt
> new file mode 100644
> index 0000000..318bf01
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/usb/typec-tcpci.txt
> @@ -0,0 +1,35 @@
> +TCPCI(Typec port cotroller interface) binding
> +---------------------------------------------
> +
> +Required properties:
> +- compatible:       should be "usb,tcpci".

usb is not a vendor. I'd do "usb-tcpci".

This will need chip specific compatible strings too.

> +- reg:              the i2c slave address of typec port controller device.
> +- interrupt-parent: the phandle to the interrupt controller which provides
> +                    the interrupt.
> +- interrupts:       interrupt specification for tcpci alert.
> +
> +Required sub-node:
> +- connector: The "usb-c-connector" attached to the tcpci chip, the bindings
> +  of connector node are specified in
> +  Documentation/devicetree/bindings/connector/usb-connector.txt
> +
> +Example:
> +
> +ptn5110@50 {
> +	compatible = "usb,tcpci";
> +	reg = <0x50>;
> +	interrupt-parent = <&gpio3>;
> +	interrupts = <3 IRQ_TYPE_LEVEL_LOW>;
> +
> +	usb_con: connector {
> +		compatible = "usb-c-connector";
> +		label = "USB-C";
> +		port-type = "dual";
> +		default-role = "sink";
> +		src-pdos = <0x380190c8>;
> +		snk-pdos = <0x380190c8 0x3802d0c8>;
> +		max-snk-mv = <9000>;
> +		max-snk-ma = <1000>;
> +		op-snk-mw = <9000>;
> +	};
> +};
> -- 
> 2.7.4
> 
> --
> To unsubscribe from this list: send the line "unsubscribe devicetree" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
---
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

RE: [PATCH v2 10/12] dt-bindings: connector: add properties for typec power delivery

[Jun Li]

> -----Original Message-----
> From: Andrzej Hajda [mailto:a.hajda@samsung.com]
> Sent: 2018年2月27日 16:41
> To: Jun Li <jun.li@nxp.com>; gregkh@linuxfoundation.org;
> robh+dt@kernel.org; heikki.krogerus@linux.intel.com; linux@roeck-us.net
> Cc: mark.rutland@arm.com; yueyao@google.com; Peter Chen
> <peter.chen@nxp.com>; garsilva@embeddedor.com; o_leveque@orange.fr;
> shufan_lee@richtek.com; linux-usb@vger.kernel.org;
> devicetree@vger.kernel.org; dl-linux-imx <linux-imx@nxp.com>
> Subject: Re: [PATCH v2 10/12] dt-bindings: connector: add properties for
> typec power delivery
> 
> On 26.02.2018 12:49, Li Jun wrote:
> > In case of usb-c-connector with power delivery support, add bingdings
> > supported by current typec driver, so user can pass all those
> > properties via dt.
> >
> > Signed-off-by: Li Jun <jun.li@nxp.com>
> > ---
> > Changes for v2:
> > - Added typec properties are based on general usb connector bindings[1]
> >   proposed by Andrzej Hajda.
> > - Use the standard unit suffixes as defined in property-units.txt.
> >
> > [1]
> >
> https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpat
> >
> chwork.kernel.org%2Fpatch%2F10231447%2F&data=02%7C01%7Cjun.li%40
> nxp.co
> >
> m%7Cccf14a36ca6445ee5f1108d57dbde3c7%7C686ea1d3bc2b4c6fa92cd99
> c5c30163
> >
> 5%7C0%7C0%7C636553176880292197&sdata=2Pi0AtiwAqHQE3rGl%2Bo49K
> 7yZZcp%2B
> > 5bvJAknRBMGTrk%3D&reserved=0
> >
> >  .../bindings/connector/usb-connector.txt           | 43
> ++++++++++++++++++++++
> >  1 file changed, 43 insertions(+)
> >
> > diff --git
> > a/Documentation/devicetree/bindings/connector/usb-connector.txt
> > b/Documentation/devicetree/bindings/connector/usb-connector.txt
> > index e1463f1..242f6df 100644
> > --- a/Documentation/devicetree/bindings/connector/usb-connector.txt
> > +++ b/Documentation/devicetree/bindings/connector/usb-connector.txt
> > @@ -15,6 +15,30 @@ Optional properties:
> >  - type: size of the connector, should be specified in case of USB-A, USB-B
> >    non-fullsize connectors: "mini", "micro".
> >
> > +Required properties for usb-c-connector with power delivery support:
> > +- port-type: should be one of "source", "sink" or "dual".
> > +- default-role: preferred power role if port-type is "dual"(drp),
> > +should be
> > +  "sink" or "source".
> 
> Since port carries data and power, it would be better to explicitly mention it
> in names of properties which can be ambiguous.
> Maybe instead of 'port-type' you can use 'power-role', for example.

Port-type is align with the name of typec coding and ABI, 'power-role'
is more like for the current role rather than the port's ability.

> Other thing is that default-role is required only in case of DRP, so maybe
> better would be to squash it in power-role, for example:
>     power-role: should be on of "source", "sink", "dual-source", "dual-sink",
> in case of dual roles suffix determines preferred role.

I don't know how much this squash can benefit, "dual-source/sink" is not
directly showing its meaning by name.

> 
> 
> > +- src-pdos: An array of u32 with each entry providing supported power
> > +  source data object(PDO), the detailed bit definitions of PDO can be
> > +found
> > +  in "Universal Serial Bus Power Delivery Specification" chapter
> > +6.4.1.2
> > +  Source_Capabilities Message, the order of each entry(PDO) should
> > +follow
> > +  the PD spec chapter 6.4.1. Required for power source and power dual
> role.
> > +- snk-pdos: An array of u32 with each entry providing supported power
> > +  sink data object(PDO), the detailed bit definitions of PDO can be
> > +found in
> > +  "Universal Serial Bus Power Delivery Specification" chapter 6.4.1.3
> > +Sink
> > +  Capabilities Message, the order of each entry(PDO) should follow
> > +the PD
> > +  spec chapter 6.4.1. Required for power sink and power dual role.
> 
> We should avoid magic numbers, magic numbers are bad :) If we really need
> to use PDOs here, I think we can re-use PDO_* macros [1] - DTC should be
> able to parse it, maybe some lifting will be necessary.
> 
> [1]:
> https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Felix
> ir.bootlin.com%2Flinux%2Fv4.16-rc3%2Fsource%2Finclude%2Flinux%2Fusb%
> 2Fpd.h%23L161&data=02%7C01%7Cjun.li%40nxp.com%7Cccf14a36ca6445e
> e5f1108d57dbde3c7%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%
> 7C636553176880292197&sdata=72HA33wgRyd2PMoPnZOlMatI2CuadplkYN
> DDGKFSUB0%3D&reserved=0
> > +- max-snk-microvolt: The max voltage the sink can support in micro
> > +volts,
> > +  required for power sink and power dual role.
> > +- max-snk-microamp: The max current the sink can support in micro
> > +amps,
> > +  required for power sink and power dual role.
> > +- max-snk-microwatt-hours: The max power the sink can support in
> > +micro
> > +  Watt-hours, required for power sink and power dual role.
> > +- op-snk-microwatt-hours: Sink required operating power in micro
> > +Watt-hours,
> > +  if source offered power is less then it, Capability Mismatch is
> > +set,
> > +  required for power sink and power dual role.
> 
> What is the relation between above properties and PDOs specified earlier?
> Are you sure all these props are required?
> 

Sorry, with latest tcpm code, those props are not required, will remove them.

Jun Li
> And general remark regarding all above properties. For me, most of them
> are specific not to the port but to devices responsible for power
> management: chargers, pmics,....
> In many cases these properties are redundant with devices capabilities.
> On the other side I guess in many cases it may be convenient to put them
> here, so I am not sure what is better :)
> 
> Regards
> Andrzej
> 
> > +
> >  Required nodes:
> >  - any data bus to the connector should be modeled using the OF graph
> bindings
> >    specified in bindings/graph.txt, unless the bus is between parent
> > node and @@ -73,3 +97,22 @@ ccic: s2mm005@33 {
> >  		};
> >  	};
> >  };
> > +
> > +3. USB-C connector attached to a typec port controller(ptn5110),
> > +which has power delivery support and enables drp.
> > +
> > +typec: ptn5110@50 {
> > +	...
> > +	usb_con: connector {
> > +		compatible = "usb-c-connector";
> > +		label = "USB-C";
> > +		port-type = "dual";
> > +		default-role = "sink";
> > +		src-pdos = <0x380190c8>;
> > +		snk-pdos = <0x380190c8 0x3802d0c8>;
> > +		max-snk-microvolt = <9000>;
> > +		max-snk-microamp = <2000>;
> > +		max-snk-microwatt-hours = <18000>;
> > +		op-snk-microwatt-hours = <9000>;
> > +	};
> > +};
> 

[v2,10/12] dt-bindings: connector: add properties for typec power delivery

[Jun Li]

> -----Original Message-----
> From: Andrzej Hajda [mailto:a.hajda@samsung.com]
> Sent: 2018年2月27日 16:41
> To: Jun Li <jun.li@nxp.com>; gregkh@linuxfoundation.org;
> robh+dt@kernel.org; heikki.krogerus@linux.intel.com; linux@roeck-us.net
> Cc: mark.rutland@arm.com; yueyao@google.com; Peter Chen
> <peter.chen@nxp.com>; garsilva@embeddedor.com; o_leveque@orange.fr;
> shufan_lee@richtek.com; linux-usb@vger.kernel.org;
> devicetree@vger.kernel.org; dl-linux-imx <linux-imx@nxp.com>
> Subject: Re: [PATCH v2 10/12] dt-bindings: connector: add properties for
> typec power delivery
> 
> On 26.02.2018 12:49, Li Jun wrote:
> > In case of usb-c-connector with power delivery support, add bingdings
> > supported by current typec driver, so user can pass all those
> > properties via dt.
> >
> > Signed-off-by: Li Jun <jun.li@nxp.com>
> > ---
> > Changes for v2:
> > - Added typec properties are based on general usb connector bindings[1]
> >   proposed by Andrzej Hajda.
> > - Use the standard unit suffixes as defined in property-units.txt.
> >
> > [1]
> >
> https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpat
> >
> chwork.kernel.org%2Fpatch%2F10231447%2F&data=02%7C01%7Cjun.li%40
> nxp.co
> >
> m%7Cccf14a36ca6445ee5f1108d57dbde3c7%7C686ea1d3bc2b4c6fa92cd99
> c5c30163
> >
> 5%7C0%7C0%7C636553176880292197&sdata=2Pi0AtiwAqHQE3rGl%2Bo49K
> 7yZZcp%2B
> > 5bvJAknRBMGTrk%3D&reserved=0
> >
> >  .../bindings/connector/usb-connector.txt           | 43
> ++++++++++++++++++++++
> >  1 file changed, 43 insertions(+)
> >
> > diff --git
> > a/Documentation/devicetree/bindings/connector/usb-connector.txt
> > b/Documentation/devicetree/bindings/connector/usb-connector.txt
> > index e1463f1..242f6df 100644
> > --- a/Documentation/devicetree/bindings/connector/usb-connector.txt
> > +++ b/Documentation/devicetree/bindings/connector/usb-connector.txt
> > @@ -15,6 +15,30 @@ Optional properties:
> >  - type: size of the connector, should be specified in case of USB-A, USB-B
> >    non-fullsize connectors: "mini", "micro".
> >
> > +Required properties for usb-c-connector with power delivery support:
> > +- port-type: should be one of "source", "sink" or "dual".
> > +- default-role: preferred power role if port-type is "dual"(drp),
> > +should be
> > +  "sink" or "source".
> 
> Since port carries data and power, it would be better to explicitly mention it
> in names of properties which can be ambiguous.
> Maybe instead of 'port-type' you can use 'power-role', for example.

Port-type is align with the name of typec coding and ABI, 'power-role'
is more like for the current role rather than the port's ability.

> Other thing is that default-role is required only in case of DRP, so maybe
> better would be to squash it in power-role, for example:
>     power-role: should be on of "source", "sink", "dual-source", "dual-sink",
> in case of dual roles suffix determines preferred role.

I don't know how much this squash can benefit, "dual-source/sink" is not
directly showing its meaning by name.

> 
> 
> > +- src-pdos: An array of u32 with each entry providing supported power
> > +  source data object(PDO), the detailed bit definitions of PDO can be
> > +found
> > +  in "Universal Serial Bus Power Delivery Specification" chapter
> > +6.4.1.2
> > +  Source_Capabilities Message, the order of each entry(PDO) should
> > +follow
> > +  the PD spec chapter 6.4.1. Required for power source and power dual
> role.
> > +- snk-pdos: An array of u32 with each entry providing supported power
> > +  sink data object(PDO), the detailed bit definitions of PDO can be
> > +found in
> > +  "Universal Serial Bus Power Delivery Specification" chapter 6.4.1.3
> > +Sink
> > +  Capabilities Message, the order of each entry(PDO) should follow
> > +the PD
> > +  spec chapter 6.4.1. Required for power sink and power dual role.
> 
> We should avoid magic numbers, magic numbers are bad :) If we really need
> to use PDOs here, I think we can re-use PDO_* macros [1] - DTC should be
> able to parse it, maybe some lifting will be necessary.
> 
> [1]:
> https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Felix
> ir.bootlin.com%2Flinux%2Fv4.16-rc3%2Fsource%2Finclude%2Flinux%2Fusb%
> 2Fpd.h%23L161&data=02%7C01%7Cjun.li%40nxp.com%7Cccf14a36ca6445e
> e5f1108d57dbde3c7%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%
> 7C636553176880292197&sdata=72HA33wgRyd2PMoPnZOlMatI2CuadplkYN
> DDGKFSUB0%3D&reserved=0
> > +- max-snk-microvolt: The max voltage the sink can support in micro
> > +volts,
> > +  required for power sink and power dual role.
> > +- max-snk-microamp: The max current the sink can support in micro
> > +amps,
> > +  required for power sink and power dual role.
> > +- max-snk-microwatt-hours: The max power the sink can support in
> > +micro
> > +  Watt-hours, required for power sink and power dual role.
> > +- op-snk-microwatt-hours: Sink required operating power in micro
> > +Watt-hours,
> > +  if source offered power is less then it, Capability Mismatch is
> > +set,
> > +  required for power sink and power dual role.
> 
> What is the relation between above properties and PDOs specified earlier?
> Are you sure all these props are required?
> 

Sorry, with latest tcpm code, those props are not required, will remove them.

Jun Li
> And general remark regarding all above properties. For me, most of them
> are specific not to the port but to devices responsible for power
> management: chargers, pmics,....
> In many cases these properties are redundant with devices capabilities.
> On the other side I guess in many cases it may be convenient to put them
> here, so I am not sure what is better :)
> 
> Regards
> Andrzej
> 
> > +
> >  Required nodes:
> >  - any data bus to the connector should be modeled using the OF graph
> bindings
> >    specified in bindings/graph.txt, unless the bus is between parent
> > node and @@ -73,3 +97,22 @@ ccic: s2mm005@33 {
> >  		};
> >  	};
> >  };
> > +
> > +3. USB-C connector attached to a typec port controller(ptn5110),
> > +which has power delivery support and enables drp.
> > +
> > +typec: ptn5110@50 {
> > +	...
> > +	usb_con: connector {
> > +		compatible = "usb-c-connector";
> > +		label = "USB-C";
> > +		port-type = "dual";
> > +		default-role = "sink";
> > +		src-pdos = <0x380190c8>;
> > +		snk-pdos = <0x380190c8 0x3802d0c8>;
> > +		max-snk-microvolt = <9000>;
> > +		max-snk-microamp = <2000>;
> > +		max-snk-microwatt-hours = <18000>;
> > +		op-snk-microwatt-hours = <9000>;
> > +	};
> > +};
>

RE: [PATCH v2 10/12] dt-bindings: connector: add properties for typec power delivery

[Jun Li]

> -----Original Message-----
> From: Rob Herring [mailto:robh@kernel.org]
> Sent: 2018年3月3日 6:29
> To: Jun Li <jun.li@nxp.com>
> Cc: gregkh@linuxfoundation.org; heikki.krogerus@linux.intel.com;
> linux@roeck-us.net; a.hajda@samsung.com; mark.rutland@arm.com;
> yueyao@google.com; Peter Chen <peter.chen@nxp.com>;
> garsilva@embeddedor.com; o_leveque@orange.fr;
> shufan_lee@richtek.com; linux-usb@vger.kernel.org;
> devicetree@vger.kernel.org; dl-linux-imx <linux-imx@nxp.com>
> Subject: Re: [PATCH v2 10/12] dt-bindings: connector: add properties for
> typec power delivery
> 
> On Mon, Feb 26, 2018 at 07:49:17PM +0800, Li Jun wrote:
> > In case of usb-c-connector with power delivery support, add bingdings
> > supported by current typec driver, so user can pass all those
> > properties via dt.
> >
> > Signed-off-by: Li Jun <jun.li@nxp.com>
> > ---
> > Changes for v2:
> > - Added typec properties are based on general usb connector bindings[1]
> >   proposed by Andrzej Hajda.
> > - Use the standard unit suffixes as defined in property-units.txt.
> >
> > [1]
> >
> https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpat
> >
> chwork.kernel.org%2Fpatch%2F10231447%2F&data=02%7C01%7Cjun.li%40
> nxp.co
> >
> m%7C1741037c725343583b2c08d5808d034c%7C686ea1d3bc2b4c6fa92cd9
> 9c5c30163
> >
> 5%7C0%7C0%7C636556265503496434&sdata=AlR4ybLfxkAedHJCYQtlD%2B
> OXLEOAcbs
> > olMZumioKKNk%3D&reserved=0
> >
> >  .../bindings/connector/usb-connector.txt           | 43
> ++++++++++++++++++++++
> >  1 file changed, 43 insertions(+)
> >
> > diff --git
> > a/Documentation/devicetree/bindings/connector/usb-connector.txt
> > b/Documentation/devicetree/bindings/connector/usb-connector.txt
> > index e1463f1..242f6df 100644
> > --- a/Documentation/devicetree/bindings/connector/usb-connector.txt
> > +++ b/Documentation/devicetree/bindings/connector/usb-connector.txt
> > @@ -15,6 +15,30 @@ Optional properties:
> >  - type: size of the connector, should be specified in case of USB-A, USB-B
> >    non-fullsize connectors: "mini", "micro".
> >
> > +Required properties for usb-c-connector with power delivery support:
> > +- port-type: should be one of "source", "sink" or "dual".
> > +- default-role: preferred power role if port-type is "dual"(drp),
> > +should be
> > +  "sink" or "source".
> > +- src-pdos: An array of u32 with each entry providing supported power
> > +  source data object(PDO), the detailed bit definitions of PDO can be
> > +found
> > +  in "Universal Serial Bus Power Delivery Specification" chapter
> > +6.4.1.2
> > +  Source_Capabilities Message, the order of each entry(PDO) should
> > +follow
> > +  the PD spec chapter 6.4.1. Required for power source and power dual
> role.
> > +- snk-pdos: An array of u32 with each entry providing supported power
> 
> Abbreviating sink to snk doesn't buy much. I'd also just do source instead of
> src.

Will use source/sink-pdos in next version.

> 
> > +  sink data object(PDO), the detailed bit definitions of PDO can be
> > +found in
> > +  "Universal Serial Bus Power Delivery Specification" chapter 6.4.1.3
> > +Sink
> > +  Capabilities Message, the order of each entry(PDO) should follow
> > +the PD
> > +  spec chapter 6.4.1. Required for power sink and power dual role.
> > +- max-snk-microvolt: The max voltage the sink can support in micro
> > +volts,
> > +  required for power sink and power dual role.
> > +- max-snk-microamp: The max current the sink can support in micro
> > +amps,
> > +  required for power sink and power dual role.
> > +- max-snk-microwatt-hours: The max power the sink can support in
> > +micro
> > +  Watt-hours, required for power sink and power dual role.
> > +- op-snk-microwatt-hours: Sink required operating power in micro
> > +Watt-hours,
> > +  if source offered power is less then it, Capability Mismatch is
> > +set,
> > +  required for power sink and power dual role.
> 
> None of these properties are part of the PDO?

Sorry, all above 4 props are not required any more with latest code,
I will remove them.

Jun Li

[v2,10/12] dt-bindings: connector: add properties for typec power delivery

[Jun Li]

DQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IFJvYiBIZXJyaW5nIFttYWls
dG86cm9iaEBrZXJuZWwub3JnXQ0KPiBTZW50OiAyMDE4xOoz1MIzyNUgNjoyOQ0KPiBUbzogSnVu
IExpIDxqdW4ubGlAbnhwLmNvbT4NCj4gQ2M6IGdyZWdraEBsaW51eGZvdW5kYXRpb24ub3JnOyBo
ZWlra2kua3JvZ2VydXNAbGludXguaW50ZWwuY29tOw0KPiBsaW51eEByb2Vjay11cy5uZXQ7IGEu
aGFqZGFAc2Ftc3VuZy5jb207IG1hcmsucnV0bGFuZEBhcm0uY29tOw0KPiB5dWV5YW9AZ29vZ2xl
LmNvbTsgUGV0ZXIgQ2hlbiA8cGV0ZXIuY2hlbkBueHAuY29tPjsNCj4gZ2Fyc2lsdmFAZW1iZWRk
ZWRvci5jb207IG9fbGV2ZXF1ZUBvcmFuZ2UuZnI7DQo+IHNodWZhbl9sZWVAcmljaHRlay5jb207
IGxpbnV4LXVzYkB2Z2VyLmtlcm5lbC5vcmc7DQo+IGRldmljZXRyZWVAdmdlci5rZXJuZWwub3Jn
OyBkbC1saW51eC1pbXggPGxpbnV4LWlteEBueHAuY29tPg0KPiBTdWJqZWN0OiBSZTogW1BBVENI
IHYyIDEwLzEyXSBkdC1iaW5kaW5nczogY29ubmVjdG9yOiBhZGQgcHJvcGVydGllcyBmb3INCj4g
dHlwZWMgcG93ZXIgZGVsaXZlcnkNCj4gDQo+IE9uIE1vbiwgRmViIDI2LCAyMDE4IGF0IDA3OjQ5
OjE3UE0gKzA4MDAsIExpIEp1biB3cm90ZToNCj4gPiBJbiBjYXNlIG9mIHVzYi1jLWNvbm5lY3Rv
ciB3aXRoIHBvd2VyIGRlbGl2ZXJ5IHN1cHBvcnQsIGFkZCBiaW5nZGluZ3MNCj4gPiBzdXBwb3J0
ZWQgYnkgY3VycmVudCB0eXBlYyBkcml2ZXIsIHNvIHVzZXIgY2FuIHBhc3MgYWxsIHRob3NlDQo+
ID4gcHJvcGVydGllcyB2aWEgZHQuDQo+ID4NCj4gPiBTaWduZWQtb2ZmLWJ5OiBMaSBKdW4gPGp1
bi5saUBueHAuY29tPg0KPiA+IC0tLQ0KPiA+IENoYW5nZXMgZm9yIHYyOg0KPiA+IC0gQWRkZWQg
dHlwZWMgcHJvcGVydGllcyBhcmUgYmFzZWQgb24gZ2VuZXJhbCB1c2IgY29ubmVjdG9yIGJpbmRp
bmdzWzFdDQo+ID4gICBwcm9wb3NlZCBieSBBbmRyemVqIEhhamRhLg0KPiA+IC0gVXNlIHRoZSBz
dGFuZGFyZCB1bml0IHN1ZmZpeGVzIGFzIGRlZmluZWQgaW4gcHJvcGVydHktdW5pdHMudHh0Lg0K
PiA+DQo+ID4gWzFdDQo+ID4NCj4gaHR0cHM6Ly9lbWVhMDEuc2FmZWxpbmtzLnByb3RlY3Rpb24u
b3V0bG9vay5jb20vP3VybD1odHRwcyUzQSUyRiUyRnBhdA0KPiA+DQo+IGNod29yay5rZXJuZWwu
b3JnJTJGcGF0Y2glMkYxMDIzMTQ0NyUyRiZkYXRhPTAyJTdDMDElN0NqdW4ubGklNDANCj4gbnhw
LmNvDQo+ID4NCj4gbSU3QzE3NDEwMzdjNzI1MzQzNTgzYjJjMDhkNTgwOGQwMzRjJTdDNjg2ZWEx
ZDNiYzJiNGM2ZmE5MmNkOQ0KPiA5YzVjMzAxNjMNCj4gPg0KPiA1JTdDMCU3QzAlN0M2MzY1NTYy
NjU1MDM0OTY0MzQmc2RhdGE9QWxSNHliTGZ4a0FlZEhKQ1lRdGxEJTJCDQo+IE9YTEVPQWNicw0K
PiA+IG9sTVp1bWlvS0tOayUzRCZyZXNlcnZlZD0wDQo+ID4NCj4gPiAgLi4uL2JpbmRpbmdzL2Nv
bm5lY3Rvci91c2ItY29ubmVjdG9yLnR4dCAgICAgICAgICAgfCA0Mw0KPiArKysrKysrKysrKysr
KysrKysrKysrDQo+ID4gIDEgZmlsZSBjaGFuZ2VkLCA0MyBpbnNlcnRpb25zKCspDQo+ID4NCj4g
PiBkaWZmIC0tZ2l0DQo+ID4gYS9Eb2N1bWVudGF0aW9uL2RldmljZXRyZWUvYmluZGluZ3MvY29u
bmVjdG9yL3VzYi1jb25uZWN0b3IudHh0DQo+ID4gYi9Eb2N1bWVudGF0aW9uL2RldmljZXRyZWUv
YmluZGluZ3MvY29ubmVjdG9yL3VzYi1jb25uZWN0b3IudHh0DQo+ID4gaW5kZXggZTE0NjNmMS4u
MjQyZjZkZiAxMDA2NDQNCj4gPiAtLS0gYS9Eb2N1bWVudGF0aW9uL2RldmljZXRyZWUvYmluZGlu
Z3MvY29ubmVjdG9yL3VzYi1jb25uZWN0b3IudHh0DQo+ID4gKysrIGIvRG9jdW1lbnRhdGlvbi9k
ZXZpY2V0cmVlL2JpbmRpbmdzL2Nvbm5lY3Rvci91c2ItY29ubmVjdG9yLnR4dA0KPiA+IEBAIC0x
NSw2ICsxNSwzMCBAQCBPcHRpb25hbCBwcm9wZXJ0aWVzOg0KPiA+ICAtIHR5cGU6IHNpemUgb2Yg
dGhlIGNvbm5lY3Rvciwgc2hvdWxkIGJlIHNwZWNpZmllZCBpbiBjYXNlIG9mIFVTQi1BLCBVU0It
Qg0KPiA+ICAgIG5vbi1mdWxsc2l6ZSBjb25uZWN0b3JzOiAibWluaSIsICJtaWNybyIuDQo+ID4N
Cj4gPiArUmVxdWlyZWQgcHJvcGVydGllcyBmb3IgdXNiLWMtY29ubmVjdG9yIHdpdGggcG93ZXIg
ZGVsaXZlcnkgc3VwcG9ydDoNCj4gPiArLSBwb3J0LXR5cGU6IHNob3VsZCBiZSBvbmUgb2YgInNv
dXJjZSIsICJzaW5rIiBvciAiZHVhbCIuDQo+ID4gKy0gZGVmYXVsdC1yb2xlOiBwcmVmZXJyZWQg
cG93ZXIgcm9sZSBpZiBwb3J0LXR5cGUgaXMgImR1YWwiKGRycCksDQo+ID4gK3Nob3VsZCBiZQ0K
PiA+ICsgICJzaW5rIiBvciAic291cmNlIi4NCj4gPiArLSBzcmMtcGRvczogQW4gYXJyYXkgb2Yg
dTMyIHdpdGggZWFjaCBlbnRyeSBwcm92aWRpbmcgc3VwcG9ydGVkIHBvd2VyDQo+ID4gKyAgc291
cmNlIGRhdGEgb2JqZWN0KFBETyksIHRoZSBkZXRhaWxlZCBiaXQgZGVmaW5pdGlvbnMgb2YgUERP
IGNhbiBiZQ0KPiA+ICtmb3VuZA0KPiA+ICsgIGluICJVbml2ZXJzYWwgU2VyaWFsIEJ1cyBQb3dl
ciBEZWxpdmVyeSBTcGVjaWZpY2F0aW9uIiBjaGFwdGVyDQo+ID4gKzYuNC4xLjINCj4gPiArICBT
b3VyY2VfQ2FwYWJpbGl0aWVzIE1lc3NhZ2UsIHRoZSBvcmRlciBvZiBlYWNoIGVudHJ5KFBETykg
c2hvdWxkDQo+ID4gK2ZvbGxvdw0KPiA+ICsgIHRoZSBQRCBzcGVjIGNoYXB0ZXIgNi40LjEuIFJl
cXVpcmVkIGZvciBwb3dlciBzb3VyY2UgYW5kIHBvd2VyIGR1YWwNCj4gcm9sZS4NCj4gPiArLSBz
bmstcGRvczogQW4gYXJyYXkgb2YgdTMyIHdpdGggZWFjaCBlbnRyeSBwcm92aWRpbmcgc3VwcG9y
dGVkIHBvd2VyDQo+IA0KPiBBYmJyZXZpYXRpbmcgc2luayB0byBzbmsgZG9lc24ndCBidXkgbXVj
aC4gSSdkIGFsc28ganVzdCBkbyBzb3VyY2UgaW5zdGVhZCBvZg0KPiBzcmMuDQoNCldpbGwgdXNl
IHNvdXJjZS9zaW5rLXBkb3MgaW4gbmV4dCB2ZXJzaW9uLg0KDQo+IA0KPiA+ICsgIHNpbmsgZGF0
YSBvYmplY3QoUERPKSwgdGhlIGRldGFpbGVkIGJpdCBkZWZpbml0aW9ucyBvZiBQRE8gY2FuIGJl
DQo+ID4gK2ZvdW5kIGluDQo+ID4gKyAgIlVuaXZlcnNhbCBTZXJpYWwgQnVzIFBvd2VyIERlbGl2
ZXJ5IFNwZWNpZmljYXRpb24iIGNoYXB0ZXIgNi40LjEuMw0KPiA+ICtTaW5rDQo+ID4gKyAgQ2Fw
YWJpbGl0aWVzIE1lc3NhZ2UsIHRoZSBvcmRlciBvZiBlYWNoIGVudHJ5KFBETykgc2hvdWxkIGZv
bGxvdw0KPiA+ICt0aGUgUEQNCj4gPiArICBzcGVjIGNoYXB0ZXIgNi40LjEuIFJlcXVpcmVkIGZv
ciBwb3dlciBzaW5rIGFuZCBwb3dlciBkdWFsIHJvbGUuDQo+ID4gKy0gbWF4LXNuay1taWNyb3Zv
bHQ6IFRoZSBtYXggdm9sdGFnZSB0aGUgc2luayBjYW4gc3VwcG9ydCBpbiBtaWNybw0KPiA+ICt2
b2x0cywNCj4gPiArICByZXF1aXJlZCBmb3IgcG93ZXIgc2luayBhbmQgcG93ZXIgZHVhbCByb2xl
Lg0KPiA+ICstIG1heC1zbmstbWljcm9hbXA6IFRoZSBtYXggY3VycmVudCB0aGUgc2luayBjYW4g
c3VwcG9ydCBpbiBtaWNybw0KPiA+ICthbXBzLA0KPiA+ICsgIHJlcXVpcmVkIGZvciBwb3dlciBz
aW5rIGFuZCBwb3dlciBkdWFsIHJvbGUuDQo+ID4gKy0gbWF4LXNuay1taWNyb3dhdHQtaG91cnM6
IFRoZSBtYXggcG93ZXIgdGhlIHNpbmsgY2FuIHN1cHBvcnQgaW4NCj4gPiArbWljcm8NCj4gPiAr
ICBXYXR0LWhvdXJzLCByZXF1aXJlZCBmb3IgcG93ZXIgc2luayBhbmQgcG93ZXIgZHVhbCByb2xl
Lg0KPiA+ICstIG9wLXNuay1taWNyb3dhdHQtaG91cnM6IFNpbmsgcmVxdWlyZWQgb3BlcmF0aW5n
IHBvd2VyIGluIG1pY3JvDQo+ID4gK1dhdHQtaG91cnMsDQo+ID4gKyAgaWYgc291cmNlIG9mZmVy
ZWQgcG93ZXIgaXMgbGVzcyB0aGVuIGl0LCBDYXBhYmlsaXR5IE1pc21hdGNoIGlzDQo+ID4gK3Nl
dCwNCj4gPiArICByZXF1aXJlZCBmb3IgcG93ZXIgc2luayBhbmQgcG93ZXIgZHVhbCByb2xlLg0K
PiANCj4gTm9uZSBvZiB0aGVzZSBwcm9wZXJ0aWVzIGFyZSBwYXJ0IG9mIHRoZSBQRE8/DQoNClNv
cnJ5LCBhbGwgYWJvdmUgNCBwcm9wcyBhcmUgbm90IHJlcXVpcmVkIGFueSBtb3JlIHdpdGggbGF0
ZXN0IGNvZGUsDQpJIHdpbGwgcmVtb3ZlIHRoZW0uDQoNCkp1biBMaQ0K
---
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

RE: [PATCH v2 10/12] dt-bindings: connector: add properties for typec power delivery

[Jun Li]

> -----Original Message-----
> From: Rob Herring [mailto:robh@kernel.org]
> Sent: 2018年3月3日 6:39
> To: Andrzej Hajda <a.hajda@samsung.com>
> Cc: Jun Li <jun.li@nxp.com>; gregkh@linuxfoundation.org;
> heikki.krogerus@linux.intel.com; linux@roeck-us.net;
> mark.rutland@arm.com; yueyao@google.com; Peter Chen
> <peter.chen@nxp.com>; garsilva@embeddedor.com; o_leveque@orange.fr;
> shufan_lee@richtek.com; linux-usb@vger.kernel.org;
> devicetree@vger.kernel.org; dl-linux-imx <linux-imx@nxp.com>
> Subject: Re: [PATCH v2 10/12] dt-bindings: connector: add properties for
> typec power delivery
> 
> On Tue, Feb 27, 2018 at 09:41:19AM +0100, Andrzej Hajda wrote:
> > On 26.02.2018 12:49, Li Jun wrote:
> > > In case of usb-c-connector with power delivery support, add
> > > bingdings supported by current typec driver, so user can pass all
> > > those properties via dt.
> > >
> > > Signed-off-by: Li Jun <jun.li@nxp.com>
> > > ---
> > > Changes for v2:
> > > - Added typec properties are based on general usb connector bindings[1]
> > >   proposed by Andrzej Hajda.
> > > - Use the standard unit suffixes as defined in property-units.txt.
> > >
> > > [1]
> > >
> https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fp
> > >
> atchwork.kernel.org%2Fpatch%2F10231447%2F&data=02%7C01%7Cjun.li%
> 40nx
> > >
> p.com%7Ccea32589f3314488e18f08d5808e5aae%7C686ea1d3bc2b4c6fa92
> cd99c5
> > >
> c301635%7C0%7C1%7C636556271266469012&sdata=ANr1jeW8x8cy6CG6tz
> ACgj%2B
> > > FgNKl9DJbRpervFwaQKM%3D&reserved=0
> > >
> > >  .../bindings/connector/usb-connector.txt           | 43
> ++++++++++++++++++++++
> > >  1 file changed, 43 insertions(+)
> > >
> > > diff --git
> > > a/Documentation/devicetree/bindings/connector/usb-connector.txt
> > > b/Documentation/devicetree/bindings/connector/usb-connector.txt
> > > index e1463f1..242f6df 100644
> > > --- a/Documentation/devicetree/bindings/connector/usb-connector.txt
> > > +++ b/Documentation/devicetree/bindings/connector/usb-connector.txt
> > > @@ -15,6 +15,30 @@ Optional properties:
> > >  - type: size of the connector, should be specified in case of USB-A,
> USB-B
> > >    non-fullsize connectors: "mini", "micro".
> > >
> > > +Required properties for usb-c-connector with power delivery support:
> > > +- port-type: should be one of "source", "sink" or "dual".
> > > +- default-role: preferred power role if port-type is "dual"(drp),
> > > +should be
> > > +  "sink" or "source".
> >
> > Since port carries data and power, it would be better to explicitly
> > mention it in names of properties which can be ambiguous.
> > Maybe instead of 'port-type' you can use 'power-role', for example.
> > Other thing is that default-role is required only in case of DRP, so
> > maybe better would be to squash it in power-role, for example:
> >     power-role: should be on of "source", "sink", "dual-source",
> > "dual-sink", in case of dual roles suffix determines preferred role.
> >
> >
> > > +- src-pdos: An array of u32 with each entry providing supported
> > > +power
> > > +  source data object(PDO), the detailed bit definitions of PDO can
> > > +be found
> > > +  in "Universal Serial Bus Power Delivery Specification" chapter
> > > +6.4.1.2
> > > +  Source_Capabilities Message, the order of each entry(PDO) should
> > > +follow
> > > +  the PD spec chapter 6.4.1. Required for power source and power dual
> role.
> > > +- snk-pdos: An array of u32 with each entry providing supported
> > > +power
> > > +  sink data object(PDO), the detailed bit definitions of PDO can be
> > > +found in
> > > +  "Universal Serial Bus Power Delivery Specification" chapter
> > > +6.4.1.3 Sink
> > > +  Capabilities Message, the order of each entry(PDO) should follow
> > > +the PD
> > > +  spec chapter 6.4.1. Required for power sink and power dual role.
> >
> > We should avoid magic numbers, magic numbers are bad :)
> 
> I don't mind if there's a defined format for the data.
> 

Yes, there is defined format in spec for this data.

> > If we really need to use PDOs here, I think we can re-use PDO_* macros
> > [1] - DTC should be able to parse it, maybe some lifting will be necessary.
> >
> > [1]:
> >
> https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Feli
> >
> xir.bootlin.com%2Flinux%2Fv4.16-rc3%2Fsource%2Finclude%2Flinux%2Fusb
> %2
> >
> Fpd.h%23L161&data=02%7C01%7Cjun.li%40nxp.com%7Ccea32589f3314488
> e18f08d
> >
> 5808e5aae%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C1%7C636556
> 271266469
> >
> 012&sdata=rebFCafzTpqI7FyYk9ZgW2nIhJ0ca5IB%2BBUa7WC05lM%3D&res
> erved=0
> > > +- max-snk-microvolt: The max voltage the sink can support in micro
> > > +volts,
> > > +  required for power sink and power dual role.
> > > +- max-snk-microamp: The max current the sink can support in micro
> > > +amps,
> > > +  required for power sink and power dual role.
> > > +- max-snk-microwatt-hours: The max power the sink can support in
> > > +micro
> > > +  Watt-hours, required for power sink and power dual role.
> > > +- op-snk-microwatt-hours: Sink required operating power in micro
> > > +Watt-hours,
> > > +  if source offered power is less then it, Capability Mismatch is
> > > +set,
> > > +  required for power sink and power dual role.
> >
> > What is the relation between above properties and PDOs specified earlier?
> > Are you sure all these props are required?
> >
> > And general remark regarding all above properties. For me, most of
> > them are specific not to the port but to devices responsible for power
> > management: chargers, pmics,....
> > In many cases these properties are redundant with devices capabilities.
> > On the other side I guess in many cases it may be convenient to put
> > them here, so I am not sure what is better :)
> 
> I debated that too, but decided if you had 2 connectors connected to a
> single power controller, then you'd want these in the connector.
> 

The standard typec port controller(tcpci) can only manage one typec port
(connector), so in my case, those props should be applied to the typec
controller, if only for power, connector child node is not required.
I will move those typec props descriptions to a separate file:
(Documentation/devicetree/bindings/usb/tyepc.txt)

> Rob

[v2,10/12] dt-bindings: connector: add properties for typec power delivery

[Jun Li]

> -----Original Message-----
> From: Rob Herring [mailto:robh@kernel.org]
> Sent: 2018年3月3日 6:39
> To: Andrzej Hajda <a.hajda@samsung.com>
> Cc: Jun Li <jun.li@nxp.com>; gregkh@linuxfoundation.org;
> heikki.krogerus@linux.intel.com; linux@roeck-us.net;
> mark.rutland@arm.com; yueyao@google.com; Peter Chen
> <peter.chen@nxp.com>; garsilva@embeddedor.com; o_leveque@orange.fr;
> shufan_lee@richtek.com; linux-usb@vger.kernel.org;
> devicetree@vger.kernel.org; dl-linux-imx <linux-imx@nxp.com>
> Subject: Re: [PATCH v2 10/12] dt-bindings: connector: add properties for
> typec power delivery
> 
> On Tue, Feb 27, 2018 at 09:41:19AM +0100, Andrzej Hajda wrote:
> > On 26.02.2018 12:49, Li Jun wrote:
> > > In case of usb-c-connector with power delivery support, add
> > > bingdings supported by current typec driver, so user can pass all
> > > those properties via dt.
> > >
> > > Signed-off-by: Li Jun <jun.li@nxp.com>
> > > ---
> > > Changes for v2:
> > > - Added typec properties are based on general usb connector bindings[1]
> > >   proposed by Andrzej Hajda.
> > > - Use the standard unit suffixes as defined in property-units.txt.
> > >
> > > [1]
> > >
> https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fp
> > >
> atchwork.kernel.org%2Fpatch%2F10231447%2F&data=02%7C01%7Cjun.li%
> 40nx
> > >
> p.com%7Ccea32589f3314488e18f08d5808e5aae%7C686ea1d3bc2b4c6fa92
> cd99c5
> > >
> c301635%7C0%7C1%7C636556271266469012&sdata=ANr1jeW8x8cy6CG6tz
> ACgj%2B
> > > FgNKl9DJbRpervFwaQKM%3D&reserved=0
> > >
> > >  .../bindings/connector/usb-connector.txt           | 43
> ++++++++++++++++++++++
> > >  1 file changed, 43 insertions(+)
> > >
> > > diff --git
> > > a/Documentation/devicetree/bindings/connector/usb-connector.txt
> > > b/Documentation/devicetree/bindings/connector/usb-connector.txt
> > > index e1463f1..242f6df 100644
> > > --- a/Documentation/devicetree/bindings/connector/usb-connector.txt
> > > +++ b/Documentation/devicetree/bindings/connector/usb-connector.txt
> > > @@ -15,6 +15,30 @@ Optional properties:
> > >  - type: size of the connector, should be specified in case of USB-A,
> USB-B
> > >    non-fullsize connectors: "mini", "micro".
> > >
> > > +Required properties for usb-c-connector with power delivery support:
> > > +- port-type: should be one of "source", "sink" or "dual".
> > > +- default-role: preferred power role if port-type is "dual"(drp),
> > > +should be
> > > +  "sink" or "source".
> >
> > Since port carries data and power, it would be better to explicitly
> > mention it in names of properties which can be ambiguous.
> > Maybe instead of 'port-type' you can use 'power-role', for example.
> > Other thing is that default-role is required only in case of DRP, so
> > maybe better would be to squash it in power-role, for example:
> >     power-role: should be on of "source", "sink", "dual-source",
> > "dual-sink", in case of dual roles suffix determines preferred role.
> >
> >
> > > +- src-pdos: An array of u32 with each entry providing supported
> > > +power
> > > +  source data object(PDO), the detailed bit definitions of PDO can
> > > +be found
> > > +  in "Universal Serial Bus Power Delivery Specification" chapter
> > > +6.4.1.2
> > > +  Source_Capabilities Message, the order of each entry(PDO) should
> > > +follow
> > > +  the PD spec chapter 6.4.1. Required for power source and power dual
> role.
> > > +- snk-pdos: An array of u32 with each entry providing supported
> > > +power
> > > +  sink data object(PDO), the detailed bit definitions of PDO can be
> > > +found in
> > > +  "Universal Serial Bus Power Delivery Specification" chapter
> > > +6.4.1.3 Sink
> > > +  Capabilities Message, the order of each entry(PDO) should follow
> > > +the PD
> > > +  spec chapter 6.4.1. Required for power sink and power dual role.
> >
> > We should avoid magic numbers, magic numbers are bad :)
> 
> I don't mind if there's a defined format for the data.
> 

Yes, there is defined format in spec for this data.

> > If we really need to use PDOs here, I think we can re-use PDO_* macros
> > [1] - DTC should be able to parse it, maybe some lifting will be necessary.
> >
> > [1]:
> >
> https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Feli
> >
> xir.bootlin.com%2Flinux%2Fv4.16-rc3%2Fsource%2Finclude%2Flinux%2Fusb
> %2
> >
> Fpd.h%23L161&data=02%7C01%7Cjun.li%40nxp.com%7Ccea32589f3314488
> e18f08d
> >
> 5808e5aae%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C1%7C636556
> 271266469
> >
> 012&sdata=rebFCafzTpqI7FyYk9ZgW2nIhJ0ca5IB%2BBUa7WC05lM%3D&res
> erved=0
> > > +- max-snk-microvolt: The max voltage the sink can support in micro
> > > +volts,
> > > +  required for power sink and power dual role.
> > > +- max-snk-microamp: The max current the sink can support in micro
> > > +amps,
> > > +  required for power sink and power dual role.
> > > +- max-snk-microwatt-hours: The max power the sink can support in
> > > +micro
> > > +  Watt-hours, required for power sink and power dual role.
> > > +- op-snk-microwatt-hours: Sink required operating power in micro
> > > +Watt-hours,
> > > +  if source offered power is less then it, Capability Mismatch is
> > > +set,
> > > +  required for power sink and power dual role.
> >
> > What is the relation between above properties and PDOs specified earlier?
> > Are you sure all these props are required?
> >
> > And general remark regarding all above properties. For me, most of
> > them are specific not to the port but to devices responsible for power
> > management: chargers, pmics,....
> > In many cases these properties are redundant with devices capabilities.
> > On the other side I guess in many cases it may be convenient to put
> > them here, so I am not sure what is better :)
> 
> I debated that too, but decided if you had 2 connectors connected to a
> single power controller, then you'd want these in the connector.
> 

The standard typec port controller(tcpci) can only manage one typec port
(connector), so in my case, those props should be applied to the typec
controller, if only for power, connector child node is not required.
I will move those typec props descriptions to a separate file:
(Documentation/devicetree/bindings/usb/tyepc.txt)

> Rob

RE: [PATCH v2 01/12] usb: typec: add API to get port type and preferred role

[Jun Li]

> -----Original Message-----
> From: Heikki Krogerus [mailto:heikki.krogerus@linux.intel.com]
> Sent: 2018年2月26日 21:19
> To: Jun Li <jun.li@nxp.com>
> Cc: gregkh@linuxfoundation.org; robh+dt@kernel.org; linux@roeck-us.net;
> a.hajda@samsung.com; mark.rutland@arm.com; yueyao@google.com;
> Peter Chen <peter.chen@nxp.com>; garsilva@embeddedor.com;
> o_leveque@orange.fr; shufan_lee@richtek.com; linux-usb@vger.kernel.org;
> devicetree@vger.kernel.org; dl-linux-imx <linux-imx@nxp.com>
> Subject: Re: [PATCH v2 01/12] usb: typec: add API to get port type and
> preferred role
> 
> On Mon, Feb 26, 2018 at 07:49:08PM +0800, Li Jun wrote:
> > This patch add 2 APIs to get port type and preferred role from
> > firmware description.
> >
> > Signed-off-by: Li Jun <jun.li@nxp.com>
> >
> > ---
> > change for v2
> > - Change the 2 APIs name and input para to be device_node pointer.
> 
> Why?
> 
> You are only dealing with device properties here, so please move back to
> using the unified device property API.
> 

Will change it back in next version.

> >  drivers/usb/typec/typec.c | 46
> > ++++++++++++++++++++++++++++++++++++++++++++++
> >  include/linux/usb/typec.h |  2 ++
> >  2 files changed, 48 insertions(+)
> >
> > diff --git a/drivers/usb/typec/typec.c b/drivers/usb/typec/typec.c
> > index 735726c..e7b2802 100644
> > --- a/drivers/usb/typec/typec.c
> > +++ b/drivers/usb/typec/typec.c
> > @@ -9,6 +9,7 @@
> >  #include <linux/device.h>
> >  #include <linux/module.h>
> >  #include <linux/mutex.h>
> > +#include <linux/of.h>
> 
> No need for that.
> 
> >  #include <linux/slab.h>
> >  #include <linux/usb/typec.h>
> >
> > @@ -1246,6 +1247,51 @@ void typec_set_pwr_opmode(struct typec_port
> > *port,  }  EXPORT_SYMBOL_GPL(typec_set_pwr_opmode);
> >
> > +/**
> > + * typec_of_get_port_type - Get the typec port type
> > + * @np: device node from which the property value is to be read.
> > + *
> > + * This routine is used by typec hardware driver to read property
> > +port type
> > + * from the device firmware description.
> > + *
> > + * Returns typec_port_type if success, otherwise negative error code.
> > + */
> > +int typec_of_get_port_type(struct device_node *np)
> 
> int typec_get_port_type(struct device *dev)
> 
> I would expect you to have the function like that even if you really were
> calling of_* functions in it so we would not need to change the API later
> once support for ACPI or some other type of FW interface is added. But as
> said, that will not be the case, and you need to use
> device_property_* functions instead.
> 
> > +{
> > +	const char *type_str;
> > +	int ret;
> > +
> > +	ret = of_property_read_string(np, "port-type", &type_str);
> 
> ret = device_property_read_string(dev, "port-type", &type_str);
> 
> > +	if (ret < 0)
> > +		return ret;
> > +
> > +	return match_string(typec_port_types, ARRAY_SIZE(typec_port_types),
> > +								 type_str);
> > +}
> > +EXPORT_SYMBOL_GPL(typec_get_port_type);
> 
> Note that you are still exporting the old function name, but that's fine. Just
> change the function name back to the original.
> 

will change it back.

> > +/**
> > + * typec_of_get_preferred_role - Get the typec preferred role
> > + * @np: device node from which the property value is to be read.
> > + *
> > + * This routine is used by typec hardware driver to read property
> > +default role
> > + * from the device firmware description.
> > + *
> > + * Returns typec_role if success, otherwise negative error code.
> > + */
> > +int typec_of_get_preferred_role(struct device_node *np)
> 
> int typec_get_preferred_role(struct device dev)
> 
> > +{
> > +	const char *power_str;
> > +	int ret;
> > +
> > +	ret = of_property_read_string(np, "default-role", &power_str);
> 
> ret = device_property_read_string(dev, "default-role", &type_str);
> 
> > +	if (ret < 0)
> > +		return ret;
> > +
> > +	return match_string(typec_roles, ARRAY_SIZE(typec_roles),
> > +power_str); } EXPORT_SYMBOL_GPL(typec_get_preferred_role);
> > +
> >  /* --------------------------------------- */
> 
> Thanks,
> 
> --
> heikki

[v2,01/12] usb: typec: add API to get port type and preferred role

[Jun Li]

DQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IEhlaWtraSBLcm9nZXJ1cyBb
bWFpbHRvOmhlaWtraS5rcm9nZXJ1c0BsaW51eC5pbnRlbC5jb21dDQo+IFNlbnQ6IDIwMTjE6jLU
wjI2yNUgMjE6MTkNCj4gVG86IEp1biBMaSA8anVuLmxpQG54cC5jb20+DQo+IENjOiBncmVna2hA
bGludXhmb3VuZGF0aW9uLm9yZzsgcm9iaCtkdEBrZXJuZWwub3JnOyBsaW51eEByb2Vjay11cy5u
ZXQ7DQo+IGEuaGFqZGFAc2Ftc3VuZy5jb207IG1hcmsucnV0bGFuZEBhcm0uY29tOyB5dWV5YW9A
Z29vZ2xlLmNvbTsNCj4gUGV0ZXIgQ2hlbiA8cGV0ZXIuY2hlbkBueHAuY29tPjsgZ2Fyc2lsdmFA
ZW1iZWRkZWRvci5jb207DQo+IG9fbGV2ZXF1ZUBvcmFuZ2UuZnI7IHNodWZhbl9sZWVAcmljaHRl
ay5jb207IGxpbnV4LXVzYkB2Z2VyLmtlcm5lbC5vcmc7DQo+IGRldmljZXRyZWVAdmdlci5rZXJu
ZWwub3JnOyBkbC1saW51eC1pbXggPGxpbnV4LWlteEBueHAuY29tPg0KPiBTdWJqZWN0OiBSZTog
W1BBVENIIHYyIDAxLzEyXSB1c2I6IHR5cGVjOiBhZGQgQVBJIHRvIGdldCBwb3J0IHR5cGUgYW5k
DQo+IHByZWZlcnJlZCByb2xlDQo+IA0KPiBPbiBNb24sIEZlYiAyNiwgMjAxOCBhdCAwNzo0OTow
OFBNICswODAwLCBMaSBKdW4gd3JvdGU6DQo+ID4gVGhpcyBwYXRjaCBhZGQgMiBBUElzIHRvIGdl
dCBwb3J0IHR5cGUgYW5kIHByZWZlcnJlZCByb2xlIGZyb20NCj4gPiBmaXJtd2FyZSBkZXNjcmlw
dGlvbi4NCj4gPg0KPiA+IFNpZ25lZC1vZmYtYnk6IExpIEp1biA8anVuLmxpQG54cC5jb20+DQo+
ID4NCj4gPiAtLS0NCj4gPiBjaGFuZ2UgZm9yIHYyDQo+ID4gLSBDaGFuZ2UgdGhlIDIgQVBJcyBu
YW1lIGFuZCBpbnB1dCBwYXJhIHRvIGJlIGRldmljZV9ub2RlIHBvaW50ZXIuDQo+IA0KPiBXaHk/
DQo+IA0KPiBZb3UgYXJlIG9ubHkgZGVhbGluZyB3aXRoIGRldmljZSBwcm9wZXJ0aWVzIGhlcmUs
IHNvIHBsZWFzZSBtb3ZlIGJhY2sgdG8NCj4gdXNpbmcgdGhlIHVuaWZpZWQgZGV2aWNlIHByb3Bl
cnR5IEFQSS4NCj4gDQoNCldpbGwgY2hhbmdlIGl0IGJhY2sgaW4gbmV4dCB2ZXJzaW9uLg0KDQo+
ID4gIGRyaXZlcnMvdXNiL3R5cGVjL3R5cGVjLmMgfCA0Ng0KPiA+ICsrKysrKysrKysrKysrKysr
KysrKysrKysrKysrKysrKysrKysrKysrKysrKysNCj4gPiAgaW5jbHVkZS9saW51eC91c2IvdHlw
ZWMuaCB8ICAyICsrDQo+ID4gIDIgZmlsZXMgY2hhbmdlZCwgNDggaW5zZXJ0aW9ucygrKQ0KPiA+
DQo+ID4gZGlmZiAtLWdpdCBhL2RyaXZlcnMvdXNiL3R5cGVjL3R5cGVjLmMgYi9kcml2ZXJzL3Vz
Yi90eXBlYy90eXBlYy5jDQo+ID4gaW5kZXggNzM1NzI2Yy4uZTdiMjgwMiAxMDA2NDQNCj4gPiAt
LS0gYS9kcml2ZXJzL3VzYi90eXBlYy90eXBlYy5jDQo+ID4gKysrIGIvZHJpdmVycy91c2IvdHlw
ZWMvdHlwZWMuYw0KPiA+IEBAIC05LDYgKzksNyBAQA0KPiA+ICAjaW5jbHVkZSA8bGludXgvZGV2
aWNlLmg+DQo+ID4gICNpbmNsdWRlIDxsaW51eC9tb2R1bGUuaD4NCj4gPiAgI2luY2x1ZGUgPGxp
bnV4L211dGV4Lmg+DQo+ID4gKyNpbmNsdWRlIDxsaW51eC9vZi5oPg0KPiANCj4gTm8gbmVlZCBm
b3IgdGhhdC4NCj4gDQo+ID4gICNpbmNsdWRlIDxsaW51eC9zbGFiLmg+DQo+ID4gICNpbmNsdWRl
IDxsaW51eC91c2IvdHlwZWMuaD4NCj4gPg0KPiA+IEBAIC0xMjQ2LDYgKzEyNDcsNTEgQEAgdm9p
ZCB0eXBlY19zZXRfcHdyX29wbW9kZShzdHJ1Y3QgdHlwZWNfcG9ydA0KPiA+ICpwb3J0LCAgfSAg
RVhQT1JUX1NZTUJPTF9HUEwodHlwZWNfc2V0X3B3cl9vcG1vZGUpOw0KPiA+DQo+ID4gKy8qKg0K
PiA+ICsgKiB0eXBlY19vZl9nZXRfcG9ydF90eXBlIC0gR2V0IHRoZSB0eXBlYyBwb3J0IHR5cGUN
Cj4gPiArICogQG5wOiBkZXZpY2Ugbm9kZSBmcm9tIHdoaWNoIHRoZSBwcm9wZXJ0eSB2YWx1ZSBp
cyB0byBiZSByZWFkLg0KPiA+ICsgKg0KPiA+ICsgKiBUaGlzIHJvdXRpbmUgaXMgdXNlZCBieSB0
eXBlYyBoYXJkd2FyZSBkcml2ZXIgdG8gcmVhZCBwcm9wZXJ0eQ0KPiA+ICtwb3J0IHR5cGUNCj4g
PiArICogZnJvbSB0aGUgZGV2aWNlIGZpcm13YXJlIGRlc2NyaXB0aW9uLg0KPiA+ICsgKg0KPiA+
ICsgKiBSZXR1cm5zIHR5cGVjX3BvcnRfdHlwZSBpZiBzdWNjZXNzLCBvdGhlcndpc2UgbmVnYXRp
dmUgZXJyb3IgY29kZS4NCj4gPiArICovDQo+ID4gK2ludCB0eXBlY19vZl9nZXRfcG9ydF90eXBl
KHN0cnVjdCBkZXZpY2Vfbm9kZSAqbnApDQo+IA0KPiBpbnQgdHlwZWNfZ2V0X3BvcnRfdHlwZShz
dHJ1Y3QgZGV2aWNlICpkZXYpDQo+IA0KPiBJIHdvdWxkIGV4cGVjdCB5b3UgdG8gaGF2ZSB0aGUg
ZnVuY3Rpb24gbGlrZSB0aGF0IGV2ZW4gaWYgeW91IHJlYWxseSB3ZXJlDQo+IGNhbGxpbmcgb2Zf
KiBmdW5jdGlvbnMgaW4gaXQgc28gd2Ugd291bGQgbm90IG5lZWQgdG8gY2hhbmdlIHRoZSBBUEkg
bGF0ZXINCj4gb25jZSBzdXBwb3J0IGZvciBBQ1BJIG9yIHNvbWUgb3RoZXIgdHlwZSBvZiBGVyBp
bnRlcmZhY2UgaXMgYWRkZWQuIEJ1dCBhcw0KPiBzYWlkLCB0aGF0IHdpbGwgbm90IGJlIHRoZSBj
YXNlLCBhbmQgeW91IG5lZWQgdG8gdXNlDQo+IGRldmljZV9wcm9wZXJ0eV8qIGZ1bmN0aW9ucyBp
bnN0ZWFkLg0KPiANCj4gPiArew0KPiA+ICsJY29uc3QgY2hhciAqdHlwZV9zdHI7DQo+ID4gKwlp
bnQgcmV0Ow0KPiA+ICsNCj4gPiArCXJldCA9IG9mX3Byb3BlcnR5X3JlYWRfc3RyaW5nKG5wLCAi
cG9ydC10eXBlIiwgJnR5cGVfc3RyKTsNCj4gDQo+IHJldCA9IGRldmljZV9wcm9wZXJ0eV9yZWFk
X3N0cmluZyhkZXYsICJwb3J0LXR5cGUiLCAmdHlwZV9zdHIpOw0KPiANCj4gPiArCWlmIChyZXQg
PCAwKQ0KPiA+ICsJCXJldHVybiByZXQ7DQo+ID4gKw0KPiA+ICsJcmV0dXJuIG1hdGNoX3N0cmlu
Zyh0eXBlY19wb3J0X3R5cGVzLCBBUlJBWV9TSVpFKHR5cGVjX3BvcnRfdHlwZXMpLA0KPiA+ICsJ
CQkJCQkJCSB0eXBlX3N0cik7DQo+ID4gK30NCj4gPiArRVhQT1JUX1NZTUJPTF9HUEwodHlwZWNf
Z2V0X3BvcnRfdHlwZSk7DQo+IA0KPiBOb3RlIHRoYXQgeW91IGFyZSBzdGlsbCBleHBvcnRpbmcg
dGhlIG9sZCBmdW5jdGlvbiBuYW1lLCBidXQgdGhhdCdzIGZpbmUuIEp1c3QNCj4gY2hhbmdlIHRo
ZSBmdW5jdGlvbiBuYW1lIGJhY2sgdG8gdGhlIG9yaWdpbmFsLg0KPiANCg0Kd2lsbCBjaGFuZ2Ug
aXQgYmFjay4NCg0KPiA+ICsvKioNCj4gPiArICogdHlwZWNfb2ZfZ2V0X3ByZWZlcnJlZF9yb2xl
IC0gR2V0IHRoZSB0eXBlYyBwcmVmZXJyZWQgcm9sZQ0KPiA+ICsgKiBAbnA6IGRldmljZSBub2Rl
IGZyb20gd2hpY2ggdGhlIHByb3BlcnR5IHZhbHVlIGlzIHRvIGJlIHJlYWQuDQo+ID4gKyAqDQo+
ID4gKyAqIFRoaXMgcm91dGluZSBpcyB1c2VkIGJ5IHR5cGVjIGhhcmR3YXJlIGRyaXZlciB0byBy
ZWFkIHByb3BlcnR5DQo+ID4gK2RlZmF1bHQgcm9sZQ0KPiA+ICsgKiBmcm9tIHRoZSBkZXZpY2Ug
ZmlybXdhcmUgZGVzY3JpcHRpb24uDQo+ID4gKyAqDQo+ID4gKyAqIFJldHVybnMgdHlwZWNfcm9s
ZSBpZiBzdWNjZXNzLCBvdGhlcndpc2UgbmVnYXRpdmUgZXJyb3IgY29kZS4NCj4gPiArICovDQo+
ID4gK2ludCB0eXBlY19vZl9nZXRfcHJlZmVycmVkX3JvbGUoc3RydWN0IGRldmljZV9ub2RlICpu
cCkNCj4gDQo+IGludCB0eXBlY19nZXRfcHJlZmVycmVkX3JvbGUoc3RydWN0IGRldmljZSBkZXYp
DQo+IA0KPiA+ICt7DQo+ID4gKwljb25zdCBjaGFyICpwb3dlcl9zdHI7DQo+ID4gKwlpbnQgcmV0
Ow0KPiA+ICsNCj4gPiArCXJldCA9IG9mX3Byb3BlcnR5X3JlYWRfc3RyaW5nKG5wLCAiZGVmYXVs
dC1yb2xlIiwgJnBvd2VyX3N0cik7DQo+IA0KPiByZXQgPSBkZXZpY2VfcHJvcGVydHlfcmVhZF9z
dHJpbmcoZGV2LCAiZGVmYXVsdC1yb2xlIiwgJnR5cGVfc3RyKTsNCj4gDQo+ID4gKwlpZiAocmV0
IDwgMCkNCj4gPiArCQlyZXR1cm4gcmV0Ow0KPiA+ICsNCj4gPiArCXJldHVybiBtYXRjaF9zdHJp
bmcodHlwZWNfcm9sZXMsIEFSUkFZX1NJWkUodHlwZWNfcm9sZXMpLA0KPiA+ICtwb3dlcl9zdHIp
OyB9IEVYUE9SVF9TWU1CT0xfR1BMKHR5cGVjX2dldF9wcmVmZXJyZWRfcm9sZSk7DQo+ID4gKw0K
PiA+ICAvKiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0gKi8NCj4gDQo+
IFRoYW5rcywNCj4gDQo+IC0tDQo+IGhlaWtraQ0K
---
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

RE: [PATCH v2 02/12] usb: typec: add API to get sink and source config

[Jun Li]

> -----Original Message-----
> From: Heikki Krogerus [mailto:heikki.krogerus@linux.intel.com]
> Sent: 2018年2月26日 21:32
> To: Jun Li <jun.li@nxp.com>
> Cc: gregkh@linuxfoundation.org; robh+dt@kernel.org; linux@roeck-us.net;
> a.hajda@samsung.com; mark.rutland@arm.com; yueyao@google.com;
> Peter Chen <peter.chen@nxp.com>; garsilva@embeddedor.com;
> o_leveque@orange.fr; shufan_lee@richtek.com; linux-usb@vger.kernel.org;
> devicetree@vger.kernel.org; dl-linux-imx <linux-imx@nxp.com>
> Subject: Re: [PATCH v2 02/12] usb: typec: add API to get sink and source
> config
> 
> Hi,
> 
> On Mon, Feb 26, 2018 at 07:49:09PM +0800, Li Jun wrote:
> > This patch add 2 APIs to get sink and source power config from
> > firmware description.
> >
> > Signed-off-by: Li Jun <jun.li@nxp.com>
> > ---
> >  drivers/usb/typec/tcpm.c | 43
> > +++++++++++++++++++++++++++++++++++++++++++
> >  include/linux/usb/tcpm.h |  2 ++
> >  2 files changed, 45 insertions(+)
> >
> > diff --git a/drivers/usb/typec/tcpm.c b/drivers/usb/typec/tcpm.c index
> > f4d563e..409f1d0 100644
> > --- a/drivers/usb/typec/tcpm.c
> > +++ b/drivers/usb/typec/tcpm.c
> > @@ -12,6 +12,7 @@
> >  #include <linux/kernel.h>
> >  #include <linux/module.h>
> >  #include <linux/mutex.h>
> > +#include <linux/of.h>
> 
> No need for that. There is nothing DT only specific here.
> 
> As in 01/12, you only have device properties here, so use the unified device
> property API instead of of_property_* functions.

I will use device property API, also as the below sink props:
"max-snk-microvolt"
"max-snk-microamp"
"max-snk-microwatt-hours"
"op-snk-microwatt-hours"
are redundant now, only PDO is required, I will combine the below 2 APIs
to be one:
int tcpm_get_pdos(struct device *dev, bool sink, struct tcpc_config *tcfg)

Jun Li
> 
> >  #include <linux/proc_fs.h>
> >  #include <linux/sched/clock.h>
> >  #include <linux/seq_file.h>
> > @@ -3589,6 +3590,48 @@ static int tcpm_copy_vdos(u32 *dest_vdo,
> const u32 *src_vdo,
> >  	return nr_vdo;
> >  }
> >
> > +int tcpm_of_get_src_config(struct device_node *np, struct tcpc_config
> > +*tcfg) {
> > +	int ret;
> > +
> > +	ret = of_property_read_variable_u32_array(np, "src-pdos",
> > +				tcfg->src_pdo, 1, PDO_MAX_OBJECTS);
> > +	if (ret > 0)
> > +		tcfg->nr_src_pdo = ret;
> > +
> > +	return ret;
> > +}
> > +EXPORT_SYMBOL_GPL(tcpm_of_get_pdos);
> > +
> > +int tcpm_of_get_snk_config(struct device_node *np, struct tcpc_config
> > +*tcfg) {
> > +	int ret;
> > +
> > +	ret = of_property_read_variable_u32_array(np, "snk-pdos",
> > +				tcfg->snk_pdo, 1, PDO_MAX_OBJECTS);
> > +	if (ret > 0)
> > +		tcfg->nr_snk_pdo = ret;
> > +	else
> > +		return ret;
> > +
> > +	ret = of_property_read_u32(np, "max-snk-microvolt",
> &tcfg->max_snk_mv);
> > +	if (ret)
> > +		return ret;
> > +
> > +	ret = of_property_read_u32(np, "max-snk-microamp",
> &tcfg->max_snk_ma);
> > +	if (ret)
> > +		return ret;
> > +
> > +	ret = of_property_read_u32(np, "max-snk-microwatt-hours",
> > +				   &tcfg->max_snk_mw);
> > +	if (ret)
> > +		return ret;
> > +
> > +	return of_property_read_u32(np, "op-snk-microwatt-hours",
> > +				    &tcfg->operating_snk_mw);
> > +}
> > +EXPORT_SYMBOL_GPL(tcpm_of_get_pdos);
> > +
> >  int tcpm_update_source_capabilities(struct tcpm_port *port, const u32
> *pdo,
> >  				    unsigned int nr_pdo)
> >  {
> > diff --git a/include/linux/usb/tcpm.h b/include/linux/usb/tcpm.h index
> > ca1c0b5..962eff1 100644
> > --- a/include/linux/usb/tcpm.h
> > +++ b/include/linux/usb/tcpm.h
> > @@ -191,6 +191,8 @@ int tcpm_update_sink_capabilities(struct
> tcpm_port *port, const u32 *pdo,
> >  				  unsigned int max_snk_ma,
> >  				  unsigned int max_snk_mw,
> >  				  unsigned int operating_snk_mw);
> > +int tcpm_of_get_src_config(struct device_node *np, struct tcpc_config
> > +*tcfg); int tcpm_of_get_snk_config(struct device_node *np, struct
> > +tcpc_config *tcfg);
> >
> >  void tcpm_vbus_change(struct tcpm_port *port);  void
> > tcpm_cc_change(struct tcpm_port *port);
> 
> Thanks,
> 
> --
> heikki

[v2,02/12] usb: typec: add API to get sink and source config

[Jun Li]

> -----Original Message-----
> From: Heikki Krogerus [mailto:heikki.krogerus@linux.intel.com]
> Sent: 2018年2月26日 21:32
> To: Jun Li <jun.li@nxp.com>
> Cc: gregkh@linuxfoundation.org; robh+dt@kernel.org; linux@roeck-us.net;
> a.hajda@samsung.com; mark.rutland@arm.com; yueyao@google.com;
> Peter Chen <peter.chen@nxp.com>; garsilva@embeddedor.com;
> o_leveque@orange.fr; shufan_lee@richtek.com; linux-usb@vger.kernel.org;
> devicetree@vger.kernel.org; dl-linux-imx <linux-imx@nxp.com>
> Subject: Re: [PATCH v2 02/12] usb: typec: add API to get sink and source
> config
> 
> Hi,
> 
> On Mon, Feb 26, 2018 at 07:49:09PM +0800, Li Jun wrote:
> > This patch add 2 APIs to get sink and source power config from
> > firmware description.
> >
> > Signed-off-by: Li Jun <jun.li@nxp.com>
> > ---
> >  drivers/usb/typec/tcpm.c | 43
> > +++++++++++++++++++++++++++++++++++++++++++
> >  include/linux/usb/tcpm.h |  2 ++
> >  2 files changed, 45 insertions(+)
> >
> > diff --git a/drivers/usb/typec/tcpm.c b/drivers/usb/typec/tcpm.c index
> > f4d563e..409f1d0 100644
> > --- a/drivers/usb/typec/tcpm.c
> > +++ b/drivers/usb/typec/tcpm.c
> > @@ -12,6 +12,7 @@
> >  #include <linux/kernel.h>
> >  #include <linux/module.h>
> >  #include <linux/mutex.h>
> > +#include <linux/of.h>
> 
> No need for that. There is nothing DT only specific here.
> 
> As in 01/12, you only have device properties here, so use the unified device
> property API instead of of_property_* functions.

I will use device property API, also as the below sink props:
"max-snk-microvolt"
"max-snk-microamp"
"max-snk-microwatt-hours"
"op-snk-microwatt-hours"
are redundant now, only PDO is required, I will combine the below 2 APIs
to be one:
int tcpm_get_pdos(struct device *dev, bool sink, struct tcpc_config *tcfg)

Jun Li
> 
> >  #include <linux/proc_fs.h>
> >  #include <linux/sched/clock.h>
> >  #include <linux/seq_file.h>
> > @@ -3589,6 +3590,48 @@ static int tcpm_copy_vdos(u32 *dest_vdo,
> const u32 *src_vdo,
> >  	return nr_vdo;
> >  }
> >
> > +int tcpm_of_get_src_config(struct device_node *np, struct tcpc_config
> > +*tcfg) {
> > +	int ret;
> > +
> > +	ret = of_property_read_variable_u32_array(np, "src-pdos",
> > +				tcfg->src_pdo, 1, PDO_MAX_OBJECTS);
> > +	if (ret > 0)
> > +		tcfg->nr_src_pdo = ret;
> > +
> > +	return ret;
> > +}
> > +EXPORT_SYMBOL_GPL(tcpm_of_get_pdos);
> > +
> > +int tcpm_of_get_snk_config(struct device_node *np, struct tcpc_config
> > +*tcfg) {
> > +	int ret;
> > +
> > +	ret = of_property_read_variable_u32_array(np, "snk-pdos",
> > +				tcfg->snk_pdo, 1, PDO_MAX_OBJECTS);
> > +	if (ret > 0)
> > +		tcfg->nr_snk_pdo = ret;
> > +	else
> > +		return ret;
> > +
> > +	ret = of_property_read_u32(np, "max-snk-microvolt",
> &tcfg->max_snk_mv);
> > +	if (ret)
> > +		return ret;
> > +
> > +	ret = of_property_read_u32(np, "max-snk-microamp",
> &tcfg->max_snk_ma);
> > +	if (ret)
> > +		return ret;
> > +
> > +	ret = of_property_read_u32(np, "max-snk-microwatt-hours",
> > +				   &tcfg->max_snk_mw);
> > +	if (ret)
> > +		return ret;
> > +
> > +	return of_property_read_u32(np, "op-snk-microwatt-hours",
> > +				    &tcfg->operating_snk_mw);
> > +}
> > +EXPORT_SYMBOL_GPL(tcpm_of_get_pdos);
> > +
> >  int tcpm_update_source_capabilities(struct tcpm_port *port, const u32
> *pdo,
> >  				    unsigned int nr_pdo)
> >  {
> > diff --git a/include/linux/usb/tcpm.h b/include/linux/usb/tcpm.h index
> > ca1c0b5..962eff1 100644
> > --- a/include/linux/usb/tcpm.h
> > +++ b/include/linux/usb/tcpm.h
> > @@ -191,6 +191,8 @@ int tcpm_update_sink_capabilities(struct
> tcpm_port *port, const u32 *pdo,
> >  				  unsigned int max_snk_ma,
> >  				  unsigned int max_snk_mw,
> >  				  unsigned int operating_snk_mw);
> > +int tcpm_of_get_src_config(struct device_node *np, struct tcpc_config
> > +*tcfg); int tcpm_of_get_snk_config(struct device_node *np, struct
> > +tcpc_config *tcfg);
> >
> >  void tcpm_vbus_change(struct tcpm_port *port);  void
> > tcpm_cc_change(struct tcpm_port *port);
> 
> Thanks,
> 
> --
> heikki

RE: [PATCH v2 03/12] staging: typec: tcpci: support port config passed via dt

[Jun Li]

Hi

> -----Original Message-----
> From: Heikki Krogerus [mailto:heikki.krogerus@linux.intel.com]
> Sent: 2018年2月27日 19:03
> To: Jun Li <jun.li@nxp.com>
> Cc: gregkh@linuxfoundation.org; robh+dt@kernel.org; linux@roeck-us.net;
> a.hajda@samsung.com; mark.rutland@arm.com; yueyao@google.com;
> Peter Chen <peter.chen@nxp.com>; garsilva@embeddedor.com;
> o_leveque@orange.fr; shufan_lee@richtek.com; linux-usb@vger.kernel.org;
> devicetree@vger.kernel.org; dl-linux-imx <linux-imx@nxp.com>
> Subject: Re: [PATCH v2 03/12] staging: typec: tcpci: support port config
> passed via dt
> 
> Hi,
> 
> On Mon, Feb 26, 2018 at 02:30:53PM +0000, Jun Li wrote:
> > > > +	child = of_get_child_by_name(tcpci->dev->of_node, "connector");
> > > > +	if (!child) {
> > > > +		dev_err(tcpci->dev, "failed to get connector node.\n");
> > > > +		return -EINVAL;
> > > > +	}
> > >
> > > Why do you need separate child node for the connector? You will
> > > always have only one connector per tcpc, i.e. the tcpci already
> > > represents the connector and all its capabilities.
> > >
> > This is my original idea, my understanding is Rob expects those
> > properties should apply for a common usb connector node[1], that way I
> > need add a child node for it, sorry I didn't make the dt-binding
> > patches come first in this series, please see patch 10,11.
> >
> > [1]
> >
> https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpat
> >
> chwork.kernel.org%2Fpatch%2F10231447%2F&data=02%7C01%7Cjun.li%40
> nxp.co
> >
> m%7Ce37ed8b084374e241d2e08d57dd1b02a%7C686ea1d3bc2b4c6fa92cd9
> 9c5c30163
> >
> 5%7C0%7C0%7C636553261972212376&sdata=hSNiAfXoTTzK3TjjkjWo7OJL7
> %2B3gDHT
> > I8NO0FQviDd4%3D&reserved=0
> 
> But was the idea really to put properties like the TCPC capabilities under the
> usb connector child node? That will force us to extract the same properties
> in two different methods in every USB Type-C driver. One extracting them
> from DT, and another from other FW interfaces and build-in properties.
> 
> To avoid that, let's just expect to get these properties in the node for tcpc,
> not the usb connector child.

I misunderstood it's better to put typec props under connector node in all cases
so we can have a unified typec description. As Rob comments that's only required
for multiple connectors for one controller, not for simple connector like my case,
I will put those props under tcpc node.

Jun Li
> 
> 
> Thanks,
> 
> --
> heikki

[v2,03/12] staging: typec: tcpci: support port config passed via dt

[Jun Li]

Hi

> -----Original Message-----
> From: Heikki Krogerus [mailto:heikki.krogerus@linux.intel.com]
> Sent: 2018年2月27日 19:03
> To: Jun Li <jun.li@nxp.com>
> Cc: gregkh@linuxfoundation.org; robh+dt@kernel.org; linux@roeck-us.net;
> a.hajda@samsung.com; mark.rutland@arm.com; yueyao@google.com;
> Peter Chen <peter.chen@nxp.com>; garsilva@embeddedor.com;
> o_leveque@orange.fr; shufan_lee@richtek.com; linux-usb@vger.kernel.org;
> devicetree@vger.kernel.org; dl-linux-imx <linux-imx@nxp.com>
> Subject: Re: [PATCH v2 03/12] staging: typec: tcpci: support port config
> passed via dt
> 
> Hi,
> 
> On Mon, Feb 26, 2018 at 02:30:53PM +0000, Jun Li wrote:
> > > > +	child = of_get_child_by_name(tcpci->dev->of_node, "connector");
> > > > +	if (!child) {
> > > > +		dev_err(tcpci->dev, "failed to get connector node.\n");
> > > > +		return -EINVAL;
> > > > +	}
> > >
> > > Why do you need separate child node for the connector? You will
> > > always have only one connector per tcpc, i.e. the tcpci already
> > > represents the connector and all its capabilities.
> > >
> > This is my original idea, my understanding is Rob expects those
> > properties should apply for a common usb connector node[1], that way I
> > need add a child node for it, sorry I didn't make the dt-binding
> > patches come first in this series, please see patch 10,11.
> >
> > [1]
> >
> https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpat
> >
> chwork.kernel.org%2Fpatch%2F10231447%2F&data=02%7C01%7Cjun.li%40
> nxp.co
> >
> m%7Ce37ed8b084374e241d2e08d57dd1b02a%7C686ea1d3bc2b4c6fa92cd9
> 9c5c30163
> >
> 5%7C0%7C0%7C636553261972212376&sdata=hSNiAfXoTTzK3TjjkjWo7OJL7
> %2B3gDHT
> > I8NO0FQviDd4%3D&reserved=0
> 
> But was the idea really to put properties like the TCPC capabilities under the
> usb connector child node? That will force us to extract the same properties
> in two different methods in every USB Type-C driver. One extracting them
> from DT, and another from other FW interfaces and build-in properties.
> 
> To avoid that, let's just expect to get these properties in the node for tcpc,
> not the usb connector child.

I misunderstood it's better to put typec props under connector node in all cases
so we can have a unified typec description. As Rob comments that's only required
for multiple connectors for one controller, not for simple connector like my case,
I will put those props under tcpc node.

Jun Li
> 
> 
> Thanks,
> 
> --
> heikki

Re: [PATCH v2 03/12] staging: typec: tcpci: support port config passed via dt

[Heikki Krogerus]

On Mon, Mar 05, 2018 at 08:53:00AM +0000, Jun Li wrote:
> > On Mon, Feb 26, 2018 at 02:30:53PM +0000, Jun Li wrote:
> > > > > +	child = of_get_child_by_name(tcpci->dev->of_node, "connector");
> > > > > +	if (!child) {
> > > > > +		dev_err(tcpci->dev, "failed to get connector node.\n");
> > > > > +		return -EINVAL;
> > > > > +	}
> > > >
> > > > Why do you need separate child node for the connector? You will
> > > > always have only one connector per tcpc, i.e. the tcpci already
> > > > represents the connector and all its capabilities.
> > > >
> > > This is my original idea, my understanding is Rob expects those
> > > properties should apply for a common usb connector node[1], that way I
> > > need add a child node for it, sorry I didn't make the dt-binding
> > > patches come first in this series, please see patch 10,11.
> > >
> > > [1]
> > >
> > https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpat
> > >
> > chwork.kernel.org%2Fpatch%2F10231447%2F&data=02%7C01%7Cjun.li%40
> > nxp.co
> > >
> > m%7Ce37ed8b084374e241d2e08d57dd1b02a%7C686ea1d3bc2b4c6fa92cd9
> > 9c5c30163
> > >
> > 5%7C0%7C0%7C636553261972212376&sdata=hSNiAfXoTTzK3TjjkjWo7OJL7
> > %2B3gDHT
> > > I8NO0FQviDd4%3D&reserved=0
> > 
> > But was the idea really to put properties like the TCPC capabilities under the
> > usb connector child node? That will force us to extract the same properties
> > in two different methods in every USB Type-C driver. One extracting them
> > from DT, and another from other FW interfaces and build-in properties.
> > 
> > To avoid that, let's just expect to get these properties in the node for tcpc,
> > not the usb connector child.
> 
> I misunderstood it's better to put typec props under connector node in all cases
> so we can have a unified typec description. As Rob comments that's only required
> for multiple connectors for one controller, not for simple connector like my case,
> I will put those props under tcpc node.

Hold on! I was not considering multi-port PD/Type-C controllers.

I'm wrong about the child node forcing us to have two methods for
extracting the properties in the drivers. It does mean we can not use
device_property* functions as the child node is not (yet) bind to any
struct device, but we can still use fwnode_property* functions, which
is fine.

So it actually does make sense to define those properties for the
"connector" node instead of TCPC parent. They are generic "Type-C"
properties (right?), so we may want to use them with multiport
devices as well.


Br,

-- 
heikki

[v2,03/12] staging: typec: tcpci: support port config passed via dt

[Heikki Krogerus]

On Mon, Mar 05, 2018 at 08:53:00AM +0000, Jun Li wrote:
> > On Mon, Feb 26, 2018 at 02:30:53PM +0000, Jun Li wrote:
> > > > > +	child = of_get_child_by_name(tcpci->dev->of_node, "connector");
> > > > > +	if (!child) {
> > > > > +		dev_err(tcpci->dev, "failed to get connector node.\n");
> > > > > +		return -EINVAL;
> > > > > +	}
> > > >
> > > > Why do you need separate child node for the connector? You will
> > > > always have only one connector per tcpc, i.e. the tcpci already
> > > > represents the connector and all its capabilities.
> > > >
> > > This is my original idea, my understanding is Rob expects those
> > > properties should apply for a common usb connector node[1], that way I
> > > need add a child node for it, sorry I didn't make the dt-binding
> > > patches come first in this series, please see patch 10,11.
> > >
> > > [1]
> > >
> > https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpat
> > >
> > chwork.kernel.org%2Fpatch%2F10231447%2F&data=02%7C01%7Cjun.li%40
> > nxp.co
> > >
> > m%7Ce37ed8b084374e241d2e08d57dd1b02a%7C686ea1d3bc2b4c6fa92cd9
> > 9c5c30163
> > >
> > 5%7C0%7C0%7C636553261972212376&sdata=hSNiAfXoTTzK3TjjkjWo7OJL7
> > %2B3gDHT
> > > I8NO0FQviDd4%3D&reserved=0
> > 
> > But was the idea really to put properties like the TCPC capabilities under the
> > usb connector child node? That will force us to extract the same properties
> > in two different methods in every USB Type-C driver. One extracting them
> > from DT, and another from other FW interfaces and build-in properties.
> > 
> > To avoid that, let's just expect to get these properties in the node for tcpc,
> > not the usb connector child.
> 
> I misunderstood it's better to put typec props under connector node in all cases
> so we can have a unified typec description. As Rob comments that's only required
> for multiple connectors for one controller, not for simple connector like my case,
> I will put those props under tcpc node.

Hold on! I was not considering multi-port PD/Type-C controllers.

I'm wrong about the child node forcing us to have two methods for
extracting the properties in the drivers. It does mean we can not use
device_property* functions as the child node is not (yet) bind to any
struct device, but we can still use fwnode_property* functions, which
is fine.

So it actually does make sense to define those properties for the
"connector" node instead of TCPC parent. They are generic "Type-C"
properties (right?), so we may want to use them with multiport
devices as well.


Br,

Re: [PATCH v2 10/12] dt-bindings: connector: add properties for typec power delivery

[Andrzej Hajda]

On 05.03.2018 08:00, Jun Li wrote:
>
>> -----Original Message-----
>> From: Andrzej Hajda [mailto:a.hajda@samsung.com]
>> Sent: 2018年2月27日 16:41
>> To: Jun Li <jun.li@nxp.com>; gregkh@linuxfoundation.org;
>> robh+dt@kernel.org; heikki.krogerus@linux.intel.com; linux@roeck-us.net
>> Cc: mark.rutland@arm.com; yueyao@google.com; Peter Chen
>> <peter.chen@nxp.com>; garsilva@embeddedor.com; o_leveque@orange.fr;
>> shufan_lee@richtek.com; linux-usb@vger.kernel.org;
>> devicetree@vger.kernel.org; dl-linux-imx <linux-imx@nxp.com>
>> Subject: Re: [PATCH v2 10/12] dt-bindings: connector: add properties for
>> typec power delivery
>>
>> On 26.02.2018 12:49, Li Jun wrote:
>>> In case of usb-c-connector with power delivery support, add bingdings
>>> supported by current typec driver, so user can pass all those
>>> properties via dt.
>>>
>>> Signed-off-by: Li Jun <jun.li@nxp.com>
>>> ---
>>> Changes for v2:
>>> - Added typec properties are based on general usb connector bindings[1]
>>>   proposed by Andrzej Hajda.
>>> - Use the standard unit suffixes as defined in property-units.txt.
>>>
>>> [1]
>>>
>> https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpat
>> chwork.kernel.org%2Fpatch%2F10231447%2F&data=02%7C01%7Cjun.li%40
>> nxp.co
>> m%7Cccf14a36ca6445ee5f1108d57dbde3c7%7C686ea1d3bc2b4c6fa92cd99
>> c5c30163
>> 5%7C0%7C0%7C636553176880292197&sdata=2Pi0AtiwAqHQE3rGl%2Bo49K
>> 7yZZcp%2B
>>> 5bvJAknRBMGTrk%3D&reserved=0
>>>
>>>  .../bindings/connector/usb-connector.txt           | 43
>> ++++++++++++++++++++++
>>>  1 file changed, 43 insertions(+)
>>>
>>> diff --git
>>> a/Documentation/devicetree/bindings/connector/usb-connector.txt
>>> b/Documentation/devicetree/bindings/connector/usb-connector.txt
>>> index e1463f1..242f6df 100644
>>> --- a/Documentation/devicetree/bindings/connector/usb-connector.txt
>>> +++ b/Documentation/devicetree/bindings/connector/usb-connector.txt
>>> @@ -15,6 +15,30 @@ Optional properties:
>>>  - type: size of the connector, should be specified in case of USB-A, USB-B
>>>    non-fullsize connectors: "mini", "micro".
>>>
>>> +Required properties for usb-c-connector with power delivery support:
>>> +- port-type: should be one of "source", "sink" or "dual".
>>> +- default-role: preferred power role if port-type is "dual"(drp),
>>> +should be
>>> +  "sink" or "source".
>> Since port carries data and power, it would be better to explicitly mention it
>> in names of properties which can be ambiguous.
>> Maybe instead of 'port-type' you can use 'power-role', for example.
> Port-type is align with the name of typec coding and ABI, 'power-role'
> is more like for the current role rather than the port's ability.

I am not sure what are you exactly mean by "coding and ABI", but I guess
it is just about Power-Delivery part of USB-C. And if you want to put
this property into USB node without mark it is related to PD part of USB
connector, you risk confusion with possible USB data related properties.
Simple question, what if somebody wants to add property describing USB
data capabilities (DFP, UFP, DRD), how should it be named?

>
>> Other thing is that default-role is required only in case of DRP, so maybe
>> better would be to squash it in power-role, for example:
>>     power-role: should be on of "source", "sink", "dual-source", "dual-sink",
>> in case of dual roles suffix determines preferred role.
> I don't know how much this squash can benefit, "dual-source/sink" is not
> directly showing its meaning by name.

Some benefit is simpler binding, no conditionally-required property.

Another question is that USB TypeC specification describes 7 different
"behavioral models" [1]:
- Source-only
- Source (Default) – strong preference toward being a Source but
subsequently
capable of becoming a Sink using USB PD swap mechanisms.
- Sink-only
- Sink (Default) – strong preference toward being a Sink but
subsequently capable of
becoming a Source using USB PD swap mechanisms.
- DRP: Toggling (Source/Sink)
- DRP: Sourcing Device
- DRP: Sinking Host

How it maps to your proposed props?

[1]: USB Type-C specification release 1.3, chapter 4.5.1.4.

Regards
Andrzej

>
>>
>>> +- src-pdos: An array of u32 with each entry providing supported power
>>> +  source data object(PDO), the detailed bit definitions of PDO can be
>>> +found
>>> +  in "Universal Serial Bus Power Delivery Specification" chapter
>>> +6.4.1.2
>>> +  Source_Capabilities Message, the order of each entry(PDO) should
>>> +follow
>>> +  the PD spec chapter 6.4.1. Required for power source and power dual
>> role.
>>> +- snk-pdos: An array of u32 with each entry providing supported power
>>> +  sink data object(PDO), the detailed bit definitions of PDO can be
>>> +found in
>>> +  "Universal Serial Bus Power Delivery Specification" chapter 6.4.1.3
>>> +Sink
>>> +  Capabilities Message, the order of each entry(PDO) should follow
>>> +the PD
>>> +  spec chapter 6.4.1. Required for power sink and power dual role.
>> We should avoid magic numbers, magic numbers are bad :) If we really need
>> to use PDOs here, I think we can re-use PDO_* macros [1] - DTC should be
>> able to parse it, maybe some lifting will be necessary.
>>
>> [1]:
>> https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Felix
>> ir.bootlin.com%2Flinux%2Fv4.16-rc3%2Fsource%2Finclude%2Flinux%2Fusb%
>> 2Fpd.h%23L161&data=02%7C01%7Cjun.li%40nxp.com%7Cccf14a36ca6445e
>> e5f1108d57dbde3c7%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%
>> 7C636553176880292197&sdata=72HA33wgRyd2PMoPnZOlMatI2CuadplkYN
>> DDGKFSUB0%3D&reserved=0
>>> +- max-snk-microvolt: The max voltage the sink can support in micro
>>> +volts,
>>> +  required for power sink and power dual role.
>>> +- max-snk-microamp: The max current the sink can support in micro
>>> +amps,
>>> +  required for power sink and power dual role.
>>> +- max-snk-microwatt-hours: The max power the sink can support in
>>> +micro
>>> +  Watt-hours, required for power sink and power dual role.
>>> +- op-snk-microwatt-hours: Sink required operating power in micro
>>> +Watt-hours,
>>> +  if source offered power is less then it, Capability Mismatch is
>>> +set,
>>> +  required for power sink and power dual role.
>> What is the relation between above properties and PDOs specified earlier?
>> Are you sure all these props are required?
>>
> Sorry, with latest tcpm code, those props are not required, will remove them.
>
> Jun Li
>> And general remark regarding all above properties. For me, most of them
>> are specific not to the port but to devices responsible for power
>> management: chargers, pmics,....
>> In many cases these properties are redundant with devices capabilities.
>> On the other side I guess in many cases it may be convenient to put them
>> here, so I am not sure what is better :)
>>
>> Regards
>> Andrzej
>>
>>> +
>>>  Required nodes:
>>>  - any data bus to the connector should be modeled using the OF graph
>> bindings
>>>    specified in bindings/graph.txt, unless the bus is between parent
>>> node and @@ -73,3 +97,22 @@ ccic: s2mm005@33 {
>>>  		};
>>>  	};
>>>  };
>>> +
>>> +3. USB-C connector attached to a typec port controller(ptn5110),
>>> +which has power delivery support and enables drp.
>>> +
>>> +typec: ptn5110@50 {
>>> +	...
>>> +	usb_con: connector {
>>> +		compatible = "usb-c-connector";
>>> +		label = "USB-C";
>>> +		port-type = "dual";
>>> +		default-role = "sink";
>>> +		src-pdos = <0x380190c8>;
>>> +		snk-pdos = <0x380190c8 0x3802d0c8>;
>>> +		max-snk-microvolt = <9000>;
>>> +		max-snk-microamp = <2000>;
>>> +		max-snk-microwatt-hours = <18000>;
>>> +		op-snk-microwatt-hours = <9000>;
>>> +	};
>>> +};

[v2,10/12] dt-bindings: connector: add properties for typec power delivery

[Andrzej Hajda]

On 05.03.2018 08:00, Jun Li wrote:
>
>> -----Original Message-----
>> From: Andrzej Hajda [mailto:a.hajda@samsung.com]
>> Sent: 2018年2月27日 16:41
>> To: Jun Li <jun.li@nxp.com>; gregkh@linuxfoundation.org;
>> robh+dt@kernel.org; heikki.krogerus@linux.intel.com; linux@roeck-us.net
>> Cc: mark.rutland@arm.com; yueyao@google.com; Peter Chen
>> <peter.chen@nxp.com>; garsilva@embeddedor.com; o_leveque@orange.fr;
>> shufan_lee@richtek.com; linux-usb@vger.kernel.org;
>> devicetree@vger.kernel.org; dl-linux-imx <linux-imx@nxp.com>
>> Subject: Re: [PATCH v2 10/12] dt-bindings: connector: add properties for
>> typec power delivery
>>
>> On 26.02.2018 12:49, Li Jun wrote:
>>> In case of usb-c-connector with power delivery support, add bingdings
>>> supported by current typec driver, so user can pass all those
>>> properties via dt.
>>>
>>> Signed-off-by: Li Jun <jun.li@nxp.com>
>>> ---
>>> Changes for v2:
>>> - Added typec properties are based on general usb connector bindings[1]
>>>   proposed by Andrzej Hajda.
>>> - Use the standard unit suffixes as defined in property-units.txt.
>>>
>>> [1]
>>>
>> https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpat
>> chwork.kernel.org%2Fpatch%2F10231447%2F&data=02%7C01%7Cjun.li%40
>> nxp.co
>> m%7Cccf14a36ca6445ee5f1108d57dbde3c7%7C686ea1d3bc2b4c6fa92cd99
>> c5c30163
>> 5%7C0%7C0%7C636553176880292197&sdata=2Pi0AtiwAqHQE3rGl%2Bo49K
>> 7yZZcp%2B
>>> 5bvJAknRBMGTrk%3D&reserved=0
>>>
>>>  .../bindings/connector/usb-connector.txt           | 43
>> ++++++++++++++++++++++
>>>  1 file changed, 43 insertions(+)
>>>
>>> diff --git
>>> a/Documentation/devicetree/bindings/connector/usb-connector.txt
>>> b/Documentation/devicetree/bindings/connector/usb-connector.txt
>>> index e1463f1..242f6df 100644
>>> --- a/Documentation/devicetree/bindings/connector/usb-connector.txt
>>> +++ b/Documentation/devicetree/bindings/connector/usb-connector.txt
>>> @@ -15,6 +15,30 @@ Optional properties:
>>>  - type: size of the connector, should be specified in case of USB-A, USB-B
>>>    non-fullsize connectors: "mini", "micro".
>>>
>>> +Required properties for usb-c-connector with power delivery support:
>>> +- port-type: should be one of "source", "sink" or "dual".
>>> +- default-role: preferred power role if port-type is "dual"(drp),
>>> +should be
>>> +  "sink" or "source".
>> Since port carries data and power, it would be better to explicitly mention it
>> in names of properties which can be ambiguous.
>> Maybe instead of 'port-type' you can use 'power-role', for example.
> Port-type is align with the name of typec coding and ABI, 'power-role'
> is more like for the current role rather than the port's ability.

I am not sure what are you exactly mean by "coding and ABI", but I guess
it is just about Power-Delivery part of USB-C. And if you want to put
this property into USB node without mark it is related to PD part of USB
connector, you risk confusion with possible USB data related properties.
Simple question, what if somebody wants to add property describing USB
data capabilities (DFP, UFP, DRD), how should it be named?

>
>> Other thing is that default-role is required only in case of DRP, so maybe
>> better would be to squash it in power-role, for example:
>>     power-role: should be on of "source", "sink", "dual-source", "dual-sink",
>> in case of dual roles suffix determines preferred role.
> I don't know how much this squash can benefit, "dual-source/sink" is not
> directly showing its meaning by name.

Some benefit is simpler binding, no conditionally-required property.

Another question is that USB TypeC specification describes 7 different
"behavioral models" [1]:
- Source-only
- Source (Default) – strong preference toward being a Source but
subsequently
capable of becoming a Sink using USB PD swap mechanisms.
- Sink-only
- Sink (Default) – strong preference toward being a Sink but
subsequently capable of
becoming a Source using USB PD swap mechanisms.
- DRP: Toggling (Source/Sink)
- DRP: Sourcing Device
- DRP: Sinking Host

How it maps to your proposed props?

[1]: USB Type-C specification release 1.3, chapter 4.5.1.4.

Regards
Andrzej

>
>>
>>> +- src-pdos: An array of u32 with each entry providing supported power
>>> +  source data object(PDO), the detailed bit definitions of PDO can be
>>> +found
>>> +  in "Universal Serial Bus Power Delivery Specification" chapter
>>> +6.4.1.2
>>> +  Source_Capabilities Message, the order of each entry(PDO) should
>>> +follow
>>> +  the PD spec chapter 6.4.1. Required for power source and power dual
>> role.
>>> +- snk-pdos: An array of u32 with each entry providing supported power
>>> +  sink data object(PDO), the detailed bit definitions of PDO can be
>>> +found in
>>> +  "Universal Serial Bus Power Delivery Specification" chapter 6.4.1.3
>>> +Sink
>>> +  Capabilities Message, the order of each entry(PDO) should follow
>>> +the PD
>>> +  spec chapter 6.4.1. Required for power sink and power dual role.
>> We should avoid magic numbers, magic numbers are bad :) If we really need
>> to use PDOs here, I think we can re-use PDO_* macros [1] - DTC should be
>> able to parse it, maybe some lifting will be necessary.
>>
>> [1]:
>> https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Felix
>> ir.bootlin.com%2Flinux%2Fv4.16-rc3%2Fsource%2Finclude%2Flinux%2Fusb%
>> 2Fpd.h%23L161&data=02%7C01%7Cjun.li%40nxp.com%7Cccf14a36ca6445e
>> e5f1108d57dbde3c7%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%
>> 7C636553176880292197&sdata=72HA33wgRyd2PMoPnZOlMatI2CuadplkYN
>> DDGKFSUB0%3D&reserved=0
>>> +- max-snk-microvolt: The max voltage the sink can support in micro
>>> +volts,
>>> +  required for power sink and power dual role.
>>> +- max-snk-microamp: The max current the sink can support in micro
>>> +amps,
>>> +  required for power sink and power dual role.
>>> +- max-snk-microwatt-hours: The max power the sink can support in
>>> +micro
>>> +  Watt-hours, required for power sink and power dual role.
>>> +- op-snk-microwatt-hours: Sink required operating power in micro
>>> +Watt-hours,
>>> +  if source offered power is less then it, Capability Mismatch is
>>> +set,
>>> +  required for power sink and power dual role.
>> What is the relation between above properties and PDOs specified earlier?
>> Are you sure all these props are required?
>>
> Sorry, with latest tcpm code, those props are not required, will remove them.
>
> Jun Li
>> And general remark regarding all above properties. For me, most of them
>> are specific not to the port but to devices responsible for power
>> management: chargers, pmics,....
>> In many cases these properties are redundant with devices capabilities.
>> On the other side I guess in many cases it may be convenient to put them
>> here, so I am not sure what is better :)
>>
>> Regards
>> Andrzej
>>
>>> +
>>>  Required nodes:
>>>  - any data bus to the connector should be modeled using the OF graph
>> bindings
>>>    specified in bindings/graph.txt, unless the bus is between parent
>>> node and @@ -73,3 +97,22 @@ ccic: s2mm005@33 {
>>>  		};
>>>  	};
>>>  };
>>> +
>>> +3. USB-C connector attached to a typec port controller(ptn5110),
>>> +which has power delivery support and enables drp.
>>> +
>>> +typec: ptn5110@50 {
>>> +	...
>>> +	usb_con: connector {
>>> +		compatible = "usb-c-connector";
>>> +		label = "USB-C";
>>> +		port-type = "dual";
>>> +		default-role = "sink";
>>> +		src-pdos = <0x380190c8>;
>>> +		snk-pdos = <0x380190c8 0x3802d0c8>;
>>> +		max-snk-microvolt = <9000>;
>>> +		max-snk-microamp = <2000>;
>>> +		max-snk-microwatt-hours = <18000>;
>>> +		op-snk-microwatt-hours = <9000>;
>>> +	};
>>> +};
---
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

RE: [PATCH v2 03/12] staging: typec: tcpci: support port config passed via dt

[Jun Li]

> -----Original Message-----
> From: Heikki Krogerus [mailto:heikki.krogerus@linux.intel.com]
> Sent: 2018年3月5日 17:54
> To: Jun Li <jun.li@nxp.com>
> Cc: gregkh@linuxfoundation.org; robh+dt@kernel.org; linux@roeck-us.net;
> a.hajda@samsung.com; mark.rutland@arm.com; yueyao@google.com;
> Peter Chen <peter.chen@nxp.com>; garsilva@embeddedor.com;
> o_leveque@orange.fr; shufan_lee@richtek.com; linux-usb@vger.kernel.org;
> devicetree@vger.kernel.org; dl-linux-imx <linux-imx@nxp.com>
> Subject: Re: [PATCH v2 03/12] staging: typec: tcpci: support port config
> passed via dt
> 
> On Mon, Mar 05, 2018 at 08:53:00AM +0000, Jun Li wrote:
> > > On Mon, Feb 26, 2018 at 02:30:53PM +0000, Jun Li wrote:
> > > > > > +	child = of_get_child_by_name(tcpci->dev->of_node,
> "connector");
> > > > > > +	if (!child) {
> > > > > > +		dev_err(tcpci->dev, "failed to get connector node.\n");
> > > > > > +		return -EINVAL;
> > > > > > +	}
> > > > >
> > > > > Why do you need separate child node for the connector? You will
> > > > > always have only one connector per tcpc, i.e. the tcpci already
> > > > > represents the connector and all its capabilities.
> > > > >
> > > > This is my original idea, my understanding is Rob expects those
> > > > properties should apply for a common usb connector node[1], that
> > > > way I need add a child node for it, sorry I didn't make the
> > > > dt-binding patches come first in this series, please see patch 10,11.
> > > >
> > > > [1]
> > > >
> > >
> https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fp
> > > at
> > > >
> > >
> chwork.kernel.org%2Fpatch%2F10231447%2F&data=02%7C01%7Cjun.li%40
> > > nxp.co
> > > >
> > >
> m%7Ce37ed8b084374e241d2e08d57dd1b02a%7C686ea1d3bc2b4c6fa92cd9
> > > 9c5c30163
> > > >
> > >
> 5%7C0%7C0%7C636553261972212376&sdata=hSNiAfXoTTzK3TjjkjWo7OJL7
> > > %2B3gDHT
> > > > I8NO0FQviDd4%3D&reserved=0
> > >
> > > But was the idea really to put properties like the TCPC capabilities
> > > under the usb connector child node? That will force us to extract
> > > the same properties in two different methods in every USB Type-C
> > > driver. One extracting them from DT, and another from other FW
> interfaces and build-in properties.
> > >
> > > To avoid that, let's just expect to get these properties in the node
> > > for tcpc, not the usb connector child.
> >
> > I misunderstood it's better to put typec props under connector node in
> > all cases so we can have a unified typec description. As Rob comments
> > that's only required for multiple connectors for one controller, not
> > for simple connector like my case, I will put those props under tcpc node.
> 
> Hold on! I was not considering multi-port PD/Type-C controllers.
> 
> I'm wrong about the child node forcing us to have two methods for
> extracting the properties in the drivers. It does mean we can not use
> device_property* functions as the child node is not (yet) bind to any struct
> device, but we can still use fwnode_property* functions, which is fine.
> 

Yes, fwnode_property* function can be used in this case.

> So it actually does make sense to define those properties for the
> "connector" node instead of TCPC parent. They are generic "Type-C"
> properties (right?), so we may want to use them with multiport devices as
> well.
> 

Yes, that's the idea of my v2, I will keep this but via fwnode_property*.

> 
> Br,
> 
> --
> heikki

[v2,03/12] staging: typec: tcpci: support port config passed via dt

[Jun Li]

> -----Original Message-----
> From: Heikki Krogerus [mailto:heikki.krogerus@linux.intel.com]
> Sent: 2018年3月5日 17:54
> To: Jun Li <jun.li@nxp.com>
> Cc: gregkh@linuxfoundation.org; robh+dt@kernel.org; linux@roeck-us.net;
> a.hajda@samsung.com; mark.rutland@arm.com; yueyao@google.com;
> Peter Chen <peter.chen@nxp.com>; garsilva@embeddedor.com;
> o_leveque@orange.fr; shufan_lee@richtek.com; linux-usb@vger.kernel.org;
> devicetree@vger.kernel.org; dl-linux-imx <linux-imx@nxp.com>
> Subject: Re: [PATCH v2 03/12] staging: typec: tcpci: support port config
> passed via dt
> 
> On Mon, Mar 05, 2018 at 08:53:00AM +0000, Jun Li wrote:
> > > On Mon, Feb 26, 2018 at 02:30:53PM +0000, Jun Li wrote:
> > > > > > +	child = of_get_child_by_name(tcpci->dev->of_node,
> "connector");
> > > > > > +	if (!child) {
> > > > > > +		dev_err(tcpci->dev, "failed to get connector node.\n");
> > > > > > +		return -EINVAL;
> > > > > > +	}
> > > > >
> > > > > Why do you need separate child node for the connector? You will
> > > > > always have only one connector per tcpc, i.e. the tcpci already
> > > > > represents the connector and all its capabilities.
> > > > >
> > > > This is my original idea, my understanding is Rob expects those
> > > > properties should apply for a common usb connector node[1], that
> > > > way I need add a child node for it, sorry I didn't make the
> > > > dt-binding patches come first in this series, please see patch 10,11.
> > > >
> > > > [1]
> > > >
> > >
> https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fp
> > > at
> > > >
> > >
> chwork.kernel.org%2Fpatch%2F10231447%2F&data=02%7C01%7Cjun.li%40
> > > nxp.co
> > > >
> > >
> m%7Ce37ed8b084374e241d2e08d57dd1b02a%7C686ea1d3bc2b4c6fa92cd9
> > > 9c5c30163
> > > >
> > >
> 5%7C0%7C0%7C636553261972212376&sdata=hSNiAfXoTTzK3TjjkjWo7OJL7
> > > %2B3gDHT
> > > > I8NO0FQviDd4%3D&reserved=0
> > >
> > > But was the idea really to put properties like the TCPC capabilities
> > > under the usb connector child node? That will force us to extract
> > > the same properties in two different methods in every USB Type-C
> > > driver. One extracting them from DT, and another from other FW
> interfaces and build-in properties.
> > >
> > > To avoid that, let's just expect to get these properties in the node
> > > for tcpc, not the usb connector child.
> >
> > I misunderstood it's better to put typec props under connector node in
> > all cases so we can have a unified typec description. As Rob comments
> > that's only required for multiple connectors for one controller, not
> > for simple connector like my case, I will put those props under tcpc node.
> 
> Hold on! I was not considering multi-port PD/Type-C controllers.
> 
> I'm wrong about the child node forcing us to have two methods for
> extracting the properties in the drivers. It does mean we can not use
> device_property* functions as the child node is not (yet) bind to any struct
> device, but we can still use fwnode_property* functions, which is fine.
> 

Yes, fwnode_property* function can be used in this case.

> So it actually does make sense to define those properties for the
> "connector" node instead of TCPC parent. They are generic "Type-C"
> properties (right?), so we may want to use them with multiport devices as
> well.
> 

Yes, that's the idea of my v2, I will keep this but via fwnode_property*.

> 
> Br,
> 
> --
> heikki

Re: [PATCH v2 03/12] staging: typec: tcpci: support port config passed via dt

[Heikki Krogerus]

Hi,

On Mon, Mar 05, 2018 at 10:35:07AM +0000, Jun Li wrote:
> > So it actually does make sense to define those properties for the
> > "connector" node instead of TCPC parent. They are generic "Type-C"
> > properties (right?), so we may want to use them with multiport devices as
> > well.
> > 
> 
> Yes, that's the idea of my v2, I will keep this but via fwnode_property*.

Cool. While at it, can you also add a patch to this series where the
fwnode is bind to the port? Something like this:

diff --git a/drivers/staging/typec/tcpci.c b/drivers/staging/typec/tcpci.c
index 9bd4412356c9..ac4e7605f9d5 100644
--- a/drivers/staging/typec/tcpci.c
+++ b/drivers/staging/typec/tcpci.c
@@ -452,6 +452,8 @@ static int tcpci_probe(struct i2c_client *client,
        if (IS_ERR(tcpci->regmap))
                return PTR_ERR(tcpci->regmap);

+       tcpci->tcpc.fwnode = device_get_named_child_node(&client->dev, "connector");
+
        tcpci->tcpc.init = tcpci_init;
        tcpci->tcpc.get_vbus = tcpci_get_vbus;
        tcpci->tcpc.set_vbus = tcpci_set_vbus;
diff --git a/drivers/usb/typec/tcpm.c b/drivers/usb/typec/tcpm.c
index f4d563ee7690..68a0ead400c0 100644
--- a/drivers/usb/typec/tcpm.c
+++ b/drivers/usb/typec/tcpm.c
@@ -3729,6 +3729,7 @@ struct tcpm_port *tcpm_register_port(struct device *dev, struct tcpc_dev *tcpc)
        else
                port->try_role = TYPEC_NO_PREFERRED_ROLE;

+       port->typec_caps.fwnode = tcpc->fwnode;
        port->typec_caps.prefer_role = tcpc->config->default_role;
        port->typec_caps.type = tcpc->config->type;
        port->typec_caps.revision = 0x0120;     /* Type-C spec release 1.2 */
diff --git a/include/linux/usb/tcpm.h b/include/linux/usb/tcpm.h
index ca1c0b57f03f..a25ebfea054d 100644
--- a/include/linux/usb/tcpm.h
+++ b/include/linux/usb/tcpm.h
@@ -127,6 +127,7 @@ struct tcpc_mux_dev {
 /**
  * struct tcpc_dev - Port configuration and callback functions
  * @config:    Pointer to port configuration
+ * @fwnode:    Pointer to port fwnode
  * @get_vbus:  Called to read current VBUS state
  * @get_current_limit:
  *             Optional; called by the tcpm core when configured as a snk
@@ -155,6 +156,7 @@ struct tcpc_mux_dev {
  */
 struct tcpc_dev {
        const struct tcpc_config *config;
+       struct fwnode_handle *fwnode;

        int (*init)(struct tcpc_dev *dev);
        int (*get_vbus)(struct tcpc_dev *dev);


Thanks,

-- 
heikki

[v2,03/12] staging: typec: tcpci: support port config passed via dt

[Heikki Krogerus]

Hi,

On Mon, Mar 05, 2018 at 10:35:07AM +0000, Jun Li wrote:
> > So it actually does make sense to define those properties for the
> > "connector" node instead of TCPC parent. They are generic "Type-C"
> > properties (right?), so we may want to use them with multiport devices as
> > well.
> > 
> 
> Yes, that's the idea of my v2, I will keep this but via fwnode_property*.

Cool. While at it, can you also add a patch to this series where the
fwnode is bind to the port? Something like this:



Thanks,

diff --git a/drivers/staging/typec/tcpci.c b/drivers/staging/typec/tcpci.c
index 9bd4412356c9..ac4e7605f9d5 100644
--- a/drivers/staging/typec/tcpci.c
+++ b/drivers/staging/typec/tcpci.c
@@ -452,6 +452,8 @@ static int tcpci_probe(struct i2c_client *client,
        if (IS_ERR(tcpci->regmap))
                return PTR_ERR(tcpci->regmap);

+       tcpci->tcpc.fwnode = device_get_named_child_node(&client->dev, "connector");
+
        tcpci->tcpc.init = tcpci_init;
        tcpci->tcpc.get_vbus = tcpci_get_vbus;
        tcpci->tcpc.set_vbus = tcpci_set_vbus;
diff --git a/drivers/usb/typec/tcpm.c b/drivers/usb/typec/tcpm.c
index f4d563ee7690..68a0ead400c0 100644
--- a/drivers/usb/typec/tcpm.c
+++ b/drivers/usb/typec/tcpm.c
@@ -3729,6 +3729,7 @@ struct tcpm_port *tcpm_register_port(struct device *dev, struct tcpc_dev *tcpc)
        else
                port->try_role = TYPEC_NO_PREFERRED_ROLE;

+       port->typec_caps.fwnode = tcpc->fwnode;
        port->typec_caps.prefer_role = tcpc->config->default_role;
        port->typec_caps.type = tcpc->config->type;
        port->typec_caps.revision = 0x0120;     /* Type-C spec release 1.2 */
diff --git a/include/linux/usb/tcpm.h b/include/linux/usb/tcpm.h
index ca1c0b57f03f..a25ebfea054d 100644
--- a/include/linux/usb/tcpm.h
+++ b/include/linux/usb/tcpm.h
@@ -127,6 +127,7 @@ struct tcpc_mux_dev {
 /**
  * struct tcpc_dev - Port configuration and callback functions
  * @config:    Pointer to port configuration
+ * @fwnode:    Pointer to port fwnode
  * @get_vbus:  Called to read current VBUS state
  * @get_current_limit:
  *             Optional; called by the tcpm core when configured as a snk
@@ -155,6 +156,7 @@ struct tcpc_mux_dev {
  */
 struct tcpc_dev {
        const struct tcpc_config *config;
+       struct fwnode_handle *fwnode;

        int (*init)(struct tcpc_dev *dev);
        int (*get_vbus)(struct tcpc_dev *dev);

RE: [PATCH v2 10/12] dt-bindings: connector: add properties for typec power delivery

[Jun Li]

> -----Original Message-----
> From: Jun Li
> Sent: 2018年3月5日 15:52
> To: Rob Herring <robh@kernel.org>; Andrzej Hajda <a.hajda@samsung.com>
> Cc: gregkh@linuxfoundation.org; heikki.krogerus@linux.intel.com;
> linux@roeck-us.net; mark.rutland@arm.com; yueyao@google.com; Peter
> Chen <peter.chen@nxp.com>; garsilva@embeddedor.com;
> o_leveque@orange.fr; shufan_lee@richtek.com; linux-usb@vger.kernel.org;
> devicetree@vger.kernel.org; dl-linux-imx <linux-imx@nxp.com>
> Subject: RE: [PATCH v2 10/12] dt-bindings: connector: add properties for
> typec power delivery
> 
> 
> > -----Original Message-----
> > From: Rob Herring [mailto:robh@kernel.org]
> > Sent: 2018年3月3日 6:39
> > To: Andrzej Hajda <a.hajda@samsung.com>
> > Cc: Jun Li <jun.li@nxp.com>; gregkh@linuxfoundation.org;
> > heikki.krogerus@linux.intel.com; linux@roeck-us.net;
> > mark.rutland@arm.com; yueyao@google.com; Peter Chen
> > <peter.chen@nxp.com>; garsilva@embeddedor.com;
> o_leveque@orange.fr;
> > shufan_lee@richtek.com; linux-usb@vger.kernel.org;
> > devicetree@vger.kernel.org; dl-linux-imx <linux-imx@nxp.com>
> > Subject: Re: [PATCH v2 10/12] dt-bindings: connector: add properties
> > for typec power delivery
> >
> > On Tue, Feb 27, 2018 at 09:41:19AM +0100, Andrzej Hajda wrote:
> > > On 26.02.2018 12:49, Li Jun wrote:
> > > > In case of usb-c-connector with power delivery support, add
> > > > bingdings supported by current typec driver, so user can pass all
> > > > those properties via dt.
> > > >
> > > > Signed-off-by: Li Jun <jun.li@nxp.com>
> > > > ---
> > > > Changes for v2:
> > > > - Added typec properties are based on general usb connector
> bindings[1]
> > > >   proposed by Andrzej Hajda.
> > > > - Use the standard unit suffixes as defined in property-units.txt.
> > > >
> > > > [1]
> > > >
> > https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fp
> > > >
> >
> atchwork.kernel.org%2Fpatch%2F10231447%2F&data=02%7C01%7Cjun.li%
> > 40nx
> > > >
> >
> p.com%7Ccea32589f3314488e18f08d5808e5aae%7C686ea1d3bc2b4c6fa92
> > cd99c5
> > > >
> >
> c301635%7C0%7C1%7C636556271266469012&sdata=ANr1jeW8x8cy6CG6tz
> > ACgj%2B
> > > > FgNKl9DJbRpervFwaQKM%3D&reserved=0
> > > >
> > > >  .../bindings/connector/usb-connector.txt           | 43
> > ++++++++++++++++++++++
> > > >  1 file changed, 43 insertions(+)
> > > >
> > > > diff --git
> > > > a/Documentation/devicetree/bindings/connector/usb-connector.txt
> > > > b/Documentation/devicetree/bindings/connector/usb-connector.txt
> > > > index e1463f1..242f6df 100644
> > > > ---
> > > > a/Documentation/devicetree/bindings/connector/usb-connector.txt
> > > > +++
> b/Documentation/devicetree/bindings/connector/usb-connector.tx
> > > > +++ t
> > > > @@ -15,6 +15,30 @@ Optional properties:
> > > >  - type: size of the connector, should be specified in case of
> > > > USB-A,
> > USB-B
> > > >    non-fullsize connectors: "mini", "micro".
> > > >
> > > > +Required properties for usb-c-connector with power delivery support:
> > > > +- port-type: should be one of "source", "sink" or "dual".
> > > > +- default-role: preferred power role if port-type is "dual"(drp),
> > > > +should be
> > > > +  "sink" or "source".
> > >
> > > Since port carries data and power, it would be better to explicitly
> > > mention it in names of properties which can be ambiguous.
> > > Maybe instead of 'port-type' you can use 'power-role', for example.
> > > Other thing is that default-role is required only in case of DRP, so
> > > maybe better would be to squash it in power-role, for example:
> > >     power-role: should be on of "source", "sink", "dual-source",
> > > "dual-sink", in case of dual roles suffix determines preferred role.
> > >
> > >
> > > > +- src-pdos: An array of u32 with each entry providing supported
> > > > +power
> > > > +  source data object(PDO), the detailed bit definitions of PDO
> > > > +can be found
> > > > +  in "Universal Serial Bus Power Delivery Specification" chapter
> > > > +6.4.1.2
> > > > +  Source_Capabilities Message, the order of each entry(PDO)
> > > > +should follow
> > > > +  the PD spec chapter 6.4.1. Required for power source and power
> > > > +dual
> > role.
> > > > +- snk-pdos: An array of u32 with each entry providing supported
> > > > +power
> > > > +  sink data object(PDO), the detailed bit definitions of PDO can
> > > > +be found in
> > > > +  "Universal Serial Bus Power Delivery Specification" chapter
> > > > +6.4.1.3 Sink
> > > > +  Capabilities Message, the order of each entry(PDO) should
> > > > +follow the PD
> > > > +  spec chapter 6.4.1. Required for power sink and power dual role.
> > >
> > > We should avoid magic numbers, magic numbers are bad :)
> >
> > I don't mind if there's a defined format for the data.
> >
> 
> Yes, there is defined format in spec for this data.
> 
> > > If we really need to use PDOs here, I think we can re-use PDO_*
> > > macros [1] - DTC should be able to parse it, maybe some lifting will be
> necessary.
> > >
> > > [1]:
> > >
> >
> https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Feli
> > >
> >
> xir.bootlin.com%2Flinux%2Fv4.16-rc3%2Fsource%2Finclude%2Flinux%2Fusb
> > %2
> > >
> >
> Fpd.h%23L161&data=02%7C01%7Cjun.li%40nxp.com%7Ccea32589f3314488
> > e18f08d
> > >
> >
> 5808e5aae%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C1%7C636556
> > 271266469
> > >
> >
> 012&sdata=rebFCafzTpqI7FyYk9ZgW2nIhJ0ca5IB%2BBUa7WC05lM%3D&res
> > erved=0
> > > > +- max-snk-microvolt: The max voltage the sink can support in
> > > > +micro volts,
> > > > +  required for power sink and power dual role.
> > > > +- max-snk-microamp: The max current the sink can support in micro
> > > > +amps,
> > > > +  required for power sink and power dual role.
> > > > +- max-snk-microwatt-hours: The max power the sink can support in
> > > > +micro
> > > > +  Watt-hours, required for power sink and power dual role.
> > > > +- op-snk-microwatt-hours: Sink required operating power in micro
> > > > +Watt-hours,
> > > > +  if source offered power is less then it, Capability Mismatch is
> > > > +set,
> > > > +  required for power sink and power dual role.
> > >
> > > What is the relation between above properties and PDOs specified
> earlier?
> > > Are you sure all these props are required?
> > >
> > > And general remark regarding all above properties. For me, most of
> > > them are specific not to the port but to devices responsible for
> > > power
> > > management: chargers, pmics,....
> > > In many cases these properties are redundant with devices capabilities.
> > > On the other side I guess in many cases it may be convenient to put
> > > them here, so I am not sure what is better :)
> >
> > I debated that too, but decided if you had 2 connectors connected to a
> > single power controller, then you'd want these in the connector.
> >
> 
> The standard typec port controller(tcpci) can only manage one typec port
> (connector), so in my case, those props should be applied to the typec
> controller, if only for power, connector child node is not required.
> I will move those typec props descriptions to a separate file:
> (Documentation/devicetree/bindings/usb/tyepc.txt)

After clarify with typec subsystem maintainer Heikki, we aligned and
correctly understand your idea that typec props should be in usb connector
node in all cases, I will keep this, sorry for the noise.

Jun Li
> 
> > Rob

[v2,10/12] dt-bindings: connector: add properties for typec power delivery

[Jun Li]

> -----Original Message-----
> From: Jun Li
> Sent: 2018年3月5日 15:52
> To: Rob Herring <robh@kernel.org>; Andrzej Hajda <a.hajda@samsung.com>
> Cc: gregkh@linuxfoundation.org; heikki.krogerus@linux.intel.com;
> linux@roeck-us.net; mark.rutland@arm.com; yueyao@google.com; Peter
> Chen <peter.chen@nxp.com>; garsilva@embeddedor.com;
> o_leveque@orange.fr; shufan_lee@richtek.com; linux-usb@vger.kernel.org;
> devicetree@vger.kernel.org; dl-linux-imx <linux-imx@nxp.com>
> Subject: RE: [PATCH v2 10/12] dt-bindings: connector: add properties for
> typec power delivery
> 
> 
> > -----Original Message-----
> > From: Rob Herring [mailto:robh@kernel.org]
> > Sent: 2018年3月3日 6:39
> > To: Andrzej Hajda <a.hajda@samsung.com>
> > Cc: Jun Li <jun.li@nxp.com>; gregkh@linuxfoundation.org;
> > heikki.krogerus@linux.intel.com; linux@roeck-us.net;
> > mark.rutland@arm.com; yueyao@google.com; Peter Chen
> > <peter.chen@nxp.com>; garsilva@embeddedor.com;
> o_leveque@orange.fr;
> > shufan_lee@richtek.com; linux-usb@vger.kernel.org;
> > devicetree@vger.kernel.org; dl-linux-imx <linux-imx@nxp.com>
> > Subject: Re: [PATCH v2 10/12] dt-bindings: connector: add properties
> > for typec power delivery
> >
> > On Tue, Feb 27, 2018 at 09:41:19AM +0100, Andrzej Hajda wrote:
> > > On 26.02.2018 12:49, Li Jun wrote:
> > > > In case of usb-c-connector with power delivery support, add
> > > > bingdings supported by current typec driver, so user can pass all
> > > > those properties via dt.
> > > >
> > > > Signed-off-by: Li Jun <jun.li@nxp.com>
> > > > ---
> > > > Changes for v2:
> > > > - Added typec properties are based on general usb connector
> bindings[1]
> > > >   proposed by Andrzej Hajda.
> > > > - Use the standard unit suffixes as defined in property-units.txt.
> > > >
> > > > [1]
> > > >
> > https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fp
> > > >
> >
> atchwork.kernel.org%2Fpatch%2F10231447%2F&data=02%7C01%7Cjun.li%
> > 40nx
> > > >
> >
> p.com%7Ccea32589f3314488e18f08d5808e5aae%7C686ea1d3bc2b4c6fa92
> > cd99c5
> > > >
> >
> c301635%7C0%7C1%7C636556271266469012&sdata=ANr1jeW8x8cy6CG6tz
> > ACgj%2B
> > > > FgNKl9DJbRpervFwaQKM%3D&reserved=0
> > > >
> > > >  .../bindings/connector/usb-connector.txt           | 43
> > ++++++++++++++++++++++
> > > >  1 file changed, 43 insertions(+)
> > > >
> > > > diff --git
> > > > a/Documentation/devicetree/bindings/connector/usb-connector.txt
> > > > b/Documentation/devicetree/bindings/connector/usb-connector.txt
> > > > index e1463f1..242f6df 100644
> > > > ---
> > > > a/Documentation/devicetree/bindings/connector/usb-connector.txt
> > > > +++
> b/Documentation/devicetree/bindings/connector/usb-connector.tx
> > > > +++ t
> > > > @@ -15,6 +15,30 @@ Optional properties:
> > > >  - type: size of the connector, should be specified in case of
> > > > USB-A,
> > USB-B
> > > >    non-fullsize connectors: "mini", "micro".
> > > >
> > > > +Required properties for usb-c-connector with power delivery support:
> > > > +- port-type: should be one of "source", "sink" or "dual".
> > > > +- default-role: preferred power role if port-type is "dual"(drp),
> > > > +should be
> > > > +  "sink" or "source".
> > >
> > > Since port carries data and power, it would be better to explicitly
> > > mention it in names of properties which can be ambiguous.
> > > Maybe instead of 'port-type' you can use 'power-role', for example.
> > > Other thing is that default-role is required only in case of DRP, so
> > > maybe better would be to squash it in power-role, for example:
> > >     power-role: should be on of "source", "sink", "dual-source",
> > > "dual-sink", in case of dual roles suffix determines preferred role.
> > >
> > >
> > > > +- src-pdos: An array of u32 with each entry providing supported
> > > > +power
> > > > +  source data object(PDO), the detailed bit definitions of PDO
> > > > +can be found
> > > > +  in "Universal Serial Bus Power Delivery Specification" chapter
> > > > +6.4.1.2
> > > > +  Source_Capabilities Message, the order of each entry(PDO)
> > > > +should follow
> > > > +  the PD spec chapter 6.4.1. Required for power source and power
> > > > +dual
> > role.
> > > > +- snk-pdos: An array of u32 with each entry providing supported
> > > > +power
> > > > +  sink data object(PDO), the detailed bit definitions of PDO can
> > > > +be found in
> > > > +  "Universal Serial Bus Power Delivery Specification" chapter
> > > > +6.4.1.3 Sink
> > > > +  Capabilities Message, the order of each entry(PDO) should
> > > > +follow the PD
> > > > +  spec chapter 6.4.1. Required for power sink and power dual role.
> > >
> > > We should avoid magic numbers, magic numbers are bad :)
> >
> > I don't mind if there's a defined format for the data.
> >
> 
> Yes, there is defined format in spec for this data.
> 
> > > If we really need to use PDOs here, I think we can re-use PDO_*
> > > macros [1] - DTC should be able to parse it, maybe some lifting will be
> necessary.
> > >
> > > [1]:
> > >
> >
> https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Feli
> > >
> >
> xir.bootlin.com%2Flinux%2Fv4.16-rc3%2Fsource%2Finclude%2Flinux%2Fusb
> > %2
> > >
> >
> Fpd.h%23L161&data=02%7C01%7Cjun.li%40nxp.com%7Ccea32589f3314488
> > e18f08d
> > >
> >
> 5808e5aae%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C1%7C636556
> > 271266469
> > >
> >
> 012&sdata=rebFCafzTpqI7FyYk9ZgW2nIhJ0ca5IB%2BBUa7WC05lM%3D&res
> > erved=0
> > > > +- max-snk-microvolt: The max voltage the sink can support in
> > > > +micro volts,
> > > > +  required for power sink and power dual role.
> > > > +- max-snk-microamp: The max current the sink can support in micro
> > > > +amps,
> > > > +  required for power sink and power dual role.
> > > > +- max-snk-microwatt-hours: The max power the sink can support in
> > > > +micro
> > > > +  Watt-hours, required for power sink and power dual role.
> > > > +- op-snk-microwatt-hours: Sink required operating power in micro
> > > > +Watt-hours,
> > > > +  if source offered power is less then it, Capability Mismatch is
> > > > +set,
> > > > +  required for power sink and power dual role.
> > >
> > > What is the relation between above properties and PDOs specified
> earlier?
> > > Are you sure all these props are required?
> > >
> > > And general remark regarding all above properties. For me, most of
> > > them are specific not to the port but to devices responsible for
> > > power
> > > management: chargers, pmics,....
> > > In many cases these properties are redundant with devices capabilities.
> > > On the other side I guess in many cases it may be convenient to put
> > > them here, so I am not sure what is better :)
> >
> > I debated that too, but decided if you had 2 connectors connected to a
> > single power controller, then you'd want these in the connector.
> >
> 
> The standard typec port controller(tcpci) can only manage one typec port
> (connector), so in my case, those props should be applied to the typec
> controller, if only for power, connector child node is not required.
> I will move those typec props descriptions to a separate file:
> (Documentation/devicetree/bindings/usb/tyepc.txt)

After clarify with typec subsystem maintainer Heikki, we aligned and
correctly understand your idea that typec props should be in usb connector
node in all cases, I will keep this, sorry for the noise.

Jun Li
> 
> > Rob

RE: [PATCH v2 03/12] staging: typec: tcpci: support port config passed via dt

[Jun Li]

> -----Original Message-----
> From: Heikki Krogerus [mailto:heikki.krogerus@linux.intel.com]
> Sent: 2018年3月5日 19:30
> To: Jun Li <jun.li@nxp.com>
> Cc: gregkh@linuxfoundation.org; robh+dt@kernel.org; linux@roeck-us.net;
> a.hajda@samsung.com; mark.rutland@arm.com; yueyao@google.com;
> Peter Chen <peter.chen@nxp.com>; garsilva@embeddedor.com;
> o_leveque@orange.fr; shufan_lee@richtek.com; linux-usb@vger.kernel.org;
> devicetree@vger.kernel.org; dl-linux-imx <linux-imx@nxp.com>
> Subject: Re: [PATCH v2 03/12] staging: typec: tcpci: support port config
> passed via dt
> 
> Hi,
> 
> On Mon, Mar 05, 2018 at 10:35:07AM +0000, Jun Li wrote:
> > > So it actually does make sense to define those properties for the
> > > "connector" node instead of TCPC parent. They are generic "Type-C"
> > > properties (right?), so we may want to use them with multiport
> > > devices as well.
> > >
> >
> > Yes, that's the idea of my v2, I will keep this but via fwnode_property*.
> 
> Cool. While at it, can you also add a patch to this series where the fwnode is
> bind to the port? Something like this:

OK, I will add a patch for this.

> 
> diff --git a/drivers/staging/typec/tcpci.c b/drivers/staging/typec/tcpci.c
> index 9bd4412356c9..ac4e7605f9d5 100644
> --- a/drivers/staging/typec/tcpci.c
> +++ b/drivers/staging/typec/tcpci.c
> @@ -452,6 +452,8 @@ static int tcpci_probe(struct i2c_client *client,
>         if (IS_ERR(tcpci->regmap))
>                 return PTR_ERR(tcpci->regmap);
> 
> +       tcpci->tcpc.fwnode =
> device_get_named_child_node(&client->dev,
> + "connector");
> +
>         tcpci->tcpc.init = tcpci_init;
>         tcpci->tcpc.get_vbus = tcpci_get_vbus;
>         tcpci->tcpc.set_vbus = tcpci_set_vbus; diff --git
> a/drivers/usb/typec/tcpm.c b/drivers/usb/typec/tcpm.c index
> f4d563ee7690..68a0ead400c0 100644
> --- a/drivers/usb/typec/tcpm.c
> +++ b/drivers/usb/typec/tcpm.c
> @@ -3729,6 +3729,7 @@ struct tcpm_port *tcpm_register_port(struct
> device *dev, struct tcpc_dev *tcpc)
>         else
>                 port->try_role = TYPEC_NO_PREFERRED_ROLE;
> 
> +       port->typec_caps.fwnode = tcpc->fwnode;
>         port->typec_caps.prefer_role = tcpc->config->default_role;
>         port->typec_caps.type = tcpc->config->type;
>         port->typec_caps.revision = 0x0120;     /* Type-C spec release
> 1.2 */
> diff --git a/include/linux/usb/tcpm.h b/include/linux/usb/tcpm.h index
> ca1c0b57f03f..a25ebfea054d 100644
> --- a/include/linux/usb/tcpm.h
> +++ b/include/linux/usb/tcpm.h
> @@ -127,6 +127,7 @@ struct tcpc_mux_dev {
>  /**
>   * struct tcpc_dev - Port configuration and callback functions
>   * @config:    Pointer to port configuration
> + * @fwnode:    Pointer to port fwnode
>   * @get_vbus:  Called to read current VBUS state
>   * @get_current_limit:
>   *             Optional; called by the tcpm core when configured as a
> snk
> @@ -155,6 +156,7 @@ struct tcpc_mux_dev {
>   */
>  struct tcpc_dev {
>         const struct tcpc_config *config;
> +       struct fwnode_handle *fwnode;
> 
>         int (*init)(struct tcpc_dev *dev);
>         int (*get_vbus)(struct tcpc_dev *dev);
> 
> 
> Thanks,
> 
> --
> heikki

[v2,03/12] staging: typec: tcpci: support port config passed via dt

[Jun Li]

> -----Original Message-----
> From: Heikki Krogerus [mailto:heikki.krogerus@linux.intel.com]
> Sent: 2018年3月5日 19:30
> To: Jun Li <jun.li@nxp.com>
> Cc: gregkh@linuxfoundation.org; robh+dt@kernel.org; linux@roeck-us.net;
> a.hajda@samsung.com; mark.rutland@arm.com; yueyao@google.com;
> Peter Chen <peter.chen@nxp.com>; garsilva@embeddedor.com;
> o_leveque@orange.fr; shufan_lee@richtek.com; linux-usb@vger.kernel.org;
> devicetree@vger.kernel.org; dl-linux-imx <linux-imx@nxp.com>
> Subject: Re: [PATCH v2 03/12] staging: typec: tcpci: support port config
> passed via dt
> 
> Hi,
> 
> On Mon, Mar 05, 2018 at 10:35:07AM +0000, Jun Li wrote:
> > > So it actually does make sense to define those properties for the
> > > "connector" node instead of TCPC parent. They are generic "Type-C"
> > > properties (right?), so we may want to use them with multiport
> > > devices as well.
> > >
> >
> > Yes, that's the idea of my v2, I will keep this but via fwnode_property*.
> 
> Cool. While at it, can you also add a patch to this series where the fwnode is
> bind to the port? Something like this:

OK, I will add a patch for this.

> 
> diff --git a/drivers/staging/typec/tcpci.c b/drivers/staging/typec/tcpci.c
> index 9bd4412356c9..ac4e7605f9d5 100644
> --- a/drivers/staging/typec/tcpci.c
> +++ b/drivers/staging/typec/tcpci.c
> @@ -452,6 +452,8 @@ static int tcpci_probe(struct i2c_client *client,
>         if (IS_ERR(tcpci->regmap))
>                 return PTR_ERR(tcpci->regmap);
> 
> +       tcpci->tcpc.fwnode =
> device_get_named_child_node(&client->dev,
> + "connector");
> +
>         tcpci->tcpc.init = tcpci_init;
>         tcpci->tcpc.get_vbus = tcpci_get_vbus;
>         tcpci->tcpc.set_vbus = tcpci_set_vbus; diff --git
> a/drivers/usb/typec/tcpm.c b/drivers/usb/typec/tcpm.c index
> f4d563ee7690..68a0ead400c0 100644
> --- a/drivers/usb/typec/tcpm.c
> +++ b/drivers/usb/typec/tcpm.c
> @@ -3729,6 +3729,7 @@ struct tcpm_port *tcpm_register_port(struct
> device *dev, struct tcpc_dev *tcpc)
>         else
>                 port->try_role = TYPEC_NO_PREFERRED_ROLE;
> 
> +       port->typec_caps.fwnode = tcpc->fwnode;
>         port->typec_caps.prefer_role = tcpc->config->default_role;
>         port->typec_caps.type = tcpc->config->type;
>         port->typec_caps.revision = 0x0120;     /* Type-C spec release
> 1.2 */
> diff --git a/include/linux/usb/tcpm.h b/include/linux/usb/tcpm.h index
> ca1c0b57f03f..a25ebfea054d 100644
> --- a/include/linux/usb/tcpm.h
> +++ b/include/linux/usb/tcpm.h
> @@ -127,6 +127,7 @@ struct tcpc_mux_dev {
>  /**
>   * struct tcpc_dev - Port configuration and callback functions
>   * @config:    Pointer to port configuration
> + * @fwnode:    Pointer to port fwnode
>   * @get_vbus:  Called to read current VBUS state
>   * @get_current_limit:
>   *             Optional; called by the tcpm core when configured as a
> snk
> @@ -155,6 +156,7 @@ struct tcpc_mux_dev {
>   */
>  struct tcpc_dev {
>         const struct tcpc_config *config;
> +       struct fwnode_handle *fwnode;
> 
>         int (*init)(struct tcpc_dev *dev);
>         int (*get_vbus)(struct tcpc_dev *dev);
> 
> 
> Thanks,
> 
> --
> heikki

RE: [PATCH v2 10/12] dt-bindings: connector: add properties for typec power delivery

[Jun Li]

Hi
> -----Original Message-----
> From: Andrzej Hajda [mailto:a.hajda@samsung.com]
> Sent: 2018年3月5日 17:59
> To: Jun Li <jun.li@nxp.com>; gregkh@linuxfoundation.org;
> robh+dt@kernel.org; heikki.krogerus@linux.intel.com; linux@roeck-us.net
> Cc: mark.rutland@arm.com; yueyao@google.com; Peter Chen
> <peter.chen@nxp.com>; garsilva@embeddedor.com; o_leveque@orange.fr;
> shufan_lee@richtek.com; linux-usb@vger.kernel.org;
> devicetree@vger.kernel.org; dl-linux-imx <linux-imx@nxp.com>
> Subject: Re: [PATCH v2 10/12] dt-bindings: connector: add properties for
> typec power delivery
> 
> On 05.03.2018 08:00, Jun Li wrote:
> >
> >> -----Original Message-----
> >> From: Andrzej Hajda [mailto:a.hajda@samsung.com]
> >> Sent: 2018年2月27日 16:41
> >> To: Jun Li <jun.li@nxp.com>; gregkh@linuxfoundation.org;
> >> robh+dt@kernel.org; heikki.krogerus@linux.intel.com;
> >> robh+linux@roeck-us.net
> >> Cc: mark.rutland@arm.com; yueyao@google.com; Peter Chen
> >> <peter.chen@nxp.com>; garsilva@embeddedor.com;
> o_leveque@orange.fr;
> >> shufan_lee@richtek.com; linux-usb@vger.kernel.org;
> >> devicetree@vger.kernel.org; dl-linux-imx <linux-imx@nxp.com>
> >> Subject: Re: [PATCH v2 10/12] dt-bindings: connector: add properties
> >> for typec power delivery
> >>
> >> On 26.02.2018 12:49, Li Jun wrote:
> >>> In case of usb-c-connector with power delivery support, add
> >>> bingdings supported by current typec driver, so user can pass all
> >>> those properties via dt.
> >>>
> >>> Signed-off-by: Li Jun <jun.li@nxp.com>
> >>> ---
> >>> Changes for v2:
> >>> - Added typec properties are based on general usb connector bindings[1]
> >>>   proposed by Andrzej Hajda.
> >>> - Use the standard unit suffixes as defined in property-units.txt.
> >>>
> >>> [1]
> >>>
> >>
> https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpa
> >> t
> >>
> chwork.kernel.org%2Fpatch%2F10231447%2F&data=02%7C01%7Cjun.li%40
> >> nxp.co
> >>
> m%7Cccf14a36ca6445ee5f1108d57dbde3c7%7C686ea1d3bc2b4c6fa92cd99
> >> c5c30163
> >>
> 5%7C0%7C0%7C636553176880292197&sdata=2Pi0AtiwAqHQE3rGl%2Bo49K
> >> 7yZZcp%2B
> >>> 5bvJAknRBMGTrk%3D&reserved=0
> >>>
> >>>  .../bindings/connector/usb-connector.txt           | 43
> >> ++++++++++++++++++++++
> >>>  1 file changed, 43 insertions(+)
> >>>
> >>> diff --git
> >>> a/Documentation/devicetree/bindings/connector/usb-connector.txt
> >>> b/Documentation/devicetree/bindings/connector/usb-connector.txt
> >>> index e1463f1..242f6df 100644
> >>> --- a/Documentation/devicetree/bindings/connector/usb-connector.txt
> >>> +++
> b/Documentation/devicetree/bindings/connector/usb-connector.txt
> >>> @@ -15,6 +15,30 @@ Optional properties:
> >>>  - type: size of the connector, should be specified in case of USB-A,
> USB-B
> >>>    non-fullsize connectors: "mini", "micro".
> >>>
> >>> +Required properties for usb-c-connector with power delivery support:
> >>> +- port-type: should be one of "source", "sink" or "dual".
> >>> +- default-role: preferred power role if port-type is "dual"(drp),
> >>> +should be
> >>> +  "sink" or "source".
> >> Since port carries data and power, it would be better to explicitly
> >> mention it in names of properties which can be ambiguous.
> >> Maybe instead of 'port-type' you can use 'power-role', for example.
> > Port-type is align with the name of typec coding and ABI, 'power-role'
> > is more like for the current role rather than the port's ability.
> 
> I am not sure what are you exactly mean by "coding and ABI", but I guess it is
> just about Power-Delivery part of USB-C. And if you want to put this property
> into USB node without mark it is related to PD part of USB connector, you
> risk confusion with possible USB data related properties.

Understood your concern, I am following typec naming conventions,
for typec, port-type property has the same meaning as
/sys/class/typec/portx/port_type
which is not only for power, also for data, there are dedicated
sys files power_role for power and data_role for data.

> Simple question, what if somebody wants to add property describing USB
> data capabilities (DFP, UFP, DRD), how should it be named?
> 

Then we may use data-role?

> >
> >> Other thing is that default-role is required only in case of DRP, so
> >> maybe better would be to squash it in power-role, for example:
> >>     power-role: should be on of "source", "sink", "dual-source",
> >> "dual-sink", in case of dual roles suffix determines preferred role.
> > I don't know how much this squash can benefit, "dual-source/sink" is
> > not directly showing its meaning by name.
> 
> Some benefit is simpler binding, no conditionally-required property.
> 

There is already string definition for port type and preferred role parse 
static const char * const typec_port_types[] = {
         [TYPEC_PORT_DFP] = "source",
         [TYPEC_PORT_UFP] = "sink",
         [TYPEC_PORT_DRP] = "dual",
};
And I think there will be other conditionally-required properties
to be extended later, are we going to name all of them by this way?
Either way is OK for me, I am not sure if there is principle like we
should avoid conditionally-required property, if we should, maybe
"dual-preferred-source/sink" is better.

Hi Heikki,
Do you have any comments/preference here?

> Another question is that USB TypeC specification describes 7 different
> "behavioral models" [1]:
> - Source-only

Maps "source"

> - Source (Default) – strong preference toward being a Source but
> subsequently capable of becoming a Sink using USB PD swap mechanisms.

Only present Rp(source) when attach, can be sink only by power swap.
Seems current code doesn't support this, to be extended.

> - Sink-only

Maps to "sink"

> - Sink (Default) – strong preference toward being a Sink but subsequently
> capable of becoming a Source using USB PD swap mechanisms.

Only present Rd while attachment, can be source only by power swap support.
Seems current code doesn't support this, to be extended.

> - DRP: Toggling (Source/Sink)

Maps to "dual"

> - DRP: Sourcing Device

"dual" but without USB host function(to be extended).

> - DRP: Sinking Host
> 

"dual" but without USB device function(to be extended).

> How it maps to your proposed props?
> 
> [1]: USB Type-C specification release 1.3, chapter 4.5.1.4.
> 

Current typec and tcpm hasn't cover the full features like this.

Thanks
Jun Li
> Regards
> Andrzej
> 
> >
> >>
> >>> +- src-pdos: An array of u32 with each entry providing supported
> >>> +power
> >>> +  source data object(PDO), the detailed bit definitions of PDO can
> >>> +be found
> >>> +  in "Universal Serial Bus Power Delivery Specification" chapter
> >>> +6.4.1.2
> >>> +  Source_Capabilities Message, the order of each entry(PDO) should
> >>> +follow
> >>> +  the PD spec chapter 6.4.1. Required for power source and power
> >>> +dual
> >> role.
> >>> +- snk-pdos: An array of u32 with each entry providing supported
> >>> +power
> >>> +  sink data object(PDO), the detailed bit definitions of PDO can be
> >>> +found in
> >>> +  "Universal Serial Bus Power Delivery Specification" chapter
> >>> +6.4.1.3 Sink
> >>> +  Capabilities Message, the order of each entry(PDO) should follow
> >>> +the PD
> >>> +  spec chapter 6.4.1. Required for power sink and power dual role.
> >> We should avoid magic numbers, magic numbers are bad :) If we really
> >> need to use PDOs here, I think we can re-use PDO_* macros [1] - DTC
> >> should be able to parse it, maybe some lifting will be necessary.
> >>
> >> [1]:
> >>
> https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fel
> >> ix
> >>
> ir.bootlin.com%2Flinux%2Fv4.16-rc3%2Fsource%2Finclude%2Flinux%2Fusb%
> >>
> 2Fpd.h%23L161&data=02%7C01%7Cjun.li%40nxp.com%7Cccf14a36ca6445e
> >>
> e5f1108d57dbde3c7%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%
> >>
> 7C636553176880292197&sdata=72HA33wgRyd2PMoPnZOlMatI2CuadplkYN
> >> DDGKFSUB0%3D&reserved=0
> >>> +- max-snk-microvolt: The max voltage the sink can support in micro
> >>> +volts,
> >>> +  required for power sink and power dual role.
> >>> +- max-snk-microamp: The max current the sink can support in micro
> >>> +amps,
> >>> +  required for power sink and power dual role.
> >>> +- max-snk-microwatt-hours: The max power the sink can support in
> >>> +micro
> >>> +  Watt-hours, required for power sink and power dual role.
> >>> +- op-snk-microwatt-hours: Sink required operating power in micro
> >>> +Watt-hours,
> >>> +  if source offered power is less then it, Capability Mismatch is
> >>> +set,
> >>> +  required for power sink and power dual role.
> >> What is the relation between above properties and PDOs specified
> earlier?
> >> Are you sure all these props are required?
> >>
> > Sorry, with latest tcpm code, those props are not required, will remove
> them.
> >
> > Jun Li
> >> And general remark regarding all above properties. For me, most of
> >> them are specific not to the port but to devices responsible for
> >> power
> >> management: chargers, pmics,....
> >> In many cases these properties are redundant with devices capabilities.
> >> On the other side I guess in many cases it may be convenient to put
> >> them here, so I am not sure what is better :)
> >>
> >> Regards
> >> Andrzej
> >>
> >>> +
> >>>  Required nodes:
> >>>  - any data bus to the connector should be modeled using the OF
> >>> graph
> >> bindings
> >>>    specified in bindings/graph.txt, unless the bus is between parent
> >>> node and @@ -73,3 +97,22 @@ ccic: s2mm005@33 {
> >>>  		};
> >>>  	};
> >>>  };
> >>> +
> >>> +3. USB-C connector attached to a typec port controller(ptn5110),
> >>> +which has power delivery support and enables drp.
> >>> +
> >>> +typec: ptn5110@50 {
> >>> +	...
> >>> +	usb_con: connector {
> >>> +		compatible = "usb-c-connector";
> >>> +		label = "USB-C";
> >>> +		port-type = "dual";
> >>> +		default-role = "sink";
> >>> +		src-pdos = <0x380190c8>;
> >>> +		snk-pdos = <0x380190c8 0x3802d0c8>;
> >>> +		max-snk-microvolt = <9000>;
> >>> +		max-snk-microamp = <2000>;
> >>> +		max-snk-microwatt-hours = <18000>;
> >>> +		op-snk-microwatt-hours = <9000>;
> >>> +	};
> >>> +};
> 

[v2,10/12] dt-bindings: connector: add properties for typec power delivery

[Jun Li]

Hi
> -----Original Message-----
> From: Andrzej Hajda [mailto:a.hajda@samsung.com]
> Sent: 2018年3月5日 17:59
> To: Jun Li <jun.li@nxp.com>; gregkh@linuxfoundation.org;
> robh+dt@kernel.org; heikki.krogerus@linux.intel.com; linux@roeck-us.net
> Cc: mark.rutland@arm.com; yueyao@google.com; Peter Chen
> <peter.chen@nxp.com>; garsilva@embeddedor.com; o_leveque@orange.fr;
> shufan_lee@richtek.com; linux-usb@vger.kernel.org;
> devicetree@vger.kernel.org; dl-linux-imx <linux-imx@nxp.com>
> Subject: Re: [PATCH v2 10/12] dt-bindings: connector: add properties for
> typec power delivery
> 
> On 05.03.2018 08:00, Jun Li wrote:
> >
> >> -----Original Message-----
> >> From: Andrzej Hajda [mailto:a.hajda@samsung.com]
> >> Sent: 2018年2月27日 16:41
> >> To: Jun Li <jun.li@nxp.com>; gregkh@linuxfoundation.org;
> >> robh+dt@kernel.org; heikki.krogerus@linux.intel.com;
> >> robh+linux@roeck-us.net
> >> Cc: mark.rutland@arm.com; yueyao@google.com; Peter Chen
> >> <peter.chen@nxp.com>; garsilva@embeddedor.com;
> o_leveque@orange.fr;
> >> shufan_lee@richtek.com; linux-usb@vger.kernel.org;
> >> devicetree@vger.kernel.org; dl-linux-imx <linux-imx@nxp.com>
> >> Subject: Re: [PATCH v2 10/12] dt-bindings: connector: add properties
> >> for typec power delivery
> >>
> >> On 26.02.2018 12:49, Li Jun wrote:
> >>> In case of usb-c-connector with power delivery support, add
> >>> bingdings supported by current typec driver, so user can pass all
> >>> those properties via dt.
> >>>
> >>> Signed-off-by: Li Jun <jun.li@nxp.com>
> >>> ---
> >>> Changes for v2:
> >>> - Added typec properties are based on general usb connector bindings[1]
> >>>   proposed by Andrzej Hajda.
> >>> - Use the standard unit suffixes as defined in property-units.txt.
> >>>
> >>> [1]
> >>>
> >>
> https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpa
> >> t
> >>
> chwork.kernel.org%2Fpatch%2F10231447%2F&data=02%7C01%7Cjun.li%40
> >> nxp.co
> >>
> m%7Cccf14a36ca6445ee5f1108d57dbde3c7%7C686ea1d3bc2b4c6fa92cd99
> >> c5c30163
> >>
> 5%7C0%7C0%7C636553176880292197&sdata=2Pi0AtiwAqHQE3rGl%2Bo49K
> >> 7yZZcp%2B
> >>> 5bvJAknRBMGTrk%3D&reserved=0
> >>>
> >>>  .../bindings/connector/usb-connector.txt           | 43
> >> ++++++++++++++++++++++
> >>>  1 file changed, 43 insertions(+)
> >>>
> >>> diff --git
> >>> a/Documentation/devicetree/bindings/connector/usb-connector.txt
> >>> b/Documentation/devicetree/bindings/connector/usb-connector.txt
> >>> index e1463f1..242f6df 100644
> >>> --- a/Documentation/devicetree/bindings/connector/usb-connector.txt
> >>> +++
> b/Documentation/devicetree/bindings/connector/usb-connector.txt
> >>> @@ -15,6 +15,30 @@ Optional properties:
> >>>  - type: size of the connector, should be specified in case of USB-A,
> USB-B
> >>>    non-fullsize connectors: "mini", "micro".
> >>>
> >>> +Required properties for usb-c-connector with power delivery support:
> >>> +- port-type: should be one of "source", "sink" or "dual".
> >>> +- default-role: preferred power role if port-type is "dual"(drp),
> >>> +should be
> >>> +  "sink" or "source".
> >> Since port carries data and power, it would be better to explicitly
> >> mention it in names of properties which can be ambiguous.
> >> Maybe instead of 'port-type' you can use 'power-role', for example.
> > Port-type is align with the name of typec coding and ABI, 'power-role'
> > is more like for the current role rather than the port's ability.
> 
> I am not sure what are you exactly mean by "coding and ABI", but I guess it is
> just about Power-Delivery part of USB-C. And if you want to put this property
> into USB node without mark it is related to PD part of USB connector, you
> risk confusion with possible USB data related properties.

Understood your concern, I am following typec naming conventions,
for typec, port-type property has the same meaning as
/sys/class/typec/portx/port_type
which is not only for power, also for data, there are dedicated
sys files power_role for power and data_role for data.

> Simple question, what if somebody wants to add property describing USB
> data capabilities (DFP, UFP, DRD), how should it be named?
> 

Then we may use data-role?

> >
> >> Other thing is that default-role is required only in case of DRP, so
> >> maybe better would be to squash it in power-role, for example:
> >>     power-role: should be on of "source", "sink", "dual-source",
> >> "dual-sink", in case of dual roles suffix determines preferred role.
> > I don't know how much this squash can benefit, "dual-source/sink" is
> > not directly showing its meaning by name.
> 
> Some benefit is simpler binding, no conditionally-required property.
> 

There is already string definition for port type and preferred role parse 
static const char * const typec_port_types[] = {
         [TYPEC_PORT_DFP] = "source",
         [TYPEC_PORT_UFP] = "sink",
         [TYPEC_PORT_DRP] = "dual",
};
And I think there will be other conditionally-required properties
to be extended later, are we going to name all of them by this way?
Either way is OK for me, I am not sure if there is principle like we
should avoid conditionally-required property, if we should, maybe
"dual-preferred-source/sink" is better.

Hi Heikki,
Do you have any comments/preference here?

> Another question is that USB TypeC specification describes 7 different
> "behavioral models" [1]:
> - Source-only

Maps "source"

> - Source (Default) – strong preference toward being a Source but
> subsequently capable of becoming a Sink using USB PD swap mechanisms.

Only present Rp(source) when attach, can be sink only by power swap.
Seems current code doesn't support this, to be extended.

> - Sink-only

Maps to "sink"

> - Sink (Default) – strong preference toward being a Sink but subsequently
> capable of becoming a Source using USB PD swap mechanisms.

Only present Rd while attachment, can be source only by power swap support.
Seems current code doesn't support this, to be extended.

> - DRP: Toggling (Source/Sink)

Maps to "dual"

> - DRP: Sourcing Device

"dual" but without USB host function(to be extended).

> - DRP: Sinking Host
> 

"dual" but without USB device function(to be extended).

> How it maps to your proposed props?
> 
> [1]: USB Type-C specification release 1.3, chapter 4.5.1.4.
> 

Current typec and tcpm hasn't cover the full features like this.

Thanks
Jun Li
> Regards
> Andrzej
> 
> >
> >>
> >>> +- src-pdos: An array of u32 with each entry providing supported
> >>> +power
> >>> +  source data object(PDO), the detailed bit definitions of PDO can
> >>> +be found
> >>> +  in "Universal Serial Bus Power Delivery Specification" chapter
> >>> +6.4.1.2
> >>> +  Source_Capabilities Message, the order of each entry(PDO) should
> >>> +follow
> >>> +  the PD spec chapter 6.4.1. Required for power source and power
> >>> +dual
> >> role.
> >>> +- snk-pdos: An array of u32 with each entry providing supported
> >>> +power
> >>> +  sink data object(PDO), the detailed bit definitions of PDO can be
> >>> +found in
> >>> +  "Universal Serial Bus Power Delivery Specification" chapter
> >>> +6.4.1.3 Sink
> >>> +  Capabilities Message, the order of each entry(PDO) should follow
> >>> +the PD
> >>> +  spec chapter 6.4.1. Required for power sink and power dual role.
> >> We should avoid magic numbers, magic numbers are bad :) If we really
> >> need to use PDOs here, I think we can re-use PDO_* macros [1] - DTC
> >> should be able to parse it, maybe some lifting will be necessary.
> >>
> >> [1]:
> >>
> https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fel
> >> ix
> >>
> ir.bootlin.com%2Flinux%2Fv4.16-rc3%2Fsource%2Finclude%2Flinux%2Fusb%
> >>
> 2Fpd.h%23L161&data=02%7C01%7Cjun.li%40nxp.com%7Cccf14a36ca6445e
> >>
> e5f1108d57dbde3c7%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%
> >>
> 7C636553176880292197&sdata=72HA33wgRyd2PMoPnZOlMatI2CuadplkYN
> >> DDGKFSUB0%3D&reserved=0
> >>> +- max-snk-microvolt: The max voltage the sink can support in micro
> >>> +volts,
> >>> +  required for power sink and power dual role.
> >>> +- max-snk-microamp: The max current the sink can support in micro
> >>> +amps,
> >>> +  required for power sink and power dual role.
> >>> +- max-snk-microwatt-hours: The max power the sink can support in
> >>> +micro
> >>> +  Watt-hours, required for power sink and power dual role.
> >>> +- op-snk-microwatt-hours: Sink required operating power in micro
> >>> +Watt-hours,
> >>> +  if source offered power is less then it, Capability Mismatch is
> >>> +set,
> >>> +  required for power sink and power dual role.
> >> What is the relation between above properties and PDOs specified
> earlier?
> >> Are you sure all these props are required?
> >>
> > Sorry, with latest tcpm code, those props are not required, will remove
> them.
> >
> > Jun Li
> >> And general remark regarding all above properties. For me, most of
> >> them are specific not to the port but to devices responsible for
> >> power
> >> management: chargers, pmics,....
> >> In many cases these properties are redundant with devices capabilities.
> >> On the other side I guess in many cases it may be convenient to put
> >> them here, so I am not sure what is better :)
> >>
> >> Regards
> >> Andrzej
> >>
> >>> +
> >>>  Required nodes:
> >>>  - any data bus to the connector should be modeled using the OF
> >>> graph
> >> bindings
> >>>    specified in bindings/graph.txt, unless the bus is between parent
> >>> node and @@ -73,3 +97,22 @@ ccic: s2mm005@33 {
> >>>  		};
> >>>  	};
> >>>  };
> >>> +
> >>> +3. USB-C connector attached to a typec port controller(ptn5110),
> >>> +which has power delivery support and enables drp.
> >>> +
> >>> +typec: ptn5110@50 {
> >>> +	...
> >>> +	usb_con: connector {
> >>> +		compatible = "usb-c-connector";
> >>> +		label = "USB-C";
> >>> +		port-type = "dual";
> >>> +		default-role = "sink";
> >>> +		src-pdos = <0x380190c8>;
> >>> +		snk-pdos = <0x380190c8 0x3802d0c8>;
> >>> +		max-snk-microvolt = <9000>;
> >>> +		max-snk-microamp = <2000>;
> >>> +		max-snk-microwatt-hours = <18000>;
> >>> +		op-snk-microwatt-hours = <9000>;
> >>> +	};
> >>> +};
>

Re: [PATCH v2 10/12] dt-bindings: connector: add properties for typec power delivery

[Andrzej Hajda]

On 06.03.2018 10:38, Jun Li wrote:
> Hi
>> -----Original Message-----
>> From: Andrzej Hajda [mailto:a.hajda@samsung.com]
>> Sent: 2018年3月5日 17:59
>> To: Jun Li <jun.li@nxp.com>; gregkh@linuxfoundation.org;
>> robh+dt@kernel.org; heikki.krogerus@linux.intel.com; linux@roeck-us.net
>> Cc: mark.rutland@arm.com; yueyao@google.com; Peter Chen
>> <peter.chen@nxp.com>; garsilva@embeddedor.com; o_leveque@orange.fr;
>> shufan_lee@richtek.com; linux-usb@vger.kernel.org;
>> devicetree@vger.kernel.org; dl-linux-imx <linux-imx@nxp.com>
>> Subject: Re: [PATCH v2 10/12] dt-bindings: connector: add properties for
>> typec power delivery
>>
>> On 05.03.2018 08:00, Jun Li wrote:
>>>> -----Original Message-----
>>>> From: Andrzej Hajda [mailto:a.hajda@samsung.com]
>>>> Sent: 2018年2月27日 16:41
>>>> To: Jun Li <jun.li@nxp.com>; gregkh@linuxfoundation.org;
>>>> robh+dt@kernel.org; heikki.krogerus@linux.intel.com;
>>>> robh+linux@roeck-us.net
>>>> Cc: mark.rutland@arm.com; yueyao@google.com; Peter Chen
>>>> <peter.chen@nxp.com>; garsilva@embeddedor.com;
>> o_leveque@orange.fr;
>>>> shufan_lee@richtek.com; linux-usb@vger.kernel.org;
>>>> devicetree@vger.kernel.org; dl-linux-imx <linux-imx@nxp.com>
>>>> Subject: Re: [PATCH v2 10/12] dt-bindings: connector: add properties
>>>> for typec power delivery
>>>>
>>>> On 26.02.2018 12:49, Li Jun wrote:
>>>>> In case of usb-c-connector with power delivery support, add
>>>>> bingdings supported by current typec driver, so user can pass all
>>>>> those properties via dt.
>>>>>
>>>>> Signed-off-by: Li Jun <jun.li@nxp.com>
>>>>> ---
>>>>> Changes for v2:
>>>>> - Added typec properties are based on general usb connector bindings[1]
>>>>>   proposed by Andrzej Hajda.
>>>>> - Use the standard unit suffixes as defined in property-units.txt.
>>>>>
>>>>> [1]
>>>>>
>> https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpa
>>>> t
>>>>
>> chwork.kernel.org%2Fpatch%2F10231447%2F&data=02%7C01%7Cjun.li%40
>>>> nxp.co
>>>>
>> m%7Cccf14a36ca6445ee5f1108d57dbde3c7%7C686ea1d3bc2b4c6fa92cd99
>>>> c5c30163
>>>>
>> 5%7C0%7C0%7C636553176880292197&sdata=2Pi0AtiwAqHQE3rGl%2Bo49K
>>>> 7yZZcp%2B
>>>>> 5bvJAknRBMGTrk%3D&reserved=0
>>>>>
>>>>>  .../bindings/connector/usb-connector.txt           | 43
>>>> ++++++++++++++++++++++
>>>>>  1 file changed, 43 insertions(+)
>>>>>
>>>>> diff --git
>>>>> a/Documentation/devicetree/bindings/connector/usb-connector.txt
>>>>> b/Documentation/devicetree/bindings/connector/usb-connector.txt
>>>>> index e1463f1..242f6df 100644
>>>>> --- a/Documentation/devicetree/bindings/connector/usb-connector.txt
>>>>> +++
>> b/Documentation/devicetree/bindings/connector/usb-connector.txt
>>>>> @@ -15,6 +15,30 @@ Optional properties:
>>>>>  - type: size of the connector, should be specified in case of USB-A,
>> USB-B
>>>>>    non-fullsize connectors: "mini", "micro".
>>>>>
>>>>> +Required properties for usb-c-connector with power delivery support:
>>>>> +- port-type: should be one of "source", "sink" or "dual".
>>>>> +- default-role: preferred power role if port-type is "dual"(drp),
>>>>> +should be
>>>>> +  "sink" or "source".
>>>> Since port carries data and power, it would be better to explicitly
>>>> mention it in names of properties which can be ambiguous.
>>>> Maybe instead of 'port-type' you can use 'power-role', for example.
>>> Port-type is align with the name of typec coding and ABI, 'power-role'
>>> is more like for the current role rather than the port's ability.
>> I am not sure what are you exactly mean by "coding and ABI", but I guess it is
>> just about Power-Delivery part of USB-C. And if you want to put this property
>> into USB node without mark it is related to PD part of USB connector, you
>> risk confusion with possible USB data related properties.
> Understood your concern, I am following typec naming conventions,
> for typec, port-type property has the same meaning as
> /sys/class/typec/portx/port_type
> which is not only for power, also for data, there are dedicated
> sys files power_role for power and data_role for data.
>
>> Simple question, what if somebody wants to add property describing USB
>> data capabilities (DFP, UFP, DRD), how should it be named?
>>
> Then we may use data-role?

Few lines above you have said -role is "for the current role rather than
the port's ability" :)

Generally my intention was to avoid such inconsistencies, for example by
using consistently
prefixes (for example: power and data) and suffixes (for example: mode
and role), which are used in specs.
We would have then:
- power_mode - for PD capabilities,
- power_role - for default/initial role,
- data_mode - for data capabilities,
- data_role - for default/initial role (as I understand specs this
property is redundant, as initial data_role is determined by power_role).

Of course if there is already well established convention, we shouldn't
change it, is there any, sysfs is well established?

>
>>>> Other thing is that default-role is required only in case of DRP, so
>>>> maybe better would be to squash it in power-role, for example:
>>>>     power-role: should be on of "source", "sink", "dual-source",
>>>> "dual-sink", in case of dual roles suffix determines preferred role.
>>> I don't know how much this squash can benefit, "dual-source/sink" is
>>> not directly showing its meaning by name.
>> Some benefit is simpler binding, no conditionally-required property.
>>
> There is already string definition for port type and preferred role parse 
> static const char * const typec_port_types[] = {
>          [TYPEC_PORT_DFP] = "source",
>          [TYPEC_PORT_UFP] = "sink",
>          [TYPEC_PORT_DRP] = "dual",
> };

I am little bit confused about enums, according typec specs DFP and UFP
are associated with flow of USB data, but DRP is about power -
Dual-Role-Power - quite misleading.
As I understand from the context it is about power capabilities.
Shouldn't be TYPEC_PORT_DFP replaced with TYPEC_PORT_SRC or
TYPEC_PORT_SOURCE, similarly UFP ?

> And I think there will be other conditionally-required properties
> to be extended later, are we going to name all of them by this way?
> Either way is OK for me, I am not sure if there is principle like we
> should avoid conditionally-required property, if we should, maybe
> "dual-preferred-source/sink" is better.

I have no strong feelings about it, it is just an idea.

>
> Hi Heikki,
> Do you have any comments/preference here?
>
>> Another question is that USB TypeC specification describes 7 different
>> "behavioral models" [1]:
>> - Source-only
> Maps "source"
>
>> - Source (Default) – strong preference toward being a Source but
>> subsequently capable of becoming a Sink using USB PD swap mechanisms.
> Only present Rp(source) when attach, can be sink only by power swap.
> Seems current code doesn't support this, to be extended.
>
>> - Sink-only
> Maps to "sink"
>
>> - Sink (Default) – strong preference toward being a Sink but subsequently
>> capable of becoming a Source using USB PD swap mechanisms.
> Only present Rd while attachment, can be source only by power swap support.
> Seems current code doesn't support this, to be extended.
>
>> - DRP: Toggling (Source/Sink)
> Maps to "dual"
>
>> - DRP: Sourcing Device
> "dual" but without USB host function(to be extended).
>
>> - DRP: Sinking Host
>>
> "dual" but without USB device function(to be extended).
>
>> How it maps to your proposed props?
>>
>> [1]: USB Type-C specification release 1.3, chapter 4.5.1.4.
>>
> Current typec and tcpm hasn't cover the full features like this.

So maybe it would be good to extend list of values, or clarify, for
example that 'source' means without PR_Swap (ie. Source-only), or maybe
add property indicating device is pr_swap capable, whatever suits better.

Regards
Andrzej

>
> Thanks
> Jun Li
>> Regards
>> Andrzej
>>
>>>>> +- src-pdos: An array of u32 with each entry providing supported
>>>>> +power
>>>>> +  source data object(PDO), the detailed bit definitions of PDO can
>>>>> +be found
>>>>> +  in "Universal Serial Bus Power Delivery Specification" chapter
>>>>> +6.4.1.2
>>>>> +  Source_Capabilities Message, the order of each entry(PDO) should
>>>>> +follow
>>>>> +  the PD spec chapter 6.4.1. Required for power source and power
>>>>> +dual
>>>> role.
>>>>> +- snk-pdos: An array of u32 with each entry providing supported
>>>>> +power
>>>>> +  sink data object(PDO), the detailed bit definitions of PDO can be
>>>>> +found in
>>>>> +  "Universal Serial Bus Power Delivery Specification" chapter
>>>>> +6.4.1.3 Sink
>>>>> +  Capabilities Message, the order of each entry(PDO) should follow
>>>>> +the PD
>>>>> +  spec chapter 6.4.1. Required for power sink and power dual role.
>>>> We should avoid magic numbers, magic numbers are bad :) If we really
>>>> need to use PDOs here, I think we can re-use PDO_* macros [1] - DTC
>>>> should be able to parse it, maybe some lifting will be necessary.
>>>>
>>>> [1]:
>>>>
>> https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fel
>>>> ix
>>>>
>> ir.bootlin.com%2Flinux%2Fv4.16-rc3%2Fsource%2Finclude%2Flinux%2Fusb%
>> 2Fpd.h%23L161&data=02%7C01%7Cjun.li%40nxp.com%7Cccf14a36ca6445e
>> e5f1108d57dbde3c7%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%
>> 7C636553176880292197&sdata=72HA33wgRyd2PMoPnZOlMatI2CuadplkYN
>>>> DDGKFSUB0%3D&reserved=0
>>>>> +- max-snk-microvolt: The max voltage the sink can support in micro
>>>>> +volts,
>>>>> +  required for power sink and power dual role.
>>>>> +- max-snk-microamp: The max current the sink can support in micro
>>>>> +amps,
>>>>> +  required for power sink and power dual role.
>>>>> +- max-snk-microwatt-hours: The max power the sink can support in
>>>>> +micro
>>>>> +  Watt-hours, required for power sink and power dual role.
>>>>> +- op-snk-microwatt-hours: Sink required operating power in micro
>>>>> +Watt-hours,
>>>>> +  if source offered power is less then it, Capability Mismatch is
>>>>> +set,
>>>>> +  required for power sink and power dual role.
>>>> What is the relation between above properties and PDOs specified
>> earlier?
>>>> Are you sure all these props are required?
>>>>
>>> Sorry, with latest tcpm code, those props are not required, will remove
>> them.
>>> Jun Li
>>>> And general remark regarding all above properties. For me, most of
>>>> them are specific not to the port but to devices responsible for
>>>> power
>>>> management: chargers, pmics,....
>>>> In many cases these properties are redundant with devices capabilities.
>>>> On the other side I guess in many cases it may be convenient to put
>>>> them here, so I am not sure what is better :)
>>>>
>>>> Regards
>>>> Andrzej
>>>>
>>>>> +
>>>>>  Required nodes:
>>>>>  - any data bus to the connector should be modeled using the OF
>>>>> graph
>>>> bindings
>>>>>    specified in bindings/graph.txt, unless the bus is between parent
>>>>> node and @@ -73,3 +97,22 @@ ccic: s2mm005@33 {
>>>>>  		};
>>>>>  	};
>>>>>  };
>>>>> +
>>>>> +3. USB-C connector attached to a typec port controller(ptn5110),
>>>>> +which has power delivery support and enables drp.
>>>>> +
>>>>> +typec: ptn5110@50 {
>>>>> +	...
>>>>> +	usb_con: connector {
>>>>> +		compatible = "usb-c-connector";
>>>>> +		label = "USB-C";
>>>>> +		port-type = "dual";
>>>>> +		default-role = "sink";
>>>>> +		src-pdos = <0x380190c8>;
>>>>> +		snk-pdos = <0x380190c8 0x3802d0c8>;
>>>>> +		max-snk-microvolt = <9000>;
>>>>> +		max-snk-microamp = <2000>;
>>>>> +		max-snk-microwatt-hours = <18000>;
>>>>> +		op-snk-microwatt-hours = <9000>;
>>>>> +	};
>>>>> +};

[v2,10/12] dt-bindings: connector: add properties for typec power delivery

[Andrzej Hajda]

On 06.03.2018 10:38, Jun Li wrote:
> Hi
>> -----Original Message-----
>> From: Andrzej Hajda [mailto:a.hajda@samsung.com]
>> Sent: 2018年3月5日 17:59
>> To: Jun Li <jun.li@nxp.com>; gregkh@linuxfoundation.org;
>> robh+dt@kernel.org; heikki.krogerus@linux.intel.com; linux@roeck-us.net
>> Cc: mark.rutland@arm.com; yueyao@google.com; Peter Chen
>> <peter.chen@nxp.com>; garsilva@embeddedor.com; o_leveque@orange.fr;
>> shufan_lee@richtek.com; linux-usb@vger.kernel.org;
>> devicetree@vger.kernel.org; dl-linux-imx <linux-imx@nxp.com>
>> Subject: Re: [PATCH v2 10/12] dt-bindings: connector: add properties for
>> typec power delivery
>>
>> On 05.03.2018 08:00, Jun Li wrote:
>>>> -----Original Message-----
>>>> From: Andrzej Hajda [mailto:a.hajda@samsung.com]
>>>> Sent: 2018年2月27日 16:41
>>>> To: Jun Li <jun.li@nxp.com>; gregkh@linuxfoundation.org;
>>>> robh+dt@kernel.org; heikki.krogerus@linux.intel.com;
>>>> robh+linux@roeck-us.net
>>>> Cc: mark.rutland@arm.com; yueyao@google.com; Peter Chen
>>>> <peter.chen@nxp.com>; garsilva@embeddedor.com;
>> o_leveque@orange.fr;
>>>> shufan_lee@richtek.com; linux-usb@vger.kernel.org;
>>>> devicetree@vger.kernel.org; dl-linux-imx <linux-imx@nxp.com>
>>>> Subject: Re: [PATCH v2 10/12] dt-bindings: connector: add properties
>>>> for typec power delivery
>>>>
>>>> On 26.02.2018 12:49, Li Jun wrote:
>>>>> In case of usb-c-connector with power delivery support, add
>>>>> bingdings supported by current typec driver, so user can pass all
>>>>> those properties via dt.
>>>>>
>>>>> Signed-off-by: Li Jun <jun.li@nxp.com>
>>>>> ---
>>>>> Changes for v2:
>>>>> - Added typec properties are based on general usb connector bindings[1]
>>>>>   proposed by Andrzej Hajda.
>>>>> - Use the standard unit suffixes as defined in property-units.txt.
>>>>>
>>>>> [1]
>>>>>
>> https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpa
>>>> t
>>>>
>> chwork.kernel.org%2Fpatch%2F10231447%2F&data=02%7C01%7Cjun.li%40
>>>> nxp.co
>>>>
>> m%7Cccf14a36ca6445ee5f1108d57dbde3c7%7C686ea1d3bc2b4c6fa92cd99
>>>> c5c30163
>>>>
>> 5%7C0%7C0%7C636553176880292197&sdata=2Pi0AtiwAqHQE3rGl%2Bo49K
>>>> 7yZZcp%2B
>>>>> 5bvJAknRBMGTrk%3D&reserved=0
>>>>>
>>>>>  .../bindings/connector/usb-connector.txt           | 43
>>>> ++++++++++++++++++++++
>>>>>  1 file changed, 43 insertions(+)
>>>>>
>>>>> diff --git
>>>>> a/Documentation/devicetree/bindings/connector/usb-connector.txt
>>>>> b/Documentation/devicetree/bindings/connector/usb-connector.txt
>>>>> index e1463f1..242f6df 100644
>>>>> --- a/Documentation/devicetree/bindings/connector/usb-connector.txt
>>>>> +++
>> b/Documentation/devicetree/bindings/connector/usb-connector.txt
>>>>> @@ -15,6 +15,30 @@ Optional properties:
>>>>>  - type: size of the connector, should be specified in case of USB-A,
>> USB-B
>>>>>    non-fullsize connectors: "mini", "micro".
>>>>>
>>>>> +Required properties for usb-c-connector with power delivery support:
>>>>> +- port-type: should be one of "source", "sink" or "dual".
>>>>> +- default-role: preferred power role if port-type is "dual"(drp),
>>>>> +should be
>>>>> +  "sink" or "source".
>>>> Since port carries data and power, it would be better to explicitly
>>>> mention it in names of properties which can be ambiguous.
>>>> Maybe instead of 'port-type' you can use 'power-role', for example.
>>> Port-type is align with the name of typec coding and ABI, 'power-role'
>>> is more like for the current role rather than the port's ability.
>> I am not sure what are you exactly mean by "coding and ABI", but I guess it is
>> just about Power-Delivery part of USB-C. And if you want to put this property
>> into USB node without mark it is related to PD part of USB connector, you
>> risk confusion with possible USB data related properties.
> Understood your concern, I am following typec naming conventions,
> for typec, port-type property has the same meaning as
> /sys/class/typec/portx/port_type
> which is not only for power, also for data, there are dedicated
> sys files power_role for power and data_role for data.
>
>> Simple question, what if somebody wants to add property describing USB
>> data capabilities (DFP, UFP, DRD), how should it be named?
>>
> Then we may use data-role?

Few lines above you have said -role is "for the current role rather than
the port's ability" :)

Generally my intention was to avoid such inconsistencies, for example by
using consistently
prefixes (for example: power and data) and suffixes (for example: mode
and role), which are used in specs.
We would have then:
- power_mode - for PD capabilities,
- power_role - for default/initial role,
- data_mode - for data capabilities,
- data_role - for default/initial role (as I understand specs this
property is redundant, as initial data_role is determined by power_role).

Of course if there is already well established convention, we shouldn't
change it, is there any, sysfs is well established?

>
>>>> Other thing is that default-role is required only in case of DRP, so
>>>> maybe better would be to squash it in power-role, for example:
>>>>     power-role: should be on of "source", "sink", "dual-source",
>>>> "dual-sink", in case of dual roles suffix determines preferred role.
>>> I don't know how much this squash can benefit, "dual-source/sink" is
>>> not directly showing its meaning by name.
>> Some benefit is simpler binding, no conditionally-required property.
>>
> There is already string definition for port type and preferred role parse 
> static const char * const typec_port_types[] = {
>          [TYPEC_PORT_DFP] = "source",
>          [TYPEC_PORT_UFP] = "sink",
>          [TYPEC_PORT_DRP] = "dual",
> };

I am little bit confused about enums, according typec specs DFP and UFP
are associated with flow of USB data, but DRP is about power -
Dual-Role-Power - quite misleading.
As I understand from the context it is about power capabilities.
Shouldn't be TYPEC_PORT_DFP replaced with TYPEC_PORT_SRC or
TYPEC_PORT_SOURCE, similarly UFP ?

> And I think there will be other conditionally-required properties
> to be extended later, are we going to name all of them by this way?
> Either way is OK for me, I am not sure if there is principle like we
> should avoid conditionally-required property, if we should, maybe
> "dual-preferred-source/sink" is better.

I have no strong feelings about it, it is just an idea.

>
> Hi Heikki,
> Do you have any comments/preference here?
>
>> Another question is that USB TypeC specification describes 7 different
>> "behavioral models" [1]:
>> - Source-only
> Maps "source"
>
>> - Source (Default) – strong preference toward being a Source but
>> subsequently capable of becoming a Sink using USB PD swap mechanisms.
> Only present Rp(source) when attach, can be sink only by power swap.
> Seems current code doesn't support this, to be extended.
>
>> - Sink-only
> Maps to "sink"
>
>> - Sink (Default) – strong preference toward being a Sink but subsequently
>> capable of becoming a Source using USB PD swap mechanisms.
> Only present Rd while attachment, can be source only by power swap support.
> Seems current code doesn't support this, to be extended.
>
>> - DRP: Toggling (Source/Sink)
> Maps to "dual"
>
>> - DRP: Sourcing Device
> "dual" but without USB host function(to be extended).
>
>> - DRP: Sinking Host
>>
> "dual" but without USB device function(to be extended).
>
>> How it maps to your proposed props?
>>
>> [1]: USB Type-C specification release 1.3, chapter 4.5.1.4.
>>
> Current typec and tcpm hasn't cover the full features like this.

So maybe it would be good to extend list of values, or clarify, for
example that 'source' means without PR_Swap (ie. Source-only), or maybe
add property indicating device is pr_swap capable, whatever suits better.

Regards
Andrzej

>
> Thanks
> Jun Li
>> Regards
>> Andrzej
>>
>>>>> +- src-pdos: An array of u32 with each entry providing supported
>>>>> +power
>>>>> +  source data object(PDO), the detailed bit definitions of PDO can
>>>>> +be found
>>>>> +  in "Universal Serial Bus Power Delivery Specification" chapter
>>>>> +6.4.1.2
>>>>> +  Source_Capabilities Message, the order of each entry(PDO) should
>>>>> +follow
>>>>> +  the PD spec chapter 6.4.1. Required for power source and power
>>>>> +dual
>>>> role.
>>>>> +- snk-pdos: An array of u32 with each entry providing supported
>>>>> +power
>>>>> +  sink data object(PDO), the detailed bit definitions of PDO can be
>>>>> +found in
>>>>> +  "Universal Serial Bus Power Delivery Specification" chapter
>>>>> +6.4.1.3 Sink
>>>>> +  Capabilities Message, the order of each entry(PDO) should follow
>>>>> +the PD
>>>>> +  spec chapter 6.4.1. Required for power sink and power dual role.
>>>> We should avoid magic numbers, magic numbers are bad :) If we really
>>>> need to use PDOs here, I think we can re-use PDO_* macros [1] - DTC
>>>> should be able to parse it, maybe some lifting will be necessary.
>>>>
>>>> [1]:
>>>>
>> https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fel
>>>> ix
>>>>
>> ir.bootlin.com%2Flinux%2Fv4.16-rc3%2Fsource%2Finclude%2Flinux%2Fusb%
>> 2Fpd.h%23L161&data=02%7C01%7Cjun.li%40nxp.com%7Cccf14a36ca6445e
>> e5f1108d57dbde3c7%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%
>> 7C636553176880292197&sdata=72HA33wgRyd2PMoPnZOlMatI2CuadplkYN
>>>> DDGKFSUB0%3D&reserved=0
>>>>> +- max-snk-microvolt: The max voltage the sink can support in micro
>>>>> +volts,
>>>>> +  required for power sink and power dual role.
>>>>> +- max-snk-microamp: The max current the sink can support in micro
>>>>> +amps,
>>>>> +  required for power sink and power dual role.
>>>>> +- max-snk-microwatt-hours: The max power the sink can support in
>>>>> +micro
>>>>> +  Watt-hours, required for power sink and power dual role.
>>>>> +- op-snk-microwatt-hours: Sink required operating power in micro
>>>>> +Watt-hours,
>>>>> +  if source offered power is less then it, Capability Mismatch is
>>>>> +set,
>>>>> +  required for power sink and power dual role.
>>>> What is the relation between above properties and PDOs specified
>> earlier?
>>>> Are you sure all these props are required?
>>>>
>>> Sorry, with latest tcpm code, those props are not required, will remove
>> them.
>>> Jun Li
>>>> And general remark regarding all above properties. For me, most of
>>>> them are specific not to the port but to devices responsible for
>>>> power
>>>> management: chargers, pmics,....
>>>> In many cases these properties are redundant with devices capabilities.
>>>> On the other side I guess in many cases it may be convenient to put
>>>> them here, so I am not sure what is better :)
>>>>
>>>> Regards
>>>> Andrzej
>>>>
>>>>> +
>>>>>  Required nodes:
>>>>>  - any data bus to the connector should be modeled using the OF
>>>>> graph
>>>> bindings
>>>>>    specified in bindings/graph.txt, unless the bus is between parent
>>>>> node and @@ -73,3 +97,22 @@ ccic: s2mm005@33 {
>>>>>  		};
>>>>>  	};
>>>>>  };
>>>>> +
>>>>> +3. USB-C connector attached to a typec port controller(ptn5110),
>>>>> +which has power delivery support and enables drp.
>>>>> +
>>>>> +typec: ptn5110@50 {
>>>>> +	...
>>>>> +	usb_con: connector {
>>>>> +		compatible = "usb-c-connector";
>>>>> +		label = "USB-C";
>>>>> +		port-type = "dual";
>>>>> +		default-role = "sink";
>>>>> +		src-pdos = <0x380190c8>;
>>>>> +		snk-pdos = <0x380190c8 0x3802d0c8>;
>>>>> +		max-snk-microvolt = <9000>;
>>>>> +		max-snk-microamp = <2000>;
>>>>> +		max-snk-microwatt-hours = <18000>;
>>>>> +		op-snk-microwatt-hours = <9000>;
>>>>> +	};
>>>>> +};
---
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

Re: [PATCH v2 10/12] dt-bindings: connector: add properties for typec power delivery

[Heikki Krogerus]

[-- Attachment #1: Type: text/plain, Size: 4433 bytes --]

Hi guys,

On Tue, Mar 06, 2018 at 09:38:59AM +0000, Jun Li wrote:
> > >>> diff --git
> > >>> a/Documentation/devicetree/bindings/connector/usb-connector.txt
> > >>> b/Documentation/devicetree/bindings/connector/usb-connector.txt
> > >>> index e1463f1..242f6df 100644
> > >>> --- a/Documentation/devicetree/bindings/connector/usb-connector.txt
> > >>> +++
> > b/Documentation/devicetree/bindings/connector/usb-connector.txt
> > >>> @@ -15,6 +15,30 @@ Optional properties:
> > >>>  - type: size of the connector, should be specified in case of USB-A,
> > USB-B
> > >>>    non-fullsize connectors: "mini", "micro".
> > >>>
> > >>> +Required properties for usb-c-connector with power delivery support:
> > >>> +- port-type: should be one of "source", "sink" or "dual".
> > >>> +- default-role: preferred power role if port-type is "dual"(drp),
> > >>> +should be
> > >>> +  "sink" or "source".
> > >> Since port carries data and power, it would be better to explicitly
> > >> mention it in names of properties which can be ambiguous.
> > >> Maybe instead of 'port-type' you can use 'power-role', for example.
> > > Port-type is align with the name of typec coding and ABI, 'power-role'
> > > is more like for the current role rather than the port's ability.
> > 
> > I am not sure what are you exactly mean by "coding and ABI", but I guess it is
> > just about Power-Delivery part of USB-C. And if you want to put this property
> > into USB node without mark it is related to PD part of USB connector, you
> > risk confusion with possible USB data related properties.
> 
> Understood your concern, I am following typec naming conventions,
> for typec, port-type property has the same meaning as
> /sys/class/typec/portx/port_type
> which is not only for power, also for data, there are dedicated
> sys files power_role for power and data_role for data.
> 
> > Simple question, what if somebody wants to add property describing USB
> > data capabilities (DFP, UFP, DRD), how should it be named?
> > 
> 
> Then we may use data-role?
> 
> > >
> > >> Other thing is that default-role is required only in case of DRP, so
> > >> maybe better would be to squash it in power-role, for example:
> > >> ?????? power-role: should be on of "source", "sink", "dual-source",
> > >> "dual-sink", in case of dual roles suffix determines preferred role.
> > > I don't know how much this squash can benefit, "dual-source/sink" is
> > > not directly showing its meaning by name.
> > 
> > Some benefit is simpler binding, no conditionally-required property.
> > 
> 
> There is already string definition for port type and preferred role parse 
> static const char * const typec_port_types[] = {
>          [TYPEC_PORT_DFP] = "source",
>          [TYPEC_PORT_UFP] = "sink",
>          [TYPEC_PORT_DRP] = "dual",
> };
> And I think there will be other conditionally-required properties
> to be extended later, are we going to name all of them by this way?
> Either way is OK for me, I am not sure if there is principle like we
> should avoid conditionally-required property, if we should, maybe
> "dual-preferred-source/sink" is better.
> 
> Hi Heikki,
> Do you have any comments/preference here?

In the first versions of USB Type-C specification the data and power
roles were in practice coupled together. There were no data role
specific modes, just DFP, UFP and DRP. However, v1.2 of the spec.
introduced separate modes for the data roles as well, and I have a
patch for that (attached).

If you are asking my opinion, the data role must be handled as
separate capability of the port, i.e. you probable want to have
separate properties for the power role and data role, even if we did
not support that yet in the class code. Don't use "port-type" name,
just call them "power-role" and "data-role" from now on.

The default-role should tell the state machines whether Try.SNK or
Try.SRC states should be used or not. Perhaps you should have boolean
property for both: "try-snk" and "try-src" (note: both can not be true).

Final note. I think it would make sense to clearly separate the USB
Type-C specific properties from USB PD ones. Though it is unlikely
that we will see USB PD being used with other connector types besides
Type-C anymore, USB Type-C connectors will still definitely not
always support USB PD, but when USB PD is not supported, we still need
to know the data-role, power-role, default-role (or try-snk, try-src),
etc.


Br,

-- 
heikki

[-- Attachment #2: 0001-usb-typec-Separate-the-definitions-for-data-and-powe.patch --]
[-- Type: text/plain, Size: 11253 bytes --]

>From 4f7652ba8a3d4e8f7bd30cf7ca8beba6af5ad873 Mon Sep 17 00:00:00 2001
From: Heikki Krogerus <heikki.krogerus@linux.intel.com>
Date: Tue, 2 Jan 2018 17:07:58 +0300
Subject: [PATCH] usb: typec: Separate the definitions for data and power roles

USB Type-C specification v1.2 separated the power and data
roles more clearly. Dual-Role-Data term was introduced, and
the meaning of DRP was changed from "Dual-Role-Port" to
"Dual-Role-Power".

In order to allow the port drivers to describe the
capabilities of the ports more clearly according to the
newest specifications, introducing separate definitions for
the data roles.

Signed-off-by: Heikki Krogerus <heikki.krogerus@linux.intel.com>
---
 drivers/usb/typec/class.c           | 56 ++++++++++++++++++++++---------------
 drivers/usb/typec/fusb302/fusb302.c |  1 +
 drivers/usb/typec/tcpm.c            |  9 +++---
 drivers/usb/typec/tps6598x.c        | 26 +++++++++++------
 drivers/usb/typec/typec_wcove.c     |  1 +
 drivers/usb/typec/ucsi/ucsi.c       | 13 +++++++--
 include/linux/usb/tcpm.h            |  1 +
 include/linux/usb/typec.h           | 14 ++++++++--
 8 files changed, 80 insertions(+), 41 deletions(-)

diff --git a/drivers/usb/typec/class.c b/drivers/usb/typec/class.c
index 2620a694704f..53df10df2f9d 100644
--- a/drivers/usb/typec/class.c
+++ b/drivers/usb/typec/class.c
@@ -282,10 +282,10 @@ typec_altmode_roles_show(struct device *dev, struct device_attribute *attr,
 	ssize_t ret;
 
 	switch (mode->roles) {
-	case TYPEC_PORT_DFP:
+	case TYPEC_PORT_SRC:
 		ret = sprintf(buf, "source\n");
 		break;
-	case TYPEC_PORT_UFP:
+	case TYPEC_PORT_SNK:
 		ret = sprintf(buf, "sink\n");
 		break;
 	case TYPEC_PORT_DRP:
@@ -797,14 +797,14 @@ static const char * const typec_data_roles[] = {
 };
 
 static const char * const typec_port_types[] = {
-	[TYPEC_PORT_DFP] = "source",
-	[TYPEC_PORT_UFP] = "sink",
+	[TYPEC_PORT_SRC] = "source",
+	[TYPEC_PORT_SNK] = "sink",
 	[TYPEC_PORT_DRP] = "dual",
 };
 
 static const char * const typec_port_types_drp[] = {
-	[TYPEC_PORT_DFP] = "dual [source] sink",
-	[TYPEC_PORT_UFP] = "dual source [sink]",
+	[TYPEC_PORT_SRC] = "dual [source] sink",
+	[TYPEC_PORT_SNK] = "dual source [sink]",
 	[TYPEC_PORT_DRP] = "[dual] source sink",
 };
 
@@ -875,9 +875,7 @@ static ssize_t data_role_store(struct device *dev,
 		return ret;
 
 	mutex_lock(&port->port_type_lock);
-	if (port->port_type != TYPEC_PORT_DRP) {
-		dev_dbg(dev, "port type fixed at \"%s\"",
-			     typec_port_types[port->port_type]);
+	if (port->cap->data != TYPEC_PORT_DRD) {
 		ret = -EOPNOTSUPP;
 		goto unlock_and_ret;
 	}
@@ -897,7 +895,7 @@ static ssize_t data_role_show(struct device *dev,
 {
 	struct typec_port *port = to_typec_port(dev);
 
-	if (port->cap->type == TYPEC_PORT_DRP)
+	if (port->cap->data == TYPEC_PORT_DRD)
 		return sprintf(buf, "%s\n", port->data_role == TYPEC_HOST ?
 			       "[host] device" : "host [device]");
 
@@ -1328,7 +1326,6 @@ struct typec_port *typec_register_port(struct device *parent,
 				       const struct typec_capability *cap)
 {
 	struct typec_port *port;
-	int role;
 	int ret;
 	int id;
 
@@ -1354,21 +1351,36 @@ struct typec_port *typec_register_port(struct device *parent,
 		goto err_mux;
 	}
 
-	if (cap->type == TYPEC_PORT_DFP)
-		role = TYPEC_SOURCE;
-	else if (cap->type == TYPEC_PORT_UFP)
-		role = TYPEC_SINK;
-	else
-		role = cap->prefer_role;
-
-	if (role == TYPEC_SOURCE) {
-		port->data_role = TYPEC_HOST;
+	switch (cap->type) {
+	case TYPEC_PORT_SRC:
 		port->pwr_role = TYPEC_SOURCE;
 		port->vconn_role = TYPEC_SOURCE;
-	} else {
-		port->data_role = TYPEC_DEVICE;
+		break;
+	case TYPEC_PORT_SNK:
 		port->pwr_role = TYPEC_SINK;
 		port->vconn_role = TYPEC_SINK;
+		break;
+	case TYPEC_PORT_DRP:
+		if (cap->prefer_role != TYPEC_NO_PREFERRED_ROLE)
+			port->pwr_role = cap->prefer_role;
+		else
+			port->pwr_role = TYPEC_SINK;
+		break;
+	}
+
+	switch (cap->data) {
+	case TYPEC_PORT_DFP:
+		port->data_role = TYPEC_HOST;
+		break;
+	case TYPEC_PORT_UFP:
+		port->data_role = TYPEC_DEVICE;
+		break;
+	case TYPEC_PORT_DRD:
+		if (cap->prefer_role == TYPEC_SOURCE)
+			port->data_role = TYPEC_HOST;
+		else
+			port->data_role = TYPEC_DEVICE;
+		break;
 	}
 
 	port->id = id;
diff --git a/drivers/usb/typec/fusb302/fusb302.c b/drivers/usb/typec/fusb302/fusb302.c
index b267b907bf24..76c9d955fa40 100644
--- a/drivers/usb/typec/fusb302/fusb302.c
+++ b/drivers/usb/typec/fusb302/fusb302.c
@@ -1230,6 +1230,7 @@ static const struct tcpc_config fusb302_tcpc_config = {
 	.max_snk_mw = 15000,
 	.operating_snk_mw = 2500,
 	.type = TYPEC_PORT_DRP,
+	.data = TYPEC_PORT_DRD,
 	.default_role = TYPEC_SINK,
 	.alt_modes = NULL,
 };
diff --git a/drivers/usb/typec/tcpm.c b/drivers/usb/typec/tcpm.c
index bfcaf6618a1f..0e1d92381522 100644
--- a/drivers/usb/typec/tcpm.c
+++ b/drivers/usb/typec/tcpm.c
@@ -350,7 +350,7 @@ static enum tcpm_state tcpm_default_state(struct tcpm_port *port)
 		else if (port->tcpc->config->default_role == TYPEC_SINK)
 			return SNK_UNATTACHED;
 		/* Fall through to return SRC_UNATTACHED */
-	} else if (port->port_type == TYPEC_PORT_UFP) {
+	} else if (port->port_type == TYPEC_PORT_SNK) {
 		return SNK_UNATTACHED;
 	}
 	return SRC_UNATTACHED;
@@ -2264,7 +2264,7 @@ static inline enum tcpm_state unattached_state(struct tcpm_port *port)
 			return SRC_UNATTACHED;
 		else
 			return SNK_UNATTACHED;
-	} else if (port->port_type == TYPEC_PORT_DFP) {
+	} else if (port->port_type == TYPEC_PORT_SRC) {
 		return SRC_UNATTACHED;
 	}
 
@@ -3554,11 +3554,11 @@ static int tcpm_port_type_set(const struct typec_capability *cap,
 
 	if (!port->connected) {
 		tcpm_set_state(port, PORT_RESET, 0);
-	} else if (type == TYPEC_PORT_UFP) {
+	} else if (type == TYPEC_PORT_SNK) {
 		if (!(port->pwr_role == TYPEC_SINK &&
 		      port->data_role == TYPEC_DEVICE))
 			tcpm_set_state(port, PORT_RESET, 0);
-	} else if (type == TYPEC_PORT_DFP) {
+	} else if (type == TYPEC_PORT_SRC) {
 		if (!(port->pwr_role == TYPEC_SOURCE &&
 		      port->data_role == TYPEC_HOST))
 			tcpm_set_state(port, PORT_RESET, 0);
@@ -3748,6 +3748,7 @@ struct tcpm_port *tcpm_register_port(struct device *dev, struct tcpc_dev *tcpc)
 
 	port->typec_caps.prefer_role = tcpc->config->default_role;
 	port->typec_caps.type = tcpc->config->type;
+	port->typec_caps.data = tcpc->config->data;
 	port->typec_caps.revision = 0x0120;	/* Type-C spec release 1.2 */
 	port->typec_caps.pd_revision = 0x0200;	/* USB-PD spec release 2.0 */
 	port->typec_caps.dr_set = tcpm_dr_set;
diff --git a/drivers/usb/typec/tps6598x.c b/drivers/usb/typec/tps6598x.c
index 37a15c14a6c6..8b8406867c02 100644
--- a/drivers/usb/typec/tps6598x.c
+++ b/drivers/usb/typec/tps6598x.c
@@ -393,31 +393,39 @@ static int tps6598x_probe(struct i2c_client *client)
 	if (ret < 0)
 		return ret;
 
+	tps->typec_cap.revision = USB_TYPEC_REV_1_2;
+	tps->typec_cap.pd_revision = 0x200;
+	tps->typec_cap.prefer_role = TYPEC_NO_PREFERRED_ROLE;
+	tps->typec_cap.pr_set = tps6598x_pr_set;
+	tps->typec_cap.dr_set = tps6598x_dr_set;
+
 	switch (TPS_SYSCONF_PORTINFO(conf)) {
 	case TPS_PORTINFO_SINK_ACCESSORY:
 	case TPS_PORTINFO_SINK:
-		tps->typec_cap.type = TYPEC_PORT_UFP;
+		tps->typec_cap.type = TYPEC_PORT_SNK;
+		tps->typec_cap.data = TYPEC_PORT_UFP;
 		break;
 	case TPS_PORTINFO_DRP_UFP_DRD:
 	case TPS_PORTINFO_DRP_DFP_DRD:
-		tps->typec_cap.dr_set = tps6598x_dr_set;
-		/* fall through */
+		tps->typec_cap.type = TYPEC_PORT_DRP;
+		tps->typec_cap.data = TYPEC_PORT_DRD;
+		break;
 	case TPS_PORTINFO_DRP_UFP:
+		tps->typec_cap.type = TYPEC_PORT_DRP;
+		tps->typec_cap.data = TYPEC_PORT_UFP;
+		break;
 	case TPS_PORTINFO_DRP_DFP:
-		tps->typec_cap.pr_set = tps6598x_pr_set;
 		tps->typec_cap.type = TYPEC_PORT_DRP;
+		tps->typec_cap.data = TYPEC_PORT_DFP;
 		break;
 	case TPS_PORTINFO_SOURCE:
-		tps->typec_cap.type = TYPEC_PORT_DFP;
+		tps->typec_cap.type = TYPEC_PORT_SRC;
+		tps->typec_cap.data = TYPEC_PORT_DFP;
 		break;
 	default:
 		return -ENODEV;
 	}
 
-	tps->typec_cap.revision = USB_TYPEC_REV_1_2;
-	tps->typec_cap.pd_revision = 0x200;
-	tps->typec_cap.prefer_role = TYPEC_NO_PREFERRED_ROLE;
-
 	tps->port = typec_register_port(&client->dev, &tps->typec_cap);
 	if (IS_ERR(tps->port))
 		return PTR_ERR(tps->port);
diff --git a/drivers/usb/typec/typec_wcove.c b/drivers/usb/typec/typec_wcove.c
index 2e990e0d917d..19cca7f1b2c5 100644
--- a/drivers/usb/typec/typec_wcove.c
+++ b/drivers/usb/typec/typec_wcove.c
@@ -572,6 +572,7 @@ static struct tcpc_config wcove_typec_config = {
 	.operating_snk_mw = 15000,
 
 	.type = TYPEC_PORT_DRP,
+	.data = TYPEC_PORT_DRD,
 	.default_role = TYPEC_SINK,
 };
 
diff --git a/drivers/usb/typec/ucsi/ucsi.c b/drivers/usb/typec/ucsi/ucsi.c
index 69d544cfcd45..bf0977fbd100 100644
--- a/drivers/usb/typec/ucsi/ucsi.c
+++ b/drivers/usb/typec/ucsi/ucsi.c
@@ -592,11 +592,18 @@ static int ucsi_register_port(struct ucsi *ucsi, int index)
 		return ret;
 
 	if (con->cap.op_mode & UCSI_CONCAP_OPMODE_DRP)
-		cap->type = TYPEC_PORT_DRP;
+		cap->data = TYPEC_PORT_DRD;
 	else if (con->cap.op_mode & UCSI_CONCAP_OPMODE_DFP)
-		cap->type = TYPEC_PORT_DFP;
+		cap->data = TYPEC_PORT_DFP;
 	else if (con->cap.op_mode & UCSI_CONCAP_OPMODE_UFP)
-		cap->type = TYPEC_PORT_UFP;
+		cap->data = TYPEC_PORT_UFP;
+
+	if (con->cap.provider && con->cap.consumer)
+		cap->type = TYPEC_PORT_DRP;
+	else if (con->cap.provider)
+		cap->type = TYPEC_PORT_SRC;
+	else if (con->cap.consumer)
+		cap->type = TYPEC_PORT_SNK;
 
 	cap->revision = ucsi->cap.typec_version;
 	cap->pd_revision = ucsi->cap.pd_version;
diff --git a/include/linux/usb/tcpm.h b/include/linux/usb/tcpm.h
index fe3508e6e1df..f0d839daeaea 100644
--- a/include/linux/usb/tcpm.h
+++ b/include/linux/usb/tcpm.h
@@ -91,6 +91,7 @@ struct tcpc_config {
 	unsigned int operating_snk_mw;
 
 	enum typec_port_type type;
+	enum typec_port_data data;
 	enum typec_role default_role;
 	bool try_role_hw;	/* try.{src,snk} implemented in hardware */
 
diff --git a/include/linux/usb/typec.h b/include/linux/usb/typec.h
index 2408e5c2ed91..672b39bb0adc 100644
--- a/include/linux/usb/typec.h
+++ b/include/linux/usb/typec.h
@@ -22,9 +22,15 @@ struct typec_port;
 struct fwnode_handle;
 
 enum typec_port_type {
+	TYPEC_PORT_SRC,
+	TYPEC_PORT_SNK,
+	TYPEC_PORT_DRP,
+};
+
+enum typec_port_data {
 	TYPEC_PORT_DFP,
 	TYPEC_PORT_UFP,
-	TYPEC_PORT_DRP,
+	TYPEC_PORT_DRD,
 };
 
 enum typec_plug_type {
@@ -186,10 +192,11 @@ struct typec_partner_desc {
 
 /*
  * struct typec_capability - USB Type-C Port Capabilities
- * @role: DFP (Host-only), UFP (Device-only) or DRP (Dual Role)
+ * @type: Supported power role of the port
+ * @data: Supported data role of the port
  * @revision: USB Type-C Specification release. Binary coded decimal
  * @pd_revision: USB Power Delivery Specification revision if supported
- * @prefer_role: Initial role preference
+ * @prefer_role: Initial role preference (DRP ports).
  * @accessory: Supported Accessory Modes
  * @sw: Cable plug orientation switch
  * @mux: Multiplexer switch for Alternate/Accessory Modes
@@ -205,6 +212,7 @@ struct typec_partner_desc {
  */
 struct typec_capability {
 	enum typec_port_type	type;
+	enum typec_port_data	data;
 	u16			revision; /* 0120H = "1.2" */
 	u16			pd_revision; /* 0300H = "3.0" */
 	int			prefer_role;
-- 
2.16.1

[v2,10/12] dt-bindings: connector: add properties for typec power delivery

[Heikki Krogerus]

Hi guys,

On Tue, Mar 06, 2018 at 09:38:59AM +0000, Jun Li wrote:
> > >>> diff --git
> > >>> a/Documentation/devicetree/bindings/connector/usb-connector.txt
> > >>> b/Documentation/devicetree/bindings/connector/usb-connector.txt
> > >>> index e1463f1..242f6df 100644
> > >>> --- a/Documentation/devicetree/bindings/connector/usb-connector.txt
> > >>> +++
> > b/Documentation/devicetree/bindings/connector/usb-connector.txt
> > >>> @@ -15,6 +15,30 @@ Optional properties:
> > >>>  - type: size of the connector, should be specified in case of USB-A,
> > USB-B
> > >>>    non-fullsize connectors: "mini", "micro".
> > >>>
> > >>> +Required properties for usb-c-connector with power delivery support:
> > >>> +- port-type: should be one of "source", "sink" or "dual".
> > >>> +- default-role: preferred power role if port-type is "dual"(drp),
> > >>> +should be
> > >>> +  "sink" or "source".
> > >> Since port carries data and power, it would be better to explicitly
> > >> mention it in names of properties which can be ambiguous.
> > >> Maybe instead of 'port-type' you can use 'power-role', for example.
> > > Port-type is align with the name of typec coding and ABI, 'power-role'
> > > is more like for the current role rather than the port's ability.
> > 
> > I am not sure what are you exactly mean by "coding and ABI", but I guess it is
> > just about Power-Delivery part of USB-C. And if you want to put this property
> > into USB node without mark it is related to PD part of USB connector, you
> > risk confusion with possible USB data related properties.
> 
> Understood your concern, I am following typec naming conventions,
> for typec, port-type property has the same meaning as
> /sys/class/typec/portx/port_type
> which is not only for power, also for data, there are dedicated
> sys files power_role for power and data_role for data.
> 
> > Simple question, what if somebody wants to add property describing USB
> > data capabilities (DFP, UFP, DRD), how should it be named?
> > 
> 
> Then we may use data-role?
> 
> > >
> > >> Other thing is that default-role is required only in case of DRP, so
> > >> maybe better would be to squash it in power-role, for example:
> > >> ?????? power-role: should be on of "source", "sink", "dual-source",
> > >> "dual-sink", in case of dual roles suffix determines preferred role.
> > > I don't know how much this squash can benefit, "dual-source/sink" is
> > > not directly showing its meaning by name.
> > 
> > Some benefit is simpler binding, no conditionally-required property.
> > 
> 
> There is already string definition for port type and preferred role parse 
> static const char * const typec_port_types[] = {
>          [TYPEC_PORT_DFP] = "source",
>          [TYPEC_PORT_UFP] = "sink",
>          [TYPEC_PORT_DRP] = "dual",
> };
> And I think there will be other conditionally-required properties
> to be extended later, are we going to name all of them by this way?
> Either way is OK for me, I am not sure if there is principle like we
> should avoid conditionally-required property, if we should, maybe
> "dual-preferred-source/sink" is better.
> 
> Hi Heikki,
> Do you have any comments/preference here?

In the first versions of USB Type-C specification the data and power
roles were in practice coupled together. There were no data role
specific modes, just DFP, UFP and DRP. However, v1.2 of the spec.
introduced separate modes for the data roles as well, and I have a
patch for that (attached).

If you are asking my opinion, the data role must be handled as
separate capability of the port, i.e. you probable want to have
separate properties for the power role and data role, even if we did
not support that yet in the class code. Don't use "port-type" name,
just call them "power-role" and "data-role" from now on.

The default-role should tell the state machines whether Try.SNK or
Try.SRC states should be used or not. Perhaps you should have boolean
property for both: "try-snk" and "try-src" (note: both can not be true).

Final note. I think it would make sense to clearly separate the USB
Type-C specific properties from USB PD ones. Though it is unlikely
that we will see USB PD being used with other connector types besides
Type-C anymore, USB Type-C connectors will still definitely not
always support USB PD, but when USB PD is not supported, we still need
to know the data-role, power-role, default-role (or try-snk, try-src),
etc.


Br,

diff --git a/drivers/usb/typec/class.c b/drivers/usb/typec/class.c
index 2620a694704f..53df10df2f9d 100644
--- a/drivers/usb/typec/class.c
+++ b/drivers/usb/typec/class.c
@@ -282,10 +282,10 @@ typec_altmode_roles_show(struct device *dev, struct device_attribute *attr,
 	ssize_t ret;
 
 	switch (mode->roles) {
-	case TYPEC_PORT_DFP:
+	case TYPEC_PORT_SRC:
 		ret = sprintf(buf, "source\n");
 		break;
-	case TYPEC_PORT_UFP:
+	case TYPEC_PORT_SNK:
 		ret = sprintf(buf, "sink\n");
 		break;
 	case TYPEC_PORT_DRP:
@@ -797,14 +797,14 @@ static const char * const typec_data_roles[] = {
 };
 
 static const char * const typec_port_types[] = {
-	[TYPEC_PORT_DFP] = "source",
-	[TYPEC_PORT_UFP] = "sink",
+	[TYPEC_PORT_SRC] = "source",
+	[TYPEC_PORT_SNK] = "sink",
 	[TYPEC_PORT_DRP] = "dual",
 };
 
 static const char * const typec_port_types_drp[] = {
-	[TYPEC_PORT_DFP] = "dual [source] sink",
-	[TYPEC_PORT_UFP] = "dual source [sink]",
+	[TYPEC_PORT_SRC] = "dual [source] sink",
+	[TYPEC_PORT_SNK] = "dual source [sink]",
 	[TYPEC_PORT_DRP] = "[dual] source sink",
 };
 
@@ -875,9 +875,7 @@ static ssize_t data_role_store(struct device *dev,
 		return ret;
 
 	mutex_lock(&port->port_type_lock);
-	if (port->port_type != TYPEC_PORT_DRP) {
-		dev_dbg(dev, "port type fixed at \"%s\"",
-			     typec_port_types[port->port_type]);
+	if (port->cap->data != TYPEC_PORT_DRD) {
 		ret = -EOPNOTSUPP;
 		goto unlock_and_ret;
 	}
@@ -897,7 +895,7 @@ static ssize_t data_role_show(struct device *dev,
 {
 	struct typec_port *port = to_typec_port(dev);
 
-	if (port->cap->type == TYPEC_PORT_DRP)
+	if (port->cap->data == TYPEC_PORT_DRD)
 		return sprintf(buf, "%s\n", port->data_role == TYPEC_HOST ?
 			       "[host] device" : "host [device]");
 
@@ -1328,7 +1326,6 @@ struct typec_port *typec_register_port(struct device *parent,
 				       const struct typec_capability *cap)
 {
 	struct typec_port *port;
-	int role;
 	int ret;
 	int id;
 
@@ -1354,21 +1351,36 @@ struct typec_port *typec_register_port(struct device *parent,
 		goto err_mux;
 	}
 
-	if (cap->type == TYPEC_PORT_DFP)
-		role = TYPEC_SOURCE;
-	else if (cap->type == TYPEC_PORT_UFP)
-		role = TYPEC_SINK;
-	else
-		role = cap->prefer_role;
-
-	if (role == TYPEC_SOURCE) {
-		port->data_role = TYPEC_HOST;
+	switch (cap->type) {
+	case TYPEC_PORT_SRC:
 		port->pwr_role = TYPEC_SOURCE;
 		port->vconn_role = TYPEC_SOURCE;
-	} else {
-		port->data_role = TYPEC_DEVICE;
+		break;
+	case TYPEC_PORT_SNK:
 		port->pwr_role = TYPEC_SINK;
 		port->vconn_role = TYPEC_SINK;
+		break;
+	case TYPEC_PORT_DRP:
+		if (cap->prefer_role != TYPEC_NO_PREFERRED_ROLE)
+			port->pwr_role = cap->prefer_role;
+		else
+			port->pwr_role = TYPEC_SINK;
+		break;
+	}
+
+	switch (cap->data) {
+	case TYPEC_PORT_DFP:
+		port->data_role = TYPEC_HOST;
+		break;
+	case TYPEC_PORT_UFP:
+		port->data_role = TYPEC_DEVICE;
+		break;
+	case TYPEC_PORT_DRD:
+		if (cap->prefer_role == TYPEC_SOURCE)
+			port->data_role = TYPEC_HOST;
+		else
+			port->data_role = TYPEC_DEVICE;
+		break;
 	}
 
 	port->id = id;
diff --git a/drivers/usb/typec/fusb302/fusb302.c b/drivers/usb/typec/fusb302/fusb302.c
index b267b907bf24..76c9d955fa40 100644
--- a/drivers/usb/typec/fusb302/fusb302.c
+++ b/drivers/usb/typec/fusb302/fusb302.c
@@ -1230,6 +1230,7 @@ static const struct tcpc_config fusb302_tcpc_config = {
 	.max_snk_mw = 15000,
 	.operating_snk_mw = 2500,
 	.type = TYPEC_PORT_DRP,
+	.data = TYPEC_PORT_DRD,
 	.default_role = TYPEC_SINK,
 	.alt_modes = NULL,
 };
diff --git a/drivers/usb/typec/tcpm.c b/drivers/usb/typec/tcpm.c
index bfcaf6618a1f..0e1d92381522 100644
--- a/drivers/usb/typec/tcpm.c
+++ b/drivers/usb/typec/tcpm.c
@@ -350,7 +350,7 @@ static enum tcpm_state tcpm_default_state(struct tcpm_port *port)
 		else if (port->tcpc->config->default_role == TYPEC_SINK)
 			return SNK_UNATTACHED;
 		/* Fall through to return SRC_UNATTACHED */
-	} else if (port->port_type == TYPEC_PORT_UFP) {
+	} else if (port->port_type == TYPEC_PORT_SNK) {
 		return SNK_UNATTACHED;
 	}
 	return SRC_UNATTACHED;
@@ -2264,7 +2264,7 @@ static inline enum tcpm_state unattached_state(struct tcpm_port *port)
 			return SRC_UNATTACHED;
 		else
 			return SNK_UNATTACHED;
-	} else if (port->port_type == TYPEC_PORT_DFP) {
+	} else if (port->port_type == TYPEC_PORT_SRC) {
 		return SRC_UNATTACHED;
 	}
 
@@ -3554,11 +3554,11 @@ static int tcpm_port_type_set(const struct typec_capability *cap,
 
 	if (!port->connected) {
 		tcpm_set_state(port, PORT_RESET, 0);
-	} else if (type == TYPEC_PORT_UFP) {
+	} else if (type == TYPEC_PORT_SNK) {
 		if (!(port->pwr_role == TYPEC_SINK &&
 		      port->data_role == TYPEC_DEVICE))
 			tcpm_set_state(port, PORT_RESET, 0);
-	} else if (type == TYPEC_PORT_DFP) {
+	} else if (type == TYPEC_PORT_SRC) {
 		if (!(port->pwr_role == TYPEC_SOURCE &&
 		      port->data_role == TYPEC_HOST))
 			tcpm_set_state(port, PORT_RESET, 0);
@@ -3748,6 +3748,7 @@ struct tcpm_port *tcpm_register_port(struct device *dev, struct tcpc_dev *tcpc)
 
 	port->typec_caps.prefer_role = tcpc->config->default_role;
 	port->typec_caps.type = tcpc->config->type;
+	port->typec_caps.data = tcpc->config->data;
 	port->typec_caps.revision = 0x0120;	/* Type-C spec release 1.2 */
 	port->typec_caps.pd_revision = 0x0200;	/* USB-PD spec release 2.0 */
 	port->typec_caps.dr_set = tcpm_dr_set;
diff --git a/drivers/usb/typec/tps6598x.c b/drivers/usb/typec/tps6598x.c
index 37a15c14a6c6..8b8406867c02 100644
--- a/drivers/usb/typec/tps6598x.c
+++ b/drivers/usb/typec/tps6598x.c
@@ -393,31 +393,39 @@ static int tps6598x_probe(struct i2c_client *client)
 	if (ret < 0)
 		return ret;
 
+	tps->typec_cap.revision = USB_TYPEC_REV_1_2;
+	tps->typec_cap.pd_revision = 0x200;
+	tps->typec_cap.prefer_role = TYPEC_NO_PREFERRED_ROLE;
+	tps->typec_cap.pr_set = tps6598x_pr_set;
+	tps->typec_cap.dr_set = tps6598x_dr_set;
+
 	switch (TPS_SYSCONF_PORTINFO(conf)) {
 	case TPS_PORTINFO_SINK_ACCESSORY:
 	case TPS_PORTINFO_SINK:
-		tps->typec_cap.type = TYPEC_PORT_UFP;
+		tps->typec_cap.type = TYPEC_PORT_SNK;
+		tps->typec_cap.data = TYPEC_PORT_UFP;
 		break;
 	case TPS_PORTINFO_DRP_UFP_DRD:
 	case TPS_PORTINFO_DRP_DFP_DRD:
-		tps->typec_cap.dr_set = tps6598x_dr_set;
-		/* fall through */
+		tps->typec_cap.type = TYPEC_PORT_DRP;
+		tps->typec_cap.data = TYPEC_PORT_DRD;
+		break;
 	case TPS_PORTINFO_DRP_UFP:
+		tps->typec_cap.type = TYPEC_PORT_DRP;
+		tps->typec_cap.data = TYPEC_PORT_UFP;
+		break;
 	case TPS_PORTINFO_DRP_DFP:
-		tps->typec_cap.pr_set = tps6598x_pr_set;
 		tps->typec_cap.type = TYPEC_PORT_DRP;
+		tps->typec_cap.data = TYPEC_PORT_DFP;
 		break;
 	case TPS_PORTINFO_SOURCE:
-		tps->typec_cap.type = TYPEC_PORT_DFP;
+		tps->typec_cap.type = TYPEC_PORT_SRC;
+		tps->typec_cap.data = TYPEC_PORT_DFP;
 		break;
 	default:
 		return -ENODEV;
 	}
 
-	tps->typec_cap.revision = USB_TYPEC_REV_1_2;
-	tps->typec_cap.pd_revision = 0x200;
-	tps->typec_cap.prefer_role = TYPEC_NO_PREFERRED_ROLE;
-
 	tps->port = typec_register_port(&client->dev, &tps->typec_cap);
 	if (IS_ERR(tps->port))
 		return PTR_ERR(tps->port);
diff --git a/drivers/usb/typec/typec_wcove.c b/drivers/usb/typec/typec_wcove.c
index 2e990e0d917d..19cca7f1b2c5 100644
--- a/drivers/usb/typec/typec_wcove.c
+++ b/drivers/usb/typec/typec_wcove.c
@@ -572,6 +572,7 @@ static struct tcpc_config wcove_typec_config = {
 	.operating_snk_mw = 15000,
 
 	.type = TYPEC_PORT_DRP,
+	.data = TYPEC_PORT_DRD,
 	.default_role = TYPEC_SINK,
 };
 
diff --git a/drivers/usb/typec/ucsi/ucsi.c b/drivers/usb/typec/ucsi/ucsi.c
index 69d544cfcd45..bf0977fbd100 100644
--- a/drivers/usb/typec/ucsi/ucsi.c
+++ b/drivers/usb/typec/ucsi/ucsi.c
@@ -592,11 +592,18 @@ static int ucsi_register_port(struct ucsi *ucsi, int index)
 		return ret;
 
 	if (con->cap.op_mode & UCSI_CONCAP_OPMODE_DRP)
-		cap->type = TYPEC_PORT_DRP;
+		cap->data = TYPEC_PORT_DRD;
 	else if (con->cap.op_mode & UCSI_CONCAP_OPMODE_DFP)
-		cap->type = TYPEC_PORT_DFP;
+		cap->data = TYPEC_PORT_DFP;
 	else if (con->cap.op_mode & UCSI_CONCAP_OPMODE_UFP)
-		cap->type = TYPEC_PORT_UFP;
+		cap->data = TYPEC_PORT_UFP;
+
+	if (con->cap.provider && con->cap.consumer)
+		cap->type = TYPEC_PORT_DRP;
+	else if (con->cap.provider)
+		cap->type = TYPEC_PORT_SRC;
+	else if (con->cap.consumer)
+		cap->type = TYPEC_PORT_SNK;
 
 	cap->revision = ucsi->cap.typec_version;
 	cap->pd_revision = ucsi->cap.pd_version;
diff --git a/include/linux/usb/tcpm.h b/include/linux/usb/tcpm.h
index fe3508e6e1df..f0d839daeaea 100644
--- a/include/linux/usb/tcpm.h
+++ b/include/linux/usb/tcpm.h
@@ -91,6 +91,7 @@ struct tcpc_config {
 	unsigned int operating_snk_mw;
 
 	enum typec_port_type type;
+	enum typec_port_data data;
 	enum typec_role default_role;
 	bool try_role_hw;	/* try.{src,snk} implemented in hardware */
 
diff --git a/include/linux/usb/typec.h b/include/linux/usb/typec.h
index 2408e5c2ed91..672b39bb0adc 100644
--- a/include/linux/usb/typec.h
+++ b/include/linux/usb/typec.h
@@ -22,9 +22,15 @@ struct typec_port;
 struct fwnode_handle;
 
 enum typec_port_type {
+	TYPEC_PORT_SRC,
+	TYPEC_PORT_SNK,
+	TYPEC_PORT_DRP,
+};
+
+enum typec_port_data {
 	TYPEC_PORT_DFP,
 	TYPEC_PORT_UFP,
-	TYPEC_PORT_DRP,
+	TYPEC_PORT_DRD,
 };
 
 enum typec_plug_type {
@@ -186,10 +192,11 @@ struct typec_partner_desc {
 
 /*
  * struct typec_capability - USB Type-C Port Capabilities
- * @role: DFP (Host-only), UFP (Device-only) or DRP (Dual Role)
+ * @type: Supported power role of the port
+ * @data: Supported data role of the port
  * @revision: USB Type-C Specification release. Binary coded decimal
  * @pd_revision: USB Power Delivery Specification revision if supported
- * @prefer_role: Initial role preference
+ * @prefer_role: Initial role preference (DRP ports).
  * @accessory: Supported Accessory Modes
  * @sw: Cable plug orientation switch
  * @mux: Multiplexer switch for Alternate/Accessory Modes
@@ -205,6 +212,7 @@ struct typec_partner_desc {
  */
 struct typec_capability {
 	enum typec_port_type	type;
+	enum typec_port_data	data;
 	u16			revision; /* 0120H = "1.2" */
 	u16			pd_revision; /* 0300H = "3.0" */
 	int			prefer_role;

RE: [PATCH v2 10/12] dt-bindings: connector: add properties for typec power delivery

[Jun Li]

Hi
> -----Original Message-----
> From: Heikki Krogerus [mailto:heikki.krogerus@linux.intel.com]
> Sent: 2018年3月6日 20:02
> To: Jun Li <jun.li@nxp.com>
> Cc: Andrzej Hajda <a.hajda@samsung.com>; gregkh@linuxfoundation.org;
> robh+dt@kernel.org; linux@roeck-us.net; mark.rutland@arm.com;
> yueyao@google.com; Peter Chen <peter.chen@nxp.com>;
> garsilva@embeddedor.com; o_leveque@orange.fr;
> shufan_lee@richtek.com; linux-usb@vger.kernel.org;
> devicetree@vger.kernel.org; dl-linux-imx <linux-imx@nxp.com>
> Subject: Re: [PATCH v2 10/12] dt-bindings: connector: add properties for
> typec power delivery
> 
> Hi guys,
> 
> On Tue, Mar 06, 2018 at 09:38:59AM +0000, Jun Li wrote:
> > > >>> diff --git
> > > >>> a/Documentation/devicetree/bindings/connector/usb-connector.txt
> > > >>> b/Documentation/devicetree/bindings/connector/usb-connector.txt
> > > >>> index e1463f1..242f6df 100644
> > > >>> ---
> > > >>> a/Documentation/devicetree/bindings/connector/usb-connector.txt
> > > >>> +++
> > > b/Documentation/devicetree/bindings/connector/usb-connector.txt
> > > >>> @@ -15,6 +15,30 @@ Optional properties:
> > > >>>  - type: size of the connector, should be specified in case of
> > > >>> USB-A,
> > > USB-B
> > > >>>    non-fullsize connectors: "mini", "micro".
> > > >>>
> > > >>> +Required properties for usb-c-connector with power delivery
> support:
> > > >>> +- port-type: should be one of "source", "sink" or "dual".
> > > >>> +- default-role: preferred power role if port-type is
> > > >>> +"dual"(drp), should be
> > > >>> +  "sink" or "source".
> > > >> Since port carries data and power, it would be better to
> > > >> explicitly mention it in names of properties which can be ambiguous.
> > > >> Maybe instead of 'port-type' you can use 'power-role', for example.
> > > > Port-type is align with the name of typec coding and ABI, 'power-role'
> > > > is more like for the current role rather than the port's ability.
> > >
> > > I am not sure what are you exactly mean by "coding and ABI", but I
> > > guess it is just about Power-Delivery part of USB-C. And if you want
> > > to put this property into USB node without mark it is related to PD
> > > part of USB connector, you risk confusion with possible USB data related
> properties.
> >
> > Understood your concern, I am following typec naming conventions, for
> > typec, port-type property has the same meaning as
> > /sys/class/typec/portx/port_type which is not only for power, also for
> > data, there are dedicated sys files power_role for power and data_role
> > for data.
> >
> > > Simple question, what if somebody wants to add property describing
> > > USB data capabilities (DFP, UFP, DRD), how should it be named?
> > >
> >
> > Then we may use data-role?
> >
> > > >
> > > >> Other thing is that default-role is required only in case of DRP,
> > > >> so maybe better would be to squash it in power-role, for example:
> > > >> ?????? power-role: should be on of "source", "sink",
> > > >> "dual-source", "dual-sink", in case of dual roles suffix determines
> preferred role.
> > > > I don't know how much this squash can benefit, "dual-source/sink"
> > > > is not directly showing its meaning by name.
> > >
> > > Some benefit is simpler binding, no conditionally-required property.
> > >
> >
> > There is already string definition for port type and preferred role
> > parse static const char * const typec_port_types[] = {
> >          [TYPEC_PORT_DFP] = "source",
> >          [TYPEC_PORT_UFP] = "sink",
> >          [TYPEC_PORT_DRP] = "dual",
> > };
> > And I think there will be other conditionally-required properties to
> > be extended later, are we going to name all of them by this way?
> > Either way is OK for me, I am not sure if there is principle like we
> > should avoid conditionally-required property, if we should, maybe
> > "dual-preferred-source/sink" is better.
> >
> > Hi Heikki,
> > Do you have any comments/preference here?
> 
> In the first versions of USB Type-C specification the data and power roles
> were in practice coupled together. There were no data role specific modes,
> just DFP, UFP and DRP. However, v1.2 of the spec.
> introduced separate modes for the data roles as well, and I have a patch for
> that (attached).
> 
> If you are asking my opinion, the data role must be handled as separate
> capability of the port, i.e. you probable want to have separate properties for
> the power role and data role, even if we did not support that yet in the class
> code. Don't use "port-type" name, just call them "power-role" and
> "data-role" from now on.
> 

OK, I will introduce power-role and data-role, meanwhile, I think the class code
should be changed accordingly(looks like your attached patch is doing that).

> The default-role should tell the state machines whether Try.SNK or Try.SRC
> states should be used or not. Perhaps you should have boolean property for
> both: "try-snk" and "try-src" (note: both can not be true).
> 

try-sink and try-source, both are optional, can't be true at the same time.

> Final note. I think it would make sense to clearly separate the USB Type-C
> specific properties from USB PD ones. Though it is unlikely that we will see
> USB PD being used with other connector types besides Type-C anymore, USB
> Type-C connectors will still definitely not always support USB PD, but when
> USB PD is not supported, we still need to know the data-role, power-role,
> default-role (or try-snk, try-src), etc.
> 

Agree, I think we can judge if the typec connector support PD by checking
if there are PD required properties(like PDO).

Thanks
Jun Li
> 
> Br,
> 
> --
> heikki

[v2,10/12] dt-bindings: connector: add properties for typec power delivery

[Jun Li]

Hi
> -----Original Message-----
> From: Heikki Krogerus [mailto:heikki.krogerus@linux.intel.com]
> Sent: 2018年3月6日 20:02
> To: Jun Li <jun.li@nxp.com>
> Cc: Andrzej Hajda <a.hajda@samsung.com>; gregkh@linuxfoundation.org;
> robh+dt@kernel.org; linux@roeck-us.net; mark.rutland@arm.com;
> yueyao@google.com; Peter Chen <peter.chen@nxp.com>;
> garsilva@embeddedor.com; o_leveque@orange.fr;
> shufan_lee@richtek.com; linux-usb@vger.kernel.org;
> devicetree@vger.kernel.org; dl-linux-imx <linux-imx@nxp.com>
> Subject: Re: [PATCH v2 10/12] dt-bindings: connector: add properties for
> typec power delivery
> 
> Hi guys,
> 
> On Tue, Mar 06, 2018 at 09:38:59AM +0000, Jun Li wrote:
> > > >>> diff --git
> > > >>> a/Documentation/devicetree/bindings/connector/usb-connector.txt
> > > >>> b/Documentation/devicetree/bindings/connector/usb-connector.txt
> > > >>> index e1463f1..242f6df 100644
> > > >>> ---
> > > >>> a/Documentation/devicetree/bindings/connector/usb-connector.txt
> > > >>> +++
> > > b/Documentation/devicetree/bindings/connector/usb-connector.txt
> > > >>> @@ -15,6 +15,30 @@ Optional properties:
> > > >>>  - type: size of the connector, should be specified in case of
> > > >>> USB-A,
> > > USB-B
> > > >>>    non-fullsize connectors: "mini", "micro".
> > > >>>
> > > >>> +Required properties for usb-c-connector with power delivery
> support:
> > > >>> +- port-type: should be one of "source", "sink" or "dual".
> > > >>> +- default-role: preferred power role if port-type is
> > > >>> +"dual"(drp), should be
> > > >>> +  "sink" or "source".
> > > >> Since port carries data and power, it would be better to
> > > >> explicitly mention it in names of properties which can be ambiguous.
> > > >> Maybe instead of 'port-type' you can use 'power-role', for example.
> > > > Port-type is align with the name of typec coding and ABI, 'power-role'
> > > > is more like for the current role rather than the port's ability.
> > >
> > > I am not sure what are you exactly mean by "coding and ABI", but I
> > > guess it is just about Power-Delivery part of USB-C. And if you want
> > > to put this property into USB node without mark it is related to PD
> > > part of USB connector, you risk confusion with possible USB data related
> properties.
> >
> > Understood your concern, I am following typec naming conventions, for
> > typec, port-type property has the same meaning as
> > /sys/class/typec/portx/port_type which is not only for power, also for
> > data, there are dedicated sys files power_role for power and data_role
> > for data.
> >
> > > Simple question, what if somebody wants to add property describing
> > > USB data capabilities (DFP, UFP, DRD), how should it be named?
> > >
> >
> > Then we may use data-role?
> >
> > > >
> > > >> Other thing is that default-role is required only in case of DRP,
> > > >> so maybe better would be to squash it in power-role, for example:
> > > >> ?????? power-role: should be on of "source", "sink",
> > > >> "dual-source", "dual-sink", in case of dual roles suffix determines
> preferred role.
> > > > I don't know how much this squash can benefit, "dual-source/sink"
> > > > is not directly showing its meaning by name.
> > >
> > > Some benefit is simpler binding, no conditionally-required property.
> > >
> >
> > There is already string definition for port type and preferred role
> > parse static const char * const typec_port_types[] = {
> >          [TYPEC_PORT_DFP] = "source",
> >          [TYPEC_PORT_UFP] = "sink",
> >          [TYPEC_PORT_DRP] = "dual",
> > };
> > And I think there will be other conditionally-required properties to
> > be extended later, are we going to name all of them by this way?
> > Either way is OK for me, I am not sure if there is principle like we
> > should avoid conditionally-required property, if we should, maybe
> > "dual-preferred-source/sink" is better.
> >
> > Hi Heikki,
> > Do you have any comments/preference here?
> 
> In the first versions of USB Type-C specification the data and power roles
> were in practice coupled together. There were no data role specific modes,
> just DFP, UFP and DRP. However, v1.2 of the spec.
> introduced separate modes for the data roles as well, and I have a patch for
> that (attached).
> 
> If you are asking my opinion, the data role must be handled as separate
> capability of the port, i.e. you probable want to have separate properties for
> the power role and data role, even if we did not support that yet in the class
> code. Don't use "port-type" name, just call them "power-role" and
> "data-role" from now on.
> 

OK, I will introduce power-role and data-role, meanwhile, I think the class code
should be changed accordingly(looks like your attached patch is doing that).

> The default-role should tell the state machines whether Try.SNK or Try.SRC
> states should be used or not. Perhaps you should have boolean property for
> both: "try-snk" and "try-src" (note: both can not be true).
> 

try-sink and try-source, both are optional, can't be true at the same time.

> Final note. I think it would make sense to clearly separate the USB Type-C
> specific properties from USB PD ones. Though it is unlikely that we will see
> USB PD being used with other connector types besides Type-C anymore, USB
> Type-C connectors will still definitely not always support USB PD, but when
> USB PD is not supported, we still need to know the data-role, power-role,
> default-role (or try-snk, try-src), etc.
> 

Agree, I think we can judge if the typec connector support PD by checking
if there are PD required properties(like PDO).

Thanks
Jun Li
> 
> Br,
> 
> --
> heikki

Re: [PATCH v2 10/12] dt-bindings: connector: add properties for typec power delivery

[Heikki Krogerus]

On Thu, Mar 08, 2018 at 01:41:23AM +0000, Jun Li wrote:
> > If you are asking my opinion, the data role must be handled as separate
> > capability of the port, i.e. you probable want to have separate properties for
> > the power role and data role, even if we did not support that yet in the class
> > code. Don't use "port-type" name, just call them "power-role" and
> > "data-role" from now on.
> > 
> 
> OK, I will introduce power-role and data-role, meanwhile, I think the class code
> should be changed accordingly(looks like your attached patch is doing that).

True. I'll send the patch out now.


Thanks,

-- 
heikki

[v2,10/12] dt-bindings: connector: add properties for typec power delivery

[Heikki Krogerus]

On Thu, Mar 08, 2018 at 01:41:23AM +0000, Jun Li wrote:
> > If you are asking my opinion, the data role must be handled as separate
> > capability of the port, i.e. you probable want to have separate properties for
> > the power role and data role, even if we did not support that yet in the class
> > code. Don't use "port-type" name, just call them "power-role" and
> > "data-role" from now on.
> > 
> 
> OK, I will introduce power-role and data-role, meanwhile, I think the class code
> should be changed accordingly(looks like your attached patch is doing that).

True. I'll send the patch out now.


Thanks,