bugreport: huawei_cdc_ncm control device freezes for 3-5 minutes on connect with E3276 LTE modem

2014-10-03 Thread Erik Alapää
Problem: When connecting to a Huawei E3276 LTE modem using
'AT+CGACT=1,1' in minicom over /dev/cdc-wdm1, the cdc-wdm device
freezes for 3-5 minutes until accepting AT commands again.

Keywords: huawei_cdc_ncm, LTE, AT commands, cdc-wdm

Detailed problem description:

I am using a 4G mobile USB dongle with the huawei_cdc_ncm driver in
Linux kernel 3.16. In general, the driver works well, but one major
issue is that bringing the modem up using 'AT+CGACT=1.1' freezes the
/dev/cdc-wdm1 control device for 3-5 minutes. After that, the device
accepts more commands over minicom. Note that I do get connectivity,
directly after the CGACT I can get a DHCP address for wwan0 and the
bandwidth is approx 20 Mbit/s downstream and 6 Mbit/s upstream.

I have tried building a custom 3.16 kernel with a few printk:s in
cdc_ncm.c and huawei_cdc_ncm.c, but found nothing suspicious.

Kernel version (from /proc/version): 3.16
Environment: Thinkpad L440 64-bit x86 (Intel Core i5-4200M cpu) laptop
with Kubuntu 14.04.1 LTS
Kernel modules: huawei_cdc_ncm,cdc_ncm

Workaround: Bring up the device with
AT^NDISDUP=1,1,internet.telenor.se instead. Also worth noting is
that AT+CGACT=1,1 does not freeze the control connection if using
/dev/ttyUSB0.

If more info is needed, let me know and I will provide it.

/Erik Alapää
--
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/4] xhci: Introduce xhci_init_driver()

2014-10-03 Thread Mathias Nyman
From: Andrew Bresticker abres...@chromium.org

Since the struct hc_driver is mostly the same across the xhci-pci,
xhci-plat, and the upcoming xhci-tegra driver, introduce the function
xhci_init_driver() which will populate the hc_driver with the default
xHCI operations.  The caller must supply a setup function which will
be used as the hc_driver's reset callback.

Note that xhci-plat also overrides the default -start() callback so
that it can do rcar-specific initialization.

Signed-off-by: Andrew Bresticker abres...@chromium.org
Signed-off-by: Mathias Nyman mathias.ny...@linux.intel.com
---
 drivers/usb/host/xhci-pci.c  | 69 +---
 drivers/usb/host/xhci-plat.c | 59 -
 drivers/usb/host/xhci.c  | 69 
 drivers/usb/host/xhci.h  |  1 +
 4 files changed, 82 insertions(+), 116 deletions(-)

diff --git a/drivers/usb/host/xhci-pci.c b/drivers/usb/host/xhci-pci.c
index c22a3e1..605852d 100644
--- a/drivers/usb/host/xhci-pci.c
+++ b/drivers/usb/host/xhci-pci.c
@@ -40,6 +40,8 @@
 
 static const char hcd_name[] = xhci_hcd;
 
+static struct hc_driver __read_mostly xhci_pci_hc_driver;
+
 /* called after powerup, by probe or system-pm wakeup */
 static int xhci_pci_reinit(struct xhci_hcd *xhci, struct pci_dev *pdev)
 {
@@ -324,68 +326,6 @@ static int xhci_pci_resume(struct usb_hcd *hcd, bool 
hibernated)
 }
 #endif /* CONFIG_PM */
 
-static const struct hc_driver xhci_pci_hc_driver = {
-   .description =  hcd_name,
-   .product_desc = xHCI Host Controller,
-   .hcd_priv_size =sizeof(struct xhci_hcd *),
-
-   /*
-* generic hardware linkage
-*/
-   .irq =  xhci_irq,
-   .flags =HCD_MEMORY | HCD_USB3 | HCD_SHARED,
-
-   /*
-* basic lifecycle operations
-*/
-   .reset =xhci_pci_setup,
-   .start =xhci_run,
-#ifdef CONFIG_PM
-   .pci_suspend =  xhci_pci_suspend,
-   .pci_resume =   xhci_pci_resume,
-#endif
-   .stop = xhci_stop,
-   .shutdown = xhci_shutdown,
-
-   /*
-* managing i/o requests and associated device resources
-*/
-   .urb_enqueue =  xhci_urb_enqueue,
-   .urb_dequeue =  xhci_urb_dequeue,
-   .alloc_dev =xhci_alloc_dev,
-   .free_dev = xhci_free_dev,
-   .alloc_streams =xhci_alloc_streams,
-   .free_streams = xhci_free_streams,
-   .add_endpoint = xhci_add_endpoint,
-   .drop_endpoint =xhci_drop_endpoint,
-   .endpoint_reset =   xhci_endpoint_reset,
-   .check_bandwidth =  xhci_check_bandwidth,
-   .reset_bandwidth =  xhci_reset_bandwidth,
-   .address_device =   xhci_address_device,
-   .enable_device =xhci_enable_device,
-   .update_hub_device =xhci_update_hub_device,
-   .reset_device = xhci_discover_or_reset_device,
-
-   /*
-* scheduling support
-*/
-   .get_frame_number = xhci_get_frame,
-
-   /* Root hub support */
-   .hub_control =  xhci_hub_control,
-   .hub_status_data =  xhci_hub_status_data,
-   .bus_suspend =  xhci_bus_suspend,
-   .bus_resume =   xhci_bus_resume,
-   /*
-* call back when device connected and addressed
-*/
-   .update_device =xhci_update_device,
-   .set_usb2_hw_lpm =  xhci_set_usb2_hardware_lpm,
-   .enable_usb3_lpm_timeout =  xhci_enable_usb3_lpm_timeout,
-   .disable_usb3_lpm_timeout = xhci_disable_usb3_lpm_timeout,
-   .find_raw_port_number = xhci_find_raw_port_number,
-};
-
 /*-*/
 
 /* PCI driver selection metadata; PCI hotplugging uses this */
