Tuned settings and enabled some debug, and add stuff for ics network.
Ported YAFFS2 from  3.0.8 Kernel! all files! just yaffs_vfs.c stays original.
all needed functions added.
tuned the NR and settings.
Tuned the iosched modules.
move TINY_RCU from softirq to kthread
priority boosting for TINY_PREEMPT_RCU
rcu optimize rcutiny
Ported New ZLIB code from 3.0.8 + RCU fix from privios commit.
[PATCH resend] kernel/async.c: fixing compilation warnings
January 14th, 2011 - 07:00 am ET by Viresh Kumar | Report spam
Help Create a new topic
This patch fixes following compilation warnings:
270:10: warning: .starttime.tv64. may be used uninitialized in this function
igned-off-by: Viresh Kumar <viresh.kumar@st.com>

[PATCH 1/2] Fix warning: 'calltime.tv64' may be used uninitialized in this function in init/main.c

Previous message: [thread] [date] [author]
Next message: [thread] [date] [author]
[view in full thread]
From: Kevin Winchester
Subject: [PATCH 1/2] Fix warning: 'calltime.tv64' may be used uninitialized in this function in init/main.c
Date: Wednesday, July 7, 2010 - 5:09 pm

[PATCH 2/2] Mark do_one_initcall* as __init_or_module
Using:

	gcc (GCC) 4.5.0 20100610 (prerelease)

The following warning appears:

	init/main.c: In function .do_one_initcall.:
	init/main.c:730:10: warning: .calltime.tv64. may be used uninitialized in this function

This warning is actually correct, as the global initcall_debug
could arguably be changed by the initcall.

Correct this warning by extracting a new function,
do_one_initcall_debug, that performs the initcall for the debug
case.

Previous message: [thread] [date] [author]
Next message: [thread] [date] [author]
[view in full thread]
From: Kevin Winchester
Subject: [PATCH 2/2] Mark do_one_initcall* as __init_or_module
Date: Wednesday, July 7, 2010 - 5:09 pm

Andrew Morton suggested that the do_one_initcall and
do_one_initcall_debug functions can be marked __init_or_module
such that they can be discarded for the CONFIG_MODULES=N case.
PATCH] ARM: Fix warning with gcc 4.5.1 in alignment fixup

With GCC 4.5.1 we get the following warning:

	  CC      arch/arm/mm/alignment.o
	arch/arm/mm/alignment.c: In function 'do_alignment':
	arch/arm/mm/alignment.c:720:21: warning: 'offset.un' may be used
	uninitialized in this function

This warning is triggered for the LDM/STM instructions which don't have
a register offset so set the offset to 0 to keep GCC happy.

Cc: George G. Davis <gdavis <at> mvista.com>
Cc: Min Zhang <mzhang <at> mvista.com>
Signed-off-by: Jamie Iles <jamie <at> jamieiles.com>
Fixed some warnings BUGS!
Reverted change for qdsp6_1550/dal.c, recording was not working..
Fixed Warning for net/netfilter/nf_conntrack_netlink.c
Need to test if any bad effect from this fix.
Ported WAKELOCK code from Kernel 3.0.8 MSM and settings tune.
Ported scripts/checkpatch.pl from Kernel 3.0.8 MSM
[bcm4329] WOW support in BCM driver

authorRahul Bansal <rbansal@nvidia.com>
 Mon, 13 Dec 2010 11:21:46 +0000 (16:21 +0530)
committerBharat Nihalani <bnihalani@nvidia.com>
 Wed, 29 Dec 2010 07:58:40 +0000 (23:58 -0800)

Making sure that Rx pkt is acknowledged and sent
to network interface by wifi driver before system
goes in suspend.

BUG ID 767438

Change-Id: Ie88176ec11aa1d2fe4253d9b0472d13a4742d300
Reviewed-on: http://git-master/r/12703
Reviewed-by: Rakesh Kumar <krakesh@nvidia.com>
Reviewed-by: Bharat Nihalani <bnihalani@nvidia.com>
Tested-by: Bharat Nihalani <bnihalani@nvidia.com>
drivers: wireless: bcmdhd: clear pending interrupts before irq release

