date:20140204

On Mon, Feb 03, 2014 at 08:51:48PM +, Paul Zimmerman wrote:
  From: Paul Zimmerman
  Sent: Monday, February 03, 2014 9:36 AM

  From: Stephen Warren [mailto:swar...@wwwdotorg.org]
  Sent: Saturday, February 01, 2014 7:44 PM

  On 02/01/2014 03:00 AM, Andre Heider wrote:
  On Fri, Jan 31, 2014 at 11:48:37PM -0700, Stephen Warren wrote:
  On 01/31/2014 11:12 AM, Andre Heider wrote:
  On Mon, Jan 13, 2014 at 01:50:09PM -0800, Paul Zimmerman wrote:
  The DWC2 driver should now be in good enough shape to move out of
  staging. I have stress tested it overnight on RPI running mass
  storage and Ethernet transfers in parallel, and for several days
  on our proprietary PCI-based platform.
  ...
  this looks just fine, but for whatever reason it breaks sdhci on my rpi.
  With today's Linus' master the dwc2 controller seems to initialize fine,
  but I get this upon boot:

  [1.783316] sdhci-bcm2835 2030.sdhci: sdhci_pltfm_init failed -12
  [1.794820] sdhci-bcm2835: probe of 2030.sdhci failed with error 
  -12
  ...
  This is due to the following code:
  ...
  What ends up happening, simply due to memory allocation order, is that
  the memory writes inside usb_settoggle() end up setting the SDHCI struct
  platform_device's num_resources to 0, so that it's call to
  platform_get_resource() fails.

  With the DWC2 move patch reverted, some other random piece of memory is
  being corrupted, which just happens not to cause any visible problem.
  Likely it's some other struct platform_device that's already had its
  resources read by the time DWC2 probes and corrupts them.

  (Yes, this was hard to find!)

  Nice work, but how did you pinpoint this? Am I missing some option/tool
  or did I just not stare for long enough?

  Well, there was a clear place where an issue was present; the resource
  lookup in sdhci_pltfm_init() was failing, so I put a bunch of printfs
  into that function to dump out the data platform_get_resource() used.
  This clearly pointed at num_resources==0 being the problem. Next, I
  dumped the same data from the code in drivers/of that sets it up, and it
  was OK there, so I knew it was getting over-written somewhere. I then
  basically added hundreds of calls to the same data dumping function
  throughout kernel functions like really_probe() to track down the
  location of the problem. Luckily, the behaviour was stable, so I wasn't
  chasing a race/timing condition. Eventually I narrowed the window to the
  few lines of code I mentioned in _dwc2_hcd_endpoint_reset(). It would
  have been much harder if it was e.g. the USB HW DMAing to memory that
  caused the corruption, so I was lucky:-)

  Nice work Stephen, thanks. I will try to come up with a patch to fix this
  ASAP, along the lines of what Alan suggested.

 Stephen, Andre,

 Can you test the attached patch, please? It works for my on the Synopsys
 PCIe-based FPGA board. Unfortunately my RPI board is currently broken,
 so I am unable to test it there to verify it actually fixes the problem
 you are seeing.

 The dwc2 driver doesn't use the usb_device toggle bits anywhere else,
 so the quickest fix is to just remove the problematic code from
 _dwc2_hcd_endpoint_reset().

 If you give me your tested-bys, I will submit this as a proper patch
 to Greg.

I'll give it a spin this evening, thanks.

Is that really just redundant code or could this removal have side effects?
Should I look out for anything specific?

Oh, and I'm not sure if I poked the right spot with the nousb fix, but
I'll send that out as well.

Regards,
Andre
--
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: Switch Intel Lynx Point ports to EHCI on shutdown.

2014-02-04 Thread Denis Turischev

The same issue like with Panther Point chipsets. If the USB ports are
switched to xHCI on shutdown, the xHCI host will send a spurious interrupt,
which will wake the system. Some BIOS have work around for this, but not all.
One example is Compulab's mini-desktop, the Intense-PC2.

The bug can be avoided if the USB ports are switched back to EHCI on
shutdown.

Signed-off-by: Denis Turischev de...@compulab.co.il
---
 drivers/usb/host/xhci-pci.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/usb/host/xhci-pci.c b/drivers/usb/host/xhci-pci.c
index 3c898c1..9233d12 100644
--- a/drivers/usb/host/xhci-pci.c
+++ b/drivers/usb/host/xhci-pci.c
@@ -134,6 +134,8 @@ static void xhci_pci_quirks(struct device *dev, struct 
xhci_hcd *xhci)
 */
if (pdev-subsystem_vendor == PCI_VENDOR_ID_HP)
xhci-quirks |= XHCI_SPURIOUS_WAKEUP;
+
+   xhci-quirks |= XHCI_SPURIOUS_REBOOT;
}
if (pdev-vendor == PCI_VENDOR_ID_ETRON 
pdev-device == PCI_DEVICE_ID_ASROCK_P67) {
-- 
1.8.1.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

[PATCH] usb: qcserial: add Netgear Aircard 340U

2014-02-04 Thread Bjørn Mork

This device was mentioned in an OpenWRT forum.  Seems to have a standard
Sierra Wireless ifnumber to function layout:
 0: qcdm
 2: nmea
 3: modem
 8: qmi
 9: storage

Cc: sta...@vger.kernel.org
Signed-off-by: Bjørn Mork bj...@mork.no
---
 drivers/usb/serial/qcserial.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/usb/serial/qcserial.c b/drivers/usb/serial/qcserial.c
index c65437cfd4a2..968a40201e5f 100644
--- a/drivers/usb/serial/qcserial.c
+++ b/drivers/usb/serial/qcserial.c
@@ -139,6 +139,9 @@ static const struct usb_device_id id_table[] = {
{USB_DEVICE_INTERFACE_NUMBER(0x1199, 0x901c, 0)},   /* Sierra 
Wireless EM7700 Device Management */
{USB_DEVICE_INTERFACE_NUMBER(0x1199, 0x901c, 2)},   /* Sierra 
Wireless EM7700 NMEA */
{USB_DEVICE_INTERFACE_NUMBER(0x1199, 0x901c, 3)},   /* Sierra 
Wireless EM7700 Modem */
+   {USB_DEVICE_INTERFACE_NUMBER(0x1199, 0x9051, 0)},   /* Netgear 
AirCard 340U Device Management */
+   {USB_DEVICE_INTERFACE_NUMBER(0x1199, 0x9051, 2)},   /* Netgear 
AirCard 340U NMEA */
+   {USB_DEVICE_INTERFACE_NUMBER(0x1199, 0x9051, 3)},   /* Netgear 
AirCard 340U Modem */
 
{ } /* Terminating entry */
 };
-- 
1.9.rc1

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

[PATCH net,stable] net: qmi_wwan: add Netgear Aircard 340U

2014-02-04 Thread Bjørn Mork

This device was mentioned in an OpenWRT forum.  Seems to have a standard
Sierra Wireless ifnumber to function layout:
 0: qcdm
 2: nmea
 3: modem
 8: qmi
 9: storage

Signed-off-by: Bjørn Mork bj...@mork.no
---
 drivers/net/usb/qmi_wwan.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/net/usb/qmi_wwan.c b/drivers/net/usb/qmi_wwan.c
index 23bdd5b9274d..ef4a45aea5aa 100644
--- a/drivers/net/usb/qmi_wwan.c
+++ b/drivers/net/usb/qmi_wwan.c
@@ -723,6 +723,7 @@ static const struct usb_device_id products[] = {
{QMI_FIXED_INTF(0x1199, 0x68a2, 8)},/* Sierra Wireless MC7710 in 
QMI mode */
{QMI_FIXED_INTF(0x1199, 0x68a2, 19)},   /* Sierra Wireless MC7710 in 
QMI mode */
{QMI_FIXED_INTF(0x1199, 0x901c, 8)},/* Sierra Wireless EM7700 */
+   {QMI_FIXED_INTF(0x1199, 0x9051, 8)},/* Netgear AirCard 340U */
{QMI_FIXED_INTF(0x1bbb, 0x011e, 4)},/* Telekom Speedstick LTE II 
(Alcatel One Touch L100V LTE) */
{QMI_FIXED_INTF(0x2357, 0x0201, 4)},/* TP-LINK HSUPA Modem MA180 */
{QMI_FIXED_INTF(0x2357, 0x9000, 4)},/* TP-LINK MA260 */
-- 
1.9.rc1

--
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] tools: usb: aio example applications

2014-02-04 Thread Michal Nazarewicz

 On 01/30/2014 03:09 PM, Michal Nazarewicz wrote:
 This is not a good way to do this.  You are looping around with
 1 µseconds delays in each loop.  This is active polling and is not a way
 to implement anything.  To properly use AIO with a single thread while
 you also handling ep0, you need to use signals and ppoll.  In pseudo
 code:
 
 1. Set up ep0, open up ep1.
 1. Set up SIGUSR1 handler to do nothing.
 2. Set up signal mask such that SIGUSR1 is blocked.
 3. Schedule transfers to ep1 if needed.
 4. Use ppoll with sigmask where SIGUSR1 is not blocked.
 5a. If ppoll returned SIGINTR io_getevents with a zero timeout.
 5b. If ppoll returned  0, process ep0.
 5c. If ppoll returned  0, exit with an error.
 6. Go to step 3.
 
 Useful reading:
 * man ppoll
 * man sigevent
 * man sigprocmask
 
 You can find a bit of code that uses this technique at line 95 of:
 https://github.com/mina86/p2p-chat/blob/master/src/application.cpp

On Tue, Feb 04 2014, Robert Baldyga wrote:
 This code is an example. Don't you think it would be better to keep it
 simple?

Sure, but it also has to be correct.  Busy waiting is *not* correct.

-- 
Best regards, _ _
.o. | Liege of Serenely Enlightened Majesty of  o' \,=./ `o
..o | Computer Science,  Michał “mina86” Nazarewicz(o o)
ooo +--m...@google.com--xmpp:min...@jabber.org--ooO--(_)--Ooo--


signature.asc
Description: PGP signature

[PATCH 1/2] usb: musb: host: Fix SuperSpeed hub enumeration

From: Ajay Kumar Gupta ajay.gu...@ti.com

Disables PING on status phase of control transfer.
PING token is not mandatory in status phase of control transfer
and so some high speed USB devices don't support it. If such devices
are connected to MUSB then they would not respond to PING token
causing delayed or failed enumeration.

[Roger Q] Fixes enumeration issues with some Super-Speed USB hubs
e.g. Dlink DUB-1340

Signed-off-by: Ajay Kumar Gupta ajay.gu...@ti.com
Signed-off-by: Roger Quadros rog...@ti.com
Acked-by: Felipe Balbi ba...@ti.com
---
 drivers/usb/musb/musb_host.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/usb/musb/musb_host.c b/drivers/usb/musb/musb_host.c
index ed45572..abb38c3 100644
--- a/drivers/usb/musb/musb_host.c
+++ b/drivers/usb/musb/musb_host.c
@@ -1183,6 +1183,9 @@ irqreturn_t musb_h_ep0_irq(struct musb *musb)
csr = MUSB_CSR0_H_STATUSPKT
| MUSB_CSR0_TXPKTRDY;
 
+   /* disable ping token in status phase */
+   csr |= MUSB_CSR0_H_DIS_PING;
+
/* flag status stage */
musb-ep0_stage = MUSB_EP0_STATUS;
 
-- 
1.8.3.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

[PATCH 2/2] usb: musb: core: Fix remote-wakeup resume

During resume don't touch SUSPENDM/RESUME bits of POWER register
while restoring controller context. These bits might be changed
by the controller during resume operation and so will be different
than what they were during suspend.

e.g. SUSPENDM bit is set by software during USB global suspend but
automatically cleared by the controller during remote wakeup or
during resume. Setting this bit back while restoring context
causes undesired behaviour. i.e. Babble interrupt is generated
and USB is broken.

Signed-off-by: Roger Quadros rog...@ti.com
---
 drivers/usb/musb/musb_core.c | 10 +-
 1 file changed, 9 insertions(+), 1 deletion(-)

diff --git a/drivers/usb/musb/musb_core.c b/drivers/usb/musb/musb_core.c
index fc192ad..a501542 100644
--- a/drivers/usb/musb/musb_core.c
+++ b/drivers/usb/musb/musb_core.c
@@ -2157,11 +2157,19 @@ static void musb_restore_context(struct musb *musb)
void __iomem *musb_base = musb-mregs;
void __iomem *ep_target_regs;
void __iomem *epio;
+   u8 power;
 
musb_writew(musb_base, MUSB_FRAME, musb-context.frame);
musb_writeb(musb_base, MUSB_TESTMODE, musb-context.testmode);
musb_write_ulpi_buscontrol(musb-mregs, musb-context.busctl);
-   musb_writeb(musb_base, MUSB_POWER, musb-context.power);
+
+   /* Don't affect SUSPENDM/RESUME bits in POWER reg */
+   power = musb_readb(musb_base, MUSB_POWER);
+   power = MUSB_POWER_SUSPENDM | MUSB_POWER_RESUME;
+   musb-context.power = ~(MUSB_POWER_SUSPENDM | MUSB_POWER_RESUME);
+   power |= musb-context.power;
+   musb_writeb(musb_base, MUSB_POWER, power);
+
musb_writew(musb_base, MUSB_INTRTXE, musb-intrtxe);
musb_writew(musb_base, MUSB_INTRRXE, musb-intrrxe);
musb_writeb(musb_base, MUSB_INTRUSBE, musb-context.intrusbe);
-- 
1.8.3.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

[PATCH 0/2] usb: musb: host: fixes for 3.14-rc

Hi Greg,

Patch 1 fixes SuperSpeed hub enumeration on beaglebone.
Patch 2 fixes remote-wakeup resume on beaglebone.

Felipe has Acked the 1st patch but still needs to Ack the 2nd one.

Patches are based on 3.14-rc1

cheers,
-roger

Ajay Kumar Gupta (1):
  usb: musb: host: Fix SuperSpeed hub enumeration

Roger Quadros (1):
  usb: musb: core: Fix remote-wakeup resume

 drivers/usb/musb/musb_core.c | 10 +-
 drivers/usb/musb/musb_host.c |  3 +++
 2 files changed, 12 insertions(+), 1 deletion(-)

-- 
1.8.3.2

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

Re: [PATCH v6 8/8] usb: ehci-exynos: Change to use phy provided by the generic phy framework

2014-02-04 Thread Tomasz Figa


Hi Alan,

On 29.01.2014 21:42, Alan Stern wrote:

On Wed, 29 Jan 2014, Kamil Debski wrote:


Change the phy provider used from the old one using the USB phy
framework to a new one using the Generic phy framework.

Signed-off-by: Kamil Debski k.deb...@samsung.com
---
  .../devicetree/bindings/usb/exynos-usb.txt |   13 +++
  drivers/usb/host/ehci-exynos.c |   97 +---
  2 files changed, 76 insertions(+), 34 deletions(-)

diff --git a/Documentation/devicetree/bindings/usb/exynos-usb.txt 
b/Documentation/devicetree/bindings/usb/exynos-usb.txt
index d967ba1..25e199a 100644
--- a/Documentation/devicetree/bindings/usb/exynos-usb.txt
+++ b/Documentation/devicetree/bindings/usb/exynos-usb.txt
@@ -12,6 +12,10 @@ Required properties:
   - interrupts: interrupt number to the cpu.
   - clocks: from common clock binding: handle to usb clock.
   - clock-names: from common clock binding: Shall be usbhost.
+  - port: if in the SoC there are EHCI phys, they should be listed here.
+One phy per port. Each port should have its reg entry with a consecutive
+number. Also it should contain phys and phy-names entries specifying the
+phy used by the port.


What is the reg entry number used for?  As far as I can see, it isn't
used for anything.  In which case, why have it at all?


The reg property is here to identify which EHCI port the node is 
describing. This should be mentioned in the documentation, though, as 
well as the whole description of port nodes should be written in a more 
structured manner, just as other properties.


Best regards,
Tomasz
--
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 Device stops working after 200001 interrupts

2014-02-04 Thread Alan Stern

On Mon, 3 Feb 2014, Alan Stern wrote:

 On Mon, 3 Feb 2014, Josh Bendavid wrote:
 
  Hi Alan,
  Yes, this hardware was in active use and working fine with 3.5.  The usb/ir
  issue came up as soon as I moved to 3.13-rc8.  (As I said, this was not the
  only change strictly speaking, given that I moved from Ubuntu to OpenElec,
  so there can well be other relevant distro-related changes)
  
  Unfortunately I prefer deep intellectual efforts which don't require much
  time...

Speaking of which, an idea struck me this morning.  Perhaps this patch 
will make a difference.  (Remove any earlier patches first.)

Without knowing the exact nature of the problem, it's not possible to 
say what will happen.  But it's worth a try.

Alan Stern



Index: usb-3.13/drivers/usb/host/ohci-hcd.c
===
--- usb-3.13.orig/drivers/usb/host/ohci-hcd.c
+++ usb-3.13/drivers/usb/host/ohci-hcd.c
@@ -801,6 +801,14 @@ static irqreturn_t ohci_irq (struct usb_
return IRQ_HANDLED;
}
 
+   /*
+* Clear all interrupts, enabled or not, except for WDH.
+* WDH must remain set until after we have read the
+* ohci-hcca-done_head value, because the controller can
+* overwrite that value whenever WDH is clear.
+*/
+   ohci_writel(ohci, ints  ~OHCI_INTR_WDH, regs-intrstatus);
+
/* We only care about interrupts that are enabled */
ints = ohci_readl(ohci, regs-intrenable);
 

--
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 0/2] usb: musb: host: fixes for 3.14-rc

