Re: [RFC PATCH] staging: typec: Intel WhiskeyCove PMIC USB Type-C PHY driver

[Guenter Roeck]

On 05/26/2017 11:39 AM, Greg Kroah-Hartman wrote:

On Fri, May 26, 2017 at 03:53:49PM +0300, Heikki Krogerus wrote:

Hi,

My two cents.

On Thu, May 25, 2017 at 10:12:27AM -0700, Guenter Roeck wrote:

What is keeping this code in staging at the moment?  Who isn't agreeing
on the existing apis we have there?



I don't think the APIs are at issue; I would not expect any substantial
(if any) changes going forward. We may have additions such as the pending
port type change support, but will always happen.

>From TODO:
- Add documentation (at the very least for the API to low level drivers)


This probable should be addressed.


- Split PD code into separate file


Can be done later.


- Check if it makes sense to use tracepoints instead of debugfs for debug logs


I would prefer tracepoints over custom debug logs, but if I'm the only
one, I'm OK changing it later.

I can also start working on this, but unfortunately I won't be able to
start right away. I'll be on vacation next week... Sorry for the last
minute announcement btw.


- Implement Alternate Mode handling


Can be done later.


- Address "#if 0" code if not addressed with the above
- Validate all comments marked with "XXX"; either address or remove comments


These need to be addressed.


- Add support for USB PD 3.0. While not mandatory, at least fast role swap
   as well as authentication support would be very desirable.


Can be done later.


All of these feel to me like they can be done later, as nothing is
messing with the user/kernel api, right?  (trace vs. debugfs doesn't
matter...)

So, who wants to send me the patch to write a tiny bit of documentation
and then get this out of staging?  :)


I'll try over the weekend. No promises.

Guenter
--
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: [PATCHv4] usb: typec: Add a sysfs node to manage port type

[Greg Kroah-Hartman]

On Fri, May 26, 2017 at 01:42:57PM -0700, Badhri Jagan Sridharan wrote:
> User space applications in some cases have the need to enforce a
> specific port type(DFP/UFP/DRP). This change allows userspace to
> attempt setting the desired port type. Low level drivers can
> however reject the request if the specific port type is not supported.
> 
> Signed-off-by: Badhri Jagan Sridharan 
> ---
> Changelog since v1:
> - introduced a new variable port_type in struct typec_port to track
>   the current port type instead of changing type member in
>   typec_capability to address Heikki Krogerus comments.
> - changed the output format and strings that would be displayed as
>   suggested by Heikki Krogerus.
> 
> Changelog since v2:
> - introduced a new mutex lock to protect port_type for addressing
>   the race conditions identified by Geunter Roeck
> - added typec_port_types_drp for printing port_type when cap->type
>   is TYPE_PORT_DRP as suggested by Geunter Roeck
> - Power role swap and data role swaps would be rejected unless
>   port port_type == TYPE_PORT_DRP
> - port_type_store would return immediately if the current port_type
>   is same as the new port_type as suggested by Geunter Roeck
> 
> Changelog since v3:
> - Moved as much as code outside port_type_lock as suggested by
>   Geunter Roeck
> - Removed Change-Id line from commit message identified by
>   Greg Kroah-Hartman

Ok, this is how you write a changelog for a patch, very nice job!

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

[PATCH] usb: dwc2: resume root hub to handle disconnect of device

[William Wu]

When handle disconnect of the hcd during bus_suspend, hcd
needs to resume its root hub, otherwise the root hub will
not disconnect the existing devices under its port.

This issue always happens when connecting with usb devices
which support auto-suspend function (e.g. usb hub).

Signed-off-by: William Wu 
---
 drivers/usb/dwc2/hcd.c | 12 +++-
 1 file changed, 7 insertions(+), 5 deletions(-)

diff --git a/drivers/usb/dwc2/hcd.c b/drivers/usb/dwc2/hcd.c
index 740c7e8..cc84f97 100644
--- a/drivers/usb/dwc2/hcd.c
+++ b/drivers/usb/dwc2/hcd.c
@@ -1975,11 +1975,13 @@ void dwc2_hcd_disconnect(struct dwc2_hsotg *hsotg, bool 
force)
 * Without the extra check here we will end calling disconnect
 * and won't get any future interrupts to handle the connect.
 */
