linux-scsi.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Michael Reed <mdr@sgi.com>
To: James Bottomley <James.Bottomley@SteelEye.com>
Cc: linux-scsi <linux-scsi@vger.kernel.org>,
	"Moore, Eric Dean" <Eric.Moore@lsil.com>
Subject: Re: [PATCH] fusion - mptspi - reset handler shouldn't be called	for other bus protocals
Date: Thu, 18 May 2006 09:45:24 -0500	[thread overview]
Message-ID: <446C8884.4030102@sgi.com> (raw)
In-Reply-To: <1147907212.3463.99.camel@mulgrave.il.steeleye.com>

This patch looks as though it will result in not calling
the reset handler for MPTBASE_DRIVER, MPTCTL_DRIVER, or
MPTLAN_DRIVER.  The base and control drivers aren't
associated with any particular board type.

The other registered reset handlers, i.e., not mptspi_ioc_reset,
already properly determine if they should execute.

NACK.  (As If I get to make this decision!)

Thanks,
 Mike


James Bottomley wrote:
> On Wed, 2006-05-17 at 16:17 -0600, Eric Moore wrote:
>> 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.
>> This patch insures domain validation is only occuring on spi end devices
>>
>> This is urgent bug fix. Pls apply this to scsi-rc-fixes-2.6,
>> as well as this patch posted yesterday:
>> http://marc.theaimsgroup.com/?l=linux-scsi&m=114782261719616&w=2
> 
> That's a pretty nasty bug ... and it will bite on the other reset
> handlers, won't it as well?  Shouldn't we be fixing it this way instead:
> 
> James
> 
> diff --git a/drivers/message/fusion/mptbase.c b/drivers/message/fusion/mptbase.c
> index 9080853..a300840 100644
> --- a/drivers/message/fusion/mptbase.c
> +++ b/drivers/message/fusion/mptbase.c
> @@ -1605,6 +1605,21 @@ mpt_resume(struct pci_dev *pdev)
>  }
>  #endif
>  
> +static int
> +mpt_signal_reset(int index, MPT_ADAPTER *ioc, int reset_phase)
> +{
> +	if ((MptDriverClass[index] == MPTSPI_DRIVER &&
> +	     ioc->bus_type != SPI) ||
> +	    (MptDriverClass[index] == MPTFC_DRIVER &&
> +	     ioc->bus_type != FC) ||
> +	    (MptDriverClass[index] == MPTSAS_DRIVER &&
> +	     ioc->bus_type != SAS))
> +		/* make sure we only call the relevant reset handler
> +		 * for the bus */
> +		return 0;
> +	return (MptResetHandlers[index])(ioc, reset_phase);
> +}
> +
>  /*=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=*/
>  /*
>   *	mpt_do_ioc_recovery - Initialize or recover MPT adapter.
> @@ -1885,14 +1900,14 @@ #endif
>  			if ((ret == 0) && MptResetHandlers[ii]) {
>  				dprintk((MYIOC_s_INFO_FMT "Calling IOC post_reset handler #%d\n",
>  						ioc->name, ii));
> -				rc += (*(MptResetHandlers[ii]))(ioc, MPT_IOC_POST_RESET);
> +				rc += mpt_signal_reset(ii, ioc, MPT_IOC_POST_RESET);
>  				handlers++;
>  			}
>  
>  			if (alt_ioc_ready && MptResetHandlers[ii]) {
>  				drsprintk((MYIOC_s_INFO_FMT "Calling alt-%s post_reset handler #%d\n",
>  						ioc->name, ioc->alt_ioc->name, ii));
> -				rc += (*(MptResetHandlers[ii]))(ioc->alt_ioc, MPT_IOC_POST_RESET);
> +				rc += mpt_signal_reset(ii, ioc->alt_ioc, MPT_IOC_POST_RESET);
>  				handlers++;
>  			}
>  		}
> @@ -3267,11 +3282,11 @@ #endif
>  				if (MptResetHandlers[ii]) {
>  					dprintk((MYIOC_s_INFO_FMT "Calling IOC pre_reset handler #%d\n",
>  							ioc->name, ii));
> -					r += (*(MptResetHandlers[ii]))(ioc, MPT_IOC_PRE_RESET);
> +					r += mpt_signal_reset(ii, ioc, MPT_IOC_PRE_RESET);
>  					if (ioc->alt_ioc) {
>  						dprintk((MYIOC_s_INFO_FMT "Calling alt-%s pre_reset handler #%d\n",
>  								ioc->name, ioc->alt_ioc->name, ii));
> -						r += (*(MptResetHandlers[ii]))(ioc->alt_ioc, MPT_IOC_PRE_RESET);
> +						r += mpt_signal_reset(ii, ioc->alt_ioc, MPT_IOC_PRE_RESET);
>  					}
>  				}
>  			}
> @@ -5706,11 +5721,11 @@ #endif
>  			if (MptResetHandlers[ii]) {
>  				dtmprintk((MYIOC_s_INFO_FMT "Calling IOC reset_setup handler #%d\n",
>  						ioc->name, ii));
> -				r += (*(MptResetHandlers[ii]))(ioc, MPT_IOC_SETUP_RESET);
> +				r += mpt_signal_reset(ii, ioc, MPT_IOC_SETUP_RESET);
>  				if (ioc->alt_ioc) {
>  					dtmprintk((MYIOC_s_INFO_FMT "Calling alt-%s setup reset handler #%d\n",
>  							ioc->name, ioc->alt_ioc->name, ii));
> -					r += (*(MptResetHandlers[ii]))(ioc->alt_ioc, MPT_IOC_SETUP_RESET);
> +					r += mpt_signal_reset(ii, ioc->alt_ioc, MPT_IOC_SETUP_RESET);
>  				}
>  			}
>  		}
> 
> 
> -
> To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 
> 

  reply	other threads:[~2006-05-18 14:45 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-05-17 22:17 [PATCH] fusion - mptspi - reset handler shouldn't be called for other bus protocals Eric Moore
2006-05-17 23:06 ` James Bottomley
2006-05-18 14:45   ` Michael Reed [this message]
2006-05-18 14:54     ` James Bottomley
2006-05-18 15:11       ` Michael Reed
2006-05-18 15:46         ` Michael Reed

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=446C8884.4030102@sgi.com \
    --to=mdr@sgi.com \
    --cc=Eric.Moore@lsil.com \
    --cc=James.Bottomley@SteelEye.com \
    --cc=linux-scsi@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).