[no subject]

[Mavis Wancyzk]

Hallo Am Mrs Mavis Wancyzk, Sie haben eine Spende von 4,800,000.00EUR Ich 
gewann die America Lottery im Wert von $ 758.7 Millionen und ich spende einen 
Teil davon an fünf glückliche Menschen und Wohltätigkeits-Häuser in Erinnerung 
an meinen verstorbenen Ehemann, der an Krebs gestorben ist. Kontaktieren Sie 
mich für weitere Details unter:
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: patch 8466489ef5ba48272ba4fa4ea9f8f403306de4c7 breaks Renesas USB3 controller functionality

[Faiz Abbas]

Hi Everyone,

On Wednesday 11 April 2018 07:32 PM, Marc Zyngier wrote:
> On Wed, 11 Apr 2018 14:11:52 +0100,
> Bockholdt Arne wrote:
>>
>> Hi all,
>>
>> is there anything new, I've just tried the new stable 4.16.1 kernel
>> without any change. The Renesys USB3 controller is still not
>> functional. I'm willing to test any patch that is based on a stable
>> kernel version because the machine is in production use.
> 
> Have you tested the branch[1] I mentioned in my previous email?
> Without your feedback, I cannot really make much progress on this.
> 
> Thanks,
> 
>   M.
>   
> [1] https://www.spinics.net/lists/linux-usb/msg167301.html
> 

I was also having problems with a Renesas card (01:00.0 USB controller
[0c03]: Renesas Technology Corp. uPD720201 USB 3.0 Host Controller
[1912:0014]) on a dra72x-evm. The kernel would just hang because of the
xhci reset.

Log:https://pastebin.ubuntu.com/p/dYYV9DZMwx/

The patches on Marc's branch have fixed this for me as well. Thanks for
the fix.


Regards,
Faiz

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 1/2] dt-bindings: add MediaTek XS-PHY binding

[Chunfeng Yun]

On Wed, 2018-05-02 at 07:41 -0500, Rob Herring wrote:
> On Wed, May 2, 2018 at 2:04 AM, Chunfeng Yun  
> wrote:
> > Hi Rob,
> > On Tue, 2018-05-01 at 09:24 -0500, Rob Herring wrote:
> >> On Wed, Apr 25, 2018 at 03:45:28PM +0800, Chunfeng Yun wrote:
> >> > Add a DT binding documentation of XS-PHY for MediaTek SoCs
> >> > with USB3.1 GEN2 controller
> 
> [...]
> 
> >> > +   reg = <0 0x11c43000 0 0x0200>;
> >> > +   mediatek,src-ref-clk-mhz = <26>;
> >> > +   mediatek,src-coef = <17>;
> >> > +   #address-cells = <2>;
> >> > +   #size-cells = <2>;
> >>
> >> Really need 64-bit sizes?
> > Just an example, 32-bit is also ok, but it's better to use the same
> > value as the root node
> 
> Why is it better?
> 
> It is unnecessary bloat and it is better to limit the range of child
> nodes using ranges.
I agree with you.
And here the parent and child address space is identical, and no address
translate is required, so use the same value as the root node, if the
root node uses 64-bit sizes, we will use 64-bit sizes as well,  if it
uses 32-bit sizes, we use 32-bit sizes too, in order to keep consistent.
> 
> Rob


--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v5 13/14] 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.

Reviewed-by: Guenter Roeck 
Signed-off-by: Li Jun 
---
 drivers/staging/typec/tcpci.c | 9 +++--
 1 file changed, 3 insertions(+), 6 deletions(-)

diff --git a/drivers/staging/typec/tcpci.c b/drivers/staging/typec/tcpci.c
index 5c0c5e3..2818a4d 100644
--- a/drivers/staging/typec/tcpci.c
+++ b/drivers/staging/typec/tcpci.c
@@ -218,12 +218,9 @@ static int tcpci_set_vconn(struct tcpc_dev *tcpc, bool 
enable)
return 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

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v5 14/14] 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 
---
 drivers/staging/Kconfig| 2 --
 drivers/staging/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
 7 files changed, 8 insertions(+), 8 deletions(-)

diff --git a/drivers/staging/Kconfig b/drivers/staging/Kconfig
index d5926f0..d83ff66 100644
--- a/drivers/staging/Kconfig
+++ b/drivers/staging/Kconfig
@@ -112,8 +112,6 @@ source "drivers/staging/greybus/Kconfig"
 
 source "drivers/staging/vc04_services/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 919753c..a71ec1f 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_IPX)  += ipx/
 obj-$(CONFIG_NCP_FS)   += ncpfs/
 obj-$(CONFIG_PRISM2_USB)   += wlan-ng/
diff --git a/drivers/staging/typec/TODO b/drivers/staging/typec/TODO
deleted file mode 100644
index 53fe2f7..000
--- a/drivers/staging/typec/TODO
+++ /dev/null
@@ -1,5 +0,0 @@
-tcpci:
-- Test with real hardware
-
-Please send patches to Guenter Roeck  and copy
-Heikki Krogerus .
diff --git a/drivers/usb/typec/Kconfig b/drivers/usb/typec/Kconfig
index 2c8eab1..0a862fc 100644
--- a/drivers/usb/typec/Kconfig
+++ b/drivers/usb/typec/Kconfig
@@ -56,6 +56,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 1f599a6..02758a1 100644
--- a/drivers/usb/typec/Makefile
+++ b/drivers/usb/typec/Makefile
@@ -7,3 +7,4 @@ obj-$(CONFIG_TYPEC_WCOVE)   += typec_wcove.o
 obj-$(CONFIG_TYPEC_UCSI)   += ucsi/
 obj-$(CONFIG_TYPEC_TPS6598X)   += tps6598x.o
 obj-$(CONFIG_TYPEC)+= mux/
+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

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v5 12/14] staging: typec: tcpci: keep the not connecting cc line open

[Li Jun]

While set polarity, we should keep the not connecting cc line to be
open.

Signed-off-by: Li Jun 
---
 drivers/staging/typec/tcpci.c | 18 ++
 1 file changed, 14 insertions(+), 4 deletions(-)

diff --git a/drivers/staging/typec/tcpci.c b/drivers/staging/typec/tcpci.c
index 5c48810..5c0c5e3 100644
--- a/drivers/staging/typec/tcpci.c
+++ b/drivers/staging/typec/tcpci.c
@@ -185,15 +185,25 @@ 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,
-  (polarity == TYPEC_POLARITY_CC2) ?
-  TCPC_TCPC_CTRL_ORIENTATION : 0);
+   /* Keep the disconnect cc line open */
+   ret = regmap_read(tcpci->regmap, TCPC_ROLE_CTRL, );
if (ret < 0)
return ret;
 
-   return 0;
+   if (polarity == TYPEC_POLARITY_CC2)
+   reg |= TCPC_ROLE_CTRL_CC_OPEN << TCPC_ROLE_CTRL_CC1_SHIFT;
+   else
+   reg |= TCPC_ROLE_CTRL_CC_OPEN << 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_TCPC_CTRL,
+  (polarity == TYPEC_POLARITY_CC2) ?
+  TCPC_TCPC_CTRL_ORIENTATION : 0);
 }
 
 static int tcpci_set_vconn(struct tcpc_dev *tcpc, bool enable)
-- 
2.7.4

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v5 11/14] usb: typec: tcpm: set cc for drp toggling attach

[Li Jun]

In case of drp toggling, we may need set correct cc value for role control
after attach as it may never been set.

Signed-off-by: Li Jun 
---
 drivers/usb/typec/tcpm.c | 5 +
 1 file changed, 5 insertions(+)

diff --git a/drivers/usb/typec/tcpm.c b/drivers/usb/typec/tcpm.c
index 0c7fa14..7e7eaca 100644
--- a/drivers/usb/typec/tcpm.c
+++ b/drivers/usb/typec/tcpm.c
@@ -2599,6 +2599,7 @@ static void tcpm_reset_port(struct tcpm_port *port)
tcpm_set_attached_state(port, false);
port->try_src_count = 0;
port->try_snk_count = 0;
+   port->cc_req = TYPEC_CC_OPEN;
port->supply_voltage = 0;
port->current_limit = 0;
port->usb_type = POWER_SUPPLY_USB_TYPE_C;
@@ -2831,6 +2832,8 @@ static void run_state_machine(struct tcpm_port *port)
break;
 
case SRC_ATTACHED:
+   if (port->cc_req == TYPEC_CC_OPEN)
+   tcpm_set_cc(port, tcpm_rp_cc(port));
ret = tcpm_src_attach(port);
tcpm_set_state(port, SRC_UNATTACHED,
   ret < 0 ? 0 : PD_T_PS_SOURCE_ON);
@@ -3004,6 +3007,8 @@ static void run_state_machine(struct tcpm_port *port)
tcpm_set_state(port, SNK_UNATTACHED, PD_T_PD_DEBOUNCE);
break;
case SNK_ATTACHED:
+   if (port->cc_req == TYPEC_CC_OPEN)
+   tcpm_set_cc(port, TYPEC_CC_RD);
ret = tcpm_snk_attach(port);
if (ret < 0)
tcpm_set_state(port, SNK_UNATTACHED, 0);
-- 
2.7.4

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v5 09/14] staging: typec: tcpci: enable vbus detection

[Li Jun]

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

Reviewed-by: Guenter Roeck 
Signed-off-by: Li Jun 
---
 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 139c2ab..5c48810 100644
--- a/drivers/staging/typec/tcpci.c
+++ b/drivers/staging/typec/tcpci.c
@@ -373,6 +373,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

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v5 10/14] 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.

Reviewed-by: Guenter Roeck 
Signed-off-by: Li Jun 
---
 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 becedcf..0c7fa14 100644
--- a/drivers/usb/typec/tcpm.c
+++ b/drivers/usb/typec/tcpm.c
@@ -2436,15 +2436,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;
}
@@ -2752,7 +2752,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;
}
@@ -2927,7 +2927,7 @@ static void run_state_machine(struct tcpm_port *port)
tcpm_swap_complete(port, -ENOTCONN);
tcpm_pps_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

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v5 08/14] staging: typec: tcpci: register port before request irq

[Li Jun]

From: Peter Chen 

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 
Signed-off-by: Li Jun 
---
 drivers/staging/typec/tcpci.c | 15 +--
 1 file changed, 9 insertions(+), 6 deletions(-)

diff --git a/drivers/staging/typec/tcpci.c b/drivers/staging/typec/tcpci.c
index a21aaf5..139c2ab 100644
--- a/drivers/staging/typec/tcpci.c
+++ b/drivers/staging/typec/tcpci.c
@@ -537,24 +537,27 @@ static int tcpci_probe(struct i2c_client *client,
if (IS_ERR(chip->data.regmap))
return PTR_ERR(chip->data.regmap);
 
+   i2c_set_clientdata(client, chip);
+
/* Disable chip interrupts before requesting irq */
err = regmap_raw_write(chip->data.regmap, TCPC_ALERT_MASK, ,
   sizeof(u16));
if (err < 0)
return err;
 
+   chip->tcpci = tcpci_register_port(>dev, >data);
+   if (PTR_ERR_OR_ZERO(chip->tcpci))
+   return PTR_ERR(chip->tcpci);
+
err = devm_request_threaded_irq(>dev, client->irq, NULL,
_tcpci_irq,
IRQF_ONESHOT | IRQF_TRIGGER_LOW,
dev_name(>dev), chip);
-   if (err < 0)
+   if (err < 0) {
+   tcpci_unregister_port(chip->tcpci);
return err;
+   }
 
-   chip->tcpci = tcpci_register_port(>dev, >data);
-   if (PTR_ERR_OR_ZERO(chip->tcpci))
-   return PTR_ERR(chip->tcpci);
-
-   i2c_set_clientdata(client, chip);
return 0;
 }
 
-- 
2.7.4

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v5 04/14] usb: typec: add fwnode to tcpc

[Li Jun]

Add fwnode handle to get the fwnode so we can get typec configs
it contains.

Suggested-by: Heikki Krogerus 
Signed-off-by: Li Jun 
---
 drivers/staging/typec/tcpci.c | 7 +++
 drivers/usb/typec/tcpm.c  | 1 +
 include/linux/usb/tcpm.h  | 2 ++
 3 files changed, 10 insertions(+)

diff --git a/drivers/staging/typec/tcpci.c b/drivers/staging/typec/tcpci.c
index 741a80a..01d14fb 100644
--- a/drivers/staging/typec/tcpci.c
+++ b/drivers/staging/typec/tcpci.c
@@ -10,6 +10,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -474,6 +475,12 @@ static int tcpci_parse_config(struct tcpci *tcpci)
 
/* TODO: Populate struct tcpc_config from ACPI/device-tree */
tcpci->tcpc.config = _tcpc_config;
+   tcpci->tcpc.fwnode = device_get_named_child_node(tcpci->dev,
+"connector");
+   if (!tcpci->tcpc.fwnode) {
+   dev_err(tcpci->dev, "Can't find connector node.\n");
+   return -EINVAL;
+   }
 
return 0;
 }
diff --git a/drivers/usb/typec/tcpm.c b/drivers/usb/typec/tcpm.c
index 7ee417a..80b2303 100644
--- a/drivers/usb/typec/tcpm.c
+++ b/drivers/usb/typec/tcpm.c
@@ -4579,6 +4579,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.data = tcpc->config->data;
diff --git a/include/linux/usb/tcpm.h b/include/linux/usb/tcpm.h
index b231b93..193920a 100644
--- a/include/linux/usb/tcpm.h
+++ b/include/linux/usb/tcpm.h
@@ -110,6 +110,7 @@ enum tcpc_mux_mode {
 /**
  * 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
@@ -138,6 +139,7 @@ enum tcpc_mux_mode {
  */
 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);
-- 
2.7.4

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v5 07/14] staging: typec: tcpci: remove unused tcpci_tcpc_config

[Li Jun]

Since we will use config settings via device properties, so
remove the hard code tcpci_tcpc_config.

Signed-off-by: Li Jun 
---
 drivers/staging/typec/tcpci.c | 7 ---
 1 file changed, 7 deletions(-)

diff --git a/drivers/staging/typec/tcpci.c b/drivers/staging/typec/tcpci.c
index 01d14fb..a21aaf5 100644
--- a/drivers/staging/typec/tcpci.c
+++ b/drivers/staging/typec/tcpci.c
@@ -464,17 +464,10 @@ 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,
-};
-
 static int tcpci_parse_config(struct tcpci *tcpci)
 {
tcpci->controls_vbus = true; /* XXX */
 
-   /* TODO: Populate struct tcpc_config from ACPI/device-tree */
-   tcpci->tcpc.config = _tcpc_config;
tcpci->tcpc.fwnode = device_get_named_child_node(tcpci->dev,
 "connector");
if (!tcpci->tcpc.fwnode) {
-- 
2.7.4

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v5 03/14] staging: typec: tcpci: add compatible string for nxp ptn5110

[Li Jun]

Add nxp ptn5110 typec controller compatible string: usb-tcpci,ptn5110,
which is a standard tcpci chip with power delivery support.

Signed-off-by: Li Jun 
---
 drivers/staging/typec/tcpci.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/staging/typec/tcpci.c b/drivers/staging/typec/tcpci.c
index 076d97e..741a80a 100644
--- a/drivers/staging/typec/tcpci.c
+++ b/drivers/staging/typec/tcpci.c
@@ -576,6 +576,7 @@ MODULE_DEVICE_TABLE(i2c, tcpci_id);
 #ifdef CONFIG_OF
 static const struct of_device_id tcpci_of_match[] = {
{ .compatible = "usb,tcpci", },
+   { .compatible = "nxp,ptn5110", },
{},
 };
 MODULE_DEVICE_TABLE(of, tcpci_of_match);
-- 
2.7.4

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v5 06/14] usb: typec: tcpm: support get typec and pd config from device properties

[Li Jun]

This patch adds support of get typec and power delivery config from
firmware description.

Signed-off-by: Li Jun 
---
 drivers/usb/typec/tcpm.c | 133 +++
 1 file changed, 111 insertions(+), 22 deletions(-)

diff --git a/drivers/usb/typec/tcpm.c b/drivers/usb/typec/tcpm.c
index 80b2303..becedcf 100644
--- a/drivers/usb/typec/tcpm.c
+++ b/drivers/usb/typec/tcpm.c
@@ -14,6 +14,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -4240,6 +4241,81 @@ static int tcpm_copy_vdos(u32 *dest_vdo, const u32 
*src_vdo,
return nr_vdo;
 }
 
+static int tcpm_fw_get_caps(struct tcpm_port *port,
+   struct fwnode_handle *fwnode)
+{
+   const char *cap_str;
+   int ret;
+   u32 mw;
+
+   if (!port || !fwnode)
+   return -EINVAL;
+
+   /* USB data support is optional */
+   ret = fwnode_property_read_string(fwnode, "data-role", _str);
+   if (ret == 0) {
+   port->typec_caps.data = typec_find_data_type(cap_str);
+   if (port->typec_caps.data < 0)
+   return -EINVAL;
+   }
+
+   ret = fwnode_property_read_string(fwnode, "power-role", _str);
+   if (ret < 0)
+   return ret;
+
+   port->typec_caps.type = typec_find_power_type(cap_str);
+   if (port->typec_caps.type < 0)
+   return -EINVAL;
+   port->port_type = port->typec_caps.type;
+
+   if (port->port_type == TYPEC_PORT_SNK)
+   goto sink;
+
+   /* Get soruce pdos */
+   ret = fwnode_property_read_u32_array(fwnode, "source-pdos",
+NULL, 0);
+   if (ret <= 0)
+   return -EINVAL;
+
+   port->nr_src_pdo = min(ret, PDO_MAX_OBJECTS);
+   ret = fwnode_property_read_u32_array(fwnode, "source-pdos",
+port->src_pdo, port->nr_src_pdo);
+   if ((ret < 0) || tcpm_validate_caps(port, port->src_pdo,
+   port->nr_src_pdo))
+   return -EINVAL;
+
+   if (port->port_type == TYPEC_PORT_SRC)
+   return 0;
+
+   /* Get the preferred power role for DRP */
+   ret = fwnode_property_read_string(fwnode, "try-power-role", _str);
+   if (ret < 0)
+   return ret;
+
+   port->typec_caps.prefer_role = typec_find_preferred_role(cap_str);
+   if (port->typec_caps.prefer_role < 0)
+   return -EINVAL;
+sink:
+   /* Get sink pdos */
+   ret = fwnode_property_read_u32_array(fwnode, "sink-pdos",
+NULL, 0);
+   if (ret <= 0)
+   return -EINVAL;
+
+   port->nr_snk_pdo = min(ret, PDO_MAX_OBJECTS);
+   ret = fwnode_property_read_u32_array(fwnode, "sink-pdos",
+port->snk_pdo, port->nr_snk_pdo);
+   if ((ret < 0) || tcpm_validate_caps(port, port->snk_pdo,
+   port->nr_snk_pdo))
+   return -EINVAL;
+
+   if (fwnode_property_read_u32(fwnode, "op-sink-microwatt", ) < 0)
+   return -EINVAL;
+   port->operating_snk_mw = mw / 1000;
+
+   return 0;
+}
+
 int tcpm_update_source_capabilities(struct tcpm_port *port, const u32 *pdo,
unsigned int nr_pdo)
 {
@@ -4524,12 +4600,36 @@ static int devm_tcpm_psy_register(struct tcpm_port 
*port)
return PTR_ERR_OR_ZERO(port->psy);
 }
 
