If ioc->pci_error_recovery is set, goto out in mpt2sas_base_hard_reset_handler()
leads to unlock unheld ioc->reset_in_progress_mutex.

The patch fixes the issue by jumping afer mutex_unlock() call.

Found by Linux Driver Verification project (linuxtesting.org).
Signed-off-by: NAlexey Khoroshilov <khoroshilov@ispras.ru>
Acked-by: N"Nandigama, Nagalakshmi" <Nagalakshmi.Nandigama@lsi.com>
Signed-off-by: NJames Bottomley <JBottomley@Parallels.com>

Rename the "Mac ESP" irq as "ESP" to be consistent with all the other Mac
drivers and ESP drivers.
Signed-off-by: NFinn Thain <fthain@telegraphics.com.au>
Signed-off-by: NGeert Uytterhoeven <geert@linux-m68k.org>

Don't enable the SCSI irq when initialising the chip -- the irq has no
handler yet.
Signed-off-by: NFinn Thain <fthain@telegraphics.com.au>
Signed-off-by: NGeert Uytterhoeven <geert@linux-m68k.org>

The fcp timer is already initialized when it gets allocated.
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>

Move the definition of the global variable fcoe_debug_logging
from fcoe.h to fcoe.c. Avoid that sparse complains about missing
declarations for local functions or variables by declaring these
static.
Signed-off-by: NBart Van Assche <bvanassche@acm.org>
Reviewed-by: NYi Zou <yi.zou@intel.com>
Signed-off-by: NRobert Love <robert.w.love@intel.com>
Signed-off-by: NJames Bottomley <JBottomley@Parallels.com>

Avoid that sparse complains about missing declarations for local
functions by declaring these static or by adding an #include directive.
Add the __percpu annotation where it is missing.
Signed-off-by: NBart Van Assche <bvanassche@acm.org>
Reviewed-by: NYi Zou <yi.zou@intel.com>
Signed-off-by: NRobert Love <robert.w.love@intel.com>
Signed-off-by: NJames Bottomley <JBottomley@Parallels.com>

This is a regression introduced by commit
1ff9918b The else statement here is breaking
the initiator logic of allocating xid from the offloaded em xid pool for READ
I/O only to use DDP, as shown by the snippet of trace below, where the WRITE
is using xid 0x5 from the offloaded em xid pool:

Protocol VID Len S_ID        D_ID     OX_ID  RX_ID  Summary
..
*FCP     228 96  0b.08.01 -> 01.0f.00 0x0005 0xffff SCSI: Write(10) LUN: 0x00
 FCP     228 76  01.0f.00 -> 0b.08.01 0x0005 0x828d XFER_RDY
...

The bug is in the else statement, for both initiator and target, the
new command will have FC frame header bit 23 (FC_FC_EX_CTX) cleared as it was
originated from the initiator. Also, this is assuming the frame header is
already filled up, which is only true for target since for initiator, this is a
new frame and oem_match gets called when em tries get xid for this i/o before
it is filled up and sent out.

The fix is to check if there is a fc_fcp_pkt associated w/ this frame from
fr_fsp(fp), since fr_fsp(fp) is NULL for tcm_fc target and non-I/O frame in
initiator. This should also return true for target only if it is an
FC_RCTL_DD_UNSOL_CMD and rx_id is not allocated.
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: NVikas Chaudhary <vikas.chaudhary@qlogic.com>
Signed-off-by: NJames Bottomley <JBottomley@Parallels.com>

Beautify modinfo display. Display correct info for ql4xextended_error_logging

[jejb: fixup checkpatch warning]
Signed-off-by: NKaren Higgins <karen.higgins@qlogic.com>
Signed-off-by: NVikas Chaudhary <vikas.chaudhary@qlogic.com>
Reviewed-by: NMike Christie <michaelc@cs.wisc.edu>
Signed-off-by: NJames Bottomley <JBottomley@Parallels.com>

This patch fix kernel panic during kdump.
Signed-off-by: NSarang Radke <sarang.radke@qlogic.com>
Signed-off-by: NVikas Chaudhary <vikas.chaudhary@qlogic.com>
Reviewed-by: NMike Christie <michaelc@cs.wisc.edu>
Signed-off-by: NJames Bottomley <JBottomley@Parallels.com>

