Commit 0ede76fc, "USB: remove uses of
URB_NO_SETUP_DMA_MAP" introduced a regression by inadvertantly removing
initialization of the transfer flags.  This caused initialization
failures in the ums-karma driver.  Fix the regression by zeroing it.

While at it, as Alan Stern points out, the initializers for
actual_length and status are handled by the core and error_count
only matters for isochronous urbs, so they don't need to be set here.
Remove them.
Signed-off-by: NBob Copeland <me@bobcopeland.com>
Acked-by: NAlan Stern <stern@rowland.harvard.edu>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

This patch (as1350) removes all usages of coherent buffers for USB
control-request setup-packet buffers.  There's no good reason to
reserve coherent memory for these things; control requests are hardly
ever used in large quantity (the major exception is firmware
transfers, and they aren't time-critical).  Furthermore, only seven
drivers used it.  We might as well always use streaming DMA mappings
for setup-packet buffers, and remove some extra complexity from
usbcore.

The DMA-mapping portion of hcd.c is currently in flux.  A separate
patch will be submitted to remove support for URB_NO_SETUP_DMA_MAP
after everything else settles down.  The removal should go smoothly,
as by then nobody will be using it.
Signed-off-by: NAlan Stern <stern@rowland.harvard.edu>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

include cleanup: Update gfp.h and slab.h includes to prepare for breaking implicit slab.h inclusion from percpu.h

percpu.h is included by sched.h and module.h and thus ends up being
included when building most .c files.  percpu.h includes slab.h which
in turn includes gfp.h making everything defined by the two files
universally available and complicating inclusion dependencies.

percpu.h -> slab.h dependency is about to be removed.  Prepare for
this change by updating users of gfp and slab facilities include those
headers directly instead of assuming availability.  As this conversion
needs to touch large number of source files, the following script is
used as the basis of conversion.

  http://userweb.kernel.org/~tj/misc/slabh-sweep.py

The script does the followings.

* Scan files for gfp and slab usages and update includes such that
  only the necessary includes are there.  ie. if only gfp is used,
  gfp.h, if slab is used, slab.h.

* When the script inserts a new include, it looks at the include
  blocks and try to put the new include such that its order conforms
  to its surrounding.  It's put in the include block which contains
  core kernel includes, in the same order that the rest are ordered -
  alphabetical, Christmas tree, rev-Xmas-tree or at the end if there
  doesn't seem to be any matching order.

* If the script can't find a place to put a new include (mostly
  because the file doesn't have fitting include block), it prints out
  an error message indicating which .h file needs to be added to the
  file.

The conversion was done in the following steps.

1. The initial automatic conversion of all .c files updated slightly
   over 4000 files, deleting around 700 includes and adding ~480 gfp.h
   and ~3000 slab.h inclusions.  The script emitted errors for ~400
   files.

2. Each error was manually checked.  Some didn't need the inclusion,
   some needed manual addition while adding it to implementation .h or
   embedding .c file was more appropriate for others.  This step added
   inclusions to around 150 files.

3. The script was run again and the output was compared to the edits
   from #2 to make sure no file was left behind.

4. Several build tests were done and a couple of problems were fixed.
   e.g. lib/decompress_*.c used malloc/free() wrappers around slab
   APIs requiring slab.h to be added manually.

5. The script was run on all .h files but without automatically
   editing them as sprinkling gfp.h and slab.h inclusions around .h
   files could easily lead to inclusion dependency hell.  Most gfp.h
   inclusion directives were ignored as stuff from gfp.h was usually
   wildly available and often used in preprocessor macros.  Each
   slab.h inclusion directive was examined and added manually as
   necessary.

6. percpu.h was updated not to include slab.h.

7. Build test were done on the following configurations and failures
   were fixed.  CONFIG_GCOV_KERNEL was turned off for all tests (as my
   distributed build env didn't work with gcov compiles) and a few
   more options had to be turned off depending on archs to make things
   build (like ipr on powerpc/64 which failed due to missing writeq).

   * x86 and x86_64 UP and SMP allmodconfig and a custom test config.
   * powerpc and powerpc64 SMP allmodconfig
   * sparc and sparc64 SMP allmodconfig
   * ia64 SMP allmodconfig
   * s390 SMP allmodconfig
   * alpha SMP allmodconfig
   * um on x86_64 SMP allmodconfig

8. percpu.h modifications were reverted so that it could be applied as
   a separate patch and serve as bisection point.

Given the fact that I had only a couple of failures from tests on step
6, I'm fairly confident about the coverage of this conversion patch.
If there is a breakage, it's likely to be something in one of the arch
headers which should be easily discoverable easily on most builds of
the specific arch.
Signed-off-by: NTejun Heo <tj@kernel.org>
Guess-its-ok-by: NChristoph Lameter <cl@linux-foundation.org>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: Lee Schermerhorn <Lee.Schermerhorn@hp.com>

Some devices must be switched to a new mode to fully use them.
A reset would make them revert to the old mode. Therefore a reset
must not be used for error handling with such devices.
Signed-off-by: NOliver Neukum <oliver@neukum.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

This patch (as1311) fixes a problem in usb-storage: Some devices are
pretty broken when it comes to reporting sense data.  The information
they send back indicates that they have more than 18 bytes of sense
data available, but when the system asks for more than 18 they fail or
hang.  The symptom is that probing fails with multiple resets.

The patch adds a new BAD_SENSE flag to indicate that usb-storage
should never ask for more than 18 bytes of sense data.  The flag can
be set in an unusual_devs entry or via the "quirks=" module parameter,
and it is set automatically whenever a REQUEST SENSE command for more
than 18 bytes fails or times out.

An unusual_devs entry is added for the Agfa photo frame, which uses a
Prolific chip having this bug.
Signed-off-by: NAlan Stern <stern@rowland.harvard.edu>
Tested-by: NDaniel Kukula <daniel.kuku@gmail.com>
Cc: stable <stable@kernel.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

usb-storage: Workaround devices with bogus sense size

Some devices, such as Huawei E169, advertise more than the standard
amount of sense data, causing us to set US_FL_SANE_SENSE, assuming
they support it. However, they subsequently fail the request sense
with that size.

This works around it generically. When a sense request fails due to
a device returning an error, US_FL_SANE_SENSE was set, and that sense
request used a larger sense size, we retry with a smaller size before
giving up.

Based on an original patch by Ben Efros <ben@pc-doctor.com>
Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
Acked-by: NAlan Stern <stern@rowland.harvard.edu>
Cc: stable <stable@kernel.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

This patch (as1294) fixes a problem that has plagued users for several
kernel releases.  Some USB mass-storage devices don't return any sense
data when they encounter certain kinds of errors.  The SCSI layer
interprets this to mean that the operation should be retried, and the
same thing happens -- over and over again with no limit.  In some
circumstances (such as when a bus reset occurs) that is the right
thing to do, but not here.

The patch checks for this condition (a transport failure with no sense
data) and changes the result code to DID_ERROR and the sense code to
Hardware Error.  This does get only a limited number of retries, and
so the command will fail relatively quickly instead of getting stuck
in an infinite loop.

This fixes a large part of Bugzilla #14118.
Signed-off-by: NAlan Stern <stern@rowland.harvard.edu>
Tested-by: NMantas Mikulenas <grawity@gmail.com>
CC: stable <stable@kernel.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

Requests to get max LUN, for certain USB storage devices, require a
longer timeout before a correct reply is returned. This happens for a
Realtek USB Card Reader (0bda:0152), which has a max LUN of 3 but is set
to 0, thus losing functionality, because of the timeout occurring too
quickly.

Raising the timeout value fixes the issue and might help other devices
to return a correct max LUN value as well.
Signed-off-by: NGiacomo Lozito <james@develia.org>
Acked-by: NAlan Stern <stern@rowland.harvard.edu>
Cc: stable <stable@kernel.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

Wireless USB endpoint state has a sequence number and a current
window and not just a single toggle bit.  So allow HCDs to provide a
endpoint_reset method and call this or clear the software toggles as
required (after a clear halt, set configuration etc.).

usb_settoggle() and friends are then HCD internal and are moved into
core/hcd.h and all device drivers call usb_reset_endpoint() instead.

If the device endpoint state has been reset (with a clear halt) but
the host endpoint state has not then subsequent data transfers will
not complete. The device will only work again after it is reset or
disconnected.
Signed-off-by: NDavid Vrabel <david.vrabel@csr.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

This patch (as1206) is the first step in converting usb-storage's
subdrivers into separate modules.  It makes the following large-scale
changes:

	Remove a bunch of unnecessary #ifdef's from usb_usual.h.
	Not truly necessary, but it does clean things up.

	Move the USB device-ID table (which is duplicated between
	libusual and usb-storage) into its own source file,
	usual-tables.c, and arrange for this to be linked with
	either libusual or usb-storage according to whether
	USB_LIBUSUAL is configured.

	Add to usual-tables.c a new usb_usual_ignore_device()
	function to detect whether a particular device needs to be
	managed by a subdriver and not by the standard handlers
	in usb-storage.

	Export a whole bunch of functions in usb-storage, renaming
	some of them because their names don't already begin with
	"usb_stor_".  These functions will be needed by the new
	subdriver modules.

	Split usb-storage's probe routine into two functions.
	The subdrivers will call the probe1 routine, then fill in
	their transport and protocol settings, and then call the
	probe2 routine.

	Take the default cases and error checking out of
	get_transport() and get_protocol(), which run during
	probe1, and instead put a check for invalid transport
	or protocol values into the probe2 function.

	Add a new probe routine to be used for standard devices,
	i.e., those that don't need a subdriver.  This new routine
	checks whether the device should be ignored (because it
	should be handled by ub or by a subdriver), and if not,
	calls the probe1 and probe2 functions.
Signed-off-by: NAlan Stern <stern@rowland.harvard.edu>
CC: Matthew Dharm <mdharm-usb@one-eyed-alien.net>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

The SUGGEST_* flags in the SCSI command result have been out of fashion
for a while and we don't actually use them in the error handling.
Remove the remaining occurrences.
Signed-off-by: NMartin K. Petersen <martin.petersen@oracle.com>
Signed-off-by: NJames Bottomley <James.Bottomley@HansenPartnership.com>

This patch (as1201) removes the WARN() from the last-sector hacks in
usb-storage, thereby making the code match the version now in
.27-stable and .28-stable.  The WARN() isn't needed, since there is no
longer any intention of assuming that all storage devices have an even
number of sectors, and it annoys users for no good reason.
Signed-off-by: NAlan Stern <stern@rowland.harvard.edu>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

This patch (as1189b) adds some hacks to usb-storage for dealing with
the growing problems involving bad capacity values and last-sector
accesses:

	A new flag, US_FL_CAPACITY_OK, is created to indicate that
	the device is known to report its capacity correctly.  An
	unusual_devs entry for Linux's own File-backed Storage Gadget
	is added with this flag set, since g_file_storage always
	reports the correct capacity and since the capacity need
	not be even (it is determined by the size of the backing
	file).

	An entry in unusual_devs.h which has only the CAPACITY_OK
	flag set shouldn't prejudice libusual, since the device will
	work perfectly well with either usb-storage or ub.  So a
	new macro, COMPLIANT_DEV, is added to let libusual know
	about these entries.

	When a last-sector access succeeds and the total number of
	sectors is odd (the unexpected case, in which guessing that
	the number is even might cause trouble), a WARN is triggered.
	The kerneloops.org project will collect these warnings,
	allowing us to add CAPACITY_OK flags for the devices in
	question before implementing the default-to-even heuristic.
	If users want to prevent the stack dump produced by the WARN,
	they can disable the hack by adding an unusual_devs entry
	for their device with the CAPACITY_OK flag.

	When a last-sector access fails three times in a row and
	neither the FIX_CAPACITY nor the CAPACITY_OK flag is set,
	we assume the last-sector bug is present.  We replace the
	existing status and sense data with values that will cause
	the SCSI core to fail the access immediately rather than
	retry indefinitely.  This should fix the difficulties
	people have been having with Nokia phones.
Signed-off-by: NAlan Stern <stern@rowland.harvard.edu>
Cc: stable <stable@kernel.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

This patch (as1173) merges usb-storage's CB and CBI transports into a
single routine.  So much of their code is common, it's silly to keep
them separate.
Signed-off-by: NAlan Stern <stern@rowland.harvard.edu>
CC: Matthew Dharm <mdharm-usb@one-eyed-alien.net>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

Add the SANE SENSE flag to indicate that a device is capable of handling
more than 18-bytes of sense data.  This functionality is required for
USB-ATA bridges implementing SAT.  A future patch will actually enable this
function for several devices.

The logic behind this is that we can detect support for SANE_SENSE in a few ways:
 1) ATA PASS THROUGH (12) or (16) execute successfully
 2) SPC-3 or higher is in use
 3) A previous CHECK CONDITION occurred with sense format 70-73 and had
    a length greater than 18-bytes total
