If a physical device exposed to the OS by hpsa
is replaced (e.g. one hot plug tape drive is replaced
by another, or a tape drive is placed into "OBDR" mode
in which it acts like a CD-ROM device) and a rescan is
initiated, the replaced device will be added to the
SCSI midlayer with target and lun numbers set to -1.
After that, a panic is likely to ensue.  When a physical
device is replaced, the lun and target number should be
preserved.
Signed-off-by: NStephen M. Cameron <scameron@beardog.cce.hp.com>
Cc: stable@kernel.org
Signed-off-by: NJames Bottomley <JBottomley@Parallels.com>

The test to detect OBDR ("One Button Disaster Recovery")
cd-rom devices was comparing against uninitialized data.

Fixed by moving the test for the device to where the
inquiry data is collected, and uninitialized variable
altogether as it wasn't really being used.
Signed-off-by: NStephen M. Cameron <scameron@beardog.cce.hp.com>
Cc: stable@kernel.org
Signed-off-by: NJames Bottomley <JBottomley@Parallels.com>

Signed-off-by: NDan Williams <dan.j.williams@intel.com>
Signed-off-by: NJames Bottomley <JBottomley@Parallels.com>

Hardware only increments the put pointer on event types >= 4.  Do not
increment the get pointer for event type 3.
Reported-by: NKapil Karkra <kapil.karkra@intel.com>
Signed-off-by: NDan Williams <dan.j.williams@intel.com>
Signed-off-by: NJames Bottomley <JBottomley@Parallels.com>

Hardware allows both an outstanding number commands and a timeout value
(whichever occurs first) as a gate to the next interrupt generation.  This
scheme at completion time looks at the remaining number of outstanding tasks
and sets the timeout to maximize small transaction operation.  If transactions
are large (take more than a few 10s of microseconds to complete) then
performance is not interrupt processing bound, so the small timeouts this
scheme generates are overridden by the time it takes for a completion to
arrive.
Tested-by: NDave Jiang <dave.jiang@intel.com>
Signed-off-by: NDan Williams <dan.j.williams@intel.com>
Signed-off-by: NJames Bottomley <JBottomley@Parallels.com>

Instead of immediately completing any request that has a second
termination call made on it, wait for the TC done/abort HW event.
Signed-off-by: NJeff Skirvin <jeffrey.d.skirvin@intel.com>
Signed-off-by: NDan Williams <dan.j.williams@intel.com>
Signed-off-by: NJames Bottomley <JBottomley@Parallels.com>

Adding API update for adding isci_id entry scsi_host sysfs entry.
Also fixing up the sysfs registration to the scsi_host template
Signed-off-by: NDave Jiang <dave.jiang@intel.com>
Signed-off-by: NDan Williams <dan.j.williams@intel.com>
Signed-off-by: NJames Bottomley <JBottomley@Parallels.com>

Need the following workaround in the driver for interoperability with
the older Intel SSD drives and any other SATA drive that may exhibit the
same behavior. This is a corner case where SCU speed is limited to
either 3G or 1.5G and the drive has a period of DC idle when it switches
speed during SATA speed negotiation. Workaround :change PHYTOV[31:24]
from 0x36 to 0x3B.
Signed-off-by: NMarcin Tomczak <marcin.tomczak@intel.com>
Signed-off-by: NDan Williams <dan.j.williams@intel.com>
Signed-off-by: NJames Bottomley <JBottomley@Parallels.com>

The unsolicited frame control infrastructure requires a table of dma
addresses for the hardware to lookup the frame buffer location by an
index.  The hardware expects the elements of this table to be 64-bit
quantities, so we cannot reference these elements as dma_addr_t.  All
unsolicited frame protocols are affected, particularly SATA-PIO and SMP
which prevented direct-attached SATA drives and expander-attached drives
to not be discovered.

Cc: <stable@kernel.org>
Reported-by: NJacek Danecki <jacek.danecki@intel.com>
Signed-off-by: NDan Williams <dan.j.williams@intel.com>
Signed-off-by: NJames Bottomley <JBottomley@Parallels.com>

A bug (likely copy/paste) that has been carried from the original
implementation.  The unsolicited frame handling structure returns the
d2h fis in the isci_request.stp.rsp buffer.

Cc: <stable@kernel.org>
Signed-off-by: NDan Williams <dan.j.williams@intel.com>
Signed-off-by: NJames Bottomley <JBottomley@Parallels.com>

Cleanup to:

- have selection for all types of frames, not just FCP.
- remove redundant cpu_online check once fcoe_select_cpu called
  as this is not required since later code flow check for offlined
  cpu.
