Re: usbtmc: vendor specific i/o

[Greg Kroah-Hartman]

On Mon, Aug 01, 2016 at 08:40:02PM +0200, Ladislav Michl wrote:
> Hi,
> 
> I need to ask usbtmc device for vendor specific data. What about adding ioctl
> which switches MsgIDs to be vendor specific? Or are there other, better,
> options? Patch bellow ilustrates changes to allow reading and writing vendor
> specific messages.

I don't understand exactly what you are changing here, it seems like you
are just changing the messages being sent to the device?  Doesn't that
break existing users?

confused,

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

[PATCH v4 6/6] 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.

Signed-off-by: Peter Chen 
---
 arch/arm/boot/dts/imx6qdl-udoo.dtsi | 26 +-
 1 file changed, 13 insertions(+), 13 deletions(-)

diff --git a/arch/arm/boot/dts/imx6qdl-udoo.dtsi 
b/arch/arm/boot/dts/imx6qdl-udoo.dtsi
index 3bee2f9..f29a72c2f 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>;
@@ -259,9 +250,18 @@
  {
pinctrl-names = "default";
pinctrl-0 = <_usbh>;
-   vbus-supply = <_usb_h1_vbus>;
-   clocks = < IMX6QDL_CLK_CKO>;
status = "okay";
+
+   #address-cells = <1>;
+   #size-cells = <0>;
+   usb2415: hub@1 {
+   compatible = "usb424,2514";
+   reg = <1>;
+
+   clocks = < IMX6QDL_CLK_CKO>;
+   reset-gpios = < 12 GPIO_ACTIVE_LOW>;
+   reset-duration-us = <3000>;
+   };
 };
 
  {
-- 
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 3/6] 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>;
};
 }
-- 
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 5/6] usb: chipidea: let chipidea core device of_node equal's glue layer device of_node

[Peter Chen]

From: Peter Chen 

At device tree, we have no device node for chipidea core,
the glue layer's node is the parent node for host and udc
device. But in related driver, the parent device is chipidea
core. So, in order to let the common driver get parent's node,
we let the core's device node equals glue layer device node.

Signed-off-by: Peter Chen 
Tested-by: Maciej S. Szmigiero 
Tested-by Joshua Clayton 
---
 drivers/usb/chipidea/core.c | 11 +++
 1 file changed, 11 insertions(+)

diff --git a/drivers/usb/chipidea/core.c b/drivers/usb/chipidea/core.c
index 69426e6..b189dc7 100644
--- a/drivers/usb/chipidea/core.c
+++ b/drivers/usb/chipidea/core.c
@@ -954,6 +954,15 @@ static int ci_hdrc_probe(struct platform_device *pdev)
dev_err(dev, "unable to init phy: %d\n", ret);
return ret;
}
+   /*
+* At device tree, we have no device node for chipidea core,
+* the glue layer's node is the parent node for host and udc
+* device. But in related driver, the parent device is chipidea
+* core. So, in order to let the common driver get parent's node,
+* we let the core's device node equals glue layer's node.
+*/
+   if (dev->parent && dev->parent->of_node)
+   dev->of_node = dev->parent->of_node;
 
ci->hw_bank.phys = res->start;
 
@@ -1057,6 +1066,7 @@ static int ci_hdrc_probe(struct platform_device *pdev)
 stop:
ci_role_destroy(ci);
 deinit_phy:
+   dev->of_node = NULL;
ci_usb_phy_exit(ci);
 
return ret;
@@ -1076,6 +1086,7 @@ static int ci_hdrc_remove(struct platform_device *pdev)
ci_extcon_unregister(ci);
ci_role_destroy(ci);
ci_hdrc_enter_lpm(ci, true);
+   ci->dev->of_node = NULL;
ci_usb_phy_exit(ci);
 
return 0;
-- 
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: [v3,2/6] power: add power sequence library

[Peter Chen]

On Fri, Jul 29, 2016 at 01:06:48PM -0700, Matthias Kaehlcke wrote:
> >...
> >
> >+static int pwrseq_generic_get(struct device_node *np, struct pwrseq *pwrseq)
> >+{
> >+struct pwrseq_generic *pwrseq_gen = to_generic_pwrseq(pwrseq);
> >+enum of_gpio_flags flags;
> >+int reset_gpio, ret = 0;
> >+
> >+pwrseq_gen->clk = of_clk_get_by_name(np, NULL);
> This only gets the first of potentially multiple clocks, is that intended?

Matthias, I have added multiple input clocks support at v4 patch set,
and you are at cc list.

-- 

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

[PATCH v4 1/6] 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>;
+   };
+   };
+};
-- 
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 4/6] 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. At first, it calls pwrseq_alloc_generic
to create a generic power sequence instance, then 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 
---
 drivers/usb/core/Makefile |   1 +
 drivers/usb/core/hub.c|  12 --
 drivers/usb/core/hub.h|  12 ++
 drivers/usb/core/pwrseq.c | 100 ++
 4 files changed, 122 insertions(+), 3 deletions(-)
 create mode 100644 drivers/usb/core/pwrseq.c

diff --git a/drivers/usb/core/Makefile b/drivers/usb/core/Makefile
index 9780877..39f2149 100644
--- a/drivers/usb/core/Makefile
+++ b/drivers/usb/core/Makefile
@@ -9,5 +9,6 @@ usbcore-y += port.o of.o
 
 usbcore-$(CONFIG_PCI)  += hcd-pci.o
 usbcore-$(CONFIG_ACPI) += usb-acpi.o
+usbcore-$(CONFIG_PWRSEQ_GENERIC) += pwrseq.o
 
 obj-$(CONFIG_USB)  += usbcore.o
diff --git a/drivers/usb/core/hub.c b/drivers/usb/core/hub.c
index bee1351..a346a8b 100644
--- a/drivers/usb/core/hub.c
+++ b/drivers/usb/core/hub.c
@@ -1700,6 +1700,7 @@ static void hub_disconnect(struct usb_interface *intf)
hub->error = 0;
hub_quiesce(hub, HUB_DISCONNECT);
 
+   hub_pwrseq_off(hub);
mutex_lock(_port_peer_mutex);
 
/* Avoid races with recursively_mark_NOTATTACHED() */
@@ -1733,6 +1734,7 @@ static int hub_probe(struct usb_interface *intf, const 
struct usb_device_id *id)
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);
@@ -1839,6 +1841,7 @@ descriptor_error:
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);
 
@@ -1852,11 +1855,14 @@ descriptor_error:
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_pwrseq_on(hub);
+   if (!ret)
+   return 0;
+   }
 
hub_disconnect(intf);
-   return -ENODEV;
+   return ret;
 }
 
 static int
diff --git a/drivers/usb/core/hub.h b/drivers/usb/core/hub.h
index 34c1a7e..9473f6f 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 list */
 };
 
 /**
@@ -166,3 +167,14 @@ static inline int hub_port_debounce_be_stable(struct 
usb_hub *hub,
 {
return hub_port_debounce(hub, port1, false);
 }
+
+#if IS_ENABLED(CONFIG_PWRSEQ_GENERIC)
+int hub_pwrseq_on(struct usb_hub *hub);
+void hub_pwrseq_off(struct usb_hub *hub);
+#else
+static inline int hub_pwrseq_on(struct usb_hub *hub)
+{
+   return 0;
+}
+static inline void hub_pwrseq_off(struct usb_hub *hub) {}
+#endif /* CONFIG_PWRSEQ_GENERIC */
diff --git a/drivers/usb/core/pwrseq.c b/drivers/usb/core/pwrseq.c
new file mode 100644
index 000..837fe66
--- /dev/null
+++ b/drivers/usb/core/pwrseq.c
@@ -0,0 +1,100 @@
+/*
+ * pwrseq.cUSB device power sequence management
+ *
+ * Copyright (C) 2016 Freescale Semiconductor, Inc.
+ * Author: Peter Chen 
+ *
+ * This program is free software: you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2  of
+ * the License as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program.  If not, see .
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "hub.h"
+
+struct usb_pwrseq_node {
+   struct pwrseq *pwrseq;
+   struct list_head list;
+};
+
+static int hub_of_pwrseq_on(struct 

[PATCH v4 2/6] 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.

pwrseq_generic is intended for general purpose of power sequence, which
handles gpios and clocks currently, and can cover regulator and pinctrl
in future. The host driver calls pwrseq_alloc_generic to create
an generic pwrseq instance.

Signed-off-by: Peter Chen 
Tested-by Joshua Clayton 
---
 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   |  71 ++
 drivers/power/pwrseq/pwrseq_generic.c | 170 ++
 include/linux/power/pwrseq.h  |  52 +++
 8 files changed, 326 insertions(+)
 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/MAINTAINERS b/MAINTAINERS
index 1ae6c84..407254b 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -9283,6 +9283,15 @@ F:   include/linux/pm_*
 F: include/linux/powercap.h
 F: drivers/powercap/
 
+POWER SEQUENCE LIBRARY
+M: Peter Chen 
+T: git git://git.kernel.org/pub/scm/linux/kernel/git/peter.chen/usb.git
+L: linux...@vger.kernel.org
+S: Maintained
+F: Documentation/devicetree/bindings/power/pwrseq/
+F: drivers/power/pwrseq/
+F: include/linux/power/pwrseq.h/
+
 POWER SUPPLY CLASS/SUBSYSTEM and DRIVERS
 M: Sebastian Reichel 
 M: Dmitry Eremin-Solenikov 
diff --git a/drivers/power/Kconfig b/drivers/power/Kconfig
index acd4a15..f6aa4fd 100644
--- a/drivers/power/Kconfig
+++ b/drivers/power/Kconfig
@@ -515,3 +515,4 @@ endif # POWER_SUPPLY
 
 source "drivers/power/reset/Kconfig"
 source "drivers/power/avs/Kconfig"
+source "drivers/power/pwrseq/Kconfig"
diff --git a/drivers/power/Makefile b/drivers/power/Makefile
index e46b75d..4ed2e12 100644
--- a/drivers/power/Makefile
+++ b/drivers/power/Makefile
@@ -74,3 +74,4 @@ obj-$(CONFIG_CHARGER_TPS65217)+= tps65217_charger.o
 obj-$(CONFIG_POWER_RESET)  += reset/
 obj-$(CONFIG_AXP288_FUEL_GAUGE) += axp288_fuel_gauge.o
 obj-$(CONFIG_AXP288_CHARGER)   += axp288_charger.o
+obj-$(CONFIG_POWER_SEQUENCE)   += pwrseq/
diff --git a/drivers/power/pwrseq/Kconfig b/drivers/power/pwrseq/Kconfig
new file mode 100644
index 000..188729e
--- /dev/null
+++ b/drivers/power/pwrseq/Kconfig
@@ -0,0 +1,20 @@
+#
+# Power Sequence library
+#
+
+config POWER_SEQUENCE
+   bool
+
+menu "Power Sequence Support"
+
+config PWRSEQ_GENERIC
+   bool "Generic power sequence control"
+   depends on OF
+   select POWER_SEQUENCE
+   help
+ It is used for drivers which needs to do power sequence
+ (eg, turn on clock, toggle reset gpio) before the related
+ devices can be found by hardware. This generic one can be
+ used for common power sequence control.
+
+endmenu
diff --git a/drivers/power/pwrseq/Makefile b/drivers/power/pwrseq/Makefile
new file mode 100644
index 000..ad82389
--- /dev/null
+++ b/drivers/power/pwrseq/Makefile
@@ -0,0 +1,2 @@
+obj-$(CONFIG_POWER_SEQUENCE) += core.o
+obj-$(CONFIG_PWRSEQ_GENERIC) += pwrseq_generic.o
diff --git a/drivers/power/pwrseq/core.c b/drivers/power/pwrseq/core.c
new file mode 100644
index 000..60f1e4e
--- /dev/null
+++ b/drivers/power/pwrseq/core.c
@@ -0,0 +1,71 @@
+/*
+ * core.c  power sequence core file
+ *
+ * Copyright (C) 2016 Freescale Semiconductor, Inc.
+ * Author: Peter Chen 
+ *
+ * This program is free software: you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2  of
+ * the License as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program.  If not, see .
+ */
+
+#include 
+
+static DEFINE_MUTEX(pwrseq_list_mutex);
+static LIST_HEAD(pwrseq_list);
+
+int pwrseq_get(struct 

[PATCH v4 0/6] power: add power sequence library

[Peter Chen]

Hi all,

This is a follow-up for my last power sequence framework patch set [1].
According to Rob Herring and Ulf Hansson's comments[2], I use a generic
power sequence library for parsing the power sequence elements on DT,
and implement generic power sequence on library. The host driver
can allocate power sequence instance, and calls pwrseq APIs accordingly.

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.

[1] http://www.spinics.net/lists/linux-usb/msg142755.html
[2] http://www.spinics.net/lists/linux-usb/msg143106.html
[3] http://www.spinics.net/lists/linux-usb/msg142815.html

Changes for v4:
- Create the patch on next-20160722 
- Fix the of_node is not NULL after chipidea driver is unbinded [Patch 5/6]
- Using more friendly wait method for reset gpio [Patch 2/6]
- Support multiple input clocks [Patch 2/6]
- Add Rob Herring's ack for DT changes
- Add Joshua Clayton's Tested-by

Changes for v3:
- Delete "power-sequence" property at binding-doc, and change related code
  at both library and user code.
- Change binding-doc example node name with Rob's comments
- of_get_named_gpio_flags only gets the gpio, but without setting gpio flags,
  add additional code request gpio with proper gpio flags
- Add Philipp Zabel's Ack and MAINTAINER's entry

Changes for v2:
- Delete "pwrseq" prefix and clock-names for properties at dt binding
- Should use structure not but its pointer for kzalloc
- Since chipidea core has no of_node, let core's of_node equals glue
  layer's at core's probe

Peter Chen (6):
  binding-doc: power: pwrseq-generic: add binding doc for generic power
sequence library
  power: add power sequence library
  binding-doc: usb: usb-device: add optional properties for power
sequence
  usb: core: add power sequence handling for USB devices
  usb: chipidea: let chipidea core device of_node equal's glue layer
device of_node
  ARM: dts: imx6qdl-udoo.dtsi: fix onboard USB HUB property

 .../bindings/power/pwrseq/pwrseq-generic.txt   |  48 ++
 .../devicetree/bindings/usb/usb-device.txt |  10 +-
 MAINTAINERS|   9 ++
 arch/arm/boot/dts/imx6qdl-udoo.dtsi|  26 ++--
 drivers/power/Kconfig  |   1 +
 drivers/power/Makefile |   1 +
 drivers/power/pwrseq/Kconfig   |  20 +++
 drivers/power/pwrseq/Makefile  |   2 +
 drivers/power/pwrseq/core.c|  71 +
 drivers/power/pwrseq/pwrseq_generic.c  | 170 +
 drivers/usb/chipidea/core.c|  11 ++
 drivers/usb/core/Makefile  |   1 +
 drivers/usb/core/hub.c |  12 +-
 drivers/usb/core/hub.h |  12 ++
 drivers/usb/core/pwrseq.c  | 100 
 include/linux/power/pwrseq.h   |  52 +++
 16 files changed, 529 insertions(+), 17 deletions(-)
 create mode 100644 
Documentation/devicetree/bindings/power/pwrseq/pwrseq-generic.txt
 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 drivers/usb/core/pwrseq.c
 create mode 100644 include/linux/power/pwrseq.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] extcon: Split out the extcon APIs for extcon provider driver

[Chanwoo Choi]

This patchs split out the extcon APIs of extcon provider driver in order to
prevent the direct access of struct extcon_dev by extcon consumer driver.
The extcon consumer driver don't need to handle the extcon provider APIs.

The extcon subsystem has two type of extcon drivers as following:
- extcon provider driver
: Detect the external connector and identify the state/property of
  each external connector. And it send the notification to synchronize
  the information between provider and consumer driver.
- extcon consumer driver
: Receive the notifcation from extcon provider driver. When receving the noti,
  it can get the both state and property of specific external connector.

Cc: Myungjoo Ham 
Cc: Chen-Yu Tsai 
Cc: Krzysztof Kozlowski 
Cc: Yoshihiro Shimoda 
Cc: Kishon Vijay Abraham I 
Cc: Maxime Ripard 
Cc: Felipe Balbi 
Cc: Greg Kroah-Hartman 
Cc: Chris Zhong 
Cc: Roger Quadros 
Cc: Charles Keepax 
Cc: patc...@opensource.wolfsonmicro.com
Cc: linux-renesas-...@vger.kernel.org
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-usb@vger.kernel.org
Signed-off-by: Chanwoo Choi 
---
 drivers/extcon/devres.c  |   2 +-
 drivers/extcon/extcon-adc-jack.c |   2 +-
 drivers/extcon/extcon-arizona.c  |   2 +-
 drivers/extcon/extcon-axp288.c   |   2 +-
 drivers/extcon/extcon-gpio.c |   2 +-
 drivers/extcon/extcon-max14577.c |   2 +-
 drivers/extcon/extcon-max3355.c  |   2 +-
 drivers/extcon/extcon-max77693.c |   2 +-
 drivers/extcon/extcon-max77843.c |   2 +-
 drivers/extcon/extcon-max8997.c  |   2 +-
 drivers/extcon/extcon-palmas.c   |   1 +
 drivers/extcon/extcon-rt8973a.c  |   2 +-
 drivers/extcon/extcon-sm5502.c   |   2 +-
 drivers/extcon/extcon-usb-gpio.c |   2 +-
 drivers/extcon/extcon.c  |   2 +-
 drivers/phy/phy-rcar-gen3-usb2.c |   2 +-
 drivers/phy/phy-sun4i-usb.c  |   2 +-
 drivers/usb/phy/phy-tahvo.c  |   2 +-
 include/linux/extcon-provider.h  | 262 +++
 include/linux/extcon.h   | 169 +
 20 files changed, 284 insertions(+), 182 deletions(-)
 create mode 100644 include/linux/extcon-provider.h

