Re: Microchip USB Hub Driver Harmonization

[Richard Leitner]

On 05/17/2017 06:01 PM, Krzysztof Kozlowski wrote:

On Wed, May 17, 2017 at 12:58:38PM +0200, Richard Leitner wrote:

...

1. Currently usb251xb uses i2c_smbus_*, usb3503 uses regmap_* and
usb4604 uses i2c_master_* functions for the hub configuration. What
would be the preferred solution?


regmap? It is already widely used for I2C drivers. I think most (or even
all?) new I2C drivers use regmap. It hides the real bus between common
regmap API.


Ok. Thanks for that information. Then I will go for regmap.




2. What would be a good prefix for common headers/functions/macros/etc.?
I thought of "mcusbhub"... Would that be OK? Or are there any
conventions/better proposals on that?


If you are going to develop one driver for entire family, then you could
even choose just one name. Let's say the most generic.

I don't quite understand the meaning behind "harmonizing drivers".


I'm currently evaluating if it is feasible to create one common driver 
for all USB hubs. Due to the fact there are currently only 3 hub 
types implemented mainline (the Microchip homepage lists 36 USB Hub 
products [1]) it involves quite a lot data-sheet reading ;-)


As a first step (and also the final one if implementing a common driver 
is not feasible) I thought of creating a common header/source file which 
implements all "re-useable" functions/macros/etc. Would that also be an 
accepted solution?





3. Currently only usb3503 supports "platform data". Is this still needed
or may it be removed?


I think it is still used, e.g. by:
arch/arm/boot/dts/exynos5250-spring.dts


Please correct me if I'm wrong, but isn't that DT only?

The reason why I'm asking if it may be removed is because the only file 
including "linux/platform_data/usb3503.h" is the usb3503.c driver itself 
and it's also the only file using "struct usb3503_platform_data".


Thanks & kind regards,
RichardL

[1] 
https://www.microchip.com/design-centers/usb/usb-hubs-and-devices/products/overview

--
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] USB: ehci-platform: fix companion-device leak

[Yoshihiro Shimoda]

Hi Johan,

> -Original Message-
> From: Johan Hovold
> Sent: Wednesday, May 17, 2017 6:00 PM
> 
> On Wed, May 17, 2017 at 04:53:07AM +, Yoshihiro Shimoda wrote:
> > Hi Johan,
> >
> > > From: Johan Hovold
> > > Sent: Tuesday, May 16, 2017 11:26 PM
> > >
> > > Make sure do drop the reference taken to the companion device during
> > > resume.
> > >
> > > Fixes: d4d75128b8fd ("usb: host: ehci-platform: fix usb 1.1 device is not 
> > > connected in system resume")
> > > Cc: stable  # 4.11
> > > Cc: Yoshihiro Shimoda 
> > > Signed-off-by: Johan Hovold 
> > > ---
> > >  drivers/usb/host/ehci-platform.c | 4 +++-
> > >  1 file changed, 3 insertions(+), 1 deletion(-)
> > >
> > > diff --git a/drivers/usb/host/ehci-platform.c 
> > > b/drivers/usb/host/ehci-platform.c
> > > index bc7b9be12f54..f1908ea9fbd8 100644
> > > --- a/drivers/usb/host/ehci-platform.c
> > > +++ b/drivers/usb/host/ehci-platform.c
> > > @@ -384,8 +384,10 @@ static int ehci_platform_resume(struct device *dev)
> > >   }
> > >
> > >   companion_dev = usb_of_get_companion_dev(hcd->self.controller);
> > > - if (companion_dev)
> > > + if (companion_dev) {
> > >   device_pm_wait_for_dev(hcd->self.controller, companion_dev);
> > > + put_device(companion_dev);
> >
> > Thank you for the patch!
> >
> > I should have added an API like "usb_of_put_companion_dev(dev)"
> > and it calls "of_dev_put(to_platform_device(dev))". And then,
> > ehci_platform_resume() can call the API instead of put_device().
> > But, adding new API is not good for stable.
> 
> I don't think that's needed or desirable. The helper returns a pointer
> to a struct device with an incremented refcount, so just using
> put_device() when done is the right thing to do.
> 
> Note that I added a comment about the refcount to the helper in patch
> 2/2 as a reminder for any future users.

Thank you for the reply!
I understood it and I agreed with you!

Best regards,
Yoshihiro Shimoda

--
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 v14 4/7] usb: core: add power sequence handling for USB devices

[Peter Chen]

Some hard-wired USB devices need to do power sequence to let the
device work normally, the typical power sequence like: enable USB
PHY clock, toggle reset pin, etc. But current Linux USB driver
lacks of such code to do it, it may cause some hard-wired USB devices
works abnormal or can't be recognized by controller at all.

In this patch, it calls power sequence library APIs to finish
the power sequence events. It will do power on sequence at hub's
probe for all devices under this hub (includes root hub).
At hub_disconnect, it will do power off sequence which is at powered
on list.

Signed-off-by: Peter Chen 
Tested-by Joshua Clayton 
Tested-by: Maciej S. Szmigiero 
Reviewed-by: Vaibhav Hiremath 
---
 drivers/usb/Kconfig|  1 +
 drivers/usb/core/hub.c | 49 +
 drivers/usb/core/hub.h |  1 +
 3 files changed, 47 insertions(+), 4 deletions(-)

diff --git a/drivers/usb/Kconfig b/drivers/usb/Kconfig
index 939a63b..b6f626e 100644
--- a/drivers/usb/Kconfig
+++ b/drivers/usb/Kconfig
@@ -39,6 +39,7 @@ config USB
tristate "Support for Host-side USB"
depends on USB_ARCH_HAS_HCD
select USB_COMMON
+   select POWER_SEQUENCE
select NLS  # for UTF-8 strings
---help---
  Universal Serial Bus (USB) is a specification for a serial bus
diff --git a/drivers/usb/core/hub.c b/drivers/usb/core/hub.c
index 9dca59e..7a67296 100644
--- a/drivers/usb/core/hub.c
+++ b/drivers/usb/core/hub.c
@@ -28,6 +28,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 #include 
@@ -1619,6 +1620,7 @@ static void hub_disconnect(struct usb_interface *intf)
hub->error = 0;
hub_quiesce(hub, HUB_DISCONNECT);
 
+   of_pwrseq_off_list(>pwrseq_on_list);
mutex_lock(_port_peer_mutex);
 
/* Avoid races with recursively_mark_NOTATTACHED() */
@@ -1646,12 +1648,42 @@ static void hub_disconnect(struct usb_interface *intf)
kref_put(>kref, hub_release);
 }
 
+#ifdef CONFIG_OF
+static int hub_of_pwrseq_on(struct usb_hub *hub)
+{
+   struct device *parent;
+   struct usb_device *hdev = hub->hdev;
+   struct device_node *np;
+   int ret;
+
+   if (hdev->parent)
+   parent = >dev;
+   else
+   parent = bus_to_hcd(hdev->bus)->self.sysdev;
+
+   for_each_child_of_node(parent->of_node, np) {
+   ret = of_pwrseq_on_list(np, >pwrseq_on_list);
+   /* Maybe no power sequence library is chosen */
+   if (ret && ret != -ENOENT)
+   return ret;
+   }
+
+   return 0;
+}
+#else
+static int hub_of_pwrseq_on(struct usb_hub *hub)
+{
+   return 0;
+}
+#endif
+
 static int hub_probe(struct usb_interface *intf, const struct usb_device_id 
*id)
 {
struct usb_host_interface *desc;
struct usb_endpoint_descriptor *endpoint;
struct usb_device *hdev;
struct usb_hub *hub;
+   int ret = -ENODEV;
 
desc = intf->cur_altsetting;
hdev = interface_to_usbdev(intf);
@@ -1756,6 +1788,7 @@ static int hub_probe(struct usb_interface *intf, const 
struct usb_device_id *id)
INIT_DELAYED_WORK(>leds, led_work);
INIT_DELAYED_WORK(>init_work, NULL);
INIT_WORK(>events, hub_event);
+   INIT_LIST_HEAD(>pwrseq_on_list);
usb_get_intf(intf);
usb_get_dev(hdev);
 
@@ -1769,11 +1802,14 @@ static int hub_probe(struct usb_interface *intf, const 
struct usb_device_id *id)
if (id->driver_info & HUB_QUIRK_CHECK_PORT_AUTOSUSPEND)
hub->quirk_check_port_auto_suspend = 1;
 
-   if (hub_configure(hub, endpoint) >= 0)
-   return 0;
+   if (hub_configure(hub, endpoint) >= 0) {
+   ret = hub_of_pwrseq_on(hub);
+   if (!ret)
+   return 0;
+   }
 
hub_disconnect(intf);
-   return -ENODEV;
+   return ret;
 }
 
 static int
@@ -3593,14 +3629,19 @@ static int hub_suspend(struct usb_interface *intf, 
pm_message_t msg)
 
/* stop hub_wq and related activity */
hub_quiesce(hub, HUB_SUSPEND);
-   return 0;
+   return pwrseq_suspend_list(>pwrseq_on_list);
 }
 
 static int hub_resume(struct usb_interface *intf)
 {
struct usb_hub *hub = usb_get_intfdata(intf);
+   int ret;
 
dev_dbg(>dev, "%s\n", __func__);
+   ret = pwrseq_resume_list(>pwrseq_on_list);
+   if (ret)
+   return ret;
+
hub_activate(hub, HUB_RESUME);
return 0;
 }
diff --git a/drivers/usb/core/hub.h b/drivers/usb/core/hub.h
index 34c1a7e..cd86f91 100644
--- a/drivers/usb/core/hub.h
+++ b/drivers/usb/core/hub.h
@@ -78,6 +78,7 @@ struct usb_hub {
struct delayed_work init_work;
struct work_struct  events;
struct usb_port **ports;
+   struct list_headpwrseq_on_list; /* powered pwrseq node 

[PATCH v14 2/7] power: add power sequence library

[Peter Chen]

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 
---
 Documentation/power/power-sequence/design.rst |  54 +
 MAINTAINERS   |   9 +
 drivers/power/Kconfig |   1 +
 drivers/power/Makefile|   1 +
 drivers/power/pwrseq/Kconfig  |  20 ++
 drivers/power/pwrseq/Makefile |   2 +
 drivers/power/pwrseq/core.c   | 335 ++
 drivers/power/pwrseq/pwrseq_generic.c | 234 ++
 include/linux/power/pwrseq.h  |  81 +++
 9 files changed, 737 insertions(+)
 create mode 100644 Documentation/power/power-sequence/design.rst
 create mode 100644 drivers/power/pwrseq/Kconfig
 create mode 100644 drivers/power/pwrseq/Makefile
 create mode 100644 drivers/power/pwrseq/core.c
 create mode 100644 drivers/power/pwrseq/pwrseq_generic.c
 create mode 100644 include/linux/power/pwrseq.h

diff --git a/Documentation/power/power-sequence/design.rst 
b/Documentation/power/power-sequence/design.rst
new file mode 100644
index 000..554608e
--- /dev/null
+++ b/Documentation/power/power-sequence/design.rst
@@ -0,0 +1,54 @@
+
+Power Sequence Library
+
+
+:Date: Feb, 2017
+:Author: Peter Chen 
+
+
+Introduction
+
+
+We have an well-known problem that the device needs to do a power
+sequence before it can be recognized by related host, the typical
+examples are hard-wired mmc devices and usb devices. The host controller
+can't know what kinds of this device is in its bus if the power
+sequence has not done, since the related devices driver's probe calling
+is determined by runtime according to eunumeration results. Besides,
+the devices may have custom power sequence, so the power sequence library
+which is independent with the devices is needed.
+
+Design
+
+
+The power sequence library includes the core file and customer power
+sequence library. The core file exports interfaces are called by
+host controller driver for power sequence and customer power sequence
+library files to register its power sequence instance to global
+power sequence list. The custom power sequence library creates power
+sequence instance and implement custom power sequence.
+
+Since the power sequence describes hardware design, the description is
+located at board description file, eg, device tree dts file. And
+a specific power sequence belongs to device, so its description
+is under the device node, please refer to:
+Documentation/devicetree/bindings/power/pwrseq/pwrseq-generic.txt
+
+Custom power sequence library allocates one power sequence instance at
+bootup periods using postcore_initcall, this static allocated instance is
+used to compare with device-tree (DT) node to see if this library can be
+used for the node or not. When the result is matched, the core API will
+try to get resourses (->get, implemented at each library) for power
+sequence, if all resources are got, it will try to allocate another
+instance for next possible request from host driver.
+
+Then, the host controller driver can carry out power sequence on for this
+DT node, the library will do corresponding operations, like open clocks,
+toggle gpio, etc. The power sequence off routine will close and free the
+resources, and is called when the parent is removed. And the power
+sequence suspend and resume routine can be called at host driver's
+suspend and resume routine if needed.
+
+The exported interfaces
+.. kernel-doc:: drivers/power/pwrseq/core.c
+   :export:
diff --git a/MAINTAINERS b/MAINTAINERS
index 

[PATCH v14 5/7] ARM: dts: imx6qdl: Enable usb node children with

[Peter Chen]

From: Joshua Clayton 

Give usb nodes #address and #size attributes, so that a child node
representing a permanently connected device such as an onboard hub may
be addressed with a  attribute

Signed-off-by: Joshua Clayton 
Signed-off-by: Peter Chen 
---
 arch/arm/boot/dts/imx6qdl.dtsi | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/arch/arm/boot/dts/imx6qdl.dtsi b/arch/arm/boot/dts/imx6qdl.dtsi
index e426faa..8c064cb 100644
--- a/arch/arm/boot/dts/imx6qdl.dtsi
+++ b/arch/arm/boot/dts/imx6qdl.dtsi
@@ -945,6 +945,8 @@
 
usbh1: usb@02184200 {
compatible = "fsl,imx6q-usb", "fsl,imx27-usb";
+   #address-cells = <1>;
+   #size-cells = <0>;
reg = <0x02184200 0x200>;
interrupts = <0 40 IRQ_TYPE_LEVEL_HIGH>;
clocks = < IMX6QDL_CLK_USBOH3>;
@@ -959,6 +961,8 @@
 
usbh2: usb@02184400 {
compatible = "fsl,imx6q-usb", "fsl,imx27-usb";
+   #address-cells = <1>;
+   #size-cells = <0>;
reg = <0x02184400 0x200>;
interrupts = <0 41 IRQ_TYPE_LEVEL_HIGH>;
clocks = < IMX6QDL_CLK_USBOH3>;
@@ -972,6 +976,8 @@
 
usbh3: usb@02184600 {
compatible = "fsl,imx6q-usb", "fsl,imx27-usb";
+   #address-cells = <1>;
+   #size-cells = <0>;
reg = <0x02184600 0x200>;
interrupts = <0 42 IRQ_TYPE_LEVEL_HIGH>;
clocks = < IMX6QDL_CLK_USBOH3>;
-- 
2.7.4

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

[PATCH v14 7/7] ARM: dts: imx6q-evi: Fix onboard hub reset line

[Peter Chen]

From: Joshua Clayton 

Previously the onboard hub was made to work by treating its
reset gpio as a regulator enable.
Get rid of that kludge now that pwseq has added reset gpio support
Move pin muxing the hub reset pin into the usbh1 group

Signed-off-by: Joshua Clayton 
Signed-off-by: Peter Chen 
---
 arch/arm/boot/dts/imx6q-evi.dts | 25 +++--
 1 file changed, 7 insertions(+), 18 deletions(-)

diff --git a/arch/arm/boot/dts/imx6q-evi.dts b/arch/arm/boot/dts/imx6q-evi.dts
index fd2220a..24fe093 100644
--- a/arch/arm/boot/dts/imx6q-evi.dts
+++ b/arch/arm/boot/dts/imx6q-evi.dts
@@ -54,18 +54,6 @@
reg = <0x1000 0x4000>;
};
 
-   reg_usbh1_vbus: regulator-usbhubreset {
-   compatible = "regulator-fixed";
-   regulator-name = "usbh1_vbus";
-   regulator-min-microvolt = <500>;
-   regulator-max-microvolt = <500>;
-   enable-active-high;
-   startup-delay-us = <2>;
-   pinctrl-names = "default";
-   pinctrl-0 = <_usbh1_hubreset>;
-   gpio = < 12 GPIO_ACTIVE_HIGH>;
-   };
-
reg_usb_otg_vbus: regulator-usbotgvbus {
compatible = "regulator-fixed";
regulator-name = "usb_otg_vbus";
@@ -204,12 +192,18 @@
 };
 
  {
-   vbus-supply = <_usbh1_vbus>;
pinctrl-names = "default";
pinctrl-0 = <_usbh1>;
dr_mode = "host";
disable-over-current;
status = "okay";
+
+   usb2415host: hub@1 {
+   compatible = "usb424,2513";
+   reg = <1>;
+   reset-gpios = < 12 GPIO_ACTIVE_LOW>;
+   reset-duration-us = <3000>;
+   };
 };
 
  {
@@ -465,11 +459,6 @@
MX6QDL_PAD_GPIO_3__USB_H1_OC 0x1b0b0
/* usbh1_b OC */
MX6QDL_PAD_GPIO_0__GPIO1_IO00 0x1b0b0
-   >;
-   };
-
-   pinctrl_usbh1_hubreset: usbh1hubresetgrp {
-   fsl,pins = <
MX6QDL_PAD_GPIO_17__GPIO7_IO12 0x1b0b0
>;
};
-- 
2.7.4

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

[PATCH v14 6/7] ARM: dts: imx6qdl-udoo.dtsi: fix onboard USB HUB property

[Peter Chen]

The current dts describes USB HUB's property at USB controller's
entry, it is improper. The USB HUB should be the child node
under USB controller, and power sequence properties are under
it. Besides, using gpio pinctrl setting for USB2415's reset pin.

Signed-off-by: Peter Chen 
Signed-off-by: Joshua Clayton 
Tested-by: Maciej S. Szmigiero 
---
 arch/arm/boot/dts/imx6qdl-udoo.dtsi | 26 --
 1 file changed, 12 insertions(+), 14 deletions(-)

diff --git a/arch/arm/boot/dts/imx6qdl-udoo.dtsi 
b/arch/arm/boot/dts/imx6qdl-udoo.dtsi
index c96c91d..a173de2 100644
--- a/arch/arm/boot/dts/imx6qdl-udoo.dtsi
+++ b/arch/arm/boot/dts/imx6qdl-udoo.dtsi
@@ -9,6 +9,8 @@
  *
  */
 
