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

2017-09-25 Thread Greg KH 
On Tue, Sep 26, 2017 at 08:45:27AM +0800, Li Jun wrote:
> 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/Kconfig  |  14 -
>  drivers/staging/typec/Makefile |   1 -
>  drivers/staging/typec/TODO |   5 -
>  drivers/staging/typec/tcpci.c  | 637 
> -
>  drivers/staging/typec/tcpci.h  | 133 -
>  drivers/usb/typec/Kconfig  |   7 +
>  drivers/usb/typec/Makefile |   1 +
>  drivers/usb/typec/tcpci.c  | 637 
> +
>  drivers/usb/typec/tcpci.h  | 133 +
>  11 files changed, 778 insertions(+), 793 deletions(-)


Creating patches like this with "-M" to git format-patch is nice, that
way we see the rename as just a rename, and not a big delete/add patch.

Can you do that instead and resend this series?

thanks,

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: Type-C port on the Asmedia ASM1142

2017-09-25 Thread Greg KH 
On Tue, Sep 26, 2017 at 09:30:31AM +1000, Will Trives wrote:
> On Mon, 25 Sep 2017 10:52:10 +0200
> Greg KH  wrote:
> 
> > On Mon, Sep 25, 2017 at 05:29:10PM +1000, Will wrote:
> > > Hello,
> > > 
> > > Basically I'm just sending this to see if anyone can confirm whether
> > > they can get SuperSpeed devices working properly through the Type-C
> > > port on an Asmedia ASM1142 controller with Linux (i've tried even
> > > with latest usb-next branch)
> > > 
> > > Any device I use with the cable I have is only able to work at
> > > HighSpeed. So I am wondering if the problem is with the cable or the
> > > controller/driver.
> > > 
> > > I have tested on 2 different PCIe cards and on an integrated Skylake
> > > system.  
> > 
> > What does the kernel logs say when you plug in the device?  And what
> > kernel versions have you tried?
> > 
> > thanks,
> > 
> > greg k-h
> 
> Up to 4.14-rc4 etc
> 
> When I plug things in, they either work fine as a Highspeed device or
> don't work and messages like this appear...
> 
> This is when plugging in a SuperSpeed UAS dock...
> 
> [232782.657551] usb 3-2: new full-speed USB device number 7 using xhci_hcd
> [232791.810878] usb 3-2: new full-speed USB device number 9 using xhci_hcd
> [232792.300861] usb 3-2: new full-speed USB device number 10 using xhci_hcd
> [232793.000854] usb 3-2: new full-speed USB device number 11 using xhci_hcd
> [232800.094199] usb 3-2: new full-speed USB device number 14 using xhci_hcd
> [232800.310903] usb 3-2: device descriptor read/64, error -71
> [232800.607550] usb 3-2: device descriptor read/64, error -71
> [232800.904190] usb 3-2: new full-speed USB device number 15 using xhci_hcd
> [232801.120917] usb 3-2: device descriptor read/64, error -71
> [232801.420958] usb 3-2: device descriptor read/64, error -71
> [232801.717539] usb 3-2: new full-speed USB device number 16 using xhci_hcd
> [232801.743984] usb 3-2: Device not responding to setup address.
> [232801.973966] usb 3-2: Device not responding to setup address.
> [232802.177519] usb 3-2: device not accepting address 16, error -71

Ick, bad device, or cable :(

I'd recommend trying a different cable, USB 3 cables are notoriously
horrid, buy one you "know" should work and try that.

thanks,

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: Type-C port on the Asmedia ASM1142

2017-09-25 Thread Mathias Nyman 

On 26.09.2017 08:55, Adrian Bocaniciu wrote:

On Mon, 25 Sep 2017 17:29:10 +1000
Will  wrote:


Hello,

Basically I'm just sending this to see if anyone can confirm whether
they can get SuperSpeed devices working properly through the Type-C port
on an Asmedia ASM1142 controller with Linux (i've tried even with latest
usb-next branch)


I have 2 different motherboards with ASM1142 and USB type C (a Gigabyte BRIX 
and a Zotac Nano).

On both of them SuperSpeed (5 Gb/s) and UASP work perfectly OK with various 
SSDs.

Therefore, you either have a bad cable (there are many USB 2.0 cables with Type 
C connectors) or your motherboard/BIOS has some weird behavior.

On the other hand, SuperSpeedPlus (10 Gb/s) does not work on ASM1142 in Linux, 
because of bugs in the XHCI driver.



Do you have any more details, logs or documentation about these 10Gbps ASM1142 
bugs in xHCI driver?
I'd be interested in getting that fixed

Thanks
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 v3][for 4.14] xhci: allow TRACE to work with EVENT ring dequeue

2017-09-25 Thread Mathias Nyman 

On 25.09.2017 19:09, David Laight wrote:

From: Adam Wallis

Sent: 25 September 2017 13:26
inc_deq() currently bails earlier for EVENT rings than the common return
point of the function, due to the fact that EVENT rings do not have
link TRBs. The unfortunate side effect of this is that the very useful
trace_xhci_inc_deq() function is not called/usable for EVENT ring
debug.


Is it actually worth using different functions for the different
ring types?
 From what I remember there are conditionals in a lot of the functions
but they are fixed for most of the call sites.



There's some restructuring and refactoring that could be done in xhci,
but that's not part of this patch.

This will just enable better debugging.

Applying this patch

Thanks
-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: Type-C port on the Asmedia ASM1142

2017-09-25 Thread Adrian Bocaniciu 
On Mon, 25 Sep 2017 17:29:10 +1000
Will  wrote:

> Hello,
> 
> Basically I'm just sending this to see if anyone can confirm whether
> they can get SuperSpeed devices working properly through the Type-C port
> on an Asmedia ASM1142 controller with Linux (i've tried even with latest
> usb-next branch)

I have 2 different motherboards with ASM1142 and USB type C (a Gigabyte BRIX 
and a Zotac Nano).

On both of them SuperSpeed (5 Gb/s) and UASP work perfectly OK with various 
SSDs.

Therefore, you either have a bad cable (there are many USB 2.0 cables with Type 
C connectors) or your motherboard/BIOS has some weird behavior.

On the other hand, SuperSpeedPlus (10 Gb/s) does not work on ASM1142 in Linux, 
because of bugs in the XHCI driver.

Best regards !




--
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: Type-C port on the Asmedia ASM1142

2017-09-25 Thread Will Trives 

> Up to 4.14-rc4 etc

Er that's not out yet.

I mean -rc2 hah
--
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 11/12] staging: typec: tcpci: Only touch target bit when enable vconn

2017-09-25 Thread Li Jun 
We need regmap_update_bits to avoid touch any other bits when
enable or disable vconn.

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

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

--
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 10/12] staging: typec: tcpci: update set_cc for different state

2017-09-25 Thread Li Jun 
As we should keep the disconnected cc line to be open when attached,
so update the set_cc interface accordingly for it.

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

diff --git a/drivers/staging/typec/tcpci.c b/drivers/staging/typec/tcpci.c
index cea67f9..c7c45da 100644
--- a/drivers/staging/typec/tcpci.c
+++ b/drivers/staging/typec/tcpci.c
@@ -57,10 +57,11 @@ static int tcpci_write16(struct tcpci *tcpci, unsigned int 
reg, u16 val)
return regmap_raw_write(tcpci->regmap, reg, &val, sizeof(u16));
 }
 
-static int tcpci_set_cc(struct tcpc_dev *tcpc, enum typec_cc_status cc)
+static int tcpci_set_cc(struct tcpc_dev *tcpc, enum typec_cc_status cc,
+   bool attached, enum typec_cc_polarity polarity)
 {
struct tcpci *tcpci = tcpc_to_tcpci(tcpc);
-   unsigned int reg;
+   unsigned int reg = 0, reg_cc1 = 0, reg_cc2 = 0;
int ret;
 
switch (cc) {
@@ -69,26 +70,23 @@ static int tcpci_set_cc(struct tcpc_dev *tcpc, enum 
typec_cc_status cc)
(TCPC_ROLE_CTRL_CC_RA << TCPC_ROLE_CTRL_CC2_SHIFT);
break;
case TYPEC_CC_RD:
-   reg = (TCPC_ROLE_CTRL_CC_RD << TCPC_ROLE_CTRL_CC1_SHIFT) |
-   (TCPC_ROLE_CTRL_CC_RD << TCPC_ROLE_CTRL_CC2_SHIFT);
+   reg_cc1 = TCPC_ROLE_CTRL_CC_RD << TCPC_ROLE_CTRL_CC1_SHIFT;
+   reg_cc2 = TCPC_ROLE_CTRL_CC_RD << TCPC_ROLE_CTRL_CC2_SHIFT;
break;
case TYPEC_CC_RP_DEF:
-   reg = (TCPC_ROLE_CTRL_CC_RP << TCPC_ROLE_CTRL_CC1_SHIFT) |
-   (TCPC_ROLE_CTRL_CC_RP << TCPC_ROLE_CTRL_CC2_SHIFT) |
-   (TCPC_ROLE_CTRL_RP_VAL_DEF <<
-TCPC_ROLE_CTRL_RP_VAL_SHIFT);
+   reg_cc1 = TCPC_ROLE_CTRL_CC_RP << TCPC_ROLE_CTRL_CC1_SHIFT;
+   reg_cc2 = TCPC_ROLE_CTRL_CC_RP << TCPC_ROLE_CTRL_CC2_SHIFT;
+   reg = TCPC_ROLE_CTRL_RP_VAL_DEF << TCPC_ROLE_CTRL_RP_VAL_SHIFT;
break;
case TYPEC_CC_RP_1_5:
-   reg = (TCPC_ROLE_CTRL_CC_RP << TCPC_ROLE_CTRL_CC1_SHIFT) |
-   (TCPC_ROLE_CTRL_CC_RP << TCPC_ROLE_CTRL_CC2_SHIFT) |
-   (TCPC_ROLE_CTRL_RP_VAL_1_5 <<
-TCPC_ROLE_CTRL_RP_VAL_SHIFT);
+   reg_cc1 = TCPC_ROLE_CTRL_CC_RP << TCPC_ROLE_CTRL_CC1_SHIFT;
+   reg_cc2 = TCPC_ROLE_CTRL_CC_RP << TCPC_ROLE_CTRL_CC2_SHIFT;
+   reg = TCPC_ROLE_CTRL_RP_VAL_1_5 << TCPC_ROLE_CTRL_RP_VAL_SHIFT;
break;
case TYPEC_CC_RP_3_0:
-   reg = (TCPC_ROLE_CTRL_CC_RP << TCPC_ROLE_CTRL_CC1_SHIFT) |
-   (TCPC_ROLE_CTRL_CC_RP << TCPC_ROLE_CTRL_CC2_SHIFT) |
-   (TCPC_ROLE_CTRL_RP_VAL_3_0 <<
-TCPC_ROLE_CTRL_RP_VAL_SHIFT);
+   reg_cc1 = TCPC_ROLE_CTRL_CC_RP << TCPC_ROLE_CTRL_CC1_SHIFT;
+   reg_cc2 = TCPC_ROLE_CTRL_CC_RP << TCPC_ROLE_CTRL_CC2_SHIFT;
+   reg = TCPC_ROLE_CTRL_RP_VAL_3_0 << TCPC_ROLE_CTRL_RP_VAL_SHIFT;
break;
case TYPEC_CC_OPEN:
default:
@@ -97,6 +95,13 @@ static int tcpci_set_cc(struct tcpc_dev *tcpc, enum 
typec_cc_status cc)
break;
}
 
+   if (!attached)
+   reg |= reg_cc1 | reg_cc2;
+   else if (polarity == TYPEC_POLARITY_CC1)
+   reg |= reg_cc1;
+   else
+   reg |= reg_cc2;
+
ret = regmap_write(tcpci->regmap, TCPC_ROLE_CTRL, reg);
if (ret < 0)
return ret;
-- 
2.6.6

--
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 12/12] staging: typec: tcpci: move tcpci driver out of staging

2017-09-25 Thread 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/Kconfig  |  14 -
 drivers/staging/typec/Makefile |   1 -
 drivers/staging/typec/TODO |   5 -
 drivers/staging/typec/tcpci.c  | 637 -
 drivers/staging/typec/tcpci.h  | 133 -
 drivers/usb/typec/Kconfig  |   7 +
 drivers/usb/typec/Makefile |   1 +
 drivers/usb/typec/tcpci.c  | 637 +
 drivers/usb/typec/tcpci.h  | 133 +
 11 files changed, 778 insertions(+), 793 deletions(-)

diff --git a/drivers/staging/Kconfig b/drivers/staging/Kconfig
index 5546839..1e3d5d0 100644
--- a/drivers/staging/Kconfig
+++ b/drivers/staging/Kconfig
@@ -112,8 +112,6 @@ source "drivers/staging/vc04_services/Kconfig"
 
 source "drivers/staging/ccree/Kconfig"
 
-source "drivers/staging/typec/Kconfig"
-
 source "drivers/staging/vboxvideo/Kconfig"
 
 source "drivers/staging/pi433/Kconfig"
diff --git a/drivers/staging/Makefile b/drivers/staging/Makefile
index 8951c37..4d1ccb4 100644
--- a/drivers/staging/Makefile
+++ b/drivers/staging/Makefile
@@ -1,7 +1,6 @@
 # Makefile for staging directory
 
 obj-y  += media/
-obj-y  += typec/
 obj-$(CONFIG_IRDA) += irda/net/
 obj-$(CONFIG_IRDA) += irda/drivers/
 obj-$(CONFIG_PRISM2_USB)   += wlan-ng/
