[PATCH v6 1/4] usb: dbc: early driver for xhci debug capability

[Lu Baolu]

xHCI debug capability (DbC) is an optional but standalone
functionality provided by an xHCI host controller. Software
learns this capability by walking through the extended
capability list of the host. xHCI specification describes
DbC in section 7.6.

This patch introduces the code to probe and initialize the
debug capability hardware during early boot. With hardware
initialized, the debug target (system on which this code is
running) will present a debug device through the debug port
(normally the first USB3 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. The DbC functionality is
independent of xHCI host. There isn't any precondition from
xHCI host side for DbC to work.

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

Cc: Mathias Nyman 
Signed-off-by: Lu Baolu 
---
 arch/x86/Kconfig.debug|   17 +
 drivers/usb/Kconfig   |3 +
 drivers/usb/Makefile  |2 +-
 drivers/usb/early/Makefile|1 +
 drivers/usb/early/xhci-dbc.c  | 1027 +
 drivers/usb/early/xhci-dbc.h  |  205 
 include/linux/usb/xhci-dbgp.h |   29 ++
 7 files changed, 1283 insertions(+), 1 deletion(-)
 create mode 100644 drivers/usb/early/xhci-dbc.c
 create mode 100644 drivers/usb/early/xhci-dbc.h
 create mode 100644 include/linux/usb/xhci-dbgp.h

diff --git a/arch/x86/Kconfig.debug b/arch/x86/Kconfig.debug
index 67eec55..ab0178f 100644
--- a/arch/x86/Kconfig.debug
+++ b/arch/x86/Kconfig.debug
@@ -5,6 +5,9 @@ config TRACE_IRQFLAGS_SUPPORT
 
 source "lib/Kconfig.debug"
 
+config EARLY_PRINTK_USB
+   bool
+
 config X86_VERBOSE_BOOTUP
bool "Enable verbose x86 bootup info messages"
default y
@@ -29,6 +32,7 @@ config EARLY_PRINTK
 config EARLY_PRINTK_DBGP
bool "Early printk via EHCI debug port"
depends on EARLY_PRINTK && PCI
+   select EARLY_PRINTK_USB
---help---
  Write kernel log output directly into the EHCI debug port.
 
@@ -48,6 +52,19 @@ 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_USB_XDBC
+   bool "Early printk via xHCI debug port"
+   depends on EARLY_PRINTK && PCI
+   select EARLY_PRINTK_USB
+   ---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/Kconfig b/drivers/usb/Kconfig
index fbe493d..9313fff 100644
--- a/drivers/usb/Kconfig
+++ b/drivers/usb/Kconfig
@@ -19,6 +19,9 @@ config USB_EHCI_BIG_ENDIAN_MMIO
 config USB_EHCI_BIG_ENDIAN_DESC
bool
 
+config USB_EARLY_PRINTK
+   bool
+
 menuconfig USB_SUPPORT
bool "USB support"
depends on HAS_IOMEM
diff --git a/drivers/usb/Makefile b/drivers/usb/Makefile
index 7791af6..53d1356 100644
--- a/drivers/usb/Makefile
+++ b/drivers/usb/Makefile
@@ -49,7 +49,7 @@ obj-$(CONFIG_USB_MICROTEK)+= image/
 obj-$(CONFIG_USB_SERIAL)   += serial/
 
 obj-$(CONFIG_USB)  += misc/
-obj-$(CONFIG_EARLY_PRINTK_DBGP)+= early/
+obj-$(CONFIG_EARLY_PRINTK_USB) += early/
 
 obj-$(CONFIG_USB_ATM)  += atm/
 obj-$(CONFIG_USB_SPEEDTOUCH)   += atm/
diff --git a/drivers/usb/early/Makefile b/drivers/usb/early/Makefile
index 24bbe51..fcde228 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_USB_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..72480c4
--- /dev/null
+++ b/drivers/usb/early/xhci-dbc.c
@@ -0,0 +1,1027 @@
+/**
+ * xhci-dbc.c - xHCI debug capability early driver
+ *
+ * Copyright (C) 2016 Intel Corporation
+ *
+ * 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.
+ */
+
+#define pr_fmt(fmt)KBUILD_MODNAME ":%s: " fmt, __func__
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "../host/xhci.h"
+#include "xhci-dbc.h"
+
+static struct xdbc_state xdbc;

[PATCH v6 3/4] usb: serial: add dbc debug device support to usb_debug

[Lu Baolu]

This patch adds dbc debug device support to the 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[] = {
-   _device, NULL
+   _device, _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 v6 2/4] x86: add support for earlyprintk via USB3 debug port

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

The hardware for USB3 debug port requires DMA memory blocks.
This requires to delay setting up debugging hardware and
registering boot console until the memblocks are filled.

Cc: Ingo Molnar 
Cc: x...@kernel.org
Signed-off-by: Lu Baolu 
---
 Documentation/admin-guide/kernel-parameters.txt | 1 +
 arch/x86/kernel/early_printk.c  | 5 +
 arch/x86/kernel/setup.c | 4 
 3 files changed, 10 insertions(+)

diff --git a/Documentation/admin-guide/kernel-parameters.txt 
b/Documentation/admin-guide/kernel-parameters.txt
index be7c0d9..4bf6138 100644
--- a/Documentation/admin-guide/kernel-parameters.txt
+++ b/Documentation/admin-guide/kernel-parameters.txt
@@ -988,6 +988,7 @@
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 8a12199..0f08403 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 
@@ -381,6 +382,10 @@ static int __init setup_early_printk(char *buf)
if (!strncmp(buf, "efi", 3))
early_console_register(_efi_console, keep);
 #endif
+#ifdef CONFIG_EARLY_PRINTK_USB_XDBC
+   if (!strncmp(buf, "xdbc", 4))
+   early_xdbc_parse_parameter(buf + 4);
+#endif
 
buf++;
}
diff --git a/arch/x86/kernel/setup.c b/arch/x86/kernel/setup.c
index 4cfba94..1f27d91 100644
--- a/arch/x86/kernel/setup.c
+++ b/arch/x86/kernel/setup.c
@@ -70,6 +70,7 @@
 #include 
 #include 
 
+#include 
 #include 
 
 #include 
@@ -1120,6 +1121,9 @@ void __init setup_arch(char **cmdline_p)
memblock_set_current_limit(ISA_END_ADDRESS);
memblock_x86_fill();
 
+   if (!early_xdbc_setup_hardware())
+   early_xdbc_register_console();
+
reserve_bios_regions();
 
if (efi_enabled(EFI_MEMMAP)) {
-- 
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 v6 4/4] usb: doc: add document for USB3 debug port usage

[Lu Baolu]

Add Documentation/usb/usb3-debug-port.rst. This document includes
the user guide for USB3 debug port.

Cc: linux-...@vger.kernel.org
Signed-off-by: Lu Baolu 
---
 Documentation/usb/usb3-debug-port.rst | 98 +++
 1 file changed, 98 insertions(+)
 create mode 100644 Documentation/usb/usb3-debug-port.rst

diff --git a/Documentation/usb/usb3-debug-port.rst 
b/Documentation/usb/usb3-debug-port.rst
new file mode 100644
index 000..9eddb3a
--- /dev/null
+++ b/Documentation/usb/usb3-debug-port.rst
@@ -0,0 +1,98 @@
+===
+USB3 debug port
+===
+
+:Author: Lu Baolu 
+:Date: January 2017
+
+GENERAL
+===
+
+This is a HOWTO for using USB3 debug port on x86 systems.
+
+Before using any kernel debugging functionality based on USB3
+debug port, you need to check 1) whether debug port is supported
+by the xHCI host; 2) which port is used for debugging purposes
+(normally the first USB3 root port). You must have a USB 3.0
+super-speed A-to-A debugging cable to connect the debug target
+with a debug host. In this document, "debug target" stands for
+the system under debugging, and "debug host" stands for a
+stand-alone system that is able to talk to the debugging target
+through the USB3 debug port.
+
+EARLY PRINTK
+
+
+On the debug target system, you need to customize a debugging
+kernel with CONFIG_EARLY_PRINTK_USB_XDBC enabled. And, add
+below kernel boot parameter::
+
+   "earlyprintk=xdbc"
+
+If there are multiple xHCI controllers in the system, you can
+append a host contoller index to this kernel parameter. This
+index starts from 0.
+
+If you are going to use the "keep" option defined by the
+early printk framework to keep the boot console alive after
+early boot, you'd better add below kernel boot parameter::
+
+   "usbcore.autosuspend=-1"
+
+On the debug host side, you don't need to customize the kernel,
+but you'd better disable usb subsystem runtime power management
+by adding below kernel boot parameter::
+
+   "usbcore.autosuspend=-1"
+
+Before starting the debug target, you should connect the debug
+port on the debug target with a root port or port of any external
+hub on the debug host. The cable used to connect these two ports
+should be a USB 3.0 super-speed A-to-A debugging cable.
+
+During early boot of the debug target, DbC (xHCI debug engine for
+USB3 debug port) hardware will be detected and initialized. After
+initialization, the debug host should be able to enumerate the
+debug target as a debug device. The debug host will then bind the
+debug device with the usb_debug driver module and create the
+/dev/ttyUSB0 device.
+
+If the debug device enumeration goes smoothly, you should be able
+to see below kernel messages on the debug host::
+
+   # tail -f /var/log/kern.log
+   [ 1815.983374] usb 4-3: new SuperSpeed USB device number 4 using 
xhci_hcd
+   [ 1815.999595] usb 4-3: LPM exit latency is zeroed, disabling LPM.
+   [ 1815.999899] usb 4-3: New USB device found, idVendor=1d6b, 
idProduct=0004
+   [ 1815.02] usb 4-3: New USB device strings: Mfr=1, Product=2, 
SerialNumber=3
+   [ 1815.03] usb 4-3: Product: Remote GDB
+   [ 1815.04] usb 4-3: Manufacturer: Linux
+   [ 1815.05] usb 4-3: SerialNumber: 0001
+   [ 1816.000240] usb_debug 4-3:1.0: xhci_dbc converter detected
+   [ 1816.000360] usb 4-3: xhci_dbc converter now attached to ttyUSB0
+
+You can run below bash scripts on the debug host to read the kernel
+log sent from debug target.
+
+.. code-block:: sh
+
+   = start of bash scripts =
+   #!/bin/bash
+
+   while true ; do
+   while [ ! -d /sys/class/tty/ttyUSB0 ] ; do
+   :
+   done
+   cat /dev/ttyUSB0 >> xdbc.log
+   done
+   = end of bash scripts ===
+
+You should be able to see the early boot message in xdbc.log.
+
+If it doesn't work, please ask it on the 
+mailing list.
+
+Below USB hosts have been verified to work::
+
+   Intel Corporation Sunrise Point-H USB 3.0 xHCI Controller
+   Intel Corporation Wildcat Point-LP USB xHCI Controller
-- 
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 v6 0/4] usb: early: add support for early printk through USB3 debug port