-   if (!force) {
-   hprt0 = dwc2_readl(hsotg->regs + HPRT0);
-   if (!(hprt0 & HPRT0_CONNDET) && (hprt0 & HPRT0_CONNSTS))
-   dwc2_hcd_connect(hsotg);
-   }
+   hprt0 = dwc2_readl(hsotg->regs + HPRT0);
+
+   if (!force && !(hprt0 & HPRT0_CONNDET) &&
+   (hprt0 & HPRT0_CONNSTS))
+   dwc2_hcd_connect(hsotg);
+   else if (hsotg->lx_state != DWC2_L0)
+   usb_hcd_resume_root_hub(hsotg->priv);
 }
 
 /**
-- 
2.0.0


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

Re: [PATCH v4] usb: typec: Add a sysfs node to manage port type

[Guenter Roeck]

On 05/26/2017 04:07 PM, Badhri Jagan Sridharan wrote:

User space applications in some cases have the need to enforce a
specific port type(DFP/UFP/DRP). This change allows userspace to
attempt setting the desired port type. Low level drivers can
however reject the request if the specific port type is not supported.

Signed-off-by: Badhri Jagan Sridharan 
---
Changelog since v1:
- introduced a new variable port_type in struct typec_port to track
   the current port type instead of changing type member in
   typec_capability to address Heikki Krogerus comments.
- changed the output format and strings that would be displayed as
   suggested by Heikki Krogerus.

Changelog since v2:
- introduced a new mutex lock to protect port_type for addressing
   the race conditions identified by Geunter Roeck
- added typec_port_types_drp for printing port_type when cap->type
   is TYPE_PORT_DRP as suggested by Geunter Roeck
- Power role swap and data role swaps would be rejected unless
   port port_type == TYPE_PORT_DRP
- port_type_store would return immediately if the current port_type
   is same as the new port_type as suggested by Geunter Roeck

Changelog since v3:
- Moved as much as code outside port_type_lock as suggested by
   Geunter Roeck
- Removed Change-Id line from commit message identified by
   Greg Kroah-Hartman

  drivers/usb/typec/typec.c | 106 +-
  include/linux/usb/typec.h |   4 ++
  2 files changed, 100 insertions(+), 10 deletions(-)

diff --git a/drivers/usb/typec/typec.c b/drivers/usb/typec/typec.c
index 89e540bb7ff3..bf1eb11c6646 100644
--- a/drivers/usb/typec/typec.c
+++ b/drivers/usb/typec/typec.c
@@ -11,6 +11,7 @@
  
  #include 

  #include 
+#include 
  #include 
  #include 
  
@@ -69,6 +70,8 @@ struct typec_port {

enum typec_role pwr_role;
enum typec_role vconn_role;
enum typec_pwr_opmode   pwr_opmode;
+   enum typec_port_typeport_type;
+   struct mutexport_type_lock;
  
  	const struct typec_capability	*cap;

  };
@@ -789,6 +792,18 @@ static const char * const typec_data_roles[] = {
[TYPEC_HOST]= "host",
  };
  
+static const char * const typec_port_types[] = {

+   [TYPEC_PORT_DFP] = "source",
+   [TYPEC_PORT_UFP] = "sink",
+   [TYPEC_PORT_DRP] = "dual",
+};
+
+static const char * const typec_port_types_drp[] = {
+   [TYPEC_PORT_DFP] = "dual [source] sink",
+   [TYPEC_PORT_UFP] = "dual source [sink]",
+   [TYPEC_PORT_DRP] = "[dual] source sink",
+};
+
  static ssize_t
  preferred_role_store(struct device *dev, struct device_attribute *attr,
 const char *buf, size_t size)
@@ -846,11 +861,6 @@ static ssize_t data_role_store(struct device *dev,
struct typec_port *port = to_typec_port(dev);
int ret;
  
-	if (port->cap->type != TYPEC_PORT_DRP) {

-   dev_dbg(dev, "data role swap only supported with DRP ports\n");
-   return -EOPNOTSUPP;
-   }
-
if (!port->cap->dr_set) {
dev_dbg(dev, "data role swapping not supported\n");
return -EOPNOTSUPP;
@@ -860,11 +870,22 @@ static ssize_t data_role_store(struct device *dev,
if (ret < 0)
return ret;
  
+	mutex_lock(>port_type_lock);

+   if (port->port_type != TYPEC_PORT_DRP) {
+   dev_dbg(dev, "port type fixed at \"%s\"",
+typec_port_types[port->port_type]);
+   ret = -EOPNOTSUPP;
+   goto unlock_and_ret;
+   }
+
ret = port->cap->dr_set(port->cap, ret);
if (ret)
-   return ret;
+   goto unlock_and_ret;
  
-	return size;

+   ret = size;
+unlock_and_ret:
+   mutex_unlock(>port_type_lock);
+   return ret;
  }
  
  static ssize_t data_role_show(struct device *dev,

@@ -885,7 +906,7 @@ static ssize_t power_role_store(struct device *dev,
const char *buf, size_t size)
  {
struct typec_port *port = to_typec_port(dev);
-   int ret = size;
+   int ret;
  
  	if (!port->cap->pd_revision) {

dev_dbg(dev, "USB Power Delivery not supported\n");
@@ -906,11 +927,22 @@ static ssize_t power_role_store(struct device *dev,
if (ret < 0)
return ret;
  
+	mutex_lock(>port_type_lock);

+   if (port->port_type != TYPEC_PORT_DRP) {
+   dev_dbg(dev, "port type fixed at \"%s\"",
+typec_port_types[port->port_type]);
+   ret = -EOPNOTSUPP;
+   goto unlock_and_ret;
+   }
+
ret = port->cap->pr_set(port->cap, ret);
if (ret)
-   return ret;
+   goto unlock_and_ret;
  
-	return size;

+   ret = size;
+unlock_and_ret:
+   mutex_unlock(>port_type_lock);
+   return ret;
  }
  
  static ssize_t power_role_show(struct device *dev,

@@ -926,6 

[PATCHv4] usb: typec: Add a sysfs node to manage port type

[Badhri Jagan Sridharan]

User space applications in some cases have the need to enforce a
specific port type(DFP/UFP/DRP). This change allows userspace to
attempt setting the desired port type. Low level drivers can
however reject the request if the specific port type is not supported.

Signed-off-by: Badhri Jagan Sridharan 
---
Changelog since v1:
- introduced a new variable port_type in struct typec_port to track
  the current port type instead of changing type member in
  typec_capability to address Heikki Krogerus comments.
- changed the output format and strings that would be displayed as
  suggested by Heikki Krogerus.

Changelog since v2:
- introduced a new mutex lock to protect port_type for addressing
  the race conditions identified by Geunter Roeck
- added typec_port_types_drp for printing port_type when cap->type
  is TYPE_PORT_DRP as suggested by Geunter Roeck
- Power role swap and data role swaps would be rejected unless
  port port_type == TYPE_PORT_DRP
- port_type_store would return immediately if the current port_type
  is same as the new port_type as suggested by Geunter Roeck

Changelog since v3:
- Moved as much as code outside port_type_lock as suggested by
  Geunter Roeck
- Removed Change-Id line from commit message identified by
  Greg Kroah-Hartman

 drivers/usb/typec/typec.c | 106 +-
 include/linux/usb/typec.h |   4 ++
 2 files changed, 100 insertions(+), 10 deletions(-)

diff --git a/drivers/usb/typec/typec.c b/drivers/usb/typec/typec.c
index 89e540bb7ff3..bf1eb11c6646 100644
--- a/drivers/usb/typec/typec.c
+++ b/drivers/usb/typec/typec.c
@@ -11,6 +11,7 @@
 
 #include 
 #include 
+#include 
 #include 
 #include 
 
@@ -69,6 +70,8 @@ struct typec_port {
enum typec_role pwr_role;
enum typec_role vconn_role;
enum typec_pwr_opmode   pwr_opmode;
+   enum typec_port_typeport_type;
+   struct mutexport_type_lock;
 
const struct typec_capability   *cap;
 };
@@ -789,6 +792,18 @@ static const char * const typec_data_roles[] = {
[TYPEC_HOST]= "host",
 };
 
+static const char * const typec_port_types[] = {
+   [TYPEC_PORT_DFP] = "source",
+   [TYPEC_PORT_UFP] = "sink",
+   [TYPEC_PORT_DRP] = "dual",
+};
+
+static const char * const typec_port_types_drp[] = {
+   [TYPEC_PORT_DFP] = "dual [source] sink",
+   [TYPEC_PORT_UFP] = "dual source [sink]",
+   [TYPEC_PORT_DRP] = "[dual] source sink",
+};
+
 static ssize_t
 preferred_role_store(struct device *dev, struct device_attribute *attr,
 const char *buf, size_t size)
@@ -846,11 +861,6 @@ static ssize_t data_role_store(struct device *dev,
struct typec_port *port = to_typec_port(dev);
int ret;
 
-   if (port->cap->type != TYPEC_PORT_DRP) {
-   dev_dbg(dev, "data role swap only supported with DRP ports\n");
-   return -EOPNOTSUPP;
-   }
-
if (!port->cap->dr_set) {
dev_dbg(dev, "data role swapping not supported\n");
return -EOPNOTSUPP;
@@ -860,11 +870,22 @@ static ssize_t data_role_store(struct device *dev,
if (ret < 0)
return ret;
 
+   mutex_lock(>port_type_lock);
+   if (port->port_type != TYPEC_PORT_DRP) {
+   dev_dbg(dev, "port type fixed at \"%s\"",
+typec_port_types[port->port_type]);
+   ret = -EOPNOTSUPP;
+   goto unlock_and_ret;
+   }
+
ret = port->cap->dr_set(port->cap, ret);
if (ret)
-   return ret;
+   goto unlock_and_ret;
 
-   return size;
+   ret = size;
+unlock_and_ret:
+   mutex_unlock(>port_type_lock);
+   return ret;
 }
 
 static ssize_t data_role_show(struct device *dev,
@@ -885,7 +906,7 @@ static ssize_t power_role_store(struct device *dev,
const char *buf, size_t size)
 {
struct typec_port *port = to_typec_port(dev);
-   int ret = size;
+   int ret;
 
if (!port->cap->pd_revision) {
dev_dbg(dev, "USB Power Delivery not supported\n");
@@ -906,11 +927,22 @@ static ssize_t power_role_store(struct device *dev,
if (ret < 0)
return ret;
 
+   mutex_lock(>port_type_lock);
+   if (port->port_type != TYPEC_PORT_DRP) {
+   dev_dbg(dev, "port type fixed at \"%s\"",
+typec_port_types[port->port_type]);
+   ret = -EOPNOTSUPP;
+   goto unlock_and_ret;
+   }
+
ret = port->cap->pr_set(port->cap, ret);
if (ret)
-   return ret;
+   goto unlock_and_ret;
 
-   return size;
+   ret = size;
+unlock_and_ret:
+   mutex_unlock(>port_type_lock);
+   return ret;
 }
 
 static ssize_t power_role_show(struct device *dev,
@@ -926,6 +958,57 @@ static ssize_t power_role_show(struct device *dev,
 

Re: [PATCHv3] usb: typec: Add a sysfs node to manage port type

[Badhri Jagan Sridharan]

On Fri, May 26, 2017 at 11:31 AM, Greg Kroah-Hartman
 wrote:
> On Fri, May 26, 2017 at 10:45:59AM -0700, Badhri Jagan Sridharan wrote:
>> User space applications in some cases have the need to enforce a
>> specific port type(DFP/UFP/DRP). This change allows userspace to
>> attempt setting the desired port type. Low level drivers can
>> however reject the request if the specific port type is not supported.
>>
>> Signed-off-by: Badhri Jagan Sridharan 
>> Change-Id: Ia76877558c47271a34d912a54eea3459655dda3c
>
> Why is this line here?  :)
Oops default commit hook for internal change tracking.
Removing in my next patch :)

>
--
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 v4] usb: typec: Add a sysfs node to manage port type

[Badhri Jagan Sridharan]

User space applications in some cases have the need to enforce a
specific port type(DFP/UFP/DRP). This change allows userspace to
attempt setting the desired port type. Low level drivers can
however reject the request if the specific port type is not supported.

Signed-off-by: Badhri Jagan Sridharan 
---
Changelog since v1:
- introduced a new variable port_type in struct typec_port to track
  the current port type instead of changing type member in
  typec_capability to address Heikki Krogerus comments.
- changed the output format and strings that would be displayed as
  suggested by Heikki Krogerus.

Changelog since v2:
- introduced a new mutex lock to protect port_type for addressing
  the race conditions identified by Geunter Roeck
- added typec_port_types_drp for printing port_type when cap->type
  is TYPE_PORT_DRP as suggested by Geunter Roeck
- Power role swap and data role swaps would be rejected unless
  port port_type == TYPE_PORT_DRP
- port_type_store would return immediately if the current port_type
  is same as the new port_type as suggested by Geunter Roeck

Changelog since v3:
- Moved as much as code outside port_type_lock as suggested by
  Geunter Roeck
- Removed Change-Id line from commit message identified by
  Greg Kroah-Hartman

 drivers/usb/typec/typec.c | 106 +-
 include/linux/usb/typec.h |   4 ++
 2 files changed, 100 insertions(+), 10 deletions(-)

diff --git a/drivers/usb/typec/typec.c b/drivers/usb/typec/typec.c
index 89e540bb7ff3..bf1eb11c6646 100644
--- a/drivers/usb/typec/typec.c
+++ b/drivers/usb/typec/typec.c
@@ -11,6 +11,7 @@
 
 #include 
 #include 
+#include 
 #include 
 #include 
 
@@ -69,6 +70,8 @@ struct typec_port {
enum typec_role pwr_role;
enum typec_role vconn_role;
enum typec_pwr_opmode   pwr_opmode;
+   enum typec_port_typeport_type;
+   struct mutexport_type_lock;
 
const struct typec_capability   *cap;
 };
@@ -789,6 +792,18 @@ static const char * const typec_data_roles[] = {
[TYPEC_HOST]= "host",
 };
 
+static const char * const typec_port_types[] = {
+   [TYPEC_PORT_DFP] = "source",
+   [TYPEC_PORT_UFP] = "sink",
+   [TYPEC_PORT_DRP] = "dual",
+};
+
+static const char * const typec_port_types_drp[] = {
+   [TYPEC_PORT_DFP] = "dual [source] sink",
+   [TYPEC_PORT_UFP] = "dual source [sink]",
+   [TYPEC_PORT_DRP] = "[dual] source sink",
+};
+
 static ssize_t
 preferred_role_store(struct device *dev, struct device_attribute *attr,
 const char *buf, size_t size)
@@ -846,11 +861,6 @@ static ssize_t data_role_store(struct device *dev,
struct typec_port *port = to_typec_port(dev);
int ret;
 
-   if (port->cap->type != TYPEC_PORT_DRP) {
-   dev_dbg(dev, "data role swap only supported with DRP ports\n");
-   return -EOPNOTSUPP;
-   }
-
if (!port->cap->dr_set) {
dev_dbg(dev, "data role swapping not supported\n");
return -EOPNOTSUPP;
@@ -860,11 +870,22 @@ static ssize_t data_role_store(struct device *dev,
if (ret < 0)
return ret;
 
+   mutex_lock(>port_type_lock);
+   if (port->port_type != TYPEC_PORT_DRP) {
+   dev_dbg(dev, "port type fixed at \"%s\"",
+typec_port_types[port->port_type]);
+   ret = -EOPNOTSUPP;
+   goto unlock_and_ret;
+   }
+
ret = port->cap->dr_set(port->cap, ret);
if (ret)
-   return ret;
+   goto unlock_and_ret;
 
-   return size;
+   ret = size;
+unlock_and_ret:
+   mutex_unlock(>port_type_lock);
+   return ret;
 }
 
 static ssize_t data_role_show(struct device *dev,
@@ -885,7 +906,7 @@ static ssize_t power_role_store(struct device *dev,
const char *buf, size_t size)
 {
struct typec_port *port = to_typec_port(dev);
-   int ret = size;
+   int ret;
 
if (!port->cap->pd_revision) {
dev_dbg(dev, "USB Power Delivery not supported\n");
@@ -906,11 +927,22 @@ static ssize_t power_role_store(struct device *dev,
if (ret < 0)
return ret;
 
+   mutex_lock(>port_type_lock);
+   if (port->port_type != TYPEC_PORT_DRP) {
+   dev_dbg(dev, "port type fixed at \"%s\"",
+typec_port_types[port->port_type]);
+   ret = -EOPNOTSUPP;
+   goto unlock_and_ret;
+   }
+
ret = port->cap->pr_set(port->cap, ret);
if (ret)
-   return ret;
+   goto unlock_and_ret;
 
-   return size;
+   ret = size;
+unlock_and_ret:
+   mutex_unlock(>port_type_lock);
+   return ret;
 }
 
 static ssize_t power_role_show(struct device *dev,
@@ -926,6 +958,57 @@ static ssize_t power_role_show(struct device *dev,
 

Re: [PATCHv3] usb: typec: Add a sysfs node to manage port type

[Badhri Jagan Sridharan]

On Fri, May 26, 2017 at 11:00 AM, Guenter Roeck  wrote:
> On Fri, May 26, 2017 at 10:45:59AM -0700, Badhri Jagan Sridharan wrote:
>> User space applications in some cases have the need to enforce a
>> specific port type(DFP/UFP/DRP). This change allows userspace to
>> attempt setting the desired port type. Low level drivers can
>> however reject the request if the specific port type is not supported.
>>
>> Signed-off-by: Badhri Jagan Sridharan 
>> Change-Id: Ia76877558c47271a34d912a54eea3459655dda3c
>> ---
>> Changelog since v1:
>> - introduced a new variable port_type in struct typec_port to track
>>   the current port type instead of changing type member in
>>   typec_capability to address Heikki Krogerus comments.
>> - changed the output format and strings that would be displayed as
>>   suggested by Heikki Krogerus.
>>
>> Changelog since v2:
>> - introduced a new mutex lock to protect port_type for addressing
>>   the race conditions identified by Geunter Roeck
>> - added typec_port_types_drp for printing port_type when cap->type
>>   is TYPE_PORT_DRP as suggested by Geunter Roeck
>> - Power role swap and data role swaps would be rejected unless
>>   port port_type == TYPE_PORT_DRP
>> - port_type_store would return immediately if the current port_type
>>   is same as the new port_type as suggested by Geunter Roeck
>>
>>  drivers/usb/typec/typec.c | 127 
>> --
>>  include/linux/usb/typec.h |   4 ++
>>  2 files changed, 116 insertions(+), 15 deletions(-)
>>
>> diff --git a/drivers/usb/typec/typec.c b/drivers/usb/typec/typec.c
>> index 89e540bb7ff3..a0d8887ad560 100644
>> --- a/drivers/usb/typec/typec.c
>> +++ b/drivers/usb/typec/typec.c
>> @@ -11,9 +11,11 @@
>>
>>  #include 
>>  #include 
>> +#include 
>>  #include 
>>  #include 
>>
>> +
>
> Single empty lines only, please.
>
>>  struct typec_mode {
>>   int index;
>>   u32 vdo;
>> @@ -69,6 +71,8 @@ struct typec_port {
>>   enum typec_role pwr_role;
>>   enum typec_role vconn_role;
>>   enum typec_pwr_opmode   pwr_opmode;
>> + enum typec_port_typeport_type;
>> + struct mutexport_type_lock;
>>
>>   const struct typec_capability   *cap;
>>  };
>> @@ -789,6 +793,19 @@ static const char * const typec_data_roles[] = {
>>   [TYPEC_HOST]= "host",
>>  };
>>
>> +static const char * const typec_port_types[] = {
>> + [TYPEC_PORT_DFP] = "source",
>> + [TYPEC_PORT_UFP] = "sink",
>> + [TYPEC_PORT_DRP] = "dual",
>> +};
>> +
>> +static const char * const typec_port_types_drp[] = {
>> + [TYPEC_PORT_DFP] = "dual [source] sink",
>> + [TYPEC_PORT_UFP] = "dual source [sink]",
>> + [TYPEC_PORT_DRP] = "[dual] source sink",
>> +};
>> +
>> +
> Single empty line.
>
>>  static ssize_t
>>  preferred_role_store(struct device *dev, struct device_attribute *attr,
>>const char *buf, size_t size)
>> @@ -846,25 +863,34 @@ static ssize_t data_role_store(struct device *dev,
>>   struct typec_port *port = to_typec_port(dev);
>>   int ret;
>>
>> - if (port->cap->type != TYPEC_PORT_DRP) {
>> - dev_dbg(dev, "data role swap only supported with DRP ports\n");
>> - return -EOPNOTSUPP;
>> - }
>> + mutex_lock(>port_type_lock);
>>
>>   if (!port->cap->dr_set) {
>>   dev_dbg(dev, "data role swapping not supported\n");
>> - return -EOPNOTSUPP;
>> + ret = -EOPNOTSUPP;
>> + goto unlock_and_ret;
>> + }
>
> I think you can check this outside the lock; capabilities won't change.
>
>> +
>> + if (port->port_type != TYPEC_PORT_DRP) {
>> + dev_dbg(dev, "port type fixed at \"%s\"",
>> +  typec_port_types[port->port_type]);
>> + ret = -EOPNOTSUPP;
>> + goto unlock_and_ret;
>>   }
>>
>>   ret = sysfs_match_string(typec_data_roles, buf);
>>   if (ret < 0)
>> - return ret;
>> + goto unlock_and_ret;
>
> Move outside the lock ?
>
>>
>>   ret = port->cap->dr_set(port->cap, ret);
>>   if (ret)
>> - return ret;
>> + goto unlock_and_ret;
>>
>> - return size;
>> + ret = size;
>> +
>> +unlock_and_ret:
>> + mutex_unlock(>port_type_lock);
>> + return ret;
>>  }
>>
>>  static ssize_t data_role_show(struct device *dev,
>> @@ -885,32 +911,47 @@ static ssize_t power_role_store(struct device *dev,
>>   const char *buf, size_t size)
>>  {
>>   struct typec_port *port = to_typec_port(dev);
>> - int ret = size;
>> + int ret;
>>
>> + mutex_lock(>port_type_lock);
>>   if (!port->cap->pd_revision) {
>>   dev_dbg(dev, "USB Power Delivery not supported\n");
>> - return -EOPNOTSUPP;
>> + ret = -EOPNOTSUPP;
>> + 

[PATCH v1] usb: host: xhci: reliable endpoint reset after halt

[gavinli]

From: Gavin Li 

If a stalling TRB is cancelled and NOOP'ed in xhci_handle_cmd_stop_ep(),
finish_td() never gets called to reset the halted endpoint and the
endpoint remains indefinitely stalled. This patch ensures that
xhci_cleanup_halted_endpoint() is called after a TRB completion if the
endpoint is halted, irregardless of the status of any pending TRBs.

Signed-off-by: Gavin Li 
---
 drivers/usb/host/xhci-ring.c | 34 +-
 drivers/usb/host/xhci.h  |  1 +
 2 files changed, 30 insertions(+), 5 deletions(-)

diff --git a/drivers/usb/host/xhci-ring.c b/drivers/usb/host/xhci-ring.c
index 03f63f50afb6..85bc53d0d43e 100644
--- a/drivers/usb/host/xhci-ring.c
+++ b/drivers/usb/host/xhci-ring.c
@@ -1113,11 +1113,13 @@ static void xhci_handle_cmd_reset_ep(struct xhci_hcd 
*xhci, int slot_id,
 {
struct xhci_virt_device *vdev;
struct xhci_ep_ctx *ep_ctx;
+   struct xhci_virt_ep *ep;
unsigned int ep_index;
 
ep_index = TRB_TO_EP_INDEX(le32_to_cpu(trb->generic.field[3]));
vdev = xhci->devs[slot_id];
ep_ctx = xhci_get_ep_ctx(xhci, vdev->out_ctx, ep_index);
+   ep = >devs[slot_id]->eps[ep_index];
trace_xhci_handle_cmd_reset_ep(ep_ctx);
 
/* This command will only fail if the endpoint wasn't halted,
@@ -1130,6 +1132,7 @@ static void xhci_handle_cmd_reset_ep(struct xhci_hcd 
*xhci, int slot_id,
 * command complete before the endpoint can be used.  Queue that here
 * because the HW can't handle two commands being queued in a row.
 */
+   ep->ep_state &= ~EP_RESET_PENDING;
if (xhci->quirks & XHCI_RESET_EP_QUIRK) {
struct xhci_command *command;
 
@@ -1145,7 +1148,11 @@ static void xhci_handle_cmd_reset_ep(struct xhci_hcd 
*xhci, int slot_id,
xhci_ring_cmd_db(xhci);
} else {
/* Clear our internal halted state */
-   xhci->devs[slot_id]->eps[ep_index].ep_state &= ~EP_HALTED;
+   ep->ep_state &= ~EP_HALTED;
+   if (!(ep->ep_state & SET_DEQ_PENDING)) {
+   /* Restart any rings with pending URBs */
+   ring_doorbell_for_active_rings(xhci, slot_id, ep_index);
+   }
}
 }
 
