IronPort-SDR: iUrroAufPJTm6jgyKVRAp+IP9Bv4kULWaMFyKB8u5CRxca9peeTwlUBiPPzm4lFWcltF6iuqU0
 lLbhlSo9iUqK6vOBwtix8oXPKjyJj2R3x+IdMbQ7EFjZ6oNB62xw1MvMuhCK5ejmbdXUE9Qv71
 Rt41zKz9MEfpF4N5BqmRu1HsLlPEVEdIFqolxniCe7K8+ZHPShi7GcI6WjGqrNtkMmfssu13i9
 hf4ieD9a8nHEpY8B31kBG6Y3xi1G/yMq3pzD/xmkgWs9CVY73HSqqmSJxVa1CWGesFuuaAVOBQ
 PZlewFTSCuNNJ2UkCeKNW85s
IronPort-SDR: V2EHXLDg8xvDZsOr3/A6NTHDzsVIw4k4B5zLJIHfj9aPayk4d8D7ovXtEy1vC7PUa64WT38/Xr
 gsOlWo+98lMUquviJxQANLlE9pBrSJXQDchoRzkPfdCY8Kw1m+fjTmLb0npht+dOhDbAlDsHjZ
 6ArS0GlsHrmUHbWo+7CNVhn0e2FD/1ezBckz8IyecNSgGp6NYXGA4vQ0IVFYjgTqta6ZdMvomE
 QWnKdg34DVvYB2jJqO8f4Mkogb/YiV19p8O0ElGa0frQulPXE1+7A/pKeLWFld6AnfsGNyIQbN
 XyQ=
WDCIronportException: Internal
Message-ID: <31ff2ee7-3e49-70bd-3f37-702d4e6c85a5@opensource.wdc.com>
Date:   Fri, 7 Jan 2022 08:59:35 +0900
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:91.0)
 Gecko/20100101 Thunderbird/91.4.1
Subject: Re: [PATCH RFT] scsi: pm8001: Fix FW crash for maxcpus=1
Content-Language: en-US
To:     John Garry <john.garry@huawei.com>, Ajish.Koshy@microchip.com,
        jejb@linux.ibm.com, martin.petersen@oracle.com,
        jinpu.wang@cloud.ionos.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
References: <1641320780-81620-1-git-send-email-john.garry@huawei.com>
 <d2d3c903-fb91-e218-9e0a-aeb2ff9e401a@opensource.wdc.com>
 <2746563e-28ce-b328-3494-f91ace1599f1@huawei.com>
 <PH0PR11MB5112F9E9BB9F029DB9A67739EC4C9@PH0PR11MB5112.namprd11.prod.outlook.com>
 <c19c2b0b-d502-b393-db8a-cb5c57c00feb@huawei.com>
From:   Damien Le Moal <damien.lemoal@opensource.wdc.com>
Organization: Western Digital
In-Reply-To: <c19c2b0b-d502-b393-db8a-cb5c57c00feb@huawei.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Precedence: bulk

On 2022/01/07 0:32, John Garry wrote:
> On 06/01/2022 13:03, Ajish.Koshy@microchip.com wrote:
>>>   only a specific vector and, also, why we check at all in
>>> an interrupt handler.
>> Here is my initial understanding so far based on the code
>> and data sheet
>>
>> 1. Controller has the capability to communicate
>> to the host about fatal error condition via configured
>> interrupt vector MSI/MSI-X.
>> 2. This capability is achieved by setting two fields
>>   a. Enable Controller Fatal error notification
>>      Dowrd 0x1C, Bit[0].
>>      1 - Enable; 0 - Disable
>>      Code: pm8001_ha->main_cfg_tbl.pm80xx_tbl.
>>      fatal_err_interrupt = 0x01;
>>   b. Fatal Error Interrupt Vector Dword 0x1C, bit[15:8]
>>      This parameter configures which interrupt vector
>>      is used to notify the host of the fatal error.
>>      Code: /* Update Fatal error interrupt vector */
>>      pm8001_ha->main_cfg_tbl.pm80xx_tbl.
>>      fatal_err_interrupt |=
>>      ((pm8001_ha->max_q_num - 1) << 8);
>>
>> Probably this will be the reason why we check
>> the vector in process_oq() for processing
>> controller fatal error
>>
>> if (vec == (pm8001_ha->max_q_num - 1)) {
>>   
>> Please do let me know if it helped in clarification.
>>
> 
> Sounds reasonable. And we only discover the issue for 8008/8009 now as 
> we have that (pm8001_ha->max_q_num - 1) vector being used for standard IO.
> 
> So let me know of any other issue, otherwise I'll send a v2 with the 
> coding style fixup.

And maybe add comments about the above so that the information does not get lost ?

> 
> Thanks,
> John


-- 
Damien Le Moal
Western Digital Research