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

[Felipe Balbi]

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
drivers/usb/gadget/Kconfig: depends on ARCH_MXC
drivers/usb/gadget/Kconfig: depends on ARCH_S3C24XX
drivers/usb/gadget/Kconfig: depends on ARCH_S3C24XX

include the original UDC for the OMAP1 SoC. I wonder if anyone
still cares about that...

Anyway, I don't have the HW so these two patches have been
build-tested only. Please make sure to Test as this will go
in v3.10 if I don't hear any complaints.

cheers

Felipe Balbi (2):
  usb: gadget: pxa27x_udc: drop ARCH_PXA dependency
  usb: gadget: pxa27x_udc: switch over to module_platform_driver

 drivers/usb/gadget/Kconfig  |  1 -
 drivers/usb/gadget/pxa27x_udc.c | 26 +-
 2 files changed, 5 insertions(+), 22 deletions(-)

-- 
1.8.1.rc1.5.g7e0651a

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

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

[Felipe Balbi]

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

diff --git a/drivers/usb/gadget/Kconfig b/drivers/usb/gadget/Kconfig
index 14625fd..9044fe5 100644
--- a/drivers/usb/gadget/Kconfig
+++ b/drivers/usb/gadget/Kconfig
@@ -258,7 +258,6 @@ config USB_RENESAS_USBHS_UDC
 
 config USB_PXA27X
tristate "PXA 27x"
-   depends on ARCH_PXA && (PXA27x || PXA3xx)
select USB_OTG_UTILS
help
   Intel's PXA 27x series XScale ARM v5TE processors include
diff --git a/drivers/usb/gadget/pxa27x_udc.c b/drivers/usb/gadget/pxa27x_udc.c
index 8f39db2..369e5a7 100644
--- a/drivers/usb/gadget/pxa27x_udc.c
+++ b/drivers/usb/gadget/pxa27x_udc.c
@@ -24,14 +24,12 @@
 #include 
 #include 
 #include 
-
-#include 
-#include 
+#include 
+#include 
 
 #include 
 #include 
 #include 
-#include 
 
 #include "pxa27x_udc.h"
 
