As Jenx Axboe explained to me: "In earlier times (2.6.18 and pre, iirc), Linux
disabled IO and mem bars on pci_disable_device(). Now in newer kernel it does
not. And in the newer kernels you run into problems if you DON'T disable the
device on exit, since when it later loads the device is already in the enabled
state - and pci_enable_device() then does nothing. This typically screws
MSI/MSI-X." This is what the big scary comment that says pci_disable_device
does "something nasty" to smart arrays was evidently referring to.

If pci_disable_device is not called on driver rmmod, subsequently insmod'ing
the driver may in result in some cases fail to be able to receive interrupts,
esp.  if other drivers are loaded between unloading and loading hpsa.
Signed-off-by: NStephen M. Cameron <scameron@beardog.cce.hp.com>
Signed-off-by: NJames Bottomley <JBottomley@Parallels.com>

Use check_signature to find a signature in the mmio address.
Signed-off-by: NAkinobu Mita <akinobu.mita@gmail.com>
Acked-by: NMike Miller <mike.miller@hp.com>
Signed-off-by: NJames Bottomley <JBottomley@Parallels.com>

Some other older controllers also do have problems to perform a kdump.
Adding controllers to this list means that the driver will signal
this non-ability via a resettable flag correctly.
The unsupported list was created after a consultation with HP.
Signed-off-by: NTomas Henzl <thenzl@redhat.com>
Acked-by: NMike Miller <mike.miller@hp.com>
Signed-off-by: NJames Bottomley <JBottomley@Parallels.com>

Use find_first_zero_bit to find the first cleared bit in a memory region.

This also includes the following minor changes.
- Use bitmap_zero
- Reduce unnecessary atomic bitops usage
Signed-off-by: NAkinobu Mita <akinobu.mita@gmail.com>
Acked-by: NStephen M. Cameron <scameron@beardog.cce.hp.com>
Signed-off-by: NJames Bottomley <JBottomley@Parallels.com>

Certain types of changes to devices should not be interpreted as a device
change that would cause the device to be removed and re-added.  These include
RAID level and Firmware revision changes.  However, these attribute changes DO
need to be reflected in the controller info structure's dev structure list, so
that sysfs and /proc info files for the devices will reflect the new values.
Signed-off-by: NScott Teel <scott.stacy.teel@hp.com>
Acked-by: NStephen M. Cameron <scameron@beardog.cce.hp.com>
Signed-off-by: NJames Bottomley <JBottomley@Parallels.com>

Reduce confusion and inaccuracy caused by dated naming of vars and functions
referring to external target devices.

CURRENT NAMING:                PROPOSED NAMING:

"MSA2xxx devices"              "external target devices"
msa2xxx_model                  ext_target_model
is_msa2xxx                     is_ext_target
add_msa2xxx_enclosure          add_ext_target_dev
nmsa2xxx_enclosures            n_ext_target_devs
Signed-off-by: NScott Teel <scott.teel@hp.com>
Signed-off-by: NStephen M. Cameron <scameron@beardog.cce.hp.com>
Signed-off-by: NJames Bottomley <JBottomley@Parallels.com>

Driver limits SAS external target IDs to range 1-8.
Need to increase limit and clean up overlapping concepts of targets and paths
in the code.

There are several defined constants that control this:
HPSA_MAX_TARGETS_PER_CTLR     16
MAX_MSA2XXX_ENCLOSURES        32
HPSA_MAX_PATHS                8

We can condense this to one constant:
MAX_EXT_TARGETS               32

SAS switches allow for 8 connections, and there is capacity for 4 switches per
enclosure in largest blade enclosure type.
Signed-off-by: NScott Teel <scott.teel@hp.com>
Signed-off-by: NStephen M. Cameron <scameron@beardog.cce.hp.com>
Signed-off-by: NJames Bottomley <JBottomley@Parallels.com>

It should call hpsa_set_bus_target_lun rather
than individually setting bus, target and lun.
Signed-off-by: NStephen M. Cameron <scameron@beardog.cce.hp.com>
Signed-off-by: NJames Bottomley <JBottomley@Parallels.com>

