From: Damien Le Moal <damien.lemoal@opensource.wdc.com>
To: John Garry <john.garry@huawei.com>,
jejb@linux.ibm.com, martin.petersen@oracle.com,
jinpu.wang@cloud.ionos.com, Ajish.Koshy@microchip.com,
Viswas.G@microchip.com
Cc: linux-scsi@vger.kernel.org, linux-kernel@vger.kernel.org,
vishakhavc@google.com, ipylypiv@google.com,
Ruksar.devadi@microchip.com,
Vasanthalakshmi.Tharmarajan@microchip.com
Subject: Re: [PATCH RFT] scsi: pm8001: Fix FW crash for maxcpus=1
Date: Wed, 5 Jan 2022 13:03:52 +0900 [thread overview]
Message-ID: <d2d3c903-fb91-e218-9e0a-aeb2ff9e401a@opensource.wdc.com> (raw)
In-Reply-To: <1641320780-81620-1-git-send-email-john.garry@huawei.com>
On 1/5/22 03:26, John Garry wrote:
> According to the comment in check_fw_ready() we should not check the
> IOP1_READY field in register SCRATCH_PAD_1 for 8008 or 8009 controllers.
>
> However we check this very field in process_oq() for processing the highest
> index interrupt vector. Change that function to not check IOP1_READY for
> those mentioned controllers, but do check ILA_READY in both cases.
>
> The reason I assume that this was not hit earlier was because we always
> allocated 64 MSI(X), and just did not pass the vector index check in
> process_oq(), i.e. the handler never ran for vector index 63.
>
> Signed-off-by: John Garry <john.garry@huawei.com>
>
> diff --git a/drivers/scsi/pm8001/pm80xx_hwi.c b/drivers/scsi/pm8001/pm80xx_hwi.c
> index 2101fc5761c3..77b8bb30615b 100644
> --- a/drivers/scsi/pm8001/pm80xx_hwi.c
> +++ b/drivers/scsi/pm8001/pm80xx_hwi.c
> @@ -4162,9 +4162,16 @@ static int process_oq(struct pm8001_hba_info *pm8001_ha, u8 vec)
> u32 regval;
>
> if (vec == (pm8001_ha->max_q_num - 1)) {
> + u32 mipsall_ready;
> +
> + if ((pm8001_ha->chip_id == chip_8008) ||
> + (pm8001_ha->chip_id == chip_8009))
nit: no need for the inner brackets here.
> + mipsall_ready = SCRATCH_PAD_MIPSALL_READY_8PORT;
> + else
> + mipsall_ready = SCRATCH_PAD_MIPSALL_READY_16PORT;
> +
> regval = pm8001_cr32(pm8001_ha, 0, MSGU_SCRATCH_PAD_1);
> - if ((regval & SCRATCH_PAD_MIPSALL_READY) !=
> - SCRATCH_PAD_MIPSALL_READY) {
> + if ((regval & mipsall_ready) != mipsall_ready) {
> pm8001_ha->controller_fatal_error = true;
> pm8001_dbg(pm8001_ha, FAIL,
> "Firmware Fatal error! Regval:0x%x\n",
> diff --git a/drivers/scsi/pm8001/pm80xx_hwi.h b/drivers/scsi/pm8001/pm80xx_hwi.h
> index c7e5d93bea92..c41ed039c92a 100644
> --- a/drivers/scsi/pm8001/pm80xx_hwi.h
> +++ b/drivers/scsi/pm8001/pm80xx_hwi.h
> @@ -1405,8 +1405,12 @@ typedef struct SASProtocolTimerConfig SASProtocolTimerConfig_t;
> #define SCRATCH_PAD_BOOT_LOAD_SUCCESS 0x0
> #define SCRATCH_PAD_IOP0_READY 0xC00
> #define SCRATCH_PAD_IOP1_READY 0x3000
> -#define SCRATCH_PAD_MIPSALL_READY (SCRATCH_PAD_IOP1_READY | \
> +#define SCRATCH_PAD_MIPSALL_READY_16PORT (SCRATCH_PAD_IOP1_READY | \
> SCRATCH_PAD_IOP0_READY | \
> + SCRATCH_PAD_ILA_READY | \
> + SCRATCH_PAD_RAAE_READY)
> +#define SCRATCH_PAD_MIPSALL_READY_8PORT (SCRATCH_PAD_IOP0_READY | \
> + SCRATCH_PAD_ILA_READY | \
> SCRATCH_PAD_RAAE_READY)
>
> /* boot loader state */
Otherwise, looks OK to me.
I tested with and without max_cpus=1 with a ATTO Technology, Inc.
ExpressSAS 12Gb/s SAS/SATA HBA (rev 06) adapter and everything is OK.
That adapter uses chip_8072 though, not 8008 or 8009.
Feel free to add:
Reviewed-by: Damien Le Moal <damien.lemoal@opensource.wdc.com>
Tested-by: Damien Le Moal <damien.lemoal@opensource.wdc.com>
--
Damien Le Moal
Western Digital Research
next prev parent reply other threads:[~2022-01-05 4:03 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-01-04 18:26 [PATCH RFT] scsi: pm8001: Fix FW crash for maxcpus=1 John Garry
2022-01-05 4:03 ` Damien Le Moal [this message]
2022-01-05 11:28 ` John Garry
2022-01-06 13:03 ` Ajish.Koshy
2022-01-06 15:32 ` John Garry
2022-01-06 23:59 ` Damien Le Moal
2022-01-07 11:05 ` Ajish.Koshy
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=d2d3c903-fb91-e218-9e0a-aeb2ff9e401a@opensource.wdc.com \
--to=damien.lemoal@opensource.wdc.com \
--cc=Ajish.Koshy@microchip.com \
--cc=Ruksar.devadi@microchip.com \
--cc=Vasanthalakshmi.Tharmarajan@microchip.com \
--cc=Viswas.G@microchip.com \
--cc=ipylypiv@google.com \
--cc=jejb@linux.ibm.com \
--cc=jinpu.wang@cloud.ionos.com \
--cc=john.garry@huawei.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-scsi@vger.kernel.org \
--cc=martin.petersen@oracle.com \
--cc=vishakhavc@google.com \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.