From: Jens Axboe <axboe@suse.de>

Following patch adds mt rainier support to the cdrom uniform layer (it
works with atapi and scsi/usb).

From: Jens Axboe <axboe@suse.de>

The command 'eject /dev/scd0' sends a START_STOP command to the device with
the data direction set to SCSI_DATA_WRITE but a transfer length of zero.
This causes a problem for some code paths.

I got underflow warnings and failures when sending an INQUIRY page 0x83
via the SG_IO REQ_BLOCK_PC interface.

The underflow field should only be set if we know for certain the size of
the data being transfered, so fix this by leaving it at zero for scsi
REQ_BLOCK_PC cases.

	kdev_t, to_kdev_t(), etc. are gone - there is no more objects
of that type and no remaining callers of these functions.

The linux/drivers/scsi/sr.c code will issue a MODE_SENSE[_10] command to
a device as the first command sent to the device.  If the device has
just come out of reset, it will likely respond with a UNIT_ATTENTION /
NOT_READY status, which causes the MODE_SENSE to fail.  In fact, the
device may have several UNIT_ATTENTION conditions queued up (power-up
reset, media change, etc.)

This results in the mode page 0x2a data not being properly read and
interpreted.  As an end-effect, things like packet-writing don't work
(because the writeable bit is not set).

The solution to this is to issue one or more TEST_UNIT_READY commands to
the device to clear any pending UNIT_ATTENTION conditions.  This is the
technique used by sd.c -- in fact, this code was lifted directly from
sd.c

At some point in the future, abstraction of this initial TEST_UNIT_READY
code between all high-level SCSI drivers may be apropriate.  For now,
this patch makes sr.c issue TEST_UNIT_READY to clear the UNIT_ATTENTION,
thus allowing the mode page 0x2a code to work properly.  Given the
approaching 2.6.0-final release, I urge that this patch be accepted.

most callers really want GFP_KERNEL, not GFP_ATOMIC.

This patch addresses a problem in both sd.c and sr.c.  When a read/write
command is initialized, the routines may reduce this_count (the number of
sectors to transfer) if it exceeds the maximum allowed value (i.e., 0xffff
for READ(10)).  However, the code does not similarly alter
scmd->request_bufflen and scmd->bufflen to match the change in the CDB
value.

scmd->request_bufflen is important for the usb-storage driver, which
requires that it be exactly equal to the number of bytes transferred.
scmd->bufflen is used in the rw_intr() routines, where it is passed to
scsi_io_completion() as the number of sectors transferred if no errors
occur.

Another small change in the patch concerns the code in sr.c that checks
whether the total of the scatter-gather area lengths matches
scmd->request_bufflen.  If they don't match, the patch bumps the kernel
log message level up to KERN_ERR, and it takes the more conservative
approach of adjusting scmd->request_bufflen only if the s-g length is
smaller than the request length.

Forward port of Kurt Garloff's recovered error fix.
http://marc.theaimsgroup.com/?l=linux-scsi&m=104470522312140&w=2

Also corrected some typos related to setting local scope variable by mistake.

Signature without fix:
Current sdc: sense key Recovered Error
Additional sense: Failure prediction threshold exceeded
end_request: I/O error, dev sdc, sector 1808
Buffer I/O error on device sdc, logical block 226

Signature with fix:
scsi_debug: cmd 28 00 00 00 3f 10 00 00 f0 00
scsi_debug: ... <1 0 0 0> non-zero result=0x8000002
Current sdsdc: sense key Recovered Error
Additional sense: Failure prediction threshold exceeded

 drivers/scsi/sd.c |    6 ++--
 drivers/scsi/sr.c |   79 +++++++++++++++++++++++++++++++++++-------------------
 2 files changed, 56 insertions(+), 29 deletions(-)

This causes blk.h to print a warning and removes all uses of blk.h.
I've tested the compilation in 2.6.0-test1 with a .config that tries to
compile as many drivers as possible.

currently the embedded struct devices and class devices have totally
irregular and sometimes confusing (sdev_driverfs_dev) names.  Name
them consistanly s{dev,host}_{class,gen}dev.

From: Kouichi ONO <co2b@ceres.dti.ne.jp>

in 2.5.73, I can't read/write mount DVD-RAM via ide-scsi (only r/o mount).
Without ide-scsi, I can mount DVD-RAM read/write mode and works fine.

(acked by Jens).

include/scsi/scsi_driver.h contains æverything related to upper
level drivers.  Unlike the other header moves there's no compatiblity
this time as it's easy to fix up the few users.

Move the mode_sense request routines to a central location and make
all block device consumers use it.  Also abstract the header as
part of the return to hide the 6/10 differences.

This moves the initialization of the struct scsi_device fields
use_10_for_ms and use_10_for_rw into a central place.  This allows the
host's slave_configure() function to change them (with effect).  This
also collapses two identical sections of code into a single one.

This is needed by usb-storage, so we can resolve some Babble problems,
some device-crashing problems, and remove a great deal of troublesome
mode-sense-translation code.

