On 17 May 2012 20:49, John Stultz john.stultz@linaro.org wrote:

Hey Andrey, Zach,    So I'm back from my vacation, and have found that the Android team has released a -compat tree for their 3.4 kernel. Basically this tree re-adds some items like earlysuspend and classic wakelocks in order to provide better compatibility with old (and by old,  I really mean current as far as we see - so ICS and earlier) Android userland.

Since we're still  shipping ICS, and have no access to whatever the Android 5.0 userland will be, it seems merging in the -compat tree would make sense.

However, I know Tixy and others have already tried to address the lack of earlysuspend in the android-3.3+ kernels, so I wanted to double check that this wouldn't cause additional pain (since those adjustments might need to be reverted).

So I just wanted to check first with folks to make sure there are no objections to merging in the -compat changes, and that the timing of merging in these changes isn't problematic (I can happily hold off till this months release is done, so we don't risk any last minute gotchas).

Yeah, lets hold off. I'll get it on the schedule for next month. Sound good everyone?

thanks -john

On 17 May 2012 22:09, Zach Pfeffer zach.pfeffer@linaro.org wrote:

On 17 May 2012 20:49, John Stultz john.stultz@linaro.org wrote:

...

Hey Andrey, Zach,    So I'm back from my vacation, and have found that the Android team has released a -compat tree for their 3.4 kernel. Basically this tree re-adds some items like earlysuspend and classic wakelocks in order to provide better compatibility with old (and by old,  I really mean current as far as we see - so ICS and earlier) Android userland.

Since we're still  shipping ICS, and have no access to whatever the Android 5.0 userland will be, it seems merging in the -compat tree would make sense.

However, I know Tixy and others have already tried to address the lack of earlysuspend in the android-3.3+ kernels, so I wanted to double check that this wouldn't cause additional pain (since those adjustments might need to be reverted).

So I just wanted to check first with folks to make sure there are no objections to merging in the -compat changes, and that the timing of merging in these changes isn't problematic (I can happily hold off till this months release is done, so we don't risk any last minute gotchas).

Yeah, lets hold off. I'll get it on the schedule for next month. Sound good everyone?

Put a meeting together next week to plan it.

...

thanks -john

-- Zach Pfeffer Android Platform Team Lead, Linaro Platform Teams Linaro.org | Open source software for ARM SoCs Follow Linaro: http://www.facebook.com/pages/Linaro http://twitter.com/#%21/linaroorg - http://www.linaro.org/linaro-blog

On 05/18/2012 09:54 PM, John Stultz wrote:

On 05/18/2012 06:57 AM, Zach Pfeffer wrote:

...

On 17 May 2012 22:09, Zach Pfefferzach.pfeffer@linaro.org wrote:

...

On 17 May 2012 20:49, John Stultzjohn.stultz@linaro.org wrote:

...

Hey Andrey, Zach, So I'm back from my vacation, and have found that the Android team has released a -compat tree for their 3.4 kernel. Basically this tree re-adds some items like earlysuspend and classic wakelocks in order to provide better compatibility with old (and by old, I really mean current as far as we see - so ICS and earlier) Android userland.

Since we're still shipping ICS, and have no access to whatever the Android 5.0 userland will be, it seems merging in the -compat tree would make sense.

However, I know Tixy and others have already tried to address the lack of earlysuspend in the android-3.3+ kernels, so I wanted to double check that this wouldn't cause additional pain (since those adjustments might need to be reverted).

So I just wanted to check first with folks to make sure there are no objections to merging in the -compat changes, and that the timing of merging in these changes isn't problematic (I can happily hold off till this months release is done, so we don't risk any last minute gotchas).

Yeah, lets hold off. I'll get it on the schedule for next month. Sound good everyone?

Works for me.

...

Put a meeting together next week to plan it.

I won't be there, so I'd rather do it over email. I really don't think this will be a huge impact, but really just wanted to give a general heads up and get input from Tixy on how badly it might impact his fix (or any other userland changes we made to accommodate 3.3+ kernels that I'm unaware of) and Andrey on if he had any objections.

No particular objections from my side. Whatever decision is made.

Thanks, Andrey

On 21/05/12 18:27, Somebody in the thread at some point said:

hi,

On Fri, May 18, 2012 at 6:00 AM, Andy Green <andy.green@linaro.org mailto:andy.green@linaro.org> wrote:

    So I just wanted to check first with folks to make sure there are no
    objections to merging in the -compat changes, and that the timing of
    merging in these changes isn't problematic (I can happily hold
    off till
    this months release is done, so we don't risk any last minute
    gotchas).


The only worry I can see is that now even vanilla versions of LT
kernels are basing off llct that includes Androidizaton, even
vanilla will have possibly invasive wakelock code.

It might be good to briefly audit the changes to confirm they don't
appear if CONFIG_ANDROID is off.  Google might not take much care
about that case but I think it might be important for us.

like Andy, I am a bit concerned that we merge the android stuff into the linaro-core and that we get android candies in 'vanilla' kernel. can't we (shouldn't we) have -android on top of -core and pull -android only into 'android' kernel? it's true that for most things, -android is not impacting a 'vanilla' kernel, but clearly from the outside (community *and* customers) a kernel 'tainted' with Android is not a 'vanilla' kernel anymore...

I really like the linux-core tree by the way, and the fact that we get Linaro technologies pre-integrated is helping us clearly. I think if we only add -android as a branch on top of -core, then that should be enough.

Then Andy (or other LT) would pull -core into their -vanilla, and pull -android branch into the LT androidized kernel!

Right that is how it used to be until recently. But to be fair to platform guys, recently mainline did bring a lot of Android stuff back into vanilla staging with intention to make it a permanent part of vanilla.

The problem is they were the "easy bits" of Androidization that would stay in the staging box.

The Androidization in llct and this new tranche is more invasive to the general tree. Despite I am not on John's whitelist of People Whose Opinions Matter for that subject, maybe we should take some care to either audit what we're adding to vanilla or as Nicolas is suggesting separate it out again.

-Andy

On 05/17/2012 09:00 PM, Andy Green wrote:

On 18/05/12 09:49, Somebody in the thread at some point said:

...

Hey Andrey, Zach, So I'm back from my vacation, and have found that the Android team has released a -compat tree for their 3.4 kernel. Basically this tree re-adds some items like earlysuspend and classic wakelocks in order to provide better compatibility with old (and by old, I really mean current as far as we see - so ICS and earlier) Android userland.

Since we're still shipping ICS, and have no access to whatever the Android 5.0 userland will be, it seems merging in the -compat tree would make sense.

However, I know Tixy and others have already tried to address the lack of earlysuspend in the android-3.3+ kernels, so I wanted to double check that this wouldn't cause additional pain (since those adjustments might need to be reverted).

So I just wanted to check first with folks to make sure there are no objections to merging in the -compat changes, and that the timing of merging in these changes isn't problematic (I can happily hold off till this months release is done, so we don't risk any last minute gotchas).

The only worry I can see is that now even vanilla versions of LT kernels are basing off llct that includes Androidizaton, even vanilla will have possibly invasive wakelock code.

Could you expand a bit more on your concern here? Is the the wakelock infrastructure you're concerned about, or the driver changes made by the wakelock usage? Or is it just other nebulous changes in the Android tree?

It might be good to briefly audit the changes to confirm they don't appear if CONFIG_ANDROID is off. Google might not take much care about that case but I think it might be important for us.

So while wakelocks should turn into a noop if they are disabled, there are other changes in the Android tree that aren't necessarily config switched. However, since we are trying to push these patches upstream, I think its actually good that we test these changes in non-android settings, since its the hope that they will be there eventually, if not soon.

Of course, if there are specific issues that pop up, we can either work with Google to add needed switches so the code can coexist, or rework the changes so the feature is runtime selectable.

thanks -john

On 22/05/12 01:58, Somebody in the thread at some point said:

On Mon, May 21, 2012 at 10:33:47AM -0700, John Stultz wrote:

...

...

like Andy, I am a bit concerned that we merge the android stuff into the linaro-core and that we get android candies in 'vanilla' kernel. can't we (shouldn't we) have -android on top of -core and pull -android only into 'android' kernel? it's true that for most things, -android is not impacting a 'vanilla' kernel, but clearly from the outside (community *and* customers) a kernel 'tainted' with Android is not a 'vanilla' kernel anymore...

So this re-opens the discussion we've been having since at least last Oct in moving to a consolidated kernel.