Signed-off-by: NBen Efros <ben@pc-doctor.com>
Signed-off-by: NMatthew Dharm <mdharm-usb@one-eyed-alien.net>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

This patch (as1161) changes the interface to
usb_lock_device_for_reset().  The existing interface is apparently not
very clear, judging from the fact that several of its callers don't
use it correctly.  The new interface always returns 0 for success and
it always requires the caller to unlock the device afterward.

The new routine will not return immediately if it is called while the
driver's probe method is running.  Instead it will wait until the
probe is over and the device has been unlocked.  This shouldn't cause
any problems; I don't know of any cases where drivers call
usb_lock_device_for_reset() during probe.
Signed-off-by: NAlan Stern <stern@rowland.harvard.edu>
Cc: Pete Zaitcev <zaitcev@redhat.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

This patch (as1118) addresses a problem with certain USB mass-storage
devices.  These devices sometimes return less data than asked for and
then provide no sense data to explain the problem.  Currently
usb-storage leaves it up to the SCSI layer to decide how this should
be handled, and the SCSI layer interprets the lack of sense data to
mean that nothing went wrong.  But if we got less data than required
then something definitely _did_ go wrong, and we should say so.

The patch tells the SCSI layer to retry the command when this sort of
thing happens.  Retrying may not solve the underlying problem, but
it's better than believing that data was transferred when it wasn't.
Signed-off-by: NAlan Stern <stern@rowland.harvard.edu>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