@@ -1800,19 +1807,25 @@ struct xhci_segment *trb_in_td(struct xhci_hcd *xhci,
 static void xhci_cleanup_halted_endpoint(struct xhci_hcd *xhci,
unsigned int slot_id, unsigned int ep_index,
unsigned int stream_id,
-   struct xhci_td *td, union xhci_trb *ep_trb)
+   struct xhci_td *td)
 {
struct xhci_virt_ep *ep = >devs[slot_id]->eps[ep_index];
struct xhci_command *command;
+
+   if (ep->ep_state & EP_RESET_PENDING)
+   return;
+
command = xhci_alloc_command(xhci, false, false, GFP_ATOMIC);
if (!command)
return;
 
-   ep->ep_state |= EP_HALTED;
+   ep->ep_state |= EP_HALTED | EP_RESET_PENDING;
ep->stopped_stream = stream_id;
 
xhci_queue_reset_ep(xhci, command, slot_id, ep_index);
-   xhci_cleanup_stalled_ring(xhci, ep_index, td);
+   if (td != NULL && !(ep->ep_state & SET_DEQ_PENDING)) {
+   xhci_cleanup_stalled_ring(xhci, ep_index, td);
+   }
 
ep->stopped_stream = 0;
 
@@ -1947,7 +1960,7 @@ static int finish_td(struct xhci_hcd *xhci, struct 
xhci_td *td,
 * The class driver clears the device side halt later.
 */
xhci_cleanup_halted_endpoint(xhci, slot_id, ep_index,
-   ep_ring->stream_id, td, ep_trb);
+   ep_ring->stream_id, td);
} else {
/* Update ring dequeue pointer */
while (ep_ring->dequeue != td->last_trb)
@@ -2588,6 +2601,17 @@ static int handle_tx_event(struct xhci_hcd *xhci,
 */
} while (handling_skipped_tds);
 
+   /*
+* If a cancelled TRB halts the endpoint, reset it here.
+*/
+   if (trb_comp_code == COMP_STALL_ERROR ||
+   xhci_requires_manual_halt_cleanup(xhci, ep_ctx,
+   trb_comp_code)) {
+   /* No harm in calling this twice; second call will be a no-op */
+   xhci_cleanup_halted_endpoint(xhci, slot_id, ep_index,
+   ep_ring->stream_id, td);
+   }
+
return 0;
 }
 
diff --git a/drivers/usb/host/xhci.h b/drivers/usb/host/xhci.h
index 73a28a986d5e..0f7439f4d414 100644
--- a/drivers/usb/host/xhci.h
+++ b/drivers/usb/host/xhci.h
@@ -922,6 +922,7 @@ struct xhci_virt_ep {
 #define EP_HAS_STREAMS (1 << 4)
 /* Transitioning the endpoint to not using streams, don't enqueue URBs */
 #define EP_GETTING_NO_STREAMS  (1 << 5)
+#define EP_RESET_PENDING  (1 << 6) /* For stall recovery */
/*   Related to URB cancellation 

Re: [PATCH 3/3] usb: max3421-hcd: Remove function name from dev_dbg calls

[Greg Kroah-Hartman]

On Fri, May 26, 2017 at 02:32:42PM +0300, Alexander Amelkin wrote:
> NOTE:
> Please don't use the plain text here as a patch because it most probably is
> corrupted by my webmail client.
> Attached is a copy of the following text guaranteed to have correct
> tabs/spaces.

Why is this here

What did you do to add this odd stuff to the patches?  Please just use
git send-email like everyone else does...

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: [GIT][PULL] Improvements to max3421-hcd driver

[Greg Kroah-Hartman]

On Fri, May 26, 2017 at 02:22:47PM +0300, Alexander Amelkin wrote:
> The following changes since commit 08332893e37af6ae779367e78e444f8f9571511d:
> 
>   Linux 4.12-rc2 (2017-05-21 19:30:23 -0700)
> 
> are available in the git repository at:
> 
>   https://github.com/AlexanderAmelkin/linux-wandboard.git
> tags/max3421-improvements-1

I don't take random USB pull requests, and never from github, sorry.
Just send patches through email, like all other developers do.

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: [RFC PATCH] staging: typec: Intel WhiskeyCove PMIC USB Type-C PHY driver

[Greg Kroah-Hartman]

On Fri, May 26, 2017 at 03:53:49PM +0300, Heikki Krogerus wrote:
> Hi,
> 
> My two cents.
> 
> On Thu, May 25, 2017 at 10:12:27AM -0700, Guenter Roeck wrote:
> > > What is keeping this code in staging at the moment?  Who isn't agreeing
> > > on the existing apis we have there?
> > > 
> > 
> > I don't think the APIs are at issue; I would not expect any substantial
> > (if any) changes going forward. We may have additions such as the pending
> > port type change support, but will always happen.
> > 
> > >From TODO:
> > - Add documentation (at the very least for the API to low level drivers)
> 
> This probable should be addressed.
> 
> > - Split PD code into separate file
> 
> Can be done later.
> 
> > - Check if it makes sense to use tracepoints instead of debugfs for debug 
> > logs
> 
> I would prefer tracepoints over custom debug logs, but if I'm the only
> one, I'm OK changing it later.
> 
> I can also start working on this, but unfortunately I won't be able to
> start right away. I'll be on vacation next week... Sorry for the last
> minute announcement btw.
> 
> > - Implement Alternate Mode handling
> 
> Can be done later.
> 
> > - Address "#if 0" code if not addressed with the above
> > - Validate all comments marked with "XXX"; either address or remove comments
> 
> These need to be addressed.
> 
> > - Add support for USB PD 3.0. While not mandatory, at least fast role swap
> >   as well as authentication support would be very desirable.
> 
> Can be done later.

All of these feel to me like they can be done later, as nothing is
messing with the user/kernel api, right?  (trace vs. debugfs doesn't
matter...)

So, who wants to send me the patch to write a tiny bit of documentation
and then get this out of staging?  :)

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: [PATCHv3] usb: typec: Add a sysfs node to manage port type

[Greg Kroah-Hartman]

On Fri, May 26, 2017 at 10:45:59AM -0700, Badhri Jagan Sridharan wrote:
> User space applications in some cases have the need to enforce a
> specific port type(DFP/UFP/DRP). This change allows userspace to
> attempt setting the desired port type. Low level drivers can
> however reject the request if the specific port type is not supported.
> 
> Signed-off-by: Badhri Jagan Sridharan 
> Change-Id: Ia76877558c47271a34d912a54eea3459655dda3c

Why is this line here?  :)

--
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: [PATCHv3] usb: typec: Add a sysfs node to manage port type

[Guenter Roeck]

On Fri, May 26, 2017 at 10:45:59AM -0700, Badhri Jagan Sridharan wrote:
> User space applications in some cases have the need to enforce a
> specific port type(DFP/UFP/DRP). This change allows userspace to
> attempt setting the desired port type. Low level drivers can
> however reject the request if the specific port type is not supported.
> 
> Signed-off-by: Badhri Jagan Sridharan 
> Change-Id: Ia76877558c47271a34d912a54eea3459655dda3c
> ---
> Changelog since v1:
> - introduced a new variable port_type in struct typec_port to track
>   the current port type instead of changing type member in
>   typec_capability to address Heikki Krogerus comments.
> - changed the output format and strings that would be displayed as
>   suggested by Heikki Krogerus.
> 
> Changelog since v2:
> - introduced a new mutex lock to protect port_type for addressing
>   the race conditions identified by Geunter Roeck
> - added typec_port_types_drp for printing port_type when cap->type
>   is TYPE_PORT_DRP as suggested by Geunter Roeck
> - Power role swap and data role swaps would be rejected unless
>   port port_type == TYPE_PORT_DRP
> - port_type_store would return immediately if the current port_type
>   is same as the new port_type as suggested by Geunter Roeck
> 
>  drivers/usb/typec/typec.c | 127 
> --
>  include/linux/usb/typec.h |   4 ++
>  2 files changed, 116 insertions(+), 15 deletions(-)
> 
> diff --git a/drivers/usb/typec/typec.c b/drivers/usb/typec/typec.c
> index 89e540bb7ff3..a0d8887ad560 100644
> --- a/drivers/usb/typec/typec.c
> +++ b/drivers/usb/typec/typec.c
> @@ -11,9 +11,11 @@
>  
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  
> +

Single empty lines only, please.

>  struct typec_mode {
>   int index;
>   u32 vdo;
> @@ -69,6 +71,8 @@ struct typec_port {
>   enum typec_role pwr_role;
>   enum typec_role vconn_role;
>   enum typec_pwr_opmode   pwr_opmode;
> + enum typec_port_typeport_type;
> + struct mutexport_type_lock;
>  
>   const struct typec_capability   *cap;
>  };
> @@ -789,6 +793,19 @@ static const char * const typec_data_roles[] = {
>   [TYPEC_HOST]= "host",
>  };
>  
> +static const char * const typec_port_types[] = {
> + [TYPEC_PORT_DFP] = "source",
> + [TYPEC_PORT_UFP] = "sink",
> + [TYPEC_PORT_DRP] = "dual",
> +};
> +
> +static const char * const typec_port_types_drp[] = {
> + [TYPEC_PORT_DFP] = "dual [source] sink",
> + [TYPEC_PORT_UFP] = "dual source [sink]",
> + [TYPEC_PORT_DRP] = "[dual] source sink",
> +};
> +
> +
Single empty line.

>  static ssize_t
>  preferred_role_store(struct device *dev, struct device_attribute *attr,
>const char *buf, size_t size)
> @@ -846,25 +863,34 @@ static ssize_t data_role_store(struct device *dev,
>   struct typec_port *port = to_typec_port(dev);
>   int ret;
>  
> - if (port->cap->type != TYPEC_PORT_DRP) {
> - dev_dbg(dev, "data role swap only supported with DRP ports\n");
> - return -EOPNOTSUPP;
> - }
> + mutex_lock(>port_type_lock);
>  
>   if (!port->cap->dr_set) {
>   dev_dbg(dev, "data role swapping not supported\n");
> - return -EOPNOTSUPP;
> + ret = -EOPNOTSUPP;
> + goto unlock_and_ret;
> + }

I think you can check this outside the lock; capabilities won't change.

> +
> + if (port->port_type != TYPEC_PORT_DRP) {
> + dev_dbg(dev, "port type fixed at \"%s\"",
> +  typec_port_types[port->port_type]);
> + ret = -EOPNOTSUPP;
> + goto unlock_and_ret;
>   }
>  
>   ret = sysfs_match_string(typec_data_roles, buf);
>   if (ret < 0)
> - return ret;
> + goto unlock_and_ret;

Move outside the lock ?

>  
>   ret = port->cap->dr_set(port->cap, ret);
>   if (ret)
> - return ret;
> + goto unlock_and_ret;
>  
> - return size;
> + ret = size;
> +
> +unlock_and_ret:
> + mutex_unlock(>port_type_lock);
> + return ret;
>  }
>  
>  static ssize_t data_role_show(struct device *dev,
> @@ -885,32 +911,47 @@ static ssize_t power_role_store(struct device *dev,
>   const char *buf, size_t size)
>  {
>   struct typec_port *port = to_typec_port(dev);
> - int ret = size;
> + int ret;
>  
> + mutex_lock(>port_type_lock);
>   if (!port->cap->pd_revision) {
>   dev_dbg(dev, "USB Power Delivery not supported\n");
> - return -EOPNOTSUPP;
> + ret = -EOPNOTSUPP;
> + goto unlock_and_ret;
>   }
>  
>   if (!port->cap->pr_set) {
>   dev_dbg(dev, "power role swapping not supported\n");
> - return -EOPNOTSUPP;
> + ret = 

[PATCHv3] usb: typec: Add a sysfs node to manage port type

[Badhri Jagan Sridharan]

User space applications in some cases have the need to enforce a
specific port type(DFP/UFP/DRP). This change allows userspace to
attempt setting the desired port type. Low level drivers can
however reject the request if the specific port type is not supported.

Signed-off-by: Badhri Jagan Sridharan 
Change-Id: Ia76877558c47271a34d912a54eea3459655dda3c
---
Changelog since v1:
- introduced a new variable port_type in struct typec_port to track
  the current port type instead of changing type member in
  typec_capability to address Heikki Krogerus comments.
- changed the output format and strings that would be displayed as
  suggested by Heikki Krogerus.

Changelog since v2:
- introduced a new mutex lock to protect port_type for addressing
  the race conditions identified by Geunter Roeck
- added typec_port_types_drp for printing port_type when cap->type
  is TYPE_PORT_DRP as suggested by Geunter Roeck
- Power role swap and data role swaps would be rejected unless
  port port_type == TYPE_PORT_DRP
- port_type_store would return immediately if the current port_type
  is same as the new port_type as suggested by Geunter Roeck

 drivers/usb/typec/typec.c | 127 --
 include/linux/usb/typec.h |   4 ++
 2 files changed, 116 insertions(+), 15 deletions(-)

diff --git a/drivers/usb/typec/typec.c b/drivers/usb/typec/typec.c
index 89e540bb7ff3..a0d8887ad560 100644
--- a/drivers/usb/typec/typec.c
+++ b/drivers/usb/typec/typec.c
@@ -11,9 +11,11 @@
 
 #include 
 #include 
+#include 
 #include 
 #include 
 
+
 struct typec_mode {
int index;
u32 vdo;
@@ -69,6 +71,8 @@ struct typec_port {
enum typec_role pwr_role;
enum typec_role vconn_role;
enum typec_pwr_opmode   pwr_opmode;
+   enum typec_port_typeport_type;
+   struct mutexport_type_lock;
 
const struct typec_capability   *cap;
 };
@@ -789,6 +793,19 @@ static const char * const typec_data_roles[] = {
[TYPEC_HOST]= "host",
 };
 
+static const char * const typec_port_types[] = {
+   [TYPEC_PORT_DFP] = "source",
+   [TYPEC_PORT_UFP] = "sink",
+   [TYPEC_PORT_DRP] = "dual",
+};
+
+static const char * const typec_port_types_drp[] = {
+   [TYPEC_PORT_DFP] = "dual [source] sink",
+   [TYPEC_PORT_UFP] = "dual source [sink]",
+   [TYPEC_PORT_DRP] = "[dual] source sink",
+};
+
+
 static ssize_t
 preferred_role_store(struct device *dev, struct device_attribute *attr,
 const char *buf, size_t size)
@@ -846,25 +863,34 @@ static ssize_t data_role_store(struct device *dev,
struct typec_port *port = to_typec_port(dev);
int ret;
 
-   if (port->cap->type != TYPEC_PORT_DRP) {
-   dev_dbg(dev, "data role swap only supported with DRP ports\n");
-   return -EOPNOTSUPP;
-   }
+   mutex_lock(>port_type_lock);
 
if (!port->cap->dr_set) {
dev_dbg(dev, "data role swapping not supported\n");
-   return -EOPNOTSUPP;
+   ret = -EOPNOTSUPP;
+   goto unlock_and_ret;
+   }
+
+   if (port->port_type != TYPEC_PORT_DRP) {
+   dev_dbg(dev, "port type fixed at \"%s\"",
+typec_port_types[port->port_type]);
+   ret = -EOPNOTSUPP;
+   goto unlock_and_ret;
}
 
ret = sysfs_match_string(typec_data_roles, buf);
if (ret < 0)
-   return ret;
+   goto unlock_and_ret;
 
ret = port->cap->dr_set(port->cap, ret);
if (ret)
-   return ret;
+   goto unlock_and_ret;
 
-   return size;
+   ret = size;
+
+unlock_and_ret:
+   mutex_unlock(>port_type_lock);
+   return ret;
 }
 
 static ssize_t data_role_show(struct device *dev,
@@ -885,32 +911,47 @@ static ssize_t power_role_store(struct device *dev,
const char *buf, size_t size)
 {
struct typec_port *port = to_typec_port(dev);
-   int ret = size;
+   int ret;
 
+   mutex_lock(>port_type_lock);
if (!port->cap->pd_revision) {
dev_dbg(dev, "USB Power Delivery not supported\n");
-   return -EOPNOTSUPP;
+   ret = -EOPNOTSUPP;
+   goto unlock_and_ret;
}
 
if (!port->cap->pr_set) {
dev_dbg(dev, "power role swapping not supported\n");
-   return -EOPNOTSUPP;
+   ret = -EOPNOTSUPP;
+   goto unlock_and_ret;
+   }
+
+   if (port->port_type != TYPEC_PORT_DRP) {
+   dev_dbg(dev, "port type fixed at \"%s\"",
+typec_port_types[port->port_type]);
+   ret = -EOPNOTSUPP;
+   goto unlock_and_ret;
}
 
if (port->pwr_opmode != TYPEC_PWR_MODE_PD) {
 

Re: [PATCH v4 3/3] usb: gadget: add f_uac1 variant based on a new u_audio api

[Julian Scheel]

On 18.05.2017 00:37, Ruslan Bilovol wrote:

This patch adds a new function 'f_uac1_acard'
(f_uac1 with virtual "ALSA card") that
uses recently created u_audio API. Comparing
to legacy f_uac1 function implementation it
doesn't require any real Audio codec to be
present on the device. In f_uac1_acard audio
streams are simply sinked to and sourced
from a virtual ALSA sound card created
using u_audio API.

Legacy f_uac1 approach is to write audio
samples directly to existing ALSA sound
card

f_uac1_acard approach is more generic/flexible
one - create an ALSA sound card that
represents USB Audio function and allows to
be used by userspace application that
may choose to do whatever it wants with the
data received from the USB Host and choose
to provide whatever it wants as audio data
to the USB Host.

f_uac1_acard also has capture support (gadget->host)
thanks to easy implementation via u_audio.
By default, capture interface has 48000kHz/2ch
configuration, same as playback channel has.

f_uac1_acard descriptors naming convention
uses f_uac2 driver naming convention that
makes it more common and meaningful.

Comparing to f_uac1, the f_uac1_acard doesn't
have volume/mute functionality. This is because
the f_uac1 volume/mute feature unit was dummy
implementation since that driver creation (2009)
and never had any real volume control or mute
functionality, so there is no any difference
here.

Since f_uac1_acard functionality, exposed
interface to userspace (virtual ALSA card),
input parameters are so different comparing
to legace f_uac1, that there is no any
reason to keep them in the same file/module,
and separate function was created.

g_audio can be built using one of existing
UAC functions (f_uac1, f_uac1_acard or f_uac2)

Signed-off-by: Ruslan Bilovol 
---
  .../ABI/testing/configfs-usb-gadget-uac1_acard |  14 +
  Documentation/usb/gadget-testing.txt   |  45 ++
  drivers/usb/gadget/Kconfig |  21 +
  drivers/usb/gadget/function/Makefile   |   2 +
  drivers/usb/gadget/function/f_uac1_acard.c | 803 +
  drivers/usb/gadget/function/u_uac1_acard.h |  41 ++
  drivers/usb/gadget/legacy/Kconfig  |  15 +-
  drivers/usb/gadget/legacy/audio.c  |  53 ++
  8 files changed, 992 insertions(+), 2 deletions(-)
  create mode 100644 Documentation/ABI/testing/configfs-usb-gadget-uac1_acard
  create mode 100644 drivers/usb/gadget/function/f_uac1_acard.c
  create mode 100644 drivers/usb/gadget/function/u_uac1_acard.h



Tested on iMX7D using chipidea usb gadget controller. Tested Windows 10 
and Linux 4.11 as host. Both work fine.


Tested-by: Julian Scheel 
--
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: Make use of ktime_* comparison functions

[Alan Stern]

On Fri, 26 May 2017, Mariusz Skamra wrote:

> Start using ktime_* compare functions to make the code backportable.
> Now that may be a bit tricky due to recent change of ktime_t.
> 
> Signed-off-by: Mariusz Skamra 
> Acked-by: Kuppuswamy Sathyanarayanan 
> ---
>  drivers/usb/chipidea/otg_fsm.c | 8 
>  drivers/usb/host/ehci-timer.c  | 2 +-
>  drivers/usb/host/fotg210-hcd.c | 2 +-
>  3 files changed, 6 insertions(+), 6 deletions(-)

> diff --git a/drivers/usb/host/ehci-timer.c b/drivers/usb/host/ehci-timer.c
> index 3893b5b..0b6cdb7 100644
> --- a/drivers/usb/host/ehci-timer.c
> +++ b/drivers/usb/host/ehci-timer.c
> @@ -424,7 +424,7 @@ static enum hrtimer_restart ehci_hrtimer_func(struct 
> hrtimer *t)
>*/
>   now = ktime_get();
>   for_each_set_bit(e, , EHCI_HRTIMER_NUM_EVENTS) {
> - if (now >= ehci->hr_timeouts[e])
> + if (ktime_compare(now, ehci->hr_timeouts[e]) >= 0)
>   event_handlers[e](ehci);
>   else
>   ehci_enable_event(ehci, e, false);

For the EHCI portion:

Acked-by: 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 3/3] usb: typec: ucsi: Add ACPI driver

[Guenter Roeck]

On 05/26/2017 04:08 AM, Heikki Krogerus wrote:

Hi,

On Thu, May 25, 2017 at 06:23:30AM -0700, Guenter Roeck wrote:

+   /*
+* NOTE: The memory region for the data structures is used also in an
+* operation region, which means ACPI has already reserved it. Therefore
+* it can not be requested here.
+*/
+   ua->ppm.data = devm_ioremap(>dev, res->start, resource_size(res));


devm_ioremap_resource() ?


devm_ioremap_resource() will try to request the region, and like I
tried to explain in the comment, it will fail as the region has
already been reserved by ACPI.



Maybe add this to the comment above ?

  .. it can not be requested here, and we can not use devm_ioremap_resource().

Thanks,
Guenter

--
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 2/3] usb: typec: Add support for UCSI interface

