Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754626AbbETUjr (ORCPT ); Wed, 20 May 2015 16:39:47 -0400 Received: from mail-ie0-f171.google.com ([209.85.223.171]:34759 "EHLO mail-ie0-f171.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753936AbbETUjm (ORCPT ); Wed, 20 May 2015 16:39:42 -0400 Date: Wed, 20 May 2015 15:39:36 -0500 From: Bjorn Helgaas To: "Luis R. Rodriguez" Cc: David Airlie , Tomi Valkeinen , "Michael S. Tsirkin" , Jean-Christophe Plagniol-Villard , Dave Airlie , Daniel Vetter , linux-fbdev , Andy Lutomirski , "cocci@systeme.lip6.fr" , "linux-kernel@vger.kernel.org" , "linux-pci@vger.kernel.org" , Toshi Kani , Suresh Siddha , Ingo Molnar , Thomas Gleixner , Juergen Gross , Daniel Vetter , Antonino Daplas , Dave Hansen , Arnd Bergmann , Stefan Bader , Ville =?iso-8859-1?Q?Syrj=E4l=E4?= , Mel Gorman , Vlastimil Babka , Borislav Petkov , Davidlohr Bueso , Konrad Rzeszutek Wilk , Ville =?iso-8859-1?Q?Syrj=E4l=E4?= , David Vrabel , Jan Beulich , Roger Pau =?iso-8859-1?Q?Monn=E9?= , "xen-devel@lists.xensource.com" Subject: Re: [PATCH v5 1/5] pci: add pci_iomap_wc() variants Message-ID: <20150520203936.GC32152@google.com> References: <1430415364-19679-1-git-send-email-mcgrof@do-not-panic.com> <20150519224452.GT31666@google.com> <1347189446.1486831.1432078140756.JavaMail.zimbra@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 3541 Lines: 81 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 wrote: > > > >> On Tue, May 19, 2015 at 4:02 PM, Bjorn Helgaas wrote: > >> > [-cc Venkatesh (bouncing) > >> > > >> > On Tue, May 19, 2015 at 5:46 PM, Luis R. Rodriguez > >> > wrote: > >> >> On Tue, May 19, 2015 at 3:44 PM, Bjorn Helgaas > >> >> wrote: > >> >>> Acked-by: Bjorn Helgaas > >> >> > >> >> 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@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/