RE: Not enough resource for old configuration after USB bus reset

> I try the same operation to produce the issue, and it >> also fails. Please attach the output of dmesg with CONFIG_USB_DEBUG and XHCI_DEBUG. >>> >>> With these two debug config on, the dmesg buffer even can not log >>> one reset operation. >> >> You can increase your buffer size

RE: Not enough resource for old configuration after USB bus reset

linux-usb-ow...@vger.kernel.org wrote: > On Mon, Feb 25, 2013 at 01:42:44PM +0200, Felipe Balbi wrote: >> HI, >> >> On Mon, Feb 25, 2013 at 07:33:23PM +0800, Soar Hung wrote: What's the actual issue here ? Can you explain to me Sarah ? This may be a known issue regarding this particular

RE: Not enough resource for old configuration after USB bus reset

> Can you send me the output of `sudo lspci -vvv` and `sudo > lspci -vvv -n` when the TI host is attached to your system? > I'll send you a patch with the workaround fix to test. We > can also add a quirk for your host, if your host controller > is already available with this issue, and you're pl

RE: Not enough resource for old configuration after USB bus reset

I try the same operation to produce the issue, and it > also fails. >>> Please attach the output of dmesg with CONFIG_USB_DEBUG and >>> XHCI_DEBUG. >> >> With these two debug config on, the dmesg buffer even can not log >> one reset operation. > > You can increase your buffer size by setti

Re: [PATCH] usb/net/asix_devices: Add USBNET HG20F9 ethernet dongle

On Tue, Feb 26, 2013 at 12:10:22AM -0500, David Miller wrote: > From: Greg KH > Date: Mon, 25 Feb 2013 21:03:11 -0800 > > > On Mon, Feb 25, 2013 at 11:45:29PM -0500, David Miller wrote: > >> From: Greg Kroah-Hartman > >> Date: Mon, 25 Feb 2013 20:23:43 -0800 > >> > >> > On Tue, Feb 26, 2013 at

[PATCH] usb/net/asix_devices: Add USBNET HG20F9 ethernet dongle

This USB ethernet adapter was purchased in anodyne packaging marked "USB2.0 to LAN" from the computer store adjacent to linux.conf.au 2013 in Canberra (Australia). A web search shows other recent purchasers in Lancaster (UK) and Seattle (USA). Just like an emergent virus, our age of e-commerce and

Re: [PATCH] usb/net/asix_devices: Add USBNET HG20F9 ethernet dongle

From: Greg KH Date: Mon, 25 Feb 2013 21:03:11 -0800 > On Mon, Feb 25, 2013 at 11:45:29PM -0500, David Miller wrote: >> From: Greg Kroah-Hartman >> Date: Mon, 25 Feb 2013 20:23:43 -0800 >> >> > On Tue, Feb 26, 2013 at 02:47:12PM +1030, Glen Turner wrote: >> >> This USB ethernet adapter was purch

RE: Not enough resource for old configuration after USB bus reset

Hi all, thanks for your help. > I just ran 10K resets with each of 3 different devices (USB3 > HDD, USB2 pendrive and a mouse) and I didn't see the problem you're > saying here. > > Tested with TUSB7340EVM on v3.8.0. Maybe I can try this with the mouse. As far as I know, most HDD and pendrive

Re: [PATCH] usb/net/asix_devices: Add USBNET HG20F9 ethernet dongle

On Mon, Feb 25, 2013 at 11:45:29PM -0500, David Miller wrote: > From: Greg Kroah-Hartman > Date: Mon, 25 Feb 2013 20:23:43 -0800 > > > On Tue, Feb 26, 2013 at 02:47:12PM +1030, Glen Turner wrote: > >> This USB ethernet adapter was purchased in anodyne packaging > >> marked "USB2.0 to LAN" from th

Re: [PATCH] usb/net/asix_devices: Add USBNET HG20F9 ethernet dongle