2014-02-04 Thread Greg KH

On Tue, Feb 04, 2014 at 03:25:47PM +0200, Roger Quadros wrote:
 Hi Greg,
 
 Patch 1 fixes SuperSpeed hub enumeration on beaglebone.
 Patch 2 fixes remote-wakeup resume on beaglebone.
 
 Felipe has Acked the 1st patch but still needs to Ack the 2nd one.
 
 Patches are based on 3.14-rc1

Why wouldn't these come into my tree from Felipe like normal?  Why
should I take them?

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

Re: [PATCH 0/2] usb: musb: host: fixes for 3.14-rc

On 02/04/2014 05:27 PM, Greg KH wrote:
 On Tue, Feb 04, 2014 at 03:25:47PM +0200, Roger Quadros wrote:
 Hi Greg,

 Patch 1 fixes SuperSpeed hub enumeration on beaglebone.
 Patch 2 fixes remote-wakeup resume on beaglebone.

 Felipe has Acked the 1st patch but still needs to Ack the 2nd one.

 Patches are based on 3.14-rc1
 
 Why wouldn't these come into my tree from Felipe like normal?  Why
 should I take them?
 
 confused,

I should have mentioned it earlier. Felipe told me to send it to you as he's out
on vacations. But never-mind, I can wait till he picks it up.

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

RE: dwc2: commit beb7e592bc is causing a disconnected device to not get detected again

2014-02-04 Thread Dinh Nguyen

On Tue, 2014-02-04 at 02:22 +, Paul Zimmerman wrote:
  From: Dinh Nguyen [mailto:dingu...@altera.com]
  Sent: Monday, February 03, 2014 3:42 PM

  On Mon, 2014-02-03 at 23:10 +, Paul Zimmerman wrote:
From: Dinh Nguyen [mailto:dingu...@altera.com]
Sent: Monday, February 03, 2014 2:53 PM

While I was testing my patch to combine the dwc2/s3c-hsotg into a DRD
driver, I found that after disconnecting a USB HDD from an OTG
A-connector, then reconnecting it, the driver would no longer detect the
USB device.

I was able to track this issue down to this commit:

commit beb7e592bcfd750951c47580494f13065f0fd44c
Author: Julien DELACOU julien.dela...@st.com
Date:   Wed Nov 20 17:29:49 2013 +0100

staging: dwc2: add check on dwc2_core_reset return

If the GRSTCTL_CSFTRST self-clearing bit never comes
back to 0 for any reason, the controller is under reset
state and cannot be used. It's preferable to abort
initialization in such case.

Signed-off-by: Julien Delacou julien.dela...@st.com
Acked-by: Paul Zimmerman pa...@synopsys.com
Signed-off-by: Greg Kroah-Hartman gre...@linuxfoundation.org

