- 25 Apr, 2008 40 commits
-
-
Robert P. J. Day authored
Based on a recent discussion on the Linux USB mailing list, remove the designation of EXPERIMENTAL from some USB gadget entries, and tag some of them as DEVELOPMENT. just for fun, i added a bit of help for gadgetfs, explaining the race condition. Signed-off-by:
Robert P. J. Day <rpjday@crashcourse.ca> Acked-by:
David Brownell <dbrownell@users.sourceforge.net>
-
Robert P. J. Day authored
Since there seems to be little reason to mark the current USB storage features as "EXPERIMENTAL," remove that dependency. Signed-off-by:
Greg Kroah-Hartman <gregkh@suse.de>
-
matthieu castet authored
I have got a cypress usb-ide bridge and I would like to tune or monitor my disk with tools like hdparm, hddtemp or smartctl. My controller support a way to send raw ATA command to the disk with something call atacb (see http://download.cypress.com.edgesuite.net/design_resources/datasheets/contents/cy7c68300c_8.pdf). Atacb support can be added for each application, but there is some disadvantages : - all application need to be patched - A race is possible if there other accesses, because the emulation can be split in 2 atacb scsi transactions. One for sending the command, one for reading the register (if ck_cond is set). I have implemented the emulation in usb-storage with a special proto_handler, and an unsual entry. Signed-off-by:
Matthieu CASTET <castet.matthieu@free.fr> Signed-off-by:
Matthew Dharm <mdharm-usb@one-eyed-alien.net> Signed-off-by:
-
Robert P. J. Day authored
For the header files in include/linux/usb, add missing multiple inclusion protection and standardize what's already there. The apparent standards: * macro name of __LINUX_USB_headerfile_H * inclusion protection placed after leading comment block * macro name added as a comment on the final #endif * any obvious trivial whitespace cleanup associated with the above Signed-off-by:
-
Tilman Schmidt authored
The the err() / info() / warn() macros in usb.h inserted __FILE__ at the beginning of the message, which expands to the complete pathname of the source file within the kernel tree, frequently taking up half of an 80 character screen line before the actual message even begins. Use the module name instead. Signed-off-by:
Tilman Schmidt <tilman@imap.cc> Signed-off-by:
-
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:
-
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:
-
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:
-
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:
-
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:
-
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: -
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:
-
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:
-
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:
-
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
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:
-
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:
-
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:
-