[Guenter Roeck]

On 05/26/2017 04:02 AM, Heikki Krogerus wrote:

Hi,

On Thu, May 25, 2017 at 06:20:16AM -0700, Guenter Roeck wrote:

On 05/16/2017 05:26 AM, Heikki Krogerus wrote:

UCSI - USB Type-C Connector System Software Interface - is a
specification that defines set of registers and data
structures for controlling the USB Type-C ports. It's
designed for systems where an embedded controller (EC) is in
charge of the USB Type-C PHY or USB Power Delivery
controller. It is designed for systems with EC, but it is
not limited to them, and for example some USB Power Delivery
controllers will use it as their direct control interface.

With UCSI the EC (or USB PD controller) acts as the port
manager, implementing all USB Type-C and Power Delivery state
machines. The OS can use the interfaces for reading the
status of the ports and controlling basic operations like
role swapping.

The UCSI specification highlights the fact that it does not
define the interface method (PCI/I2C/ACPI/etc.).
Therefore the driver is implemented as library and every
supported interface method needs its own driver. Driver for
ACPI is provided in separate patch following this one.

The initial driver includes support for all required
features from UCSI specification version 1.0 (getting
connector capabilities and status, and support for power and
data role swapping), but none of the optional UCSI features
(alternate modes, power source capabilities, and cable
capabilities).

Signed-off-by: Heikki Krogerus 
---
   drivers/usb/typec/Kconfig   |   2 +
   drivers/usb/typec/Makefile  |   1 +
   drivers/usb/typec/ucsi/Kconfig  |  22 ++
   drivers/usb/typec/ucsi/Makefile |   7 +
   drivers/usb/typec/ucsi/debug.h  |  64 
   drivers/usb/typec/ucsi/trace.c  |   2 +
   drivers/usb/typec/ucsi/trace.h  | 143 
   drivers/usb/typec/ucsi/ucsi.c   | 770 

   drivers/usb/typec/ucsi/ucsi.h   | 329 +
   9 files changed, 1340 insertions(+)
   create mode 100644 drivers/usb/typec/ucsi/Kconfig
   create mode 100644 drivers/usb/typec/ucsi/Makefile
   create mode 100644 drivers/usb/typec/ucsi/debug.h
   create mode 100644 drivers/usb/typec/ucsi/trace.c
   create mode 100644 drivers/usb/typec/ucsi/trace.h
   create mode 100644 drivers/usb/typec/ucsi/ucsi.c
   create mode 100644 drivers/usb/typec/ucsi/ucsi.h

diff --git a/drivers/usb/typec/Kconfig b/drivers/usb/typec/Kconfig
index dfcfe459b7cf..bc1b7745f1d4 100644
--- a/drivers/usb/typec/Kconfig
+++ b/drivers/usb/typec/Kconfig
@@ -19,4 +19,6 @@ config TYPEC_WCOVE
  To compile this driver as module, choose M here: the module will be
  called typec_wcove
+source "drivers/usb/typec/ucsi/Kconfig"
+
   endmenu
diff --git a/drivers/usb/typec/Makefile b/drivers/usb/typec/Makefile
index b9cb862221af..bc214f15f1b5 100644
--- a/drivers/usb/typec/Makefile
+++ b/drivers/usb/typec/Makefile
@@ -1,2 +1,3 @@
   obj-$(CONFIG_TYPEC)  += typec.o
   obj-$(CONFIG_TYPEC_WCOVE)+= typec_wcove.o
+obj-$(CONFIG_TYPEC_UCSI)   += ucsi/
diff --git a/drivers/usb/typec/ucsi/Kconfig b/drivers/usb/typec/ucsi/Kconfig
new file mode 100644
index ..679ba6648396
--- /dev/null
+++ b/drivers/usb/typec/ucsi/Kconfig
@@ -0,0 +1,22 @@
+config TYPEC_UCSI
+   tristate "USB Type-C Connector System Software Interface driver"
+   select TYPEC
+   help
+ USB Type-C Connector System Software Interface (UCSI) is a
+ specification for an interface that allows the operating system to
+ control the USB Type-C ports. On UCSI system the USB Type-C ports
+ function autonomously by default, but in order to get the status of
+ the ports and support basic operations like role swapping, the driver
+ is required. UCSI is available on most of the new Intel based systems
+ that are equipped with Embedded Controller and USB Type-C ports.
+
+ UCSI specification does not define the interface method, so depending
+ on the platform, ACPI, PCI, I2C, etc. may be used. Therefore this
+ driver only provides the core part, and separate drivers are needed
+ for every supported interface method.
+
+ The UCSI specification can be downloaded from:
+ 
http://www.intel.com/content/www/us/en/io/universal-serial-bus/usb-type-c-ucsi-spec.html
+
+ To compile the driver as a module, choose M here: the module will be
+ called typec_ucsi.
diff --git a/drivers/usb/typec/ucsi/Makefile b/drivers/usb/typec/ucsi/Makefile
new file mode 100644
index ..87dd6ee6c9f3
--- /dev/null
+++ b/drivers/usb/typec/ucsi/Makefile
@@ -0,0 +1,7 @@
+CFLAGS_trace.o := -I$(src)
+
+obj-$(CONFIG_TYPEC_UCSI)   += typec_ucsi.o
+
+typec_ucsi-y   := ucsi.o
+
+typec_ucsi-$(CONFIG_FTRACE)+= trace.o
diff --git a/drivers/usb/typec/ucsi/debug.h b/drivers/usb/typec/ucsi/debug.h
new file mode 100644
index 

Re: [RFC PATCH] staging: typec: Intel WhiskeyCove PMIC USB Type-C PHY driver

[Heikki Krogerus]

Hi,

My two cents.

On Thu, May 25, 2017 at 10:12:27AM -0700, Guenter Roeck wrote:
> > What is keeping this code in staging at the moment?  Who isn't agreeing
> > on the existing apis we have there?
> > 
> 
> I don't think the APIs are at issue; I would not expect any substantial
> (if any) changes going forward. We may have additions such as the pending
> port type change support, but will always happen.
> 
> >From TODO:
> - Add documentation (at the very least for the API to low level drivers)

This probable should be addressed.

> - Split PD code into separate file

Can be done later.

> - Check if it makes sense to use tracepoints instead of debugfs for debug logs

I would prefer tracepoints over custom debug logs, but if I'm the only
one, I'm OK changing it later.

I can also start working on this, but unfortunately I won't be able to
start right away. I'll be on vacation next week... Sorry for the last
minute announcement btw.

> - Implement Alternate Mode handling

Can be done later.

> - Address "#if 0" code if not addressed with the above
> - Validate all comments marked with "XXX"; either address or remove comments

These need to be addressed.

> - Add support for USB PD 3.0. While not mandatory, at least fast role swap
>   as well as authentication support would be very desirable.

Can be done later.


Thanks,

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

Re: [PATCH] usb: xhci: add quirk flag for broken stop command on AMD platforms

[Mathias Nyman]

On 25.05.2017 16:17, Shyam Sundar S K wrote:



On 5/22/2017 8:26 PM, Shyam Sundar S K wrote:


On 5/22/2017 6:49 PM, Mathias Nyman wrote:

On 22.05.2017 11:56, Shyam Sundar S K wrote:

Hi Mathias,


On 5/19/2017 12:43 PM, Mathias Nyman wrote:

On 18.05.2017 16:46, Alan Stern wrote:

On Thu, 18 May 2017, Shyam Sundar S K wrote:


on AMD platforms with SNPS 3.1 USB controller has an issue
if the stop EP command is issued when the controller is not
in running state. If issued, it is leading to a critical RTL bug
because of which controller goes into irrecoverable state.

This patch adds a appropriate checks to make sure that scenario
does not happen.

