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: Wed, 8 Jan 2025 11:10:21 -0400 [thread overview]
Message-ID: <20250108151021.GS5556@nvidia.com> (raw)
In-Reply-To: <c9aeb7a0-5fef-49a5-9ebb-c0e7f3b0fd3e@nvidia.com>
On Tue, Jan 07, 2025 at 06:32:42PM -0800, Tushar Dave wrote:
>
>
> On 1/6/25 16:10, Jason Gunthorpe wrote:
> > On Mon, Jan 06, 2025 at 12:34:00PM -0800, Tushar Dave wrote:
> >
> > > > > @@ -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?
> > >
> > > No, it does not break the unchanged functionality. I removed it because it
> > > is not needed after my fix.
> >
> > I mean, the whole hunk above is not needed, right? Or at least I don't
> > see how it relates to your commit message..
>
> Without the above hunk, there are cases where ACS flags do not get set
> correctly. Here is the example test case without above hunk in my patch (IOW
> keeping fw_ctrl changes as it is like original code plus pci_dbg to print
> debug info)
Isn't that because the bit logic in the code is wrong?
> - /* If mask is 0 then we copy the bit from the firmware setting. */
> - caps->ctrl = (caps->ctrl & ~mask) | (caps->fw_ctrl & mask);
That comment doesn't match the calculation at all.
> > > If it helps, using 'config_acs' the code only allows to configures the lower
> > > 7 bits of ACS ctrl for the specified PCI device(s).
> > > The bits other than the lower 7 bits of ACS ctrl remain unchanged.
> > > The bits specified with 'x' or 'X' that are within the 7 lower bits remain
> > > unchanged. Trying to configure bits other than lower 7 bits generates an
> > > error message "Invalid ACS flags specified"
> >
> > But the fw_ctrl was how the x behavior was supposed to be implemented,
> > IIRC there were cases where you could not just rely on caps->ctrl as
> > something prior had alreaded changed it.
>
> I read your comment in https://lore.kernel.org/all/20240508131427.GH4650@nvidia.com/
>
> Looking at the current code, the sequence begin with function
> 'pci_enable_acs()' that reads PCI_ACS_CTRL into caps->ctrl and invoke the
> below three functions that prepares caps->ctrl before writing to ACS CTRL
> reg.
caps->ctrl is supposed to be the target setting and it is supposed to
evolve as it progresses.
> i.e.
> pci_std_enable_acs()
> __pci_config_acs(dev, &caps,disable_acs_redir_param,...)
> __pci_config_acs(dev, &caps, config_acs_param, 0, 0)
>
> Here kernel command line takes precedence over 'pci_std_enable_acs()'.
> 'config_acs' takes precedence over 'disable_acs_redir'. IOW, if config_acs
> param is used then it takes the final control over what value is getting
> written to ACS CTRL reg and that is how it should be, no?
Yes, but X in config_acs should copy the FW value not the value
modified by disable_acs_redir_param
Jason
next prev parent reply other threads:[~2025-01-08 15:10 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
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 [this message]
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=20250108151021.GS5556@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.