Since Android upstreaming is an very active goal of Linaro, I think there's strong technical value in putting the Android patches in along with all the other Linaro trees, as it allows us to work out any sort of incompatibilities or issues, so we can resolve them prior to being pushed upstream.

I'm quite +1 on what John is saying. There was a time when there was great uncertainty about the future of the Android patches, but since Linus' comment last year it's become dead certain that the functionality /will/ be merged upstream. We can pave the way by getting any integration issues sorted out early -- similarly to what we do for practically everything else in linux-linaro.

Hm I just said we should audit it for being dependent on CONFIG_ANDROID.

If we KNOW that deconfiguration of CONFIG_ANDROID is equivalent to not having Androidization patched in, people will stop wanting to get rid of the patches. But since Google's interest is in the case it is configured, I doubt they took care about having it disabled well.

For other configurable features in the mainline kernel, part of the deal of getting in there is that they can be turned off nicely. There's even a wholesale CONFIG_PM. But the remaining (200 or so last time I looked) Androidization patches haven't been through that kind of scrutiny by anyone. Again last time I looked they fiddled with a fair amount of kernel guts, sometimes with additional config coverage but not always.

Initially we added without discrimination that 7 year old patch that turns dmesg into junk to llct because it came in with Google's Androidization series. It suggests we're just shovelling them on without any plan at the moment.

If we're claiming we are converging these patches to upstream, "working out integration issues" then we should be auditing them for being properly dependent on CONFIG_ANDROID before adding them to the same basis used for vanilla consumers.

-Andy

On 05/21/2012 09:21 PM, Andy Green wrote:

On 22/05/12 01:58, Somebody in the thread at some point said:

...

On Mon, May 21, 2012 at 10:33:47AM -0700, John Stultz wrote:

...

...

like Andy, I am a bit concerned that we merge the android stuff into the linaro-core and that we get android candies in 'vanilla' kernel. can't we (shouldn't we) have -android on top of -core and pull -android only into 'android' kernel? it's true that for most things, -android is not impacting a 'vanilla' kernel, but clearly from the outside (community *and* customers) a kernel 'tainted' with Android is not a 'vanilla' kernel anymore...

So this re-opens the discussion we've been having since at least last Oct in moving to a consolidated kernel.

Since Android upstreaming is an very active goal of Linaro, I think there's strong technical value in putting the Android patches in along with all the other Linaro trees, as it allows us to work out any sort of incompatibilities or issues, so we can resolve them prior to being pushed upstream.

I'm quite +1 on what John is saying. There was a time when there was great uncertainty about the future of the Android patches, but since Linus' comment last year it's become dead certain that the functionality /will/ be merged upstream. We can pave the way by getting any integration issues sorted out early -- similarly to what we do for practically everything else in linux-linaro.

Hm I just said we should audit it for being dependent on CONFIG_ANDROID.

If we KNOW that deconfiguration of CONFIG_ANDROID is equivalent to not having Androidization patched in, people will stop wanting to get rid of the patches. But since Google's interest is in the case it is configured, I doubt they took care about having it disabled well.

For new or optional functionality, this is usually the case, but not for all changes. Having multiple config based code paths has additional maintainance burden, so frequently if a change really should be generic there isn't any need for a config. The simplest example of this are bug fixes, which shouldn't be configurable off :)

For other configurable features in the mainline kernel, part of the deal of getting in there is that they can be turned off nicely. There's even a wholesale CONFIG_PM. But the remaining (200 or so last time I looked) Androidization patches haven't been through that kind of scrutiny by anyone. Again last time I looked they fiddled with a fair amount of kernel guts, sometimes with additional config coverage but not always.

Initially we added without discrimination that 7 year old patch that turns dmesg into junk to llct because it came in with Google's Androidization series. It suggests we're just shovelling them on without any plan at the moment.

And I'd say in this case things worked ideally! Android tree had a very old hack that has since become obsolete. You noticed it in the tree and requested it be reverted. I've generated a patch to do so, and plan to send it to AOSP in my next submission bundle. Once the Google guys rebase, and squish the two patches down, we're down one more patch. This is exactly the type of integration work I think we benefit from.

If this were something that we went in and just configured off, its less likely anyone would notice it was unnecessary until we finished upstreaming all the larger changes we're focusing on.

Similarly, Andrey and Tushar found early cases during the first few integration attempts where parts of the Android patch set didn't align with non-Android builds. They submitted patches that have since been pushed back to AOSP.

With regard to your characterization of shovelling the patches in, its true we've traditionally taken the patch tree in its entirety, in order to produce Android builds that were fully functional. The positive news is that as items have been making it upstream, we may soon be able to reverse the model, only hand picking specific required changes from the AOSP tree. This possibility has different pros and cons, so it may not be the right approach, but its something I'll be looking at in the future.

If we're claiming we are converging these patches to upstream, "working out integration issues" then we should be auditing them for being properly dependent on CONFIG_ANDROID before adding them to the same basis used for vanilla consumers.

So I'd welcome more help in reviewing and auditing the Android patch tree with detailed care to accomplish what you're suggesting. That said, I would suggest against blindly be adding #ifdef CONFIG_ANDROID all over the code, as there are changes that shouldn't necessarily be configurable. Working these out properly will take time and care.

Again, if there is a specific concern, please let me know and I'll try to quickly address it, but I currently don't have the bandwith myself to spend auditing the entire patch set with my current priorities. If that is really unacceptable, we can have Andrey avoid merging the Android tree into the linaro-core set, and instead merge it at a later phase. But I think this would be unfortunate as we would miss out on wider testing of the changes.

thanks -john

On Wed, May 23, 2012 at 02:21:50PM +0800, Andy Green wrote:

...

...

If we KNOW that deconfiguration of CONFIG_ANDROID is equivalent to not having Androidization patched in, people will stop wanting to get rid of the patches. But since Google's interest is in the case it is configured, I doubt they took care about having it disabled well.

For new or optional functionality, this is usually the case, but not for all changes. Having multiple config based code paths has additional maintainance burden, so frequently if a change really should be generic there isn't any need for a config. The simplest example of this are bug fixes, which shouldn't be configurable off :)

For an example we had a problem yesterday with the Androidization "interactive" cpufreq governor turning up unexpectedly in an Ubuntu build and spamming block task logs. I dunno why it appeared yet, maybe it's marked up as defauly=y or some config fumble on part of guy who built the kernel.

Generally when analyzing a situation like this I think the first question is whether feature X will be merged upstream, and then the question is whether it would be protected by CONFIG_ANDROID.

How does the interactive governor fair against this criteria? Will it be accepted upstream, and if so, will it be behind CONFIG_ANDROID=y?

...

...

Initially we added without discrimination that 7 year old patch that turns dmesg into junk to llct because it came in with Google's Androidization series. It suggests we're just shovelling them on without any plan at the moment.

...

And I'd say in this case things worked ideally! Android tree had a very old hack that has since become obsolete. You noticed it in the tree and

Yeah but that's what I am saying, we shovelled the patches on with no plan about assessment or audit and just waited for trouble. It's fair enough to do that on android-specific tree because it's for benefit of Android guys. But some vanilla people don't want to participate in finding bugs from non-mainline Android code they don't care about.

Am I right in thinking the issue you're running into here is that your customer has direct expectations for the tree you're maintaining, which makes adding unexpected instability on a vanilla build very undesireable?

(If that's not the case, then generally I don't see a problem with broadening the group testing the Androidization patches to the vanilla set -- they will be beta testing, but that's one key part of open source QA.)

Personally I like the idea of the Androidization becoming part of the basis because it puts us in generally converged direction with mainline. But then we have a responsibility to make it as transparent as mainline will insist that it is if we expect members are seriously going to offer vanilla kernels on this basis.

I like it too. What could we do cheaply that will give us the transparency or policy that addresses the risk you've outlined?

On 05/23/2012 05:25 PM, Andy Green wrote:

On 24/05/12 06:42, Somebody in the thread at some point said:

...

Am I right in thinking the issue you're running into here is that your customer has direct expectations for the tree you're maintaining, which makes adding unexpected instability on a vanilla build very undesireable?

(If that's not the case, then generally I don't see a problem with broadening the group testing the Androidization patches to the vanilla set -- they will be beta testing, but that's one key part of open source QA.)

Pretty much, I think they're saying to their customers, "here's an enabled vanilla tree" and then nobody wants to see problems coming from OOT Androidization series. Since we already had "funny things" in vanilla build from the series, this isn't so paranoid to be concerned about.

I think part of the difficulty here has been the classic question of: A) Is the linaro kernel release a development snapshot of the current state of our work - allowing us to get real world testing of our not-yet-upstreamed work? B) Or is it a stable base for others to build upon?

