diff options
Diffstat (limited to 'Documentation/scsi')
| -rw-r--r-- | Documentation/scsi/scsi_fc_transport.rst | 35 | ||||
| -rw-r--r-- | Documentation/scsi/scsi_mid_low_api.rst | 18 |
2 files changed, 43 insertions, 10 deletions
diff --git a/Documentation/scsi/scsi_fc_transport.rst b/Documentation/scsi/scsi_fc_transport.rst index e3ddcfb7f8fd3..5ef75575924e4 100644 --- a/Documentation/scsi/scsi_fc_transport.rst +++ b/Documentation/scsi/scsi_fc_transport.rst @@ -30,7 +30,40 @@ This file is found at Documentation/scsi/scsi_fc_transport.rst FC Remote Ports (rports) ======================== -<< To Be Supplied >> + + In the Fibre Channel (FC) subsystem, a remote port (rport) refers to a + remote Fibre Channel node that the local port can communicate with. + These are typically storage targets (e.g., arrays, tapes) that respond + to SCSI commands over FC transport. + + In Linux, rports are managed by the FC transport class and are + represented in sysfs under: + + /sys/class/fc_remote_ports/ + + Each rport directory contains attributes describing the remote port, + such as port ID, node name, port state, and link speed. + + rports are typically created by the FC transport when a new device is + discovered during a fabric login or scan, and they persist until the + device is removed or the link is lost. + + Common attributes: + - node_name: World Wide Node Name (WWNN). + - port_name: World Wide Port Name (WWPN). + - port_id: FC address of the remote port. + - roles: Indicates if the port is an initiator, target, or both. + - port_state: Shows the current operational state. + + After discovering a remote port, the driver typically populates a + fc_rport_identifiers structure and invokes fc_remote_port_add() to + create and register the remote port with the SCSI subsystem via the + Fibre Channel (FC) transport class. + + rports are also visible via sysfs as children of the FC host adapter. + + For developers: use fc_remote_port_add() and fc_remote_port_delete() when + implementing a driver that interacts with the FC transport class. FC Virtual Ports (vports) diff --git a/Documentation/scsi/scsi_mid_low_api.rst b/Documentation/scsi/scsi_mid_low_api.rst index 3cd6dce98e74c..3ac4c7fafb55c 100644 --- a/Documentation/scsi/scsi_mid_low_api.rst +++ b/Documentation/scsi/scsi_mid_low_api.rst @@ -37,7 +37,7 @@ ISA adapters).] The SCSI mid level isolates an LLD from other layers such as the SCSI upper layer drivers and the block layer. -This version of the document roughly matches linux kernel version 2.6.8 . +This version of the document roughly matches Linux kernel version 2.6.8 . Documentation ============= @@ -48,7 +48,7 @@ found in that directory. A more recent copy of this document may be found at https://docs.kernel.org/scsi/scsi_mid_low_api.html. Many LLDs are documented in Documentation/scsi (e.g. aic7xxx.rst). The SCSI mid-level is briefly described in scsi.rst which contains a URL to a document describing -the SCSI subsystem in the Linux Kernel 2.4 series. Two upper level +the SCSI subsystem in the Linux kernel 2.4 series. Two upper level drivers have documents in that directory: st.rst (SCSI tape driver) and scsi-generic.rst (for the sg driver). @@ -75,7 +75,7 @@ It is probably best to study how existing LLDs are organized. As the 2.5 series development kernels evolve into the 2.6 series production series, changes are being introduced into this interface. An example of this is driver initialization code where there are now 2 models -available. The older one, similar to what was found in the lk 2.4 series, +available. The older one, similar to what was found in the Linux 2.4 series, is based on hosts that are detected at HBA driver load time. This will be referred to the "passive" initialization model. The newer model allows HBAs to be hot plugged (and unplugged) during the lifetime of the LLD and will @@ -1026,7 +1026,7 @@ initialized from the driver's struct scsi_host_template instance. Members of interest: host_no - - system wide unique number that is used for identifying + - system-wide unique number that is used for identifying this host. Issued in ascending order from 0. can_queue - must be greater than 0; do not send more than can_queue @@ -1053,7 +1053,7 @@ of interest: - pointer to driver's struct scsi_host_template from which this struct Scsi_Host instance was spawned hostt->proc_name - - name of LLD. This is the driver name that sysfs uses + - name of LLD. This is the driver name that sysfs uses. transportt - pointer to driver's struct scsi_transport_template instance (if any). FC and SPI transports currently supported. @@ -1067,7 +1067,7 @@ The scsi_host structure is defined in include/scsi/scsi_host.h struct scsi_device ------------------ Generally, there is one instance of this structure for each SCSI logical unit -on a host. Scsi devices connected to a host are uniquely identified by a +on a host. SCSI devices connected to a host are uniquely identified by a channel number, target id and logical unit number (lun). The structure is defined in include/scsi/scsi_device.h @@ -1091,7 +1091,7 @@ Members of interest: - should be set by LLD prior to calling 'done'. A value of 0 implies a successfully completed command (and all data (if any) has been transferred to or from the SCSI - target device). 'result' is a 32 bit unsigned integer that + target device). 'result' is a 32-bit unsigned integer that can be viewed as 2 related bytes. The SCSI status value is in the LSB. See include/scsi/scsi.h status_byte() and host_byte() macros and related constants. @@ -1180,8 +1180,8 @@ may get out of synchronization. This is why it is best for the LLD to perform autosense. -Changes since lk 2.4 series -=========================== +Changes since Linux kernel 2.4 series +===================================== io_request_lock has been replaced by several finer grained locks. The lock relevant to LLDs is struct Scsi_Host::host_lock and there is one per SCSI host. |