On Sun, Sep 25, 2011 at 11:56 PM, Benjamin Herrenschmidt
<benh@xxxxxxxxxxxxxxxxxxx> wrote:
> When configuring the PCIe settings for "performance", we allow parents
> to have a larger Max Payload Size than children and rely on children
> Max Read Request Size to not be larger than their own MPS to avoid
> having the host bridge generate responses they can't cope with.
>
> However, various drivers in Linux call pci_set_readrq() with arbitrary
> values, assuming this to be a simple performance tweak. This breaks
> under our "performance" configuration.
>
> Fix that by making sure the value programmed by pcie_set_readrq() is
> never larger than the configured MPS for that device.
Funny, I have a patch for this queued. Looks like you beat me to it.
>
> Signed-off-by: Benjamin Herrenschmidt <benh@xxxxxxxxxxxxxxxxxxx>
> ---
>
> diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c
> index 4e84fd4..d369316 100644
> --- a/drivers/pci/pci.c
> +++ b/drivers/pci/pci.c
> @@ -3203,8 +3203,6 @@ int pcie_set_readrq(struct pci_dev *dev, int rq)
> if (rq < 128 || rq > 4096 || !is_power_of_2(rq))
> goto out;
>
> - v = (ffs(rq) - 8) << 12;
> -
> cap = pci_pcie_cap(dev);
> if (!cap)
> goto out;
> @@ -3212,6 +3210,22 @@ int pcie_set_readrq(struct pci_dev *dev, int rq)
> err = pci_read_config_word(dev, cap + PCI_EXP_DEVCTL, &ctl);
> if (err)
> goto out;
> + /*
> + * If using the "performance" PCIe config, we clamp the
> + * read rq size to the max packet size to prevent the
> + * host bridge generating requests larger than we can
> + * cope with
> + */
> + if (pcie_bus_config == PCIE_BUS_PERFORMANCE) {
> + int mps = pcie_get_mps(dev);
> +
> + if (mps < 0)
> + return mps;
Shouldn't this return an error, not the mps? "goto out" is what I was using.
> + if (mps < rq)
> + rq = mps;
I had a dev_warn in there to notify the user.
> + }
> +
> + v = (ffs(rq) - 8) << 12;
>
> if ((ctl & PCI_EXP_DEVCTL_READRQ) != v) {
> ctl &= ~PCI_EXP_DEVCTL_READRQ;
>
>
>
--
To unsubscribe from this list: send the line "unsubscribe linux-pci" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
