From: Jason Gunthorpe <jgg@nvidia.com>
To: Tushar Dave <tdave@nvidia.com>
Cc: corbet@lwn.net, bhelgaas@google.com, paulmck@kernel.org,
akpm@linux-foundation.org, thuth@redhat.com, rostedt@goodmis.org,
xiongwei.song@windriver.com, vidyas@nvidia.com,
linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-pci@vger.kernel.org, vsethi@nvidia.com,
sdonthineni@nvidia.com
Subject: Re: [PATCH 1/1] PCI: Fix Extend ACS configurability
Date: Thu, 2 Jan 2025 14:40:09 -0400 [thread overview]
Message-ID: <20250102184009.GD5556@nvidia.com> (raw)
In-Reply-To: <20241213202942.44585-1-tdave@nvidia.com>
On Fri, Dec 13, 2024 at 12:29:42PM -0800, Tushar Dave wrote:
> diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt
> index dc663c0ca670..fc1c37910d1c 100644
> --- a/Documentation/admin-guide/kernel-parameters.txt
> +++ b/Documentation/admin-guide/kernel-parameters.txt
> @@ -4654,11 +4654,10 @@
> Format:
> <ACS flags>@<pci_dev>[; ...]
> Specify one or more PCI devices (in the format
> - specified above) optionally prepended with flags
> - and separated by semicolons. The respective
> - capabilities will be enabled, disabled or
> - unchanged based on what is specified in
> - flags.
> + specified above) prepended with flags and separated
> + by semicolons. The respective capabilities will be
> + enabled, disabled or unchanged based on what is
> + specified in flags.
>
> ACS Flags is defined as follows:
> bit-0 : ACS Source Validation
> @@ -4673,7 +4672,7 @@
> '1' – force enabled
> 'x' – unchanged
> For example,
> - pci=config_acs=10x
> + pci=config_acs=10x@pci:0:0
> would configure all devices that support
> ACS to enable P2P Request Redirect, disable
> Translation Blocking, and leave Source
Is this an unrelated change? The format of the command line shouldn't
be changed to fix the described bug, why is the documentation changed?
> static void __pci_config_acs(struct pci_dev *dev, struct pci_acs *caps,
> - const char *p, u16 mask, u16 flags)
> + const char *p, const u16 acs_mask, const u16 acs_flags)
> {
> + u16 flags = acs_flags;
> + u16 mask = acs_mask;
> char *delimit;
> int ret = 0;
>
> @@ -964,7 +965,7 @@ static void __pci_config_acs(struct pci_dev *dev, struct pci_acs *caps,
> return;
>
> while (*p) {
> - if (!mask) {
> + if (!acs_mask) {
> /* Check for ACS flags */
> delimit = strstr(p, "@");
> if (delimit) {
> @@ -972,6 +973,8 @@ static void __pci_config_acs(struct pci_dev *dev, struct pci_acs *caps,
> u32 shift = 0;
>
> end = delimit - p - 1;
> + mask = 0;
> + flags = 0;
>
> while (end > -1) {
> if (*(p + end) == '0') {
This function the entire fix, right? Because the routine was
clobbering acs_mask as it processed the earlier devices?
> @@ -1028,10 +1031,10 @@ static void __pci_config_acs(struct pci_dev *dev, struct pci_acs *caps,
>
> pci_dbg(dev, "ACS mask = %#06x\n", mask);
> pci_dbg(dev, "ACS flags = %#06x\n", flags);
> + pci_dbg(dev, "ACS control = %#06x\n", caps->ctrl);
>
> - /* If mask is 0 then we copy the bit from the firmware setting. */
> - caps->ctrl = (caps->ctrl & ~mask) | (caps->fw_ctrl & mask);
> - caps->ctrl |= flags;
> + caps->ctrl &= ~mask;
> + caps->ctrl |= (flags & mask);
And why delete fw_ctrl? Doesn't that break the unchanged
functionality?
Jason
next prev parent reply other threads:[~2025-01-02 18:40 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-12-13 20:29 [PATCH 1/1] PCI: Fix Extend ACS configurability Tushar Dave
2024-12-14 12:30 ` Vidya Sagar
2025-01-02 18:40 ` Jason Gunthorpe [this message]
2025-01-06 20:34 ` Tushar Dave
2025-01-06 20:53 ` Bjorn Helgaas
2025-01-08 2:34 ` Tushar Dave
2025-01-07 0:10 ` Jason Gunthorpe
2025-01-08 2:32 ` Tushar Dave
2025-01-08 15:10 ` Jason Gunthorpe
2025-01-09 3:13 ` Tushar Dave
2025-01-13 20:07 ` Jason Gunthorpe
2025-01-16 3:11 ` Tushar Dave
2025-01-16 19:01 ` Jason Gunthorpe
2025-01-17 1:21 ` Tushar Dave
2025-01-17 13:28 ` Jason Gunthorpe
2025-01-17 18:41 ` Tushar Dave
2025-01-02 23:26 ` Bjorn Helgaas
2025-01-06 20:45 ` Tushar Dave
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=20250102184009.GD5556@nvidia.com \
--to=jgg@nvidia.com \
--cc=akpm@linux-foundation.org \
--cc=bhelgaas@google.com \
--cc=corbet@lwn.net \
--cc=linux-doc@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pci@vger.kernel.org \
--cc=paulmck@kernel.org \
--cc=rostedt@goodmis.org \
--cc=sdonthineni@nvidia.com \
--cc=tdave@nvidia.com \
--cc=thuth@redhat.com \
--cc=vidyas@nvidia.com \
--cc=vsethi@nvidia.com \
--cc=xiongwei.song@windriver.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;
as well as URLs for NNTP newsgroup(s).