Received-SPF: pass (google.com: domain of linux-kernel+bounces-93199-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:45d1:ec00::1 as permitted sender) client-ip=2604:1380:45d1:ec00::1;
Message-ID: <4908a5ab-dc07-41fa-bdf4-36b1f3f516e2@linux.intel.com>
Date: Wed, 6 Mar 2024 09:37:01 +0800
Precedence: bulk
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH pci-next] pci/edr: Ignore Surprise Down error on hot
 removal
To: Lukas Wunner <lukas@wunner.de>
Cc: bhelgaas@google.com, Smita.KoralahalliChannabasappa@amd.com,
 ilpo.jarvinen@linux.intel.com, sathyanarayanan.kuppuswamy@linux.intel.com,
 linux-pci@vger.kernel.org, linux-kernel@vger.kernel.org, kbusch@kernel.org
References: <20240305092139.GA28325@wunner.de>
From: Ethan Zhao <haifeng.zhao@linux.intel.com>
In-Reply-To: <20240305092139.GA28325@wunner.de>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

On 3/5/2024 5:21 PM, Lukas Wunner wrote:
> On Tue, Mar 05, 2024 at 10:09:20AM +0800, Ethan Zhao wrote:
>> On 3/4/2024 7:58 PM, Lukas Wunner wrote:
>>> On Mon, Mar 04, 2024 at 04:08:19AM -0500, Ethan Zhao wrote:
>>>> -static void dpc_handle_surprise_removal(struct pci_dev *pdev)
>>>> +bool  dpc_handle_surprise_removal(struct pci_dev *pdev)
>>>>    {
>>>> +	if (!dpc_is_surprise_removal(pdev))
>>>> +		return false;
>>> This change of moving dpc_is_surprise_removal() into
>>> dpc_handle_surprise_removal() seems unrelated to the problem at hand.
>>>
>>> Please drop it if it's unnecessary to fix the issue.
>> To only export one function dpc_is_surprise_removal()... or I have to
>> export them both.
>> Seems I should keep them intact or refactor them in separated patch ?
> Please keep them intact and make both public.  (You're not "exporting"
> the functions, there are no modular users.)
>
> However, I doubt whether you need to respin this patch at all:
>
>
>> Reproduced on "Hardware name: Intel Corporation ArcherCity/ArcherCity,
>>   BIOS EGSDCRB1.86B.0107.D20.2310211929 10/21/2023"
> Eagle Stream BIOS, isn't that an Intel-provided BIOS?
>
> Sathya's comments sound like the BIOS is misbehaving.  If so,
> then the first thing to do is ask the BIOS team to fix the issue.
> We do not want to pollute the kernel with workarounds for BIOS bugs
> that can be fixed in the field through a BIOS update.

Agree, BIOS writer finally was convinced to fix it in BIOS.
no need to respin.


Thanks,
Ethan

>
> Thanks,
>
> Lukas