And the answer so far has been "both!" (we're always optimistic! :) but this is a good example of a case where the integration testing of android code with mainline (which helps resolve issues before pushing upstream) is apparently considered too risky for folks wanting that stable base to build upon.

Again, I can see both sides, and what makes most sense depends on our priorities.

...

...

Personally I like the idea of the Androidization becoming part of the basis because it puts us in generally converged direction with mainline. But then we have a responsibility to make it as transparent as mainline will insist that it is if we expect members are seriously going to offer vanilla kernels on this basis.

I like it too. What could we do cheaply that will give us the transparency or policy that addresses the risk you've outlined?

Someone needs to audit the OOT Androidization stuff and confirm that for patches that go "out of their box", ie, reach out of /staging or some specific driver:

• the impact of the patch is negated if CONFIG_ANDROID or some more

specific config is disabled, or,

• remove the patch as too invasive, or,

• conclude the patch is useful and needed in vanilla case too

there's a big variety of "out of the box" patches for stuff like cache code, mmc core, network stack and so on in that series last time I looked. We should give some assurance for people using linux-linaro-core-tracking that someone at least looked at each of those cases and determined its status as above.

Again, this would be great to have. Although the calls being made here also have costs to consider: * If we remove the patch, we diverge from AOSP, which makes keeping up with Google's tree more costly. * If the patch is needed in vanilla, but might not be acceptable, considerable work might be required to get it into shape. So what do we do in the meantime?

Further, for the various bits that are not config switched, any such review would need to be done by domain experts, as much of the changes (especially with regard to arm architecture and mmc tweaks) are well beyond my/a novice's ability to audit. In some cases where I've pushed seemingly trivial fixes from the AOSP stack to lkml, Russell and others have not been able to come to consensus as to if the fix is correct or not, so this definitely isn't a trivial work.

And all of the above suggestions you've made are desired, but given time constraints we've been focusing on the more generic functionality first, and moving from there to the more specific driver and architecture changes (which is where the majority of the un-config switched changes are). Its just taking some time to get there, so I suspect pushing the linaro-android tree into a separate merge tree is likely the easiest solution at this point to address your concern (assuming the loss of integration testing is deemed as ok).

thanks -john

On 05/24/2012 11:06 PM, the mail apparently from Andy Green included:

Putting it another way if Linaro isn't going to take even a modest amount of care about the OOT Android content making problems in vanilla case, we probably aren't ready to add this lot to a vanilla basis. Irritating as that is for me as much as anyone.

Here is an audit I did myself today of OOT Android content needed to understand what we're adding to Linaro kernels for vanilla case. It's looking at the changes from POV of someone who does not want the additional Android content to build into their kernel or affect actions when deconfigured.

Things are "harmless" if they don't unconditionally change the source, the CONFIG_ they depend on is not "default y", or by looking at the code I determined that it's reasonable or even beneficial.

These are the suspicious things I found from the diff between linaro-android-3.4 (from http://git.linaro.org/gitweb?p=people/jstultz/android.git%3Ba=shortlog%3Bh=r... at HEAD 8674fd7a65aeff35c3879cf0d56e78c93ee62e2c) vs v3.4. Some are clear cut and others change code I don't really understand, but others on this list will.

1) drivers/input/evdev.c: adds wakelock code not dependent on ANDROID *** need discussion ***

2) *** BUG *** changes net/wireless/scan.c not protected by CFG80211_ALLOW_RECONNECT: IEEE80211_SCAN_RESULT_EXPIRE reduced to 3s from 15s whether configured or not

3) add net/activity_stats.c contingent on NET_ACTIVITY_STATS *** BUG *** default y

4) net/Kconfig: add ANDROID_PARANOID_NETWORK *** BUG *** default Y: needs changing

5) mm/page_alloc.c: replace constant of 1 with filescope int min_free_order_shift defaults to 1 but changeable from sysctl *** Needs comment ***

6) fs/proc.c: add support for Android-specific OOM adjust interface... ***BUG*** should be contingent on CONFIG_ANDROID or the ANDROID OOM config

7) kernel/cgroup.c: adds a "queue of wairer to do rmdir() cgroup", removes most content from free_css_set_work(), screws with much else in there, no idea if that makes cgroups better or worse, but the changes are not contingent on anything *** needs discussion ***

8) kernel/power/Kconfig: ***BUG*** HAS_WAKELOCK, WAKELOCK, USER_WAKELOCK all introduced as default y

9) kernel/printk.c: *** BUG? *** unconditionally remove CPU_DYING notification from console_cpu_notify, contaminate with printascii on DEBUG_LL (later reverted hopefully), log_buf_get_len, log_buf_clear, log_buf_copy apis added

10) kernel/sched/core.c: __might_sleep_init_called flag introduction (harmless) change __might_sleep processing *** Needs checking ***; add allow_attach cgroup api callback, if not same task actig on itself then confirm CAP_SYS_NICE, or effective uid is suid (seems good); only requeue task if any "ancestors" are the one element in queue as well as if it's just us (seems good)

11) kernel/sysctl.c: add min_order_free_shift change (pagealloc.c) interface *** Needs comment ***

12) drivers/base/power/main.c: add driver suspend / resume timeout concept, no driver may take more than 12s suspending or BUG(), not dependent on any CONFIG_ probably benficial but *** Needs discussion ***

13) drivers/char/Kconfig: Add DEVMEM *** BUG *** default y ; add DCC_TTY (harmless)

14) drivers/cpuidle/governors/menu.c: remove scaling formula "mult += 2 * get_loadavg();" *** needs discussion ***

15) drivers/mmc/card/block.c: change computation in mmc_get_devidx() *** needs discussion ***; add pr_err if r/w command fails or we abort, harmless; deferred resume implementation properly protected by config, harmless; set md->disk->flags to GENHD_FL_EXT_DEVT *** needs discussion ***

16) drivers/mmc/core/core.c: add wakelocks unconditionally *** bug ***; mmc_resume_bus() introduction; extend wakelock flag, other unconditonal changes *** needs discussion ***

17) drivers/mmc/core/host.c: add wakelocks unconditionally *** bug ***; adds pm_notifier if not flagged MMC_PM_IGNORE_PM_NOTIFY *** needs discussion ***

18) drivers/power/power_supply_core.c: change power_supply_changed() processing, add wakelocks unconditionally *** needs discussion ***

19) arch/arm/boot/compressed/head.S: wrap older chip IDs from colliding with v7 *** needs discussion ***

20) arch/arm/include/asm/hardware/coresight.h: various lowlevel io changes *** need discussion ***

21) arch/arm/include/asm/mach/mmc.h: extra stuff for embedded_sdio_data, declares mmc_platform_data ??? *** needs discussion ***

22) arch/arm/kernel/etm.c: mass changes, no idea *** needs discussion ***

23) arch/arm/mm/cache-l2x0.c: add sets and ways count, service CONFIG_PL310_ERRATA_727915, two magic debug_writel *** needs discussion ***

24) arch/arm/mm/cache-v6.S: support CONFIG_CACHE_FLUSH_RANGE_LIMIT *** needs discussion ***

25) arch/arm/mm/mmu.c: simplify early_pte_alloc() args, add force_pages to alloc_init_pud(), more changes *** needs discussion ***

26) arch/arm/vfp/entry.S: thumb2 code added *** needs discussion ***

27) arch/arm/vfp/vfpmodule.c: add SMP code *** needs discussion ***

28) linux/amba/mmci.h: hmmm also defines stuff defined in include/asm/mach/mmc.h, *** needs discussion ***

29) linux/power_supply.h: hmmm wakelocks going in there *** needs discussion ***

Original diffstat and full notes are appended.

-Andy

Documentation/android.txt | 121 + Documentation/cgroups/cgroups.txt | 9 + Documentation/cpu-freq/governors.txt | 59 + Documentation/dma-buf-sharing.txt | 98 +- arch/arm/Kconfig | 9 + arch/arm/Kconfig.debug | 21 + arch/arm/boot/compressed/head.S | 3 + arch/arm/common/Kconfig | 50 + arch/arm/common/Makefile | 2 + arch/arm/common/fiq_debugger.c | 1322 ++++ arch/arm/common/fiq_debugger_ringbuf.h | 94 + arch/arm/common/fiq_glue.S | 111 + arch/arm/common/fiq_glue_setup.c | 100 + arch/arm/include/asm/cacheflush.h | 3 +- arch/arm/include/asm/fiq_debugger.h | 64 + arch/arm/include/asm/fiq_glue.h | 30 + arch/arm/include/asm/hardirq.h | 2 +- arch/arm/include/asm/hardware/cache-l2x0.h | 3 + arch/arm/include/asm/hardware/coresight.h | 50 +- arch/arm/include/asm/irq.h | 3 + arch/arm/include/asm/mach/mmc.h | 28 + arch/arm/include/asm/rodata.h | 32 + arch/arm/include/asm/smp.h | 2 + arch/arm/kernel/etm.c | 680 +- arch/arm/kernel/ftrace.c | 15 + arch/arm/kernel/leds.c | 26 +- arch/arm/kernel/process.c | 120 +- arch/arm/kernel/smp.c | 58 + arch/arm/kernel/traps.c | 4 +- arch/arm/mm/Makefile | 1 + arch/arm/mm/cache-l2x0.c | 68 +- arch/arm/mm/cache-v6.S | 17 + arch/arm/mm/mmu.c | 73 +- arch/arm/mm/rodata.c | 159 + arch/arm/vfp/entry.S | 3 +- arch/arm/vfp/vfpmodule.c | 8 +- arch/x86/include/asm/idle.h | 7 - arch/x86/kernel/process.c | 17 +- block/genhd.c | 17 + block/partition-generic.c | 11 + drivers/Kconfig | 2 + drivers/Makefile | 1 + drivers/base/Kconfig | 26 + drivers/base/Makefile | 3 + drivers/base/dma-buf.c | 64 +- drivers/base/power/main.c | 45 + drivers/base/sw_sync.c | 259 + drivers/base/sync.c | 830 +++ drivers/char/Kconfig | 17 + drivers/char/Makefile | 1 + drivers/char/dcc_tty.c | 326 + drivers/char/mem.c | 17 + drivers/cpufreq/Kconfig | 27 + drivers/cpufreq/Makefile | 1 + drivers/cpufreq/cpufreq_interactive.c | 1000 +++ drivers/cpufreq/cpufreq_stats.c | 25 + drivers/cpuidle/governors/menu.c | 7 +- drivers/gpu/Makefile | 2 +- drivers/gpu/ion/Kconfig | 13 + drivers/gpu/ion/Makefile | 2 + drivers/gpu/ion/ion.c | 1070 +++ drivers/gpu/ion/ion_carveout_heap.c | 162 + drivers/gpu/ion/ion_heap.c | 72 + drivers/gpu/ion/ion_priv.h | 172 + drivers/gpu/ion/ion_system_heap.c | 238 + drivers/gpu/ion/ion_system_mapper.c | 114 + drivers/gpu/ion/tegra/Makefile | 1 + drivers/gpu/ion/tegra/tegra_ion.c | 96 + drivers/hid/hid-input.c | 7 + drivers/hid/hid-magicmouse.c | 13 +- drivers/hid/hid-multitouch.c | 10 + drivers/input/Kconfig | 9 + drivers/input/Makefile | 1 + drivers/input/evdev.c | 53 + drivers/input/keyreset.c | 239 + drivers/input/misc/Kconfig | 16 + drivers/input/misc/Makefile | 2 + drivers/input/misc/gpio_axis.c | 192 + drivers/input/misc/gpio_event.c | 239 + drivers/input/misc/gpio_input.c | 376 + drivers/input/misc/gpio_matrix.c | 441 ++ drivers/input/misc/gpio_output.c | 97 + drivers/input/misc/keychord.c | 387 ++ drivers/input/touchscreen/Kconfig | 6 + drivers/input/touchscreen/Makefile | 1 + drivers/input/touchscreen/synaptics_i2c_rmi.c | 675 ++ drivers/leds/Kconfig | 6 + drivers/leds/Makefile | 1 + drivers/leds/ledtrig-sleep.c | 80 + drivers/misc/Kconfig | 20 + drivers/misc/Makefile | 3 + drivers/misc/akm8975.c | 732 ++ drivers/misc/uid_stat.c | 156 + drivers/misc/wl127x-rfkill.c | 121 + drivers/mmc/card/Kconfig | 9 + drivers/mmc/card/block.c | 33 +- drivers/mmc/core/Kconfig | 17 + drivers/mmc/core/core.c | 94 +- drivers/mmc/core/host.c | 10 +- drivers/mmc/core/sd.c | 86 +- drivers/mmc/core/sdio.c | 149 +- drivers/mmc/core/sdio_bus.c | 13 +- drivers/mmc/core/sdio_io.c | 33 + drivers/mmc/host/sdhci.c | 5 +- drivers/mtd/nand/Kconfig | 10 +- drivers/net/ppp/Kconfig | 17 + drivers/net/ppp/Makefile | 2 + drivers/net/ppp/pppolac.c | 449 ++ drivers/net/ppp/pppopns.c | 428 ++ drivers/net/tun.c | 6 + drivers/net/wireless/Kconfig | 6 + drivers/net/wireless/Makefile | 2 + drivers/net/wireless/bcmdhd/Kconfig | 47 + drivers/net/wireless/bcmdhd/Makefile | 39 + drivers/net/wireless/bcmdhd/aiutils.c | 836 +++ drivers/net/wireless/bcmdhd/bcmevent.c | 148 + drivers/net/wireless/bcmdhd/bcmsdh.c | 726 ++ drivers/net/wireless/bcmdhd/bcmsdh_linux.c | 742 ++ drivers/net/wireless/bcmdhd/bcmsdh_sdmmc.c | 1432 ++++ drivers/net/wireless/bcmdhd/bcmsdh_sdmmc_linux.c | 402 ++ drivers/net/wireless/bcmdhd/bcmutils.c | 2093 ++++++ drivers/net/wireless/bcmdhd/bcmwifi_channels.c | 936 +++ drivers/net/wireless/bcmdhd/bcmwifi_channels.h | 345 + drivers/net/wireless/bcmdhd/bcmwifi_rates.h | 306 + drivers/net/wireless/bcmdhd/dhd.h | 789 +++ drivers/net/wireless/bcmdhd/dhd_bta.c | 338 + drivers/net/wireless/bcmdhd/dhd_bta.h | 39 + drivers/net/wireless/bcmdhd/dhd_bus.h | 109 + drivers/net/wireless/bcmdhd/dhd_cdc.c | 2838 ++++++++ drivers/net/wireless/bcmdhd/dhd_cfg80211.c | 673 ++ drivers/net/wireless/bcmdhd/dhd_cfg80211.h | 44 + drivers/net/wireless/bcmdhd/dhd_common.c | 2337 +++++++ drivers/net/wireless/bcmdhd/dhd_custom_gpio.c | 293 + drivers/net/wireless/bcmdhd/dhd_dbg.h | 110 + drivers/net/wireless/bcmdhd/dhd_linux.c | 5358 ++++++++++++++ drivers/net/wireless/bcmdhd/dhd_linux_sched.c | 39 + drivers/net/wireless/bcmdhd/dhd_proto.h | 109 + drivers/net/wireless/bcmdhd/dhd_sdio.c | 6962 +++++++++++++++++++ drivers/net/wireless/bcmdhd/dhd_wlfc.h | 278 + drivers/net/wireless/bcmdhd/dngl_stats.h | 43 + drivers/net/wireless/bcmdhd/dngl_wlhdr.h | 40 + drivers/net/wireless/bcmdhd/hndpmu.c | 197 + drivers/net/wireless/bcmdhd/include/Makefile | 53 + drivers/net/wireless/bcmdhd/include/aidmp.h | 375 + .../wireless/bcmdhd/include/bcm_android_types.h | 44 + drivers/net/wireless/bcmdhd/include/bcm_cfg.h | 29 + .../net/wireless/bcmdhd/include/bcm_mpool_pub.h | 361 + drivers/net/wireless/bcmdhd/include/bcmcdc.h | 126 + drivers/net/wireless/bcmdhd/include/bcmdefs.h | 239 + drivers/net/wireless/bcmdhd/include/bcmdevs.h | 487 ++ drivers/net/wireless/bcmdhd/include/bcmendian.h | 278 + drivers/net/wireless/bcmdhd/include/bcmnvram.h | 179 + drivers/net/wireless/bcmdhd/include/bcmpcispi.h | 181 + drivers/net/wireless/bcmdhd/include/bcmperf.h | 36 + drivers/net/wireless/bcmdhd/include/bcmsdbus.h | 131 + drivers/net/wireless/bcmdhd/include/bcmsdh.h | 238 + drivers/net/wireless/bcmdhd/include/bcmsdh_sdmmc.h | 123 + drivers/net/wireless/bcmdhd/include/bcmsdpcm.h | 274 + drivers/net/wireless/bcmdhd/include/bcmsdspi.h | 135 + drivers/net/wireless/bcmdhd/include/bcmsdstd.h | 248 + drivers/net/wireless/bcmdhd/include/bcmspi.h | 40 + drivers/net/wireless/bcmdhd/include/bcmspibrcm.h | 139 + drivers/net/wireless/bcmdhd/include/bcmsrom_fmt.h | 607 ++ drivers/net/wireless/bcmdhd/include/bcmsrom_tbl.h | 900 +++ drivers/net/wireless/bcmdhd/include/bcmutils.h | 775 +++ drivers/net/wireless/bcmdhd/include/dbus.h | 571 ++ drivers/net/wireless/bcmdhd/include/dhdioctl.h | 135 + drivers/net/wireless/bcmdhd/include/epivers.h | 48 + drivers/net/wireless/bcmdhd/include/hndpmu.h | 36 + .../net/wireless/bcmdhd/include/hndrte_armtrap.h | 88 + drivers/net/wireless/bcmdhd/include/hndrte_cons.h | 67 + drivers/net/wireless/bcmdhd/include/hndsoc.h | 235 + drivers/net/wireless/bcmdhd/include/linux_osl.h | 422 ++ drivers/net/wireless/bcmdhd/include/linuxver.h | 614 ++ drivers/net/wireless/bcmdhd/include/miniopt.h | 77 + drivers/net/wireless/bcmdhd/include/msgtrace.h | 74 + drivers/net/wireless/bcmdhd/include/osl.h | 88 + .../wireless/bcmdhd/include/packed_section_end.h | 53 + .../wireless/bcmdhd/include/packed_section_start.h | 60 + drivers/net/wireless/bcmdhd/include/pcicfg.h | 90 + drivers/net/wireless/bcmdhd/include/proto/802.11.h | 2253 ++++++ .../net/wireless/bcmdhd/include/proto/802.11_bta.h | 45 + .../net/wireless/bcmdhd/include/proto/802.11e.h | 131 + drivers/net/wireless/bcmdhd/include/proto/802.1d.h | 48 + drivers/net/wireless/bcmdhd/include/proto/bcmeth.h | 82 + .../net/wireless/bcmdhd/include/proto/bcmevent.h | 329 + drivers/net/wireless/bcmdhd/include/proto/bcmip.h | 210 + .../net/wireless/bcmdhd/include/proto/bcmipv6.h | 104 + .../net/wireless/bcmdhd/include/proto/bt_amp_hci.h | 441 ++ drivers/net/wireless/bcmdhd/include/proto/eapol.h | 193 + .../net/wireless/bcmdhd/include/proto/ethernet.h | 162 + drivers/net/wireless/bcmdhd/include/proto/p2p.h | 564 ++ drivers/net/wireless/bcmdhd/include/proto/sdspi.h | 75 + drivers/net/wireless/bcmdhd/include/proto/vlan.h | 69 + drivers/net/wireless/bcmdhd/include/proto/wpa.h | 203 + drivers/net/wireless/bcmdhd/include/proto/wps.h | 379 + drivers/net/wireless/bcmdhd/include/rwl_wifi.h | 96 + drivers/net/wireless/bcmdhd/include/sbchipc.h | 2233 ++++++ drivers/net/wireless/bcmdhd/include/sbconfig.h | 275 + drivers/net/wireless/bcmdhd/include/sbhnddma.h | 370 + drivers/net/wireless/bcmdhd/include/sbpcmcia.h | 108 + drivers/net/wireless/bcmdhd/include/sbsdio.h | 187 + drivers/net/wireless/bcmdhd/include/sbsdpcmdev.h | 293 + drivers/net/wireless/bcmdhd/include/sbsocram.h | 193 + drivers/net/wireless/bcmdhd/include/sdio.h | 617 ++ drivers/net/wireless/bcmdhd/include/sdioh.h | 441 ++ drivers/net/wireless/bcmdhd/include/sdiovar.h | 58 + drivers/net/wireless/bcmdhd/include/siutils.h | 313 + drivers/net/wireless/bcmdhd/include/spid.h | 153 + drivers/net/wireless/bcmdhd/include/trxhdr.h | 53 + drivers/net/wireless/bcmdhd/include/typedefs.h | 310 + drivers/net/wireless/bcmdhd/include/usbrdl.h | 203 + .../net/wireless/bcmdhd/include/wlc_extlog_idstr.h | 117 + drivers/net/wireless/bcmdhd/include/wlfc_proto.h | 229 + drivers/net/wireless/bcmdhd/include/wlioctl.h | 5067 ++++++++++++++ drivers/net/wireless/bcmdhd/linux_osl.c | 1053 +++ drivers/net/wireless/bcmdhd/sbutils.c | 1001 +++ drivers/net/wireless/bcmdhd/siutils.c | 2356 +++++++ drivers/net/wireless/bcmdhd/siutils_priv.h | 246 + drivers/net/wireless/bcmdhd/uamp_api.h | 176 + drivers/net/wireless/bcmdhd/wl_android.c | 845 +++ drivers/net/wireless/bcmdhd/wl_android.h | 57 + drivers/net/wireless/bcmdhd/wl_cfg80211.c | 7332 ++++++++++++++++++++ drivers/net/wireless/bcmdhd/wl_cfg80211.h | 658 ++ drivers/net/wireless/bcmdhd/wl_cfgp2p.c | 1967 ++++++ drivers/net/wireless/bcmdhd/wl_cfgp2p.h | 284 + drivers/net/wireless/bcmdhd/wl_dbg.h | 63 + drivers/net/wireless/bcmdhd/wl_iw.c | 3737 ++++++++++ drivers/net/wireless/bcmdhd/wl_iw.h | 161 + drivers/net/wireless/bcmdhd/wl_linux_mon.c | 422 ++ drivers/net/wireless/bcmdhd/wldev_common.c | 368 + drivers/net/wireless/bcmdhd/wldev_common.h | 110 + drivers/power/power_supply_core.c | 30 +- drivers/staging/android/Kconfig | 35 +- drivers/staging/android/Makefile | 6 +- drivers/staging/android/TODO | 10 - drivers/staging/android/alarm-dev.c | 124 +- drivers/staging/android/alarm.c | 601 -- drivers/staging/android/android_alarm.h | 59 - drivers/staging/android/ashmem.c | 20 +- drivers/staging/android/binder.c | 95 +- drivers/staging/android/binder_trace.h | 327 + drivers/staging/android/logger.c | 189 +- drivers/staging/android/logger.h | 29 +- drivers/staging/android/lowmemorykiller.c | 1 - drivers/staging/android/persistent_ram.c | 40 +- drivers/staging/android/persistent_ram.h | 78 - drivers/staging/android/ram_console.c | 7 +- drivers/staging/android/trace_persistent.c | 242 + drivers/switch/Kconfig | 15 + drivers/switch/Makefile | 4 + drivers/switch/switch_class.c | 174 + drivers/switch/switch_gpio.c | 172 + drivers/tty/serial/serial_core.c | 3 + drivers/usb/gadget/Kconfig | 9 + drivers/usb/gadget/Makefile | 2 + drivers/usb/gadget/android.c | 1314 ++++ drivers/usb/gadget/composite.c | 70 +- drivers/usb/gadget/f_accessory.c | 796 +++ drivers/usb/gadget/f_adb.c | 619 ++ drivers/usb/gadget/f_mtp.c | 1283 ++++ drivers/usb/gadget/f_rndis.c | 22 +- drivers/usb/gadget/u_ether.c | 22 +- drivers/usb/gadget/u_ether.h | 12 + drivers/usb/gadget/u_serial.c | 4 +- drivers/usb/otg/Kconfig | 8 + drivers/usb/otg/Makefile | 1 + drivers/usb/otg/otg-wakelock.c | 170 + drivers/video/Kconfig | 2 + fs/Kconfig | 4 + fs/Makefile | 3 + fs/fat/dir.c | 9 + fs/fat/fat.h | 1 + fs/fat/inode.c | 9 + fs/fs-writeback.c | 2 +- fs/fuse/dev.c | 6 +- fs/proc/base.c | 37 +- fs/yaffs2/Kconfig | 161 + fs/yaffs2/Makefile | 17 + fs/yaffs2/yaffs_allocator.c | 396 ++ fs/yaffs2/yaffs_allocator.h | 30 + fs/yaffs2/yaffs_attribs.c | 124 + fs/yaffs2/yaffs_attribs.h | 28 + fs/yaffs2/yaffs_bitmap.c | 98 + fs/yaffs2/yaffs_bitmap.h | 33 + fs/yaffs2/yaffs_checkptrw.c | 415 ++ fs/yaffs2/yaffs_checkptrw.h | 33 + fs/yaffs2/yaffs_ecc.c | 298 + fs/yaffs2/yaffs_ecc.h | 44 + fs/yaffs2/yaffs_getblockinfo.h | 35 + fs/yaffs2/yaffs_guts.c | 5164 ++++++++++++++ fs/yaffs2/yaffs_guts.h | 915 +++ fs/yaffs2/yaffs_linux.h | 41 + fs/yaffs2/yaffs_mtdif.c | 54 + fs/yaffs2/yaffs_mtdif.h | 23 + fs/yaffs2/yaffs_mtdif1.c | 330 + fs/yaffs2/yaffs_mtdif1.h | 29 + fs/yaffs2/yaffs_mtdif2.c | 225 + fs/yaffs2/yaffs_mtdif2.h | 29 + fs/yaffs2/yaffs_nameval.c | 201 + fs/yaffs2/yaffs_nameval.h | 28 + fs/yaffs2/yaffs_nand.c | 127 + fs/yaffs2/yaffs_nand.h | 38 + fs/yaffs2/yaffs_packedtags1.c | 53 + fs/yaffs2/yaffs_packedtags1.h | 39 + fs/yaffs2/yaffs_packedtags2.c | 196 + fs/yaffs2/yaffs_packedtags2.h | 47 + fs/yaffs2/yaffs_tagscompat.c | 422 ++ fs/yaffs2/yaffs_tagscompat.h | 36 + fs/yaffs2/yaffs_tagsvalidity.c | 27 + fs/yaffs2/yaffs_tagsvalidity.h | 23 + fs/yaffs2/yaffs_trace.h | 57 + fs/yaffs2/yaffs_verify.c | 535 ++ fs/yaffs2/yaffs_verify.h | 43 + fs/yaffs2/yaffs_vfs.c | 2792 ++++++++ fs/yaffs2/yaffs_yaffs1.c | 433 ++ fs/yaffs2/yaffs_yaffs1.h | 22 + fs/yaffs2/yaffs_yaffs2.c | 1598 +++++ fs/yaffs2/yaffs_yaffs2.h | 39 + fs/yaffs2/yportenv.h | 70 + include/linux/Kbuild | 2 + include/linux/akm8975.h | 87 + include/linux/alarmtimer.h | 3 + include/linux/amba/mmci.h | 12 + include/linux/android_aid.h | 28 + include/linux/cgroup.h | 14 +- include/linux/cpu.h | 7 + include/linux/cpufreq.h | 3 + include/linux/dma-buf.h | 16 + include/linux/gpio_event.h | 170 + include/linux/hid.h | 4 + include/linux/if_pppolac.h | 33 + include/linux/if_pppopns.h | 32 + include/linux/if_pppox.h | 27 +- include/linux/input.h | 3 + include/linux/ion.h | 326 + include/linux/kernel.h | 3 + include/linux/keychord.h | 52 + include/linux/keyreset.h | 28 + include/linux/mm.h | 1 + include/linux/mmc/host.h | 35 + include/linux/mmc/pm.h | 1 + include/linux/mmc/sdio_func.h | 10 + include/linux/msdos_fs.h | 12 + include/linux/netfilter/xt_IDLETIMER.h | 8 + include/linux/netfilter/xt_qtaguid.h | 13 + include/linux/netfilter/xt_quota2.h | 25 + include/linux/netfilter/xt_socket.h | 6 + include/linux/persistent_ram.h | 83 + include/linux/power_supply.h | 4 + include/linux/sched.h | 3 + include/linux/serial_core.h | 1 + include/linux/sockios.h | 1 + include/linux/sw_sync.h | 58 + include/linux/switch.h | 53 + include/linux/synaptics_i2c_rmi.h | 55 + include/linux/sync.h | 412 ++ include/linux/uid_stat.h | 29 + include/linux/usb/composite.h | 3 + include/linux/usb/f_accessory.h | 83 + include/linux/usb/f_mtp.h | 75 + include/linux/wakelock.h | 67 + include/linux/wifi_tiwlan.h | 27 + include/linux/wl127x-rfkill.h | 35 + include/linux/wlan_plat.h | 27 + include/net/activity_stats.h | 25 + include/net/bluetooth/hci.h | 9 +- include/net/bluetooth/hci_core.h | 10 +- include/net/bluetooth/sco.h | 4 +- include/net/tcp.h | 2 + include/trace/events/cpufreq_interactive.h | 112 + include/trace/events/power.h | 19 + init/Kconfig | 6 + kernel/cgroup.c | 214 +- kernel/cpu.c | 20 + kernel/debug/debug_core.c | 12 + kernel/debug/kdb/kdb_io.c | 12 +- kernel/fork.c | 19 +- kernel/irq/pm.c | 7 +- kernel/panic.c | 13 +- kernel/power/Kconfig | 25 + kernel/power/Makefile | 2 + kernel/power/main.c | 9 + kernel/power/power.h | 11 + kernel/power/suspend.c | 15 + kernel/power/suspend_time.c | 111 + kernel/power/userwakelock.c | 219 + kernel/printk.c | 56 +- kernel/sched/core.c | 31 +- kernel/sched/rt.c | 15 +- kernel/sysctl.c | 8 + kernel/time/alarmtimer.c | 4 +- lib/Kconfig.debug | 3 +- mm/page_alloc.c | 3 +- mm/shmem.c | 15 +- net/Kconfig | 16 +- net/Makefile | 1 + net/activity_stats.c | 115 + net/bluetooth/af_bluetooth.c | 38 + net/bluetooth/hci_conn.c | 53 +- net/bluetooth/hci_event.c | 22 +- net/bluetooth/l2cap_core.c | 4 +- net/bluetooth/mgmt.c | 8 +- net/bluetooth/rfcomm/core.c | 1 - net/bluetooth/sco.c | 54 +- net/bridge/br_device.c | 11 +- net/ipv4/Makefile | 1 + net/ipv4/af_inet.c | 18 + net/ipv4/devinet.c | 8 +- net/ipv4/netfilter/Kconfig | 12 + net/ipv4/netfilter/ipt_REJECT.c | 8 + net/ipv4/sysfs_net_ipv4.c | 88 + net/ipv4/tcp.c | 121 +- net/ipv6/af_inet6.c | 34 + net/ipv6/netfilter/Kconfig | 12 + net/ipv6/netfilter/ip6_tables.c | 14 +- net/ipv6/netfilter/ip6t_REJECT.c | 9 + net/netfilter/Kconfig | 42 + net/netfilter/Makefile | 2 + net/netfilter/xt_IDLETIMER.c | 78 +- net/netfilter/xt_qtaguid.c | 2976 ++++++++ net/netfilter/xt_qtaguid_internal.h | 333 + net/netfilter/xt_qtaguid_print.c | 564 ++ net/netfilter/xt_qtaguid_print.h | 120 + net/netfilter/xt_quota2.c | 382 + net/netfilter/xt_socket.c | 70 +- net/rfkill/Kconfig | 5 + net/rfkill/core.c | 4 + net/wireless/Kconfig | 11 + net/wireless/scan.c | 2 +- net/wireless/sme.c | 6 + security/commoncap.c | 11 + 432 files changed, 116964 insertions(+), 1381 deletions(-)

