Merge remote-tracking branch 'scsi-queue/drivers-for-3.19' into for-linus (096cbc35) · Commits · e / devices / android_kernel_xiaomi_nabu

Documentation/ABI/stable/sysfs-driver-ib_srp

+19 −6

Original line number	Diff line number	Diff line
		@@ -55,12 +55,12 @@ Description: Interface for making ib_srp connect to a new target.
		only safe with partial memory descriptor list support enabled
		(allow_ext_sg=1).
		* comp_vector, a number in the range 0..n-1 specifying the
		MSI-X completion vector. Some HCA's allocate multiple (n)
		MSI-X vectors per HCA port. If the IRQ affinity masks of
		these interrupts have been configured such that each MSI-X
		interrupt is handled by a different CPU then the comp_vector
		parameter can be used to spread the SRP completion workload
		over multiple CPU's.
		MSI-X completion vector of the first RDMA channel. Some
		HCA's allocate multiple (n) MSI-X vectors per HCA port. If
		the IRQ affinity masks of these interrupts have been
		configured such that each MSI-X interrupt is handled by a
		different CPU then the comp_vector parameter can be used to
		spread the SRP completion workload over multiple CPU's.
		* tl_retry_count, a number in the range 2..7 specifying the
		IB RC retry count.
		* queue_size, the maximum number of commands that the
		@@ -88,6 +88,13 @@ Description: Whether ib_srp is allowed to include a partial memory
		descriptor list in an SRP_CMD when communicating with an SRP
		target.

		What: /sys/class/scsi_host/host<n>/ch_count
		Date: April 1, 2015
		KernelVersion: 3.19
		Contact: linux-rdma@vger.kernel.org
		Description: Number of RDMA channels used for communication with the SRP
		target.

		What: /sys/class/scsi_host/host<n>/cmd_sg_entries
		Date: May 19, 2011
		KernelVersion: 2.6.39
		@@ -95,6 +102,12 @@ Contact: linux-rdma@vger.kernel.org
		Description: Maximum number of data buffer descriptors that may be sent to
		the target in a single SRP_CMD request.

		What: /sys/class/scsi_host/host<n>/comp_vector
		Date: September 2, 2013
		KernelVersion: 3.11
		Contact: linux-rdma@vger.kernel.org
		Description: Completion vector used for the first RDMA channel.

		What: /sys/class/scsi_host/host<n>/dgid
		Date: June 17, 2006
		KernelVersion: 2.6.17

Documentation/scsi/libsas.txt

+4 −78