diff --git a/drivers/extcon/devres.c b/drivers/extcon/devres.c
index e686acd1c459..1b7dce13b21b 100644
--- a/drivers/extcon/devres.c
+++ b/drivers/extcon/devres.c
@@ -14,7 +14,7 @@
  * GNU General Public License for more details.
  */
 
-#include 
+#include 
 
 static int devm_extcon_dev_match(struct device *dev, void *res, void *data)
 {
diff --git a/drivers/extcon/extcon-adc-jack.c b/drivers/extcon/extcon-adc-jack.c
index e62e6cd7e00a..7340b03487fb 100644
--- a/drivers/extcon/extcon-adc-jack.c
+++ b/drivers/extcon/extcon-adc-jack.c
@@ -26,7 +26,7 @@
 #include 
 #include 
 #include 
-#include 
+#include 
 
 /**
  * struct adc_jack_data - internal data for adc_jack device driver
diff --git a/drivers/extcon/extcon-arizona.c b/drivers/extcon/extcon-arizona.c
index 493bd9fe5f67..bf35697f7278 100644
--- a/drivers/extcon/extcon-arizona.c
+++ b/drivers/extcon/extcon-arizona.c
@@ -27,7 +27,7 @@
 #include 
 #include 
 #include 
-#include 
+#include 
 
 #include 
 
diff --git a/drivers/extcon/extcon-axp288.c b/drivers/extcon/extcon-axp288.c
index fd55c2f2080a..2ba1a14a51fa 100644
--- a/drivers/extcon/extcon-axp288.c
+++ b/drivers/extcon/extcon-axp288.c
@@ -23,7 +23,7 @@
 #include 
 #include 
 #include 
-#include 
+#include 
 #include 
 #include 
 #include 
diff --git a/drivers/extcon/extcon-gpio.c b/drivers/extcon/extcon-gpio.c
index b1b0264eb12d..835488ea7dbb 100644
--- a/drivers/extcon/extcon-gpio.c
+++ b/drivers/extcon/extcon-gpio.c
@@ -17,7 +17,7 @@
  * GNU General Public License for more details.
  */
 
-#include 
+#include 
 #include 
 #include 
 #include 
diff --git a/drivers/extcon/extcon-max14577.c b/drivers/extcon/extcon-max14577.c
index 852a7112f451..d0a01490649b 100644
--- a/drivers/extcon/extcon-max14577.c
+++ b/drivers/extcon/extcon-max14577.c
@@ -23,7 +23,7 @@
 #include 
 #include 
 #include 
-#include 
+#include 
 
 #defineDELAY_MS_DEFAULT17000   /* unit: 
millisecond */
 
diff --git a/drivers/extcon/extcon-max3355.c b/drivers/extcon/extcon-max3355.c
index c24abec5d06c..ec94c2ff8f6f 100644
--- a/drivers/extcon/extcon-max3355.c
+++ b/drivers/extcon/extcon-max3355.c
@@ -9,7 +9,7 @@
  * may be copied, distributed, and modified under those terms.
  */
 
-#include 
+#include 
 #include 
 #include 
 #include 
diff --git a/drivers/extcon/extcon-max77693.c b/drivers/extcon/extcon-max77693.c
index f17cb76b567c..9729b1fc402c 100644
--- a/drivers/extcon/extcon-max77693.c
+++ b/drivers/extcon/extcon-max77693.c
@@ -26,7 +26,7 @@
 #include 
 #include 
 #include 
-#include 
+#include 
 #include 
 #include 
 

Re: pwc over musb: 100% frame drop (lost) on high resolution stream

[Viresh Kumar]

On 31-07-16, 23:31, Matwey V. Kornilov wrote:
> Hello,
> 
> I've also just found that the same commit breaks cpufreq on BeagleBone Black 
> :)
> 
> So, probably without HCD_BH flag musb works correctly only at 1Ghz CPU
> frequency, which is unlisted and being set to 720Mhz by cpufreq driver
> (as it did whet there was cpufreq driver).
> 
> 2016-07-29 21:01 GMT+03:00 Matwey V. Kornilov :
> > Hello,
> >
> > I've found that the following commit fixes the issue:
> >
> > commit 7694ca6e1d6f01122f05039b81f70f64b1ec4063
> > Author: Viresh Kumar 
> > Date:   Fri Apr 22 16:58:42 2016 +0530
> >
> > cpufreq: omap: Use generic platdev driver
> >
> > The cpufreq-dt-platdev driver supports creation of cpufreq-dt platform
> > device now, reuse that and remove similar code from platform code.

Sorry for this commit and the man hours wasted to get to this :(

I am trying to figure out why things break though, as this patch shouldn't have
had any functional impacts. So, some of the assumptions I had are surely
incorrect..

The defconfig linked in the original thread [1] has this:

CONFIG_CPUFREQ_DT=m

So, the cpufreq-dt module needs to get inserted to make it work.

Can someone provide the output of:

cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_driver

with and without this patch ?

It looks like we wanted to select "omap-cpufreq" for beaglebone and selected
"cpufreq-dt" by mistake.

[Note]: I am not subscribed to USB lists and so please include me for any emails
you want my response on.

--
viresh

[1] http://www.spinics.net/lists/linux-usb/msg143956.html

-- 
viresh
--
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] power: add power sequence library

[Peter Chen]

On Mon, Aug 01, 2016 at 07:55:10AM -0700, Joshua Clayton wrote:
> 
> 
> On 07/28/2016 09:41 AM, Fabio Estevam wrote:
> > Hi Joshua,
> >
> > On Thu, Jul 28, 2016 at 12:56 PM, Joshua Clayton
> >  wrote:
> >
> >> I assume there is a v4 coming due to rmk's comments on patch 5.
> >> I couldn't figure out where to null the of_node in error paths, but in 
> >> testing
> >> we did put a line of code to null the of_node on release.
> >>
> >> but...
> >> As an aside,
> >> I was hoping this series would magically fix a problem
> >> with the imx6q-evi which has forced us to disable
> >> runtime power management. But it did not. :(
> > I also see a similar problem on a mx28 board with a hub.
> >
> > Does it help in your case if you pass 'usbcore.autosuspend=-1' in the
> > kernel command line?
> >
> > Regards,
> >
> > Fabio Estevam
> Thanks a million, Fabio!
> 
> 'usbcore.autosuspend=-1' quiets the errors.
> 
> ~joshua
> 

If you are using imx6q, there are some patches which is not upstreamed
to workaround one SoC problem.

http://www.spinics.net/lists/linux-usb/msg98682.html

Try to implement the design for notify_suspend/resume at
drivers/usb/phy/phy-mxs-usb.c and drivers/usb/chipidea/host.c

You can refer to the code at:
http://git.freescale.com/git/cgit.cgi/imx/linux-2.6-imx.git/tree/?h=imx_4.1.15_1.0.0_ga

-- 

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

[PATCH v2] USB: validate wMaxPacketValue entries in endpoint descriptors

[Alan Stern]

Erroneous or malicious endpoint descriptors may have non-zero bits in
reserved positions, or out-of-bounds values.  This patch helps prevent
these from causing problems by bounds-checking the wMaxPacketValue
entries in endpoint descriptors and capping the values at the maximum
allowed.

This issue was first discovered and tests were conducted by Jake Lamberson
, an intern working for Rosie Hall.

Signed-off-by: Alan Stern 
Reported-by: roswest 
Tested-by: roswest 
CC: 

---

v2: Add text to the patch description crediting Jake Lamberson for his 
work.

[as1806b]


 drivers/usb/core/config.c |   66 +++---
 1 file changed, 63 insertions(+), 3 deletions(-)

Index: usb-4.x/drivers/usb/core/config.c
===
--- usb-4.x.orig/drivers/usb/core/config.c
+++ usb-4.x/drivers/usb/core/config.c
@@ -171,6 +171,31 @@ static void usb_parse_ss_endpoint_compan
ep, buffer, size);
 }
 
+static const unsigned short low_speed_maxpacket_maxes[4] = {
+   [USB_ENDPOINT_XFER_CONTROL] = 8,
+   [USB_ENDPOINT_XFER_ISOC] = 0,
+   [USB_ENDPOINT_XFER_BULK] = 0,
+   [USB_ENDPOINT_XFER_INT] = 8,
+};
+static const unsigned short full_speed_maxpacket_maxes[4] = {
+   [USB_ENDPOINT_XFER_CONTROL] = 64,
+   [USB_ENDPOINT_XFER_ISOC] = 1023,
+   [USB_ENDPOINT_XFER_BULK] = 64,
+   [USB_ENDPOINT_XFER_INT] = 64,
+};
+static const unsigned short high_speed_maxpacket_maxes[4] = {
+   [USB_ENDPOINT_XFER_CONTROL] = 64,
+   [USB_ENDPOINT_XFER_ISOC] = 1024,
+   [USB_ENDPOINT_XFER_BULK] = 512,
+   [USB_ENDPOINT_XFER_INT] = 1023,
+};
+static const unsigned short super_speed_maxpacket_maxes[4] = {
+   [USB_ENDPOINT_XFER_CONTROL] = 512,
+   [USB_ENDPOINT_XFER_ISOC] = 1024,
+   [USB_ENDPOINT_XFER_BULK] = 1024,
+   [USB_ENDPOINT_XFER_INT] = 1024,
+};
+
 static int usb_parse_endpoint(struct device *ddev, int cfgno, int inum,
 int asnum, struct usb_host_interface *ifp, int num_ep,
 unsigned char *buffer, int size)
@@ -179,6 +204,8 @@ static int usb_parse_endpoint(struct dev
struct usb_endpoint_descriptor *d;
struct usb_host_endpoint *endpoint;
int n, i, j, retval;
+   unsigned int maxp;
+   const unsigned short *maxpacket_maxes;
 
d = (struct usb_endpoint_descriptor *) buffer;
buffer += d->bLength;
@@ -290,6 +317,42 @@ static int usb_parse_endpoint(struct dev
endpoint->desc.wMaxPacketSize = cpu_to_le16(8);
}
 
+   /* Validate the wMaxPacketSize field */
+   maxp = usb_endpoint_maxp(>desc);
+
+   /* Find the highest legal maxpacket size for this endpoint */
+   i = 0;  /* additional transactions per microframe */
+   switch (to_usb_device(ddev)->speed) {
+   case USB_SPEED_LOW:
+   maxpacket_maxes = low_speed_maxpacket_maxes;
+   break;
+   case USB_SPEED_FULL:
+   maxpacket_maxes = full_speed_maxpacket_maxes;
+   break;
+   case USB_SPEED_HIGH:
+   /* Bits 12..11 are allowed only for HS periodic endpoints */
+   if (usb_endpoint_xfer_int(d) || usb_endpoint_xfer_isoc(d)) {
+   i = maxp & (BIT(12) | BIT(11));
+   maxp &= ~i;
+   }
+   /* fallthrough */
+   default:
+   maxpacket_maxes = high_speed_maxpacket_maxes;
+   break;
+   case USB_SPEED_SUPER:
+   case USB_SPEED_SUPER_PLUS:
+   maxpacket_maxes = super_speed_maxpacket_maxes;
+   break;
+   }
+   j = maxpacket_maxes[usb_endpoint_type(>desc)];
+
+   if (maxp > j) {
+   dev_warn(ddev, "config %d interface %d altsetting %d endpoint 
0x%X has invalid maxpacket %d, setting to %d\n",
+   cfgno, inum, asnum, d->bEndpointAddress, maxp, j);
+   maxp = j;
+   endpoint->desc.wMaxPacketSize = cpu_to_le16(i | maxp);
+   }
+
/*
 * Some buggy high speed devices have bulk endpoints using
 * maxpacket sizes other than 512.  High speed HCDs may not
@@ -297,9 +360,6 @@ static int usb_parse_endpoint(struct dev
 */
if (to_usb_device(ddev)->speed == USB_SPEED_HIGH
&& usb_endpoint_xfer_bulk(d)) {
-   unsigned maxp;
-
-   maxp = usb_endpoint_maxp(>desc) & 0x07ff;
if (maxp != 512)
dev_warn(ddev, "config %d interface %d altsetting %d "
"bulk endpoint 0x%X has invalid maxpacket %d\n",

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

Re: [PATCH] USB: validate wMaxPacketValue entries in endpoint descriptors

[roswest]

On Mon Aug 01 2016 14:28:46 GMT-0400 (EDT), Greg KH wrote:
> On Mon, Aug 01, 2016 at 02:04:06PM -0400, Alan Stern wrote:
>> On Mon, 1 Aug 2016, roswest wrote:
>>
>>> Alan,
>>>
>>> I think it would be more accurate to put Jake Lamberson as the reporter
>>> and tester.
>>
>> I could mention him in the body of the patch description.  But it
>> doesn't seem appropriate to list him as the reporter or tester because
>> he didn't report anything to me or to the mailing list.  Only you did.
>>
>> Greg, any thoughts?
> 
> rowest, if Jake didn't email us anything, how could they be listed as a
> reporter?
> 
> thanks,
> 
> greg k-h
> 

Greg,

Fair enough.  He did the work though, and was listed as the finder in
the bug description I sent.  I sent the email because I didn't expect
the issues to be resolved before the end of his internship.

Rosie



signature.asc
Description: OpenPGP digital signature

Re: [PATCH] USB: validate wMaxPacketValue entries in endpoint descriptors

[Greg KH]

On Mon, Aug 01, 2016 at 02:04:06PM -0400, Alan Stern wrote:
> On Mon, 1 Aug 2016, roswest wrote:
> 
> > Alan,
> > 
> > I think it would be more accurate to put Jake Lamberson as the reporter
> > and tester.
> 
> I could mention him in the body of the patch description.  But it
> doesn't seem appropriate to list him as the reporter or tester because
> he didn't report anything to me or to the mailing list.  Only you did.
> 
> Greg, any thoughts?

rowest, if Jake didn't email us anything, how could they be listed as a
reporter?

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: validate wMaxPacketValue entries in endpoint descriptors

[Greg KH]

On Mon, Aug 01, 2016 at 12:18:54PM -0400, Alan Stern wrote:
> Erroneous or malicious endpoint descriptors may have non-zero bits in
> reserved positions, or out-of-bounds values.  This patch helps prevent
> these from causing problems by bounds-checking the wMaxPacketValue
> entries in endpoint descriptors and capping the values at the maximum
> allowed.
> 
> Signed-off-by: Alan Stern 
> Reported-by: roswest 
> Tested-by: roswest 
> 
> ---
> 
> I don't think this needs to go into the -stable kernels, but if anyone
> disagrees I won't object.

It's a "hardening" think to fix a known issue, I think it should go
there, but will wait for some testing in Linus's tree before doing so.

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] usb: host: u132-hcd: Remove deprecated create_singlethread_workqueue

[Alan Stern]

On Mon, 1 Aug 2016, Tejun Heo wrote:

> Hello,
> 
> On Mon, Aug 01, 2016 at 03:50:36PM +0200, Michal Hocko wrote:
> > > All that would do is deferring the deadlock, right?  I'm not sure it
> > > makes a lot of sense to protect an IO path against memory pressure
> > > half-way.  It either can be depended during memory reclaim or it
> > > can't. 
> > 
> > Completely agreed! If the rescuer thread can block on a memory
> > allocation be it GFP_NOIO or others it is basically useless.
> ...
> > > Can MM people please chime in?  The question is about USB stoage
> > > devices and memory reclaim.  USB doesn't guarantee forward progress
> > > under memory pressure but tries a best-effort attempt with GFP_NOIO
> > > and ATOMIC.  Is this the right thing to do?
> > 
> > If any real IO depends on those devices then this is not sufficient and
> > they need some form of guarantee for progress (aka mempool).
> 
> Oliver, Alan, what do you think?  If USB itself can't operate without
> allocating memory during transactions, whatever USB storage drivers
> are doing isn't all that meaningful.  Can we proceed with the
> workqueue patches?  Also, it could be that the only thing GFP_NOIO and
> GFP_ATOMIC are doing is increasing the chance of IO failures under
> memory pressure.  Maybe it'd be a good idea to reconsider the
> approach?

I agree that USB's approach to memory allocation won't prevent failures 
when there is severe pressure.

However, is it possible that the _type_ of failure might be more 
transparent?  With GFP_NOIO, you end up with a cascading series of 
allocation errors and it's obvious that something has gone very wrong.  
If we were to switch to GFP_KERNEL, page-out could lead to deadlock 
with no diagnostics (except perhaps for a watchdog warning).

Regardless, I would like to hear Oliver's thoughts.

Alan Stern

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

usbtmc: vendor specific i/o

[Ladislav Michl]

Hi,

I need to ask usbtmc device for vendor specific data. What about adding ioctl
which switches MsgIDs to be vendor specific? Or are there other, better,
options? Patch bellow ilustrates changes to allow reading and writing vendor
specific messages.

Thank you,
ladis

diff --git a/drivers/usb/class/usbtmc.c b/drivers/usb/class/usbtmc.c
index 917a55c..594f74d 100644
--- a/drivers/usb/class/usbtmc.c
+++ b/drivers/usb/class/usbtmc.c
@@ -549,7 +549,7 @@ static int send_request_dev_dep_msg_in(struct 
usbtmc_device_data *data, size_t t
/* Setup IO buffer for REQUEST_DEV_DEP_MSG_IN message
 * Refer to class specs for details
 */
-   buffer[0] = 2;
+   buffer[0] = 127;
buffer[1] = data->bTag;
buffer[2] = ~data->bTag;
buffer[3] = 0; /* Reserved */
@@ -677,8 +677,8 @@ static ssize_t usbtmc_read(struct file *filp, char __user 
*buf,
goto exit;
}
 
-   if (buffer[0] != 2) {
-   dev_err(dev, "Device sent reply with wrong 
MsgID: %u != 2\n", buffer[0]);
+   if (buffer[0] != 127) {
+   dev_err(dev, "Device sent reply with wrong 
MsgID: %u != 127\n", buffer[0]);
if (data->auto_abort)
usbtmc_ioctl_abort_bulk_in(data);
goto exit;
@@ -807,7 +807,7 @@ static ssize_t usbtmc_write(struct file *filp, const char 
__user *buf,
}
 
/* Setup IO buffer for DEV_DEP_MSG_OUT message */
-   buffer[0] = 1;
+   buffer[0] = 126;
buffer[1] = data->bTag;
buffer[2] = ~data->bTag;
buffer[3] = 0; /* Reserved */
--
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: validate wMaxPacketValue entries in endpoint descriptors

[Alan Stern]

On Mon, 1 Aug 2016, roswest wrote:

> Alan,
> 
> I think it would be more accurate to put Jake Lamberson as the reporter
> and tester.

I could mention him in the body of the patch description.  But it
doesn't seem appropriate to list him as the reporter or tester because
he didn't report anything to me or to the mailing list.  Only you did.

Greg, any thoughts?

Alan Stern


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

Re: [RFC] usb: host: u132-hcd: Remove deprecated create_singlethread_workqueue

[Michal Hocko]

On Mon 01-08-16 14:00:57, Alan Stern wrote:
> On Mon, 1 Aug 2016, Tejun Heo wrote:
> 
> > Hello,
> > 
> > On Mon, Aug 01, 2016 at 03:50:36PM +0200, Michal Hocko wrote:
> > > > All that would do is deferring the deadlock, right?  I'm not sure it
> > > > makes a lot of sense to protect an IO path against memory pressure
> > > > half-way.  It either can be depended during memory reclaim or it
> > > > can't. 
> > > 
> > > Completely agreed! If the rescuer thread can block on a memory
> > > allocation be it GFP_NOIO or others it is basically useless.
> > ...
> > > > Can MM people please chime in?  The question is about USB stoage
> > > > devices and memory reclaim.  USB doesn't guarantee forward progress
> > > > under memory pressure but tries a best-effort attempt with GFP_NOIO
> > > > and ATOMIC.  Is this the right thing to do?
> > > 
> > > If any real IO depends on those devices then this is not sufficient and
> > > they need some form of guarantee for progress (aka mempool).
> > 
> > Oliver, Alan, what do you think?  If USB itself can't operate without
> > allocating memory during transactions, whatever USB storage drivers
> > are doing isn't all that meaningful.  Can we proceed with the
> > workqueue patches?  Also, it could be that the only thing GFP_NOIO and
> > GFP_ATOMIC are doing is increasing the chance of IO failures under
> > memory pressure.  Maybe it'd be a good idea to reconsider the
> > approach?
> 
> I agree that USB's approach to memory allocation won't prevent failures 
> when there is severe pressure.

Or even worse, silent hangs for GFP_NOIO requests. If the allocation
size that is issued from that context is not large (basically < order-4)
then the allocation would be retried basically for ever without invoking
the OOM killer. Now, this is rather unlikely to become a real problem
unless there is a serious flood of these GFP_NOIO allocation requests.
But the main point remains. GFP_NOIO doesn't guanratee a forward
progress. Success of such an allocation depends on on a different
context with the full reclaim capabilities (including the OOM killer).

-- 
Michal Hocko
SUSE Labs
--
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: pwc over musb: 100% frame drop (lost) on high resolution stream

[Matwey V. Kornilov]

2016-08-01 20:06 GMT+03:00 Viresh Kumar :
> On 01-08-16, 20:01, Matwey V. Kornilov wrote:
>> With this patch, there is no cpufreq directory here.
>>
>> Without this patch, the output is the following:
>>
>> nohostname:~ # uname -a
>> Linux nohostname 4.6.4-3.gecd9058-default #1 SMP PREEMPT Fri Jul 15
>> 08:08:50 UTC 2016 (ecd9058) armv7l armv7l armv7l GNU/Linux
>> nohostname:~ # cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_driver
>> cpufreq-dt
>
> I hope that the below patch fixes it for you?
>

Yes, it is. Thank you.

> [PATCH] cpufreq: am33xx: Use generic platdev driver
>
> --
> viresh
>



-- 
With best regards,
Matwey V. Kornilov.
Sternberg Astronomical Institute, Lomonosov Moscow State University, Russia
119991, Moscow, Universitetsky pr-k 13, +7 (495) 9392382
--
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 01/10] usb: ulpi: move setting of ulpi->dev parent up in ulpi_register()

[Tal Shorer]

Once ulpi operations use the parent device directly, this will be
needed during the operations used in ulpi_register() itself, so set
the parent field before calling any ulpi operations.

Signed-off-by: Tal Shorer 
---
 drivers/usb/common/ulpi.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/usb/common/ulpi.c b/drivers/usb/common/ulpi.c
index 01c0c04..d1f419c 100644
--- a/drivers/usb/common/ulpi.c
+++ b/drivers/usb/common/ulpi.c
@@ -156,6 +156,8 @@ static int ulpi_register(struct device *dev, struct ulpi 
*ulpi)
 {
int ret;
 
+   ulpi->dev.parent = dev; /* needed early for ops */
+
/* Test the interface */
ret = ulpi_write(ulpi, ULPI_SCRATCH, 0xaa);
if (ret < 0)
@@ -174,7 +176,6 @@ static int ulpi_register(struct device *dev, struct ulpi 
*ulpi)
ulpi->id.product = ulpi_read(ulpi, ULPI_PRODUCT_ID_LOW);
ulpi->id.product |= ulpi_read(ulpi, ULPI_PRODUCT_ID_HIGH) << 8;
 
-   ulpi->dev.parent = dev;
ulpi->dev.bus = _bus;
ulpi->dev.type = _dev_type;
dev_set_name(>dev, "%s.ulpi", dev_name(dev));
-- 
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 v2 06/10] usb: ulpi: remove old api callbacks from struct ulpi_ops

[Tal Shorer]

The old api callbacks, read() and write(), are not referenced anywhere.
Remove them.

Signed-off-by: Tal Shorer 
---
 include/linux/ulpi/interface.h | 2 --
 1 file changed, 2 deletions(-)

diff --git a/include/linux/ulpi/interface.h b/include/linux/ulpi/interface.h
index d8189d0..71f3c99 100644
--- a/include/linux/ulpi/interface.h
+++ b/include/linux/ulpi/interface.h
@@ -13,8 +13,6 @@ struct ulpi;
  */
 struct ulpi_ops {
struct device *dev;
-   int (*read)(struct ulpi_ops *ops, u8 addr);
-   int (*write)(struct ulpi_ops *ops, u8 addr, u8 val);
int (*read_dev)(struct device *dev, u8 addr);
int (*write_dev)(struct device *dev, u8 addr, u8 val);
 };
-- 
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 v2 04/10] usb: dwc3: ulpi: use new api

[Tal Shorer]

The old read, write callbacks in struct ulpi_ops have been deprecated
in favor of new callbacks that pass the parent device directly.
Replace the used callbacks in dwc3's ulpi component with the new api.

Signed-off-by: Tal Shorer 
---
 drivers/usb/dwc3/ulpi.c | 12 ++--
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/drivers/usb/dwc3/ulpi.c b/drivers/usb/dwc3/ulpi.c
index ec004c6..94eeb7a 100644
--- a/drivers/usb/dwc3/ulpi.c
+++ b/drivers/usb/dwc3/ulpi.c
@@ -35,9 +35,9 @@ static int dwc3_ulpi_busyloop(struct dwc3 *dwc)
return -ETIMEDOUT;
 }
 
-static int dwc3_ulpi_read(struct ulpi_ops *ops, u8 addr)
+static int dwc3_ulpi_read(struct device *dev, u8 addr)
 {
-   struct dwc3 *dwc = dev_get_drvdata(ops->dev);
+   struct dwc3 *dwc = dev_get_drvdata(dev);
u32 reg;
int ret;
 
@@ -53,9 +53,9 @@ static int dwc3_ulpi_read(struct ulpi_ops *ops, u8 addr)
return DWC3_GUSB2PHYACC_DATA(reg);
 }
 
-static int dwc3_ulpi_write(struct ulpi_ops *ops, u8 addr, u8 val)
+static int dwc3_ulpi_write(struct device *dev, u8 addr, u8 val)
 {
-   struct dwc3 *dwc = dev_get_drvdata(ops->dev);
+   struct dwc3 *dwc = dev_get_drvdata(dev);
u32 reg;
 
reg = DWC3_GUSB2PHYACC_NEWREGREQ | DWC3_ULPI_ADDR(addr);
@@ -66,8 +66,8 @@ static int dwc3_ulpi_write(struct ulpi_ops *ops, u8 addr, u8 
val)
 }
 
 static struct ulpi_ops dwc3_ulpi_ops = {
-   .read = dwc3_ulpi_read,
-   .write = dwc3_ulpi_write,
+   .read_dev = dwc3_ulpi_read,
+   .write_dev = dwc3_ulpi_write,
 };
 
 int dwc3_ulpi_init(struct dwc3 *dwc)
-- 
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 v2 03/10] usb: ulpi: use new api functions if available

[Tal Shorer]

If the registered has the new api callbacks {read|write}_dev, call
these instead of the deprecated read, write functions. If the
registered does not support the new callbacks, revert to calling the
old ones as before.

Signed-off-by: Tal Shorer 
---
 drivers/usb/common/ulpi.c | 8 ++--
 1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/drivers/usb/common/ulpi.c b/drivers/usb/common/ulpi.c
index d1f419c..a877ddb 100644
--- a/drivers/usb/common/ulpi.c
+++ b/drivers/usb/common/ulpi.c
@@ -21,13 +21,17 @@
 
 int ulpi_read(struct ulpi *ulpi, u8 addr)
 {
-   return ulpi->ops->read(ulpi->ops, addr);
+   if (!ulpi->ops->read_dev)
+   return ulpi->ops->read(ulpi->ops, addr);
+   return ulpi->ops->read_dev(ulpi->dev.parent, addr);
 }
 EXPORT_SYMBOL_GPL(ulpi_read);
 
 int ulpi_write(struct ulpi *ulpi, u8 addr, u8 val)
 {
-   return ulpi->ops->write(ulpi->ops, addr, val);
+   if (!ulpi->ops->write_dev)
+   return ulpi->ops->write(ulpi->ops, addr, val);
+   return ulpi->ops->write_dev(ulpi->dev.parent, addr, val);
 }
 EXPORT_SYMBOL_GPL(ulpi_write);
 
-- 
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 v2 02/10] usb: ulpi: add new api functions, {read|write}_dev()

[Tal Shorer]

Add these two new api callbacks to struct ulpi_ops. These are different
than read, write in that they pass the parent device directly instead
of via the ops argument.
They are intended to replace the old api functions.

Signed-off-by: Tal Shorer 
---
 include/linux/ulpi/interface.h | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/include/linux/ulpi/interface.h b/include/linux/ulpi/interface.h
index 4de8ab4..d8189d0 100644
--- a/include/linux/ulpi/interface.h
+++ b/include/linux/ulpi/interface.h
@@ -15,6 +15,8 @@ struct ulpi_ops {
struct device *dev;
int (*read)(struct ulpi_ops *ops, u8 addr);
int (*write)(struct ulpi_ops *ops, u8 addr, u8 val);
+   int (*read_dev)(struct device *dev, u8 addr);
+   int (*write_dev)(struct device *dev, u8 addr, u8 val);
 };
 
 struct ulpi *ulpi_register_interface(struct device *, struct ulpi_ops *);
-- 
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 v2 00/10] usb: ulpi: remove "dev" field from struct ulpi_ops

[Tal Shorer]

struct ulpi_ops is defined as follows:

struct ulpi_ops {
struct device *dev;
int (*read)(struct ulpi_ops *ops, u8 addr);
int (*write)(struct ulpi_ops *ops, u8 addr, u8 val);
};

Upon calling ulpi_register_interface(), the struct device argument is
put inside the struct ulpi_ops argument's dev field. Later, when
calling the actual read()/write() operations, the struct ulpi_ops is
passed to them and they use the stored device to access whatever
private data they need.

This means that if one wishes to reuse the same oprations for multiple
interfaces (e.g if we have multiple instances of the same controller),
any but the last interface registered will not operate properly (and
the one that does work will be at the mercy of the others to not mess
it up).

I understand that barely any driver uses this bus right now, but I
suppose it's there to be used at some point. We might as well fix the
design here before we hit this bug.

This series fixes this by passing the given struct device directly to
the operation functions via ulpi->dev.parent in ulpi_read() and
ulpi_write(). It also changes the operations struct to be constant
since now nobody has a reason to modify it.

Changes from v1:
 * Split the actual api change into multiple patch as per Felipe Balbi's
   suggestion. The series now first adds the new api, then migrates
   everything to use and only then removes the old api.

Tal Shorer (10):
  usb: ulpi: move setting of ulpi->dev parent up in ulpi_register()
  usb: ulpi: add new api functions, {read|write}_dev()
  usb: ulpi: use new api functions if available
  usb: dwc3: ulpi: use new api
  usb: ulpi: remove calls to old api callbacks
  usb: ulpi: remove old api callbacks from struct ulpi_ops
  usb: ulpi: rename operations {read|write}_dev to simply {read|write}
  usb: ulpi: remove "dev" field from struct ulpi_ops
  usb: ulpi: make ops struct constant
  usb: dwc3: ulpi: make dwc3_ulpi_ops constant

 drivers/usb/common/ulpi.c  | 11 ++-
 drivers/usb/dwc3/ulpi.c| 10 +-
 include/linux/ulpi/driver.h|  2 +-
 include/linux/ulpi/interface.h |  8 
 4 files changed, 16 insertions(+), 15 deletions(-)

-- 
2.7.4

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

Re: pwc over musb: 100% frame drop (lost) on high resolution stream

[Matwey V. Kornilov]

pwc module output with trace=511 is the following:

[   24.793109] usbcore: registered new interface driver Philips webcam
[   29.276979] pwc: Unsupported pixel format
[   29.277055] pwc: pwc_vidioc_fill_fmt() width=640, height=480,
bytesperline=640, sizeimage=460800, pixelformat=YU12
[   29.277090] pwc: Trying to set format to: width=640 height=480
fps=15 format=YU12
[   29.277123] pwc: set_video_mode(640x480 @ 30, pixfmt 32315559).
[   29.277145] pwc: decode_size = 5.
[   29.277180] pwc: frame_size=63120, vframes=15, vsize=5, vbandlength=526
[   29.277204] pwc: Set resolution to 640x480
[   29.277225] pwc: pwc_set_video_mode(), return=0
[   29.277256] pwc: pwc_vidioc_fill_fmt() width=640, height=480,
bytesperline=640, sizeimage=460800, pixelformat=YU12
[   29.277306] pwc: ioctl(VIDIOC_G_FMT) return size 640x480
[   29.277337] pwc: pwc_vidioc_fill_fmt() width=640, height=480,
bytesperline=640, sizeimage=460800, pixelformat=YU12
[   29.277449] pwc: set_video_mode(640x480 @ 10, pixfmt 32315559).
[   29.277475] pwc: decode_size = 5.
[   29.278726] pwc: frame_size=94560, vframes=10, vsize=5, vbandlength=788
[   29.278750] pwc: Set resolution to 640x480
[   29.300374] pwc: set_video_mode(640x480 @ 10, pixfmt 32315559).
[   29.300420] pwc: decode_size = 5.
[   29.441759] pwc: frame_size=94560, vframes=10, vsize=5, vbandlength=788
[   29.441792] pwc: Set resolution to 640x480
[   29.441824] pwc: Setting alternate interface 9
[   29.455061] pwc: Allocated URB at 0xc9b83600
[   29.455850] pwc: Allocated URB at 0xc9b83400
[   29.456040] pwc: Allocated URB at 0xc9b83200
[   29.456271] pwc: URB 0xc9b83600 submitted.
[   29.456310] pwc: URB 0xc9b83400 submitted.
[   29.456341] pwc: URB 0xc9b83200 submitted.
[   29.456362] pwc: << pwc_isoc_init()
[   30.078550] pwc: Frame buffer underflow (20076 bytes); discarded.
[   30.170543] pwc: Frame buffer underflow (12428 bytes); discarded.
[   30.272538] pwc: Frame buffer underflow (14340 bytes); discarded.
[   30.374541] pwc: Frame buffer underflow (16252 bytes); discarded.
[   30.476535] pwc: Frame buffer underflow (18164 bytes); discarded.
[   30.578532] pwc: Frame buffer underflow (20076 bytes); discarded.
[   30.670538] pwc: Frame buffer underflow (12428 bytes); discarded.
[   30.772544] pwc: Frame buffer underflow (14340 bytes); discarded.
[   30.874547] pwc: Frame buffer underflow (16252 bytes); discarded.
[   30.976552] pwc: Frame buffer underflow (18164 bytes); discarded.
[   31.078536] pwc: Frame buffer underflow (20076 bytes); discarded.
[   31.170533] pwc: Frame buffer underflow (12428 bytes); discarded.
[   31.272549] pwc: Frame buffer underflow (14340 bytes); discarded.
[   31.374545] pwc: Frame buffer underflow (16252 bytes); discarded.
[   31.476537] pwc: Frame buffer underflow (18164 bytes); discarded.
[   31.578536] pwc: Frame buffer underflow (20076 bytes); discarded.
[   31.660895] pwc: Frame buffer underflow (11472 bytes); discarded.
[   31.772554] pwc: Frame buffer underflow (14340 bytes); discarded.
[   31.874548] pwc: Frame buffer underflow (16252 bytes); discarded.
[   31.976533] pwc: Frame buffer underflow (18164 bytes); discarded.


2016-07-31 23:31 GMT+03:00 Matwey V. Kornilov :
> Hello,
>
> I've also just found that the same commit breaks cpufreq on BeagleBone Black 
> :)
>
> So, probably without HCD_BH flag musb works correctly only at 1Ghz CPU
> frequency, which is unlisted and being set to 720Mhz by cpufreq driver
> (as it did whet there was cpufreq driver).
>
> 2016-07-29 21:01 GMT+03:00 Matwey V. Kornilov :
>> Hello,
>>
>> I've found that the following commit fixes the issue:
>>
>> commit 7694ca6e1d6f01122f05039b81f70f64b1ec4063
>> Author: Viresh Kumar 
>> Date:   Fri Apr 22 16:58:42 2016 +0530
>>
>> cpufreq: omap: Use generic platdev driver
>>
>> The cpufreq-dt-platdev driver supports creation of cpufreq-dt platform
>> device now, reuse that and remove similar code from platform code.
>>
>>
>> 2016-07-28 19:16 GMT+03:00 Matwey V. Kornilov :
>>> Hello,
>>>
>>> I've just bisected commit, which fixed the issue in v4.7
>>>
>>> commit 9fa64d6424adabf0e3a546ae24d01a62a927b342
>>> Merge: f55532a febce40
>>> Author: Rafael J. Wysocki 
>>> Date:   Sat Apr 2 01:07:17 2016 +0200
>>>
>>> Merge back intel_pstate fixes for v4.6.
>>>
>>> * pm-cpufreq:
>>>   intel_pstate: Avoid extra invocation of intel_pstate_sample()
>>>   intel_pstate: Do not set utilization update hook too early
>>>
>>> Unfortunately, intel_pstate branch doesn't have
>>> f551e13529833e052f75ec628a8af7b034af20f9 applied.
>>> I'll try to bisect this branch with the patch manually applied.
>>>
>>> 2016-07-27 20:34 GMT+03:00 Matwey V. Kornilov :
 Hello,

 I've just biseced commit, which introduced this issue

 commit f551e13529833e052f75ec628a8af7b034af20f9
 Author: Bin Liu 
 Date:   Mon Apr 25 

