* master.kernel.org:/pub/scm/linux/kernel/git/davem/sparc-2.6:
  [SPARC64]: Avoid JBUS errors on some Niagara systems.
  [FUSION]: Fix mptspi.c build with CONFIG_PM not set.
  [TG3]: Handle Sun onboard tg3 chips more correctly.
  [SPARC64]: Dump local cpu registers in sun4v_log_error()

From: Markus Lidel <Markus.Lidel@shadowconnect.com>

- Fixed locking of struct i2o_exec_wait in Executive-OSM

- Removed LCT Notify in i2o_exec_probe() which caused freeing memory and
  accessing freed memory during first enumeration of I2O devices

- Added missing locking in i2o_exec_lct_notify()

- removed put_device() of I2O controller in i2o_iop_remove() which caused
  the controller structure get freed to early

- Fixed size of mempool in i2o_iop_alloc()

- Fixed access to freed memory in i2o_msg_get()

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

Signed-off-by: Markus Lidel <Markus.Lidel@shadowconnect.com>
Cc: <stable@kernel.org>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>

Signed-off-by: Tom "spot" Callaway <tcallawa@redhat.com>
Signed-off-by: David S. Miller <davem@davemloft.net>

All registered reset callback handlers are called during reset processing.
The mptspi modules has its own reset callback handler, just recently
added for issuing domain validation after host reset.  If either the mptsas or
mptfc driver are loaded, this callback could be called. Thus resulting
in domain validation being issued for sas or fibre end devices.

Fix this by having mptbase.c check the bus type against the driver
type and only call the reset handler if they match (or if it's a
non-bus specific reset handler).

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

A race condition exists in mptfc between the thread registering a device
with the fc transport and the scan work generated by the transport.
This race existed prior to the application of the mptfc bug fix patch.

mptfc_register_dev() calls fc_remote_port_add() with the FC_RPORT_ROLE_TARGET
bit set in the rport ids passed to the function.  Having this bit set causes
fc_remote_port_add() to schedule a scan of the device.

This scan can execute before mptfc_register_dev() can fill in the dd_data
in the rport structure.  When this happens, mptfc_target_alloc() will fail
because dd_data is null.

Attached is a patch which fixes the problem.  The patch changes the rport ids
passed to fc_remote_port_add() to not have the TARGET bit set.  This prevents
the scan from being scheduled.  After mptfc_register_dev() fills in the rport
dd_data field, fc_remote_port_rolechg() is called, changing the role of the
rport to TARGET.  Thus, the scan is scheduled after dd_data is filled
in which prevents the failure in mptfc_target_alloc().

Signed-off-by: Michael Reed <mdr@sgi.com>
Signed-off-by: Eric Moore <Eric.Moore@lsil.com>
Signed-off-by: James Bottomley <James.Bottomley@SteelEye.com>

This is a bug fix for mptspi driver, where after a host reset or
resume, we revalidate the negotiation parameters for all devices.
This bug was introduced when the driver was ported to use the spi
transport layer.

Signed-off-by: Eric Moore <Eric.Moore@lsil.com>
Signed-off-by: James Bottomley <James.Bottomley@SteelEye.com>

Bug fix for stack overflow in EventDescriptionStr, (a function
for debuging firmware events).  We allocated 50 bytes on local stack
for buff[], however there are places in the code where we've attempted
copying in greater than 50 bytes into buff[].

Signed-off-by: Eric Moore <Eric.Moore@lsil.com>
Signed-off-by: James Bottomley <James.Bottomley@SteelEye.com>

mptbase.h

	bump version number to 3.03.09

	remove unneeded flags
	define workq and remove old fc specific locks

mptbase.c

	initialize new lock and don't initialize two removed locks

mptscsih.c

	when firmware reports target is no longer there, return
        DID_REQUEUE for fc hosts so that i/o doesn't get killed until
        the transport has an opportunity to manage the loss via its
        dev loss timer

	when the "eh_abort" routine is called, check to see if the
        driver has the command or not before looking to see if a reset
        is pending.  James Smart and I talked about this and believe
        that the API for this routine is: if driver doesn't have
        command, return SUCCESS.  This change helps prevent a target
        from being taken offline.  SUCCESS is returned because it's
        likely that the command completed after error recovery timed
        it out but before it could be aborted.

	provide a routine to queue work to newly created workq, and
        use it.

	remove "ioc" from mptscsih_abort() it was only used one time.
	the other references were via hd->ioc, so I just moved it....
	net change in references to ioc via hd->ioc is zero

	move hd->resetPending test and hd->timeouts increment to after
	the test for whether the command to be aborted remains known
	to the driver

	Make certain that the workq exists before queuing work to it.

mptfc.c

	no longer need to lock rport data structures as I was able to
	single thread the code!  I fixed up the debug code to
	eliminate compilation messages due to type mismatch in the
	printk.  Got rid of some no longer needed rport flags.
	Initialize and destroy the workq used for the rescan work.

	simplify the logic regarding the increment of
        fc_rescan_work_count.  use post increment and test for zero
        vs. pre increment and test for one; eliminate work_count
        variable: queue_work can be called with the work_lock held as
        it doesn't sleep

Signed-off-by: Michael Reed <mdr@sgi.com>
Signed-off-by: Eric Moore <Eric.Moore@lsil.com>
Signed-off-by: James Bottomley <James.Bottomley@SteelEye.com>

This patch handles case where raid hidden components
are not being removed when power turned off to device
attached to expander, as well as the case of
exposing raid components when power is turned back on
to devices attached to an expander.  (This is a repost
of this patch, with  mptsas_is_end_device declared
further up in the code.)

This patch contains some other miscellaneous bug fix's.

Signed-off-by: Eric Moore <Eric.Moore@lsil.com>
Signed-off-by: James Bottomley <James.Bottomley@SteelEye.com>

Driver panic when RAID logical volume was present when driver
loaded, or when a RAID logical volume was created on the fly.

This issue was created in due to recent scsi_transport_sas change,
when sas_read_port_mode_page was added into the mptsas drivers
slave_config entry point.

This new API expects that all sdev's to be assocated to an rphy, however
that is not the case for logical volumes, as they are created using
scsi_add_device, instead of sas_rphy_add().

Signed-off-by: Eric Moore <Eric.Moore@lsil.com>
Signed-off-by: James Bottomley <James.Bottomley@SteelEye.com>