- 25 Apr, 2008 40 commits
-
-
Andrew Morton authored
drivers/usb/core/devio.c: In function 'proc_control': drivers/usb/core/devio.c:657: warning: comparison is always false due to limited range of data type Cc: Alan Stern <stern@rowland.harvard.edu> Cc: Pete Zaitcev <zaitcev@redhat.com> Cc: Oliver Neukum <oliver@neukum.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
-
Alan Cox authored
The recent changes to this driver cleaned it up a lot, follow that up by sorting the speed side of things out as well Signed-off-by: Alan Cox <alan@redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
-
David Brownell authored
Some EHCI fault paths with large control transfers aren't coded. Avoid problems by rejecting transfers that may need two qTDs (16+ KB). This is mostly paranoia; even 4 KB transfers are rare, and most HCDs use lower limits (so it's unlikely anyone would ever try such a thing). Signed-off-by: David Brownell <dbrownell@users.sourceforge.net> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
-
Alan Stern authored
power.power_state is scheduled for removal. This patch (as1053) removes all uses of that field from drivers/usb. Almost all of them were write-only, the most significant exceptions being sl811-hcd.c and u132-hcd.c. Part of this patch was written by Pavel Machek. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Cc: David Brownell <david-b@pacbell.net> Acked-by: Pavel Machek <pavel@ucw.cz> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
-
Matthias Geissert authored
The ipaq module supports devices with one endpoint only. Some devices, e.g. Yakumo Delta 300, have more than one endpoint. This patch fixes support for devices having up to 2 endpoints which used to work on older kernel versions. Signed-off-by: Matthias Geissert <matthias.geissert@web.de> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
-
David Brownell authored
It was pointed out that we found and fixed the cause of the "bogus" fatal IRQ reports some time ago ... this patch removes the code which was working around that bug ("status" got clobbered), and a comment which needlessly confused folk reading this code. This also includes a minor cleanup to the code which fixed that bug. Signed-off-by: David Brownell <dbrownell@users.sourceforge.net> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
-
Robin Getz authored
This provides better support for USB "Embedded Host" functionality, which is a subset of the USB OTG options: * External hub support can be disabled; * USB peripherals not whitelisted in "otg_whitelist.h" will be rejected during enumeration. These options can allow some savings in software and support. Signed-off-by: Robin Getz <rgetz@blackfin.uclinux.org> Signed-off-by: David Brownell <dbrownell@users.sourceforge.net> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
-
Ray Lee authored
The Coverity checker (and Adrian Bunk) spotted an inconsistent NULL check of port->tty (it's blindly dereferenced later without the check). Alan Cox confirmed the check can go. Signed-off-by: Ray Lee <ray-lk@madrabbit.org> Cc: Adrian Bunk <bunk@kernel.org> Cc: Alan Cox <alan@lxorguk.ukuu.org.uk> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
-
Julia Lawall authored
The kernel.h macro DIV_ROUND_UP performs the computation (((n) + (d) - 1) / (d)) but is perhaps more readable. An extract of the semantic patch that makes this change is as follows: (http://www.emn.fr/x-info/coccinelle/) // <smpl> @haskernel@ @@ #include <linux/kernel.h> @depends on haskernel@ expression n,d; @@ ( - (n + d - 1) / d + DIV_ROUND_UP(n,d) | - (n + (d - 1)) / d + DIV_ROUND_UP(n,d) ) @depends on haskernel@ expression n,d; @@ - DIV_ROUND_UP((n),d) + DIV_ROUND_UP(n,d) @depends on haskernel@ expression n,d; @@ - DIV_ROUND_UP(n,(d)) + DIV_ROUND_UP(n,d) // </smpl> Signed-off-by: Julia Lawall <julia@diku.dk> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
-
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 <alan@redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
-
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 <alan@redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
-
Alan Cox authored
Signed-off-by: Alan Cox <alan@redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
-
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 <alan@redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
-
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: Alan Cox <alan@redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
-
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: Greg Kroah-Hartman <gregkh@suse.de>
-
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: Greg Kroah-Hartman <gregkh@suse.de>
-
matthias@kaehlcke.net authored
The semaphore ccp->readmutex 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: Greg Kroah-Hartman <gregkh@suse.de>
-
matthias@kaehlcke.net authored
The semaphore cp->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: Greg Kroah-Hartman <gregkh@suse.de>
-
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: Greg Kroah-Hartman <gregkh@suse.de>
-
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 <isely@pobox.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
-
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 <isely@pobox.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
-
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 <isely@pobox.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
-
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: Mike Isely <isely@pobox.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
-
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: Greg Kroah-Hartman <gregkh@suse.de>
-
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: David Brownell <dbrownell@users.sourceforge.net> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
-
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: Karsten Wiese <fzu@wemgehoertderstaat.de> Signed-off-by: David Brownell <dbrownell@users.sourceforge.net> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
-
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: Greg Kroah-Hartman <gregkh@suse.de>
-
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 <dbrownell@users.sourceforge.net> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
-
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 <dbrownell@users.sourceforge.net> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
-
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 <dbrownell@users.sourceforge.net> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
-
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 <dbrownell@users.sourceforge.net> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
-
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: David Brownell <dbrownell@users.sourceforge.net> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
-
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: Greg Kroah-Hartman <gregkh@suse.de>
-
Andrew Morton authored
Cc: Alan Stern <stern@rowland.harvard.edu> Cc: Magnus Damm <damm@igel.co.jp> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
-
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: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
-
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: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
-
Daniel Walker authored
No current references, so removing it. Signed-off-by: Daniel Walker <dwalker@mvista.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
-
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 <gregkh@suse.de>
-