+#include 
+
 / {
aliases {
backlight = 
@@ -58,17 +60,6 @@
#address-cells = <1>;
#size-cells = <0>;
 
-   reg_usb_h1_vbus: regulator@0 {
-   compatible = "regulator-fixed";
-   reg = <0>;
-   regulator-name = "usb_h1_vbus";
-   regulator-min-microvolt = <500>;
-   regulator-max-microvolt = <500>;
-   enable-active-high;
-   startup-delay-us = <2>; /* USB2415 requires a POR of 1 
us minimum */
-   gpio = < 12 0>;
-   };
-
reg_panel: regulator@1 {
compatible = "regulator-fixed";
reg = <1>;
@@ -188,7 +179,7 @@
 
pinctrl_usbh: usbhgrp {
fsl,pins = <
-   MX6QDL_PAD_GPIO_17__GPIO7_IO12 0x8000
+   MX6QDL_PAD_GPIO_17__GPIO7_IO12  0x1b0b0
MX6QDL_PAD_NANDF_CS2__CCM_CLKO2 0x130b0
>;
};
@@ -259,9 +250,16 @@
  {
pinctrl-names = "default";
pinctrl-0 = <_usbh>;
-   vbus-supply = <_usb_h1_vbus>;
-   clocks = < IMX6QDL_CLK_CKO>;
status = "okay";
+
+   usb2415: hub@1 {
+   compatible = "usb424,2514";
+   reg = <1>;
+
+   clocks = < IMX6QDL_CLK_CKO>;
+   reset-gpios = < 12 GPIO_ACTIVE_LOW>;
+   reset-duration-us = <3000>;
+   };
 };
 
  {
-- 
2.7.4

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

[PATCH v14 3/7] binding-doc: usb: usb-device: add optional properties for power sequence

[Peter Chen]

Add optional properties for power sequence.

Signed-off-by: Peter Chen 
Acked-by: Rob Herring 
---
 Documentation/devicetree/bindings/usb/usb-device.txt | 10 +-
 1 file changed, 9 insertions(+), 1 deletion(-)

diff --git a/Documentation/devicetree/bindings/usb/usb-device.txt 
b/Documentation/devicetree/bindings/usb/usb-device.txt
index 1c35e7b..3661dd2 100644
--- a/Documentation/devicetree/bindings/usb/usb-device.txt
+++ b/Documentation/devicetree/bindings/usb/usb-device.txt
@@ -13,6 +13,10 @@ Required properties:
 - reg: the port number which this device is connecting to, the range
   is 1-31.
 
+Optional properties:
+power sequence properties, see
+Documentation/devicetree/bindings/power/pwrseq/pwrseq-generic.txt for detail
+
 Example:
 
  {
@@ -21,8 +25,12 @@ Example:
#address-cells = <1>;
#size-cells = <0>;
 
-   hub: genesys@1 {
+   genesys: hub@1 {
compatible = "usb5e3,608";
reg = <1>;
+
+   clocks = < IMX6SX_CLK_CKO>;
+   reset-gpios = < 5 GPIO_ACTIVE_LOW>; /* hub reset pin */
+   reset-duration-us = <10>;
};
 }
-- 
2.7.4

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

[PATCH v14 1/7] binding-doc: power: pwrseq-generic: add binding doc for generic power sequence library

[Peter Chen]

Add binding doc for generic power sequence library.

Signed-off-by: Peter Chen 
Acked-by: Philipp Zabel 
Acked-by: Rob Herring 
---
 .../bindings/power/pwrseq/pwrseq-generic.txt   | 48 ++
 1 file changed, 48 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/power/pwrseq/pwrseq-generic.txt

diff --git a/Documentation/devicetree/bindings/power/pwrseq/pwrseq-generic.txt 
b/Documentation/devicetree/bindings/power/pwrseq/pwrseq-generic.txt
new file mode 100644
index 000..ebf0d47
--- /dev/null
+++ b/Documentation/devicetree/bindings/power/pwrseq/pwrseq-generic.txt
@@ -0,0 +1,48 @@
+The generic power sequence library
+
+Some hard-wired devices (eg USB/MMC) need to do power sequence before
+the device can be enumerated on the bus, the typical power sequence
+like: enable USB PHY clock, toggle reset pin, etc. But current
+Linux device driver lacks of such code to do it, it may cause some
+hard-wired devices works abnormal or can't be recognized by
+controller at all. The power sequence will be done before this device
+can be found at the bus.
+
+The power sequence properties is under the device node.
+
+Optional properties:
+- clocks: the input clocks for device.
+- reset-gpios: Should specify the GPIO for reset.
+- reset-duration-us: the duration in microsecond for assert reset signal.
+
+Below is the example of USB power sequence properties on USB device
+nodes which have two level USB hubs.
+
+ {
+   vbus-supply = <_usb_otg1_vbus>;
+   pinctrl-names = "default";
+   pinctrl-0 = <_usb_otg1_id>;
+   status = "okay";
+
+   #address-cells = <1>;
+   #size-cells = <0>;
+   genesys: hub@1 {
+   compatible = "usb5e3,608";
+   reg = <1>;
+
+   clocks = < IMX6SX_CLK_CKO>;
+   reset-gpios = < 5 GPIO_ACTIVE_LOW>; /* hub reset pin */
+   reset-duration-us = <10>;
+
+   #address-cells = <1>;
+   #size-cells = <0>;
+   asix: ethernet@1 {
+   compatible = "usbb95,1708";
+   reg = <1>;
+
+   clocks = < IMX6SX_CLK_IPG>;
+   reset-gpios = < 6 GPIO_ACTIVE_LOW>; /* 
ethernet_rst */
+   reset-duration-us = <15>;
+   };
+   };
+};
-- 
2.7.4

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

[PATCH v14 0/7] power: add power sequence library

[Peter Chen]

This is a follow-up for my last power sequence framework patch set [1].
According to Rob Herring and Ulf Hansson's comments[2]. The kinds of
power sequence instances will be added at postcore_initcall, the match
criteria is compatible string first, if the compatible string is not
matched between dts and library, it will try to use generic power sequence.
 
The host driver just needs to call of_pwrseq_on/of_pwrseq_off
if only one power sequence instance is needed, for more power sequences
are used, using of_pwrseq_on_list/of_pwrseq_off_list instead (eg, USB hub 
driver).

In future, if there are special power sequence requirements, the special
power sequence library can be created.

This patch set is tested on i.mx6 sabresx evk using a dts change, I use
two hot-plug devices to simulate this use case, the related binding
change is updated at patch [1/6], The udoo board changes were tested
using my last power sequence patch set.[3]

Except for hard-wired MMC and USB devices, I find the USB ULPI PHY also
need to power on itself before it can be found by ULPI bus.

Changes for v14:
- Rebase for v4.12-rc1
- Delete some USB sysdev patches which has already merged

Changes for v13:
- Add more design descriptions at design doc and fix one build error
  introduced by v12 wrongly [Patch 2/12]
- Add the last three dts patches which were forgotten at last series
- Move the comment for usb_create_shared_hcd to correct place [Patch 3/12]
- Add sysdev for shared hcd too for xhci-plat.c [Patch 6/12]

Rafael, if the first two power sequence patches are ok for you, would you 
consider
accept these first, the other USB patches can go through USB tree at v4.12-rc1?

Changes for v12:
- Add design doc and more comments at generic power sequence source file [Patch 
2/9]
- Introduce four Arnd Bergmann patches and one my ehci related patches, these 
patches
  are used to get property DT/firmware information at USB code, and these 
information
  are needed for power sequence operation at USB. With these five patches, my 
chipidea
  hack patch in previous patch set can be removed. [Patch 3-7/9]
- Add -ENOENT judgement to avoid USB error if no power sequence library is 
chosen [9/9]

Changes for v11:
- Fix warning: (USB) selects POWER_SEQUENCE which has unmet direct dependencies 
(OF)
- Delete redundant copyright statement.
- Change pr_warn to pr_debug at wrseq_find_available_instance
- Refine kerneldoc
- %s/ENONET/ENOENT 
- Allocate pwrseq list node before than carry out power sequence on 
- Add mutex_lock/mutex_lock for pwrseq node browse at 
pwrseq_find_available_instance
- Add pwrseq_suspend/resume for API both single instance and list 
- Add .pwrseq_suspend/resume for pwrseq_generic.c
- Add pwrseq_suspend_list and pwrseq_resume_list for USB hub suspend
  and resume routine

Changes for v10:
- Improve the kernel-doc for power sequence core, including exported APIs and
  main structure. [Patch 2/8]
- Change Kconfig, and let the user choose power sequence. [Patch 2/8]
- Delete EXPORT_SYMBOL and change related APIs as local, these APIs do not
  be intended to export currently. [Patch 2/8]
- Selete POWER_SEQUENCE at USB core's Kconfig. [Patch 4/8]

Changes for v9:
- Add Vaibhav Hiremath's reviewed-by [Patch 4/8]
- Rebase to v4.9-rc1

Changes for v8:
- Allocate one extra pwrseq instance if pwrseq_get has succeed, it can avoid
  preallocate instances problem which the number of instance is decided at
  compile time, thanks for Heiko Stuebner's suggestion [Patch 2/8]
- Delete pwrseq_compatible_sample.c which is the demo purpose to show compatible
  match method. [Patch 2/8]
- Add Maciej S. Szmigiero's tested-by. [Patch 7/8]

Changes for v7:
- Create kinds of power sequence instance at postcore_initcall, and match
  the instance with node using compatible string, the beneit of this is
  the host driver doesn't need to consider which pwrseq instance needs
  to be used, and pwrseq core will match it, however, it eats some memories
  if less power sequence instances are used. [Patch 2/8]
- Add pwrseq_compatible_sample.c to test match pwrseq using device_id. [Patch 
2/8]
- Fix the comments Vaibhav Hiremath adds for error path for clock and do not
  use device_node for parameters at pwrseq_on. [Patch 2/8]
- Simplify the caller to use power sequence, follows Alan's commnets [Patch 4/8]
- Tested three pwrseq instances together using both specific compatible string 
and
  generic libraries.

Changes for v6:
- Add Matthias Kaehlcke's Reviewed-by and Tested-by. (patch [2/6])
- Change chipidea core of_node assignment for coming user. (patch [5/6])
- Applies Joshua Clayton's three dts changes for two boards,
  the USB device's reg has only #address-cells, but without #size-cells.

Changes for v5:
- Delete pwrseq_register/pwrseq_unregister, which is useless currently
- Fix the linker error when the pwrseq user is compiled as module

Changes for v4:
- Create the patch on next-20160722 
- Fix the of_node is not NULL after chipidea driver is 

[PATCH 0/4] Make ohci-platform usable for omap3/4/5

[Tony Lindgren]

Hi all,

Here are patches I promised several months ago so we can eventually
get rid of ohci-omap3 in favor of ohci-platform as suggested by
Alan Stern.

I think we need to wait a while before removing ohci-omap3, so
I just added a warning for now to urge people to move to use
ohci-platform instead.

Regards,

Tony

Tony Lindgren (4):
  usb: host: ohci-platform: Add basic runtime PM support
  usb: host: ohci-platform: Add support for omap3 and later
  usb: host: ohci-omap3: Print warning to get people to use
ohci-platform
  ARM: dts: Add remote-wakeup-connected for omap OHCI

 Documentation/devicetree/bindings/usb/usb-ohci.txt |  1 +
 arch/arm/boot/dts/omap3.dtsi   |  1 +
 arch/arm/boot/dts/omap4.dtsi   |  1 +
 arch/arm/boot/dts/omap5.dtsi   |  1 +
 drivers/usb/host/ohci-omap3.c  |  3 +++
 drivers/usb/host/ohci-platform.c   | 16 
 6 files changed, 23 insertions(+)

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

[PATCH 1/4] usb: host: ohci-platform: Add basic runtime PM support

[Tony Lindgren]

This is needed in preparation of adding support for omap3 and
later OHCI. The runtime PM will only do something on platforms
that implement it.

Cc: devicet...@vger.kernel.org
Cc: Hans de Goede 
Cc: Rob Herring 
Cc: Roger Quadros 
Cc: Yoshihiro Shimoda 
Signed-off-by: Tony Lindgren 
---
 drivers/usb/host/ohci-platform.c | 11 +++
 1 file changed, 11 insertions(+)

diff --git a/drivers/usb/host/ohci-platform.c b/drivers/usb/host/ohci-platform.c
--- a/drivers/usb/host/ohci-platform.c
+++ b/drivers/usb/host/ohci-platform.c
@@ -24,6 +24,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -51,6 +52,10 @@ static int ohci_platform_power_on(struct platform_device 
*dev)
struct ohci_platform_priv *priv = hcd_to_ohci_priv(hcd);
int clk, ret, phy_num;
 
+   ret = pm_runtime_get_sync(>dev);
+   if (ret < 0)
+   return ret;
+
for (clk = 0; clk < OHCI_MAX_CLKS && priv->clks[clk]; clk++) {
ret = clk_prepare_enable(priv->clks[clk]);
if (ret)
@@ -96,6 +101,8 @@ static void ohci_platform_power_off(struct platform_device 
*dev)
for (clk = OHCI_MAX_CLKS - 1; clk >= 0; clk--)
if (priv->clks[clk])
clk_disable_unprepare(priv->clks[clk]);
+
+   pm_runtime_put_sync(>dev);
 }
 
 static struct hc_driver __read_mostly ohci_platform_hc_driver;
@@ -242,6 +249,7 @@ static int ohci_platform_probe(struct platform_device *dev)
}
 #endif
 
+   pm_runtime_enable(>dev);
if (pdata->power_on) {
err = pdata->power_on(dev);
if (err < 0)
@@ -271,6 +279,7 @@ static int ohci_platform_probe(struct platform_device *dev)
if (pdata->power_off)
pdata->power_off(dev);
 err_reset:
+   pm_runtime_disable(>dev);
while (--rst >= 0)
reset_control_assert(priv->resets[rst]);
 err_put_clks:
@@ -305,6 +314,8 @@ static int ohci_platform_remove(struct platform_device *dev)
 
usb_put_hcd(hcd);
 
+   pm_runtime_disable(>dev);
+
if (pdata == _platform_defaults)
dev->dev.platform_data = NULL;
 
-- 
2.13.0
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 4/4] ARM: dts: Add remote-wakeup-connected for omap OHCI

[Tony Lindgren]

Add remote-wakeup-connected for omap OHCI as that's needed by
ehci-platform driver.

Cc: devicet...@vger.kernel.org
Cc: Hans de Goede 
Cc: Rob Herring 
Cc: Roger Quadros 
Cc: Yoshihiro Shimoda 
Signed-off-by: Tony Lindgren 
---
 arch/arm/boot/dts/omap3.dtsi | 1 +
 arch/arm/boot/dts/omap4.dtsi | 1 +
 arch/arm/boot/dts/omap5.dtsi | 1 +
 3 files changed, 3 insertions(+)

diff --git a/arch/arm/boot/dts/omap3.dtsi b/arch/arm/boot/dts/omap3.dtsi
--- a/arch/arm/boot/dts/omap3.dtsi
+++ b/arch/arm/boot/dts/omap3.dtsi
@@ -715,6 +715,7 @@
reg = <0x48064400 0x400>;
interrupt-parent = <>;
interrupts = <76>;
+   remote-wakeup-connected;
};
 
usbhsehci: ehci@48064800 {
diff --git a/arch/arm/boot/dts/omap4.dtsi b/arch/arm/boot/dts/omap4.dtsi
--- a/arch/arm/boot/dts/omap4.dtsi
+++ b/arch/arm/boot/dts/omap4.dtsi
@@ -863,6 +863,7 @@
reg = <0x4a064800 0x400>;
interrupt-parent = <>;
interrupts = ;
+   remote-wakeup-connected;
};
 
usbhsehci: ehci@4a064c00 {
diff --git a/arch/arm/boot/dts/omap5.dtsi b/arch/arm/boot/dts/omap5.dtsi
--- a/arch/arm/boot/dts/omap5.dtsi
+++ b/arch/arm/boot/dts/omap5.dtsi
@@ -939,6 +939,7 @@
compatible = "ti,ohci-omap3";
reg = <0x4a064800 0x400>;
interrupts = ;
+   remote-wakeup-connected;
};
 
usbhsehci: ehci@4a064c00 {
-- 
2.13.0
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 3/4] usb: host: ohci-omap3: Print warning to get people to use ohci-platform

[Tony Lindgren]

We can't just remove ohci-omap3 as that could make some people's
systems unusable for keyboard and mouse. Let's print a warning for
now, and then remove the driver in a year or so.

Cc: Hans de Goede 
Cc: Rob Herring 
Cc: Roger Quadros 
Cc: Yoshihiro Shimoda 
Signed-off-by: Tony Lindgren 
---
 drivers/usb/host/ohci-omap3.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/usb/host/ohci-omap3.c b/drivers/usb/host/ohci-omap3.c
--- a/drivers/usb/host/ohci-omap3.c
+++ b/drivers/usb/host/ohci-omap3.c
@@ -130,6 +130,9 @@ static int ohci_hcd_omap3_probe(struct platform_device 
*pdev)
dev_dbg(dev, "failed to add hcd with err %d\n", ret);
goto err_add_hcd;
}
+
+   WARN(1, "ohci-omap3 is deprecated, please use ohci-platform instead\n");
+
device_wakeup_enable(hcd->self.controller);
 
return 0;
-- 
2.13.0
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 2/4] usb: host: ohci-platform: Add support for omap3 and later

[Tony Lindgren]

With the runtime PM implemented for ohci-platform driver, we can
now support omap3 and later OHCI by adding one device tree
property.

Cc: Hans de Goede 
Cc: Rob Herring 
Cc: Roger Quadros 
Cc: Yoshihiro Shimoda 
Signed-off-by: Tony Lindgren 
---
 Documentation/devicetree/bindings/usb/usb-ohci.txt | 1 +
 drivers/usb/host/ohci-platform.c   | 5 +
 2 files changed, 6 insertions(+)

diff --git a/Documentation/devicetree/bindings/usb/usb-ohci.txt 
b/Documentation/devicetree/bindings/usb/usb-ohci.txt
--- a/Documentation/devicetree/bindings/usb/usb-ohci.txt
+++ b/Documentation/devicetree/bindings/usb/usb-ohci.txt
@@ -10,6 +10,7 @@ Optional properties:
 - big-endian-desc : boolean, set this for hcds with big-endian descriptors
 - big-endian : boolean, for hcds with big-endian-regs + big-endian-desc
 - no-big-frame-no : boolean, set if frame_no lives in bits [15:0] of HCCA
+- remote-wakeup-connected: remote wakeup is wired on the platform
 - num-ports : u32, to override the detected port count
 - clocks : a list of phandle + clock specifier pairs
 - phys : phandle + phy specifier pair
diff --git a/drivers/usb/host/ohci-platform.c b/drivers/usb/host/ohci-platform.c
--- a/drivers/usb/host/ohci-platform.c
+++ b/drivers/usb/host/ohci-platform.c
@@ -170,6 +170,10 @@ static int ohci_platform_probe(struct platform_device *dev)
if (of_property_read_bool(dev->dev.of_node, "no-big-frame-no"))
ohci->flags |= OHCI_QUIRK_FRAME_NO;
 
+   if (of_property_read_bool(dev->dev.of_node,
+ "remote-wakeup-connected"))
+   ohci->hc_control = OHCI_CTRL_RWC;
+
of_property_read_u32(dev->dev.of_node, "num-ports",
 >num_ports);
 
@@ -361,6 +365,7 @@ static int ohci_platform_resume(struct device *dev)
 static const struct of_device_id ohci_platform_ids[] = {
{ .compatible = "generic-ohci", },
{ .compatible = "cavium,octeon-6335-ohci", },
+   { .compatible = "ti,ohci-omap3", },
{ }
 };
 MODULE_DEVICE_TABLE(of, ohci_platform_ids);
-- 
2.13.0
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v4 0/3] USB Audio Gadget refactoring

[Ruslan Bilovol]

I came to this patch series when wanted to do two things:
 - use UAC1 as virtual ALSA sound card on gadget side,
   just like UAC2 is used so it's possible to do rate
   resampling
 - have both playback/capture support in UAC1

Since I wanted to have same behavior for both UAC1/UAC2,
obviously I've got an utility part (u_audio.c) for
virtual ALSA sound card handling like we have
for ethernet(u_ether) or serial(u_serial) functions.
Function-specific parts (f_uac1/f_uac2) became almost 
as storage for class-specific USB descriptors, some
boilerplate for configfs, binding and few USB
config request handling.

Originally in RFC [1] I've posted before, there was
major change to f_uac1 after that it couldn't do
direct play to existing ALSA sound card anymore,
representing audio on gadget side as virtual
ALSA sound card where audio streams are simply
sinked to and sourced from it, so it may break
current usecase for some people (and that's why
it was RFC).

During RFC discussion, it was agreed to not touch
existing f_uac1 implementation and create new one
instead. This patchset (v4) introduced new function
named f_uac1_acard and doesn't touch current f_uac1
implementation, so people still can use old behavior

Now, it's possible to use existing user-space
applications for audio routing between Audio Gadget
and real sound card. I personally use alsaloop tool
from alsautils and have ability to create PCM
loopback between two different ALSA cards using
rate resampling, which was not possible with previous
"direct play to ALSA card" approach in f_uac1. 

While here, also dropped redundant platform
driver/device creation in f_uac2 driver (as well as
didn't add "never implemented" volume/mute functionality
in f_uac1 to f_uac1_acard) that made this work even
easier to do.

This series is tested with both legacy g_audio.ko and
modern configfs approaches under Ubuntu 14.04 (UAC1 and
UAC2) and under Windows7 x64 (UAC1 only) having
perfect results in all cases.

Comments, testing are welcome.

v4 changes:
 - renamed f_uac1_newapi to f_uac1_acard that is
   more meaningful
 - rebased on top of balbi/next

v3 changes:
 - renamed u_audio exported symbols so they don't
   conflict with old f_uac1 if both are built-in.

v2 changes:
 - do not touch f_uac1, instead created f_uac1_newapi
 - added documentation for f_uac1_newapi
 - rebased on top of v4.8-rc1

[1] https://lkml.org/lkml/2016/5/23/649

Ruslan Bilovol (3):
  usb: gadget: f_uac2: remove platform driver/device creation
  usb: gadget: f_uac2: split out audio core
  usb: gadget: add f_uac1 variant based on a new u_audio api

 .../ABI/testing/configfs-usb-gadget-uac1_acard |  14 +
 Documentation/usb/gadget-testing.txt   |  45 ++
 drivers/usb/gadget/Kconfig |  25 +
 drivers/usb/gadget/function/Makefile   |   3 +
 drivers/usb/gadget/function/f_uac1_acard.c | 803 +
 drivers/usb/gadget/function/f_uac2.c   | 798 +++-
 drivers/usb/gadget/function/u_audio.c  | 661 +
 drivers/usb/gadget/function/u_audio.h  |  95 +++
 drivers/usb/gadget/function/u_uac1_acard.h |  41 ++
 drivers/usb/gadget/legacy/Kconfig  |  14 +-
 drivers/usb/gadget/legacy/audio.c  |  53 ++
 11 files changed, 1850 insertions(+), 702 deletions(-)
 create mode 100644 Documentation/ABI/testing/configfs-usb-gadget-uac1_acard
 create mode 100644 drivers/usb/gadget/function/f_uac1_acard.c
 create mode 100644 drivers/usb/gadget/function/u_audio.c
 create mode 100644 drivers/usb/gadget/function/u_audio.h
 create mode 100644 drivers/usb/gadget/function/u_uac1_acard.h

-- 
1.9.1

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

[PATCH v4 2/3] usb: gadget: f_uac2: split out audio core

[Ruslan Bilovol]

Abstract the peripheral side ALSA sound card code from
the f_uac2 function into a component that can be called
by various functions, so the various flavors can be split
apart and selectively reused.

Visible changes:
 - add uac_params structure to pass audio paramteres for
   g_audio_setup
 - make ALSA sound card's name configurable
 - add [in/out]_ep_maxpsize
 - allocate snd_uac_chip structure during g_audio_setup
 - add u_audio_[start/stop]_[capture/playback] functions

Signed-off-by: Ruslan Bilovol 
---
 drivers/usb/gadget/Kconfig|   4 +
 drivers/usb/gadget/function/Makefile  |   1 +
 drivers/usb/gadget/function/f_uac2.c  | 721 --
 drivers/usb/gadget/function/u_audio.c | 661 +++
 drivers/usb/gadget/function/u_audio.h |  95 +
 drivers/usb/gadget/legacy/Kconfig |   1 +
 6 files changed, 846 insertions(+), 637 deletions(-)
 create mode 100644 drivers/usb/gadget/function/u_audio.c
 create mode 100644 drivers/usb/gadget/function/u_audio.h

diff --git a/drivers/usb/gadget/Kconfig b/drivers/usb/gadget/Kconfig
index c164d6b..2ba0ace 100644
--- a/drivers/usb/gadget/Kconfig
+++ b/drivers/usb/gadget/Kconfig
@@ -158,6 +158,9 @@ config USB_U_SERIAL
 config USB_U_ETHER
tristate
 
+config USB_U_AUDIO
+   tristate
+
 config USB_F_SERIAL
tristate
 
@@ -381,6 +384,7 @@ config USB_CONFIGFS_F_UAC2
depends on SND
select USB_LIBCOMPOSITE
select SND_PCM
+   select USB_U_AUDIO
select USB_F_UAC2
help
  This Audio function is compatible with USB Audio Class
diff --git a/drivers/usb/gadget/function/Makefile 
b/drivers/usb/gadget/function/Makefile
index cb8c225..b29f2ae 100644
--- a/drivers/usb/gadget/function/Makefile
+++ b/drivers/usb/gadget/function/Makefile
@@ -32,6 +32,7 @@ usb_f_mass_storage-y  := f_mass_storage.o 
storage_common.o
 obj-$(CONFIG_USB_F_MASS_STORAGE)+= usb_f_mass_storage.o
 usb_f_fs-y := f_fs.o
 obj-$(CONFIG_USB_F_FS) += usb_f_fs.o
+obj-$(CONFIG_USB_U_AUDIO)  += u_audio.o
 usb_f_uac1-y   := f_uac1.o u_uac1.o
 obj-$(CONFIG_USB_F_UAC1)   += usb_f_uac1.o
 usb_f_uac2-y   := f_uac2.o
diff --git a/drivers/usb/gadget/function/f_uac2.c 
b/drivers/usb/gadget/function/f_uac2.c
index d4565b5..059a14a 100644
--- a/drivers/usb/gadget/function/f_uac2.c
+++ b/drivers/usb/gadget/function/f_uac2.c
@@ -15,10 +15,7 @@
 #include 
 #include 
 
