1What:		/sys/class/scsi_host/hostX/isci_id
 2Date:		June 2011
 3Contact:	Dave Jiang <dave.jiang@intel.com>
 4Description:
 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.

  1What:		/sys/class/scsi_host/hostX/isci_id
  2Date:		June 2011
  3Contact:	Dave Jiang <dave.jiang@intel.com>
  4Description:
  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.
 14
 15What:		/sys/class/scsi_host/hostX/acciopath_status
 16Date:		November 2013
 17Contact:	Stephen M. Cameron <scameron@beardog.cce.hp.com>
 18Description:	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.
 30
 31What:		/sys/class/scsi_host/hostX/link_power_management_policy
 32Date:		Oct, 2007
 33KernelVersion:	v2.6.24
 34Contact:	linux-ide@vger.kernel.org
 35Description:
 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
 63What:		/sys/class/scsi_host/hostX/em_message
 64What:		/sys/class/scsi_host/hostX/em_message_type
 65Date:		Jun, 2008
 66KernelVersion:	v2.6.27
 67Contact:	linux-ide@vger.kernel.org
 68Description:
 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
 81What:		/sys/class/scsi_host/hostX/ahci_port_cmd
 82What:		/sys/class/scsi_host/hostX/ahci_host_caps
 83What:		/sys/class/scsi_host/hostX/ahci_host_cap2
 84Date:		Mar, 2010
 85KernelVersion:	v2.6.35
 86Contact:	linux-ide@vger.kernel.org
 87Description:
 88		[to be documented]
 89
 90What:		/sys/class/scsi_host/hostX/ahci_host_version
 91Date:		Mar, 2010
 92KernelVersion:	v2.6.35
 93Contact:	linux-ide@vger.kernel.org
 94Description:
 95		(RO) Display the version of the AHCI spec implemented by the
 96		host.
 97
 98What:		/sys/class/scsi_host/hostX/em_buffer
 99Date:		Apr, 2010
100KernelVersion:	v2.6.35
101Contact:	linux-ide@vger.kernel.org
102Description:
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
113What:		/sys/class/scsi_host/hostX/em_message_supported
114Date:		Oct, 2009
115KernelVersion:	v2.6.39
116Contact:	linux-ide@vger.kernel.org
117Description:
118		(RO) Displays supported enclosure management message types.