The code is changed to support the new dynamic logging infrastructure.
Following are the levels added.
Default is 0 - no logging.  0x40000000 - Module Init & Probe.
0x20000000 - Mailbox Cmnds. 0x10000000 - Device Discovery.
0x08000000 - IO tracing.    0x04000000 - DPC Thread.
0x02000000 - Async events.  0x01000000 - Timer routines.
0x00800000 - User space.    0x00400000 - Task Management.
0x00200000 - AER/EEH.       0x00100000 - Multi Q.
0x00080000 - P3P Specific.  0x00040000 - Virtual Port.
0x00020000 - Buffer Dump.   0x00010000 - Misc.
0x7fffffff - For enabling all logs, can be too many logs.

Setting ql2xextended_error_logging module parameter to any of the above
value, will enable the debug for that particular level.
Do LOGICAL OR of the value to enable more than one level.
Signed-off-by: NSaurav Kashyap <saurav.kashyap@qlogic.com>
Signed-off-by: NGiridhar Malavali <giridhar.malavali@qlogic.com>
Signed-off-by: NAndrew Vasquez <andrew.vasquez@qlogic.com>
Signed-off-by: NJoe Carnuccio <joe.carnuccio@qlogic.com>
Signed-off-by: NChad Dupuis <chad.dupuis@qlogic.com>
Signed-off-by: NMadhuranath Iyengar <Madhu.Iyengar@qlogic.com>
Signed-off-by: NJames Bottomley <JBottomley@Parallels.com>

This patch adds the dynamic logging framework to the qla2xxx driver.
The user will be able to change the logging levels on the fly i.e.
without load/unload of the driver. This also enables logging to be
enabled for a particular section of the driver such as initialization,
device discovery etc.
Signed-off-by: NSaurav Kashyap <saurav.kashyap@qlogic.com>
Signed-off-by: NGiridhar Malavali <giridhar.malavali@qlogic.com>
Signed-off-by: NJames Bottomley <JBottomley@Parallels.com>

During cable pull tests on our 16G FC adapter, we are seeing errors,
typically reads to close targets, which fail due to CRC or framing
errors caused by the cable being pull (return status DID_ERROR).
The adapter detects the error on one of the first frames received,
marks the FC exchange as dead (further frames go to bit bucket) and
signals the host of the error. This action is so quick, and coupled
with fast host CPUs, creates a scenario in which the midlayer sees
the failure and retries the io almost immediately. We've seen link
traces with the retry on the link while the original i/o is still
being processed by the target. We're also seeing the time window
for the "link to pull-apart" and the physical interface to report
disconnected to be in the few millisecond range. Which means, we're
encountering scenarios where the full retry count is exhausted
(all with error) by the midlayer before the link disconnect state
is detected.

We looked at 8G FC behavior and occasionally see the same behavior,
but as the link was slower, it rarely could exhaust all retries
before the link reported disconnect.

What is needed is a slight delay between io retries due to DID_ERROR
to cover this error.  It is inappropriate to put this delay in the
driver, as the error is indistinguishable from other link-related errors,
nor does the driver track whether the io is a retry or not. This is also
easier than tracking between-io-error bursts that are seen in this
scenario.

The patch below updates the retry path so that it inserts a delay as
if the target was busy.  The busy delay is on the order of 6ms. This
delay is sufficient to ensure the link down condition is reported
before the retry count is exhausted (at most 1 retry is seen).
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>

Issue:

This issue is seen on LSI H/W WarpDrive SSS6200 When filed direct I/O
is tried as volume I/O the scmd field in internal lookup table get
cleared and because of that the retried volume I/O never gets reported
as completed to SML.

Result:

I/O timeout and Error handling thread will kicking off

Fix:

Setting back the scmd in the lookup table before retrying the failed
direct i/o
Signed-off-by: NKashyap Desai <kashyap.desai@lsi.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>

