Re: xhci inc_deq question
hi Sebastian 2012/8/18 Sebastian Andrzej Siewior sebast...@breakpoint.cc: On Wed, Aug 08, 2012 at 08:55:37PM +0800, loody wrote: when I study inc_deq in xhci-ring.c, why we need to announce and assigned value to addr it seems useless. Unless Sarah plans to use addr for debug output you can remove this addr and the one in the function below. Andiry Xu has told me this usage before. Thanks for your help, -- Regards, -- 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: [BUG] - USB3 bluetooth device not working properly?
On 08/18/2012 12:33 PM, Andiry Xu wrote: From the dmesg, it looks like your xhci host controller is in a mess. It either does not respond to the address device command, or just return an invalid response. And worse, the memory is leaked. I think the host controller is not initialized properly in this case. Have you tried any other USB3.0 controllers? I would gladly try different controllers but I don't have any other. I found couple of bugs on Ubuntu Launchpad system with exact same error messages from xhci but related to different controlers. Do you have any idea how to solve this issue? -- Best regards, Miroslav -- 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: [BUG] - USB3 bluetooth device not working properly?
On Sat, Aug 18, 2012 at 8:16 PM, Miroslav Sabljic miroslav.sabl...@avl.com wrote: On 08/18/2012 12:33 PM, Andiry Xu wrote: From the dmesg, it looks like your xhci host controller is in a mess. It either does not respond to the address device command, or just return an invalid response. And worse, the memory is leaked. I think the host controller is not initialized properly in this case. Have you tried any other USB3.0 controllers? I would gladly try different controllers but I don't have any other. I found couple of bugs on Ubuntu Launchpad system with exact same error messages from xhci but related to different controlers. Do you have any idea how to solve this issue? I don't have a Intel Panther Point platform. Can you post the dmesg with CONFIG_USB_XHCI_HCD_DEBUGGING? Thanks, Andiry -- Best regards, Miroslav -- 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 host: fix spelling of provides in Kconfig
Signed-off-by: Peter Meerwald pme...@pmeerw.net --- drivers/usb/host/Kconfig |4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/usb/host/Kconfig b/drivers/usb/host/Kconfig index 075d2ec..7cac2e8 100644 --- a/drivers/usb/host/Kconfig +++ b/drivers/usb/host/Kconfig @@ -418,7 +418,7 @@ config USB_OHCI_HCD_PLATFORM default n ---help--- Adds an OHCI host driver for a generic platform device, which - provieds a memory space and an irq. + provides a memory space and an irq. If unsure, say N. @@ -428,7 +428,7 @@ config USB_EHCI_HCD_PLATFORM default n ---help--- Adds an EHCI host driver for a generic platform device, which - provieds a memory space and an irq. + provides a memory space and an irq. If unsure, say N. -- 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: add ZTE EV_DO to a proper driver
on Sat, 18 Aug 2012 03:02:13 +0300, Greg KH gre...@linuxfoundation.org wrote: On Thu, Jul 26, 2012 at 05:51:59PM +0300, nirinA raseliarison wrote: hi Greg, Le Thu, 26 Jul 2012 01:04:08 +0300, Greg KH gre...@linuxfoundation.org a écrit: On Wed, Jul 25, 2012 at 12:51:34PM -0700, nirinA raseliarison wrote: hello there, i have an usb modem zte ev-do that i used with kernel from 2.6.29 up to 3.5. since 3.5, i got the following message: [77496.664090] usb 5-2: udev 10, busnum 5, minor = 521 [77496.664097] usb 5-2: New USB device found, idVendor=19d2, idProduct= [77496.664102] usb 5-2: New USB device strings: Mfr=1, Product=2, SerialNumber=0 [77496.664107] usb 5-2: Product: ZTE CDMA Tech [77496.664112] usb 5-2: Manufacturer: ZTE, Incorporated [77496.664226] usb 5-2: usb_probe_device [77496.664232] usb 5-2: configuration #1 chosen from 1 choice [77496.667119] usb 5-2: adding 5-2:1.0 (config #1, interface 0) [77496.670161] usbserial_generic 5-2:1.0: usb_probe_interface [77496.670169] usbserial_generic 5-2:1.0: usb_probe_interface - got id [77496.670177] usbserial_generic 5-2:1.0: The generic usb-serial driver is only for testing and one-off prototypes. [77496.670182] usbserial_generic 5-2:1.0: Tell linux-usb@vger.kernel.org to add your device to a proper driver. [77496.670186] usbserial_generic 5-2:1.0: generic converter detected [77496.670276] usb 5-2: generic converter now attached to ttyUSB0 i would be nice to have a driver for this device in the kernel. the device is shipped with sources to build its modules. if i understand correctly thet are released under GPL, so i attached them below. this is portion of Makefile i used: obj-m := ztemt.o ztemt-objs := usb-serial.o bus.o generic.o ezusb.o zte_ev.o Ick, that's not really the proper way to support this device, but I can take the file below and write a real driver for it. Can you test a patch if I create it? yes, of course, i can test it. Very sorry for the delay, but I think I have a first cut at this. Can you try the patch attached to this mail, it was made against the 3.6-rc2 kernel, but should apply cleanly to the 3.5 kernel and probably older ones as well. Can you enable this driver and let me know if it works properly for you or not? i've patched against 3.5.0 and it worked like a charm. below portion of dmesg when the device was plugged, did a few minutes of connexion and then unplugged. [ 1212.303779] hub 1-0:1.0: state 7 ports 8 chg evt 0100 [ 1212.303797] ehci_hcd :00:1d.7: GetStatus port:8 status 001803 0 ACK POWER sig=j CSC CONNECT [ 1212.303806] hub 1-0:1.0: port 8, status 0501, change 0001, 480 Mb/s [ 1212.407040] hub 1-0:1.0: debounce: port 8: total 100ms stable 100ms status 0x501 [ 1212.458311] ehci_hcd :00:1d.7: port 8 full speed -- companion [ 1212.458318] ehci_hcd :00:1d.7: GetStatus port:8 status 003801 0 ACK POWER OWNER sig=j CONNECT [ 1212.458323] hub 1-0:1.0: port 8 not reset yet, waiting 50ms [ 1212.509041] ehci_hcd :00:1d.7: GetStatus port:8 status 003002 0 ACK POWER OWNER sig=se0 CSC [ 1212.509071] hub 1-0:1.0: state 7 ports 8 chg evt 0100 [ 1212.509081] ehci_hcd :00:1d.7: GetStatus port:8 status 003002 0 ACK POWER OWNER sig=se0 CSC [ 1212.509090] hub 1-0:1.0: port 8, status 0100, change 0001, 12 Mb/s [ 1212.613064] hub 1-0:1.0: debounce: port 8: total 100ms stable 100ms status 0x100 [ 1212.704045] usb usb5: wakeup_rh (auto-start) [ 1212.704074] hub 5-0:1.0: state 7 ports 2 chg evt 0004 [ 1212.704086] uhci_hcd :00:1d.3: port 2 portsc 0093,00 [ 1212.704094] hub 5-0:1.0: port 2, status 0101, change 0001, 12 Mb/s [ 1212.808044] hub 5-0:1.0: debounce: port 2: total 100ms stable 100ms status 0x101 [ 1212.859068] hub 5-0:1.0: port 2 not reset yet, waiting 50ms [ 1212.961053] usb 5-2: new full-speed USB device number 2 using uhci_hcd [ 1212.965069] usb 5-2: uhci_result_common: failed with status 44 [ 1212.969066] usb 5-2: uhci_result_common: failed with status 44 [ 1212.973068] usb 5-2: uhci_result_common: failed with status 44 [ 1213.075282] usb 5-2: device descriptor read/64, error -71 [ 1213.180066] usb 5-2: uhci_result_common: failed with status 44 [ 1213.184063] usb 5-2: uhci_result_common: failed with status 44 [ 1213.188070] usb 5-2: uhci_result_common: failed with status 44 [ 1213.290046] usb 5-2: device descriptor read/64, error -71 [ 1213.442073] hub 5-0:1.0: port 2 not reset yet, waiting 50ms [ 1213.544028] usb 5-2: new full-speed USB device number 3 using uhci_hcd [ 1213.547067] usb 5-2: uhci_result_common: failed with status 44 [ 1213.551070] usb 5-2: uhci_result_common: failed with status 44 [ 1213.555067] usb 5-2: uhci_result_common: failed with status 44 [ 1213.657030] usb 5-2: device descriptor read/64, error -71 [ 1213.762070] usb 5-2: uhci_result_common: failed with status 44 [
[PATCH] usb musb: fix spelling of families in Kconfig
Signed-off-by: Peter Meerwald pme...@pmeerw.net --- drivers/usb/musb/Kconfig |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/usb/musb/Kconfig b/drivers/usb/musb/Kconfig index ef0c3f9..2c74188 100644 --- a/drivers/usb/musb/Kconfig +++ b/drivers/usb/musb/Kconfig @@ -20,7 +20,7 @@ config USB_MUSB_HDRC it's being used with, including the USB peripheral role, or the USB host role, or both. - Texas Instruments familiies using this IP include DaVinci + Texas Instruments families using this IP include DaVinci (35x, 644x ...), OMAP 243x, OMAP 3, and TUSB 6010. Analog Devices parts using this IP include Blackfin BF54x, -- 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
linux 3.6-rc2, undefined reference to omap_musb_mailbox
3.6-rc2 fails to compile with CONFIG_USB_MUSB_HDRC=m CONFIG_USB_MUSB_OMAP2PLUS=m LD init/built-in.o drivers/built-in.o: In function `twl4030_usb_irq': /home/pmeerw/linux-3.6-rc2/drivers/usb/otg/twl4030-usb.c:518: undefined reference to `omap_musb_mailbox' drivers/built-in.o: In function `twl4030_usb_phy_init': /home/pmeerw/linux-3.6-rc2/drivers/usb/otg/twl4030-usb.c:540: undefined reference to `omap_musb_mailbox' make[1]: *** [vmlinux] Error 1 make[1]: Leaving directory `/home/pmeerw/linux-3.6-rc2' thanks, p. -- Peter Meerwald +43-664-218 (mobile) -- 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: add ZTE EV_DO to a proper driver
On Sat, Aug 18, 2012 at 07:57:21AM -0700, nirinA raseliarison wrote: on Sat, 18 Aug 2012 03:02:13 +0300, Greg KH gre...@linuxfoundation.org wrote: On Thu, Jul 26, 2012 at 05:51:59PM +0300, nirinA raseliarison wrote: hi Greg, Le Thu, 26 Jul 2012 01:04:08 +0300, Greg KH gre...@linuxfoundation.org a écrit: On Wed, Jul 25, 2012 at 12:51:34PM -0700, nirinA raseliarison wrote: hello there, i have an usb modem zte ev-do that i used with kernel from 2.6.29 up to 3.5. since 3.5, i got the following message: [77496.664090] usb 5-2: udev 10, busnum 5, minor = 521 [77496.664097] usb 5-2: New USB device found, idVendor=19d2, idProduct= [77496.664102] usb 5-2: New USB device strings: Mfr=1, Product=2, SerialNumber=0 [77496.664107] usb 5-2: Product: ZTE CDMA Tech [77496.664112] usb 5-2: Manufacturer: ZTE, Incorporated [77496.664226] usb 5-2: usb_probe_device [77496.664232] usb 5-2: configuration #1 chosen from 1 choice [77496.667119] usb 5-2: adding 5-2:1.0 (config #1, interface 0) [77496.670161] usbserial_generic 5-2:1.0: usb_probe_interface [77496.670169] usbserial_generic 5-2:1.0: usb_probe_interface - got id [77496.670177] usbserial_generic 5-2:1.0: The generic usb-serial driver is only for testing and one-off prototypes. [77496.670182] usbserial_generic 5-2:1.0: Tell linux-usb@vger.kernel.org to add your device to a proper driver. [77496.670186] usbserial_generic 5-2:1.0: generic converter detected [77496.670276] usb 5-2: generic converter now attached to ttyUSB0 i would be nice to have a driver for this device in the kernel. the device is shipped with sources to build its modules. if i understand correctly thet are released under GPL, so i attached them below. this is portion of Makefile i used: obj-m := ztemt.o ztemt-objs := usb-serial.o bus.o generic.o ezusb.o zte_ev.o Ick, that's not really the proper way to support this device, but I can take the file below and write a real driver for it. Can you test a patch if I create it? yes, of course, i can test it. Very sorry for the delay, but I think I have a first cut at this. Can you try the patch attached to this mail, it was made against the 3.6-rc2 kernel, but should apply cleanly to the 3.5 kernel and probably older ones as well. Can you enable this driver and let me know if it works properly for you or not? i've patched against 3.5.0 and it worked like a charm. below portion of dmesg when the device was plugged, did a few minutes of connexion and then unplugged. Wonderful, thanks for testing, I'll queue it up for the 3.7 kernel release after I clean up the debugging code a bit. 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: Kernel oops on usbhid_submit_report (updates)
On Fri, Aug 17, 2012 at 10:04:24PM -0400, Alan Stern wrote: [snip] Thanks for the reply. Some updates: After running usbmon, I realized that the paging request address is the address of the urb. That doesn't make sense. implement() shouldn't know anything about the address of any URBs. (It should be able to access an URB's transfer buffer, but that's a different matter.) Check out the following output from the oops markup (http://paste.debian.net/184443/). It isolates the faulting instruction. Maybe it makes more sense to you? I think the urb gets deleted while the implement function is going on. If hid_output_report() gets passed the address of an URB then something has already gone wrong. Looking at the output of usbmon, the kernel re-uses URB addresses. Is it possible that the urb is freed while the instruction is in *implement()*? Thanks, Amit -- 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: add ZTE EV_DO to a proper driver
Le Sat, 18 Aug 2012 19:18:31 +0300, Greg KH gre...@linuxfoundation.org a écrit: On Sat, Aug 18, 2012 at 07:57:21AM -0700, nirinA raseliarison wrote: on Sat, 18 Aug 2012 03:02:13 +0300, Greg KH gre...@linuxfoundation.org wrote: On Thu, Jul 26, 2012 at 05:51:59PM +0300, nirinA raseliarison wrote: hi Greg, Le Thu, 26 Jul 2012 01:04:08 +0300, Greg KH gre...@linuxfoundation.org a écrit: On Wed, Jul 25, 2012 at 12:51:34PM -0700, nirinA raseliarison wrote: hello there, i have an usb modem zte ev-do that i used with kernel from 2.6.29 up to 3.5. since 3.5, i got the following message: [77496.664090] usb 5-2: udev 10, busnum 5, minor = 521 [77496.664097] usb 5-2: New USB device found, idVendor=19d2, idProduct= [77496.664102] usb 5-2: New USB device strings: Mfr=1, Product=2, SerialNumber=0 [77496.664107] usb 5-2: Product: ZTE CDMA Tech [77496.664112] usb 5-2: Manufacturer: ZTE, Incorporated [77496.664226] usb 5-2: usb_probe_device [77496.664232] usb 5-2: configuration #1 chosen from 1 choice [77496.667119] usb 5-2: adding 5-2:1.0 (config #1, interface 0) [77496.670161] usbserial_generic 5-2:1.0: usb_probe_interface [77496.670169] usbserial_generic 5-2:1.0: usb_probe_interface - got id [77496.670177] usbserial_generic 5-2:1.0: The generic usb-serial driver is only for testing and one-off prototypes. [77496.670182] usbserial_generic 5-2:1.0: Tell linux-usb@vger.kernel.org to add your device to a proper driver. [77496.670186] usbserial_generic 5-2:1.0: generic converter detected [77496.670276] usb 5-2: generic converter now attached to ttyUSB0 i would be nice to have a driver for this device in the kernel. the device is shipped with sources to build its modules. if i understand correctly thet are released under GPL, so i attached them below. this is portion of Makefile i used: obj-m := ztemt.o ztemt-objs := usb-serial.o bus.o generic.o ezusb.o zte_ev.o Ick, that's not really the proper way to support this device, but I can take the file below and write a real driver for it. Can you test a patch if I create it? yes, of course, i can test it. Very sorry for the delay, but I think I have a first cut at this. Can you try the patch attached to this mail, it was made against the 3.6-rc2 kernel, but should apply cleanly to the 3.5 kernel and probably older ones as well. Can you enable this driver and let me know if it works properly for you or not? i've patched against 3.5.0 and it worked like a charm. below portion of dmesg when the device was plugged, did a few minutes of connexion and then unplugged. Wonderful, thanks for testing, I'll queue it up for the 3.7 kernel release after I clean up the debugging code a bit. that's really nice. thanks. greg k-h -- nirinA -- 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: Kernel oops on usbhid_submit_report (updates)
On Sat, 18 Aug 2012, Alan Stern wrote: Looking at the output of usbmon, the kernel re-uses URB addresses. Is it possible that the urb is freed while the instruction is in *implement()*? In fact, the usbhid driver does not free any URBs until it is unbound from the device. It keeps a circular queue of URBs and uses them in sequence, over and over. Correction: The usbhid driver keeps a circular queue of report structures and related data and uses _them_ in sequence, over and over. There is only one URB, which gets used for all the reports. More accurately, there is one URB for the interrupt-IN endpoint, one URB for the interrupt-OUT endpoint (if there is one), and one URB for endpoint 0. Each URB gets used for all the reports on its endpoint. One thing to look out for: Evidently usbhid_submit_report() does not check the HID_DISCONNECTED flag and will happily allow reports to be submitted after usbhid_stop() returns. This appears to be a bug. It could account for the behavior you're seeing. 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