Has anyone else seen this issue with the dwc2 driver on 3.14-rc1?

   Hi Dinh,

   I haven't seen it. Do either of the HANG messages in dwc2_core_reset()
   show up in your dmesg when this happens?

   If so, what happens if you try increasing the timeout values in there?
   i.e. try changing the two if (++count  50) to if (++count  250)
   or so.

  I think it's because of this change:

  static int dwc2_hs_phy_init(struct dwc2_hsotg *hsotg, bool select_phy)
   {
  u32 usbcfg;
  +   int retval = 0;

  if (!select_phy)
  -   return;
  +   return -ENODEV;

  My select_phy is NULL. Not sure why, but I'll debug it some more.

 Hi Dinh,

 That looks like just a silly error in that patch. Does the attached
 patch fix it?

Hi Paul,

Yes, the attached patch does fix it.

Thanks,
Dinh

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

[PATCHv2] usb: dwc2: Handle the Host Port Interrupt when it occurs in device mode

2014-02-04 Thread dinguyen

From: Dinh Nguyen dingu...@altera.com

According to the spec for the DWC2 controller, when the PRTINT interrupt fires,
the application must clear the appropriate status bit in the Host Port Control
and Status register to clear this bit.

When disconnecting an A-cable when the dwc2 host driver, the PRTINT fires, but
only the GINTSTS_PRTINT status is cleared, no action is done with the HPRT0
register. The HPRT0_ENACHG bit in the HPRT0 must also be poked to correctly
clear the GINTSTS_PRTINT interrupt.

I am seeing this behavoir on v2.93 of the DWC2 IP. When I disconnect an OTG
A-cable adapter, the PRTINT interrupt fires when the DWC2 is in device mode
and is never cleared.

This patch adds the function to read the HPRT0 register when the PRTINT fires
and the dwc2 IP has already transitioned to device mode. This function is only
clearing the HPRT0_ENACHG bit for now, but can be modified to handle more.

Signed-off-by: Dinh Nguyen dingu...@altera.com
Cc: Paul Zimmerman pa...@synopsys.com
Cc: Matt Porter mpor...@linaro.org
Cc: Matthijs Kooijman matth...@stdin.nl
---
v2: only need to call dwc2_handle_usb_port_intr() once
---
 drivers/usb/dwc2/core_intr.c |   18 ++
 1 file changed, 18 insertions(+)

diff --git a/drivers/usb/dwc2/core_intr.c b/drivers/usb/dwc2/core_intr.c
index bad298a..e037ad5 100644
--- a/drivers/usb/dwc2/core_intr.c
+++ b/drivers/usb/dwc2/core_intr.c
@@ -72,6 +72,23 @@ static const char *dwc2_op_state_str(struct dwc2_hsotg 
*hsotg)
 }
 
 /**
+ * dwc2_handle_usb_port_intr - handles OTG PRTINT interrupts.
+ * When the PRTINT interrupt fires, there are certain status bits in the Host
+ * Port that needs to get cleared.
+ *
+ * @hsotg: Programming view of DWC_otg controller
+ */
+static void dwc2_handle_usb_port_intr(struct dwc2_hsotg *hsotg)
+{
+   u32 hprt0 = readl(hsotg-regs + HPRT0);
+
+   if (hprt0  HPRT0_ENACHG) {
+   hprt0 |= HPRT0_ENACHG;
+   writel(hprt0, hsotg-regs + HPRT0);
+   }
+}
+
+/**
  * dwc2_handle_mode_mismatch_intr() - Logs a mode mismatch warning message
  *
  * @hsotg: Programming view of DWC_otg controller
@@ -572,6 +589,7 @@ irq_retry:
if (dwc2_is_device_mode(hsotg)) {
dev_dbg(hsotg-dev,
 --Port interrupt received in Device 
mode--\n);
+   dwc2_handle_usb_port_intr(hsotg);
gintsts = GINTSTS_PRTINT;
writel(gintsts, hsotg-regs + GINTSTS);
retval = 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

ax88179_178a problems on ASMedia xhci controller

2014-02-04 Thread David Laight

I've spent most of the day adding traces to the usbnet, xhci-ring and
ax88179_178a code to try to find out why the link doesn't come up quickly.

I've just found out something significant that someone else might
like to try and repeat.

If I add a trace print to xhci_queue_control_tx() is all seems to
work (modulo long delays in anything actually being transmitted).

Now the ax88179_set multicast() is called three times in quick
succession as part of the original initialisation.
Each call queues 2 control requests (it doesn't wait for any
completions).

If you trace the TD completions you see that the first one
completes more or less immediately, but the following ones
complete each time another control transfer is added.

What appears to happen is that the controller only executes one
item from that queue every time the doorbell is rung.

The register read/write requests then timeout, the driver doesn't
check.
Eventually enough of the write transfers must complete for the ring to
come up.

All the time this is happening the code keeps telling 'netdev'
that this link is ok - generating all the extra traces about
missing 'link down' events.

It might be worth seeing  if ringing the bell in the completion
function helps.

David



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

Re: usb3 stopped working 3.13.0-rc3-g8d276377 → 3.13.0-g9b0cd304

On Tue, Feb 04, 2014 at 12:55:25AM +0200, Sami Farin wrote:
 Asus P8Z68-V PRO GEN3 [ bios-version 3402, bios-release-date 05/07/2012 ]
 
 dmesg-3.13.0-rc3-g8d276377+-1391075301.txt
 http://pastebin.com/peJJkXZV
 
 dmesg-3.13.0-g9b0cd304+-1391076985.txt
 http://pastebin.com/p0UQsEte
 
 some days ago I had connected mobile phones and microphone into HP ZR24w 
 monitor's
 hub, and there was some glitch (got power but no data connection).  Even 
 earlier I once
 I got same kind of problem with this hub and I fixed it by power cycling the 
 monitor,
 but this time it did not work, so I tried also with usbcore.autosuspend=-1 
 parameter
 (did not help).
 
 I have now power cycled the computer and I do not use suspend, anyways..
 I have not yet tried if 3.13.0-rc3-g8d276377 would work now.
 
 these with 3.13.0-g9b0cd304:
 [  296.401362] xhci_hcd :03:00.0: Timeout while waiting for a slot
 [  312.015464] xhci_hcd :03:00.0: Stopped the command ring failed, maybe 
 the host is dead
 [  312.015477] xhci_hcd :03:00.0: Abort command ring failed
 [  312.015571] xhci_hcd :03:00.0: HC died; cleaning up
 [  317.010861] xhci_hcd :03:00.0: Timeout while waiting for a slot
 [  317.010867] xhci_hcd :03:00.0: Abort the command ring, but the xHCI is 
 dead.
 [  322.006129] xhci_hcd :03:00.0: Timeout while waiting for a slot
 [  322.006135] xhci_hcd :03:00.0: Abort the command ring, but the xHCI is 
 dead.
 [  327.001400] xhci_hcd :03:00.0: Timeout while waiting for a slot
 [  327.001406] xhci_hcd :03:00.0: Abort the command ring, but the xHCI is 
 dead.
 [  442.124359] xhci_hcd :05:00.0: Timeout while waiting for a slot

This may be a known regression.  Please try reverting these commits:

7dd09a1af2c7 xhci: replace xhci_write_64() with writeq()
e8b373326d8e xhci: replace xhci_read_64() with readq()

The reverts will be sent to the USB subsystem maintainer's tree today,
and will land in 3.14-rc2.

Sarah Sharp

 
 here I attached usb3 card reader into computer's usb3 port and usb2 keyboard 
 stopped
 working while the reader was plugged in
 
 [  457.679216] xhci_hcd :05:00.0: Stopped the command ring failed, maybe 
 the host is dead
 [  457.679230] xhci_hcd :05:00.0: Abort command ring failed
 [  457.679329] xhci_hcd :05:00.0: HC died; cleaning up
 [  462.673908] xhci_hcd :05:00.0: Timeout while waiting for a slot
 [  462.673914] xhci_hcd :05:00.0: Abort the command ring, but the xHCI is 
 dead.
 [  467.669179] xhci_hcd :05:00.0: Timeout while waiting for a slot
 [  467.669186] xhci_hcd :05:00.0: Abort the command ring, but the xHCI is 
 dead.
 [  472.664455] xhci_hcd :05:00.0: Timeout while waiting for a slot
 [  472.664461] xhci_hcd :05:00.0: Abort the command ring, but the xHCI is 
 dead.
 
 now when I plug any device into usb3 ports, no messages are produced.
 
 00:00.0 Host bridge: Intel Corporation 2nd Generation Core Processor Family 
 DRAM Controller (rev 09)
 Subsystem: ASUSTeK Computer Inc. P8P67 Deluxe Motherboard
 Flags: bus master, fast devsel, latency 0
 Capabilities: [e0] Vendor Specific Information: Len=0c ?
 
 00:01.0 PCI bridge: Intel Corporation Xeon E3-1200/2nd Generation Core 
 Processor Family PCI Express Root Port (rev 09) (prog-if 00 [Normal decode])
 Flags: bus master, fast devsel, latency 0
 Bus: primary=00, secondary=01, subordinate=01, sec-latency=0
 Capabilities: [88] Subsystem: ASUSTeK Computer Inc. Device 844d
 Capabilities: [80] Power Management version 3
 Capabilities: [90] MSI: Enable+ Count=1/1 Maskable- 64bit-
 Capabilities: [a0] Express Root Port (Slot+), MSI 00
 Capabilities: [100] Virtual Channel
 Capabilities: [140] Root Complex Link
 Kernel driver in use: pcieport
 
 00:02.0 VGA compatible controller: Intel Corporation 2nd Generation Core 
 Processor Family Integrated Graphics Controller (rev 09) (prog-if 00 [VGA 
 controller])
 Subsystem: ASUSTeK Computer Inc. Device 844d
 Flags: bus master, fast devsel, latency 0, IRQ 55
 Memory at f740 (64-bit, non-prefetchable) [size=4M]
 Memory at e000 (64-bit, prefetchable) [size=256M]
 I/O ports at f000 [size=64]
 Expansion ROM at unassigned [disabled]
 Capabilities: [90] MSI: Enable+ Count=1/1 Maskable- 64bit-
 Capabilities: [d0] Power Management version 2
 Capabilities: [a4] PCI Advanced Features
 Kernel driver in use: i915
 
 00:16.0 Communication controller: Intel Corporation 6 Series/C200 Series 
 Chipset Family MEI Controller #1 (rev 04)
 Subsystem: ASUSTeK Computer Inc. P8P67 Deluxe Motherboard
 Flags: bus master, fast devsel, latency 0, IRQ 41
 Memory at f7d2c000 (64-bit, non-prefetchable) [size=16]
 Capabilities: [50] Power Management version 3
 Capabilities: [8c] MSI: Enable+ Count=1/1 Maskable- 64bit+
 Kernel driver in use: mei_me

Re: [PATCH v4] Move DWC2 driver out of staging

On Mon, Feb 03, 2014 at 08:51:48PM +, Paul Zimmerman wrote:
  From: Paul Zimmerman
  Sent: Monday, February 03, 2014 9:36 AM

  From: Stephen Warren [mailto:swar...@wwwdotorg.org]
  Sent: Saturday, February 01, 2014 7:44 PM

  On 02/01/2014 03:00 AM, Andre Heider wrote:
  On Fri, Jan 31, 2014 at 11:48:37PM -0700, Stephen Warren wrote:
  On 01/31/2014 11:12 AM, Andre Heider wrote:
  On Mon, Jan 13, 2014 at 01:50:09PM -0800, Paul Zimmerman wrote:
  The DWC2 driver should now be in good enough shape to move out of
  staging. I have stress tested it overnight on RPI running mass
  storage and Ethernet transfers in parallel, and for several days
  on our proprietary PCI-based platform.
  ...
  this looks just fine, but for whatever reason it breaks sdhci on my rpi.
  With today's Linus' master the dwc2 controller seems to initialize fine,
  but I get this upon boot:

  [1.783316] sdhci-bcm2835 2030.sdhci: sdhci_pltfm_init failed -12
  [1.794820] sdhci-bcm2835: probe of 2030.sdhci failed with error 
  -12
  ...
  This is due to the following code:
  ...
  What ends up happening, simply due to memory allocation order, is that
  the memory writes inside usb_settoggle() end up setting the SDHCI struct
  platform_device's num_resources to 0, so that it's call to
  platform_get_resource() fails.

  With the DWC2 move patch reverted, some other random piece of memory is
  being corrupted, which just happens not to cause any visible problem.
  Likely it's some other struct platform_device that's already had its
  resources read by the time DWC2 probes and corrupts them.

  (Yes, this was hard to find!)

  Nice work, but how did you pinpoint this? Am I missing some option/tool
  or did I just not stare for long enough?

  Well, there was a clear place where an issue was present; the resource
  lookup in sdhci_pltfm_init() was failing, so I put a bunch of printfs
  into that function to dump out the data platform_get_resource() used.
  This clearly pointed at num_resources==0 being the problem. Next, I
  dumped the same data from the code in drivers/of that sets it up, and it
  was OK there, so I knew it was getting over-written somewhere. I then
  basically added hundreds of calls to the same data dumping function
  throughout kernel functions like really_probe() to track down the
  location of the problem. Luckily, the behaviour was stable, so I wasn't
  chasing a race/timing condition. Eventually I narrowed the window to the
  few lines of code I mentioned in _dwc2_hcd_endpoint_reset(). It would
  have been much harder if it was e.g. the USB HW DMAing to memory that
  caused the corruption, so I was lucky:-)

  Nice work Stephen, thanks. I will try to come up with a patch to fix this
  ASAP, along the lines of what Alan suggested.

 Stephen, Andre,

 Can you test the attached patch, please? It works for my on the Synopsys
 PCIe-based FPGA board. Unfortunately my RPI board is currently broken,
 so I am unable to test it there to verify it actually fixes the problem
 you are seeing.

 The dwc2 driver doesn't use the usb_device toggle bits anywhere else,
 so the quickest fix is to just remove the problematic code from
 _dwc2_hcd_endpoint_reset().

 If you give me your tested-bys, I will submit this as a proper patch
 to Greg.

LGTM, sdhci works again and there're no glaring USB issues with lan,
hid nor mass storage:

Tested-by: Andre Heider a.hei...@gmail.com

Thanks Paul,
Andre
--
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: PROBLEM: XHCI Host Controller on Intel Panther Point with CDC/ACM dead after massive NAK

2014-02-04 Thread Peter Stuge

Hi Andreas,

Kasberger Andreas wrote:
 XHCI Host Controller on Intel Panther Point with CDC/ACM dead after
 massive NAK
 PCH 82HM76 (PantherPoint) chipset connect with  a Renesas RX621
 How to reproduce :
 No Reader on device /dev/ttyACM0 connected
 Writer will send in endless loop always same command
 : echo readhik/dev/ttyACM0
 
 Function: Renesas RX621 will receive command, put into a internal
 queue and it is waiting for reader. As long reader is comming it
 will stored in the queue. If command has reached time out the
 command will removed from queue. If queue is full every command
 will be answered with NAK
 
 The response will be nearly always with NAK because nobody will
 read from /dev/ttyACM0
 
 After some time ( between seconds and several hours ) the host
 controller will not send anything to the device connected on
 Renesas RX621. 
 We proven this with a analyzer directly on the bus. Other devices
 connect to host controller are still alive and working.

I'm sorry, but this protocol design is rather broken use of USB.

That said, the HC must certainly be more robust in dealing with it.


On the protocol design:

First, using CDC-ACM means sacrificing all structured communication
offered by the USB packet bus and settling for such primitive use of
USB is not a decision that should be made lightly. Almost all
applications can benefit quite significantly both in end-user
usability and in ease of implementation from an application-specific
protocol which takes advantage of what USB offers.

Application-specific or vendor-specific are often frowned upon in
other contexts but if the protocol is documented publically then it
is a great way to take advantage of all that USB offers, and it is
explicitly supported by the specification. Use bDeviceClass or
bInterfaceClass 0xff.


But more importantly, regardless of the application protocol, with
USB it is the absolute and complete responsibility of the host-side
software to communicate with the device only *exactly* in the way
that the device supports.

You mention device-side buffering and that the device at some point
can't accept anything more from the host. With USB this means that
you must ensure that the host will know when it must not send more.

The USB way to do this, were you using an application-specific
protocol instead of serial port simulation, would be to stall the
endpoint. Unfortunately CDC-ACM doesn't allow doing that.

So you have to include some kind of in-band signalling for this. :\

This is just one reason why ACM is a poor choice for when you need
structured communication.


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

[PATCH] usb: dwc2: bail out early when booting with nousb

Add usb_disabled() check to prevent kernel oops when booting with nousb
in the cmdline:

Unable to handle kernel NULL pointer dereference at virtual address 0030
...
PC is at bus_add_device+0xe0/0x18c
LR is at device_add_groups+0x1c/0x20
...
[c02191c0] (bus_add_device) from [c0217130] (device_add+0x41c/0x538)
[c0217130] (device_add) from [c023b1d4] (usb_new_device+0x270/0x35c)
[c023b1d4] (usb_new_device) from [c0241174] (usb_add_hcd+0x4fc/0x760)
[c0241174] (usb_add_hcd) from [c0254ce0] (dwc2_hcd_init+0x434/0x510)
[c0254ce0] (dwc2_hcd_init) from [c02594f4] (dwc2_driver_probe+0x130/0x170)
[c02594f4] (dwc2_driver_probe) from [c021bbd0] 
(platform_drv_probe+0x28/0x58)

Signed-off-by: Andre Heider a.hei...@gmail.com
---
 drivers/usb/dwc2/platform.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/usb/dwc2/platform.c b/drivers/usb/dwc2/platform.c
index d01d0d3..eaba547 100644
--- a/drivers/usb/dwc2/platform.c
+++ b/drivers/usb/dwc2/platform.c
@@ -124,6 +124,9 @@ static int dwc2_driver_probe(struct platform_device *dev)
int retval;
int irq;
 
+   if (usb_disabled())
+   return -ENODEV;
+
match = of_match_device(dwc2_of_match_table, dev-dev);
if (match  match-data) {
params = match-data;
-- 
1.9.rc1

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

Re: xhci and other woes

On Mon, Feb 03, 2014 at 04:45:14PM +, David Laight wrote:
 From: David Laight
  From: David Laight
   From: renev...@internode.on.
   But there are also further issues I'm about to look at.
   Short 'ping' requests work, but a 'netperf' tcp rr test with 8k blocks
   (which probably generates sg transmits) fails generating some
   'TRB DMA ptr not part of current TD' errors.
   I think I've seem that when a 'TRB error' is reported (when I was using 
   the
   wrong type of NOP). I'm about to investigate what is being errored here.

  In this case they happen when receive buffers cross 64k boundaries
  and so are split into two TRBS.
  The controller is generating one event for the 'short transfer' and
  a second for the last TRB - by which time the TD and URB have already
  been cleared up.

 From the end of section 4.10.1.1 (Short transfers)
 - If the Short Packet occurred while processing a Transfer TRB with only an
   ISP flag set, then two events shall be generated for the transfer;
   one for the Transfer TRB that the short packet occurred on, and a second
   for the last TRB with the IOC flag set.
 - Software shall not interpret an Short Packet Event as indicating that the
   TD that it is associated with is “complete”, unless the TRB Pointer field
   of the Transfer Event references the last TRB of the TD.

And there's code in the xHCI driver to ignore the second successful
event.  See ep-last_td_was_short.  Yes, this is a slight race
condition, and we should wait for the successful event.  However, we
have not seen any issues with this race condition.

 Which means that the controller is obeying the rules, and the software is 
 wrong.

I think your mindset isn't helpful here.  Software is full of bugs.
Some bugs we know, some bugs we'll never find.  Software will never be
perfect.  The questions to ask when discovering a bug are:

1. What is the impact of this bug?  Is it user-visible?
2. How many customers are impacted by this bug?
3. What is the software complexity of fixing this bug?
4. What are the chances of the fix causing other issues?

In this case, the bug has been worked around (not perfectly), but we've
had no customer reports that this is an issue.  There is no user-visible
impact as far as we know.  So fixing this race condition is a really low
priority for me, and the fix would have to very minimally touch the
driver.

Sarah Sharp
--
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: dwc2: fix memory corruption in dwc2 driver

The move from the staging tree to the main tree exposed a
longstanding memory corruption bug in the dwc2 driver. The
reordering of the driver initialization caused the dwc2 driver
to corrupt the initialization data of the sdhci driver on the
Raspberry Pi platform, which made the bug show up.

The error is in calling to_usb_device(hsotg-dev), since -dev
is not a member of struct usb_device. The easiest fix is to
just remove the offending code, since it is not really needed.

Thanks to Stephen Warren for tracking down the cause of this.

Reported-by: Andre Heider a.hei...@gmail.com
Tested-by: Stephen Warren swar...@wwwdotorg.org
Signed-off-by: Paul Zimmerman pa...@synopsys.com
---
 drivers/usb/dwc2/hcd.c | 11 ---
 1 file changed, 11 deletions(-)

diff --git a/drivers/usb/dwc2/hcd.c b/drivers/usb/dwc2/hcd.c
index f59484d..4d918ed 100644
--- a/drivers/usb/dwc2/hcd.c
+++ b/drivers/usb/dwc2/hcd.c
@@ -2565,25 +2565,14 @@ static void _dwc2_hcd_endpoint_reset(struct usb_hcd 
*hcd,
 struct usb_host_endpoint *ep)
 {
struct dwc2_hsotg *hsotg = dwc2_hcd_to_hsotg(hcd);
-   int is_control = usb_endpoint_xfer_control(ep-desc);
-   int is_out = usb_endpoint_dir_out(ep-desc);
-   int epnum = usb_endpoint_num(ep-desc);
-   struct usb_device *udev;
unsigned long flags;
 
dev_dbg(hsotg-dev,
DWC OTG HCD EP RESET: bEndpointAddress=0x%02x\n,
ep-desc.bEndpointAddress);
 
-   udev = to_usb_device(hsotg-dev);
-
spin_lock_irqsave(hsotg-lock, flags);
-
-   usb_settoggle(udev, epnum, is_out, 0);
-   if (is_control)
-   usb_settoggle(udev, epnum, !is_out, 0);
dwc2_hcd_endpoint_reset(hsotg, ep);
-
spin_unlock_irqrestore(hsotg-lock, flags);
 }
 
-- 
1.8.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] usb: dwc2: fix role switch breakage

Commit beb7e592bc staging: dwc2: add check on dwc2_core_reset
return broke the B - A role switching on OTG-enabled platforms.
This commit fixes it.

Reported-by: Dinh Nguyen dingu...@altera.com
Tested-by: Dinh Nguyen dingu...@altera.com
Signed-off-by: Paul Zimmerman pa...@synopsys.com
---
 drivers/usb/dwc2/core.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/usb/dwc2/core.c b/drivers/usb/dwc2/core.c
index 8565d87..1d12988 100644
--- a/drivers/usb/dwc2/core.c
+++ b/drivers/usb/dwc2/core.c
@@ -216,7 +216,7 @@ static int dwc2_hs_phy_init(struct dwc2_hsotg *hsotg, bool 
select_phy)
int retval = 0;
 
if (!select_phy)
-   return -ENODEV;
+   return 0;
 
usbcfg = readl(hsotg-regs + GUSBCFG);
 
-- 
1.8.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

[RFT] xHCI TD fragment revert

Hi Mark and David,

Can you test the following two patches against 3.13?

Please make sure the adapter works when it's plugged directly into a USB
3.0 port and when it's plugged into a USB 2.0 hub.

Thanks,
Sarah Sharp

The following changes since commit d8ec26d7f8287f5788a494f56e8814210f0e64be:

  Linux 3.13 (2014-01-19 18:40:07 -0800)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/sarah/xhci.git 
3.13-td-changes-reverted

for you to fetch changes up to 4327645d0e03dad2e2ec4480cb43f30a2d1a6d20:

  Revert usb: xhci: Link TRB must not occur within a USB payload burst 
(2014-01-31 12:53:13 -0800)


Sarah Sharp (2):
  xhci 1.0: Limit arbitrarily-aligned scatter gather.
  Revert usb: xhci: Link TRB must not occur within a USB payload burst

 drivers/usb/host/xhci-ring.c |   54 +
 drivers/usb/host/xhci.c  |   14 --
 include/linux/usb.h  |2 -
 3 files changed, 13 insertions(+), 57 deletions(-)
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[RFT 2/2] Revert usb: xhci: Link TRB must not occur within a USB payload burst

This reverts commit 35773dac5f862cb1c82ea151eba3e2f6de51ec3e.  It's a
hack that caused regressions in the usb-storage and userspace USB
drivers that use usbfs and libusb.  Commit 70cabb7d992f xhci 1.0: Limit
arbitrarily-aligned scatter gather. should fix the issues seen with the
ax88179_178a driver on xHCI 1.0 hosts, without causing regressions.

Signed-off-by: Sarah Sharp sarah.a.sh...@linux.intel.com
Cc: sta...@vger.kernel.org # 3.12
---
 drivers/usb/host/xhci-ring.c | 54 ++--
 include/linux/usb.h  |  2 --
 2 files changed, 2 insertions(+), 54 deletions(-)

diff --git a/drivers/usb/host/xhci-ring.c b/drivers/usb/host/xhci-ring.c
index 53c2e296467f..1e2f3f495843 100644
--- a/drivers/usb/host/xhci-ring.c
+++ b/drivers/usb/host/xhci-ring.c
@@ -2973,58 +2973,8 @@ static int prepare_ring(struct xhci_hcd *xhci, struct 
xhci_ring *ep_ring,
}
 
while (1) {
-   if (room_on_ring(xhci, ep_ring, num_trbs)) {
-   union xhci_trb *trb = ep_ring-enqueue;
-   unsigned int usable = ep_ring-enq_seg-trbs +
-   TRBS_PER_SEGMENT - 1 - trb;
-   u32 nop_cmd;
-
-   /*
-* Section 4.11.7.1 TD Fragments states that a link
-* TRB must only occur at the boundary between
-* data bursts (eg 512 bytes for 480M).
-* While it is possible to split a large fragment
-* we don't know the size yet.
-* Simplest solution is to fill the trb before the
-* LINK with nop commands.
-*/
-   if (num_trbs == 1 || num_trbs = usable || usable == 0)
-   break;
-
-   if (ep_ring-type != TYPE_BULK)
-   /*
-* While isoc transfers might have a buffer that
-* crosses a 64k boundary it is unlikely.
-* Since we can't add NOPs without generating
-* gaps in the traffic just hope it never
-* happens at the end of the ring.
-* This could be fixed by writing a LINK TRB
-* instead of the first NOP - however the
-* TRB_TYPE_LINK_LE32() calls would all need
-* changing to check the ring length.
-*/
-   break;
-
-   if (num_trbs = TRBS_PER_SEGMENT) {
-   xhci_err(xhci, Too many fragments %d, max 
%d\n,
-   num_trbs, TRBS_PER_SEGMENT - 1);
-   return -ENOMEM;
-   }
-
-   nop_cmd = cpu_to_le32(TRB_TYPE(TRB_TR_NOOP) |
-   ep_ring-cycle_state);
-   ep_ring-num_trbs_free -= usable;
-   do {
-   trb-generic.field[0] = 0;
-   trb-generic.field[1] = 0;
-   trb-generic.field[2] = 0;
-   trb-generic.field[3] = nop_cmd;
-   trb++;
-   } while (--usable);
-   ep_ring-enqueue = trb;
-   if (room_on_ring(xhci, ep_ring, num_trbs))
-   break;
-   }
+   if (room_on_ring(xhci, ep_ring, num_trbs))
+   break;
 