[Lu Baolu]

xHCI debug capability (DbC) is an optional but standalone
functionality provided by an xHCI host controller. With DbC
hardware initialized, the system will present a debug device
through the USB3 debug port (normally the first USB3 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.
The DbC functionality is independent of xHCI host. There
isn't any precondition from xHCI host side for DbC to work.

This patch set adds support for early printk functionality
through a USB3 debug port by 1) initializing and enabling
the DbC hardware during early boot; 2) registering a boot
console to the system so that early printk messages can go
through the USB3 debug port. It also includes some lines
of changes in usb_debug driver so that it can be bound when
a USB3 debug device is enumerated.

---
Change log:
v5->v6:
  - rebase the patches on top of the latest 4.10-rc4
  - run successfully in a 32-bit kernel
  - [PATCH 1/4]
- remove ugly linebreaks to make code more readable
- rename config names to make them consistency
- move sleep-able ioremap() out of the lock area
- rename reserved fields of register structures
- make the vertical tabulation of struct fields consistent
  - [PATCH 2/4]
- remove "#ifdef" in the generic code by creating proper
  wrappers in header file
  - [PATCH 3/4]
- refine the title and commit message
  - [PATCH 4/4]
- fix several typos and grammar errors in the document

v4->v5:
  - add raw_spin_lock to make xdbc_bulk_write() reentrant.

v3->v4:
  - Rename the document with .dst suffix.
  - Add the list of hardware that has been succesfuly
tested on in the document.

v2->v3:
  - Removed spinlock usage.
  - Removed work queue usage.
  - Refined the user guide document.

v1->v2:
  - Refactor the duplicate code in xdbc_early_start() and
xdbc_handle_external_reset().
  - Free resources when hardware not used any more.
  - Refine the user guide document.

Lu Baolu (4):
  usb: dbc: early driver for xhci debug capability
  x86: add support for earlyprintk via USB3 debug port
  usb: serial: add dbc debug device support to usb_debug
  usb: doc: add document for USB3 debug port usage

 Documentation/admin-guide/kernel-parameters.txt |1 +
 Documentation/usb/usb3-debug-port.rst   |   98 +++
 arch/x86/Kconfig.debug  |   17 +
 arch/x86/kernel/early_printk.c  |5 +
 arch/x86/kernel/setup.c |4 +
 drivers/usb/Kconfig |3 +
 drivers/usb/Makefile|2 +-
 drivers/usb/early/Makefile  |1 +
 drivers/usb/early/xhci-dbc.c| 1027 +++
 drivers/usb/early/xhci-dbc.h|  205 +
 drivers/usb/serial/usb_debug.c  |   28 +-
 include/linux/usb/xhci-dbgp.h   |   29 +
 12 files changed, 1416 insertions(+), 4 deletions(-)
 create mode 100644 Documentation/usb/usb3-debug-port.rst
 create mode 100644 drivers/usb/early/xhci-dbc.c
 create mode 100644 drivers/usb/early/xhci-dbc.h
 create mode 100644 include/linux/usb/xhci-dbgp.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

Re: [RESEND PATCH 6/6] dt-bindings: phy-mt65xx-usb: add support for mt2712 platform

[Chunfeng Yun]

On Sat, 2017-01-21 at 14:08 -0600, Rob Herring wrote:
> On Wed, Jan 18, 2017 at 02:00:14PM +0800, Chunfeng Yun wrote:
> > add a new compatible string for "mt2712", and a new reference clock
> > for SuperSpeed analog phy;
> > 
> > Signed-off-by: Chunfeng Yun 
> > ---
> >  .../devicetree/bindings/phy/phy-mt65xx-usb.txt |   81 
> > +---
> >  1 file changed, 70 insertions(+), 11 deletions(-)
> > 
> > diff --git a/Documentation/devicetree/bindings/phy/phy-mt65xx-usb.txt 
> > b/Documentation/devicetree/bindings/phy/phy-mt65xx-usb.txt
> > index 33a2b1e..8f91136 100644
> > --- a/Documentation/devicetree/bindings/phy/phy-mt65xx-usb.txt
> > +++ b/Documentation/devicetree/bindings/phy/phy-mt65xx-usb.txt
> > @@ -6,19 +6,25 @@ This binding describes a usb3.0 phy for mt65xx platforms 
> > of Medaitek SoC.
> >  Required properties (controller (parent) node):
> >   - compatible  : should be one of
> >   "mediatek,mt2701-u3phy"
> > + "mediatek,mt2712-u3phy"
> >   "mediatek,mt8173-u3phy"
> > - - reg : offset and length of register for phy, exclude port's
> > - register.
> >   - clocks  : a list of phandle + clock-specifier pairs, one for each
> >   entry in clock-names
> >   - clock-names : must contain
> > - "u3phya_ref": for reference clock of usb3.0 analog phy.
> > + "u2ref_clk": 48M reference clock of HighSpeed analog phy.
> > + "u3ref_clk": 26M reference clock of SuperSpeed analog phy,
> > +   sometimes is 24M, 25M or 27M, depended on platform.
> 
> _clk is redundant.
remove it
> 
> >  
> >  Required nodes : a sub-node is required for each port the controller
> >   provides. Address range information including the usual
> >   'reg' property is used inside these nodes to describe
> >   the controller's topology.
> >  
> > +Optional properties (controller (parent) node):
> > + - reg : offset and length of register shared by multiple 
> > ports,
> > + exclude port's private register. It is needed on mt2701
> > + and mt8173, but not on mt2712.
> > +
> >  Required properties (port (child) node):
> >  - reg  : address and length of the register set for the port.
> >  - #phy-cells   : should be 1 (See second example)
> > @@ -31,21 +37,27 @@ Example:
> >  u3phy: usb-phy@1129 {
> > compatible = "mediatek,mt8173-u3phy";
> > reg = <0 0x1129 0 0x800>;
> > -   clocks = < CLK_APMIXED_REF2USB_TX>;
> > -   clock-names = "u3phya_ref";
> > +   clocks = < CLK_APMIXED_REF2USB_TX>, <>;
> > +   clock-names = "u2ref_clk", "u3ref_clk";
> > #address-cells = <2>;
> > #size-cells = <2>;
> > ranges;
> > status = "okay";
> >  
> > -   phy_port0: port@11290800 {
> > -   reg = <0 0x11290800 0 0x800>;
> > +   u2port0: port@11290800 {
> 
> port is for OF graph. This should be usb-phy@... instead.
Is there any problems if u2port0's name@addr is the same as its parent's
(u3phy)?  as following:
u3phy: usb-phy@1129 {
compatible = ...;
// no reg property
clocks = ...;
u2port0: usb-phy@1129 {
reg = ...;
}

> 
> > +   reg = <0 0x11290800 0 0x100>;
> > +   #phy-cells = <1>;
> > +   status = "okay";
> > +   };
> > +
> > +   u3port0: port@11290900 {
> > +   reg = <0 0x11290800 0 0x700>;
> > #phy-cells = <1>;
> > status = "okay";
> > };
> >  

> > +...

Thank you!



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

Re: [PATCH v11 2/8] power: add power sequence library

[Peter Chen]

On Fri, Jan 20, 2017 at 11:21:27AM +0100, Rafael J. Wysocki wrote:
> On Fri, Jan 20, 2017 at 8:52 AM, Peter Chen  wrote:
> > On Tue, Jan 10, 2017 at 03:02:41PM +0800, Peter Chen wrote:
> >> On Sat, Jan 07, 2017 at 10:54:56AM +0200, Krzysztof Kozlowski wrote:
> >> > On Thu, Jan 05, 2017 at 02:01:53PM +0800, Peter Chen wrote:
> >> > > We have an well-known problem that the device needs to do some power
> >> > > sequence before it can be recognized by related host, the typical
> >> > > example like hard-wired mmc devices and usb devices.
> >> > >
> >> > > This power sequence is hard to be described at device tree and handled 
> >> > > by
> >> > > related host driver, so we have created a common power sequence
> >> > > library to cover this requirement. The core code has supplied
> >> > > some common helpers for host driver, and individual power sequence
> >> > > libraries handle kinds of power sequence for devices. The pwrseq
> >> > > librares always need to allocate extra instance for compatible
> >> > > string match.
> >> > >
> >> > > pwrseq_generic is intended for general purpose of power sequence, which
> >> > > handles gpios and clocks currently, and can cover other controls in
> >> > > future. The host driver just needs to call of_pwrseq_on/of_pwrseq_off
> >> > > if only one power sequence is needed, else call of_pwrseq_on_list
> >> > > /of_pwrseq_off_list instead (eg, USB hub driver).
> >> > >
> >> > > For new power sequence library, it can add its compatible string
> >> > > to pwrseq_of_match_table, then the pwrseq core will match it with
> >> > > DT's, and choose this library at runtime.
> >> > >
> >> > > Signed-off-by: Peter Chen 
> >> > > Tested-by: Maciej S. Szmigiero 
> >> > > Tested-by Joshua Clayton 
> >> > > Reviewed-by: Matthias Kaehlcke 
> >> > > Tested-by: Matthias Kaehlcke 
> >> >
> >> > Acked-by: Krzysztof Kozlowski 
> >> > Tested on Odroid U3 (reset sequence for LAN9730):
> >> > Tested-by: Krzysztof Kozlowski 
> >> >
> >>
> >> A nice ping...
> >>
> >
> > Rafael, would you please review it? This series was discussed about
> > half a year, and many people need it, I hope it can be in v4.11-rc1,
> > thanks.
> 
> I'm travelling now
> (http://marc.info/?l=linux-pm=148410629024194=2) and (as stated in
> this message) I'll get to the patches when I'm back home.
> 
> There is a good chance for your code to go into 4.11-rc1 if the review
> comments so far have been addressed.
> 

Thanks, Rafael. I think I have addressed all your comments.

-- 

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

Re: [PATCH v7 2/5] usb: chipidea: msm: Configure phy for appropriate mode

[Peter Chen]

On Fri, Jan 20, 2017 at 10:50:54AM -0800, Stephen Boyd wrote:
> When the qcom chipidea controller is used with an extcon, we need
> to signal device mode or host mode to the phy so it can configure
> itself for the correct mode. This should be done after the phy is
> powered up, so that the register writes work correctly. Add in
> the appropriate phy_set_mode() call here.
> 
> To signal the correct state to the qcom glue driver we need to
> change the ci->role before we do the role switch. Make sure to
> undo the change if the role switch fails, but otherwise update
> the state before calling the role start function so that the glue
> driver knows what state to configure for.
> 
> Cc: Greg Kroah-Hartman 
> Signed-off-by: Stephen Boyd 
> ---
> 
> Made this msm specific because of how msm handles phy powerup.
> 
>  drivers/usb/chipidea/ci.h  | 7 +--
>  drivers/usb/chipidea/ci_hdrc_msm.c | 4 
>  2 files changed, 9 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/usb/chipidea/ci.h b/drivers/usb/chipidea/ci.h
> index 59e22389c10b..18348b0529af 100644
> --- a/drivers/usb/chipidea/ci.h
> +++ b/drivers/usb/chipidea/ci.h
> @@ -268,6 +268,7 @@ static inline struct ci_role_driver *ci_role(struct 
> ci_hdrc *ci)
>  static inline int ci_role_start(struct ci_hdrc *ci, enum ci_role role)
>  {
>   int ret;
> + enum ci_role prev_role;
>  
>   if (role >= CI_ROLE_END)
>   return -EINVAL;
> @@ -275,9 +276,11 @@ static inline int ci_role_start(struct ci_hdrc *ci, enum 
> ci_role role)
>   if (!ci->roles[role])
>   return -ENXIO;
>  
> + prev_role = ci->role;
> + ci->role = role;
>   ret = ci->roles[role]->start(ci);
> - if (!ret)
> - ci->role = role;
> + if (ret)
> + ci->role = prev_role;
>   return ret;

Sorry, this changes ci->role's life cycle. You may try to get coming
role at your glue layer code (eg, through usbmode), or add your
changes at ci_role_start directly if the sequence can make your requirement.

Peter
>  }
>  
> diff --git a/drivers/usb/chipidea/ci_hdrc_msm.c 
> b/drivers/usb/chipidea/ci_hdrc_msm.c
> index f1ede7909f54..9c58d13970ca 100644
> --- a/drivers/usb/chipidea/ci_hdrc_msm.c
> +++ b/drivers/usb/chipidea/ci_hdrc_msm.c
> @@ -125,6 +125,10 @@ static int ci_hdrc_msm_notify_event(struct ci_hdrc *ci, 
> unsigned event)
>   hw_write(ci, OP_USBCMD, HSPHY_SESS_VLD_CTRL,
>HSPHY_SESS_VLD_CTRL);
>  
> + if (ci->role == CI_ROLE_GADGET)
> + phy_set_mode(ci->phy, PHY_MODE_USB_DEVICE);
> + else if (ci->role == CI_ROLE_HOST)
> + phy_set_mode(ci->phy, PHY_MODE_USB_HOST);
>   }
>   break;
>   case CI_HDRC_CONTROLLER_STOPPED_EVENT:
> -- 
> 2.10.0.297.gf6727b0
> 
> --
> 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

-- 

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

Re: [PATCH 5/6] dt-bindings: mt8173-xhci: add reference clock

[Chunfeng Yun]

On Sat, 2017-01-21 at 14:12 -0600, Rob Herring wrote:
> On Wed, Jan 18, 2017 at 02:08:26PM +0800, Chunfeng Yun wrote:
> > add a reference clock for compatibility
> 
> Same question here, too.
The reason is the same as mt8173-mtu3

thanks a lot
> 


--
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 6/6] dt-bindings: mt8173-mtu3: add reference clock

[Chunfeng Yun]

Hi,

On Sat, 2017-01-21 at 14:11 -0600, Rob Herring wrote:
> On Wed, Jan 18, 2017 at 02:08:27PM +0800, Chunfeng Yun wrote:
> > add a reference clock for compatibility
> 
> Why? This block suddenly has 2 clocks instead of 1?
In fact, there is a reference clock which comes from 26M oscillator
directly. I ignore it because it is a fixed-clock in DTS, and always
turned on for mt8173. But later, I find that I made a mistake before
when I bring up it on a new platform whose reference clock comes from
PLL, and need control it. So here add it, no matter it is a fixed-clock
or not.

> 
> > 
> > Signed-off-by: Chunfeng Yun 
> > ---
> >  .../devicetree/bindings/usb/mt8173-mtu3.txt|   10 +-
> >  1 file changed, 5 insertions(+), 5 deletions(-)
> > 
> > diff --git a/Documentation/devicetree/bindings/usb/mt8173-mtu3.txt 
> > b/Documentation/devicetree/bindings/usb/mt8173-mtu3.txt
> > index e049d19..8c976cd 100644
> > --- a/Documentation/devicetree/bindings/usb/mt8173-mtu3.txt
> > +++ b/Documentation/devicetree/bindings/usb/mt8173-mtu3.txt
> > @@ -10,7 +10,7 @@ Required properties:
> >   - vusb33-supply : regulator of USB avdd3.3v
> >   - clocks : a list of phandle + clock-specifier pairs, one for each
> > entry in clock-names
> > - - clock-names : must contain "sys_ck" for clock of controller;
> > + - clock-names : must contain "sys_ck" and "ref_ck" for clock of 
> > controller;
> > "wakeup_deb_p0" and "wakeup_deb_p1" are optional, they are
> > depends on "mediatek,enable-wakeup"
> >   - phys : a list of phandle + phy specifier pairs
> > @@ -56,10 +56,10 @@ ssusb: usb@11271000 {
> > phys = <_port0 PHY_TYPE_USB3>,
> ><_port1 PHY_TYPE_USB2>;
> > power-domains = < MT8173_POWER_DOMAIN_USB>;
> > -   clocks = < CLK_TOP_USB30_SEL>,
> > +   clocks = < CLK_TOP_USB30_SEL>, <>,
> >  < CLK_PERI_USB0>,
> >  < CLK_PERI_USB1>;
> > -   clock-names = "sys_ck",
> > +   clock-names = "sys_ck", "ref_ck",
> >   "wakeup_deb_p0",
> >   "wakeup_deb_p1";
> > vusb33-supply = <_vusb_reg>;
> > @@ -79,8 +79,8 @@ ssusb: usb@11271000 {
> > reg-names = "mac";
> > interrupts = ;
> > power-domains = < MT8173_POWER_DOMAIN_USB>;
> > -   clocks = < CLK_TOP_USB30_SEL>;
> > -   clock-names = "sys_ck";
> > +   clocks = < CLK_TOP_USB30_SEL>, <>;
> > +   clock-names = "sys_ck", "ref_ck";
> > vusb33-supply = <_vusb_reg>;
> > status = "disabled";
> > };
> > -- 
> > 1.7.9.5
> > 


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

RE: [PATCH v7 4/5] usb: chipidea: Signal vbus state to phy

[Peter Chen]

 
>
> drivers/usb/chipidea/otg.c | 7 +--
> 1 file changed, 5 insertions(+), 2 deletions(-)
>
>diff --git a/drivers/usb/chipidea/otg.c b/drivers/usb/chipidea/otg.c index
>10236fe71522..6ea702beed48 100644
>--- a/drivers/usb/chipidea/otg.c
>+++ b/drivers/usb/chipidea/otg.c
>@@ -134,10 +134,13 @@ void ci_handle_vbus_change(struct ci_hdrc *ci)
>   if (!ci->is_otg)
>   return;
>
>-  if (hw_read_otgsc(ci, OTGSC_BSV) && !ci->vbus_active)
>+  if (hw_read_otgsc(ci, OTGSC_BSV) && !ci->vbus_active) {
>   usb_gadget_vbus_connect(>gadget);
>-  else if (!hw_read_otgsc(ci, OTGSC_BSV) && ci->vbus_active)
>+  phy_set_vbus(ci->phy, 1);
>+  } else if (!hw_read_otgsc(ci, OTGSC_BSV) && ci->vbus_active) {
>+  phy_set_vbus(ci->phy, 0);
>   usb_gadget_vbus_disconnect(>gadget);
>+  }
> }
>
You can add my ack if you accept the name of phy_notify_vbus.

Peter

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

RE: [PATCH v7 3/5] phy: Add set_vbus callback

[Peter Chen]

 
>  * @set_mode: set the mode of the phy
>+ * @set_vbus: enable/disable vbus in the phy (USB)
>  * @reset: resetting the phy
>  * @owner: the module owner containing the ops
>  */
>@@ -45,6 +46,7 @@ struct phy_ops {
>   int (*power_on)(struct phy *phy);
>   int (*power_off)(struct phy *phy);
>   int (*set_mode)(struct phy *phy, enum phy_mode mode);
>+  int (*set_vbus)(struct phy *phy, int on);

How about using the name notify_vbus? The main purpose of this API is notify
PHY vbus status.

Peter
--
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] dt-bindings: leds: document new led-triggers property

[Jacek Anaszewski]

On 01/21/2017 05:24 PM, Rafał Miłecki wrote:
> On 20 January 2017 at 23:35, Jacek Anaszewski
>  wrote:
>> On 01/20/2017 10:56 PM, Rafał Miłecki wrote:
>>> From: Rafał Miłecki 
>>>
>>> Some LEDs can be related to particular devices described in DT. This
>>> property allows specifying such relations. E.g. USB LED should usually
>>> be used to indicate some USB port(s) state.
>>>
>>> Signed-off-by: Rafał Miłecki 
>>> ---
>>> V2: Replace "usb-ports" with "led-triggers" property which is more generic 
>>> and
>>> allows specifying other devices as well.
>>>
>>> When bindings patch is related to some followup implementation, they 
>>> usually go
>>> through the same tree.
>>>
>>> Greg: this patch is based on top of e64b8cc72bf9 ("DT: leds: Improve 
>>> examples by
>>> adding some context") from kernel/git/j.anaszewski/linux-leds.git . Is 
>>> there any
>>> way to solve this dependency issue? Or should this patch wait until 3.11 is
>>> released?
>>> ---
>>>  Documentation/devicetree/bindings/leds/common.txt | 16 
>>>  1 file changed, 16 insertions(+)
>>>
>>> diff --git a/Documentation/devicetree/bindings/leds/common.txt 
>>> b/Documentation/devicetree/bindings/leds/common.txt
>>> index 24b656014089..17632a041196 100644
>>> --- a/Documentation/devicetree/bindings/leds/common.txt
>>> +++ b/Documentation/devicetree/bindings/leds/common.txt
>>> @@ -49,6 +49,17 @@ Optional properties for child nodes:
>>>  - panic-indicator : This property specifies that the LED should be used,
>>>   if at all possible, as a panic indicator.
>>>
>>> +- led-triggers : List of devices that should trigger this LED activity. 
>>> Some
>>> +  LEDs can be related to a specific device and should somehow
>>> +  indicate its state. E.g. USB 2.0 LED may react to device(s) 
>>> in
>>> +  a USB 2.0 port(s). Another common example is switch or router
>>> +  with multiple Ethernet ports each of them having its own LED
>>> +  assigned (assuminled-trigger-usbportg they are not 
>>> hardwired).
>>> +  In such cases this property should contain phandle(s) of
>>> +  related device(s). In many cases LED can be related to more
>>> +  than one device (e.g. one USB LED vs. multiple USB ports) so 
>>> a
>>> +  list of entries can be specified.
>>> +
>>
>> This implies that it is possible to define multiple triggers for
>> a LED class device but it is not supported by LED Trigger core.
>> There is linux,default-trigger property which allows to define one
>> trigger that will be initially assigned.
> 
> I think we owe some extra explanation to people not closely familiar
> with the triggers.
> 
> Linux has multiple trigger drivers each supporting some *type* of
> events. Linux supports assigning only one trigger driver to LED at a
> time.
> This means you can use e.g.:
> 1) "usbport" trigger driver that supports USB events
> XOR
> 2) "timer" trigger driver that uses timer to control LED
> XOR
> 3) "cpu" trigger driver that supports CPU events
> at once.

