[PATCH v2] usb: dwc3: add disable u2mac linestate check quirk

2017-04-17 Thread William Wu 
This patch adds a quirk to disable USB 2.0 MAC linestate check
during HS transmit. Refer the dwc3 databook, we can use it for
some special platforms if the linestate not reflect the expected
line state(J) during transmission.

When use this quirk, the controller implements a fixed 40-bit
TxEndDelay after the packet is given on UTMI and ignores the
linestate during the transmit of a token (during token-to-token
and token-to-data IPGAP).

On some rockchip platforms (e.g. rk3399), it requires to disable
the u2mac linestate check to decrease the SSPLIT token to SETUP
token inter-packet delay from 566ns to 466ns, and fix the issue
that FS/LS devices not recognized if inserted through USB 3.0 HUB.

Signed-off-by: William Wu 
---
Changes in v2:
- fix coding style

 Documentation/devicetree/bindings/usb/dwc3.txt |  2 ++
 drivers/usb/dwc3/core.c| 14 ++
 drivers/usb/dwc3/core.h|  4 
 3 files changed, 16 insertions(+), 4 deletions(-)

diff --git a/Documentation/devicetree/bindings/usb/dwc3.txt 
b/Documentation/devicetree/bindings/usb/dwc3.txt
index f658f39..6a89f0c 100644
--- a/Documentation/devicetree/bindings/usb/dwc3.txt
+++ b/Documentation/devicetree/bindings/usb/dwc3.txt
@@ -45,6 +45,8 @@ Optional properties:
a free-running PHY clock.
  - snps,dis-del-phy-power-chg-quirk: when set core will change PHY power
from P0 to P1/P2/P3 without delay.
+ - snps,tx-ipgap-linecheck-dis-quirk: when set, disable u2mac linestate check
+   during HS transmit.
  - snps,is-utmi-l1-suspend: true when DWC3 asserts output signal
utmi_l1_suspend_n, false when asserts utmi_sleep_n
  - snps,hird-threshold: HIRD threshold
diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c
index 455d89a..03429c5 100644
--- a/drivers/usb/dwc3/core.c
+++ b/drivers/usb/dwc3/core.c
@@ -796,15 +796,19 @@ static int dwc3_core_init(struct dwc3 *dwc)
dwc3_writel(dwc->regs, DWC3_GUCTL2, reg);
}
 
+   reg = dwc3_readl(dwc->regs, DWC3_GUCTL1);
+
/*
 * Enable hardware control of sending remote wakeup in HS when
 * the device is in the L1 state.
 */
-   if (dwc->revision >= DWC3_REVISION_290A) {
-   reg = dwc3_readl(dwc->regs, DWC3_GUCTL1);
+   if (dwc->revision >= DWC3_REVISION_290A)
reg |= DWC3_GUCTL1_DEV_L1_EXIT_BY_HW;
-   dwc3_writel(dwc->regs, DWC3_GUCTL1, reg);
-   }
+
+   if (dwc->tx_ipgap_linecheck_dis_quirk)
+   reg |= DWC3_GUCTL1_TX_IPGAP_LINECHECK_DIS;
+
+   dwc3_writel(dwc->regs, DWC3_GUCTL1, reg);
 
return 0;
 
@@ -1023,6 +1027,8 @@ static void dwc3_get_properties(struct dwc3 *dwc)
"snps,dis-u2-freeclk-exists-quirk");
dwc->dis_del_phy_power_chg_quirk = device_property_read_bool(dev,
"snps,dis-del-phy-power-chg-quirk");
+   dwc->tx_ipgap_linecheck_dis_quirk = device_property_read_bool(dev,
+   "snps,tx-ipgap-linecheck-dis-quirk");
 
dwc->tx_de_emphasis_quirk = device_property_read_bool(dev,
"snps,tx_de_emphasis_quirk");
diff --git a/drivers/usb/dwc3/core.h b/drivers/usb/dwc3/core.h
index 981c77f..3c2537b 100644
--- a/drivers/usb/dwc3/core.h
+++ b/drivers/usb/dwc3/core.h
@@ -204,6 +204,7 @@
 #define DWC3_GCTL_DSBLCLKGTNG  BIT(0)
 
 /* Global User Control 1 Register */
+#define DWC3_GUCTL1_TX_IPGAP_LINECHECK_DIS BIT(28)
 #define DWC3_GUCTL1_DEV_L1_EXIT_BY_HW  BIT(24)
 
 /* Global USB2 PHY Configuration Register */
@@ -850,6 +851,8 @@ struct dwc3_scratchpad_array {
  * provide a free-running PHY clock.
  * @dis_del_phy_power_chg_quirk: set if we disable delay phy power
  * change quirk.
+ * @tx_ipgap_linecheck_dis_quirk: set if we disable u2mac linestate
+ * check during HS transmit.
  * @tx_de_emphasis_quirk: set if we enable Tx de-emphasis quirk
  * @tx_de_emphasis: Tx de-emphasis value
  * 0   - -6dB de-emphasis
@@ -1004,6 +1007,7 @@ struct dwc3 {
unsigneddis_rxdet_inp3_quirk:1;
unsigneddis_u2_freeclk_exists_quirk:1;
unsigneddis_del_phy_power_chg_quirk:1;
+   unsignedtx_ipgap_linecheck_dis_quirk:1;
 
unsignedtx_de_emphasis_quirk:1;
unsignedtx_de_emphasis:2;
-- 
2.0.0


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

[PATCH] usb: dwc3: add disable u2mac linestate check quirk

2017-04-17 Thread William Wu 
This patch adds a quirk to disable USB 2.0 MAC linestate check
during HS transmit. Refer the dwc3 databook, we can use it for
some special platforms if the linestate not reflect the expected
line state(J) during transmission.

When use this quirk, the controller implements a fixed 40-bit
TxEndDelay after the packet is given on UTMI and ignores the
linestate during the transmit of a token (during token-to-token
and token-to-data IPGAP).

On some rockchip platforms (e.g. rk3399), it requires to disable
the u2mac linestate check to decrease the SSPLIT token to SETUP
token inter-packet delay from 566ns to 466ns, and fix the issue
that FS/LS devices not recognized if inserted through USB 3.0 HUB.

Signed-off-by: William Wu 
---
 Documentation/devicetree/bindings/usb/dwc3.txt |  2 ++
 drivers/usb/dwc3/core.c| 14 ++
 drivers/usb/dwc3/core.h|  4 
 3 files changed, 16 insertions(+), 4 deletions(-)

diff --git a/Documentation/devicetree/bindings/usb/dwc3.txt 
b/Documentation/devicetree/bindings/usb/dwc3.txt
index f658f39..6a89f0c 100644
--- a/Documentation/devicetree/bindings/usb/dwc3.txt
+++ b/Documentation/devicetree/bindings/usb/dwc3.txt
@@ -45,6 +45,8 @@ Optional properties:
a free-running PHY clock.
  - snps,dis-del-phy-power-chg-quirk: when set core will change PHY power
from P0 to P1/P2/P3 without delay.
+ - snps,tx-ipgap-linecheck-dis-quirk: when set, disable u2mac linestate check
+   during HS transmit.
  - snps,is-utmi-l1-suspend: true when DWC3 asserts output signal
utmi_l1_suspend_n, false when asserts utmi_sleep_n
  - snps,hird-threshold: HIRD threshold
diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c
index 455d89a..22e0c35 100644
--- a/drivers/usb/dwc3/core.c
+++ b/drivers/usb/dwc3/core.c
@@ -796,15 +796,19 @@ static int dwc3_core_init(struct dwc3 *dwc)
dwc3_writel(dwc->regs, DWC3_GUCTL2, reg);
}
 
+   reg = dwc3_readl(dwc->regs, DWC3_GUCTL1);
+
/*
 * Enable hardware control of sending remote wakeup in HS when
 * the device is in the L1 state.
 */
-   if (dwc->revision >= DWC3_REVISION_290A) {
-   reg = dwc3_readl(dwc->regs, DWC3_GUCTL1);
+   if (dwc->revision >= DWC3_REVISION_290A)
reg |= DWC3_GUCTL1_DEV_L1_EXIT_BY_HW;
-   dwc3_writel(dwc->regs, DWC3_GUCTL1, reg);
-   }
+
+   if (dwc->tx_ipgap_linecheck_dis_quirk)
+   reg |= DWC3_GUCTL1_TX_IPGAP_LINECHECK_DIS;
+
+   dwc3_writel(dwc->regs, DWC3_GUCTL1, reg);
 
return 0;
 
@@ -1023,6 +1027,8 @@ static void dwc3_get_properties(struct dwc3 *dwc)
"snps,dis-u2-freeclk-exists-quirk");
dwc->dis_del_phy_power_chg_quirk = device_property_read_bool(dev,
"snps,dis-del-phy-power-chg-quirk");
+dwc->tx_ipgap_linecheck_dis_quirk = device_property_read_bool(dev,
+   "snps,tx-ipgap-linecheck-dis-quirk");
 
dwc->tx_de_emphasis_quirk = device_property_read_bool(dev,
"snps,tx_de_emphasis_quirk");
diff --git a/drivers/usb/dwc3/core.h b/drivers/usb/dwc3/core.h
index 981c77f..3c2537b 100644
--- a/drivers/usb/dwc3/core.h
+++ b/drivers/usb/dwc3/core.h
@@ -204,6 +204,7 @@
 #define DWC3_GCTL_DSBLCLKGTNG  BIT(0)
 
 /* Global User Control 1 Register */
+#define DWC3_GUCTL1_TX_IPGAP_LINECHECK_DIS BIT(28)
 #define DWC3_GUCTL1_DEV_L1_EXIT_BY_HW  BIT(24)
 
 /* Global USB2 PHY Configuration Register */
@@ -850,6 +851,8 @@ struct dwc3_scratchpad_array {
  * provide a free-running PHY clock.
  * @dis_del_phy_power_chg_quirk: set if we disable delay phy power
  * change quirk.
+ * @tx_ipgap_linecheck_dis_quirk: set if we disable u2mac linestate
+ * check during HS transmit.
  * @tx_de_emphasis_quirk: set if we enable Tx de-emphasis quirk
  * @tx_de_emphasis: Tx de-emphasis value
  * 0   - -6dB de-emphasis
@@ -1004,6 +1007,7 @@ struct dwc3 {
unsigneddis_rxdet_inp3_quirk:1;
unsigneddis_u2_freeclk_exists_quirk:1;
unsigneddis_del_phy_power_chg_quirk:1;
+   unsignedtx_ipgap_linecheck_dis_quirk:1;
 
unsignedtx_de_emphasis_quirk:1;
unsignedtx_de_emphasis:2;
-- 
2.0.0


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

Re: [PATCH] usb: Make sure usb/phy/of gets built-in

2017-04-17 Thread Frank Rowand 
On 04/13/17 05:33, Alexey Brodkin wrote:
> DWC3 driver uses of_usb_get_phy_mode() which is
> implemented in drivers/usb/phy/of.c and in bare minimal
> configuration it might not be pulled in kernel binary.
> 
> In case of ARC or ARM this could be easily reproduced with
> "allnodefconfig" +CONFIG_USB=m +CONFIG_USB_DWC3=m.
> 
> On building all ends-up with:
> -->8--
>   Kernel: arch/arm/boot/Image is ready
>   Kernel: arch/arm/boot/zImage is ready
>   Building modules, stage 2.
>   MODPOST 5 modules
> ERROR: "of_usb_get_phy_mode" [drivers/usb/dwc3/dwc3.ko] undefined!
> make[1]: *** [__modpost] Error 1
> make: *** [modules] Error 2
> -->8--
> 
> Signed-off-by: Alexey Brodkin 
> Cc: Greg Kroah-Hartman 
> Cc: Masahiro Yamada 
> Cc: Geert Uytterhoeven 
> Cc: Nicolas Pitre 
> Cc: Thomas Gleixner 
> Cc: Felipe Balbi 
> Cc: Felix Fietkau 
> Cc: Jeremy Kerr 
> Cc: linux-snps-...@lists.infradead.org
> Cc: sta...@vger.kernel.org
> ---
>  drivers/Makefile | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/drivers/Makefile b/drivers/Makefile
> index 2eced9afba53..8f8bdc9e3d29 100644
> --- a/drivers/Makefile
> +++ b/drivers/Makefile
> @@ -104,6 +104,7 @@ obj-$(CONFIG_USB_PHY) += usb/
>  obj-$(CONFIG_USB)+= usb/
>  obj-$(CONFIG_PCI)+= usb/
>  obj-$(CONFIG_USB_GADGET) += usb/

> +obj-$(CONFIG_OF) += usb/

Would CONFIG_USB_SUPPORT make more sense? (And does it work?)


>  obj-$(CONFIG_SERIO)  += input/serio/
>  obj-$(CONFIG_GAMEPORT)   += input/gameport/
>  obj-$(CONFIG_INPUT)  += input/
> 

--
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] Partially revert "usb: Kconfig: using select for USB_COMMON dependency"

2017-04-17 Thread Ben Hutchings 
This reverts commit cb9c1cfc86926d0e86d19c8e34f6c23458cd3478 for
USB_LED_TRIG.  This config symbol has bool type and enables extra code
in usb_common itself, not a separate driver.  Enabling it should not
force usb_common to be built-in!

Fixes: cb9c1cfc8692 ("usb: Kconfig: using select for USB_COMMON dependency")
Signed-off-by: Ben Hutchings 
---
 drivers/usb/Kconfig | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/drivers/usb/Kconfig b/drivers/usb/Kconfig
index fbe493d44e81..8270abe6c677 100644
--- a/drivers/usb/Kconfig
+++ b/drivers/usb/Kconfig
@@ -154,8 +154,7 @@ source "drivers/usb/gadget/Kconfig"
 
 config USB_LED_TRIG
bool "USB LED Triggers"
-   depends on LEDS_CLASS && LEDS_TRIGGERS
-   select USB_COMMON
+   depends on LEDS_CLASS && USB_COMMON && LEDS_TRIGGERS
help
  This option adds LED triggers for USB host and/or gadget activity.
 


signature.asc
Description: Digital signature

[GIT PULL] usb: chipidea changes for v4.12-rc1

2017-04-17 Thread Peter Chen 
The following changes since commit 4495c08e84729385774601b5146d51d9e5849f81:

  Linux 4.11-rc2 (2017-03-12 14:47:08 -0700)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/peter.chen/usb.git/ 
tags/usb-ci-v4.12-rc1

for you to fetch changes up to a932a8041ff9941a244619555f1c75ecf299f662:

  usb: chipidea: core: add sysfs group (2017-04-14 09:26:37 +0800)


Two changes for this v4.12-rc1:
- Add sysfs entry for role switch
- Update gadget state after gadget back from suspend


Li Jun (1):
  usb: chipidea: udc: update gadget state after bus resume

Peter Chen (1):
  usb: chipidea: core: add sysfs group

 .../ABI/testing/sysfs-platform-chipidea-usb2   |  9 +++
 drivers/usb/chipidea/ci.h  |  2 +
 drivers/usb/chipidea/core.c| 64 +-
 drivers/usb/chipidea/udc.c | 23 +---
 4 files changed, 87 insertions(+), 11 deletions(-)
 create mode 100644 Documentation/ABI/testing/sysfs-platform-chipidea-usb2
--
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: Ops in usb stack

2017-04-17 Thread Lars Melin 

On 2017-04-18 02:06, Anders Eriksson wrote:

[1.056684] dwc_otg: version 3.00a 10-AUG-2012 (platform bus)


The pesky dwc_otg driver is the reason for your problem, it is not
part of the official 4.9 kernel.
It was replaced by dwc2 some two years ago.


/Lars

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

Regression: asix: BISECTED suspend crash - Dell XPS13-9360

2017-04-17 Thread Zhang Rui 
Hi, Freddy,

We have a bug report that system suspend crashes if the asix
USB/ETHERNET adapter is connected.
https://bugzilla.kernel.org/show_bug.cgi?id=195431


And the bisect result shows that 
d9fe64e511144c1ee7d7555b4111f09dde9692ef is the first bad commit.

commit d9fe64e511144c1ee7d7555b4111f09dde9692ef
Author: Robert Foss 
Date:   Mon Aug 29 09:32:15 2016 -0400

net: asix: Add in_pm parameter

From: Freddy Xin 

In order to R/W registers in suspend/resume functions, in_pm flags
are
added to some functions to determine whether the nopm version of
usb
functions is called.

Save BMCR and ANAR PHY registers in suspend function and restore
them
in resume function.

Reset HW in resume function to ensure the PHY works correctly.

Signed-off-by: Freddy Xin 
Signed-off-by: Robert Foss 
Tested-by: Robert Foss 
Signed-off-by: David S. Miller 

can you please take a look at this problem?

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

Re: usb: dwc2: NMI watchdog: BUG: soft lockup - CPU#0 stuck for 146s

2017-04-17 Thread Heiko Stuebner 
Hi Stefan,

Am Montag, 17. April 2017, 13:05:40 CEST schrieb Stefan Wahren:
> > Stefan Wahren  hat am 31. Oktober 2016 um 21:34 
> > geschrieben:
> > 
> > 
> > I inspired by this issue [1] i build up a slightly modified setup with a
> > Raspberry Pi B (mainline kernel 4.9rc3), a powered 7 port USB hub and 5 
> > Prolific
> > PL2303 USB to serial convertors. I modified the usb_test for dwc2 [2], which
> > only tries to open all ttyUSB devices one after the other. 
> > 
> > Unfortunately the complete system stuck after opening the first ttyUSB 
> > device (
> > heartbeat LED stop blinking, no reaction to debug UART). The only way to
> > reanimate the system is to powerdown the USB hub with the USB to serial
> > convertors.
> > 
> > [1] - https://github.com/raspberrypi/linux/issues/1692
> > [2] - https://gist.github.com/lategoodbye/dd0d30af27b6f101b03d5923b279dbaa
> 
> since this issue still exists with 4.11 (even without or with microframe 
> scheduler enabled), i want to ask some additional questions:
> 
> Is this issue reproducible with other dwc2 platforms than bcm2835?
> Does the soft lockup also occurs after opening the second serial convertor or 
> later?

A friend of mine uses a rk3288-veyron-jerry as work-device also with a
slightly interesting usb topology (multiple hubs, keyboard, mouse,
smartcard-reader and printer) but not usb-serial adapters.

On the 4.9 that is currently on there, the system sometimes locks up when
trying to print things, sadly there is no serial console on it and the lockup
also kills the whole ui and we haven't managed to dig deeper yet.
[cpufreq is set to 600MHz minimum to mitigate the worst dwc2 issues].


Heiko


> > 
> > pi@raspberrypi:~$ lsusb -t
> > /:  Bus 01.Port 1: Dev 1, Class=root_hub, Driver=dwc2/1p, 480M
> > |__ Port 1: Dev 2, If 0, Class=Hub, Driver=hub/3p, 480M
> > |__ Port 1: Dev 3, If 0, Class=Vendor Specific Class, 
> > Driver=smsc95xx,
> > 480M
> > |__ Port 2: Dev 11, If 0, Class=Hub, Driver=hub/4p, 480M
> > |__ Port 3: Dev 15, If 0, Class=Vendor Specific Class,
> > Driver=pl2303, 12M
> > |__ Port 1: Dev 12, If 0, Class=Hub, Driver=hub/4p, 480M
> > |__ Port 2: Dev 14, If 0, Class=Vendor Specific Class,
> > Driver=pl2303, 12M
> > |__ Port 3: Dev 16, If 0, Class=Vendor Specific Class,
> > Driver=pl2303, 12M
> > |__ Port 4: Dev 17, If 0, Class=Vendor Specific Class,
> > Driver=pl2303, 12M
> > |__ Port 2: Dev 13, If 0, Class=Vendor Specific Class,
> > Driver=pl2303, 12M
> > 
> > pi@raspberrypi:~$ ./usb_test
> > idle
> > opening [/dev/ttyUSB0] ok
> > [  232.658768] NMI watchdog: BUG: soft lockup - CPU#0 stuck for 146s!
> > [usb_test:522]
> > [  232.678443] Modules linked in: pwm_bcm2835 vchiq(C)
> > [  232.678481] CPU: 0 PID: 522 Comm: usb_test Tainted: G C
> >  4.9.0-rc3+ #33
> > [  232.678486] Hardware name: BCM2835
> > [  232.678498] task: cab54e40 task.stack: c688c000
> > [  232.678520] PC is at __do_softirq+0x68/0x2a8
> > [  232.678538] LR is at irq_exit+0xb8/0x120
> > [  232.678552] pc : []lr : []psr: 6113
> > sp : c688da60  ip : c688daa8  fp : c688daa4
> > [  232.678560] r10: c0b7f800  r9 : c688c000  r8 : 0040
> > [  232.678567] r7 : 000a  r6 : cb802400  r5 :   r4 : 0001
> > [  232.678575] r3 :   r2 : 0100  r1 : 0040  r0 : 
> > [  232.678585] Flags: nZCv  IRQs on  FIQs on  Mode SVC_32  ISA ARM  Segment 
> > none
> > [  232.678593] Control: 00c5387d  Table: 068a4008  DAC: 0051
> > [  232.678604] CPU: 0 PID: 522 Comm: usb_test Tainted: G C
> >  4.9.0-rc3+ #33
> > [  232.678609] Hardware name: BCM2835
> > [  232.678667] [] (unwind_backtrace) from []
> > (show_stack+0x20/0x24)
> > [  232.678695] [] (show_stack) from []
> > (dump_stack+0x20/0x28)
> > [  232.678718] [] (dump_stack) from [] 
> > (show_regs+0x1c/0x20)
> > [  232.678752] [] (show_regs) from []
> > (watchdog_timer_fn+0x140/0x19c)
> > [  232.678779] [] (watchdog_timer_fn) from []
> > (__hrtimer_run_queues.constprop.3+0xec/0x210)
> > [  232.678798] [] (__hrtimer_run_queues.constprop.3) from 
> > []
> > (hrtimer_interrupt+0xa4/0x1cc)
> > [  232.678827] [] (hrtimer_interrupt) from []
> > (bcm2835_time_interrupt+0x40/0x48)
> > [  232.678865] [] (bcm2835_time_interrupt) from []
> > (__handle_irq_event_percpu+0x68/0x1b8)
> > [  232.678891] [] (__handle_irq_event_percpu) from []
> > (handle_irq_event_percpu+0x2c/0x68)
> > [  232.678915] [] (handle_irq_event_percpu) from []
> > (handle_irq_event+0x38/0x4c)
> > [  232.678939] [] (handle_irq_event) from []
> > (handle_level_irq+0xc4/0xf8)
> > [  232.678960] [] (handle_level_irq) from []
> > (generic_handle_irq+0x28/0x38)
> > [  232.678983] [] (generic_handle_irq) from []
> > (__handle_domain_irq+0x90/0xb8)
> > [  232.679004] [] (__handle_domain_irq) from []
> > (bcm2835_handle_irq+0x30/0x48)
> > [  232.679022] [] (bcm2835_handle_irq) from []
> >

Re: usb: dwc2: NMI watchdog: BUG: soft lockup - CPU#0 stuck for 146s

2017-04-17 Thread Doug Anderson 
Hi,

On Mon, Apr 17, 2017 at 4:05 AM, Stefan Wahren  wrote:
> Hi,
>
>> Stefan Wahren  hat am 31. Oktober 2016 um 21:34 
>> geschrieben:
>>
>>
>> I inspired by this issue [1] i build up a slightly modified setup with a
>> Raspberry Pi B (mainline kernel 4.9rc3), a powered 7 port USB hub and 5 
>> Prolific
>> PL2303 USB to serial convertors. I modified the usb_test for dwc2 [2], which
>> only tries to open all ttyUSB devices one after the other.
>>
>> Unfortunately the complete system stuck after opening the first ttyUSB 
>> device (
>> heartbeat LED stop blinking, no reaction to debug UART). The only way to
>> reanimate the system is to powerdown the USB hub with the USB to serial
>> convertors.
>>
>> [1] - https://github.com/raspberrypi/linux/issues/1692
>> [2] - https://gist.github.com/lategoodbye/dd0d30af27b6f101b03d5923b279dbaa
>
> since this issue still exists with 4.11 (even without or with microframe 
> scheduler enabled), i want to ask some additional questions:
>
> Is this issue reproducible with other dwc2 platforms than bcm2835?

+Edmund Szeto, who I seem to remember emailing me about similar
questions in the past.


> Does the soft lockup also occurs after opening the second serial convertor or 
> later?

I don't have serial converters easily available to me, but back in the
day when I was stressing things out on rk3288 I never saw anything
this bad.  ...of course, on rk3288 we've got 4 A17 cores running
really fast, so possibly just being slower is what causes your
problems here?

I will make the following observations:

1. With dwc2 you often end up in the situation where you need to
service an interrupt every 125 uS.  If servicing that interrupt takes
anywhere near 125 uS in the common case then you'll be in trouble.

===

2. When I was testing on rk3288 (on kernel 3.14) I did see occasions
where uvc_video_complete() could sometimes take > 125 uS.  It's been a
long time now, but if I remember correctly this had to do with the
fact that the URB buffers were allocated in a way where you had to
access them non-cached and this was super duper slow.  In my
particular case I could "fix" it by adjusting UVC_MAX_PACKETS
(crosreview.com/321932).  ...and I had some timing code in
crosreview.com/321980.

Again, it was a long time ago, but elsewhere I have written down:

-

Specifically:
* The USB "complete" functions are called with local interrupts
disabled.  Specifically see __usb_hcd_giveback_urb().
* I see calls to uvc_video_complete() that easily take > 125us.

Unfortunately the interrupts disabled while uvc_video_complete() is
called are always the interrupts for the same CPU that's dealing with
the normal dwc2 USB interrupts.

--

Ugh.  This may be the memcpy() as others have found:

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

...looks like the issue is that the driver is allocating memory that's
supposed to be DMA coherent and copying from this memory is slow.

-

You could probably pick my timing patch and then see if you're
actually hitting cases like this, I guess?

===

3. Are you running CPUFreq by chance?

...back in the day we had a bug on rk3288 where we were temporarily
running the CPU as slow as 8 MHz for a short while during a CPUFreq
transition.  If you happened to get a dwc2 interrupt while at this
speed then you were in trouble.


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

Re: Regression - Linux 4.9: ums_eneub6250 broken: transfer buffer not dma capable - Trace

2017-04-17 Thread Andreas Hartmann 
On 04/17/2017 at 09:10 PM, Alan Stern wrote:
> On Mon, 17 Apr 2017, Greg KH wrote:
> 
>> On Mon, Apr 17, 2017 at 11:28:44AM +0200, Andreas Hartmann wrote:
>>> Hello!
>>>
>>> Since Linux 4.9, ums_eneub6250 is broken. It's working fine if
>>> CONFIG_VMAP_STACK is disabled.
>>>
>>> I would be glad if it would be fixed.
>>
>> Ah, nice catch, thanks for finding this.
>>
>> Does the patch below fix this for you?
>>
>> thanks,
>>
>> greg k-h
>>
>> -
>>
>>
>> diff --git a/drivers/usb/storage/ene_ub6250.c 
>> b/drivers/usb/storage/ene_ub6250.c
>> index 369f3c24815a..6a227b142146 100644
>> --- a/drivers/usb/storage/ene_ub6250.c
>> +++ b/drivers/usb/storage/ene_ub6250.c
>> @@ -2180,21 +2180,29 @@ static int ene_sd_init(struct us_data *us)
> 
>> @@ -2303,7 +2311,7 @@ static int ene_ub6250_probe(struct usb_interface *intf,
> 
> Good start, but there are five (!) other places in this driver where
> the same bug occurs, at lines 904, 1350, 1577, 2088, and 2157.  Would
> you like to fix them too?
> 
> Maybe it would be easier for the driver to allocate a single 512-byte 
> buffer at the start, and use it for all of these I/O requests.

Yes, it doesn't work yet:


Apr 17 21:57:41 notebook2 kernel: usb 1-1.1: new high-speed USB device number 3 
using ehci-pci
Apr 17 21:57:42 notebook2 kernel: usb 1-1.1: New USB device found, 
idVendor=0cf2, idProduct=6250
Apr 17 21:57:42 notebook2 kernel: usb 1-1.1: New USB device strings: Mfr=1, 
Product=2, SerialNumber=4
Apr 17 21:57:42 notebook2 kernel: usb 1-1.1: Product: UB6250   
Apr 17 21:57:42 notebook2 kernel: usb 1-1.1: Manufacturer: ENE Flash  
Apr 17 21:57:42 notebook2 kernel: usb 1-1.1: SerialNumber: 606569746801
Apr 17 21:57:42 notebook2 mtp-probe[2166]: checking bus 1, device 3: 
"/sys/devices/pci:00/:00:1a.0/usb1/1-1/1-1.1"
Apr 17 21:57:42 notebook2 mtp-probe[2166]: bus: 1, device: 3 was not an MTP 
device
Apr 17 21:57:43 notebook2 kernel: usbcore: registered new interface driver 
usb-storage
Apr 17 21:57:43 notebook2 kernel: usbcore: registered new interface driver uas
Apr 17 21:57:43 notebook2 kernel: ums_eneub6250 1-1.1:1.0: USB Mass Storage 
device detected
Apr 17 21:57:43 notebook2 kernel: scsi host6: usb-storage 1-1.1:1.0
Apr 17 21:57:43 notebook2 kernel: usbcore: registered new interface driver 
ums_eneub6250
Apr 17 21:57:44 notebook2 kernel: usb 1-1.1: direct-loading 
ene-ub6250/sd_init1.bin
Apr 17 21:57:44 notebook2 kernel: usb 1-1.1: direct-loading 
ene-ub6250/sd_init2.bin
Apr 17 21:57:44 notebook2 kernel: [ cut here ]
Apr 17 21:57:44 notebook2 kernel: WARNING: CPU: 2 PID: 2182 at 
../drivers/usb/core/hcd.c:1587 usb_hcd_map_urb_for_dma+0x4ba/0x4f0 [usbcore]
Apr 17 21:57:44 notebook2 kernel: transfer buffer not dma capable
Apr 17 21:57:44 notebook2 kernel: Modules linked in: ums_eneub6250 uas 
usb_storage binfmt_misc snd_hda_codec_hdmi snd_hda_codec_realtek 
snd_hda_codec_generic snd_hda_intel snd_hda_codec snd_hda_core snd_hwdep 
snd_pcm_oss snd_pcm iTCO_wdt iTCO_vendor_support msi_wmi snd_s
eq intel_powerclamp coretemp snd_seq_device kvm_intel snd_timer msi_laptop 
sparse_keymap rfkill kvm snd_mixer_oss ac battery irqbypass snd joydev r8169 
thermal mii soundcore mei_me i2c_i801 intel_ips lpc_ich mei shpchp mfd_core 
i2c_smbus fjes acpi_cpufreq pcspkr tpm_tis tpm_tis_core tpm fan dm_crypt 
crc32c_intel serio_raw sr_mod cdrom i915 ehci_pci i2c_algo_bit ehci_hcd 
drm_kms_helper syscopyarea sysfillrect sysimgblt usbcore fb_sys_fops drm wmi 
button video dm_mirror dm_region_hash dm_log sg dm_multipath dm_mod 
scsi_dh_rdac scsi_dh_emc scsi_dh_alua
Apr 17 21:57:44 notebook2 kernel: CPU: 2 PID: 2182 Comm: usb-storage Not 
tainted 4.9.22-1.2-default #1
Apr 17 21:57:44 notebook2 kernel: Hardware name: Micro-Star International 
CR620/CR620, BIOS E1681IMS VER.10C 04/12/2011
Apr 17 21:57:44 notebook2 kernel:  a0c840dc77c0 813c856a 
a0c840dc7810 
Apr 17 21:57:44 notebook2 kernel:  a0c840dc7800 81085c71 
0633810bd0ee 92e6fbfa7b40
Apr 17 21:57:44 notebook2 kernel:   0200 
0002 92e74aecf800
Apr 17 21:57:44 notebook2 kernel: Call Trace:
Apr 17 21:57:44 notebook2 kernel:  [] dump_stack+0x63/0x89
Apr 17 21:57:44 notebook2 kernel:  [] __warn+0xd1/0xf0
Apr 17 21:57:44 notebook2 kernel:  [] 
warn_slowpath_fmt+0x4f/0x60
Apr 17 21:57:44 notebook2 kernel:  [] ? 
put_prev_entity+0x48/0x720
Apr 17 21:57:44 notebook2 kernel:  [] 
usb_hcd_map_urb_for_dma+0x4ba/0x4f0 [usbcore]
Apr 17 21:57:44 notebook2 kernel:  [] ? 
finish_task_switch+0x78/0x1e0
Apr 17 21:57:44 notebook2 kernel:  [] 
usb_hcd_submit_urb+0x1c9/0xb30 [usbcore]
Apr 17 21:57:44 notebook2 kernel:  [] ? schedule+0x3d/0x90
Apr 17 21:57:44 notebook2 kernel:  [] ? 
schedule_timeout+0x220/0x3c0
Apr 17 21:57:44 notebook2 kernel:  [] 
usb_submit_urb.part.6+0x295/0x550 [usbcore]
Apr 17 21:57:44 notebook2 kernel:  [] 
usb_submit_urb+0x34/0x70 [usbcore]
Apr 17 21:57:44 notebook2 kernel:  []

Re: Regression - Linux 4.9: ums_eneub6250 broken: transfer buffer not dma capable - Trace

2017-04-17 Thread Alan Stern 
On Mon, 17 Apr 2017, Greg KH wrote:

> On Mon, Apr 17, 2017 at 11:28:44AM +0200, Andreas Hartmann wrote:
> > Hello!
> > 
> > Since Linux 4.9, ums_eneub6250 is broken. It's working fine if
> > CONFIG_VMAP_STACK is disabled.
> > 
> > I would be glad if it would be fixed.
> 
> Ah, nice catch, thanks for finding this.
> 
> Does the patch below fix this for you?
> 
> thanks,
> 
> greg k-h
> 
> -
> 
> 
> diff --git a/drivers/usb/storage/ene_ub6250.c 
> b/drivers/usb/storage/ene_ub6250.c
> index 369f3c24815a..6a227b142146 100644
> --- a/drivers/usb/storage/ene_ub6250.c
> +++ b/drivers/usb/storage/ene_ub6250.c
> @@ -2180,21 +2180,29 @@ static int ene_sd_init(struct us_data *us)

> @@ -2303,7 +2311,7 @@ static int ene_ub6250_probe(struct usb_interface *intf,

Good start, but there are five (!) other places in this driver where
the same bug occurs, at lines 904, 1350, 1577, 2088, and 2157.  Would
you like to fix them too?

Maybe it would be easier for the driver to allocate a single 512-byte 
buffer at the start, and use it for all of these I/O requests.

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

Ops in usb stack

2017-04-17 Thread Anders Eriksson 
I get oopses like this rather often on my rpi2. As can be seen it has
quite a bit of USB devices attached and the odd thing is that if I
disconnect either of the tv-capture devices the oopses are gone.

Any ideas what triggers it? I'd be ahppy to try any patches.

The call stack differs between the oopses (some triggered by network
writes, some by dvb reads etc), so I suspect its something to do with
the guts of the usb host driver (and load related).

Br,
Anders


[0.00] Booting Linux on physical CPU 0xf00
[0.00] Linux version 4.9.17-v7+ (r...@rpi2.lan) (gcc version
4.9.4 (Gentoo 4.9.4 p1.0, pie-0.6.4) ) #1 SMP Sun Mar 26 03:12:42 CEST
2017
[0.00] CPU: ARMv7 Processor [410fc075] revision 5 (ARMv7), cr=10c5387d
[0.00] CPU: div instructions available: patching division code
[0.00] CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing
instruction cache
[0.00] OF: fdt:Machine model: Raspberry Pi 2 Model B Rev 1.1
[0.00] cma: Reserved 8 MiB at 0x3a80
[0.00] Memory policy: Data cache writealloc
[0.00] percpu: Embedded 14 pages/cpu @b9f65000 s25600 r8192
d23552 u57344
[0.00] Built 1 zonelists in Zone order, mobility grouping on.
Total pages: 239540
[0.00] Kernel command line: bcm2708_fb.fbwidth=656
bcm2708_fb.fbheight=416 bcm2708_fb.fbswap=1 vc_mem.mem_base=0x3dc0
vc_mem.mem_size=0x3f00  root=/dev/mmcblk0p4 smsc95xx.turbo_mode=N
rootdelay=2 console=ttyAMA0,115200 console=tty0
init=/usr/lib/systemd/systemd ro
[0.00] PID hash table entries: 4096 (order: 2, 16384 bytes)
[0.00] Dentry cache hash table entries: 131072 (order: 7, 524288 bytes)
[0.00] Inode-cache hash table entries: 65536 (order: 6, 262144 bytes)
[0.00] Memory: 936308K/966656K available (7168K kernel code,
483K rwdata, 2012K rodata, 1024K init, 778K bss, 22156K reserved,
8192K cma-reserved)
[0.00] Virtual kernel memory layout:
[0.00] vector  : 0x - 0x1000   (   4 kB)
[0.00] fixmap  : 0xffc0 - 0xfff0   (3072 kB)
[0.00] vmalloc : 0xbb80 - 0xff80   (1088 MB)
[0.00] lowmem  : 0x8000 - 0xbb00   ( 944 MB)
[0.00] modules : 0x7f00 - 0x8000   (  16 MB)
[0.00]   .text : 0x80008000 - 0x8080   (8160 kB)
[0.00]   .init : 0x80b0 - 0x80c0   (1024 kB)
[0.00]   .data : 0x80c0 - 0x80c78fd4   ( 484 kB)
[0.00].bss : 0x80c7a000 - 0x80d3cb64   ( 779 kB)
[0.00] SLUB: HWalign=64, Order=0-3, MinObjects=0, CPUs=4, Nodes=1
[0.00] Hierarchical RCU implementation.
[0.00]  Build-time adjustment of leaf fanout to 32.
[0.00] NR_IRQS:16 nr_irqs:16 16
[0.00] arm_arch_timer: Architected cp15 timer(s) running at
19.20MHz (phys).
[0.00] clocksource: arch_sys_counter: mask: 0xff
max_cycles: 0x46d987e47, max_idle_ns: 440795202767 ns
[0.11] sched_clock: 56 bits at 19MHz, resolution 52ns, wraps
every 4398046511078ns
[0.32] Switching to timer-based delay loop, resolution 52ns
[0.000378] Console: colour dummy device 80x30
[0.001338] console [tty0] enabled
[0.001394] Calibrating delay loop (skipped), value calculated
using timer frequency.. 38.40 BogoMIPS (lpj=192000)
[0.001473] pid_max: default: 32768 minimum: 301
[0.001910] Mount-cache hash table entries: 2048 (order: 1, 8192 bytes)
[0.001966] Mountpoint-cache hash table entries: 2048 (order: 1, 8192 bytes)
[0.003287] Disabling cpuset control group subsystem
[0.003552] CPU: Testing write buffer coherency: ok
[0.003655] ftrace: allocating 22396 entries in 66 pages
[0.058575] CPU0: update cpu_capacity 1024
[0.058654] CPU0: thread -1, cpu 0, socket 15, mpidr 8f00
[0.058753] Setting up static identity map for 0x10 - 0x100034
[0.061958] CPU1: update cpu_capacity 1024
[0.061970] CPU1: thread -1, cpu 1, socket 15, mpidr 8f01
[0.063040] CPU2: update cpu_capacity 1024
[0.063049] CPU2: thread -1, cpu 2, socket 15, mpidr 8f02
[0.064022] CPU3: update cpu_capacity 1024
[0.064031] CPU3: thread -1, cpu 3, socket 15, mpidr 8f03
[0.064147] Brought up 4 CPUs
[0.064347] SMP: Total of 4 processors activated (153.60 BogoMIPS).
[0.064381] CPU: All CPU(s) started in HYP mode.
[0.064410] CPU: Virtualization extensions available.
[0.065591] devtmpfs: initialized
[0.078981] VFP support v0.3: implementor 41 architecture 2 part 30
variant 7 rev 5
[0.079442] clocksource: jiffies: mask: 0x max_cycles:
0x, max_idle_ns: 1911260446275 ns
[0.079522] futex hash table entries: 1024 (order: 4, 65536 bytes)
[0.080344] pinctrl core: initialized pinctrl subsystem
[0.081655] NET: Registered protocol family 16
[0.084189] DMA: preallocated 1024 KiB pool for atomic coherent allocations
[0.094702] hw-breakpoint: found 5 (+1 reserved) breakpoint and

Re: em28xx i2c writing error

2017-04-17 Thread Anders Eriksson 
Hi Frank,


On Sun, Apr 16, 2017 at 7:59 PM, Frank Schäfer
 wrote:
>
> Am 15.04.2017 um 20:28 schrieb Anders Eriksson:
>> Hi Mauro,
>>
>> I've two devices using this driver, and whenever I have them both in
>> use I eventually (between 10K and 100K secs uptime) i2c write errors
>> such as in the log below. If only have one of the devices in use, the
>> machine is stable.
>>
>> The machine never recovers from the error.
>>
>> All help apreciated.
>> -Anders
>>
>>
>>

>> [   45.616358] br0: port 6(vb-work) entered forwarding state
>> [   45.634769] br0: port 6(vb-work) entered forwarding state
>> [   54.045274] br0: port 5(vb-revproxy) entered forwarding state
>> [   60.645283] br0: port 6(vb-work) entered forwarding state
> Did you skip any lines here ? Any usb related messages ?
>
Nope. It ran without any messages up to 93093

>> [93038.637557] em28178 #1: writing to i2c device at 0xc8 failed (error=-5)
>> [93038.737581] em28174 #0: writing to i2c device at 0xd8 failed (error=-5)
> -5 is -EIO, which means the errors occure at usb level (line 176 in
> em28xx-core.c)
> However, the actual error returned by usb_control_msg() might be
> different, because it is passed through usb_translate_errors().
>
> Hth,
> Frank
>

I add linux-usb@ and see who might knwo something. Do you know whom I
should contact wrt usb?

Br,
Anders

>> [93038.746399] i2c i2c-4: cxd2820r: i2c rd failed=-5 reg=10 len=1
>> [93039.247560] em28178 #1: writing to i2c device at 0xc8 failed (error=-5)
>> [93039.447579] em28178 #1: writing to i2c device at 0xc8 failed (error=-5)
>> [93039.647559] em28178 #1: writing to i2c device at 0xc8 failed (error=-5)
>> [93039.847564] em28178 #1: writing to i2c device at 0xc8 failed (error=-5)
>> [93040.047567] em28178 #1: writing to i2c device at 0xc8 failed (error=-5)
>> [93040.157570] em28174 #0: writing to i2c device at 0xd8 failed (error=-5)
>> [93040.165915] i2c i2c-4: cxd2820r: i2c rd failed=-5 reg=10 len=1
>> [93041.047583] em28178 #1: writing to i2c device at 0xc8 failed (error=-5)
>> [93041.167571] em28174 #0: writing to i2c device at 0xd8 failed (error=-5)
>> [93041.175973] i2c i2c-4: cxd2820r: i2c rd failed=-5 reg=10 len=1
>> [93042.047587] em28178 #1: writing to i2c device at 0xc8 failed (error=-5)
>> [93042.177582] em28174 #0: writing to i2c device at 0xd8 failed (error=-5)
>> [93042.185886] i2c i2c-4: cxd2820r: i2c rd failed=-5 reg=10 len=1
>> [93043.047590] em28178 #1: writing to i2c device at 0xc8 failed (error=-5)
>> [93043.187592] em28174 #0: writing to i2c device at 0xd8 failed (error=-5)
>> [93043.195868] i2c i2c-4: cxd2820r: i2c rd failed=-5 reg=10 len=1
>> [93044.047593] em28178 #1: writing to i2c device at 0xc8 failed (error=-5)
>> [93044.197589] em28174 #0: writing to i2c device at 0xd8 failed (error=-5)
>> [93044.205925] i2c i2c-4: cxd2820r: i2c rd failed=-5 reg=10 len=1
>> [93045.047597] em28178 #1: writing to i2c device at 0xc8 failed (error=-5)
>> [93045.207593] em28174 #0: writing to i2c device at 0xd8 failed (error=-5)
>> [93045.215996] i2c i2c-4: cxd2820r: i2c rd failed=-5 reg=10 len=1
>> [93046.117605] em28178 #1: writing to i2c device at 0xc8 failed (error=-5)
>> [93046.217617] em28174 #0: writing to i2c device at 0xd8 failed (error=-5)
>> [93046.226038] i2c i2c-4: cxd2820r: i2c rd failed=-5 reg=10 len=1
>> [93047.127686] em28178 #1: writing to i2c device at 0xc8 failed (error=-5)
>> [93048.127607] em28178 #1: writing to i2c device at 0xc8 failed (error=-5)
>> [93049.127649] em28178 #1: writing to i2c device at 0xc8 failed (error=-5)
>> [93050.127623] em28178 #1: writing to i2c device at 0xc8 failed (error=-5)
>> [93051.127653] em28178 #1: writing to i2c device at 0xc8 failed (error=-5)
>> [93052.127661] em28178 #1: writing to i2c device at 0xc8 failed (error=-5)
>> [93053.127629] em28178 #1: writing to i2c device at 0xc8 failed (error=-5)
>> [93054.127676] em28178 #1: writing to i2c device at 0xc8 failed (error=-5)
>> [93055.127642] em28178 #1: writing to i2c device at 0xc8 failed (error=-5)
>> [93055.567657] em28178 #1: writing to i2c device at 0xc8 failed (error=-5)
>> [93055.627642] em28174 #0: writing to i2c device at 0xd8 failed (error=-5)
>> [93055.635697] i2c i2c-4: cxd2820r: i2c wr failed=-5 reg=85 len=1
>> [93055.737670] em28174 #0: writing to i2c device at 0xd8 failed (error=-5)
>> [93055.745838] i2c i2c-4: cxd2820r: i2c rd failed=-5 reg=10 len=1
>> [93055.767696] em28178 #1: writing to i2c device at 0xc8 failed (error=-5)
>> [93055.937644] em28174 #0: writing to i2c device at 0xd8 failed (error=-5)
>> [93055.945765] i2c i2c-4: cxd2820r: i2c rd failed=-5 reg=10 len=1
>> [93056.357654] em28174 #0: writing to i2c device at 0xd8 failed (error=-5)
>> [93056.365873] i2c i2c-4: cxd2820r: i2c wr failed=-5 reg=85 len=1
>> [93056.557660] em28174 #0: writing to i2c device at 0xd8 failed (error=-5)
>> [93056.565881] i2c i2c-4: cxd2820r: i2c rd failed=-5 reg=10 len=1
>> [93056.767668] em28178 #1: writing to i2c device at 0xc8 failed (error=-5)

Re: Regression - Linux 4.9: ums_eneub6250 broken: transfer buffer not dma capable - Trace

2017-04-17 Thread Greg KH 
On Mon, Apr 17, 2017 at 11:28:44AM +0200, Andreas Hartmann wrote:
> Hello!
> 
> Since Linux 4.9, ums_eneub6250 is broken. It's working fine if
> CONFIG_VMAP_STACK is disabled.
> 
> I would be glad if it would be fixed.

Ah, nice catch, thanks for finding this.

Does the patch below fix this for you?

thanks,

greg k-h

-


diff --git a/drivers/usb/storage/ene_ub6250.c b/drivers/usb/storage/ene_ub6250.c
index 369f3c24815a..6a227b142146 100644
--- a/drivers/usb/storage/ene_ub6250.c
+++ b/drivers/usb/storage/ene_ub6250.c
@@ -2180,21 +2180,29 @@ static int ene_sd_init(struct us_data *us)
 static int ene_init(struct us_data *us)
 {
int result;
-   u8  misc_reg03 = 0;
+   u8 *misc_reg03;
+   u8 reg03;
struct ene_ub6250_info *info = (struct ene_ub6250_info *)(us->extra);
 
-   result = ene_get_card_type(us, REG_CARD_STATUS, _reg03);
+   misc_reg03 = kzalloc(1, GFP_KERNEL);
+   if (!misc_reg03)
+   return -ENOMEM;
+
+   result = ene_get_card_type(us, REG_CARD_STATUS, misc_reg03);
+   reg03 = misc_reg03[0];
+   kfree(misc_reg03);
+
if (result != USB_STOR_XFER_GOOD)
return USB_STOR_TRANSPORT_ERROR;
 
-   if (misc_reg03 & 0x01) {
+   if (reg03 & 0x01) {
if (!info->SD_Status.Ready) {
result = ene_sd_init(us);
if (result != USB_STOR_XFER_GOOD)
return USB_STOR_TRANSPORT_ERROR;
}
}
-   if (misc_reg03 & 0x02) {
+   if (reg03 & 0x02) {
if (!info->MS_Status.Ready) {
result = ene_ms_init(us);
if (result != USB_STOR_XFER_GOOD)
@@ -2303,7 +2311,7 @@ static int ene_ub6250_probe(struct usb_interface *intf,
 const struct usb_device_id *id)
 {
int result;
-   u8  misc_reg03 = 0;
+   u8 *misc_reg03;
struct us_data *us;
 
result = usb_stor_probe1(, intf, id,
@@ -2328,18 +2336,26 @@ static int ene_ub6250_probe(struct usb_interface *intf,
if (result)
return result;
 
+   misc_reg03 = kzalloc(1, GFP_KERNEL);
+   if (!misc_reg03) {
+   usb_stor_disconnect(intf);
+   return -ENOMEM;
+   }
+
/* probe card type */
-   result = ene_get_card_type(us, REG_CARD_STATUS, _reg03);
+   result = ene_get_card_type(us, REG_CARD_STATUS, misc_reg03);
if (result != USB_STOR_XFER_GOOD) {
+   kfree(misc_reg03);
usb_stor_disconnect(intf);
return USB_STOR_TRANSPORT_ERROR;
}
 
-   if (!(misc_reg03 & 0x01)) {
+   if (!(misc_reg03[0] & 0x01)) {
pr_info("ums_eneub6250: This driver only supports SD/MS cards. "
"It does not support SM cards.\n");
}
 
+   kfree(misc_reg03);
return result;
 }
 
--
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 v4] smsc95xx: Add comments to the registers definition

2017-04-17 Thread David Miller 
From: Martin Wetterwald 
Date: Thu, 13 Apr 2017 10:08:44 +0200

> This chip is used by a lot of embedded devices and also by the Raspberry
> Pi 1, 2 & 3 which were created to promote the study of computer
> sciences. Students wanting to learn kernel / network device driver
> programming through those devices can only rely on the Linux kernel
> driver source to make their own.
> 
> This commit adds a lot of comments to the registers definition to expand
> the register names.
> 
> Cc: Steve Glendinning 
> Cc: Microchip Linux Driver Support 
> CC: David Miller 
> Signed-off-by: Martin Wetterwald 
> Reviewed-by: Andrew Lunn 
> Acked-by: Steve Glendinning 

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

Re: usb: host: xhci: stalled endpoint ring not cleared on empty td_list

2017-04-17 Thread Alan Stern 
On Sun, 16 Apr 2017, Rolf Evers-Fischer wrote:

> Hi Chris,
> > On 04/11/2017 04:33 PM, Christian Gromm wrote:
> > Well, this sounds like a workaround to me as you are changing the timing
> > by waiting for the URBs to finish. This might prevent the
> > race from happening.
> > 
> I personally would rate it rather as a fix than as a workaround,
> because the "usb_wait_anchor_empty_timeout()" function doesn't only
> change the timing: It ensures that we won't kill any URB which is
> just being processed. And this is exactly the failure that we are
> observing here.
> 
> > I thought an USB device driver is allowed to kill anchored URBs at any
> > time, isn't it?
> > 
> Both functions are described in Documentation/usb/anchors.txt and I
> agree: It is not stated clearly that we must always call the
> "usb_wait_anchor_empty_timeout()" function before we can call the
> "usb_kill_anchored_urbs()" function.
> 
> Probably Oliver Neukum, who has written these functions long time
> ago, can explain shortly, if we can call the
> "usb_kill_anchored_urbs()" function always - and if not, in which
> situation the "usb_wait_anchor_empty_timeout()" function has to be
> called in advance.

It is not necessary to call usb_wait_anchor_empty_timeout() before 
calling usb_kill_anchored_urbs().

And, if you have already called usb_wait_anchor_empty_timeout() in a 
different thread, it is not necessary to wait for that call to return 
before you call usb_kill_anchored_urbs().

Alan Stern

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

Re: [PATCH] USB: serial: ftdi_sio: add device ID for Microsemi/Arrow SF2PLUS Dev Kit

2017-04-17 Thread Marek Vasut 
On 02/13/2017 10:29 AM, Johan Hovold wrote:
> [+CC: linux-usb]
> 
> Always make sure to CC linux-usb for USB patches.
> 
> On Fri, Feb 10, 2017 at 05:16:12PM +0100, Marek Vasut wrote:
>> This development kit has an FT4232 on it with a custom USB VID/PID.
>> The FT4232 provides four UARTs, but only two are used. The UART 0
>> is used by the FlashPro5 programmer and UART 2 is connected to the
>> SmartFusion2 CortexM3 SoC UART port.
> 
> Don't you want to use the "jtag" quirk for this one then to prevent the
> driver from binding to interface 0? Or do you still need this interface
> to be accessible as a tty device?

I just got the programmer working and yes, I need the JTAG quirk, thanks
for pointing that out. V2 is out.

NOTE that the MS Libero software experience on Linux is really abysmal,
neither the flashpro5 or flashpro express are usable, one has to use the
inobvious "configure programmer" in the libero gui after the synthesis
was done to make the programmer usable. And that's not the only
inobvious thing when it comes to Microsemi ... :(

>> Note that the USB VID is registered to Actel according to Linux USB
>> VID database, but that was acquired by Microsemi.
>>
>> Signed-off-by: Marek Vasut 
>> Cc: stable 
>> Cc: Johan Hovold 
>> ---
>>  drivers/usb/serial/ftdi_sio.c |  1 +
>>  drivers/usb/serial/ftdi_sio_ids.h | 10 ++
>>  2 files changed, 11 insertions(+)
>>
>> diff --git a/drivers/usb/serial/ftdi_sio.c b/drivers/usb/serial/ftdi_sio.c
>> index c98cf10be5af..14f0fb34f655 100644
>> --- a/drivers/usb/serial/ftdi_sio.c
>> +++ b/drivers/usb/serial/ftdi_sio.c
>> @@ -873,6 +873,7 @@ static const struct usb_device_id id_table_combined[] = {
>>  { USB_DEVICE_AND_INTERFACE_INFO(MICROCHIP_VID, MICROCHIP_USB_BOARD_PID,
>>  USB_CLASS_VENDOR_SPEC,
>>  USB_SUBCLASS_VENDOR_SPEC, 0x00) },
>> +{ USB_DEVICE(ACTEL_VID, MICROSEMI_ARROW_SF2PLUS_BOARD_PID) },
>>  { USB_DEVICE(JETI_VID, JETI_SPC1201_PID) },
>>  { USB_DEVICE(MARVELL_VID, MARVELL_SHEEVAPLUG_PID),
>>  .driver_info = (kernel_ulong_t)_jtag_quirk },
>> diff --git a/drivers/usb/serial/ftdi_sio_ids.h 
>> b/drivers/usb/serial/ftdi_sio_ids.h
>> index 168ccb03ce08..a9d538d18344 100644
>> --- a/drivers/usb/serial/ftdi_sio_ids.h
>> +++ b/drivers/usb/serial/ftdi_sio_ids.h
>> @@ -627,6 +627,16 @@
>>  #define MICROCHIP_USB_BOARD_PID 0x000A /* CDC RS-232 Emulation Demo */
>>  
>>  /*
>> + * Microsemi/Arrow SF2PLUS Dev Kit
>> + *
>> + * This board has an FT4232 on it which provides four UART ports.
>> + * UART 0 is used by the FlashPro5 programmer, UART 2 is connected
>> + * to the UART of an CortexM3 SoC-FPGA on the board.
>> + */
>> +#define ACTEL_VID   0x1514
>> +#define MICROSEMI_ARROW_SF2PLUS_BOARD_PID   0x2008
>> +
> 
> Please place this before the Olimex section to try to maintain some
> order based on VID.

Done

-- 
Best regards,
Marek Vasut
--
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: serial: ftdi_sio: add device ID for Microsemi/Arrow SF2PLUS Dev Kit

2017-04-17 Thread Marek Vasut 
This development kit has an FT4232 on it with a custom USB VID/PID.
The FT4232 provides four UARTs, but only two are used. The UART 0
is used by the FlashPro5 programmer and UART 2 is connected to the
SmartFusion2 CortexM3 SoC UART port.

Note that the USB VID is registered to Actel according to Linux USB
VID database, but that was acquired by Microsemi.

Signed-off-by: Marek Vasut 
Cc: stable 
Cc: usb 
Cc: Johan Hovold 
---
V2: - Move the ID in ftdi_sio_ids.h to keep it sorted by VIDs
- Use the JTAG quirk to avoid binding channel 0, this is needed by
  the Libero software, otherwise it cannot use the programmer.
---
 drivers/usb/serial/ftdi_sio.c |  2 ++
 drivers/usb/serial/ftdi_sio_ids.h | 10 ++
 2 files changed, 12 insertions(+)

diff --git a/drivers/usb/serial/ftdi_sio.c b/drivers/usb/serial/ftdi_sio.c
index 80c6d3deb80d..a42e7f2af420 100644
--- a/drivers/usb/serial/ftdi_sio.c
+++ b/drivers/usb/serial/ftdi_sio.c
@@ -873,6 +873,8 @@ static const struct usb_device_id id_table_combined[] = {
{ USB_DEVICE_AND_INTERFACE_INFO(MICROCHIP_VID, MICROCHIP_USB_BOARD_PID,
USB_CLASS_VENDOR_SPEC,
USB_SUBCLASS_VENDOR_SPEC, 0x00) },
+   { USB_DEVICE(ACTEL_VID, MICROSEMI_ARROW_SF2PLUS_BOARD_PID),
+   .driver_info = (kernel_ulong_t)_jtag_quirk },
{ USB_DEVICE(JETI_VID, JETI_SPC1201_PID) },
{ USB_DEVICE(MARVELL_VID, MARVELL_SHEEVAPLUG_PID),
.driver_info = (kernel_ulong_t)_jtag_quirk },
diff --git a/drivers/usb/serial/ftdi_sio_ids.h 
b/drivers/usb/serial/ftdi_sio_ids.h
index 168ccb03ce08..7b6edb8e9ee2 100644
--- a/drivers/usb/serial/ftdi_sio_ids.h
+++ b/drivers/usb/serial/ftdi_sio_ids.h
@@ -877,6 +877,16 @@
 #defineFIC_VID 0x1457
 #defineFIC_NEO1973_DEBUG_PID   0x5118
 
+/*
+ * Microsemi/Arrow SF2PLUS Dev Kit
+ *
+ * This board has an FT4232 on it which provides four UART ports.
+ * UART 0 is used by the FlashPro5 programmer, UART 2 is connected
+ * to the UART of an CortexM3 SoC-FPGA on the board.
+ */
+#define ACTEL_VID  0x1514
+#define MICROSEMI_ARROW_SF2PLUS_BOARD_PID  0x2008
+
 /* Olimex */
 #define OLIMEX_VID 0x15BA
 #define OLIMEX_ARM_USB_OCD_PID 0x0003
-- 
2.11.0

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

Re: usb: dwc2: NMI watchdog: BUG: soft lockup - CPU#0 stuck for 146s

2017-04-17 Thread Stefan Wahren 
Hi,

> Stefan Wahren  hat am 31. Oktober 2016 um 21:34 
> geschrieben:
> 
> 
> I inspired by this issue [1] i build up a slightly modified setup with a
> Raspberry Pi B (mainline kernel 4.9rc3), a powered 7 port USB hub and 5 
> Prolific
> PL2303 USB to serial convertors. I modified the usb_test for dwc2 [2], which
> only tries to open all ttyUSB devices one after the other. 
> 
> Unfortunately the complete system stuck after opening the first ttyUSB device 
> (
> heartbeat LED stop blinking, no reaction to debug UART). The only way to
> reanimate the system is to powerdown the USB hub with the USB to serial
> convertors.
> 
> [1] - https://github.com/raspberrypi/linux/issues/1692
> [2] - https://gist.github.com/lategoodbye/dd0d30af27b6f101b03d5923b279dbaa

since this issue still exists with 4.11 (even without or with microframe 
scheduler enabled), i want to ask some additional questions:

Is this issue reproducible with other dwc2 platforms than bcm2835?
Does the soft lockup also occurs after opening the second serial convertor or 
later?

Regards
Stefan

> 
> pi@raspberrypi:~$ lsusb -t
> /:  Bus 01.Port 1: Dev 1, Class=root_hub, Driver=dwc2/1p, 480M
> |__ Port 1: Dev 2, If 0, Class=Hub, Driver=hub/3p, 480M
> |__ Port 1: Dev 3, If 0, Class=Vendor Specific Class, Driver=smsc95xx,
> 480M
> |__ Port 2: Dev 11, If 0, Class=Hub, Driver=hub/4p, 480M
> |__ Port 3: Dev 15, If 0, Class=Vendor Specific Class,
> Driver=pl2303, 12M
> |__ Port 1: Dev 12, If 0, Class=Hub, Driver=hub/4p, 480M
> |__ Port 2: Dev 14, If 0, Class=Vendor Specific Class,
> Driver=pl2303, 12M
> |__ Port 3: Dev 16, If 0, Class=Vendor Specific Class,
> Driver=pl2303, 12M
> |__ Port 4: Dev 17, If 0, Class=Vendor Specific Class,
> Driver=pl2303, 12M
> |__ Port 2: Dev 13, If 0, Class=Vendor Specific Class,
> Driver=pl2303, 12M
> 
> pi@raspberrypi:~$ ./usb_test
> idle
> opening [/dev/ttyUSB0] ok
> [  232.658768] NMI watchdog: BUG: soft lockup - CPU#0 stuck for 146s!
> [usb_test:522]
> [  232.678443] Modules linked in: pwm_bcm2835 vchiq(C)
> [  232.678481] CPU: 0 PID: 522 Comm: usb_test Tainted: G C
>  4.9.0-rc3+ #33
> [  232.678486] Hardware name: BCM2835
> [  232.678498] task: cab54e40 task.stack: c688c000
> [  232.678520] PC is at __do_softirq+0x68/0x2a8
> [  232.678538] LR is at irq_exit+0xb8/0x120
> [  232.678552] pc : []lr : []psr: 6113
> sp : c688da60  ip : c688daa8  fp : c688daa4
> [  232.678560] r10: c0b7f800  r9 : c688c000  r8 : 0040
> [  232.678567] r7 : 000a  r6 : cb802400  r5 :   r4 : 0001
> [  232.678575] r3 :   r2 : 0100  r1 : 0040  r0 : 
> [  232.678585] Flags: nZCv  IRQs on  FIQs on  Mode SVC_32  ISA ARM  Segment 
> none
> [  232.678593] Control: 00c5387d  Table: 068a4008  DAC: 0051
> [  232.678604] CPU: 0 PID: 522 Comm: usb_test Tainted: G C
>  4.9.0-rc3+ #33
> [  232.678609] Hardware name: BCM2835
> [  232.678667] [] (unwind_backtrace) from []
> (show_stack+0x20/0x24)
> [  232.678695] [] (show_stack) from []
> (dump_stack+0x20/0x28)
> [  232.678718] [] (dump_stack) from [] 
> (show_regs+0x1c/0x20)
> [  232.678752] [] (show_regs) from []
> (watchdog_timer_fn+0x140/0x19c)
> [  232.678779] [] (watchdog_timer_fn) from []
> (__hrtimer_run_queues.constprop.3+0xec/0x210)
> [  232.678798] [] (__hrtimer_run_queues.constprop.3) from 
> []
> (hrtimer_interrupt+0xa4/0x1cc)
> [  232.678827] [] (hrtimer_interrupt) from []
> (bcm2835_time_interrupt+0x40/0x48)
> [  232.678865] [] (bcm2835_time_interrupt) from []
> (__handle_irq_event_percpu+0x68/0x1b8)
> [  232.678891] [] (__handle_irq_event_percpu) from []
> (handle_irq_event_percpu+0x2c/0x68)
> [  232.678915] [] (handle_irq_event_percpu) from []
> (handle_irq_event+0x38/0x4c)
> [  232.678939] [] (handle_irq_event) from []
> (handle_level_irq+0xc4/0xf8)
> [  232.678960] [] (handle_level_irq) from []
> (generic_handle_irq+0x28/0x38)
> [  232.678983] [] (generic_handle_irq) from []
> (__handle_domain_irq+0x90/0xb8)
> [  232.679004] [] (__handle_domain_irq) from []
> (bcm2835_handle_irq+0x30/0x48)
> [  232.679022] [] (bcm2835_handle_irq) from []
> (__irq_svc+0x6c/0x90)
> [  232.679031] Exception stack(0xc688da10 to 0xc688da58)
> [  232.679044] da00:  0040
> 0100 
> [  232.679062] da20: 0001  cb802400 000a 0040 c688c000
> c0b7f800 c688daa4
> [  232.679078] da40: c688daa8 c688da60 c0121270 c01014d0 6113 f00
> c687a300 c9374900 ca918b00 caff1200 c688db84
> [  232.679235] db20: c688db28 c688db40 c04a1cf8 c049cb64 6013 
> [  232.679272] [] (__irq_svc) from []
> (_dwc2_hcd_urb_enqueue+0x414/0x560)
> [  232.679302] [] (_dwc2_hcd_urb_enqueue) from []
> (usb_hcd_submit_urb+0x704/0x8c4)
> [  232.679327] [] (usb_hcd_submit_urb) from []
> (usb_submit_urb+0x438/0x4e0)
> [  232.679358] [] (usb_submit_urb)

Re: [PATCH v2 2/2] usb: dwc2: add multiple clocks handling

2017-04-17 Thread Frank Wang 

Hi John,

I apologize if this was presumptuous, would you like to have a look this 
series please?



On 2017/3/28 21:49, Felipe Balbi wrote:

Hi,

Heiko Stübner  writes:

Am Donnerstag, 9. Februar 2017, 10:44:39 CET schrieb Frank Wang:

Since dwc2 may have one or more input clocks need to manage for some
platform, so this adds change clk to clk's array of struct dwc2_hsotg
to handle more clocks operation.

Signed-off-by: Frank Wang 

for the simple clock handling the dwc2-driver does right now, this looks
adquate and honoring EPROBE_DEFER is a nice touch ;-), so

Reviewed-by: Heiko Stuebner 

John, care to look at this series?



BR.
Frank


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

Regression - Linux 4.9: ums_eneub6250 broken: transfer buffer not dma capable - Trace

2017-04-17 Thread Andreas Hartmann 
Hello!

Since Linux 4.9, ums_eneub6250 is broken. It's working fine if
CONFIG_VMAP_STACK is disabled.

I would be glad if it would be fixed.


Thanks,
kind regards,
Andreas


Apr 15 17:58:54 notebook2 kernel: usb 1-1.1: new high-speed USB device number 3 
using ehci-pci
Apr 15 17:58:54 notebook2 kernel: usb 1-1.1: New USB device found, 
idVendor=0cf2, idProduct=6250
Apr 15 17:58:54 notebook2 kernel: usb 1-1.1: New USB device strings: Mfr=1, 
Product=2, SerialNumber=4
Apr 15 17:58:54 notebook2 kernel: usb 1-1.1: Product: UB6250   
Apr 15 17:58:54 notebook2 kernel: usb 1-1.1: Manufacturer: ENE Flash  
Apr 15 17:58:54 notebook2 kernel: usb 1-1.1: SerialNumber: 606569746801
Apr 15 17:58:54 notebook2 mtp-probe[2134]: checking bus 1, device 3: 
"/sys/devices/pci:00/:00:1a.0/usb1/1-1/1-1.1"
Apr 15 17:58:54 notebook2 mtp-probe[2134]: bus: 1, device: 3 was not an MTP 
device
Apr 15 17:58:55 notebook2 kernel: usbcore: registered new interface driver 
usb-storage
Apr 15 17:58:55 notebook2 kernel: usbcore: registered new interface driver uas
Apr 15 17:58:55 notebook2 kernel: ums_eneub6250 1-1.1:1.0: USB Mass Storage 
device detected
Apr 15 17:58:55 notebook2 kernel: scsi host6: usb-storage 1-1.1:1.0
Apr 15 17:58:55 notebook2 kernel: [ cut here ]
Apr 15 17:58:55 notebook2 kernel: WARNING: CPU: 2 PID: 2133 at 
../drivers/usb/core/hcd.c:1587 usb_hcd_map_urb_for_dma+0x4ba/0x4f0 [usbcore]
Apr 15 17:58:55 notebook2 kernel: transfer buffer not dma capable
Apr 15 17:58:55 notebook2 kernel: Modules linked in: ums_eneub6250(+) uas 
usb_storage fuse binfmt_misc snd_hda_codec_hdmi snd_hda_codec_realtek 
snd_hda_codec_generic snd_hda_intel snd_hda_codec snd_hda_core snd_hwdep 
snd_pcm_oss msi_wmi iTCO_wdt iTCO_vendor_support snd_pcm wmi snd_seq battery ac 
msi_laptop sparse_keymap rfkill joydev snd_seq_device snd_timer r8169 mii 
snd_mixer_oss intel_powerclamp coretemp kvm_intel snd mei_me mei kvm i2c_i801 
lpc_ich soundcore intel_ips shpchp mfd_core i2c_smbus fjes acpi_cpufreq tpm_tis 
pcspkr thermal tpm_tis_core tpm irqbypass fan dm_crypt crc32c_intel serio_raw 
sr_mod cdrom ehci_pci i915 ehci_hcd i2c_algo_bit usbcore drm_kms_helper 
syscopyarea sysfillrect sysimgblt fb_sys_fops drm video button dm_mirror 
dm_region_hash dm_log sg dm_multipath dm_mod scsi_dh_rdac scsi_dh_emc 
scsi_dh_alua
Apr 15 17:58:55 notebook2 kernel: CPU: 2 PID: 2133 Comm: systemd-udevd Not 
tainted 4.9.21-1-default #1
Apr 15 17:58:55 notebook2 kernel: Hardware name: Micro-Star International 
CR620/CR620, BIOS E1681IMS VER.10C 04/12/2011
Apr 15 17:58:55 notebook2 kernel:  baf681b477f0 af3c854a 
baf681b47840 
Apr 15 17:58:55 notebook2 kernel:  baf681b47830 af085c71 
0633af0bd0de 8d35b2844e40
Apr 15 17:58:55 notebook2 kernel:   0200 
0002 8d360fafd800
Apr 15 17:58:55 notebook2 kernel: Call Trace:
Apr 15 17:58:55 notebook2 kernel:  [] dump_stack+0x63/0x89
Apr 15 17:58:55 notebook2 kernel:  [] __warn+0xd1/0xf0
Apr 15 17:58:55 notebook2 kernel:  [] 
warn_slowpath_fmt+0x4f/0x60
Apr 15 17:58:55 notebook2 kernel:  [] ? 
put_prev_entity+0x48/0x720
Apr 15 17:58:55 notebook2 kernel:  [] 
usb_hcd_map_urb_for_dma+0x4ba/0x4f0 [usbcore]
Apr 15 17:58:55 notebook2 kernel:  [] ? 
finish_task_switch+0x78/0x1e0
Apr 15 17:58:55 notebook2 kernel:  [] 
usb_hcd_submit_urb+0x1c9/0xb30 [usbcore]
Apr 15 17:58:55 notebook2 kernel:  [] ? schedule+0x3d/0x90
Apr 15 17:58:55 notebook2 kernel:  [] ? 
schedule_timeout+0x220/0x3c0
Apr 15 17:58:55 notebook2 kernel:  [] 
usb_submit_urb.part.6+0x295/0x550 [usbcore]
Apr 15 17:58:55 notebook2 kernel:  [] 
usb_submit_urb+0x34/0x70 [usbcore]
Apr 15 17:58:55 notebook2 kernel:  [] 
usb_stor_msg_common+0x9d/0x120 [usb_storage]
Apr 15 17:58:55 notebook2 kernel:  [] 
usb_stor_bulk_transfer_buf+0x56/0xa0 [usb_storage]
Apr 15 17:58:55 notebook2 kernel:  [] 
usb_stor_bulk_transfer_sg+0x4e/0x60 [usb_storage]
Apr 15 17:58:55 notebook2 kernel:  [] 
ene_send_scsi_cmd+0x97/0x160 [ums_eneub6250]
Apr 15 17:58:55 notebook2 kernel:  [] 
ene_get_card_type.constprop.19+0x5b/0x60 [ums_eneub6250]
Apr 15 17:58:55 notebook2 kernel:  [] 
ene_ub6250_probe+0x8f/0x110 [ums_eneub6250]
Apr 15 17:58:55 notebook2 kernel:  [] 
usb_probe_interface+0x157/0x2f0 [usbcore]
Apr 15 17:58:55 notebook2 kernel:  [] 
driver_probe_device+0x227/0x440
Apr 15 17:58:55 notebook2 kernel:  [] 
__driver_attach+0xdd/0xe0
Apr 15 17:58:55 notebook2 kernel:  [] ? 
driver_probe_device+0x440/0x440
Apr 15 17:58:55 notebook2 kernel:  [] 
bus_for_each_dev+0x5d/0x90
Apr 15 17:58:55 notebook2 kernel:  [] driver_attach+0x1e/0x20
Apr 15 17:58:55 notebook2 kernel:  [] 
bus_add_driver+0x45/0x270
Apr 15 17:58:55 notebook2 kernel:  [] 
driver_register+0x60/0xe0
Apr 15 17:58:55 notebook2 kernel:  [] 
usb_register_driver+0x82/0x150 [usbcore]
Apr 15 17:58:55 notebook2 kernel:  [] ? 0xc03b9000
Apr 15 17:58:55 notebook2 kernel:  [] 
ene_ub6250_driver_init+0x38/0x1000

Re: [PATCH v4 6/6] sound: replace /proc/bus/usb by /dev/bus/usb

2017-04-17 Thread Takashi Iwai 
On Mon, 17 Apr 2017 02:51:11 +0200,
Mauro Carvalho Chehab wrote:
> 
> The /proc/bus/usb devices don't exist anymore, since when we
> got rid of usbfs. Those devices are now seen at
> /dev/bus/usb.
> 
> Signed-off-by: Mauro Carvalho Chehab 

Since it's a driver fix, I applied it to sound tree now.


thanks,

Takashi

> ---
>  sound/usb/usx2y/us122l.c| 2 +-
>  sound/usb/usx2y/usX2Yhwdep.c| 2 +-
>  sound/usb/usx2y/usx2yhwdeppcm.c | 2 +-
>  3 files changed, 3 insertions(+), 3 deletions(-)
> 
> diff --git a/sound/usb/usx2y/us122l.c b/sound/usb/usx2y/us122l.c
> index cf45bf1f7ee0..e118bdca983d 100644
> --- a/sound/usb/usx2y/us122l.c
> +++ b/sound/usb/usx2y/us122l.c
> @@ -472,7 +472,7 @@ static int usb_stream_hwdep_new(struct snd_card *card)
>   hw->ops.mmap = usb_stream_hwdep_mmap;
>   hw->ops.poll = usb_stream_hwdep_poll;
>  
> - sprintf(hw->name, "/proc/bus/usb/%03d/%03d/hwdeppcm",
> + sprintf(hw->name, "/dev/bus/usb/%03d/%03d/hwdeppcm",
>   dev->bus->busnum, dev->devnum);
>   return 0;
>  }
> diff --git a/sound/usb/usx2y/usX2Yhwdep.c b/sound/usb/usx2y/usX2Yhwdep.c
> index 605e1047c01d..f4b3cda412fc 100644
> --- a/sound/usb/usx2y/usX2Yhwdep.c
> +++ b/sound/usb/usx2y/usX2Yhwdep.c
> @@ -258,7 +258,7 @@ int usX2Y_hwdep_new(struct snd_card *card, struct 
> usb_device* device)
>   hw->ops.mmap = snd_us428ctls_mmap;
>   hw->ops.poll = snd_us428ctls_poll;
>   hw->exclusive = 1;
> - sprintf(hw->name, "/proc/bus/usb/%03d/%03d", device->bus->busnum, 
> device->devnum);
> + sprintf(hw->name, "/dev/bus/usb/%03d/%03d", device->bus->busnum, 
> device->devnum);
>   return 0;
>  }
>  
> diff --git a/sound/usb/usx2y/usx2yhwdeppcm.c b/sound/usb/usx2y/usx2yhwdeppcm.c
> index f95164b91152..d51c7fd7835b 100644
> --- a/sound/usb/usx2y/usx2yhwdeppcm.c
> +++ b/sound/usb/usx2y/usx2yhwdeppcm.c
> @@ -723,7 +723,7 @@ int usX2Y_hwdep_pcm_new(struct snd_card *card)
>   hw->ops.release = snd_usX2Y_hwdep_pcm_release;
>   hw->ops.mmap = snd_usX2Y_hwdep_pcm_mmap;
>   hw->exclusive = 1;
> - sprintf(hw->name, "/proc/bus/usb/%03d/%03d/hwdeppcm", dev->bus->busnum, 
> dev->devnum);
> + sprintf(hw->name, "/dev/bus/usb/%03d/%03d/hwdeppcm", dev->bus->busnum, 
> dev->devnum);
>  
>   err = snd_pcm_new(card, NAME_ALLCAPS" hwdep Audio", 2, 1, 1, );
>   if (err < 0) {
> -- 
> 2.9.3
> 
> 
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

2017-04-17 Thread Peter Chen 
According to xHCI spec Figure 30: Interrupt Throttle Flow Diagram

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

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

Signed-off-by: Peter Chen 
---
Mathias, I am not very sure if the comments I delete is complete
useless, plese help to check.

 drivers/usb/host/xhci-ring.c | 5 +
 drivers/usb/host/xhci.c  | 5 +++--
 include/linux/usb/hcd.h  | 1 +
 3 files changed, 5 insertions(+), 6 deletions(-)

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

2017-04-17 Thread Peter Chen 
On Sun, Apr 16, 2017 at 08:12:50PM -0700, Stefan Agner wrote:
> The assignment ret = ret is redundant and can be removed.
> 
> Signed-off-by: Stefan Agner 
> ---
> A very similar patch has been applied already last year, but there is
> a second such assignment...
> 
> --
> Stefan
> 
>  drivers/usb/gadget/udc/core.c | 4 +---
>  1 file changed, 1 insertion(+), 3 deletions(-)
> 
> diff --git a/drivers/usb/gadget/udc/core.c b/drivers/usb/gadget/udc/core.c
> index d685d82dcf48..b57bd53812fe 100644
> --- a/drivers/usb/gadget/udc/core.c
> +++ b/drivers/usb/gadget/udc/core.c
> @@ -139,10 +139,8 @@ int usb_ep_disable(struct usb_ep *ep)
>   goto out;
>  
>   ret = ep->ops->disable(ep);
> - if (ret) {
> - ret = ret;
> + if (ret)
>   goto out;
> - }
>  
>   ep->enabled = false;
>  

Reviewed-by: Peter Chen 

-- 

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