Re: [PATCH v2 1/1] PCI/hotplug: Don't enable HPIE in poll mode

[Bjorn Helgaas <helgaas@kernel.org>]

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@linux.intel.com>
> Reviewed-by: Lukas Wunner <lukas@wunner.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
>