Since nothing under the USB serial/ directory seems to be obviously
experimental, remove the EXPERIMENTAL dependency from all of those
Kconfig entries.
Signed-off-by: Robert P. J. Day <rpjday@crashcourse.ca>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Since nothing under the USB misc/ seems to be obviously experimental,
remove the EXPERIMENTAL dependency from those Kconfig entries.
Signed-off-by: Robert P. J. Day <rpjday@crashcourse.ca>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
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>
Since there seems to be little reason to mark the current USB storage
features as "EXPERIMENTAL," remove that dependency.
Signed-off-by: Robert P. J. Day <rpjday@crashcourse.ca>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
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: Greg Kroah-Hartman <gregkh@suse.de>
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: Robert P. J. Day <rpjday@crashcourse.ca>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
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: Greg Kroah-Hartman <gregkh@suse.de>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
As Torsten Kaiser pointed out, it seems the dependency of
USB_STORAGE_ONETOUCH on !PM should have been removed in commit
7931e1c6f8.
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>
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>
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>
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>
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 <gregkh@suse.de>
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: Greg Kroah-Hartman <gregkh@suse.de>