Signed-off-by: Shyam Sundar S K 
Signed-off-by: Nehal Shah 
---
--- a/drivers/usb/host/xhci.h
+++ b/drivers/usb/host/xhci.h
@@ -1819,6 +1819,7 @@ struct xhci_hcd {
/* For controller with a broken Port Disable implementation */
#define XHCI_BROKEN_PORT_PED(1 << 25)
#define XHCI_LIMIT_ENDPOINT_INTERVAL_7(1 << 26)
+#define XHCI_BROKEN_STOP(1 << 27)

Does there really need to be a quirk flag for this?  I should think
that you never want to issue a STOP EP command while the controller is
not running, no matter what kind of controller it is.

Alan Stern


If it's about controller not running then there shouldn't be any problems.
We shouldn't issue a stop endpoint command if controller is halted.

If this is about issuing a stop endpoint command while endpoint isn't
running, then fully working controllers should just respond with a command
completion with "context state error" status.

As per SNPS the controller is responding with "Context State Error", however 
the same is not getting
reflected when we check the cmd->status in the xhci driver.


Anyway, as Alan said the quirk is probably unnecessary here.

OK. We will take care of this.


We shouldn't need to
stop endpoints that are not running. Only problem I see here is that the
endpoint state in the output endpoint context might not be up to date. If driver
just restarted the endpoint by ringing the doorbell, the output context state
might not be updated yet.

Before issuing the stop end point command, we checked the state of the endpoint 
and it looks the state of
the end point is EP_STATE_STOPPED. If the output endpoint context is not 
updated is there a better way
to retrieve the EP state before issuing the stop end point command ?

Not really, checking endpoint context and possible a software variable kept up 
to date
by driver to keep track of doorbell. Perhaps checking endpoint ctx is enough 
for now

So, is it OK to guard the stop endpoint by checking the EP context before 
queuing it?


How does this SNPS 3.1 controller react if the endpoint just halted or moved to
error state just before controller runs the stop endpoint command? Still 
triggers
the RTL bug?

As per SNPS analysis.

1) Driver issues STOP ENDPOINT command  and the EP is in Running state.
2) HW executes the STOP ENDPOINT command successfully
3) Driver again issues STOP ENDPOINT command.
4) Since the EP is already halted/stopped, HW completes the command execution 
and reports “device context error” completion code. This is as per the spec.
5) However HW on receiving the second command additionally marks EP to Flow 
control state in HW which is RTL bug
6) The above bug causes the HW not to respond to any further doorbells that are 
rung by the driver. This causes the EP to not functional anymore and causes 
gross functional failures.


What happens if endpoint ctx shows endpoint is in the halted or error state 
when stop endpoint command is issued?
  still RTL bug?

Yes. That's right. If EP context shows as halted/stopped/error and we issue a 
stop endpoint command it is triggering the RTL bug. Since the tapeout has 
already happened and there is no way to fix this
from SNPS side, they are asking for a SW workaround i.e.  "issuing the stop endpoint 
command only when the EP context state is running."

So, it is OK to have this patch submission which will check for EP context 
before queuing the stop endpoint command ?


I'm talking about the in xhci spec 4.6.9:

" A Busy endpoint may asynchronously transition from the Running to the Halted 
or Error state due
to error conditions detected while processing TRBs. A possible race condition 
may occur if
software, thinking an endpoint is in the Running state, issues a Stop Endpoint 
Command however
at the same time the xHC asynchronously transitions the endpoint to the Halted 
or Error state. In
this case, a Context State Error may be generated for the command completion. 
Software may
verify that this case occurred by inspecting the EP State for Halted or Error 
when a Stop Endpoint
Command results in a Context State Error."


Since we are novice, can you please help to understand what is the intuition 
behind sending two stop endpoint commands ?

No need for two stop endpoint commands, that can be fixed in the 

[GIT][PULL] Improvements to max3421-hcd driver

[Alexander Amelkin]

The following changes since commit 
08332893e37af6ae779367e78e444f8f9571511d:


  Linux 4.12-rc2 (2017-05-21 19:30:23 -0700)

are available in the git repository at:

  https://github.com/AlexanderAmelkin/linux-wandboard.git 
tags/max3421-improvements-1


for you to fetch changes up to b9a7559d24c0b2cb6e69124d861a943f79272681:

  usb: max3421-hcd: Remove function name from dev_dbg calls (2017-05-25 
11:52:13 +0300)


The separate patches for these changes will be sent as a follow up.


usb: max3421-hcd: Make the driver more up-to-date and flexible

This set of patches updates the max3421-hcd driver and fixes
some bugs in it. Specifically, it:

- Adds support for devicetree
- Makes platform related parameters configurable
- Adds sanity checks for platform related parameters
- Fixes crash on driver removal
- Tidies up use of memory allocation/deallocation functions
- Removes superfluous debug text


Alexander Amelkin (3):
  usb: max3421-hcd: Add devicetree support to the driver
  usb: max3421-hcd: Fix crash on the driver removal
  usb: max3421-hcd: Remove function name from dev_dbg calls

 .../devicetree/bindings/usb/maxim,max3421-hcd.txt  |  19 +++
 drivers/usb/host/max3421-hcd.c | 131 
+

 2 files changed, 127 insertions(+), 23 deletions(-)
 create mode 100644 
Documentation/devicetree/bindings/usb/maxim,max3421-hcd.txt


--
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 3/3] usb: max3421-hcd: Remove function name from dev_dbg calls

[Alexander Amelkin]

NOTE:
Please don't use the plain text here as a patch because it most probably 
is corrupted by my webmail client.
Attached is a copy of the following text guaranteed to have correct 
tabs/spaces.

-
From b9a7559d24c0b2cb6e69124d861a943f79272681 Mon Sep 17 00:00:00 2001
From: Alexander Amelkin 
Date: Fri, 14 Apr 2017 18:01:58 +0300
Subject: [PATCH 3/3] usb: max3421-hcd: Remove function name from dev_dbg 
calls


The kernel dynamic debugging facility already has a
means for displaying the function name if the developer
wants to (the 'f' flag).

There is no need to hard-code output of the function
name into dev_dbg calls.

Signed-off-by: Alexander Amelkin 
---
 drivers/usb/host/max3421-hcd.c | 18 --
 1 file changed, 8 insertions(+), 10 deletions(-)

diff --git a/drivers/usb/host/max3421-hcd.c 
b/drivers/usb/host/max3421-hcd.c

index bd59c16..cfca8a2 100644
--- a/drivers/usb/host/max3421-hcd.c
+++ b/drivers/usb/host/max3421-hcd.c
@@ -706,8 +706,8 @@ max3421_select_and_start_urb(struct usb_hcd *hcd)
urb = list_first_entry(>urb_list, struct urb,
   urb_list);
