[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20150520203936.GC32152@google.com>
Date: Wed, 20 May 2015 15:39:36 -0500
From: Bjorn Helgaas <bhelgaas@...gle.com>
To: "Luis R. Rodriguez" <mcgrof@...not-panic.com>
Cc: David Airlie <airlied@...hat.com>,
Tomi Valkeinen <tomi.valkeinen@...com>,
"Michael S. Tsirkin" <mst@...hat.com>,
Jean-Christophe Plagniol-Villard <plagnioj@...osoft.com>,
Dave Airlie <airlied@...ux.ie>,
Daniel Vetter <daniel.vetter@...el.com>,
linux-fbdev <linux-fbdev@...r.kernel.org>,
Andy Lutomirski <luto@...capital.net>,
"cocci@...teme.lip6.fr" <cocci@...teme.lip6.fr>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"linux-pci@...r.kernel.org" <linux-pci@...r.kernel.org>,
Toshi Kani <toshi.kani@...com>,
Suresh Siddha <sbsiddha@...il.com>,
Ingo Molnar <mingo@...e.hu>,
Thomas Gleixner <tglx@...utronix.de>,
Juergen Gross <jgross@...e.com>,
Daniel Vetter <daniel.vetter@...ll.ch>,
Antonino Daplas <adaplas@...il.com>,
Dave Hansen <dave.hansen@...ux.intel.com>,
Arnd Bergmann <arnd@...db.de>,
Stefan Bader <stefan.bader@...onical.com>,
Ville Syrjälä <syrjala@....fi>,
Mel Gorman <mgorman@...e.de>, Vlastimil Babka <vbabka@...e.cz>,
Borislav Petkov <bp@...e.de>, Davidlohr Bueso <dbueso@...e.de>,
Konrad Rzeszutek Wilk <konrad.wilk@...cle.com>,
Ville Syrjälä
<ville.syrjala@...ux.intel.com>,
David Vrabel <david.vrabel@...rix.com>,
Jan Beulich <jbeulich@...e.com>,
Roger Pau Monné <roger.pau@...rix.com>,
"xen-devel@...ts.xensource.com" <xen-devel@...ts.xensource.com>
Subject: Re: [PATCH v5 1/5] pci: add pci_iomap_wc() variants
On Tue, May 19, 2015 at 04:45:30PM -0700, Luis R. Rodriguez wrote:
> On Tue, May 19, 2015 at 4:29 PM, David Airlie <airlied@...hat.com> wrote:
> >
> >> On Tue, May 19, 2015 at 4:02 PM, Bjorn Helgaas <bhelgaas@...gle.com> wrote:
> >> > [-cc Venkatesh (bouncing)
> >> >
> >> > On Tue, May 19, 2015 at 5:46 PM, Luis R. Rodriguez
> >> > <mcgrof@...not-panic.com> wrote:
> >> >> On Tue, May 19, 2015 at 3:44 PM, Bjorn Helgaas <bhelgaas@...gle.com>
> >> >> wrote:
> >> >>> Acked-by: Bjorn Helgaas <bhelgaas@...gle.com>
> >> >>
> >> >> Thanks! Who's tree should this go through?
> >> >
> >> > I don't know. This is the only patch that went to linux-pci, so I
> >> > haven't seen the rest.
> >>
> >> Oh I only rev'd a v5 for 1/5 as that's the only one that had feedback
> >> asking for changes.
> >>
> >> Patch v4 2/5 was for "lib: devres: add pcim_iomap_wc() variants", you
> >> had questions about EXPORT_SYMBOL_GPL() and the fact that this is not
> >> yet used. I replied. This patch can then be ignored but again, I'd
> >> hate for folks to go in and try to add a non EXPORT_SYMBOL_GPL()
> >> symbol of this.
I'm not really a fan of adding code before it's needed.
But even when we have a user and that objection is resolved, I'd
like to have a little more guidance on the difference between
EXPORT_SYMBOL() and EXPORT_SYMBOL_GPL(), e.g., a patch to clarify
what's in Documentation/DocBook/kernel-hacking.tmpl. I can't
evaluate that issue based on "current trends and reality"; I need
something a little more formal.
If we want to allow non-GPL modules and we want to give them a
consistent kernel interface, even though it might be lacking some
implementation-specific things, I can follow that guideline.
That's how I read the current kernel-hacking.tmpl text
("[EXPORT_SYMBOL_GPL()] implies that the function is considered
an internal implementation issue, and not really an interface"),
and that would lead me to suggest EXPORT_SYMBOL() in this case.
If we don't care about consistency, and EXPORT_SYMBOL_GPL()
should be used at the developer's preference, I can follow that
guideline instead, but it would be easier if it were made more
explicit.
> >> Patches v4 3-5 remain intact, I had addressed it to you, but failed to
> >> Cc linux-pci, I'll go ahead and bounce those now.
> >>
> >> Just today Dave Arlie provided a Reviewed-by to some simple
> >> framebuffer device driver changes. I wonder if these changes should go
> >> through the framebuffer tree provided you already gave the Acked-by
> >> for the PCI parts, or if the PCI parts should go in first and only
> >> later (I guess we'd have to wait) then intake the driver changes that
> >> use the symbol.
> >>
> >> What we decide should likely also apply to the series that adds
> >> pci_ioremap_wc_bar() and makes use of it on drivers.
> >>
> >> Dave, Tomi, any preference?
> >>
> >
> > Maybe send Bjorn a pull request with a tree with the pci changes, and the fb changes reviewed-by me and acked by Tomi.
> >
> > Seems like it could be the simplest path forward.
>
> Works with me, Bjorn, are you OK with that?
Can you incorporate the acks and just post a complete v6? I don't like
trying to assemble patches from different versions of a series; it's too
much administrative hassle and too easy for me to screw up.
Bjorn
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists