linux-pci.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Lucas Stach <l.stach@pengutronix.de>
To: Alexandre Courbot <gnurou@gmail.com>
Cc: Thierry Reding <thierry.reding@gmail.com>,
	Bjorn Helgaas <bhelgaas@google.com>,
	Stephen Warren <swarren@wwwdotorg.org>,
	"linux-tegra@vger.kernel.org" <linux-tegra@vger.kernel.org>,
	linux-pci@vger.kernel.org
Subject: Re: [PATCH 1/2] PCI: tegra: apply relaxed ordering fixup only on Tegra
Date: Tue, 09 Dec 2014 11:28:17 +0100	[thread overview]
Message-ID: <1418120897.2741.1.camel@pengutronix.de> (raw)
In-Reply-To: <CAAVeFu+sYnhMEmDSPvinbP-BQQnqAu6rpEVgaLx25Y3UtGVUwQ@mail.gmail.com>

Am Dienstag, den 09.12.2014, 12:23 +0900 schrieb Alexandre Courbot:
> Hi Lucas,
> 
> Apologies for taking so long to come back to this. The patch looks ok
> to me, just a minor comment about the Tegra PCI detection:
> 
> On Fri, Nov 14, 2014 at 4:37 AM, Lucas Stach <l.stach@pengutronix.de> wrote:
> > The fixup to enable relaxed ordering on all PCI devices was
> > executed unconditionally if the Tegra PCI host driver was
> > built into the kernel. This doesn't play nice with a
> > multiplatform kernel executed on other platforms which
> > may not need this fixup.
> >
> > Make sure to only apply the fixup if the root port is
> > a Tegra.
> >
> > Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
> > ---
> >  drivers/pci/host/pci-tegra.c | 26 +++++++++++++++++++++++++-
> >  1 file changed, 25 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/pci/host/pci-tegra.c b/drivers/pci/host/pci-tegra.c
> > index 3d43874319be..d5a14f22ebb8 100644
> > --- a/drivers/pci/host/pci-tegra.c
> > +++ b/drivers/pci/host/pci-tegra.c
> > @@ -647,10 +647,34 @@ DECLARE_PCI_FIXUP_EARLY(PCI_VENDOR_ID_NVIDIA, 0x0bf1, tegra_pcie_fixup_class);
> >  DECLARE_PCI_FIXUP_EARLY(PCI_VENDOR_ID_NVIDIA, 0x0e1c, tegra_pcie_fixup_class);
> >  DECLARE_PCI_FIXUP_EARLY(PCI_VENDOR_ID_NVIDIA, 0x0e1d, tegra_pcie_fixup_class);
> >
> > +static int tegra_pcie_root_is_tegra(struct pci_dev *dev)
> > +{
> > +       struct pci_bus *bus = dev->bus;
> > +       struct pci_dev *root_bridge;
> > +
> > +       /* walk up the PCIe hierarchy to the first level below the root bus */
> > +       while (bus->parent && bus->parent->self)
> > +               bus = bus->parent;
> > +
> > +       /*
> > +        * If there is no bridge on the bus the passed device is the root
> > +        * bridge itself.
> > +        */
> > +       root_bridge = bus->self ? bus->self : dev;
> > +       if (root_bridge->vendor == PCI_VENDOR_ID_NVIDIA &&
> > +           (root_bridge->device == 0x0bf0 || root_bridge->device == 0x0bf1 ||
> > +            root_bridge->device == 0x0e1c || root_bridge->device == 0x0e1d ||
> > +            root_bridge->device == 0x0e12 || root_bridge->device == 0x0e13))
> > +               return 1;
> 
> I am not very familiar with PCI so sorry if these are stupid
> questions, but where do these device IDs come from? Are they needed at
> all, e.g. can't you just test against root_bridge->vendor ==
> PCI_VENDOR_ID_NVIDIA to detect a NVIDIA root? Is the list susceptible
> to increase as new chips get released? If that's the case, how can we
> make sure we won't forget to update it?
> 

The device IDs are assigned by NVIDIA HW for the different Tegra PCI
generation/link width combinations. Note that the K1 TRM is wrong as it
still lists the T30 device IDs, instead of the ones used on K1.

While we technically could test only against vendor==nvidia I don't
think it is entirely safe. As this is a PCI fixup it will get executed
on every device running a kernel including this PCI host bridge driver. 

So only testing for the vendor assumes that every ARM device with a PCI
host bridge built by NVIDIA will be a Tegra. Do you think this is a
reasonable assertion? I'm on the fence here.
 
> If you need to test against the device ID, it might be more legible
> (and easier to update) if you use a switch case, e.g:
> 
>     if (root_bridge->vendor != PCI_VENDOR_ID_NVIDIA)
>         return 0;
>     switch (root_bridge->device) {
>     case 0x0bf0:
>     case 0x0bf1:
>     case 0x0e1c:
>     case 0x0e1d:
>     case 0x0e12:
>     case 0x0e12:
>         return 1;
>     default:
>         return 0;
>     }
> 
Right, this looks nicer and easier to extend. I'll have to think about
if we need the device IDs at all and respin accordingly.

> Otherwise I have not noticed any problem using this patch.
> 
> Tested-by: Alexandre Courbot <acourbot@nvidia.com>

Thanks,
Lucas

-- 
Pengutronix e.K.             | Lucas Stach                 |
Industrial Linux Solutions   | http://www.pengutronix.de/  |


  reply	other threads:[~2014-12-09 10:28 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-11-13 19:37 [PATCH 0/2] Tegra PCI multiplatform fixes Lucas Stach
2014-11-13 19:37 ` [PATCH 1/2] PCI: tegra: apply relaxed ordering fixup only on Tegra Lucas Stach
2014-12-09  3:23   ` Alexandre Courbot
2014-12-09 10:28     ` Lucas Stach [this message]
2014-12-10 12:13       ` Thierry Reding
2014-12-10 12:23         ` Lucas Stach
2014-12-10 14:11           ` Thierry Reding
2014-12-10 14:15             ` Lucas Stach
2014-12-10 14:31               ` Thierry Reding
2014-12-09 22:31   ` Bjorn Helgaas
2014-11-13 19:37 ` [PATCH 2/2] PCI: tegra: remove bogus bridge setup fixup Lucas Stach
2014-12-09  3:17   ` Alexandre Courbot
2014-12-10 12:16   ` Thierry Reding
2014-12-10 21:14   ` Bjorn Helgaas
2014-12-05 19:06 ` [PATCH 0/2] Tegra PCI multiplatform fixes Lucas Stach

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=1418120897.2741.1.camel@pengutronix.de \
    --to=l.stach@pengutronix.de \
    --cc=bhelgaas@google.com \
    --cc=gnurou@gmail.com \
    --cc=linux-pci@vger.kernel.org \
    --cc=linux-tegra@vger.kernel.org \
    --cc=swarren@wwwdotorg.org \
    --cc=thierry.reding@gmail.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).