...and here is the audit...

- fs/yaffs - subdir Makefile contingent on default n YAFFS_FS, stays in its box

- drivers/net/wireless/bcmdhd

- all Kconfig depends on non-default BCMDHD

- FIQ debugger - default n protected by CONFIG_FIQ_DEBUGGER

- drivers/staging/android

- verified it's all wrapped in if ANDROID in subdir Kconfig

- drivers/gpu/ion

- Protected by CONFIG_ION not on by default

- drivers/input/misc

- Adds INPUT_KEYCHORD and INPUT_GPIO, neither on by default

- drivers/input

- Adds INPUT_KEYRESET, not on by default

- evdev.c: adds wakelock code not dependent on ANDROID *** need discussion ***

- touchscreen/ adds synaptics_i2c_rmi protected by non-default CONFIG_TOUCHSCREEN_SYNAPTICS_I2C_RMI

- net/netfilter

- Changes to existing xt_IDLETIMER.c; seem to be small changes around duration management, looks harmless

- Changes to existing xt_socket.c; exporting some functions and changing retcode from bool to sock*, move a pr_debug(), looks harmless

- Add xt_qtaguid, xt_quota2, protected by CONFIG_NETFILTER_XT_MATCH_QTAGUID and CONFIG_NETFILTER_XT_MATCH_QUOTA2 which are non-default

