[SCSI] add missing scan mutex to scsi_scan_target()

This patch (as543) adds a private entry point to scsi_scan_target, for use
when the caller already owns the scan_mutex, and updates the kerneldoc for
that routine (which was badly out-of-date).  It converts scsi_scan_channel
to use the new entry point.  Lastly, it modifies scsi_get_host_dev to make
it acquire the scan_mutex, necessary since the routine adds a new
scsi_device even if it doesn't do any actual scanning.

Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: James Bottomley <James.Bottomley@SteelEye.com>
[SCSI] fix callers of scsi_remove_device() who already hold the scan muted

This patch (as544) adds a private entry point to scsi_remove_device, for
use when callers already own the scan_mutex.  The appropriate callers are
modified to use the new entry point.

Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: James Bottomley <James.Bottomley@SteelEye.com>
[SCSI] fix possible deadlock in scsi_lib.c

  If a filesystem, while writing out data, decides that it is good
to issue a cache flush on a SCSI drive (or other 'sd' device), it will
call blkdev_issue_flush which calls ->issue_flush_fn which is
scsi_issue_flush_fn.
This calls sd_issue_flush which calls sd_sync_cache, which calls
scsi_execute_request.
This will (as sshdr != NULL) call
    kmalloc(SCSI_SENSE_BUFFERSIZE, GFP_KERNEL)

If memory is tight, the presence of GFP_KERNEL may cause write
requests to be sent to some filesystem to free up memory, however if
that filesystem is waiting for the issue_flush_fn to complete, you
could get a deadlock.

I wonder if it might be more appropriate to use GFP_NOIO as in the
following patch.

I wonder if it might be even more appropriate to cope better with a
kmalloc failure, especially as in this use, sd_sync_cache only will
use the sense information to print out a more informative error
message.

Signed-off-by: Neil Brown <neilb@suse.de>
Signed-off-by: James Bottomley <James.Bottomley@SteelEye.com>
[SCSI] SCSI core: fix leakage of scsi_cmnd's

From: 	Alan Stern <stern@rowland.harvard.edu>

This patch (as559b) adds a new routine, scsi_unprep_request, which
gets called every place a request is requeued.  (That includes
scsi_queue_insert as well as scsi_requeue_command.)  It also changes
scsi_kill_requests to make it call __scsi_done with result equal to
DID_NO_CONNECT << 16.  (I'm not sure if it's necessary to call
scsi_init_cmd_errh here; maybe you can check on that.)  Finally, the
patch changes the return value from scsi_end_request, to avoid
returning a stale pointer in the case where the request was requeued.
Fortunately the return value is used in only place, and the change
actually simplified it.

Signed-off-by: Alan Stern <stern@rowland.harvard.edu>

Rejections fixed up and
Signed-off-by: James Bottomley <James.Bottomley@SteelEye.com>
[PATCH] updated hdaps driver.

Driver for the IBM Hard Drive Active Protection System (HDAPS), an
accelerometer found in most modern ThinkPads.

Signed-off-by: Robert Love <rml@novell.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
[PATCH] aoe [1/2]: support 16 AoE slot addresses per AoE shelf

Change the number of supported AoE slot addresses per AoE shelf
address to 16.

Signed-off-by: Ed L. Cashin <ecashin@coraid.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
[PATCH] aoe [2/2]: update driver version number to twelve

Update driver version number to twelve.

Signed-off-by: Ed L. Cashin <ecashin@coraid.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
[PATCH] printk : Documentation/firmware_class/firmware_sample_driver.c

printk() calls should include appropriate KERN_* constant.

Signed-off-by: Christophe Lucas <clucas@rotomalug.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Merge gregkh@master.kernel.org:/pub/scm/linux/kernel/git/gregkh/driver-2.6
[SCSI] SCSI core: fix leakage of scsi_cmnd's

Actually, just one problem and one cosmetic fix:

1) We need to dequeue for the loop and kill case (it seems easiest
simply to dequeue in the scsi_kill_request() routine)
2) There's no real need to drop the queue lock.  __scsi_done() is lock
agnostic, so since there's no requirement, let's just leave it in to
avoid any locking issues.

Signed-off-by: James Bottomley <James.Bottomley@SteelEye.com>
[PATCH] hwmon: fix sis5595, via686a force_addr module parameter

Recent changes to the i2c-isa design broke the force_addr parameter of
two hardware monitoring drivers as a side effect: sis5595 and via686a.
The last address test was in fact useless beforehand, and the redesign
turned it into a bug. I'm sorry about that.

Signed-off-by: Jean Delvare <khali@linux-fr.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
[PATCH] hwmon: Update smsc47m1 head comment

Update the head comment of the smsc47m1 driver to mention all the
supported devices.

Signed-off-by: Jean Delvare <khali@linux-fr.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
[PATCH] hwmon: w83627hf: no reset by default