diff --git a/drivers/staging/typec/Kconfig b/drivers/staging/typec/Kconfig
deleted file mode 100644
index 5359f55..000
--- a/drivers/staging/typec/Kconfig
+++ /dev/null
@@ -1,14 +0,0 @@
-menu "USB Power Delivery and Type-C drivers"
-
-if TYPEC_TCPM
-
-config TYPEC_TCPCI
-   tristate "Type-C Port Controller Interface driver"
-   depends on I2C
-   select REGMAP_I2C
-   help
- Type-C Port Controller driver for TCPCI-compliant controller.
-
-endif
-
-endmenu
diff --git a/drivers/staging/typec/Makefile b/drivers/staging/typec/Makefile
deleted file mode 100644
index 53d649a..000
--- a/drivers/staging/typec/Makefile
+++ /dev/null
@@ -1 +0,0 @@
-obj-$(CONFIG_TYPEC_TCPCI)  += tcpci.o
diff --git a/drivers/staging/typec/TODO b/drivers/staging/typec/TODO
deleted file mode 100644
index 53fe2f7..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/staging/typec/tcpci.c b/drivers/staging/typec/tcpci.c
deleted file mode 100644
index 293a07c..000
--- a/drivers/staging/typec/tcpci.c
+++ /dev/null
@@ -1,637 +0,0 @@
-/*
- * Copyright 2015-2017 Google, Inc
- *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License as published by
- * the Free Software Foundation; either version 2 of the License, or
- * (at your option) any later version.
- *
- * This program is distributed in the hope that it will be useful,
- * but WITHOUT ANY WARRANTY; without even the implied warranty of
- * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
- * GNU General Public License for more details.
- *
- * USB Type-C Port Controller Interface.
- */
-
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-
-#include "tcpci.h"
-
-#define PD_RETRY_COUNT 3
-
-struct tcpci {
-   struct device *dev;
-   struct i2c_client *client;
-
-   struct tcpm_port *port;
-
-   struct regmap *regmap;
-
-   bool controls_vbus;
-
-   struct tcpc_dev tcpc;
-};
-
-static inline struct tcpci *tcpc_to_tcpci(struct tcpc_dev *tcpc)
-{
-   return container_of(tcpc, struct tcpci, tcpc);
-}
-
-static int tcpci_read16(struct tcpci *tcpci, unsigned int reg,
-   unsigned int *val)
-{
-   return regmap_raw_read(tcpci->regmap, reg, val, sizeof(u16));
-}
-
-static int tcpci_write16(struct tcpci *tcpci, unsigned int reg, u16 val)
-{
-   return regmap_raw_write(tcpci->regmap, reg, &val, sizeof(u16));
-}
-
-static int tcpci_set_cc(struct tcpc_dev *tcpc, enum typec_cc_status cc,
-   bool attached, enum typec_cc_polarity polarity)
-{
-   struct tcpci *tcpci = tcpc_to_tcpci(tcpc);
-   unsigned int reg = 0, reg_cc1 = 0, reg_cc2 = 0;
-   int ret;
-
-   switch (cc) {
-   case TYPEC_CC_RA:
-   reg = (TCPC_ROLE_CTRL_CC_RA << TCPC_ROLE_CTRL_CC1_SHIFT) |
-   (TCPC_ROLE_CTRL_CC_RA << TCPC_ROLE_CTRL_CC2_SHIFT);
-   break;
-   case TYPEC_CC_RD:
-   reg_cc1 = TCPC_ROLE_CTRL_CC_RD << TCPC_ROLE_CTRL_CC1_SHIFT;
-   reg_cc2 = TCPC_ROLE_CTRL_CC_RD << TCPC_ROLE_CTRL_CC2_SHIFT;
-   break;
-   case TYPEC_CC_RP_DEF:
-   reg_cc1 = TCPC_ROLE_CTRL_CC_RP << TCPC_ROLE_CTRL_CC1_SHIFT;
-   reg_cc2 = TCPC_ROLE_CTRL_CC_RP <<

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

2017-09-25 Thread Li Jun 
With that we can clear any pending events and the port is registered
so driver can be ready to handle typec events once we request irq.

Signed-off-by: Peter Chen 
Signed-off-by: Li Jun 
---
 drivers/staging/typec/tcpci.c | 11 +--
 1 file changed, 5 insertions(+), 6 deletions(-)

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

--
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 00/12] staging: typec: tcpci: move out of staging

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

Li Jun (12):
  usb: typec: add API to get port type and preferred role
  usb: typec: add basic typec properties
  staging: typec: tcpci: add documentation for tcpci
  staging: typec: tcpci: support port config passed via dt
  staging: typec: tcpci: register port before request irq
  staging: typec: tcpci: enable vbus detection
  typec: tcpm: add starting value for drp toggling
  staging: typec: tcpci: correct drp toggling
  usb: typec: tcpm: only drives the connected cc line when attached
  staging: typec: tcpci: update set_cc for different state
  staging: typec: tcpci: Only touch target bit when enable vconn
  staging: typec: tcpci: move tcpci driver out of staging

 .../devicetree/bindings/usb/typec-tcpci.txt|  36 ++
 Documentation/devicetree/bindings/usb/typec.txt|  46 ++
 drivers/staging/Kconfig|   2 -
 drivers/staging/Makefile   |   1 -
 drivers/staging/typec/Kconfig  |  14 -
 drivers/staging/typec/Makefile |   1 -
 drivers/staging/typec/TODO |   5 -
 drivers/staging/typec/tcpci.c  | 526 -
 drivers/staging/typec/tcpci.h  | 133 -
 drivers/usb/typec/Kconfig  |   7 +
 drivers/usb/typec/Makefile |   1 +
 drivers/usb/typec/tcpci.c  | 637 +
 drivers/usb/typec/tcpci.h  | 133 +
 drivers/usb/typec/tcpm.c   |  22 +-
 drivers/usb/typec/typec.c  |  45 ++
 include/linux/usb/tcpm.h   |   9 +-
 include/linux/usb/typec.h  |   2 +
 17 files changed, 928 insertions(+), 692 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/usb/typec-tcpci.txt
 create mode 100644 Documentation/devicetree/bindings/usb/typec.txt
 delete mode 100644 drivers/staging/typec/Kconfig
 delete mode 100644 drivers/staging/typec/Makefile
 delete mode 100644 drivers/staging/typec/TODO
 delete mode 100644 drivers/staging/typec/tcpci.c
 delete mode 100644 drivers/staging/typec/tcpci.h
 create mode 100644 drivers/usb/typec/tcpci.c
 create mode 100644 drivers/usb/typec/tcpci.h

-- 
2.6.6

--
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 08/12] staging: typec: tcpci: correct drp toggling

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

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

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

--
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 06/12] staging: typec: tcpci: enable vbus detection

2017-09-25 Thread Li Jun 
TCPCI implementation may need SW to enable VBUS detection to generate
power status events.

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

diff --git a/drivers/staging/typec/tcpci.c b/drivers/staging/typec/tcpci.c
index 6d608b4..851d026 100644
--- a/drivers/staging/typec/tcpci.c
+++ b/drivers/staging/typec/tcpci.c
@@ -313,6 +313,26 @@ static int tcpci_pd_transmit(struct tcpc_dev *tcpc,
return 0;
 }
 
+static int tcpci_vbus_detect(struct tcpc_dev *tcpc, bool enable)
+{
+   struct tcpci *tcpci = tcpc_to_tcpci(tcpc);
+   int ret;
+
+   if (enable) {
+   ret = regmap_write(tcpci->regmap, TCPC_COMMAND,
+  TCPC_CMD_ENABLE_VBUS_DETECT);
+   if (ret < 0)
+   return ret;
+   } else {
+   ret = regmap_write(tcpci->regmap, TCPC_COMMAND,
+  TCPC_CMD_DISABLE_VBUS_DETECT);
+   if (ret < 0)
+   return ret;
+   }
+
+   return 0;
+}
+
 static int tcpci_init(struct tcpc_dev *tcpc)
 {
struct tcpci *tcpci = tcpc_to_tcpci(tcpc);
@@ -344,6 +364,9 @@ static int tcpci_init(struct tcpc_dev *tcpc)
if (ret < 0)
return ret;
 
+   /* Enable Vbus detection */
+   tcpci_vbus_detect(tcpc, true);
+
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.6.6

--
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 01/12] usb: typec: add API to get port type and preferred role

2017-09-25 Thread Li Jun 
This patch add 2 APIs to get port type and preferred role from firmware
description.

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

diff --git a/drivers/usb/typec/typec.c b/drivers/usb/typec/typec.c
index 24e355b..0c77cc4 100644
--- a/drivers/usb/typec/typec.c
+++ b/drivers/usb/typec/typec.c
@@ -12,6 +12,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 
@@ -1249,6 +1250,50 @@ void typec_set_pwr_opmode(struct typec_port *port,
 }
 EXPORT_SYMBOL_GPL(typec_set_pwr_opmode);
 
+/**
+ * typec_get_port_type - Get the typec port type
+ * @dev: Device to get the property of
+ *
+ * This routine is used by typec hardware driver to read property port type
+ * from the device firmware description.
+ *
+ * Returns typec_port_type if success, otherwise negative error code.
+ */
+int typec_get_port_type(struct device *dev)
+{
+   const char *type_str;
+   int ret;
+
+   ret = device_property_read_string(dev, "port-type", &type_str);
+   if (ret < 0)
+   return ret;
+
+   return match_string(typec_port_types, ARRAY_SIZE(typec_port_types),
+type_str);
+}
+EXPORT_SYMBOL_GPL(typec_get_port_type);
+
+/**
+ * typec_get_power_role - Get the typec preferred role
+ * @dev: Device to get the property of
+ *
+ * This routine is used by typec hardware driver to read property default role
+ * from the device firmware description.
+ *
+ * Returns typec_role if success, otherwise negative error code.
+ */
+int typec_get_power_role(struct device *dev)
+{
+   const char *power_str;
+   int ret;
+
+   ret = device_property_read_string(dev, "default-role", &power_str);
+   if (ret < 0)
+   return ret;
+
+   return match_string(typec_roles, ARRAY_SIZE(typec_roles), power_str);
+}
+EXPORT_SYMBOL_GPL(typec_get_power_role);
 /* --- */
 
 /**
diff --git a/include/linux/usb/typec.h b/include/linux/usb/typec.h
index ffe7487..bfac685 100644
--- a/include/linux/usb/typec.h
+++ b/include/linux/usb/typec.h
@@ -243,5 +243,7 @@ void typec_set_data_role(struct typec_port *port, enum 
typec_data_role role);
 void typec_set_pwr_role(struct typec_port *port, enum typec_role role);
 void typec_set_vconn_role(struct typec_port *port, enum typec_role role);
 void typec_set_pwr_opmode(struct typec_port *port, enum typec_pwr_opmode mode);
+int typec_get_port_type(struct device *dev);
+int typec_get_power_role(struct device *dev);
 
 #endif /* __LINUX_USB_TYPEC_H */
-- 
2.6.6

--
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 04/12] staging: typec: tcpci: support port config passed via dt

2017-09-25 Thread Li Jun 
User can define the typec port properties in tcpci node to setup
the port config.

Signed-off-by: Li Jun 
---
 drivers/staging/typec/tcpci.c | 89 +++
 include/linux/usb/tcpm.h  |  6 +--
 2 files changed, 85 insertions(+), 10 deletions(-)

diff --git a/drivers/staging/typec/tcpci.c b/drivers/staging/typec/tcpci.c
index 4636804..0119453 100644
--- a/drivers/staging/typec/tcpci.c
+++ b/drivers/staging/typec/tcpci.c
@@ -425,17 +425,92 @@ static const struct regmap_config tcpci_regmap_config = {
.max_register = 0x7F, /* 0x80 .. 0xFF are vendor defined */
 };
 
-static const struct tcpc_config tcpci_tcpc_config = {
-   .type = TYPEC_PORT_DFP,
-   .default_role = TYPEC_SINK,
-};
-
+/* Populate struct tcpc_config from device-tree */
 static int tcpci_parse_config(struct tcpci *tcpci)
 {
+   struct tcpc_config *tcfg;
+   int ret = -EINVAL;
+
tcpci->controls_vbus = true; /* XXX */
 
-   /* TODO: Populate struct tcpc_config from ACPI/device-tree */
-   tcpci->tcpc.config = &tcpci_tcpc_config;
+   tcpci->tcpc.config = devm_kzalloc(tcpci->dev, sizeof(*tcfg),
+ GFP_KERNEL);
+   if (!tcpci->tcpc.config)
+   return -ENOMEM;
+
+   tcfg = tcpci->tcpc.config;
+
+   /* Get port-type */
+   ret = typec_get_port_type(tcpci->dev);
+   if (ret < 0) {
+   dev_err(tcpci->dev, "typec port type is NOT correct!\n");
+   return ret;
+   }
+   tcfg->type = ret;
+
+   if (tcfg->type == TYPEC_PORT_UFP)
+   goto sink;
+
+   /* Get source PDO */
+   tcfg->nr_src_pdo = device_property_read_u32_array(tcpci->dev,
+   "src-pdos", NULL, 0);
+   if (tcfg->nr_src_pdo <= 0) {
+   dev_err(tcpci->dev, "typec source pdo is missing!\n");
+   return -EINVAL;
+   }
+
+   tcfg->src_pdo = devm_kzalloc(tcpci->dev,
+   sizeof(*tcfg->src_pdo) * tcfg->nr_src_pdo, GFP_KERNEL);
+   if (!tcfg->src_pdo)
+   return -ENOMEM;
+
+   ret = device_property_read_u32_array(tcpci->dev, "src-pdos",
+   tcfg->src_pdo, tcfg->nr_src_pdo);
+   if (ret) {
+   dev_err(tcpci->dev, "Failed to read src pdo!\n");
+   return -EINVAL;
+   }
+
+   if (tcfg->type == TYPEC_PORT_DFP)
+   return 0;
+
+   /* Get the preferred power role for drp */
+   ret = typec_get_power_role(tcpci->dev);
+   if (ret < 0) {
+   dev_err(tcpci->dev, "typec preferred role is wrong!\n");
+   return ret;
+   }
+   tcfg->default_role = ret;
+sink:
+   /* Get sink power capability */
+   tcfg->nr_snk_pdo = device_property_read_u32_array(tcpci->dev,
+   "snk-pdos", NULL, 0);
+   if (tcfg->nr_snk_pdo <= 0) {
+   dev_err(tcpci->dev, "typec sink pdo is missing!\n");
+   return -EINVAL;
+   }
+
+   tcfg->snk_pdo = devm_kzalloc(tcpci->dev,
+   sizeof(*tcfg->snk_pdo) * tcfg->nr_snk_pdo, GFP_KERNEL);
+   if (!tcfg->snk_pdo)
+   return -ENOMEM;
+
+   ret = device_property_read_u32_array(tcpci->dev, "snk-pdos",
+   tcfg->snk_pdo, tcfg->nr_snk_pdo);
+   if (ret) {
+   dev_err(tcpci->dev, "Failed to read sink pdo!\n");
+   return -EINVAL;
+   }
+
+   if (device_property_read_u32(tcpci->dev, "max-snk-mv",
+&tcfg->max_snk_mv) ||
+   device_property_read_u32(tcpci->dev, "max-snk-ma",
+&tcfg->max_snk_ma) ||
+   device_property_read_u32(tcpci->dev, "op-snk-mw",
+&tcfg->operating_snk_mw)) {
+   dev_err(tcpci->dev, "Failed to read sink capability!\n");
+   return -EINVAL;
+   }
 
return 0;
 }
