[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAMuHMdU5L_bdWWsnbrVobdTwzJRTwz2m3UawHp-1GXqyXu=hXg@mail.gmail.com>
Date: Fri, 24 Apr 2015 09:15:00 +0200
From: Geert Uytterhoeven <geert@...ux-m68k.org>
To: Greg Kroah-Hartman <gregkh@...uxfoundation.org>
Cc: Thomas Petazzoni <thomas.petazzoni@...e-electrons.com>,
Noralf Trønnes <noralf@...nnes.org>,
driverdevel <devel@...verdev.osuosl.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v2] staging: fbtft: Disable DMA support if DMA is not available
On Thu, Apr 23, 2015 at 9:17 PM, Greg Kroah-Hartman
<gregkh@...uxfoundation.org> wrote:
> On Thu, Apr 23, 2015 at 08:47:15PM +0200, Geert Uytterhoeven wrote:
>> If NO_DMA=y:
>>
>> drivers/built-in.o: In function `fbtft_framebuffer_alloc':
>> (.text+0xb53cae): undefined reference to `dmam_alloc_coherent'
>>
>> As DMA support is already optional, make it depend on HAS_DMA.
>>
>> If !HAS_DMA, "dma" will always be false, and the compiler will optimize
>> away the call to dmam_alloc_coherent().
>
> Oh that's "sneaky" and not good, let's just make this driver be
> dependant on DMA and be done with it. I don't like to rely on the
> optimizer to get things to work properly.
Alternatively, I can stick in one more #ifdef, to no longer rely on the compiler
optimization?
AFAICS, the driver itself considers DMA optional, and will work without.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@...ux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
--
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/
Powered by blists - more mailing lists