This patch (as1119) will help to reduce the clutter of usb-storage's
unusual_devs file by automatically detecting some devices that need
the IGNORE_RESIDUE flag.  The idea is that devices should never return
a non-zero residue for an INQUIRY or a READ CAPACITY command unless
they failed to transfer all the requested data.  So if one of these
commands transfers a standard amount of data but there is a positive
residue, we know that the residue is bogus and we can set the flag.

This fixes the problems reported in Bugzilla #11125.
Signed-off-by: NAlan Stern <stern@rowland.harvard.edu>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

This patch renames the existing usb_reset_device in hub.c to
usb_reset_and_verify_device and renames the existing
usb_reset_composite_device to usb_reset_device. Also the new
usb_reset_and_verify_device does't need to be EXPORTED .

The idea of the patch is that external interface driver
should warn the other interfaces' driver of the same
device before and after reseting the usb device. One interface
driver shoud call _old_ usb_reset_composite_device instead of
_old_ usb_reset_device since it can't assume the device contains
only one interface. The _old_ usb_reset_composite_device
is safe for single interface device also. we rename the two
functions to make the change easily.

This patch is under guideline from Alan Stern.
Signed-off-by: NMing Lei <tom.leiming@gmail.com>

From the current implementation of usb_reset_composite_device
function, the iface parameter is no longer useful. This function
doesn't do something special for the iface usb_interface,compared
with other interfaces in the usb_device. So remove the parameter
and fix the related caller.
Signed-off-by: NMing Lei <tom.leiming@gmail.com>
Acked-by: NAlan Stern <stern@rowland.harvard.edu>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