if (ep_ring == xhci-cmd_ring) {
xhci_err(xhci, Do not support expand command ring\n);
diff --git a/include/linux/usb.h b/include/linux/usb.h
index 512ab162832c..7454865ad148 100644
--- a/include/linux/usb.h
+++ b/include/linux/usb.h
@@ -1264,8 +1264,6 @@ typedef void (*usb_complete_t)(struct urb *);
  * @sg: scatter gather buffer list, the buffer size of each element in
  * the list (except the last) must be divisible by the endpoint's
  * max packet size if no_sg_constraint isn't set in 'struct usb_bus'
- * (FIXME: scatter-gather under xHCI is broken for periodic transfers.
- * Do not use urb-sg for interrupt endpoints for now, only bulk.)
  * @num_mapped_sgs: (internal) number of mapped sg entries
  * @num_sgs: number of entries in the sg list
  * @transfer_buffer_length: How big is transfer_buffer.  The transfer may
-- 
1.8.5.2

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

Re: [PATCH] usb: dwc2: bail out early when booting with nousb

 From: Andre Heider [mailto:a.hei...@gmail.com]
 Sent: Tuesday, February 04, 2014 10:44 AM
 
 Add usb_disabled() check to prevent kernel oops when booting with nousb
 in the cmdline:

Hi Andre,

Please resend this with GregKH on Cc, since he is the maintainer of the
USB tree and is the one who will apply the patch. You can add my:

Acked-by: Paul Zimmerman pa...@synopsys.com

-- 
Paul

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

[RFT 1/2] xhci 1.0: Limit arbitrarily-aligned scatter gather.

xHCI 1.0 hosts have a set of requirements on how to align transfer
buffers on the endpoint rings called TD fragment rules.  When the
ax88179_178a driver added support for scatter gather in 3.12, with
commit 804fad45411b48233b48003e33a78f290d227c8 USBNET: ax88179_178a:
enable tso if usb host supports sg dma, it broke the device under xHCI
1.0 hosts.  Under certain network loads, the device would see an
unexpected short packet from the host, which would cause the device to
stop sending ethernet packets, even through USB packets would still be
sent.

Commit 35773dac5f86 usb: xhci: Link TRB must not occur within a USB
payload burst attempted to fix this.  It was a quick hack to partially
implement the TD fragment rules.  However, it caused regressions in the
usb-storage layer and userspace USB drivers using libusb.  The patches
to attempt to fix this are too far reaching into the USB core, and we
really need to implement the TD fragment rules correctly in the xHCI
driver, instead of continuing to wallpaper over the issues.

Disable arbitrarily-aligned scatter-gather in the xHCI driver for 1.0
hosts.  Only the ax88179_178a driver checks the no_sg_constraint flag,
so don't set it for 1.0 hosts.  This should not impact usb-storage or
usbfs behavior, since they pass down max packet sized aligned sg-list
entries (512 for USB 2.0 and 1024 for USB 3.0).

Signed-off-by: Sarah Sharp sarah.a.sh...@linux.intel.com
Cc: David Laight david.lai...@aculab.com
Cc: Mark Lord ml...@pobox.com
Cc: Bjørn Mork bj...@mork.no
Cc: Freddy Xin fre...@asix.com.tw
Cc: Ming Lei ming@canonical.com
Cc: sta...@vger.kernel.org # 3.12
---
 drivers/usb/host/xhci.c | 14 +++---
 1 file changed, 11 insertions(+), 3 deletions(-)

diff --git a/drivers/usb/host/xhci.c b/drivers/usb/host/xhci.c
index 4265b48856f6..ceab86e848bf 100644
--- a/drivers/usb/host/xhci.c
+++ b/drivers/usb/host/xhci.c
@@ -4716,9 +4716,6 @@ int xhci_gen_setup(struct usb_hcd *hcd, xhci_get_quirks_t 
get_quirks)
/* Accept arbitrarily long scatter-gather lists */
hcd-self.sg_tablesize = ~0;
 
-   /* support to build packet from discontinuous buffers */
-   hcd-self.no_sg_constraint = 1;
-
/* XHCI controllers don't stop the ep queue on short packets :| */
hcd-self.no_stop_on_short = 1;
 
@@ -4743,6 +4740,14 @@ int xhci_gen_setup(struct usb_hcd *hcd, 
xhci_get_quirks_t get_quirks)
/* xHCI private pointer was set in xhci_pci_probe for the second
 * registered roothub.
 */
+   xhci = hcd_to_xhci(hcd);
+   /*
+* Support arbitrarily aligned sg-list entries on hosts without
+* TD fragment rules (which are currently unsupported).
+*/
+   if (xhci-hci_version  0x100)
+   hcd-self.no_sg_constraint = 1;
+
return 0;
}
 
