From: Thierry Reding <thierry.reding@gmail.com>
To: Arnd Bergmann <arnd@arndb.de>
Cc: Lorenzo Pieralisi <lorenzo.pieralisi@arm.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 2/4] PCI: Allow driver-specific data in host bridge
Date: Fri, 25 Nov 2016 08:26:29 +0100 [thread overview]
Message-ID: <20161125072629.GA29326@ulmo.ba.sec> (raw)
In-Reply-To: <26481704.zoJheIBO1p@wuerfel>
[-- Attachment #1: Type: text/plain, Size: 2840 bytes --]
On Mon, Aug 22, 2016 at 04:00:42PM +0200, Arnd Bergmann wrote:
> On Friday, August 19, 2016 5:55:06 PM CEST Lorenzo Pieralisi wrote:
> > >
> > > diff --git a/drivers/pci/probe.c b/drivers/pci/probe.c
> > > index 93583b389058..ecf543014da3 100644
> > > --- a/drivers/pci/probe.c
> > > +++ b/drivers/pci/probe.c
> > > @@ -521,16 +521,19 @@ static void pci_release_host_bridge_dev(struct device *dev)
> > > kfree(bridge);
> > > }
> > >
> > > -static struct pci_host_bridge *pci_alloc_host_bridge(void)
> > > +static struct pci_host_bridge *pci_alloc_host_bridge(size_t priv)
> > > {
> > > struct pci_host_bridge *bridge;
> > >
> > > - bridge = kzalloc(sizeof(*bridge), GFP_KERNEL);
> > > + bridge = kzalloc(sizeof(*bridge) + priv, GFP_KERNEL);
> > > if (!bridge)
> > > return NULL;
> > >
> > > INIT_LIST_HEAD(&bridge->windows);
> > >
> > > + if (priv)
> > > + bridge->private = &bridge[1];
> >
> > How about making private a zero length array ?
>
> Right, the member can actually be removed here if we want to, this
> was just meant as a shorthand so we can avoid the cast or function
> call in device drivers. I think either way makes sense.
>
> Also, someone commented on a related issue in the previous version, and I
> recommended to align it to ARCH_SLAB_MINALIGN. This might be done more
> easily with the zero-length array using
>
> struct pci_host_bridge {
> ...
>
> unsigned long private[0] __attribute__((aligned(ARCH_SLAB_MINALIGN)));
> };
>
> Without this, we need a bit more computation, like
>
> bridge = kzalloc(ALIGN(sizeof(*bridge), ARCH_SLAB_MINALIGN) + priv, GFP_KERNEL);
> bridge->private = (void *)bridge + ALIGN(sizeof(*bridge);
>
> or
>
> static inline void *pci_bridge_private(struct pci_host_bridge *bridge)
> {
> return (void *)bridge + ALIGN(sizeof(*bridge);
> }
> static inline struct pci_host_bridge *pci_bridge_from_private(void *priv)
> {
> return priv - ALIGN(sizeof(*bridge);
> }
>
> The alignment is needed if the private structure contains any data that
> we may want to transfer using DMA.
Looks like I never replied to this, though I seem to remember that I
did...
My question is: why would we want the private structure to be aligned?
Surely if somebody has data in the private structure that needs to be
transferred using DMA then they need to make sure that that field will
be properly aligned. Aligning the private structure itself won't ensure
that, right?
Anyway, it seems like there's very little contentious about this other
than the minor issue of how to get at the private data. I'd like to make
progress on this because we're now three generations into 64-bit with
Tegra and still missing PCI support on all of them.
Thierry
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
next prev parent reply other threads:[~2016-11-25 7:26 UTC|newest]
Thread overview: 12+ 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 ` [PATCH v3 2/4] PCI: Allow driver-specific data in host bridge Thierry Reding
2016-08-19 16:55 ` Lorenzo Pieralisi
2016-08-22 14:00 ` Arnd Bergmann
2016-08-23 13:59 ` Lorenzo Pieralisi
2016-11-25 7:26 ` Thierry Reding [this message]
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 ` [PATCH v3 4/4] PCI: tegra: Use new pci_register_host_bridge() interface Thierry Reding
2016-08-19 17:13 ` Lorenzo Pieralisi
2016-08-22 13:50 ` Arnd Bergmann
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=20161125072629.GA29326@ulmo.ba.sec \
--to=thierry.reding@gmail.com \
--cc=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=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 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).