On Tue, May 27, 2003 at 09:32:18AM +0200, Christoph Hellwig wrote:
>  - removed the tape sysfs pseudodevice crap that caused hangs
>  - switched sg to a class_interface.  This means sg can be used
>    on devices already claimed be an upper driver again.  This
>    also means I had to remove the sg sysfs attributes temporarily
>    because the old mechanism is gone, but I'll restore them
>    differently in a followon patch.

Yikes, this was the old patch again.  Here's the right one:

In the old days, ancient scsi devices understood 6-byte commands
and more recent ones also understood 10-byte commands.
Thus, we had a "ten" flag indicating that 10-byte commands worked.

These days, especially for usb-storage devices, the opposite
sometimes holds - 10-byte commands are supported, but 6-byte commands
are not.

The patch below changes the field ten into the pair of fields
use_10_for_rw, use_10_for_ms set initially when the driver
thinks these are supported. Ifthe device returns ILLEGAL_REQUEST
they are cleared.

This patch obsoletes a large amount of code in usb-storage,
and not only that, once the subsequent patch removes all this
usb-storage code many devices will work that hang today.


Andries

I added those two to factor out common code from the upper drivers
a long time ago, but after Doug & Lubens nice work there's nothing
left but incrementing/decrementing a counter in struct scsi_device
that's never used except in the case were we not it must be NULL
because we just walked the chain of drivers to detach every single
one..

Two new headers:

  scsi_priv.h - for macros/declarations private to the scsi midlayer
		  (= not EXPORT_SYMBOL()ed)
  scsi_logging.h - for SCSI_LOG_* and friends, semi-private to the
  		midlayer and the upper drivers.  One abuse of this
		in dpt_i2o killed.

Previously gendisk.devfs_name was used only for partitioned devices
or CDroms, and for the latter it was slightly broken.  Fix it to
work genericly for all gendisks.

Always pass around the pathnames for the devfs entries / directories
instead of the devfs_handle_ts.  Cleanes up the code massivly.

Patch from Andries.Brouwer@cwi.nl

The following patch does the following:

- static const char *blkdevs[MAX_BLKDEV]; disappears
- get_blkdev_list, (un)register_blkdev, __bdevname
  are moved from block_dev.c to genhd.c
- the third "fops" parameter of register_blkdev was unused;
  now removed everywhere
- zillions of places had printk("cannot get major") upon
  error return from register_blkdev; removed all of these
  and inserted a single printk in register_blkdev.

Of course the reason for the patch is that one fixed size
array is eliminated.

In get_sectorsize(), we can already sleep in scsi_wait_req().
In get_capabilities(), we can use GFP_KERNEL because it is only called
from sr_attach() which already does a GFP_KERNEL allocation.

This patch replaces "loose" with "lose" where appropriate.
There remain 56 correct uses of "loose" in the 2.5 kernel source.

Currently for block devices both the SCSI_IOCTL_GET_IDLUN and 
SCSI_IOCTL_GET_BUS_NUMBER ioctls yield the value 0 (type: int).

Various applications that utilize the sg driver use these ioctls
to work out the relationship between sg devices and their higher
level counterparts in the sd, sr, st and osst drivers. Examples
that spring to mind are cdrecord, cdparanoia, SANE and sg_utils.

This has been discussed in an earlier threaded started by me:
http://marc.theaimsgroup.com/?l=linux-scsi&m=103967899608891&w=2
in which my patch removed the ioctls in question from the block
level. This broke non-scsi block devices that used applications
that thought they were talking to an sg device **.

The attachment fine tunes the original patch: for scsi block
devices (i.e. owned by the sd or sr drivers) these 2 ioctls
are redirected to the scsi mid level; for non-scsi block
devices they will yield the value as 0 as they do now in
lk 2.5.53 .


** This "yield 0" strategy will come unstuck when 2 or more
cd writers (for example) are connected to the same box.
Hence to be well formed, these ioctls (together) should
produce unique tuples for each device (be they ATA(PI) or
SCSI).

Update scsi_scan so that we don't pass around a scsi_device struct for
    	scanning.  Instead, we pass around a request_queue during
    	scanning and create and destroy device structs as needed.  This
    	allows us to have a 1:1 correlation between scsi_alloc_sdev()
    	and scsi_free_sdev() calls, which we didn't have before.

