[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20190617174018.GA18185@lst.de>
Date: Mon, 17 Jun 2019 19:40:18 +0200
From: Christoph Hellwig <hch@....de>
To: Dan Williams <dan.j.williams@...el.com>
Cc: Christoph Hellwig <hch@....de>,
Jérôme Glisse <jglisse@...hat.com>,
Jason Gunthorpe <jgg@...lanox.com>,
Ben Skeggs <bskeggs@...hat.com>, Linux MM <linux-mm@...ck.org>,
nouveau@...ts.freedesktop.org,
Maling list - DRI developers
<dri-devel@...ts.freedesktop.org>,
linux-nvdimm <linux-nvdimm@...ts.01.org>,
linux-pci@...r.kernel.org,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
John Hubbard <jhubbard@...dia.com>
Subject: Re: [PATCH 06/25] mm: factor out a devm_request_free_mem_region
helper
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.
Powered by blists - more mailing lists