@@ -4769,6 +4774,9 @@ int xhci_gen_setup(struct usb_hcd *hcd, xhci_get_quirks_t 
get_quirks)
if (xhci-hci_version  0x96)
xhci-quirks |= XHCI_SPURIOUS_SUCCESS;
 
+   if (xhci-hci_version  0x100)
+   hcd-self.no_sg_constraint = 1;
+
/* Make sure the HC is halted. */
retval = xhci_halt(xhci);
if (retval)
-- 
1.8.5.2

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

Re: [PATCH] usb: dwc2: bail out early when booting with nousb

On Tue, Feb 04, 2014 at 08:10:19PM +, Paul Zimmerman wrote:
  From: Andre Heider [mailto:a.hei...@gmail.com]
  Sent: Tuesday, February 04, 2014 10:44 AM
  
  Add usb_disabled() check to prevent kernel oops when booting with nousb
  in the cmdline:
 
 Hi Andre,
 
 Please resend this with GregKH on Cc, since he is the maintainer of the
 USB tree and is the one who will apply the patch. You can add my:
 
 Acked-by: Paul Zimmerman pa...@synopsys.com

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

[GIT PULL] xhci: Fix some regressions introduced in 3.14.

The following changes since commit 2fc5a7dace3c43e62402ab4e8800a8f1834ffe2a:

  usb: chipidea: udc: using MultO at TD as real mult value for ISO-TX 
(2014-01-13 15:55:19 -0800)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/sarah/xhci.git 
tags/for-usb-linus-2014-02-04

for you to fetch changes up to f7b2e4032d52deff480e0c303fbd9180276f8dfc:

  Revert xhci: replace xhci_read_64() with readq() (2014-01-30 13:27:49 -0800)


xhci: Fix some regressions introduced in 3.14.

Hi Greg,

Here's four patches for 3.14.

One of them adds an xHCI host quirk, and the other three of them fix
regressions introduced in 3.14.  One regression causes USB 3.0 Link PM to
be enabled on all xHCI hosts (even those that may not support it), which
causes some USB 3.0 devices to not enumerate.  A second regression causes
some xHCI hosts that don't support 64-bit addressing to stop responding to
commands and die.

Note, these patches don't fix the recent usbfs regression that was caused
by commit 35773dac5f862cb1c82ea151eba3e2f6de51ec3e usb: xhci: Link TRB
must not occur within a USB payload burst.  I'm waiting for those patches
to be tested.

Please pull usb-linus into usb-next, as I have feature patches that rely on
140e3026a57a Revert usbcore: set lpm_capable field for LPM capable root
hubs

Sarah Sharp


Sarah Sharp (4):
  xhci: Fix resume issues on Renesas chips in Samsung laptops
  Revert usbcore: set lpm_capable field for LPM capable root hubs
  Revert xhci: replace xhci_write_64() with writeq()
  Revert xhci: replace xhci_read_64() with readq()

 drivers/usb/core/hcd.c   |1 -
 drivers/usb/core/hub.c   |7 +--
 drivers/usb/core/usb.h   |1 -
 drivers/usb/host/xhci-dbg.c  |6 +++---
 drivers/usb/host/xhci-mem.c  |   14 +++---
 drivers/usb/host/xhci-pci.c  |5 +
 drivers/usb/host/xhci-ring.c |   14 --
 drivers/usb/host/xhci.c  |   20 ++--
 drivers/usb/host/xhci.h  |   39 ---
 9 files changed, 62 insertions(+), 45 deletions(-)
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH] usb: dwc2: bail out early when booting with nousb

Add usb_disabled() check to prevent kernel oops when booting with nousb
in the cmdline:

Unable to handle kernel NULL pointer dereference at virtual address 0030
...
PC is at bus_add_device+0xe0/0x18c
LR is at device_add_groups+0x1c/0x20
...
[c02191c0] (bus_add_device) from [c0217130] (device_add+0x41c/0x538)
[c0217130] (device_add) from [c023b1d4] (usb_new_device+0x270/0x35c)
[c023b1d4] (usb_new_device) from [c0241174] (usb_add_hcd+0x4fc/0x760)
[c0241174] (usb_add_hcd) from [c0254ce0] (dwc2_hcd_init+0x434/0x510)
[c0254ce0] (dwc2_hcd_init) from [c02594f4] (dwc2_driver_probe+0x130/0x170)
[c02594f4] (dwc2_driver_probe) from [c021bbd0] 
(platform_drv_probe+0x28/0x58)

Signed-off-by: Andre Heider a.hei...@gmail.com
Acked-by: Paul Zimmerman pa...@synopsys.com
---
 drivers/usb/dwc2/platform.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/usb/dwc2/platform.c b/drivers/usb/dwc2/platform.c
index d01d0d3..eaba547 100644
--- a/drivers/usb/dwc2/platform.c
+++ b/drivers/usb/dwc2/platform.c
@@ -124,6 +124,9 @@ static int dwc2_driver_probe(struct platform_device *dev)
int retval;
int irq;
 
+   if (usb_disabled())
+   return -ENODEV;
+
match = of_match_device(dwc2_of_match_table, dev-dev);
if (match  match-data) {
params = match-data;
-- 
1.9.rc1

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

[PATCH 1/4] xhci: Fix resume issues on Renesas chips in Samsung laptops

Don Zickus dzic...@redhat.com writes:

Some co-workers of mine bought Samsung laptops that had mostly usb3 ports.
Those ports did not resume correctly (the driver would timeout communicating
and fail).  This led to frustration as suspend/resume is a common use for
laptops.

Poking around, I applied the reset on resume quirk to this chipset and the
resume started working.  Reloading the xhci_hcd module had been the temporary
workaround.

Signed-off-by: Sarah Sharp sarah.a.sh...@linux.intel.com
Reported-by: Don Zickus dzic...@redhat.com
Tested-by: Prarit Bhargava pra...@redhat.com
Cc: stable # 2.6.37
---
 drivers/usb/host/xhci-pci.c | 5 +
 1 file changed, 5 insertions(+)

diff --git a/drivers/usb/host/xhci-pci.c b/drivers/usb/host/xhci-pci.c
index 3c898c12a06b..04f986d9234f 100644
--- a/drivers/usb/host/xhci-pci.c
+++ b/drivers/usb/host/xhci-pci.c
@@ -142,6 +142,11 @@ static void xhci_pci_quirks(struct device *dev, struct 
xhci_hcd *xhci)
QUIRK: Resetting on resume);
xhci-quirks |= XHCI_TRUST_TX_LENGTH;
}
+   if (pdev-vendor == PCI_VENDOR_ID_RENESAS 
+   pdev-device == 0x0015 
+   pdev-subsystem_vendor == PCI_VENDOR_ID_SAMSUNG 
+   pdev-subsystem_device == 0xc0cd)
+   xhci-quirks |= XHCI_RESET_ON_RESUME;
if (pdev-vendor == PCI_VENDOR_ID_VIA)
xhci-quirks |= XHCI_RESET_ON_RESUME;
 }
-- 
1.8.5.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

[PATCH 2/4] Revert usbcore: set lpm_capable field for LPM capable root hubs

Commit 9df89d85b407690afa46ddfbccc80bec6869971d usbcore: set
lpm_capable field for LPM capable root hubs was created under the
assumption that all USB host controllers should have USB 3.0 Link PM
enabled for all devices under the hosts.

Unfortunately, that's not the case.  The xHCI driver relies on knowledge
of the host hardware scheduler to calculate the LPM U1/U2 timeout
values, and it only sets lpm_capable to one for Intel host controllers
(that have the XHCI_LPM_SUPPORT quirk set).

When LPM is enabled for some Fresco Logic hosts, it causes failures with
a AgeStar 3UBT USB 3.0 hard drive dock:

Jan 11 13:59:03 sg-laptop kernel: usb 3-1: new SuperSpeed USB device number 2 
using xhci_hcd
Jan 11 13:59:03 sg-laptop kernel: usb 3-1: Set SEL for device-initiated U1 
failed.
Jan 11 13:59:08 sg-laptop kernel: usb 3-1: Set SEL for device-initiated U2 
failed.
Jan 11 13:59:08 sg-laptop kernel: usb-storage 3-1:1.0: USB Mass Storage device 
detected
Jan 11 13:59:08 sg-laptop mtp-probe[613]: checking bus 3, device 2: 
/sys/devices/pci:00/:00:1c.3/:04:00.0/usb3/3-1
Jan 11 13:59:08 sg-laptop mtp-probe[613]: bus: 3, device: 2 was not an MTP 
device
Jan 11 13:59:08 sg-laptop kernel: scsi6 : usb-storage 3-1:1.0
Jan 11 13:59:13 sg-laptop kernel: usb 3-1: Set SEL for device-initiated U1 
failed.
Jan 11 13:59:18 sg-laptop kernel: usb 3-1: Set SEL for device-initiated U2 
failed.
Jan 11 13:59:18 sg-laptop kernel: usbcore: registered new interface driver 
usb-storage
Jan 11 13:59:40 sg-laptop kernel: usb 3-1: reset SuperSpeed USB device number 2 
using xhci_hcd
Jan 11 13:59:41 sg-laptop kernel: usb 3-1: device descriptor read/8, error -71
Jan 11 13:59:41 sg-laptop kernel: usb 3-1: reset SuperSpeed USB device number 2 
using xhci_hcd
Jan 11 13:59:46 sg-laptop kernel: usb 3-1: device descriptor read/8, error -110
Jan 11 13:59:46 sg-laptop kernel: scsi 6:0:0:0: Device offlined - not ready 
after error recovery
Jan 11 13:59:46 sg-laptop kernel: usb 3-1: USB disconnect, device number 2