- net/rfkill

- Add CONFIG_RFKILL_PM to wrap suspend resume callbacks... default y matches pre-patched code status ... harmless

- net/wireless

- Add CFG80211_ALLOW_RECONNECT, allows reconnect even if you are already connected, non-default

- *** BUG *** changes net/wireless/scan.c not protected by CFG80211_ALLOW_RECONNECT: IEEE80211_SCAN_RESULT_EXPIRE reduced to 3s from 15s whether configured or not

- otherwise harmless

- net/

- add activity_stats.c contingent on NET_ACTIVITY_STATS *** BUG *** default y

- Kconfig: add ANDROID_PARANOID_NETWORK *** BUG *** default Y: needs changing

- net/bluetooth

- changes af_bluetooth.c wholly contingent on CONFIG_ANDROID_PARANOID_NETWORK but this is currently default Y

- change hci_conn_add with additional parameter unconditionally, fixups in other files due to that, other changes around stats collection in hci_event.c; not contingent on anything

- other changes around hci connection attempt and timeout handling not contingent on anything

- sco_sock_connect in sco.c re-done not contingent on anything

- net/bridge

- looks like harmless / good bugfix, move stats update for bridge tx packets until after initialize tx skb and set MAC header / pull the SKB

- net/ipv4

- add sysfs_net_ipv4.c contingent on CONFIG_SYSFS (ie, not contingent on anything more specific)

