Re: [PATCH] phy: phy-mt65xx-usb3: fix test fail of HS receiver sensitivity

[chunfeng yun]

Hi,
On Mon, 2015-11-16 at 22:16 -0800, Greg KH wrote:
> On Tue, Nov 17, 2015 at 02:02:58PM +0800, Chunfeng Yun wrote:
> > when use the default value 8 of RG_USB20_SQTH, the HS receiver
> > sensitivity test of HQA will fail, set it as 2 to fix up the
> > issue.
> > 
> > Change-Id: Ia5bdbbfc8ebb170d3ef26007e665b7350b6d28ab
> 
> What is this field for?  Hint, it should never be there for a patch you
> submit upstream as it means nothing...
> 
I'm sorry for forgetting remove it. 
And I will remove change-id in next round after review

Thanks a lot

> 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 v4 04/12] usb: xhci: dbc: add support for Intel xHCI dbc quirk

[Lu Baolu]

On Intel platforms, if the debug target is connected with debug
host, enabling DCE bit in command register leads to a port hung
state. In the hung state, the host system will not see a port
connected status bit set. Hence debug target fails to be probed.

The state could be resolved by performing a port reset to the
debug port from the host xHCI. This patch introduces this work
around.

Signed-off-by: Lu Baolu 
---
 drivers/usb/early/xhci-dbc.c | 52 
 include/linux/usb/xhci-dbc.h |  2 ++
 2 files changed, 54 insertions(+)

diff --git a/drivers/usb/early/xhci-dbc.c b/drivers/usb/early/xhci-dbc.c
index 22a1de9..6b23f09 100644
--- a/drivers/usb/early/xhci-dbc.c
+++ b/drivers/usb/early/xhci-dbc.c
@@ -255,6 +255,8 @@ static void __iomem *xdbc_map_pci_mmio(u32 bus,
xdbcp->bar = bar;
xdbcp->xhci_base = base;
xdbcp->xhci_length = sz64;
+   xdbcp->vendor = read_pci_config_16(bus, dev, func, PCI_VENDOR_ID);
+   xdbcp->device = read_pci_config_16(bus, dev, func, PCI_DEVICE_ID);
 
if (length)
*length = sz64;
@@ -651,6 +653,52 @@ static int xdbc_mem_init(void)
return 0;
 }
 
+static void xdbc_reset_debug_port_callback(int cap_offset, void *data)
+{
+   u8 major;
+   u32 val, port_offset, port_count;
+   u32 cap_length;
+   void __iomem *ops_reg;
+   void __iomem *portsc;
+   int i;
+
+   val = readl(xdbcp->xhci_base + cap_offset);
+   major = (u8) XHCI_EXT_PORT_MAJOR(val);
+
+   /* only reset super-speed port */
+   if (major != 0x3)
+   return;
+
+   val = readl(xdbcp->xhci_base + cap_offset + 8);
+   port_offset = XHCI_EXT_PORT_OFF(val);
+   port_count = XHCI_EXT_PORT_COUNT(val);
+   xdbc_trace("Extcap Port offset %d count %d\n",
+   port_offset, port_count);
+
+   cap_length = readl(xdbcp->xhci_base) & 0xff;
+   ops_reg = xdbcp->xhci_base + cap_length;
+
+   port_offset--;
+   for (i = port_offset; i < (port_offset + port_count); i++) {
+   portsc = ops_reg + 0x400 + i * 0x10;
+   val = readl(portsc);
+   /* reset the port if CCS bit is cleared */
+   if (!(val & 0x1))
+   writel(val | (1 << 4), portsc);
+   }
+}
+
+static void xdbc_reset_debug_port(void)
+{
+   xdbc_walk_excap(xdbcp->bus,
+   xdbcp->dev,
+   xdbcp->func,
+   XHCI_EXT_CAPS_PROTOCOL,
+   false,
+   xdbc_reset_debug_port_callback,
+   NULL);
+}
+
 /*
  * xdbc_start: start DbC
  *
@@ -669,6 +717,10 @@ static int xdbc_start(void)
return -ENODEV;
}
 
+   /* reset port to avoid bus hang */
+   if (xdbcp->vendor == PCI_VENDOR_ID_INTEL)
+   xdbc_reset_debug_port();
+
/* wait for port connection */
if (handshake(&xdbcp->xdbc_reg->portsc, PORTSC_CCS,
PORTSC_CCS, 500, 100) < 0) {
diff --git a/include/linux/usb/xhci-dbc.h b/include/linux/usb/xhci-dbc.h
index 153fb87..fc0ef9a 100644
--- a/include/linux/usb/xhci-dbc.h
+++ b/include/linux/usb/xhci-dbc.h
@@ -128,6 +128,8 @@ struct xdbc_state {
u32 dev;
u32 func;
u8  bar;
+   u16 vendor;
+   u16 device;
void __iomem*xhci_base;
size_t  xhci_length;
 #defineXDBC_PCI_MAX_BUSES  256
-- 
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 v4 00/12] usb: early: add support for early printk through USB3 debug port

[Lu Baolu]

Hi,

This patch series adds support for early printk through USB3 debug port.
USB3 debug port is described in xHCI specification as an optional extended
capability.

The first patch adds a file in sysfs, through which users can check
whether the debug capability is supported by a specific host controller,
and the hardware state.

Patch 2 to 10 add the driver for xHCI debug capability. It interfaces with
the register set and provides the required ops (read/write/control) to upper
layers. Early printk is one consumer of these ops. The hooks for early printk
are introduced in patch 9. This design is similar to what we have done in
drivers/usb/early/ehci-dbgp.c.

Patch 11 is a minor change to usb_debug module. This change is required to
bind usb_debug with the USB3 debug device.

Patch 12 is the design document and user guide.

Change log:
v1->v2:
(1) Patch 1 re-implemented. "debugfs" has been replaced with sysfs.
The scope reduced from all extended capabilities to debug port
specific.
(2) Patch 11 changed. Removed unnecessary .bulk_out_size setting.

v2->v3:
(1) Patch 11 got acked by Johan Hovold.

v3->v4:
(1) Patch 1 code refactored by using xhci_find_ext_cap_by_id() helper.
(2) Patch 3 "bus hung state" changed to "port hung state" in commit message.
(3) Patch 12 added verified platform information.

Lu Baolu (12):
  usb: xhci: add sysfs file for xHCI debug port
  x86: fixmap: add permanent fixmap for xhci debug port
  usb: xhci: dbc: probe and setup xhci debug capability
  usb: xhci: dbc: add support for Intel xHCI dbc quirk
  usb: xhci: dbc: add debug buffer
  usb: xhci: dbc: add bulk out and bulk in interfaces
  usb: xhci: dbc: handle dbc-configured exit
  usb: xhci: dbc: handle endpoint stall
  x86: early_printk: add USB3 debug port earlyprintk support
  usb: xhci: dbc: add handshake between debug target and host
  usb: serial: usb_debug: add support for dbc debug device
  usb: doc: add document for xHCI DbC driver

 .../ABI/testing/sysfs-bus-pci-drivers-xhci_hcd |   23 +
 Documentation/kernel-parameters.txt|1 +
 Documentation/usb/xhci-dbc.txt |  325 +
 MAINTAINERS|8 +
 arch/x86/Kconfig.debug |   12 +
 arch/x86/include/asm/fixmap.h  |4 +
 arch/x86/kernel/early_printk.c |5 +
 drivers/usb/early/Makefile |1 +
 drivers/usb/early/xhci-dbc.c   | 1407 
 drivers/usb/host/Makefile  |2 +-
 drivers/usb/host/xhci-ext-caps.h   |   14 +-
 drivers/usb/host/xhci-sysfs.c  |   80 ++
 drivers/usb/host/xhci.c|4 +
 drivers/usb/host/xhci.h|4 +
 drivers/usb/serial/usb_debug.c |   28 +-
 include/linux/usb/xhci-dbc.h   |  224 
 16 files changed, 2137 insertions(+), 5 deletions(-)
 create mode 100644 Documentation/ABI/testing/sysfs-bus-pci-drivers-xhci_hcd
 create mode 100644 Documentation/usb/xhci-dbc.txt
 create mode 100644 drivers/usb/early/xhci-dbc.c
 create mode 100644 drivers/usb/host/xhci-sysfs.c
 create mode 100644 include/linux/usb/xhci-dbc.h

Thanks,
-Baolu
-- 
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 v4 01/12] usb: xhci: add sysfs file for xHCI debug port

[Lu Baolu]

This patch adds a sysfs file for users to check 1) whether the debug
capability is implemented by hardware; 2) if supported, which state
does it stay at.

With a host that supports debug port, a file named "debug_port_state"
will be created under the device sysfs directory. Reading this file
will show users the state (disabled, enabled or configured) of the
debug port.

With a host that does NOT support debug port, "debug_port_state" file
won't be created.

Signed-off-by: Lu Baolu 
---
 .../ABI/testing/sysfs-bus-pci-drivers-xhci_hcd | 23 +++
 drivers/usb/host/Makefile  |  2 +-
 drivers/usb/host/xhci-ext-caps.h   | 14 +++-
 drivers/usb/host/xhci-sysfs.c  | 80 ++
 drivers/usb/host/xhci.c|  4 ++
 drivers/usb/host/xhci.h|  4 ++
 6 files changed, 125 insertions(+), 2 deletions(-)
 create mode 100644 Documentation/ABI/testing/sysfs-bus-pci-drivers-xhci_hcd
 create mode 100644 drivers/usb/host/xhci-sysfs.c

diff --git a/Documentation/ABI/testing/sysfs-bus-pci-drivers-xhci_hcd 
b/Documentation/ABI/testing/sysfs-bus-pci-drivers-xhci_hcd
new file mode 100644
index 000..dd3e722
--- /dev/null
+++ b/Documentation/ABI/testing/sysfs-bus-pci-drivers-xhci_hcd
@@ -0,0 +1,23 @@
+What:  /sys/bus/pci/drivers/xhci_hcd/.../debug_port_state
+Date:  November 2015
+KernelVersion: 4.3.0
+Contact:   Lu Baolu 
+Description:
+   This file is designed for users to check the state of a
+   USB3 debug port. On a machine which supports USB3 debug
+   port, this file will be created. Reading this file will
+   show the state (disabled, enabled or configured) of the
+   debug port. On a machine that doesn't support USB3 debug
+   port, this file doesn't exist.
+
+   The state of a debug port could be:
+   1) disabled: The debug port is not enabled and the root
+   port has been switched to xHCI host as a normal
+   root port.
+   2) enabled: The debug port is enabled. The debug port
+   has been assigned to debug capability. The debug
+   capability is able to handle the control requests
+   defined in USB3 spec.
+   3) configured: The debug port has been enumerated by the
+   debug host as a debug device. The debug port is
+   in use now.
diff --git a/drivers/usb/host/Makefile b/drivers/usb/host/Makefile
index e7558ab..810c304 100644
--- a/drivers/usb/host/Makefile
+++ b/drivers/usb/host/Makefile
@@ -12,7 +12,7 @@ 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-y += xhci-trace.o xhci-sysfs.o
 
 xhci-plat-hcd-y := xhci-plat.o
 ifneq ($(CONFIG_USB_XHCI_MVEBU), )
diff --git a/drivers/usb/host/xhci-ext-caps.h b/drivers/usb/host/xhci-ext-caps.h
index 9fe3225..12c87e5 100644
--- a/drivers/usb/host/xhci-ext-caps.h
+++ b/drivers/usb/host/xhci-ext-caps.h
@@ -49,8 +49,15 @@
 #define XHCI_EXT_CAPS_PM   3
 #define XHCI_EXT_CAPS_VIRT 4
 #define XHCI_EXT_CAPS_ROUTE5
-/* IDs 6-9 reserved */
+#define XHCI_EXT_CAPS_LOCALMEM 6
+/* IDs 7-9 reserved */
 #define XHCI_EXT_CAPS_DEBUG10
+/* IDs 192-255 vendor specific */
+#define XHCI_EXT_CAPS_VEN_START192
+#define XHCI_EXT_CAPS_VEN_END  255
+#define XHCI_EXT_CAPS_VENDOR(p)(((p) >= XHCI_EXT_CAPS_VEN_START) && \
+   ((p) <= XHCI_EXT_CAPS_VEN_END))
+#define XHCI_EXT_MAX_CAPID XHCI_EXT_CAPS_VEN_END
 /* USB Legacy Support Capability - section 7.1.1 */
 #define XHCI_HC_BIOS_OWNED (1 << 16)
 #define XHCI_HC_OS_OWNED   (1 << 24)
@@ -73,6 +80,11 @@
 #define XHCI_HLC   (1 << 19)
 #define XHCI_BLC   (1 << 20)
 
+/* Debug capability - section 7.6.8 */
+#define XHCI_DBC_DCCTRL0x20
+#define XHCI_DBC_DCCTRL_DCR(1 << 0)
+#defineXHCI_DBC_DCCTRL_DCE (1 << 31)
+
 /* command register values to disable interrupts and halt the HC */
 /* start/stop HC execution - do not write unless HC is halted*/
 #define XHCI_CMD_RUN   (1 << 0)
diff --git a/drivers/usb/host/xhci-sysfs.c b/drivers/usb/host/xhci-sysfs.c
new file mode 100644
index 000..365858f
--- /dev/null
+++ b/drivers/usb/host/xhci-sysfs.c
@@ -0,0 +1,80 @@
+/*
+ * sysfs interface for xHCI host controller driver
+ *
+ * Copyright (C) 2015 Intel Corp.
+ *
+ * Author: Lu Baolu 
+ *
+ * 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 "xhci.h"
+
+/*
+ * Return the register offset of a extended capability specified
+ * by @cap_id. Return 0 if @cap_id capabil

[PATCH v4 03/12] usb: xhci: dbc: probe and setup xhci debug capability

[Lu Baolu]

xHCI debug capability (DbC) is an optional functionality provided
by an xHCI host controller. Software learns this capability by
walking through the extended capability list in mmio of the host.

This patch introduces the code to probe and initialize the debug
capability hardware during early boot. With hardware initialization
done, the debug target (system under debug which has DbC enabled)
will present a debug device through the debug port. The debug device
is fully compliant with the USB framework and provides the equivalent
of a very high performance (USB3) full-duplex serial link between the
debug host and target.

Signed-off-by: Lu Baolu 
---
 MAINTAINERS  |   7 +
 arch/x86/Kconfig.debug   |  12 +
 drivers/usb/early/Makefile   |   1 +
 drivers/usb/early/xhci-dbc.c | 787 +++
 include/linux/usb/xhci-dbc.h | 187 ++
 5 files changed, 994 insertions(+)
 create mode 100644 drivers/usb/early/xhci-dbc.c
 create mode 100644 include/linux/usb/xhci-dbc.h

diff --git a/MAINTAINERS b/MAINTAINERS
index e9caa4b..3d7e0cf 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -11250,6 +11250,13 @@ S: Supported
 F: drivers/usb/host/xhci*
 F: drivers/usb/host/pci-quirks*
 
+USB XHCI DEBUG PORT
+M: Lu Baolu 
+L: linux-usb@vger.kernel.org
+S: Supported
+F: drivers/usb/early/xhci-dbc.c
+F: include/linux/usb/xhci-dbc.h
+
 USB ZD1201 DRIVER
 L: linux-wirel...@vger.kernel.org
 W: http://linux-lc100020.sourceforge.net
diff --git a/arch/x86/Kconfig.debug b/arch/x86/Kconfig.debug
index 137dfa9..e450f88 100644
--- a/arch/x86/Kconfig.debug
+++ b/arch/x86/Kconfig.debug
@@ -65,6 +65,18 @@ config EARLY_PRINTK_EFI
  This is useful for kernel debugging when your machine crashes very
  early before the console code is initialized.
 
+config EARLY_PRINTK_XDBC
+   bool "Early printk via xHCI debug port"
+   depends on EARLY_PRINTK && PCI
+   ---help---
+ Write kernel log output directly into the xHCI debug port.
+
+ This is useful for kernel debugging when your machine crashes very
+ early before the console code is initialized. For normal operation
+ it is not recommended because it looks ugly and doesn't cooperate
+ with klogd/syslogd or the X server. You should normally N here,
+ unless you want to debug such a crash.
+
 config X86_PTDUMP_CORE
def_bool n
 
diff --git a/drivers/usb/early/Makefile b/drivers/usb/early/Makefile
index 24bbe51..2db5906 100644
--- a/drivers/usb/early/Makefile
+++ b/drivers/usb/early/Makefile
@@ -3,3 +3,4 @@
 #
 
 obj-$(CONFIG_EARLY_PRINTK_DBGP) += ehci-dbgp.o
+obj-$(CONFIG_EARLY_PRINTK_XDBC) += xhci-dbc.o
diff --git a/drivers/usb/early/xhci-dbc.c b/drivers/usb/early/xhci-dbc.c
new file mode 100644
index 000..22a1de9
--- /dev/null
+++ b/drivers/usb/early/xhci-dbc.c
@@ -0,0 +1,787 @@
+/**
+ * xhci-dbc.c - xHCI debug capability driver
+ *
+ * Copyright (C) 2015 Intel Corporation
+ *
+ * Author: Lu Baolu 
+ * Some code shared with EHCI debug port and xHCI driver.
+ *
+ * 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 "../host/xhci.h"
+
+#defineXDBC_PROTOCOL   1   /* GNU Remote Debug Command Set 
*/
+#defineXDBC_VENDOR_ID  0x1d6b  /* Linux Foundation 0x1d6b */
+#defineXDBC_PRODUCT_ID 0x0004  /* __le16 idProduct; device 
0004 */
+#defineXDBC_DEVICE_REV 0x0010  /* 0.10 */
+
+static struct xdbc_state xdbc_stat;
+static struct xdbc_state *xdbcp = &xdbc_stat;
+
+#ifdef DBC_DEBUG
+/* place holder */
+#definexdbc_trace  printk
+static void xdbc_dbg_dump_regs(char *str)
+{
+   if (!xdbcp->xdbc_reg) {
+   xdbc_trace("register not mapped\n");
+   return;
+   }
+
+   xdbc_trace("XDBC registers: %s\n", str);
+   xdbc_trace("  Capability: %08x\n",
+   readl(&xdbcp->xdbc_reg->capability));
+   xdbc_trace("  Door bell: %08x\n",
+   readl(&xdbcp->xdbc_reg->doorbell));
+   xdbc_trace("  Event Ring Segment Table Size: %08x\n",
+   readl(&xdbcp->xdbc_reg->ersts));
+   xdbc_trace("  Event Ring Segment Table Base Address: %16llx\n",
+   xdbc_read64(&xdbcp->xdbc_reg->erstba));
+   xdbc_trace("  Event Ring Dequeue Pointer: %16llx\n",
+   xdbc_read64(&xdbcp->xdbc_reg->erdp));
+   xdbc_trace("  Port status and control: %08x\n",
+   readl(&xdbcp->xdbc_reg->portsc));
+   xdbc_trace("  Debug Capability Context Pointer: %16llx\n",
+   xdbc_read64(&xdbcp->xdbc_reg->dccp));
+   xdbc_trace("  Device Descriptor Info Re

[PATCH v4 02/12] x86: fixmap: add permanent fixmap for xhci debug port

[Lu Baolu]

xHCI compatible USB3 host controller may provide debug capability
which enables low-level system debug over USB. In order to probing
this debug capability, Linux kernel needs to map and access the
mmio of the host controller during early boot.

This patch adds permenent fixmap pages in fixed_addresses table for
xHCI mmio access.

Signed-off-by: Lu Baolu 
---
 arch/x86/include/asm/fixmap.h | 4 
 1 file changed, 4 insertions(+)

diff --git a/arch/x86/include/asm/fixmap.h b/arch/x86/include/asm/fixmap.h
index f80d700..fbf452f 100644
--- a/arch/x86/include/asm/fixmap.h
+++ b/arch/x86/include/asm/fixmap.h
@@ -82,6 +82,10 @@ enum fixed_addresses {
 #ifdef CONFIG_PROVIDE_OHCI1394_DMA_INIT
FIX_OHCI1394_BASE,
 #endif
+#ifdef CONFIG_EARLY_PRINTK_XDBC
+   FIX_XDBC_BASE,
+   FIX_XDBC_END = FIX_XDBC_BASE + 15,
+#endif
 #ifdef CONFIG_X86_LOCAL_APIC
FIX_APIC_BASE,  /* local (CPU) APIC) -- required for SMP or not */
 #endif
-- 
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 v4 06/12] usb: xhci: dbc: add bulk out and bulk in interfaces

[Lu Baolu]

This patch adds interfaces for bulk out and bulk in ops. These
interfaces could be used to implement early printk bootconsole
or hook to various system debuggers.

Signed-off-by: Lu Baolu 
---
 drivers/usb/early/xhci-dbc.c | 373 +++
 include/linux/usb/xhci-dbc.h |  30 
 2 files changed, 403 insertions(+)

diff --git a/drivers/usb/early/xhci-dbc.c b/drivers/usb/early/xhci-dbc.c
index b36a527..f51daa4 100644
--- a/drivers/usb/early/xhci-dbc.c
+++ b/drivers/usb/early/xhci-dbc.c
@@ -219,11 +219,21 @@ static void xdbc_dbg_dump_data(char *str)
xdbc_dbg_dump_string("String Descriptor:");
 }
 
+static void xdbc_dbg_dump_trb(struct xdbc_trb *trb, char *str)
+{
+   xdbc_trace("DBC trb: %s\n", str);
+   xdbc_trace("@%016llx %08x %08x %08x %08x\n", (u64)__pa(trb),
+   le32_to_cpu(trb->field[0]),
+   le32_to_cpu(trb->field[1]),
+   le32_to_cpu(trb->field[2]),
+   le32_to_cpu(trb->field[3]));
+}
 #else
 static inline void xdbc_trace(const char *fmt, ...) { }
 static inline void xdbc_dump_debug_buffer(void) { }
 static inline void xdbc_dbg_dump_regs(char *str) { }
 static inline void xdbc_dbg_dump_data(char *str) { }
+static inline void xdbc_dbg_dump_trb(struct xdbc_trb *trb, char *str) { }
 #endif /* DBC_DEBUG */
 
 /*
@@ -334,6 +344,7 @@ static void *xdbc_get_page(dma_addr_t *dma_addr,
static char in_ring_page[PAGE_SIZE] __aligned(PAGE_SIZE);
static char out_ring_page[PAGE_SIZE] __aligned(PAGE_SIZE);
static char table_page[PAGE_SIZE] __aligned(PAGE_SIZE);
+   static char bulk_buf_page[PAGE_SIZE] __aligned(PAGE_SIZE);
 
switch (type) {
case XDBC_PAGE_EVENT:
@@ -348,6 +359,9 @@ static void *xdbc_get_page(dma_addr_t *dma_addr,
case XDBC_PAGE_TABLE:
virt = (void *)table_page;
break;
+   case XDBC_PAGE_BUFFER:
+   virt = (void *)bulk_buf_page;
+   break;
default:
return NULL;
}
@@ -707,6 +721,12 @@ static int xdbc_mem_init(void)
dev_info = cpu_to_le32((XDBC_DEVICE_REV << 16) | XDBC_PRODUCT_ID);
writel(dev_info, &xdbcp->xdbc_reg->devinfo2);
 
+   /* get and store the transfer buffer */
+   xdbcp->out_buf = xdbc_get_page(&xdbcp->out_dma,
+   XDBC_PAGE_BUFFER);
+   xdbcp->in_buf = xdbcp->out_buf + XDBC_MAX_PACKET;
+   xdbcp->in_dma = xdbcp->out_dma + XDBC_MAX_PACKET;
+
return 0;
 }
 
@@ -802,6 +822,9 @@ static int xdbc_start(void)
 
xdbc_trace("root hub port number %d\n", DCST_DPN(status));
 
+   xdbcp->in_ep_state = EP_RUNNING;
+   xdbcp->out_ep_state = EP_RUNNING;
+
xdbc_trace("DbC is running now, control 0x%08x\n",
readl(&xdbcp->xdbc_reg->control));
 
@@ -895,3 +918,353 @@ int __init early_xdbc_init(char *s)
 
return 0;
 }
+
+static void xdbc_queue_trb(struct xdbc_ring *ring,
+   u32 field1, u32 field2, u32 field3, u32 field4)
+{
+   struct xdbc_trb *trb, *link_trb;
+
+   trb = ring->enqueue;
+   trb->field[0] = cpu_to_le32(field1);
+   trb->field[1] = cpu_to_le32(field2);
+   trb->field[2] = cpu_to_le32(field3);
+   trb->field[3] = cpu_to_le32(field4);
+
+   xdbc_dbg_dump_trb(trb, "enqueue trb");
+
+   ++(ring->enqueue);
+   if (ring->enqueue >= &ring->segment->trbs[TRBS_PER_SEGMENT - 1]) {
+   link_trb = ring->enqueue;
+   if (ring->cycle_state)
+   link_trb->field[3] |= cpu_to_le32(TRB_CYCLE);
+   else
+   link_trb->field[3] &= cpu_to_le32(~TRB_CYCLE);
+
+   ring->enqueue = ring->segment->trbs;
+   ring->cycle_state ^= 1;
+   }
+}
+
+static void xdbc_ring_doorbell(int target)
+{
+   writel(DOOR_BELL_TARGET(target), &xdbcp->xdbc_reg->doorbell);
+}
+
+static void xdbc_handle_port_status(struct xdbc_trb *evt_trb)
+{
+   u32 port_reg;
+
+   port_reg = readl(&xdbcp->xdbc_reg->portsc);
+
+   if (port_reg & PORTSC_CSC) {
+   xdbc_trace("%s: connect status change event\n", __func__);
+   writel(port_reg | PORTSC_CSC, &xdbcp->xdbc_reg->portsc);
+   port_reg = readl(&xdbcp->xdbc_reg->portsc);
+   }
+
+   if (port_reg & PORTSC_PRC) {
+   xdbc_trace("%s: port reset change event\n", __func__);
+   writel(port_reg | PORTSC_PRC, &xdbcp->xdbc_reg->portsc);
+   port_reg = readl(&xdbcp->xdbc_reg->portsc);
+   }
+
+   if (port_reg & PORTSC_PLC) {
+   xdbc_trace("%s: port link status change event\n", __func__);
+   writel(port_reg | PORTSC_PLC, &xdbcp->xdbc_reg->portsc);
+   port_reg = readl(&xdbcp->xdbc_reg->portsc);
+   }
+
+   if (port_reg & PORTSC_CEC) {
+   xdbc_trace("%s: config error change\n", __func__)

[PATCH v4 05/12] usb: xhci: dbc: add debug buffer

[Lu Baolu]

"printk" is not suitable for dbc debugging especially when console
is in usage. This patch adds a debug buffer in dbc driver and puts
the debug messages in this local buffer. The debug buffer could be
dumped whenever the console is not in use. This part of code will
not be visible unless DBC_DEBUG is defined.

Signed-off-by: Lu Baolu 
---
 drivers/usb/early/xhci-dbc.c | 62 ++--
 1 file changed, 60 insertions(+), 2 deletions(-)

diff --git a/drivers/usb/early/xhci-dbc.c b/drivers/usb/early/xhci-dbc.c
index 6b23f09..b36a527 100644
--- a/drivers/usb/early/xhci-dbc.c
+++ b/drivers/usb/early/xhci-dbc.c
@@ -32,8 +32,64 @@ static struct xdbc_state xdbc_stat;
 static struct xdbc_state *xdbcp = &xdbc_stat;
 
 #ifdef DBC_DEBUG
-/* place holder */
-#definexdbc_trace  printk
+#defineXDBC_DEBUG_BUF_SIZE (PAGE_SIZE * 32)
+#defineMSG_MAX_LINE128
+static char xdbc_debug_buf[XDBC_DEBUG_BUF_SIZE];
+static void xdbc_trace(const char *fmt, ...)
+{
+   int i, size;
+   va_list args;
+   static int pos;
+   char temp_buf[MSG_MAX_LINE];
+
+   if (pos >= XDBC_DEBUG_BUF_SIZE - 1)
+   return;
+
+   memset(temp_buf, 0, MSG_MAX_LINE);
+   va_start(args, fmt);
+   vsnprintf(temp_buf, MSG_MAX_LINE - 1, fmt, args);
+   va_end(args);
+
+   i = 0;
+   size = strlen(temp_buf);
+   while (i < size) {
+   xdbc_debug_buf[pos] = temp_buf[i];
+   pos++;
+   i++;
+
+   if (pos >= XDBC_DEBUG_BUF_SIZE - 1)
+   break;
+   }
+}
+
+static void xdbc_dump_debug_buffer(void)
+{
+   int index = 0;
+   int count = 0;
+   char dump_buf[MSG_MAX_LINE];
+
+   xdbc_trace("The end of DbC trace buffer\n");
+   pr_notice("DBC debug buffer:\n");
+   memset(dump_buf, 0, MSG_MAX_LINE);
+
+   while (index < XDBC_DEBUG_BUF_SIZE) {
+   if (!xdbc_debug_buf[index])
+   break;
+
+   if (xdbc_debug_buf[index] == '\n' ||
+   count >= MSG_MAX_LINE - 1) {
+   pr_notice("DBC: @%08x %s\n", index, dump_buf);
+   memset(dump_buf, 0, MSG_MAX_LINE);
+   count = 0;
+   } else {
+   dump_buf[count] = xdbc_debug_buf[index];
+   count++;
+   }
+
+   index++;
+   }
+}
+
 static void xdbc_dbg_dump_regs(char *str)
 {
if (!xdbcp->xdbc_reg) {
@@ -165,6 +221,7 @@ static void xdbc_dbg_dump_data(char *str)
 
 #else
 static inline void xdbc_trace(const char *fmt, ...) { }
+static inline void xdbc_dump_debug_buffer(void) { }
 static inline void xdbc_dbg_dump_regs(char *str) { }
 static inline void xdbc_dbg_dump_data(char *str) { }
 #endif /* DBC_DEBUG */
@@ -832,6 +889,7 @@ int __init early_xdbc_init(char *s)
pr_notice("failed to setup xHCI DbC connection\n");
xdbcp->xhci_base = NULL;
xdbcp->xdbc_reg = NULL;
+   xdbc_dump_debug_buffer();
return ret;
}
 
-- 
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 v4 08/12] usb: xhci: dbc: handle endpoint stall

[Lu Baolu]

In case of endpoint stall, software is able to detect the situation
by reading DCCTRL.HIT or DCCTRL.HOT bits. DbC follows the normal USB
framework to handle endpoint stall. When software detects endpoint
stall situation, it should wait until endpoint is recovered before
read or write oprations.

Signed-off-by: Lu Baolu 
---
 drivers/usb/early/xhci-dbc.c | 36 
 1 file changed, 36 insertions(+)

diff --git a/drivers/usb/early/xhci-dbc.c b/drivers/usb/early/xhci-dbc.c
index 8a5a51f..aaf655f 100644
--- a/drivers/usb/early/xhci-dbc.c
+++ b/drivers/usb/early/xhci-dbc.c
@@ -1176,6 +1176,37 @@ static int xdbc_wait_until_dbc_configured(void)
return -ETIMEDOUT;
 }
 
+static int xdbc_wait_until_epstall_cleared(bool read)
+{
+   int timeout = 0;
+
+   if (read) {
+   do {
+   if (!(readl(&xdbcp->xdbc_reg->control) & CTRL_HIT)) {
+   xdbcp->in_ep_state = EP_RUNNING;
+
+   return 0;
+   }
+
+   xdbcp->in_ep_state = EP_HALTED;
+   xdbc_udelay(10);
+   } while (timeout++ < XDBC_LOOPS);
+   } else {
+   do {
+   if (!(readl(&xdbcp->xdbc_reg->control) & CTRL_HOT)) {
+   xdbcp->out_ep_state = EP_RUNNING;
+
+   return 0;
+   }
+
+   xdbcp->out_ep_state = EP_HALTED;
+   xdbc_udelay(10);
+   } while (timeout++ < XDBC_LOOPS);
+   }
+
+   return -ETIMEDOUT;
+}
+
 static int xdbc_bulk_transfer(void *data, int size, int loops, bool read)
 {
u64 addr;
@@ -1195,6 +1226,11 @@ static int xdbc_bulk_transfer(void *data, int size, int 
loops, bool read)
return -EPERM;
}
 
+   if (xdbc_wait_until_epstall_cleared(read)) {
+   xdbc_trace("%s: endpoint not ready\n", __func__);
+   return -EPERM;
+   }
+
ring = (read ? &xdbcp->in_ring : &xdbcp->out_ring);
trb = ring->enqueue;
cycle = ring->cycle_state;
-- 
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 v4 07/12] usb: xhci: dbc: handle dbc-configured exit

[Lu Baolu]

DbC might exit configured state in some cases (refer to 7.6.4.4 in
xHCI spec 1.1). Software needs detect and clear this situation by
clearing DCCTRL.DCR and wait until the DbC configured before read
or write oprations.

Signed-off-by: Lu Baolu 
---
 drivers/usb/early/xhci-dbc.c | 28 
 1 file changed, 28 insertions(+)

diff --git a/drivers/usb/early/xhci-dbc.c b/drivers/usb/early/xhci-dbc.c
index f51daa4..8a5a51f 100644
--- a/drivers/usb/early/xhci-dbc.c
+++ b/drivers/usb/early/xhci-dbc.c
@@ -1153,6 +1153,29 @@ static int xdbc_wait_until_bulk_done(struct xdbc_trb 
*trb, int loops)
return -EIO;
 }
 
+static int xdbc_wait_until_dbc_configured(void)
+{
+   int timeout = 0;
+   u32 reg;
+
+   /* Port exits configured state */
+   reg = readl(&xdbcp->xdbc_reg->control);
+   if (!(reg & CTRL_DRC))
+   return 0;
+
+   /* clear run change bit (RW1C) */
+   writel(reg | CTRL_DRC, &xdbcp->xdbc_reg->control);
+
+   do {
+   if (readl(&xdbcp->xdbc_reg->control) & CTRL_DCR)
+   return 0;
+
+   xdbc_udelay(10);
+   } while (timeout++ < XDBC_LOOPS);
+
+   return -ETIMEDOUT;
+}
+
 static int xdbc_bulk_transfer(void *data, int size, int loops, bool read)
 {
u64 addr;
@@ -1167,6 +1190,11 @@ static int xdbc_bulk_transfer(void *data, int size, int 
loops, bool read)
return -EINVAL;
}
 
+   if (xdbc_wait_until_dbc_configured()) {
+   xdbc_trace("%s: hardware not ready\n", __func__);
+   return -EPERM;
+   }
+
ring = (read ? &xdbcp->in_ring : &xdbcp->out_ring);
trb = ring->enqueue;
cycle = ring->cycle_state;
-- 
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 v4 10/12] usb: xhci: dbc: add handshake between debug target and host

[Lu Baolu]

After DbC setup, debug target needs to wait until tty driver and
application (e.g. mincom) on debug taget start.  Otherwise, out
messages might be ignored.

This patch adds a ping/pong mechanism between debug target and
host. Debug target will be waiting there until user presses 'Y'
or 'y' in the tty application.

Signed-off-by: Lu Baolu 
---
 drivers/usb/early/xhci-dbc.c | 27 +++
 1 file changed, 27 insertions(+)

diff --git a/drivers/usb/early/xhci-dbc.c b/drivers/usb/early/xhci-dbc.c
index 68a7139..b75c523 100644
--- a/drivers/usb/early/xhci-dbc.c
+++ b/drivers/usb/early/xhci-dbc.c
@@ -32,6 +32,9 @@
 static struct xdbc_state xdbc_stat;
 static struct xdbc_state *xdbcp = &xdbc_stat;
 
+static int early_xdbc_read(struct console *con, char *str, unsigned n);
+static void early_xdbc_write(struct console *con, const char *str, u32 n);
+
 #ifdef DBC_DEBUG
 #defineXDBC_DEBUG_BUF_SIZE (PAGE_SIZE * 32)
 #defineMSG_MAX_LINE128
