[SCSI] zfcp: avoid clutter in erp_dbf

avoid clutter in erp_dbf

cleanup zfcp_fsf_req_dismiss functions:
- avoid clutter in erp_dbf (reqs_active is always 0)
- fold called three-line function into calling function
- add meaningful comment
- coding style

Signed-off-by: Martin Peschke <mp3@de.ibm.com>
Signed-off-by: Swen Schillig <swen@vnet.ibm.com>
Signed-off-by: James Bottomley <James.Bottomley@SteelEye.com>
[SCSI] zfcp: IO stall after deleting and path checker changes after reenabling zfcp devices

IO stall after deleting and path checker changes after reenabling zfcp device

Setting one zfcp device offline using chccwdev in a multipath
environment and waiting will lead to IO stall on all paths.
After setting the zfcp device back online using chccwdev,
the devices with io stall will have a different path checker.
Devices corresponding to the deleted units are never freed.
This has the effect that 'slave_destroy' is never called and zfcp
still thinks that this unit is registered
(ZFCP_STATUS_UNIT_REGISTERED is still set). Hence the erp
routine is not called correctly and the unit is not enabled properly.

Do not delete rport and the sdev. Just set the host to block on
'offline'. Setting host online again will then remove the blocked status
and everything is fine again.

Signed-off-by: Michael Loehr <mloehr2@linux.vnet.ibm.com>
Signed-off-by: Swen Schillig <swen@vnet.ibm.com>
Signed-off-by: James Bottomley <James.Bottomley@SteelEye.com>
[SCSI] ipr: Proper return codes for eh_dev_reset for SATA devices

Currently ipr always returns success from eh_dev_reset when
called for a SATA device. If ata_do_eh is unable to recover
for some reason, this can result in commands that are still
outstanding when ata_do_eh returns. Change ipr to verify no
commands are outstanding before returning success.

Signed-off-by: Brian King <brking@linux.vnet.ibm.com>
Signed-off-by: James Bottomley <James.Bottomley@SteelEye.com>
[SCSI] stex: fix id mapping issue

The correct internal mapping of stex controllers should be:
id:0~15, lun:0~7 (st_shasta)
id:0, lun:0~127 (st_yosemite)
id:0~127, lun:0 (st_vsc and st_vsc1)

This patch reports the internal mapping to scsi mid layer,  eliminating
the translation between scsi mid layer and firmware. To achieve this
goal, we also need to:
-- fail the REPORT_LUNS command for st_shasta because the
   firmware is known to not report all actual luns
-- add an entry in scsi_devindo.c to force sequential lun scan
   (for st_shasta controllers)
-- fail the REPORT_LUNS command for console device
-- remove special handling of REPORT_LUNS command for
   st_yosemite, as there is no translation mapping now

Signed-off-by: Ed Lin <ed.lin@promise.com>
Signed-off-by: James Bottomley <James.Bottomley@SteelEye.com>
[SCSI] stex: extend hard reset wait time

During hard bus reset of st_shasta controllers, 1 ms is not enough for
16-port controllers, although it's good for 8-port controllers.  Extend the
wait time to 100  ms to allow bus resets finish successfully.

Signed-off-by: Ed Lin <ed.lin@promise.com>
Signed-off-by: James Bottomley <James.Bottomley@SteelEye.com>
[SCSI] stex: fix reset recovery for console device

After reset completed, the scsi error handler sends out TEST_UNIT_READY
to the device. For 'normal' devices the command will be handled by firmware.
However, because the RAID console only interfaces to scsi mid layer, the
firmware will not process the command for it. This will make the console to
be offlined right after reset. Add the handling in driver to fix this problem.

Signed-off-by: Ed Lin <ed.lin@promise.com>
Signed-off-by: James Bottomley <James.Bottomley@SteelEye.com>
[SCSI] stex: minor cleanup and version update

Add debug information into abort and host_reset routine.
Change ioremap to ioremap_nocache.
Version updated to 3.6.0000.1.

Signed-off-by: Ed Lin <ed.lin@promise.com>
Signed-off-by: James Bottomley <James.Bottomley@SteelEye.com>
[SCSI] MegaRAID: Update MAINTAINERS email-id

Update Maintainer email-id for MegaRAID SCSI drivers.

Signed-off-by: Sumant Patro <sumant.patro@lsi.com>
Signed-off-by: James Bottomley <James.Bottomley@SteelEye.com>
[SCSI] tgt: fix a rdma indirect transfer error bug

This sets sg_dma_len to a proper value.

Signed-off-by: FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp>
Signed-off-by: James Bottomley <James.Bottomley@SteelEye.com>
[SCSI] NCR53C9x: correct spelling mistake in deprecation notice

On Mon, Apr 30, 2007 at 03:16:39PM +0200, Geert Uytterhoeven wrote:
> > +What:	old NCR53C9x driver
> > +When:	October 2007
> > +Why:	Replaced by the much better esp_scsi driver.  Actual low-level
> > +	driver can ported over almost trivially.
>                   ^
> 		  be

current linus' tree still has my spelling mistake.  Here's a patch to
update it

Signed-off-by: James Bottomley <James.Bottomley@SteelEye.com>
[SCSI] aacraid: Correct sa platform support. (Was: [Bug 8469] Bad EIP value on pentium3 SMP kernel-2.6.21.1)

http://bugzilla.kernel.org/show_bug.cgi?id=8469

As discussed in the bugzilla outlined below, we have an sa based
(Mustang) RAID adapter on the system, a Dell PERC2/QC. Affected
controllers are HP NetRAID, Adaptec AAC-364, Dell PERC2/QC or Adaptec
5400S. This problem  coincides with the introduction of the adapter_comm
and adapter_deliver platform functions (Message [PATCH 1/4] aacraid:
rework communication support code, January 23 2007, which initially
migrated to 2.6.21)

The panic occurs with an uninitialized adapter_deliver platform function
pointer. The enclosed patch, unmodified as tested by Rainer, solves the
problem.

Signed-off-by: Mark Salyzyn <aacraid@adaptec.com>
Signed-off-by: James Bottomley <James.Bottomley@SteelEye.com>
[SCSI] aacraid: fix panic on short Inquiry

Unable to handle kernel paging request at ffff8101c0000000 RIP:
 [<ffffffff880b22a1>] :aacraid:aac_internal_transfer+0xd6/0xe3