Currently it's impossible to find out if the host supports
wide SCSI unless you're committed to trawl through syslog.
And it's near impossible to find the actual HBA id, which
is settable for some SCSI HBAs (like aic7xxx).
So export them via sysfs.
Signed-off-by: NHannes Reinecke <hare@suse.de>
Signed-off-by: NAnkit Jain <jankit@suse.de>
Signed-off-by: NJames Bottomley <JBottomley@Parallels.com>

Add support for interrupt tasklet, which will improve performance.
Correct spelling of "20011"

[jejb: simplified ifdefs and fixed unused variable problem]
Signed-off-by: NXiangliang Yu <yuxiangl@marvell.com>
Signed-off-by: NJames Bottomley <JBottomley@Parallels.com>

Remove obsolete comments and add new comments
Signed-off-by: NXiangliang Yu <yuxiangl@marvell.com>
Signed-off-by: NJames Bottomley <JBottomley@Parallels.com>

Change code to match HBA datasheet.
Change code to make it readable.
Add support big endian for mvs_prd_imt.
Add cpu_to_le32 and cpu_to_le64 to use on addr.
Add scan_finished for structure mvs_prv_info.
Signed-off-by: NXiangliang Yu <yuxiangl@marvell.com>
Signed-off-by: NJames Bottomley <JBottomley@Parallels.com>

Add new macros: MVS_SOFT_RESET, MVS_HARD_RESET, MVS_PHY_TUNE,
	MVS_COMMAND_ACTIVE, EXP_BRCT_CHG, MVS_MAX_SG
Add new member sg_width in struct mvs_chip_info
Use macros rather than magic number
Add new functions: mvs_fill_ssp_resp_iu, mvs_set_sense,
	mvs_94xx_clear_srs_irq, mvs_94xx_phy_set_link_rate
Signed-off-by: NXiangliang Yu <yuxiangl@marvell.com>
Signed-off-by: NJames Bottomley <JBottomley@Parallels.com>

Remove unused macros: VSR_PHY_VS0, VSR_PHY_VS1, MVS_SLOTS,
	MVS_CAN_QUEUE, MVS_MSI, SG_MX, _MV_DUMP, MV_DISABLE_NCQ
Remove unused variables for mvs_info: irq, exp_req, cmd_size
Remove unused functions: mvs_get_sas_addr, mvs_hexdump,
	mvs_hba_sb_dump, mvs_hab_memory_dump, mvs_hba_cq_dump
Signed-off-by: NXiangliang Yu <yuxiangl@marvell.com>
Signed-off-by: NJames Bottomley <JBottomley@Parallels.com>

Fix 94xx A0/B0 revision hotplug issue.
Remove unused macro: DISABLE_HOTPLUG_DMA_FIX
Signed-off-by: NXiangliang Yu <yuxiangl@marvell.com>
Signed-off-by: NJames Bottomley <JBottomley@Parallels.com>

Signed-off-by: NXiangliang Yu <yuxiangl@marvell.com>
Signed-off-by: NJames Bottomley <JBottomley@Parallels.com>

Add 94xx phy tuning to aid manufacturing.
Add support for 94xx multiple revisions: A0, B0, C0, C1, C2.
Signed-off-by: NXiangliang Yu <yuxiangl@marvell.com>
Signed-off-by: NJames Bottomley <JBottomley@Parallels.com>

Signed-off-by: NXiangliang Yu <yuxiangl@marvell.com>
Signed-off-by: NJames Bottomley <JBottomley@Parallels.com>

USB surprise removal of sr is triggering an oops in
scsi_dispatch_command().  What seems to be happening is that USB is
hanging on to a queue reference until the last close of the upper
device, so the crash is caused by surprise remove of a mounted CD
followed by attempted unmount.

