All of lore.kernel.org
 help / color / mirror / Atom feed
From: Alex Williamson <alex.williamson-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
To: Lucas Stach <l.stach-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>
Cc: Bjorn Helgaas <bhelgaas-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org>,
	Thierry Reding
	<thierry.reding-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>,
	Stephen Warren <swarren-3lzwWm7+Weoh9ZMKESR00Q@public.gmane.org>,
	Alexandre Courbot
	<gnurou-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>,
	linux-tegra-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	linux-pci-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
Subject: Re: [PATCH v4 1/2] PCI: add helper function to find root port for device
Date: Tue, 31 Mar 2015 08:09:53 -0600	[thread overview]
Message-ID: <1427810993.5567.90.camel@redhat.com> (raw)
In-Reply-To: <1427804588.3370.19.camel-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>

On Tue, 2015-03-31 at 14:23 +0200, Lucas Stach wrote:
> Am Montag, den 30.03.2015, 10:52 -0600 schrieb Alex Williamson:
> > On Mon, 2015-03-30 at 18:06 +0200, Lucas Stach wrote:
> > > Am Montag, den 30.03.2015, 08:33 -0600 schrieb Alex Williamson:
> > > > On Mon, 2015-03-30 at 12:55 +0200, Lucas Stach wrote:
> > > > > This adds a simple way to get the root port a given device
> > > > > is connected to.
> > > > > 
> > > > > Signed-off-by: Lucas Stach <l.stach-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>
> > > > > ---
> > > > > v2: new patch in v2
> > > > > v3: rename to pci_find_rootport to fit better with other API
> > > > > v4: - rename to make it obvious that this function is PCIe specific
> > > > >     - fixes wrong assumption about what is a root bus in the presence
> > > > >       virtual buses
> > > > > ---
> > > > >  drivers/pci/search.c | 20 ++++++++++++++++++++
> > > > >  include/linux/pci.h  |  1 +
> > > > >  2 files changed, 21 insertions(+)
> > > > > 
> > > > > diff --git a/drivers/pci/search.c b/drivers/pci/search.c
> > > > > index a20ce7d5e2a7..d7c599103ae1 100644
> > > > > --- a/drivers/pci/search.c
> > > > > +++ b/drivers/pci/search.c
> > > > > @@ -384,3 +384,23 @@ int pci_dev_present(const struct pci_device_id *ids)
> > > > >  	return 0;
> > > > >  }
> > > > >  EXPORT_SYMBOL(pci_dev_present);
> > > > > +
> > > > > +/**
> > > > > + * pcie_find_root_port - Returns the root port the given device is connected to.
> > > > > + * @dev: PCI device for which the root port should be found.
> > > > > + */
> > > > > +struct pci_dev *pcie_find_root_port(struct pci_dev *dev)
> > > > > +{
> > > > > +	struct pci_bus *bus = dev->bus;
> > > > > +
> > > > > +	/* if this device is located on the root bus, it is a root port */
> > > > > +	if (pci_is_root_bus(bus))
> > > > > +		return dev;
> > > > 
> > > > It could also be a root complex endpoint or a conventional PCI
> > > > device/bridge sitting on the host bridge bus.
> > > 
> > > > > +
> > > > > +	/* walk up the PCI hierarchy to the first level below the root */
> > > > > +	while (bus->parent && bus->parent->parent)
> > > > > +		bus = bus->parent;
> > > > > +
> > > > > +	return bus->self;
> > > > > +}
> > > > > +EXPORT_SYMBOL(pcie_find_root_port);
> > > > 
> > > > IMHO, this makes too many assumptions about the topology that it's
> > > > working with for a generic interface.  Your usage may be fairly fixed,
> > > > but there are too many cases where it could return something that's not
> > > > a root port as a general interface.  Thanks,
> > > > 
> > > I'm open to suggestions on how to improve the detection. I really need
> > > something which works reliable in the majority of cases, as the Tegra
> > > quirk should not be executed on other platforms.
> > > 
> > > Do you think filtering out EP devices and conventional PCI bridges on
> > > the root bus is enough?
> > 
> > I'm actually pretty confused by the implementation of the quirk as well,
> > why do you even need this pcie_find_root_port() function?  Your fixup is
> > called for every single PCI device in the system, so why do you need to
> > go to the trouble of scanning the topology for the root port?  You'll be
> > passed the root port eventually and it will match your ID table w/o any
> > extra effort.  As coded, you're calling the set capability function
> > multiple times per root port, once for itself and once for each device
> > below it.
> > 
> > Personally, I'd probably do away with the table, declare a fixup for
> > each entry for the specific vendor/device ID, and make a simple quirk
> > callback that sets the capability bit.  Just my preference though.
> > Thanks,
> > 
> No, you missed the point of the fixup here.
> 
> We need to apply this fixup on every device in the system if the root
> port is a Tegra. So the fixup needs to get called for every device,
> filtering on a specific vendor/device ID is not possible.
> 
> But on the other hand this fixup may be compiled into a multiplatform
> kernel. If this kernel is strated on a device which isn't a Tegra (and
> so has no Tegra root port) we don't want to apply the fixup at all.