Correct.

> With proposed "led-triggers" property one could assign different
> trigger *sources* to a LED. You could e.g. assign 2 USB ports, network
> device & CPU to a single LED. For reason explained above Linux
> couldn't support all of them at once.
> 
> 
>> I am aware that this is renamed usb-ports property from v1,
>> that attempts to address Rob's comment, but we can't do that this way.
>> Maybe usb-ports property could be documented in led-trigger-usbport's
>> specific bindings and a reference to it could be added next to the
>> related entry on the list of the available LED triggers (which is
>> actually missing) in Documentation/devicetree/bindings/leds/common.txt.
> 
> I'm wondering if we need to care about this Linux limitation and if it
> should stop us from adding this flexible DT property. Maybe we could
> live with Linux having limitation of supporting one trigger type at a
> time?

That's what I meant. Generally I have objections to the generic
property for defining list of allowed triggers. That's why I proposed
to stay by usb-ports property that would be specific to only one
trigger: led-trigger-usbport.

led-trigger-usbport in fact is an entirely new type of LED trigger.
LED triggers is a kernel based source of events. All existing triggers
react only to a single, well defined source of events, whereas
led-trigger-usbport allows to define the scope of events (usb ports)
to notify about. Activity on each port is treated similarly and the LED
class device that listens to the trigger notifications doesn't know
which exact port triggered the notification.

>From this POV led-trigger-usbport is kind of facade, which allows
for it to fit well into the LED Trigger design and API, and usb ports
are not identical with LED triggers, but sit rather one level below.
It is led-trigger-usbport which 

[PATCH v5] USB: Add uPD78F0730 USB to Serial Adaptor Driver

[Maksim Salau]

The adaptor can be found on development boards for 78k, RL78 and V850
microcontrollers produced by Renesas Electronics Corporation.

This is not a full-featured USB to serial converter, however it allows
basic communication and simple control which is enough for programming of
on-board flash and debugging through a debug monitor.

uPD78F0730 is a USB-enabled microcontroller with USB-to-UART conversion
implemented in firmware.

This chip is also present in some debugging adaptors which use it for
USB-to-SPI conversion as well. The present driver doesn't cover SPI,
only USB-to-UART conversion is supported.

Signed-off-by: Maksim Salau 
---
Changes in v5:
  Fixed a typo in assignment of opcode of the SET_DTR_RTS request

Changes in v4:
  Addressed comments from Johan

 drivers/usb/serial/Kconfig  |   9 +
 drivers/usb/serial/Makefile |   1 +
 drivers/usb/serial/upd78f0730.c | 458 
 3 files changed, 468 insertions(+)
 create mode 100644 drivers/usb/serial/upd78f0730.c

diff --git a/drivers/usb/serial/Kconfig b/drivers/usb/serial/Kconfig
index d9bc8da..a8d5f2e 100644
--- a/drivers/usb/serial/Kconfig
+++ b/drivers/usb/serial/Kconfig
@@ -713,6 +713,15 @@ config USB_SERIAL_QT2
  To compile this driver as a module, choose M here: the
  module will be called quatech-serial.
 