The problem is that USB doesn't issue its final commands as part of
the SCSI teardown path, but on last close when the block queue is long
gone.  The long term fix is probably to make sr do the teardown in the
same way as sd (so remove all the lower bits on ejection, but keep the
upper disk alive until last close of user space).  However, the
current oops can be simply fixed by not allowing any commands to be
sent to a dead queue.

Cc: stable@kernel.org
Signed-off-by: NJames Bottomley <JBottomley@Parallels.com>

Some broken devices indicates that media has changed on every
GET_EVENT_STATUS_NOTIFICATION.  This translates into MEDIA_CHANGE
uevent on every open() which lets udev run into a loop.

Verify GET_EVENT result against TUR and if it generates spurious
events for several times in a row, ignore the GET_EVENT events, and
trust only the TUR status.

This is the log of a USB stick with a (broken) fake CDROM drive:

 scsi 5:0:0:0: Direct-Access     SanDisk  U3 Cruzer Micro  8.02 PQ: 0 ANSI: 0 CCS
 sd 5:0:0:0: Attached scsi generic sg3 type 0
 scsi 5:0:0:1: CD-ROM            SanDisk  U3 Cruzer Micro  8.02 PQ: 0 ANSI: 0
 sd 5:0:0:0: [sdb] Attached SCSI removable disk
 sr2: scsi3-mmc drive: 48x/48x tray
 sr 5:0:0:1: Attached scsi CD-ROM sr2
 sr 5:0:0:1: Attached scsi generic sg4 type 5
 sr2: GET_EVENT and TUR disagree continuously, suppress GET_EVENT events
 sd 5:0:0:0: [sdb] 31777279 512-byte logical blocks: (16.2 GB/15.1 GiB)
 sd 5:0:0:0: [sdb] No Caching mode page present
 sd 5:0:0:0: [sdb] Assuming drive cache: write through
 sd 5:0:0:0: [sdb] No Caching mode page present
 sd 5:0:0:0: [sdb] Assuming drive cache: write through
 sdb: sdb1

-tj: Updated to consider only spurious GET_EVENT events among
     different types of disagreement and allow using TUR for kernel
     event polling after GET_EVENT is ignored.

Reported-By: Markus Rathgeb maggu2810@googlemail.com
Signed-off-by: NKay Sievers <kay.sievers@vrfy.org>
Signed-off-by: NTejun Heo <tj@kernel.org>
Cc: stable@kernel.org	# >= v2.6.38, fixes udev busy looping w/ certain devices
Signed-off-by: NJames Bottomley <JBottomley@Parallels.com>

A kernel panic was observed when passing the sc->request->cpu = -1 to
retrieve the per_cpu variable pointer:
 #0 [ffff880011203960] machine_kexec at ffffffff81022bc3
 #1 [ffff8800112039b0] crash_kexec at ffffffff81088630
 #2 [ffff880011203a80] __die at ffffffff8139ea20
 #3 [ffff880011203aa0] no_context at ffffffff8102f3a7
 #4 [ffff880011203ae0] __bad_area_nosemaphore at ffffffff8102f665
 #5 [ffff880011203ba0] retint_signal at ffffffff8139dd1f
 #6 [ffff880011203cc8] bnx2i_indicate_kcqe at ffffffffa03dc4f2
 #7 [ffff880011203da8] service_kcqes at ffffffffa03cb04f
 #8 [ffff880011203e68] cnic_service_bnx2x_kcq at ffffffffa03cb14a
 #9 [ffff880011203e88] cnic_service_bnx2x_bh at ffffffffa03cb1b3

The problem lies in the slow path sg_io (and perhaps sg_scsi_ioctl) call to
blk_get_request->get_request/wait->blk_alloc_request->blk_rq_init which
re-initializes the request->cpu to -1.  There is no assignment for cpu from
that to the request_fn call to low level drivers.

When this happens, the sc->request->cpu will be using the init value of
-1.  This will create a kernel panic when it hits bnx2i because the code
refers it to get the per_cpu variables ptr.