if (urb->unlinked) {
-   dev_dbg(>dev, "%s: URB %p unlinked=%d",
-   __func__, urb, urb->unlinked);
+   dev_dbg(>dev, "URB %p unlinked=%d",
+   urb, urb->unlinked);
max3421_hcd->curr_urb = urb;
max3421_hcd->urb_done = 1;
spin_unlock_irqrestore(_hcd->lock,
@@ -815,8 +815,8 @@ max3421_check_unlink(struct usb_hcd *hcd)
list_for_each_entry_safe(urb, next, >urb_list, urb_list) {
if (urb->unlinked) {
retval = 1;
-   dev_dbg(>dev, "%s: URB %p unlinked=%d",
-   __func__, urb, urb->unlinked);
+   dev_dbg(>dev, "URB %p unlinked=%d",
+   urb, urb->unlinked);
usb_hcd_unlink_urb_from_ep(hcd, urb);
spin_unlock_irqrestore(_hcd->lock,
   flags);
@@ -912,8 +912,8 @@ max3421_handle_error(struct usb_hcd *hcd, u8 hrsl)
 * from; report error
 */
max3421_hcd->urb_done = hrsl_to_error[result_code];
-   dev_dbg(>dev, "%s: unexpected error HRSL=0x%02x",
-   __func__, hrsl);
+   dev_dbg(>dev, "unexpected error HRSL=0x%02x",
+   hrsl);
break;

case MAX3421_HRSL_TOGERR:
@@ -940,14 +940,12 @@ max3421_handle_error(struct usb_hcd *hcd, u8 hrsl)
else {
/* Based on ohci.h cc_to_err[]: */
max3421_hcd->urb_done = hrsl_to_error[result_code];
-   dev_dbg(>dev, "%s: unexpected error HRSL=0x%02x",
-   __func__, hrsl);
+   dev_dbg(>dev, "unexpected error HRSL=0x%02x", 
hrsl);
}
break;

case MAX3421_HRSL_STALL:
-   dev_dbg(>dev, "%s: unexpected error HRSL=0x%02x",
-   __func__, hrsl);
+   dev_dbg(>dev, "unexpected error HRSL=0x%02x", hrsl);
max3421_hcd->urb_done = hrsl_to_error[result_code];
break;

--
2.7.4

From b9a7559d24c0b2cb6e69124d861a943f79272681 Mon Sep 17 00:00:00 2001
From: Alexander Amelkin 
Date: Fri, 14 Apr 2017 18:01:58 +0300
Subject: [PATCH 3/3] usb: max3421-hcd: Remove function name from dev_dbg calls

The kernel dynamic debugging facility already has a
means for displaying the function name if the developer
wants to (the 'f' flag).

There is no need to hard-code output of the function
name into dev_dbg calls.

Signed-off-by: Alexander Amelkin 
---
 drivers/usb/host/max3421-hcd.c | 18 --
 1 file changed, 8 insertions(+), 10 deletions(-)

diff --git a/drivers/usb/host/max3421-hcd.c b/drivers/usb/host/max3421-hcd.c
index bd59c16..cfca8a2 100644
--- a/drivers/usb/host/max3421-hcd.c
+++ b/drivers/usb/host/max3421-hcd.c
@@ -706,8 +706,8 @@ max3421_select_and_start_urb(struct usb_hcd *hcd)
 			urb = list_first_entry(>urb_list, struct urb,
 	   urb_list);
 			if (urb->unlinked) {
-dev_dbg(>dev, "%s: URB %p unlinked=%d",
-	__func__, urb, urb->unlinked);
+dev_dbg(>dev, "URB %p unlinked=%d",
+	urb, urb->unlinked);
 max3421_hcd->curr_urb = urb;
 max3421_hcd->urb_done = 1;
 spin_unlock_irqrestore(_hcd->lock,
@@ -815,8 +815,8 @@ max3421_check_unlink(struct usb_hcd *hcd)
 		list_for_each_entry_safe(urb, next, 

[PATCH 2/3] usb: max3421-hcd: Fix crash on the driver removal

[Alexander Amelkin]

NOTE:
Please don't use the plain text here as a patch because it most probably 
is corrupted by my webmail client.
Attached is a copy of the following text guaranteed to have correct 
tabs/spaces.

-
From 8c4c65d3892df3721474023836216a02e03fb23e Mon Sep 17 00:00:00 2001
From: Alexander Amelkin 
Date: Fri, 14 Apr 2017 17:58:07 +0300
Subject: [PATCH 2/3] usb: max3421-hcd: Fix crash on the driver removal

The driver was calling kthread_stop inside a spin-locked
region while the thread was calling schedule() on a regular
basis. That resulted in panic due to 'scheduling while atomic'.

There was no need to get the spin-lock before stopping the
thread as thread stopping is asynchronous and the thread
only stops when it detects the stop flag set by kthread_stop(),
at which point it is not accessing any resources anyway.

Hence, this patch removes the spin-locking around the
kthread_stop() call.

Additionally, the allocated resources were not free'd in
the correct order. Some were not free'd at all. This patch
switches all resource allocations to devm_* functions
and also reorders deallocation to properly revert the
allocations (although not actually needed for devm-allocated
resources).

Signed-off-by: Alexander Amelkin 
---
 drivers/usb/host/max3421-hcd.c | 29 +++--
 1 file changed, 15 insertions(+), 14 deletions(-)

diff --git a/drivers/usb/host/max3421-hcd.c 
b/drivers/usb/host/max3421-hcd.c

index f600052..bd59c16 100644
--- a/drivers/usb/host/max3421-hcd.c
+++ b/drivers/usb/host/max3421-hcd.c
@@ -1925,10 +1925,10 @@ max3421_probe(struct spi_device *spi)
max3421_hcd_list = max3421_hcd;
INIT_LIST_HEAD(_hcd->ep_list);

-   max3421_hcd->tx = kmalloc(sizeof(*max3421_hcd->tx), GFP_KERNEL);
+	max3421_hcd->tx = devm_kzalloc(>dev, sizeof(*max3421_hcd->tx), 
GFP_KERNEL);

if (!max3421_hcd->tx)
goto error;
-   max3421_hcd->rx = kmalloc(sizeof(*max3421_hcd->rx), GFP_KERNEL);
+	max3421_hcd->rx = devm_kzalloc(>dev, sizeof(*max3421_hcd->rx), 
GFP_KERNEL);

if (!max3421_hcd->rx)
goto error;

@@ -1946,8 +1946,8 @@ max3421_probe(struct spi_device *spi)
goto error;
}

-   retval = request_irq(spi->irq, max3421_irq_handler,
-IRQF_TRIGGER_LOW, "max3421", hcd);
+   retval = devm_request_irq(>dev, spi->irq, max3421_irq_handler,
+ IRQF_TRIGGER_LOW, "max3421", hcd);
if (retval < 0) {
dev_err(>dev, "failed to request irq %d\n", spi->irq);
goto error;
@@ -1976,7 +1976,6 @@ max3421_remove(struct spi_device *spi)
 {
struct max3421_hcd *max3421_hcd = NULL, **prev;
struct usb_hcd *hcd = NULL;
-   unsigned long flags;

for (prev = _hcd_list; *prev; prev = &(*prev)->next) {
max3421_hcd = *prev;
@@ -1990,12 +1989,20 @@ max3421_remove(struct spi_device *spi)
spi);
return -ENODEV;
}
-   spin_lock_irqsave(_hcd->lock, flags);
+
+   devm_free_irq(>dev, spi->irq, hcd);
+
+   usb_remove_hcd(hcd);

kthread_stop(max3421_hcd->spi_thread);
-   *prev = max3421_hcd->next;

-   spin_unlock_irqrestore(_hcd->lock, flags);
+   devm_kfree(>dev, max3421_hcd->rx);
+   max3421_hcd->rx = NULL;
+   devm_kfree(>dev, max3421_hcd->tx);
+   max3421_hcd->tx = NULL;
+
+   *prev = max3421_hcd->next;
+   usb_put_hcd(hcd);

 #if defined(CONFIG_OF)
if (spi->dev.platform_data) {
@@ -2005,12 +2012,6 @@ max3421_remove(struct spi_device *spi)
}
 #endif

-   free_irq(spi->irq, hcd);
-
-   usb_remove_hcd(hcd);
-
-
-   usb_put_hcd(hcd);
return 0;
 }

--
2.7.4

From 8c4c65d3892df3721474023836216a02e03fb23e Mon Sep 17 00:00:00 2001
From: Alexander Amelkin 
Date: Fri, 14 Apr 2017 17:58:07 +0300
Subject: [PATCH 2/3] usb: max3421-hcd: Fix crash on the driver removal

The driver was calling kthread_stop inside a spin-locked
region while the thread was calling schedule() on a regular
basis. That resulted in panic due to 'scheduling while atomic'.

There was no need to get the spin-lock before stopping the
thread as thread stopping is asynchronous and the thread
only stops when it detects the stop flag set by kthread_stop(),
at which point it is not accessing any resources anyway.

Hence, this patch removes the spin-locking around the
kthread_stop() call.

Additionally, the allocated resources were not free'd in
the correct order. Some were not free'd at all. This patch
switches all resource allocations to devm_* functions
and also reorders deallocation to properly revert the
allocations (although not actually needed for devm-allocated
resources).

Signed-off-by: Alexander Amelkin 
---
 drivers/usb/host/max3421-hcd.c | 29 +++--
 1 file changed, 15 

[PATCH 1/3] usb: max3421-hcd: Add devicetree support to the driver

[Alexander Amelkin]

NOTE:
Please don't use the plain text here as a patch because it most probably 
is corrupted by my webmail client.
Attached is a copy of the following text guaranteed to have correct 
tabs/spaces.

-

Before this patch the max3421-hcd driver could only use
statically linked platform data to initialize its parameters.
This prevented it from being used on systems using device
tree.

The data taken from the device tree is put into dev->platform_data
when CONFIG_OF is enabled and the device is an OpenFirmware node.

The driver's 'compatible' string is 'maxim,max3421'

Binding documentation is also added with this patch.

Signed-off-by: Alexander Amelkin 
---
 .../devicetree/bindings/usb/maxim,max3421-hcd.txt  | 19 +
 drivers/usb/host/max3421-hcd.c | 96 
--

 2 files changed, 110 insertions(+), 5 deletions(-)
 create mode 100644 
Documentation/devicetree/bindings/usb/maxim,max3421-hcd.txt


diff --git a/Documentation/devicetree/bindings/usb/maxim,max3421-hcd.txt 
b/Documentation/devicetree/bindings/usb/maxim,max3421-hcd.txt

new file mode 100644
index 000..a8b9faa
--- /dev/null
+++ b/Documentation/devicetree/bindings/usb/maxim,max3421-hcd.txt
@@ -0,0 +1,19 @@
+* SPI-based USB host controller Maxim Integrated max3421e
+
+Required properties:
+- compatible: must be "maxim,max3421"
+- reg: chip select number to which the max3421 chip is connected
+  (depends on master SPI controller)
+- spi-max-frequency: the operational frequency, must not exceed 
<2600>
+- interrupt-parent: phandle of the associated GPIO controller to which 
the INT line

+  of max3421e chip is connected
+- interrupts: specification of the GPIO pin (in terms of the 
`interrupt-parent`)

+  to which INT line of max3421e chip is connected.
+  The driver configures MAX3421E for active low level triggered 
interrupts.

+  Configure your 'interrupt-parent' gpio controller accordingly.
+- vbus: 
+  GPOUTx is the number (1-8) of GPOUT pin of max3421e used to drive 
Vbus.

+  ACTIVE_LEVEL is 1 or 0.
+
+Don't forget to add pinctrl properties if you need some GPIO pins 
reconfigured

+for use as INT. See binding information for the pinctrl nodes.
diff --git a/drivers/usb/host/max3421-hcd.c 
b/drivers/usb/host/max3421-hcd.c

index 369869a..f600052 100644
--- a/drivers/usb/host/max3421-hcd.c
+++ b/drivers/usb/host/max3421-hcd.c
@@ -61,6 +61,12 @@
 #include 
 #include 

+#if defined(CONFIG_OF)
+#include 
+
+#define MAX3421_GPOUT_COUNT 8
+#endif
+
 #include 

 #define DRIVER_DESC"MAX3421 USB Host-Controller Driver"
@@ -1699,6 +1705,10 @@ max3421_hub_control(struct usb_hcd *hcd, u16 
type_req, u16 value, u16 index,

spin_lock_irqsave(_hcd->lock, flags);

pdata = spi->dev.platform_data;
+   if (!pdata) {
+   dev_err(>dev, "Device platform data is missing\n");
+   return -EFAULT;
+   }

switch (type_req) {
case ClearHubFeature:
@@ -1831,20 +1841,80 @@ static struct hc_driver max3421_hcd_desc = {
.bus_resume =   max3421_bus_resume,
 };

+#if defined(CONFIG_OF)
+static struct max3421_hcd_platform_data max3421_data;
+
+static const struct of_device_id max3421_dt_ids[] = {
+   { .compatible = "maxim,max3421", .data = _data, },
+   { /* sentinel */ }
+};
+MODULE_DEVICE_TABLE(of, max3421_dt_ids);
+#endif
+
 static int
 max3421_probe(struct spi_device *spi)
 {
struct max3421_hcd *max3421_hcd;
struct usb_hcd *hcd = NULL;
int retval = -ENOMEM;
+#if defined(CONFIG_OF)
+   struct max3421_hcd_platform_data *pdata = NULL;
+#endif

if (spi_setup(spi) < 0) {
dev_err(>dev, "Unable to setup SPI bus");
return -EFAULT;
}

-   hcd = usb_create_hcd(_hcd_desc, >dev,
-dev_name(>dev));
+   if (!spi->irq) {
+   dev_err(>dev, "Failed to get SPI IRQ for node '%s'\n", 
spi->dev.of_node->full_name);

+   return -EFAULT;
+   }
+
+#if defined(CONFIG_OF)
+   if (spi->dev.of_node) {
+   /* A temporary alias structure */
+   union {
+   uint32_t value[2];
+   struct {
+   uint32_t gpout;
+   uint32_t active_level;
+   };
+   } vbus;
+
+   if(!(pdata = devm_kzalloc(>dev, sizeof(*pdata), 
GFP_KERNEL))) {
+   dev_err(>dev, "failed to allocate memory for private 
data\n");

+   retval = -ENOMEM;
+   goto error;
+   }
+   spi->dev.platform_data = pdata;
+
+   if ((retval = of_property_read_u32_array(spi->dev.of_node, 
"vbus", vbus.value, 2))) {
+   dev_err(>dev, "device tree node property 'vbus' is 
missing\n");

+   goto error;
+   }
+   pdata->vbus_gpout = vbus.gpout;
+   pdata->vbus_active_level = vbus.active_level;
+   }
+   else
+#endif
+   pdata = spi->dev.platform_data;
+   if (!pdata) {
+   dev_err(>dev, "driver configuration data is not 
provided\n");

+   retval = -EFAULT;
+   goto error;
+   }
+   if (pdata->vbus_active_level > 1) {
+   dev_err(>dev, 

RE: [PATCH v4] usb:host:xhci:USB 3.1 speed

[yd_tseng]

Thanks for the hand:)

Thanks,
YD

> -Original Message-
> From: Mathias Nyman [mailto:mathias.ny...@linux.intel.com]
> Sent: Friday, May 26, 2017 6:50 PM
> To: YD; gre...@linuxfoundation.org; mathias.ny...@intel.com; linux-
> u...@vger.kernel.org
> Cc: yd_ts...@asmedia.com.tw
> Subject: Re: [PATCH v4] usb:host:xhci:USB 3.1 speed
> 
> On 26.05.2017 13:27, YD wrote:
> > From: YD Tseng 
> >
> > One of the xHCI host controllers supports both USB 3.1/3.0 extended
> > speed protocol lists. The content of the lists is shown as below.
> > In xhci-mem.c, the USB 3.1 speed is parsed first, the min_rev of
> > usb3_rhub is set as 0x10.  And then USB 3.0 is parsed.  However, the
> > min_rev of usb3_rhub will be changed to 0x00. If USB 3.1 device is
> > connected behind this host controller, the speed of USB 3.1 device
> > just reports 5G speed using lsusb.
> >
> >   00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F
> >00 01 08 00 00 00 00 00 40 00 00 00 00 00 00 00 00
> >10 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> >20 02 08 10 03 55 53 42 20 01 02 00 00 00 00 00 00 //USB 3.1
> >30 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> >40 02 08 00 03 55 53 42 20 03 06 00 00 00 00 00 00 //USB 3.0
> >50 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> >60 02 08 00 02 55 53 42 20 09 0E 19 00 00 00 00 00 //USB 2.0
> >70 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> >
> > This patch works around for parsing extended speed protocol lists. If
> > the xHCI controller supports USB 3.1 and 3.0 extended speed protocol,
> > it could show as one 3.1 roothub.
> >
> > Signed-off-by: YD Tseng 
> > ---
> 
> There is one small complaint from checkpatch about the commit message
itself:
> 
> WARNING: Possible unwrapped commit description (prefer a maximum 75 chars
> per line)
> #11:
> this host controller, the speed of USB 3.1 device just reports 5G speed
using
> 
> total: 0 errors, 1 warnings, 23 lines checked
> 
> 
> I'll fix that myself, no need to resend
> 
> Applied,
> Thanks
> -Mathias


==
This email and any attachments to it contain confidential information and are 
intended solely for the use of the individual to whom it 
is addressed.If you are not the intended recipient or receive it accidentally, 
please immediately notify the sender by e-mail and delete 
the message and any attachments from your computer system, and destroy all hard 
copies. If any, please be advised that any unauthorized 
disclosure, copying, distribution or any action taken or omitted in reliance on 
this, is illegal and prohibited. Furthermore, any views 
or opinions expressed are solely those of the author and do not represent those 
of ASMedia Technology Inc. Thank you for your cooperation.
==

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

Re: [PATCH 3/3] usb: typec: ucsi: Add ACPI driver

[Heikki Krogerus]

Hi,

On Thu, May 25, 2017 at 06:23:30AM -0700, Guenter Roeck wrote:
> > +   /*
> > +* NOTE: The memory region for the data structures is used also in an
> > +* operation region, which means ACPI has already reserved it. Therefore
> > +* it can not be requested here.
> > +*/
> > +   ua->ppm.data = devm_ioremap(>dev, res->start, resource_size(res));
> 
> devm_ioremap_resource() ?

devm_ioremap_resource() will try to request the region, and like I
tried to explain in the comment, it will fail as the region has
already been reserved by ACPI.


Thanks,

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

Re: [PATCH 2/3] usb: typec: Add support for UCSI interface

[Heikki Krogerus]

Hi,

On Thu, May 25, 2017 at 06:20:16AM -0700, Guenter Roeck wrote:
> On 05/16/2017 05:26 AM, Heikki Krogerus wrote:
> > UCSI - USB Type-C Connector System Software Interface - is a
> > specification that defines set of registers and data
> > structures for controlling the USB Type-C ports. It's
> > designed for systems where an embedded controller (EC) is in
> > charge of the USB Type-C PHY or USB Power Delivery
> > controller. It is designed for systems with EC, but it is
> > not limited to them, and for example some USB Power Delivery
> > controllers will use it as their direct control interface.
> > 
> > With UCSI the EC (or USB PD controller) acts as the port
> > manager, implementing all USB Type-C and Power Delivery state
> > machines. The OS can use the interfaces for reading the
> > status of the ports and controlling basic operations like
> > role swapping.
> > 
> > The UCSI specification highlights the fact that it does not
> > define the interface method (PCI/I2C/ACPI/etc.).
> > Therefore the driver is implemented as library and every
> > supported interface method needs its own driver. Driver for
> > ACPI is provided in separate patch following this one.
> > 
> > The initial driver includes support for all required
> > features from UCSI specification version 1.0 (getting
> > connector capabilities and status, and support for power and
> > data role swapping), but none of the optional UCSI features
> > (alternate modes, power source capabilities, and cable
> > capabilities).
> > 
> > Signed-off-by: Heikki Krogerus 
> > ---
> >   drivers/usb/typec/Kconfig   |   2 +
> >   drivers/usb/typec/Makefile  |   1 +
> >   drivers/usb/typec/ucsi/Kconfig  |  22 ++
> >   drivers/usb/typec/ucsi/Makefile |   7 +
> >   drivers/usb/typec/ucsi/debug.h  |  64 
> >   drivers/usb/typec/ucsi/trace.c  |   2 +
> >   drivers/usb/typec/ucsi/trace.h  | 143 
> >   drivers/usb/typec/ucsi/ucsi.c   | 770 
> > 
> >   drivers/usb/typec/ucsi/ucsi.h   | 329 +
> >   9 files changed, 1340 insertions(+)
> >   create mode 100644 drivers/usb/typec/ucsi/Kconfig
> >   create mode 100644 drivers/usb/typec/ucsi/Makefile
> >   create mode 100644 drivers/usb/typec/ucsi/debug.h
> >   create mode 100644 drivers/usb/typec/ucsi/trace.c
> >   create mode 100644 drivers/usb/typec/ucsi/trace.h
> >   create mode 100644 drivers/usb/typec/ucsi/ucsi.c
> >   create mode 100644 drivers/usb/typec/ucsi/ucsi.h
> > 
> > diff --git a/drivers/usb/typec/Kconfig b/drivers/usb/typec/Kconfig
> > index dfcfe459b7cf..bc1b7745f1d4 100644
> > --- a/drivers/usb/typec/Kconfig
> > +++ b/drivers/usb/typec/Kconfig
> > @@ -19,4 +19,6 @@ config TYPEC_WCOVE
> >   To compile this driver as module, choose M here: the module will be
> >   called typec_wcove
> > +source "drivers/usb/typec/ucsi/Kconfig"
> > +
> >   endmenu
> > diff --git a/drivers/usb/typec/Makefile b/drivers/usb/typec/Makefile
> > index b9cb862221af..bc214f15f1b5 100644
> > --- a/drivers/usb/typec/Makefile
> > +++ b/drivers/usb/typec/Makefile
> > @@ -1,2 +1,3 @@
> >   obj-$(CONFIG_TYPEC)   += typec.o
> >   obj-$(CONFIG_TYPEC_WCOVE) += typec_wcove.o
> > +obj-$(CONFIG_TYPEC_UCSI)   += ucsi/
> > diff --git a/drivers/usb/typec/ucsi/Kconfig b/drivers/usb/typec/ucsi/Kconfig
> > new file mode 100644
> > index ..679ba6648396
> > --- /dev/null
> > +++ b/drivers/usb/typec/ucsi/Kconfig
> > @@ -0,0 +1,22 @@
> > +config TYPEC_UCSI
> > +   tristate "USB Type-C Connector System Software Interface driver"
> > +   select TYPEC
> > +   help
> > + USB Type-C Connector System Software Interface (UCSI) is a
> > + specification for an interface that allows the operating system to
> > + control the USB Type-C ports. On UCSI system the USB Type-C ports
> > + function autonomously by default, but in order to get the status of
> > + the ports and support basic operations like role swapping, the driver
> > + is required. UCSI is available on most of the new Intel based systems
> > + that are equipped with Embedded Controller and USB Type-C ports.
> > +
> > + UCSI specification does not define the interface method, so depending
> > + on the platform, ACPI, PCI, I2C, etc. may be used. Therefore this
> > + driver only provides the core part, and separate drivers are needed
> > + for every supported interface method.
> > +
> > + The UCSI specification can be downloaded from:
> > + 
> > http://www.intel.com/content/www/us/en/io/universal-serial-bus/usb-type-c-ucsi-spec.html
> > +
> > + To compile the driver as a module, choose M here: the module will be
> > + called typec_ucsi.
> > diff --git a/drivers/usb/typec/ucsi/Makefile 
> > b/drivers/usb/typec/ucsi/Makefile
> > new file mode 100644
> > index ..87dd6ee6c9f3
> > --- /dev/null
> > +++ b/drivers/usb/typec/ucsi/Makefile
> > @@ -0,0 +1,7 @@
> > +CFLAGS_trace.o 

Re: [PATCH v4] usb:host:xhci:USB 3.1 speed

[Mathias Nyman]

On 26.05.2017 13:27, YD wrote:

From: YD Tseng 

One of the xHCI host controllers supports both USB 3.1/3.0 extended speed
protocol lists. The content of the lists is shown as below.
In xhci-mem.c, the USB 3.1 speed is parsed first, the min_rev of usb3_rhub
is set as 0x10.  And then USB 3.0 is parsed.  However, the min_rev of
usb3_rhub will be changed to 0x00. If USB 3.1 device is connected behind
this host controller, the speed of USB 3.1 device just reports 5G speed using
lsusb.

  00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F
   00 01 08 00 00 00 00 00 40 00 00 00 00 00 00 00 00
   10 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
   20 02 08 10 03 55 53 42 20 01 02 00 00 00 00 00 00 //USB 3.1
   30 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
   40 02 08 00 03 55 53 42 20 03 06 00 00 00 00 00 00 //USB 3.0
   50 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
   60 02 08 00 02 55 53 42 20 09 0E 19 00 00 00 00 00 //USB 2.0
   70 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

This patch works around for parsing extended speed protocol lists. If the
xHCI controller supports USB 3.1 and 3.0 extended speed protocol, it could
show as one 3.1 roothub.

Signed-off-by: YD Tseng 
---


There is one small complaint from checkpatch about the commit message itself:

WARNING: Possible unwrapped commit description (prefer a maximum 75 chars per 
line)
#11:
this host controller, the speed of USB 3.1 device just reports 5G speed using

total: 0 errors, 1 warnings, 23 lines checked


I'll fix that myself, no need to resend

Applied,
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] usb:host:xhci:USB 3.1 speed

[yd_tseng]

Update V4

Remove whitespace

> -Original Message-
> From: YD [mailto:yuhdar.ts...@gmail.com]
> Sent: Thursday, May 25, 2017 5:38 PM
> To: gre...@linuxfoundation.org; mathias.ny...@intel.com; linux-
> u...@vger.kernel.org
> Cc: yd_ts...@asmedia.com.tw
> Subject: [PATCH v3] usb:host:xhci:USB 3.1 speed
> 
> From: YD Tseng 
> 
> One of the xHCI host controllers supports both USB 3.1/3.0 extended speed
> protocol lists. The content of the lists is shown as below.
> In xhci-mem.c, the USB 3.1 speed is parsed first, the min_rev of usb3_rhub
is set
> as 0x10.  And then USB 3.0 is parsed.  However, the min_rev of usb3_rhub
will be
> changed to 0x00. If USB 3.1 device is connected behind this host
controller, the
> speed of USB 3.1 device just reports 5G speed using lsusb.
> 
>  00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F
>   00 01 08 00 00 00 00 00 40 00 00 00 00 00 00 00 00
>   10 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
>   20 02 08 10 03 55 53 42 20 01 02 00 00 00 00 00 00 //USB 3.1
>   30 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
>   40 02 08 00 03 55 53 42 20 03 06 00 00 00 00 00 00 //USB 3.0
>   50 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
>   60 02 08 00 02 55 53 42 20 09 0E 19 00 00 00 00 00 //USB 2.0
>   70 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 
> This patch works around for parsing extended speed protocol lists. If the
xHCI
> controller supports USB 3.1 and 3.0 extended speed protocol, it could show
as
> one 3.1 roothub.
> 
> Signed-off-by: YD Tseng 
> ---
>  drivers/usb/host/xhci-mem.c | 7 +--
>  1 file changed, 5 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/usb/host/xhci-mem.c b/drivers/usb/host/xhci-mem.c
index
> 1f1687e..fddf273 100644
> --- a/drivers/usb/host/xhci-mem.c
> +++ b/drivers/usb/host/xhci-mem.c
> @@ -2119,11 +2119,12 @@ static void xhci_add_in_port(struct xhci_hcd
*xhci,
> unsigned int num_ports,  {
>   u32 temp, port_offset, port_count;
>   int i;
> - u8 major_revision;
> + u8 major_revision, minor_revision;
>   struct xhci_hub *rhub;
> 
>   temp = readl(addr);
>   major_revision = XHCI_EXT_PORT_MAJOR(temp);
> + minor_revision = XHCI_EXT_PORT_MINOR(temp);
> 
>   if (major_revision == 0x03) {
>   rhub = >usb3_rhub;
> @@ -2137,7 +2138,9 @@ static void xhci_add_in_port(struct xhci_hcd *xhci,
> unsigned int num_ports,
>   return;
>   }
>   rhub->maj_rev = XHCI_EXT_PORT_MAJOR(temp);
> - rhub->min_rev = XHCI_EXT_PORT_MINOR(temp);
> +
> + if (rhub->min_rev < minor_revision)
> + rhub->min_rev = minor_revision;
> 
>   /* Port offset and count in the third dword, see section 7.2 */
>   temp = readl(addr + 2);
> --
> 2.7.4

==
This email and any attachments to it contain confidential information and are 
intended solely for the use of the individual to whom it 
is addressed.If you are not the intended recipient or receive it accidentally, 
please immediately notify the sender by e-mail and delete 
the message and any attachments from your computer system, and destroy all hard 
copies. If any, please be advised that any unauthorized 
disclosure, copying, distribution or any action taken or omitted in reliance on 
this, is illegal and prohibited. Furthermore, any views 
or opinions expressed are solely those of the author and do not represent those 
of ASMedia Technology Inc. Thank you for your cooperation.
==

--
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 v4] usb:host:xhci:USB 3.1 speed

[YD]

From: YD Tseng 

One of the xHCI host controllers supports both USB 3.1/3.0 extended speed
protocol lists. The content of the lists is shown as below.
In xhci-mem.c, the USB 3.1 speed is parsed first, the min_rev of usb3_rhub
is set as 0x10.  And then USB 3.0 is parsed.  However, the min_rev of
usb3_rhub will be changed to 0x00. If USB 3.1 device is connected behind
this host controller, the speed of USB 3.1 device just reports 5G speed using
lsusb.

 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F
  00 01 08 00 00 00 00 00 40 00 00 00 00 00 00 00 00
  10 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  20 02 08 10 03 55 53 42 20 01 02 00 00 00 00 00 00 //USB 3.1
  30 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  40 02 08 00 03 55 53 42 20 03 06 00 00 00 00 00 00 //USB 3.0
  50 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  60 02 08 00 02 55 53 42 20 09 0E 19 00 00 00 00 00 //USB 2.0
  70 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

This patch works around for parsing extended speed protocol lists. If the
xHCI controller supports USB 3.1 and 3.0 extended speed protocol, it could
show as one 3.1 roothub.

Signed-off-by: YD Tseng 
---
 drivers/usb/host/xhci-mem.c | 7 +--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/drivers/usb/host/xhci-mem.c b/drivers/usb/host/xhci-mem.c
index 1f1687e..fddf273 100644
--- a/drivers/usb/host/xhci-mem.c
+++ b/drivers/usb/host/xhci-mem.c
@@ -2119,11 +2119,12 @@ static void xhci_add_in_port(struct xhci_hcd *xhci, 
unsigned int num_ports,
 {
u32 temp, port_offset, port_count;
int i;
-   u8 major_revision;
+   u8 major_revision, minor_revision;
struct xhci_hub *rhub;

temp = readl(addr);
major_revision = XHCI_EXT_PORT_MAJOR(temp);
+   minor_revision = XHCI_EXT_PORT_MINOR(temp);

if (major_revision == 0x03) {
rhub = >usb3_rhub;
@@ -2137,7 +2138,9 @@ static void xhci_add_in_port(struct xhci_hcd *xhci, 
unsigned int num_ports,
return;
}
rhub->maj_rev = XHCI_EXT_PORT_MAJOR(temp);
-   rhub->min_rev = XHCI_EXT_PORT_MINOR(temp);
+
+   if (rhub->min_rev < minor_revision)
+   rhub->min_rev = minor_revision;

/* Port offset and count in the third dword, see section 7.2 */
temp = readl(addr + 2);
--
2.7.4

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

[PATCH] usb: Make use of ktime_* comparison functions

[Mariusz Skamra]

Start using ktime_* compare functions to make the code backportable.
Now that may be a bit tricky due to recent change of ktime_t.

Signed-off-by: Mariusz Skamra 
Acked-by: Kuppuswamy Sathyanarayanan 
---
 drivers/usb/chipidea/otg_fsm.c | 8 
 drivers/usb/host/ehci-timer.c  | 2 +-
 drivers/usb/host/fotg210-hcd.c | 2 +-
 3 files changed, 6 insertions(+), 6 deletions(-)

diff --git a/drivers/usb/chipidea/otg_fsm.c b/drivers/usb/chipidea/otg_fsm.c
index 93e24ce..949183e 100644
--- a/drivers/usb/chipidea/otg_fsm.c
+++ b/drivers/usb/chipidea/otg_fsm.c
@@ -234,7 +234,7 @@ static void ci_otg_add_timer(struct ci_hdrc *ci, enum 
otg_fsm_timer t)
ktime_set(timer_sec, timer_nsec));
ci->enabled_otg_timer_bits |= (1 << t);
if ((ci->next_otg_timer == NUM_OTG_FSM_TIMERS) ||
-   (ci->hr_timeouts[ci->next_otg_timer] >
+   ktime_after(ci->hr_timeouts[ci->next_otg_timer],
ci->hr_timeouts[t])) {
ci->next_otg_timer = t;
hrtimer_start_range_ns(>otg_fsm_hrtimer,
@@ -269,7 +269,7 @@ static void ci_otg_del_timer(struct ci_hdrc *ci, enum 
otg_fsm_timer t)
for_each_set_bit(cur_timer, _timer_bits,
NUM_OTG_FSM_TIMERS) {
if ((next_timer == NUM_OTG_FSM_TIMERS) ||
-   (ci->hr_timeouts[next_timer] <
+   
ktime_before(ci->hr_timeouts[next_timer],
 ci->hr_timeouts[cur_timer]))
next_timer = cur_timer;
}
@@ -397,13 +397,13 @@ static enum hrtimer_restart ci_otg_hrtimer_func(struct 
hrtimer *t)
 
now = ktime_get();
for_each_set_bit(cur_timer, _timer_bits, NUM_OTG_FSM_TIMERS) {
-   if (now >= ci->hr_timeouts[cur_timer]) {
+   if (ktime_compare(now, ci->hr_timeouts[cur_timer]) >= 0) {
ci->enabled_otg_timer_bits &= ~(1 << cur_timer);
if (otg_timer_handlers[cur_timer])
ret = otg_timer_handlers[cur_timer](ci);
} else {
if ((next_timer == NUM_OTG_FSM_TIMERS) ||
-   (ci->hr_timeouts[cur_timer] <
+   ktime_before(ci->hr_timeouts[cur_timer],
ci->hr_timeouts[next_timer]))
next_timer = cur_timer;
}
diff --git a/drivers/usb/host/ehci-timer.c b/drivers/usb/host/ehci-timer.c
index 3893b5b..0b6cdb7 100644
--- a/drivers/usb/host/ehci-timer.c
+++ b/drivers/usb/host/ehci-timer.c
@@ -424,7 +424,7 @@ static enum hrtimer_restart ehci_hrtimer_func(struct 
hrtimer *t)
 */
now = ktime_get();
for_each_set_bit(e, , EHCI_HRTIMER_NUM_EVENTS) {
-   if (now >= ehci->hr_timeouts[e])
+   if (ktime_compare(now, ehci->hr_timeouts[e]) >= 0)
event_handlers[e](ehci);
else
ehci_enable_event(ehci, e, false);
diff --git a/drivers/usb/host/fotg210-hcd.c b/drivers/usb/host/fotg210-hcd.c
index ced08dc..457cc65 100644
--- a/drivers/usb/host/fotg210-hcd.c
+++ b/drivers/usb/host/fotg210-hcd.c
@@ -1380,7 +1380,7 @@ static enum hrtimer_restart fotg210_hrtimer_func(struct 
hrtimer *t)
 */
now = ktime_get();
for_each_set_bit(e, , FOTG210_HRTIMER_NUM_EVENTS) {
-   if (now >= fotg210->hr_timeouts[e])
+   if (ktime_compare(now, fotg210->hr_timeouts[e]) >= 0)
event_handlers[e](fotg210);
else
fotg210_enable_event(fotg210, e, false);
-- 
2.1.4



Intel Technology Poland sp. z o.o.
ul. Slowackiego 173 | 80-298 Gdansk | Sad Rejonowy Gdansk Polnoc | VII Wydzial 
Gospodarczy Krajowego Rejestru Sadowego - KRS 101882 | NIP 957-07-52-316 | 
Kapital zakladowy 200.000 PLN.

Ta wiadomosc wraz z zalacznikami jest przeznaczona dla okreslonego adresata i 
moze zawierac informacje poufne. W razie przypadkowego otrzymania tej 
wiadomosci, prosimy o powiadomienie nadawcy oraz trwale jej usuniecie; 
jakiekolwiek
przegladanie lub rozpowszechnianie jest zabronione.
This e-mail and any attachments may contain confidential material for the sole 
use of the intended recipient(s). If you are not the intended recipient, please 
contact the sender and delete all copies; any review or distribution by
others is strictly prohibited.

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

Re: [PATCH v2] usb:host:xhci AMD Promontory USB disable port support

[Greg KH]

On Fri, May 26, 2017 at 05:35:24PM +0800, Jiahau Chang wrote:
>  There is some limitation for AMD Promontory xHCI host to disable USB port
>  function. It will enable USB wake-up function then cause USB disable port 
>  feature to fail.  Workaround this issue on Promontory xHCI host is clear
>  PORT_WAKE_BITS.
> 
> Signed-off-by: Jiahau Chang 
> ---
>  drivers/usb/host/xhci-hub.c | 3 +--
>  1 file changed, 1 insertion(+), 2 deletions(-)

What changed from v1?  Always put that information below the --- line,
as Documentation/SubmittingPatches describes.

And why the leading space on the changelog?

thanks,

greg k-h


> 
> diff --git a/drivers/usb/host/xhci-hub.c b/drivers/usb/host/xhci-hub.c
> index 51e408b..fa5ef22 100644
> --- a/drivers/usb/host/xhci-hub.c
> +++ b/drivers/usb/host/xhci-hub.c
> @@ -1224,7 +1224,7 @@ int xhci_hub_control(struct usb_hcd *hcd, u16 typeReq, 
> u16 wValue,
>   "actual port %d status  = 
> 0x%x\n",
>   wIndex, temp);
>   }
> -  else { 
> +  else {

This needs to go up one line.

>   xhci_set_remote_wake_mask(xhci, port_array,
>   wIndex, wake_mask);
>   temp = readl(port_array[wIndex]);
> @@ -1469,7 +1469,6 @@ int xhci_bus_suspend(struct usb_hcd *hcd)
>   t2 |= PORT_WKOC_E | PORT_WKCONN_E;
>   t2 &= ~PORT_WKDISC_E;
>   }
> - 

Your patch does nothing here, are you sure you didn't just make this
against your last patch?

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: [PATCH v2] usb:host:xhci AMD Promontory USB disable port support

[Sergei Shtylyov]

Hello!

On 5/26/2017 12:35 PM, Jiahau Chang wrote:


 There is some limitation for AMD Promontory xHCI host to disable USB port
 function. It will enable USB wake-up function then cause USB disable port
 feature to fail.  Workaround this issue on Promontory xHCI host is clear
 PORT_WAKE_BITS.

Signed-off-by: Jiahau Chang 
---
 drivers/usb/host/xhci-hub.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/drivers/usb/host/xhci-hub.c b/drivers/usb/host/xhci-hub.c
index 51e408b..fa5ef22 100644
--- a/drivers/usb/host/xhci-hub.c
+++ b/drivers/usb/host/xhci-hub.c
@@ -1224,7 +1224,7 @@ int xhci_hub_control(struct usb_hcd *hcd, u16 typeReq, 
u16 wValue,
"actual port %d status  = 
0x%x\n",
wIndex, temp);
}
-else { 
+else {


   Unrelated whitespace change (and not even being enough here).


xhci_set_remote_wake_mask(xhci, port_array,
wIndex, wake_mask);
temp = readl(port_array[wIndex]);
@@ -1469,7 +1469,6 @@ int xhci_bus_suspend(struct usb_hcd *hcd)
t2 |= PORT_WKOC_E | PORT_WKCONN_E;
t2 &= ~PORT_WKDISC_E;
}
-   


   Again.


if ((xhci->quirks & XHCI_U2_DISABLE_WAKE) && (hcd->speed 
< HCD_USB3))
t2 &= ~PORT_WAKE_BITS;
} else


   The real question is where's the related changes are? :-)

MBR, Sergei

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

[Jiahau Chang]

 There is some limitation for AMD Promontory xHCI host to disable USB port
 function. It will enable USB wake-up function then cause USB disable port 
 feature to fail.  Workaround this issue on Promontory xHCI host is clear
 PORT_WAKE_BITS.

Signed-off-by: Jiahau Chang 
---
 drivers/usb/host/xhci-hub.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/drivers/usb/host/xhci-hub.c b/drivers/usb/host/xhci-hub.c
index 51e408b..fa5ef22 100644
--- a/drivers/usb/host/xhci-hub.c
+++ b/drivers/usb/host/xhci-hub.c
@@ -1224,7 +1224,7 @@ int xhci_hub_control(struct usb_hcd *hcd, u16 typeReq, 
u16 wValue,
"actual port %d status  = 
0x%x\n",
wIndex, temp);
}
-else { 
+else {
xhci_set_remote_wake_mask(xhci, port_array,
wIndex, wake_mask);
temp = readl(port_array[wIndex]);
@@ -1469,7 +1469,6 @@ int xhci_bus_suspend(struct usb_hcd *hcd)
t2 |= PORT_WKOC_E | PORT_WKCONN_E;
t2 &= ~PORT_WKDISC_E;
}
-   
if ((xhci->quirks & XHCI_U2_DISABLE_WAKE) && 
(hcd->speed < HCD_USB3))
t2 &= ~PORT_WAKE_BITS;
} else
-- 
2.7.4

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

Re: [RFC] usb-phy-generic: Add support to SMSC USB3315

[Fabien Lahoudere]

Hello

I modify ci_hrdc_imx_probe to bypass "data->phy = 
devm_usb_get_phy_by_phandle(>dev,
"fsl,usbphy", 0);". Everything works as expected and call ci_ulpi_init.

The problem is that in ci_ulpi_init, before calling "ci->ulpi = 
ulpi_register_interface(ci->dev,
>ulpi_ops);" (to initialize our phy), "hw_phymode_configure(ci);" is called 
which is the
original function that make our system to hang.

Our phy is not initialised before calling ulpi_register_interface so I don't 
understand how the phy
can reply if it is not out of reset state.

The conclusion is that using ulpi_bus to manage our phy doesn't improve and we 
reach the same issue.

I will try to check if we don't do bad things in hw_phymode_configure.
If anyone have an idea it is welcome??

Fabien

On Thu, 2017-05-25 at 12:36 +0200, Fabien Lahoudere wrote:
> On Tue, 2017-05-23 at 14:00 -0700, Stephen Boyd wrote:
> > On 05/23, Fabien Lahoudere wrote:
> > > Hi,
> > > 
> > > We investigate on the topic and now our device tree look like:
> > > 
> > > in imx53.dtsi:
> > > 
> > > usbh2: usb@53f80400 {
> > >   compatible = "fsl,imx53-usb", "fsl,imx27-usb";
> > > reg = <0x53f80400 0x0200>;
> > > interrupts = <16>;
> > > clocks = < IMX5_CLK_USBOH3_GATE>;
> > > fsl,usbmisc = < 2>;
> > > dr_mode = "host";
> > > status = "disabled";
> > > };
> > > 
> > > usbmisc: usbmisc@53f80800 {
> > >   #index-cells = <1>;
> > >   compatible = "fsl,imx53-usbmisc";
> > >   reg = <0x53f80800 0x200>;
> > >   clocks = < IMX5_CLK_USBOH3_GATE>;
> > > };
> > > 
> > > and in our dts:
> > > 
> > >  {
> > > pinctrl-names = "default";
> > >   pinctrl-0 = <_usbh2>;
> > >   disable-int60ck;
> > > dr_mode = "host";
> > > //fsl,usbphy = <>;
> > > vbus-supply = <_usbh2_vbus>;
> > > status = "okay";
> > >   ulpi {
> > > phy {
> > > compatible = "smsc,usb3315-ulpi";
> > > reset-gpios = < 4 GPIO_ACTIVE_LOW>;
> > >   clock-names = "main_clk";
> > >   /*
> > >  * Hardware uses CKO2 at 24MHz at several places. 
> > > Set the parent
> > >    *  clock of CKO2 to OSC.
> > >  */
> > >   clock-frequency = <2400>;
> > >   clocks = < IMX5_CLK_CKO2>;
> > > assigned-clocks = < IMX5_CLK_CKO2_SEL>, 
> > > < IMX5_CLK_OSC>;
> > >   assigned-clock-parents = < IMX5_CLK_OSC>;
> > > status = "okay";
> > > };
> > > };
> > > };
> > > 
> > > And we create a basic driver to check what happened:
> > > 
> > > static int smsc_usb3315_phy_probe(struct ulpi *ulpi)
> > > {
> > > printk(KERN_ERR "Fabien: %s:%d-%s\n", __FILE__, __LINE__, 
> > > __func__);
> > > 
> > > return 0;
> > > }
> > > 
> > > static const struct of_device_id smsc_usb3315_phy_match[] = {
> > > { .compatible = "smsc,usb3315-phy", },
> > > { }
> > > };
> > > MODULE_DEVICE_TABLE(of, smsc_usb3315_phy_match);
> > > 
> > > static struct ulpi_driver smsc_usb3315_phy_driver = {
> > > .probe = smsc_usb3315_phy_probe,
> > > .driver = {
> > > .name = "smsc_usb3315_phy",
> > > .of_match_table = smsc_usb3315_phy_match,
> > > },
> > > };
> > > module_ulpi_driver(smsc_usb3315_phy_driver);
> > > 
> > > /*MODULE_ALIAS("platform:usb_phy_generic");*/
> > > MODULE_AUTHOR("GE Healthcare");
> > > MODULE_DESCRIPTION("SMSC USB 3315 ULPI Phy driver");
> > > MODULE_LICENSE("GPL v2");
> > > 
> > > I checked that the driver is registered by 
> > > drivers/usb/common/ulpi.c:__ulpi_register_driver
> > > successfully.
> > 
> > Does the ulpi device have some vendor/product ids associated
> > with it? The design is made to only fallback to matching the
> > device to driver based on DT if the ulpi vendor id is 0.
> > Otherwise, if vendor is non-zero you'll need to have a
> > ulpi_device_id id table in your ulpi_driver structure.
> > 
> 
> Hi,
> 
> Thanks Stephen for your reply.
> Indeed we have a vendor/product so I modify my code but without effect.
> 
> After looking at the ulpi source code in the kernel, it seems that I need to 
> call
> ulpi_register_interface. ci_hdrc_probe should be called to execute the ulpi 
> init.
> 
> The problem is that we replace "fsl,usbphy = <>;" by an ulpi node but 
> ci_hdrc_imx_probe
> fail
> because of "data->phy = devm_usb_get_phy_by_phandle(>dev, "fsl,usbphy", 
> 0);"
> 
> So I will try to adapt ci_hdrc_imx_probe to continue phy initialisation if 
> fsl,usbphy is missing.
> Is it the good way to proceed?
> 
> Thanks for any advice
> Fabien
> 
--
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/3] usb: host: ohci-platform: Add basic runtime PM support

[Roger Quadros]

On 25/05/17 19:13, Tony Lindgren wrote:
> This is needed in preparation of adding support for omap3 and
> later OHCI. The runtime PM will only do something on platforms
> that implement it.
> 
> Cc: devicet...@vger.kernel.org
> Cc: Hans de Goede 
> Cc: Rob Herring 
> Cc: Roger Quadros 
> Cc: Sebastian Reichel 
> Cc: Yoshihiro Shimoda 
> Signed-off-by: Tony Lindgren 

Acked-by: Roger Quadros 

> ---
>  drivers/usb/host/ohci-platform.c | 8 
>  1 file changed, 8 insertions(+)
> 
> diff --git a/drivers/usb/host/ohci-platform.c 
> b/drivers/usb/host/ohci-platform.c
> --- a/drivers/usb/host/ohci-platform.c
> +++ b/drivers/usb/host/ohci-platform.c
> @@ -24,6 +24,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -242,6 +243,8 @@ static int ohci_platform_probe(struct platform_device 
> *dev)
>   }
>  #endif
>  
> + pm_runtime_set_active(>dev);
> + pm_runtime_enable(>dev);
>   if (pdata->power_on) {
>   err = pdata->power_on(dev);
>   if (err < 0)
> @@ -271,6 +274,7 @@ static int ohci_platform_probe(struct platform_device 
> *dev)
>   if (pdata->power_off)
>   pdata->power_off(dev);
>  err_reset:
> + pm_runtime_disable(>dev);
>   while (--rst >= 0)
>   reset_control_assert(priv->resets[rst]);
>  err_put_clks:
> @@ -292,6 +296,7 @@ static int ohci_platform_remove(struct platform_device 
> *dev)
>   struct ohci_platform_priv *priv = hcd_to_ohci_priv(hcd);
>   int clk, rst;
>  
> + pm_runtime_get_sync(>dev);
>   usb_remove_hcd(hcd);
>  
>   if (pdata->power_off)
> @@ -305,6 +310,9 @@ static int ohci_platform_remove(struct platform_device 
> *dev)
>  
>   usb_put_hcd(hcd);
>  
> + pm_runtime_put_sync(>dev);
> + pm_runtime_disable(>dev);
> +
>   if (pdata == _platform_defaults)
>   dev->dev.platform_data = NULL;
>  
> 

-- 
cheers,
-roger
--
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:host:xhci AMD Promontory USB disable port support

[Greg KH]

On Fri, May 26, 2017 at 09:44:17AM +0800, Jiahau Chang wrote:
> There is some limitation for AMD Promontory xHCI host to
>  disable USB port function. It will enable USB wake-up function then cause USB
>  disable port feature to fail. 
> Workaround this issue on Promontory xHCI host
>  is clear PORT_WAKE_BITS.
> 
> Signed-off-by: Jiahau Chang 
> ---
>  drivers/usb/host/xhci-hub.c | 20 +++-
>  drivers/usb/host/xhci-pci.c | 13 +
>  drivers/usb/host/xhci.h |  2 ++
>  3 files changed, 30 insertions(+), 5 deletions(-)
> 
> diff --git a/drivers/usb/host/xhci-hub.c b/drivers/usb/host/xhci-hub.c
> index 0dde49c..252c278 100644
> --- a/drivers/usb/host/xhci-hub.c
> +++ b/drivers/usb/host/xhci-hub.c
> @@ -1218,12 +1218,19 @@ int xhci_hub_control(struct usb_hcd *hcd, u16 
> typeReq, u16 wValue,
>   xhci_dbg(xhci, "set port reset, actual port %d status  
> = 0x%x\n", wIndex, temp);
>   break;
>   case USB_PORT_FEAT_REMOTE_WAKE_MASK:
> - xhci_set_remote_wake_mask(xhci, port_array,
> + if((xhci->quirks & XHCI_U2_DISABLE_WAKE) &&(hcd->speed 
> < HCD_USB3)) {
> + temp = readl(port_array[wIndex]);
> + xhci_dbg(xhci, "skip set port remote wake mask, 
> "
> + "actual port %d status  = 
> 0x%x\n",
> + wIndex, temp);
> + }else{  
> + xhci_set_remote_wake_mask(xhci, port_array,
>   wIndex, wake_mask);

ALWAYS run your patches through scripts/checkpatch.pl so you don't get
grumpy emails from maintainers telling you to run your patch through
scripts/checkpatch.pl :)

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