+config USB_SERIAL_UPD78F0730
+   tristate "USB Renesas uPD78F0730 Single Port Serial Driver"
+   help
+ Say Y here if you want to use the Renesas uPD78F0730
+ serial driver.
+
+ To compile this driver as a module, choose M here: the
+ module will be called upd78f0730.
+
 config USB_SERIAL_DEBUG
tristate "USB Debugging Device"
help
diff --git a/drivers/usb/serial/Makefile b/drivers/usb/serial/Makefile
index 9e43b7b..5a21a82 100644
--- a/drivers/usb/serial/Makefile
+++ b/drivers/usb/serial/Makefile
@@ -56,6 +56,7 @@ obj-$(CONFIG_USB_SERIAL_SSU100)   += 
ssu100.o
 obj-$(CONFIG_USB_SERIAL_SYMBOL)+= symbolserial.o
 obj-$(CONFIG_USB_SERIAL_WWAN)  += usb_wwan.o
 obj-$(CONFIG_USB_SERIAL_TI)+= ti_usb_3410_5052.o
+obj-$(CONFIG_USB_SERIAL_UPD78F0730)+= upd78f0730.o
 obj-$(CONFIG_USB_SERIAL_VISOR) += visor.o
 obj-$(CONFIG_USB_SERIAL_WISHBONE)  += wishbone-serial.o
 obj-$(CONFIG_USB_SERIAL_WHITEHEAT) += whiteheat.o
diff --git a/drivers/usb/serial/upd78f0730.c b/drivers/usb/serial/upd78f0730.c
new file mode 100644
index 000..a1ca02b
--- /dev/null
+++ b/drivers/usb/serial/upd78f0730.c
@@ -0,0 +1,458 @@
+/*
+ * Renesas Electronics uPD78F0730 USB to serial converter driver
+ *
+ * Copyright (C) 2014,2016 Maksim Salau 
+ *
+ * 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.
+ *
+ * Protocol of the adaptor is described in the application note U19660EJ1V0AN00
+ * μPD78F0730 8-bit Single-Chip Microcontroller
+ * USB-to-Serial Conversion Software
+ * 
+ *
+ * The adaptor functionality is limited to the following:
+ * - data bits: 7 or 8
+ * - stop bits: 1 or 2
+ * - parity: even, odd or none
+ * - flow control: none
+ * - baud rates: 0, 2400, 4800, 9600, 19200, 38400, 57600, 115200
+ * - signals: DTR, RTS and BREAK
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define DRIVER_DESC "Renesas uPD78F0730 USB to serial converter driver"
+
+#define DRIVER_AUTHOR "Maksim Salau "
+
+static const struct usb_device_id id_table[] = {
+   { USB_DEVICE(0x045B, 0x0212) }, /* YRPBRL78G13, YRPBRL78G14 */
+   { USB_DEVICE(0x0409, 0x0063) }, /* V850ESJX3-STICK */
+   {}
+};
+
+MODULE_DEVICE_TABLE(usb, id_table);
+
+/*
+ * Each adaptor is associated with a private structure, that holds the current
+ * state of control signals (DTR, RTS and BREAK).
+ */
+struct upd78f0730_port_private {
+   struct mutexlock;   /* mutex to protect line_signals */
+   u8  line_signals;
+};
+
+/* Op-codes of control commands */
+#define UPD78F0730_CMD_LINE_CONTROL0x00
+#define UPD78F0730_CMD_SET_DTR_RTS 0x01
+#define UPD78F0730_CMD_SET_XON_XOFF_CHR0x02
+#define UPD78F0730_CMD_OPEN_CLOSE  0x03
+#define UPD78F0730_CMD_SET_ERR_CHR 0x04
+
+/* Data sizes in UPD78F0730_CMD_LINE_CONTROL command */
+#define UPD78F0730_DATA_SIZE_7_BITS0x00
+#define UPD78F0730_DATA_SIZE_8_BITS0x01
+#define UPD78F0730_DATA_SIZE_MASK  0x01
+
+/* Stop-bit modes in UPD78F0730_CMD_LINE_CONTROL command */
+#define UPD78F0730_STOP_BIT_1_BIT  0x00
+#define UPD78F0730_STOP_BIT_2_BIT  0x02
+#define UPD78F0730_STOP_BIT_MASK   0x02
+
+/* Parity modes in UPD78F0730_CMD_LINE_CONTROL command */
+#define 

[PATCH v4] USB: Add uPD78F0730 USB to Serial Adaptor Driver

[Maksim Salau]

The adaptor can be found on development boards for 78k, RL78 and V850
microcontrollers produced by Renesas Electronics Corporation.

This is not a full-featured USB to serial converter, however it allows
basic communication and simple control which is enough for programming of
on-board flash and debugging through a debug monitor.

uPD78F0730 is a USB-enabled microcontroller with USB-to-UART conversion
implemented in firmware.

This chip is also present in some debugging adaptors which use it for
USB-to-SPI conversion as well. The present driver doesn't cover SPI,
only USB-to-UART conversion is supported.

Signed-off-by: Maksim Salau 
---
 drivers/usb/serial/Kconfig  |   9 +
 drivers/usb/serial/Makefile |   1 +
 drivers/usb/serial/upd78f0730.c | 458 
 3 files changed, 468 insertions(+)
 create mode 100644 drivers/usb/serial/upd78f0730.c

diff --git a/drivers/usb/serial/Kconfig b/drivers/usb/serial/Kconfig
index d9bc8da..a8d5f2e 100644
--- a/drivers/usb/serial/Kconfig
+++ b/drivers/usb/serial/Kconfig
@@ -713,6 +713,15 @@ config USB_SERIAL_QT2
  To compile this driver as a module, choose M here: the
  module will be called quatech-serial.
 
+config USB_SERIAL_UPD78F0730
+   tristate "USB Renesas uPD78F0730 Single Port Serial Driver"
+   help
+ Say Y here if you want to use the Renesas uPD78F0730
+ serial driver.
+
+ To compile this driver as a module, choose M here: the
+ module will be called upd78f0730.
+
 config USB_SERIAL_DEBUG
tristate "USB Debugging Device"
help
diff --git a/drivers/usb/serial/Makefile b/drivers/usb/serial/Makefile
index 9e43b7b..5a21a82 100644
--- a/drivers/usb/serial/Makefile
+++ b/drivers/usb/serial/Makefile
@@ -56,6 +56,7 @@ obj-$(CONFIG_USB_SERIAL_SSU100)   += 
ssu100.o
 obj-$(CONFIG_USB_SERIAL_SYMBOL)+= symbolserial.o
 obj-$(CONFIG_USB_SERIAL_WWAN)  += usb_wwan.o
 obj-$(CONFIG_USB_SERIAL_TI)+= ti_usb_3410_5052.o
+obj-$(CONFIG_USB_SERIAL_UPD78F0730)+= upd78f0730.o
 obj-$(CONFIG_USB_SERIAL_VISOR) += visor.o
 obj-$(CONFIG_USB_SERIAL_WISHBONE)  += wishbone-serial.o
 obj-$(CONFIG_USB_SERIAL_WHITEHEAT) += whiteheat.o
diff --git a/drivers/usb/serial/upd78f0730.c b/drivers/usb/serial/upd78f0730.c
new file mode 100644
index 000..7372b94
--- /dev/null
+++ b/drivers/usb/serial/upd78f0730.c
@@ -0,0 +1,458 @@
+/*
+ * Renesas Electronics uPD78F0730 USB to serial converter driver
+ *
+ * Copyright (C) 2014,2016 Maksim Salau 
+ *
+ * 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.
+ *
+ * Protocol of the adaptor is described in the application note U19660EJ1V0AN00
+ * μPD78F0730 8-bit Single-Chip Microcontroller
+ * USB-to-Serial Conversion Software
+ * 
+ *
+ * The adaptor functionality is limited to the following:
+ * - data bits: 7 or 8
+ * - stop bits: 1 or 2
+ * - parity: even, odd or none
+ * - flow control: none
+ * - baud rates: 0, 2400, 4800, 9600, 19200, 38400, 57600, 115200
+ * - signals: DTR, RTS and BREAK
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define DRIVER_DESC "Renesas uPD78F0730 USB to serial converter driver"
+
+#define DRIVER_AUTHOR "Maksim Salau "
+
+static const struct usb_device_id id_table[] = {
+   { USB_DEVICE(0x045B, 0x0212) }, /* YRPBRL78G13, YRPBRL78G14 */
+   { USB_DEVICE(0x0409, 0x0063) }, /* V850ESJX3-STICK */
+   {}
+};
+
+MODULE_DEVICE_TABLE(usb, id_table);
+
+/*
+ * Each adaptor is associated with a private structure, that holds the current
+ * state of control signals (DTR, RTS and BREAK).
+ */
+struct upd78f0730_port_private {
+   struct mutexlock;   /* mutex to protect line_signals */
+   u8  line_signals;
+};
+
+/* Op-codes of control commands */
+#define UPD78F0730_CMD_LINE_CONTROL0x00
+#define UPD78F0730_CMD_SET_DTR_RTS 0x01
+#define UPD78F0730_CMD_SET_XON_XOFF_CHR0x02
+#define UPD78F0730_CMD_OPEN_CLOSE  0x03
+#define UPD78F0730_CMD_SET_ERR_CHR 0x04
+
+/* Data sizes in UPD78F0730_CMD_LINE_CONTROL command */
+#define UPD78F0730_DATA_SIZE_7_BITS0x00
+#define UPD78F0730_DATA_SIZE_8_BITS0x01
+#define UPD78F0730_DATA_SIZE_MASK  0x01
+
+/* Stop-bit modes in UPD78F0730_CMD_LINE_CONTROL command */
+#define UPD78F0730_STOP_BIT_1_BIT  0x00
+#define UPD78F0730_STOP_BIT_2_BIT  0x02
+#define UPD78F0730_STOP_BIT_MASK   0x02
+
+/* Parity modes in UPD78F0730_CMD_LINE_CONTROL command */
+#define UPD78F0730_PARITY_NONE 0x00
+#define UPD78F0730_PARITY_EVEN 0x04
+#define UPD78F0730_PARITY_ODD  0x08
+#define UPD78F0730_PARITY_MASK 