@@ -417,6 +357,11 @@ static struct pci_driver xhci_pci_driver = {
 
 int __init xhci_register_pci(void)
 {
+   xhci_init_driver(xhci_pci_hc_driver, xhci_pci_setup);
+#ifdef CONFIG_PM
+   xhci_pci_hc_driver.pci_suspend = xhci_pci_suspend;
+   xhci_pci_hc_driver.pci_resume = xhci_pci_resume;
+#endif
return pci_register_driver(xhci_pci_driver);
 }
 
diff --git a/drivers/usb/host/xhci-plat.c b/drivers/usb/host/xhci-plat.c
index 1a0cf9f..f352368 100644
--- a/drivers/usb/host/xhci-plat.c
+++ b/drivers/usb/host/xhci-plat.c
@@ -23,6 +23,8 @@
 #include xhci-mvebu.h
 #include xhci-rcar.h
 
+static struct hc_driver __read_mostly xhci_plat_hc_driver;
+
 static void xhci_plat_quirks(struct device *dev, struct xhci_hcd *xhci)
 {
/*
@@ -60,59 +62,6 @@ static int xhci_plat_start(struct usb_hcd *hcd)
return xhci_run(hcd);
 }
 
-static const struct hc_driver xhci_plat_xhci_driver = {
-   .description =  xhci-hcd,
-   .product_desc = xHCI Host Controller,
-   

[PATCH 3/4] xhci: Export symbols used by host-controller drivers

2014-10-03 Thread Mathias Nyman
From: Andrew Bresticker abres...@chromium.org

In preparation for allowing the xHCI host controller drivers to be built
as separate modules, export symbols from the xHCI core that may be used
by the host controller drivers.

Signed-off-by: Andrew Bresticker abres...@chromium.org
Signed-off-by: Mathias Nyman mathias.ny...@linux.intel.com
---
 drivers/usb/host/xhci-dbg.c   | 1 +
 drivers/usb/host/xhci-trace.c | 2 ++
 drivers/usb/host/xhci.c   | 4 
 3 files changed, 7 insertions(+)

diff --git a/drivers/usb/host/xhci-dbg.c b/drivers/usb/host/xhci-dbg.c
index eb009a4..bb89175 100644
--- a/drivers/usb/host/xhci-dbg.c
+++ b/drivers/usb/host/xhci-dbg.c
@@ -594,3 +594,4 @@ void xhci_dbg_trace(struct xhci_hcd *xhci, void 
(*trace)(struct va_format *),
trace(vaf);
va_end(args);
 }
+EXPORT_SYMBOL_GPL(xhci_dbg_trace);
diff --git a/drivers/usb/host/xhci-trace.c b/drivers/usb/host/xhci-trace.c
index 7cf30c8..367b630 100644
--- a/drivers/usb/host/xhci-trace.c
+++ b/drivers/usb/host/xhci-trace.c
@@ -13,3 +13,5 @@
 
 #define CREATE_TRACE_POINTS
 #include xhci-trace.h
+
+EXPORT_TRACEPOINT_SYMBOL_GPL(xhci_dbg_quirks);
diff --git a/drivers/usb/host/xhci.c b/drivers/usb/host/xhci.c
index d4e1340..3e0f5c7 100644
--- a/drivers/usb/host/xhci.c
+++ b/drivers/usb/host/xhci.c
@@ -653,6 +653,7 @@ int xhci_run(struct usb_hcd *hcd)
Finished xhci_run for USB2 roothub);
return 0;
 }
+EXPORT_SYMBOL_GPL(xhci_run);
 
 static void xhci_only_stop_hcd(struct usb_hcd *hcd)
 {
@@ -929,6 +930,7 @@ int xhci_suspend(struct xhci_hcd *xhci)
 
return rc;
 }
+EXPORT_SYMBOL_GPL(xhci_suspend);
 
 /*
  * start xHC (not bus-specific)
@@ -1082,6 +1084,7 @@ int xhci_resume(struct xhci_hcd *xhci, bool hibernated)
 
return retval;
 }
+EXPORT_SYMBOL_GPL(xhci_resume);
 #endif /* CONFIG_PM */
 
 /*-*/
@@ -4902,6 +4905,7 @@ error:
kfree(xhci);
return retval;
 }
+EXPORT_SYMBOL_GPL(xhci_gen_setup);
 
 static const struct hc_driver xhci_hc_driver = {
.description =  xhci-hcd,
-- 
1.8.3.2

--
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/4] xhci: Check for XHCI_COMP_MODE_QUIRK when disabling D3cold

2014-10-03 Thread Mathias Nyman
From: Andrew Bresticker abres...@chromium.org

Instead of calling xhci_compliance_mode_recovery_timer_quirk_check() again
in the PCI suspend path, just check for XHCI_COMP_MODE_QUIRK which will
have been set based on xhci_compliance_mode_recovery_timer_quirk_check()
in xhci_init().

Signed-off-by: Andrew Bresticker abres...@chromium.org
Signed-off-by: Mathias Nyman mathias.ny...@linux.intel.com
---
 drivers/usb/host/xhci-pci.c | 2 +-
 drivers/usb/host/xhci.c | 2 +-
 drivers/usb/host/xhci.h | 3 ---
 3 files changed, 2 insertions(+), 5 deletions(-)

diff --git a/drivers/usb/host/xhci-pci.c b/drivers/usb/host/xhci-pci.c
index 605852d..effa62a 100644
--- a/drivers/usb/host/xhci-pci.c
+++ b/drivers/usb/host/xhci-pci.c
@@ -288,7 +288,7 @@ static int xhci_pci_suspend(struct usb_hcd *hcd, bool 
do_wakeup)
 * Systems with the TI redriver that loses port status change events
 * need to have the registers polled during D3, so avoid D3cold.
 */
-   if (xhci_compliance_mode_recovery_timer_quirk_check())
+   if (xhci-quirks  XHCI_COMP_MODE_QUIRK)
pdev-no_d3cold = true;
 
return xhci_suspend(xhci);
diff --git a/drivers/usb/host/xhci.c b/drivers/usb/host/xhci.c
index 1787dee..d4e1340 100644
--- a/drivers/usb/host/xhci.c
+++ b/drivers/usb/host/xhci.c
@@ -491,7 +491,7 @@ static void compliance_mode_recovery_timer_init(struct 
xhci_hcd *xhci)
  * Systems:
  * Vendor: Hewlett-Packard - System Models: Z420, Z620 and Z820
  */
-bool xhci_compliance_mode_recovery_timer_quirk_check(void)
+static bool xhci_compliance_mode_recovery_timer_quirk_check(void)
 {
const char *dmi_product_name, *dmi_sys_vendor;
 
diff --git a/drivers/usb/host/xhci.h b/drivers/usb/host/xhci.h
index fdc394e..a099f38 100644
--- a/drivers/usb/host/xhci.h
+++ b/drivers/usb/host/xhci.h
@@ -1887,7 +1887,4 @@ struct xhci_input_control_ctx 
*xhci_get_input_control_ctx(struct xhci_hcd *xhci,
 struct xhci_slot_ctx *xhci_get_slot_ctx(struct xhci_hcd *xhci, struct 
xhci_container_ctx *ctx);
 struct xhci_ep_ctx *xhci_get_ep_ctx(struct xhci_hcd *xhci, struct 
xhci_container_ctx *ctx, unsigned int ep_index);
 
-/* xHCI quirks */
-bool xhci_compliance_mode_recovery_timer_quirk_check(void);
-
 #endif /* __LINUX_XHCI_HCD_H */
-- 
1.8.3.2

--
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 4/4] xhci: Allow xHCI drivers to be built as separate modules

2014-10-03 Thread Mathias Nyman
From: Andrew Bresticker abres...@chromium.org

Instead of building all of the xHCI code into a single module, separate
it out into the core (xhci-hcd), PCI (xhci-pci, now selected by the new
config option CONFIG_USB_XHCI_PCI), and platform (xhci-plat) drivers.
Also update the PCI/platform drivers with module descriptions/licenses
and have them register their respective drivers in their initcalls.

Signed-off-by: Andrew Bresticker abres...@chromium.org
Signed-off-by: Mathias Nyman mathias.ny...@linux.intel.com
---
 drivers/usb/host/Kconfig |  5 +
 drivers/usb/host/Makefile| 12 ++--
 drivers/usb/host/xhci-pci.c  |  9 +++--
 drivers/usb/host/xhci-plat.c |  9 +++--
 drivers/usb/host/xhci.c  | 22 --
 drivers/usb/host/xhci.h  | 19 ---
 6 files changed, 25 insertions(+), 51 deletions(-)

diff --git a/drivers/usb/host/Kconfig b/drivers/usb/host/Kconfig
index 002ba1d..fa038a2 100644
--- a/drivers/usb/host/Kconfig
+++ b/drivers/usb/host/Kconfig
@@ -26,6 +26,11 @@ config USB_XHCI_HCD
 
 if USB_XHCI_HCD
 
+config USB_XHCI_PCI
+   tristate
+   depends on PCI
+   default y
+
 config USB_XHCI_PLATFORM
tristate
 
diff --git a/drivers/usb/host/Makefile b/drivers/usb/host/Makefile
index 0336bb2..8c69189 100644
--- a/drivers/usb/host/Makefile
+++ b/drivers/usb/host/Makefile
@@ -15,22 +15,22 @@ fhci-$(CONFIG_FHCI_DEBUG) += fhci-dbg.o
 xhci-hcd-y := xhci.o xhci-mem.o
 xhci-hcd-y += xhci-ring.o xhci-hub.o xhci-dbg.o
 xhci-hcd-y += xhci-trace.o
-xhci-hcd-$(CONFIG_PCI) += xhci-pci.o
 
-ifneq ($(CONFIG_USB_XHCI_PLATFORM), )
-   xhci-hcd-y  += xhci-plat.o
+xhci-plat-hcd-y := xhci-plat.o
 ifneq ($(CONFIG_USB_XHCI_MVEBU), )
-   xhci-hcd-y  += xhci-mvebu.o
+   xhci-plat-hcd-y += xhci-mvebu.o
 endif
 ifneq ($(CONFIG_USB_XHCI_RCAR), )
-   xhci-hcd-y  += xhci-rcar.o
-endif
+   xhci-plat-hcd-y += xhci-rcar.o
 endif
 
 obj-$(CONFIG_USB_WHCI_HCD) += whci/
 
 obj-$(CONFIG_PCI)  += pci-quirks.o
 
+obj-$(CONFIG_USB_XHCI_PCI) += xhci-pci.o
+obj-$(CONFIG_USB_XHCI_PLATFORM) += xhci-plat-hcd.o
+
 obj-$(CONFIG_USB_EHCI_HCD) += ehci-hcd.o
 obj-$(CONFIG_USB_EHCI_PCI) += ehci-pci.o
 obj-$(CONFIG_USB_EHCI_HCD_PLATFORM)+= ehci-platform.o
diff --git a/drivers/usb/host/xhci-pci.c b/drivers/usb/host/xhci-pci.c
index effa62a..280dde9 100644
--- a/drivers/usb/host/xhci-pci.c
+++ b/drivers/usb/host/xhci-pci.c
@@ -355,7 +355,7 @@ static struct pci_driver xhci_pci_driver = {
 #endif
 };
 
-int __init xhci_register_pci(void)
+static int __init xhci_pci_init(void)
 {
xhci_init_driver(xhci_pci_hc_driver, xhci_pci_setup);
 #ifdef CONFIG_PM
@@ -364,8 +364,13 @@ int __init xhci_register_pci(void)
 #endif
return pci_register_driver(xhci_pci_driver);
 }
+module_init(xhci_pci_init);
 
-void xhci_unregister_pci(void)
+static void __exit xhci_pci_exit(void)
 {
pci_unregister_driver(xhci_pci_driver);
 }
+module_exit(xhci_pci_exit);
+
+MODULE_DESCRIPTION(xHCI PCI Host Controller Driver);
+MODULE_LICENSE(GPL);
diff --git a/drivers/usb/host/xhci-plat.c b/drivers/usb/host/xhci-plat.c
index f352368..3d78b0c 100644
--- a/drivers/usb/host/xhci-plat.c
+++ b/drivers/usb/host/xhci-plat.c
@@ -247,14 +247,19 @@ static struct platform_driver usb_xhci_driver = {
 };
 MODULE_ALIAS(platform:xhci-hcd);
 
-int xhci_register_plat(void)
+static int __init xhci_plat_init(void)
 {
xhci_init_driver(xhci_plat_hc_driver, xhci_plat_setup);
xhci_plat_hc_driver.start = xhci_plat_start;
return platform_driver_register(usb_xhci_driver);
 }
+module_init(xhci_plat_init);
 
-void xhci_unregister_plat(void)
+static void __exit xhci_plat_exit(void)
 {
platform_driver_unregister(usb_xhci_driver);
 }
+module_exit(xhci_plat_exit);
+
+MODULE_DESCRIPTION(xHCI Platform Host Controller Driver);
+MODULE_LICENSE(GPL);
diff --git a/drivers/usb/host/xhci.c b/drivers/usb/host/xhci.c
index 3e0f5c7..2a5d45b 100644
--- a/drivers/usb/host/xhci.c
+++ b/drivers/usb/host/xhci.c
@@ -4982,18 +4982,6 @@ MODULE_LICENSE(GPL);
 
 static int __init xhci_hcd_init(void)
 {
-   int retval;
-
-   retval = xhci_register_pci();
-   if (retval  0) {
-   pr_debug(Problem registering PCI driver.\n);
-   return retval;
-   }
-   retval = xhci_register_plat();
-   if (retval  0) {
-   pr_debug(Problem registering platform driver.\n);
-   goto unreg_pci;
-   }
/*
 * Check the compiler generated sizes of structures that must be laid
 * out in specific ways for hardware access.
@@ -5012,15 +5000,5 @@ static int __init xhci_hcd_init(void)
/* xhci_run_regs has eight fields and embeds 128 xhci_intr_regs */
BUILD_BUG_ON(sizeof(struct xhci_run_regs) != (8+8*128)*32/8);
return 0;
-unreg_pci:
-   xhci_unregister_pci();
-   return retval;
 }
 module_init(xhci_hcd_init);
-

[PATCH 0/4] xhci features for usb-next

2014-10-03 Thread Mathias Nyman
Hi Greg

Here's Andrew's patches modularizing xhci to better support
non-PCI xhci hosts like the one on NVIDIA Tegra SoCs

If possible, consider applying them to your usb-next branch so they still could 
make it to 3.18

-Mathias

Andrew Bresticker (4):
  xhci: Introduce xhci_init_driver()
  xhci: Check for XHCI_COMP_MODE_QUIRK when disabling D3cold
  xhci: Export symbols used by host-controller drivers
  xhci: Allow xHCI drivers to be built as separate modules

 drivers/usb/host/Kconfig  |  5 +++
 drivers/usb/host/Makefile | 12 +++---
 drivers/usb/host/xhci-dbg.c   |  1 +
 drivers/usb/host/xhci-pci.c   | 80 +++
 drivers/usb/host/xhci-plat.c  | 68 ++
 drivers/usb/host/xhci-trace.c |  2 +
 drivers/usb/host/xhci.c   | 97 +--
 drivers/usb/host/xhci.h   | 23 +-
 8 files changed, 116 insertions(+), 172 deletions(-)

-- 
1.8.3.2

--
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] [next-20141003] USB: host: st: fix typo 'CONFIG_USB_EHCI_HCD_ST'

2014-10-03 Thread Paul Bolle
Signed-off-by: Paul Bolle pebo...@tiscali.nl
Fixes: 905e300e1043 (USB: host: st: fix ehci/ohci driver selection)
---
drivers/usb/host/ehci-st.o actually builds (on x86_64. that is) so
there's no _obvious_ reason not to fix this typo.

 drivers/usb/host/Makefile | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/usb/host/Makefile b/drivers/usb/host/Makefile
index 0336bb2c0e6f..3beda2655232 100644
--- a/drivers/usb/host/Makefile
+++ b/drivers/usb/host/Makefile
@@ -38,7 +38,7 @@ obj-$(CONFIG_USB_EHCI_MXC)+= ehci-mxc.o
 obj-$(CONFIG_USB_EHCI_HCD_OMAP)+= ehci-omap.o
 obj-$(CONFIG_USB_EHCI_HCD_ORION)   += ehci-orion.o
 obj-$(CONFIG_USB_EHCI_HCD_SPEAR)   += ehci-spear.o
-obj-$(CONFIG_USB_EHCI_HCD_ST)  += ehci-st.o
+obj-$(CONFIG_USB_EHCI_HCD_STI) += ehci-st.o
 obj-$(CONFIG_USB_EHCI_EXYNOS)  += ehci-exynos.o
 obj-$(CONFIG_USB_EHCI_HCD_AT91) += ehci-atmel.o
 obj-$(CONFIG_USB_EHCI_MSM) += ehci-msm.o
-- 
1.9.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


Re: [PATCH 2/2] uas: Make uas work with blk-mq

2014-10-03 Thread Christoph Hellwig
On Thu, Oct 02, 2014 at 09:25:50AM -0400, James Bottomley wrote:
 OK, so 3.17 should be on sunday giving three days or so to sort this
 out.  If you're happy with blk-mq being disabled so the bug never
 triggers unless the user activates it, doing nothing is my preferred
 outcome ... but that also means no need to backport to stable.  
 
 If you want a it fixed in 3.17, then we need a patch from you now.
 Ultimately you have to judge the necessity for us, since it's your
 driver.

scsi-mq might be new and not default, but I wouldn't really consider it
experimental in the sense that people should expect crashes if they
attach a usb device.

Please consider applying the patch below for 3.17, as there is a cxgb
patch pending anyway:

---
From 8a42ea1369701960a821b7fa9a3da5c68e7e4366 Mon Sep 17 00:00:00 2001
From: Christoph Hellwig h...@lst.de
Date: Fri, 3 Oct 2014 10:45:10 +0200
Subject: uas: disable use of blk-mq I/O path
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

The uas driver uses the block layer tag for USB3 stream IDs.  With
blk-mq we can get larger tag numbers that the queue depth, which breaks
this assumption.  A fix is under way for 3.18, but sits on top of
large changes so can't easily be backported.   Set the disable_blk_mq
path so that a uas device can't easily crash the system when using
blk-mq for SCSI.

Signed-off-by: Christoph Hellwig h...@lst.de
Acked-by: Hans de Goede hdego...@redhat.com
---
 drivers/usb/storage/uas.c | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/drivers/usb/storage/uas.c b/drivers/usb/storage/uas.c
index 3f42785..9bfa725 100644
--- a/drivers/usb/storage/uas.c
+++ b/drivers/usb/storage/uas.c
@@ -970,6 +970,13 @@ static struct scsi_host_template uas_host_template = {
.cmd_per_lun = 1,   /* until we override it */
.skip_settle_delay = 1,
.ordered_tag = 1,
+
+   /*
+* The uas drivers expects tags not to be bigger than the maximum
+* per-device queue depth, which is not true with the blk-mq tag
+* allocator.
+*/
+   .disable_blk_mq = true,
 };
 
 #define UNUSUAL_DEV(id_vendor, id_product, bcdDeviceMin, bcdDeviceMax, \
-- 
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 2/2] uas: Make uas work with blk-mq

2014-10-03 Thread Hans de Goede
Hi,

On 10/03/2014 10:47 AM, Christoph Hellwig wrote:
 On Thu, Oct 02, 2014 at 09:25:50AM -0400, James Bottomley wrote:
 OK, so 3.17 should be on sunday giving three days or so to sort this
 out.  If you're happy with blk-mq being disabled so the bug never
 triggers unless the user activates it, doing nothing is my preferred
 outcome ... but that also means no need to backport to stable.  

 If you want a it fixed in 3.17, then we need a patch from you now.
 Ultimately you have to judge the necessity for us, since it's your
 driver.
 
 scsi-mq might be new and not default, but I wouldn't really consider it
 experimental in the sense that people should expect crashes if they
 attach a usb device.
 
 Please consider applying the patch below for 3.17, as there is a cxgb
 patch pending anyway:

For the record, and since I said before that I'm fine with leaving this as
is. As Christoph believes it is important to get this fixed for 3.17, lets
try to get this fix in.

So my Acked-by which is included below still stands.

Regards,

Hans



 
 ---
 From 8a42ea1369701960a821b7fa9a3da5c68e7e4366 Mon Sep 17 00:00:00 2001
 From: Christoph Hellwig h...@lst.de
 Date: Fri, 3 Oct 2014 10:45:10 +0200
 Subject: uas: disable use of blk-mq I/O path
 MIME-Version: 1.0
 Content-Type: text/plain; charset=UTF-8
 Content-Transfer-Encoding: 8bit
 
 The uas driver uses the block layer tag for USB3 stream IDs.  With
 blk-mq we can get larger tag numbers that the queue depth, which breaks
 this assumption.  A fix is under way for 3.18, but sits on top of
 large changes so can't easily be backported.   Set the disable_blk_mq
 path so that a uas device can't easily crash the system when using
 blk-mq for SCSI.
 
 Signed-off-by: Christoph Hellwig h...@lst.de
 Acked-by: Hans de Goede hdego...@redhat.com
 ---
  drivers/usb/storage/uas.c | 7 +++
  1 file changed, 7 insertions(+)
 
 diff --git a/drivers/usb/storage/uas.c b/drivers/usb/storage/uas.c
 index 3f42785..9bfa725 100644
 --- a/drivers/usb/storage/uas.c
 +++ b/drivers/usb/storage/uas.c
 @@ -970,6 +970,13 @@ static struct scsi_host_template uas_host_template = {
   .cmd_per_lun = 1,   /* until we override it */
   .skip_settle_delay = 1,
   .ordered_tag = 1,
 +
 + /*
 +  * The uas drivers expects tags not to be bigger than the maximum
 +  * per-device queue depth, which is not true with the blk-mq tag
 +  * allocator.
 +  */
 + .disable_blk_mq = true,
  };
  
  #define UNUSUAL_DEV(id_vendor, id_product, bcdDeviceMin, bcdDeviceMax, \
 
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[PATCH v2 1/2] uas: Reduce number of function arguments for uas_alloc_foo functions