- Simplify fcoe_select_cpu() by removing unnecessary checks to
  skip curr_cpu, this also fixes possibly infinite loop in case
  of curr_cpu is the only cpu while iterating in the loop.

This cleanup mainly applies to target as incoming request are
mostly for target, therefore Kiran has verified the patch
with target also.
Signed-off-by: NVasu Dev <vasu.dev@intel.com>
Tested-by: NKiran Patil <kiran.patil@intel.com>
Tested-by: NRoss Brattain <ross.b.brattain@intel.com>
Signed-off-by: NRobert Love <robert.w.love@intel.com>
Signed-off-by: NJames Bottomley <JBottomley@Parallels.com>

Use pending queue to retry FIP frame in case its tx
fails and use common pending queue for both fcoe
and fip frames using fcoe_port_send.
Signed-off-by: NVasu Dev <vasu.dev@intel.com>
Tested-by: NRoss Brattain <ross.b.brattain@intel.com>
Signed-off-by: NRobert Love <robert.w.love@intel.com>
Signed-off-by: NJames Bottomley <JBottomley@Parallels.com>

The lport retry timer hits warn on in case
it has become ready in response from fip
login from fcoe_ctlr_flogi_send(), this is
possible but safe code path, therefore
removing this warn on.

Jun 22 03:16:30 10.0.16.6 [488198.316517] host3: Assigned Port ID 180f02
Jun 22 03:16:32 10.0.16.6 [488200.091561] ------------[ cut here ]------------
Jun 22 03:16:32 10.0.16.6 [488200.091586] WARNING: at
drivers/scsi/libfc/fc_lport.c:1355 fc_lport_timeout+0xd9/0xe0 [libfc]()
Signed-off-by: NVasu Dev <vasu.dev@intel.com>
Tested-by: NRoss Brattain <ross.b.brattain@intel.com>
Signed-off-by: NRobert Love <robert.w.love@intel.com>
Signed-off-by: NJames Bottomley <JBottomley@Parallels.com>

fc_queuecommand() allocates an FCP packet for each SCSI command and sends
it out on the wire. In the process it stores the reference to the FCP packet
in the scsi_cmnd structure.
Now, in case under stress testing the libfc exchange layer runs out of
exchanges the fc_queuecommand() may not be able to send out commands out on
the wire. In such a scenario if there is an error in sending the FCP packet
out the wire; fc_queuecommand() deletes the FCP packet from internal queue,
releases the FCP packet and returns a SCSI_MLQUEUE_HOST_BUSY status to the
scsi-ml. But, the reference to the FCP packet set in the scsi_cmnd is not
removed from the scsi_cmnd in this code path.

This might lead to a crash under stress testing where the scsi_cmnd failed by
fc_queuecommand() comes up to fc_eh_abort() via scsi eh thread. fc_eh_abort()
will get reference to the FCP packet to be aborted from the scsi_cmnd for
further FCP abort related processing and then try to release the FCP packet
that has already been released.

This patch removes the FCP packet reference from the scsi_cmnd before returning
back from fc_queuecommand() in case of an error in sending out the FCP packet.
Signed-off-by: NNeerav Parikh <Neerav.Parikh@intel.com>
Tested-by: NRoss Brattain <ross.b.brattain@intel.com>
Signed-off-by: NRobert Love <robert.w.love@intel.com>
Signed-off-by: NJames Bottomley <JBottomley@Parallels.com>

The variable on stack, namely cdb_op, is not used but removed.

[ Patch reworked by Robert Love due to invalid patch format ]
Signed-off-by: NHillf Danton <dhillf@gmail.com>
Signed-off-by: NRobert Love <robert.w.love@intel.com>
Signed-off-by: NJames Bottomley <JBottomley@Parallels.com>

One change is to cleanup typo in comment for fc_fcp_recv(), another corrects
the misleading comment for fc_fcp_abts_resp().

[ Patch reworked by Robert Love due to invalid patch format ]
Signed-off-by: NHillf Danton <dhillf@gmail.com>
Signed-off-by: NRobert Love <robert.w.love@intel.com>
Signed-off-by: NJames Bottomley <JBottomley@Parallels.com>

Drop the rx frame having xid with wrong cpu info
or received with xid  not matching to our xid.

Not dropping such frame is causing panic as
that causes accessing data struct beyond their
bounds.
Signed-off-by: NVasu Dev <vasu.dev@intel.com>
Tested-by: NRoss Brattain <ross.b.brattain@intel.com>
Signed-off-by: NRobert Love <robert.w.love@intel.com>
Signed-off-by: NJames Bottomley <JBottomley@Parallels.com>