This patch removes CVS keywords that weren't updated for a long time
from comments.
Signed-off-by: NAdrian Bunk <bunk@kernel.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

This patch (as1092) implements "soft" unbinding for usb-storage.  When
the disconnect routine is called, all commands and reset delays are
allowed to complete normally until after scsi_remove_host() returns.
This means that the commands needed for an orderly shutdown will be
sent through to the device.

Unlike before, the driver will now execute every command that it
accepts.  Hence there's no need for special code to catch unexecuted
commands and fail them.

The new sequence of events when disconnect runs goes as follows:

	If the device is truly unplugged, set the DISCONNECTING
	flag so we won't try to access it any more.

	If the SCSI-scanning thread hasn't started up yet, prevent
	it from doing anything by setting the new DONT_SCAN flag.
	Then wake it up and wait for it to terminate.

	Remove the SCSI host.  This unbinds the upper-level drivers,
	doing an orderly shutdown.  Commands sent to quiesce the
	device will be transmitted normally, unless the device is
	unplugged.

	Set the DISCONNECTING flag so that we won't accept any new
	commands that might get submitted (there aren't supposed to be
	any) and we won't try to access the device for resets.

	Tell the control thread to exit by waking it up with no
	pending command, and wait for it to terminate.

	Go on to do all the other normal stuff: releasing resources,
	freeing memory, and so on.