diff --git a/include/linux/usb/tcpm.h b/include/linux/usb/tcpm.h
index 073197f..a67cf77 100644
--- a/include/linux/usb/tcpm.h
+++ b/include/linux/usb/tcpm.h
@@ -76,10 +76,10 @@ enum tcpm_transmit_type {
  * @alt_modes: List of supported alternate modes
  */
 struct tcpc_config {
-   const u32 *src_pdo;
+   u32 *src_pdo;
unsigned int nr_src_pdo;
 
-   const u32 *snk_pdo;
+   u32 *snk_pdo;
unsigned int nr_snk_pdo;
 
const u32 *snk_vdo;
@@ -154,7 +154,7 @@ struct tcpc_mux_dev {
  * @mux:   Pointer to multiplexer data
  */
 struct tcpc_dev {
-   const struct tcpc_config *config;
+   struct tcpc_config *config;
 
int (*init)(struct tcpc_dev *dev);
int (*get_vbus)(struct tcpc_dev *dev);
-- 
2.6.6

--
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 09/12] usb: typec: tcpm: only drives the connected cc line when attached

2017-09-25 Thread Li Jun 
As we should only drive connected cc line to be the right state when
attached, and keeps the other one to be open, so update the set_cc
interface for that.

Signed-off-by: Li Jun 
---
 drivers/usb/typec/tcpm.c | 12 +++-
 include/linux/usb/tcpm.h |  3 ++-
 2 files changed, 13 insertions(+), 2 deletions(-)

diff --git a/drivers/usb/typec/tcpm.c b/drivers/usb/typec/tcpm.c
index 38a6223..c9966ee 100644
--- a/drivers/usb/typec/tcpm.c
+++ b/drivers/usb/typec/tcpm.c
@@ -1857,9 +1857,15 @@ static bool tcpm_start_drp_toggling(struct tcpm_port 
*port,
 
 static void tcpm_set_cc(struct tcpm_port *port, enum typec_cc_status cc)
 {
+   bool attached;
+
tcpm_log(port, "cc:=%d", cc);
port->cc_req = cc;
-   port->tcpc->set_cc(port->tcpc, cc);
+   if (port->state == SRC_ATTACHED || port->state == SNK_ATTACHED)
+   attached = true;
+   else
+   attached = false;
+   port->tcpc->set_cc(port->tcpc, cc, attached, port->polarity);
 }
 
 static int tcpm_init_vbus(struct tcpm_port *port)
@@ -1913,6 +1919,8 @@ static int tcpm_src_attach(struct tcpm_port *port)
if (ret < 0)
return ret;
 
+   tcpm_set_cc(port, tcpm_rp_cc(port));
+
ret = tcpm_set_roles(port, true, TYPEC_SOURCE, TYPEC_HOST);
if (ret < 0)
return ret;
@@ -2028,6 +2036,8 @@ static int tcpm_snk_attach(struct tcpm_port *port)
if (ret < 0)
return ret;
 
+   tcpm_set_cc(port, TYPEC_CC_RD);
+
ret = tcpm_set_roles(port, true, TYPEC_SINK, TYPEC_DEVICE);
if (ret < 0)
return ret;
diff --git a/include/linux/usb/tcpm.h b/include/linux/usb/tcpm.h
index a67cf77..a007e2a1 100644
--- a/include/linux/usb/tcpm.h
+++ b/include/linux/usb/tcpm.h
@@ -159,7 +159,8 @@ struct tcpc_dev {
int (*init)(struct tcpc_dev *dev);
int (*get_vbus)(struct tcpc_dev *dev);
int (*get_current_limit)(struct tcpc_dev *dev);
-   int (*set_cc)(struct tcpc_dev *dev, enum typec_cc_status cc);
+   int (*set_cc)(struct tcpc_dev *dev, enum typec_cc_status cc,
+   bool attached, enum typec_cc_polarity polarity);
int (*get_cc)(struct tcpc_dev *dev, enum typec_cc_status *cc1,
  enum typec_cc_status *cc2);
int (*set_polarity)(struct tcpc_dev *dev,
-- 
2.6.6

--
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 03/12] staging: typec: tcpci: add documentation for tcpci

2017-09-25 Thread 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| 36 ++
 1 file changed, 36 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..9268440
--- /dev/null
+++ b/Documentation/devicetree/bindings/usb/typec-tcpci.txt
@@ -0,0 +1,36 @@
+TCPCI(Typec port cotroller interface) binding
+-
+
+Required properties:
+- compatible:   should be "usb,tcpci".
+- reg:  the i2c slave address of typec port controller device.
+- interrupt-parent: the phandle to the interrupt controller which provides
+the interrupt.
+- interrupts:   interrupt specification for tcpci alert.
+- port-type:typec port type.
+- default-role: preferred power role if port type is "dual".
+
+Required properties only for power source or drp:
+- src-pdos
+
+Required properties only for power sink or drp:
+- snk-pdos
+- max-snk-mv
+- max-snk-ma
+- op-snk-mw
+
+Example:
+
+ptn5110@50 {
+   compatible = "usb,tcpci";
+   reg = <0x50>;
+   interrupt-parent = <&gpio3>;
+   interrupts = <3 IRQ_TYPE_LEVEL_LOW>;
+   port-type = "dual";
+   default-role = "sink";
+   src-pdos = <0x380190c8>;
+   snk-pdos = <0x380190c8 0x3802d0c8>;
+   max-snk-mv = <9000>;
+   max-snk-ma = <1000>;
+   op-snk-mw = <9000>;
+};
-- 
2.6.6

--
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 02/12] usb: typec: add basic typec properties

2017-09-25 Thread Li Jun 
port-type is required for any typec port; default-role is only required
for drp; power source capable needs src-pdos; power sink capable needs
snk-pdos, max-snk-mv, max-snk-ma, op-snk-mw.

Signed-off-by: Li Jun 
---
 Documentation/devicetree/bindings/usb/typec.txt | 46 +
 1 file changed, 46 insertions(+)

diff --git a/Documentation/devicetree/bindings/usb/typec.txt 
b/Documentation/devicetree/bindings/usb/typec.txt
new file mode 100644
index 000..36d4467
--- /dev/null
+++ b/Documentation/devicetree/bindings/usb/typec.txt
@@ -0,0 +1,46 @@
+Generic typec and power delivery properties
+---
+
+Required properties:
+- port-type:should be one of "source", "sink" or "dual".
+- default-role: preferred power role if drp, should be "sink" or "source".
+- src-pdos: An array of u32 with each entry providing supported power
+source data object(PDO), the detailed bit definitions of
+PDO can be found in "Universal Serial Bus Power Delivery
+Specification" chapter 6.4.1.2 Source_Capabilities Message,
+the order of each entry(PDO) should follow the PD spec chapter
+6.4.1. Required only for power source and power dual role with
+power delivery support.
+- snk-pdos: An array of u32 with each entry providing supported power
+sink data object(PDO), the detailed bit definitions of PDO
+can be found in "Universal Serial Bus Power Delivery
+Specification" chapter 6.4.1.3 Sink Capabilities Message,
+the order of each entry(PDO) should follow the PD spec chapter
+6.4.1. Required only for power sink and power dual role with
+power delivery support.
+- max-snk-mv:   The max voltage the sink can support in millivoltage, required
+only for power sink and power dual role with power delivery
+support.
+- max-snk-ma:   The max current the sink can support in milliampere, required
+only for power sink and power dual role with power delivery
+support.
+- op-snk-mw:Sink required operating power in milliwatts, if source offered
+power is less then it, Capability Mismatch is set, required
+only for power sink and power dual role with power delivery
+support.
+
+Example:
+
+ptn5110@50 {
+   compatible = "usb,tcpci";
+   reg = <0x50>;
+   interrupt-parent = <&gpio3>;
+   interrupts = <3 IRQ_TYPE_LEVEL_LOW>;
+   port-type = "dual";
+   default-role = "sink";
+   src-pdos = <0x380190c8>;
+   snk-pdos = <0x380190c8 0x3802d0c8>;
+   max-snk-mv = <9000>;
+   max-snk-ma = <1000>;
+   op-snk-mw = <9000>;
+};
-- 
2.6.6

--
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 07/12] typec: tcpm: add starting value for drp toggling

2017-09-25 Thread Li Jun 
As DRP port autonomously toggles the Rp/Rd need a start value to
begin with, so add one parameter for it in tcpm_start_drp_toggling.

Signed-off-by: Li Jun 
---
 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 8483d3e..38a6223 100644
--- a/drivers/usb/typec/tcpm.c
+++ b/drivers/usb/typec/tcpm.c
@@ -1839,15 +1839,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;
}
@@ -2156,7 +2156,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;
}
@@ -2328,7 +2328,7 @@ static void run_state_machine(struct tcpm_port *port)
if (!port->non_pd_role_swap)
tcpm_swap_complete(port, -ENOTCONN);
tcpm_snk_detach(port);
-   if (tcpm_start_drp_toggling(port)) {
+   if (tcpm_start_drp_toggling(port, TYPEC_CC_RD)) {
tcpm_set_state(port, DRP_TOGGLING, 0);
break;
}
-- 
2.6.6

--
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: write to a UVC device

2017-09-25 Thread Jaejoong Kim 
Hi,

The below link will help.

http://git.ideasonboard.org/uvc-gadget.git
https://lwn.net/Articles/203924/

Jaejoong

2017-09-26 7:06 GMT+09:00 Rail Shafigulin :
> Working on a custom Xilinx board with Petalinux on it. Have
> /dev/video0 node which is UVC. Tested it with vivid driver and know
> that it is working. Now I want to stream my own video through it.
> Decided to test with a simple buffer. Got the following error:
>
> write to UVC: Invalid argument.
>
> The code is provided below.
>
> Can't understand what is the problem with the invalid argument? Is a
> call to write not the correct method to "talk" to the UVC gadget?
>
>
> #define IMG_SIZE_BYTES 100
> int main(int argc, char **argv) {
>   char pImg[IMG_SIZE_BYTES] = {0};
>   int res;
>
>   uvc_fd = open("/dev/video0", O_RDWR | O_NONBLOCK);
>   if (uvc_fd < 0) {
> perror("Open UVC");
> exit(uvc_fd);
>   }
>
>   while(1) {
> res = write(uvc_fd, pImg, IMG_SIZE_BYTES);
> if (res < 0) {
>   perror("write to UVC");
>   close(uvc_fd);
>   exit(res);
> }
> sleep(1);
>   }
>
>   close(uvc_fd);
>   return 0;
> }
>
>
>
> --
> Rail Shafigulin
> Software Engineer
> Esencia Technologies
>
> --
>
>
>
>
> *ESENCIA TECHNOLOGIES, INC.*3945 Freedom Circle, Suite #360,
> Santa Clara CA 95054
> 
>
> Phone: +1 408 736 8284 Fax: +1 408 519 3475
> http://www.esenciatech.com | http://www.lnttechservices.com
>
>
> --
> 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
--
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] r8152: add Linksys USB3GIGV1 id

2017-09-25 Thread Grant Grundler 
On Mon, Sep 25, 2017 at 1:17 PM, Grant Grundler  wrote:
...
> I didn't realize cdc_ether has a blacklist to make sure
> RTL8152|RTL8153 devices are not picked up by cdc_ether. Would you
> prefer I add this device to the blacklist in the same patch?

I've sent a V2 which also updates the blacklist in cdc_ether.

cheers,
grant
--
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 V2] r8152: add Linksys USB3GIGV1 id

2017-09-25 Thread Grant Grundler 
This linksys dongle by default comes up in cdc_ether mode.
This patch allows r8152 to claim the device:
   Bus 002 Device 002: ID 13b1:0041 Linksys

Signed-off-by: Grant Grundler 
---
 drivers/net/usb/cdc_ether.c | 8 
 drivers/net/usb/r8152.c | 2 ++
 2 files changed, 10 insertions(+)

V2: add LINKSYS_VENDOR_ID to cdc_ether blacklist

