- 25 Apr, 2008 40 commits
-
-
Alan Cox authored
Signed-off-by:
Alan Cox <alan@redhat.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@suse.de>
-
Alan Cox authored
Signed-off-by:
-
Alan Cox authored
Signed-off-by:
-
Alan Cox authored
Signed-off-by:
-
Alan Cox authored
Signed-off-by:
-
Alan Cox authored
The ftdi_sio driver has no internal locking on the dtr/rts state. Flag that up for someone to fix. Signed-off-by:
-
Alan Cox authored
Take the lock in usb-serial instead. As it relies on the BKL internally we can't push it any deeper yet. Signed-off-by:
-
Karsten Wiese authored
Remove two (or one) conditional tests in per-urb isochronous transfer setup code paths. Signed-off-by:
Karsten Wiese <fzu@wemgehoertderstaat.de> Signed-off-by:
David Brownell <dbrownell@users.sourceforge.net> Signed-off-by:
-
matthias@kaehlcke.net authored
The semaphore ccp->mutex is used as mutex, convert it to the mutex API Signed-off-by:
Matthias Kaehlcke <matthias@kaehlcke.net> Cc: Wolfgang Mües <wolfgang@iksw-muees.de> Signed-off-by:
-
matthias@kaehlcke.net authored
The semaphore ccp->readmutex is used as mutex, convert it to the mutex API Signed-off-by:
-
matthias@kaehlcke.net authored
The semaphore cp->mutex is used as mutex, convert it to the mutex API Signed-off-by:
-
Mike Isely authored
The cypress app note for the M8 states that for the USB low speed version of the part, throughput is effectively limited to 800 bytes/sec. So if we were to try a faster baud rate in such cases then we risk overrun errors on receive. Best to just identify this case and limit the rate to 4800 baud or less (by ignoring any request to set a faster rate). The old baud rate setting code was somewhat fragile; this change also hopefully makes it easier in the future to better checking / limiting. Signed-off-by:
Mike Isely <isely@pobox.com> Signed-off-by:
-
Mike Isely authored
Remove a NULL check in cypress_m8; the check is useless in this context because it is referenced earlier in the same code path thus the kernel would be oops'ed before reaching this point anyway. (And it's really pointless here anyway; if this pointer somehow is NULL the driver is going to have serious problems in many other places.) Signed-off-by:
-
Mike Isely authored
Earthmate LT-20 devices (both "old" and "new" versions) can't tolerate a GET_CONFIG command. The original Earthmate has no trouble with this. Presumably other non-Earthmate devices are still OK as well. This change disables the use of GET_CONFIG for cases where it is known not to work. Signed-off-by:
-
Mike Isely authored
cypress_m8: Packet format is separate from characteristic size The Cypress app note states that when using an 8 byte packet buffer size that the packet format is modified (to be more compact). However I have since discovered that newer DeLorme Earthmate LT-20 devices (those that are low speed USB with 8 byte packet size) STILL use the format that is really supposed to correspond to 32 byte packets. Further confusing things is the subsequent discovery that there are actually two different types of LT-20 - older LT-20's use 32 byte packets which is probably why this issue wasn't originally encountered. The solution here is to flag the packet format separately from the buffer size. Then at initialization time, identify the correct combination and set it up. This is a critical fix for anyone with a newer LT-20. Older devices and non-Earthmate devices should remain unaffected by this change. (If other devices behave in this, uh, unexpected manner, it's now just a simple 1 line change to fix them as well (change the pkt_fmt member for that device). Default behavior with this patch is still to drive the format as per the app-note; of course for Earthmate devices this is overridden. Signed-off-by:
-
Mike Isely authored
cypress_m8: Feature buffer fixes From: Mike Isely <isely@pobox.com> Don't hardcode the feature buffer size; use sizeof() instead. That way we can easily specify the size in a single spot. Speaking of the feature buffer size, the Cypress app note (and further testing with a DeLorme Earthmate) suggests that this size should be 5 not 8 bytes. Signed-off-by:
-
Andrew Morton authored
These strings always come up as false positives whenever I'm doing git-conflict fixups (ie: about 1000 times/day). I don't think the zillion "<" and ">" characters are very useful and removing them makes my life that little bit easier. Signed-off-by:
Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
-
Savin Zlobec authored
On USB cable disconnect g_serial doesn't hangup the port tty, which results in an endless read on the tty device. With the following patch the read and select behave correctly when the cable is unplugged. Tested on at91rm9200 Signed-off-by:
Savin Zlobec <savin@epiko.si> Signed-off-by:
-
Karsten Wiese authored
Refactor the EHCI "if (handshake()) state = HC_STATE_HALT" idiom, which appears 4 times, by replacing it with calls to a new function called handshake_on_error_set_halt(). Saves a few bytes too. Signed-off-by:
-
Paul Mundt authored
Poking around with pahole, we see that m66592 handily shoves a u16 in between larger types on 2 separate occasions leaving us with 2 2-byte holes: struct m66592 { ... /* size: 1196, cachelines: 38 */ /* sum members: 1192, holes: 2, sum holes: 4 */ /* last cacheline: 12 bytes */ }; /* definitions: 1 */ Pairing them gets back 4-bytes: struct m66592 { ... /* size: 1192, cachelines: 38 */ /* last cacheline: 8 bytes */ }; /* definitions: 1 */ Unfortunately it's not enough to save a cacheline with this massive structure, but every byte helps. Signed-off-by:Paul Mundt <lethal@linux-sh.org> Signed-off-by:
Yoshihiro Shimoda <shimoda.yoshihiro@renesas.com> Signed-off-by:
-
David Brownell authored
Various minor fixes to some SOC bus glue for EHCI: - Remove a bogus copyright (by "me"!) which someone added to the FSL driver, and an irrelevant comment. - Un-break MODULE_ALIAS() directives after platform_bus hotplugging acquired a backwards-incompatible change. (Which didn't fix ANY of the in-tree drivers it prevented from hotplugging -- sigh.) - Remove some bogus assignments of platform_bus_type; that's done by the platform_bus code. - Add some FIXMEs for drivers with that pointless two-level idiom for probe() and remove() routines. ("Obfuscation" is a non-goal.) That should help avoid future bus glue which copies that idiom. Signed-off-by: -
David Brownell authored
This teaches EHCI how to to work around bugs in certain high speed devices, by accomodating "bulk" packets that exceed the 512 byte constant value required by the USB 2.0 specification. (Have a look at section 5.8.3, paragraphs 1 and 3.) It also makes the descriptor parsing code warn when it encounters such bugs. (We've had reports of maybe two or three such devices, all pretty recent.) Such devices are nonconformant. The proper fix is have the vendors of those devices do the simple, obvious, and correct thing ... which will let them be used with USB hosts that don't have workarounds for this particular vendor bug. But unless/until they do, we can at least have one of the high speed HCDs work with such buggy devices. Signed-off-by:
-
David Brownell authored
This limits how long the OHCI port reset loop waits for the hardware to do its job, if the controller either (a) dies, or (b) can't finish the reset. Such limits are always a good idea. Signed-off-by:
-
David Brownell authored
Minor cleanups to the EHCI code: revision history is what source code repositories should have. Switch to a more standard way to kick in verbose debugging -- don't be EHCI-specific. Signed-off-by:
-
David Brownell authored
There's a new PM-related change notice for the USB 2.0 specification called "Link Power Management" (LPM). It defines a new "L1 Suspend" state which resembles the current (L2) suspend state, except that it can be entered and exited much more quickly. It should thus be more useful for runtime PM, even though it doesn't mandate reduced power draw from VBUS. This patch provides the relevant #defines for usbcore. Actually implementing these mechanisms requires host silicon that can generate new USB packets, plus hubs handling some new requests and peripherals which understand the new packets. Signed-off-by:
-
Pavel Emelyanov authored
This is an attempt to kill two birds with one stone. First, we kill one more user of kernel_thread, which is scheduled for removal. Second - we kill one of the last users of kill_proc - the function which is also to be removed, because it uses a pid_t which is not safe now. Signed-off-by:
Pavel Emelyanov <xemul@openvz.org> Signed-off-by:
Duncan Sands <baldrick@free.fr> Signed-off-by:
-
Andrew Morton authored
Cc: Alan Stern <stern@rowland.harvard.edu> Cc: Magnus Damm <damm@igel.co.jp> Signed-off-by:
-
Adrian Bunk authored
As Torsten Kaiser pointed out, it seems the dependency of USB_STORAGE_ONETOUCH on !PM should have been removed in commit 7931e1c6. Signed-off-by:
Adrian Bunk <bunk@kernel.org> Cc: Matthew Dharm <mdharm-usb@one-eyed-alien.net> Cc: Alan Stern <stern@rowland.harvard.edu> Cc: Greg Kroah-Hartman <gregkh@suse.de> Cc: Torsten Kaiser <just.for.lkml@googlemail.com> Signed-off-by:
-
Daniel Walker authored
I converted the usu_init_notify semaphore to normal mutex usage, and it should still prevent the request_module before the init routine is complete. Before it acted more like a complete, now the mutex protects two distinct section from running at the same time. Signed-off-by:
Daniel Walker <dwalker@mvista.com> Cc: Pete Zaitcev <zaitcev@redhat.com> Signed-off-by:
-
Daniel Walker authored
No current references, so removing it. Signed-off-by:
-
Randy Dunlap authored
Convert struct usb_device to use kernel-doc notation. Please especially check the @filelist and @usb_classdev descriptions. Signed-off-by:
Randy Dunlap <randy.dunlap@oracle.com> Cc: Alan Stern <stern@rowland.harvard.edu> Signed-off-by:
-
Greg Kroah-Hartman authored
This is needed by the wireless usb developers, and is part of the USB spec. Cc: Inaky Perez-Gonzalez <inaky.perez-gonzalez@intel.com> Signed-off-by: -
Greg Kroah-Hartman authored
usb_free_urb() can take a NULL, so let's check and warn about that. Signed-off-by: -
Alan Stern authored
This patch (as1052) enables USB-PERSIST for all devices by default. The user won't have to remember to enable it explicitly for devices containing mounted filesystems. Eventually userspace tools like hal may be able to set the persist attribute automatically when a filesystem is mounted on a USB device. When that time comes this patch can be reverted, if people think it matters. This approach has the advantage of giving the user the ability to turn off USB-PERSIST for devices with mounted filesystems, rather than making the kernel always assume it should be on. Signed-off-by:
Alan Stern <stern@rowland.harvard.edu> Signed-off-by:
-
Alan Stern authored
This patch (as1048) extends the descriptor checking after a device is reset. Now the SerialNumber string descriptor is compared to its old value, in addition to the device and configuration descriptors. As a consequence, the kmalloc() call in usb_string() is now on the error-handling pathway for usb-storage. Hence its allocation type is changed to GFO_NOIO. Signed-off-by:
-
Alan Stern authored
This patch (as1047) removes the USB_PERSIST Kconfig option, enabling it permanently. It also prevents the power/persist attribute from being created for hub devices; there's no point in having it since USB-PERSIST is always turned on for hubs. Signed-off-by:
-
Alan Stern authored
This patch (as1046) makes USB-PERSIST work more in accordance with the documentation. Currently it takes effect only in cases where the root hub has lost power or been reset, but it is supposed to operate whenever a power session was dropped during a system sleep. A new hub_restart() routine carries out the duties required during a reset or a reset-resume. It checks to see whether occupied ports are still enabled, and if they aren't then it clears the enable-change and connect-change features (to prevent interference by khubd) and sets the child device's reset_resume flag. It also checks ports that are supposed to be unoccupied to verify that the firmware hasn't left the port in an enabled state. Signed-off-by:
-
Alan Stern authored
This patch (as1045) reorganizes some code in the hub driver. hub_port_status() is moved earlier in the file, and a new hub_stop() routine is created to do the work currently in hub_preset() (i.e., disconnect all child devices and quiesce the hub). There are no functional changes. Signed-off-by:
-
Alan Stern authored
This patch (as1044) causes EHCI port handover for non-high-speed devices to occur during every root-hub resume, not just in cases where the controller lost power or was reset. This is necessary because: When some machines go into suspend, they remove power from on-board USB devices while retaining suspend current for USB controllers. The user might well unplug a USB device while the system is suspended and then plug it back in before resuming. A corresponding change is made to the core resume routine; now high-speed root hubs will always be resumed when the system wakes up, even if they were suspended before the system went to sleep. If this weren't done then EHCI port handover wouldn't work, since it is called when the EHCI root hub is resumed. Finally, a comment is added to the hub driver explaining the khubd has to be freezable; if it weren't frozen then it could interfere with port handover. Signed-off-by:
-
Stefan Seyfried authored
Add the HP hs2300 Broadband Wireless Module (relabeled MC8775) USB IDs Signed-off-by:
Stefan Seyfried <seife@suse.de> Cc: stable <stable@kernel.org> Signed-off-by:
-