Signed-off-by: NAlan Stern <stern@rowland.harvard.edu>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

This patch (as1089) separates out the dynamic atomic bitflags and the
static bitfields in usb-storage.  Until now the two sorts of flags
have been sharing the same word; this has always been awkward.

To help prevent possible confusion, the two new fields each have a
different name from the original.  us->fflags contains the fixed
bitfields (mostly taken from the USB ID table in unusual_devs.h), and
us->dflags contains the dynamic atomic bitflags (used with set_bit,
test_bit, and so on).
Signed-off-by: NAlan Stern <stern@rowland.harvard.edu>
Cc: Matthew Dharm <mdharm-usb@one-eyed-alien.net>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

urb->context code cleanup
Signed-off-by: NMing Lei <tom.leiming@gmail.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

__FUNCTION__ is gcc-specific, use __func__
Signed-off-by: NHarvey Harrison <harvey.harrison@gmail.com>
Signed-off-by: NGreg 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: NMatthieu CASTET <castet.matthieu@free.fr>
Signed-off-by: NMatthew Dharm <mdharm-usb@one-eyed-alien.net>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

Motorola ROKR Z6 cellphone has bugs in its USB, so it is impossible to use
it as mass storage. Patch describes new "unusual" USB device for it with
FIX_INQUIRY and FIX_CAPACITY flags and new BULK_IGNORE_TAG flag.
Last flag relaxes check for equality of bcs->Tag and us->tag in
usb_stor_Bulk_transport routine.
Signed-off-by: NConstantin Baranov <const@tltsu.ru>
Signed-off-by: NMatthew Dharm <mdharm-usb@one-eyed-alien.net>
Signed-off-by: NDaniel Drake <dsd@gentoo.org>
Cc: stable <stable@kernel.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

This patch (as1032) removes the Clear-Halt calls in
usb_stor_Bulk_max_lun().  Evidently some devices (such as the Oracom
MP3 player) really don't like to receive these requests when their
bulk endpoints aren't halted.

The only reason for adding them originally was to get an ancient
ZIP-100 drive to work.  But since this device has only a single LUN,
we don't need to send it a Get-Max-LUN request at all.  Adding an
unusual_devs entry for the ZIP-100 with the SINGLE_LUN flag set will
cause this step to be skipped.
Signed-off-by: NAlan Stern <stern@rowland.harvard.edu>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

  - This patch depends on:
    usb: transport.c use scsi_eh API in REQUEST_SENSE execution

  - Use scsi data accessors and remove of !use_sg code path.
  - New usb_stor_bulk_srb() for use by drivers

