Since the request structure contains a pointer to the completion to be
used if the request is being aborted or terminated, there is no reason
to pass the completion as a pointer to isci_terminate_request_core().
Signed-off-by: NJeff Skirvin <jeffrey.d.skirvin@intel.com>
Signed-off-by: NJacek Danecki <Jacek.Danecki@intel.com>
Signed-off-by: NDan Williams <dan.j.williams@intel.com>

Made sure the device ready check accounts for all states.
Moved the aborted task check into the loop of pulling task requests
off of the submitted list.
Signed-off-by: NJeff Skirvin <jeffrey.d.skirvin@intel.com>
Signed-off-by: NJacek Danecki <Jacek.Danecki@intel.com>
[remove host and device starting state checks]
Signed-off-by: NDan Williams <dan.j.williams@intel.com>

The pointer to the core representation of a request is marked NULL at
completion, but we need to save the i/o tag for task management.
Signed-off-by: NJeff Skirvin <jeffrey.d.skirvin@intel.com>
Signed-off-by: NJacek Danecki <Jacek.Danecki@intel.com>
[revise changelog]
Signed-off-by: NDan Williams <dan.j.williams@intel.com>

Corrected use of the request state_lock in the completion callback.

In the case where an abort (or reset) thread is trying to terminate an
I/O request, it sets the request state to "aborting" (or "terminating")
if the state is still "starting".  One of the bugs was to never set the
state to "completed".  Another was to not correctly recognize the
situation where the I/O had completed but the sas_task was still pending
callback to task_done - this was typically a problem in the LUN and
device reset cases.

It is now possible that we leave isci_task_abort_task() with
request->io_request_completion pointing to localy allocated
aborted_io_completion struct. It may result in a system crash.
Signed-off-by: NJeff Skirvin <jeffrey.d.skirvin@intel.com>
Signed-off-by: NMaciej Trela <Maciej.Trela@intel.com>
Signed-off-by: NJacek Danecki <Jacek.Danecki@intel.com>
Signed-off-by: NDan Williams <dan.j.williams@intel.com>

In the condition where outstanding I/Os are being cleaned from the device
requests in process list, the cleanup function needs to check that the
request is actually a sas-task and not a task management function.
Signed-off-by: NJeff Skirvin <jeffrey.d.skirvin@intel.com>
Signed-off-by: NDan Williams <dan.j.williams@intel.com>

The midlayer is already throttling i/o in the places where host_quiesce
was trying to prevent further i/o to the device.  It's also problematic
in that it holds a lock over GFP_KERNEL allocations.
Signed-off-by: NDan Williams <dan.j.williams@intel.com>

It belies the fact that isci_remote_device and scic_sds_remote_device
are one in same object with the same lifetime rules.
Signed-off-by: NDan Williams <dan.j.williams@intel.com>

Prepare the timer api for the arrival of dynamic creation and
destruction events from the core.  It pretended to do this previously
but the core to date only used it in a static init-time only fashion.
This is an interim fix until a cleaner event queue can be developed.

1/ make all locking external to the api (add WARN_ONCE to verify)
2/ add a timer_destroy interface (to be used by the core)
3/ use del_timer_sync() prior to deallocating timer data
4/ delete the "timer_list" indirection, we only have timers allocated
   for the isci_host
5/ fix detection of timer list allocation errors
Signed-off-by: NDan Williams <dan.j.williams@intel.com>

The lldd actively disallows requests in the "starting" state.  Retrying
or holding off commands in this state is sub-optimal:
1/ it adds another state check to the fast path
2/ retrying can cause libsas to give up

However, isci's ->lldd_dev_found() routine already waits for controller
start to complete before allowing further progress.  Checking the
"starting" state in isci_task_execute_task and the isr is redundant and
misleading.  Clean this up and introduce a controller-wide event queue
to start reeling in "completion" proliferation in the driver.

The "stopping" state cleanups are in a similar vein, rely on the the isr
and other paths being precluded from occurring rather than implementing
state checking logic.
Reported-by: NChristoph Hellwig <hch@infradead.org>
Cc: Jeff Garzik <jeff@garzik.org>
Signed-off-by: NEdmund Nadolski <edmund.nadolski@intel.com>
Signed-off-by: NDan Williams <dan.j.williams@intel.com>

Support for the up to 2x4-port 6Gb/s SAS controllers embedded in the
chipset.

This is a snapshot of the first publicly available version of the driver,
commit 4c1db2d0 in the 'historical' branch.

   git://git.kernel.org/pub/scm/linux/kernel/git/djbw/isci.git historical
Signed-off-by: NMaciej Trela <maciej.trela@intel.com>
Signed-off-by: NDave Jiang <dave.jiang@intel.com>
Signed-off-by: NEdmund Nadolski <edmund.nadolski@intel.com>
Signed-off-by: NDan Williams <dan.j.williams@intel.com>