diff --git a/drivers/net/usb/cdc_ether.c b/drivers/net/usb/cdc_ether.c
index 8ab281b478f2..fa5c2e7aff1a 100644
--- a/drivers/net/usb/cdc_ether.c
+++ b/drivers/net/usb/cdc_ether.c
@@ -546,6 +546,7 @@ static const struct driver_info wwan_info = {
 #define DELL_VENDOR_ID 0x413C
 #define REALTEK_VENDOR_ID  0x0bda
 #define SAMSUNG_VENDOR_ID  0x04e8
+#define LINKSYS_VENDOR_ID  0x13b1
 #define LENOVO_VENDOR_ID   0x17ef
 #define NVIDIA_VENDOR_ID   0x0955
 #define HP_VENDOR_ID   0x03f0
@@ -737,6 +738,13 @@ static const struct usb_device_id  products[] = {
.driver_info = 0,
 },
 
+/* Linksys USB3GIGV1 Ethernet Adapter */
+{
+   USB_DEVICE_AND_INTERFACE_INFO(LINKSYS_VENDOR_ID, 0x0041, USB_CLASS_COMM,
+   USB_CDC_SUBCLASS_ETHERNET, USB_CDC_PROTO_NONE),
+   .driver_info = 0,
+},
+
 /* ThinkPad USB-C Dock (based on Realtek RTL8153) */
 {
USB_DEVICE_AND_INTERFACE_INFO(LENOVO_VENDOR_ID, 0x3062, USB_CLASS_COMM,
diff --git a/drivers/net/usb/r8152.c b/drivers/net/usb/r8152.c
index ceb78e2ea4f0..941ece08ba78 100644
--- a/drivers/net/usb/r8152.c
+++ b/drivers/net/usb/r8152.c
@@ -613,6 +613,7 @@ enum rtl8152_flags {
 #define VENDOR_ID_MICROSOFT0x045e
 #define VENDOR_ID_SAMSUNG  0x04e8
 #define VENDOR_ID_LENOVO   0x17ef
+#define VENDOR_ID_LINKSYS  0x13b1
 #define VENDOR_ID_NVIDIA   0x0955
 
 #define MCU_TYPE_PLA   0x0100
@@ -5316,6 +5317,7 @@ static const struct usb_device_id rtl8152_table[] = {
{REALTEK_USB_DEVICE(VENDOR_ID_LENOVO,  0x7205)},
{REALTEK_USB_DEVICE(VENDOR_ID_LENOVO,  0x720c)},
{REALTEK_USB_DEVICE(VENDOR_ID_LENOVO,  0x7214)},
+   {REALTEK_USB_DEVICE(VENDOR_ID_LINKSYS, 0x0041)},
{REALTEK_USB_DEVICE(VENDOR_ID_NVIDIA,  0x09ff)},
{}
 };
-- 
2.14.1.821.g8fa685d3b7-goog

--
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: Type-C port on the Asmedia ASM1142

2017-09-25 Thread Will Trives 
On Mon, 25 Sep 2017 10:52:10 +0200
Greg KH  wrote:

> On Mon, Sep 25, 2017 at 05:29:10PM +1000, Will wrote:
> > Hello,
> > 
> > Basically I'm just sending this to see if anyone can confirm whether
> > they can get SuperSpeed devices working properly through the Type-C
> > port on an Asmedia ASM1142 controller with Linux (i've tried even
> > with latest usb-next branch)
> > 
> > Any device I use with the cable I have is only able to work at
> > HighSpeed. So I am wondering if the problem is with the cable or the
> > controller/driver.
> > 
> > I have tested on 2 different PCIe cards and on an integrated Skylake
> > system.  
> 
> What does the kernel logs say when you plug in the device?  And what
> kernel versions have you tried?
> 
> thanks,
> 
> greg k-h

Up to 4.14-rc4 etc

When I plug things in, they either work fine as a Highspeed device or
don't work and messages like this appear...

This is when plugging in a SuperSpeed UAS dock...

[232782.657551] usb 3-2: new full-speed USB device number 7 using xhci_hcd
[232791.810878] usb 3-2: new full-speed USB device number 9 using xhci_hcd
[232792.300861] usb 3-2: new full-speed USB device number 10 using xhci_hcd
[232793.000854] usb 3-2: new full-speed USB device number 11 using xhci_hcd
[232800.094199] usb 3-2: new full-speed USB device number 14 using xhci_hcd
[232800.310903] usb 3-2: device descriptor read/64, error -71
[232800.607550] usb 3-2: device descriptor read/64, error -71
[232800.904190] usb 3-2: new full-speed USB device number 15 using xhci_hcd
[232801.120917] usb 3-2: device descriptor read/64, error -71
[232801.420958] usb 3-2: device descriptor read/64, error -71
[232801.717539] usb 3-2: new full-speed USB device number 16 using xhci_hcd
[232801.743984] usb 3-2: Device not responding to setup address.
[232801.973966] usb 3-2: Device not responding to setup address.
[232802.177519] usb 3-2: device not accepting address 16, error -71
[232802.374243] usb 3-2: new full-speed USB device number 17 using xhci_hcd
[232802.400676] usb 3-2: Device not responding to setup address.
[232802.633995] usb 3-2: Device not responding to setup address.
[232802.837511] usb 3-2: device not accepting address 17, error -71
[232802.837541] usb usb3-port2: unable to enumerate USB device

It could be the cable, i'm just not sure, as far as i'm aware it's
supposed to convert a type c port to type a 

Not a huge deal it's just that one of the cards I have only has 1
type-c port and nothing else.



Regards,

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

write to a UVC device

2017-09-25 Thread Rail Shafigulin 
Working on a custom Xilinx board with Petalinux on it. Have
/dev/video0 node which is UVC. Tested it with vivid driver and know
that it is working. Now I want to stream my own video through it.
Decided to test with a simple buffer. Got the following error:

write to UVC: Invalid argument.

The code is provided below.

Can't understand what is the problem with the invalid argument? Is a
call to write not the correct method to "talk" to the UVC gadget?


#define IMG_SIZE_BYTES 100
int main(int argc, char **argv) {
  char pImg[IMG_SIZE_BYTES] = {0};
  int res;

  uvc_fd = open("/dev/video0", O_RDWR | O_NONBLOCK);
  if (uvc_fd < 0) {
perror("Open UVC");
exit(uvc_fd);
  }

  while(1) {
res = write(uvc_fd, pImg, IMG_SIZE_BYTES);
if (res < 0) {
  perror("write to UVC");
  close(uvc_fd);
  exit(res);
}
sleep(1);
  }

  close(uvc_fd);
  return 0;
}



-- 
Rail Shafigulin
Software Engineer
Esencia Technologies

-- 




*ESENCIA TECHNOLOGIES, INC.*3945 Freedom Circle, Suite #360,
Santa Clara CA 95054


Phone: +1 408 736 8284 Fax: +1 408 519 3475 
http://www.esenciatech.com | http://www.lnttechservices.com


--
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: Issue with Gadget UVC and dummy_hcd

2017-09-25 Thread Alan Stern 
On Mon, 25 Sep 2017, David Tulloh wrote:

> Hi,
> 
> I have been trying to get a UVC gadget running through configfs and
> wired in to dummy_hcd.
> 
> I have largely been following the instructions from the Tizen wiki.
> https://wiki.tizen.org/USB/Linux_USB_Layers/Configfs_Composite_Gadget/Usage_eq._to_g_webcam.ko
> 
> However I am getting a hard lockup, I believe when device is started.
> The system does not respond to any commands, including SYSRQ.
> 
> A bash script I have been executing to set it all up is attached, as is the 
> log.
> 
> I am running in a VM against v4.14-rc2. I have the same issues with
> v4.13 and with the recent setup_timer() patch set. The v4.10 kernel
> had other issues which have since been corrected.
> 
> The last log lines are:
> + echo dummy_udc.0
> [   92.086000] udc dummy_udc.0: registering UDC driver [g1]
> [   92.086620] configfs-gadget gadget: adding 'uvc'/9f6ab8a965f0
> to config 'c'/9f6aba715520
> [   92.087544] configfs-gadget gadget: uvc_function_bind
> [   92.089110] dummy_hcd dummy_hcd.0: port status 0x00010101 has changes
> ~~~ end of transmission ~~~
> 
> 
> Is there anything obvious that I have done wrong or an area I should
> start looking?
> 
> I have very little kernel experience but am happy to poke at things
> with GDB like a small child until something happens. However with the
> size of the code base I would appreciate some pointers on where to
> start poking.

Does uvc use isochronous transfers?  I assume it would, since it's a 
video protocol.

dummy-hcd does not support isochronous.  I don't know what would happen 
if you tried it, but one way or another it would not work the way you 
want.

Of course, you might be facing a different problem.

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] r8152: add Linksys USB3GIGV1 id

2017-09-25 Thread Grant Grundler 
[grrhmail...sorry! resending as plain text]

Hallo Oliver!

On Mon, Sep 25, 2017 at 7:51 AM, Oliver Neukum  wrote:
> Am Freitag, den 22.09.2017, 12:06 -0700 schrieb Grant Grundler:
> > This Linksys dongle by default comes up in cdc_ether mode.
> > This patch allows r8152 to claim the device:
> >Bus 002 Device 002: ID 13b1:0041 Linksys
>
> Hi,
>
> have you tested this in case cdc_ether is for some reason already
> loaded?

I did not consider testing this case since it's not possible on a
normal chromeos system (the entire root file system is signed for
normal users and get's rebooted after an update).  I could test this
in developer mode of course.

Did you expect both driver probe routines to claim the device and
wreak havoc with the device?

> The patch seems to enable r8152 but does not disable cdc_ether.

Correct. r8152 happens to claim the device before cdc_ether does - I
thought because cdc_ether is a class driver and only gets picked up
after vendor specific drivers are probed.  Is that correct?

I didn't realize cdc_ether has a blacklist to make sure
RTL8152|RTL8153 devices are not picked up by cdc_ether. Would you
prefer I add this device to the blacklist in the same patch?

cheers,
grant

>
> Regards
> Oliver
>
--
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] ARM: dts: exynos: Add dwc3 SUSPHY quirk

2017-09-25 Thread Krzysztof Kozlowski 
On Fri, Sep 22, 2017 at 10:18:54AM +0200, Andrzej Pietrasiewicz wrote:
> Hi,
> 
> W dniu 19.09.2017 o 20:10, Robin Murphy pisze:
> > On 19/09/17 18:40, Krzysztof Kozlowski wrote:
> > > On Mon, Sep 18, 2017 at 12:02:13PM +0200, Andrzej Pietrasiewicz wrote:
> > > > Odroid XU4 board does not enumerate SuperSpeed devices.
> > > > This patch makes exynos5 series chips use USB SUSPHY quirk,
> > > > which solves the problem.
> > > > 
> > > > Signed-off-by: Andrzej Pietrasiewicz 
> > > > ---
> > > >   arch/arm/boot/dts/exynos54xx.dtsi | 2 ++
> > > >   1 file changed, 2 insertions(+)
> > > 
> > > Makes sense to me... was it tested also on XU3 and XU?
> > 
> > Well, it at least doesn't make USB3 on my XU any more or less broken
> > than it was before ;) (both ports still report an over-current condition
> > even with nothing plugged in - I suspect there's probably still some
> > pinctrl/regulator stuff missing)
> > 
> > Robin.
> > 
> Similar with XU3: nothing is any more or less broken with this patch
> compared to the situation without the patch.

OK, thanks, 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: [PATCH v3][for 4.14] xhci: allow TRACE to work with EVENT ring dequeue

2017-09-25 Thread David Laight 
From: Adam Wallis
> Sent: 25 September 2017 13:26
> inc_deq() currently bails earlier for EVENT rings than the common return
> point of the function, due to the fact that EVENT rings do not have
> link TRBs. The unfortunate side effect of this is that the very useful
> trace_xhci_inc_deq() function is not called/usable for EVENT ring
> debug.

Is it actually worth using different functions for the different
ring types?
>From what I remember there are conditionals in a lot of the functions
but they are fixed for most of the call sites.

David

--
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 v6] xhci : AMD Promontory USB disable port support

2017-09-25 Thread kbuild test robot 
Hi Joe,

[auto build test WARNING on usb/usb-testing]
[also build test WARNING on v4.14-rc2]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/Joe-Lee/xhci-AMD-Promontory-USB-disable-port-support/20170925-212427
base:   https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git 
usb-testing
config: x86_64-randconfig-x011-201739 (attached as .config)
compiler: gcc-6 (Debian 6.2.0-3) 6.2.0 20160901
reproduce:
# save the attached .config to linux build tree
make ARCH=x86_64 

All warnings (new ones prefixed by >>):

   In file included from include/asm-generic/bug.h:4:0,
from arch/x86/include/asm/bug.h:81,
from include/linux/bug.h:4,
from include/linux/mmdebug.h:4,
from include/linux/gfp.h:4,
from include/linux/slab.h:14,
from drivers/usb//host/xhci-hub.c:24:
   drivers/usb//host/xhci-hub.c: In function 'xhci_bus_suspend':
   drivers/usb//host/xhci-hub.c:1511:9: error: implicit declaration of function 
'usb_amd_pt_check_port' [-Werror=implicit-function-declaration]
if (usb_amd_pt_check_port(hcd->self.controller,
^
   include/linux/compiler.h:156:30: note: in definition of macro '__trace_if'
 if (__builtin_constant_p(!!(cond)) ? !!(cond) :   \
 ^~~~
>> drivers/usb//host/xhci-hub.c:1511:5: note: in expansion of macro 'if'
if (usb_amd_pt_check_port(hcd->self.controller,
^~
   cc1: some warnings being treated as errors

vim +/if +1511 drivers/usb//host/xhci-hub.c

  1451  
  1452  int xhci_bus_suspend(struct usb_hcd *hcd)
  1453  {
  1454  struct xhci_hcd *xhci = hcd_to_xhci(hcd);
  1455  int max_ports, port_index;
  1456  __le32 __iomem **port_array;
  1457  struct xhci_bus_state *bus_state;
  1458  unsigned long flags;
  1459  
  1460  max_ports = xhci_get_ports(hcd, &port_array);
  1461  bus_state = &xhci->bus_state[hcd_index(hcd)];
  1462  
  1463  spin_lock_irqsave(&xhci->lock, flags);
  1464  
  1465  if (hcd->self.root_hub->do_remote_wakeup) {
  1466  if (bus_state->resuming_ports ||/* USB2 */
  1467  bus_state->port_remote_wakeup) {/* USB3 */
  1468  spin_unlock_irqrestore(&xhci->lock, flags);
  1469  xhci_dbg(xhci, "suspend failed because a port 
is resuming\n");
  1470  return -EBUSY;
  1471  }
  1472  }
  1473  
  1474  port_index = max_ports;
  1475  bus_state->bus_suspended = 0;
  1476  while (port_index--) {
  1477  /* suspend the port if the port is not suspended */
  1478  u32 t1, t2;
  1479  int slot_id;
  1480  
  1481  t1 = readl(port_array[port_index]);
  1482  t2 = xhci_port_state_to_neutral(t1);
  1483  
  1484  if ((t1 & PORT_PE) && !(t1 & PORT_PLS_MASK)) {
  1485  xhci_dbg(xhci, "port %d not suspended\n", 
port_index);
  1486  slot_id = xhci_find_slot_id_by_port(hcd, xhci,
  1487  port_index + 1);
  1488  if (slot_id) {
  1489  spin_unlock_irqrestore(&xhci->lock, 
flags);
  1490  xhci_stop_device(xhci, slot_id, 1);
  1491  spin_lock_irqsave(&xhci->lock, flags);
  1492  }
  1493  t2 &= ~PORT_PLS_MASK;
  1494  t2 |= PORT_LINK_STROBE | XDEV_U3;
  1495  set_bit(port_index, &bus_state->bus_suspended);
  1496  }
  1497  /* USB core sets remote wake mask for USB 3.0 hubs,
  1498   * including the USB 3.0 roothub, but only if CONFIG_PM
  1499   * is enabled, so also enable remote wake here.
  1500   */
  1501  if (hcd->self.root_hub->do_remote_wakeup) {
  1502  if (t1 & PORT_CONNECT) {
  1503  t2 |= PORT_WKOC_E | PORT_WKDISC_E;
  1504  t2 &= ~PORT_WKCONN_E;
  1505  } else {
  1506  t2 |= PORT_WKOC_E | PORT_WKCONN_E;
  1507  t2 &= ~PORT_WKDISC_E;
  1508  }
  1509  if ((xhci->quirks & XHCI_U2_DISABLE_WAKE) &&
  1510  (hcd->speed <

Re: [PATCH] r8152: add Linksys USB3GIGV1 id

2017-09-25 Thread Oliver Neukum 
Am Freitag, den 22.09.2017, 12:06 -0700 schrieb Grant Grundler:
> This Linksys dongle by default comes up in cdc_ether mode.
> This patch allows r8152 to claim the device:
>    Bus 002 Device 002: ID 13b1:0041 Linksys

Hi,

have you tested this in case cdc_ether is for some reason already
loaded? The patch seems to enable r8152 but does not disable
cdc_ether.

Regards
Oliver

--
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 10/11] staging: typec: fusb302: Hook up mux support using tcpc_gen_mux support

2017-09-25 Thread Hans de Goede 

Hi,

On 25-09-17 15:45, Peter Rosin wrote:

On 2017-09-25 13:35, Hans de Goede wrote:

Hi,

On 25-09-17 12:34, Peter Rosin wrote:

On 2017-09-13 17:48, Hans de Goede wrote:

Hi,

On 13-09-17 17:07, Rob Herring wrote:

On Wed, Sep 13, 2017 at 9:06 AM, Hans de Goede  wrote:

Hi,


On 13-09-17 15:38, Rob Herring wrote:


On Wed, Sep 13, 2017 at 3:56 AM, Hans de Goede 
wrote:


Hi,


On 13-09-17 00:20, Rob Herring wrote:



On Tue, Sep 05, 2017 at 06:42:20PM +0200, Hans de Goede wrote:



Add mux support to the fusb302 driver, call devm_tcpc_gen_mux_create()
to let the generic tcpc_mux_dev code create a tcpc_mux_dev for us.

Also document the mux-names used by the generic tcpc_mux_dev code in
our devicetree bindings.

Cc: Rob Herring 
Cc: Mark Rutland 
Cc: devicet...@vger.kernel.org
Signed-off-by: Hans de Goede 
---
  Documentation/devicetree/bindings/usb/fcs,fusb302.txt |  3 +++
  drivers/staging/typec/fusb302/fusb302.c   | 11
++-
  2 files changed, 13 insertions(+), 1 deletion(-)

diff --git a/Documentation/devicetree/bindings/usb/fcs,fusb302.txt
b/Documentation/devicetree/bindings/usb/fcs,fusb302.txt
index 472facfa5a71..63d639eadacd 100644
--- a/Documentation/devicetree/bindings/usb/fcs,fusb302.txt
+++ b/Documentation/devicetree/bindings/usb/fcs,fusb302.txt
@@ -6,6 +6,9 @@ Required properties :
  - interrupts : Interrupt specifier
Optional properties :
+- mux-controls   : List of mux-ctrl-specifiers containing 1 or
2
muxes
+- mux-names  : "type-c-mode-mux" when using 1 mux, or
+   "type-c-mode-mux", "usb-role-mux" when
using
2 muxes




I'm not sure this is the right place for this. The mux is outside the
FUSB302. In a type-C connector node or USB phy node would make more
sense to me.




The mux certainly does not belong in the USB phy node, it sits between
the
USB PHY
and the Type-C connector and can for example also mux the Type-C pins to
a
Display
Port PHY.



Thinking about this some more, the mux(es) should be its own node(s).
Then the question is where to put the nodes.



Right, the mux will be its own node per
Documentation/devicetree/bindings/mux/mux-controller.txt
the bindings bit this patch is adding is only adding phandles pointing
to that mux-node as the fusb302 "consumes" the mux functionality.

So as such (the fusb302 is the component which should control the mux)
I do believe that the bindings this patch adds are correct.


Humm, that's not how the mux binding works. The mux controller is what
drives the mux select lines and is the provider. The consumer is the
mux device itself. What decides the mux state is determined by what
you are muxing, not which node has mux-controls property.

By putting mux-controls in fusb302 node, you are saying fusb302 is a
mux (or contains a mux).



As for putting it in a type-C connector node, currently we do not have
such
a node,



Well, you should. Type-C connectors are certainly complicated enough
that we'll need one. Plus we already require connector nodes for
display outputs, so what do we do once you add display muxing?



An interesting question, I'm working on this for x86 + ACPI boards actually,
not a board using DT I've been adding DT bindings docs for device-properties
I use because that seems like the right thing to do where the binding is
obvious
(which I believe it is in this case as the fusb302 is the mux consumer) and
because the device-property code should work the same on x86 + ACPI
(where some platform-specific drivers attach the device properties) and
on e.g. ARM + DT.

The rest should probably be left to be figured out when an actual DT
using device using the fusb302 or another Type-C controller shows up.


Well this is a new one (maybe, I suppose others have sneaked by). If
ACPI folks want to use DT bindings, then what do I care. But I have no
interest in reviewing ACPI properties. The whole notion of sharing
bindings between DT and ACPI beyond anything trivial is flawed IMO.
The ptifalls have been discussed multiple times before, so I'm not
going to repeat them here.


Ok, so shall I just drop the 
Documentation/devicetree/bindings/usb/fcs,fusb302.txt
part of this patch then ?


I totally agree with the concern that Rob expressed about handling USB C
muxes in a non-adhoc way. And this makes this series scary. I don't know
enough details about USB C muxes and PD (I just have a very superficial
mental model) to tell if this series is going down the right path. Or
how terrible it will be to fix things up if not?

The series extends the mux subsystem with muxes that pins semantics
to specific states. That is new, and shows up exactly here when Rob is
not happy about the binding. And if Rob does not want this in the
DT bindings then I'm not so sure it is wise to do it at all? This
problem doesn't go away just because you remove the binding. I think
I would feel much better if there was a path forward on how to
represent USB C muxes in DT an

Re: [PATCH v2 10/11] staging: typec: fusb302: Hook up mux support using tcpc_gen_mux support

2017-09-25 Thread Peter Rosin 
On 2017-09-25 13:35, Hans de Goede wrote:
> Hi,
> 
> On 25-09-17 12:34, Peter Rosin wrote:
>> On 2017-09-13 17:48, Hans de Goede wrote:
>>> Hi,
>>>
>>> On 13-09-17 17:07, Rob Herring wrote:
 On Wed, Sep 13, 2017 at 9:06 AM, Hans de Goede  wrote:
> Hi,
>
>
> On 13-09-17 15:38, Rob Herring wrote:
>>
>> On Wed, Sep 13, 2017 at 3:56 AM, Hans de Goede 
>> wrote:
>>>
>>> Hi,
>>>
>>>
>>> On 13-09-17 00:20, Rob Herring wrote:


 On Tue, Sep 05, 2017 at 06:42:20PM +0200, Hans de Goede wrote:
>
>
> Add mux support to the fusb302 driver, call devm_tcpc_gen_mux_create()
> to let the generic tcpc_mux_dev code create a tcpc_mux_dev for us.
>
> Also document the mux-names used by the generic tcpc_mux_dev code in
> our devicetree bindings.
>
> Cc: Rob Herring 
> Cc: Mark Rutland 
> Cc: devicet...@vger.kernel.org
> Signed-off-by: Hans de Goede 
> ---
>  Documentation/devicetree/bindings/usb/fcs,fusb302.txt |  3 +++
>  drivers/staging/typec/fusb302/fusb302.c   | 11
> ++-
>  2 files changed, 13 insertions(+), 1 deletion(-)
>
> diff --git a/Documentation/devicetree/bindings/usb/fcs,fusb302.txt
> b/Documentation/devicetree/bindings/usb/fcs,fusb302.txt
> index 472facfa5a71..63d639eadacd 100644
> --- a/Documentation/devicetree/bindings/usb/fcs,fusb302.txt
> +++ b/Documentation/devicetree/bindings/usb/fcs,fusb302.txt
> @@ -6,6 +6,9 @@ Required properties :
>  - interrupts : Interrupt specifier
>Optional properties :
> +- mux-controls   : List of mux-ctrl-specifiers containing 1 
> or
> 2
> muxes
> +- mux-names  : "type-c-mode-mux" when using 1 mux, or
> +   "type-c-mode-mux", "usb-role-mux" when
> using
> 2 muxes



 I'm not sure this is the right place for this. The mux is outside the
 FUSB302. In a type-C connector node or USB phy node would make more
 sense to me.
>>>
>>>
>>>
>>> The mux certainly does not belong in the USB phy node, it sits between
>>> the
>>> USB PHY
>>> and the Type-C connector and can for example also mux the Type-C pins to
>>> a
>>> Display
>>> Port PHY.
>>
>>
>> Thinking about this some more, the mux(es) should be its own node(s).
>> Then the question is where to put the nodes.
>
>
> Right, the mux will be its own node per
> Documentation/devicetree/bindings/mux/mux-controller.txt
> the bindings bit this patch is adding is only adding phandles pointing
> to that mux-node as the fusb302 "consumes" the mux functionality.
>
> So as such (the fusb302 is the component which should control the mux)
> I do believe that the bindings this patch adds are correct.

 Humm, that's not how the mux binding works. The mux controller is what
 drives the mux select lines and is the provider. The consumer is the
 mux device itself. What decides the mux state is determined by what
 you are muxing, not which node has mux-controls property.

 By putting mux-controls in fusb302 node, you are saying fusb302 is a
 mux (or contains a mux).


>>> As for putting it in a type-C connector node, currently we do not have
>>> such
>>> a node,
>>
>>
>> Well, you should. Type-C connectors are certainly complicated enough
>> that we'll need one. Plus we already require connector nodes for
>> display outputs, so what do we do once you add display muxing?
>
>
> An interesting question, I'm working on this for x86 + ACPI boards 
> actually,
> not a board using DT I've been adding DT bindings docs for 
> device-properties
> I use because that seems like the right thing to do where the binding is
> obvious
> (which I believe it is in this case as the fusb302 is the mux consumer) 
> and
> because the device-property code should work the same on x86 + ACPI
> (where some platform-specific drivers attach the device properties) and
> on e.g. ARM + DT.
>
> The rest should probably be left to be figured out when an actual DT
> using device using the fusb302 or another Type-C controller shows up.

 Well this is a new one (maybe, I suppose others have sneaked by). If
 ACPI folks want to use DT bindings, then what do I care. But I have no
 interest in reviewing ACPI properties. The whole notion of sharing
 bindings between DT and ACPI beyond anything trivial is flawed IMO.
 The ptifalls have been discussed multiple times before, so I'm not
 going to repeat them here.
>>>
>>> Ok, so shall I just drop the 
>>> Document

[PATCH v3][for 4.14] xhci: allow TRACE to work with EVENT ring dequeue

2017-09-25 Thread Adam Wallis 
inc_deq() currently bails earlier for EVENT rings than the common return
point of the function, due to the fact that EVENT rings do not have
link TRBs. The unfortunate side effect of this is that the very useful
trace_xhci_inc_deq() function is not called/usable for EVENT ring
debug.

This patch provides a refactor by removing the multiple return exit
points into a single return which additionally allows for all rings to
use the trace function.

Signed-off-by: Adam Wallis 
---
Changes in v2: undo accidental line removal at end of patch
Changes in v3: reduced complexity by using goto as recommended by Mathias

 drivers/usb/host/xhci-ring.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/drivers/usb/host/xhci-ring.c b/drivers/usb/host/xhci-ring.c
index a944365..8d3df2f 100644
--- a/drivers/usb/host/xhci-ring.c
+++ b/drivers/usb/host/xhci-ring.c
@@ -171,13 +171,13 @@ static void inc_deq(struct xhci_hcd *xhci, struct 
xhci_ring *ring)
if (ring->type == TYPE_EVENT) {
if (!last_trb_on_seg(ring->deq_seg, ring->dequeue)) {
ring->dequeue++;
-   return;
+   goto out;
}
if (last_trb_on_ring(ring, ring->deq_seg, ring->dequeue))
ring->cycle_state ^= 1;
ring->deq_seg = ring->deq_seg->next;
ring->dequeue = ring->deq_seg->trbs;
-   return;
+   goto out;
}
 
/* All other rings have link trbs */
@@ -190,6 +190,7 @@ static void inc_deq(struct xhci_hcd *xhci, struct xhci_ring 
*ring)
ring->dequeue = ring->deq_seg->trbs;
}
 
+out:
trace_xhci_inc_deq(ring);
 
return;
-- 
Qualcomm Datacenter Technologies as an affiliate of Qualcomm Technologies, Inc.
Qualcomm Technologies, 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

Re: Mouse freezes on button depression

2017-09-25 Thread Oliver Neukum 
Am Sonntag, den 24.09.2017, 13:14 +1000 schrieb Christian Bullow:
> Upon depressing the DIP switch or forward/backward buttons, the mouse 
> freezes and is unresponsive. The only way to fix this is my unplugging 
> it, and putting it into a /different/ USB port.
> 
> I am happy to be guided as to how to inform you of the issue and/or 
> capture the messaging from the mouse buttons.
> 
> *dmesg output*
> 
> [ 1386.760402] usb 1-1.1: USB disconnect, device number 3
> [ 1389.758884] usb 1-1.1: new full-speed USB device number 4 using ehci-pci
> [ 1389.872812] usb 1-1.1: New USB device found, idVendor=1044, 
> idProduct=7a13
> [ 1389.872816] usb 1-1.1: New USB device strings: Mfr=1, Product=2, 
> SerialNumber=3
> [ 1389.872818] usb 1-1.1: Product: MSP430-USB Mouse
> [ 1389.872820] usb 1-1.1: Manufacturer: Texas Instruments
> [ 1389.872822] usb 1-1.1: SerialNumber: 8C2F0C5132000C00
> [ 1389.903323] input: Texas Instruments MSP430-USB Mouse as 
> /devices/pci:00/:00:1a.0/usb1/1-1/1-1.1/1-1.1:1.0/0003:1044:7A13.0007/input/input27
> [ 1389.963586] hid-generic 0003:1044:7A13.0007: input,hidraw0: USB HID 
> v1.01 Keyboard [Texas Instruments MSP430-USB Mouse] on 
> usb-:00:1a.0-1.1/input0
> [ 1389.966651] input: Texas Instruments MSP430-USB Mouse as 
> /devices/pci:00/:00:1a.0/usb1/1-1/1-1.1/1-1.1:1.1/0003:1044:7A13.0008/input/input28
> [ 1390.027363] hid-generic 0003:1044:7A13.0008: input,hidraw2: USB HID 
> v1.01 Mouse [Texas Instruments MSP430-USB Mouse] on 
> usb-:00:1a.0-1.1/input1
> [ 1390.031052] input: Texas Instruments MSP430-USB Mouse as 
> /devices/pci:00/:00:1a.0/usb1/1-1/1-1.1/1-1.1:1.2/0003:1044:7A13.0009/input/input29
> [ 1390.091874] hid-generic 0003:1044:7A13.0009: input,hiddev0,hidraw3: 
> USB HID v1.01 Mouse [Texas Instruments MSP430-USB Mouse] on 
> usb-:00:1a.0-1.1/input2
> [ 1400.113061] hid-generic 0003:1044:7A13.000A: timeout initializing reports
> [ 1400.113386] hid-generic 0003:1044:7A13.000A: hiddev0,hidraw5: USB HID 
> v1.01 Device [Texas Instruments MSP430-USB Mouse] on 
> usb-:00:1a.0-1.1/input3


Hi,

this dmesg as such is pretty uninformative. Is that what you get as you
plug in the mouse or as you push the button? If the latter, we will
need a usbmon trace.

Regards
Oliver

--
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][for 4.14] xhci: allow TRACE to work with EVENT ring dequeue

2017-09-25 Thread Adam Wallis 
On 9/25/2017 5:59 AM, Mathias Nyman wrote:
> On 22.09.2017 22:55, Adam Wallis wrote:
>> inc_deq() currently bails earlier for EVENT rings than the common return
>> point of the function, due to the fact that EVENT rings do not have
>> link TRBs. The unfortunate side effect of this is that the very useful
>> trace_xhci_inc_deq() function is not called/usable for EVENT ring
>> debug.
> 
> True, makes sense to trace the event ring deq ptr as well.
> 
>>
>> This patch provides a refactor by removing the multiple return exit
>> points into a single return which additionally allows for all rings to
>> use the trace function.
>>
>> Signed-off-by: Adam Wallis 
>> ---
>> Changes in v2: undo accidental line removal at end of patch
>>
>>   drivers/usb/host/xhci-ring.c | 32 
>>   1 file changed, 16 insertions(+), 16 deletions(-)
>>
>> diff --git a/drivers/usb/host/xhci-ring.c b/drivers/usb/host/xhci-ring.c
>> index a944365..3960ba9 100644
>> --- a/drivers/usb/host/xhci-ring.c
>> +++ b/drivers/usb/host/xhci-ring.c
>> @@ -171,23 +171,23 @@ static void inc_deq(struct xhci_hcd *xhci, struct
>> xhci_ring *ring)
>>   if (ring->type == TYPE_EVENT) {
>>   if (!last_trb_on_seg(ring->deq_seg, ring->dequeue)) {
>>   ring->dequeue++;
>> -    return;
>> +    } else {
>> +    if (last_trb_on_ring(ring, ring->deq_seg,
>> +    ring->dequeue))
>> +    ring->cycle_state ^= 1;
>> +    ring->deq_seg = ring->deq_seg->next;
>> +    ring->dequeue = ring->deq_seg->trbs;
>> +    }
>> +    } else {
>> +    /* All other rings have link trbs */
>> +    if (!trb_is_link(ring->dequeue)) {
>> +    ring->dequeue++;
>> +    ring->num_trbs_free++;
>> +    }
>> +    while (trb_is_link(ring->dequeue)) {
>> +    ring->deq_seg = ring->deq_seg->next;
>> +    ring->dequeue = ring->deq_seg->trbs;
> 
> The added level of indentation makes it a little bit messier.
> How about just using goto out; instead of return?
> 
> out:
> trace_xhci_inc_deq(ring);

My first version of this patch (before submission) actually had gotos, but I
wasn't sure if you would accept. I agree that this will be much cleaner. v3
patch en route!

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


-- 
Adam Wallis
Qualcomm Datacenter Technologies as an affiliate of Qualcomm Technologies, Inc.
Qualcomm Technologies, 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

Re: [PATCH v2 10/11] staging: typec: fusb302: Hook up mux support using tcpc_gen_mux support

2017-09-25 Thread Hans de Goede 

Hi,

On 25-09-17 12:34, Peter Rosin wrote:

On 2017-09-13 17:48, Hans de Goede wrote:

Hi,

On 13-09-17 17:07, Rob Herring wrote:

On Wed, Sep 13, 2017 at 9:06 AM, Hans de Goede  wrote:

Hi,


On 13-09-17 15:38, Rob Herring wrote:


On Wed, Sep 13, 2017 at 3:56 AM, Hans de Goede 
wrote:


Hi,


On 13-09-17 00:20, Rob Herring wrote:



On Tue, Sep 05, 2017 at 06:42:20PM +0200, Hans de Goede wrote:



Add mux support to the fusb302 driver, call devm_tcpc_gen_mux_create()
to let the generic tcpc_mux_dev code create a tcpc_mux_dev for us.

Also document the mux-names used by the generic tcpc_mux_dev code in
our devicetree bindings.

Cc: Rob Herring 
Cc: Mark Rutland 
Cc: devicet...@vger.kernel.org
Signed-off-by: Hans de Goede 
---
 Documentation/devicetree/bindings/usb/fcs,fusb302.txt |  3 +++
 drivers/staging/typec/fusb302/fusb302.c   | 11
++-
 2 files changed, 13 insertions(+), 1 deletion(-)

diff --git a/Documentation/devicetree/bindings/usb/fcs,fusb302.txt
b/Documentation/devicetree/bindings/usb/fcs,fusb302.txt
index 472facfa5a71..63d639eadacd 100644
--- a/Documentation/devicetree/bindings/usb/fcs,fusb302.txt
+++ b/Documentation/devicetree/bindings/usb/fcs,fusb302.txt
@@ -6,6 +6,9 @@ Required properties :
 - interrupts : Interrupt specifier
   Optional properties :
+- mux-controls   : List of mux-ctrl-specifiers containing 1 or
2
muxes
+- mux-names  : "type-c-mode-mux" when using 1 mux, or
+   "type-c-mode-mux", "usb-role-mux" when
using
2 muxes




I'm not sure this is the right place for this. The mux is outside the
FUSB302. In a type-C connector node or USB phy node would make more
sense to me.




The mux certainly does not belong in the USB phy node, it sits between
the
USB PHY
and the Type-C connector and can for example also mux the Type-C pins to
a
Display
Port PHY.



Thinking about this some more, the mux(es) should be its own node(s).
Then the question is where to put the nodes.



Right, the mux will be its own node per
Documentation/devicetree/bindings/mux/mux-controller.txt
the bindings bit this patch is adding is only adding phandles pointing
to that mux-node as the fusb302 "consumes" the mux functionality.

So as such (the fusb302 is the component which should control the mux)
I do believe that the bindings this patch adds are correct.


Humm, that's not how the mux binding works. The mux controller is what
drives the mux select lines and is the provider. The consumer is the
mux device itself. What decides the mux state is determined by what
you are muxing, not which node has mux-controls property.

By putting mux-controls in fusb302 node, you are saying fusb302 is a
mux (or contains a mux).



As for putting it in a type-C connector node, currently we do not have
such
a node,



Well, you should. Type-C connectors are certainly complicated enough
that we'll need one. Plus we already require connector nodes for
display outputs, so what do we do once you add display muxing?



An interesting question, I'm working on this for x86 + ACPI boards actually,
not a board using DT I've been adding DT bindings docs for device-properties
I use because that seems like the right thing to do where the binding is
obvious
(which I believe it is in this case as the fusb302 is the mux consumer) and
because the device-property code should work the same on x86 + ACPI
(where some platform-specific drivers attach the device properties) and
on e.g. ARM + DT.

The rest should probably be left to be figured out when an actual DT
using device using the fusb302 or another Type-C controller shows up.


Well this is a new one (maybe, I suppose others have sneaked by). If
ACPI folks want to use DT bindings, then what do I care. But I have no
interest in reviewing ACPI properties. The whole notion of sharing
bindings between DT and ACPI beyond anything trivial is flawed IMO.
The ptifalls have been discussed multiple times before, so I'm not
going to repeat them here.


Ok, so shall I just drop the 
Documentation/devicetree/bindings/usb/fcs,fusb302.txt
part of this patch then ?


I totally agree with the concern that Rob expressed about handling USB C
muxes in a non-adhoc way. And this makes this series scary. I don't know
enough details about USB C muxes and PD (I just have a very superficial
mental model) to tell if this series is going down the right path. Or
how terrible it will be to fix things up if not?

The series extends the mux subsystem with muxes that pins semantics
to specific states. That is new, and shows up exactly here when Rob is
not happy about the binding. And if Rob does not want this in the
DT bindings then I'm not so sure it is wise to do it at all? This
problem doesn't go away just because you remove the binding. I think
I would feel much better if there was a path forward on how to
represent USB C muxes in DT and how that would fit with the driver
structure.

If you compare to the i2c-muxes, there is a

Re: [PATCH v2 10/11] staging: typec: fusb302: Hook up mux support using tcpc_gen_mux support

2017-09-25 Thread Peter Rosin 
On 2017-09-13 17:48, Hans de Goede wrote:
> Hi,
> 
> On 13-09-17 17:07, Rob Herring wrote:
>> On Wed, Sep 13, 2017 at 9:06 AM, Hans de Goede  wrote:
>>> Hi,
>>>
>>>
>>> On 13-09-17 15:38, Rob Herring wrote:

 On Wed, Sep 13, 2017 at 3:56 AM, Hans de Goede 
 wrote:
>
> Hi,
>
>
> On 13-09-17 00:20, Rob Herring wrote:
>>
>>
>> On Tue, Sep 05, 2017 at 06:42:20PM +0200, Hans de Goede wrote:
>>>
>>>
>>> Add mux support to the fusb302 driver, call devm_tcpc_gen_mux_create()
>>> to let the generic tcpc_mux_dev code create a tcpc_mux_dev for us.
>>>
>>> Also document the mux-names used by the generic tcpc_mux_dev code in
>>> our devicetree bindings.
>>>
>>> Cc: Rob Herring 
>>> Cc: Mark Rutland 
>>> Cc: devicet...@vger.kernel.org
>>> Signed-off-by: Hans de Goede 
>>> ---
>>> Documentation/devicetree/bindings/usb/fcs,fusb302.txt |  3 +++
>>> drivers/staging/typec/fusb302/fusb302.c   | 11
>>> ++-
>>> 2 files changed, 13 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/Documentation/devicetree/bindings/usb/fcs,fusb302.txt
>>> b/Documentation/devicetree/bindings/usb/fcs,fusb302.txt
>>> index 472facfa5a71..63d639eadacd 100644
>>> --- a/Documentation/devicetree/bindings/usb/fcs,fusb302.txt
>>> +++ b/Documentation/devicetree/bindings/usb/fcs,fusb302.txt
>>> @@ -6,6 +6,9 @@ Required properties :
>>> - interrupts : Interrupt specifier
>>>   Optional properties :
>>> +- mux-controls   : List of mux-ctrl-specifiers containing 1 or
>>> 2
>>> muxes
>>> +- mux-names  : "type-c-mode-mux" when using 1 mux, or
>>> +   "type-c-mode-mux", "usb-role-mux" when
>>> using
>>> 2 muxes
>>
>>
>>
>> I'm not sure this is the right place for this. The mux is outside the
>> FUSB302. In a type-C connector node or USB phy node would make more
>> sense to me.
>
>
>
> The mux certainly does not belong in the USB phy node, it sits between
> the
> USB PHY
> and the Type-C connector and can for example also mux the Type-C pins to
> a
> Display
> Port PHY.


 Thinking about this some more, the mux(es) should be its own node(s).
 Then the question is where to put the nodes.
>>>
>>>
>>> Right, the mux will be its own node per
>>> Documentation/devicetree/bindings/mux/mux-controller.txt
>>> the bindings bit this patch is adding is only adding phandles pointing
>>> to that mux-node as the fusb302 "consumes" the mux functionality.
>>>
>>> So as such (the fusb302 is the component which should control the mux)
>>> I do believe that the bindings this patch adds are correct.
>>
>> Humm, that's not how the mux binding works. The mux controller is what
>> drives the mux select lines and is the provider. The consumer is the
>> mux device itself. What decides the mux state is determined by what
>> you are muxing, not which node has mux-controls property.
>>
>> By putting mux-controls in fusb302 node, you are saying fusb302 is a
>> mux (or contains a mux).
>>
>>
> As for putting it in a type-C connector node, currently we do not have
> such
> a node,


 Well, you should. Type-C connectors are certainly complicated enough
 that we'll need one. Plus we already require connector nodes for
 display outputs, so what do we do once you add display muxing?
>>>
>>>
>>> An interesting question, I'm working on this for x86 + ACPI boards actually,
>>> not a board using DT I've been adding DT bindings docs for device-properties
>>> I use because that seems like the right thing to do where the binding is
>>> obvious
>>> (which I believe it is in this case as the fusb302 is the mux consumer) and
>>> because the device-property code should work the same on x86 + ACPI
>>> (where some platform-specific drivers attach the device properties) and
>>> on e.g. ARM + DT.
>>>
>>> The rest should probably be left to be figured out when an actual DT
>>> using device using the fusb302 or another Type-C controller shows up.
>>
>> Well this is a new one (maybe, I suppose others have sneaked by). If
>> ACPI folks want to use DT bindings, then what do I care. But I have no
>> interest in reviewing ACPI properties. The whole notion of sharing
>> bindings between DT and ACPI beyond anything trivial is flawed IMO.
>> The ptifalls have been discussed multiple times before, so I'm not
>> going to repeat them here.
> 
> Ok, so shall I just drop the 
> Documentation/devicetree/bindings/usb/fcs,fusb302.txt
> part of this patch then ?

I totally agree with the concern that Rob expressed about handling USB C
muxes in a non-adhoc way. And this makes this series scary. I don't know
enough details about USB C muxes and PD (I just have a very superficial
mental model) to tell if this series is going down the right path. Or
how terrib

Re: [PATCH v2][for 4.14] xhci: allow TRACE to work with EVENT ring dequeue

2017-09-25 Thread Mathias Nyman 

On 22.09.2017 22:55, Adam Wallis wrote:

inc_deq() currently bails earlier for EVENT rings than the common return
point of the function, due to the fact that EVENT rings do not have
link TRBs. The unfortunate side effect of this is that the very useful
trace_xhci_inc_deq() function is not called/usable for EVENT ring
debug.


True, makes sense to trace the event ring deq ptr as well.



This patch provides a refactor by removing the multiple return exit
points into a single return which additionally allows for all rings to
use the trace function.

Signed-off-by: Adam Wallis 
---
Changes in v2: undo accidental line removal at end of patch

  drivers/usb/host/xhci-ring.c | 32 
  1 file changed, 16 insertions(+), 16 deletions(-)

diff --git a/drivers/usb/host/xhci-ring.c b/drivers/usb/host/xhci-ring.c
index a944365..3960ba9 100644
--- a/drivers/usb/host/xhci-ring.c
+++ b/drivers/usb/host/xhci-ring.c
@@ -171,23 +171,23 @@ static void inc_deq(struct xhci_hcd *xhci, struct 
xhci_ring *ring)
if (ring->type == TYPE_EVENT) {
if (!last_trb_on_seg(ring->deq_seg, ring->dequeue)) {
ring->dequeue++;
-   return;
+   } else {
+   if (last_trb_on_ring(ring, ring->deq_seg,
+   ring->dequeue))
+   ring->cycle_state ^= 1;
+   ring->deq_seg = ring->deq_seg->next;
+   ring->dequeue = ring->deq_seg->trbs;
+   }
+   } else {
+   /* All other rings have link trbs */
+   if (!trb_is_link(ring->dequeue)) {
+   ring->dequeue++;
+   ring->num_trbs_free++;
+   }
+   while (trb_is_link(ring->dequeue)) {
+   ring->deq_seg = ring->deq_seg->next;
+   ring->dequeue = ring->deq_seg->trbs;


The added level of indentation makes it a little bit messier.
How about just using goto out; instead of return?

out:
trace_xhci_inc_deq(ring);

-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: Fibocom L831-EAU and cdc_mbim

2017-09-25 Thread Oliver Neukum 
Am Freitag, den 22.09.2017, 20:23 +0200 schrieb Bjørn Mork :
> Sounds good.  Ideally we should also get it tested with lots of other
> devices.  But the only way I know of to make that happen is by pushing
> the patch into mainline and stable kernels. I'll do some minimal testing
> myself for a while and then submit.

Hi,

I think you picked the right approach. We have to deal with real
hardware and you do that.

Regards
Oliver

--
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: uas: fix bug in handling of alternate settings

2017-09-25 Thread Oliver Neukum 
Am Freitag, den 22.09.2017, 11:56 -0400 schrieb Alan Stern:
> The uas driver has a subtle bug in the way it handles alternate
> settings.  The uas_find_uas_alt_setting() routine returns an
> altsetting value (the bAlternateSetting number in the descriptor), but
> uas_use_uas_driver() then treats that value as an index to the
> intf->altsetting array, which it isn't.

Hi,

thanks for doing this.

Regards
Oliver

--
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: Type-C port on the Asmedia ASM1142

2017-09-25 Thread Greg KH 
On Mon, Sep 25, 2017 at 05:29:10PM +1000, Will wrote:
> Hello,
> 
> Basically I'm just sending this to see if anyone can confirm whether
> they can get SuperSpeed devices working properly through the Type-C port
> on an Asmedia ASM1142 controller with Linux (i've tried even with latest
> usb-next branch)
> 
> Any device I use with the cable I have is only able to work at
> HighSpeed. So I am wondering if the problem is with the cable or the
> controller/driver.
> 
> I have tested on 2 different PCIe cards and on an integrated Skylake
> system.

What does the kernel logs say when you plug in the device?  And what
kernel versions have you tried?

thanks,

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

Issue with Gadget UVC and dummy_hcd

2017-09-25 Thread David Tulloh 
Hi,

I have been trying to get a UVC gadget running through configfs and
wired in to dummy_hcd.

I have largely been following the instructions from the Tizen wiki.
https://wiki.tizen.org/USB/Linux_USB_Layers/Configfs_Composite_Gadget/Usage_eq._to_g_webcam.ko

However I am getting a hard lockup, I believe when device is started.
The system does not respond to any commands, including SYSRQ.

A bash script I have been executing to set it all up is attached, as is the log.

I am running in a VM against v4.14-rc2. I have the same issues with
v4.13 and with the recent setup_timer() patch set. The v4.10 kernel
had other issues which have since been corrected.

The last log lines are:
+ echo dummy_udc.0
[   92.086000] udc dummy_udc.0: registering UDC driver [g1]
[   92.086620] configfs-gadget gadget: adding 'uvc'/9f6ab8a965f0
to config 'c'/9f6aba715520
[   92.087544] configfs-gadget gadget: uvc_function_bind
[   92.089110] dummy_hcd dummy_hcd.0: port status 0x00010101 has changes
~~~ end of transmission ~~~


Is there anything obvious that I have done wrong or an area I should
start looking?

I have very little kernel experience but am happy to poke at things
with GDB like a small child until something happens. However with the
size of the code base I would appreciate some pointers on where to
start poking.


David
root@vm:~# bash /host/gen_video_cfg.sh 
+ echo -n 'module dummy_hcd +p'
+ echo -n 'file *usb* +p'
+ echo -n 'file *gadget* +p'
+ echo -n 'file *uvc* +p'
+ echo -n 'file *video* +p'
+ echo -n 'file *v4l* +p'
+ echo 8
+ modprobe libcomposite
+ mkdir -p cfg
+ /bin/mountpoint -q cfg
+ mount none cfg -t configfs
+ mkdir -p cfg/usb_gadget/g1
+ cd cfg/usb_gadget/g1
+ echo 0x2323
+ echo 0x1234
+ mkdir -p strings/0x409
+ echo SERIAL
+ echo MANUFACTURER
+ echo PRODUCT
+ mkdir -p configs/c.1
+ mkdir -p configs/c.1/strings/0x409
+ echo 120
+ mkdir -p functions/uvc.usb0/streaming/uncompressed/u/360p
[   92.045271] media: Linux media interface: v0.10
[   92.048644] Linux video capture interface: v2.00
+ cd functions/uvc.usb0
+ cat
+ mkdir streaming/header/h
+ ln -s streaming/header/h streaming/class/fs
+ ln -s streaming/header/h streaming/class/hs
+ ln -s streaming/header/h streaming/class/ss
+ mkdir control/header/h
+ ln -s control/header/h control/class/fs
+ ln -s control/header/h control/class/ss
+ cd ../..
+ ln -s functions/uvc.usb0 configs/c.1
+ modprobe dummy_hcd
[   92.065166] dummy_hcd dummy_hcd.0: USB Host+Gadget Emulator, driver 02 May 
2005
[   92.066078] dummy_hcd dummy_hcd.0: Dummy host controller
[   92.066686] dummy_hcd dummy_hcd.0: new USB bus registered, assigned bus 
number 5
[   92.067520] usb usb5: default language 0x0409
[   92.068015] usb usb5: udev 1, busnum 5, minor = 512
[   92.068540] usb usb5: New USB device found, idVendor=1d6b, idProduct=0002
[   92.069259] usb usb5: New USB device strings: Mfr=3, Product=2, 
SerialNumber=1
[   92.070055] usb usb5: Product: Dummy host controller
[   92.070586] usb usb5: Manufacturer: Linux 4.14.0-rc2+ dummy_hcd
[   92.071212] usb usb5: SerialNumber: dummy_hcd.0
[   92.073127] usb usb5: usb_probe_device
[   92.073565] usb usb5: configuration #1 chosen from 1 choice
[   92.074522] usb usb5: adding 5-0:1.0 (config #1, interface 0)
[   92.075945] hub 5-0:1.0: usb_probe_interface
[   92.076423] hub 5-0:1.0: usb_probe_interface - got id
[   92.076969] hub 5-0:1.0: USB hub found
[   92.077420] hub 5-0:1.0: 1 port detected
[   92.078357] hub 5-0:1.0: standalone hub
[   92.078780] hub 5-0:1.0: individual port power switching
[   92.079347] hub 5-0:1.0: global over-current protection
[   92.079908] hub 5-0:1.0: Single TT
[   92.080277] hub 5-0:1.0: TT requires at most 8 FS bit times (666 ns)
[   92.080948] hub 5-0:1.0: power on to power good time: 0ms
[   92.081585] hub 5-0:1.0: local power source is good
[   92.082131] hub 5-0:1.0: no over-current condition exists
[   92.083422] hub 5-0:1.0: enabling power on all ports
+ echo dummy_udc.0
[   92.086000] udc dummy_udc.0: registering UDC driver [g1]
[   92.086620] configfs-gadget gadget: adding 'uvc'/9f6ab8a965f0 to config 
'c'/9f6aba715520
[   92.087544] configfs-gadget gadget: uvc_function_bind
[   92.089110] dummy_hcd dummy_hcd.0: port status 0x00010101 has changes




gen_video_cfg.sh
Description: Bourne shell script

Re: [PATCH v2 3/9] clk: at91: pmc: Support backup for programmable clocks

2017-09-25 Thread Romain Izard 
2017-09-22 12:31 GMT+02:00 Nicolas Ferre :
> On 15/09/2017 at 16:04, Romain Izard wrote:
>> From: Romain Izard 
>>
>> When an AT91 programmable clock is declared in the device tree, register
>> it into the Power Management Controller driver. On entering suspend mode,
>> the driver saves and restores the Programmable Clock registers to support
>> the backup mode for these clocks.
>>
>> Signed-off-by: Romain Izard 
>
> Romain,
>
> Some nitpicking and one comment. But on the overall patch, here is my:
> Acked-by: Nicolas Ferre 
>
> See below:
>
>> ---
>> Changes in v2:
>> * register PCKs on clock startup
>>
>>  drivers/clk/at91/clk-programmable.c |  2 ++
>>  drivers/clk/at91/pmc.c  | 27 +++
>>  drivers/clk/at91/pmc.h  |  2 ++
>>  3 files changed, 31 insertions(+)
>>
>> diff --git a/drivers/clk/at91/clk-programmable.c 
>> b/drivers/clk/at91/clk-programmable.c
>> index 85a449cf61e3..0e6aab1252fc 100644
>> --- a/drivers/clk/at91/clk-programmable.c
>> +++ b/drivers/clk/at91/clk-programmable.c
>> @@ -204,6 +204,8 @@ at91_clk_register_programmable(struct regmap *regmap,
>>   if (ret) {
>>   kfree(prog);
>>   hw = ERR_PTR(ret);
>
> Nit: "else" not needed.
>
This is a shared idiom in all the atmel clock drivers, so I prefer to keep
it this way.

>> + } else {
>> + pmc_register_pck(id);
>>   }
>>
>>   return hw;
>> diff --git a/drivers/clk/at91/pmc.c b/drivers/clk/at91/pmc.c
>> index 07dc2861ad3f..3910b7537152 100644
>> --- a/drivers/clk/at91/pmc.c
>> +++ b/drivers/clk/at91/pmc.c
>> @@ -22,6 +22,7 @@
>>  #include "pmc.h"
>>
>>  #define PMC_MAX_IDS 128
>> +#define PMC_MAX_PCKS 8
>>
>>  int of_at91_get_clk_range(struct device_node *np, const char *propname,
>> struct clk_range *range)
>> @@ -50,6 +51,7 @@ EXPORT_SYMBOL_GPL(of_at91_get_clk_range);
>>  static struct regmap *pmcreg;
>>
>>  static u8 registered_ids[PMC_MAX_IDS];
>> +static u8 registered_pcks[PMC_MAX_PCKS];
>>
>>  static struct
>>  {
>> @@ -66,8 +68,10 @@ static struct
>>   u32 pcr[PMC_MAX_IDS];
>>   u32 audio_pll0;
>>   u32 audio_pll1;
>> + u32 pckr[PMC_MAX_PCKS];
>>  } pmc_cache;
>>
>> +/* Clock ID 0 is invalid */
>
> (read: so we can use the 0 value as an indicator that this place in the
> table hasn't been filled, so unused)
>
>>  void pmc_register_id(u8 id)
>>  {
>>   int i;
>> @@ -82,6 +86,21 @@ void pmc_register_id(u8 id)
>>   }
>>  }
>>
>> +/* Programmable Clock 0 is valid */
>
> I understand the rationale behind these ^^ two comments, but I would
> like that it's more explicit. Saying that you will store the pck id as
> (id + 1) and that you would have to invert this operation while using
> the stored id.
> Maybe add a comment about this transformation to the struct definition
> as well...
>

I will improve the comments for the next revision.

>
>> +void pmc_register_pck(u8 pck)
>> +{
>> + int i;
>> +
>> + for (i = 0; i < PMC_MAX_PCKS; i++) {
>> + if (registered_pcks[i] == 0) {
>> + registered_pcks[i] = pck + 1;
>> + break;
>> + }
>> + if (registered_pcks[i] == (pck + 1))
>> + break;
>> + }
>> +}
>> +
>>  static int pmc_suspend(void)
>>  {
>>   int i;
>> @@ -103,6 +122,10 @@ static int pmc_suspend(void)
>>   regmap_read(pmcreg, AT91_PMC_PCR,
>>   &pmc_cache.pcr[registered_ids[i]]);
>>   }
>> + for (i = 0; registered_pcks[i]; i++) {
>> + u8 num = registered_pcks[i] - 1;
>
> Nit: declaration are better made at the beginning of the function. This
> lead to a checkpatch warning:
> "WARNING: Missing a blank line after declarations"
>

I'll fix this as well.

>> + regmap_read(pmcreg, AT91_PMC_PCKR(num), &pmc_cache.pckr[num]);
>> + }
>>
>>   return 0;
>>  }
>> @@ -143,6 +166,10 @@ static void pmc_resume(void)
>>pmc_cache.pcr[registered_ids[i]] |
>>AT91_PMC_PCR_CMD);
>>   }
>> + for (i = 0; registered_pcks[i]; i++) {
>> + u8 num = registered_pcks[i] - 1;
>
> Ditto
>
>> + regmap_write(pmcreg, AT91_PMC_PCKR(num), pmc_cache.pckr[num]);
>> + }
>>
>>   if (pmc_cache.uckr & AT91_PMC_UPLLEN)
>>   mask |= AT91_PMC_LOCKU;
>> diff --git a/drivers/clk/at91/pmc.h b/drivers/clk/at91/pmc.h
>> index 858e8ef7e8db..d22b1fa9ecdc 100644
>> --- a/drivers/clk/at91/pmc.h
>> +++ b/drivers/clk/at91/pmc.h
>> @@ -31,8 +31,10 @@ int of_at91_get_clk_range(struct device_node *np, const 
>> char *propname,
>>
>>  #ifdef CONFIG_PM
>>  void pmc_register_id(u8 id);
>> +void pmc_register_pck(u8 pck);
>>  #else
>>  static inline void pmc_register_id(u8 id) {}
>> +static inline void pmc_register_pck(u8 pck) {}
>>  #endif
>>
>>  #endif /* __PMC_H_ */
>>

-- 
Romain Izard
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a

Re: [PATCH v6] xhci : AMD Promontory USB disable port support

2017-09-25 Thread Mathias Nyman 

On 25.09.2017 10:08, Joe Lee wrote:

From: Joe Lee 

For AMD Promontory xHCI host,
although you can disable USB 2.0 ports in BIOSsettings,
those ports will be enabled anyway after you remove a device on
that port and re-plug it in again. It's a known limitation of the chip.
As a workaround we can clear the PORT_WAKE_BITS.

Signed-off-by: Joe Lee 

---


Kai-Heng Feng,
Do you have the time to check if this works on your Promontory setup?

Does the usb2 ports stay alive with runtime PM enabled after this patch?

Thanks
-Mathias



v6: Fix coding format.
v5: Add check disable port setting before set PORT_WAKE_BITS
v4: Remove the patch code in case USB_PORT_FEAT_REMOTE_WAKE_MASK
v3: Fix some checkpatch.pl
---
  drivers/usb/host/pci-quirks.c | 116 +-
  drivers/usb/host/pci-quirks.h |   1 +
  drivers/usb/host/xhci-hub.c   |   7 ++-
  3 files changed, 121 insertions(+), 3 deletions(-)

diff --git a/drivers/usb/host/pci-quirks.c b/drivers/usb/host/pci-quirks.c
index 658d9d1..934220c 100644
--- a/drivers/usb/host/pci-quirks.c
+++ b/drivers/usb/host/pci-quirks.c
@@ -64,7 +64,22 @@
  #define   AB_DATA(addr)   ((addr) + 0x04)
  #define   AX_INDXC0x30
  #define   AX_DATAC0x34
-
+#define PT_ADDR_INDEX  0xE8
+#define PT_READ_INDEX  0xE4
+#define PT_SIG_1_ADDR  0xA520
+#define PT_SIG_2_ADDR  0xA521
+#define PT_SIG_3_ADDR  0xA522
+#define PT_SIG_4_ADDR  0xA523
+#define PT_SIG_1_DATA  0x78
+#define PT_SIG_2_DATA  0x56
+#define PT_SIG_3_DATA  0x34
+#define PT_SIG_4_DATA  0x12
+#define PT_4_PORT_1_REG0xB521
+#define PT_4_PORT_2_REG0xB522
+#define PT_2_PORT_1_REG0xD520
+#define PT_2_PORT_2_REG0xD521
+#define PT_1_PORT_1_REG0xD522
+#define PT_1_PORT_2_REG0xD523
  #define   NB_PCIE_INDX_ADDR   0xe0
  #define   NB_PCIE_INDX_DATA   0xe4
  #define   PCIE_P_CNTL 0x10040
@@ -511,6 +526,105 @@ void usb_amd_dev_put(void)
  }
  EXPORT_SYMBOL_GPL(usb_amd_dev_put);

+int usb_amd_pt_check_port(struct device *device, int port)
+{
+   unsigned char value;
+   struct pci_dev *pdev;
+
+   pdev = to_pci_dev(device);
+   pci_write_config_word(pdev, PT_ADDR_INDEX, PT_SIG_1_ADDR);
+   pci_read_config_byte(pdev, PT_READ_INDEX, &value);
+   if (value != PT_SIG_1_DATA)
+   return 0;
+   pci_write_config_word(pdev, PT_ADDR_INDEX, PT_SIG_2_ADDR);
+   pci_read_config_byte(pdev, PT_READ_INDEX, &value);
+   if (value != PT_SIG_2_DATA)
+   return 0;
+   pci_write_config_word(pdev, PT_ADDR_INDEX, PT_SIG_3_ADDR);
+   pci_read_config_byte(pdev, PT_READ_INDEX, &value);
+   if (value != PT_SIG_3_DATA)
+   return 0;
+   pci_write_config_word(pdev, PT_ADDR_INDEX, PT_SIG_4_ADDR);
+   pci_read_config_byte(pdev, PT_READ_INDEX, &value);
+   if (value != PT_SIG_4_DATA)
+   return 0;
+   if ((pdev->device == 0x43b9) || (pdev->device == 0x43ba)) {
+   /* device is AMD_PROMONTORYA_4(0x43b9) or
+* PROMONTORYA_3(0x43ba)
+* disable port setting PT_4_PORT_1_REG[7..1] is
+* USB2.0 port6 to 0
+* PT_4_PORT_2_REG[6..0] is USB 13 to port 7
+* 0 : disable ;1 : enable
+*/
+   if (port > 6) {
+   pci_write_config_word(pdev, PT_ADDR_INDEX,
+   PT_4_PORT_2_REG);
+   pci_read_config_byte(pdev, PT_READ_INDEX, &value);
+   if (value & (1<<(port - 7)))
+   return 0;
+   else
+   return 1;
+   } else {
+   pci_write_config_word(pdev, PT_ADDR_INDEX,
+   PT_4_PORT_1_REG);
+   pci_read_config_byte(pdev, PT_READ_INDEX, &value);
+   if (value & (1<<(port + 1)))
+   return 0;
+   else
+   return 1;
+   }
+   } else if (pdev->device == 0x43bb) {
+   /* device is AMD_PROMONTORYA_2(0x43bb)
+* disable port setting PT_2_PORT_1_REG[7..5] is
+* USB2.0 port2 to
+* PT_2_PORT_2_REG[5..0] is USB9 to port3
+* 0 : disable ;1 : enable
+*/
+   if (port > 2) {
+   pci_write_config_word(pdev, PT_ADDR_INDEX,
+   PT_2_PORT_2_REG);
+   pci_read_config_byte(pdev, PT_READ_INDEX, &value);
+   if (value & (1<<(port - 3)))
+   return 0;
+   e

[PATCH 3/3] usb: gadget: udc: renesas_usb3: Fix return value of usb3_write_pipe()

2017-09-25 Thread Yoshihiro Shimoda 
This patch fixes an issue that this driver cannot go status stage
in control read when the req.zero is set to 1 and the len in
usb3_write_pipe() is set to 0. Otherwise, if we use g_ncm driver,
usb enumeration takes long time (5 seconds or more).

Fixes: 746bfe63bba3 ("usb: gadget: renesas_usb3: add support for Renesas USB3.0 
peripheral controller")
Cc:  # v4.5+
Signed-off-by: Yoshihiro Shimoda 
---
 drivers/usb/gadget/udc/renesas_usb3.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/drivers/usb/gadget/udc/renesas_usb3.c 
b/drivers/usb/gadget/udc/renesas_usb3.c
index 7e0c534..63a2061 100644
--- a/drivers/usb/gadget/udc/renesas_usb3.c
+++ b/drivers/usb/gadget/udc/renesas_usb3.c
@@ -1038,7 +1038,7 @@ static int usb3_write_pipe(struct renesas_usb3_ep 
*usb3_ep,
usb3_ep->ep.maxpacket);
u8 *buf = usb3_req->req.buf + usb3_req->req.actual;
u32 tmp = 0;
-   bool is_last;
+   bool is_last = !len ? true : false;
 
if (usb3_wait_pipe_status(usb3_ep, PX_STA_BUFSTS) < 0)
return -EBUSY;
@@ -1059,7 +1059,8 @@ static int usb3_write_pipe(struct renesas_usb3_ep 
*usb3_ep,
usb3_write(usb3, tmp, fifo_reg);
}
 
-   is_last = usb3_is_transfer_complete(usb3_ep, usb3_req);
+   if (!is_last)
+   is_last = usb3_is_transfer_complete(usb3_ep, usb3_req);
/* Send the data */
usb3_set_px_con_send(usb3_ep, len, is_last);
 
-- 
1.9.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

[PATCH 2/3] usb: gadget: udc: renesas_usb3: fix Pn_RAMMAP.Pn_MPKT value

2017-09-25 Thread Yoshihiro Shimoda 
According to the datasheet of R-Car Gen3, the Pn_RAMMAP.Pn_MPKT should
be set to one of 8, 16, 32, 64, 512 and 1024. Otherwise, when a gadget
driver uses an interrupt endpoint, unexpected behavior happens. So,
this patch fixes it.

Fixes: 746bfe63bba3 ("usb: gadget: renesas_usb3: add support for Renesas USB3.0 
peripheral controller")
Cc:  # v4.5+
Signed-off-by: Yoshihiro Shimoda 
---
 drivers/usb/gadget/udc/renesas_usb3.c | 11 ++-
 1 file changed, 10 insertions(+), 1 deletion(-)

diff --git a/drivers/usb/gadget/udc/renesas_usb3.c 
b/drivers/usb/gadget/udc/renesas_usb3.c
index 555c105..7e0c534 100644
--- a/drivers/usb/gadget/udc/renesas_usb3.c
+++ b/drivers/usb/gadget/udc/renesas_usb3.c
@@ -2054,7 +2054,16 @@ static u32 usb3_calc_ramarea(int ram_size)
 static u32 usb3_calc_rammap_val(struct renesas_usb3_ep *usb3_ep,
const struct usb_endpoint_descriptor *desc)
 {
-   return usb3_ep->rammap_val | PN_RAMMAP_MPKT(usb_endpoint_maxp(desc));
+   int i;
+   const u32 max_packet_array[] = {8, 16, 32, 64, 512};
+   u32 mpkt = PN_RAMMAP_MPKT(1024);
+
+   for (i = 0; i < ARRAY_SIZE(max_packet_array); i++) {
+   if (usb_endpoint_maxp(desc) <= max_packet_array[i])
+   mpkt = PN_RAMMAP_MPKT(max_packet_array[i]);
+   }
+
+   return usb3_ep->rammap_val | mpkt;
 }
 
 static int usb3_enable_pipe_n(struct renesas_usb3_ep *usb3_ep,
-- 
1.9.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

[PATCH 0/3] usb: gadget: udc: renesas_usb3: bugfix for v4.14

2017-09-25 Thread Yoshihiro Shimoda 
This patch set is based on the Felipe's usb.git / testing/fixes branch
(The commit is 7661ca09b2ff98f48693f431bb01fed62830e433).

Yoshihiro Shimoda (3):
  usb: gadget: udc: renesas_usb3: fix for no-data control transfer
  usb: gadget: udc: renesas_usb3: fix Pn_RAMMAP.Pn_MPKT value
  usb: gadget: udc: renesas_usb3: Fix return value of usb3_write_pipe()

 drivers/usb/gadget/udc/renesas_usb3.c | 19 +++
 1 file changed, 15 insertions(+), 4 deletions(-)

-- 
1.9.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

[PATCH 1/3] usb: gadget: udc: renesas_usb3: fix for no-data control transfer

2017-09-25 Thread Yoshihiro Shimoda 
When bRequestType & USB_DIR_IN is false and req.length is 0 in control
transfer, since it means non-data, this driver should not set the mode
as control write. So, this patch fixes it.

Fixes: 746bfe63bba3 ("usb: gadget: renesas_usb3: add support for Renesas USB3.0 
peripheral controller")
Cc:  # v4.5+
Signed-off-by: Yoshihiro Shimoda 
---
 drivers/usb/gadget/udc/renesas_usb3.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/usb/gadget/udc/renesas_usb3.c 
b/drivers/usb/gadget/udc/renesas_usb3.c
index df37c1e..555c105 100644
--- a/drivers/usb/gadget/udc/renesas_usb3.c
+++ b/drivers/usb/gadget/udc/renesas_usb3.c
@@ -1150,7 +1150,8 @@ static void usb3_start_pipe0(struct renesas_usb3_ep 
*usb3_ep,
usb3_set_p0_con_for_ctrl_read_data(usb3);
} else {
usb3_clear_bit(usb3, P0_MOD_DIR, USB3_P0_MOD);
-   usb3_set_p0_con_for_ctrl_write_data(usb3);
+   if (usb3_req->req.length)
+   usb3_set_p0_con_for_ctrl_write_data(usb3);
}
 
usb3_p0_xfer(usb3_ep, usb3_req);
-- 
1.9.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

Type-C port on the Asmedia ASM1142

2017-09-25 Thread Will 
Hello,

Basically I'm just sending this to see if anyone can confirm whether
they can get SuperSpeed devices working properly through the Type-C port
on an Asmedia ASM1142 controller with Linux (i've tried even with latest
usb-next branch)

Any device I use with the cable I have is only able to work at
HighSpeed. So I am wondering if the problem is with the cable or the
controller/driver.

I have tested on 2 different PCIe cards and on an integrated Skylake
system.


Regards,

Will
--
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] usb: typec: driver for TI TPS6598x USB Power Delivery controllers

2017-09-25 Thread Heikki Krogerus 
Driver for TI TPS65982, TPS65983 and other TPS6598x family
stand alone USB Power Delivery controllers.

The driver will at this stage only register the port and
partners attached to it, so cables and alternate modes are
not yet registered. Both power and data role swapping is
supported.

Signed-off-by: Heikki Krogerus 
---
 drivers/usb/typec/Kconfig|  11 +
 drivers/usb/typec/Makefile   |   1 +
 drivers/usb/typec/tps6598x.c | 475 +++
 3 files changed, 487 insertions(+)
 create mode 100644 drivers/usb/typec/tps6598x.c

diff --git a/drivers/usb/typec/Kconfig b/drivers/usb/typec/Kconfig
index 103cb8bce3e7..465d7da849c3 100644
--- a/drivers/usb/typec/Kconfig
+++ b/drivers/usb/typec/Kconfig
@@ -35,4 +35,15 @@ endif
 
 source "drivers/usb/typec/ucsi/Kconfig"
 
+config TYPEC_TPS6598X
+   tristate "TI TPS6598x USB Power Delivery controller driver"
+   depends on I2C
+   select TYPEC
+   help
+ Say Y or M here if your system has TI TPS65982 or TPS65983 USB Power
+ Delivery controller.
+
+ If you choose to build this driver as a dynamically linked module, the
+ module will be called tps6598x.ko.
+
 endmenu
diff --git a/drivers/usb/typec/Makefile b/drivers/usb/typec/Makefile
index b77688ce1f16..6be5e161ac2b 100644
--- a/drivers/usb/typec/Makefile
+++ b/drivers/usb/typec/Makefile
@@ -3,3 +3,4 @@ obj-$(CONFIG_TYPEC_TCPM)+= tcpm.o
 obj-y  += fusb302/
 obj-$(CONFIG_TYPEC_WCOVE)  += typec_wcove.o
 obj-$(CONFIG_TYPEC_UCSI)   += ucsi/
+obj-$(CONFIG_TYPEC_TPS6598X)   += tps6598x.o
diff --git a/drivers/usb/typec/tps6598x.c b/drivers/usb/typec/tps6598x.c
new file mode 100644
index ..8893f7937560
--- /dev/null
+++ b/drivers/usb/typec/tps6598x.c
@@ -0,0 +1,475 @@
+/*
+ * Driver for TI TPS6598x USB Power Delivery controller family
+ *
+ * Copyright (C) 2017, Intel Corporation
+ * Author: Heikki Krogerus 
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+/* Register offsets */
+#define TPS_REG_CMD1   0x08
+#define TPS_REG_DATA1  0x09
+#define TPS_REG_INT_EVENT1 0x14
+#define TPS_REG_INT_EVENT2 0x15
+#define TPS_REG_INT_MASK1  0x16
+#define TPS_REG_INT_MASK2  0x17
+#define TPS_REG_INT_CLEAR1 0x18
+#define TPS_REG_INT_CLEAR2 0x19
+#define TPS_REG_STATUS 0x1a
+#define TPS_REG_SYSTEM_CONF0x28
+#define TPS_REG_CTRL_CONF  0x29
+#define TPS_REG_POWER_STATUS   0x3f
+#define TPS_REG_RX_IDENTITY_SOP0x48
+
+/* TPS_REG_INT_* bits */
+#define TPS_REG_INT_PLUG_EVENT BIT(3)
+
+/* TPS_REG_STATUS bits */
+#define TPS_STATUS_PLUG_PRESENTBIT(0)
+#define TPS_STATUS_ORIENTATION BIT(4)
+#define TPS_STATUS_PORTROLE(s) (!!((s) & BIT(5)))
+#define TPS_STATUS_DATAROLE(s) (!!((s) & BIT(6)))
+#define TPS_STATUS_VCONN(s)(!!((s) & BIT(7)))
+
+/* TPS_REG_SYSTEM_CONF bits */
+#define TPS_SYSCONF_PORTINFO(c)((c) & 3)
+
+enum {
+   TPS_PORTINFO_SINK,
+   TPS_PORTINFO_SINK_ACCESSORY,
+   TPS_PORTINFO_DRP_UFP,
+   TPS_PORTINFO_DRP_UFP_DRD,
+   TPS_PORTINFO_DRP_DFP,
+   TPS_PORTINFO_DRP_DFP_DRD,
+   TPS_PORTINFO_SOURCE,
+};
+
+/* TPS_REG_POWER_STATUS bits */
+#define TPS_POWER_STATUS_SOURCESINKBIT(1)
+#define TPS_POWER_STATUS_PWROPMODE(p)  (((p) & GENMASK(3, 2)) >> 2)
+
+/* TPS_REG_RX_IDENTITY_SOP */
+struct tps6598x_rx_identity_reg {
+   u8 status;
+   struct usb_pd_identity identity;
+   u32 vdo[3];
+} __packed;
+
+/* Standard Task return codes */
+#define TPS_TASK_TIMEOUT   1
+#define TPS_TASK_REJECTED  3
+
+/* Unrecognized commands will be replaced with "!CMD" */
+#define INVALID_CMD(_cmd_) (_cmd_ == 0x444d4321)
+
+struct tps6598x {
+   struct device *dev;
+   struct regmap *regmap;
+   struct mutex lock; /* device lock */
+
+   struct typec_port *port;
+   struct typec_partner *partner;
+   struct usb_pd_identity partner_identity;
+   struct typec_capability typec_cap;
+};
+
+static inline int tps6598x_read16(struct tps6598x *tps, u8 reg, u16 *val)
+{
+   return regmap_raw_read(tps->regmap, reg, val, sizeof(u16));
+}
+
+static inline int tps6598x_read32(struct tps6598x *tps, u8 reg, u32 *val)
+{
+   return regmap_raw_read(tps->regmap, reg, val, sizeof(u32));
+}
+
+static inline int tps6598x_read64(struct tps6598x *tps, u8 reg, u64 *val)
+{
+   return regmap_raw_read(tps->regmap, reg, val, sizeof(u64));
+}
+
+static inline int tps6598x_write16(struct tps6598x *tps, u8 reg, u16 val)
+{
+   return regmap_raw_write(tps->regmap, reg, &val, sizeof(u16

[PATCH v6] xhci : AMD Promontory USB disable port support

2017-09-25 Thread Joe Lee 
From: Joe Lee 

For AMD Promontory xHCI host,
although you can disable USB 2.0 ports in BIOSsettings,
those ports will be enabled anyway after you remove a device on
that port and re-plug it in again. It's a known limitation of the chip.
As a workaround we can clear the PORT_WAKE_BITS.

Signed-off-by: Joe Lee 

---
v6: Fix coding format.
v5: Add check disable port setting before set PORT_WAKE_BITS
v4: Remove the patch code in case USB_PORT_FEAT_REMOTE_WAKE_MASK
v3: Fix some checkpatch.pl
---
 drivers/usb/host/pci-quirks.c | 116 +-
 drivers/usb/host/pci-quirks.h |   1 +
 drivers/usb/host/xhci-hub.c   |   7 ++-
 3 files changed, 121 insertions(+), 3 deletions(-)

diff --git a/drivers/usb/host/pci-quirks.c b/drivers/usb/host/pci-quirks.c
index 658d9d1..934220c 100644
--- a/drivers/usb/host/pci-quirks.c
+++ b/drivers/usb/host/pci-quirks.c
@@ -64,7 +64,22 @@
 #defineAB_DATA(addr)   ((addr) + 0x04)
 #defineAX_INDXC0x30
 #defineAX_DATAC0x34
-
+#define PT_ADDR_INDEX  0xE8
+#define PT_READ_INDEX  0xE4
+#define PT_SIG_1_ADDR  0xA520
+#define PT_SIG_2_ADDR  0xA521
+#define PT_SIG_3_ADDR  0xA522
+#define PT_SIG_4_ADDR  0xA523
+#define PT_SIG_1_DATA  0x78
+#define PT_SIG_2_DATA  0x56
+#define PT_SIG_3_DATA  0x34
+#define PT_SIG_4_DATA  0x12
+#define PT_4_PORT_1_REG0xB521
+#define PT_4_PORT_2_REG0xB522
+#define PT_2_PORT_1_REG0xD520
+#define PT_2_PORT_2_REG0xD521
+#define PT_1_PORT_1_REG0xD522
+#define PT_1_PORT_2_REG0xD523
 #defineNB_PCIE_INDX_ADDR   0xe0
 #defineNB_PCIE_INDX_DATA   0xe4
 #definePCIE_P_CNTL 0x10040
@@ -511,6 +526,105 @@ void usb_amd_dev_put(void)
 }
 EXPORT_SYMBOL_GPL(usb_amd_dev_put);
 
+int usb_amd_pt_check_port(struct device *device, int port)
+{
+   unsigned char value;
+   struct pci_dev *pdev;
+
+   pdev = to_pci_dev(device);
+   pci_write_config_word(pdev, PT_ADDR_INDEX, PT_SIG_1_ADDR);
+   pci_read_config_byte(pdev, PT_READ_INDEX, &value);
+   if (value != PT_SIG_1_DATA)
+   return 0;
+   pci_write_config_word(pdev, PT_ADDR_INDEX, PT_SIG_2_ADDR);
+   pci_read_config_byte(pdev, PT_READ_INDEX, &value);
+   if (value != PT_SIG_2_DATA)
+   return 0;
+   pci_write_config_word(pdev, PT_ADDR_INDEX, PT_SIG_3_ADDR);
+   pci_read_config_byte(pdev, PT_READ_INDEX, &value);
+   if (value != PT_SIG_3_DATA)
+   return 0;
+   pci_write_config_word(pdev, PT_ADDR_INDEX, PT_SIG_4_ADDR);
+   pci_read_config_byte(pdev, PT_READ_INDEX, &value);
+   if (value != PT_SIG_4_DATA)
+   return 0;
+   if ((pdev->device == 0x43b9) || (pdev->device == 0x43ba)) {
+   /* device is AMD_PROMONTORYA_4(0x43b9) or
+* PROMONTORYA_3(0x43ba)
+* disable port setting PT_4_PORT_1_REG[7..1] is
+* USB2.0 port6 to 0
+* PT_4_PORT_2_REG[6..0] is USB 13 to port 7
+* 0 : disable ;1 : enable
+*/
+   if (port > 6) {
+   pci_write_config_word(pdev, PT_ADDR_INDEX,
+   PT_4_PORT_2_REG);
+   pci_read_config_byte(pdev, PT_READ_INDEX, &value);
+   if (value & (1<<(port - 7)))
+   return 0;
+   else
+   return 1;
+   } else {
+   pci_write_config_word(pdev, PT_ADDR_INDEX,
+   PT_4_PORT_1_REG);
+   pci_read_config_byte(pdev, PT_READ_INDEX, &value);
+   if (value & (1<<(port + 1)))
+   return 0;
+   else
+   return 1;
+   }
+   } else if (pdev->device == 0x43bb) {
+   /* device is AMD_PROMONTORYA_2(0x43bb)
+* disable port setting PT_2_PORT_1_REG[7..5] is
+* USB2.0 port2 to
+* PT_2_PORT_2_REG[5..0] is USB9 to port3
+* 0 : disable ;1 : enable
+*/
+   if (port > 2) {
+   pci_write_config_word(pdev, PT_ADDR_INDEX,
+   PT_2_PORT_2_REG);
+   pci_read_config_byte(pdev, PT_READ_INDEX, &value);
+   if (value & (1<<(port - 3)))
+   return 0;
+   else
+   return 1;
+   } else {
+   pci_write_config_word(pdev, PT_ADDR_INDEX,
+   PT_2_PORT_1_REG);
+