sched: Set MC (multi-core) sched domain's busy_factor attribute to 1

busy_factor attribute of a scheduler domain causes busy CPUs (CPUs
that are not idle) to load balance less frequently in that domain,
which could impact performance by increasing scheduling latency for
tasks.

As an example, consider MC scheduler domain's attribute values of
max_interval = 4ms and busy_factor = 64. Further consider
max_load_balance_interval = 100 (HZ/10). In this case, a non-idle CPU
could put off load balance check in MC domain by 100ms. This
effectively means that a CPU running a single task in its queue could
fail to notice increased load on another CPU (that is in same MC
domain) for upto 100ms, before picking up load from the overloaded
CPU. Needless to say, this leads to increased scheduling latency for
tasks, affecting performance adversely.

By setting MC domain's busy_factor value to 1, we limit maximum
interval that busy CPU can put off load balance checks to 4ms
(effectively 10ms, given HZ value of 100).

Change-Id: Id45869d06f5556ea8eec602b65c2ffd2143fe060
Signed-off-by: Srivatsa Vaddagiri <vatsa@codeaurora.org>
Signed-off-by: Francisco Franco <franciscofranco.1990@gmail.com>
Fixed GPU locking at specific Mhz
net-fixes: flow_dissector: prevent an infinite loop (CVE-2013-4348)

Jason Wang found that a malicious packet could make skb_flow_dissect()
loop forever. We must check that IP header has a valid ihl to avoid
this loop. It involves IPIP encapsulation and ihl = 0 to trigger.

Given this bug is critical, I cooked a patch before having
a fix in upstream kernel.

Tested:

 Compiled/booted
 Ran some tests on bnx2x and explicitely disabled hardware provided rxhash
 ethtool -K eth1 rxhash off
 ethtool -K eth2 rxhash off

Google-Bug-Id: 11465355
Effort: net-fixes
Change-Id: I813e4dc48cecb05f8edfa218304e1f13fd764323
 net: wireless: bcmdhd: reduced the wakelock time of RX packet

	Reduce time : 1secs -> 500ms
	Problem : [Issue 11512235] 34% battery eaten overnight
		  [Issue 11374623] OS + Wifi used 41% of battery,
		  wlan_rx_wake
Signed-off-by: Ecco Park <eccopark@broadcom.com>
net: wireless: bcmdhd: Change DTIM skip policy in suspend

	issue : WiFi continuously disconnects
	Root cause :
	Sometimes we got link down event due to beacon
	lost when device goes to suspend.
	This problem sometimes happens in case that DTIM is 3 and beacon
	100ms because we wake up on 900ms (100ms * 3 * 3) during
	suspend.
	This value(900ms) is too big to STA for sync up with AP time.
	This causes STA out of sync for time with the AP.
	Eventually STA got lost of beacon during long time (4secs).

	Solution :
	If the total dtim skip interval (beacon_interval *
	DTIM * 3) is greater than 300ms, we will not extend DTIM to DTIM
	* 3.
	Instead of that, we will use original value (DTIM) for wake up
	in suspend.
	Bug : 1343127 WiFi continuously disconnects

Signed-off-by: Ecco Park <eccopark@broadcom.com>

Change-Id: I6d89bd1c56127befe4d9606869396ee25b7911ef
Signed-off-by: Paul Reioux <reioux@gmail.com>
net: wireless: bcmdhd: Set MAX_DTIM_ALLOWED_INTERVAL to 600

Change-Id: Ie4d9cac1e0828651a142d64762b251537431ea99
Signed-off-by: Dmitry Shmidt <dimitrysh@google.com>
 net: wireless: bcmdhd: Enable IPv6 RA filter feature

1) We will block IPv6 Router Advertisement multicast packet in suspend mode to save power on device.

Bug: 11638281
Signed-off-by: Ecco Park <eccopark@broadcom.com>
Kernel V0.6A