The same for sr (I didn't actually had a chance to actually test this,
but it's the same change as in sd).

Two new helpers: scsi_device_get and scsi_device_put that get/release a
reference to the underlying HBA driver and increment/decrement
->access_count.  Cleanup ->attach/->detach routines in the upper layer
drivers a bit to consolidate the error pathes once we're cleaning them
up.

->attach and ->detach in upper layer drivers are mandatory now (not
having them would be rather pointless).

(note that the sd.c changes are not in this patch, it'll be part of
my next, bigger patch)

I have attached an updated combined patch of my previously posted sysfs
changes. 

This patch is against linux-scsi.bkbits.net/scsi-misc-2.5

This patch contains these updates:
	- update to osst.c to support sysfs cleanups.
	- oops fix in osst.c detach if no device attached. A better
	  method than this quick fix is needed.
	- removed scsi_bus_hotplug function do to bug and not really
	  needed now as default gives path data. If needed in future can
	  be added with better definition.

-andmike

Update scsi.c for struct list_head in upper layer templates
Update scsi.c for new module loader semantics

Okay, we're finally at the point where ->detect has become entirely
superflous.  In sd, sr and st it does nothing but return different
values that are ignored anyway, in sg it increments a variable
that is never read (and thus removed in this patch aswell), only
in osst it increments a variable that is actually checked for beeing
non-zero.  But if it was zero we'd never reached that place anyway
(same check in the beginning of osst_detect and osst_attach).

This make the upper layer interface a lot nicer and avoids the
race condition where a device is remove between detect and attach
(which currently wouldn't matter anyway as we aren't doing anything
in detect anymore)

This patch fixes queue depth setting of scsi devices.

This is done by pairing shost->slave_attach() calls with
a scsi_build_commandblocks in the new scsi_slave_attach.

This is a patch aginst linux-scsi.bkbits.net/scsi-for-linus-2.5 after
applying the last posted hch version of the "Eliminate scsi_host_tmpl_list"
patch, it still applies with offset to the current scsi-for-linus-2.5.

It also:

Will properly call shost->slave_attach after a scsi_unregister_device()
followed by a scsi_register_device() - as could happen if you were able to
rmmod all upper level drivers and then insmod any of them back (only
possible when not booted on scsi).

Checks for scsi_build_commandblocks() allocation failures.

Sets queue depth even if shost->slave_attach() does not call
scsi_adjust_queue_depth.

Removes the use of revoke (no drivers are setting it, it was only
call via the proc scsi remove-single-device interface).

There are at least two problems with sysfs and scsi (one in sysfs, one in
scsi, I'll try and post more soon ...) so I could not completey test rmmod
of an adapter or upper level driver without leading to an oops or shutdown
hang.

 hosts.c              |    5 --
 hosts.h              |    6 --
 osst.c               |    9 ++-
 scsi.c               |  118 +++++++++++++++++++++++++++++++--------------------
 scsi.h               |    2
 scsi_mid_low_api.txt |   24 ----------
 scsi_scan.c          |    9 ---
 sd.c                 |   10 +++-
 sg.c                 |   10 ++--
 sr.c                 |    7 ++-
 st.c                 |   11 +++-
 11 files changed, 106 insertions(+), 105 deletions(-)

===== drivers/scsi/hosts.c 1.23 vs edited =====

Now that .init isn't implement anymore we can get rid of it and
do some more cleanup in the scsi device template:

* remove .blk - unused since 2.5.46
* remove .dev_noticed, only midlayer user is gone together with
  .init.  remaining instance now driver-private
* remove .nr_dev and .dev_max - they're purely driver internal
  and at least in sd and sr they'll be completly gone very soon.

Similar cleanup to the recent sd patch:  allocate the scsi_cd struct
in sd_attach instead of needing the global array and sd_init.

Tested with a DVD reader/CD write combination and ide-scsi.

	_Now_ we can clean the scsi_get_request_dev() up.  Indeed, for
any SCSI request we either have ->rq_dev == NODEV and ->rq_disk == NULL
or ->rq_disk->private_data points to address of template in question.
IOW, scsi_get_request_dev() becomes simply
{
	struct gendisk *p = req->rq_disk;
	return p ? *(struct Scsi_Device_Template **)p->private_data : NULL;
}
and that allows to kill ->max_major, ->min_major and ->major in
Scsi_Device_Template, along with the last non-trivial use of ->rq_dev.

	Ditto for sr.c

Hi James,

Here are the changes that are good outside the other changes :-)

scsi_lib:
	o ->errors is used as the scsi status byte for REQ_BLOCK_PC
	o ->data_len is the residual byte count
	o call __scsi_end_request even for !good_sectors if status is
	  good. This legitimately can happen for REQ_BLOCK_PC commands
	  sent from a user space program, if it gets the command setup
	  wrong (or weird). Right now this will hang that queue.

scsi_merge:
	o set SCpnt->request_bufflen to ->data_len, this is the
	  authoritative io byte count for REQ_BLOCK_PC. Here we deal in
	  bytes and not sectors.

sr + sd:
	o Set transfersize and underlow correctly for REQ_BLOCK_PC

sr_ioctl
	o We want to return -EIO for command failure, not EINVAL. That
 	  is pretty stupid :-)


===== drivers/scsi/scsi_lib.c 1.35 vs edited =====

bring it back in line with sd:
* get rid of typedefs where possible
* tab-align all credits entries
* line-wrap after 80 characters
* use C99-initializers

Various small bits that make SCSI work well with REQ_BLOCK_PC.

o Use ->errors as the scsi status byte for REQ_BLOCK_PC

o Always call end_io completion, even if 0 sectors, as long as the
  status is good. Otherwise we risk hanging this device if a
  REQ_BLOCK_PC user command didn't specify a transfer size for a command
  that did.

o Remove bouncing checks in scsi_merge for REQ_BLOCK_PC, bio_map_user()
  correctly bounces pages now.

o Decrement req->data_len, it's our residual data count.

o sr/sd: set right transfer and underflow size.