Re: [PATCH v6 1/4] pci: add pci_iomap_wc() variants
From: Luis R. Rodriguez
Date: Tue Jun 16 2015 - 15:17:11 EST
On Thu, May 28, 2015 at 5:36 PM, Luis R. Rodriguez
> On Wed, May 27, 2015 at 1:04 PM, Luis R. Rodriguez <mcgrof@xxxxxxxx> wrote:
>> On Tue, May 26, 2015 at 12:40:08PM -0500, Bjorn Helgaas wrote:
>>> On Fri, May 22, 2015 at 02:23:41AM +0200, Luis R. Rodriguez wrote:
>>> > On Thu, May 21, 2015 at 05:33:21PM -0500, Bjorn Helgaas wrote:
>>> > >
>>> > > I tentatively put this (and the rest of the series) on a pci/resource
>>> > > branch. I'm hoping you'll propose some clarification about
>>> > > EXPORT_SYMBOL_GPL().
>>> > EXPORT_SYMBOL_GPL() also serves to ensure only GPL modules can
>>> > only run that code. So for instance although we have "Dual BSD/GPL"
>>> > tags for modules pure "BSD" tags do not exist for module tags and
>>> > cannot run EXPORT_SYMBOL_GPL() code . Also there is some folks
>>> > who do believe tha at run time all kernel modules are GPL  .
>>> > And to be precise even though the FSF may claim a list of licenses
>>> > are GPL-compatible we cannot rely on this list alone for our own
>>> > goals and if folks want to use our EXPORT_SYMBOL_GPL()s they must
>>> > discuss this on lkml .
>>> By "propose some clarification," I meant that I hoped you would propose a
>>> patch to Documentation/ that would give maintainers some guidance.
>> I *really really* would hate to do so but only because you insist, I'll look
>> into this...
> OK done.
This is now on Jonathan Corbet's tree and visible on linux-next:
> Please let me know if there is anything else I can do to
Please let me know.
> Also as per review with Tomi, the framebuffer maintainer, he
> would prefer for only the required symbols to go through your tree.
> We'd then wait for the next merge window for them to perculate to
> Linus' tree and once there I'd send him a pull request for the
> framebuffer device driver changes alone. So this does mean we'll have
> no users of the symbols for a full release, but again, this is as per
> Tomi's preference. This strategy is also the preference then for the
> pci_iomap_wc() series as well. With that in mind, perhaps the lib
> patch can go in as we'd have no users but we do have a few future
> possible expected users.
I repoked Tomi about this topic with a new context provided, my
expressed hope was to just merge the fbvdev dependent changes for both
series (now both Acked by Tomi) through your tree.
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/