Re: [PATCH 6/6] dt-bindings: mt8173-mtu3: add reference clock

[Rob Herring]

On Wed, Jan 18, 2017 at 02:08:27PM +0800, Chunfeng Yun wrote:
> add a reference clock for compatibility

Why? This block suddenly has 2 clocks instead of 1?

> 
> Signed-off-by: Chunfeng Yun 
> ---
>  .../devicetree/bindings/usb/mt8173-mtu3.txt|   10 +-
>  1 file changed, 5 insertions(+), 5 deletions(-)
> 
> diff --git a/Documentation/devicetree/bindings/usb/mt8173-mtu3.txt 
> b/Documentation/devicetree/bindings/usb/mt8173-mtu3.txt
> index e049d19..8c976cd 100644
> --- a/Documentation/devicetree/bindings/usb/mt8173-mtu3.txt
> +++ b/Documentation/devicetree/bindings/usb/mt8173-mtu3.txt
> @@ -10,7 +10,7 @@ Required properties:
>   - vusb33-supply : regulator of USB avdd3.3v
>   - clocks : a list of phandle + clock-specifier pairs, one for each
>   entry in clock-names
> - - clock-names : must contain "sys_ck" for clock of controller;
> + - clock-names : must contain "sys_ck" and "ref_ck" for clock of controller;
>   "wakeup_deb_p0" and "wakeup_deb_p1" are optional, they are
>   depends on "mediatek,enable-wakeup"
>   - phys : a list of phandle + phy specifier pairs
> @@ -56,10 +56,10 @@ ssusb: usb@11271000 {
>   phys = <_port0 PHY_TYPE_USB3>,
>  <_port1 PHY_TYPE_USB2>;
>   power-domains = < MT8173_POWER_DOMAIN_USB>;
> - clocks = < CLK_TOP_USB30_SEL>,
> + clocks = < CLK_TOP_USB30_SEL>, <>,
>< CLK_PERI_USB0>,
>< CLK_PERI_USB1>;
> - clock-names = "sys_ck",
> + clock-names = "sys_ck", "ref_ck",
> "wakeup_deb_p0",
> "wakeup_deb_p1";
>   vusb33-supply = <_vusb_reg>;
> @@ -79,8 +79,8 @@ ssusb: usb@11271000 {
>   reg-names = "mac";
>   interrupts = ;
>   power-domains = < MT8173_POWER_DOMAIN_USB>;
> - clocks = < CLK_TOP_USB30_SEL>;
> - clock-names = "sys_ck";
> + clocks = < CLK_TOP_USB30_SEL>, <>;
> + clock-names = "sys_ck", "ref_ck";
>   vusb33-supply = <_vusb_reg>;
>   status = "disabled";
>   };
> -- 
> 1.7.9.5
> 
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v3 2/3] USB3/DWC3: Add property "snps, incr-burst-type-adjustment" for INCR burst type

[Rob Herring]

On Tue, Jan 3, 2017 at 8:24 PM, Jerry Huang  wrote:
> Hi, Rob,
>
>> -Original Message-
>> From: Rob Herring [mailto:r...@kernel.org]
>> Sent: Wednesday, January 04, 2017 5:24 AM
>> To: Jerry Huang 
>> Cc: ba...@kernel.org; mark.rutl...@arm.com; catalin.mari...@arm.com;
>> will.dea...@arm.com; li...@armlinux.org.uk; devicet...@vger.kernel.org;
>> linux-usb@vger.kernel.org; linux-ker...@vger.kernel.org; linux-arm-
>> ker...@lists.infradead.org
>> Subject: Re: [PATCH v3 2/3] USB3/DWC3: Add property "snps, incr-burst-
>> type-adjustment" for INCR burst type
>>
>> On Thu, Dec 22, 2016 at 8:52 PM, Jerry Huang  wrote:
>> > Hi, Rob,
>> >> -Original Message-
>> >> From: Rob Herring [mailto:r...@kernel.org]
>> >> Sent: Friday, December 23, 2016 2:45 AM
>> >> To: Jerry Huang 
>> >> Cc: ba...@kernel.org; mark.rutl...@arm.com; catalin.mari...@arm.com;
>> >> will.dea...@arm.com; li...@armlinux.org.uk;
>> >> devicet...@vger.kernel.org; linux-usb@vger.kernel.org;
>> >> linux-ker...@vger.kernel.org; linux-arm- ker...@lists.infradead.org
>> >> Subject: Re: [PATCH v3 2/3] USB3/DWC3: Add property "snps,
>> >> incr-burst- type-adjustment" for INCR burst type
>> >>
>> >> On Mon, Dec 19, 2016 at 05:25:53PM +0800, Changming Huang wrote:
>> >> > New property "snps,incr-burst-type-adjustment = , " for
>> >> > USB3.0
>> >> DWC3.
>> >> > Field "x": 1/0 - undefined length INCR burst type enable or not;
>> >> > Field
>> >> > "y": INCR4/INCR8/INCR16/INCR32/INCR64/INCR128/INCR256 burst type.
>> >> >
>> >> > While enabling undefined length INCR burst type and INCR16 burst
>> >> > type, get better write performance on NXP Layerscape platform:
>> >> > around 3% improvement (from 364MB/s to 375MB/s).
>> >> >
>> >> > Signed-off-by: Changming Huang 
>> >> > ---
>> >> > Changes in v3:
>> >> >   - add new property for INCR burst in usb node.
>> >> >
>> >> >  Documentation/devicetree/bindings/usb/dwc3.txt |5 +
>> >> >  arch/arm/boot/dts/ls1021a.dtsi |1 +
>> >> >  arch/arm64/boot/dts/freescale/fsl-ls1043a.dtsi |3 +++
>> >> >  arch/arm64/boot/dts/freescale/fsl-ls2080a.dtsi |2 ++
>> >> >  4 files changed, 11 insertions(+)
>> >> >
>> >> > diff --git a/Documentation/devicetree/bindings/usb/dwc3.txt
>> >> > b/Documentation/devicetree/bindings/usb/dwc3.txt
>> >> > index e3e6983..8c405a3 100644
>> >> > --- a/Documentation/devicetree/bindings/usb/dwc3.txt
>> >> > +++ b/Documentation/devicetree/bindings/usb/dwc3.txt
>> >> > @@ -55,6 +55,10 @@ Optional properties:
>> >> > fladj_30mhz_sdbnd signal is invalid or incorrect.
>> >> >
>> >> >   -  tx-fifo-resize: determines if the FIFO *has* to be
>> >> reallocated.
>> >> > + - snps,incr-burst-type-adjustment: Value for INCR burst type of
>> >> GSBUSCFG0
>> >> > +   register, undefined length INCR burst type enable and INCRx type.
>> >> > +   First field is for undefined length INCR burst type enable or not.
>> >> > +   Second field is for largest INCRx type enabled.
>> >>
>> >> Why do you need the first field? Is the 2nd field used if the 1st is 0?
>> >> If not, then just use the presence of the property to enable or not.
>> > The first field is one switch.
>> > When it is 1, means undefined length INCR burst type enabled, we can use
>> any length less than or equal to the largest-enabled burst length of
>> INCR4/8/16/32/64/128/256.
>> > When it is zero, means INCRx burst mode enabled, we can use one fixed
>> burst length of 1/4/8/16/32/64/128/256 byte.
>> > So, the 2nd field is used if the 1st is 0, we need to select one largest 
>> > burst
>> length the USB controller can support.
>> > If we don't want to change the value of this register (use the default 
>> > value),
>> we don't need to add this property to usb node.
>>
>> Just make this a single value with 0 meaning INCR and 4/8/16/etc being INCRx.
> Maybe, I didn't describe it clearly.
> According to DWC3 spec, the value "0" of field INCRBrstEna means INCRx burst 
> mode, 1 means INCR burst mode.
> Regardless of the value of INCRBrstEna [bit0], we need to modify the other 
> field bit[1,2,3,4,5,6,7] to one INCR burst type  for the platform supported.
> Ad you mentioned, if we just use a single value with 0 meaning INCR and 
> 4/8/16/etc being INCRx.
> I understand totally that when it is none-zero, we can use it for INCR burst 
> mode.
> Then, when it is 0, how to select the INCRx value?

