Re: usbmon: compile as an external module
hello On Sun, 2008-02-17 at 14:13 -0800, Pete Zaitcev wrote: > On Fri, 15 Feb 2008 09:38:14 +0100, "Paolo Abeni" wrote: > > > I'm again playing with usbmon and I think it would be useful, at least > > for testing purpose, being able to compile the usbmon device code as an > > external module. [] > > This can easily be accomplished by building USB core as a module. True :-) Anyway the infrastructure to compile usbmon as a module is yet in place and take advantage of it will help save some memory when usbmon is not used. Moreover it's a bit more troublesome probe/remove the USB core (when compiled as a module) than the only usbmon (for example if I have [part of] my root file system mounted via usb-storage...) > > CONFIG_USB_MON_MMAP enable memory mapped access for the usbmon binary > > device > > If you're going to use it, we should just enable it. I'll send a > patch. I follow the example of packet socket, which have memory mapped access and a configuration option for enabling it. Generally speaking, I thought that having fine-grane configuration options would be preferable. cheers, Paolo -- Email.it, the professional e-mail, gratis per te: http://www.email.it/f Sponsor: Nuovi giochi per cellulare. Scarica e inizia la tua partita. * Clicca qui: http://adv.email.it/cgi-bin/foclick.cgi?mid=7519&d=18-2 - To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Detaching memory stick leaves device node reserved
--- Alan Stern : > On Fri, 15 Feb 2008, tike64 wrote: > > > I can't understand what is going on with yahoo. My reply seemed > > perfectly normal before sending. Hopefully this comes through a > > little prettier ... > > Sorry, yes, this is much better. I had to edit the text first in text editor and then paste it to the mail window. But now I switched back to yahoo mail classic -- let's see... > Ubuntu's desktop environment probably includes a program (like hal or > autofs) that watches for device removals and automatically unmounts > the filesystem for you. Yes, this was supposed to be handled by udev scripts in the ARM environment. The thing was that I was not able to do the umount even manually. But now, as I tried to collect more details, I am not able to replicate the problem at all! How typical and embarrassing. One thing that might have misled me is that the shell kept the redirected file open. But I tried honestly to check very carefully that there were no files open on the stick before umount. Oh well... Thanks anyway and sorry for the noise. The difference between the ARM system and my desktop was that the desktop uses lazy umount. -- Timo Never miss a thing. Make Yahoo your home page. http://www.yahoo.com/r/hs - To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Nikon D80 new FW still needs Fixup
Konstantin Kletschke wrote: > Hi! > > The Nikon D80 got a new Firmware version 1.10 and still needs the fixup > in unusual_devs.h (I suspect they will never fix this :-)) > > Kind Regards, Konsti > > This looks fine to me. For form's sake, can I get we copy of /proc/bus/usb/devices with the device plugged in? Thanks. -- Phil Dibowitz [EMAIL PROTECTED] Open Source software and tech docsInsanity Palace of Metallica http://www.phildev.net/ http://www.ipom.com/ "Never write it in C if you can do it in 'awk'; Never do it in 'awk' if 'sed' can handle it; Never use 'sed' when 'tr' can do the job; Never invoke 'tr' when 'cat' is sufficient; Avoid using 'cat' whenever possible" -- Taylor's Laws of Programming signature.asc Description: OpenPGP digital signature
[PATCH] USB: Simplify EHCI's itd_urb_transaction()
stream->free_list is either empty or contains ITD(s).
Spare an "if (!itd)" and only do another after dma_pool_alloc().
Signed-off-by: Karsten Wiese <[EMAIL PROTECTED]>
---
drivers/usb/host/ehci-sched.c | 15 ++-
1 files changed, 6 insertions(+), 9 deletions(-)
diff --git a/drivers/usb/host/ehci-sched.c b/drivers/usb/host/ehci-sched.c
index e3e85ab..d009d3c 100644
--- a/drivers/usb/host/ehci-sched.c
+++ b/drivers/usb/host/ehci-sched.c
@@ -1182,21 +1182,18 @@ itd_urb_transaction (
struct ehci_itd, itd_list);
list_del (&itd->itd_list);
itd_dma = itd->itd_dma;
- } else
- itd = NULL;
-
- if (!itd) {
+ } else {
spin_unlock_irqrestore (&ehci->lock, flags);
itd = dma_pool_alloc (ehci->itd_pool, mem_flags,
&itd_dma);
spin_lock_irqsave (&ehci->lock, flags);
+ if (unlikely(!itd)) {
+ iso_sched_free(stream, sched);
+ spin_unlock_irqrestore(&ehci->lock, flags);
+ return -ENOMEM;
+ }
}
- if (unlikely (NULL == itd)) {
- iso_sched_free (stream, sched);
- spin_unlock_irqrestore (&ehci->lock, flags);
- return -ENOMEM;
- }
memset (itd, 0, sizeof *itd);
itd->itd_dma = itd_dma;
list_add (&itd->itd_list, &sched->td_list);
--
1.5.3.8
-
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: problem with starting 2.5.26-rc1 and latest git
On Thu, 14 Feb 2008 00:27:34 +0100, Mariusz Kozlowski wrote: > Of course there is a typo in the subject :) > > 2.5.25-rc1 -> 2.6.25-rc1 > > > Hello, > > > > I tried 2.6.25-rc1 and latest git on my laptop (x86 32bit) and have a > > problem. > > Linux boots but with huge delay due to some issue with loading usb modules. > > Udev complains: > > > > 'Could not lock modprobe uhci_hcd' > > 'Could not lock modprobe yenta_socket' > > 'Unknown symbol usb_*' > > 'Gave up waiting for init of module usbcore' > > (...) Have you tried upgrading to rc2? I used to have the same problem you reported, but I was unable to reproduce it since I upgraded to rc2. -- Jean Delvare - To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
USB enumeration process
Hi all, after we attach a usb device we get a hub_port_connect event which call usb_new_device. But after that, which function is called to create device nodes and configure the device so we can use it ? sorry, if it's a stupid question but I couldn't find such method tracing the function call :-s -- Best Regards, Felipe Balbi [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: ubs_skeleton how does unanchor_urb get called in write path?
On Sun, 2008-02-17 at 12:33 -0500, Alan Stern wrote: > On Sun, 17 Feb 2008, Richard Kennedy wrote: > > > Sorry if this a dumb question but I've been trying to figure out how to > > use usb_anchor_urb by looking at usb_skeleton.c. > > > > skel_write calls usb_anchor_urb, but how does usb_unanchor_urb get > > called when the urb is processed successfully? I see it gets called on > > the error path but nowhere else. > > When an URB completes (successfully or unsuccessfully), it > automatically is unanchored. > > > Should skel_write_bulk_callback call usb_unanchor_urb, or does it get > > done automatically by the framework? > > It is done automatically. Look at usb_hcd_giveback_urb() in > drivers/usb/core/hcd.c. > > Alan Stern Alan, Thanks for the pointer. I wonder if it's worth adding a note to the documentation for usb_anchor_urb just to say that they are automatically unlinked on completion ? Richard - To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: USB enumeration process
Hi, On Feb 18, 2008 5:02 PM, Alan Stern <[EMAIL PROTECTED]> wrote: > On Mon, 18 Feb 2008, Felipe Balbi wrote: > > > Hi all, > > > > after we attach a usb device we get a hub_port_connect event which > > call usb_new_device. But after that, which function is called to > > create device nodes and configure the device so we can use it ? > > > > sorry, if it's a stupid question but I couldn't find such method > > tracing the function call :-s > > Configuration is handled in generic.c:generic_probe(). > > Device nodes are created by udev, not by the kernel. But maybe you are > referring to the code in devio.c:usb_classdev_add(). Thanks Alan for the quick reply :-) what I really wanna know is when we match/bind drivers to usb_interfaces. -- Best Regards, Felipe Balbi [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: USB enumeration process
On Mon, 18 Feb 2008, Felipe Balbi wrote: > Thanks Alan for the quick reply :-) > what I really wanna know is when we match/bind drivers to usb_interfaces. That's in message.c:usb_set_configuration(). It occurs near the end of that routine, in the call to device_add(). Alan Stern - To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [usb-storage] usb-storage and S.M.A.R.T.
Hello, Le samedi 16 février 2008 à 12:54 -0800, Matthew Dharm a écrit : > On Thu, Feb 14, 2008 at 06:19:46PM +0100, René Rebe wrote: > > As I do not know the underlying protocols off-hand, is that a driver / > > sub-system limitation or not possible to get thru this USB mass > > storage protocol? > > It's a limitation of the particular USB/ATA bridge device you're using. > > Matt Do you know of USB-(S and/or P)ATA bridges that do not suffer from these limitations ? Regards, Guillaume B. - To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: USB enumeration process
On Mon, 18 Feb 2008, Felipe Balbi wrote: > Hi all, > > after we attach a usb device we get a hub_port_connect event which > call usb_new_device. But after that, which function is called to > create device nodes and configure the device so we can use it ? > > sorry, if it's a stupid question but I couldn't find such method > tracing the function call :-s Configuration is handled in generic.c:generic_probe(). Device nodes are created by udev, not by the kernel. But maybe you are referring to the code in devio.c:usb_classdev_add(). Alan Stern - To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: ubs_skeleton how does unanchor_urb get called in write path?
On Mon, 18 Feb 2008, Richard Kennedy wrote: > Alan, > Thanks for the pointer. > I wonder if it's worth adding a note to the documentation for > usb_anchor_urb just to say that they are automatically unlinked on > completion ? That sounds like a good idea. Care to submit a patch? Alan Stern - To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Hello!!
Congratulations!!Your email id was selected and you have therefore been awarded the sum of £750,000GBP by the Microsoft Promotions. contact this email for further instructions: [EMAIL PROTECTED] Thank you - To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: usb device handled by ohci and not by ehci
On Mon, 18 Feb 2008, Alan Stern wrote: > On Mon, 18 Feb 2008, Michael SCHINDLER wrote: > > > I have recompiled the kernel with USB debugging, and now I see > > explicitly that EHCI hands over the device to its companion driver > > OHCI (see below). > > > > However, I do not yet know why this happens and how I can avoid it and > > have the device handled by EHCI at full speed. Is it sufficient to > > create a new entry in unusual_dev.h? How do I specify the capability > > of USB2.0 there? > > Judging from your log, the reason the handover occurs is because your > device doesn't support high-speed operation. To confirm this, let's > see what "lsusb -v" has to say about the device. Another possible explanation is that your computer's EHCI controller doesn't work properly. Can you run any devices attached to that USB port at high speed? Alan Stern - To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: usb device handled by ohci and not by ehci
On Mon, 18 Feb 2008, Michael SCHINDLER wrote: > I have recompiled the kernel with USB debugging, and now I see > explicitly that EHCI hands over the device to its companion driver > OHCI (see below). > > However, I do not yet know why this happens and how I can avoid it and > have the device handled by EHCI at full speed. Is it sufficient to > create a new entry in unusual_dev.h? How do I specify the capability > of USB2.0 there? Judging from your log, the reason the handover occurs is because your device doesn't support high-speed operation. To confirm this, let's see what "lsusb -v" has to say about the device. Alan Stern - To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: usb device handled by ohci and not by ehci
Dear Alan, On 13.02.08, Alan Stern wrote: > On Wed, 13 Feb 2008 [EMAIL PROTECTED] wrote: > > I have problems with a usb device (mp3 player) which is handled by the > > kernel modules in a wrong way. It is a usb 2.0 device (which behaves > > as such on e.g. Mac OS X), but with the linux kernel (2.6.22-3 debian > > kernel) I encounter only about 1MB/min of data transfer. > > > > A look into /proc/bus/usb/devices shows that the device is handled by > > the ohci module instead of the ehci module. Can anybody explain to me > > how to fix (debug) this problem? I am a bit lost with the usb modules, > > which do not seem to have a debug option argument. > > You can start by looking at the output from dmesg. If that doesn't > provide enough information you can enable debugging by turning on > CONFIG_USB_DEBUG -- it's a configuration setting rather than a module > parameter. I have recompiled the kernel with USB debugging, and now I see explicitly that EHCI hands over the device to its companion driver OHCI (see below). However, I do not yet know why this happens and how I can avoid it and have the device handled by EHCI at full speed. Is it sufficient to create a new entry in unusual_dev.h? How do I specify the capability of USB2.0 there? Michael - output from dmesg Feb 13 19:11:00 pugliese kernel: hub 2-0:1.0: hub_resume Feb 13 19:11:00 pugliese kernel: ehci_hcd :00:0b.1: resume root hub Feb 13 19:11:00 pugliese kernel: hub 2-0:1.0: state 7 ports 8 chg evt Feb 13 19:11:00 pugliese kernel: ehci_hcd :00:0b.1: GetStatus port 2 status 001803 POWER sig=j CSC CONNECT Feb 13 19:11:00 pugliese kernel: hub 2-0:1.0: port 2, status 0501, change 0001, 480 Mb/s Feb 13 19:11:00 pugliese kernel: hub 2-0:1.0: debounce: port 2: total 100ms stable 100ms status 0x501 Feb 13 19:11:00 pugliese kernel: ehci_hcd :00:0b.1: port 2 full speed --> companion Feb 13 19:11:00 pugliese kernel: ehci_hcd :00:0b.1: GetStatus port 2 status 003001 POWER OWNER sig=se0 CONNECT Feb 13 19:11:00 pugliese kernel: hub 2-0:1.0: port 2 not reset yet, waiting 50ms Feb 13 19:11:00 pugliese kernel: usb usb1: usb resume Feb 13 19:11:00 pugliese kernel: usb usb1: finish resume Feb 13 19:11:00 pugliese kernel: hub 1-0:1.0: hub_resume Feb 13 19:11:00 pugliese kernel: ohci_hcd :00:0b.0: wakeup root hub Feb 13 19:11:00 pugliese kernel: ehci_hcd :00:0b.1: GetStatus port 2 status 003802 POWER OWNER sig=j CSC Feb 13 19:11:00 pugliese kernel: hub 2-0:1.0: state 7 ports 8 chg evt 0004 Feb 13 19:11:00 pugliese kernel: hub 1-0:1.0: state 7 ports 8 chg evt Feb 13 19:11:00 pugliese kernel: ohci_hcd :00:0b.0: GetStatus roothub.portstatus [1] = 0x00010101 CSC PPS CCS Feb 13 19:11:00 pugliese kernel: hub 1-0:1.0: port 2, status 0101, change 0001, 12 Mb/s Feb 13 19:11:00 pugliese kernel: hub 1-0:1.0: debounce: port 2: total 100ms stable 100ms status 0x101 Feb 13 19:11:00 pugliese kernel: ohci_hcd :00:0b.0: GetStatus roothub.portstatus [1] = 0x00100103 PRSC PPS PES CCS Feb 13 19:11:00 pugliese kernel: usb 1-2: new full speed USB device using ohci_hcd and address 2 Feb 13 19:11:01 pugliese kernel: ohci_hcd :00:0b.0: GetStatus roothub.portstatus [1] = 0x00100103 PRSC PPS PES CCS Feb 13 19:11:01 pugliese kernel: usb 1-2: ep0 maxpacket = 16 Feb 13 19:11:01 pugliese kernel: usb 1-2: default language 0x0409 Feb 13 19:11:01 pugliese kernel: usb 1-2: new device strings: Mfr=1, Product=2, SerialNumber=0 Feb 13 19:11:01 pugliese kernel: usb 1-2: Product: USB Mass Storage Device 2.0 Feb 13 19:11:01 pugliese kernel: usb 1-2: Manufacturer: NewTech Inc. Feb 13 19:11:01 pugliese kernel: usb 1-2: uevent Feb 13 19:11:01 pugliese kernel: usb 1-2: usb_probe_device Feb 13 19:11:01 pugliese kernel: usb 1-2: configuration #1 chosen from 1 choice Feb 13 19:11:01 pugliese kernel: usb 1-2: adding 1-2:1.0 (config #1, interface 0) Feb 13 19:11:01 pugliese kernel: usb 1-2:1.0: uevent Feb 13 19:11:01 pugliese kernel: usb 1-2:1.0: uevent Feb 13 19:11:01 pugliese kernel: libusual 1-2:1.0: usb_probe_interface Feb 13 19:11:01 pugliese kernel: libusual 1-2:1.0: usb_probe_interface - got id Feb 13 19:11:01 pugliese kernel: usb-storage 1-2:1.0: usb_probe_interface Feb 13 19:11:01 pugliese kernel: usb-storage 1-2:1.0: usb_probe_interface - got id Feb 13 19:11:01 pugliese kernel: usb-storage: USB Mass Storage device detected Feb 13 19:11:01 pugliese kernel: usb-storage: -- associate_dev Feb 13 19:11:01 pugliese kernel: usb-storage: Vendor: 0x04e8, Product: 0x9826, Revision: 0x0100 Feb 13 19:11:01 pugliese kernel: usb-storage: Interface Subclass: 0x06, Protocol: 0x50 Feb 13 19:11:01 pugliese kernel: usb-storage: Transport: Bulk Feb 13 19:11:01 pugliese kernel: usb-storage: Protocol: Transparent SCSI Feb 13 19:11:01 pugliese kernel: scsi3 : SCSI emulation for USB Mass Storage devices Feb 13 19:11:01 pugliese kernel: usb-storage: *** thread sleeping. Feb 13 19:11:01 pugliese kernel: usb-storage: device found at 2 Feb 13 19
Re: Re: Gadgetfs problem.
Hi Dave, After the stress test and backport gadget code from 2.6.24 to my current 2.6.20 version, the problem remains . It always reports error when responding to the following setup request: SETUP 80.06 v0300 i l00ff usb.c always fails at replying to this request, it reports: write string data: Device or resource busy ep0 read after poll: Level 2 halted I don't know if AIO is mandantory for this enumaration, as I did not use AIO. I also got something DEBUG message from gadgetfs as the following: SETUP 80.06 v0300 i l00ff gadgetfs: delegate req80.06 v0300 i l255 gadgetfs: event[1] = 3 gadgetfs: ep0 request busy! gadgetfs: ep0in stall Any suggestion for me? Thanks ... --- David Brownell <[EMAIL PROTECTED]>写道: > On Thursday 14 February 2008, hui zhuu wrote: > > > > Thanks, anyway, how can I find the if version > of > > > the > > > > gadgetfs.h is wrong? > > > > > > Use the version of the header from the kernel > that > > > you're running with. > > > > I just did that, the problem is still there. > > > > This is strange, as our d12 driver works ok with > the > > serial/ether/file_storage gadget, from this point > can > > I suppose it is sufficient to hooks up with > gadgetfs? > > It could be. Does g_zero work well in stress test > mode? > (That is, running all the tests in the test script, > for > several days at a time ... try it over this > weekend.) > > Usually the problem with gadgetfs has been a mode > for > handling control transfers that isn't widely used > ... > except in gadgetfs, and g_file_storage. > > > > The gadget code i am working with is form 2.6.20.4 > > kernel tree, I think it's pretty new. Did I miss > > anything else? > > I've not used gadgetfs much lately, beyond just a > quick sanity test on 2.6.24 to sort out that one > issue (which turned out to be in userspace). > > So, all I can say for sure is: try 2.6.24 and see > if that works for you too. > > - Dave > > ___ 雅虎邮箱传递新年祝福，个性贺卡送亲朋！ http://cn.mail.yahoo.com/gc/index.html?entry=5&souce=mail_mailletter_tagline - To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: usb device handled by ohci and not by ehci
Hello Alan, thanks for the quick response. On 18.02.08, Alan Stern wrote: > On Mon, 18 Feb 2008, Alan Stern wrote: > > On Mon, 18 Feb 2008, Michael SCHINDLER wrote: > > > > > I have recompiled the kernel with USB debugging, and now I see > > > explicitly that EHCI hands over the device to its companion driver > > > OHCI (see below). > > > > > > However, I do not yet know why this happens and how I can avoid it and > > > have the device handled by EHCI at full speed. Is it sufficient to > > > create a new entry in unusual_dev.h? How do I specify the capability > > > of USB2.0 there? > > Judging from your log, the reason the handover occurs is because your > > device doesn't support high-speed operation. To confirm this, let's > > see what "lsusb -v" has to say about the device. The output from lsusb -v for the device is below. I tested the device with MacOSX and found a transfer rate corresponding to high-speed (approximately the same as for a nicely working USB key, see below). In the meantime, I have tested the device with a different linux computer (also debian lenny) and found the same transfer rates. Only, this time the companion driver is UHCI and not OHCI. The logs below correspond to this situation. > Another possible explanation is that your computer's EHCI controller > doesn't work properly. Can you run any devices attached to that USB > port at high speed? Yes, I can. For comparison, I include the output from lsusb -v for a Toshiba USB key, which works nicely. Michael -- lsusb -v for the strange MP3-player Bus 001 Device 002: ID 04e8:9826 Samsung Electronics Co., Ltd Device Descriptor: bLength18 bDescriptorType 1 bcdUSB 2.00 bDeviceClass0 (Defined at Interface level) bDeviceSubClass 0 bDeviceProtocol 0 bMaxPacketSize016 idVendor 0x04e8 Samsung Electronics Co., Ltd idProduct 0x9826 bcdDevice1.00 iManufacturer 1 NewTech Inc. iProduct2 USB Mass Storage Device 2.0 iSerial 0 bNumConfigurations 1 Configuration Descriptor: bLength 9 bDescriptorType 2 wTotalLength 39 bNumInterfaces 1 bConfigurationValue 1 iConfiguration 0 bmAttributes 0x80 (Bus Powered) MaxPower 200mA Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber0 bAlternateSetting 0 bNumEndpoints 3 bInterfaceClass 8 Mass Storage bInterfaceSubClass 6 SCSI bInterfaceProtocol 80 Bulk (Zip) iInterface 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x82 EP 2 IN bmAttributes2 Transfer TypeBulk Synch Type None Usage Type Data wMaxPacketSize 0x0040 1x 64 bytes bInterval 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x03 EP 3 OUT bmAttributes2 Transfer TypeBulk Synch Type None Usage Type Data wMaxPacketSize 0x0040 1x 64 bytes bInterval 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x81 EP 1 IN bmAttributes3 Transfer TypeInterrupt Synch Type None Usage Type Data wMaxPacketSize 0x0040 1x 64 bytes bInterval 255 -- lsusb -v for a working USB key Bus 005 Device 004: ID 0930:6528 Toshiba Corp. Device Descriptor: bLength18 bDescriptorType 1 bcdUSB 2.00 bDeviceClass0 (Defined at Interface level) bDeviceSubClass 0 bDeviceProtocol 0 bMaxPacketSize064 idVendor 0x0930 Toshiba Corp. idProduct 0x6528 bcdDevice1.00 iManufacturer 1 TOSHIBA iProduct2 TransMemory iSerial 3 0A81F750B0F04A48 bNumConfigurations 1 Configuration Descriptor: bLength 9 bDescriptorType 2 wTotalLength 39 bNumInterfaces 1 bConfigurationValue 1 iConfiguration 0 bmAttributes 0x80 (Bus Powered) MaxPower 200mA Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber0 bAlternateSetting 0 bNumEndpoin
Re: usb device handled by ohci and not by ehci
On Mon, 18 Feb 2008, Michael SCHINDLER wrote: > > > Judging from your log, the reason the handover occurs is because your > > > device doesn't support high-speed operation. To confirm this, let's > > > see what "lsusb -v" has to say about the device. > > The output from lsusb -v for the device is below. I tested the device > with MacOSX and found a transfer rate corresponding to high-speed > (approximately the same as for a nicely working USB key, see below). > > In the meantime, I have tested the device with a different linux > computer (also debian lenny) and found the same transfer rates. Only, > this time the companion driver is UHCI and not OHCI. The logs below > correspond to this situation. I don't know what's going on with your Mac OSX test; however the lsusb output indicates plainly that the Samsung device does not run at high speed. The key point is lack of a Device Qualifier descriptor -- it is mandatory for high-speed devices (and notice that it is present in the working Toshiba device). Could it be that the Samsung device runs at full speed even under OSX and somehow your transfer rate test is giving a misleading result? > > Another possible explanation is that your computer's EHCI controller > > doesn't work properly. Can you run any devices attached to that USB > > port at high speed? > > Yes, I can. For comparison, I include the output from lsusb -v for a > Toshiba USB key, which works nicely. If you want a definitive test then edit the kernel source file drivers/usb/host/ehci_hub.c, and at the start of the check_reset_complete() routine add the following lines: ehci_dbg(ehci, "port %d status after reset 0x%x\n", index + 1, port_status); After you build and load the new ehci_hcd.ko module, that new debugging line should show up in the dmesg log when you plug in any USB device. What does it say for the Samsung and Toshiba devices? Alan Stern - To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Nikon D80 new FW still needs Fixup
Am 2008-02-18 03:09 -0800 schrieb Phil Dibowitz: > This looks fine to me. For form's sake, can I get we copy of > /proc/bus/usb/devices with the device plugged in? You mean this? T: Bus=02 Lev=01 Prnt=01 Port=04 Cnt=02 Dev#= 5 Spd=480 MxCh= 0 D: Ver= 2.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs= 1 P: Vendor=04b0 ProdID=0411 Rev= 1.10 S: Manufacturer=NIKON S: Product=NIKON DSC D80 S: SerialNumber=04042426 C:* #Ifs= 1 Cfg#= 1 Atr=c0 MxPwr= 2mA I:* If#= 0 Alt= 0 #EPs= 2 Cls=08(stor.) Sub=06 Prot=50 Driver=usb-storage E: Ad=81(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=02(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms In case of not I will of course deliver other required data :) Kind Regards, Konsti -- GPG KeyID EF62FCEF Fingerprint: 13C9 B16B 9844 EC15 CC2E A080 1E69 3FDA EF62 FCEF - To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[patch 1/3] Convert stats_sem in a mutex
The semaphore cp->mutex is used as mutex, convert it to the mutex API
Signed-off-by: Matthias Kaehlcke <[EMAIL PROTECTED]>
Index: linux-2.6/drivers/usb/misc/auerswald.c
===
--- linux-2.6.orig/drivers/usb/misc/auerswald.c 2008-02-18 19:47:18.0
+0100
+++ linux-2.6/drivers/usb/misc/auerswald.c 2008-02-18 19:51:52.0
+0100
@@ -31,6 +31,7 @@
#include
#include
#include
+#include
/*---*/
/* Debug support*/
@@ -232,7 +233,7 @@
/* USB device context */
typedef struct
{
- struct semaphoremutex; /* protection in user
context */
+ struct mutexmutex; /* protection in user context */
charname[20]; /* name of the /dev/usb
entry */
unsigned intdtindex;/* index in the device
table */
struct usb_device * usbdev; /* USB device handle */
@@ -1376,7 +1377,7 @@
if (cp == NULL) {
return -ENODEV;
}
- if (down_interruptible (&cp->mutex)) {
+ if (mutex_lock_interruptible(&cp->mutex)) {
return -ERESTARTSYS;
}
@@ -1405,7 +1406,7 @@
cp->open_count++;
ccp->auerdev = cp;
dbg("open %s as /dev/%s", cp->dev_desc, cp->name);
- up (&cp->mutex);
+ mutex_unlock(&cp->mutex);
/* file IO stuff */
file->f_pos = 0;
@@ -1413,7 +1414,7 @@
return nonseekable_open(inode, file);
/* Error exit */
-ofail: up (&cp->mutex);
+ofail: mutex_unlock(&cp->mutex);
auerchar_delete (ccp);
return ret;
}
@@ -1440,14 +1441,14 @@
up (&ccp->mutex);
return -ENODEV;
}
- if (down_interruptible (&cp->mutex)) {
+ if (mutex_lock_interruptible(&cp->mutex)) {
up(&ccp->mutex);
return -ERESTARTSYS;
}
/* Check for removal */
if (!cp->usbdev) {
- up(&cp->mutex);
+ mutex_unlock(&cp->mutex);
up(&ccp->mutex);
return -ENODEV;
}
@@ -1550,7 +1551,7 @@
break;
}
/* release the mutexes */
- up(&cp->mutex);
+ mutex_unlock(&cp->mutex);
up(&ccp->mutex);
return ret;
}
@@ -1721,12 +1722,12 @@
up (&ccp->mutex);
return -ERESTARTSYS;
}
- if (down_interruptible (&cp->mutex)) {
+ if (mutex_lock_interruptible(&cp->mutex)) {
up (&ccp->mutex);
return -ERESTARTSYS;
}
if (!cp->usbdev) {
- up (&cp->mutex);
+ mutex_unlock(&cp->mutex);
up (&ccp->mutex);
return -EIO;
}
@@ -1750,7 +1751,7 @@
/* are there any buffers left? */
if (!bp) {
- up (&cp->mutex);
+ mutex_unlock(&cp->mutex);
up (&ccp->mutex);
/* NONBLOCK: don't wait */
@@ -1783,7 +1784,7 @@
auerbuf_releasebuf (bp);
/* Wake up all processes waiting for a buffer */
wake_up (&cp->bufferwait);
- up (&cp->mutex);
+ mutex_unlock(&cp->mutex);
up (&ccp->mutex);
return -EFAULT;
}
@@ -1803,7 +1804,7 @@
auerchar_ctrlwrite_complete, bp);
/* up we go */
ret = auerchain_submit_urb (&cp->controlchain, bp->urbp);
- up (&cp->mutex);
+ mutex_unlock(&cp->mutex);
if (ret) {
dbg ("auerchar_write: nonzero result of auerchain_submit_urb
%d", ret);
auerbuf_releasebuf (bp);
@@ -1830,16 +1831,16 @@
down(&ccp->mutex);
cp = ccp->auerdev;
if (cp) {
- down(&cp->mutex);
+ mutex_lock(&cp->mutex);
/* remove an open service */
auerswald_removeservice (cp, &ccp->scontext);
/* detach from device */
if ((--cp->open_count <= 0) && (cp->usbdev == NULL)) {
/* usb device waits for removal */
- up (&cp->mutex);
+ mutex_unlock(&cp->mutex);
auerswald_delete (cp);
} else {
- up (&cp->mutex);
+ mutex_unlock(&cp->mutex);
}
cp = NULL;
ccp->auerdev = NULL;
@@ -1917,7 +1918,7 @@
}
/* Initialize device descriptor */
- init_MUTEX (&cp->mutex);
+ mutex_init(&cp->mutex);
cp->usbdev = usbdev;
auerchain_init (&cp->controlchain);
auerbuf_init (&cp->bufctl);
@@ -2042,7 +2043,7 @@
/* give back our USB minor number */
usb_deregister_dev(i
[patch 3/3] Convert ccp->mutex in a mutex
The semaphore ccp->mutex is used as mutex, convert it to the mutex API
Signed-off-by: Matthias Kaehlcke <[EMAIL PROTECTED]>
Index: linux-2.6/drivers/usb/misc/auerswald.c
===
--- linux-2.6.orig/drivers/usb/misc/auerswald.c 2008-02-18 20:17:08.0
+0100
+++ linux-2.6/drivers/usb/misc/auerswald.c 2008-02-18 20:28:02.0
+0100
@@ -254,7 +254,7 @@
/* character device context */
typedef struct
{
- struct semaphore mutex; /* protection in user context */
+ struct mutex mutex; /* protection in user context */
pauerswald_t auerdev; /* context pointer of assigned device */
auerbufctl_t bufctl;/* controls the buffer chain */
auerscon_t scontext;/* service context */
@@ -1390,7 +1390,7 @@
}
/* Initialize device descriptor */
- init_MUTEX( &ccp->mutex);
+ mutex_init(&ccp->mutex);
mutex_init(&ccp->readmutex);
auerbuf_init (&ccp->bufctl);
ccp->scontext.id = AUH_UNASSIGNED;
@@ -1433,23 +1433,23 @@
dbg ("ioctl");
/* get the mutexes */
- if (down_interruptible (&ccp->mutex)) {
+ if (mutex_lock_interruptible(&ccp->mutex)) {
return -ERESTARTSYS;
}
cp = ccp->auerdev;
if (!cp) {
- up (&ccp->mutex);
+ mutex_unlock(&ccp->mutex);
return -ENODEV;
}
if (mutex_lock_interruptible(&cp->mutex)) {
- up(&ccp->mutex);
+ mutex_unlock(&ccp->mutex);
return -ERESTARTSYS;
}
/* Check for removal */
if (!cp->usbdev) {
mutex_unlock(&cp->mutex);
- up(&ccp->mutex);
+ mutex_unlock(&ccp->mutex);
return -ENODEV;
}
@@ -1552,7 +1552,7 @@
}
/* release the mutexes */
mutex_unlock(&cp->mutex);
- up(&ccp->mutex);
+ mutex_unlock(&ccp->mutex);
return ret;
}
@@ -1575,18 +1575,18 @@
return 0;
/* get the mutex */
- if (down_interruptible (&ccp->mutex))
+ if (mutex_lock_interruptible(&ccp->mutex))
return -ERESTARTSYS;
/* Can we expect to read something? */
if (ccp->scontext.id == AUH_UNASSIGNED) {
- up (&ccp->mutex);
+ mutex_unlock(&ccp->mutex);
return -EIO;
}
/* only one reader per device allowed */
if (mutex_lock_interruptible(&ccp->readmutex)) {
- up (&ccp->mutex);
+ mutex_unlock(&ccp->mutex);
return -ERESTARTSYS;
}
@@ -1604,7 +1604,7 @@
if (copy_to_user (buf, bp->bufp+ccp->readoffset,
count)) {
dbg ("auerswald_read: copy_to_user failed");
mutex_unlock(&ccp->readmutex);
- up (&ccp->mutex);
+ mutex_unlock(&ccp->mutex);
return -EFAULT;
}
}
@@ -1619,7 +1619,7 @@
/* return with number of bytes read */
if (count) {
mutex_unlock(&ccp->readmutex);
- up (&ccp->mutex);
+ mutex_unlock(&ccp->mutex);
return count;
}
}
@@ -1656,12 +1656,12 @@
set_current_state (TASK_RUNNING);
remove_wait_queue (&ccp->readwait, &wait);
mutex_unlock(&ccp->readmutex);
- up (&ccp->mutex);
+ mutex_unlock(&ccp->mutex);
return -EAGAIN; /* nonblocking, no data available */
}
/* yes, we should wait! */
- up (&ccp->mutex); /* allow other operations while we wait */
+ mutex_unlock(&ccp->mutex); /* allow other operations while we wait */
schedule();
remove_wait_queue (&ccp->readwait, &wait);
if (signal_pending (current)) {
@@ -1676,7 +1676,7 @@
return -EIO;
}
- if (down_interruptible (&ccp->mutex)) {
+ if (mutex_lock_interruptible(&ccp->mutex)) {
mutex_unlock(&ccp->readmutex);
return -ERESTARTSYS;
}
@@ -1708,27 +1708,27 @@
write_again:
/* get the mutex */
- if (down_interruptible (&ccp->mutex))
+ if (mutex_lock_interruptible(&ccp->mutex))
return -ERESTARTSYS;
/* Can we expect to write something? */
if (ccp->scontext.id == AUH_UNASSIGNED) {
- up (&ccp->mutex);
+ mutex_unlock(&ccp->mutex);
return -EIO;
}
cp = ccp->auerdev;
if (!cp) {
- up (&ccp->mutex);
+ mutex_unlock(&ccp->mutex);
return -ERESTARTSYS;
}
[patch 0/3] USB Auerswald ISDN: Convert semaphores to mutexes
USB Auerswald ISDN driver: The semaphores cp->mutex, ccp->readmutex and ccp->mutex are used as mutexes, convert them to the muxex API -- Matthias Kaehlcke Linux System Developer Barcelona We build too many walls and not enough bridges (Isaac Newton) .''`. using free software / Debian GNU/Linux | http://debian.org : :' : `. `'` gpg --keyserver pgp.mit.edu --recv-keys 47D8E5D4 `- - To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[patch 2/3] Convert ccp->readmutex in a mutex
The semaphore ccp->readmutex is used as mutex, convert it to the mutex API
Signed-off-by: Matthias Kaehlcke <[EMAIL PROTECTED]>
Index: linux-2.6/drivers/usb/misc/auerswald.c
===
--- linux-2.6.orig/drivers/usb/misc/auerswald.c 2008-02-18 20:12:55.0
+0100
+++ linux-2.6/drivers/usb/misc/auerswald.c 2008-02-18 20:10:00.0
+0100
@@ -259,7 +259,7 @@
auerbufctl_t bufctl;/* controls the buffer chain */
auerscon_t scontext;/* service context */
wait_queue_head_t readwait; /* for synchronous reading */
- struct semaphore readmutex; /* protection against multiple reads */
+ struct mutex readmutex; /* protection against multiple reads */
pauerbuf_t readbuf; /* buffer held for partial reading */
unsigned int readoffset;/* current offset in readbuf */
unsigned int removed; /* is != 0 if device is removed */
@@ -1391,7 +1391,7 @@
/* Initialize device descriptor */
init_MUTEX( &ccp->mutex);
- init_MUTEX( &ccp->readmutex);
+ mutex_init(&ccp->readmutex);
auerbuf_init (&ccp->bufctl);
ccp->scontext.id = AUH_UNASSIGNED;
ccp->scontext.dispatch = auerchar_ctrlread_dispatch;
@@ -1585,7 +1585,7 @@
}
/* only one reader per device allowed */
- if (down_interruptible (&ccp->readmutex)) {
+ if (mutex_lock_interruptible(&ccp->readmutex)) {
up (&ccp->mutex);
return -ERESTARTSYS;
}
@@ -1603,7 +1603,7 @@
if (count) {
if (copy_to_user (buf, bp->bufp+ccp->readoffset,
count)) {
dbg ("auerswald_read: copy_to_user failed");
- up (&ccp->readmutex);
+ mutex_unlock(&ccp->readmutex);
up (&ccp->mutex);
return -EFAULT;
}
@@ -1618,7 +1618,7 @@
}
/* return with number of bytes read */
if (count) {
- up (&ccp->readmutex);
+ mutex_unlock(&ccp->readmutex);
up (&ccp->mutex);
return count;
}
@@ -1655,7 +1655,7 @@
dbg ("No read buffer available, returning -EAGAIN");
set_current_state (TASK_RUNNING);
remove_wait_queue (&ccp->readwait, &wait);
- up (&ccp->readmutex);
+ mutex_unlock(&ccp->readmutex);
up (&ccp->mutex);
return -EAGAIN; /* nonblocking, no data available */
}
@@ -1666,18 +1666,18 @@
remove_wait_queue (&ccp->readwait, &wait);
if (signal_pending (current)) {
/* waked up by a signal */
- up (&ccp->readmutex);
+ mutex_unlock(&ccp->readmutex);
return -ERESTARTSYS;
}
/* Anything left to read? */
if ((ccp->scontext.id == AUH_UNASSIGNED) || ccp->removed) {
- up (&ccp->readmutex);
+ mutex_unlock(&ccp->readmutex);
return -EIO;
}
if (down_interruptible (&ccp->mutex)) {
- up (&ccp->readmutex);
+ mutex_unlock(&ccp->readmutex);
return -ERESTARTSYS;
}
--
Matthias Kaehlcke
Linux System Developer
Barcelona
We build too many walls and not enough bridges
(Isaac Newton)
.''`.
using free software / Debian GNU/Linux | http://debian.org : :' :
`. `'`
gpg --keyserver pgp.mit.edu --recv-keys 47D8E5D4 `-
-
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: usb device handled by ohci and not by ehci
On Monday 18 February 2008, Alan Stern wrote: > I don't know what's going on with your Mac OSX test; however the lsusb > output indicates plainly that the Samsung device does not run at high > speed. The key point is lack of a Device Qualifier descriptor -- it > is mandatory for high-speed devices (and notice that it is present in > the working Toshiba device). That's what it looked like to me too ... but there are still some old versions of "lsusb" floating around, which don't even try to dump the device qualifier. If both those descriptor dumps were made on the same system, and hence same "lsusb" binary, then it would seem clear that the issue is just that the Samsung device won't run at high speed. - Dave - To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Gadgetfs problem.
On Monday 18 February 2008, hui zhuu wrote: > Hi Dave, > > After the stress test and backport gadget code from > 2.6.24 to my current 2.6.20 version, the problem > remains . Suggesting more strongly that it's the "d12" driver which is making trouble. > It always reports error when responding to the > following setup request: > > SETUP 80.06 v0300 i l00ff See below ... this is *after* the problem. The fact that you see an error with this request is a side effect of the bug. > usb.c always fails at replying to this request, it > reports: > > write string data: Device or resource busy > ep0 read after poll: Level 2 halted > > I don't know if AIO is mandantory for this > enumaration, as I did not use AIO. > > I also got something DEBUG message from gadgetfs as > the following: > > SETUP 80.06 v0300 i l00ff > gadgetfs: delegate req80.06 v0300 i l255 > gadgetfs: event[1] = 3 > gadgetfs: ep0 request busy! Did you look at the gadgetfs source to see *WHY* that message was emitted? It explains much of what the problem is. Specifically, setup_out_ready is set. And a simple examination of the code shows that there's only one way that can be nonzero: there was an ep0out request, and its data didn't get up to userspace yet. What request was that? Is your d12 driver handling its part of that request correctly ... including the code paths which clear that flag after it gets set? - Dave > gadgetfs: ep0in stall > > Any suggestion for me? > > Thanks ... > > > --- David Brownell <[EMAIL PROTECTED]>写道: > > > On Thursday 14 February 2008, hui zhuu wrote: > > > > > Thanks, anyway, how can I find the if version > > of > > > > the > > > > > gadgetfs.h is wrong? > > > > > > > > Use the version of the header from the kernel > > that > > > > you're running with. > > > > > > I just did that, the problem is still there. > > > > > > This is strange, as our d12 driver works ok with > > the > > > serial/ether/file_storage gadget, from this point > > can > > > I suppose it is sufficient to hooks up with > > gadgetfs? > > > > It could be. Does g_zero work well in stress test > > mode? > > (That is, running all the tests in the test script, > > for > > several days at a time ... try it over this > > weekend.) > > > > Usually the problem with gadgetfs has been a mode > > for > > handling control transfers that isn't widely used > > ... > > except in gadgetfs, and g_file_storage. > > > > > > > The gadget code i am working with is form 2.6.20.4 > > > kernel tree, I think it's pretty new. Did I miss > > > anything else? > > > > I've not used gadgetfs much lately, beyond just a > > quick sanity test on 2.6.24 to sort out that one > > issue (which turned out to be in userspace). > > > > So, all I can say for sure is: try 2.6.24 and see > > if that works for you too. > > > > - Dave > > - To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Nikon D80 new FW still needs Fixup
Konstantin Kletschke wrote: > Am 2008-02-18 03:09 -0800 schrieb Phil Dibowitz: > >> This looks fine to me. For form's sake, can I get we copy of >> /proc/bus/usb/devices with the device plugged in? > > You mean this? Yup. Thanks. I just noticed your patch is missing a "Signed-off-by" line, can you please re-send your patch with that added, and I can then add mine and pass it on upstream? See Documentation/SubmittingPatches for more details. Let me know if you have any questions. Thanks. -- Phil Dibowitz [EMAIL PROTECTED] Open Source software and tech docsInsanity Palace of Metallica http://www.phildev.net/ http://www.ipom.com/ "Never write it in C if you can do it in 'awk'; Never do it in 'awk' if 'sed' can handle it; Never use 'sed' when 'tr' can do the job; Never invoke 'tr' when 'cat' is sufficient; Avoid using 'cat' whenever possible" -- Taylor's Laws of Programming signature.asc Description: OpenPGP digital signature
Problem with USB detection [Device not following USB spec but works in windows!!]
Hi all, I have 1 more USB which is not gettingdetected. Following is the information and my analysis on it Error: usb 2-1: device not accepting address 3, error -71 usb 2-1: device not accepting address 4, error -71 In hub.c i tried both the old scheme and the new scheme but still it doesnt work. The error comes when hub driver is trying to assign a unique address(which the device is not able to accept) , with the new scheme we first send a 64 byte get_device_descriptor and get the ep0 max packet size(Dont know what it is?), but it appears that device is not able to accept this standard request. Even set_address is failing (It shd not fail right?). Currently i dont have the USB stick i have asked them to courier it to me. Once it comes i will try to analyse in detail. But still it appears device is not following the spec. I guess according to the USB spec device should respond to device descriptor request? . But i dont know why 64 byte device descriptor request is made(it is working for normal USB's for which kernel makes 64 btye request), The size of the descriptor is 18 bytes, but kernel can ask for <= 18 bytes right? Any clues on this error will be helpful? Will keep updating u on my observations and analysis. Warm Regards, Akshay - To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] USB: Simplify EHCI's itd_urb_transaction()
On Monday 18 February 2008, Karsten Wiese wrote:
>
> stream->free_list is either empty or contains ITD(s).
> Spare an "if (!itd)" and only do another after dma_pool_alloc().
>
> Signed-off-by: Karsten Wiese <[EMAIL PROTECTED]>
Can you update this to do the same for sitd_urb_transaction()?
> ---
> drivers/usb/host/ehci-sched.c | 15 ++-
> 1 files changed, 6 insertions(+), 9 deletions(-)
>
> diff --git a/drivers/usb/host/ehci-sched.c b/drivers/usb/host/ehci-sched.c
> index e3e85ab..d009d3c 100644
> --- a/drivers/usb/host/ehci-sched.c
> +++ b/drivers/usb/host/ehci-sched.c
> @@ -1182,21 +1182,18 @@ itd_urb_transaction (
> struct ehci_itd, itd_list);
> list_del (&itd->itd_list);
> itd_dma = itd->itd_dma;
> - } else
> - itd = NULL;
> -
> - if (!itd) {
> + } else {
> spin_unlock_irqrestore (&ehci->lock, flags);
> itd = dma_pool_alloc (ehci->itd_pool, mem_flags,
> &itd_dma);
> spin_lock_irqsave (&ehci->lock, flags);
> + if (unlikely(!itd)) {
> + iso_sched_free(stream, sched);
> + spin_unlock_irqrestore(&ehci->lock, flags);
> + return -ENOMEM;
> + }
> }
>
> - if (unlikely (NULL == itd)) {
> - iso_sched_free (stream, sched);
> - spin_unlock_irqrestore (&ehci->lock, flags);
> - return -ENOMEM;
> - }
> memset (itd, 0, sizeof *itd);
> itd->itd_dma = itd_dma;
> list_add (&itd->itd_list, &sched->td_list);
> --
> 1.5.3.8
>
-
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: USB enumeration process
On Feb 18, 2008 5:15 PM, Alan Stern <[EMAIL PROTECTED]> wrote: > On Mon, 18 Feb 2008, Felipe Balbi wrote: > > > Thanks Alan for the quick reply :-) > > what I really wanna know is when we match/bind drivers to usb_interfaces. > > That's in message.c:usb_set_configuration(). It occurs near the end of > that routine, in the call to device_add(). Thanks again Alan. -- Best Regards, Felipe Balbi [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
