linux-kernel - Re: [PATCH v5 1/5] pci: add pci_iomap

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
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/