Lines Matching refs:SCSI

2                  SCSI mid_level - lower_level driver interface
7 This document outlines the interface between the Linux SCSI mid level and
8 SCSI lower level drivers. Lower level drivers (LLDs) are variously called
11 single SCSI initiator port on a SCSI transport. An "initiator" port
12 (SCSI terminology, see SAM-3 at http://www.t10.org) sends SCSI commands
13 to "target" SCSI ports (e.g. disks). There can be many LLDs in a running
15 SCSI HBAs. Some HBAs contain multiple hosts.
17 In some cases the SCSI transport is an external bus that already has
19 SCSI subsystem LLD is a software bridge to the other driver subsystem.
24 For example, the aic7xxx LLD controls Adaptec SCSI parallel interface
32 a SCSI host and a PCI device is common but not required (e.g. with
35 The SCSI mid level isolates an LLD from other layers such as the SCSI
42 There is a SCSI documentation directory within the kernel source tree,
47 Many LLDs are documented there (e.g. aic7xxx.txt). The SCSI mid-level is
49 describing the SCSI subsystem in the lk 2.4 series. Two upper level
50 drivers have documents in that directory: st.txt (SCSI tape driver) and
60 Traditionally an LLD for the SCSI subsystem has been at least two files in
81 preferred as it can handle both traditional SCSI equipment that is
82 permanently connected as well as modern "SCSI" devices (e.g. USB or
86 An LLD interfaces to the SCSI subsystem several ways:
122 In this model an LLD controls when SCSI hosts are introduced and removed
123 from the SCSI subsystem. Hosts can be introduced as early as driver
128 with the SCSI mid level.
134 registered with sysfs at this point. The SCSI mid level first becomes
142 HBA PROBE: assume 2 SCSI devices found in scan
171 HBA REMOVE: assume 2 SCSI devices attached
186 Hot unplugging an HBA that controls a disk which is processing SCSI
192 The hotplug concept may be extended to SCSI devices. Currently, when an
193 HBA is added, the scsi_scan_host() function causes a scan for SCSI devices
194 attached to the HBA's SCSI transport. On newer SCSI transports the HBA
195 may become aware of a new SCSI device _after_ the scan has completed.
196 An LLD can use this sequence to make the mid level aware of a SCSI device:
198 SCSI DEVICE hotplug
207 In a similar fashion, an LLD may become aware that a SCSI device has been
209 existing SCSI transports (e.g. SPI) may not become aware that a SCSI
210 device has been removed until a subsequent SCSI command fails which will
212 detects the removal of a SCSI device can instigate its removal from
215 SCSI DEVICE hot unplug
233 across the various SCSI layers which use them. Previously such instances
249 across the various SCSI layers which use them. Previously such instances
267 struct tags. Both can be still found in the SCSI subsystem, but
286 These functions are supplied by the SCSI mid level for use by LLDs.
289 arrange for the SCSI mid level to be loaded and initialized before any LLD
296 scsi_change_queue_depth - change the queue depth on a SCSI device
304 scsi_remove_device - detach and remove a SCSI device
305 scsi_remove_host - detach and remove all SCSI devices owned by host
307 scsi_scan_host - scan SCSI bus
364 * scsi_change_queue_depth - allow LLD to change queue depth on a SCSI device
365 * @sdev: pointer to SCSI device to change queue depth on
374 * Notes: Can be invoked any time on a SCSI device controlled by this
427 * Notes: When this call returns to the LLD, the SCSI bus scan on
505 * Notes: When this call returns to the LLD, the SCSI bus scan on
517 * scsi_remove_device - detach and remove a SCSI device
536 * scsi_remove_host - detach and remove all SCSI devices owned by host
573 * scsi_scan_host - scan SCSI bus
589 * @sdev: pointer to SCSI device instance
590 * @depth: Current number of outstanding SCSI commands on this device,
668 eh_bus_reset_handler - issue SCSI bus reset
669 eh_device_reset_handler - issue SCSI device reset
758 * eh_bus_reset_handler - issue SCSI bus reset
759 * @scp: SCSI bus that contains this device should be reset
776 * eh_device_reset_handler - issue SCSI device reset
777 * @scp: identifies SCSI device to be reset
795 * @scp: SCSI host that contains this device should be reset
861 * Notes: The SCSI subsystem uses a "trickle down" ioctl model.
864 * the 'cmd' then it is passed to the SCSI mid level. If the SCSI
962 * response to a SCSI INQUIRY) the scp->scsi_done callback may be
964 * callback is not invoked within a certain period the SCSI mid
1065 SCSI commands into an LLD.
1089 in a single SCSI command. The default value of 0 leads
1125 Generally, there is one instance of this structure for each SCSI logical unit
1132 Instances of this structure convey SCSI commands to the LLD and responses
1133 back to the mid level. The SCSI mid level will ensure that no more SCSI
1136 be at least one instance of struct scsi_cmnd available for each SCSI device.
1138 cmnd - array containing SCSI command
1139 cmnd_len - length (in bytes) of SCSI command
1152 SCSI command is completed (successfully or otherwise).
1159 data (if any) has been transferred to or from the SCSI
1161 can be viewed as 4 related bytes. The SCSI status value is
1166 should be written when the SCSI status (LSB of 'result')
1170 contains a valid SCSI sense buffer; otherwise the mid
1171 level will issue a REQUEST_SENSE SCSI command to
1183 interesting case is data transfers from a SCSI target
1192 It is recommended that a LLD set 'resid' on data transfers from a SCSI
1222 with the completion of a SCSI command" when a status of CHECK CONDITION
1225 a) instructing the SCSI protocol (e.g. SCSI Parallel Interface (SPI))
1246 one per SCSI host.
1252 In the 2.4 series the SCSI subsystem configuration descriptions were
1255 the SCSI subsystem now has its own (much smaller) drivers/scsi/Kconfig