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
>
>
next prev parent 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).