Some distros have a "rescan-scsi-bus.sh" script which depends on
SCSI REPORT LUNs not reporting something different than what the
driver tells the kernel, even if the driver uses scan_start and
scan_finished methods of the SCSI host template to override the
usual SCSI midlayer discovery code.  Previously, 1 was added to
the LUN to make room to insert the RAID controller device at
LUN 0.  Now, the RAID controller is moved to bus 3, and 1 is no
longer added to the LUN.  However, SCSI REPORT LUNS on Smart Array
doesn't report physical devices like tape drives or auto-loaders
as it turns out, so those particular device types still won't match.
Generally the logical drives are reported first however, so at
least those should match.
Signed-off-by: NStephen M. Cameron <scameron@beardog.cce.hp.com>
Signed-off-by: NJames Bottomley <JBottomley@Parallels.com>

Upgraded firmware on Smart Array P7xx (and some others) made them show up as
SCSI revision 5 devices and this caused the driver to fail to map MSA2xxx
logical drives to the correct bus/target/lun.  A symptom of this would be that
the target ID of the logical drives as presented by the external storage array
is ignored, and all such logical drives are assigned to target zero,
differentiated only by LUN.  Some multipath software reportedly does not deal
well with this behavior, failing to recognize different paths to the same
device as such.
Signed-off-by: NStephen M. Cameron <scameron@beardog.cce.hp.com>
Signed-off-by: NScott Teel <scott.teel@hp.com>
Signed-off-by: NJames Bottomley <JBottomley@Parallels.com>

Sometimes, for testing purposes (e.g. testing rmmod on a system
that normally boots using hpsa) it's nice to rename the driver
and split it into two drivers and restrict it to certain
controllers.  This makes that easier.
Signed-off-by: NStephen M. Cameron <scameron@beardog.cce.hp.com>
Signed-off-by: NJames Bottomley <JBottomley@Parallels.com>

hpsa_register_scsi just calls hpsa_scsi_detect.  Move
the guts of hpsa_scsi_detect into hpsa_register_scsi and
get rid of hpsa_scsi_detect.
Signed-off-by: NStephen M. Cameron <scameron@beardog.cce.hp.com>
Signed-off-by: NJames Bottomley <JBottomley@Parallels.com>

[SCSI] hpsa: removed unneeded structure member max_sg_entries and fix badly named constant MAXSGENTRIES

We had both h->max_sg_entries and h->maxsgentries in the per controller
structure which is terribly confusing.  max_sg_entries was really
just a constant, 32, which defines how big the "block fetch table"
is, which is as large as the max number of SG elements embedded
within a command (excluding SG elements in chain blocks).

MAXSGENTRIES was the constant used to denote the max number of SG
elements embedded within a command, also a poor name.

So renamed MAXSGENTREIS to SG_ENTRIES_IN_CMD, and removed
h->max_sg_entries and replaced it with SG_ENTRIES_IN_CMD.

h->maxsgentries is unchanged, and is the maximum number of sg
elements the controller will support in a command, including
those in chain blocks, minus 1 for the chain block pointer..
Signed-off-by: NStephen M. Cameron <scameron@beardog.cce.hp.com>
Signed-off-by: NJames Bottomley <JBottomley@Parallels.com>

Signed-off-by: NStephen M. Cameron <scameron@beardog.cce.hp.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>

The '5i' controller freezes when a kdump is attemted.
This patch admits it and adds the controller
to the unresetable list.
Signed-off-by: NTomas Henzl <thenzl@redhat.com>
Signed-off-by: NJames Bottomley <JBottomley@Parallels.com>

IRQF_SHARED is required for older controllers that don't support MSI(X)
and which may end up sharing an interrupt.  All the controllers hpsa
normally supports have MSI(X) capability, but older controllers may be
encountered via the hpsa_allow_any=1 module parameter.

Also remove deprecated IRQF_DISABLED.
Signed-off-by: NStephen M. Cameron <scameron@beardog.cce.hp.com>
Signed-off-by: NJames Bottomley <JBottomley@Parallels.com>

