Config fragment for Versatile Express [ was: [RFC] First pass config fragment breakout for linaro kernel]

[John Stultz]

On 03/30/2012 01:19 AM, Jon Medhurst (Tixy) wrote:
> On Thu, 2012-03-29 at 11:00 -0700, John Stultz wrote:
>> On 03/29/2012 02:22 AM, Jon Medhurst (Tixy) wrote:
>>> John, I've attached a config fragment for Versatile Express.
>> Great! I've merged that in!  There's a few warnings though:
>>
>> Value requested for CONFIG_ARCH_VEXPRESS_DT not in final .config
>> Requested value:  CONFIG_ARCH_VEXPRESS_DT=y
>> Actual value:
>>
>> Value requested for CONFIG_FB_ARMHDLCD not in final .config
>> Requested value:  CONFIG_FB_ARMHDLCD=y
>> Actual value:
>>
>> I'm guessing these are features not in the base 3.3 tree? If so you
>> might want to break those out and re-add them with those patches.
> To do that the vexpress config fragment will need to be a topic branch
> on the ARM Landing Teams git, and every topic which changes a config
> needs to be stacked on top of that. Is that what is expected?
I'm not sure I'm following you here.  I'm hoping to have the base 
configs added to the lianro-android tree, then as each topic gets 
merged, the topics which require an option, enable them in the fragments 
as well.  Then as topic branch features are merged upstream, those 
config enablement patches get merged into the base config tree.

However, if that sort of fine-grained management is too onerous, I'm ok 
with dealing with the warnings.  I realize that managing the patch 
queues can be hard enough work, so I don't mean to add more work if it 
doesn't provide much benefit.


> Currently I have two separate topics with monolithic Android and Ubuntu
> configs, so if we are moving over to config fragments I can delete
> these?
Well, you might hang on to them somewhere, just to make sure no configs 
get moved or dropped and then cause problems later on.

thanks
-john