From: "Kuppuswamy, Sathyanarayanan" <email@example.com> To: Lukas Wunner <firstname.lastname@example.org>, Bjorn Helgaas <email@example.com>, Dan Williams <firstname.lastname@example.org> Cc: Ethan Zhao <email@example.com>, Sinan Kaya <firstname.lastname@example.org>, Ashok Raj <email@example.com>, Keith Busch <firstname.lastname@example.org>, email@example.com, Russell Currey <firstname.lastname@example.org>, Oliver O'Halloran <email@example.com>, Stuart Hayes <firstname.lastname@example.org>, Mika Westerberg <email@example.com> Subject: Re: [PATCH] PCI: pciehp: Ignore Link Down/Up caused by DPC Date: Tue, 27 Apr 2021 17:39:43 -0700 [thread overview] Message-ID: <firstname.lastname@example.org> (raw) In-Reply-To: <email@example.com> Hi Bjorn, On 3/30/21 1:53 PM, Kuppuswamy, Sathyanarayanan wrote: >> Downstream Port Containment (PCIe Base Spec, sec. 6.2.10) disables the >> link upon an error and attempts to re-enable it when instructed by the >> DPC driver. >> >> A slot which is both DPC- and hotplug-capable is currently brought down >> by pciehp once DPC is triggered (due to the link change) and brought up >> on successful recovery. That's undesirable, the slot should remain up >> so that the hotplugged device remains bound to its driver. DPC notifies >> the driver of the error and of successful recovery in pcie_do_recovery() >> and the driver may then restore the device to working state. >> >> Moreover, Sinan points out that turning off slot power by pciehp may >> foil recovery by DPC: Power off/on is a cold reset concurrently to >> DPC's warm reset. Sathyanarayanan reports extended delays or failure >> in link retraining by DPC if pciehp brings down the slot. >> >> Fix by detecting whether a Link Down event is caused by DPC and awaiting >> recovery if so. On successful recovery, ignore both the Link Down and >> the subsequent Link Up event. >> >> Afterwards, check whether the link is down to detect surprise-removal or >> another DPC event immediately after DPC recovery. Ensure that the >> corresponding DLLSC event is not ignored by synthesizing it and >> invoking irq_wake_thread() to trigger a re-run of pciehp_ist(). >> >> The IRQ threads of the hotplug and DPC drivers, pciehp_ist() and >> dpc_handler(), race against each other. If pciehp is faster than DPC, >> it will wait until DPC recovery completes. >> >> Recovery consists of two steps: The first step (waiting for link >> disablement) is recognizable by pciehp through a set DPC Trigger Status >> bit. The second step (waiting for link retraining) is recognizable >> through a newly introduced PCI_DPC_RECOVERING flag. >> >> If DPC is faster than pciehp, neither of the two flags will be set and >> pciehp may glean the recovery status from the new PCI_DPC_RECOVERED flag. >> The flag is zero if DPC didn't occur at all, hence DLLSC events are not >> ignored by default. >> >> This commit draws inspiration from previous attempts to synchronize DPC >> with pciehp: >> >> By Sinan Kaya, August 2018: >> https://firstname.lastname@example.org/ >> >> By Ethan Zhao, October 2020: >> https://email@example.com/ >> >> By Sathyanarayanan Kuppuswamy, March 2021: >> https://firstname.lastname@example.org/ >> > Looks good to me. This patch fixes the reported issue in our environment. > > Reviewed-by: Kuppuswamy Sathyanarayanan <email@example.com> > Tested-by: Kuppuswamy Sathyanarayanan <firstname.lastname@example.org> Any update on this patch? is this queued for merge? One of our customers is looking for this fix. So wondering about the status. -- Sathyanarayanan Kuppuswamy Linux Kernel Developer
next prev parent reply other threads:[~2021-04-28 0:39 UTC|newest] Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top 2021-03-28 8:52 Lukas Wunner 2021-03-30 20:53 ` Kuppuswamy, Sathyanarayanan 2021-04-28 0:39 ` Kuppuswamy, Sathyanarayanan [this message] 2021-04-28 1:42 ` Zhao, Haifeng 2021-04-28 10:08 ` Yicong Yang 2021-04-28 14:40 ` Lukas Wunner 2021-04-29 11:29 ` Yicong Yang 2021-04-29 12:40 ` Zhao, Haifeng 2021-04-29 19:42 ` Lukas Wunner 2021-04-30 8:47 ` Yicong Yang 2021-04-30 12:15 ` Lukas Wunner 2021-04-29 19:36 ` Keith Busch 2021-04-29 20:16 ` Lukas Wunner 2021-04-29 21:16 ` Keith Busch
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 \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --subject='Re: [PATCH] PCI: pciehp: Ignore Link Down/Up caused by DPC' \ /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
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).