lspci for the affected host:

04:00.0 0c03: 1b73:1000 (rev 04) (prog-if 30 [XHCI])
Subsystem: 1043:1039
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast TAbort- TAbort- 
MAbort- SERR- PERR- INTx-
Latency: 0, Cache Line Size: 64 bytes
Interrupt: pin A routed to IRQ 19
Region 0: Memory at dd20 (32-bit, non-prefetchable) [size=64K]
Capabilities: [50] Power Management version 3
Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA 
PME(D0+,D1-,D2-,D3hot+,D3cold-)
Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME-
Capabilities: [68] MSI: Enable- Count=1/1 Maskable- 64bit+
Address:   Data: 
Capabilities: [80] Express (v1) Endpoint, MSI 00
DevCap: MaxPayload 128 bytes, PhantFunc 0, Latency L0s 2us, L1 
32us
ExtTag- AttnBtn- AttnInd- PwrInd- RBE+ FLReset-
DevCtl: Report errors: Correctable- Non-Fatal- Fatal- 
Unsupported-
RlxdOrd+ ExtTag- PhantFunc- AuxPwr- NoSnoop+
MaxPayload 128 bytes, MaxReadReq 512 bytes
DevSta: CorrErr- UncorrErr- FatalErr- UnsuppReq- AuxPwr- 
TransPend-
LnkCap: Port #0, Speed 2.5GT/s, Width x1, ASPM L0s L1, Latency 
L0 unlimited, L1 unlimited
ClockPM- Surprise- LLActRep- BwNot-
LnkCtl: ASPM Disabled; RCB 64 bytes Disabled- Retrain- CommClk+
ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt-
LnkSta: Speed 2.5GT/s, Width x1, TrErr- Train- SlotClk+ 
DLActive- BWMgmt- ABWMgmt-
Kernel driver in use: xhci_hcd
Kernel modules: xhci_hcd

The commit was backported to stable kernels, and will need to be
reverted there as well.

Signed-off-by: Sarah Sharp sarah.a.sh...@intel.com
Reported-by: Sergey Galanov sergey.e.gala...@gmail.com
Cc: sta...@vger.kernel.org
---
 drivers/usb/core/hcd.c | 1 -
 drivers/usb/core/hub.c | 7 +--
 drivers/usb/core/usb.h | 1 -
 3 files changed, 1 insertion(+), 8 deletions(-)

diff --git a/drivers/usb/core/hcd.c b/drivers/usb/core/hcd.c
index 199aaea6bfe0..2518c3250750 100644
--- a/drivers/usb/core/hcd.c
+++ b/drivers/usb/core/hcd.c
@@ -1032,7 +1032,6 @@ static int register_root_hub(struct usb_hcd *hcd)
dev_name(usb_dev-dev), retval);
return retval;
}
-   usb_dev-lpm_capable = usb_device_supports_lpm(usb_dev);
}
 
retval = usb_new_device (usb_dev);
diff --git a/drivers/usb/core/hub.c b/drivers/usb/core/hub.c
index babba885978d..64ea21971be2 100644
--- a/drivers/usb/core/hub.c
+++ b/drivers/usb/core/hub.c
@@ -128,7 +128,7 @@ struct usb_hub *usb_hub_to_struct_hub(struct usb_device 
*hdev)
return

[PATCH 3/4] Revert xhci: replace xhci_write_64() with writeq()

This reverts commit 7dd09a1af2c7150269350aaa567a11b06e831003.

Many xHCI host controllers can only handle 32-bit addresses, and writing
64-bits at a time causes them to fail.  Rafał reports that USB devices
simply do not enumerate, and reverting this patch helps.  Branimir
reports that his host controller doesn't respond to an Enable Slot
command and dies:

[   75.576160] xhci_hcd :03:00.0: Timeout while waiting for a slot
[   88.991634] xhci_hcd :03:00.0: Stopped the command ring failed, maybe 
the host is dead
[   88.991748] xhci_hcd :03:00.0: Abort command ring failed
[   88.991845] xhci_hcd :03:00.0: HC died; cleaning up
[   93.985489] xhci_hcd :03:00.0: Timeout while waiting for a slot
[   93.985494] xhci_hcd :03:00.0: Abort the command ring, but the xHCI is 
dead.
[   98.982586] xhci_hcd :03:00.0: Timeout while waiting for a slot
[   98.982591] xhci_hcd :03:00.0: Abort the command ring, but the xHCI is 
dead.
[  103.979696] xhci_hcd :03:00.0: Timeout while waiting for a slot
[  103.979702] xhci_hcd :03:00.0: Abort the command ring, but the xHCI is 
dead

Signed-off-by: Sarah Sharp sarah.a.sh...@intel.com
Reported-by: Rafał Miłecki zaj...@gmail.com
Reported-by: Branimir Maksimovic branimir.maksimo...@gmail.com
Cc: Xenia Ragiadakou burzalod...@gmail.com
---
 drivers/usb/host/xhci-mem.c  |  8 
 drivers/usb/host/xhci-ring.c |  8 +---
 drivers/usb/host/xhci.c  |  8 
 drivers/usb/host/xhci.h  | 29 -
 4 files changed, 33 insertions(+), 20 deletions(-)

diff --git a/drivers/usb/host/xhci-mem.c b/drivers/usb/host/xhci-mem.c
index 873c272b3ef5..4b87026f8a5a 100644
--- a/drivers/usb/host/xhci-mem.c
+++ b/drivers/usb/host/xhci-mem.c
@@ -1967,7 +1967,7 @@ static void xhci_set_hc_event_deq(struct xhci_hcd *xhci)
xhci_dbg_trace(xhci, trace_xhci_dbg_init,
// Write event ring dequeue pointer, 
preserving EHB bit);
-   writeq(((u64) deq  (u64) ~ERST_PTR_MASK) | temp,
+   xhci_write_64(xhci, ((u64) deq  (u64) ~ERST_PTR_MASK) | temp,
xhci-ir_set-erst_dequeue);
 }
 
@@ -2269,7 +2269,7 @@ int xhci_mem_init(struct xhci_hcd *xhci, gfp_t flags)
xhci_dbg_trace(xhci, trace_xhci_dbg_init,
// Device context base array address = 0x%llx (DMA), 
%p (virt),
(unsigned long long)xhci-dcbaa-dma, xhci-dcbaa);
-   writeq(dma, xhci-op_regs-dcbaa_ptr);
+   xhci_write_64(xhci, dma, xhci-op_regs-dcbaa_ptr);
 
/*
 * Initialize the ring segment pool.  The ring must be a contiguous
@@ -2318,7 +2318,7 @@ int xhci_mem_init(struct xhci_hcd *xhci, gfp_t flags)
xhci-cmd_ring-cycle_state;
xhci_dbg_trace(xhci, trace_xhci_dbg_init,
// Setting command ring address to 0x%x, val);
-   writeq(val_64, xhci-op_regs-cmd_ring);
+   xhci_write_64(xhci, val_64, xhci-op_regs-cmd_ring);
xhci_dbg_cmd_ptrs(xhci);
 
xhci-lpm_command = xhci_alloc_command(xhci, true, true, flags);
@@ -2399,7 +2399,7 @@ int xhci_mem_init(struct xhci_hcd *xhci, gfp_t flags)
val_64 = readq(xhci-ir_set-erst_base);
val_64 = ERST_PTR_MASK;
val_64 |= (xhci-erst.erst_dma_addr  (u64) ~ERST_PTR_MASK);
-   writeq(val_64, xhci-ir_set-erst_base);
+   xhci_write_64(xhci, val_64, xhci-ir_set-erst_base);
 
/* Set the event ring dequeue address */
xhci_set_hc_event_deq(xhci);
diff --git a/drivers/usb/host/xhci-ring.c b/drivers/usb/host/xhci-ring.c
index a0b248c34526..e19fae964f76 100644
--- a/drivers/usb/host/xhci-ring.c
+++ b/drivers/usb/host/xhci-ring.c
@@ -313,7 +313,8 @@ static int xhci_abort_cmd_ring(struct xhci_hcd *xhci)
return 0;
}
xhci-cmd_ring_state = CMD_RING_STATE_ABORTED;
-   writeq(temp_64 | CMD_RING_ABORT, xhci-op_regs-cmd_ring);
+   xhci_write_64(xhci, temp_64 | CMD_RING_ABORT,
+   xhci-op_regs-cmd_ring);
 
/* Section 4.6.1.2 of xHCI 1.0 spec says software should
 * time the completion od all xHCI commands, including
@@ -2865,7 +2866,8 @@ hw_died:
 * the event ring should be empty.
 */
temp_64 = readq(xhci-ir_set-erst_dequeue);
-   writeq(temp_64 | ERST_EHB, xhci-ir_set-erst_dequeue);
+   xhci_write_64(xhci, temp_64 | ERST_EHB,
+   xhci-ir_set-erst_dequeue);
spin_unlock(xhci-lock);
 
return IRQ_HANDLED;
@@ -2892,7 +2894,7 @@ hw_died:
 
/* Clear the event handler busy flag (RW1C); event ring is empty. */
temp_64 |= ERST_EHB;
-   writeq(temp_64, xhci-ir_set-erst_dequeue);
+   xhci_write_64(xhci, temp_64, xhci-ir_set-erst_dequeue);
 
spin_unlock(xhci-lock);
 
diff --git a/drivers/usb/host/xhci.c b/drivers/usb/host/xhci.c
index ad364394885a..ebbe52cafaa1 100644
---

[PATCH 4/4] Revert xhci: replace xhci_read_64() with readq()

This reverts commit e8b373326d8efcaf9ec1da8b618556c89bd5ffc4.  Many xHCI
host controllers can only handle 32-bit addresses, and writing 64-bits
at a time causes them to fail.  Reading 64-bits at a time may also cause
them to return 0x, so revert this commit as well.

Signed-off-by: Sarah Sharp sarah.a.sh...@linux.intel.com
---
 drivers/usb/host/xhci-dbg.c  |  6 +++---
 drivers/usb/host/xhci-mem.c  |  6 +++---
 drivers/usb/host/xhci-ring.c |  6 +++---
 drivers/usb/host/xhci.c  | 12 ++--
 drivers/usb/host/xhci.h  | 10 --
 5 files changed, 23 insertions(+), 17 deletions(-)

diff --git a/drivers/usb/host/xhci-dbg.c b/drivers/usb/host/xhci-dbg.c
index b016d38199f2..eb009a457fb5 100644
--- a/drivers/usb/host/xhci-dbg.c
+++ b/drivers/usb/host/xhci-dbg.c
@@ -203,12 +203,12 @@ void xhci_print_ir_set(struct xhci_hcd *xhci, int set_num)
addr, (unsigned int)temp);
 
addr = ir_set-erst_base;
-   temp_64 = readq(addr);
+   temp_64 = xhci_read_64(xhci, addr);
xhci_dbg(xhci,   %p: ir_set.erst_base = @%08llx\n,
addr, temp_64);
 
addr = ir_set-erst_dequeue;
-   temp_64 = readq(addr);
+   temp_64 = xhci_read_64(xhci, addr);
xhci_dbg(xhci,   %p: ir_set.erst_dequeue = @%08llx\n,
addr, temp_64);
 }