[PATCH v2 09/10] usb: ulpi: make ops struct constant

[Tal Shorer]

None of the core ulpi functions perform any changes to the operations
struct, and logically as a struct that contains function pointers
there's no reason it shouldn't be constant.

Signed-off-by: Tal Shorer 
---
 drivers/usb/common/ulpi.c  | 3 ++-
 include/linux/ulpi/driver.h| 2 +-
 include/linux/ulpi/interface.h | 2 +-
 3 files changed, 4 insertions(+), 3 deletions(-)

diff --git a/drivers/usb/common/ulpi.c b/drivers/usb/common/ulpi.c
index 0439e96..d4ff6df 100644
--- a/drivers/usb/common/ulpi.c
+++ b/drivers/usb/common/ulpi.c
@@ -202,7 +202,8 @@ static int ulpi_register(struct device *dev, struct ulpi 
*ulpi)
  * Allocates and registers a ULPI device and an interface for it. Called from
  * the USB controller that provides the ULPI interface.
  */
-struct ulpi *ulpi_register_interface(struct device *dev, struct ulpi_ops *ops)
+struct ulpi *ulpi_register_interface(struct device *dev,
+const struct ulpi_ops *ops)
 {
struct ulpi *ulpi;
int ret;
diff --git a/include/linux/ulpi/driver.h b/include/linux/ulpi/driver.h
index 388f6e0..a44408f 100644
--- a/include/linux/ulpi/driver.h
+++ b/include/linux/ulpi/driver.h
@@ -15,7 +15,7 @@ struct ulpi_ops;
  */
 struct ulpi {
struct ulpi_device_id id;
-   struct ulpi_ops *ops;
+   const struct ulpi_ops *ops;
struct device dev;
 };
 
diff --git a/include/linux/ulpi/interface.h b/include/linux/ulpi/interface.h
index ee6e35a..43b0738 100644
--- a/include/linux/ulpi/interface.h
+++ b/include/linux/ulpi/interface.h
@@ -17,7 +17,7 @@ struct ulpi_ops {
int (*write)(struct device *dev, u8 addr, u8 val);
 };
 
-struct ulpi *ulpi_register_interface(struct device *, struct ulpi_ops *);
+struct ulpi *ulpi_register_interface(struct device *, const struct ulpi_ops *);
 void ulpi_unregister_interface(struct ulpi *);
 
 #endif /* __LINUX_ULPI_INTERFACE_H */
-- 
2.7.4

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

[PATCH v2 07/10] usb: ulpi: rename operations {read|write}_dev to simply {read|write}

[Tal Shorer]

With the removal of the old {read|write} operations, we can now safely
rename the new api operations {read|write}_dev to use the shorter and
clearer names {read|write}, respectively.

Signed-off-by: Tal Shorer 
---
 drivers/usb/common/ulpi.c  | 4 ++--
 drivers/usb/dwc3/ulpi.c| 4 ++--
 include/linux/ulpi/interface.h | 4 ++--
 3 files changed, 6 insertions(+), 6 deletions(-)

diff --git a/drivers/usb/common/ulpi.c b/drivers/usb/common/ulpi.c
index 43142c3..fdaed7c 100644
--- a/drivers/usb/common/ulpi.c
+++ b/drivers/usb/common/ulpi.c
@@ -21,13 +21,13 @@
 
 int ulpi_read(struct ulpi *ulpi, u8 addr)
 {
-   return ulpi->ops->read_dev(ulpi->dev.parent, addr);
+   return ulpi->ops->read(ulpi->dev.parent, addr);
 }
 EXPORT_SYMBOL_GPL(ulpi_read);
 
 int ulpi_write(struct ulpi *ulpi, u8 addr, u8 val)
 {
-   return ulpi->ops->write_dev(ulpi->dev.parent, addr, val);
+   return ulpi->ops->write(ulpi->dev.parent, addr, val);
 }
 EXPORT_SYMBOL_GPL(ulpi_write);
 
diff --git a/drivers/usb/dwc3/ulpi.c b/drivers/usb/dwc3/ulpi.c
index 94eeb7a..51ac939 100644
--- a/drivers/usb/dwc3/ulpi.c
+++ b/drivers/usb/dwc3/ulpi.c
@@ -66,8 +66,8 @@ static int dwc3_ulpi_write(struct device *dev, u8 addr, u8 
val)
 }
 
 static struct ulpi_ops dwc3_ulpi_ops = {
-   .read_dev = dwc3_ulpi_read,
-   .write_dev = dwc3_ulpi_write,
+   .read = dwc3_ulpi_read,
+   .write = dwc3_ulpi_write,
 };
 
 int dwc3_ulpi_init(struct dwc3 *dwc)
diff --git a/include/linux/ulpi/interface.h b/include/linux/ulpi/interface.h
index 71f3c99..ac3cd80 100644
--- a/include/linux/ulpi/interface.h
+++ b/include/linux/ulpi/interface.h
@@ -13,8 +13,8 @@ struct ulpi;
  */
 struct ulpi_ops {
struct device *dev;
-   int (*read_dev)(struct device *dev, u8 addr);
-   int (*write_dev)(struct device *dev, u8 addr, u8 val);
+   int (*read)(struct device *dev, u8 addr);
+   int (*write)(struct device *dev, u8 addr, u8 val);
 };
 
 struct ulpi *ulpi_register_interface(struct device *, struct ulpi_ops *);
-- 
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 v2 05/10] usb: ulpi: remove calls to old api callbacks

[Tal Shorer]

Now that all users use the new api callbacks, remove the calls to the
old api functions and force new interface drivers to use the new api.

Signed-off-by: Tal Shorer 
---
 drivers/usb/common/ulpi.c | 4 
 1 file changed, 4 deletions(-)

diff --git a/drivers/usb/common/ulpi.c b/drivers/usb/common/ulpi.c
index a877ddb..43142c3 100644
--- a/drivers/usb/common/ulpi.c
+++ b/drivers/usb/common/ulpi.c
@@ -21,16 +21,12 @@
 
 int ulpi_read(struct ulpi *ulpi, u8 addr)
 {
-   if (!ulpi->ops->read_dev)
-   return ulpi->ops->read(ulpi->ops, addr);
return ulpi->ops->read_dev(ulpi->dev.parent, addr);
 }
 EXPORT_SYMBOL_GPL(ulpi_read);
 
 int ulpi_write(struct ulpi *ulpi, u8 addr, u8 val)
 {
-   if (!ulpi->ops->write_dev)
-   return ulpi->ops->write(ulpi->ops, addr, val);
return ulpi->ops->write_dev(ulpi->dev.parent, addr, val);
 }
 EXPORT_SYMBOL_GPL(ulpi_write);
-- 
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 v2 08/10] usb: ulpi: remove "dev" field from struct ulpi_ops

[Tal Shorer]

Operations now use ulpi->dev.parent directly instead of via the
ulpi_ops struct, making this field unused. Remove it.

Signed-off-by: Tal Shorer 
---
 drivers/usb/common/ulpi.c  | 1 -
 include/linux/ulpi/interface.h | 2 +-
 2 files changed, 1 insertion(+), 2 deletions(-)

diff --git a/drivers/usb/common/ulpi.c b/drivers/usb/common/ulpi.c
index fdaed7c..0439e96 100644
--- a/drivers/usb/common/ulpi.c
+++ b/drivers/usb/common/ulpi.c
@@ -212,7 +212,6 @@ struct ulpi *ulpi_register_interface(struct device *dev, 
struct ulpi_ops *ops)
return ERR_PTR(-ENOMEM);
 
ulpi->ops = ops;
-   ops->dev = dev;
 
ret = ulpi_register(dev, ulpi);
if (ret) {
diff --git a/include/linux/ulpi/interface.h b/include/linux/ulpi/interface.h
index ac3cd80..ee6e35a 100644
--- a/include/linux/ulpi/interface.h
+++ b/include/linux/ulpi/interface.h
@@ -4,6 +4,7 @@
 #include 
 
 struct ulpi;
+struct device;
 
 /**
  * struct ulpi_ops - ULPI register access
@@ -12,7 +13,6 @@ struct ulpi;
  * @write: write operation for ULPI register access
  */
 struct ulpi_ops {
-   struct device *dev;
int (*read)(struct device *dev, u8 addr);
int (*write)(struct device *dev, u8 addr, u8 val);
 };
-- 
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 v2 10/10] usb: dwc3: ulpi: make dwc3_ulpi_ops constant

[Tal Shorer]

ulpi_register_interface() accepts a const struct ulpi_ops and dwc3
doesn't perform any changes to this struct at runtime, so there's no
reason it shouldn't be constant.

Signed-off-by: Tal Shorer 
---
 drivers/usb/dwc3/ulpi.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/usb/dwc3/ulpi.c b/drivers/usb/dwc3/ulpi.c
index 51ac939..bd86f84 100644
--- a/drivers/usb/dwc3/ulpi.c
+++ b/drivers/usb/dwc3/ulpi.c
@@ -65,7 +65,7 @@ static int dwc3_ulpi_write(struct device *dev, u8 addr, u8 
val)
return dwc3_ulpi_busyloop(dwc);
 }
 
-static struct ulpi_ops dwc3_ulpi_ops = {
+static const struct ulpi_ops dwc3_ulpi_ops = {
.read = dwc3_ulpi_read,
.write = dwc3_ulpi_write,
 };
-- 
2.7.4

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

Re: pwc over musb: 100% frame drop (lost) on high resolution stream

[Viresh Kumar]

On 01-08-16, 20:01, Matwey V. Kornilov wrote:
> With this patch, there is no cpufreq directory here.
> 
> Without this patch, the output is the following:
> 
> nohostname:~ # uname -a
> Linux nohostname 4.6.4-3.gecd9058-default #1 SMP PREEMPT Fri Jul 15
> 08:08:50 UTC 2016 (ecd9058) armv7l armv7l armv7l GNU/Linux
> nohostname:~ # cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_driver
> cpufreq-dt

I hope that the below patch fixes it for you?

[PATCH] cpufreq: am33xx: Use generic platdev driver

-- 
viresh
--
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: validate wMaxPacketValue entries in endpoint descriptors

[roswest]

Alan,

I think it would be more accurate to put Jake Lamberson as the reporter
and tester.

Thanks,
Rosie

On Mon Aug 01 2016 12:18:54 GMT-0400 (EDT), Alan Stern wrote:
> Erroneous or malicious endpoint descriptors may have non-zero bits in
> reserved positions, or out-of-bounds values.  This patch helps prevent
> these from causing problems by bounds-checking the wMaxPacketValue
> entries in endpoint descriptors and capping the values at the maximum
> allowed.
> 
> Signed-off-by: Alan Stern 
> Reported-by: roswest 
> Tested-by: roswest 
> 
> ---
> 
> I don't think this needs to go into the -stable kernels, but if anyone
> disagrees I won't object.
> 
> [as1806]
> 
> 
>  drivers/usb/core/config.c |   66 
> +++---
>  1 file changed, 63 insertions(+), 3 deletions(-)
> 
> Index: usb-4.x/drivers/usb/core/config.c
> ===
> --- usb-4.x.orig/drivers/usb/core/config.c
> +++ usb-4.x/drivers/usb/core/config.c
> @@ -171,6 +171,31 @@ static void usb_parse_ss_endpoint_compan
>   ep, buffer, size);
>  }
>  
> +static const unsigned short low_speed_maxpacket_maxes[4] = {
> + [USB_ENDPOINT_XFER_CONTROL] = 8,
> + [USB_ENDPOINT_XFER_ISOC] = 0,
> + [USB_ENDPOINT_XFER_BULK] = 0,
> + [USB_ENDPOINT_XFER_INT] = 8,
> +};
> +static const unsigned short full_speed_maxpacket_maxes[4] = {
> + [USB_ENDPOINT_XFER_CONTROL] = 64,
> + [USB_ENDPOINT_XFER_ISOC] = 1023,
> + [USB_ENDPOINT_XFER_BULK] = 64,
> + [USB_ENDPOINT_XFER_INT] = 64,
> +};
> +static const unsigned short high_speed_maxpacket_maxes[4] = {
> + [USB_ENDPOINT_XFER_CONTROL] = 64,
> + [USB_ENDPOINT_XFER_ISOC] = 1024,
> + [USB_ENDPOINT_XFER_BULK] = 512,
> + [USB_ENDPOINT_XFER_INT] = 1023,
> +};
> +static const unsigned short super_speed_maxpacket_maxes[4] = {
> + [USB_ENDPOINT_XFER_CONTROL] = 512,
> + [USB_ENDPOINT_XFER_ISOC] = 1024,
> + [USB_ENDPOINT_XFER_BULK] = 1024,
> + [USB_ENDPOINT_XFER_INT] = 1024,
> +};
> +
>  static int usb_parse_endpoint(struct device *ddev, int cfgno, int inum,
>  int asnum, struct usb_host_interface *ifp, int num_ep,
>  unsigned char *buffer, int size)
> @@ -179,6 +204,8 @@ static int usb_parse_endpoint(struct dev
>   struct usb_endpoint_descriptor *d;
>   struct usb_host_endpoint *endpoint;
>   int n, i, j, retval;
> + unsigned int maxp;
> + const unsigned short *maxpacket_maxes;
>  
>   d = (struct usb_endpoint_descriptor *) buffer;
>   buffer += d->bLength;
> @@ -290,6 +317,42 @@ static int usb_parse_endpoint(struct dev
>   endpoint->desc.wMaxPacketSize = cpu_to_le16(8);
>   }
>  
> + /* Validate the wMaxPacketSize field */
> + maxp = usb_endpoint_maxp(>desc);
> +
> + /* Find the highest legal maxpacket size for this endpoint */
> + i = 0;  /* additional transactions per microframe */
> + switch (to_usb_device(ddev)->speed) {
> + case USB_SPEED_LOW:
> + maxpacket_maxes = low_speed_maxpacket_maxes;
> + break;
> + case USB_SPEED_FULL:
> + maxpacket_maxes = full_speed_maxpacket_maxes;
> + break;
> + case USB_SPEED_HIGH:
> + /* Bits 12..11 are allowed only for HS periodic endpoints */
> + if (usb_endpoint_xfer_int(d) || usb_endpoint_xfer_isoc(d)) {
> + i = maxp & (BIT(12) | BIT(11));
> + maxp &= ~i;
> + }
> + /* fallthrough */
> + default:
> + maxpacket_maxes = high_speed_maxpacket_maxes;
> + break;
> + case USB_SPEED_SUPER:
> + case USB_SPEED_SUPER_PLUS:
> + maxpacket_maxes = super_speed_maxpacket_maxes;
> + break;
> + }
> + j = maxpacket_maxes[usb_endpoint_type(>desc)];
> +
> + if (maxp > j) {
> + dev_warn(ddev, "config %d interface %d altsetting %d endpoint 
> 0x%X has invalid maxpacket %d, setting to %d\n",
> + cfgno, inum, asnum, d->bEndpointAddress, maxp, j);
> + maxp = j;
> + endpoint->desc.wMaxPacketSize = cpu_to_le16(i | maxp);
> + }
> +
>   /*
>* Some buggy high speed devices have bulk endpoints using
>* maxpacket sizes other than 512.  High speed HCDs may not
> @@ -297,9 +360,6 @@ static int usb_parse_endpoint(struct dev
>*/
>   if (to_usb_device(ddev)->speed == USB_SPEED_HIGH
>   && usb_endpoint_xfer_bulk(d)) {
> - unsigned maxp;
> -
> - maxp = usb_endpoint_maxp(>desc) & 0x07ff;
>   if (maxp != 512)
>   dev_warn(ddev, "config %d interface %d altsetting %d "
>   "bulk endpoint 0x%X has invalid maxpacket %d\n",
> 



signature.asc
Description: OpenPGP digital signature

Re: pwc over musb: 100% frame drop (lost) on high resolution stream

[Matwey V. Kornilov]

2016-08-01 19:50 GMT+03:00 Viresh Kumar :
> On 31-07-16, 23:31, Matwey V. Kornilov wrote:
>> Hello,
>>
>> I've also just found that the same commit breaks cpufreq on BeagleBone Black 
>> :)
>>
>> So, probably without HCD_BH flag musb works correctly only at 1Ghz CPU
>> frequency, which is unlisted and being set to 720Mhz by cpufreq driver
>> (as it did whet there was cpufreq driver).
>>
>> 2016-07-29 21:01 GMT+03:00 Matwey V. Kornilov :
>> > Hello,
>> >
>> > I've found that the following commit fixes the issue:
>> >
>> > commit 7694ca6e1d6f01122f05039b81f70f64b1ec4063
>> > Author: Viresh Kumar 
>> > Date:   Fri Apr 22 16:58:42 2016 +0530
>> >
>> > cpufreq: omap: Use generic platdev driver
>> >
>> > The cpufreq-dt-platdev driver supports creation of cpufreq-dt platform
>> > device now, reuse that and remove similar code from platform code.
>
> Sorry for this commit and the man hours wasted to get to this :(
>
> I am trying to figure out why things break though, as this patch shouldn't 
> have
> had any functional impacts. So, some of the assumptions I had are surely
> incorrect..

Actually, nothing to sorry about.
I suppose, that with this patch my BeagleBone run at 1Ghz after boot,
because usually cpufreq limits it to 720Mhz saying
[   14.255646] cpu cpu0: dev_pm_opp_set_rate: failed to find current
OPP for freq 10 (-34)
And actually musb is still broken after f551e13529833e052f75ec628a8af7
(" Revert "usb: musb: musb_host")

>
> The defconfig linked in the original thread [1] has this:
>
> CONFIG_CPUFREQ_DT=m
>
> So, the cpufreq-dt module needs to get inserted to make it work.
>

It has been inserted automatically by alias `platform:cpufreq-dt'
Issue here that 4.7 stopped to provide `platfrom:cpufreq-dt' on BeagleBone.
Have you received my patch fixing it yet?

> Can someone provide the output of:
>
> cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_driver
>
> with and without this patch ?

With this patch, there is no cpufreq directory here.

Without this patch, the output is the following:

nohostname:~ # uname -a
Linux nohostname 4.6.4-3.gecd9058-default #1 SMP PREEMPT Fri Jul 15
08:08:50 UTC 2016 (ecd9058) armv7l armv7l armv7l GNU/Linux
nohostname:~ # cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_driver
cpufreq-dt

>
> It looks like we wanted to select "omap-cpufreq" for beaglebone and selected
> "cpufreq-dt" by mistake.

No, I am not sure, cpufreq-dt worked well until v4.7 where it is disappeared.

>
> [Note]: I am not subscribed to USB lists and so please include me for any 
> emails
> you want my response on.
>
> --
> viresh
>
> [1] http://www.spinics.net/lists/linux-usb/msg143956.html
>
> --
> viresh
>



-- 
With best regards,
Matwey V. Kornilov.
Sternberg Astronomical Institute, Lomonosov Moscow State University, Russia
119991, Moscow, Universitetsky pr-k 13, +7 (495) 9392382
--
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: NEC uPD720200 xHCI Controller dies when Runtime PM enabled

[Durval Menezes]

Hi Mike,

On Mon, Aug 1, 2016 at 12:05 PM, Mike Murdoch  wrote:
> On 2016-08-01 13:57, Durval Menezes wrote:
> > Hi Mathias,
> >
> > On Mon, Aug 1, 2016 at 8:20 AM, Mathias Nyman 
> >  wrote:
> >>> On 01.08.2016 13:15, Durval Menezes wrote:
> >>> Hello Mike, Mathias, list,
> >>>
> >>> On 06.02.2016 19:08, Mike Murdoch wrote:
> >>> Bug ID: 111251
> >>>
> >>> I have a NEC uPD720200 USB3.0 controller in a Thinkpad W520 laptop on
> >>> kernel 4.4.1-gentoo.
> >>>
> >>> 0e:00.0 USB controller: NEC Corporation uPD720200 USB 3.0 Host
> >>> Controller (rev 04) (prog-if 30 [XHCI])
> >>>  Subsystem: Lenovo uPD720200 USB 3.0 Host Controller
> >>>  Flags: bus master, fast devsel, latency 0
> >>>  Memory at f380 (64-bit, non-prefetchable) [size=8K]
> >>>  Capabilities: [50] Power Management version 3
> >>>  Capabilities: [70] MSI: Enable- Count=1/8 Maskable- 64bit+
> >>>  Capabilities: [90] MSI-X: Enable+ Count=8 Masked-
> >>>  Capabilities: [a0] Express Endpoint, MSI 00
> >>>  Capabilities: [100] Advanced Error Reporting
> >>>  Capabilities: [140] Device Serial Number ff-ff-ff-ff-ff-ff-ff-ff
> >>>  Capabilities: [150] Latency Tolerance Reporting
> >>>  Kernel driver in use: xhci_hcd
> >>>  Kernel modules: xhci_pci
> >>>
> >>> When runtime power control for this controller is disabled
> >>> (/sys/bus/pci/devices/:0e:00.0/power/control = on), the controller
> >>> works fine and reaches over 120MB/s transfer rates.
> >>>
> >>> When runtime power control for this controller is enabled
> >>> (/sys/bus/pci/devices/:0e:00.0/power/control = auto), two effects
> >>> can be observed:
> >>>
> >>> - Transfer rates are much lower at around 30MB/s
> >>> - During transfers, the controller dies after a couple of seconds:
> >>>
> >>> I found this message in the list archives, and I have the exact same
> >>> issues on exactly the same hardware (Thinkpad W520 laptop with the same
> >>> USB3 controller showing on lspci -v); otherwise, I'm running distro kernel
> >>> 2.6.32-573.7.1.el6.x86_64 on a Springdale Linux 6.7 (RHEL6) install.
> >>>
> >>> I just verified that my controller's PM was set by default to "auto":
> >>> cat /sys/bus/pci/devices/\:0e\:00.0/power/control
> >>> auto
> >>> I have now set it to "on" and will test whether this will work around
> >>> the issue (I'm waiting for my USB3.0 "heavy duty" disk docks to be
> >>> released from another system that is using them right now).
> >>>
> >>> I have one question for Mike: have you upgraded your uPD720200 controller
> >>> firmware (as per [1], [2]) or are you still running stock?
> >>>
> >>> Also, one question for Mathias: do you know whether your patches at [3]
> >>> can be applied to kernel 2.6.32?
> >> The last patch in [3] is faulty. So don't use the patches from the mail.
> >>
> >> I just force updated that branch, so if you like you can try to backport
> >> patches from:
> >>
> >>  git://git.kernel.org/pub/scm/linux/kernel/git/mnyman/xhci.git 
> >> bug_usb3_enum_rtresume
> >>
> >> only 2 patches are relevant:
> >>
> >> 8caabe9 xhci: Don't suspend the xhci bus it there is a pending event.
> >> 4427456 xhci: resume USB 3 roothub first
> > Thanks Mathias. Now I only need Mike's response concerning the firmware
> > in order to proceed.
> > 
> No, I haven't tried updating the firmware. Feel free to give it a go,
> I'm curious if it'll make a difference.

As long as the patch (or the workaround) allow me to avoid the issue,
I'd rather let sleeping dragons lie (windows-only update procedure, etc)

:-)

> As for the patches. All three of them did fix this bug, but introduced
> other problems (I don't remember details, sorry). As Mathias said, the
> last one is faulty. However, using only the first two patches is *not*
> enough to completely fix this bug (I verified it just now).

No prob, Mathias sent me a reference to the relevant (and presumably 
working) patches, I will first try the "disable PM mode" workaround and
later (possibly *much* later) to backport the patches to my kernel.

> Unfortunately I don't have the time to do much testing. The Thinkpad is
> used by someone else and I only have access to it on the weekends. A
> workaround is to just disable runtime power management.

Thanks for the feedback.

> Let me know how things work for you!

Will do: will post a progress report (on the workaround) later today to the
list and, as you asked, directly to your email too.

Thanks again,
-- 
  Durval Menezes (durval AT tmp DOT com DOT br, http://www.tmp.com.br/)

--
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] power: add power sequence library

[Fabio Estevam]

On Mon, Aug 1, 2016 at 11:55 AM, Joshua Clayton
 wrote:

> Thanks a million, Fabio!
>
> 'usbcore.autosuspend=-1' quiets the errors.
>
> ~joshua
>
> P.S. I guess this technically is a bug in chipidea usb.
> I'll give it a quick once over, though I am not very familiar
> with USB core or the CI driver.

Yes, it would be really nice if we can get a proper fix for this bug.
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] usb: ehci: change order of register cleanup during shutdown

[Alan Stern]

On Mon, 1 Aug 2016, Marc Ohlf wrote:

> In ehci_turn_off_all_ports() all EHCI port register bits
> (except the PORT_RWC_BITS) are set to zero.

Even the PORT_WRC_BITS are set to 0.  Oddly enough, the way to set 
those bits to 0 is to write a 1 to them (see Table 2-16 in the EHCI 
spec).

> On some hardware, this can lead to an system hang,
> when ehci_port_power() accesses the already cleaned registers.
> 
> This patch changes the order of cleanup.
> First call ehci_port_power() which respects the current bits in
> port status registers
> and afterwards cleanup the hard way by setting everything else to zero.
> 
> Signed-off-by: Marc Ohlf 
> ---
>  drivers/usb/host/ehci-hcd.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/usb/host/ehci-hcd.c b/drivers/usb/host/ehci-hcd.c
> index a962b89..1e5f529 100644
> --- a/drivers/usb/host/ehci-hcd.c
> +++ b/drivers/usb/host/ehci-hcd.c
> @@ -332,11 +332,11 @@ static void ehci_turn_off_all_ports(struct ehci_hcd 
> *ehci)
>   int port = HCS_N_PORTS(ehci->hcs_params);
>  
>   while (port--) {
> - ehci_writel(ehci, PORT_RWC_BITS,
> - >regs->port_status[port]);
>   spin_unlock_irq(>lock);
>   ehci_port_power(ehci, port, false);
>   spin_lock_irq(>lock);
> + ehci_writel(ehci, PORT_RWC_BITS,
> + >regs->port_status[port]);
>   }
>  }

Acked-by: Alan Stern 

This should be marked for the -stable kernels as well.

Alan Stern

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

Re: [PATCH] xhci: Fix soft lockup in xhci_pci_probe path when XHCI_STATE_HALTED

[Gabriel Krisman Bertazi]

Kamal Mostafa  writes:

> Commit 27a41a83ec54 ("xhci: Cleanup only when releasing primary hcd")
> causes a soft lockup at boot when XHCI_STATE_HALTED, preventing
> VirtualBox 5.1.x from booting if USB3.0 is enabled.
>
> Revert to allowing xhci_irq to handle the interrupt when
> XHCI_STATE_HALTED but not XHCI_STATE_DYING.
>
> Fixes: 27a41a83ec54 ("xhci: Cleanup only when releasing primary hcd")
> BugLink: https://bugs.launchpad.net/bugs/1604058
> Signed-off-by: Kamal Mostafa 
> Cc:  #v4.3+
> Cc: Gabriel Krisman Bertazi 
> Acked-by: Tim Gardner 
> Acked-by: Stefan Bader 
> ---
>  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 918e0c7..1d36a5f 100644
> --- a/drivers/usb/host/xhci-ring.c
> +++ b/drivers/usb/host/xhci-ring.c
> @@ -2751,8 +2751,7 @@ hw_died:
>   writel(irq_pending, >ir_set->irq_pending);
>   }
>
> - if (xhci->xhc_state & XHCI_STATE_DYING ||
> - xhci->xhc_state & XHCI_STATE_HALTED) {
> + if (xhci->xhc_state & XHCI_STATE_DYING) {
>   xhci_dbg(xhci, "xHCI dying, ignoring interrupt. "
>   "Shouldn't IRQs be disabled?\n");
>   /* Clear the event handler busy flag (RW1C);
> @@ -2764,6 +2763,8 @@ hw_died:
>   spin_unlock(>lock);
>
>   return IRQ_HANDLED;
> + } else if (xhci->xhc_state & XHCI_STATE_HALTED) {
> + xhci_dbg(xhci, "xHCI halted, handling interrupt.\n");
>   }

Returning early when XHCI_STATE_HALTED is no longer necessary since my
commit ensures we only free the HCD after disabling the primary HCD.

I think we can drop the 'else if' leg all together and only test for
XHCI_STATE_DYING here.

-- 
Gabriel Krisman Bertazi

--
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: validate wMaxPacketValue entries in endpoint descriptors

[Alan Stern]

Erroneous or malicious endpoint descriptors may have non-zero bits in
reserved positions, or out-of-bounds values.  This patch helps prevent
these from causing problems by bounds-checking the wMaxPacketValue
entries in endpoint descriptors and capping the values at the maximum
allowed.

Signed-off-by: Alan Stern 
Reported-by: roswest 
Tested-by: roswest 

---

I don't think this needs to go into the -stable kernels, but if anyone
disagrees I won't object.

[as1806]


 drivers/usb/core/config.c |   66 +++---
 1 file changed, 63 insertions(+), 3 deletions(-)

Index: usb-4.x/drivers/usb/core/config.c
===
--- usb-4.x.orig/drivers/usb/core/config.c
+++ usb-4.x/drivers/usb/core/config.c
@@ -171,6 +171,31 @@ static void usb_parse_ss_endpoint_compan
ep, buffer, size);
 }
 
+static const unsigned short low_speed_maxpacket_maxes[4] = {
+   [USB_ENDPOINT_XFER_CONTROL] = 8,
+   [USB_ENDPOINT_XFER_ISOC] = 0,
+   [USB_ENDPOINT_XFER_BULK] = 0,
+   [USB_ENDPOINT_XFER_INT] = 8,
+};
+static const unsigned short full_speed_maxpacket_maxes[4] = {
+   [USB_ENDPOINT_XFER_CONTROL] = 64,
+   [USB_ENDPOINT_XFER_ISOC] = 1023,
+   [USB_ENDPOINT_XFER_BULK] = 64,
+   [USB_ENDPOINT_XFER_INT] = 64,
+};
+static const unsigned short high_speed_maxpacket_maxes[4] = {
+   [USB_ENDPOINT_XFER_CONTROL] = 64,
+   [USB_ENDPOINT_XFER_ISOC] = 1024,
+   [USB_ENDPOINT_XFER_BULK] = 512,
+   [USB_ENDPOINT_XFER_INT] = 1023,
+};
+static const unsigned short super_speed_maxpacket_maxes[4] = {
+   [USB_ENDPOINT_XFER_CONTROL] = 512,
+   [USB_ENDPOINT_XFER_ISOC] = 1024,
+   [USB_ENDPOINT_XFER_BULK] = 1024,
+   [USB_ENDPOINT_XFER_INT] = 1024,
+};
+
 static int usb_parse_endpoint(struct device *ddev, int cfgno, int inum,
 int asnum, struct usb_host_interface *ifp, int num_ep,
 unsigned char *buffer, int size)
@@ -179,6 +204,8 @@ static int usb_parse_endpoint(struct dev
struct usb_endpoint_descriptor *d;
struct usb_host_endpoint *endpoint;
int n, i, j, retval;
+   unsigned int maxp;
+   const unsigned short *maxpacket_maxes;
 
d = (struct usb_endpoint_descriptor *) buffer;
buffer += d->bLength;
@@ -290,6 +317,42 @@ static int usb_parse_endpoint(struct dev
endpoint->desc.wMaxPacketSize = cpu_to_le16(8);
}
 
+   /* Validate the wMaxPacketSize field */
+   maxp = usb_endpoint_maxp(>desc);
+
+   /* Find the highest legal maxpacket size for this endpoint */
+   i = 0;  /* additional transactions per microframe */
+   switch (to_usb_device(ddev)->speed) {
+   case USB_SPEED_LOW:
+   maxpacket_maxes = low_speed_maxpacket_maxes;
+   break;
+   case USB_SPEED_FULL:
+   maxpacket_maxes = full_speed_maxpacket_maxes;
+   break;
+   case USB_SPEED_HIGH:
+   /* Bits 12..11 are allowed only for HS periodic endpoints */
+   if (usb_endpoint_xfer_int(d) || usb_endpoint_xfer_isoc(d)) {
+   i = maxp & (BIT(12) | BIT(11));
+   maxp &= ~i;
+   }
+   /* fallthrough */
+   default:
+   maxpacket_maxes = high_speed_maxpacket_maxes;
+   break;
+   case USB_SPEED_SUPER:
+   case USB_SPEED_SUPER_PLUS:
+   maxpacket_maxes = super_speed_maxpacket_maxes;
+   break;
+   }
+   j = maxpacket_maxes[usb_endpoint_type(>desc)];
+
+   if (maxp > j) {
+   dev_warn(ddev, "config %d interface %d altsetting %d endpoint 
0x%X has invalid maxpacket %d, setting to %d\n",
+   cfgno, inum, asnum, d->bEndpointAddress, maxp, j);
+   maxp = j;
+   endpoint->desc.wMaxPacketSize = cpu_to_le16(i | maxp);
+   }
+
/*
 * Some buggy high speed devices have bulk endpoints using
 * maxpacket sizes other than 512.  High speed HCDs may not
@@ -297,9 +360,6 @@ static int usb_parse_endpoint(struct dev
 */
if (to_usb_device(ddev)->speed == USB_SPEED_HIGH
&& usb_endpoint_xfer_bulk(d)) {
-   unsigned maxp;
-
-   maxp = usb_endpoint_maxp(>desc) & 0x07ff;
if (maxp != 512)
dev_warn(ddev, "config %d interface %d altsetting %d "
"bulk endpoint 0x%X has invalid maxpacket %d\n",

--
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] xhci: Fix soft lockup in xhci_pci_probe path when XHCI_STATE_HALTED

[Kamal Mostafa]

Commit 27a41a83ec54 ("xhci: Cleanup only when releasing primary hcd")
causes a soft lockup at boot when XHCI_STATE_HALTED, preventing
VirtualBox 5.1.x from booting if USB3.0 is enabled.

Revert to allowing xhci_irq to handle the interrupt when
XHCI_STATE_HALTED but not XHCI_STATE_DYING.

Fixes: 27a41a83ec54 ("xhci: Cleanup only when releasing primary hcd")
BugLink: https://bugs.launchpad.net/bugs/1604058
Signed-off-by: Kamal Mostafa 
Cc:  #v4.3+
Cc: Gabriel Krisman Bertazi 
Acked-by: Tim Gardner 
Acked-by: Stefan Bader 
---
 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 918e0c7..1d36a5f 100644
--- a/drivers/usb/host/xhci-ring.c
+++ b/drivers/usb/host/xhci-ring.c
@@ -2751,8 +2751,7 @@ hw_died:
writel(irq_pending, >ir_set->irq_pending);
}
 
-   if (xhci->xhc_state & XHCI_STATE_DYING ||
-   xhci->xhc_state & XHCI_STATE_HALTED) {
+   if (xhci->xhc_state & XHCI_STATE_DYING) {
xhci_dbg(xhci, "xHCI dying, ignoring interrupt. "
"Shouldn't IRQs be disabled?\n");
/* Clear the event handler busy flag (RW1C);
@@ -2764,6 +2763,8 @@ hw_died:
spin_unlock(>lock);
 
return IRQ_HANDLED;
+   } else if (xhci->xhc_state & XHCI_STATE_HALTED) {
+   xhci_dbg(xhci, "xHCI halted, handling interrupt.\n");
}
 
event_ring_deq = xhci->event_ring->dequeue;
-- 
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 v2] usb: gadget: Add per-lun inquiry string

[Philipp Gesang]

Introduce an attribute "inquiry_string" to the lun.

In some environments, e. g. BIOS boot menus, the inquiry string
is the only information about devices presented to the user. The
default string depends on the "cdrom" bit of the first lun as
well as the kernel version and allows no further customization.
So without access to the client it is not obvious which gadget is
active at a given point and what any of the available luns might
contain.

If "inquiry_string" is ignored or set to the empty string, the
old behavior is preserved.

Signed-off-by: Philipp Gesang 
---
 drivers/usb/gadget/function/f_mass_storage.c | 28 ++--
 drivers/usb/gadget/function/f_mass_storage.h |  1 +
 drivers/usb/gadget/function/storage_common.c | 24 
 drivers/usb/gadget/function/storage_common.h | 10 ++
 4 files changed, 57 insertions(+), 6 deletions(-)

diff --git a/drivers/usb/gadget/function/f_mass_storage.c 
b/drivers/usb/gadget/function/f_mass_storage.c
index 5c6d4d7..efcc3de 100644
--- a/drivers/usb/gadget/function/f_mass_storage.c
+++ b/drivers/usb/gadget/function/f_mass_storage.c
@@ -311,11 +311,7 @@ struct fsg_common {
/* Gadget's private data. */
void*private_data;
 
-   /*
-* Vendor (8 chars), product (16 chars), release (4
-* hexadecimal digits) and NUL byte
-*/
-   char inquiry_string[8 + 16 + 4 + 1];
+   char inquiry_string[INQUIRY_STRING_LEN];
 
struct kref ref;
 };
@@ -1107,7 +1103,12 @@ static int do_inquiry(struct fsg_common *common, struct 
fsg_buffhd *bh)
buf[5] = 0; /* No special options */
buf[6] = 0;
buf[7] = 0;
-   memcpy(buf + 8, common->inquiry_string, sizeof common->inquiry_string);
+   if (curlun->inquiry_string[0])
+   memcpy(buf + 8, curlun->inquiry_string,
+  sizeof(curlun->inquiry_string));
+   else
+   memcpy(buf + 8, common->inquiry_string,
+  sizeof(common->inquiry_string));
return 36;
 }
 
@@ -3225,12 +3226,27 @@ static ssize_t fsg_lun_opts_nofua_store(struct 
config_item *item,
 
 CONFIGFS_ATTR(fsg_lun_opts_, nofua);
 
+static ssize_t fsg_lun_opts_inquiry_string_show(struct config_item *item,
+   char *page)
+{
+   return fsg_show_inquiry_string(to_fsg_lun_opts(item)->lun, page);
+}
+
+static ssize_t fsg_lun_opts_inquiry_string_store(struct config_item *item,
+const char *page, size_t len)
+{
+   return fsg_store_inquiry_string(to_fsg_lun_opts(item)->lun, page, len);
+}
+
+CONFIGFS_ATTR(fsg_lun_opts_, inquiry_string);
+
 static struct configfs_attribute *fsg_lun_attrs[] = {
_lun_opts_attr_file,
_lun_opts_attr_ro,
_lun_opts_attr_removable,
_lun_opts_attr_cdrom,
_lun_opts_attr_nofua,
+   _lun_opts_attr_inquiry_string,
NULL,
 };
 
diff --git a/drivers/usb/gadget/function/f_mass_storage.h 
b/drivers/usb/gadget/function/f_mass_storage.h
index b6a9918..d390231 100644
--- a/drivers/usb/gadget/function/f_mass_storage.h
+++ b/drivers/usb/gadget/function/f_mass_storage.h
@@ -100,6 +100,7 @@ struct fsg_lun_config {
char removable;
char cdrom;
char nofua;
+   char inquiry_string[INQUIRY_STRING_LEN];
 };
 
 struct fsg_config {
diff --git a/drivers/usb/gadget/function/storage_common.c 
b/drivers/usb/gadget/function/storage_common.c
index 990df22..8fbf686 100644
--- a/drivers/usb/gadget/function/storage_common.c
+++ b/drivers/usb/gadget/function/storage_common.c
@@ -369,6 +369,12 @@ ssize_t fsg_show_removable(struct fsg_lun *curlun, char 
*buf)
 }
 EXPORT_SYMBOL_GPL(fsg_show_removable);
 
+ssize_t fsg_show_inquiry_string(struct fsg_lun *curlun, char *buf)
+{
+   return sprintf(buf, "%s\n", curlun->inquiry_string);
+}
+EXPORT_SYMBOL_GPL(fsg_show_inquiry_string);
+
 /*
  * The caller must hold fsg->filesem for reading when calling this function.
  */
@@ -499,4 +505,22 @@ ssize_t fsg_store_removable(struct fsg_lun *curlun, const 
char *buf,
 }
 EXPORT_SYMBOL_GPL(fsg_store_removable);
 
+ssize_t fsg_store_inquiry_string(struct fsg_lun *curlun, const char *buf,
+size_t count)
+{
+   const size_t len = min(count, sizeof(curlun->inquiry_string));
+
+   if (len == 0 || buf[0] == '\n') {
+   curlun->inquiry_string[0] = 0;
+   } else {
+   snprintf(curlun->inquiry_string,
+sizeof(curlun->inquiry_string), "%-28s", buf);
+   if (curlun->inquiry_string[len-1] == '\n')
+   curlun->inquiry_string[len-1] = ' ';
+   }
+
+   return count;
+}
+EXPORT_SYMBOL_GPL(fsg_store_inquiry_string);
+
 MODULE_LICENSE("GPL");
diff --git a/drivers/usb/gadget/function/storage_common.h 
b/drivers/usb/gadget/function/storage_common.h
index 

Re: NEC uPD720200 xHCI Controller dies when Runtime PM enabled

[Mike Murdoch]

Hello,

On 2016-08-01 13:57, Durval Menezes wrote:
> Hi Mathias,
>
> On Mon, Aug 1, 2016 at 8:20 AM, Mathias Nyman  
> wrote:
>>> On 01.08.2016 13:15, Durval Menezes wrote:
>>> Hello Mike, Mathias, list,
>>>
>>> On 06.02.2016 19:08, Mike Murdoch wrote:
>>> Bug ID: 111251
>>>
>>> I have a NEC uPD720200 USB3.0 controller in a Thinkpad W520 laptop on
>>> kernel 4.4.1-gentoo.
>>>
>>> 0e:00.0 USB controller: NEC Corporation uPD720200 USB 3.0 Host
>>> Controller (rev 04) (prog-if 30 [XHCI])
>>>  Subsystem: Lenovo uPD720200 USB 3.0 Host Controller
>>>  Flags: bus master, fast devsel, latency 0
>>>  Memory at f380 (64-bit, non-prefetchable) [size=8K]
>>>  Capabilities: [50] Power Management version 3
>>>  Capabilities: [70] MSI: Enable- Count=1/8 Maskable- 64bit+
>>>  Capabilities: [90] MSI-X: Enable+ Count=8 Masked-
>>>  Capabilities: [a0] Express Endpoint, MSI 00
>>>  Capabilities: [100] Advanced Error Reporting
>>>  Capabilities: [140] Device Serial Number ff-ff-ff-ff-ff-ff-ff-ff
>>>  Capabilities: [150] Latency Tolerance Reporting
>>>  Kernel driver in use: xhci_hcd
>>>  Kernel modules: xhci_pci
>>>
>>> When runtime power control for this controller is disabled
>>> (/sys/bus/pci/devices/:0e:00.0/power/control = on), the controller
>>> works fine and reaches over 120MB/s transfer rates.
>>>
>>> When runtime power control for this controller is enabled
>>> (/sys/bus/pci/devices/:0e:00.0/power/control = auto), two effects
>>> can be observed:
>>>
>>> - Transfer rates are much lower at around 30MB/s
>>> - During transfers, the controller dies after a couple of seconds:
>>>
>>> I found this message in the list archives, and I have the exact same
>>> issues on exactly the same hardware (Thinkpad W520 laptop with the same
>>> USB3 controller showing on lspci -v); otherwise, I'm running distro kernel
>>> 2.6.32-573.7.1.el6.x86_64 on a Springdale Linux 6.7 (RHEL6) install.
>>>
>>> I just verified that my controller's PM was set by default to "auto":
>>> cat /sys/bus/pci/devices/\:0e\:00.0/power/control
>>> auto
>>> I have now set it to "on" and will test whether this will work around
>>> the issue (I'm waiting for my USB3.0 "heavy duty" disk docks to be
>>> released from another system that is using them right now).
>>>
>>> I have one question for Mike: have you upgraded your uPD720200 controller
>>> firmware (as per [1], [2]) or are you still running stock?
>>>
>>> Also, one question for Mathias: do you know whether your patches at [3]
>>> can be applied to kernel 2.6.32?
>> The last patch in [3] is faulty. So don't use the patches from the mail.
>>
>> I just force updated that branch, so if you like you can try to backport
>> patches from:
>>
>>  git://git.kernel.org/pub/scm/linux/kernel/git/mnyman/xhci.git 
>> bug_usb3_enum_rtresume
>>
>> only 2 patches are relevant:
>>
>> 8caabe9 xhci: Don't suspend the xhci bus it there is a pending event.
>> 4427456 xhci: resume USB 3 roothub first
> Thanks Mathias. Now I only need Mike's response concerning the firmware
> in order to proceed.
>
> Cheers,
No, I haven't tried updating the firmware. Feel free to give it a go,
I'm curious if it'll make a difference.

As for the patches. All three of them did fix this bug, but introduced
other problems (I don't remember details, sorry). As Mathias said, the
last one is faulty. However, using only the first two patches is *not*
enough to completely fix this bug (I verified it just now).

Unfortunately I don't have the time to do much testing. The Thinkpad is
used by someone else and I only have access to it on the weekends. A
workaround is to just disable runtime power management.

Let me know how things work for you!

Cheers,
Mike
--
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] power: add power sequence library

[Joshua Clayton]

On 07/28/2016 09:41 AM, Fabio Estevam wrote:
> Hi Joshua,
>
> On Thu, Jul 28, 2016 at 12:56 PM, Joshua Clayton
>  wrote:
>
>> I assume there is a v4 coming due to rmk's comments on patch 5.
>> I couldn't figure out where to null the of_node in error paths, but in 
>> testing
>> we did put a line of code to null the of_node on release.
>>
>> but...
>> As an aside,
>> I was hoping this series would magically fix a problem
>> with the imx6q-evi which has forced us to disable
>> runtime power management. But it did not. :(
> I also see a similar problem on a mx28 board with a hub.
>
> Does it help in your case if you pass 'usbcore.autosuspend=-1' in the
> kernel command line?
>
> Regards,
>
> Fabio Estevam
Thanks a million, Fabio!

'usbcore.autosuspend=-1' quiets the errors.

~joshua

P.S. I guess this technically is a bug in chipidea usb.
I'll give it a quick once over, though I am not very familiar
with USB core or the CI driver.


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

Re: [RFC] usb: host: u132-hcd: Remove deprecated create_singlethread_workqueue

[Tejun Heo]

Hello,

On Mon, Aug 01, 2016 at 03:50:36PM +0200, Michal Hocko wrote:
> > All that would do is deferring the deadlock, right?  I'm not sure it
> > makes a lot of sense to protect an IO path against memory pressure
> > half-way.  It either can be depended during memory reclaim or it
> > can't. 
> 
> Completely agreed! If the rescuer thread can block on a memory
> allocation be it GFP_NOIO or others it is basically useless.
...
> > Can MM people please chime in?  The question is about USB stoage
> > devices and memory reclaim.  USB doesn't guarantee forward progress
> > under memory pressure but tries a best-effort attempt with GFP_NOIO
> > and ATOMIC.  Is this the right thing to do?
> 
> If any real IO depends on those devices then this is not sufficient and
> they need some form of guarantee for progress (aka mempool).

Oliver, Alan, what do you think?  If USB itself can't operate without
allocating memory during transactions, whatever USB storage drivers
are doing isn't all that meaningful.  Can we proceed with the
workqueue patches?  Also, it could be that the only thing GFP_NOIO and
GFP_ATOMIC are doing is increasing the chance of IO failures under
memory pressure.  Maybe it'd be a good idea to reconsider the
approach?

Thanks.

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

Re: [RFC] usb: host: u132-hcd: Remove deprecated create_singlethread_workqueue

[Michal Hocko]

On Fri 29-07-16 09:11:47, Tejun Heo wrote:
> Hello, Alan.
> 
> On Wed, Jul 27, 2016 at 04:45:19PM -0400, Alan Stern wrote:
> > > Hmm... That doesn't really make them dependable during memory reclaim.
> > 
> > True.  But it does mean that they can't cause a deadlock by waiting
> > indefinitely for some other memory to be paged out to the very device
> > they are on the access pathway for.
> > 
> > > What happens when those allocations fail?
> > 
> > The same thing that happens when any allocation fails -- the original
> > I/O request fails with -ENOMEM or the equivalent.  In the case of 
> > usb-storage, this is likely to trigger error recovery, which will need 
> > to allocate memory of its own...  A bad situation to get into.
> 
> All that would do is deferring the deadlock, right?  I'm not sure it
> makes a lot of sense to protect an IO path against memory pressure
> half-way.  It either can be depended during memory reclaim or it
> can't. 

Completely agreed! If the rescuer thread can block on a memory
allocation be it GFP_NOIO or others it is basically useless.

> The use of GFP_NOIO / ATOMIC is probably increases the chance
> of IO errors under moderate memory pressure too when there are
> dependable memory backing devices (and there better be) which can push
> things forward if called upon.
> 
> Can MM people please chime in?  The question is about USB stoage
> devices and memory reclaim.  USB doesn't guarantee forward progress
> under memory pressure but tries a best-effort attempt with GFP_NOIO
> and ATOMIC.  Is this the right thing to do?

If any real IO depends on those devices then this is not sufficient and
they need some form of guarantee for progress (aka mempool).
-- 
Michal Hocko
SUSE Labs
--
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: NEC uPD720200 xHCI Controller dies when Runtime PM enabled

[Durval Menezes]

Hi Mathias,

On Mon, Aug 1, 2016 at 8:20 AM, Mathias Nyman  
wrote:
> > On 01.08.2016 13:15, Durval Menezes wrote:
> > Hello Mike, Mathias, list,
> > 
> > On 06.02.2016 19:08, Mike Murdoch wrote:
> > Bug ID: 111251
> > 
> > I have a NEC uPD720200 USB3.0 controller in a Thinkpad W520 laptop on
> > kernel 4.4.1-gentoo.
> > 
> > 0e:00.0 USB controller: NEC Corporation uPD720200 USB 3.0 Host
> > Controller (rev 04) (prog-if 30 [XHCI])
> >  Subsystem: Lenovo uPD720200 USB 3.0 Host Controller
> >  Flags: bus master, fast devsel, latency 0
> >  Memory at f380 (64-bit, non-prefetchable) [size=8K]
> >  Capabilities: [50] Power Management version 3
> >  Capabilities: [70] MSI: Enable- Count=1/8 Maskable- 64bit+
> >  Capabilities: [90] MSI-X: Enable+ Count=8 Masked-
> >  Capabilities: [a0] Express Endpoint, MSI 00
> >  Capabilities: [100] Advanced Error Reporting
> >  Capabilities: [140] Device Serial Number ff-ff-ff-ff-ff-ff-ff-ff
> >  Capabilities: [150] Latency Tolerance Reporting
> >  Kernel driver in use: xhci_hcd
> >  Kernel modules: xhci_pci
> > 
> > When runtime power control for this controller is disabled
> > (/sys/bus/pci/devices/:0e:00.0/power/control = on), the controller
> > works fine and reaches over 120MB/s transfer rates.
> > 
> > When runtime power control for this controller is enabled
> > (/sys/bus/pci/devices/:0e:00.0/power/control = auto), two effects
> > can be observed:
> > 
> > - Transfer rates are much lower at around 30MB/s
> > - During transfers, the controller dies after a couple of seconds:
> > 
> > I found this message in the list archives, and I have the exact same
> > issues on exactly the same hardware (Thinkpad W520 laptop with the same
> > USB3 controller showing on lspci -v); otherwise, I'm running distro kernel
> > 2.6.32-573.7.1.el6.x86_64 on a Springdale Linux 6.7 (RHEL6) install.
> > 
> > I just verified that my controller's PM was set by default to "auto":
> > cat /sys/bus/pci/devices/\:0e\:00.0/power/control
> > auto
> > I have now set it to "on" and will test whether this will work around
> > the issue (I'm waiting for my USB3.0 "heavy duty" disk docks to be
> > released from another system that is using them right now).
> > 
> > I have one question for Mike: have you upgraded your uPD720200 controller
> > firmware (as per [1], [2]) or are you still running stock?
> > 
> > Also, one question for Mathias: do you know whether your patches at [3]
> > can be applied to kernel 2.6.32?
> 
> The last patch in [3] is faulty. So don't use the patches from the mail.
> 
> I just force updated that branch, so if you like you can try to backport
> patches from:
> 
>  git://git.kernel.org/pub/scm/linux/kernel/git/mnyman/xhci.git 
> bug_usb3_enum_rtresume
> 
> only 2 patches are relevant:
> 
> 8caabe9 xhci: Don't suspend the xhci bus it there is a pending event.
> 4427456 xhci: resume USB 3 roothub first

Thanks Mathias. Now I only need Mike's response concerning the firmware
in order to proceed.

Cheers,
-- 
  Durval Menezes (durval AT tmp DOT com DOT br, http://www.tmp.com.br/)
--
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: Possible design problem with struct ulpi_ops's dev field

[Felipe Balbi]

Hi,

Tal Shorer  writes:
> struct ulpi_ops is defined as follows:
>
> struct ulpi_ops {
> struct device *dev;
> int (*read)(struct ulpi_ops *ops, u8 addr);
> int (*write)(struct ulpi_ops *ops, u8 addr, u8 val);
> };
>
> Upon calling ulpi_register_interface(), the struct device argument is
> put inside the struct ulpi_ops argument's dev field. Later, when
> calling the actual read()/write() operations, the struct ulpi_ops is
> passed to them and they use the stored device to access whatever
> private data they need.
>
> This means that if one wishes to reuse the same oprations for multiple
> interfaces (e.g if we have multiple instances of the same controller),
> any but the last interface registered will not operate properly (and
> the one that does work will be at the mercy of the others to not mess
> it up).
>
> I understand that barely any driver uses this bus right now, but I
> suppose it's there to be used at some point. We might as well fix the
> design here before we hit this bug.
>
> I would like to create a patch series to fix this by passing the given
> struct device directly to the operation functions via ulpi->dev.parent
> in ulpi_read() and ulpi_write(), but I'm not sure about the correct
> order of the patches that make such a series. Do I change the api and
> all users in one patch? one patch for api and one for each user?
>
> Any comments and guidelines are welcome :)

add new ->read_dev() and ->write_dev() methods which take a struct
device * as argument. Change users to new API, then remove old API and
later rename everybody back to ->read()/->write() (removing the extra
_dev) argument.

Another option would be to start by renaming current API to
->read_deprecated/->write_deprecated, adding new ->read/->write and the
rest is the same.

Either way, you shouldn't break anything along the way and make sure you
use lots of grepping to make sure there are no regressions.

-- 
balbi


signature.asc
Description: PGP signature

Re: NEC uPD720200 xHCI Controller dies when Runtime PM enabled

[Mathias Nyman]

Hi

On 01.08.2016 13:15, Durval Menezes wrote:

Hello Mike, Mathias, list,

On 06.02.2016 19:08, Mike Murdoch wrote:

Bug ID: 111251

I have a NEC uPD720200 USB3.0 controller in a Thinkpad W520 laptop on
kernel 4.4.1-gentoo.

0e:00.0 USB controller: NEC Corporation uPD720200 USB 3.0 Host
Controller (rev 04) (prog-if 30 [XHCI])
 Subsystem: Lenovo uPD720200 USB 3.0 Host Controller
 Flags: bus master, fast devsel, latency 0
 Memory at f380 (64-bit, non-prefetchable) [size=8K]
 Capabilities: [50] Power Management version 3
 Capabilities: [70] MSI: Enable- Count=1/8 Maskable- 64bit+
 Capabilities: [90] MSI-X: Enable+ Count=8 Masked-
 Capabilities: [a0] Express Endpoint, MSI 00
 Capabilities: [100] Advanced Error Reporting
 Capabilities: [140] Device Serial Number ff-ff-ff-ff-ff-ff-ff-ff
 Capabilities: [150] Latency Tolerance Reporting
 Kernel driver in use: xhci_hcd
 Kernel modules: xhci_pci

When runtime power control for this controller is disabled
(/sys/bus/pci/devices/:0e:00.0/power/control = on), the controller
works fine and reaches over 120MB/s transfer rates.

When runtime power control for this controller is enabled
(/sys/bus/pci/devices/:0e:00.0/power/control = auto), two effects
can be observed:

- Transfer rates are much lower at around 30MB/s
- During transfers, the controller dies after a couple of seconds:


I found this message in the list archives, and I have the exact same
issues on exactly the same hardware (Thinkpad W520 laptop with the same
USB3 controller showing on lspci -v); otherwise, I'm running distro kernel
2.6.32-573.7.1.el6.x86_64 on a Springdale Linux 6.7 (RHEL6) install.

I just verified that my controller's PM was set by default to "auto":
cat /sys/bus/pci/devices/\:0e\:00.0/power/control
auto
I have now set it to "on" and will test whether this will work around
the issue (I'm waiting for my USB3.0 "heavy duty" disk docks to be
released from another system that is using them right now).

I have one question for Mike: have you upgraded your uPD720200 controller
firmware (as per [1], [2]) or are you still running stock?

Also, one question for Mathias: do you know whether your patches at [3]
can be applied to kernel 2.6.32?


The last patch in [3] is faulty. So don't use the patches from the mail.

I just force updated that branch, so if you like you can try to backport
patches from:

 git://git.kernel.org/pub/scm/linux/kernel/git/mnyman/xhci.git 
bug_usb3_enum_rtresume

only 2 patches are relevant:

8caabe9 xhci: Don't suspend the xhci bus it there is a pending event.
4427456 xhci: resume USB 3 roothub first

-Mathias



References
 [1] 
https://forums.lenovo.com/t5/ThinkPad-P-and-W-Series-Mobile/Anyone-updated-their-W520-USB-3-0-firmware/td-p/1164719
 [2] http://pete.akeo.ie/2011/10/flashing-necrenesas-usb-30.html
 [3] http://marc.info/?l=linux-usb=145684596900873=2



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

Re: NEC uPD720200 xHCI Controller dies when Runtime PM enabled

[Durval Menezes]

Hello Mike, Mathias, list,

On 06.02.2016 19:08, Mike Murdoch wrote:
> Bug ID: 111251
> 
> I have a NEC uPD720200 USB3.0 controller in a Thinkpad W520 laptop on
> kernel 4.4.1-gentoo.
> 
> 0e:00.0 USB controller: NEC Corporation uPD720200 USB 3.0 Host
> Controller (rev 04) (prog-if 30 [XHCI])
> Subsystem: Lenovo uPD720200 USB 3.0 Host Controller
> Flags: bus master, fast devsel, latency 0
> Memory at f380 (64-bit, non-prefetchable) [size=8K]
> Capabilities: [50] Power Management version 3
> Capabilities: [70] MSI: Enable- Count=1/8 Maskable- 64bit+
> Capabilities: [90] MSI-X: Enable+ Count=8 Masked-
> Capabilities: [a0] Express Endpoint, MSI 00
> Capabilities: [100] Advanced Error Reporting
> Capabilities: [140] Device Serial Number ff-ff-ff-ff-ff-ff-ff-ff
> Capabilities: [150] Latency Tolerance Reporting
> Kernel driver in use: xhci_hcd
> Kernel modules: xhci_pci
> 
> When runtime power control for this controller is disabled
> (/sys/bus/pci/devices/:0e:00.0/power/control = on), the controller
> works fine and reaches over 120MB/s transfer rates.
> 
> When runtime power control for this controller is enabled
> (/sys/bus/pci/devices/:0e:00.0/power/control = auto), two effects
> can be observed:
> 
> - Transfer rates are much lower at around 30MB/s
> - During transfers, the controller dies after a couple of seconds:

I found this message in the list archives, and I have the exact same
issues on exactly the same hardware (Thinkpad W520 laptop with the same
USB3 controller showing on lspci -v); otherwise, I'm running distro kernel
2.6.32-573.7.1.el6.x86_64 on a Springdale Linux 6.7 (RHEL6) install.

I just verified that my controller's PM was set by default to "auto":
cat /sys/bus/pci/devices/\:0e\:00.0/power/control
auto
I have now set it to "on" and will test whether this will work around
the issue (I'm waiting for my USB3.0 "heavy duty" disk docks to be
released from another system that is using them right now).

I have one question for Mike: have you upgraded your uPD720200 controller
firmware (as per [1], [2]) or are you still running stock?

Also, one question for Mathias: do you know whether your patches at [3]
can be applied to kernel 2.6.32?

References
[1] 
https://forums.lenovo.com/t5/ThinkPad-P-and-W-Series-Mobile/Anyone-updated-their-W520-USB-3-0-firmware/td-p/1164719
[2] http://pete.akeo.ie/2011/10/flashing-necrenesas-usb-30.html
[3] http://marc.info/?l=linux-usb=145684596900873=2 

Cheers, 
-- 
  Durval Menezes (durval AT tmp DOT com DOT br, http://www.tmp.com.br/)

--
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] ehci-platform: add the max clock number to 4

[Hans de Goede]

Hi,

On 01-08-16 10:18, Icenowy Zheng wrote:



01.08.2016, 15:27, "Hans de Goede" :

Hi,

On 01-08-16 09:05, Icenowy Zheng wrote:

 clocks = < CLK_A64_BUS_OHCI1>,
  < CLK_A64_BUS_EHCI1>,
  < CLK_A64_USB_OHCI0>,
  < CLK_A64_USB_OHCI1>;

 On A64, EHCI requires the matched OHCI to work.


Ah, so just like on the H3 (where this also is needed
and not documented).

Yes, I feeled that A64 is like a hybrid of H3 and A33.



 And OHCI1 clock requires OHCI0 clock to work.


Hmm, that one is new, can you double check this ?

SCLK_GATING_OHCI.
Gating Special Clock For OHCI(48M and 12M)
00: Clock is OFF
01: OTG-OHCI Clock is ON
10: Clock is OFF
11:OTG-OHCI and OHCI0 Clock is ON

P.113 of A64 user manual 1.0


Ah I see that looks weird, I assume that you're working
on getting the regular usb host on the A64 to work, iow
the "HCI0" block in the usb block diagram at p. 580, right ?

It could be that the ohci clock for that somehow is
tapped from the ohci clock for the "USB-OTG-HCI" block,
but:

P.113, other bits of the USBPHY_CFG_REG register:

23:22 R/W 0x0 OHCI1_12M_SRC_SEL. OHCI1 12M Source Select
00: 12M divided from 48M
01: 12M divided from 24M
10: LOSC
11: /

21:20 R/W 0x0 OHCI0_12M_SRC_SEL. OHCI0 12M Source Select
00: 12M divided from 48M
01: 12M divided from 24M
10: LOSC
11: /

Suggests that they are independent...

Have you tried to simply drop

 < CLK_A64_USB_OHCI0>,

From the clocks list and check that usb-1 devices
(e.g. a mouse / keyboard) plugged directly into the
board still work ?

If it does we can simply drop it, of it does not work
then indeed we need 4 clocks because allwinner has
done something weird again.

###

Also it seems that the CLK_A64_USB_OHCI0 /
CLK_A64_USB_OHCI1 names are wrong, the datasheet
consistently (*) refers to "usb-otg-ohci" and an
"usb-ohci0" rather then ohci0 and ohci1 (**)

Except for the USBPHY_CFG_REG documentation for bits 20:23,
which I believe is an error in the datasheet.

So we should do the same in the dt-bindings IMHO.

Regards,

Hans



*) In the system address map (p. 73), "Interrupt Source" list (p.210)
in the "Bus Clock Gating Register0" doc (p. 100) and
in the usb block diagram (p. 580).

**) Unlike the H3 where usb-otg-ohci is called usb-ohci0 and
the first non otg host controller is called usb-ohci1.
--
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: ehci: change order of register cleanup during shutdown

[Marc Ohlf]

In ehci_turn_off_all_ports() all EHCI port register bits
(except the PORT_RWC_BITS) are set to zero.
On some hardware, this can lead to an system hang,
when ehci_port_power() accesses the already cleaned registers.

This patch changes the order of cleanup.
First call ehci_port_power() which respects the current bits in
port status registers
and afterwards cleanup the hard way by setting everything else to zero.

Signed-off-by: Marc Ohlf 
---
 drivers/usb/host/ehci-hcd.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/usb/host/ehci-hcd.c b/drivers/usb/host/ehci-hcd.c
index a962b89..1e5f529 100644
--- a/drivers/usb/host/ehci-hcd.c
+++ b/drivers/usb/host/ehci-hcd.c
@@ -332,11 +332,11 @@ static void ehci_turn_off_all_ports(struct ehci_hcd *ehci)
int port = HCS_N_PORTS(ehci->hcs_params);
 
while (port--) {
-   ehci_writel(ehci, PORT_RWC_BITS,
-   >regs->port_status[port]);
spin_unlock_irq(>lock);
ehci_port_power(ehci, port, false);
spin_lock_irq(>lock);
+   ehci_writel(ehci, PORT_RWC_BITS,
+   >regs->port_status[port]);
}
 }
 
-- 
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: [RFC] usb: phy: generic: get rid of VBUS handling

[Felipe Balbi]

Hi,

Robert Jarzmik  writes:
> Felipe Balbi  writes:
>
>> Hi Robert,
>>
>> Robert Jarzmik  writes:
>>> Felipe Balbi  writes:
>>>
 Hi,

 Robert Jarzmik  writes:
> I don't know if there are other users than pxa, I'll make the assumption 
> there
> aren't.

 yeah, we can keep patches in linux-next for as long as possible. If
 nobody complains, we're good.
>>>
>>> Hi Felipe,
>>>
>>> Just a small update. I made the change, but I'm not submitting it yet
>>
>> thanks for the update :-)
> Euh I think you have even more backlog in your mails than I do :)
>
> The latest update is here :
> https://patchwork.kernel.org/patch/9221755
>
> This one is fully functional AFAIK.