Added debug print with error code in case of firmware error.
Signed-off-by: NNilesh Javali <nilesh.javali@qlogic.com>
Signed-off-by: NVikas Chaudhary <vikas.chaudhary@qlogic.com>
Reviewed-by: NMike Christie <michaelc@cs.wisc.edu>
Signed-off-by: NJames Bottomley <JBottomley@Parallels.com>

In case of FW hung  ISP82xx generates continuous pause frames
which causes switch to disable port.
Added fix to disable generating pause frames in case of
FW hung
Signed-off-by: NGiridhar Malavali <giridhar.malavali@qlogic.com>
Signed-off-by: NVikas Chaudhary <vikas.chaudhary@qlogic.com>
Reviewed-by: NMike Christie <michaelc@cs.wisc.edu>
Signed-off-by: NJames Bottomley <JBottomley@Parallels.com>

During watchdog, need to monitor temperature of ISP82XX core
and set device state to FAILED when temperature reaches
"Panic" level.
Signed-off-by: NMike Hernandez <michael.hernandez@qlogic.com>
Signed-off-by: NVikas Chaudhary <vikas.chaudhary@qlogic.com>
Reviewed-by: NMike Christie <michaelc@cs.wisc.edu>
Signed-off-by: NJames Bottomley <JBottomley@Parallels.com>

There's a zero day mistake in the megaraid driver in that the code that
obtains the version number does a >> 8 on a char quantity.  This >>8 causes a
sparse warning because it always produces zero.  Al Viro suggested these
shifts should be >> 4 thus treating the firmware version as a BCD quantity.
However, in the interests of safety we've elected to replace the >> 8
quantities with an explicit zero, thus quieting the sparse warning while
preserving the same (albeit incorrect) version number as had previously been
seen.
Signed-off-by: NAdam Radford <aradford@gmail.com>
Signed-off-by: NJames Bottomley <JBottomley@Parallels.com>

Instead of open coding this function use kstrtoul_from_user() directly.
Signed-off-by: NStephen Boyd <sboyd@codeaurora.org>
Acked-by: NDouglas Gilbert <dgilbert@interlog.com>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NJames Bottomley <JBottomley@Parallels.com>

The sdev is deleted from starved list and then try to dispatch from this
device. It's quite possible the sdev can't eventually dispatch a request,
then the sdev will be in starved list tail. This isn't fair.
There are two cases here:
1. unplug path. scsi_request_fn() calls to scsi_target_queue_ready(), then
the dev is removed from starved list, but quite possible host queue isn't
ready, the dev is moved to starved list without dispatching any request.
2. scsi_run_queue path. It deletes the dev from starved list first (both
global and local starved lists), then handles the dev. Then we could have
the same process like case 1.

This patch fixes the first case. Case 2 isn't fixed, because there is a
rare case scsi_run_queue finds host isn't busy but scsi_request_fn finds
host is busy (other CPU is faster to get host queue depth). Not deleting
the dev from starved list in scsi_run_queue will keep scsi_run_queue
looping (though this is very rare case, because host will become busy).
Fortunately fixing case 1 already gives big improvement for starvation in
my test. In a 12 disk JBOD setup, running file creation under EXT4, this
gives 12% more throughput.
Signed-off-by: NShaohua Li <shaohua.li@intel.com>
Signed-off-by: NJames Bottomley <JBottomley@Parallels.com>

When expander connected in x2 or x4 mode and with IO runnning, if
a cable from wideport is plugged out from the phy, IO's start failing
on all the targets.

Observed that when cable is pulled with IO running, cominit is
happening on all the links and IO's start dropping to 0 and eventually
the whole IO fails. Second observation, target is trying to open and
SCU is responding with "Open reject no destination".

A cause of the problem is when the port went from the "ready
configuring substate" back to "ready configuring substate" as a result
of phy being pulled off, scic suspended the port task scheduler
register. As a result no IO was allowed and in the "substate
configuring enter" routine the IO never goes back to 0. As a result
the port never comes out of "ready substate configuring".

The patch adds a mechanism of activate and deactivate phy when a port
link up, which fixes the problem.
Signed-off-by: NBartek Nowakowski <bartek.nowakowski@intel.com>
Signed-off-by: NMaciej Trela <maciej.trela@intel.com>
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>

Split scu_link_layer_start_oob function to reset and enable and
add flush after all steps.
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>