This change is to put in a guard against that and also for cases when
bio affinity/queue completion to the same cpu is not enabled.  In those
cases, the request->cpu will remain a -1 also.

This bug was created from commit:  b5cf6b63

For the case when the blk layer did not setup the request->cpu, bnx2i
will complete the sc with the current CPU of the thread.
Signed-off-by: NEddie Wai <eddie.wai@broadcom.com>
Signed-off-by: NJames Bottomley <JBottomley@Parallels.com>

The bnx2fc driver needs to handle netdev events on VLAN devices.
Signed-off-by: NMichael Chan <mchan@broadcom.com>
Reviewed-by: NBhanu Prakash Gollapudi <bprakash@broadcom.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

All these are instances of
  #define NAME value;
or
  #define NAME(params_opt) value;

These of course fail to build when used in contexts like
  if(foo $OP NAME)
  while(bar $OP NAME)
and may silently generate the wrong code in contexts such as
  foo = NAME + 1;    /* foo = value; + 1; */
  bar = NAME - 1;    /* bar = value; - 1; */
  baz = NAME & quux; /* baz = value; & quux; */

Reported on comp.lang.c,
Message-ID: <ab0d55fe-25e5-482b-811e-c475aa6065c3@c29g2000yqd.googlegroups.com>
Initial analysis of the dangers provided by Keith Thompson in that thread.