Original line number	Diff line number	Diff line
		@@ -226,9 +226,6 @@ static int register_sas_ha(struct my_sas_ha *my_ha)
		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_max_execute_num = lldd_max_execute_num; (1)

		my_ha->sas_ha.lldd_queue_size = ha_can_queue;
		my_ha->sas_ha.lldd_execute_task = my_execute_task;

		my_ha->sas_ha.lldd_abort_task = my_abort_task;
		@@ -247,28 +244,6 @@ static int register_sas_ha(struct my_sas_ha *my_ha)
		return sas_register_ha(&my_ha->sas_ha);
		}

		(1) This is normally a LLDD parameter, something of the
		lines of a task collector. What it tells the SAS Layer is
		whether the SAS layer should run in Direct Mode (default:
		value 0 or 1) or Task Collector Mode (value greater than 1).

		In Direct Mode, the SAS Layer calls Execute Task as soon as
		it has a command to send to the SDS, _and_ this is a single
		command, i.e. not linked.

		Some hardware (e.g. aic94xx) has the capability to DMA more
		than one task at a time (interrupt) from host memory. Task
		Collector Mode is an optional feature for HAs which support
		this in their hardware. (Again, it is completely optional
		even if your hardware supports it.)

		In Task Collector Mode, the SAS Layer would do _natural_
		coalescing of tasks and at the appropriate moment it would
		call your driver to DMA more than one task in a single HA
		interrupt. DMBS may want to use this by insmod/modprobe
		setting the lldd_max_execute_num to something greater than
		1.

		(2) SAS 1.1 does not define I_T Nexus Reset TMF.

		Events
		@@ -325,71 +300,22 @@ PHYE_SPINUP_HOLD -- SATA is present, COMWAKE not sent.

		The Execute Command SCSI RPC:

		int (lldd_execute_task)(struct sas_task , int num,
		unsigned long gfp_flags);
		int (lldd_execute_task)(struct sas_task , gfp_t gfp_flags);

		Used to queue a task to the SAS LLDD. @task is the tasks to
		be executed. @num should be the number of tasks being
		queued at this function call (they are linked listed via
		task::list), @gfp_mask should be the gfp_mask defining the
		context of the caller.
		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,
		or if you're sending a SCSI Task as linked commands, you
		should also use this function.

		That is, when lldd_execute_task() is called, the command(s)
		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.

		The use of task::list is two-fold, one for linked commands,
		the other discussed below.

		It is possible to queue up more than one task at a time, by
		initializing the list element of struct sas_task, and
		passing the number of tasks enlisted in this manner in num.

		Returns: -SAS_QUEUE_FULL, -ENOMEM, nothing was queued;
		0, the task(s) were queued.

		If you want to pass num > 1, then either
		A) you're the only caller of this function and keep track
		of what you've queued to the LLDD, or
		B) you know what you're doing and have a strategy of
		retrying.

		As opposed to queuing one task at a time (function call),
		batch queuing of tasks, by having num > 1, greatly
		simplifies LLDD code, sequencer code, and _hardware design_,
		and has some performance advantages in certain situations
		(DBMS).

		The LLDD advertises if it can take more than one command at
		a time at lldd_execute_task(), by setting the
		lldd_max_execute_num parameter (controlled by "collector"
		module parameter in aic94xx SAS LLDD).

		You should leave this to the default 1, unless you know what
		you're doing.

		This is a function of the LLDD, to which the SAS layer can
		cater to.

		int lldd_queue_size
		The host adapter's queue size. This is the maximum
		number of commands the lldd can have pending to domain
		devices on behalf of all upper layers submitting through
		lldd_execute_task().

		You really want to set this to something (much) larger than
		1.

		This _really_ has absolutely nothing to do with queuing.
		There is no queuing in SAS LLDDs.

		struct sas_task {
		dev -- the device this task is destined to
		list -- must be initialized (INIT_LIST_HEAD)
		task_proto -- _one_ of enum sas_proto
		scatter -- pointer to scatter gather list array
		num_scatter -- number of elements in scatter

Documentation/scsi/scsi_mid_low_api.txt

+10 −10

Original line number	Diff line number	Diff line
		@@ -149,7 +149,7 @@ scsi_add_host() ---->
		scsi_scan_host() -------+
		\|
		slave_alloc()
		slave_configure() --> scsi_adjust_queue_depth()
		slave_configure() --> scsi_change_queue_depth()
		\|
		slave_alloc()
		slave_configure()
		@@ -159,7 +159,7 @@ scsi_scan_host() -------+
		------------------------------------------------------------

		If the LLD wants to adjust the default queue settings, it can invoke
		scsi_adjust_queue_depth() in its slave_configure() routine.
		scsi_change_queue_depth() in its slave_configure() routine.

		*** For scsi devices that the mid level tries to scan but do not
		respond, a slave_alloc(), slave_destroy() pair is called.
		@@ -203,7 +203,7 @@ LLD mid level LLD
		scsi_add_device() ------+
		\|
		slave_alloc()
		slave_configure() [--> scsi_adjust_queue_depth()]
		slave_configure() [--> scsi_change_queue_depth()]
		------------------------------------------------------------

		In a similar fashion, an LLD may become aware that a SCSI device has been
		@@ -261,7 +261,7 @@ init_this_scsi_driver() ----+
		\| scsi_register()
		\|
		slave_alloc()
		slave_configure() --> scsi_adjust_queue_depth()
		slave_configure() --> scsi_change_queue_depth()
		slave_alloc() ***
		slave_destroy() ***
		\|
		@@ -271,7 +271,7 @@ init_this_scsi_driver() ----+
		slave_destroy() ***
		------------------------------------------------------------

		The mid level invokes scsi_adjust_queue_depth() with "cmd_per_lun" for that
		The mid level invokes scsi_change_queue_depth() with "cmd_per_lun" for that
		host as the queue length. These settings can be overridden by a
		slave_configure() supplied by the LLD.

		@@ -368,7 +368,7 @@ names all start with "scsi_".
		Summary:
		scsi_add_device - creates new scsi device (lu) instance
		scsi_add_host - perform sysfs registration and set up transport class
		scsi_adjust_queue_depth - change the queue depth on a SCSI device
		scsi_change_queue_depth - change the queue depth on a SCSI device
		scsi_bios_ptable - return copy of block device's partition table
		scsi_block_requests - prevent further commands being queued to given host
		scsi_host_alloc - return a new scsi_host instance whose refcount==1
		@@ -436,7 +436,7 @@ int scsi_add_host(struct Scsi_Host shost, struct device dev)


		/**
		* scsi_adjust_queue_depth - allow LLD to change queue depth on a SCSI device
		* scsi_change_queue_depth - allow LLD to change queue depth on a SCSI device
		* @sdev: pointer to SCSI device to change queue depth on
		* @tags Number of tags allowed if tagged queuing enabled,
		* or number of commands the LLD can queue up
		@@ -453,7 +453,7 @@ int scsi_add_host(struct Scsi_Host shost, struct device dev)
		* Defined in: drivers/scsi/scsi.c [see source code for more notes]
		*
		**/
		void scsi_adjust_queue_depth(struct scsi_device *sdev, int tags)
		int scsi_change_queue_depth(struct scsi_device *sdev, int tags)


		/**
		@@ -1214,7 +1214,7 @@ of interest:
		for disk firmware uploads.
		cmd_per_lun - maximum number of commands that can be queued on devices
		controlled by the host. Overridden by LLD calls to
		scsi_adjust_queue_depth().
		scsi_change_queue_depth().
		unchecked_isa_dma - 1=>only use bottom 16 MB of ram (ISA DMA addressing
		restriction), 0=>can use full 32 bit (or better) DMA
		address space
		@@ -1254,7 +1254,7 @@ struct scsi_cmnd
		Instances of this structure convey SCSI commands to the LLD and responses
		back to the mid level. The SCSI mid level will ensure that no more SCSI
		commands become queued against the LLD than are indicated by
		scsi_adjust_queue_depth() (or struct Scsi_Host::cmd_per_lun). There will
		scsi_change_queue_depth() (or struct Scsi_Host::cmd_per_lun). There will
		be at least one instance of struct scsi_cmnd available for each SCSI device.
		Members of interest:
		cmnd - array containing SCSI command

Documentation/scsi/wd719x.txt

0 → 100644

+21 −0

Original line number	Diff line number	Diff line
		Driver for Western Digital WD7193, WD7197 and WD7296 SCSI cards
		---------------------------------------------------------------

		The card requires firmware that can be cut out of the Windows NT driver that
		can be downloaded from WD at:
		http://support.wdc.com/product/download.asp?groupid=801&sid=27&lang=en

		There is no license anywhere in the file or on the page - so the firmware
		probably cannot be added to linux-firmware.

		This script downloads and extracts the firmware, creating wd719x-risc.bin and
		d719x-wcs.bin files. Put them in /lib/firmware/.

		#!/bin/sh
		wget http://support.wdc.com/download/archive/pciscsi.exe
		lha xi pciscsi.exe pci-scsi.exe
		lha xi pci-scsi.exe nt/wd7296a.sys
		rm pci-scsi.exe
		dd if=wd7296a.sys of=wd719x-risc.bin bs=1 skip=5760 count=14336
		dd if=wd7296a.sys of=wd719x-wcs.bin bs=1 skip=20096 count=514
		rm wd7296a.sys

MAINTAINERS

+9 −8

Original line number	Diff line number	Diff line
		@@ -2862,11 +2862,10 @@ F: Documentation/networking/dmfe.txt
		F: drivers/net/ethernet/dec/tulip/dmfe.c

		DC390/AM53C974 SCSI driver
		M: Kurt Garloff <garloff@suse.de>
		W: http://www.garloff.de/kurt/linux/dc390/
		M: Guennadi Liakhovetski <g.liakhovetski@gmx.de>
		M: Hannes Reinecke <hare@suse.de>
		L: linux-scsi@vger.kernel.org
		S: Maintained
		F: drivers/scsi/tmscsim.*
		F: drivers/scsi/am53c974.c

		DC395x SCSI driver
		M: Oliver Neukum <oliver@neukum.org>
		@@ -5991,10 +5990,13 @@ W: http://linuxtv.org
		S: Odd Fixes
		F: drivers/media/parport/pms*

		MEGARAID SCSI DRIVERS
		M: Neela Syam Kolli <megaraidlinux@lsi.com>
		MEGARAID SCSI/SAS DRIVERS
		M: Kashyap Desai <kashyap.desai@avagotech.com>
		M: Sumit Saxena <sumit.saxena@avagotech.com>
		M: Uday Lingala <uday.lingala@avagotech.com>
		L: megaraidlinux.pdl@avagotech.com
		L: linux-scsi@vger.kernel.org
		W: http://megaraid.lsilogic.com
		W: http://www.lsi.com
		S: Maintained
		F: Documentation/scsi/megaraid.txt
		F: drivers/scsi/megaraid.*
		@@ -6305,7 +6307,6 @@ F: drivers/scsi/g_NCR5380.*
		F: drivers/scsi/g_NCR5380_mmio.c
		F: drivers/scsi/mac_scsi.*
		F: drivers/scsi/pas16.*
		F: drivers/scsi/sun3_NCR5380.c
		F: drivers/scsi/sun3_scsi.*
		F: drivers/scsi/sun3_scsi_vme.c
		F: drivers/scsi/t128.*