If fail to create workqueue, the newly created cache for exchg has to be
released.
Signed-off-by: NHillf Danton <dhillf@gmail.com>
Reviewed-by: NVasu Dev <vasu.dev@intel.com>
Signed-off-by: NRobert Love <robert.w.love@intel.com>
Signed-off-by: NJames Bottomley <JBottomley@Parallels.com>

Though defined, FC_MAX_ERROR_CNT is not used. It is used now for CRC error in
the path of receiving FCP frame.
Signed-off-by: NHillf Danton <dhillf@gmail.com>
Signed-off-by: NRobert Love <robert.w.love@intel.com>
Signed-off-by: NJames Bottomley <JBottomley@Parallels.com>

There is no need to cache the ptype in fcoe_rcv_info struct as it is never
used anywhere.
Signed-off-by: NYi Zou <yi.zou@intel.com>
Tested-by: NRoss Brattain <ross.b.brattain@intel.com>
Signed-off-by: NRobert Love <robert.w.love@intel.com>
Signed-off-by: NJames Bottomley <JBottomley@Parallels.com>

Signed-off-by: NBhanu Prakash Gollapudi <bprakash@broadcom.com>
Signed-off-by: NJames Bottomley <JBottomley@Parallels.com>

When there is a single BD for the entire data to be transmitted, use the BD
inside the SGL context and set the cached SGE indication in the task context
Signed-off-by: NBhanu Prakash Gollapudi <bprakash@broadcom.com>
Signed-off-by: NJames Bottomley <JBottomley@Parallels.com>

Signed-off-by: NBhanu Prakash Gollapudi <bprakash@broadcom.com>
Signed-off-by: NJames Bottomley <JBottomley@Parallels.com>

Signed-off-by: NBhanu Prakash Gollapudi <bprakash@broadcom.com>
Signed-off-by: NJames Bottomley <JBottomley@Parallels.com>

Driver advertises its support for 'retry' bit and 'conf completion' bit in PRLI
params to enable support for 'sequence level error recovery'
Signed-off-by: NBhanu Prakash Gollapudi <bprakash@broadcom.com>
Signed-off-by: NJames Bottomley <JBottomley@Parallels.com>

Program the firmware task structure with init_flags indicating the device is
'sequence level error recovery' capable.
Signed-off-by: NBhanu Prakash Gollapudi <bprakash@broadcom.com>
Signed-off-by: NJames Bottomley <JBottomley@Parallels.com>

Driver decides to initiate REC on REC_TOV timer pop. The firmware maintains the
REC timer and informs the driver as a firmware error message, which is an
unsolicited event to the driver. Driver also issues REC on other unsolicited
events from firmware that indicate data loss.
Signed-off-by: NBhanu Prakash Gollapudi <bprakash@broadcom.com>
Signed-off-by: NJames Bottomley <JBottomley@Parallels.com>

Signed-off-by: NBhanu Prakash Gollapudi <bprakash@broadcom.com>
Signed-off-by: NJames Bottomley <JBottomley@Parallels.com>

For the devices that support sequence level error recovery, based on the REC
response, the firmware has to be informed about the offset from which the
retransmission should happen. Driver initiates sequence cleanup task to
firmware so that the firmware can program the task. Upon the sequence cleanup
completion, SRR is issued to retransmit the sequence.
Signed-off-by: NBhanu Prakash Gollapudi <bprakash@broadcom.com>
Signed-off-by: NJames Bottomley <JBottomley@Parallels.com>

rdac hardware handler assumes that there is one-to-one relation ship
between the host and the controller w.r.t lun.  IOW, it does not
support "multiple storage partitions" within a storage.

Example:
HBA1 and HBA2 see lun 0 and 1 in storage A (1)
HBA3 and HBA4 see lun 0 and 1 in storage A (2)
HBA5 and HBA6 see lun 0 and 1 in storage A (3)

luns 0 and 1 in (1), (2) and (3) are totally different.

But, rdac handler treats the lun 0s (and lun 1s) as the same when
sending a mode select to the controller, which is wrong.

This patch makes the rdac hardware handler associate HBA and the
storage w.r.t lun (and not the host itself).
Signed-off-by: NChandra Seetharaman <sekharan@us.ibm.com>
Signed-off-by: NJames Bottomley <JBottomley@Parallels.com>

The out_msi_disable label should be before cleanup_nomem to additionally
benefit from the call to iounmap.  Subsequent gotos are adjusted to go to
out_msi_disable instead of cleanup_nomem, which now follows it.  This is
safe because pci_disable_msi does nothing if pci_enable_msi was not called.