- af_inet.c: add code contingent on CONFIG_ANDROID_PARANOID_NETWORK, allow additional SIOCKILLADDR ioctl unconditionally

- devinet.c: more code for SIOCKILLADDR, again not contingent on anything

- netfilter/Kconfig: add IP_NF_TARGET_REJECT_SKERR, not default

- net/ipv4/netfilter/ipt_REJECT.c: code for IP_NF_TARGET_REJECT_SKERR, correctly contingent on it

- tcp.c: unconditional code to keep better stats per-uid on copied skb; add tcp_nuke_addr() function used by ioctl SIOCKILLADDR... looks harmless

- net/ipv6

- (repeat of ipv4 changes in ipv6 context)

- bugfix to return -EINVAL from ipv6_find_header if last fragment

- mm/

- page_alloc.c: replace constant of 1 with filescope int min_free_order_shift defaults to 1 but changeable from sysctl *** Needs comment ***

- shmem.c: refactor some code out to subfunction: harmless

- block/

- genhd.c: add uevent handler giving number of partitions on the block device, harmless

- partition_generic.c: add per-partition uevent handler, gives partition index and name: harmless

- fs/

- fat/dir.c: add ioctl to get the volume id VFAT_IOCTL_GET_VOLUME_ID: harmless

- fat/inode.c: fetch volume ID from FAT32 BSX for VFAT_IOCTL_GET_VOLUME_ID: looks harmless

- fs/fs-writeback.c: only mark inode dirty if block_dump is > 1 instead of just !=0.... presumably a desirable bugfix

- fs/fuse.c: don't hold up suspend while waiting for fuse fs to "finish".... presumably a sesirable bugfix

- fs/proc.c: add support for Android-specific OOM adjust interface... ***BUG*** should be contingent on CONFIG_ANDROID or the ANDROID OOM config

- kernel/

- cgroup.c: adds a "queue of wairer to do rmdir() cgroup", removes most content from free_css_set_work(), screws with much else in there, no idea if that makes cgroups better or worse, but the changes are not contingent on anything *** needs discussion ***

- cpu.c: add some exports for idle notifier, seems harmless

- debug_core.c: addiional kdb-related cmdline options break_on_panic and break_on_exception, seems harmless

- kdb_io.c: code to handle DOS and unix crlf, seems harmless

- fork.c: add "task free notifier", additional check for caller having CAP_SYS_RESOURCE, AFAIK harmless

- pm.c: additional pr_info if wakeup irq already pending, harmless

- panic.c: add optional mach_panic_string: harmless

- kernel/power

- Kconfig: ***BUG*** HAS_WAKELOCK, WAKELOCK, USER_WAKELOCK all introduced as default y

- Makefile: harmless

- main.c: correctly wrapped USER_WAKELOCK additional members

- power.h: correctly wrapped USER_WAKELOCK exports

- suspend.c: additional pr_info() around suspend actions, harmless

- suspend_time.c: debugfs stats around suspend / resume activity: harmless

- userwakelock.c: contingent on USER_WAKELOCK

- printk.c: *** BUG? *** unconditionally remove CPU_DYING notification from console_cpu_notify, contaminate with printascii on DEBUG_LL (later reverted hopefully), log_buf_get_len, log_buf_clear, log_buf_copy apis added

- sched/core.c: __might_sleep_init_called flag introduction (harmless) change __might_sleep processing *** Needs checking ***; add allow_attach cgroup api callback, if not same task actig on itself then confirm CAP_SYS_NICE, or effective uid is suid (seems good); only requeue task if any "ancestors" are the one element in queue as well as if it's just us (seems good)

- sysctl.c: add min_order_free_shift change (pagealloc.c) interface *** Needs comment ***

- timer/alarmtimer.c: remove static inline from alarmtimer_get_rtcdev (seems harmless)

- lib

- lib/Kconfig.debug: make CONFIG_STACKTRACE default y - seems harmless

- init

- init/Kconfig: Introduce PANIC_TIMEOUT default initially 0 (harmless)

- security/

- add small code to commoncap.c contingent on CONFIG_ANDROID_PARANOID_NETWORK but this is currently default Y

- drivers/

- Kconfig: just source drivers/switch/Kconfig as well (harmless)

- Makefile: enter drivers/switch contingent on CONFIG_SWITCH (harmless)

- base/Kconfig: SYNC, SW_SYNC, SW_SYNC_USER all default n (harmless)

- base/Makefile: harmless

- base/dma-buf.c: add mmap operation api to dma_buf_fops, dma_buf_mmap_internal *** Needs comment ***; add dma_buf_mmap() api and export (AFAIK harmless)

- base/power/main.c: add driver suspend / resume timeout concept, no driver may take more than 12s suspending or BUG(), not dependent on any CONFIG_ probably benficial but *** Needs discussion ***

- base/sw_sync.c: introduced for SW_SYNC etc harmless

- base/sync.c: introduced for SW_SYNC etc harmless

- char/Kconfig: Add DEVMEM *** BUG *** default y ; add DCC_TTY (harmless)

- char/Makefile: harmless

- char/dcc_tty.c: ARM-dpecific DCC tty interface, harmless

- char/mem.c: DEVMEM-related changes but all protected by ifdef CONFIG_DEVMEM correctly, harmless

- cpufreq/Kconfig: add CPU_FREQ_DEFAULT_GOV_INTERACTIVE, not default, harmless; add CPU_FREQ_GOV_INTERACTIVE not default, harmless

- cpufreq/Makefile: harmless

- cpufreq/cpufreq_interactive.c: harmless

- cpufreq/cpufreq_stats.c: call cpufreq_stats_create_table when CPU_DOWN_FAILED or CPU_DOWN_FAILED_FROZEN *** need discussion ***

- cpuidle/governors/menu.c: remove scaling formula "mult += 2 * get_loadavg();" *** needs discussion ***

- hid/hid-input.c: use hid driver-specific registration function, seems good

- hid/magicmouse.c: change magicmouse_setup_input() argument (probably good), add input_register api callback (probably good)

- hid/hid-multitouch.c: restrict multitouch-specific processing to touchpad or touchscreen device types (probably good)

- leds/Kconfig: add LEDS_TRIGGER_SLEEP, not default, harmless

- leds/Makefile: harmless

- leds/ledtrig-sleep: harmless

- misc/Kconfig: add SENSORS_AK8975, UID_STAT, WL127X_RFKILL, none default, harmless

- misc/Makefile: harmless

- misc/akm8975.c: harmless

- misc/uid_stat.c: harmless

- misc/wl127x-rfkill.c: harmless

- mmc/card/Kconfig: add MMC_BLOCK_DEFERRED_RESUME, default n, harmless

- mmc/card/block.c: change computation in mmc_get_devidx() *** needs discussion ***; add pr_err if r/w command fails or we abort, harmless; deferred resume implementation properly protected by config, harmless; set md->disk->flags to GENHD_FL_EXT_DEVT *** needs discussion ***