[jejb: updated with corrective fix.

had a bug in residual handling in the new usb_stor_bulk_srb()
function.  Found by Gabriel C. in -mm tree.
Tested-by: NGabriel C <nix.or.die@googlemail.com>
]
Signed-off-by: NBoaz Harrosh <bharrosh@panasas.com>
Acked-by: NMatthew Dharm <mdharm-scsi@one-eyed-alien.net>
Signed-off-by: NJames Bottomley <James.Bottomley@HansenPartnership.com>

  - Use new scsi_eh_prep/restor_cmnd() for synchronous
    REQUEST_SENSE invocation.
Signed-off-by: NBoaz Harrosh <bharrosh@panasas.com>
Acked-by: NAlan Stern <stern@rowland.harvard.edu>
Signed-off-by: NJames Bottomley <James.Bottomley@SteelEye.com>

SLAB_NOIO is an alias of GFP_NOIO with a single instance of use.
Signed-off-by: NChristoph Lameter <clameter@sgi.com>
Signed-off-by: NAndrew Morton <akpm@osdl.org>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

Maintain a per-CPU global "struct pt_regs *" variable which can be used instead
of passing regs around manually through all ~1800 interrupt handlers in the
Linux kernel.

The regs pointer is used in few places, but it potentially costs both stack
space and code to pass it around.  On the FRV arch, removing the regs parameter
from all the genirq function results in a 20% speed up of the IRQ exit path
(ie: from leaving timer_interrupt() to leaving do_IRQ()).

Where appropriate, an arch may override the generic storage facility and do
something different with the variable.  On FRV, for instance, the address is
maintained in GR28 at all times inside the kernel as part of general exception
handling.

Having looked over the code, it appears that the parameter may be handed down
through up to twenty or so layers of functions.  Consider a USB character
device attached to a USB hub, attached to a USB controller that posts its
interrupts through a cascaded auxiliary interrupt controller.  A character
device driver may want to pass regs to the sysrq handler through the input
layer which adds another few layers of parameter passing.

I've build this code with allyesconfig for x86_64 and i386.  I've runtested the
main part of the code on FRV and i386, though I can't test most of the drivers.
I've also done partial conversion for powerpc and MIPS - these at least compile
with minimal configurations.

This will affect all archs.  Mostly the changes should be relatively easy.
Take do_IRQ(), store the regs pointer at the beginning, saving the old one:

	struct pt_regs *old_regs = set_irq_regs(regs);

And put the old one back at the end:

	set_irq_regs(old_regs);

Don't pass regs through to generic_handle_irq() or __do_IRQ().

In timer_interrupt(), this sort of change will be necessary:

	-	update_process_times(user_mode(regs));
	-	profile_tick(CPU_PROFILING, regs);
	+	update_process_times(user_mode(get_irq_regs()));
	+	profile_tick(CPU_PROFILING);

I'd like to move update_process_times()'s use of get_irq_regs() into itself,
except that i386, alone of the archs, uses something other than user_mode().

Some notes on the interrupt handling in the drivers:

 (*) input_dev() is now gone entirely.  The regs pointer is no longer stored in
     the input_dev struct.

 (*) finish_unlinks() in drivers/usb/host/ohci-q.c needs checking.  It does
     something different depending on whether it's been supplied with a regs
     pointer or not.

 (*) Various IRQ handler function pointers have been moved to type
     irq_handler_t.
Signed-Off-By: NDavid Howells <dhowells@redhat.com>
(cherry picked from 1b16e7ac850969f38b375e511e3fa2f474a33867 commit)

The purpose of this patch is to split off the case when a device does
not reply on the lower level (which is reported by HC hardware), and
a case when the device accepted the request, but does not reply at
upper level. This redefinition allows to diagnose issues easier,
without asking the user if the -110 happened "immediately".

The usbmon splits such cases already thanks to its timestamp, but
it's not always available.

I adjusted all drivers which I found affected (by searching for "urb").
Out of tree drivers may suffer a little bit, but I do not expect much
breakage. At worst they may print a few messages.
Signed-off-by: NPete Zaitcev <zaitcev@redhat.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

We all failed to notice that Franck's recent update to usb-storage allowed
an URB to complete after its context data was no longer valid.  This patch
(as746) makes the driver wait for the URB to complete whenever there's a
timeout.

