From: Bjorn Helgaas <helgaas@kernel.org>
To: Songyang Li <leesongyang@outlook.com>
Cc: bhelgaas@google.com, linux-kernel@vger.kernel.org,
linux-pci@vger.kernel.org
Subject: Re: [PATCH] PCI: Cancel compilation restrictions on function pcie_clear_device_status
Date: Wed, 12 Jun 2024 15:14:32 -0500 [thread overview]
Message-ID: <20240612201432.GA1035119@bhelgaas> (raw)
In-Reply-To: <TY3P286MB275469F17C8C5389C18313BBB4C02@TY3P286MB2754.JPNP286.PROD.OUTLOOK.COM>
On Wed, Jun 12, 2024 at 11:15:43PM +0800, Songyang Li wrote:
> On Tue, 11 Jun 2024 17:34:18 -0500, Bjorn Helgaas wrote:
> > Unindent this.
>
> > Add "()" after function names.
>
> > Please explain what this patch does and why we want it. I can see
> > from the patch that it makes it so pcie_clear_device_status() is
> > always compiled, but the commit log should say that and should say why
> > we need that.
>
> Thank you for reminding to add "()" after function pcie_clear_device_status.
> The following is a revised patch,and it explains why we need that.
> Thanks,
>
> Songyang Li
>
> From 3c1340522565a44ef25d2045e5bee2c0bdb72b32 Mon Sep 17 00:00:00 2001
> From: Songyang Li <leesongyang@outlook.com>
> Date: Wed, 12 Jun 2024 22:29:51 +0800
> Subject: [PATCH] PCI: Cancel compilation restrictions on function
> pcie_clear_device_status()
>
> Some PCIe devices do not have AER capabilities, but they have
> device status registers. The PCIe device status register and
> AER register are independent PCIe capabilities, so it is
> unreasonable to use CONFIG_PCIEAER for compilation control of
> pcie_clear_device_status(), although which is currently only
> used in the "aer.c", "edr.c", and "err.c". Some operating system
> configurations do not enable the AER feature, but still expect to
> use the device status register for simple RAS. In this case,
> pcie_clear_device_status() can be used to clear the device status
> regs, so this patch can meet the requirements of this scenario.
I think all current any callers of pcie_clear_device_status() are also
under CONFIG_PCIEAER, so I don't think this fixes a current problem.
As you point out, it might make sense to use
pcie_clear_device_status() even without AER, but I think we should
include this change at the time when we add such a use.
If I'm missing a use with the current kernel, let me know.
> Signed-off-by: Songyang Li <leesongyang@outlook.com>
> ---
> drivers/pci/pci.c | 8 ++++++--
> 1 file changed, 6 insertions(+), 2 deletions(-)
> mode change 100644 => 100755 drivers/pci/pci.c
>
> diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c
> old mode 100644
> new mode 100755
> index 35fb1f17a589..e6de55be4c45
> --- a/drivers/pci/pci.c
> +++ b/drivers/pci/pci.c
> @@ -2263,7 +2263,12 @@ int pci_set_pcie_reset_state(struct pci_dev *dev, enum pcie_reset_state state)
> }
> EXPORT_SYMBOL_GPL(pci_set_pcie_reset_state);
>
> -#ifdef CONFIG_PCIEAER
> +/**
> + * pcie_clear_device_status - Clear device status.
> + * @dev: the PCI device.
> + *
> + * Clear the device status for the PCI device.
> + */
> void pcie_clear_device_status(struct pci_dev *dev)
> {
> u16 sta;
> @@ -2271,7 +2276,6 @@ void pcie_clear_device_status(struct pci_dev *dev)
> pcie_capability_read_word(dev, PCI_EXP_DEVSTA, &sta);
> pcie_capability_write_word(dev, PCI_EXP_DEVSTA, sta);
> }
> -#endif
>
> /**
> * pcie_clear_root_pme_status - Clear root port PME interrupt status.
> --
> 2.34.1
>
next prev parent reply other threads:[~2024-06-12 20:14 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-06-11 15:15 [PATCH] PCI: Cancel compilation restrictions on function pcie_clear_device_status Songyang Li
2024-06-11 22:34 ` Bjorn Helgaas
2024-06-12 15:15 ` Songyang Li
2024-06-12 20:14 ` Bjorn Helgaas [this message]
2024-06-15 3:13 ` Songyang Li
2024-06-15 21:26 ` Bjorn Helgaas
2024-06-17 13:35 ` Songyang Li
2024-06-17 16:31 ` Bjorn Helgaas
2024-06-23 3:28 ` Songyang Li
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=20240612201432.GA1035119@bhelgaas \
--to=helgaas@kernel.org \
--cc=bhelgaas@google.com \
--cc=leesongyang@outlook.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pci@vger.kernel.org \
/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