From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Date: Mon, 17 Jun 2019 19:42:51 +0200 From: Christoph Hellwig Subject: Re: [PATCH 06/25] mm: factor out a devm_request_free_mem_region helper Message-ID: <20190617174251.GA18249@lst.de> References: <20190617122733.22432-1-hch@lst.de> <20190617122733.22432-7-hch@lst.de> <20190617174018.GA18185@lst.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20190617174018.GA18185@lst.de> Sender: owner-linux-mm@kvack.org To: Dan Williams Cc: Christoph Hellwig , =?iso-8859-1?B?Suly9G1l?= Glisse , Jason Gunthorpe , Ben Skeggs , Linux MM , nouveau@lists.freedesktop.org, Maling list - DRI developers , linux-nvdimm , linux-pci@vger.kernel.org, Linux Kernel Mailing List , John Hubbard List-ID: On Mon, Jun 17, 2019 at 07:40:18PM +0200, Christoph Hellwig wrote: > On Mon, Jun 17, 2019 at 10:37:12AM -0700, Dan Williams wrote: > > > +struct resource *devm_request_free_mem_region(struct device *dev, > > > + struct resource *base, unsigned long size); > > > > This appears to need a 'static inline' helper stub in the > > CONFIG_DEVICE_PRIVATE=n case, otherwise this compile error triggers: > > > > ld: mm/hmm.o: in function `hmm_devmem_add': > > /home/dwillia2/git/linux/mm/hmm.c:1427: undefined reference to > > `devm_request_free_mem_region' > > *sigh* - hmm_devmem_add already only works for device private memory, > so it shouldn't be built if that option is not enabled, but in the > current code it is. And a few patches later in the series we just > kill it off entirely, and the only real caller of this function > already depends on CONFIG_DEVICE_PRIVATE. So I'm tempted to just > ignore the strict bisectability requirement here instead of making > things messy by either adding the proper ifdefs in hmm.c or providing > a stub we don't really need. Actually, I could just move the patch to mark CONFIG_DEVICE_PUBLIC broken earlier, which would force hmm_devmem_add to only be built when CONFIG_DEVICE_PRIVATE ist set.