When the first phy of a wide port comes up, don't report the port ready
yet, always wait for 250 miliseconds then config the port with all phys
added to the port. So that we can avoid reporting wide port device too
early to kernel, which caused the first IOs (report luns, inquirys)
failed due to not all the phys are configured into its port. Changes
also made that the phys in a wide port don't need to go through half
second wait time for consuming power.
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>

When hot insert the wide port device through the mini-sas port,
the first IOs (Report Luns or Inquiry) may fail due to the device
trying to open to a SCU phy that is still in suspended state. This
IO failure causes the wide port device stuck in UPDATING_PORT_WIDTH
state.
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>

Arrange for task_contexts prepared for the wide targets to account for
all the attached phys in the port.
Signed-off-by: NBartek Nowakowski <bartek.nowakowski@intel.com>
Signed-off-by: NDan Williams <dan.j.williams@intel.com>
Signed-off-by: NJames Bottomley <JBottomley@Parallels.com>

Failure seen pulling a cable from a x4 port configured in manual port
configuration (MPC) mode (MPC mode is set by the the OEM paramaters
provided by the platform or isci_firmware.bin).  While IO running to
devices behind and expander, plugging out the cable from phy is causing
IO failures and IO drops on disks and never recover.

It happens because during link up/down the phy were being taken out of
the port.

Fix: during link down the phy is kept in the same logical port.
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>

Bump the version now that the driver has atapi support and the initial
round of hotplug fixes.  The EXPERIMENTAL tag should have been removed a
while back.  While we're here also kill the "select SCSI_SAS_HOST_SMP"
as the build error was separately fixed by commit d962480e "[SCSI]
libsas: fix try_test_sas_gpio_gp_bit() build error".
Signed-off-by: NDan Williams <dan.j.williams@intel.com>
Signed-off-by: NJames Bottomley <JBottomley@Parallels.com>

As the field was never set, isci_print_tmf() using 'isci_tmf->device'
sometimes causes a kernel crash if the dev_dbg() statement is enabled.
Remove the unused field both from isci_tmf struct definition and from
isci_print_tmf()
Signed-off-by: NMaciej Trela <maciej.trela@intel.com>
Signed-off-by: NDan Williams <dan.j.williams@intel.com>
Signed-off-by: NJames Bottomley <JBottomley@Parallels.com>

Gen-3 operation is marginal, default to gen-2 for now.
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>

"No task timeout timer reduced from 20 to 2 This timer controls how
long the SCU hardware will hold open the TX side of the connection
before sending a DONE.  The timer allows the hardware to attempt to
optimize the DONE/CLOSE behavior to allow for new COMMAND IU to be
posted.  In practice closing the connection quicker is better."
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>

v1.3 allows the attenuation of the attached cables to be specified to
the driver in terms of 'short', 'medium', and 'long' (see probe_roms.h).
These settings (per phy) are retrieved from the platform oem-parameters
(BIOS rom) or via a module parameter override.
Reviewed-by: NJiangbi Liu <jiangbi.liu@intel.com>
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>

v1.1 allows finer grained tuning of the SSC (spread-spectrum-clocking)
settings for SAS and SATA.  See notes in probe_roms.h
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>

C1 silicon requires updates to the phy tuning recipe and also support
for user provided cable selects (per-phy) for short, medium, and long
cables.  Default to 'short' awaiting support for selecting the cable via
oem parameters.
Reviewed-by: NJiangbi Liu <jiangbi.liu@intel.com>
Signed-off-by: NMarcin Tomczak <marcin.tomczak@intel.com>
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>

Before updating the code to support the latest platform updates and
silicon revision cleanup some of the long deref chains.
Signed-off-by: NDan Williams <dan.j.williams@intel.com>
Signed-off-by: NJames Bottomley <JBottomley@Parallels.com>

This parameter blob and generator program have been moved to the
linux-firmware.git repository.
Signed-off-by: NBen Hutchings <ben@decadent.org.uk>
Signed-off-by: NDan Williams <dan.j.williams@intel.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>

This code has never worked correctly, doesn't disable interrupts when
set as a module parameter, doesn't disable interrupts when set after
driver load time in sysfs node, etc.
Signed-off-by: NAdam Radford <aradford@gmail.com>
Signed-off-by: NJames Bottomley <JBottomley@Parallels.com>