A simplified version of the semantic match that finds this problem is as
follows: (http://coccinelle.lip6.fr/)

// <smpl>
@r@
expression e1,e2;
statement S;
@@

e1 = pci_ioremap_bar(...);
... when != e1 = e2
    when != iounmap(e1)
    when any
(
 if (<+...e1...+>) S
|
 if(...) { ... return 0; }
|
 if (...) { ... when != iounmap(e1)
                when != if (...) { ... iounmap(e1) ... }
* return ...;
 } else S
)
// </smpl>
Signed-off-by: NJulia Lawall <julia@diku.dk>
Acked-by: NBrian King <brking@linux.vnet.ibm.com>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NJames Bottomley <JBottomley@Parallels.com>

There's a code path in pmcraid that can be reached via device ioctl that
causes all sorts of ugliness, including heap corruption or triggering the
OOM killer due to consecutive allocation of large numbers of pages.

First, the user can call pmcraid_chr_ioctl(), with a type
PMCRAID_PASSTHROUGH_IOCTL.  This calls through to
pmcraid_ioctl_passthrough().  Next, a pmcraid_passthrough_ioctl_buffer
is copied in, and the request_size variable is set to
buffer->ioarcb.data_transfer_length, which is an arbitrary 32-bit
signed value provided by the user.  If a negative value is provided
here, bad things can happen.  For example,
pmcraid_build_passthrough_ioadls() is called with this request_size,
which immediately calls pmcraid_alloc_sglist() with a negative size.
The resulting math on allocating a scatter list can result in an
overflow in the kzalloc() call (if num_elem is 0, the sglist will be
smaller than expected), or if num_elem is unexpectedly large the
subsequent loop will call alloc_pages() repeatedly, a high number of
pages will be allocated and the OOM killer might be invoked.

It looks like preventing this value from being negative in
pmcraid_ioctl_passthrough() would be sufficient.
Signed-off-by: NDan Rosenberg <drosenberg@vsecurity.com>
Cc: <stable@kernel.org>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NJames Bottomley <JBottomley@Parallels.com>

If expander discovery fails (sas_discover_expander()), remove the
expander from the port device list (sas_ex_discover_expander()),
before freeing it. Else the list is corrupted and, e.g., when we
attempt to send SMP commands to other devices, the kernel oopses.
Signed-off-by: NLuben Tuikov <ltuikov@yahoo.com>
Cc: stable@kernel.org
Reviewed-by: NJack Wang <jack_wang@usish.com>
Signed-off-by: NJames Bottomley <JBottomley@Parallels.com>

Signed-off-by: NAdam Radford <aradford@gmail.com>
Signed-off-by: NJames Bottomley <JBottomley@Parallels.com>

Signed-off-by: NAdam Radford <aradford@gmail.com>
Signed-off-by: NJames Bottomley <JBottomley@Parallels.com>

Signed-off-by: NAdam Radford <aradford@gmail.com>
Signed-off-by: NJames Bottomley <JBottomley@Parallels.com>

Based on PRLI response, identify if the target is FCP-2 (seq level error
recovery) capable, and appropriately set the corresponding CONF, REC flags when
offloading the session.
Signed-off-by: NBhanu Prakash Gollapudi <bprakash@broadcom.com>
Signed-off-by: NJames Bottomley <JBottomley@Parallels.com>

Currently, bnx2fc has a hba structure that can work with only a single vlan
interface.  When there is a change in vlan id, it does not have the capability
to switch to different vlan interface. To solve this problem, a new structure
called 'interface' has been introduced, and each hba can now have multiple
interfaces, one per vlan id.

Most of the patch is a moving the interface specific fields from hba to the
interface structure, and appropriately modifying the dereferences. A list of
interfaces (if_list) is maintained along with adapter list. During a create
call, the interface structure is allocated and added to if_list and deleted &
freed on a destroy call.  Link events are propagated to all interfaces
belonging to the hba.
Signed-off-by: NBhanu Prakash Gollapudi <bprakash@broadcom.com>
Signed-off-by: NJames Bottomley <JBottomley@Parallels.com>

In a shared SAS setup, target devices may be reset by one of
several hosts, and outstanding commands on that device will be
completed to corresponding hosts with status of UNSOLICITED_ABORT.
Such commands should be retried instead of being treated as i/o
errors.  Also fixed a nearby spelling error.
Signed-off-by: NStephen M. Cameron <scameron@beardog.cce.hp.com>
Signed-off-by: NJames Bottomley <JBottomley@Parallels.com>

Most smartarrays tolerate it, but a few new ones don't.
Without this change some newer Smart Arrays will lock up
and i/o will grind to a halt.
Signed-off-by: NStephen M. Cameron <scameron@beardog.cce.hp.com>
Cc: stable@kernel.org
Signed-off-by: NJames Bottomley <JBottomley@Parallels.com>