There are many more instances of more complicated macros having unnecessary
trailing semicolons, but this pile seems to be all of the cases of simple
values suffering from the problem. (Thus things that are likely to be found
in one of the contexts above, more complicated ones aren't.)
Signed-off-by: NPhil Carmody <ext-phil.2.carmody@nokia.com>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

The rcu callback fc_rport_free_rcu() just calls a kfree(),
so we use kfree_rcu() instead of the call_rcu(fc_rport_free_rcu).
Signed-off-by: NLai Jiangshan <laijs@cn.fujitsu.com>
Signed-off-by: NPaul E. McKenney <paulmck@linux.vnet.ibm.com>
Cc: Robert Love <robert.w.love@intel.com>
Cc: "James E.J. Bottomley" <James.Bottomley@suse.de>
Reviewed-by: NJosh Triplett <josh@joshtriplett.org>

dst_{get,set}_neighbour()
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Signed-off-by: NJames Bottomley <JBottomley@Parallels.com>

The hard_reset parameter passed to the LLDD in the direct-attached
phy control case allows the LLDD to filter link failure events
while the direct-attached device reset is executing.
Signed-off-by: NJeff Skirvin <jeffrey.d.skirvin@intel.com>
Signed-off-by: NDan Williams <dan.j.williams@intel.com>

The messages emitted from task.c and some from request.c likely
duplicate (in a less undertandable way) what is reported by the
midlayer.
Signed-off-by: NDan Williams <dan.j.williams@intel.com>

Perform checking per-pci device (even though all systems will only have
1 pci device in this generation), and delete support for silicon that
does not report a proper revision (i.e. A0).
Reported-by: NChristoph Hellwig <hch@lst.de>
Signed-off-by: NDan Williams <dan.j.williams@intel.com>

Does not need its own file.
Signed-off-by: NDan Williams <dan.j.williams@intel.com>

Undo some needless separation.
Signed-off-by: NDan Williams <dan.j.williams@intel.com>

Most of these simple dereference macros are longer than their open coded
equivalent.  Deleting enum sci_controller_mode is thrown in for good
measure.
Reported-by: NChristoph Hellwig <hch@lst.de>
Signed-off-by: NDan Williams <dan.j.williams@intel.com>

The distinction between scic_sds_ scic_ and sci_ are no longer relevant
so just unify the prefixes on sci_.  The distinction between isci_ and
sci_ is historically significant, and useful for comparing the old
'core' to the current Linux driver. 'sci_' represents the former core as
well as the routines that are closer to the hardware and protocol than
their 'isci_' brethren. sci == sas controller interface.

Also unwind the 'sds1' out of the parameter structs.
Reported-by: NChristoph Hellwig <hch@lst.de>
Signed-off-by: NDan Williams <dan.j.williams@intel.com>

Remove the distinction between these two implementations and unify on
isci_host (local instances named ihost).  Hmmm, we had two
'oem_parameters' instances, one was unused... nice.
Reported-by: NChristoph Hellwig <hch@lst.de>
Signed-off-by: NDan Williams <dan.j.williams@intel.com>

Remove the distinction between these two implementations and unify on
isci_remote_device (local instances named idev).
Reported-by: NChristoph Hellwig <hch@lst.de>
Signed-off-by: NDan Williams <dan.j.williams@intel.com>

Remove the distinction between these two implementations and unify on
isci_port (local instances named iport).  The duplicate '->owning_port' and
'->isci_port' in both isci_phy and isci_remote_device will be fixed in a later
patch... this is just the straightforward rename/unification.
Reported-by: NChristoph Hellwig <hch@lst.de>
Signed-off-by: NDan Williams <dan.j.williams@intel.com>

Commit 0815632 "isci: unify remote_device stop_handlers" introduced the
possibility that not all requests get terminated if we reach the
request_count.  Now that we properly reference count devices we don't
need this self-defense and can do the straightforward scan of all active
requests.
Reported-by: NJeff Skirvin <jeffrey.d.skirvin@intel.com>
Acked-by: NJeff Skirvin <jeffrey.d.skirvin@intel.com>
Signed-off-by: NDan Williams <dan.j.williams@intel.com>

They are one in the same object so remove the distinction.  The near
duplicate fields (owning_port, and isci_port) will be cleaned up
after the scic_sds_port isci_port unification.
Reported-by: NChristoph Hellwig <hch@lst.de>
Signed-off-by: NDan Williams <dan.j.williams@intel.com>

They are one in the same object so remove the distinction.  The near
duplicate fields (owning_controller, and isci_host) will be cleaned up
after the scic_sds_contoller isci_host unification.
Reported-by: NChristoph Hellwig <hch@lst.de>
Signed-off-by: NDan Williams <dan.j.williams@intel.com>

* Rename scic_sds_stp_request to isci_stp_request
* Remove the unused fields and union indirection
Reported-by: NChristoph Hellwig <hch@lst.de>
Signed-off-by: NDan Williams <dan.j.williams@intel.com>

the dma_pool interface is optimized for object_size << page_size which
is not the case with isci_request objects and the dma_pool routines show
up in the top of the profile.

The old io_request_table which tracked whether tci slots were in-flight
or not is replaced with an IREQ_ACTIVE flag per request.
Signed-off-by: NDan Williams <dan.j.williams@intel.com>

Combine three bools into one unsigned long 'flags'.  Doesn't increase the
request size due to packing. (to do: optimize the structure layout).
Signed-off-by: NDan Williams <dan.j.williams@intel.com>

The tci_pool tracks our outstanding command slots which are also the 'index'
portion of our tags.  Grabbing the tag early in ->lldd_execute_task let's us
drop the isci_host_can_queue() and ->was_tag_assigned_by_user infrastructure.
->was_tag_assigned_by_user required the task context to be duplicated in
request-local buffer.  With the tci established early we can build the
task_context directly into its final location and skip a memcpy.

With the task context buffer at a known address at request construction we
have the opportunity/obligation to also fix sgl handling.  This rework feels
like it belongs in another patch but the sgl handling and task_context are too
intertwined.
1/ fix the 'ab' pair embedded in the task context to point to the 'cd' pair in
   the task context (previously we were prematurely linking to the staging
   buffer).
2/ fix the broken iteration of pio sgls that assumes all sgls are relative to
   the request, and does a dangerous looking reverse lookup of physical
   address to virtual address.
Signed-off-by: NDan Williams <dan.j.williams@intel.com>