Signed-off-by: NAndrew Vasquez <andrew.vasquez@qlogic.com>
Signed-off-by: NJames Bottomley <James.Bottomley@SteelEye.com>

Modify intialization semantics:

- perform basic hardware configuration only (as usual)
  - allocate resources
  - load and execute firmware

- defer link (transport) negotiations to the DPC thread
  - again the code in qla2x00_initialize_adapter() to stall probe()
    completion was needed for legacy-style scanning.
  - DPC thread stalls until probe() complete.

- before probe() completes, set DPC flags to perform loop-resync logic
  (similar to what's done during cable-insertion/removal).

Benefits: user does not have to wait 20+ seconds in case the FC cable
is unplugged during driver load, code consolidation (removal of
redundant link negotiation logic during initialize_adaoter()), and
finilly, the driver no longer needs to defer the fc_remote_port_add()
calls to hold off lun-scanning prior to returning from the probe()
function.
Signed-off-by: NAndrew Vasquez <andrew.vasquez@qlogic.com>
Signed-off-by: NJames Bottomley <James.Bottomley@SteelEye.com>

If a driver can find its own targets, it can now fill in scan_finished and
(optionally) scan_start in the scsi_host_template.  Then, when it calls
scsi_scan_host(), it will be called back (from a thread if asynchronous
discovery is enabled), first to start the scan, and then at intervals to
check if the scan is completed.

Also make scsi_prep_async_scan and scsi_finish_async_scan static.
Signed-off-by: NMatthew Wilcox <matthew@wil.cx>
Signed-off-by: NJames Bottomley <James.Bottomley@SteelEye.com>

Drivers that called scsi_scan_target() instead of scsi_scan_host() were
still adding devices; this needs to be under the control of userspace,
not the driver.
Signed-off-by: NMatthew Wilcox <matthew@wil.cx>
Signed-off-by: NJames Bottomley <James.Bottomley@SteelEye.com>

Without this patch, the user has to add a kernel command line parameter
to get asynchronous SCSI scanning.  Now they can select the default at
compile time and still override it at boot time if they need to.
Signed-off-by: NMatthew Wilcox <matthew@wil.cx>
Signed-off-by: NJames Bottomley <James.Bottomley@SteelEye.com>

Received from Mark Salyzyn:

Version patch, update to reflect a rough estimate of the Adaptec build
(2423) that coincides with the sources on kernel.org.
Signed-off-by: NMark Haverkamp <markh@osdl.org>
Signed-off-by: NJames Bottomley <James.Bottomley@SteelEye.com>

Received from Mark Salyzyn:

Add code to abort outstanding management ioctl fibs when the blinkLED recovery
is performed. This code is 'clunky' and does not have any real feedback in that
the reset could progress before the user application has gotten it's
notification of command completion. We put a schedule() call to delay just the
right amount for most cases, because we tried a spin and still managed to find
cases where we would spin forever waiting for the management application to
acknowledge the impending doom surrounding the cause of the BlinkLED. Will
cause an oops in the context of the management application if we proceed too
quickly. I view this as the lesser of many evils since currently if there are
outstanding management ioctls during a need to reset/recover the adapter, the
management application just locks up and waits forever. The best practices fix
for this problem not going to be simple or easy (at least the fixes I imagine
today); and we found a balance between the needs of the driver to proceed, and
the applications that locked or confused that would hold back the driver. I
just do not like the idea of a kernel oops in an application to deal with low
priority, sluggish or misbehaving applications.
Signed-off-by: NMark Haverkamp <markh@osdl.org>
Signed-off-by: NJames Bottomley <James.Bottomley@SteelEye.com>

Received from Mark Salyzyn:

Blinkled at startup is useful for catching Adapters in a lot of pain, in a
BlinkLED assert, quickly; rather than waiting several minutes for commands to
timeout.
Signed-off-by: NMark Haverkamp <markh@osdl.org>
Signed-off-by: NJames Bottomley <James.Bottomley@SteelEye.com>

Bump driver version.
Signed-off-by: NJames Bottomley <James.Bottomley@SteelEye.com>

This patch makes ipr_ioctl static.
Signed-off-by: NAdrian Bunk <bunk@stusta.de>
Signed-off-by: NBrian King <brking@us.ibm.com>
Signed-off-by: NJames Bottomley <James.Bottomley@SteelEye.com>

Since the default error log size has increased on SAS adapters,
prevent ipr from logging this additional data unless requested
to do so by the user set log level in order to prevent flooding
the logs.
Signed-off-by: NBrian King <brking@us.ibm.com>
Signed-off-by: NJames Bottomley <James.Bottomley@SteelEye.com>

Adds support for logging SAS fabric errors logged by
the ipr firmware.
Signed-off-by: NBrian King <brking@us.ibm.com>
Signed-off-by: NJames Bottomley <James.Bottomley@SteelEye.com>

Remove some debug trace points that clutter up the log
when ipr debugging is turned on.
Signed-off-by: NJames Bottomley <James.Bottomley@SteelEye.com>

Remove ipr's usage of the scsi transport eh_timed_out for
handling SATA timeouts. This was only needed in order to set
some flags on the qc prior to calling ata_do_eh.
Signed-off-by: NJames Bottomley <James.Bottomley@SteelEye.com>

Both SCSI_IPR_TRACE and SCSI_IPR_DUMP should be defaulted to
yes when SCSI_IPR is enabled.
Signed-off-by: NBrian King <brking@us.ibm.com>
Signed-off-by: NJames Bottomley <James.Bottomley@SteelEye.com>

Adds PCI IDs for some new ipr SAS adapters.
Signed-off-by: NJames Bottomley <James.Bottomley@SteelEye.com>

The ipr disk array devices do not support a cancel all
requests primitive, so change the ipr driver to never
send it.
Signed-off-by: NJames Bottomley <James.Bottomley@SteelEye.com>

If an ipr adapter hits a fatal microcode error requiring a reset
while a SATA device is going through EH, it can result in a command
getting issued to the ipr adapter while it is getting reset, which
can cause PCI bus errors. Wait for any outstanding adapter reset
to finish prior to issuing a SATA device reset.
Signed-off-by: NJames Bottomley <James.Bottomley@SteelEye.com>

This patch fixes a timing issue related to nvram accesses in qla4xxx
driver for some cpu/slot speed combination.
Signed-off-by: NDavid Somayajulu <david.somayajulu@qlogic.com>
Signed-off-by: NJames Bottomley <James.Bottomley@SteelEye.com>

This patch makes two needlessly global functions static.
Signed-off-by: NAdrian Bunk <bunk@stusta.de>
Acked-by: N"Patro, Sumant" <Sumant.Patro@lsi.com>
Signed-off-by: NJames Bottomley <James.Bottomley@SteelEye.com>

This patch provides the following:

1. adds support for the next version of Qlogic's iSCSI HBA, qla4032
   (PCI Device ID 4032).

2. removes dead code related to topcat chip and renames
   qla4010_soft_reset to qla4xxx_soft_reset (minor changes).
Signed-off-by: NDavid Somayajulu <david.somayajulu@qlogic.com>
Signed-off-by: NJames Bottomley <James.Bottomley@SteelEye.com>

Signed-off-by: NJames Bottomley <James.Bottomley@SteelEye.com>

On qla4xxx, the driver needs to grab the drvr semaphore provided by
the hardware, prior to issuing a reset. This patches takes care of a
couple of places where it was not being done. In addition there is
minor clean up.
Signed-off-by: NDavid Somayajulu <david.somayajulu@qlogic.com>
Signed-off-by: NJames Bottomley <James.Bottomley@SteelEye.com>

When the aic94xx driver creates ascbs, each ascb is initialized with a
timeout timer.  If there are any ascbs left over when the driver is being
torn down, these timers need to be deleted.  In particular, we seem to
hit this case when ascbs are issued yet never end up on the done list.
Right now there's a sequencer bug that results in this happening every
so often.

CONTROL PHY commands are typically sent when things are really messed
up with the sequencer; however, any other leftover ascb should produce
loud warnings.
Signed-off-by: NDarrick J. Wong <djwong@us.ibm.com>
Signed-off-by: NJames Bottomley <James.Bottomley@SteelEye.com>

This patch implements a REQ_DEVICE_RESET handler for the aic94xx
driver.  Like the earlier REQ_TASK_ABORT patch, this patch defers the
device reset to the Scsi_Host's workqueue, which has the added benefit
of ensuring that the device reset does not happen at the same time
that the abort tmfs are being processed.  After the phy reset, the
busted drive should go away and be re-detected later, which is indeed
what I've seen on both a x260 and a x206m.
Signed-off-by: NDarrick J. Wong <djwong@us.ibm.com>
Signed-off-by: NJames Bottomley <James.Bottomley@SteelEye.com>

* 'merge' of master.kernel.org:/pub/scm/linux/kernel/git/paulus/powerpc:
  [POWERPC] Fix ucc_geth of_device discovery on mpc832x
  [POWERPC] Revert "[POWERPC] Add powerpc get/set_rtc_time interface to new generic rtc class"
  [POWERPC] Revert "[POWERPC] Enable generic rtc hook for the MPC8349 mITX"

* master.kernel.org:/pub/scm/linux/kernel/git/davem/net-2.6:
  [TG3]: Add missing unlock in tg3_open() error path.
  [IPV6]: Fix address/interface handling in UDP and DCCP, according to the scoping architecture.
  [IRDA]: Lockdep fix.
  [BLUETOOTH]: Fix unaligned access in hci_send_to_sock.
  [XFRM]: nlmsg length not computed correctly in the presence of subpolicies
  [XFRM]: Sub-policies broke policy events
  [IGMP]: Fix IGMPV3_EXP() normalization bit shift value.
  [Bluetooth] Ignore L2CAP config requests on disconnect
  [Bluetooth] Always include MTU in L2CAP config responses
  [Bluetooth] Check if RFCOMM session is still attached to the TTY
  [Bluetooth] Handling pending connect attempts after inquiry
  [Bluetooth] Attach low-level connections to the Bluetooth bus
  [IPV6] IP6TUNNEL: Add missing nf_reset() on input path.
  [IPV6] IP6TUNNEL: Delete all tunnel device when unloading module.
  [IPV6] ROUTE: Do not enable router reachability probing in router mode.
  [IPV6] ROUTE: Prefer reachable nexthop only if the caller requests.
  [IPV6] ROUTE: Try to use router which is not known unreachable.

mpc832x, as in mpc8360, needs to explicitly find and create the
platform device for ucc_geth in 2.6.19.  This code will likely be
readapted to Benh's new of_ methods for 2.6.20.
Signed-off-by: NKim Phillips <kim.phillips@freescale.com>
Signed-off-by: NPaul Mackerras <paulus@samba.org>

Sparse noticed a locking imbalance in tg3_open(). This patch adds an
unlock to one of the error paths, so that tg3_open() always exits
without the lock held.
Signed-off-by: NIra W. Snyder <kernel@irasnyder.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

TCP and RAW do not have this issue.  Closes Bug #7432.
Signed-off-by: NYOSHIFUJI Hideaki <yoshfuji@linux-ipv6.org>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

On Sat, 2006-11-18 at 16:12 +0300, Andrey Borzenkov wrote:

> =============================================
> [ INFO: possible recursive locking detected ]
> 2.6.19-rc5-2avb #2
> - ---------------------------------------------
> pppd/26425 is trying to acquire lock:
>  (&hashbin->hb_spinlock){....}, at: [<dfdea87a>] irlmp_slsap_inuse+0x5a/0x170
> [irda]
>
> but task is already holding lock:
>  (&hashbin->hb_spinlock){....}, at: [<dfdea857>] irlmp_slsap_inuse+0x37/0x170
> [irda]
>
> other info that might help us debug this:
> 1 lock held by pppd/26425:
>  #0:  (&hashbin->hb_spinlock){....}, at: [<dfdea857>]
> irlmp_slsap_inuse+0x37/0x170 [irda]
>
> stack backtrace:
>  [<c010413c>] dump_trace+0x1cc/0x200
>  [<c010418a>] show_trace_log_lvl+0x1a/0x30
>  [<c01047f2>] show_trace+0x12/0x20
>  [<c01048c9>] dump_stack+0x19/0x20
>  [<c01346ca>] __lock_acquire+0x8fa/0xc20
>  [<c0134d2d>] lock_acquire+0x5d/0x80
>  [<c02a851c>] _spin_lock+0x2c/0x40
>  [<dfdea87a>] irlmp_slsap_inuse+0x5a/0x170 [irda]
>  [<dfdebab2>] irlmp_open_lsap+0x62/0x180 [irda]
>  [<dfdf35d1>] irttp_open_tsap+0x181/0x230 [irda]
>  [<dfdc0c3d>] ircomm_open_tsap+0x5d/0xa0 [ircomm]
>  [<dfdc05d8>] ircomm_open+0xb8/0xd0 [ircomm]
>  [<dfdd0477>] ircomm_tty_open+0x4f7/0x570 [ircomm_tty]
>  [<c020bbe4>] tty_open+0x174/0x340
>  [<c016bd69>] chrdev_open+0x89/0x170
>  [<c0167bd6>] __dentry_open+0xa6/0x1d0
>  [<c0167da5>] nameidata_to_filp+0x35/0x40
>  [<c0167df9>] do_filp_open+0x49/0x50
>  [<c0167e47>] do_sys_open+0x47/0xd0
>  [<c0167f0c>] sys_open+0x1c/0x20
>  [<c010307d>] sysenter_past_esp+0x56/0x8d
>  [<b7f86410>] 0xb7f86410
>  =======================

The comment at the nesting lock says:

	/* Careful for priority inversions here !
	 * irlmp->links is never taken while another IrDA
	 * spinlock is held, so we are safe. Jean II */

So, under the assumption the author was right, it just needs a lockdep
annotation.
Signed-off-by: NPeter Zijlstra <a.p.zijlstra@chello.nl>
Acked-by: NIngo Molnar <mingo@elte.hu>
Signed-off-by: NAndrew Morton <akpm@osdl.org>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

This reverts commit 7a69af63.

As advised by David Brownell:

http://marc.theaimsgroup.com/?l=linux-kernel&m=116387226902131&w=2Signed-off-by: NKim Phillips <kim.phillips@freescale.com>
Signed-off-by: NPaul Mackerras <paulus@samba.org>

This reverts commit a8ed4f7e.

As advised by David Brownell:

http://marc.theaimsgroup.com/?l=linux-kernel&m=116387226902131&w=2Signed-off-by: NKim Phillips <kim.phillips@freescale.com>
Signed-off-by: NPaul Mackerras <paulus@samba.org>

The "u16 *" derefs of skb->data need to be wrapped inside of
a get_unaligned().

Thanks to Gustavo Zacarias for the bug report.
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

I actually dont have a test case for these; i just found them by
inspection. Refer to patch "[XFRM]: Sub-policies broke policy events"
for more info
Signed-off-by: NJamal Hadi Salim <hadi@cyberus.ca>
Acked-by: NMasahide NAKAMURA <nakam@linux-ipv6.org>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

XFRM policy events are broken when sub-policy feature is turned on.
A simple test to verify this:
run ip xfrm mon on one window and add then delete a policy on another
window ..
Signed-off-by: NJamal Hadi Salim <hadi@cyberus.ca>
Acked-by: NMasahide NAKAMURA <nakam@linux-ipv6.org>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

The IGMPV3_EXP() macro doesn't correctly shift the normalization bit, so
time-out values are longer than they should be.

Thanks to Dirk Ooms for finding the problem in IGMPv3 - MLDv2 had a
similar problem that was already fixed a year ago. :-(
Signed-off-by: NDavid L Stevens <dlstevens@us.ibm.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Any L2CAP connection in disconnecting state shall not response
to any further config requests from the remote side. So in case
such a request is received, ignore it.
Signed-off-by: NVille Tervo <ville.tervo@nokia.com>
Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>

When sending a positive config response it shall include the actual
MTU to be used on this channel. This differs from the Bluetooth 1.1
specification where it was enough to acknowledge the config request.
Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>