[REGRESSION] asix: Lots of asix_rx_fixup() errors and slow transmissions

2016-05-02 Thread John Stultz
In testing with HiKey, we found that since commit 3f30b158eba5c60
(asix: On RX avoid creating bad Ethernet frames), we're seeing lots of
noise during network transfers:

[  239.027993] asix 1-1.1:1.0 eth0: asix_rx_fixup() Data Header
synchronisation was lost, remaining 988
[  239.037310] asix 1-1.1:1.0 eth0: asix_rx_fixup() Bad Header Length
0x54ebb5ec, offset 4
[  239.045519] asix 1-1.1:1.0 eth0: asix_rx_fixup() Bad Header Length
0xcdffe7a2, offset 4
[  239.275044] asix 1-1.1:1.0 eth0: asix_rx_fixup() Data Header
synchronisation was lost, remaining 988
[  239.284355] asix 1-1.1:1.0 eth0: asix_rx_fixup() Bad Header Length
0x1d36f59d, offset 4
[  239.292541] asix 1-1.1:1.0 eth0: asix_rx_fixup() Bad Header Length
0xaef3c1e9, offset 4
[  239.518996] asix 1-1.1:1.0 eth0: asix_rx_fixup() Data Header
synchronisation was lost, remaining 988
[  239.528300] asix 1-1.1:1.0 eth0: asix_rx_fixup() Bad Header Length
0x2881912, offset 4
[  239.536413] asix 1-1.1:1.0 eth0: asix_rx_fixup() Bad Header Length
0x5638f7e2, offset 4


And network throughput ends up being pretty bursty and slow with a
overall throughput of at best ~30kB/s.

Looking through the commits since the v4.1 kernel where we didn't see
this, I narrowed the regression down, and reverting the following two
commits seems to avoid the problem:

6a570814cd430fa5ef4f278e8046dcf12ee63f13 asix: Continue processing URB
if no RX netdev buffer
3f30b158eba5c604b6e0870027eef5d19fc9271d asix: On RX avoid creating
bad Ethernet frames

With these reverted, we don't see all the error messages, and we see
better ~1.1MB/s throughput (I've got a mouse plugged in, so I think
the usb host is only running at "full-speed" mode here).

This worries me some, as the patches seem to describe trying to fix
the issue they seem to cause, so I suspect a revert isn't the correct
solution, but am not sure why we're having such trouble and the patch
authors did not.  I'd be happy to do further testing of patches if
folks have any ideas.

Originally Reported-by: Yongqin Liu 

thanks
-john
--
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: [RESEND PATCH v10 4/4] power: wm831x_power: Support USB charger current limit management

