From: Lukas Wunner <lukas@wunner.de>
To: Hongbo Yao <andy.xu@hj-micro.com>
Cc: bhelgaas@google.com, linux-pci@vger.kernel.org,
linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org, peter.du@hj-micro.com,
jemma.zhang@hj-micro.com
Subject: Re: [RFC PATCH] PCI: pciehp: Replace fixed delay with polling for slot power-off
Date: Thu, 19 Jun 2025 13:52:23 +0200 [thread overview]
Message-ID: <aFP598Yyl0el1uKh@wunner.de> (raw)
In-Reply-To: <20250619093228.283171-1-andy.xu@hj-micro.com>
On Thu, Jun 19, 2025 at 05:32:28PM +0800, Hongbo Yao wrote:
> Fixed 1-second delay in remove_board() fails to accommodate certain
> hardware like multi-host OCP cards, which exhibit longer power-off
> latencies.
Please name the affected product(s).
They don't seem to comply to the spec. How prevalent are they?
If there are only few deployed, quirks like this are probably
best addressed by an out-of-tree patch.
> Logs before fix:
> [157.778307] pcieport 0003:00:00.0: pciehp: pending interrupts 0x0001 from Slot Status
> [157.778321] pcieport 0003:00:00.0: pciehp: Slot(31): Attention button pressed
> [157.785445] pcieport 0003:00:00.0: pciehp: Slot(31): Powering off due to button press
> [157.798931] pcieport 000b:00:02.0: pciehp: pending interrupts 0x0001 from Slot Status
This log excerpt mixes messages from two separate hotplug ports
(0003:00:00.0 and 000b:00:02.0). Are these hotplug ports related?
If not, please reduce the log excerpt to a single hotplug port
to avoid confusion.
> --- a/drivers/pci/hotplug/pciehp_ctrl.c
> +++ b/drivers/pci/hotplug/pciehp_ctrl.c
> @@ -30,6 +30,25 @@
> #define SAFE_REMOVAL true
> #define SURPRISE_REMOVAL false
>
> +static void pciehp_wait_for_link_inactive(struct controller *ctrl)
> +{
> + u16 lnk_status;
> + int timeout = 10000, step = 20;
> +
> + do {
> + pcie_capability_read_word(ctrl->pcie->port, PCI_EXP_LNKSTA,
> + &lnk_status);
> +
> + if (!(lnk_status & PCI_EXP_LNKSTA_DLLLA))
> + return;
> +
> + msleep(step);
> + timeout -= step;
> + } while (timeout >= 0);
> +
> + ctrl_dbg(ctrl, "Timeout waiting for link inactive state\n");
> +}
Any chance you can use one of the existing helpers, such as
pcie_wait_for_link()?
Is the 10 second delay chosen arbitrarily or how did you come up
with it? How much time do the affected products really need?
> @@ -119,8 +138,11 @@ static void remove_board(struct controller *ctrl, bool safe_removal)
> * After turning power off, we must wait for at least 1 second
> * before taking any action that relies on power having been
> * removed from the slot/adapter.
> + *
> + * Extended wait with polling to ensure hardware has completed
> + * power-off sequence.
> */
> - msleep(1000);
> + pciehp_wait_for_link_inactive(ctrl);
>
> /* Ignore link or presence changes caused by power off */
> atomic_and(~(PCI_EXP_SLTSTA_DLLSC | PCI_EXP_SLTSTA_PDC),
Please keep the msleep(1000), that's the minimum we need to wait
per PCIe r6.3 sec 6.7.1.8.
Please make the extra wait for link down conditional on
ctrl->pcie->port->link_active_reporting. (DLLLA reporting is
optional for hotplug ports conforming to older spec revisions.)
Thanks,
Lukas
next prev parent reply other threads:[~2025-06-19 11:52 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-06-19 9:32 [RFC PATCH] PCI: pciehp: Replace fixed delay with polling for slot power-off Hongbo Yao
2025-06-19 11:52 ` Lukas Wunner [this message]
2025-06-20 5:54 ` Hongbo Yao
2025-06-23 18:00 ` 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=aFP598Yyl0el1uKh@wunner.de \
--to=lukas@wunner.de \
--cc=andy.xu@hj-micro.com \
--cc=bhelgaas@google.com \
--cc=jemma.zhang@hj-micro.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pci@vger.kernel.org \
--cc=peter.du@hj-micro.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.