MIME-Version: 1.0
In-Reply-To: <20121121140109.GA7549@shaftnet.org>
References: <1353422714-18327-1-git-send-email-pizza@shaftnet.org>
	<CACVXFVM=+Gus1_6U82G6_mszoRNsqb24Y+F7UPPLPBgzQasaew@mail.gmail.com>
	<20121120161011.GD18015@shaftnet.org>
	<20121120163309.GB4990@kroah.com>
	<20121120181203.GA7922@shaftnet.org>
	<20121121093528.4fe11c26@tom-ThinkPad-T410>
	<20121121140109.GA7549@shaftnet.org>
Date: Thu, 22 Nov 2012 09:45:23 +0800
Message-ID: <CACVXFVOuGQTLKSuFmTnv50-Eo0hzZSA2gh65upWu-E+439Dvsg@mail.gmail.com>
Subject: Re: [PATCH] [firmware_class] Fix compile with no builtin firmware
From: Ming Lei <tom.leiming@gmail.com>
To: Solomon Peachy <pizza@shaftnet.org>
Cc: Greg KH <gregkh@linuxfoundation.org>, linux-kernel@vger.kernel.org,
        stable@vger.kernel.org
Content-Type: text/plain; charset=ISO-8859-1
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1857
Lines: 42

On Wed, Nov 21, 2012 at 10:01 PM, Solomon Peachy <pizza@shaftnet.org> wrote:
> On Wed, Nov 21, 2012 at 09:35:28AM +0800, Ming Lei wrote:
>> Solomon, I can't duplicate the build failure with your .config on 3.7-rc5-next.
>
> Okay, so it's since been fixed.
>
>> >  * The #ifdef wraps code that pertains solely to built-in firmware, (ie
>> >    CONFIG_FIRMWARE_IN_KERNEL) and has an #else path for when it's disabled.
>> >  * There is no point in a CONFIG_FW_LOADER test inside firmware_class.c
>> >    when the file isn't even compiled unless CONFIG_FW_LOADER is defined.
>>
>> Enabling CONFIG_EXTRA_FIRMWARE still can make one firmware built in kernel
>> even though CONFIG_FIRMWARE_IN_KERNEL isn't defined, so your patch will break
>> this case.
>
> So... isn't the logical solution here to make CONFIG_EXTRA_FIRMARE
> depend on (or enable) CONFIG_FIRMWARE_IN_KERNEL?  After all, the two are
> apparently related.

No, it is not related closely, CONFIG_FIRMWARE_IN_KERNEL means
that all in-kernel-tree firmware blobs should be included in kernel binary,
but CONFIG_EXTRA_FIRMARE means that one additional firmware
image will be put into kernel binary.

>
> I can update my patch to include this, and rewrite the commit message so
> it's relevant to modern kernels, or I can just drop this and forget the
> whole affair.

Considered that there is no your problem in -linus tree or -next tree and
the current code works for long time, maybe it is better to not touch the code.
Or suggest you to study this kind of config options and firmware/Makefie first,
then figure out one proper patch.

Thanks,
-- 
Ming Lei
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/