+static int tcpm_copy_caps(struct tcpm_port *port,
+ const struct tcpc_config *tcfg)
+{
+   if (tcpm_validate_caps(port, tcfg->src_pdo, tcfg->nr_src_pdo) ||
+   tcpm_validate_caps(port, tcfg->snk_pdo, tcfg->nr_snk_pdo))
+   return -EINVAL;
+
+   port->nr_src_pdo = tcpm_copy_pdos(port->src_pdo, tcfg->src_pdo,
+ tcfg->nr_src_pdo);
+   port->nr_snk_pdo = tcpm_copy_pdos(port->snk_pdo, tcfg->snk_pdo,
+ tcfg->nr_snk_pdo);
+
+   port->nr_snk_vdo = tcpm_copy_vdos(port->snk_vdo, tcfg->snk_vdo,
+ tcfg->nr_snk_vdo);
+
+   port->operating_snk_mw = tcfg->operating_snk_mw;
+
+   port->typec_caps.prefer_role = tcfg->default_role;
+   port->typec_caps.type = tcfg->type;
+   port->typec_caps.data = tcfg->data;
+
+   return 0;
+}
+
 struct tcpm_port *tcpm_register_port(struct device *dev, struct tcpc_dev *tcpc)
 {
struct tcpm_port *port;
int i, err;
 
-   if (!dev || !tcpc || !tcpc->config ||
+   if (!dev || !tcpc ||
!tcpc->get_vbus || !tcpc->set_cc || !tcpc->get_cc ||
!tcpc->set_polarity || !tcpc->set_vconn || !tcpc->set_vbus ||
!tcpc->set_pd_rx || !tcpc->set_roles || !tcpc->pd_transmit)
@@ -4559,30 +4659,19 @@ struct tcpm_port *tcpm_register_port(struct device 
*dev, struct 

[PATCH v5 05/14] usb: typec: add API to get typec basic port power and data config

[Li Jun]

This patch adds 3 APIs to get the typec port power and data type,
and preferred power role by its name string.

Signed-off-by: Li Jun 
---
 drivers/usb/typec/class.c | 52 +++
 include/linux/usb/typec.h |  3 +++
 2 files changed, 55 insertions(+)

diff --git a/drivers/usb/typec/class.c b/drivers/usb/typec/class.c
index 53df10d..5981e18 100644
--- a/drivers/usb/typec/class.c
+++ b/drivers/usb/typec/class.c
@@ -9,6 +9,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -802,6 +803,12 @@ static const char * const typec_port_types[] = {
[TYPEC_PORT_DRP] = "dual",
 };
 
+static const char * const typec_data_types[] = {
+   [TYPEC_PORT_DFP] = "host",
+   [TYPEC_PORT_UFP] = "device",
+   [TYPEC_PORT_DRD] = "dual",
+};
+
 static const char * const typec_port_types_drp[] = {
[TYPEC_PORT_SRC] = "dual [source] sink",
[TYPEC_PORT_SNK] = "dual source [sink]",
@@ -1252,6 +1259,51 @@ void typec_set_pwr_opmode(struct typec_port *port,
 }
 EXPORT_SYMBOL_GPL(typec_set_pwr_opmode);
 
+/**
+ * typec_find_power_type - Get the typec port power type
+ * @name: port type string
+ *
+ * This routine is used to find the typec_port_type by its string name.
+ *
+ * Returns typec_port_type if success, otherwise negative error code.
+ */
+int typec_find_power_type(const char *name)
+{
+   return match_string(typec_port_types, ARRAY_SIZE(typec_port_types),
+   name);
+}
+EXPORT_SYMBOL_GPL(typec_find_power_type);
+
+/**
+ * typec_find_preferred_role - Find the typec drp port preferred power role
+ * @name: power role string
+ *
+ * This routine is used to find the typec_role by its string name of
+ * preferred power role(Try.SRC or Try.SNK).
+ *
+ * Returns typec_role if success, otherwise negative error code.
+ */
+int typec_find_preferred_role(const char *name)
+{
+   return match_string(typec_roles, ARRAY_SIZE(typec_roles), name);
+}
+EXPORT_SYMBOL_GPL(typec_find_preferred_role);
+
+/**
+ * typec_find_data_type - Get the typec port data capability
+ * @name: data type string
+ *
+ * This routine is used to find the typec_port_data by its string name.
+ *
+ * Returns typec_port_data if success, otherwise negative error code.
+ */
+int typec_find_data_type(const char *name)
+{
+   return match_string(typec_data_types, ARRAY_SIZE(typec_data_types),
+   name);
+}
+EXPORT_SYMBOL_GPL(typec_find_data_type);
+
 /* -- */
 /* API for Multiplexer/DeMultiplexer Switches */
 
diff --git a/include/linux/usb/typec.h b/include/linux/usb/typec.h
index 672b39b..00c93e7 100644
--- a/include/linux/usb/typec.h
+++ b/include/linux/usb/typec.h
@@ -267,4 +267,7 @@ int typec_set_orientation(struct typec_port *port,
  enum typec_orientation orientation);
 int typec_set_mode(struct typec_port *port, int mode);
 
+int typec_find_power_type(const char *name);
+int typec_find_preferred_role(const char *name);
+int typec_find_data_type(const char *name);
 #endif /* __LINUX_USB_TYPEC_H */
-- 
2.7.4

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v5 02/14] 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 
---
 .../devicetree/bindings/usb/typec-tcpci.txt| 49 ++
 1 file changed, 49 insertions(+)

diff --git a/Documentation/devicetree/bindings/usb/typec-tcpci.txt 
b/Documentation/devicetree/bindings/usb/typec-tcpci.txt
new file mode 100644
index 000..0dd1469
--- /dev/null
+++ b/Documentation/devicetree/bindings/usb/typec-tcpci.txt
@@ -0,0 +1,49 @@
+TCPCI(Typec port cotroller interface) binding
+-
+
+Required properties:
+- compatible:   should be set one of following:
+   - "nxp,ptn5110" for NXP USB PD TCPC PHY IC ptn5110.
+
+- 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 = "nxp,ptn5110";
+   reg = <0x50>;
+   interrupt-parent = <>;
+   interrupts = <3 IRQ_TYPE_LEVEL_LOW>;
+
+   usb_con: connector {
+   compatible = "usb-c-connector";
+   label = "USB-C";
+   data-role = "dual";
+   power-role = "dual";
+   try-power-role = "sink";
+   source-pdos = ;
+   sink-pdos = ;
+   op-sink-microwatt = <1000>;
+
+   ports {
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   port@1 {
+   reg = <1>;
+   usb_con_ss: endpoint {
+   remote-endpoint = <_data_ss>;
+   };
+   };
+   };
+   };
+};
-- 
2.7.4

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v5 00/14] 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 define typec and power delivery device
properties, the changes are 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.

Changes for v5:
- Use "power-role" and "data-role" for typec port power and data capability
  property name.  
- Use macro defintion instead of cryptic numbers for readability of
  power delivery properties(PDO).
- Add one tcpci driver binding string to be "nxp,ptn5110" to follow binding
  name rule ",".
- Change operating power property name to be op-sink-microwatt.
- Add one patch(remove unused tcpci_tcpc_config) to resolve bisectablitity
  issue of patch usb: typec: add fwnode to tcpc.
- A minor error handling change to keep the error path and success path
  separate in patch: register port before request irq
- Rebase to latest Greg's tree with max_snk_* removed.

Changes for v4:
- Remove max-sink-* properties as we will purge max_snk_* in tcpm,
  see patch set[4].
- Get typec power and data type value via name string(patch 5).
- Move finding typec and pd properties code from tcpci to tcpm(patch 6)
- Add a compatible string for nxp ptn5110 typec controller in tcpci driver.
  (patch 3)
- Add set cc for drp toggling without try.src/snk in tcpm(patch 10), then
  patch 11 can only update CCx bits for keep disconnect cc line open.
- Update op-sink-microwatt-hours example value to be the right value in
  micorwatts, and accordingly divide 1000 to get its miliwatts value
  in patch 6.
- Add Guenter's Reviewed-by for patch(8/9/12)

[4] https://www.spinics.net/lists/linux-usb/msg167261.html

Changes for v3:
- Use 2 properties to separate power and data capability of typec port:
  "power-type" and "data-type", this is based on Heikki's typec class code
  change[2]. use "try-power-role" to present if the typec port can support
  Try.SNK or Try.SRC.
- 4 sink properties(max_sink_mv/ma/mw and op_sink_mw) are kept because the
  counterpart code is back, see revert patch[3], meanwhile I post a patch
  to fix the reported problem of current source pdo select machinism(which
  completely ignored those 4 sink settings), to see if we can keep current
  code, once it was discussed and have conclusion I can update this
  accordingly.
- Use fwnode to get the connector node for dt setting parse.

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/
[2] https://patchwork.kernel.org/patch/10276483/
[3] https://www.spinics.net/lists/linux-usb/msg166366.html

Li Jun (13):
  dt-bindings: connector: add properties for typec
  dt-bindings: usb: add documentation for typec port controller(TCPCI)
  staging: typec: tcpci: add compatible string for nxp ptn5110
  usb: typec: add fwnode to tcpc
  usb: typec: add API to get typec basic port power and data config
  usb: typec: tcpm: support get typec and pd config from device
properties
  staging: typec: tcpci: remove unused tcpci_tcpc_config
  staging: typec: tcpci: enable vbus detection
  typec: tcpm: add starting value for drp toggling
  usb: typec: tcpm: set cc for drp toggling attach
  staging: typec: tcpci: keep the not connecting cc line open
  staging: typec: tcpci: Only touch target bit when enable vconn
  staging: typec: tcpci: move tcpci driver out of staging

Peter Chen (1):
  staging: typec: tcpci: register port before request irq

 .../bindings/connector/usb-connector.txt   |  44 ++
 .../devicetree/bindings/usb/typec-tcpci.txt|  49 +++
 drivers/staging/Kconfig|   2 -
 drivers/staging/Makefile   |   1 -
 drivers/staging/typec/TODO |   5 -
 drivers/usb/typec/Kconfig  |   7 +
 drivers/usb/typec/Makefile |   1 +
 drivers/usb/typec/class.c  |  52 +++
 drivers/{staging => usb}/typec/tcpci.c |  63 +
 drivers/{staging => usb}/typec/tcpci.h |   0
 drivers/usb/typec/tcpm.c   | 149 +
 include/dt-bindings/usb/pd.h   |  62 +
 include/linux/usb/tcpm.h   |   2 +
 include/linux/usb/typec.h  |   3 +
 14 files changed, 382 insertions(+), 58 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/usb/typec-tcpci.txt
 delete mode 100644 drivers/staging/typec/TODO
 rename 

[PATCH v5 01/14] dt-bindings: connector: add properties for typec

[Li Jun]

Add bingdings supported by current typec driver, so user can pass
all those properties via dt.

Signed-off-by: Li Jun 
---
 .../bindings/connector/usb-connector.txt   | 44 +++
 include/dt-bindings/usb/pd.h   | 62 ++
 2 files changed, 106 insertions(+)

diff --git a/Documentation/devicetree/bindings/connector/usb-connector.txt 
b/Documentation/devicetree/bindings/connector/usb-connector.txt
index e1463f1..4b19de6d0 100644
--- a/Documentation/devicetree/bindings/connector/usb-connector.txt
+++ b/Documentation/devicetree/bindings/connector/usb-connector.txt
@@ -15,6 +15,33 @@ Optional properties:
 - type: size of the connector, should be specified in case of USB-A, USB-B
   non-fullsize connectors: "mini", "micro".
 
+Optional properties for usb-c-connector:
+- power-role: should be one of "source", "sink" or "dual"(DRP) if typec
+  connector has power support.
+- try-power-role: preferred power role if "dual"(DRP) can support Try.SNK
+  or Try.SRC, should be "sink" for Try.SNK or "source" for Try.SRC.
+- data-role: should be one of "host", "device", "dual"(DRD) if typec
+  connector supports USB data.
+
+Required properties for usb-c-connector with power delivery support:
+- source-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.
+  User can specify the source PDO array via PDO_FIXED/BATT/VAR() defined in
+  dt-bindings/usb/pd.h.
+- sink-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.
+  User can specify the sink PDO array via PDO_FIXED/BATT/VAR() defined in
+  dt-bindings/usb/pd.h.
+- op-sink-microwatt: Sink required operating power in microwatt, if source
+  can't offer the power, 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 +100,20 @@ 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";
+   power-role = "dual";
+   try-power-role = "sink";
+   source-pdos = ;
+   sink-pdos = ;
+   op-sink-microwatt = <1000>;
+   };
+};
diff --git a/include/dt-bindings/usb/pd.h b/include/dt-bindings/usb/pd.h
new file mode 100644
index 000..7b7a92f
--- /dev/null
+++ b/include/dt-bindings/usb/pd.h
@@ -0,0 +1,62 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+#ifndef __DT_POWER_DELIVERY_H
+#define __DT_POWER_DELIVERY_H
+
+/* Power delivery Power Data Object definitions */
+#define PDO_TYPE_FIXED 0
+#define PDO_TYPE_BATT  1
+#define PDO_TYPE_VAR   2
+#define PDO_TYPE_APDO  3
+
+#define PDO_TYPE_SHIFT 30
+#define PDO_TYPE_MASK  0x3
+
+#define PDO_TYPE(t)((t) << PDO_TYPE_SHIFT)
+
+#define PDO_VOLT_MASK  0x3ff
+#define PDO_CURR_MASK  0x3ff
+#define PDO_PWR_MASK   0x3ff
+
+#define PDO_FIXED_DUAL_ROLE(1 << 29) /* Power role swap supported */
+#define PDO_FIXED_SUSPEND  (1 << 28) /* USB Suspend supported (Source) */
+#define PDO_FIXED_HIGHER_CAP   (1 << 28) /* Requires more than vSafe5V (Sink) 
*/
+#define PDO_FIXED_EXTPOWER (1 << 27) /* Externally powered */
+#define PDO_FIXED_USB_COMM (1 << 26) /* USB communications capable */
+#define PDO_FIXED_DATA_SWAP(1 << 25) /* Data role swap supported */
+#define PDO_FIXED_VOLT_SHIFT   10  /* 50mV units */
+#define PDO_FIXED_CURR_SHIFT   0   /* 10mA units */
+
+#define PDO_FIXED_VOLT(mv) mv) / 50) & PDO_VOLT_MASK) << 
PDO_FIXED_VOLT_SHIFT)
+#define PDO_FIXED_CURR(ma) ma) / 10) & PDO_CURR_MASK) << 
PDO_FIXED_CURR_SHIFT)
+
+#define PDO_FIXED(mv, ma, flags)   \
+   (PDO_TYPE(PDO_TYPE_FIXED) | (flags) |   \
+PDO_FIXED_VOLT(mv) | PDO_FIXED_CURR(ma))
+
+#define VSAFE5V 5000 /* mv units */
+
+#define PDO_BATT_MAX_VOLT_SHIFT20  /* 50mV units */
+#define 

[PATCH v5 1/7] clk: msm8996-gcc: Mark halt check as no-op for USB/PCIE pipe_clk

[Manu Gautam]

The USB and PCIE pipe clocks are sourced from external clocks
inside the QMP USB/PCIE PHYs. Enabling or disabling of PIPE RCG
clocks is dependent on PHY initialization sequence hence
update halt_check to BRANCH_HALT_SKIP for these clocks so
that clock status bit is not polled when enabling or disabling
the clocks. It allows to simplify PHY client driver code which
is both user and source of the pipe_clk and avoid error logging
related status check on clk_disable/enable.

Signed-off-by: Manu Gautam 
---
 drivers/clk/qcom/gcc-msm8996.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/drivers/clk/qcom/gcc-msm8996.c b/drivers/clk/qcom/gcc-msm8996.c
