From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755157AbbJ1BxH (ORCPT ); Tue, 27 Oct 2015 21:53:07 -0400 Received: from e18.ny.us.ibm.com ([129.33.205.208]:60393 "EHLO e18.ny.us.ibm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751805AbbJ1BxE (ORCPT ); Tue, 27 Oct 2015 21:53:04 -0400 X-IBM-Helo: d01dlp03.pok.ibm.com X-IBM-MailFrom: nacc@linux.vnet.ibm.com X-IBM-RcptTo: linux-kernel@vger.kernel.org;sparclinux@vger.kernel.org Date: Tue, 27 Oct 2015 18:52:55 -0700 From: Nishanth Aravamudan To: David Miller Cc: willy@linux.intel.com, keith.busch@intel.com, benh@kernel.crashing.org, paulus@samba.org, mpe@ellerman.id.au, aik@ozlabs.ru, david@gibson.dropbear.id.au, hch@infradead.org, linux-nvme@lists.infradead.org, linux-kernel@vger.kernel.org, linuxppc-dev@lists.ozlabs.org, sparclinux@vger.kernel.org Subject: Re: [PATCH 0/5 v3] Fix NVMe driver support on Power with 32-bit DMA Message-ID: <20151028015255.GG7716@linux.vnet.ibm.com> References: <20151023205420.GA10197@linux.vnet.ibm.com> <20151026.182746.1323901353520152838.davem@davemloft.net> <20151027222010.GD7716@linux.vnet.ibm.com> <20151027.175322.247163553940004154.davem@davemloft.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20151027.175322.247163553940004154.davem@davemloft.net> X-Operating-System: Linux 3.13.0-40-generic (x86_64) User-Agent: Mutt/1.5.21 (2010-09-15) X-TM-AS-MML: disable X-Content-Scanned: Fidelis XPS MAILER x-cbid: 15102801-0045-0000-0000-0000020EC5CB Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 27.10.2015 [17:53:22 -0700], David Miller wrote: > From: Nishanth Aravamudan > Date: Tue, 27 Oct 2015 15:20:10 -0700 > > > Well, looks like I should spin up a v4 anyways for the powerpc changes. > > So, to make sure I understand your point, should I make the generic > > dma_get_page_shift a compile-error kind of thing? It will only fail on > > architectures that actually build the NVME driver (as the only caller). > > But I'm not sure how exactly to achieve that, if you could give a bit > > more detail I'd appreciate it! > > Yes, I am basically suggesting to simply not provide a default at all. For my own edification -- what is the way that gets resolved? I guess I mean it seems like linux-next would cease to compile because of my new series. Would my patches just get kicked out of -next for introducing that (or even via the 0-day notifications), or should I put something into the commit message indicating it is an API introduction? Sorry for the tentativeness, I have not introduce a cross-architecture API like this before. Thanks, Nish >