awesome :-) Thanks. I'll pick it up shortly after v4.7-rc1 is tagged

-- 
balbi


signature.asc
Description: PGP signature

Re: [PATCH 3/3] ehci-platform: add the max clock number to 4

[Hans de Goede]

Hi,

On 01-08-16 09:05, Icenowy Zheng wrote:

clocks = < CLK_A64_BUS_OHCI1>,
 < CLK_A64_BUS_EHCI1>,
 < CLK_A64_USB_OHCI0>,
 < CLK_A64_USB_OHCI1>;

On A64, EHCI requires the matched OHCI to work.


Ah, so just like on the H3 (where this also is needed
and not documented).


And OHCI1 clock requires OHCI0 clock to work.


Hmm, that one is new, can you double check this ?

Regards,

Hans




(But from the SoC's user manual we cannot get any infomation
about the relationship between OHCI1 clock and OHCI0 clock,
and in the manual OHCI0 clock is called OTG-OHCI)

01.08.2016, 15:01, "Arnd Bergmann" :

On Sunday, July 31, 2016 7:25:36 PM CEST Icenowy Zheng wrote:

 Allwinner A64 EHCI requires 4 clocks to be enabled.

 Signed-off-by: Icenowy Zheng 


Can you say what those four clocks are?

Are you sure that it's not just a case of a clock being
incorrectly described in the clk driver, i.e. you reference
one clock along with its parent here?