index 3d64529..b73e7f1 100644
--- a/drivers/clk/qcom/gcc-msm8996.c
+++ b/drivers/clk/qcom/gcc-msm8996.c
@@ -1418,6 +1418,7 @@ enum {
 
 static struct clk_branch gcc_usb3_phy_pipe_clk = {
.halt_reg = 0x50004,
+   .halt_check = BRANCH_HALT_SKIP,
.clkr = {
.enable_reg = 0x50004,
.enable_mask = BIT(0),
@@ -2472,6 +2473,7 @@ enum {
 
 static struct clk_branch gcc_pcie_0_pipe_clk = {
.halt_reg = 0x6b018,
+   .halt_check = BRANCH_HALT_SKIP,
.clkr = {
.enable_reg = 0x6b018,
.enable_mask = BIT(0),
@@ -2547,6 +2549,7 @@ enum {
 
 static struct clk_branch gcc_pcie_1_pipe_clk = {
.halt_reg = 0x6d018,
+   .halt_check = BRANCH_HALT_SKIP,
.clkr = {
.enable_reg = 0x6d018,
.enable_mask = BIT(0),
@@ -2622,6 +2625,7 @@ enum {
 
 static struct clk_branch gcc_pcie_2_pipe_clk = {
.halt_reg = 0x6e018,
+   .halt_check = BRANCH_HALT_SKIP,
.clkr = {
.enable_reg = 0x6e018,
.enable_mask = BIT(0),
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v5 3/7] phy: qcom-qusb2: Fix crash if nvmem cell not specified

[Manu Gautam]

Driver currently crashes due to NULL pointer deference
while updating PHY tune register if nvmem cell is NULL.
Since, fused value for Tune1/2 register is optional,
we'd rather bail out.

Fixes: ca04d9d3e1b1 ("phy: qcom-qusb2: New driver for QUSB2 PHY on Qcom chips")
Reviewed-by: Vivek Gautam 
Reviewed-by: Evan Green 
Cc: stable  # 4.14+
Signed-off-by: Manu Gautam 
---
 drivers/phy/qualcomm/phy-qcom-qusb2.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/drivers/phy/qualcomm/phy-qcom-qusb2.c 
b/drivers/phy/qualcomm/phy-qcom-qusb2.c
index 94afeac..40fdef8 100644
--- a/drivers/phy/qualcomm/phy-qcom-qusb2.c
+++ b/drivers/phy/qualcomm/phy-qcom-qusb2.c
@@ -315,6 +315,10 @@ static void qusb2_phy_set_tune2_param(struct qusb2_phy 
*qphy)
const struct qusb2_phy_cfg *cfg = qphy->cfg;
u8 *val;
 
+   /* efuse register is optional */
+   if (!qphy->cell)
+   return;
+
/*
 * Read efuse register having TUNE2/1 parameter's high nibble.
 * If efuse register shows value as 0x0, or if we fail to find
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v5 5/7] phy: qcom-qmp: Add QMP V3 USB3 UNI PHY support for sdm845

[Manu Gautam]

QMP V3 UNI PHY is a single lane USB3 PHY without support
for DisplayPort (DP).
Main difference from DP combo QMPv3 PHY is that UNI PHY
doesn't have dual RX/TX lanes and no separate DP_COM
block for configuration related to type-c or DP.
Also remove "qcom,qmp-v3-usb3-phy" compatible string which
was earlier added for sdm845 only as there wouldn't be
any user of same.
While at it, fix has_pwrdn_delay attribute for USB-DP
PHY configuration and.

Reviewed-by: Evan Green 
Signed-off-by: Manu Gautam 
---
 drivers/phy/qualcomm/phy-qcom-qmp.c | 147 +++-
 drivers/phy/qualcomm/phy-qcom-qmp.h |   5 ++
 2 files changed, 151 insertions(+), 1 deletion(-)

diff --git a/drivers/phy/qualcomm/phy-qcom-qmp.c 
b/drivers/phy/qualcomm/phy-qcom-qmp.c
index fddb1c9..4c47010 100644
--- a/drivers/phy/qualcomm/phy-qcom-qmp.c
+++ b/drivers/phy/qualcomm/phy-qcom-qmp.c
@@ -490,6 +490,118 @@ enum qphy_reg_layout {
QMP_PHY_INIT_CFG(QPHY_V3_PCS_RXEQTRAINING_RUN_TIME, 0x13),
 };
 
+static const struct qmp_phy_init_tbl qmp_v3_usb3_uniphy_serdes_tbl[] = {
+   QMP_PHY_INIT_CFG(QSERDES_V3_COM_PLL_IVCO, 0x07),
+   QMP_PHY_INIT_CFG(QSERDES_V3_COM_SYSCLK_EN_SEL, 0x14),
+   QMP_PHY_INIT_CFG(QSERDES_V3_COM_BIAS_EN_CLKBUFLR_EN, 0x04),
+   QMP_PHY_INIT_CFG(QSERDES_V3_COM_CLK_SELECT, 0x30),
+   QMP_PHY_INIT_CFG(QSERDES_V3_COM_SYS_CLK_CTRL, 0x02),
+   QMP_PHY_INIT_CFG(QSERDES_V3_COM_RESETSM_CNTRL2, 0x08),
+   QMP_PHY_INIT_CFG(QSERDES_V3_COM_CMN_CONFIG, 0x06),
+   QMP_PHY_INIT_CFG(QSERDES_V3_COM_SVS_MODE_CLK_SEL, 0x01),
+   QMP_PHY_INIT_CFG(QSERDES_V3_COM_HSCLK_SEL, 0x80),
+   QMP_PHY_INIT_CFG(QSERDES_V3_COM_DEC_START_MODE0, 0x82),
+   QMP_PHY_INIT_CFG(QSERDES_V3_COM_DIV_FRAC_START1_MODE0, 0xab),
+   QMP_PHY_INIT_CFG(QSERDES_V3_COM_DIV_FRAC_START2_MODE0, 0xea),
+   QMP_PHY_INIT_CFG(QSERDES_V3_COM_DIV_FRAC_START3_MODE0, 0x02),
+   QMP_PHY_INIT_CFG(QSERDES_V3_COM_CP_CTRL_MODE0, 0x06),
+   QMP_PHY_INIT_CFG(QSERDES_V3_COM_PLL_RCTRL_MODE0, 0x16),
+   QMP_PHY_INIT_CFG(QSERDES_V3_COM_PLL_CCTRL_MODE0, 0x36),
+   QMP_PHY_INIT_CFG(QSERDES_V3_COM_INTEGLOOP_GAIN1_MODE0, 0x00),
+   QMP_PHY_INIT_CFG(QSERDES_V3_COM_INTEGLOOP_GAIN0_MODE0, 0x3f),
+   QMP_PHY_INIT_CFG(QSERDES_V3_COM_VCO_TUNE2_MODE0, 0x01),
+   QMP_PHY_INIT_CFG(QSERDES_V3_COM_VCO_TUNE1_MODE0, 0xc9),
+   QMP_PHY_INIT_CFG(QSERDES_V3_COM_CORECLK_DIV_MODE0, 0x0a),
+   QMP_PHY_INIT_CFG(QSERDES_V3_COM_LOCK_CMP3_MODE0, 0x00),
+   QMP_PHY_INIT_CFG(QSERDES_V3_COM_LOCK_CMP2_MODE0, 0x34),
+   QMP_PHY_INIT_CFG(QSERDES_V3_COM_LOCK_CMP1_MODE0, 0x15),
+   QMP_PHY_INIT_CFG(QSERDES_V3_COM_LOCK_CMP_EN, 0x04),
+   QMP_PHY_INIT_CFG(QSERDES_V3_COM_CORE_CLK_EN, 0x00),
+   QMP_PHY_INIT_CFG(QSERDES_V3_COM_LOCK_CMP_CFG, 0x00),
+   QMP_PHY_INIT_CFG(QSERDES_V3_COM_VCO_TUNE_MAP, 0x00),
+   QMP_PHY_INIT_CFG(QSERDES_V3_COM_SYSCLK_BUF_ENABLE, 0x0a),
+   QMP_PHY_INIT_CFG(QSERDES_V3_COM_SSC_EN_CENTER, 0x01),
+   QMP_PHY_INIT_CFG(QSERDES_V3_COM_SSC_PER1, 0x31),
+   QMP_PHY_INIT_CFG(QSERDES_V3_COM_SSC_PER2, 0x01),
+   QMP_PHY_INIT_CFG(QSERDES_V3_COM_SSC_ADJ_PER1, 0x00),
+   QMP_PHY_INIT_CFG(QSERDES_V3_COM_SSC_ADJ_PER2, 0x00),
+   QMP_PHY_INIT_CFG(QSERDES_V3_COM_SSC_STEP_SIZE1, 0x85),
+   QMP_PHY_INIT_CFG(QSERDES_V3_COM_SSC_STEP_SIZE2, 0x07),
+};
+
+static const struct qmp_phy_init_tbl qmp_v3_usb3_uniphy_tx_tbl[] = {
+   QMP_PHY_INIT_CFG(QSERDES_V3_TX_HIGHZ_DRVR_EN, 0x10),
+   QMP_PHY_INIT_CFG(QSERDES_V3_TX_RCV_DETECT_LVL_2, 0x12),
+   QMP_PHY_INIT_CFG(QSERDES_V3_TX_LANE_MODE_1, 0xc6),
+   QMP_PHY_INIT_CFG(QSERDES_V3_TX_RES_CODE_LANE_OFFSET_RX, 0x06),
+   QMP_PHY_INIT_CFG(QSERDES_V3_TX_RES_CODE_LANE_OFFSET_TX, 0x06),
+};
+
+static const struct qmp_phy_init_tbl qmp_v3_usb3_uniphy_rx_tbl[] = {
+   QMP_PHY_INIT_CFG(QSERDES_V3_RX_VGA_CAL_CNTRL2, 0x0c),
+   QMP_PHY_INIT_CFG(QSERDES_V3_RX_RX_MODE_00, 0x50),
+   QMP_PHY_INIT_CFG(QSERDES_V3_RX_UCDR_FASTLOCK_FO_GAIN, 0x0b),
+   QMP_PHY_INIT_CFG(QSERDES_V3_RX_RX_EQU_ADAPTOR_CNTRL2, 0x0e),
+   QMP_PHY_INIT_CFG(QSERDES_V3_RX_RX_EQU_ADAPTOR_CNTRL3, 0x4e),
+   QMP_PHY_INIT_CFG(QSERDES_V3_RX_RX_EQU_ADAPTOR_CNTRL4, 0x18),
+   QMP_PHY_INIT_CFG(QSERDES_V3_RX_RX_EQ_OFFSET_ADAPTOR_CNTRL1, 0x77),
+   QMP_PHY_INIT_CFG(QSERDES_V3_RX_RX_OFFSET_ADAPTOR_CNTRL2, 0x80),
+   QMP_PHY_INIT_CFG(QSERDES_V3_RX_SIGDET_CNTRL, 0x03),
+   QMP_PHY_INIT_CFG(QSERDES_V3_RX_SIGDET_DEGLITCH_CNTRL, 0x1c),
+   QMP_PHY_INIT_CFG(QSERDES_V3_RX_UCDR_SO_SATURATION_AND_ENABLE, 0x75),
+};
+
+static const struct qmp_phy_init_tbl qmp_v3_usb3_uniphy_pcs_tbl[] = {
+   /* FLL settings */
+   QMP_PHY_INIT_CFG(QPHY_V3_PCS_FLL_CNTRL2, 0x83),
+   QMP_PHY_INIT_CFG(QPHY_V3_PCS_FLL_CNT_VAL_L, 0x09),
+   QMP_PHY_INIT_CFG(QPHY_V3_PCS_FLL_CNT_VAL_H_TOL, 0xa2),
+   QMP_PHY_INIT_CFG(QPHY_V3_PCS_FLL_MAN_CODE, 0x40),
+   

[PATCH v5 4/7] dt-bindings: phy-qcom-qmp: Update bindings for sdm845

[Manu Gautam]

Update compatible strings for USB3 PHYs on SDM845.
One is QMPv3 DisplayPort-USB combo PHY and other one
is USB UNI PHY which is single lane USB3 PHY without
DP capability. While at it also remove "qcom,qmp-v3-usb3-phy"
compatible string which was earlier added for sdm845
only as there wouldn't be any user of same.

Reviewed-by: Douglas Anderson 
Signed-off-by: Manu Gautam 
---
 Documentation/devicetree/bindings/phy/qcom-qmp-phy.txt | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/Documentation/devicetree/bindings/phy/qcom-qmp-phy.txt 
b/Documentation/devicetree/bindings/phy/qcom-qmp-phy.txt
index dcf1b8f..266a1bb 100644
--- a/Documentation/devicetree/bindings/phy/qcom-qmp-phy.txt
+++ b/Documentation/devicetree/bindings/phy/qcom-qmp-phy.txt
@@ -9,7 +9,8 @@ Required properties:
   "qcom,ipq8074-qmp-pcie-phy" for PCIe phy on IPQ8074
   "qcom,msm8996-qmp-pcie-phy" for 14nm PCIe phy on msm8996,
   "qcom,msm8996-qmp-usb3-phy" for 14nm USB3 phy on msm8996,
-  "qcom,qmp-v3-usb3-phy" for USB3 QMP V3 phy.
+  "qcom,sdm845-qmp-usb3-phy" for USB3 QMP V3 phy on sdm845,
+  "qcom,sdm845-qmp-usb3-uni-phy" for USB3 QMP V3 UNI phy on sdm845.
 
  - reg: offset and length of register set for PHY's common serdes block.
 
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v5 7/7] phy: qcom-qusb2: Add QUSB2 PHYs support for sdm845

[Manu Gautam]

There are two QUSB2 PHYs present on sdm845. In order
to improve eye diagram for both the PHYs some parameters
need to be changed. Provide device tree properties to
override these from board specific device tree files.

Signed-off-by: Manu Gautam 
---
 drivers/phy/qualcomm/phy-qcom-qusb2.c | 126 +++---
 1 file changed, 118 insertions(+), 8 deletions(-)

diff --git a/drivers/phy/qualcomm/phy-qcom-qusb2.c 
b/drivers/phy/qualcomm/phy-qcom-qusb2.c
index 40fdef8..e70e425 100644
--- a/drivers/phy/qualcomm/phy-qcom-qusb2.c
+++ b/drivers/phy/qualcomm/phy-qcom-qusb2.c
@@ -20,6 +20,8 @@
 #include 
 #include 
 
+#include 
+
 #define QUSB2PHY_PLL_TEST  0x04
 #define CLK_REF_SELBIT(7)
 
@@ -60,6 +62,17 @@
 #define CORE_RESET BIT(5)
 #define CORE_RESET_MUX BIT(6)
 
+/* QUSB2PHY_IMP_CTRL1 register bits */
+#define IMP_RES_OFFSET_MASKGENMASK(5, 0)
+#define IMP_RES_OFFSET_SHIFT   0x0
+
+/* QUSB2PHY_PORT_TUNE1 register bits */
+#define HSTX_TRIM_MASK GENMASK(7, 4)
+#define HSTX_TRIM_SHIFT0x4
+#define PREEMPH_WIDTH_HALF_BIT BIT(2)
+#define PREEMPHASIS_EN_MASKGENMASK(1, 0)
+#define PREEMPHASIS_EN_SHIFT   0x0
+
 #define QUSB2PHY_PLL_ANALOG_CONTROLS_TWO   0x04
 #define QUSB2PHY_PLL_CLOCK_INVERTERS   0x18c
 #define QUSB2PHY_PLL_CMODE 0x2c
@@ -139,7 +152,7 @@ enum qusb2phy_reg_layout {
QUSB2_PHY_INIT_CFG(QUSB2PHY_PLL_PWR_CTRL, 0x00),
 };
 
-static const unsigned int qusb2_v2_regs_layout[] = {
+static const unsigned int sdm845_regs_layout[] = {
[QUSB2PHY_PLL_CORE_INPUT_OVERRIDE] = 0xa8,
[QUSB2PHY_PLL_STATUS]   = 0x1a0,
[QUSB2PHY_PORT_TUNE1]   = 0x240,
@@ -153,7 +166,7 @@ enum qusb2phy_reg_layout {
[QUSB2PHY_INTR_CTRL]= 0x230,
 };
 
-static const struct qusb2_phy_init_tbl qusb2_v2_init_tbl[] = {
+static const struct qusb2_phy_init_tbl sdm845_init_tbl[] = {
QUSB2_PHY_INIT_CFG(QUSB2PHY_PLL_ANALOG_CONTROLS_TWO, 0x03),
QUSB2_PHY_INIT_CFG(QUSB2PHY_PLL_CLOCK_INVERTERS, 0x7c),
QUSB2_PHY_INIT_CFG(QUSB2PHY_PLL_CMODE, 0x80),
@@ -208,10 +221,10 @@ struct qusb2_phy_cfg {
.autoresume_en   = BIT(3),
 };
 
-static const struct qusb2_phy_cfg qusb2_v2_phy_cfg = {
-   .tbl= qusb2_v2_init_tbl,
-   .tbl_num= ARRAY_SIZE(qusb2_v2_init_tbl),
-   .regs   = qusb2_v2_regs_layout,
+static const struct qusb2_phy_cfg sdm845_phy_cfg = {
+   .tbl= sdm845_init_tbl,
+   .tbl_num= ARRAY_SIZE(sdm845_init_tbl),
+   .regs   = sdm845_regs_layout,
 
.disable_ctrl   = (PWR_CTRL1_VREF_SUPPLY_TRIM | PWR_CTRL1_CLAMP_N_EN |
   POWER_DOWN),
@@ -241,6 +254,15 @@ struct qusb2_phy_cfg {
  * @tcsr: TCSR syscon register map
  * @cell: nvmem cell containing phy tuning value
  *
+ * @override_imp_res_offset: PHY should use different rescode offset
+ * @imp_res_offset_value: rescode offset to be updated in IMP_CTRL1 register
+ * @override_hstx_trim: PHY should use different HSTX o/p current value
+ * @hstx_trim_value: HSTX_TRIM value to be updated in TUNE1 register
+ * @override_preemphasis: PHY should use different pre-amphasis amplitude
+ * @preemphasis_level: Amplitude Pre-Emphasis to be updated in TUNE1 register
+ * @override_preemphasis_width: PHY should use different pre-emphasis duration
+ * @preemphasis_width: half/full-width Pre-Emphasis updated via TUNE1
+ *
  * @cfg: phy config data
  * @has_se_clk_scheme: indicate if PHY has single-ended ref clock scheme
  * @phy_initialized: indicate if PHY has been initialized
@@ -259,12 +281,35 @@ struct qusb2_phy {
struct regmap *tcsr;
struct nvmem_cell *cell;
 
+   bool override_imp_res_offset;
+   u8 imp_res_offset_value;
+   bool override_hstx_trim;
+   u8 hstx_trim_value;
+   bool override_preemphasis;
+   u8 preemphasis_level;
+   bool override_preemphasis_width;
+   u8 preemphasis_width;
+
const struct qusb2_phy_cfg *cfg;
bool has_se_clk_scheme;
bool phy_initialized;
enum phy_mode mode;
 };
 
+static inline void qusb2_write_mask(void __iomem *base, u32 offset,
+   u32 val, u32 mask)
+{
+   u32 reg;
+
+   reg = readl(base + offset);
+   reg &= ~mask;
+   reg |= val & mask;
+   writel(reg, base + offset);
+
+   /* Ensure above write is completed */
+   readl(base + offset);
+}
+
 static inline void qusb2_setbits(void __iomem *base, u32 offset, u32 val)
 {
u32 reg;
@@ -305,6 +350,42 @@ void qcom_qusb2_phy_configure(void __iomem *base,
 }
 
 /*
+ * Update board specific PHY tuning override values if specified from
+ * device tree.
+ */
+static void 

[PATCH v5 6/7] dt-bindings: phy-qcom-usb2: Add support to override tuning values

[Manu Gautam]

To improve eye diagram for PHYs on different boards of same SOC,
some parameters may need to be changed. Provide device tree
properties to override these from board specific device tree
files. While at it, replace "qcom,qusb2-v2-phy" with compatible
string for USB2 PHY on sdm845 which was earlier added for
sdm845 only.

Signed-off-by: Manu Gautam 
---
 .../devicetree/bindings/phy/qcom-qusb2-phy.txt | 23 +-
 include/dt-bindings/phy/phy-qcom-qusb2.h   | 37 ++
 2 files changed, 59 insertions(+), 1 deletion(-)
 create mode 100644 include/dt-bindings/phy/phy-qcom-qusb2.h

diff --git a/Documentation/devicetree/bindings/phy/qcom-qusb2-phy.txt 
b/Documentation/devicetree/bindings/phy/qcom-qusb2-phy.txt
index 42c9742..03025d9 100644
--- a/Documentation/devicetree/bindings/phy/qcom-qusb2-phy.txt
+++ b/Documentation/devicetree/bindings/phy/qcom-qusb2-phy.txt
@@ -6,7 +6,7 @@ QUSB2 controller supports LS/FS/HS usb connectivity on Qualcomm 
chipsets.
 Required properties:
  - compatible: compatible list, contains
   "qcom,msm8996-qusb2-phy" for 14nm PHY on msm8996,
-  "qcom,qusb2-v2-phy" for QUSB2 V2 PHY.
+  "qcom,sdm845-qusb2-phy" for 10nm PHY on sdm845.
 
  - reg: offset and length of the PHY register set.
  - #phy-cells: must be 0.
@@ -27,6 +27,27 @@ Optional properties:
tuning parameter value for qusb2 phy.
 
  - qcom,tcsr-syscon: Phandle to TCSR syscon register region.
+ - qcom,imp-res-offset-value: It is a 6 bit value that specifies offset to be
+   added to PHY refgen RESCODE via IMP_CTRL1 register. It is a PHY
+   tuning parameter that may vary for different boards of same SOC.
+   This property is applicable to only QUSB2 v2 PHY (sdm845).
+ - qcom,hstx-trim-value: It is a 4 bit value that specifies tuning for HSTX
+   output current.
+   Possible range is - 15mA to 24mA (stepsize of 600 uA).
+   See dt-bindings/phy/phy-qcom-qusb2.h for applicable values.
+   This property is applicable to only QUSB2 v2 PHY (sdm845).
+   Default value is 22.2mA for sdm845.
+ - qcom,preemphasis-level: It is a 2 bit value that specifies pre-emphasis 
level.
+   Possible range is 0 to 15% (stepsize of 5%).
+   See dt-bindings/phy/phy-qcom-qusb2.h for applicable values.
+   This property is applicable to only QUSB2 v2 PHY (sdm845).
+   Default value is 10% for sdm845.
+- qcom,preemphasis-width: It is a 1 bit value that specifies how long the HSTX
+   pre-emphasis (specified using qcom,preemphasis-level) must be in
+   effect. Duration could be half-bit of full-bit.
+   See dt-bindings/phy/phy-qcom-qusb2.h for applicable values.
+   This property is applicable to only QUSB2 v2 PHY (sdm845).
+   Default value is full-bit width for sdm845.
 
 Example:
hsusb_phy: phy@7411000 {
diff --git a/include/dt-bindings/phy/phy-qcom-qusb2.h 
b/include/dt-bindings/phy/phy-qcom-qusb2.h
new file mode 100644
index 000..aea814a
--- /dev/null
+++ b/include/dt-bindings/phy/phy-qcom-qusb2.h
@@ -0,0 +1,37 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (c) 2018, The Linux Foundation. All rights reserved.
+ */
+
+#ifndef _DT_BINDINGS_QCOM_PHY_QUSB2_H_
+#define _DT_BINDINGS_QCOM_PHY_QUSB2_H_
+
+/* PHY HSTX TRIM bit values (24mA to 15mA) */
+#define QUSB2_V2_HSTX_TRIM_24_0_MA 0x0
+#define QUSB2_V2_HSTX_TRIM_23_4_MA 0x1
+#define QUSB2_V2_HSTX_TRIM_22_8_MA 0x2
+#define QUSB2_V2_HSTX_TRIM_22_2_MA 0x3
+#define QUSB2_V2_HSTX_TRIM_21_6_MA 0x4
+#define QUSB2_V2_HSTX_TRIM_21_0_MA 0x5
+#define QUSB2_V2_HSTX_TRIM_20_4_MA 0x6
+#define QUSB2_V2_HSTX_TRIM_19_8_MA 0x7
+#define QUSB2_V2_HSTX_TRIM_19_2_MA 0x8
+#define QUSB2_V2_HSTX_TRIM_18_6_MA 0x9
+#define QUSB2_V2_HSTX_TRIM_18_0_MA 0xa
+#define QUSB2_V2_HSTX_TRIM_17_4_MA 0xb
+#define QUSB2_V2_HSTX_TRIM_16_8_MA 0xc
+#define QUSB2_V2_HSTX_TRIM_16_2_MA 0xd
+#define QUSB2_V2_HSTX_TRIM_15_6_MA 0xe
+#define QUSB2_V2_HSTX_TRIM_15_0_MA 0xf
+
+/* PHY PREEMPHASIS bit values */
+#define QUSB2_V2_PREEMPHASIS_NONE  0
+#define QUSB2_V2_PREEMPHASIS_5_PERCENT 1
+#define QUSB2_V2_PREEMPHASIS_10_PERCENT2
+#define QUSB2_V2_PREEMPHASIS_15_PERCENT3
+
+/* PHY PREEMPHASIS-WIDTH bit values */
+#define QUSB2_V2_PREEMPHASIS_WIDTH_FULL_BIT0
+#define QUSB2_V2_PREEMPHASIS_WIDTH_HALF_BIT1
+
+#endif
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  

[PATCH v5 0/7] phy: qcom: Updates for USB PHYs on SDM845

[Manu Gautam]

SDM845 has two USB instances each with QUSB2 and QMP PHYs.
One of the QMP PHY is USB-DP (DisplayPort) combo PHY where
as other one is single lane UNI-PHY (without DP support).
Changes are related to PHY configuration for electrical
parameters tuning to improve eye-diagram and some fixes.

First gcc-msm8996 driver patch is dependent on following
patch which is now applied by Stephen.
https://patchwork.kernel.org/patch/10375043/


Changes since v4:
 - Addressed Doug's review comments to have QUSB2 PHY tuning
   values in header file.
 - Updated msm8996-gcc patch to use BRANCH_HALT_SKIP flag
   added by patch - https://patchwork.kernel.org/patch/10375041/
   
Changes since v3:
 - As per Doug's review comments added device tree parameters
   to handle board level differences in PHY tuning values instead
   of adding separate device tree bindings.
 - Replace PHY version specific bindings names with SOC name as
   no one is going to use generic binding names.
 - Update halt_check to not check for pipe clock status that
   allows to simplify pipe_clk handling in QMP driver.

Changes since v2:
 - Use separate phy_ops for USB to not register power_on op.
 - And other minor changes as per review comments from Stephen.

Changes since v1:
 - Updated qusb2 compatibility name as per comment from Vivek.

Manu Gautam (7):
  clk: msm8996-gcc: Mark halt check as no-op for USB/PCIE pipe_clk
  phy: qcom-qmp: Enable pipe_clk before PHY initialization
  phy: qcom-qusb2: Fix crash if nvmem cell not specified
  dt-bindings: phy-qcom-qmp: Update bindings for sdm845
  phy: qcom-qmp: Add QMP V3 USB3 UNI PHY support for sdm845
  dt-bindings: phy-qcom-usb2: Add support to override tuning values
  phy: qcom-qusb2: Add QUSB2 PHYs support for sdm845

 .../devicetree/bindings/phy/qcom-qmp-phy.txt   |   3 +-
 .../devicetree/bindings/phy/qcom-qusb2-phy.txt |  23 ++-
 drivers/clk/qcom/gcc-msm8996.c |   4 +
 drivers/phy/qualcomm/phy-qcom-qmp.c| 169 +++--
 drivers/phy/qualcomm/phy-qcom-qmp.h|   5 +
 drivers/phy/qualcomm/phy-qcom-qusb2.c  | 130 +++-
 include/dt-bindings/phy/phy-qcom-qusb2.h   |  37 +
 7 files changed, 346 insertions(+), 25 deletions(-)
 create mode 100644 include/dt-bindings/phy/phy-qcom-qusb2.h

-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v5 0/7] phy: qcom: Updates for USB PHYs on SDM845

[Manu Gautam]

SDM845 has two USB instances each with QUSB2 and QMP PHYs.
One of the QMP PHY is USB-DP (DisplayPort) combo PHY where
as other one is single lane UNI-PHY (without DP support).
Changes are related to PHY configuration for electrical
parameters tuning to improve eye-diagram and some fixes.

First gcc-msm8996 driver patch is dependent on following
patch which is now applied by Stephen.
https://patchwork.kernel.org/patch/10375043/


Changes since v4:
 - Addressed Doug's review comments to have QUSB2 PHY tuning
   values in header file.
 - Updated msm8996-gcc patch to use BRANCH_HALT_SKIP flag
   added by patch - https://patchwork.kernel.org/patch/10375041/
   
Changes since v3:
 - As per Doug's review comments added device tree parameters
   to handle board level differences in PHY tuning values instead
   of adding separate device tree bindings.
 - Replace PHY version specific bindings names with SOC name as
   no one is going to use generic binding names.
 - Update halt_check to not check for pipe clock status that
   allows to simplify pipe_clk handling in QMP driver.

Changes since v2:
 - Use separate phy_ops for USB to not register power_on op.
 - And other minor changes as per review comments from Stephen.

Changes since v1:
 - Updated qusb2 compatibility name as per comment from Vivek.

Manu Gautam (7):
  clk: msm8996-gcc: Mark halt check as no-op for USB/PCIE pipe_clk
  phy: qcom-qmp: Enable pipe_clk before PHY initialization
  phy: qcom-qusb2: Fix crash if nvmem cell not specified
  dt-bindings: phy-qcom-qmp: Update bindings for sdm845
  phy: qcom-qmp: Add QMP V3 USB3 UNI PHY support for sdm845
  dt-bindings: phy-qcom-usb2: Add support to override tuning values
  phy: qcom-qusb2: Add QUSB2 PHYs support for sdm845

 .../devicetree/bindings/phy/qcom-qmp-phy.txt   |   3 +-
 .../devicetree/bindings/phy/qcom-qusb2-phy.txt |  23 ++-
 drivers/clk/qcom/gcc-msm8996.c |   4 +
 drivers/phy/qualcomm/phy-qcom-qmp.c| 169 +++--
 drivers/phy/qualcomm/phy-qcom-qmp.h|   5 +
 drivers/phy/qualcomm/phy-qcom-qusb2.c  | 130 +++-
 include/dt-bindings/phy/phy-qcom-qusb2.h   |  37 +
 7 files changed, 346 insertions(+), 25 deletions(-)
 create mode 100644 include/dt-bindings/phy/phy-qcom-qusb2.h

-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH net,stable] qmi_wwan: do not steal interfaces from class drivers

[Bjørn Mork]

The USB_DEVICE_INTERFACE_NUMBER matching macro assumes that
the { vendorid, productid, interfacenumber } set uniquely
identifies one specific function.  This has proven to fail
for some configurable devices. One example is the Quectel
EM06/EP06 where the same interface number can be either
QMI or MBIM, without the device ID changing either.

Fix by requiring the vendor-specific class for interface number
based matching.  Functions of other classes can and should use
class based matching instead.

Fixes: 03304bcb5ec4 ("net: qmi_wwan: use fixed interface number matching")
Signed-off-by: Bjørn Mork 
---
It's quite possible that the fix should be integrated in the
USB_DEVICE_INTERFACE_NUMBER macro instead.  But that has grown a few
other users since it was added, so changing it now seems risky. 
Another option is of course adding a new match macro with the
USB_CLASS_VENDOR_SPEC match integrated. Maybe best?

But I'm proposing this as-is for now, since this quickfix seems most
suitable for stable backporting.

 drivers/net/usb/qmi_wwan.c | 12 
 1 file changed, 12 insertions(+)

diff --git a/drivers/net/usb/qmi_wwan.c b/drivers/net/usb/qmi_wwan.c
index 51c68fc416fa..42565dd33aa6 100644
--- a/drivers/net/usb/qmi_wwan.c
+++ b/drivers/net/usb/qmi_wwan.c
@@ -1344,6 +1344,18 @@ static int qmi_wwan_probe(struct usb_interface *intf,
id->driver_info = (unsigned long)_wwan_info;
}
 
+   /* There are devices where the same interface number can be
+* configured as different functions. We should only bind to
+* vendor specific functions when matching on interface number
+*/
+   if (id->match_flags & USB_DEVICE_ID_MATCH_INT_NUMBER &&
+   desc->bInterfaceClass != USB_CLASS_VENDOR_SPEC) {
+   dev_dbg(>dev,
+   "Rejecting interface number match for class %02x\n",
+   desc->bInterfaceClass);
+   return -ENODEV;
+   }
+
/* Quectel EC20 quirk where we've QMI on interface 4 instead of 0 */
if (quectel_ec20_detected(intf) && desc->bInterfaceNumber == 0) {
dev_dbg(>dev, "Quectel EC20 quirk, skipping interface 
0\n");
-- 
2.11.0

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Since Linux 4.13 tlp or powertop usage cause "xHCI host controller not responding, assume dead" on Dell 5855

[Alan Stern]

On Wed, 2 May 2018, Mathias Nyman wrote:

> On 24.04.2018 16:50, Alan Stern wrote:
> > On Tue, 24 Apr 2018, Mathias Nyman wrote:
> > 
> > In this situation, the HCD_WAKEUP_PENDING(hcd) test in
> > hcd-pci.c:suspend_common() should prevent the controller from going
> > back into D3.  The WAKEUP_PENDING bit gets set in
> > usb_hcd_resume_root_hub() and it doesn't get cleared until
> > hcd_bus_resume() runs.
> >
> 
>  I think xhci never calls usb_hcd_resume_root_hub() in xhci_resume() in 
>  this
>  specific failing case
> 
>  xhci_resume() has a check:
>  /* Resume root hubs only when have pending events. */
>   status = readl(>op_regs->status);
> if (status & STS_EINT) {
>   usb_hcd_resume_root_hub(xhci->shared_hcd);
>   usb_hcd_resume_root_hub(hcd);
> }
> 
>  If the check fails, then WAKEUP_PENDING bit is not set, and runtime PM
>  can suspend host controller again. when xhci driver finally gets to 
>  handle the interrupt
>  the controller may be in D3 already
> 
>  This should only happen if xhci_resume() is called before xhci driver 
>  sees a pending interrupt,
>  could be possible as xhci has interrupt moderation enabled.
> >>>
> >>> Then maybe that test should be removed.  Calling
> >>> usb_hcd_resume_root_hub() for every wakeup shouldn't be too bad,
> >>> because there probably are not very many times when the controller gets
> >>> resumed without the root hub also being resumed.
> >>>
> >>
> >> The check was added to fix system suspend issue on a runtime suspended 
> >> host:
> >>
> >> commit d6236f6d1d885aa19d1cd7317346fe795227a3cc
> >>
> >>   xhci: Fix runtime suspended xhci from blocking system suspend.
> >>   
> >>   The system suspend flow as following:
> >>   1, Freeze all user processes and kenrel threads.
> >>   
> >>   2, Try to suspend all devices.
> >>   
> >>   2.1, If pci device is in RPM suspended state, then pci driver will 
> >> try
> >>   to resume it to RPM active state in the prepare stage.
> >>   
> >>   2.2, xhci_resume function calls usb_hcd_resume_root_hub to queue two
> >>   workqueue items to resume usb2 roothub devices.
> >>   
> >>   2.3, Call suspend callbacks of devices.
> >>   
> >>   2.3.1, All suspend callbacks of all hcd's children, including
> >>   roothub devices are called.
> >>   
> >>   2.3.2, Finally, hcd_pci_suspend callback is called.
> >>   
> >>   Due to workqueue threads were already frozen in step 1, the workqueue
> >>   items can't be scheduled, and the roothub devices can't be resumed in
> >>   this flow. The HCD_FLAG_WAKEUP_PENDING flag which is set in
> >>   usb_hcd_resume_root_hub won't be cleared. Finally,
> >>   hcd_pci_suspend will return -EBUSY, and system suspend fails.
> > 
> > Hmmm.  I don't recall seeing this problem occur with ehci-hcd.  But
> > then, I haven't tested it very much recently.
> > 
> > We could change to a different work queue, one that doesn't get
> > frozen.  But there's no guarantee that the work items would run before
> > your step 2.3.2.
> > 
> > Maybe we can avoid step 2.1.  I think there have been some recent
> > changes to the PM code in this area.  There may be a flag you can set
> > that will prevent the PCI core from resuming the host controller.
> > 
> > Or maybe we can change step 2.3.1, so that the root hub's suspend
> > callback will first do a resume if the WAKEUP_PENDING flag is set.
> > That might be the most reliable approach.
> > 
> 
> I'm not sure I understand the last suggestion, could you open up how it
> would work?

Here's what I had in mind.  See if you think this would work.

Consider choose_wakeup() in core/driver.c.  That subroutine gets called
by usb_suspend() when step 2.3.1 wants to suspend a USB device.  We
could patch it as follows:

--- usb-4.x.orig/drivers/usb/core/driver.c
+++ usb-4.x/drivers/usb/core/driver.c
@@ -1449,11 +1449,21 @@ static void choose_wakeup(struct usb_dev
 */
w = device_may_wakeup(>dev);
 
-   /* If the device is autosuspended with the wrong wakeup setting,
+   /*
+* If the device is autosuspended with the wrong wakeup setting,
 * autoresume now so the setting can be changed.
+*
+* Likewise, if the device is an autosuspended root hub and the
+* hcd needs to wake it up before the controller can be suspended,
+* resume it now to clear the WAKEUP_PENDING flag.
 */
-   if (udev->state == USB_STATE_SUSPENDED && w != udev->do_remote_wakeup)
-   pm_runtime_resume(>dev);
+   if (udev->state == USB_STATE_SUSPENDED) {
+   struct usb_hcd  *hcd = bus_to_hcd(udev->bus);
+
+   if (w != udev->do_remote_wakeup ||
+   (!udev->parent && HCD_WAKEUP_PENDING(hcd)))
+   

Re: [PATCH v2 2/2] usb: dwc2: fix isoc split in transfer with no data

[wlf]

Dear Doug,


在 2018年05月02日 13:02, Doug Anderson 写道:

Hi,

On Tue, May 1, 2018 at 8:04 PM, William Wu  wrote:

If isoc split in transfer with no data (the length of DATA0
packet is zero), we can't simply return immediately. Because
the DATA0 can be the first transaction or the second transaction
for the isoc split in transaction. If the DATA0 packet with no
data is in the first transaction, we can return immediately.
But if the DATA0 packet with no data is in the second transaction
of isoc split in transaction sequence, we need to increase the
qtd->isoc_frame_index and giveback urb to device driver if needed,
otherwise, the MDATA packet will be lost.

A typical test case is that connect the dwc2 controller with an
usb hs Hub (GL852G-12), and plug an usb fs audio device (Plantronics
headset) into the downstream port of Hub. Then use the usb mic
to record, we can find noise when playback.

In the case, the isoc split in transaction sequence like this:

- SSPLIT IN transaction
- CSPLIT IN transaction
   - MDATA packet (176 bytes)
- CSPLIT IN transaction
   - DATA0 packet (0 byte)

This patch use both the length of DATA0 and qtd->isoc_split_offset
to check if the DATA0 is in the second transaction.

Signed-off-by: William Wu 
---
Changes in v2:
- Modify the commit message

  drivers/usb/dwc2/hcd_intr.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/usb/dwc2/hcd_intr.c b/drivers/usb/dwc2/hcd_intr.c
index 5e2378f..479f628 100644
--- a/drivers/usb/dwc2/hcd_intr.c
+++ b/drivers/usb/dwc2/hcd_intr.c
@@ -930,7 +930,7 @@ static int dwc2_xfercomp_isoc_split_in(struct dwc2_hsotg 
*hsotg,
 frame_desc = >urb->iso_descs[qtd->isoc_frame_index];
 len = dwc2_get_actual_xfer_length(hsotg, chan, chnum, qtd,
   DWC2_HC_XFER_COMPLETE, NULL);
-   if (!len) {
+   if (!len && !qtd->isoc_split_offset) {
 qtd->complete_split = 0;
 qtd->isoc_split_offset = 0;
 return 0;

I don't think my USB-fu is strong enough to do a real review of this
patch, but one small nitpick is that you can remove
"qtd->isoc_split_offset = 0" in the if test now.  AKA:

if (!len && !qtd->isoc_split_offset) {
   qtd->complete_split = 0;
   return 0;
}

Yes, good idea! I will fix it in next patch. Thank you!


...since you only enter the "if" test now when isoc_split_offset is
already 0...  Hopefully John Youn will have some time to comment on
this patch with more real USB knowledge...


-Doug


Best regards,
 wulf





--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 1/2] usb: dwc2: alloc dma aligned buffer for isoc split in

[wlf]

Dear Doug,


在 2018年05月02日 12:33, Doug Anderson 写道:

Hi,

On Tue, May 1, 2018 at 8:04 PM, William Wu  wrote:

The commit 3bc04e28a030 ("usb: dwc2: host: Get aligned DMA in
a more supported way") rips out a lot of code to simply the
allocation of aligned DMA. However, it also introduces a new
issue when use isoc split in transfer.

In my test case, I connect the dwc2 controller with an usb hs
Hub (GL852G-12), and plug an usb fs audio device (Plantronics
headset) into the downstream port of Hub. Then use the usb mic
to record, we can find noise when playback.

It's because that the usb Hub uses an MDATA for the first
transaction and a DATA0 for the second transaction for the isoc
split in transaction. An typical isoc split in transaction sequence
like this:

- SSPLIT IN transaction
- CSPLIT IN transaction
   - MDATA packet
- CSPLIT IN transaction
   - DATA0 packet

The DMA address of MDATA (urb->dma) is always DWORD-aligned, but
the DMA address of DATA0 (urb->dma + qtd->isoc_split_offset) may
not be DWORD-aligned, it depends on the qtd->isoc_split_offset (the
length of MDATA). In my test case, the length of MDATA is usually
unaligned, this casue DATA0 packet transmission error.

This patch base on the old way of aligned DMA allocation in the
dwc2 driver to get aligned DMA for isoc split in.

Signed-off-by: William Wu 
---
Changes in v2:
- None

  drivers/usb/dwc2/hcd.c   | 63 +---
  drivers/usb/dwc2/hcd.h   | 10 +++
  drivers/usb/dwc2/hcd_intr.c  |  8 ++
  drivers/usb/dwc2/hcd_queue.c |  8 +-
  4 files changed, 85 insertions(+), 4 deletions(-)

A word of warning that I'm pretty rusty on dwc2 and even when I was
making lots of patches I still considered myself a bit clueless.
...so if something seems wrong, please call me on it...

Most of your suggestions are great, thanks very much！



diff --git a/drivers/usb/dwc2/hcd.c b/drivers/usb/dwc2/hcd.c
index 190f959..8c2b35f 100644
--- a/drivers/usb/dwc2/hcd.c
+++ b/drivers/usb/dwc2/hcd.c
@@ -1562,11 +1562,20 @@ static void dwc2_hc_start_transfer(struct dwc2_hsotg 
*hsotg,
 }

 if (hsotg->params.host_dma) {
-   dwc2_writel((u32)chan->xfer_dma,
-   hsotg->regs + HCDMA(chan->hc_num));
+   dma_addr_t dma_addr;
+
+   if (chan->align_buf) {
+   if (dbg_hc(chan))
+   dev_vdbg(hsotg->dev, "align_buf\n");
+   dma_addr = chan->align_buf;
+   } else {
+   dma_addr = chan->xfer_dma;
+   }
+   dwc2_writel((u32)dma_addr, hsotg->regs + HCDMA(chan->hc_num));
+
 if (dbg_hc(chan))
 dev_vdbg(hsotg->dev, "Wrote %08lx to HCDMA(%d)\n",
-(unsigned long)chan->xfer_dma, chan->hc_num);
+(unsigned long)dma_addr, chan->hc_num);
 }

 /* Start the split */
@@ -2620,6 +2629,33 @@ static void dwc2_hc_init_xfer(struct dwc2_hsotg *hsotg,
 }
  }

+static int dwc2_alloc_split_dma_aligned_buf(struct dwc2_hsotg *hsotg,
+   struct dwc2_qh *qh,
+   struct dwc2_host_chan *chan)
+{
+   if (!qh->dw_align_buf) {
+   qh->dw_align_buf = kmalloc(chan->max_packet,

So you're potentially doing a bounce buffer atop a bounce buffer now,
right?  That seems pretty non-optimal.  You're also back to doing a
kmalloc at interrupt time which I found was pretty bad for
performance.
Yes, I just allocate an additional bounce buffer here. I haven't thought 
consummately
about this patch, it's really not a good way to use a kmalloc at 
interrut time.

Is there really no way you can do your memory allocation in
dwc2_alloc_dma_aligned_buffer() instead of here?  For input packets,
if you could just allocate an extra 3 bytes in the original bounce
buffer you could just re-use the original bounce buffer together with
a memmove?  AKA:

transfersize = 13 + 64;
buf = alloc(16 + 64);

// Do the first transfer, no problems.
dma_into(buf, 13);

// 2nd transfer isn't aligned, so align.
// we allocated a little extra to account for this
dma_into(buf + 16, 64);

// move back where it belongs.
memmove(buf + 13, buf + 16, 64);


To make the above work you'd need to still allocate a bounce buffer
even if the original "urb->transfer_buffer" was already aligned.
Ideally you'd be able to know when dwc2_alloc_dma_aligned_buffer()
that this is one of the special cases where you need a slightly
oversized bounce buffer.
It's a good way to allocate an extra 3 bytes in the original bounce 
buffer for this unaligned
issue， it's similar to the tailroom of sk_buff. However, just as you 
said, we'd better find
the special cases where we need an oversized bounce buffer, otherwise，we 
need to allocate

a bounce buffer for all 

Re: [RFC 07/10] pinctrl: samsung: Remove support for Exynos5440

[Krzysztof Kozlowski]

On Tue, Apr 24, 2018 at 10:32:36PM +0200, Krzysztof Kozlowski wrote:
> The Exynos5440 is not actively developed, there are no development
> boards available and probably there are no real products with it.
> Remove wide-tree support for Exynos5440.
> 
> Signed-off-by: Krzysztof Kozlowski 
> ---
>  drivers/pinctrl/samsung/Kconfig  |   10 +-
>  drivers/pinctrl/samsung/Makefile |1 -
>  drivers/pinctrl/samsung/pinctrl-exynos5440.c | 1005 
> --
>  3 files changed, 2 insertions(+), 1014 deletions(-)
>  delete mode 100644 drivers/pinctrl/samsung/pinctrl-exynos5440.c
> 

Applied.

Best regards,
Krzysztof

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC 01/10] ARM: dts: exynos: Remove Exynos5440

[Krzysztof Kozlowski]

On Tue, Apr 24, 2018 at 10:32:30PM +0200, Krzysztof Kozlowski wrote:
> The Exynos5440 (quad-core A15 with GMAC, PCIe, SATA) was targeting
> server platforms but it did not make it to the market really.  There are
> no development boards with it and probably there are no real products
> neither.  The development for Exynos5440 ended in 2013 and since then
> the platform is in maintenance mode.
> 
> Remove all Device Tree sources for Exynos5440, as first step of removal
> of the platform to simplify the code and drivers.
> 
> Signed-off-by: Krzysztof Kozlowski 
> ---
>  .../bindings/arm/samsung/samsung-boards.txt|   2 -
>  arch/arm/boot/dts/Makefile |   2 -
>  arch/arm/boot/dts/exynos5440-sd5v1.dts |  42 ---
>  arch/arm/boot/dts/exynos5440-ssdk5440.dts  |  81 -
>  arch/arm/boot/dts/exynos5440-tmu-sensor-conf.dtsi  |  20 --
>  arch/arm/boot/dts/exynos5440-trip-points.dtsi  |  21 --
>  arch/arm/boot/dts/exynos5440.dtsi  | 355 
> -
>  7 files changed, 523 deletions(-)
>  delete mode 100644 arch/arm/boot/dts/exynos5440-sd5v1.dts
>  delete mode 100644 arch/arm/boot/dts/exynos5440-ssdk5440.dts
>  delete mode 100644 arch/arm/boot/dts/exynos5440-tmu-sensor-conf.dtsi
>  delete mode 100644 arch/arm/boot/dts/exynos5440-trip-points.dtsi
>  delete mode 100644 arch/arm/boot/dts/exynos5440.dtsi
> 

Applied.

Best regards,
Krzysztof

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC 10/10] ARM: exynos: Remove support for Exynos5440

[Krzysztof Kozlowski]

On Tue, Apr 24, 2018 at 10:32:39PM +0200, Krzysztof Kozlowski wrote:
> The Exynos5440 is not actively developed, there are no development
> boards available and probably there are no real products with it.
> Remove wide-tree support for Exynos5440.
> 
> Signed-off-by: Krzysztof Kozlowski 
> ---
>  arch/arm/mach-exynos/Kconfig  | 12 
>  arch/arm/mach-exynos/common.h |  8 
>  arch/arm/mach-exynos/exynos.c | 15 ++-
>  3 files changed, 2 insertions(+), 33 deletions(-)
> 

Applied.

Best regards,
Krzysztof

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: dwc2: enumeration issue with audio dongle connected to USB hub

[Stefan Wahren]

Hi Minas,

> Minas Harutyunyan  hat am 2. Mai 2018 um 
> 10:54 geschrieben:
> 
> 
> Hi,
> 
> On 4/27/2018 10:03 AM, Stefan Wahren wrote:
> > Hi,
> > during my tests with a Raspberry Pi 2 B with an C-Media audio dongle 
> > connected to a powered USB hub, i noticed the enumeration errors below (the 
> > device gets finally ernumerated). I tested yesterdays linux-next, 4.17-rc2 
> > and 4.14 but all of them show this behavior, if i plugin the audio dongle 
> > into the USB hub.
> > 
> > /:  Bus 01.Port 1: Dev 1, Class=root_hub, Driver=dwc2/1p, 480M
> >  |__ Port 1: Dev 2, If 0, Class=Hub, Driver=hub/5p, 480M
> >  |__ Port 1: Dev 3, If 0, Class=Vendor Specific Class, 
> > Driver=smsc95xx, 480M
> >  |__ Port 2: Dev 4, If 0, Class=Hub, Driver=hub/4p, 480M
> >  |__ Port 3: Dev 8, If 2, Class=Audio, Driver=snd-usb-audio, 12M
> >  |__ Port 3: Dev 8, If 0, Class=Audio, Driver=snd-usb-audio, 12M
> >  |__ Port 3: Dev 8, If 3, Class=Human Interface Device, 
> > Driver=usbhid, 12M
> >  |__ Port 3: Dev 8, If 1, Class=Audio, Driver=snd-usb-audio, 12M
> >  |__ Port 1: Dev 5, If 0, Class=Hub, Driver=hub/4p, 480M
> >  |__ Port 4: Dev 7, If 1, Class=Human Interface Device, 
> > Driver=usbhid, 1.5M
> >  |__ Port 4: Dev 7, If 0, Class=Human Interface Device, 
> > Driver=usbhid, 1.5M
> > 
> > The verbose version can be found here:
> > https://urldefense.proofpoint.com/v2/url?u=https-3A__gist.github.com_lategoodbye_baa0f8890325f8698664aeb60ecedfd5=DwICaQ=DPL6_X_6JkXFx7AXWqB0tg=cQBKt4q-qzNVC53rNAwuwplH23V61rHQhhULvdLA0U8=oor4Ij_LNZepp0TZuefnbqFJacQjGXIOEk_BRVa4Vf8=qbdE3PnqX9pigSEbMTqXPeSItGUGJTIOVUapC-fZXdg=
> > 
> > Here is an example dmesg after plugin the audio dongle:
> > [ 1176.382877] usb 1-1.2.1.3: new full-speed USB device number 14 using dwc2
> > [ 1176.516254] dwc2 2098.usb: dwc2_hc_chhltd_intr_dma: Channel 1 - 
> > ChHltd set, but reason is unknown
> > [ 1176.516284] dwc2 2098.usb: hcint 0x0402, intsts 0x0429
> > [ 1176.516355] dwc2 2098.usb: dwc2_hc_chhltd_intr_dma: Channel 4 - 
> > ChHltd set, but reason is unknown
> > [ 1176.516372] dwc2 2098.usb: hcint 0x0402, intsts 0x0429
> > [ 1176.516427] dwc2 2098.usb: dwc2_hc_chhltd_intr_dma: Channel 6 - 
> > ChHltd set, but reason is unknown
> > [ 1176.516442] dwc2 2098.usb: hcint 0x0402, intsts 0x0421
> > [ 1176.518435] dwc2 2098.usb: dwc2_hc_chhltd_intr_dma: Channel 5 - 
> > ChHltd set, but reason is unknown
> > [ 1176.518464] dwc2 2098.usb: hcint 0x0402, intsts 0x0421
> > [ 1176.518532] dwc2 2098.usb: dwc2_hc_chhltd_intr_dma: Channel 3 - 
> > ChHltd set, but reason is unknown
> > [ 1176.518549] dwc2 2098.usb: hcint 0x0402, intsts 0x0421
> > [ 1176.518605] dwc2 2098.usb: dwc2_hc_chhltd_intr_dma: Channel 1 - 
> > ChHltd set, but reason is unknown
> > [ 1176.518623] dwc2 2098.usb: hcint 0x0402, intsts 0x0429
> > [ 1176.520704] dwc2 2098.usb: dwc2_hc_chhltd_intr_dma: Channel 3 - 
> > ChHltd set, but reason is unknown
> > [ 1176.520734] dwc2 2098.usb: hcint 0x0402, intsts 0x0421
> > [ 1176.520802] dwc2 2098.usb: dwc2_hc_chhltd_intr_dma: Channel 1 - 
> > ChHltd set, but reason is unknown
> > [ 1176.520820] dwc2 2098.usb: hcint 0x0402, intsts 0x0421
> > [ 1176.520887] dwc2 2098.usb: dwc2_hc_chhltd_intr_dma: Channel 6 - 
> > ChHltd set, but reason is unknown
> > [ 1176.520905] dwc2 2098.usb: hcint 0x0402, intsts 0x0421
> > [ 1176.521127] usb 1-1.2.1.3: unable to read config index 0 descriptor/all
> > [ 1176.521197] usb 1-1.2.1.3: can't read configurations, error -71
> > [ 1176.632956] usb 1-1.2.1.3: new full-speed USB device number 15 using dwc2
> > [ 1176.763789] dwc2 2098.usb: dwc2_hc_chhltd_intr_dma: Channel 6 - 
> > ChHltd set, but reason is unknown
> > [ 1176.763820] dwc2 2098.usb: hcint 0x0402, intsts 0x0421
> > [ 1176.763890] dwc2 2098.usb: dwc2_hc_chhltd_intr_dma: Channel 5 - 
> > ChHltd set, but reason is unknown
> > [ 1176.763909] dwc2 2098.usb: hcint 0x0402, intsts 0x0421
> > [ 1176.763998] dwc2 2098.usb: dwc2_hc_chhltd_intr_dma: Channel 2 - 
> > ChHltd set, but reason is unknown
> > [ 1176.764016] dwc2 2098.usb: hcint 0x0402, intsts 0x0429
> > [ 1177.012371] input: C-Media Electronics Inc.   USB PnP Sound Device 
> > as 
> > /devices/platform/soc/2098.usb/usb1/1-1/1-1.2/1-1.2.1/1-1.2.1.3/1-1.2.1.3:1.3/0003:0D8C:013C.0008/input/input7
> > [ 1177.088948] hid-generic 0003:0D8C:013C.0008: input: USB HID v1.00 Device 
> > [C-Media Electronics Inc.   USB PnP Sound Device] on 
> > usb-2098.usb-1.2.1.3/input3
> > 
> > Best regards
> > 
> 
> Could you please apply follow patches from linux-usb mailing list:
> 1. usb: dwc2: hcd: Fix host channel halt flow

this patch has already been applied to linux-next (which i tested), so it 
doesn't 

Re: USB regression for Android phone and sound card in 4.14

[Nazar Mokrynskyi]

Some more details from my system:

[    0.725657] ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver
[    0.725670] ehci-pci: EHCI PCI platform driver
[    0.726004] ehci-platform: EHCI generic platform driver
[    0.726340] ohci_hcd: USB 1.1 'Open' Host Controller (OHCI) Driver
[    0.726684] ohci-pci: OHCI PCI platform driver
[    0.727022] ohci-platform: OHCI generic platform driver
[    0.727356] uhci_hcd: USB Universal Host Controller Interface driver
[    0.727762] xhci_hcd :00:14.0: xHCI Host Controller
[    0.728122] xhci_hcd :00:14.0: new USB bus registered, assigned bus 
number 1
[    0.729533] xhci_hcd :00:14.0: hcc params 0x200077c1 hci version 0x100 
quirks 0x9810
[    0.729873] xhci_hcd :00:14.0: cache line size of 64 is not supported
[    0.730972] usb usb1: Manufacturer: Linux 4.15.0-20-generic xhci-hcd
[    0.733250] xhci_hcd :00:14.0: xHCI Host Controller
[    0.733580] xhci_hcd :00:14.0: new USB bus registered, assigned bus 
number 2
[    0.734947] usb usb2: Manufacturer: Linux 4.15.0-20-generic xhci-hcd
[    0.737314] xhci_hcd :03:00.0: xHCI Host Controller
[    0.737650] xhci_hcd :03:00.0: new USB bus registered, assigned bus 
number 3
[    0.792826] xhci_hcd :03:00.0: hcc params 0x0200ef81 hci version 0x110 
quirks 0x0010
[    0.794272] usb usb3: Manufacturer: Linux 4.15.0-20-generic xhci-hcd
[    0.795715] xhci_hcd :03:00.0: xHCI Host Controller
[    0.796035] xhci_hcd :03:00.0: new USB bus registered, assigned bus 
number 4
[    0.796331] xhci_hcd :03:00.0: Host supports USB 3.1 Enhanced SuperSpeed
[    0.797849] usb usb4: Manufacturer: Linux 4.15.0-20-generic xhci-hcd
[    0.917461] ahci :00:17.0: version 3.0
[    0.917754] ahci :00:17.0: AHCI 0001.0301 32 slots 6 ports 6 Gbps 0x3f 
impl SATA mode
[    0.918095] ahci :00:17.0: flags: 64bit ncq sntf led clo only pio slum 
part ems deso sadm sds apst
[    0.988425] scsi host0: ahci
[    0.988932] scsi host1: ahci
[    0.989430] scsi host2: ahci
[    0.989891] scsi host3: ahci
[    0.990335] scsi host4: ahci
[    0.990777] scsi host5: ahci
[    1.072061] usb 1-9: new high-speed USB device number 2 using xhci_hcd
[    1.356096] usb 1-10: new high-speed USB device number 3 using xhci_hcd
[    1.584007] usb 1-9.1: new full-speed USB device number 4 using xhci_hcd
[    1.812022] usb 1-12: new high-speed USB device number 5 using xhci_hcd
[    2.040005] usb 1-9.2: new full-speed USB device number 6 using xhci_hcd
[    7.532036] usb 1-9.3: new full-speed USB device number 7 using xhci_hcd
[  351.369187] usb 1-9: new high-speed USB device number 8 using xhci_hcd
[  351.805248] usb 1-9.1: new full-speed USB device number 9 using xhci_hcd
[  352.053264] usb 1-9.2: new high-speed USB device number 10 using xhci_hcd
[  357.417231] usb 1-9.3: new full-speed USB device number 11 using xhci_hcd

usb 1-9 is a 4-port USB hub to which USB mouse, keyboard and sound card are 
connected.

USB hub correctly initializes at high-speed from the start, but sound card (usb 
1-9.2) for some reason only initializes at full-speed, which causes my issues.

However, when I unplug USB hub on fully booted system and plug it back, sound 
card initializes at high-speed.

More debugging revealed that sound card connected directly to USB port on 
motherboard initializes properly.

So my current understanding is that there is some kind of an issue with USB hub 
handling during system boot.

Sincerely, Nazar Mokrynskyi
github.com/nazar-pc

24.04.18 12:16, Nazar Mokrynskyi пише:
> My expectation is that kernel will figure out what to load first on its own.
>
> What HCD stands for in your message? USB hub is connected to native USB 2.0 
> port on motherboard with Z370 chipset.
>
> Sincerely, Nazar Mokrynskyi
> github.com/nazar-pc
>
> 24.04.18 11:04, Oliver Neukum пише:
>> Am Dienstag, den 24.04.2018, 07:35 +0300 schrieb Nazar Mokrynskyi:
>>> I've tried to bisect kernels from 4.13 to 4.14 and didn't find the reason. 
>>> Then I found that with upstream 4.13 the issue is still present on Ubuntu 
>>> 18.04, so there should be something more than just a kernel.
>>>
>>> Eventually, I found that issue is somehow related to USB hub I use for my 
>>> periferals (mouse, keyboard and sound card).
>>>
>>> When sound card is connected separately, it is properly initialized as USB 
>>> 2.0 device: https://pastebin.com/0rv1aUBz
>>>
>>> However, when connected to USB hub, it initializes as USB 1.1 device, in 
>>> which case it disables some of its capabilities, like 5.1 output mode: 
>>> https://pastebin.com/i4qE9JTZ
>>>
>>> Can't blame USB hub for this, since when I unplug it with mentioned 3 
>>> devices and plug back - everything works fine, the issue only happens on 
>>> system boot.
>>>
>>> USB hub I use at the moment (used another before with the same outcome): 
>>> https://pastebin.com/wkA6D9TP
>> You need to make sure ehci/hcd is loaded before ohci or uhci, if indeed
>> you have a setup with true companion 

Re: [PATCH] usb-storage: stop using block layer bounce buffers

[Alan Stern]

On Wed, 2 May 2018, Christoph Hellwig wrote:

> On Fri, Apr 27, 2018 at 10:09:17AM -0400, Alan Stern wrote:
> > On Fri, 27 Apr 2018, Christoph Hellwig wrote:
> > 
> > > On Sun, Apr 15, 2018 at 11:24:11AM -0400, Alan Stern wrote:
> > > > On Sun, 15 Apr 2018, Christoph Hellwig wrote:
> > > > 
> > > > > USB host controllers now must handle highmem, so we can get rid of 
> > > > > bounce
> > > > > buffering highmem pages in the block layer.
> > > > 
> > > > Sorry, I don't quite understand what you are saying.  Do you mean that
> > > > all USB host controllers now magically _do_ handle highmem?  Or do you
> > > > mean that if they _don't_ handle highmem, we will not support them any
> > > > more?
> > > 
> > > USB controller themselves never cared about highmem, drivers did.  For
> > > PIO based controllers they'd have to kmap any address no in the kernel
> > > drirect mapping.
> > > 
> > > Nothing in drivers/usb/host or the other diretories related to host
> > > drivers calls page_address (only used in a single gadget) or sg_virt
> > > (only used in a few upper level drivers), which makes me assume
> > > semi-confidently that no USB host driver is not highmem aware these
> > > days.
> > 
> > sg_virt is called in drivers/usb/core/message.c.  (Maybe that's what
> > you meant by "upper level drivers".)  I'm not sure just how important
> > that usage is.
> 
> I don't really know either.  I'll need some guidance from the usb
> maintainers on:
> 
>  - when drivers can submit urbs with a scatterlist
>  - if there are any drivers that do not want to take highmem
> 
> Unfortunately the way dma mapping works in usb is just so deeply
> convoluted that I have a hard time following it, and often wonder
> what is intentional and what is accidental in it.

I can help explain some of this.

Drivers are allowed to submit bulk URBs with scatterlists.  
Isochronous definitely does not support scatterlists.  I suppose
control/interrupt might or might not support it (depending on how the
host controller driver is written), but (1) support is not guaranteed 
so drivers can't rely on it, and (2) nobody ever needs to use 
scatter-gather I/O for control or interrupt transfers anyway.

In practice, mass storage (usb_storage, uas, and f_tcm) is the only
important USB application that I know uses scatterlists.  The usbtest
driver includes scatter-gather support, but it is purely for testing
and verification purposes.  Also, the usbfs driver (core/devio.c) can
use SG, but in this case the scatterlist is constructed by the driver
itself rather than received from someone else.

Scatter-gather I/O is handled at two different levels in the USB
subsystem.  Some of the host controller drivers have native SG support;  
for them it isn't a problem, so we only have to worry about the other
ones.  Most of those use normal DMA transfers, so high memory issues
should be handled by the block layer and DMA core.  However, a few of
the drivers rely on PIO or special memory that is local to the
controller hardware.  You can see all the different possibilities if
you read through core/hcd.c: map_urb_for_dma() and
usb_hcd_map_urb_for_dma().  I don't remember which drivers are special,
but you can search the driver source code for dma_mask and
HCD_LOCAL_MEM.

At a higher level, there are some library routines in core/message.c
that provide a poor-man's form of SG for cases where the host
controller driver doesn't have native support; see usb_sg_init() and
the surrounding routines.  (The library predates the native SG support
by many years.)  This is really the only interesting case; the code
creates an individual URB for each entry in the scatterlist and submits
them all.  The question is whether the host controller driver will be 
able to access the data given by the scatterlist entries.

Do you have any particular questions about accidental vs. intentional 
aspects of the DMA support?

Alan Stern

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Since Linux 4.13 tlp or powertop usage cause "xHCI host controller not responding, assume dead" on Dell 5855

[Mathias Nyman]

On 24.04.2018 16:50, Alan Stern wrote:

On Tue, 24 Apr 2018, Mathias Nyman wrote:


In this situation, the HCD_WAKEUP_PENDING(hcd) test in
hcd-pci.c:suspend_common() should prevent the controller from going
back into D3.  The WAKEUP_PENDING bit gets set in
usb_hcd_resume_root_hub() and it doesn't get cleared until
hcd_bus_resume() runs.



I think xhci never calls usb_hcd_resume_root_hub() in xhci_resume() in this
specific failing case

xhci_resume() has a check:
/* Resume root hubs only when have pending events. */
 status = readl(>op_regs->status);
   if (status & STS_EINT) {
 usb_hcd_resume_root_hub(xhci->shared_hcd);
 usb_hcd_resume_root_hub(hcd);
   }

If the check fails, then WAKEUP_PENDING bit is not set, and runtime PM
can suspend host controller again. when xhci driver finally gets to handle the 
interrupt
the controller may be in D3 already

This should only happen if xhci_resume() is called before xhci driver sees a 
pending interrupt,
could be possible as xhci has interrupt moderation enabled.


Then maybe that test should be removed.  Calling
usb_hcd_resume_root_hub() for every wakeup shouldn't be too bad,
because there probably are not very many times when the controller gets
resumed without the root hub also being resumed.



The check was added to fix system suspend issue on a runtime suspended host:

commit d6236f6d1d885aa19d1cd7317346fe795227a3cc

  xhci: Fix runtime suspended xhci from blocking system suspend.
  
  The system suspend flow as following:

  1, Freeze all user processes and kenrel threads.
  
  2, Try to suspend all devices.
  
  2.1, If pci device is in RPM suspended state, then pci driver will try

  to resume it to RPM active state in the prepare stage.
  
  2.2, xhci_resume function calls usb_hcd_resume_root_hub to queue two

  workqueue items to resume usb2 roothub devices.
  
  2.3, Call suspend callbacks of devices.
  
  2.3.1, All suspend callbacks of all hcd's children, including

  roothub devices are called.
  
  2.3.2, Finally, hcd_pci_suspend callback is called.
  
  Due to workqueue threads were already frozen in step 1, the workqueue

  items can't be scheduled, and the roothub devices can't be resumed in
  this flow. The HCD_FLAG_WAKEUP_PENDING flag which is set in
  usb_hcd_resume_root_hub won't be cleared. Finally,
  hcd_pci_suspend will return -EBUSY, and system suspend fails.


Hmmm.  I don't recall seeing this problem occur with ehci-hcd.  But
then, I haven't tested it very much recently.

We could change to a different work queue, one that doesn't get
frozen.  But there's no guarantee that the work items would run before
your step 2.3.2.

Maybe we can avoid step 2.1.  I think there have been some recent
changes to the PM code in this area.  There may be a flag you can set
that will prevent the PCI core from resuming the host controller.

Or maybe we can change step 2.3.1, so that the root hub's suspend
callback will first do a resume if the WAKEUP_PENDING flag is set.
That might be the most reliable approach.



I'm not sure I understand the last suggestion, could you open up how it
would work?

I started approaching this from another direction, mainly making sure we don't
immediately runtime suspend the host controller after resume. Adding a 
next_statechange
minimal time between resume and suspend, and checking for pending events in 
xhci_suspend().

I'll have some patches to test for russianneuroman...@ya.ru soon

These are generic checks that ehci_suspend() also does

-Mathias
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: [PATCH v2 1/2] usb: dwc3: gadget: Correct handling of scattergather lists

[Anurag Kumar Vulisha]

Hi All,

Please let me know if the changes in this patch are okay . If the changes looks 
fine , can we proceed with this patch. 
 
Thanks,
Anurag Kumar Vulisha

>-Original Message-
>From: v.anuragku...@gmail.com [mailto:v.anuragku...@gmail.com]
>Sent: Tuesday, March 27, 2018 4:35 PM
>To: Felipe Balbi ; Greg Kroah-Hartman
>
>Cc: linux-usb@vger.kernel.org; linux-ker...@vger.kernel.org; Ajay Yugalkishore
>Pandey ; v.anuragku...@gmail.com; Anurag Kumar Vulisha
>
>Subject: [PATCH v2 1/2] usb: dwc3: gadget: Correct handling of scattergather 
>lists
>
>From: Anurag Kumar Vulisha 
>
>The code logic in dwc3_prepare_one_trb() incorrectly uses the address and 
>length
>fields present in req packet for mapping TRB's instead of using the address 
>and length
>fields of scattergather lists. This patch correct's the code to use 
>sg->address and sg-
>>length when scattergather lists are present.
>
>Signed-off-by: Anurag Kumar Vulisha 
>---
> Changes in v2:
>  1. Split the single patch into 2 patches as suggested by Felipe Balbi
>  2. Renamed sg_to_start variable to start_sg
>---
> drivers/usb/dwc3/core.h   |  2 ++
> drivers/usb/dwc3/gadget.c | 25 ++---
> 2 files changed, 24 insertions(+), 3 deletions(-)
>
>diff --git a/drivers/usb/dwc3/core.h b/drivers/usb/dwc3/core.h index
>860d2bc..1406c4f 100644
>--- a/drivers/usb/dwc3/core.h
>+++ b/drivers/usb/dwc3/core.h
>@@ -718,6 +718,7 @@ struct dwc3_hwparams {
>  * @list: a list_head used for request queueing
>  * @dep: struct dwc3_ep owning this request
>  * @sg: pointer to first incomplete sg
>+ * @start_sg: pointer to the sg which should be queued next
>  * @num_pending_sgs: counter to pending sgs
>  * @remaining: amount of data remaining
>  * @epnum: endpoint number to which this request refers @@ -734,6 +735,7 @@
>struct dwc3_request {
>   struct list_headlist;
>   struct dwc3_ep  *dep;
>   struct scatterlist  *sg;
>+  struct scatterlist  *start_sg;
>
>   unsignednum_pending_sgs;
>   unsignedremaining;
>diff --git a/drivers/usb/dwc3/gadget.c b/drivers/usb/dwc3/gadget.c index
>2bda4eb..330a4de 100644
>--- a/drivers/usb/dwc3/gadget.c
>+++ b/drivers/usb/dwc3/gadget.c
>@@ -978,11 +978,19 @@ static void dwc3_prepare_one_trb(struct dwc3_ep *dep,
>   struct dwc3_request *req, unsigned chain, unsigned node)  {
>   struct dwc3_trb *trb;
>-  unsignedlength = req->request.length;
>+  unsigned intlength;
>+  dma_addr_t  dma;
>   unsignedstream_id = req->request.stream_id;
>   unsignedshort_not_ok = req->request.short_not_ok;
>   unsignedno_interrupt = req->request.no_interrupt;
>-  dma_addr_t  dma = req->request.dma;
>+
>+  if (req->request.num_sgs > 0) {
>+  length = sg_dma_len(req->start_sg);
>+  dma = sg_dma_address(req->start_sg);
>+  } else {
>+  length = req->request.length;
>+  dma = req->request.dma;
>+  }
>
>   trb = >trb_pool[dep->trb_enqueue];
>
>@@ -1048,7 +1056,7 @@ static u32 dwc3_calc_trbs_left(struct dwc3_ep *dep)
>static void dwc3_prepare_one_trb_sg(struct dwc3_ep *dep,
>   struct dwc3_request *req)
> {
>-  struct scatterlist *sg = req->sg;
>+  struct scatterlist *sg = req->start_sg;
>   struct scatterlist *s;
>   int i;
>
>@@ -1081,6 +1089,16 @@ static void dwc3_prepare_one_trb_sg(struct dwc3_ep
>*dep,
>   dwc3_prepare_one_trb(dep, req, chain, i);
>   }
>
>+  /*
>+   * There can be a situation where all sgs in sglist are not
>+   * queued because of insufficient trb number. To handle this
>+   * case, update start_sg to next sg to be queued, so that
>+   * we have free trbs we can continue queuing from where we
>+   * previously stopped
>+   */
>+  if (chain)
>+  req->start_sg = sg_next(s);
>+
>   if (!dwc3_calc_trbs_left(dep))
>   break;
>   }
>@@ -1171,6 +1189,7 @@ static void dwc3_prepare_trbs(struct dwc3_ep *dep)
>   return;
>
>   req->sg = req->request.sg;
>+  req->start_sg   = req->sg;
>   req->num_pending_sgs= req->request.num_mapped_sgs;
>
>   if (req->num_pending_sgs > 0)
>--
>2.1.1

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 02/20] usb: host: xhci: check DYING state earlier

[Alan Stern]

On Wed, 2 May 2018, Felipe Balbi wrote:

> >> Look at the result. With this change we don't need to take a lock,
> >> allocate memory, search for endpoint index, search for endpoint
> >> state. All of those are needed for proper operation of the function, but
> >> if the controller has already died, there's no point in going any
> >> further.
> >
> > But we might miss the fact that host died, and go even further, adding URB 
> > to list,
> > writing TRBs to ringbuffers etc.
> >
> > In code we save one line,
> > goto: free_priv
> 
> We're saving a lot more than that, actually. All of the following ends
> up being skipped. All of these are unnecessary work when xHC has already
> died:
> 
> 8<
> 
> slot_id = urb->dev->slot_id;
> ep_index = xhci_get_endpoint_index(>ep->desc);
> ep_state = >devs[slot_id]->eps[ep_index].ep_state;
> 
> if (!HCD_HW_ACCESSIBLE(hcd)) {
> if (!in_interrupt())
> xhci_dbg(xhci, "urb submitted during PCI suspend\n");
> return -ESHUTDOWN;
> }
> 
> if (usb_endpoint_xfer_isoc(>ep->desc))
> num_tds = urb->number_of_packets;
> else if (usb_endpoint_is_bulk_out(>ep->desc) &&
> urb->transfer_buffer_length > 0 &&
> urb->transfer_flags & URB_ZERO_PACKET &&
> !(urb->transfer_buffer_length % usb_endpoint_maxp(>ep->desc)))
> num_tds = 2;
> else
> num_tds = 1;
> 
> urb_priv = kzalloc(sizeof(struct urb_priv) +
>num_tds * sizeof(struct xhci_td), mem_flags);
> if (!urb_priv)
> return -ENOMEM;
> 
> urb_priv->num_tds = num_tds;
> urb_priv->num_tds_done = 0;
> urb->hcpriv = urb_priv;
> 
> trace_xhci_urb_enqueue(urb);
> 
> if (usb_endpoint_xfer_control(>ep->desc)) {
> /* Check to see if the max packet size for the default control
>  * endpoint changed during FS device enumeration
>  */
> if (urb->dev->speed == USB_SPEED_FULL) {
> ret = xhci_check_maxpacket(xhci, slot_id,
> ep_index, urb);
> if (ret < 0) {
> xhci_urb_free_priv(urb_priv);
> urb->hcpriv = NULL;
> return ret;
> }
> }
> }
> 
> spin_lock_irqsave(>lock, flags);
> 
> 8<

Regardless, how often does it happen that an xHCI host controller dies?  
A few times a day for every xHCI controller in the world seems like a
gross overestimate.

But even if it isn't, who cares if we end up executing the code above a
few extra times per day?  It's the "almost never used" path.  :-)

Alan Stern

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] typec: tcpm: Fix incorrect 'and' operator

[Heikki Krogerus]

On Mon, Apr 30, 2018 at 08:23:06AM -0500, Gustavo A. R. Silva wrote:
> Currently, logical and is being used instead of *bitwise* and.
> 
> Fix this by using a proper bitwise and operator.
> 
> Addresses-Coverity-ID: 1468455 ("Logical vs. bitwise operator")
> Fixes: 64f7c494a3c0 ("typec: tcpm: Add support for sink PPS related
> messages")
> Signed-off-by: Gustavo A. R. Silva 

Acked-by: Heikki Krogerus 

> ---
>  drivers/usb/typec/tcpm.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/usb/typec/tcpm.c b/drivers/usb/typec/tcpm.c
> index 1ee259b..7ee417a 100644
> --- a/drivers/usb/typec/tcpm.c
> +++ b/drivers/usb/typec/tcpm.c
> @@ -1772,7 +1772,7 @@ static void tcpm_pd_ext_msg_request(struct tcpm_port 
> *port,
>   enum pd_ext_msg_type type = pd_header_type_le(msg->header);
>   unsigned int data_size = 
> pd_ext_header_data_size_le(msg->ext_msg.header);
>  
> - if (!(msg->ext_msg.header && PD_EXT_HDR_CHUNKED)) {
> + if (!(msg->ext_msg.header & PD_EXT_HDR_CHUNKED)) {
>   tcpm_log(port, "Unchunked extended messages unsupported");
>   return;
>   }

Thanks,

-- 
heikki
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC PATCH 1/7] usb: typec: Generalize mux mode names

[Mats Karrman]

Hi Heikki,

On 2018-05-02 10:25, Heikki Krogerus wrote:


On Wed, May 02, 2018 at 11:23:35AM +0300, Heikki Krogerus wrote:

Hi Mats,

On Wed, May 02, 2018 at 12:21:07AM +0200, Mats Karrman wrote:

The current naming used for tcpc_mux_mode constants makes
too much assumptioms about the usage of the signals.
This patch replaces the names with generic names more closely
tied to the Type-C specifications and also adds some new ones.
At the same time TCPC_MUX_* defines are removed as they do not
fit the new concept and currently have no in-tree users.

I'm afraid trying to generalize the modal connector states even like
this is not going to work. We can't make any assumptions about how the
alternate modes configure the pins, or the connector in general.

The only way this will work is that every alternate mode has its own
configurations defined separately, and I'm talking about the actual
pin configurations that the specifications for each alternate mode
defines, so something like TYPEC_MUX_DP and TYPEC_MUX_DOCK will not
work for sure.

The connector states that are defined in USB Type-C specification (so
basically USB Operation and USB Safe State) can be generalized, but
those states just should not be defined in tcpm.h. We need to use
them in other drivers as well.

I'm in the middle of preparing more complete support for alternate
modes. If you check the RFC [1] I send previously, in the first patch
of the series I'm adding documentation that should explain the
plan.

Sorry, I forgot the link:

[1] https://www.spinics.net/lists/linux-usb/msg166520.html


Oh, sorry I forgot about that post in the first place... I reread it now.

Since the modal TYPEC_STATE_ are overlapping for each AM, this means that
the mux driver "set" must know which AM is active, right?

And each mux driver also need to support all possible alt modes?

I was thinking that it must be a finite number of possible routes
between the local connections of a mux and the four available SS lanes of
the cable but of course there is no theoretical limit to the number of
local connections...

Do we want to set a limitation of one mux device per port? I guess we
could and then let people write "composite" mux drivers if it should ever
be necessary.

Still it's difficult to write a mux device driver that support everything,
but I'm thinking that it might be possible to write a "mode agnostic" mux
driver that uses properties to match the "AM:STATE" pairs the board needs
to support to the hardware mux device specific muxing modes available?

It would be very interesting to see a devicetree example on how you
picture things being connected to each other.

Btw. You're using "mode" and "state" interchangeably which is a bit
confusing. Could you settle for one?

BR // Mats


Cheers,


--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 02/20] usb: host: xhci: check DYING state earlier

[Mathias Nyman]

On 02.05.2018 14:46, Felipe Balbi wrote:


Hi,

Mathias Nyman  writes:

On 17.04.2018 10:07, Felipe Balbi wrote:


Hi,

Mathias Nyman  writes:

On 16.04.2018 15:29, Felipe Balbi wrote:

Instead of allocating urb priv and, maybe, bail out due to xhci being
in DYING state, we can move the check earlier and avoid the memory
allocation altogether.


This also moves checking for DYING outside the lock.

Most cases set DYING with lock held, so if we first get the lock before
checking DYING we have a better chance of not being in the process of dying.


pretty sure that's atomic, though.


That's not what I'm after, your fix is cleaning up code in the case where DYING 
flag is
set before xhci_urb_enqueue() is called. I'm worried about the case when 
setting DYING flag races
with xhci_urb_enqueue(). i.e. xhci_urb_enqueue() is spinning on the lock, 
waiting, while
some other part of the driver is desperately trying to access hw with lock 
held, failing,
finally setting DYING flag, and then releasing lock.

If the check is done before taking the lock then the URB might be queued on 
dying device,
at a time when xhci_hc_died already started cancelling and giving back all 
queued URB


this can only happen if checking that bit isn't an atomic operation
which, AFAICT, it is. IOW, it would be the same if you were to change:

if (a & b)
return -1;

to:

if (test_bit(b, ))
return -1;

right? Now, if this isn't an atomic operation, I'm happy to be educated.


Again, it's not about being atomic.
As an example lets take the get port status request racing with queueing a URB.
After this patch the following is possible:


CPU:0   CPU:1
get port status queue URB

xhci_hub_control()  xhci_queue_urb()
spin_lock(lock), got it XHCI_STATE_DYING? no, continue
temp = readl(port_array[wIndex])spin_lock(lock), already taken, spin 
here
if (temp == ~(u32)0) {
xhci_hc_died(xhci)  
xhc_state |= XHCI_STATE_DYING
cleanup_command_queue()
kill_endpoint_urbs()
spin_unlock(lock) // at URB givebackspin_lock(lock) got it, finally
allocate urb_priv, plus other stuff
xhci_queue_*_tx()   
count_trbs_needed(urb)
prepare_transfer()
queue_trb() // for each trb

So its more likely we end up queuing URBs on a dead host, a host that the 
driver already
started tearing down, freeing URBs. xhci_hub_control() was just one example,
you can replace it with almost any function that calls xhci_hc_died()




Small thing, but so is this cleanup, so not sure its worth the change


Look at the result. With this change we don't need to take a lock,
allocate memory, search for endpoint index, search for endpoint
state. All of those are needed for proper operation of the function, but
if the controller has already died, there's no point in going any
further.


But we might miss the fact that host died, and go even further, adding URB to 
list,
writing TRBs to ringbuffers etc.

In code we save one line,
goto: free_priv


We're saving a lot more than that, actually. All of the following ends
up being skipped. All of these are unnecessary work when xHC has already
died:


In lines of code in the driver it's just one line.

In extra code being run it's a gamble.
Before the patch we ran the below code, after the patch it's either nothing, or 
the below
code plus all the URB/TRB queuing code.



8<

slot_id = urb->dev->slot_id;
ep_index = xhci_get_endpoint_index(>ep->desc);
ep_state = >devs[slot_id]->eps[ep_index].ep_state;

if (!HCD_HW_ACCESSIBLE(hcd)) {
 if (!in_interrupt())
 xhci_dbg(xhci, "urb submitted during PCI suspend\n");
 return -ESHUTDOWN;
}

if (usb_endpoint_xfer_isoc(>ep->desc))
 num_tds = urb->number_of_packets;
else if (usb_endpoint_is_bulk_out(>ep->desc) &&
 urb->transfer_buffer_length > 0 &&
 urb->transfer_flags & URB_ZERO_PACKET &&
 !(urb->transfer_buffer_length % usb_endpoint_maxp(>ep->desc)))
 num_tds = 2;
else
 num_tds = 1;

urb_priv = kzalloc(sizeof(struct urb_priv) +
num_tds * sizeof(struct xhci_td), mem_flags);
if (!urb_priv)
 return -ENOMEM;

urb_priv->num_tds = num_tds;
urb_priv->num_tds_done = 0;
urb->hcpriv = urb_priv;

trace_xhci_urb_enqueue(urb);

if (usb_endpoint_xfer_control(>ep->desc)) {
 /* Check to see if the max packet size for the default control
  * endpoint changed during FS device enumeration
  */
 if (urb->dev->speed == USB_SPEED_FULL) {
 ret = 

Re: [PATCH] usb-storage: stop using block layer bounce buffers

[Christoph Hellwig]

On Fri, Apr 27, 2018 at 10:09:17AM -0400, Alan Stern wrote:
> On Fri, 27 Apr 2018, Christoph Hellwig wrote:
> 
> > On Sun, Apr 15, 2018 at 11:24:11AM -0400, Alan Stern wrote:
> > > On Sun, 15 Apr 2018, Christoph Hellwig wrote:
> > > 
> > > > USB host controllers now must handle highmem, so we can get rid of 
> > > > bounce
> > > > buffering highmem pages in the block layer.
> > > 
> > > Sorry, I don't quite understand what you are saying.  Do you mean that
> > > all USB host controllers now magically _do_ handle highmem?  Or do you
> > > mean that if they _don't_ handle highmem, we will not support them any
> > > more?
> > 
> > USB controller themselves never cared about highmem, drivers did.  For
> > PIO based controllers they'd have to kmap any address no in the kernel
> > drirect mapping.
> > 
> > Nothing in drivers/usb/host or the other diretories related to host
> > drivers calls page_address (only used in a single gadget) or sg_virt
> > (only used in a few upper level drivers), which makes me assume
> > semi-confidently that no USB host driver is not highmem aware these
> > days.
> 
> sg_virt is called in drivers/usb/core/message.c.  (Maybe that's what
> you meant by "upper level drivers".)  I'm not sure just how important
> that usage is.

I don't really know either.  I'll need some guidance from the usb
maintainers on:

 - when drivers can submit urbs with a scatterlist
 - if there are any drivers that do not want to take highmem

Unfortunately the way dma mapping works in usb is just so deeply
convoluted that I have a hard time following it, and often wonder
what is intentional and what is accidental in it.
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 1/2] dt-bindings: add MediaTek XS-PHY binding

[Rob Herring]

On Wed, May 2, 2018 at 2:04 AM, Chunfeng Yun  wrote:
> Hi Rob,
> On Tue, 2018-05-01 at 09:24 -0500, Rob Herring wrote:
>> On Wed, Apr 25, 2018 at 03:45:28PM +0800, Chunfeng Yun wrote:
>> > Add a DT binding documentation of XS-PHY for MediaTek SoCs
>> > with USB3.1 GEN2 controller

[...]

>> > +   reg = <0 0x11c43000 0 0x0200>;
>> > +   mediatek,src-ref-clk-mhz = <26>;
>> > +   mediatek,src-coef = <17>;
>> > +   #address-cells = <2>;
>> > +   #size-cells = <2>;
>>
>> Really need 64-bit sizes?
> Just an example, 32-bit is also ok, but it's better to use the same
> value as the root node

Why is it better?

It is unnecessary bloat and it is better to limit the range of child
nodes using ranges.

Rob
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] musb: fix remote wakeup racing with suspend

[Bin Liu]

On Wed, May 02, 2018 at 03:12:16AM +0200, Daniel Glöckner wrote:
> Hi,
> 
> On Tue, May 01, 2018 at 08:48:11AM -0500, Bin Liu wrote:
> > On Fri, Apr 27, 2018 at 03:00:05PM +0200, Daniel Glöckner wrote:
> > > It has been observed that writing 0xF2 to the power register while it
> > > reads as 0xF4 results in the register having the value 0xF0, i.e. clearing
> > > RESUME and setting SUSPENDM in one go does not work. It might also violate
> > > the USB spec to transition directly from resume to suspend, especially
> > > when not taking T_DRSMDN into account. But this is what happens when a
> > > remote wakeup occurs between SetPortFeature USB_PORT_FEAT_SUSPEND on the
> > > root hub and musb_bus_suspend being called.
> > > 
> > > This commit returns -EBUSY when musb_bus_suspend is called while remote
> > > wakeup is signalled and thus avoids to reset the RESUME bit. Remember that
> > > resume can be signalled only when the bus was already suspended, so it is
> > > safe to skip the following steps even when musb_hub_control ignores the
> > 
> > what do you mean by "skip the following steps"?
> 
> Setting USB_PORT_STAT_SUSPEND in musb->port1_status, changing
> musb->xceiv->otg->state, setting musb->is_active, etc.

Okay, but I am not sure how "even musb_hub_control ignores the error..."
is relevant in this statement. The steps are safely skipped in
musb_port_suspend() when MUSB_POWER_RESUME bit is set, no matter how
musb_hub_control() to deal with the return code from
musb_port_suspend(). Did I misunderstand anything?

> 
> > > error returned by musb_port_suspend.
> > > 
> > > The resume part of musb_port_suspend is modified to also accept a pending
> > > remote wakeup, to bring it to the end after T_DRSMDN has passed.
> > 
> > Can you please explain more here? I am not sure when musb_port_suspend()
> > is involved in resume by remote wakeup, and what case is a 'pending'
> > remote wakeup?
> 
> With 'pending' I was referring to the situation when MUSB_POWER_RESUME
> has been set by the controller in the power register as a result of
> of a detected remote wakeup.

Okay.

> 
> I see... finish_resume_work is already scheduled by musb_stage0_irq.

Yes.

> So the condition of the if statement probably does not need to be

I think so too. BTY, I don't think this pending remote wakeup situation
will trigger ClearPortFeature, which is the only case that invokes that
if statement you changed.

> changed. I'll test without that part and make a v2 patch if it works.
> 
> Btw., do you know why that 1 iterations while loop is needed in
> musb_port_suspend to pass the OTG Protocol Test as indicated by the
> comment?

Unfortunately I don't. There are many mysteries in the musb drivers :)

Regards,
-Bin.
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Kernel Oops when downloading data from a 4G modem connected via USB

[Amr Bekhit]

> Could you please apply follow patches from linux-usb mailing list:
> 1. usb: dwc2: hcd: Fix host channel halt flow
> 2. usb: dwc2: host: Fix transaction errors in host mode
> and test again.

Thanks for your response. I've tried applying the above patches (taken from
https://patchwork.kernel.org/patch/10096209/ and
https://patchwork.kernel.org/patch/10104403/) to kernel 4.15.16. The
compilation failed with the following error:

drivers/usb/dwc2/hcd.c: In function ‘dwc2_hc_halt’:
drivers/usb/dwc2/hcd.c:995:12: error: ‘struct dwc2_hsotg’ has no member
named ‘core_params’; did you mean ‘hw_params’?
   if ((hsotg->core_params->dma_enable > 0 &&
 ^~
drivers/usb/dwc2/hcd.c:996:12: error: ‘struct dwc2_hsotg’ has no member
named ‘core_params’; did you mean ‘hw_params’?
hsotg->core_params->dma_desc_enable <= 0) ||
 ^~
drivers/usb/dwc2/hcd.c: In function ‘dwc2_core_host_init’:
drivers/usb/dwc2/hcd.c:2339:34: warning: unused variable ‘val’
[-Wunused-variable]
   u32 hcfg, hfir, otgctl, usbcfg, val;
   ^~~
scripts/Makefile.build:324: recipe for target 'drivers/usb/dwc2/hcd.o'
failed

I tried to manually get the patch working by looking at the struct
definitions in core.h and modified lines hcd.c lines 995-996 as follows
(changing core_params to params and dma_enable to host_dma):

if ((hsotg->params.host_dma > 0 &&
  hsotg->params.dma_desc_enable <= 0) ||

This compiles, but doesn't solve the problem. The kernel oops still occurs
with the following trace (full dmesg trace can be found at
https://paste.ee/p/R8Ccj):

[   50.520879] dwc2 101c.usb: --Host Channel 5 Interrupt: Transaction
Error--
[   57.760866] dwc2 101c.usb: --Host Channel 10 Interrupt: Transaction
Error--
[   57.846752] dwc2 101c.usb: --Host Channel 15 Interrupt: Transaction
Error--
[   57.912946] dwc2 101c.usb: --Host Channel 2 Interrupt: Transaction
Error--
[   57.920037] dwc2 101c.usb: --Host Channel 13 Interrupt: Transaction
Error--
[   57.926534] dwc2 101c.usb: --Host Channel 10 Interrupt: Transaction
Error--
[   57.926588] dwc2 101c.usb: dwc2_hc_chhltd_intr_dma: Channel 7 -
ChHltd set, but reason is unknown
[   57.935448] dwc2 101c.usb: hcint 0x0002, intsts 0x0429
[   57.940901] dwc2 101c.usb: dwc2_update_urb_state_abn(): trimming
xfer length
[   57.947796] dwc2 101c.usb: dwc2_update_urb_state(): trimming xfer
length
[   57.985245] dwc2 101c.usb: --Host Channel 15 Interrupt: Transaction
Error--
[   57.988891] dwc2 101c.usb: --Host Channel 10 Interrupt: Transaction
Error--
[   57.989236] dwc2 101c.usb: --Host Channel 14 Interrupt: Transaction
Error--
[   58.005362] dwc2 101c.usb: --Host Channel 3 Interrupt: Transaction
Error--
[   58.005486] dwc2 101c.usb: --Host Channel 10 Interrupt: Transaction
Error--
[   58.005666] dwc2 101c.usb: --Host Channel 15 Interrupt: Transaction
Error--
[   58.006000] dwc2 101c.usb: --Host Channel 14 Interrupt: Transaction
Error--
[   58.006143] dwc2 101c.usb: --Host Channel 1 Interrupt: Transaction
Error--
[   58.006308] dwc2 101c.usb: --Host Channel 15 Interrupt: Transaction
Error--
[   58.006415] dwc2 101c.usb: --Host Channel 0 Interrupt: Transaction
Error--
[   58.006574] dwc2 101c.usb: --Host Channel 14 Interrupt: Transaction
Error--
[   58.006749] dwc2 101c.usb: --Host Channel 10 Interrupt: Transaction
Error--
[   58.020865] Unable to handle kernel paging request at virtual address
76ad3ad7
[   58.027491] pgd = 7da1f8f3
[   58.029054] [76ad3ad7] *pgd=
[   58.031650] Internal error: Oops: 5 [#1] SMP ARM
[   58.035354] Modules linked in:
[   58.037311] CPU: 2 PID: 175 Comm: wget Not tainted 4.15.16 #2
[   58.042274] Hardware name: Rockchip (Device Tree)
[   58.046086] PC is at kfree_skb_list+0x18/0x28
[   58.049493] LR is at skb_release_data+0x40/0x134
[   58.053187] pc : []lr : []psr: 200d0013
[   58.058733] sp : eeb1dd60  ip : eeb1dd78  fp : eeb1dd74
[   58.063114] r10:   r9 :   r8 : ee630404
[   58.067497] r7 : eeb1ddf8  r6 :   r5 : eea19cc0  r4 : ee4ad540
[   58.073336] r3 :   r2 : 1a00  r1 : 1240  r0 : 76ad3ad7
[   58.079176] Flags: nzCv  IRQs on  FIQs on  Mode SVC_32  ISA ARM  Segment
none
[   58.085695] Control: 10c5387d  Table: 8ebf404a  DAC: 0051
[   58.090663] Process wget (pid: 175, stack limit = 0x8f583f74)
[   58.095629] Stack: (0xeeb1dd60 to 0xeeb1e000)
[   58.099048] dd60: ee4ad540 eea19cc0 eeb1dd94 eeb1dd78 c050a968 c0509fbc
eea19cc0 0b00
[   58.106739] dd80: eea19cc0 eeb1ddf8 eeb1ddac eeb1dd98 c0509f30 c050a934
eea19cc0 0b00
[   58.114431] dda0: eeb1ddc4 eeb1ddb0 c0509f48 c0509f14 ee630040 0b00
eeb1de4c eeb1ddc8
[   58.122121] ddc0: c055c9b8 c0509f40 effda7e0  eeb1ddec 0004
eeb1de20 ee6300dc
[   58.129812] dde0: 0001  ee6304dc 0001 eeb1de90 1500
5ae9a3ec 1dcda13f
[   58.137502] de00: eeb1def0 7fff 5ae9a3ec 1dcda13f eeb1de28 

Re: [PATCH 02/20] usb: host: xhci: check DYING state earlier

[Felipe Balbi]

Hi,

Mathias Nyman  writes:
> On 17.04.2018 10:07, Felipe Balbi wrote:
>> 
>> Hi,
>> 
>> Mathias Nyman  writes:
>>> On 16.04.2018 15:29, Felipe Balbi wrote:
 Instead of allocating urb priv and, maybe, bail out due to xhci being
 in DYING state, we can move the check earlier and avoid the memory
 allocation altogether.
>>>
>>> This also moves checking for DYING outside the lock.
>>>
>>> Most cases set DYING with lock held, so if we first get the lock before
>>> checking DYING we have a better chance of not being in the process of dying.
>> 
>> pretty sure that's atomic, though.
>
> That's not what I'm after, your fix is cleaning up code in the case where 
> DYING flag is
> set before xhci_urb_enqueue() is called. I'm worried about the case when 
> setting DYING flag races
> with xhci_urb_enqueue(). i.e. xhci_urb_enqueue() is spinning on the lock, 
> waiting, while
> some other part of the driver is desperately trying to access hw with lock 
> held, failing,
> finally setting DYING flag, and then releasing lock.
>
> If the check is done before taking the lock then the URB might be queued on 
> dying device,
> at a time when xhci_hc_died already started cancelling and giving back all 
> queued URB

this can only happen if checking that bit isn't an atomic operation
which, AFAICT, it is. IOW, it would be the same if you were to change:

if (a & b)
return -1;

to:

if (test_bit(b, ))
return -1;

right? Now, if this isn't an atomic operation, I'm happy to be educated.

>>> Small thing, but so is this cleanup, so not sure its worth the change
>> 
>> Look at the result. With this change we don't need to take a lock,
>> allocate memory, search for endpoint index, search for endpoint
>> state. All of those are needed for proper operation of the function, but
>> if the controller has already died, there's no point in going any
>> further.
>
> But we might miss the fact that host died, and go even further, adding URB to 
> list,
> writing TRBs to ringbuffers etc.
>
> In code we save one line,
> goto: free_priv

We're saving a lot more than that, actually. All of the following ends
up being skipped. All of these are unnecessary work when xHC has already
died:

8<

slot_id = urb->dev->slot_id;
ep_index = xhci_get_endpoint_index(>ep->desc);
ep_state = >devs[slot_id]->eps[ep_index].ep_state;

if (!HCD_HW_ACCESSIBLE(hcd)) {
if (!in_interrupt())
xhci_dbg(xhci, "urb submitted during PCI suspend\n");
return -ESHUTDOWN;
}

if (usb_endpoint_xfer_isoc(>ep->desc))
num_tds = urb->number_of_packets;
else if (usb_endpoint_is_bulk_out(>ep->desc) &&
urb->transfer_buffer_length > 0 &&
urb->transfer_flags & URB_ZERO_PACKET &&
!(urb->transfer_buffer_length % usb_endpoint_maxp(>ep->desc)))
num_tds = 2;
else
num_tds = 1;

urb_priv = kzalloc(sizeof(struct urb_priv) +
   num_tds * sizeof(struct xhci_td), mem_flags);
if (!urb_priv)
return -ENOMEM;

urb_priv->num_tds = num_tds;
urb_priv->num_tds_done = 0;
urb->hcpriv = urb_priv;

trace_xhci_urb_enqueue(urb);

if (usb_endpoint_xfer_control(>ep->desc)) {
/* Check to see if the max packet size for the default control
 * endpoint changed during FS device enumeration
 */
if (urb->dev->speed == USB_SPEED_FULL) {
ret = xhci_check_maxpacket(xhci, slot_id,
ep_index, urb);
if (ret < 0) {
xhci_urb_free_priv(urb_priv);
urb->hcpriv = NULL;
return ret;
}
}
}

spin_lock_irqsave(>lock, flags);

8<

-- 
balbi


signature.asc
Description: PGP signature

Re: [PATCH 02/20] usb: host: xhci: check DYING state earlier

[Mathias Nyman]

On 17.04.2018 10:07, Felipe Balbi wrote:


Hi,

Mathias Nyman  writes:

On 16.04.2018 15:29, Felipe Balbi wrote:

Instead of allocating urb priv and, maybe, bail out due to xhci being
in DYING state, we can move the check earlier and avoid the memory
allocation altogether.


This also moves checking for DYING outside the lock.

Most cases set DYING with lock held, so if we first get the lock before
checking DYING we have a better chance of not being in the process of dying.


pretty sure that's atomic, though.


That's not what I'm after, your fix is cleaning up code in the case where DYING 
flag is
set before xhci_urb_enqueue() is called. I'm worried about the case when 
setting DYING flag races
with xhci_urb_enqueue(). i.e. xhci_urb_enqueue() is spinning on the lock, 
waiting, while
some other part of the driver is desperately trying to access hw with lock 
held, failing,
finally setting DYING flag, and then releasing lock.

If the check is done before taking the lock then the URB might be queued on 
dying device,
at a time when xhci_hc_died already started cancelling and giving back all 
queued URB




Small thing, but so is this cleanup, so not sure its worth the change


Look at the result. With this change we don't need to take a lock,
allocate memory, search for endpoint index, search for endpoint
state. All of those are needed for proper operation of the function, but
if the controller has already died, there's no point in going any
further.


But we might miss the fact that host died, and go even further, adding URB to 
list,
writing TRBs to ringbuffers etc.

In code we save one line,
goto: free_priv

-Mathias
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] USB: serial: visor: handle potential invalid device configuration

[Greg Kroah-Hartman]

On Wed, May 02, 2018 at 09:50:04AM +0200, Johan Hovold wrote:
> On Sun, Apr 29, 2018 at 05:41:55PM +0200, Greg Kroah-Hartman wrote:
> > If we get an invalid device configuration from a palm 3 type device, we
> > might incorrectly parse things, and we have the potential to crash in
> > "interesting" ways.
> > 
> > Fix this up by verifying the size of the configuration passed to us by
> > the device, and only if it is correct, will we handle it.
> > 
> > Reported-by: Andrey Konovalov 
> > Reviewed-by: Andrey Konovalov 
> > Signed-off-by: Greg Kroah-Hartman 
> > 
> > ---
> > 
> > Here is my long-forgotten patch for the visor driver to resolve an issue
> > that Andrey found back in September of 2017.  Sorry for the long delay.
> > 
> > Johan, I incorporated your review comments of my original one-off patch
> > here as well.
> 
> Thanks for the update. I've applied this for 4.17-rc now after adding a
> stable tag and a comment about this one also fixing a slab info leak
> (through that dev_info in the port loop below).

Ugh, I forgot about the stable tag, thanks for that!

greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v1 0/2] usb: dwc2: gadget: Fixes for LPM

[Grigor Tovmasyan]

Hi Simon,

On 4/21/2018 4:52 PM, Simon Shields wrote:
> Hi Grigor,
> 
> On Fri, Apr 20, 2018 at 01:00:16PM +, Grigor Tovmasyan wrote:
>> Hi Simon,
>>
>> On 4/19/2018 8:31 PM, Simon Shields wrote:
>>> Hi all,
>>>
>>> On 10/04/2018 10:21 PM, Grigor Tovmasyan wrote:
 Here are two little fixes for LPM feature.

 First one is coverity warning fix.

 The Second one was asserted by Stefan Wahren.

 Changes from version 0:

 1/2:
   - Instead of converting parameter in the CHECK_RANGE macro
 to int, changed hird_threshold type from u8 to int.


 Grigor Tovmasyan (2):
  usb: dwc2: gadget: Fix coverity issue
  usb: dwc2: gadget: Change LPM default values

 drivers/usb/dwc2/core.h   | 2 +-
 drivers/usb/dwc2/params.c | 8 
 2 files changed, 5 insertions(+), 5 deletions(-)
>>>
>>> The second patch in this series fixes a regression in 4.17-rc1 using dwc2 
>>> in gadget
>>> mode on Exynos4412, introduced by commit 7455f8b7f0b3 ("usb: dwc2: Enable
>>> LPM"). The regression is that using the cdc_acm serial gadget (and
>>> presumably other gadgets) serial console output will only sporadically
>>> show up on the host (it seems to only show up as input is sent).
>>>
>> The second patch is not fix for described by you issue. We will try to
>> reproduce your issue and provide fix. Could you provide some logs or usb
>> traces for issue?
> 
> Here's a log[0]. The log is pretty big: I generated it with both regular and 
> verbose
> debugging enabled for DWC2. However, I suspect the relevant line is
> probably:
> 
> [   95.222330] dwc2 1248.hsotg: dwc2_hsotg_ep_queue: submit request only 
> in active state
> 
> Which occurs whenever the controller is in LPM mode. I guess that input
> makes it "work" because it reawakens the controller -- but I'm just
> spitballing :-). Let me know if you need any more information from my
> side.
> 
> [0]: 
> https://urldefense.proofpoint.com/v2/url?u=https-3A__forkwhiletrue.me_-7Esimon_midas-5Fdwc2-5Flpm-5Fverbose.log=DwIBAg=DPL6_X_6JkXFx7AXWqB0tg=K1ULVL1slpLXpMJJlAXSOxws4tRq0IkTBqxDkyW2hUQ=fkdnWR9_dgHLGH5-mN9lDclJ58GWR__m7hS3zz3am28=aind-wCFaB40EyTcHvphrqt6SngQTnf3CYXJxOfBjWc=
> 
>>
>>> However, I'm unsure if completely disabling LPM is the correct fix, as the 
>>> dwc2
>>> revision in Exynos4412 (0x4f54281a) should support LPM according to the
>>> source
>> Yes, we can enable LPM based on hardware configuration.
>>
>>> I'm not really sure how to debug this any further (vendor kernel
>>> releases contain no mention of LPM in the gadget drivers), so any pointers
>>> in that direction would be much appreciated.
>>>
>>> Cheers,
>>> Simon
>>>
>>
> 
> Cheers,
> Simon
> 

Could you please revert "usb: dwc2: Add core state checking" patch and 
try again.

Let me know about result.

Thanks,
Grigor.
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Regression due to "Workaround for uPD72020x USB3 chips"

[Ard Biesheuvel]

On 2 May 2018 at 11:18, Domenico Andreoli  wrote:
> On Wed, May 02, 2018 at 10:22:05AM +0200, Ard Biesheuvel wrote:
>> On 2 May 2018 at 10:06, Domenico Andreoli  
>> wrote:
>> > Dear all,
>> >
>> >   my home machine stopped to boot starting from kernel version 4.12.7.
>> >
>> > The last message I read is about resetting some USB3 bus. It's 100%
>> > reproducible also with any recent kernel up to 4.17.0-rc3.
>> >
>> > I bisected down to the following commit:
>> >
>> > commit 0e1f0eaed6c20db41ff61e024b361ee3ec9d686c (tag: my_broken_xhci)
>> > Author: Marc Zyngier 
>> > Date:   Tue Aug 1 20:11:08 2017 -0500
>> >
>> > xhci: Reset Renesas uPD72020x USB controller for 32-bit DMA issue
>> >
>>
>> Hello Domenico,
>
> Sir..
>
>>
>> Long time no see :-)
>
> Instead I see you pretty much everywhere :P
>
>>
>> Please refer to the following thread
>>
>> https://marc.info/?l=linux-usb=151872295419486
>>
>> for some discussion on this topic, and a possible workaround.
>
> Interesting, thanks for the pointer!
>
> I'm happy to learn I've this nice piece of HW in my machine. It might
> have at least some other issue while trying to hibernate (there is a
> fair chance for it to abort the process because of some "business").
>
> I tried the usb/uPD720202-reset branch from Marc (with some massaging
> due to quirks now being >32) and my system boots again. I think it's
> more because of the PCI reset is removed, I am not affected by the
> original issue it was meant to fix.
>

Indeed. The majority of x86 machines never perform DMA above 4 GB in
UEFI, so the issue does not occur, although it could still affect a
kernel with IOMMU on kexec'ed from a kernel with IOMMU off.
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Regression due to "Workaround for uPD72020x USB3 chips"

[Domenico Andreoli]

On Wed, May 02, 2018 at 10:22:05AM +0200, Ard Biesheuvel wrote:
> On 2 May 2018 at 10:06, Domenico Andreoli  wrote:
> > Dear all,
> >
> >   my home machine stopped to boot starting from kernel version 4.12.7.
> >
> > The last message I read is about resetting some USB3 bus. It's 100%
> > reproducible also with any recent kernel up to 4.17.0-rc3.
> >
> > I bisected down to the following commit:
> >
> > commit 0e1f0eaed6c20db41ff61e024b361ee3ec9d686c (tag: my_broken_xhci)
> > Author: Marc Zyngier 
> > Date:   Tue Aug 1 20:11:08 2017 -0500
> >
> > xhci: Reset Renesas uPD72020x USB controller for 32-bit DMA issue
> >
> 
> Hello Domenico,

Sir..

> 
> Long time no see :-)

Instead I see you pretty much everywhere :P

> 
> Please refer to the following thread
> 
> https://marc.info/?l=linux-usb=151872295419486
> 
> for some discussion on this topic, and a possible workaround.

Interesting, thanks for the pointer!

I'm happy to learn I've this nice piece of HW in my machine. It might
have at least some other issue while trying to hibernate (there is a
fair chance for it to abort the process because of some "business").

I tried the usb/uPD720202-reset branch from Marc (with some massaging
due to quirks now being >32) and my system boots again. I think it's
more because of the PCI reset is removed, I am not affected by the
original issue it was meant to fix.

> 
> Regards,
> Ard.

thanks,
Dom

-- 
3B10 0CA1 8674 ACBA B4FE  FCD2 CE5B CF17 9960 DE13
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: dwc2: enumeration issue with audio dongle connected to USB hub

[Minas Harutyunyan]

Hi,

On 4/27/2018 10:03 AM, Stefan Wahren wrote:
> Hi,
> during my tests with a Raspberry Pi 2 B with an C-Media audio dongle 
> connected to a powered USB hub, i noticed the enumeration errors below (the 
> device gets finally ernumerated). I tested yesterdays linux-next, 4.17-rc2 
> and 4.14 but all of them show this behavior, if i plugin the audio dongle 
> into the USB hub.
> 
> /:  Bus 01.Port 1: Dev 1, Class=root_hub, Driver=dwc2/1p, 480M
>  |__ Port 1: Dev 2, If 0, Class=Hub, Driver=hub/5p, 480M
>  |__ Port 1: Dev 3, If 0, Class=Vendor Specific Class, 
> Driver=smsc95xx, 480M
>  |__ Port 2: Dev 4, If 0, Class=Hub, Driver=hub/4p, 480M
>  |__ Port 3: Dev 8, If 2, Class=Audio, Driver=snd-usb-audio, 12M
>  |__ Port 3: Dev 8, If 0, Class=Audio, Driver=snd-usb-audio, 12M
>  |__ Port 3: Dev 8, If 3, Class=Human Interface Device, 
> Driver=usbhid, 12M
>  |__ Port 3: Dev 8, If 1, Class=Audio, Driver=snd-usb-audio, 12M
>  |__ Port 1: Dev 5, If 0, Class=Hub, Driver=hub/4p, 480M
>  |__ Port 4: Dev 7, If 1, Class=Human Interface Device, 
> Driver=usbhid, 1.5M
>  |__ Port 4: Dev 7, If 0, Class=Human Interface Device, 
> Driver=usbhid, 1.5M
> 
> The verbose version can be found here:
> https://urldefense.proofpoint.com/v2/url?u=https-3A__gist.github.com_lategoodbye_baa0f8890325f8698664aeb60ecedfd5=DwICaQ=DPL6_X_6JkXFx7AXWqB0tg=cQBKt4q-qzNVC53rNAwuwplH23V61rHQhhULvdLA0U8=oor4Ij_LNZepp0TZuefnbqFJacQjGXIOEk_BRVa4Vf8=qbdE3PnqX9pigSEbMTqXPeSItGUGJTIOVUapC-fZXdg=
> 
> Here is an example dmesg after plugin the audio dongle:
> [ 1176.382877] usb 1-1.2.1.3: new full-speed USB device number 14 using dwc2
> [ 1176.516254] dwc2 2098.usb: dwc2_hc_chhltd_intr_dma: Channel 1 - ChHltd 
> set, but reason is unknown
> [ 1176.516284] dwc2 2098.usb: hcint 0x0402, intsts 0x0429
> [ 1176.516355] dwc2 2098.usb: dwc2_hc_chhltd_intr_dma: Channel 4 - ChHltd 
> set, but reason is unknown
> [ 1176.516372] dwc2 2098.usb: hcint 0x0402, intsts 0x0429
> [ 1176.516427] dwc2 2098.usb: dwc2_hc_chhltd_intr_dma: Channel 6 - ChHltd 
> set, but reason is unknown
> [ 1176.516442] dwc2 2098.usb: hcint 0x0402, intsts 0x0421
> [ 1176.518435] dwc2 2098.usb: dwc2_hc_chhltd_intr_dma: Channel 5 - ChHltd 
> set, but reason is unknown
> [ 1176.518464] dwc2 2098.usb: hcint 0x0402, intsts 0x0421
> [ 1176.518532] dwc2 2098.usb: dwc2_hc_chhltd_intr_dma: Channel 3 - ChHltd 
> set, but reason is unknown
> [ 1176.518549] dwc2 2098.usb: hcint 0x0402, intsts 0x0421
> [ 1176.518605] dwc2 2098.usb: dwc2_hc_chhltd_intr_dma: Channel 1 - ChHltd 
> set, but reason is unknown
> [ 1176.518623] dwc2 2098.usb: hcint 0x0402, intsts 0x0429
> [ 1176.520704] dwc2 2098.usb: dwc2_hc_chhltd_intr_dma: Channel 3 - ChHltd 
> set, but reason is unknown
> [ 1176.520734] dwc2 2098.usb: hcint 0x0402, intsts 0x0421
> [ 1176.520802] dwc2 2098.usb: dwc2_hc_chhltd_intr_dma: Channel 1 - ChHltd 
> set, but reason is unknown
> [ 1176.520820] dwc2 2098.usb: hcint 0x0402, intsts 0x0421
> [ 1176.520887] dwc2 2098.usb: dwc2_hc_chhltd_intr_dma: Channel 6 - ChHltd 
> set, but reason is unknown
> [ 1176.520905] dwc2 2098.usb: hcint 0x0402, intsts 0x0421
> [ 1176.521127] usb 1-1.2.1.3: unable to read config index 0 descriptor/all
> [ 1176.521197] usb 1-1.2.1.3: can't read configurations, error -71
> [ 1176.632956] usb 1-1.2.1.3: new full-speed USB device number 15 using dwc2
> [ 1176.763789] dwc2 2098.usb: dwc2_hc_chhltd_intr_dma: Channel 6 - ChHltd 
> set, but reason is unknown
> [ 1176.763820] dwc2 2098.usb: hcint 0x0402, intsts 0x0421
> [ 1176.763890] dwc2 2098.usb: dwc2_hc_chhltd_intr_dma: Channel 5 - ChHltd 
> set, but reason is unknown
> [ 1176.763909] dwc2 2098.usb: hcint 0x0402, intsts 0x0421
> [ 1176.763998] dwc2 2098.usb: dwc2_hc_chhltd_intr_dma: Channel 2 - ChHltd 
> set, but reason is unknown
> [ 1176.764016] dwc2 2098.usb: hcint 0x0402, intsts 0x0429
> [ 1177.012371] input: C-Media Electronics Inc.   USB PnP Sound Device as 
> /devices/platform/soc/2098.usb/usb1/1-1/1-1.2/1-1.2.1/1-1.2.1.3/1-1.2.1.3:1.3/0003:0D8C:013C.0008/input/input7
> [ 1177.088948] hid-generic 0003:0D8C:013C.0008: input: USB HID v1.00 Device 
> [C-Media Electronics Inc.   USB PnP Sound Device] on 
> usb-2098.usb-1.2.1.3/input3
> 
> Best regards
> 

Could you please apply follow patches from linux-usb mailing list:
1. usb: dwc2: hcd: Fix host channel halt flow
2. usb: dwc2: host: Fix transaction errors in host mode
and test again.

Thanks,
Minas
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Kernel Oops when downloading data from a 4G modem connected via USB

[Minas Harutyunyan]

Hi,

On 4/29/2018 4:44 PM, Amr Bekhit wrote:
> Hello,
> 
> We're working with an embedded system that uses the RK3188 SoC and has a
> Quectel EC25 4G modem connected via USB. We're using Buildroot 2018.02.1 to
> compile the kernel (4.15.16 using the radxarock_defconfig) and root file
> system. The system enumerates the USB just fine and Quectel's quectel-CM
> executable is then used to start QMI and connect to the 4G network. The
> connection is successful, and I can ping websites just fine. However, when
> I come to download a large file, a kernel oops occurs. This happens
> consistently. Here's an example log:
> 
> # wget 
> https://urldefense.proofpoint.com/v2/url?u=http-3A__speedtest.tele2.net_100MB.zip=DwIBaQ=DPL6_X_6JkXFx7AXWqB0tg=cQBKt4q-qzNVC53rNAwuwplH23V61rHQhhULvdLA0U8=jJJIamtosvad_neUIcXyUCTtHjH3ue9cRjgWDi0hOTs=sAsFiRlSCGgMQbB2kirQXr2nURDLZn1rEGlMX5JvJ3k=
> --2018-04-27 14:54:54--  
> https://urldefense.proofpoint.com/v2/url?u=http-3A__speedtest.tele2.net_100MB.zip=DwIBaQ=DPL6_X_6JkXFx7AXWqB0tg=cQBKt4q-qzNVC53rNAwuwplH23V61rHQhhULvdLA0U8=jJJIamtosvad_neUIcXyUCTtHjH3ue9cRjgWDi0hOTs=sAsFiRlSCGgMQbB2kirQXr2nURDLZn1rEGlMX5JvJ3k=
> Resolving speedtest.tele2.net... 90.130.70.73, 2a00:800:1010::1
> Connecting to speedtest.tele2.net|90.130.70.73|:80... connected.
> HTTP request sent, awaiting response... 200 OK
> Length: 104857600 (100M) [application/zip]
> Saving to: '100MB.zip'
> 
> 100MB.zip0%[
> 
>] 358.58K  1.72MB/s   dwc2 101c.usb:
> dwc2_hc_chhltd_intr_dma: Channel 1 - ChHltd set, but reason is unknown
> dwc2 101c.usb: hcint 0x0002, intsts 0x0429
> dwc2 101c.usb: dwc2_update_urb_state_abn(): trimming xfer length
> dwc2 101c.usb: dwc2_update_urb_state(): trimming xfer length
> Unable to handle kernel paging request at virtual address 2f0cf7d0
> pgd = e12e3a71
> [2f0cf7d0] *pgd=
> Internal error: Oops: 5 [#1] SMP ARM
> Modules linked in:
> CPU: 1 PID: 196 Comm: wget Not tainted 4.15.16 #2
> Hardware name: Rockchip (Device Tree)
> PC is at kfree_skb_list+0x18/0x28
> LR is at skb_release_data+0x40/0x134
> pc : []lr : []psr: 2013
> sp : ef085d60  ip : ef085d78  fp : ef085d74
> r10:   r9 :   r8 : ee4a1084
> r7 : ef085df8  r6 :   r5 : ee9b9780  r4 : eeae7f40
> r3 :   r2 : 1b40  r1 : 1380  r0 : 2f0cf7d0
> Flags: nzCv  IRQs on  FIQs on  Mode SVC_32  ISA ARM  Segment none
> Control: 10c5387d  Table: 8e45804a  DAC: 0051
> Process wget (pid: 196, stack limit = 0x11d0fd5f)
> Stack: (0xef085d60 to 0xef086000)
> 5d60: eeae7f40 ee9b9780 ef085d94 ef085d78 c05098f8 c0508f4c ee9b9780
> 1600
> 5d80: ee9b9780 ef085df8 ef085dac ef085d98 c0508ec0 c05098c4 ee9b9780
> 1600
> 5da0: ef085dc4 ef085db0 c0508ed8 c0508ea4 ee4a0cc0 1600 ef085e4c
> ef085dc8
> 5dc0: c055b948 c0508ed0 effba620  eeede0b0 0004 ef085e20
> ee4a0d5c
> 5de0: 0001  ee4a115c 0001 ef085e90 0a00 5ae339c0
> 1c015810
> 5e00: ef085ef0 7fff 5ae339c0 1c015810 ef085e28 ef085e2c 
> 
> 5e20: 0008 ef085e90 c055b304 ee9bdc00 eeea5500 2000 ef084000
> 
> 5e40: ef085e74 ef085e50 c0582410 c055b310  ef085e5c ef085edc
> 
> 5e60: c05823c8 2000 ef085e8c ef085e78 c04fdb38 c05823d4 ef085ef0
> 2000
> 5e80: ef085edc ef085e90 c04fdbc4 c04fdb24   
> 1600
> 5ea0: 0a00 ef085ee8 0001 0002   
> ef085f08
> 5ec0: ee9bdc00   ef085f80 ef085f4c ef085ee0 c01eaf88
> c04fdb48
> 5ee0: 2000  00e25b18 2000   2000
> ef085ee8
> 5f00: 0001 0002 ee9bdc00    
> 
> 5f20:   be9243e0 ee9bdc00  2000 00e25b18
> ef085f80
> 5f40: ef085f7c ef085f50 c01eb044 c01eae94 c02072ac c020720c ef085f7c
> ee9bdc00
> 5f60: ee9bdc00 00e25b18 2000 c0107c84 ef085fa4 ef085f80 c01eb4b0
> c01eafb8
> 5f80:    0003 0008ce08 0003 
> ef085fa8
> 5fa0: c0107aa0 c01eb474  0003 0003 00e25b18 2000
> 
> 5fc0:  0003 0008ce08 0003 2000  000bf64d
> 
> 5fe0: 000850a4 be924470 000164e0 b6cacaf8 6010 0003 
> 
> Backtrace:
> [] (kfree_skb_list) from []
> (skb_release_data+0x40/0x134)
>r5:ee9b9780 r4:eeae7f40
> [] (skb_release_data) from []
> (skb_release_all+0x28/0x2c)
>r7:ef085df8 r6:ee9b9780 r5:1600 r4:ee9b9780
> [] (skb_release_all) from [] (__kfree_skb+0x14/0x20)
>r5:1600 r4:ee9b9780
> [] (__kfree_skb) from [] (tcp_recvmsg+0x644/0x8c8)
>r5:1600 r4:ee4a0cc0
> [] (tcp_recvmsg) from [] (inet_recvmsg+0x48/0xc4)
>r10: r9:ef084000 r8:2000 r7:eeea5500 r6:ee9bdc00 r5:c055b304
>r4:ef085e90
> [] (inet_recvmsg) from [] (sock_recvmsg+0x20/0x24)
>r5:2000 r4:c05823c8
> [] (sock_recvmsg) from [] (sock_read_iter+0x88/0xb0)
>

Re: [RFC PATCH 1/7] usb: typec: Generalize mux mode names

[Heikki Krogerus]

On Wed, May 02, 2018 at 11:23:35AM +0300, Heikki Krogerus wrote:
> Hi Mats,
> 
> On Wed, May 02, 2018 at 12:21:07AM +0200, Mats Karrman wrote:
> > The current naming used for tcpc_mux_mode constants makes
> > too much assumptioms about the usage of the signals.
> > This patch replaces the names with generic names more closely
> > tied to the Type-C specifications and also adds some new ones.
> > At the same time TCPC_MUX_* defines are removed as they do not
> > fit the new concept and currently have no in-tree users.
> 
> I'm afraid trying to generalize the modal connector states even like
> this is not going to work. We can't make any assumptions about how the
> alternate modes configure the pins, or the connector in general.
> 
> The only way this will work is that every alternate mode has its own
> configurations defined separately, and I'm talking about the actual
> pin configurations that the specifications for each alternate mode
> defines, so something like TYPEC_MUX_DP and TYPEC_MUX_DOCK will not
> work for sure.
> 
> The connector states that are defined in USB Type-C specification (so
> basically USB Operation and USB Safe State) can be generalized, but
> those states just should not be defined in tcpm.h. We need to use
> them in other drivers as well.
> 
> I'm in the middle of preparing more complete support for alternate
> modes. If you check the RFC [1] I send previously, in the first patch
> of the series I'm adding documentation that should explain the
> plan.

Sorry, I forgot the link:

[1] https://www.spinics.net/lists/linux-usb/msg166520.html


Cheers,

-- 
heikki
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC PATCH 1/7] usb: typec: Generalize mux mode names

[Heikki Krogerus]

Hi Mats,

On Wed, May 02, 2018 at 12:21:07AM +0200, Mats Karrman wrote:
> The current naming used for tcpc_mux_mode constants makes
> too much assumptioms about the usage of the signals.
> This patch replaces the names with generic names more closely
> tied to the Type-C specifications and also adds some new ones.
> At the same time TCPC_MUX_* defines are removed as they do not
> fit the new concept and currently have no in-tree users.

I'm afraid trying to generalize the modal connector states even like
this is not going to work. We can't make any assumptions about how the
alternate modes configure the pins, or the connector in general.

The only way this will work is that every alternate mode has its own
configurations defined separately, and I'm talking about the actual
pin configurations that the specifications for each alternate mode
defines, so something like TYPEC_MUX_DP and TYPEC_MUX_DOCK will not
work for sure.

The connector states that are defined in USB Type-C specification (so
basically USB Operation and USB Safe State) can be generalized, but
those states just should not be defined in tcpm.h. We need to use
them in other drivers as well.

I'm in the middle of preparing more complete support for alternate
modes. If you check the RFC [1] I send previously, in the first patch
of the series I'm adding documentation that should explain the
plan.

> Signed-off-by: Mats Karrman 
> ---
>  drivers/usb/typec/mux/pi3usb30532.c |  7 ---
>  drivers/usb/typec/tcpm.c|  2 +-
>  include/linux/usb/tcpm.h| 21 ++---
>  3 files changed, 15 insertions(+), 15 deletions(-)
> 
> diff --git a/drivers/usb/typec/mux/pi3usb30532.c 
> b/drivers/usb/typec/mux/pi3usb30532.c
> index b0e88db..279f3c3 100644
> --- a/drivers/usb/typec/mux/pi3usb30532.c
> +++ b/drivers/usb/typec/mux/pi3usb30532.c
> @@ -83,18 +83,19 @@ static int pi3usb30532_mux_set(struct typec_mux *mux, int 
> state)
>   new_conf = pi->conf;
>  
>   switch (state) {
> + default:
>   case TYPEC_MUX_NONE:
>   new_conf = PI3USB30532_CONF_OPEN;
>   break;
> - case TYPEC_MUX_USB:
> + case TYPEC_MUX_2CH_USBSS:
>   new_conf = (new_conf & PI3USB30532_CONF_SWAP) |
>  PI3USB30532_CONF_USB3;
>   break;
> - case TYPEC_MUX_DP:
> + case TYPEC_MUX_4CH_AM:
>   new_conf = (new_conf & PI3USB30532_CONF_SWAP) |
>  PI3USB30532_CONF_4LANE_DP;
>   break;
> - case TYPEC_MUX_DOCK:
> + case TYPEC_MUX_2CH_USBSS_2CH_AM:
>   new_conf = (new_conf & PI3USB30532_CONF_SWAP) |
>  PI3USB30532_CONF_USB3_AND_2LANE_DP;
>   break;
> diff --git a/drivers/usb/typec/tcpm.c b/drivers/usb/typec/tcpm.c
> index 7ee417a..0451ea0 100644
> --- a/drivers/usb/typec/tcpm.c
> +++ b/drivers/usb/typec/tcpm.c
> @@ -790,7 +790,7 @@ static int tcpm_set_roles(struct tcpm_port *port, bool 
> attached,
>   else
>   usb_role = USB_ROLE_DEVICE;
>  
> - ret = tcpm_mux_set(port, TYPEC_MUX_USB, usb_role, orientation);
> + ret = tcpm_mux_set(port, TYPEC_MUX_2CH_USBSS, usb_role, orientation);
>   if (ret < 0)
>   return ret;
>  
> diff --git a/include/linux/usb/tcpm.h b/include/linux/usb/tcpm.h
> index b231b93..3518965 100644
> --- a/include/linux/usb/tcpm.h
> +++ b/include/linux/usb/tcpm.h
> @@ -93,20 +93,19 @@ struct tcpc_config {
>   const struct typec_altmode_desc *alt_modes;
>  };
>  
> -/* Mux state attributes */
> -#define TCPC_MUX_USB_ENABLED BIT(0)  /* USB enabled */
> -#define TCPC_MUX_DP_ENABLED  BIT(1)  /* DP enabled */
> -#define TCPC_MUX_POLARITY_INVERTED   BIT(2)  /* Polarity inverted */
> -
> -/* Mux modes, decoded to attributes */
> +/* Mux modes */
>  enum tcpc_mux_mode {
> - TYPEC_MUX_NONE  = 0,/* Open switch */
> - TYPEC_MUX_USB   = TCPC_MUX_USB_ENABLED, /* USB only */
> - TYPEC_MUX_DP= TCPC_MUX_DP_ENABLED,  /* DP only */
> - TYPEC_MUX_DOCK  = TCPC_MUX_USB_ENABLED |/* Both USB and DP */
> -   TCPC_MUX_DP_ENABLED,
> + TYPEC_MUX_NONE, /* Open switch */
> + TYPEC_MUX_2CH_USBSS,/* 2ch USB SS */
> + TYPEC_MUX_4CH_AM,   /* 4ch Alt Mode */
> + TYPEC_MUX_2CH_USBSS_2CH_AM, /* 2ch USB SS + 2ch Alt Mode */
> +
> + // Example of additional modes that may be needed in future:
> + TYPEC_MUX_4CH_USBSS,/* 4ch USB SS */
> + TYPEC_MUX_2CH_USBSS_2CH_AM_B,   /* 2ch USB SS + 2ch Alt Mode 
> (e.g. DP GPU2) */
>  };
>  
> +
>  /**
>   * struct tcpc_dev - Port configuration and callback functions
>   * @config:  Pointer to port configuration


Thanks,

-- 
heikki
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to 

Re: [PATCH] USB: serial: visor: handle potential invalid device configuration

[Johan Hovold]

On Sun, Apr 29, 2018 at 05:41:55PM +0200, Greg Kroah-Hartman wrote:
> If we get an invalid device configuration from a palm 3 type device, we
> might incorrectly parse things, and we have the potential to crash in
> "interesting" ways.
> 
> Fix this up by verifying the size of the configuration passed to us by
> the device, and only if it is correct, will we handle it.
> 
> Reported-by: Andrey Konovalov 
> Reviewed-by: Andrey Konovalov 
> Signed-off-by: Greg Kroah-Hartman 
> 
> ---
> 
> Here is my long-forgotten patch for the visor driver to resolve an issue
> that Andrey found back in September of 2017.  Sorry for the long delay.
> 
> Johan, I incorporated your review comments of my original one-off patch
> here as well.

Thanks for the update. I've applied this for 4.17-rc now after adding a
stable tag and a comment about this one also fixing a slab info leak
(through that dev_info in the port loop below).

> diff --git a/drivers/usb/serial/visor.c b/drivers/usb/serial/visor.c
> index f5373ed2cd45..8ddbecc25d89 100644
> --- a/drivers/usb/serial/visor.c
> +++ b/drivers/usb/serial/visor.c
> @@ -335,47 +335,48 @@ static int palm_os_3_probe(struct usb_serial *serial,
>   goto exit;
>   }
>  
> - if (retval == sizeof(*connection_info)) {
> - connection_info = (struct visor_connection_info *)
> - transfer_buffer;
> -
> - num_ports = le16_to_cpu(connection_info->num_ports);
> - for (i = 0; i < num_ports; ++i) {
> - switch (
> -connection_info->connections[i].port_function_id) {
> - case VISOR_FUNCTION_GENERIC:
> - string = "Generic";
> - break;
> - case VISOR_FUNCTION_DEBUGGER:
> - string = "Debugger";
> - break;
> - case VISOR_FUNCTION_HOTSYNC:
> - string = "HotSync";
> - break;
> - case VISOR_FUNCTION_CONSOLE:
> - string = "Console";
> - break;
> - case VISOR_FUNCTION_REMOTE_FILE_SYS:
> - string = "Remote File System";
> - break;
> - default:
> - string = "unknown";
> - break;
> - }
> - dev_info(dev, "%s: port %d, is for %s use\n",
> - serial->type->description,
> - connection_info->connections[i].port, string);
> - }

Johan
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] USB: serial: option: adding support for ublox R410M

[Johan Hovold]

On Thu, Apr 26, 2018 at 02:12:32PM -0500, Dan Williams wrote:
> On Thu, 2018-04-26 at 18:29 +0200, Johan Hovold wrote:
> > On Thu, Apr 26, 2018 at 11:22:25PM +0700, Lars Melin wrote:
> > > On 4/26/2018 23:12, Johan Hovold wrote:
> > > > On Thu, Apr 26, 2018 at 06:40:46PM +0700, Lars Melin wrote:
> > > > > On 4/26/2018 18:39, Lars Melin wrote:
> > > > > > On 4/26/2018 18:19, Bjørn Mork wrote:
> > > > > > > Anyway, Qualcomm based designs are definitely handled by
> > > > > > > both drivers.  Using qcserial only makes sense if the
> > > > > > > interface layout matches one of the defined shared
> > > > > > > schemes, which currently are:
> > > > > > > 
> > > > > > >  QCSERIAL_G2K = 0,/* Gobi 2000 */
> > > > > > >  QCSERIAL_G1K = 1,/* Gobi 1000 */
> > > > > > >  QCSERIAL_SWI = 2,/* Sierra Wireless */
> > > > > > >  QCSERIAL_HWI = 3,/* Huawei */
> > > > > > 
> > > > > > It seems to me that this Quectel device matches the
> > > > > > interface layout for Gobi1K:
> > > >
> > > > Yeah, but qcserial appears to select a different altsetting for
> > > > the DM port for Gobi 1000, an altsetting which this particular
> > > > device does not have.
> > > > 
> > > > I didn't re-read the full thread I referred to earlier, but I
> > > > think in it, Dan mentioned Gobi 1000 device requiring firmware
> > > > to be loaded too.
> > > > 
> > > > So if it's not a G1K device, we probably shouldn't be using
> > > > qcserial even if the interface layout happens to match.
> > >
> > > Good point, I forgot about the required firmware loading for
> > > Gobi1K.
> > > So this device should be handled by the option driver.
> > 
> > Yeah, we probably should document all of this at some point. :)
> > 
> > I didn't include the patch in this weeks -rc updates, but I've
> > queued it up for the next batch.
> 
> Option is likely the right driver for this device.
> 
> qcaux was mainly for mobile phones that have a TTY (often cdc-acm) as
> the modem port and a secondary DIAG/DM port driven by qcaux.  The DM
> port doesn't have an interrupt endpoint thus it's not a normal modem
> port requiring the larger buffers of option and its control signaling.
> 
> qcserial (as Bjorn mentioned) is only for actual Gobi-type devices with
> the specific layouts and the firmware loading requirement where the 1K
> and 2K devices start in a special 1-port mode waiting for firmware and
> then become 4-port devices on firmware reboot.

Thanks for that summary. I've applied SZ's patch now.

Johan
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 1/2] dt-bindings: add MediaTek XS-PHY binding

[Chunfeng Yun]

Hi Rob,
On Tue, 2018-05-01 at 09:24 -0500, Rob Herring wrote:
> On Wed, Apr 25, 2018 at 03:45:28PM +0800, Chunfeng Yun wrote:
> > Add a DT binding documentation of XS-PHY for MediaTek SoCs
> > with USB3.1 GEN2 controller
> > 
> > Signed-off-by: Chunfeng Yun 
> > ---
> >  .../devicetree/bindings/phy/phy-mtk-xsphy.txt  |  127 
> > 
> >  1 file changed, 127 insertions(+)
> >  create mode 100644 Documentation/devicetree/bindings/phy/phy-mtk-xsphy.txt
> > 
> > diff --git a/Documentation/devicetree/bindings/phy/phy-mtk-xsphy.txt 
> > b/Documentation/devicetree/bindings/phy/phy-mtk-xsphy.txt
> > new file mode 100644
> > index 000..23c51a0
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/phy/phy-mtk-xsphy.txt
> > @@ -0,0 +1,127 @@
> > +MediaTek XS-PHY binding
> > +--
> > +
> > +The XS-PHY controller supports physical layer functionality for USB3.1
> > +GEN2 controller on MediaTek SoCs.
> > +
> > +Required properties (controller (parent) node):
> > + - compatible  : should be "mediatek,-xsphy", 
> > "mediatek,xsphy",
> > + soc-model is the name of SoC, such as mt2712 etc;
> 
> Please list all valid SoCs.
Ok
> 
> > + when using "mediatek,xsphy" compatible string, you need SoC 
> > specific
> > + ones in addition.
> > +
> > +Required nodes : a sub-node is required for each port the controller
> > + provides. Address range information including the usual
> > + 'reg' property is used inside these nodes to describe
> > + the controller's topology.
> 
> This should go afer the parent optional properties.
Ok
> 
> > +
> > +Optional properties (controller (parent) node):
> > + - reg : offset and length of register shared by multiple U3 
> > ports,
> > + exclude port's private register, if only U2 ports provided,
> > + shouldn't use the property.
> > + - mediatek,src-ref-clk-mhz: u32, frequency of reference clock for 
> > slew rate
> > + calibrate
> > + - mediatek,src-coef   : u32, coefficient for slew rate calibrate, 
> > depends on
> > + SoC process
> > +
> > +Required properties (port (child) node):
> > +- reg  : address and length of the register set for the port.
> > +- clocks   : a list of phandle + clock-specifier pairs, one for each
> > + entry in clock-names
> > +- clock-names  : must contain
> > + "ref": 48M reference clock for HighSpeed analog phy; and 26M
> > +   reference clock for SuperSpeedPlus analog phy, 
> > sometimes is
> > +   24M, 25M or 27M, depended on platform.
> > +- #phy-cells   : should be 1 (See second example)
> > + cell after port phandle is phy type from:
> > +   - PHY_TYPE_USB2
> > +   - PHY_TYPE_USB3
> 
> Is the type a property of the connection to the host? If not, this 
> shouldn't be part of the phy cells. I would add compatible strings to 
> the child nodes to define this. I think that would simplify the driver 
> too as then you can parse DT properties in probe rather than phy_init.
Yes, it is.
It's parsed when the phy is got by the host driver.
> 
> > +
> > +The following optional properties are only for debug or HQA test
> > +Optional properties (PHY_TYPE_USB2 port (child) node):
> > +- mediatek,eye-src : u32, the value of slew rate calibrate
> > +- mediatek,eye-vrt : u32, the selection of VRT reference voltage
> > +- mediatek,eye-term: u32, the selection of HS_TX TERM reference 
> > voltage
> > +- mediatek,efuse-intr  : u32, the selection of Internal Resistor
> > +
> > +Optional properties (PHY_TYPE_USB3 port (child) node):
> > +- mediatek,efuse-intr  : u32, the selection of Internal Resistor
> > +- mediatek,efuse-tx-imp: u32, the selection of TX Impedance
> > +- mediatek,efuse-rx-imp: u32, the selection of RX Impedance
> > +
> > +Example:
> > +
> > +u3phy: usb-phy@11c4 {
> > +   compatible = "mediatek,mt36xx-xsphy", "mediatek,xsphy";
> 
> Is mt36xx a specific SoC? Don't use wildcards in compatible strings.
No, will use a specific one

> 
> > +   reg = <0 0x11c43000 0 0x0200>;
> > +   mediatek,src-ref-clk-mhz = <26>;
> > +   mediatek,src-coef = <17>;
> > +   #address-cells = <2>;
> > +   #size-cells = <2>;
> 
> Really need 64-bit sizes?
Just an example, 32-bit is also ok, but it's better to use the same
value as the root node
> 
> > +   ranges;
> 
> Limiting the range to only the phy addresses is preferred.
> 
> > +   status = "disabled";
> 
> Don't show status in examples.
Ok
> 
> > +
> > +   u2port0: usb-phy@11c4 {
> > +   reg = <0 0x11c4 0 0x0400>;
> > +   clocks = <>;
> > +   clock-names = "ref";
> > +   mediatek,eye-src = <4>;
> > +   #phy-cells = <1>;
> > +   status = "okay";
> > +   };
> > +
> > +   u3port0: usb-phy@11c43000 {
> > +  

Re: [PATCH 1/4] platform: x86: intel_cht_int33fe: Fix dependencies

[Heikki Krogerus]

On Tue, May 01, 2018 at 11:53:24AM +0200, Hans de Goede wrote:
> Hi,
> 
> On 30-04-18 14:41, Heikki Krogerus wrote:
> > The driver will not probe unless bq24190 is loaded, so
> > making it a dependency.
> 
> Hmm, the dependency is pure run-time, with this Kconfig
> change if a user now decides to builtin the intel_cht_int33fe
> driver, the bq24190 driver must also be builtin, I'm not sure
> if that is a good thing.

OK. That should be possible to sort out with something like this:

depends on CHARGER_BQ24190=y || CHARGER_BQ24190=INTEL_CHT_INT33FE

I'll fix this one.

> > Signed-off-by: Heikki Krogerus 
> > Cc: Wolfram Sang 
> > Cc: Darren Hart 
> > Cc: Andy Shevchenko 
> > ---
> >   drivers/i2c/busses/Kconfig   | 3 +--
> >   drivers/platform/x86/Kconfig | 4 ++--
> >   2 files changed, 3 insertions(+), 4 deletions(-)
> > 
> > diff --git a/drivers/i2c/busses/Kconfig b/drivers/i2c/busses/Kconfig
> > index 8d21b9825d71..fce9f2ca0570 100644
> > --- a/drivers/i2c/busses/Kconfig
> > +++ b/drivers/i2c/busses/Kconfig
> > @@ -202,8 +202,7 @@ config I2C_CHT_WC
> >   Note this controller is hooked up to a TI bq24292i charger-IC,
> >   combined with a FUSB302 Type-C port-controller as such it is advised
> > - to also select CONFIG_CHARGER_BQ24190=m and CONFIG_TYPEC_FUSB302=m
> > - (the fusb302 driver currently is in drivers/staging).
> > + to also select CONFIG_TYPEC_FUSB302=m.
> >   config I2C_NFORCE2
> > tristate "Nvidia nForce2, nForce3 and nForce4"
> > diff --git a/drivers/platform/x86/Kconfig b/drivers/platform/x86/Kconfig
> > index 39d06dd1f63a..1dbd9d547e60 100644
> > --- a/drivers/platform/x86/Kconfig
> > +++ b/drivers/platform/x86/Kconfig
> > @@ -866,6 +866,7 @@ config ACPI_CMPC
> >   config INTEL_CHT_INT33FE
> > tristate "Intel Cherry Trail ACPI INT33FE Driver"
> > depends on X86 && ACPI && I2C && REGULATOR
> > +   depends on CHARGER_BQ24190
> > ---help---
> >   This driver add support for the INT33FE ACPI device found on
> >   some Intel Cherry Trail devices.
> > @@ -877,8 +878,7 @@ config INTEL_CHT_INT33FE
> >   i2c drivers for these chips can bind to the them.
> >   If you enable this driver it is advised to also select
> > - CONFIG_TYPEC_FUSB302=m, CONFIG_CHARGER_BQ24190=m and
> > - CONFIG_BATTERY_MAX17042=m.
> > + CONFIG_TYPEC_FUSB302=m and CONFIG_BATTERY_MAX17042=m.
> >   config INTEL_INT0002_VGPIO
> > tristate "Intel ACPI INT0002 Virtual GPIO driver"
> > 

Thanks,

-- 
heikki
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 4/4] usb: roles: intel_xhci: Always allow user control

[Heikki Krogerus]

On Tue, May 01, 2018 at 11:57:55AM +0200, Hans de Goede wrote:
> Hi,
> 
> On 30-04-18 14:41, Heikki Krogerus wrote:
> > Trying to determine the USB port type with this mux is very
> > difficult. To simplify the situation, always allowing user
> > control, even if the port is USB Type-C port.
> > 
> > Signed-off-by: Heikki Krogerus  > ---
> >   drivers/usb/roles/intel-xhci-usb-role-switch.c | 15 +--
> >   1 file changed, 1 insertion(+), 14 deletions(-)
> > 
> > diff --git a/drivers/usb/roles/intel-xhci-usb-role-switch.c 
> > b/drivers/usb/roles/intel-xhci-usb-role-switch.c
> > index 28102127b9d5..6482eee6fd45 100644
> > --- a/drivers/usb/roles/intel-xhci-usb-role-switch.c
> > +++ b/drivers/usb/roles/intel-xhci-usb-role-switch.c
> > @@ -43,15 +43,6 @@ struct intel_xhci_acpi_match {
> > int hrv;
> >   };
> > -/*
> > - * ACPI IDs for PMICs which do not support separate data and power role
> > - * detection (USB ACA detection for micro USB OTG), we allow userspace to
> > - * change the role manually on these.
> > - */
> > -static const struct intel_xhci_acpi_match allow_userspace_ctrl_ids[] = {
> > -   { "INT33F4",  3 }, /* X-Powers AXP288 PMIC */
> > -};
> > -
> >   static int intel_xhci_usb_set_role(struct device *dev, enum usb_role role)
> >   {
> > struct intel_xhci_usb_data *data = dev_get_drvdata(dev);
> > @@ -137,7 +128,6 @@ static int intel_xhci_usb_probe(struct platform_device 
> > *pdev)
> > struct device *dev = >dev;
> > struct intel_xhci_usb_data *data;
> > struct resource *res;
> > -   int i;
> > data = devm_kzalloc(dev, sizeof(*data), GFP_KERNEL);
> > if (!data)
> > @@ -150,10 +140,7 @@ static int intel_xhci_usb_probe(struct platform_device 
> > *pdev)
> > if (!data->base)
> > return -ENOMEM;
> > -   for (i = 0; i < ARRAY_SIZE(allow_userspace_ctrl_ids); i++)
> > -   if (acpi_dev_present(allow_userspace_ctrl_ids[i].hid, "1",
> > -allow_userspace_ctrl_ids[i].hrv))
> > -   sw_desc.allow_userspace_control = true;
> > +   sw_desc.allow_userspace_control = true;
> 
> It would be better to add:
> 
>   .allow_userspace_control = true,
> 
> To the initialization of the struct and also make the struct const since
> we are now no longer changing it and usb_role_switch_register() accepts
> it being const.

Makes sense.

> With that changed:
> 
> Reviewed-by: Hans de Goede 

Thanks,

-- 
heikki
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 3/4] usb: typec: fusb302: Fix debugfs issue

[Heikki Krogerus]

On Mon, Apr 30, 2018 at 06:34:03AM -0700, Guenter Roeck wrote:
> On 04/30/2018 05:41 AM, Heikki Krogerus wrote:
> > Removing the "fusb302" debugfs directory when unloading
> > the driver. That allows the driver to be loaded more then
> > ones.
> > 
> > This fixes an issue where the driver, if unloaded, can't be
> > re-loaded, as the "fusb302" debugfs directory already
> > exists. While here, removing useless condition when creating
> > the debugfs directory.
> > 
> > Fixes: 76f0c53d08b9 ("usb: typec: fusb302: Move out of staging")
> > Signed-off-by: Heikki Krogerus 
> > ---
> >   drivers/usb/typec/fusb302/fusb302.c | 9 -
> >   1 file changed, 4 insertions(+), 5 deletions(-)
> > 
> > diff --git a/drivers/usb/typec/fusb302/fusb302.c 
> > b/drivers/usb/typec/fusb302/fusb302.c
> > index eba6bb890b17..0e5d0aa052f5 100644
> > --- a/drivers/usb/typec/fusb302/fusb302.c
> > +++ b/drivers/usb/typec/fusb302/fusb302.c
> > @@ -218,11 +218,9 @@ static struct dentry *rootdir;
> >   static int fusb302_debugfs_init(struct fusb302_chip *chip)
> >   {
> > mutex_init(>logbuffer_lock);
> > -   if (!rootdir) {
> > -   rootdir = debugfs_create_dir("fusb302", NULL);
> > -   if (!rootdir)
> > -   return -ENOMEM;
> > -   }
> 
> I think the idea here was to permit more than one instance of the driver,
> and have all debugfs file entries under the fusb302 directory. Loading the
> second instance will fail after this patch is applied.

OK, need to come up with something else for this issue then.

> > +   rootdir = debugfs_create_dir("fusb302", NULL);
> > +   if (!rootdir)
> > +   return -ENOMEM;
> > chip->dentry = debugfs_create_file(dev_name(chip->dev),
> >S_IFREG | 0444, rootdir,
> > @@ -234,6 +232,7 @@ static int fusb302_debugfs_init(struct fusb302_chip 
> > *chip)
> >   static void fusb302_debugfs_exit(struct fusb302_chip *chip)
> >   {
> > debugfs_remove(chip->dentry);
> > +   debugfs_remove(rootdir); >   }
> >   #else
> > 

Thanks,

-- 
heikki
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [GIT PULL] USB fixes for v4.17-rc3

[Felipe Balbi]

Hi,

Greg Kroah-Hartman  writes:
> On Fri, Apr 27, 2018 at 11:09:50AM +0300, Felipe Balbi wrote:
>> 
>> Hi Greg,
>> 
>> here's a tiny, 7 fixes only, pull request for the current -rc cycle. Let
>> me know if you want anything to be changed.
>> 
>> cheers
>> 
>> The following changes since commit 6d08b06e67cd117f6992c46611dfb4ce267cd71e:
>> 
>>   Linux 4.17-rc2 (2018-04-22 19:20:09 -0700)
>> 
>> are available in the Git repository at:
>> 
>>   git://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb.git 
>> tags/fixes-for-v4.17-rc3
>> 
>> for you to fetch changes up to ed769520727edbf526e0f510e6c501fc6ba3824a:
>> 
>>   usb: gadget: composite Allow for larger configuration descriptors 
>> (2018-04-27 10:17:10 +0300)
>
> Sorry these missed my last pull request to Linus.  I've taken them now
> and will send them off to him with my next round in a week or so.

sure thing, no issues :-)

-- 
balbi
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v9 2/2] usb/gadget: Add driver for Aspeed SoC virtual hub

[Benjamin Herrenschmidt]

The Aspeed BMC SoCs support a "virtual hub" function. It provides some
HW support for a top-level USB2 hub behind which sit 5 gadget "ports".

This driver adds support for the full functionality, emulating the
hub standard requests and exposing 5 UDC gadget drivers corresponding
to the ports.

The hub itself has HW provided dedicated EP0 and EP1 (the latter for
hub interrupts). It also has dedicated EP0s for each function. For
other endpoints, there's a pool of 15 "generic" endpoints that are
shared among the ports.

The driver relies on my previous patch adding a "dispose" EP op to
handle EP allocation between ports. EPs are allocated from the shared
pool in the UDC "match_ep" callback and assigned to the UDC instance
(added to the gadget ep_list).

When the composite driver gets unbound, the new hook will allow the UDC
to clean things up and return those EPs to the shared pool.

Signed-off-by: Benjamin Herrenschmidt 
---
v9. - Fix lock recursion issues when replying to standard SETUP
  packets
- Fix lifetime of the port_dev struct device

v8. - Rework ast_vhub_rep_desc() to avoid incorrect built error
  when fortify is enabled
- Rework ast_vhub_rep_string() to use usb_gadget_get_string()
  instead of a local copy of ascii2desc
- Whitespace fixes

v7. - Fix OF match list
- Remove unused variable in hub code

v6. - Fix bug with 0-length packets on IN endpoints in desc mode

v5. - Remove #ifdef's and hard coded values
- Remove module parameters
- Honor maximum speed device-tree property
- Remove useless list_empty test
- Cosmetic/spaces fixes
- Add SPDX licence identifiers

v4. - Fix missing unlock ast_vhub_udc_wakeup() error path
- Make "irq" signed to deal with error from platform_get_irq
- Fix Makefile for module builds
- Fix a missing endian conversion

v3. - Rebased
- Add clk stuff

v2. - Cosmetic fixes
- Properly "allocate" device addresses instead of using a never
  reset counter
- Move .dtsi updates to a different patch

foo
---
 drivers/usb/gadget/udc/Kconfig  |   2 +
 drivers/usb/gadget/udc/Makefile |   1 +
 drivers/usb/gadget/udc/aspeed-vhub/Kconfig  |   7 +
 drivers/usb/gadget/udc/aspeed-vhub/Makefile |   4 +
 drivers/usb/gadget/udc/aspeed-vhub/core.c   | 425 ++
 drivers/usb/gadget/udc/aspeed-vhub/dev.c| 589 ++
 drivers/usb/gadget/udc/aspeed-vhub/ep0.c| 486 +++
 drivers/usb/gadget/udc/aspeed-vhub/epn.c| 843 
 drivers/usb/gadget/udc/aspeed-vhub/hub.c| 819 +++
 drivers/usb/gadget/udc/aspeed-vhub/vhub.h   | 514 
 10 files changed, 3690 insertions(+)
 create mode 100644 drivers/usb/gadget/udc/aspeed-vhub/Kconfig
 create mode 100644 drivers/usb/gadget/udc/aspeed-vhub/Makefile
 create mode 100644 drivers/usb/gadget/udc/aspeed-vhub/core.c
 create mode 100644 drivers/usb/gadget/udc/aspeed-vhub/dev.c
 create mode 100644 drivers/usb/gadget/udc/aspeed-vhub/ep0.c
 create mode 100644 drivers/usb/gadget/udc/aspeed-vhub/epn.c
 create mode 100644 drivers/usb/gadget/udc/aspeed-vhub/hub.c
 create mode 100644 drivers/usb/gadget/udc/aspeed-vhub/vhub.h

diff --git a/drivers/usb/gadget/udc/Kconfig b/drivers/usb/gadget/udc/Kconfig
index 0875d38476ee..b838cae1 100644
--- a/drivers/usb/gadget/udc/Kconfig
+++ b/drivers/usb/gadget/udc/Kconfig
@@ -438,6 +438,8 @@ config USB_GADGET_XILINX
  dynamically linked module called "udc-xilinx" and force all
  gadget drivers to also be dynamically linked.
 
+source "drivers/usb/gadget/udc/aspeed-vhub/Kconfig"
+
 #
 # LAST -- dummy/emulated controller
 #
diff --git a/drivers/usb/gadget/udc/Makefile b/drivers/usb/gadget/udc/Makefile
index ce865b129fd6..897f648f3cf1 100644
--- a/drivers/usb/gadget/udc/Makefile
+++ b/drivers/usb/gadget/udc/Makefile
@@ -39,4 +39,5 @@ obj-$(CONFIG_USB_MV_U3D)  += mv_u3d_core.o
 obj-$(CONFIG_USB_GR_UDC)   += gr_udc.o
 obj-$(CONFIG_USB_GADGET_XILINX)+= udc-xilinx.o
 obj-$(CONFIG_USB_SNP_UDC_PLAT) += snps_udc_plat.o
+obj-$(CONFIG_USB_ASPEED_VHUB)  += aspeed-vhub/
 obj-$(CONFIG_USB_BDC_UDC)  += bdc/
diff --git a/drivers/usb/gadget/udc/aspeed-vhub/Kconfig 
b/drivers/usb/gadget/udc/aspeed-vhub/Kconfig
new file mode 100644
index ..f0cdf89b8503
--- /dev/null
+++ b/drivers/usb/gadget/udc/aspeed-vhub/Kconfig
@@ -0,0 +1,7 @@
+# SPDX-License-Identifier: GPL-2.0+
+config USB_ASPEED_VHUB
+   tristate "Aspeed vHub UDC driver"
+   depends on ARCH_ASPEED || COMPILE_TEST
+   help
+ USB peripheral controller for the Aspeed AST2500 family
+ SoCs supporting the "vHub" functionality and USB2.0
diff --git a/drivers/usb/gadget/udc/aspeed-vhub/Makefile 
b/drivers/usb/gadget/udc/aspeed-vhub/Makefile
new file mode 100644
index ..9f3add605f8e
--- /dev/null
+++ b/drivers/usb/gadget/udc/aspeed-vhub/Makefile
@@ -0,0 +1,4 @@
+# SPDX-License-Identifier: GPL-2.0+

[PATCH v9 1/2] usb/gadget: Constify usb_gadget_get_string "table" argument

[Benjamin Herrenschmidt]

The table is never modified by the function. This allows us
to use it on a statically defined table that is marked const.

Signed-off-by: Benjamin Herrenschmidt 
---
 drivers/usb/gadget/usbstring.c | 2 +-
 include/linux/usb/gadget.h | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/usb/gadget/usbstring.c b/drivers/usb/gadget/usbstring.c
index 566ab261e8b7..7c24d1ce1088 100644
--- a/drivers/usb/gadget/usbstring.c
+++ b/drivers/usb/gadget/usbstring.c
@@ -33,7 +33,7 @@
  * characters (which are also widely used in C strings).
  */
 int
-usb_gadget_get_string (struct usb_gadget_strings *table, int id, u8 *buf)
+usb_gadget_get_string (const struct usb_gadget_strings *table, int id, u8 *buf)
 {
struct usb_string   *s;
int len;
diff --git a/include/linux/usb/gadget.h b/include/linux/usb/gadget.h
index 847f423ad9b3..e5cd84a0f84a 100644
--- a/include/linux/usb/gadget.h
+++ b/include/linux/usb/gadget.h
@@ -763,7 +763,7 @@ struct usb_gadget_string_container {
 };
 
 /* put descriptor for string with that id into buf (buflen >= 256) */
-int usb_gadget_get_string(struct usb_gadget_strings *table, int id, u8 *buf);
+int usb_gadget_get_string(const struct usb_gadget_strings *table, int id, u8 
*buf);
 
 /*-*/
 
-- 
2.17.0

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html