Although timeouts in usb-storage are relatively uncommon, they do occur.
Without this patch the code in 2.6.18-rc1 will fault within an interrupt
handler, which is not nice at all.
Signed-off-by: NAlan Stern <stern@rowland.harvard.edu>
Cc: Greg KH <greg@kroah.com>
Signed-off-by: NAndrew Morton <akpm@osdl.org>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

Signed-off-by: NJörn Engel <joern@wohnheim.fh-wedel.de>
Signed-off-by: NAdrian Bunk <bunk@stusta.de>

This patch (as701) modifies usb-storage to take advantage of the new
usb_reset_composite_device() API.  Now we will be able to safely request
port resets even if other drivers are bound to a mass-storage device.
Signed-off-by: NAlan Stern <stern@rowland.harvard.edu>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

This patch uses completion timeout instead of a timer to implement
a timeout when submitting an URB.

It also put the task in interruptible state instead of an
uninterruptible one while waiting for the completion.
Signed-off-by: NFranck Bui-Huu <vagabon.xyz@gmail.com>
Signed-off-by: NMatthew Dharm <mdharm-usb@one-eyed-alien.net>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

This patch is from Alan Stern (as560).  It has been rediffed against a
current tree.

This patch allocates a separate buffer for usb-storage to use when
auto-sensing.  Up to now we have been using the sense buffer embedded in a
scsi_cmnd struct, which is dangerous on hosts that (a) don't do
cache-coherent DMA or (b) have DMA alignment restrictions.
Signed-off-by: NAlan Stern <stern@rowland.harvard.edu>
Signed-off-by: NMatthew Dharm <mdharm-usb@one-eyed-alien.net>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

This patch is originally from Alan Stern (as557).  It has been re-diffed
against a current tree, and I also corrected a minor merging error.

Some time ago we introduced a delay before device scanning, because many
devices do not like to receive SCSI commands right after enumeration.
Now it turns out there's a device that doesn't like to receive
Get-Max-LUN right after enumeration either.  Accordingly this patch
delays the Get-Max-LUN request until the beginning of the scanning
procedure.  This fixes Bugzilla entry #5010.

Three things are worth noting.  First, I removed the locking code from
usb_stor_acquire_resources.  It's not needed, because the locking is to
protect against disconnect events and acquire_resources is only called
during probe (so the disconnect routine can't be called).  Second, I
initialized to 0 the buffer used for the Get-Max-LUN response.  It's not
really necessary, but it will prevent random values from showing up in
the debugging log when the request fails.  Third, I added a test against
the SINGLE_LUN flag.  This will allow us to use the flag to indicate
Bulk-only devices that can't handle Get-Max-LUN.
Signed-off-by: NAlan Stern <stern@rowland.harvard.edu>
Signed-off-by: NMatthew Dharm <mdharm-usb@one-eyed-alien.net>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

29 July 2005, Cambridge, MA:

This afternoon Alan Stern submitted a patch to remove the URB_ASYNC_UNLINK
flag from the Linux kernel.  Mr. Stern explained, "This flag is a relic
from an earlier, less-well-designed system.  For over a year it hasn't
been used for anything other than printing warning messages."

An anonymous spokesman for the Linux kernel development community
commented, "This is exactly the sort of thing we see happening all the
time.  As the kernel evolves, support for old techniques and old code can
be jettisoned and replaced by newer, better approaches.  Proprietary
operating systems do not have the freedom or flexibility to change so
quickly."

Mr. Stern, a staff member at Harvard University's Rowland Institute who
works on Linux only as a hobby, noted that the patch (labelled as548) did
not update two files, keyspan.c and option.c, in the USB drivers' "serial"
subdirectory.  "Those files need more extensive changes," he remarked.
"They examine the status field of several URBs at times when they're not
supposed to.  That will need to be fixed before the URB_ASYNC_UNLINK flag
is removed."

Greg Kroah-Hartman, the kernel maintainer responsible for overseeing all
of Linux's USB drivers, did not respond to our inquiries or return our
calls.  His only comment was "Applied, thanks."
Signed-off-by: NAlan Stern <stern@rowland.harvard.edu>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>