Yes, you're right, sorry for the misinterpretation.  So the quirk works
as expected, but I think at a minimum the helper function needs to be
renamed to something like pci_find_root_bus_dev() since there is no
attempt made to verify whether the returned device is actually a root
port.  If you don't support hotplug, you could also apply the quirk from
the root port down instead of searching from every device up.  Thanks,

Alex

WARNING: multiple messages have this Message-ID (diff)
From: Alex Williamson <alex.williamson@redhat.com>
To: Lucas Stach <l.stach@pengutronix.de>
Cc: Bjorn Helgaas <bhelgaas@google.com>,
	Thierry Reding <thierry.reding@gmail.com>,
	Stephen Warren <swarren@wwwdotorg.org>,
	Alexandre Courbot <gnurou@gmail.com>,
	linux-tegra@vger.kernel.org, linux-pci@vger.kernel.org
Subject: Re: [PATCH v4 1/2] PCI: add helper function to find root port for device
Date: Tue, 31 Mar 2015 08:09:53 -0600	[thread overview]
Message-ID: <1427810993.5567.90.camel@redhat.com> (raw)
In-Reply-To: <1427804588.3370.19.camel@pengutronix.de>

On Tue, 2015-03-31 at 14:23 +0200, Lucas Stach wrote:
> Am Montag, den 30.03.2015, 10:52 -0600 schrieb Alex Williamson:
> > On Mon, 2015-03-30 at 18:06 +0200, Lucas Stach wrote:
> > > Am Montag, den 30.03.2015, 08:33 -0600 schrieb Alex Williamson:
> > > > On Mon, 2015-03-30 at 12:55 +0200, Lucas Stach wrote:
> > > > > This adds a simple way to get the root port a given device
> > > > > is connected to.
> > > > > 
> > > > > Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
> > > > > ---
> > > > > v2: new patch in v2
> > > > > v3: rename to pci_find_rootport to fit better with other API
> > > > > v4: - rename to make it obvious that this function is PCIe specific
> > > > >     - fixes wrong assumption about what is a root bus in the presence
> > > > >       virtual buses
> > > > > ---
> > > > >  drivers/pci/search.c | 20 ++++++++++++++++++++
> > > > >  include/linux/pci.h  |  1 +
> > > > >  2 files changed, 21 insertions(+)
> > > > > 
> > > > > diff --git a/drivers/pci/search.c b/drivers/pci/search.c
> > > > > index a20ce7d5e2a7..d7c599103ae1 100644
> > > > > --- a/drivers/pci/search.c
> > > > > +++ b/drivers/pci/search.c
> > > > > @@ -384,3 +384,23 @@ int pci_dev_present(const struct pci_device_id *ids)
> > > > >  	return 0;
> > > > >  }
> > > > >  EXPORT_SYMBOL(pci_dev_present);
> > > > > +
> > > > > +/**
> > > > > + * pcie_find_root_port - Returns the root port the given device is connected to.
> > > > > + * @dev: PCI device for which the root port should be found.
> > > > > + */
> > > > > +struct pci_dev *pcie_find_root_port(struct pci_dev *dev)
> > > > > +{
> > > > > +	struct pci_bus *bus = dev->bus;
> > > > > +
> > > > > +	/* if this device is located on the root bus, it is a root port */
> > > > > +	if (pci_is_root_bus(bus))
> > > > > +		return dev;
> > > > 
> > > > It could also be a root complex endpoint or a conventional PCI
> > > > device/bridge sitting on the host bridge bus.
> > > 
> > > > > +
> > > > > +	/* walk up the PCI hierarchy to the first level below the root */
> > > > > +	while (bus->parent && bus->parent->parent)
> > > > > +		bus = bus->parent;
> > > > > +
> > > > > +	return bus->self;
> > > > > +}
> > > > > +EXPORT_SYMBOL(pcie_find_root_port);
> > > > 
> > > > IMHO, this makes too many assumptions about the topology that it's
> > > > working with for a generic interface.  Your usage may be fairly fixed,
> > > > but there are too many cases where it could return something that's not
> > > > a root port as a general interface.  Thanks,
> > > > 
> > > I'm open to suggestions on how to improve the detection. I really need
> > > something which works reliable in the majority of cases, as the Tegra
> > > quirk should not be executed on other platforms.
> > > 
> > > Do you think filtering out EP devices and conventional PCI bridges on
> > > the root bus is enough?
> > 
> > I'm actually pretty confused by the implementation of the quirk as well,
> > why do you even need this pcie_find_root_port() function?  Your fixup is
> > called for every single PCI device in the system, so why do you need to
> > go to the trouble of scanning the topology for the root port?  You'll be
> > passed the root port eventually and it will match your ID table w/o any
> > extra effort.  As coded, you're calling the set capability function
> > multiple times per root port, once for itself and once for each device
> > below it.
> > 
> > Personally, I'd probably do away with the table, declare a fixup for
> > each entry for the specific vendor/device ID, and make a simple quirk
> > callback that sets the capability bit.  Just my preference though.
> > Thanks,
> > 
> No, you missed the point of the fixup here.
> 
> We need to apply this fixup on every device in the system if the root
> port is a Tegra. So the fixup needs to get called for every device,
> filtering on a specific vendor/device ID is not possible.
> 
> But on the other hand this fixup may be compiled into a multiplatform
> kernel. If this kernel is strated on a device which isn't a Tegra (and
> so has no Tegra root port) we don't want to apply the fixup at all.

Yes, you're right, sorry for the misinterpretation.  So the quirk works
as expected, but I think at a minimum the helper function needs to be
renamed to something like pci_find_root_bus_dev() since there is no
attempt made to verify whether the returned device is actually a root
port.  If you don't support hotplug, you could also apply the quirk from
the root port down instead of searching from every device up.  Thanks,

Alex


  parent reply	other threads:[~2015-03-31 14:09 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-03-30 10:55 [PATCH v4 1/2] PCI: add helper function to find root port for device Lucas Stach
2015-03-30 10:55 ` Lucas Stach
     [not found] ` <1427712913-13678-1-git-send-email-l.stach-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>
2015-03-30 10:55   ` [PATCH v4 2/2] PCI: tegra: apply relaxed ordering fixup only on Tegra Lucas Stach
2015-03-30 10:55     ` Lucas Stach
2015-03-30 14:33   ` [PATCH v4 1/2] PCI: add helper function to find root port for device Alex Williamson
2015-03-30 14:33     ` Alex Williamson
2015-03-30 16:06     ` Lucas Stach
2015-03-30 16:52       ` Alex Williamson
2015-03-31 12:23         ` Lucas Stach
     [not found]           ` <1427804588.3370.19.camel-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>
2015-03-31 14:09             ` Alex Williamson [this message]
2015-03-31 14:09               ` Alex Williamson
     [not found]               ` <1427810993.5567.90.camel-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2015-04-08 18:13                 ` Bjorn Helgaas
2015-04-08 18:13                   ` Bjorn Helgaas

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=1427810993.5567.90.camel@redhat.com \
    --to=alex.williamson-h+wxahxf7alqt0dzr+alfa@public.gmane.org \
    --cc=bhelgaas-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org \
    --cc=gnurou-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org \
    --cc=l.stach-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org \
    --cc=linux-pci-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    --cc=linux-tegra-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    --cc=swarren-3lzwWm7+Weoh9ZMKESR00Q@public.gmane.org \
    --cc=thierry.reding-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org \
    /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.