From: Alex Williamson <alex.williamson@redhat.com>
To: Mika Westerberg <mika.westerberg@linux.intel.com>
Cc: Bjorn Helgaas <bhelgaas@google.com>, linux-pci@vger.kernel.org
Subject: Re: [PATCH] PCI: Add ACS quirk for Intel 300 series chipset
Date: Thu, 16 Aug 2018 14:25:04 -0600 [thread overview]
Message-ID: <20180816142504.4e3d121c@t450s.home> (raw)
In-Reply-To: <20180816192805.GN2343@lahna.fi.intel.com>
On Thu, 16 Aug 2018 22:28:05 +0300
Mika Westerberg <mika.westerberg@linux.intel.com> wrote:
> On Thu, Aug 16, 2018 at 09:13:03AM -0600, Alex Williamson wrote:
> > static int pci_quirk_enable_intel_spt_pch_acs(struct pci_dev *dev)
> > {
> > int pos;
> > + u16 std_ctrl;
> > u32 cap, ctrl;
> >
> > if (!pci_quirk_intel_spt_pch_acs_match(dev))
> > @@ -4621,6 +4628,18 @@ static int pci_quirk_enable_intel_spt_pch_acs(struct pci_dev *dev)
> > if (!pos)
> > return -ENOTTY;
> >
> > + /* If the std control word has bits set or is writable, do not quirk */
> > + pci_read_config_word(dev, pos + PCI_ACS_CTRL, &std_ctrl);
> > + if (std_ctrl)
> > + return -ENOTTY;
> > +
> > + pci_write_config_word(dev, pos + PCI_ACS_CTRL, 0xff);
>
> I don't know ACS well but could the above have some unwanted
> side-effects, even if we write back zeroes below?
It can certainly influence in-flight packet routing, but at the point
we're performing this test, we're about to do that anyway. This should
only be happening during discovery and we're limited to a set of root
ports for this test, so we shouldn't have any drivers attached
downstream from here. For the majority of devices that would pass
through this quirk, we expect the register to behave as if it were
read-only so we can only potentially break the already broken C246 port
through here.
We could possibly refine this to fully replace pci_std_enable_acs(),
even for the matched Intel root ports that seem to be fixed by
attempting to set the requested flags at the standard location, test if
they stick, if so consider it done (exit success rather than -ENOTTY),
if not try the dword version. Thanks,
Alex
> > + pci_read_config_word(dev, pos + PCI_ACS_CTRL, &std_ctrl);
> > + if (std_ctrl) {
> > + pci_write_config_word(dev, pos + PCI_ACS_CTRL, 0);
> > + return -ENOTTY;
> > + }
> > +
> > pci_read_config_dword(dev, pos + PCI_ACS_CAP, &cap);
> > pci_read_config_dword(dev, pos + INTEL_SPT_ACS_CTRL, &ctrl);
> >
next prev parent reply other threads:[~2018-08-16 23:25 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-04-27 10:44 [PATCH] PCI: Add ACS quirk for Intel 300 series chipset Mika Westerberg
2018-04-27 18:10 ` Bjorn Helgaas
2018-04-29 7:03 ` Mika Westerberg
2018-08-15 21:21 ` Alex Williamson
2018-08-15 22:43 ` Alex Williamson
2018-08-16 6:10 ` Mika Westerberg
2018-08-16 15:13 ` Alex Williamson
2018-08-16 19:28 ` Mika Westerberg
2018-08-16 20:25 ` Alex Williamson [this message]
2018-08-17 9:37 ` Mika Westerberg
2018-09-05 9:58 ` Mika Westerberg
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=20180816142504.4e3d121c@t450s.home \
--to=alex.williamson@redhat.com \
--cc=bhelgaas@google.com \
--cc=linux-pci@vger.kernel.org \
--cc=mika.westerberg@linux.intel.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).