From: Feng Tang <feng.tang@linux.alibaba.com>
To: Lukas Wunner <lukas@wunner.de>
Cc: Bjorn Helgaas <bhelgaas@google.com>,
Sathyanarayanan Kuppuswamy
<sathyanarayanan.kuppuswamy@linux.intel.com>,
Liguang Zhang <zhangliguang@linux.alibaba.com>,
Guanghui Feng <guanghuifeng@linux.alibaba.com>,
rafael@kernel.org, Markus Elfring <Markus.Elfring@web.de>,
lkp@intel.com, Jonathan Cameron <Jonathan.Cameron@huawei.com>,
ilpo.jarvinen@linux.intel.com, linux-pci@vger.kernel.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH v3 3/4] PCI/portdrv: Loose the condition check for disabling hotplug interrupts
Date: Wed, 26 Feb 2025 10:54:18 +0800 [thread overview]
Message-ID: <Z76CWifQmFIQugiZ@U-2FWC9VHC-2323.local> (raw)
In-Reply-To: <Z71CZyU11-cBXawr@wunner.de>
Hi Lukas,
On Tue, Feb 25, 2025 at 05:09:11AM +0100, Lukas Wunner wrote:
> On Mon, Feb 24, 2025 at 11:44:59AM +0800, Feng Tang wrote:
> > Currently when 'pcie_ports_native' and host's 'native_pcie_hotplug' are
> > both false, kernel will not disable PCIe hotplug interrupts. But as
> > those could be affected by software setup like kernel cmdline parameter,
> > remove the depency over them.
> [...]
> > --- a/drivers/pci/pcie/portdrv.c
> > +++ b/drivers/pci/pcie/portdrv.c
> > @@ -263,9 +263,9 @@ static int get_port_device_capability(struct pci_dev *dev)
> >
> > if (dev->is_hotplug_bridge &&
> > (pci_pcie_type(dev) == PCI_EXP_TYPE_ROOT_PORT ||
> > - pci_pcie_type(dev) == PCI_EXP_TYPE_DOWNSTREAM) &&
> > - (pcie_ports_native || host->native_pcie_hotplug)) {
> > - services |= PCIE_PORT_SERVICE_HP;
> > + pci_pcie_type(dev) == PCI_EXP_TYPE_DOWNSTREAM)) {
> > + if (pcie_ports_native || host->native_pcie_hotplug)
> > + services |= PCIE_PORT_SERVICE_HP;
> >
> > /*
> > * Disable hot-plug interrupts in case they have been enabled
>
> If the platform doesn't grant hotplug control to OSPM, OSPM isn't allowed
> to disable interrupts behind the platform's back.
>
> So this change doesn't seem safe and we should focus on finding out
> why the platform isn't granting hotplug control in the pci=nomsi case.
Yes. As discussed in https://lore.kernel.org/lkml/Z6ycYOKUeOECrcgb@U-2FWC9VHC-2323.local/
the last state is:
"
I tried to remove OSC_PCI_MSI_SUPPORT from ACPI_PCIE_REQ_SUPPORT, but
after negotiate_os_control(), the 'PCIeHotplug' control is still
disabled in the control capability after ACPI query_osc, run_osc
routines (I haven't figured out why yet), thus the pciehp severvice
driver can't be loader.
"
After talking with some firmware developer, the root cause is the
parameter OS passed to OSC control shows it doesn't support MSI, then
firmware doesn't grant hotplug control. The hardware here is a ARM
server. As different OEM/vendor (X86/ARM) may have different
implementaions of firmware, other firmware may make different decision.
Thanks,
Feng
next prev parent reply other threads:[~2025-02-26 2:54 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-02-24 3:44 [PATCH v3 0/4] PCIe hotplug interrupt related fixes Feng Tang
2025-02-24 3:44 ` [PATCH v3 1/4] PCI: portdrv: pciehp: Move PCIe hotplug command waiting logic to port driver Feng Tang
2025-02-24 15:06 ` Ilpo Järvinen
2025-02-25 8:18 ` Feng Tang
2025-02-24 3:44 ` [PATCH v3 2/4] PCI/portdrv: Add necessary wait for disabling hotplug events Feng Tang
2025-02-24 9:42 ` Markus Elfring
2025-02-24 15:00 ` Ilpo Järvinen
2025-02-25 5:51 ` Feng Tang
2025-02-24 18:12 ` Lukas Wunner
2025-02-25 3:06 ` Feng Tang
2025-02-25 4:01 ` Lukas Wunner
2025-02-25 4:42 ` Feng Tang
2025-02-28 6:29 ` Feng Tang
2025-02-28 7:14 ` Lukas Wunner
2025-02-28 9:33 ` Feng Tang
2025-02-28 10:01 ` Feng Tang
2025-02-24 3:44 ` [PATCH v3 3/4] PCI/portdrv: Loose the condition check for disabling hotplug interrupts Feng Tang
2025-02-24 9:47 ` Markus Elfring
2025-02-25 4:09 ` Lukas Wunner
2025-02-26 2:54 ` Feng Tang [this message]
2025-02-24 3:45 ` [PATCH v3 4/4] PCI: Disable PCIe hotplug interrupts early when msi is disabled Feng Tang
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=Z76CWifQmFIQugiZ@U-2FWC9VHC-2323.local \
--to=feng.tang@linux.alibaba.com \
--cc=Jonathan.Cameron@huawei.com \
--cc=Markus.Elfring@web.de \
--cc=bhelgaas@google.com \
--cc=guanghuifeng@linux.alibaba.com \
--cc=ilpo.jarvinen@linux.intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pci@vger.kernel.org \
--cc=lkp@intel.com \
--cc=lukas@wunner.de \
--cc=rafael@kernel.org \
--cc=sathyanarayanan.kuppuswamy@linux.intel.com \
--cc=zhangliguang@linux.alibaba.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox