From: Arnd Bergmann <arnd@arndb.de>
To: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Cc: Thierry Reding <thierry.reding@gmail.com>,
Bjorn Helgaas <bhelgaas@google.com>,
Tomasz Nowicki <tn@semihalf.com>,
Liviu Dudau <liviu.dudau@arm.com>,
linux-pci@vger.kernel.org, linux-tegra@vger.kernel.org
Subject: Re: [PATCH v3 4/4] PCI: tegra: Use new pci_register_host_bridge() interface
Date: Mon, 22 Aug 2016 15:50:54 +0200 [thread overview]
Message-ID: <2181889.X0BmtRgjvi@wuerfel> (raw)
In-Reply-To: <20160819171300.GB11823@red-moon>
On Friday, August 19, 2016 6:13:00 PM CEST Lorenzo Pieralisi wrote:
> On Mon, Aug 15, 2016 at 05:36:47PM +0200, Thierry Reding wrote:
> > From: Arnd Bergmann <arnd@arndb.de>
> >
> > Tegra is one of the remaining platforms that still use the traditional
> > pci_common_init_dev() interface for probing PCI host bridges.
> >
> > This demonstrates how to convert it to the pci_register_host interface
> > I just added in a previous patch. This leads to a more linear probe
> > sequence that can handle errors better because we avoid callbacks into
> > the driver, and it makes the driver architecture independent.
> >
> > As a side note, I should mention that I noticed this driver does not
> > register any IORESOURCE_IO resource with the bus, but instead registers
> > the I/O port window as a memory resource, which is surely a bug.
>
> I do not think that's true (and these comments do not belong in
> a commit log anyway). It registers both; granted the way
> the resources are named is a bit misleading, but by looking
> at the code it seems correct to me (struct tegra_pcie.{io/pio}).
Hmm, I don't remember when or why I wrote this comment, but it seems
you are right. This was apparently fixed by 5106787a9e08 ("PCI: tegra:
Use physical range for I/O mapping"), which I reviewed and which
has been applied a long time ago, surely before I sent the first
version of this patch.
> > Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> > Signed-off-by: Thierry Reding <treding@nvidia.com>
> > ---
> > drivers/pci/host/pci-tegra.c | 99 +++++++++++++++++++++++---------------------
> > 1 file changed, 52 insertions(+), 47 deletions(-)
> >
> > diff --git a/drivers/pci/host/pci-tegra.c b/drivers/pci/host/pci-tegra.c
> > index 2d520755b1d7..6737d1be9798 100644
> > --- a/drivers/pci/host/pci-tegra.c
> > +++ b/drivers/pci/host/pci-tegra.c
> > @@ -260,6 +260,7 @@ static inline struct tegra_msi *to_tegra_msi(struct msi_controller *chip)
> > }
> >
> > struct tegra_pcie {
> > + struct pci_host_bridge *bridge;
>
> If we go for the zero length array approach we would remove this
> pointer too, since it would be superfluos, a container_of would
> just do, right ?
Regardless of whether we have a zero-length array or the current
code, we can provide a helper function that computes the pointer
to the pci_host_bridge from the tegra_pcie pointer.
Arnd
WARNING: multiple messages have this Message-ID (diff)
From: Arnd Bergmann <arnd-r2nGTMty4D4@public.gmane.org>
To: Lorenzo Pieralisi <lorenzo.pieralisi-5wv7dgnIgG8@public.gmane.org>
Cc: Thierry Reding
<thierry.reding-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>,
Bjorn Helgaas <bhelgaas-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org>,
Tomasz Nowicki <tn-nYOzD4b6Jr9Wk0Htik3J/w@public.gmane.org>,
Liviu Dudau <liviu.dudau-5wv7dgnIgG8@public.gmane.org>,
linux-pci-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-tegra-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
Subject: Re: [PATCH v3 4/4] PCI: tegra: Use new pci_register_host_bridge() interface
Date: Mon, 22 Aug 2016 15:50:54 +0200 [thread overview]
Message-ID: <2181889.X0BmtRgjvi@wuerfel> (raw)
In-Reply-To: <20160819171300.GB11823@red-moon>
On Friday, August 19, 2016 6:13:00 PM CEST Lorenzo Pieralisi wrote:
> On Mon, Aug 15, 2016 at 05:36:47PM +0200, Thierry Reding wrote:
> > From: Arnd Bergmann <arnd-r2nGTMty4D4@public.gmane.org>
> >
> > Tegra is one of the remaining platforms that still use the traditional
> > pci_common_init_dev() interface for probing PCI host bridges.
> >
> > This demonstrates how to convert it to the pci_register_host interface
> > I just added in a previous patch. This leads to a more linear probe
> > sequence that can handle errors better because we avoid callbacks into
> > the driver, and it makes the driver architecture independent.
> >
> > As a side note, I should mention that I noticed this driver does not
> > register any IORESOURCE_IO resource with the bus, but instead registers
> > the I/O port window as a memory resource, which is surely a bug.
>
> I do not think that's true (and these comments do not belong in
> a commit log anyway). It registers both; granted the way
> the resources are named is a bit misleading, but by looking
> at the code it seems correct to me (struct tegra_pcie.{io/pio}).
Hmm, I don't remember when or why I wrote this comment, but it seems
you are right. This was apparently fixed by 5106787a9e08 ("PCI: tegra:
Use physical range for I/O mapping"), which I reviewed and which
has been applied a long time ago, surely before I sent the first
version of this patch.
> > Signed-off-by: Arnd Bergmann <arnd-r2nGTMty4D4@public.gmane.org>
> > Signed-off-by: Thierry Reding <treding-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
> > ---
> > drivers/pci/host/pci-tegra.c | 99 +++++++++++++++++++++++---------------------
> > 1 file changed, 52 insertions(+), 47 deletions(-)
> >
> > diff --git a/drivers/pci/host/pci-tegra.c b/drivers/pci/host/pci-tegra.c
> > index 2d520755b1d7..6737d1be9798 100644
> > --- a/drivers/pci/host/pci-tegra.c
> > +++ b/drivers/pci/host/pci-tegra.c
> > @@ -260,6 +260,7 @@ static inline struct tegra_msi *to_tegra_msi(struct msi_controller *chip)
> > }
> >
> > struct tegra_pcie {
> > + struct pci_host_bridge *bridge;
>
> If we go for the zero length array approach we would remove this
> pointer too, since it would be superfluos, a container_of would
> just do, right ?
Regardless of whether we have a zero-length array or the current
code, we can provide a helper function that computes the pointer
to the pci_host_bridge from the tegra_pcie pointer.
Arnd
next prev parent reply other threads:[~2016-08-22 13:51 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-08-15 15:36 [PATCH v3 1/4] PCI: Add new method for registering PCI hosts Thierry Reding
2016-08-15 15:36 ` Thierry Reding
2016-08-15 15:36 ` [PATCH v3 2/4] PCI: Allow driver-specific data in host bridge Thierry Reding
2016-08-15 15:36 ` Thierry Reding
2016-08-19 16:55 ` Lorenzo Pieralisi
2016-08-19 16:55 ` Lorenzo Pieralisi
2016-08-22 14:00 ` Arnd Bergmann
2016-08-22 14:00 ` Arnd Bergmann
2016-08-23 13:59 ` Lorenzo Pieralisi
2016-08-23 13:59 ` Lorenzo Pieralisi
2016-11-25 7:26 ` Thierry Reding
2016-11-25 7:26 ` Thierry Reding
2016-11-25 9:53 ` Arnd Bergmann
2016-11-25 9:53 ` Arnd Bergmann
2016-08-15 15:36 ` [PATCH v3 3/4] PCI: Make host bridge interface publicly available Thierry Reding
2016-08-15 15:36 ` Thierry Reding
2016-08-15 15:36 ` [PATCH v3 4/4] PCI: tegra: Use new pci_register_host_bridge() interface Thierry Reding
2016-08-15 15:36 ` Thierry Reding
2016-08-19 17:13 ` Lorenzo Pieralisi
2016-08-19 17:13 ` Lorenzo Pieralisi
2016-08-22 13:50 ` Arnd Bergmann [this message]
2016-08-22 13:50 ` Arnd Bergmann
2016-08-23 14:01 ` Lorenzo Pieralisi
2016-08-23 14:01 ` Lorenzo Pieralisi
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=2181889.X0BmtRgjvi@wuerfel \
--to=arnd@arndb.de \
--cc=bhelgaas@google.com \
--cc=linux-pci@vger.kernel.org \
--cc=linux-tegra@vger.kernel.org \
--cc=liviu.dudau@arm.com \
--cc=lorenzo.pieralisi@arm.com \
--cc=thierry.reding@gmail.com \
--cc=tn@semihalf.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 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.