@@ -873,8 +876,12 @@ int __init early_xdbc_init(char *s)
 {
u32 bus = 0, dev = 0, func = 0;
unsigned long dbgp_num = 0;
+   char *ping = "Press Y to continue...\n";
+   char pong[64];
+   size_t size;
u32 offset;
int ret;
+   int retry = 20;
 
if (!early_pci_allowed())
return -EPERM;
@@ -917,6 +924,21 @@ int __init early_xdbc_init(char *s)
return ret;
}
 
+   while (retry > 0) {
+   early_xdbc_write(NULL, ping, strlen(ping));
+   size = early_xdbc_read(NULL, pong, 64);
+   if (size > 0) {
+   xdbc_trace("%s: pong message: %s\n", __func__, pong);
+   if (pong[0] == 'Y' || pong[0] == 'y')
+   break;
+   } else {
+   xdbc_trace("%s: pong message error %d\n",
+   __func__, size);
+   }
+
+   retry--;
+   }
+
return 0;
 }
 
@@ -1338,6 +1360,11 @@ int xdbc_bulk_write(const char *bytes, int size)
  * Start a bulk-in or bulk-out transfer, wait until transfer completion
  * or error. Return the count of actually transferred bytes or error.
  */
+static int early_xdbc_read(struct console *con, char *str, unsigned n)
+{
+   return xdbc_bulk_read(str, n, 0);
+}
+
 static void early_xdbc_write(struct console *con, const char *str, u32 n)
 {
int chunk, ret;
-- 
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 v4 09/12] x86: early_printk: add USB3 debug port earlyprintk support

[Lu Baolu]

Add support for early printk by writing debug messages to the USB3
debug port. Users can use this type of early printk by specifying
kernel parameter of "earlyprintk=xdbc". This gives users a chance
of providing debug output.

Signed-off-by: Lu Baolu 
---
 Documentation/kernel-parameters.txt |  1 +
 arch/x86/kernel/early_printk.c  |  5 +
 drivers/usb/early/xhci-dbc.c| 43 +
 include/linux/usb/xhci-dbc.h|  5 +
 4 files changed, 54 insertions(+)

