linux-pci.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Bjorn Helgaas <helgaas@kernel.org>
To: Huacai Chen <chenhuacai@gmail.com>
Cc: Huacai Chen <chenhuacai@loongson.cn>,
	Bjorn Helgaas <bhelgaas@google.com>,
	linux-pci <linux-pci@vger.kernel.org>,
	Xuefeng Li <lixuefeng@loongson.cn>,
	Jiaxun Yang <jiaxun.yang@flygoat.com>
Subject: Re: [PATCH V4 3/4] PCI: Improve the MRRS quirk for LS7A
Date: Tue, 29 Jun 2021 14:42:52 -0500	[thread overview]
Message-ID: <20210629194252.GA4079683@bjorn-Precision-5520> (raw)
In-Reply-To: <CAAhV-H72fyOHGyOMk7OE5HmZUec5J1vE2K3D2bxrerikk9QBUw@mail.gmail.com>

On Tue, Jun 29, 2021 at 11:20:45AM +0800, Huacai Chen wrote:
> On Tue, Jun 29, 2021 at 6:35 AM Bjorn Helgaas <helgaas@kernel.org> wrote:
> > On Mon, Jun 28, 2021 at 06:10:26PM +0800, Huacai Chen wrote:
> > > In new revision of LS7A, some PCIe ports support larger value than 256,
> > > but their maximum supported MRRS values are not detectable. Moreover,
> > > the current loongson_mrrs_quirk() cannot avoid devices increasing its
> > > MRRS after pci_enable_device(), and some devices (e.g. Realtek 8169)
> > > will actually set a big value in its driver. So the only possible way
> > > is configure MRRS of all devices in BIOS, and add a PCI bus flag (i.e.,
> > > PCI_BUS_FLAGS_NO_INC_MRRS) to stop the increasing MRRS operations.
> > >
> > > However, according to PCIe Spec, it is legal for an OS to program any
> > > value for MRRS, and it is also legal for an endpoint to generate a Read
> > > Request with any size up to its MRRS. As the hardware engineers say, the
> > > root cause here is LS7A doesn't break up large read requests. In detail,
> > > LS7A PCIe port reports CA (Completer Abort) if it receives a Memory Read
> > > request with a size that's "too big" (Yes, that is a problem in the LS7A
> > > hardware design).
> > >
> > > Signed-off-by: Huacai Chen <chenhuacai@loongson.cn>
> > > ---
> > >  drivers/pci/pci.c    |  5 +++++
> > >  drivers/pci/quirks.c | 41 +++++++++++------------------------------
> > >  include/linux/pci.h  |  1 +
> > >  3 files changed, 17 insertions(+), 30 deletions(-)
> > >
> > > diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c
> > > index 8d4ebe095d0c..0f1ff4a6fe44 100644
> > > --- a/drivers/pci/pci.c
> > > +++ b/drivers/pci/pci.c
> > > @@ -5812,6 +5812,11 @@ int pcie_set_readrq(struct pci_dev *dev, int rq)
> > >
> > >       v = (ffs(rq) - 8) << 12;
> > >
> > > +     if (dev->bus->bus_flags & PCI_BUS_FLAGS_NO_INC_MRRS) {
> > > +             if (rq > pcie_get_readrq(dev))
> > > +                     return -EINVAL;
> >
> > I'd prefer to make this simpler, so we just never touch MRRS at all,
> > like this:
> >
> >   @@ -5785,6 +5785,9 @@ int pcie_set_readrq(struct pci_dev *dev, int rq)
> >           u16 v;
> >           int ret;
> >
> >   +       if (<loongson-quirk>)
> >   +               return -EINVAL;
> >   +
> >           if (rq < 128 || rq > 4096 || !is_power_of_2(rq))
> >                   return -EINVAL;
> >
> > What would that break?  It's just harder to analyze the behavior if it
> > depends on what the driver is trying to do.  AFAIK, devices should
> > *work* correctly with any value of MRRS.
>
> This disables both increase and decrease MRRS, and so make
> pcie_bus_config completely useless. I think allowing decrease MRRS is
> useful in the PEER2PEER case.

True.  The MPS/MRRS algorithm, including pcie_bus_config, is very
complicated and poorly understood, so I'm a little hesitant to
complicate it even more with one-off quirks.  I'd really prefer to
push LS7A off into a corner and have the generic MPS/MRRS algorithm
ignore it completely.

But I guess just keeping pcie_set_readrq() from *increasing* MRRS
doesn't add too much complication and should always be safe.

Bjorn

  reply	other threads:[~2021-06-29 19:42 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-06-28 10:10 [PATCH V4 0/4] PCI: Loongson-related pci quirks Huacai Chen
2021-06-28 10:10 ` [PATCH V4 1/4] PCI/portdrv: Don't disable device during shutdown Huacai Chen
2021-06-28 10:10 ` [PATCH V4 2/4] PCI: Move loongson pci quirks to quirks.c Huacai Chen
2021-06-28 10:13   ` Jiaxun Yang
2021-06-28 10:38     ` Huacai Chen
2021-06-28 10:41       ` Jiaxun Yang
2021-06-28 10:55         ` Huacai Chen
2021-06-28 10:57           ` Jiaxun Yang
2021-06-28 10:58   ` Jiaxun Yang
2021-06-28 10:10 ` [PATCH V4 3/4] PCI: Improve the MRRS quirk for LS7A Huacai Chen
2021-06-28 10:59   ` Jiaxun Yang
2021-06-28 22:35   ` Bjorn Helgaas
2021-06-29  3:20     ` Huacai Chen
2021-06-29 19:42       ` Bjorn Helgaas [this message]
2021-06-28 10:10 ` [PATCH V4 4/4] PCI: Add quirk for multifunction devices of LS7A Huacai Chen
2021-06-28 10:59   ` Jiaxun Yang

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=20210629194252.GA4079683@bjorn-Precision-5520 \
    --to=helgaas@kernel.org \
    --cc=bhelgaas@google.com \
    --cc=chenhuacai@gmail.com \
    --cc=chenhuacai@loongson.cn \
    --cc=jiaxun.yang@flygoat.com \
    --cc=linux-pci@vger.kernel.org \
    --cc=lixuefeng@loongson.cn \
    /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).