Some of the storage devices (that can be accessed through multiple paths),
do need some special handling for
1. Activating the passive path of the storage access.
2. Decode and handle the special sense codes returned by the devices.
3. Handle the I/Os being sent to the passive path, especially
during the device probe time.
when accessed through multiple paths.
As of today this special device handling is done at the dm-multipath
layer using dm-handlers. That works well for (1); for (2) to be handled
at dm layer, scsi sense information need to be exported from SCSI to dm-layer,
which is not very attractive; (3) cannot be done at all at the dm layer.
Device handler has been moved to SCSI mainly to handle (2) and (3) properly.
Signed-off-by: Chandra Seetharaman <sekharan@us.ibm.com>
Signed-off-by: Mike Anderson <andmike@linux.vnet.ibm.com>
Signed-off-by: Mike Christie <michaelc@cs.wisc.edu>
Signed-off-by: James Bottomley <James.Bottomley@HansenPartnership.com>
Replace the mac_esp driver with a new one based on the esp_scsi core.
For esp_scsi: add support for sync transfers for the PIO mode, add a new
esp_driver_ops method to get the maximum dma transfer size (like the old
NCR53C9x driver), and some cleanups.
Signed-off-by: Finn Thain <fthain@telegraphics.com.au>
Acked-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
Signed-off-by: James Bottomley <James.Bottomley@HansenPartnership.com>
This adds support to SCSI for enclosure services devices. It also makes
use of the enclosure services added in an earlier patch to display the
enclosure topology in sysfs.
At the moment, the enclosures are SAS specific, but if anyone actually
has a non-SAS enclosure that follows the SES-2 standard, we can add that
as well.
On my Vitesse based system, the enclosures show up like this:
sparkweed:~# ls -l /sys/class/enclosure/0\:0\:1\:0/
total 0
-r--r--r-- 1 root root 4096 2008-02-03 15:44 components
lrwxrwxrwx 1 root root 0 2008-02-03 15:44 device -> ../../../devices/pci0000:01/0000:01:02.0/host0/port-0:0/expander-0:0/port-0:0:12/end_device-0:0:12/target0:0:1/0:0:1:0
drwxr-xr-x 2 root root 0 2008-02-03 15:44 SLOT 000
drwxr-xr-x 2 root root 0 2008-02-03 15:44 SLOT 001
drwxr-xr-x 2 root root 0 2008-02-03 15:44 SLOT 002
drwxr-xr-x 2 root root 0 2008-02-03 15:44 SLOT 003
drwxr-xr-x 2 root root 0 2008-02-03 15:44 SLOT 004
drwxr-xr-x 2 root root 0 2008-02-03 15:44 SLOT 005
lrwxrwxrwx 1 root root 0 2008-02-03 15:44 subsystem -> ../../enclosure
--w------- 1 root root 4096 2008-02-03 15:44 uevent
And the individual occupied slots like this:
sparkweed:~# ls -l /sys/class/enclosure/0\:0\:1\:0/SLOT\ 001/
total 0
-rw-r--r-- 1 root root 4096 2008-02-03 15:45 active
lrwxrwxrwx 1 root root 0 2008-02-03 15:45 device -> ../../../../devices/pci0000:01/0000:01:02.0/host0/port-0:0/expander-0:0/port-0:0:11/end_device-0:0:11/target0:0:0/0:0:0:0
-rw-r--r-- 1 root root 4096 2008-02-03 15:45 fault
-rw-r--r-- 1 root root 4096 2008-02-03 15:45 locate
-rw-r--r-- 1 root root 4096 2008-02-03 15:45 status
lrwxrwxrwx 1 root root 0 2008-02-03 15:45 subsystem -> ../../../enclosure_component
-r--r--r-- 1 root root 4096 2008-02-03 15:45 type
--w------- 1 root root 4096 2008-02-03 15:45 uevent
You can flash the various blinky lights by echoing to the fault and locate files.
>From the device's point of view, you can see it has an enclosure like this:
sparkweed:~# ls /sys/class/scsi_disk/0\:0\:0\:0/device/
block:sda generic queue_depth state
bsg:0:0:0:0 iocounterbits queue_type subsystem
bus iodone_cnt rescan timeout
delete ioerr_cnt rev type
device_blocked iorequest_cnt scsi_device:0:0:0:0 uevent
driver modalias scsi_disk:0:0:0:0 vendor
enclosure_component:SLOT 001 model scsi_generic:sg0
evt_media_change power scsi_level
Note the enclosure_component:SLOT 001 which shows where in the enclosure
this device fits.
The astute will notice that I'm using SCSI VPD Inquiries to identify the
devices. This, unfortunately, won't work for SATA devices unless we do
some really nasty hacking about on the SAT because the only think that
knows the SAS addresses for SATA devices is libsas, not libata where the
SAT resides.
Signed-off-by: James Bottomley <James.Bottomley@HansenPartnership.com>
subdir-y|m isn't supposed to contain modules or built-in components.
Change subdir-$(CONFIG_PCMCIA) to obj-$(CONFIG_PCMCIA).
Signed-off-by: Tejun Heo <htejun@gmail.com>
Acked-by: Sam Ravnborg <sam@ravnborg.org>
Signed-off-by: James Bottomley <James.Bottomley@HansenPartnership.com>
- Apparently no one wonts this driver, and no one
is willing to fix it for future changes to SCSI.
So remove it, and if someone wants it in the future
He can revive it with the needed fixes.
Signed-off-by: Boaz Harrosh <bharrosh@panasas.com>
Signed-off-by: James Bottomley <James.Bottomley@HansenPartnership.com>
The psi240i driver is still written for cmnd->request_buffer
as a char pointer to actual data. There was never any attempt
to use the scatterlist option.
- remove all source files (3) from drivers/scsi
- Remove from Makefile and Kconfig
Signed-off-by: Boaz Harrosh <bharrosh@panasas.com>
Signed-off-by: James Bottomley <James.Bottomley@HansenPartnership.com>
This code has been slowly rotting for about eight years. It's currently
impeding a few SCSI cleanups, and nobody seems to have hardware to test
it any more. I talked to Dave Miller about it, and he agrees we can
delete it. If anyone wants a software FC stack in future, they can
retrieve this driver from git.
Signed-off-by: Matthew Wilcox <matthew@wil.cx>
Acked-by: David S. Miller <davem@davemloft.net>
Signed-off-by: James Bottomley <James.Bottomley@SteelEye.com>
This adds srp transport class that works with ib_srp and ibmvscsi.
It creates only /sys/class/{srp_host,srp_remote_ports} and
srp_remote_ports has only "port_id" attribute.
viola:/sys/class/srp_remote_ports/port-0:1# ls
device port_id subsystem uevent
viola:/sys/class/srp_remote_ports/port-0:1# cat port_id
4c:49:4e:55:58:20:56:49:4f:00:00:00:00:00:00:00
Signed-off-by: FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp>
Signed-off-by: James Bottomley <James.Bottomley@SteelEye.com>
With
dma-mapping-prevent-dma-dependent-code-from-linking-on.patch
scsi fails to build on !HAS_DMA architectures:
drivers/built-in.o(.text+0x20af6): In function `scsi_dma_map':
: undefined reference to `dma_map_sg'
drivers/built-in.o(.text+0x20b5c): In function `scsi_dma_unmap':
: undefined reference to `dma_unmap_sg'
I split those functions out into a new file. Builds on s390 and i386.
Move scsi_dma_{map,unmap} into scsi_lib_dma.c which is only build if
HAS_DMA is set.
Signed-off-by: Cornelia Huck <cornelia.huck@de.ibm.com>
Cc: Martin Schwidefsky <schwidefsky@de.ibm.com>
Cc: Heiko Carstens <heiko.carstens@de.ibm.com>
Cc: James Bottomley <James.Bottomley@SteelEye.com>
Cc: Jeff Garzik <jeff@garzik.org>
Cc: Christoph Hellwig <hch@lst.de>
Cc: Dan Williams <dan.j.williams@intel.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: James Bottomley <James.Bottomley@SteelEye.com>
CONFIG_SCSI_FD_8xx no longer exists.
Apparently it was renamed to CONFIG_SCSI_SEAGATE, but the Makefile was
not correctly updated.
Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
Signed-off-by: James Bottomley <James.Bottomley@SteelEye.com>
New driver for Amiga Zorro bus NCR53c710 SCSI controllers, using the 53c700
SCSI core.
Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
Signed-off-by: James Bottomley <James.Bottomley@SteelEye.com>
New driver for the Amiga 4000T built-in NCR53c710 SCSI controller, using the
53c700 SCSI core.
Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
Signed-off-by: James Bottomley <James.Bottomley@SteelEye.com>
New driver for the MVME16x NCR53C710 SCSI controller, using the 53c700 SCSI
core.
Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
Signed-off-by: James Bottomley <James.Bottomley@SteelEye.com>
New driver for the BVME6000 NCR53C710 SCSI controller, using the 53c700 SCSI
core.
Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
Signed-off-by: James Bottomley <James.Bottomley@SteelEye.com>
Conflicts:
drivers/scsi/jazz_esp.c
Same changes made by both SCSI and SPARC trees: problem with UTF-8
conversion in the copyright.
Signed-off-by: James Bottomley <James.Bottomley@SteelEye.com>
It's been more than enough time now to try to get the new m68k drivers
into the tree. Let's remove the old ones and we can remerge the new
glue once it's ready. Given that there are patches to rename two out
of the three drivers in m68k CVS and all of them need a lot of
codingstyle love anyway that's probably the better strategy to begin
with.
Signed-off-by: Christoph Hellwig <hch@lst.de>
Cc: Geert Uytterhoeven <geert@linux-m68k.org>
Cc: Kars de Jong <jongk@linux-m68k.org>
Cc: linux-m68k@vger.kernel.org
Signed-off-by: James Bottomley <James.Bottomley@SteelEye.com>