@@ -2664,15 +2662,10 @@ static struct platform_driver udc_driver = {
 
 static int __init udc_init(void)
 {
-   if (!cpu_is_pxa27x() && !cpu_is_pxa3xx())
-   return -ENODEV;
-
-   printk(KERN_INFO "%s: version %s\n", driver_name, DRIVER_VERSION);
return platform_driver_probe(&udc_driver, pxa_udc_probe);
 }
 module_init(udc_init);
 
-
 static void __exit udc_exit(void)
 {
platform_driver_unregister(&udc_driver);
-- 
1.8.1.rc1.5.g7e0651a

--
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: gadget: pxa27x_udc: switch over to module_platform_driver

[Felipe Balbi]

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/usb/gadget/pxa27x_udc.c
+++ b/drivers/usb/gadget/pxa27x_udc.c
@@ -2440,7 +2440,7 @@ static struct pxa_udc memory = {
  * Perform basic init : allocates udc clock, creates sysfs files, requests
  * irq.
  */
-static int __init pxa_udc_probe(struct platform_device *pdev)
+static int pxa_udc_probe(struct platform_device *pdev)
 {
struct resource *regs;
struct pxa_udc *udc = &memory;
@@ -2652,6 +2652,7 @@ static struct platform_driver udc_driver = {
.name   = "pxa27x-udc",
.owner  = THIS_MODULE,
},
+   .probe  = pxa_udc_probe,
.remove = __exit_p(pxa_udc_remove),
.shutdown   = pxa_udc_shutdown,
 #ifdef CONFIG_PM
@@ -2660,17 +2661,7 @@ static struct platform_driver udc_driver = {
 #endif
 };
 
-static int __init udc_init(void)
-{
-   return platform_driver_probe(&udc_driver, pxa_udc_probe);
-}
-module_init(udc_init);
-
-static void __exit udc_exit(void)
-{
-   platform_driver_unregister(&udc_driver);
-}
-module_exit(udc_exit);
+module_platform_driver(udc_driver);
 
 MODULE_DESCRIPTION(DRIVER_DESC);
 MODULE_AUTHOR("Robert Jarzmik");
-- 
1.8.1.rc1.5.g7e0651a

--
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 RFC] usb: dwc3: Set GCTL.PrtCapDir based on selected mode.

[Felipe Balbi]

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, 8 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c
> index 177f4c6..f4c47f7 100644
> --- a/drivers/usb/dwc3/core.c
> +++ b/drivers/usb/dwc3/core.c
> @@ -479,7 +479,6 @@ static int dwc3_probe(struct platform_device *pdev)
>  
>   switch (mode) {
>   case DWC3_MODE_DEVICE:
> - dwc3_set_mode(dwc, DWC3_GCTL_PRTCAP_DEVICE);
>   ret = dwc3_gadget_init(dwc);
>   if (ret) {
>   dev_err(dev, "failed to initialize gadget\n");
> @@ -487,7 +486,6 @@ static int dwc3_probe(struct platform_device *pdev)
>   }
>   break;
>   case DWC3_MODE_HOST:
> - dwc3_set_mode(dwc, DWC3_GCTL_PRTCAP_HOST);
>   ret = dwc3_host_init(dwc);
>   if (ret) {
>   dev_err(dev, "failed to initialize host\n");
> @@ -495,7 +493,6 @@ static int dwc3_probe(struct platform_device *pdev)
>   }
>   break;
>   case DWC3_MODE_DRD:
> - dwc3_set_mode(dwc, DWC3_GCTL_PRTCAP_OTG);
>   ret = dwc3_host_init(dwc);
>   if (ret) {
>   dev_err(dev, "failed to initialize host\n");
> @@ -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);
> +#elif IS_ENABLED(CONFIG_USB_DWC3_GADGET)
> + dwc3_set_mode(dwc, DWC3_GCTL_PRTCAP_DEVICE);
> +#else
> + dwc3_set_mode(dwc, DWC3_GCTL_PRTCAP_OTG);
> +#endif

you can actually use:

if (IS_ENABLED(CONFIG_USB_DWC3_HOST))
dwc3_set_mode(dwc...
else if (IS_ENABLED( ...
...
else
...

instead of pre-processor conditionals. In fact, I have recently written
a patch converting #if IS_ENABLED() to if (IS_ENABLED()) but I haven't
posted yet:

commit 42dbbbc272bc941ec2b0cac51342609e61e13a01
Author: Felipe Balbi 
Date:   Fri Feb 22 16:24:49 2013 +0200

usb: dwc3: debugfs: improve debugfs file creation

when commit 388e5c5 (usb: dwc3: remove dwc3
dependency on host AND gadget.) changed the
way debugfs files are created, it failed to
note that 'mode' is necessary in Dual Role
mode only while 'testmode' and 'link_state'
are valid in Dual Role and Peripheral-only
builds. Fix this while also converting pre-
processor conditional to C conditionals.

Signed-off-by: Felipe Balbi 

diff --git a/drivers/usb/dwc3/debugfs.c b/drivers/usb/dwc3/debugfs.c
index a1bac9a..8b23d045 100644
--- a/drivers/usb/dwc3/debugfs.c
+++ b/drivers/usb/dwc3/debugfs.c
@@ -667,28 +667,31 @@ int dwc3_debugfs_init(struct dwc3 *dwc)
goto err1;
}
 
-#if IS_ENABLED(CONFIG_USB_DWC3_GADGET)
-   file = debugfs_create_file("mode", S_IRUGO | S_IWUSR, root,
-   dwc, &dwc3_mode_fops);
-   if (!file) {
-   ret = -ENOMEM;
-   goto err1;
+   if (IS_ENABLED(CONFIG_USB_DWC3_DUAL_ROLE)) {
+   file = debugfs_create_file("mode", S_IRUGO | S_IWUSR, root,
+   dwc, &dwc3_mode_fops);
+   if (!file) {
+   ret = -ENOMEM;
+   goto err1;
+   }
}
 
-   file = debugfs_create_file("testmode", S_IRUGO | S_IWUSR, root,
-   dwc, &dwc3_testmode_fops);
-   if (!file) {
-   ret = -ENOMEM;
-   goto err1;
-   }
-
-   file = debugfs_create_file("link_state", S_IRUGO | S_IWUSR, root,
-   dwc, &dwc3_link_state_fops);
-   if (!file) {
-   ret = -ENOMEM;
-   goto err1;
+   if (IS_ENABLED(CONFIG_USB_DWC3_DUAL_ROLE) ||
+   IS_ENABLED(CONFIG_USB_DWC3_GADGET)) {
+   file = debugfs_create_file("testmode", S_IRUGO | S_IWUSR, root,
+   dwc, &dwc3_testmode_fops);
+   if (!file) {
+   ret = -ENOMEM;
+   goto err1;
+   }
+
+   file = debugfs_create_file("link_state", S_IRUGO | S_IWUSR, 
root,
+   dwc, &dwc3_link_state_fops);
+   if (!file) {
+   ret = -ENOMEM;
+   goto err1;
+   }
}
-#endif
 
return 0;
 

-- 
balbi


signature.asc
Description: Digital signature

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

[Soar Hung]

> -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 Soar Hung :
> > Hi all,
> >
> > I checkout the usb-next branch (on 2/18) and following the 
> https://wiki.ubuntu.com/KernelTeam/GitKernelBuild to build the kernel.
> >
> > After reboot, the new kernel version is Linux dev 
> 3.8.0-rc5-usbnext #1 SMP Mon Feb 18 18:04:02 CST 2013 i686 
> i686 i386 GNU/Linux.
> >
> > 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.

What information do we want from these two debug config?

We currently know that the issue is fail at the configure endpoint command 
after bus reset.

The failing reason is the reset operation make the endpoint state disabled, and 
HCD still try to drop the disabled endpoint.

This cause the host can not manage its resouce correctly. As a result, the last 
configure command fail with not enough bandwidth.

Soar--
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 RFC] usb: dwc3: Set GCTL.PrtCapDir based on selected mode.

[Vivek Gautam]

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 Gautam 
>> ---
>>  drivers/usb/dwc3/core.c |   11 ---
>>  1 files changed, 8 insertions(+), 3 deletions(-)
>>
>> diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c
>> index 177f4c6..f4c47f7 100644
>> --- a/drivers/usb/dwc3/core.c
>> +++ b/drivers/usb/dwc3/core.c
>> @@ -479,7 +479,6 @@ static int dwc3_probe(struct platform_device *pdev)
>>
>>   switch (mode) {
>>   case DWC3_MODE_DEVICE:
>> - dwc3_set_mode(dwc, DWC3_GCTL_PRTCAP_DEVICE);
>>   ret = dwc3_gadget_init(dwc);
>>   if (ret) {
>>   dev_err(dev, "failed to initialize gadget\n");
>> @@ -487,7 +486,6 @@ static int dwc3_probe(struct platform_device *pdev)
>>   }
>>   break;
>>   case DWC3_MODE_HOST:
>> - dwc3_set_mode(dwc, DWC3_GCTL_PRTCAP_HOST);
>>   ret = dwc3_host_init(dwc);
>>   if (ret) {
>>   dev_err(dev, "failed to initialize host\n");
>> @@ -495,7 +493,6 @@ static int dwc3_probe(struct platform_device *pdev)
>>   }
>>   break;
>>   case DWC3_MODE_DRD:
>> - dwc3_set_mode(dwc, DWC3_GCTL_PRTCAP_OTG);
>>   ret = dwc3_host_init(dwc);
>>   if (ret) {
>>   dev_err(dev, "failed to initialize host\n");
>> @@ -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);
>> +#elif IS_ENABLED(CONFIG_USB_DWC3_GADGET)
>> + dwc3_set_mode(dwc, DWC3_GCTL_PRTCAP_DEVICE);
>> +#else
>> + dwc3_set_mode(dwc, DWC3_GCTL_PRTCAP_OTG);
>> +#endif
>
> you can actually use:
>
> if (IS_ENABLED(CONFIG_USB_DWC3_HOST))
> dwc3_set_mode(dwc...
> else if (IS_ENABLED( ...
> ...
> else
> ...
>

I am actually hoping to change this to something like below (after
of course changing the preprocessor conditionals) :

commit 9a62ed948dcb6ac5d78aff41f5355c0a5ea86475
Author: Vivek Gautam 
Date:   Thu Jan 24 11:58:05 2013 +0530

usb: dwc3: Set GCTL.PrtCapDir based on selected mode.

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 

diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c
index 79f335f..9444fbe 100644
--- a/drivers/usb/dwc3/core.c
+++ b/drivers/usb/dwc3/core.c
@@ -478,7 +478,13 @@ static int dwc3_probe(struct platform_device *pdev)
goto err1;
}

-   mode = DWC3_MODE(dwc->hwparams.hwparams0);
+#if IS_ENABLED(CONFIG_USB_DWC3_HOST)
+   mode = DWC3_MODE_HOST;
+#elif IS_ENABLED(CONFIG_USB_DWC3_GADGET)
+   mode = DWC3_MODE_DEVICE;
+#else
+   mode = DWC3_MODE_DRD;
+#endif

switch (mode) {
case DWC3_MODE_DEVICE:


Since the mode is now software dependent, we can skip
initializing gadget/host in case of Host-only/Gadget-only modes respectively.
Can't guess how much this is valid though :-(

> instead of pre-processor conditionals. In fact, I have recently written
> a patch converting #if IS_ENABLED() to if (IS_ENABLED()) but I haven't
> posted yet:
>

Right, very valid change. Missed this in earlier change :-(

> commit 42dbbbc272bc941ec2b0cac51342609e61e13a01
> Author: Felipe Balbi 
> Date:   Fri Feb 22 16:24:49 2013 +0200
>
> usb: dwc3: debugfs: improve debugfs file creation
>
> when commit 388e5c5 (usb: dwc3: remove dwc3
> dependency on host AND gadget.) changed the
> way debugfs files are created, it failed to
> note that 'mode' is necessary in Dual Role
> mode only while 'testmode' and 'link_state'
> are valid in Dual Role and Peripheral-only
> builds. Fix this while also converting pre-
> processor conditional to C conditionals.
>
> Signed-off-by: Felipe Balbi 
>
> diff --git a/drivers/usb/dwc3/debugfs.c b/drivers/usb/dwc3/debugfs.c
> index a1bac9a..8b23d045 100644
> --- a/drivers/usb/dwc3/debugfs.c
> +++ b/drivers/usb/dwc3/debugfs.c
> @@ -667,28 +667,31 @@ int dwc3_debugfs_init(struct dwc3 *dwc)
> goto err1;
> }
>
> -#if IS_ENABLED(CONFIG_USB_DWC3_GADGET)
> -   file = debugfs_create_file("mode", S_IRUGO | S_IWUSR, root,
> -   dwc, &dwc3_mode_fops);
> -   if (!file) {
> -   ret = -ENOMEM;
> -   goto err1;
> +   if (IS_ENABLED(CONFIG_USB_DWC3_DUAL_ROLE)) {
> +   file = debugfs_create_file("mode", S_IRUGO | S_IWUSR, root,
> +   dwc, &dwc3_mode_fops);
> +   if (!file) {
> +   ret = -ENOMEM;
> +  

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

[Felipe Balbi]

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 on the latest Intel xHCI host, and it's
> up to over 4,000 successful resets of a USB mouse with a periodic IN
> endpoint.
> 
> I tried it with a USB ethernet dongle, but after about a hundred resets,
> the device returned different device descriptors.  The USB core treated
> it as a new device and assigned it a different address, which caused the
> script to fail since the /dev/bus/usb files went away.  Was there a
> different device you would like me to test with?
> 
> Basically, I think this is a host-specific bug.  We can certainly work
> around it in the xHCI driver with a quirk for all hosts that have this
> resource tracking problem.  We would issue a Configure Endpoint command
> to drop all endpoints before the Reset Device command.  However, I would
> really suggest you fix your host controller.
> 
> 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
> planning on having the mainline kernel support your host controller.

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.

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, since
TI's TUSB7340 is built with a USB3 Certified IP.

cheers

-- 
balbi


signature.asc
Description: Digital signature

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

[Felipe Balbi]

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);
> >> +#elif IS_ENABLED(CONFIG_USB_DWC3_GADGET)
> >> + dwc3_set_mode(dwc, DWC3_GCTL_PRTCAP_DEVICE);
> >> +#else
> >> + dwc3_set_mode(dwc, DWC3_GCTL_PRTCAP_OTG);
> >> +#endif
> >
> > you can actually use:
> >
> > if (IS_ENABLED(CONFIG_USB_DWC3_HOST))
> > dwc3_set_mode(dwc...
> > else if (IS_ENABLED( ...
> > ...
> > else
> > ...
> >
> 
> I am actually hoping to change this to something like below (after
> of course changing the preprocessor conditionals) :
> 
> commit 9a62ed948dcb6ac5d78aff41f5355c0a5ea86475
> Author: Vivek Gautam 
> Date:   Thu Jan 24 11:58:05 2013 +0530
> 
> usb: dwc3: Set GCTL.PrtCapDir based on selected mode.
> 
> 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 
> 
> diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c
> index 79f335f..9444fbe 100644
> --- a/drivers/usb/dwc3/core.c
> +++ b/drivers/usb/dwc3/core.c
> @@ -478,7 +478,13 @@ static int dwc3_probe(struct platform_device *pdev)
> goto err1;
> }
> 
> -   mode = DWC3_MODE(dwc->hwparams.hwparams0);
> +#if IS_ENABLED(CONFIG_USB_DWC3_HOST)
> +   mode = DWC3_MODE_HOST;
> +#elif IS_ENABLED(CONFIG_USB_DWC3_GADGET)
> +   mode = DWC3_MODE_DEVICE;
> +#else
> +   mode = DWC3_MODE_DRD;

looks alright.

-- 
balbi


signature.asc
Description: Digital signature

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

[Vivek Gautam]

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)
>> >> + dwc3_set_mode(dwc, DWC3_GCTL_PRTCAP_HOST);
>> >> +#elif IS_ENABLED(CONFIG_USB_DWC3_GADGET)
>> >> + dwc3_set_mode(dwc, DWC3_GCTL_PRTCAP_DEVICE);
>> >> +#else
>> >> + dwc3_set_mode(dwc, DWC3_GCTL_PRTCAP_OTG);
>> >> +#endif
>> >
>> > you can actually use:
>> >
>> > if (IS_ENABLED(CONFIG_USB_DWC3_HOST))
>> > dwc3_set_mode(dwc...
>> > else if (IS_ENABLED( ...
>> > ...
>> > else
>> > ...
>> >
>>
>> I am actually hoping to change this to something like below (after
>> of course changing the preprocessor conditionals) :
>>
>> commit 9a62ed948dcb6ac5d78aff41f5355c0a5ea86475
>> Author: Vivek Gautam 
>> Date:   Thu Jan 24 11:58:05 2013 +0530
>>
>> usb: dwc3: Set GCTL.PrtCapDir based on selected mode.
>>
>> 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 
>>
>> diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c
>> index 79f335f..9444fbe 100644
>> --- a/drivers/usb/dwc3/core.c
>> +++ b/drivers/usb/dwc3/core.c
>> @@ -478,7 +478,13 @@ static int dwc3_probe(struct platform_device *pdev)
>> goto err1;
>> }
>>
>> -   mode = DWC3_MODE(dwc->hwparams.hwparams0);
>> +#if IS_ENABLED(CONFIG_USB_DWC3_HOST)
>> +   mode = DWC3_MODE_HOST;
>> +#elif IS_ENABLED(CONFIG_USB_DWC3_GADGET)
>> +   mode = DWC3_MODE_DEVICE;
>> +#else
>> +   mode = DWC3_MODE_DRD;
>
> looks alright.
>
Fine then, i'll post this.


-- 
Thanks & Regards
Vivek
--
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: Not enough resource for old configuration after USB bus reset

[Soar Hung]

 
> 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_device, hcd issue a reset command.
The reset device command make the endpoint state disabled without releaseing 
the bandwidth.

After reset is done, the HCD try to reconfigure the device to previous active 
config by usb_hcd_alloc_bandwidth. 
The HCD does such thing by modifying drop and add flag in input context, 
and issue configure endpoint command to comoplete the operation.

When executing drop_endpoint, the endpoint is already in the disabled state.
This behavior is correct according to the spec. And the HC will not evaluate 
drop flag of disable endpoint,too.
As a result, the HC can not drop the endpoint to release the bandwidth.

Then add_endpoint to enable these endpoints. 
After all drop add flag are set, HCD sends a configure endpoint command to 
complete the change.

Before the priodic bandiwdth is used up, the configure endpoint command can 
success.
However, after reset several times, the configure endpoint command fail with 
command status "not enough bandwidth".
And the HC can not correctly configure any more periodic device.

> 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, since TI's TUSB7340 is built with a USB3 
> Certified IP.
> 

We have try two devices, both are USB-IF certified, on this host and they fail 
with same scenario.
And these two devices can successfully reset several times on some other host.--
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: Not enough resource for old configuration after USB bus reset

[Felipe Balbi]

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 and try to make it more clear.
>
> When calling usb_reset_and_verify_device, hcd issue a reset command.
> The reset device command make the endpoint state disabled without
> releaseing the bandwidth.
>
> After reset is done, the HCD try to reconfigure the device to previous
> active config by usb_hcd_alloc_bandwidth.
> The HCD does such thing by modifying drop and add flag in input
> context, and issue configure endpoint command to comoplete the
> operation.
> 
> When executing drop_endpoint, the endpoint is already in the disabled
> state.
> This behavior is correct according to the spec. And the HC will not
> evaluate drop flag of disable endpoint,too.

fair enough.

> As a result, the HC can not drop the endpoint to release the
> bandwidth.

But if the endpoint is already dropped, why hasn't bandwidth allocation
being released too ? Sarah ?

> 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 configure endpoint
> command can success.
> However, after reset several times, the configure endpoint command
> fail with command status "not enough bandwidth".
> And the HC can not correctly configure any more periodic device.

this does sound like a known errata. Unfortunately there's no suggested
for it. Just to make sure this is really the case, can you, somehow,
make sure that no transfers are ever scheduled to any of the periodic
endpoints and see if that "solves" the issue.

If it turns own that this helps, then we're talking about a known
errata. It will just take some time to figure out how to work around it
provided there are no suggested workarounds on the errata description.

I'll try to reproduce it here with a mouse (I happen to have a TUSB7340
too in my PC), if it fails the same way, I'll have a simple way to try,
but meanwhile please check that preventing transfers from being
scheduled to any periodic EP makes your test work.

> > 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, since TI's TUSB7340 is built with a USB3
> > Certified IP.
> > 
> 
> We have try two devices, both are USB-IF certified, on this host and
> they fail with same scenario.
> And these two devices can successfully reset several times on some
> other host.

that's alright, I'm just wondering how come this wasn't caught during
certification... perhaps certification lab didn't use a device with
periodic endpoints to run the test.

cheers

-- 
balbi


signature.asc
Description: Digital signature

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

[Soar Hung]

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 copy the previous content and try to make it more clear.
>> 
>> When calling usb_reset_and_verify_device, hcd issue a reset command.
>> The reset device command make the endpoint state disabled without
>> releaseing the bandwidth. 
>> 
>> After reset is done, the HCD try to reconfigure the device to
>> previous active config by usb_hcd_alloc_bandwidth.
>> The HCD does such thing by modifying drop and add flag in input
>> context, and issue configure endpoint command to comoplete the
>> operation. 
>> 
>> When executing drop_endpoint, the endpoint is already in the
>> disabled state. This behavior is correct according to the spec. And
>> the HC will not evaluate drop flag of disable endpoint,too.
> 
> fair enough.
> 
>> As a result, the HC can not drop the endpoint to release the
>> bandwidth.
> 
> But if the endpoint is already dropped, why hasn't bandwidth
> allocation being released too ? Sarah ?
> 

HCD fill the drop/add flag of input context, and issue configure command to 
tell HC evaluate the flag.
The realease is done when HC evaluate drop flag.
But HCD and HC will not do drop operation since it is disabled.

>> 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 configure endpoint
>> command can success. However, after reset several times, the
>> configure endpoint command fail with command status "not enough
>> bandwidth". 
>> And the HC can not correctly configure any more periodic device.
> 
> this does sound like a known errata. Unfortunately there's no
> suggested for it. Just to make sure this is really the case,
> can you, somehow, make sure that no transfers are ever
> scheduled to any of the periodic endpoints and see if that "solves"
> the issue. 
> 

We found this issue on our embedded system.
The driver is wrote with no periodic transfer.
So it might not solve the issue.
Thanks for the suggesstion.

> If it turns own that this helps, then we're talking about a
> known errata. It will just take some time to figure out how
> to work around it provided there are no suggested workarounds on the
> errata description. 
> 
> I'll try to reproduce it here with a mouse (I happen to have
> a TUSB7340 too in my PC), if it fails the same way, I'll have
> a simple way to try, but meanwhile please check that
> preventing transfers from being scheduled to any periodic EP makes
> your test work. 
> 

I have do some trick on my embedded system HCD source.
Make it always not set the periodic endpoint add flag (because we don't use it 
on the embedded system),
And this provide us a work-around solution temporarily.
But I know this is not correct method, I just want to bypass it.

>>> 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,
>>> since TI's TUSB7340 is built with a USB3 Certified IP.
>>> 
>> 
>> We have try two devices, both are USB-IF certified, on this host and
>> they fail with same scenario. And these two devices can successfully
>> reset several times on some other host.
> 
> that's alright, I'm just wondering how come this wasn't
> caught during certification... perhaps certification lab
> didn't use a device with periodic endpoints to run the test.
> 
> cheers



Best regards,
Soar
--
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: Not enough resource for old configuration after USB bus reset

[Felipe Balbi]

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 configure endpoint
> >> command can success. However, after reset several times, the
> >> configure endpoint command fail with command status "not enough
> >> bandwidth". 
> >> And the HC can not correctly configure any more periodic device.
> > 
> > this does sound like a known errata. Unfortunately there's no
> > suggested for it. Just to make sure this is really the case,
> > can you, somehow, make sure that no transfers are ever
> > scheduled to any of the periodic endpoints and see if that "solves"
> > the issue. 
> > 
> 
> We found this issue on our embedded system.
> The driver is wrote with no periodic transfer.
> So it might not solve the issue.

fair enough, I'll continue to try out on my end too.

cheers

-- 
balbi


signature.asc
Description: Digital signature

Re: Unable to reinsert the am35x MUSB module

[Igor Grinberg]

-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).
>>> Recently we faced with the following issue: am35x MUSB module fails
>>> when trying to reinsert it.
>>> It fails with the message "musb-hdrc.0: failed to claim resource 1",
>>> see the console clip below:
>>>
>>> root@cm-debian:~# modprobe am35x
>>> musb-hdrc: version 6.0, ?dma?, otg (peripheral+host)
>>> 
6Waiting for PHY clock good...
>>> musb-hdrc: ConfigData=0x1e (UTMI-8, dyn FIFOs, HB-ISO Rx, HB-ISO Tx,
>>> SoftConn)
>>> musb-hdrc: MHDRC RTL version 1.900
>>> musb-hdrc: setup fifo_mode 4
>>> musb-hdrc: 28/31 max ep, 16384/16384 memory
>>> root@cm-debian:~#
>>> root@cm-debian:~#
>>> root@cm-debian:~#
>>> root@cm-debian:~#
>>> root@cm-debian:~#
>>> root@cm-debian:~# modprobe -r am35x
>>> udc musb-hdrc.0: releasing 'musb-hdrc.0'
>>> root@cm-debian:~#
>>> root@cm-debian:~#
>>> root@cm-debian:~#
>>> root@cm-debian:~#
>>> root@cm-debian:~#
>>> root@cm-debian:~# modprobe am35x
>>> musb-hdrc: version 6.0, ?dma?, otg (peripheral+host)
>>> musb-hdrc.0: failed to claim resource 1
>>> musb-am35x musb-am35x: failed to register musb device
>>> musb-am35x: probe of musb-am35x failed with error -16
>>> root@cm-debian:~#
>>>
>>> The issue still exists even in the resent kernel v3.7.0-rc7.
>>> While searching for the resolution I found the similar issue with the
>>> davinci MUSB module:
>>>
>>> http://comments.gmane.org/gmane.linux.davinci/23781
>>>
>>> It was found almost a year ago. Does anybody know how it can be
>>> properly resolved?
> 
>> Can you try to figure which resource is getting a conflict ?
> 
> Yep:
> 
> # modprobe am35x
> musb-hdrc: version 6.0, ?dma?, otg (peripheral+host)
> >>>  ALLOCATED RESOURCES = 2
> RESOURCE #0 of TYPE = 1024 NAME = mc
> RESOURCE #1 of TYPE = 512 NAME = musb-am35x
> musb-hdrc: failed to claim resource 1
> musb-am35x musb-am35x: failed to register musb device
> musb-am35x: probe of musb-am35x failed with error -16

Any news on this?


- -- 
Regards,
Igor.
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.17 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBAgAGBQJRK1jSAAoJEBDE8YO64Efau10P/iax/r2P/kSPccKJisbl4iUa
M/i3qP03vVzrFK9K4gYGLX0NKPm5jORBnYhT9IOlJwqrzJJCtkmm707I16T4uLCx
77An7Q7ekyj1IzX+w1BmH29IDI1xJ9tLoIQZskIAtATxp1RHtesCNYPerKa9HF/y
bp7naEUQnDAN/SHFSD/n2BGvtwfCvXPJxXtDeahk3K0CRHQ4zRB/fwuMeizZa58z
hTImEvdD2RLRsgtojXTn82sOFfhoVqnSBRAc10P4+OK8GYnXn/XbTuuGAOangA2W
yfKDZBA039OqvFUGpe2vP/rDq/YScT/vXFTPKL1heggS+7jFsPl8zpuENIOc70P7
39NILFUmOgfPIyVkdoOEtxpg1Gv9qSy12L2VZQ7uiQi40zs+khPpTt1uH63URXKO
qu4esReFghAGIswpBb5364xkEpA6pRR2/3N1r+FqTO8caa8cHd8qYC2bhEJ+cVis
MoXApLcu5OHNKTVd6SuDP3Ern0vtyF+KwRH0G2lqjRadrdiUaY52xrjpxF5cLbqM
JdoMbnOgI4LUpvlJxx3RhZSg9M8w1ce1ita8pLve1lTMIh5cpU0xgn/yKftpAdnB
iRnHKMo4XGb7F9n/DgJ9PYIs3f8HassSnHLUnywKow7YJJBoD6o0VQ6kydwo3kCX
/q05I0Be1M1pwy0qi6Kx
=vE6I
-END PGP SIGNATURE-
--
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: Not enough resource for old configuration after USB bus reset

[Felipe Balbi]

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.
> > > 
> > > right.
> > > 
> > >> Before the priodic bandiwdth is used up, the configure endpoint
> > >> command can success. However, after reset several times, the
> > >> configure endpoint command fail with command status "not enough
> > >> bandwidth". 
> > >> And the HC can not correctly configure any more periodic device.
> > > 
> > > this does sound like a known errata. Unfortunately there's no
> > > suggested for it. Just to make sure this is really the case,
> > > can you, somehow, make sure that no transfers are ever
> > > scheduled to any of the periodic endpoints and see if that "solves"
> > > the issue. 
> > > 
> > 
> > We found this issue on our embedded system.
> > The driver is wrote with no periodic transfer.
> > So it might not solve the issue.
> 
> fair enough, I'll continue to try out on my end too.

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.

cheers

-- 
balbi


signature.asc
Description: Digital signature

Re: carl9170 A-MPDU transmit problem

[Seth Forshee]

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 machines only have USB 3.0 ports, but I did manage to find an
Ivy Bridge machine with both. On that machine I get a stable connection
on the USB 2.0 ports and a flaky connection on the USB 3.0 ports. I
didn't actually sniff the frames, but the behavior is consistent with
what I saw on the other machines.

Seth

--
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: carl9170 A-MPDU transmit problem

[Seth Forshee]

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 device, the
> > same firmware and the same kernel drivers in all tests, right)?
> 
> No, not really.  Unless one is using USB-2 and the other USB-3 -- the 
> device might have a bug in its USB-3 firmware.

This appears to be a high-speed device; at least, dmesg says "new
high-speed USB device ..." when I plug it in. So for the firmware isn't
it USB 2.0 even when plugged in a SuperSpeed port?

> What happens if xhci-hcd is unloaded before the test?

I'll test this, but I need to rebuild first. xhci-hcd is currently
built-in to my kenel.

Seth

--
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: carl9170 A-MPDU transmit problem

[Christian Lamparter]

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 myself wondering how the "88012fe19500"
> > urb-complete ninja'd right in between the 880146c8af00 xmit and
> > complete.
> > 
> > 88012fe19500 1519981417 S Bo:3:003:1 -115 126 = 7e00 190f0100 
> > 23232303 42b53600 82b11a00 01c02e00 6a00e846 c2ad3e00
> > ...
> > 880146c8af00 1522200650 S Bo:3:003:1 -115 62 = 3e00 01000500 
> > 0300    22000$
> > 88012fe19500 1522200720 C Bo:3:003:1 0 126 > 
> > 880146c8af00 1522200756 C Bo:3:003:1 0 62 >
> 
> 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 said: "It's strange that
after such a long silence the urb tx trigger at 1519981417 seemd to
unfreeze the pending urb. It's almost as if a urb completion event
was lost and the urb_complete just had to wait until another tx urb
on the same ep went by to free it.   
 
> > From the device side, taking the data shouldn't be a problem. The
> > rx is handled by hardware dma. The data from the host is put into
> > packages of 320 bytes (The carl9170 firmware has about 180 to 190
> > of these 320 byte packages reserved for this purpose. So at no 
> > point there should be any long delay because of lack of resources
> > or whatever). Also, it doesn't look the was any unusually high 
> > load on the link. And the hardware can handle sustained wifi traffic
> > up to 160mbit/s (udp peaks at about 180mbit/s) without choking.
> > 
> >  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 device, the
> > same firmware and the same kernel drivers in all tests, right)?
> 
> No, not really.  Unless one is using USB-2 and the other USB-3 -- the 
> device might have a bug in its USB-3 firmware.
Don't worry, the device was designed about 5 years ago. Hence, we don't
need to care about any USB 3.0 features.

> What happens if xhci-hcd is unloaded before the test?
Isn't xhci-hcd needed to drive the usb 3.0 ports? I know about the hub
concept with uhci/ohci and ehci, but I thought they did away with that.

Regards,
Chr
--
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: remove incorrect __exit markups

[Alan Stern]

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 disables sysfs bind/unbind
> attributes.
> 
> Signed-off-by: Dmitry Torokhov 

For the EHCI driver parts:

Acked-by: Alan Stern 

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

Re: carl9170 A-MPDU transmit problem

[Alan Stern]

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 said: "It's strange that
> after such a long silence the urb tx trigger at 1519981417 seemd to
> unfreeze the pending urb. It's almost as if a urb completion event
> was lost and the urb_complete just had to wait until another tx urb
> on the same ep went by to free it.   

That's quite possible.  The new URB may trigger something in the
xhci-hcd driver or in the xHCI hardware.  Sarah (CC'ed), the maintainer
for xhci-hcd, is the person who would know best.

> > > From the device side, taking the data shouldn't be a problem. The
> > > rx is handled by hardware dma. The data from the host is put into
> > > packages of 320 bytes (The carl9170 firmware has about 180 to 190
> > > of these 320 byte packages reserved for this purpose. So at no 
> > > point there should be any long delay because of lack of resources
> > > or whatever). Also, it doesn't look the was any unusually high 
> > > load on the link. And the hardware can handle sustained wifi traffic
> > > up to 160mbit/s (udp peaks at about 180mbit/s) without choking.
> > > 
> > >  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 device, the
> > > same firmware and the same kernel drivers in all tests, right)?
> > 
> > No, not really.  Unless one is using USB-2 and the other USB-3 -- the 
> > device might have a bug in its USB-3 firmware.
> Don't worry, the device was designed about 5 years ago. Hence, we don't
> need to care about any USB 3.0 features.

Since the device firmware is therefore unlikely to be the cause of the 
problem, it now seems a lot more likely that the problem is in the xHCI 
hardware or driver.

> > What happens if xhci-hcd is unloaded before the test?
> Isn't xhci-hcd needed to drive the usb 3.0 ports? I know about the hub
> concept with uhci/ohci and ehci, but I thought they did away with that.

Yes.  Without xhci-hcd, nothing will happen when a device is plugged
into a USB-3 port.  (Although on some systems, ports are wired up as
both USB-2 and USB-3, so when xhci-hcd isn't loaded the ports are
managed by ehci-hcd.)

Never mind; when I wrote the question it wasn't clear that the failures 
occurred only when the device was attached to a USB-3 port.

Alan Stern

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

Re: carl9170 A-MPDU transmit problem

[Christian Lamparter]

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 they were submitted.
> > Yes, I know that ;). I guess I should have said: "It's strange that
> > after such a long silence the urb tx trigger at 1519981417 seemd to
> > unfreeze the pending urb. It's almost as if a urb completion event
> > was lost and the urb_complete just had to wait until another tx urb
> > on the same ep went by to free it.   
> 
> That's quite possible.  The new URB may trigger something in the
> xhci-hcd driver or in the xHCI hardware.  Sarah (CC'ed), the maintainer
> for xhci-hcd, is the person who would know best.

Thanks (Hello Sarah).

One detail that might be important (to keep in mind):

Original report :
> On the air everything seems to go smoothly for a while, but 
> then the D-Link adapter stops transmitting *DATA* frames for a while. [...] 
> Eventually it sends the action frame with the *DELBA* request, but
> immediately before sending the action frame it sends a single *DATA*
> frame (1). This pattern repeats each time this happens.

Now if we take this and apply it to the usbmon recording in:


> Normally the time between submission and callback for a given urb
> is short. However, some are much longer, e.g.:
>
>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 1522200650 S Bo:3:003:1 -115 62 = 3e00 ... <-- DELBA
>88012fe19500 1522200720 C Bo:3:003:1 0 126 > <-- DATA urb completion
>880146c8af00 1522200756 C Bo:3:003:1 0 62 > <-- DELBA urb completion

It would mean that the (delayed) urb with the *DATA* frame urb was not
sent (?or received?) by the usb dongle until the *DELBA* came along (1)
and triggered the TX for both (in quick succession). So, I think we 
should be looking for lost/unhandled interrupts/events.

One more thing: So far this issue only occurs with:
00:14.0 USB controller [0c03]: Intel Corporation 7 Series/C210 Series Chipset 
Family USB xHCI Host Controller [8086:1e31] (rev 04) (prog-if 30 [XHCI])

However, it not all xhci-hcd are affected. I have not seen this with
the NEC Corporation uPD720200 I have in my sandy bridge laptop:
19:00.0 USB controller [0c03]: NEC Corporation uPD720200 USB 3.0 Host 
Controller [1033:0194] (rev 04)

Regards,
Chr
--
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: otg: use try_module_get in all usb_get_phy functions and add missing module_put

[Michael Grzeschik]

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() and usb_get_phy_dev().
Further the missing module_put() is added to usb_put_phy().

Reviewed-by: Kishon Vijay Abraham I 
Acked-by: Felipe Balbi 
Signed-off-by: Marc Kleine-Budde 
Signed-off-by: Michael Grzeschik 
---
Hello,

this patch got lost somehow, it applies to current linus/master (pre v3.9-rc1).
Please apply.

regards,
Marc & Michael

 drivers/usb/otg/otg.c |   10 +++---
 1 file changed, 7 insertions(+), 3 deletions(-)

diff --git a/drivers/usb/otg/otg.c b/drivers/usb/otg/otg.c
index e181439..2bd03d2 100644
--- a/drivers/usb/otg/otg.c
+++ b/drivers/usb/otg/otg.c
@@ -130,7 +130,7 @@ struct usb_phy *usb_get_phy(enum usb_phy_type type)
spin_lock_irqsave(&phy_lock, flags);
 
phy = __usb_find_phy(&phy_list, type);
-   if (IS_ERR(phy)) {
+   if (IS_ERR(phy) || !try_module_get(phy->dev->driver->owner)) {
pr_err("unable to find transceiver of type %s\n",
usb_phy_type_string(type));
goto err0;
@@ -228,7 +228,7 @@ struct usb_phy *usb_get_phy_dev(struct device *dev, u8 
index)
spin_lock_irqsave(&phy_lock, flags);
 
phy = __usb_find_phy_dev(dev, &phy_bind_list, index);
-   if (IS_ERR(phy)) {
+   if (IS_ERR(phy) || !try_module_get(phy->dev->driver->owner)) {
pr_err("unable to find transceiver\n");
goto err0;
}
@@ -301,8 +301,12 @@ EXPORT_SYMBOL(devm_usb_put_phy);
  */
 void usb_put_phy(struct usb_phy *x)
 {
-   if (x)
+   if (x) {
+   struct module *owner = x->dev->driver->owner;
+
put_device(x->dev);
+   module_put(owner);
+   }
 }
 EXPORT_SYMBOL(usb_put_phy);
 
-- 
1.7.10.4

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

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

[Felipe Balbi]

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() is missing in that patch.
> 
> This patch adds try_module_get() to usb_get_phy() and usb_get_phy_dev().
> Further the missing module_put() is added to usb_put_phy().
> 
> Reviewed-by: Kishon Vijay Abraham I 
> Acked-by: Felipe Balbi 
> Signed-off-by: Marc Kleine-Budde 
> Signed-off-by: Michael Grzeschik 
> ---
> 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

-- 
balbi


signature.asc
Description: Digital signature

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

[Marc Kleine-Budde]

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   |
Industrial Linux Solutions| Phone: +49-231-2826-924 |
Vertretung West/Dortmund  | Fax:   +49-5121-206917- |
Amtsgericht Hildesheim, HRA 2686  | http://www.pengutronix.de   |



signature.asc
Description: OpenPGP digital signature

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

[Sarah Sharp]

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 might already be workarounds available.
> >
> > I copy the previous content and try to make it more clear.
> >
> > When calling usb_reset_and_verify_device, hcd issue a reset command.
> > The reset device command make the endpoint state disabled without
> > releaseing the bandwidth.
> >
> > After reset is done, the HCD try to reconfigure the device to previous
> > active config by usb_hcd_alloc_bandwidth.
> > The HCD does such thing by modifying drop and add flag in input
> > context, and issue configure endpoint command to comoplete the
> > operation.
> > 
> > When executing drop_endpoint, the endpoint is already in the disabled
> > state.
> > This behavior is correct according to the spec. And the HC will not
> > evaluate drop flag of disable endpoint,too.
> 
> fair enough.
> 
> > As a result, the HC can not drop the endpoint to release the
> > bandwidth.
> 
> But if the endpoint is already dropped, why hasn't bandwidth allocation
> being released too ? Sarah ?

I think we're talking past each other. :)  Soar, what bandwidth
allocation resources are you talking about?  In the xHC hardware, or in
the xHCI driver?  I've been talking about resources in the hardware
only, but I want to confirm we're talking about the same thing.

As I understand it, the Reset Device command should drop all bandwidth
allocated within the xHC hardware.  Then we go back and re-add the
endpoints, setting only the add flag in the input context.  As Soar
mentioned, this is spec-compliant, but the host eventually gives an
out-of-bandwidth completion code for the Configure Endpoint command.

> > 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 configure endpoint
> > command can success.
> > However, after reset several times, the configure endpoint command
> > fail with command status "not enough bandwidth".
> > And the HC can not correctly configure any more periodic device.
> 
> this does sound like a known errata. Unfortunately there's no suggested
> for it. Just to make sure this is really the case, can you, somehow,
> make sure that no transfers are ever scheduled to any of the periodic
> endpoints and see if that "solves" the issue.
> 
> If it turns own that this helps, then we're talking about a known
> errata. It will just take some time to figure out how to work around it
> provided there are no suggested workarounds on the errata description.
> 
> I'll try to reproduce it here with a mouse (I happen to have a TUSB7340
> too in my PC), if it fails the same way, I'll have a simple way to try,
> but meanwhile please check that preventing transfers from being
> scheduled to any periodic EP makes your test work.
> 
> > > 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, since TI's TUSB7340 is built with a USB3
> > > Certified IP.
> > > 
> > 
> > We have try two devices, both are USB-IF certified, on this host and
> > they fail with same scenario.
> > And these two devices can successfully reset several times on some
> > other host.
> 
> that's alright, I'm just wondering how come this wasn't caught during
> certification... perhaps certification lab didn't use a device with
> periodic endpoints to run the test.

Or maybe they issue a Configure Endpoint command to drop all endpoints
before they issue the Reset Device command?  That was my proposed
work-around.

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

Re: linux-next and usb gadget composite BUG

[Robert Jarzmik]

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, I'm only looking for a fix :)
I just hope this change will still enable to change the gadget (ie. switch from
g_ether to g_zero by rmmoding/modprobing).

> The bug is that pxa27x_udc tries to register gadget->dev at udc_start()
> time and that's only called after gadget driver has already been bound
> to the controller. Since commit above converted pxa27x to
> udc_start()/udc_stop() calls, it exposed the issue.
>
> Anyway, this patch should fix it (I didn't even compile test it, since
> pxa27x still depends on its architecture, which needs to be fixed).

I suppose you made that patch against your own tree, not linux-next nor Linus's
tree.
But anyway, I took your changes into linux-next and it solves the problem.

So please take my :
Tested-by: Robert Jarzmik 

I think the same problem occurs on other drivers. Out of my head I see :
  - pxa25x_udc.c
  - s3c2410_udc.c
  - imx_udc_start.c

Cheers.

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

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

[Dmitry Torokhov]

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 1 so it was clearing itself even though we were
setting IMAN_IE instead of IMAN_IP), we should still correct the values.

Signed-off-by: Dmitry Torokhov 
---

 drivers/usb/host/xhci.h |4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/usb/host/xhci.h b/drivers/usb/host/xhci.h
index f791bd0..2c510e4 100644
--- a/drivers/usb/host/xhci.h
+++ b/drivers/usb/host/xhci.h
@@ -206,8 +206,8 @@ struct xhci_op_regs {
 /* bits 12:31 are reserved (and should be preserved on writes). */
 
 /* IMAN - Interrupt Management Register */
-#define IMAN_IP(1 << 1)
-#define IMAN_IE(1 << 0)
+#define IMAN_IE(1 << 1)
+#define IMAN_IP(1 << 0)
 
 /* USBSTS - USB status - status bitmasks */
 /* HC not running - set to 1 when run/stop bit is cleared. */
--
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: linux-next and usb gadget composite BUG

[Felipe Balbi]

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 the fact
> > is that what pxa27x is doing is pretty wrong.
> No need to argue, I'm only looking for a fix :)
> I just hope this change will still enable to change the gadget (ie. switch 
> from
> g_ether to g_zero by rmmoding/modprobing).
> 
> > The bug is that pxa27x_udc tries to register gadget->dev at udc_start()
> > time and that's only called after gadget driver has already been bound
> > to the controller. Since commit above converted pxa27x to
> > udc_start()/udc_stop() calls, it exposed the issue.
> >
> > Anyway, this patch should fix it (I didn't even compile test it, since
> > pxa27x still depends on its architecture, which needs to be fixed).
> 
> I suppose you made that patch against your own tree, not linux-next nor 
> Linus's
> tree.
> But anyway, I took your changes into linux-next and it solves the problem.
> 
> So please take my :
> Tested-by: Robert Jarzmik 

thanks, will add your tested-by for sure.

> I think the same problem occurs on other drivers. Out of my head I see :
>   - pxa25x_udc.c
>   - s3c2410_udc.c
>   - imx_udc_start.c

Thank you, I'll patch those too unless someone beats me to it ;-)

-- 
balbi


signature.asc
Description: Digital signature

Re: carl9170 A-MPDU transmit problem

[Sarah Sharp]

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 :
> > On the air everything seems to go smoothly for a while, but 
> > then the D-Link adapter stops transmitting *DATA* frames for a while. [...] 
> > Eventually it sends the action frame with the *DELBA* request, but
> > immediately before sending the action frame it sends a single *DATA*
> > frame (1). This pattern repeats each time this happens.
> 
> Now if we take this and apply it to the usbmon recording in:
> 
> 
> > Normally the time between submission and callback for a given urb
> > is short. However, some are much longer, e.g.:
> >
> >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 1522200650 S Bo:3:003:1 -115 62 = 3e00 ... <-- DELBA
> >88012fe19500 1522200720 C Bo:3:003:1 0 126 > <-- DATA urb completion
> >880146c8af00 1522200756 C Bo:3:003:1 0 62 > <-- DELBA urb completion
> 
> It would mean that the (delayed) urb with the *DATA* frame urb was not
> sent (?or received?) by the usb dongle until the *DELBA* came along (1)
> and triggered the TX for both (in quick succession). So, I think we 
> should be looking for lost/unhandled interrupts/events.
> 
> One more thing: So far this issue only occurs with:
> 00:14.0 USB controller [0c03]: Intel Corporation 7 Series/C210 Series Chipset 
> Family USB xHCI Host Controller [8086:1e31] (rev 04) (prog-if 30 [XHCI])

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 the xHCI rings if the data URB stalls for longer than say, a
minute.

As for lost interrupts, the only issue we had with that particular xHCI
host had to do with lost isochronous transfers.  We fixed that with a
quirk to avoid the BEI flag on that platform.  But your data is being
sent via a bulk endpoint, so we shouldn't have any issues there.

> However, it not all xhci-hcd are affected. I have not seen this with
> the NEC Corporation uPD720200 I have in my sandy bridge laptop:
> 19:00.0 USB controller [0c03]: NEC Corporation uPD720200 USB 3.0 Host 
> Controller [1033:0194] (rev 04)

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 a link so I can purchase the device and test it
with my analyzer?

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 1/4] usb: gadget: s3c2410: fix gadget->dev registration

[Felipe Balbi]

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 +++---
 1 file changed, 11 insertions(+), 15 deletions(-)

diff --git a/drivers/usb/gadget/s3c2410_udc.c b/drivers/usb/gadget/s3c2410_udc.c
index fc07b43..9404858 100644
--- a/drivers/usb/gadget/s3c2410_udc.c
+++ b/drivers/usb/gadget/s3c2410_udc.c
@@ -1669,7 +1669,6 @@ static int s3c2410_udc_start(struct usb_gadget *g,
struct usb_gadget_driver *driver)
 {
struct s3c2410_udc *udc = to_s3c2410(g)
-   int retval;
 
dprintk(DEBUG_NORMAL, "%s() '%s'\n", __func__, driver->driver.name);
 
@@ -1677,22 +1676,10 @@ static int s3c2410_udc_start(struct usb_gadget *g,
udc->driver = driver;
udc->gadget.dev.driver = &driver->driver;
 
-   /* Bind the driver */
-   retval = device_add(&udc->gadget.dev);
-   if (retval) {
-   dev_err(&udc->gadget.dev, "Error in device_add() : %d\n", 
retval);
-   goto register_error;
-   }
-
/* Enable udc */
s3c2410_udc_enable(udc);
 
return 0;
-
-register_error:
-   udc->driver = NULL;
-   udc->gadget.dev.driver = NULL;
-   return retval;
 }
 
 static int s3c2410_udc_stop(struct usb_gadget *g,
@@ -1700,7 +1687,6 @@ static int s3c2410_udc_stop(struct usb_gadget *g,
 {
struct s3c2410_udc *udc = to_s3c2410(g);
 
-   device_del(&udc->gadget.dev);
udc->driver = NULL;
 
/* Disable udc */
@@ -1842,6 +1828,13 @@ static int s3c2410_udc_probe(struct platform_device 
*pdev)
udc->gadget.dev.parent = &pdev->dev;
udc->gadget.dev.dma_mask = pdev->dev.dma_mask;
 
+   /* Bind the driver */
+   retval = device_add(&udc->gadget.dev);
+   if (retval) {
+   dev_err(&udc->gadget.dev, "Error in device_add() : %d\n", 
retval);
+   goto err_device_add;
+   }
+
the_controller = udc;
platform_set_drvdata(pdev, udc);
 
@@ -1930,6 +1923,8 @@ err_gpio_claim:
 err_int:
free_irq(IRQ_USBD, udc);
 err_map:
+   device_unregister(&udc->gadget.dev);
+err_device_add:
iounmap(base_addr);
 err_mem:
release_mem_region(rsrc_start, rsrc_len);
@@ -1947,10 +1942,11 @@ static int s3c2410_udc_remove(struct platform_device 
*pdev)
 
dev_dbg(&pdev->dev, "%s()\n", __func__);
 
-   usb_del_gadget_udc(&udc->gadget);
if (udc->driver)
return -EBUSY;
 
+   usb_del_gadget_udc(&udc->gadget);
+   device_unregister(&udc->gadget.dev);
debugfs_remove(udc->regs_info);
 
if (udc_info && !udc_info->udc_command &&
-- 
1.8.1.rc1.5.g7e0651a

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

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

[Felipe Balbi]

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 +++-
 1 file changed, 11 insertions(+), 9 deletions(-)

diff --git a/drivers/usb/gadget/pxa25x_udc.c b/drivers/usb/gadget/pxa25x_udc.c
index 2bbcdce..9aa9dd5 100644
--- a/drivers/usb/gadget/pxa25x_udc.c
+++ b/drivers/usb/gadget/pxa25x_udc.c
@@ -1266,13 +1266,6 @@ static int pxa25x_udc_start(struct usb_gadget *g,
dev->gadget.dev.driver = &driver->driver;
dev->pullup = 1;
 
-   retval = device_add (&dev->gadget.dev);
-   if (retval) {
-   dev->driver = NULL;
-   dev->gadget.dev.driver = NULL;
-   return retval;
-   }
-
/* ... then enable host detection and ep0; and we're ready
 * for set_configuration as well as eventual disconnect.
 */
@@ -1331,7 +1324,6 @@ static int pxa25x_udc_stop(struct usb_gadget*g,
dev->gadget.dev.driver = NULL;
dev->driver = NULL;
 
-   device_del (&dev->gadget.dev);
dump_state(dev);
 
return 0;
@@ -2146,6 +2138,13 @@ static int __init pxa25x_udc_probe(struct 
platform_device *pdev)
dev->gadget.dev.parent = &pdev->dev;
dev->gadget.dev.dma_mask = pdev->dev.dma_mask;
 
+   retval = device_add(&dev->gadget.dev);
+   if (retval) {
+   dev->driver = NULL;
+   dev->gadget.dev.driver = NULL;
+   goto err_device_add;
+   }
+
the_controller = dev;
platform_set_drvdata(pdev, dev);
 
@@ -2196,6 +2195,8 @@ lubbock_fail0:
free_irq(irq, dev);
 #endif
  err_irq1:
+   device_unregister(&dev->gadget.dev);
+ err_device_add:
if (gpio_is_valid(dev->mach->gpio_pullup))
gpio_free(dev->mach->gpio_pullup);
  err_gpio_pullup:
@@ -2217,10 +2218,11 @@ static int __exit pxa25x_udc_remove(struct 
platform_device *pdev)
 {
struct pxa25x_udc *dev = platform_get_drvdata(pdev);
 
-   usb_del_gadget_udc(&dev->gadget);
if (dev->driver)
return -EBUSY;
 
+   usb_del_gadget_udc(&dev->gadget);
+   device_unregister(&dev->gadget.dev);
dev->pullup = 0;
pullup(dev);
 
-- 
1.8.1.rc1.5.g7e0651a

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

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

[Felipe Balbi]

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/gadget/s3c2410_udc.c
+++ b/drivers/usb/gadget/s3c2410_udc.c
@@ -1668,7 +1668,7 @@ static void s3c2410_udc_enable(struct s3c2410_udc *dev)
 static int s3c2410_udc_start(struct usb_gadget *g,
struct usb_gadget_driver *driver)
 {
-   struct s3c2410_udc *udc = to_s3c2410(g)
+   struct s3c2410_udc *udc = to_s3c2410(g);
 
dprintk(DEBUG_NORMAL, "%s() '%s'\n", __func__, driver->driver.name);
 
-- 
1.8.1.rc1.5.g7e0651a

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

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

[Felipe Balbi]

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 
 1 file changed, 8 insertions(+), 12 deletions(-)

diff --git a/drivers/usb/gadget/imx_udc.c b/drivers/usb/gadget/imx_udc.c
index 8efd755..5bd930d 100644
--- a/drivers/usb/gadget/imx_udc.c
+++ b/drivers/usb/gadget/imx_udc.c
@@ -1334,27 +1334,18 @@ static int imx_udc_start(struct usb_gadget *gadget,
struct usb_gadget_driver *driver)
 {
struct imx_udc_struct *imx_usb;
-   int retval;
 
imx_usb = container_of(gadget, struct imx_udc_struct, gadget);
/* first hook up the driver ... */
imx_usb->driver = driver;
imx_usb->gadget.dev.driver = &driver->driver;
 
-   retval = device_add(&imx_usb->gadget.dev);
-   if (retval)
-   goto fail;
-
D_INI(imx_usb->dev, "<%s> registered gadget driver '%s'\n",
__func__, driver->driver.name);
 
imx_udc_enable(imx_usb);
 
return 0;
-fail:
-   imx_usb->driver = NULL;
-   imx_usb->gadget.dev.driver = NULL;
-   return retval;
 }
 
 static int imx_udc_stop(struct usb_gadget *gadget,
@@ -1370,8 +1361,6 @@ static int imx_udc_stop(struct usb_gadget *gadget,
imx_usb->gadget.dev.driver = NULL;
imx_usb->driver = NULL;
 
-   device_del(&imx_usb->gadget.dev);
-
D_INI(imx_usb->dev, "<%s> unregistered gadget driver '%s'\n",
__func__, driver->driver.name);
 
@@ -1477,6 +1466,10 @@ static int __init imx_udc_probe(struct platform_device 
*pdev)
imx_usb->gadget.dev.parent = &pdev->dev;
imx_usb->gadget.dev.dma_mask = pdev->dev.dma_mask;
 
+   ret = device_add(&imx_usb->gadget.dev);
+   if (retval)
+   goto fail4;
+
platform_set_drvdata(pdev, imx_usb);
 
usb_init_data(imx_usb);
@@ -1488,9 +1481,11 @@ static int __init imx_udc_probe(struct platform_device 
*pdev)
 
ret = usb_add_gadget_udc(&pdev->dev, &imx_usb->gadget);
if (ret)
-   goto fail4;
+   goto fail5;
 
return 0;
+fail5:
+   device_unregister(&imx_usb->gadget.dev);
 fail4:
for (i = 0; i < IMX_USB_NB_EP + 1; i++)
free_irq(imx_usb->usbd_int[i], imx_usb);
@@ -1514,6 +1509,7 @@ static int __exit imx_udc_remove(struct platform_device 
*pdev)
int i;
 
usb_del_gadget_udc(&imx_usb->gadget);
+   device_unregister(&imx_usb->gadget.dev);
imx_udc_disable(imx_usb);
del_timer(&imx_usb->timer);
 
-- 
1.8.1.rc1.5.g7e0651a

--
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: carl9170 A-MPDU transmit problem

[Seth Forshee]

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 mind):
> > 
> > Original report 
> > :
> > > On the air everything seems to go smoothly for a while, but 
> > > then the D-Link adapter stops transmitting *DATA* frames for a while. 
> > > [...] 
> > > Eventually it sends the action frame with the *DELBA* request, but
> > > immediately before sending the action frame it sends a single *DATA*
> > > frame (1). This pattern repeats each time this happens.
> > 
> > Now if we take this and apply it to the usbmon recording in:
> > 
> > 
> > > Normally the time between submission and callback for a given urb
> > > is short. However, some are much longer, e.g.:
> > >
> > >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 1522200650 S Bo:3:003:1 -115 62 = 3e00 ... <-- DELBA
> > >88012fe19500 1522200720 C Bo:3:003:1 0 126 > <-- DATA urb completion
> > >880146c8af00 1522200756 C Bo:3:003:1 0 62 > <-- DELBA urb completion
> > 
> > It would mean that the (delayed) urb with the *DATA* frame urb was not
> > sent (?or received?) by the usb dongle until the *DELBA* came along (1)
> > and triggered the TX for both (in quick succession). So, I think we 
> > should be looking for lost/unhandled interrupts/events.
> > 
> > One more thing: So far this issue only occurs with:
> > 00:14.0 USB controller [0c03]: Intel Corporation 7 Series/C210 Series 
> > Chipset Family USB xHCI Host Controller [8086:1e31] (rev 04) (prog-if 30 
> > [XHCI])
> 
> 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 the xHCI rings if the data URB stalls for longer than say, a
> minute.

I'll do this.

> As for lost interrupts, the only issue we had with that particular xHCI
> host had to do with lost isochronous transfers.  We fixed that with a
> quirk to avoid the BEI flag on that platform.  But your data is being
> sent via a bulk endpoint, so we shouldn't have any issues there.
> 
> > However, it not all xhci-hcd are affected. I have not seen this with
> > the NEC Corporation uPD720200 I have in my sandy bridge laptop:
> > 19:00.0 USB controller [0c03]: NEC Corporation uPD720200 USB 3.0 Host 
> > Controller [1033:0194] (rev 04)
> 
> 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 a link so I can purchase the device and test it
> with my analyzer?

Hmm. This looks the same, but it sounds like there are multiple hardware
versions sold under the same name so I'm not sure. The one I have is
hardware version A2.

http://www.amazon.com/D-Link-DWA-160-Extreme-N-Dual-Band-802-11n/dp/B00127OVHI

Seth

--
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: carl9170 A-MPDU transmit problem

[Christian Lamparter]

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 a link so I can purchase the device and test it
> > with my analyzer?
> 
> Hmm. This looks the same, but it sounds like there are multiple hardware
> versions sold under the same name so I'm not sure. The one I have is
> hardware version A2.
> 
> http://www.amazon.com/D-Link-DWA-160-Extreme-N-Dual-Band-802-11n/dp/B00127OVHI
> 
Or this one:


In the description they say it's A2 (so it should be the same Seth is using)
(Note: The "current" DWA-160 have RaLink/MediaTek chips)

Regards,
Chr
--
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: carl9170 A-MPDU transmit problem

[Alan Stern]

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 1522200650 S Bo:3:003:1 -115 62 = 3e00 ... <-- DELBA
> > > >88012fe19500 1522200720 C Bo:3:003:1 0 126 > <-- DATA urb completion
> > > >880146c8af00 1522200756 C Bo:3:003:1 0 62 > <-- DELBA urb completion

> > 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 the xHCI rings if the data URB stalls for longer than say, a
> > minute.
> 
> I'll do this.

Bear in mind that the usbmon trace shows the URB stalling for 2 - 3
seconds.  There may have been other examples that went on for longer,
but probably nothing anywhere near as long as a minute.

Alan Stern

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

Re: carl9170 A-MPDU transmit problem

[Seth Forshee]

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
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

[Felipe Balbi]

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, since TI's TUSB7340 is built with a USB3
> > > > Certified IP.
> > > > 
> > > 
> > > We have try two devices, both are USB-IF certified, on this host and
> > > they fail with same scenario.
> > > And these two devices can successfully reset several times on some
> > > other host.
> > 
> > that's alright, I'm just wondering how come this wasn't caught during
> > certification... perhaps certification lab didn't use a device with
> > periodic endpoints to run the test.
> 
> Or maybe they issue a Configure Endpoint command to drop all endpoints
> before they issue the Reset Device command?  That was my proposed
> work-around.

well, if it works, great :-) Funny that I couldn't reproduce it here
though :-s

-- 
balbi


signature.asc
Description: Digital signature

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

[David Miller]

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 linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Testing for hardware bug in EHCI controllers

[Alan Stern]

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 this bug in
any EHCI controller, without the need for a g-zero gadget.  It's a
two-part procedure:

Apply the patch below (which is written for vanilla 3.8) and
load the resulting driver.  The patch adds an explicit test
to ehci-hcd for detecting the bug.

Then plug in an ordinary USB flash drive and run the attached
program (as root), giving it the device path for the flash
drive as the single command-line argument.  For example:

sudo ./ehci-test /dev/bus/usb/002/003

The program won't do anything bad to the flash drive; it just reads the
first 256 KB of data over and over again, now and then unlinking an URB
to try and trigger the bug.  If the program works right, it will print
out a loop counter every hundred iterations.  If it runs for 1000
iterations with no error messages in the kernel log, you may consider
that the controller has passed the test.  This should take under a
minute, depending on the hardware speed.

The program won't stop by itself unless something goes wrong.  You can
kill it with ^C or more simply by unplugging the flash drive.  (If you
want to be safe, make sure there are no mounted filesystems on the
drive before running the test program.)

If the hardware bug is detected, the kernel patch will print error
messages to the system log.  For example, when I run the test on the
Intel controller in this computer, I get:

[  150.019441] usb-storage 3-8:1.0: disconnect by usbfs
[  150.271190] ehci-pci :00:1d.7: EHCI hardware bug detected: 8d00 
80008d00
[  150.591089] ehci-pci :00:1d.7: EHCI hardware bug detected: 8d00 
80008d00
[  151.538560] ehci-pci :00:1d.7: EHCI hardware bug detected: 8d00 
80008d00
[  151.857569] ehci-pci :00:1d.7: EHCI hardware bug detected: 8d00 
80008d00
[  152.018886] ehci-pci :00:1d.7: EHCI hardware bug detected: 8d00 
80008d00
[  152.179810] ehci-pci :00:1d.7: EHCI hardware bug detected: 80008d00 
8d00
[  153.211804] ehci-pci :00:1d.7: EHCI hardware bug detected: 8d00 
80008d00
[  153.374497] ehci-pci :00:1d.7: EHCI hardware bug detected: 8d00 
80008d00
[  153.770443] ehci-pci :00:1d.7: EHCI hardware bug detected: 80008d00 
8d00
[  154.247861] ehci-pci :00:1d.7: EHCI hardware bug detected: 82008d80 
8d00
[  154.566912] ehci-pci :00:1d.7: EHCI hardware bug detected: 82008d80 
8d00
[  155.359101] ehci-pci :00:1d.7: EHCI hardware bug detected: 8d00 
80008d00
[  155.838132] ehci-pci :00:1d.7: EHCI hardware bug detected: 8d00 
80008d00
[  156.791107] ehci-pci :00:1d.7: EHCI hardware bug detected: 80008d00 
8d00
[  157.267620] ehci-pci :00:1d.7: EHCI hardware bug detected: 8d00 
80008d00
[  159.252057] ehci-pci :00:1d.7: EHCI hardware bug detected: 80008d00 
8d00
[  159.886048] ehci-pci :00:1d.7: EHCI hardware bug detected: 80008d00 
8d00
[  160.206625] ehci-pci :00:1d.7: EHCI hardware bug detected: 02008d80 
80008d00
...

You get the idea.  The values in the two columns on the right are 
always supposed to be equal; when they aren't it indicates that the 
controller has done a DMA write at a time when ehci-hcd isn't expecting 
one to happen.

I'd be interested to hear the results of testing on a variety of 
controllers.  (This computer also has an NEC EHCI controller, and that 
one does not have the bug.)  Do the EHCI controllers on current Intel 
chipsets pass the test?  What about other vendors?

Thanks to all who try it out and report their results.

Alan Stern




Index: usb-3.8/drivers/usb/host/ehci-q.c
===
--- usb-3.8.orig/drivers/usb/host/ehci-q.c
+++ usb-3.8/drivers/usb/host/ehci-q.c
@@ -547,7 +547,7 @@ qh_completions (struct ehci_hcd *ehci, s
if (stopped != 0 || hw->hw_qtd_next == EHCI_LIST_END(ehci)) {
switch (state) {
case QH_STATE_IDLE:
-   qh_refresh(ehci, qh);
+// qh_refresh(ehci, qh);
break;
case QH_STATE_LINKED:
/* We won't refresh a QH that's linked (after the HC
@@ -1232,6 +1232,7 @@ static void start_iaa_cycle(struct ehci_
 static void end_unlink_async(struct ehci_hcd *ehci)
 {
struct ehci_qh  *qh;
+   __hc32  tok1, tok2;
 
if (ehci->has_synopsys_hc_bug)
ehci_writel(ehci, (u32) ehci->async->qh_dma,
@@ -1242,6 +1243,7 @@ static void end_unlink_async(struct ehci
ehci->async_unlinking = true;
while (ehci->async_iaa) {
qh = ehci->async_iaa;
+   tok1

Re: Testing for hardware bug in EHCI controllers

[Sarah Sharp]

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 quite true.
> 
> Now I have figured out a simple way for anyone to test for this bug in
> any EHCI controller, without the need for a g-zero gadget.  It's a
> two-part procedure:

Thanks Alan!  I'll try this on the Ivy Bridge and Haswell EHCI hosts.

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

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

[Tony Camuso]

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 in
xhci.c that had to be exposed so they could be called by
xhci_bus_suspend and xhci_bus_resume.

Besides that, xchi_bus_suspend/resume are called a number of times
during boot. I don't know why this is, but you may be able to shed
some light on that. Furthermore, xhci_bus_suspend is called before
xhci_bus_resume, so an attempt is made to delete the compliance
mode recovery timer, which does not yet exist. This produces a
list_add corruption call trace a number of times during boot.

Ultimately, the system panics.


Or do you need the timer to remain running even while the root hub
and USB bus are suspended?



Did not get far enough to determine this.


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

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

[Alan Stern]

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,
> 
> I tried implementing this. There were some static functions in
> xhci.c that had to be exposed so they could be called by
> xhci_bus_suspend and xhci_bus_resume.
> 
> Besides that, xchi_bus_suspend/resume are called a number of times
> during boot. I don't know why this is, but you may be able to shed
> some light on that.

Probably because the buses are registered at boot but there aren't any
devices plugged in.  (Or maybe there are devices, but the system is too
busy doing other things during boot to detect them for a while.)  
Since the buses are idle, they get suspended.

>  Furthermore, xhci_bus_suspend is called before
> xhci_bus_resume, so an attempt is made to delete the compliance
> mode recovery timer, which does not yet exist. This produces a
> list_add corruption call trace a number of times during boot.

That doesn't make sense.  The timer must be added somewhere other than
in xhci_bus_resume; otherwise it would never get activated in the
current xhci-hcd.  Wherever that other place is, it should still be in
operation.

Alan Stern

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

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

[Sarah Sharp]

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 resource for old configuration after 
> > USB bus reset
> > 
> > 2013/2/19 Soar Hung :
> > > Hi all,
> > >
> > > I checkout the usb-next branch (on 2/18) and following the 
> > https://wiki.ubuntu.com/KernelTeam/GitKernelBuild to build the kernel.
> > >
> > > After reboot, the new kernel version is Linux dev 
> > 3.8.0-rc5-usbnext #1 SMP Mon Feb 18 18:04:02 CST 2013 i686 
> > i686 i386 GNU/Linux.
> > >
> > > 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 setting CONFIG_LOG_BUF_SHIFT=21.

> What information do we want from these two debug config?

Everything.  I'd like to understand exactly what's happening at the xHCI
driver level.  I probably only need to see three reset cycles.  Zip up
the log file or use pastebin if you think the log file is too big.

> We currently know that the issue is fail at the configure endpoint
> command after bus reset.
> 
> The failing reason is the reset operation make the endpoint state
> disabled, and HCD still try to drop the disabled endpoint.
>
> This cause the host can not manage its resouce correctly. As a result,
> the last configure command fail with not enough bandwidth.

Are you saying the xHCI driver is trying to issue a Configure Endpoint
command with the drop flag set for an endpoint that was removed by the
Reset Device command?

If so, I would like to see the log files so I can debug why that
happened.

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

Bug in xHCI command cancellation

[Sarah Sharp]

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 that long, since other things
like port status change events can cause the interrupt handler to be
called (which would attempt to acquire the spinlock).

Would it be OK to drop the spinlock in xhci_abort_cmd_ring() before
spinning on the CRR?  Or were you trying to protect some other xHCI
structures/registers with the lock while you waited to abort the command
ring?

It's commit ID b92cc66c047ff7cf587b318fe377061a353c120f "xHCI: add
aborting command ring function" if you need to refresh your memory.

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

Re: carl9170 A-MPDU transmit problem

[Seth Forshee]

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 the xHCI rings if the data URB stalls for longer than say, a
> > minute.
> 
> I'll do this.

dmesg turned out to be rather large here, so I put in on a server rather
than attaching it. Here's the link.

http://people.canonical.com/~sforshee/dmesg-carl9170-usb-debug.txt

Thanks,
Seth

--
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: carl9170 A-MPDU transmit problem

[Christian Lamparter]

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 data to the host via EP2 - so it is working!]
> > > > >
> > > > >880146c8af00 1522200650 S Bo:3:003:1 -115 62 = 3e00 ... <-- 
> > > > >DELBA
> > > > >88012fe19500 1522200720 C Bo:3:003:1 0 126 > <-- DATA urb 
> > > > >completion
> > > > >880146c8af00 1522200756 C Bo:3:003:1 0 62 > <-- DELBA urb 
> > > > >completion
> 
> > > 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 the xHCI rings if the data URB stalls for longer than say, a
> > > minute.
> > 
> > I'll do this.
> 
> Bear in mind that the usbmon trace shows the URB stalling for 2 - 3
> seconds.  There may have been other examples that went on for longer,
> but probably nothing anywhere near as long as a minute.
> 
---
This should open up the window for as long as we want it. 
The driver will now queue, but not deliver any frames to
the device when there are unfinished urbs.

Note: Just in case someone is interested in the interval
values of the eps. I attached a lsusb dump of a typical
carl9170 device (So, apart from the vendor and product
id, it should be the same for DWA-160 A2).

Regards,
Christian
---
diff --git a/drivers/net/wireless/ath/carl9170/tx.c 
b/drivers/net/wireless/ath/carl9170/tx.c
index 9c0b150..3931a1e 100644
--- a/drivers/net/wireless/ath/carl9170/tx.c
+++ b/drivers/net/wireless/ath/carl9170/tx.c
@@ -598,7 +598,6 @@ next:
 *  - all bugs you can't...
 *  - ...
 */
-   carl9170_restart(ar, CARL9170_RR_STUCK_TX);
}
 }
 
@@ -1336,6 +1335,9 @@ static void carl9170_tx(struct ar9170 *ar)
if (unlikely(!IS_STARTED(ar)))
return;
 
+   if (atomic_read(&ar->tx_total_pending))
+   return;
+
carl9170_usb_handle_tx_err(ar);
 
for (i = 0; i < ar->hw->queues; i++) {
---

Bus 004 Device 005: ID 0846:9010 NetGear, Inc. WNDA3100v1 802.11abgn [Atheros 
AR9170+AR9104]
Device Descriptor:
  bLength18
  bDescriptorType 1
  bcdUSB   2.00
  bDeviceClass  255 Vendor Specific Class
  bDeviceSubClass   255 Vendor Specific Subclass
  bDeviceProtocol   255 Vendor Specific Protocol
  bMaxPacketSize064
  idVendor   0x0846 NetGear, Inc.
  idProduct  0x9010 WNDA3100v1 802.11abgn [Atheros AR9170+AR9104]
  bcdDevice1.06
  iManufacturer  16 ATHER
  iProduct   32 USB2.0 WLAN
  iSerial48 12345
  bNumConfigurations  1
  Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength   46
bNumInterfaces  1
bConfigurationValue 1
iConfiguration  0 
bmAttributes 0x80
  (Bus Powered)
MaxPower  500mA
Interface Descriptor:
  bLength 9
  bDescriptorType 4
  bInterfaceNumber0
  bAlternateSetting   0
  bNumEndpoints   4
  bInterfaceClass   255 Vendor Specific Class
  bInterfaceSubClass  0 
  bInterfaceProtocol  0 
  iInterface  0 
  Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x01  EP 1 OUT
bmAttributes2
  Transfer TypeBulk
  Synch Type   None
  Usage Type   Data
wMaxPacketSize 0x0200  1x 512 bytes
bInterval   0
  Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x82  EP 2 IN
bmAttributes2
  Transfer TypeBulk
  Synch Type   None
  Usage Type   Data
wMaxPacketSize 0x0200  1x 512 bytes
bInterval   0
  Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x83  EP 3 IN
bmAttributes3
  Transfer TypeInterrupt
  Synch Type   None
  Usage Type   Data
wMaxPacketSize 0x0040  1x 64 bytes
bInterval   1
  Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x04  EP 4 OUT
bmAttributes3
  Transfer TypeInterrupt
  Synch Type   None
  Usage Type

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

[Greg Kroah-Hartman]

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 Seattle
> (USA). Just like an emergent virus, our age of e-commerce and
> airmail allows underdocumented hardware to spread around the
> world instantly using the vector of ridiculously low prices.
> 
> Paige Thompson, infected via eBay, discovered that the HG20F9
> is a copy of the Asix 88772B; many viruses copy the RNA of
> other viruses. See Paige's work at
> .
> This patch uses her discovery to update the restructured Asix
> driver in the current kernel.
> 
> The spread of viruses is often accompanied by rumours. It is
> rumoured that the HG20F9 has extensions to to provide gigabit
> ethernet. This patch does not chase that chimera.
> 
> Just as some viruses inhabit seemingly-healthy cells, the
> HG20F9 uses the Vendor ID 0x066b assigned to Linksys Inc.
> For the present there is no clash of Product ID 0x20f9.
> 
> Signed-off-by: Glen Turner 

That is the best "add a new device id" changelog entry I have _ever_
seen.  Wonderful job:

Acked-by: Greg Kroah-Hartman 
--
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/net/asix_devices: Add USBNET HG20F9 ethernet dongle

[David Miller]

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). A web search
>> shows other recent purchasers in Lancaster (UK) and Seattle
>> (USA). Just like an emergent virus, our age of e-commerce and
>> airmail allows underdocumented hardware to spread around the
>> world instantly using the vector of ridiculously low prices.
>> 
>> Paige Thompson, infected via eBay, discovered that the HG20F9
>> is a copy of the Asix 88772B; many viruses copy the RNA of
>> other viruses. See Paige's work at
>> .
>> This patch uses her discovery to update the restructured Asix
>> driver in the current kernel.
>> 
>> The spread of viruses is often accompanied by rumours. It is
>> rumoured that the HG20F9 has extensions to to provide gigabit
>> ethernet. This patch does not chase that chimera.
>> 
>> Just as some viruses inhabit seemingly-healthy cells, the
>> HG20F9 uses the Vendor ID 0x066b assigned to Linksys Inc.
>> For the present there is no clash of Product ID 0x20f9.
>> 
>> Signed-off-by: Glen Turner 
> 
> That is the best "add a new device id" changelog entry I have _ever_
> seen.  Wonderful job:
> 
> Acked-by: Greg Kroah-Hartman 

Was this patch really submitted properly to netdev?  I can't
find it in patchwork at all.
--
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/net/asix_devices: Add USBNET HG20F9 ethernet dongle

[Greg KH]

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 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
> >> airmail allows underdocumented hardware to spread around the
> >> world instantly using the vector of ridiculously low prices.
> >> 
> >> Paige Thompson, infected via eBay, discovered that the HG20F9
> >> is a copy of the Asix 88772B; many viruses copy the RNA of
> >> other viruses. See Paige's work at
> >> .
> >> This patch uses her discovery to update the restructured Asix
> >> driver in the current kernel.
> >> 
> >> The spread of viruses is often accompanied by rumours. It is
> >> rumoured that the HG20F9 has extensions to to provide gigabit
> >> ethernet. This patch does not chase that chimera.
> >> 
> >> Just as some viruses inhabit seemingly-healthy cells, the
> >> HG20F9 uses the Vendor ID 0x066b assigned to Linksys Inc.
> >> For the present there is no clash of Product ID 0x20f9.
> >> 
> >> Signed-off-by: Glen Turner 
> > 
> > That is the best "add a new device id" changelog entry I have _ever_
> > seen.  Wonderful job:
> > 
> > Acked-by: Greg Kroah-Hartman 
> 
> Was this patch really submitted properly to netdev?  I can't
> find it in patchwork at all.

It was Cc: net...@vger.kernel.org with Message-ID:
<1361852232.23197.4.ca...@andromache.adelaide.aarnet.edu.au> so it
should have gone through there somehow.

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: Not enough resource for old configuration after USB bus reset

[Soar Hung]

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 do not use periodic tranfer.
So they can not produce the issue.

The lspci shows Texas Instruments Device 8241 (rev 02).
Is this the same?


Best regards,
Soar
--
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/net/asix_devices: Add USBNET HG20F9 ethernet dongle

[David Miller]

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 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
>> >> airmail allows underdocumented hardware to spread around the
>> >> world instantly using the vector of ridiculously low prices.
>> >> 
>> >> Paige Thompson, infected via eBay, discovered that the HG20F9
>> >> is a copy of the Asix 88772B; many viruses copy the RNA of
>> >> other viruses. See Paige's work at
>> >> .
>> >> This patch uses her discovery to update the restructured Asix
>> >> driver in the current kernel.
>> >> 
>> >> The spread of viruses is often accompanied by rumours. It is
>> >> rumoured that the HG20F9 has extensions to to provide gigabit
>> >> ethernet. This patch does not chase that chimera.
>> >> 
>> >> Just as some viruses inhabit seemingly-healthy cells, the
>> >> HG20F9 uses the Vendor ID 0x066b assigned to Linksys Inc.
>> >> For the present there is no clash of Product ID 0x20f9.
>> >> 
>> >> Signed-off-by: Glen Turner 
>> > 
>> > That is the best "add a new device id" changelog entry I have _ever_
>> > seen.  Wonderful job:
>> > 
>> > Acked-by: Greg Kroah-Hartman 
>> 
>> Was this patch really submitted properly to netdev?  I can't
>> find it in patchwork at all.
> 
> It was Cc: net...@vger.kernel.org with Message-ID:
> <1361852232.23197.4.ca...@andromache.adelaide.aarnet.edu.au> so it
> should have gone through there somehow.

Nope:

http://marc.info/?t=13618526711&r=1&w=2

It didn't make it to any of the lists, that's why you are the
only person who saw the original patch.
--
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/net/asix_devices: Add USBNET HG20F9 ethernet dongle

[Glen Turner]

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
airmail allows underdocumented hardware to spread around the
world instantly using the vector of ridiculously low prices.

Paige Thompson, infected via eBay, discovered that the HG20F9
is a copy of the Asix 88772B; many viruses copy the RNA of
other viruses. See Paige's work at
.
This patch uses her discovery to update the restructured Asix
driver in the current kernel.

The spread of viruses is often accompanied by rumours. It is
rumoured that the HG20F9 has extensions to to provide gigabit
ethernet. This patch does not chase that chimera.

Just as some viruses inhabit seemingly-healthy cells, the
HG20F9 uses the Vendor ID 0x066b assigned to Linksys Inc.
For the present there is no clash of Product ID 0x20f9.

Signed-off-by: Glen Turner 
---
 drivers/net/usb/asix_devices.c |   24 
 1 file changed, 24 insertions(+)

diff --git a/drivers/net/usb/asix_devices.c b/drivers/net/usb/asix_devices.c
index 7a6e758..649025d 100644
--- a/drivers/net/usb/asix_devices.c
+++ b/drivers/net/usb/asix_devices.c
@@ -883,6 +883,24 @@ static const struct driver_info ax88178_info = {
.tx_fixup = asix_tx_fixup,
 };
 
+// USBLINK 20F9 "USB 2.0 LAN" USB ethernet adapter, typically found in
+// no-name packaging.
+// USB device strings are:
+//   1: Manufacturer: USBLINK
+//   2: Product: HG20F9 USB2.0
+//   3: Serial: 03
+// Appears to be compatible with Asix 88772B.
+static const struct driver_info hg20f9_info = {
+   .description = "HG20F9 USB 2.0 Ethernet",
+   .bind = ax88772_bind,
+   .status = asix_status,
+   .link_reset = ax88772_link_reset,
+   .reset = ax88772_reset,
+   .flags = FLAG_ETHER | FLAG_FRAMING_AX | FLAG_LINK_INTR | 
FLAG_MULTI_PACKET,
+   .rx_fixup = asix_rx_fixup,
+   .tx_fixup = asix_tx_fixup,
+};
+
 extern const struct driver_info ax88172a_info;
 
 static const struct usb_device_id  products [] = {
@@ -1022,6 +1040,12 @@ static const struct usb_device_idproducts [] = {
/* ASIX 88172a demo board */
USB_DEVICE(0x0b95, 0x172a),
.driver_info = (unsigned long) &ax88172a_info,
+}, {
+   // USBLINK HG20F9 "USB 2.0 LAN"
+   // Appears to have gazumped Linksys's manufacturer ID but
+   // doesn't (yet) conflict with any known Linksys product.
+   USB_DEVICE(0x066b, 0x20f9),
+   .driver_info = (unsigned long) &hg20f9_info,
 },
{ },// END
 };
-- 
1.7.10.4

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

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

[Greg KH]

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 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 Seattle
> >> >> (USA). Just like an emergent virus, our age of e-commerce and
> >> >> airmail allows underdocumented hardware to spread around the
> >> >> world instantly using the vector of ridiculously low prices.
> >> >> 
> >> >> Paige Thompson, infected via eBay, discovered that the HG20F9
> >> >> is a copy of the Asix 88772B; many viruses copy the RNA of
> >> >> other viruses. See Paige's work at
> >> >> .
> >> >> This patch uses her discovery to update the restructured Asix
> >> >> driver in the current kernel.
> >> >> 
> >> >> The spread of viruses is often accompanied by rumours. It is
> >> >> rumoured that the HG20F9 has extensions to to provide gigabit
> >> >> ethernet. This patch does not chase that chimera.
> >> >> 
> >> >> Just as some viruses inhabit seemingly-healthy cells, the
> >> >> HG20F9 uses the Vendor ID 0x066b assigned to Linksys Inc.
> >> >> For the present there is no clash of Product ID 0x20f9.
> >> >> 
> >> >> Signed-off-by: Glen Turner 
> >> > 
> >> > That is the best "add a new device id" changelog entry I have _ever_
> >> > seen.  Wonderful job:
> >> > 
> >> > Acked-by: Greg Kroah-Hartman 
> >> 
> >> Was this patch really submitted properly to netdev?  I can't
> >> find it in patchwork at all.
> > 
> > It was Cc: net...@vger.kernel.org with Message-ID:
> > <1361852232.23197.4.ca...@andromache.adelaide.aarnet.edu.au> so it
> > should have gone through there somehow.
> 
> Nope:
> 
> http://marc.info/?t=13618526711&r=1&w=2
> 
> It didn't make it to any of the lists, that's why you are the
> only person who saw the original patch.

Odd, I've now bounced it to the mailing lists, hopefully it gets there
that way.  If not, I can resend it from me directly.

I'll wait till the morning to see if the messages make it through the
lists.

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: Not enough resource for old configuration after USB bus reset

[Soar Hung]

 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 setting CONFIG_LOG_BUF_SHIFT=21.
> 
>> What information do we want from these two debug config?
> 
> Everything.  I'd like to understand exactly what's happening
> at the xHCI driver level.  I probably only need to see three
> reset cycles.  Zip up the log file or use pastebin if you
> think the log file is too big.
> 

I will append the dmesg log later.

>> We currently know that the issue is fail at the configure endpoint
>> command after bus reset. 
>> 
>> The failing reason is the reset operation make the endpoint state
>> disabled, and HCD still try to drop the disabled endpoint.
>> 
>> This cause the host can not manage its resouce correctly. As a
>> result, the last configure command fail with not enough bandwidth.
> 
> Are you saying the xHCI driver is trying to issue a Configure
> Endpoint command with the drop flag set for an endpoint that
> was removed by the Reset Device command?
> 
> If so, I would like to see the log files so I can debug why
> that happened.
> 

No. the drop endpoint function will notice the ep state is disabled,

And shows message like "drop endponits with disabled endpoint", 
then  skip the set drop flag.


Soar
--
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: Not enough resource for old configuration after USB bus reset

[Soar Hung]

> 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 planning on
> having the mainline kernel support your host controller.
> 

Please check the following link

Lspci -vvv
http://pastebin.com/SBkncaBf

Lspci -vvv -n
http://pastebin.com/i464n0AT

Thanks,
Soar
--
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: Not enough resource for old configuration after USB bus reset

[Soar Hung]

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 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_device, hcd issue a reset command.
>>> The reset device command make the endpoint state disabled without
>>> releaseing the bandwidth. 
>>> 
>>> After reset is done, the HCD try to reconfigure the device to
>>> previous active config by usb_hcd_alloc_bandwidth.
>>> The HCD does such thing by modifying drop and add flag in input
>>> context, and issue configure endpoint command to comoplete the
>>> operation. 
>>> 
>>> When executing drop_endpoint, the endpoint is already in the
>>> disabled state. This behavior is correct according to the spec. And
>>> the HC will not evaluate drop flag of disable endpoint,too.
>> 

>>> As a result, the HC can not drop the endpoint to release the
>>> bandwidth.
>> 
>> But if the endpoint is already dropped, why hasn't bandwidth
>> allocation being released too ? Sarah ?
> 
> I think we're talking past each other. :)  Soar, what
> bandwidth allocation resources are you talking about?  In the
> xHC hardware, or in the xHCI driver?  I've been talking about
> resources in the hardware only, but I want to confirm we're talking
> about the same thing. 
> 
As my understading, the bandwidth is managed by xHC(hardware),
The HCD(driver) only use xHCI input context and command to tell xHC do 
something.

> As I understand it, the Reset Device command should drop all
> bandwidth allocated within the xHC hardware.  Then we go back
> and re-add the endpoints, setting only the add flag in the
> input context.  As Soar mentioned, this is spec-compliant,
> but the host eventually gives an out-of-bandwidth completion
> code for the Configure Endpoint command.
> 

Now I understand why this is QUIRK not a fix.
Spec 4.6.11 says the xHC shall release bandwidth automatically when doing reset 
device command.


Best regards,
Soar
--
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: Not enough resource for old configuration after USB bus reset

[Soar Hung]

> 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 setting CONFIG_LOG_BUF_SHIFT=21.
>> 
>>> What information do we want from these two debug config?
>> 
>> Everything.  I'd like to understand exactly what's happening at the
>> xHCI driver level.  I probably only need to see three reset cycles.
>> Zip up the log file or use pastebin if you think the log file is too
>> big. 
>> 
> 
> I will append the dmesg log later.
> 

Please reference the following link

First attach :
http://pastebin.com/nN3SQuy0

Last few reset
http://pastebin.com/L2GxaS5M

Thanks,
Soar
--
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