diff --git a/Documentation/kernel-parameters.txt 
b/Documentation/kernel-parameters.txt
index f8aae63..cb879cd 100644
--- a/Documentation/kernel-parameters.txt
+++ b/Documentation/kernel-parameters.txt
@@ -1049,6 +1049,7 @@ bytes respectively. Such letter suffixes can also be 
entirely omitted.
earlyprintk=ttySn[,baudrate]
earlyprintk=dbgp[debugController#]
earlyprintk=pciserial,bus:device.function[,baudrate]
+   earlyprintk=xdbc[xhciController#]
 
earlyprintk is useful when the kernel crashes before
the normal console is initialized. It is not enabled by
diff --git a/arch/x86/kernel/early_printk.c b/arch/x86/kernel/early_printk.c
index 21bf924..ba4c471 100644
--- a/arch/x86/kernel/early_printk.c
+++ b/arch/x86/kernel/early_printk.c
@@ -17,6 +17,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -373,6 +374,10 @@ static int __init setup_early_printk(char *buf)
if (!strncmp(buf, "dbgp", 4) && !early_dbgp_init(buf + 4))
early_console_register(&early_dbgp_console, keep);
 #endif
+#ifdef CONFIG_EARLY_PRINTK_XDBC
+   if (!strncmp(buf, "xdbc", 4) && !early_xdbc_init(buf + 4))
+   early_console_register(&early_xdbc_console, keep);
+#endif
 #ifdef CONFIG_HVC_XEN
if (!strncmp(buf, "xen", 3))
early_console_register(&xenboot_console, keep);
diff --git a/drivers/usb/early/xhci-dbc.c b/drivers/usb/early/xhci-dbc.c
index aaf655f..68a7139 100644
--- a/drivers/usb/early/xhci-dbc.c
+++ b/drivers/usb/early/xhci-dbc.c
@@ -10,6 +10,7 @@
  * it under the terms of the GNU General Public License version 2 as
  * published by the Free Software Foundation.
  */
+#include 
 #include 
 #include 
 #include 
@@ -1332,3 +1333,45 @@ int xdbc_bulk_write(const char *bytes, int size)
 
return ret;
 }
+
+/*
+ * Start a bulk-in or bulk-out transfer, wait until transfer completion
+ * or error. Return the count of actually transferred bytes or error.
+ */
+static void early_xdbc_write(struct console *con, const char *str, u32 n)
+{
+   int chunk, ret;
+   static char buf[XDBC_MAX_PACKET];
+   int use_cr = 0;
+
+   if (!xdbcp->xdbc_reg)
+   return;
+   memset(buf, 0, XDBC_MAX_PACKET);
+   while (n > 0) {
+   for (chunk = 0; chunk < XDBC_MAX_PACKET && n > 0;
+str++, chunk++, n--) {
+   if (!use_cr && *str == '\n') {
+   use_cr = 1;
+   buf[chunk] = '\r';
+   str--;
+   n++;
+   continue;
+   }
+   if (use_cr)
+   use_cr = 0;
+   buf[chunk] = *str;
+   }
+   if (chunk > 0) {
+   ret = xdbc_bulk_write(buf, chunk);
+   if (ret < 0)
+   break;
+   }
+   }
+}
+
+struct console early_xdbc_console = {
+   .name = "earlyxdbc",
+   .write =early_xdbc_write,
+   .flags =CON_PRINTBUFFER,
+   .index =-1,
+};
diff --git a/include/linux/usb/xhci-dbc.h b/include/linux/usb/xhci-dbc.h
index 289ba58..a556eb8 100644
--- a/include/linux/usb/xhci-dbc.h
+++ b/include/linux/usb/xhci-dbc.h
@@ -216,4 +216,9 @@ struct xdbc_state {
 #definexdbc_read64(regs)   xhci_read_64(NULL, (regs))
 #definexdbc_write64(val, regs) xhci_write_64(NULL, (val), (regs))
 
+#ifdef CONFIG_EARLY_PRINTK_XDBC
+extern int early_xdbc_init(char *s);
+extern struct console early_xdbc_console;
+#endif /* CONFIG_EARLY_PRINTK_XDBC */
+
 #endif /* __LINUX_XHCI_DBC_H */
-- 
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 v4 11/12] usb: serial: usb_debug: add support for dbc debug device

[Lu Baolu]

This patch add dbc debug device support in usb_debug driver.

Signed-off-by: Lu Baolu 
Acked-by: Johan Hovold 
---
 drivers/usb/serial/usb_debug.c | 28 +---
 1 file changed, 25 insertions(+), 3 deletions(-)

diff --git a/drivers/usb/serial/usb_debug.c b/drivers/usb/serial/usb_debug.c
index ca2fa5b..92f7e5c 100644
--- a/drivers/usb/serial/usb_debug.c
+++ b/drivers/usb/serial/usb_debug.c
@@ -32,7 +32,18 @@ static const struct usb_device_id id_table[] = {
{ USB_DEVICE(0x0525, 0x127a) },
{ },
 };
-MODULE_DEVICE_TABLE(usb, id_table);
+
+static const struct usb_device_id dbc_id_table[] = {
+   { USB_DEVICE(0x1d6b, 0x0004) },
+   { },
+};
+
+static const struct usb_device_id id_table_combined[] = {
+   { USB_DEVICE(0x0525, 0x127a) },
+   { USB_DEVICE(0x1d6b, 0x0004) },
+   { },
+};
+MODULE_DEVICE_TABLE(usb, id_table_combined);
 
 /* This HW really does not support a serial break, so one will be
  * emulated when ever the break state is set to true.
@@ -71,9 +82,20 @@ static struct usb_serial_driver debug_device = {
.process_read_urb = usb_debug_process_read_urb,
 };
 
+static struct usb_serial_driver dbc_device = {
+   .driver = {
+   .owner =THIS_MODULE,
+   .name = "xhci_dbc",
+   },
+   .id_table = dbc_id_table,
+   .num_ports =1,
+   .break_ctl =usb_debug_break_ctl,
+   .process_read_urb = usb_debug_process_read_urb,
+};
+
 static struct usb_serial_driver * const serial_drivers[] = {
-   &debug_device, NULL
+   &debug_device, &dbc_device, NULL
 };
 
-module_usb_serial_driver(serial_drivers, id_table);
+module_usb_serial_driver(serial_drivers, id_table_combined);
 MODULE_LICENSE("GPL");
-- 
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 v4 12/12] usb: doc: add document for xHCI DbC driver

[Lu Baolu]

Add Documentation/usb/xhci-dbc.txt. This document includes
development status and user guide for USB3 debug port.

Signed-off-by: Lu Baolu 
---
 Documentation/usb/xhci-dbc.txt | 325 +
 MAINTAINERS|   1 +
 drivers/usb/early/xhci-dbc.c   |   3 +
 3 files changed, 329 insertions(+)
 create mode 100644 Documentation/usb/xhci-dbc.txt

diff --git a/Documentation/usb/xhci-dbc.txt b/Documentation/usb/xhci-dbc.txt
new file mode 100644
index 000..441b40c
--- /dev/null
+++ b/Documentation/usb/xhci-dbc.txt
@@ -0,0 +1,325 @@
+xHCI debug capability driver
+
+ Lu Baolu 
+
+Last-updated: September 2015
+
+
+   Contents:
+   -
+   * What is xHCI DbC?
+   * Debug topologies
+   * Debug stacks
+   * Port Multiplexing
+   * Hardware initialization
+   * External reset
+   * Port reset
+   * Interrupt/DMA/Memory during early boot
+   * Endpoint STALL
+   * Debug device information
+   * How to use DbC early printk?
+   * Limitations
+
+   What is xHCI DbC?
+   -
+
+The xHCI Debugging Capability defined in section 7.6 of xHCI spec 1.1
+provides an optional functionality that enables low-level system debug
+over USB. It provides a means of connecting two systems where one system
+is a Debug Host and the other a Debug Target (System Under Test). The
+Debug Capability provides an interface that is completely independent
+of the xHCI interface. A Debug Target enumerates as a USB debug device
+to the Debug Host, allowing a Debug Host to access a Debug Target through
+the standard USB software stack.
+
+   Debug topologies
+   
+
+Multiple Debug Targets may be attached to a single Debug Host. Debug
+Targets may be connected to any downstream facing port below a Debug
+Host (i.e. anywhere in the fabric, root port or external hub puts).
+A Debug Target may only connect to a Debug Host through a Root Hub port
+of the target. That means connection of a Debug Target to a Debug Host
+through the ports of an external hub is not supported.
+
+Below is a typical connection between Debug Host and Debug target. Two
+Debug targets are connected to a single Debug host.
+
+
+ 
+|   Debug Host   |  |  Debug Target  |
+||  ||
+|xHC without DbC |  |  xHC with DbC  |
+|or DbC disabled |  | enabled|
+||  ||
+|P1|  |p2|  |P1|  |p2|
+|__|  |__|  |__|  |__|
+  || |
+  ||_|
+  |_
+|
+ ___|
+|   HUB  |  |  Debug Target  |
+||  ||
+| Superspeed hub |  |  xHC with DbC  |
+||  | enabled|
+||  ||
+|P1|  |p2|  |P1|  |p2|
+|__|  |__|  |__|  |__|
+   | |
+   |_|
+
+   Debug stacks
+   
+
+Below is a software stack diagram of both Debug Host and Debug Target.
+
+ 
+|   Debug Host   |  |  Debug Target  |
+||  ||
+|   debug App|  ||
+||  | system debug   |
+|   usb_debug|  | hooks  |
+||  ||
+|usbcore |  ||
+||  |debug capability|
+|xhci_hcd|  | driver |
+||  ||
+|xHC without DbC |  |  xHC with DbC  |
+|or DbC disabled |  | enabled|
+||  ||
+|P1|  |p2|  |P1|  |p2|
+|__|  |__|  |__|  |__|
+   | |
+   |_|
+
+
+   Port Multiplexing
+   -
+
+A debug port is always multiplexed with the first xHCI root hub port.
+Whenever debug capability is supported and enabled, and the first root
+hub port is detected to be connected to a downstream super-speed port
+of a Debug Host, the root hub port is assigned to the debug capability
+and operating i

[PATCH] HID: usbhid: add Logitech G710+ keyboard quirk NOGET

[Jimmy Berry]

Without quirk keyboard repeats '6' until volume control is used since it
indicates the key is pressed without ever releasing.

Signed-off-by: Jimmy Berry 
---
 drivers/hid/hid-ids.h   | 1 +
 drivers/hid/usbhid/hid-quirks.c | 1 +
 2 files changed, 2 insertions(+)

diff --git a/drivers/hid/hid-ids.h b/drivers/hid/hid-ids.h
index ac1feea..9024a3d 100644
--- a/drivers/hid/hid-ids.h
+++ b/drivers/hid/hid-ids.h
@@ -609,6 +609,7 @@
 #define USB_DEVICE_ID_LOGITECH_HARMONY_FIRST  0xc110
 #define USB_DEVICE_ID_LOGITECH_HARMONY_LAST 0xc14f
 #define USB_DEVICE_ID_LOGITECH_HARMONY_PS3 0x0306
+#define USB_DEVICE_ID_LOGITECH_KEYBOARD_G710_PLUS 0xc24d
 #define USB_DEVICE_ID_LOGITECH_MOUSE_C01A  0xc01a
 #define USB_DEVICE_ID_LOGITECH_MOUSE_C05A  0xc05a
 #define USB_DEVICE_ID_LOGITECH_MOUSE_C06A  0xc06a
diff --git a/drivers/hid/usbhid/hid-quirks.c b/drivers/hid/usbhid/hid-quirks.c
index 94bb137..2324520 100644
--- a/drivers/hid/usbhid/hid-quirks.c
+++ b/drivers/hid/usbhid/hid-quirks.c
@@ -84,6 +84,7 @@ static const struct hid_blacklist {
{ USB_VENDOR_ID_HP, 
USB_PRODUCT_ID_HP_LOGITECH_OEM_USB_OPTICAL_MOUSE_0B4A, HID_QUIRK_ALWAYS_POLL },
{ USB_VENDOR_ID_HP, USB_PRODUCT_ID_HP_PIXART_OEM_USB_OPTICAL_MOUSE, 
HID_QUIRK_ALWAYS_POLL },
{ USB_VENDOR_ID_LOGITECH, USB_DEVICE_ID_LOGITECH_C077, 
HID_QUIRK_ALWAYS_POLL },
+   { USB_VENDOR_ID_LOGITECH, USB_DEVICE_ID_LOGITECH_KEYBOARD_G710_PLUS, 
HID_QUIRK_NOGET },
{ USB_VENDOR_ID_LOGITECH, USB_DEVICE_ID_LOGITECH_MOUSE_C01A, 
HID_QUIRK_ALWAYS_POLL },
{ USB_VENDOR_ID_LOGITECH, USB_DEVICE_ID_LOGITECH_MOUSE_C05A, 
HID_QUIRK_ALWAYS_POLL },
{ USB_VENDOR_ID_LOGITECH, USB_DEVICE_ID_LOGITECH_MOUSE_C06A, 
HID_QUIRK_ALWAYS_POLL },
-- 
2.6.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] phy: phy-mt65xx-usb3: fix test fail of HS receiver sensitivity

[Greg KH]

On Tue, Nov 17, 2015 at 02:02:58PM +0800, Chunfeng Yun wrote:
> when use the default value 8 of RG_USB20_SQTH, the HS receiver
> sensitivity test of HQA will fail, set it as 2 to fix up the
> issue.
> 
> Change-Id: Ia5bdbbfc8ebb170d3ef26007e665b7350b6d28ab

What is this field for?  Hint, it should never be there for a patch you
submit upstream as it means nothing...

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: [RESEND] phy: core: Get a refcount to phy in devm_of_phy_get_by_index()

[Jisheng Zhang]

Hi,

On Tue, 17 Nov 2015 13:56:48 +0800
Chunfeng Yun  wrote:

> On driver detach, devm_phy_release() will put a refcount to
> the phy, so gets a refconut to it before return.
> 
> Change-Id: I56fe428bf945f19c38d56245978c8ca17340eb2c

This line need to be removed



> Signed-off-by: Chunfeng Yun 
> ---
>  drivers/phy/phy-core.c | 21 +++--
>  1 file changed, 15 insertions(+), 6 deletions(-)
> 
> diff --git a/drivers/phy/phy-core.c b/drivers/phy/phy-core.c
> index fc48fac..8c7f27d 100644
> --- a/drivers/phy/phy-core.c
> +++ b/drivers/phy/phy-core.c
> @@ -636,8 +636,9 @@ EXPORT_SYMBOL_GPL(devm_of_phy_get);
>   * @np: node containing the phy
>   * @index: index of the phy
>   *
> - * Gets the phy using _of_phy_get(), and associates a device with it using
> - * devres. On driver detach, release function is invoked on the devres data,
> + * Gets the phy using _of_phy_get(), then gets a refcount to it,
> + * and associates a device with it using devres. On driver detach,
> + * release function is invoked on the devres data,
>   * then, devres data is freed.
>   *
>   */
> @@ -651,13 +652,21 @@ struct phy *devm_of_phy_get_by_index(struct device 
> *dev, struct device_node *np,
>   return ERR_PTR(-ENOMEM);
>  
>   phy = _of_phy_get(np, index);
> - if (!IS_ERR(phy)) {
> - *ptr = phy;
> - devres_add(dev, ptr);
> - } else {
> + if (IS_ERR(phy)) {
>   devres_free(ptr);
> + return phy;
>   }
>  
> + if (!try_module_get(phy->ops->owner)) {
> + devres_free(ptr);
> + return ERR_PTR(-EPROBE_DEFER);
> + }
> +
> + get_device(&phy->dev);
> +
> + *ptr = phy;
> + devres_add(dev, ptr);
> +
>   return phy;
>  }
>  EXPORT_SYMBOL_GPL(devm_of_phy_get_by_index);

--
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] phy: phy-mt65xx-usb3: improve HS eye diagram

[Chunfeng Yun]

calibrate HS slew rate and switch 100uA current to SSUSB
to improve HS eye diagram of HQA test.

Change-Id: I6d392c7fffb32b3a710e3a8dda92710886806d90
Signed-off-by: Chunfeng Yun 
---
 drivers/phy/phy-mt65xx-usb3.c | 99 +--
 1 file changed, 96 insertions(+), 3 deletions(-)

diff --git a/drivers/phy/phy-mt65xx-usb3.c b/drivers/phy/phy-mt65xx-usb3.c
index dc480d3..9069162 100644
--- a/drivers/phy/phy-mt65xx-usb3.c
+++ b/drivers/phy/phy-mt65xx-usb3.c
@@ -17,6 +17,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -27,6 +28,7 @@
  * relative to USB3_SIF2_BASE base address
  */
 #define SSUSB_SIFSLV_SPLLC 0x
+#define SSUSB_SIFSLV_U2FREQ0x0100
 
 /* offsets of sub-segment in each port registers */
 #define SSUSB_SIFSLV_U2PHY_COM_BASE0x
@@ -41,6 +43,7 @@
 #define PA2_RG_SIF_U2PLL_FORCE_EN  BIT(18)
 
 #define U3P_USBPHYACR5 (SSUSB_SIFSLV_U2PHY_COM_BASE + 0x0014)
+#define PA5_RG_U2_HSTX_SRCAL_ENBIT(15)
 #define PA5_RG_U2_HSTX_SRCTRL  GENMASK(14, 12)
 #define PA5_RG_U2_HSTX_SRCTRL_VAL(x)   ((0x7 & (x)) << 12)
 #define PA5_RG_U2_HS_100U_U3_ENBIT(11)
@@ -113,6 +116,24 @@
 #define XC3_RG_U3_XTAL_RX_PWD  BIT(9)
 #define XC3_RG_U3_FRC_XTAL_RX_PWD  BIT(8)
 
+#define U3P_U2FREQ_FMCR0   (SSUSB_SIFSLV_U2FREQ + 0x00)
+#define P2F_RG_MONCLK_SEL  GENMASK(27, 26)
+#define P2F_RG_MONCLK_SEL_VAL(x)   ((0x3 & (x)) << 26)
+#define P2F_RG_FREQDET_EN  BIT(24)
+#define P2F_RG_CYCLECNTGENMASK(23, 0)
+#define P2F_RG_CYCLECNT_VAL(x) ((P2F_RG_CYCLECNT) & (x))
+
+#define U3P_U2FREQ_VALUE   (SSUSB_SIFSLV_U2FREQ + 0x0c)
+
+#define U3P_U2FREQ_FMMONR1 (SSUSB_SIFSLV_U2FREQ + 0x10)
+#define P2F_USB_FM_VALID   BIT(0)
+#define P2F_RG_FRCK_EN BIT(8)
+
+#define U3P_REF_CLK26  /* MHZ */
+#define U3P_SLEW_RATE_COEF 28
+#define U3P_SR_COEF_DIVISOR1000
+#define U3P_FM_DET_CYCLE_CNT   1024
+
 struct mt65xx_phy_instance {
struct phy *phy;
void __iomem *port_base;
@@ -128,6 +149,77 @@ struct mt65xx_u3phy {
int nphys;
 };
 
+static void hs_slew_rate_calibrate(struct mt65xx_u3phy *u3phy,
+   struct mt65xx_phy_instance *instance)
+{
+   void __iomem *sif_base = u3phy->sif_base;
+   int calibration_val;
+   int fm_out;
+   u32 tmp;
+
+   /* enable USB ring oscillator */
+   tmp = readl(instance->port_base + U3P_USBPHYACR5);
+   tmp |= PA5_RG_U2_HSTX_SRCAL_EN;
+   writel(tmp, instance->port_base + U3P_USBPHYACR5);
+   udelay(1);
+
+   /*enable free run clock */
+   tmp = readl(sif_base + U3P_U2FREQ_FMMONR1);
+   tmp |= P2F_RG_FRCK_EN;
+   writel(tmp, sif_base + U3P_U2FREQ_FMMONR1);
+
+   /* set cycle count as 1024, and select u2 channel */
+   tmp = readl(sif_base + U3P_U2FREQ_FMCR0);
+   tmp &= ~(P2F_RG_CYCLECNT | P2F_RG_MONCLK_SEL);
+   tmp |= P2F_RG_CYCLECNT_VAL(U3P_FM_DET_CYCLE_CNT);
+   tmp |= P2F_RG_MONCLK_SEL_VAL(instance->index);
+   writel(tmp, sif_base + U3P_U2FREQ_FMCR0);
+
+   /* enable frequency meter */
+   tmp = readl(sif_base + U3P_U2FREQ_FMCR0);
+   tmp |= P2F_RG_FREQDET_EN;
+   writel(tmp, sif_base + U3P_U2FREQ_FMCR0);
+
+   /* ignore return value */
+   readl_poll_timeout(sif_base + U3P_U2FREQ_FMMONR1, tmp,
+ (tmp & P2F_USB_FM_VALID), 10, 200);
+
+   fm_out = readl(sif_base + U3P_U2FREQ_VALUE);
+
+   /* disable frequency meter */
+   tmp = readl(sif_base + U3P_U2FREQ_FMCR0);
+   tmp &= ~P2F_RG_FREQDET_EN;
+   writel(tmp, sif_base + U3P_U2FREQ_FMCR0);
+
+   /*disable free run clock */
+   tmp = readl(sif_base + U3P_U2FREQ_FMMONR1);
+   tmp &= ~P2F_RG_FRCK_EN;
+   writel(tmp, sif_base + U3P_U2FREQ_FMMONR1);
+
+   if (fm_out) {
+   /* ( 1024 / FM_OUT ) x reference clock frequency x 0.028 */
+   tmp = U3P_FM_DET_CYCLE_CNT * U3P_REF_CLK * U3P_SLEW_RATE_COEF;
+   tmp /= fm_out;
+   calibration_val = DIV_ROUND_CLOSEST(tmp, U3P_SR_COEF_DIVISOR);
+   } else {
+   /* if FM detection fail, set default value */
+   calibration_val = 4;
+   }
+   dev_dbg(u3phy->dev, "phy:%d, fm_out:%d, calib:%d\n",
+   instance->index, fm_out, calibration_val);
+
+   /* set HS slew rate */
+   tmp = readl(instance->port_base + U3P_USBPHYACR5);
+   tmp &= ~PA5_RG_U2_HSTX_SRCTRL;
+   tmp |= PA5_RG_U2_HSTX_SRCTRL_VAL(calibration_val);
+   writel(tmp, instance->port_base + U3P_USBPHYACR5);
+
+   /* disable USB ring oscillator */
+   tmp = readl(instance->port_base + U3P_USBPHYACR5);
+   tmp &= ~PA5_RG_U2_HSTX_SRCAL_EN;
+   writel(tmp, instance->port_base + U3P_USBPHYACR5);
+}
+
 static void phy_instance_init(struct mt65xx_u3phy *u3phy,
struct mt65xx_phy_instance *instance)
 {
@@ -226,9 +318,9 @@ static void phy_instance_power_on(s

[PATCH] phy: phy-mt65xx-usb3: fix test fail of HS receiver sensitivity

[Chunfeng Yun]

when use the default value 8 of RG_USB20_SQTH, the HS receiver
sensitivity test of HQA will fail, set it as 2 to fix up the
issue.

Change-Id: Ia5bdbbfc8ebb170d3ef26007e665b7350b6d28ab
Signed-off-by: Chunfeng Yun 
---
 drivers/phy/phy-mt65xx-usb3.c | 7 +--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/drivers/phy/phy-mt65xx-usb3.c b/drivers/phy/phy-mt65xx-usb3.c
index f30b28b..dc480d3 100644
--- a/drivers/phy/phy-mt65xx-usb3.c
+++ b/drivers/phy/phy-mt65xx-usb3.c
@@ -49,6 +49,8 @@
 #define PA6_RG_U2_ISO_EN   BIT(31)
 #define PA6_RG_U2_BC11_SW_EN   BIT(23)
 #define PA6_RG_U2_OTG_VBUSCMP_EN   BIT(20)
+#define PA6_RG_U2_SQTH GENMASK(3, 0)
+#define PA6_RG_U2_SQTH_VAL(x)  (0xf & (x))
 
 #define U3P_U2PHYACR4  (SSUSB_SIFSLV_U2PHY_COM_BASE + 0x0020)
 #define P2C_RG_USB20_GPIO_CTL  BIT(9)
@@ -165,9 +167,10 @@ static void phy_instance_init(struct mt65xx_u3phy *u3phy,
writel(tmp, port_base + U3P_U2PHYDTM0);
}
 
-   /* DP/DM BC1.1 path Disable */
tmp = readl(port_base + U3P_USBPHYACR6);
-   tmp &= ~PA6_RG_U2_BC11_SW_EN;
+   tmp &= ~PA6_RG_U2_BC11_SW_EN;   /* DP/DM BC1.1 path Disable */
+   tmp &= ~PA6_RG_U2_SQTH;
+   tmp |= PA6_RG_U2_SQTH_VAL(2);
writel(tmp, port_base + U3P_USBPHYACR6);
 
tmp = readl(port_base + U3P_U3PHYA_DA_REG0);
-- 
1.8.1.1.dirty

--
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] phy: core: Get a refcount to phy in devm_of_phy_get_by_index()

[Chunfeng Yun]

On driver detach, devm_phy_release() will put a refcount to
the phy, so gets a refconut to it before return.

Change-Id: I56fe428bf945f19c38d56245978c8ca17340eb2c
Signed-off-by: Chunfeng Yun 
---
 drivers/phy/phy-core.c | 21 +++--
 1 file changed, 15 insertions(+), 6 deletions(-)

diff --git a/drivers/phy/phy-core.c b/drivers/phy/phy-core.c
index fc48fac..8c7f27d 100644
--- a/drivers/phy/phy-core.c
+++ b/drivers/phy/phy-core.c
@@ -636,8 +636,9 @@ EXPORT_SYMBOL_GPL(devm_of_phy_get);
  * @np: node containing the phy
  * @index: index of the phy
  *
- * Gets the phy using _of_phy_get(), and associates a device with it using
- * devres. On driver detach, release function is invoked on the devres data,
+ * Gets the phy using _of_phy_get(), then gets a refcount to it,
+ * and associates a device with it using devres. On driver detach,
+ * release function is invoked on the devres data,
  * then, devres data is freed.
  *
  */
@@ -651,13 +652,21 @@ struct phy *devm_of_phy_get_by_index(struct device *dev, 
struct device_node *np,
return ERR_PTR(-ENOMEM);
 
phy = _of_phy_get(np, index);
-   if (!IS_ERR(phy)) {
-   *ptr = phy;
-   devres_add(dev, ptr);
-   } else {
+   if (IS_ERR(phy)) {
devres_free(ptr);
+   return phy;
}
 
+   if (!try_module_get(phy->ops->owner)) {
+   devres_free(ptr);
+   return ERR_PTR(-EPROBE_DEFER);
+   }
+
+   get_device(&phy->dev);
+
+   *ptr = phy;
+   devres_add(dev, ptr);
+
return phy;
 }
 EXPORT_SYMBOL_GPL(devm_of_phy_get_by_index);
-- 
1.8.1.1.dirty

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

Re: [RFC] usb: dwc2: hcd: fix split schedule issue

[Doug Anderson]

John,

On Wed, Nov 11, 2015 at 8:29 PM, John Youn  wrote:
> On 11/11/2015 4:22 PM, Doug Anderson wrote:
>> John,
>>
>> On Fri, Nov 6, 2015 at 2:04 AM, Yunzhi Li  wrote:
>>> hi John ,
>>>
>>>   As we talked yesterday, I tried to fix the split schedule sequence. This
>>> patch will
>>> avoid scheduling SSPLIT-IN packet for another device between
>>> SSPLIT-OUT-begin and
>>> SSPLIT-OUT-end, now the keyboard and Jebra audio speaker could work together
>>> well, but
>>> I'm not sure if this is exactly the right way to schedule split transfers
>>> and if there
>>> is any dide effect with this patch. Please help review this patch. Thanks.
>>>
 Fix dwc2 split schedule sequence issue. Not schedule a SSPLIT_IN
 packet between SSPLIT-begin and SSPLIT-end.

 Signed-off-by: Yunzhi Li 
 ---
   drivers/usb/dwc2/hcd.c | 4 
   1 file changed, 4 insertions(+)
>>
>> Did you have any thoughts on this patch?  Although this patch didn't
>> fix the problems I was seeing with the Microsoft Wireless Keyboard
>> (see the patch I sent out earlier which does seem to fix it), I can
>> confirm that in a different setup (HUB goes to USB audio + mouse) that
>> this patch does fix some problems.
>>
>> That being said, it feels to me like a band-aid rather than an actual
>> fix (I'm talking out of my rear end, though, since my USB experience
>> is lacking at best).  It feels like perhaps we're just not keeping
>> track the xact_pos correctly, but of course I don't know that for
>> sure...
>>
>> Anyway, just fishing...  ;)
>>
>> -Doug
>>
>
> Hi Doug,
>
> I also feel it is not quite right as the SSPLIT should be able to
> happen during the SSPLIT of another device. I tried to reproduce
> and see the same scheduling but don't see any hang due to it.
>
> Yunzhi, any details on what kind of hub and keyboard you are
> using? I have the same Jabra 410 speaker.

Just to tie things together for anyone following along, my current
thoughts on how to fix this are something like
.

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

Re: [PATCH v2 1/2] usb: dwc2: host: Fix missing device insertions

[Doug Anderson]

John,

On Mon, Nov 16, 2015 at 5:53 PM, John Youn  wrote:
> Yup it's only available in host mode. The same with all the
> host-mode registers. You will get a ModeMis interrupt if you
> try to access them in device mode.
>
> I gave my test-by on the v2 patches earlier, no problems here.

Yup, I appreciate it!  I just wanted to confirm that you tested this
particular case in gadget mode.  ;)
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 1/2] usb: dwc2: host: Fix missing device insertions

[John Youn]

On 11/16/2015 3:14 PM, Doug Anderson wrote:
> Alan,
> 
> On Mon, Nov 16, 2015 at 12:31 PM, Alan Stern  
> wrote:
>> On Mon, 16 Nov 2015, Doug Anderson wrote:
>>
>>> Alan,
>>>
>>> On Mon, Nov 16, 2015 at 11:31 AM, Alan Stern  
>>> wrote:
 On Mon, 16 Nov 2015, Doug Anderson wrote:

> ---
>
> usb: dwc2: host: Fix missing device insertions
>
> If you've got your interrupt signals bouncing a bit as you insert your
> USB device, you might end up in a state when the device is connected but
> the driver doesn't know it.
>
> Specifically, the observed order is:
>  1. hardware sees connect
>  2. hardware sees disconnect
>  3. hardware sees connect
>  4. dwc2_port_intr() - clears connect interrupt
>  5. dwc2_handle_common_intr() - calls dwc2_hcd_disconnect()
>
> Now you'll be stuck with the cable plugged in and no further interrupts
> coming in but the driver will think we're disconnected.
>
> We'll fix this by checking for the missing connect interrupt and
> re-connecting after the disconnect is posted.  We don't skip the
> disconnect because if there is a transitory disconnect we really want to
> de-enumerate and re-enumerate.

 Why do you need to do anything special here?  Normally a driver's
 interrupt handler should query the hardware status after clearing the
 interrupt source.  That way no transitions ever get missed.

 In your example, at step 5 the dwc2 driver would check the port status
 and see that it currently is connected.  Therefore the driver would
 pass a "connect status changed" event to the USB core and set the port
 status to "connected".  No extra checking is needed, and transitory
 connects or disconnects get handled correctly.
>>>
>>> Things are pretty ugly at the moment because the dwc2 interrupt
>>> handler is split in two.  There's dwc2_handle_hcd_intr() and
>>> dwc2_handle_common_intr().  Both are registered for the same "shared"
>>> IRQ.  If I had to guess, I'd say that this is probably because someone
>>> wanted to assign the ".irq" field in the "struct hc_driver" for the
>>> host controller but that they also needed the other interrupt handler
>>> to handle things shared between host and gadget mode.
>>>
>>> In any case, one of these two interrupt routines handles connect and
>>> the other disconnect.  That's pretty ugly but means that you can't
>>> just rely on standard techniques for keeping things in sync.
>>
>> Okay, that is rather weird.  Still, I don't see why it should matter.
>>
>> Fundamentally there's no difference between a "connect" interrupt and a
>> "disconnect" interrupt.  They should both do exactly the same things:
>> clear the interrupt source, post a "connection change" event, and set
>> the driver's connect status based on the hardware's current state.
>> The second and third parts can be handled by a shared subroutine.
> 
> Ah, sorry I misunderstood.  OK, fair enough.  So you're saying that
> the problem is that dwc2_hcd_disconnect() has a line that looks like
> this:
> 
>   hsotg->flags.b.port_connect_status = 0;
> 
> ...and the dwc2_port_intr() has a line that looks like this:
> 
>   hsotg->flags.b.port_connect_status = 1;
> 
> ...and both should just query the status.
> 
> 
> Do you think we should to block landing this patch on cleaning up how
> dwc2 handles port_connect_status?  I'm not sure what side effects
> changing port_connect_status will have, so I'll need to test and dig a
> bit...
> 
> I'm currently working on trying to fix the microframe scheduler and
> was planning to post the next series of patches there pretty soon.
> I'm also planning to keep digging to figure out how to overall
> increase compatibility with devices (and compatibility with many
> devices plugged in).
> 
> If it were up to me, I'd prefer to land this patch in either 4.4 or
> 4.5 since it does seem to work.  ...then put seeing what we can do to
> cleanup all of the port_connect_status on the todo list.

That sound good to me. Though I'd prefer to see this series
queued for 4.5 for more testing.

> 
> Julius points out in his response that there are comments saying that
> HPRT0 can't be read in device mode.  John: since you're setup to test
> device mode, can you check if my patch (which now adds a read of
> HPRT0) will cause problems? Maybe holding this off and keeping it out
> of the RC is a good idea after all...
> 

Yup it's only available in host mode. The same with all the
host-mode registers. You will get a ModeMis interrupt if you
try to access them in device mode.

I gave my test-by on the v2 patches earlier, no problems here.

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: [PATCH 1/3] usb: gadget: f_sourcesink: add queue depth

[Peter Chen]

On Mon, Nov 16, 2015 at 05:56:25PM +0100, Krzysztof Opasiak wrote:
> 
> 
> On 11/13/2015 09:00 AM, Peter Chen wrote:
> >Add queue depth for both iso and bulk transfer, with more queues, we
> >can do performance and stress test using sourcesink, and update g_zero
> >accordingly.
> >
> >Signed-off-by: Peter Chen 
> >---
> >  drivers/usb/gadget/function/f_sourcesink.c | 144 
> > ++---
> >  drivers/usb/gadget/function/g_zero.h   |   6 ++
> >  drivers/usb/gadget/legacy/zero.c   |  12 +++
> >  3 files changed, 129 insertions(+), 33 deletions(-)
> >
> >diff --git a/drivers/usb/gadget/function/f_sourcesink.c 
> >b/drivers/usb/gadget/function/f_sourcesink.c
> >index d7646d3..4ab603e8 100644
> >--- a/drivers/usb/gadget/function/f_sourcesink.c
> >+++ b/drivers/usb/gadget/function/f_sourcesink.c
> >@@ -34,13 +34,6 @@
> >   * plus two that support control-OUT tests.  If the optional "autoresume"
> >   * mode is enabled, it provides good functional coverage for the "USBCV"
> >   * test harness from USB-IF.
> >- *
> >- * Note that because this doesn't queue more than one request at a time,
> >- * some other function must be used to test queueing logic.  The network
> >- * link (g_ether) is the best overall option for that, since its TX and RX
> >- * queues are relatively independent, will receive a range of packet sizes,
> >- * and can often be made to run out completely.  Those issues are important
> >- * when stress testing peripheral controller drivers.
> >   */
> >  struct f_sourcesink {
> > struct usb_function function;
> >@@ -57,6 +50,8 @@ struct f_sourcesink {
> > unsigned isoc_mult;
> > unsigned isoc_maxburst;
> > unsigned buflen;
> >+unsigned bulk_qlen;
> >+unsigned iso_qlen;
> >  };
> >
> >  static inline struct f_sourcesink *func_to_ss(struct usb_function *f)
> >@@ -595,31 +590,33 @@ static int source_sink_start_ep(struct f_sourcesink 
> >*ss, bool is_in,
> >  {
> > struct usb_ep   *ep;
> > struct usb_request  *req;
> >-int i, size, status;
> >-
> >-for (i = 0; i < 8; i++) {
> >-if (is_iso) {
> >-switch (speed) {
> >-case USB_SPEED_SUPER:
> >-size = ss->isoc_maxpacket *
> >-(ss->isoc_mult + 1) *
> >-(ss->isoc_maxburst + 1);
> >-break;
> >-case USB_SPEED_HIGH:
> >-size = ss->isoc_maxpacket * (ss->isoc_mult + 1);
> >-break;
> >-default:
> >-size = ss->isoc_maxpacket > 1023 ?
> >-1023 : ss->isoc_maxpacket;
> >-break;
> >-}
> >-ep = is_in ? ss->iso_in_ep : ss->iso_out_ep;
> >-req = ss_alloc_ep_req(ep, size);
> >-} else {
> >-ep = is_in ? ss->in_ep : ss->out_ep;
> >-req = ss_alloc_ep_req(ep, 0);
> >+int i, size, qlen, status = 0;
> >+
> >+if (is_iso) {
> >+switch (speed) {
> >+case USB_SPEED_SUPER:
> >+size = ss->isoc_maxpacket *
> >+(ss->isoc_mult + 1) *
> >+(ss->isoc_maxburst + 1);
> >+break;
> >+case USB_SPEED_HIGH:
> >+size = ss->isoc_maxpacket * (ss->isoc_mult + 1);
> >+break;
> >+default:
> >+size = ss->isoc_maxpacket > 1023 ?
> >+1023 : ss->isoc_maxpacket;
> >+break;
> > }
> >+ep = is_in ? ss->iso_in_ep : ss->iso_out_ep;
> >+qlen = ss->iso_qlen;
> >+} else {
> >+ep = is_in ? ss->in_ep : ss->out_ep;
> >+qlen = ss->bulk_qlen;
> >+size = 0;
> >+}
> >
> >+for (i = 0; i < qlen; i++) {
> >+req = ss_alloc_ep_req(ep, size);
> > if (!req)
> > return -ENOMEM;
> >
> >@@ -639,9 +636,6 @@ static int source_sink_start_ep(struct f_sourcesink *ss, 
> >bool is_in,
> >   ep->name, status);
> > free_ep_req(ep, req);
> 
> Well... to be honest I would prefer to return here an error instead
> of silently try with another request as we may end up in situation
> that qlen is 8 and we haven't successfully enqueued any request but
> we treat this as a success.
> 

Ok, but it seems not related with this patch set, I will change after
this one has queued.

-- 

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

[PATCH v3 5/8] usb: dwc2: host: Keep track of and use our scheduled microframe

[Douglas Anderson]

The microframe scheduler did a lot of work to pick the proper
microframe.  Then dwc2_sched_periodic_split() went ahead and ignored
which microframe we picked if it ever needed to re-assign things.

Let's keep track of the uframe and then we'll always use it.

Signed-off-by: Douglas Anderson 
---
Changes in v3:
- Keep track and use our uframe new for v3.

Changes in v2: None

 drivers/usb/dwc2/hcd.h   |  4 
 drivers/usb/dwc2/hcd_queue.c | 16 +---
 2 files changed, 17 insertions(+), 3 deletions(-)

diff --git a/drivers/usb/dwc2/hcd.h b/drivers/usb/dwc2/hcd.h
index a3dbc561fe3f..ff99cb44c89d 100644
--- a/drivers/usb/dwc2/hcd.h
+++ b/drivers/usb/dwc2/hcd.h
@@ -231,6 +231,9 @@ enum dwc2_transaction_type {
  * @do_split:   Full/low speed endpoint on high-speed hub requires 
split
  * @td_first:   Index of first activated isochronous transfer 
descriptor
  * @td_last:Index of last activated isochronous transfer descriptor
+ * @sched_uframe:   The microframe that we're scheduled to be in (0 - 7).
+ *  Whenever we start a new split this is expected to be 
the
+ *  lower 3 bits of sched_frame.
  * @usecs:  Bandwidth in microseconds per (micro)frame
  * @interval:   Interval between transfers in (micro)frames
  * @sched_frame:(Micro)frame to initialize a periodic transfer.
@@ -263,6 +266,7 @@ struct dwc2_qh {
u8 do_split;
u8 td_first;
u8 td_last;
+   u8 sched_uframe;
u16 usecs;
u16 interval;
u16 sched_frame;
diff --git a/drivers/usb/dwc2/hcd_queue.c b/drivers/usb/dwc2/hcd_queue.c
index 64b779a5c93f..4c1d9cf482d0 100644
--- a/drivers/usb/dwc2/hcd_queue.c
+++ b/drivers/usb/dwc2/hcd_queue.c
@@ -464,8 +464,10 @@ static int dwc2_schedule_periodic(struct dwc2_hsotg 
*hsotg, struct dwc2_qh *qh)
 
/* Set the new frame up */
if (frame >= 0) {
-   qh->sched_frame &= ~0x7;
-   qh->sched_frame |= (frame & 7);
+   qh->sched_uframe = frame;
+
+   /* The next frame that matches our scheduled uframe */
+   qh->sched_frame = ((qh->sched_frame + 7) & ~7) | frame;
dwc2_sch_dbg(hsotg,
 "sched_p %p sch=%04x, uf=%d, us=%d\n",
 qh, qh->sched_frame, frame,
@@ -668,7 +670,15 @@ static void dwc2_sched_periodic_split(struct dwc2_hsotg 
*hsotg,
 qh->interval);
if (dwc2_frame_num_le(qh->sched_frame, frame_number))
qh->sched_frame = frame_number;
-   qh->sched_frame |= 0x7;
+
+   if (hsotg->core_params->uframe_sched > 0)
+   /* The next frame that matches our scheduled uframe */
+   qh->sched_frame = ((qh->sched_frame + 7) & ~7) |
+ qh->sched_uframe;
+   else
+   /* The beginning of the next full frame */
+   qh->sched_frame |= 0x7;
+
qh->start_split_frame = qh->sched_frame;
}
 
-- 
2.6.0.rc2.230.g3dd15c0

--
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 v3 3/8] usb: dwc2: host: Add scheduler tracing

[Douglas Anderson]

In preparation for future changes to the scheduler let's add some
tracing that makes it easy for us to see what's happening.  By default
this tracing will be off.

Note that I've chosen to point tracing at ftrace rather than the console
since performance is pretty critical for these traces and ftrace is more
appropriate for performance-critical traces.

Signed-off-by: Douglas Anderson 
---
Changes in v3:
- scheduler tracing new for v3.

Changes in v2: None

 drivers/usb/dwc2/core.h  |  9 +
 drivers/usb/dwc2/hcd.h   |  5 +
 drivers/usb/dwc2/hcd_intr.c  |  7 ++-
 drivers/usb/dwc2/hcd_queue.c | 24 +++-
 4 files changed, 43 insertions(+), 2 deletions(-)

diff --git a/drivers/usb/dwc2/core.h b/drivers/usb/dwc2/core.h
index a66d3cb62b65..8224a1c21ac3 100644
--- a/drivers/usb/dwc2/core.h
+++ b/drivers/usb/dwc2/core.h
@@ -44,6 +44,15 @@
 #include 
 #include "hw.h"
 
+#ifdef DWC2_TRACE_SCHEDULER
+#define dwc2_scheduler_printk trace_printk
+#else
+#define dwc2_scheduler_printk no_printk
+#endif
+#define dwc2_sch_dbg(hsotg, fmt, ...)  \
+   dwc2_scheduler_printk(pr_fmt("%s: SCH: " fmt),  \
+ dev_name(hsotg->dev), ##__VA_ARGS__)
+
 static inline u32 dwc2_readl(const void __iomem *addr)
 {
u32 value = __raw_readl(addr);
diff --git a/drivers/usb/dwc2/hcd.h b/drivers/usb/dwc2/hcd.h
index 8a4486e1a542..de8c0b0937e6 100644
--- a/drivers/usb/dwc2/hcd.h
+++ b/drivers/usb/dwc2/hcd.h
@@ -554,6 +554,11 @@ static inline u16 dwc2_frame_num_inc(u16 frame, u16 inc)
return (frame + inc) & HFNUM_MAX_FRNUM;
 }
 
+static inline u16 dwc2_frame_num_dec(u16 frame, u16 dec)
+{
+   return (frame + HFNUM_MAX_FRNUM + 1 - dec) & HFNUM_MAX_FRNUM;
+}
+
 static inline u16 dwc2_full_frame_num(u16 frame)
 {
return (frame & HFNUM_MAX_FRNUM) >> 3;
diff --git a/drivers/usb/dwc2/hcd_intr.c b/drivers/usb/dwc2/hcd_intr.c
index 84190243b8be..c3f6200bc630 100644
--- a/drivers/usb/dwc2/hcd_intr.c
+++ b/drivers/usb/dwc2/hcd_intr.c
@@ -135,13 +135,18 @@ static void dwc2_sof_intr(struct dwc2_hsotg *hsotg)
while (qh_entry != &hsotg->periodic_sched_inactive) {
qh = list_entry(qh_entry, struct dwc2_qh, qh_list_entry);
qh_entry = qh_entry->next;
-   if (dwc2_frame_num_le(qh->sched_frame, hsotg->frame_number))
+   if (dwc2_frame_num_le(qh->sched_frame, hsotg->frame_number)) {
+   dwc2_sch_dbg(hsotg,
+"ready %p fn=%04x, sch=%04x\n",
+qh, hsotg->frame_number, qh->sched_frame);
+
/*
 * Move QH to the ready list to be executed next
 * (micro)frame
 */
list_move(&qh->qh_list_entry,
  &hsotg->periodic_sched_ready);
+   }
}
tr_type = dwc2_hcd_select_transactions(hsotg);
if (tr_type != DWC2_TRANSACTION_NONE)
diff --git a/drivers/usb/dwc2/hcd_queue.c b/drivers/usb/dwc2/hcd_queue.c
index 3e1edafc593c..93b26c8fef88 100644
--- a/drivers/usb/dwc2/hcd_queue.c
+++ b/drivers/usb/dwc2/hcd_queue.c
@@ -113,6 +113,9 @@ static void dwc2_qh_init(struct dwc2_hsotg *hsotg, struct 
dwc2_qh *qh,
qh->sched_frame = dwc2_frame_num_inc(hsotg->frame_number,
 SCHEDULE_SLOP);
qh->interval = urb->interval;
+   dwc2_sch_dbg(hsotg, "init %p sch=%04x, fn=%04x, int=%#x\n",
+qh, qh->sched_frame, hsotg->frame_number,
+qh->interval);
 #if 0
/* Increase interrupt polling rate for debugging */
if (qh->ep_type == USB_ENDPOINT_XFER_INT)
@@ -126,6 +129,11 @@ static void dwc2_qh_init(struct dwc2_hsotg *hsotg, struct 
dwc2_qh *qh,
qh->interval *= 8;
qh->sched_frame |= 0x7;
qh->start_split_frame = qh->sched_frame;
+   dwc2_sch_dbg(hsotg,
+"init*8 %p sch=%04x, fn=%04x, int=%#x\n",
+qh, qh->sched_frame, hsotg->frame_number,
+qh->interval);
+
}
dev_dbg(hsotg->dev, "interval=%d\n", qh->interval);
}
@@ -482,6 +490,8 @@ static int dwc2_schedule_periodic(struct dwc2_hsotg *hsotg, 
struct dwc2_qh *qh)
if (frame >= 0) {
qh->sched_frame &= ~0x7;
qh->sched_frame |= (frame & 7);
+   dwc2_sch_dbg(hsotg, "sched_p %p sch=%04x, uf=%d\n",
+qh, qh->sched_frame, frame);
}
 
if (status > 0)
@@ -583,10 +593,16 @@ int dwc2_hcd_qh_add(struct dwc2_hsotg *hsotg, struct 
dwc2_qh *qh)
 
 

[PATCH v3 6/8] usb: dwc2: host: Assume all devices are on one single_tt hub

[Douglas Anderson]

Until we have logic to determine which devices share the same TT let's
add logic to assume that all devices on a given dwc2 controller are on
one single_tt hub.  This is better than the previous code that assumed
that all devices were on one multi_tt hub, since single_tt hubs
appear (in my experience) to be much more common and any schedule that
would work on a single_tt hub will also work on a multi_tt hub.  This
will prevent more than 8 total low/full speed devices to be on the bus
at one time, but that's a reasonable restriction until we've made things
smarter.

Signed-off-by: Douglas Anderson 
---
Changes in v3:
- Assuming single_tt is new for v3; not terribly well tested (yet).

Changes in v2: None

 drivers/usb/dwc2/core.h  |  1 +
 drivers/usb/dwc2/hcd_queue.c | 40 +++-
 2 files changed, 40 insertions(+), 1 deletion(-)

diff --git a/drivers/usb/dwc2/core.h b/drivers/usb/dwc2/core.h
index 567ee2c9e69f..09aa2b5ae29e 100644
--- a/drivers/usb/dwc2/core.h
+++ b/drivers/usb/dwc2/core.h
@@ -782,6 +782,7 @@ struct dwc2_hsotg {
u16 periodic_usecs;
unsigned long periodic_bitmap[DIV_ROUND_UP(TOTAL_PERIODIC_USEC,
   BITS_PER_LONG)];
+   bool has_split[8];
u16 frame_number;
u16 periodic_qh_count;
bool bus_suspended;
diff --git a/drivers/usb/dwc2/hcd_queue.c b/drivers/usb/dwc2/hcd_queue.c
index 4c1d9cf482d0..c5a2edb04bec 100644
--- a/drivers/usb/dwc2/hcd_queue.c
+++ b/drivers/usb/dwc2/hcd_queue.c
@@ -372,10 +372,33 @@ static int dwc2_find_single_uframe(struct dwc2_hsotg 
*hsotg, struct dwc2_qh *qh)
  */
 static int dwc2_find_multi_uframe(struct dwc2_hsotg *hsotg, struct dwc2_qh *qh)
 {
+   unsigned long tmp_bmp[DIV_ROUND_UP(TOTAL_PERIODIC_USEC, BITS_PER_LONG)];
+   unsigned long *bmp;
unsigned short utime = qh->usecs;
unsigned long start;
+   int i;
+
+   if (qh->do_split) {
+   /*
+* Eventually we'll only want to exclude out microframes used by
+* other people on the same TT as us, and then only if we're on
+* a single_tt hub.  ...but until we have that logic, just
+* schedule everyone together.
+*/
+   bmp = tmp_bmp;
+   memcpy(bmp, hsotg->periodic_bitmap, sizeof(tmp_bmp));
+   start = 0;
+
+   for (i = 0; i < ARRAY_SIZE(max_uframe_usecs); i++) {
+   if (hsotg->has_split[i])
+   bitmap_set(bmp, start, max_uframe_usecs[i]);
+   start += max_uframe_usecs[i];
+   }
+   } else {
+   bmp = hsotg->periodic_bitmap;
+   }
 
-   start = bitmap_find_next_zero_area(hsotg->periodic_bitmap,
+   start = bitmap_find_next_zero_area(bmp,
   TOTAL_PERIODIC_USEC, 0, utime, 0);
if (start >= TOTAL_PERIODIC_USEC) {
dwc2_sch_dbg(hsotg, "%s: failed to assign %d us\n",
@@ -386,6 +409,13 @@ static int dwc2_find_multi_uframe(struct dwc2_hsotg 
*hsotg, struct dwc2_qh *qh)
bitmap_set(hsotg->periodic_bitmap, start, qh->usecs);
qh->start_usecs = start;
 
+   if (qh->do_split) {
+   for (i = start / EARLY_FRAME_USEC;
+i < DIV_ROUND_UP(start + utime - 1, EARLY_FRAME_USEC);
+i++)
+   hsotg->has_split[i] = true;
+   }
+
dwc2_sch_dbg(hsotg, "%s: assigned %d us @ %d us\n",
 __func__, qh->usecs, qh->start_usecs);
 
@@ -533,6 +563,7 @@ static void dwc2_deschedule_periodic(struct dwc2_hsotg 
*hsotg,
 {
int start = qh->start_usecs;
int utime = qh->usecs;
+   int i;
 
list_del_init(&qh->qh_list_entry);
 
@@ -546,6 +577,13 @@ static void dwc2_deschedule_periodic(struct dwc2_hsotg 
*hsotg,
}
 
bitmap_clear(hsotg->periodic_bitmap, start, utime);
+
+   if (qh->do_split) {
+   for (i = start / EARLY_FRAME_USEC;
+i < DIV_ROUND_UP(start + utime - 1, EARLY_FRAME_USEC);
+i++)
+   hsotg->has_split[i] = false;
+   }
 }
 
 /**
-- 
2.6.0.rc2.230.g3dd15c0

--
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 v3 7/8] usb: dwc2: host: Add a delay before releasing periodic bandwidth

[Douglas Anderson]

We'd like to be able to use HCD_BH in order to speed up the dwc2 host
interrupt handler quite a bit.  However, according to the kernel doc for
usb_submit_urb() (specifically the part about "Reserved Bandwidth
Transfers"), we need to keep a reservation active as long as a device
driver keeps submitting.  That was easy to do when we gave back the URB
in the interrupt context: we just looked at when our queue was empty and
released the reserved bandwidth then.  ...but now we need a little more
complexity.

We'll follow EHCI's lead in commit 9118f9eb4f1e ("USB: EHCI: improve
interrupt qh unlink") and add a 5ms delay.  Since we don't have a whole
timer infrastructure in dwc2, we'll just add a timer per QH.  The
overhead for this is very small.

Signed-off-by: Douglas Anderson 
---
Changes in v3:
- Moved periodic bandwidth release delay patch later in the series.

Changes in v2:
- Periodic bandwidth release delay new for V2

 drivers/usb/dwc2/hcd.h   |   6 ++
 drivers/usb/dwc2/hcd_queue.c | 252 ---
 2 files changed, 193 insertions(+), 65 deletions(-)

diff --git a/drivers/usb/dwc2/hcd.h b/drivers/usb/dwc2/hcd.h
index ff99cb44c89d..2d9bb45c1777 100644
--- a/drivers/usb/dwc2/hcd.h
+++ b/drivers/usb/dwc2/hcd.h
@@ -211,6 +211,7 @@ enum dwc2_transaction_type {
 /**
  * struct dwc2_qh - Software queue head structure
  *
+ * @hsotg:  The HCD state structure for the DWC OTG controller
  * @ep_type:Endpoint type. One of the following values:
  *   - USB_ENDPOINT_XFER_CONTROL
  *   - USB_ENDPOINT_XFER_BULK
@@ -250,13 +251,16 @@ enum dwc2_transaction_type {
  * @n_bytes:Xfer Bytes array. Each element corresponds to a 
transfer
  *  descriptor and indicates original XferSize value for 
the
  *  descriptor
+ * @unreserve_timer:Timer for releasing periodic reservation.
  * @tt_buffer_dirty True if clear_tt_buffer_complete is pending
+ * @unreserve_pending:  True if we planned to unreserve but haven't yet.
  *
  * A Queue Head (QH) holds the static characteristics of an endpoint and
  * maintains a list of transfers (QTDs) for that endpoint. A QH structure may
  * be entered in either the non-periodic or periodic schedule.
  */
 struct dwc2_qh {
+   struct dwc2_hsotg *hsotg;
u8 ep_type;
u8 ep_is_in;
u16 maxp;
@@ -279,7 +283,9 @@ struct dwc2_qh {
struct dwc2_hcd_dma_desc *desc_list;
dma_addr_t desc_list_dma;
u32 *n_bytes;
+   struct timer_list unreserve_timer;
unsigned tt_buffer_dirty:1;
+   unsigned unreserve_pending:1;
 };
 
 /**
diff --git a/drivers/usb/dwc2/hcd_queue.c b/drivers/usb/dwc2/hcd_queue.c
index c5a2edb04bec..a287e52f9a63 100644
--- a/drivers/usb/dwc2/hcd_queue.c
+++ b/drivers/usb/dwc2/hcd_queue.c
@@ -53,6 +53,101 @@
 #include "core.h"
 #include "hcd.h"
 
+/* Wait this long before releasing periodic reservation */
+#define DWC2_UNRESERVE_DELAY (msecs_to_jiffies(5))
+
+/**
+ * dwc2_do_unreserve() - Actually release the periodic reservation
+ *
+ * This function actually releases the periodic bandwidth that was reserved
+ * by the given qh.
+ *
+ * @hsotg: The HCD state structure for the DWC OTG controller
+ * @qh:QH for the periodic transfer.
+ */
+static void dwc2_do_unreserve(struct dwc2_hsotg *hsotg, struct dwc2_qh *qh)
+{
+   int start = qh->start_usecs;
+   int utime = qh->usecs;
+   int i;
+
+   assert_spin_locked(&hsotg->lock);
+
+   WARN_ON(!qh->unreserve_pending);
+
+   /* No more unreserve pending--we're doing it */
+   qh->unreserve_pending = false;
+
+   if (WARN_ON(!list_empty(&qh->qh_list_entry)))
+   list_del_init(&qh->qh_list_entry);
+
+   /* Update claimed usecs per (micro)frame */
+   hsotg->periodic_usecs -= qh->usecs;
+
+   /* Release periodic channel reservation */
+   if (hsotg->core_params->uframe_sched <= 0) {
+   hsotg->periodic_channels--;
+   return;
+   }
+
+   bitmap_clear(hsotg->periodic_bitmap, start, utime);
+
+   if (qh->do_split) {
+   for (i = start / EARLY_FRAME_USEC;
+i < DIV_ROUND_UP(start + utime - 1, EARLY_FRAME_USEC);
+i++)
+   hsotg->has_split[i] = false;
+   }
+}
+
+/**
+ * dwc2_unreserve_timer_fn() - Timer function to release periodic reservation
+ *
+ * According to the kernel doc for usb_submit_urb() (specifically the part 
about
+ * "Reserved Bandwidth Transfers"), we need to keep a reservation active as
+ * long as a device driver keeps submitting.  Since we're using HCD_BH to give
+ * back the URB we need to give the driver a little bit of time before we
+ * release the reservation.  This worker is called after the appropriate
+ * delay.
+ *
+ * @work: Pointer to a qh unreserve_work.
+ */
+static void dwc2_unreserve_timer_fn(unsigned long data)
+{
+   struct 

[PATCH v3 8/8] usb: dwc2: host: Giveback URB in tasklet context

[Douglas Anderson]

In commit 94dfd7edfd5c ("USB: HCD: support giveback of URB in tasklet
context") support was added to give back the URB in tasklet context.
Let's take advantage of this in dwc2.

This speeds up the dwc2 interrupt handler considerably.

Note that this requires the change ("usb: dwc2: host: Add a delay before
releasing periodic bandwidth") to come first.

Signed-off-by: Douglas Anderson 
Tested-by: Heiko Stuebner 
---
Changes in v3: None
Changes in v2:
- Commit message now says that URB giveback change needs delay change.

 drivers/usb/dwc2/hcd.c | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/drivers/usb/dwc2/hcd.c b/drivers/usb/dwc2/hcd.c
index 803992985935..5fc86aad542e 100644
--- a/drivers/usb/dwc2/hcd.c
+++ b/drivers/usb/dwc2/hcd.c
@@ -2266,9 +2266,7 @@ void dwc2_host_complete(struct dwc2_hsotg *hsotg, struct 
dwc2_qtd *qtd,
kfree(qtd->urb);
qtd->urb = NULL;
 
-   spin_unlock(&hsotg->lock);
usb_hcd_giveback_urb(dwc2_hsotg_to_hcd(hsotg), urb, status);
-   spin_lock(&hsotg->lock);
 }
 
 /*
@@ -2881,7 +2879,7 @@ static struct hc_driver dwc2_hc_driver = {
.hcd_priv_size = sizeof(struct wrapper_priv_data),
 
.irq = _dwc2_hcd_irq,
-   .flags = HCD_MEMORY | HCD_USB2,
+   .flags = HCD_MEMORY | HCD_USB2 | HCD_BH,
 
.start = _dwc2_hcd_start,
.stop = _dwc2_hcd_stop,
-- 
2.6.0.rc2.230.g3dd15c0

--
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 v3 0/8] dwc2: Fix uframe scheduler + speed up the interrupt handler quite a bit

[Douglas Anderson]

This series now effectively has two purposes:
1. Speed up dwc2 interrupt latency.
2. Start fixing up the microframe scheduler.

...the two things were separate series in the past but they ended up
running into each other, so now they're combined.

To summarize what we have here:

1. usb: dwc2: rockchip: Make the max_transfer_size automatic

   No brainer.  Can land any time.

2. usb: dwc2: host: Get aligned DMA in a more supported way

   Although this touches a lot of code, it's mostly just deleting
   stuff.  The way this is working is nearly the same as tegra.  Biggest
   objection I expect is that it has too much duplication with tegra and
   musb.  I'd personally prefer to land it now and remove duplication
   later, but up to others.  Speeding up interrupt handler helps with
   SOF scheduling, so this is not just a dumb optimization.

3. usb: dwc2: host: Add scheduler tracing

   Useful for patches below.

4. usb: dwc2: host: Rewrite the microframe scheduler

   Seems hard to believe this would make things worse since the old
   scheduler is easy to break.  Certainly microframe scheduler isn't
   amazing, but small steps, right?

5. usb: dwc2: host: Keep track of and use our scheduled microframe

   Needs review, but seems simple to me.  Maybe doesn't fix everything,
   but fixes some things...

6. usb: dwc2: host: Assume all devices are on one single_tt hub

   Questionable, but maybe worth landing it?

7. usb: dwc2: host: Add a delay before releasing periodic bandwidth

   Pretty much the same patch I sent before, just rebased.

8. usb: dwc2: host: Giveback URB in tasklet context

   Simple and a nice speedup assuming it doesn't break anything.  My
   belief is that our scheduler is already broken enough that things
   aren't made worse by this patch (and lots of things are made better
   by speeding up the interrupt handler and not mising SOFs), but
   welcome other testing and opinions.

===

Below is discussion of some of the speedup stuff.

===

The dwc2 interrupt handler is quite slow.  On rk3288 with a few things
plugged into the ports and with cpufreq locked at 696MHz (to simulate
real world idle system), I can easily observe dwc2_handle_hcd_intr()
taking > 120 us, sometimes > 150 us.  Note that SOF interrupts come
every 125 us with high speed USB, so taking > 120 us in the interrupt
handler is a big deal.

The patches here will speed up the interrupt controller significantly.
After this series, I have a hard time seeing the interrupt controller
taking > 20 us and I don't ever see it taking > 30 us ever in my tests
unless I bring the cpufreq back down.  With the cpufreq at 126 MHz I can
still see the interrupt handler take > 50 us, so I'm sure we could
improve this further.  ...but hey, it's a start.

This series also shows big speed improvements when testing with a USB
Gigabit Ethernet adapter.  Previously the tested adapter would top out
at about 15MB/s.  After these changes it gets about 23MB/s.

In addition to the speedup, this series also has the advantage of
simplifying dwc2 and making it more like everyone else (introducing the
possibility of future simplifications).  Picking this series up will
help your diffstat and likely win you friends.  ;)

===

Steps for gathering data with ftrace:

cd /sys/devices/system/cpu/cpu0/cpufreq/
echo userspace > scaling_governor
echo 696000 > scaling_setspeed

cd /sys/kernel/debug/tracing
echo 0 > tracing_on
echo "" > trace
echo nop > current_tracer
echo function_graph > current_tracer
echo dwc2_handle_hcd_intr > set_graph_function
echo dwc2_handle_common_intr >> set_graph_function
echo dwc2_handle_hcd_intr > set_ftrace_filter
echo dwc2_handle_common_intr >> set_ftrace_filter
echo funcgraph-abstime > trace_options
echo 70 > tracing_thresh
echo 1 > /sys/kernel/debug/tracing/tracing_on

sleep 2
cat trace

===

NOTE: This series doesn't replace any other patches I've submitted
recently, it merely adds another set of changes that upstream could
benefit from.

Changes in v3:
- scheduler tracing new for v3.
- The uframe scheduler patch is folded into optimization series.
- Optimize uframe scheduler "single uframe" case a little.
- uframe scheduler now atop logging patches.
- uframe scheduler now before delayed bandwidth release patches.
- Add defines like EARLY_FRAME_USEC
- Reorder dwc2_deschedule_periodic() in prep for future patches.
- uframe scheduler now shows real usefulness w/ future patches!
- Keep track and use our uframe new for v3.
- Assuming single_tt is new for v3; not terribly well tested (yet).
- Moved periodic bandwidth release delay patch later in the series.

Changes in v2:
- Add a warn if setup_dma is not aligned (Julius Werner).
- Totally rewrote uframe scheduler again after writing test code.
- uframe scheduler atop delayed bandwidth release patches.
- Periodic bandwidth release delay new for V2
- Commit message now says that URB giveback change needs delay change.

Douglas Anderson (8):
  usb: dwc2: rockchip: Make the max_transfer_size

[PATCH v3 4/8] usb: dwc2: host: Rewrite the microframe scheduler

[Douglas Anderson]

The old microframe scheduler was hard to follow and had some bugs in
it.  Specifically, I made some code to visualize what was happening and
found:

Add W (280 us):
  WW|WW|  |  |  |  |   |
Add B (260 us):
  WW|WW|BB|BB|BB|  |   |
Add C ( 80 us):
  WW|WW|BB|BB|BB|CC|CC |
Add K ( 10 us):
  WW|WW|BB|BB|BB|K |   |
Add S (170 us):
  SS|SSS   |BB|BB|BB|K |   |
Add L ( 60 us):
  SS|SSSLLL|LLL BB|BB|BB|K |   |
Add W ( 60 us):
  SS|SSSLLL|LLLWBB|BB|BB|KW|   |

As you can see, the "W" is broken up in a bogus way.  It's in microframe
2 and microframe 5.  It's easy to find more examples of bugs with more
testing.

As a first step toward fixing things, let's first change the scheduling
functions to do what I believe was the intent of the old function.  This
new code uses the existing Linux bitmap code to avoid reinventing the
wheel.  You can see (ugly) test code for this up on pastebin:
  http://pastebin.com/PjxktNYA

Note that the frames picked by the microframe scheduler functions aren't
properly used yet elsewhere, so this patch won't really have much of an
effect.  See future patches in the series.

Signed-off-by: Douglas Anderson 
---
Changes in v3:
- The uframe scheduler patch is folded into optimization series.
- Optimize uframe scheduler "single uframe" case a little.
- uframe scheduler now atop logging patches.
- uframe scheduler now before delayed bandwidth release patches.
- Add defines like EARLY_FRAME_USEC
- Reorder dwc2_deschedule_periodic() in prep for future patches.
- uframe scheduler now shows real usefulness w/ future patches!

Changes in v2:
- Totally rewrote uframe scheduler again after writing test code.
- uframe scheduler atop delayed bandwidth release patches.

 drivers/usb/dwc2/core.h  |  10 +++-
 drivers/usb/dwc2/hcd.c   |   3 -
 drivers/usb/dwc2/hcd.h   |   5 +-
 drivers/usb/dwc2/hcd_intr.c  |   5 +-
 drivers/usb/dwc2/hcd_queue.c | 134 ++-
 5 files changed, 69 insertions(+), 88 deletions(-)

diff --git a/drivers/usb/dwc2/core.h b/drivers/usb/dwc2/core.h
index 8224a1c21ac3..567ee2c9e69f 100644
--- a/drivers/usb/dwc2/core.h
+++ b/drivers/usb/dwc2/core.h
@@ -658,7 +658,7 @@ struct dwc2_hregs_backup {
  *  This value is in microseconds per (micro)frame. The
  *  assumption is that all periodic transfers may occur in
  *  the same (micro)frame.
- * @frame_usecs:Internal variable used by the microframe scheduler
+ * @periodic_bitmap:Bitmap used by the microframe scheduler
  * @frame_number:   Frame number read from the core at SOF. The value 
ranges
  *  from 0 to HFNUM_MAX_FRNUM.
  * @periodic_qh_count:  Count of periodic QHs, if using several eps. Used for
@@ -753,6 +753,11 @@ struct dwc2_hsotg {
 #define DWC2_CORE_REV_3_00a0x4f54300a
 
 #if IS_ENABLED(CONFIG_USB_DWC2_HOST) || IS_ENABLED(CONFIG_USB_DWC2_DUAL_ROLE)
+
+/* Total number of microseconds for scheduling */
+#define EARLY_FRAME_USEC   100
+#define TOTAL_PERIODIC_USEC(6 * EARLY_FRAME_USEC + 30)
+
union dwc2_hcd_internal_flags {
u32 d32;
struct {
@@ -775,7 +780,8 @@ struct dwc2_hsotg {
struct list_head periodic_sched_assigned;
struct list_head periodic_sched_queued;
u16 periodic_usecs;
-   u16 frame_usecs[8];
+   unsigned long periodic_bitmap[DIV_ROUND_UP(TOTAL_PERIODIC_USEC,
+  BITS_PER_LONG)];
u16 frame_number;
u16 periodic_qh_count;
bool bus_suspended;
diff --git a/drivers/usb/dwc2/hcd.c b/drivers/usb/dwc2/hcd.c
index 33495b235b3c..803992985935 100644
--- a/drivers/usb/dwc2/hcd.c
+++ b/drivers/usb/dwc2/hcd.c
@@ -3091,9 +3091,6 @@ int dwc2_hcd_init(struct dwc2_hsotg *hsotg, int irq)
hsotg->hc_ptr_array[i] = channel;
}
 
-   if (hsotg->core_params->uframe_sched > 0)
-   dwc2_hcd_init_usecs(hsotg);
-
/* Initialize hsotg start work */
INIT_DELAYED_WORK(&hsotg->start_work, dwc2_hcd_start_func);
 
diff --git a/drivers/usb/dwc2/hcd.h b/drivers/usb/dwc2/hcd.h
index de8c0b0937e6..a3dbc561fe3f 100644
--- a/drivers/usb/dwc2/hcd.h
+++ b/drivers/usb/dwc2/hcd.h
@@ -235,7 +235,7 @@ enum dwc2_transaction_type {
  * @interval:   Interval between transfers in (micro)frames
  * @sched_frame:(Micro)frame to initialize a periodic transfer.
  *  The transfer executes in the following (micro)frame.
- * @frame_usecs:Internal variable used by the microframe scheduler
+ * @start_usecs:Exact start microsecond value.
  * @start_split

[PATCH v3 1/8] usb: dwc2: rockchip: Make the max_transfer_size automatic

[Douglas Anderson]

Previously we needed to set the max_transfer_size to explicitly be 65535
because the old driver would detect that our hardware could support much
bigger transfers and then would try to do them.  This wouldn't work
since the DMA alignment code couldn't support it.

Later in commit e8f8c14d9da7 ("usb: dwc2: clip max_transfer_size to
65535") upstream added support for clipping this automatically.  Since
that commit it has been OK to just use "-1" (default), but nobody
bothered to change it.

Let's change it to default now for two reasons:
- It's nice to use autodetected params.
- If we can remove the 65535 limit, we can transfer more!

Signed-off-by: Douglas Anderson 
Tested-by: Heiko Stuebner 
---
Changes in v3: None
Changes in v2: None

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

diff --git a/drivers/usb/dwc2/platform.c b/drivers/usb/dwc2/platform.c
index 5859b0fa19ee..f26e0c31c07e 100644
--- a/drivers/usb/dwc2/platform.c
+++ b/drivers/usb/dwc2/platform.c
@@ -95,7 +95,7 @@ static const struct dwc2_core_params params_rk3066 = {
.host_rx_fifo_size  = 520,  /* 520 DWORDs */
.host_nperio_tx_fifo_size   = 128,  /* 128 DWORDs */
.host_perio_tx_fifo_size= 256,  /* 256 DWORDs */
-   .max_transfer_size  = 65535,
+   .max_transfer_size  = -1,
.max_packet_count   = -1,
.host_channels  = -1,
.phy_type   = -1,
-- 
2.6.0.rc2.230.g3dd15c0

--
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 v3 2/8] usb: dwc2: host: Get aligned DMA in a more supported way

[Douglas Anderson]

All other host controllers who want aligned buffers for DMA do it a
certain way.  Let's do that too instead of working behind the USB core's
back.  This makes our interrupt handler not take forever and also rips
out a lot of code, simplifying things a bunch.

This also has the side effect of removing the 65535 max transfer size
limit.

NOTE: The actual code to allocate the aligned buffers is ripped almost
completely from the tegra EHCI driver.  At some point in the future we
may want to add this functionality to the USB core to share more code
everywhere.

Signed-off-by: Douglas Anderson 
Tested-by: Heiko Stuebner 
---
Changes in v3: None
Changes in v2:
- Add a warn if setup_dma is not aligned (Julius Werner).

 drivers/usb/dwc2/core.c  |  21 +-
 drivers/usb/dwc2/hcd.c   | 170 +--
 drivers/usb/dwc2/hcd.h   |  10 ---
 drivers/usb/dwc2/hcd_intr.c  |  65 -
 drivers/usb/dwc2/hcd_queue.c |   7 +-
 5 files changed, 87 insertions(+), 186 deletions(-)

diff --git a/drivers/usb/dwc2/core.c b/drivers/usb/dwc2/core.c
index ef73e498e98f..7e28cfafcfd8 100644
--- a/drivers/usb/dwc2/core.c
+++ b/drivers/usb/dwc2/core.c
@@ -1830,19 +1830,11 @@ void dwc2_hc_start_transfer(struct dwc2_hsotg *hsotg,
}
 
if (hsotg->core_params->dma_enable > 0) {
-   dma_addr_t dma_addr;
-
-   if (chan->align_buf) {
-   if (dbg_hc(chan))
-   dev_vdbg(hsotg->dev, "align_buf\n");
-   dma_addr = chan->align_buf;
-   } else {
-   dma_addr = chan->xfer_dma;
-   }
-   dwc2_writel((u32)dma_addr, hsotg->regs + HCDMA(chan->hc_num));
+   dwc2_writel((u32)chan->xfer_dma,
+   hsotg->regs + HCDMA(chan->hc_num));
if (dbg_hc(chan))
dev_vdbg(hsotg->dev, "Wrote %08lx to HCDMA(%d)\n",
-(unsigned long)dma_addr, chan->hc_num);
+(unsigned long)chan->xfer_dma, chan->hc_num);
}
 
/* Start the split */
@@ -3137,13 +3129,6 @@ int dwc2_get_hwparams(struct dwc2_hsotg *hsotg)
width = (hwcfg3 & GHWCFG3_XFER_SIZE_CNTR_WIDTH_MASK) >>
GHWCFG3_XFER_SIZE_CNTR_WIDTH_SHIFT;
hw->max_transfer_size = (1 << (width + 11)) - 1;
-   /*
-* Clip max_transfer_size to 65535. dwc2_hc_setup_align_buf() allocates
-* coherent buffers with this size, and if it's too large we can
-* exhaust the coherent DMA pool.
-*/
-   if (hw->max_transfer_size > 65535)
-   hw->max_transfer_size = 65535;
width = (hwcfg3 & GHWCFG3_PACKET_SIZE_CNTR_WIDTH_MASK) >>
GHWCFG3_PACKET_SIZE_CNTR_WIDTH_SHIFT;
hw->max_packet_count = (1 << (width + 4)) - 1;
diff --git a/drivers/usb/dwc2/hcd.c b/drivers/usb/dwc2/hcd.c
index e79baf73c234..33495b235b3c 100644
--- a/drivers/usb/dwc2/hcd.c
+++ b/drivers/usb/dwc2/hcd.c
@@ -598,9 +598,9 @@ static void dwc2_hc_init_split(struct dwc2_hsotg *hsotg,
chan->hub_port = (u8)hub_port;
 }
 
-static void *dwc2_hc_init_xfer(struct dwc2_hsotg *hsotg,
-  struct dwc2_host_chan *chan,
-  struct dwc2_qtd *qtd, void *bufptr)
+static void dwc2_hc_init_xfer(struct dwc2_hsotg *hsotg,
+ struct dwc2_host_chan *chan,
+ struct dwc2_qtd *qtd)
 {
struct dwc2_hcd_urb *urb = qtd->urb;
struct dwc2_hcd_iso_packet_desc *frame_desc;
@@ -620,7 +620,6 @@ static void *dwc2_hc_init_xfer(struct dwc2_hsotg *hsotg,
else
chan->xfer_buf = urb->setup_packet;
chan->xfer_len = 8;
-   bufptr = NULL;
break;
 
case DWC2_CONTROL_DATA:
@@ -647,7 +646,6 @@ static void *dwc2_hc_init_xfer(struct dwc2_hsotg *hsotg,
chan->xfer_dma = hsotg->status_buf_dma;
else
chan->xfer_buf = hsotg->status_buf;
-   bufptr = NULL;
break;
}
break;
@@ -680,14 +678,6 @@ static void *dwc2_hc_init_xfer(struct dwc2_hsotg *hsotg,
 
chan->xfer_len = frame_desc->length - qtd->isoc_split_offset;
 
-   /* For non-dword aligned buffers */
-   if (hsotg->core_params->dma_enable > 0 &&
-   (chan->xfer_dma & 0x3))
-   bufptr = (u8 *)urb->buf + frame_desc->offset +
-   qtd->isoc_split_offset;
-   else
-   bufptr = NULL;
-
if (chan->xact_pos == DWC2_HCSPLT_XACTPOS_ALL) {
if (chan->xfer_len <= 188)
chan->xact_pos = DWC2_HCSPLT

Re: [PATCH v2 1/2] usb: dwc2: host: Fix missing device insertions

[Doug Anderson]

Alan,

On Mon, Nov 16, 2015 at 12:31 PM, Alan Stern  wrote:
> On Mon, 16 Nov 2015, Doug Anderson wrote:
>
>> Alan,
>>
>> On Mon, Nov 16, 2015 at 11:31 AM, Alan Stern  
>> wrote:
>> > On Mon, 16 Nov 2015, Doug Anderson wrote:
>> >
>> >> ---
>> >>
>> >> usb: dwc2: host: Fix missing device insertions
>> >>
>> >> If you've got your interrupt signals bouncing a bit as you insert your
>> >> USB device, you might end up in a state when the device is connected but
>> >> the driver doesn't know it.
>> >>
>> >> Specifically, the observed order is:
>> >>  1. hardware sees connect
>> >>  2. hardware sees disconnect
>> >>  3. hardware sees connect
>> >>  4. dwc2_port_intr() - clears connect interrupt
>> >>  5. dwc2_handle_common_intr() - calls dwc2_hcd_disconnect()
>> >>
>> >> Now you'll be stuck with the cable plugged in and no further interrupts
>> >> coming in but the driver will think we're disconnected.
>> >>
>> >> We'll fix this by checking for the missing connect interrupt and
>> >> re-connecting after the disconnect is posted.  We don't skip the
>> >> disconnect because if there is a transitory disconnect we really want to
>> >> de-enumerate and re-enumerate.
>> >
>> > Why do you need to do anything special here?  Normally a driver's
>> > interrupt handler should query the hardware status after clearing the
>> > interrupt source.  That way no transitions ever get missed.
>> >
>> > In your example, at step 5 the dwc2 driver would check the port status
>> > and see that it currently is connected.  Therefore the driver would
>> > pass a "connect status changed" event to the USB core and set the port
>> > status to "connected".  No extra checking is needed, and transitory
>> > connects or disconnects get handled correctly.
>>
>> Things are pretty ugly at the moment because the dwc2 interrupt
>> handler is split in two.  There's dwc2_handle_hcd_intr() and
>> dwc2_handle_common_intr().  Both are registered for the same "shared"
>> IRQ.  If I had to guess, I'd say that this is probably because someone
>> wanted to assign the ".irq" field in the "struct hc_driver" for the
>> host controller but that they also needed the other interrupt handler
>> to handle things shared between host and gadget mode.
>>
>> In any case, one of these two interrupt routines handles connect and
>> the other disconnect.  That's pretty ugly but means that you can't
>> just rely on standard techniques for keeping things in sync.
>
> Okay, that is rather weird.  Still, I don't see why it should matter.
>
> Fundamentally there's no difference between a "connect" interrupt and a
> "disconnect" interrupt.  They should both do exactly the same things:
> clear the interrupt source, post a "connection change" event, and set
> the driver's connect status based on the hardware's current state.
> The second and third parts can be handled by a shared subroutine.

Ah, sorry I misunderstood.  OK, fair enough.  So you're saying that
the problem is that dwc2_hcd_disconnect() has a line that looks like
this:

  hsotg->flags.b.port_connect_status = 0;

...and the dwc2_port_intr() has a line that looks like this:

  hsotg->flags.b.port_connect_status = 1;

...and both should just query the status.


Do you think we should to block landing this patch on cleaning up how
dwc2 handles port_connect_status?  I'm not sure what side effects
changing port_connect_status will have, so I'll need to test and dig a
bit...

I'm currently working on trying to fix the microframe scheduler and
was planning to post the next series of patches there pretty soon.
I'm also planning to keep digging to figure out how to overall
increase compatibility with devices (and compatibility with many
devices plugged in).

If it were up to me, I'd prefer to land this patch in either 4.4 or
4.5 since it does seem to work.  ...then put seeing what we can do to
cleanup all of the port_connect_status on the todo list.

Julius points out in his response that there are comments saying that
HPRT0 can't be read in device mode.  John: since you're setup to test
device mode, can you check if my patch (which now adds a read of
HPRT0) will cause problems? Maybe holding this off and keeping it out
of the RC is a good idea after all...


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

[PATCHv3] Input: xpad - Fix double URB submission races

[Laura Abbott]

The xpad driver has several races with respect to URB submission which
make it easy to end up with submission while active:

[ cut here ]
WARNING: CPU: 3 PID: 3563 at drivers/usb/core/urb.c:339
usb_submit_urb+0x2ad/0x5a0()
URB 8804078ac240 submitted while active
CPU: 3 PID: 3563 Comm: led_test.sh Not tainted 4.2.0-rc4-xpad+ #14
Hardware name: LENOVO 20BFS0EC00/20BFS0EC00, BIOS GMET62WW (2.10 )
03/19/2014
 17a45bc6 8800c9a0fbd8 81758a11
 8800c9a0fc30 8800c9a0fc18 8109b656
0002 8804078ac240 00d0 8800c9806d60
Call Trace:
[] dump_stack+0x45/0x57
[] warn_slowpath_common+0x86/0xc0
[] warn_slowpath_fmt+0x55/0x70
[] ? do_truncate+0x88/0xc0
[] usb_submit_urb+0x2ad/0x5a0
[] ? mntput+0x24/0x40
[] ? terminate_walk+0xc7/0xe0
[] xpad_send_led_command+0xc7/0x110 [xpad]
[] xpad_led_set+0x15/0x20 [xpad]
[] led_set_brightness+0x88/0xc0
[] brightness_store+0x7e/0xc0
[] dev_attr_store+0x18/0x30
[] sysfs_kf_write+0x37/0x40
[] kernfs_fop_write+0x11d/0x170
[] __vfs_write+0x37/0x100
[] ? __sb_start_write+0x58/0x110
[] ? security_file_permission+0x3d/0xc0
[] vfs_write+0xa6/0x1a0
[] ? filp_close+0x5a/0x80
[] SyS_write+0x55/0xc0
[] entry_SYSCALL_64_fastpath+0x12/0x71
---[ end trace f573b768c94a66d6 ]---

This is easily reproducible with

while true; do
for i in $(seq 0 5); do
echo $i > /sys/class/leds/xpad0/subsystem/xpad0/brightness
done
done

xpad_send_led_command attempts to protect against races by locking
around usb_submit_urb. This is not sufficent since usb_submit_urb
is asynchronous; the urb is considered to be in use until the callback
(xpad_irq_out) returns appropriately. Additionally, there is no
protection at all in xpad_play_effect which uses the same urb. Fix this
by only allowing URB submission after the IRQ callback is complete.
If another request comes in which URB submission is in progress, the
request may be stored for submission later.

Signed-off-by: Laura Abbott 
---
v3: Only keep a buffer of one command instead of all the commands
---
 drivers/input/joystick/xpad.c | 295 --
 1 file changed, 201 insertions(+), 94 deletions(-)

diff --git a/drivers/input/joystick/xpad.c b/drivers/input/joystick/xpad.c
index fd4100d..6a90cd5 100644
--- a/drivers/input/joystick/xpad.c
+++ b/drivers/input/joystick/xpad.c
@@ -317,6 +317,14 @@ static struct usb_device_id xpad_table[] = {
 
 MODULE_DEVICE_TABLE(usb, xpad_table);
 
+#define OUT_IRQ_AVAILABLE  0
+#define OUT_IRQ_QUEUE_EMPTY1
+#define OUT_IRQ_QUEUE_FULL 2
+
+#define OUT_IRQ_FF 0
+#define OUT_IRQ_LED1
+#define OUT_IRQ_INQUIRY2
+
 struct usb_xpad {
struct input_dev *dev;  /* input device interface */
struct usb_device *udev;/* usb device */
@@ -330,8 +338,13 @@ struct usb_xpad {
 
struct urb *irq_out;/* urb for interrupt out report */
unsigned char *odata;   /* output data */
+   unsigned char odata_queue[XPAD_PKT_LEN]; /* pending output data */
dma_addr_t odata_dma;
-   struct mutex odata_mutex;
+   spinlock_t submit_lock;
+   int transfer_length;
+   int submit_state;   /* Can the out urb be submitted */
+   int out_submitter;  /* which submitter is being processed */
+   int queue_submitter;/* Which submission type is in the 
queue */
 
 #if defined(CONFIG_JOYSTICK_XPAD_LEDS)
struct xpad_led *led;
@@ -346,6 +359,104 @@ struct usb_xpad {
 };
 
 /*
+ * Must be called with the lock held
+ */
+static int __xpad_submit_urb(struct usb_xpad *xpad,
+   unsigned char odata[XPAD_PKT_LEN], int transfer_length,
+   int type, bool safe_submit)
+{
+   int ret;
+
+   if (safe_submit || xpad->submit_state == OUT_IRQ_AVAILABLE) {
+   memcpy(xpad->odata, odata, transfer_length);
+   xpad->irq_out->transfer_buffer_length = transfer_length;
+   ret = usb_submit_urb(xpad->irq_out, GFP_ATOMIC);
+   xpad->submit_state = OUT_IRQ_QUEUE_EMPTY;
+   xpad->out_submitter = type;
+   } else {
+   /*
+* The goal here is to prevent starvation of any other type.
+* If this type matches what is being submitted and there is
+* another type in the queue, don't ovewrite it
+*/
+   if (xpad->submit_state != OUT_IRQ_QUEUE_EMPTY &&
+   xpad->out_submitter == type &&
+   xpad->queue_submitter != type) {
+   ret = -EBUSY;
+   goto out;
+   }
+   memcpy(xpad->odata_queue, odata, transfer_length);
+   xpad->transfer_length = transfer_length;
+   xpad->submit_state = OUT_IRQ_QUEUE_FULL;
+   xpad->

Re: [PATCH] usb: dwc2: hcd: fix periodic transfer schedule sequence

[Caesar Wang]

Hi,

在 2015年11月16日 23:25, Yunzhi Li 写道:

When checking dwc2 host channel interrupts, handle qh in
periodic_sched_queued list at first, then we could make sure CSPLIT
packets scheduled in the same order as SSPLIT packets.

Signed-off-by: Yunzhi Li 


This patch can fix some usb issues on my hand machine.

Says:
(1) The usb hub can't normal work (KB, mouse ...) when SB 
headset/Speaker is connected to USB2.0 travel HUB.

(2)  The music have the wonder noise when we are use some usb speak.
..

So, you can free add my test tag:

Tested-by: Caesar Wang 


---
  drivers/usb/dwc2/hcd_intr.c | 22 ++
  1 file changed, 22 insertions(+)

diff --git a/drivers/usb/dwc2/hcd_intr.c b/drivers/usb/dwc2/hcd_intr.c
index bda0b21..e8e8970 100644
--- a/drivers/usb/dwc2/hcd_intr.c
+++ b/drivers/usb/dwc2/hcd_intr.c
@@ -2115,6 +2115,8 @@ static void dwc2_hc_intr(struct dwc2_hsotg *hsotg)
  {
u32 haint;
int i;
+   int hc_num;
+   struct dwc2_qh *qh, *qh_tmp;
  
  	haint = dwc2_readl(hsotg->regs + HAINT);

if (dbg_perio()) {
@@ -2123,6 +2125,26 @@ static void dwc2_hc_intr(struct dwc2_hsotg *hsotg)
dev_vdbg(hsotg->dev, "HAINT=%08x\n", haint);
}
  
+	/*

+* According to USB 2.0 spec section 11.18.8, a host must
+* issue complete-split transactions in a microframe for a
+* set of full-/low-speed endpoints in the same relative
+* order as the start-splits were issued in a microframe for.
+* So here we should at first picking up host channels
+* from periodic_sched_queued list and checking if there is
+* any start-split have already finished then schedule
+* complete-split in the same order.
+*/
+   list_for_each_entry_safe(qh, qh_tmp,
+&hsotg->periodic_sched_queued,
+qh_list_entry) {
+   hc_num = qh->channel->hc_num;
+   if (haint & (1 << hc_num)) {
+   dwc2_hc_n_intr(hsotg, hc_num);
+   haint &= ~(1 << hc_num);
+   }
+   }
+
for (i = 0; i < hsotg->core_params->host_channels; i++) {
if (haint & (1 << i))
dwc2_hc_n_intr(hsotg, i);

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

Re: [RFC] usb: dwc2: hcd: fix split schedule issue

[Julius Werner]

> To handle things smarter, I think I need to research how to deal with
> hubs attached to hubs attached to hubs.  For instance:
>
> dwc2
> -> multi_tt hub
> -> single_tt hub
> -> device 1
> -> device 2

Keep in mind that there's always at most one (active) TT between host
and device. The TT is the point where high-speed traffic is translated
to low-/full-speed traffic, so after that you cannot translate again.
With multiple hubs you either have

-> high-speed 2.0 hub (TT inactive / irrelevant for this path)
  -> multi or single TT 2.0 hub
-> device

or

-> multi or single TT 2.0 hub
  -> full-speed 1.1 hub
 -> device

All the information you need should already be in struct usb_device.
If udev->tt->multi == 0, then it must be scheduled in the same group
as all other devices it shares udev->tt (the same pointer address)
with. If udev->tt->multi == 1, then it belongs in the same group as
all that have the same udev->tt and the same udev->ttport. There's
even a udev->tt->hcpriv where you could link a data structure (array)
in to keep track of these matching devices.

I agree that this is a nice-to-have optimization, though... it's more
important to get the thing stable, and I think it's fine to assume
that all low-/full-speed transfers go on the same bus for the first
iteration.
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 1/2] usb: dwc2: host: Fix missing device insertions

[Alan Stern]

On Mon, 16 Nov 2015, Julius Werner wrote:

> Another point to note, which I think is what prevents the flow Alan
> suggested from working, is this little snippet in DWC2's hub_control
> GetPortStatus callback:
> 
> if (!hsotg->flags.b.port_connect_status) {
> /*
>  * The port is disconnected, which means the core is
>  * either in device mode or it soon will be.
> Just
>  * return 0's for the remainder of the port status
>  * since the port register can't be read if the core
>  * is in device mode.
>  */
> *(__le32 *)buf = cpu_to_le32(port_status);
> break;
> }
> 
> This is before it actually checks the register state of the port. So
> it relies on dwc2_hcd_connect() and dwc2_hcd_disconnect() to be called
> in the right order to give the correct answer for
> USB_PORT_STAT_CONNECTION. This could maybe be improved but I don't
> know what kind of weird interactions with device mode operation made
> that snippet necessary in the first place.

Why does this test hsotg->flags.b.port_connect_status?  What it really 
needs to know is whether the core is in device mode.  It should test 
for that instead.  Then it could accurately report the true connection 
state whenever the core is in host mode, regardless of the order in 
which dwc2_hcd_connect() and dwc2_hcd_disconnect() get called.  No?

My guess would be that using the wrong test was simply a misguided 
attempt at optimization.

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 1/2] usb: dwc2: host: Fix missing device insertions

[Alan Stern]

On Mon, 16 Nov 2015, Doug Anderson wrote:

> Alan,
> 
> On Mon, Nov 16, 2015 at 11:31 AM, Alan Stern  
> wrote:
> > On Mon, 16 Nov 2015, Doug Anderson wrote:
> >
> >> ---
> >>
> >> usb: dwc2: host: Fix missing device insertions
> >>
> >> If you've got your interrupt signals bouncing a bit as you insert your
> >> USB device, you might end up in a state when the device is connected but
> >> the driver doesn't know it.
> >>
> >> Specifically, the observed order is:
> >>  1. hardware sees connect
> >>  2. hardware sees disconnect
> >>  3. hardware sees connect
> >>  4. dwc2_port_intr() - clears connect interrupt
> >>  5. dwc2_handle_common_intr() - calls dwc2_hcd_disconnect()
> >>
> >> Now you'll be stuck with the cable plugged in and no further interrupts
> >> coming in but the driver will think we're disconnected.
> >>
> >> We'll fix this by checking for the missing connect interrupt and
> >> re-connecting after the disconnect is posted.  We don't skip the
> >> disconnect because if there is a transitory disconnect we really want to
> >> de-enumerate and re-enumerate.
> >
> > Why do you need to do anything special here?  Normally a driver's
> > interrupt handler should query the hardware status after clearing the
> > interrupt source.  That way no transitions ever get missed.
> >
> > In your example, at step 5 the dwc2 driver would check the port status
> > and see that it currently is connected.  Therefore the driver would
> > pass a "connect status changed" event to the USB core and set the port
> > status to "connected".  No extra checking is needed, and transitory
> > connects or disconnects get handled correctly.
> 
> Things are pretty ugly at the moment because the dwc2 interrupt
> handler is split in two.  There's dwc2_handle_hcd_intr() and
> dwc2_handle_common_intr().  Both are registered for the same "shared"
> IRQ.  If I had to guess, I'd say that this is probably because someone
> wanted to assign the ".irq" field in the "struct hc_driver" for the
> host controller but that they also needed the other interrupt handler
> to handle things shared between host and gadget mode.
> 
> In any case, one of these two interrupt routines handles connect and
> the other disconnect.  That's pretty ugly but means that you can't
> just rely on standard techniques for keeping things in sync.

Okay, that is rather weird.  Still, I don't see why it should matter.  

Fundamentally there's no difference between a "connect" interrupt and a
"disconnect" interrupt.  They should both do exactly the same things:
clear the interrupt source, post a "connection change" event, and set
the driver's connect status based on the hardware's current state.  
The second and third parts can be handled by a shared subroutine.

If you think of these things as "connect changed" interrupts rather 
than as "connect" and "disconnect" interrupts, it makes a lot of sense.

> It would probably be a pretty reasonable idea to try to clean that up
> more, but that would be a very major and intrusive change.

Maybe so -- I'll take your word for it since I'm not at all familiar 
with the dwc2 code.

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 1/2] usb: dwc2: host: Fix missing device insertions

[Julius Werner]

Another point to note, which I think is what prevents the flow Alan
suggested from working, is this little snippet in DWC2's hub_control
GetPortStatus callback:

if (!hsotg->flags.b.port_connect_status) {
/*
 * The port is disconnected, which means the core is
 * either in device mode or it soon will be.
Just
 * return 0's for the remainder of the port status
 * since the port register can't be read if the core
 * is in device mode.
 */
*(__le32 *)buf = cpu_to_le32(port_status);
break;
}

This is before it actually checks the register state of the port. So
it relies on dwc2_hcd_connect() and dwc2_hcd_disconnect() to be called
in the right order to give the correct answer for
USB_PORT_STAT_CONNECTION. This could maybe be improved but I don't
know what kind of weird interactions with device mode operation made
that snippet necessary in the first place.
--
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: Infrastructure for zerocopy I/O

[Alan Stern]

On Mon, 16 Nov 2015, Christoph Hellwig wrote:

> On Mon, Nov 16, 2015 at 08:03:12PM +0100, Steinar H. Gunderson wrote:
> > The original use case: DVB capture on embedded devices.
> > 
> > My use case: USB3 uncompressed HD video capture (from multiple cards).
> > 
> > Both of these hit (beyond the speed boost from zerocopy) the problem that
> > as time goes by, memory gets more fragmented and usbfs fails allocation.
> > Allocating memory up-front solves that.
> 
> As said I think you should just use get_user_pages() on user memory,
> and bounce buffer if it doesn't fit the DMA mask.
> 
> Thіs also allows the user to use hugetlbs if they need large contiguous
> allocations for performance reasons.

In other words, you're suggesting we do this:

Check that userspace requested zerocopy (otherwise the user 
program might try to access other data stored in the same cache 
lines as the buffer while the I/O is in progres);

Call get_user_pages (or get_user_pages_fast? -- it's not clear 
which should be used) for this buffer;

Use the array of pages returned by that routine to populate
a scatter-gather list (sg_alloc_table_from_pages);

Pass that list to dma_map_sg.

Is that right?

Does dma_map_sg check the page addresses against the DMA mask and
automatically create a bounce buffer, or do we have to do that
manually?  Documentation/DMA-API-HOWTO.txt doesn't discuss this.

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 1/1] net: usb: cdc_ether: add Dell DW5580 as a mobile broadband adapter

[David Miller]

From: Daniele Palmas 
Date: Fri, 13 Nov 2015 18:01:21 +0100

> Since Dell DW5580 is a 3G modem, this patch adds the device as a
> mobile broadband adapter
> 
> Signed-off-by: Daniele Palmas 

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

Re: [PATCH v2 1/2] usb: dwc2: host: Fix missing device insertions

[Doug Anderson]

Alan,

On Mon, Nov 16, 2015 at 11:31 AM, Alan Stern  wrote:
> On Mon, 16 Nov 2015, Doug Anderson wrote:
>
>> ---
>>
>> usb: dwc2: host: Fix missing device insertions
>>
>> If you've got your interrupt signals bouncing a bit as you insert your
>> USB device, you might end up in a state when the device is connected but
>> the driver doesn't know it.
>>
>> Specifically, the observed order is:
>>  1. hardware sees connect
>>  2. hardware sees disconnect
>>  3. hardware sees connect
>>  4. dwc2_port_intr() - clears connect interrupt
>>  5. dwc2_handle_common_intr() - calls dwc2_hcd_disconnect()
>>
>> Now you'll be stuck with the cable plugged in and no further interrupts
>> coming in but the driver will think we're disconnected.
>>
>> We'll fix this by checking for the missing connect interrupt and
>> re-connecting after the disconnect is posted.  We don't skip the
>> disconnect because if there is a transitory disconnect we really want to
>> de-enumerate and re-enumerate.
>
> Why do you need to do anything special here?  Normally a driver's
> interrupt handler should query the hardware status after clearing the
> interrupt source.  That way no transitions ever get missed.
>
> In your example, at step 5 the dwc2 driver would check the port status
> and see that it currently is connected.  Therefore the driver would
> pass a "connect status changed" event to the USB core and set the port
> status to "connected".  No extra checking is needed, and transitory
> connects or disconnects get handled correctly.

Things are pretty ugly at the moment because the dwc2 interrupt
handler is split in two.  There's dwc2_handle_hcd_intr() and
dwc2_handle_common_intr().  Both are registered for the same "shared"
IRQ.  If I had to guess, I'd say that this is probably because someone
wanted to assign the ".irq" field in the "struct hc_driver" for the
host controller but that they also needed the other interrupt handler
to handle things shared between host and gadget mode.

In any case, one of these two interrupt routines handles connect and
the other disconnect.  That's pretty ugly but means that you can't
just rely on standard techniques for keeping things in sync.


It would probably be a pretty reasonable idea to try to clean that up
more, but that would be a very major and intrusive change.

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

Re: [PATCH v2 1/2] usb: dwc2: host: Fix missing device insertions

[Alan Stern]

On Mon, 16 Nov 2015, Doug Anderson wrote:

> ---
> 
> usb: dwc2: host: Fix missing device insertions
> 
> If you've got your interrupt signals bouncing a bit as you insert your
> USB device, you might end up in a state when the device is connected but
> the driver doesn't know it.
> 
> Specifically, the observed order is:
>  1. hardware sees connect
>  2. hardware sees disconnect
>  3. hardware sees connect
>  4. dwc2_port_intr() - clears connect interrupt
>  5. dwc2_handle_common_intr() - calls dwc2_hcd_disconnect()
> 
> Now you'll be stuck with the cable plugged in and no further interrupts
> coming in but the driver will think we're disconnected.
> 
> We'll fix this by checking for the missing connect interrupt and
> re-connecting after the disconnect is posted.  We don't skip the
> disconnect because if there is a transitory disconnect we really want to
> de-enumerate and re-enumerate.

Why do you need to do anything special here?  Normally a driver's
interrupt handler should query the hardware status after clearing the
interrupt source.  That way no transitions ever get missed.

In your example, at step 5 the dwc2 driver would check the port status
and see that it currently is connected.  Therefore the driver would
pass a "connect status changed" event to the USB core and set the port
status to "connected".  No extra checking is needed, and transitory
connects or disconnects get handled correctly.

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: phy: msm: fix a possible NULL dereference

[Felipe Balbi]

Hi,

(you need to break your lines at 80 characters)

Corentin LABBE  writes:
> Le 16/11/2015 18:07, Felipe Balbi a écrit :
>> 
>> Hi,
>> 
>> LABBE Corentin  writes:
>>> of_match_device could return NULL, and so cause a NULL pointer
>>> dereference later. Renaming id to of_id (like all others do) in the
>>> process.
>>>
>>> Reported-by: coverity (CID 1324133)
>>> Signed-off-by: LABBE Corentin 
>>> ---
>>>  drivers/usb/phy/phy-msm-usb.c | 9 ++---
>>>  1 file changed, 6 insertions(+), 3 deletions(-)
>>>
>>> diff --git a/drivers/usb/phy/phy-msm-usb.c b/drivers/usb/phy/phy-msm-usb.c
>>> index 80eb991..c4a66cf 100644
>>> --- a/drivers/usb/phy/phy-msm-usb.c
>>> +++ b/drivers/usb/phy/phy-msm-usb.c
>>> @@ -1506,20 +1506,23 @@ static int msm_otg_read_dt(struct platform_device 
>>> *pdev, struct msm_otg *motg)
>>>  {
>>> struct msm_otg_platform_data *pdata;
>>> struct extcon_dev *ext_id, *ext_vbus;
>>> -   const struct of_device_id *id;
>>> +   const struct of_device_id *of_id;
>> 
>> and why did you need to rename this variable ? Please resend without the
>> variable rename.
>> 
>
> I was renaming because all other drivers call it of_id, but I got hint
> from another thread to use of_device_get_match_data() which will
> permit to remove that variable, and still solve the issue.

for -rc we usually want the smallest patch needed to fix the issue. That
would be the two line if() condition. If converting to
of_device_get_match_data() is about the same (2 or 3 lines), then it
should be fine; but as a general rule of thumb: we don't fix and
cleanup/refactor on the same patch unless strictly necessary.

-- 
balbi


signature.asc
Description: PGP signature

Re: [PATCH] usb: phy: msm: fix a possible NULL dereference

[Corentin LABBE]

Le 16/11/2015 18:07, Felipe Balbi a écrit :
> 
> Hi,
> 
> LABBE Corentin  writes:
>> of_match_device could return NULL, and so cause a NULL pointer
>> dereference later. Renaming id to of_id (like all others do) in the
>> process.
>>
>> Reported-by: coverity (CID 1324133)
>> Signed-off-by: LABBE Corentin 
>> ---
>>  drivers/usb/phy/phy-msm-usb.c | 9 ++---
>>  1 file changed, 6 insertions(+), 3 deletions(-)
>>
>> diff --git a/drivers/usb/phy/phy-msm-usb.c b/drivers/usb/phy/phy-msm-usb.c
>> index 80eb991..c4a66cf 100644
>> --- a/drivers/usb/phy/phy-msm-usb.c
>> +++ b/drivers/usb/phy/phy-msm-usb.c
>> @@ -1506,20 +1506,23 @@ static int msm_otg_read_dt(struct platform_device 
>> *pdev, struct msm_otg *motg)
>>  {
>>  struct msm_otg_platform_data *pdata;
>>  struct extcon_dev *ext_id, *ext_vbus;
>> -const struct of_device_id *id;
>> +const struct of_device_id *of_id;
> 
> and why did you need to rename this variable ? Please resend without the
> variable rename.
> 

I was renaming because all other drivers call it of_id, but I got hint from 
another thread to use of_device_get_match_data() which will permit to remove 
that variable, and still solve the issue.

Regards

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

Re: [PATCH v2 1/2] usb: dwc2: host: Fix missing device insertions

[Felipe Balbi]

hi,

Doug Anderson  writes:
> Felipe,
>
> On Mon, Nov 16, 2015 at 10:22 AM, Felipe Balbi  wrote:
>>> I added "force" in v2 of the patch in response to John's feedback to
>>> v1.  He pointed out that when you unload the module when you have a
>>> device connected that my v1 patch would not properly disconnect the
>>> device (or, rather, it would disconnect it and then reconnect it).
>>>
>>> That's why _dwc2_hcd_stop() calls dwc2_hcd_disconnect() with a force
>>> of "true".
>>
>> There's no mention of this in commit log. It would be great to add a:
>>
>> "while at that, also make sure that we don't try to detect a device on
>> module unload because of foo bar baz as pointed out by John Youn".
>>
>> Or something along these lines.
>
> ...well, except that it's not new behavior.  In other words:
>
> * Without my patch at all: we don't try to detect a device on module unload.
>
> * With my v1 patch: we (incorrectly) did try to detect a device on
> module unload.
>
> * With my v2 patch: we're back to not trying to detect a device on
> module unload.
>
> In other words: my v2 patch (correctly) doesn't change the behavior on
> module unload.  That's why I didn't mention it in the commit message.
> It's in the "v2" changelog though.
>
>
> I'll try to come up with something for the commit message though.  See
> below for new proposed commit message.
>
>
 you make no mention of why this is needed. This is basically a refactor,
 not a fix.
>>>
>>> This new function is called from two places now, isn't it?
>>>
>>> Basically this is a little bit of code that used to be directly in
>>> dwc2_port_intr().  I still want it there, but I also want to call the
>>> same bit of code after a disconnect if I detect that the device has
>>> been inserted again.
>>
>> I got that :-) But it's not mentioned in commit and it's apparently
>> unnecessary for fixing the bug :-) Another "we're also adding a new
>> hsotg_disconnect() function by means of refactoring to avoid code
>> duplication" would've been enough.
>
> OK, sure.
>
>
>>> I'd really rather not add the duplication unless you insist.  To me it
>>> makes it clearer to include the (small) refactor in the same patch.
>>>
>>> If the refactor makes this change too big for an RC, then it's OK with
>>> me to just skip this for the RC.  It's not fixing a regression or
>>> anything.  I have no requirements to have this land in 4.4.  It fixes
>>> a bug and I thought that the fix was pretty small and safe (despite
>>> having a diffstat that's bigger than the bare minimum).  I will leave
>>> it to your judgement.
>>
>> let's at least modify commit log to make all these extra changes clear
>> that they are needed because of reason (a) or (b) or whatever. If you
>> just send a patch doing much more than it apparently should without no
>> mention as to why it was done this way, I can't know for sure those
>> changes are needed; next thing you know, Greg refuses to apply my pull
>> request because the change is too large :-)
>>
>> We don't want that to happen :-)
>
> Totally understand.  It's your butt on the line for the pull request
> to Greg, so definitely want to make sure you're comfortable with
> anything you pass on.  As always I definitely appreciate your reviews
> and your time.
>
>
> How about if we just add a "Notes" to the end of the patch
> description.  I can repost a patch or you can feel free to change the
> description as per below (just let me know).  ...so in total:
>
> ---
>
> usb: dwc2: host: Fix missing device insertions
>
> If you've got your interrupt signals bouncing a bit as you insert your
> USB device, you might end up in a state when the device is connected but
> the driver doesn't know it.
>
> Specifically, the observed order is:
>  1. hardware sees connect
>  2. hardware sees disconnect
>  3. hardware sees connect
>  4. dwc2_port_intr() - clears connect interrupt
>  5. dwc2_handle_common_intr() - calls dwc2_hcd_disconnect()
>
> Now you'll be stuck with the cable plugged in and no further interrupts
> coming in but the driver will think we're disconnected.
>
> We'll fix this by checking for the missing connect interrupt and
> re-connecting after the disconnect is posted.  We don't skip the
> disconnect because if there is a transitory disconnect we really want to
> de-enumerate and re-enumerate.
>
> Notes:
>
> 1. As part of this change we add a "force" parameter to
>dwc2_hcd_disconnect() so that when we're unloading the module we
>avoid the new behavior.  The need for this was pointed out by John
>Youn.
> 2. The bit of code needed at the end of dwc2_hcd_disconnect() is
>exactly the same bit of code from dwc2_port_intr().  To avoid
>duplication, we refactor that code out into a new function
>dwc2_hcd_connect().

this should be enough, thanks for being so responsive

-- 
balbi


signature.asc
Description: PGP signature

Re: Infrastructure for zerocopy I/O

[Christoph Hellwig]

On Mon, Nov 16, 2015 at 08:03:12PM +0100, Steinar H. Gunderson wrote:
> The original use case: DVB capture on embedded devices.
> 
> My use case: USB3 uncompressed HD video capture (from multiple cards).
> 
> Both of these hit (beyond the speed boost from zerocopy) the problem that
> as time goes by, memory gets more fragmented and usbfs fails allocation.
> Allocating memory up-front solves that.

As said I think you should just use get_user_pages() on user memory,
and bounce buffer if it doesn't fit the DMA mask.

Thіs also allows the user to use hugetlbs if they need large contiguous
allocations for performance reasons.
--
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: Infrastructure for zerocopy I/O

[Steinar H. Gunderson]

On Mon, Nov 16, 2015 at 07:55:45PM +0100, Christoph Hellwig wrote:
>> A proposed patch has been posted
>> (http://marc.info/?l=linux-usb&m=144763502829452&w=2), but I'm not
>> convinced that it is the best approach.  For instance, it always tries 
>> to get contiguous pages and so is vulnerable to memory fragmentation.
> This looks totally crazy to me.  What's the use case for it?

The original use case: DVB capture on embedded devices.

My use case: USB3 uncompressed HD video capture (from multiple cards).

Both of these hit (beyond the speed boost from zerocopy) the problem that
as time goes by, memory gets more fragmented and usbfs fails allocation.
Allocating memory up-front solves that.

/* Steinar */
-- 
Homepage: https://www.sesse.net/
--
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: Infrastructure for zerocopy I/O

[Christoph Hellwig]

On Mon, Nov 16, 2015 at 01:29:58PM -0500, Alan Stern wrote:
>   Allocating memory pages that match the device's DMA mask, for 
>   use as I/O buffers, and locking them so their physical 
>   addresses don't change (and they don't get paged out);
> 
>   Mapping those pages into a user process;
> 
>   Constructing scatter-gather lists to describe the I/O if the
>   pages aren't contiguous.
> 
> I don't have much experience in this area.  Can you point to good 
> examples where these things are done or documents describing what is 
> involved?  For example, are the allocating and mapping steps normally 
> done separately or are they normally combined in an mmap(2) system 
> call?

The answer is probably not what you want to here, but the recommendation
is to not bother.  Just use the iommu for this one reasonable hardware,
or swiotlb for bounce buffering if your systems has more addressable memory
than what the hardware can address.

This is what we've been doing for block I/O since day 1.

> A proposed patch has been posted
> (http://marc.info/?l=linux-usb&m=144763502829452&w=2), but I'm not
> convinced that it is the best approach.  For instance, it always tries 
> to get contiguous pages and so is vulnerable to memory fragmentation.

This looks totally crazy to me.  What's the use case for it?
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 1/2] usb: dwc2: host: Fix missing device insertions

[Doug Anderson]

Felipe,

On Mon, Nov 16, 2015 at 10:22 AM, Felipe Balbi  wrote:
>> I added "force" in v2 of the patch in response to John's feedback to
>> v1.  He pointed out that when you unload the module when you have a
>> device connected that my v1 patch would not properly disconnect the
>> device (or, rather, it would disconnect it and then reconnect it).
>>
>> That's why _dwc2_hcd_stop() calls dwc2_hcd_disconnect() with a force
>> of "true".
>
> There's no mention of this in commit log. It would be great to add a:
>
> "while at that, also make sure that we don't try to detect a device on
> module unload because of foo bar baz as pointed out by John Youn".
>
> Or something along these lines.

...well, except that it's not new behavior.  In other words:

* Without my patch at all: we don't try to detect a device on module unload.

* With my v1 patch: we (incorrectly) did try to detect a device on
module unload.

* With my v2 patch: we're back to not trying to detect a device on
module unload.

In other words: my v2 patch (correctly) doesn't change the behavior on
module unload.  That's why I didn't mention it in the commit message.
It's in the "v2" changelog though.


I'll try to come up with something for the commit message though.  See
below for new proposed commit message.


>>> you make no mention of why this is needed. This is basically a refactor,
>>> not a fix.
>>
>> This new function is called from two places now, isn't it?
>>
>> Basically this is a little bit of code that used to be directly in
>> dwc2_port_intr().  I still want it there, but I also want to call the
>> same bit of code after a disconnect if I detect that the device has
>> been inserted again.
>
> I got that :-) But it's not mentioned in commit and it's apparently
> unnecessary for fixing the bug :-) Another "we're also adding a new
> hsotg_disconnect() function by means of refactoring to avoid code
> duplication" would've been enough.

OK, sure.


>> I'd really rather not add the duplication unless you insist.  To me it
>> makes it clearer to include the (small) refactor in the same patch.
>>
>> If the refactor makes this change too big for an RC, then it's OK with
>> me to just skip this for the RC.  It's not fixing a regression or
>> anything.  I have no requirements to have this land in 4.4.  It fixes
>> a bug and I thought that the fix was pretty small and safe (despite
>> having a diffstat that's bigger than the bare minimum).  I will leave
>> it to your judgement.
>
> let's at least modify commit log to make all these extra changes clear
> that they are needed because of reason (a) or (b) or whatever. If you
> just send a patch doing much more than it apparently should without no
> mention as to why it was done this way, I can't know for sure those
> changes are needed; next thing you know, Greg refuses to apply my pull
> request because the change is too large :-)
>
> We don't want that to happen :-)

Totally understand.  It's your butt on the line for the pull request
to Greg, so definitely want to make sure you're comfortable with
anything you pass on.  As always I definitely appreciate your reviews
and your time.


How about if we just add a "Notes" to the end of the patch
description.  I can repost a patch or you can feel free to change the
description as per below (just let me know).  ...so in total:

---

usb: dwc2: host: Fix missing device insertions

If you've got your interrupt signals bouncing a bit as you insert your
USB device, you might end up in a state when the device is connected but
the driver doesn't know it.

Specifically, the observed order is:
 1. hardware sees connect
 2. hardware sees disconnect
 3. hardware sees connect
 4. dwc2_port_intr() - clears connect interrupt
 5. dwc2_handle_common_intr() - calls dwc2_hcd_disconnect()

Now you'll be stuck with the cable plugged in and no further interrupts
coming in but the driver will think we're disconnected.

We'll fix this by checking for the missing connect interrupt and
re-connecting after the disconnect is posted.  We don't skip the
disconnect because if there is a transitory disconnect we really want to
de-enumerate and re-enumerate.

Notes:

1. As part of this change we add a "force" parameter to
   dwc2_hcd_disconnect() so that when we're unloading the module we
   avoid the new behavior.  The need for this was pointed out by John
   Youn.
2. The bit of code needed at the end of dwc2_hcd_disconnect() is
   exactly the same bit of code from dwc2_port_intr().  To avoid
   duplication, we refactor that code out into a new function
   dwc2_hcd_connect().


-Doug
--
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: Infrastructure for zerocopy I/O

[Steinar H. Gunderson]

On Mon, Nov 16, 2015 at 01:29:58PM -0500, Alan Stern wrote:
> A proposed patch has been posted
> (http://marc.info/?l=linux-usb&m=144763502829452&w=2), but I'm not
> convinced that it is the best approach.  For instance, it always tries 
> to get contiguous pages and so is vulnerable to memory fragmentation.

What Alan says is right, but there's one additional piece of information:
The patch also makes allocation an up-front issue (the memory block allocated
can be reused across transfers), so if you can allocate at the start of the
program, you will not be affected by later fragmentation.

/* Steinar */
-- 
Homepage: https://www.sesse.net/
--
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-EHCI: Delete unnecessary checks before the function call "dma_pool_destroy"

[Alan Stern]

On Mon, 16 Nov 2015, SF Markus Elfring wrote:

> From: Markus Elfring 
> Date: Mon, 16 Nov 2015 19:01:44 +0100
> 
> The dma_pool_destroy() function tests whether its argument is NULL
> and then returns immediately. Thus the test around the calls is not needed.
> 
> This issue was detected by using the Coccinelle software.
> 
> Signed-off-by: Markus Elfring 

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

Infrastructure for zerocopy I/O

[Alan Stern]

Christoph:

Can you help answer some questions about implementing zerocopy I/O?

We would like to add zerocopy support for USB devices.  Basically this
means:

Allocating memory pages that match the device's DMA mask, for 
use as I/O buffers, and locking them so their physical 
addresses don't change (and they don't get paged out);

Mapping those pages into a user process;

Constructing scatter-gather lists to describe the I/O if the
pages aren't contiguous.

I don't have much experience in this area.  Can you point to good 
examples where these things are done or documents describing what is 
involved?  For example, are the allocating and mapping steps normally 
done separately or are they normally combined in an mmap(2) system 
call?

A proposed patch has been posted
(http://marc.info/?l=linux-usb&m=144763502829452&w=2), but I'm not
convinced that it is the best approach.  For instance, it always tries 
to get contiguous pages and so is vulnerable to memory fragmentation.

Thanks,

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: dwc2: hcd: fix periodic transfer schedule sequence

[Doug Anderson]

Yunzhi

On Mon, Nov 16, 2015 at 7:25 AM, Yunzhi Li  wrote:
> When checking dwc2 host channel interrupts, handle qh in
> periodic_sched_queued list at first, then we could make sure CSPLIT
> packets scheduled in the same order as SSPLIT packets.
>
> Signed-off-by: Yunzhi Li 
> ---
>  drivers/usb/dwc2/hcd_intr.c | 22 ++
>  1 file changed, 22 insertions(+)

This seems like a very reasonable fix to me.  I also bought the same
keyboard you were debugging with (The Das Keyboard 4 Ultimate Clicky)
and confirmed that problems are fixed by this patch on the
rk3288-based veyron-jerry sitting on my desk.


Reviewed-by: Douglas Anderson 
Tested-by: Douglas Anderson 
--
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: at91sam9x5: USB mass storage gadget problems

[Felipe Balbi]

Hi,

Boris Brezillon  writes:



>> >> If I don't hear anything on this issue then I can produce
>> >> a patch. Does it go through the ARM or USB (or both) trees?
>> >
>> > You can go ahead and send a patch to the ARM and USB MLs (+
>> > appropriate maintainers), unless you want me to do it.
>> >
>> >> 
>> >> If my patch is sufficient, then perhaps it should also be
>> >> issued against the lk 4.0, 4.1, 4.2 and 4.3 kernels that are
>> >> still actively maintained.
>> >
>> > Yep, adding the following line after your SoB should do the trick:
>> >
>> > Cc:  #4.0+
>> 
>> please send this out as a real patch, otherwise I can't apply.
>> 
>
> I'll take care of that.

thanks :-)

-- 
balbi


signature.asc
Description: PGP signature

[PATCH] usb: gadget: atmel_usba_udc: Expose correct device speed

[Boris Brezillon]

From: Douglas Gilbert 

Following changes that appeared in lk 4.0.0, the gadget udc driver for
some ARM based Atmel SoCs (e.g. at91sam9x5 and sama5d3 families)
incorrectly deduced full-speed USB link speed even when the hardware
had negotiated a high-speed link. The fix is to make sure that the
UDPHS Interrupt Enable Register value does not mask the SPEED bit
in the Interrupt Status Register.

For a mass storage gadget this problem lead to failures when the host
had a USB 3 port with the xhci_hcd driver. If the host was a USB 2
port using the ehci_hcd driver then the mass storage gadget worked
(but probably at a lower speed than it should have).

Signed-of-by: Douglas Gilbert 
Reviewed-by: Boris Brezillon 
Cc:  #4.0+
Fixes: 9870d895ad87 ("usb: atmel_usba_udc: Mask status with enabled irqs")
---
 drivers/usb/gadget/udc/atmel_usba_udc.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/usb/gadget/udc/atmel_usba_udc.c 
b/drivers/usb/gadget/udc/atmel_usba_udc.c
index f0f2b06..f92f5af 100644
--- a/drivers/usb/gadget/udc/atmel_usba_udc.c
+++ b/drivers/usb/gadget/udc/atmel_usba_udc.c
@@ -1633,7 +1633,7 @@ static irqreturn_t usba_udc_irq(int irq, void *devid)
spin_lock(&udc->lock);
 
int_enb = usba_int_enb_get(udc);
-   status = usba_readl(udc, INT_STA) & int_enb;
+   status = usba_readl(udc, INT_STA) & (int_enb | USBA_HIGH_SPEED);
DBG(DBG_INT, "irq, status=%#08x\n", status);
 
if (status & USBA_DET_SUSPEND) {
-- 
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 v2 1/2] usb: dwc2: host: Fix missing device insertions

[Felipe Balbi]

Hi,

Doug Anderson  writes:
> Felipe,
>
> On Mon, Nov 16, 2015 at 9:44 AM, Felipe Balbi  wrote:
>>>  extern void dwc2_hcd_start(struct dwc2_hsotg *hsotg);
>>>  #else
>>>  static inline int dwc2_hcd_get_frame_number(struct dwc2_hsotg *hsotg)
>>>  { return 0; }
>>> -static inline void dwc2_hcd_disconnect(struct dwc2_hsotg *hsotg) {}
>>> +static inline void dwc2_hcd_connect(struct dwc2_hsotg *hsotg) {}
>>> +static inline void dwc2_hcd_disconnect(struct dwc2_hsotg *hsotg, bool 
>>> force) {}
>>>  static inline void dwc2_hcd_start(struct dwc2_hsotg *hsotg) {}
>>>  static inline void dwc2_hcd_remove(struct dwc2_hsotg *hsotg) {}
>>>  static inline int dwc2_hcd_init(struct dwc2_hsotg *hsotg, int irq)
>>> diff --git a/drivers/usb/dwc2/core_intr.c b/drivers/usb/dwc2/core_intr.c
>>> index 27daa42788b1..61601d16e233 100644
>>> --- a/drivers/usb/dwc2/core_intr.c
>>> +++ b/drivers/usb/dwc2/core_intr.c
>>> @@ -239,7 +239,7 @@ static void dwc2_handle_otg_intr(struct dwc2_hsotg 
>>> *hsotg)
>>>   dev_dbg(hsotg->dev, "a_suspend->a_peripheral (%d)\n",
>>>   hsotg->op_state);
>>>   spin_unlock(&hsotg->lock);
>>> - dwc2_hcd_disconnect(hsotg);
>>> + dwc2_hcd_disconnect(hsotg, false);
>>
>> because force is unnecessary (it seems to be just an optimization to
>> me), this change is unnecessary.
>
> I added "force" in v2 of the patch in response to John's feedback to
> v1.  He pointed out that when you unload the module when you have a
> device connected that my v1 patch would not properly disconnect the
> device (or, rather, it would disconnect it and then reconnect it).
>
> That's why _dwc2_hcd_stop() calls dwc2_hcd_disconnect() with a force
> of "true".

There's no mention of this in commit log. It would be great to add a:

"while at that, also make sure that we don't try to detect a device on
module unload because of foo bar baz as pointed out by John Youn".

Or something along these lines.

>>>  /**
>>> + * dwc2_hcd_connect() - Handles connect of the HCD
>>> + *
>>> + * @hsotg: Pointer to struct dwc2_hsotg
>>> + *
>>> + * Must be called with interrupt disabled and spinlock held
>>> + */
>>> +void dwc2_hcd_connect(struct dwc2_hsotg *hsotg)
>>> +{
>>> + if (hsotg->lx_state != DWC2_L0)
>>> + usb_hcd_resume_root_hub(hsotg->priv);
>>> +
>>> + hsotg->flags.b.port_connect_status_change = 1;
>>> + hsotg->flags.b.port_connect_status = 1;
>>> +}
>>
>> you make no mention of why this is needed. This is basically a refactor,
>> not a fix.
>
> This new function is called from two places now, isn't it?
>
> Basically this is a little bit of code that used to be directly in
> dwc2_port_intr().  I still want it there, but I also want to call the
> same bit of code after a disconnect if I detect that the device has
> been inserted again.

I got that :-) But it's not mentioned in commit and it's apparently
unnecessary for fixing the bug :-) Another "we're also adding a new
hsotg_disconnect() function by means of refactoring to avoid code
duplication" would've been enough.

>>> @@ -315,6 +333,24 @@ void dwc2_hcd_disconnect(struct dwc2_hsotg *hsotg)
>>>   dwc2_hcd_cleanup_channels(hsotg);
>>>
>>>   dwc2_host_disconnect(hsotg);
>>> +
>>> + /*
>>> +  * Add an extra check here to see if we're actually connected but
>>> +  * we don't have a detection interrupt pending.  This can happen if:
>>> +  *   1. hardware sees connect
>>> +  *   2. hardware sees disconnect
>>> +  *   3. hardware sees connect
>>> +  *   4. dwc2_port_intr() - clears connect interrupt
>>> +  *   5. dwc2_handle_common_intr() - calls here
>>> +  *
>>> +  * Without the extra check here we will end calling disconnect
>>> +  * and won't get any future interrupts to handle the connect.
>>> +  */
>>> + if (!force) {
>>> + hprt0 = dwc2_readl(hsotg->regs + HPRT0);
>>> + if (!(hprt0 & HPRT0_CONNDET) && (hprt0 & HPRT0_CONNSTS))
>>> + dwc2_hcd_connect(hsotg);
>>
>> what's inside this 'force' branch is what you really need to fix the
>> problem, right ? It seems like for the -rc cycle, all you need is:
>>
>> diff --git a/drivers/usb/dwc2/hcd.c b/drivers/usb/dwc2/hcd.c
>> index 571c21727ff9..967d1e686efe 100644
>> --- a/drivers/usb/dwc2/hcd.c
>> +++ b/drivers/usb/dwc2/hcd.c
>> @@ -276,6 +276,7 @@ static void dwc2_hcd_cleanup_channels(struct dwc2_hsotg 
>> *hsotg)
>>   */
>>  void dwc2_hcd_disconnect(struct dwc2_hsotg *hsotg)
>>  {
>> +   u32 hprt0;
>> u32 intr;
>>
>> /* Set status flags for the hub driver */
>> @@ -315,6 +316,15 @@ void dwc2_hcd_disconnect(struct dwc2_hsotg *hsotg)
>> dwc2_hcd_cleanup_channels(hsotg);
>>
>> dwc2_host_disconnect(hsotg);
>> +
>> +   hprt0 = dwc2_readl(hsotg->regs + HPRT0);
>> +   if (!(hprt0 & (HPRT0_CONNDET | HPRT0_CONNSTS))) {
>> +   if (hsotg->lx_state != 

Re: at91sam9x5: USB mass storage gadget problems

[Boris Brezillon]

Hi Felipe,

On Mon, 16 Nov 2015 11:17:56 -0600
Felipe Balbi  wrote:

> 
> Hi,
> 
> Boris Brezillon  writes:
> > Hi Douglas,
> >
> > On Sat, 14 Nov 2015 14:15:30 -0500
> > Douglas Gilbert  wrote:
> >
> >> On 15-11-12 05:18 PM, Alan Stern wrote:
> >> > On Thu, 12 Nov 2015, Douglas Gilbert wrote:
> >> >
> >> >> Yes, the X201 has USB 2.0 host ports. It is running a stock Ubuntu
> >> >> 15.10 kernel: 4.2.0-18-generic and the log indicates that the
> >> >> ehci_pci driver is being used. Part of the X201's syslog is
> >> >> attached in which a driver complains about the invalid maxpacket
> >> >> values of 64.
> >> >>
> >> >> So its seems that the ehci drivers as used on the X201 can work
> >> >> around the invalid maxpacket value (64) while the xhci drivers
> >> >> used by the X240 (due to the USB 3.0 host ports) get tripped up.
> >> >
> >> > Yes, I think that's right.  The restriction that high speed bulk
> >> > endpoints must have a maxpacket size of 512 is enforced by the xHCI
> >> > hardware but not by the EHCI hardware; this explains why ehci-hcd is
> >> > able to work around such violations while xhci-hcd isn't.
> >> >
> >> >> Still looking at drivers/usb/gadget/udc/atmel_usba_udc.c which
> >> >> has lots of changes between lk 3.19.0-rc4 and 4.0.0-rc4 . The
> >> >> maxpacket value seems (to me) to be related to the fifo-size
> >> >> in the gadget section of this dts include file:
> >> >> arch/arm/boot/dts/at91sam9x5.dtsi
> >> >> which has 1024 for ep1 through ep5 and 64 for ep0.
> >> >
> >> > The assignment of endpoints isn't done in the UDC driver; it is carried
> >> > out by epautoconf.c in drivers/usb/gadget/.  So you may need to expand
> >> > your bisection search beyond the single UDC driver source file.
> >> >
> >> > Have you tried enabling debugging in the gadget drivers and checking
> >> > out the kernel log on the gadget?
> >> >
> >> >> So it looks like 1.5 bugs:
> >> >> - one in atmel's udc driver for the at91sam9x5 family, and
> >> >> - the inconsistency between the ehci driver working around
> >> >>   invalid maxpacket values and the xhci driver behaving
> >> >>   badly (lots of bus resets and a badly made SCSI storage
> >> >>   device [e.g. INQUIRY works but READ(10) fails]).
> >> >
> >> > The first is clearly a bug, although at the moment we can't be sure
> >> > where.  The second is an unavoidable hardware restriction, not a bug.
> >> > Anyway, if you fix the first problem then the second won't be an issue.
> >> 
> >> Found the udc driver bug. A shadow register value was introduced
> >> around lk 4.0 for the Atmel 9x5/sama5d3 UDPHS driver
> >> (atmel_usba_udc.c) for the interrupt status register. It used the
> >> interrupt enable register (last written) value as a mask. At least
> >> for the at91sam9g25 that works apart from the SPEED bit (bit 0)
> >> which is only present in the interrupt status register.
> >> 
> >> It seems that USB negotiates the link speed during resets and at
> >> the G25 end, even though the hardware had negotiated a "high
> >> speed" link with the host, the logic in usba_udc_irq() deduced it
> >> was only a full speed link (due to the above bug). Thereafter
> >> there was confusion which the ehci_hcd host driver could handle
> >> but the xhci_pci driver could not. In the xhci_pci case there
> >> were multiple high speed link resets in the host log, matched
> >> at the device (G25) end with a similar number of reported _full_
> >> speed resets.
> >> 
> >> The author of the changes to the code that caused this is
> >> cc-ed on this post. He might like to consider the attached
> >> patch which fixed my problem. However the shadow mask register
> >> technique might have other subtle issues that I'm not
> >> qualified to address.
> >
> > Looks good to me, and sorry for the inconvenience.
> >
> >> 
> >> If I don't hear anything on this issue then I can produce
> >> a patch. Does it go through the ARM or USB (or both) trees?
> >
> > You can go ahead and send a patch to the ARM and USB MLs (+
> > appropriate maintainers), unless you want me to do it.
> >
> >> 
> >> If my patch is sufficient, then perhaps it should also be
> >> issued against the lk 4.0, 4.1, 4.2 and 4.3 kernels that are
> >> still actively maintained.
> >
> > Yep, adding the following line after your SoB should do the trick:
> >
> > Cc:  #4.0+
> 
> please send this out as a real patch, otherwise I can't apply.
> 

I'll take care of that.

Best Regards,

Boris

-- 
Boris Brezillon, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 1/2] usb: dwc2: host: Fix missing device insertions

[Doug Anderson]

Felipe,

On Mon, Nov 16, 2015 at 9:44 AM, Felipe Balbi  wrote:
>>  extern void dwc2_hcd_start(struct dwc2_hsotg *hsotg);
>>  #else
>>  static inline int dwc2_hcd_get_frame_number(struct dwc2_hsotg *hsotg)
>>  { return 0; }
>> -static inline void dwc2_hcd_disconnect(struct dwc2_hsotg *hsotg) {}
>> +static inline void dwc2_hcd_connect(struct dwc2_hsotg *hsotg) {}
>> +static inline void dwc2_hcd_disconnect(struct dwc2_hsotg *hsotg, bool 
>> force) {}
>>  static inline void dwc2_hcd_start(struct dwc2_hsotg *hsotg) {}
>>  static inline void dwc2_hcd_remove(struct dwc2_hsotg *hsotg) {}
>>  static inline int dwc2_hcd_init(struct dwc2_hsotg *hsotg, int irq)
>> diff --git a/drivers/usb/dwc2/core_intr.c b/drivers/usb/dwc2/core_intr.c
>> index 27daa42788b1..61601d16e233 100644
>> --- a/drivers/usb/dwc2/core_intr.c
>> +++ b/drivers/usb/dwc2/core_intr.c
>> @@ -239,7 +239,7 @@ static void dwc2_handle_otg_intr(struct dwc2_hsotg 
>> *hsotg)
>>   dev_dbg(hsotg->dev, "a_suspend->a_peripheral (%d)\n",
>>   hsotg->op_state);
>>   spin_unlock(&hsotg->lock);
>> - dwc2_hcd_disconnect(hsotg);
>> + dwc2_hcd_disconnect(hsotg, false);
>
> because force is unnecessary (it seems to be just an optimization to
> me), this change is unnecessary.

I added "force" in v2 of the patch in response to John's feedback to
v1.  He pointed out that when you unload the module when you have a
device connected that my v1 patch would not properly disconnect the
device (or, rather, it would disconnect it and then reconnect it).

That's why _dwc2_hcd_stop() calls dwc2_hcd_disconnect() with a force of "true".


>>  /**
>> + * dwc2_hcd_connect() - Handles connect of the HCD
>> + *
>> + * @hsotg: Pointer to struct dwc2_hsotg
>> + *
>> + * Must be called with interrupt disabled and spinlock held
>> + */
>> +void dwc2_hcd_connect(struct dwc2_hsotg *hsotg)
>> +{
>> + if (hsotg->lx_state != DWC2_L0)
>> + usb_hcd_resume_root_hub(hsotg->priv);
>> +
>> + hsotg->flags.b.port_connect_status_change = 1;
>> + hsotg->flags.b.port_connect_status = 1;
>> +}
>
> you make no mention of why this is needed. This is basically a refactor,
> not a fix.

This new function is called from two places now, isn't it?

Basically this is a little bit of code that used to be directly in
dwc2_port_intr().  I still want it there, but I also want to call the
same bit of code after a disconnect if I detect that the device has
been inserted again.


>> @@ -315,6 +333,24 @@ void dwc2_hcd_disconnect(struct dwc2_hsotg *hsotg)
>>   dwc2_hcd_cleanup_channels(hsotg);
>>
>>   dwc2_host_disconnect(hsotg);
>> +
>> + /*
>> +  * Add an extra check here to see if we're actually connected but
>> +  * we don't have a detection interrupt pending.  This can happen if:
>> +  *   1. hardware sees connect
>> +  *   2. hardware sees disconnect
>> +  *   3. hardware sees connect
>> +  *   4. dwc2_port_intr() - clears connect interrupt
>> +  *   5. dwc2_handle_common_intr() - calls here
>> +  *
>> +  * Without the extra check here we will end calling disconnect
>> +  * and won't get any future interrupts to handle the connect.
>> +  */
>> + if (!force) {
>> + hprt0 = dwc2_readl(hsotg->regs + HPRT0);
>> + if (!(hprt0 & HPRT0_CONNDET) && (hprt0 & HPRT0_CONNSTS))
>> + dwc2_hcd_connect(hsotg);
>
> what's inside this 'force' branch is what you really need to fix the
> problem, right ? It seems like for the -rc cycle, all you need is:
>
> diff --git a/drivers/usb/dwc2/hcd.c b/drivers/usb/dwc2/hcd.c
> index 571c21727ff9..967d1e686efe 100644
> --- a/drivers/usb/dwc2/hcd.c
> +++ b/drivers/usb/dwc2/hcd.c
> @@ -276,6 +276,7 @@ static void dwc2_hcd_cleanup_channels(struct dwc2_hsotg 
> *hsotg)
>   */
>  void dwc2_hcd_disconnect(struct dwc2_hsotg *hsotg)
>  {
> +   u32 hprt0;
> u32 intr;
>
> /* Set status flags for the hub driver */
> @@ -315,6 +316,15 @@ void dwc2_hcd_disconnect(struct dwc2_hsotg *hsotg)
> dwc2_hcd_cleanup_channels(hsotg);
>
> dwc2_host_disconnect(hsotg);
> +
> +   hprt0 = dwc2_readl(hsotg->regs + HPRT0);
> +   if (!(hprt0 & (HPRT0_CONNDET | HPRT0_CONNSTS))) {
> +   if (hsotg->lx_state != DWC2_L0)
> +   usb_hcd_resume_roothub(hsotg->priv);
> +
> +   hsotg->flags.b.port_connect_status_change = 1;
> +   hsotg->flags.b.port_connect_status = 1;
> +   }

I'd really rather not add the duplication unless you insist.  To me it
makes it clearer to include the (small) refactor in the same patch.

If the refactor makes this change too big for an RC, then it's OK with
me to just skip this for the RC.  It's not fixing a regression or
anything.  I have no requirements to have this land in 4.4.  It fixes
a bug and I thought that the fix was pretty small and safe (despite
h

[PATCH] USB-EHCI: Delete unnecessary checks before the function call "dma_pool_destroy"

[SF Markus Elfring]

From: Markus Elfring 
Date: Mon, 16 Nov 2015 19:01:44 +0100

The dma_pool_destroy() function tests whether its argument is NULL
and then returns immediately. Thus the test around the calls is not needed.

This issue was detected by using the Coccinelle software.

Signed-off-by: Markus Elfring 
---
 drivers/usb/host/ehci-mem.c | 18 +-
 1 file changed, 5 insertions(+), 13 deletions(-)

diff --git a/drivers/usb/host/ehci-mem.c b/drivers/usb/host/ehci-mem.c
index b6205fa..4de4301 100644
--- a/drivers/usb/host/ehci-mem.c
+++ b/drivers/usb/host/ehci-mem.c
@@ -128,21 +128,13 @@ static void ehci_mem_cleanup (struct ehci_hcd *ehci)
ehci->dummy = NULL;
 
/* DMA consistent memory and pools */
-   if (ehci->qtd_pool)
-   dma_pool_destroy (ehci->qtd_pool);
+   dma_pool_destroy(ehci->qtd_pool);
ehci->qtd_pool = NULL;
-
-   if (ehci->qh_pool) {
-   dma_pool_destroy (ehci->qh_pool);
-   ehci->qh_pool = NULL;
-   }
-
-   if (ehci->itd_pool)
-   dma_pool_destroy (ehci->itd_pool);
+   dma_pool_destroy(ehci->qh_pool);
+   ehci->qh_pool = NULL;
+   dma_pool_destroy(ehci->itd_pool);
ehci->itd_pool = NULL;
-
-   if (ehci->sitd_pool)
-   dma_pool_destroy (ehci->sitd_pool);
+   dma_pool_destroy(ehci->sitd_pool);
ehci->sitd_pool = NULL;
 
if (ehci->periodic)
-- 
2.6.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

Re: [PATCH v2] USB: qcserial: Fix support for HP lt4112 LTE/HSPA+ Gobi 4G Modem

[Johan Hovold]

On Mon, Nov 16, 2015 at 01:15:46PM +0100, Bjørn Mork wrote:
> The DEVICE_HWI type was added under the faulty assumption that Huawei
> devices based on Qualcomm chipsets and firmware use the static USB
> interface numbering known from Gobi devices.  But this model does
> not apply to Huawei devices like the HP branded lt4112 (Huawei me906e).
> Huawei firmwares will dynamically assign interface numbers. Functions
> are renumbered when the firmware is reconfigured.
> 
> Fix by changing the DEVICE_HWI type to use a simplified version
> of Huawei's subclass + protocol scheme: Blacklisting known network
> interface combinations and assuming the rest are serial.
> 
> Reported-and-tested-by: Muri Nicanor 
> Tested-by: Martin Hauke 
> Cc: 
> Fixes: e7181d005e84 ("USB: qcserial: Add support for HP lt4112 LTE/HSPA+ Gobi 
> 4G Modem")
> Signed-off-by: Bjørn Mork 

Now applied, 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: [PATCH v2 1/2] usb: dwc2: host: Fix missing device insertions

[Felipe Balbi]

Hi,

(replying here for the context of why I think this is NOT the smallest
patch possible for the -rc)

Douglas Anderson  writes:
> If you've got your interrupt signals bouncing a bit as you insert your
> USB device, you might end up in a state when the device is connected but
> the driver doesn't know it.
>
> Specifically, the observed order is:
>  1. hardware sees connect
>  2. hardware sees disconnect
>  3. hardware sees connect
>  4. dwc2_port_intr() - clears connect interrupt
>  5. dwc2_handle_common_intr() - calls dwc2_hcd_disconnect()
>
> Now you'll be stuck with the cable plugged in and no further interrupts
> coming in but the driver will think we're disconnected.
>
> We'll fix this by checking for the missing connect interrupt and
> re-connecting after the disconnect is posted.  We don't skip the
> disconnect because if there is a transitory disconnect we really want to
> de-enumerate and re-enumerate.
>
> Signed-off-by: Douglas Anderson 
> ---
> Changes in v2:
> - Don't reconnect when called from _dwc2_hcd_stop() (John Youn)
>
>  drivers/usb/dwc2/core.h  |  6 --
>  drivers/usb/dwc2/core_intr.c |  4 ++--
>  drivers/usb/dwc2/hcd.c   | 40 ++--
>  drivers/usb/dwc2/hcd_intr.c  |  6 +-
>  4 files changed, 45 insertions(+), 11 deletions(-)
>
> diff --git a/drivers/usb/dwc2/core.h b/drivers/usb/dwc2/core.h
> index a66d3cb62b65..daa1c342cdac 100644
> --- a/drivers/usb/dwc2/core.h
> +++ b/drivers/usb/dwc2/core.h
> @@ -1154,12 +1154,14 @@ static inline int dwc2_hsotg_set_test_mode(struct 
> dwc2_hsotg *hsotg,
>  
>  #if IS_ENABLED(CONFIG_USB_DWC2_HOST) || IS_ENABLED(CONFIG_USB_DWC2_DUAL_ROLE)
>  extern int dwc2_hcd_get_frame_number(struct dwc2_hsotg *hsotg);
> -extern void dwc2_hcd_disconnect(struct dwc2_hsotg *hsotg);
> +extern void dwc2_hcd_connect(struct dwc2_hsotg *hsotg);
> +extern void dwc2_hcd_disconnect(struct dwc2_hsotg *hsotg, bool force);

this 'force' parameter is new and looks unnecessary for the -rc.

>  extern void dwc2_hcd_start(struct dwc2_hsotg *hsotg);
>  #else
>  static inline int dwc2_hcd_get_frame_number(struct dwc2_hsotg *hsotg)
>  { return 0; }
> -static inline void dwc2_hcd_disconnect(struct dwc2_hsotg *hsotg) {}
> +static inline void dwc2_hcd_connect(struct dwc2_hsotg *hsotg) {}
> +static inline void dwc2_hcd_disconnect(struct dwc2_hsotg *hsotg, bool force) 
> {}
>  static inline void dwc2_hcd_start(struct dwc2_hsotg *hsotg) {}
>  static inline void dwc2_hcd_remove(struct dwc2_hsotg *hsotg) {}
>  static inline int dwc2_hcd_init(struct dwc2_hsotg *hsotg, int irq)
> diff --git a/drivers/usb/dwc2/core_intr.c b/drivers/usb/dwc2/core_intr.c
> index 27daa42788b1..61601d16e233 100644
> --- a/drivers/usb/dwc2/core_intr.c
> +++ b/drivers/usb/dwc2/core_intr.c
> @@ -239,7 +239,7 @@ static void dwc2_handle_otg_intr(struct dwc2_hsotg *hsotg)
>   dev_dbg(hsotg->dev, "a_suspend->a_peripheral (%d)\n",
>   hsotg->op_state);
>   spin_unlock(&hsotg->lock);
> - dwc2_hcd_disconnect(hsotg);
> + dwc2_hcd_disconnect(hsotg, false);

because force is unnecessary (it seems to be just an optimization to
me), this change is unnecessary.

>   spin_lock(&hsotg->lock);
>   hsotg->op_state = OTG_STATE_A_PERIPHERAL;
>   } else {
> @@ -401,7 +401,7 @@ static void dwc2_handle_disconnect_intr(struct dwc2_hsotg 
> *hsotg)
>   dwc2_op_state_str(hsotg));
>  
>   if (hsotg->op_state == OTG_STATE_A_HOST)
> - dwc2_hcd_disconnect(hsotg);
> + dwc2_hcd_disconnect(hsotg, false);


and so is this.

>   dwc2_writel(GINTSTS_DISCONNINT, hsotg->regs + GINTSTS);
>  }
> diff --git a/drivers/usb/dwc2/hcd.c b/drivers/usb/dwc2/hcd.c
> index e79baf73c234..e208eac7ff57 100644
> --- a/drivers/usb/dwc2/hcd.c
> +++ b/drivers/usb/dwc2/hcd.c
> @@ -268,15 +268,33 @@ static void dwc2_hcd_cleanup_channels(struct dwc2_hsotg 
> *hsotg)
>  }
>  
>  /**
> + * dwc2_hcd_connect() - Handles connect of the HCD
> + *
> + * @hsotg: Pointer to struct dwc2_hsotg
> + *
> + * Must be called with interrupt disabled and spinlock held
> + */
> +void dwc2_hcd_connect(struct dwc2_hsotg *hsotg)
> +{
> + if (hsotg->lx_state != DWC2_L0)
> + usb_hcd_resume_root_hub(hsotg->priv);
> +
> + hsotg->flags.b.port_connect_status_change = 1;
> + hsotg->flags.b.port_connect_status = 1;
> +}

you make no mention of why this is needed. This is basically a refactor,
not a fix.

> +/**
>   * dwc2_hcd_disconnect() - Handles disconnect of the HCD
>   *
>   * @hsotg: Pointer to struct dwc2_hsotg
> + * @force: If true, we won't try to reconnect even if we see device 
> connected.
>   *
>   * Must be called with interrupt disabled and spinlock held
>   */
> -void dwc2_hcd_disconnect(struct dwc2_hsotg *hsotg)
> +void dwc2_hcd_disconnect(struct dwc2_hsotg *hsotg, bool force)

as mentioned before, unnecessary 'for

Kernel v4.3 - RCU hang, USB implicated

[Ilia Mirkin]

Hello all,

I'm not sure if USB hung because RCU died, or actually caused the RCU
death itself. Hopefully the below is useful in determining the issue.
I have a pretty standard system with a Haswell i7-4790 CPU, and these
USB controllers:

00:14.0 USB controller [0c03]: Intel Corporation 8 Series/C220 Series
Chipset Family USB xHCI [8086:8c31] (rev 05)
00:1a.0 USB controller [0c03]: Intel Corporation 8 Series/C220 Series
Chipset Family USB EHCI #2 [8086:8c2d] (rev 05)
00:1d.0 USB controller [0c03]: Intel Corporation 8 Series/C220 Series
Chipset Family USB EHCI #1 [8086:8c26] (rev 05)

The below spew kept going ad-infinitum with increasing jiffies counts
until I reset the box (it wouldn't wake up to local input, although
since that's USB, not too surprising in hindsight). I suspect it might
have been triggered by my monitors going to sleep, which in turn
disconnects the USB hub within, to which my mouse is connected. (I
found out that hooking the keyboard up to those wasn't smart... my
bootloader tends to freak out.)

Please let me know if there's any additional relevant info I can
provide. I haven't been running v4.3 long, but this is the first time
this happened. The kernel I ran earlier, v4.0.5, never produced such
errors (that I know about).

[Not particularly thrilled about the \x09 in there either...]

Thanks,

  -ilia

INFO: rcu_sched detected stalls on CPUs/tasks:
\x090: (5 GPs behind) idle=885/1/0 softirq=2623140/2623141 fqs=6990
\x09(detected by 7, t=21002 jiffies, g=3598337, c=3598336, q=6721)
Task dump for CPU 0:
swapper/0   R  running task14624 0  0 0x0008
 0018 3d6348081d6c 243081e03f18 81ebcab8
 81f39d18 81e04000 88022fa1d618 81ebc8c0
 81e0 81e03f10 816cc0e7 81e03f28
Call Trace:
 [] ? cpuidle_enter+0x17/0x20
 [] ? call_cpuidle+0x32/0x60
 [] ? cpuidle_select+0x13/0x20
 [] ? cpu_startup_entry+0x243/0x2f0
 [] ? rest_init+0x77/0x80
 [] ? start_kernel+0x43c/0x449
 [] ? x86_64_start_reservations+0x2a/0x2c
 [] ? x86_64_start_kernel+0xeb/0xee
xhci_hcd :00:14.0: xHCI host not responding to stop endpoint command.
xhci_hcd :00:14.0: Assuming host is dying, halting host.
xhci_hcd :00:14.0: HC died; cleaning up
usb 1-7: USB disconnect, device number 2
usb 2-4: USB disconnect, device number 2
usb 2-4.4: USB disconnect, device number 3
INFO: rcu_sched detected expedited stalls on CPUs: { 0 2 4 5 6 7 }
21000 jiffies s: 565
Task dump for CPU 0:
swapper/0   R  running task14624 0  0 0x0008
 0018 3d6348081d6c 243081e03f18 81ebcab8
 81f39d18 81e04000 88022fa1d618 81ebc8c0
 81e0 81e03f10 816cc0e7 81e03f28
Call Trace:
 [] ? cpuidle_enter+0x17/0x20
 [] ? call_cpuidle+0x32/0x60
 [] ? cpuidle_select+0x13/0x20
 [] ? cpu_startup_entry+0x243/0x2f0
 [] ? rest_init+0x77/0x80
 [] ? start_kernel+0x43c/0x449
 [] ? x86_64_start_reservations+0x2a/0x2c
 [] ? x86_64_start_kernel+0xeb/0xee
Task dump for CPU 2:
kworker/2:2 R  running task13152 23226  2 0x
Workqueue: usb_hub_wq hub_event
 88017fd3ba08 88017fd3b9c8 8111dfc8 0002
 88017fd3ba08 88017fd3b9e0 8111fd39 0002
 88017fd3ba30 81146727 8801 880225e62580
Call Trace:
 [] sched_show_task+0xc8/0x130
 [] dump_cpu_task+0x39/0x40
 [] synchronize_sched_expedited_wait.constprop.64+0x1f7/0x220
 [] ? wait_woken+0x80/0x80
 [] synchronize_sched_expedited+0x1f5/0x2e0
 [] synchronize_rcu_expedited+0xe/0x10
 [] bdi_unregister+0x4f/0x100
 [] blk_cleanup_queue+0xef/0x120
 [] __scsi_remove_device+0x54/0xd0
 [] scsi_forget_host+0x60/0x70
 [] scsi_remove_host+0x77/0x110
 [] usb_stor_disconnect+0x59/0xc0
 [] usb_unbind_interface+0x83/0x270
 [] __device_release_driver+0x96/0x130
 [] device_release_driver+0x23/0x30
 [] bus_remove_device+0xf8/0x140
 [] device_del+0x139/0x270
 [] ? usb_remove_ep_devs+0x1f/0x30
 [] usb_disable_device+0xa0/0x1f0
 [] usb_disconnect+0x87/0x230
 [] hub_quiesce+0x5a/0xb0
 [] hub_event+0x33f/0x1180
 [] ? pick_next_task_fair+0xa1/0x970
 [] process_one_work+0x14c/0x3d0
 [] worker_thread+0x4b/0x440
 [] ? __schedule+0x335/0x8e0
 [] ? rescuer_thread+0x2d0/0x2d0
 [] ? rescuer_thread+0x2d0/0x2d0
 [] kthread+0xc9/0xe0
 [] ? kthread_park+0x60/0x60
 [] ret_from_fork+0x3f/0x70
 [] ? kthread_park+0x60/0x60
Task dump for CPU 4:
swapper/4   R  running task15136 0  1 0x0020
 816cbf54 3d757e834a8c 034026a5fec8 81ebcab8
 81f39d18 880226a6 88022fb1d618 81ebc8c0
 880226a5c000 880226a5fec0 816cc0e7 880226a5fed8
Call Trace:
 [] ? cpuidle_enter_state+0xb4/0x210
 [] ? cpuidle_enter+0x17/0x20
 [] ? call_cpuidle+0x32/0x60
 [] ? cpuidle_select+0x13/0x20
 [] ? cpu_startup_entry+0x243/0x2f0
 [] ? start_secondary+0x12c/0x140
Task dump for CPU 5:
swapper/5   R  running task

Re: [PATCH v2 2/2] usb: dwc2: host: Clear interrupts before handling them

[Doug Anderson]

Felipe,

On Mon, Nov 16, 2015 at 8:28 AM, Felipe Balbi  wrote:
>
> Hi,
>
> Douglas Anderson  writes:
>> In general it is wise to clear interrupts before processing them.  If
>> you don't do that, you can get:
>>  1. Interrupt happens
>>  2. You look at system state and process interrupt
>>  3. A new interrupt happens
>>  4. You clear interrupt without processing it.
>>
>> This patch was actually a first attempt to fix missing device insertions
>> as described in (usb: dwc2: host: Fix missing device insertions) and it
>> did solve some of the signal bouncing problems but not all of
>> them (which is why I submitted the other patch).  Specifically, this
>> patch itself would sometimes change:
>>  1. hardware sees connect
>>  2. hardware sees disconnect
>>  3. hardware sees connect
>>  4. dwc2_port_intr() - clears connect interrupt
>>  5. dwc2_handle_common_intr() - calls dwc2_hcd_disconnect()
>>
>> ...to:
>>  1. hardware sees connect
>>  2. hardware sees disconnect
>>  3. dwc2_port_intr() - clears connect interrupt
>>  4. hardware sees connect
>>  5. dwc2_handle_common_intr() - calls dwc2_hcd_disconnect()
>>
>> ...but with different timing then sometimes we'd still miss cable
>> insertions.
>>
>> In any case, though this patch doesn't fix any (known) problems, it
>> still seems wise as a general policy to clear interrupt before handling
>> them.
>>
>> Signed-off-by: Douglas Anderson 
>> ---
>> Changes in v2: None
>>
>>  drivers/usb/dwc2/core_intr.c | 55 
>> ++--
>>  drivers/usb/dwc2/hcd_intr.c  | 16 ++---
>>  2 files changed, 35 insertions(+), 36 deletions(-)
>>
>> diff --git a/drivers/usb/dwc2/core_intr.c b/drivers/usb/dwc2/core_intr.c
>> index 61601d16e233..2a166b7eec41 100644
>> --- a/drivers/usb/dwc2/core_intr.c
>> +++ b/drivers/usb/dwc2/core_intr.c
>> @@ -80,15 +80,16 @@ static const char *dwc2_op_state_str(struct dwc2_hsotg 
>> *hsotg)
>>   */
>>  static void dwc2_handle_usb_port_intr(struct dwc2_hsotg *hsotg)
>>  {
>> - u32 hprt0 = dwc2_readl(hsotg->regs + HPRT0);
>> + u32 hprt0;
>>
>> + /* Clear interrupt */
>> + dwc2_writel(GINTSTS_PRTINT, hsotg->regs + GINTSTS);
>> +
>> + hprt0 = dwc2_readl(hsotg->regs + HPRT0);
>>   if (hprt0 & HPRT0_ENACHG) {
>>   hprt0 &= ~HPRT0_ENA;
>>   dwc2_writel(hprt0, hsotg->regs + HPRT0);
>>   }
>> -
>> - /* Clear interrupt */
>> - dwc2_writel(GINTSTS_PRTINT, hsotg->regs + GINTSTS);
>
> isn't this a regression ? You're first clearing the interrupts and only
> then reading to check what's pending, however, what's pending has just
> been cleared. Seems like this should be:
>
> hprt0 = dwc2_readl(HPRT0);
> dwc2_writeal(PRTINT, GINTSTS);

Actually, we could probably remove the setting of GINTSTS_PRTINT
completely.  The docs I have say that the GINTSTS_PRTINT is read only
and that:

> The core sets this bit to indicate a change in port status of one of the
> DWC_otg core ports in Host mode. The application must read the
> Host Port Control and Status (HPRT) register to determine the exact
> event that caused this interrupt. The application must clear the
> appropriate status bit in the Host Port Control and Status register to
> clear this bit.

...so writing PRTINT is probably useless, but John can confirm.

...if it wasn't useless to clear PRTINT it would depend on how things
were implemented.  One (purely speculative) case where my patch would
be more correct:

1. Interrupt source 1 in HPRT fires.  PRTINT is latched to 1 and
interrupt handler is called.
2. Read HPRT
3. Interrupt source 2 in HPRT fires.  PRTINT is already 1, so no new
interrupt handler called.
4. Clear PRTINT
5. Handle interrupt source 1

...now we'll never get an interrupt for interrupt source 2.


In any case, I think this particular change is a no-op, but other
changes in this patch (probably) aren't.


> Also, these two patches look very large for the -rc. I'll move them to
> v4.5 merge window unless you can convince me that they are, indeed, the
> smallest change possible to fix the problem you're facing and that they
> are, indeed, regressions.

Patch #2 should definitely _not_ go into the RC.  It is a relatively
intrusive patch, fixes no known issues, and has only had light
testing.  I haven't even landed this change locally in ChromeOS since
it's a bit scary to me I haven't found any good use for it.  I do keep
testing with it to see if it fixes any of my issues, though.  ;)


I'd like to see patch #1 should go into the RC since it fixes problems
that are really easy to reproduce.  IMHO It's also neither big nor
scary.  FWIW it's already landed in the ChromeOS tree as of Oct 20th
(almost a month).  While it hasn't hit stable channel yet, it's been
on beta channel and nobody has discovered any issues with it yet.


Thanks!  :)

-Doug
--
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.ker

Re: [PATCH 07/21] usb/gadget: Remove set-but-not-used variables

[Felipe Balbi]

Christoph Hellwig  writes:
> On Thu, Oct 22, 2015 at 03:55:45PM -0700, Bart Van Assche wrote:
>> Avoid that building with W=1 triggers compiler warnings about
>> set-but-not-used variables.
>
> Looks good,
>
> Reviewed-by: Christoph Hellwig 

should I take this patch or will it go through Target ?

-- 
balbi


signature.asc
Description: PGP signature

Re: [PATCH 2/2] usb: phy: msm: fix connect/disconnect bug for dragonboard OTG port

[Felipe Balbi]

Hi,

Peter Chen  writes:
> On Wed, Nov 11, 2015 at 09:48:00AM -0800, Tim Bird wrote:
>> 
>> 
>> On 11/10/2015 07:14 PM, Peter Chen wrote:
>> > On Tue, Nov 10, 2015 at 04:46:51PM -0800, Tim Bird wrote:
>> >> This fixes a bug where if you disconnect and re-connect the USB cable,
>> >> the gadget driver stops working.
>> >>
>> >> Add support for async_irq to wake up driver from low power mode.
>> >> Without this, the power management code never calls resume.
>> >> Also, have the phy driver kick the gadget driver (chipidea otg)
>> >> by having the chipidea driver register with it, for vbus connect
>> >> notifications.
>> >>
>> >> Signed-off-by: Tim Bird 
>> >> ---
>> >>  drivers/usb/chipidea/udc.c|  6 ++
>> >>  drivers/usb/phy/phy-msm-usb.c | 16 
>> >>  include/linux/usb/msm_hsusb.h |  1 +
>> >>  3 files changed, 23 insertions(+)

I just wanna know how you guys want this to be handled ? Through my tree
or chipidea's ? Or do we break the dependencies between the changes ?

-- 
balbi


signature.asc
Description: PGP signature

Re: at91sam9x5: USB mass storage gadget problems

[Felipe Balbi]

Hi,

Boris Brezillon  writes:
> Hi Douglas,
>
> On Sat, 14 Nov 2015 14:15:30 -0500
> Douglas Gilbert  wrote:
>
>> On 15-11-12 05:18 PM, Alan Stern wrote:
>> > On Thu, 12 Nov 2015, Douglas Gilbert wrote:
>> >
>> >> Yes, the X201 has USB 2.0 host ports. It is running a stock Ubuntu
>> >> 15.10 kernel: 4.2.0-18-generic and the log indicates that the
>> >> ehci_pci driver is being used. Part of the X201's syslog is
>> >> attached in which a driver complains about the invalid maxpacket
>> >> values of 64.
>> >>
>> >> So its seems that the ehci drivers as used on the X201 can work
>> >> around the invalid maxpacket value (64) while the xhci drivers
>> >> used by the X240 (due to the USB 3.0 host ports) get tripped up.
>> >
>> > Yes, I think that's right.  The restriction that high speed bulk
>> > endpoints must have a maxpacket size of 512 is enforced by the xHCI
>> > hardware but not by the EHCI hardware; this explains why ehci-hcd is
>> > able to work around such violations while xhci-hcd isn't.
>> >
>> >> Still looking at drivers/usb/gadget/udc/atmel_usba_udc.c which
>> >> has lots of changes between lk 3.19.0-rc4 and 4.0.0-rc4 . The
>> >> maxpacket value seems (to me) to be related to the fifo-size
>> >> in the gadget section of this dts include file:
>> >> arch/arm/boot/dts/at91sam9x5.dtsi
>> >> which has 1024 for ep1 through ep5 and 64 for ep0.
>> >
>> > The assignment of endpoints isn't done in the UDC driver; it is carried
>> > out by epautoconf.c in drivers/usb/gadget/.  So you may need to expand
>> > your bisection search beyond the single UDC driver source file.
>> >
>> > Have you tried enabling debugging in the gadget drivers and checking
>> > out the kernel log on the gadget?
>> >
>> >> So it looks like 1.5 bugs:
>> >> - one in atmel's udc driver for the at91sam9x5 family, and
>> >> - the inconsistency between the ehci driver working around
>> >>   invalid maxpacket values and the xhci driver behaving
>> >>   badly (lots of bus resets and a badly made SCSI storage
>> >>   device [e.g. INQUIRY works but READ(10) fails]).
>> >
>> > The first is clearly a bug, although at the moment we can't be sure
>> > where.  The second is an unavoidable hardware restriction, not a bug.
>> > Anyway, if you fix the first problem then the second won't be an issue.
>> 
>> Found the udc driver bug. A shadow register value was introduced
>> around lk 4.0 for the Atmel 9x5/sama5d3 UDPHS driver
>> (atmel_usba_udc.c) for the interrupt status register. It used the
>> interrupt enable register (last written) value as a mask. At least
>> for the at91sam9g25 that works apart from the SPEED bit (bit 0)
>> which is only present in the interrupt status register.
>> 
>> It seems that USB negotiates the link speed during resets and at
>> the G25 end, even though the hardware had negotiated a "high
>> speed" link with the host, the logic in usba_udc_irq() deduced it
>> was only a full speed link (due to the above bug). Thereafter
>> there was confusion which the ehci_hcd host driver could handle
>> but the xhci_pci driver could not. In the xhci_pci case there
>> were multiple high speed link resets in the host log, matched
>> at the device (G25) end with a similar number of reported _full_
>> speed resets.
>> 
>> The author of the changes to the code that caused this is
>> cc-ed on this post. He might like to consider the attached
>> patch which fixed my problem. However the shadow mask register
>> technique might have other subtle issues that I'm not
>> qualified to address.
>
> Looks good to me, and sorry for the inconvenience.
>
>> 
>> If I don't hear anything on this issue then I can produce
>> a patch. Does it go through the ARM or USB (or both) trees?
>
> You can go ahead and send a patch to the ARM and USB MLs (+
> appropriate maintainers), unless you want me to do it.
>
>> 
>> If my patch is sufficient, then perhaps it should also be
>> issued against the lk 4.0, 4.1, 4.2 and 4.3 kernels that are
>> still actively maintained.
>
> Yep, adding the following line after your SoB should do the trick:
>
> Cc:  #4.0+

please send this out as a real patch, otherwise I can't apply.

-- 
balbi


signature.asc
Description: PGP signature

Re: [PATCH] usb: musb: enable usb_dma parameter

[Felipe Balbi]

Hi,

Bin Liu  writes:
> On 11/13/2015 06:57 PM, Greg KH wrote:
>> On Fri, Nov 13, 2015 at 03:45:24PM -0600, Bin Liu wrote:
>>> Change the permission of usb_dma parameter so it can be used for runtime
>>> debug without reboot.
>>
>> Why would you want to do that?  This is only used at init time, so if
>> you change it while the driver is running, I don't think you will
>> actually affect anything.
>
> During debug, I want to run with CPPI enabled or disabled without reboot 
> the board to load different kernel image.
>
> With this patch, I can archive this by
>
> - unbind musb_hdrc
> - change usb_dma param
> - bind musb_hdrc
>
>>
>> Have you tested this out?
>
> Yes, I did and it works for me.

this is correct, we check use_dma every time before starting a DMA
transfer. But claiming that you need to reboot is kinda dodgy. You could
very well rmmod/modprobe with the different parameter ;-)

In any case, this is useful and causes no regressions, I'll take it
anyways.

-- 
balbi


signature.asc
Description: PGP signature

Re: [linux-sunxi] Re: [PATCH 2/2] ehci-platform: Add support for controllers with multiple reset lines

[Hans de Goede]

Hi,

On 16-11-15 18:01, Philipp Zabel wrote:

Am Montag, den 16.11.2015, 17:49 +0100 schrieb Hans de Goede:

Hi,

On 16-11-15 17:04, Chen-Yu Tsai wrote:

On Mon, Nov 16, 2015 at 11:42 PM, Alan Stern  wrote:

On Sun, 15 Nov 2015, Hans de Goede wrote:


From: Reinder de Haan 

At least the EHCI found on the Allwinnner H3 SoC needs multiple reset
lines, the controller will not initialize while the reset for its
companion OHCI is still asserted, which means we need to de-assert
2 reset-controllers for this EHCI controller to work.


I assume that reset_control_deassert() is smart enough to maintain a
count of de-assertions, and it doesn't actually turn on the reset line
until the count drops to 0.  Right?


No it doesn't. That might be a problem when 2 devices (such as EHCI / OHCI
pairs) share a reset line, one probes successfully while the other doesn't.
Hans?


Ugh, good catch Alan, so I think the best way to solve this is to
actually make reset_control do a deassert / (re)assert count like
is done already for clocks, there is bound to be more hardware out there
which shares a reset line between 2 related blocks.

I'll whip up a patch for this, submit it and then we'll see.


If there are two devices sharing the same reset line that is initially
held asserted, do the two drivers somehow have to synchronize before
releasing the reset together?


Not to my knowledge, I suggest that we simply treat this same as
regulators / clocks where the first one to enable it actually gets
it enabled (de-asserted in case of a reset), and the last one
to disable (assert) it (so dropping the usage counter back to 0) leads
to it being asserted again.

This seems to work well enough for clocks / regulators and phys, and
at least for my use-case it should work fine for the shared reset too
(I will test to make sure of course).

So from my pov a simple counter should suffice, does that work for you ?

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

Re: [PATCH 1/1] usb: gadget: f_loopback: fix the warning during the enumeration

[Felipe Balbi]

Hi

Krzysztof Opasiak  writes:
> On 11/16/2015 05:34 PM, Felipe Balbi wrote:
>>
>> Hi,
>>
>> Peter Chen  writes:
>>> The current code tries to allocate memory with GFP_KERNEL at
>>> interrupt context, it would show below warning during the enumeration
>>> when I test it with chipidea hardware, change GFP flag as GFP_ATOMIC
>>> can fix this issue.
>>>
>>> [   40.438237] zero gadget: high-speed config #2: loopback
>>> [   40.444924] [ cut here ]
>>> [   40.449609] WARNING: CPU: 0 PID: 0 at kernel/locking/lockdep.c:2755 
>>> lockdep_trace_alloc+0x108/0x128()
>>> [   40.461715] DEBUG_LOCKS_WARN_ON(irqs_disabled_flags(flags))
>>> [   40.467130] Modules linked in:
>>> [   40.470216]  usb_f_ss_lb g_zero libcomposite evbug
>>> [   40.473822] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 
>>> 4.3.0-rc5-00168-gb730aaf #604
>>> [   40.481496] Hardware name: Freescale i.MX6 SoloX (Device Tree)
>>> [   40.487345] Backtrace:
>>> [   40.489857] [<80014e94>] (dump_backtrace) from [<80015088>] 
>>> (show_stack+0x18/0x1c)
>>> [   40.497445]  r6:80b67a80 r5: r4: r3:
>>> [   40.503234] [<80015070>] (show_stack) from [<802e27b4>] 
>>> (dump_stack+0x8c/0xa4)
>>> [   40.510503] [<802e2728>] (dump_stack) from [<8002cfe8>] 
>>> (warn_slowpath_common+0x80/0xbc)
>>> [   40.518612]  r6:8007510c r5:0009 r4:80b49c88 r3:0001
>>> [   40.524396] [<8002cf68>] (warn_slowpath_common) from [<8002d05c>] 
>>> (warn_slowpath_fmt+0x38/0x40)
>>> [   40.533109]  r8:bcfdef80 r7:bdb705cc r6:80d0 r5:be001e80 r4:809cc278
>>> [   40.539965] [<8002d028>] (warn_slowpath_fmt) from [<8007510c>] 
>>> (lockdep_trace_alloc+0x108/0x128)
>>> [   40.548766]  r3:809d0128 r2:809cc278
>>> [   40.552401]  r4:600b0193
>>> [   40.554990] [<80075004>] (lockdep_trace_alloc) from [<801093d4>] 
>>> (kmem_cache_alloc+0x28/0x15c)
>>> [   40.563618]  r4:80d0 r3:80b4aa8c
>>> [   40.567270] [<801093ac>] (kmem_cache_alloc) from [<804d95e4>] 
>>> (ep_alloc_request+0x58/0x68)
>>> [   40.575550]  r10:7f01f104 r9:0001 r8:bcfdef80 r7:bdb705cc 
>>> r6:bc178700 r5:
>>> [   40.583512]  r4:bcfdef80 r3:813c0a38
>>> [   40.587183] [<804d958c>] (ep_alloc_request) from [<7f01f7ec>] 
>>> (loopback_set_alt+0x114/0x21c [usb_f_ss_lb])
>>> [   40.596929] [<7f01f6d8>] (loopback_set_alt [usb_f_ss_lb]) from 
>>> [<7f006910>] (composite_setup+0xbd0/0x17e8 [libcomposite])
>>> [   40.607902]  r10:bd3a2c0c r9: r8:bcfdef80 r7:bc178700 
>>> r6:bdb702d0 r5:bcfdefdc
>>> [   40.615866]  r4:7f0199b4 r3:0002
>>> [   40.619542] [<7f005d40>] (composite_setup [libcomposite]) from 
>>> [<804dae88>] (udc_irq+0x784/0xd1c)
>>> [   40.628431]  r10:80bb5619 r9:c0876140 r8:00012001 r7:bdb71010 
>>> r6:bdb70568 r5:00010001
>>> [   40.636392]  r4:bdb70014
>>> [   40.638985] [<804da704>] (udc_irq) from [<804d64f8>] (ci_irq+0x5c/0x118)
>>> [   40.645702]  r10:80bb5619 r9:be11e000 r8:0117 r7: 
>>> r6:bdb71010 r5:be11e060
>>> [   40.653666]  r4:bdb70010
>>> [   40.656261] [<804d649c>] (ci_irq) from [<8007f638>] 
>>> (handle_irq_event_percpu+0x7c/0x13c)
>>> [   40.664367]  r6: r5:be11e060 r4:bdb05cc0 r3:804d649c
>>> [   40.670149] [<8007f5bc>] (handle_irq_event_percpu) from [<8007f740>] 
>>> (handle_irq_event+0x48/0x6c)
>>> [   40.679036]  r10: r9:be008000 r8:0001 r7: 
>>> r6:bdb05cc0 r5:be11e060
>>> [   40.686998]  r4:be11e000
>>> [   40.689581] [<8007f6f8>] (handle_irq_event) from [<80082850>] 
>>> (handle_fasteoi_irq+0xd4/0x1b0)
>>> [   40.698120]  r6:80b56a30 r5:be11e060 r4:be11e000 r3:
>>> [   40.703898] [<8008277c>] (handle_fasteoi_irq) from [<8007ec04>] 
>>> (generic_handle_irq+0x28/0x3c)
>>> [   40.712524]  r7: r6:80b4aaf4 r5:0117 r4:80b445fc
>>> [   40.718304] [<8007ebdc>] (generic_handle_irq) from [<8007ef20>] 
>>> (__handle_domain_irq+0x6c/0xe8)
>>> [   40.727033] [<8007eeb4>] (__handle_domain_irq) from [<800095d4>] 
>>> (gic_handle_irq+0x48/0x94)
>>> [   40.735402]  r9:c080f100 r8:80b4ac6c r7:c080e100 r6:80b67d40 r5:80b49f00 
>>> r4:c080e10c
>>> [   40.743290] [<8000958c>] (gic_handle_irq) from [<80015d38>] 
>>> (__irq_svc+0x58/0x78)
>>> [   40.750791] Exception stack(0x80b49f00 to 0x80b49f48)
>>> [   40.755873] 9f00: 0001 0001  80024320 80b48000 80b4a9d0 
>>> 80b4a984 80b433e4
>>> [   40.764078] 9f20: 0001 807f4680  80b49f5c 80b49f20 80b49f50 
>>> 80071ca4 800113fc
>>> [   40.772272] 9f40: 200b0013 
>>> [   40.775776]  r9:807f4680 r8:0001 r7:80b49f34 r6: r5:200b0013 
>>> r4:800113fc
>>> [   40.783677] [<800113d4>] (arch_cpu_idle) from [<8006c5bc>] 
>>> (default_idle_call+0x28/0x38)
>>> [   40.791798] [<8006c594>] (default_idle_call) from [<8006c6dc>] 
>>> (cpu_startup_entry+0x110/0x1b0)
>>> [   40.800445] [<8006c5cc>] (cpu_startup_entry) from [<807e95dc>] 
>>> (rest_init+0x12c/0x168)
>>> [   40.808376]  r7:80b4a8c0 r3:807f4b7c
>>> [   40.812030] [<807e94b0>] (rest_init) from [<80ad7cc0>] 
>>> (start_kernel+0x360/0x3d4)
>>> [

Re: [PATCH] usb: phy: msm: fix a possible NULL dereference

[Felipe Balbi]

Hi,

LABBE Corentin  writes:
> of_match_device could return NULL, and so cause a NULL pointer
> dereference later. Renaming id to of_id (like all others do) in the
> process.
>
> Reported-by: coverity (CID 1324133)
> Signed-off-by: LABBE Corentin 
> ---
>  drivers/usb/phy/phy-msm-usb.c | 9 ++---
>  1 file changed, 6 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/usb/phy/phy-msm-usb.c b/drivers/usb/phy/phy-msm-usb.c
> index 80eb991..c4a66cf 100644
> --- a/drivers/usb/phy/phy-msm-usb.c
> +++ b/drivers/usb/phy/phy-msm-usb.c
> @@ -1506,20 +1506,23 @@ static int msm_otg_read_dt(struct platform_device 
> *pdev, struct msm_otg *motg)
>  {
>   struct msm_otg_platform_data *pdata;
>   struct extcon_dev *ext_id, *ext_vbus;
> - const struct of_device_id *id;
> + const struct of_device_id *of_id;

and why did you need to rename this variable ? Please resend without the
variable rename.

-- 
balbi


signature.asc
Description: PGP signature

[PATCH] usb: dwc3: gadget: let us set lower max_speed

[Felipe Balbi]

From: Ben McCauley 

In some SoCs, dwc3 is implemented as a USB2.0 only
core, meaning that it can't ever achieve SuperSpeed.

Currect driver always sets gadget.max_speed to
USB_SPEED_SUPER unconditionally. This can causes
issues to some Host stacks where the host will issue
a GetBOS() request and we will reply with a BOS
containing Superspeed Capability Descriptor.

At least Windows seems to be upset by this fact and
prints a warning that we should connect $this device
to another port.

[ ba...@ti.com : rewrote entire commit, including
source code comment to make a lot clearer what the
problem is ]

Signed-off-by: Ben McCauley 
Signed-off-by: Felipe Balbi 
---
 drivers/usb/dwc3/gadget.c | 23 ++-
 1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/drivers/usb/dwc3/gadget.c b/drivers/usb/dwc3/gadget.c
index 55ba447fdf8b..91035eefbe77 100644
--- a/drivers/usb/dwc3/gadget.c
+++ b/drivers/usb/dwc3/gadget.c
@@ -2744,12 +2744,33 @@ int dwc3_gadget_init(struct dwc3 *dwc)
}
 
dwc->gadget.ops = &dwc3_gadget_ops;
-   dwc->gadget.max_speed   = USB_SPEED_SUPER;
dwc->gadget.speed   = USB_SPEED_UNKNOWN;
dwc->gadget.sg_supported= true;
dwc->gadget.name= "dwc3-gadget";
 
/*
+* FIXME We might be setting max_speed to revision < DWC3_REVISION_220A)
+   dwc3_trace(trace_dwc3_gadget, "Changing max_speed on rev 
%08x\n",
+   dwc->revision);
+
+   dwc->gadget.max_speed   = dwc->maximum_speed;
+
+   /*
 * Per databook, DWC3 needs buffer size to be aligned to MaxPacketSize
 * on ep out.
 */
-- 
2.6.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

Re: [linux-sunxi] Re: [PATCH 2/2] ehci-platform: Add support for controllers with multiple reset lines

[Philipp Zabel]

Am Montag, den 16.11.2015, 17:49 +0100 schrieb Hans de Goede:
> Hi,
> 
> On 16-11-15 17:04, Chen-Yu Tsai wrote:
> > On Mon, Nov 16, 2015 at 11:42 PM, Alan Stern  
> > wrote:
> >> On Sun, 15 Nov 2015, Hans de Goede wrote:
> >>
> >>> From: Reinder de Haan 
> >>>
> >>> At least the EHCI found on the Allwinnner H3 SoC needs multiple reset
> >>> lines, the controller will not initialize while the reset for its
> >>> companion OHCI is still asserted, which means we need to de-assert
> >>> 2 reset-controllers for this EHCI controller to work.
> >>
> >> I assume that reset_control_deassert() is smart enough to maintain a
> >> count of de-assertions, and it doesn't actually turn on the reset line
> >> until the count drops to 0.  Right?
> >
> > No it doesn't. That might be a problem when 2 devices (such as EHCI / OHCI
> > pairs) share a reset line, one probes successfully while the other doesn't.
> > Hans?
> 
> Ugh, good catch Alan, so I think the best way to solve this is to
> actually make reset_control do a deassert / (re)assert count like
> is done already for clocks, there is bound to be more hardware out there
> which shares a reset line between 2 related blocks.
> 
> I'll whip up a patch for this, submit it and then we'll see.

If there are two devices sharing the same reset line that is initially
held asserted, do the two drivers somehow have to synchronize before
releasing the reset together?

regards
Philipp

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

Re: [PATCH 1/2] reset: Add of_reset_control_get_by_index

[Philipp Zabel]

Hi Hans,

Am Sonntag, den 15.11.2015, 20:44 +0100 schrieb Hans de Goede:
> From: Reinder de Haan 
> 
> In some cases it is useful to be able to get a reset-controller by
> index rather then by name. E.g. for a generic ip-block driver such
> as the ehci-platform drivers which needs to support more then one reset,
> without knowing the names of the reset lines (as that would make it
> non generic).
> 
> Signed-off-by: Reinder de Haan 
> Signed-off-by: Hans de Goede 

Thank you for the patch, but I already have a similar patch in the
queue. I have included it in a pull request sent to the arm-soc
maintainers today.

best regards
Philipp

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

Re: [PATCH 1/3] usb: gadget: f_sourcesink: add queue depth

[Krzysztof Opasiak]

On 11/13/2015 09:00 AM, Peter Chen wrote:

Add queue depth for both iso and bulk transfer, with more queues, we
can do performance and stress test using sourcesink, and update g_zero
accordingly.

Signed-off-by: Peter Chen 
---
  drivers/usb/gadget/function/f_sourcesink.c | 144 ++---
  drivers/usb/gadget/function/g_zero.h   |   6 ++
  drivers/usb/gadget/legacy/zero.c   |  12 +++
  3 files changed, 129 insertions(+), 33 deletions(-)

diff --git a/drivers/usb/gadget/function/f_sourcesink.c 
b/drivers/usb/gadget/function/f_sourcesink.c
index d7646d3..4ab603e8 100644
--- a/drivers/usb/gadget/function/f_sourcesink.c
+++ b/drivers/usb/gadget/function/f_sourcesink.c
@@ -34,13 +34,6 @@
   * plus two that support control-OUT tests.  If the optional "autoresume"
   * mode is enabled, it provides good functional coverage for the "USBCV"
   * test harness from USB-IF.
- *
- * Note that because this doesn't queue more than one request at a time,
- * some other function must be used to test queueing logic.  The network
- * link (g_ether) is the best overall option for that, since its TX and RX
- * queues are relatively independent, will receive a range of packet sizes,
- * and can often be made to run out completely.  Those issues are important
- * when stress testing peripheral controller drivers.
   */
  struct f_sourcesink {
struct usb_function function;
@@ -57,6 +50,8 @@ struct f_sourcesink {
unsigned isoc_mult;
unsigned isoc_maxburst;
unsigned buflen;
+   unsigned bulk_qlen;
+   unsigned iso_qlen;
  };

  static inline struct f_sourcesink *func_to_ss(struct usb_function *f)
@@ -595,31 +590,33 @@ static int source_sink_start_ep(struct f_sourcesink *ss, 
bool is_in,
  {
struct usb_ep   *ep;
struct usb_request  *req;
-   int i, size, status;
-
-   for (i = 0; i < 8; i++) {
-   if (is_iso) {
-   switch (speed) {
-   case USB_SPEED_SUPER:
-   size = ss->isoc_maxpacket *
-   (ss->isoc_mult + 1) *
-   (ss->isoc_maxburst + 1);
-   break;
-   case USB_SPEED_HIGH:
-   size = ss->isoc_maxpacket * (ss->isoc_mult + 1);
-   break;
-   default:
-   size = ss->isoc_maxpacket > 1023 ?
-   1023 : ss->isoc_maxpacket;
-   break;
-   }
-   ep = is_in ? ss->iso_in_ep : ss->iso_out_ep;
-   req = ss_alloc_ep_req(ep, size);
-   } else {
-   ep = is_in ? ss->in_ep : ss->out_ep;
-   req = ss_alloc_ep_req(ep, 0);
+   int i, size, qlen, status = 0;
+
+   if (is_iso) {
+   switch (speed) {
+   case USB_SPEED_SUPER:
+   size = ss->isoc_maxpacket *
+   (ss->isoc_mult + 1) *
+   (ss->isoc_maxburst + 1);
+   break;
+   case USB_SPEED_HIGH:
+   size = ss->isoc_maxpacket * (ss->isoc_mult + 1);
+   break;
+   default:
+   size = ss->isoc_maxpacket > 1023 ?
+   1023 : ss->isoc_maxpacket;
+   break;
}
+   ep = is_in ? ss->iso_in_ep : ss->iso_out_ep;
+   qlen = ss->iso_qlen;
+   } else {
+   ep = is_in ? ss->in_ep : ss->out_ep;
+   qlen = ss->bulk_qlen;
+   size = 0;
+   }

+   for (i = 0; i < qlen; i++) {
+   req = ss_alloc_ep_req(ep, size);
if (!req)
return -ENOMEM;

@@ -639,9 +636,6 @@ static int source_sink_start_ep(struct f_sourcesink *ss, 
bool is_in,
  ep->name, status);
free_ep_req(ep, req);


Well... to be honest I would prefer to return here an error instead of 
silently try with another request as we may end up in situation that 
qlen is 8 and we haven't successfully enqueued any request but we treat 
this as a success.


Best regards,
--
Krzysztof Opasiak
Samsung R&D Institute Poland
Samsung Electronics
--
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 03/23] usb: gadget: f_sourcesink: free requests in sourcesink_disable()

[Krzysztof Opasiak]

Hi,

On 11/10/2015 03:02 AM, Peter Chen wrote:

On Fri, Nov 06, 2015 at 10:58:39AM +0100, Krzysztof Opasiak wrote:



On 11/06/2015 10:48 AM, Peter Chen wrote:

On Fri, Nov 06, 2015 at 09:50:11AM +0100, Robert Baldyga wrote:

On 11/06/2015 09:15 AM, Peter Chen wrote:

On Tue, Nov 03, 2015 at 01:53:42PM +0100, Robert Baldyga wrote:

USB requests in SourceSink function are allocated in sourcesink_get_alt()
function, so we prefer to free them rather in sourcesink_disable() than
in source_sink_complete() when request is completed with error. It provides
better symetry in resource management and improves code readability.

Signed-off-by: Robert Baldyga 
---
  drivers/usb/gadget/function/f_sourcesink.c | 33 +++---
  1 file changed, 30 insertions(+), 3 deletions(-)

diff --git a/drivers/usb/gadget/function/f_sourcesink.c 
b/drivers/usb/gadget/function/f_sourcesink.c
index a8b68c6..d8f5f56 100644
--- a/drivers/usb/gadget/function/f_sourcesink.c
+++ b/drivers/usb/gadget/function/f_sourcesink.c
@@ -22,6 +22,8 @@
  #include "g_zero.h"
  #include "u_f.h"

+#define REQ_CNT8
+


It would be buffer if we can have module parameter for this like
qlen at f_loopback.

@@ -561,7 +568,6 @@ static void source_sink_complete(struct usb_ep *ep, struct 
usb_request *req)
req->actual, req->length);
if (ep == ss->out_ep)
check_read_data(ss, req);
-   free_ep_req(ep, req);


I find the current code may cause memory leak, since above code
is only called one time.



I don't see what you mean. Can you explain a bit more in which situation
can memory leak take place?


Oh, sorry, I have not seen there is a "break;" at the source_sink_start_ep for
none-iso endpoint, so, I am wrong, no memory leak here.

I have tried changing bulk for 8 requests, the performance improves
greatly, but still a little problem for OUT,  I will see what's the matter.
Besides, it will be better we can have a qlen parameters like f_loopback,
in that case, we can improve the performance for gadget, and get the best 
performance
when testing with usbtest, I will do it later.



Moreover, I would suggest to add qlen and iso_qlen params not only
qlen as even now we are using different qlen for bulk and iso.



Krzysztof, would you know why we have different qlen for bulk and iso now?



Well, in my opinion iso and bulk use different buf sizes and simply 
different number of requests is needed to saturate the bandwidth.


--
Krzysztof Opasiak
Samsung R&D Institute Poland
Samsung Electronics
--
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: [linux-sunxi] Re: [PATCH 2/2] ehci-platform: Add support for controllers with multiple reset lines

[Hans de Goede]

Hi,

On 16-11-15 17:04, Chen-Yu Tsai wrote:

On Mon, Nov 16, 2015 at 11:42 PM, Alan Stern  wrote:

On Sun, 15 Nov 2015, Hans de Goede wrote:


From: Reinder de Haan 

At least the EHCI found on the Allwinnner H3 SoC needs multiple reset
lines, the controller will not initialize while the reset for its
companion OHCI is still asserted, which means we need to de-assert
2 reset-controllers for this EHCI controller to work.


I assume that reset_control_deassert() is smart enough to maintain a
count of de-assertions, and it doesn't actually turn on the reset line
until the count drops to 0.  Right?


No it doesn't. That might be a problem when 2 devices (such as EHCI / OHCI
pairs) share a reset line, one probes successfully while the other doesn't.
Hans?


Ugh, good catch Alan, so I think the best way to solve this is to
actually make reset_control do a deassert / (re)assert count like
is done already for clocks, there is bound to be more hardware out there
which shares a reset line between 2 related blocks.

I'll whip up a patch for this, submit it and then we'll see.

Regards,

Hans





Signed-off-by: Reinder de Haan 
Signed-off-by: Hans de Goede 


...


@@ -229,18 +230,24 @@ static int ehci_platform_probe(struct platform_device 
*dev)
   break;
   }
   }
- }

- priv->rst = devm_reset_control_get_optional(&dev->dev, NULL);
- if (IS_ERR(priv->rst)) {
- err = PTR_ERR(priv->rst);
- if (err == -EPROBE_DEFER)
- goto err_put_clks;
- priv->rst = NULL;
- } else {
- err = reset_control_deassert(priv->rst);
- if (err)
- goto err_put_clks;
+ for (rst = 0; rst < EHCI_MAX_RESETS; rst++) {


What happens on platforms that don't use OF?  Or if pdata is not equal
to &ehci_platform_defaults?  Can you guarantee that those platforms
will never need to turn off a reset line?


The reset control framework is OF / DT only at the moment.

Regards
ChenYu


+ priv->resets[rst] =
+ of_reset_control_get_by_index(dev->dev.of_node,
+   rst);


The style used in this file is to indent continuation lines to 2 two
stops, not to line things up with an open paren on the previous line.

The rest of the patch looks okay.

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 1/1] usb: gadget: f_loopback: fix the warning during the enumeration

[Krzysztof Opasiak]

On 11/16/2015 05:34 PM, Felipe Balbi wrote:


Hi,

Peter Chen  writes:

The current code tries to allocate memory with GFP_KERNEL at
interrupt context, it would show below warning during the enumeration
when I test it with chipidea hardware, change GFP flag as GFP_ATOMIC
can fix this issue.

[   40.438237] zero gadget: high-speed config #2: loopback
[   40.444924] [ cut here ]
[   40.449609] WARNING: CPU: 0 PID: 0 at kernel/locking/lockdep.c:2755 
lockdep_trace_alloc+0x108/0x128()
[   40.461715] DEBUG_LOCKS_WARN_ON(irqs_disabled_flags(flags))
[   40.467130] Modules linked in:
[   40.470216]  usb_f_ss_lb g_zero libcomposite evbug
[   40.473822] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 
4.3.0-rc5-00168-gb730aaf #604
[   40.481496] Hardware name: Freescale i.MX6 SoloX (Device Tree)
[   40.487345] Backtrace:
[   40.489857] [<80014e94>] (dump_backtrace) from [<80015088>] 
(show_stack+0x18/0x1c)
[   40.497445]  r6:80b67a80 r5: r4: r3:
[   40.503234] [<80015070>] (show_stack) from [<802e27b4>] 
(dump_stack+0x8c/0xa4)
[   40.510503] [<802e2728>] (dump_stack) from [<8002cfe8>] 
(warn_slowpath_common+0x80/0xbc)
[   40.518612]  r6:8007510c r5:0009 r4:80b49c88 r3:0001
[   40.524396] [<8002cf68>] (warn_slowpath_common) from [<8002d05c>] 
(warn_slowpath_fmt+0x38/0x40)
[   40.533109]  r8:bcfdef80 r7:bdb705cc r6:80d0 r5:be001e80 r4:809cc278
[   40.539965] [<8002d028>] (warn_slowpath_fmt) from [<8007510c>] 
(lockdep_trace_alloc+0x108/0x128)
[   40.548766]  r3:809d0128 r2:809cc278
[   40.552401]  r4:600b0193
[   40.554990] [<80075004>] (lockdep_trace_alloc) from [<801093d4>] 
(kmem_cache_alloc+0x28/0x15c)
[   40.563618]  r4:80d0 r3:80b4aa8c
[   40.567270] [<801093ac>] (kmem_cache_alloc) from [<804d95e4>] 
(ep_alloc_request+0x58/0x68)
[   40.575550]  r10:7f01f104 r9:0001 r8:bcfdef80 r7:bdb705cc r6:bc178700 
r5:
[   40.583512]  r4:bcfdef80 r3:813c0a38
[   40.587183] [<804d958c>] (ep_alloc_request) from [<7f01f7ec>] 
(loopback_set_alt+0x114/0x21c [usb_f_ss_lb])
[   40.596929] [<7f01f6d8>] (loopback_set_alt [usb_f_ss_lb]) from [<7f006910>] 
(composite_setup+0xbd0/0x17e8 [libcomposite])
[   40.607902]  r10:bd3a2c0c r9: r8:bcfdef80 r7:bc178700 r6:bdb702d0 
r5:bcfdefdc
[   40.615866]  r4:7f0199b4 r3:0002
[   40.619542] [<7f005d40>] (composite_setup [libcomposite]) from [<804dae88>] 
(udc_irq+0x784/0xd1c)
[   40.628431]  r10:80bb5619 r9:c0876140 r8:00012001 r7:bdb71010 r6:bdb70568 
r5:00010001
[   40.636392]  r4:bdb70014
[   40.638985] [<804da704>] (udc_irq) from [<804d64f8>] (ci_irq+0x5c/0x118)
[   40.645702]  r10:80bb5619 r9:be11e000 r8:0117 r7: r6:bdb71010 
r5:be11e060
[   40.653666]  r4:bdb70010
[   40.656261] [<804d649c>] (ci_irq) from [<8007f638>] 
(handle_irq_event_percpu+0x7c/0x13c)
[   40.664367]  r6: r5:be11e060 r4:bdb05cc0 r3:804d649c
[   40.670149] [<8007f5bc>] (handle_irq_event_percpu) from [<8007f740>] 
(handle_irq_event+0x48/0x6c)
[   40.679036]  r10: r9:be008000 r8:0001 r7: r6:bdb05cc0 
r5:be11e060
[   40.686998]  r4:be11e000
[   40.689581] [<8007f6f8>] (handle_irq_event) from [<80082850>] 
(handle_fasteoi_irq+0xd4/0x1b0)
[   40.698120]  r6:80b56a30 r5:be11e060 r4:be11e000 r3:
[   40.703898] [<8008277c>] (handle_fasteoi_irq) from [<8007ec04>] 
(generic_handle_irq+0x28/0x3c)
[   40.712524]  r7: r6:80b4aaf4 r5:0117 r4:80b445fc
[   40.718304] [<8007ebdc>] (generic_handle_irq) from [<8007ef20>] 
(__handle_domain_irq+0x6c/0xe8)
[   40.727033] [<8007eeb4>] (__handle_domain_irq) from [<800095d4>] 
(gic_handle_irq+0x48/0x94)
[   40.735402]  r9:c080f100 r8:80b4ac6c r7:c080e100 r6:80b67d40 r5:80b49f00 
r4:c080e10c
[   40.743290] [<8000958c>] (gic_handle_irq) from [<80015d38>] 
(__irq_svc+0x58/0x78)
[   40.750791] Exception stack(0x80b49f00 to 0x80b49f48)
[   40.755873] 9f00: 0001 0001  80024320 80b48000 80b4a9d0 
80b4a984 80b433e4
[   40.764078] 9f20: 0001 807f4680  80b49f5c 80b49f20 80b49f50 
80071ca4 800113fc
[   40.772272] 9f40: 200b0013 
[   40.775776]  r9:807f4680 r8:0001 r7:80b49f34 r6: r5:200b0013 
r4:800113fc
[   40.783677] [<800113d4>] (arch_cpu_idle) from [<8006c5bc>] 
(default_idle_call+0x28/0x38)
[   40.791798] [<8006c594>] (default_idle_call) from [<8006c6dc>] 
(cpu_startup_entry+0x110/0x1b0)
[   40.800445] [<8006c5cc>] (cpu_startup_entry) from [<807e95dc>] 
(rest_init+0x12c/0x168)
[   40.808376]  r7:80b4a8c0 r3:807f4b7c
[   40.812030] [<807e94b0>] (rest_init) from [<80ad7cc0>] 
(start_kernel+0x360/0x3d4)
[   40.819528]  r5:80bcb000 r4:80bcb050
[   40.823171] [<80ad7960>] (start_kernel) from [<8000807c>] (0x8000807c)

It fixes commit 91c42b0da8e3 ("usb: gadget: loopback: Fix looping back
logic implementation").

Signed-off-by: Peter Chen 
Cc: Krzysztof Opasiak 
Cc: 


how is this stable material ? this commit was added to v4.4. merge
window. Applying without stable tag.



Peter added stable tag because my commit 91c

RE: [PATCH] USB: DCW3: GADGET: Set Correct Max Speed

[Felipe Balbi]

Hi,

"McCauley, Ben"  writes:



>> Ben, can you respin your patch to also add the comment explaining the
>> situation so we don't loose track of it ? Then I can apply once -rc1 is out.
>>
>> thanks
>>
>> --
>> Balbi
>
> The max speed was always being set to USB_SUPER_SPEED
> even when the phy was only capable of HIGH_SPEED. This
> uses the value set for the phy to set the max for the
> gadget. It resolves an issue with Window PCs where they
> report that using a USB3.0 port would result in better
> performance even when connecting through a 3.0 port. A
> follow on patch will be needed to add USB_SPEED_HIGH_LPM
> to support High Speed devices which also support LPM.
>
> Signed-off-by: McCauley, Ben 

if I were to apply this patch, all of those hundreds of lines of context
in the email would go into the git log. This is not how you send a patch.

> diff --git a/drivers/usb/dwc3/gadget.c b/drivers/usb/dwc3/gadget.c
> index 1eaf31c..342be2f 100644
> --- a/drivers/usb/dwc3/gadget.c
> +++ b/drivers/usb/dwc3/gadget.c
> @@ -2899,7 +2899,15 @@
> }
>
> dwc->gadget.ops = &dwc3_gadget_ops;
> -   dwc->gadget.max_speed   = USB_SPEED_SUPER;
> +   /*
> +* FIXME A new enumeration USB_SPEED_HIGH_LPM needs to be added
> +* to support USB 2.10. Setting max_speed to dwc->maximum_speed
> +* disables LPM support for devices which do not support
> +* SuperSpeed but are LPM capable.
> +*/
> +   if (dwc->maximum_speed < USB_SPEED_SUPER)
> +   dev_info(dwc->dev, "SuperSpeed not supported.\n");
> +   dwc->gadget.max_speed   = dwc->maximum_speed;
> dwc->gadget.speed   = USB_SPEED_UNKNOWN;
> dwc->gadget.sg_supported= true;
> dwc->gadget.name= "dwc3-gadget"
>
> 
>
> CONFIDENTIALITY NOTICE: This email and any attachments are for the
> sole use of the intended recipient(s) and contain information that may
> be confidential and/or legally privileged. If you have received this
> email in error, please notify the sender by reply email and delete the
> message. Any disclosure, copying, distribution or use of this
> communication (including attachments) by someone other than the
> intended recipient is prohibited. Thank you.

this note, as I have said before, should not be in your email anymore,
much less in git's history. I'll all of these while applying, but it's
the only time; next time, sorry, I'll have to ignore your patch until
you manage to get it done correct.

regards

-- 
balbi


signature.asc
Description: PGP signature

Re: [PATCH v2] usb: musb: fix tx fifo flush handling

[Felipe Balbi]

Hi,

Sergei Shtylyov  writes:
> Hello.
>
> On 11/06/2015 12:44 AM, Felipe Balbi wrote:
>
>>> Here are a few changes in musb_h_tx_flush_fifo().
>>>
>>> - Refering to 2ccc6d30a (usb: musb: fix bit mask for CSR in
>>>  musb_h_tx_flush_fifo()), the datasheet says that
>>> MUSB_TXCSR_FLUSHFIFO
>>>  is only valid when MUSB_TXCSR_TXPKTRDY is set as well. It means
>>>  MUSB_TXCSR_TXPKTRDY should be checked, not set.
>>
>>   Hum, my copy of the MUSBHDRC  programmer's guide says about
>> TXCSR.FlushFIFO in host mode:
>>
>> <<
>> The CPU writes a 1 to this bit to flush the latest packet from the
>> endpoint Tx FIFO. The FIFO pointer is reset, the TxPktRdy bit 
>> (below) is
>> cleared and an interrupt is generated. May be set simultaneously with
>> TxPktRdy to abort the packet that is currently being loaded into the
>> FIFO. Note: FlushFIFO should only be used when TxPktRdy is set. At 
>> other
>> times, it may cause data to be corrupted. Also note that, if the 
>> FIFO is
>> double-buffered, FlushFIFO may need to be set twice to completely 
>> clear
>> the FIFO.
>>>>
>
> So how to interpret this message? FLUSHFIFO and TXPKTRDY should be set
> at the
> same time? If so, I will drop this change in V3.

   Yes, I think it's rather clear in this respect.

> In either case, musb is unable to flush the tx fifo in urb dequque for
> device
> disconnect, but harmless, so the next two changes are important to
> give better
> user experience.

   Hm, looks like some errata... and hiding this from users while
 there's no workaround doesn't seem a good policy.
>>>
>>> Well, based on the programmer's guide, the driver should set the 
>>> flushFIFO
>>> bit, and wait for the interrupt.
>>
>>   That's oversimplified, consider the double-buffered FIFO. ;-)
>
> Seems like we have some misinterpretation here and IMO Bin's patch is
> almost complete. The way I read MUSB's docs, it tells me three different
> things:
>
> 1. FIFONOTEMPTY is valid *only* when TXPKTRDY is also set
>
>   Bin's new while condition solves this part:
>
> + while ((csr & MUSB_TXCSR_FIFONOTEMPTY) && (csr & 
> MUSB_TXCSR_TXPKTRDY)) {
>
> 2. If we have Double Buffering, we need to set MUSB_TXCSR_FLUSHFIFO
> twice.
>
>   This does not seem to be taken care of, but it would be
>   something below:
>
> csr |= MUSB_TXCSR_FLUSH_FIFO;
> musb_writew(epio, MUSB_TXCSR, csr);
>
> if (ep->double_buffering_enabled)
>   musb_write(epio, MUSB_TXCSR, csr);
>
> 3. We can set TXPKTRDY *together* with MUSB_TXCSR_FLUSH_FIFO to cancel
> the packet which is being loaded in the fifo right now.
>
>   This seems to be a regression with current patch, however I
>   don't think current code is perfect either. It unconditionally
>   sets FLUSH_FIFO and TXPKTRDY without caring for the consequences
>   of doing that. What happens if we set both of them but there's
>   no packet being currently loaded into the FIFO ?
>
> To minimize changes, I think Bin just needs to keep the original csr
> unconditionally setting both FLUSHFIFO and TXPKTRDY alone while also
> making sure to check that TKPKTRDY is set when checking FIFONOTEMPTY.
>
>>> I am not sure this is any different, since TXPKTRDY is checked, setting
>>> it again along with FLUSHFIFO does not change TXPKTRDY bit, isn't it?
>>
>> you're missing one detail:
>>
>> If you set only FLUSHFIFO, TXPKTRDY is cleared and the packet *already*
>> in the FIFO gets flushed.
>
> That's exactly what we want, no? Note that the CPU cannot clear the 
> TxPktRdy bit, only MUSB itself can.
>
>> If you set them both together, you're telling MUSB that you want to
>> flush a packet which is *still* being loaded into the FIFO. After that
>> TXPKTRDY will be cleared by MUSB.
>
> This is not really different from the first case.

not for single buffering, not. If you use double buffering, it is very
different.

>>> I have a few different test cases, as long as a tx urb is queued, the
>>> WARN() will be triggered when dequque called by device disconnect, that
>>> is why I concluded that currently musb is never able to flush tx fifo.
>>>
>>> If we are doing it wrong, I am not what the problem is...
>>
>> And that's where debugging comes in, right ? MUSB's docs are not the
>> best out there and they haven't been updated for 8 years at least. There
>> will be points where it's lacking and we just have to deal with it and
>> figure out what the IP is actually doing.
>
> BTW, about MUSB docs. I have encountered the issue with the SendStall bit 
>

Re: [PATCH 1/1] usb: gadget: f_loopback: fix the warning during the enumeration

[Felipe Balbi]

Hi,

Peter Chen  writes:
> The current code tries to allocate memory with GFP_KERNEL at
> interrupt context, it would show below warning during the enumeration
> when I test it with chipidea hardware, change GFP flag as GFP_ATOMIC
> can fix this issue.
>
> [   40.438237] zero gadget: high-speed config #2: loopback
> [   40.444924] [ cut here ]
> [   40.449609] WARNING: CPU: 0 PID: 0 at kernel/locking/lockdep.c:2755 
> lockdep_trace_alloc+0x108/0x128()
> [   40.461715] DEBUG_LOCKS_WARN_ON(irqs_disabled_flags(flags))
> [   40.467130] Modules linked in:
> [   40.470216]  usb_f_ss_lb g_zero libcomposite evbug
> [   40.473822] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 
> 4.3.0-rc5-00168-gb730aaf #604
> [   40.481496] Hardware name: Freescale i.MX6 SoloX (Device Tree)
> [   40.487345] Backtrace:
> [   40.489857] [<80014e94>] (dump_backtrace) from [<80015088>] 
> (show_stack+0x18/0x1c)
> [   40.497445]  r6:80b67a80 r5: r4: r3:
> [   40.503234] [<80015070>] (show_stack) from [<802e27b4>] 
> (dump_stack+0x8c/0xa4)
> [   40.510503] [<802e2728>] (dump_stack) from [<8002cfe8>] 
> (warn_slowpath_common+0x80/0xbc)
> [   40.518612]  r6:8007510c r5:0009 r4:80b49c88 r3:0001
> [   40.524396] [<8002cf68>] (warn_slowpath_common) from [<8002d05c>] 
> (warn_slowpath_fmt+0x38/0x40)
> [   40.533109]  r8:bcfdef80 r7:bdb705cc r6:80d0 r5:be001e80 r4:809cc278
> [   40.539965] [<8002d028>] (warn_slowpath_fmt) from [<8007510c>] 
> (lockdep_trace_alloc+0x108/0x128)
> [   40.548766]  r3:809d0128 r2:809cc278
> [   40.552401]  r4:600b0193
> [   40.554990] [<80075004>] (lockdep_trace_alloc) from [<801093d4>] 
> (kmem_cache_alloc+0x28/0x15c)
> [   40.563618]  r4:80d0 r3:80b4aa8c
> [   40.567270] [<801093ac>] (kmem_cache_alloc) from [<804d95e4>] 
> (ep_alloc_request+0x58/0x68)
> [   40.575550]  r10:7f01f104 r9:0001 r8:bcfdef80 r7:bdb705cc r6:bc178700 
> r5:
> [   40.583512]  r4:bcfdef80 r3:813c0a38
> [   40.587183] [<804d958c>] (ep_alloc_request) from [<7f01f7ec>] 
> (loopback_set_alt+0x114/0x21c [usb_f_ss_lb])
> [   40.596929] [<7f01f6d8>] (loopback_set_alt [usb_f_ss_lb]) from 
> [<7f006910>] (composite_setup+0xbd0/0x17e8 [libcomposite])
> [   40.607902]  r10:bd3a2c0c r9: r8:bcfdef80 r7:bc178700 r6:bdb702d0 
> r5:bcfdefdc
> [   40.615866]  r4:7f0199b4 r3:0002
> [   40.619542] [<7f005d40>] (composite_setup [libcomposite]) from 
> [<804dae88>] (udc_irq+0x784/0xd1c)
> [   40.628431]  r10:80bb5619 r9:c0876140 r8:00012001 r7:bdb71010 r6:bdb70568 
> r5:00010001
> [   40.636392]  r4:bdb70014
> [   40.638985] [<804da704>] (udc_irq) from [<804d64f8>] (ci_irq+0x5c/0x118)
> [   40.645702]  r10:80bb5619 r9:be11e000 r8:0117 r7: r6:bdb71010 
> r5:be11e060
> [   40.653666]  r4:bdb70010
> [   40.656261] [<804d649c>] (ci_irq) from [<8007f638>] 
> (handle_irq_event_percpu+0x7c/0x13c)
> [   40.664367]  r6: r5:be11e060 r4:bdb05cc0 r3:804d649c
> [   40.670149] [<8007f5bc>] (handle_irq_event_percpu) from [<8007f740>] 
> (handle_irq_event+0x48/0x6c)
> [   40.679036]  r10: r9:be008000 r8:0001 r7: r6:bdb05cc0 
> r5:be11e060
> [   40.686998]  r4:be11e000
> [   40.689581] [<8007f6f8>] (handle_irq_event) from [<80082850>] 
> (handle_fasteoi_irq+0xd4/0x1b0)
> [   40.698120]  r6:80b56a30 r5:be11e060 r4:be11e000 r3:
> [   40.703898] [<8008277c>] (handle_fasteoi_irq) from [<8007ec04>] 
> (generic_handle_irq+0x28/0x3c)
> [   40.712524]  r7: r6:80b4aaf4 r5:0117 r4:80b445fc
> [   40.718304] [<8007ebdc>] (generic_handle_irq) from [<8007ef20>] 
> (__handle_domain_irq+0x6c/0xe8)
> [   40.727033] [<8007eeb4>] (__handle_domain_irq) from [<800095d4>] 
> (gic_handle_irq+0x48/0x94)
> [   40.735402]  r9:c080f100 r8:80b4ac6c r7:c080e100 r6:80b67d40 r5:80b49f00 
> r4:c080e10c
> [   40.743290] [<8000958c>] (gic_handle_irq) from [<80015d38>] 
> (__irq_svc+0x58/0x78)
> [   40.750791] Exception stack(0x80b49f00 to 0x80b49f48)
> [   40.755873] 9f00: 0001 0001  80024320 80b48000 80b4a9d0 
> 80b4a984 80b433e4
> [   40.764078] 9f20: 0001 807f4680  80b49f5c 80b49f20 80b49f50 
> 80071ca4 800113fc
> [   40.772272] 9f40: 200b0013 
> [   40.775776]  r9:807f4680 r8:0001 r7:80b49f34 r6: r5:200b0013 
> r4:800113fc
> [   40.783677] [<800113d4>] (arch_cpu_idle) from [<8006c5bc>] 
> (default_idle_call+0x28/0x38)
> [   40.791798] [<8006c594>] (default_idle_call) from [<8006c6dc>] 
> (cpu_startup_entry+0x110/0x1b0)
> [   40.800445] [<8006c5cc>] (cpu_startup_entry) from [<807e95dc>] 
> (rest_init+0x12c/0x168)
> [   40.808376]  r7:80b4a8c0 r3:807f4b7c
> [   40.812030] [<807e94b0>] (rest_init) from [<80ad7cc0>] 
> (start_kernel+0x360/0x3d4)
> [   40.819528]  r5:80bcb000 r4:80bcb050
> [   40.823171] [<80ad7960>] (start_kernel) from [<8000807c>] (0x8000807c)
>
> It fixes commit 91c42b0da8e3 ("usb: gadget: loopback: Fix looping back
> logic implementation").
>
> Signed-off-by: Peter Chen 
> Cc: Krzysztof Opasiak 
> Cc: 

Re: [PATCH v2 2/2] usb: dwc2: host: Clear interrupts before handling them

[Felipe Balbi]

Hi,

Douglas Anderson  writes:
> In general it is wise to clear interrupts before processing them.  If
> you don't do that, you can get:
>  1. Interrupt happens
>  2. You look at system state and process interrupt
>  3. A new interrupt happens
>  4. You clear interrupt without processing it.
>
> This patch was actually a first attempt to fix missing device insertions
> as described in (usb: dwc2: host: Fix missing device insertions) and it
> did solve some of the signal bouncing problems but not all of
> them (which is why I submitted the other patch).  Specifically, this
> patch itself would sometimes change:
>  1. hardware sees connect
>  2. hardware sees disconnect
>  3. hardware sees connect
>  4. dwc2_port_intr() - clears connect interrupt
>  5. dwc2_handle_common_intr() - calls dwc2_hcd_disconnect()
>
> ...to:
>  1. hardware sees connect
>  2. hardware sees disconnect
>  3. dwc2_port_intr() - clears connect interrupt
>  4. hardware sees connect
>  5. dwc2_handle_common_intr() - calls dwc2_hcd_disconnect()
>
> ...but with different timing then sometimes we'd still miss cable
> insertions.
>
> In any case, though this patch doesn't fix any (known) problems, it
> still seems wise as a general policy to clear interrupt before handling
> them.
>
> Signed-off-by: Douglas Anderson 
> ---
> Changes in v2: None
>
>  drivers/usb/dwc2/core_intr.c | 55 
> ++--
>  drivers/usb/dwc2/hcd_intr.c  | 16 ++---
>  2 files changed, 35 insertions(+), 36 deletions(-)
>
> diff --git a/drivers/usb/dwc2/core_intr.c b/drivers/usb/dwc2/core_intr.c
> index 61601d16e233..2a166b7eec41 100644
> --- a/drivers/usb/dwc2/core_intr.c
> +++ b/drivers/usb/dwc2/core_intr.c
> @@ -80,15 +80,16 @@ static const char *dwc2_op_state_str(struct dwc2_hsotg 
> *hsotg)
>   */
>  static void dwc2_handle_usb_port_intr(struct dwc2_hsotg *hsotg)
>  {
> - u32 hprt0 = dwc2_readl(hsotg->regs + HPRT0);
> + u32 hprt0;
>  
> + /* Clear interrupt */
> + dwc2_writel(GINTSTS_PRTINT, hsotg->regs + GINTSTS);
> +
> + hprt0 = dwc2_readl(hsotg->regs + HPRT0);
>   if (hprt0 & HPRT0_ENACHG) {
>   hprt0 &= ~HPRT0_ENA;
>   dwc2_writel(hprt0, hsotg->regs + HPRT0);
>   }
> -
> - /* Clear interrupt */
> - dwc2_writel(GINTSTS_PRTINT, hsotg->regs + GINTSTS);

isn't this a regression ? You're first clearing the interrupts and only
then reading to check what's pending, however, what's pending has just
been cleared. Seems like this should be:

hprt0 = dwc2_readl(HPRT0);
dwc2_writeal(PRTINT, GINTSTS);


Also, these two patches look very large for the -rc. I'll move them to
v4.5 merge window unless you can convince me that they are, indeed, the
smallest change possible to fix the problem you're facing and that they
are, indeed, regressions.

-- 
balbi


signature.asc
Description: PGP signature

Re: [PATCH v6 4/4] power: wm831x_power: Support USB charger current limit management

[kbuild test robot]

Hi Baolin,

[auto build test ERROR on balbi-usb/next]
[also build test ERROR on v4.4-rc1 next-20151116]

url:
https://github.com/0day-ci/linux/commits/Baolin-Wang/Introduce-usb-charger-framework-to-deal-with-the-usb-gadget-power-negotation/20151116-143734
base:   https://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb.git next
config: arm-allmodconfig (attached as .config)
reproduce:
wget 
https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross
 -O ~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=arm 

All errors (new ones prefixed by >>):

   ERROR: "usb_charger_init" [drivers/usb/gadget/udc/udc-core.ko] undefined!
   ERROR: "usb_charger_plug_by_gadget" [drivers/usb/gadget/udc/udc-core.ko] 
undefined!
   ERROR: "usb_charger_exit" [drivers/usb/gadget/udc/udc-core.ko] undefined!
   ERROR: "usb_charger_set_cur_limit_by_type" 
[drivers/usb/gadget/libcomposite.ko] undefined!
   ERROR: "usb_charger_set_cur_limit_by_type" 
[drivers/usb/gadget/legacy/gadgetfs.ko] undefined!
>> ERROR: "usb_charger_register_notify" [drivers/power/wm831x_power.ko] 
>> undefined!
>> ERROR: "usb_charger_find_by_name" [drivers/power/wm831x_power.ko] undefined!
>> ERROR: "usb_charger_unregister_notify" [drivers/power/wm831x_power.ko] 
>> undefined!

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation


.config.gz
Description: Binary data

Re: [RFC PATCH] usb: gadget: Introduce Cadence USB2 UDC Driver

[Felipe Balbi]

Hi,

Neil Armstrong  writes:
> Introduces UDC support for the Device-Mode only version of the
> Cadence USB2 Controller IP Core.
>
> Host mode and OTG mode are not implemented by lack of hardware.
> Support for Isochronous endpoints is not implemented by lack of time.
>
> Internal DMA is supported and can be activated by DT property.
>
> Signed-off-by: Neil Armstrong 

looks like there are a few checkpatch warnings to be fixed:

WARNING: added, moved or deleted file(s), does MAINTAINERS need updating?
#89: 
new file mode 100644

WARNING: 'tranfer' may be misspelled - perhaps 'transfer'?
#233: FILE: drivers/usb/gadget/udc/cadence_hsudc.c:44:
+ *  - EP Bulk and Interrupt tranfer

WARNING: Avoid crashing the kernel - try using WARN_ON & recovery code rather 
than BUG() or BUG_ON()
#968: FILE: drivers/usb/gadget/udc/cadence_hsudc.c:779:
+   BUG();

WARNING: Avoid crashing the kernel - try using WARN_ON & recovery code rather 
than BUG() or BUG_ON()
#1492: FILE: drivers/usb/gadget/udc/cadence_hsudc.c:1303:
+   BUG();

WARNING: DT compatible string "cdns,usbhs-udc" appears un-documented -- check 
workspace/linux/Documentation/devicetree/bindings/
#1882: FILE: drivers/usb/gadget/udc/cadence_hsudc.c:1693:
+   { .compatible = "cdns,usbhs-udc" },

WARNING: 'tranfer' may be misspelled - perhaps 'transfer'?
#2603: FILE: drivers/usb/gadget/udc/cadence_hsudc_regs.h:272:
+#define HSUDC_DMA_BUSCTRL_HSIZE_8BIT   (0 << 1) /* 8-bit data tranfer */

WARNING: 'tranfer' may be misspelled - perhaps 'transfer'?
#2604: FILE: drivers/usb/gadget/udc/cadence_hsudc_regs.h:273:
+#define HSUDC_DMA_BUSCTRL_HSIZE_16BIT  (1 << 1) /* 16-bit data tranfer */

WARNING: 'tranfer' may be misspelled - perhaps 'transfer'?
#2605: FILE: drivers/usb/gadget/udc/cadence_hsudc_regs.h:274:
+#define HSUDC_DMA_BUSCTRL_HSIZE_32BIT  (2 << 1) /* 32-bit data tranfer */

WARNING: 'tranfer' may be misspelled - perhaps 'transfer'?
#2607: FILE: drivers/usb/gadget/udc/cadence_hsudc_regs.h:276:
+#define HSUDC_DMA_BUSCTRL_BURST_SINGLE (0 << 4) /* Single tranfer */

total: 0 errors, 9 warnings, 2499 lines checked

Your patch has style problems, please review.

NOTE: If any of the errors are false positives, please report
  them to the maintainer, see CHECKPATCH in MAINTAINERS.

-- 
balbi


signature.asc
Description: PGP signature

Re: [linux-sunxi] Re: [PATCH 2/2] ehci-platform: Add support for controllers with multiple reset lines

[Chen-Yu Tsai]

On Mon, Nov 16, 2015 at 11:42 PM, Alan Stern  wrote:
> On Sun, 15 Nov 2015, Hans de Goede wrote:
>
>> From: Reinder de Haan 
>>
>> At least the EHCI found on the Allwinnner H3 SoC needs multiple reset
>> lines, the controller will not initialize while the reset for its
>> companion OHCI is still asserted, which means we need to de-assert
>> 2 reset-controllers for this EHCI controller to work.
>
> I assume that reset_control_deassert() is smart enough to maintain a
> count of de-assertions, and it doesn't actually turn on the reset line
> until the count drops to 0.  Right?

No it doesn't. That might be a problem when 2 devices (such as EHCI / OHCI
pairs) share a reset line, one probes successfully while the other doesn't.
Hans?

>> Signed-off-by: Reinder de Haan 
>> Signed-off-by: Hans de Goede 
>
> ...
>
>> @@ -229,18 +230,24 @@ static int ehci_platform_probe(struct platform_device 
>> *dev)
>>   break;
>>   }
>>   }
>> - }
>>
>> - priv->rst = devm_reset_control_get_optional(&dev->dev, NULL);
>> - if (IS_ERR(priv->rst)) {
>> - err = PTR_ERR(priv->rst);
>> - if (err == -EPROBE_DEFER)
>> - goto err_put_clks;
>> - priv->rst = NULL;
>> - } else {
>> - err = reset_control_deassert(priv->rst);
>> - if (err)
>> - goto err_put_clks;
>> + for (rst = 0; rst < EHCI_MAX_RESETS; rst++) {
>
> What happens on platforms that don't use OF?  Or if pdata is not equal
> to &ehci_platform_defaults?  Can you guarantee that those platforms
> will never need to turn off a reset line?

The reset control framework is OF / DT only at the moment.

Regards
ChenYu

>> + priv->resets[rst] =
>> + of_reset_control_get_by_index(dev->dev.of_node,
>> +   rst);
>
> The style used in this file is to indent continuation lines to 2 two
> stops, not to line things up with an open paren on the previous line.
>
> The rest of the patch looks okay.
>
> 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: musb: enable usb_dma parameter

[Bin Liu]

Hi,

On 11/13/2015 06:57 PM, Greg KH wrote:

On Fri, Nov 13, 2015 at 03:45:24PM -0600, Bin Liu wrote:

Change the permission of usb_dma parameter so it can be used for runtime
debug without reboot.


Why would you want to do that?  This is only used at init time, so if
you change it while the driver is running, I don't think you will
actually affect anything.


During debug, I want to run with CPPI enabled or disabled without reboot 
the board to load different kernel image.


With this patch, I can archive this by

- unbind musb_hdrc
- change usb_dma param
- bind musb_hdrc



Have you tested this out?


Yes, I did and it works for me.

Regards,
-Bin.



thanks,

greg k-h


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

Re: [PATCH v2] usb: host: ohci-pxa27x: use of_property_read_bool()

[Alan Stern]

On Mon, 16 Nov 2015, Saurabh Sengar wrote:

> for checking if a property is present or not,
> of_property_read_bool is more appropriate than of_get_property()
> 
> Signed-off-by: Saurabh Sengar 
> ---
> v2 : replaced then to than in description

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 2/2] ehci-platform: Add support for controllers with multiple reset lines

[Alan Stern]

On Sun, 15 Nov 2015, Hans de Goede wrote:

> From: Reinder de Haan 
> 
> At least the EHCI found on the Allwinnner H3 SoC needs multiple reset
> lines, the controller will not initialize while the reset for its
> companion OHCI is still asserted, which means we need to de-assert
> 2 reset-controllers for this EHCI controller to work.

I assume that reset_control_deassert() is smart enough to maintain a 
count of de-assertions, and it doesn't actually turn on the reset line 
until the count drops to 0.  Right?

> Signed-off-by: Reinder de Haan 
> Signed-off-by: Hans de Goede 

...

> @@ -229,18 +230,24 @@ static int ehci_platform_probe(struct platform_device 
> *dev)
>   break;
>   }
>   }
> - }
>  
> - priv->rst = devm_reset_control_get_optional(&dev->dev, NULL);
> - if (IS_ERR(priv->rst)) {
> - err = PTR_ERR(priv->rst);
> - if (err == -EPROBE_DEFER)
> - goto err_put_clks;
> - priv->rst = NULL;
> - } else {
> - err = reset_control_deassert(priv->rst);
> - if (err)
> - goto err_put_clks;
> + for (rst = 0; rst < EHCI_MAX_RESETS; rst++) {

What happens on platforms that don't use OF?  Or if pdata is not equal
to &ehci_platform_defaults?  Can you guarantee that those platforms 
will never need to turn off a reset line?

> + priv->resets[rst] =
> + of_reset_control_get_by_index(dev->dev.of_node,
> +   rst);

The style used in this file is to indent continuation lines to 2 two 
stops, not to line things up with an open paren on the previous line.

The rest of the patch looks okay.

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 1/5] clk: sunxi: Add support for the H3 usb phy clocks

[Rob Herring]

On Sun, Nov 15, 2015 at 08:46:13PM +0100, Hans de Goede wrote:
> From: Reinder de Haan 
> 
> The H3 has a usb-phy clk register which is similar to that of earlier
> SoCs, but with support for a larger number of phys. So we can simply add
> a new set of clk-data and a new compatible and be done with it.
> 
> Signed-off-by: Reinder de Haan 
> Signed-off-by: Hans de Goede 

Acked-by: Rob Herring 

> ---
>  Documentation/devicetree/bindings/clock/sunxi.txt |  1 +
>  drivers/clk/sunxi/clk-usb.c   | 12 
>  2 files changed, 13 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/clock/sunxi.txt 
> b/Documentation/devicetree/bindings/clock/sunxi.txt
> index d303dec..23e7bce 100644
> --- a/Documentation/devicetree/bindings/clock/sunxi.txt
> +++ b/Documentation/devicetree/bindings/clock/sunxi.txt
> @@ -70,6 +70,7 @@ Required properties:
>   "allwinner,sun5i-a13-usb-clk" - for usb gates + resets on A13
>   "allwinner,sun6i-a31-usb-clk" - for usb gates + resets on A31
>   "allwinner,sun8i-a23-usb-clk" - for usb gates + resets on A23
> + "allwinner,sun8i-h3-usb-clk" - for usb gates + resets on H3
>   "allwinner,sun9i-a80-usb-mod-clk" - for usb gates + resets on A80
>   "allwinner,sun9i-a80-usb-phy-clk" - for usb phy gates + resets on A80
>  
> diff --git a/drivers/clk/sunxi/clk-usb.c b/drivers/clk/sunxi/clk-usb.c
> index 1a72cd6..67b8e38 100644
> --- a/drivers/clk/sunxi/clk-usb.c
> +++ b/drivers/clk/sunxi/clk-usb.c
> @@ -243,3 +243,15 @@ static void __init sun9i_a80_usb_phy_setup(struct 
> device_node *node)
>   sunxi_usb_clk_setup(node, &sun9i_a80_usb_phy_data, &a80_usb_phy_lock);
>  }
>  CLK_OF_DECLARE(sun9i_a80_usb_phy, "allwinner,sun9i-a80-usb-phy-clk", 
> sun9i_a80_usb_phy_setup);
> +
> +static const struct usb_clk_data sun8i_h3_usb_clk_data __initconst = {
> + .clk_mask =  BIT(19) | BIT(18) | BIT(17) | BIT(16) |
> +  BIT(11) | BIT(10) | BIT(9) | BIT(8),
> + .reset_mask = BIT(3) | BIT(2) | BIT(1) | BIT(0),
> +};
> +
> +static void __init sun8i_h3_usb_setup(struct device_node *node)
> +{
> + sunxi_usb_clk_setup(node, &sun8i_h3_usb_clk_data, &sun4i_a10_usb_lock);
> +}
> +CLK_OF_DECLARE(sun8i_h3_usb, "allwinner,sun8i-h3-usb-clk", 
> sun8i_h3_usb_setup);
> -- 
> 2.5.0
> 
> --
> To unsubscribe from this list: send the line "unsubscribe devicetree" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 2/5] phy-sun4i-usb: Add support for the host usb-phys found on the H3 SoC

[Rob Herring]

On Sun, Nov 15, 2015 at 08:46:14PM +0100, Hans de Goede wrote:
> From: Reinder de Haan 
> 
> Note this commit only adds support for phys 1-3, phy 0, the otg phy, is
> not yet (fully) supported after this commit.
> 
> Signed-off-by: Reinder de Haan 
> Signed-off-by: Hans de Goede 
> ---
>  .../devicetree/bindings/phy/sun4i-usb-phy.txt  |  1 +

Acked-by: Rob Herring 

>  drivers/phy/phy-sun4i-usb.c| 67 
> +-
>  2 files changed, 53 insertions(+), 15 deletions(-)
> 
> diff --git a/Documentation/devicetree/bindings/phy/sun4i-usb-phy.txt 
> b/Documentation/devicetree/bindings/phy/sun4i-usb-phy.txt
> index 0cebf74..95736d7 100644
> --- a/Documentation/devicetree/bindings/phy/sun4i-usb-phy.txt
> +++ b/Documentation/devicetree/bindings/phy/sun4i-usb-phy.txt
> @@ -9,6 +9,7 @@ Required properties:
>* allwinner,sun7i-a20-usb-phy
>* allwinner,sun8i-a23-usb-phy
>* allwinner,sun8i-a33-usb-phy
> +  * allwinner,sun8i-h3-usb-phy
>  - reg : a list of offset + length pairs
>  - reg-names :
>* "phy_ctrl"
> diff --git a/drivers/phy/phy-sun4i-usb.c b/drivers/phy/phy-sun4i-usb.c
> index b12964b..17f97ab 100644
> --- a/drivers/phy/phy-sun4i-usb.c
> +++ b/drivers/phy/phy-sun4i-usb.c
> @@ -46,6 +46,9 @@
>  #define REG_PHYBIST  0x08
>  #define REG_PHYTUNE  0x0c
>  #define REG_PHYCTL_A33   0x10
> +#define REG_PHY_UNK_H3   0x20
> +
> +#define REG_PMU_UNK_H3   0x10
>  
>  #define PHYCTL_DATA  BIT(7)
>  
> @@ -79,7 +82,7 @@
>  #define PHY_DISCON_TH_SEL0x2a
>  #define PHY_SQUELCH_DETECT   0x3c
>  
> -#define MAX_PHYS 3
> +#define MAX_PHYS 4
>  
>  /*
>   * Note do not raise the debounce time, we must report Vusb high within 100ms
> @@ -88,12 +91,19 @@
>  #define DEBOUNCE_TIMEmsecs_to_jiffies(50)
>  #define POLL_TIMEmsecs_to_jiffies(250)
>  
> +enum sun4i_usb_phy_type {
> + sun4i_a10_phy,
> + sun8i_a33_phy,
> + sun8i_h3_phy
> +};
> +
>  struct sun4i_usb_phy_data {
> + struct device *dev;
>   void __iomem *base;
>   struct mutex mutex;
>   int num_phys;
>   u32 disc_thresh;
> - bool has_a33_phyctl;
> + enum sun4i_usb_phy_type type;
>   struct sun4i_usb_phy {
>   struct phy *phy;
>   void __iomem *pmu;
> @@ -164,12 +174,18 @@ static void sun4i_usb_phy_write(struct sun4i_usb_phy 
> *phy, u32 addr, u32 data,
>  
>   mutex_lock(&phy_data->mutex);
>  
> - if (phy_data->has_a33_phyctl) {
> + switch (phy_data->type) {
> + case sun4i_a10_phy:
> + phyctl = phy_data->base + REG_PHYCTL_A10;
> + break;
> + case sun8i_a33_phy:
>   phyctl = phy_data->base + REG_PHYCTL_A33;
>   /* A33 needs us to set phyctl to 0 explicitly */
>   writel(0, phyctl);
> - } else {
> - phyctl = phy_data->base + REG_PHYCTL_A10;
> + break;
> + case sun8i_h3_phy:
> + dev_err(phy_data->dev, "H3 usb_phy_write is not supported\n");
> + break;
>   }
>  
>   for (i = 0; i < len; i++) {
> @@ -230,6 +246,7 @@ static int sun4i_usb_phy_init(struct phy *_phy)
>   struct sun4i_usb_phy *phy = phy_get_drvdata(_phy);
>   struct sun4i_usb_phy_data *data = to_sun4i_usb_phy_data(phy);
>   int ret;
> + u32 val;
>  
>   ret = clk_prepare_enable(phy->clk);
>   if (ret)
> @@ -241,15 +258,26 @@ static int sun4i_usb_phy_init(struct phy *_phy)
>   return ret;
>   }
>  
> - /* Enable USB 45 Ohm resistor calibration */
> - if (phy->index == 0)
> - sun4i_usb_phy_write(phy, PHY_RES45_CAL_EN, 0x01, 1);
> + if (data->type == sun8i_h3_phy) {
> + if (phy->index == 0) {
> + val = readl(data->base + REG_PHY_UNK_H3);
> + writel(val & ~1, data->base + REG_PHY_UNK_H3);
> + }
> +
> + val = readl(phy->pmu + REG_PMU_UNK_H3);
> + writel(val & ~2, phy->pmu + REG_PMU_UNK_H3);
> + } else {
> + /* Enable USB 45 Ohm resistor calibration */
> + if (phy->index == 0)
> + sun4i_usb_phy_write(phy, PHY_RES45_CAL_EN, 0x01, 1);
>  
> - /* Adjust PHY's magnitude and rate */
> - sun4i_usb_phy_write(phy, PHY_TX_AMPLITUDE_TUNE, 0x14, 5);
> + /* Adjust PHY's magnitude and rate */
> + sun4i_usb_phy_write(phy, PHY_TX_AMPLITUDE_TUNE, 0x14, 5);
>  
> - /* Disconnect threshold adjustment */
> - sun4i_usb_phy_write(phy, PHY_DISCON_TH_SEL, data->disc_thresh, 2);
> + /* Disconnect threshold adjustment */
> + sun4i_usb_phy_write(phy, PHY_DISCON_TH_SEL,
> + data->disc_thresh, 2);
> + }
>  
>   sun4i_usb_phy_passby(phy, 1);
>  
> @@ -522,11 +550,14 @@ static int sun4i_us

[PATCH] usb: dwc2: hcd: fix periodic transfer schedule sequence

[Yunzhi Li]

When checking dwc2 host channel interrupts, handle qh in
periodic_sched_queued list at first, then we could make sure CSPLIT
packets scheduled in the same order as SSPLIT packets.

Signed-off-by: Yunzhi Li 
---
 drivers/usb/dwc2/hcd_intr.c | 22 ++
 1 file changed, 22 insertions(+)

diff --git a/drivers/usb/dwc2/hcd_intr.c b/drivers/usb/dwc2/hcd_intr.c
index bda0b21..e8e8970 100644
--- a/drivers/usb/dwc2/hcd_intr.c
+++ b/drivers/usb/dwc2/hcd_intr.c
@@ -2115,6 +2115,8 @@ static void dwc2_hc_intr(struct dwc2_hsotg *hsotg)
 {
u32 haint;
int i;
+   int hc_num;
+   struct dwc2_qh *qh, *qh_tmp;
 
haint = dwc2_readl(hsotg->regs + HAINT);
if (dbg_perio()) {
@@ -2123,6 +2125,26 @@ static void dwc2_hc_intr(struct dwc2_hsotg *hsotg)
dev_vdbg(hsotg->dev, "HAINT=%08x\n", haint);
}
 
+   /*
+* According to USB 2.0 spec section 11.18.8, a host must
+* issue complete-split transactions in a microframe for a
+* set of full-/low-speed endpoints in the same relative
+* order as the start-splits were issued in a microframe for.
+* So here we should at first picking up host channels
+* from periodic_sched_queued list and checking if there is
+* any start-split have already finished then schedule
+* complete-split in the same order.
+*/
+   list_for_each_entry_safe(qh, qh_tmp,
+&hsotg->periodic_sched_queued,
+qh_list_entry) {
+   hc_num = qh->channel->hc_num;
+   if (haint & (1 << hc_num)) {
+   dwc2_hc_n_intr(hsotg, hc_num);
+   haint &= ~(1 << hc_num);
+   }
+   }
+
for (i = 0; i < hsotg->core_params->host_channels; i++) {
if (haint & (1 << i))
dwc2_hc_n_intr(hsotg, i);
-- 
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: XHCI, "brain-dead scanner", and microframe rounding

[Alan Stern]

On Sun, 15 Nov 2015, Stéphane Lavergne wrote:

> On Sat, Sep 12, 2015 at 4:08 AM, Hans-Peter Jansen  wrote:
> > With some changes in the 4.0 time frame, AND an update of the epson iscan
> > stuff, I'm happily scanning with my Epson 4490 Photo scanner plugged to a 
> > USB
> > 3.0 port using xsane.
> >
> > Other USB 3.0 issues are currently investigated.
> 
> Thank you for the update.  I updated my Debian amd64 box to kernel
> 4.2.0-0 (Jessie backport) today, re-enabled "Auto" XHCI in my Gigabyte
> BIOS and I can confirm that xhci_usb is handling my Fujitsu ScanSnap
> S1500 correctly now.
> 
> FYI I do get 2 warnings in dmesg and my console every single time Sane
> talks to the device:
> 
> [ 2036.780271] usb 3-12: ep 0x81 - rounding interval to 128
> microframes, ep desc says 255 microframes
> 
> [ 2036.780835] usb 3-12: ep 0x2 - rounding interval to 128
> microframes, ep desc says 255 microframes
> 
> No big deal, just thought I'd let _someone_ out there know. :)

There's no reason for these messages to be warnings.  They don't
indicate that anything is wrong or out of the ordinary.  Probably they
should be debug-level.

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: [4.3] kworker busy in pm_runtime_work

[Alan Stern]

On Mon, 16 Nov 2015, Daniel J Blueman wrote:

> Tuning USB suspend [1] in 4.3 on a Dell XPS 15 9553 (Skylake), I see a
> kworker thread spinning in rpm_suspend [2].
> 
> What is the most useful debug to get here beyond the immediate [3]?

You can try doing:

echo 'module usbcore =p' >/sys/kernel/debug/dynamic_debug/control

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: [Workaround] ASM1153E : ASM 174c:55aa problems re-loaded [quirk needed]

[Hans de Goede]

Hi,

On 13-11-15 20:12, Manfred_Knick wrote:

First of all:
A big "Thank You!" especially to Sarah Sharp and Hans de Goede.
Finding their contributions finally led my way.

Second:
Please, keep me CC'ed on this subject - I am not subscribed to the list above.


HARDWARE involved:
##

- Xeon E3-1276 v3

- Asus P9D WS
- - 00:14.0 USB controller [0c03] :
- - Intel Corporation 8 Series/C220 Series Chipset Family USB xHCI [8086:8c31] 
(rev 05)

- LC-Power "LC-35U3-Becrux"with
- - ASM1153E   soldered onto its adapter board  
<-- <--
- - - 130926 a1 00 00  original firmware version
- - - 140509_A1_82_80.bin  newest firmware update I could gather from
- - -  http://plugable.com/drivers/hddockfirmware

- Seagate Barracuda 7200.11 1.5TB (ST315003 41AS)


Kernel versions involved:
#

- linux-4.1.12-gentoo<-- failure, 
as described below
- linux-4.1.13-gentoo<-- failure

- linux-4.2.6-gentoo <-- failure

- linux-4.3.0-gentoo <-- failure
- linux-4.3.0-gentoo   with   "usb-storage.quirks=174c:55aa:u"   <-- working  
[Workaround]


SHORT STORY:


ASM continues shuffling new HW under the old hat of 174c:55aa.

Connecting the external enclosure, lsusb identifies it as "ASM1051 SATA 3Gb/s 
bridge" -
you need a microscope to finally detect the chip as an ASM1153E instead.


Thanks for checking the exact bridge chip model.


Usage of the device @ USB 2 succeeds.

"Normal" usage of the device @ USB 3 succeeds, but
under stress the connection fails *instantaneusly* .

Adding "usb-storage.quirks=174c:55aa:u" to the kernel start parameters
makes the device fall back from UAS to usb-storage,
but deliver stable full throughput the disc is capable of.


LONG  STORY:


[ 5155.065761] usb 2-6: new SuperSpeed USB device number 2 using xhci_hcd
[ 5155.077463] usb 2-6: New USB device found, idVendor=174c, idProduct=55aa
[ 5155.077467] usb 2-6: New USB device strings: Mfr=2, Product=3, SerialNumber=1
[ 5155.077469] usb 2-6: Product: mkn_LC-53U3-Becrux
[ 5155.077470] usb 2-6: Manufacturer: mkn_LC-POWER
[ 5155.077472] usb 2-6: SerialNumber: 20140156

[ 5155.079306] scsi host7: uas
[ 5155.163597] scsi 7:0:0:0: Direct-Access ST315003 41AS 0
PQ: 0 ANSI: 6

[ 5155.163966] sd 7:0:0:0: Attached scsi generic sg6 type 0
[ 5155.164117] sd 7:0:0:0: [sdd] 2930277168 512-byte logical blocks: (1.50 
TB/1.36 TiB)
[ 5155.164433] sd 7:0:0:0: [sdd] Write Protect is off
[ 5155.164435] sd 7:0:0:0: [sdd] Mode Sense: 43 00 00 00
[ 5155.164553] sd 7:0:0:0: [sdd] Write cache: enabled, read cache: enabled, 
doesn't support DPO or FUA
[ 5155.229663]  sdd: sdd1
[ 5155.230384] sd 7:0:0:0: [sdd] Attached SCSI disk

### Until here, everything is o.k.

### Afterwards, "normal" / "slow" access to the disk works o.k.

### But when stressing the disk (even without mounting a fs, e.g. with "dd"),
### a READ ERROR occurs right away:

[ 7505.098336] sd 7:0:0:0: [sdd] tag#0 data cmplt err -71 uas-tag 1 inflight: 
CMD
[ 7505.098341] sd 7:0:0:0: [sdd] tag#0 CDB: Read(10) 28 00 0e df 25 d0 00 01 00 
00


This indicates a usb-3 signalling error, have you tried replacing the USB-3
cable. Preferably with a high quality usb-3 cable ?


[ 7505.101696] xhci_hcd :00:14.0: ERROR Transfer event for disabled endpoint 
or incorrect stream ring<-- !!!
[ 7505.101708] xhci_hcd :00:14.0: @c6d0   
0400 01038000


This is sorta kinda normal once things have failed (not really, but it happens).


[ 7535.253307] sd 7:0:0:0: [sdd] tag#1 uas_eh_abort_handler 0 uas-tag 2 
inflight: CMD IN
[ 7535.253311] sd 7:0:0:0: [sdd] tag#1 CDB: Read(10) 28 00 0e df 26 d0 00 01 00 
00
[ 7535.253343] sd 7:0:0:0: [sdd] tag#0 uas_eh_abort_handler 0 uas-tag 1 
inflight: CMD
[ 7535.253344] sd 7:0:0:0: [sdd] tag#0 CDB: Read(10) 28 00 0e df 25 d0 00 01 00 
00

[ 7535.253363] scsi host7: uas_eh_bus_reset_handler start
[ 7535.355461] usb 2-6: reset SuperSpeed USB device number 2 using xhci_hcd
[ 7535.367384] scsi host7: uas_eh_bus_reset_handler success

# From now on, the connection to the disk is lost:

[ 7542.276188] sd 7:0:0:0: [sdd] tag#0 FAILED Result: hostbyte=DID_OK 
driverbyte=DRIVER_SENSE
[ 7542.276193] sd 7:0:0:0: [sdd] tag#0 Sense Key : Not Ready [current]
[ 7542.276196] sd 7:0:0:0: [

Re: USB: ti_usb_3410_5052: Add Honeywell HGI80 ID

[Johan Hovold]

On Sat, Nov 14, 2015 at 04:49:30PM +, David Woodhouse wrote:
> The Honeywell HGI80 is a wireless interface to the evohome connected
> thermostat. It uses a TI 3410 USB-serial port.
> 
> Signed-off-by: David Woodhouse 
> Cc: sta...@vger.kernel.org

Applied, 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: [PATCH] USB: serial: option: add support for Novatel MiFi USB620L

[Johan Hovold]

On Wed, Nov 11, 2015 at 07:51:40PM +0100, Aleksander Morgado wrote:
> Also known as Verizon U620L.
> 
> The device is modeswitched from 1410:9020 to 1410:9022 by selecting the 4th 
> USB
> configuration:
> 
>  $ sudo usb_modeswitch –v 0x1410 –p 0x9020 –u 4
> 
> This configuration provides a ECM interface as well as TTYs ('Enterprise Mode'
> according to the U620 Linux integration guide).
> 
> Signed-off-by: Aleksander Morgado 

Applied, 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: [PATCH] USB: qcserial: Add support for Quectel EC20 Mini PCIe module

[Johan Hovold]

On Tue, Nov 03, 2015 at 11:25:28AM +0100, Petr Štetiar wrote:
> It seems like this device has same vendor and product IDs as G2K
> devices, but it has different number of interfaces(4 vs 5) and also
> different interface layout which makes it currently unusable:
> 
>   usbcore: registered new interface driver qcserial
>   usbserial: USB Serial support registered for Qualcomm USB modem
>   usb 2-1.2: unknown number of interfaces: 5
> 
> lsusb output:
> 
>   Bus 002 Device 003: ID 05c6:9215 Qualcomm, Inc. Acer Gobi 2000 Wireless
>   Device Descriptor:
> bLength18
> bDescriptorType 1
> bcdUSB   2.00
> bDeviceClass0 (Defined at Interface level)
> bDeviceSubClass 0
> bDeviceProtocol 0
> bMaxPacketSize064
> idVendor   0x05c6 Qualcomm, Inc.
> idProduct  0x9215 Acer Gobi 2000 Wireless Modem
> bcdDevice2.32
> iManufacturer   1 Quectel
> iProduct2 Quectel LTE Module
> iSerial 0
> bNumConfigurations  1
> Configuration Descriptor:
>   bLength 9
>   bDescriptorType 2
>   wTotalLength  209
>   bNumInterfaces  5
>   bConfigurationValue 1
>   iConfiguration  0
>   bmAttributes 0xa0
> (Bus Powered)
> Remote Wakeup
>   MaxPower  500mA
> 
> Signed-off-by: Petr Štetiar 

Applied for v4.4-rc with stable tag.

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

[PATCH v2] usb: host: ohci-pxa27x: use of_property_read_bool()

[Saurabh Sengar]

for checking if a property is present or not,
of_property_read_bool is more appropriate than of_get_property()

Signed-off-by: Saurabh Sengar 
---
v2 : replaced then to than in description

 drivers/usb/host/ohci-pxa27x.c | 14 +++---
 1 file changed, 7 insertions(+), 7 deletions(-)

diff --git a/drivers/usb/host/ohci-pxa27x.c b/drivers/usb/host/ohci-pxa27x.c
index ba1bec7..e8c006e 100644
--- a/drivers/usb/host/ohci-pxa27x.c
+++ b/drivers/usb/host/ohci-pxa27x.c
@@ -365,19 +365,19 @@ static int ohci_pxa_of_init(struct platform_device *pdev)
if (!pdata)
return -ENOMEM;
 
-   if (of_get_property(np, "marvell,enable-port1", NULL))
+   if (of_property_read_bool(np, "marvell,enable-port1"))
pdata->flags |= ENABLE_PORT1;
-   if (of_get_property(np, "marvell,enable-port2", NULL))
+   if (of_property_read_bool(np, "marvell,enable-port2"))
pdata->flags |= ENABLE_PORT2;
-   if (of_get_property(np, "marvell,enable-port3", NULL))
+   if (of_property_read_bool(np, "marvell,enable-port3"))
pdata->flags |= ENABLE_PORT3;
-   if (of_get_property(np, "marvell,port-sense-low", NULL))
+   if (of_property_read_bool(np, "marvell,port-sense-low"))
pdata->flags |= POWER_SENSE_LOW;
-   if (of_get_property(np, "marvell,power-control-low", NULL))
+   if (of_property_read_bool(np, "marvell,power-control-low"))
pdata->flags |= POWER_CONTROL_LOW;
-   if (of_get_property(np, "marvell,no-oc-protection", NULL))
+   if (of_property_read_bool(np, "marvell,no-oc-protection"))
pdata->flags |= NO_OC_PROTECTION;
-   if (of_get_property(np, "marvell,oc-mode-perport", NULL))
+   if (of_property_read_bool(np, "marvell,oc-mode-perport"))
pdata->flags |= OC_MODE_PERPORT;
if (!of_property_read_u32(np, "marvell,power-on-delay", &tmp))
pdata->power_on_delay = tmp;
-- 
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: Page allocation failure

[Steinar H. Gunderson]

On Mon, Nov 16, 2015 at 01:49:50AM +0100, Steinar H. Gunderson wrote:
> Just so we're on the same page, I cleaned up the patch I'm now using, and I'm
> attaching it here. You said the next step would be changing the memory
> allocation interface; I guess I could give it a shot, but I doubt I would
> understand the subtleties involved.

Cc-ing Markus Rechberger (original patch author), as he wanted to be kept in
the loop. Also:

Signed-off-by: Steinar H. Gunderson 
Signed-off-by: Markus Rechberger 

/* Steinar */
-- 
Homepage: https://www.sesse.net/
--
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