What I mean is:
 - burst disabled
0 - INCR burst. INCR is undefined length burst IIRC.
4/8/16/etc. - INCR4/INCR8/INCR16/etc.

What case does this not cover?

Rob
--
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 5/6] dt-bindings: mt8173-xhci: add reference clock

[Rob Herring]

On Wed, Jan 18, 2017 at 02:08:26PM +0800, Chunfeng Yun wrote:
> add a reference clock for compatibility

Same question here, too.

--
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 5/6] dt-bindings: mt8173-xhci: add reference clock

[Rob Herring]

On Wed, Jan 18, 2017 at 02:08:26PM +0800, Chunfeng Yun wrote:
> add a reference clock for compatibility
> 
> Signed-off-by: Chunfeng Yun 
> ---
>  .../devicetree/bindings/usb/mt8173-xhci.txt|   10 ++
>  1 file changed, 6 insertions(+), 4 deletions(-)

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

Re: [RESEND PATCH 6/6] dt-bindings: phy-mt65xx-usb: add support for mt2712 platform

[Rob Herring]

On Wed, Jan 18, 2017 at 02:00:14PM +0800, Chunfeng Yun wrote:
> add a new compatible string for "mt2712", and a new reference clock
> for SuperSpeed analog phy;
> 
> Signed-off-by: Chunfeng Yun 
> ---
>  .../devicetree/bindings/phy/phy-mt65xx-usb.txt |   81 
> +---
>  1 file changed, 70 insertions(+), 11 deletions(-)
> 
> diff --git a/Documentation/devicetree/bindings/phy/phy-mt65xx-usb.txt 
> b/Documentation/devicetree/bindings/phy/phy-mt65xx-usb.txt
> index 33a2b1e..8f91136 100644
> --- a/Documentation/devicetree/bindings/phy/phy-mt65xx-usb.txt
> +++ b/Documentation/devicetree/bindings/phy/phy-mt65xx-usb.txt
> @@ -6,19 +6,25 @@ This binding describes a usb3.0 phy for mt65xx platforms of 
> Medaitek SoC.
>  Required properties (controller (parent) node):
>   - compatible: should be one of
> "mediatek,mt2701-u3phy"
> +   "mediatek,mt2712-u3phy"
> "mediatek,mt8173-u3phy"
> - - reg   : offset and length of register for phy, exclude port's
> -   register.
>   - clocks: a list of phandle + clock-specifier pairs, one for each
> entry in clock-names
>   - clock-names   : must contain
> -   "u3phya_ref": for reference clock of usb3.0 analog phy.
> +   "u2ref_clk": 48M reference clock of HighSpeed analog phy.
> +   "u3ref_clk": 26M reference clock of SuperSpeed analog phy,
> + sometimes is 24M, 25M or 27M, depended on platform.

_clk is redundant.

