summaryrefslogtreecommitdiffstats
path: root/drivers/scsi/Makefile
Commit message (Collapse)AuthorAgeFilesLines
* libata: add new driver pdc_adma for PDC ADMA ATA cardsMark Lord2005-10-101-0/+1
|
* Merge branch 'master'Jeff Garzik2005-10-061-0/+1
|\
| * [SCSI] MegaRAID SAS RAID: new driverBagalkote, Sreenivas2005-09-261-0/+1
| | | | | | | | | | Signed-off-by: Sreenivas Bagalkote <Sreenivas.Bagalkote@lsil.com> Signed-off-by: James Bottomley <James.Bottomley@SteelEye.com>
* | Merge /spare/repo/linux-2.6/ Jeff Garzik2005-09-141-0/+1
|\ \ | |/
| * [SCSI] SAS transport classChristoph Hellwig2005-09-091-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* | Merge /spare/repo/linux-2.6/ Jeff Garzik2005-09-081-0/+3
|\ \ | |/
| * Merge master.kernel.org:/pub/scm/linux/kernel/git/jejb/scsi-for-linus-2.6 Linus Torvalds2005-09-071-0/+2
| |\
| | * [SCSI] embryonic RAID classJames Bottomley2005-08-301-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The idea behind a RAID class is to provide a uniform interface to all RAID subsystems (both hardware and software) in the kernel. To do that, I've made this class a transport class that's entirely subsystem independent (although the matching routines have to match per subsystem, as you'll see looking at the code). I put it in the scsi subdirectory purely because I needed somewhere to play with it, but it's not a scsi specific module. I used a fusion raid card as the test bed for this; with that kind of card, this is the type of class output you get: jejb@titanic> ls -l /sys/class/raid_devices/20\:0\:0\:0/ total 0 lrwxrwxrwx 1 root root 0 Aug 16 17:21 component-0 -> ../../../devices/pci0000:80/0000:80:04.0/host20/target20:1:0/20:1:0:0/ lrwxrwxrwx 1 root root 0 Aug 16 17:21 component-1 -> ../../../devices/pci0000:80/0000:80:04.0/host20/target20:1:1/20:1:1:0/ lrwxrwxrwx 1 root root 0 Aug 16 17:21 device -> ../../../devices/pci0000:80/0000:80:04.0/host20/target20:0:0/20:0:0:0/ -r--r--r-- 1 root root 16384 Aug 16 17:21 level -r--r--r-- 1 root root 16384 Aug 16 17:21 resync -r--r--r-- 1 root root 16384 Aug 16 17:21 state So it's really simple: for a SCSI device representing a hardware raid, it shows the raid level, the array state, the resync % complete (if the state is resyncing) and the underlying components of the RAID (these are exposed in fusion on the virtual channel 1). As you can see, this type of information can be exported by almost anything, including software raid. The more difficult trick, of course, is going to be getting it to perform configuration type actions with writable attributes. Signed-off-by: James Bottomley <James.Bottomley@SteelEye.com>
| * | [PATCH] libata: Marvell SATA support (PIO mode)Brett Russ2005-09-071-0/+1
| |/ | | | | | | | | | | | | | | | | | | This is my libata compatible low level driver for the Marvell SATA family. Currently it successfully runs in PIO mode on a 6081 chip. EDMA support is in the works and should be done shortly. Review, testing (especially on other flavors of Marvell), comments welcome. Signed-off-by: Brett Russ <russb@emc.com> Signed-off-by: Jeff Garzik <jgarzik@pobox.com>
* | [PATCH] SATA: rewritten sil24 driverTejun Heo2005-07-281-0/+1
|/ | | | | | | | | This is rewritten sil24 driver against v2.6.13-rc3. Rewritten based on driver originally submitted by Silicon Image. Signed-off-by: Tejun Heo <htejun@gmail.com> Signed-off-by: Jeff Garzik <jgarzik@pobox.com>
* [SCSI] add scsi changer driverGerd Knorr2005-05-201-0/+1
| | | | | | | This patch adds a device driver for scsi media changer devices. Signed-off-by: Gerd Knorr <kraxel@bytesex.org> Signed-off-by: James Bottomley <James.Bottomley@SteelEye.com>
* [SCSI] remove PCI2000 and PCI2220i driversJames Bottomley2005-05-201-2/+0
| | | | | | | | | | From: Christoph Hellwig <hch@lst.de> Both drivers are marked broken and haven't compiled since very early 2.5.x. And they're for IDE hardware so they shouldn't have been written to the SCSI layer at all. Signed-off-by: James Bottomley <James.Bottomley@SteelEye.com>
* lpfc: add Emulex FC driver version 8.0.282005-04-181-0/+1
| | | | | | | From: James.Smart@Emulex.Com Modified for kernel import and Signed-off-by: James Bottomley <James.Bottomley@SteelEye.com>
* Linux-2.6.12-rc2v2.6.12-rc2Linus Torvalds2005-04-161-0/+184
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!
OpenPOWER on IntegriCloud