The Windows driver .inf disables ASPM on hpsa devices. Do the same because the
selection of a non default ASPM policy can cause the device to hang.
Signed-off-by: NMatthew Garrett <mjg@redhat.com>
Cc: stable@kernel.org
Acked-by: NMike Miller <mike.miller@hp.com>
Signed-off-by: NJames Bottomley <JBottomley@Parallels.com>

When controller lockup condition is detected,
we should fail all outstanding commands and disable
the controller.  This will enable multipath solutions
to recover gracefully.
Signed-off-by: NStephen M. Cameron <scameron@beardog.cce.hp.com>
Signed-off-by: NJames Bottomley <JBottomley@Parallels.com>

We weren't filling in the transfer length of the
flush cache command (it transfers 4 bytes of zeroes).
Firmware didn't seem to be bothered by this, but it
should be fixed.
Signed-off-by: NStephen M. Cameron <scameron@beardog.cce.hp.com>
Signed-off-by: NJames Bottomley <JBottomley@Parallels.com>

The currentsd[] array in hpsa_update_scsi_devices had room for
256 devices.  The code was iterating over however many physical
and logical devices plus an additional number of possible external
MSA2XXX controllers, which together could potentially exceed 256.

We increased the size of the currentsd array to 1024 + 1024 + 32 + 1
elements to reflect a reasonable maximum possible number of devices
which might be encountered.  We also don't just walk off the end
of the array if the array controller reports more devices than we
are prepared to handle, we just ignore the excessive devices.
Signed-off-by: NScott Teel <scott.teel@hp.com>
Signed-off-by: NStephen M. Cameron <scameron@beardog.cce.hp.com>
Signed-off-by: NJames Bottomley <JBottomley@Parallels.com>

Rename HPSA_MAX_SCSI_DEVS_PER_HBA to HPSA_MAX_DEVICES
Signed-off-by: NScott Teel <scott.teel@hp.com>
Signed-off-by: NStephen M. Cameron <scameron@beardog.cce.hp.com>
Signed-off-by: NJames Bottomley <JBottomley@Parallels.com>

Signed-off-by: NStephen M. Cameron <scameron@beardog.cce.hp.com>
Signed-off-by: NJames Bottomley <JBottomley@Parallels.com>

Set the max hardware sectors in the SCSI host template to 8192
to allow for larger i/o's (8192 is the same limit the cciss
driver currently has.)
Signed-off-by: NStephen M. Cameron <scameron@beardog.cce.hp.com>
Signed-off-by: NJames Bottomley <JBottomley@Parallels.com>

The P600 requires a small delay when changing states. Otherwise we may think
the board did not reset and we bail. This for kdump only and is particular
to the P600.
Signed-off-by: NMike Miller <mike.miller@hp.com>
Cc: stable@kernel.org
Signed-off-by: NJens Axboe <axboe@kernel.dk>

The following warning message may be confusing to some users:

dev_warn(&pdev->dev, "Controller claims that "
		"'Bit 2 doorbell reset' is "
		"supported, but not 'bit 5 doorbell reset'.  "
		"Firmware update is recommended.\n");

Most users don't know or care what bit we may be hitting. Also change
"recommended" to "required."
Signed-off-by: NMike Miller <mike.miller@hp.com>
Signed-off-by: NJames Bottomley <JBottomley@Parallels.com>

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>

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>

This allows us to move duplicated code in <asm/atomic.h>
(atomic_inc_not_zero() for now) to <linux/atomic.h>
Signed-off-by: NArun Sharma <asharma@fb.com>
Reviewed-by: NEric Dumazet <eric.dumazet@gmail.com>
Cc: Ingo Molnar <mingo@elte.hu>
Cc: David Miller <davem@davemloft.net>
Cc: Eric Dumazet <eric.dumazet@gmail.com>
Acked-by: NMike Frysinger <vapier@gentoo.org>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

This memcpy:

   memcpy(cmd->sense_buffer, ei->SenseInfo,
	   ei->SenseLen > SCSI_SENSE_BUFFERSIZE ?
		   SCSI_SENSE_BUFFERSIZE :
		   ei->SenseLen);

