| Dave Jiang | 3a7bda8 | 2011-07-29 17:17:00 -0700 | [diff] [blame] | 1 | What: /sys/class/scsi_host/hostX/isci_id |
| 2 | Date: June 2011 |
| 3 | Contact: Dave Jiang <dave.jiang@intel.com> |
| 4 | Description: |
| 5 | This file contains the enumerated host ID for the Intel |
| 6 | SCU controller. The Intel(R) C600 Series Chipset SATA/SAS |
| 7 | Storage Control Unit embeds up to two 4-port controllers in |
| 8 | a single PCI device. The controllers are enumerated in order |
| 9 | which usually means the lowest number scsi_host corresponds |
| 10 | with the first controller, but this association is not |
| 11 | guaranteed. The 'isci_id' attribute unambiguously identifies |
| 12 | the controller index: '0' for the first controller, |
| 13 | '1' for the second. |
| Scott Teel | da0697b | 2014-02-18 13:57:00 -0600 | [diff] [blame] | 14 | |
| 15 | What: /sys/class/scsi_host/hostX/acciopath_status |
| 16 | Date: November 2013 |
| 17 | Contact: Stephen M. Cameron <scameron@beardog.cce.hp.com> |
| 18 | Description: This file contains the current status of the "SSD Smart Path" |
| 19 | feature of HP Smart Array RAID controllers using the hpsa |
| 20 | driver. SSD Smart Path, when enabled permits the driver to |
| 21 | send i/o requests directly to physical devices that are part |
| 22 | of a logical drive, bypassing the controllers firmware RAID |
| 23 | stack for a performance advantage when possible. A value of |
| 24 | '1' indicates the feature is enabled, and the controller may |
| 25 | use the direct i/o path to physical devices. A value of zero |
| 26 | means the feature is disabled and the controller may not use |
| 27 | the direct i/o path to physical devices. This setting is |
| 28 | controller wide, affecting all configured logical drives on the |
| 29 | controller. This file is readable and writable. |
| Aishwarya Pant | 0a65e12 | 2018-02-13 13:48:16 +0530 | [diff] [blame] | 30 | |
| 31 | What: /sys/class/scsi_host/hostX/link_power_management_policy |
| 32 | Date: Oct, 2007 |
| 33 | KernelVersion: v2.6.24 |
| 34 | Contact: linux-ide@vger.kernel.org |
| 35 | Description: |
| 36 | (RW) This parameter allows the user to read and set the link |
| 37 | (interface) power management. |
| 38 | |
| 39 | There are four possible options: |
| 40 | |
| 41 | min_power: Tell the controller to try to make the link use the |
| 42 | least possible power when possible. This may sacrifice some |
| 43 | performance due to increased latency when coming out of lower |
| 44 | power states. |
| 45 | |
| 46 | max_performance: Generally, this means no power management. |
| 47 | Tell the controller to have performance be a priority over power |
| 48 | management. |
| 49 | |
| 50 | medium_power: Tell the controller to enter a lower power state |
| 51 | when possible, but do not enter the lowest power state, thus |
| 52 | improving latency over min_power setting. |
| 53 | |
| 54 | med_power_with_dipm: Identical to the existing medium_power |
| 55 | setting except that it enables dipm (device initiated power |
| 56 | management) on top, which makes it match the Windows IRST (Intel |
| 57 | Rapid Storage Technology) driver settings. This setting is also |
| 58 | close to min_power, except that: |
| 59 | a) It does not use host-initiated slumber mode, but it does |
| 60 | allow device-initiated slumber |
| 61 | b) It does not enable low power device sleep mode (DevSlp). |
| 62 | |
| 63 | What: /sys/class/scsi_host/hostX/em_message |
| 64 | What: /sys/class/scsi_host/hostX/em_message_type |
| 65 | Date: Jun, 2008 |
| 66 | KernelVersion: v2.6.27 |
| 67 | Contact: linux-ide@vger.kernel.org |
| 68 | Description: |
| 69 | em_message: (RW) Enclosure management support. For the LED |
| 70 | protocol, writes and reads correspond to the LED message format |
| 71 | as defined in the AHCI spec. |
| 72 | |
| 73 | The user must turn sw_activity (under /sys/block/*/device/) OFF |
| 74 | it they wish to control the activity LED via the em_message |
| 75 | file. |
| 76 | |
| 77 | em_message_type: (RO) Displays the current enclosure management |
| 78 | protocol that is being used by the driver (for eg. LED, SAF-TE, |
| 79 | SES-2, SGPIO etc). |
| 80 | |
| 81 | What: /sys/class/scsi_host/hostX/ahci_port_cmd |
| 82 | What: /sys/class/scsi_host/hostX/ahci_host_caps |
| 83 | What: /sys/class/scsi_host/hostX/ahci_host_cap2 |
| 84 | Date: Mar, 2010 |
| 85 | KernelVersion: v2.6.35 |
| 86 | Contact: linux-ide@vger.kernel.org |
| 87 | Description: |
| 88 | [to be documented] |
| 89 | |
| 90 | What: /sys/class/scsi_host/hostX/ahci_host_version |
| 91 | Date: Mar, 2010 |
| 92 | KernelVersion: v2.6.35 |
| 93 | Contact: linux-ide@vger.kernel.org |
| 94 | Description: |
| 95 | (RO) Display the version of the AHCI spec implemented by the |
| 96 | host. |
| 97 | |
| 98 | What: /sys/class/scsi_host/hostX/em_buffer |
| 99 | Date: Apr, 2010 |
| 100 | KernelVersion: v2.6.35 |
| 101 | Contact: linux-ide@vger.kernel.org |
| 102 | Description: |
| 103 | (RW) Allows access to AHCI EM (enclosure management) buffer |
| 104 | directly if the host supports EM. |
| 105 | |
| 106 | For eg. the AHCI driver supports SGPIO EM messages but the |
| 107 | SATA/AHCI specs do not define the SGPIO message format of the EM |
| 108 | buffer. Different hardware(HW) vendors may have different |
| 109 | definitions. With the em_buffer attribute, this issue can be |
| 110 | solved by allowing HW vendors to provide userland drivers and |
| 111 | tools for their SGPIO initiators. |
| 112 | |
| 113 | What: /sys/class/scsi_host/hostX/em_message_supported |
| 114 | Date: Oct, 2009 |
| 115 | KernelVersion: v2.6.39 |
| 116 | Contact: linux-ide@vger.kernel.org |
| 117 | Description: |
| 118 | (RO) Displays supported enclosure management message types. |