From: Greg Kroah-Hartman Date: Mon, 25 Feb 2013 20:23:43 -0800 > On Tue, Feb 26, 2013 at 02:47:12PM +1030, Glen Turner wrote: >> This USB ethernet adapter was purchased in anodyne packaging >> marked "USB2.0 to LAN" from the computer store adjacent to >> linux.conf.au 2013 in Canberra (Australia)

Re: [PATCH] usb/net/asix_devices: Add USBNET HG20F9 ethernet dongle

On Tue, Feb 26, 2013 at 02:47:12PM +1030, Glen Turner wrote: > This USB ethernet adapter was purchased in anodyne packaging > marked "USB2.0 to LAN" from the computer store adjacent to > linux.conf.au 2013 in Canberra (Australia). A web search > shows other recent purchasers in Lancaster (UK) and S

Re: carl9170 A-MPDU transmit problem

On Monday, February 25, 2013 09:19:03 PM Alan Stern wrote: > On Mon, 25 Feb 2013, Seth Forshee wrote: > > > > >88012fe19500 1519981417 S Bo:3:003:1 -115 126 = 7e00 ... <-- > > > > >DATA > > > > > > > > > > [... long period where the device receives commands on EP4 and sends > > > > > wifi

Re: carl9170 A-MPDU transmit problem

On Mon, Feb 25, 2013 at 01:46:23PM -0600, Seth Forshee wrote: > > Which kernel version are you testing under? Can you please recompile > > with CONFIG_USB_DEBUG and CONFIG_USB_XHCI_HCD_DEBUGGING turned on, and > > send me dmesg? I should be able to see if there's an unhandled pending > > event on

Bug in xHCI command cancellation

Hi Elric, I was looking at the xHCI command cancellation code, and I realized that xhci_cancel_cmd() calls xhci_abort_cmd_ring() with the xHCI spinlock held. That function spins for up to 5 seconds, waiting for the command ring running bit to be clear. We really can't have the spinlock held for

Re: Not enough resource for old configuration after USB bus reset

On Mon, Feb 25, 2013 at 04:38:06PM +0800, Soar Hung wrote: > > > -Original Message- > > From: Lan Tianyu [mailto:lantianyu1...@gmail.com] > > Sent: Wednesday, February 20, 2013 4:14 PM > > To: Soar Hung > > Cc: Alan Stern; Sarah Sharp; linux-usb@vger.kernel.org > > Subject: Re: Not enough

Re: [PATCH v4] xhci - correct comp_mode_recovery_timer on return from hibernate

On Mon, 25 Feb 2013, Tony Camuso wrote: > On 02/21/2013 05:04 PM, Alan Stern wrote: > > > > Would it be simpler to delete the timer in xhci_bus_suspend() and > > restart it in xhci_bus_resume()? Then you wouldn't need to care > > about the difference between suspend and hibernation. > > > > Alan

Re: [PATCH v4] xhci - correct comp_mode_recovery_timer on return from hibernate

On 02/21/2013 05:04 PM, Alan Stern wrote: Would it be simpler to delete the timer in xhci_bus_suspend() and restart it in xhci_bus_resume()? Then you wouldn't need to care about the difference between suspend and hibernation. Alan, I tried implementing this. There were some static functions

Re: Testing for hardware bug in EHCI controllers

On Mon, Feb 25, 2013 at 03:54:22PM -0500, Alan Stern wrote: > Sarah (and anyone else who's interested): > > A while ago I wrote about a hardware bug in my Intel ICH5 and ICH8 EHCI > controllers. You pointed out that these are rather old components, not > being used in current systems, which is q

Testing for hardware bug in EHCI controllers

Sarah (and anyone else who's interested): A while ago I wrote about a hardware bug in my Intel ICH5 and ICH8 EHCI controllers. You pointed out that these are rather old components, not being used in current systems, which is quite true. Now I have figured out a simple way for anyone to test for

Re: [PATCH 0/3] usbnet: smsc95xx: fix smsc95xx_suspend

From: Ming Lei Date: Fri, 22 Feb 2013 21:05:02 +0800 > The 1st two patches fix smsc95xx_suspend, and the 1st one should > be backported to 3.8. > > The last one is to rename the misleading FEATURE_AUTOSUSPEND. All applied, thanks. -- To unsubscribe from this list: send the line "unsubscribe lin

Re: Not enough resource for old configuration after USB bus reset

Hi, On Mon, Feb 25, 2013 at 09:32:51AM -0800, Sarah Sharp wrote: > > > > If the problem is related only to device reset, then it would > > > > have failed USB30CV Device Reset test which drives 500 Device > > > > Resets and checks that device reenumerates. I doubt that's > > > > the case though, s

Re: carl9170 A-MPDU transmit problem

On Mon, Feb 25, 2013 at 11:13:57AM -0800, Sarah Sharp wrote: > Which kernel version are you testing under? Forgot to answer this. I'm running 3.8 on these machines. Seth -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org

Re: carl9170 A-MPDU transmit problem

On Mon, 25 Feb 2013, Seth Forshee wrote: > > > >88012fe19500 1519981417 S Bo:3:003:1 -115 126 = 7e00 ... <-- DATA > > > > > > > > [... long period where the device receives commands on EP4 and sends > > > > wifi data to the host via EP2 - so it is working!] > > > > > > > >880146c8af00

Re: carl9170 A-MPDU transmit problem

On Monday, February 25, 2013 08:46:23 PM Seth Forshee wrote: > On Mon, Feb 25, 2013 at 11:13:57AM -0800, Sarah Sharp wrote: > > Hmm, yeah, that kind of points to an Intel xHCI hardware issue. It's > > too bad you don't have a USB analyzer (the high speed ones are about > > $480). Can you send me

Re: carl9170 A-MPDU transmit problem

On Mon, Feb 25, 2013 at 11:13:57AM -0800, Sarah Sharp wrote: > On Mon, Feb 25, 2013 at 05:03:40PM +0100, Christian Lamparter wrote: > > On Monday, February 25, 2013 04:29:55 PM Alan Stern wrote: > > > On Mon, 25 Feb 2013, Christian Lamparter wrote: > > One detail that might be important (to keep in

[PATCH 3/4] usb: gadget: imx_udc: fix gadget->dev registration

Whenever ->udc_start() gets called, gadget driver has already being bound to the udc controller, which means that gadget->dev had to be already initialized and added to driver model. This patch fixes imx_udc mistake. Signed-off-by: Felipe Balbi --- drivers/usb/gadget/imx_udc.c | 20

[PATCH 4/4] usb: gadget: s3c2410: fix build breakage

add missing semicolon to fix compile breakage. Signed-off-by: Felipe Balbi --- drivers/usb/gadget/s3c2410_udc.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/usb/gadget/s3c2410_udc.c b/drivers/usb/gadget/s3c2410_udc.c index 9404858..08f8965 100644 --- a/drivers/usb/

[PATCH 1/4] usb: gadget: s3c2410: fix gadget->dev registration

Whenever ->udc_start() gets called, gadget driver has already being bound to the udc controller, which means that gadget->dev had to be already initialized and added to driver model. This patch fixes s3c2410 mistake. Signed-off-by: Felipe Balbi --- drivers/usb/gadget/s3c2410_udc.c | 26

[PATCH 2/4] usb: gadget: pxa25x: fix gadget->dev registration

Whenever ->udc_start() gets called, gadget driver has already being bound to the udc controller, which means that gadget->dev had to be already initialized and added to driver model. This patch fixes pxa25x mistake. Signed-off-by: Felipe Balbi --- drivers/usb/gadget/pxa25x_udc.c | 20 ++

Re: carl9170 A-MPDU transmit problem

On Mon, Feb 25, 2013 at 05:03:40PM +0100, Christian Lamparter wrote: > On Monday, February 25, 2013 04:29:55 PM Alan Stern wrote: > > On Mon, 25 Feb 2013, Christian Lamparter wrote: > One detail that might be important (to keep in mind): > > Original report

Re: linux-next and usb gadget composite BUG

On Mon, Feb 25, 2013 at 07:16:26PM +0100, Robert Jarzmik wrote: > Felipe Balbi writes: > > > this is not caused by current pull request. Well, you could argue that > > commit 70189a63d408d4ea0cddbf0ff0afe6020844e813 (usb: gadget: > > pxa27x_udc: convert to udc_start/udc_stop) is the culprit, but

[RESEND PATCH] USB: xhci - fix bit definitions for IMAN register

According to XHCI specification (5.5.2.1) the IP is bit 0 and IE is bit 1 of IMAN register. Previously their definitions were reversed. Even though there are no ill effects being observed from the swapped definitions (because IMAN_IP is RW1C and in legacy PCI case we come in with it already set to

Re: linux-next and usb gadget composite BUG

Felipe Balbi writes: > this is not caused by current pull request. Well, you could argue that > commit 70189a63d408d4ea0cddbf0ff0afe6020844e813 (usb: gadget: > pxa27x_udc: convert to udc_start/udc_stop) is the culprit, but the fact > is that what pxa27x is doing is pretty wrong. No need to argue,

Re: Not enough resource for old configuration after USB bus reset

On Mon, Feb 25, 2013 at 01:42:44PM +0200, Felipe Balbi wrote: > HI, > > On Mon, Feb 25, 2013 at 07:33:23PM +0800, Soar Hung wrote: > > > What's the actual issue here ? Can you explain to me Sarah ? > > > This may be a known issue regarding this particular host > > > controller and if it is, there

Re: [PATCH] usb: otg: use try_module_get in all usb_get_phy functions and add missing module_put

On 02/25/2013 05:54 PM, Felipe Balbi wrote: >> Hello, >> >> this patch got lost somehow, it applies to current linus/master (pre >> v3.9-rc1). >> Please apply. > > I'll take it once v3.9-rc1 is tagged, thanks tnx, Marc -- Pengutronix e.K. | Marc Kleine-Budde | Indust

Re: [PATCH] usb: otg: use try_module_get in all usb_get_phy functions and add missing module_put

On Mon, Feb 25, 2013 at 05:15:46PM +0100, Michael Grzeschik wrote: > From: Marc Kleine-Budde > > In patch "5d3c28b usb: otg: add device tree support to otg library" > devm_usb_get_phy_by_phandle() was added. It uses try_module_get() to lock the > phy driver in memory. The corresponding module_put

[PATCH] usb: otg: use try_module_get in all usb_get_phy functions and add missing module_put

From: Marc Kleine-Budde In patch "5d3c28b usb: otg: add device tree support to otg library" devm_usb_get_phy_by_phandle() was added. It uses try_module_get() to lock the phy driver in memory. The corresponding module_put() is missing in that patch. This patch adds try_module_get() to usb_get_phy

Re: carl9170 A-MPDU transmit problem

On Monday, February 25, 2013 04:29:55 PM Alan Stern wrote: > On Mon, 25 Feb 2013, Christian Lamparter wrote: > > > In fact this is both normal and required. Packets to any particular > > > endpoint must always be delivered in order. Therefore the URBs have > > > to complete in the same order as

Re: carl9170 A-MPDU transmit problem

On Mon, 25 Feb 2013, Christian Lamparter wrote: > > In fact this is both normal and required. Packets to any particular > > endpoint must always be delivered in order. Therefore the URBs have > > to complete in the same order as they were submitted. > Yes, I know that ;). I guess I should have

Re: [PATCH] USB: remove incorrect __exit markups

On Sun, 24 Feb 2013, Dmitry Torokhov wrote: > Even if bus is not hot-pluggable, the devices can be unbound from the > driver via sysfs, so we should not be using __exit annotations on > remove() methods. The only exception is drivers registered with > platform_driver_probe() which specifically dis

Re: carl9170 A-MPDU transmit problem

On Monday, February 25, 2013 12:41:06 AM Alan Stern wrote: > On Sun, 24 Feb 2013, Christian Lamparter wrote: > > > > The usbmon trace indicates that the data gets delivered to the device > > > as it should, but the device doesn't accept it for several seconds. > > > > Looking at the logs, I find

Re: carl9170 A-MPDU transmit problem

On Sun, Feb 24, 2013 at 06:41:06PM -0500, Alan Stern wrote: > > Or can you think of any other "interesting" > > bits that could help to explain why the "Arrandale box [...] worked > > perfectly" whereas (all his) Ivy Bridge ones have problems. > > (Of course, I assume that it is always the same de

Re: carl9170 A-MPDU transmit problem

On Sun, Feb 24, 2013 at 11:30:56PM +0100, Christian Lamparter wrote: > Did you plug the DWA-160 device into a USB 3.0 port on your ivy bridge > system or does it react in the same way on the 'legacy' USB 2.0 ports as > well [so we are not comparing xhci (Ivy Bridge) to ehci (Arrandale)]? Those two

Re: Not enough resource for old configuration after USB bus reset

Hi, On Mon, Feb 25, 2013 at 02:03:56PM +0200, Felipe Balbi wrote: > On Mon, Feb 25, 2013 at 07:56:49PM +0800, Soar Hung wrote: > > >> Then add_endpoint to enable these endpoints. > > >> After all drop add flag are set, HCD sends a configure endpoint > > >> command to complete the change. > > > >

Re: Unable to reinsert the am35x MUSB module

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 01/20/13 13:27, Igor Grinberg wrote: > On 01/18/13 20:58, Felipe Balbi wrote: >> Hi, > >> On Sun, Dec 02, 2012 at 05:33:36PM +0200, Dmitry Lifshitz wrote: >>> Hi, >>> >>> We are running kernel v3.5.7 on am3517 based hardware (CM-T3517 module). >>>

Re: Not enough resource for old configuration after USB bus reset

Hi, On Mon, Feb 25, 2013 at 07:56:49PM +0800, Soar Hung wrote: > >> Then add_endpoint to enable these endpoints. > >> After all drop add flag are set, HCD sends a configure endpoint > >> command to complete the change. > > > > right. > > > >> Before the priodic bandiwdth is used up, the configur

RE: Not enough resource for old configuration after USB bus reset

Felipe Balbi wrote: > HI, > > On Mon, Feb 25, 2013 at 07:33:23PM +0800, Soar Hung wrote: >>> What's the actual issue here ? Can you explain to me Sarah ? >>> This may be a known issue regarding this particular host controller >>> and if it is, there might already be workarounds available. >> >> I

Re: Not enough resource for old configuration after USB bus reset

HI, On Mon, Feb 25, 2013 at 07:33:23PM +0800, Soar Hung wrote: > > What's the actual issue here ? Can you explain to me Sarah ? > > This may be a known issue regarding this particular host > > controller and if it is, there might already be workarounds available. > > I copy the previous content an

RE: Not enough resource for old configuration after USB bus reset

> What's the actual issue here ? Can you explain to me Sarah ? > This may be a known issue regarding this particular host > controller and if it is, there might already be workarounds available. > I copy the previous content and try to make it more clear. When calling usb_reset_and_verify_de

Re: [PATCH RFC] usb: dwc3: Set GCTL.PrtCapDir based on selected mode.

On Mon, Feb 25, 2013 at 2:49 PM, Felipe Balbi wrote: > Hi, > > On Mon, Feb 25, 2013 at 02:21:46PM +0530, Vivek Gautam wrote: >> >> @@ -514,6 +511,14 @@ static int dwc3_probe(struct platform_device *pdev) >> >> } >> >> dwc->mode = mode; >> >> >> >> +#if IS_ENABLED(CONFIG_USB_DWC3_HOST)

Re: [PATCH RFC] usb: dwc3: Set GCTL.PrtCapDir based on selected mode.

Hi, On Mon, Feb 25, 2013 at 02:21:46PM +0530, Vivek Gautam wrote: > >> @@ -514,6 +511,14 @@ static int dwc3_probe(struct platform_device *pdev) > >> } > >> dwc->mode = mode; > >> > >> +#if IS_ENABLED(CONFIG_USB_DWC3_HOST) > >> + dwc3_set_mode(dwc, DWC3_GCTL_PRTCAP_HOST); > >> +#eli

Re: Not enough resource for old configuration after USB bus reset

Hi, On Wed, Feb 20, 2013 at 11:53:26AM -0800, Sarah Sharp wrote: > On Wed, Feb 20, 2013 at 10:14:46AM -0800, Sarah Sharp wrote: > > Are you sure the TI host and your host isn't neglecting to drop endpoint > > resources when the Reset Device command is handled? > > I double checked your test file

Re: [PATCH RFC] usb: dwc3: Set GCTL.PrtCapDir based on selected mode.

Hi Balbi, On Mon, Feb 25, 2013 at 1:47 PM, Felipe Balbi wrote: > Hi, > > On Tue, Feb 05, 2013 at 07:15:58PM +0530, Vivek Gautam wrote: >> Now that machines may select the mode of working of DWC3, >> we can set the Port capability direction based on selected mode. >> >> Signed-off-by: Vivek Gauta

RE: Not enough resource for old configuration after USB bus reset

> -Original Message- > From: Lan Tianyu [mailto:lantianyu1...@gmail.com] > Sent: Wednesday, February 20, 2013 4:14 PM > To: Soar Hung > Cc: Alan Stern; Sarah Sharp; linux-usb@vger.kernel.org > Subject: Re: Not enough resource for old configuration after > USB bus reset > > 2013/2/19 Soa

Re: [PATCH RFC] usb: dwc3: Set GCTL.PrtCapDir based on selected mode.

Hi, On Tue, Feb 05, 2013 at 07:15:58PM +0530, Vivek Gautam wrote: > Now that machines may select the mode of working of DWC3, > we can set the Port capability direction based on selected mode. > > Signed-off-by: Vivek Gautam > --- > drivers/usb/dwc3/core.c | 11 --- > 1 files changed,

[PATCH 1/2] usb: gadget: pxa27x_udc: drop ARCH_PXA dependency

This driver can compile in any arch quite easily by just removing a few headers and dropping cpu_is_* check from module_init. Signed-off-by: Felipe Balbi --- drivers/usb/gadget/Kconfig | 1 - drivers/usb/gadget/pxa27x_udc.c | 11 ++- 2 files changed, 2 insertions(+), 10 deletions(-

[PATCH 2/2] usb: gadget: pxa27x_udc: switch over to module_platform_driver

just removing some boilerplate code. Signed-off-by: Felipe Balbi --- drivers/usb/gadget/pxa27x_udc.c | 15 +++ 1 file changed, 3 insertions(+), 12 deletions(-) diff --git a/drivers/usb/gadget/pxa27x_udc.c b/drivers/usb/gadget/pxa27x_udc.c index 369e5a7..0661337 100644 --- a/drivers/

[PATCH 0/2] usb: gadget: pxa27x_udc: drop ARCH dependency

This one was easy enough to do, but there are still quite a few left. $ git grep -e "depends on ARCH" drivers/usb/gadget/Kconfig drivers/usb/gadget/Kconfig: depends on ARCH_AT91 drivers/usb/gadget/Kconfig: depends on ARCH_LPC32XX drivers/usb/gadget/Kconfig: depends on ARCH_OMAP1 driver