The ei->SenseLen field is filled in by the Smart Array.  For requests to
logical drives, it will not exceed 32 bytes, so should be ok, but for physical
requests it depends on the target device, not the Smart Array.  It's conceivable
that this could exceed the 32 byte size of ei->SenseInfo.  In that case, the memcpy
would read past the end of ei->SenseInfo, copying data from the next command,
as if it were sense data, or, if it happened to be the very last command in the
block of allocated commands, could fall off the end of the allocated area and
crash.  I'm not aware of anyone ever encountering this behavior, but it could
conceivably happen.  This bug was found by Coverity.
Signed-off-by: NStephen M. Cameron <scameron@beardog.cce.hp.com>
Signed-off-by: NJames Bottomley <JBottomley@Parallels.com>

Signed-off-by: NStephen M. Cameron <scameron@beardog.cce.hp.com>
Signed-off-by: NJames Bottomley <JBottomley@Parallels.com>

Not at all sure this is correct or appropriate to change,
but this seems odd.

Found via coccinelle script

@@
type T;
T* ptr;
expression E1;
@@

* memset(E1, 0, sizeof(ptr));
Signed-off-by: NJoe Perches <joe@perches.com>
Acked-by: NStephen M. Cameron <scameron@beardog.cce.hp.com>
Signed-off-by: NJames Bottomley <jbottomley@parallels.com>
Signed-off-by: NJames Bottomley <James.Bottomley@suse.de>

Signed-off-by: NScott Teel <scott.stacy.teel@hp.com>
Signed-off-by: NJames Bottomley <jbottomley@parallels.com>
Signed-off-by: NJames Bottomley <James.Bottomley@suse.de>

Just go straight to the soft-reset method instead.
Signed-off-by: NStephen M. Cameron <scameron@beardog.cce.hp.com>
Signed-off-by: NJames Bottomley <jbottomley@parallels.com>
Signed-off-by: NJames Bottomley <James.Bottomley@suse.de>

Signed-off-by: NStephen M. Cameron <scameron@beardog.cce.hp.com>
Signed-off-by: NJames Bottomley <jbottomley@parallels.com>
Signed-off-by: NJames Bottomley <James.Bottomley@suse.de>

on driver load, if reset_devices is set, and the hard reset
attempts fail, try to bring up the controller to the point that
a command can be sent, and send it a soft reset command, then
after the reset undo whatever driver initialization was done to get
it to the point to take a command, and re-do it after the reset.

This is to get kdump to work on all the "non-resettable" controllers
(except 64xx controllers which can't be reset due to the potentially
shared cache module.)
Signed-off-by: NStephen M. Cameron <scameron@beardog.cce.hp.com>
Signed-off-by: NJames Bottomley <jbottomley@parallels.com>
Signed-off-by: NJames Bottomley <James.Bottomley@suse.de>

The bit-2-doorbell reset method seemed to cause (survivable) NMIs
on some systems and (unsurvivable) IOCK NMIs on some G7 servers.
Firmware guys implemented a new doorbell method to alleviate these
problems triggered by bit 5 of the doorbell register.  We want to
use it if it's available.
Signed-off-by: NStephen M. Cameron <scameron@beardog.cce.hp.com>
Signed-off-by: NJames Bottomley <jbottomley@parallels.com>
Signed-off-by: NJames Bottomley <James.Bottomley@suse.de>

hpsa_scsi_setup at one time contained enough code to justify
its existence, but that time has passed.
Signed-off-by: NStephen M. Cameron <scameron@beardog.cce.hp.com>
Signed-off-by: NJames Bottomley <jbottomley@parallels.com>
Signed-off-by: NJames Bottomley <James.Bottomley@suse.de>

When waiting for the board to become "not ready"
don't print a message saying "waiting for board to
become ready" (possibly followed by a message saying
"failed waiting for board to become not ready".  Instead,
it should be "waiting for board to reset" and "failed
waiting for board to reset."
Signed-off-by: NStephen M. Cameron <scameron@beardog.cce.hp.com>
Signed-off-by: NJames Bottomley <jbottomley@parallels.com>
Signed-off-by: NJames Bottomley <James.Bottomley@suse.de>