sd_issue_flush() is called from atomic context so we can't use the
semaphore based routines to get a reference to the scsi_disk. Assume
something else already got the reference so we can safely use it.
Signed-off-by: James Bottomley <James.Bottomley@SteelEye.com>
Currently the driver takes a reference only for requests coming by way
of the gendisk, not for requests coming by way of the struct device or
struct scsi_device. Such requests can arrive in the rescan, flush,
and shutdown pathways.
The patch also makes the scsi_disk keep a reference to the underlying
scsi_device, and it erases the scsi_device's pointer to the scsi_disk
when the scsi_device is removed (since the pointer should no longer be
used).
This resolves Bugzilla entry #5237.
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: James Bottomley <James.Bottomley@SteelEye.com>
This should eliminate (at least in the mid layer) to make numeric
assumptions about any of the enumeration variables. As a side effect,
it will also make all the messages consistent and line us up nicely for
the error logging strategy (if it ever shows itself again).
Signed-off-by: James Bottomley <James.Bottomley@SteelEye.com>
This fixes an issue in scsi command initialization from a request
where sd, sr, st, and scsi_lib all fail to copy the request's
cmd_len to the scsi command's cmd_len field.
Signed-off-by: Timothy Thelin <timothy.thelin@wdc.com>
Signed-off-by: James Bottomley <James.Bottomley@SteelEye.com>
This patch adds a delay tailored for USB flash devices that are slow to
initialize their firmware. The symptom is a repeated Unit Attention with
ASC=0x28 (Not Ready to Ready transition). The patch will wait for up to 5
seconds for such devices to become ready. Normal devices won't send the
repeated Unit Attention sense key and hence won't trigger the patch.
This fixes a problem with James Roberts-Thomson's USB device, and I've
seen several reports of other devices exhibiting the same symptoms --
presumably they will be helped as well.
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: James Bottomley <James.Bottomley@SteelEye.com>
This one removes struct scsi_request entirely from sd. In the process,
I noticed we have no callers of scsi_wait_req who don't immediately
normalise the sense, so I updated the API to make it take a struct
scsi_sense_hdr instead of simply a big sense buffer.
Signed-off-by: James Bottomley <James.Bottomley@SteelEye.com>
After this, we just have some drivers, all the ULDs and the SPI
transport class using scsi_wait_req().
Signed-off-by: James Bottomley <James.Bottomley@SteelEye.com>
I was going over the scsi I/O submit path, when sd_init_command
construct the scsi command, this_count is already checked in the
previous else if clause. Why does it need to check it again in
the last else block?
Patch to delete the spurious check.
Signed-off-by: Ken Chen <kenneth.w.chen@intel.com>
Signed-off-by: James Bottomley <James.Bottomley@SteelEye.com>
a) TYPE_SDAD renamed to TYPE_RBC and taken to scsi.h
b) in sbp2.c remapping of TYPE_RPB to TYPE_DISK turned off
c) relevant places in midlayer and sd.c taught to accept TYPE_RBC
d) sd.c::sd_read_cache_type() looks into page 6 when dealing with
TYPE_RBC - these guys have writeback cache flag there and are not guaranteed
to have page 8 at all.
e) sd_read_cache_type() got an extra sanity check - it checks that
it got the page it asked for before using its contents. And screams if
mismatch had happened. Rationale: there are broken devices out there that
are "helpful" enough to go for "I don't have a page you've asked for, here,
have another one". For example, PL3507 had been caught doing just that...
f) sbp2 sets sdev->use_10_for_rw and sdev->use_10_for_ms instead
of bothering to remap READ6/WRITE6/MOD_SENSE, so most of the conversions
in there are gone now.
Incidentally, I wonder if USB storage devices that have no
mode page 8 are simply RBC ones. I haven't touched that, but it might
be interesting to check...
Signed-off-by: Al Viro <viro@parcelfarce.linux.theplanet.co.uk>
Signed-off-by: James Bottomley <James.Bottomley@SteelEye.com>
Initial git repository build. I'm not bothering with the full history,
even though we have it. We can create a separate "historical" git
archive of that later if we want to, and in the meantime it's about
3.2GB when imported into git - space that would just make the early
git days unnecessarily complicated, when we don't have a lot of good
infrastructure for it.
Let it rip!
