Re: [PATCH v6 1/4] pci: add pci_iomap_wc() variants

On 29/05/15 03:36, Luis R. Rodriguez wrote:

On Wed, May 27, 2015 at 1:04 PM, Luis R. Rodriguez [off-list ref] wrote:

quoted

On Tue, May 26, 2015 at 12:40:08PM -0500, Bjorn Helgaas wrote:

quoted

On Fri, May 22, 2015 at 02:23:41AM +0200, Luis R. Rodriguez wrote:

quoted

On Thu, May 21, 2015 at 05:33:21PM -0500, Bjorn Helgaas wrote:

quoted

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 [0]. Also there is some folks
who do believe tha at run time all kernel modules are GPL [1] [2].
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 [2].

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. Please let me know if there is anything else I can do to
help. 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 don't have any issue with fbdev changes going through other trees, but
I'd rather do that only if there are good reasons to go that way.

These changes to fbdev drivers look like cleanups, so they are not
critical, right? Does delaying the fbdev changes until the dependencies
are in prevent some other development?

 Tomi