[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20250321170919.GA1130592@bhelgaas>
Date: Fri, 21 Mar 2025 12:09:19 -0500
From: Bjorn Helgaas <helgaas@...nel.org>
To: Ilpo Järvinen <ilpo.jarvinen@...ux.intel.com>
Cc: Bjorn Helgaas <bhelgaas@...gle.com>,
"Rafael J. Wysocki" <rafael.j.wysocki@...el.com>,
Mika Westerberg <mika.westerberg@...ux.intel.com>,
linux-pci@...r.kernel.org, linux-kernel@...r.kernel.org,
Lukas Wunner <lukas@...ner.de>
Subject: Re: [PATCH v2 1/1] PCI/hotplug: Don't enable HPIE in poll mode
On Fri, Mar 21, 2025 at 06:21:14PM +0200, Ilpo Järvinen wrote:
> PCIe hotplug can operate in poll mode without interrupt handlers using
> a polling kthread only. The commit eb34da60edee ("PCI: pciehp: Disable
> hotplug interrupt during suspend") failed to consider that and enables
> HPIE (Hot-Plug Interrupt Enable) unconditionally when resuming the
> Port.
>
> Only set HPIE if non-poll mode is in use. This makes
> pcie_enable_interrupt() match how pcie_enable_notification() already
> handles HPIE.
>
> Fixes: eb34da60edee ("PCI: pciehp: Disable hotplug interrupt during suspend")
> Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@...ux.intel.com>
> Reviewed-by: Lukas Wunner <lukas@...ner.de>
Applied to pci/hotplug with subject:
PCI: pciehp: Don't enable HPIE when resuming in poll mode
to match the pciehp history.
Random things that I noticed while looking at this:
- It does make me wonder why we have both pcie_enable_interrupt()
and pcie_enable_notification(). Apparently we don't need to
restore the other PCI_EXP_SLTCTL bits when resuming? Maybe we
depend on some other restoration, e.g., pci_restore_pcie_state(),
that happens first?
That makes me worry that there's a window between
pci_restore_pcie_state() and pcie_enable_interrupt(). I suppose
we probably saved the pcie state after pcie_disable_interrupt(),
so HPIE would be disabled in the saved state.
- I also wonder about the fact that pci_restore_pcie_state() doesn't
account for Command Completed events, so we might write to Slot
Control too fast.
- It's annoying that pcie_enable_interrupt() and
pcie_disable_interrupt() are global symbols, a consequence of
pciehp being split across five files instead of being one, which
is also a nuisance for code browsing.
Also annoying that they are generically named, with no pciehp
connection (probably another consequence of being split into
several files).
- The eb34da60edee commit log hints at the reason for testing
pme_is_native(). Would be nice if there were also a comment in
the code about this because it's not 100% obvious why we test PME
support in the PCIe native hotplug driver.
- Also slightly weird that eb34da60edee added the pme_is_native()
tests in pciehp_suspend() and pciehp_resume(), but somewhere along
the line the suspend-side one got moved to
pciehp_disable_interrupt(), so they're no longer parallel for no
obvious reason.
- I forgot why we have both pcie_write_cmd() and
pcie_write_cmd_nowait() and how to decide which to use.
Whew, that was a lot. I feel unusually ignorant this morning.
> ---
>
> v2:
> - Dropped other hotplug fixes/changes (Lukas' approach/fix is better)
> - Fixed typo in shortlog
>
> drivers/pci/hotplug/pciehp_hpc.c | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/pci/hotplug/pciehp_hpc.c b/drivers/pci/hotplug/pciehp_hpc.c
> index bb5a8d9f03ad..28ab393af1c0 100644
> --- a/drivers/pci/hotplug/pciehp_hpc.c
> +++ b/drivers/pci/hotplug/pciehp_hpc.c
> @@ -842,7 +842,9 @@ void pcie_enable_interrupt(struct controller *ctrl)
> {
> u16 mask;
>
> - mask = PCI_EXP_SLTCTL_HPIE | PCI_EXP_SLTCTL_DLLSCE;
> + mask = PCI_EXP_SLTCTL_DLLSCE;
> + if (!pciehp_poll_mode)
> + mask |= PCI_EXP_SLTCTL_HPIE;
> pcie_write_cmd(ctrl, mask, mask);
> }
>
>
> base-commit: 2014c95afecee3e76ca4a56956a936e23283f05b
> --
> 2.39.5
>
Powered by blists - more mailing lists