While using inband interrupt and SDIO_ISR_THREAD defined,
wifi irq handler run in context of ksdioirqd.
While turning off wifi, bcmdhd driver releases irq in a different thread.
If there is a pending wifi interrupt(not served) it never get cleared as driver
has removed the irq handler.

Bug 857429

Change-Id: Ib9b041f49d18e973824a5a5b9ce4a6d771b231ca
Reviewed-on: http://git-master/r/60220
Reviewed-by: Varun Colbert <vcolbert@nvidia.com>
Tested-by: Varun Colbert <vcolbert@nvidia.com>
Added back the wakelocks: Allow independent debugging of wake_lock_destroy()
After wakelock port from 3.0.8
mmc: sdio: fix SDIO suspend/resume regression

commit 1c8cf9c upstream.

Fix SDIO suspend/resume regression introduced by 4c2ef25 "mmc: fix
all hangs related to mmc/sd card insert/removal during suspend/resume":

  PM: Syncing filesystems ... done.
  Freezing user space processes ... (elapsed 0.01 seconds) done.
  Freezing remaining freezable tasks ... (elapsed 0.01 seconds) done.
  Suspending console(s) (use no_console_suspend to debug)
  pm_op(): platform_pm_suspend+0x0/0x5c returns -38
  PM: Device pxa2xx-mci.0 failed to suspend: error -38
  PM: Some devices failed to suspend

4c2ef25 moved the card removal/insertion mechanism out of MMC's
suspend/resume path and into pm notifiers (mmc_pm_notify), and that
broke SDIO's expectation that mmc_suspend_host() will remove the card,
and squash the error, in case -ENOSYS is returned from the bus suspend
handler (mmc_sdio_suspend() in this case).

mmc_sdio_suspend() is using this whenever at least one of the card's SDIO
function drivers does not have suspend/resume handlers - in that case
it is agreed to force removal of the entire card.

This patch fixes this regression by trivially bringing back that part of
mmc_suspend_host(), which was removed by 4c2ef25.

Reported-and-tested-by: Sven Neumann <s.neumann@raumfeld.com>
Signed-off-by: Ohad Ben-Cohen <ohad@wizery.com>
Cc: Maxim Levitsky <maximlevitsky@gmail.com>
Acked-by: Nicolas Pitre <nico@fluxnic.net>
Signed-off-by: Chris Ball <cjb@laptop.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
drm: Prune GEM vma entries

commit 31dfbc9 upstream.

Hook the GEM vm open/close ops into the generic drm vm open/close so
that the private vma entries are created and destroy appropriately.
Fixes the leak of the drm_vma_entries during the lifetime of the filp.

Reported-by: Matt Mackall <mpm@selenic.com>
Cc: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Acked-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
De-pessimize rds_page_copy_user

commit 799c105 upstream.

Don't try to "optimize" rds_page_copy_user() by using kmap_atomic() and
the unsafe atomic user mode accessor functions.  It's actually slower
than the straightforward code on any reasonable modern CPU.

Back when the code was written (although probably not by the time it was
actually merged, though), 32-bit x86 may have been the dominant
architecture.  And there kmap_atomic() can be a lot faster than kmap()
(unless you have very good locality, in which case the virtual address
caching by kmap() can overcome all the downsides).

But these days, x86-64 may not be more populous, but it's getting there
(and if you care about performance, it's definitely already there -
you'd have upgraded your CPU's already in the last few years).  And on
x86-64, the non-kmap_atomic() version is faster, simply because the code
is simpler and doesn't have the "re-try page fault" case.

People with old hardware are not likely to care about RDS anyway, and
the optimization for the 32-bit case is simply buggy, since it doesn't
verify the user addresses properly.

Reported-by: Dan Rosenberg <drosenberg@vsecurity.com>
Acked-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>