From 31df2fd54cafdadadb20c60e80461c9b08b2ff56 Mon Sep 17 00:00:00 2001 From: Mauro Carvalho Chehab Date: Mon, 2 Mar 2020 09:15:34 +0100 Subject: scsi: docs: Add an empty index file for SCSI documents In preparation for adding the SCSI documents to the documentation body, add an empty index for it. The next patches should be adding contents to it, as files get converted to ReST format. Link: https://lore.kernel.org/r/4d8c1b7ebe5898ac4a8265ca5e5a9552da3b426f.1583136624.git.mchehab+huawei@kernel.org Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Martin K. Petersen --- Documentation/scsi/index.rst | 10 ++++++++++ 1 file changed, 10 insertions(+) create mode 100644 Documentation/scsi/index.rst (limited to 'Documentation/scsi') diff --git a/Documentation/scsi/index.rst b/Documentation/scsi/index.rst new file mode 100644 index 000000000000..16baf8b0f11f --- /dev/null +++ b/Documentation/scsi/index.rst @@ -0,0 +1,10 @@ +.. SPDX-License-Identifier: GPL-2.0 + +==================== +Linux SCSI Subsystem +==================== + +.. toctree:: + :maxdepth: 1 + + -- cgit v1.2.3 From 7f877908df42d58468980d89a7f130ab30c83afd Mon Sep 17 00:00:00 2001 From: Mauro Carvalho Chehab Date: Mon, 2 Mar 2020 09:15:35 +0100 Subject: scsi: docs: include SCSI Transport SRP diagram at the doc body Instead of having a separate makefile, and be alone, group it at the SCSI documentation and make it being built as part of docs makefile. Link: https://lore.kernel.org/r/419c455fb40c9a1e85cc9a654a7fdb07aeeccf71.1583136624.git.mchehab+huawei@kernel.org Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Martin K. Petersen --- Documentation/scsi/index.rst | 2 +- Documentation/scsi/scsi_transport_srp/Makefile | 7 ------- Documentation/scsi/scsi_transport_srp/figures.rst | 6 ++++++ 3 files changed, 7 insertions(+), 8 deletions(-) delete mode 100644 Documentation/scsi/scsi_transport_srp/Makefile create mode 100644 Documentation/scsi/scsi_transport_srp/figures.rst (limited to 'Documentation/scsi') diff --git a/Documentation/scsi/index.rst b/Documentation/scsi/index.rst index 16baf8b0f11f..3ef7ad65372a 100644 --- a/Documentation/scsi/index.rst +++ b/Documentation/scsi/index.rst @@ -7,4 +7,4 @@ Linux SCSI Subsystem .. toctree:: :maxdepth: 1 - + scsi_transport_srp/figures diff --git a/Documentation/scsi/scsi_transport_srp/Makefile b/Documentation/scsi/scsi_transport_srp/Makefile deleted file mode 100644 index 5f6b567e955c..000000000000 --- a/Documentation/scsi/scsi_transport_srp/Makefile +++ /dev/null @@ -1,7 +0,0 @@ -all: rport_state_diagram.svg rport_state_diagram.png - -rport_state_diagram.svg: rport_state_diagram.dot - dot -Tsvg -o $@ $< - -rport_state_diagram.png: rport_state_diagram.dot - dot -Tpng -o $@ $< diff --git a/Documentation/scsi/scsi_transport_srp/figures.rst b/Documentation/scsi/scsi_transport_srp/figures.rst new file mode 100644 index 000000000000..6c8f8dd6301b --- /dev/null +++ b/Documentation/scsi/scsi_transport_srp/figures.rst @@ -0,0 +1,6 @@ +.. SPDX-License-Identifier: GPL-2.0 + +SCSI RDMA (SRP) transport class diagram +======================================= + +.. kernel-figure:: rport_state_diagram.dot -- cgit v1.2.3 From f76576777a03bdd02bc8e5e71838c187051b17a0 Mon Sep 17 00:00:00 2001 From: Mauro Carvalho Chehab Date: Mon, 2 Mar 2020 09:15:36 +0100 Subject: scsi: docs: convert 53c700.txt to ReST Link: https://lore.kernel.org/r/a2e5116b70564f36b4fc7f1f1e5da1e693d7dadb.1583136624.git.mchehab+huawei@kernel.org Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Martin K. Petersen --- Documentation/scsi/53c700.rst | 134 +++++++++++++++++++++++++++++++++++++++++ Documentation/scsi/53c700.txt | 135 ------------------------------------------ Documentation/scsi/index.rst | 2 + 3 files changed, 136 insertions(+), 135 deletions(-) create mode 100644 Documentation/scsi/53c700.rst delete mode 100644 Documentation/scsi/53c700.txt (limited to 'Documentation/scsi') diff --git a/Documentation/scsi/53c700.rst b/Documentation/scsi/53c700.rst new file mode 100644 index 000000000000..53a0e9f9c198 --- /dev/null +++ b/Documentation/scsi/53c700.rst @@ -0,0 +1,134 @@ +.. SPDX-License-Identifier: GPL-2.0 + +======================= +The 53c700 Driver Notes +======================= + +General Description +=================== + +This driver supports the 53c700 and 53c700-66 chips. It also supports +the 53c710 but only in 53c700 emulation mode. It is full featured and +does sync (-66 and 710 only), disconnects and tag command queueing. + +Since the 53c700 must be interfaced to a bus, you need to wrapper the +card detector around this driver. For an example, see the +NCR_D700.[ch] or lasi700.[ch] files. + +The comments in the 53c700.[ch] files tell you which parts you need to +fill in to get the driver working. + + +Compile Time Flags +================== + +A compile time flag is:: + + CONFIG_53C700_LE_ON_BE + +define if the chipset must be supported in little endian mode on a big +endian architecture (used for the 700 on parisc). + + +Using the Chip Core Driver +========================== + +In order to plumb the 53c700 chip core driver into a working SCSI +driver, you need to know three things about the way the chip is wired +into your system (or expansion card). + +1. The clock speed of the SCSI core +2. The interrupt line used +3. The memory (or io space) location of the 53c700 registers. + +Optionally, you may also need to know other things, like how to read +the SCSI Id from the card bios or whether the chip is wired for +differential operation. + +Usually you can find items 2. and 3. from general spec. documents or +even by examining the configuration of a working driver under another +operating system. + +The clock speed is usually buried deep in the technical literature. +It is required because it is used to set up both the synchronous and +asynchronous dividers for the chip. As a general rule of thumb, +manufacturers set the clock speed at the lowest possible setting +consistent with the best operation of the chip (although some choose +to drive it off the CPU or bus clock rather than going to the expense +of an extra clock chip). The best operation clock speeds are: + +========= ===== +53c700 25MHz +53c700-66 50MHz +53c710 40Mhz +========= ===== + +Writing Your Glue Driver +======================== + +This will be a standard SCSI driver (I don't know of a good document +describing this, just copy from some other driver) with at least a +detect and release entry. + +In the detect routine, you need to allocate a struct +NCR_700_Host_Parameters sized memory area and clear it (so that the +default values for everything are 0). Then you must fill in the +parameters that matter to you (see below), plumb the NCR_700_intr +routine into the interrupt line and call NCR_700_detect with the host +template and the new parameters as arguments. You should also call +the relevant request_*_region function and place the register base +address into the 'base' pointer of the host parameters. + +In the release routine, you must free the NCR_700_Host_Parameters that +you allocated, call the corresponding release_*_region and free the +interrupt. + +Handling Interrupts +------------------- + +In general, you should just plumb the card's interrupt line in with + +request_irq(irq, NCR_700_intr, , , host); + +where host is the return from the relevant NCR_700_detect() routine. + +You may also write your own interrupt handling routine which calls +NCR_700_intr() directly. However, you should only really do this if +you have a card with more than one chip on it and you can read a +register to tell which set of chips wants the interrupt. + +Settable NCR_700_Host_Parameters +-------------------------------- + +The following are a list of the user settable parameters: + +clock: (MANDATORY) + Set to the clock speed of the chip in MHz. + +base: (MANDATORY) + Set to the base of the io or mem region for the register set. On 64 + bit architectures this is only 32 bits wide, so the registers must be + mapped into the low 32 bits of memory. + +pci_dev: (OPTIONAL) + Set to the PCI board device. Leave NULL for a non-pci board. This is + used for the pci_alloc_consistent() and pci_map_*() functions. + +dmode_extra: (OPTIONAL, 53c710 only) + Extra flags for the DMODE register. These are used to control bus + output pins on the 710. The settings should be a combination of + DMODE_FC1 and DMODE_FC2. What these pins actually do is entirely up + to the board designer. Usually it is safe to ignore this setting. + +differential: (OPTIONAL) + Set to 1 if the chip drives a differential bus. + +force_le_on_be: (OPTIONAL, only if CONFIG_53C700_LE_ON_BE is set) + Set to 1 if the chip is operating in little endian mode on a big + endian architecture. + +chip710: (OPTIONAL) + Set to 1 if the chip is a 53c710. + +burst_disable: (OPTIONAL, 53c710 only) + Disable 8 byte bursting for DMA transfers. diff --git a/Documentation/scsi/53c700.txt b/Documentation/scsi/53c700.txt deleted file mode 100644 index e31aceb6df15..000000000000 --- a/Documentation/scsi/53c700.txt +++ /dev/null @@ -1,135 +0,0 @@ -General Description -=================== - -This driver supports the 53c700 and 53c700-66 chips. It also supports -the 53c710 but only in 53c700 emulation mode. It is full featured and -does sync (-66 and 710 only), disconnects and tag command queueing. - -Since the 53c700 must be interfaced to a bus, you need to wrapper the -card detector around this driver. For an example, see the -NCR_D700.[ch] or lasi700.[ch] files. - -The comments in the 53c700.[ch] files tell you which parts you need to -fill in to get the driver working. - - -Compile Time Flags -================== - -A compile time flag is: - -CONFIG_53C700_LE_ON_BE - -define if the chipset must be supported in little endian mode on a big -endian architecture (used for the 700 on parisc). - - -Using the Chip Core Driver -========================== - -In order to plumb the 53c700 chip core driver into a working SCSI -driver, you need to know three things about the way the chip is wired -into your system (or expansion card). - -1. The clock speed of the SCSI core -2. The interrupt line used -3. The memory (or io space) location of the 53c700 registers. - -Optionally, you may also need to know other things, like how to read -the SCSI Id from the card bios or whether the chip is wired for -differential operation. - -Usually you can find items 2. and 3. from general spec. documents or -even by examining the configuration of a working driver under another -operating system. - -The clock speed is usually buried deep in the technical literature. -It is required because it is used to set up both the synchronous and -asynchronous dividers for the chip. As a general rule of thumb, -manufacturers set the clock speed at the lowest possible setting -consistent with the best operation of the chip (although some choose -to drive it off the CPU or bus clock rather than going to the expense -of an extra clock chip). The best operation clock speeds are: - -53c700 - 25MHz -53c700-66 - 50MHz -53c710 - 40Mhz - -Writing Your Glue Driver -======================== - -This will be a standard SCSI driver (I don't know of a good document -describing this, just copy from some other driver) with at least a -detect and release entry. - -In the detect routine, you need to allocate a struct -NCR_700_Host_Parameters sized memory area and clear it (so that the -default values for everything are 0). Then you must fill in the -parameters that matter to you (see below), plumb the NCR_700_intr -routine into the interrupt line and call NCR_700_detect with the host -template and the new parameters as arguments. You should also call -the relevant request_*_region function and place the register base -address into the `base' pointer of the host parameters. - -In the release routine, you must free the NCR_700_Host_Parameters that -you allocated, call the corresponding release_*_region and free the -interrupt. - -Handling Interrupts -------------------- - -In general, you should just plumb the card's interrupt line in with - -request_irq(irq, NCR_700_intr, , , host); - -where host is the return from the relevant NCR_700_detect() routine. - -You may also write your own interrupt handling routine which calls -NCR_700_intr() directly. However, you should only really do this if -you have a card with more than one chip on it and you can read a -register to tell which set of chips wants the interrupt. - -Settable NCR_700_Host_Parameters --------------------------------- - -The following are a list of the user settable parameters: - -clock: (MANDATORY) - -Set to the clock speed of the chip in MHz. - -base: (MANDATORY) - -set to the base of the io or mem region for the register set. On 64 -bit architectures this is only 32 bits wide, so the registers must be -mapped into the low 32 bits of memory. - -pci_dev: (OPTIONAL) - -set to the PCI board device. Leave NULL for a non-pci board. This is -used for the pci_alloc_consistent() and pci_map_*() functions. - -dmode_extra: (OPTIONAL, 53c710 only) - -extra flags for the DMODE register. These are used to control bus -output pins on the 710. The settings should be a combination of -DMODE_FC1 and DMODE_FC2. What these pins actually do is entirely up -to the board designer. Usually it is safe to ignore this setting. - -differential: (OPTIONAL) - -set to 1 if the chip drives a differential bus. - -force_le_on_be: (OPTIONAL, only if CONFIG_53C700_LE_ON_BE is set) - -set to 1 if the chip is operating in little endian mode on a big -endian architecture. - -chip710: (OPTIONAL) - -set to 1 if the chip is a 53c710. - -burst_disable: (OPTIONAL, 53c710 only) - -disable 8 byte bursting for DMA transfers. - diff --git a/Documentation/scsi/index.rst b/Documentation/scsi/index.rst index 3ef7ad65372a..99efc77c3ac2 100644 --- a/Documentation/scsi/index.rst +++ b/Documentation/scsi/index.rst @@ -7,4 +7,6 @@ Linux SCSI Subsystem .. toctree:: :maxdepth: 1 + 53c700 + scsi_transport_srp/figures -- cgit v1.2.3 From dd9cc1447ad39ddf09224357396d5e5175fb44dc Mon Sep 17 00:00:00 2001 From: Mauro Carvalho Chehab Date: Mon, 2 Mar 2020 09:15:37 +0100 Subject: scsi: docs: convert aacraid.txt to ReST Link: https://lore.kernel.org/r/67c60ad88777c91937d49771e2a3f48cbf353e4c.1583136624.git.mchehab+huawei@kernel.org Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Martin K. Petersen --- Documentation/scsi/aacraid.rst | 177 +++++++++++++++++++++++++++++++++++++++++ Documentation/scsi/aacraid.txt | 150 ---------------------------------- Documentation/scsi/index.rst | 1 + 3 files changed, 178 insertions(+), 150 deletions(-) create mode 100644 Documentation/scsi/aacraid.rst delete mode 100644 Documentation/scsi/aacraid.txt (limited to 'Documentation/scsi') diff --git a/Documentation/scsi/aacraid.rst b/Documentation/scsi/aacraid.rst new file mode 100644 index 000000000000..1904674b94f3 --- /dev/null +++ b/Documentation/scsi/aacraid.rst @@ -0,0 +1,177 @@ +.. SPDX-License-Identifier: GPL-2.0 + +=================================== +AACRAID Driver for Linux (take two) +=================================== + +Introduction +============ +The aacraid driver adds support for Adaptec (http://www.adaptec.com) +RAID controllers. This is a major rewrite from the original +Adaptec supplied driver. It has significantly cleaned up both the code +and the running binary size (the module is less than half the size of +the original). + +Supported Cards/Chipsets +======================== + + =================== ======= ======================================= + PCI ID (pci.ids) OEM Product + =================== ======= ======================================= + 9005:0285:9005:0285 Adaptec 2200S (Vulcan) + 9005:0285:9005:0286 Adaptec 2120S (Crusader) + 9005:0285:9005:0287 Adaptec 2200S (Vulcan-2m) + 9005:0285:9005:0288 Adaptec 3230S (Harrier) + 9005:0285:9005:0289 Adaptec 3240S (Tornado) + 9005:0285:9005:028a Adaptec 2020ZCR (Skyhawk) + 9005:0285:9005:028b Adaptec 2025ZCR (Terminator) + 9005:0286:9005:028c Adaptec 2230S (Lancer) + 9005:0286:9005:028c Adaptec 2230SLP (Lancer) + 9005:0286:9005:028d Adaptec 2130S (Lancer) + 9005:0285:9005:028e Adaptec 2020SA (Skyhawk) + 9005:0285:9005:028f Adaptec 2025SA (Terminator) + 9005:0285:9005:0290 Adaptec 2410SA (Jaguar) + 9005:0285:103c:3227 Adaptec 2610SA (Bearcat HP release) + 9005:0285:9005:0293 Adaptec 21610SA (Corsair-16) + 9005:0285:9005:0296 Adaptec 2240S (SabreExpress) + 9005:0285:9005:0292 Adaptec 2810SA (Corsair-8) + 9005:0285:9005:0297 Adaptec 4005 (AvonPark) + 9005:0285:9005:0298 Adaptec 4000 (BlackBird) + 9005:0285:9005:0299 Adaptec 4800SAS (Marauder-X) + 9005:0285:9005:029a Adaptec 4805SAS (Marauder-E) + 9005:0286:9005:029b Adaptec 2820SA (Intruder) + 9005:0286:9005:029c Adaptec 2620SA (Intruder) + 9005:0286:9005:029d Adaptec 2420SA (Intruder HP release) + 9005:0286:9005:02ac Adaptec 1800 (Typhoon44) + 9005:0285:9005:02b5 Adaptec 5445 (Voodoo44) + 9005:0285:15d9:02b5 SMC AOC-USAS-S4i + 9005:0285:9005:02b6 Adaptec 5805 (Voodoo80) + 9005:0285:15d9:02b6 SMC AOC-USAS-S8i + 9005:0285:9005:02b7 Adaptec 5085 (Voodoo08) + 9005:0285:9005:02bb Adaptec 3405 (Marauder40LP) + 9005:0285:9005:02bc Adaptec 3805 (Marauder80LP) + 9005:0285:9005:02c7 Adaptec 3085 (Marauder08ELP) + 9005:0285:9005:02bd Adaptec 31205 (Marauder120) + 9005:0285:9005:02be Adaptec 31605 (Marauder160) + 9005:0285:9005:02c3 Adaptec 51205 (Voodoo120) + 9005:0285:9005:02c4 Adaptec 51605 (Voodoo160) + 9005:0285:15d9:02c9 SMC AOC-USAS-S4iR + 9005:0285:15d9:02ca SMC AOC-USAS-S8iR + 9005:0285:9005:02ce Adaptec 51245 (Voodoo124) + 9005:0285:9005:02cf Adaptec 51645 (Voodoo164) + 9005:0285:9005:02d0 Adaptec 52445 (Voodoo244) + 9005:0285:9005:02d1 Adaptec 5405 (Voodoo40) + 9005:0285:15d9:02d2 SMC AOC-USAS-S8i-LP + 9005:0285:15d9:02d3 SMC AOC-USAS-S8iR-LP + 9005:0285:9005:02d4 Adaptec ASR-2045 (Voodoo04 Lite) + 9005:0285:9005:02d5 Adaptec ASR-2405 (Voodoo40 Lite) + 9005:0285:9005:02d6 Adaptec ASR-2445 (Voodoo44 Lite) + 9005:0285:9005:02d7 Adaptec ASR-2805 (Voodoo80 Lite) + 9005:0285:9005:02d8 Adaptec 5405Z (Voodoo40 BLBU) + 9005:0285:9005:02d9 Adaptec 5445Z (Voodoo44 BLBU) + 9005:0285:9005:02da Adaptec 5805Z (Voodoo80 BLBU) + 1011:0046:9005:0364 Adaptec 5400S (Mustang) + 1011:0046:9005:0365 Adaptec 5400S (Mustang) + 9005:0287:9005:0800 Adaptec Themisto (Jupiter) + 9005:0200:9005:0200 Adaptec Themisto (Jupiter) + 9005:0286:9005:0800 Adaptec Callisto (Jupiter) + 1011:0046:9005:1364 Dell PERC 2/QC (Quad Channel, Mustang) + 1011:0046:9005:1365 Dell PERC 2/QC (Quad Channel, Mustang) + 1028:0001:1028:0001 Dell PERC 2/Si (Iguana) + 1028:0003:1028:0003 Dell PERC 3/Si (SlimFast) + 1028:0002:1028:0002 Dell PERC 3/Di (Opal) + 1028:0004:1028:0004 Dell PERC 3/SiF (Iguana) + 1028:0004:1028:00d0 Dell PERC 3/DiF (Iguana) + 1028:0002:1028:00d1 Dell PERC 3/DiV (Viper) + 1028:0002:1028:00d9 Dell PERC 3/DiL (Lexus) + 1028:000a:1028:0106 Dell PERC 3/DiJ (Jaguar) + 1028:000a:1028:011b Dell PERC 3/DiD (Dagger) + 1028:000a:1028:0121 Dell PERC 3/DiB (Boxster) + 9005:0285:1028:0287 Dell PERC 320/DC (Vulcan) + 9005:0285:1028:0291 Dell CERC 2 (DellCorsair) + 1011:0046:103c:10c2 HP NetRAID-4M (Mustang) + 9005:0285:17aa:0286 Legend S220 (Crusader) + 9005:0285:17aa:0287 Legend S230 (Vulcan) + 9005:0285:9005:0290 IBM ServeRAID 7t (Jaguar) + 9005:0285:1014:02F2 IBM ServeRAID 8i (AvonPark) + 9005:0286:1014:9540 IBM ServeRAID 8k/8k-l4 (AuroraLite) + 9005:0286:1014:9580 IBM ServeRAID 8k/8k-l8 (Aurora) + 9005:0285:1014:034d IBM ServeRAID 8s (Marauder-E) + 9005:0286:9005:029e ICP ICP9024RO (Lancer) + 9005:0286:9005:029f ICP ICP9014RO (Lancer) + 9005:0286:9005:02a0 ICP ICP9047MA (Lancer) + 9005:0286:9005:02a1 ICP ICP9087MA (Lancer) + 9005:0285:9005:02a4 ICP ICP9085LI (Marauder-X) + 9005:0285:9005:02a5 ICP ICP5085BR (Marauder-E) + 9005:0286:9005:02a6 ICP ICP9067MA (Intruder-6) + 9005:0285:9005:02b2 ICP (Voodoo 8 internal 8 external) + 9005:0285:9005:02b8 ICP ICP5445SL (Voodoo44) + 9005:0285:9005:02b9 ICP ICP5085SL (Voodoo80) + 9005:0285:9005:02ba ICP ICP5805SL (Voodoo08) + 9005:0285:9005:02bf ICP ICP5045BL (Marauder40LP) + 9005:0285:9005:02c0 ICP ICP5085BL (Marauder80LP) + 9005:0285:9005:02c8 ICP ICP5805BL (Marauder08ELP) + 9005:0285:9005:02c1 ICP ICP5125BR (Marauder120) + 9005:0285:9005:02c2 ICP ICP5165BR (Marauder160) + 9005:0285:9005:02c5 ICP ICP5125SL (Voodoo120) + 9005:0285:9005:02c6 ICP ICP5165SL (Voodoo160) + 9005:0286:9005:02ab (Typhoon40) + 9005:0286:9005:02ad (Aurora ARK) + 9005:0286:9005:02ae (Aurora Lite ARK) + 9005:0285:9005:02b0 (Sunrise Lake ARK) + 9005:0285:9005:02b1 Adaptec (Voodoo 8 internal 8 external) + 9005:0285:108e:7aac SUN STK RAID REM (Voodoo44 Coyote) + 9005:0285:108e:0286 SUN STK RAID INT (Cougar) + 9005:0285:108e:0287 SUN STK RAID EXT (Prometheus) + 9005:0285:108e:7aae SUN STK RAID EM (Narvi) + =================== ======= ======================================= + +People +====== + +Alan Cox + +Christoph Hellwig + +- updates for new-style PCI probing and SCSI host registration, + small cleanups/fixes + +Matt Domsch + +- revision ioctl, adapter messages + +Deanna Bonds + +- non-DASD support, PAE fibs and 64 bit, added new adaptec controllers + added new ioctls, changed scsi interface to use new error handler, + increased the number of fibs and outstanding commands to a container +- fixed 64bit and 64G memory model, changed confusing naming convention + where fibs that go to the hardware are consistently called hw_fibs and + not just fibs like the name of the driver tracking structure + +Mark Salyzyn + +- Fixed panic issues and added some new product ids for upcoming hbas. +- Performance tuning, card failover and bug mitigations. + +Achim Leubner + +- Original Driver + +------------------------- + +Adaptec Unix OEM Product Group + +Mailing List +============ + +linux-scsi@vger.kernel.org (Interested parties troll here) +Also note this is very different to Brian's original driver +so don't expect him to support it. + +Adaptec does support this driver. Contact Adaptec tech support or +aacraid@adaptec.com + +Original by Brian Boerner February 2001 + +Rewritten by Alan Cox, November 2001 diff --git a/Documentation/scsi/aacraid.txt b/Documentation/scsi/aacraid.txt deleted file mode 100644 index 30f643f611b2..000000000000 --- a/Documentation/scsi/aacraid.txt +++ /dev/null @@ -1,150 +0,0 @@ -AACRAID Driver for Linux (take two) - -Introduction -------------------------- -The aacraid driver adds support for Adaptec (http://www.adaptec.com) -RAID controllers. This is a major rewrite from the original -Adaptec supplied driver. It has significantly cleaned up both the code -and the running binary size (the module is less than half the size of -the original). - -Supported Cards/Chipsets -------------------------- - PCI ID (pci.ids) OEM Product - 9005:0285:9005:0285 Adaptec 2200S (Vulcan) - 9005:0285:9005:0286 Adaptec 2120S (Crusader) - 9005:0285:9005:0287 Adaptec 2200S (Vulcan-2m) - 9005:0285:9005:0288 Adaptec 3230S (Harrier) - 9005:0285:9005:0289 Adaptec 3240S (Tornado) - 9005:0285:9005:028a Adaptec 2020ZCR (Skyhawk) - 9005:0285:9005:028b Adaptec 2025ZCR (Terminator) - 9005:0286:9005:028c Adaptec 2230S (Lancer) - 9005:0286:9005:028c Adaptec 2230SLP (Lancer) - 9005:0286:9005:028d Adaptec 2130S (Lancer) - 9005:0285:9005:028e Adaptec 2020SA (Skyhawk) - 9005:0285:9005:028f Adaptec 2025SA (Terminator) - 9005:0285:9005:0290 Adaptec 2410SA (Jaguar) - 9005:0285:103c:3227 Adaptec 2610SA (Bearcat HP release) - 9005:0285:9005:0293 Adaptec 21610SA (Corsair-16) - 9005:0285:9005:0296 Adaptec 2240S (SabreExpress) - 9005:0285:9005:0292 Adaptec 2810SA (Corsair-8) - 9005:0285:9005:0297 Adaptec 4005 (AvonPark) - 9005:0285:9005:0298 Adaptec 4000 (BlackBird) - 9005:0285:9005:0299 Adaptec 4800SAS (Marauder-X) - 9005:0285:9005:029a Adaptec 4805SAS (Marauder-E) - 9005:0286:9005:029b Adaptec 2820SA (Intruder) - 9005:0286:9005:029c Adaptec 2620SA (Intruder) - 9005:0286:9005:029d Adaptec 2420SA (Intruder HP release) - 9005:0286:9005:02ac Adaptec 1800 (Typhoon44) - 9005:0285:9005:02b5 Adaptec 5445 (Voodoo44) - 9005:0285:15d9:02b5 SMC AOC-USAS-S4i - 9005:0285:9005:02b6 Adaptec 5805 (Voodoo80) - 9005:0285:15d9:02b6 SMC AOC-USAS-S8i - 9005:0285:9005:02b7 Adaptec 5085 (Voodoo08) - 9005:0285:9005:02bb Adaptec 3405 (Marauder40LP) - 9005:0285:9005:02bc Adaptec 3805 (Marauder80LP) - 9005:0285:9005:02c7 Adaptec 3085 (Marauder08ELP) - 9005:0285:9005:02bd Adaptec 31205 (Marauder120) - 9005:0285:9005:02be Adaptec 31605 (Marauder160) - 9005:0285:9005:02c3 Adaptec 51205 (Voodoo120) - 9005:0285:9005:02c4 Adaptec 51605 (Voodoo160) - 9005:0285:15d9:02c9 SMC AOC-USAS-S4iR - 9005:0285:15d9:02ca SMC AOC-USAS-S8iR - 9005:0285:9005:02ce Adaptec 51245 (Voodoo124) - 9005:0285:9005:02cf Adaptec 51645 (Voodoo164) - 9005:0285:9005:02d0 Adaptec 52445 (Voodoo244) - 9005:0285:9005:02d1 Adaptec 5405 (Voodoo40) - 9005:0285:15d9:02d2 SMC AOC-USAS-S8i-LP - 9005:0285:15d9:02d3 SMC AOC-USAS-S8iR-LP - 9005:0285:9005:02d4 Adaptec ASR-2045 (Voodoo04 Lite) - 9005:0285:9005:02d5 Adaptec ASR-2405 (Voodoo40 Lite) - 9005:0285:9005:02d6 Adaptec ASR-2445 (Voodoo44 Lite) - 9005:0285:9005:02d7 Adaptec ASR-2805 (Voodoo80 Lite) - 9005:0285:9005:02d8 Adaptec 5405Z (Voodoo40 BLBU) - 9005:0285:9005:02d9 Adaptec 5445Z (Voodoo44 BLBU) - 9005:0285:9005:02da Adaptec 5805Z (Voodoo80 BLBU) - 1011:0046:9005:0364 Adaptec 5400S (Mustang) - 1011:0046:9005:0365 Adaptec 5400S (Mustang) - 9005:0287:9005:0800 Adaptec Themisto (Jupiter) - 9005:0200:9005:0200 Adaptec Themisto (Jupiter) - 9005:0286:9005:0800 Adaptec Callisto (Jupiter) - 1011:0046:9005:1364 Dell PERC 2/QC (Quad Channel, Mustang) - 1011:0046:9005:1365 Dell PERC 2/QC (Quad Channel, Mustang) - 1028:0001:1028:0001 Dell PERC 2/Si (Iguana) - 1028:0003:1028:0003 Dell PERC 3/Si (SlimFast) - 1028:0002:1028:0002 Dell PERC 3/Di (Opal) - 1028:0004:1028:0004 Dell PERC 3/SiF (Iguana) - 1028:0004:1028:00d0 Dell PERC 3/DiF (Iguana) - 1028:0002:1028:00d1 Dell PERC 3/DiV (Viper) - 1028:0002:1028:00d9 Dell PERC 3/DiL (Lexus) - 1028:000a:1028:0106 Dell PERC 3/DiJ (Jaguar) - 1028:000a:1028:011b Dell PERC 3/DiD (Dagger) - 1028:000a:1028:0121 Dell PERC 3/DiB (Boxster) - 9005:0285:1028:0287 Dell PERC 320/DC (Vulcan) - 9005:0285:1028:0291 Dell CERC 2 (DellCorsair) - 1011:0046:103c:10c2 HP NetRAID-4M (Mustang) - 9005:0285:17aa:0286 Legend S220 (Crusader) - 9005:0285:17aa:0287 Legend S230 (Vulcan) - 9005:0285:9005:0290 IBM ServeRAID 7t (Jaguar) - 9005:0285:1014:02F2 IBM ServeRAID 8i (AvonPark) - 9005:0286:1014:9540 IBM ServeRAID 8k/8k-l4 (AuroraLite) - 9005:0286:1014:9580 IBM ServeRAID 8k/8k-l8 (Aurora) - 9005:0285:1014:034d IBM ServeRAID 8s (Marauder-E) - 9005:0286:9005:029e ICP ICP9024RO (Lancer) - 9005:0286:9005:029f ICP ICP9014RO (Lancer) - 9005:0286:9005:02a0 ICP ICP9047MA (Lancer) - 9005:0286:9005:02a1 ICP ICP9087MA (Lancer) - 9005:0285:9005:02a4 ICP ICP9085LI (Marauder-X) - 9005:0285:9005:02a5 ICP ICP5085BR (Marauder-E) - 9005:0286:9005:02a6 ICP ICP9067MA (Intruder-6) - 9005:0285:9005:02b2 ICP (Voodoo 8 internal 8 external) - 9005:0285:9005:02b8 ICP ICP5445SL (Voodoo44) - 9005:0285:9005:02b9 ICP ICP5085SL (Voodoo80) - 9005:0285:9005:02ba ICP ICP5805SL (Voodoo08) - 9005:0285:9005:02bf ICP ICP5045BL (Marauder40LP) - 9005:0285:9005:02c0 ICP ICP5085BL (Marauder80LP) - 9005:0285:9005:02c8 ICP ICP5805BL (Marauder08ELP) - 9005:0285:9005:02c1 ICP ICP5125BR (Marauder120) - 9005:0285:9005:02c2 ICP ICP5165BR (Marauder160) - 9005:0285:9005:02c5 ICP ICP5125SL (Voodoo120) - 9005:0285:9005:02c6 ICP ICP5165SL (Voodoo160) - 9005:0286:9005:02ab (Typhoon40) - 9005:0286:9005:02ad (Aurora ARK) - 9005:0286:9005:02ae (Aurora Lite ARK) - 9005:0285:9005:02b0 (Sunrise Lake ARK) - 9005:0285:9005:02b1 Adaptec (Voodoo 8 internal 8 external) - 9005:0285:108e:7aac SUN STK RAID REM (Voodoo44 Coyote) - 9005:0285:108e:0286 SUN STK RAID INT (Cougar) - 9005:0285:108e:0287 SUN STK RAID EXT (Prometheus) - 9005:0285:108e:7aae SUN STK RAID EM (Narvi) - -People -------------------------- -Alan Cox -Christoph Hellwig (updates for new-style PCI probing and SCSI host registration, - small cleanups/fixes) -Matt Domsch (revision ioctl, adapter messages) -Deanna Bonds (non-DASD support, PAE fibs and 64 bit, added new adaptec controllers - added new ioctls, changed scsi interface to use new error handler, - increased the number of fibs and outstanding commands to a container) - - (fixed 64bit and 64G memory model, changed confusing naming convention - where fibs that go to the hardware are consistently called hw_fibs and - not just fibs like the name of the driver tracking structure) -Mark Salyzyn Fixed panic issues and added some new product ids for upcoming hbas. Performance tuning, card failover and bug mitigations. -Achim Leubner - -Original Driver -------------------------- -Adaptec Unix OEM Product Group - -Mailing List -------------------------- -linux-scsi@vger.kernel.org (Interested parties troll here) -Also note this is very different to Brian's original driver -so don't expect him to support it. -Adaptec does support this driver. Contact Adaptec tech support or -aacraid@adaptec.com - -Original by Brian Boerner February 2001 -Rewritten by Alan Cox, November 2001 diff --git a/Documentation/scsi/index.rst b/Documentation/scsi/index.rst index 99efc77c3ac2..2e0429d1a7a5 100644 --- a/Documentation/scsi/index.rst +++ b/Documentation/scsi/index.rst @@ -8,5 +8,6 @@ Linux SCSI Subsystem :maxdepth: 1 53c700 + aacraid scsi_transport_srp/figures -- cgit v1.2.3 From cb3224089417af6c1f6526303c0c7bd1c76652e8 Mon Sep 17 00:00:00 2001 From: Mauro Carvalho Chehab Date: Mon, 2 Mar 2020 09:15:38 +0100 Subject: scsi: docs: convert advansys.txt to ReST Link: https://lore.kernel.org/r/3c697a046e641c81cdfd0784f037d41d54766931.1583136624.git.mchehab+huawei@kernel.org Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Martin K. Petersen --- Documentation/scsi/advansys.rst | 272 ++++++++++++++++++++++++++++++++++++++++ Documentation/scsi/advansys.txt | 243 ----------------------------------- Documentation/scsi/index.rst | 1 + 3 files changed, 273 insertions(+), 243 deletions(-) create mode 100644 Documentation/scsi/advansys.rst delete mode 100644 Documentation/scsi/advansys.txt (limited to 'Documentation/scsi') diff --git a/Documentation/scsi/advansys.rst b/Documentation/scsi/advansys.rst new file mode 100644 index 000000000000..e0367e179696 --- /dev/null +++ b/Documentation/scsi/advansys.rst @@ -0,0 +1,272 @@ +.. SPDX-License-Identifier: GPL-2.0 + +===================== +AdvanSys Driver Notes +===================== + +AdvanSys (Advanced System Products, Inc.) manufactures the following +RISC-based, Bus-Mastering, Fast (10 Mhz) and Ultra (20 Mhz) Narrow +(8-bit transfer) SCSI Host Adapters for the ISA, EISA, VL, and PCI +buses and RISC-based, Bus-Mastering, Ultra (20 Mhz) Wide (16-bit +transfer) SCSI Host Adapters for the PCI bus. + +The CDB counts below indicate the number of SCSI CDB (Command +Descriptor Block) requests that can be stored in the RISC chip +cache and board LRAM. A CDB is a single SCSI command. The driver +detect routine will display the number of CDBs available for each +adapter detected. The number of CDBs used by the driver can be +lowered in the BIOS by changing the 'Host Queue Size' adapter setting. + +Laptop Products: + - ABP-480 - Bus-Master CardBus (16 CDB) + +Connectivity Products: + - ABP510/5150 - Bus-Master ISA (240 CDB) + - ABP5140 - Bus-Master ISA PnP (16 CDB) + - ABP5142 - Bus-Master ISA PnP with floppy (16 CDB) + - ABP902/3902 - Bus-Master PCI (16 CDB) + - ABP3905 - Bus-Master PCI (16 CDB) + - ABP915 - Bus-Master PCI (16 CDB) + - ABP920 - Bus-Master PCI (16 CDB) + - ABP3922 - Bus-Master PCI (16 CDB) + - ABP3925 - Bus-Master PCI (16 CDB) + - ABP930 - Bus-Master PCI (16 CDB) + - ABP930U - Bus-Master PCI Ultra (16 CDB) + - ABP930UA - Bus-Master PCI Ultra (16 CDB) + - ABP960 - Bus-Master PCI MAC/PC (16 CDB) + - ABP960U - Bus-Master PCI MAC/PC Ultra (16 CDB) + +Single Channel Products: + - ABP542 - Bus-Master ISA with floppy (240 CDB) + - ABP742 - Bus-Master EISA (240 CDB) + - ABP842 - Bus-Master VL (240 CDB) + - ABP940 - Bus-Master PCI (240 CDB) + - ABP940U - Bus-Master PCI Ultra (240 CDB) + - ABP940UA/3940UA - Bus-Master PCI Ultra (240 CDB) + - ABP970 - Bus-Master PCI MAC/PC (240 CDB) + - ABP970U - Bus-Master PCI MAC/PC Ultra (240 CDB) + - ABP3960UA - Bus-Master PCI MAC/PC Ultra (240 CDB) + - ABP940UW/3940UW - Bus-Master PCI Ultra-Wide (253 CDB) + - ABP970UW - Bus-Master PCI MAC/PC Ultra-Wide (253 CDB) + - ABP3940U2W - Bus-Master PCI LVD/Ultra2-Wide (253 CDB) + +Multi-Channel Products: + - ABP752 - Dual Channel Bus-Master EISA (240 CDB Per Channel) + - ABP852 - Dual Channel Bus-Master VL (240 CDB Per Channel) + - ABP950 - Dual Channel Bus-Master PCI (240 CDB Per Channel) + - ABP950UW - Dual Channel Bus-Master PCI Ultra-Wide (253 CDB Per Channel) + - ABP980 - Four Channel Bus-Master PCI (240 CDB Per Channel) + - ABP980U - Four Channel Bus-Master PCI Ultra (240 CDB Per Channel) + - ABP980UA/3980UA - Four Channel Bus-Master PCI Ultra (16 CDB Per Chan.) + - ABP3950U2W - Bus-Master PCI LVD/Ultra2-Wide and Ultra-Wide (253 CDB) + - ABP3950U3W - Bus-Master PCI Dual LVD2/Ultra3-Wide (253 CDB) + +Driver Compile Time Options and Debugging +========================================= + +The following constants can be defined in the source file. + +1. ADVANSYS_ASSERT - Enable driver assertions (Def: Enabled) + + Enabling this option adds assertion logic statements to the + driver. If an assertion fails a message will be displayed to + the console, but the system will continue to operate. Any + assertions encountered should be reported to the person + responsible for the driver. Assertion statements may proactively + detect problems with the driver and facilitate fixing these + problems. Enabling assertions will add a small overhead to the + execution of the driver. + +2. ADVANSYS_DEBUG - Enable driver debugging (Def: Disabled) + + Enabling this option adds tracing functions to the driver and the + ability to set a driver tracing level at boot time. This option is + very useful for debugging the driver, but it will add to the size + of the driver execution image and add overhead to the execution of + the driver. + + The amount of debugging output can be controlled with the global + variable 'asc_dbglvl'. The higher the number the more output. By + default the debug level is 0. + + If the driver is loaded at boot time and the LILO Driver Option + is included in the system, the debug level can be changed by + specifying a 5th (ASC_NUM_IOPORT_PROBE + 1) I/O Port. The + first three hex digits of the pseudo I/O Port must be set to + 'deb' and the fourth hex digit specifies the debug level: 0 - F. + The following command line will look for an adapter at 0x330 + and set the debug level to 2:: + + linux advansys=0x330,0,0,0,0xdeb2 + + If the driver is built as a loadable module this variable can be + defined when the driver is loaded. The following insmod command + will set the debug level to one:: + + insmod advansys.o asc_dbglvl=1 + + Debugging Message Levels: + + + ==== ================== + 0 Errors Only + 1 High-Level Tracing + 2-N Verbose Tracing + ==== ================== + + To enable debug output to console, please make sure that: + + a. System and kernel logging is enabled (syslogd, klogd running). + b. Kernel messages are routed to console output. Check + /etc/syslog.conf for an entry similar to this:: + + kern.* /dev/console + + c. klogd is started with the appropriate -c parameter + (e.g. klogd -c 8) + + This will cause printk() messages to be be displayed on the + current console. Refer to the klogd(8) and syslogd(8) man pages + for details. + + Alternatively you can enable printk() to console with this + program. However, this is not the 'official' way to do this. + + Debug output is logged in /var/log/messages. + + :: + + main() + { + syscall(103, 7, 0, 0); + } + + Increasing LOG_BUF_LEN in kernel/printk.c to something like + 40960 allows more debug messages to be buffered in the kernel + and written to the console or log file. + +3. ADVANSYS_STATS - Enable statistics (Def: Enabled) + + Enabling this option adds statistics collection and display + through /proc to the driver. The information is useful for + monitoring driver and device performance. It will add to the + size of the driver execution image and add minor overhead to + the execution of the driver. + + Statistics are maintained on a per adapter basis. Driver entry + point call counts and transfer size counts are maintained. + Statistics are only available for kernels greater than or equal + to v1.3.0 with the CONFIG_PROC_FS (/proc) file system configured. + + AdvanSys SCSI adapter files have the following path name format:: + + /proc/scsi/advansys/{0,1,2,3,...} + + This information can be displayed with cat. For example:: + + cat /proc/scsi/advansys/0 + + When ADVANSYS_STATS is not defined the AdvanSys /proc files only + contain adapter and device configuration information. + +Driver LILO Option +================== + +If init/main.c is modified as described in the 'Directions for Adding +the AdvanSys Driver to Linux' section (B.4.) above, the driver will +recognize the 'advansys' LILO command line and /etc/lilo.conf option. +This option can be used to either disable I/O port scanning or to limit +scanning to 1 - 4 I/O ports. Regardless of the option setting EISA and +PCI boards will still be searched for and detected. This option only +affects searching for ISA and VL boards. + +Examples: + 1. Eliminate I/O port scanning: + + boot:: + + linux advansys= + + or:: + + boot: linux advansys=0x0 + + 2. Limit I/O port scanning to one I/O port: + + boot:: + + linux advansys=0x110 + + 3. Limit I/O port scanning to four I/O ports: + + boot:: + + linux advansys=0x110,0x210,0x230,0x330 + +For a loadable module the same effect can be achieved by setting +the 'asc_iopflag' variable and 'asc_ioport' array when loading +the driver, e.g.:: + + insmod advansys.o asc_iopflag=1 asc_ioport=0x110,0x330 + +If ADVANSYS_DEBUG is defined a 5th (ASC_NUM_IOPORT_PROBE + 1) +I/O Port may be added to specify the driver debug level. Refer to +the 'Driver Compile Time Options and Debugging' section above for +more information. + +Credits (Chronological Order) +============================= + +Bob Frey wrote the AdvanSys SCSI driver +and maintained it up to 3.3F. He continues to answer questions +and help maintain the driver. + +Nathan Hartwell provided the directions and +basis for the Linux v1.3.X changes which were included in the +1.2 release. + +Thomas E Zerucha pointed out a bug +in advansys_biosparam() which was fixed in the 1.3 release. + +Erik Ratcliffe has done testing of the +AdvanSys driver in the Caldera releases. + +Rik van Riel provided a patch to +AscWaitTixISRDone() which he found necessary to make the +driver work with a SCSI-1 disk. + +Mark Moran has helped test Ultra-Wide +support in the 3.1A driver. + +Doug Gilbert has made changes and +suggestions to improve the driver and done a lot of testing. + +Ken Mort reported a DEBUG compile bug fixed +in 3.2K. + +Tom Rini provided the CONFIG_ISA +patch and helped with PowerPC wide and narrow board support. + +Philip Blundell provided an +advansys_interrupts_enabled patch. + +Dave Jones reported the compiler +warnings generated when CONFIG_PROC_FS was not defined in +the 3.2M driver. + +Jerry Quinn fixed PowerPC support (endian +problems) for wide cards. + +Bryan Henderson helped debug narrow +card error handling. + +Manuel Veloso worked hard on PowerPC narrow +board support and fixed a bug in AscGetEEPConfig(). + +Arnaldo Carvalho de Melo made +save_flags/restore_flags changes. + +Andy Kellner continued the Advansys SCSI +driver development for ConnectCom (Version > 3.3F). + +Ken Witherow for extensive testing during the development of version 3.4. diff --git a/Documentation/scsi/advansys.txt b/Documentation/scsi/advansys.txt deleted file mode 100644 index 4a3db62b7424..000000000000 --- a/Documentation/scsi/advansys.txt +++ /dev/null @@ -1,243 +0,0 @@ -AdvanSys (Advanced System Products, Inc.) manufactures the following -RISC-based, Bus-Mastering, Fast (10 Mhz) and Ultra (20 Mhz) Narrow -(8-bit transfer) SCSI Host Adapters for the ISA, EISA, VL, and PCI -buses and RISC-based, Bus-Mastering, Ultra (20 Mhz) Wide (16-bit -transfer) SCSI Host Adapters for the PCI bus. - -The CDB counts below indicate the number of SCSI CDB (Command -Descriptor Block) requests that can be stored in the RISC chip -cache and board LRAM. A CDB is a single SCSI command. The driver -detect routine will display the number of CDBs available for each -adapter detected. The number of CDBs used by the driver can be -lowered in the BIOS by changing the 'Host Queue Size' adapter setting. - -Laptop Products: - ABP-480 - Bus-Master CardBus (16 CDB) - -Connectivity Products: - ABP510/5150 - Bus-Master ISA (240 CDB) - ABP5140 - Bus-Master ISA PnP (16 CDB) - ABP5142 - Bus-Master ISA PnP with floppy (16 CDB) - ABP902/3902 - Bus-Master PCI (16 CDB) - ABP3905 - Bus-Master PCI (16 CDB) - ABP915 - Bus-Master PCI (16 CDB) - ABP920 - Bus-Master PCI (16 CDB) - ABP3922 - Bus-Master PCI (16 CDB) - ABP3925 - Bus-Master PCI (16 CDB) - ABP930 - Bus-Master PCI (16 CDB) - ABP930U - Bus-Master PCI Ultra (16 CDB) - ABP930UA - Bus-Master PCI Ultra (16 CDB) - ABP960 - Bus-Master PCI MAC/PC (16 CDB) - ABP960U - Bus-Master PCI MAC/PC Ultra (16 CDB) - -Single Channel Products: - ABP542 - Bus-Master ISA with floppy (240 CDB) - ABP742 - Bus-Master EISA (240 CDB) - ABP842 - Bus-Master VL (240 CDB) - ABP940 - Bus-Master PCI (240 CDB) - ABP940U - Bus-Master PCI Ultra (240 CDB) - ABP940UA/3940UA - Bus-Master PCI Ultra (240 CDB) - ABP970 - Bus-Master PCI MAC/PC (240 CDB) - ABP970U - Bus-Master PCI MAC/PC Ultra (240 CDB) - ABP3960UA - Bus-Master PCI MAC/PC Ultra (240 CDB) - ABP940UW/3940UW - Bus-Master PCI Ultra-Wide (253 CDB) - ABP970UW - Bus-Master PCI MAC/PC Ultra-Wide (253 CDB) - ABP3940U2W - Bus-Master PCI LVD/Ultra2-Wide (253 CDB) - -Multi-Channel Products: - ABP752 - Dual Channel Bus-Master EISA (240 CDB Per Channel) - ABP852 - Dual Channel Bus-Master VL (240 CDB Per Channel) - ABP950 - Dual Channel Bus-Master PCI (240 CDB Per Channel) - ABP950UW - Dual Channel Bus-Master PCI Ultra-Wide (253 CDB Per Channel) - ABP980 - Four Channel Bus-Master PCI (240 CDB Per Channel) - ABP980U - Four Channel Bus-Master PCI Ultra (240 CDB Per Channel) - ABP980UA/3980UA - Four Channel Bus-Master PCI Ultra (16 CDB Per Chan.) - ABP3950U2W - Bus-Master PCI LVD/Ultra2-Wide and Ultra-Wide (253 CDB) - ABP3950U3W - Bus-Master PCI Dual LVD2/Ultra3-Wide (253 CDB) - -Driver Compile Time Options and Debugging - -The following constants can be defined in the source file. - -1. ADVANSYS_ASSERT - Enable driver assertions (Def: Enabled) - - Enabling this option adds assertion logic statements to the - driver. If an assertion fails a message will be displayed to - the console, but the system will continue to operate. Any - assertions encountered should be reported to the person - responsible for the driver. Assertion statements may proactively - detect problems with the driver and facilitate fixing these - problems. Enabling assertions will add a small overhead to the - execution of the driver. - -2. ADVANSYS_DEBUG - Enable driver debugging (Def: Disabled) - - Enabling this option adds tracing functions to the driver and the - ability to set a driver tracing level at boot time. This option is - very useful for debugging the driver, but it will add to the size - of the driver execution image and add overhead to the execution of - the driver. - - The amount of debugging output can be controlled with the global - variable 'asc_dbglvl'. The higher the number the more output. By - default the debug level is 0. - - If the driver is loaded at boot time and the LILO Driver Option - is included in the system, the debug level can be changed by - specifying a 5th (ASC_NUM_IOPORT_PROBE + 1) I/O Port. The - first three hex digits of the pseudo I/O Port must be set to - 'deb' and the fourth hex digit specifies the debug level: 0 - F. - The following command line will look for an adapter at 0x330 - and set the debug level to 2. - - linux advansys=0x330,0,0,0,0xdeb2 - - If the driver is built as a loadable module this variable can be - defined when the driver is loaded. The following insmod command - will set the debug level to one. - - insmod advansys.o asc_dbglvl=1 - - Debugging Message Levels: - 0: Errors Only - 1: High-Level Tracing - 2-N: Verbose Tracing - - To enable debug output to console, please make sure that: - - a. System and kernel logging is enabled (syslogd, klogd running). - b. Kernel messages are routed to console output. Check - /etc/syslog.conf for an entry similar to this: - - kern.* /dev/console - - c. klogd is started with the appropriate -c parameter - (e.g. klogd -c 8) - - This will cause printk() messages to be be displayed on the - current console. Refer to the klogd(8) and syslogd(8) man pages - for details. - - Alternatively you can enable printk() to console with this - program. However, this is not the 'official' way to do this. - Debug output is logged in /var/log/messages. - - main() - { - syscall(103, 7, 0, 0); - } - - Increasing LOG_BUF_LEN in kernel/printk.c to something like - 40960 allows more debug messages to be buffered in the kernel - and written to the console or log file. - -3. ADVANSYS_STATS - Enable statistics (Def: Enabled) - - Enabling this option adds statistics collection and display - through /proc to the driver. The information is useful for - monitoring driver and device performance. It will add to the - size of the driver execution image and add minor overhead to - the execution of the driver. - - Statistics are maintained on a per adapter basis. Driver entry - point call counts and transfer size counts are maintained. - Statistics are only available for kernels greater than or equal - to v1.3.0 with the CONFIG_PROC_FS (/proc) file system configured. - - AdvanSys SCSI adapter files have the following path name format: - - /proc/scsi/advansys/{0,1,2,3,...} - - This information can be displayed with cat. For example: - - cat /proc/scsi/advansys/0 - - When ADVANSYS_STATS is not defined the AdvanSys /proc files only - contain adapter and device configuration information. - -Driver LILO Option - -If init/main.c is modified as described in the 'Directions for Adding -the AdvanSys Driver to Linux' section (B.4.) above, the driver will -recognize the 'advansys' LILO command line and /etc/lilo.conf option. -This option can be used to either disable I/O port scanning or to limit -scanning to 1 - 4 I/O ports. Regardless of the option setting EISA and -PCI boards will still be searched for and detected. This option only -affects searching for ISA and VL boards. - -Examples: - 1. Eliminate I/O port scanning: - boot: linux advansys= - or - boot: linux advansys=0x0 - 2. Limit I/O port scanning to one I/O port: - boot: linux advansys=0x110 - 3. Limit I/O port scanning to four I/O ports: - boot: linux advansys=0x110,0x210,0x230,0x330 - -For a loadable module the same effect can be achieved by setting -the 'asc_iopflag' variable and 'asc_ioport' array when loading -the driver, e.g. - - insmod advansys.o asc_iopflag=1 asc_ioport=0x110,0x330 - -If ADVANSYS_DEBUG is defined a 5th (ASC_NUM_IOPORT_PROBE + 1) -I/O Port may be added to specify the driver debug level. Refer to -the 'Driver Compile Time Options and Debugging' section above for -more information. - -Credits (Chronological Order) - -Bob Frey wrote the AdvanSys SCSI driver -and maintained it up to 3.3F. He continues to answer questions -and help maintain the driver. - -Nathan Hartwell provided the directions and -basis for the Linux v1.3.X changes which were included in the -1.2 release. - -Thomas E Zerucha pointed out a bug -in advansys_biosparam() which was fixed in the 1.3 release. - -Erik Ratcliffe has done testing of the -AdvanSys driver in the Caldera releases. - -Rik van Riel provided a patch to -AscWaitTixISRDone() which he found necessary to make the -driver work with a SCSI-1 disk. - -Mark Moran has helped test Ultra-Wide -support in the 3.1A driver. - -Doug Gilbert has made changes and -suggestions to improve the driver and done a lot of testing. - -Ken Mort reported a DEBUG compile bug fixed -in 3.2K. - -Tom Rini provided the CONFIG_ISA -patch and helped with PowerPC wide and narrow board support. - -Philip Blundell provided an -advansys_interrupts_enabled patch. - -Dave Jones reported the compiler -warnings generated when CONFIG_PROC_FS was not defined in -the 3.2M driver. - -Jerry Quinn fixed PowerPC support (endian -problems) for wide cards. - -Bryan Henderson helped debug narrow -card error handling. - -Manuel Veloso worked hard on PowerPC narrow -board support and fixed a bug in AscGetEEPConfig(). - -Arnaldo Carvalho de Melo made -save_flags/restore_flags changes. - -Andy Kellner continued the Advansys SCSI -driver development for ConnectCom (Version > 3.3F). - -Ken Witherow for extensive testing during the development of version 3.4. diff --git a/Documentation/scsi/index.rst b/Documentation/scsi/index.rst index 2e0429d1a7a5..df526a0ceccf 100644 --- a/Documentation/scsi/index.rst +++ b/Documentation/scsi/index.rst @@ -9,5 +9,6 @@ Linux SCSI Subsystem 53c700 aacraid + advansys scsi_transport_srp/figures -- cgit v1.2.3 From 94b5530f1fb8e468ca0a4117f2bb0fbdca550df1 Mon Sep 17 00:00:00 2001 From: Mauro Carvalho Chehab Date: Mon, 2 Mar 2020 09:15:39 +0100 Subject: scsi: docs: convert aha152x.txt to ReST Link: https://lore.kernel.org/r/097cfcc7f25343676a1fedcefed7e3b91b41b4df.1583136624.git.mchehab+huawei@kernel.org Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Martin K. Petersen --- Documentation/scsi/aha152x.rst | 204 +++++++++++++++++++++++++++++++++ Documentation/scsi/aha152x.txt | 183 ----------------------------- Documentation/scsi/index.rst | 1 + Documentation/scsi/scsi-parameters.txt | 2 +- 4 files changed, 206 insertions(+), 184 deletions(-) create mode 100644 Documentation/scsi/aha152x.rst delete mode 100644 Documentation/scsi/aha152x.txt (limited to 'Documentation/scsi') diff --git a/Documentation/scsi/aha152x.rst b/Documentation/scsi/aha152x.rst new file mode 100644 index 000000000000..7012b5c46d5d --- /dev/null +++ b/Documentation/scsi/aha152x.rst @@ -0,0 +1,204 @@ +.. SPDX-License-Identifier: GPL-2.0 +.. include:: + +===================================================== +Adaptec AHA-1520/1522 SCSI driver for Linux (aha152x) +===================================================== + +Copyright |copy| 1993-1999 Jürgen Fischer + +TC1550 patches by Luuk van Dijk (ldz@xs4all.nl) + + +In Revision 2 the driver was modified a lot (especially the +bottom-half handler complete()). + +The driver is much cleaner now, has support for the new +error handling code in 2.3, produced less cpu load (much +less polling loops), has slightly higher throughput (at +least on my ancient test box; a i486/33Mhz/20MB). + + +Configuration Arguments +======================= + +============ ======================================== ====================== +IOPORT base io address (0x340/0x140) +IRQ interrupt level (9-12; default 11) +SCSI_ID scsi id of controller (0-7; default 7) +RECONNECT allow targets to disconnect from the bus (0/1; default 1 [on]) +PARITY enable parity checking (0/1; default 1 [on]) +SYNCHRONOUS enable synchronous transfers (0/1; default 1 [on]) +DELAY: bus reset delay (default 100) +EXT_TRANS: enable extended translation (0/1: default 0 [off]) + (see NOTES) +============ ======================================== ====================== + +Compile Time Configuration +========================== + +(go into AHA152X in drivers/scsi/Makefile): + +- DAUTOCONF + use configuration the controller reports (AHA-152x only) + +- DSKIP_BIOSTEST + Don't test for BIOS signature (AHA-1510 or disabled BIOS) + +- DSETUP0="{ IOPORT, IRQ, SCSI_ID, RECONNECT, PARITY, SYNCHRONOUS, DELAY, EXT_TRANS }" + override for the first controller + +- DSETUP1="{ IOPORT, IRQ, SCSI_ID, RECONNECT, PARITY, SYNCHRONOUS, DELAY, EXT_TRANS }" + override for the second controller + +- DAHA152X_DEBUG + enable debugging output + +- DAHA152X_STAT + enable some statistics + + +LILO Command Line Options +========================= + + :: + + aha152x=[,[,[,[,[,[, [,1GB: + + - take current geometry from the partition table + (using scsicam_bios_param and accept only 'valid' geometries, + ie. either (C/32/64) or (C/63/255)). This can be extended translation + even if it's not enabled in the driver. + + - if that fails, take extended translation if enabled by override, + kernel or module parameter, otherwise take default translation and + ask the user for verification. This might on not yet partitioned + disks. + + +References Used +=============== + + "AIC-6260 SCSI Chip Specification", Adaptec Corporation. + + "SCSI COMPUTER SYSTEM INTERFACE - 2 (SCSI-2)", X3T9.2/86-109 rev. 10h + + "Writing a SCSI device driver for Linux", Rik Faith (faith@cs.unc.edu) + + "Kernel Hacker's Guide", Michael K. Johnson (johnsonm@sunsite.unc.edu) + + "Adaptec 1520/1522 User's Guide", Adaptec Corporation. + + Michael K. Johnson (johnsonm@sunsite.unc.edu) + + Drew Eckhardt (drew@cs.colorado.edu) + + Eric Youngdale (eric@andante.org) + + special thanks to Eric Youngdale for the free(!) supplying the + documentation on the chip. diff --git a/Documentation/scsi/aha152x.txt b/Documentation/scsi/aha152x.txt deleted file mode 100644 index 94848734ac66..000000000000 --- a/Documentation/scsi/aha152x.txt +++ /dev/null @@ -1,183 +0,0 @@ -$Id: README.aha152x,v 1.2 1999/12/25 15:32:30 fischer Exp fischer $ -Adaptec AHA-1520/1522 SCSI driver for Linux (aha152x) - -Copyright 1993-1999 Jürgen Fischer -TC1550 patches by Luuk van Dijk (ldz@xs4all.nl) - - -In Revision 2 the driver was modified a lot (especially the -bottom-half handler complete()). - -The driver is much cleaner now, has support for the new -error handling code in 2.3, produced less cpu load (much -less polling loops), has slightly higher throughput (at -least on my ancient test box; a i486/33Mhz/20MB). - - -CONFIGURATION ARGUMENTS: - -IOPORT base io address (0x340/0x140) -IRQ interrupt level (9-12; default 11) -SCSI_ID scsi id of controller (0-7; default 7) -RECONNECT allow targets to disconnect from the bus (0/1; default 1 [on]) -PARITY enable parity checking (0/1; default 1 [on]) -SYNCHRONOUS enable synchronous transfers (0/1; default 1 [on]) -DELAY: bus reset delay (default 100) -EXT_TRANS: enable extended translation (0/1: default 0 [off]) - (see NOTES) - -COMPILE TIME CONFIGURATION (go into AHA152X in drivers/scsi/Makefile): - --DAUTOCONF - use configuration the controller reports (AHA-152x only) - --DSKIP_BIOSTEST - Don't test for BIOS signature (AHA-1510 or disabled BIOS) - --DSETUP0="{ IOPORT, IRQ, SCSI_ID, RECONNECT, PARITY, SYNCHRONOUS, DELAY, EXT_TRANS }" - override for the first controller - --DSETUP1="{ IOPORT, IRQ, SCSI_ID, RECONNECT, PARITY, SYNCHRONOUS, DELAY, EXT_TRANS }" - override for the second controller - --DAHA152X_DEBUG - enable debugging output - --DAHA152X_STAT - enable some statistics - - -LILO COMMAND LINE OPTIONS: - -aha152x=[,[,[,[,[,[, [,1GB: - - take current geometry from the partition table - (using scsicam_bios_param and accept only `valid' geometries, - ie. either (C/32/64) or (C/63/255)). This can be extended translation - even if it's not enabled in the driver. - - - if that fails, take extended translation if enabled by override, - kernel or module parameter, otherwise take default translation and - ask the user for verification. This might on not yet partitioned - disks. - - -REFERENCES USED: - - "AIC-6260 SCSI Chip Specification", Adaptec Corporation. - - "SCSI COMPUTER SYSTEM INTERFACE - 2 (SCSI-2)", X3T9.2/86-109 rev. 10h - - "Writing a SCSI device driver for Linux", Rik Faith (faith@cs.unc.edu) - - "Kernel Hacker's Guide", Michael K. Johnson (johnsonm@sunsite.unc.edu) - - "Adaptec 1520/1522 User's Guide", Adaptec Corporation. - - Michael K. Johnson (johnsonm@sunsite.unc.edu) - - Drew Eckhardt (drew@cs.colorado.edu) - - Eric Youngdale (eric@andante.org) - - special thanks to Eric Youngdale for the free(!) supplying the - documentation on the chip. diff --git a/Documentation/scsi/index.rst b/Documentation/scsi/index.rst index df526a0ceccf..8404e991b588 100644 --- a/Documentation/scsi/index.rst +++ b/Documentation/scsi/index.rst @@ -10,5 +10,6 @@ Linux SCSI Subsystem 53c700 aacraid advansys + aha152x scsi_transport_srp/figures diff --git a/Documentation/scsi/scsi-parameters.txt b/Documentation/scsi/scsi-parameters.txt index 25a4b4cf04a6..064d6dfcac26 100644 --- a/Documentation/scsi/scsi-parameters.txt +++ b/Documentation/scsi/scsi-parameters.txt @@ -16,7 +16,7 @@ parameters may be changed at runtime by the command See header of drivers/scsi/advansys.c. aha152x= [HW,SCSI] - See Documentation/scsi/aha152x.txt. + See Documentation/scsi/aha152x.rst. aha1542= [HW,SCSI] Format: [,,[,]] -- cgit v1.2.3 From 520a44d4dfe15ac6a0c1b79b13cc548af51467b7 Mon Sep 17 00:00:00 2001 From: Mauro Carvalho Chehab Date: Mon, 2 Mar 2020 09:15:40 +0100 Subject: scsi: docs: convert aic79xx.txt to ReST Link: https://lore.kernel.org/r/e8a40337a2173f028c9ac569d3d71fd880f4fab5.1583136624.git.mchehab+huawei@kernel.org Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Martin K. Petersen --- Documentation/scsi/aic79xx.rst | 593 +++++++++++++++++++++++++++++++++ Documentation/scsi/aic79xx.txt | 497 --------------------------- Documentation/scsi/index.rst | 1 + Documentation/scsi/scsi-parameters.txt | 2 +- 4 files changed, 595 insertions(+), 498 deletions(-) create mode 100644 Documentation/scsi/aic79xx.rst delete mode 100644 Documentation/scsi/aic79xx.txt (limited to 'Documentation/scsi') diff --git a/Documentation/scsi/aic79xx.rst b/Documentation/scsi/aic79xx.rst new file mode 100644 index 000000000000..071ff5111a4f --- /dev/null +++ b/Documentation/scsi/aic79xx.rst @@ -0,0 +1,593 @@ +.. SPDX-License-Identifier: GPL-2.0 +.. include:: + +=================================== +Adaptec Ultra320 Family Manager Set +=================================== + +README for The Linux Operating System + +.. The following information is available in this file: + + 1. Supported Hardware + 2. Version History + 3. Command Line Options + 4. Additional Notes + 5. Contacting Adaptec + + +1. Supported Hardware +===================== + + The following Adaptec SCSI Host Adapters are supported by this + driver set. + + ============= ========================================= + Ultra320 ASIC Description + ============= ========================================= + AIC-7901A Single Channel 64-bit PCI-X 133MHz to + Ultra320 SCSI ASIC + AIC-7901B Single Channel 64-bit PCI-X 133MHz to + Ultra320 SCSI ASIC with Retained Training + AIC-7902A4 Dual Channel 64-bit PCI-X 133MHz to + Ultra320 SCSI ASIC + AIC-7902B Dual Channel 64-bit PCI-X 133MHz to + Ultra320 SCSI ASIC with Retained Training + ============= ========================================= + + ========================== ===================================== ============ + Ultra320 Adapters Description ASIC + ========================== ===================================== ============ + Adaptec SCSI Card 39320 Dual Channel 64-bit PCI-X 133MHz to 7902A4/7902B + Ultra320 SCSI Card (one external + 68-pin, two internal 68-pin) + Adaptec SCSI Card 39320A Dual Channel 64-bit PCI-X 133MHz to 7902B + Ultra320 SCSI Card (one external + 68-pin, two internal 68-pin) + Adaptec SCSI Card 39320D Dual Channel 64-bit PCI-X 133MHz to 7902A4 + Ultra320 SCSI Card (two external VHDC + and one internal 68-pin) + Adaptec SCSI Card 39320D Dual Channel 64-bit PCI-X 133MHz to 7902A4 + Ultra320 SCSI Card (two external VHDC + and one internal 68-pin) based on the + AIC-7902B ASIC + Adaptec SCSI Card 29320 Single Channel 64-bit PCI-X 133MHz to 7901A + Ultra320 SCSI Card (one external + 68-pin, two internal 68-pin, one + internal 50-pin) + Adaptec SCSI Card 29320A Single Channel 64-bit PCI-X 133MHz to 7901B + Ultra320 SCSI Card (one external + 68-pin, two internal 68-pin, one + internal 50-pin) + Adaptec SCSI Card 29320LP Single Channel 64-bit Low Profile 7901A + PCI-X 133MHz to Ultra320 SCSI Card + (One external VHDC, one internal + 68-pin) + Adaptec SCSI Card 29320ALP Single Channel 64-bit Low Profile 7901B + PCI-X 133MHz to Ultra320 SCSI Card + (One external VHDC, one internal + 68-pin) + ========================== ===================================== ============ + +2. Version History +================== + + + * 3.0 (December 1st, 2005) + - Updated driver to use SCSI transport class infrastructure + - Upported sequencer and core fixes from adaptec released + version 2.0.15 of the driver. + + * 1.3.11 (July 11, 2003) + - Fix several deadlock issues. + - Add 29320ALP and 39320B Id's. + + * 1.3.10 (June 3rd, 2003) + - Align the SCB_TAG field on a 16byte boundary. This avoids + SCB corruption on some PCI-33 busses. + - Correct non-zero luns on Rev B. hardware. + - Update for change in 2.5.X SCSI proc FS interface. + - When negotiation async via an 8bit WDTR message, send + an SDTR with an offset of 0 to be sure the target + knows we are async. This works around a firmware defect + in the Quantum Atlas 10K. + - Implement controller suspend and resume. + - Clear PCI error state during driver attach so that we + don't disable memory mapped I/O due to a stray write + by some other driver probe that occurred before we + claimed the controller. + + * 1.3.9 (May 22nd, 2003) + - Fix compiler errors. + - Remove S/G splitting for segments that cross a 4GB boundary. + This is guaranteed not to happen in Linux. + - Add support for scsi_report_device_reset() found in + 2.5.X kernels. + - Add 7901B support. + - Simplify handling of the packetized lun Rev A workaround. + - Correct and simplify handling of the ignore wide residue + message. The previous code would fail to report a residual + if the transaction data length was even and we received + an IWR message. + + * 1.3.8 (April 29th, 2003) + - Fix types accessed via the command line interface code. + - Perform a few firmware optimizations. + - Fix "Unexpected PKT busfree" errors. + - Use a sequencer interrupt to notify the host of + commands with bad status. We defer the notification + until there are no outstanding selections to ensure + that the host is interrupted for as short a time as + possible. + - Remove pre-2.2.X support. + - Add support for new 2.5.X interrupt API. + - Correct big-endian architecture support. + + * 1.3.7 (April 16th, 2003) + - Use del_timer_sync() to ensure that no timeouts + are pending during controller shutdown. + - For pre-2.5.X kernels, carefully adjust our segment + list size to avoid SCSI malloc pool fragmentation. + - Cleanup channel display in our /proc output. + - Workaround duplicate device entries in the mid-layer + device list during add-single-device. + + * 1.3.6 (March 28th, 2003) + - Correct a double free in the Domain Validation code. + - Correct a reference to free'ed memory during controller + shutdown. + - Reset the bus on an SE->LVD change. This is required + to reset our transceivers. + + * 1.3.5 (March 24th, 2003) + - Fix a few register window mode bugs. + - Include read streaming in the PPR flags we display in + diagnostics as well as /proc. + - Add PCI hot plug support for 2.5.X kernels. + - Correct default precompensation value for RevA hardware. + - Fix Domain Validation thread shutdown. + - Add a firmware workaround to make the LED blink + brighter during packetized operations on the H2A4. + - Correct /proc display of user read streaming settings. + - Simplify driver locking by releasing the io_request_lock + upon driver entry from the mid-layer. + - Cleanup command line parsing and move much of this code + to aiclib. + + * 1.3.4 (February 28th, 2003) + - Correct a race condition in our error recovery handler. + - Allow Test Unit Ready commands to take a full 5 seconds + during Domain Validation. + + * 1.3.2 (February 19th, 2003) + - Correct a Rev B. regression due to the GEM318 + compatibility fix included in 1.3.1. + + * 1.3.1 (February 11th, 2003) + - Add support for the 39320A. + - Improve recovery for certain PCI-X errors. + - Fix handling of LQ/DATA/LQ/DATA for the + same write transaction that can occur without + interveining training. + - Correct compatibility issues with the GEM318 + enclosure services device. + - Correct data corruption issue that occurred under + high tag depth write loads. + - Adapt to a change in the 2.5.X daemonize() API. + - Correct a "Missing case in ahd_handle_scsiint" panic. + + * 1.3.0 (January 21st, 2003) + - Full regression testing for all U320 products completed. + - Added abort and target/lun reset error recovery handler and + interrupt coalescing. + + * 1.2.0 (November 14th, 2002) + - Added support for Domain Validation + - Add support for the Hewlett-Packard version of the 39320D + and AIC-7902 adapters. + + Support for previous adapters has not been fully tested and should + only be used at the customer's own risk. + + * 1.1.1 (September 24th, 2002) + - Added support for the Linux 2.5.X kernel series + + * 1.1.0 (September 17th, 2002) + - Added support for four additional SCSI products: + ASC-39320, ASC-29320, ASC-29320LP, AIC-7901. + + * 1.0.0 (May 30th, 2002) + - Initial driver release. + + * 2.1. Software/Hardware Features + - Support for the SPI-4 "Ultra320" standard: + - 320MB/s transfer rates + - Packetized SCSI Protocol at 160MB/s and 320MB/s + - Quick Arbitration Selection (QAS) + - Retained Training Information (Rev B. ASIC only) + - Interrupt Coalescing + - Initiator Mode (target mode not currently + supported) + - Support for the PCI-X standard up to 133MHz + - Support for the PCI v2.2 standard + - Domain Validation + + * 2.2. Operating System Support: + - Redhat Linux 7.2, 7.3, 8.0, Advanced Server 2.1 + - SuSE Linux 7.3, 8.0, 8.1, Enterprise Server 7 + - only Intel and AMD x86 supported at this time + - >4GB memory configurations supported. + + Refer to the User's Guide for more details on this. + +3. Command Line Options +======================= + + .. Warning:: + + ALTERING OR ADDING THESE DRIVER PARAMETERS + INCORRECTLY CAN RENDER YOUR SYSTEM INOPERABLE. + USE THEM WITH CAUTION. + + Put a .conf file in the /etc/modprobe.d/ directory and add/edit a + line containing ``options aic79xx aic79xx=[command[,command...]]`` where + ``command`` is one or more of the following: + + +verbose + :Definition: enable additional informative messages during driver operation. + :Possible Values: This option is a flag + :Default Value: disabled + +debug:[value] + :Definition: Enables various levels of debugging information + The bit definitions for the debugging mask can + be found in drivers/scsi/aic7xxx/aic79xx.h under + the "Debug" heading. + :Possible Values: 0x0000 = no debugging, 0xffff = full debugging + :Default Value: 0x0000 + +no_reset + :Definition: Do not reset the bus during the initial probe + phase + :Possible Values: This option is a flag + :Default Value: disabled + +extended + :Definition: Force extended translation on the controller + :Possible Values: This option is a flag + :Default Value: disabled + +periodic_otag + :Definition: Send an ordered tag periodically to prevent + tag starvation. Needed for some older devices + :Possible Values: This option is a flag + :Default Value: disabled + +reverse_scan + :Definition: Probe the scsi bus in reverse order, starting with target 15 + :Possible Values: This option is a flag + :Default Value: disabled + +global_tag_depth + :Definition: Global tag depth for all targets on all busses. + This option sets the default tag depth which + may be selectively overridden vi the tag_info + option. + + :Possible Values: 1 - 253 + :Default Value: 32 + +tag_info:{{value[,value...]}[,{value[,value...]}...]} + :Definition: Set the per-target tagged queue depth on a + per controller basis. Both controllers and targets + may be omitted indicating that they should retain + the default tag depth. + + :Possible Values: 1 - 253 + :Default Value: 32 + + Examples: + + + :: + + tag_info:{{16,32,32,64,8,8,,32,32,32,32,32,32,32,32,32} + + On Controller 0 + + - specifies a tag depth of 16 for target 0 + - specifies a tag depth of 64 for target 3 + - specifies a tag depth of 8 for targets 4 and 5 + - leaves target 6 at the default + - specifies a tag depth of 32 for targets 1,2,7-15 + + All other targets retain the default depth. + + :: + + tag_info:{{},{32,,32}} + + On Controller 1 + + - specifies a tag depth of 32 for targets 0 and 2 + + All other targets retain the default depth. + + +rd_strm: {rd_strm_bitmask[,rd_strm_bitmask...]} + :Definition: Enable read streaming on a per target basis. + The rd_strm_bitmask is a 16 bit hex value in which + each bit represents a target. Setting the target's + bit to '1' enables read streaming for that + target. Controllers may be omitted indicating that + they should retain the default read streaming setting. + + Examples: + + :: + + rd_strm:{0x0041} + + On Controller 0 + + - enables read streaming for targets 0 and 6. + - disables read streaming for targets 1-5,7-15. + + All other targets retain the default read + streaming setting. + + :: + + rd_strm:{0x0023,,0xFFFF} + + On Controller 0 + + - enables read streaming for targets 1,2, and 5. + - disables read streaming for targets 3,4,6-15. + + On Controller 2 + + - enables read streaming for all targets. + + All other targets retain the default read + streaming setting. + + :Possible Values: 0x0000 - 0xffff + :Default Value: 0x0000 + +dv: {value[,value...]} + :Definition: Set Domain Validation Policy on a per-controller basis. + Controllers may be omitted indicating that + they should retain the default read streaming setting. + + :Possible Values: + + ==== =============================== + < 0 Use setting from serial EEPROM. + 0 Disable DV + > 0 Enable DV + ==== =============================== + + :Default Value: DV Serial EEPROM configuration setting. + + Example: + + :: + + dv:{-1,0,,1,1,0} + + - On Controller 0 leave DV at its default setting. + - On Controller 1 disable DV. + - Skip configuration on Controller 2. + - On Controllers 3 and 4 enable DV. + - On Controller 5 disable DV. + +seltime:[value] + :Definition: Specifies the selection timeout value + :Possible Values: 0 = 256ms, 1 = 128ms, 2 = 64ms, 3 = 32ms + :Default Value: 0 + +.. Warning: + + The following three options should only be changed at + the direction of a technical support representative. + + +precomp: {value[,value...]} + :Definition: Set IO Cell precompensation value on a per-controller basis. + Controllers may be omitted indicating that + they should retain the default precompensation setting. + + :Possible Values: 0 - 7 + :Default Value: Varies based on chip revision + + Examples: + + :: + + precomp:{0x1} + + On Controller 0 set precompensation to 1. + + :: + + precomp:{1,,7} + + - On Controller 0 set precompensation to 1. + - On Controller 2 set precompensation to 8. + +slewrate: {value[,value...]} + :Definition: Set IO Cell slew rate on a per-controller basis. + Controllers may be omitted indicating that + they should retain the default slew rate setting. + + :Possible Values: 0 - 15 + :Default Value: Varies based on chip revision + + Examples: + + :: + + slewrate:{0x1} + + - On Controller 0 set slew rate to 1. + + :: + + slewrate :{1,,8} + + - On Controller 0 set slew rate to 1. + - On Controller 2 set slew rate to 8. + +amplitude: {value[,value...]} + :Definition: Set IO Cell signal amplitude on a per-controller basis. + Controllers may be omitted indicating that + they should retain the default read streaming setting. + + :Possible Values: 1 - 7 + :Default Value: Varies based on chip revision + + Examples: + + :: + + amplitude:{0x1} + + On Controller 0 set amplitude to 1. + + :: + + amplitude :{1,,7} + + - On Controller 0 set amplitude to 1. + - On Controller 2 set amplitude to 7. + +Example:: + + options aic79xx aic79xx=verbose,rd_strm:{{0x0041}} + +enables verbose output in the driver and turns read streaming on +for targets 0 and 6 of Controller 0. + +4. Additional Notes +=================== + +4.1. Known/Unresolved or FYI Issues +----------------------------------- + + * Under SuSE Linux Enterprise 7, the driver may fail to operate + correctly due to a problem with PCI interrupt routing in the + Linux kernel. Please contact SuSE for an updated Linux + kernel. + +4.2. Third-Party Compatibility Issues +------------------------------------- + + * Adaptec only supports Ultra320 hard drives running + the latest firmware available. Please check with + your hard drive manufacturer to ensure you have the + latest version. + +4.3. Operating System or Technology Limitations +----------------------------------------------- + + * PCI Hot Plug is untested and may cause the operating system + to stop responding. + * Luns that are not numbered contiguously starting with 0 might not + be automatically probed during system startup. This is a limitation + of the OS. Please contact your Linux vendor for instructions on + manually probing non-contiguous luns. + * Using the Driver Update Disk version of this package during OS + installation under RedHat might result in two versions of this + driver being installed into the system module directory. This + might cause problems with the /sbin/mkinitrd program and/or + other RPM packages that try to install system modules. The best + way to correct this once the system is running is to install + the latest RPM package version of this driver, available from + http://www.adaptec.com. + + +5. Adaptec Customer Support +=========================== + + A Technical Support Identification (TSID) Number is required for + Adaptec technical support. + + - The 12-digit TSID can be found on the white barcode-type label + included inside the box with your product. The TSID helps us + provide more efficient service by accurately identifying your + product and support status. + + Support Options + - Search the Adaptec Support Knowledgebase (ASK) at + http://ask.adaptec.com for articles, troubleshooting tips, and + frequently asked questions about your product. + - For support via Email, submit your question to Adaptec's + Technical Support Specialists at http://ask.adaptec.com/. + + North America + - Visit our Web site at http://www.adaptec.com/. + - For information about Adaptec's support options, call + 408-957-2550, 24 hours a day, 7 days a week. + - To speak with a Technical Support Specialist, + + * For hardware products, call 408-934-7274, + Monday to Friday, 3:00 am to 5:00 pm, PDT. + * For RAID and Fibre Channel products, call 321-207-2000, + Monday to Friday, 3:00 am to 5:00 pm, PDT. + + To expedite your service, have your computer with you. + - To order Adaptec products, including accessories and cables, + call 408-957-7274. To order cables online go to + http://www.adaptec.com/buy-cables/. + + Europe + - Visit our Web site at http://www.adaptec.com/en-US/_common/world_index. + - To speak with a Technical Support Specialist, call, or email, + + * German: +49 89 4366 5522, Monday-Friday, 9:00-17:00 CET, + http://ask-de.adaptec.com/. + * French: +49 89 4366 5533, Monday-Friday, 9:00-17:00 CET, + http://ask-fr.adaptec.com/. + * English: +49 89 4366 5544, Monday-Friday, 9:00-17:00 GMT, + http://ask.adaptec.com/. + + - You can order Adaptec cables online at + http://www.adaptec.com/buy-cables/. + + Japan + - Visit our web site at http://www.adaptec.co.jp/. + - To speak with a Technical Support Specialist, call + +81 3 5308 6120, Monday-Friday, 9:00 a.m. to 12:00 p.m., + 1:00 p.m. to 6:00 p.m. + +Copyright |copy| 2003 Adaptec Inc. 691 S. Milpitas Blvd., Milpitas CA 95035 USA. +All rights reserved. + +You are permitted to redistribute, use and modify this README file in whole +or in part in conjunction with redistribution of software governed by the +General Public License, provided that the following conditions are met: + +1. Redistributions of README file must retain the above copyright + notice, this list of conditions, and the following disclaimer, + without modification. +2. The name of the author may not be used to endorse or promote products + derived from this software without specific prior written permission. +3. Modifications or new contributions must be attributed in a copyright + notice identifying the author ("Contributor") and added below the + original copyright notice. The copyright notice is for purposes of + identifying contributors and should not be deemed as permission to alter + the permissions given by Adaptec. + +THIS README FILE IS PROVIDED BY ADAPTEC AND CONTRIBUTORS ``AS IS`` AND +ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, ANY +WARRANTIES OF NON-INFRINGEMENT OR THE IMPLIED WARRANTIES OF MERCHANTABILITY +AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL +ADAPTEC OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, +SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED +TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR +PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF +LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING +NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS README +FILE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. diff --git a/Documentation/scsi/aic79xx.txt b/Documentation/scsi/aic79xx.txt deleted file mode 100644 index e2d3273000d4..000000000000 --- a/Documentation/scsi/aic79xx.txt +++ /dev/null @@ -1,497 +0,0 @@ -==================================================================== -= Adaptec Ultra320 Family Manager Set = -= = -= README for = -= The Linux Operating System = -==================================================================== - -The following information is available in this file: - - 1. Supported Hardware - 2. Version History - 3. Command Line Options - 4. Additional Notes - 5. Contacting Adaptec - - -1. Supported Hardware - - The following Adaptec SCSI Host Adapters are supported by this - driver set. - - Ultra320 ASIC Description - ---------------------------------------------------------------- - AIC-7901A Single Channel 64-bit PCI-X 133MHz to - Ultra320 SCSI ASIC - AIC-7901B Single Channel 64-bit PCI-X 133MHz to - Ultra320 SCSI ASIC with Retained Training - AIC-7902A4 Dual Channel 64-bit PCI-X 133MHz to - Ultra320 SCSI ASIC - AIC-7902B Dual Channel 64-bit PCI-X 133MHz to - Ultra320 SCSI ASIC with Retained Training - - Ultra320 Adapters Description ASIC - -------------------------------------------------------------------------- - Adaptec SCSI Card 39320 Dual Channel 64-bit PCI-X 133MHz to 7902A4/7902B - Ultra320 SCSI Card (one external - 68-pin, two internal 68-pin) - Adaptec SCSI Card 39320A Dual Channel 64-bit PCI-X 133MHz to 7902B - Ultra320 SCSI Card (one external - 68-pin, two internal 68-pin) - Adaptec SCSI Card 39320D Dual Channel 64-bit PCI-X 133MHz to 7902A4 - Ultra320 SCSI Card (two external VHDC - and one internal 68-pin) - Adaptec SCSI Card 39320D Dual Channel 64-bit PCI-X 133MHz to 7902A4 - Ultra320 SCSI Card (two external VHDC - and one internal 68-pin) based on the - AIC-7902B ASIC - Adaptec SCSI Card 29320 Single Channel 64-bit PCI-X 133MHz to 7901A - Ultra320 SCSI Card (one external - 68-pin, two internal 68-pin, one - internal 50-pin) - Adaptec SCSI Card 29320A Single Channel 64-bit PCI-X 133MHz to 7901B - Ultra320 SCSI Card (one external - 68-pin, two internal 68-pin, one - internal 50-pin) - Adaptec SCSI Card 29320LP Single Channel 64-bit Low Profile 7901A - PCI-X 133MHz to Ultra320 SCSI Card - (One external VHDC, one internal - 68-pin) - Adaptec SCSI Card 29320ALP Single Channel 64-bit Low Profile 7901B - PCI-X 133MHz to Ultra320 SCSI Card - (One external VHDC, one internal - 68-pin) -2. Version History - - 3.0 (December 1st, 2005) - - Updated driver to use SCSI transport class infrastructure - - Upported sequencer and core fixes from adaptec released - version 2.0.15 of the driver. - - 1.3.11 (July 11, 2003) - - Fix several deadlock issues. - - Add 29320ALP and 39320B Id's. - - 1.3.10 (June 3rd, 2003) - - Align the SCB_TAG field on a 16byte boundary. This avoids - SCB corruption on some PCI-33 busses. - - Correct non-zero luns on Rev B. hardware. - - Update for change in 2.5.X SCSI proc FS interface. - - When negotiation async via an 8bit WDTR message, send - an SDTR with an offset of 0 to be sure the target - knows we are async. This works around a firmware defect - in the Quantum Atlas 10K. - - Implement controller suspend and resume. - - Clear PCI error state during driver attach so that we - don't disable memory mapped I/O due to a stray write - by some other driver probe that occurred before we - claimed the controller. - - 1.3.9 (May 22nd, 2003) - - Fix compiler errors. - - Remove S/G splitting for segments that cross a 4GB boundary. - This is guaranteed not to happen in Linux. - - Add support for scsi_report_device_reset() found in - 2.5.X kernels. - - Add 7901B support. - - Simplify handling of the packetized lun Rev A workaround. - - Correct and simplify handling of the ignore wide residue - message. The previous code would fail to report a residual - if the transaction data length was even and we received - an IWR message. - - 1.3.8 (April 29th, 2003) - - Fix types accessed via the command line interface code. - - Perform a few firmware optimizations. - - Fix "Unexpected PKT busfree" errors. - - Use a sequencer interrupt to notify the host of - commands with bad status. We defer the notification - until there are no outstanding selections to ensure - that the host is interrupted for as short a time as - possible. - - Remove pre-2.2.X support. - - Add support for new 2.5.X interrupt API. - - Correct big-endian architecture support. - - 1.3.7 (April 16th, 2003) - - Use del_timer_sync() to ensure that no timeouts - are pending during controller shutdown. - - For pre-2.5.X kernels, carefully adjust our segment - list size to avoid SCSI malloc pool fragmentation. - - Cleanup channel display in our /proc output. - - Workaround duplicate device entries in the mid-layer - device list during add-single-device. - - 1.3.6 (March 28th, 2003) - - Correct a double free in the Domain Validation code. - - Correct a reference to free'ed memory during controller - shutdown. - - Reset the bus on an SE->LVD change. This is required - to reset our transceivers. - - 1.3.5 (March 24th, 2003) - - Fix a few register window mode bugs. - - Include read streaming in the PPR flags we display in - diagnostics as well as /proc. - - Add PCI hot plug support for 2.5.X kernels. - - Correct default precompensation value for RevA hardware. - - Fix Domain Validation thread shutdown. - - Add a firmware workaround to make the LED blink - brighter during packetized operations on the H2A4. - - Correct /proc display of user read streaming settings. - - Simplify driver locking by releasing the io_request_lock - upon driver entry from the mid-layer. - - Cleanup command line parsing and move much of this code - to aiclib. - - 1.3.4 (February 28th, 2003) - - Correct a race condition in our error recovery handler. - - Allow Test Unit Ready commands to take a full 5 seconds - during Domain Validation. - - 1.3.2 (February 19th, 2003) - - Correct a Rev B. regression due to the GEM318 - compatibility fix included in 1.3.1. - - 1.3.1 (February 11th, 2003) - - Add support for the 39320A. - - Improve recovery for certain PCI-X errors. - - Fix handling of LQ/DATA/LQ/DATA for the - same write transaction that can occur without - interveining training. - - Correct compatibility issues with the GEM318 - enclosure services device. - - Correct data corruption issue that occurred under - high tag depth write loads. - - Adapt to a change in the 2.5.X daemonize() API. - - Correct a "Missing case in ahd_handle_scsiint" panic. - - 1.3.0 (January 21st, 2003) - - Full regression testing for all U320 products completed. - - Added abort and target/lun reset error recovery handler and - interrupt coalescing. - - 1.2.0 (November 14th, 2002) - - Added support for Domain Validation - - Add support for the Hewlett-Packard version of the 39320D - and AIC-7902 adapters. - Support for previous adapters has not been fully tested and should - only be used at the customer's own risk. - - 1.1.1 (September 24th, 2002) - - Added support for the Linux 2.5.X kernel series - - 1.1.0 (September 17th, 2002) - - Added support for four additional SCSI products: - ASC-39320, ASC-29320, ASC-29320LP, AIC-7901. - - 1.0.0 (May 30th, 2002) - - Initial driver release. - - 2.1. Software/Hardware Features - - Support for the SPI-4 "Ultra320" standard: - - 320MB/s transfer rates - - Packetized SCSI Protocol at 160MB/s and 320MB/s - - Quick Arbitration Selection (QAS) - - Retained Training Information (Rev B. ASIC only) - - Interrupt Coalescing - - Initiator Mode (target mode not currently - supported) - - Support for the PCI-X standard up to 133MHz - - Support for the PCI v2.2 standard - - Domain Validation - - 2.2. Operating System Support: - - Redhat Linux 7.2, 7.3, 8.0, Advanced Server 2.1 - - SuSE Linux 7.3, 8.0, 8.1, Enterprise Server 7 - - only Intel and AMD x86 supported at this time - - >4GB memory configurations supported. - - Refer to the User's Guide for more details on this. - -3. Command Line Options - - WARNING: ALTERING OR ADDING THESE DRIVER PARAMETERS - INCORRECTLY CAN RENDER YOUR SYSTEM INOPERABLE. - USE THEM WITH CAUTION. - - Put a .conf file in the /etc/modprobe.d/ directory and add/edit a - line containing 'options aic79xx aic79xx=[command[,command...]]' where - 'command' is one or more of the following: - ----------------------------------------------------------------- - Option: verbose - Definition: enable additional informative messages during - driver operation. - Possible Values: This option is a flag - Default Value: disabled - ----------------------------------------------------------------- - Option: debug:[value] - Definition: Enables various levels of debugging information - The bit definitions for the debugging mask can - be found in drivers/scsi/aic7xxx/aic79xx.h under - the "Debug" heading. - Possible Values: 0x0000 = no debugging, 0xffff = full debugging - Default Value: 0x0000 - ----------------------------------------------------------------- - Option: no_reset - Definition: Do not reset the bus during the initial probe - phase - Possible Values: This option is a flag - Default Value: disabled - ----------------------------------------------------------------- - Option: extended - Definition: Force extended translation on the controller - Possible Values: This option is a flag - Default Value: disabled - ----------------------------------------------------------------- - Option: periodic_otag - Definition: Send an ordered tag periodically to prevent - tag starvation. Needed for some older devices - Possible Values: This option is a flag - Default Value: disabled - ----------------------------------------------------------------- - Option: reverse_scan - Definition: Probe the scsi bus in reverse order, starting - with target 15 - Possible Values: This option is a flag - Default Value: disabled - ----------------------------------------------------------------- - Option: global_tag_depth - Definition: Global tag depth for all targets on all busses. - This option sets the default tag depth which - may be selectively overridden vi the tag_info - option. - Possible Values: 1 - 253 - Default Value: 32 - ----------------------------------------------------------------- - Option: tag_info:{{value[,value...]}[,{value[,value...]}...]} - Definition: Set the per-target tagged queue depth on a - per controller basis. Both controllers and targets - may be omitted indicating that they should retain - the default tag depth. - Examples: tag_info:{{16,32,32,64,8,8,,32,32,32,32,32,32,32,32,32} - On Controller 0 - specifies a tag depth of 16 for target 0 - specifies a tag depth of 64 for target 3 - specifies a tag depth of 8 for targets 4 and 5 - leaves target 6 at the default - specifies a tag depth of 32 for targets 1,2,7-15 - All other targets retain the default depth. - - tag_info:{{},{32,,32}} - On Controller 1 - specifies a tag depth of 32 for targets 0 and 2 - All other targets retain the default depth. - - Possible Values: 1 - 253 - Default Value: 32 - ----------------------------------------------------------------- - Option: rd_strm: {rd_strm_bitmask[,rd_strm_bitmask...]} - Definition: Enable read streaming on a per target basis. - The rd_strm_bitmask is a 16 bit hex value in which - each bit represents a target. Setting the target's - bit to '1' enables read streaming for that - target. Controllers may be omitted indicating that - they should retain the default read streaming setting. - Example: rd_strm:{0x0041} - On Controller 0 - enables read streaming for targets 0 and 6. - disables read streaming for targets 1-5,7-15. - All other targets retain the default read - streaming setting. - Example: rd_strm:{0x0023,,0xFFFF} - On Controller 0 - enables read streaming for targets 1,2, and 5. - disables read streaming for targets 3,4,6-15. - On Controller 2 - enables read streaming for all targets. - All other targets retain the default read - streaming setting. - - Possible Values: 0x0000 - 0xffff - Default Value: 0x0000 - ----------------------------------------------------------------- - Option: dv: {value[,value...]} - Definition: Set Domain Validation Policy on a per-controller basis. - Controllers may be omitted indicating that - they should retain the default read streaming setting. - Example: dv:{-1,0,,1,1,0} - On Controller 0 leave DV at its default setting. - On Controller 1 disable DV. - Skip configuration on Controller 2. - On Controllers 3 and 4 enable DV. - On Controller 5 disable DV. - - Possible Values: < 0 Use setting from serial EEPROM. - 0 Disable DV - > 0 Enable DV - Default Value: DV Serial EEPROM configuration setting. - ----------------------------------------------------------------- - Option: seltime:[value] - Definition: Specifies the selection timeout value - Possible Values: 0 = 256ms, 1 = 128ms, 2 = 64ms, 3 = 32ms - Default Value: 0 - ----------------------------------------------------------------- - - *** The following three options should only be changed at *** - *** the direction of a technical support representative. *** - - ----------------------------------------------------------------- - Option: precomp: {value[,value...]} - Definition: Set IO Cell precompensation value on a per-controller - basis. - Controllers may be omitted indicating that - they should retain the default precompensation setting. - Example: precomp:{0x1} - On Controller 0 set precompensation to 1. - Example: precomp:{1,,7} - On Controller 0 set precompensation to 1. - On Controller 2 set precompensation to 8. - - Possible Values: 0 - 7 - Default Value: Varies based on chip revision - ----------------------------------------------------------------- - Option: slewrate: {value[,value...]} - Definition: Set IO Cell slew rate on a per-controller basis. - Controllers may be omitted indicating that - they should retain the default slew rate setting. - Example: slewrate:{0x1} - On Controller 0 set slew rate to 1. - Example: slewrate :{1,,8} - On Controller 0 set slew rate to 1. - On Controller 2 set slew rate to 8. - - Possible Values: 0 - 15 - Default Value: Varies based on chip revision - ----------------------------------------------------------------- - Option: amplitude: {value[,value...]} - Definition: Set IO Cell signal amplitude on a per-controller basis. - Controllers may be omitted indicating that - they should retain the default read streaming setting. - Example: amplitude:{0x1} - On Controller 0 set amplitude to 1. - Example: amplitude :{1,,7} - On Controller 0 set amplitude to 1. - On Controller 2 set amplitude to 7. - - Possible Values: 1 - 7 - Default Value: Varies based on chip revision - ----------------------------------------------------------------- - - Example: 'options aic79xx aic79xx=verbose,rd_strm:{{0x0041}}' - enables verbose output in the driver and turns read streaming on - for targets 0 and 6 of Controller 0. - -4. Additional Notes - - 4.1. Known/Unresolved or FYI Issues - - * Under SuSE Linux Enterprise 7, the driver may fail to operate - correctly due to a problem with PCI interrupt routing in the - Linux kernel. Please contact SuSE for an updated Linux - kernel. - - 4.2. Third-Party Compatibility Issues - - * Adaptec only supports Ultra320 hard drives running - the latest firmware available. Please check with - your hard drive manufacturer to ensure you have the - latest version. - - 4.3. Operating System or Technology Limitations - - * PCI Hot Plug is untested and may cause the operating system - to stop responding. - * Luns that are not numbered contiguously starting with 0 might not - be automatically probed during system startup. This is a limitation - of the OS. Please contact your Linux vendor for instructions on - manually probing non-contiguous luns. - * Using the Driver Update Disk version of this package during OS - installation under RedHat might result in two versions of this - driver being installed into the system module directory. This - might cause problems with the /sbin/mkinitrd program and/or - other RPM packages that try to install system modules. The best - way to correct this once the system is running is to install - the latest RPM package version of this driver, available from - http://www.adaptec.com. - - -5. Adaptec Customer Support - - A Technical Support Identification (TSID) Number is required for - Adaptec technical support. - - The 12-digit TSID can be found on the white barcode-type label - included inside the box with your product. The TSID helps us - provide more efficient service by accurately identifying your - product and support status. - - Support Options - - Search the Adaptec Support Knowledgebase (ASK) at - http://ask.adaptec.com for articles, troubleshooting tips, and - frequently asked questions about your product. - - For support via Email, submit your question to Adaptec's - Technical Support Specialists at http://ask.adaptec.com/. - - North America - - Visit our Web site at http://www.adaptec.com/. - - For information about Adaptec's support options, call - 408-957-2550, 24 hours a day, 7 days a week. - - To speak with a Technical Support Specialist, - * For hardware products, call 408-934-7274, - Monday to Friday, 3:00 am to 5:00 pm, PDT. - * For RAID and Fibre Channel products, call 321-207-2000, - Monday to Friday, 3:00 am to 5:00 pm, PDT. - To expedite your service, have your computer with you. - - To order Adaptec products, including accessories and cables, - call 408-957-7274. To order cables online go to - http://www.adaptec.com/buy-cables/. - - Europe - - Visit our Web site at http://www.adaptec.com/en-US/_common/world_index. - - To speak with a Technical Support Specialist, call, or email, - * German: +49 89 4366 5522, Monday-Friday, 9:00-17:00 CET, - http://ask-de.adaptec.com/. - * French: +49 89 4366 5533, Monday-Friday, 9:00-17:00 CET, - http://ask-fr.adaptec.com/. - * English: +49 89 4366 5544, Monday-Friday, 9:00-17:00 GMT, - http://ask.adaptec.com/. - - You can order Adaptec cables online at - http://www.adaptec.com/buy-cables/. - - Japan - - Visit our web site at http://www.adaptec.co.jp/. - - To speak with a Technical Support Specialist, call - +81 3 5308 6120, Monday-Friday, 9:00 a.m. to 12:00 p.m., - 1:00 p.m. to 6:00 p.m. - -------------------------------------------------------------------- -/* - * Copyright (c) 2003 Adaptec Inc. 691 S. Milpitas Blvd., Milpitas CA 95035 USA. - * All rights reserved. - * - * You are permitted to redistribute, use and modify this README file in whole - * or in part in conjunction with redistribution of software governed by the - * General Public License, provided that the following conditions are met: - * 1. Redistributions of README file must retain the above copyright - * notice, this list of conditions, and the following disclaimer, - * without modification. - * 2. The name of the author may not be used to endorse or promote products - * derived from this software without specific prior written permission. - * 3. Modifications or new contributions must be attributed in a copyright - * notice identifying the author ("Contributor") and added below the - * original copyright notice. The copyright notice is for purposes of - * identifying contributors and should not be deemed as permission to alter - * the permissions given by Adaptec. - * - * THIS README FILE IS PROVIDED BY ADAPTEC AND CONTRIBUTORS ``AS IS'' AND - * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, ANY - * WARRANTIES OF NON-INFRINGEMENT OR THE IMPLIED WARRANTIES OF MERCHANTABILITY - * AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL - * ADAPTEC OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, - * SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED - * TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR - * PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF - * LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING - * NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS README - * FILE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. - */ diff --git a/Documentation/scsi/index.rst b/Documentation/scsi/index.rst index 8404e991b588..b7fdfc0cb956 100644 --- a/Documentation/scsi/index.rst +++ b/Documentation/scsi/index.rst @@ -11,5 +11,6 @@ Linux SCSI Subsystem aacraid advansys aha152x + aic79xx scsi_transport_srp/figures diff --git a/Documentation/scsi/scsi-parameters.txt b/Documentation/scsi/scsi-parameters.txt index 064d6dfcac26..8ed9c662a1d4 100644 --- a/Documentation/scsi/scsi-parameters.txt +++ b/Documentation/scsi/scsi-parameters.txt @@ -25,7 +25,7 @@ parameters may be changed at runtime by the command See Documentation/scsi/aic7xxx.txt. aic79xx= [HW,SCSI] - See Documentation/scsi/aic79xx.txt. + See Documentation/scsi/aic79xx.rst. atascsi= [HW,SCSI] See drivers/scsi/atari_scsi.c. -- cgit v1.2.3 From cff7c4a596e3498f52ac9c1277b4bc7d7a18e5d7 Mon Sep 17 00:00:00 2001 From: Mauro Carvalho Chehab Date: Mon, 2 Mar 2020 09:15:41 +0100 Subject: scsi: docs: convert aic7xxx.txt to ReST Link: https://lore.kernel.org/r/dc2b1ffe4bf64cfc4b32328740704a30e8d38a79.1583136624.git.mchehab+huawei@kernel.org Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Martin K. Petersen --- Documentation/scsi/aic7xxx.rst | 458 +++++++++++++++++++++++++++++++++ Documentation/scsi/aic7xxx.txt | 394 ---------------------------- Documentation/scsi/index.rst | 1 + Documentation/scsi/scsi-parameters.txt | 2 +- 4 files changed, 460 insertions(+), 395 deletions(-) create mode 100644 Documentation/scsi/aic7xxx.rst delete mode 100644 Documentation/scsi/aic7xxx.txt (limited to 'Documentation/scsi') diff --git a/Documentation/scsi/aic7xxx.rst b/Documentation/scsi/aic7xxx.rst new file mode 100644 index 000000000000..bad0e5567b21 --- /dev/null +++ b/Documentation/scsi/aic7xxx.rst @@ -0,0 +1,458 @@ +.. SPDX-License-Identifier: GPL-2.0 +.. include:: + +======================================================== +Adaptec Aic7xxx Fast -> Ultra160 Family Manager Set v7.0 +======================================================== + +README for The Linux Operating System + +The following information is available in this file: + + 1. Supported Hardware + 2. Version History + 3. Command Line Options + 4. Contacting Adaptec + +1. Supported Hardware +===================== + + The following Adaptec SCSI Chips and Host Adapters are supported by + the aic7xxx driver. + + ======== ===== ========= ======== ========= ===== =============== + Chip MIPS Host Bus MaxSync MaxWidth SCBs Notes + ======== ===== ========= ======== ========= ===== =============== + aic7770 10 EISA/VL 10MHz 16Bit 4 1 + aic7850 10 PCI/32 10MHz 8Bit 3 + aic7855 10 PCI/32 10MHz 8Bit 3 + aic7856 10 PCI/32 10MHz 8Bit 3 + aic7859 10 PCI/32 20MHz 8Bit 3 + aic7860 10 PCI/32 20MHz 8Bit 3 + aic7870 10 PCI/32 10MHz 16Bit 16 + aic7880 10 PCI/32 20MHz 16Bit 16 + aic7890 20 PCI/32 40MHz 16Bit 16 3 4 5 6 7 8 + aic7891 20 PCI/64 40MHz 16Bit 16 3 4 5 6 7 8 + aic7892 20 PCI/64-66 80MHz 16Bit 16 3 4 5 6 7 8 + aic7895 15 PCI/32 20MHz 16Bit 16 2 3 4 5 + aic7895C 15 PCI/32 20MHz 16Bit 16 2 3 4 5 8 + aic7896 20 PCI/32 40MHz 16Bit 16 2 3 4 5 6 7 8 + aic7897 20 PCI/64 40MHz 16Bit 16 2 3 4 5 6 7 8 + aic7899 20 PCI/64-66 80MHz 16Bit 16 2 3 4 5 6 7 8 + ======== ===== ========= ======== ========= ===== =============== + + 1. Multiplexed Twin Channel Device - One controller servicing two + busses. + 2. Multi-function Twin Channel Device - Two controllers on one chip. + 3. Command Channel Secondary DMA Engine - Allows scatter gather list + and SCB prefetch. + 4. 64 Byte SCB Support - Allows disconnected, untagged request table + for all possible target/lun combinations. + 5. Block Move Instruction Support - Doubles the speed of certain + sequencer operations. + 6. 'Bayonet' style Scatter Gather Engine - Improves S/G prefetch + performance. + 7. Queuing Registers - Allows queuing of new transactions without + pausing the sequencer. + 8. Multiple Target IDs - Allows the controller to respond to selection + as a target on multiple SCSI IDs. + + ============== ======= =========== =============== =============== ========= + Controller Chip Host-Bus Int-Connectors Ext-Connectors Notes + ============== ======= =========== =============== =============== ========= + AHA-274X[A] aic7770 EISA SE-50M SE-HD50F + AHA-274X[A]W aic7770 EISA SE-HD68F SE-HD68F + SE-50M + AHA-274X[A]T aic7770 EISA 2 X SE-50M SE-HD50F + AHA-2842 aic7770 VL SE-50M SE-HD50F + AHA-2940AU aic7860 PCI/32 SE-50M SE-HD50F + AVA-2902I aic7860 PCI/32 SE-50M + AVA-2902E aic7860 PCI/32 SE-50M + AVA-2906 aic7856 PCI/32 SE-50M SE-DB25F + APC-7850 aic7850 PCI/32 SE-50M 1 + AVA-2940 aic7860 PCI/32 SE-50M + AHA-2920B aic7860 PCI/32 SE-50M + AHA-2930B aic7860 PCI/32 SE-50M + AHA-2920C aic7856 PCI/32 SE-50M SE-HD50F + AHA-2930C aic7860 PCI/32 SE-50M + AHA-2930C aic7860 PCI/32 SE-50M + AHA-2910C aic7860 PCI/32 SE-50M + AHA-2915C aic7860 PCI/32 SE-50M + AHA-2940AU/CN aic7860 PCI/32 SE-50M SE-HD50F + AHA-2944W aic7870 PCI/32 HVD-HD68F HVD-HD68F + HVD-50M + AHA-3940W aic7870 PCI/32 2 X SE-HD68F SE-HD68F 2 + AHA-2940UW aic7880 PCI/32 SE-HD68F + SE-50M SE-HD68F + AHA-2940U aic7880 PCI/32 SE-50M SE-HD50F + AHA-2940D aic7880 PCI/32 + aHA-2940 A/T aic7880 PCI/32 + AHA-2940D A/T aic7880 PCI/32 + AHA-3940UW aic7880 PCI/32 2 X SE-HD68F SE-HD68F 3 + AHA-3940UWD aic7880 PCI/32 2 X SE-HD68F 2 X SE-VHD68F 3 + AHA-3940U aic7880 PCI/32 2 X SE-50M SE-HD50F 3 + AHA-2944UW aic7880 PCI/32 HVD-HD68F HVD-HD68F + HVD-50M + AHA-3944UWD aic7880 PCI/32 2 X HVD-HD68F 2 X HVD-VHD68F 3 + AHA-4944UW aic7880 PCI/32 + AHA-2930UW aic7880 PCI/32 + AHA-2940UW Pro aic7880 PCI/32 SE-HD68F SE-HD68F 4 + SE-50M + AHA-2940UW/CN aic7880 PCI/32 + AHA-2940UDual aic7895 PCI/32 + AHA-2940UWDual aic7895 PCI/32 + AHA-3940UWD aic7895 PCI/32 + AHA-3940AUW aic7895 PCI/32 + AHA-3940AUWD aic7895 PCI/32 + AHA-3940AU aic7895 PCI/32 + AHA-3944AUWD aic7895 PCI/32 2 X HVD-HD68F 2 X HVD-VHD68F + AHA-2940U2B aic7890 PCI/32 LVD-HD68F LVD-HD68F + AHA-2940U2 OEM aic7891 PCI/64 + AHA-2940U2W aic7890 PCI/32 LVD-HD68F LVD-HD68F + SE-HD68F + SE-50M + AHA-2950U2B aic7891 PCI/64 LVD-HD68F LVD-HD68F + AHA-2930U2 aic7890 PCI/32 LVD-HD68F SE-HD50F + SE-50M + AHA-3950U2B aic7897 PCI/64 + AHA-3950U2D aic7897 PCI/64 + AHA-29160 aic7892 PCI/64-66 + AHA-29160 CPQ aic7892 PCI/64-66 + AHA-29160N aic7892 PCI/32 LVD-HD68F SE-HD50F + SE-50M + AHA-29160LP aic7892 PCI/64-66 + AHA-19160 aic7892 PCI/64-66 + AHA-29150LP aic7892 PCI/64-66 + AHA-29130LP aic7892 PCI/64-66 + AHA-3960D aic7899 PCI/64-66 2 X LVD-HD68F 2 X LVD-VHD68F + LVD-50M + AHA-3960D CPQ aic7899 PCI/64-66 2 X LVD-HD68F 2 X LVD-VHD68F + LVD-50M + AHA-39160 aic7899 PCI/64-66 2 X LVD-HD68F 2 X LVD-VHD68F + LVD-50M + ============== ======= =========== =============== =============== ========= + + 1. No BIOS support + 2. DEC21050 PCI-PCI bridge with multiple controller chips on secondary bus + 3. DEC2115X PCI-PCI bridge with multiple controller chips on secondary bus + 4. All three SCSI connectors may be used simultaneously without + SCSI "stub" effects. + +2. Version History +================== + + * 7.0 (4th August, 2005) + - Updated driver to use SCSI transport class infrastructure + - Upported sequencer and core fixes from last adaptec released + version of the driver. + + * 6.2.36 (June 3rd, 2003) + - Correct code that disables PCI parity error checking. + - Correct and simplify handling of the ignore wide residue + message. The previous code would fail to report a residual + if the transaction data length was even and we received + an IWR message. + - Add support for the 2.5.X EISA framework. + - Update for change in 2.5.X SCSI proc FS interface. + - Correct Domain Validation command-line option parsing. + - When negotiation async via an 8bit WDTR message, send + an SDTR with an offset of 0 to be sure the target + knows we are async. This works around a firmware defect + in the Quantum Atlas 10K. + - Clear PCI error state during driver attach so that we + don't disable memory mapped I/O due to a stray write + by some other driver probe that occurred before we + claimed the controller. + + * 6.2.35 (May 14th, 2003) + - Fix a few GCC 3.3 compiler warnings. + - Correct operation on EISA Twin Channel controller. + - Add support for 2.5.X's scsi_report_device_reset(). + + * 6.2.34 (May 5th, 2003) + - Fix locking regression introduced in 6.2.29 that + could cause a lock order reversal between the io_request_lock + and our per-softc lock. This was only possible on RH9, + SuSE, and kernel.org 2.4.X kernels. + + * 6.2.33 (April 30th, 2003) + - Dynamically disable PCI parity error reporting after + 10 errors are reported to the user. These errors are + the result of some other device issuing PCI transactions + with bad parity. Once the user has been informed of the + problem, continuing to report the errors just degrades + our performance. + + * 6.2.32 (March 28th, 2003) + - Dynamically sized S/G lists to avoid SCSI malloc + pool fragmentation and SCSI mid-layer deadlock. + + * 6.2.28 (January 20th, 2003) + - Domain Validation Fixes + - Add ability to disable PCI parity error checking. + - Enhanced Memory Mapped I/O probe + + * 6.2.20 (November 7th, 2002) + - Added Domain Validation. + +3. Command Line Options +======================= + + + .. Warning:: + + ALTERING OR ADDING THESE DRIVER PARAMETERS + INCORRECTLY CAN RENDER YOUR SYSTEM INOPERABLE. + USE THEM WITH CAUTION. + + Put a .conf file in the /etc/modprobe.d directory and add/edit a + line containing ``options aic7xxx aic7xxx=[command[,command...]]`` where + ``command`` is one or more of the following: + +verbose + + :Definition: enable additional informative messages during driver operation. + :Possible Values: This option is a flag + :Default Value: disabled + + +debug:[value] + + :Definition: Enables various levels of debugging information + :Possible Values: 0x0000 = no debugging, 0xffff = full debugging + :Default Value: 0x0000 + +no_probe + +probe_eisa_vl + + :Definition: Do not probe for EISA/VLB controllers. + This is a toggle. If the driver is compiled + to not probe EISA/VLB controllers by default, + specifying "no_probe" will enable this probing. + If the driver is compiled to probe EISA/VLB + controllers by default, specifying "no_probe" + will disable this probing. + + :Possible Values: This option is a toggle + :Default Value: EISA/VLB probing is disabled by default. + +pci_parity + + :Definition: Toggles the detection of PCI parity errors. + On many motherboards with VIA chipsets, + PCI parity is not generated correctly on the + PCI bus. It is impossible for the hardware to + differentiate between these "spurious" parity + errors and real parity errors. The symptom of + this problem is a stream of the message:: + + "scsi0: Data Parity Error Detected during address or write data phase" + + output by the driver. + + :Possible Values: This option is a toggle + :Default Value: PCI Parity Error reporting is disabled + +no_reset + + :Definition: Do not reset the bus during the initial probe + phase + + :Possible Values: This option is a flag + :Default Value: disabled + +extended + + :Definition: Force extended translation on the controller + :Possible Values: This option is a flag + :Default Value: disabled + +periodic_otag + + :Definition: Send an ordered tag periodically to prevent + tag starvation. Needed for some older devices + + :Possible Values: This option is a flag + :Default Value: disabled + +reverse_scan + + :Definition: Probe the scsi bus in reverse order, starting + with target 15 + + :Possible Values: This option is a flag + :Default Value: disabled + +global_tag_depth:[value] + + :Definition: Global tag depth for all targets on all busses. + This option sets the default tag depth which + may be selectively overridden vi the tag_info + option. + + :Possible Values: 1 - 253 + :Default Value: 32 + +tag_info:{{value[,value...]}[,{value[,value...]}...]} + + :Definition: Set the per-target tagged queue depth on a + per controller basis. Both controllers and targets + may be omitted indicating that they should retain + the default tag depth. + + :Possible Values: 1 - 253 + :Default Value: 32 + + Examples: + + :: + + tag_info:{{16,32,32,64,8,8,,32,32,32,32,32,32,32,32,32} + + On Controller 0: + + - specifies a tag depth of 16 for target 0 + - specifies a tag depth of 64 for target 3 + - specifies a tag depth of 8 for targets 4 and 5 + - leaves target 6 at the default + - specifies a tag depth of 32 for targets 1,2,7-15 + - All other targets retain the default depth. + + :: + + tag_info:{{},{32,,32}} + + On Controller 1: + + - specifies a tag depth of 32 for targets 0 and 2 + - All other targets retain the default depth. + +seltime:[value] + + :Definition: Specifies the selection timeout value + :Possible Values: 0 = 256ms, 1 = 128ms, 2 = 64ms, 3 = 32ms + :Default Value: 0 + +dv: {value[,value...]} + + :Definition: Set Domain Validation Policy on a per-controller basis. + Controllers may be omitted indicating that + they should retain the default read streaming setting. + + :Possible Values: + + ==== =============================== + < 0 Use setting from serial EEPROM. + 0 Disable DV + > 0 Enable DV + ==== =============================== + + + :Default Value: SCSI-Select setting on controllers with a SCSI Select + option for DV. Otherwise, on for controllers supporting + U160 speeds and off for all other controller types. + + Example: + + :: + + dv:{-1,0,,1,1,0} + + - On Controller 0 leave DV at its default setting. + - On Controller 1 disable DV. + - Skip configuration on Controller 2. + - On Controllers 3 and 4 enable DV. + - On Controller 5 disable DV. + +Example:: + + options aic7xxx aic7xxx=verbose,no_probe,tag_info:{{},{,,10}},seltime:1 + +enables verbose logging, Disable EISA/VLB probing, +and set tag depth on Controller 1/Target 2 to 10 tags. + +4. Adaptec Customer Support +=========================== + + A Technical Support Identification (TSID) Number is required for + Adaptec technical support. + + - The 12-digit TSID can be found on the white barcode-type label + included inside the box with your product. The TSID helps us + provide more efficient service by accurately identifying your + product and support status. + + Support Options + - Search the Adaptec Support Knowledgebase (ASK) at + http://ask.adaptec.com for articles, troubleshooting tips, and + frequently asked questions about your product. + - For support via Email, submit your question to Adaptec's + Technical Support Specialists at http://ask.adaptec.com/. + + North America + - Visit our Web site at http://www.adaptec.com/. + - For information about Adaptec's support options, call + 408-957-2550, 24 hours a day, 7 days a week. + - To speak with a Technical Support Specialist, + + * For hardware products, call 408-934-7274, + Monday to Friday, 3:00 am to 5:00 pm, PDT. + * For RAID and Fibre Channel products, call 321-207-2000, + Monday to Friday, 3:00 am to 5:00 pm, PDT. + + To expedite your service, have your computer with you. + - To order Adaptec products, including accessories and cables, + call 408-957-7274. To order cables online go to + http://www.adaptec.com/buy-cables/. + + Europe + - Visit our Web site at http://www.adaptec.com/en-US/_common/world_index. + - To speak with a Technical Support Specialist, call, or email, + + * German: +49 89 4366 5522, Monday-Friday, 9:00-17:00 CET, + http://ask-de.adaptec.com/. + * French: +49 89 4366 5533, Monday-Friday, 9:00-17:00 CET, + http://ask-fr.adaptec.com/. + * English: +49 89 4366 5544, Monday-Friday, 9:00-17:00 GMT, + http://ask.adaptec.com/. + + - You can order Adaptec cables online at + http://www.adaptec.com/buy-cables/. + + Japan + - Visit our web site at http://www.adaptec.co.jp/. + - To speak with a Technical Support Specialist, call + +81 3 5308 6120, Monday-Friday, 9:00 a.m. to 12:00 p.m., + 1:00 p.m. to 6:00 p.m. + +Copyright |copy| 2003 Adaptec Inc. 691 S. Milpitas Blvd., Milpitas CA 95035 USA. + +All rights reserved. + +You are permitted to redistribute, use and modify this README file in whole +or in part in conjunction with redistribution of software governed by the +General Public License, provided that the following conditions are met: + +1. Redistributions of README file must retain the above copyright + notice, this list of conditions, and the following disclaimer, + without modification. +2. The name of the author may not be used to endorse or promote products + derived from this software without specific prior written permission. +3. Modifications or new contributions must be attributed in a copyright + notice identifying the author ("Contributor") and added below the + original copyright notice. The copyright notice is for purposes of + identifying contributors and should not be deemed as permission to alter + the permissions given by Adaptec. + +THIS README FILE IS PROVIDED BY ADAPTEC AND CONTRIBUTORS ``AS IS`` AND +ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, ANY +WARRANTIES OF NON-INFRINGEMENT OR THE IMPLIED WARRANTIES OF MERCHANTABILITY +AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL +ADAPTEC OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, +SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED +TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR +PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF +LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING +NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS README +FILE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. diff --git a/Documentation/scsi/aic7xxx.txt b/Documentation/scsi/aic7xxx.txt deleted file mode 100644 index 7c5d0223d444..000000000000 --- a/Documentation/scsi/aic7xxx.txt +++ /dev/null @@ -1,394 +0,0 @@ -==================================================================== -= Adaptec Aic7xxx Fast -> Ultra160 Family Manager Set v7.0 = -= README for = -= The Linux Operating System = -==================================================================== - -The following information is available in this file: - - 1. Supported Hardware - 2. Version History - 3. Command Line Options - 4. Contacting Adaptec - -1. Supported Hardware - - The following Adaptec SCSI Chips and Host Adapters are supported by - the aic7xxx driver. - - Chip MIPS Host Bus MaxSync MaxWidth SCBs Notes - --------------------------------------------------------------- - aic7770 10 EISA/VL 10MHz 16Bit 4 1 - aic7850 10 PCI/32 10MHz 8Bit 3 - aic7855 10 PCI/32 10MHz 8Bit 3 - aic7856 10 PCI/32 10MHz 8Bit 3 - aic7859 10 PCI/32 20MHz 8Bit 3 - aic7860 10 PCI/32 20MHz 8Bit 3 - aic7870 10 PCI/32 10MHz 16Bit 16 - aic7880 10 PCI/32 20MHz 16Bit 16 - aic7890 20 PCI/32 40MHz 16Bit 16 3 4 5 6 7 8 - aic7891 20 PCI/64 40MHz 16Bit 16 3 4 5 6 7 8 - aic7892 20 PCI/64-66 80MHz 16Bit 16 3 4 5 6 7 8 - aic7895 15 PCI/32 20MHz 16Bit 16 2 3 4 5 - aic7895C 15 PCI/32 20MHz 16Bit 16 2 3 4 5 8 - aic7896 20 PCI/32 40MHz 16Bit 16 2 3 4 5 6 7 8 - aic7897 20 PCI/64 40MHz 16Bit 16 2 3 4 5 6 7 8 - aic7899 20 PCI/64-66 80MHz 16Bit 16 2 3 4 5 6 7 8 - - 1. Multiplexed Twin Channel Device - One controller servicing two - busses. - 2. Multi-function Twin Channel Device - Two controllers on one chip. - 3. Command Channel Secondary DMA Engine - Allows scatter gather list - and SCB prefetch. - 4. 64 Byte SCB Support - Allows disconnected, untagged request table - for all possible target/lun combinations. - 5. Block Move Instruction Support - Doubles the speed of certain - sequencer operations. - 6. `Bayonet' style Scatter Gather Engine - Improves S/G prefetch - performance. - 7. Queuing Registers - Allows queuing of new transactions without - pausing the sequencer. - 8. Multiple Target IDs - Allows the controller to respond to selection - as a target on multiple SCSI IDs. - - Controller Chip Host-Bus Int-Connectors Ext-Connectors Notes - -------------------------------------------------------------------------- - AHA-274X[A] aic7770 EISA SE-50M SE-HD50F - AHA-274X[A]W aic7770 EISA SE-HD68F SE-HD68F - SE-50M - AHA-274X[A]T aic7770 EISA 2 X SE-50M SE-HD50F - AHA-2842 aic7770 VL SE-50M SE-HD50F - AHA-2940AU aic7860 PCI/32 SE-50M SE-HD50F - AVA-2902I aic7860 PCI/32 SE-50M - AVA-2902E aic7860 PCI/32 SE-50M - AVA-2906 aic7856 PCI/32 SE-50M SE-DB25F - APC-7850 aic7850 PCI/32 SE-50M 1 - AVA-2940 aic7860 PCI/32 SE-50M - AHA-2920B aic7860 PCI/32 SE-50M - AHA-2930B aic7860 PCI/32 SE-50M - AHA-2920C aic7856 PCI/32 SE-50M SE-HD50F - AHA-2930C aic7860 PCI/32 SE-50M - AHA-2930C aic7860 PCI/32 SE-50M - AHA-2910C aic7860 PCI/32 SE-50M - AHA-2915C aic7860 PCI/32 SE-50M - AHA-2940AU/CN aic7860 PCI/32 SE-50M SE-HD50F - AHA-2944W aic7870 PCI/32 HVD-HD68F HVD-HD68F - HVD-50M - AHA-3940W aic7870 PCI/32 2 X SE-HD68F SE-HD68F 2 - AHA-2940UW aic7880 PCI/32 SE-HD68F - SE-50M SE-HD68F - AHA-2940U aic7880 PCI/32 SE-50M SE-HD50F - AHA-2940D aic7880 PCI/32 - aHA-2940 A/T aic7880 PCI/32 - AHA-2940D A/T aic7880 PCI/32 - AHA-3940UW aic7880 PCI/32 2 X SE-HD68F SE-HD68F 3 - AHA-3940UWD aic7880 PCI/32 2 X SE-HD68F 2 X SE-VHD68F 3 - AHA-3940U aic7880 PCI/32 2 X SE-50M SE-HD50F 3 - AHA-2944UW aic7880 PCI/32 HVD-HD68F HVD-HD68F - HVD-50M - AHA-3944UWD aic7880 PCI/32 2 X HVD-HD68F 2 X HVD-VHD68F 3 - AHA-4944UW aic7880 PCI/32 - AHA-2930UW aic7880 PCI/32 - AHA-2940UW Pro aic7880 PCI/32 SE-HD68F SE-HD68F 4 - SE-50M - AHA-2940UW/CN aic7880 PCI/32 - AHA-2940UDual aic7895 PCI/32 - AHA-2940UWDual aic7895 PCI/32 - AHA-3940UWD aic7895 PCI/32 - AHA-3940AUW aic7895 PCI/32 - AHA-3940AUWD aic7895 PCI/32 - AHA-3940AU aic7895 PCI/32 - AHA-3944AUWD aic7895 PCI/32 2 X HVD-HD68F 2 X HVD-VHD68F - AHA-2940U2B aic7890 PCI/32 LVD-HD68F LVD-HD68F - AHA-2940U2 OEM aic7891 PCI/64 - AHA-2940U2W aic7890 PCI/32 LVD-HD68F LVD-HD68F - SE-HD68F - SE-50M - AHA-2950U2B aic7891 PCI/64 LVD-HD68F LVD-HD68F - AHA-2930U2 aic7890 PCI/32 LVD-HD68F SE-HD50F - SE-50M - AHA-3950U2B aic7897 PCI/64 - AHA-3950U2D aic7897 PCI/64 - AHA-29160 aic7892 PCI/64-66 - AHA-29160 CPQ aic7892 PCI/64-66 - AHA-29160N aic7892 PCI/32 LVD-HD68F SE-HD50F - SE-50M - AHA-29160LP aic7892 PCI/64-66 - AHA-19160 aic7892 PCI/64-66 - AHA-29150LP aic7892 PCI/64-66 - AHA-29130LP aic7892 PCI/64-66 - AHA-3960D aic7899 PCI/64-66 2 X LVD-HD68F 2 X LVD-VHD68F - LVD-50M - AHA-3960D CPQ aic7899 PCI/64-66 2 X LVD-HD68F 2 X LVD-VHD68F - LVD-50M - AHA-39160 aic7899 PCI/64-66 2 X LVD-HD68F 2 X LVD-VHD68F - LVD-50M - - 1. No BIOS support - 2. DEC21050 PCI-PCI bridge with multiple controller chips on secondary bus - 3. DEC2115X PCI-PCI bridge with multiple controller chips on secondary bus - 4. All three SCSI connectors may be used simultaneously without - SCSI "stub" effects. - -2. Version History - 7.0 (4th August, 2005) - - Updated driver to use SCSI transport class infrastructure - - Upported sequencer and core fixes from last adaptec released - version of the driver. - 6.2.36 (June 3rd, 2003) - - Correct code that disables PCI parity error checking. - - Correct and simplify handling of the ignore wide residue - message. The previous code would fail to report a residual - if the transaction data length was even and we received - an IWR message. - - Add support for the 2.5.X EISA framework. - - Update for change in 2.5.X SCSI proc FS interface. - - Correct Domain Validation command-line option parsing. - - When negotiation async via an 8bit WDTR message, send - an SDTR with an offset of 0 to be sure the target - knows we are async. This works around a firmware defect - in the Quantum Atlas 10K. - - Clear PCI error state during driver attach so that we - don't disable memory mapped I/O due to a stray write - by some other driver probe that occurred before we - claimed the controller. - - 6.2.35 (May 14th, 2003) - - Fix a few GCC 3.3 compiler warnings. - - Correct operation on EISA Twin Channel controller. - - Add support for 2.5.X's scsi_report_device_reset(). - - 6.2.34 (May 5th, 2003) - - Fix locking regression introduced in 6.2.29 that - could cause a lock order reversal between the io_request_lock - and our per-softc lock. This was only possible on RH9, - SuSE, and kernel.org 2.4.X kernels. - - 6.2.33 (April 30th, 2003) - - Dynamically disable PCI parity error reporting after - 10 errors are reported to the user. These errors are - the result of some other device issuing PCI transactions - with bad parity. Once the user has been informed of the - problem, continuing to report the errors just degrades - our performance. - - 6.2.32 (March 28th, 2003) - - Dynamically sized S/G lists to avoid SCSI malloc - pool fragmentation and SCSI mid-layer deadlock. - - 6.2.28 (January 20th, 2003) - - Domain Validation Fixes - - Add ability to disable PCI parity error checking. - - Enhanced Memory Mapped I/O probe - - 6.2.20 (November 7th, 2002) - - Added Domain Validation. - -3. Command Line Options - - WARNING: ALTERING OR ADDING THESE DRIVER PARAMETERS - INCORRECTLY CAN RENDER YOUR SYSTEM INOPERABLE. - USE THEM WITH CAUTION. - - Put a .conf file in the /etc/modprobe.d directory and add/edit a - line containing 'options aic7xxx aic7xxx=[command[,command...]]' where - 'command' is one or more of the following: - ----------------------------------------------------------------- - Option: verbose - Definition: enable additional informative messages during - driver operation. - Possible Values: This option is a flag - Default Value: disabled - ----------------------------------------------------------------- - Option: debug:[value] - Definition: Enables various levels of debugging information - Possible Values: 0x0000 = no debugging, 0xffff = full debugging - Default Value: 0x0000 - ----------------------------------------------------------------- - Option: no_probe - Option: probe_eisa_vl - Definition: Do not probe for EISA/VLB controllers. - This is a toggle. If the driver is compiled - to not probe EISA/VLB controllers by default, - specifying "no_probe" will enable this probing. - If the driver is compiled to probe EISA/VLB - controllers by default, specifying "no_probe" - will disable this probing. - Possible Values: This option is a toggle - Default Value: EISA/VLB probing is disabled by default. - ----------------------------------------------------------------- - Option: pci_parity - Definition: Toggles the detection of PCI parity errors. - On many motherboards with VIA chipsets, - PCI parity is not generated correctly on the - PCI bus. It is impossible for the hardware to - differentiate between these "spurious" parity - errors and real parity errors. The symptom of - this problem is a stream of the message: - "scsi0: Data Parity Error Detected during address or write data phase" - output by the driver. - Possible Values: This option is a toggle - Default Value: PCI Parity Error reporting is disabled - ----------------------------------------------------------------- - Option: no_reset - Definition: Do not reset the bus during the initial probe - phase - Possible Values: This option is a flag - Default Value: disabled - ----------------------------------------------------------------- - Option: extended - Definition: Force extended translation on the controller - Possible Values: This option is a flag - Default Value: disabled - ----------------------------------------------------------------- - Option: periodic_otag - Definition: Send an ordered tag periodically to prevent - tag starvation. Needed for some older devices - Possible Values: This option is a flag - Default Value: disabled - ----------------------------------------------------------------- - Option: reverse_scan - Definition: Probe the scsi bus in reverse order, starting - with target 15 - Possible Values: This option is a flag - Default Value: disabled - ----------------------------------------------------------------- - Option: global_tag_depth:[value] - Definition: Global tag depth for all targets on all busses. - This option sets the default tag depth which - may be selectively overridden vi the tag_info - option. - Possible Values: 1 - 253 - Default Value: 32 - ----------------------------------------------------------------- - Option: tag_info:{{value[,value...]}[,{value[,value...]}...]} - Definition: Set the per-target tagged queue depth on a - per controller basis. Both controllers and targets - may be omitted indicating that they should retain - the default tag depth. - Examples: tag_info:{{16,32,32,64,8,8,,32,32,32,32,32,32,32,32,32} - On Controller 0 - specifies a tag depth of 16 for target 0 - specifies a tag depth of 64 for target 3 - specifies a tag depth of 8 for targets 4 and 5 - leaves target 6 at the default - specifies a tag depth of 32 for targets 1,2,7-15 - All other targets retain the default depth. - - tag_info:{{},{32,,32}} - On Controller 1 - specifies a tag depth of 32 for targets 0 and 2 - All other targets retain the default depth. - - Possible Values: 1 - 253 - Default Value: 32 - ----------------------------------------------------------------- - Option: seltime:[value] - Definition: Specifies the selection timeout value - Possible Values: 0 = 256ms, 1 = 128ms, 2 = 64ms, 3 = 32ms - Default Value: 0 - ----------------------------------------------------------------- - Option: dv: {value[,value...]} - Definition: Set Domain Validation Policy on a per-controller basis. - Controllers may be omitted indicating that - they should retain the default read streaming setting. - Example: dv:{-1,0,,1,1,0} - On Controller 0 leave DV at its default setting. - On Controller 1 disable DV. - Skip configuration on Controller 2. - On Controllers 3 and 4 enable DV. - On Controller 5 disable DV. - - Possible Values: < 0 Use setting from serial EEPROM. - 0 Disable DV - > 0 Enable DV - - Default Value: SCSI-Select setting on controllers with a SCSI Select - option for DV. Otherwise, on for controllers supporting - U160 speeds and off for all other controller types. - ----------------------------------------------------------------- - - Example: - 'options aic7xxx aic7xxx=verbose,no_probe,tag_info:{{},{,,10}},seltime:1' - enables verbose logging, Disable EISA/VLB probing, - and set tag depth on Controller 1/Target 2 to 10 tags. - -4. Adaptec Customer Support - - A Technical Support Identification (TSID) Number is required for - Adaptec technical support. - - The 12-digit TSID can be found on the white barcode-type label - included inside the box with your product. The TSID helps us - provide more efficient service by accurately identifying your - product and support status. - - Support Options - - Search the Adaptec Support Knowledgebase (ASK) at - http://ask.adaptec.com for articles, troubleshooting tips, and - frequently asked questions about your product. - - For support via Email, submit your question to Adaptec's - Technical Support Specialists at http://ask.adaptec.com/. - - North America - - Visit our Web site at http://www.adaptec.com/. - - For information about Adaptec's support options, call - 408-957-2550, 24 hours a day, 7 days a week. - - To speak with a Technical Support Specialist, - * For hardware products, call 408-934-7274, - Monday to Friday, 3:00 am to 5:00 pm, PDT. - * For RAID and Fibre Channel products, call 321-207-2000, - Monday to Friday, 3:00 am to 5:00 pm, PDT. - To expedite your service, have your computer with you. - - To order Adaptec products, including accessories and cables, - call 408-957-7274. To order cables online go to - http://www.adaptec.com/buy-cables/. - - Europe - - Visit our Web site at http://www.adaptec.com/en-US/_common/world_index. - - To speak with a Technical Support Specialist, call, or email, - * German: +49 89 4366 5522, Monday-Friday, 9:00-17:00 CET, - http://ask-de.adaptec.com/. - * French: +49 89 4366 5533, Monday-Friday, 9:00-17:00 CET, - http://ask-fr.adaptec.com/. - * English: +49 89 4366 5544, Monday-Friday, 9:00-17:00 GMT, - http://ask.adaptec.com/. - - You can order Adaptec cables online at - http://www.adaptec.com/buy-cables/. - - Japan - - Visit our web site at http://www.adaptec.co.jp/. - - To speak with a Technical Support Specialist, call - +81 3 5308 6120, Monday-Friday, 9:00 a.m. to 12:00 p.m., - 1:00 p.m. to 6:00 p.m. - -------------------------------------------------------------------- -/* - * Copyright (c) 2003 Adaptec Inc. 691 S. Milpitas Blvd., Milpitas CA 95035 USA. - * All rights reserved. - * - * You are permitted to redistribute, use and modify this README file in whole - * or in part in conjunction with redistribution of software governed by the - * General Public License, provided that the following conditions are met: - * 1. Redistributions of README file must retain the above copyright - * notice, this list of conditions, and the following disclaimer, - * without modification. - * 2. The name of the author may not be used to endorse or promote products - * derived from this software without specific prior written permission. - * 3. Modifications or new contributions must be attributed in a copyright - * notice identifying the author ("Contributor") and added below the - * original copyright notice. The copyright notice is for purposes of - * identifying contributors and should not be deemed as permission to alter - * the permissions given by Adaptec. - * - * THIS README FILE IS PROVIDED BY ADAPTEC AND CONTRIBUTORS ``AS IS'' AND - * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, ANY - * WARRANTIES OF NON-INFRINGEMENT OR THE IMPLIED WARRANTIES OF MERCHANTABILITY - * AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL - * ADAPTEC OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, - * SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED - * TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR - * PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF - * LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING - * NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS README - * FILE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. - */ diff --git a/Documentation/scsi/index.rst b/Documentation/scsi/index.rst index b7fdfc0cb956..c0b66763515f 100644 --- a/Documentation/scsi/index.rst +++ b/Documentation/scsi/index.rst @@ -12,5 +12,6 @@ Linux SCSI Subsystem advansys aha152x aic79xx + aic7xxx scsi_transport_srp/figures diff --git a/Documentation/scsi/scsi-parameters.txt b/Documentation/scsi/scsi-parameters.txt index 8ed9c662a1d4..266fd3b2398a 100644 --- a/Documentation/scsi/scsi-parameters.txt +++ b/Documentation/scsi/scsi-parameters.txt @@ -22,7 +22,7 @@ parameters may be changed at runtime by the command Format: [,,[,]] aic7xxx= [HW,SCSI] - See Documentation/scsi/aic7xxx.txt. + See Documentation/scsi/aic7xxx.rst. aic79xx= [HW,SCSI] See Documentation/scsi/aic79xx.rst. -- cgit v1.2.3 From 6e5a663d8e5c6a39ba0a98058ee94796e835fb98 Mon Sep 17 00:00:00 2001 From: Mauro Carvalho Chehab Date: Mon, 2 Mar 2020 09:15:42 +0100 Subject: scsi: docs: convert bfa.txt to ReST Link: https://lore.kernel.org/r/6660d0f83ddae2ab8efb31c39f9c220fc132e9d4.1583136624.git.mchehab+huawei@kernel.org Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Martin K. Petersen --- Documentation/scsi/bfa.rst | 92 ++++++++++++++++++++++++++++++++++++++++++++ Documentation/scsi/bfa.txt | 82 --------------------------------------- Documentation/scsi/index.rst | 1 + 3 files changed, 93 insertions(+), 82 deletions(-) create mode 100644 Documentation/scsi/bfa.rst delete mode 100644 Documentation/scsi/bfa.txt (limited to 'Documentation/scsi') diff --git a/Documentation/scsi/bfa.rst b/Documentation/scsi/bfa.rst new file mode 100644 index 000000000000..3abc0411857d --- /dev/null +++ b/Documentation/scsi/bfa.rst @@ -0,0 +1,92 @@ +.. SPDX-License-Identifier: GPL-2.0 + +========================================= +Linux driver for Brocade FC/FCOE adapters +========================================= + +Supported Hardware +------------------ + +bfa 3.0.2.2 driver supports all Brocade FC/FCOE adapters. Below is a list of +adapter models with corresponding PCIIDs. + + =================== =========================================== + PCIID Model + =================== =========================================== + 1657:0013:1657:0014 425 4Gbps dual port FC HBA + 1657:0013:1657:0014 825 8Gbps PCIe dual port FC HBA + 1657:0013:103c:1742 HP 82B 8Gbps PCIedual port FC HBA + 1657:0013:103c:1744 HP 42B 4Gbps dual port FC HBA + 1657:0017:1657:0014 415 4Gbps single port FC HBA + 1657:0017:1657:0014 815 8Gbps single port FC HBA + 1657:0017:103c:1741 HP 41B 4Gbps single port FC HBA + 1657:0017:103c 1743 HP 81B 8Gbps single port FC HBA + 1657:0021:103c:1779 804 8Gbps FC HBA for HP Bladesystem c-class + + 1657:0014:1657:0014 1010 10Gbps single port CNA - FCOE + 1657:0014:1657:0014 1020 10Gbps dual port CNA - FCOE + 1657:0014:1657:0014 1007 10Gbps dual port CNA - FCOE + 1657:0014:1657:0014 1741 10Gbps dual port CNA - FCOE + + 1657:0022:1657:0024 1860 16Gbps FC HBA + 1657:0022:1657:0022 1860 10Gbps CNA - FCOE + =================== =========================================== + + +Firmware download +----------------- + +The latest Firmware package for 3.0.2.2 bfa driver can be found at: + +http://www.brocade.com/services-support/drivers-downloads/adapters/Linux.page + +and then click following respective util package link: + + ========= ======================================================= + Version Link + ========= ======================================================= + v3.0.0.0 Linux Adapter Firmware package for RHEL 6.2, SLES 11SP2 + ========= ======================================================= + + +Configuration & Management utility download +------------------------------------------- + +The latest driver configuration & management utility for 3.0.2.2 bfa driver can +be found at: + +http://www.brocade.com/services-support/drivers-downloads/adapters/Linux.page + +and then click following respective util package link + + ========= ======================================================= + Version Link + ========= ======================================================= + v3.0.2.0 Linux Adapter Firmware package for RHEL 6.2, SLES 11SP2 + ========= ======================================================= + + +Documentation +------------- + +The latest Administration's Guide, Installation and Reference Manual, +Troubleshooting Guide, and Release Notes for the corresponding out-of-box +driver can be found at: + +http://www.brocade.com/services-support/drivers-downloads/adapters/Linux.page + +and use the following inbox and out-of-box driver version mapping to find +the corresponding documentation: + + ============= ================== + Inbox Version Out-of-box Version + ============= ================== + v3.0.2.2 v3.0.0.0 + ============= ================== + +Support +------- + +For general product and support info, go to the Brocade website at: + +http://www.brocade.com/services-support/index.page diff --git a/Documentation/scsi/bfa.txt b/Documentation/scsi/bfa.txt deleted file mode 100644 index 3cc4d80d6092..000000000000 --- a/Documentation/scsi/bfa.txt +++ /dev/null @@ -1,82 +0,0 @@ -Linux driver for Brocade FC/FCOE adapters - - -Supported Hardware ------------------- - -bfa 3.0.2.2 driver supports all Brocade FC/FCOE adapters. Below is a list of -adapter models with corresponding PCIIDs. - - PCIID Model - - 1657:0013:1657:0014 425 4Gbps dual port FC HBA - 1657:0013:1657:0014 825 8Gbps PCIe dual port FC HBA - 1657:0013:103c:1742 HP 82B 8Gbps PCIedual port FC HBA - 1657:0013:103c:1744 HP 42B 4Gbps dual port FC HBA - 1657:0017:1657:0014 415 4Gbps single port FC HBA - 1657:0017:1657:0014 815 8Gbps single port FC HBA - 1657:0017:103c:1741 HP 41B 4Gbps single port FC HBA - 1657:0017:103c 1743 HP 81B 8Gbps single port FC HBA - 1657:0021:103c:1779 804 8Gbps FC HBA for HP Bladesystem c-class - - 1657:0014:1657:0014 1010 10Gbps single port CNA - FCOE - 1657:0014:1657:0014 1020 10Gbps dual port CNA - FCOE - 1657:0014:1657:0014 1007 10Gbps dual port CNA - FCOE - 1657:0014:1657:0014 1741 10Gbps dual port CNA - FCOE - - 1657:0022:1657:0024 1860 16Gbps FC HBA - 1657:0022:1657:0022 1860 10Gbps CNA - FCOE - - -Firmware download ------------------ - -The latest Firmware package for 3.0.2.2 bfa driver can be found at: - -http://www.brocade.com/services-support/drivers-downloads/adapters/Linux.page - -and then click following respective util package link: - - Version Link - - v3.0.0.0 Linux Adapter Firmware package for RHEL 6.2, SLES 11SP2 - - -Configuration & Management utility download -------------------------------------------- - -The latest driver configuration & management utility for 3.0.2.2 bfa driver can -be found at: - -http://www.brocade.com/services-support/drivers-downloads/adapters/Linux.page - -and then click following respective util package link - - Version Link - - v3.0.2.0 Linux Adapter Firmware package for RHEL 6.2, SLES 11SP2 - - -Documentation -------------- - -The latest Administration's Guide, Installation and Reference Manual, -Troubleshooting Guide, and Release Notes for the corresponding out-of-box -driver can be found at: - -http://www.brocade.com/services-support/drivers-downloads/adapters/Linux.page - -and use the following inbox and out-of-box driver version mapping to find -the corresponding documentation: - - Inbox Version Out-of-box Version - - v3.0.2.2 v3.0.0.0 - - -Support -------- - -For general product and support info, go to the Brocade website at: - -http://www.brocade.com/services-support/index.page diff --git a/Documentation/scsi/index.rst b/Documentation/scsi/index.rst index c0b66763515f..1e37227f3536 100644 --- a/Documentation/scsi/index.rst +++ b/Documentation/scsi/index.rst @@ -13,5 +13,6 @@ Linux SCSI Subsystem aha152x aic79xx aic7xxx + bfa scsi_transport_srp/figures -- cgit v1.2.3 From 1d4f8dfe2d976d49e6d9065643f106b1750f3445 Mon Sep 17 00:00:00 2001 From: Mauro Carvalho Chehab Date: Mon, 2 Mar 2020 09:15:43 +0100 Subject: scsi: docs: convert bnx2fc.txt to ReST Link: https://lore.kernel.org/r/f239116bd2c36f6fc8deb62e325bb8161da04270.1583136624.git.mchehab+huawei@kernel.org Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Martin K. Petersen --- Documentation/scsi/bnx2fc.rst | 81 +++++++++++++++++++++++++++++++++++++++++++ Documentation/scsi/bnx2fc.txt | 75 --------------------------------------- Documentation/scsi/index.rst | 1 + 3 files changed, 82 insertions(+), 75 deletions(-) create mode 100644 Documentation/scsi/bnx2fc.rst delete mode 100644 Documentation/scsi/bnx2fc.txt (limited to 'Documentation/scsi') diff --git a/Documentation/scsi/bnx2fc.rst b/Documentation/scsi/bnx2fc.rst new file mode 100644 index 000000000000..2fef2dff80c7 --- /dev/null +++ b/Documentation/scsi/bnx2fc.rst @@ -0,0 +1,81 @@ +.. SPDX-License-Identifier: GPL-2.0 + +=========================== +Operating FCoE using bnx2fc +=========================== +Broadcom FCoE offload through bnx2fc is full stateful hardware offload that +cooperates with all interfaces provided by the Linux ecosystem for FC/FCoE and +SCSI controllers. As such, FCoE functionality, once enabled is largely +transparent. Devices discovered on the SAN will be registered and unregistered +automatically with the upper storage layers. + +Despite the fact that the Broadcom's FCoE offload is fully offloaded, it does +depend on the state of the network interfaces to operate. As such, the network +interface (e.g. eth0) associated with the FCoE offload initiator must be 'up'. +It is recommended that the network interfaces be configured to be brought up +automatically at boot time. + +Furthermore, the Broadcom FCoE offload solution creates VLAN interfaces to +support the VLANs that have been discovered for FCoE operation (e.g. +eth0.1001-fcoe). Do not delete or disable these interfaces or FCoE operation +will be disrupted. + +Driver Usage Model: +=================== + +1. Ensure that fcoe-utils package is installed. + +2. Configure the interfaces on which bnx2fc driver has to operate on. +Here are the steps to configure: + + a. cd /etc/fcoe + b. copy cfg-ethx to cfg-eth5 if FCoE has to be enabled on eth5. + c. Repeat this for all the interfaces where FCoE has to be enabled. + d. Edit all the cfg-eth files to set "no" for DCB_REQUIRED** field, and + "yes" for AUTO_VLAN. + e. Other configuration parameters should be left as default + +3. Ensure that "bnx2fc" is in SUPPORTED_DRIVERS list in /etc/fcoe/config. + +4. Start fcoe service. (service fcoe start). If Broadcom devices are present in +the system, bnx2fc driver would automatically claim the interfaces, starts vlan +discovery and log into the targets. + +5. "Symbolic Name" in 'fcoeadm -i' output would display if bnx2fc has claimed +the interface. + +Eg:: + + [root@bh2 ~]# fcoeadm -i + Description: NetXtreme II BCM57712 10 Gigabit Ethernet + Revision: 01 + Manufacturer: Broadcom Corporation + Serial Number: 0010186FD558 + Driver: bnx2x 1.70.00-0 + Number of Ports: 2 + + Symbolic Name: bnx2fc v1.0.5 over eth5.4 + OS Device Name: host11 + Node Name: 0x10000010186FD559 + Port Name: 0x20000010186FD559 + FabricName: 0x2001000DECB3B681 + Speed: 10 Gbit + Supported Speed: 10 Gbit + MaxFrameSize: 2048 + FC-ID (Port ID): 0x0F0377 + State: Online + +6. Verify the vlan discovery is performed by running ifconfig and notice + .-fcoe interfaces are automatically created. + +Refer to fcoeadm manpage for more information on fcoeadm operations to +create/destroy interfaces or to display lun/target information. + +NOTE +==== +** Broadcom FCoE capable devices implement a DCBX/LLDP client on-chip. Only one +LLDP client is allowed per interface. For proper operation all host software +based DCBX/LLDP clients (e.g. lldpad) must be disabled. To disable lldpad on a +given interface, run the following command:: + + lldptool set-lldp -i adminStatus=disabled diff --git a/Documentation/scsi/bnx2fc.txt b/Documentation/scsi/bnx2fc.txt deleted file mode 100644 index 80823556d62f..000000000000 --- a/Documentation/scsi/bnx2fc.txt +++ /dev/null @@ -1,75 +0,0 @@ -Operating FCoE using bnx2fc -=========================== -Broadcom FCoE offload through bnx2fc is full stateful hardware offload that -cooperates with all interfaces provided by the Linux ecosystem for FC/FCoE and -SCSI controllers. As such, FCoE functionality, once enabled is largely -transparent. Devices discovered on the SAN will be registered and unregistered -automatically with the upper storage layers. - -Despite the fact that the Broadcom's FCoE offload is fully offloaded, it does -depend on the state of the network interfaces to operate. As such, the network -interface (e.g. eth0) associated with the FCoE offload initiator must be 'up'. -It is recommended that the network interfaces be configured to be brought up -automatically at boot time. - -Furthermore, the Broadcom FCoE offload solution creates VLAN interfaces to -support the VLANs that have been discovered for FCoE operation (e.g. -eth0.1001-fcoe). Do not delete or disable these interfaces or FCoE operation -will be disrupted. - -Driver Usage Model: -=================== - -1. Ensure that fcoe-utils package is installed. - -2. Configure the interfaces on which bnx2fc driver has to operate on. -Here are the steps to configure: - a. cd /etc/fcoe - b. copy cfg-ethx to cfg-eth5 if FCoE has to be enabled on eth5. - c. Repeat this for all the interfaces where FCoE has to be enabled. - d. Edit all the cfg-eth files to set "no" for DCB_REQUIRED** field, and - "yes" for AUTO_VLAN. - e. Other configuration parameters should be left as default - -3. Ensure that "bnx2fc" is in SUPPORTED_DRIVERS list in /etc/fcoe/config. - -4. Start fcoe service. (service fcoe start). If Broadcom devices are present in -the system, bnx2fc driver would automatically claim the interfaces, starts vlan -discovery and log into the targets. - -5. "Symbolic Name" in 'fcoeadm -i' output would display if bnx2fc has claimed -the interface. -Eg: -[root@bh2 ~]# fcoeadm -i - Description: NetXtreme II BCM57712 10 Gigabit Ethernet - Revision: 01 - Manufacturer: Broadcom Corporation - Serial Number: 0010186FD558 - Driver: bnx2x 1.70.00-0 - Number of Ports: 2 - - Symbolic Name: bnx2fc v1.0.5 over eth5.4 - OS Device Name: host11 - Node Name: 0x10000010186FD559 - Port Name: 0x20000010186FD559 - FabricName: 0x2001000DECB3B681 - Speed: 10 Gbit - Supported Speed: 10 Gbit - MaxFrameSize: 2048 - FC-ID (Port ID): 0x0F0377 - State: Online - -6. Verify the vlan discovery is performed by running ifconfig and notice -.-fcoe interfaces are automatically created. - -Refer to fcoeadm manpage for more information on fcoeadm operations to -create/destroy interfaces or to display lun/target information. - -NOTE: -==== -** Broadcom FCoE capable devices implement a DCBX/LLDP client on-chip. Only one -LLDP client is allowed per interface. For proper operation all host software -based DCBX/LLDP clients (e.g. lldpad) must be disabled. To disable lldpad on a -given interface, run the following command: - -lldptool set-lldp -i adminStatus=disabled diff --git a/Documentation/scsi/index.rst b/Documentation/scsi/index.rst index 1e37227f3536..d453fb3f1f7d 100644 --- a/Documentation/scsi/index.rst +++ b/Documentation/scsi/index.rst @@ -14,5 +14,6 @@ Linux SCSI Subsystem aic79xx aic7xxx bfa + bnx2fc scsi_transport_srp/figures -- cgit v1.2.3 From 977b899ce3cc4c5ca6776f1a62d7817f49c7581f Mon Sep 17 00:00:00 2001 From: Mauro Carvalho Chehab Date: Mon, 2 Mar 2020 09:15:44 +0100 Subject: scsi: docs: convert BusLogic.txt to ReST Link: https://lore.kernel.org/r/750629b6a5233c85c5391c44d126606b8aabefc8.1583136624.git.mchehab+huawei@kernel.org Acked-by: Khalid Aziz Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Martin K. Petersen --- Documentation/scsi/BusLogic.rst | 605 ++++++++++++++++++++++++++++++++++++++++ Documentation/scsi/BusLogic.txt | 566 ------------------------------------- Documentation/scsi/index.rst | 1 + 3 files changed, 606 insertions(+), 566 deletions(-) create mode 100644 Documentation/scsi/BusLogic.rst delete mode 100644 Documentation/scsi/BusLogic.txt (limited to 'Documentation/scsi') diff --git a/Documentation/scsi/BusLogic.rst b/Documentation/scsi/BusLogic.rst new file mode 100644 index 000000000000..b60169812358 --- /dev/null +++ b/Documentation/scsi/BusLogic.rst @@ -0,0 +1,605 @@ +.. SPDX-License-Identifier: GPL-2.0 + +========================================================= +BusLogic MultiMaster and FlashPoint SCSI Driver for Linux +========================================================= + + Version 2.0.15 for Linux 2.0 + + Version 2.1.15 for Linux 2.1 + + PRODUCTION RELEASE + + 17 August 1998 + + Leonard N. Zubkoff + + Dandelion Digital + + lnz@dandelion.com + + Copyright 1995-1998 by Leonard N. Zubkoff + + +Introduction +============ + +BusLogic, Inc. designed and manufactured a variety of high performance SCSI +host adapters which share a common programming interface across a diverse +collection of bus architectures by virtue of their MultiMaster ASIC technology. +BusLogic was acquired by Mylex Corporation in February 1996, but the products +supported by this driver originated under the BusLogic name and so that name is +retained in the source code and documentation. + +This driver supports all present BusLogic MultiMaster Host Adapters, and should +support any future MultiMaster designs with little or no modification. More +recently, BusLogic introduced the FlashPoint Host Adapters, which are less +costly and rely on the host CPU, rather than including an onboard processor. +Despite not having an onboard CPU, the FlashPoint Host Adapters perform very +well and have very low command latency. BusLogic has recently provided me with +the FlashPoint Driver Developer's Kit, which comprises documentation and freely +redistributable source code for the FlashPoint SCCB Manager. The SCCB Manager +is the library of code that runs on the host CPU and performs functions +analogous to the firmware on the MultiMaster Host Adapters. Thanks to their +having provided the SCCB Manager, this driver now supports the FlashPoint Host +Adapters as well. + +My primary goals in writing this completely new BusLogic driver for Linux are +to achieve the full performance that BusLogic SCSI Host Adapters and modern +SCSI peripherals are capable of, and to provide a highly robust driver that can +be depended upon for high performance mission critical applications. All of +the major performance features can be configured from the Linux kernel command +line or at module initialization time, allowing individual installations to +tune driver performance and error recovery to their particular needs. + +The latest information on Linux support for BusLogic SCSI Host Adapters, as +well as the most recent release of this driver and the latest firmware for the +BT-948/958/958D, will always be available from my Linux Home Page at URL +"http://sourceforge.net/projects/dandelion/". + +Bug reports should be sent via electronic mail to "lnz@dandelion.com". Please +include with the bug report the complete configuration messages reported by the +driver and SCSI subsystem at startup, along with any subsequent system messages +relevant to SCSI operations, and a detailed description of your system's +hardware configuration. + +Mylex has been an excellent company to work with and I highly recommend their +products to the Linux community. In November 1995, I was offered the +opportunity to become a beta test site for their latest MultiMaster product, +the BT-948 PCI Ultra SCSI Host Adapter, and then again for the BT-958 PCI Wide +Ultra SCSI Host Adapter in January 1996. This was mutually beneficial since +Mylex received a degree and kind of testing that their own testing group cannot +readily achieve, and the Linux community has available high performance host +adapters that have been well tested with Linux even before being brought to +market. This relationship has also given me the opportunity to interact +directly with their technical staff, to understand more about the internal +workings of their products, and in turn to educate them about the needs and +potential of the Linux community. + +More recently, Mylex has reaffirmed the company's interest in supporting the +Linux community, and I am now working on a Linux driver for the DAC960 PCI RAID +Controllers. Mylex's interest and support is greatly appreciated. + +Unlike some other vendors, if you contact Mylex Technical Support with a +problem and are running Linux, they will not tell you that your use of their +products is unsupported. Their latest product marketing literature even states +"Mylex SCSI host adapters are compatible with all major operating systems +including: ... Linux ...". + +Mylex Corporation is located at 34551 Ardenwood Blvd., Fremont, California +94555, USA and can be reached at 510/796-6100 or on the World Wide Web at +http://www.mylex.com. Mylex HBA Technical Support can be reached by electronic +mail at techsup@mylex.com, by Voice at 510/608-2400, or by FAX at 510/745-7715. +Contact information for offices in Europe and Japan is available on the Web +site. + + +Driver Features +=============== + +Configuration Reporting and Testing +----------------------------------- + + During system initialization, the driver reports extensively on the host + adapter hardware configuration, including the synchronous transfer parameters + requested and negotiated with each target device. AutoSCSI settings for + Synchronous Negotiation, Wide Negotiation, and Disconnect/Reconnect are + reported for each target device, as well as the status of Tagged Queuing. + If the same setting is in effect for all target devices, then a single word + or phrase is used; otherwise, a letter is provided for each target device to + indicate the individual status. The following examples + should clarify this reporting format: + + Synchronous Negotiation: Ultra + + Synchronous negotiation is enabled for all target devices and the host + adapter will attempt to negotiate for 20.0 mega-transfers/second. + + Synchronous Negotiation: Fast + + Synchronous negotiation is enabled for all target devices and the host + adapter will attempt to negotiate for 10.0 mega-transfers/second. + + Synchronous Negotiation: Slow + + Synchronous negotiation is enabled for all target devices and the host + adapter will attempt to negotiate for 5.0 mega-transfers/second. + + Synchronous Negotiation: Disabled + + Synchronous negotiation is disabled and all target devices are limited to + asynchronous operation. + + Synchronous Negotiation: UFSNUUU#UUUUUUUU + + Synchronous negotiation to Ultra speed is enabled for target devices 0 + and 4 through 15, to Fast speed for target device 1, to Slow speed for + target device 2, and is not permitted to target device 3. The host + adapter's SCSI ID is represented by the "#". + + The status of Wide Negotiation, Disconnect/Reconnect, and Tagged Queuing + are reported as "Enabled", Disabled", or a sequence of "Y" and "N" letters. + +Performance Features +-------------------- + + BusLogic SCSI Host Adapters directly implement SCSI-2 Tagged Queuing, and so + support has been included in the driver to utilize tagged queuing with any + target devices that report having the tagged queuing capability. Tagged + queuing allows for multiple outstanding commands to be issued to each target + device or logical unit, and can improve I/O performance substantially. In + addition, BusLogic's Strict Round Robin Mode is used to optimize host adapter + performance, and scatter/gather I/O can support as many segments as can be + effectively utilized by the Linux I/O subsystem. Control over the use of + tagged queuing for each target device as well as individual selection of the + tagged queue depth is available through driver options provided on the kernel + command line or at module initialization time. By default, the queue depth + is determined automatically based on the host adapter's total queue depth and + the number, type, speed, and capabilities of the target devices found. In + addition, tagged queuing is automatically disabled whenever the host adapter + firmware version is known not to implement it correctly, or whenever a tagged + queue depth of 1 is selected. Tagged queuing is also disabled for individual + target devices if disconnect/reconnect is disabled for that device. + +Robustness Features +------------------- + + The driver implements extensive error recovery procedures. When the higher + level parts of the SCSI subsystem request that a timed out command be reset, + a selection is made between a full host adapter hard reset and SCSI bus reset + versus sending a bus device reset message to the individual target device + based on the recommendation of the SCSI subsystem. Error recovery strategies + are selectable through driver options individually for each target device, + and also include sending a bus device reset to the specific target device + associated with the command being reset, as well as suppressing error + recovery entirely to avoid perturbing an improperly functioning device. If + the bus device reset error recovery strategy is selected and sending a bus + device reset does not restore correct operation, the next command that is + reset will force a full host adapter hard reset and SCSI bus reset. SCSI bus + resets caused by other devices and detected by the host adapter are also + handled by issuing a soft reset to the host adapter and re-initialization. + Finally, if tagged queuing is active and more than one command reset occurs + in a 10 minute interval, or if a command reset occurs within the first 10 + minutes of operation, then tagged queuing will be disabled for that target + device. These error recovery options improve overall system robustness by + preventing individual errant devices from causing the system as a whole to + lock up or crash, and thereby allowing a clean shutdown and restart after the + offending component is removed. + +PCI Configuration Support +------------------------- + + On PCI systems running kernels compiled with PCI BIOS support enabled, this + driver will interrogate the PCI configuration space and use the I/O port + addresses assigned by the system BIOS, rather than the ISA compatible I/O + port addresses. The ISA compatible I/O port address is then disabled by the + driver. On PCI systems it is also recommended that the AutoSCSI utility be + used to disable the ISA compatible I/O port entirely as it is not necessary. + The ISA compatible I/O port is disabled by default on the BT-948/958/958D. + +/proc File System Support +------------------------- + + Copies of the host adapter configuration information together with updated + data transfer and error recovery statistics are available through the + /proc/scsi/BusLogic/ interface. + +Shared Interrupts Support +------------------------- + + On systems that support shared interrupts, any number of BusLogic Host + Adapters may share the same interrupt request channel. + + +Supported Host Adapters +======================= + +The following list comprises the supported BusLogic SCSI Host Adapters as of +the date of this document. It is recommended that anyone purchasing a BusLogic +Host Adapter not in the following table contact the author beforehand to verify +that it is or will be supported. + +FlashPoint Series PCI Host Adapters: + +======================= ============================================= +FlashPoint LT (BT-930) Ultra SCSI-3 +FlashPoint LT (BT-930R) Ultra SCSI-3 with RAIDPlus +FlashPoint LT (BT-920) Ultra SCSI-3 (BT-930 without BIOS) +FlashPoint DL (BT-932) Dual Channel Ultra SCSI-3 +FlashPoint DL (BT-932R) Dual Channel Ultra SCSI-3 with RAIDPlus +FlashPoint LW (BT-950) Wide Ultra SCSI-3 +FlashPoint LW (BT-950R) Wide Ultra SCSI-3 with RAIDPlus +FlashPoint DW (BT-952) Dual Channel Wide Ultra SCSI-3 +FlashPoint DW (BT-952R) Dual Channel Wide Ultra SCSI-3 with RAIDPlus +======================= ============================================= + +MultiMaster "W" Series Host Adapters: + +======= === ============================== +BT-948 PCI Ultra SCSI-3 +BT-958 PCI Wide Ultra SCSI-3 +BT-958D PCI Wide Differential Ultra SCSI-3 +======= === ============================== + +MultiMaster "C" Series Host Adapters: + +======== ==== ============================== +BT-946C PCI Fast SCSI-2 +BT-956C PCI Wide Fast SCSI-2 +BT-956CD PCI Wide Differential Fast SCSI-2 +BT-445C VLB Fast SCSI-2 +BT-747C EISA Fast SCSI-2 +BT-757C EISA Wide Fast SCSI-2 +BT-757CD EISA Wide Differential Fast SCSI-2 +BT-545C ISA Fast SCSI-2 +BT-540CF ISA Fast SCSI-2 +======== ==== ============================== + +MultiMaster "S" Series Host Adapters: + +======= ==== ============================== +BT-445S VLB Fast SCSI-2 +BT-747S EISA Fast SCSI-2 +BT-747D EISA Differential Fast SCSI-2 +BT-757S EISA Wide Fast SCSI-2 +BT-757D EISA Wide Differential Fast SCSI-2 +BT-545S ISA Fast SCSI-2 +BT-542D ISA Differential Fast SCSI-2 +BT-742A EISA SCSI-2 (742A revision H) +BT-542B ISA SCSI-2 (542B revision H) +======= ==== ============================== + +MultiMaster "A" Series Host Adapters: + +======= ==== ============================== +BT-742A EISA SCSI-2 (742A revisions A - G) +BT-542B ISA SCSI-2 (542B revisions A - G) +======= ==== ============================== + +AMI FastDisk Host Adapters that are true BusLogic MultiMaster clones are also +supported by this driver. + +BusLogic SCSI Host Adapters are available packaged both as bare boards and as +retail kits. The BT- model numbers above refer to the bare board packaging. +The retail kit model numbers are found by replacing BT- with KT- in the above +list. The retail kit includes the bare board and manual as well as cabling and +driver media and documentation that are not provided with bare boards. + + +FlashPoint Installation Notes +============================= + +RAIDPlus Support +---------------- + + FlashPoint Host Adapters now include RAIDPlus, Mylex's bootable software + RAID. RAIDPlus is not supported on Linux, and there are no plans to support + it. The MD driver in Linux 2.0 provides for concatenation (LINEAR) and + striping (RAID-0), and support for mirroring (RAID-1), fixed parity (RAID-4), + and distributed parity (RAID-5) is available separately. The built-in Linux + RAID support is generally more flexible and is expected to perform better + than RAIDPlus, so there is little impetus to include RAIDPlus support in the + BusLogic driver. + +Enabling UltraSCSI Transfers +---------------------------- + + FlashPoint Host Adapters ship with their configuration set to "Factory + Default" settings that are conservative and do not allow for UltraSCSI speed + to be negotiated. This results in fewer problems when these host adapters + are installed in systems with cabling or termination that is not sufficient + for UltraSCSI operation, or where existing SCSI devices do not properly + respond to synchronous transfer negotiation for UltraSCSI speed. AutoSCSI + may be used to load "Optimum Performance" settings which allow UltraSCSI + speed to be negotiated with all devices, or UltraSCSI speed can be enabled on + an individual basis. It is recommended that SCAM be manually disabled after + the "Optimum Performance" settings are loaded. + + +BT-948/958/958D Installation Notes +================================== + +The BT-948/958/958D PCI Ultra SCSI Host Adapters have some features which may +require attention in some circumstances when installing Linux. + +PCI I/O Port Assignments +------------------------ + + When configured to factory default settings, the BT-948/958/958D will only + recognize the PCI I/O port assignments made by the motherboard's PCI BIOS. + The BT-948/958/958D will not respond to any of the ISA compatible I/O ports + that previous BusLogic SCSI Host Adapters respond to. This driver supports + the PCI I/O port assignments, so this is the preferred configuration. + However, if the obsolete BusLogic driver must be used for any reason, such as + a Linux distribution that does not yet use this driver in its boot kernel, + BusLogic has provided an AutoSCSI configuration option to enable a legacy ISA + compatible I/O port. + + To enable this backward compatibility option, invoke the AutoSCSI utility via + Ctrl-B at system startup and select "Adapter Configuration", "View/Modify + Configuration", and then change the "ISA Compatible Port" setting from + "Disable" to "Primary" or "Alternate". Once this driver has been installed, + the "ISA Compatible Port" option should be set back to "Disable" to avoid + possible future I/O port conflicts. The older BT-946C/956C/956CD also have + this configuration option, but the factory default setting is "Primary". + +PCI Slot Scanning Order +----------------------- + + In systems with multiple BusLogic PCI Host Adapters, the order in which the + PCI slots are scanned may appear reversed with the BT-948/958/958D as + compared to the BT-946C/956C/956CD. For booting from a SCSI disk to work + correctly, it is necessary that the host adapter's BIOS and the kernel agree + on which disk is the boot device, which requires that they recognize the PCI + host adapters in the same order. The motherboard's PCI BIOS provides a + standard way of enumerating the PCI host adapters, which is used by the Linux + kernel. Some PCI BIOS implementations enumerate the PCI slots in order of + increasing bus number and device number, while others do so in the opposite + direction. + + Unfortunately, Microsoft decided that Windows 95 would always enumerate the + PCI slots in order of increasing bus number and device number regardless of + the PCI BIOS enumeration, and requires that their scheme be supported by the + host adapter's BIOS to receive Windows 95 certification. Therefore, the + factory default settings of the BT-948/958/958D enumerate the host adapters + by increasing bus number and device number. To disable this feature, invoke + the AutoSCSI utility via Ctrl-B at system startup and select "Adapter + Configuration", "View/Modify Configuration", press Ctrl-F10, and then change + the "Use Bus And Device # For PCI Scanning Seq." option to OFF. + + This driver will interrogate the setting of the PCI Scanning Sequence option + so as to recognize the host adapters in the same order as they are enumerated + by the host adapter's BIOS. + +Enabling UltraSCSI Transfers +---------------------------- + + The BT-948/958/958D ship with their configuration set to "Factory Default" + settings that are conservative and do not allow for UltraSCSI speed to be + negotiated. This results in fewer problems when these host adapters are + installed in systems with cabling or termination that is not sufficient for + UltraSCSI operation, or where existing SCSI devices do not properly respond + to synchronous transfer negotiation for UltraSCSI speed. AutoSCSI may be + used to load "Optimum Performance" settings which allow UltraSCSI speed to be + negotiated with all devices, or UltraSCSI speed can be enabled on an + individual basis. It is recommended that SCAM be manually disabled after the + "Optimum Performance" settings are loaded. + + +Driver Options +============== + +BusLogic Driver Options may be specified either via the Linux Kernel Command +Line or via the Loadable Kernel Module Installation Facility. Driver Options +for multiple host adapters may be specified either by separating the option +strings by a semicolon, or by specifying multiple "BusLogic=" strings on the +command line. Individual option specifications for a single host adapter are +separated by commas. The Probing and Debugging Options apply to all host +adapters whereas the remaining options apply individually only to the +selected host adapter. + +The BusLogic Driver Probing Options comprise the following: + +IO: + + The "IO:" option specifies an ISA I/O Address to be probed for a non-PCI + MultiMaster Host Adapter. If neither "IO:" nor "NoProbeISA" options are + specified, then the standard list of BusLogic MultiMaster ISA I/O Addresses + will be probed (0x330, 0x334, 0x230, 0x234, 0x130, and 0x134). Multiple + "IO:" options may be specified to precisely determine the I/O Addresses to + be probed, but the probe order will always follow the standard list. + +NoProbe + + The "NoProbe" option disables all probing and therefore no BusLogic Host + Adapters will be detected. + +NoProbeISA + + The "NoProbeISA" option disables probing of the standard BusLogic ISA I/O + Addresses and therefore only PCI MultiMaster and FlashPoint Host Adapters + will be detected. + +NoProbePCI + + The "NoProbePCI" options disables the interrogation of PCI Configuration + Space and therefore only ISA Multimaster Host Adapters will be detected, as + well as PCI Multimaster Host Adapters that have their ISA Compatible I/O + Port set to "Primary" or "Alternate". + +NoSortPCI + + The "NoSortPCI" option forces PCI MultiMaster Host Adapters to be + enumerated in the order provided by the PCI BIOS, ignoring any setting of + the AutoSCSI "Use Bus And Device # For PCI Scanning Seq." option. + +MultiMasterFirst + + The "MultiMasterFirst" option forces MultiMaster Host Adapters to be probed + before FlashPoint Host Adapters. By default, if both FlashPoint and PCI + MultiMaster Host Adapters are present, this driver will probe for + FlashPoint Host Adapters first unless the BIOS primary disk is controlled + by the first PCI MultiMaster Host Adapter, in which case MultiMaster Host + Adapters will be probed first. + +FlashPointFirst + + The "FlashPointFirst" option forces FlashPoint Host Adapters to be probed + before MultiMaster Host Adapters. + +The BusLogic Driver Tagged Queuing Options allow for explicitly specifying +the Queue Depth and whether Tagged Queuing is permitted for each Target +Device (assuming that the Target Device supports Tagged Queuing). The Queue +Depth is the number of SCSI Commands that are allowed to be concurrently +presented for execution (either to the Host Adapter or Target Device). Note +that explicitly enabling Tagged Queuing may lead to problems; the option to +enable or disable Tagged Queuing is provided primarily to allow disabling +Tagged Queuing on Target Devices that do not implement it correctly. The +following options are available: + +QueueDepth: + + The "QueueDepth:" or QD:" option specifies the Queue Depth to use for all + Target Devices that support Tagged Queuing, as well as the maximum Queue + Depth for devices that do not support Tagged Queuing. If no Queue Depth + option is provided, the Queue Depth will be determined automatically based + on the Host Adapter's Total Queue Depth and the number, type, speed, and + capabilities of the detected Target Devices. For Host Adapters that + require ISA Bounce Buffers, the Queue Depth is automatically set by default + to BusLogic_TaggedQueueDepthBB or BusLogic_UntaggedQueueDepthBB to avoid + excessive preallocation of DMA Bounce Buffer memory. Target Devices that + do not support Tagged Queuing always have their Queue Depth set to + BusLogic_UntaggedQueueDepth or BusLogic_UntaggedQueueDepthBB, unless a + lower Queue Depth option is provided. A Queue Depth of 1 automatically + disables Tagged Queuing. + +QueueDepth:[,...] + + The "QueueDepth:[...]" or "QD:[...]" option specifies the Queue Depth + individually for each Target Device. If an is omitted, the + associated Target Device will have its Queue Depth selected automatically. + +TaggedQueuing:Default + + The "TaggedQueuing:Default" or "TQ:Default" option permits Tagged Queuing + based on the firmware version of the BusLogic Host Adapter and based on + whether the Queue Depth allows queuing multiple commands. + +TaggedQueuing:Enable + + The "TaggedQueuing:Enable" or "TQ:Enable" option enables Tagged Queuing for + all Target Devices on this Host Adapter, overriding any limitation that + would otherwise be imposed based on the Host Adapter firmware version. + +TaggedQueuing:Disable + + The "TaggedQueuing:Disable" or "TQ:Disable" option disables Tagged Queuing + for all Target Devices on this Host Adapter. + +TaggedQueuing: + + The "TaggedQueuing:" or "TQ:" option controls + Tagged Queuing individually for each Target Device. is a + sequence of "Y", "N", and "X" characters. "Y" enables Tagged Queuing, "N" + disables Tagged Queuing, and "X" accepts the default based on the firmware + version. The first character refers to Target Device 0, the second to + Target Device 1, and so on; if the sequence of "Y", "N", and "X" characters + does not cover all the Target Devices, unspecified characters are assumed + to be "X". + +The BusLogic Driver Miscellaneous Options comprise the following: + +BusSettleTime: + + The "BusSettleTime:" or "BST:" option specifies the Bus Settle Time in + seconds. The Bus Settle Time is the amount of time to wait between a Host + Adapter Hard Reset which initiates a SCSI Bus Reset and issuing any SCSI + Commands. If unspecified, it defaults to BusLogic_DefaultBusSettleTime. + +InhibitTargetInquiry + + The "InhibitTargetInquiry" option inhibits the execution of an Inquire + Target Devices or Inquire Installed Devices command on MultiMaster Host + Adapters. This may be necessary with some older Target Devices that do not + respond correctly when Logical Units above 0 are addressed. + +The BusLogic Driver Debugging Options comprise the following: + +TraceProbe + + The "TraceProbe" option enables tracing of Host Adapter Probing. + +TraceHardwareReset + + The "TraceHardwareReset" option enables tracing of Host Adapter Hardware + Reset. + +TraceConfiguration + + The "TraceConfiguration" option enables tracing of Host Adapter + Configuration. + +TraceErrors + + The "TraceErrors" option enables tracing of SCSI Commands that return an + error from the Target Device. The CDB and Sense Data will be printed for + each SCSI Command that fails. + +Debug + + The "Debug" option enables all debugging options. + +The following examples demonstrate setting the Queue Depth for Target Devices +1 and 2 on the first host adapter to 7 and 15, the Queue Depth for all Target +Devices on the second host adapter to 31, and the Bus Settle Time on the +second host adapter to 30 seconds. + +Linux Kernel Command Line:: + + linux BusLogic=QueueDepth:[,7,15];QueueDepth:31,BusSettleTime:30 + +LILO Linux Boot Loader (in /etc/lilo.conf):: + + append = "BusLogic=QueueDepth:[,7,15];QueueDepth:31,BusSettleTime:30" + +INSMOD Loadable Kernel Module Installation Facility:: + + insmod BusLogic.o \ + 'BusLogic="QueueDepth:[,7,15];QueueDepth:31,BusSettleTime:30"' + + +.. Note:: + + Module Utilities 2.1.71 or later is required for correct parsing + of driver options containing commas. + + +Driver Installation +=================== + +This distribution was prepared for Linux kernel version 2.0.35, but should be +compatible with 2.0.4 or any later 2.0 series kernel. + +To install the new BusLogic SCSI driver, you may use the following commands, +replacing "/usr/src" with wherever you keep your Linux kernel source tree:: + + cd /usr/src + tar -xvzf BusLogic-2.0.15.tar.gz + mv README.* LICENSE.* BusLogic.[ch] FlashPoint.c linux/drivers/scsi + patch -p0 < BusLogic.patch (only for 2.0.33 and below) + cd linux + make config + make zImage + +Then install "arch/x86/boot/zImage" as your standard kernel, run lilo if +appropriate, and reboot. + + +BusLogic Announcements Mailing List +=================================== + +The BusLogic Announcements Mailing List provides a forum for informing Linux +users of new driver releases and other announcements regarding Linux support +for BusLogic SCSI Host Adapters. To join the mailing list, send a message to +"buslogic-announce-request@dandelion.com" with the line "subscribe" in the +message body. diff --git a/Documentation/scsi/BusLogic.txt b/Documentation/scsi/BusLogic.txt deleted file mode 100644 index 48e982cd6fe7..000000000000 --- a/Documentation/scsi/BusLogic.txt +++ /dev/null @@ -1,566 +0,0 @@ - BusLogic MultiMaster and FlashPoint SCSI Driver for Linux - - Version 2.0.15 for Linux 2.0 - Version 2.1.15 for Linux 2.1 - - PRODUCTION RELEASE - - 17 August 1998 - - Leonard N. Zubkoff - Dandelion Digital - lnz@dandelion.com - - Copyright 1995-1998 by Leonard N. Zubkoff - - - INTRODUCTION - -BusLogic, Inc. designed and manufactured a variety of high performance SCSI -host adapters which share a common programming interface across a diverse -collection of bus architectures by virtue of their MultiMaster ASIC technology. -BusLogic was acquired by Mylex Corporation in February 1996, but the products -supported by this driver originated under the BusLogic name and so that name is -retained in the source code and documentation. - -This driver supports all present BusLogic MultiMaster Host Adapters, and should -support any future MultiMaster designs with little or no modification. More -recently, BusLogic introduced the FlashPoint Host Adapters, which are less -costly and rely on the host CPU, rather than including an onboard processor. -Despite not having an onboard CPU, the FlashPoint Host Adapters perform very -well and have very low command latency. BusLogic has recently provided me with -the FlashPoint Driver Developer's Kit, which comprises documentation and freely -redistributable source code for the FlashPoint SCCB Manager. The SCCB Manager -is the library of code that runs on the host CPU and performs functions -analogous to the firmware on the MultiMaster Host Adapters. Thanks to their -having provided the SCCB Manager, this driver now supports the FlashPoint Host -Adapters as well. - -My primary goals in writing this completely new BusLogic driver for Linux are -to achieve the full performance that BusLogic SCSI Host Adapters and modern -SCSI peripherals are capable of, and to provide a highly robust driver that can -be depended upon for high performance mission critical applications. All of -the major performance features can be configured from the Linux kernel command -line or at module initialization time, allowing individual installations to -tune driver performance and error recovery to their particular needs. - -The latest information on Linux support for BusLogic SCSI Host Adapters, as -well as the most recent release of this driver and the latest firmware for the -BT-948/958/958D, will always be available from my Linux Home Page at URL -"http://sourceforge.net/projects/dandelion/". - -Bug reports should be sent via electronic mail to "lnz@dandelion.com". Please -include with the bug report the complete configuration messages reported by the -driver and SCSI subsystem at startup, along with any subsequent system messages -relevant to SCSI operations, and a detailed description of your system's -hardware configuration. - -Mylex has been an excellent company to work with and I highly recommend their -products to the Linux community. In November 1995, I was offered the -opportunity to become a beta test site for their latest MultiMaster product, -the BT-948 PCI Ultra SCSI Host Adapter, and then again for the BT-958 PCI Wide -Ultra SCSI Host Adapter in January 1996. This was mutually beneficial since -Mylex received a degree and kind of testing that their own testing group cannot -readily achieve, and the Linux community has available high performance host -adapters that have been well tested with Linux even before being brought to -market. This relationship has also given me the opportunity to interact -directly with their technical staff, to understand more about the internal -workings of their products, and in turn to educate them about the needs and -potential of the Linux community. - -More recently, Mylex has reaffirmed the company's interest in supporting the -Linux community, and I am now working on a Linux driver for the DAC960 PCI RAID -Controllers. Mylex's interest and support is greatly appreciated. - -Unlike some other vendors, if you contact Mylex Technical Support with a -problem and are running Linux, they will not tell you that your use of their -products is unsupported. Their latest product marketing literature even states -"Mylex SCSI host adapters are compatible with all major operating systems -including: ... Linux ...". - -Mylex Corporation is located at 34551 Ardenwood Blvd., Fremont, California -94555, USA and can be reached at 510/796-6100 or on the World Wide Web at -http://www.mylex.com. Mylex HBA Technical Support can be reached by electronic -mail at techsup@mylex.com, by Voice at 510/608-2400, or by FAX at 510/745-7715. -Contact information for offices in Europe and Japan is available on the Web -site. - - - DRIVER FEATURES - -o Configuration Reporting and Testing - - During system initialization, the driver reports extensively on the host - adapter hardware configuration, including the synchronous transfer parameters - requested and negotiated with each target device. AutoSCSI settings for - Synchronous Negotiation, Wide Negotiation, and Disconnect/Reconnect are - reported for each target device, as well as the status of Tagged Queuing. - If the same setting is in effect for all target devices, then a single word - or phrase is used; otherwise, a letter is provided for each target device to - indicate the individual status. The following examples - should clarify this reporting format: - - Synchronous Negotiation: Ultra - - Synchronous negotiation is enabled for all target devices and the host - adapter will attempt to negotiate for 20.0 mega-transfers/second. - - Synchronous Negotiation: Fast - - Synchronous negotiation is enabled for all target devices and the host - adapter will attempt to negotiate for 10.0 mega-transfers/second. - - Synchronous Negotiation: Slow - - Synchronous negotiation is enabled for all target devices and the host - adapter will attempt to negotiate for 5.0 mega-transfers/second. - - Synchronous Negotiation: Disabled - - Synchronous negotiation is disabled and all target devices are limited to - asynchronous operation. - - Synchronous Negotiation: UFSNUUU#UUUUUUUU - - Synchronous negotiation to Ultra speed is enabled for target devices 0 - and 4 through 15, to Fast speed for target device 1, to Slow speed for - target device 2, and is not permitted to target device 3. The host - adapter's SCSI ID is represented by the "#". - - The status of Wide Negotiation, Disconnect/Reconnect, and Tagged Queuing - are reported as "Enabled", Disabled", or a sequence of "Y" and "N" letters. - -o Performance Features - - BusLogic SCSI Host Adapters directly implement SCSI-2 Tagged Queuing, and so - support has been included in the driver to utilize tagged queuing with any - target devices that report having the tagged queuing capability. Tagged - queuing allows for multiple outstanding commands to be issued to each target - device or logical unit, and can improve I/O performance substantially. In - addition, BusLogic's Strict Round Robin Mode is used to optimize host adapter - performance, and scatter/gather I/O can support as many segments as can be - effectively utilized by the Linux I/O subsystem. Control over the use of - tagged queuing for each target device as well as individual selection of the - tagged queue depth is available through driver options provided on the kernel - command line or at module initialization time. By default, the queue depth - is determined automatically based on the host adapter's total queue depth and - the number, type, speed, and capabilities of the target devices found. In - addition, tagged queuing is automatically disabled whenever the host adapter - firmware version is known not to implement it correctly, or whenever a tagged - queue depth of 1 is selected. Tagged queuing is also disabled for individual - target devices if disconnect/reconnect is disabled for that device. - -o Robustness Features - - The driver implements extensive error recovery procedures. When the higher - level parts of the SCSI subsystem request that a timed out command be reset, - a selection is made between a full host adapter hard reset and SCSI bus reset - versus sending a bus device reset message to the individual target device - based on the recommendation of the SCSI subsystem. Error recovery strategies - are selectable through driver options individually for each target device, - and also include sending a bus device reset to the specific target device - associated with the command being reset, as well as suppressing error - recovery entirely to avoid perturbing an improperly functioning device. If - the bus device reset error recovery strategy is selected and sending a bus - device reset does not restore correct operation, the next command that is - reset will force a full host adapter hard reset and SCSI bus reset. SCSI bus - resets caused by other devices and detected by the host adapter are also - handled by issuing a soft reset to the host adapter and re-initialization. - Finally, if tagged queuing is active and more than one command reset occurs - in a 10 minute interval, or if a command reset occurs within the first 10 - minutes of operation, then tagged queuing will be disabled for that target - device. These error recovery options improve overall system robustness by - preventing individual errant devices from causing the system as a whole to - lock up or crash, and thereby allowing a clean shutdown and restart after the - offending component is removed. - -o PCI Configuration Support - - On PCI systems running kernels compiled with PCI BIOS support enabled, this - driver will interrogate the PCI configuration space and use the I/O port - addresses assigned by the system BIOS, rather than the ISA compatible I/O - port addresses. The ISA compatible I/O port address is then disabled by the - driver. On PCI systems it is also recommended that the AutoSCSI utility be - used to disable the ISA compatible I/O port entirely as it is not necessary. - The ISA compatible I/O port is disabled by default on the BT-948/958/958D. - -o /proc File System Support - - Copies of the host adapter configuration information together with updated - data transfer and error recovery statistics are available through the - /proc/scsi/BusLogic/ interface. - -o Shared Interrupts Support - - On systems that support shared interrupts, any number of BusLogic Host - Adapters may share the same interrupt request channel. - - - SUPPORTED HOST ADAPTERS - -The following list comprises the supported BusLogic SCSI Host Adapters as of -the date of this document. It is recommended that anyone purchasing a BusLogic -Host Adapter not in the following table contact the author beforehand to verify -that it is or will be supported. - -FlashPoint Series PCI Host Adapters: - -FlashPoint LT (BT-930) Ultra SCSI-3 -FlashPoint LT (BT-930R) Ultra SCSI-3 with RAIDPlus -FlashPoint LT (BT-920) Ultra SCSI-3 (BT-930 without BIOS) -FlashPoint DL (BT-932) Dual Channel Ultra SCSI-3 -FlashPoint DL (BT-932R) Dual Channel Ultra SCSI-3 with RAIDPlus -FlashPoint LW (BT-950) Wide Ultra SCSI-3 -FlashPoint LW (BT-950R) Wide Ultra SCSI-3 with RAIDPlus -FlashPoint DW (BT-952) Dual Channel Wide Ultra SCSI-3 -FlashPoint DW (BT-952R) Dual Channel Wide Ultra SCSI-3 with RAIDPlus - -MultiMaster "W" Series Host Adapters: - -BT-948 PCI Ultra SCSI-3 -BT-958 PCI Wide Ultra SCSI-3 -BT-958D PCI Wide Differential Ultra SCSI-3 - -MultiMaster "C" Series Host Adapters: - -BT-946C PCI Fast SCSI-2 -BT-956C PCI Wide Fast SCSI-2 -BT-956CD PCI Wide Differential Fast SCSI-2 -BT-445C VLB Fast SCSI-2 -BT-747C EISA Fast SCSI-2 -BT-757C EISA Wide Fast SCSI-2 -BT-757CD EISA Wide Differential Fast SCSI-2 -BT-545C ISA Fast SCSI-2 -BT-540CF ISA Fast SCSI-2 - -MultiMaster "S" Series Host Adapters: - -BT-445S VLB Fast SCSI-2 -BT-747S EISA Fast SCSI-2 -BT-747D EISA Differential Fast SCSI-2 -BT-757S EISA Wide Fast SCSI-2 -BT-757D EISA Wide Differential Fast SCSI-2 -BT-545S ISA Fast SCSI-2 -BT-542D ISA Differential Fast SCSI-2 -BT-742A EISA SCSI-2 (742A revision H) -BT-542B ISA SCSI-2 (542B revision H) - -MultiMaster "A" Series Host Adapters: - -BT-742A EISA SCSI-2 (742A revisions A - G) -BT-542B ISA SCSI-2 (542B revisions A - G) - -AMI FastDisk Host Adapters that are true BusLogic MultiMaster clones are also -supported by this driver. - -BusLogic SCSI Host Adapters are available packaged both as bare boards and as -retail kits. The BT- model numbers above refer to the bare board packaging. -The retail kit model numbers are found by replacing BT- with KT- in the above -list. The retail kit includes the bare board and manual as well as cabling and -driver media and documentation that are not provided with bare boards. - - - FLASHPOINT INSTALLATION NOTES - -o RAIDPlus Support - - FlashPoint Host Adapters now include RAIDPlus, Mylex's bootable software - RAID. RAIDPlus is not supported on Linux, and there are no plans to support - it. The MD driver in Linux 2.0 provides for concatenation (LINEAR) and - striping (RAID-0), and support for mirroring (RAID-1), fixed parity (RAID-4), - and distributed parity (RAID-5) is available separately. The built-in Linux - RAID support is generally more flexible and is expected to perform better - than RAIDPlus, so there is little impetus to include RAIDPlus support in the - BusLogic driver. - -o Enabling UltraSCSI Transfers - - FlashPoint Host Adapters ship with their configuration set to "Factory - Default" settings that are conservative and do not allow for UltraSCSI speed - to be negotiated. This results in fewer problems when these host adapters - are installed in systems with cabling or termination that is not sufficient - for UltraSCSI operation, or where existing SCSI devices do not properly - respond to synchronous transfer negotiation for UltraSCSI speed. AutoSCSI - may be used to load "Optimum Performance" settings which allow UltraSCSI - speed to be negotiated with all devices, or UltraSCSI speed can be enabled on - an individual basis. It is recommended that SCAM be manually disabled after - the "Optimum Performance" settings are loaded. - - - BT-948/958/958D INSTALLATION NOTES - -The BT-948/958/958D PCI Ultra SCSI Host Adapters have some features which may -require attention in some circumstances when installing Linux. - -o PCI I/O Port Assignments - - When configured to factory default settings, the BT-948/958/958D will only - recognize the PCI I/O port assignments made by the motherboard's PCI BIOS. - The BT-948/958/958D will not respond to any of the ISA compatible I/O ports - that previous BusLogic SCSI Host Adapters respond to. This driver supports - the PCI I/O port assignments, so this is the preferred configuration. - However, if the obsolete BusLogic driver must be used for any reason, such as - a Linux distribution that does not yet use this driver in its boot kernel, - BusLogic has provided an AutoSCSI configuration option to enable a legacy ISA - compatible I/O port. - - To enable this backward compatibility option, invoke the AutoSCSI utility via - Ctrl-B at system startup and select "Adapter Configuration", "View/Modify - Configuration", and then change the "ISA Compatible Port" setting from - "Disable" to "Primary" or "Alternate". Once this driver has been installed, - the "ISA Compatible Port" option should be set back to "Disable" to avoid - possible future I/O port conflicts. The older BT-946C/956C/956CD also have - this configuration option, but the factory default setting is "Primary". - -o PCI Slot Scanning Order - - In systems with multiple BusLogic PCI Host Adapters, the order in which the - PCI slots are scanned may appear reversed with the BT-948/958/958D as - compared to the BT-946C/956C/956CD. For booting from a SCSI disk to work - correctly, it is necessary that the host adapter's BIOS and the kernel agree - on which disk is the boot device, which requires that they recognize the PCI - host adapters in the same order. The motherboard's PCI BIOS provides a - standard way of enumerating the PCI host adapters, which is used by the Linux - kernel. Some PCI BIOS implementations enumerate the PCI slots in order of - increasing bus number and device number, while others do so in the opposite - direction. - - Unfortunately, Microsoft decided that Windows 95 would always enumerate the - PCI slots in order of increasing bus number and device number regardless of - the PCI BIOS enumeration, and requires that their scheme be supported by the - host adapter's BIOS to receive Windows 95 certification. Therefore, the - factory default settings of the BT-948/958/958D enumerate the host adapters - by increasing bus number and device number. To disable this feature, invoke - the AutoSCSI utility via Ctrl-B at system startup and select "Adapter - Configuration", "View/Modify Configuration", press Ctrl-F10, and then change - the "Use Bus And Device # For PCI Scanning Seq." option to OFF. - - This driver will interrogate the setting of the PCI Scanning Sequence option - so as to recognize the host adapters in the same order as they are enumerated - by the host adapter's BIOS. - -o Enabling UltraSCSI Transfers - - The BT-948/958/958D ship with their configuration set to "Factory Default" - settings that are conservative and do not allow for UltraSCSI speed to be - negotiated. This results in fewer problems when these host adapters are - installed in systems with cabling or termination that is not sufficient for - UltraSCSI operation, or where existing SCSI devices do not properly respond - to synchronous transfer negotiation for UltraSCSI speed. AutoSCSI may be - used to load "Optimum Performance" settings which allow UltraSCSI speed to be - negotiated with all devices, or UltraSCSI speed can be enabled on an - individual basis. It is recommended that SCAM be manually disabled after the - "Optimum Performance" settings are loaded. - - - DRIVER OPTIONS - -BusLogic Driver Options may be specified either via the Linux Kernel Command -Line or via the Loadable Kernel Module Installation Facility. Driver Options -for multiple host adapters may be specified either by separating the option -strings by a semicolon, or by specifying multiple "BusLogic=" strings on the -command line. Individual option specifications for a single host adapter are -separated by commas. The Probing and Debugging Options apply to all host -adapters whereas the remaining options apply individually only to the -selected host adapter. - -The BusLogic Driver Probing Options comprise the following: - -IO: - - The "IO:" option specifies an ISA I/O Address to be probed for a non-PCI - MultiMaster Host Adapter. If neither "IO:" nor "NoProbeISA" options are - specified, then the standard list of BusLogic MultiMaster ISA I/O Addresses - will be probed (0x330, 0x334, 0x230, 0x234, 0x130, and 0x134). Multiple - "IO:" options may be specified to precisely determine the I/O Addresses to - be probed, but the probe order will always follow the standard list. - -NoProbe - - The "NoProbe" option disables all probing and therefore no BusLogic Host - Adapters will be detected. - -NoProbeISA - - The "NoProbeISA" option disables probing of the standard BusLogic ISA I/O - Addresses and therefore only PCI MultiMaster and FlashPoint Host Adapters - will be detected. - -NoProbePCI - - The "NoProbePCI" options disables the interrogation of PCI Configuration - Space and therefore only ISA Multimaster Host Adapters will be detected, as - well as PCI Multimaster Host Adapters that have their ISA Compatible I/O - Port set to "Primary" or "Alternate". - -NoSortPCI - - The "NoSortPCI" option forces PCI MultiMaster Host Adapters to be - enumerated in the order provided by the PCI BIOS, ignoring any setting of - the AutoSCSI "Use Bus And Device # For PCI Scanning Seq." option. - -MultiMasterFirst - - The "MultiMasterFirst" option forces MultiMaster Host Adapters to be probed - before FlashPoint Host Adapters. By default, if both FlashPoint and PCI - MultiMaster Host Adapters are present, this driver will probe for - FlashPoint Host Adapters first unless the BIOS primary disk is controlled - by the first PCI MultiMaster Host Adapter, in which case MultiMaster Host - Adapters will be probed first. - -FlashPointFirst - - The "FlashPointFirst" option forces FlashPoint Host Adapters to be probed - before MultiMaster Host Adapters. - -The BusLogic Driver Tagged Queuing Options allow for explicitly specifying -the Queue Depth and whether Tagged Queuing is permitted for each Target -Device (assuming that the Target Device supports Tagged Queuing). The Queue -Depth is the number of SCSI Commands that are allowed to be concurrently -presented for execution (either to the Host Adapter or Target Device). Note -that explicitly enabling Tagged Queuing may lead to problems; the option to -enable or disable Tagged Queuing is provided primarily to allow disabling -Tagged Queuing on Target Devices that do not implement it correctly. The -following options are available: - -QueueDepth: - - The "QueueDepth:" or QD:" option specifies the Queue Depth to use for all - Target Devices that support Tagged Queuing, as well as the maximum Queue - Depth for devices that do not support Tagged Queuing. If no Queue Depth - option is provided, the Queue Depth will be determined automatically based - on the Host Adapter's Total Queue Depth and the number, type, speed, and - capabilities of the detected Target Devices. For Host Adapters that - require ISA Bounce Buffers, the Queue Depth is automatically set by default - to BusLogic_TaggedQueueDepthBB or BusLogic_UntaggedQueueDepthBB to avoid - excessive preallocation of DMA Bounce Buffer memory. Target Devices that - do not support Tagged Queuing always have their Queue Depth set to - BusLogic_UntaggedQueueDepth or BusLogic_UntaggedQueueDepthBB, unless a - lower Queue Depth option is provided. A Queue Depth of 1 automatically - disables Tagged Queuing. - -QueueDepth:[,...] - - The "QueueDepth:[...]" or "QD:[...]" option specifies the Queue Depth - individually for each Target Device. If an is omitted, the - associated Target Device will have its Queue Depth selected automatically. - -TaggedQueuing:Default - - The "TaggedQueuing:Default" or "TQ:Default" option permits Tagged Queuing - based on the firmware version of the BusLogic Host Adapter and based on - whether the Queue Depth allows queuing multiple commands. - -TaggedQueuing:Enable - - The "TaggedQueuing:Enable" or "TQ:Enable" option enables Tagged Queuing for - all Target Devices on this Host Adapter, overriding any limitation that - would otherwise be imposed based on the Host Adapter firmware version. - -TaggedQueuing:Disable - - The "TaggedQueuing:Disable" or "TQ:Disable" option disables Tagged Queuing - for all Target Devices on this Host Adapter. - -TaggedQueuing: - - The "TaggedQueuing:" or "TQ:" option controls - Tagged Queuing individually for each Target Device. is a - sequence of "Y", "N", and "X" characters. "Y" enables Tagged Queuing, "N" - disables Tagged Queuing, and "X" accepts the default based on the firmware - version. The first character refers to Target Device 0, the second to - Target Device 1, and so on; if the sequence of "Y", "N", and "X" characters - does not cover all the Target Devices, unspecified characters are assumed - to be "X". - -The BusLogic Driver Miscellaneous Options comprise the following: - -BusSettleTime: - - The "BusSettleTime:" or "BST:" option specifies the Bus Settle Time in - seconds. The Bus Settle Time is the amount of time to wait between a Host - Adapter Hard Reset which initiates a SCSI Bus Reset and issuing any SCSI - Commands. If unspecified, it defaults to BusLogic_DefaultBusSettleTime. - -InhibitTargetInquiry - - The "InhibitTargetInquiry" option inhibits the execution of an Inquire - Target Devices or Inquire Installed Devices command on MultiMaster Host - Adapters. This may be necessary with some older Target Devices that do not - respond correctly when Logical Units above 0 are addressed. - -The BusLogic Driver Debugging Options comprise the following: - -TraceProbe - - The "TraceProbe" option enables tracing of Host Adapter Probing. - -TraceHardwareReset - - The "TraceHardwareReset" option enables tracing of Host Adapter Hardware - Reset. - -TraceConfiguration - - The "TraceConfiguration" option enables tracing of Host Adapter - Configuration. - -TraceErrors - - The "TraceErrors" option enables tracing of SCSI Commands that return an - error from the Target Device. The CDB and Sense Data will be printed for - each SCSI Command that fails. - -Debug - - The "Debug" option enables all debugging options. - -The following examples demonstrate setting the Queue Depth for Target Devices -1 and 2 on the first host adapter to 7 and 15, the Queue Depth for all Target -Devices on the second host adapter to 31, and the Bus Settle Time on the -second host adapter to 30 seconds. - -Linux Kernel Command Line: - - linux BusLogic=QueueDepth:[,7,15];QueueDepth:31,BusSettleTime:30 - -LILO Linux Boot Loader (in /etc/lilo.conf): - - append = "BusLogic=QueueDepth:[,7,15];QueueDepth:31,BusSettleTime:30" - -INSMOD Loadable Kernel Module Installation Facility: - - insmod BusLogic.o \ - 'BusLogic="QueueDepth:[,7,15];QueueDepth:31,BusSettleTime:30"' - -NOTE: Module Utilities 2.1.71 or later is required for correct parsing - of driver options containing commas. - - - DRIVER INSTALLATION - -This distribution was prepared for Linux kernel version 2.0.35, but should be -compatible with 2.0.4 or any later 2.0 series kernel. - -To install the new BusLogic SCSI driver, you may use the following commands, -replacing "/usr/src" with wherever you keep your Linux kernel source tree: - - cd /usr/src - tar -xvzf BusLogic-2.0.15.tar.gz - mv README.* LICENSE.* BusLogic.[ch] FlashPoint.c linux/drivers/scsi - patch -p0 < BusLogic.patch (only for 2.0.33 and below) - cd linux - make config - make zImage - -Then install "arch/x86/boot/zImage" as your standard kernel, run lilo if -appropriate, and reboot. - - - BUSLOGIC ANNOUNCEMENTS MAILING LIST - -The BusLogic Announcements Mailing List provides a forum for informing Linux -users of new driver releases and other announcements regarding Linux support -for BusLogic SCSI Host Adapters. To join the mailing list, send a message to -"buslogic-announce-request@dandelion.com" with the line "subscribe" in the -message body. diff --git a/Documentation/scsi/index.rst b/Documentation/scsi/index.rst index d453fb3f1f7d..6bb2428c1d56 100644 --- a/Documentation/scsi/index.rst +++ b/Documentation/scsi/index.rst @@ -15,5 +15,6 @@ Linux SCSI Subsystem aic7xxx bfa bnx2fc + BusLogic scsi_transport_srp/figures -- cgit v1.2.3 From d2ba7ca33840a1e58368594c552fa1fa11b15152 Mon Sep 17 00:00:00 2001 From: Mauro Carvalho Chehab Date: Mon, 2 Mar 2020 09:15:45 +0100 Subject: scsi: docs: convert cxgb3i.txt to ReST Link: https://lore.kernel.org/r/0708b62b6ec4f0dddc581e412bb02ba6476f4523.1583136624.git.mchehab+huawei@kernel.org Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Martin K. Petersen --- Documentation/scsi/cxgb3i.rst | 90 +++++++++++++++++++++++++++++++++++++++++++ Documentation/scsi/cxgb3i.txt | 84 ---------------------------------------- Documentation/scsi/index.rst | 1 + 3 files changed, 91 insertions(+), 84 deletions(-) create mode 100644 Documentation/scsi/cxgb3i.rst delete mode 100644 Documentation/scsi/cxgb3i.txt (limited to 'Documentation/scsi') diff --git a/Documentation/scsi/cxgb3i.rst b/Documentation/scsi/cxgb3i.rst new file mode 100644 index 000000000000..e01f18fbfa9f --- /dev/null +++ b/Documentation/scsi/cxgb3i.rst @@ -0,0 +1,90 @@ +.. SPDX-License-Identifier: GPL-2.0 + +================================= +Chelsio S3 iSCSI Driver for Linux +================================= + +Introduction +============ + +The Chelsio T3 ASIC based Adapters (S310, S320, S302, S304, Mezz cards, etc. +series of products) support iSCSI acceleration and iSCSI Direct Data Placement +(DDP) where the hardware handles the expensive byte touching operations, such +as CRC computation and verification, and direct DMA to the final host memory +destination: + + - iSCSI PDU digest generation and verification + + On transmitting, Chelsio S3 h/w computes and inserts the Header and + Data digest into the PDUs. + On receiving, Chelsio S3 h/w computes and verifies the Header and + Data digest of the PDUs. + + - Direct Data Placement (DDP) + + S3 h/w can directly place the iSCSI Data-In or Data-Out PDU's + payload into pre-posted final destination host-memory buffers based + on the Initiator Task Tag (ITT) in Data-In or Target Task Tag (TTT) + in Data-Out PDUs. + + - PDU Transmit and Recovery + + On transmitting, S3 h/w accepts the complete PDU (header + data) + from the host driver, computes and inserts the digests, decomposes + the PDU into multiple TCP segments if necessary, and transmit all + the TCP segments onto the wire. It handles TCP retransmission if + needed. + + On receiving, S3 h/w recovers the iSCSI PDU by reassembling TCP + segments, separating the header and data, calculating and verifying + the digests, then forwarding the header to the host. The payload data, + if possible, will be directly placed into the pre-posted host DDP + buffer. Otherwise, the payload data will be sent to the host too. + +The cxgb3i driver interfaces with open-iscsi initiator and provides the iSCSI +acceleration through Chelsio hardware wherever applicable. + +Using the cxgb3i Driver +======================= + +The following steps need to be taken to accelerates the open-iscsi initiator: + +1. Load the cxgb3i driver: "modprobe cxgb3i" + + The cxgb3i module registers a new transport class "cxgb3i" with open-iscsi. + + * in the case of recompiling the kernel, the cxgb3i selection is located at:: + + Device Drivers + SCSI device support ---> + [*] SCSI low-level drivers ---> + Chelsio S3xx iSCSI support + +2. Create an interface file located under /etc/iscsi/ifaces/ for the new + transport class "cxgb3i". + + The content of the file should be in the following format:: + + iface.transport_name = cxgb3i + iface.net_ifacename = + iface.ipaddress = + + * if iface.ipaddress is specified, needs to be either the + same as the ethX's ip address or an address on the same subnet. Make + sure the ip address is unique in the network. + +3. edit /etc/iscsi/iscsid.conf + The default setting for MaxRecvDataSegmentLength (131072) is too big; + replace with a value no bigger than 15360 (for example 8192):: + + node.conn[0].iscsi.MaxRecvDataSegmentLength = 8192 + + * The login would fail for a normal session if MaxRecvDataSegmentLength is + too big. A error message in the format of + "cxgb3i: ERR! MaxRecvSegmentLength too big. Need to be <= ." + would be logged to dmesg. + +4. To direct open-iscsi traffic to go through cxgb3i's accelerated path, + "-I " option needs to be specified with most of the + iscsiadm command. is the transport interface file created + in step 2. diff --git a/Documentation/scsi/cxgb3i.txt b/Documentation/scsi/cxgb3i.txt deleted file mode 100644 index 7ac8032ee9b2..000000000000 --- a/Documentation/scsi/cxgb3i.txt +++ /dev/null @@ -1,84 +0,0 @@ -Chelsio S3 iSCSI Driver for Linux - -Introduction -============ - -The Chelsio T3 ASIC based Adapters (S310, S320, S302, S304, Mezz cards, etc. -series of products) support iSCSI acceleration and iSCSI Direct Data Placement -(DDP) where the hardware handles the expensive byte touching operations, such -as CRC computation and verification, and direct DMA to the final host memory -destination: - - - iSCSI PDU digest generation and verification - - On transmitting, Chelsio S3 h/w computes and inserts the Header and - Data digest into the PDUs. - On receiving, Chelsio S3 h/w computes and verifies the Header and - Data digest of the PDUs. - - - Direct Data Placement (DDP) - - S3 h/w can directly place the iSCSI Data-In or Data-Out PDU's - payload into pre-posted final destination host-memory buffers based - on the Initiator Task Tag (ITT) in Data-In or Target Task Tag (TTT) - in Data-Out PDUs. - - - PDU Transmit and Recovery - - On transmitting, S3 h/w accepts the complete PDU (header + data) - from the host driver, computes and inserts the digests, decomposes - the PDU into multiple TCP segments if necessary, and transmit all - the TCP segments onto the wire. It handles TCP retransmission if - needed. - - On receiving, S3 h/w recovers the iSCSI PDU by reassembling TCP - segments, separating the header and data, calculating and verifying - the digests, then forwarding the header to the host. The payload data, - if possible, will be directly placed into the pre-posted host DDP - buffer. Otherwise, the payload data will be sent to the host too. - -The cxgb3i driver interfaces with open-iscsi initiator and provides the iSCSI -acceleration through Chelsio hardware wherever applicable. - -Using the cxgb3i Driver -======================= - -The following steps need to be taken to accelerates the open-iscsi initiator: - -1. Load the cxgb3i driver: "modprobe cxgb3i" - - The cxgb3i module registers a new transport class "cxgb3i" with open-iscsi. - - * in the case of recompiling the kernel, the cxgb3i selection is located at - Device Drivers - SCSI device support ---> - [*] SCSI low-level drivers ---> - Chelsio S3xx iSCSI support - -2. Create an interface file located under /etc/iscsi/ifaces/ for the new - transport class "cxgb3i". - - The content of the file should be in the following format: - iface.transport_name = cxgb3i - iface.net_ifacename = - iface.ipaddress = - - * if iface.ipaddress is specified, needs to be either the - same as the ethX's ip address or an address on the same subnet. Make - sure the ip address is unique in the network. - -3. edit /etc/iscsi/iscsid.conf - The default setting for MaxRecvDataSegmentLength (131072) is too big; - replace with a value no bigger than 15360 (for example 8192): - - node.conn[0].iscsi.MaxRecvDataSegmentLength = 8192 - - * The login would fail for a normal session if MaxRecvDataSegmentLength is - too big. A error message in the format of - "cxgb3i: ERR! MaxRecvSegmentLength too big. Need to be <= ." - would be logged to dmesg. - -4. To direct open-iscsi traffic to go through cxgb3i's accelerated path, - "-I " option needs to be specified with most of the - iscsiadm command. is the transport interface file created - in step 2. diff --git a/Documentation/scsi/index.rst b/Documentation/scsi/index.rst index 6bb2428c1d56..3809213b83da 100644 --- a/Documentation/scsi/index.rst +++ b/Documentation/scsi/index.rst @@ -16,5 +16,6 @@ Linux SCSI Subsystem bfa bnx2fc BusLogic + cxgb3i scsi_transport_srp/figures -- cgit v1.2.3 From 62e3bfa4a1869cf8f221dce8ab90790e836e2b61 Mon Sep 17 00:00:00 2001 From: Mauro Carvalho Chehab Date: Mon, 2 Mar 2020 09:15:46 +0100 Subject: scsi: docs: convert dc395x.txt to ReST Link: https://lore.kernel.org/r/3c0876df0045695185f922a0404c497a69de36a9.1583136624.git.mchehab+huawei@kernel.org Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Martin K. Petersen --- Documentation/scsi/dc395x.rst | 117 ++++++++++++++++++++++++++++++++++++++++++ Documentation/scsi/dc395x.txt | 102 ------------------------------------ Documentation/scsi/index.rst | 1 + 3 files changed, 118 insertions(+), 102 deletions(-) create mode 100644 Documentation/scsi/dc395x.rst delete mode 100644 Documentation/scsi/dc395x.txt (limited to 'Documentation/scsi') diff --git a/Documentation/scsi/dc395x.rst b/Documentation/scsi/dc395x.rst new file mode 100644 index 000000000000..d779e782b1cb --- /dev/null +++ b/Documentation/scsi/dc395x.rst @@ -0,0 +1,117 @@ +.. SPDX-License-Identifier: GPL-2.0 + +====================================== +README file for the dc395x SCSI driver +====================================== + +Status +------ +The driver has been tested with CD-R and CD-R/W drives. These should +be safe to use. Testing with hard disks has not been done to any +great degree and caution should be exercised if you want to attempt +to use this driver with hard disks. + +This is a 2.5 only driver. For a 2.4 driver please see the original +driver (which this driver started from) at +http://www.garloff.de/kurt/linux/dc395/ + +Problems, questions and patches should be submitted to the mailing +list. Details on the list, including archives, are available at +http://lists.twibble.org/mailman/listinfo/dc395x/ + +Parameters +---------- +The driver uses the settings from the EEPROM set in the SCSI BIOS +setup. If there is no EEPROM, the driver uses default values. +Both can be overridden by command line parameters (module or kernel +parameters). + +The following parameters are available: + +safe + Default: 0, Acceptable values: 0 or 1 + + If safe is set to 1 then the adapter will use conservative + ("safe") default settings. This sets: + + shortcut for dc395x=7,4,9,15,2,10 + +adapter_id + Default: 7, Acceptable values: 0 to 15 + + Sets the host adapter SCSI ID. + +max_speed + Default: 1, Acceptable value: 0 to 7 + + == ======== + 0 20 Mhz + 1 12.2 Mhz + 2 10 Mhz + 3 8 Mhz + 4 6.7 Mhz + 5 5.8 Hhz + 6 5 Mhz + 7 4 Mhz + == ======== + +dev_mode + Bitmap for device configuration + + DevMode bit definition: + + === ======== ======== ========================================= + Bit Val(hex) Val(dec) Meaning + === ======== ======== ========================================= + 0 0x01 1 Parity check + 1 0x02 2 Synchronous Negotiation + 2 0x04 4 Disconnection + 3 0x08 8 Send Start command on startup. (Not used) + 4 0x10 16 Tagged Command Queueing + 5 0x20 32 Wide Negotiation + === ======== ======== ========================================= + +adapter_mode + Bitmap for adapter configuration + + AdaptMode bit definition + + ===== ======== ======== ==================================================== + Bit Val(hex) Val(dec) Meaning + ===== ======== ======== ==================================================== + 0 0x01 1 Support more than two drives. (Not used) + 1 0x02 2 Use DOS compatible mapping for HDs greater than 1GB. + 2 0x04 4 Reset SCSI Bus on startup. + 3 0x08 8 Active Negation: Improves SCSI Bus noise immunity. + 4 0x10 16 Immediate return on BIOS seek command. (Not used) + (*)5 0x20 32 Check for LUNs >= 1. + ===== ======== ======== ==================================================== + +tags + Default: 3, Acceptable values: 0-5 + + The number of tags is 1<= 1. - - - tags - Default: 3, Acceptable values: 0-5 - - The number of tags is 1< Date: Mon, 2 Mar 2020 09:15:47 +0100 Subject: scsi: docs: convert dpti.txt to ReST Link: https://lore.kernel.org/r/212fd7961c134c5bd73d87cd818bcddc30270804.1583136624.git.mchehab+huawei@kernel.org Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Martin K. Petersen --- Documentation/scsi/dpti.rst | 92 ++++++++++++++++++++++++++++++++++++++++++++ Documentation/scsi/dpti.txt | 83 --------------------------------------- Documentation/scsi/index.rst | 1 + 3 files changed, 93 insertions(+), 83 deletions(-) create mode 100644 Documentation/scsi/dpti.rst delete mode 100644 Documentation/scsi/dpti.txt (limited to 'Documentation/scsi') diff --git a/Documentation/scsi/dpti.rst b/Documentation/scsi/dpti.rst new file mode 100644 index 000000000000..0496919d87d3 --- /dev/null +++ b/Documentation/scsi/dpti.rst @@ -0,0 +1,92 @@ +.. SPDX-License-Identifier: GPL-2.0 + +=================== +Adaptec dpti driver +=================== + +Redistribution and use in source form, with or without modification, are +permitted provided that redistributions of source code must retain the +above copyright notice, this list of conditions and the following disclaimer. + +This software is provided ``as is`` by Adaptec and +any express or implied warranties, including, but not limited to, the +implied warranties of merchantability and fitness for a particular purpose, +are disclaimed. In no event shall Adaptec be +liable for any direct, indirect, incidental, special, exemplary or +consequential damages (including, but not limited to, procurement of +substitute goods or services; loss of use, data, or profits; or business +interruptions) however caused and on any theory of liability, whether in +contract, strict liability, or tort (including negligence or otherwise) +arising in any way out of the use of this driver software, even if advised +of the possibility of such damage. + +This driver supports the Adaptec I2O RAID and DPT SmartRAID V I2O boards. + +Credits +======= + +The original linux driver was ported to Linux by Karen White while at +Dell Computer. It was ported from Bob Pasteur's (of DPT) original +non-Linux driver. Mark Salyzyn and Bob Pasteur consulted on the original +driver. + +2.0 version of the driver by Deanna Bonds and Mark Salyzyn. + +History +======= + +The driver was originally ported to linux version 2.0.34 + +==== ========================================================================== +V2.0 Rewrite of driver. Re-architectured based on i2o subsystem. + This was the first full GPL version since the last version used + i2osig headers which were not GPL. Developer Testing version. +V2.1 Internal testing +V2.2 First released version + +V2.3 Changes: + + - Added Raptor Support + - Fixed bug causing system to hang under extreme load with + - management utilities running (removed GFP_DMA from kmalloc flags) + +V2.4 First version ready to be submitted to be embedded in the kernel + + Changes: + + - Implemented suggestions from Alan Cox + - Added calculation of resid for sg layer + - Better error handling + - Added checking underflow conditions + - Added DATAPROTECT checking + - Changed error return codes + - Fixed pointer bug in bus reset routine + - Enabled hba reset from ioctls (allows a FW flash to reboot and use + the new FW without having to reboot) + - Changed proc output +==== ========================================================================== + +TODO +==== +- Add 64 bit Scatter Gather when compiled on 64 bit architectures +- Add sparse lun scanning +- Add code that checks if a device that had been taken offline is + now online (at the FW level) when test unit ready or inquiry + command from scsi-core +- Add proc read interface +- busrescan command +- rescan command +- Add code to rescan routine that notifies scsi-core about new devices +- Add support for C-PCI (hotplug stuff) +- Add ioctl passthru error recovery + +Notes +===== +The DPT card optimizes the order of processing commands. Consequently, +a command may take up to 6 minutes to complete after it has been sent +to the board. + +The files dpti_ioctl.h dptsig.h osd_defs.h osd_util.h sys_info.h are part of the +interface files for Adaptec's management routines. These define the structures used +in the ioctls. They are written to be portable. They are hard to read, but I need +to use them 'as is' or I can miss changes in the interface. diff --git a/Documentation/scsi/dpti.txt b/Documentation/scsi/dpti.txt deleted file mode 100644 index f36dc0e7c8da..000000000000 --- a/Documentation/scsi/dpti.txt +++ /dev/null @@ -1,83 +0,0 @@ - /* TERMS AND CONDITIONS OF USE - * - * Redistribution and use in source form, with or without modification, are - * permitted provided that redistributions of source code must retain the - * above copyright notice, this list of conditions and the following disclaimer. - * - * This software is provided `as is' by Adaptec and - * any express or implied warranties, including, but not limited to, the - * implied warranties of merchantability and fitness for a particular purpose, - * are disclaimed. In no event shall Adaptec be - * liable for any direct, indirect, incidental, special, exemplary or - * consequential damages (including, but not limited to, procurement of - * substitute goods or services; loss of use, data, or profits; or business - * interruptions) however caused and on any theory of liability, whether in - * contract, strict liability, or tort (including negligence or otherwise) - * arising in any way out of the use of this driver software, even if advised - * of the possibility of such damage. - * - **************************************************************** - * This driver supports the Adaptec I2O RAID and DPT SmartRAID V I2O boards. - * - * CREDITS: - * The original linux driver was ported to Linux by Karen White while at - * Dell Computer. It was ported from Bob Pasteur's (of DPT) original - * non-Linux driver. Mark Salyzyn and Bob Pasteur consulted on the original - * driver. - * - * 2.0 version of the driver by Deanna Bonds and Mark Salyzyn. - * - * HISTORY: - * The driver was originally ported to linux version 2.0.34 - * - * V2.0 Rewrite of driver. Re-architectured based on i2o subsystem. - * This was the first full GPL version since the last version used - * i2osig headers which were not GPL. Developer Testing version. - * V2.1 Internal testing - * V2.2 First released version - * - * V2.3 - * Changes: - * Added Raptor Support - * Fixed bug causing system to hang under extreme load with - * management utilities running (removed GFP_DMA from kmalloc flags) - * - * - * V2.4 First version ready to be submitted to be embedded in the kernel - * Changes: - * Implemented suggestions from Alan Cox - * Added calculation of resid for sg layer - * Better error handling - * Added checking underflow conditions - * Added DATAPROTECT checking - * Changed error return codes - * Fixed pointer bug in bus reset routine - * Enabled hba reset from ioctls (allows a FW flash to reboot and use the new - * FW without having to reboot) - * Changed proc output - * - * TODO: - * Add 64 bit Scatter Gather when compiled on 64 bit architectures - * Add sparse lun scanning - * Add code that checks if a device that had been taken offline is - * now online (at the FW level) when test unit ready or inquiry - * command from scsi-core - * Add proc read interface - * busrescan command - * rescan command - * Add code to rescan routine that notifies scsi-core about new devices - * Add support for C-PCI (hotplug stuff) - * Add ioctl passthru error recovery - * - * NOTES: - * The DPT card optimizes the order of processing commands. Consequently, - * a command may take up to 6 minutes to complete after it has been sent - * to the board. - * - * The files dpti_ioctl.h dptsig.h osd_defs.h osd_util.h sys_info.h are part of the - * interface files for Adaptec's management routines. These define the structures used - * in the ioctls. They are written to be portable. They are hard to read, but I need - * to use them 'as is' or I can miss changes in the interface. - * - */ - diff --git a/Documentation/scsi/index.rst b/Documentation/scsi/index.rst index 6fe00709cbce..b553dd9904bf 100644 --- a/Documentation/scsi/index.rst +++ b/Documentation/scsi/index.rst @@ -18,5 +18,6 @@ Linux SCSI Subsystem BusLogic cxgb3i dc395x + dpti scsi_transport_srp/figures -- cgit v1.2.3 From cc0d9d3ad7e60ee0bc6f78809ef6f58f512a9cae Mon Sep 17 00:00:00 2001 From: Mauro Carvalho Chehab Date: Mon, 2 Mar 2020 09:15:48 +0100 Subject: scsi: docs: convert FlashPoint.txt to ReST Link: https://lore.kernel.org/r/e755b9644047eed6be69fcc77eb797f0801fcb99.1583136624.git.mchehab+huawei@kernel.org Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Martin K. Petersen --- Documentation/scsi/FlashPoint.rst | 176 ++++++++++++++++++++++++++++++++++++++ Documentation/scsi/FlashPoint.txt | 163 ----------------------------------- Documentation/scsi/index.rst | 1 + 3 files changed, 177 insertions(+), 163 deletions(-) create mode 100644 Documentation/scsi/FlashPoint.rst delete mode 100644 Documentation/scsi/FlashPoint.txt (limited to 'Documentation/scsi') diff --git a/Documentation/scsi/FlashPoint.rst b/Documentation/scsi/FlashPoint.rst new file mode 100644 index 000000000000..ef3c07e94ad6 --- /dev/null +++ b/Documentation/scsi/FlashPoint.rst @@ -0,0 +1,176 @@ +.. SPDX-License-Identifier: GPL-2.0 + +=================================== +The BusLogic FlashPoint SCSI Driver +=================================== + +The BusLogic FlashPoint SCSI Host Adapters are now fully supported on Linux. +The upgrade program described below has been officially terminated effective +31 March 1997 since it is no longer needed. + +:: + + MYLEX INTRODUCES LINUX OPERATING SYSTEM SUPPORT FOR ITS + BUSLOGIC FLASHPOINT LINE OF SCSI HOST ADAPTERS + + + FREMONT, CA, -- October 8, 1996 -- Mylex Corporation has expanded Linux + operating system support to its BusLogic brand of FlashPoint Ultra SCSI + host adapters. All of BusLogic's other SCSI host adapters, including the + MultiMaster line, currently support the Linux operating system. Linux + drivers and information will be available on October 15th at + http://sourceforge.net/projects/dandelion/. + + "Mylex is committed to supporting the Linux community," says Peter Shambora, + vice president of marketing for Mylex. "We have supported Linux driver + development and provided technical support for our host adapters for several + years, and are pleased to now make our FlashPoint products available to this + user base." + +The Linux Operating System +========================== + +Linux is a freely-distributed implementation of UNIX for Intel x86, Sun +SPARC, SGI MIPS, Motorola 68k, Digital Alpha AXP and Motorola PowerPC +machines. It supports a wide range of software, including the X Window +System, Emacs, and TCP/IP networking. Further information is available at +http://www.linux.org and http://www.ssc.com/. + +FlashPoint Host Adapters +======================== + +The FlashPoint family of Ultra SCSI host adapters, designed for workstation +and file server environments, are available in narrow, wide, dual channel, +and dual channel wide versions. These adapters feature SeqEngine +automation technology, which minimizes SCSI command overhead and reduces +the number of interrupts generated to the CPU. + +About Mylex +=========== + +Mylex Corporation (NASDAQ/NM SYMBOL: MYLX), founded in 1983, is a leading +producer of RAID technology and network management products. The company +produces high performance disk array (RAID) controllers, and complementary +computer products for network servers, mass storage systems, workstations +and system boards. Through its wide range of RAID controllers and its +BusLogic line of Ultra SCSI host adapter products, Mylex provides enabling +intelligent I/O technologies that increase network management control, +enhance CPU utilization, optimize I/O performance, and ensure data security +and availability. Products are sold globally through a network of OEMs, +major distributors, VARs, and system integrators. Mylex Corporation is +headquartered at 34551 Ardenwood Blvd., Fremont, CA. + +Contact: +======== + +:: + + Peter Shambora + Vice President of Marketing + Mylex Corp. + 510/796-6100 + peters@mylex.com + + +:: + + ANNOUNCEMENT + BusLogic FlashPoint LT/BT-948 Upgrade Program + 1 February 1996 + + ADDITIONAL ANNOUNCEMENT + BusLogic FlashPoint LW/BT-958 Upgrade Program + 14 June 1996 + + Ever since its introduction last October, the BusLogic FlashPoint LT has + been problematic for members of the Linux community, in that no Linux + drivers have been available for this new Ultra SCSI product. Despite its + officially being positioned as a desktop workstation product, and not being + particularly well suited for a high performance multitasking operating + system like Linux, the FlashPoint LT has been touted by computer system + vendors as the latest thing, and has been sold even on many of their high + end systems, to the exclusion of the older MultiMaster products. This has + caused grief for many people who inadvertently purchased a system expecting + that all BusLogic SCSI Host Adapters were supported by Linux, only to + discover that the FlashPoint was not supported and would not be for quite + some time, if ever. + + After this problem was identified, BusLogic contacted its major OEM + customers to make sure the BT-946C/956C MultiMaster cards would still be + made available, and that Linux users who mistakenly ordered systems with + the FlashPoint would be able to upgrade to the BT-946C. While this helped + many purchasers of new systems, it was only a partial solution to the + overall problem of FlashPoint support for Linux users. It did nothing to + assist the people who initially purchased a FlashPoint for a supported + operating system and then later decided to run Linux, or those who had + ended up with a FlashPoint LT, believing it was supported, and were unable + to return it. + + In the middle of December, I asked to meet with BusLogic's senior + management to discuss the issues related to Linux and free software support + for the FlashPoint. Rumors of varying accuracy had been circulating + publicly about BusLogic's attitude toward the Linux community, and I felt + it was best that these issues be addressed directly. I sent an email + message after 11pm one evening, and the meeting took place the next + afternoon. Unfortunately, corporate wheels sometimes grind slowly, + especially when a company is being acquired, and so it's taken until now + before the details were completely determined and a public statement could + be made. + + BusLogic is not prepared at this time to release the information necessary + for third parties to write drivers for the FlashPoint. The only existing + FlashPoint drivers have been written directly by BusLogic Engineering, and + there is no FlashPoint documentation sufficiently detailed to allow outside + developers to write a driver without substantial assistance. While there + are people at BusLogic who would rather not release the details of the + FlashPoint architecture at all, that debate has not yet been settled either + way. In any event, even if documentation were available today it would + take quite a while for a usable driver to be written, especially since I'm + not convinced that the effort required would be worthwhile. + + However, BusLogic does remain committed to providing a high performance + SCSI solution for the Linux community, and does not want to see anyone left + unable to run Linux because they have a Flashpoint LT. Therefore, BusLogic + has put in place a direct upgrade program to allow any Linux user worldwide + to trade in their FlashPoint LT for the new BT-948 MultiMaster PCI Ultra + SCSI Host Adapter. The BT-948 is the Ultra SCSI successor to the BT-946C + and has all the best features of both the BT-946C and FlashPoint LT, + including smart termination and a flash PROM for easy firmware updates, and + is of course compatible with the present Linux driver. The price for this + upgrade has been set at US $45 plus shipping and handling, and the upgrade + program will be administered through BusLogic Technical Support, which can + be reached by electronic mail at techsup@buslogic.com, by Voice at +1 408 + 654-0760, or by FAX at +1 408 492-1542. + + As of 14 June 1996, the original BusLogic FlashPoint LT to BT-948 upgrade + program has now been extended to encompass the FlashPoint LW Wide Ultra + SCSI Host Adapter. Any Linux user worldwide may trade in their FlashPoint + LW (BT-950) for a BT-958 MultiMaster PCI Ultra SCSI Host Adapter. The + price for this upgrade has been set at US $65 plus shipping and handling. + + I was a beta test site for the BT-948/958, and versions 1.2.1 and 1.3.1 of + my BusLogic driver already included latent support for the BT-948/958. + Additional cosmetic support for the Ultra SCSI MultiMaster cards was added + subsequent releases. As a result of this cooperative testing process, + several firmware bugs were found and corrected. My heavily loaded Linux + test system provided an ideal environment for testing error recovery + processes that are much more rarely exercised in production systems, but + are crucial to overall system stability. It was especially convenient + being able to work directly with their firmware engineer in demonstrating + the problems under control of the firmware debugging environment; things + sure have come a long way since the last time I worked on firmware for an + embedded system. I am presently working on some performance testing and + expect to have some data to report in the not too distant future. + + BusLogic asked me to send this announcement since a large percentage of the + questions regarding support for the FlashPoint have either been sent to me + directly via email, or have appeared in the Linux newsgroups in which I + participate. To summarize, BusLogic is offering Linux users an upgrade + from the unsupported FlashPoint LT (BT-930) to the supported BT-948 for US + $45 plus shipping and handling, or from the unsupported FlashPoint LW + (BT-950) to the supported BT-958 for $65 plus shipping and handling. + Contact BusLogic Technical Support at techsup@buslogic.com or +1 408 + 654-0760 to take advantage of their offer. + + Leonard N. Zubkoff + lnz@dandelion.com diff --git a/Documentation/scsi/FlashPoint.txt b/Documentation/scsi/FlashPoint.txt deleted file mode 100644 index 5b5f29cb9f8b..000000000000 --- a/Documentation/scsi/FlashPoint.txt +++ /dev/null @@ -1,163 +0,0 @@ -The BusLogic FlashPoint SCSI Host Adapters are now fully supported on Linux. -The upgrade program described below has been officially terminated effective -31 March 1997 since it is no longer needed. - - - - MYLEX INTRODUCES LINUX OPERATING SYSTEM SUPPORT FOR ITS - BUSLOGIC FLASHPOINT LINE OF SCSI HOST ADAPTERS - - -FREMONT, CA, -- October 8, 1996 -- Mylex Corporation has expanded Linux -operating system support to its BusLogic brand of FlashPoint Ultra SCSI -host adapters. All of BusLogic's other SCSI host adapters, including the -MultiMaster line, currently support the Linux operating system. Linux -drivers and information will be available on October 15th at -http://sourceforge.net/projects/dandelion/. - -"Mylex is committed to supporting the Linux community," says Peter Shambora, -vice president of marketing for Mylex. "We have supported Linux driver -development and provided technical support for our host adapters for several -years, and are pleased to now make our FlashPoint products available to this -user base." - -The Linux Operating System - -Linux is a freely-distributed implementation of UNIX for Intel x86, Sun -SPARC, SGI MIPS, Motorola 68k, Digital Alpha AXP and Motorola PowerPC -machines. It supports a wide range of software, including the X Window -System, Emacs, and TCP/IP networking. Further information is available at -http://www.linux.org and http://www.ssc.com/. - -FlashPoint Host Adapters - -The FlashPoint family of Ultra SCSI host adapters, designed for workstation -and file server environments, are available in narrow, wide, dual channel, -and dual channel wide versions. These adapters feature SeqEngine -automation technology, which minimizes SCSI command overhead and reduces -the number of interrupts generated to the CPU. - -About Mylex - -Mylex Corporation (NASDAQ/NM SYMBOL: MYLX), founded in 1983, is a leading -producer of RAID technology and network management products. The company -produces high performance disk array (RAID) controllers, and complementary -computer products for network servers, mass storage systems, workstations -and system boards. Through its wide range of RAID controllers and its -BusLogic line of Ultra SCSI host adapter products, Mylex provides enabling -intelligent I/O technologies that increase network management control, -enhance CPU utilization, optimize I/O performance, and ensure data security -and availability. Products are sold globally through a network of OEMs, -major distributors, VARs, and system integrators. Mylex Corporation is -headquartered at 34551 Ardenwood Blvd., Fremont, CA. - - #### - -Contact: - -Peter Shambora -Vice President of Marketing -Mylex Corp. -510/796-6100 -peters@mylex.com - - ANNOUNCEMENT - BusLogic FlashPoint LT/BT-948 Upgrade Program - 1 February 1996 - - ADDITIONAL ANNOUNCEMENT - BusLogic FlashPoint LW/BT-958 Upgrade Program - 14 June 1996 - -Ever since its introduction last October, the BusLogic FlashPoint LT has -been problematic for members of the Linux community, in that no Linux -drivers have been available for this new Ultra SCSI product. Despite its -officially being positioned as a desktop workstation product, and not being -particularly well suited for a high performance multitasking operating -system like Linux, the FlashPoint LT has been touted by computer system -vendors as the latest thing, and has been sold even on many of their high -end systems, to the exclusion of the older MultiMaster products. This has -caused grief for many people who inadvertently purchased a system expecting -that all BusLogic SCSI Host Adapters were supported by Linux, only to -discover that the FlashPoint was not supported and would not be for quite -some time, if ever. - -After this problem was identified, BusLogic contacted its major OEM -customers to make sure the BT-946C/956C MultiMaster cards would still be -made available, and that Linux users who mistakenly ordered systems with -the FlashPoint would be able to upgrade to the BT-946C. While this helped -many purchasers of new systems, it was only a partial solution to the -overall problem of FlashPoint support for Linux users. It did nothing to -assist the people who initially purchased a FlashPoint for a supported -operating system and then later decided to run Linux, or those who had -ended up with a FlashPoint LT, believing it was supported, and were unable -to return it. - -In the middle of December, I asked to meet with BusLogic's senior -management to discuss the issues related to Linux and free software support -for the FlashPoint. Rumors of varying accuracy had been circulating -publicly about BusLogic's attitude toward the Linux community, and I felt -it was best that these issues be addressed directly. I sent an email -message after 11pm one evening, and the meeting took place the next -afternoon. Unfortunately, corporate wheels sometimes grind slowly, -especially when a company is being acquired, and so it's taken until now -before the details were completely determined and a public statement could -be made. - -BusLogic is not prepared at this time to release the information necessary -for third parties to write drivers for the FlashPoint. The only existing -FlashPoint drivers have been written directly by BusLogic Engineering, and -there is no FlashPoint documentation sufficiently detailed to allow outside -developers to write a driver without substantial assistance. While there -are people at BusLogic who would rather not release the details of the -FlashPoint architecture at all, that debate has not yet been settled either -way. In any event, even if documentation were available today it would -take quite a while for a usable driver to be written, especially since I'm -not convinced that the effort required would be worthwhile. - -However, BusLogic does remain committed to providing a high performance -SCSI solution for the Linux community, and does not want to see anyone left -unable to run Linux because they have a Flashpoint LT. Therefore, BusLogic -has put in place a direct upgrade program to allow any Linux user worldwide -to trade in their FlashPoint LT for the new BT-948 MultiMaster PCI Ultra -SCSI Host Adapter. The BT-948 is the Ultra SCSI successor to the BT-946C -and has all the best features of both the BT-946C and FlashPoint LT, -including smart termination and a flash PROM for easy firmware updates, and -is of course compatible with the present Linux driver. The price for this -upgrade has been set at US $45 plus shipping and handling, and the upgrade -program will be administered through BusLogic Technical Support, which can -be reached by electronic mail at techsup@buslogic.com, by Voice at +1 408 -654-0760, or by FAX at +1 408 492-1542. - -As of 14 June 1996, the original BusLogic FlashPoint LT to BT-948 upgrade -program has now been extended to encompass the FlashPoint LW Wide Ultra -SCSI Host Adapter. Any Linux user worldwide may trade in their FlashPoint -LW (BT-950) for a BT-958 MultiMaster PCI Ultra SCSI Host Adapter. The -price for this upgrade has been set at US $65 plus shipping and handling. - -I was a beta test site for the BT-948/958, and versions 1.2.1 and 1.3.1 of -my BusLogic driver already included latent support for the BT-948/958. -Additional cosmetic support for the Ultra SCSI MultiMaster cards was added -subsequent releases. As a result of this cooperative testing process, -several firmware bugs were found and corrected. My heavily loaded Linux -test system provided an ideal environment for testing error recovery -processes that are much more rarely exercised in production systems, but -are crucial to overall system stability. It was especially convenient -being able to work directly with their firmware engineer in demonstrating -the problems under control of the firmware debugging environment; things -sure have come a long way since the last time I worked on firmware for an -embedded system. I am presently working on some performance testing and -expect to have some data to report in the not too distant future. - -BusLogic asked me to send this announcement since a large percentage of the -questions regarding support for the FlashPoint have either been sent to me -directly via email, or have appeared in the Linux newsgroups in which I -participate. To summarize, BusLogic is offering Linux users an upgrade -from the unsupported FlashPoint LT (BT-930) to the supported BT-948 for US -$45 plus shipping and handling, or from the unsupported FlashPoint LW -(BT-950) to the supported BT-958 for $65 plus shipping and handling. -Contact BusLogic Technical Support at techsup@buslogic.com or +1 408 -654-0760 to take advantage of their offer. - - Leonard N. Zubkoff - lnz@dandelion.com diff --git a/Documentation/scsi/index.rst b/Documentation/scsi/index.rst index b553dd9904bf..aad8359357e6 100644 --- a/Documentation/scsi/index.rst +++ b/Documentation/scsi/index.rst @@ -19,5 +19,6 @@ Linux SCSI Subsystem cxgb3i dc395x dpti + FlashPoint scsi_transport_srp/figures -- cgit v1.2.3 From 3c1e681bcdd86b86c676044330ec945d9abc4533 Mon Sep 17 00:00:00 2001 From: Mauro Carvalho Chehab Date: Mon, 2 Mar 2020 09:15:49 +0100 Subject: scsi: docs: convert g_NCR5380.txt to ReST Link: https://lore.kernel.org/r/a66e9ea704be6a7aa81b9864ad66a32b75ab808d.1583136624.git.mchehab+huawei@kernel.org Acked-by: Finn Thain Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Martin K. Petersen --- Documentation/scsi/g_NCR5380.rst | 93 ++++++++++++++++++++++++++++++++++ Documentation/scsi/g_NCR5380.txt | 68 ------------------------- Documentation/scsi/index.rst | 1 + Documentation/scsi/scsi-parameters.txt | 6 +-- 4 files changed, 97 insertions(+), 71 deletions(-) create mode 100644 Documentation/scsi/g_NCR5380.rst delete mode 100644 Documentation/scsi/g_NCR5380.txt (limited to 'Documentation/scsi') diff --git a/Documentation/scsi/g_NCR5380.rst b/Documentation/scsi/g_NCR5380.rst new file mode 100644 index 000000000000..a282059fec43 --- /dev/null +++ b/Documentation/scsi/g_NCR5380.rst @@ -0,0 +1,93 @@ +.. SPDX-License-Identifier: GPL-2.0 +.. include:: + +========================================== +README file for the Linux g_NCR5380 driver +========================================== + +Copyright |copy| 1993 Drew Eckhard + +NCR53c400 extensions Copyright |copy| 1994,1995,1996 Kevin Lentin + +This file documents the NCR53c400 extensions by Kevin Lentin and some +enhancements to the NCR5380 core. + +This driver supports NCR5380 and NCR53c400 and compatible cards in port or +memory mapped modes. + +Use of an interrupt is recommended, if supported by the board, as this will +allow targets to disconnect and thereby improve SCSI bus utilization. + +If the irq parameter is 254 or is omitted entirely, the driver will probe +for the correct IRQ line automatically. If the irq parameter is 0 or 255 +then no IRQ will be used. + +The NCR53c400 does not support DMA but it does have Pseudo-DMA which is +supported by the driver. + +This driver provides some information on what it has detected in +/proc/scsi/g_NCR5380/x where x is the scsi card number as detected at boot +time. More info to come in the future. + +This driver works as a module. +When included as a module, parameters can be passed on the insmod/modprobe +command line: + + ============= =============================================================== + irq=xx[,...] the interrupt(s) + base=xx[,...] the port or base address(es) (for port or memory mapped, resp.) + card=xx[,...] card type(s): + + == ====================================== + 0 NCR5380, + 1 NCR53C400, + 2 NCR53C400A, + 3 Domex Technology Corp 3181E (DTC3181E) + 4 Hewlett Packard C2502 + == ====================================== + ============= =============================================================== + +These old-style parameters can support only one card: + + ============= ================================================= + ncr_irq=xx the interrupt + ncr_addr=xx the port or base address (for port or memory + mapped, resp.) + ncr_5380=1 to set up for a NCR5380 board + ncr_53c400=1 to set up for a NCR53C400 board + ncr_53c400a=1 to set up for a NCR53C400A board + dtc_3181e=1 to set up for a Domex Technology Corp 3181E board + hp_c2502=1 to set up for a Hewlett Packard C2502 board + ============= ================================================= + +E.g. Trantor T130B in its default configuration:: + + modprobe g_NCR5380 irq=5 base=0x350 card=1 + +or alternatively, using the old syntax:: + + modprobe g_NCR5380 ncr_irq=5 ncr_addr=0x350 ncr_53c400=1 + +E.g. a port mapped NCR5380 board, driver to probe for IRQ:: + + modprobe g_NCR5380 base=0x350 card=0 + +or alternatively:: + + modprobe g_NCR5380 ncr_addr=0x350 ncr_5380=1 + +E.g. a memory mapped NCR53C400 board with no IRQ:: + + modprobe g_NCR5380 irq=255 base=0xc8000 card=1 + +or alternatively:: + + modprobe g_NCR5380 ncr_irq=255 ncr_addr=0xc8000 ncr_53c400=1 + +E.g. two cards, DTC3181 (in non-PnP mode) at 0x240 with no IRQ +and HP C2502 at 0x300 with IRQ 7:: + + modprobe g_NCR5380 irq=0,7 base=0x240,0x300 card=3,4 + +Kevin Lentin +K.Lentin@cs.monash.edu.au diff --git a/Documentation/scsi/g_NCR5380.txt b/Documentation/scsi/g_NCR5380.txt deleted file mode 100644 index 37b1967a00a9..000000000000 --- a/Documentation/scsi/g_NCR5380.txt +++ /dev/null @@ -1,68 +0,0 @@ -README file for the Linux g_NCR5380 driver. - -(c) 1993 Drew Eckhard -NCR53c400 extensions (c) 1994,1995,1996 Kevin Lentin - -This file documents the NCR53c400 extensions by Kevin Lentin and some -enhancements to the NCR5380 core. - -This driver supports NCR5380 and NCR53c400 and compatible cards in port or -memory mapped modes. - -Use of an interrupt is recommended, if supported by the board, as this will -allow targets to disconnect and thereby improve SCSI bus utilization. - -If the irq parameter is 254 or is omitted entirely, the driver will probe -for the correct IRQ line automatically. If the irq parameter is 0 or 255 -then no IRQ will be used. - -The NCR53c400 does not support DMA but it does have Pseudo-DMA which is -supported by the driver. - -This driver provides some information on what it has detected in -/proc/scsi/g_NCR5380/x where x is the scsi card number as detected at boot -time. More info to come in the future. - -This driver works as a module. -When included as a module, parameters can be passed on the insmod/modprobe -command line: - irq=xx[,...] the interrupt(s) - base=xx[,...] the port or base address(es) (for port or memory mapped, resp.) - card=xx[,...] card type(s): - 0 = NCR5380, - 1 = NCR53C400, - 2 = NCR53C400A, - 3 = Domex Technology Corp 3181E (DTC3181E) - 4 = Hewlett Packard C2502 - -These old-style parameters can support only one card: - ncr_irq=xx the interrupt - ncr_addr=xx the port or base address (for port or memory - mapped, resp.) - ncr_5380=1 to set up for a NCR5380 board - ncr_53c400=1 to set up for a NCR53C400 board - ncr_53c400a=1 to set up for a NCR53C400A board - dtc_3181e=1 to set up for a Domex Technology Corp 3181E board - hp_c2502=1 to set up for a Hewlett Packard C2502 board - -E.g. Trantor T130B in its default configuration: -modprobe g_NCR5380 irq=5 base=0x350 card=1 -or alternatively, using the old syntax, -modprobe g_NCR5380 ncr_irq=5 ncr_addr=0x350 ncr_53c400=1 - -E.g. a port mapped NCR5380 board, driver to probe for IRQ: -modprobe g_NCR5380 base=0x350 card=0 -or alternatively, -modprobe g_NCR5380 ncr_addr=0x350 ncr_5380=1 - -E.g. a memory mapped NCR53C400 board with no IRQ: -modprobe g_NCR5380 irq=255 base=0xc8000 card=1 -or alternatively, -modprobe g_NCR5380 ncr_irq=255 ncr_addr=0xc8000 ncr_53c400=1 - -E.g. two cards, DTC3181 (in non-PnP mode) at 0x240 with no IRQ -and HP C2502 at 0x300 with IRQ 7: -modprobe g_NCR5380 irq=0,7 base=0x240,0x300 card=3,4 - -Kevin Lentin -K.Lentin@cs.monash.edu.au diff --git a/Documentation/scsi/index.rst b/Documentation/scsi/index.rst index aad8359357e6..4b577c9e804e 100644 --- a/Documentation/scsi/index.rst +++ b/Documentation/scsi/index.rst @@ -20,5 +20,6 @@ Linux SCSI Subsystem dc395x dpti FlashPoint + g_NCR5380 scsi_transport_srp/figures diff --git a/Documentation/scsi/scsi-parameters.txt b/Documentation/scsi/scsi-parameters.txt index 266fd3b2398a..864bbf7f737b 100644 --- a/Documentation/scsi/scsi-parameters.txt +++ b/Documentation/scsi/scsi-parameters.txt @@ -57,13 +57,13 @@ parameters may be changed at runtime by the command See header of drivers/scsi/NCR_D700.c. ncr5380= [HW,SCSI] - See Documentation/scsi/g_NCR5380.txt. + See Documentation/scsi/g_NCR5380.rst. ncr53c400= [HW,SCSI] - See Documentation/scsi/g_NCR5380.txt. + See Documentation/scsi/g_NCR5380.rst. ncr53c400a= [HW,SCSI] - See Documentation/scsi/g_NCR5380.txt. + See Documentation/scsi/g_NCR5380.rst. ncr53c8xx= [HW,SCSI] -- cgit v1.2.3 From 1392de9d7a89915bf0269e038b0d2b3a393d253d Mon Sep 17 00:00:00 2001 From: Mauro Carvalho Chehab Date: Mon, 2 Mar 2020 09:15:50 +0100 Subject: scsi: docs: convert hpsa.txt to ReST Link: https://lore.kernel.org/r/ea58e04176d43fb7194615b145060aa04c9cf3ad.1583136624.git.mchehab+huawei@kernel.org Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Martin K. Petersen --- Documentation/scsi/hpsa.rst | 129 ++++++++++++++++++++++++++++++++++++++++++ Documentation/scsi/hpsa.txt | 130 ------------------------------------------- Documentation/scsi/index.rst | 1 + 3 files changed, 130 insertions(+), 130 deletions(-) create mode 100644 Documentation/scsi/hpsa.rst delete mode 100644 Documentation/scsi/hpsa.txt (limited to 'Documentation/scsi') diff --git a/Documentation/scsi/hpsa.rst b/Documentation/scsi/hpsa.rst new file mode 100644 index 000000000000..340e10c6e35f --- /dev/null +++ b/Documentation/scsi/hpsa.rst @@ -0,0 +1,129 @@ +.. SPDX-License-Identifier: GPL-2.0 + +========================================= +HPSA - Hewlett Packard Smart Array driver +========================================= + +This file describes the hpsa SCSI driver for HP Smart Array controllers. +The hpsa driver is intended to supplant the cciss driver for newer +Smart Array controllers. The hpsa driver is a SCSI driver, while the +cciss driver is a "block" driver. Actually cciss is both a block +driver (for logical drives) AND a SCSI driver (for tape drives). This +"split-brained" design of the cciss driver is a source of excess +complexity and eliminating that complexity is one of the reasons +for hpsa to exist. + +Supported devices +================= + +- Smart Array P212 +- Smart Array P410 +- Smart Array P410i +- Smart Array P411 +- Smart Array P812 +- Smart Array P712m +- Smart Array P711m +- StorageWorks P1210m + +Additionally, older Smart Arrays may work with the hpsa driver if the kernel +boot parameter "hpsa_allow_any=1" is specified, however these are not tested +nor supported by HP with this driver. For older Smart Arrays, the cciss +driver should still be used. + +The "hpsa_simple_mode=1" boot parameter may be used to prevent the driver from +putting the controller into "performant" mode. The difference is that with simple +mode, each command completion requires an interrupt, while with "performant mode" +(the default, and ordinarily better performing) it is possible to have multiple +command completions indicated by a single interrupt. + +HPSA specific entries in /sys +============================= + + In addition to the generic SCSI attributes available in /sys, hpsa supports + the following attributes: + +HPSA specific host attributes +============================= + + :: + + /sys/class/scsi_host/host*/rescan + /sys/class/scsi_host/host*/firmware_revision + /sys/class/scsi_host/host*/resettable + /sys/class/scsi_host/host*/transport_mode + + the host "rescan" attribute is a write only attribute. Writing to this + attribute will cause the driver to scan for new, changed, or removed devices + (e.g. hot-plugged tape drives, or newly configured or deleted logical drives, + etc.) and notify the SCSI midlayer of any changes detected. Normally this is + triggered automatically by HP's Array Configuration Utility (either the GUI or + command line variety) so for logical drive changes, the user should not + normally have to use this. It may be useful when hot plugging devices like + tape drives, or entire storage boxes containing pre-configured logical drives. + + The "firmware_revision" attribute contains the firmware version of the Smart Array. + For example:: + + root@host:/sys/class/scsi_host/host4# cat firmware_revision + 7.14 + + The transport_mode indicates whether the controller is in "performant" + or "simple" mode. This is controlled by the "hpsa_simple_mode" module + parameter. + + The "resettable" read-only attribute indicates whether a particular + controller is able to honor the "reset_devices" kernel parameter. If the + device is resettable, this file will contain a "1", otherwise, a "0". This + parameter is used by kdump, for example, to reset the controller at driver + load time to eliminate any outstanding commands on the controller and get the + controller into a known state so that the kdump initiated i/o will work right + and not be disrupted in any way by stale commands or other stale state + remaining on the controller from the previous kernel. This attribute enables + kexec tools to warn the user if they attempt to designate a device which is + unable to honor the reset_devices kernel parameter as a dump device. + +HPSA specific disk attributes +----------------------------- + + :: + + /sys/class/scsi_disk/c:b:t:l/device/unique_id + /sys/class/scsi_disk/c:b:t:l/device/raid_level + /sys/class/scsi_disk/c:b:t:l/device/lunid + + (where c:b:t:l are the controller, bus, target and lun of the device) + + For example:: + + root@host:/sys/class/scsi_disk/4:0:0:0/device# cat unique_id + 600508B1001044395355323037570F77 + root@host:/sys/class/scsi_disk/4:0:0:0/device# cat lunid + 0x0000004000000000 + root@host:/sys/class/scsi_disk/4:0:0:0/device# cat raid_level + RAID 0 + +HPSA specific ioctls +==================== + + For compatibility with applications written for the cciss driver, many, but + not all of the ioctls supported by the cciss driver are also supported by the + hpsa driver. The data structures used by these are described in + include/linux/cciss_ioctl.h + + CCISS_DEREGDISK, CCISS_REGNEWDISK, CCISS_REGNEWD + The above three ioctls all do exactly the same thing, which is to cause the driver + to rescan for new devices. This does exactly the same thing as writing to the + hpsa specific host "rescan" attribute. + + CCISS_GETPCIINFO + Returns PCI domain, bus, device and function and "board ID" (PCI subsystem ID). + + CCISS_GETDRIVVER + Returns driver version in three bytes encoded as:: + + (major_version << 16) | (minor_version << 8) | (subminor_version) + + CCISS_PASSTHRU, CCISS_BIG_PASSTHRU + Allows "BMIC" and "CISS" commands to be passed through to the Smart Array. + These are used extensively by the HP Array Configuration Utility, SNMP storage + agents, etc. See cciss_vol_status at http://cciss.sf.net for some examples. diff --git a/Documentation/scsi/hpsa.txt b/Documentation/scsi/hpsa.txt deleted file mode 100644 index 891435a72fce..000000000000 --- a/Documentation/scsi/hpsa.txt +++ /dev/null @@ -1,130 +0,0 @@ - -HPSA - Hewlett Packard Smart Array driver ------------------------------------------ - -This file describes the hpsa SCSI driver for HP Smart Array controllers. -The hpsa driver is intended to supplant the cciss driver for newer -Smart Array controllers. The hpsa driver is a SCSI driver, while the -cciss driver is a "block" driver. Actually cciss is both a block -driver (for logical drives) AND a SCSI driver (for tape drives). This -"split-brained" design of the cciss driver is a source of excess -complexity and eliminating that complexity is one of the reasons -for hpsa to exist. - -Supported devices: ------------------- - -Smart Array P212 -Smart Array P410 -Smart Array P410i -Smart Array P411 -Smart Array P812 -Smart Array P712m -Smart Array P711m -StorageWorks P1210m - -Additionally, older Smart Arrays may work with the hpsa driver if the kernel -boot parameter "hpsa_allow_any=1" is specified, however these are not tested -nor supported by HP with this driver. For older Smart Arrays, the cciss -driver should still be used. - -The "hpsa_simple_mode=1" boot parameter may be used to prevent the driver from -putting the controller into "performant" mode. The difference is that with simple -mode, each command completion requires an interrupt, while with "performant mode" -(the default, and ordinarily better performing) it is possible to have multiple -command completions indicated by a single interrupt. - -HPSA specific entries in /sys ------------------------------ - - In addition to the generic SCSI attributes available in /sys, hpsa supports - the following attributes: - - HPSA specific host attributes: - ------------------------------ - - /sys/class/scsi_host/host*/rescan - /sys/class/scsi_host/host*/firmware_revision - /sys/class/scsi_host/host*/resettable - /sys/class/scsi_host/host*/transport_mode - - the host "rescan" attribute is a write only attribute. Writing to this - attribute will cause the driver to scan for new, changed, or removed devices - (e.g. hot-plugged tape drives, or newly configured or deleted logical drives, - etc.) and notify the SCSI midlayer of any changes detected. Normally this is - triggered automatically by HP's Array Configuration Utility (either the GUI or - command line variety) so for logical drive changes, the user should not - normally have to use this. It may be useful when hot plugging devices like - tape drives, or entire storage boxes containing pre-configured logical drives. - - The "firmware_revision" attribute contains the firmware version of the Smart Array. - For example: - - root@host:/sys/class/scsi_host/host4# cat firmware_revision - 7.14 - - The transport_mode indicates whether the controller is in "performant" - or "simple" mode. This is controlled by the "hpsa_simple_mode" module - parameter. - - The "resettable" read-only attribute indicates whether a particular - controller is able to honor the "reset_devices" kernel parameter. If the - device is resettable, this file will contain a "1", otherwise, a "0". This - parameter is used by kdump, for example, to reset the controller at driver - load time to eliminate any outstanding commands on the controller and get the - controller into a known state so that the kdump initiated i/o will work right - and not be disrupted in any way by stale commands or other stale state - remaining on the controller from the previous kernel. This attribute enables - kexec tools to warn the user if they attempt to designate a device which is - unable to honor the reset_devices kernel parameter as a dump device. - - HPSA specific disk attributes: - ------------------------------ - - /sys/class/scsi_disk/c:b:t:l/device/unique_id - /sys/class/scsi_disk/c:b:t:l/device/raid_level - /sys/class/scsi_disk/c:b:t:l/device/lunid - - (where c:b:t:l are the controller, bus, target and lun of the device) - - For example: - - root@host:/sys/class/scsi_disk/4:0:0:0/device# cat unique_id - 600508B1001044395355323037570F77 - root@host:/sys/class/scsi_disk/4:0:0:0/device# cat lunid - 0x0000004000000000 - root@host:/sys/class/scsi_disk/4:0:0:0/device# cat raid_level - RAID 0 - -HPSA specific ioctls: ---------------------- - - For compatibility with applications written for the cciss driver, many, but - not all of the ioctls supported by the cciss driver are also supported by the - hpsa driver. The data structures used by these are described in - include/linux/cciss_ioctl.h - - CCISS_DEREGDISK - CCISS_REGNEWDISK - CCISS_REGNEWD - - The above three ioctls all do exactly the same thing, which is to cause the driver - to rescan for new devices. This does exactly the same thing as writing to the - hpsa specific host "rescan" attribute. - - CCISS_GETPCIINFO - - Returns PCI domain, bus, device and function and "board ID" (PCI subsystem ID). - - CCISS_GETDRIVVER - - Returns driver version in three bytes encoded as: - (major_version << 16) | (minor_version << 8) | (subminor_version) - - CCISS_PASSTHRU - CCISS_BIG_PASSTHRU - - Allows "BMIC" and "CISS" commands to be passed through to the Smart Array. - These are used extensively by the HP Array Configuration Utility, SNMP storage - agents, etc. See cciss_vol_status at http://cciss.sf.net for some examples. - diff --git a/Documentation/scsi/index.rst b/Documentation/scsi/index.rst index 4b577c9e804e..b16f348bd31b 100644 --- a/Documentation/scsi/index.rst +++ b/Documentation/scsi/index.rst @@ -21,5 +21,6 @@ Linux SCSI Subsystem dpti FlashPoint g_NCR5380 + hpsa scsi_transport_srp/figures -- cgit v1.2.3 From ac69461b6058dc8bc84b940665b84828575b0cc6 Mon Sep 17 00:00:00 2001 From: Mauro Carvalho Chehab Date: Mon, 2 Mar 2020 09:15:51 +0100 Subject: scsi: docs: convert hptiop.txt to ReST Link: https://lore.kernel.org/r/d189a339bb360b7b397914ee3ddeb75d9a7fd788.1583136624.git.mchehab+huawei@kernel.org Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Martin K. Petersen --- Documentation/scsi/hptiop.rst | 215 ++++++++++++++++++++++++++++++++++++++++++ Documentation/scsi/hptiop.txt | 184 ------------------------------------ Documentation/scsi/index.rst | 1 + 3 files changed, 216 insertions(+), 184 deletions(-) create mode 100644 Documentation/scsi/hptiop.rst delete mode 100644 Documentation/scsi/hptiop.txt (limited to 'Documentation/scsi') diff --git a/Documentation/scsi/hptiop.rst b/Documentation/scsi/hptiop.rst new file mode 100644 index 000000000000..23ae7ae36971 --- /dev/null +++ b/Documentation/scsi/hptiop.rst @@ -0,0 +1,215 @@ +.. SPDX-License-Identifier: GPL-2.0 +.. include:: + +====================================================== +Highpoint RocketRAID 3xxx/4xxx Adapter Driver (hptiop) +====================================================== + +Controller Register Map +----------------------- + +For RR44xx Intel IOP based adapters, the controller IOP is accessed via PCI BAR0 and BAR2 + + ============== ================================== + BAR0 offset Register + ============== ================================== + 0x11C5C Link Interface IRQ Set + 0x11C60 Link Interface IRQ Clear + ============== ================================== + + ============== ================================== + BAR2 offset Register + ============== ================================== + 0x10 Inbound Message Register 0 + 0x14 Inbound Message Register 1 + 0x18 Outbound Message Register 0 + 0x1C Outbound Message Register 1 + 0x20 Inbound Doorbell Register + 0x24 Inbound Interrupt Status Register + 0x28 Inbound Interrupt Mask Register + 0x30 Outbound Interrupt Status Register + 0x34 Outbound Interrupt Mask Register + 0x40 Inbound Queue Port + 0x44 Outbound Queue Port + ============== ================================== + +For Intel IOP based adapters, the controller IOP is accessed via PCI BAR0: + + ============== ================================== + BAR0 offset Register + ============== ================================== + 0x10 Inbound Message Register 0 + 0x14 Inbound Message Register 1 + 0x18 Outbound Message Register 0 + 0x1C Outbound Message Register 1 + 0x20 Inbound Doorbell Register + 0x24 Inbound Interrupt Status Register + 0x28 Inbound Interrupt Mask Register + 0x30 Outbound Interrupt Status Register + 0x34 Outbound Interrupt Mask Register + 0x40 Inbound Queue Port + 0x44 Outbound Queue Port + ============== ================================== + +For Marvell not Frey IOP based adapters, the IOP is accessed via PCI BAR0 and BAR1: + + ============== ================================== + BAR0 offset Register + ============== ================================== + 0x20400 Inbound Doorbell Register + 0x20404 Inbound Interrupt Mask Register + 0x20408 Outbound Doorbell Register + 0x2040C Outbound Interrupt Mask Register + ============== ================================== + + ============== ================================== + BAR1 offset Register + ============== ================================== + 0x0 Inbound Queue Head Pointer + 0x4 Inbound Queue Tail Pointer + 0x8 Outbound Queue Head Pointer + 0xC Outbound Queue Tail Pointer + 0x10 Inbound Message Register + 0x14 Outbound Message Register + 0x40-0x1040 Inbound Queue + 0x1040-0x2040 Outbound Queue + ============== ================================== + +For Marvell Frey IOP based adapters, the IOP is accessed via PCI BAR0 and BAR1: + + ============== ================================== + BAR0 offset Register + ============== ================================== + 0x0 IOP configuration information. + ============== ================================== + + ============== =================================================== + BAR1 offset Register + ============== =================================================== + 0x4000 Inbound List Base Address Low + 0x4004 Inbound List Base Address High + 0x4018 Inbound List Write Pointer + 0x402C Inbound List Configuration and Control + 0x4050 Outbound List Base Address Low + 0x4054 Outbound List Base Address High + 0x4058 Outbound List Copy Pointer Shadow Base Address Low + 0x405C Outbound List Copy Pointer Shadow Base Address High + 0x4088 Outbound List Interrupt Cause + 0x408C Outbound List Interrupt Enable + 0x1020C PCIe Function 0 Interrupt Enable + 0x10400 PCIe Function 0 to CPU Message A + 0x10420 CPU to PCIe Function 0 Message A + 0x10480 CPU to PCIe Function 0 Doorbell + 0x10484 CPU to PCIe Function 0 Doorbell Enable + ============== =================================================== + + +I/O Request Workflow of Not Marvell Frey +---------------------------------------- + +All queued requests are handled via inbound/outbound queue port. +A request packet can be allocated in either IOP or host memory. + +To send a request to the controller: + + - Get a free request packet by reading the inbound queue port or + allocate a free request in host DMA coherent memory. + + The value returned from the inbound queue port is an offset + relative to the IOP BAR0. + + Requests allocated in host memory must be aligned on 32-bytes boundary. + + - Fill the packet. + + - Post the packet to IOP by writing it to inbound queue. For requests + allocated in IOP memory, write the offset to inbound queue port. For + requests allocated in host memory, write (0x80000000|(bus_addr>>5)) + to the inbound queue port. + + - The IOP process the request. When the request is completed, it + will be put into outbound queue. An outbound interrupt will be + generated. + + For requests allocated in IOP memory, the request offset is posted to + outbound queue. + + For requests allocated in host memory, (0x80000000|(bus_addr>>5)) + is posted to the outbound queue. If IOP_REQUEST_FLAG_OUTPUT_CONTEXT + flag is set in the request, the low 32-bit context value will be + posted instead. + + - The host read the outbound queue and complete the request. + + For requests allocated in IOP memory, the host driver free the request + by writing it to the outbound queue. + +Non-queued requests (reset/flush etc) can be sent via inbound message +register 0. An outbound message with the same value indicates the completion +of an inbound message. + + +I/O Request Workflow of Marvell Frey +------------------------------------ + +All queued requests are handled via inbound/outbound list. + +To send a request to the controller: + + - Allocate a free request in host DMA coherent memory. + + Requests allocated in host memory must be aligned on 32-bytes boundary. + + - Fill the request with index of the request in the flag. + + Fill a free inbound list unit with the physical address and the size of + the request. + + Set up the inbound list write pointer with the index of previous unit, + round to 0 if the index reaches the supported count of requests. + + - Post the inbound list writer pointer to IOP. + + - The IOP process the request. When the request is completed, the flag of + the request with or-ed IOPMU_QUEUE_MASK_HOST_BITS will be put into a + free outbound list unit and the index of the outbound list unit will be + put into the copy pointer shadow register. An outbound interrupt will be + generated. + + - The host read the outbound list copy pointer shadow register and compare + with previous saved read pointer N. If they are different, the host will + read the (N+1)th outbound list unit. + + The host get the index of the request from the (N+1)th outbound list + unit and complete the request. + +Non-queued requests (reset communication/reset/flush etc) can be sent via PCIe +Function 0 to CPU Message A register. The CPU to PCIe Function 0 Message register +with the same value indicates the completion of message. + + +User-level Interface +--------------------- + +The driver exposes following sysfs attributes: + + ================== === ======================== + NAME R/W Description + ================== === ======================== + driver-version R driver version string + firmware-version R firmware version string + ================== === ======================== + + +----------------------------------------------------------------------------- + +Copyright |copy| 2006-2012 HighPoint Technologies, Inc. All Rights Reserved. + + This file is distributed in the hope that it will be useful, + but WITHOUT ANY WARRANTY; without even the implied warranty of + MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + GNU General Public License for more details. + + linux@highpoint-tech.com + + http://www.highpoint-tech.com diff --git a/Documentation/scsi/hptiop.txt b/Documentation/scsi/hptiop.txt deleted file mode 100644 index 12ecfd308e55..000000000000 --- a/Documentation/scsi/hptiop.txt +++ /dev/null @@ -1,184 +0,0 @@ -HIGHPOINT ROCKETRAID 3xxx/4xxx ADAPTER DRIVER (hptiop) - -Controller Register Map -------------------------- - -For RR44xx Intel IOP based adapters, the controller IOP is accessed via PCI BAR0 and BAR2: - - BAR0 offset Register - 0x11C5C Link Interface IRQ Set - 0x11C60 Link Interface IRQ Clear - - BAR2 offset Register - 0x10 Inbound Message Register 0 - 0x14 Inbound Message Register 1 - 0x18 Outbound Message Register 0 - 0x1C Outbound Message Register 1 - 0x20 Inbound Doorbell Register - 0x24 Inbound Interrupt Status Register - 0x28 Inbound Interrupt Mask Register - 0x30 Outbound Interrupt Status Register - 0x34 Outbound Interrupt Mask Register - 0x40 Inbound Queue Port - 0x44 Outbound Queue Port - -For Intel IOP based adapters, the controller IOP is accessed via PCI BAR0: - - BAR0 offset Register - 0x10 Inbound Message Register 0 - 0x14 Inbound Message Register 1 - 0x18 Outbound Message Register 0 - 0x1C Outbound Message Register 1 - 0x20 Inbound Doorbell Register - 0x24 Inbound Interrupt Status Register - 0x28 Inbound Interrupt Mask Register - 0x30 Outbound Interrupt Status Register - 0x34 Outbound Interrupt Mask Register - 0x40 Inbound Queue Port - 0x44 Outbound Queue Port - -For Marvell not Frey IOP based adapters, the IOP is accessed via PCI BAR0 and BAR1: - - BAR0 offset Register - 0x20400 Inbound Doorbell Register - 0x20404 Inbound Interrupt Mask Register - 0x20408 Outbound Doorbell Register - 0x2040C Outbound Interrupt Mask Register - - BAR1 offset Register - 0x0 Inbound Queue Head Pointer - 0x4 Inbound Queue Tail Pointer - 0x8 Outbound Queue Head Pointer - 0xC Outbound Queue Tail Pointer - 0x10 Inbound Message Register - 0x14 Outbound Message Register - 0x40-0x1040 Inbound Queue - 0x1040-0x2040 Outbound Queue - -For Marvell Frey IOP based adapters, the IOP is accessed via PCI BAR0 and BAR1: - - BAR0 offset Register - 0x0 IOP configuration information. - - BAR1 offset Register - 0x4000 Inbound List Base Address Low - 0x4004 Inbound List Base Address High - 0x4018 Inbound List Write Pointer - 0x402C Inbound List Configuration and Control - 0x4050 Outbound List Base Address Low - 0x4054 Outbound List Base Address High - 0x4058 Outbound List Copy Pointer Shadow Base Address Low - 0x405C Outbound List Copy Pointer Shadow Base Address High - 0x4088 Outbound List Interrupt Cause - 0x408C Outbound List Interrupt Enable - 0x1020C PCIe Function 0 Interrupt Enable - 0x10400 PCIe Function 0 to CPU Message A - 0x10420 CPU to PCIe Function 0 Message A - 0x10480 CPU to PCIe Function 0 Doorbell - 0x10484 CPU to PCIe Function 0 Doorbell Enable - - -I/O Request Workflow of Not Marvell Frey ------------------------------------------- - -All queued requests are handled via inbound/outbound queue port. -A request packet can be allocated in either IOP or host memory. - -To send a request to the controller: - - - Get a free request packet by reading the inbound queue port or - allocate a free request in host DMA coherent memory. - - The value returned from the inbound queue port is an offset - relative to the IOP BAR0. - - Requests allocated in host memory must be aligned on 32-bytes boundary. - - - Fill the packet. - - - Post the packet to IOP by writing it to inbound queue. For requests - allocated in IOP memory, write the offset to inbound queue port. For - requests allocated in host memory, write (0x80000000|(bus_addr>>5)) - to the inbound queue port. - - - The IOP process the request. When the request is completed, it - will be put into outbound queue. An outbound interrupt will be - generated. - - For requests allocated in IOP memory, the request offset is posted to - outbound queue. - - For requests allocated in host memory, (0x80000000|(bus_addr>>5)) - is posted to the outbound queue. If IOP_REQUEST_FLAG_OUTPUT_CONTEXT - flag is set in the request, the low 32-bit context value will be - posted instead. - - - The host read the outbound queue and complete the request. - - For requests allocated in IOP memory, the host driver free the request - by writing it to the outbound queue. - -Non-queued requests (reset/flush etc) can be sent via inbound message -register 0. An outbound message with the same value indicates the completion -of an inbound message. - - -I/O Request Workflow of Marvell Frey --------------------------------------- - -All queued requests are handled via inbound/outbound list. - -To send a request to the controller: - - - Allocate a free request in host DMA coherent memory. - - Requests allocated in host memory must be aligned on 32-bytes boundary. - - - Fill the request with index of the request in the flag. - - Fill a free inbound list unit with the physical address and the size of - the request. - - Set up the inbound list write pointer with the index of previous unit, - round to 0 if the index reaches the supported count of requests. - - - Post the inbound list writer pointer to IOP. - - - The IOP process the request. When the request is completed, the flag of - the request with or-ed IOPMU_QUEUE_MASK_HOST_BITS will be put into a - free outbound list unit and the index of the outbound list unit will be - put into the copy pointer shadow register. An outbound interrupt will be - generated. - - - The host read the outbound list copy pointer shadow register and compare - with previous saved read pointer N. If they are different, the host will - read the (N+1)th outbound list unit. - - The host get the index of the request from the (N+1)th outbound list - unit and complete the request. - -Non-queued requests (reset communication/reset/flush etc) can be sent via PCIe -Function 0 to CPU Message A register. The CPU to PCIe Function 0 Message register -with the same value indicates the completion of message. - - -User-level Interface ---------------------- - -The driver exposes following sysfs attributes: - - NAME R/W Description - driver-version R driver version string - firmware-version R firmware version string - - ------------------------------------------------------------------------------ -Copyright (C) 2006-2012 HighPoint Technologies, Inc. All Rights Reserved. - - This file is distributed in the hope that it will be useful, - but WITHOUT ANY WARRANTY; without even the implied warranty of - MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the - GNU General Public License for more details. - - linux@highpoint-tech.com - http://www.highpoint-tech.com diff --git a/Documentation/scsi/index.rst b/Documentation/scsi/index.rst index b16f348bd31b..b13df9c1810a 100644 --- a/Documentation/scsi/index.rst +++ b/Documentation/scsi/index.rst @@ -22,5 +22,6 @@ Linux SCSI Subsystem FlashPoint g_NCR5380 hpsa + hptiop scsi_transport_srp/figures -- cgit v1.2.3 From a88dc3ec2ca48d23c7761af02e1ceea731f609e9 Mon Sep 17 00:00:00 2001 From: Mauro Carvalho Chehab Date: Mon, 2 Mar 2020 09:15:52 +0100 Subject: scsi: docs: convert libsas.txt to ReST Link: https://lore.kernel.org/r/9022cb5551487f774cab16a828fe06b0b6b3add3.1583136624.git.mchehab+huawei@kernel.org Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Martin K. Petersen --- Documentation/scsi/index.rst | 1 + Documentation/scsi/libsas.rst | 465 ++++++++++++++++++++++++++++++++++++++++++ Documentation/scsi/libsas.txt | 395 ----------------------------------- 3 files changed, 466 insertions(+), 395 deletions(-) create mode 100644 Documentation/scsi/libsas.rst delete mode 100644 Documentation/scsi/libsas.txt (limited to 'Documentation/scsi') diff --git a/Documentation/scsi/index.rst b/Documentation/scsi/index.rst index b13df9c1810a..e6850c0a1378 100644 --- a/Documentation/scsi/index.rst +++ b/Documentation/scsi/index.rst @@ -23,5 +23,6 @@ Linux SCSI Subsystem g_NCR5380 hpsa hptiop + libsas scsi_transport_srp/figures diff --git a/Documentation/scsi/libsas.rst b/Documentation/scsi/libsas.rst new file mode 100644 index 000000000000..7216b5d25800 --- /dev/null +++ b/Documentation/scsi/libsas.rst @@ -0,0 +1,465 @@ +.. SPDX-License-Identifier: GPL-2.0 + +========= +SAS Layer +========= + +The SAS Layer is a management infrastructure which manages +SAS LLDDs. It sits between SCSI Core and SAS LLDDs. The +layout is as follows: while SCSI Core is concerned with +SAM/SPC issues, and a SAS LLDD+sequencer is concerned with +phy/OOB/link management, the SAS layer is concerned with: + + * SAS Phy/Port/HA event management (LLDD generates, + SAS Layer processes), + * SAS Port management (creation/destruction), + * SAS Domain discovery and revalidation, + * SAS Domain device management, + * SCSI Host registration/unregistration, + * Device registration with SCSI Core (SAS) or libata + (SATA), and + * Expander management and exporting expander control + to user space. + +A SAS LLDD is a PCI device driver. It is concerned with +phy/OOB management, and vendor specific tasks and generates +events to the SAS layer. + +The SAS Layer does most SAS tasks as outlined in the SAS 1.1 +spec. + +The sas_ha_struct describes the SAS LLDD to the SAS layer. +Most of it is used by the SAS Layer but a few fields need to +be initialized by the LLDDs. + +After initializing your hardware, from the probe() function +you call sas_register_ha(). It will register your LLDD with +the SCSI subsystem, creating a SCSI host and it will +register your SAS driver with the sysfs SAS tree it creates. +It will then return. Then you enable your phys to actually +start OOB (at which point your driver will start calling the +notify_* event callbacks). + +Structure descriptions +====================== + +``struct sas_phy`` +------------------ + +Normally this is statically embedded to your driver's +phy structure:: + + struct my_phy { + blah; + struct sas_phy sas_phy; + bleh; + }; + +And then all the phys are an array of my_phy in your HA +struct (shown below). + +Then as you go along and initialize your phys you also +initialize the sas_phy struct, along with your own +phy structure. + +In general, the phys are managed by the LLDD and the ports +are managed by the SAS layer. So the phys are initialized +and updated by the LLDD and the ports are initialized and +updated by the SAS layer. + +There is a scheme where the LLDD can RW certain fields, +and the SAS layer can only read such ones, and vice versa. +The idea is to avoid unnecessary locking. + +enabled + - must be set (0/1) + +id + - must be set [0,MAX_PHYS)] + +class, proto, type, role, oob_mode, linkrate + - must be set + +oob_mode + - you set this when OOB has finished and then notify + the SAS Layer. + +sas_addr + - this normally points to an array holding the sas + address of the phy, possibly somewhere in your my_phy + struct. + +attached_sas_addr + - set this when you (LLDD) receive an + IDENTIFY frame or a FIS frame, _before_ notifying the SAS + layer. The idea is that sometimes the LLDD may want to fake + or provide a different SAS address on that phy/port and this + allows it to do this. At best you should copy the sas + address from the IDENTIFY frame or maybe generate a SAS + address for SATA directly attached devices. The Discover + process may later change this. + +frame_rcvd + - this is where you copy the IDENTIFY/FIS frame + when you get it; you lock, copy, set frame_rcvd_size and + unlock the lock, and then call the event. It is a pointer + since there's no way to know your hw frame size _exactly_, + so you define the actual array in your phy struct and let + this pointer point to it. You copy the frame from your + DMAable memory to that area holding the lock. + +sas_prim + - this is where primitives go when they're + received. See sas.h. Grab the lock, set the primitive, + release the lock, notify. + +port + - this points to the sas_port if the phy belongs + to a port -- the LLDD only reads this. It points to the + sas_port this phy is part of. Set by the SAS Layer. + +ha + - may be set; the SAS layer sets it anyway. + +lldd_phy + - you should set this to point to your phy so you + can find your way around faster when the SAS layer calls one + of your callbacks and passes you a phy. If the sas_phy is + embedded you can also use container_of -- whatever you + prefer. + + +``struct sas_port`` +------------------- + +The LLDD doesn't set any fields of this struct -- it only +reads them. They should be self explanatory. + +phy_mask is 32 bit, this should be enough for now, as I +haven't heard of a HA having more than 8 phys. + +lldd_port + - I haven't found use for that -- maybe other + LLDD who wish to have internal port representation can make + use of this. + +``struct sas_ha_struct`` +------------------------ + +It normally is statically declared in your own LLDD +structure describing your adapter:: + + struct my_sas_ha { + blah; + struct sas_ha_struct sas_ha; + struct my_phy phys[MAX_PHYS]; + struct sas_port sas_ports[MAX_PHYS]; /* (1) */ + bleh; + }; + + (1) If your LLDD doesn't have its own port representation. + +What needs to be initialized (sample function given below). + +pcidev +^^^^^^ + +sas_addr + - since the SAS layer doesn't want to mess with + memory allocation, etc, this points to statically + allocated array somewhere (say in your host adapter + structure) and holds the SAS address of the host + adapter as given by you or the manufacturer, etc. + +sas_port +^^^^^^^^ + +sas_phy + - an array of pointers to structures. (see + note above on sas_addr). + These must be set. See more notes below. + +num_phys + - the number of phys present in the sas_phy array, + and the number of ports present in the sas_port + array. There can be a maximum num_phys ports (one per + port) so we drop the num_ports, and only use + num_phys. + +The event interface:: + + /* LLDD calls these to notify the class of an event. */ + void (*notify_ha_event)(struct sas_ha_struct *, enum ha_event); + void (*notify_port_event)(struct sas_phy *, enum port_event); + void (*notify_phy_event)(struct sas_phy *, enum phy_event); + +When sas_register_ha() returns, those are set and can be +called by the LLDD to notify the SAS layer of such events +the SAS layer. + +The port notification:: + + /* The class calls these to notify the LLDD of an event. */ + void (*lldd_port_formed)(struct sas_phy *); + void (*lldd_port_deformed)(struct sas_phy *); + +If the LLDD wants notification when a port has been formed +or deformed it sets those to a function satisfying the type. + +A SAS LLDD should also implement at least one of the Task +Management Functions (TMFs) described in SAM:: + + /* Task Management Functions. Must be called from process context. */ + int (*lldd_abort_task)(struct sas_task *); + int (*lldd_abort_task_set)(struct domain_device *, u8 *lun); + int (*lldd_clear_aca)(struct domain_device *, u8 *lun); + int (*lldd_clear_task_set)(struct domain_device *, u8 *lun); + int (*lldd_I_T_nexus_reset)(struct domain_device *); + int (*lldd_lu_reset)(struct domain_device *, u8 *lun); + int (*lldd_query_task)(struct sas_task *); + +For more information please read SAM from T10.org. + +Port and Adapter management:: + + /* Port and Adapter management */ + int (*lldd_clear_nexus_port)(struct sas_port *); + int (*lldd_clear_nexus_ha)(struct sas_ha_struct *); + +A SAS LLDD should implement at least one of those. + +Phy management:: + + /* Phy management */ + int (*lldd_control_phy)(struct sas_phy *, enum phy_func); + +lldd_ha + - set this to point to your HA struct. You can also + use container_of if you embedded it as shown above. + +A sample initialization and registration function +can look like this (called last thing from probe()) +*but* before you enable the phys to do OOB:: + + static int register_sas_ha(struct my_sas_ha *my_ha) + { + int i; + static struct sas_phy *sas_phys[MAX_PHYS]; + static struct sas_port *sas_ports[MAX_PHYS]; + + my_ha->sas_ha.sas_addr = &my_ha->sas_addr[0]; + + for (i = 0; i < MAX_PHYS; i++) { + sas_phys[i] = &my_ha->phys[i].sas_phy; + sas_ports[i] = &my_ha->sas_ports[i]; + } + + my_ha->sas_ha.sas_phy = sas_phys; + my_ha->sas_ha.sas_port = sas_ports; + my_ha->sas_ha.num_phys = MAX_PHYS; + + my_ha->sas_ha.lldd_port_formed = my_port_formed; + + my_ha->sas_ha.lldd_dev_found = my_dev_found; + my_ha->sas_ha.lldd_dev_gone = my_dev_gone; + + my_ha->sas_ha.lldd_execute_task = my_execute_task; + + my_ha->sas_ha.lldd_abort_task = my_abort_task; + my_ha->sas_ha.lldd_abort_task_set = my_abort_task_set; + my_ha->sas_ha.lldd_clear_aca = my_clear_aca; + my_ha->sas_ha.lldd_clear_task_set = my_clear_task_set; + my_ha->sas_ha.lldd_I_T_nexus_reset= NULL; (2) + my_ha->sas_ha.lldd_lu_reset = my_lu_reset; + my_ha->sas_ha.lldd_query_task = my_query_task; + + my_ha->sas_ha.lldd_clear_nexus_port = my_clear_nexus_port; + my_ha->sas_ha.lldd_clear_nexus_ha = my_clear_nexus_ha; + + my_ha->sas_ha.lldd_control_phy = my_control_phy; + + return sas_register_ha(&my_ha->sas_ha); + } + +(2) SAS 1.1 does not define I_T Nexus Reset TMF. + +Events +====== + +Events are **the only way** a SAS LLDD notifies the SAS layer +of anything. There is no other method or way a LLDD to tell +the SAS layer of anything happening internally or in the SAS +domain. + +Phy events:: + + PHYE_LOSS_OF_SIGNAL, (C) + PHYE_OOB_DONE, + PHYE_OOB_ERROR, (C) + PHYE_SPINUP_HOLD. + +Port events, passed on a _phy_:: + + PORTE_BYTES_DMAED, (M) + PORTE_BROADCAST_RCVD, (E) + PORTE_LINK_RESET_ERR, (C) + PORTE_TIMER_EVENT, (C) + PORTE_HARD_RESET. + +Host Adapter event: + HAE_RESET + +A SAS LLDD should be able to generate + + - at least one event from group C (choice), + - events marked M (mandatory) are mandatory (only one), + - events marked E (expander) if it wants the SAS layer + to handle domain revalidation (only one such). + - Unmarked events are optional. + +Meaning: + +HAE_RESET + - when your HA got internal error and was reset. + +PORTE_BYTES_DMAED + - on receiving an IDENTIFY/FIS frame + +PORTE_BROADCAST_RCVD + - on receiving a primitive + +PORTE_LINK_RESET_ERR + - timer expired, loss of signal, loss of DWS, etc. [1]_ + +PORTE_TIMER_EVENT + - DWS reset timeout timer expired [1]_ + +PORTE_HARD_RESET + - Hard Reset primitive received. + +PHYE_LOSS_OF_SIGNAL + - the device is gone [1]_ + +PHYE_OOB_DONE + - OOB went fine and oob_mode is valid + +PHYE_OOB_ERROR + - Error while doing OOB, the device probably + got disconnected. [1]_ + +PHYE_SPINUP_HOLD + - SATA is present, COMWAKE not sent. + +.. [1] should set/clear the appropriate fields in the phy, + or alternatively call the inlined sas_phy_disconnected() + which is just a helper, from their tasklet. + +The Execute Command SCSI RPC:: + + int (*lldd_execute_task)(struct sas_task *, gfp_t gfp_flags); + +Used to queue a task to the SAS LLDD. @task is the task to be executed. +@gfp_mask is the gfp_mask defining the context of the caller. + +This function should implement the Execute Command SCSI RPC, + +That is, when lldd_execute_task() is called, the command +go out on the transport *immediately*. There is *no* +queuing of any sort and at any level in a SAS LLDD. + +Returns: + + * -SAS_QUEUE_FULL, -ENOMEM, nothing was queued; + * 0, the task(s) were queued. + +:: + + struct sas_task { + dev -- the device this task is destined to + task_proto -- _one_ of enum sas_proto + scatter -- pointer to scatter gather list array + num_scatter -- number of elements in scatter + total_xfer_len -- total number of bytes expected to be transferred + data_dir -- PCI_DMA_... + task_done -- callback when the task has finished execution + }; + +Discovery +========= + +The sysfs tree has the following purposes: + + a) It shows you the physical layout of the SAS domain at + the current time, i.e. how the domain looks in the + physical world right now. + b) Shows some device parameters _at_discovery_time_. + +This is a link to the tree(1) program, very useful in +viewing the SAS domain: +ftp://mama.indstate.edu/linux/tree/ + +I expect user space applications to actually create a +graphical interface of this. + +That is, the sysfs domain tree doesn't show or keep state if +you e.g., change the meaning of the READY LED MEANING +setting, but it does show you the current connection status +of the domain device. + +Keeping internal device state changes is responsibility of +upper layers (Command set drivers) and user space. + +When a device or devices are unplugged from the domain, this +is reflected in the sysfs tree immediately, and the device(s) +removed from the system. + +The structure domain_device describes any device in the SAS +domain. It is completely managed by the SAS layer. A task +points to a domain device, this is how the SAS LLDD knows +where to send the task(s) to. A SAS LLDD only reads the +contents of the domain_device structure, but it never creates +or destroys one. + +Expander management from User Space +=================================== + +In each expander directory in sysfs, there is a file called +"smp_portal". It is a binary sysfs attribute file, which +implements an SMP portal (Note: this is *NOT* an SMP port), +to which user space applications can send SMP requests and +receive SMP responses. + +Functionality is deceptively simple: + +1. Build the SMP frame you want to send. The format and layout + is described in the SAS spec. Leave the CRC field equal 0. + +open(2) + +2. Open the expander's SMP portal sysfs file in RW mode. + +write(2) + +3. Write the frame you built in 1. + +read(2) + +4. Read the amount of data you expect to receive for the frame you built. + If you receive different amount of data you expected to receive, + then there was some kind of error. + +close(2) + +All this process is shown in detail in the function do_smp_func() +and its callers, in the file "expander_conf.c". + +The kernel functionality is implemented in the file +"sas_expander.c". + +The program "expander_conf.c" implements this. It takes one +argument, the sysfs file name of the SMP portal to the +expander, and gives expander information, including routing +tables. + +The SMP portal gives you complete control of the expander, +so please be careful. diff --git a/Documentation/scsi/libsas.txt b/Documentation/scsi/libsas.txt deleted file mode 100644 index 8cac6492aade..000000000000 --- a/Documentation/scsi/libsas.txt +++ /dev/null @@ -1,395 +0,0 @@ -SAS Layer ---------- - -The SAS Layer is a management infrastructure which manages -SAS LLDDs. It sits between SCSI Core and SAS LLDDs. The -layout is as follows: while SCSI Core is concerned with -SAM/SPC issues, and a SAS LLDD+sequencer is concerned with -phy/OOB/link management, the SAS layer is concerned with: - - * SAS Phy/Port/HA event management (LLDD generates, - SAS Layer processes), - * SAS Port management (creation/destruction), - * SAS Domain discovery and revalidation, - * SAS Domain device management, - * SCSI Host registration/unregistration, - * Device registration with SCSI Core (SAS) or libata - (SATA), and - * Expander management and exporting expander control - to user space. - -A SAS LLDD is a PCI device driver. It is concerned with -phy/OOB management, and vendor specific tasks and generates -events to the SAS layer. - -The SAS Layer does most SAS tasks as outlined in the SAS 1.1 -spec. - -The sas_ha_struct describes the SAS LLDD to the SAS layer. -Most of it is used by the SAS Layer but a few fields need to -be initialized by the LLDDs. - -After initializing your hardware, from the probe() function -you call sas_register_ha(). It will register your LLDD with -the SCSI subsystem, creating a SCSI host and it will -register your SAS driver with the sysfs SAS tree it creates. -It will then return. Then you enable your phys to actually -start OOB (at which point your driver will start calling the -notify_* event callbacks). - -Structure descriptions: - -struct sas_phy -------------------- -Normally this is statically embedded to your driver's -phy structure: - struct my_phy { - blah; - struct sas_phy sas_phy; - bleh; - }; -And then all the phys are an array of my_phy in your HA -struct (shown below). - -Then as you go along and initialize your phys you also -initialize the sas_phy struct, along with your own -phy structure. - -In general, the phys are managed by the LLDD and the ports -are managed by the SAS layer. So the phys are initialized -and updated by the LLDD and the ports are initialized and -updated by the SAS layer. - -There is a scheme where the LLDD can RW certain fields, -and the SAS layer can only read such ones, and vice versa. -The idea is to avoid unnecessary locking. - -enabled -- must be set (0/1) -id -- must be set [0,MAX_PHYS) -class, proto, type, role, oob_mode, linkrate -- must be set -oob_mode -- you set this when OOB has finished and then notify -the SAS Layer. - -sas_addr -- this normally points to an array holding the sas -address of the phy, possibly somewhere in your my_phy -struct. - -attached_sas_addr -- set this when you (LLDD) receive an -IDENTIFY frame or a FIS frame, _before_ notifying the SAS -layer. The idea is that sometimes the LLDD may want to fake -or provide a different SAS address on that phy/port and this -allows it to do this. At best you should copy the sas -address from the IDENTIFY frame or maybe generate a SAS -address for SATA directly attached devices. The Discover -process may later change this. - -frame_rcvd -- this is where you copy the IDENTIFY/FIS frame -when you get it; you lock, copy, set frame_rcvd_size and -unlock the lock, and then call the event. It is a pointer -since there's no way to know your hw frame size _exactly_, -so you define the actual array in your phy struct and let -this pointer point to it. You copy the frame from your -DMAable memory to that area holding the lock. - -sas_prim -- this is where primitives go when they're -received. See sas.h. Grab the lock, set the primitive, -release the lock, notify. - -port -- this points to the sas_port if the phy belongs -to a port -- the LLDD only reads this. It points to the -sas_port this phy is part of. Set by the SAS Layer. - -ha -- may be set; the SAS layer sets it anyway. - -lldd_phy -- you should set this to point to your phy so you -can find your way around faster when the SAS layer calls one -of your callbacks and passes you a phy. If the sas_phy is -embedded you can also use container_of -- whatever you -prefer. - - -struct sas_port -------------------- -The LLDD doesn't set any fields of this struct -- it only -reads them. They should be self explanatory. - -phy_mask is 32 bit, this should be enough for now, as I -haven't heard of a HA having more than 8 phys. - -lldd_port -- I haven't found use for that -- maybe other -LLDD who wish to have internal port representation can make -use of this. - - -struct sas_ha_struct -------------------- -It normally is statically declared in your own LLDD -structure describing your adapter: -struct my_sas_ha { - blah; - struct sas_ha_struct sas_ha; - struct my_phy phys[MAX_PHYS]; - struct sas_port sas_ports[MAX_PHYS]; /* (1) */ - bleh; -}; - -(1) If your LLDD doesn't have its own port representation. - -What needs to be initialized (sample function given below). - -pcidev -sas_addr -- since the SAS layer doesn't want to mess with - memory allocation, etc, this points to statically - allocated array somewhere (say in your host adapter - structure) and holds the SAS address of the host - adapter as given by you or the manufacturer, etc. -sas_port -sas_phy -- an array of pointers to structures. (see - note above on sas_addr). - These must be set. See more notes below. -num_phys -- the number of phys present in the sas_phy array, - and the number of ports present in the sas_port - array. There can be a maximum num_phys ports (one per - port) so we drop the num_ports, and only use - num_phys. - -The event interface: - - /* LLDD calls these to notify the class of an event. */ - void (*notify_ha_event)(struct sas_ha_struct *, enum ha_event); - void (*notify_port_event)(struct sas_phy *, enum port_event); - void (*notify_phy_event)(struct sas_phy *, enum phy_event); - -When sas_register_ha() returns, those are set and can be -called by the LLDD to notify the SAS layer of such events -the SAS layer. - -The port notification: - - /* The class calls these to notify the LLDD of an event. */ - void (*lldd_port_formed)(struct sas_phy *); - void (*lldd_port_deformed)(struct sas_phy *); - -If the LLDD wants notification when a port has been formed -or deformed it sets those to a function satisfying the type. - -A SAS LLDD should also implement at least one of the Task -Management Functions (TMFs) described in SAM: - - /* Task Management Functions. Must be called from process context. */ - int (*lldd_abort_task)(struct sas_task *); - int (*lldd_abort_task_set)(struct domain_device *, u8 *lun); - int (*lldd_clear_aca)(struct domain_device *, u8 *lun); - int (*lldd_clear_task_set)(struct domain_device *, u8 *lun); - int (*lldd_I_T_nexus_reset)(struct domain_device *); - int (*lldd_lu_reset)(struct domain_device *, u8 *lun); - int (*lldd_query_task)(struct sas_task *); - -For more information please read SAM from T10.org. - -Port and Adapter management: - - /* Port and Adapter management */ - int (*lldd_clear_nexus_port)(struct sas_port *); - int (*lldd_clear_nexus_ha)(struct sas_ha_struct *); - -A SAS LLDD should implement at least one of those. - -Phy management: - - /* Phy management */ - int (*lldd_control_phy)(struct sas_phy *, enum phy_func); - -lldd_ha -- set this to point to your HA struct. You can also -use container_of if you embedded it as shown above. - -A sample initialization and registration function -can look like this (called last thing from probe()) -*but* before you enable the phys to do OOB: - -static int register_sas_ha(struct my_sas_ha *my_ha) -{ - int i; - static struct sas_phy *sas_phys[MAX_PHYS]; - static struct sas_port *sas_ports[MAX_PHYS]; - - my_ha->sas_ha.sas_addr = &my_ha->sas_addr[0]; - - for (i = 0; i < MAX_PHYS; i++) { - sas_phys[i] = &my_ha->phys[i].sas_phy; - sas_ports[i] = &my_ha->sas_ports[i]; - } - - my_ha->sas_ha.sas_phy = sas_phys; - my_ha->sas_ha.sas_port = sas_ports; - my_ha->sas_ha.num_phys = MAX_PHYS; - - my_ha->sas_ha.lldd_port_formed = my_port_formed; - - my_ha->sas_ha.lldd_dev_found = my_dev_found; - my_ha->sas_ha.lldd_dev_gone = my_dev_gone; - - my_ha->sas_ha.lldd_execute_task = my_execute_task; - - my_ha->sas_ha.lldd_abort_task = my_abort_task; - my_ha->sas_ha.lldd_abort_task_set = my_abort_task_set; - my_ha->sas_ha.lldd_clear_aca = my_clear_aca; - my_ha->sas_ha.lldd_clear_task_set = my_clear_task_set; - my_ha->sas_ha.lldd_I_T_nexus_reset= NULL; (2) - my_ha->sas_ha.lldd_lu_reset = my_lu_reset; - my_ha->sas_ha.lldd_query_task = my_query_task; - - my_ha->sas_ha.lldd_clear_nexus_port = my_clear_nexus_port; - my_ha->sas_ha.lldd_clear_nexus_ha = my_clear_nexus_ha; - - my_ha->sas_ha.lldd_control_phy = my_control_phy; - - return sas_register_ha(&my_ha->sas_ha); -} - -(2) SAS 1.1 does not define I_T Nexus Reset TMF. - -Events ------- - -Events are _the only way_ a SAS LLDD notifies the SAS layer -of anything. There is no other method or way a LLDD to tell -the SAS layer of anything happening internally or in the SAS -domain. - -Phy events: - PHYE_LOSS_OF_SIGNAL, (C) - PHYE_OOB_DONE, - PHYE_OOB_ERROR, (C) - PHYE_SPINUP_HOLD. - -Port events, passed on a _phy_: - PORTE_BYTES_DMAED, (M) - PORTE_BROADCAST_RCVD, (E) - PORTE_LINK_RESET_ERR, (C) - PORTE_TIMER_EVENT, (C) - PORTE_HARD_RESET. - -Host Adapter event: - HAE_RESET - -A SAS LLDD should be able to generate - - at least one event from group C (choice), - - events marked M (mandatory) are mandatory (only one), - - events marked E (expander) if it wants the SAS layer - to handle domain revalidation (only one such). - - Unmarked events are optional. - -Meaning: - -HAE_RESET -- when your HA got internal error and was reset. - -PORTE_BYTES_DMAED -- on receiving an IDENTIFY/FIS frame -PORTE_BROADCAST_RCVD -- on receiving a primitive -PORTE_LINK_RESET_ERR -- timer expired, loss of signal, loss -of DWS, etc. (*) -PORTE_TIMER_EVENT -- DWS reset timeout timer expired (*) -PORTE_HARD_RESET -- Hard Reset primitive received. - -PHYE_LOSS_OF_SIGNAL -- the device is gone (*) -PHYE_OOB_DONE -- OOB went fine and oob_mode is valid -PHYE_OOB_ERROR -- Error while doing OOB, the device probably -got disconnected. (*) -PHYE_SPINUP_HOLD -- SATA is present, COMWAKE not sent. - -(*) should set/clear the appropriate fields in the phy, - or alternatively call the inlined sas_phy_disconnected() - which is just a helper, from their tasklet. - -The Execute Command SCSI RPC: - - int (*lldd_execute_task)(struct sas_task *, gfp_t gfp_flags); - -Used to queue a task to the SAS LLDD. @task is the task to be executed. -@gfp_mask is the gfp_mask defining the context of the caller. - -This function should implement the Execute Command SCSI RPC, - -That is, when lldd_execute_task() is called, the command -go out on the transport *immediately*. There is *no* -queuing of any sort and at any level in a SAS LLDD. - -Returns: -SAS_QUEUE_FULL, -ENOMEM, nothing was queued; - 0, the task(s) were queued. - -struct sas_task { - dev -- the device this task is destined to - task_proto -- _one_ of enum sas_proto - scatter -- pointer to scatter gather list array - num_scatter -- number of elements in scatter - total_xfer_len -- total number of bytes expected to be transferred - data_dir -- PCI_DMA_... - task_done -- callback when the task has finished execution -}; - -DISCOVERY ---------- - -The sysfs tree has the following purposes: - a) It shows you the physical layout of the SAS domain at - the current time, i.e. how the domain looks in the - physical world right now. - b) Shows some device parameters _at_discovery_time_. - -This is a link to the tree(1) program, very useful in -viewing the SAS domain: -ftp://mama.indstate.edu/linux/tree/ -I expect user space applications to actually create a -graphical interface of this. - -That is, the sysfs domain tree doesn't show or keep state if -you e.g., change the meaning of the READY LED MEANING -setting, but it does show you the current connection status -of the domain device. - -Keeping internal device state changes is responsibility of -upper layers (Command set drivers) and user space. - -When a device or devices are unplugged from the domain, this -is reflected in the sysfs tree immediately, and the device(s) -removed from the system. - -The structure domain_device describes any device in the SAS -domain. It is completely managed by the SAS layer. A task -points to a domain device, this is how the SAS LLDD knows -where to send the task(s) to. A SAS LLDD only reads the -contents of the domain_device structure, but it never creates -or destroys one. - -Expander management from User Space ------------------------------------ - -In each expander directory in sysfs, there is a file called -"smp_portal". It is a binary sysfs attribute file, which -implements an SMP portal (Note: this is *NOT* an SMP port), -to which user space applications can send SMP requests and -receive SMP responses. - -Functionality is deceptively simple: - -1. Build the SMP frame you want to send. The format and layout - is described in the SAS spec. Leave the CRC field equal 0. -open(2) -2. Open the expander's SMP portal sysfs file in RW mode. -write(2) -3. Write the frame you built in 1. -read(2) -4. Read the amount of data you expect to receive for the frame you built. - If you receive different amount of data you expected to receive, - then there was some kind of error. -close(2) -All this process is shown in detail in the function do_smp_func() -and its callers, in the file "expander_conf.c". - -The kernel functionality is implemented in the file -"sas_expander.c". - -The program "expander_conf.c" implements this. It takes one -argument, the sysfs file name of the SMP portal to the -expander, and gives expander information, including routing -tables. - -The SMP portal gives you complete control of the expander, -so please be careful. -- cgit v1.2.3 From cbbc70a8cde7edb427b6cf00b3bc0f86181e2b4d Mon Sep 17 00:00:00 2001 From: Mauro Carvalho Chehab Date: Mon, 2 Mar 2020 09:15:53 +0100 Subject: scsi: docs: convert link_power_management_policy.txt to ReST Link: https://lore.kernel.org/r/c56177fdf046d80e0dec6031c4139cb4e8c39d31.1583136624.git.mchehab+huawei@kernel.org Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Martin K. Petersen --- Documentation/scsi/index.rst | 1 + .../scsi/link_power_management_policy.rst | 25 ++++++++++++++++++++++ .../scsi/link_power_management_policy.txt | 19 ---------------- 3 files changed, 26 insertions(+), 19 deletions(-) create mode 100644 Documentation/scsi/link_power_management_policy.rst delete mode 100644 Documentation/scsi/link_power_management_policy.txt (limited to 'Documentation/scsi') diff --git a/Documentation/scsi/index.rst b/Documentation/scsi/index.rst index e6850c0a1378..c40050ac3b32 100644 --- a/Documentation/scsi/index.rst +++ b/Documentation/scsi/index.rst @@ -24,5 +24,6 @@ Linux SCSI Subsystem hpsa hptiop libsas + link_power_management_policy scsi_transport_srp/figures diff --git a/Documentation/scsi/link_power_management_policy.rst b/Documentation/scsi/link_power_management_policy.rst new file mode 100644 index 000000000000..64288dcf10f6 --- /dev/null +++ b/Documentation/scsi/link_power_management_policy.rst @@ -0,0 +1,25 @@ +.. SPDX-License-Identifier: GPL-2.0 + +========================== +Link Power Managent Policy +========================== + +This parameter allows the user to set the link (interface) power management. +There are 3 possible options: + +===================== ===================================================== +Value Effect +===================== ===================================================== +min_power Tell the controller to try to make the link use the + least possible power when possible. This may + sacrifice some performance due to increased latency + when coming out of lower power states. + +max_performance Generally, this means no power management. Tell + the controller to have performance be a priority + over power management. + +medium_power Tell the controller to enter a lower power state + when possible, but do not enter the lowest power + state, thus improving latency over min_power setting. +===================== ===================================================== diff --git a/Documentation/scsi/link_power_management_policy.txt b/Documentation/scsi/link_power_management_policy.txt deleted file mode 100644 index d18993d01884..000000000000 --- a/Documentation/scsi/link_power_management_policy.txt +++ /dev/null @@ -1,19 +0,0 @@ -This parameter allows the user to set the link (interface) power management. -There are 3 possible options: - -Value Effect ----------------------------------------------------------------------------- -min_power Tell the controller to try to make the link use the - least possible power when possible. This may - sacrifice some performance due to increased latency - when coming out of lower power states. - -max_performance Generally, this means no power management. Tell - the controller to have performance be a priority - over power management. - -medium_power Tell the controller to enter a lower power state - when possible, but do not enter the lowest power - state, thus improving latency over min_power setting. - - -- cgit v1.2.3 From b4adb7578169ea810d2c3d9b2f3ad1aebef96886 Mon Sep 17 00:00:00 2001 From: Mauro Carvalho Chehab Date: Mon, 2 Mar 2020 09:15:54 +0100 Subject: scsi: docs: convert lpfc.txt to ReST Link: https://lore.kernel.org/r/48c13184b77ba61ed4fd7c235816fdb8e7530664.1583136624.git.mchehab+huawei@kernel.org Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Martin K. Petersen --- Documentation/scsi/index.rst | 1 + Documentation/scsi/lpfc.rst | 81 ++++++++++++++++++++++++++++++++++++++++++ Documentation/scsi/lpfc.txt | 83 -------------------------------------------- 3 files changed, 82 insertions(+), 83 deletions(-) create mode 100644 Documentation/scsi/lpfc.rst delete mode 100644 Documentation/scsi/lpfc.txt (limited to 'Documentation/scsi') diff --git a/Documentation/scsi/index.rst b/Documentation/scsi/index.rst index c40050ac3b32..22427511e227 100644 --- a/Documentation/scsi/index.rst +++ b/Documentation/scsi/index.rst @@ -25,5 +25,6 @@ Linux SCSI Subsystem hptiop libsas link_power_management_policy + lpfc scsi_transport_srp/figures diff --git a/Documentation/scsi/lpfc.rst b/Documentation/scsi/lpfc.rst new file mode 100644 index 000000000000..6e217e82b9b9 --- /dev/null +++ b/Documentation/scsi/lpfc.rst @@ -0,0 +1,81 @@ +.. SPDX-License-Identifier: GPL-2.0 + +========================= +LPFC Driver Release Notes +========================= + + +.. important:: + + Starting in the 8.0.17 release, the driver began to be targeted strictly + toward the upstream kernel. As such, we removed #ifdefs for older kernels + (pre 2.6.10). The 8.0.16 release should be used if the driver is to be + run on one of the older kernels. + + The proposed modifications to the transport layer for FC remote ports + and extended attribute support is now part of the upstream kernel + as of 2.6.12. We no longer need to provide patches for this support, + nor a *full* version which has old an new kernel support. + + The driver now requires a 2.6.12 (if pre-release, 2.6.12-rc1) or later + kernel. + + Please heed these dependencies.... + + +The following information is provided for additional background on the +history of the driver as we push for upstream acceptance. + +Cable pull and temporary device Loss: + + In older revisions of the lpfc driver, the driver internally queued i/o + received from the midlayer. In the cases where a cable was pulled, link + jitter, or a device temporarily loses connectivity (due to its cable + being removed, a switch rebooting, or a device reboot), the driver could + hide the disappearance of the device from the midlayer. I/O's issued to + the LLDD would simply be queued for a short duration, allowing the device + to reappear or link come back alive, with no inadvertent side effects + to the system. If the driver did not hide these conditions, i/o would be + errored by the driver, the mid-layer would exhaust its retries, and the + device would be taken offline. Manual intervention would be required to + re-enable the device. + + The community supporting kernel.org has driven an effort to remove + internal queuing from all LLDDs. The philosophy is that internal + queuing is unnecessary as the block layer already performs the + queuing. Removing the queues from the LLDD makes a more predictable + and more simple LLDD. + + As a potential new addition to kernel.org, the 8.x driver was asked to + have all internal queuing removed. Emulex complied with this request. + In explaining the impacts of this change, Emulex has worked with the + community in modifying the behavior of the SCSI midlayer so that SCSI + devices can be temporarily suspended while transport events (such as + those described) can occur. + + The proposed patch was posted to the linux-scsi mailing list. The patch + is contained in the 2.6.10-rc2 (and later) patch kits. As such, this + patch is part of the standard 2.6.10 kernel. + + By default, the driver expects the patches for block/unblock interfaces + to be present in the kernel. No #define needs to be set to enable support. + + +Kernel Support +============== + + This source package is targeted for the upstream kernel only. (See notes + at the top of this file). It relies on interfaces that are slowing + migrating into the kernel.org kernel. + + At this time, the driver requires the 2.6.12 (if pre-release, 2.6.12-rc1) + kernel. + + If a driver is needed for older kernels please utilize the 8.0.16 + driver sources. + + +Patches +======= + + Thankfully, at this time, patches are not needed. diff --git a/Documentation/scsi/lpfc.txt b/Documentation/scsi/lpfc.txt deleted file mode 100644 index 5741ea8aa88a..000000000000 --- a/Documentation/scsi/lpfc.txt +++ /dev/null @@ -1,83 +0,0 @@ - -LPFC Driver Release Notes: - -============================================================================= - - - IMPORTANT: - - Starting in the 8.0.17 release, the driver began to be targeted strictly - toward the upstream kernel. As such, we removed #ifdefs for older kernels - (pre 2.6.10). The 8.0.16 release should be used if the driver is to be - run on one of the older kernels. - - The proposed modifications to the transport layer for FC remote ports - and extended attribute support is now part of the upstream kernel - as of 2.6.12. We no longer need to provide patches for this support, - nor a *full* version which has old an new kernel support. - - The driver now requires a 2.6.12 (if pre-release, 2.6.12-rc1) or later - kernel. - - Please heed these dependencies.... - - - ******************************************************************** - - -The following information is provided for additional background on the -history of the driver as we push for upstream acceptance. - -Cable pull and temporary device Loss: - - In older revisions of the lpfc driver, the driver internally queued i/o - received from the midlayer. In the cases where a cable was pulled, link - jitter, or a device temporarily loses connectivity (due to its cable - being removed, a switch rebooting, or a device reboot), the driver could - hide the disappearance of the device from the midlayer. I/O's issued to - the LLDD would simply be queued for a short duration, allowing the device - to reappear or link come back alive, with no inadvertent side effects - to the system. If the driver did not hide these conditions, i/o would be - errored by the driver, the mid-layer would exhaust its retries, and the - device would be taken offline. Manual intervention would be required to - re-enable the device. - - The community supporting kernel.org has driven an effort to remove - internal queuing from all LLDDs. The philosophy is that internal - queuing is unnecessary as the block layer already performs the - queuing. Removing the queues from the LLDD makes a more predictable - and more simple LLDD. - - As a potential new addition to kernel.org, the 8.x driver was asked to - have all internal queuing removed. Emulex complied with this request. - In explaining the impacts of this change, Emulex has worked with the - community in modifying the behavior of the SCSI midlayer so that SCSI - devices can be temporarily suspended while transport events (such as - those described) can occur. - - The proposed patch was posted to the linux-scsi mailing list. The patch - is contained in the 2.6.10-rc2 (and later) patch kits. As such, this - patch is part of the standard 2.6.10 kernel. - - By default, the driver expects the patches for block/unblock interfaces - to be present in the kernel. No #define needs to be set to enable support. - - -Kernel Support - - This source package is targeted for the upstream kernel only. (See notes - at the top of this file). It relies on interfaces that are slowing - migrating into the kernel.org kernel. - - At this time, the driver requires the 2.6.12 (if pre-release, 2.6.12-rc1) - kernel. - - If a driver is needed for older kernels please utilize the 8.0.16 - driver sources. - - -Patches - - Thankfully, at this time, patches are not needed. - - -- cgit v1.2.3 From a756185de6792278bb5c7d286c9a6fa22722b319 Mon Sep 17 00:00:00 2001 From: Mauro Carvalho Chehab Date: Mon, 2 Mar 2020 09:15:55 +0100 Subject: scsi: docs: convert megaraid.txt to ReST Link: https://lore.kernel.org/r/b7ee59230c5a33ff6d60edba0d0bcf3e2aeaa88f.1583136624.git.mchehab+huawei@kernel.org Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Martin K. Petersen --- Documentation/scsi/index.rst | 1 + Documentation/scsi/megaraid.rst | 77 +++++++++++++++++++++++++++++++++++++++++ Documentation/scsi/megaraid.txt | 70 ------------------------------------- 3 files changed, 78 insertions(+), 70 deletions(-) create mode 100644 Documentation/scsi/megaraid.rst delete mode 100644 Documentation/scsi/megaraid.txt (limited to 'Documentation/scsi') diff --git a/Documentation/scsi/index.rst b/Documentation/scsi/index.rst index 22427511e227..37be1fc9d128 100644 --- a/Documentation/scsi/index.rst +++ b/Documentation/scsi/index.rst @@ -26,5 +26,6 @@ Linux SCSI Subsystem libsas link_power_management_policy lpfc + megaraid scsi_transport_srp/figures diff --git a/Documentation/scsi/megaraid.rst b/Documentation/scsi/megaraid.rst new file mode 100644 index 000000000000..22b75a86ba72 --- /dev/null +++ b/Documentation/scsi/megaraid.rst @@ -0,0 +1,77 @@ +.. SPDX-License-Identifier: GPL-2.0 + +========================== +Notes on Management Module +========================== + +Overview +-------- + +Different classes of controllers from LSI Logic accept and respond to the +user applications in a similar way. They understand the same firmware control +commands. Furthermore, the applications also can treat different classes of +the controllers uniformly. Hence it is logical to have a single module that +interfaces with the applications on one side and all the low level drivers +on the other. + +The advantages, though obvious, are listed for completeness: + + i. Avoid duplicate code from the low level drivers. + ii. Unburden the low level drivers from having to export the + character node device and related handling. + iii. Implement any policy mechanisms in one place. + iv. Applications have to interface with only module instead of + multiple low level drivers. + +Currently this module (called Common Management Module) is used only to issue +ioctl commands. But this module is envisioned to handle all user space level +interactions. So any 'proc', 'sysfs' implementations will be localized in this +common module. + +Credits +------- + +:: + + "Shared code in a third module, a "library module", is an acceptable + solution. modprobe automatically loads dependent modules, so users + running "modprobe driver1" or "modprobe driver2" would automatically + load the shared library module." + +- Jeff Garzik (jgarzik@pobox.com), 02.25.2004 LKML + +:: + + "As Jeff hinted, if your userspace<->driver API is consistent between + your new MPT-based RAID controllers and your existing megaraid driver, + then perhaps you need a single small helper module (lsiioctl or some + better name), loaded by both mptraid and megaraid automatically, which + handles registering the /dev/megaraid node dynamically. In this case, + both mptraid and megaraid would register with lsiioctl for each + adapter discovered, and lsiioctl would essentially be a switch, + redirecting userspace tool ioctls to the appropriate driver." + +- Matt Domsch, (Matt_Domsch@dell.com), 02.25.2004 LKML + +Design +------ + +The Common Management Module is implemented in megaraid_mm.[ch] files. This +module acts as a registry for low level hba drivers. The low level drivers +(currently only megaraid) register each controller with the common module. + +The applications interface with the common module via the character device +node exported by the module. + +The lower level drivers now understand only a new improved ioctl packet called +uioc_t. The management module converts the older ioctl packets from the older +applications into uioc_t. After driver handles the uioc_t, the common module +will convert that back into the old format before returning to applications. + +As new applications evolve and replace the old ones, the old packet format +will be retired. + +Common module dedicates one uioc_t packet to each controller registered. This +can easily be more than one. But since megaraid is the only low level driver +today, and it can handle only one ioctl, there is no reason to have more. But +as new controller classes get added, this will be tuned appropriately. diff --git a/Documentation/scsi/megaraid.txt b/Documentation/scsi/megaraid.txt deleted file mode 100644 index 3c7cea51e687..000000000000 --- a/Documentation/scsi/megaraid.txt +++ /dev/null @@ -1,70 +0,0 @@ - Notes on Management Module - ~~~~~~~~~~~~~~~~~~~~~~~~~~ - -Overview: --------- - -Different classes of controllers from LSI Logic accept and respond to the -user applications in a similar way. They understand the same firmware control -commands. Furthermore, the applications also can treat different classes of -the controllers uniformly. Hence it is logical to have a single module that -interfaces with the applications on one side and all the low level drivers -on the other. - -The advantages, though obvious, are listed for completeness: - - i. Avoid duplicate code from the low level drivers. - ii. Unburden the low level drivers from having to export the - character node device and related handling. - iii. Implement any policy mechanisms in one place. - iv. Applications have to interface with only module instead of - multiple low level drivers. - -Currently this module (called Common Management Module) is used only to issue -ioctl commands. But this module is envisioned to handle all user space level -interactions. So any 'proc', 'sysfs' implementations will be localized in this -common module. - -Credits: -------- - -"Shared code in a third module, a "library module", is an acceptable -solution. modprobe automatically loads dependent modules, so users -running "modprobe driver1" or "modprobe driver2" would automatically -load the shared library module." - - - Jeff Garzik (jgarzik@pobox.com), 02.25.2004 LKML - -"As Jeff hinted, if your userspace<->driver API is consistent between -your new MPT-based RAID controllers and your existing megaraid driver, -then perhaps you need a single small helper module (lsiioctl or some -better name), loaded by both mptraid and megaraid automatically, which -handles registering the /dev/megaraid node dynamically. In this case, -both mptraid and megaraid would register with lsiioctl for each -adapter discovered, and lsiioctl would essentially be a switch, -redirecting userspace tool ioctls to the appropriate driver." - - - Matt Domsch, (Matt_Domsch@dell.com), 02.25.2004 LKML - -Design: ------- - -The Common Management Module is implemented in megaraid_mm.[ch] files. This -module acts as a registry for low level hba drivers. The low level drivers -(currently only megaraid) register each controller with the common module. - -The applications interface with the common module via the character device -node exported by the module. - -The lower level drivers now understand only a new improved ioctl packet called -uioc_t. The management module converts the older ioctl packets from the older -applications into uioc_t. After driver handles the uioc_t, the common module -will convert that back into the old format before returning to applications. - -As new applications evolve and replace the old ones, the old packet format -will be retired. - -Common module dedicates one uioc_t packet to each controller registered. This -can easily be more than one. But since megaraid is the only low level driver -today, and it can handle only one ioctl, there is no reason to have more. But -as new controller classes get added, this will be tuned appropriately. -- cgit v1.2.3 From 8dca37d259dff2371d414c51b72b5730e3c1ed01 Mon Sep 17 00:00:00 2001 From: Mauro Carvalho Chehab Date: Mon, 2 Mar 2020 09:15:56 +0100 Subject: scsi: docs: convert ncr53c8xx.txt to ReST Link: https://lore.kernel.org/r/cover.1583136624.git.mchehab+huawei@kernel.org Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Martin K. Petersen --- Documentation/scsi/index.rst | 1 + Documentation/scsi/ncr53c8xx.rst | 2169 ++++++++++++++++++++++++++++++++++++++ Documentation/scsi/ncr53c8xx.txt | 1824 -------------------------------- 3 files changed, 2170 insertions(+), 1824 deletions(-) create mode 100644 Documentation/scsi/ncr53c8xx.rst delete mode 100644 Documentation/scsi/ncr53c8xx.txt (limited to 'Documentation/scsi') diff --git a/Documentation/scsi/index.rst b/Documentation/scsi/index.rst index 37be1fc9d128..a2545efbb407 100644 --- a/Documentation/scsi/index.rst +++ b/Documentation/scsi/index.rst @@ -27,5 +27,6 @@ Linux SCSI Subsystem link_power_management_policy lpfc megaraid + ncr53c8xx scsi_transport_srp/figures diff --git a/Documentation/scsi/ncr53c8xx.rst b/Documentation/scsi/ncr53c8xx.rst new file mode 100644 index 000000000000..c41cec99f07c --- /dev/null +++ b/Documentation/scsi/ncr53c8xx.rst @@ -0,0 +1,2169 @@ +.. SPDX-License-Identifier: GPL-2.0 + +================================================= +The Linux NCR53C8XX/SYM53C8XX drivers README file +================================================= + +Written by Gerard Roudier + +21 Rue Carnot + +95170 DEUIL LA BARRE - FRANCE + +29 May 1999 + +.. Contents: + + 1. Introduction + 2. Supported chips and SCSI features + 3. Advantages of the enhanced 896 driver + 3.1 Optimized SCSI SCRIPTS + 3.2 New features of the SYM53C896 (64 bit PCI dual LVD SCSI controller) + 4. Memory mapped I/O versus normal I/O + 5. Tagged command queueing + 6. Parity checking + 7. Profiling information + 8. Control commands + 8.1 Set minimum synchronous period + 8.2 Set wide size + 8.3 Set maximum number of concurrent tagged commands + 8.4 Set order type for tagged command + 8.5 Set debug mode + 8.6 Clear profile counters + 8.7 Set flag (no_disc) + 8.8 Set verbose level + 8.9 Reset all logical units of a target + 8.10 Abort all tasks of all logical units of a target + 9. Configuration parameters + 10. Boot setup commands + 10.1 Syntax + 10.2 Available arguments + 10.2.1 Master parity checking + 10.2.2 Scsi parity checking + 10.2.3 Scsi disconnections + 10.2.4 Special features + 10.2.5 Ultra SCSI support + 10.2.6 Default number of tagged commands + 10.2.7 Default synchronous period factor + 10.2.8 Negotiate synchronous with all devices + 10.2.9 Verbosity level + 10.2.10 Debug mode + 10.2.11 Burst max + 10.2.12 LED support + 10.2.13 Max wide + 10.2.14 Differential mode + 10.2.15 IRQ mode + 10.2.16 Reverse probe + 10.2.17 Fix up PCI configuration space + 10.2.18 Serial NVRAM + 10.2.19 Check SCSI BUS + 10.2.20 Exclude a host from being attached + 10.2.21 Suggest a default SCSI id for hosts + 10.2.22 Enable use of IMMEDIATE ARBITRATION + 10.3 Advised boot setup commands + 10.4 PCI configuration fix-up boot option + 10.5 Serial NVRAM support boot option + 10.6 SCSI BUS checking boot option + 10.7 IMMEDIATE ARBITRATION boot option + 11. Some constants and flags of the ncr53c8xx.h header file + 12. Installation + 13. Architecture dependent features + 14. Known problems + 14.1 Tagged commands with Iomega Jaz device + 14.2 Device names change when another controller is added + 14.3 Using only 8 bit devices with a WIDE SCSI controller. + 14.4 Possible data corruption during a Memory Write and Invalidate + 14.5 IRQ sharing problems + 15. SCSI problem troubleshooting + 15.1 Problem tracking + 15.2 Understanding hardware error reports + 16. Synchronous transfer negotiation tables + 16.1 Synchronous timings for 53C875 and 53C860 Ultra-SCSI controllers + 16.2 Synchronous timings for fast SCSI-2 53C8XX controllers + 17. Serial NVRAM support (by Richard Waltham) + 17.1 Features + 17.2 Symbios NVRAM layout + 17.3 Tekram NVRAM layout + 18. Support for Big Endian + 18.1 Big Endian CPU + 18.2 NCR chip in Big Endian mode of operations + +1. Introduction +=============== + +The initial Linux ncr53c8xx driver has been a port of the ncr driver from +FreeBSD that has been achieved in November 1995 by: + + - Gerard Roudier + +The original driver has been written for 386bsd and FreeBSD by: + + - Wolfgang Stanglmeier + - Stefan Esser + +It is now available as a bundle of 2 drivers: + +- ncr53c8xx generic driver that supports all the SYM53C8XX family including + the earliest 810 rev. 1, the latest 896 (2 channel LVD SCSI controller) and + the new 895A (1 channel LVD SCSI controller). +- sym53c8xx enhanced driver (a.k.a. 896 drivers) that drops support of oldest + chips in order to gain advantage of new features, as LOAD/STORE instructions + available since the 810A and hardware phase mismatch available with the + 896 and the 895A. + +You can find technical information about the NCR 8xx family in the +PCI-HOWTO written by Michael Will and in the SCSI-HOWTO written by +Drew Eckhardt. + +Information about new chips is available at LSILOGIC web server: + + - http://www.lsilogic.com/ + +SCSI standard documentations are available at SYMBIOS ftp server: + + - ftp://ftp.symbios.com/ + +Useful SCSI tools written by Eric Youngdale are available at tsx-11: + + - ftp://tsx-11.mit.edu/pub/linux/ALPHA/scsi/scsiinfo-X.Y.tar.gz + - ftp://tsx-11.mit.edu/pub/linux/ALPHA/scsi/scsidev-X.Y.tar.gz + +These tools are not ALPHA but quite clean and work quite well. +It is essential you have the 'scsiinfo' package. + +This short documentation describes the features of the generic and enhanced +drivers, configuration parameters and control commands available through +the proc SCSI file system read / write operations. + +This driver has been tested OK with linux/i386, Linux/Alpha and Linux/PPC. + +Latest driver version and patches are available at: + + - ftp://ftp.tux.org/pub/people/gerard-roudier + +or + + - ftp://ftp.symbios.com/mirror/ftp.tux.org/pub/tux/roudier/drivers + +I am not a native speaker of English and there are probably lots of +mistakes in this README file. Any help will be welcome. + + +2. Supported chips and SCSI features +==================================== + +The following features are supported for all chips: + + - Synchronous negotiation + - Disconnection + - Tagged command queuing + - SCSI parity checking + - Master parity checking + +"Wide negotiation" is supported for chips that allow it. The +following table shows some characteristics of NCR 8xx family chips +and what drivers support them. + ++--------+-----------+-----+-----------+------------+------------+------------+ +| | | | | |Supported by|Supported by| +| |On board | | | |the generic |the enhanced| +|Chip |SDMS BIOS |Wide |SCSI std. | Max. sync |driver |driver | ++--------+-----------+-----+-----------+------------+------------+------------+ +|810 | N | N | FAST10 | 10 MB/s | Y | N | ++--------+-----------+-----+-----------+------------+------------+------------+ +|810A | N | N | FAST10 | 10 MB/s | Y | Y | ++--------+-----------+-----+-----------+------------+------------+------------+ +|815 | Y | N | FAST10 | 10 MB/s | Y | N | ++--------+-----------+-----+-----------+------------+------------+------------+ +|825 | Y | Y | FAST10 | 20 MB/s | Y | N | ++--------+-----------+-----+-----------+------------+------------+------------+ +|825A | Y | Y | FAST10 | 20 MB/s | Y | Y | ++--------+-----------+-----+-----------+------------+------------+------------+ +|860 | N | N | FAST20 | 20 MB/s | Y | Y | ++--------+-----------+-----+-----------+------------+------------+------------+ +|875 | Y | Y | FAST20 | 40 MB/s | Y | Y | ++--------+-----------+-----+-----------+------------+------------+------------+ +|876 | Y | Y | FAST20 | 40 MB/s | Y | Y | ++--------+-----------+-----+-----------+------------+------------+------------+ +|895 | Y | Y | FAST40 | 80 MB/s | Y | Y | ++--------+-----------+-----+-----------+------------+------------+------------+ +|895A | Y | Y | FAST40 | 80 MB/s | Y | Y | ++--------+-----------+-----+-----------+------------+------------+------------+ +|896 | Y | Y | FAST40 | 80 MB/s | Y | Y | ++--------+-----------+-----+-----------+------------+------------+------------+ +|897 | Y | Y | FAST40 | 80 MB/s | Y | Y | ++--------+-----------+-----+-----------+------------+------------+------------+ +|1510D | Y | Y | FAST40 | 80 MB/s | Y | Y | ++--------+-----------+-----+-----------+------------+------------+------------+ +|1010 | Y | Y | FAST80 |160 MB/s | N | Y | ++--------+-----------+-----+-----------+------------+------------+------------+ +|1010_66 | Y | Y | FAST80 |160 MB/s | N | Y | +|[1]_ | | | | | | | ++--------+-----------+-----+-----------+------------+------------+------------+ + +.. [1] Chip supports 33MHz and 66MHz PCI buses. + + +Summary of other supported features: + +:Module: allow to load the driver +:Memory mapped I/O: increases performance +:Profiling information: read operations from the proc SCSI file system +:Control commands: write operations to the proc SCSI file system +:Debugging information: written to syslog (expert only) +:Serial NVRAM: Symbios and Tekram formats + +- Scatter / gather +- Shared interrupt +- Boot setup commands + + +3. Advantages of the enhanced 896 driver +======================================== + +3.1 Optimized SCSI SCRIPTS +-------------------------- + +The 810A, 825A, 875, 895, 896 and 895A support new SCSI SCRIPTS instructions +named LOAD and STORE that allow to move up to 1 DWORD from/to an IO register +to/from memory much faster that the MOVE MEMORY instruction that is supported +by the 53c7xx and 53c8xx family. +The LOAD/STORE instructions support absolute and DSA relative addressing +modes. The SCSI SCRIPTS had been entirely rewritten using LOAD/STORE instead +of MOVE MEMORY instructions. + +3.2 New features of the SYM53C896 (64 bit PCI dual LVD SCSI controller) +----------------------------------------------------------------------- + +The 896 and the 895A allows handling of the phase mismatch context from +SCRIPTS (avoids the phase mismatch interrupt that stops the SCSI processor +until the C code has saved the context of the transfer). +Implementing this without using LOAD/STORE instructions would be painful +and I didn't even want to try it. + +The 896 chip supports 64 bit PCI transactions and addressing, while the +895A supports 32 bit PCI transactions and 64 bit addressing. +The SCRIPTS processor of these chips is not true 64 bit, but uses segment +registers for bit 32-63. Another interesting feature is that LOAD/STORE +instructions that address the on-chip RAM (8k) remain internal to the chip. + +Due to the use of LOAD/STORE SCRIPTS instructions, this driver does not +support the following chips: + +- SYM53C810 revision < 0x10 (16) +- SYM53C815 all revisions +- SYM53C825 revision < 0x10 (16) + +4. Memory mapped I/O versus normal I/O +====================================== + +Memory mapped I/O has less latency than normal I/O. Since +linux-1.3.x, memory mapped I/O is used rather than normal I/O. Memory +mapped I/O seems to work fine on most hardware configurations, but +some poorly designed motherboards may break this feature. + +The configuration option CONFIG_SCSI_NCR53C8XX_IOMAPPED forces the +driver to use normal I/O in all cases. + + +5. Tagged command queueing +========================== + +Queuing more than 1 command at a time to a device allows it to perform +optimizations based on actual head positions and its mechanical +characteristics. This feature may also reduce average command latency. +In order to really gain advantage of this feature, devices must have +a reasonable cache size (No miracle is to be expected for a low-end +hard disk with 128 KB or less). +Some known SCSI devices do not properly support tagged command queuing. +Generally, firmware revisions that fix this kind of problems are available +at respective vendor web/ftp sites. +All I can say is that the hard disks I use on my machines behave well with +this driver with tagged command queuing enabled: + +- IBM S12 0662 +- Conner 1080S +- Quantum Atlas I +- Quantum Atlas II + +If your controller has NVRAM, you can configure this feature per target +from the user setup tool. The Tekram Setup program allows to tune the +maximum number of queued commands up to 32. The Symbios Setup only allows +to enable or disable this feature. + +The maximum number of simultaneous tagged commands queued to a device +is currently set to 8 by default. This value is suitable for most SCSI +disks. With large SCSI disks (>= 2GB, cache >= 512KB, average seek time +<= 10 ms), using a larger value may give better performances. + +The sym53c8xx driver supports up to 255 commands per device, and the +generic ncr53c8xx driver supports up to 64, but using more than 32 is +generally not worth-while, unless you are using a very large disk or disk +array. It is noticeable that most of recent hard disks seem not to accept +more than 64 simultaneous commands. So, using more than 64 queued commands +is probably just resource wasting. + +If your controller does not have NVRAM or if it is managed by the SDMS +BIOS/SETUP, you can configure tagged queueing feature and device queue +depths from the boot command-line. For example:: + + ncr53c8xx=tags:4/t2t3q15-t4q7/t1u0q32 + +will set tagged commands queue depths as follow: + +- target 2 all luns on controller 0 --> 15 +- target 3 all luns on controller 0 --> 15 +- target 4 all luns on controller 0 --> 7 +- target 1 lun 0 on controller 1 --> 32 +- all other target/lun --> 4 + +In some special conditions, some SCSI disk firmwares may return a +QUEUE FULL status for a SCSI command. This behaviour is managed by the +driver using the following heuristic: + +- Each time a QUEUE FULL status is returned, tagged queue depth is reduced + to the actual number of disconnected commands. + +- Every 1000 successfully completed SCSI commands, if allowed by the + current limit, the maximum number of queueable commands is incremented. + +Since QUEUE FULL status reception and handling is resource wasting, the +driver notifies by default this problem to user by indicating the actual +number of commands used and their status, as well as its decision on the +device queue depth change. +The heuristic used by the driver in handling QUEUE FULL ensures that the +impact on performances is not too bad. You can get rid of the messages by +setting verbose level to zero, as follow: + +1st method: + boot your system using 'ncr53c8xx=verb:0' option. + +2nd method: + apply "setverbose 0" control command to the proc fs entry + corresponding to your controller after boot-up. + +6. Parity checking +================== + +The driver supports SCSI parity checking and PCI bus master parity +checking. These features must be enabled in order to ensure safe data +transfers. However, some flawed devices or mother boards will have +problems with parity. You can disable either PCI parity or SCSI parity +checking by entering appropriate options from the boot command line. +(See 10: Boot setup commands). + +7. Profiling information +======================== + +Profiling information is available through the proc SCSI file system. +Since gathering profiling information may impact performances, this +feature is disabled by default and requires a compilation configuration +option to be set to Y. + +The device associated with a host has the following pathname:: + + /proc/scsi/ncr53c8xx/N (N=0,1,2 ....) + +Generally, only 1 board is used on hardware configuration, and that device is:: + + /proc/scsi/ncr53c8xx/0 + +However, if the driver has been made as module, the number of the +hosts is incremented each time the driver is loaded. + +In order to display profiling information, just enter:: + + cat /proc/scsi/ncr53c8xx/0 + +and you will get something like the following text:: + + General information: + Chip NCR53C810, device id 0x1, revision id 0x2 + IO port address 0x6000, IRQ number 10 + Using memory mapped IO at virtual address 0x282c000 + Synchronous transfer period 25, max commands per lun 4 + Profiling information: + num_trans = 18014 + num_kbytes = 671314 + num_disc = 25763 + num_break = 1673 + num_int = 1685 + num_fly = 18038 + ms_setup = 4940 + ms_data = 369940 + ms_disc = 183090 + ms_post = 1320 + +General information is easy to understand. The device ID and the +revision ID identify the SCSI chip as follows: + +======= ============= =========== +Chip Device id Revision Id +======= ============= =========== +810 0x1 < 0x10 +810A 0x1 >= 0x10 +815 0x4 +825 0x3 < 0x10 +860 0x6 +825A 0x3 >= 0x10 +875 0xf +895 0xc +======= ============= =========== + +The profiling information is updated upon completion of SCSI commands. +A data structure is allocated and zeroed when the host adapter is +attached. So, if the driver is a module, the profile counters are +cleared each time the driver is loaded. The "clearprof" command +allows you to clear these counters at any time. + +The following counters are available: + +("num" prefix means "number of", +"ms" means milli-seconds) + +num_trans + Number of completed commands + Example above: 18014 completed commands + +num_kbytes + Number of kbytes transferred + Example above: 671 MB transferred + +num_disc + Number of SCSI disconnections + Example above: 25763 SCSI disconnections + +num_break + number of script interruptions (phase mismatch) + Example above: 1673 script interruptions + +num_int + Number of interrupts other than "on the fly" + Example above: 1685 interruptions not "on the fly" + +num_fly + Number of interrupts "on the fly" + Example above: 18038 interruptions "on the fly" + +ms_setup + Elapsed time for SCSI commands setups + Example above: 4.94 seconds + +ms_data + Elapsed time for data transfers + Example above: 369.94 seconds spent for data transfer + +ms_disc + Elapsed time for SCSI disconnections + Example above: 183.09 seconds spent disconnected + +ms_post + Elapsed time for command post processing + (time from SCSI status get to command completion call) + Example above: 1.32 seconds spent for post processing + +Due to the 1/100 second tick of the system clock, "ms_post" time may +be wrong. + +In the example above, we got 18038 interrupts "on the fly" and only +1673 script breaks generally due to disconnections inside a segment +of the scatter list. + + +8. Control commands +=================== + +Control commands can be sent to the driver with write operations to +the proc SCSI file system. The generic command syntax is the +following:: + + echo " " >/proc/scsi/ncr53c8xx/0 + (assumes controller number is 0) + +Using "all" for "" parameter with the commands below will +apply to all targets of the SCSI chain (except the controller). + +Available commands: + +8.1 Set minimum synchronous period factor +----------------------------------------- + + setsync + + :target: target number + :period: minimum synchronous period. + Maximum speed = 1000/(4*period factor) except for special + cases below. + + Specify a period of 255, to force asynchronous transfer mode. + + - 10 means 25 nano-seconds synchronous period + - 11 means 30 nano-seconds synchronous period + - 12 means 50 nano-seconds synchronous period + +8.2 Set wide size +----------------- + + setwide + + :target: target number + :size: 0=8 bits, 1=16bits + +8.3 Set maximum number of concurrent tagged commands +---------------------------------------------------- + + settags + + :target: target number + :tags: number of concurrent tagged commands + must not be greater than SCSI_NCR_MAX_TAGS (default: 8) + +8.4 Set order type for tagged command +------------------------------------- + + setorder + + :order: 3 possible values: + + simple: + use SIMPLE TAG for all operations (read and write) + + ordered: + use ORDERED TAG for all operations + + default: + use default tag type, + SIMPLE TAG for read operations + ORDERED TAG for write operations + + +8.5 Set debug mode +------------------ + + setdebug + + Available debug flags: + + ======== ======================================================== + alloc print info about memory allocations (ccb, lcb) + queue print info about insertions into the command start queue + result print sense data on CHECK CONDITION status + scatter print info about the scatter process + scripts print info about the script binding process + tiny print minimal debugging information + timing print timing information of the NCR chip + nego print information about SCSI negotiations + phase print information on script interruptions + ======== ======================================================== + + Use "setdebug" with no argument to reset debug flags. + + +8.6 Clear profile counters +-------------------------- + + clearprof + + The profile counters are automatically cleared when the amount of + data transferred reaches 1000 GB in order to avoid overflow. + The "clearprof" command allows you to clear these counters at any time. + + +8.7 Set flag (no_disc) +---------------------- + + setflag + + target: target number + + For the moment, only one flag is available: + + no_disc: not allow target to disconnect. + + Do not specify any flag in order to reset the flag. For example: + + setflag 4 + will reset no_disc flag for target 4, so will allow it disconnections. + + setflag all + will allow disconnection for all devices on the SCSI bus. + + +8.8 Set verbose level +--------------------- + + setverbose #level + + The driver default verbose level is 1. This command allows to change + th driver verbose level after boot-up. + +8.9 Reset all logical units of a target +--------------------------------------- + + resetdev + + :target: target number + + The driver will try to send a BUS DEVICE RESET message to the target. + (Only supported by the SYM53C8XX driver and provided for test purpose) + +8.10 Abort all tasks of all logical units of a target +----------------------------------------------------- + + cleardev + + :target: target number + + The driver will try to send a ABORT message to all the logical units + of the target. + + (Only supported by the SYM53C8XX driver and provided for test purpose) + + +9. Configuration parameters +=========================== + +If the firmware of all your devices is perfect enough, all the +features supported by the driver can be enabled at start-up. However, +if only one has a flaw for some SCSI feature, you can disable the +support by the driver of this feature at linux start-up and enable +this feature after boot-up only for devices that support it safely. + +CONFIG_SCSI_NCR53C8XX_IOMAPPED (default answer: n) + Answer "y" if you suspect your mother board to not allow memory mapped I/O. + + May slow down performance a little. This option is required by + Linux/PPC and is used no matter what you select here. Linux/PPC + suffers no performance loss with this option since all IO is memory + mapped anyway. + +CONFIG_SCSI_NCR53C8XX_DEFAULT_TAGS (default answer: 8) + Default tagged command queue depth. + +CONFIG_SCSI_NCR53C8XX_MAX_TAGS (default answer: 8) + This option allows you to specify the maximum number of tagged commands + that can be queued to a device. The maximum supported value is 32. + +CONFIG_SCSI_NCR53C8XX_SYNC (default answer: 5) + This option allows you to specify the frequency in MHz the driver + will use at boot time for synchronous data transfer negotiations. + This frequency can be changed later with the "setsync" control command. + 0 means "asynchronous data transfers". + +CONFIG_SCSI_NCR53C8XX_FORCE_SYNC_NEGO (default answer: n) + Force synchronous negotiation for all SCSI-2 devices. + + Some SCSI-2 devices do not report this feature in byte 7 of inquiry + response but do support it properly (TAMARACK scanners for example). + +CONFIG_SCSI_NCR53C8XX_NO_DISCONNECT (default and only reasonable answer: n) + If you suspect a device of yours does not properly support disconnections, + you can answer "y". Then, all SCSI devices will never disconnect the bus + even while performing long SCSI operations. + +CONFIG_SCSI_NCR53C8XX_SYMBIOS_COMPAT + Genuine SYMBIOS boards use GPIO0 in output for controller LED and GPIO3 + bit as a flag indicating singled-ended/differential interface. + If all the boards of your system are genuine SYMBIOS boards or use + BIOS and drivers from SYMBIOS, you would want to enable this option. + + This option must NOT be enabled if your system has at least one 53C8XX + based scsi board with a vendor-specific BIOS. + For example, Tekram DC-390/U, DC-390/W and DC-390/F scsi controllers + use a vendor-specific BIOS and are known to not use SYMBIOS compatible + GPIO wiring. So, this option must not be enabled if your system has + such a board installed. + +CONFIG_SCSI_NCR53C8XX_NVRAM_DETECT + Enable support for reading the serial NVRAM data on Symbios and + some Symbios compatible cards, and Tekram DC390W/U/F cards. Useful for + systems with more than one Symbios compatible controller where at least + one has a serial NVRAM, or for a system with a mixture of Symbios and + Tekram cards. Enables setting the boot order of host adaptors + to something other than the default order or "reverse probe" order. + Also enables Symbios and Tekram cards to be distinguished so + CONFIG_SCSI_NCR53C8XX_SYMBIOS_COMPAT may be set in a system with a + mixture of Symbios and Tekram cards so the Symbios cards can make use of + the full range of Symbios features, differential, led pin, without + causing problems for the Tekram card(s). + +10. Boot setup commands +======================= + +10.1 Syntax +----------- + +Setup commands can be passed to the driver either at boot time or as a +string variable using 'insmod'. + +A boot setup command for the ncr53c8xx (sym53c8xx) driver begins with the +driver name "ncr53c8xx="(sym53c8xx). The kernel syntax parser then expects +an optional list of integers separated with comma followed by an optional +list of comma-separated strings. Example of boot setup command under lilo +prompt:: + + lilo: linux root=/dev/hda2 ncr53c8xx=tags:4,sync:10,debug:0x200 + +- enable tagged commands, up to 4 tagged commands queued. +- set synchronous negotiation speed to 10 Mega-transfers / second. +- set DEBUG_NEGO flag. + +Since comma seems not to be allowed when defining a string variable using +'insmod', the driver also accepts as option separator. +The following command will install driver module with the same options as +above:: + + insmod ncr53c8xx.o ncr53c8xx="tags:4 sync:10 debug:0x200" + +For the moment, the integer list of arguments is discarded by the driver. +It will be used in the future in order to allow a per controller setup. + +Each string argument must be specified as "keyword:value". Only lower-case +characters and digits are allowed. + +In a system that contains multiple 53C8xx adapters insmod will install the +specified driver on each adapter. To exclude a chip use the 'excl' keyword. + +The sequence of commands:: + + insmod sym53c8xx sym53c8xx=excl:0x1400 + insmod ncr53c8xx + +installs the sym53c8xx driver on all adapters except the one at IO port +address 0x1400 and then installs the ncr53c8xx driver to the adapter at IO +port address 0x1400. + + +10.2 Available arguments +------------------------ + +10.2.1 Master parity checking +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + + ====== ======== + mpar:y enabled + mpar:n disabled + ====== ======== + +10.2.2 Scsi parity checking +^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + + ====== ======== + spar:y enabled + spar:n disabled + ====== ======== + +10.2.3 Scsi disconnections +^^^^^^^^^^^^^^^^^^^^^^^^^^^ + + ====== ======== + disc:y enabled + disc:n disabled + ====== ======== + +10.2.4 Special features +^^^^^^^^^^^^^^^^^^^^^^^^ + + Only apply to 810A, 825A, 860, 875 and 895 controllers. + Have no effect with other ones. + + ======= ================================================= + specf:y (or 1) enabled + specf:n (or 0) disabled + specf:3 enabled except Memory Write And Invalidate + ======= ================================================= + + The default driver setup is 'specf:3'. As a consequence, option 'specf:y' + must be specified in the boot setup command to enable Memory Write And + Invalidate. + +10.2.5 Ultra SCSI support +^^^^^^^^^^^^^^^^^^^^^^^^^^ + + Only apply to 860, 875, 895, 895a, 896, 1010 and 1010_66 controllers. + Have no effect with other ones. + + ======= ======================== + ultra:n All ultra speeds enabled + ultra:2 Ultra2 enabled + ultra:1 Ultra enabled + ultra:0 Ultra speeds disabled + ======= ======================== + +10.2.6 Default number of tagged commands +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + + ======================= =============================== + tags:0 (or tags:1 ) tagged command queuing disabled + tags:#tags (#tags > 1) tagged command queuing enabled + ======================= =============================== + + #tags will be truncated to the max queued commands configuration parameter. + This option also allows to specify a command queue depth for each device + that support tagged command queueing. + + Example:: + + ncr53c8xx=tags:10/t2t3q16-t5q24/t1u2q32 + + will set devices queue depth as follow: + + - controller #0 target #2 and target #3 -> 16 commands, + - controller #0 target #5 -> 24 commands, + - controller #1 target #1 logical unit #2 -> 32 commands, + - all other logical units (all targets, all controllers) -> 10 commands. + +10.2.7 Default synchronous period factor +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +============ ======================================================== +sync:255 disabled (asynchronous transfer mode) +sync:#factor + ============ ======================================= + #factor = 10 Ultra-2 SCSI 40 Mega-transfers / second + #factor = 11 Ultra-2 SCSI 33 Mega-transfers / second + #factor < 25 Ultra SCSI 20 Mega-transfers / second + #factor < 50 Fast SCSI-2 + ============ ======================================= +============ ======================================================== + + In all cases, the driver will use the minimum transfer period supported by + controllers according to NCR53C8XX chip type. + +10.2.8 Negotiate synchronous with all devices +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + (force sync nego) + + ===== ========= + fsn:y enabled + fsn:n disabled + ===== ========= + +10.2.9 Verbosity level +^^^^^^^^^^^^^^^^^^^^^^^ + + ====== ========= + verb:0 minimal + verb:1 normal + verb:2 too much + ====== ========= + +10.2.10 Debug mode +^^^^^^^^^^^^^^^^^^ + +======== ================================================================== +debug:0 clear debug flags +debug:#x set debug flags + + #x is an integer value combining the following power-of-2 values: + + ============= ====== + DEBUG_ALLOC 0x1 + DEBUG_PHASE 0x2 + DEBUG_POLL 0x4 + DEBUG_QUEUE 0x8 + DEBUG_RESULT 0x10 + DEBUG_SCATTER 0x20 + DEBUG_SCRIPT 0x40 + DEBUG_TINY 0x80 + DEBUG_TIMING 0x100 + DEBUG_NEGO 0x200 + DEBUG_TAGS 0x400 + DEBUG_FREEZE 0x800 + DEBUG_RESTART 0x1000 + ============= ====== +======== ================================================================== + + You can play safely with DEBUG_NEGO. However, some of these flags may + generate bunches of syslog messages. + +10.2.11 Burst max +^^^^^^^^^^^^^^^^^ + +========= ================================================================== +burst:0 burst disabled +burst:255 get burst length from initial IO register settings. +burst:#x burst enabled (1<<#x burst transfers max) + + #x is an integer value which is log base 2 of the burst transfers + max. + + The NCR53C875 and NCR53C825A support up to 128 burst transfers + (#x = 7). + + Other chips only support up to 16 (#x = 4). + + This is a maximum value. The driver set the burst length according + to chip and revision ids. By default the driver uses the maximum + value supported by the chip. +========= ================================================================== + +10.2.12 LED support +^^^^^^^^^^^^^^^^^^^ + + ===== =================== + led:1 enable LED support + led:0 disable LED support + ===== =================== + + Donnot enable LED support if your scsi board does not use SDMS BIOS. + (See 'Configuration parameters') + +10.2.13 Max wide +^^^^^^^^^^^^^^^^ + + ====== =================== + wide:1 wide scsi enabled + wide:0 wide scsi disabled + ====== =================== + + Some scsi boards use a 875 (ultra wide) and only supply narrow connectors. + If you have connected a wide device with a 50 pins to 68 pins cable + converter, any accepted wide negotiation will break further data transfers. + In such a case, using "wide:0" in the bootup command will be helpful. + +10.2.14 Differential mode +^^^^^^^^^^^^^^^^^^^^^^^^^ + + ====== ================================= + diff:0 never set up diff mode + diff:1 set up diff mode if BIOS set it + diff:2 always set up diff mode + diff:3 set diff mode if GPIO3 is not set + ====== ================================= + +10.2.15 IRQ mode +^^^^^^^^^^^^^^^^ + + ========= ======================================================== + irqm:0 always open drain + irqm:1 same as initial settings (assumed BIOS settings) + irqm:2 always totem pole + irqm:0x10 driver will not use IRQF_SHARED flag when requesting irq + ========= ======================================================== + + (Bits 0x10 and 0x20 can be combined with hardware irq mode option) + +10.2.16 Reverse probe +^^^^^^^^^^^^^^^^^^^^^ + + ========= ======================================================== + revprob:n probe chip ids from the PCI configuration in this order: + 810, 815, 820, 860, 875, 885, 895, 896 + revprob:y probe chip ids in the reverse order. + ========= ======================================================== + +10.2.17 Fix up PCI configuration space +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + pcifix: