linux-pci.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Ethan Zhao <haifeng.zhao@linux.intel.com>
To: AceLan Kao <acelan.kao@canonical.com>, Lukas Wunner <lukas@wunner.de>
Cc: "Bjorn Helgaas" <bhelgaas@google.com>,
	"Ilpo Järvinen" <ilpo.jarvinen@linux.intel.com>,
	linux-pci@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] PCI: pciehp: Fix system hang on resume after hot-unplug during suspend
Date: Wed, 23 Oct 2024 12:23:54 +0800	[thread overview]
Message-ID: <3354e37e-c48a-4696-a074-2df9e625fc0c@linux.intel.com> (raw)
In-Reply-To: <CAFv23QmAOAobFC=4tkKBM4NQPR_b3Nsji5xa+TczUbAJ1dxhvg@mail.gmail.com>

On 10/17/2024 10:40 AM, AceLan Kao wrote:
> AceLan Kao <acelan.kao@canonical.com> 於 2024年10月7日 週一 下午12:34寫道:
>> Lukas Wunner <lukas@wunner.de> 於 2024年10月1日 週二 下午7:03寫道:
>>> On Tue, Oct 01, 2024 at 01:02:46PM +0200, Lukas Wunner wrote:
>>>> On Mon, Sep 30, 2024 at 09:31:53AM +0800, AceLan Kao wrote:
>>>>> Lukas Wunner <lukas@wunner.de> 2024 9 28 8:51:
>>>>>> -       if (pci_get_dsn(pdev) != ctrl->dsn)
>>>>>> +       dsn = pci_get_dsn(pdev);
>>>>>> +       if (!PCI_POSSIBLE_ERROR(dsn) &&
>>>>>> +           dsn != ctrl->dsn)
>>>>>>                  return true;
>>>>> In my case, the pciehp_device_replaced() returns true from this final check.
>>>>> And these are the values I got
>>>>> dsn = 0x00000000, ctrl->dsn = 0x7800AA00
>>>>> dsn = 0x00000000, ctrl->dsn = 0x21B7D000
>>>> Ah because pci_get_dsn() returns 0 if the device is gone.
>>>> Below is a modified patch which returns false in that case.
>>> Sorry, forgot to include the patch:
>>>
>>> -- >8 --
>>>
>>> diff --git a/drivers/pci/hotplug/pciehp_core.c b/drivers/pci/hotplug/pciehp_core.c
>>> index ff458e6..957c320 100644
>>> --- a/drivers/pci/hotplug/pciehp_core.c
>>> +++ b/drivers/pci/hotplug/pciehp_core.c
>>> @@ -287,24 +287,32 @@ static int pciehp_suspend(struct pcie_device *dev)
>>>   static bool pciehp_device_replaced(struct controller *ctrl)
>>>   {
>>>          struct pci_dev *pdev __free(pci_dev_put);
>>> +       u64 dsn;
>>>          u32 reg;
>>>
>>>          pdev = pci_get_slot(ctrl->pcie->port->subordinate, PCI_DEVFN(0, 0));
>>>          if (!pdev)
>>> +               return false;
>>> +
>>> +       if (pci_read_config_dword(pdev, PCI_VENDOR_ID, &reg) == 0 &&
>>> +           !PCI_POSSIBLE_ERROR(reg) &&
>>> +           reg != (pdev->vendor | (pdev->device << 16)))
>>>                  return true;
>>>
>>> -       if (pci_read_config_dword(pdev, PCI_VENDOR_ID, &reg) ||
>>> -           reg != (pdev->vendor | (pdev->device << 16)) ||
>>> -           pci_read_config_dword(pdev, PCI_CLASS_REVISION, &reg) ||
>>> +       if (pci_read_config_dword(pdev, PCI_CLASS_REVISION, &reg) == 0 &&
>>> +           !PCI_POSSIBLE_ERROR(reg) &&
>>>              reg != (pdev->revision | (pdev->class << 8)))
>>>                  return true;
>>>
>>>          if (pdev->hdr_type == PCI_HEADER_TYPE_NORMAL &&
>>> -           (pci_read_config_dword(pdev, PCI_SUBSYSTEM_VENDOR_ID, &reg) ||
>>> -            reg != (pdev->subsystem_vendor | (pdev->subsystem_device << 16))))
>>> +           pci_read_config_dword(pdev, PCI_SUBSYSTEM_VENDOR_ID, &reg) == 0 &&
>>> +           !PCI_POSSIBLE_ERROR(reg) &&
>>> +           reg != (pdev->subsystem_vendor | (pdev->subsystem_device << 16)))
>>>                  return true;
>>>
>>> -       if (pci_get_dsn(pdev) != ctrl->dsn)
>>> +       if ((dsn = pci_get_dsn(pdev)) &&
>>> +           !PCI_POSSIBLE_ERROR(dsn) &&
>>> +           dsn != ctrl->dsn)
>>>                  return true;
>>>
>>>          return false;
>> Hi Lukas,
>>
>> Sorry for the late reply, just encountered a strong typhoon in my area
>> last week and can't check this in our lab.
>>
>> The patched pciehp_device_replaced() returns false at the end of the
>> function in my case.
>> Unplug the dock which is connected with a tbt storage won't be
>> considered as a replacement.
>>
>> But when I tried to replace the dock with the tbt storage during
>> suspend, it still returned false at the end of the function like
>> unplugged.
>>
>> BTW, it's a new model, so I think the ICM is used. And the reg is
>> 0xffffffff when unplugged.
> Hi Lukas,
>
> PCI_POSSIBLE_ERROR() always returns true no matter the device is
> replaced or unplugged
> It seems difficult to distinguish between when a device is replaced
> and when it's unplugged.

If DSN (Device Serial Number) is not optional extended capability, then
we could use it as a tag to know if the device is replaced or unplugged.

So it would be better to have something like DSN but not optional in spec.

Thanks,
Ethan

>
> Do you have any ideas to fix the issue?
> This issue is severe to me, because the system hangs almost everytime
> when daisy chain tbt devices are unplugged when suspended.
> Thanks.
>

  parent reply	other threads:[~2024-10-23  4:24 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-09-26 12:59 [PATCH] PCI: pciehp: Fix system hang on resume after hot-unplug during suspend Chia-Lin Kao (AceLan)
2024-09-26 13:23 ` Lukas Wunner
2024-09-27  7:33   ` AceLan Kao
2024-09-27  9:28     ` Lukas Wunner
2024-09-28 12:51       ` Lukas Wunner
2024-09-30  1:31         ` AceLan Kao
2024-10-01 11:02           ` Lukas Wunner
2024-10-01 11:03             ` Lukas Wunner
2024-10-07  4:34               ` AceLan Kao
2024-10-17  2:40                 ` AceLan Kao
2024-10-22 13:05                   ` AceLan Kao
2024-10-23  4:23                   ` Ethan Zhao [this message]
2024-09-30  3:27       ` AceLan Kao
2024-10-01 11:07         ` Lukas Wunner

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=3354e37e-c48a-4696-a074-2df9e625fc0c@linux.intel.com \
    --to=haifeng.zhao@linux.intel.com \
    --cc=acelan.kao@canonical.com \
    --cc=bhelgaas@google.com \
    --cc=ilpo.jarvinen@linux.intel.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pci@vger.kernel.org \
    --cc=lukas@wunner.de \
    /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).