2016-05-02 Thread Manish Badarkhe
On Tue, May 3, 2016 at 9:00 AM, Baolin Wang  wrote:
> Integrate with the newly added USB charger interface to limit the current
> we draw from the USB input based on the input device configuration
> identified by the USB stack, allowing us to charge more quickly from high
> current inputs without drawing more current than specified from others.
>
> Signed-off-by: Mark Brown 
> Signed-off-by: Baolin Wang 
> Acked-by: Lee Jones 
> Acked-by: Charles Keepax 
> Acked-by: Peter Chen 
> Acked-by: Sebastian Reichel 
> ---
>  drivers/power/wm831x_power.c |   69 
> ++
>  include/linux/mfd/wm831x/pdata.h |3 ++
>  2 files changed, 72 insertions(+)
>
> diff --git a/drivers/power/wm831x_power.c b/drivers/power/wm831x_power.c
> index 7082301..cef1812 100644
> --- a/drivers/power/wm831x_power.c
> +++ b/drivers/power/wm831x_power.c
> @@ -13,6 +13,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>
>  #include 
>  #include 
> @@ -31,6 +32,8 @@ struct wm831x_power {
> char usb_name[20];
> char battery_name[20];
> bool have_battery;
> +   struct usb_charger *usb_charger;
> +   struct notifier_block usb_notify;
>  };
>
>  static int wm831x_power_check_online(struct wm831x *wm831x, int supply,
> @@ -125,6 +128,43 @@ static enum power_supply_property wm831x_usb_props[] = {
> POWER_SUPPLY_PROP_VOLTAGE_NOW,
>  };
>
> +/* In milliamps */
> +static const unsigned int wm831x_usb_limits[] = {
> +   0,
> +   2,
> +   100,
> +   500,
> +   900,
> +   1500,
> +   1800,
> +   550,
> +};

Just for curiosity, How these current limits are getting decided?
Can we have some proper defines over here so that it can be grasped easily?

Thanks
Manish Badarkhe
--
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


[RESEND PATCH v10 1/4] gadget: Introduce the usb charger framework

2016-05-02 Thread Baolin Wang
This patch introduces the usb charger driver based on usb gadget that
makes an enhancement to a power driver. It works well in practice but
that requires a system with suitable hardware.

The basic conception of the usb charger is that, when one usb charger
is added or removed by reporting from the usb gadget state change or
the extcon device state change, the usb charger will report to power
user to set the current limitation.

The usb charger will register notifiees on the usb gadget or the extcon
device to get notified the usb charger state. It also supplies the
notification mechanism to userspace When the usb charger state is changed.

Power user will register a notifiee on the usb charger to get notified
by status changes from the usb charger. It will report to power user
to set the current limitation when detecting the usb charger is added
or removed from extcon device state or usb gadget state.

This patch doesn't yet integrate with the gadget code, so some functions
which rely on the 'gadget' are not completed, that will be implemented
in the following patches.

Signed-off-by: Baolin Wang 
---
 drivers/usb/gadget/Kconfig   |7 +
 drivers/usb/gadget/udc/Makefile  |1 +
 drivers/usb/gadget/udc/charger.c |  729 ++
 include/linux/usb/charger.h  |  173 +
 include/uapi/linux/usb/charger.h |   31 ++
 5 files changed, 941 insertions(+)
 create mode 100644 drivers/usb/gadget/udc/charger.c
 create mode 100644 include/linux/usb/charger.h
 create mode 100644 include/uapi/linux/usb/charger.h

diff --git a/drivers/usb/gadget/Kconfig b/drivers/usb/gadget/Kconfig
index af5d922..82a5b3c 100644
--- a/drivers/usb/gadget/Kconfig
+++ b/drivers/usb/gadget/Kconfig
@@ -133,6 +133,13 @@ config U_SERIAL_CONSOLE
help
   It supports the serial gadget can be used as a console.
 
+config USB_CHARGER
+   bool "USB charger support"
+   help
+ The usb charger driver based on the usb gadget that makes an
+ enhancement to a power driver which can set the current limitation
+ when the usb charger is added or removed.
+
 source "drivers/usb/gadget/udc/Kconfig"
 
 #
diff --git a/drivers/usb/gadget/udc/Makefile b/drivers/usb/gadget/udc/Makefile
index dfee534..0e9564c 100644
--- a/drivers/usb/gadget/udc/Makefile
+++ b/drivers/usb/gadget/udc/Makefile
@@ -2,6 +2,7 @@
 # USB peripheral controller drivers
 #
 obj-$(CONFIG_USB_GADGET)   += udc-core.o
+obj-$(CONFIG_USB_CHARGER)  += charger.o
 obj-$(CONFIG_USB_DUMMY_HCD)+= dummy_hcd.o
 obj-$(CONFIG_USB_NET2272)  += net2272.o
 obj-$(CONFIG_USB_NET2280)  += net2280.o
diff --git a/drivers/usb/gadget/udc/charger.c b/drivers/usb/gadget/udc/charger.c
new file mode 100644
index 000..e24cb0a
--- /dev/null
+++ b/drivers/usb/gadget/udc/charger.c
@@ -0,0 +1,729 @@
+/*
+ * charger.c -- USB charger driver
+ *
+ * Copyright (C) 2015 Linaro Ltd.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define DEFAULT_SDP_CUR_LIMIT  500
+#define DEFAULT_SDP_CUR_LIMIT_SS   900
+#define DEFAULT_DCP_CUR_LIMIT  1500
+#define DEFAULT_CDP_CUR_LIMIT  1500
+#define DEFAULT_ACA_CUR_LIMIT  1500
+
+static DEFINE_IDA(usb_charger_ida);
+struct class *usb_charger_class;
+static unsigned int usb_charger_get_cur_limit(struct usb_charger *uchger);
+
+static struct usb_charger *dev_to_uchger(struct device *dev)
+{
+   return container_of(dev, struct usb_charger, dev);
+}
+
+/*
+ * charger_current_show() - Show the charger current limit.
+ */
+static ssize_t charger_current_show(struct device *dev,
+   struct device_attribute *attr,
+   char *buf)
+{
+   struct usb_charger *uchger = dev_to_uchger(dev);
+
+   return sprintf(buf, "%u\n", usb_charger_get_cur_limit(uchger));
+}
+static DEVICE_ATTR_RO(charger_current);
+
+/*
+ * charger_type_show() - Show the charger type.
+ *
+ * It can be SDP/DCP/CDP/ACA type, else for unknown type.
+ */
+static ssize_t charger_type_show(struct device *dev,
+struct device_attribute *attr,
+char *buf)
+{
+   struct usb_charger *uchger = dev_to_uchger(dev);
+   int cnt;
+
+   switch (uchger->type) {
+   case SDP_TYPE:
+   cnt = sprintf(buf, "%s\n", "SDP");
+   break;
+   case DCP_TYPE:
+   cnt = sprintf(buf, "%s\n", "DCP");
+   break;
+   case CDP_TYPE:
+   cnt = sprintf(buf, "%s\n", "CDP");
+   break;
+   case ACA_TYPE:
+   cnt = sprintf(buf, "%s\n", "ACA");
+   break;
+   default:
+ 

[RESEND PATCH v10 3/4] gadget: Integrate with the usb gadget supporting for usb charger

2016-05-02 Thread Baolin Wang
When the usb gadget supporting for usb charger is ready, the usb charger
can implement the usb_charger_plug_by_gadget() function and usb_charger_exit()
function by getting 'struct usb_charger' from 'struct gadget'.

Signed-off-by: Baolin Wang 
---
 drivers/usb/gadget/udc/charger.c |   39 +-
 1 file changed, 38 insertions(+), 1 deletion(-)

diff --git a/drivers/usb/gadget/udc/charger.c b/drivers/usb/gadget/udc/charger.c
index e24cb0a..ee711cd 100644
--- a/drivers/usb/gadget/udc/charger.c
+++ b/drivers/usb/gadget/udc/charger.c
@@ -527,6 +527,30 @@ usb_charger_plug_by_extcon(struct notifier_block *nb,
 int usb_charger_plug_by_gadget(struct usb_gadget *gadget,
   unsigned long state)
 {
+   struct usb_charger *uchger = gadget->charger;
+   enum usb_charger_state uchger_state;
+
+   if (WARN(!uchger, "charger can not be NULL"))
+   return -EINVAL;
+
+   /*
+* Report event to power to setting the current limitation
+* for this usb charger when one usb charger state is changed
+* with detecting by usb gadget state.
+*/
+   if (uchger->old_gadget_state != state) {
+   uchger->old_gadget_state = state;
+
+   if (state >= USB_STATE_ATTACHED)
+   uchger_state = USB_CHARGER_PRESENT;
+   else if (state == USB_STATE_NOTATTACHED)
+   uchger_state = USB_CHARGER_REMOVE;
+   else
+   uchger_state = USB_CHARGER_DEFAULT;
+
+   usb_charger_notify_others(uchger, uchger_state);
+   }
+
return 0;
 }
 EXPORT_SYMBOL_GPL(usb_charger_plug_by_gadget);
@@ -683,6 +707,7 @@ int usb_charger_init(struct usb_gadget *ugadget)
 
/* register a notifier on a usb gadget device */
uchger->gadget = ugadget;
+   ugadget->charger = uchger;
uchger->old_gadget_state = ugadget->state;
 
/* register a new usb charger */
@@ -703,7 +728,19 @@ fail:
 
 int usb_charger_exit(struct usb_gadget *ugadget)
 {
-   return 0;
+   struct usb_charger *uchger = ugadget->charger;
+
+   if (WARN(!uchger, "charger can not be NULL"))
+   return -EINVAL;
+
+   if (uchger->extcon_dev)
+   extcon_unregister_notifier(uchger->extcon_dev,
+  EXTCON_USB,
+  >extcon_nb.nb);
+
+   ida_simple_remove(_charger_ida, uchger->id);
+
+   return usb_charger_unregister(uchger);
 }
 
 static int __init usb_charger_class_init(void)
-- 
1.7.9.5

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


[RESEND PATCH v10 4/4] power: wm831x_power: Support USB charger current limit management

2016-05-02 Thread Baolin Wang
Integrate with the newly added USB charger interface to limit the current
we draw from the USB input based on the input device configuration
identified by the USB stack, allowing us to charge more quickly from high
current inputs without drawing more current than specified from others.

Signed-off-by: Mark Brown 
Signed-off-by: Baolin Wang 
Acked-by: Lee Jones 
Acked-by: Charles Keepax 
Acked-by: Peter Chen 
Acked-by: Sebastian Reichel 
---
 drivers/power/wm831x_power.c |   69 ++
 include/linux/mfd/wm831x/pdata.h |3 ++
 2 files changed, 72 insertions(+)

diff --git a/drivers/power/wm831x_power.c b/drivers/power/wm831x_power.c
index 7082301..cef1812 100644
--- a/drivers/power/wm831x_power.c
+++ b/drivers/power/wm831x_power.c
@@ -13,6 +13,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 #include 
@@ -31,6 +32,8 @@ struct wm831x_power {
char usb_name[20];
char battery_name[20];
bool have_battery;
+   struct usb_charger *usb_charger;
+   struct notifier_block usb_notify;
 };
 
 static int wm831x_power_check_online(struct wm831x *wm831x, int supply,
@@ -125,6 +128,43 @@ static enum power_supply_property wm831x_usb_props[] = {
POWER_SUPPLY_PROP_VOLTAGE_NOW,
 };
 
+/* In milliamps */
+static const unsigned int wm831x_usb_limits[] = {
+   0,
+   2,
+   100,
+   500,
+   900,
+   1500,
+   1800,
+   550,
+};
+
+static int wm831x_usb_limit_change(struct notifier_block *nb,
+  unsigned long limit, void *data)
+{
+   struct wm831x_power *wm831x_power = container_of(nb,
+struct wm831x_power,
+usb_notify);
+   unsigned int i, best;
+
+   /* Find the highest supported limit */
+   best = 0;
+   for (i = 0; i < ARRAY_SIZE(wm831x_usb_limits); i++) {
+   if (limit >= wm831x_usb_limits[i] &&
+   wm831x_usb_limits[best] < wm831x_usb_limits[i])
+   best = i;
+   }
+
+   dev_dbg(wm831x_power->wm831x->dev,
+   "Limiting USB current to %umA", wm831x_usb_limits[best]);
+
+   wm831x_set_bits(wm831x_power->wm831x, WM831X_POWER_STATE,
+   WM831X_USB_ILIM_MASK, best);
+
+   return 0;
+}
+
 /*
  * Battery properties
  */
@@ -607,8 +647,31 @@ static int wm831x_power_probe(struct platform_device *pdev)
}
}
 
+   if (wm831x_pdata && wm831x_pdata->usb_gadget) {
+   power->usb_charger =
+   usb_charger_find_by_name(wm831x_pdata->usb_gadget);
+   if (IS_ERR(power->usb_charger)) {
+   ret = PTR_ERR(power->usb_charger);
+   dev_err(>dev,
+   "Failed to find USB gadget: %d\n", ret);
+   goto err_bat_irq;
+   }
+
+   power->usb_notify.notifier_call = wm831x_usb_limit_change;
+
+   ret = usb_charger_register_notify(power->usb_charger,
+ >usb_notify);
+   if (ret != 0) {
+   dev_err(>dev,
+   "Failed to register notifier: %d\n", ret);
+   goto err_usb_charger;
+   }
+   }
+
return ret;
 
+err_usb_charger:
+   /* put_device on charger */
 err_bat_irq:
--i;
for (; i >= 0; i--) {
@@ -637,6 +700,12 @@ static int wm831x_power_remove(struct platform_device 
*pdev)
struct wm831x *wm831x = wm831x_power->wm831x;
int irq, i;
 
+   if (wm831x_power->usb_charger) {
+   usb_charger_unregister_notify(wm831x_power->usb_charger,
+ _power->usb_notify);
+   /* Free charger */
+   }
+
for (i = 0; i < ARRAY_SIZE(wm831x_bat_irqs); i++) {
irq = wm831x_irq(wm831x, 
 platform_get_irq_byname(pdev,
diff --git a/include/linux/mfd/wm831x/pdata.h b/include/linux/mfd/wm831x/pdata.h
index dcc9631..5af8399 100644
--- a/include/linux/mfd/wm831x/pdata.h
+++ b/include/linux/mfd/wm831x/pdata.h
@@ -126,6 +126,9 @@ struct wm831x_pdata {
/** The driver should initiate a power off sequence during shutdown */
bool soft_shutdown;
 
+   /** dev_name of USB charger gadget to integrate with */
+   const char *usb_gadget;
+
int irq_base;
int gpio_base;
int gpio_defaults[WM831X_GPIO_NUM];
-- 
1.7.9.5

--
To unsubscribe from this list: send the line "unsubscribe 

[RESEND PATCH v10 0/4] Introduce usb charger framework to deal with the usb gadget power negotation

2016-05-02 Thread Baolin Wang
Currently the Linux kernel does not provide any standard integration of this
feature that integrates the USB subsystem with the system power regulation
provided by PMICs meaning that either vendors must add this in their kernels
or USB gadget devices based on Linux (such as mobile phones) may not behave
as they should. Thus provide a standard framework for doing this in kernel.

Now introduce one user with wm831x_power to support and test the usb charger,
which is pending testing. Moreover there may be other potential users will use
it in future.

Changes since v9:
 - Remove some redundant sysfs attributes.
 - Change the SDP charger default current if gadget is SS.
 - Remove the 'get_charger_type' callback in gadget->ops.

Baolin Wang (4):
  gadget: Introduce the usb charger framework
  gadget: Support for the usb charger framework
  gadget: Integrate with the usb gadget supporting for usb charger
  power: wm831x_power: Support USB charger current limit management

 drivers/power/wm831x_power.c  |   69 
 drivers/usb/gadget/Kconfig|7 +
 drivers/usb/gadget/udc/Makefile   |1 +
 drivers/usb/gadget/udc/charger.c  |  766 +
 drivers/usb/gadget/udc/udc-core.c |   11 +
 include/linux/mfd/wm831x/pdata.h  |3 +
 include/linux/usb/charger.h   |  173 +
 include/linux/usb/gadget.h|   13 +
 include/uapi/linux/usb/charger.h  |   31 ++
 9 files changed, 1074 insertions(+)
 create mode 100644 drivers/usb/gadget/udc/charger.c
 create mode 100644 include/linux/usb/charger.h
 create mode 100644 include/uapi/linux/usb/charger.h

-- 
1.7.9.5

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


[RESEND PATCH v10 2/4] gadget: Support for the usb charger framework

2016-05-02 Thread Baolin Wang
For supporting the usb charger, it adds the usb_charger_init() and
usb_charger_exit() functions for usb charger initialization and exit.

It will report to the usb charger when the gadget state is changed,
then the usb charger can do the power things.

Signed-off-by: Baolin Wang 
---
 drivers/usb/gadget/udc/udc-core.c |   11 +++
 include/linux/usb/gadget.h|   13 +
 2 files changed, 24 insertions(+)

diff --git a/drivers/usb/gadget/udc/udc-core.c 
b/drivers/usb/gadget/udc/udc-core.c
index 4151597..3a37980 100644
--- a/drivers/usb/gadget/udc/udc-core.c
+++ b/drivers/usb/gadget/udc/udc-core.c
@@ -28,6 +28,7 @@
 #include 
 #include 
 #include 
+#include 
 
 /**
  * struct usb_udc - describes one usb device controller
@@ -230,6 +231,9 @@ static void usb_gadget_state_work(struct work_struct *work)
struct usb_gadget *gadget = work_to_gadget(work);
struct usb_udc *udc = gadget->udc;
 
+   /* when the gadget state is changed, then report to USB charger */
+   usb_charger_plug_by_gadget(gadget, gadget->state);
+
if (udc)
sysfs_notify(>dev.kobj, NULL, "state");
 }
@@ -423,8 +427,14 @@ int usb_add_gadget_udc_release(struct device *parent, 
struct usb_gadget *gadget,
 
mutex_unlock(_lock);
 
+   ret = usb_charger_init(gadget);
+   if (ret)
+   goto err5;
+
return 0;
 
+err5:
+   device_del(>dev);
 err4:
list_del(>list);
mutex_unlock(_lock);
@@ -533,6 +543,7 @@ void usb_del_gadget_udc(struct usb_gadget *gadget)
kobject_uevent(>dev.kobj, KOBJ_REMOVE);
flush_work(>work);
device_unregister(>dev);
+   usb_charger_exit(gadget);
device_unregister(>dev);
 }
 EXPORT_SYMBOL_GPL(usb_del_gadget_udc);
diff --git a/include/linux/usb/gadget.h b/include/linux/usb/gadget.h
index 5d4e151..f82ed6b 100644
--- a/include/linux/usb/gadget.h
+++ b/include/linux/usb/gadget.h
@@ -24,6 +24,7 @@
 #include 
 #include 
 #include 
+#include 
 
 struct usb_ep;
 
@@ -639,6 +640,8 @@ struct usb_gadget {
unsignedout_epnum;
unsignedin_epnum;
struct usb_otg_caps *otg_caps;
+   /* negotiate the power with the usb charger */
+   struct usb_charger  *charger;
 
unsignedsg_supported:1;
unsignedis_otg:1;
@@ -855,10 +858,20 @@ static inline int usb_gadget_vbus_connect(struct 
usb_gadget *gadget)
  * reporting how much power the device may consume.  For example, this
  * could affect how quickly batteries are recharged.
  *
+ * It will also notify the USB charger how much power the device may
+ * consume if there is a USB charger linking with the gadget.
+ *
  * Returns zero on success, else negative errno.
  */
 static inline int usb_gadget_vbus_draw(struct usb_gadget *gadget, unsigned mA)
 {
+   enum usb_charger_type type;
+
+   if (gadget->charger) {
+   type = usb_charger_get_type(gadget->charger);
+   usb_charger_set_cur_limit_by_type(gadget->charger, type, mA);
+   }
+
if (!gadget->ops->vbus_draw)
return -EOPNOTSUPP;
return gadget->ops->vbus_draw(gadget, mA);
-- 
1.7.9.5

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


[PATCH 2/2] Documentation: gadget_configfs: update UDC binding

2016-05-02 Thread changbin . du
From: "Du, Changbin" 

Add the usage of new binding mode 'any'.
$ echo any > UDC

Signed-off-by: Du, Changbin 
Signed-off-by: Du, Changbin 
---
 Documentation/usb/gadget_configfs.txt | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/Documentation/usb/gadget_configfs.txt 
b/Documentation/usb/gadget_configfs.txt
index 635e574..1edeb4f 100644
--- a/Documentation/usb/gadget_configfs.txt
+++ b/Documentation/usb/gadget_configfs.txt
@@ -205,11 +205,13 @@ In order to enable the gadget it must be bound to a UDC 
(USB Device Controller).
 
 $ echo  > UDC
 
-where  is one of those found in /sys/class/udc/*
+where  is one of those found in /sys/class/udc/* or "any" if you
+doesn't care about which controller to bind.
 e.g.:
 
 $ echo s3c-hsotg > UDC
-
+or
+$ echo any > UDC
 
 6. Disabling the gadget
 ---
-- 
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 1/2] usb: configfs: allow UDC binding rule configured as binding to *any* UDC

2016-05-02 Thread changbin . du
From: "Du, Changbin" 

On most platforms, there is only one device controller available.
In this case, we desn't care the UDC's name. So let's ignore the
name by setting 'UDC' to 'any'. And also we can change UDC name
at any time if it is not binded (no need set to "" first).

Signed-off-by: Du, Changbin 
Signed-off-by: Du, Changbin 
---
 drivers/usb/gadget/configfs.c | 22 ++
 1 file changed, 14 insertions(+), 8 deletions(-)

diff --git a/drivers/usb/gadget/configfs.c b/drivers/usb/gadget/configfs.c
index b6f60ca..5da2991 100644
--- a/drivers/usb/gadget/configfs.c
+++ b/drivers/usb/gadget/configfs.c
@@ -230,16 +230,18 @@ static ssize_t gadget_dev_desc_bcdUSB_store(struct 
config_item *item,
 
 static ssize_t gadget_dev_desc_UDC_show(struct config_item *item, char *page)
 {
-   char *udc_name = to_gadget_info(item)->composite.gadget_driver.udc_name;
+   struct gadget_info *gi = to_gadget_info(item);
+   char *udc_name = gi->composite.gadget_driver.udc_name;
 
-   return sprintf(page, "%s\n", udc_name ?: "");
+   return sprintf(page, "%s\n", udc_name ?:
+   (gi->cdev.gadget ? "any" : ""));
 }
 
 static int unregister_gadget(struct gadget_info *gi)
 {
int ret;
 
-   if (!gi->composite.gadget_driver.udc_name)
+   if (!gi->cdev.gadget)
return -ENODEV;
 
ret = usb_gadget_unregister_driver(>composite.gadget_driver);
@@ -270,10 +272,14 @@ static ssize_t gadget_dev_desc_UDC_store(struct 
config_item *item,
if (ret)
goto err;
} else {
-   if (gi->composite.gadget_driver.udc_name) {
+   if (gi->cdev.gadget) {
ret = -EBUSY;
goto err;
}
+   if (!strcmp(name, "any")) {
+   kfree(name);
+   name = NULL;
+   }
gi->composite.gadget_driver.udc_name = name;
ret = usb_gadget_probe_driver(>composite.gadget_driver);
if (ret) {
@@ -428,9 +434,9 @@ static int config_usb_cfg_unlink(
 * remove the function.
 */
mutex_lock(>lock);
-   if (gi->composite.gadget_driver.udc_name)
+   if (gi->cdev.gadget)
unregister_gadget(gi);
-   WARN_ON(gi->composite.gadget_driver.udc_name);
+   WARN_ON(gi->cdev.gadget);
 
list_for_each_entry(f, >func_list, list) {
if (f->fi == fi) {
@@ -873,10 +879,10 @@ static int os_desc_unlink(struct config_item *os_desc_ci,
struct usb_composite_dev *cdev = >cdev;
 
mutex_lock(>lock);
-   if (gi->composite.gadget_driver.udc_name)
+   if (gi->cdev.gadget)
unregister_gadget(gi);
cdev->os_desc_config = NULL;
-   WARN_ON(gi->composite.gadget_driver.udc_name);
+   WARN_ON(gi->cdev.gadget);
mutex_unlock(>lock);
return 0;
 }
-- 
2.7.4

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


[PATCH 0/2] Add binding rule *any* support for USB Gadget Configfs

2016-05-02 Thread changbin . du
From: "Du, Changbin" 

When I am configuring Gadget Configfs, I need found a exactly UDC name before
I can start my gadget. But, really I doesn't care about which UDC name is used,
because I have only controller. "any" is a good option.

Du, Changbin (2):
  usb: configfs: allow UDC binding rule configured as binding to *any*
UDC
  Documentation: gadget_configfs: update UDC binding

 Documentation/usb/gadget_configfs.txt |  6 --
 drivers/usb/gadget/configfs.c | 22 ++
 2 files changed, 18 insertions(+), 10 deletions(-)

-- 
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: How to read & back up data of SIM Card using its Reader?

2016-05-02 Thread Susmita/Rajib Bandopadhyay
On 02/05/2016, Greg KH  wrote:
...
[snipped]

Before plugging in:
knoppix@Microknoppix:~$ sudo dmesg -c
[1.370778] ehci-pci :00:02.1: EHCI Host Controller
[1.370828] ehci-pci :00:02.1: new USB bus registered, assigned
bus number 1
[1.370895] ehci-pci :00:02.1: debug port 1
[1.370963] ehci-pci :00:02.1: cache line size of 64 is not supported
[1.370990] ehci-pci :00:02.1: irq 22, io mem 0xfb004000
[1.380034] ehci-pci :00:02.1: USB 2.0 started, EHCI 1.00
[1.380122] usb usb1: New USB device found, idVendor=1d6b, idProduct=0002
[1.380169] usb usb1: New USB device strings: Mfr=3, Product=2,
SerialNumber=1
[1.380227] usb usb1: Product: EHCI Host Controller
[1.380270] usb usb1: Manufacturer: Linux 3.9.6 ehci_hcd
[1.380314] usb usb1: SerialNumber: :00:02.1
[1.380503] hub 1-0:1.0: USB hub found
[1.380549] hub 1-0:1.0: 10 ports detected
[1.380786] ehci-platform: EHCI generic platform driver
[1.380868] ohci_hcd: USB 1.1 'Open' Host Controller (OHCI) Driver
[1.381055] ohci_hcd :00:02.0: setting latency timer to 64
[1.381059] ohci_hcd :00:02.0: OHCI Host Controller
[1.381107] ohci_hcd :00:02.0: new USB bus registered, assigned
bus number 2
[1.381196] ohci_hcd :00:02.0: irq 23, io mem 0xfb005000
[1.435366] usb usb2: New USB device found, idVendor=1d6b, idProduct=0001
[1.435413] usb usb2: New USB device strings: Mfr=3, Product=2,
SerialNumber=1
[1.435471] usb usb2: Product: OHCI Host Controller
[1.435514] usb usb2: Manufacturer: Linux 3.9.6 ohci_hcd
[1.435558] usb usb2: SerialNumber: :00:02.0
[1.435724] hub 2-0:1.0: USB hub found
[1.435770] hub 2-0:1.0: 10 ports detected
[1.435990] uhci_hcd: USB Universal Host Controller Interface driver
[1.436163] Initializing USB Mass Storage driver...
[1.436257] usbcore: registered new interface driver usb-storage
[1.436301] USB Mass Storage support registered.
[1.436380] usbcore: registered new interface driver ums-alauda
[1.436461] usbcore: registered new interface driver ums-cypress
[1.436542] usbcore: registered new interface driver ums-datafab
[1.436628] usbcore: registered new interface driver ums_eneub6250
[1.436727] usbcore: registered new interface driver ums-freecom
[1.436810] usbcore: registered new interface driver ums-isd200
[1.436891] usbcore: registered new interface driver ums-jumpshot
[1.436972] usbcore: registered new interface driver ums-karma
[1.437053] usbcore: registered new interface driver ums-onetouch
[1.437139] usbcore: registered new interface driver ums-realtek
[1.437220] usbcore: registered new interface driver ums-sddr09
[1.437303] usbcore: registered new interface driver ums-sddr55
[1.437384] usbcore: registered new interface driver ums-usbat
[1.437524] i8042: PNP: PS/2 Controller [PNP0303:PS2K] at 0x60,0x64 irq 1
[1.437570] i8042: PNP: PS/2 appears to have AUX port disabled, if
this is incorrect please boot with i8042.nopnp
[1.437848] serio: i8042 KBD port at 0x60,0x64 irq 1
[1.438078] mousedev: PS/2 mouse device common for all mice
[1.438376] rtc_cmos 00:04: RTC can wake from S4
[1.438630] rtc_cmos 00:04: rtc core: registered rtc_cmos as rtc0
[1.438710] rtc_cmos 00:04: alarms up to one year, y3k, 242 bytes
nvram, hpet irqs
[1.438900] device-mapper: uevent: version 1.0.3
[1.439000] device-mapper: ioctl: 4.24.0-ioctl (2013-01-15)
initialised: dm-de...@redhat.com
[1.439106] EISA: Probing bus 0 at eisa.0
[1.439149] EISA: Cannot allocate resource for mainboard
[1.439244] cpuidle: using governor ladder
[1.439285] cpuidle: using governor menu
[1.439361] sdhci: Secure Digital Host Controller Interface driver
[1.439406] sdhci: Copyright(c) Pierre Ossman
[1.439597] wbsd: Winbond W83L51xD SD/MMC card interface driver
[1.439641] wbsd: Copyright(c) Pierre Ossman
[1.439834] VUB300 Driver rom wait states = 1C irqpoll timeout = 0400
[1.439961] usbcore: registered new interface driver vub300
[1.440105] usbcore: registered new interface driver ushc
[1.440185] sdhci-pltfm: SDHCI platform and OF driver helper
[1.440353] hidraw: raw HID events driver (C) Jiri Kosina
[1.441376] usbcore: registered new interface driver usbhid
[1.441421] usbhid: USB HID core driver
[1.441504] usbcore: registered new interface driver rts5139
[1.441729] zram: Created 1 device(s) ...
[1.441897] ashmem: initialized
[1.442077] goldfish_pdev_bus goldfish_pdev_bus: unable to reserve
Goldfish MMIO.
[1.442138] goldfish_pdev_bus: probe of goldfish_pdev_bus failed
with error -16
[1.442672] Initializing XFRM netlink socket
[1.442719] NET: Registered protocol family 17
[1.442773] NET: Registered protocol family 15
[1.442952] Key type dns_resolver registered
[1.443172] Using IPI No-Shortcut mode
[1.443418] registered taskstats version 1

Re: [PATCH v7 1/7] regulator: fixed: add support for ACPI interface

2016-05-02 Thread Lu Baolu
Hi,

On 05/02/2016 07:00 PM, Mark Brown wrote:
> On Fri, Apr 29, 2016 at 02:26:32PM +0800, Lu Baolu wrote:
>
>> +gpiod = gpiod_get(dev, "vbus_en", GPIOD_ASIS);
>> +if (IS_ERR(gpiod))
>> +return PTR_ERR(gpiod);
> This is clearly an inappropriate name for the signal in generic code,
> it's specific to your use case.

I will change the gpio name to "gpio". Is that okay?

Best regards,
Lu Baolu
--
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: add device id to linux kernel

2016-05-02 Thread Lars Melin

On 2016-05-02 20:43, gre...@linuxfoundation.org wrote:

On Mon, May 02, 2016 at 09:22:57AM +0300, Felipe Balbi wrote:


Hi,

刘磊  writes:

dear linuxfoundation:
 I am liulei come from ZTEMT.  We need add some device ID to linux kernel, 
We need some help from yours.
Looking forward to you reply, thanks!


Signed-off-by:lei liu





Do all these devices really exist ? If they do, then please just send
this as a proper patch and it should be simple to get it merged. See
Documentation/SubmittingPatches for some hints as to how to write proper
patches, but basically, your patch needs a commit log with a
Signed-off-by line.


There is a signed-off-by line :)

--
The patch is anyway wrong since it is inserted in the wrong place and 
the id's are reverse sorted.


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


[PATCH 2/2] usb: musb: host: don't start next rx urb if current one failed

2016-05-02 Thread Bin Liu
urb->status is set when endpoint csr RXSTALL, H_ERROR, DATAERROR or
INCOMPRX bit is set. Those bits mean a broken pipe, so don't start next
urb when any of these bits is set by checking urb->status.

To minimize the risk of regression, only do so for RX, until we have a
test case to understand the behavior of TX.

The patch fixes system freeze issue caused by repeatedly invoking RX ISR
while removing a usb uart device connected to a hub, in which case the
hub has no chance to report the disconnect event due to the kernel is
busy in processing the RX interrupt flooding.

Reported-by: Max Uvarov 
Signed-off-by: Bin Liu 
---
 drivers/usb/musb/musb_host.c | 8 +++-
 1 file changed, 7 insertions(+), 1 deletion(-)

diff --git a/drivers/usb/musb/musb_host.c b/drivers/usb/musb/musb_host.c
index 931381c..a8b62d8 100644
--- a/drivers/usb/musb/musb_host.c
+++ b/drivers/usb/musb/musb_host.c
@@ -434,7 +434,13 @@ static void musb_advance_schedule(struct musb *musb, 
struct urb *urb,
}
}
 
-   if (qh != NULL && qh->is_ready) {
+   /*
+* The pipe must be broken if current urb->status is set, so don't
+* start next urb.
+* TODO: to minimize the risk of regression, only check urb->status
+* for RX, until we have a test case to understand the behavior of TX.
+*/
+   if ((!status || !is_in) && qh != NULL && qh->is_ready) {
dev_dbg(musb->controller, "... next ep%d %cX urb %p\n",
hw_ep->epnum, is_in ? 'R' : 'T', next_urb(qh));
musb_start_urb(musb, is_in, qh);
-- 
1.9.1

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


[PATCH 1/2] usb: musb: host: clear rxcsr error bit if set

2016-05-02 Thread Bin Liu
The MUSB Programming Guide states that the driver should clear RXCSR
bit2 when the controller sets the bit.

Signed-off-by: Bin Liu 
---
 drivers/usb/musb/musb_host.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/usb/musb/musb_host.c b/drivers/usb/musb/musb_host.c
index 2f8ad7f..931381c 100644
--- a/drivers/usb/musb/musb_host.c
+++ b/drivers/usb/musb/musb_host.c
@@ -1870,6 +1870,9 @@ void musb_host_rx(struct musb *musb, u8 epnum)
status = -EPROTO;
musb_writeb(epio, MUSB_RXINTERVAL, 0);
 
+   rx_csr &= ~MUSB_RXCSR_H_ERROR;
+   musb_writew(epio, MUSB_RXCSR, rx_csr);
+
} else if (rx_csr & MUSB_RXCSR_DATAERROR) {
 
if (USB_ENDPOINT_XFER_ISOC != qh->type) {
-- 
1.9.1

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


[PATCH] usb: serial: ti_usb_3410_5052: add MOXA UPORT 11x0 support

2016-05-02 Thread Mathieu OTHACEHE
Hi Johan,

Thanks for your review.

> Looks like this code could use a few vid/pid temporaries.

> I'm not sure it makes sense to try to load a "ti_usb-v110a-p1150.fw"
> firmware before requesting the moxa firmware. Avoids a confusing:

> usb 1-2.2: Direct firmware load for ti_usb-v110a-p1150.fw failed with error -2

> message too.

I'm not sure to get your point here, shall I rename moxa firmwares in 
linux-firmware repo
to be compliant with ti_usb-v%04x-p%04x.fw format ?

> I did a quick test of the patch using a Moxa 1150-device. Works at
> 115200, but communication appeared broken at 9600. Looks like the baud
> rate calculations are similar but not identical to what the Moxa driver
> does. Is this something you have looked into?

Well, on my moxa 1110 communication is working at 9600, 115200 and other baud 
rates.
However, I think baud rate calculation may be wrong for TI3410 chips.

According to table 5-13 in datasheet 
http://www.ti.com/lit/ds/symlink/tusb3410.pdf
the baud rate calculation formula, is :

baud_rate = 923077 / (desired_baud_rate)

So, we get :

desired_baud = 9600   -> baud_rate = 923077 / 9600 = 96
desired_baud = 115200 -> baud_rate = 923077 / 115200 = 8
...

In ti_usb_3410_5052 driver, the formula used for 3410 is :

baud_rate = (923077 + desired_baud_rate/2) / desired_baud_rate

so,

desired_baud = 9600   -> baud_rate = (923077 + 9600/2) / 9600 = 97 (!= 96)
desired_baud = 115200 -> baud_rate = (923077 + 115200/2) / 115200 = 9 (!= 8)

It seems the formula is wrong but some firmware deal with it anyway.
Should I correct the formula or use a quirk for moxa devices ?

Thank you,

Mathieu
--
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: How to read & back up data of SIM Card using its Reader?

2016-05-02 Thread Greg KH
On Mon, May 02, 2016 at 10:41:24PM +0530, Susmita/Rajib Bandopadhyay wrote:
> Dear Sirs,
> I am a FOSS enthusiast.
> Recently, I have run into a problem.  Although it is a long-standing
> problem, this is a special case of the issue.
> I placed the queries on Debian and Knoppix forums with sufficient information.
> The issue is this:
> 
> How to back up data of SIM Card with its Reader?
> Links:
> (1) http://forums.debian.net/viewtopic.php?f=7=128156
> (2) 
> http://knoppix.net/forum/threads/31824-How-to-back-up-SIM-Card-data-with-its-Reader?p=133623#post133623
> Postby bkpsusmitaa » 2016-04-29 09:13
> 
> I recently bought a Master Gold USB 2.0 SIM Card Reader [model
> MG-008], having compatibility with Doze XP, 2000, Me, Vista and OSX
> 10.2+.
> I also have the mini-CD which has the software that allows Doze users
> to access the SIM card.
> I lament because with a dozing system like Doze people can access
> everything via applications, while Linux, with so much power, can't.
> I want to back up my SIM card data.
> Are you aware of a package that can help me do this and more?
> Symbian and Android can do it, so therefore can Linux.
> I am sure my more able compatriots would be able to do it.
> Eager to hear from you, leaders!
> 
> Regarding the codes:
> [code]lsusb -v[/code]
> [quote]
> Bus 001 Device 003: ID 14cd:6700 Super Top Card Reader
> Couldn't open device, some information will be missing
> Device Descriptor:
>   bLength18
>   bDescriptorType 1
>   bcdUSB   2.00
>   bDeviceClass0 (Defined at Interface level)
>   bDeviceSubClass 0
>   bDeviceProtocol 0
>   bMaxPacketSize064
>   idVendor   0x14cd Super Top
>   idProduct  0x6700 Card Reader
>   bcdDevice2.01
>   iManufacturer   1
>   iProduct3
>   iSerial 2
>   bNumConfigurations  1
>   Configuration Descriptor:
> bLength 9
> bDescriptorType 2
> wTotalLength   32
> bNumInterfaces  1
> bConfigurationValue 1
> iConfiguration  0
> bmAttributes 0x80
>   (Bus Powered)
> MaxPower  100mA
> Interface Descriptor:
>   bLength 9
>   bDescriptorType 4
>   bInterfaceNumber0
>   bAlternateSetting   0
>   bNumEndpoints   2
>   bInterfaceClass 8 Mass Storage
>   bInterfaceSubClass  6 SCSI
>   bInterfaceProtocol 80 Bulk-Only
>   iInterface  0
>   Endpoint Descriptor:
> bLength 7
> bDescriptorType 5
> bEndpointAddress 0x81  EP 1 IN
> bmAttributes2
>   Transfer TypeBulk
>   Synch Type   None
>   Usage Type   Data
> wMaxPacketSize 0x0200  1x 512 bytes
> bInterval   0
>   Endpoint Descriptor:
> bLength 7
> bDescriptorType 5
> bEndpointAddress 0x02  EP 2 OUT
> bmAttributes2
>   Transfer TypeBulk
>   Synch Type   None
>   Usage Type   Data
> wMaxPacketSize 0x0200  1x 512 bytes
> bInterval   0
> [/quote]
> 
> I tried to mount only one USB device loaded, but the response is as follows:
> [code]mount /dev/usb/hiddev0 /media/sdc[/code]
> [quote]
> mount: /dev/usb/hiddev0 is not a block device
> [/quote]

Why would you mount a hid device?  This is a mass storage device, it
should be mounted automatically by your system when you plug it in, or
you can run:
mount /dev/sdc /tmp/x

if you have a /tmp/x directory and /dev/sdc is the block device.

What is the kernel log messages when you plug the device in?  You can
get that by doing:

Before plugging in:
sudo dmesg -c

Plug the device in.

Provide the output of:
dmesg

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: [EXT] Re: [PATCH] Add DCD line support to CP210x driver

2016-05-02 Thread Konstantin Shkolnyy
> -Original Message-
> From: Johan Hovold [mailto:jhov...@gmail.com] On Behalf Of Johan Hovold
> Sent: Sunday, May 01, 2016 10:20
> To: Konstantin Shkolnyy
> Cc: Johan Hovold; Valentin Yakovenkov; linux-usb@vger.kernel.org
> Subject: Re: [EXT] Re: [PATCH] Add DCD line support to CP210x driver
[...]

> > > > +   wake_up_interruptible(
> > > >port.delta_msr_wait);
> > > > +   spriv->rx_state = CP210X_STATE_IDLE;
> > > > +   break;
> > > > +   }
> > > > +   }
> > >
> > > Instead of maintaining this state machine (which should not need to be
> > > global, or can the events really be split over multiple bulk
> > > transfers?), just scan the buffer for the escape character and if found,
> >
> > Do you know for sure that they can't be split over multiple transfers,
> > in today's and future chips?
> 
> We don't need to care about future chips just yet, but you should know
> how the current firmware has been implemented, right? Does it really
> split escape chars over multiple transfers?

I think if the official spec doesn't spell out this behavior, it effectively 
means s/w can't assume anything.
What problem do you see in persisting this state between callbacks, as this 
code does?
--
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


How to read & back up data of SIM Card using its Reader?

2016-05-02 Thread Susmita/Rajib Bandopadhyay
Dear Sirs,
I am a FOSS enthusiast.
Recently, I have run into a problem.  Although it is a long-standing
problem, this is a special case of the issue.
I placed the queries on Debian and Knoppix forums with sufficient information.
The issue is this:

How to back up data of SIM Card with its Reader?
Links:
(1) http://forums.debian.net/viewtopic.php?f=7=128156
(2) 
http://knoppix.net/forum/threads/31824-How-to-back-up-SIM-Card-data-with-its-Reader?p=133623#post133623
Postby bkpsusmitaa » 2016-04-29 09:13

I recently bought a Master Gold USB 2.0 SIM Card Reader [model
MG-008], having compatibility with Doze XP, 2000, Me, Vista and OSX
10.2+.
I also have the mini-CD which has the software that allows Doze users
to access the SIM card.
I lament because with a dozing system like Doze people can access
everything via applications, while Linux, with so much power, can't.
I want to back up my SIM card data.
Are you aware of a package that can help me do this and more?
Symbian and Android can do it, so therefore can Linux.
I am sure my more able compatriots would be able to do it.
Eager to hear from you, leaders!

Regarding the codes:
[code]lsusb -v[/code]
[quote]
Bus 001 Device 003: ID 14cd:6700 Super Top Card Reader
Couldn't open device, some information will be missing
Device Descriptor:
  bLength18
  bDescriptorType 1
  bcdUSB   2.00
  bDeviceClass0 (Defined at Interface level)
  bDeviceSubClass 0
  bDeviceProtocol 0
  bMaxPacketSize064
  idVendor   0x14cd Super Top
  idProduct  0x6700 Card Reader
  bcdDevice2.01
  iManufacturer   1
  iProduct3
  iSerial 2
  bNumConfigurations  1
  Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength   32
bNumInterfaces  1
bConfigurationValue 1
iConfiguration  0
bmAttributes 0x80
  (Bus Powered)
MaxPower  100mA
Interface Descriptor:
  bLength 9
  bDescriptorType 4
  bInterfaceNumber0
  bAlternateSetting   0
  bNumEndpoints   2
  bInterfaceClass 8 Mass Storage
  bInterfaceSubClass  6 SCSI
  bInterfaceProtocol 80 Bulk-Only
  iInterface  0
  Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x81  EP 1 IN
bmAttributes2
  Transfer TypeBulk
  Synch Type   None
  Usage Type   Data
wMaxPacketSize 0x0200  1x 512 bytes
bInterval   0
  Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x02  EP 2 OUT
bmAttributes2
  Transfer TypeBulk
  Synch Type   None
  Usage Type   Data
wMaxPacketSize 0x0200  1x 512 bytes
bInterval   0
[/quote]

I tried to mount only one USB device loaded, but the response is as follows:
[code]mount /dev/usb/hiddev0 /media/sdc[/code]
[quote]
mount: /dev/usb/hiddev0 is not a block device
[/quote]

Regards,
Rajib Bandopadhyay
Mysore
--
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] Revert "USB / PM: Allow USB devices to remain runtime-suspended when sleeping"

2016-05-02 Thread Greg Kroah-Hartman
On Mon, May 02, 2016 at 11:26:01AM -0400, Alan Stern wrote:
> On Mon, 2 May 2016, Greg Kroah-Hartman wrote:
> 
> > On Mon, May 02, 2016 at 11:13:10AM -0400, Alan Stern wrote:
> > > On Mon, 2 May 2016, Johan Hovold wrote:
> > > 
> > > > This reverts commit e3345db85068ddb937fc0ba40dfc39c293dad977, which
> > > > broke system resume for a large class of devices.
> > > > 
> > > > Devices that after having been reset during resume need to be rebound
> > > > due to a missing reset_resume callback, are now left in a suspended
> > > > state. This specifically broke resume of common USB-serial devices,
> > > > which are now unusable after system suspend (until disconnected and
> > > > reconnected) when USB persist is enabled.
> > > > 
> > > > During resume, usb_resume_interface will set the needs_binding flag for
> > > > such interfaces, but unlike system resume, run-time resume does not
> > > > honour it.
> > > > 
> > > > Cc: stable  # 4.5
> > > > Signed-off-by: Johan Hovold 
> > > > ---
> > > > 
> > > > Greg, Alan,
> > > > 
> > > > This patch for v4.6-rc7 fixes a 4.5-regression that broke system suspend
> > > > for a large class of devices, including USB-serial devices, for example
> > > > when USB persist is enabled.
> > > > 
> > > > We may be able to find a way around this, but since it's a user-visible
> > > > regression and late in the rc-cycle, I believe reverting the offending
> > > > commit is the right thing to do.
> > > 
> > > The description of the problem doesn't sound right to me.  For 
> > > instance, would it help if usb_runtime_resume() did honor the 
> > > needs_binding flag?  I doubt it.  Things like the wakeup setting would 
> > > still be lost before the runtime resume occurred.
> > > 
> > > I suspect the right answer is always to resume a USB device if it needs 
> > > a reset-resume, but otherwise allow it to remain in runtime suspend.
> > > 
> > > Reverting the patch for now is okay with me.  Tomeu may want to work on
> > > a better solution.  Part of the difficulty is that the PM core wants to
> > > know before suspending whether skipping resume will be okay, but the
> > > USB stack doesn't know until after the host controller has been 
> > > resumed.
> > > 
> > > In the end, we'll probably have the PM core call usb_resume all the 
> > > time, but usb_resume will leave the device in runtime suspend if it 
> > > can.  This isn't ideal but it may be the best we can do.
> > 
> > So is that an "acked-by" for this revert?
> 
> Yes.

Great, now applied, 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] Revert "USB / PM: Allow USB devices to remain runtime-suspended when sleeping"

2016-05-02 Thread Alan Stern
On Mon, 2 May 2016, Greg Kroah-Hartman wrote:

> On Mon, May 02, 2016 at 11:13:10AM -0400, Alan Stern wrote:
> > On Mon, 2 May 2016, Johan Hovold wrote:
> > 
> > > This reverts commit e3345db85068ddb937fc0ba40dfc39c293dad977, which
> > > broke system resume for a large class of devices.
> > > 
> > > Devices that after having been reset during resume need to be rebound
> > > due to a missing reset_resume callback, are now left in a suspended
> > > state. This specifically broke resume of common USB-serial devices,
> > > which are now unusable after system suspend (until disconnected and
> > > reconnected) when USB persist is enabled.
> > > 
> > > During resume, usb_resume_interface will set the needs_binding flag for
> > > such interfaces, but unlike system resume, run-time resume does not
> > > honour it.
> > > 
> > > Cc: stable    # 4.5
> > > Signed-off-by: Johan Hovold 
> > > ---
> > > 
> > > Greg, Alan,
> > > 
> > > This patch for v4.6-rc7 fixes a 4.5-regression that broke system suspend
> > > for a large class of devices, including USB-serial devices, for example
> > > when USB persist is enabled.
> > > 
> > > We may be able to find a way around this, but since it's a user-visible
> > > regression and late in the rc-cycle, I believe reverting the offending
> > > commit is the right thing to do.
> > 
> > The description of the problem doesn't sound right to me.  For 
> > instance, would it help if usb_runtime_resume() did honor the 
> > needs_binding flag?  I doubt it.  Things like the wakeup setting would 
> > still be lost before the runtime resume occurred.
> > 
> > I suspect the right answer is always to resume a USB device if it needs 
> > a reset-resume, but otherwise allow it to remain in runtime suspend.
> > 
> > Reverting the patch for now is okay with me.  Tomeu may want to work on
> > a better solution.  Part of the difficulty is that the PM core wants to
> > know before suspending whether skipping resume will be okay, but the
> > USB stack doesn't know until after the host controller has been 
> > resumed.
> > 
> > In the end, we'll probably have the PM core call usb_resume all the 
> > time, but usb_resume will leave the device in runtime suspend if it 
> > can.  This isn't ideal but it may be the best we can do.
> 
> So is that an "acked-by" for this revert?

Yes.

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] Revert "USB / PM: Allow USB devices to remain runtime-suspended when sleeping"

2016-05-02 Thread Greg Kroah-Hartman
On Mon, May 02, 2016 at 11:13:10AM -0400, Alan Stern wrote:
> On Mon, 2 May 2016, Johan Hovold wrote:
> 
> > This reverts commit e3345db85068ddb937fc0ba40dfc39c293dad977, which
> > broke system resume for a large class of devices.
> > 
> > Devices that after having been reset during resume need to be rebound
> > due to a missing reset_resume callback, are now left in a suspended
> > state. This specifically broke resume of common USB-serial devices,
> > which are now unusable after system suspend (until disconnected and
> > reconnected) when USB persist is enabled.
> > 
> > During resume, usb_resume_interface will set the needs_binding flag for
> > such interfaces, but unlike system resume, run-time resume does not
> > honour it.
> > 
> > Cc: stable  # 4.5
> > Signed-off-by: Johan Hovold 
> > ---
> > 
> > Greg, Alan,
> > 
> > This patch for v4.6-rc7 fixes a 4.5-regression that broke system suspend
> > for a large class of devices, including USB-serial devices, for example
> > when USB persist is enabled.
> > 
> > We may be able to find a way around this, but since it's a user-visible
> > regression and late in the rc-cycle, I believe reverting the offending
> > commit is the right thing to do.
> 
> The description of the problem doesn't sound right to me.  For 
> instance, would it help if usb_runtime_resume() did honor the 
> needs_binding flag?  I doubt it.  Things like the wakeup setting would 
> still be lost before the runtime resume occurred.
> 
> I suspect the right answer is always to resume a USB device if it needs 
> a reset-resume, but otherwise allow it to remain in runtime suspend.
> 
> Reverting the patch for now is okay with me.  Tomeu may want to work on
> a better solution.  Part of the difficulty is that the PM core wants to
> know before suspending whether skipping resume will be okay, but the
> USB stack doesn't know until after the host controller has been 
> resumed.
> 
> In the end, we'll probably have the PM core call usb_resume all the 
> time, but usb_resume will leave the device in runtime suspend if it 
> can.  This isn't ideal but it may be the best we can do.

So is that an "acked-by" for this revert?

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] USB: leave LPM alone if possible when binding/unbinding interface drivers

2016-05-02 Thread Alan Stern
On Mon, 2 May 2016, Mathias Nyman wrote:

> On 29.04.2016 22:25, Alan Stern wrote:
> > When a USB driver is bound to an interface (either through probing or
> > by claiming it) or is unbound from an interface, the USB core always
> > disables Link Power Management during the transition and then
> > re-enables it afterward.  The reason is because the driver might want
> > to prevent hub-initiated link power transitions, in which case the HCD
> > would have to recalculate the various LPM parameters.  This
> > recalculation takes place when LPM is re-enabled and the new
> > parameters are sent to the device and its parent hub.
> >
> > However, if the driver does not want to prevent hub-initiated link
> > power transitions then none of this work is necessary.  The parameters
> > don't need to be recalculated, and LPM doesn't need to be disabled and
> > re-enabled.
> >
> > It turns out that disabling and enabling LPM can be time-consuming,
> > enough so that it interferes with user programs that want to claim and
> > release interfaces rapidly via usbfs.  Since the usbfs kernel driver
> > doesn't set the disable_hub_initiated_lpm flag, we can speed things up
> > and get the user programs to work by leaving LPM alone whenever the
> > flag isn't set.
> >
> > And while we're improving the way disable_hub_initiated_lpm gets used,
> > let's also fix its kerneldoc.
> >
> > Signed-off-by: Alan Stern 
> > Tested-by: Matthew Giassa 
> > CC: Mathias Nyman 
> > CC: 
> >
> > ---
> >
> > Mathias, can you check that this is right?  If the driver's
> > disable_hub_initiated_lpm flag isn't set then binding or unbinding it
> > shouldn't require any changes to the LPM parameters.  The flag gets
> > used in only one place, in xhci_calculate_lpm_timeout(), and if it
> > isn't set then then result would be the same as if the driver weren't
> > bound.
> >
> > Thanks.
> 
> It looks like xhci driver calculates the u1 and u2 timeout values for
> ports based on udev->u1_params.sel * x (where x depends on endpoint type).
> 
> It loops through all active interfaces all endpoints, and picks the worst
> (longest) timeout as the timeout value.
> 
> In this sense if a interface drive disappears or appears it could be possible
> that the timeout values change, even if the xhci_calculate_lpm_timeout() is
> not set.

I don't understand.  The calculation below doesn't care whether the 
interface is bound to a driver, does it?  It looks at all the endpoints 
in all the current altsettings, whether they are bound or not.

Or have I misunderstood something?

Alan Stern

> usb_enable_lpm()
>usb_enable_link_state()
>  hcd->driver->enable_usb3_lpm_timeout(hcd, udev, state)
>xhci_calculate_lpm_timeout()
>  for (i = 0; i < udev->actconfig->desc.bNumInterfaces; i++)
>xhci_update_timeout_for_interface(... ))
>  for (j = 0; j < alt->desc.bNumEndpoints; j++)
>xhci_update_timeout_for_endpoint() // saves longest 
> timeout
>  xhci_call_host_update_timeout_for_endpoint()
>..xhci_calculate_intel_u1_timeout()  // skipped a few steps
>   case USB_ENDPOINT_XFER_CONTROL:
> timeout = udev->u1_params.sel * 3;
>   case USB_ENDPOINT_XFER_BULK:
> timeout = udev->u1_params.sel * 5;
>   case USB_ENDPOINT_XFER_INT:
>   timeout = ...
> 
> -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] Revert "USB / PM: Allow USB devices to remain runtime-suspended when sleeping"

2016-05-02 Thread Alan Stern
On Mon, 2 May 2016, Johan Hovold wrote:

> This reverts commit e3345db85068ddb937fc0ba40dfc39c293dad977, which
> broke system resume for a large class of devices.
> 
> Devices that after having been reset during resume need to be rebound
> due to a missing reset_resume callback, are now left in a suspended
> state. This specifically broke resume of common USB-serial devices,
> which are now unusable after system suspend (until disconnected and
> reconnected) when USB persist is enabled.
> 
> During resume, usb_resume_interface will set the needs_binding flag for
> such interfaces, but unlike system resume, run-time resume does not
> honour it.
> 
> Cc: stable    # 4.5
> Signed-off-by: Johan Hovold 
> ---
> 
> Greg, Alan,
> 
> This patch for v4.6-rc7 fixes a 4.5-regression that broke system suspend
> for a large class of devices, including USB-serial devices, for example
> when USB persist is enabled.
> 
> We may be able to find a way around this, but since it's a user-visible
> regression and late in the rc-cycle, I believe reverting the offending
> commit is the right thing to do.

The description of the problem doesn't sound right to me.  For 
instance, would it help if usb_runtime_resume() did honor the 
needs_binding flag?  I doubt it.  Things like the wakeup setting would 
still be lost before the runtime resume occurred.

I suspect the right answer is always to resume a USB device if it needs 
a reset-resume, but otherwise allow it to remain in runtime suspend.

Reverting the patch for now is okay with me.  Tomeu may want to work on
a better solution.  Part of the difficulty is that the PM core wants to
know before suspending whether skipping resume will be okay, but the
USB stack doesn't know until after the host controller has been 
resumed.

In the end, we'll probably have the PM core call usb_resume all the 
time, but usb_resume will leave the device in runtime suspend if it 
can.  This isn't ideal but it may be the best we can do.

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] usb: misc: usbtest: fix pattern tests for scatterlists.

2016-05-02 Thread Alan Stern
On Mon, 2 May 2016, Mathias Nyman wrote:

> The current implemenentation restart the sent pattern for each entry in
> the sg list. The receiving end expects a continuous pattern, and test
> will fail unless scatterilst entries happen to be aligned with the
> pattern

Ah.  We didn't spot this earlier because for non-xHCI controllers, the 
scatterlist entries _must_ be aligned with the maxpacket size and 
therefore with the pattern.

> Fix this by calculating the pattern byte based on total sent size
> instead of just the current sg entry.
> 
> Signed-off-by: Mathias Nyman 

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 v2] xhci: Cleanup only when releasing primary hcd.

2016-05-02 Thread Mathias Nyman

On 28.04.2016 11:33, Roger Quadros wrote:

Mathias,

On 22/04/16 21:00, Gabriel Krisman Bertazi wrote:

Mathias Nyman  writes:


Nice catch, and moving xhci_mem_cleanup() until second hcd (primary) is
removed is one way to solve it.


Thank you and Roger for your suggestions!


But I don't think we should even try to handle the interrupt at this stage 
anymore.
The host is already halted and normally the handler should not be called 
anymore.

How about handling interrupts for a halted host in the same way as a dying host?
Does something like this work for your TI devices?


I really liked your suggestions.  In fact, I agree, we shouldn't be
handling interrupts anymore at this stage of shutdown.  Nevertheless, I
still think it makes sense to refactor xhci_stop such that we don't trip
on this again.  We definitely shouldn't call xhci_mem_cleanup before
releasing the primary hcd.

I merged your suggestion to the patch below, how do you feel about this
version?

Thanks,

-- >8 --
Subject: [PATCH v2] xhci: Cleanup only when releasing primary hcd

Under stress occasions some TI devices might not return early when
reading the status register during the quirk invocation of xhci_irq made
by usb_hcd_pci_remove.  This means that instead of returning, we end up
handling this interruption in the middle of a shutdown.  Since
xhci->event_ring has already been freed in xhci_mem_cleanup, we end up
accessing freed memory, causing the Oops below.

commit 8c24d6d7b09d ("usb: xhci: stop everything on the first call to
xhci_stop") is the one that changed the instant in which we clean up the
event queue when stopping a device.  Before, we didn't call
xhci_mem_cleanup at the first time xhci_stop is executed (for the shared
HCD), instead, we only did it after the invocation for the primary HCD,
much later at the removal path.  The code flow for this oops looks like
this:

xhci_pci_remove()
usb_remove_hcd(xhci->shared)
xhci_stop(xhci->shared)
xhci_halt()
xhci_mem_cleanup(xhci);  // Free the event_queue
usb_hcd_pci_remove(primary)
xhci_irq()  // Access the event_queue if STS_EINT is set. Crash.
xhci_stop()
xhci_halt()
// return early

The fix modifies xhci_stop to only cleanup the xhci data when releasing
the primary HCD.  This way, we still have the event_queue configured
when invoking xhci_irq.  We still halt the device on the first call to
xhci_stop, though.

I could reproduce this issue several times on the mainline kernel by
doing a bind-unbind stress test with a specific storage gadget attached.
I also ran the same test over-night with my patch applied and didn't
observe the issue anymore.

[  113.334124] Unable to handle kernel paging request for data at address 
0x0028
[  113.335514] Faulting instruction address: 0xdd4f767c
[  113.336839] Oops: Kernel access of bad area, sig: 11 [#1]
[  113.338214] SMP NR_CPUS=1024 NUMA PowerNV

[c00efe47ba90] c0720850 usb_hcd_irq+0x50/0x80
[c00efe47bac0] c073d328 usb_hcd_pci_remove+0x68/0x1f0
[c00efe47bb00] ddaf0128 xhci_pci_remove+0x78/0xb0
[xhci_pci]
[c00efe47bb30] c055cf70 pci_device_remove+0x70/0x110
[c00efe47bb70] c061c6bc __device_release_driver+0xbc/0x190
[c00efe47bba0] c061c7d0 device_release_driver+0x40/0x70
[c00efe47bbd0] c0619510 unbind_store+0x120/0x150
[c00efe47bc20] c06183c4 drv_attr_store+0x64/0xa0
[c00efe47bc60] c039f1d0 sysfs_kf_write+0x80/0xb0
[c00efe47bca0] c039e14c kernfs_fop_write+0x18c/0x1f0
[c00efe47bcf0] c02e962c __vfs_write+0x6c/0x190
[c00efe47bd90] c02eab40 vfs_write+0xc0/0x200
[c00efe47bde0] c02ec85c SyS_write+0x6c/0x110
[c00efe47be30] c0009260 system_call+0x38/0x108

Signed-off-by: Gabriel Krisman Bertazi 
Cc: Roger Quadros 
Cc: j...@jms.id.au
Cc: sta...@vger.kernel.org
Reviewed-by: Roger Quadros 
---
  drivers/usb/host/xhci-ring.c |  3 ++-
  drivers/usb/host/xhci.c  | 27 +++
  2 files changed, 17 insertions(+), 13 deletions(-)

diff --git a/drivers/usb/host/xhci-ring.c b/drivers/usb/host/xhci-ring.c
index 99b4ff4..447abaa 100644
--- a/drivers/usb/host/xhci-ring.c
+++ b/drivers/usb/host/xhci-ring.c
@@ -2728,7 +2728,8 @@ hw_died:
writel(irq_pending, >ir_set->irq_pending);
}

-   if (xhci->xhc_state & XHCI_STATE_DYING) {
+   if (xhci->xhc_state & XHCI_STATE_DYING ||
+   xhci->xhc_state & XHCI_STATE_HALTED) {
xhci_dbg(xhci, "xHCI dying, ignoring interrupt. "
"Shouldn't IRQs be disabled?\n");
/* Clear the event handler busy flag (RW1C);
diff --git a/drivers/usb/host/xhci.c b/drivers/usb/host/xhci.c
index 

Re: [PATCH] USB: leave LPM alone if possible when binding/unbinding interface drivers

2016-05-02 Thread Mathias Nyman

On 29.04.2016 22:25, Alan Stern wrote:

When a USB driver is bound to an interface (either through probing or
by claiming it) or is unbound from an interface, the USB core always
disables Link Power Management during the transition and then
re-enables it afterward.  The reason is because the driver might want
to prevent hub-initiated link power transitions, in which case the HCD
would have to recalculate the various LPM parameters.  This
recalculation takes place when LPM is re-enabled and the new
parameters are sent to the device and its parent hub.

However, if the driver does not want to prevent hub-initiated link
power transitions then none of this work is necessary.  The parameters
don't need to be recalculated, and LPM doesn't need to be disabled and
re-enabled.

It turns out that disabling and enabling LPM can be time-consuming,
enough so that it interferes with user programs that want to claim and
release interfaces rapidly via usbfs.  Since the usbfs kernel driver
doesn't set the disable_hub_initiated_lpm flag, we can speed things up
and get the user programs to work by leaving LPM alone whenever the
flag isn't set.

And while we're improving the way disable_hub_initiated_lpm gets used,
let's also fix its kerneldoc.

Signed-off-by: Alan Stern 
Tested-by: Matthew Giassa 
CC: Mathias Nyman 
CC: 

---

Mathias, can you check that this is right?  If the driver's
disable_hub_initiated_lpm flag isn't set then binding or unbinding it
shouldn't require any changes to the LPM parameters.  The flag gets
used in only one place, in xhci_calculate_lpm_timeout(), and if it
isn't set then then result would be the same as if the driver weren't
bound.

Thanks.


It looks like xhci driver calculates the u1 and u2 timeout values for
ports based on udev->u1_params.sel * x (where x depends on endpoint type).

It loops through all active interfaces all endpoints, and picks the worst
(longest) timeout as the timeout value.

In this sense if a interface drive disappears or appears it could be possible
that the timeout values change, even if the xhci_calculate_lpm_timeout() is
not set.

usb_enable_lpm()
  usb_enable_link_state()
hcd->driver->enable_usb3_lpm_timeout(hcd, udev, state)
  xhci_calculate_lpm_timeout()
for (i = 0; i < udev->actconfig->desc.bNumInterfaces; i++)
  xhci_update_timeout_for_interface(... ))
for (j = 0; j < alt->desc.bNumEndpoints; j++)
  xhci_update_timeout_for_endpoint() // saves longest 
timeout
xhci_call_host_update_timeout_for_endpoint()
  ..xhci_calculate_intel_u1_timeout()  // skipped a few steps
 case USB_ENDPOINT_XFER_CONTROL:
   timeout = udev->u1_params.sel * 3;
 case USB_ENDPOINT_XFER_BULK:
   timeout = udev->u1_params.sel * 5;
 case USB_ENDPOINT_XFER_INT:
timeout = ...

-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 v4 01/13] USB: ch341: fix error handling on resume

2016-05-02 Thread Johan Hovold
On Fri, Apr 29, 2016 at 05:11:13PM +0200, Grigori Goronzy wrote:
> On 2016-04-29 14:16, Johan Hovold wrote:
> > On Fri, Apr 15, 2016 at 11:14:04PM +0200, Grigori Goronzy wrote:
> >> This may fail, do not assume it always works.
> >> 
> >> Signed-off-by: Grigori Goronzy 
> >> ---
> >>  drivers/usb/serial/ch341.c | 4 +---
> >>  1 file changed, 1 insertion(+), 3 deletions(-)
> >> 
> >> diff --git a/drivers/usb/serial/ch341.c b/drivers/usb/serial/ch341.c
> >> index c73808f..63df8ce 100644
> >> --- a/drivers/usb/serial/ch341.c
> >> +++ b/drivers/usb/serial/ch341.c
> >> @@ -544,9 +544,7 @@ static int ch341_reset_resume(struct usb_serial 
> >> *serial)
> >>priv = usb_get_serial_port_data(serial->port[0]);
> >> 
> >>/* reconfigure ch341 serial port after bus-reset */
> >> -  ch341_configure(serial->dev, priv);
> >> -
> >> -  return 0;
> >> +  return ch341_configure(serial->dev, priv);
> > 
> > This is correct, but have noticed that resume is currently broken in
> > that the interrupt urb is never resubmitted on resume in case the port 
> > is
> > already open?
> > 
> > Also ch341_configure must not use GFP_KERNEL either if called from a
> > resume path (use GFP_NOIO).
> > 
> > Care to fix this up as well?
> > 
> 
> Sure. How can I trigger a reset properly? AFAIR, I tried USBDEVFS_RESET 
> and it didn't really do what I wanted, at least the reset_resume 
> callback wasn't invoked.

You should be able to use the USB persistent-device functionality or
temporarily enable the USB_QUIRK_RESET_RESUME quirk for your device to
have reset_resume be called on system resume, but note that a resume
callback also needs to be implemented for normal (system and runtime)
resume.

Also note that reset_resume for usb-serial is currently broken in
mainline (since 4.5).

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


Re: add device id to linux kernel

2016-05-02 Thread gre...@linuxfoundation.org
On Mon, May 02, 2016 at 09:22:57AM +0300, Felipe Balbi wrote:
> 
> Hi,
> 
> 刘磊  writes:
> > dear linuxfoundation:
> > I am liulei come from ZTEMT.  We need add some device ID to linux 
> > kernel, We need some help from yours. 
> > Looking forward to you reply, thanks!
> >
> >
> > Signed-off-by:lei liu



> Do all these devices really exist ? If they do, then please just send
> this as a proper patch and it should be simple to get it merged. See
> Documentation/SubmittingPatches for some hints as to how to write proper
> patches, but basically, your patch needs a commit log with a
> Signed-off-by line.

There is a signed-off-by line :)

--
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: [RFT PATCH 0/3] usb: misc: usb3503: Fix missing device when TFTP booting

2016-05-02 Thread Krzysztof Kozlowski
On 05/02/2016 03:40 PM, Hans Verkuil wrote:
>>> Anyway, after disabling that config option I was finally able to test your 
>>> patch
>>> series:
>>>
>>> Tested-by: Hans Verkuil 
> 
> BTW, one thing I noticed is that to have u-boot detect the network device I
> need to call 'usb reset' twice. This is with u-boot 2016.1 release.
> 
> Not a big deal, but I wondered if you see the same.

Yes, I also have to do it twice.

Best regards,
Krzysztof

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


Re: [RFT PATCH 0/3] usb: misc: usb3503: Fix missing device when TFTP booting

2016-05-02 Thread Hans Verkuil
On 05/01/16 18:42, Krzysztof Kozlowski wrote:
> On Sun, May 01, 2016 at 06:01:08PM +0200, Hans Verkuil wrote:
>>> Sorry, I meant the hanging issue I got in 4.6, not the ethernet issue.
>>> I get the same problem with linux-next. Can you mail me the .config you are 
>>> using?
>>
>> Never mind.
>>
>>> After some more testing I don't think it is hanging, instead it seems that 
>>> the mmc
>>> isn't enabled/found and so it just sits waiting for the root partition to 
>>> appear.
>>
>> That was fun. There are two problems that both caused the boot to end at the 
>> same
>> place: first of all the root partition is now called mmcblk1p1 instead of 
>> mmcblk0p1
>> in 4.6, so it was just waiting for the root partition to appear. Nothing to 
>> do with
>> your patch series, just unexpected.
> 
> Yes, annoying issue and unfortunately this is known... recommended
> solution is to use root=PARTUUID= (you can get the PARTUUID with
> blkid)... or replace the mmc device.
> 
>> The second is that enabling CONFIG_VIDEO_S5P_FIMC causes the boot to hang at 
>> that
>> same place. I suspect there is a deadlock somewhere. I'm digging deeper into 
>> that
>> but again, unrelated to your patch series.
>>
>> Anyway, after disabling that config option I was finally able to test your 
>> patch
>> series:
>>
>> Tested-by: Hans Verkuil 

BTW, one thing I noticed is that to have u-boot detect the network device I
need to call 'usb reset' twice. This is with u-boot 2016.1 release.

Not a big deal, but I wondered if you see the same.

Regards,

Hans
--
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] Revert "USB / PM: Allow USB devices to remain runtime-suspended when sleeping"

2016-05-02 Thread Johan Hovold
This reverts commit e3345db85068ddb937fc0ba40dfc39c293dad977, which
broke system resume for a large class of devices.

Devices that after having been reset during resume need to be rebound
due to a missing reset_resume callback, are now left in a suspended
state. This specifically broke resume of common USB-serial devices,
which are now unusable after system suspend (until disconnected and
reconnected) when USB persist is enabled.

During resume, usb_resume_interface will set the needs_binding flag for
such interfaces, but unlike system resume, run-time resume does not
honour it.

Cc: stable  # 4.5
Signed-off-by: Johan Hovold 
---

Greg, Alan,

This patch for v4.6-rc7 fixes a 4.5-regression that broke system suspend
for a large class of devices, including USB-serial devices, for example
when USB persist is enabled.

We may be able to find a way around this, but since it's a user-visible
regression and late in the rc-cycle, I believe reverting the offending
commit is the right thing to do.

Thanks,
Johan


 drivers/usb/core/port.c | 6 --
 drivers/usb/core/usb.c  | 8 +---
 2 files changed, 1 insertion(+), 13 deletions(-)

diff --git a/drivers/usb/core/port.c b/drivers/usb/core/port.c
index 14718a9ffcfb..460c855be0d0 100644
--- a/drivers/usb/core/port.c
+++ b/drivers/usb/core/port.c
@@ -249,18 +249,12 @@ static int usb_port_runtime_suspend(struct device *dev)
 
return retval;
 }
-
-static int usb_port_prepare(struct device *dev)
-{
-   return 1;
-}
 #endif
 
 static const struct dev_pm_ops usb_port_pm_ops = {
 #ifdef CONFIG_PM
.runtime_suspend =  usb_port_runtime_suspend,
.runtime_resume =   usb_port_runtime_resume,
-   .prepare =  usb_port_prepare,
 #endif
 };
 
diff --git a/drivers/usb/core/usb.c b/drivers/usb/core/usb.c
index dcb85e3cd5a7..479187c32571 100644
--- a/drivers/usb/core/usb.c
+++ b/drivers/usb/core/usb.c
@@ -312,13 +312,7 @@ static int usb_dev_uevent(struct device *dev, struct 
kobj_uevent_env *env)
 
 static int usb_dev_prepare(struct device *dev)
 {
-   struct usb_device *udev = to_usb_device(dev);
-
-   /* Return 0 if the current wakeup setting is wrong, otherwise 1 */
-   if (udev->do_remote_wakeup != device_may_wakeup(dev))
-   return 0;
-
-   return 1;
+   return 0;   /* Implement eventually? */
 }
 
 static void usb_dev_complete(struct device *dev)
-- 
2.7.3

--
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 v7 00/14] USB OTG/dual-role framework

2016-05-02 Thread Roger Quadros
Hi,

This series centralizes OTG/Dual-role functionality in the kernel.
As of now I've got Dual-role functionality working pretty reliably on
dra7-evm and am437x-gp-evm.

DWC3 controller and platform related patches will be sent separately.

Series is based on v4.6-rc1 and depends on first 2 patches of [1]
[1] - OTG fsm cleanup - https://lkml.org/lkml/2016/3/30/186

Why?:


Currently there is no central location where OTG/dual-role functionality is
implemented in the Linux USB stack and every USB controller driver is
doing their own thing for OTG/dual-role. We can benefit from code-reuse
and simplicity by adding the OTG/dual-role core driver.

Newer OTG cores support standard host interface (e.g. xHCI) so
host and gadget functionality are no longer closely knit like older
cores. There needs to be a way to co-ordinate the operation of the
host and gadget controllers in dual-role mode. i.e. to stop and start them
from a central location. This central location should be the
USB OTG/dual-role core.

Host and gadget controllers might be sharing resources and can't
be always running. One has to be stopped for the other to run.
This couldn't be done till now but can be done from the OTG core.

What?:
-

The OTG/dual-role core consists of a set of APIs that allow
registration of OTG controller device and OTG capable host and gadget
controllers.

- The OTG controller driver can provide the OTG capabilities and the
Finite State Machine work function via 'struct usb_otg_config'
at the time of registration i.e. usb_otg_register();

struct usb_otg *usb_otg_register(struct device *dev,
 struct usb_otg_config *config);
int usb_otg_unregister(struct device *dev);
/**
 * struct usb_otg_config - otg controller configuration
 * @caps: otg capabilities of the controller
 * @ops: otg fsm operations
 * @otg_work: optional custom otg state machine work function
 */
struct usb_otg_config {
struct usb_otg_caps *otg_caps;
struct otg_fsm_ops *fsm_ops;
void (*otg_work)(struct work_struct *work);
};

The dual-role state machine is built-into the OTG core so nothing
special needs to be provided if only dual-role functionality is desired.
The low level OTG controller driver ops are povided via
'struct otg_fsm_ops *fsm_ops' in the 'struct usb_otg_config'.

After registration, the OTG core waits for host, gadget controller
and the gadget function driver to be registered. Once all resources are
available it instantiates the Finite State Machine (FSM).
The host/gadget controllers are started/stopped according to the FSM.

- Host and gadget controllers that are a part of OTG/dual-role port must
use the OTG core provided APIs to add/remove the host/gadget.
i.e. hosts must use usb_otg_add_hcd() usb_otg_remove_hcd(),,
gadgets must use usb_otg_add_gadget_udc() usb_del_gadget_udc().
This ensures that the host and gadget controllers are not started till
the state machine is ready and the right bus conditions are met.
It also allows the host and gadget controllers to provide the OTG
controller device to link them together. For Device tree boots
the related OTG controller is automatically picked up via the
'otg-controller' property in the Host/Gadget controller nodes.

int usb_otg_add_hcd(struct usb_hcd *hcd,
unsigned int irqnum, unsigned long irqflags,
struct device *otg_dev);
void usb_otg_remove_hcd(struct usb_hcd *hcd);

int usb_otg_add_gadget_udc(struct device *parent,
   struct usb_gadget *gadget,
   struct device *otg_dev);
usb_del_gadget_udc() must be used for removal.


- During the lifetime of the FSM, the OTG controller driver can provide
inputs event changes using usb_otg_sync_inputs(). The OTG core will
then schedule the FSM work function (or internal dual-role state machine)
to update the FSM state. The FSM then calls the OTG controller
operations (fsm_ops) as necessary.
void usb_otg_sync_inputs(struct usb_otg *otg);

- The following 2 functions are provided as helpers for use by the
OTG controller driver to start/stop the host/gadget controllers.
int usb_otg_start_host(struct usb_otg *otg, int on);
int usb_otg_start_gadget(struct usb_otg *otg, int on);

- The following function is provided for use by the USB host stack
to sync OTG related events to the OTG state machine.
e.g. change in host_bus->b_hnp_enable, gadget->b_hnp_enable
int usb_otg_kick_fsm(struct device *otg_device);

Changelog:
-
v7:
- added dual-role support for host controllers requiring a companion
controller. e.g. EHCI + OHCI.
- added of_usb_get_otg() to get the OTG controller device
from the USB controller's device node.
- addressed review comments.

v6:
- added otg specific APIs for host/gadget 

[PATCH v7 07/14] usb: otg: get rid of CONFIG_USB_OTG_FSM in favour of CONFIG_USB_OTG

2016-05-02 Thread Roger Quadros
Let's use CONFIG_USB_OTG as a single config option to enable
USB OTG and the OTG FSM. This makes things a lot less confusing.

Update all users of CONFIG_USB_OTG_FSM to CONFIG_USB_OTG.

Signed-off-by: Roger Quadros 
---
 Documentation/usb/chipidea.txt | 2 +-
 drivers/usb/chipidea/Makefile  | 2 +-
 drivers/usb/chipidea/ci.h  | 2 +-
 drivers/usb/chipidea/otg_fsm.h | 2 +-
 drivers/usb/common/Makefile| 3 ++-
 drivers/usb/core/Kconfig   | 8 
 drivers/usb/phy/Kconfig| 2 +-
 7 files changed, 7 insertions(+), 14 deletions(-)

diff --git a/Documentation/usb/chipidea.txt b/Documentation/usb/chipidea.txt
index 678741b..3b1f263 100644
--- a/Documentation/usb/chipidea.txt
+++ b/Documentation/usb/chipidea.txt
@@ -5,7 +5,7 @@ with 2 Freescale i.MX6Q sabre SD boards.
 
 1.1 How to enable OTG FSM in menuconfig
 ---
-Select CONFIG_USB_OTG_FSM, rebuild kernel Image and modules.
+Select CONFIG_USB_OTG, rebuild kernel Image and modules.
 If you want to check some internal variables for otg fsm,
 mount debugfs, there are 2 files which can show otg fsm
 variables and some controller registers value:
diff --git a/drivers/usb/chipidea/Makefile b/drivers/usb/chipidea/Makefile
index 518e445..45aa24d 100644
--- a/drivers/usb/chipidea/Makefile
+++ b/drivers/usb/chipidea/Makefile
@@ -3,7 +3,7 @@ obj-$(CONFIG_USB_CHIPIDEA)  += ci_hdrc.o
 ci_hdrc-y  := core.o otg.o debug.o
 ci_hdrc-$(CONFIG_USB_CHIPIDEA_UDC) += udc.o
 ci_hdrc-$(CONFIG_USB_CHIPIDEA_HOST)+= host.o
-ci_hdrc-$(CONFIG_USB_OTG_FSM)  += otg_fsm.o
+ci_hdrc-$(CONFIG_USB_OTG)  += otg_fsm.o
 
 # Glue/Bridge layers go here
 
diff --git a/drivers/usb/chipidea/ci.h b/drivers/usb/chipidea/ci.h
index c523975..1a32b8c 100644
--- a/drivers/usb/chipidea/ci.h
+++ b/drivers/usb/chipidea/ci.h
@@ -406,7 +406,7 @@ static inline u32 hw_test_and_write(struct ci_hdrc *ci, 
enum ci_hw_regs reg,
  */
 static inline bool ci_otg_is_fsm_mode(struct ci_hdrc *ci)
 {
-#ifdef CONFIG_USB_OTG_FSM
+#ifdef CONFIG_USB_OTG
struct usb_otg_caps *otg_caps = >platdata->ci_otg_caps;
 
return ci->is_otg && ci->roles[CI_ROLE_HOST] &&
diff --git a/drivers/usb/chipidea/otg_fsm.h b/drivers/usb/chipidea/otg_fsm.h
index 6366fe3..2d451bb 100644
--- a/drivers/usb/chipidea/otg_fsm.h
+++ b/drivers/usb/chipidea/otg_fsm.h
@@ -64,7 +64,7 @@
 
 #define TB_AIDL_BDIS (20)  /* 4ms ~ 150ms, section 5.2.1 */
 
-#if IS_ENABLED(CONFIG_USB_OTG_FSM)
+#if IS_ENABLED(CONFIG_USB_OTG)
 
 int ci_hdrc_otg_fsm_init(struct ci_hdrc *ci);
 int ci_otg_fsm_work(struct ci_hdrc *ci);
diff --git a/drivers/usb/common/Makefile b/drivers/usb/common/Makefile
index 6bbb3ec..f8f2c88 100644
--- a/drivers/usb/common/Makefile
+++ b/drivers/usb/common/Makefile
@@ -6,5 +6,6 @@ obj-$(CONFIG_USB_COMMON)  += usb-common.o
 usb-common-y += common.o
 usb-common-$(CONFIG_USB_LED_TRIG) += led.o
 
-obj-$(CONFIG_USB_OTG_FSM) += usb-otg-fsm.o
 obj-$(CONFIG_USB_ULPI_BUS) += ulpi.o
+usbotg-y   := usb-otg-fsm.o
+obj-$(CONFIG_USB_OTG)  += usbotg.o
diff --git a/drivers/usb/core/Kconfig b/drivers/usb/core/Kconfig
index dd28010..ae228d0 100644
--- a/drivers/usb/core/Kconfig
+++ b/drivers/usb/core/Kconfig
@@ -75,14 +75,6 @@ config USB_OTG_BLACKLIST_HUB
  and software costs by not supporting external hubs.  So
  are "Embedded Hosts" that don't offer OTG support.
 
-config USB_OTG_FSM
-   tristate "USB 2.0 OTG FSM implementation"
-   depends on USB && USB_OTG
-   select USB_PHY
-   help
- Implements OTG Finite State Machine as specified in On-The-Go
- and Embedded Host Supplement to the USB Revision 2.0 Specification.
-
 config USB_ULPI_BUS
tristate "USB ULPI PHY interface support"
depends on USB_SUPPORT
diff --git a/drivers/usb/phy/Kconfig b/drivers/usb/phy/Kconfig
index c690474..06794e2 100644
--- a/drivers/usb/phy/Kconfig
+++ b/drivers/usb/phy/Kconfig
@@ -20,7 +20,7 @@ config AB8500_USB
 
 config FSL_USB2_OTG
bool "Freescale USB OTG Transceiver Driver"
-   depends on USB_EHCI_FSL && USB_FSL_USB2 && USB_OTG_FSM && PM
+   depends on USB_EHCI_FSL && USB_FSL_USB2 && USB_OTG && PM
select USB_PHY
help
  Enable this to support Freescale USB OTG transceiver.
-- 
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 v7 10/14] usb: otg: add hcd companion support

2016-05-02 Thread Roger Quadros
From: Yoshihiro Shimoda 

Since some host controller (e.g. EHCI) needs a companion host controller
(e.g. OHCI), this patch adds such a configuration to use it in the OTG
core.

Signed-off-by: Yoshihiro Shimoda 
Signed-off-by: Roger Quadros 
---
 Documentation/devicetree/bindings/usb/generic.txt |  3 +++
 drivers/usb/common/usb-otg.c  | 32 ---
 include/linux/usb/otg.h   |  7 -
 3 files changed, 32 insertions(+), 10 deletions(-)

diff --git a/Documentation/devicetree/bindings/usb/generic.txt 
b/Documentation/devicetree/bindings/usb/generic.txt
index f6866c1..1db1c33 100644
--- a/Documentation/devicetree/bindings/usb/generic.txt
+++ b/Documentation/devicetree/bindings/usb/generic.txt
@@ -27,6 +27,9 @@ Optional properties:
  - otg-controller: phandle to otg controller. Host or gadget controllers can
contain this property to link it to a particular OTG
controller.
+ - hcd-needs-companion: must be present if otg controller is dealing with
+   EHCI host controller that needs a companion OHCI host
+   controller.
 
 This is an attribute to a USB controller such as:
 
diff --git a/drivers/usb/common/usb-otg.c b/drivers/usb/common/usb-otg.c
index 702bca8..77048aa 100644
--- a/drivers/usb/common/usb-otg.c
+++ b/drivers/usb/common/usb-otg.c
@@ -20,6 +20,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -582,6 +583,10 @@ struct usb_otg *usb_otg_register(struct device *dev,
else
INIT_WORK(>work, usb_drd_work);
 
+   if (of_find_property(dev->of_node, "hcd-needs-companion", NULL) ||
+   config->hcd_needs_companion)/* needs companion ? */
+   otg->flags |= OTG_FLAG_HCD_NEEDS_COMPANION;
+
otg->wq = create_singlethread_workqueue("usb_otg");
if (!otg->wq) {
dev_err(dev, "otg: %s: can't create workqueue\n",
@@ -805,15 +810,18 @@ int usb_otg_register_hcd(struct usb_hcd *hcd, unsigned 
int irqnum,
/* HCD will be started by OTG fsm when needed */
mutex_lock(>fsm.lock);
if (otg->primary_hcd.hcd) {
-   /* probably a shared HCD ? */
-   if (usb_otg_hcd_is_primary_hcd(hcd)) {
+   /* probably a shared HCD or a companion OHCI HCD ? */
+   if (!(otg->flags & OTG_FLAG_HCD_NEEDS_COMPANION) &&
+   usb_otg_hcd_is_primary_hcd(hcd)) {
dev_err(otg_dev, "otg: primary host already 
registered\n");
goto err;
}
 
-   if (hcd->shared_hcd == otg->primary_hcd.hcd) {
+   if (otg->flags & OTG_FLAG_HCD_NEEDS_COMPANION ||
+   (hcd->shared_hcd == otg->primary_hcd.hcd)) {
if (otg->shared_hcd.hcd) {
-   dev_err(otg_dev, "otg: shared host already 
registered\n");
+   dev_err(otg_dev,
+   "otg: shared/companion host already 
registered\n");
goto err;
}
 
@@ -821,10 +829,12 @@ int usb_otg_register_hcd(struct usb_hcd *hcd, unsigned 
int irqnum,
otg->shared_hcd.irqnum = irqnum;
otg->shared_hcd.irqflags = irqflags;
otg->shared_hcd.ops = ops;
-   dev_info(otg_dev, "otg: shared host %s registered\n",
+   dev_info(otg_dev,
+"otg: shared/companion host %s registered\n",
 dev_name(hcd->self.controller));
} else {
-   dev_err(otg_dev, "otg: invalid shared host %s\n",
+   dev_err(otg_dev,
+   "otg: invalid shared/companion host %s\n",
dev_name(hcd->self.controller));
goto err;
}
@@ -847,14 +857,17 @@ int usb_otg_register_hcd(struct usb_hcd *hcd, unsigned 
int irqnum,
 * we're ready only if we have shared HCD
 * or we don't need shared HCD.
 */
-   if (otg->shared_hcd.hcd || !otg->primary_hcd.hcd->shared_hcd) {
+   if (otg->shared_hcd.hcd ||
+   (!(otg->flags & OTG_FLAG_HCD_NEEDS_COMPANION) &&
+!otg->primary_hcd.hcd->shared_hcd)) {
otg->host = hcd_to_bus(hcd);
/* FIXME: set bus->otg_port if this is true OTG port with HNP */
 
/* start FSM */
usb_otg_start_fsm(otg);
} else {
-   dev_dbg(otg_dev, "otg: can't start till shared host 
registers\n");
+   dev_dbg(otg_dev,
+   "otg: can't start till shared/companion host 
registers\n");
}
 

[PATCH v7 09/14] usb: of: add an API to get OTG device from USB controller node

2016-05-02 Thread Roger Quadros
The OTG controller and the USB controller an be linked via the
'otg-controller' property in the USB controller's device node.

of_usb_get_otg() can be used to get the OTG controller device
from the USB controller's device node.

Signed-off-by: Roger Quadros 
---
 Documentation/devicetree/bindings/usb/generic.txt |  3 +++
 drivers/usb/common/common.c   | 27 +++
 include/linux/usb/of.h|  9 
 3 files changed, 39 insertions(+)

diff --git a/Documentation/devicetree/bindings/usb/generic.txt 
b/Documentation/devicetree/bindings/usb/generic.txt
index bba8257..f6866c1 100644
--- a/Documentation/devicetree/bindings/usb/generic.txt
+++ b/Documentation/devicetree/bindings/usb/generic.txt
@@ -24,6 +24,9 @@ Optional properties:
optional for OTG device.
  - adp-disable: tells OTG controllers we want to disable OTG ADP, ADP is
optional for OTG device.
+ - otg-controller: phandle to otg controller. Host or gadget controllers can
+   contain this property to link it to a particular OTG
+   controller.
 
 This is an attribute to a USB controller such as:
 
diff --git a/drivers/usb/common/common.c b/drivers/usb/common/common.c
index e3d0161..d7ec471 100644
--- a/drivers/usb/common/common.c
+++ b/drivers/usb/common/common.c
@@ -238,6 +238,33 @@ int of_usb_update_otg_caps(struct device_node *np,
 }
 EXPORT_SYMBOL_GPL(of_usb_update_otg_caps);
 
+#ifdef CONFIG_USB_OTG
+/**
+ * of_usb_get_otg - get the OTG controller linked to the USB controller
+ * @np: Pointer to the device_node of the USB controller
+ * @otg_caps: Pointer to the target usb_otg_caps to be set
+ *
+ * Returns the OTG controller device or NULL on error.
+ */
+struct device *of_usb_get_otg(struct device_node *np)
+{
+   struct device_node *otg_np;
+   struct platform_device *pdev;
+
+   otg_np = of_parse_phandle(np, "otg-controller", 0);
+   if (!otg_np)
+   return NULL;
+
+   pdev = of_find_device_by_node(otg_np);
+   of_node_put(otg_np);
+   if (!pdev)
+   return NULL;
+
+   return >dev;
+}
+EXPORT_SYMBOL_GPL(of_usb_get_otg);
+#endif
+
 #endif
 
 MODULE_LICENSE("GPL");
diff --git a/include/linux/usb/of.h b/include/linux/usb/of.h
index de3237f..499a4e8 100644
--- a/include/linux/usb/of.h
+++ b/include/linux/usb/of.h
@@ -40,6 +40,15 @@ static inline struct device_node *usb_of_get_child_node
 }
 #endif
 
+#if IS_ENABLED(CONFIG_OF) && IS_ENABLED(CONFIG_USB_OTG)
+struct device *of_usb_get_otg(struct device_node *np);
+#else
+static inline struct device *of_usb_get_otg(struct device_node *np)
+{
+   return NULL;
+}
+#endif
+
 #if IS_ENABLED(CONFIG_OF) && IS_ENABLED(CONFIG_USB_SUPPORT)
 enum usb_phy_interface of_usb_get_phy_mode(struct device_node *np);
 #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


[PATCH v7 01/14] usb: hcd: Initialize hcd->flags to 0

2016-05-02 Thread Roger Quadros
When using the OTG/drd library we can call hcd_add/remove
consecutively without calling usb_put_hcd/usb_create_hcd in between
so hcd->flags can be stale.

If the HC dies due to whatever reason then without this
patch we get the below error on next hcd_add.

[   91.494257] xhci-hcd xhci-hcd.0.auto: HC died; cleaning up
[   91.502068] hub 3-0:1.0: state 0 ports 1 chg  evt 
[   91.510240] xhci-hcd xhci-hcd.0.auto: xHCI Host Controller
[   91.516940] xhci-hcd xhci-hcd.0.auto: new USB bus registered, assigned bus 
number 4
[   91.529745] usb usb4: We don't know the algorithms for LPM for this host, 
disabling LPM.
[   91.540637] usb usb4: New USB device found, idVendor=1d6b, idProduct=0003
[   91.757865] irq 254: nobody cared (try booting with the "irqpoll" option)
[   91.757880] CPU: 0 PID: 68 Comm: kworker/u2:2 Not tainted 
4.1.4-00828-g1f0ed8c-dirty #44
[   91.757885] Hardware name: Generic AM43 (Flattened Device Tree)
[   91.757914] Workqueue: usb_otg usb_otg_work
[   91.757921] Backtrace:
[   91.757954] [] (dump_backtrace) from [] 
(show_stack+0x18/0x1c)
[   91.757972]  r6:c089d4a4 r5: r4: r3:ee44
[   91.757991] [] (show_stack) from [] 
(dump_stack+0x84/0xd0)
[   91.758008] [] (dump_stack) from [] 
(__report_bad_irq+0x28/0xc8)
[   91.758024]  r7: r6:00fe r5: r4:ee514c40
[   91.758037] [] (__report_bad_irq) from [] 
(note_interrupt+0x24c/0x2ac)
[   91.758052]  r6:00fe r5: r4:ee514c40 r3:
[   91.758065] [] (note_interrupt) from [] 
(handle_irq_event_percpu+0xb0/0x158)
[   91.758085]  r10:ee514c40 r9:c08ce49a r8:00fe r7: r6: 
r5:
[   91.758094]  r4: r3:
[   91.758105] [] (handle_irq_event_percpu) from [] 
(handle_irq_event+0x44/0x64)
[   91.758126]  r10:0001 r9:ee441ab0 r8:ee441bb8 r7:c0858b4c r6:ed174280 
r5:ee514ca0
[   91.758132]  r4:ee514c40
[   91.758144] [] (handle_irq_event) from [] 
(handle_fasteoi_irq+0x100/0x1bc)
[   91.758159]  r6:c085dba0 r5:ee514ca0 r4:ee514c40 r3:
[   91.758171] [] (handle_fasteoi_irq) from [] 
(generic_handle_irq+0x28/0x38)
[   91.758186]  r7:c0853d40 r6:c0858b4c r5:00fe r4:00fe
[   91.758197] [] (generic_handle_irq) from [] 
(__handle_domain_irq+0x98/0x12c)
[   91.758207]  r4:c0853d40 r3:0100
[   91.758219] [] (__handle_domain_irq) from [] 
(gic_handle_irq+0x28/0x68)
[   91.758239]  r10:0001 r9:ee441bb8 r8:fa240100 r7:c0858d70 r6:ee441ab0 
r5:00b8
[   91.758245]  r4:fa24010c
[   91.758264] [] (gic_handle_irq) from [] 
(__irq_svc+0x40/0x74)
[   91.758271] Exception stack(0xee441ab0 to 0xee441af8)
[   91.758280] 1aa0:  c08d2980 
ee441ac0 
[   91.758292] 1ac0: 0008 0089 c0858b4c c0858080  ee441bb8 
0001 ee441b3c
[   91.758301] 1ae0: 0101 ee441af8 c02fc418 c0046a1c 2113 
[   91.758321]  r8: r7:ee441ae4 r6: r5:2113 r4:c0046a1c 
r3:c02fc418
[   91.758347] [] (__do_softirq) from [] 
(irq_exit+0xb8/0x104)
[   91.758367]  r10:0001 r9:ee441bb8 r8: r7:c0853d40 r6:c0858b4c 
r5:0089
[   91.758373]  r4:
[   91.758386] [] (irq_exit) from [] 
(__handle_domain_irq+0xa0/0x12c)
[   91.758395]  r4: r3:0100
[   91.758406] [] (__handle_domain_irq) from [] 
(gic_handle_irq+0x28/0x68)
[   91.758426]  r10:c08e3510 r9:2013 r8:fa240100 r7:c0858d70 r6:ee441bb8 
r5:0039
[   91.758433]  r4:fa24010c
[   91.758445] [] (gic_handle_irq) from [] 
(__irq_svc+0x40/0x74)
[   91.758450] Exception stack(0xee441bb8 to 0xee441c00)
[   91.758457] 1ba0:   
 0001
[   91.758468] 1bc0:  ee44 c08e2524 004d 0274  
 2013
[   91.758479] 1be0: c08e3510 ee441c4c ee441b60 ee441c00 c03acfec c0080d4c 
6013 
[   91.758499]  r8: r7:ee441bec r6: r5:6013 r4:c0080d4c 
r3:c03acfec
[   91.758524] [] (console_unlock) from [] 
(vprintk_emit+0x20c/0x500)
[   91.758544]  r10:ee441cc0 r9:c08d3550 r8:c08e3ea0 r7: r6:0001 
r5:003d
[   91.758551]  r4:c08d3550
[   91.758573] [] (vprintk_emit) from [] 
(dev_vprintk_emit+0x104/0x1ac)
[   91.758593]  r10:ee441d8c r9:000e r8:c07951e0 r7:0006 r6:ee441cc0 
r5:000d
[   91.758599]  r4:ee731068
[   91.758612] [] (dev_vprintk_emit) from [] 
(dev_printk_emit+0x28/0x30)
[   91.758632]  r10:0001 r9:ee5f8410 r8:ee731000 r7:ed429000 r6:0006 
r5:ee441dc0
[   91.758638]  r4:ee731068
[   91.758651] [] (dev_printk_emit) from [] 
(__dev_printk+0x50/0x70)
[   91.758660]  r3:bf2268cc r2:c07951e0
[   91.758673] [] (__dev_printk) from [] 
(_dev_info+0x3c/0x48)
[   91.758686]  r6: r5:ee731068 r4:ee731000
[   91.758790] [] (_dev_info) from [] 
(usb_new_device+0x11c/0x518 [usbcore])
[   91.758804]  r3:0003 r2:1d6b r1:bf225bc4
[   91.758881] [] (usb_new_device [usbcore]) from [] 
(usb_otg_add_hcd+0x514/0x7f8 [usbcore])
[   91.758903]  r10:0001 

[PATCH v7 12/14] usb: hcd: Adapt to OTG core

2016-05-02 Thread Roger Quadros
Introduce usb_otg_add/remove_hcd() for use by host
controllers that are part of OTG/dual-role port.

Non Device tree platforms can use the otg_dev argument
to specify the OTG controller device. If otg_dev is NULL
then the device tree node's otg-controller property is used to
get the otg_dev device.

Signed-off-by: Roger Quadros 
---
 drivers/usb/core/hcd.c  | 55 +
 include/linux/usb/hcd.h |  4 
 2 files changed, 59 insertions(+)

diff --git a/drivers/usb/core/hcd.c b/drivers/usb/core/hcd.c
index 9484539..cfc8232 100644
--- a/drivers/usb/core/hcd.c
+++ b/drivers/usb/core/hcd.c
@@ -46,6 +46,11 @@
 #include 
 #include 
 #include 
+#include 
+#include 
+
+#include 
+#include 
 
 #include "usb.h"
 
@@ -3013,6 +3018,56 @@ void usb_remove_hcd(struct usb_hcd *hcd)
 }
 EXPORT_SYMBOL_GPL(usb_remove_hcd);
 
+static struct otg_hcd_ops otg_hcd_intf = {
+   .add = usb_add_hcd,
+   .remove = usb_remove_hcd,
+   .usb_bus_start_enum = usb_bus_start_enum,
+   .usb_control_msg = usb_control_msg,
+   .usb_hub_find_child = usb_hub_find_child,
+};
+
+/**
+ * usb_otg_add_hcd - Register the HCD with OTG core.
+ * @hcd: the usb_hcd structure to initialize
+ * @irqnum: Interrupt line to allocate
+ * @irqflags: Interrupt type flags
+ * @otg_dev: OTG controller device managing this HCD
+ *
+ * Registers the HCD with OTG core. OTG core will call usb_add_hcd()
+ * or usb_remove_hcd() as necessary.
+ * If otg_dev is NULL then device tree node is checked for OTG
+ * controller device via the otg-controller property.
+ */
+int usb_otg_add_hcd(struct usb_hcd *hcd,
+   unsigned int irqnum, unsigned long irqflags,
+   struct device *otg_dev)
+{
+   struct device *dev = hcd->self.controller;
+
+   if (!otg_dev) {
+   hcd->otg_dev = of_usb_get_otg(dev->of_node);
+   if (!hcd->otg_dev)
+   return -ENODEV;
+   } else {
+   hcd->otg_dev = otg_dev;
+   }
+
+   return usb_otg_register_hcd(hcd, irqnum, irqflags, _hcd_intf);
+}
+EXPORT_SYMBOL_GPL(usb_otg_add_hcd);
+
+/**
+ * usb_otg_remove_hcd - Unregister the HCD with OTG core.
+ * @hcd: the usb_hcd structure to remove
+ *
+ * Unregisters the HCD from the OTG core.
+ */
+void usb_otg_remove_hcd(struct usb_hcd *hcd)
+{
+   usb_otg_unregister_hcd(hcd);
+}
+EXPORT_SYMBOL_GPL(usb_otg_remove_hcd);
+
 void
 usb_hcd_platform_shutdown(struct platform_device *dev)
 {
diff --git a/include/linux/usb/hcd.h b/include/linux/usb/hcd.h
index 2017cd4..adcf2e7 100644
--- a/include/linux/usb/hcd.h
+++ b/include/linux/usb/hcd.h
@@ -472,6 +472,10 @@ extern int usb_hcd_is_primary_hcd(struct usb_hcd *hcd);
 extern int usb_add_hcd(struct usb_hcd *hcd,
unsigned int irqnum, unsigned long irqflags);
 extern void usb_remove_hcd(struct usb_hcd *hcd);
+extern int usb_otg_add_hcd(struct usb_hcd *hcd,
+  unsigned int irqnum, unsigned long irqflags,
+  struct device *otg_dev);
+extern void usb_otg_remove_hcd(struct usb_hcd *hcd);
 extern int usb_hcd_find_raw_port_number(struct usb_hcd *hcd, int port1);
 
 struct platform_device;
-- 
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 v7 03/14] usb: hcd.h: Add OTG to HCD interface

2016-05-02 Thread Roger Quadros
The OTG core will use struct otg_hcd_ops to interface
with the HCD controller.

The main purpose of this interface is to avoid directly
calling HCD APIs from the OTG core as they
wouldn't be defined in the built-in symbol table if
CONFIG_USB is m.

Signed-off-by: Roger Quadros 
Acked-by: Peter Chen 
---
 include/linux/usb/hcd.h | 24 
 1 file changed, 24 insertions(+)

diff --git a/include/linux/usb/hcd.h b/include/linux/usb/hcd.h
index b98f831..861ccaa 100644
--- a/include/linux/usb/hcd.h
+++ b/include/linux/usb/hcd.h
@@ -399,6 +399,30 @@ struct hc_driver {
 
 };
 
+/**
+ * struct otg_hcd_ops - Interface between OTG core and HCD
+ *
+ * Provided by the HCD core to allow the OTG core to interface with the HCD
+ *
+ * @add: function to add the HCD
+ * @remove: function to remove the HCD
+ * @usb_bus_start_enum: function to immediately start bus enumeration
+ * @usb_control_msg: function to build and send of a control urb
+ * @usb_hub_find_child: function to get pointer to the child device
+ */
+struct otg_hcd_ops {
+   int (*add)(struct usb_hcd *hcd,
+  unsigned int irqnum, unsigned long irqflags);
+   void (*remove)(struct usb_hcd *hcd);
+   int (*usb_bus_start_enum)(struct usb_bus *bus, unsigned int port_num);
+   int (*usb_control_msg)(struct usb_device *dev, unsigned int pipe,
+  __u8 request, __u8 requesttype, __u16 value,
+  __u16 index, void *data, __u16 size,
+  int timeout);
+   struct usb_device * (*usb_hub_find_child)(struct usb_device *hdev,
+ int port1);
+};
+
 static inline int hcd_giveback_urb_in_bh(struct usb_hcd *hcd)
 {
return hcd->driver->flags & HCD_BH;
-- 
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 v7 08/14] usb: otg: add OTG/dual-role core

2016-05-02 Thread Roger Quadros
It provides APIs for the following tasks

- Registering an OTG/dual-role capable controller
- Registering Host and Gadget controllers to OTG core
- Providing inputs to and kicking the OTG state machine

Provide a dual-role device (DRD) state machine.
DRD mode is a reduced functionality OTG mode. In this mode
we don't support SRP, HNP and dynamic role-swap.

In DRD operation, the controller mode (Host or Peripheral)
is decided based on the ID pin status. Once a cable plug (Type-A
or Type-B) is attached the controller selects the state
and doesn't change till the cable in unplugged and a different
cable type is inserted.

As we don't need most of the complex OTG states and OTG timers
we implement a lean DRD state machine in usb-otg.c.
The DRD state machine is only interested in 2 hardware inputs
'id' and 'b_sess_vld'.

Signed-off-by: Roger Quadros 
---
 drivers/usb/common/Makefile  |2 +-
 drivers/usb/common/usb-otg.c | 1040 ++
 drivers/usb/common/usb-otg.h |   71 +++
 drivers/usb/core/Kconfig |2 +-
 include/linux/usb/gadget.h   |2 +
 include/linux/usb/hcd.h  |1 +
 include/linux/usb/otg-fsm.h  |7 +
 include/linux/usb/otg.h  |  154 ++-
 8 files changed, 1274 insertions(+), 5 deletions(-)
 create mode 100644 drivers/usb/common/usb-otg.c
 create mode 100644 drivers/usb/common/usb-otg.h

diff --git a/drivers/usb/common/Makefile b/drivers/usb/common/Makefile
index f8f2c88..730d928 100644
--- a/drivers/usb/common/Makefile
+++ b/drivers/usb/common/Makefile
@@ -7,5 +7,5 @@ usb-common-y  += common.o
 usb-common-$(CONFIG_USB_LED_TRIG) += led.o
 
 obj-$(CONFIG_USB_ULPI_BUS) += ulpi.o
-usbotg-y   := usb-otg-fsm.o
+usbotg-y   := usb-otg.o usb-otg-fsm.o
 obj-$(CONFIG_USB_OTG)  += usbotg.o
diff --git a/drivers/usb/common/usb-otg.c b/drivers/usb/common/usb-otg.c
new file mode 100644
index 000..702bca8
--- /dev/null
+++ b/drivers/usb/common/usb-otg.c
@@ -0,0 +1,1040 @@
+/**
+ * drivers/usb/common/usb-otg.c - USB OTG core
+ *
+ * Copyright (C) 2016 Texas Instruments Incorporated - http://www.ti.com
+ * Author: Roger Quadros 
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "usb-otg.h"
+
+struct otg_gcd {
+   struct usb_gadget *gadget;
+   struct otg_gadget_ops *ops;
+};
+
+/* OTG device list */
+LIST_HEAD(otg_list);
+static DEFINE_MUTEX(otg_list_mutex);
+
+/* Hosts and Gadgets waiting for OTG controller */
+struct otg_wait_data {
+   struct device *dev; /* OTG controller device */
+
+   struct otg_hcd primary_hcd;
+   struct otg_hcd shared_hcd;
+   struct otg_gcd gcd;
+   struct list_head list;
+};
+
+LIST_HEAD(wait_list);
+static DEFINE_MUTEX(wait_list_mutex);
+
+static int usb_otg_hcd_is_primary_hcd(struct usb_hcd *hcd)
+{
+   if (!hcd->primary_hcd)
+   return 1;
+   return hcd == hcd->primary_hcd;
+}
+
+/**
+ * Check if the OTG device is in our wait list and return
+ * otg_wait_data, else NULL.
+ *
+ * wait_list_mutex must be held.
+ */
+static struct otg_wait_data *usb_otg_get_wait(struct device *otg_dev)
+{
+   struct otg_wait_data *wait;
+
+   if (!otg_dev)
+   return NULL;
+
+   /* is there an entry for this otg_dev ?*/
+   list_for_each_entry(wait, _list, list) {
+   if (wait->dev == otg_dev)
+   return wait;
+   }
+
+   return NULL;
+}
+
+/**
+ * Add the hcd to our wait list
+ */
+static int usb_otg_hcd_wait_add(struct device *otg_dev, struct usb_hcd *hcd,
+   unsigned int irqnum, unsigned long irqflags,
+   struct otg_hcd_ops *ops)
+{
+   struct otg_wait_data *wait;
+   int ret = -EINVAL;
+
+   mutex_lock(_list_mutex);
+
+   wait = usb_otg_get_wait(otg_dev);
+   if (!wait) {
+   /* Not yet in wait list? allocate and add */
+   wait = kzalloc(sizeof(*wait), GFP_KERNEL);
+   if (!wait) {
+   ret = -ENOMEM;
+   goto fail;
+   }
+
+   wait->dev = otg_dev;
+   list_add_tail(>list, _list);
+   }
+
+   if (usb_otg_hcd_is_primary_hcd(hcd)) {
+   if (wait->primary_hcd.hcd)  /* already assigned? */
+   goto fail;
+
+   wait->primary_hcd.hcd = hcd;
+   wait->primary_hcd.irqnum = irqnum;
+ 

[PATCH v7 14/14] usb: host: xhci-plat: Add otg device to platform data

2016-05-02 Thread Roger Quadros
Host controllers that are part of an OTG/dual-role instance
need to somehow pass the OTG controller device information
to the HCD core.

We use platform data to pass the OTG controller device.

Signed-off-by: Roger Quadros 
---
 drivers/usb/host/xhci-plat.c | 35 ---
 include/linux/usb/xhci_pdriver.h |  3 +++
 2 files changed, 31 insertions(+), 7 deletions(-)

diff --git a/drivers/usb/host/xhci-plat.c b/drivers/usb/host/xhci-plat.c
index 5c15e9b..84ebe18 100644
--- a/drivers/usb/host/xhci-plat.c
+++ b/drivers/usb/host/xhci-plat.c
@@ -230,11 +230,20 @@ static int xhci_plat_probe(struct platform_device *pdev)
goto put_usb3_hcd;
}
 
-   ret = usb_add_hcd(hcd, irq, IRQF_SHARED);
+   if (pdata && pdata->otg_dev)
+   ret = usb_otg_add_hcd(hcd, irq, IRQF_SHARED, pdata->otg_dev);
+   else
+   ret = usb_add_hcd(hcd, irq, IRQF_SHARED);
+
if (ret)
goto disable_usb_phy;
 
-   ret = usb_add_hcd(xhci->shared_hcd, irq, IRQF_SHARED);
+   if (pdata && pdata->otg_dev)
+   ret = usb_otg_add_hcd(xhci->shared_hcd, irq, IRQF_SHARED,
+ pdata->otg_dev);
+   else
+   ret = usb_add_hcd(xhci->shared_hcd, irq, IRQF_SHARED);
+
if (ret)
goto dealloc_usb2_hcd;
 
@@ -242,7 +251,10 @@ static int xhci_plat_probe(struct platform_device *pdev)
 
 
 dealloc_usb2_hcd:
-   usb_remove_hcd(hcd);
+   if (pdata && pdata->otg_dev)
+   usb_otg_remove_hcd(hcd);
+   else
+   usb_remove_hcd(hcd);
 
 disable_usb_phy:
usb_phy_shutdown(hcd->usb_phy);
@@ -260,16 +272,25 @@ put_hcd:
return ret;
 }
 
-static int xhci_plat_remove(struct platform_device *dev)
+static int xhci_plat_remove(struct platform_device *pdev)
 {
-   struct usb_hcd  *hcd = platform_get_drvdata(dev);
+   struct usb_hcd  *hcd = platform_get_drvdata(pdev);
struct xhci_hcd *xhci = hcd_to_xhci(hcd);
struct clk *clk = xhci->clk;
+   struct usb_xhci_pdata *pdata = dev_get_platdata(>dev);
+
+   if (pdata && pdata->otg_dev)
+   usb_otg_remove_hcd(xhci->shared_hcd);
+   else
+   usb_remove_hcd(xhci->shared_hcd);
 
-   usb_remove_hcd(xhci->shared_hcd);
usb_phy_shutdown(hcd->usb_phy);
 
-   usb_remove_hcd(hcd);
+   if (pdata && pdata->otg_dev)
+   usb_otg_remove_hcd(hcd);
+   else
+   usb_remove_hcd(hcd);
+
usb_put_hcd(xhci->shared_hcd);
 
if (!IS_ERR(clk))
diff --git a/include/linux/usb/xhci_pdriver.h b/include/linux/usb/xhci_pdriver.h
index 376654b..5c68b83 100644
--- a/include/linux/usb/xhci_pdriver.h
+++ b/include/linux/usb/xhci_pdriver.h
@@ -18,10 +18,13 @@
  *
  * @usb3_lpm_capable:  determines if this xhci platform supports USB3
  * LPM capability
+ * @otg_dev:   OTG controller device. Only requied if part of
+ * OTG/dual-role.
  *
  */
 struct usb_xhci_pdata {
unsignedusb3_lpm_capable:1;
+   struct device   *otg_dev;
 };
 
 #endif /* __USB_CORE_XHCI_PDRIVER_H */
-- 
2.7.4

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


[PATCH v7 11/14] usb: otg: use dev_dbg() instead of VDBG()

2016-05-02 Thread Roger Quadros
Now that we have a device reference in struct usb_otg
let's use dev_dbg() for debug messages.

Signed-off-by: Roger Quadros 
---
 drivers/usb/common/usb-otg-fsm.c | 19 +++
 1 file changed, 7 insertions(+), 12 deletions(-)

diff --git a/drivers/usb/common/usb-otg-fsm.c b/drivers/usb/common/usb-otg-fsm.c
index 2986b66..e6e58c2 100644
--- a/drivers/usb/common/usb-otg-fsm.c
+++ b/drivers/usb/common/usb-otg-fsm.c
@@ -30,13 +30,6 @@
 #include 
 #include 
 
-#ifdef VERBOSE
-#define VDBG(fmt, args...) pr_debug("[%s]  " fmt , \
-__func__, ## args)
-#else
-#define VDBG(stuff...) do {} while (0)
-#endif
-
 /* Change USB protocol when there is a protocol change */
 static int otg_set_protocol(struct otg_fsm *fsm, int protocol)
 {
@@ -44,8 +37,9 @@ static int otg_set_protocol(struct otg_fsm *fsm, int protocol)
int ret = 0;
 
if (fsm->protocol != protocol) {
-   VDBG("Changing role fsm->protocol= %d; new protocol= %d\n",
-   fsm->protocol, protocol);
+   dev_vdbg(otg->dev,
+"Changing role fsm->protocol= %d; new protocol= %d\n",
+fsm->protocol, protocol);
/* stop old protocol */
if (fsm->protocol == PROTO_HOST)
ret = otg_start_host(otg, 0);
@@ -226,7 +220,7 @@ static int otg_set_state(struct otg_fsm *fsm, enum 
usb_otg_state new_state)
 
if (otg->state == new_state)
return 0;
-   VDBG("Set state: %s\n", usb_otg_state_string(new_state));
+   dev_vdbg(otg->dev, "Set state: %s\n", usb_otg_state_string(new_state));
otg_leave_state(fsm, otg->state);
switch (new_state) {
case OTG_STATE_B_IDLE:
@@ -358,7 +352,7 @@ int otg_statemachine(struct usb_otg *otg)
 
switch (state) {
case OTG_STATE_UNDEFINED:
-   VDBG("fsm->id = %d\n", fsm->id);
+   dev_vdbg(otg->dev, "fsm->id = %d\n", fsm->id);
if (fsm->id)
otg_set_state(fsm, OTG_STATE_B_IDLE);
else
@@ -466,7 +460,8 @@ int otg_statemachine(struct usb_otg *otg)
}
mutex_unlock(>lock);
 
-   VDBG("quit statemachine, changed = %d\n", fsm->state_changed);
+   dev_vdbg(otg->dev, "quit statemachine, changed = %d\n",
+fsm->state_changed);
return fsm->state_changed;
 }
 EXPORT_SYMBOL_GPL(otg_statemachine);
-- 
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 v7 13/14] usb: gadget: udc: adapt to OTG core

2016-05-02 Thread Roger Quadros
The OTG state machine needs a mechanism to start and
stop the gadget controller. Add usb_gadget_start()
and usb_gadget_stop().

Introduce usb_otg_add_gadget_udc() to allow controller drivers
to register a gadget controller that is part of an OTG instance.

Register with OTG core when gadget function driver
is available and unregister when function driver is unbound.

We need to unlock the usb_lock mutex before calling
usb_otg_register_gadget() in udc_bind_to_driver() and
usb_gadget_remove_driver() else it will cause a circular
locking dependency.

Ignore softconnect sysfs control when we're in OTG
mode as OTG FSM takes care of gadget softconnect using
the b_bus_req mechanism.

Signed-off-by: Roger Quadros 
---
 drivers/usb/gadget/udc/udc-core.c | 161 +++---
 include/linux/usb/gadget.h|   4 +
 2 files changed, 156 insertions(+), 9 deletions(-)

diff --git a/drivers/usb/gadget/udc/udc-core.c 
b/drivers/usb/gadget/udc/udc-core.c
index 4151597..e384c7e 100644
--- a/drivers/usb/gadget/udc/udc-core.c
+++ b/drivers/usb/gadget/udc/udc-core.c
@@ -28,6 +28,11 @@
 #include 
 #include 
 #include 
+#include 
+#include 
+
+#include 
+#include 
 
 /**
  * struct usb_udc - describes one usb device controller
@@ -325,6 +330,87 @@ static inline void usb_gadget_udc_stop(struct usb_udc *udc)
 }
 
 /**
+ * usb_gadget_to_udc - get the UDC owning the gadget
+ *
+ * udc_lock must be held.
+ * Returs NULL if UDC is not found.
+ */
+static struct usb_udc *usb_gadget_to_udc(struct usb_gadget *gadget)
+{
+   struct usb_udc *udc;
+
+   list_for_each_entry(udc, _list, list)
+   if (udc->gadget == gadget)
+   return udc;
+
+   return NULL;
+}
+
+/**
+ * usb_gadget_start - start the usb gadget controller and connect to bus
+ * @gadget: the gadget device to start
+ *
+ * This is external API for use by OTG core.
+ *
+ * Start the usb device controller and connect to bus (enable pull).
+ */
+static int usb_gadget_start(struct usb_gadget *gadget)
+{
+   int ret;
+   struct usb_udc *udc;
+
+   mutex_lock(_lock);
+   udc = usb_gadget_to_udc(gadget);
+   if (!udc) {
+   dev_err(gadget->dev.parent, "%s: gadget not registered.\n",
+   __func__);
+   mutex_unlock(_lock);
+   return -EINVAL;
+   }
+
+   ret = usb_gadget_udc_start(udc);
+   if (ret)
+   dev_err(>dev, "USB Device Controller didn't start: %d\n",
+   ret);
+   else
+   usb_udc_connect_control(udc);
+
+   mutex_unlock(_lock);
+
+   return ret;
+}
+
+/**
+ * usb_gadget_stop - disconnect from bus and stop the usb gadget
+ * @gadget: The gadget device we want to stop
+ *
+ * This is external API for use by OTG core.
+ *
+ * Disconnect from the bus (disable pull) and stop the
+ * gadget controller.
+ */
+static int usb_gadget_stop(struct usb_gadget *gadget)
+{
+   struct usb_udc *udc;
+
+   mutex_lock(_lock);
+   udc = usb_gadget_to_udc(gadget);
+   if (!udc) {
+   dev_err(gadget->dev.parent, "%s: gadget not registered.\n",
+   __func__);
+   mutex_unlock(_lock);
+   return -EINVAL;
+   }
+
+   usb_gadget_disconnect(udc->gadget);
+   udc->driver->disconnect(udc->gadget);
+   usb_gadget_udc_stop(udc);
+   mutex_unlock(_lock);
+
+   return 0;
+}
+
+/**
  * usb_udc_release - release the usb_udc struct
  * @dev: the dev member within usb_udc
  *
@@ -486,6 +572,33 @@ int usb_add_gadget_udc(struct device *parent, struct 
usb_gadget *gadget)
 }
 EXPORT_SYMBOL_GPL(usb_add_gadget_udc);
 
+/**
+ * usb_otg_add_gadget_udc - adds a new gadget to the udc class driver list
+ * @parent: the parent device to this udc. Usually the controller
+ * driver's device.
+ * @gadget: the gadget to be added to the list
+ * @otg_dev: the OTG controller device
+ *
+ * If otg_dev is NULL then device tree node is checked
+ * for OTG controller via the otg-controller property.
+ * Returns zero on success, negative errno otherwise.
+ */
+int usb_otg_add_gadget_udc(struct device *parent, struct usb_gadget *gadget,
+  struct device *otg_dev)
+{
+   if (!otg_dev) {
+   gadget->otg_dev = of_usb_get_otg(parent->of_node);
+   if (!gadget->otg_dev)
+   return -ENODEV;
+   } else {
+   gadget->otg_dev = otg_dev;
+   }
+
+   return usb_add_gadget_udc_release(parent, gadget, NULL);
+}
+EXPORT_SYMBOL_GPL(usb_otg_add_gadget_udc);
+
+/* udc_lock must be held */
 static void usb_gadget_remove_driver(struct usb_udc *udc)
 {
dev_dbg(>dev, "unregistering UDC driver [%s]\n",
@@ -493,10 +606,18 @@ static void usb_gadget_remove_driver(struct usb_udc *udc)
 
kobject_uevent(>dev.kobj, KOBJ_CHANGE);
 
-   usb_gadget_disconnect(udc->gadget);
-   udc->driver->disconnect(udc->gadget);
+   /* 

[PATCH v7 04/14] usb: otg-fsm: use usb_otg wherever possible

2016-05-02 Thread Roger Quadros
Move otg_fsm into usb_otg and use usb_otg wherever possible
in the usb_otg APIs.

Signed-off-by: Roger Quadros 
Acked-by: Peter Chen 
---
 drivers/usb/chipidea/ci.h|   1 -
 drivers/usb/chipidea/core.c  |  14 +--
 drivers/usb/chipidea/debug.c |   2 +-
 drivers/usb/chipidea/otg_fsm.c   | 169 ++--
 drivers/usb/chipidea/udc.c   |  17 ++--
 drivers/usb/common/usb-otg-fsm.c | 180 ---
 drivers/usb/phy/phy-fsl-usb.c| 141 +++---
 drivers/usb/phy/phy-fsl-usb.h|   3 +-
 include/linux/usb/otg-fsm.h  | 132 +++-
 include/linux/usb/otg.h  | 107 +++
 10 files changed, 383 insertions(+), 383 deletions(-)

diff --git a/drivers/usb/chipidea/ci.h b/drivers/usb/chipidea/ci.h
index cd41455..c523975 100644
--- a/drivers/usb/chipidea/ci.h
+++ b/drivers/usb/chipidea/ci.h
@@ -209,7 +209,6 @@ struct ci_hdrc {
enum ci_rolerole;
boolis_otg;
struct usb_otg  otg;
-   struct otg_fsm  fsm;
struct hrtimer  otg_fsm_hrtimer;
ktime_t hr_timeouts[NUM_OTG_FSM_TIMERS];
unsignedenabled_otg_timer_bits;
diff --git a/drivers/usb/chipidea/core.c b/drivers/usb/chipidea/core.c
index 69426e6..56b6ac6 100644
--- a/drivers/usb/chipidea/core.c
+++ b/drivers/usb/chipidea/core.c
@@ -1085,8 +1085,8 @@ static int ci_hdrc_remove(struct platform_device *pdev)
 /* Prepare wakeup by SRP before suspend */
 static void ci_otg_fsm_suspend_for_srp(struct ci_hdrc *ci)
 {
-   if ((ci->fsm.otg->state == OTG_STATE_A_IDLE) &&
-   !hw_read_otgsc(ci, OTGSC_ID)) {
+   if ((ci->otg.state == OTG_STATE_A_IDLE) &&
+   !hw_read_otgsc(ci, OTGSC_ID)) {
hw_write(ci, OP_PORTSC, PORTSC_W1C_BITS | PORTSC_PP,
PORTSC_PP);
hw_write(ci, OP_PORTSC, PORTSC_W1C_BITS | PORTSC_WKCN,
@@ -1097,13 +1097,13 @@ static void ci_otg_fsm_suspend_for_srp(struct ci_hdrc 
*ci)
 /* Handle SRP when wakeup by data pulse */
 static void ci_otg_fsm_wakeup_by_srp(struct ci_hdrc *ci)
 {
-   if ((ci->fsm.otg->state == OTG_STATE_A_IDLE) &&
-   (ci->fsm.a_bus_drop == 1) && (ci->fsm.a_bus_req == 0)) {
+   if ((ci->otg.state == OTG_STATE_A_IDLE) &&
+   (ci->otg.fsm.a_bus_drop == 1) && (ci->otg.fsm.a_bus_req == 0)) {
if (!hw_read_otgsc(ci, OTGSC_ID)) {
-   ci->fsm.a_srp_det = 1;
-   ci->fsm.a_bus_drop = 0;
+   ci->otg.fsm.a_srp_det = 1;
+   ci->otg.fsm.a_bus_drop = 0;
} else {
-   ci->fsm.id = 1;
+   ci->otg.fsm.id = 1;
}
ci_otg_queue_work(ci);
}
diff --git a/drivers/usb/chipidea/debug.c b/drivers/usb/chipidea/debug.c
index 6d23eed..374cdaa 100644
--- a/drivers/usb/chipidea/debug.c
+++ b/drivers/usb/chipidea/debug.c
@@ -224,7 +224,7 @@ static int ci_otg_show(struct seq_file *s, void *unused)
if (!ci || !ci_otg_is_fsm_mode(ci))
return 0;
 
-   fsm = >fsm;
+   fsm = >otg.fsm;
 
/* -- State - */
seq_printf(s, "OTG state: %s\n\n",
diff --git a/drivers/usb/chipidea/otg_fsm.c b/drivers/usb/chipidea/otg_fsm.c
index de8e22e..1c0c750 100644
--- a/drivers/usb/chipidea/otg_fsm.c
+++ b/drivers/usb/chipidea/otg_fsm.c
@@ -40,7 +40,7 @@ get_a_bus_req(struct device *dev, struct device_attribute 
*attr, char *buf)
 
next = buf;
size = PAGE_SIZE;
-   t = scnprintf(next, size, "%d\n", ci->fsm.a_bus_req);
+   t = scnprintf(next, size, "%d\n", ci->otg.fsm.a_bus_req);
size -= t;
next += t;
 
@@ -56,25 +56,25 @@ set_a_bus_req(struct device *dev, struct device_attribute 
*attr,
if (count > 2)
return -1;
 
-   mutex_lock(>fsm.lock);
+   mutex_lock(>otg.fsm.lock);
if (buf[0] == '0') {
-   ci->fsm.a_bus_req = 0;
+   ci->otg.fsm.a_bus_req = 0;
} else if (buf[0] == '1') {
/* If a_bus_drop is TRUE, a_bus_req can't be set */
-   if (ci->fsm.a_bus_drop) {
-   mutex_unlock(>fsm.lock);
+   if (ci->otg.fsm.a_bus_drop) {
+   mutex_unlock(>otg.fsm.lock);
return count;
}
-   ci->fsm.a_bus_req = 1;
-   if (ci->fsm.otg->state == OTG_STATE_A_PERIPHERAL) {
+   ci->otg.fsm.a_bus_req = 1;
+   if (ci->otg.state == OTG_STATE_A_PERIPHERAL) {
ci->gadget.host_request_flag = 1;
-   mutex_unlock(>fsm.lock);
+   

[PATCH v7 02/14] usb: otg-fsm: Prevent build warning "VDBG" redefined

2016-05-02 Thread Roger Quadros
If usb/otg-fsm.h and usb/composite.h are included together
then it results in the build warning [1].

Prevent that by defining VDBG locally.

Also get rid of MPC_LOC which doesn't seem to be used
by anyone.

[1] - warning fixed by this patch:

In file included from drivers/usb/dwc3/core.h:33,
   from drivers/usb/dwc3/ep0.c:33:
   include/linux/usb/otg-fsm.h:30:1: warning: "VDBG" redefined
   In file included from drivers/usb/dwc3/ep0.c:31:
   include/linux/usb/composite.h:615:1: warning: this is the location
   of the previous definition

Signed-off-by: Roger Quadros 
---
 drivers/usb/common/usb-otg-fsm.c |  7 +++
 drivers/usb/phy/phy-fsl-usb.c|  7 +++
 include/linux/usb/otg-fsm.h  | 15 ---
 3 files changed, 14 insertions(+), 15 deletions(-)

diff --git a/drivers/usb/common/usb-otg-fsm.c b/drivers/usb/common/usb-otg-fsm.c
index 9059b7d..015cf41 100644
--- a/drivers/usb/common/usb-otg-fsm.c
+++ b/drivers/usb/common/usb-otg-fsm.c
@@ -30,6 +30,13 @@
 #include 
 #include 
 
+#ifdef VERBOSE
+#define VDBG(fmt, args...) pr_debug("[%s]  " fmt , \
+__func__, ## args)
+#else
+#define VDBG(stuff...) do {} while (0)
+#endif
+
 /* Change USB protocol when there is a protocol change */
 static int otg_set_protocol(struct otg_fsm *fsm, int protocol)
 {
diff --git a/drivers/usb/phy/phy-fsl-usb.c b/drivers/usb/phy/phy-fsl-usb.c
index 94eb292..dd8a1ad 100644
--- a/drivers/usb/phy/phy-fsl-usb.c
+++ b/drivers/usb/phy/phy-fsl-usb.c
@@ -44,6 +44,13 @@
 
 #include "phy-fsl-usb.h"
 
+#ifdef VERBOSE
+#define VDBG(fmt, args...) pr_debug("[%s]  " fmt , \
+__func__, ## args)
+#else
+#define VDBG(stuff...) do {} while (0)
+#endif
+
 #define DRIVER_VERSION "Rev. 1.55"
 #define DRIVER_AUTHOR "Jerry Huang/Li Yang"
 #define DRIVER_DESC "Freescale USB OTG Transceiver Driver"
diff --git a/include/linux/usb/otg-fsm.h b/include/linux/usb/otg-fsm.h
index 7a03505..a0a8f87 100644
--- a/include/linux/usb/otg-fsm.h
+++ b/include/linux/usb/otg-fsm.h
@@ -21,21 +21,6 @@
 #include 
 #include 
 
-#undef VERBOSE
-
-#ifdef VERBOSE
-#define VDBG(fmt, args...) pr_debug("[%s]  " fmt , \
-__func__, ## args)
-#else
-#define VDBG(stuff...) do {} while (0)
-#endif
-
-#ifdef VERBOSE
-#define MPC_LOC printk("Current Location [%s]:[%d]\n", __FILE__, __LINE__)
-#else
-#define MPC_LOC do {} while (0)
-#endif
-
 #define PROTO_UNDEF(0)
 #define PROTO_HOST (1)
 #define PROTO_GADGET   (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 v7 06/14] usb: gadget.h: Add OTG to gadget interface

2016-05-02 Thread Roger Quadros
The OTG core will use struct otg_gadget_ops to
start/stop the gadget controller.

The main purpose of this interface is to avoid directly
calling usb_gadget_start/stop() from the OTG core as they
wouldn't be defined in the built-in symbol table if
CONFIG_USB_GADGET is m.

Signed-off-by: Roger Quadros 
Reviewed-by: Peter Chen 
---
 include/linux/usb/gadget.h | 14 ++
 1 file changed, 14 insertions(+)

diff --git a/include/linux/usb/gadget.h b/include/linux/usb/gadget.h
index 5d4e151..8c0ae64 100644
--- a/include/linux/usb/gadget.h
+++ b/include/linux/usb/gadget.h
@@ -1100,6 +1100,20 @@ struct usb_gadget_driver {
 };
 
 
+/*-*/
+
+/**
+ * struct otg_gadget_ops - Interface between OTG core and gadget
+ *
+ * Provided by the gadget core to allow the OTG core to start/stop the gadget
+ *
+ * @start: function to start the gadget
+ * @stop: function to stop the gadget
+ */
+struct otg_gadget_ops {
+   int (*start)(struct usb_gadget *gadget);
+   int (*stop)(struct usb_gadget *gadget);
+};
 
 /*-*/
 
-- 
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 v7 05/14] usb: otg-fsm: move host controller operations into usb_otg->hcd_ops

2016-05-02 Thread Roger Quadros
This is to prevent missing symbol build error if OTG is
enabled (built-in) and HCD core (CONFIG_USB) is module.

Signed-off-by: Roger Quadros 
Acked-by: Peter Chen 
---
 drivers/usb/chipidea/otg_fsm.c   |  7 +++
 drivers/usb/common/usb-otg-fsm.c | 15 +++
 drivers/usb/phy/phy-fsl-usb.c|  7 +++
 include/linux/usb/otg.h  |  2 ++
 4 files changed, 27 insertions(+), 4 deletions(-)

diff --git a/drivers/usb/chipidea/otg_fsm.c b/drivers/usb/chipidea/otg_fsm.c
index 1c0c750..2d8d659 100644
--- a/drivers/usb/chipidea/otg_fsm.c
+++ b/drivers/usb/chipidea/otg_fsm.c
@@ -582,6 +582,12 @@ static struct otg_fsm_ops ci_otg_ops = {
.start_gadget = ci_otg_start_gadget,
 };
 
+static struct otg_hcd_ops ci_hcd_ops = {
+   .usb_bus_start_enum = usb_bus_start_enum,
+   .usb_control_msg = usb_control_msg,
+   .usb_hub_find_child = usb_hub_find_child,
+};
+
 int ci_otg_fsm_work(struct ci_hdrc *ci)
 {
/*
@@ -804,6 +810,7 @@ int ci_hdrc_otg_fsm_init(struct ci_hdrc *ci)
ci->otg.fsm.id = hw_read_otgsc(ci, OTGSC_ID) ? 1 : 0;
ci->otg.state = OTG_STATE_UNDEFINED;
ci->otg.fsm.ops = _otg_ops;
+   ci->otg.hcd_ops = _hcd_ops;
ci->gadget.hnp_polling_support = 1;
ci->otg.fsm.host_req_flag = devm_kzalloc(ci->dev, 1, GFP_KERNEL);
if (!ci->otg.fsm.host_req_flag)
diff --git a/drivers/usb/common/usb-otg-fsm.c b/drivers/usb/common/usb-otg-fsm.c
index 4bfc6a5..2986b66 100644
--- a/drivers/usb/common/usb-otg-fsm.c
+++ b/drivers/usb/common/usb-otg-fsm.c
@@ -141,11 +141,16 @@ static void otg_hnp_polling_work(struct work_struct *work)
enum usb_otg_state state = otg->state;
u8 flag;
int retval;
+   struct otg_hcd_ops *hcd_ops = otg->hcd_ops;
 
if (state != OTG_STATE_A_HOST && state != OTG_STATE_B_HOST)
return;
 
-   udev = usb_hub_find_child(otg->host->root_hub, 1);
+   if (!hcd_ops || !hcd_ops->usb_control_msg ||
+   !hcd_ops->usb_hub_find_child)
+   return;
+
+   udev = hcd_ops->usb_hub_find_child(otg->host->root_hub, 1);
if (!udev) {
dev_err(otg->host->controller,
"no usb dev connected, can't start HNP polling\n");
@@ -154,7 +159,7 @@ static void otg_hnp_polling_work(struct work_struct *work)
 
*fsm->host_req_flag = 0;
/* Get host request flag from connected USB device */
-   retval = usb_control_msg(udev,
+   retval = hcd_ops->usb_control_msg(udev,
usb_rcvctrlpipe(udev, 0),
USB_REQ_GET_STATUS,
USB_DIR_IN | USB_RECIP_DEVICE,
@@ -183,7 +188,7 @@ static void otg_hnp_polling_work(struct work_struct *work)
if (state == OTG_STATE_A_HOST) {
/* Set b_hnp_enable */
if (!otg->host->b_hnp_enable) {
-   retval = usb_control_msg(udev,
+   retval = hcd_ops->usb_control_msg(udev,
usb_sndctrlpipe(udev, 0),
USB_REQ_SET_FEATURE, 0,
USB_DEVICE_B_HNP_ENABLE,
@@ -262,7 +267,9 @@ static int otg_set_state(struct otg_fsm *fsm, enum 
usb_otg_state new_state)
otg_loc_conn(otg, 0);
otg_loc_sof(otg, 1);
otg_set_protocol(fsm, PROTO_HOST);
-   usb_bus_start_enum(otg->host, otg->host->otg_port);
+   if (otg->hcd_ops && otg->hcd_ops->usb_bus_start_enum)
+   otg->hcd_ops->usb_bus_start_enum(otg->host,
+otg->host->otg_port);
otg_start_hnp_polling(fsm);
break;
case OTG_STATE_A_IDLE:
diff --git a/drivers/usb/phy/phy-fsl-usb.c b/drivers/usb/phy/phy-fsl-usb.c
index 587a187..9dbd9f0 100644
--- a/drivers/usb/phy/phy-fsl-usb.c
+++ b/drivers/usb/phy/phy-fsl-usb.c
@@ -792,6 +792,12 @@ static struct otg_fsm_ops fsl_otg_ops = {
.start_gadget = fsl_otg_start_gadget,
 };
 
+static struct otg_hcd_ops fsl_hcd_ops = {
+   .usb_bus_start_enum = usb_bus_start_enum,
+   .usb_control_msg = usb_control_msg,
+   .usb_hub_find_child = usb_hub_find_child,
+};
+
 /* Initialize the global variable fsl_otg_dev and request IRQ for OTG */
 static int fsl_otg_conf(struct platform_device *pdev)
 {
@@ -820,6 +826,7 @@ static int fsl_otg_conf(struct platform_device *pdev)
 
/* Set OTG state machine operations */
fsl_otg_tc->otg.fsm.ops = _otg_ops;
+   fsl_otg_tc->otg.hcd_ops = _hcd_ops;
 
/* initialize the otg structure */
fsl_otg_tc->phy.label = DRIVER_DESC;
diff --git a/include/linux/usb/otg.h b/include/linux/usb/otg.h
index e8a14dc..85b8fb5 100644
--- a/include/linux/usb/otg.h
+++ b/include/linux/usb/otg.h
@@ -12,6 +12,7 @@
 #include 
 #include 
 #include 
+#include 
 
 struct usb_otg 

[PATCH] sisusbvga: correct speed testing

2016-05-02 Thread Oliver Neukum
Allow for SS+

Signed-off-by: Oliver Neukum 
---
 drivers/usb/misc/sisusbvga/sisusb.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/usb/misc/sisusbvga/sisusb.c 
b/drivers/usb/misc/sisusbvga/sisusb.c
index a22de52..15666ad 100644
--- a/drivers/usb/misc/sisusbvga/sisusb.c
+++ b/drivers/usb/misc/sisusbvga/sisusb.c
@@ -2420,7 +2420,7 @@ static int sisusb_open(struct inode *inode, struct file 
*file)
 
if (!sisusb->devinit) {
if (sisusb->sisusb_dev->speed == USB_SPEED_HIGH ||
-   sisusb->sisusb_dev->speed == USB_SPEED_SUPER) {
+   sisusb->sisusb_dev->speed >= USB_SPEED_SUPER) {
if (sisusb_init_gfxdevice(sisusb, 0)) {
mutex_unlock(>lock);
dev_err(>sisusb_dev->dev,
@@ -3127,7 +3127,7 @@ static int sisusb_probe(struct usb_interface *intf,
 
sisusb->present = 1;
 
-   if (dev->speed == USB_SPEED_HIGH || dev->speed == USB_SPEED_SUPER) {
+   if (dev->speed == USB_SPEED_HIGH || dev->speed >= USB_SPEED_SUPER) {
int initscreen = 1;
 #ifdef INCL_SISUSB_CON
if (sisusb_first_vc > 0 && sisusb_last_vc > 0 &&
-- 
2.1.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] sisusbvga: correct speed testing

2016-05-02 Thread Oliver Neukum
Allow for SS+

Signed-off-by: Oliver Neukum 
---
 drivers/usb/misc/sisusbvga/sisusb.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/usb/misc/sisusbvga/sisusb.c 
b/drivers/usb/misc/sisusbvga/sisusb.c
index a22de52..15666ad 100644
--- a/drivers/usb/misc/sisusbvga/sisusb.c
+++ b/drivers/usb/misc/sisusbvga/sisusb.c
@@ -2420,7 +2420,7 @@ static int sisusb_open(struct inode *inode, struct file 
*file)
 
if (!sisusb->devinit) {
if (sisusb->sisusb_dev->speed == USB_SPEED_HIGH ||
-   sisusb->sisusb_dev->speed == USB_SPEED_SUPER) {
+   sisusb->sisusb_dev->speed >= USB_SPEED_SUPER) {
if (sisusb_init_gfxdevice(sisusb, 0)) {
mutex_unlock(>lock);
dev_err(>sisusb_dev->dev,
@@ -3127,7 +3127,7 @@ static int sisusb_probe(struct usb_interface *intf,
 
sisusb->present = 1;
 
-   if (dev->speed == USB_SPEED_HIGH || dev->speed == USB_SPEED_SUPER) {
+   if (dev->speed == USB_SPEED_HIGH || dev->speed >= USB_SPEED_SUPER) {
int initscreen = 1;
 #ifdef INCL_SISUSB_CON
if (sisusb_first_vc > 0 && sisusb_last_vc > 0 &&
-- 
2.1.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 1/3] brcm80211: correct speed testing

2016-05-02 Thread Oliver Neukum
Allow for SS+ USB

Signed-off-by: Oliver Neukum 
---
 drivers/net/wireless/broadcom/brcm80211/brcmfmac/usb.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/usb.c 
b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/usb.c
index 869eb82..056bda3 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/usb.c
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/usb.c
@@ -1368,7 +1368,9 @@ brcmf_usb_probe(struct usb_interface *intf, const struct 
usb_device_id *id)
 
devinfo->ifnum = desc->bInterfaceNumber;
 
-   if (usb->speed == USB_SPEED_SUPER)
+   if (usb->speed == USB_SPEED_SUPER_PLUS)
+   brcmf_dbg(USB, "Broadcom super speed plus USB WLAN interface 
detected\n");
+   else if (usb->speed == USB_SPEED_SUPER)
brcmf_dbg(USB, "Broadcom super speed USB WLAN interface 
detected\n");
else if (usb->speed == USB_SPEED_HIGH)
brcmf_dbg(USB, "Broadcom high speed USB WLAN interface 
detected\n");
-- 
2.1.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 3/3] rtl8152: correct speed testing

2016-05-02 Thread Oliver Neukum
Allow for SS+ USB

Signed-off-by: Oliver Neukum 
---
 drivers/net/usb/r8152.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/net/usb/r8152.c b/drivers/net/usb/r8152.c
index d1f78c2..3f9f6ed 100644
--- a/drivers/net/usb/r8152.c
+++ b/drivers/net/usb/r8152.c
@@ -3366,7 +3366,7 @@ static void r8153_init(struct r8152 *tp)
ocp_write_word(tp, MCU_TYPE_PLA, PLA_LED_FEATURE, ocp_data);
 
ocp_data = FIFO_EMPTY_1FB | ROK_EXIT_LPM;
-   if (tp->version == RTL_VER_04 && tp->udev->speed != USB_SPEED_SUPER)
+   if (tp->version == RTL_VER_04 && tp->udev->speed < USB_SPEED_SUPER)
ocp_data |= LPM_TIMER_500MS;
else
ocp_data |= LPM_TIMER_500US;
@@ -4211,6 +4211,7 @@ static int rtl8152_probe(struct usb_interface *intf,
 
switch (udev->speed) {
case USB_SPEED_SUPER:
+   case USB_SPEED_SUPER_PLUS:
tp->coalesce = COALESCE_SUPER;
break;
case USB_SPEED_HIGH:
-- 
2.1.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 2/3] usbnet: correct speed testing

2016-05-02 Thread Oliver Neukum
Allow for SS+ USB

Signed-off-by: Oliver Neukum 
---
 drivers/net/usb/usbnet.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/net/usb/usbnet.c b/drivers/net/usb/usbnet.c
index 4f08426..bc46ef9 100644
--- a/drivers/net/usb/usbnet.c
+++ b/drivers/net/usb/usbnet.c
@@ -355,6 +355,7 @@ void usbnet_update_max_qlen(struct usbnet *dev)
dev->tx_qlen = MAX_QUEUE_MEMORY / dev->hard_mtu;
break;
case USB_SPEED_SUPER:
+   case USB_SPEED_SUPER_PLUS:
/*
 * Not take default 5ms qlen for super speed HC to
 * save memory, and iperf tests show 2.5ms qlen can
-- 
2.1.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: [PATCH v7 1/7] regulator: fixed: add support for ACPI interface

2016-05-02 Thread Mark Brown
On Fri, Apr 29, 2016 at 02:26:32PM +0800, Lu Baolu wrote:

> + gpiod = gpiod_get(dev, "vbus_en", GPIOD_ASIS);
> + if (IS_ERR(gpiod))
> + return PTR_ERR(gpiod);

This is clearly an inappropriate name for the signal in generic code,
it's specific to your use case.


signature.asc
Description: PGP signature


Re: [RFT PATCH 1/3] usb: misc: usb3503: Fix HUB mode after bootloader initialization

2016-05-02 Thread Mark Brown
On Mon, May 02, 2016 at 11:49:12AM +0200, Krzysztof Kozlowski wrote:

> This VDD regulator supply actually is not a usb3503 USB HUB regulator
> supply... but a supply to the LAN attached to this HUB. Regulator off/on
> is needed for LAN to show up. The hub will show up with typical reset
> (which is also missing before my patchset btw).

> The LAN, as a USB device, is auto-probed so it cannot take the regulator
> and play with it. The simplest idea I have is to add it as "external
> supply"  to the parent: usb3503.

This is common enough that that just isn't going to scale well I fear
without some generic handling, either walking child devices at the bus
level or at the device level with a pre-probe() callback to get the
device to power on.  The latter is more appropriate to things like
Slimbus where the device is more likely to do active management at
runtime, it's not clear people are building USB devices like that.


signature.asc
Description: PGP signature


Re: [RFT PATCH 1/3] usb: misc: usb3503: Fix HUB mode after bootloader initialization

2016-05-02 Thread Krzysztof Kozlowski
On 05/02/2016 11:49 AM, Krzysztof Kozlowski wrote:
> On 04/29/2016 06:44 PM, Mark Brown wrote:
>> On Fri, Apr 29, 2016 at 01:55:14PM +0200, Krzysztof Kozlowski wrote:
>>> On 04/29/2016 01:30 PM, Mark Brown wrote:
>>
 Supplies are only optional if they may be physically absent.  In this
 case it's possible that on device regulators may be used instead, a
 pattern more like that used for arizona-ldo1 where we represent those
 regulators might be better as it's more clearly describing the
 situation.  I'm just wondering if the supply lookup stuff there should
 be factored out as this is not an uncommon pattern..
>>
 It should at least be clearly stated what's going on, ignoring failure
 to get supplies is generally a bug and people will tend to blindly cut
 and paste things (witness all the breakage in graphics drivers with
 this).
>>
>>> The VDD33 is really optional. The device can work in different
>>> configuration, e.g. only on VBAT. How the reset logic would work then? I
>>> don't know... I would suspect that it could be exactly the same (just
>>> replace VDD33 with VBAT) but I am not sure.
>>
>> What the Arizona example I mentioned does is look for the property
>> specifying an external supply in DT and if there isn't one assumes that
>> it must be using the internal regulator.  That's a bit icky but it does
>> the right thing and is much simpler from a user point of view.
> 
> Okay, that indeed looks similar... in case of lack of external supplies
> the usb3503 pins should be tied to the internal regulators.
> 
> However it seems I was wrong at the beginning. We've been looking here
> at the schematics and the datasheet. The design is unfortunately a
> little bit confusing but finally I think we got the impression how does
> it work.
> 
> This VDD regulator supply actually is not a usb3503 USB HUB regulator
> supply... but a supply to the LAN attached to this HUB. Regulator off/on
> is needed for LAN to show up. The hub will show up with typical reset
> (which is also missing before my patchset btw).
> 
> The LAN, as a USB device, is auto-probed so it cannot take the regulator
> and play with it. The simplest idea I have is to add it as "external
> supply"  to the parent: usb3503.

I run some more tests which adds more confusion. If the usb3503 hub does
not turn off/on the supply (LAN regulator supply in reality) it usually
does not show up as USB device (lsusb) neither. In such case sometimes
it is present, sometimes not.

"Hardware" reset with regulator fixes all the problems: with LAN and
with USB hub... It really does not match the schematics but apparently
usb3503 also needs the regulator.

Best regards,
Krzysztof


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


[PATCH] sisusbvga: correct speed testing

2016-05-02 Thread Oliver Neukum
Allow for SS+

Signed-off-by: Oliver Neukum 
---
 drivers/usb/misc/sisusbvga/sisusb.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/usb/misc/sisusbvga/sisusb.c 
b/drivers/usb/misc/sisusbvga/sisusb.c
index a22de52..15666ad 100644
--- a/drivers/usb/misc/sisusbvga/sisusb.c
+++ b/drivers/usb/misc/sisusbvga/sisusb.c
@@ -2420,7 +2420,7 @@ static int sisusb_open(struct inode *inode, struct file 
*file)
 
if (!sisusb->devinit) {
if (sisusb->sisusb_dev->speed == USB_SPEED_HIGH ||
-   sisusb->sisusb_dev->speed == USB_SPEED_SUPER) {
+   sisusb->sisusb_dev->speed >= USB_SPEED_SUPER) {
if (sisusb_init_gfxdevice(sisusb, 0)) {
mutex_unlock(>lock);
dev_err(>sisusb_dev->dev,
@@ -3127,7 +3127,7 @@ static int sisusb_probe(struct usb_interface *intf,
 
sisusb->present = 1;
 
-   if (dev->speed == USB_SPEED_HIGH || dev->speed == USB_SPEED_SUPER) {
+   if (dev->speed == USB_SPEED_HIGH || dev->speed >= USB_SPEED_SUPER) {
int initscreen = 1;
 #ifdef INCL_SISUSB_CON
if (sisusb_first_vc > 0 && sisusb_last_vc > 0 &&
-- 
2.1.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: [PATCH] usb: misc: usbtest: fix pattern tests for scatterlists.

2016-05-02 Thread Felipe Balbi

Hi,

Mathias Nyman  writes:
> The current implemenentation restart the sent pattern for each entry in
   ^^^
   restarts

> the sg list. The receiving end expects a continuous pattern, and test
> will fail unless scatterilst entries happen to be aligned with the
> pattern
 ^
 . (missing a period)

> Fix this by calculating the pattern byte based on total sent size
> instead of just the current sg entry.
>
> Signed-off-by: Mathias Nyman 

thanks for finding and fixing this really, really old bug. It seems like
we should add:

Fixes: 8b5249019352 ("[PATCH] USB: usbtest: scatterlist OUT data pattern 
testing")
Cc:  # v2.6.18+

Acked-by: Felipe Balbi 

-- 
balbi


signature.asc
Description: PGP signature


[PATCH] sisusbvga: correct speed testing

2016-05-02 Thread Oliver Neukum
Allow for SS+

Signed-off-by: Oliver Neukum 
---
 drivers/usb/misc/sisusbvga/sisusb.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/usb/misc/sisusbvga/sisusb.c 
b/drivers/usb/misc/sisusbvga/sisusb.c
index a22de52..15666ad 100644
--- a/drivers/usb/misc/sisusbvga/sisusb.c
+++ b/drivers/usb/misc/sisusbvga/sisusb.c
@@ -2420,7 +2420,7 @@ static int sisusb_open(struct inode *inode, struct file 
*file)
 
if (!sisusb->devinit) {
if (sisusb->sisusb_dev->speed == USB_SPEED_HIGH ||
-   sisusb->sisusb_dev->speed == USB_SPEED_SUPER) {
+   sisusb->sisusb_dev->speed >= USB_SPEED_SUPER) {
if (sisusb_init_gfxdevice(sisusb, 0)) {
mutex_unlock(>lock);
dev_err(>sisusb_dev->dev,
@@ -3127,7 +3127,7 @@ static int sisusb_probe(struct usb_interface *intf,
 
sisusb->present = 1;
 
-   if (dev->speed == USB_SPEED_HIGH || dev->speed == USB_SPEED_SUPER) {
+   if (dev->speed == USB_SPEED_HIGH || dev->speed >= USB_SPEED_SUPER) {
int initscreen = 1;
 #ifdef INCL_SISUSB_CON
if (sisusb_first_vc > 0 && sisusb_last_vc > 0 &&
-- 
2.1.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: [RFT PATCH 1/3] usb: misc: usb3503: Fix HUB mode after bootloader initialization

2016-05-02 Thread Krzysztof Kozlowski
On 04/29/2016 06:44 PM, Mark Brown wrote:
> On Fri, Apr 29, 2016 at 01:55:14PM +0200, Krzysztof Kozlowski wrote:
>> On 04/29/2016 01:30 PM, Mark Brown wrote:
> 
>>> Supplies are only optional if they may be physically absent.  In this
>>> case it's possible that on device regulators may be used instead, a
>>> pattern more like that used for arizona-ldo1 where we represent those
>>> regulators might be better as it's more clearly describing the
>>> situation.  I'm just wondering if the supply lookup stuff there should
>>> be factored out as this is not an uncommon pattern..
> 
>>> It should at least be clearly stated what's going on, ignoring failure
>>> to get supplies is generally a bug and people will tend to blindly cut
>>> and paste things (witness all the breakage in graphics drivers with
>>> this).
> 
>> The VDD33 is really optional. The device can work in different
>> configuration, e.g. only on VBAT. How the reset logic would work then? I
>> don't know... I would suspect that it could be exactly the same (just
>> replace VDD33 with VBAT) but I am not sure.
> 
> What the Arizona example I mentioned does is look for the property
> specifying an external supply in DT and if there isn't one assumes that
> it must be using the internal regulator.  That's a bit icky but it does
> the right thing and is much simpler from a user point of view.

Okay, that indeed looks similar... in case of lack of external supplies
the usb3503 pins should be tied to the internal regulators.

However it seems I was wrong at the beginning. We've been looking here
at the schematics and the datasheet. The design is unfortunately a
little bit confusing but finally I think we got the impression how does
it work.

This VDD regulator supply actually is not a usb3503 USB HUB regulator
supply... but a supply to the LAN attached to this HUB. Regulator off/on
is needed for LAN to show up. The hub will show up with typical reset
(which is also missing before my patchset btw).

The LAN, as a USB device, is auto-probed so it cannot take the regulator
and play with it. The simplest idea I have is to add it as "external
supply"  to the parent: usb3503.

Best regards,
Krzysztof

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


Re: [PATCH v5] kconfig/symbol.c: handle choice_values that depend on 'm' symbols

2016-05-02 Thread Roger Quadros
On 29/04/16 11:24, Dirk Gouders wrote:
> If choices consist of choice_values of type tristate that depend on
> symbols set to 'm', those choice_values are not set to 'n' if the
> choice is changed from 'm' to 'y' (in which case only one active
> choice_value is allowed). Those values are also written to the config
> file causing modules to be built when they should not.
> 
> The following config can be used to reproduce and examine the problem;
> with the frontend of your choice set "Choice 0" and "Choice 1" to 'm',
> then set "Tristate Choice" to 'y' and save the configuration:
> 
> config modules
>   boolean modules
>   default y
>   option modules
> 
> config dependency
>   tristate "Dependency"
>   default m
> 
> choice
>   prompt "Tristate Choice"
>   default choice0
> 
> config choice0
>   tristate "Choice 0"
> 
> config choice1
>   tristate "Choice 1"
>   depends on dependency
> 
> endchoice
> 
> This patch sets tristate choice_values' visibility that depend on
> symbols set to 'm' to 'n' if the corresponding choice is set to 'y'.
> 
> This makes them disappear from the choice list and will also cause the
> choice_values' value set to 'n' in sym_calc_value() and as a result
> they are written as "not set" to the resulting .config file.
> 
> Reported-by: Sebastian Andrzej Siewior 
> Signed-off-by: Dirk Gouders 
> Tested-by: Sebastian Andrzej Siewior 
> ---
> v5: This patch should handle tristate choice-values, only.
> 
> I assumed that only tristate choice-values can have visibility 'm',
> which was wrong: tristate dependencies can result in 'm'
> visibility.
> 
> So, add an explicit test if a symbol is of type tristate.
> 
> I am a bit unsure how to handle Tested-By credits when patches change
> substantially and left the credits untouched but new test reports
> are welcome.

If you made a non cosmetic change old Tested-By tags aren't valid.

> 
> ---

The USB gadget case works fine for me. Thanks :)

Tested-by: Roger Quadros 

cheers,
-roger

>  scripts/kconfig/symbol.c | 14 ++
>  1 file changed, 14 insertions(+)
> 
> diff --git a/scripts/kconfig/symbol.c b/scripts/kconfig/symbol.c
> index 25cf0c2..2432298 100644
> --- a/scripts/kconfig/symbol.c
> +++ b/scripts/kconfig/symbol.c
> @@ -209,12 +209,26 @@ static void sym_set_all_changed(void)
>  static void sym_calc_visibility(struct symbol *sym)
>  {
>   struct property *prop;
> + struct symbol *choice_sym = NULL;
>   tristate tri;
>  
>   /* any prompt visible? */
>   tri = no;
> +
> + if (sym_is_choice_value(sym))
> + choice_sym = prop_get_symbol(sym_get_choice_prop(sym));
> +
>   for_all_prompts(sym, prop) {
>   prop->visible.tri = expr_calc_value(prop->visible.expr);
> + /*
> +  * Tristate choice_values with visibility 'mod' are
> +  * not visible if the corresponding choice's value is
> +  * 'yes'.
> +  */
> + if (choice_sym && sym->type == S_TRISTATE &&
> + prop->visible.tri == mod && choice_sym->curr.tri == yes)
> + prop->visible.tri = no;
> +
>   tri = EXPR_OR(tri, prop->visible.tri);
>   }
>   if (tri == mod && (sym->type != S_TRISTATE || modules_val == no))
> 
--
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: misc: usbtest: fix pattern tests for scatterlists.

2016-05-02 Thread Mathias Nyman
The current implemenentation restart the sent pattern for each entry in
the sg list. The receiving end expects a continuous pattern, and test
will fail unless scatterilst entries happen to be aligned with the
pattern

Fix this by calculating the pattern byte based on total sent size
instead of just the current sg entry.

Signed-off-by: Mathias Nyman 
---
 drivers/usb/misc/usbtest.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/usb/misc/usbtest.c b/drivers/usb/misc/usbtest.c
index 92fdb6e..c78ff95 100644
--- a/drivers/usb/misc/usbtest.c
+++ b/drivers/usb/misc/usbtest.c
@@ -529,6 +529,7 @@ static struct scatterlist *
 alloc_sglist(int nents, int max, int vary, struct usbtest_dev *dev, int pipe)
 {
struct scatterlist  *sg;
+   unsigned intn_size = 0;
unsignedi;
unsignedsize = max;
unsignedmaxpacket =
@@ -561,7 +562,8 @@ alloc_sglist(int nents, int max, int vary, struct 
usbtest_dev *dev, int pipe)
break;
case 1:
for (j = 0; j < size; j++)
-   *buf++ = (u8) ((j % maxpacket) % 63);
+   *buf++ = (u8) (((j + n_size) % maxpacket) % 63);
+   n_size += size;
break;
}
 
-- 
1.9.1

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


Re: [PATCH] usb: gadget: f_fs: Fix kernel panic for SuperSpeed

2016-05-02 Thread Felipe Balbi

Hi,

Mathias Nyman  writes:
>>> dmesg from PC host side (after adding your change without my patch):
>>>
>>> [17907.984647] usb 6-2: new SuperSpeed USB device number 54 using xhci_hcd
>>> [17908.012036] usb 6-2: No SuperSpeed endpoint companion for config 1
>>> interface 1 altsetting 0 ep 2: using minimum values
>>> [17908.012040] usb 6-2: No SuperSpeed endpoint companion for config 1
>>> interface 1 altsetting 0 ep 131: using minimum values
>>> [17908.013652] usb 6-2: New USB device found, idVendor=, idProduct=
>>> [17908.013656] usb 6-2: New USB device strings: Mfr=1, Product=2,
>>> SerialNumber=3
>>> [17908.013658] usb 6-2: Product: xxx
>>> [17908.013661] usb 6-2: Manufacturer: xx
>>> [17908.013664] usb 6-2: SerialNumber: 1234567890
>>> [17908.014680] xhci_hcd :05:00.0: ERROR: unexpected command
>>> completion code 0x11.
>>
>> hmmm... completed with unknown code ? Odd. Mathias, any idea what this
>> is ?
>>
>
> Parameter error, xhci doesn't like one of the values in one of the contexts we
> give it (slot context, endpoint context etc)

okay, thanks :-)

-- 
balbi


signature.asc
Description: PGP signature


Re: add device id to linux kernel

2016-05-02 Thread Felipe Balbi

Hi,

刘磊  writes:
> dear linuxfoundation:
> I am liulei come from ZTEMT.  We need add some device ID to linux kernel, 
> We need some help from yours. 
> Looking forward to you reply, thanks!
>
>
> Signed-off-by:lei liu
> --- linux-4.5.2/drivers/usb/serial/option.c   2016-04-30 14:52:30.262955240 
> +0800
> +++ linux-4.5.2-update/drivers/usb/serial/option.c2016-04-30 
> 16:51:35.930627755 +0800
> @@ -1621,6 +1621,79 @@ static const struct usb_device_id option
>   { USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0xfff9, 0xff, 0xff, 
> 0xff) },
>   { USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0xfffb, 0xff, 0xff, 
> 0xff) },
>   { USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0xfffc, 0xff, 0xff, 
> 0xff) },
> + { USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0xff8a, 0xff, 0xff, 
> 0xff) },
> + { USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0xff89, 0xff, 0xff, 
> 0xff) },
> + { USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0xff88, 0xff, 0xff, 
> 0xff) },
> + { USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0xff87, 0xff, 0xff, 
> 0xff) },
> + { USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0xff86, 0xff, 0xff, 
> 0xff) },
> + { USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0xff85, 0xff, 0xff, 
> 0xff) },
> + { USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0xff84, 0xff, 0xff, 
> 0xff) },
> + { USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0xff83, 0xff, 0xff, 
> 0xff) },
> + { USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0xff82, 0xff, 0xff, 
> 0xff) },
> + { USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0xff81, 0xff, 0xff, 
> 0xff) },
> + { USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0xff80, 0xff, 0xff, 
> 0xff) },
> + { USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0xff7f, 0xff, 0xff, 
> 0xff) },
> + { USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0xff7e, 0xff, 0xff, 
> 0xff) },
> + { USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0xff7d, 0xff, 0xff, 
> 0xff) },
> + { USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0xff7c, 0xff, 0xff, 
> 0xff) },
> + { USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0xff7b, 0xff, 0xff, 
> 0xff) },
> + { USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0xff7a, 0xff, 0xff, 
> 0xff) },
> + { USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0xff79, 0xff, 0xff, 
> 0xff) },
> + { USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0xff78, 0xff, 0xff, 
> 0xff) },
> + { USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0xff77, 0xff, 0xff, 
> 0xff) },
> + { USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0xff76, 0xff, 0xff, 
> 0xff) },
> + { USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0xff75, 0xff, 0xff, 
> 0xff) },
> + { USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0xff74, 0xff, 0xff, 
> 0xff) },
> + { USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0xff73, 0xff, 0xff, 
> 0xff) },
> + { USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0xff72, 0xff, 0xff, 
> 0xff) },
> + { USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0xff71, 0xff, 0xff, 
> 0xff) },
> + { USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0xff70, 0xff, 0xff, 
> 0xff) },
> + { USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0xff6f, 0xff, 0xff, 
> 0xff) },
> + { USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0xff6e, 0xff, 0xff, 
> 0xff) },
> + { USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0xff6d, 0xff, 0xff, 
> 0xff) },
> + { USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0xff6c, 0xff, 0xff, 
> 0xff) },
> + { USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0xff6b, 0xff, 0xff, 
> 0xff) },
> + { USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0xff6a, 0xff, 0xff, 
> 0xff) },
> + { USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0xff69, 0xff, 0xff, 
> 0xff) },
> + { USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0xff68, 0xff, 0xff, 
> 0xff) },
> + { USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0xff67, 0xff, 0xff, 
> 0xff) },
> + { USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0xff66, 0xff, 0xff, 
> 0xff) },
> + { USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0xff65, 0xff, 0xff, 
> 0xff) },
> + { USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0xff64, 0xff, 0xff, 
> 0xff) },
> + { USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0xff63, 0xff, 0xff, 
> 0xff) },
> + { USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0xff62, 0xff, 0xff, 
> 0xff) },
> + { USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0xff61, 0xff, 0xff, 
> 0xff) },
> + { USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0xff60, 0xff, 0xff, 
> 0xff) },
> + { USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0xff5f, 0xff, 0xff, 
> 0xff) },
> + { USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0xff5e, 0xff, 0xff, 
> 0xff) },
> + { USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0xff5d, 0xff, 0xff, 
> 0xff) },
> + { USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0xff5c, 0xff, 0xff, 
> 0xff) },
> + { USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0xff5b, 0xff, 0xff, 
> 0xff) },
> + { 

Re: [PATCH 1/2] usb: dwc3: gadget: update DCFG.NumP to max burst size

2016-05-02 Thread Felipe Balbi

Hi,

John Youn  writes:
>> John Youn  writes:
>>> On 4/28/2016 1:01 AM, Felipe Balbi wrote:
 NumP field of DCFG register is used on NumP field of
 ACK TP header and it tells the host how many packets
 an endpoint can receive before waiting for
 synchronization.

 Documentation says it should be set to anything
 <=bMaxBurst. Interestingly, however, this setting is
 not per-endpoint how it should be (different
 endpoints could have different burst sizes), but
 things seem to work okay right now.

 Signed-off-by: Felipe Balbi 
 ---
  drivers/usb/dwc3/core.h   |  3 +++
  drivers/usb/dwc3/gadget.c | 14 --
  2 files changed, 15 insertions(+), 2 deletions(-)

 diff --git a/drivers/usb/dwc3/core.h b/drivers/usb/dwc3/core.h
 index 87df6dd20d23..c5f576aa1903 100644
 --- a/drivers/usb/dwc3/core.h
 +++ b/drivers/usb/dwc3/core.h
 @@ -271,6 +271,9 @@
  #define DWC3_DCFG_LOWSPEED(2 << 0)
  #define DWC3_DCFG_FULLSPEED1  (3 << 0)
  
 +#define DWC3_DCFG_NUMP_SHIFT  17
 +#define DWC3_DCFG_NUMP(n) (((n) & 0x1f) >> DWC3_DCFG_NUMP_SHIFT)
 +#define DWC3_DCFG_NUMP_MASK   (0x1f << DWC3_DCFG_NUMP_SHIFT)
  #define DWC3_DCFG_LPM_CAP (1 << 22)
  
  /* Device Control Register */
 diff --git a/drivers/usb/dwc3/gadget.c b/drivers/usb/dwc3/gadget.c
 index 43efb627d1cf..4b681b0d420f 100644
 --- a/drivers/usb/dwc3/gadget.c
 +++ b/drivers/usb/dwc3/gadget.c
 @@ -464,9 +464,19 @@ static int dwc3_gadget_set_ep_config(struct dwc3 
 *dwc, struct dwc3_ep *dep,
  
/* Burst size is only needed in SuperSpeed mode */
if (dwc->gadget.speed >= USB_SPEED_SUPER) {
 -  u32 burst = dep->endpoint.maxburst - 1;
 +  u32 burst = dep->endpoint.maxburst;
 +  u32 nump;
 +  u32 reg;
  
 -  params.param0 |= DWC3_DEPCFG_BURST_SIZE(burst);
 +  /* update NumP */
 +  reg = dwc3_readl(dwc->regs, DWC3_DCFG);
 +  nump = DWC3_DCFG_NUMP(reg);
 +  nump = max(nump, burst);
 +  reg &= ~DWC3_DCFG_NUMP_MASK;
 +  reg |= nump << DWC3_DCFG_NUMP_SHIFT;
 +  dwc3_writel(dwc->regs, DWC3_DCFG, reg);
 +
 +  params.param0 |= DWC3_DEPCFG_BURST_SIZE(burst - 1);
>>>
>>> Hi Felipe,
>>>
>>> The controller already takes care not to send a NUMP greater than the
>>> configured maxburst for the endpoint. So there is no need to do
>>> this. You can just set it globally in core init.
>> 
>> iow, we just set this to the maximum value and forget about it ? That
>
> You can do that and it will always work, but it might not be optimal
> for every system. You may want to tweak this value in that case, or
> set it to calculate based on the rx fifo space.

How about setting it to rx_fifo_size / wMaxPacketSize ?

and I guess rx_fifo_size can be computed with num_words * mdwidth,
right?

-- 
balbi


signature.asc
Description: PGP signature


我的个人主页是

2016-05-02 Thread 我的个人主页是
你的小姐妹邀你加Q群:546645595 抢红包。