Arnd

--
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 v16 0/4] Introduce usb charger framework to deal with the usb gadget power negotation

[Baolin Wang]

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

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

CHanges since v15:
 - Add charger state checking to avoid sending out duplicate notifies to users.
 - Add one work to notify power users the current has been changed.

Changes since v14:
 - Add kernel documentation for struct usb_cahrger.
 - Remove some redundant WARN() functions.

Changes since v13:
 - Remove the charger checking in usb_gadget_vbus_draw() function.
 - Rename some functions in charger.c file.
 - Rebase on git://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb.git 
tags/usb-for-v4.8

Changes since v12:
 - Remove the class and device things.
 - Link usb charger to udc-core.ko.
 - Create one "charger" subdirectory which holds all charger-related attributes.

Changes since v11:
 - Reviewed and tested by Li Jun.

Changes since v10:
 - Introduce usb_charger_get_state() function to check charger state.
 - Remove the mutex lock in usb_charger_set_cur_limit_by_type() function
 in case will be issued in atomic context.

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

 drivers/power/wm831x_power.c |   69 
 drivers/usb/gadget/Kconfig   |8 +
 drivers/usb/gadget/udc/Makefile  |1 +
 drivers/usb/gadget/udc/charger.c |  780 ++
 drivers/usb/gadget/udc/core.c|   17 +
 include/linux/mfd/wm831x/pdata.h |3 +
 include/linux/usb/charger.h  |  186 +
 include/linux/usb/gadget.h   |3 +
 include/uapi/linux/usb/charger.h |   31 ++
 9 files changed, 1098 insertions(+)
 create mode 100644 drivers/usb/gadget/udc/charger.c
 create mode 100644 include/linux/usb/charger.h
 create mode 100644 include/uapi/linux/usb/charger.h