2014-10-03 Thread Hans de Goede
The stream_id and pipe are already present in uas_cmd_info resp uas_dev_info,
so there is no need to pass a copy along.

Signed-off-by: Hans de Goede hdego...@redhat.com
Reviewed-by: Christoph Hellwig h...@lst.de
---
 drivers/usb/storage/uas.c | 29 ++---
 1 file changed, 14 insertions(+), 15 deletions(-)

diff --git a/drivers/usb/storage/uas.c b/drivers/usb/storage/uas.c
index f62ef61..89b2434 100644
--- a/drivers/usb/storage/uas.c
+++ b/drivers/usb/storage/uas.c
@@ -412,20 +412,22 @@ static void uas_cmd_cmplt(struct urb *urb)
 }
 
 static struct urb *uas_alloc_data_urb(struct uas_dev_info *devinfo, gfp_t gfp,
- unsigned int pipe, u16 stream_id,
  struct scsi_cmnd *cmnd,
  enum dma_data_direction dir)
 {
struct usb_device *udev = devinfo-udev;
+   struct uas_cmd_info *cmdinfo = (void *)cmnd-SCp;
struct urb *urb = usb_alloc_urb(0, gfp);
struct scsi_data_buffer *sdb = (dir == DMA_FROM_DEVICE)
? scsi_in(cmnd) : scsi_out(cmnd);
+   unsigned int pipe = (dir == DMA_FROM_DEVICE)
+   ? devinfo-data_in_pipe : devinfo-data_out_pipe;
 
if (!urb)
goto out;
usb_fill_bulk_urb(urb, udev, pipe, NULL, sdb-length,
  uas_data_cmplt, cmnd);
-   urb-stream_id = stream_id;
+   urb-stream_id = cmdinfo-stream;
urb-num_sgs = udev-bus-sg_tablesize ? sdb-table.nents : 0;
urb-sg = sdb-table.sgl;
  out:
@@ -433,9 +435,10 @@ static struct urb *uas_alloc_data_urb(struct uas_dev_info 
*devinfo, gfp_t gfp,
 }
 
 static struct urb *uas_alloc_sense_urb(struct uas_dev_info *devinfo, gfp_t gfp,
-  struct Scsi_Host *shost, u16 stream_id)
+  struct scsi_cmnd *cmnd)
 {
struct usb_device *udev = devinfo-udev;
+   struct uas_cmd_info *cmdinfo = (void *)cmnd-SCp;
struct urb *urb = usb_alloc_urb(0, gfp);
struct sense_iu *iu;
 
@@ -447,8 +450,8 @@ static struct urb *uas_alloc_sense_urb(struct uas_dev_info 
*devinfo, gfp_t gfp,
goto free;
 
usb_fill_bulk_urb(urb, udev, devinfo-status_pipe, iu, sizeof(*iu),
-   uas_stat_cmplt, shost);
-   urb-stream_id = stream_id;
+ uas_stat_cmplt, cmnd-device-host);
+   urb-stream_id = cmdinfo-stream;
urb-transfer_flags |= URB_FREE_BUFFER;
  out:
return urb;
@@ -500,15 +503,13 @@ static struct urb *uas_alloc_cmd_urb(struct uas_dev_info 
*devinfo, gfp_t gfp,
  * daft to me.
  */
 
-static struct urb *uas_submit_sense_urb(struct scsi_cmnd *cmnd,
-   gfp_t gfp, unsigned int stream)
+static struct urb *uas_submit_sense_urb(struct scsi_cmnd *cmnd, gfp_t gfp)
 {
-   struct Scsi_Host *shost = cmnd-device-host;
-   struct uas_dev_info *devinfo = (struct uas_dev_info *)shost-hostdata;
+   struct uas_dev_info *devinfo = cmnd-device-hostdata;
struct urb *urb;
int err;
 
-   urb = uas_alloc_sense_urb(devinfo, gfp, shost, stream);
+   urb = uas_alloc_sense_urb(devinfo, gfp, cmnd);
if (!urb)
return NULL;
usb_anchor_urb(urb, devinfo-sense_urbs);
@@ -531,7 +532,7 @@ static int uas_submit_urbs(struct scsi_cmnd *cmnd,
 
lockdep_assert_held(devinfo-lock);
if (cmdinfo-state  SUBMIT_STATUS_URB) {
-   urb = uas_submit_sense_urb(cmnd, gfp, cmdinfo-stream);
+   urb = uas_submit_sense_urb(cmnd, gfp);
if (!urb)
return SCSI_MLQUEUE_DEVICE_BUSY;
cmdinfo-state = ~SUBMIT_STATUS_URB;
@@ -539,8 +540,7 @@ static int uas_submit_urbs(struct scsi_cmnd *cmnd,
 
if (cmdinfo-state  ALLOC_DATA_IN_URB) {
cmdinfo-data_in_urb = uas_alloc_data_urb(devinfo, gfp,
-   devinfo-data_in_pipe, cmdinfo-stream,
-   cmnd, DMA_FROM_DEVICE);
+   cmnd, DMA_FROM_DEVICE);
if (!cmdinfo-data_in_urb)
return SCSI_MLQUEUE_DEVICE_BUSY;
cmdinfo-state = ~ALLOC_DATA_IN_URB;
@@ -560,8 +560,7 @@ static int uas_submit_urbs(struct scsi_cmnd *cmnd,
 
if (cmdinfo-state  ALLOC_DATA_OUT_URB) {
cmdinfo-data_out_urb = uas_alloc_data_urb(devinfo, gfp,
-   devinfo-data_out_pipe, cmdinfo-stream,
-   cmnd, DMA_TO_DEVICE);
+   cmnd, DMA_TO_DEVICE);
if (!cmdinfo-data_out_urb)
return SCSI_MLQUEUE_DEVICE_BUSY;
cmdinfo-state = ~ALLOC_DATA_OUT_URB;
-- 
2.1.0

--
To unsubscribe from this list: send the line unsubscribe linux-usb 

[PATCH v2 2/2] uas: Make uas work with blk-mq

2014-10-03 Thread Hans de Goede
With uas over usb-3 the tags inside the uas iu-s must match the usb-3 stream
ids, and those go from 1 - qdepth.

Before blk-mq calling scsi_activate_tcq(sdev, qdepth) guaranteed that we would
only get cmnd-request-tag from 0 - (qdepth - 1), and we used those as
uas-tags / stream-ids.

With blk-mq however we are guaranteed to never get more then qdepth commands
queued at the same time, but the cmnd-request-tag values may be much larger,
which breaks uas.

This commit fixes this by generating uas tags in the 1 - qdepth range ourselves
instead of using cmnd-request-tag.

While touching all involved code anyways also rename the uas_cmd_info stream
field to uas_tag, because when using uas over usb-2 streams are not used.

Cc: Christoph Hellwig h...@infradead.org
Reported-by: Douglas Gilbert dgilb...@interlog.com
Signed-off-by: Hans de Goede hdego...@redhat.com
Reviewed-by: Christoph Hellwig h...@lst.de

--
Changes in v2:
-Remove .disable_blk_mq = true from uas_host_template
---
 drivers/usb/storage/uas.c | 64 +--
 1 file changed, 23 insertions(+), 41 deletions(-)

diff --git a/drivers/usb/storage/uas.c b/drivers/usb/storage/uas.c
index 89b2434..004ebc1 100644
--- a/drivers/usb/storage/uas.c
+++ b/drivers/usb/storage/uas.c
@@ -66,7 +66,7 @@ enum {
 /* Overrides scsi_pointer */
 struct uas_cmd_info {
unsigned int state;
-   unsigned int stream;
+   unsigned int uas_tag;
struct urb *cmd_urb;
struct urb *data_in_urb;
struct urb *data_out_urb;
@@ -173,30 +173,15 @@ static void uas_sense(struct urb *urb, struct scsi_cmnd 
*cmnd)
cmnd-result = sense_iu-status;
 }
 
-/*
- * scsi-tags go from 0 - (nr_tags - 1), uas tags need to match stream-ids,
- * which go from 1 - nr_streams. And we use 1 for untagged commands.
- */
-static int uas_get_tag(struct scsi_cmnd *cmnd)
-{
-   int tag;
-
-   if (blk_rq_tagged(cmnd-request))
-   tag = cmnd-request-tag + 2;
-   else
-   tag = 1;
-
-   return tag;
-}
-
 static void uas_log_cmd_state(struct scsi_cmnd *cmnd, const char *prefix,
  int status)
 {
struct uas_cmd_info *ci = (void *)cmnd-SCp;
+   struct uas_cmd_info *cmdinfo = (void *)cmnd-SCp;
 
scmd_printk(KERN_INFO, cmnd,
-   %s %d tag %d inflight:%s%s%s%s%s%s%s%s%s%s%s%s ,
-   prefix, status, uas_get_tag(cmnd),
+   %s %d uas-tag %d inflight:%s%s%s%s%s%s%s%s%s%s%s%s ,
+   prefix, status, cmdinfo-uas_tag,
(ci-state  SUBMIT_STATUS_URB) ?  s-st  : ,
(ci-state  ALLOC_DATA_IN_URB) ?  a-in  : ,
(ci-state  SUBMIT_DATA_IN_URB)?  s-in  : ,
@@ -242,7 +227,7 @@ static int uas_try_complete(struct scsi_cmnd *cmnd, const 
char *caller)
  DATA_OUT_URB_INFLIGHT |
  COMMAND_ABORTED))
return -EBUSY;
-   devinfo-cmnd[uas_get_tag(cmnd) - 1] = NULL;
+   devinfo-cmnd[cmdinfo-uas_tag - 1] = NULL;
uas_free_unsubmitted_urbs(cmnd);
cmnd-scsi_done(cmnd);
return 0;
@@ -289,7 +274,7 @@ static void uas_stat_cmplt(struct urb *urb)
idx = be16_to_cpup(iu-tag) - 1;
if (idx = MAX_CMNDS || !devinfo-cmnd[idx]) {
dev_err(urb-dev-dev,
-   stat urb: no pending cmd for tag %d\n, idx + 1);
+   stat urb: no pending cmd for uas-tag %d\n, idx + 1);
goto out;
}
 
@@ -427,7 +412,8 @@ static struct urb *uas_alloc_data_urb(struct uas_dev_info 
*devinfo, gfp_t gfp,
goto out;
usb_fill_bulk_urb(urb, udev, pipe, NULL, sdb-length,
  uas_data_cmplt, cmnd);
-   urb-stream_id = cmdinfo-stream;
+   if (devinfo-use_streams)
+   urb-stream_id = cmdinfo-uas_tag;
urb-num_sgs = udev-bus-sg_tablesize ? sdb-table.nents : 0;
urb-sg = sdb-table.sgl;
  out:
@@ -451,7 +437,8 @@ static struct urb *uas_alloc_sense_urb(struct uas_dev_info 
*devinfo, gfp_t gfp,
 
usb_fill_bulk_urb(urb, udev, devinfo-status_pipe, iu, sizeof(*iu),
  uas_stat_cmplt, cmnd-device-host);
-   urb-stream_id = cmdinfo-stream;
+   if (devinfo-use_streams)
+   urb-stream_id = cmdinfo-uas_tag;
urb-transfer_flags |= URB_FREE_BUFFER;
  out:
return urb;
@@ -465,6 +452,7 @@ static struct urb *uas_alloc_cmd_urb(struct uas_dev_info 
*devinfo, gfp_t gfp,
 {
struct usb_device *udev = devinfo-udev;
struct scsi_device *sdev = cmnd-device;
+   struct uas_cmd_info *cmdinfo = (void *)cmnd-SCp;
struct urb *urb = usb_alloc_urb(0, gfp);
struct command_iu *iu;
int len;
@@ -481,7 +469,7 @@ static struct urb *uas_alloc_cmd_urb(struct uas_dev_info 
*devinfo, gfp_t gfp,
goto free;
 
iu-iu_id = IU_ID_COMMAND;
-   iu-tag = 

Re: Question about calculate trbs in xhci

2014-10-03 Thread Mathias Nyman
On 10/01/2014 05:50 PM, vichy wrote:
 hi Mathias:
 

 In xhci-ring.c,  static int xhci_queue_isoc_tx():

 /* Calculate TRB length */
   trb_buff_len = TRB_MAX_BUFF_SIZE - (addr  ((1  TRB_MAX_BUFF_SHIFT) - 
 1));

 where  addr = start_addr + urb-iso_frame_desc[i].offset;

 this limits the trb_buff_len to stop the trb buffer at TRB_MAX_BUFF_SIZE 
 boundary
 Yes, you are right.
 the above is make sure trb buffer will not cross over
 TRB_MAX_BUFF_SIZE boundary.
 But it still possible to cross the page boundary for ISO trb, right?
 (suppose page boundary is 4KB, TRB_MAX_BUFF_SIZE is 64KB)
 
 appreciate your kind help,
 

Hi

As I understood it, it is ok to cross page boundaries as long as the buffer is 
physically contiguous. As our dma case should be.
xhci specification section 3.2.8 says that:

Note that no constraints are placed on the TRB Length fields in a 
Scatter/Gather list. Classically all the
buffers pointed to by a scatter gather list were required to be “page size” in 
length except for the first and
last (as illustrated by the example above). The xHCI does not require this 
constraint. Any buffer pointed to
by a Normal, Data Stage, or Isoch TRB in a TD may be any size between 0 and 64K 
bytes in size. For
instance, if when an OS translates a virtual memory buffer into a list of 
physical pages, some of the entries
in the list reference multiple contiguous pages, the flexible Length fields of 
TRBs allow a 1:1 mapping of list
entries to TRBs, i.e. a multi-page list entry does not need to be defined as 
multiple page sized TRBs.


Same section defines a scatter/gather transfer as:
Transfers that are comprised of non-contiguous data (e.g. cross memory Page 
boundaries) are referred to
as Scatter/Gather Transfers.

-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 v6 2/4] i2c: add support for Diolan DLN-2 USB-I2C adapter

2014-10-03 Thread Octavian Purdila
On Fri, Oct 3, 2014 at 4:14 AM, Wolfram Sang w...@the-dreams.de wrote:
 Hi,

 diff --git a/drivers/i2c/busses/Kconfig b/drivers/i2c/busses/Kconfig
 index 2ac87fa..6afc17e 100644
 --- a/drivers/i2c/busses/Kconfig
 +++ b/drivers/i2c/busses/Kconfig
 @@ -1021,4 +1021,14 @@ config SCx200_ACB
 This support is also available as a module.  If so, the module
 will be called scx200_acb.

 +config I2C_DLN2
 +   tristate Diolan DLN-2 USB I2C adapter
 +   depends on MFD_DLN2
 +   help
 + If you say yes to this option, support will be included for Diolan
 + DLN2, a USB to I2C interface.
 +
 + This driver can also be built as a module.  If so, the module
 + will be called i2c-dln2.
 +

 Please keep to the existing sorting.


  endmenu
 diff --git a/drivers/i2c/busses/Makefile b/drivers/i2c/busses/Makefile
 index 49bf07e..3118fea 100644
 --- a/drivers/i2c/busses/Makefile
 +++ b/drivers/i2c/busses/Makefile
 @@ -100,5 +100,6 @@ obj-$(CONFIG_I2C_ELEKTOR) += i2c-elektor.o
  obj-$(CONFIG_I2C_PCA_ISA)+= i2c-pca-isa.o
  obj-$(CONFIG_I2C_SIBYTE) += i2c-sibyte.o
  obj-$(CONFIG_SCx200_ACB) += scx200_acb.o
 +obj-$(CONFIG_I2C_DLN2)   += i2c-dln2.o

 Ditto!

 +static int dln2_i2c_enable(struct dln2_i2c *dln2, bool enable)
 +{
 + int ret;
 + u16 cmd;
 +
 + if (enable)
 + cmd = DLN2_I2C_ENABLE;
 + else
 + cmd = DLN2_I2C_DISABLE;

 Ternary operator?


In the first versions of the patch it was used, but Johan suggested to avoid it.

I have addressed the rest of you comments, thanks for the review.
--
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: Question about calculate trbs in xhci

2014-10-03 Thread David Laight
From: Mathias Nyman
 On 10/01/2014 05:50 PM, vichy wrote:
  hi Mathias:
 
 
  In xhci-ring.c,  static int xhci_queue_isoc_tx():
 
  /* Calculate TRB length */
trb_buff_len = TRB_MAX_BUFF_SIZE - (addr  ((1  TRB_MAX_BUFF_SHIFT) - 
  1));
 
  where  addr = start_addr + urb-iso_frame_desc[i].offset;
 
  this limits the trb_buff_len to stop the trb buffer at TRB_MAX_BUFF_SIZE 
  boundary
  Yes, you are right.
  the above is make sure trb buffer will not cross over
  TRB_MAX_BUFF_SIZE boundary.
  But it still possible to cross the page boundary for ISO trb, right?
  (suppose page boundary is 4KB, TRB_MAX_BUFF_SIZE is 64KB)
 
  appreciate your kind help,
 
 
 Hi
 
 As I understood it, it is ok to cross page boundaries as long as the buffer 
 is physically contiguous.
 As our dma case should be.
 xhci specification section 3.2.8 says that:
 
 Note that no constraints are placed on the TRB Length fields in a 
 Scatter/Gather list. Classically
 all the
 buffers pointed to by a scatter gather list were required to be “page size” 
 in length except for the
 first and
 last (as illustrated by the example above). The xHCI does not require this 
 constraint. Any buffer
 pointed to
 by a Normal, Data Stage, or Isoch TRB in a TD may be any size between 0 and 
 64K bytes in size. For
 instance, if when an OS translates a virtual memory buffer into a list of 
 physical pages, some of the
 entries
 in the list reference multiple contiguous pages, the flexible Length fields 
 of TRBs allow a 1:1
 mapping of list
 entries to TRBs, i.e. a multi-page list entry does not need to be defined as 
 multiple page sized
 TRBs.
 

The ohci hardware requires that scatter-gather boundaries occur on USB message 
boundaries.

The xhi hardware doesn't have that constraint, but has the different 
constraints:
1) A buffer must not cross a 64k address boundary.
2) A LINK TRB (at the end of the ring) must only occur at a USB message boundary
   (actually it is a slightly tighter constraint).
In combination those two are a PITA.

David

N�r��yb�X��ǧv�^�)޺{.n�+{��^n�r���z���h����G���h�(�階�ݢj���m��z�ޖ���f���h���~�m�

Re: [PATCH 1/2] arm: shimobile: r8a7790: add HS-USB device node

2014-10-03 Thread Sergei Shtylyov

Hello.

On 10/02/2014 12:04 PM, Yoshihiro Shimoda wrote:


Signed-off-by: Yoshihiro Shimoda yoshihiro.shimoda...@renesas.com


   The subject has shimobile instead of shmobile on both this and R8A7791 
patch. And capitalize arm: please on all the patches.


WBR, Sergei

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


[PATCH] USB: serial: cp210x: Add Silicon Labs 358x VID and PID.

2014-10-03 Thread Nathaniel Ting
From: Nathaniel Ting nathaniel.t...@silabs.com

Enable Silicon Labs Ember VID chips to enumerate with the cp210x usb serial
driver. EM358x devices operating with the Ember Z-Net 5.1.2 stack may now
connect to host PCs over a USB serial link.

Signed-off-by: Nathaniel Ting nathaniel.t...@silabs.com
---
 drivers/usb/serial/cp210x.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/usb/serial/cp210x.c b/drivers/usb/serial/cp210x.c
index e4bb622..ce81fa8 100644
--- a/drivers/usb/serial/cp210x.c
+++ b/drivers/usb/serial/cp210x.c
@@ -154,6 +154,7 @@ static const struct usb_device_id id_table[] = {
{ USB_DEVICE(0x18EF, 0xE00F) }, /* ELV USB-I2C-Interface */
{ USB_DEVICE(0x1ADB, 0x0001) }, /* Schweitzer Engineering C662 Cable */
{ USB_DEVICE(0x1B1C, 0x1C00) }, /* Corsair USB Dongle */
+{ USB_DEVICE(0x1BA4, 0x0002) }, /* Silicon Labs 358x factory default */
{ USB_DEVICE(0x1BE3, 0x07A6) }, /* WAGO 750-923 USB Service Cable */
{ USB_DEVICE(0x1E29, 0x0102) }, /* Festo CPX-USB */
{ USB_DEVICE(0x1E29, 0x0501) }, /* Festo CMSP */
-- 
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: serial: cp210x: Add Silicon Labs 358x VID and PID.

2014-10-03 Thread Greg KH
On Fri, Oct 03, 2014 at 11:06:33AM -0400, Nathaniel Ting wrote:
 From: Nathaniel Ting nathaniel.t...@silabs.com
 
 Enable Silicon Labs Ember VID chips to enumerate with the cp210x usb serial
 driver. EM358x devices operating with the Ember Z-Net 5.1.2 stack may now
 connect to host PCs over a USB serial link.
 
 Signed-off-by: Nathaniel Ting nathaniel.t...@silabs.com
 ---
  drivers/usb/serial/cp210x.c | 1 +
  1 file changed, 1 insertion(+)
 
 diff --git a/drivers/usb/serial/cp210x.c b/drivers/usb/serial/cp210x.c
 index e4bb622..ce81fa8 100644
 --- a/drivers/usb/serial/cp210x.c
 +++ b/drivers/usb/serial/cp210x.c
 @@ -154,6 +154,7 @@ static const struct usb_device_id id_table[] = {
   { USB_DEVICE(0x18EF, 0xE00F) }, /* ELV USB-I2C-Interface */
   { USB_DEVICE(0x1ADB, 0x0001) }, /* Schweitzer Engineering C662 Cable */
   { USB_DEVICE(0x1B1C, 0x1C00) }, /* Corsair USB Dongle */
 +{ USB_DEVICE(0x1BA4, 0x0002) }, /* Silicon Labs 358x factory default 
 */

Close, but if you ran your patch through checkpatch.pl you would see
that you used spaces instead of tabs for indentation.

At least the tabs on the other lines came through correctly, which is
good.

Care to fix this up and try again?

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


[PATCH] USB: serial: cp210x: Add Silicon Labs 358x VID and PID.

2014-10-03 Thread Nathaniel Ting
From: Nathaniel Ting nathaniel.t...@silabs.com

Enable Silicon Labs Ember VID chips to enumerate with the cp210x usb serial
driver. EM358x devices operating with the Ember Z-Net 5.1.2 stack may now
connect to host PCs over a USB serial link.

Signed-off-by: Nathaniel Ting nathaniel.t...@silabs.com
---
 drivers/usb/serial/cp210x.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/usb/serial/cp210x.c b/drivers/usb/serial/cp210x.c
index e4bb622..ab1eb9b 100644
--- a/drivers/usb/serial/cp210x.c
+++ b/drivers/usb/serial/cp210x.c
@@ -154,6 +154,7 @@ static const struct usb_device_id id_table[] = {
{ USB_DEVICE(0x18EF, 0xE00F) }, /* ELV USB-I2C-Interface */
{ USB_DEVICE(0x1ADB, 0x0001) }, /* Schweitzer Engineering C662 Cable */
{ USB_DEVICE(0x1B1C, 0x1C00) }, /* Corsair USB Dongle */
+   { USB_DEVICE(0x1BA4, 0x0002) }, /* Silicon Labs 358x factory default */
{ USB_DEVICE(0x1BE3, 0x07A6) }, /* WAGO 750-923 USB Service Cable */
{ USB_DEVICE(0x1E29, 0x0102) }, /* Festo CPX-USB */
{ USB_DEVICE(0x1E29, 0x0501) }, /* Festo CMSP */
-- 
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: serial: cp210x: Add Silicon Labs 358x VID and PID.

2014-10-03 Thread Greg KH
On Fri, Oct 03, 2014 at 12:01:20PM -0400, Nathaniel Ting wrote:
 From: Nathaniel Ting nathaniel.t...@silabs.com
 
 Enable Silicon Labs Ember VID chips to enumerate with the cp210x usb serial
 driver. EM358x devices operating with the Ember Z-Net 5.1.2 stack may now
 connect to host PCs over a USB serial link.
 
 Signed-off-by: Nathaniel Ting nathaniel.t...@silabs.com
 ---
  drivers/usb/serial/cp210x.c | 1 +
  1 file changed, 1 insertion(+)
 
 diff --git a/drivers/usb/serial/cp210x.c b/drivers/usb/serial/cp210x.c
 index e4bb622..ab1eb9b 100644
 --- a/drivers/usb/serial/cp210x.c
 +++ b/drivers/usb/serial/cp210x.c
 @@ -154,6 +154,7 @@ static const struct usb_device_id id_table[] = {
   { USB_DEVICE(0x18EF, 0xE00F) }, /* ELV USB-I2C-Interface */
   { USB_DEVICE(0x1ADB, 0x0001) }, /* Schweitzer Engineering C662 Cable */
   { USB_DEVICE(0x1B1C, 0x1C00) }, /* Corsair USB Dongle */
 + { USB_DEVICE(0x1BA4, 0x0002) }, /* Silicon Labs 358x factory default */
   { USB_DEVICE(0x1BE3, 0x07A6) }, /* WAGO 750-923 USB Service Cable */
   { USB_DEVICE(0x1E29, 0x0102) }, /* Festo CPX-USB */
   { USB_DEVICE(0x1E29, 0x0501) }, /* Festo CMSP */
 -- 
 1.9.1

Much better, thanks.

Johan will queue this up to his tree in a bit and will then send it on
to me.

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 v6 1/4] mfd: add support for Diolan DLN-2 devices

2014-10-03 Thread Johan Hovold
On Thu, Sep 25, 2014 at 07:07:31PM +0300, Octavian Purdila wrote:
 This patch implements the USB part of the Diolan USB-I2C/SPI/GPIO
 Master Adapter DLN-2. Details about the device can be found here:
 
 https://www.diolan.com/i2c/i2c_interface.html.
 
 Information about the USB protocol can be found in the Programmer's
 Reference Manual [1], see section 1.7.
 
 Because the hardware has a single transmit endpoint and a single
 receive endpoint the communication between the various DLN2 drivers
 and the hardware will be muxed/demuxed by this driver.
 
 Each DLN2 module will be identified by the handle field within the DLN2
 message header. If a DLN2 module issues multiple commands in parallel
 they will be identified by the echo counter field in the message header.
 
 The DLN2 modules can use the dln2_transfer() function to issue a
 command and wait for its response. They can also register a callback
 that is going to be called when a specific event id is generated by
 the device (e.g. GPIO interrupts). The device uses handle 0 for
 sending events.
 
 [1] https://www.diolan.com/downloads/dln-api-manual.pdf
 
 Signed-off-by: Octavian Purdila octavian.purd...@intel.com
 ---
  drivers/mfd/Kconfig  |   9 +
  drivers/mfd/Makefile |   1 +
  drivers/mfd/dln2.c   | 751 
 +++
  include/linux/mfd/dln2.h |  67 +
  4 files changed, 828 insertions(+)
  create mode 100644 drivers/mfd/dln2.c
  create mode 100644 include/linux/mfd/dln2.h

[...]

 +#define DLN2_HW_ID   0x200
 +#define DLN2_USB_TIMEOUT 200 /* in ms */
 +#define DLN2_MAX_RX_SLOTS16
 +#define DLN2_MAX_URBS16
 +#define DLN2_RX_BUF_SIZE 512
 +
 +enum dln2_handle {
 + DLN2_HANDLE_EVENT,

This is the only handle that was fixed (0), right? Initialise this one
explicitly in case any one ever tries to reorder them.

 + DLN2_HANDLE_CTRL,
 + DLN2_HANDLE_GPIO,
 + DLN2_HANDLE_I2C,
 + DLN2_HANDLES
 +};
 +
 +/*
 + * Receive context used between the receive demultiplexer and the
 + * transfer routine. While sending a request the transfer routine
 + * will look for a free receive context and use it to wait for a
 + * response and to receive the URB and thus the response data.
 + */
 +struct dln2_rx_context {
 + /* completion used to wait for a response */
 + struct completion done;
 +
 + /* if non-NULL the URB contains the response */
 + struct urb *urb;
 +
 + /* if true then this context is used to wait for a response */
 + bool in_use;
 +};
 +
 +/*
 + * Receive contexts for a particular DLN2 module (i2c, gpio, etc.). We
 + * use the handle header field to identify the module in
 + * dln2_dev.mod_rx_slots and then the echo header field to index the
 + * slots field and find the receive context for a particular request.
 + */
 +struct dln2_mod_rx_slots {
 + /* RX slots bitmap */
 + unsigned long bmap;
 +
 + /* used to wait for a free RX slot */
 + wait_queue_head_t wq;
 +
 + /* used to wait for an RX operation to complete */
 + struct dln2_rx_context slots[DLN2_MAX_RX_SLOTS];
 +
 + /* avoid races between alloc/free_rx_slot and dln2_rx_transfer */
 + spinlock_t lock;
 +};
 +
 +struct dln2_dev {
 + struct usb_device *usb_dev;
 + struct usb_interface *interface;
 + u8 ep_in;
 + u8 ep_out;
 +
 + struct urb *rx_urb[DLN2_MAX_URBS];
 + void *rx_buf[DLN2_MAX_URBS];
 +
 + struct dln2_mod_rx_slots mod_rx_slots[DLN2_HANDLES];
 +
 + struct list_head event_cb_list;
 + spinlock_t event_cb_lock;
 +
 + bool disconnect;
 + int active_transfers;
 + wait_queue_head_t disconnect_wq;
 + spinlock_t disconnect_lock;
 +};
 +
 +struct dln2_event_cb_entry {
 + struct list_head list;
 + u16 id;
 + struct platform_device *pdev;
 + dln2_event_cb_t callback;
 +};
 +
 +int dln2_register_event_cb(struct platform_device *pdev, u16 id,
 +dln2_event_cb_t rx_cb)
 +{
 + struct dln2_dev *dln2 = dev_get_drvdata(pdev-dev.parent);
 + struct dln2_event_cb_entry *i, *new;
 + unsigned long flags;
 + int ret = 0;
 +
 + new = kmalloc(sizeof(*new), GFP_KERNEL);
 + if (!new)
 + return -ENOMEM;
 +
 + new-id = id;
 + new-callback = rx_cb;
 + new-pdev = pdev;
 +
 + spin_lock_irqsave(dln2-event_cb_lock, flags);
 +
 + list_for_each_entry(i, dln2-event_cb_list, list) {
 + if (i-id == id) {
 + ret = -EBUSY;
 + break;
 + }
 + }
 +
 + if (!ret)
 + list_add_rcu(new-list, dln2-event_cb_list);
 +
 + spin_unlock_irqrestore(dln2-event_cb_lock, flags);
 +
 + if (ret)
 + kfree(new);
 +
 + return ret;
 +}
 +EXPORT_SYMBOL(dln2_register_event_cb);
 +
 +void dln2_unregister_event_cb(struct platform_device *pdev, u16 id)
 +{
 + struct dln2_dev *dln2 = 

Re: [PATCH 2/3] arm: shmobile: koelsch: enable HS-USB

2014-10-03 Thread Sergei Shtylyov

Hello.

On 10/02/2014 03:48 PM, Yoshihiro Shimoda wrote:


Signed-off-by: Yoshihiro Shimoda yoshihiro.shimoda...@renesas.com
---
   arch/arm/boot/dts/r8a7791-koelsch.dts |5 +
   1 file changed, 5 insertions(+)



diff --git a/arch/arm/boot/dts/r8a7791-koelsch.dts 
b/arch/arm/boot/dts/r8a7791-koelsch.dts
index 3f55c16..b3dac1a 100644
--- a/arch/arm/boot/dts/r8a7791-koelsch.dts
+++ b/arch/arm/boot/dts/r8a7791-koelsch.dts
@@ -495,3 +495,8 @@
   };
   };
   };
+
+hsusb {
+status = okay;
+renesas,enable-gpio = gpio5 18 GPIO_ACTIVE_LOW;


   Rather GPIO_ACTIVE_HIGH, I think.


I think it's GP5_31 on Koelsch instead, i.e. the ID output from MAX3355.



Thank you for the point. I will fix this.


   The same stands for Henninger BTW.

WBR, Sergei

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


Re: [PATCH 2/2] arm: shmobile: lager: enable HS-USB

2014-10-03 Thread Sergei Shtylyov

On 10/02/2014 12:04 PM, Yoshihiro Shimoda wrote:


Signed-off-by: Yoshihiro Shimoda yoshihiro.shimoda...@renesas.com
---
  arch/arm/boot/dts/r8a7790-lager.dts |5 +
  1 file changed, 5 insertions(+)



diff --git a/arch/arm/boot/dts/r8a7790-lager.dts 
b/arch/arm/boot/dts/r8a7790-lager.dts
index 1698591..4badd0a 100644
--- a/arch/arm/boot/dts/r8a7790-lager.dts
+++ b/arch/arm/boot/dts/r8a7790-lager.dts
@@ -445,3 +445,8 @@
};
};
  };
+
+hsusb {
+   status = okay;
+   renesas,enable-gpio = gpio5 18 GPIO_ACTIVE_LOW;


   It's certainly active-high.

WBR, Sergei

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


Re: bugreport: huawei_cdc_ncm control device freezes for 3-5 minutes on connect with E3276 LTE modem

2014-10-03 Thread Oliver Neukum
On Fri, 2014-10-03 at 10:01 +0200, Erik Alapää wrote:
 Workaround: Bring up the device with
 AT^NDISDUP=1,1,internet.telenor.se instead. Also worth noting is
 that AT+CGACT=1,1 does not freeze the control connection if using
 /dev/ttyUSB0.
 
 If more info is needed, let me know and I will provide it.

I suggest you take an usbmon trace to look for the CDC notification.

Regards
Oliver


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


Re: [PATCH net-next] r8152: nway reset after setting eee

2014-10-03 Thread David Miller
From: Hayes Wang hayesw...@realtek.com
Date: Thu, 2 Oct 2014 16:01:22 +0800

 @@ -3480,6 +3480,9 @@ rtl_ethtool_set_eee(struct net_device *net, struct 
 ethtool_eee *edata)
  
   ret = tp-rtl_ops.eee_set(tp, edata);
  
 + if (ret == 0)
 + ret = mii_nway_restart(tp-mii);

Please test this canonically as if (!ret) and delete the empty line between 
the function
call and the return value test.

Thank you.
--
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 2/2] uas: Make uas work with blk-mq

2014-10-03 Thread Greg Kroah-Hartman
On Fri, Oct 03, 2014 at 12:08:57PM +0200, Hans de Goede wrote:
 With uas over usb-3 the tags inside the uas iu-s must match the usb-3 stream
 ids, and those go from 1 - qdepth.
 
 Before blk-mq calling scsi_activate_tcq(sdev, qdepth) guaranteed that we would
 only get cmnd-request-tag from 0 - (qdepth - 1), and we used those as
 uas-tags / stream-ids.
 
 With blk-mq however we are guaranteed to never get more then qdepth commands
 queued at the same time, but the cmnd-request-tag values may be much larger,
 which breaks uas.
 
 This commit fixes this by generating uas tags in the 1 - qdepth range 
 ourselves
 instead of using cmnd-request-tag.
 
 While touching all involved code anyways also rename the uas_cmd_info stream
 field to uas_tag, because when using uas over usb-2 streams are not used.
 
 Cc: Christoph Hellwig h...@infradead.org
 Reported-by: Douglas Gilbert dgilb...@interlog.com
 Signed-off-by: Hans de Goede hdego...@redhat.com
 Reviewed-by: Christoph Hellwig h...@lst.de

This doesn't apply to my usb-next branch of usb.git, care to refresh it
and resend?

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 net v2] r8152: autoresume before setting MAC address

2014-10-03 Thread David Miller
From: Hayes Wang hayesw...@realtek.com
Date: Thu, 2 Oct 2014 17:03:12 +0800

 Resume the device before setting the MAC address.
 
 Signed-off-by: Hayes Wang hayesw...@realtek.com

Applied, thanks.
--
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: Question about calculate trbs in xhci

2014-10-03 Thread Paul Zimmerman
 From: linux-usb-ow...@vger.kernel.org 
 [mailto:linux-usb-ow...@vger.kernel.org] On Behalf Of David Laight
 Sent: Friday, October 03, 2014 6:08 AM
 
 From: Mathias Nyman
  On 10/01/2014 05:50 PM, vichy wrote:
   hi Mathias:
  
  
   In xhci-ring.c,  static int xhci_queue_isoc_tx():
  
   /* Calculate TRB length */
 trb_buff_len = TRB_MAX_BUFF_SIZE - (addr  ((1  TRB_MAX_BUFF_SHIFT) 
   - 1));
  
   where  addr = start_addr + urb-iso_frame_desc[i].offset;
  
   this limits the trb_buff_len to stop the trb buffer at TRB_MAX_BUFF_SIZE 
   boundary
   Yes, you are right.
   the above is make sure trb buffer will not cross over
   TRB_MAX_BUFF_SIZE boundary.
   But it still possible to cross the page boundary for ISO trb, right?
   (suppose page boundary is 4KB, TRB_MAX_BUFF_SIZE is 64KB)
  
   appreciate your kind help,
  
 
  Hi
 
  As I understood it, it is ok to cross page boundaries as long as the buffer 
  is physically contiguous.
  As our dma case should be.
  xhci specification section 3.2.8 says that:
 
  Note that no constraints are placed on the TRB Length fields in a 
  Scatter/Gather list. Classically
  all the
  buffers pointed to by a scatter gather list were required to be “page size” 
  in length except for the
  first and
  last (as illustrated by the example above). The xHCI does not require this 
  constraint. Any buffer
  pointed to
  by a Normal, Data Stage, or Isoch TRB in a TD may be any size between 0 and 
  64K bytes in size. For
  instance, if when an OS translates a virtual memory buffer into a list of 
  physical pages, some of the
  entries
  in the list reference multiple contiguous pages, the flexible Length fields 
  of TRBs allow a 1:1
  mapping of list
  entries to TRBs, i.e. a multi-page list entry does not need to be defined 
  as multiple page sized
  TRBs.
  
 
 The ohci hardware requires that scatter-gather boundaries occur on USB 
 message boundaries.
 
 The xhi hardware doesn't have that constraint, but has the different 
 constraints:
 1) A buffer must not cross a 64k address boundary.
 2) A LINK TRB (at the end of the ring) must only occur at a USB message 
 boundary
(actually it is a slightly tighter constraint).
 In combination those two are a PITA.

Hi David,

May I ask where in the xHCI spec is 2) stated? I'm not finding it
(looking at Revision 1.0 with errata to 7/12/12).

I can't find message boundary anywhere in the spec. Did you mean packet
boundary?

If so, there is some text in the spec which contradicts that. In 4.11.7.1,
it says:

In Figure 26 the IOC flag only may be set in TRBs 5 and 10 ...
 Note that THE LINK TRB DOES NOT LAND ON A PACKET BOUNDARY relative
 to the start of TD Fragment 1, so its IOC flag may not be set.

(emphasis mine)

-- 
Paul

N�r��yb�X��ǧv�^�)޺{.n�+{��^n�r���z���h����G���h�(�階�ݢj���m��z�ޖ���f���h���~�m�

Re: [PATCH 1/1] usb: chipidea: Fix oops when removing the ci_hdrc module

2014-10-03 Thread Peter Chen
On Fri, Oct 03, 2014 at 11:01:20AM +0200, Torsten Fleischer wrote:
 The call of 'kfree(ci-hw_bank.regmap)' in ci_hdrc_remove() sometimes causes
 a kernel oops when removing the ci_hdrc module.
 
 Since there is no separate memory allocated for the ci-hw_bank.regmap array,
 there is no need to free it.
 
 Signed-off-by: Torsten Fleischer to-fleisc...@t-online.de
 ---
  drivers/usb/chipidea/core.c | 1 -
  1 file changed, 1 deletion(-)
 
 diff --git a/drivers/usb/chipidea/core.c b/drivers/usb/chipidea/core.c
 index 619d13e..4ecb650 100644
 --- a/drivers/usb/chipidea/core.c
 +++ b/drivers/usb/chipidea/core.c
 @@ -732,7 +732,6 @@ static int ci_hdrc_remove(struct platform_device *pdev)
   ci_role_destroy(ci);
   ci_hdrc_enter_lpm(ci, true);
   usb_phy_shutdown(ci-transceiver);
 - kfree(ci-hw_bank.regmap);
  
   return 0;
  }
 -- 
 1.8.4.5
 

Good fix, applied, thanks.

-- 
Best Regards,
Peter Chen
--
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