PGD 8063 PUD 0
Oops: 0000 [1] SMP
last sysfs file: /block/sdb/removable
CPU 2
Modules linked in: autofs4(U) hidp(U) nfs(U) lockd(U)
fscache(U) nfs_acl(U) rfcomm(U) l2cap(U) bluetooth(U)
sunrpc(U) ipv6(U) cpufreq_ondemand(U) dm_mirror(U) dm_mod(U)
video(U) sbs(U) i2c_ec(U) button(U) battery(U) asus_acpi(U)
acpi_memhotplug(U) ac(U) parport_pc(U) lp(U) parport(U)
joydev(U) ide_cd(U) i2c_i801(U) i2c_core(U) shpchp(U)
cdrom(U) bnx2(U) sg(U) pcspkr(U) ata_piix(U) libata(U)
aacraid(U) sd_mod(U) scsi_mod(U) ext3(U) jbd(U) ehci_hcd(U)
ohci_hcd(U) uhci_hcd(U)
Pid: 2352, comm: syslogd Not tainted 2.6.18-prep #1
RIP: 0010:[<ffffffff880b22a1>]  [<ffffffff880b22a1>] :aacraid:aac_internal_transfer+0xd6/0xe3
RSP: 0000:ffff8101bfd1fe68  EFLAGS: 00010083
RAX: 0000000000000063 RBX: 0000000000000008 RCX: 00000000ffd1fea0
RDX: ffffffff802da628 RSI: ffff8101c0000000 RDI: ffff8101b2a08168
RBP: ffff8101b2728010 R08: ffffffff802da628 R09: 0000000000000046
R10: 0000000000000000 R11: 0000000000000080 R12: 0000000000000010
R13: ffff8101bfd1fea8 R14: ffff8101bc74df58 R15: ffff8101bc74df58
FS:  00002aaaab0146f0(0000) GS:ffff8101bfcd2e40(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
CR2: ffff8101c0000000 CR3: 00000001bdecd000 CR4: 00000000000006e0
Process syslogd (pid: 2352, threadinfo ffff8101bc74c000, task ffff8101bd979040)
Stack:  0000000000000012 0000000000000036 0000000000000000 ffff8101bee9a800
 ffff8101be9d3a00 ffff8101be9d3a00 ffff8101be8014f8 ffffffff880b26cc
 40212227607e3141 2029282a26252423 0000000000000003 ffff810037e3a000
Call Trace:
 <IRQ [<ffffffff880b26cc>] :aacraid:get_container_name_callback+0x8b/0xb5
 [<ffffffff880b6f67>] :aacraid:aac_intr_normal+0x1b3/0x1f9
 [<ffffffff880b8007>] :aacraid:aac_rkt_intr+0x37/0x115
 [<ffffffff80099749>] __rcu_process_callbacks+0xf8/0x1a8
 [<ffffffff80010705>] handle_IRQ_event+0x29/0x58
 [<ffffffff800b2fe0>] __do_IRQ+0xa4/0x105
 [<ffffffff80011c19>] __do_softirq+0x5e/0xd5
 [<ffffffff8006a193>] do_IRQ+0xe7/0xf5
 [<ffffffff8005b649>] ret_from_intr+0x0/0xa

On digging into it, it turned out that the customer was probing an
aacraid device with an INQUIRY of 8 bytes.  The way aacraid works, it
was blindly trying to use aac_internal_transfer to copy the container
name to byte 16 of the inquiry data, resulting in a negative transfer
length.  It then copies over the whole of kernel memory before
dropping off the end.

Fix updated and corrected by Mark Salyzyn

Signed-off-by: James Bottomley <James.Bottomley@SteelEye.com>
[PATCH] libertas: skb dereferenced after netif_rx

In libertas_process_rxed_packet() and process_rxed_802_11_packet() the
skb is dereferenced after being passed to netif_rx (called from
libertas_upload_rx_packet). Spotted by Coverity (1658, 1659).

Also, libertas_upload_rx_packet() unconditionally returns 0 so the error
check is dead code - might as well take it out and change the signature.

Signed-off-by: Florin Malita <fmalita@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
[PATCH] drivers/net/wireless/libertas/fw.c: fix use-before-check

NULL checks should be performed before the dereference.

Spotted by the Coverity checker.

Signed-off-by: Eugene Teo <eteo@redhat.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
[PATCH] drivers/net/wireless/libertas/rx.c: fix use-after-free

skb could have been freed by then. Also, in libertas_upload_rx_packet(),
skb->protocol is initialized by eth_type_trans().

Signed-off-by: Eugene Teo <eugeneteo@kernel.sg>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
[SCSI] sd: fix refcounting regression in suspend/resume routines

This patch (as909) fixes a couple of refcounting errors in the sd
driver's suspend and resume methods.

Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: James Bottomley <James.Bottomley@SteelEye.com>
[SCSI] aacraid: apply commit config for reset_devices flag

Under some conditions associated with the unclean transition to kdump,
the aacraid adapters will view the array as foreign and not export it to
prevent access and data manipulation. The solution is to submit a commit
configuration to export the devices since this is a expected behavior
when transitioning to a kdump kernel.

This patch adds the aacraid.reset_devices flag and when either this or
the global reset_devices flag is set, ensures that a commit config is
issued and extends the startup_timeout if it is set less than 5 minutes.

Signed-off-by: Mark Salyzyn <aacraid@adaptec.com>
Signed-off-by: James Bottomley <James.Bottomley@SteelEye.com>
[SCSI] aic7xxx: fix aicasm build failure with gcc-3.4.6

On Tue, 2007-05-22 at 06:51 -0500, Bob Tracy wrote:
> Second try: originally reported this back on April 17th.  2.6.X
> kernel builds started failing after I upgraded my compiler from
> gcc-3.3.X to gcc-3.4.6:
>
> make -C drivers/scsi/aic7xxx/aicasm
> (...)
> gcc -I/usr/include -I. aicasm.c aicasm_symbol.c aicasm_gram.c aicasm_macro_gram.c aicasm_scan.c aicasm_macro_scan.c -o aicasm -ldb
> aicasm_gram.y:1948: error: conflicting types for 'yyerror'
> aicasm_gram.tab.c:3004: error: previous implicit declaration of 'yyerror' was here
> aicasm_macro_gram.y:162: error: conflicting types for 'mmerror'
> aicasm_macro_gram.tab.c:1196: error: previous implicit declaration of 'mmerror' was here

Fix is to add a prototype for yyerror and mmerror to the relevant files.

Signed-off-by: James Bottomley <James.Bottomley@SteelEye.com>
[SCSI] aic94xx: asd_clear_nexus should fail if the cleared task does not complete

Every so often, the driver will call asd_clear_nexus to clean out a task.
It is supposed to be the case that the CLEAR NEXUS does not go on the done
list until after the task itself has been put on the done list, but for
some reason this doesn't always happen.  Thus, the
wait_for_completion_timeout call times out, and we return success.  This
makes libsas free the task even though the task hasn't completed, leading
to a BUG_ON message from aic94xx_hwi.c around line 341.  We should return
failure from asd_clear_nexus so that libsas tries again; at a bare minimum
it shouldn't be freeing active tasks.  I _think_ this will fix one of
the SCB timeout crash problems (though I've not been able to reproduce
it lately...)

Signed-off-by: Darrick J. Wong <djwong@us.ibm.com>
Signed-off-by: James Bottomley <James.Bottomley@SteelEye.com>
[SCSI] fusion: Fix |/|| confusion

There are several cases where the fusion driver uses the logical || to
try to do an arithmetical or ... fix by replacing with |.

Signed-off-by: Dave Jones <davej@redhat.com>
Acked-by: "Moore, Eric" <Eric.Moore@lsi.com>
Signed-off-by: James Bottomley <James.Bottomley@SteelEye.com>