[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Tue, 05 May 2015 06:03:05 -0700
From: Bryan O'Donoghue <pure.logic@...us-software.ie>
To: Paul Bolle <pebolle@...cali.nl>
CC: tglx@...utronix.de, mingo@...hat.com, hpa@...or.com,
x86@...nel.org, dvhart@...radead.org, andy.schevchenko@...il.com,
boon.leong.ong@...el.com, linux-kernel@...r.kernel.org,
platform-driver-x86@...r.kernel.org, derek.browne@...el.com,
josef.ahmad@...el.com, erik.nyquist@...el.com
Subject: Re: [PATCH 1/2] x86/quark: Add Quark embedded SRAM support
On 05/05/15 01:44, Paul Bolle wrote:
> On Mon, 2015-05-04 at 03:17 +0100, Bryan O'Donoghue wrote:
>> --- a/arch/x86/platform/intel-quark/Makefile
>> +++ b/arch/x86/platform/intel-quark/Makefile
>
>> obj-$(CONFIG_INTEL_IMR) += imr.o
>
> (Your change to drivers/platform/x86/Kconfig now makes it possible that
> imr.o will be part of a module. More on that below.)
>
>> +obj-$(CONFIG_INTEL_ESRAM) += esram.o
>
> INTEL_ESRAM is a bool Kconfig symbol, so esram.o will never be part of a
> module, right?
Nope - this is kak that is hanging around in my git repo for no good
reason. No intention to make IMRs modules (and in fact everything would
break if they were).
Thanks - no idea how that crept in :)
> Was your intention perhaps to make this a tristate symbol?
No I think I was making esram tristate for test purposes - edited the
wrong line - and then didn't scrub it before the patchseries :(
Cheers !
--
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