@@ -412,7 +412,7 @@ void xhci_dbg_cmd_ptrs(struct xhci_hcd *xhci)
 {
u64 val;
 
-   val = readq(xhci-op_regs-cmd_ring);
+   val = xhci_read_64(xhci, xhci-op_regs-cmd_ring);
xhci_dbg(xhci, // xHC command ring deq ptr low bits + flags = @%08x\n,
lower_32_bits(val));
xhci_dbg(xhci, // xHC command ring deq ptr high bits = @%08x\n,
diff --git a/drivers/usb/host/xhci-mem.c b/drivers/usb/host/xhci-mem.c
index 4b87026f8a5a..bce4391a0e7d 100644
--- a/drivers/usb/host/xhci-mem.c
+++ b/drivers/usb/host/xhci-mem.c
@@ -1958,7 +1958,7 @@ static void xhci_set_hc_event_deq(struct xhci_hcd *xhci)
xhci_warn(xhci, WARN something wrong with SW event ring 
dequeue ptr.\n);
/* Update HC event ring dequeue pointer */
-   temp = readq(xhci-ir_set-erst_dequeue);
+   temp = xhci_read_64(xhci, xhci-ir_set-erst_dequeue);
temp = ERST_PTR_MASK;
/* Don't clear the EHB bit (which is RW1C) because
 * there might be more events to service.
@@ -2312,7 +2312,7 @@ int xhci_mem_init(struct xhci_hcd *xhci, gfp_t flags)
(unsigned long long)xhci-cmd_ring-first_seg-dma);
 
/* Set the address in the Command Ring Control register */
-   val_64 = readq(xhci-op_regs-cmd_ring);
+   val_64 = xhci_read_64(xhci, xhci-op_regs-cmd_ring);
val_64 = (val_64  (u64) CMD_RING_RSVD_BITS) |
(xhci-cmd_ring-first_seg-dma  (u64) ~CMD_RING_RSVD_BITS) |
xhci-cmd_ring-cycle_state;
@@ -2396,7 +2396,7 @@ int xhci_mem_init(struct xhci_hcd *xhci, gfp_t flags)
xhci_dbg_trace(xhci, trace_xhci_dbg_init,
// Set ERST base address for ir_set 0 = 0x%llx,
(unsigned long long)xhci-erst.erst_dma_addr);
-   val_64 = readq(xhci-ir_set-erst_base);
+   val_64 = xhci_read_64(xhci, xhci-ir_set-erst_base);
val_64 = ERST_PTR_MASK;
val_64 |= (xhci-erst.erst_dma_addr  (u64) ~ERST_PTR_MASK);
xhci_write_64(xhci, val_64, xhci-ir_set-erst_base);
diff --git a/drivers/usb/host/xhci-ring.c b/drivers/usb/host/xhci-ring.c
index e19fae964f76..909b32a4412f 100644
--- a/drivers/usb/host/xhci-ring.c
+++ b/drivers/usb/host/xhci-ring.c
@@ -307,7 +307,7 @@ static int xhci_abort_cmd_ring(struct xhci_hcd *xhci)
return 0;
}
 
-   temp_64 = readq(xhci-op_regs-cmd_ring);
+   temp_64 = xhci_read_64(xhci, xhci-op_regs-cmd_ring);
if (!(temp_64  CMD_RING_RUNNING)) {
xhci_dbg(xhci, Command ring had been stopped\n);
return 0;
@@ -2865,7 +2865,7 @@ hw_died:
/* Clear the event handler busy flag (RW1C);
 * the event ring should be empty.
 */
-   temp_64 = readq(xhci-ir_set-erst_dequeue);
+   temp_64 = xhci_read_64(xhci, xhci-ir_set-erst_dequeue);
xhci_write_64(xhci, temp_64 | ERST_EHB,
xhci-ir_set-erst_dequeue);
spin_unlock(xhci-lock);
@@ -2879,7 +2879,7 @@ hw_died:
 */
while (xhci_handle_event(xhci)  0) {}
 
-   temp_64 = readq(xhci-ir_set-erst_dequeue);
+   temp_64 = xhci_read_64(xhci, xhci-ir_set-erst_dequeue);
/* If necessary, update the HW's version of the event ring deq ptr. */
if (event_ring_deq != xhci-event_ring-dequeue) {
deq = xhci_trb_virt_to_dma(xhci-event_ring-deq_seg,
diff --git a/drivers/usb/host/xhci.c b/drivers/usb/host/xhci.c
index ebbe52cafaa1..3712359d18ba 100644
--- a/drivers/usb/host/xhci.c
+++

Re: xhci and other woes

2014-02-04 Thread Mark Lord

On 14-02-04 02:10 PM, Sarah Sharp wrote:
 On Mon, Feb 03, 2014 at 04:45:14PM +, David Laight wrote:

 From the end of section 4.10.1.1 (Short transfers)
 - If the Short Packet occurred while processing a Transfer TRB with only an
   ISP flag set, then two events shall be generated for the transfer;
   one for the Transfer TRB that the short packet occurred on, and a second
   for the last TRB with the IOC flag set.
 - Software shall not interpret an Short Packet Event as indicating that the
   TD that it is associated with is “complete”, unless the TRB Pointer field
   of the Transfer Event references the last TRB of the TD.
 
 And there's code in the xHCI driver to ignore the second successful
 event.  See ep-last_td_was_short.  Yes, this is a slight race
 condition, and we should wait for the successful event.  However, we
 have not seen any issues with this race condition.
 
 Which means that the controller is obeying the rules, and the software is 
 wrong.
..
 In this case, the bug has been worked around (not perfectly), but we've
 had no customer reports that this is an issue.  There is no user-visible
 impact as far as we know.  So fixing this race condition is a really low
 priority for me, and the fix would have to very minimally touch the
 driver.
..

There are a gazillion reports out there (google) that using any XHCI
controller other than the NEC chip (and some Intel chips) causes instability,
in particular when using the AMD and VIA chips.

Right now, Linux USB3 has a very bad reputation -- buggy and unstable.
If there's a bug we/you know about, then let's get it fixed.
It could help some of those anonymous reports.

Cheers
-- 
Mark Lord
Real-Time Remedies Inc.
ml...@pobox.com
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [GIT PULL] xhci: Fix some regressions introduced in 3.14.

2014-02-04 Thread Greg Kroah-Hartman

On Tue, Feb 04, 2014 at 12:29:22PM -0800, Sarah Sharp wrote:
 The following changes since commit 2fc5a7dace3c43e62402ab4e8800a8f1834ffe2a:
 
   usb: chipidea: udc: using MultO at TD as real mult value for ISO-TX 
 (2014-01-13 15:55:19 -0800)
 
 are available in the git repository at:
 
   git://git.kernel.org/pub/scm/linux/kernel/git/sarah/xhci.git 
 tags/for-usb-linus-2014-02-04
 
 for you to fetch changes up to f7b2e4032d52deff480e0c303fbd9180276f8dfc:
 
   Revert xhci: replace xhci_read_64() with readq() (2014-01-30 13:27:49 
 -0800)
 
 
 xhci: Fix some regressions introduced in 3.14.
 
 Hi Greg,
 
 Here's four patches for 3.14.
 
 One of them adds an xHCI host quirk, and the other three of them fix
 regressions introduced in 3.14.  One regression causes USB 3.0 Link PM to
 be enabled on all xHCI hosts (even those that may not support it), which
 causes some USB 3.0 devices to not enumerate.  A second regression causes
 some xHCI hosts that don't support 64-bit addressing to stop responding to
 commands and die.
 
 Note, these patches don't fix the recent usbfs regression that was caused
 by commit 35773dac5f862cb1c82ea151eba3e2f6de51ec3e usb: xhci: Link TRB
 must not occur within a USB payload burst.  I'm waiting for those patches
 to be tested.
 
 Please pull usb-linus into usb-next, as I have feature patches that rely on
 140e3026a57a Revert usbcore: set lpm_capable field for LPM capable root
 hubs

usb-linus and usb-next are now based on 3.14-rc1, so all should be fine
for you now.

thanks,

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

Re: [GIT PULL] xhci: Fix some regressions introduced in 3.14.

2014-02-04 Thread Greg Kroah-Hartman

On Tue, Feb 04, 2014 at 12:29:22PM -0800, Sarah Sharp wrote:
 The following changes since commit 2fc5a7dace3c43e62402ab4e8800a8f1834ffe2a:
 
   usb: chipidea: udc: using MultO at TD as real mult value for ISO-TX 
 (2014-01-13 15:55:19 -0800)
 
 are available in the git repository at:
 
   git://git.kernel.org/pub/scm/linux/kernel/git/sarah/xhci.git 
 tags/for-usb-linus-2014-02-04

Pulled and pushed out, thanks.

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

RE: [PATCHv2] usb: dwc2: Handle the Host Port Interrupt when it occurs in device mode

 From: dingu...@altera.com [mailto:dingu...@altera.com]
 Sent: Tuesday, February 04, 2014 8:11 AM
 
 According to the spec for the DWC2 controller, when the PRTINT interrupt 
 fires,
 the application must clear the appropriate status bit in the Host Port Control
 and Status register to clear this bit.
 
 When disconnecting an A-cable when the dwc2 host driver, the PRTINT fires, but
 only the GINTSTS_PRTINT status is cleared, no action is done with the HPRT0
 register. The HPRT0_ENACHG bit in the HPRT0 must also be poked to correctly
 clear the GINTSTS_PRTINT interrupt.
 
 I am seeing this behavoir on v2.93 of the DWC2 IP. When I disconnect an OTG
 A-cable adapter, the PRTINT interrupt fires when the DWC2 is in device mode
 and is never cleared.
 
 This patch adds the function to read the HPRT0 register when the PRTINT fires
 and the dwc2 IP has already transitioned to device mode. This function is only
 clearing the HPRT0_ENACHG bit for now, but can be modified to handle more.
 
 Signed-off-by: Dinh Nguyen dingu...@altera.com
 Cc: Paul Zimmerman pa...@synopsys.com
 Cc: Matt Porter mpor...@linaro.org
 Cc: Matthijs Kooijman matth...@stdin.nl
 ---
 v2: only need to call dwc2_handle_usb_port_intr() once
 ---
  drivers/usb/dwc2/core_intr.c |   18 ++
  1 file changed, 18 insertions(+)
 
 diff --git a/drivers/usb/dwc2/core_intr.c b/drivers/usb/dwc2/core_intr.c
 index bad298a..e037ad5 100644
 --- a/drivers/usb/dwc2/core_intr.c
 +++ b/drivers/usb/dwc2/core_intr.c
 @@ -72,6 +72,23 @@ static const char *dwc2_op_state_str(struct dwc2_hsotg 
 *hsotg)
  }
 
  /**
 + * dwc2_handle_usb_port_intr - handles OTG PRTINT interrupts.
 + * When the PRTINT interrupt fires, there are certain status bits in the Host
 + * Port that needs to get cleared.
 + *
 + * @hsotg: Programming view of DWC_otg controller
 + */
 +static void dwc2_handle_usb_port_intr(struct dwc2_hsotg *hsotg)
 +{
 + u32 hprt0 = readl(hsotg-regs + HPRT0);
 +
 + if (hprt0  HPRT0_ENACHG) {
 + hprt0 |= HPRT0_ENACHG;
 + writel(hprt0, hsotg-regs + HPRT0);
 + }
 +}

Hi Dinh,

On second thought, I'm not sure it is safe to blindly write to HPRT0
like this. There is the write-1-to-clear HPRT0_ENA bit in there that
could cause the port to get disabled by this write.

 +/**
   * dwc2_handle_mode_mismatch_intr() - Logs a mode mismatch warning message
   *
   * @hsotg: Programming view of DWC_otg controller
 @@ -572,6 +589,7 @@ irq_retry:
   if (dwc2_is_device_mode(hsotg)) {
   dev_dbg(hsotg-dev,
--Port interrupt received in Device 
 mode--\n);
 + dwc2_handle_usb_port_intr(hsotg);
   gintsts = GINTSTS_PRTINT;
   writel(gintsts, hsotg-regs + GINTSTS);
   retval = 1;

Also, for consistency the write to GINTSTS should be done inside
dwc2_handle_usb_port_intr() like is done for all the other handlers.

So, something like the attached alternate patch. Does it also work for
you?

-- 
Paul



dwc2-hprt0.patch
Description: dwc2-hprt0.patch

[RFC PATCHv1] usb: dwc2: Combine dwc2/s3c-hsotg into a single DRD

2014-02-04 Thread dinguyen

From: Dinh Nguyen dingu...@altera.com

Hello,

This patch is my first attempt in combining the Synopsys DWC2 host and the
s3c-hsotg peripheral into a single dual-role driver.

The patch:

* Moves the s3c-hsotg driver into the dwc2 folder.
* Adds the gadget data structure into the dwc2_hsotg data structure.
* Replace the s3c-hsotg.h defines with the hw.h defines in dwc2
* Uses the otg clock for both host/peripheral.
* Uses the dwc2_handle_common_intr() IRQ handler for both modes.

I have only been able to test the driver on the SOCFPGA platform, which has
v2.93a of the dual-role core.

Any comments and testing would be greatly appreciated.

Thanks,

Dinh Nguyen (1):
  usb: dwc2: Combine the dwc2 and s3c_hsotg into a single USB DRD
driver.

 drivers/usb/dwc2/Kconfig |   35 +-
 drivers/usb/dwc2/Makefile|2 +
 drivers/usb/dwc2/core.c  |1 +
 drivers/usb/dwc2/core.h  |  173 ++-
 drivers/usb/dwc2/core_intr.c |  134 ++-
 drivers/usb/dwc2/hcd.c   |7 +-
 drivers/usb/dwc2/hcd.h   |1 +
 drivers/usb/dwc2/hw.h|   23 +-
 drivers/usb/dwc2/platform.c  |   49 +-
 drivers/usb/{gadget = dwc2}/s3c-hsotg.c | 1835 --
 drivers/usb/gadget/Kconfig   |7 -
 drivers/usb/gadget/Makefile  |1 -
 drivers/usb/gadget/s3c-hsotg.h   |  378 --
 13 files changed, 1088 insertions(+), 1558 deletions(-)
 rename drivers/usb/{gadget = dwc2}/s3c-hsotg.c (57%)
 delete mode 100644 drivers/usb/gadget/s3c-hsotg.h
---
Cc: Greg Kroah-Hartman gre...@linuxfoundation.org
Cc: Paul Zimmerman pa...@synopsys.com
Cc: Felipe Balbi ba...@ti.com
Cc: Ben Dooks ben-li...@fluff.org
Cc: Matt Porter mpor...@linaro.org
Cc: Kukjin Kim kgene@samsung.com
Cc: Stephen Warren swar...@wwwdotorg.org
Cc: Matthijs Kooijman matth...@stdin.nl
Cc: Fengguang Wu fengguang...@intel.com
Cc: Dan Carpenter dan.carpen...@oracle.com
Cc: Wei Yongjun yongjun_...@trendmicro.com.cn
Cc: Wolfram Sang w...@the-dreams.de
Cc: Yijing Wang wangyij...@huawei.com
Cc: Ray Jui r...@broadcom.com
Cc: Julien Delacou julien.dela...@stericsson.com
Cc: Dom Cobley popcorn...@gmail.com
Cc: Rashika Kheria rashika.khe...@gmail.com
Cc: Jingoo Han jg1@samsung.com
Cc: Sachin Kamat sachin.ka...@linaro.org
Cc: Robert Baldyga r.bald...@samsung.com
Cc: Kishon Vijay Abraham I kis...@ti.com

-- 
1.7.9.5

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

RE: [PATCHv2] usb: dwc2: Handle the Host Port Interrupt when it occurs in device mode

2014-02-04 Thread Dinh Nguyen

On Tue, 2014-02-04 at 21:43 +, Paul Zimmerman wrote:
  From: dingu...@altera.com [mailto:dingu...@altera.com]
  Sent: Tuesday, February 04, 2014 8:11 AM
  
  According to the spec for the DWC2 controller, when the PRTINT interrupt 
  fires,
  the application must clear the appropriate status bit in the Host Port 
  Control
  and Status register to clear this bit.
  
  When disconnecting an A-cable when the dwc2 host driver, the PRTINT fires, 
  but
  only the GINTSTS_PRTINT status is cleared, no action is done with the HPRT0
  register. The HPRT0_ENACHG bit in the HPRT0 must also be poked to correctly
  clear the GINTSTS_PRTINT interrupt.
  
  I am seeing this behavoir on v2.93 of the DWC2 IP. When I disconnect an OTG
  A-cable adapter, the PRTINT interrupt fires when the DWC2 is in device mode
  and is never cleared.
  
  This patch adds the function to read the HPRT0 register when the PRTINT 
  fires
  and the dwc2 IP has already transitioned to device mode. This function is 
  only
  clearing the HPRT0_ENACHG bit for now, but can be modified to handle more.
  
  Signed-off-by: Dinh Nguyen dingu...@altera.com
  Cc: Paul Zimmerman pa...@synopsys.com
  Cc: Matt Porter mpor...@linaro.org
  Cc: Matthijs Kooijman matth...@stdin.nl
  ---
  v2: only need to call dwc2_handle_usb_port_intr() once
  ---
   drivers/usb/dwc2/core_intr.c |   18 ++
   1 file changed, 18 insertions(+)
  
  diff --git a/drivers/usb/dwc2/core_intr.c b/drivers/usb/dwc2/core_intr.c
  index bad298a..e037ad5 100644
  --- a/drivers/usb/dwc2/core_intr.c
  +++ b/drivers/usb/dwc2/core_intr.c
  @@ -72,6 +72,23 @@ static const char *dwc2_op_state_str(struct dwc2_hsotg 
  *hsotg)
   }
  
   /**
  + * dwc2_handle_usb_port_intr - handles OTG PRTINT interrupts.
  + * When the PRTINT interrupt fires, there are certain status bits in the 
  Host
  + * Port that needs to get cleared.
  + *
  + * @hsotg: Programming view of DWC_otg controller
  + */
  +static void dwc2_handle_usb_port_intr(struct dwc2_hsotg *hsotg)
  +{
  +   u32 hprt0 = readl(hsotg-regs + HPRT0);
  +
  +   if (hprt0  HPRT0_ENACHG) {
  +   hprt0 |= HPRT0_ENACHG;
  +   writel(hprt0, hsotg-regs + HPRT0);
  +   }
  +}
 
 Hi Dinh,
 
 On second thought, I'm not sure it is safe to blindly write to HPRT0
 like this. There is the write-1-to-clear HPRT0_ENA bit in there that
 could cause the port to get disabled by this write.
 
  +/**
* dwc2_handle_mode_mismatch_intr() - Logs a mode mismatch warning message
*
* @hsotg: Programming view of DWC_otg controller
  @@ -572,6 +589,7 @@ irq_retry:
  if (dwc2_is_device_mode(hsotg)) {
  dev_dbg(hsotg-dev,
   --Port interrupt received in Device 
  mode--\n);
  +   dwc2_handle_usb_port_intr(hsotg);
  gintsts = GINTSTS_PRTINT;
  writel(gintsts, hsotg-regs + GINTSTS);
  retval = 1;
 
 Also, for consistency the write to GINTSTS should be done inside
 dwc2_handle_usb_port_intr() like is done for all the other handlers.
 
 So, something like the attached alternate patch. Does it also work for
 you?
 

Yes, the attached patch also works for me.

Thanks,
Dinh


--
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: gadgetfs USB2.0 Chapter 9 Tests: Test after Addressed State fails

2014-02-04 Thread Jack Pham

On Tue, Dec 24, 2013 at 05:14:29PM +0100, Michal Nazarewicz wrote:
This is a bug in user space. FUNCTIONFS_DISABLE event means the host
has chosen a configuration with given function disabled. User-space
should clean up it's state, as any pending requests of any kind are
now invalid. It should not close all of the ep files.

On Tue, Dec 24 2013, roshan.jhal...@broadcom.com wrote:
Then, I would say this bug exists in both Android 4.2 and Android 4.4
version. But we are facing issue in Android 4.4 because kernel uses
FunctionFs instead of f_adb.c.

That may be the case.

Do you think this should be ONLY fixed in user space or we can avoid
all ep releases in kernel?

I think this should be fixed in user space since kernel space behaves as
it always has and as advertised[1].

Hi Roshan,

I believe I ran into the same issue you faced when using the ADB daemon
with FunctionFS, and submitted a patch to Android upstream:

https://android.googlesource.com/platform/system/core/+/4cbf1d882236462482b8e22893061604b224e308

I figured out that the fix was to hang on to the ep0 file handle, and
not always close it, which Michal corroborated in his previous reply.

Hope this helps in your case as well.
Jack
--
Employee of Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by The Linux Foundation
--
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: [RFT] xHCI TD fragment revert

2014-02-04 Thread Mark Lord

On 14-02-04 03:11 PM, Sarah Sharp wrote:
 Hi Mark and David,
 
 Can you test the following two patches against 3.13?
 
 Please make sure the adapter works when it's plugged directly into a USB
 3.0 port and when it's plugged into a USB 2.0 hub.
..
 are available in the git repository at:
 
   git://git.kernel.org/pub/scm/linux/kernel/git/sarah/xhci.git 
 3.13-td-changes-reverted
 
 for you to fetch changes up to 4327645d0e03dad2e2ec4480cb43f30a2d1a6d20:

I tested against the git tree (rather than patching 3.13.x).
Seems to work fine here, thanks.
-- 
Mark Lord
Real-Time Remedies Inc.
ml...@pobox.com
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v3] usb: dwc2: handle the Host Port Interrupt when it occurs in device mode

From: Dinh Nguyen dingu...@altera.com

According to the spec for the DWC2 controller, when the PRTINT interrupt fires,
the application must clear the appropriate status bit in the Host Port Control
and Status register to clear this bit.

When disconnecting an A-cable when the dwc2 host driver, the PRTINT fires, but
only the GINTSTS_PRTINT status is cleared, no action is done with the HPRT0
register. The HPRT0_ENACHG bit in the HPRT0 must also be poked to correctly
clear the GINTSTS_PRTINT interrupt.

I am seeing this behavoir on v2.93 of the DWC2 IP. When I disconnect an OTG
A-cable adapter, the PRTINT interrupt fires when the DWC2 is in device mode
and is never cleared.

This patch adds the function to read the HPRT0 register when the PRTINT fires
and the dwc2 IP has already transitioned to device mode. This function is only
clearing the HPRT0_ENACHG bit for now, but can be modified to handle more.

Signed-off-by: Dinh Nguyen dingu...@altera.com
[ paulz: modified patch to preserve HPRT0_ENA bit ]
Signed-off-by: Paul Zimmerman pa...@synopsys.com
---
 drivers/usb/dwc2/core_intr.c | 25 ++---
 1 file changed, 22 insertions(+), 3 deletions(-)

diff --git a/drivers/usb/dwc2/core_intr.c b/drivers/usb/dwc2/core_intr.c
index 8205799..c93918b 100644
--- a/drivers/usb/dwc2/core_intr.c
+++ b/drivers/usb/dwc2/core_intr.c
@@ -72,6 +72,26 @@ static const char *dwc2_op_state_str(struct dwc2_hsotg 
*hsotg)
 }
 
 /**
+ * dwc2_handle_usb_port_intr - handles OTG PRTINT interrupts.
+ * When the PRTINT interrupt fires, there are certain status bits in the Host
+ * Port that needs to get cleared.
+ *
+ * @hsotg: Programming view of DWC_otg controller
+ */
+static void dwc2_handle_usb_port_intr(struct dwc2_hsotg *hsotg)
+{
+   u32 hprt0 = readl(hsotg-regs + HPRT0);
+
+   if (hprt0  HPRT0_ENACHG) {
+   hprt0 = ~HPRT0_ENA;
+   writel(hprt0, hsotg-regs + HPRT0);
+   }
+
+   /* Clear interrupt */
+   writel(GINTSTS_PRTINT, hsotg-regs + GINTSTS);
+}
+
+/**
  * dwc2_handle_mode_mismatch_intr() - Logs a mode mismatch warning message
  *
  * @hsotg: Programming view of DWC_otg controller
@@ -479,9 +499,8 @@ irqreturn_t dwc2_handle_common_intr(int irq, void *dev)
if (dwc2_is_device_mode(hsotg)) {
dev_dbg(hsotg-dev,
 --Port interrupt received in Device 
mode--\n);
-   gintsts = GINTSTS_PRTINT;
-   writel(gintsts, hsotg-regs + GINTSTS);
-   retval = 1;
+   dwc2_handle_usb_port_intr(hsotg);
+   retval = IRQ_HANDLED;
}
}
 
-- 
1.8.5

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

Re: [RFT] xHCI TD fragment revert

2014-02-04 Thread Mark Lord

On 14-02-04 05:55 PM, Mark Lord wrote:
 On 14-02-04 03:11 PM, Sarah Sharp wrote:
 Hi Mark and David,

 Can you test the following two patches against 3.13?

 Please make sure the adapter works when it's plugged directly into a USB
 3.0 port and when it's plugged into a USB 2.0 hub.
 ..
 are available in the git repository at:

   git://git.kernel.org/pub/scm/linux/kernel/git/sarah/xhci.git 
 3.13-td-changes-reverted

 for you to fetch changes up to 4327645d0e03dad2e2ec4480cb43f30a2d1a6d20:
 
 I tested against the git tree (rather than patching 3.13.x).
 Seems to work fine here, thanks.

And now I've tested the two patches, applied against 3.13.1.  All Okay again.
-- 
Mark Lord
Real-Time Remedies Inc.
ml...@pobox.com
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: [RFC PATCHv1] usb: dwc2: Combine the dwc2 and s3c_hsotg into a single USB DRD driver.