usb 2.0 device connected on Super Speed HUB on USB 3.0 Port throws error during enumeration on 3.4 kernel.
Hi , I am working on 3.4 kernel , when i try to connect a USB 2.0 device on Super Speed HUB , i get following error. usb 3-1.1: Device not responding to set address. usb 3-1.1: device not accepting address 3, error -71 any inputs will be of great help. Thanks and Regards Vikas Sajjan
Re: [PATCH 1/3 v2] USB: ohci-exynos: Add support for device tree
On Thursday, July 12, 2012 2:55 PM, Vivek Gautam wrote:
This patch adds support to parse probe data for
ohci driver for exynos using device tree.
Signed-off-by: Thomas Abraham thomas.abra...@linaro.org
Signed-off-by: Abhilash Kesavan a.kesa...@samsung.com
Signed-off-by: Vivek Gautam gautam.vi...@samsung.com
diff --git a/drivers/usb/host/ohci-exynos.c b/drivers/usb/host/ohci-exynos.c
index 2909621..c4ad60f 100644
--- a/drivers/usb/host/ohci-exynos.c
+++ b/drivers/usb/host/ohci-exynos.c
@@ -12,6 +12,7 @@
*/
#include linux/clk.h
+#include linux/of.h
#include linux/platform_device.h
#include mach/ohci.h
#include plat/usb-phy.h
@@ -71,6 +72,8 @@ static const struct hc_driver exynos_ohci_hc_driver = {
.start_port_reset = ohci_start_port_reset,
};
+static u64 ohci_exynos_dma_mask = DMA_BIT_MASK(32);
+
static int __devinit exynos_ohci_probe(struct platform_device *pdev)
{
struct exynos4_ohci_platdata *pdata;
@@ -87,6 +90,16 @@ static int __devinit exynos_ohci_probe(struct
platform_device *pdev)
return -EINVAL;
}
+ /*
+ * Right now device-tree probed devices don't get dma_mask set.
+ * Since shared usb code relies on it, set it here for now.
+ * Once we move to full device tree support this will vanish off.
+ */
+ if (!pdev-dev.dma_mask)
+ pdev-dev.dma_mask = ohci_exynos_dma_mask;
+ if (!pdev-dev.coherent_dma_mask)
+ pdev-dev.coherent_dma_mask = DMA_BIT_MASK(32);
+
exynos_ohci = kzalloc(sizeof(struct exynos_ohci_hcd), GFP_KERNEL);
This makes conflict on 'usb-next' branch.
Please re-base the patch on 'usb-next' branch.
if (!exynos_ohci)
return -ENOMEM;
@@ -258,6 +271,14 @@ static const struct dev_pm_ops exynos_ohci_pm_ops = {
.resume = exynos_ohci_resume,
};
+#ifdef CONFIG_OF
+static const struct of_device_id exynos_ohci_match[] = {
+ { .compatible = samsung,exynos-ohci },
+ {},
+};
+MODULE_DEVICE_TABLE(of, exynos_ohci_match);
+#endif
+
static struct platform_driver exynos_ohci_driver = {
.probe = exynos_ohci_probe,
.remove = __devexit_p(exynos_ohci_remove),
@@ -266,6 +287,7 @@ static struct platform_driver exynos_ohci_driver = {
.name = exynos-ohci,
.owner = THIS_MODULE,
.pm = exynos_ohci_pm_ops,
+ .of_match_table = of_match_ptr(exynos_ohci_match),
}
};
--
1.7.0.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: Problems with the Nikon D800 and USB3
On 07/13/2012 12:26 AM, Richard Adams wrote: Hi, I've recently been doing some development work with the latest Linux Kernel (3.4 3.5rc6) and I'm experiencing problems with USB3 on both. I've been in conversation with the developers at gphoto and they've directed me to you? 1) The problem occurs when I plug in the Nikon D800 in to any of my USB3 ports 2) Ubuntu fails to mount the device 3) gphoto can issue a single command to the camera before it locks. The gphoto forum thread is below with more details is below: http://old.nabble.com/NikonD800-locks-after-first-access.-Log-included.-to34032300.html#a34034687 If I can provide any more information or you can advise in any way that would be fantastic! Ive attached the kernel log file to this mail. The device is disconnected just after hub_port_init(). I don't know why. Can you post a dmesg with CONFIG_USB_XHCI_HCD_DEBUGGING enabled? Thanks, Andiry -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: usb sound issue ...
On 07/13/2012 03:19 AM, Dr. Ing. Dieter Jurzitza wrote: Hi Andiry, hi Sarah, Andiry is right, the test patch was applied. Please advise what I can do on top of this ... Thank you for all your time and all your efforts, take care Sarah, What do you suggest? What should we do with a interrupted config endpoint command? Shall we mark the endpoint so later we know the endpoint is disabled because a config ep command has already been operated to drop it? Thanks, Andiry -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: usb 2.0 device connected on Super Speed HUB on USB 3.0 Port throws error during enumeration on 3.4 kernel.
On 07/13/2012 02:49 PM, VIKAS SAJJAN C wrote: Hi , I am working on 3.4 kernel , when i try to connect a USB 2.0 device on Super Speed HUB , i get following error. usb 3-1.1: Device not responding to set address. usb 3-1.1: device not accepting address 3, error -71 any inputs will be of great help. Thanks and Regards Vikas Sajjan¢éì¹» ®Þ~º¶¬–+-±éݶ¥Šw®žË›±Êâmébžìn±¸§¶›¡Ü¨}©ž²Æ zÚj:+v‰¨¾«‘êçzZ+€Ê+zf£¢·hšˆ§~††Ûiÿûàz¹ ®w¥¢¸?™¨èÚ¢)ߢf The address command is rejected by the device. What happens if you plug the device to EHCI controller or to xHCI root hub (without the SS hub)? Thanks, Andiry -- 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: g_serial and cdc_acm communications
Hi, However I have another problem. My host application calls SET_CONFIGURATION everytime it starts. On device side my application is running and waiting for data from Host. But whenever set config is called serial gadget driver (from composite.c) does soft reset and I think new port number is generated. Because of this my device application will not receive data until I close and reopen device node (/dev/ttyGS0). How to let device side application know that set_config is called and it needs to reopen device node? For the time being I have implemented work around but it may not be good workaround. In cdev structure I have added input dev and whenever set_config is called I generate input event at the end of function. My application looks for this event and if received it reinitializes device. Regards, Dipen Patel -- 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: Re: usb 2.0 device connected on Super Speed HUB on USB 3.0 Port throws error during enumeration on 3.4 kernel.
Hi Andiry, 1. xHCI root hub --- SS hub --- some other USB 2.0 devices - I tired with 2 more usb 2.0 devices , same error comes. 2. xHCI root hub --- some other SS hub or HS hub --- the same USB2.0 device -- i connected xHCI root hub --HS hub-- the same 2.0 device , it works fine. I dont have another SS hub to check with. please find the attachement fot the log. Regards Vikas Sajjan --- Original Message --- Sender : Andiry Xuandiry...@amd.com Date : Jul 13, 2012 17:11 (GMT+09:00) Title : Re: usb 2.0 device connected on Super Speed HUB on USB 3.0 Port throws error during enumeration on 3.4 kernel. On 07/13/2012 03:50 PM, VIKAS SAJJAN C wrote: Hi Andiry, Thanks for the reply. If I connect the USB 2.0 Device directly to the USB 3.0 Port (without the SS Hub ), it works fine. It even works fine if i connect the same USB 2.0 Device through a SS Hub connected to USB 2.0 port (EHCI root hub). the Problem comes if i connect the same USB 2.0 Device through a SS Hub connected to USB 3.0 port (XHCI root hub). When a SS hub is connected to EHCI, it just works like a HS hub. No address device command is issued. Can you post the output of lsusb - and lspci -vvnn? And what occurs with the following two scnearios: 1. xHCI root hub --- SS hub --- some other USB 2.0 devices 2. xHCI root hub --- some other SS hub or HS hub --- the same USB2.0 device Thanks, Andiry --- Original Message --- Sender : Andiry Xuandiry...@amd.com Date : Jul 13, 2012 16:29 (GMT+09:00) Title : Re: usb 2.0 device connected on Super Speed HUB on USB 3.0 Port throws error during enumeration on 3.4 kernel. On 07/13/2012 02:49 PM, VIKAS SAJJAN C wrote: Hi , I am working on 3.4 kernel , when i try to connect a USB 2.0 device on Super Speed HUB , i get following error. usb 3-1.1: Device not responding to set address. usb 3-1.1: device not accepting address 3, error -71 any inputs will be of great help. Thanks and Regards Vikas Sajjan¢éì¹» ®Þ~º¶¬–+-±éݶ¥Šw®žË›±Êâmébžìn±¸§¶›¡Ü¨}©ž²Æ zÚj:+v‰¨¾«‘êçzZ+€Ê+zf£¢·hšˆ§~††Ûiÿûàz¹ ®w¥¢¸?™¨èÚ¢)ߢf The address command is rejected by the device. What happens if you plug the device to EHCI controller or to xHCI root hub (without the SS hub)? Thanks, Andiry lsusb.txt Description: Binary data
[PATCH] USB: ehci-omap: fix compile failure(v1)
The omap_ehci_init() is introduced in the below commit:
commit 1a49e2ac9651df7349867a5cf44e2c83de1046af(EHCI:
centralize controller initialization)
the local variable of 'pdev' inside omap_ehci_init() is used
but not defined, so fix the compiling failure.
Cc: Alan Stern st...@rowland.harvard.edu
Signed-off-by: Ming Lei ming@canonical.com
---
drivers/usb/host/ehci-omap.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/usb/host/ehci-omap.c b/drivers/usb/host/ehci-omap.c
index 6133d93..ec21f4a 100644
--- a/drivers/usb/host/ehci-omap.c
+++ b/drivers/usb/host/ehci-omap.c
@@ -115,9 +115,8 @@ static void omap_ehci_erratum_i693(struct ehci_hcd *ehci)
clk_disable(usbhost_p2_fck);
}
-static void omap_ehci_soft_phy_reset(struct platform_device *pdev, u8 port)
+static void omap_ehci_soft_phy_reset(struct usb_hcd *hcd, u8 port)
{
- struct usb_hcd *hcd = dev_get_drvdata(pdev-dev);
unsigned long timeout = jiffies + msecs_to_jiffies(1000);
unsigned reg = 0;
@@ -139,7 +138,8 @@ static void omap_ehci_soft_phy_reset(struct platform_device
*pdev, u8 port)
cpu_relax();
if (time_after(jiffies, timeout)) {
- dev_dbg(pdev-dev, phy reset operation timed out\n);
+ dev_dbg(hcd-self.controller,
+ phy reset operation timed out\n);
break;
}
}
@@ -167,9 +167,9 @@ static int omap_ehci_init(struct usb_hcd *hcd)
/* Soft reset the PHY using PHY reset command over ULPI */
if (pdata-port_mode[0] == OMAP_EHCI_PORT_MODE_PHY)
- omap_ehci_soft_phy_reset(pdev, 0);
+ omap_ehci_soft_phy_reset(hcd, 0);
if (pdata-port_mode[1] == OMAP_EHCI_PORT_MODE_PHY)
- omap_ehci_soft_phy_reset(pdev, 1);
+ omap_ehci_soft_phy_reset(hcd, 1);
/* we know this is the memory we want, no need to ioremap again */
ehci-caps = hcd-regs;
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: usb 2.0 device connected on Super Speed HUB on USB 3.0 Port throws error during enumeration on 3.4 kernel.
On 07/13/2012 04:57 PM, VIKAS SAJJAN C wrote: Hi Andiry, 1. xHCI root hub --- SS hub --- some other USB 2.0 devices - I tired with 2 more usb 2.0 devices , same error comes. 2. xHCI root hub --- some other SS hub or HS hub --- the same USB2.0 device -- i connected xHCI root hub --HS hub-- the same 2.0 device , it works fine. I dont have another SS hub to check with. SO that sounds like a hub issue. please find the attachement fot the log. It's a VIA USB3.0 hub. I've not used it before but I heard it has several issues. So the easiest solution is to use another SS hub which passes USB-IF certification. Thanks, Andiry --- Original Message --- Sender : Andiry Xuandiry...@amd.com Date : Jul 13, 2012 17:11 (GMT+09:00) Title : Re: usb 2.0 device connected on Super Speed HUB on USB 3.0 Port throws error during enumeration on 3.4 kernel. On 07/13/2012 03:50 PM, VIKAS SAJJAN C wrote: Hi Andiry, Thanks for the reply. If I connect the USB 2.0 Device directly to the USB 3.0 Port (without the SS Hub ), it works fine. It even works fine if i connect the same USB 2.0 Device through a SS Hub connected to USB 2.0 port (EHCI root hub). the Problem comes if i connect the same USB 2.0 Device through a SS Hub connected to USB 3.0 port (XHCI root hub). When a SS hub is connected to EHCI, it just works like a HS hub. No address device command is issued. Can you post the output of lsusb - and lspci -vvnn? And what occurs with the following two scnearios: 1. xHCI root hub --- SS hub --- some other USB 2.0 devices 2. xHCI root hub --- some other SS hub or HS hub --- the same USB2.0 device Thanks, Andiry --- Original Message --- Sender : Andiry Xuandiry...@amd.com Date : Jul 13, 2012 16:29 (GMT+09:00) Title : Re: usb 2.0 device connected on Super Speed HUB on USB 3.0 Port throws error during enumeration on 3.4 kernel. On 07/13/2012 02:49 PM, VIKAS SAJJAN C wrote: Hi , I am working on 3.4 kernel , when i try to connect a USB 2.0 device on Super Speed HUB , i get following error. usb 3-1.1: Device not responding to set address. usb 3-1.1: device not accepting address 3, error -71 any inputs will be of great help. Thanks and Regards Vikas Sajjan¢éì¹» ®Þ~º¶¬–+-±éݶ¥Šw®žË›±Êâmébžìn±¸§¶›¡Ü¨}©ž²Æ zÚj:+v‰¨¾«‘êçzZ+€Ê+zf£¢·hšˆ§~††Ûiÿûàz¹ ®w¥¢¸?™¨èÚ¢)ߢf The address command is rejected by the device. What happens if you plug the device to EHCI controller or to xHCI root hub (without the SS hub)? Thanks, Andiry -- 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: Re: usb 2.0 device connected on Super Speed HUB on USB 3.0 Port throws error during enumeration on 3.4 kernel.
2012/7/13 VIKAS SAJJAN C vikas.saj...@samsung.com: Hi Andiry, 1. xHCI root hub --- SS hub --- some other USB 2.0 devices - I tired with 2 more usb 2.0 devices , same error comes. That is strange. The usb 3.0 hub is VIA VL810. I have a same usb 3.0 hub that has same firmware with your hub. But it works fine. I tested it on 3.5.0-rc4 and 3.4.0-rc2. Best Regards, Elric 2. xHCI root hub --- some other SS hub or HS hub --- the same USB2.0 device -- i connected xHCI root hub --HS hub-- the same 2.0 device , it works fine. I dont have another SS hub to check with. please find the attachement fot the log. Regards Vikas Sajjan --- Original Message --- Sender : Andiry Xuandiry...@amd.com Date : Jul 13, 2012 17:11 (GMT+09:00) Title : Re: usb 2.0 device connected on Super Speed HUB on USB 3.0 Port throws error during enumeration on 3.4 kernel. On 07/13/2012 03:50 PM, VIKAS SAJJAN C wrote: Hi Andiry, Thanks for the reply. If I connect the USB 2.0 Device directly to the USB 3.0 Port (without the SS Hub ), it works fine. It even works fine if i connect the same USB 2.0 Device through a SS Hub connected to USB 2.0 port (EHCI root hub). the Problem comes if i connect the same USB 2.0 Device through a SS Hub connected to USB 3.0 port (XHCI root hub). When a SS hub is connected to EHCI, it just works like a HS hub. No address device command is issued. Can you post the output of lsusb - and lspci -vvnn? And what occurs with the following two scnearios: 1. xHCI root hub --- SS hub --- some other USB 2.0 devices 2. xHCI root hub --- some other SS hub or HS hub --- the same USB2.0 device Thanks, Andiry --- Original Message --- Sender : Andiry Xuandiry...@amd.com Date : Jul 13, 2012 16:29 (GMT+09:00) Title : Re: usb 2.0 device connected on Super Speed HUB on USB 3.0 Port throws error during enumeration on 3.4 kernel. On 07/13/2012 02:49 PM, VIKAS SAJJAN C wrote: Hi , I am working on 3.4 kernel , when i try to connect a USB 2.0 device on Super Speed HUB , i get following error. usb 3-1.1: Device not responding to set address. usb 3-1.1: device not accepting address 3, error -71 any inputs will be of great help. Thanks and Regards Vikas Sajjan ¢éì¹» ®Þ~º¶ ¬–+-±éݶ ¥Šw®žË›±Êâmébžìn±¸§¶ ›¡Ü¨}©ž²Æ zÚj:+v‰¨¾ «‘êçzZ+€Ê+zf£¢·hšˆ§~††Ûiÿûàz¹ ®w¥¢¸?™¨èÚ¢)ߢ f The address command is rejected by the device. What happens if you plug the device to EHCI controller or to xHCI root hub (without the SS hub)? Thanks, Andiry -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: usb 2.0 device connected on Super Speed HUB on USB 3.0 Port throws error during enumeration on 3.4 kernel.
2012/7/13 Andiry Xu andiry...@amd.com: On 07/13/2012 04:57 PM, VIKAS SAJJAN C wrote: Hi Andiry, 1. xHCI root hub --- SS hub --- some other USB 2.0 devices - I tired with 2 more usb 2.0 devices , same error comes. 2. xHCI root hub --- some other SS hub or HS hub --- the same USB2.0 device -- i connected xHCI root hub --HS hub-- the same 2.0 device , it works fine. I dont have another SS hub to check with. SO that sounds like a hub issue. I think it seems like the hub is broken. please find the attachement fot the log. It's a VIA USB3.0 hub. I've not used it before but I heard it has several issues. So the easiest solution is to use another SS hub which passes USB-IF certification. Umm, Until now no one pass the USB-IF due to the Forum isn't ready for usb 3.0 hub. Thanks, Andiry --- Original Message --- Sender : Andiry Xuandiry...@amd.com Date : Jul 13, 2012 17:11 (GMT+09:00) Title : Re: usb 2.0 device connected on Super Speed HUB on USB 3.0 Port throws error during enumeration on 3.4 kernel. On 07/13/2012 03:50 PM, VIKAS SAJJAN C wrote: Hi Andiry, Thanks for the reply. If I connect the USB 2.0 Device directly to the USB 3.0 Port (without the SS Hub ), it works fine. It even works fine if i connect the same USB 2.0 Device through a SS Hub connected to USB 2.0 port (EHCI root hub). the Problem comes if i connect the same USB 2.0 Device through a SS Hub connected to USB 3.0 port (XHCI root hub). When a SS hub is connected to EHCI, it just works like a HS hub. No address device command is issued. Can you post the output of lsusb - and lspci -vvnn? And what occurs with the following two scnearios: 1. xHCI root hub --- SS hub --- some other USB 2.0 devices 2. xHCI root hub --- some other SS hub or HS hub --- the same USB2.0 device Thanks, Andiry --- Original Message --- Sender : Andiry Xuandiry...@amd.com Date : Jul 13, 2012 16:29 (GMT+09:00) Title : Re: usb 2.0 device connected on Super Speed HUB on USB 3.0 Port throws error during enumeration on 3.4 kernel. On 07/13/2012 02:49 PM, VIKAS SAJJAN C wrote: Hi , I am working on 3.4 kernel , when i try to connect a USB 2.0 device on Super Speed HUB , i get following error. usb 3-1.1: Device not responding to set address. usb 3-1.1: device not accepting address 3, error -71 any inputs will be of great help. Thanks and Regards Vikas Sajjan ¢éì¹» ®Þ~º¶ ¬–+-±éݶ ¥Šw®žË›±Êâmébžìn±¸§¶ ›¡Ü¨}©ž²Æ zÚj:+v‰¨¾ «‘êçzZ+€Ê+zf£¢·hšˆ§~††Ûiÿûàz¹ ®w¥¢¸?™¨èÚ¢)ߢ f The address command is rejected by the device. What happens if you plug the device to EHCI controller or to xHCI root hub (without the SS hub)? Thanks, Andiry -- 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 -- 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: Re: usb 2.0 device connected on Super Speed HUB on USB 3.0 Port throws error during enumeration on 3.4 kernel.
I tested same USB 2.0 device on a linux machine running 3.2.19 kernel connecting through same VIA SS hub. it works fine. now i wonder where is the issue in my 3.4.0 kernel. is it in my exynos driver or usb core... --- Original Message --- Sender : Elric Fuelric...@gmail.com Date : Jul 13, 2012 18:59 (GMT+09:00) Title : Re: usb 2.0 device connected on Super Speed HUB on USB 3.0 Port throws error during enumeration on 3.4 kernel. 2012/7/13 Andiry Xu andiry...@amd.com: On 07/13/2012 04:57 PM, VIKAS SAJJAN C wrote: Hi Andiry, 1. xHCI root hub --- SS hub --- some other USB 2.0 devices - I tired with 2 more usb 2.0 devices , same error comes. 2. xHCI root hub --- some other SS hub or HS hub --- the same USB2.0 device -- i connected xHCI root hub --HS hub-- the same 2.0 device , it works fine. I dont have another SS hub to check with. SO that sounds like a hub issue. I think it seems like the hub is broken. please find the attachement fot the log. It's a VIA USB3.0 hub. I've not used it before but I heard it has several issues. So the easiest solution is to use another SS hub which passes USB-IF certification. Umm, Until now no one pass the USB-IF due to the Forum isn't ready for usb 3.0 hub. Thanks, Andiry --- Original Message --- Sender : Andiry Xuandiry...@amd.com Date : Jul 13, 2012 17:11 (GMT+09:00) Title : Re: usb 2.0 device connected on Super Speed HUB on USB 3.0 Port throws error during enumeration on 3.4 kernel. On 07/13/2012 03:50 PM, VIKAS SAJJAN C wrote: Hi Andiry, Thanks for the reply. If I connect the USB 2.0 Device directly to the USB 3.0 Port (without the SS Hub ), it works fine. It even works fine if i connect the same USB 2.0 Device through a SS Hub connected to USB 2.0 port (EHCI root hub). the Problem comes if i connect the same USB 2.0 Device through a SS Hub connected to USB 3.0 port (XHCI root hub). When a SS hub is connected to EHCI, it just works like a HS hub. No address device command is issued. Can you post the output of lsusb - and lspci -vvnn? And what occurs with the following two scnearios: 1. xHCI root hub --- SS hub --- some other USB 2.0 devices 2. xHCI root hub --- some other SS hub or HS hub --- the same USB2.0 device Thanks, Andiry --- Original Message --- Sender : Andiry Xuandiry...@amd.com Date : Jul 13, 2012 16:29 (GMT+09:00) Title : Re: usb 2.0 device connected on Super Speed HUB on USB 3.0 Port throws error during enumeration on 3.4 kernel. On 07/13/2012 02:49 PM, VIKAS SAJJAN C wrote: Hi , I am working on 3.4 kernel , when i try to connect a USB 2.0 device on Super Speed HUB , i get following error. usb 3-1.1: Device not responding to set address. usb 3-1.1: device not accepting address 3, error -71 any inputs will be of great help. Thanks and Regards Vikas Sajjan ¢éì¹» ®Þ~º¶ ¬–+-±éݶ ¥Šw®žË›±Êâmébžìn±¸§¶ ›¡Ü¨}©ž²Æ zÚj:+v‰¨¾ «‘êçzZ+€Ê+zf£¢·hšˆ§~††Ûiÿûàz¹ ®w¥¢¸?™¨èÚ¢)ߢ f The address command is rejected by the device. What happens if you plug the device to EHCI controller or to xHCI root hub (without the SS hub)? Thanks, Andiry -- 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 7/13] USB:support the new interfaces of Huawei Data Card devices in option driver
From: fangxiaozhi huana...@huawei.com
1. This patch is based on the kernel of 3.5-rc6
2. In this patch, we add new micro for matching the series USB devices with
vendor ID and interface information.
3. In this patch, we add new declarations into option.c to support the new
interfaces of Huawei Data Card devices.
Signed-off-by: fangxiaozhi huana...@huawei.com
---
--- ../test/linux-3.5-rc6/include/linux/usb.h 2012-07-08 08:23:56.0
+0800
+++ include/linux/usb.h 2012-07-13 17:45:59.0 +0800
@@ -828,6 +828,27 @@ static inline int usb_make_path(struct u
.bInterfaceClass = (cl), \
.bInterfaceSubClass = (sc), \
.bInterfaceProtocol = (pr)
+/**
+ * * USB_VENDOR_AND_INTERFACE_INFO - describe a specific usb device with a
class of usb interfaces, but independent of product ID
+ * @vend: the 16 bit USB Vendor ID
+ * @cl: bInterfaceClass value
+ * @sc: bInterfaceSubClass value
+ * @pr: bInterfaceProtocol value
+ *
+ * This macro is used to create a struct usb_device_id that matches a
+ * series of devices with a vendor ID and a specific class of interfaces.
+ *
+ * This is especially useful when explicitly matching the specific interface
for series of different devices with
+ * the same vendor.
+ */
+
+#define USB_VENDOR_AND_INTERFACE_INFO(vend, cl, sc, pr) \
+ .match_flags = USB_DEVICE_ID_MATCH_INT_INFO \
+ | USB_DEVICE_ID_MATCH_VENDOR, \
+ .idVendor = (vend), \
+ .bInterfaceClass = (cl), \
+ .bInterfaceSubClass = (sc), \
+ .bInterfaceProtocol = (pr)
/* --- */
--- ../test/linux-3.5-rc6/drivers/usb/serial/option.c 2012-07-13
14:22:52.0 +0800
+++ drivers/usb/serial/option.c 2012-07-13 17:38:38.0 +0800
@@ -572,6 +572,115 @@ static const struct option_blacklist_inf
};
static const struct usb_device_id option_ids[] = {
+ { USB_VENDOR_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, 0xff, 0x01, 0x01) },
+ { USB_VENDOR_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, 0xff, 0x01, 0x02) },
+ { USB_VENDOR_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, 0xff, 0x01, 0x03) },
+ { USB_VENDOR_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, 0xff, 0x01, 0x04) },
+ { USB_VENDOR_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, 0xff, 0x01, 0x05) },
+ { USB_VENDOR_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, 0xff, 0x01, 0x06) },
+ { USB_VENDOR_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, 0xff, 0x01, 0x0A) },
+ { USB_VENDOR_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, 0xff, 0x01, 0x0B) },
+ { USB_VENDOR_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, 0xff, 0x01, 0x0D) },
+ { USB_VENDOR_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, 0xff, 0x01, 0x0E) },
+ { USB_VENDOR_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, 0xff, 0x01, 0x0F) },
+ { USB_VENDOR_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, 0xff, 0x01, 0x10) },
+ { USB_VENDOR_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, 0xff, 0x01, 0x12) },
+ { USB_VENDOR_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, 0xff, 0x01, 0x13) },
+ { USB_VENDOR_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, 0xff, 0x01, 0x14) },
+ { USB_VENDOR_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, 0xff, 0x01, 0x15) },
+ { USB_VENDOR_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, 0xff, 0x01, 0x17) },
+ { USB_VENDOR_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, 0xff, 0x01, 0x18) },
+ { USB_VENDOR_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, 0xff, 0x01, 0x19) },
+ { USB_VENDOR_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, 0xff, 0x01, 0x1A) },
+ { USB_VENDOR_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, 0xff, 0x01, 0x1B) },
+ { USB_VENDOR_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, 0xff, 0x01, 0x1C) },
+ { USB_VENDOR_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, 0xff, 0x01, 0x31) },
+ { USB_VENDOR_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, 0xff, 0x01, 0x32) },
+ { USB_VENDOR_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, 0xff, 0x01, 0x33) },
+ { USB_VENDOR_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, 0xff, 0x01, 0x34) },
+ { USB_VENDOR_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, 0xff, 0x01, 0x35) },
+ { USB_VENDOR_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, 0xff, 0x01, 0x36) },
+ { USB_VENDOR_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, 0xff, 0x01, 0x3A) },
+ { USB_VENDOR_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, 0xff, 0x01, 0x3B) },
+ { USB_VENDOR_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, 0xff, 0x01, 0x3D) },
+ { USB_VENDOR_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, 0xff, 0x01, 0x3E) },
+ { USB_VENDOR_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, 0xff, 0x01, 0x3F) },
+ { USB_VENDOR_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, 0xff, 0x01, 0x48) },
+ { USB_VENDOR_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, 0xff, 0x01, 0x49) },
+ { USB_VENDOR_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, 0xff, 0x01, 0x4A) },
+ { USB_VENDOR_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, 0xff, 0x01, 0x4B) },
+ { USB_VENDOR_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, 0xff, 0x01, 0x4C) },
+ {
Re: [PATCH -next] USB: ehci-omap: fix compile failure
Hello. On 13-07-2012 7:54, Ming Lei wrote: The omap_ehci_init() is introduced in the below commit: commit 1a49e2ac9651df7349867a5cf44e2c83de1046af(EHCI: centralize controller initialization) the local variable of 'pdev' inside omap_ehci_init() is used but not defined, so fix the bug. Cc: Alan Stern st...@rowland.harvard.edu Signed-off-by: Ming Lei ming@canonical.com --- drivers/usb/host/ehci-omap.c |4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/drivers/usb/host/ehci-omap.c b/drivers/usb/host/ehci-omap.c index 6133d93..4c43681 100644 --- a/drivers/usb/host/ehci-omap.c +++ b/drivers/usb/host/ehci-omap.c @@ -150,8 +150,10 @@ static int omap_ehci_init(struct usb_hcd *hcd) struct ehci_hcd *ehci = hcd_to_ehci(hcd); int rc; struct ehci_hcd_omap_platform_data *pdata; + struct platform_device *pdev = + to_platform_device(hcd-self.controller); - pdata = hcd-self.controller-platform_data; + pdata = platform_get_drvdata(pdev); First, you don't describe this change. Second, 'driver_data' and 'platform_data' fields is not the same, are you sure this change is correct. The declaration of 'pdata' suggests that it should be 'platform_data'. WBR, Sergei -- 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: Logitech USB keyboard arbitrarily gets unresponsive
Dear Alan, just before I forget, your mail program does not set the »References:« header field [1], so threading does not work if received and sent messages are stored in different folders. Am Mittwoch, den 11.07.2012, 11:44 -0400 schrieb Alan Stern: On Wed, 11 Jul 2012, Paul Menzel wrote: Am Mittwoch, den 04.07.2012, 21:25 -0400 schrieb Alan Stern: On Thu, 5 Jul 2012, Paul Menzel wrote: an USB Logitech keyboard Bus 004 Device 003: ID 046d:c30f Logitech, Inc. Logicool HID-Compliant Keyboard (106 key) arbitrarily gets unresponsive on my system and stays this way. I am working in X and suddenly nothing entered to the keyboard has an effect. I cannot switch to a virtual terminal with Ctrl + Alt + Fn, n ∈ ℕ, but the LEDs of the keyboard are still lighted. The USB mouse keeps working though. After plugging it out and back in it works again. The distribution is Debian Sid/unstable with Linux 3.2 and it happened with two mainboards, the ASUS M2A-VM [1] and ASRock A780FullHD [2]. Is the keyboard attached to an xHCI controller or something else (EHCI, UHCI, or OHCI)? It is directly plugged into the mainboard which only supports USB 2. Does that answer the question? If not, how do I find out? It says in the dmesg log when you plug in the keyboard: [ 7381.444185] usb 4-1: new low-speed USB device number 3 using ohci_hcd So the answer is OHCI. Please find the acquired logs attached. I did the following. 1. Keyboard unresponsive 2. log in with SSH 3. follow `Documentation/usb/usbmon.txt` 4. capture the traces $ sudo cat /sys/kernel/debug/usb/usbmon/4u /tmp/20120711--usbmon.out-hang-random-presses $ sudo cat /sys/kernel/debug/usb/usbmon/4u /tmp/20120711--usbmon.out.hang-before-unplug--asdf-return $ sudo cat /sys/kernel/debug/usb/usbmon/4u /tmp/20120711--usbmon.out.unplug-replug $ sudo cat /sys/kernel/debug/usb/usbmon/4u /tmp/20120711--usbmon.out.after-replug--asdf-return Very good. It looks like data is received. Not only is data received; the very same data is received in both cases. Therefore the keyboard is working correctly. So could it be an X (evdev)(?) problem? Maybe. You could test this. The next time the same thing happens, do a network login as root and run the command chvt 2. This will change from the graphics screen to the vt2 text console. See if the keyboard works then. Thank you for that great suggestion. The keyboard indeed does work in tty1 after doing `sudo chvt 1` beforehand over SSH. In theory the problem could be something really stupid. For example, typing a control-S in an xterm window (or at a text console) will suppress output to the screen until you type control-Q. Unfortunately this is not it. The awesome window manager does not provide such kind of feature and no input is received in any window, which I do can select because the mouse still works. So I guess it is an X problem. I will try to increase the debug level for the evdev module although I did not find such an option skimming through its manual. Thanks, Paul [1] http://cr.yp.to/immhf/thread.html signature.asc Description: This is a digitally signed message part
Re: [PATCH 7/13] USB:support the new interfaces of Huawei Data Card devices in option driver
Fangxiaozhi (Franko) fangxiao...@huawei.com writes:
From: fangxiaozhi huana...@huawei.com
1. This patch is based on the kernel of 3.5-rc6
2. In this patch, we add new micro for matching the series USB devices with
vendor ID and interface information.
3. In this patch, we add new declarations into option.c to support the new
interfaces of Huawei Data Card devices.
Signed-off-by: fangxiaozhi huana...@huawei.com
---
--- ../test/linux-3.5-rc6/include/linux/usb.h 2012-07-08 08:23:56.0
+0800
+++ include/linux/usb.h 2012-07-13 17:45:59.0 +0800
@@ -828,6 +828,27 @@ static inline int usb_make_path(struct u
.bInterfaceClass = (cl), \
.bInterfaceSubClass = (sc), \
.bInterfaceProtocol = (pr)
+/**
+ * * USB_VENDOR_AND_INTERFACE_INFO - describe a specific usb device with a
class of usb interfaces, but independent of product ID
This chunk seems like a copy of the patch Gustavo Padovan just
submitted? Should really be listed as a precondition instead of
included here, should it not?
--- ../test/linux-3.5-rc6/drivers/usb/serial/option.c 2012-07-13
14:22:52.0 +0800
+++ drivers/usb/serial/option.c 2012-07-13 17:38:38.0 +0800
@@ -572,6 +572,115 @@ static const struct option_blacklist_inf
};
static const struct usb_device_id option_ids[] = {
+ { USB_VENDOR_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, 0xff, 0x01, 0x01) },
+ { USB_VENDOR_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, 0xff, 0x01, 0x02) },
+ { USB_VENDOR_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, 0xff, 0x01, 0x03) },
I guess this means that the device specific entries matching this could
and should be removed, does it not? All these seem redundant with your
patch:
{ USB_DEVICE_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, HUAWEI_PRODUCT_K4605,
0xff, 0x01, 0x31) },
{ USB_DEVICE_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, HUAWEI_PRODUCT_K4605,
0xff, 0x01, 0x32) },
{ USB_DEVICE_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, HUAWEI_PRODUCT_K5005,
0xff, 0x01, 0x31) },
{ USB_DEVICE_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, HUAWEI_PRODUCT_K5005,
0xff, 0x01, 0x32) },
{ USB_DEVICE_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, HUAWEI_PRODUCT_K5005,
0xff, 0x01, 0x33) },
{ USB_DEVICE_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, HUAWEI_PRODUCT_K3770,
0xff, 0x02, 0x31) },
{ USB_DEVICE_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, HUAWEI_PRODUCT_K3770,
0xff, 0x02, 0x32) },
{ USB_DEVICE_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, HUAWEI_PRODUCT_K3771,
0xff, 0x02, 0x31) },
{ USB_DEVICE_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, HUAWEI_PRODUCT_K3771,
0xff, 0x02, 0x32) },
{ USB_DEVICE_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, HUAWEI_PRODUCT_K4510,
0xff, 0x01, 0x31) },
{ USB_DEVICE_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, HUAWEI_PRODUCT_K4510,
0xff, 0x01, 0x32) },
{ USB_DEVICE_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, HUAWEI_PRODUCT_K4511,
0xff, 0x01, 0x31) },
{ USB_DEVICE_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, HUAWEI_PRODUCT_K4511,
0xff, 0x01, 0x32) },
{ USB_DEVICE_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, HUAWEI_PRODUCT_E353,
0xff, 0x01, 0x01) },
{ USB_DEVICE_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, HUAWEI_PRODUCT_E353,
0xff, 0x01, 0x02) },
{ USB_DEVICE_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, HUAWEI_PRODUCT_E353,
0xff, 0x01, 0x03) },
{ USB_DEVICE_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, HUAWEI_PRODUCT_E353,
0xff, 0x01, 0x10) },
{ USB_DEVICE_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, HUAWEI_PRODUCT_E353,
0xff, 0x01, 0x12) },
{ USB_DEVICE_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, HUAWEI_PRODUCT_E353,
0xff, 0x01, 0x13) },
{ USB_DEVICE_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, HUAWEI_PRODUCT_E353,
0xff, 0x02, 0x01) }, /* E398 3G Modem */
{ USB_DEVICE_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, HUAWEI_PRODUCT_E353,
0xff, 0x02, 0x02) }, /* E398 3G PC UI Interface */
{ USB_DEVICE_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, HUAWEI_PRODUCT_E353,
0xff, 0x02, 0x03) }, /* E398 3G Application Interface */
+ { USB_VENDOR_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, 0xff, 0x01, 0x04) },
+ { USB_VENDOR_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, 0xff, 0x01, 0x05) },
+ { USB_VENDOR_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, 0xff, 0x01, 0x06) },
+ { USB_VENDOR_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, 0xff, 0x01, 0x0A) },
+ { USB_VENDOR_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, 0xff, 0x01, 0x0B) },
+ { USB_VENDOR_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, 0xff, 0x01, 0x0D) },
+ { USB_VENDOR_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, 0xff, 0x01, 0x0E) },
+ { USB_VENDOR_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, 0xff, 0x01, 0x0F) },
+ { USB_VENDOR_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, 0xff, 0x01, 0x10) },
+ { USB_VENDOR_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, 0xff, 0x01, 0x12) },
I see that the holes I know of are there, like protocol 0x08, 0x09 and
0x11. You wouldn't happen to have a complete list of those as
Re: [PATCH 12/12] USB: chipidea: add imx usbmisc support
On Thu, Jul 12, 2012 at 03:01:52PM +0800, Richard Zhao wrote:
i.MX usb controllers shares non-core registers, which may include
SoC specific controls. We take it as a usbmisc device and usbmisc
driver export functions needed by ci13xxx_imx driver.
So this is SoC and not chipidea specific and should not be sorted into
this subdir.
For example, Sabrelite board has bad over-current design, we can
usbmisc to disable over-current detect.
This driver layout is also reflected in:
arch/arm/mach-imx/ehci-imx*.c
You should use these existing mx*_initialize_usb_hw functions to avoid
code duplication and add your mx6_initialize_usb_hw routine for mx6 there.
This devicetree based glue code in this file can be reused to
call the right mx*_initialize_usb_hw by the compatible.
We already have common flags available like i.e. MXC_EHCI_POWER_PINS_ENABLED
which is currently used to disable overcurrent detection.
Signed-off-by: Richard Zhao richard.z...@freescale.com
---
.../devicetree/bindings/usb/imx-usbmisc.txt| 15 ++
drivers/usb/chipidea/Makefile |2 +-
drivers/usb/chipidea/ci13xxx_imx.c |4 +
drivers/usb/chipidea/imx_usbmisc.c | 144
4 files changed, 164 insertions(+), 1 deletion(-)
create mode 100644 Documentation/devicetree/bindings/usb/imx-usbmisc.txt
create mode 100644 drivers/usb/chipidea/imx_usbmisc.c
diff --git a/Documentation/devicetree/bindings/usb/imx-usbmisc.txt
b/Documentation/devicetree/bindings/usb/imx-usbmisc.txt
new file mode 100644
index 000..09f01ca
--- /dev/null
+++ b/Documentation/devicetree/bindings/usb/imx-usbmisc.txt
@@ -0,0 +1,15 @@
+* Freescale i.MX non-core registers
+
+Required properties:
+- compatible: Should be fsl,imx6q-usbmisc
+- reg: Should contain registers location and length
+
+Optional properties:
+- fsl,disable-over-current: disable over current detect
+
+Examples:
+usbmisc@02184800 {
+ compatible = fsl,imx6q-usbmisc;
+ reg = 0x02184800 0x200;
+ fsl,disable-over-current;
+};
diff --git a/drivers/usb/chipidea/Makefile b/drivers/usb/chipidea/Makefile
index 3f56b76..46fc31c 100644
--- a/drivers/usb/chipidea/Makefile
+++ b/drivers/usb/chipidea/Makefile
@@ -17,5 +17,5 @@ ifneq ($(CONFIG_PCI),)
endif
ifneq ($(CONFIG_OF_DEVICE),)
- obj-$(CONFIG_USB_CHIPIDEA) += ci13xxx_imx.o
+ obj-$(CONFIG_USB_CHIPIDEA) += ci13xxx_imx.o imx_usbmisc.o
endif
diff --git a/drivers/usb/chipidea/ci13xxx_imx.c
b/drivers/usb/chipidea/ci13xxx_imx.c
index b3173d8..dd7f3a3 100644
--- a/drivers/usb/chipidea/ci13xxx_imx.c
+++ b/drivers/usb/chipidea/ci13xxx_imx.c
@@ -24,6 +24,8 @@
#include ci.h
+int imx_usbmisc_init(struct device *usbdev);
+
#define pdev_to_phy(pdev) \
((struct usb_phy *)platform_get_drvdata(pdev))
#define ci_to_imx_data(ci) \
@@ -142,6 +144,8 @@ static int __devinit ci13xxx_imx_probe(struct
platform_device *pdev)
dma_set_coherent_mask(pdev-dev, *pdev-dev.dma_mask);
}
+ imx_usbmisc_init(pdev-dev);
+
platform_set_drvdata(pdev, data);
plat_ci = ci13xxx_add_device(pdev-dev,
diff --git a/drivers/usb/chipidea/imx_usbmisc.c
b/drivers/usb/chipidea/imx_usbmisc.c
new file mode 100644
index 000..33a8ec0
--- /dev/null
+++ b/drivers/usb/chipidea/imx_usbmisc.c
@@ -0,0 +1,144 @@
+/*
+ * Copyright 2012 Freescale Semiconductor, Inc.
+ *
+ * The code contained herein is licensed under the GNU General Public
+ * License. You may obtain a copy of the GNU General Public License
+ * Version 2 or later at the following locations:
+ *
+ * http://www.opensource.org/licenses/gpl-license.html
+ * http://www.gnu.org/copyleft/gpl.html
+ */
+
+#include linux/module.h
+#include linux/of_platform.h
+#include linux/clk.h
+#include linux/err.h
+#include asm/io.h
+
+struct usbmisc;
+
+struct soc_data {
+ int (*init) (struct usbmisc *usbmisc, int id);
+ void (*exit) (struct usbmisc *usbmisc, int id);
+};
+
+struct usbmisc {
+ struct soc_data *soc_data;
+ void __iomem *base;
+ struct clk *clk;
+
+ int dis_oc:1;
+};
+
+/* Since we only have one usbmisc device at runtime, we global variables */
+static struct usbmisc *usbmisc;
Global variable?
+
+static int imx6q_usbmisc_init(struct usbmisc *usbmisc, int id)
What is initialized here? How about preconfigure?
Even better is to reuse mx*_initialize_usb_hw here.
+{
+ u32 reg;
+
+ if (usbmisc-dis_oc) {
+ reg = readl_relaxed(usbmisc-base + id * 4);
+ writel_relaxed(reg | (1 7), usbmisc-base + id * 4);
#define IMX6_OTG_CTRL_USBMISC1 7
+ }
+
+ return 0;
+}
+
+static struct soc_data imx6q_data = {
+ .init = imx6q_usbmisc_init,
+};
+
+
+static const struct of_device_id imx_usbmisc_dt_ids[] = {
+ { .compatible = fsl,imx6q-usbmisc, .data = imx6q_data },
something like
Re: g_serial and cdc_acm communications
However I have another problem. My host application calls SET_CONFIGURATION everytime it starts. On device side my application is running and waiting for data from Host. But whenever set config is called serial gadget driver (from composite.c) does soft reset and I think new port number is generated. Because of this my device application will not receive data until I close and reopen device node (/dev/ttyGS0). So, the port number has not changed as you can still open with ttyGS0. The set_config should call gserial_disconnect from reading code. How to let device side application know that set_config is called and it needs to reopen device node? Are there any Error returns for read if you have disconnected the cable or set_config occurs? For the time being I have implemented work around but it may not be good workaround. In cdev structure I have added input dev and whenever set_config is called I generate input event at the end of function. My application looks for this event and if received it reinitializes device. Regards, Dipen Patel -- 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 -- 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: g_serial and cdc_acm communications
Peter Chen hzpeterchen@... writes: However I have another problem. My host application calls SET_CONFIGURATION everytime it starts. On device side my application is running and waiting for data from Host. But whenever set config is called serial gadget driver (from composite.c) does soft reset and I think new port number is generated. Because of this my device application will not receive data until I close and reopen device node (/dev/ttyGS0). So, the port number has not changed as you can still open with ttyGS0. The set_config should call gserial_disconnect from reading code. Well I have already open the port as soon as board boots and application starts. And after that I start my host application and it will first do set_config. Since my device has only one configuration it will perform reset and since acm_set_alt() calls gserial_connect() it will create new port (I think so). How to let device side application know that set_config is called and it needs to reopen device node? Are there any Error returns for read if you have disconnected the cable or set_config occurs? Read will return EAGAIN if set_config is called and I try to read. But I never get data untill I close and reopen /dev/ttyGS0 Regards, Dipen Patel -- 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 12/12] USB: chipidea: add imx usbmisc support
On Fri, Jul 13, 2012 at 02:25:45PM +0200, Michael Grzeschik wrote:
On Thu, Jul 12, 2012 at 03:01:52PM +0800, Richard Zhao wrote:
i.MX usb controllers shares non-core registers, which may include
SoC specific controls. We take it as a usbmisc device and usbmisc
driver export functions needed by ci13xxx_imx driver.
So this is SoC and not chipidea specific and should not be sorted into
this subdir.
Yes, but it's usb specific and serve chipidea usb IP.
For example, Sabrelite board has bad over-current design, we can
usbmisc to disable over-current detect.
This driver layout is also reflected in:
arch/arm/mach-imx/ehci-imx*.c
It sounds sensible, but I'm not quite sure. I saw drivers are moving
out of there, event it's SoC specific, for example, clk, pinmux. And
the non-core registers might not only be setup onetime on boot, but
be called at runtime by usb driver. For now, it's set once.
You should use these existing mx*_initialize_usb_hw functions to avoid
code duplication
I can not see what duplication it can avoid.
and add your mx6_initialize_usb_hw routine for mx6 there.
Maybe.
This devicetree based glue code in this file can be reused to
call the right mx*_initialize_usb_hw by the compatible.
The glue code makes it more like a normal driver. Doesn't it?
We already have common flags available like i.e. MXC_EHCI_POWER_PINS_ENABLED
which is currently used to disable overcurrent detection.
The flags may be replace with properties in DT bindings.
Signed-off-by: Richard Zhao richard.z...@freescale.com
---
.../devicetree/bindings/usb/imx-usbmisc.txt| 15 ++
drivers/usb/chipidea/Makefile |2 +-
drivers/usb/chipidea/ci13xxx_imx.c |4 +
drivers/usb/chipidea/imx_usbmisc.c | 144
4 files changed, 164 insertions(+), 1 deletion(-)
create mode 100644 Documentation/devicetree/bindings/usb/imx-usbmisc.txt
create mode 100644 drivers/usb/chipidea/imx_usbmisc.c
diff --git a/Documentation/devicetree/bindings/usb/imx-usbmisc.txt
b/Documentation/devicetree/bindings/usb/imx-usbmisc.txt
new file mode 100644
index 000..09f01ca
--- /dev/null
+++ b/Documentation/devicetree/bindings/usb/imx-usbmisc.txt
@@ -0,0 +1,15 @@
+* Freescale i.MX non-core registers
+
+Required properties:
+- compatible: Should be fsl,imx6q-usbmisc
+- reg: Should contain registers location and length
+
+Optional properties:
+- fsl,disable-over-current: disable over current detect
+
+Examples:
+usbmisc@02184800 {
+ compatible = fsl,imx6q-usbmisc;
+ reg = 0x02184800 0x200;
+ fsl,disable-over-current;
+};
diff --git a/drivers/usb/chipidea/Makefile b/drivers/usb/chipidea/Makefile
index 3f56b76..46fc31c 100644
--- a/drivers/usb/chipidea/Makefile
+++ b/drivers/usb/chipidea/Makefile
@@ -17,5 +17,5 @@ ifneq ($(CONFIG_PCI),)
endif
ifneq ($(CONFIG_OF_DEVICE),)
- obj-$(CONFIG_USB_CHIPIDEA) += ci13xxx_imx.o
+ obj-$(CONFIG_USB_CHIPIDEA) += ci13xxx_imx.o imx_usbmisc.o
endif
diff --git a/drivers/usb/chipidea/ci13xxx_imx.c
b/drivers/usb/chipidea/ci13xxx_imx.c
index b3173d8..dd7f3a3 100644
--- a/drivers/usb/chipidea/ci13xxx_imx.c
+++ b/drivers/usb/chipidea/ci13xxx_imx.c
@@ -24,6 +24,8 @@
#include ci.h
+int imx_usbmisc_init(struct device *usbdev);
+
#define pdev_to_phy(pdev) \
((struct usb_phy *)platform_get_drvdata(pdev))
#define ci_to_imx_data(ci) \
@@ -142,6 +144,8 @@ static int __devinit ci13xxx_imx_probe(struct
platform_device *pdev)
dma_set_coherent_mask(pdev-dev, *pdev-dev.dma_mask);
}
+ imx_usbmisc_init(pdev-dev);
+
platform_set_drvdata(pdev, data);
plat_ci = ci13xxx_add_device(pdev-dev,
diff --git a/drivers/usb/chipidea/imx_usbmisc.c
b/drivers/usb/chipidea/imx_usbmisc.c
new file mode 100644
index 000..33a8ec0
--- /dev/null
+++ b/drivers/usb/chipidea/imx_usbmisc.c
@@ -0,0 +1,144 @@
+/*
+ * Copyright 2012 Freescale Semiconductor, Inc.
+ *
+ * The code contained herein is licensed under the GNU General Public
+ * License. You may obtain a copy of the GNU General Public License
+ * Version 2 or later at the following locations:
+ *
+ * http://www.opensource.org/licenses/gpl-license.html
+ * http://www.gnu.org/copyleft/gpl.html
+ */
+
+#include linux/module.h
+#include linux/of_platform.h
+#include linux/clk.h
+#include linux/err.h
+#include asm/io.h
+
+struct usbmisc;
+
+struct soc_data {
+ int (*init) (struct usbmisc *usbmisc, int id);
+ void (*exit) (struct usbmisc *usbmisc, int id);
+};
+
+struct usbmisc {
+ struct soc_data *soc_data;
+ void __iomem *base;
+ struct clk *clk;
+
+ int dis_oc:1;
+};
+
+/* Since we only have one usbmisc device at runtime, we global variables */
+static struct usbmisc *usbmisc;
Global variable?
Yes. we
Re: [PATCH 12/12] USB: chipidea: add imx usbmisc support
On 07/13/2012 04:02 PM, Richard Zhao wrote:
On Fri, Jul 13, 2012 at 02:25:45PM +0200, Michael Grzeschik wrote:
On Thu, Jul 12, 2012 at 03:01:52PM +0800, Richard Zhao wrote:
i.MX usb controllers shares non-core registers, which may include
SoC specific controls. We take it as a usbmisc device and usbmisc
driver export functions needed by ci13xxx_imx driver.
So this is SoC and not chipidea specific and should not be sorted into
this subdir.
Yes, but it's usb specific and serve chipidea usb IP.
I don't care where this code is located.
For example, Sabrelite board has bad over-current design, we can
usbmisc to disable over-current detect.
This driver layout is also reflected in:
arch/arm/mach-imx/ehci-imx*.c
It sounds sensible, but I'm not quite sure. I saw drivers are moving
out of there, event it's SoC specific, for example, clk, pinmux. And
the non-core registers might not only be setup onetime on boot, but
be called at runtime by usb driver. For now, it's set once.
You should use these existing mx*_initialize_usb_hw functions to avoid
code duplication
I can not see what duplication it can avoid.
We want to use the chipidea driver for the other imx, too. We already
have existing code for the non-DT case in arch/arm/mach-imx/ehci-imx*.c.
So we need to glue these functions to the DT or duplicate the code,
which is to be avoided.
and add your mx6_initialize_usb_hw routine for mx6 there.
Maybe.
Or at least next to the other imx usb-misc code (wherever that will end up).
This devicetree based glue code in this file can be reused to
call the right mx*_initialize_usb_hw by the compatible.
The glue code makes it more like a normal driver. Doesn't it?
We already have common flags available like i.e. MXC_EHCI_POWER_PINS_ENABLED
which is currently used to disable overcurrent detection.
The flags may be replace with properties in DT bindings.
Yes, write some code that extracts these flags from the DT and then
calls the existing code (for the existing imx platforms).
Signed-off-by: Richard Zhao richard.z...@freescale.com
---
.../devicetree/bindings/usb/imx-usbmisc.txt| 15 ++
drivers/usb/chipidea/Makefile |2 +-
drivers/usb/chipidea/ci13xxx_imx.c |4 +
drivers/usb/chipidea/imx_usbmisc.c | 144
4 files changed, 164 insertions(+), 1 deletion(-)
create mode 100644 Documentation/devicetree/bindings/usb/imx-usbmisc.txt
create mode 100644 drivers/usb/chipidea/imx_usbmisc.c
diff --git a/Documentation/devicetree/bindings/usb/imx-usbmisc.txt
b/Documentation/devicetree/bindings/usb/imx-usbmisc.txt
new file mode 100644
index 000..09f01ca
--- /dev/null
+++ b/Documentation/devicetree/bindings/usb/imx-usbmisc.txt
@@ -0,0 +1,15 @@
+* Freescale i.MX non-core registers
+
+Required properties:
+- compatible: Should be fsl,imx6q-usbmisc
+- reg: Should contain registers location and length
+
+Optional properties:
+- fsl,disable-over-current: disable over current detect
+
+Examples:
+usbmisc@02184800 {
+ compatible = fsl,imx6q-usbmisc;
+ reg = 0x02184800 0x200;
+ fsl,disable-over-current;
+};
diff --git a/drivers/usb/chipidea/Makefile b/drivers/usb/chipidea/Makefile
index 3f56b76..46fc31c 100644
--- a/drivers/usb/chipidea/Makefile
+++ b/drivers/usb/chipidea/Makefile
@@ -17,5 +17,5 @@ ifneq ($(CONFIG_PCI),)
endif
ifneq ($(CONFIG_OF_DEVICE),)
- obj-$(CONFIG_USB_CHIPIDEA) += ci13xxx_imx.o
+ obj-$(CONFIG_USB_CHIPIDEA) += ci13xxx_imx.o imx_usbmisc.o
endif
diff --git a/drivers/usb/chipidea/ci13xxx_imx.c
b/drivers/usb/chipidea/ci13xxx_imx.c
index b3173d8..dd7f3a3 100644
--- a/drivers/usb/chipidea/ci13xxx_imx.c
+++ b/drivers/usb/chipidea/ci13xxx_imx.c
@@ -24,6 +24,8 @@
#include ci.h
+int imx_usbmisc_init(struct device *usbdev);
+
#define pdev_to_phy(pdev) \
((struct usb_phy *)platform_get_drvdata(pdev))
#define ci_to_imx_data(ci) \
@@ -142,6 +144,8 @@ static int __devinit ci13xxx_imx_probe(struct
platform_device *pdev)
dma_set_coherent_mask(pdev-dev, *pdev-dev.dma_mask);
}
+ imx_usbmisc_init(pdev-dev);
+
platform_set_drvdata(pdev, data);
plat_ci = ci13xxx_add_device(pdev-dev,
diff --git a/drivers/usb/chipidea/imx_usbmisc.c
b/drivers/usb/chipidea/imx_usbmisc.c
new file mode 100644
index 000..33a8ec0
--- /dev/null
+++ b/drivers/usb/chipidea/imx_usbmisc.c
@@ -0,0 +1,144 @@
+/*
+ * Copyright 2012 Freescale Semiconductor, Inc.
+ *
+ * The code contained herein is licensed under the GNU General Public
+ * License. You may obtain a copy of the GNU General Public License
+ * Version 2 or later at the following locations:
+ *
+ * http://www.opensource.org/licenses/gpl-license.html
+ * http://www.gnu.org/copyleft/gpl.html
+ */
+
+#include linux/module.h
+#include linux/of_platform.h
+#include linux/clk.h
+#include linux/err.h
+#include asm/io.h
+
+struct
Re: usb3 writes fail with transcend rdf8
On Fri, 13 Jul 2012, Sami Farin wrote: transcend rdf8 reader works in usb2 port, but some SD cards do not work in usb3 port. 3.5.0-g918227bb1 kernel, Asus P8Z68-V PRO GEN3 rev 3402. If someone knows a working (in Linux) SD card reader for usb3, please tell me. cat: write error: Input/output error Please post a usbmon trace showing the error (see Documentation/usb/usbmon.txt). Alan Stern -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH] drivers: usb: otg: add device tree support to otg library
On 06/26/2012 11:37 AM, Kishon Vijay Abraham I wrote:
Adds an API to get usb phy by passing a device node phandle value. Since
now it's possible to obtain phy by phandle, the checks in usb_add_phy
for a valid phy type is removed (now it's just a debug message if a user
tries to add a phy with undefined type).
This also allows to add multiple phys of same type.
Cc: Richard Zhao richard.z...@freescale.com
Cc: Marek Vasut ma...@denx.de
Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
---
Had to remove the restricion on adding multiple phys of same type as now it
would be possible to get the phys by phandle value. However there is no
clear way to get a phy when there are multiple phys of same type without
a phandle (non-dt). So in non-dt environment, adding and getting phy API's
should be used with caution. Currently multiple-phys of the same type
doesn't exist in kernel.
What's the status of this patch?
Marc
drivers/usb/otg/otg.c | 95
---
include/linux/usb/otg.h |8
2 files changed, 89 insertions(+), 14 deletions(-)
diff --git a/drivers/usb/otg/otg.c b/drivers/usb/otg/otg.c
index 0fa4d8c..b36a647 100644
--- a/drivers/usb/otg/otg.c
+++ b/drivers/usb/otg/otg.c
@@ -14,6 +14,7 @@
#include linux/err.h
#include linux/device.h
#include linux/slab.h
+#include linux/of.h
#include linux/usb/otg.h
@@ -35,6 +36,21 @@ static struct usb_phy *__usb_find_phy(struct list_head
*list,
return ERR_PTR(-ENODEV);
}
+static struct usb_phy *__of_usb_find_phy(struct list_head *list,
+ struct device_node *node)
+{
+ struct usb_phy *phy;
+
+ list_for_each_entry(phy, list, head) {
+ if (node != phy-dev-of_node)
+ continue;
+
+ return phy;
+ }
+
+ return ERR_PTR(-ENODEV);
+}
+
static void devm_usb_phy_release(struct device *dev, void *res)
{
struct usb_phy *phy = *(struct usb_phy **)res;
@@ -110,6 +126,65 @@ struct usb_phy *usb_get_phy(enum usb_phy_type type)
EXPORT_SYMBOL(usb_get_phy);
/**
+ * devm_usb_get_phy_by_phandle - find the USB PHY by phandle
+ * @dev - device that requests this phy
+ * @phandle - name of the property holding the phy phandle value
+ *
+ * Returns the phy driver associated with the given phandle value,
+ * after getting a refcount to it; or -ENODEV/NULL if there is no such phy.
+ * While at that, it also associates the device with the phy using
+ * devres. On driver detach, release function is invoked on the devres data,
+ * then, devres data is freed.
+ *
+ * For use by USB host and peripheral drivers.
+ */
+struct usb_phy *devm_usb_get_phy_by_phandle(struct device *dev,
+ const char *phandle)
+{
+ struct usb_phy *phy = NULL, **ptr;
+ unsigned long flags;
+ struct device_node *node;
+
+ if (!dev-of_node) {
+ dev_dbg(dev, device does not have a device node entry\n);
+ return ERR_PTR(-EINVAL);
+ }
+
+ ptr = devres_alloc(devm_usb_phy_release, sizeof(*ptr), GFP_KERNEL);
+ if (!ptr) {
+ dev_dbg(dev, failed to allocate memory for devres\n);
+ return ERR_PTR(-ENOMEM);
+ }
+
+ spin_lock_irqsave(phy_lock, flags);
+
+ node = of_parse_phandle(dev-of_node, phandle, 0);
+ if (!node) {
+ dev_dbg(dev, failed to get %s phandle in %s node\n, phandle,
+ dev-of_node-full_name);
+ goto err0;
+ }
+
+ phy = __of_usb_find_phy(phy_list, node);
+ if (!IS_ERR(phy)) {
+ *ptr = phy;
+ devres_add(dev, ptr);
+ } else {
+ pr_err(unable to find transceiver with phandle %s\n, phandle);
+ devres_free(ptr);
+ goto err0;
+ }
+
+ get_device(phy-dev);
+
+err0:
+ spin_unlock_irqrestore(phy_lock, flags);
+
+ return phy;
+}
+EXPORT_SYMBOL(devm_usb_get_phy_by_phandle);
+
+/**
* devm_usb_put_phy - release the USB PHY
* @dev - device that wants to release this phy
* @phy - the phy returned by devm_usb_get_phy()
@@ -154,32 +229,24 @@ EXPORT_SYMBOL(usb_put_phy);
*/
int usb_add_phy(struct usb_phy *x, enum usb_phy_type type)
{
- int ret = 0;
unsigned long flags;
struct usb_phy *phy;
- if (x x-type != USB_PHY_TYPE_UNDEFINED) {
- dev_err(x-dev, not accepting initialized PHY %s\n, x-label);
- return -EINVAL;
- }
+ if (x x-type != USB_PHY_TYPE_UNDEFINED)
+ dev_dbg(x-dev, add a phy with undefined type %s\n, x-label);
spin_lock_irqsave(phy_lock, flags);
- list_for_each_entry(phy, phy_list, head) {
- if (phy-type == type) {
- ret = -EBUSY;
- dev_err(x-dev, transceiver type %s already exists\n,
+ list_for_each_entry(phy, phy_list, head)
+ if (phy-type == type)
+
Re: [PATCH] USB: ehci-omap: fix compile failure(v1)
On Fri, 13 Jul 2012, Ming Lei wrote:
The omap_ehci_init() is introduced in the below commit:
commit 1a49e2ac9651df7349867a5cf44e2c83de1046af(EHCI:
centralize controller initialization)
the local variable of 'pdev' inside omap_ehci_init() is used
but not defined, so fix the compiling failure.
Cc: Alan Stern st...@rowland.harvard.edu
Signed-off-by: Ming Lei ming@canonical.com
---
drivers/usb/host/ehci-omap.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/usb/host/ehci-omap.c b/drivers/usb/host/ehci-omap.c
index 6133d93..ec21f4a 100644
--- a/drivers/usb/host/ehci-omap.c
+++ b/drivers/usb/host/ehci-omap.c
@@ -115,9 +115,8 @@ static void omap_ehci_erratum_i693(struct ehci_hcd *ehci)
clk_disable(usbhost_p2_fck);
}
-static void omap_ehci_soft_phy_reset(struct platform_device *pdev, u8 port)
+static void omap_ehci_soft_phy_reset(struct usb_hcd *hcd, u8 port)
{
- struct usb_hcd *hcd = dev_get_drvdata(pdev-dev);
unsigned long timeout = jiffies + msecs_to_jiffies(1000);
unsigned reg = 0;
@@ -139,7 +138,8 @@ static void omap_ehci_soft_phy_reset(struct
platform_device *pdev, u8 port)
cpu_relax();
if (time_after(jiffies, timeout)) {
- dev_dbg(pdev-dev, phy reset operation timed out\n);
+ dev_dbg(hcd-self.controller,
+ phy reset operation timed out\n);
break;
}
}
@@ -167,9 +167,9 @@ static int omap_ehci_init(struct usb_hcd *hcd)
/* Soft reset the PHY using PHY reset command over ULPI */
if (pdata-port_mode[0] == OMAP_EHCI_PORT_MODE_PHY)
- omap_ehci_soft_phy_reset(pdev, 0);
+ omap_ehci_soft_phy_reset(hcd, 0);
if (pdata-port_mode[1] == OMAP_EHCI_PORT_MODE_PHY)
- omap_ehci_soft_phy_reset(pdev, 1);
+ omap_ehci_soft_phy_reset(hcd, 1);
/* we know this is the memory we want, no need to ioremap again */
ehci-caps = hcd-regs;
Acked-by: Alan Stern st...@rowland.harvard.edu
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: xhci_hcd: external drive not initialised if already connected during restart or cold boot
On Fri, Jul 13, 2012 at 7:13 AM, Andiry Xu andiry...@amd.com wrote: On 07/13/2012 09:56 AM, Matt Causey wrote: On Thu, Jul 12, 2012 at 12:54 PM, Matt Causeymatt.cau...@gmail.com wrote: On Thu, Jul 12, 2012 at 2:04 AM, Andiry Xuandiry...@amd.com wrote: On 07/12/2012 10:53 AM, Matt Causey wrote: On Wed, Jul 11, 2012 at 11:03 AM, Matt Causeymatt.cau...@gmail.com wrote: On Wed, Jul 11, 2012 at 10:12 AM, Matt Causeymatt.cau...@gmail.com wrote: On Tue, Jul 10, 2012 at 10:55 PM, Andiry Xuandiry...@amd.com wrote: On 07/11/2012 01:56 AM, Matt wrote: Lee Harrislee.r.harris@...writes: Hi Sarah Whenever I restart or coldboot, my external drive (3.5 sata in a USB3 enclosure) is not detected / initialised correctly. fdisk -l does not show the drive at all. I have found that I have to: turn it off ( or disconnect the usb cable) modprobe -r xhci_hcd modprobe xhci_hcd and then turn it on. It is then found and initialised. I'm having this same issue. Does anyone have any ideas? Can you post the bootup dmesg with device connected and CONFIG_USB_DEBUG and CONFIG_USB_XHCI_HCD_DEBUGGING enabled? Thanks, Andiry Some more background...I've got another OS image that runs Linux 2.6.32-33-generic (Ubuntu 10.4 LTS) - and that OS on this hardware works as expected. I've also tested Linux 3.2.22 and it fails in the same way on my system. Upon more digging, what I'm finding is that if I leave my device disconnected from the USB3 port when I boot the system, and the connect the device after the system has booted fully, the device works correctly. The problem occurs when a device is connected to the USB3 port, and I simply boot the system. The dmesg below is from the test system that has the problem. My configuration is also included as an attachment, in case that's helpful. dmesg: ... xhci_hcd :05:00.0: PCI INT A - GSI 19 (level, low) - IRQ 19 xhci_hcd :05:00.0: setting latency timer to 64 xhci_hcd :05:00.0: xHCI Host Controller drivers/usb/core/inode.c: creating file '003' xhci_hcd :05:00.0: new USB bus registered, assigned bus number 3 xhci_hcd :05:00.0: xHCI capability registers at f806: xhci_hcd :05:00.0: CAPLENGTH AND HCIVERSION 0x960020: xhci_hcd :05:00.0: CAPLENGTH: 0x20 xhci_hcd :05:00.0: HCIVERSION: 0x96 xhci_hcd :05:00.0: HCSPARAMS 1: 0x4000840 xhci_hcd :05:00.0: Max device slots: 64 xhci_hcd :05:00.0: Max interrupters: 8 xhci_hcd :05:00.0: Max ports: 4 xhci_hcd :05:00.0: HCSPARAMS 2: 0xcf1 xhci_hcd :05:00.0: Isoc scheduling threshold: 1 xhci_hcd :05:00.0: Maximum allowed segments in event ring: 15 xhci_hcd :05:00.0: HCSPARAMS 3 0x7ff000a: xhci_hcd :05:00.0: Worst case U1 device exit latency: 10 xhci_hcd :05:00.0: Worst case U2 device exit latency: 2047 xhci_hcd :05:00.0: HCC PARAMS 0x270f06d: xhci_hcd :05:00.0: HC generates 64 bit addresses xhci_hcd :05:00.0: FIXME: more HCCPARAMS debugging xhci_hcd :05:00.0: RTSOFF 0x4a0: xhci_hcd :05:00.0: xHCI operational registers at f8060020: xhci_hcd :05:00.0: USBCMD 0x0: xhci_hcd :05:00.0: HC is being stopped xhci_hcd :05:00.0: HC has finished hard reset xhci_hcd :05:00.0: Event Interrupts disabled xhci_hcd :05:00.0: Host System Error Interrupts disabled xhci_hcd :05:00.0: HC has finished light reset xhci_hcd :05:00.0: USBSTS 0x0: xhci_hcd :05:00.0: Event ring is empty xhci_hcd :05:00.0: No Host System Error xhci_hcd :05:00.0: HC is running xhci_hcd :05:00.0: f8060420 port status reg = 0x2a0 xhci_hcd :05:00.0: f8060424 port power reg = 0x0 xhci_hcd :05:00.0: f8060428 port link reg = 0x0 xhci_hcd :05:00.0: f806042c port reserved reg = 0x0 xhci_hcd :05:00.0: f8060430 port status reg = 0xa03 Here the device is connected. xhci_hcd :05:00.0: f8060434 port power reg = 0x0 xhci_hcd :05:00.0: f8060438 port link reg = 0x0 xhci_hcd :05:00.0: f806043c port reserved reg = 0x0 xhci_hcd :05:00.0: f8060440 port status reg = 0x2a0 xhci_hcd :05:00.0: f8060444 port power reg = 0x0 xhci_hcd :05:00.0: f8060448 port link reg = 0x0 xhci_hcd :05:00.0: f806044c port reserved reg = 0x0 xhci_hcd :05:00.0: f8060450 port status reg = 0x2a0 xhci_hcd :05:00.0: f8060454 port power reg = 0x0 xhci_hcd :05:00.0: f8060458 port link reg = 0x0 xhci_hcd :05:00.0: f806045c port reserved reg = 0x0 xhci_hcd :05:00.0: // Halt the HC xhci_hcd :05:00.0: `MEM_WRITE_DWORD(3'b000, 32'hf8060020, 32'h0, 4'hf); xhci_hcd :05:00.0: can't setup This is where the error occurs. The host controller is not halted. xhci_hcd :05:00.0: USB bus 3 deregistered xhci_hcd :05:00.0: PCI INT A disabled xhci_hcd :05:00.0: init :05:00.0 fail, -110 xhci_hcd: probe of :05:00.0 failed with error -110 ... Hello again,
Re: usb3 writes fail with transcend rdf8
On Fri, Jul 13, 2012 at 10:17:14 -0400, Alan Stern wrote: On Fri, 13 Jul 2012, Sami Farin wrote: transcend rdf8 reader works in usb2 port, but some SD cards do not work in usb3 port. 3.5.0-g918227bb1 kernel, Asus P8Z68-V PRO GEN3 rev 3402. If someone knows a working (in Linux) SD card reader for usb3, please tell me. cat: write error: Input/output error Please post a usbmon trace showing the error (see Documentation/usb/usbmon.txt). Alan Stern I uploaded it here, 534 KB https://docs.google.com/open?id=0B_EMXtsx7o56bEtobmJwYi1TaWc I did this: $ head -c1m /dev/urandom ur.bin $ head -c10m /dev/urandom ur2.bin $ head -c100m /dev/urandom ur3.bin $ l total 11280 drwxrwx--- 3 safari safari 4096 2012-07-13 17:55:10.0 +0300 . drwxrwxrwx 20 root root 4096 2012-07-12 21:15:01.517680424 +0300 .. drwxrwx--- 3 safari safari 4096 2012-07-13 13:11:28.0 +0300 dcim -rw-rw 1 safari safari 512 2012-07-13 13:11:28.0 +0300 nikon001.dsc -rw-rw 1 safari safari 10485760 2012-07-13 17:55:01.0 +0300 ur2.bin -rw-rw 1 safari safari 1048576 2012-07-13 17:54:47.0 +0300 ur.bin (then the filesystem got corrupted) [75506.894120] ehci_hcd :00:1d.0: detected XactErr len 0/31 retry 1 [75506.894243] ehci_hcd :00:1d.0: detected XactErr len 0/31 retry 2 [75506.894369] ehci_hcd :00:1d.0: detected XactErr len 0/31 retry 3 [75506.894493] ehci_hcd :00:1d.0: detected XactErr len 0/31 retry 4 [75506.894618] ehci_hcd :00:1d.0: detected XactErr len 0/31 retry 5 [75506.894742] ehci_hcd :00:1d.0: detected XactErr len 0/31 retry 6 [75506.894868] ehci_hcd :00:1d.0: detected XactErr len 0/31 retry 7 [75506.894995] ehci_hcd :00:1d.0: detected XactErr len 0/31 retry 8 [75506.895117] ehci_hcd :00:1d.0: detected XactErr len 0/31 retry 9 [75506.895242] ehci_hcd :00:1d.0: detected XactErr len 0/31 retry 10 [75506.895368] ehci_hcd :00:1d.0: detected XactErr len 0/31 retry 11 [75506.895493] ehci_hcd :00:1d.0: detected XactErr len 0/31 retry 12 [75506.895617] ehci_hcd :00:1d.0: detected XactErr len 0/31 retry 13 [75506.895742] ehci_hcd :00:1d.0: detected XactErr len 0/31 retry 14 [75506.895866] ehci_hcd :00:1d.0: detected XactErr len 0/31 retry 15 [75506.895992] ehci_hcd :00:1d.0: detected XactErr len 0/31 retry 16 [75506.896118] ehci_hcd :00:1d.0: detected XactErr len 0/31 retry 17 [75506.896241] ehci_hcd :00:1d.0: detected XactErr len 0/31 retry 18 [75506.896366] ehci_hcd :00:1d.0: detected XactErr len 0/31 retry 19 [75506.896491] ehci_hcd :00:1d.0: detected XactErr len 0/31 retry 20 [75506.896616] ehci_hcd :00:1d.0: detected XactErr len 0/31 retry 21 [75506.896741] ehci_hcd :00:1d.0: detected XactErr len 0/31 retry 22 [75506.896866] ehci_hcd :00:1d.0: detected XactErr len 0/31 retry 23 [75506.896991] ehci_hcd :00:1d.0: detected XactErr len 0/31 retry 24 [75506.897117] ehci_hcd :00:1d.0: detected XactErr len 0/31 retry 25 [75506.897241] ehci_hcd :00:1d.0: detected XactErr len 0/31 retry 26 [75506.897365] ehci_hcd :00:1d.0: detected XactErr len 0/31 retry 27 [75506.897491] ehci_hcd :00:1d.0: detected XactErr len 0/31 retry 28 [75506.897615] ehci_hcd :00:1d.0: detected XactErr len 0/31 retry 29 [75506.897740] ehci_hcd :00:1d.0: detected XactErr len 0/31 retry 30 [75506.897865] ehci_hcd :00:1d.0: detected XactErr len 0/31 retry 31 [75506.897991] ehci_hcd :00:1d.0: devpath 1.5.3 ep2out 3strikes [75506.909241] hub 2-1.5:1.0: logical disconnect on port 3 [75506.909377] hub 2-1.5:1.0: state 7 ports 4 chg 0008 evt [75506.909609] hub 2-1.5:1.0: port 3, status 0100, change 0001, 12 Mb/s [75506.909612] usb 2-1.5.3: USB disconnect, device number 12 [75506.909614] usb 2-1.5.3: unregistering device [75506.909615] usb 2-1.5.3: unregistering interface 2-1.5.3:1.0 [75506.925548] usb 2-1.5.3: usb_disable_device nuking all URBs [75507.029888] hub 2-1.5:1.0: debounce: port 3: total 100ms stable 100ms status 0x100 [75548.741551] hub 4-0:1.0: state 7 ports 2 chg evt 0004 [75548.741577] hub 4-0:1.0: port 2, status 0203, change 0001, 5.0 Gb/s [75548.845356] hub 4-0:1.0: debounce: port 2: total 100ms stable 100ms status 0x203 [75548.950897] usb 4-2: new SuperSpeed USB device number 9 using xhci_hcd [75548.962611] usb 4-2: Parent hub missing LPM exit latency info. Power management will be impacted. [75548.963431] usb 4-2: skipped 1 descriptor after endpoint [75548.963435] usb 4-2: skipped 1 descriptor after endpoint [75548.963723] usb 4-2: default language 0x0409 [75548.964704] usb 4-2: udev 9, busnum 4, minor = 392 [75548.964708] usb 4-2: New USB device found, idVendor=8564, idProduct=4000 [75548.964711] usb 4-2: New USB device strings: Mfr=3, Product=4, SerialNumber=5 [75548.964714] usb 4-2: Product: GL3220 [75548.964716] usb 4-2: Manufacturer: Genesys [75548.964719] usb 4-2: SerialNumber: 01272 [75548.964890] usb 4-2:
Re: xhci_hcd: external drive not initialised if already connected during restart or cold boot
On Fri, Jul 13, 2012 at 2:41 PM, Matt Causey matt.cau...@gmail.com wrote: On Fri, Jul 13, 2012 at 7:13 AM, Andiry Xu andiry...@amd.com wrote: On 07/13/2012 09:56 AM, Matt Causey wrote: On Thu, Jul 12, 2012 at 12:54 PM, Matt Causeymatt.cau...@gmail.com wrote: On Thu, Jul 12, 2012 at 2:04 AM, Andiry Xuandiry...@amd.com wrote: On 07/12/2012 10:53 AM, Matt Causey wrote: On Wed, Jul 11, 2012 at 11:03 AM, Matt Causeymatt.cau...@gmail.com wrote: On Wed, Jul 11, 2012 at 10:12 AM, Matt Causeymatt.cau...@gmail.com wrote: On Tue, Jul 10, 2012 at 10:55 PM, Andiry Xuandiry...@amd.com wrote: On 07/11/2012 01:56 AM, Matt wrote: Lee Harrislee.r.harris@...writes: Hi Sarah Whenever I restart or coldboot, my external drive (3.5 sata in a USB3 enclosure) is not detected / initialised correctly. fdisk -l does not show the drive at all. I have found that I have to: turn it off ( or disconnect the usb cable) modprobe -r xhci_hcd modprobe xhci_hcd and then turn it on. It is then found and initialised. I'm having this same issue. Does anyone have any ideas? Can you post the bootup dmesg with device connected and CONFIG_USB_DEBUG and CONFIG_USB_XHCI_HCD_DEBUGGING enabled? Thanks, Andiry Some more background...I've got another OS image that runs Linux 2.6.32-33-generic (Ubuntu 10.4 LTS) - and that OS on this hardware works as expected. I've also tested Linux 3.2.22 and it fails in the same way on my system. Upon more digging, what I'm finding is that if I leave my device disconnected from the USB3 port when I boot the system, and the connect the device after the system has booted fully, the device works correctly. The problem occurs when a device is connected to the USB3 port, and I simply boot the system. The dmesg below is from the test system that has the problem. My configuration is also included as an attachment, in case that's helpful. dmesg: ... xhci_hcd :05:00.0: PCI INT A - GSI 19 (level, low) - IRQ 19 xhci_hcd :05:00.0: setting latency timer to 64 xhci_hcd :05:00.0: xHCI Host Controller drivers/usb/core/inode.c: creating file '003' xhci_hcd :05:00.0: new USB bus registered, assigned bus number 3 xhci_hcd :05:00.0: xHCI capability registers at f806: xhci_hcd :05:00.0: CAPLENGTH AND HCIVERSION 0x960020: xhci_hcd :05:00.0: CAPLENGTH: 0x20 xhci_hcd :05:00.0: HCIVERSION: 0x96 xhci_hcd :05:00.0: HCSPARAMS 1: 0x4000840 xhci_hcd :05:00.0: Max device slots: 64 xhci_hcd :05:00.0: Max interrupters: 8 xhci_hcd :05:00.0: Max ports: 4 xhci_hcd :05:00.0: HCSPARAMS 2: 0xcf1 xhci_hcd :05:00.0: Isoc scheduling threshold: 1 xhci_hcd :05:00.0: Maximum allowed segments in event ring: 15 xhci_hcd :05:00.0: HCSPARAMS 3 0x7ff000a: xhci_hcd :05:00.0: Worst case U1 device exit latency: 10 xhci_hcd :05:00.0: Worst case U2 device exit latency: 2047 xhci_hcd :05:00.0: HCC PARAMS 0x270f06d: xhci_hcd :05:00.0: HC generates 64 bit addresses xhci_hcd :05:00.0: FIXME: more HCCPARAMS debugging xhci_hcd :05:00.0: RTSOFF 0x4a0: xhci_hcd :05:00.0: xHCI operational registers at f8060020: xhci_hcd :05:00.0: USBCMD 0x0: xhci_hcd :05:00.0: HC is being stopped xhci_hcd :05:00.0: HC has finished hard reset xhci_hcd :05:00.0: Event Interrupts disabled xhci_hcd :05:00.0: Host System Error Interrupts disabled xhci_hcd :05:00.0: HC has finished light reset xhci_hcd :05:00.0: USBSTS 0x0: xhci_hcd :05:00.0: Event ring is empty xhci_hcd :05:00.0: No Host System Error xhci_hcd :05:00.0: HC is running xhci_hcd :05:00.0: f8060420 port status reg = 0x2a0 xhci_hcd :05:00.0: f8060424 port power reg = 0x0 xhci_hcd :05:00.0: f8060428 port link reg = 0x0 xhci_hcd :05:00.0: f806042c port reserved reg = 0x0 xhci_hcd :05:00.0: f8060430 port status reg = 0xa03 Here the device is connected. xhci_hcd :05:00.0: f8060434 port power reg = 0x0 xhci_hcd :05:00.0: f8060438 port link reg = 0x0 xhci_hcd :05:00.0: f806043c port reserved reg = 0x0 xhci_hcd :05:00.0: f8060440 port status reg = 0x2a0 xhci_hcd :05:00.0: f8060444 port power reg = 0x0 xhci_hcd :05:00.0: f8060448 port link reg = 0x0 xhci_hcd :05:00.0: f806044c port reserved reg = 0x0 xhci_hcd :05:00.0: f8060450 port status reg = 0x2a0 xhci_hcd :05:00.0: f8060454 port power reg = 0x0 xhci_hcd :05:00.0: f8060458 port link reg = 0x0 xhci_hcd :05:00.0: f806045c port reserved reg = 0x0 xhci_hcd :05:00.0: // Halt the HC xhci_hcd :05:00.0: `MEM_WRITE_DWORD(3'b000, 32'hf8060020, 32'h0, 4'hf); xhci_hcd :05:00.0: can't setup This is where the error occurs. The host controller is not halted. xhci_hcd :05:00.0: USB bus 3 deregistered xhci_hcd :05:00.0: PCI INT A disabled xhci_hcd :05:00.0: init :05:00.0 fail, -110 xhci_hcd:
Re: usb3 writes fail with transcend rdf8
On Fri, 13 Jul 2012, Sami Farin wrote: On Fri, Jul 13, 2012 at 10:17:14 -0400, Alan Stern wrote: On Fri, 13 Jul 2012, Sami Farin wrote: transcend rdf8 reader works in usb2 port, but some SD cards do not work in usb3 port. 3.5.0-g918227bb1 kernel, Asus P8Z68-V PRO GEN3 rev 3402. If someone knows a working (in Linux) SD card reader for usb3, please tell me. cat: write error: Input/output error Please post a usbmon trace showing the error (see Documentation/usb/usbmon.txt). Alan Stern I uploaded it here, 534 KB https://docs.google.com/open?id=0B_EMXtsx7o56bEtobmJwYi1TaWc The card reader has a couple of bugs in its firmware. It's odd that the errors occur only when running at SuperSpeed. You'd think the firmware would behave the same way regardless of the speed. Anyway, you can work around one of the bugs by specifying a quirk parameter for usb-storage: modprobe usb-storage quirks=8564:4000:m To fix the other bug will require adding a blacklist entry for the card reader. First let's see if the quirk alone will get it working. 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: g_serial and cdc_acm communications
HI, One thing I observed is that set_config() from composite.c calls acm_set_alt() in f_acm.c. Here in acm_set_alt() for intf==acm-data_id it always goes to else part. So rather than resetting it activates new configuration and thus it gets new port number everytime. I guess once the device is connected to Host then for future unplug/plug or even SET_CONFIGURATION requests it should just do reset so calling gserial_disconnect() and then gserial_connect(). Correct me if I am wrong. Regards, Dipen Patel -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: usb3 writes fail with transcend rdf8
On Fri, Jul 13, 2012 at 12:02:34 -0400, Alan Stern wrote: On Fri, 13 Jul 2012, Sami Farin wrote: On Fri, Jul 13, 2012 at 10:17:14 -0400, Alan Stern wrote: On Fri, 13 Jul 2012, Sami Farin wrote: transcend rdf8 reader works in usb2 port, but some SD cards do not work in usb3 port. 3.5.0-g918227bb1 kernel, Asus P8Z68-V PRO GEN3 rev 3402. If someone knows a working (in Linux) SD card reader for usb3, please tell me. cat: write error: Input/output error Please post a usbmon trace showing the error (see Documentation/usb/usbmon.txt). Alan Stern I uploaded it here, 534 KB https://docs.google.com/open?id=0B_EMXtsx7o56bEtobmJwYi1TaWc The card reader has a couple of bugs in its firmware. It's odd that the errors occur only when running at SuperSpeed. You'd think the firmware would behave the same way regardless of the speed. Anyway, you can work around one of the bugs by specifying a quirk parameter for usb-storage: modprobe usb-storage quirks=8564:4000:m To fix the other bug will require adding a blacklist entry for the card reader. First let's see if the quirk alone will get it working. Alan Stern Unfortunately it still does not work. I first re-ran mkfs.vfat when connected to usb2 port and then tried to write 512 MB with usb3.. usbmon with quirk enabled https://docs.google.com/file/d/0B_EMXtsx7o56bEtobmJwYi1TaWc/edit [81577.454868] hub 4-0:1.0: state 7 ports 2 chg evt 0004 [81577.454895] hub 4-0:1.0: port 2, status 0203, change 0001, 5.0 Gb/s [81577.558207] hub 4-0:1.0: debounce: port 2: total 100ms stable 100ms status 0x203 [81577.663743] usb 4-2: new SuperSpeed USB device number 14 using xhci_hcd [81577.675454] usb 4-2: Parent hub missing LPM exit latency info. Power management will be impacted. [81577.676274] usb 4-2: skipped 1 descriptor after endpoint [81577.676278] usb 4-2: skipped 1 descriptor after endpoint [81577.676550] usb 4-2: default language 0x0409 [81577.677574] usb 4-2: udev 14, busnum 4, minor = 397 [81577.677577] usb 4-2: New USB device found, idVendor=8564, idProduct=4000 [81577.677581] usb 4-2: New USB device strings: Mfr=3, Product=4, SerialNumber=5 [81577.677584] usb 4-2: Product: GL3220 [81577.677586] usb 4-2: Manufacturer: Genesys [81577.677589] usb 4-2: SerialNumber: 01272 [81577.677757] usb 4-2: usb_probe_device [81577.677760] usb 4-2: configuration #1 chosen from 1 choice [81577.678391] usb 4-2: Successful Endpoint Configure command [81577.678649] usb 4-2: adding 4-2:1.0 (config #1, interface 0) [81577.678735] usb-storage 4-2:1.0: usb_probe_interface [81577.678739] usb-storage 4-2:1.0: usb_probe_interface - got id [81577.678767] usb-storage 4-2:1.0: Quirks match for vid 8564 pid 4000: 400 [81577.678785] scsi24 : usb-storage 4-2:1.0 [81578.679882] scsi 24:0:0:0: Direct-Access Generic STORAGE DEVICE TS07 PQ: 0 ANSI: 0 [81578.680364] scsi 24:0:0:1: Direct-Access Generic STORAGE DEVICE TS07 PQ: 0 ANSI: 0 [81578.680806] scsi 24:0:0:2: Direct-Access Generic STORAGE DEVICE TS07 PQ: 0 ANSI: 0 [81578.681731] sd 24:0:0:0: Attached scsi generic sg4 type 0 [81578.682568] sd 24:0:0:1: Attached scsi generic sg5 type 0 [81578.683254] sd 24:0:0:2: Attached scsi generic sg6 type 0 [81579.028286] sd 24:0:0:1: [sdg] 15759360 512-byte logical blocks: (8.06 GB/7.51 GiB) [81579.029333] sd 24:0:0:1: [sdg] Write Protect is off [81579.029335] sd 24:0:0:1: [sdg] Mode Sense: 0b 00 00 08 [81579.029557] sd 24:0:0:0: [sdd] Attached SCSI removable disk [81579.029781] sd 24:0:0:2: [sdh] Attached SCSI removable disk [81579.030418] sd 24:0:0:1: [sdg] No Caching mode page present [81579.030419] sd 24:0:0:1: [sdg] Assuming drive cache: write through [81579.036337] sd 24:0:0:1: [sdg] No Caching mode page present [81579.036340] sd 24:0:0:1: [sdg] Assuming drive cache: write through [81579.037357] sdg: sdg1 [81579.041152] sd 24:0:0:1: [sdg] No Caching mode page present [81579.041155] sd 24:0:0:1: [sdg] Assuming drive cache: write through [81579.041157] sd 24:0:0:1: [sdg] Attached SCSI removable disk [81691.504815] usb 4-2: reset SuperSpeed USB device number 14 using xhci_hcd [81691.516980] usb 4-2: Parent hub missing LPM exit latency info. Power management will be impacted. [81691.517881] xhci_hcd :03:00.0: xHCI xhci_drop_endpoint called with disabled ep 880365464400 [81691.517883] xhci_hcd :03:00.0: xHCI xhci_drop_endpoint called with disabled ep 880365464440 [81691.518512] usb 4-2: Successful Endpoint Configure command [81691.866349] sd 24:0:0:1: [sdg] Media Changed [81691.866354] sd 24:0:0:1: [sdg] [81691.866356] Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE [81691.866359] sd 24:0:0:1: [sdg] [81691.866360] Sense Key : Unit Attention [current] [81691.866365] sd 24:0:0:1: [sdg] [81691.866368] Add. Sense: Not ready to ready change, medium may have changed [81691.866378] sd 24:0:0:1: [sdg] CDB: [81691.866379] Write(10): 2a 00 00 00 5e 60 00 00
Re: usb3 writes fail with transcend rdf8
On Fri, 13 Jul 2012, Sami Farin wrote: The card reader has a couple of bugs in its firmware. It's odd that the errors occur only when running at SuperSpeed. You'd think the firmware would behave the same way regardless of the speed. Anyway, you can work around one of the bugs by specifying a quirk parameter for usb-storage: modprobe usb-storage quirks=8564:4000:m To fix the other bug will require adding a blacklist entry for the card reader. First let's see if the quirk alone will get it working. Alan Stern Unfortunately it still does not work. I first re-ran mkfs.vfat when connected to usb2 port and then tried to write 512 MB with usb3.. usbmon with quirk enabled https://docs.google.com/file/d/0B_EMXtsx7o56bEtobmJwYi1TaWc/edit That's really weird. Your log confirms that the quirk was recognized: [81577.678735] usb-storage 4-2:1.0: usb_probe_interface [81577.678739] usb-storage 4-2:1.0: usb_probe_interface - got id [81577.678767] usb-storage 4-2:1.0: Quirks match for vid 8564 pid 4000: 400 And yet the usbmon log shows that the quirk didn't take effect. That's why the problem occurred again. After the device is plugged in, what shows up in the /sys/block/sdg/queue/max_hw_sectors_kb file? Without the quirk it should contain 120; with the quirk it should contain 32. The effect of the quirk is to reduce the maximum size allowed in a single data transfer from 120 KB to 32 KB. The usbmon trace shows that your card reader got an error when it was asked to write a 120-KB buffer. Reducing the transfer buffer size should eliminate the errors -- but that the latest usbmon trace still shows a 120-KB transfer. I tried doing an equivalent test on my system (using reads, not writes) and it worked fine. I got 32-KB transfers instead of 120-KB transfers. I have no idea why it didn't work on your system. Maybe you should do some tests with reads instead of writes. A simple test would be: dd if=/dev/sdg of=/dev/null bs=1M count=1 Let's compare the usbmon traces for that command with and without the quirk present. 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: suspending USB keyboards
[CC-ing the public mailing list and a few interested parties]
On Wed, 11 Jul 2012, Len Brown wrote:
Hello Alan,
I'm struggling with a system that consumes 20% more power when a USB keyboard
is plugged in.
Can you help me?
thanks,
-Len
I find that even if no keyboard is plugged in, that I have to issue this
command to drop power to 72 Watts from 88 Watts
# echo auto /sys/bus/usb/devices/2-1.4/power/control
I find that if I have a physical keyboard connected,
it is impossible to save this 16 Watts. (at least with
the 3 keyboards that I've tried). Unplugging it is the only
way to save that power.
I can't tell exactly what the problem is, but testing has revealed
several bugs in the usbhid driver related to autosuspend. The patch
below should fix them. (The biggest bug was that the gets and puts
weren't balanced, but there were others.)
Note that you'll still have to use that echo auto ... command before
anything will happen, because autosuspend is disabled by default for
most USB devices (including keyboards).
Also, you'll have to make sure that either all the keyboard LEDs are
off or else you modprobe usbhid with the ignoreled=1 option.
Jiri and Oliver: What do you think of the patch? I can break it up
into several pieces, each making a single change.
Alan Stern
Index: usb-3.5/drivers/hid/usbhid/hid-core.c
===
--- usb-3.5.orig/drivers/hid/usbhid/hid-core.c
+++ usb-3.5/drivers/hid/usbhid/hid-core.c
@@ -213,9 +213,20 @@ static int usbhid_restart_out_queue(stru
if ((kicked = (usbhid-outhead != usbhid-outtail))) {
hid_dbg(hid, Kicking head %d tail %d, usbhid-outhead,
usbhid-outtail);
+ /* Try to wake up from autosuspend... */
r = usb_autopm_get_interface_async(usbhid-intf);
if (r 0)
return r;
+
+ /*
+* If still suspended, don't submit. Submission will
+* occur if/when resume drains the queue.
+*/
+ if (test_bit(HID_REPORTED_IDLE, usbhid-iofl)) {
+ usb_autopm_put_interface_no_suspend(usbhid-intf);
+ return r;
+ }
+
/* Asynchronously flush queue. */
set_bit(HID_OUT_RUNNING, usbhid-iofl);
if (hid_submit_out(hid)) {
@@ -240,9 +251,20 @@ static int usbhid_restart_ctrl_queue(str
if ((kicked = (usbhid-ctrlhead != usbhid-ctrltail))) {
hid_dbg(hid, Kicking head %d tail %d, usbhid-ctrlhead,
usbhid-ctrltail);
+ /* Try to wake up from autosuspend... */
r = usb_autopm_get_interface_async(usbhid-intf);
if (r 0)
return r;
+
+ /*
+* If still suspended, don't submit. Submission will
+* occur if/when resume drains the queue.
+*/
+ if (test_bit(HID_REPORTED_IDLE, usbhid-iofl)) {
+ usb_autopm_put_interface_no_suspend(usbhid-intf);
+ return r;
+ }
+
/* Asynchronously flush queue. */
set_bit(HID_CTRL_RUNNING, usbhid-iofl);
if (hid_submit_ctrl(hid)) {
@@ -331,9 +353,12 @@ static int hid_submit_out(struct hid_dev
usbhid-urbout-transfer_buffer_length = ((report-size - 1) 3) +
1 + (report-id 0);
usbhid-urbout-dev = hid_to_usb_dev(hid);
- memcpy(usbhid-outbuf, raw_report,
- usbhid-urbout-transfer_buffer_length);
- kfree(raw_report);
+ if (raw_report) {
+ memcpy(usbhid-outbuf, raw_report,
+ usbhid-urbout-transfer_buffer_length);
+ kfree(raw_report);
+ usbhid-out[usbhid-outtail].raw_report = NULL;
+ }
dbg_hid(submitting out urb\n);
@@ -362,8 +387,11 @@ static int hid_submit_ctrl(struct hid_de
if (dir == USB_DIR_OUT) {
usbhid-urbctrl-pipe = usb_sndctrlpipe(hid_to_usb_dev(hid), 0);
usbhid-urbctrl-transfer_buffer_length = len;
- memcpy(usbhid-ctrlbuf, raw_report, len);
- kfree(raw_report);
+ if (raw_report) {
+ memcpy(usbhid-ctrlbuf, raw_report, len);
+ kfree(raw_report);
+ usbhid-ctrl[usbhid-ctrltail].raw_report = NULL;
+ }
} else {
int maxpacket, padlen;
@@ -407,16 +435,6 @@ static int hid_submit_ctrl(struct hid_de
* Output interrupt completion handler.
*/
-static int irq_out_pump_restart(struct hid_device *hid)
-{
- struct usbhid_device *usbhid = hid-driver_data;
-
- if (usbhid-outhead != usbhid-outtail)
- return hid_submit_out(hid);
- else
- return -1;
Re: usb3 writes fail with transcend rdf8
On Fri, Jul 13, 2012 at 16:39:13 -0400, Alan Stern wrote: On Fri, 13 Jul 2012, Sami Farin wrote: The card reader has a couple of bugs in its firmware. It's odd that the errors occur only when running at SuperSpeed. You'd think the firmware would behave the same way regardless of the speed. Anyway, you can work around one of the bugs by specifying a quirk parameter for usb-storage: modprobe usb-storage quirks=8564:4000:m To fix the other bug will require adding a blacklist entry for the card reader. First let's see if the quirk alone will get it working. Alan Stern Unfortunately it still does not work. I first re-ran mkfs.vfat when connected to usb2 port and then tried to write 512 MB with usb3.. usbmon with quirk enabled https://docs.google.com/file/d/0B_EMXtsx7o56bEtobmJwYi1TaWc/edit That's really weird. Your log confirms that the quirk was recognized: [81577.678735] usb-storage 4-2:1.0: usb_probe_interface [81577.678739] usb-storage 4-2:1.0: usb_probe_interface - got id [81577.678767] usb-storage 4-2:1.0: Quirks match for vid 8564 pid 4000: 400 And yet the usbmon log shows that the quirk didn't take effect. That's why the problem occurred again. After the device is plugged in, what shows up in the /sys/block/sdg/queue/max_hw_sectors_kb file? Without the quirk it should contain 120; with the quirk it should contain 32. This is what happens.. 120 and 32. The effect of the quirk is to reduce the maximum size allowed in a single data transfer from 120 KB to 32 KB. The usbmon trace shows that your card reader got an error when it was asked to write a 120-KB buffer. Reducing the transfer buffer size should eliminate the errors -- but that the latest usbmon trace still shows a 120-KB transfer. I tried doing an equivalent test on my system (using reads, not writes) and it worked fine. I got 32-KB transfers instead of 120-KB transfers. I have no idea why it didn't work on your system. Maybe you should do some tests with reads instead of writes. A simple test would be: dd if=/dev/sdg of=/dev/null bs=1M count=1 Let's compare the usbmon traces for that command with and without the quirk present. it worked with 1M with and without quirks, but with 300M it failed without quirks, OK with quirks (36 MB/s, though it was advertized 85 MB/s). 4[97245.555816] usb 4-2: Device not responding to set address. 3[97250.149959] usb 4-2: device not accepting address 18, error -71 4[97258.840645] usb 4-2: Device not responding to set address. 4[97263.336556] usb 4-2: Device not responding to set address. 3[97267.931175] usb 4-2: device not accepting address 18, error -71 4[97276.621870] usb 4-2: Device not responding to set address. 4[97285.553439] usb 4-2: Device not responding to set address. 4[97290.050208] usb 4-2: Device not responding to set address. 3[97294.643963] usb 4-2: device not accepting address 20, error -71 quirks off, 1M dd read test: https://docs.google.com/file/d/0B_EMXtsx7o56Y3dtME93ZGdELUU/edit quirks on, 1M dd read test: https://docs.google.com/file/d/0B_EMXtsx7o56clFYSUxHZ2hjMUk/edit Alan Stern -- Do what you love because life is too short for anything else. -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: usb sound issue ...
On Fri, Jul 13, 2012 at 03:19:58PM +0800, Andiry Xu wrote: On 07/13/2012 03:19 AM, Dr. Ing. Dieter Jurzitza wrote: Hi Andiry, hi Sarah, Andiry is right, the test patch was applied. Please advise what I can do on top of this ... Thank you for all your time and all your efforts, take care Sarah, What do you suggest? What should we do with a interrupted config endpoint command? Shall we mark the endpoint so later we know the endpoint is disabled because a config ep command has already been operated to drop it? Ideally we would use the command cancellation patches from Elric Fu to cancel the command. Either the hardware will have finished the command, or not, and I guess we would need to mark the endpoints as disabled. Let me think about this more next week. I'm on vacation until Tuesday. 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