- mmc/core/Kconfig: add MMC_EMBEDDED_SDIO, MMC_PARANOID_SD_INIT, not default and dependent on EXPERIMENTAL, harmless

- mmc/core/core.c: add wakelocks unconditionally *** bug ***; mmc_resume_bus() introduction; extend wakelock flag, other unconditonal changes *** needs discussion ***

- mmc/core/host.c: add wakelocks unconditionally *** bug ***; adds pm_notifier if not flagged MMC_PM_IGNORE_PM_NOTIFY *** needs discussion ***

- mmc/core/sd.c: CONFIG_MMC_PARANOID_SD_INIT changes but properly protected with #ifdef, harmless

- mmc/core/sdio.c: CONFIG_MMC_EMBEDDED_SDIO changes again properly protected, harmless; add sdio_reset_comm(), harmless afaik

- mmc/core/sdio_bus.c: CONFIG_MMC_EMBEDDED_SDIO protected, harmless

- mmc/core/sdio_io.c: add sdio_readb_ext() api, harmless

- mmc/host/sdhci.c: remove pr_warning, harmless

- mtd/nand/Kconfig: improve definition of MTD_NAND_IDS, harmless

- net/ppp/Kconfig: add PPPOLAC PPPOPNS, not defaut, harmless

- net/ppp/Makefile: harmless

- net/ppp/pppolac.c: harmless

- net/ppp/pppopns.c: harmless

- net/tun.c: addition for CONFIG_ANDROID_PARANOID_NETWORK, propery protected, harmless

- net/wireless/Kconfig: add WIFI_CONTROL_FUNC, not default, harmless; add source of bcmdhd dir, harmless

- net/wireless/Makefile: harmless

- power/power_supply_core.c: change power_supply_changed() processing, add wakelocks unconditionally *** needs discussion ***

- switch/*: harmless

- tty/serial/serial_core.c: add port->ops_wake_peer callback at uart_start: seems harmless

- usb/gadget/Kconfig: Add USB_G_ANDROID, not default, harmless

- usb/gadget/Makefile: harmless

- usb/gadget/android.c: harmless

- usb/gadget/composite.c: memset config->interface to 0, looks good; add unbind_config() and remove_config(), use in place of existing code: looks good;

- usb/gadget/f_accessory.c: included by android.c, but that is dependent on USB_G_ANDROID: harmless

- usb/gadget/f_adb.c: included by android.c, but that is dependent on USB_G_ANDROID: harmless

- usb/gadget/f_mtp.c: included by android.c, but that is dependent on USB_G_ANDROID: harmless

- usb/gadget/f_rndis: fix broken vendor / manufacturor settings: harmless;

- usb/gadget/u_ether.c: streamline device naming: harmless

- usb/gadget/u_ether.h: export from above, harmless

- usb/gadget/u_serial.c: fix __init not needed in functions, harmless

- usb/otg/Kconfig: add USB_OTG_WAKELOCK, not default, harmless

- usb/otg/Makefile: harmless

- usb/otg/otg-wakelock.c: harmless

- video/Kconfig: add ion/ as source, harmless

- arch/x86

- include/asm/idle.h: remove exports for idle_notifier_[un]register, seems harmless AFAIK

- kernel/process.c: remove idle_notifier_[un]register, use idle_notifier_call_chain(), seems harmless AFAIK

- arch/arm

- Kconfig: Add ARM_FLUSH_CONSOLE_ON_RESTART, not default, harmless

- Kconfig.debug: DEBUG_RODATA[_TEST] not default, harmless

- boot/compressed/head.S: wrap older chip IDs from colliding with v7 *** needs discussion ***

- common/Kconfig: adds FIQ_*, all default n, harmless

- common/Makefile: harmless

- common/fiq_*.c: harmless

- include/asm/cacheflush.h: remove unused vma from flush_cache_user_range(), harmless

- include/asm/fiq_debugger.h: harmless

- include/asm/fiq_glue.h: harmless

- include/asm/hardirq.h: increase NR_IPI to 6 harmless AFAIK

- include/asm/hardware/cache-l2x0.h: define L2X0_CACHE_ID_REV_MASK and REV_PL310_R2P0, harmless

- include/asm/hardware/coresight.h: various lowlevel io changes *** need discussion ***

- include/asm/mach/mmc.h: extra stuff for embedded_sdio_data, declares mmc_platform_data ??? *** needs discussion ***

- include/asm/rodata.h: harmless

- include/asm/smp.h: add declaration for smp_send_all_cpu_backtrace(), harmless

- kernel/etm.c: mass changes, no idea *** needs discussion ***

- kernel/ftrace.c: add ftrace_arch_code_modify_prepare() and ftrace_arch_code_modify_post_process() exports for the RO kernel config, harmless

- kernel/leds.c: add leds_idle_notifier, harmless

- kernel/process.c: add support for arch_trigger_all_cpu_backtrace(), CONFIG_ARM_FLUSH_CONSOLE_ON_RESTART, properly protected, harmless; migrate leds_event out of cpu_idle() body and use notifier chain: harmless; add call to flush console at machine shutdown: harmless; add show_data() and show_extra_register_data(), harmless

- kernel/smp.c: define additional IPI type IPI_CPU_BACKTRACE, add smp_send_all_cpu_backtrace() to provoke and handle it: harmless

- kernel/traps.c: don't forget to do the up_read of the semaphore on one exit path: beneficial

- kernel/Makefile: harmless

- mm/cache-l2x0.c: add sets and ways count, service CONFIG_PL310_ERRATA_727915, two magic debug_writel *** needs discussion ***

- mm/cache-v6.S: support CONFIG_CACHE_FLUSH_RANGE_LIMIT *** needs discussion ***

- mm/mmu.c: simplify early_pte_alloc() args, add force_pages to alloc_init_pud(), more changes *** needs discussion ***

- mm/rodata.c: harmless

- vfp/entry.S: thumb2 code added *** needs discussion ***

- vfp/vfpmodule.c: add SMP code *** needs discussion ***

- include/

- linux/Kbuild: export new ppp headers to userland, harmless

- linux/amba/mmci.h: hmmm also defines stuff defined in include/asm/mach/mmc.h, *** needs discussion ***

- linux/power_supply.h: hmmm wakelocks going in there *** needs discussion ***

- rest of include/*.h: leafed through them didn't notice anything not seen before

On 06/10/2012 02:53 AM, Andy Green wrote:

On 05/24/2012 11:06 PM, the mail apparently from Andy Green included:

...

Putting it another way if Linaro isn't going to take even a modest amount of care about the OOT Android content making problems in vanilla case, we probably aren't ready to add this lot to a vanilla basis. Irritating as that is for me as much as anyone.

Here is an audit I did myself today of OOT Android content needed to understand what we're adding to Linaro kernels for vanilla case. It's looking at the changes from POV of someone who does not want the additional Android content to build into their kernel or affect actions when deconfigured.

Things are "harmless" if they don't unconditionally change the source, the CONFIG_ they depend on is not "default y", or by looking at the code I determined that it's reasonable or even beneficial.

These are the suspicious things I found from the diff between linaro-android-3.4 (from http://git.linaro.org/gitweb?p=people/jstultz/android.git%3Ba=shortlog%3Bh=r... at HEAD 8674fd7a65aeff35c3879cf0d56e78c93ee62e2c) vs v3.4. Some are clear cut and others change code I don't really understand, but others on this list will.

Interesting log, I appreciate the effort you took here. I don't really have too much to add here, but I'll comment on the few items below I have a bit of context on.

 1) drivers/input/evdev.c: adds wakelock code not dependent on 

ANDROID *** need discussion ***

I *believe* the evdev/wakelock changes has landed in modified form upstream in 3.5 as: 4d7e30d98939a0340022ccd49325a3d70f7e0238 epoll: Add a flag, EPOLLWAKEUP, to prevent suspend while epoll events are re

Although for now I'm still carrying the evdev wakelock change in my 3.5-jstultz-rebase tree (since Android userland will need to be updated to use EPOLLWAKEUP).

22) arch/arm/kernel/etm.c: mass changes, no idea *** needs 

discussion ***

I've pinged the etm driver maintainer on the status of these patches as part of this blueprint:

https://blueprints.launchpad.net/linux-linaro/+spec/android-etm-upstreaming

And as you noticed we have some fixes pending in the linaro-android-3.4 branch that I plan to send those up to AOSP when I get a chance. Feel free to send me other changes and I'll queue them as well.

thanks -john