Mask off flags in the ioctl path to prevent memory scribble with older MegaCLI
versions.
Signed-off-by: NAdam Radford <aradford@gmail.com>
Signed-off-by: NJames Bottomley <JBottomley@Parallels.com>

The following patch for megaraid_sas fixes the reglockFlags field for
degraded raid5/6 for MR9360/9380, which will result in a performance
improvement.
Signed-off-by: NAdam Radford <aradford@gmail.com>
Signed-off-by: NJames Bottomley <JBottomley@Parallels.com>

Don't call kthread_stop with a spin lock held and interrupts
disabled because kthread_stop will sleep waiting for the thread
to stop.
Signed-off-by: NStephen M. Cameron <scameron@beardog.cce.hp.com>
Signed-off-by: NJames Bottomley <JBottomley@Parallels.com>

This patch fixes a bug where devloss is not called on fc_host teardown.
The issue is seen if the LLDD uses rport_rolechg to add the target role
to an rport.

When an rport goes away, the LLDD will call fc_remote_port_delete, which
will start the devloss timer.  If the timer expires, the transport will
call the devloss callback and set the FC_RPORT_DEVLOSS_CALLBK_DONE flag.
However, the rport structure is not deleted, it is retained to store the
SCSI id mappings for the rport in case it comes back. In the scenario
where it does come back, and the driver calls fc_remote_port_add, but does
not indicate the "target" role for the rport - the create will clear the
structure, but forgets to clear FC_RPORT_DEVLOSS_CALLBK_DONE flag (which
is cleared if it's added with the target role). The secondary call, of
fc_remote_port_rolechg to add the target role also does not clear the flag.
Thus, the next time the rport goes away, the resulting devloss timer
expiration will not call the driver callback as the flag is still set.

This patch adds the FC_RPORT_DEVLOSS_CALLBK_DONE flags to the list of
those that are cleared upon reuse of the rport structure.
Signed-off-by: NAlex Iannicelli <alex.iannicelli@emulex.com>
Signed-off-by: NJames Smart <james.smart@emulex.com>
Signed-off-by: NJames Bottomley <JBottomley@Parallels.com>

Linux allows executing the SG_IO ioctl on a partition or LVM volume, and
will pass the command to the underlying block device.  This is
well-known, but it is also a large security problem when (via Unix
permissions, ACLs, SELinux or a combination thereof) a program or user
needs to be granted access only to part of the disk.

This patch lets partitions forward a small set of harmless ioctls;
others are logged with printk so that we can see which ioctls are
actually sent.  In my tests only CDROM_GET_CAPABILITY actually occurred.
Of course it was being sent to a (partition on a) hard disk, so it would
have failed with ENOTTY and the patch isn't changing anything in
practice.  Still, I'm treating it specially to avoid spamming the logs.

In principle, this restriction should include programs running with
CAP_SYS_RAWIO.  If for example I let a program access /dev/sda2 and
/dev/sdb, it still should not be able to read/write outside the
boundaries of /dev/sda2 independent of the capabilities.  However, for
now programs with CAP_SYS_RAWIO will still be allowed to send the
ioctls.  Their actions will still be logged.

This patch does not affect the non-libata IDE driver.  That driver
however already tests for bd != bd->bd_contains before issuing some
ioctl; it could be restricted further to forbid these ioctls even for
programs running with CAP_SYS_ADMIN/CAP_SYS_RAWIO.

Cc: linux-scsi@vger.kernel.org
Cc: Jens Axboe <axboe@kernel.dk>
Cc: James Bottomley <JBottomley@parallels.com>
Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
[ Make it also print the command name when warning - Linus ]
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Introduce a wrapper around scsi_cmd_ioctl that takes a block device.

The function will then be enhanced to detect partition block devices
and, in that case, subject the ioctls to whitelisting.

Cc: linux-scsi@vger.kernel.org
Cc: Jens Axboe <axboe@kernel.dk>
Cc: James Bottomley <JBottomley@parallels.com>
Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

module_param(bool) used to counter-intuitively take an int.  In
fddd5201 (mid-2009) we allowed bool or int/unsigned int using a messy
trick.

It's time to remove the int/unsigned int option.  For this version
it'll simply give a warning, but it'll break next kernel version.
Acked-by: NMauro Carvalho Chehab <mchehab@redhat.com>
Signed-off-by: NRusty Russell <rusty@rustcorp.com.au>