-- 
1.7.9.5

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

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

[Baolin Wang]

For supporting the usb charger, it adds the usb_charger_init() and
usb_charger_exit() functions for usb charger initialization and exit.

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

Signed-off-by: Baolin Wang 
Reviewed-by: Li Jun 
Tested-by: Li Jun 
---
 drivers/usb/gadget/udc/core.c |   17 +
 include/linux/usb/gadget.h|3 +++
 2 files changed, 20 insertions(+)

diff --git a/drivers/usb/gadget/udc/core.c b/drivers/usb/gadget/udc/core.c
index ff8685e..bdf1874 100644
--- a/drivers/usb/gadget/udc/core.c
+++ b/drivers/usb/gadget/udc/core.c
@@ -25,6 +25,7 @@
 #include 
 #include 
 
+#include 
 #include 
 #include 
 #include 
@@ -578,12 +579,17 @@ EXPORT_SYMBOL_GPL(usb_gadget_vbus_connect);
  * reporting how much power the device may consume.  For example, this
  * could affect how quickly batteries are recharged.
  *
+ * It will also notify the USB charger how much power the device may
+ * consume if there is a USB charger linking with the gadget.
+ *
  * Returns zero on success, else negative errno.
  */
 int usb_gadget_vbus_draw(struct usb_gadget *gadget, unsigned mA)
 {
int ret = 0;
 
+   usb_charger_set_cur_limit_by_gadget(gadget, mA);
+
if (!gadget->ops->vbus_draw) {
ret = -EOPNOTSUPP;
goto out;
@@ -965,6 +971,9 @@ static void usb_gadget_state_work(struct work_struct *work)
struct usb_gadget *gadget = work_to_gadget(work);
struct usb_udc *udc = gadget->udc;
 
+   /* when the gadget state is changed, then report to USB charger */
+   usb_charger_plug_by_gadget(gadget, gadget->state);
+
if (udc)
sysfs_notify(>dev.kobj, NULL, "state");
 }
@@ -1134,6 +1143,10 @@ int usb_add_gadget_udc_release(struct device *parent, 
struct usb_gadget *gadget,
if (ret)
goto err4;
 
+   ret = usb_charger_init(gadget);
+   if (ret)
+   goto err5;
+
usb_gadget_set_state(gadget, USB_STATE_NOTATTACHED);
udc->vbus = true;
 
@@ -1154,6 +1167,9 @@ int usb_add_gadget_udc_release(struct device *parent, 
struct usb_gadget *gadget,
 
return 0;
 
+err5:
+   device_del(>dev);
+
 err4:
list_del(>list);
mutex_unlock(_lock);
@@ -1262,6 +1278,7 @@ void usb_del_gadget_udc(struct usb_gadget *gadget)
kobject_uevent(>dev.kobj, KOBJ_REMOVE);
flush_work(>work);
device_unregister(>dev);
+   usb_charger_exit(gadget);
device_unregister(>dev);
 }
 EXPORT_SYMBOL_GPL(usb_del_gadget_udc);
diff --git a/include/linux/usb/gadget.h b/include/linux/usb/gadget.h
index 612dbdf..c864b51 100644
--- a/include/linux/usb/gadget.h
+++ b/include/linux/usb/gadget.h
@@ -24,6 +24,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #define UDC_TRACE_STR_MAX  512
 
@@ -328,6 +329,7 @@ struct usb_gadget_ops {
  * @in_epnum: last used in ep number
  * @mA: last set mA value
  * @otg_caps: OTG capabilities of this gadget.
+ * @charger: Negotiate the power with the usb charger.
  * @sg_supported: true if we can handle scatter-gather
  * @is_otg: True if the USB device port uses a Mini-AB jack, so that the
  * gadget driver must provide a USB OTG descriptor.
@@ -385,6 +387,7 @@ struct usb_gadget {
unsignedin_epnum;
unsignedmA;
struct usb_otg_caps *otg_caps;
+   struct usb_charger  *charger;
 
unsignedsg_supported:1;
unsignedis_otg:1;
-- 
1.7.9.5

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

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

[Baolin Wang]

When the usb gadget supporting for usb charger is ready, the usb charger
can implement the usb_charger_plug_by_gadget() function, usb_charger_exit()
function and dev_to_uchger() function by getting 'struct usb_charger' from
'struct gadget'.

Signed-off-by: Baolin Wang 
Reviewed-by: Li Jun 
Tested-by: Li Jun 
---
 drivers/usb/gadget/udc/charger.c |   87 +-
 1 file changed, 85 insertions(+), 2 deletions(-)

diff --git a/drivers/usb/gadget/udc/charger.c b/drivers/usb/gadget/udc/charger.c
index 462faa1..13f53b1 100644
--- a/drivers/usb/gadget/udc/charger.c
+++ b/drivers/usb/gadget/udc/charger.c
@@ -36,7 +36,9 @@ static unsigned int __usb_charger_get_cur_limit(struct 
usb_charger *uchger);
 
 static struct usb_charger *dev_to_uchger(struct device *dev)
 {
-   return NULL;
+   struct usb_gadget *gadget = container_of(dev, struct usb_gadget, dev);
+
+   return gadget->charger;
 }
 
 /*
@@ -325,6 +327,18 @@ static void usb_charger_notify_work(struct work_struct 
*work)
 int usb_charger_set_cur_limit_by_gadget(struct usb_gadget *gadget,
unsigned int cur_limit)
 {
+   struct usb_charger *uchger = gadget->charger;
+   int ret;
+
+   if (!uchger)
+   return -EINVAL;
+
+   ret = __usb_charger_set_cur_limit_by_type(uchger, uchger->type,
+ cur_limit);
+   if (ret)
+   return ret;
+
+   schedule_work(>work);
return 0;
 }
 EXPORT_SYMBOL_GPL(usb_charger_set_cur_limit_by_gadget);
@@ -582,11 +596,68 @@ usb_charger_plug_by_extcon(struct notifier_block *nb,
 int usb_charger_plug_by_gadget(struct usb_gadget *gadget,
   unsigned long state)
 {
+   struct usb_charger *uchger = gadget->charger;
+   enum usb_charger_state uchger_state;
+
+   if (WARN(!uchger, "charger can not be NULL"))
+   return -EINVAL;
+
+   /*
+* Report event to power to setting the current limitation
+* for this usb charger when one usb charger state is changed
+* with detecting by usb gadget state.
+*/
+   if (uchger->old_gadget_state != state) {
+   uchger->old_gadget_state = state;
+
+   if (state >= USB_STATE_ATTACHED) {
+   uchger_state = USB_CHARGER_PRESENT;
+   } else if (state == USB_STATE_NOTATTACHED) {
+   mutex_lock(>lock);
+
+   /*
+* Need check the charger type to make sure the usb
+* cable is removed, in case it just changes the usb
+* function with configfs.
+*/
+   uchger->type = UNKNOWN_TYPE;
+   usb_charger_get_type_by_others(uchger);
+   if (uchger->type != UNKNOWN_TYPE) {
+   mutex_unlock(>lock);
+   return 0;
+   }
+
+   mutex_unlock(>lock);
+   uchger_state = USB_CHARGER_REMOVE;
+   } else {
+   uchger_state = USB_CHARGER_DEFAULT;
+   }
+
+   usb_charger_notify_others(uchger, uchger_state);
+   }
+
return 0;
 }
 EXPORT_SYMBOL_GPL(usb_charger_plug_by_gadget);
 
 /*
+ * usb_charger_unregister() - Unregister a usb charger.
+ * @uchger - the usb charger to be unregistered.
+ */
+static int usb_charger_unregister(struct usb_charger *uchger)
+{
+   ida_simple_remove(_charger_ida, uchger->id);
+   sysfs_remove_groups(>gadget->dev.kobj, usb_charger_groups);
+
+   mutex_lock(_lock);
+   list_del(>list);
+   mutex_unlock(_lock);
+
+   kfree(uchger);
+   return 0;
+}
+
+/*
  * usb_charger_register() - Register a new usb charger.
  * @uchger - the new usb charger instance.
  */
@@ -667,6 +738,7 @@ int usb_charger_init(struct usb_gadget *ugadget)
 
/* register a notifier on a usb gadget device */
uchger->gadget = ugadget;
+   ugadget->charger = uchger;
uchger->old_gadget_state = USB_STATE_NOTATTACHED;
 
/* register a new usb charger */
@@ -689,7 +761,18 @@ fail:
 
 int usb_charger_exit(struct usb_gadget *ugadget)
 {
-   return 0;
+   struct usb_charger *uchger = ugadget->charger;
+
+   if (!uchger)
+   return -EINVAL;
+
+   ugadget->charger = NULL;
+   if (uchger->extcon_dev)
+   extcon_unregister_notifier(uchger->extcon_dev,
+  EXTCON_USB,
+  >extcon_nb.nb);
+
+   return usb_charger_unregister(uchger);
 }
 
 MODULE_AUTHOR("Baolin Wang ");
-- 
1.7.9.5

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org

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

[Baolin Wang]

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

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

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

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

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

Signed-off-by: Baolin Wang 
Reviewed-by: Li Jun 
Tested-by: Li Jun 
---
 drivers/usb/gadget/Kconfig   |8 +
 drivers/usb/gadget/udc/Makefile  |1 +
 drivers/usb/gadget/udc/charger.c |  697 ++
 include/linux/usb/charger.h  |  186 ++
 include/uapi/linux/usb/charger.h |   31 ++
 5 files changed, 923 insertions(+)
 create mode 100644 drivers/usb/gadget/udc/charger.c
 create mode 100644 include/linux/usb/charger.h
 create mode 100644 include/uapi/linux/usb/charger.h

diff --git a/drivers/usb/gadget/Kconfig b/drivers/usb/gadget/Kconfig
index 3c3f31c..acea3f7 100644
--- a/drivers/usb/gadget/Kconfig
+++ b/drivers/usb/gadget/Kconfig
@@ -134,6 +134,14 @@ config U_SERIAL_CONSOLE
help
   It supports the serial gadget can be used as a console.
 
+config USB_CHARGER
+   bool "USB charger support"
+   select EXTCON
+   help
+ The usb charger driver based on the usb gadget that makes an
+ enhancement to a power driver which can set the current limitation
+ when the usb charger is added or removed.
+
 source "drivers/usb/gadget/udc/Kconfig"
 
 #
diff --git a/drivers/usb/gadget/udc/Makefile b/drivers/usb/gadget/udc/Makefile
index 98e74ed..ede2351 100644
--- a/drivers/usb/gadget/udc/Makefile
+++ b/drivers/usb/gadget/udc/Makefile
@@ -2,6 +2,7 @@
 CFLAGS_trace.o := -I$(src)
 
 udc-core-y := core.o trace.o
+udc-core-$(CONFIG_USB_CHARGER) += charger.o
 
 #
 # USB peripheral controller drivers
diff --git a/drivers/usb/gadget/udc/charger.c b/drivers/usb/gadget/udc/charger.c
new file mode 100644
index 000..462faa1
--- /dev/null
+++ b/drivers/usb/gadget/udc/charger.c
@@ -0,0 +1,697 @@
+/*
+ * charger.c -- USB charger driver
+ *
+ * Copyright (C) 2016 Linaro Ltd.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+/* Default current limit by charger type. */
+#define DEFAULT_SDP_CUR_LIMIT  500
+#define DEFAULT_SDP_CUR_LIMIT_SS   900
+#define DEFAULT_DCP_CUR_LIMIT  1500
+#define DEFAULT_CDP_CUR_LIMIT  1500
+#define DEFAULT_ACA_CUR_LIMIT  1500
+
+static DEFINE_IDA(usb_charger_ida);
+static LIST_HEAD(charger_list);
+static DEFINE_MUTEX(charger_lock);
+
+static unsigned int __usb_charger_get_cur_limit(struct usb_charger *uchger);
+
+static struct usb_charger *dev_to_uchger(struct device *dev)
+{
+   return NULL;
+}
+
+/*
+ * charger_current_show() - Show the charger current limit.
+ */
+static ssize_t charger_current_show(struct device *dev,
+   struct device_attribute *attr,
+   char *buf)
+{
+   struct usb_charger *uchger = dev_to_uchger(dev);
+
+   return sprintf(buf, "%u\n", __usb_charger_get_cur_limit(uchger));
+}
+static DEVICE_ATTR_RO(charger_current);
+
+/*
+ * charger_type_show() - Show the charger type.
+ *
+ * It can be SDP/DCP/CDP/ACA type, else for unknown type.
+ */
+static ssize_t charger_type_show(struct device *dev,
+struct device_attribute *attr,
+char *buf)
+{
+   struct usb_charger *uchger = dev_to_uchger(dev);
+   int cnt;
+
+   switch (uchger->type) {
+   case SDP_TYPE:
+   cnt = sprintf(buf, "%s\n", "SDP");
+   break;
+   case DCP_TYPE:
+   cnt = sprintf(buf, "%s\n", "DCP");
+   break;
+   case CDP_TYPE:
+   cnt = sprintf(buf, "%s\n", "CDP");
+   break;
+   case ACA_TYPE:
+   cnt = 

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

[Baolin Wang]

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

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

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

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

Re: [PATCH 3/3] ehci-platform: add the max clock number to 4

[Arnd Bergmann]

On Sunday, July 31, 2016 7:25:36 PM CEST Icenowy Zheng wrote:
> Allwinner A64 EHCI requires 4 clocks to be enabled.
> 
> Signed-off-by: Icenowy Zheng 
> 

Can you say what those four clocks are?

Are you sure that it's not just a case of a clock being
incorrectly described in the clk driver, i.e. you reference
one clock along with its parent here?

Arnd

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