-#include 
-#include 
-#include 
-
+#include "u_audio.h"
 #include "u_uac2.h"
 
 /*
@@ -50,455 +47,23 @@
 #define UNFLW_CTRL 8
 #define OVFLW_CTRL 10
 
-struct uac2_req {
-   struct uac2_rtd_params *pp; /* parent param */
-   struct usb_request *req;
-};
-
-struct uac2_rtd_params {
-   struct snd_uac2_chip *uac2; /* parent chip */
-   bool ep_enabled; /* if the ep is enabled */
-   /* Size of the ring buffer */
-   size_t dma_bytes;
-   unsigned char *dma_area;
-
-   struct snd_pcm_substream *ss;
-
-   /* Ring buffer */
-   ssize_t hw_ptr;
-
-   void *rbuf;
-
-   size_t period_size;
-
-   unsigned max_psize;
-   struct uac2_req *ureq;
-
-   spinlock_t lock;
-};
-
-struct snd_uac2_chip {
-   struct uac2_rtd_params p_prm;
-   struct uac2_rtd_params c_prm;
-
-   struct snd_card *card;
-   struct snd_pcm *pcm;
-
-   /* timekeeping for the playback endpoint */
-   unsigned int p_interval;
-   unsigned int p_residue;
-
-   /* pre-calculated values for playback iso completion */
-   unsigned int p_pktsize;
-   unsigned int p_pktsize_residue;
-   unsigned int p_framesize;
+struct f_uac2 {
+   struct g_audio g_audio;
+   u8 ac_intf, as_in_intf, as_out_intf;
+   u8 ac_alt, as_in_alt, as_out_alt;   /* needed for get_alt() */
 };
 
-#define BUFF_SIZE_MAX  (PAGE_SIZE * 16)
-#define PRD_SIZE_MAX   PAGE_SIZE
-#define MIN_PERIODS4
-
-static struct snd_pcm_hardware uac2_pcm_hardware = {
-   .info = SNDRV_PCM_INFO_INTERLEAVED | SNDRV_PCM_INFO_BLOCK_TRANSFER
-| SNDRV_PCM_INFO_MMAP | SNDRV_PCM_INFO_MMAP_VALID
-| SNDRV_PCM_INFO_PAUSE | SNDRV_PCM_INFO_RESUME,
-   .rates = SNDRV_PCM_RATE_CONTINUOUS,
-   .periods_max = BUFF_SIZE_MAX / PRD_SIZE_MAX,
-   .buffer_bytes_max = BUFF_SIZE_MAX,
-   .period_bytes_max = PRD_SIZE_MAX,
-   .periods_min = MIN_PERIODS,
-};
-
-struct audio_dev {
-   u8 ac_intf, ac_alt;
-   u8 as_out_intf, as_out_alt;
-   u8 as_in_intf, as_in_alt;
-
-   struct usb_ep *in_ep, *out_ep;
-   struct usb_function func;
-   struct usb_gadget *gadget;
-
-   /* The ALSA Sound Card it represents on the USB-Client side */
-   struct snd_uac2_chip uac2;
-};
-
-static inline
-struct audio_dev *func_to_agdev(struct usb_function *f)
+static inline struct f_uac2 *func_to_uac2(struct usb_function *f)
 {
-   return container_of(f, struct 

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

[Ruslan Bilovol]

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

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

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

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

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

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

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

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

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

diff --git a/Documentation/ABI/testing/configfs-usb-gadget-uac1_acard 
b/Documentation/ABI/testing/configfs-usb-gadget-uac1_acard
new file mode 100644
index 000..2cffeaa
--- /dev/null
+++ b/Documentation/ABI/testing/configfs-usb-gadget-uac1_acard
@@ -0,0 +1,14 @@
+What:  /config/usb-gadget/gadget/functions/uac1_acard.name
+Date:  May 2017
+KernelVersion: 4.13
+Description:
+   The attributes:
+
+   c_chmask - capture channel mask
+   c_srate - capture sampling rate
+   c_ssize - capture sample size (bytes)
+   p_chmask - playback channel mask
+   p_srate - playback sampling rate
+   p_ssize - playback sample size (bytes)
+   req_number - the number of pre-allocated request
+   for both capture and playback
diff --git a/Documentation/usb/gadget-testing.txt 
b/Documentation/usb/gadget-testing.txt
index fb0cc4d..ecff3ec 100644
--- a/Documentation/usb/gadget-testing.txt
+++ b/Documentation/usb/gadget-testing.txt
@@ -20,6 +20,7 @@ provided by gadgets.
 17. UAC2 function
 18. UVC function
 19. PRINTER function
+20. UAC1 function (new API)
 
 
 1. ACM function
@@ -772,3 +773,47 @@ host:
 
 More advanced testing can be done with the prn_example
 described in Documentation/usb/gadget-printer.txt.
+
+
+20. UAC1 function (virtual ALSA card, using u_audio API)
+=
+
+The function is provided by usb_f_uac1_acard.ko module.
+It will create a virtual ALSA card and the audio streams are simply
+sinked to and sourced from it.
+
+Function-specific configfs interface
+
+
+The function name to use when creating the function directory
+is "uac1_acard". The uac1_acard function provides these attributes
+in its function directory:
+
+   c_chmask - capture channel mask
+   c_srate - capture sampling rate
+   c_ssize - capture sample size (bytes)
+   p_chmask - playback channel mask
+   p_srate - playback sampling rate
+   p_ssize - playback sample size (bytes)
+   req_number - the number of pre-allocated request for both capture
+and playback
+
+The attributes have sane default values.
+
+Testing the UAC1 function
+-
+
+device: run the gadget
+host: aplay -l # should list our USB Audio Gadget
+
+This function does not require real hardware support, it just
+sends a stream of audio data to/from the 

[PATCH v4 1/3] usb: gadget: f_uac2: remove platform driver/device creation

[Ruslan Bilovol]

Simplify f_uac2 by removing platform driver/device
creation; use composite's usb_gadget device as
parent for sound card and for debug prints.
This removes extra layer of code without any functional
change.

Signed-off-by: Ruslan Bilovol 
---
 drivers/usb/gadget/function/f_uac2.c | 107 +--
 1 file changed, 28 insertions(+), 79 deletions(-)

diff --git a/drivers/usb/gadget/function/f_uac2.c 
b/drivers/usb/gadget/function/f_uac2.c
index f6a0d3a..d4565b5 100644
--- a/drivers/usb/gadget/function/f_uac2.c
+++ b/drivers/usb/gadget/function/f_uac2.c
@@ -13,7 +13,6 @@
 
 #include 
 #include 
-#include 
 #include 
 
 #include 
@@ -51,8 +50,6 @@
 #define UNFLW_CTRL 8
 #define OVFLW_CTRL 10
 
-static const char *uac2_name = "snd_uac2";
-
 struct uac2_req {
struct uac2_rtd_params *pp; /* parent param */
struct usb_request *req;
@@ -81,9 +78,6 @@ struct uac2_rtd_params {
 };
 
 struct snd_uac2_chip {
-   struct platform_device pdev;
-   struct platform_driver pdrv;
-
struct uac2_rtd_params p_prm;
struct uac2_rtd_params c_prm;
 
@@ -122,6 +116,7 @@ struct audio_dev {
 
struct usb_ep *in_ep, *out_ep;
struct usb_function func;
+   struct usb_gadget *gadget;
 
/* The ALSA Sound Card it represents on the USB-Client side */
struct snd_uac2_chip uac2;
@@ -140,12 +135,6 @@ struct audio_dev *uac2_to_agdev(struct snd_uac2_chip *u)
 }
 
 static inline
-struct snd_uac2_chip *pdev_to_uac2(struct platform_device *p)
-{
-   return container_of(p, struct snd_uac2_chip, pdev);
-}
-
-static inline
 struct f_uac2_opts *agdev_to_uac2_opts(struct audio_dev *agdev)
 {
return container_of(agdev->func.fi, struct f_uac2_opts, func_inst);
@@ -254,7 +243,7 @@ uint num_channels(uint chanmask)
 
 exit:
if (usb_ep_queue(ep, req, GFP_ATOMIC))
-   dev_err(>pdev.dev, "%d Error!\n", __LINE__);
+   dev_err(uac2->card->dev, "%d Error!\n", __LINE__);
 
if (update_alsa)
snd_pcm_period_elapsed(substream);
@@ -440,23 +429,22 @@ static int uac2_pcm_null(struct snd_pcm_substream 
*substream)
.prepare = uac2_pcm_null,
 };
 
-static int snd_uac2_probe(struct platform_device *pdev)
+static int snd_uac2_probe(struct audio_dev *audio_dev)
 {
-   struct snd_uac2_chip *uac2 = pdev_to_uac2(pdev);
+   struct snd_uac2_chip *uac2 = _dev->uac2;
struct snd_card *card;
struct snd_pcm *pcm;
-   struct audio_dev *audio_dev;
struct f_uac2_opts *opts;
int err;
int p_chmask, c_chmask;
 
-   audio_dev = uac2_to_agdev(uac2);
opts = container_of(audio_dev->func.fi, struct f_uac2_opts, func_inst);
p_chmask = opts->p_chmask;
c_chmask = opts->c_chmask;
 
/* Choose any slot, with no id */
-   err = snd_card_new(>dev, -1, NULL, THIS_MODULE, 0, );
+   err = snd_card_new(_dev->gadget->dev,
+   -1, NULL, THIS_MODULE, 0, );
if (err < 0)
return err;
 
@@ -481,16 +469,15 @@ static int snd_uac2_probe(struct platform_device *pdev)
 
strcpy(card->driver, "UAC2_Gadget");
strcpy(card->shortname, "UAC2_Gadget");
-   sprintf(card->longname, "UAC2_Gadget %i", pdev->id);
+   sprintf(card->longname, "UAC2_Gadget %i", card->dev->id);
 
snd_pcm_lib_preallocate_pages_for_all(pcm, SNDRV_DMA_TYPE_CONTINUOUS,
snd_dma_continuous_data(GFP_KERNEL), 0, BUFF_SIZE_MAX);
 
err = snd_card_register(card);
-   if (!err) {
-   platform_set_drvdata(pdev, card);
+
+   if (!err)
return 0;
-   }
 
 snd_fail:
snd_card_free(card);
@@ -501,9 +488,9 @@ static int snd_uac2_probe(struct platform_device *pdev)
return err;
 }
 
-static int snd_uac2_remove(struct platform_device *pdev)
+static int snd_uac2_remove(struct audio_dev *audio_dev)
 {
-   struct snd_card *card = platform_get_drvdata(pdev);
+   struct snd_card *card = audio_dev->uac2.card;
 
if (card)
return snd_card_free(card);
@@ -511,45 +498,6 @@ static int snd_uac2_remove(struct platform_device *pdev)
return 0;
 }
 
-static void snd_uac2_release(struct device *dev)
-{
-   dev_dbg(dev, "releasing '%s'\n", dev_name(dev));
-}
-
-static int alsa_uac2_init(struct audio_dev *agdev)
-{
-   struct snd_uac2_chip *uac2 = >uac2;
-   int err;
-
-   uac2->pdrv.probe = snd_uac2_probe;
-   uac2->pdrv.remove = snd_uac2_remove;
-   uac2->pdrv.driver.name = uac2_name;
-
-   uac2->pdev.id = 0;
-   uac2->pdev.name = uac2_name;
-   uac2->pdev.dev.release = snd_uac2_release;
-
-   /* Register snd_uac2 driver */
-   err = platform_driver_register(>pdrv);
-   if (err)
-   return err;
-
-   /* Register snd_uac2 device */
-   err = platform_device_register(>pdev);
-   if (err)
-   

VL812 Hub does not recognize USB3 flash drives being plugged/unplugged

[Sergiu Giurgiu]

Hi,
I have an Anker USB hub, which is using the VL812 chipset. It works 
perfectly when plug/unplug USB2 flash drives. It does not work at all 
(dmesg is quiet) when I plug/unplug USB3 flash drives.
It works in Windows. It kinda works in FreeBSD (the USB3 device just 
works at USB2 speeds).
However, it does see it once I do a ` cat /dev/bus/usb/006/002  ` . It 
just needs that little "push". Since I have this workaround, I have been 
procrastinating and not actually reported this bug, but it's been this 
way since ... as far as I remember (3.x line of kernels as well).


Any ideas? Things to try? More information?

Thank you.

My kernel: Linux 4.12.0-rc1 #1 SMP Wed May 17 17:54:39 EDT 2017 x86_64 
x86_64 x86_64 GNU/Linux

lsusb:
Bus 002 Device 008: ID 12ba:00ff Licensed by Sony Computer Entertainment 
America Rocksmith Guitar Adapter
Bus 002 Device 007: ID 04d9:2013 Holtek Semiconductor, Inc. Keyboard 
[Das Keyboard]

Bus 002 Device 006: ID 05e3:0608 Genesys Logic, Inc. Hub
Bus 002 Device 005: ID 262a:1048
Bus 002 Device 004: ID 0424:2514 Standard Microsystems Corp. USB 2.0 Hub
Bus 002 Device 003: ID 046d:c07d Logitech, Inc. G502 Mouse
Bus 002 Device 002: ID 8087:0024 Intel Corp. Integrated Rate Matching Hub
Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 006 Device 005: ID 0951:16a2 Kingston Technology  --the flash drive 
that now is seen appears as well
Bus 006 Device 003: ID 2109:0812 VIA Labs, Inc. VL812 Hub  -- the hub is 
here
Bus 006 Device 002: ID 2109:0812 VIA Labs, Inc. VL812 Hub   -- the hub 
is here

Bus 006 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 005 Device 002: ID 2109:2812 VIA Labs, Inc. VL812 Hub   -- the hub 
is here

Bus 005 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 004 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 003 Device 002: ID 0b05:17cb ASUSTek Computer, Inc. Broadcom 
BCM20702A0 Bluetooth

Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 001 Device 004: ID 0403:6010 Future Technology Devices 
International, Ltd FT2232C/D/H Dual UART/FIFO IC

Bus 001 Device 003: ID 046d:08ad Logitech, Inc. QuickCam Communicate STX
Bus 001 Device 002: ID 8087:0024 Intel Corp. Integrated Rate Matching Hub
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub


[0.00] Linux version 4.12.0-rc1 (sergiu@sergiu-pc) (gcc version 7.1.1 
20170503 (Red Hat 7.1.1-1) (GCC) ) #1 SMP Wed May 17 17:54:39 EDT 2017
[0.00] Command line: BOOT_IMAGE=/boot/vmlinuz-4.12.0-rc1 
root=UUID=4683c10c-9098-4c23-b987-6913a2642a4a ro rhgb quiet nouveau.modeset=0 
rd.driver.blacklist=nouveau nvidia-drm.modeset=1 LANG=en_CA.UTF-8
[0.00] x86/fpu: Supporting XSAVE feature 0x001: 'x87 floating point 
registers'
[0.00] x86/fpu: Supporting XSAVE feature 0x002: 'SSE registers'
[0.00] x86/fpu: Supporting XSAVE feature 0x004: 'AVX registers'
[0.00] x86/fpu: xstate_offset[2]:  576, xstate_sizes[2]:  256
[0.00] x86/fpu: Enabled xstate features 0x7, context size is 832 bytes, 
using 'standard' format.
[0.00] e820: BIOS-provided physical RAM map:
[0.00] BIOS-e820: [mem 0x-0x0009] usable
[0.00] BIOS-e820: [mem 0x0010-0xbc173fff] usable
[0.00] BIOS-e820: [mem 0xbc174000-0xbc459fff] reserved
[0.00] BIOS-e820: [mem 0xbc45a000-0xbc567fff] ACPI data
[0.00] BIOS-e820: [mem 0xbc568000-0xbc78afff] ACPI NVS
[0.00] BIOS-e820: [mem 0xbc78b000-0xbd73] reserved
[0.00] BIOS-e820: [mem 0xbd74-0xbd740fff] usable
[0.00] BIOS-e820: [mem 0xbd741000-0xbd7c6fff] ACPI NVS
[0.00] BIOS-e820: [mem 0xbd7c7000-0xbdc05fff] usable
[0.00] BIOS-e820: [mem 0xbdc06000-0xbdff3fff] reserved
[0.00] BIOS-e820: [mem 0xbdff4000-0xbdff] usable
[0.00] BIOS-e820: [mem 0xe000-0xefff] reserved
[0.00] BIOS-e820: [mem 0xfed1c000-0xfed1] reserved
[0.00] BIOS-e820: [mem 0xff00-0x] reserved
[0.00] BIOS-e820: [mem 0x0001-0x00083fff] usable
[0.00] tsc: Fast TSC calibration using PIT
[0.00] NX (Execute Disable) protection: active
[0.00] e820: update [mem 0x7dca0018-0x7dcc1a57] usable ==> usable
[0.00] e820: update [mem 0x7dc90018-0x7dc9f857] usable ==> usable
[0.00] extended physical RAM map:
[0.00] reserve setup_data: [mem 0x-0x0009] 
usable
[0.00] reserve setup_data: [mem 0x0010-0x7dc90017] 
usable
[0.00] reserve setup_data: [mem 0x7dc90018-0x7dc9f857] 
usable
[0.00] reserve setup_data: [mem 0x7dc9f858-0x7dca0017] 
usable
[0.00] reserve setup_data: [mem 

[PATCH] r8152: Mark usb_ocp_read() as __maybe_unused

[Matthias Kaehlcke]

The function is not used, but is probably kept around for debugging and
symmetry with usb_ocp_write(). Adding the attribute fixes the following
clang warning:

drivers/net/usb/r8152.c:825:5: error: unused function 'usb_ocp_read'
[-Werror,-Wunused-function]

Signed-off-by: Matthias Kaehlcke 
---
 drivers/net/usb/r8152.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/usb/r8152.c b/drivers/net/usb/r8152.c
index ddc62cb69be8..12776230ab96 100644
--- a/drivers/net/usb/r8152.c
+++ b/drivers/net/usb/r8152.c
@@ -840,7 +840,7 @@ int pla_ocp_write(struct r8152 *tp, u16 index, u16 byteen, 
u16 size, void *data)
return generic_ocp_write(tp, index, byteen, size, data, MCU_TYPE_PLA);
 }
 
-static inline
+static inline __maybe_unused
 int usb_ocp_read(struct r8152 *tp, u16 index, u16 size, void *data)
 {
return generic_ocp_read(tp, index, size, data, MCU_TYPE_USB);
-- 
2.13.0.303.g4ebf302169-goog

--
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] net1080: Mark nc_dump_ttl() as __maybe_unused

[Matthias Kaehlcke]

The function is not used, but it looks useful for debugging. Adding the
attribute fixes the following clang warning:

drivers/net/usb/net1080.c:271:20: error: unused function
'nc_dump_ttl' [-Werror,-Wunused-function]

Signed-off-by: Matthias Kaehlcke 
---
 drivers/net/usb/net1080.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/usb/net1080.c b/drivers/net/usb/net1080.c
index 4cbdb1307f3e..7ade2119f462 100644
--- a/drivers/net/usb/net1080.c
+++ b/drivers/net/usb/net1080.c
@@ -268,7 +268,7 @@ static inline void nc_dump_status(struct usbnet *dev, u16 
status)
 #defineTTL_OTHER(ttl)  (0x00ff & (ttl >> 8))
 #define MK_TTL(this,other) ((u16)(((other)<<8)|(0x00ff&(this
 
-static inline void nc_dump_ttl(struct usbnet *dev, u16 ttl)
+static inline void __maybe_unused nc_dump_ttl(struct usbnet *dev, u16 ttl)
 {
netif_dbg(dev, link, dev->net, "net1080 %s-%s ttl 0x%x this = %d, other 
= %d\n",
  dev->udev->bus->bus_name, dev->udev->devpath,
-- 
2.13.0.303.g4ebf302169-goog

--
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 5/9] usb: musb: tusb6010_omap: Create new struct for DMA data/parameters

[Bin Liu]

On Fri, May 12, 2017 at 04:57:48PM +0300, Peter Ujfalusi wrote:
> For the DMA we have ch (channel), dmareq and sync_dev parameters both
> within the tusb_omap_dma_ch and tusb_omap_dma_ch struct.

one of the two "tusb_omap_dma_ch" should be "tusb_omap_dma".

Regards,
-Bin.
--
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 5/9] usb: musb: tusb6010_omap: Create new struct for DMA data/parameters

[Bin Liu]

On Fri, May 12, 2017 at 04:57:48PM +0300, Peter Ujfalusi wrote:
> For the DMA we have ch (channel), dmareq and sync_dev parameters both
> within the tusb_omap_dma_ch and tusb_omap_dma_ch struct.
> By creating a common struct the code can be simplified when selecting
> between the shared or multichannel DMA parameters.
> 
> Signed-off-by: Peter Ujfalusi 
> Tested-by: Tony Lindgren 
> ---
>  drivers/usb/musb/tusb6010_omap.c | 163 
> ---
>  1 file changed, 84 insertions(+), 79 deletions(-)
> 
> diff --git a/drivers/usb/musb/tusb6010_omap.c 
> b/drivers/usb/musb/tusb6010_omap.c
> index 025b52e0b34d..938ded0c407b 100644
> --- a/drivers/usb/musb/tusb6010_omap.c
> +++ b/drivers/usb/musb/tusb6010_omap.c
> @@ -31,6 +31,12 @@
>  #define OMAP242X_DMA_EXT_DMAREQ4 16
>  #define OMAP242X_DMA_EXT_DMAREQ5 64
>  
> +struct tusb_dma_data {
> + int ch;
> + s8  dmareq;
> + s8  sync_dev;
> +};
> +
>  struct tusb_omap_dma_ch {
>   struct musb *musb;
>   void __iomem*tbase;
> @@ -39,9 +45,7 @@ struct tusb_omap_dma_ch {
>   u8  tx;
>   struct musb_hw_ep   *hw_ep;
>  
> - int ch;
> - s8  dmareq;
> - s8  sync_dev;
> + struct tusb_dma_datadma_data;
>  
>   struct tusb_omap_dma*tusb_dma;
>  
> @@ -58,9 +62,7 @@ struct tusb_omap_dma {
>   struct dma_controller   controller;
>   void __iomem*tbase;
>  
> - int ch;
> - s8  dmareq;
> - s8  sync_dev;
> + struct tusb_dma_datadma_data;
>   unsignedmultichannel:1;
>  };
>  
> @@ -119,9 +121,9 @@ static void tusb_omap_dma_cb(int lch, u16 ch_status, void 
> *data)
>   spin_lock_irqsave(>lock, flags);
>  
>   if (tusb_dma->multichannel)
> - ch = chdat->ch;
> + ch = chdat->dma_data.ch;
>   else
> - ch = tusb_dma->ch;
> + ch = tusb_dma->dma_data.ch;
>  
>   if (ch_status != OMAP_DMA_BLOCK_IRQ)
>   printk(KERN_ERR "TUSB DMA error status: %i\n", ch_status);
> @@ -140,8 +142,7 @@ static void tusb_omap_dma_cb(int lch, u16 ch_status, void 
> *data)
>   /* HW issue #10: XFR_SIZE may get corrupt on DMA (both async & sync) */
>   if (unlikely(remaining > chdat->transfer_len)) {
>   dev_dbg(musb->controller, "Corrupt %s dma ch%i XFR_SIZE: 
> 0x%08lx\n",
> - chdat->tx ? "tx" : "rx", chdat->ch,
> - remaining);
> + chdat->tx ? "tx" : "rx", ch, remaining);
>   remaining = 0;
>   }
>  
> @@ -220,9 +221,7 @@ static int tusb_omap_dma_program(struct dma_channel 
> *channel, u16 packet_sz,
>   int src_burst, dst_burst;
>   u16 csr;
>   u32 psize;
> - int ch;
> - s8  dmareq;
> - s8  sync_dev;
> + struct tusb_dma_data*dma_data;
>  
>   if (unlikely(dma_addr & 0x1) || (len < 32) || (len > packet_sz))
>   return false;
> @@ -249,7 +248,7 @@ static int tusb_omap_dma_program(struct dma_channel 
> *channel, u16 packet_sz,
>   dma_remaining = TUSB_EP_CONFIG_XFR_SIZE(dma_remaining);
>   if (dma_remaining) {
>   dev_dbg(musb->controller, "Busy %s dma ch%i, not using: %08x\n",
> - chdat->tx ? "tx" : "rx", chdat->ch,
> + chdat->tx ? "tx" : "rx", chdat->dma_data.ch,
>   dma_remaining);
>   return false;
>   }
> @@ -262,15 +261,15 @@ static int tusb_omap_dma_program(struct dma_channel 
> *channel, u16 packet_sz,
>   chdat->transfer_packet_sz = packet_sz;
>  
>   if (tusb_dma->multichannel) {
> - ch = chdat->ch;
> - dmareq = chdat->dmareq;
> - sync_dev = chdat->sync_dev;
> + dma_data = >dma_data;
>   } else {
> + dma_data = _dma->dma_data;
> +
>   if (tusb_omap_use_shared_dmareq(chdat) != 0) {
>   dev_dbg(musb->controller, "could not get dma for 
> ep%i\n", chdat->epnum);
>   return false;
>   }
> - if (tusb_dma->ch < 0) {
> + if (dma_data->ch < 0) {
>   /* REVISIT: This should get blocked earlier, happens
>* with MSC ErrorRecoveryTest
>*/
> @@ -278,10 +277,7 @@ static int tusb_omap_dma_program(struct dma_channel 
> *channel, u16 packet_sz,
>   return false;
>   }
>  
> - ch = tusb_dma->ch;
> -  

Re: [PATCH v3 3/9] usb: musb: tusb6010: Add MUSB_G_NO_SKB_RESERVE to quirks

[Bin Liu]

On Fri, May 12, 2017 at 04:57:46PM +0300, Peter Ujfalusi wrote:
> When using the g_ncm for networking this flag will make sure that the
> buffer is alligned to 32bit so the DMA can be used to offload the data

s/alligned/aligned/

Regards,
-Bin.

> movement.
> 
> Signed-off-by: Peter Ujfalusi 
> Tested-by: Tony Lindgren 
> ---
>  drivers/usb/musb/tusb6010.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/usb/musb/tusb6010.c b/drivers/usb/musb/tusb6010.c
> index e85cc8e4e7a9..4253bfb22043 100644
> --- a/drivers/usb/musb/tusb6010.c
> +++ b/drivers/usb/musb/tusb6010.c
> @@ -1181,7 +1181,8 @@ static int tusb_musb_exit(struct musb *musb)
>  }
>  
>  static const struct musb_platform_ops tusb_ops = {
> - .quirks = MUSB_DMA_TUSB_OMAP | MUSB_IN_TUSB,
> + .quirks = MUSB_DMA_TUSB_OMAP | MUSB_IN_TUSB |
> +   MUSB_G_NO_SKB_RESERVE,
>   .init   = tusb_musb_init,
>   .exit   = tusb_musb_exit,
>  
> -- 
> 2.13.0
> 
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: OHCI-PCI: Thin client does not shutdown properly

[Alan Stern]

On Wed, 17 May 2017, Rainer Koenig wrote:

> Oops, pressed the "send button too quickly, sorry"
> 
> Am 16.05.2017 um 16:20 schrieb Alan Stern:
> > You've got a BIOS developer in the same building?  That's a great
> > resource!  Maybe together you can find out what condition is causing
> > the BIOS to initiate a reboot.
> 
> We got everything here. We got hardware developers for our mainboards
> and systems, BIOS developers, QA engineeers, product management and a
> factory to build servers and PCs. The only site in Europe that is still
> developing and producing PCs and servers.
> 
> > For example, exactly what does "Power-On via USB" in the BIOS do?
> 
> BIOS is waiting for a "resume" in that case. If a resume on USB is
> there, machine starts. We have special keyboards with a power on button
> and the trick is that this button issues a "resume" even if the keyboard
> itself is not programmed to send resumes.

Okay.  So probably what happens is that when the EHCI controller is 
reset, it causes some sort of noise to appear on the USB data lines and 
the OHCI controller interprets this as a port status change or resume 
request.  So the controller asserts a resume signal, and that causes 
the BIOS to turn the computer back on.

> > I didn't expect the patch to solve the problem.  Nevertheless, I would 
> > like to know exactly what effect it has on both kernels.  Can you 
> > provide more details?
> 
> Here we go. That's the USB releated log with the patch:
> usbhid 5-2:1.0: rkoenig handling
> 
> usbhid 5-2:1.0: shutdown
> 
> usbhid 5-1:1.1: rkoenig handling
> 
> usbhid 5-1:1.1: shutdown
> 
> usbhid 5-1:1.0: rkoenig handling
> 
> usbhid 5-1:1.0: shutdown
> 
> usb 5-2: rkoenig handling
> 
> usb 5-2: shutdown
> 
> usb 5-1: rkoenig handling
> 
> usb 5-1: shutdown
> 
> usb usb6-port4: rkoenig handling
> 
> usb usb6-port3: rkoenig handling
> 
> usb usb6-port2: rkoenig handling
> 
> usb usb6-port1: rkoenig handling
> 
> usb usb6: rkoenig handling
> 
> usb usb6: shutdown
> 
> ohci-pci :00:13.0: rkoenig handling
> 
> ohci-pci :00:13.0: shutdown
> 
> usb usb5-port4: rkoenig handling
> 
> usb usb5-port3: rkoenig handling
> 
> usb usb5-port2: rkoenig handling
> 
> usb usb5-port1: rkoenig handling
> 
> usb usb5: rkoenig handling
> 
> usb usb5: shutdown
> 
> ohci-pci :00:12.0: rkoenig handling
> 
> ohci-pci :00:12.0: shutdown
> 
> usb usb4-port4: rkoenig handling
> 
> usb usb4-port3: rkoenig handling
> 
> usb usb4-port2: rkoenig handling
> 
> usb usb4-port1: rkoenig handling
> 
> usb usb4: rkoenig handling
> 
> usb usb4: shutdown
> 
> ehci-pci :00:13.2: rkoenig handling
> 
> ehci-pci :00:13.2: shutdown
> 
> usb usb3-port4: rkoenig handling
> 
> usb usb3-port3: rkoenig handling
> 
> usb usb3-port2: rkoenig handling
> 
> usb usb3-port1: rkoenig handling
> 
> usb usb3: rkoenig handling
> 
> usb usb3: shutdown
> 
> ehci-pci :00:12.2: rkoenig handling
> 
> ehci-pci :00:12.2: shutdown
> 
> usb usb2-port2: rkoenig handling
> 
> usb usb2-port1: rkoenig handling
> 
> usb usb2: rkoenig handling
> 
> usb usb2: shutdown
> 
> usb usb1-port2: rkoenig handling
> 
> usb usb1-port1: rkoenig handling
> 
> usb usb1: rkoenig handling
> 
> usb usb1: shutdown
> 
> xhci_hcd :00:10.0: rkoenig handling
> 
> xhci_hcd :00:10.0: shutdown

No important differences.  All right.

> > You should have unbound the controllers, not the devices.  That is, you
> > should have unbound PCI devices :00:12.0 and :00:13.0 from
> > ohci-pci (in /sys/bus/pci/drivers/ohci_pci), and :00:12.2 and
> > :00:13.2 from ehci-pci (in /sys/bus/pci/drivers/ehci_pci).
> 
> Yeah, that one I tried and it works perfectly, even when the drivers
> are compiled into the kernel.
> 
> >> The keyboard/mouse still continued to work on my system (which btw is
> > 
> > Are they connected over USB?  If they are, removing ehci-pci won't make 
> > any difference.  But without ohci-pci, they won't work -- unless they 
> > are plugged into a USB-3 port.
> 
> Yes, keyboard and mouse are attached on the USB ports.
> 
> >> running Ubuntu 16.04 for this tests). But now its getting strange:
> >>
> >> - if I shutdown the system at this point with "init 0" from a root shell
> >>   it performs a shutdown, and it turns off! Yeah.
> >>
> >> - if I shutdown the system at this point by using the shutdown menu from
> >>   the Ubuntu menu then the shutdown ends up in a kernel panic.
> > 
> > Don't you get any information about the panic on your serial console?  
> > I would expect it to have a stack dump, at least.  A panic means 
> > there's a bug, and it needs to be fixed.
> 
> That's what I get:
> 
> [  297.243132] general protection fault:  [#1] SMP
> 
> [  297.250152] Modules linked in: amd_freq_sensitivity(E)
> snd_hda_codec_realtek(E) snd_hda_codec_generic(E) snd_hda_codec_hdmi(E)
> kvm_amd(E) snd_hda_intel(E) kvm(E) snd_hda_codec(E) crct10dif_pclmul(E)
> snd_hda_core(E) crc32_pclmul(E) snd_hwdep(E) ghash_clmulni_intel(E)
> snd_pcm(E) 

Re: [RFC V1 1/1] net: cdc_ncm: Reduce memory use when kernel memory low

[David Miller]

From: Bjørn Mork 
Date: Tue, 16 May 2017 20:24:10 +0200

> Jim Baxter  writes:
> 
>> The CDC-NCM driver can require large amounts of memory to create
>> skb's and this can be a problem when the memory becomes fragmented.
>>
>> This especially affects embedded systems that have constrained
>> resources but wish to maximise the throughput of CDC-NCM with 16KiB
>> NTB's.
>>
>> The issue is after running for a while the kernel memory can become
>> fragmented and it needs compacting.
>> If the NTB allocation is needed before the memory has been compacted
>> the atomic allocation can fail which can cause increased latency,
>> large re-transmissions or disconnections depending upon the data
>> being transmitted at the time.
>> This situation occurs for less than a second until the kernel has
>> compacted the memory but the failed devices can take a lot longer to
>> recover from the failed TX packets.
>>
>> To ease this temporary situation I modified the CDC-NCM TX path to
>> temporarily switch into a reduced memory mode which allocates an NTB
>> that will fit into a USB_CDC_NCM_NTB_MIN_OUT_SIZE (default 2048 Bytes)
>> sized memory block and only transmit NTB's with a single network frame
>> until the memory situation is resolved.
>> Once the memory is compacted the CDC-NCM data can resume transmitting
>> at the normal tx_max rate once again.
> 
> I must say that I don't like the additional complexity added here.  If
> there are memory issues and you can reduce the buffer size to
> USB_CDC_NCM_NTB_MIN_OUT_SIZE, then why don't you just set a lower tx_max
> buffer size in the first place?
> 
>   echo 2048 > /sys/class/net/wwan0/cdc_ncm/tx_max

When there isn't memory pressure this will hurt performance of
course.

It is a quite common paradigm to back down to 0 order memory requests
when higher order ones fail, so this isn't such a bad change from the
perspective.

However, one negative about it is that when the system is under memory
stress it doesn't help at all to keep attemping high order allocations
when the system hasn't recovered yet.  In fact, this can make it
worse.
--
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: typec: Defer checking of valid power role swap to low level drivers

[Badhri Jagan Sridharan]

For non-pd case, Should I instead say that the low level driver might optionally
choose to perform a best case effort of performing a role swap by disconnect
and reconnect ?

Does the following description look better ?

Description:
The supported power roles. This attribute can be used to request
power role swap. Swapping is supported as synchronous
operation, so
write(2) to the attribute will not return until the operation
has finished. The attribute is notified about role changes so
that poll(2) on the attribute wakes up. Change on the role will
also generate uevent KOBJ_CHANGE. The current role is show in
brackets, for example "[source] sink" when in source mode.
When both the port and the port-partner supports USB Power
Delivery, the PR_SWAP command is used to perform the role swap.
For non-pd case, the low level driver might optionally perform
a best effort approach to swap port roles by forcing
a disconnect and reconnect.

Thanks,
Badhri

On Wed, May 17, 2017 at 6:51 AM, Heikki Krogerus
 wrote:
>
> On Wed, May 17, 2017 at 06:02:47AM -0700, Guenter Roeck wrote:
> > On 05/17/2017 05:38 AM, Heikki Krogerus wrote:
> > > Hi guys,
> > >
> > > On Wed, May 17, 2017 at 02:36:44AM -0700, Guenter Roeck wrote:
> > > > On 05/17/2017 12:34 AM, Oliver Neukum wrote:
> > > > > Am Mittwoch, den 17.05.2017, 00:32 -0700 schrieb Badhri Jagan
> > > > > Sridharan:
> > > > >
> > > > > Hi,
> > > > >
> > > > > > "Two independent set of mechanisms are defined to allow a USB Type-C
> > > > > > DRP to functionally swap power and data roles. When USB PD is
> > > > > > supported, power and data role swapping is performed as a subsequent
> > > > > > step following the initial connection process. For non-PD 
> > > > > > implementations,
> > > > > > power/data role swapping can optionally be dealt with as part of 
> > > > > > the initial
> > > > > > connection process."
> > > > >
> > > > > Well, as I read it, without PD once a connection is established, you
> > > > > are stuck with your role. So it seems to me that blocking a later
> > > > > attempt to change it makes sense.
> > > > >
> > > >
> > > > That seems to be a harsh and not very user friendly reading of the 
> > > > specification.
> > > >
> > > > I would argue that the user doesn't care if the partner supports PD or 
> > > > not
> > > > when selecting a role, and I would prefer to provide an implementation 
> > > > which is
> > > > as user friendly as possible.
> > >
> > > I agree. But I have to point out that at least with UCSI, the role
> > > swapping is usually not possible without USB PD connection.
> > >
> > > So what I'm trying to say is that we can't really promise that role
> > > swapping will ever be possible in all cases without PD, which may mean
> > > different behavior depending on the platform. I don't know if that is
> > > a huge problem.
> > >
> > > How predictable do we want this interface to function with role
> > > swapping?
> > >
> >
> > We can only do as good as we can, but we should not preclude it either.
> > PR_SWAP and other swap operations fail a lot in practice with many dongles,
> > just because the PD protocol implementation isn't always stable. So even 
> > that
> > won't be predictable for some time to come.
> >
> > As Badhri pointed out earlier, at least some low cost devices won't support 
> > PD.
> > Since we are talking about high volume products, we _have_ to make it as
> > user friendly as we can, if for nothing else to reduce the number of 
> > customer
> > service calls, repeated bug filings, and, last but not least, to avoid bad 
> > press.
>
> OK. So I think we just need to explain in the documentation that there
> are no guarantees with role swapping.
>
>
> Thanks,
>
> --
> heikki
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 0/2] musb fixes for v4.12-rc2

[Bin Liu]

Hi Greg,

Here are the couple musb fixes for v4.12-rc2. One fixes an regression caused in
the runtime PM refactoring in musb since v4.9, and the other fixes a register
cross-talk between rx and tx in tusb6010 since the beginning when the driver was
merged.

Please let me know if any change is needed.

Thanks,
-Bin.
---

Peter Ujfalusi (1):
  usb: musb: tusb6010_omap: Do not reset the other direction's packet
size

Tony Lindgren (1):
  usb: musb: Fix trying to suspend while active for OTG configurations

 drivers/usb/musb/musb_host.c |  9 +
 drivers/usb/musb/tusb6010_omap.c | 13 +
 2 files changed, 14 insertions(+), 8 deletions(-)

-- 
1.9.1

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

[PATCH 2/2] usb: musb: tusb6010_omap: Do not reset the other direction's packet size

[Bin Liu]

From: Peter Ujfalusi 

We have one register for each EP to set the maximum packet size for both
TX and RX.
If for example an RX programming would happen before the previous TX
transfer finishes we would reset the TX packet side.

To fix this issue, only modify the TX or RX part of the register.

Fixes: 550a7375fe72 ("USB: Add MUSB and TUSB support")
Signed-off-by: Peter Ujfalusi 
Tested-by: Tony Lindgren 
Signed-off-by: Bin Liu 
---
 drivers/usb/musb/tusb6010_omap.c | 13 +
 1 file changed, 9 insertions(+), 4 deletions(-)

diff --git a/drivers/usb/musb/tusb6010_omap.c b/drivers/usb/musb/tusb6010_omap.c
index 8b43c4b99f04..7870b37e0ea5 100644
--- a/drivers/usb/musb/tusb6010_omap.c
+++ b/drivers/usb/musb/tusb6010_omap.c
@@ -219,6 +219,7 @@ static int tusb_omap_dma_program(struct dma_channel 
*channel, u16 packet_sz,
u32 dma_remaining;
int src_burst, dst_burst;
u16 csr;
+   u32 psize;
int ch;
s8  dmareq;
s8  sync_dev;
@@ -390,15 +391,19 @@ static int tusb_omap_dma_program(struct dma_channel 
*channel, u16 packet_sz,
 
if (chdat->tx) {
/* Send transfer_packet_sz packets at a time */
-   musb_writel(ep_conf, TUSB_EP_MAX_PACKET_SIZE_OFFSET,
-   chdat->transfer_packet_sz);
+   psize = musb_readl(ep_conf, TUSB_EP_MAX_PACKET_SIZE_OFFSET);
+   psize &= ~0x7ff;
+   psize |= chdat->transfer_packet_sz;
+   musb_writel(ep_conf, TUSB_EP_MAX_PACKET_SIZE_OFFSET, psize);
 
musb_writel(ep_conf, TUSB_EP_TX_OFFSET,
TUSB_EP_CONFIG_XFR_SIZE(chdat->transfer_len));
} else {
/* Receive transfer_packet_sz packets at a time */
-   musb_writel(ep_conf, TUSB_EP_MAX_PACKET_SIZE_OFFSET,
-   chdat->transfer_packet_sz << 16);
+   psize = musb_readl(ep_conf, TUSB_EP_MAX_PACKET_SIZE_OFFSET);
+   psize &= ~(0x7ff << 16);
+   psize |= (chdat->transfer_packet_sz << 16);
+   musb_writel(ep_conf, TUSB_EP_MAX_PACKET_SIZE_OFFSET, psize);
 
musb_writel(ep_conf, TUSB_EP_RX_OFFSET,
TUSB_EP_CONFIG_XFR_SIZE(chdat->transfer_len));
-- 
1.9.1

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

[PATCH 1/2] usb: musb: Fix trying to suspend while active for OTG configurations

[Bin Liu]

From: Tony Lindgren 

Commit d8e5f0eca1e8 ("usb: musb: Fix hardirq-safe hardirq-unsafe
lock order error") caused a regression where musb keeps trying to
enable host mode with no cable connected. This seems to be caused
by the fact that now phy is enabled earlier, and we are wrongly
trying to force USB host mode on an OTG port. The errors we are
getting are "trying to suspend as a_idle while active".

For ports configured as OTG, we should not need to do anything
to try to force USB host mode on it's OTG port. Trying to force host
mode in this case just seems to completely confuse the musb state
machine.

Let's fix the issue by making musb_host_setup() attempt to force the
mode only if port_mode is configured for host mode.

Fixes: d8e5f0eca1e8 ("usb: musb: Fix hardirq-safe hardirq-unsafe
lock order error")
Cc: Johan Hovold 
Reported-by: Laurent Pinchart 
Reported-by: Peter Ujfalusi 
Tested-by: Peter Ujfalusi 
Signed-off-by: Tony Lindgren 
Signed-off-by: Bin Liu 
---
 drivers/usb/musb/musb_host.c | 9 +
 1 file changed, 5 insertions(+), 4 deletions(-)

diff --git a/drivers/usb/musb/musb_host.c b/drivers/usb/musb/musb_host.c
index ac3a4952abb4..dbe617a735d8 100644
--- a/drivers/usb/musb/musb_host.c
+++ b/drivers/usb/musb/musb_host.c
@@ -2780,10 +2780,11 @@ int musb_host_setup(struct musb *musb, int power_budget)
int ret;
struct usb_hcd *hcd = musb->hcd;
 
-   MUSB_HST_MODE(musb);
-   musb->xceiv->otg->default_a = 1;
-   musb->xceiv->otg->state = OTG_STATE_A_IDLE;
-
+   if (musb->port_mode == MUSB_PORT_MODE_HOST) {
+   MUSB_HST_MODE(musb);
+   musb->xceiv->otg->default_a = 1;
+   musb->xceiv->otg->state = OTG_STATE_A_IDLE;
+   }
otg_set_host(musb->xceiv->otg, >self);
hcd->self.otg_port = 1;
musb->xceiv->otg->host = >self;
-- 
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: Microchip USB Hub Driver Harmonization

[Krzysztof Kozlowski]

On Wed, May 17, 2017 at 12:58:38PM +0200, Richard Leitner wrote:
> Hello,
> due to the fact (all?) the Microchip (former SMSC) USB hubs share the
> same I2C configuration interface, I'm currently working on harmonizing
> those USB Hub drivers. Currently this affects the usb251xb, usb3503 and
> usb4604 drivers. To avoid preventable efforts (and patch versions) I
> have some question on the preferred implementation:
> 
> 1. Currently usb251xb uses i2c_smbus_*, usb3503 uses regmap_* and
> usb4604 uses i2c_master_* functions for the hub configuration. What
> would be the preferred solution?

regmap? It is already widely used for I2C drivers. I think most (or even
all?) new I2C drivers use regmap. It hides the real bus between common
regmap API.

> 2. What would be a good prefix for common headers/functions/macros/etc.?
> I thought of "mcusbhub"... Would that be OK? Or are there any
> conventions/better proposals on that?

If you are going to develop one driver for entire family, then you could
even choose just one name. Let's say the most generic.

I don't quite understand the meaning behind "harmonizing drivers".

> 3. Currently only usb3503 supports "platform data". Is this still needed
> or may it be removed?

I think it is still used, e.g. by:
arch/arm/boot/dts/exynos5250-spring.dts

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

[PATCH 5/8] USB: xhci: fix lock-inversion problem

[Mathias Nyman]

From: Alan Stern 

With threaded interrupts, bottom-half handlers are called with
interrupts enabled.  Therefore they can't safely use spin_lock(); they
have to use spin_lock_irqsave().  Lockdep warns about a violation
occurring in xhci_irq():

=
[ INFO: possible irq lock inversion dependency detected ]
4.11.0-rc8-dbg+ #1 Not tainted
-
swapper/7/0 just changed the state of lock:
 (&(>lock)->rlock){-.-...}, at: []
ehci_hrtimer_func+0x29/0xc0 [ehci_hcd]
but this lock took another, HARDIRQ-unsafe lock in the past:
 (hcd_urb_list_lock){+.}

and interrupts could create inverse lock ordering between them.

other info that might help us debug this:
 Possible interrupt unsafe locking scenario:

   CPU0CPU1
   
  lock(hcd_urb_list_lock);
   local_irq_disable();
   lock(&(>lock)->rlock);
   lock(hcd_urb_list_lock);
  
lock(&(>lock)->rlock);
 *** DEADLOCK ***

no locks held by swapper/7/0.
the shortest dependencies between 2nd lock and 1st lock:
 -> (hcd_urb_list_lock){+.} ops: 252 {
HARDIRQ-ON-W at:
  __lock_acquire+0x602/0x1280
  lock_acquire+0xd5/0x1c0
  _raw_spin_lock+0x2f/0x40
  usb_hcd_unlink_urb_from_ep+0x1b/0x60 [usbcore]
  xhci_giveback_urb_in_irq.isra.45+0x70/0x1b0 [xhci_hcd]
  finish_td.constprop.60+0x1d8/0x2e0 [xhci_hcd]
  xhci_irq+0xdd6/0x1fa0 [xhci_hcd]
  usb_hcd_irq+0x26/0x40 [usbcore]
  irq_forced_thread_fn+0x2f/0x70
  irq_thread+0x149/0x1d0
  kthread+0x113/0x150
  ret_from_fork+0x2e/0x40

This patch fixes the problem.

Signed-off-by: Alan Stern 
Reported-and-tested-by: Bart Van Assche 
CC: 
Signed-off-by: Mathias Nyman 
---
 drivers/usb/host/xhci-ring.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/drivers/usb/host/xhci-ring.c b/drivers/usb/host/xhci-ring.c
index 0830b25..6d2492c 100644
--- a/drivers/usb/host/xhci-ring.c
+++ b/drivers/usb/host/xhci-ring.c
@@ -2677,11 +2677,12 @@ irqreturn_t xhci_irq(struct usb_hcd *hcd)
struct xhci_hcd *xhci = hcd_to_xhci(hcd);
union xhci_trb *event_ring_deq;
irqreturn_t ret = IRQ_NONE;
+   unsigned long flags;
dma_addr_t deq;
u64 temp_64;
u32 status;
 
-   spin_lock(>lock);
+   spin_lock_irqsave(>lock, flags);
/* Check if the xHC generated the interrupt, or the irq is shared */
status = readl(>op_regs->status);
if (status == ~(u32)0) {
@@ -2754,7 +2755,7 @@ irqreturn_t xhci_irq(struct usb_hcd *hcd)
ret = IRQ_HANDLED;
 
 out:
-   spin_unlock(>lock);
+   spin_unlock_irqrestore(>lock, flags);
 
return ret;
 }
-- 
1.9.1

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

[PATCH 8/8] usb: host: xhci-plat: propagate return value of platform_get_irq()

[Mathias Nyman]

From: Thomas Petazzoni 

platform_get_irq() returns an error code, but the xhci-plat driver
ignores it and always returns -ENODEV. This is not correct, and
prevents -EPROBE_DEFER from being propagated properly.

CC: 
Signed-off-by: Thomas Petazzoni 
Signed-off-by: Mathias Nyman 
---
 drivers/usb/host/xhci-plat.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/usb/host/xhci-plat.c b/drivers/usb/host/xhci-plat.c
index 7c2a9e7..c04144b 100644
--- a/drivers/usb/host/xhci-plat.c
+++ b/drivers/usb/host/xhci-plat.c
@@ -177,7 +177,7 @@ static int xhci_plat_probe(struct platform_device *pdev)
 
irq = platform_get_irq(pdev, 0);
if (irq < 0)
-   return -ENODEV;
+   return irq;
 
/*
 * sysdev must point to a device that is known to the system firmware
-- 
1.9.1

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

[PATCH 7/8] xhci: Fix command ring stop regression in 4.11

[Mathias Nyman]

In 4.11 TRB completion codes were renamed to match spec.

Completion codes for command ring stopped and endpoint stopped
were mixed, leading to failures while handling a stopped command ring.

Use the correct completion code for command ring stopped events.

Fixes: 0b7c105a04ca ("usb: host: xhci: rename completion codes to match spec")
Cc:  # 4.11
Signed-off-by: Mathias Nyman 
---
 drivers/usb/host/xhci-hub.c  | 2 +-
 drivers/usb/host/xhci-ring.c | 8 
 drivers/usb/host/xhci.c  | 8 
 3 files changed, 9 insertions(+), 9 deletions(-)

diff --git a/drivers/usb/host/xhci-hub.c b/drivers/usb/host/xhci-hub.c
index 5e3e9d4..0dde49c 100644
--- a/drivers/usb/host/xhci-hub.c
+++ b/drivers/usb/host/xhci-hub.c
@@ -419,7 +419,7 @@ static int xhci_stop_device(struct xhci_hcd *xhci, int 
slot_id, int suspend)
wait_for_completion(cmd->completion);
 
if (cmd->status == COMP_COMMAND_ABORTED ||
-   cmd->status == COMP_STOPPED) {
+   cmd->status == COMP_COMMAND_RING_STOPPED) {
xhci_warn(xhci, "Timeout while waiting for stop endpoint 
command\n");
ret = -ETIME;
}
diff --git a/drivers/usb/host/xhci-ring.c b/drivers/usb/host/xhci-ring.c
index 6d2492c..03f63f5 100644
--- a/drivers/usb/host/xhci-ring.c
+++ b/drivers/usb/host/xhci-ring.c
@@ -323,7 +323,7 @@ static void xhci_handle_stopped_cmd_ring(struct xhci_hcd 
*xhci,
if (i_cmd->status != COMP_COMMAND_ABORTED)
continue;
 
-   i_cmd->status = COMP_STOPPED;
+   i_cmd->status = COMP_COMMAND_RING_STOPPED;
 
xhci_dbg(xhci, "Turn aborted command %p to no-op\n",
 i_cmd->command_trb);
@@ -1380,7 +1380,7 @@ static void handle_cmd_completion(struct xhci_hcd *xhci,
cmd_comp_code = GET_COMP_CODE(le32_to_cpu(event->status));
 
/* If CMD ring stopped we own the trbs between enqueue and dequeue */
-   if (cmd_comp_code == COMP_STOPPED) {
+   if (cmd_comp_code == COMP_COMMAND_RING_STOPPED) {
complete_all(>cmd_ring_stop_completion);
return;
}
@@ -1436,8 +1436,8 @@ static void handle_cmd_completion(struct xhci_hcd *xhci,
break;
case TRB_CMD_NOOP:
/* Is this an aborted command turned to NO-OP? */
-   if (cmd->status == COMP_STOPPED)
-   cmd_comp_code = COMP_STOPPED;
+   if (cmd->status == COMP_COMMAND_RING_STOPPED)
+   cmd_comp_code = COMP_COMMAND_RING_STOPPED;
break;
case TRB_RESET_EP:
WARN_ON(slot_id != TRB_TO_SLOT_ID(
diff --git a/drivers/usb/host/xhci.c b/drivers/usb/host/xhci.c
index 71eb299..30f47d9 100644
--- a/drivers/usb/host/xhci.c
+++ b/drivers/usb/host/xhci.c
@@ -1764,7 +1764,7 @@ static int xhci_configure_endpoint_result(struct xhci_hcd 
*xhci,
 
switch (*cmd_status) {
case COMP_COMMAND_ABORTED:
-   case COMP_STOPPED:
+   case COMP_COMMAND_RING_STOPPED:
xhci_warn(xhci, "Timeout while waiting for configure endpoint 
command\n");
ret = -ETIME;
break;
@@ -1814,7 +1814,7 @@ static int xhci_evaluate_context_result(struct xhci_hcd 
*xhci,
 
switch (*cmd_status) {
case COMP_COMMAND_ABORTED:
-   case COMP_STOPPED:
+   case COMP_COMMAND_RING_STOPPED:
xhci_warn(xhci, "Timeout while waiting for evaluate context 
command\n");
ret = -ETIME;
break;
@@ -3433,7 +3433,7 @@ static int xhci_discover_or_reset_device(struct usb_hcd 
*hcd,
ret = reset_device_cmd->status;
switch (ret) {
case COMP_COMMAND_ABORTED:
-   case COMP_STOPPED:
+   case COMP_COMMAND_RING_STOPPED:
xhci_warn(xhci, "Timeout waiting for reset device command\n");
ret = -ETIME;
goto command_cleanup;
@@ -3818,7 +3818,7 @@ static int xhci_setup_device(struct usb_hcd *hcd, struct 
usb_device *udev,
 */
switch (command->status) {
case COMP_COMMAND_ABORTED:
-   case COMP_STOPPED:
+   case COMP_COMMAND_RING_STOPPED:
xhci_warn(xhci, "Timeout while waiting for setup device 
command\n");
ret = -ETIME;
break;
-- 
1.9.1

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

[PATCH 0/8] xhci fixes for usb-linus

[Mathias Nyman]

Hi Greg

A bunch of smaller fixes for usb-linus this time, including among others
a lock inversion fix by Alan.

-Mathias

Alan Stern (1):
  USB: xhci: fix lock-inversion problem

Mathias Nyman (3):
  usb: xhci: trace URB before giving it back instead of after
  xhci: apply PME_STUCK_QUIRK and MISSING_CAS quirk for Denverton
  xhci: Fix command ring stop regression in 4.11

Matthias Lange (1):
  xhci: remove GFP_DMA flag from allocation

Peter Chen (2):
  usb: host: xhci-mem: allocate zeroed Scratchpad Buffer
  usb: host: xhci-ring: don't need to clear interrupt pending for MSI
enabled hcd

Thomas Petazzoni (1):
  usb: host: xhci-plat: propagate return value of platform_get_irq()

 drivers/usb/host/xhci-hub.c  |  2 +-
 drivers/usb/host/xhci-mem.c  |  4 ++--
 drivers/usb/host/xhci-pci.c  |  7 +--
 drivers/usb/host/xhci-plat.c |  2 +-
 drivers/usb/host/xhci-ring.c | 20 +---
 drivers/usb/host/xhci.c  | 13 +++--
 include/linux/usb/hcd.h  |  1 +
 7 files changed, 26 insertions(+), 23 deletions(-)

-- 
1.9.1

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

[PATCH 4/8] usb: host: xhci-ring: don't need to clear interrupt pending for MSI enabled hcd

[Mathias Nyman]

From: Peter Chen 

According to xHCI spec Figure 30: Interrupt Throttle Flow Diagram

If PCI Message Signaled Interrupts (MSI or MSI-X) are enabled,
then the assertion of the Interrupt Pending (IP) flag in Figure 30
generates a PCI Dword write. The IP flag is automatically cleared
by the completion of the PCI write.

the MSI enabled HCs don't need to clear interrupt pending bit, but
hcd->irq = 0 doesn't equal to MSI enabled HCD. At some Dual-role
controller software designs, it sets hcd->irq as 0 to avoid HCD
requesting interrupt, and they want to decide when to call usb_hcd_irq
by software.

Signed-off-by: Peter Chen 
Signed-off-by: Mathias Nyman 
---
 drivers/usb/host/xhci-ring.c | 5 +
 drivers/usb/host/xhci.c  | 5 +++--
 include/linux/usb/hcd.h  | 1 +
 3 files changed, 5 insertions(+), 6 deletions(-)

diff --git a/drivers/usb/host/xhci-ring.c b/drivers/usb/host/xhci-ring.c
index 507ba77..0830b25 100644
--- a/drivers/usb/host/xhci-ring.c
+++ b/drivers/usb/host/xhci-ring.c
@@ -2707,12 +2707,9 @@ irqreturn_t xhci_irq(struct usb_hcd *hcd)
 */
status |= STS_EINT;
writel(status, >op_regs->status);
-   /* FIXME when MSI-X is supported and there are multiple vectors */
-   /* Clear the MSI-X event interrupt status */
 
-   if (hcd->irq) {
+   if (!hcd->msi_enabled) {
u32 irq_pending;
-   /* Acknowledge the PCI interrupt */
irq_pending = readl(>ir_set->irq_pending);
irq_pending |= IMAN_IP;
writel(irq_pending, >ir_set->irq_pending);
diff --git a/drivers/usb/host/xhci.c b/drivers/usb/host/xhci.c
index 2d13102..71eb299 100644
--- a/drivers/usb/host/xhci.c
+++ b/drivers/usb/host/xhci.c
@@ -359,9 +359,10 @@ static int xhci_try_enable_msi(struct usb_hcd *hcd)
/* fall back to msi*/
ret = xhci_setup_msi(xhci);
 
-   if (!ret)
-   /* hcd->irq is 0, we have MSI */
+   if (!ret) {
+   hcd->msi_enabled = 1;
return 0;
+   }
 
if (!pdev->irq) {
xhci_err(xhci, "No msi-x/msi found and no IRQ in BIOS\n");
diff --git a/include/linux/usb/hcd.h b/include/linux/usb/hcd.h
index a46..50398b6 100644
--- a/include/linux/usb/hcd.h
+++ b/include/linux/usb/hcd.h
@@ -148,6 +148,7 @@ struct usb_hcd {
unsignedrh_registered:1;/* is root hub registered? */
unsignedrh_pollable:1;  /* may we poll the root hub? */
unsignedmsix_enabled:1; /* driver has MSI-X enabled? */
+   unsignedmsi_enabled:1;  /* driver has MSI enabled? */
unsignedremove_phy:1;   /* auto-remove USB phy */
 
/* The next flag is a stopgap, to be removed when all the HCDs
-- 
1.9.1

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

[PATCH 2/8] xhci: apply PME_STUCK_QUIRK and MISSING_CAS quirk for Denverton

[Mathias Nyman]

Intel Denverton microserver is Atom based and need the PME and CAS quirks
as well.

Cc: stable 
Signed-off-by: Mathias Nyman 
---
 drivers/usb/host/xhci-pci.c | 7 +--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/drivers/usb/host/xhci-pci.c b/drivers/usb/host/xhci-pci.c
index 7b86508..fcf1f3f 100644
--- a/drivers/usb/host/xhci-pci.c
+++ b/drivers/usb/host/xhci-pci.c
@@ -52,6 +52,7 @@
 #define PCI_DEVICE_ID_INTEL_BROXTON_M_XHCI 0x0aa8
 #define PCI_DEVICE_ID_INTEL_BROXTON_B_XHCI 0x1aa8
 #define PCI_DEVICE_ID_INTEL_APL_XHCI   0x5aa8
+#define PCI_DEVICE_ID_INTEL_DNV_XHCI   0x19d0
 
 static const char hcd_name[] = "xhci_hcd";
 
@@ -166,7 +167,8 @@ static void xhci_pci_quirks(struct device *dev, struct 
xhci_hcd *xhci)
 pdev->device == PCI_DEVICE_ID_INTEL_CHERRYVIEW_XHCI ||
 pdev->device == PCI_DEVICE_ID_INTEL_BROXTON_M_XHCI ||
 pdev->device == PCI_DEVICE_ID_INTEL_BROXTON_B_XHCI ||
-pdev->device == PCI_DEVICE_ID_INTEL_APL_XHCI)) {
+pdev->device == PCI_DEVICE_ID_INTEL_APL_XHCI ||
+pdev->device == PCI_DEVICE_ID_INTEL_DNV_XHCI)) {
xhci->quirks |= XHCI_PME_STUCK_QUIRK;
}
if (pdev->vendor == PCI_VENDOR_ID_INTEL &&
@@ -175,7 +177,8 @@ static void xhci_pci_quirks(struct device *dev, struct 
xhci_hcd *xhci)
}
if (pdev->vendor == PCI_VENDOR_ID_INTEL &&
(pdev->device == PCI_DEVICE_ID_INTEL_CHERRYVIEW_XHCI ||
-pdev->device == PCI_DEVICE_ID_INTEL_APL_XHCI))
+pdev->device == PCI_DEVICE_ID_INTEL_APL_XHCI ||
+pdev->device == PCI_DEVICE_ID_INTEL_DNV_XHCI))
xhci->quirks |= XHCI_MISSING_CAS;
 
if (pdev->vendor == PCI_VENDOR_ID_ETRON &&
-- 
1.9.1

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

[PATCH 6/8] xhci: remove GFP_DMA flag from allocation

[Mathias Nyman]

From: Matthias Lange 

There is no reason to restrict allocations to the first 16MB ISA DMA
addresses.

It is causing problems in a virtualization setup with enabled IOMMU
(x86_64). The result is that USB is not working in the VM.

CC: 
Signed-off-by: Matthias Lange 
Signed-off-by: Mathias Nyman 
---
 drivers/usb/host/xhci-mem.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/usb/host/xhci-mem.c b/drivers/usb/host/xhci-mem.c
index 12b573c..1f1687e 100644
--- a/drivers/usb/host/xhci-mem.c
+++ b/drivers/usb/host/xhci-mem.c
@@ -56,7 +56,7 @@ static struct xhci_segment *xhci_segment_alloc(struct 
xhci_hcd *xhci,
}
 
if (max_packet) {
-   seg->bounce_buf = kzalloc(max_packet, flags | GFP_DMA);
+   seg->bounce_buf = kzalloc(max_packet, flags);
if (!seg->bounce_buf) {
dma_pool_free(xhci->segment_pool, seg->trbs, dma);
kfree(seg);
-- 
1.9.1

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

[PATCH 1/8] usb: xhci: trace URB before giving it back instead of after

[Mathias Nyman]

Don't access any members of a URB after giving it back.
URB might be freed by then already.

Signed-off-by: Mathias Nyman 
---
 drivers/usb/host/xhci-ring.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/usb/host/xhci-ring.c b/drivers/usb/host/xhci-ring.c
index 74bf5c6..507ba77 100644
--- a/drivers/usb/host/xhci-ring.c
+++ b/drivers/usb/host/xhci-ring.c
@@ -641,8 +641,8 @@ static void xhci_giveback_urb_in_irq(struct xhci_hcd *xhci,
xhci_urb_free_priv(urb_priv);
usb_hcd_unlink_urb_from_ep(hcd, urb);
spin_unlock(>lock);
-   usb_hcd_giveback_urb(hcd, urb, status);
trace_xhci_urb_giveback(urb);
+   usb_hcd_giveback_urb(hcd, urb, status);
spin_lock(>lock);
 }
 
-- 
1.9.1

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

[PATCH 3/8] usb: host: xhci-mem: allocate zeroed Scratchpad Buffer

[Mathias Nyman]

From: Peter Chen 

According to xHCI ch4.20 Scratchpad Buffers, the Scratchpad
Buffer needs to be zeroed.

...
The following operations take place to allocate
Scratchpad Buffers to the xHC:
...
b. Software clears the Scratchpad Buffer to '0'

Cc: stable 
Signed-off-by: Peter Chen 
Signed-off-by: Mathias Nyman 
---
 drivers/usb/host/xhci-mem.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/usb/host/xhci-mem.c b/drivers/usb/host/xhci-mem.c
index 69428e9..12b573c 100644
--- a/drivers/usb/host/xhci-mem.c
+++ b/drivers/usb/host/xhci-mem.c
@@ -1724,7 +1724,7 @@ static int scratchpad_alloc(struct xhci_hcd *xhci, gfp_t 
flags)
xhci->dcbaa->dev_context_ptrs[0] = 
cpu_to_le64(xhci->scratchpad->sp_dma);
for (i = 0; i < num_sp; i++) {
dma_addr_t dma;
-   void *buf = dma_alloc_coherent(dev, xhci->page_size, ,
+   void *buf = dma_zalloc_coherent(dev, xhci->page_size, ,
flags);
if (!buf)
goto fail_sp4;
-- 
1.9.1

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

Re: [PATCH] USB: qcserial: add more Lenovo EM74xx device IDs

[Johan Hovold]

On Wed, May 17, 2017 at 04:30:50PM +0200, Bjørn Mork wrote:
> In their infinite wisdom, and never ending quest for end user frustration,
> Lenovo has decided to use new USB device IDs for the wwan modules in
> their 2017 laptops.  The actual hardware is still the Sierra Wireless
> EM7455 or EM7430, depending on region.
> 
> Cc: 
> Signed-off-by: Bjørn Mork 

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

[PATCH net,stable] qmi_wwan: add another Lenovo EM74xx device ID

[Bjørn Mork]

In their infinite wisdom, and never ending quest for end user frustration,
Lenovo has decided to use a new USB device ID for the wwan modules in
their 2017 laptops.  The actual hardware is still the Sierra Wireless
EM7455 or EM7430, depending on region.

Signed-off-by: Bjørn Mork 
---
 drivers/net/usb/qmi_wwan.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/net/usb/qmi_wwan.c b/drivers/net/usb/qmi_wwan.c
index d7165767ca9d..8f923a147fa9 100644
--- a/drivers/net/usb/qmi_wwan.c
+++ b/drivers/net/usb/qmi_wwan.c
@@ -1196,6 +1196,8 @@ static const struct usb_device_id products[] = {
{QMI_FIXED_INTF(0x1199, 0x9071, 10)},   /* Sierra Wireless MC74xx */
{QMI_FIXED_INTF(0x1199, 0x9079, 8)},/* Sierra Wireless EM74xx */
{QMI_FIXED_INTF(0x1199, 0x9079, 10)},   /* Sierra Wireless EM74xx */
+   {QMI_FIXED_INTF(0x1199, 0x907b, 8)},/* Sierra Wireless EM74xx */
+   {QMI_FIXED_INTF(0x1199, 0x907b, 10)},   /* Sierra Wireless EM74xx */
{QMI_FIXED_INTF(0x1bbb, 0x011e, 4)},/* Telekom Speedstick LTE II 
(Alcatel One Touch L100V LTE) */
{QMI_FIXED_INTF(0x1bbb, 0x0203, 2)},/* Alcatel L800MA */
{QMI_FIXED_INTF(0x2357, 0x0201, 4)},/* TP-LINK HSUPA Modem MA180 */
-- 
2.11.0

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

[PATCH] USB: qcserial: add more Lenovo EM74xx device IDs

[Bjørn Mork]

In their infinite wisdom, and never ending quest for end user frustration,
Lenovo has decided to use new USB device IDs for the wwan modules in
their 2017 laptops.  The actual hardware is still the Sierra Wireless
EM7455 or EM7430, depending on region.

Cc: 
Signed-off-by: Bjørn Mork 
---
 drivers/usb/serial/qcserial.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/usb/serial/qcserial.c b/drivers/usb/serial/qcserial.c
index 38b3f0d8cd58..fd509ed6cf70 100644
--- a/drivers/usb/serial/qcserial.c
+++ b/drivers/usb/serial/qcserial.c
@@ -162,6 +162,8 @@ static const struct usb_device_id id_table[] = {
{DEVICE_SWI(0x1199, 0x9071)},   /* Sierra Wireless MC74xx */
{DEVICE_SWI(0x1199, 0x9078)},   /* Sierra Wireless EM74xx */
{DEVICE_SWI(0x1199, 0x9079)},   /* Sierra Wireless EM74xx */
+   {DEVICE_SWI(0x1199, 0x907a)},   /* Sierra Wireless EM74xx QDL */
+   {DEVICE_SWI(0x1199, 0x907b)},   /* Sierra Wireless EM74xx */
{DEVICE_SWI(0x413c, 0x81a2)},   /* Dell Wireless 5806 Gobi(TM) 4G LTE 
Mobile Broadband Card */
{DEVICE_SWI(0x413c, 0x81a3)},   /* Dell Wireless 5570 HSPA+ (42Mbps) 
Mobile Broadband Card */
{DEVICE_SWI(0x413c, 0x81a4)},   /* Dell Wireless 5570e HSPA+ (42Mbps) 
Mobile Broadband Card */
-- 
2.11.0

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

RE: [PATCH] USB: core: replace %p with %pK

[David Laight]

From: Greg KH
> Sent: 16 May 2017 11:19
> Format specifier %p can leak kernel addresses while not valuing the
> kptr_restrict system settings. When kptr_restrict is set to (1), kernel
> pointers printed using the %pK format specifier will be replaced with
> Zeros. Debugging Note :  prints only Zeros as address. If you need
> actual address information, write 0 to kptr_restrict.
> 
> echo 0 > /proc/sys/kernel/kptr_restrict

ISTM that kptr_restrict ought to affect all %p, except a few that
would be annotated as user pointers (or look at the value??).

Would also be better to output (say)  rather than 0.
Although 0x0 could be output for NULL pointers.

David

--
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: typec: Defer checking of valid power role swap to low level drivers

[Heikki Krogerus]

On Wed, May 17, 2017 at 06:02:47AM -0700, Guenter Roeck wrote:
> On 05/17/2017 05:38 AM, Heikki Krogerus wrote:
> > Hi guys,
> > 
> > On Wed, May 17, 2017 at 02:36:44AM -0700, Guenter Roeck wrote:
> > > On 05/17/2017 12:34 AM, Oliver Neukum wrote:
> > > > Am Mittwoch, den 17.05.2017, 00:32 -0700 schrieb Badhri Jagan
> > > > Sridharan:
> > > > 
> > > > Hi,
> > > > 
> > > > > "Two independent set of mechanisms are defined to allow a USB Type-C
> > > > > DRP to functionally swap power and data roles. When USB PD is
> > > > > supported, power and data role swapping is performed as a subsequent
> > > > > step following the initial connection process. For non-PD 
> > > > > implementations,
> > > > > power/data role swapping can optionally be dealt with as part of the 
> > > > > initial
> > > > > connection process."
> > > > 
> > > > Well, as I read it, without PD once a connection is established, you
> > > > are stuck with your role. So it seems to me that blocking a later
> > > > attempt to change it makes sense.
> > > > 
> > > 
> > > That seems to be a harsh and not very user friendly reading of the 
> > > specification.
> > > 
> > > I would argue that the user doesn't care if the partner supports PD or not
> > > when selecting a role, and I would prefer to provide an implementation 
> > > which is
> > > as user friendly as possible.
> > 
> > I agree. But I have to point out that at least with UCSI, the role
> > swapping is usually not possible without USB PD connection.
> > 
> > So what I'm trying to say is that we can't really promise that role
> > swapping will ever be possible in all cases without PD, which may mean
> > different behavior depending on the platform. I don't know if that is
> > a huge problem.
> > 
> > How predictable do we want this interface to function with role
> > swapping?
> > 
> 
> We can only do as good as we can, but we should not preclude it either.
> PR_SWAP and other swap operations fail a lot in practice with many dongles,
> just because the PD protocol implementation isn't always stable. So even that
> won't be predictable for some time to come.
> 
> As Badhri pointed out earlier, at least some low cost devices won't support 
> PD.
> Since we are talking about high volume products, we _have_ to make it as
> user friendly as we can, if for nothing else to reduce the number of customer
> service calls, repeated bug filings, and, last but not least, to avoid bad 
> press.

OK. So I think we just need to explain in the documentation that there
are no guarantees with role swapping.


Thanks,

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

Re: [PATCH] usb: dwc3: replace %p with %pK

[Greg KH]

On Wed, May 17, 2017 at 04:02:33PM +0300, Felipe Balbi wrote:
> %p will leak kernel pointers, so let's not expose the information on
> dmesg and instead use %pK. %pK will only show the actual addresses if
> explicitly enabled under /proc/sys/kernel/kptr_restrict.
> 
> Signed-off-by: Felipe Balbi 
> ---
> 
> Inspired by a recent patch Greg posted. Note that I've kept
> tracepoints with %p because you already need admin rights to mount
> tracefs and/or debugfs. If folks think tracepoints should be changed
> to %pK too, let me know and I'll change the patch.

I don't think that tracepoints have to be changed, so this should be
fine for now.

Acked-by: Greg Kroah-Hartman 

And care to mark this for stable?

thanks,

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

Re: [RFC][PATCH 0/3] add EXTCON_CHG_USB_* cables to MSM USB phy

[Damien Riegel]

Hi,

On Fri, Apr 14, 2017 at 02:43:27PM -0400, Damien Riegel wrote:
> This patchset adds a way for the MSM USB phy to notify a power supply
> when the charging state changes. It achieves that using the extcon
> subsystem.
> 
> The first patch makes sure msm_otg_notify_charger is called after the
> charger attributes have been set.
> The second one makes sure that function is called when unplugging a
> "in-the-wall" charger.
> The last one adds EXTCON_CHG_USB_* cables to the phy.
> 
> 
> I send this patchset as RFC because it seems a bit peculiar to have
> different drivers that generate the EXTCON_USB_* and EXTCON_CHG_USB_*
> events, so I want to make sure to get things right.
> 
> As far as I can tell, all the drivers in the kernel that have USB
> charger events also have the EXTCON_USB one. In this case, this patchset
> would make things a bit different for the MSM phy:
> 
>+--+  +--+
>|   gpio   |  | PMIC |<-+
>+--+  +--+  |
>||  |
>`+  |  EXTCON_CHG_USB_*
> |  |   events
> EXTCON_USB  |  |
>   events|  |
>\|/ |
>  +--+  |
>  |   USB PHY|--+
>  +--+
>
> Text version: EXTCON_USB comes from a GPIO or a PMIC, that triggers a
> notifier in the USB phy. That notifier will determine the new
> EXTCON_CHG_USB_XXX state and the PMIC will be notified about it and
> determine how much current it can use to charge a battery.
> 
> Please let me know if this is the correct way to go.

I wanted to know if someone has any comment to make on this patchset?
I'm currently working on the PMIC driver and it uses the EXTCON
notifications, so I just want to make sure it makes sense to do that.

Thanks,
-- 
Damien
--
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 3/9] usb: dwc3: debugfs: slightly improve output of trb_ring

[Felipe Balbi]

Instead of printing out enqueue and dequeue pointer value as a header
to the output, let's mark the TRBs in question with 'E' and 'D'. The
output looks slightly easier to read.

Signed-off-by: Felipe Balbi 
---
 drivers/usb/dwc3/debugfs.c | 9 -
 1 file changed, 4 insertions(+), 5 deletions(-)

diff --git a/drivers/usb/dwc3/debugfs.c b/drivers/usb/dwc3/debugfs.c
index 7be963dd8e3b..4e09be80e59f 100644
--- a/drivers/usb/dwc3/debugfs.c
+++ b/drivers/usb/dwc3/debugfs.c
@@ -653,16 +653,13 @@ static int dwc3_ep_trb_ring_show(struct seq_file *s, void 
*unused)
goto out;
}
 
-   seq_printf(s, "enqueue pointer %d\n", dep->trb_enqueue);
-   seq_printf(s, "dequeue pointer %d\n", dep->trb_dequeue);
-   seq_printf(s, 
"\n--\n\n");
seq_printf(s, "buffer_addr,size,type,ioc,isp_imi,csp,chn,lst,hwo\n");
 
for (i = 0; i < DWC3_TRB_NUM; i++) {
struct dwc3_trb *trb = >trb_pool[i];
unsigned int type = DWC3_TRBCTL_TYPE(trb->ctrl);
 
-   seq_printf(s, "%08x%08x,%d,%s,%d,%d,%d,%d,%d,%d\n",
+   seq_printf(s, "%08x%08x,%d,%s,%d,%d,%d,%d,%d,%d   %c%c\n",
trb->bph, trb->bpl, trb->size,
dwc3_trb_type_string(type),
!!(trb->ctrl & DWC3_TRB_CTRL_IOC),
@@ -670,7 +667,9 @@ static int dwc3_ep_trb_ring_show(struct seq_file *s, void 
*unused)
!!(trb->ctrl & DWC3_TRB_CTRL_CSP),
!!(trb->ctrl & DWC3_TRB_CTRL_CHN),
!!(trb->ctrl & DWC3_TRB_CTRL_LST),
-   !!(trb->ctrl & DWC3_TRB_CTRL_HWO));
+   !!(trb->ctrl & DWC3_TRB_CTRL_HWO),
+   dep->trb_enqueue == i ? 'E' : ' ',
+   dep->trb_dequeue == i ? 'D' : ' ');
}
 
 out:
-- 
2.11.0.295.gd7dffce1ce

--
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 8/9] usb: dwc3: add ReST documentation

[Felipe Balbi]

Document a few details about DWC3 in order to help people report bugs
and debug DWC3.

Signed-off-by: Felipe Balbi 
---
 Documentation/driver-api/usb/dwc3.rst  | 712 +
 Documentation/driver-api/usb/index.rst |   1 +
 2 files changed, 713 insertions(+)
 create mode 100644 Documentation/driver-api/usb/dwc3.rst

diff --git a/Documentation/driver-api/usb/dwc3.rst 
b/Documentation/driver-api/usb/dwc3.rst
new file mode 100644
index ..c3dc84a50ce5
--- /dev/null
+++ b/Documentation/driver-api/usb/dwc3.rst
@@ -0,0 +1,712 @@
+===
+Synopsys DesignWare Core SuperSpeed USB 3.0 Controller
+===
+
+:Author: Felipe Balbi 
+:Date: April 2017
+
+Introduction
+
+
+The *Synopsys DesignWare Core SuperSpeed USB 3.0 Controller*
+(hereinafter referred to as *DWC3*) is a USB SuperSpeed compliant
+controller which can be configured in one of 4 ways:
+
+   1. Peripheral-only configuration
+   2. Host-only configuration
+   3. Dual-Role configuration
+   4. Hub configuration
+
+Linux currently supports several versions of this controller. In all
+likelyhood, the version in your SoC is already supported. At the time
+of this writing, known tested versions range from 2.02a to 3.10a. As a
+rule of thumb, anything above 2.02a should work reliably well.
+
+Currently, we have many known users for this driver. In alphabetical
+order:
+
+   1. Cavium
+   2. Intel Corporation
+   3. Qualcomm
+   4. Rockchip
+   5. ST
+   6. Samsung
+   7. Texas Instruments
+   8. Xilinx
+
+Summary of Features
+==
+
+For details about features supported by your version of DWC3, consult
+your IP team and/or *Synopsys DesignWare Core SuperSpeed USB 3.0
+Controller Databook*. Following is a list of features supported by the
+driver at the time of this writing:
+
+   1. Up to 16 bidirectional endpoints (including the control
+  pipe - ep0)
+   2. Flexible endpoint configuration
+   3. Simultaneous IN and OUT transfer support
+   4. Scatter-list support
+   5. Up to 256 TRBs [#trb]_ per endpoint
+   6. Support for all transfer types (*Control*, *Bulk*,
+  *Interrupt*, and *Isochronous*)
+   7. SuperSpeed Bulk Streams
+   8. Link Power Management
+   9. Trace Events for debugging
+   10. DebugFS [#debugfs]_ interface
+
+These features have all been exercised with many of the **in-tree**
+gadget drivers. We have verified both *ConfigFS* [#configfs]_ and
+legacy gadget drivers.
+
+Driver Design
+==
+
+The DWC3 driver sits on the *drivers/usb/dwc3/* directory. All files
+related to this driver are in this one directory. This makes it easy
+for new-comers to read the code and understand how it behaves.
+
+Because of DWC3's configuration flexibility, the driver is a little
+complex in some places but it should be rather straightforward to
+understand.
+
+The biggest part of the driver refers to the Gadget API.
+
+Known Limitations
+===
+
+Like any other HW, DWC3 has its own set of limitations. To avoid
+constant questions about such problems, we decided to document them
+here and have a single location to where we could point users.
+
+OUT Transfer Size Requirements
+-
+
+According to Synopsys Databook, all OUT transfer TRBs [#trb]_ must
+have their *size* field set to a value which is integer divisible by
+the endpoint's *wMaxPacketSize*. This means that *e.g.* in order to
+receive a Mass Storage *CBW* [#cbw]_, req->length must either be set
+to a value that's divisible by *wMaxPacketSize* (1024 on SuperSpeed,
+512 on HighSpeed, etc), or DWC3 driver must add a Chained TRB pointing
+to a throw-away buffer for the remaining length. Without this, OUT
+transfers will **NOT** start.
+
+Note that as of this writing, this won't be a problem because DWC3 is
+fully capable of appending a chained TRB for the remaining length and
+completely hide this detail from the gadget driver. It's still worth
+mentioning because this seems to be the largest source of queries
+about DWC3 and *non-working transfers*.
+
+TRB Ring Size Limitation
+-
+
+We, currently, have a hard limit of 256 TRBs [#trb]_ per endpoint,
+with the last TRB being a Link TRB [#link_trb]_ pointing back to the
+first. This limit is arbitrary but it has the benefit of adding up to
+exactly 4096 bytes, or 1 Page.
+
+DWC3 driver will try its best to cope with more than 255 requests and,
+for the most part, it should work normally. However this is not
+something that has been exercised very frequently. If you experience
+any problems, see section **Reporting Bugs** below.
+
+Reporting Bugs
+
+
+Whenever you encounter a problem with DWC3, first and foremost you
+should 

[PATCH v2 9/9] usb: move ReST documentation to Documentation/driver-api/usb/

[Felipe Balbi]

This is where all other USB ReST documentation has moved to.

Signed-off-by: Felipe Balbi 
---
 Documentation/driver-api/usb/index.rst | 2 ++
 Documentation/{ => driver-api}/usb/typec.rst   | 0
 Documentation/{ => driver-api}/usb/usb3-debug-port.rst | 0
 3 files changed, 2 insertions(+)
 rename Documentation/{ => driver-api}/usb/typec.rst (100%)
 rename Documentation/{ => driver-api}/usb/usb3-debug-port.rst (100%)

diff --git a/Documentation/driver-api/usb/index.rst 
b/Documentation/driver-api/usb/index.rst
index 3d357a83046b..8fe995a1ec94 100644
--- a/Documentation/driver-api/usb/index.rst
+++ b/Documentation/driver-api/usb/index.rst
@@ -18,6 +18,8 @@ Linux USB API
writing_usb_driver
dwc3
writing_musb_glue_layer
+   typec
+   usb3-debug-port
 
 .. only::  subproject and html
 
diff --git a/Documentation/usb/typec.rst 
b/Documentation/driver-api/usb/typec.rst
similarity index 100%
rename from Documentation/usb/typec.rst
rename to Documentation/driver-api/usb/typec.rst
diff --git a/Documentation/usb/usb3-debug-port.rst 
b/Documentation/driver-api/usb/usb3-debug-port.rst
similarity index 100%
rename from Documentation/usb/usb3-debug-port.rst
rename to Documentation/driver-api/usb/usb3-debug-port.rst
-- 
2.11.0.295.gd7dffce1ce

--
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 5/9] usb: dwc3: trace: rely on __string() and __assign_str()

[Felipe Balbi]

Instead of going for a 512 byte buffer and using snprintf(), let's
rely on helps __string() and __assign_str() where possible.

Signed-off-by: Felipe Balbi 
---
 drivers/usb/dwc3/trace.h | 16 
 1 file changed, 8 insertions(+), 8 deletions(-)

diff --git a/drivers/usb/dwc3/trace.h b/drivers/usb/dwc3/trace.h
index f1bd444d22a3..15909b579e69 100644
--- a/drivers/usb/dwc3/trace.h
+++ b/drivers/usb/dwc3/trace.h
@@ -107,7 +107,7 @@ DECLARE_EVENT_CLASS(dwc3_log_request,
TP_PROTO(struct dwc3_request *req),
TP_ARGS(req),
TP_STRUCT__entry(
-   __dynamic_array(char, name, DWC3_MSG_MAX)
+   __string(name, req->dep->name)
__field(struct dwc3_request *, req)
__field(unsigned, actual)
__field(unsigned, length)
@@ -117,7 +117,7 @@ DECLARE_EVENT_CLASS(dwc3_log_request,
__field(int, no_interrupt)
),
TP_fast_assign(
-   snprintf(__get_str(name), DWC3_MSG_MAX, "%s", req->dep->name);
+   __assign_str(name, req->dep->name);
__entry->req = req;
__entry->actual = req->request.actual;
__entry->length = req->request.length;
@@ -190,7 +190,7 @@ DECLARE_EVENT_CLASS(dwc3_log_gadget_ep_cmd,
struct dwc3_gadget_ep_cmd_params *params, int cmd_status),
TP_ARGS(dep, cmd, params, cmd_status),
TP_STRUCT__entry(
-   __dynamic_array(char, name, DWC3_MSG_MAX)
+   __string(name, dep->name)
__field(unsigned int, cmd)
__field(u32, param0)
__field(u32, param1)
@@ -198,7 +198,7 @@ DECLARE_EVENT_CLASS(dwc3_log_gadget_ep_cmd,
__field(int, cmd_status)
),
TP_fast_assign(
-   snprintf(__get_str(name), DWC3_MSG_MAX, "%s", dep->name);
+   __assign_str(name, dep->name);
__entry->cmd = cmd;
__entry->param0 = params->param0;
__entry->param1 = params->param1;
@@ -223,7 +223,7 @@ DECLARE_EVENT_CLASS(dwc3_log_trb,
TP_PROTO(struct dwc3_ep *dep, struct dwc3_trb *trb),
TP_ARGS(dep, trb),
TP_STRUCT__entry(
-   __dynamic_array(char, name, DWC3_MSG_MAX)
+   __string(name, dep->name)
__field(struct dwc3_trb *, trb)
__field(u32, allocated)
__field(u32, queued)
@@ -234,7 +234,7 @@ DECLARE_EVENT_CLASS(dwc3_log_trb,
__field(u32, type)
),
TP_fast_assign(
-   snprintf(__get_str(name), DWC3_MSG_MAX, "%s", dep->name);
+   __assign_str(name, dep->name);
__entry->trb = trb;
__entry->allocated = dep->allocated_requests;
__entry->queued = dep->queued_requests;
@@ -291,7 +291,7 @@ DECLARE_EVENT_CLASS(dwc3_log_ep,
TP_PROTO(struct dwc3_ep *dep),
TP_ARGS(dep),
TP_STRUCT__entry(
-   __dynamic_array(char, name, DWC3_MSG_MAX)
+   __string(name, dep->name)
__field(unsigned, maxpacket)
__field(unsigned, maxpacket_limit)
__field(unsigned, max_streams)
@@ -302,7 +302,7 @@ DECLARE_EVENT_CLASS(dwc3_log_ep,
__field(u8, trb_dequeue)
),
TP_fast_assign(
-   snprintf(__get_str(name), DWC3_MSG_MAX, "%s", dep->name);
+   __assign_str(name, dep->name);
__entry->maxpacket = dep->endpoint.maxpacket;
__entry->maxpacket_limit = dep->endpoint.maxpacket_limit;
__entry->max_streams = dep->endpoint.max_streams;
-- 
2.11.0.295.gd7dffce1ce

--
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 2/9] usb: dwc3: update documentation

[Felipe Balbi]

No functional changes, just making sure we can use these for ReST docs
later.

Signed-off-by: Felipe Balbi 
---
 drivers/usb/dwc3/core.h   |  44 +
 drivers/usb/dwc3/ep0.c|   2 +-
 drivers/usb/dwc3/gadget.c | 121 +++---
 drivers/usb/dwc3/gadget.h |  22 +++--
 4 files changed, 124 insertions(+), 65 deletions(-)

diff --git a/drivers/usb/dwc3/core.h b/drivers/usb/dwc3/core.h
index 6f6294dbea9d..ea910acb4bb0 100644
--- a/drivers/usb/dwc3/core.h
+++ b/drivers/usb/dwc3/core.h
@@ -1,4 +1,4 @@
-/**
+/*
  * core.h - DesignWare USB3 DRD Core Header
  *
  * Copyright (C) 2010-2011 Texas Instruments Incorporated - http://www.ti.com
@@ -523,7 +523,6 @@ struct dwc3_event_buffer {
  * @trb_pool_dma: dma address of @trb_pool
  * @trb_enqueue: enqueue 'pointer' into TRB array
  * @trb_dequeue: dequeue 'pointer' into TRB array
- * @desc: usb_endpoint_descriptor pointer
  * @dwc: pointer to DWC controller
  * @saved_state: ep state saved during hibernation
  * @flags: endpoint flags (wedged, stalled, ...)
@@ -665,7 +664,7 @@ enum dwc3_link_state {
  * @bpl: DW0-3
  * @bph: DW4-7
  * @size: DW8-B
- * @trl: DWC-F
+ * @ctrl: DWC-F
  */
 struct dwc3_trb {
u32 bpl;
@@ -675,16 +674,16 @@ struct dwc3_trb {
 } __packed;
 
 /**
- * dwc3_hwparams - copy of HWPARAMS registers
- * @hwparams0 - GHWPARAMS0
- * @hwparams1 - GHWPARAMS1
- * @hwparams2 - GHWPARAMS2
- * @hwparams3 - GHWPARAMS3
- * @hwparams4 - GHWPARAMS4
- * @hwparams5 - GHWPARAMS5
- * @hwparams6 - GHWPARAMS6
- * @hwparams7 - GHWPARAMS7
- * @hwparams8 - GHWPARAMS8
+ * struct dwc3_hwparams - copy of HWPARAMS registers
+ * @hwparams0: GHWPARAMS0
+ * @hwparams1: GHWPARAMS1
+ * @hwparams2: GHWPARAMS2
+ * @hwparams3: GHWPARAMS3
+ * @hwparams4: GHWPARAMS4
+ * @hwparams5: GHWPARAMS5
+ * @hwparams6: GHWPARAMS6
+ * @hwparams7: GHWPARAMS7
+ * @hwparams8: GHWPARAMS8
  */
 struct dwc3_hwparams {
u32 hwparams0;
@@ -731,7 +730,8 @@ struct dwc3_hwparams {
  * @unaligned: true for OUT endpoints with length not divisible by maxp
  * @direction: IN or OUT direction flag
  * @mapped: true when request has been dma-mapped
- * @queued: true when request has been queued to HW
+ * @started: request is started
+ * @zero: wants a ZLP
  */
 struct dwc3_request {
struct usb_request  request;
@@ -762,17 +762,23 @@ struct dwc3_scratchpad_array {
 
 /**
  * struct dwc3 - representation of our controller
- * @drd_work - workqueue used for role swapping
+ * @drd_work: workqueue used for role swapping
  * @ep0_trb: trb which is used for the ctrl_req
+ * @bounce: address of bounce buffer
+ * @scratchbuf: address of scratch buffer
  * @setup_buf: used while precessing STD USB requests
- * @ep0_trb: dma address of ep0_trb
+ * @ep0_trb_addr: dma address of @ep0_trb
+ * @bounce_addr: dma address of @bounce
  * @ep0_usb_req: dummy req used while handling STD USB requests
  * @scratch_addr: dma address of scratchbuf
  * @ep0_in_setup: one control transfer is completed and enter setup phase
  * @lock: for synchronizing
  * @dev: pointer to our struct device
+ * @sysdev: pointer to the DMA-capable device
  * @xhci: pointer to our xHCI child
- * @event_buffer_list: a list of event buffers
+ * @xhci_resources: struct resources for our @xhci child
+ * @ev_buf: struct dwc3_event_buffer pointer
+ * @eps: endpoint array
  * @gadget: device side representation of the peripheral controller
  * @gadget_driver: pointer to the gadget driver
  * @regs: base address for our registers
@@ -796,8 +802,6 @@ struct dwc3_scratchpad_array {
  * @usb2_generic_phy: pointer to USB2 PHY
  * @usb3_generic_phy: pointer to USB3 PHY
  * @ulpi: pointer to ulpi interface
- * @dcfg: saved contents of DCFG register
- * @gctl: saved contents of GCTL register
  * @isoch_delay: wValue from Set Isochronous Delay request;
  * @u2sel: parameter from Set SEL request.
  * @u2pel: parameter from Set SEL request.
@@ -831,7 +835,6 @@ struct dwc3_scratchpad_array {
  * @pending_events: true when we have pending IRQs to be handled
  * @pullups_connected: true when Run/Stop bit is set
  * @setup_packet_pending: true when there's a Setup Packet in FIFO. Workaround
- * @start_config_issued: true when StartConfig command has been issued
  * @three_stage_setup: set if we perform a three phase setup
  * @usb3_lpm_capable: set if hadrware supports Link Power Management
  * @disable_scramble_quirk: set if we enable the disable scramble quirk
@@ -846,6 +849,7 @@ struct dwc3_scratchpad_array {
  * @dis_u2_susphy_quirk: set if we disable usb2 suspend phy
  * @dis_enblslpm_quirk: set if we clear enblslpm in GUSB2PHYCFG,
  *  disabling the suspend signal to the PHY.
+ * @dis_rxdet_inp3_quirk: set if we disable Rx.Detect in P3
  * @dis_u2_freeclk_exists_quirk : set if we clear u2_freeclk_exists
  * in GUSB2PHYCFG, specify that USB2 PHY doesn't
  * provide a free-running PHY clock.

[PATCH v2 4/9] usb: dwc3: gadget: slight cleanup to dwc3_process_event_entry()

[Felipe Balbi]

No functional changes, just a slight readability improvement.

Signed-off-by: Felipe Balbi 
---
 drivers/usb/dwc3/gadget.c | 16 
 1 file changed, 4 insertions(+), 12 deletions(-)

diff --git a/drivers/usb/dwc3/gadget.c b/drivers/usb/dwc3/gadget.c
index e4e872c703f1..d2bd28dc28b6 100644
--- a/drivers/usb/dwc3/gadget.c
+++ b/drivers/usb/dwc3/gadget.c
@@ -2972,20 +2972,12 @@ static void dwc3_process_event_entry(struct dwc3 *dwc,
 {
trace_dwc3_event(event->raw, dwc);
 
-   /* Endpoint IRQ, handle it and return early */
-   if (event->type.is_devspec == 0) {
-   /* depevt */
-   return dwc3_endpoint_interrupt(dwc, >depevt);
-   }
-
-   switch (event->type.type) {
-   case DWC3_EVENT_TYPE_DEV:
+   if (!event->type.is_devspec)
+   dwc3_endpoint_interrupt(dwc, >depevt);
+   else if (event->type.type == DWC3_EVENT_TYPE_DEV)
dwc3_gadget_interrupt(dwc, >devt);
-   break;
-   /* REVISIT what to do with Carkit and I2C events ? */
-   default:
+   else
dev_err(dwc->dev, "UNKNOWN IRQ type %d\n", event->raw);
-   }
 }
 
 static irqreturn_t dwc3_process_event_buf(struct dwc3_event_buffer *evt)
-- 
2.11.0.295.gd7dffce1ce

--
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 6/9] usb: dwc3: debug: remove static char buffer from dwc3_decode_event()

[Felipe Balbi]

Instead, we can require caller to pass a buffer for the function to
use. This cleans things quite a bit.

Signed-off-by: Felipe Balbi 
---
 drivers/usb/dwc3/debug.h | 13 ++---
 drivers/usb/dwc3/trace.h |  4 +++-
 2 files changed, 9 insertions(+), 8 deletions(-)

diff --git a/drivers/usb/dwc3/debug.h b/drivers/usb/dwc3/debug.h
index cb2d8d3f7f3d..1025713ebdd1 100644
--- a/drivers/usb/dwc3/debug.h
+++ b/drivers/usb/dwc3/debug.h
@@ -173,9 +173,8 @@ static inline const char *dwc3_ep0_state_string(enum 
dwc3_ep0_state state)
  * @event: the event code
  */
 static inline const char *
-dwc3_gadget_event_string(const struct dwc3_event_devt *event)
+dwc3_gadget_event_string(char *str, const struct dwc3_event_devt *event)
 {
-   static char str[256];
enum dwc3_link_state state = event->event_info & DWC3_LINK_STATE_MASK;
 
switch (event->type) {
@@ -228,10 +227,10 @@ dwc3_gadget_event_string(const struct dwc3_event_devt 
*event)
  * @event: then event code
  */
 static inline const char *
-dwc3_ep_event_string(const struct dwc3_event_depevt *event, u32 ep0state)
+dwc3_ep_event_string(char *str, const struct dwc3_event_depevt *event,
+u32 ep0state)
 {
u8 epnum = event->endpoint_number;
-   static char str[256];
size_t len;
int status;
int ret;
@@ -332,14 +331,14 @@ static inline const char 
*dwc3_gadget_event_type_string(u8 event)
}
 }
 
-static inline const char *dwc3_decode_event(u32 event, u32 ep0state)
+static inline const char *dwc3_decode_event(char *str, u32 event, u32 ep0state)
 {
const union dwc3_event evt = (union dwc3_event) event;
 
if (evt.type.is_devspec)
-   return dwc3_gadget_event_string();
+   return dwc3_gadget_event_string(str, );
else
-   return dwc3_ep_event_string(, ep0state);
+   return dwc3_ep_event_string(str, , ep0state);
 }
 
 static inline const char *dwc3_ep_cmd_status_string(int status)
diff --git a/drivers/usb/dwc3/trace.h b/drivers/usb/dwc3/trace.h
index 15909b579e69..af093b4e5dc5 100644
--- a/drivers/usb/dwc3/trace.h
+++ b/drivers/usb/dwc3/trace.h
@@ -60,13 +60,15 @@ DECLARE_EVENT_CLASS(dwc3_log_event,
TP_STRUCT__entry(
__field(u32, event)
__field(u32, ep0state)
+   __dynamic_array(char, str, DWC3_MSG_MAX)
),
TP_fast_assign(
__entry->event = event;
__entry->ep0state = dwc->ep0state;
),
TP_printk("event (%08x): %s", __entry->event,
-   dwc3_decode_event(__entry->event, __entry->ep0state))
+   dwc3_decode_event(__get_str(str), __entry->event,
+ __entry->ep0state))
 );
 
 DEFINE_EVENT(dwc3_log_event, dwc3_event,
-- 
2.11.0.295.gd7dffce1ce

--
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 7/9] usb: dwc3: trace: decode ctrl request

[Felipe Balbi]

Instead of *always* dumping raw ctrl bytes, let's decode standard
requests which will make the lives of those debugging DWC3 quite a bit
easier.

Output will now look like so:

irq/34-dwc3-1594  [000] d..1   107.573081: dwc3_ctrl_req: Get Device 
Descriptor(Index = 0, Length = 18)
irq/34-dwc3-1594  [000] d..1   107.573694: dwc3_ctrl_req: Set Address(Addr = 01)
irq/34-dwc3-1594  [000] d..1   107.588319: dwc3_ctrl_req: Get Device 
Descriptor(Index = 0, Length = 18)
irq/34-dwc3-1594  [000] d..1   107.588816: dwc3_ctrl_req: Get Configuration 
Descriptor(Index = 0, Length = 9)
irq/34-dwc3-1594  [000] d..1   107.589191: dwc3_ctrl_req: Set 
Configuration(Config = 3)
irq/34-dwc3-1594  [000] d..1   107.589846: dwc3_ctrl_req: Get BOS 
Descriptor(Index = 0, Length = 5)
irq/34-dwc3-1594  [000] d..1   107.590146: dwc3_ctrl_req: Get BOS 
Descriptor(Index = 0, Length = 22)
irq/34-dwc3-1594  [000] d..1   107.590546: dwc3_ctrl_req: Get Configuration 
Descriptor(Index = 0, Length = 9)
irq/34-dwc3-1594  [000] d..1   107.590840: dwc3_ctrl_req: Get Configuration 
Descriptor(Index = 0, Length = 69)
irq/34-dwc3-1594  [000] d..1   107.591138: dwc3_ctrl_req: Get Configuration 
Descriptor(Index = 1, Length = 9)
irq/34-dwc3-1594  [000] d..1   107.591541: dwc3_ctrl_req: Get Configuration 
Descriptor(Index = 1, Length = 32)
irq/34-dwc3-1594  [000] d..1   107.591834: dwc3_ctrl_req: Get Device 
Descriptor(Index = 0, Length = 18)
irq/34-dwc3-1594  [000] d..1   114.701005: dwc3_ctrl_req: Get Device 
Descriptor(Index = 0, Length = 18)
irq/34-dwc3-1594  [000] d..1   114.721080: dwc3_ctrl_req: Get Device 
Descriptor(Index = 0, Length = 18)
irq/34-dwc3-1594  [000] d..1   114.722709: dwc3_ctrl_req: Get Device 
Descriptor(Index = 0, Length = 18)
irq/34-dwc3-1594  [000] d..1   114.728979: dwc3_ctrl_req: Get Device 
Descriptor(Index = 0, Length = 18)
irq/34-dwc3-1594  [000] d..1   114.730544: dwc3_ctrl_req: Get Device Qualifier 
Descriptor(Index = 0, Length = 10)
irq/34-dwc3-1594  [000] d..1   115.776018: dwc3_ctrl_req: Get Configuration 
Descriptor(Index = 0, Length = 9)
irq/34-dwc3-1594  [000] d..1   115.776760: dwc3_ctrl_req: Set 
Configuration(Config = 0)
irq/34-dwc3-1594  [000] d..1   115.777676: dwc3_ctrl_req: Get 
Configuration(Length = 1)
irq/34-dwc3-1594  [000] d..1   115.924797: dwc3_ctrl_req: Get Device 
Descriptor(Index = 0, Length = 18)
irq/34-dwc3-1594  [000] d..1   115.929025: dwc3_ctrl_req: Get String 
Descriptor(Index = 0, Length = 500)
irq/34-dwc3-1594  [000] d..1   115.929566: dwc3_ctrl_req: Get String 
Descriptor(Index = 1, Length = 500)
irq/34-dwc3-1594  [000] d..1   115.930911: dwc3_ctrl_req: Get String 
Descriptor(Index = 0, Length = 500)
irq/34-dwc3-1594  [000] d..1   115.931528: dwc3_ctrl_req: Get String 
Descriptor(Index = 2, Length = 500)
irq/34-dwc3-1594  [000] d..1   115.932950: dwc3_ctrl_req: Get String 
Descriptor(Index = 0, Length = 500)
irq/34-dwc3-1594  [000] d..1   115.933533: dwc3_ctrl_req: Get String 
Descriptor(Index = 3, Length = 500)

Note that Class and Vendor requests won't be decoded for obvious
reasons. Those will be printed as a raw sequence of bytes.

This patch has been tested against a normal host (both Linux and
Windows) and USB30CV Chapter 9 tests.

Signed-off-by: Felipe Balbi 
---
 drivers/usb/dwc3/debug.h | 234 +++
 drivers/usb/dwc3/trace.h |   8 +-
 2 files changed, 238 insertions(+), 4 deletions(-)

diff --git a/drivers/usb/dwc3/debug.h b/drivers/usb/dwc3/debug.h
index 1025713ebdd1..5e9c070ec874 100644
--- a/drivers/usb/dwc3/debug.h
+++ b/drivers/usb/dwc3/debug.h
@@ -222,6 +222,240 @@ dwc3_gadget_event_string(char *str, const struct 
dwc3_event_devt *event)
return str;
 }
 
+static inline void dwc3_decode_get_status(__u8 t, __u16 i, __u16 l, char *str)
+{
+   switch (t & USB_RECIP_MASK) {
+   case USB_RECIP_INTERFACE:
+   sprintf(str, "Get Interface Status(Intf = %d, Length = %d)",
+   i, l);
+   break;
+   case USB_RECIP_ENDPOINT:
+   sprintf(str, "Get Endpoint Status(ep%d%s)",
+   i & ~USB_DIR_IN,
+   i & USB_DIR_IN ? "in" : "out");
+   break;
+   }
+}
+
+static inline void dwc3_decode_set_clear_feature(__u8 t, __u8 b, __u16 v,
+__u16 i, char *str)
+{
+   switch (t & USB_RECIP_MASK) {
+   case USB_RECIP_DEVICE:
+   sprintf(str, "%s Device Feature(%s%s)",
+   b == USB_REQ_CLEAR_FEATURE ? "Clear" : "Set",
+   ({char *s;
+   switch (v) {
+   case USB_DEVICE_SELF_POWERED:
+   s = "Self Powered";
+   break;
+   case USB_DEVICE_REMOTE_WAKEUP:
+   s = "Remote Wakeup";
+ 

[PATCH v2 1/9] tools: usb: testusb: update default vary for superspeed

[Felipe Balbi]

Currently, default vary will not accomodate superspeed endpoints
causing unexpected babble errors in the IN direction. Let's update
default 'vary' parameter so that we can maintain a "short-less"
transfer as hinted at the comment.

Reported-by: Ammy Yi 
Signed-off-by: Felipe Balbi 
---
 tools/usb/testusb.c | 16 +---
 1 file changed, 9 insertions(+), 7 deletions(-)

diff --git a/tools/usb/testusb.c b/tools/usb/testusb.c
index 0692d99b6d8f..2d89b5f686b1 100644
--- a/tools/usb/testusb.c
+++ b/tools/usb/testusb.c
@@ -387,15 +387,17 @@ int main (int argc, char **argv)
/* pick defaults that works with all speeds, without short packets.
 *
 * Best per-frame data rates:
-* high speed, bulk   512 * 13 * 8 = 53248
-* interrupt 1024 *  3 * 8 = 24576
-* full speed, bulk/intr   64 * 19 =  1216
-* interrupt   64 *  1 =64
-*  low speed, interrupt8 *  1 = 8
+* super speed,bulk  1024 * 16 * 8 = 131072
+* interrupt 1024 *  3 * 8 =  24576
+* high speed, bulk   512 * 13 * 8 =  53248
+* interrupt 1024 *  3 * 8 =  24576
+* full speed, bulk/intr   64 * 19 =   1216
+* interrupt   64 *  1 = 64
+*  low speed, interrupt8 *  1 =  8
 */
param.iterations = 1000;
param.length = 1024;
-   param.vary = 512;
+   param.vary = 1024;
param.sglen = 32;
 
/* for easy use when hotplugging */
@@ -457,7 +459,7 @@ int main (int argc, char **argv)
"\t-c iterationsdefault 1000\n"
"\t-s transfer length   default 1024\n"
"\t-g sglen default 32\n"
-   "\t-v vary  default 512\n",
+   "\t-v vary  default 1024\n",
argv[0]);
return 1;
}
-- 
2.11.0.295.gd7dffce1ce

--
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: typec: Defer checking of valid power role swap to low level drivers

[Guenter Roeck]

On 05/17/2017 05:38 AM, Heikki Krogerus wrote:

Hi guys,

On Wed, May 17, 2017 at 02:36:44AM -0700, Guenter Roeck wrote:

On 05/17/2017 12:34 AM, Oliver Neukum wrote:

Am Mittwoch, den 17.05.2017, 00:32 -0700 schrieb Badhri Jagan
Sridharan:

Hi,


"Two independent set of mechanisms are defined to allow a USB Type-C
DRP to functionally swap power and data roles. When USB PD is
supported, power and data role swapping is performed as a subsequent
step following the initial connection process. For non-PD implementations,
power/data role swapping can optionally be dealt with as part of the initial
connection process."


Well, as I read it, without PD once a connection is established, you
are stuck with your role. So it seems to me that blocking a later
attempt to change it makes sense.



That seems to be a harsh and not very user friendly reading of the 
specification.

I would argue that the user doesn't care if the partner supports PD or not
when selecting a role, and I would prefer to provide an implementation which is
as user friendly as possible.


I agree. But I have to point out that at least with UCSI, the role
swapping is usually not possible without USB PD connection.

So what I'm trying to say is that we can't really promise that role
swapping will ever be possible in all cases without PD, which may mean
different behavior depending on the platform. I don't know if that is
a huge problem.

How predictable do we want this interface to function with role
swapping?



We can only do as good as we can, but we should not preclude it either.
PR_SWAP and other swap operations fail a lot in practice with many dongles,
just because the PD protocol implementation isn't always stable. So even that
won't be predictable for some time to come.

As Badhri pointed out earlier, at least some low cost devices won't support PD.
Since we are talking about high volume products, we _have_ to make it as
user friendly as we can, if for nothing else to reduce the number of customer
service calls, repeated bug filings, and, last but not least, to avoid bad 
press.

Thanks,
Guenter

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

[PATCH] usb: dwc3: replace %p with %pK

[Felipe Balbi]

%p will leak kernel pointers, so let's not expose the information on
dmesg and instead use %pK. %pK will only show the actual addresses if
explicitly enabled under /proc/sys/kernel/kptr_restrict.

Signed-off-by: Felipe Balbi 
---

Inspired by a recent patch Greg posted. Note that I've kept
tracepoints with %p because you already need admin rights to mount
tracefs and/or debugfs. If folks think tracepoints should be changed
to %pK too, let me know and I'll change the patch.

 drivers/usb/dwc3/dwc3-st.c | 2 +-
 drivers/usb/dwc3/gadget.c  | 9 +++--
 2 files changed, 4 insertions(+), 7 deletions(-)

diff --git a/drivers/usb/dwc3/dwc3-st.c b/drivers/usb/dwc3/dwc3-st.c
index dfbf464eb88c..505676fd3ba4 100644
--- a/drivers/usb/dwc3/dwc3-st.c
+++ b/drivers/usb/dwc3/dwc3-st.c
@@ -230,7 +230,7 @@ static int st_dwc3_probe(struct platform_device *pdev)
 
dwc3_data->syscfg_reg_off = res->start;
 
-   dev_vdbg(>dev, "glue-logic addr 0x%p, syscfg-reg offset 0x%x\n",
+   dev_vdbg(>dev, "glue-logic addr 0x%pK, syscfg-reg offset 0x%x\n",
 dwc3_data->glue_base, dwc3_data->syscfg_reg_off);
 
dwc3_data->rstc_pwrdn =
diff --git a/drivers/usb/dwc3/gadget.c b/drivers/usb/dwc3/gadget.c
index 750364eb11e1..011ac3ccfbe7 100644
--- a/drivers/usb/dwc3/gadget.c
+++ b/drivers/usb/dwc3/gadget.c
@@ -1224,12 +1224,9 @@ static int __dwc3_gadget_ep_queue(struct dwc3_ep *dep, 
struct dwc3_request *req)
return -ESHUTDOWN;
}
 
-   if (WARN(req->dep != dep, "request %p belongs to '%s'\n",
-   >request, req->dep->name)) {
-   dev_err(dwc->dev, "%s: request %p belongs to '%s'\n",
-   dep->name, >request, req->dep->name);
+   if (WARN(req->dep != dep, "request %pK belongs to '%s'\n",
+   >request, req->dep->name))
return -EINVAL;
-   }
 
pm_runtime_get(dwc->dev);
 
@@ -1387,7 +1384,7 @@ static int dwc3_gadget_ep_dequeue(struct usb_ep *ep,
}
goto out1;
}
-   dev_err(dwc->dev, "request %p was not queued to %s\n",
+   dev_err(dwc->dev, "request %pK was not queued to %s\n",
request, ep->name);
ret = -EINVAL;
goto out0;
-- 
2.11.0.295.gd7dffce1ce

--
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] doc-rst: fixed kernel-doc directives in usb/typec.rst

[Heikki Krogerus]

On Sat, May 13, 2017 at 03:49:17PM +0200, Markus Heiser wrote:
> Even if this file is not yet included in any toctree, it is parsed by
> Sphinx since it is named '.rst'. This patch fixes the following two
> ERRORs from Sphinx build:
> 
> Documentation/usb/typec.rst:116: ERROR: Error in "kernel-doc" directive:
> invalid option block.
> 
> .. kernel-doc:: drivers/usb/typec/typec.c
>:functions: typec_register_cable typec_unregister_cable typec_register_plug
>typec_unregister_plug
> 
> Documentation/usb/typec.rst:139: ERROR: Error in "kernel-doc" directive:
> invalid option block.
> 
> .. kernel-doc:: drivers/usb/typec/typec.c
>:functions: typec_set_data_role typec_set_pwr_role typec_set_vconn_role
>typec_set_pwr_opmode
> 
> Signed-off-by: Markus Heiser 
> ---
>  Documentation/usb/typec.rst | 6 ++
>  1 file changed, 2 insertions(+), 4 deletions(-)

Applied:
https://github.com/krohei/linux/commits/typec


Thanks,

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

Re: [PATCH] usb: typec: Defer checking of valid power role swap to low level drivers

[Heikki Krogerus]

Hi guys,

On Wed, May 17, 2017 at 02:36:44AM -0700, Guenter Roeck wrote:
> On 05/17/2017 12:34 AM, Oliver Neukum wrote:
> > Am Mittwoch, den 17.05.2017, 00:32 -0700 schrieb Badhri Jagan
> > Sridharan:
> > 
> > Hi,
> > 
> > > "Two independent set of mechanisms are defined to allow a USB Type-C
> > > DRP to functionally swap power and data roles. When USB PD is
> > > supported, power and data role swapping is performed as a subsequent
> > > step following the initial connection process. For non-PD implementations,
> > > power/data role swapping can optionally be dealt with as part of the 
> > > initial
> > > connection process."
> > 
> > Well, as I read it, without PD once a connection is established, you
> > are stuck with your role. So it seems to me that blocking a later
> > attempt to change it makes sense.
> > 
> 
> That seems to be a harsh and not very user friendly reading of the 
> specification.
> 
> I would argue that the user doesn't care if the partner supports PD or not
> when selecting a role, and I would prefer to provide an implementation which 
> is
> as user friendly as possible.

I agree. But I have to point out that at least with UCSI, the role
swapping is usually not possible without USB PD connection.

So what I'm trying to say is that we can't really promise that role
swapping will ever be possible in all cases without PD, which may mean
different behavior depending on the platform. I don't know if that is
a huge problem.

How predictable do we want this interface to function with role
swapping?


Thanks,

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

Re: [PATCH v3] usb: usbip: let urb_destroy kfree the transfer_buffer

[Michael Grzeschik]

On Wed, May 17, 2017 at 12:07:50PM +0200, Michael Grzeschik wrote:
> The usbip stack dynamically allocates the transfer_buffer of each urb in
> stub_recv_cmd_submit depending on the requested transfer_buffer_length
> set via the received tcp packet.
> 
> As the usbip layer never reuses the always different sized
> transfer_buffer it can add URB_FREE_BUFFER to every urbs transfer_flags
> and let urb_destroy call the kfree for it.
> 
> This patch fixes double kfree situations where the usbip remote side
> added the URB_FREE_BUFFER.
> 
> Cc: sta...@vger.kernel.org
> Signed-off-by: Michael Grzeschik 
> ---
> v1 -> v2: - rephrased patch subject from:
> "usb: usbip: avoid the usb layer to kfree our allocated buffer"
>   - changed to always let urb_destoy remove the transfer_buffer
> v2 -> v3: - added stable to cc
>   - wraped long line with over 80 chars
> 
>  drivers/usb/usbip/stub_main.c| 1 -
>  drivers/usb/usbip/stub_tx.c  | 1 -
>  drivers/usb/usbip/usbip_common.c | 9 -
>  3 files changed, 8 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/usb/usbip/stub_main.c b/drivers/usb/usbip/stub_main.c
> index 44ab43fc4fcc7..898e0d271fd47 100644
> --- a/drivers/usb/usbip/stub_main.c
> +++ b/drivers/usb/usbip/stub_main.c
> @@ -261,7 +261,6 @@ void stub_device_cleanup_urbs(struct stub_device *sdev)
>  
>   kmem_cache_free(stub_priv_cache, priv);
>  
> - kfree(urb->transfer_buffer);
>   kfree(urb->setup_packet);
>   usb_free_urb(urb);
>   }

I found the corresponding code in vudc_dev.c where the
urb->transfer_buffer is set to NULL. This also solves the double kfree
situations. I don't know if we also should prefer that fix in stub_main
and stub_tx aswell or instead also remove the explicit kfree of
urb->transfer_buffer in the vudc code.

> diff --git a/drivers/usb/usbip/stub_tx.c b/drivers/usb/usbip/stub_tx.c
> index 6b1e8c3f0e4b2..23d1d76766d2c 100644
> --- a/drivers/usb/usbip/stub_tx.c
> +++ b/drivers/usb/usbip/stub_tx.c
> @@ -28,7 +28,6 @@ static void stub_free_priv_and_urb(struct stub_priv *priv)
>   struct urb *urb = priv->urb;
>  
>   kfree(urb->setup_packet);
> - kfree(urb->transfer_buffer);
>   list_del(>list);
>   kmem_cache_free(stub_priv_cache, priv);
>   usb_free_urb(urb);
> diff --git a/drivers/usb/usbip/usbip_common.c 
> b/drivers/usb/usbip/usbip_common.c
> index cab2b71a80d02..829b608135989 100644
> --- a/drivers/usb/usbip/usbip_common.c
> +++ b/drivers/usb/usbip/usbip_common.c
> @@ -381,6 +381,12 @@ static unsigned int tweak_transfer_flags(unsigned int 
> flags)
>   return flags;
>  }
>  
> +static unsigned int tweak_submit_transfer_flags(unsigned int flags)
> +{
> + flags |= URB_FREE_BUFFER;
> + return flags;
> +}
> +
>  static void usbip_pack_cmd_submit(struct usbip_header *pdu, struct urb *urb,
> int pack)
>  {
> @@ -398,7 +404,8 @@ static void usbip_pack_cmd_submit(struct usbip_header 
> *pdu, struct urb *urb,
>   spdu->number_of_packets = urb->number_of_packets;
>   spdu->interval  = urb->interval;
>   } else  {
> - urb->transfer_flags = spdu->transfer_flags;
> + urb->transfer_flags =
> + tweak_submit_transfer_flags(spdu->transfer_flags);
>   urb->transfer_buffer_length = spdu->transfer_buffer_length;
>   urb->start_frame= spdu->start_frame;
>   urb->number_of_packets  = spdu->number_of_packets;
> -- 
> 2.11.0
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-usb" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

-- 
Pengutronix e.K.   | |
Industrial Linux Solutions | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0|
Amtsgericht Hildesheim, HRA 2686   | Fax:   +49-5121-206917- |
--
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 51/53] usb: fix the comment with regards to DocBook

[Felipe Balbi]

Mauro Carvalho Chehab  writes:

> The USB gadget documentation is not at DocBook anymore.
> The main file was converted to ReST, and stored at
> Documentation/driver-api/usb/gadget.rst, but there are
> still several plain text files related to gadget under
> Documentation/usb.
>
> So, be generic and just mention documentation
> without specifying where it is.
>
> Signed-off-by: Mauro Carvalho Chehab 

I'm adding this to my queue. If this is part of a larger series, let me
know and I'll drop it :-)

-- 
balbi


signature.asc
Description: PGP signature

Re: OHCI-PCI: Thin client does not shutdown properly

[Rainer Koenig]

Oops, pressed the "send button too quickly, sorry"

Am 16.05.2017 um 16:20 schrieb Alan Stern:
> You've got a BIOS developer in the same building?  That's a great
> resource!  Maybe together you can find out what condition is causing
> the BIOS to initiate a reboot.

We got everything here. We got hardware developers for our mainboards
and systems, BIOS developers, QA engineeers, product management and a
factory to build servers and PCs. The only site in Europe that is still
developing and producing PCs and servers.

> For example, exactly what does "Power-On via USB" in the BIOS do?

BIOS is waiting for a "resume" in that case. If a resume on USB is
there, machine starts. We have special keyboards with a power on button
and the trick is that this button issues a "resume" even if the keyboard
itself is not programmed to send resumes.

> I didn't expect the patch to solve the problem.  Nevertheless, I would 
> like to know exactly what effect it has on both kernels.  Can you 
> provide more details?

Here we go. That's the USB releated log with the patch:
usbhid 5-2:1.0: rkoenig handling

usbhid 5-2:1.0: shutdown

usbhid 5-1:1.1: rkoenig handling

usbhid 5-1:1.1: shutdown

usbhid 5-1:1.0: rkoenig handling

usbhid 5-1:1.0: shutdown

usb 5-2: rkoenig handling

usb 5-2: shutdown

usb 5-1: rkoenig handling

usb 5-1: shutdown

usb usb6-port4: rkoenig handling

usb usb6-port3: rkoenig handling

usb usb6-port2: rkoenig handling

usb usb6-port1: rkoenig handling

usb usb6: rkoenig handling

usb usb6: shutdown

ohci-pci :00:13.0: rkoenig handling

ohci-pci :00:13.0: shutdown

usb usb5-port4: rkoenig handling

usb usb5-port3: rkoenig handling

usb usb5-port2: rkoenig handling

usb usb5-port1: rkoenig handling

usb usb5: rkoenig handling

usb usb5: shutdown

ohci-pci :00:12.0: rkoenig handling

ohci-pci :00:12.0: shutdown

usb usb4-port4: rkoenig handling

usb usb4-port3: rkoenig handling

usb usb4-port2: rkoenig handling

usb usb4-port1: rkoenig handling

usb usb4: rkoenig handling

usb usb4: shutdown

ehci-pci :00:13.2: rkoenig handling

ehci-pci :00:13.2: shutdown

usb usb3-port4: rkoenig handling

usb usb3-port3: rkoenig handling

usb usb3-port2: rkoenig handling

usb usb3-port1: rkoenig handling

usb usb3: rkoenig handling

usb usb3: shutdown

ehci-pci :00:12.2: rkoenig handling

ehci-pci :00:12.2: shutdown

usb usb2-port2: rkoenig handling

usb usb2-port1: rkoenig handling

usb usb2: rkoenig handling

usb usb2: shutdown

usb usb1-port2: rkoenig handling

usb usb1-port1: rkoenig handling

usb usb1: rkoenig handling

usb usb1: shutdown

xhci_hcd :00:10.0: rkoenig handling

xhci_hcd :00:10.0: shutdown

> You should have unbound the controllers, not the devices.  That is, you
> should have unbound PCI devices :00:12.0 and :00:13.0 from
> ohci-pci (in /sys/bus/pci/drivers/ohci_pci), and :00:12.2 and
> :00:13.2 from ehci-pci (in /sys/bus/pci/drivers/ehci_pci).

Yeah, that one I tried and it works perfectly, even when the drivers
are compiled into the kernel.

>> The keyboard/mouse still continued to work on my system (which btw is
> 
> Are they connected over USB?  If they are, removing ehci-pci won't make 
> any difference.  But without ohci-pci, they won't work -- unless they 
> are plugged into a USB-3 port.

Yes, keyboard and mouse are attached on the USB ports.

>> running Ubuntu 16.04 for this tests). But now its getting strange:
>>
>> - if I shutdown the system at this point with "init 0" from a root shell
>>   it performs a shutdown, and it turns off! Yeah.
>>
>> - if I shutdown the system at this point by using the shutdown menu from
>>   the Ubuntu menu then the shutdown ends up in a kernel panic.
> 
> Don't you get any information about the panic on your serial console?  
> I would expect it to have a stack dump, at least.  A panic means 
> there's a bug, and it needs to be fixed.

That's what I get:

[  297.243132] general protection fault:  [#1] SMP

[  297.250152] Modules linked in: amd_freq_sensitivity(E)
snd_hda_codec_realtek(E) snd_hda_codec_generic(E) snd_hda_codec_hdmi(E)
kvm_amd(E) snd_hda_intel(E) kvm(E) snd_hda_codec(E) crct10dif_pclmul(E)
snd_hda_core(E) crc32_pclmul(E) snd_hwdep(E) ghash_clmulni_intel(E)
snd_pcm(E) aesni_intel(E) aes_x86_64(E) snd_seq_midi(E) lrw(E)
snd_seq_midi_event(E) input_leds(E) gf128mul(E) snd_rawmidi(E)
glue_helper(E) snd_seq(E) ablk_helper(E) snd_seq_device(E) snd_timer(E)
cryptd(E) edac_mce_amd(E) snd(E) serio_raw(E) edac_core(E)
fam15h_power(E) k10temp(E) soundcore(E) shpchp(E) fujitsu_laptop(E)
8250_fintek(E) i2c_piix4(E) mac_hid(E) parport_pc(E) ppdev(E) lp(E)
parport(E) autofs4(E) hid_generic(E) usbhid(E) hid(E) amdkfd(E)
amd_iommu_v2(E) radeon(E) i2c_algo_bit(E) ttm(E) ohci_pci(E) ohci_hcd(E)
drm_kms_helper(E) ahci(E) xhci_pci(E) psmouse(E) r8169(E) libahci(E)
drm(E) xhci_hcd(E) mii(E) video(E) [last unloaded: ehci_hcd]

[  297.346784] CPU: 2 PID: 1 Comm: systemd-shutdow Tainted: G
E   4.2.0-rc4-bad #10

Microchip USB Hub Driver Harmonization

[Richard Leitner]

Hello,
due to the fact (all?) the Microchip (former SMSC) USB hubs share the
same I2C configuration interface, I'm currently working on harmonizing
those USB Hub drivers. Currently this affects the usb251xb, usb3503 and
usb4604 drivers. To avoid preventable efforts (and patch versions) I
have some question on the preferred implementation:

1. Currently usb251xb uses i2c_smbus_*, usb3503 uses regmap_* and
usb4604 uses i2c_master_* functions for the hub configuration. What
would be the preferred solution?

2. What would be a good prefix for common headers/functions/macros/etc.?
I thought of "mcusbhub"... Would that be OK? Or are there any
conventions/better proposals on that?

3. Currently only usb3503 supports "platform data". Is this still needed
or may it be removed?

Thanks & kind regards,
RichardL
--
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: OHCI-PCI: Thin client does not shutdown properly

[Rainer Koenig]

Am 16.05.2017 um 16:20 schrieb Alan Stern:

> You've got a BIOS developer in the same building?  That's a great
> resource!  Maybe together you can find out what condition is causing
> the BIOS to initiate a reboot.

We got everything here. We got hardware developers for our mainboards
and systems, BIOS developers, QA engineeers, product management and a
factory to build servers and PCs. The only site in Europe that is still
developing and producing PCs and servers.

> For example, exactly what does "Power-On via USB" in the BIOS do?

BIOS is waiting for a "resume" in that case. If a resume on USB is
there, machine starts. We have special keyboards with a power on button
and the trick is that this button issues a "resume" even if the keyboard
itself is not programmed to send resumes.

> I didn't expect the patch to solve the problem.  Nevertheless, I would 
> like to know exactly what effect it has on both kernels.  Can you 
> provide more details?
> 
>> Next thing I tried was the unbind approach. Since ehci and ohci were
>> compiled into the kernel I tried to unbind every USB device I found
>> under /sys/bus/usb/drivers/, but even with everything gone there the
>> machine doesn't shutdown at the end.
> 
> You should have unbound the controllers, not the devices.  That is, you
> should have unbound PCI devices :00:12.0 and :00:13.0 from
> ohci-pci (in /sys/bus/pci/drivers/ohci_pci), and :00:12.2 and
> :00:13.2 from ehci-pci (in /sys/bus/pci/drivers/ehci_pci).
> 
>> Next approach was that I changed the kernel config so that ehci and ohci
>> are modules instead of being compiled into the kernel. Then I booted the
>> "bad" kernel and did
>>
>> rmmod ehci-pci
>> rmmod ehci-hcd
> 
> That works too.
> 
>> The keyboard/mouse still continued to work on my system (which btw is
> 
> Are they connected over USB?  If they are, removing ehci-pci won't make 
> any difference.  But without ohci-pci, they won't work -- unless they 
> are plugged into a USB-3 port.
> 
>> running Ubuntu 16.04 for this tests). But now its getting strange:
>>
>> - if I shutdown the system at this point with "init 0" from a root shell
>>   it performs a shutdown, and it turns off! Yeah.
>>
>> - if I shutdown the system at this point by using the shutdown menu from
>>   the Ubuntu menu then the shutdown ends up in a kernel panic.
> 
> Don't you get any information about the panic on your serial console?  
> I would expect it to have a stack dump, at least.  A panic means 
> there's a bug, and it needs to be fixed.
> 
>> Both results are reproducible. "init 0" shuts the system down and keeps
>> it off, shutdown form menu crashes.
>>
>> Since keyboard/mouse are still functional without the ehci stuff I tried
>> to blacklist them by putting a blacklist-ehci.conf file into
>> /etc/modprobe.d/ that had 2 lines:
>> blacklist ehci_pci
>> blacklist ehci_hcd
>>
>> I also rebuild the initrd image, but I really couldn't get rid of those
>> modules, after every new start lsmod still showed the ehci modules
>> despite the blacklist entries.
> 
> You probably have to tell the program that creates the initrd image to 
> blacklist them or leave them out entirely.  I don't know how to do this 
> for Ubuntu.
> 
>> Next step was disabling ehci support in the kernel config. Rebuilding
>> everything and now I have a bad kernel without ehci support that boots
>> up, is able to handle keyboard and mouse and I shutdown the system (even
>> from the menu) its shuts down and keeps off. So now it seems to behave
>> like the "good" kernel.
> 
> Therefore it appears that the problem is somehow caused by the 
> operation of shutting down the EHCI controller.  Perhaps it interrupts 
> the connections to the OHCI controller briefly, in a way that leads the 
> BIOS to believe that a "Power-On via USB" event has occurred.
> 
>> So at least we would have a workaround, but I would really prefer that I
>> can blacklist those modules because then our partner could build his own
>> kernel for the thin client system in the usual way and a "workaround"
>> could be disabling the ehci stuff from loading.
> 
> Another possibility is to unbind ehci-pci just before shutting down, 
> for example as part of a shutdown script.
> 
>> Makes me really wonder if something is wrong with the ehci part of the
>> hardware on that machine. Well, we also shipped one system to AMD for
>> further analysis, maybe they can explain this strange behaviour.
>>
>> Thanks a lot for your input, it was really helpful.
> 
> Let me know what you find out.
> 
> Alan Stern
> 


-- 
Dipl.-Inf. (FH) Rainer Koenig
Project Manager Linux Clients
FJ EMEIA PR PSO PM CCD ENG SW OSS

Fujitsu Technology Solutions
Bürgermeister-Ullrich-Str. 100
86199 Augsburg
Germany

Telephone: +49-821-804-3321
Telefax:   +49-821-804-2131
Mail:  mailto:rainer.koe...@ts.fujitsu.com

Internet ts.fujtsu.com
Company Details  ts.fujitsu.com/imprint.html
--
To unsubscribe from this list: send the line "unsubscribe 

Re: [RFC V1 1/1] net: cdc_ncm: Reduce memory use when kernel memory low

[Baxter, Jim]

From: Oliver Neukum (oneu...@suse.com) Sent: Wed, 17 May 2017 09:44:20 +0200 

> Am Dienstag, den 16.05.2017, 20:24 +0200 schrieb Bjørn Mork:
>>
>> I must say that I don't like the additional complexity added here.  If
>> there are memory issues and you can reduce the buffer size to
>> USB_CDC_NCM_NTB_MIN_OUT_SIZE, then why don't you just set a lower tx_max
>> buffer size in the first place?
>>
>>   echo 2048 > /sys/class/net/wwan0/cdc_ncm/tx_max
>>

Hi

The issue is we need the higher performance for Mirrorlink to be able to
work correctly. The low memory situation only occurs very occasionally and
once the kernel has run compaction if this issue occurs again it will be
many hours later.

> 
> Hi,
> 
> that would hurt performance across the board though.
> Can we trigger memory compactation earlier?
> 
>   Regards
>   Oliver
> 

We initially tried increasing the vm.min_free_kbytes but the value needed to 
address
the problem was around 65536 which then meant some other applications were 
unable to
run due to there not being enough free memory.
The i.MX6 based system has 863MB of RAM in total.

Regards,
Jim
--
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: usb: usbtmc: Questions of the IVI Foundation

[Guido . Kiener]

linux-usb-ow...@vger.kernel.org schrieb am 17.05.2017 09:08:39:
> > I'm not sure for 100%, but I assume that reading the IN pipe could be
> > setup asynchronously (e.g. with usb_submit_urb(..)) just before 
sending
> > send_request_dev_dep_msg_in(..).
> > USBTMC_SIZE_IOBUFFER = 2kB is a bottleneck when dealing with data size 
>
> > 1MB (Need of Scatter/Gather).
> 
> The major problem with usbtmc_read() is that it sends a new TMC read
> request for every 2033-byte buffer it wants to read.
> 
> As a first step, try enabling the "rigol" quirk, which simply uses
> a single read request for the entire buffer.  (I don't know why the
> driver author thought this shouldn't be done for every device.)

Thank you for the hint! I think that all T instruments should be able to 
send the entire buffer and I hope the "rigol quirk" can be used for all 
devices.

Regards,
Guido

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

[PATCH 2/2] usb: dwc3: gadget: lazily map requests for DMA

[Felipe Balbi]

Some functions might want to have very, very long request queues. We
can't make any assumptions about how many requests we *are* able to
map, so instead of mapping requests early, let's map them late. This
way, functions can queue as many requests as they'd like but we won't
take DMA resources until they are needed.

Also, we can now stop processing requests when we run out of DMA
resources but still keep requests in the queue for late processing.

Signed-off-by: Felipe Balbi 
---

Tested with g_mass_storage using 1024 requests. Note that we have
space for 255 TRBs in our ring. TRB #256 is our link TRB back to
the head of the ring.

 drivers/usb/dwc3/gadget.c | 21 -
 1 file changed, 12 insertions(+), 9 deletions(-)

diff --git a/drivers/usb/dwc3/gadget.c b/drivers/usb/dwc3/gadget.c
index 7113a9f53ca9..750364eb11e1 100644
--- a/drivers/usb/dwc3/gadget.c
+++ b/drivers/usb/dwc3/gadget.c
@@ -1099,6 +1099,17 @@ static void dwc3_prepare_trbs(struct dwc3_ep *dep)
}
 
list_for_each_entry_safe(req, n, >pending_list, list) {
+   struct dwc3 *dwc = dep->dwc;
+   int ret;
+
+   ret = usb_gadget_map_request_by_dev(dwc->sysdev, >request,
+   dep->direction);
+   if (ret)
+   return;
+
+   req->sg = req->request.sg;
+   req->num_pending_sgs= req->request.num_mapped_sgs;
+
if (req->num_pending_sgs > 0)
dwc3_prepare_one_trb_sg(dep, req);
else
@@ -1205,7 +1216,7 @@ static void dwc3_gadget_start_isoc(struct dwc3 *dwc,
 static int __dwc3_gadget_ep_queue(struct dwc3_ep *dep, struct dwc3_request 
*req)
 {
struct dwc3 *dwc = dep->dwc;
-   int ret;
+   int ret = 0;
 
if (!dep->endpoint.desc) {
dev_err(dwc->dev, "%s: can't queue to disabled endpoint\n",
@@ -1229,14 +1240,6 @@ static int __dwc3_gadget_ep_queue(struct dwc3_ep *dep, 
struct dwc3_request *req)
 
trace_dwc3_ep_queue(req);
 
-   ret = usb_gadget_map_request_by_dev(dwc->sysdev, >request,
-   dep->direction);
-   if (ret)
-   return ret;
-
-   req->sg = req->request.sg;
-   req->num_pending_sgs= req->request.num_mapped_sgs;
-
list_add_tail(>list, >pending_list);
 
/*
-- 
2.11.0.295.gd7dffce1ce

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

[PATCH 1/2] usb: dwc3: gadget: don't WARN about lack of TRBs

[Felipe Balbi]

We don't need a big fat warning with stack dump at all. Running out of
TRBs is a normal condition and we will have more TRBs available as
soon as some transfers complete.

Signed-off-by: Felipe Balbi 
---
 drivers/usb/dwc3/gadget.c | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/drivers/usb/dwc3/gadget.c b/drivers/usb/dwc3/gadget.c
index 6f6f0b3be3ad..7113a9f53ca9 100644
--- a/drivers/usb/dwc3/gadget.c
+++ b/drivers/usb/dwc3/gadget.c
@@ -953,7 +953,6 @@ static struct dwc3_trb *dwc3_ep_prev_trb(struct dwc3_ep 
*dep, u8 index)
 static u32 dwc3_calc_trbs_left(struct dwc3_ep *dep)
 {
struct dwc3_trb *tmp;
-   struct dwc3 *dwc = dep->dwc;
u8  trbs_left;
 
/*
@@ -965,8 +964,7 @@ static u32 dwc3_calc_trbs_left(struct dwc3_ep *dep)
 */
if (dep->trb_enqueue == dep->trb_dequeue) {
tmp = dwc3_ep_prev_trb(dep, dep->trb_enqueue);
-   if (dev_WARN_ONCE(dwc->dev, tmp->ctrl & DWC3_TRB_CTRL_HWO,
- "%s No TRBS left\n", dep->name))
+   if (tmp->ctrl & DWC3_TRB_CTRL_HWO)
return 0;
 
return DWC3_TRB_NUM - 1;
-- 
2.11.0.295.gd7dffce1ce

--
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] usb: usbip: let urb_destroy kfree the transfer_buffer

[Michael Grzeschik]

The usbip stack dynamically allocates the transfer_buffer of each urb in
stub_recv_cmd_submit depending on the requested transfer_buffer_length
set via the received tcp packet.

As the usbip layer never reuses the always different sized
transfer_buffer it can add URB_FREE_BUFFER to every urbs transfer_flags
and let urb_destroy call the kfree for it.

This patch fixes double kfree situations where the usbip remote side
added the URB_FREE_BUFFER.

Cc: sta...@vger.kernel.org
Signed-off-by: Michael Grzeschik 
---
v1 -> v2: - rephrased patch subject from:
"usb: usbip: avoid the usb layer to kfree our allocated buffer"
  - changed to always let urb_destoy remove the transfer_buffer
v2 -> v3: - added stable to cc
  - wraped long line with over 80 chars

 drivers/usb/usbip/stub_main.c| 1 -
 drivers/usb/usbip/stub_tx.c  | 1 -
 drivers/usb/usbip/usbip_common.c | 9 -
 3 files changed, 8 insertions(+), 3 deletions(-)

diff --git a/drivers/usb/usbip/stub_main.c b/drivers/usb/usbip/stub_main.c
index 44ab43fc4fcc7..898e0d271fd47 100644
--- a/drivers/usb/usbip/stub_main.c
+++ b/drivers/usb/usbip/stub_main.c
@@ -261,7 +261,6 @@ void stub_device_cleanup_urbs(struct stub_device *sdev)
 
kmem_cache_free(stub_priv_cache, priv);
 
-   kfree(urb->transfer_buffer);
kfree(urb->setup_packet);
usb_free_urb(urb);
}
diff --git a/drivers/usb/usbip/stub_tx.c b/drivers/usb/usbip/stub_tx.c
index 6b1e8c3f0e4b2..23d1d76766d2c 100644
--- a/drivers/usb/usbip/stub_tx.c
+++ b/drivers/usb/usbip/stub_tx.c
@@ -28,7 +28,6 @@ static void stub_free_priv_and_urb(struct stub_priv *priv)
struct urb *urb = priv->urb;
 
kfree(urb->setup_packet);
-   kfree(urb->transfer_buffer);
list_del(>list);
kmem_cache_free(stub_priv_cache, priv);
usb_free_urb(urb);
diff --git a/drivers/usb/usbip/usbip_common.c b/drivers/usb/usbip/usbip_common.c
index cab2b71a80d02..829b608135989 100644
--- a/drivers/usb/usbip/usbip_common.c
+++ b/drivers/usb/usbip/usbip_common.c
@@ -381,6 +381,12 @@ static unsigned int tweak_transfer_flags(unsigned int 
flags)
return flags;
 }
 
+static unsigned int tweak_submit_transfer_flags(unsigned int flags)
+{
+   flags |= URB_FREE_BUFFER;
+   return flags;
+}
+
 static void usbip_pack_cmd_submit(struct usbip_header *pdu, struct urb *urb,
  int pack)
 {
@@ -398,7 +404,8 @@ static void usbip_pack_cmd_submit(struct usbip_header *pdu, 
struct urb *urb,
spdu->number_of_packets = urb->number_of_packets;
spdu->interval  = urb->interval;
} else  {
-   urb->transfer_flags = spdu->transfer_flags;
+   urb->transfer_flags =
+   tweak_submit_transfer_flags(spdu->transfer_flags);
urb->transfer_buffer_length = spdu->transfer_buffer_length;
urb->start_frame= spdu->start_frame;
urb->number_of_packets  = spdu->number_of_packets;
-- 
2.11.0

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

Re: [PATCH] usb: typec: Defer checking of valid power role swap to low level drivers

[Guenter Roeck]

On 05/17/2017 01:08 AM, Greg Kroah-Hartman wrote:

On Wed, May 17, 2017 at 12:32:19AM -0700, Badhri Jagan Sridharan wrote:

With this CL the lower level drivers are reponsible to check and make sure


responsible


that the role swap can be performed.


What is a "CL"?



Too much Gerrit. "Change List". Took me a while to understand what people
were talking about when talking about CLs.

Guenter

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

Re: [PATCH v2] usb: usbip: let urb_destroy the transfer_buffer

[Greg KH]

On Tue, May 16, 2017 at 11:14:46AM +0200, Michael Grzeschik wrote:
> On Mon, May 15, 2017 at 05:37:52PM +0200, Michael Grzeschik wrote:
> > The usbip stack dynamically allocates the transfer_buffer of each urb in
> > stub_recv_cmd_submit depending on the requested transfer_buffer_length
> > set via the received tcp packet. As the usbip layer never reuses the
> > always different sized transfer_buffer it can always add URB_FREE_BUFFER
> > to the urbs transfer_flags and let urb_destroy call the kfree for it.
> 
> As this also fixes the double kfree I think this could go into the stable 
> tree.

Any reason you aren't cc: the maintainers for this driver?  Please use
scripts/get_maintainer.pl to find that, and resend, properly tagging
this for stable as well.

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 v3 0/6] usb: usbip: Fix ports and port status

[Greg KH]

On Thu, Apr 06, 2017 at 06:03:21AM +0800, Yuyang Du wrote:
> The commit 0775a9cbc694e8c7 ("usbip: vhci extension: modifications
> to vhci driver") introduced several bugs relating to the number of
> ports amd the port status. In addition, a small improvement is made
> to the vhci_hcd module.

Can you rebase this series and resend it with the accumulated acks?  I'm
confused about what has, and has not been applied and reviewed in this
series at the moment.

thanks,

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

Re: [PATCH] usb: typec: Defer checking of valid power role swap to low level drivers

[Guenter Roeck]

On 05/17/2017 12:34 AM, Oliver Neukum wrote:

Am Mittwoch, den 17.05.2017, 00:32 -0700 schrieb Badhri Jagan
Sridharan:

Hi,


"Two independent set of mechanisms are defined to allow a USB Type-C
DRP to functionally swap power and data roles. When USB PD is
supported, power and data role swapping is performed as a subsequent
step following the initial connection process. For non-PD implementations,
power/data role swapping can optionally be dealt with as part of the initial
connection process."


Well, as I read it, without PD once a connection is established, you
are stuck with your role. So it seems to me that blocking a later
attempt to change it makes sense.



That seems to be a harsh and not very user friendly reading of the 
specification.

I would argue that the user doesn't care if the partner supports PD or not
when selecting a role, and I would prefer to provide an implementation which is
as user friendly as possible.

Thanks,
Guenter

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

Re: [GIT PULL] USB fixes for v4.12-rc

[Greg KH]

On Wed, May 17, 2017 at 10:51:48AM +0300, Felipe Balbi wrote:
> 
> Hi Greg,
> 
> here's my first pull request for v4.12-rc cycle. Only 6 patches this
> time around. Where applicable, patches were tested on a few Intel
> platforms I have available.
> 
> Let me know if you want anything to be changed.
> 
> cheers
> 
> The following changes since commit 2ea659a9ef488125eb46da6eb571de5eae5c43f6:
> 
>   Linux 4.12-rc1 (2017-05-13 13:19:49 -0700)
> 
> are available in the git repository at:
> 
>   git://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb.git 
> tags/fixes-for-v4.12-rc2

Pulled and pushed out, 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 1/2] USB: ehci-platform: fix companion-device leak

[Johan Hovold]

On Wed, May 17, 2017 at 04:53:07AM +, Yoshihiro Shimoda wrote:
> Hi Johan,
> 
> > From: Johan Hovold
> > Sent: Tuesday, May 16, 2017 11:26 PM
> > 
> > Make sure do drop the reference taken to the companion device during
> > resume.
> > 
> > Fixes: d4d75128b8fd ("usb: host: ehci-platform: fix usb 1.1 device is not 
> > connected in system resume")
> > Cc: stable  # 4.11
> > Cc: Yoshihiro Shimoda 
> > Signed-off-by: Johan Hovold 
> > ---
> >  drivers/usb/host/ehci-platform.c | 4 +++-
> >  1 file changed, 3 insertions(+), 1 deletion(-)
> > 
> > diff --git a/drivers/usb/host/ehci-platform.c 
> > b/drivers/usb/host/ehci-platform.c
> > index bc7b9be12f54..f1908ea9fbd8 100644
> > --- a/drivers/usb/host/ehci-platform.c
> > +++ b/drivers/usb/host/ehci-platform.c
> > @@ -384,8 +384,10 @@ static int ehci_platform_resume(struct device *dev)
> > }
> > 
> > companion_dev = usb_of_get_companion_dev(hcd->self.controller);
> > -   if (companion_dev)
> > +   if (companion_dev) {
> > device_pm_wait_for_dev(hcd->self.controller, companion_dev);
> > +   put_device(companion_dev);
> 
> Thank you for the patch!
> 
> I should have added an API like "usb_of_put_companion_dev(dev)"
> and it calls "of_dev_put(to_platform_device(dev))". And then,
> ehci_platform_resume() can call the API instead of put_device().
> But, adding new API is not good for stable.

I don't think that's needed or desirable. The helper returns a pointer
to a struct device with an incremented refcount, so just using
put_device() when done is the right thing to do.

Note that I added a comment about the refcount to the helper in patch
2/2 as a reminder for any future users.

> So,
> 
> Acked-by: Yoshihiro Shimoda 

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 v3] ftdi_sio: add Olimex ARM-USB-TINY(H) PIDs

[Johan Hovold]

On Tue, May 16, 2017 at 11:54:41PM +0300, Andrey Korolyov wrote:
> This patch adds support for recognition of ARM-USB-TINY(H) devices which
> are almost identical to ARM-USB-OCD(H) but lacking separate barrel jack
> and serial console.
> 
> By suggestion from Johan Hovold it is possible to replace
> ftdi_jtag_quirk with a bit more generic construction. Since all
> Olimex-ARM debuggers has exactly two ports, we could safely always use
> only second port within the debugger family.

I had already fixed up and applied your v2, but ok let's convert the old
entries as well for consistency and to make things easier for the stable
maintainers.

> Signed-off-by: Andrey Korolyov 
> Cc: stable 
> ---
>  drivers/usb/serial/ftdi_sio.c | 12 
>  drivers/usb/serial/ftdi_sio_ids.h |  2 ++
>  2 files changed, 10 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/usb/serial/ftdi_sio.c b/drivers/usb/serial/ftdi_sio.c
> index d38780f..3f6da7c 100644
> --- a/drivers/usb/serial/ftdi_sio.c
> +++ b/drivers/usb/serial/ftdi_sio.c
> @@ -809,10 +809,14 @@ static const struct usb_device_id id_table_combined[] = 
> {
>   { USB_DEVICE(FTDI_VID, FTDI_PROPOX_ISPCABLEIII_PID) },
>   { USB_DEVICE(FTDI_VID, CYBER_CORTEX_AV_PID),
>   .driver_info = (kernel_ulong_t)_jtag_quirk },
> - { USB_DEVICE(OLIMEX_VID, OLIMEX_ARM_USB_OCD_PID),
> - .driver_info = (kernel_ulong_t)_jtag_quirk },
> - { USB_DEVICE(OLIMEX_VID, OLIMEX_ARM_USB_OCD_H_PID),
> - .driver_info = (kernel_ulong_t)_jtag_quirk },
> + { USB_DEVICE_INTERFACE_NUMBER(OLIMEX_VID, OLIMEX_ARM_USB_OCD_PID,
> + 1) },
> + { USB_DEVICE_INTERFACE_NUMBER(OLIMEX_VID, OLIMEX_ARM_USB_TINY_PID,
> + 1) },
> + { USB_DEVICE_INTERFACE_NUMBER(OLIMEX_VID, OLIMEX_ARM_USB_TINY_H_PID,
> + 1) },
> + { USB_DEVICE_INTERFACE_NUMBER(OLIMEX_VID, OLIMEX_ARM_USB_OCD_H_PID,
> + 1) },

No need to break these lines even if checkpatch complains. We're a bit
more allowing for id tables.

>   { USB_DEVICE(FIC_VID, FIC_NEO1973_DEBUG_PID),
>   .driver_info = (kernel_ulong_t)_jtag_quirk },
>   { USB_DEVICE(FTDI_VID, FTDI_OOCDLINK_PID),
> diff --git a/drivers/usb/serial/ftdi_sio_ids.h 
> b/drivers/usb/serial/ftdi_sio_ids.h
> index 71fb9e5..4fcf1ce 100644
> --- a/drivers/usb/serial/ftdi_sio_ids.h
> +++ b/drivers/usb/serial/ftdi_sio_ids.h
> @@ -882,6 +882,8 @@
>  /* Olimex */
>  #define OLIMEX_VID   0x15BA
>  #define OLIMEX_ARM_USB_OCD_PID   0x0003
> +#define OLIMEX_ARM_USB_TINY_PID  0x0004
> +#define OLIMEX_ARM_USB_TINY_H_PID0x002a
>  #define OLIMEX_ARM_USB_OCD_H_PID 0x002b
>  
>  /*

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: usb: usbtmc: Questions of the IVI Foundation

[Greg KH]

On Tue, May 16, 2017 at 05:04:37PM +0200, guido.kie...@rohde-schwarz.com wrote:
> 
> Sounds good. I think if we decide to extend the usbtmc driver then we will 
> hopefully find some driver developers within the companies who are 
> experienced :-)

If you all are maintaining a Windows driver, I'm sure some of the
developers involved will be more than willing to work on a sane
operating system and help you out :)

> > Where exactly are things not going fast enough?  Have you found any
> > specific bottlenecks?  How fast are you needing to go?  What type of
> > interface do you expect userspace to have to handle high rates of data?
> >
> 
> I'm not sure for 100%, but I assume that reading the IN pipe could be 
> setup asynchronously (e.g. with usb_submit_urb(..)) just before sending 
> send_request_dev_dep_msg_in(..).
> USBTMC_SIZE_IOBUFFER = 2kB is a bottleneck when dealing with data size > 
> 1MB (Need of Scatter/Gather).

Please test and send us patches for what you find.  You all have the
hardware, which is the hardest thing for people to get to test this type
of thing.

> > Have you evaluated both and found any differences?
> 
> The Windows USBTMC driver is maintained by the IVI Foundation. The main 
> difference is that protocol specific headers are filled up or analyzed in 
> user mode. This allows VISA vendors to be more flexible to maintain their 
> applications. The specification is here: 
> http://ivifoundation.org/downloads/Protocol%20Specifications/Ivi-6%202_USBTMC_2010-03-23.pdf

That puts most of the device specific control into the applications,
forcing everyone to duplicate the same logic over and over in all
programs.  Are you sure that is really very wise?

Anyway, please test out the Linux driver, and if you find problems,
please send patches, that's all we can offer here.

> At the moment I'm still not sure about the right way to go. The goal is to 
> avoid troubles between different USBTMC applications. So we could do one 
> of the following:
> 1. Drop out or disable the usbtmc driver. The IVI Foundation agrees to use 
> only libusb from now and in the future.

I'm not going to delete the in-kernel driver, as obviously it is being
used by people today, unless _everyone_ agrees that it should be done in
userspace instead, and we have a working solution there that everyone
can use (i.e. properly licensed.)

> 2. Replace or extend the usbtmc driver with a new one. For current 
> distributions the libusb is an alternative.

Again, please test what we have now, and send changes for what you have
issues with.  That's the way all Linux development happens, nothing
special here for just this tiny driver :)

good luck!

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

[PATCH] usb: gadget: f_uac2: calculate wMaxPacketSize before endpoint match

[Sekhar Nori]

Calculate wMaxPacketSize before endpoint matching the
descriptor is found.

This allows audio gadget to be used with controllers
which have a shortage or unavailability of endpoints
that can handle max packet size of 1023 (FS) or 1024
(HS).

With this audio gadget can be used on TI's OMAP-L138 SoC
which has a MUSB HS controller with endpoints having max
packet size much less than 1023 or 1024. See mode_2_cfg in
drivers/usb/musb/musb_core.c

Signed-off-by: Sekhar Nori 
---
 drivers/usb/gadget/function/f_uac2.c | 12 ++--
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/drivers/usb/gadget/function/f_uac2.c 
b/drivers/usb/gadget/function/f_uac2.c
index f6a0d3a1311b..5a7ba058d947 100644
--- a/drivers/usb/gadget/function/f_uac2.c
+++ b/drivers/usb/gadget/function/f_uac2.c
@@ -1065,6 +1065,12 @@ afunc_bind(struct usb_configuration *cfg, struct 
usb_function *fn)
agdev->as_in_intf = ret;
agdev->as_in_alt = 0;
 
+   /* Calculate wMaxPacketSize according to audio bandwidth */
+   set_ep_max_packet_size(uac2_opts, _epin_desc, 1000, true);
+   set_ep_max_packet_size(uac2_opts, _epout_desc, 1000, false);
+   set_ep_max_packet_size(uac2_opts, _epin_desc, 8000, true);
+   set_ep_max_packet_size(uac2_opts, _epout_desc, 8000, false);
+
agdev->out_ep = usb_ep_autoconfig(gadget, _epout_desc);
if (!agdev->out_ep) {
dev_err(dev, "%s:%d Error!\n", __func__, __LINE__);
@@ -1080,12 +1086,6 @@ afunc_bind(struct usb_configuration *cfg, struct 
usb_function *fn)
uac2->p_prm.uac2 = uac2;
uac2->c_prm.uac2 = uac2;
 
-   /* Calculate wMaxPacketSize according to audio bandwidth */
-   set_ep_max_packet_size(uac2_opts, _epin_desc, 1000, true);
-   set_ep_max_packet_size(uac2_opts, _epout_desc, 1000, false);
-   set_ep_max_packet_size(uac2_opts, _epin_desc, 8000, true);
-   set_ep_max_packet_size(uac2_opts, _epout_desc, 8000, false);
-
hs_epout_desc.bEndpointAddress = fs_epout_desc.bEndpointAddress;
hs_epin_desc.bEndpointAddress = fs_epin_desc.bEndpointAddress;
 
-- 
2.9.0

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

Re: [PATCH] usb: class: usblp: Fixed assignments inside if conditions

[Greg KH]

On Tue, May 16, 2017 at 07:37:31PM -0500, Alberto Ladron wrote:
> On Tue, May 16, 2017 at 01:44:47PM +0800, kbuild test robot wrote:
> Hi,
> 
>Here is the fix.  Or I have to resubmit the whole patch?

The whole patch, of course, you can't break the build with any
individual patch, yours is long gone from the patch queue now :)

thanks,

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

Re: [PATCH] usb: typec: Defer checking of valid power role swap to low level drivers

[Greg Kroah-Hartman]

On Wed, May 17, 2017 at 12:32:19AM -0700, Badhri Jagan Sridharan wrote:
> With this CL the lower level drivers are reponsible to check and make sure
> that the role swap can be performed.

What is a "CL"?

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 3/3] Fixed coding style issues.

[Greg KH]

On Tue, May 16, 2017 at 09:17:23PM -0500, Alberto Ladron wrote:
> Signed-off-by: Alberto Ladron 

I can't take patches without any changelog text.

Also only do "one logical thing" per patch, and no, fixing all coding
style issues is not "one thing".

Also, where are patches 1/3 and 2/3?

And finally, please don't send coding style changes to stuff outside of
drivers/staging/ in the kernel until you have the process well under
control.

please try again,

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

[GIT PULL] USB fixes for v4.12-rc

[Felipe Balbi]

Hi Greg,

here's my first pull request for v4.12-rc cycle. Only 6 patches this
time around. Where applicable, patches were tested on a few Intel
platforms I have available.

Let me know if you want anything to be changed.

cheers

The following changes since commit 2ea659a9ef488125eb46da6eb571de5eae5c43f6:

  Linux 4.12-rc1 (2017-05-13 13:19:49 -0700)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb.git 
tags/fixes-for-v4.12-rc2

for you to fetch changes up to 018047a1dba7636e1f7fdae2cc290a528991d648:

  usb: dwc3: keystone: check return value (2017-05-16 14:11:04 +0300)


usb: fixes for v4.12-rc2

- New device ID for Intel Canonlake CPUs
- fix for Isochronous performance regression on dwc3
- fix for out-of-bounds access on comp_desc on f_fs
- fix for lost events on dwc3 in case of spurious interrupts


Bogdan Mirea (1):
  usb: gadget: gserial: check if console kthread exists

Heikki Krogerus (1):
  usb: dwc3: pci: add Intel Cannonlake PCI IDs

Pan Bian (1):
  usb: dwc3: keystone: check return value

Roger Quadros (1):
  usb: dwc3: gadget: Fix ISO transfer performance

Thinh Nguyen (1):
  usb: dwc3: gadget: Prevent losing events in event cache

William Wu (1):
  usb: gadget: f_fs: avoid out of bounds access on comp_desc

 drivers/usb/dwc3/dwc3-keystone.c   |  4 
 drivers/usb/dwc3/dwc3-pci.c|  4 
 drivers/usb/dwc3/gadget.c  | 21 -
 drivers/usb/gadget/function/f_fs.c | 10 +-
 drivers/usb/gadget/function/u_serial.c |  2 +-
 5 files changed, 34 insertions(+), 7 deletions(-)

-- 
balbi


signature.asc
Description: PGP signature

Re: [PATCH] usb: dwc3: gadget: Fix ISO transfer performance

[Felipe Balbi]

Hi,

Roger Quadros  writes:
> On 21/04/17 15:58, Roger Quadros wrote:
>> Commit 08a36b543803 ("usb: dwc3: gadget: simplify __dwc3_gadget_ep_queue()")
>> caused a small change in the way ISO transfer is handled in the case
>> when XferInProgress event happens on Isoc EP with an active transfer.
>> This caused a performance degradation of 50%. e.g. using g_webcam on DUT
>> and luvcview on host the video frame rate dropped from 16fps to 8fps
>> @high-speed.
>> 
>> Make the ISO transfer handling equivalent to that prior to that commit
>> to get back the original ISO performance numbers.
>> 
>> Fixes: 08a36b543803 ("usb: dwc3: gadget: simplify __dwc3_gadget_ep_queue()")
>> Signed-off-by: Roger Quadros 
>
> Any comments?

pull request coming shortly ;-)

-- 
balbi


signature.asc
Description: PGP signature

Re: [RFC V1 1/1] net: cdc_ncm: Reduce memory use when kernel memory low

[Oliver Neukum]

Am Dienstag, den 16.05.2017, 20:24 +0200 schrieb Bjørn Mork:
> 
> I must say that I don't like the additional complexity added here.  If
> there are memory issues and you can reduce the buffer size to
> USB_CDC_NCM_NTB_MIN_OUT_SIZE, then why don't you just set a lower tx_max
> buffer size in the first place?
> 
>   echo 2048 > /sys/class/net/wwan0/cdc_ncm/tx_max
> 

Hi,

that would hurt performance across the board though.
Can we trigger memory compactation earlier?

Regards
Oliver

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

Re: [PATCH] usb: dwc3: gadget: Fix ISO transfer performance

[Roger Quadros]

Hi Felipe,

On 21/04/17 15:58, Roger Quadros wrote:
> Commit 08a36b543803 ("usb: dwc3: gadget: simplify __dwc3_gadget_ep_queue()")
> caused a small change in the way ISO transfer is handled in the case
> when XferInProgress event happens on Isoc EP with an active transfer.
> This caused a performance degradation of 50%. e.g. using g_webcam on DUT
> and luvcview on host the video frame rate dropped from 16fps to 8fps
> @high-speed.
> 
> Make the ISO transfer handling equivalent to that prior to that commit
> to get back the original ISO performance numbers.
> 
> Fixes: 08a36b543803 ("usb: dwc3: gadget: simplify __dwc3_gadget_ep_queue()")
> Signed-off-by: Roger Quadros 

Any comments?

> ---
>  drivers/usb/dwc3/gadget.c | 12 +++-
>  1 file changed, 11 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/usb/dwc3/gadget.c b/drivers/usb/dwc3/gadget.c
> index 0d75158..8f71ccc 100644
> --- a/drivers/usb/dwc3/gadget.c
> +++ b/drivers/usb/dwc3/gadget.c
> @@ -1245,14 +1245,24 @@ static int __dwc3_gadget_ep_queue(struct dwc3_ep 
> *dep, struct dwc3_request *req)
>   __dwc3_gadget_start_isoc(dwc, dep, cur_uf);
>   dep->flags &= ~DWC3_EP_PENDING_REQUEST;
>   }
> + return 0;
>   }
> - return 0;
> +
> + if ((dep->flags & DWC3_EP_BUSY) &&
> + !(dep->flags & DWC3_EP_MISSED_ISOC)) {
> + WARN_ON_ONCE(!dep->resource_index);
> + ret = __dwc3_gadget_kick_transfer(dep,
> +   dep->resource_index);
> + }
> +
> + goto out;
>   }
>  
>   if (!dwc3_calc_trbs_left(dep))
>   return 0;
>  
>   ret = __dwc3_gadget_kick_transfer(dep, 0);
> +out:
>   if (ret == -EBUSY)
>   ret = 0;
>  
> 

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

Re: [PATCH] usb: typec: Defer checking of valid power role swap to low level drivers

[Oliver Neukum]

Am Mittwoch, den 17.05.2017, 00:32 -0700 schrieb Badhri Jagan
Sridharan:

Hi,

> "Two independent set of mechanisms are defined to allow a USB Type-C
> DRP to functionally swap power and data roles. When USB PD is
> supported, power and data role swapping is performed as a subsequent
> step following the initial connection process. For non-PD implementations,
> power/data role swapping can optionally be dealt with as part of the initial
> connection process."

Well, as I read it, without PD once a connection is established, you
are stuck with your role. So it seems to me that blocking a later
attempt to change it makes sense.

Regards
Oliver

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

Re: [PATCH 3/3] Fixed coding style issues.

[Oliver Neukum]

Am Dienstag, den 16.05.2017, 21:17 -0500 schrieb Alberto Ladron:
> Signed-off-by: Alberto Ladron 
> ---
>  drivers/usb/storage/shuttle_usbat.c | 83 
> ++---
>  1 file changed, 41 insertions(+), 42 deletions(-)
> 
> diff --git a/drivers/usb/storage/shuttle_usbat.c 
> b/drivers/usb/storage/shuttle_usbat.c
> index 3b0294e..9eddc40 100644
> --- a/drivers/usb/storage/shuttle_usbat.c
> +++ b/drivers/usb/storage/shuttle_usbat.c
> @@ -152,13 +152,13 @@ struct usbat_info {
>   unsigned long sense_ascq;  /* additional sense code qualifier */
>  };
>  
> -#define short_pack(LSB,MSB) ( ((u16)(LSB)) | ( ((u16)(MSB))<<8 ) )
> +#define short_pack(LSB, MSB) (((u16)(LSB)) | (((u16)(MSB))<<8))
>  #define LSB_of(s) ((s)&0xFF)
>  #define MSB_of(s) ((s)>>8)
>  
> -static int transferred = 0;
> +static int transferred;
>  
> -static int usbat_flash_transport(struct scsi_cmnd * srb, struct us_data *us);
> +static int usbat_flash_transport(struct scsi_cmnd *srb, struct us_data *us);
>  static int usbat_hp8200e_transport(struct scsi_cmnd *srb, struct us_data 
> *us);
>  
>  static int init_usbat_cd(struct us_data *us);
> @@ -172,7 +172,7 @@ static int init_usbat_flash(struct us_data *us);
>   vendorName, productName, useProtocol, useTransport, \
>   initFunction, flags) \
>  { USB_DEVICE_VER(id_vendor, id_product, bcdDeviceMin, bcdDeviceMax), \
> -  .driver_info = (flags) }
> +.driver_info = (flags) }
>  
>  static struct usb_device_id usbat_usb_ids[] = {
>  #include "unusual_usbat.h"
> @@ -225,7 +225,7 @@ static void usbat_pack_ata_sector_cmd(unsigned char *buf,
>   */
>  static int usbat_get_device_type(struct us_data *us)
>  {
> - return ((struct usbat_info*)us->extra)->devicetype;
> + return ((struct usbat_info *)us->extra)->devicetype;
>  }
>  
>  /*
> @@ -268,7 +268,7 @@ static int usbat_write(struct us_data *us,
>   * Convenience function to perform a bulk read
>   */
>  static int usbat_bulk_read(struct us_data *us,
> -void* buf,
> +void *buf,
>  unsigned int len,
>  int use_sg)
>  {
> @@ -283,7 +283,7 @@ static int usbat_bulk_read(struct us_data *us,
>   * Convenience function to perform a bulk write
>   */
>  static int usbat_bulk_write(struct us_data *us,
> - void* buf,
> + void *buf,
>   unsigned int len,
>   int use_sg)
>  {
> @@ -416,11 +416,11 @@ static int usbat_wait_not_busy(struct us_data *us, int 
> minutes)
>* minutes!
>*/
>  
> - for (i=0; i<1200+minutes*60; i++) {
> + for (i = 0; i < 1200+minutes*60; i++) {
>  
> - result = usbat_get_status(us, status);
> + result = usbat_get_status(us, status);
>  
> - if (result!=USB_STOR_XFER_GOOD)
> + if (result != USB_STOR_XFER_GOOD)
>   return USB_STOR_TRANSPORT_ERROR;
>   if (*status & 0x01) { /* check condition */
>   result = usbat_read(us, USBAT_ATA, 0x10, status);
> @@ -429,16 +429,16 @@ static int usbat_wait_not_busy(struct us_data *us, int 
> minutes)
>   if (*status & 0x20) /* device fault */
>   return USB_STOR_TRANSPORT_FAILED;
>  
> - if ((*status & 0x80)==0x00) { /* not busy */
> + if ((*status & 0x80) == 0x00) { /* not busy */

Would you care to make a second pass and submit patches using the BIT()
macro where appropriate?

> [..]
> @@ -1753,13 +1752,13 @@ static int usbat_flash_transport(struct scsi_cmnd * 
> srb, struct us_data *us)
>* I don't think we'll ever see a READ_12 but support it anyway
>*/
>   block = ((u32)(srb->cmnd[2]) << 24) | ((u32)(srb->cmnd[3]) << 
> 16) |
> - ((u32)(srb->cmnd[4]) <<  8) | ((u32)(srb->cmnd[5]));
> + ((u32)(srb->cmnd[4]) <<  8) | ((u32)(srb->cmnd[5]));
>  
>   blocks = ((u32)(srb->cmnd[6]) << 24) | ((u32)(srb->cmnd[7]) << 
> 16) |
> -  ((u32)(srb->cmnd[8]) <<  8) | ((u32)(srb->cmnd[9]));
> + ((u32)(srb->cmnd[8]) <<  8) | ((u32)(srb->cmnd[9]));

There is no point in beautifying such things. Just make another pass
and use the macros for endianness conversion with unaligned access.

Regards
Oliver

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

[PATCH] usb: typec: Defer checking of valid power role swap to low level drivers

[Badhri Jagan Sridharan]

With this CL the lower level drivers are reponsible to check and make sure
that the role swap can be performed.

This facilitates the lower level driver to attempt to perform role swap
through initial connection process.

Quoting from the Type-C specification release(page 24),
role swaps are not limited to devices that only support PD.

"Two independent set of mechanisms are defined to allow a USB Type-C
DRP to functionally swap power and data roles. When USB PD is
supported, power and data role swapping is performed as a subsequent
step following the initial connection process. For non-PD implementations,
power/data role swapping can optionally be dealt with as part of the initial
connection process."

Signed-off-by: Badhri Jagan Sridharan 
---
 Documentation/ABI/testing/sysfs-class-typec |  7 +--
 drivers/usb/typec/typec.c   | 10 --
 2 files changed, 5 insertions(+), 12 deletions(-)

diff --git a/Documentation/ABI/testing/sysfs-class-typec 
b/Documentation/ABI/testing/sysfs-class-typec
index d4a3d23eb09c..ba4ca684adb2 100644
--- a/Documentation/ABI/testing/sysfs-class-typec
+++ b/Documentation/ABI/testing/sysfs-class-typec
@@ -20,13 +20,16 @@ Date:   April 2017
 Contact:   Heikki Krogerus 
 Description:
The supported power roles. This attribute can be used to request
-   power role swap on the port when the port supports USB Power
-   Delivery. Swapping is supported as synchronous operation, so
+   power role swap. Swapping is supported as synchronous 
operation, so
write(2) to the attribute will not return until the operation
has finished. The attribute is notified about role changes so
that poll(2) on the attribute wakes up. Change on the role will
also generate uevent KOBJ_CHANGE. The current role is show in
brackets, for example "[source] sink" when in source mode.
+   When both the port and the port-partner supports USB Power
+   Delivery, the PR_SWAP command is used to perform the role swap.
+   Otherwise, the port roles would be re-resolved by forcing
+   a disconnect and reconnect.
 
Valid values: source, sink
 
diff --git a/drivers/usb/typec/typec.c b/drivers/usb/typec/typec.c
index 89e540bb7ff3..fd2d661665fa 100644
--- a/drivers/usb/typec/typec.c
+++ b/drivers/usb/typec/typec.c
@@ -887,21 +887,11 @@ static ssize_t power_role_store(struct device *dev,
struct typec_port *port = to_typec_port(dev);
int ret = size;
 
-   if (!port->cap->pd_revision) {
-   dev_dbg(dev, "USB Power Delivery not supported\n");
-   return -EOPNOTSUPP;
-   }
-
if (!port->cap->pr_set) {
dev_dbg(dev, "power role swapping not supported\n");
return -EOPNOTSUPP;
}
 
-   if (port->pwr_opmode != TYPEC_PWR_MODE_PD) {
-   dev_dbg(dev, "partner unable to swap power role\n");
-   return -EIO;
-   }
-
ret = sysfs_match_string(typec_roles, buf);
if (ret < 0)
return ret;
-- 
2.13.0.303.g4ebf302169-goog

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

[PATCH 3/3] Fixed coding style issues.

[Alberto Ladron]

Signed-off-by: Alberto Ladron 
---
 drivers/usb/storage/shuttle_usbat.c | 83 ++---
 1 file changed, 41 insertions(+), 42 deletions(-)

diff --git a/drivers/usb/storage/shuttle_usbat.c 
b/drivers/usb/storage/shuttle_usbat.c
index 3b0294e..9eddc40 100644
--- a/drivers/usb/storage/shuttle_usbat.c
+++ b/drivers/usb/storage/shuttle_usbat.c
@@ -152,13 +152,13 @@ struct usbat_info {
unsigned long sense_ascq;  /* additional sense code qualifier */
 };
 
-#define short_pack(LSB,MSB) ( ((u16)(LSB)) | ( ((u16)(MSB))<<8 ) )
+#define short_pack(LSB, MSB) (((u16)(LSB)) | (((u16)(MSB))<<8))
 #define LSB_of(s) ((s)&0xFF)
 #define MSB_of(s) ((s)>>8)
 
-static int transferred = 0;
+static int transferred;
 
-static int usbat_flash_transport(struct scsi_cmnd * srb, struct us_data *us);
+static int usbat_flash_transport(struct scsi_cmnd *srb, struct us_data *us);
 static int usbat_hp8200e_transport(struct scsi_cmnd *srb, struct us_data *us);
 
 static int init_usbat_cd(struct us_data *us);
@@ -172,7 +172,7 @@ static int init_usbat_flash(struct us_data *us);
vendorName, productName, useProtocol, useTransport, \
initFunction, flags) \
 { USB_DEVICE_VER(id_vendor, id_product, bcdDeviceMin, bcdDeviceMax), \
-  .driver_info = (flags) }
+.driver_info = (flags) }
 
 static struct usb_device_id usbat_usb_ids[] = {
 #  include "unusual_usbat.h"
@@ -225,7 +225,7 @@ static void usbat_pack_ata_sector_cmd(unsigned char *buf,
  */
 static int usbat_get_device_type(struct us_data *us)
 {
-   return ((struct usbat_info*)us->extra)->devicetype;
+   return ((struct usbat_info *)us->extra)->devicetype;
 }
 
 /*
@@ -268,7 +268,7 @@ static int usbat_write(struct us_data *us,
  * Convenience function to perform a bulk read
  */
 static int usbat_bulk_read(struct us_data *us,
-  void* buf,
+  void *buf,
   unsigned int len,
   int use_sg)
 {
@@ -283,7 +283,7 @@ static int usbat_bulk_read(struct us_data *us,
  * Convenience function to perform a bulk write
  */
 static int usbat_bulk_write(struct us_data *us,
-   void* buf,
+   void *buf,
unsigned int len,
int use_sg)
 {
@@ -416,11 +416,11 @@ static int usbat_wait_not_busy(struct us_data *us, int 
minutes)
 * minutes!
 */
 
-   for (i=0; i<1200+minutes*60; i++) {
+   for (i = 0; i < 1200+minutes*60; i++) {
 
-   result = usbat_get_status(us, status);
+   result = usbat_get_status(us, status);
 
-   if (result!=USB_STOR_XFER_GOOD)
+   if (result != USB_STOR_XFER_GOOD)
return USB_STOR_TRANSPORT_ERROR;
if (*status & 0x01) { /* check condition */
result = usbat_read(us, USBAT_ATA, 0x10, status);
@@ -429,16 +429,16 @@ static int usbat_wait_not_busy(struct us_data *us, int 
minutes)
if (*status & 0x20) /* device fault */
return USB_STOR_TRANSPORT_FAILED;
 
-   if ((*status & 0x80)==0x00) { /* not busy */
+   if ((*status & 0x80) == 0x00) { /* not busy */
usb_stor_dbg(us, "Waited not busy for %d steps\n", i);
return USB_STOR_TRANSPORT_GOOD;
}
 
-   if (i<500)
+   if (i < 500)
msleep(10); /* 5 seconds */
-   else if (i<700)
+   else if (i < 700)
msleep(50); /* 10 seconds */
-   else if (i<1200)
+   else if (i < 1200)
msleep(100); /* 50 seconds */
else
msleep(1000); /* X minutes */
@@ -453,7 +453,7 @@ static int usbat_wait_not_busy(struct us_data *us, int 
minutes)
  * Read block data from the data register
  */
 static int usbat_read_block(struct us_data *us,
-   void* buf,
+   void *buf,
unsigned short len,
int use_sg)
 {
@@ -486,7 +486,7 @@ static int usbat_read_block(struct us_data *us,
  */
 static int usbat_write_block(struct us_data *us,
 unsigned char access,
-void* buf,
+void *buf,
 unsigned short len,
 int minutes,
 int use_sg)
@@ -548,7 +548,7 @@ static int usbat_hp8200e_rw_block_test(struct us_data *us,
 
BUG_ON(num_registers > US_IOBUF_SIZE/2);
 
-   for (i=0; i<20; i++) {
+   for (i = 0; i < 20; i++) {
 
/*
 * The first time we send the full command, which consists
@@ -561,7 +561,7 @@ static int 

Re: usb: usbtmc: Questions of the IVI Foundation

[Clemens Ladisch]

guido.kie...@rohde-schwarz.com wrote:
> linux-usb-ow...@vger.kernel.org schrieb am 15.05.2017 15:20:22:
>> Von: Greg KH 
>> On Mon, May 15, 2017 at 02:47:48PM +0200, Guido.Kiener@x wrote:
>>> 2. As we have looked at the Linux driver, we’ve noticed that performance
>>> of the usbtmc_read() function doesn’t keep up with our fastest
>>> instruments. Do you have any suggestions on how to improve the read
>>> performance?
>>
>> Where exactly are things not going fast enough?  Have you found any
>> specific bottlenecks?  How fast are you needing to go?  What type of
>> interface do you expect userspace to have to handle high rates of data?
>
> I'm not sure for 100%, but I assume that reading the IN pipe could be
> setup asynchronously (e.g. with usb_submit_urb(..)) just before sending
> send_request_dev_dep_msg_in(..).
> USBTMC_SIZE_IOBUFFER = 2kB is a bottleneck when dealing with data size >
> 1MB (Need of Scatter/Gather).

The major problem with usbtmc_read() is that it sends a new TMC read
request for every 2033-byte buffer it wants to read.

As a first step, try enabling the "rigol" quirk, which simply uses
a single read request for the entire buffer.  (I don't know why the
driver author thought this shouldn't be done for every device.)


Regards,
Clemens
--
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: kernel does not receive any USB3.0 plug/unplug events from the Renesas upd720202 chipset

[Felipe Balbi]

Hi,

"Xavier ."  writes:
> Hello.
> I have one problem with chip Renesas uPD720202 (card Startech PCIUSB3S22).
> In Windows XP run fine, very fine, but in GNU/Linux kernel does not
> receive any USB3.0 plug/unplug events, why?
> No usb device is recognized, it is as if the card had nothing connected.
>
> I have tried the following GNU/Linux:
>
> Ubuntu 17.04-desktop-i386
> Lubuntu 17.04-i386
> Debian-live-8.8.0-i386-lxde-desktop
> Centos-7-i386-LiveGnome-1611
> Fedora-LXDE-Live-i386-25-1.3
> OpenSUSE-13.2-DVD-i5860054
> In no case kernel does not receive any USB plug/unplug events
>
> The card firmware is the latest (2026) and is well installed.
> My machine is very old: P3 1Ghz on ASUS P3B-F but run fine
> Xavier.
> Thanks
>
> ***
>
> Attached 5 files: dmesg.txt, interrupts.txt, lspci.txt, lx201fw21.txt,
> dmesg_with_pendrive_connected_at_boot.txt
>
> dmesg.txt
>
> [0.00] Initializing cgroup subsys cpuset
> [0.00] Initializing cgroup subsys cpu
> [0.00] Initializing cgroup subsys cpuacct
> [0.00] Linux version 3.16.0-4-686-pae

this is really, really old kernel. Please try with v4.11 or v4.12-rc1
and tell us if you see the same problem.

-- 
balbi


signature.asc
Description: PGP signature