Make the reset of the chips in w83627hf optional rather than the
default. This reset has been causing trouble several times already. It
may even go completely away unless it proves to be useful to at least
one user.

Closes bug #5168:
http://bugzilla.kernel.org/show_bug.cgi?id=5168

Signed-off-by: Jean Delvare <khali@linux-fr.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
[PATCH] I2C: i2c-nforce2: drop unused define

One more cleanup in i2c-nforce2.

Signed-off-by: Jean Delvare <khali@linux-fr.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
[SCSI] sg: do not set VM_IO flag on mmap-ed pages

Further to the problem discussed in this post:
http://marc.theaimsgroup.com/?l=linux-scsi&m=112540053711489&w=2

It seems that the sg driver does not need to set the VM_IO flag
on pages that it memory maps to the user space since they are
not from the IO space. Ahmed Teirelbar <ahmed.teirelbar@adic.com>
wants the facility and has tested this patch as I have without
adverse effects.

The oops protection is still important. Some users really did
try and use dio transfers from the sg driver to memory mapped
IO space (on a video capture card if my memory serves) during the
lk 2.4 series. I'm not sure how successful it was but that will
now be politely refused in lk 2.6.13+ .

Changelog:
   - set the page flags for sg's reserved buffer mmap-ed
     to the user space to VM_RESERVED (rather than
     VM_RESERVED | VM_IO )

Signed-off-by: Douglas Gilbert <dougg@torque.net>
Signed-off-by: James Bottomley <James.Bottomley@SteelEye.com>
[SCSI] permit READ DEFECT DATA in block/scsi_ioctl

The soon to be released smartmontools 5.34 uses the
READ DEFECT DATA command on SCSI disks. A disk that
has defect list entries (or worse, an increasing number
of them) is at risk.

Currently the first invocation of smartctl causes this:
   scsi: unknown opcode 0x37
message to appear the console and in the log.

The READ DEFECT DATA SCSI command does not change
the state of a disk. Its opcode (0x37) is valid for
SBC devices (e.g. disks) and SMC-2 devices (media
changers) where it is called INITIALIZE STATUS ELEMENT
WITH RANGE and again doesn't change the external state
of the device.

Changelog:
  - mark SCSI opcode 0x37 (READ DEFECT DATA) as
    safe_for_read

Signed-off-by: Douglas Gilbert <dougg@torque.net>
Acked-by: Jens Axboe <axboe@suse.de>
Signed-off-by: James Bottomley <James.Bottomley@SteelEye.com>
[SCSI] SAS transport class

The SAS transport class contains common code to deal with SAS HBAs, an
aproximated representation of SAS topologies in the driver model,
and various sysfs attributes to expose these topologies and managment
interfaces to userspace.

In addition to the basic SCSI core objects this transport class introduces
two additional intermediate objects:  The SAS PHY as represented by struct
sas_phy defines an "outgoing" PHY on a SAS HBA or Expander, and the SAS
remote PHY represented by struct sas_rphy defines an "incoming" PHY on a
SAS Expander or end device.  Note that this is purely a software concept, the
underlying hardware for a PHY and a remote PHY is the exactly the same.

There is no concept of a SAS port in this code, users can see what PHYs
form a wide port based on the port_identifier attribute, which is the same
for all PHYs in a port.

This submission doesn't handle hot-plug addition or removal of SAS devices
and thus doesn't do scanning in a workqueue yet, that will be added in
phase2 after this submission.  In a third phase I will add additional
managment infrastructure.

I think this submission is ready for 2.6.14, but additional comments are
of course very welcome.

I'd like to thanks James Smart a lot for his very useful input on the
design.

Signed-off-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: James Bottomley <James.Bottomley@SteelEye.com>
[SCSI] 3ware 9000: handle use_sg != 0 for emulated commands

The attached patch updates the driver for the 3ware 9000 series to do
the following:

- Correctly handle single sgl's with use_sg = 1.

This is needed with the latest scsi-block-2.6 merge otherwise the 3w-9xxx
driver will not work.  I tested the patch James sent a few weeks back to fix
this, and it had a bug where the request_buffer was accessed in
twa_scsiop_execute_scsi_complete() when it was invalid.  This is a corrected
variation of that patch.

Signed-off-by: Adam Radford <linuxraid@amcc.com>
Signed-off-by: James Bottomley <James.Bottomley@SteelEye.com>
[SCSI] SAS transport class: fixup prototype of sas_host_setup

Signed-off-by: James Bottomley <James.Bottomley@SteelEye.com>
[SCSI] fc_transport: Generalize WWN to u64 interger conversions.

On some platforms the hard-casting of 8 byte node_name and
port_name arrays to an u64 would cause unaligned-access
warnings.  Generalize the conversions with a transport
helper function which performs consistent shifting of WWN
bytes.

Signed-off-by: Andrew Vasquez <andrew.vasquez@qlogic.com>
Signed-off-by: James Bottomley <James.Bottomley@SteelEye.com>