>  
>  Required nodes   : a sub-node is required for each port the controller
> provides. Address range information including the usual
> 'reg' property is used inside these nodes to describe
> the controller's topology.
>  
> +Optional properties (controller (parent) node):
> + - reg   : offset and length of register shared by multiple 
> ports,
> +   exclude port's private register. It is needed on mt2701
> +   and mt8173, but not on mt2712.
> +
>  Required properties (port (child) node):
>  - reg: address and length of the register set for the port.
>  - #phy-cells : should be 1 (See second example)
> @@ -31,21 +37,27 @@ Example:
>  u3phy: usb-phy@1129 {
>   compatible = "mediatek,mt8173-u3phy";
>   reg = <0 0x1129 0 0x800>;
> - clocks = < CLK_APMIXED_REF2USB_TX>;
> - clock-names = "u3phya_ref";
> + clocks = < CLK_APMIXED_REF2USB_TX>, <>;
> + clock-names = "u2ref_clk", "u3ref_clk";
>   #address-cells = <2>;
>   #size-cells = <2>;
>   ranges;
>   status = "okay";
>  
> - phy_port0: port@11290800 {
> - reg = <0 0x11290800 0 0x800>;
> + u2port0: port@11290800 {

port is for OF graph. This should be usb-phy@... instead.

> + reg = <0 0x11290800 0 0x100>;
> + #phy-cells = <1>;
> + status = "okay";
> + };
> +
> + u3port0: port@11290900 {
> + reg = <0 0x11290800 0 0x700>;
>   #phy-cells = <1>;
>   status = "okay";
>   };
>  
> - phy_port1: port@11291000 {
> - reg = <0 0x11291000 0 0x800>;
> + u2port1: port@11291000 {
> + reg = <0 0x11291000 0 0x100>;
>   #phy-cells = <1>;
>   status = "okay";
>   };
> @@ -64,7 +76,54 @@ Example:
>  
>  usb30: usb@1127 {
>   ...
> - phys = <_port0 PHY_TYPE_USB3>;
> - phy-names = "usb3-0";
> + phys = < PHY_TYPE_USB2>, < PHY_TYPE_USB3>;
> + phy-names = "usb2-0", "usb3-0";
>   ...
>  };
> +
> +
> +Layout differences of banks between mt8173/mt2701 and mt2712
> +-
> +mt8173 and mt2701:
> +portoffsetbank
> +shared  0xSPLLC
> +0x0100FMREG
> +u2 port00x0800U2PHY_COM
> +u3 port00x0900U3PHYD
> +0x0a00U3PHYD_BANK2
> +0x0b00U3PHYA
> +0x0c00U3PHYA_DA
> +u2 port10x1000U2PHY_COM
> +u3 port10x1100U3PHYD
> +0x1200U3PHYD_BANK2
> +0x1300U3PHYA
> +0x1400U3PHYA_DA
> +u2 port20x1800U2PHY_COM
> +...
> +
> +mt2712:
> +portoffsetbank
> +u2 port00xMISC
> +0x0100FMREG
> +0x0300U2PHY_COM
> +u3 port00x0700SPLLC
> +0x0800CHIP
> +0x0900U3PHYD
> +0x0a00U3PHYD_BANK2
> +0x0b00U3PHYA
> +0x0c00U3PHYA_DA
> +u2 port10x1000MISC
> +0x1100FMREG
> +0x1300U2PHY_COM
> +u3 port10x1700SPLLC
> +0x1800CHIP
> +0x1900U3PHYD
> +0x1a00U3PHYD_BANK2
> +0x1b00U3PHYA
> +0x1c00U3PHYA_DA
> +u2 port20x2000MISC
> +...
> +
> +

Re: [PATCH V2 1/2] dt-bindings: leds: document new led-triggers property

[Rafał Miłecki]

On 20 January 2017 at 23:35, Jacek Anaszewski
 wrote:
> On 01/20/2017 10:56 PM, Rafał Miłecki wrote:
>> From: Rafał Miłecki 
>>
>> Some LEDs can be related to particular devices described in DT. This
>> property allows specifying such relations. E.g. USB LED should usually
>> be used to indicate some USB port(s) state.
>>
>> Signed-off-by: Rafał Miłecki 
>> ---
>> V2: Replace "usb-ports" with "led-triggers" property which is more generic 
>> and
>> allows specifying other devices as well.
>>
>> When bindings patch is related to some followup implementation, they usually 
>> go
>> through the same tree.
>>
>> Greg: this patch is based on top of e64b8cc72bf9 ("DT: leds: Improve 
>> examples by
>> adding some context") from kernel/git/j.anaszewski/linux-leds.git . Is there 
>> any
>> way to solve this dependency issue? Or should this patch wait until 3.11 is
>> released?
>> ---
>>  Documentation/devicetree/bindings/leds/common.txt | 16 
>>  1 file changed, 16 insertions(+)
>>
>> diff --git a/Documentation/devicetree/bindings/leds/common.txt 
>> b/Documentation/devicetree/bindings/leds/common.txt
>> index 24b656014089..17632a041196 100644
>> --- a/Documentation/devicetree/bindings/leds/common.txt
>> +++ b/Documentation/devicetree/bindings/leds/common.txt
>> @@ -49,6 +49,17 @@ Optional properties for child nodes:
>>  - panic-indicator : This property specifies that the LED should be used,
>>   if at all possible, as a panic indicator.
>>
>> +- led-triggers : List of devices that should trigger this LED activity. Some
>> +  LEDs can be related to a specific device and should somehow
>> +  indicate its state. E.g. USB 2.0 LED may react to device(s) in
>> +  a USB 2.0 port(s). Another common example is switch or router
>> +  with multiple Ethernet ports each of them having its own LED
>> +  assigned (assuminled-trigger-usbportg they are not hardwired).
>> +  In such cases this property should contain phandle(s) of
>> +  related device(s). In many cases LED can be related to more
>> +  than one device (e.g. one USB LED vs. multiple USB ports) so a
>> +  list of entries can be specified.
>> +
>
> This implies that it is possible to define multiple triggers for
> a LED class device but it is not supported by LED Trigger core.
> There is linux,default-trigger property which allows to define one
> trigger that will be initially assigned.

I think we owe some extra explanation to people not closely familiar
with the triggers.

Linux has multiple trigger drivers each supporting some *type* of
events. Linux supports assigning only one trigger driver to LED at a
time.
This means you can use e.g.:
1) "usbport" trigger driver that supports USB events
XOR
2) "timer" trigger driver that uses timer to control LED
XOR
3) "cpu" trigger driver that supports CPU events
at once.

With proposed "led-triggers" property one could assign different
trigger *sources* to a LED. You could e.g. assign 2 USB ports, network
device & CPU to a single LED. For reason explained above Linux
couldn't support all of them at once.


> I am aware that this is renamed usb-ports property from v1,
> that attempts to address Rob's comment, but we can't do that this way.
> Maybe usb-ports property could be documented in led-trigger-usbport's
> specific bindings and a reference to it could be added next to the
> related entry on the list of the available LED triggers (which is
> actually missing) in Documentation/devicetree/bindings/leds/common.txt.

I'm wondering if we need to care about this Linux limitation and if it
should stop us from adding this flexible DT property. Maybe we could
live with Linux having limitation of supporting one trigger type at a
time? So e.g. if one assigns 2 USB ports + network device + CPU and
decides to use "usport" trigger driver he'll get LED indicating status
of USB ports only.

I think we could live with such limitation in Linux support for this
generic "led-triggers" property. I think it's also not very common to
have LED with different types of devices assigned. Personally I've
never seen devices with LED label "USB & CPU" or whatever.

What do you think about this? Maybe we could also document this
limitation in trigger docs.
--
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

[GIT PULL] USB driver fixes for 4.10-rc5

[Greg KH]

The following changes since commit 49def1853334396f948dcb4cedb9347abb318df5:

  Linux 4.10-rc4 (2017-01-15 16:21:59 -0800)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git/ 
tags/usb-4.10-rc5

for you to fetch changes up to 488dc164914ff5ce5e913abd32048d28fc0d06b8:

  xhci: remove WARN_ON if dma mask is not set for platform devices (2017-01-20 
14:55:20 +0100)


USB fixes for 4.10-rc5

Here are a few small USB fixes for 4.10-rc5.

Most of these are gadget/dwc2 fixes for reported issues, all of these
have been in linux-next for a while.  The last one is a single xhci
WARN_ON removal to handle an issue that the dwc3 driver is hitting in
the 4.10-rc tree.  The warning is harmless and needs to be removed, and
a "real" fix that is more complex will show up in 4.11-rc1 for this
device.

That last patch hasn't been in linux-next yet due to the weekend timing,
but it's a "simple" WARN_ON() removal so what could go wrong?  :)

Signed-off-by: Greg Kroah-Hartman 


Alexandre Belloni (1):
  usb: gadget: udc: atmel: remove memory leak

Amelie Delaunay (1):
  usb: dwc2: gadget: Fix GUSBCFG.USBTRDTIM value

Christophe JAILLET (1):
  usb: gadget: composite: Fix function used to free memory

Greg Kroah-Hartman (1):
  Merge tag 'fixes-for-v4.10-rc5' of git://git.kernel.org/.../balbi/usb 
into usb-linus

John Stultz (1):
  usb: dwc2: Avoid suspending if we're in gadget mode

Leo Yan (1):
  usb: dwc2: use u32 for DT binding parameters

Mathias Nyman (1):
  xhci: remove WARN_ON if dma mask is not set for platform devices

Nicholas Mc Guire (1):
  usb: dwc2: host: fix Wmaybe-uninitialized warning

Shuah Khan (1):
  usb: dwc3: exynos fix axius clock error path to do cleanup

Vardan Mikayelyan (1):
  usb: dwc2: gadget: Fix DMA memory freeing

Vincent Pelletier (1):
  usb: gadget: f_fs: Fix iterations on endpoints.

 drivers/usb/dwc2/core.h |  4 ++--
 drivers/usb/dwc2/gadget.c   | 18 +-
 drivers/usb/dwc2/hcd.c  |  7 +--
 drivers/usb/dwc2/params.c   | 10 +-
 drivers/usb/dwc3/dwc3-exynos.c  |  4 +++-
 drivers/usb/gadget/composite.c  |  2 +-
 drivers/usb/gadget/function/f_fs.c  | 12 ++--
 drivers/usb/gadget/udc/atmel_usba_udc.c |  3 ++-
 drivers/usb/gadget/udc/atmel_usba_udc.h |  1 +
 drivers/usb/host/xhci-plat.c|  2 +-
 10 files changed, 31 insertions(+), 32 deletions(-)
--
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: Add quirk for WORLDE easykey.25 MIDI keyboard

[Greg Kroah-Hartman]

On Fri, Jan 20, 2017 at 07:46:34PM +0100, Lukáš Lalinský wrote:
> Add a quirk for WORLDE easykey.25 MIDI keyboard (idVendor=0218,
> idProduct=0401). The device reports that it has config string
> descriptor at index 3, but when the system selects the configuration
> and tries to get the description, it returns a -EPROTO error,
> the communication restarts and this keeps repeating over and over again.
> Not requesting the string descriptor makes the device work correctly.

Always use scripts/get_maintainer.pl to determine who to send patches
to, and what mailing list.  You forgot linux-usb@vger, which I've now
added...

> 
> Relevant info from Wireshark:
> 
> [...]
> 
> CONFIGURATION DESCRIPTOR
> bLength: 9
> bDescriptorType: 0x02 (CONFIGURATION)
> wTotalLength: 101
> bNumInterfaces: 2
> bConfigurationValue: 1
> iConfiguration: 3
> Configuration bmAttributes: 0xc0  SELF-POWERED  NO REMOTE-WAKEUP
> 1...  = Must be 1: Must be 1 for USB 1.1 and higher
> .1..  = Self-Powered: This device is SELF-POWERED
> ..0.  = Remote Wakeup: This device does NOT support remote wakeup
> bMaxPower: 50  (100mA)
> 
> [...]
> 
>  45 0.369104   host  2.38.0USB  
> 64 GET DESCRIPTOR Request STRING
> 
> [...]
> 
> URB setup
> bmRequestType: 0x80
> 1...  = Direction: Device-to-host
> .00.  = Type: Standard (0x00)
> ...0  = Recipient: Device (0x00)
> bRequest: GET DESCRIPTOR (6)
> Descriptor Index: 0x03
> bDescriptorType: 0x03
> Language Id: English (United States) (0x0409)
> wLength: 255
> 
>  46 0.369255   2.38.0host  USB  
> 64 GET DESCRIPTOR Response STRING[Malformed Packet]
> 
> [...]
> 
> Frame 46: 64 bytes on wire (512 bits), 64 bytes captured (512 bits) on 
> interface 0
> USB URB
> [Source: 2.38.0]
> [Destination: host]
> URB id: 0x88021f62d480
> URB type: URB_COMPLETE ('C')
> URB transfer type: URB_CONTROL (0x02)
> Endpoint: 0x80, Direction: IN
> Device: 38
> URB bus id: 2
> Device setup request: not relevant ('-')
> Data: present (0)
> URB sec: 1484896277
> URB usec: 455031
> URB status: Protocol error (-EPROTO) (-71)
> URB length [bytes]: 0
> Data length [bytes]: 0
> [Request in: 45]
> [Time from request: 0.000151000 seconds]
> Unused Setup Header
> Interval: 0
> Start frame: 0
> Copy of Transfer Flags: 0x0200
> Number of ISO descriptors: 0
> [Malformed Packet: USB]
> [Expert Info (Error/Malformed): Malformed Packet (Exception occurred)]
> [Malformed Packet (Exception occurred)]
> [Severity level: Error]
> [Group: Malformed]
> 
> Signed-off-by: Lukáš Lalinský 
> ---
>  drivers/usb/core/quirks.c | 4 
>  1 file changed, 4 insertions(+)
> 
> diff --git a/drivers/usb/core/quirks.c b/drivers/usb/core/quirks.c
> index d2e50a2..24f9f98 100644
> --- a/drivers/usb/core/quirks.c
> +++ b/drivers/usb/core/quirks.c
> @@ -37,6 +37,10 @@ static const struct usb_device_id usb_quirk_list[] = {
>   /* CBM - Flash disk */
>   { USB_DEVICE(0x0204, 0x6025), .driver_info = USB_QUIRK_RESET_RESUME },
>  
> + /* WORLDE easy key (easykey.25) MIDI controller  */
> + { USB_DEVICE(0x0218, 0x0401), .driver_info =
> + USB_QUIRK_CONFIG_INTF_STRINGS },

That's odd, how does other operating systems handle this device?

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