Thread (8 messages) 8 messages, 3 authors, 2012-11-22

Re: [PATCH] [firmware_class] Fix compile with no builtin firmware

From: Ming Lei <tom.leiming@gmail.com>
Date: 2012-11-22 20:07:49
Also in: lkml

On Wed, Nov 21, 2012 at 10:01 PM, Solomon Peachy [off-list ref] wrote:
On Wed, Nov 21, 2012 at 09:35:28AM +0800, Ming Lei wrote:
quoted
Solomon, I can't duplicate the build failure with your .config on 3.7-rc5-next.
Okay, so it's since been fixed.
quoted
quoted
 * 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
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help