OMAP4: hsmmc: fix race conditions in suspend/resume path

using mmc_host_enable/disable causes race conditions. By using
runtime pm framework during hsmmc suspend/resume, clock management
integrity is kept, thereby avoid race conditions

Change-Id: I34dac7d3aaacab82b82dedff610b3a5060cf72ce
Signed-off-by: Mahesh Renduchintala <mahesh@ti.com>
OMAP: mcspi: Perform NULL pointer check before accessing cd->swap_datalines

Signed-off-by: Barbaros Tokaoglu <barbarost@gmail.com>
Toro: Update USB gadget for DM feature

1. Add RNDIS+DM composite for modem logging

Change-Id: I21cd2809a9ffc48900e7fa188ff8cc471fffa301
Signed-off-by: Benoit Goby <benoit@android.com>
Signed-off-by: sujin119.kim <sujin119.kim@samsung.com>
Merge branch 'android-3.0' into android-omap-3.0
Merge branch 'android-omap-3.0' into android-omap-tuna-3.0

Conflicts:
	drivers/net/wireless/bcmdhd/wl_cfg80211.c
Merge branch 'android-3.0' into android-omap-3.0
Merge branch 'linux-omap-3.0' into android-omap-3.0
Merge branch 'android-omap-3.0' into android-omap-tuna-3.0
Revert "OMAP4: hsmmc: fix race conditions in suspend/resume path"

This reverts commit 1b8153cc8ca36697f4d1dbf36916fbe506d6cd95.

Change-Id: If8c8bf0db3d25be38ce2a4743260838d7089aceb
Signed-off-by: Todd Poynor <toddpoynor@google.com>
USB: gadget: f_audio_source: Fix use after free in audio_unbind

When USB was disconnected, we were freeing our audio_dev struct in audio_unbind
before the audio system had cleaned up, resulting in a hang in audio_pcm_close.
We now statically allocate the audio_dev struct to avoid this problem.

Change-Id: I58ad21eaa20dcf4aa74ee614ef3b6ed2c91d52a1
Signed-off-by: Mike Lockwood <lockwood@google.com>
USB: gadget: f_audio_source: Fix compilation error

Change-Id: I1b785c47bda03208d396473a9d1c94631f5624d9
Signed-off-by: Mike Lockwood <lockwood@google.com>
net: wireless: bcmdhd: Report proper mcs rate mask

Setting proper mcs rate mask allows to connect in 802.11n-only mode

Change-Id: Iffd47a60c92a74d29e42d81d79fa64463f5895c5
Signed-off-by: Dmitry Shmidt <dimitrysh@google.com>
timekeeping: fix 32-bit overflow in get_monotonic_boottime

get_monotonic_boottime adds three nanonsecond values stored
in longs, followed by an s64.  If the long values are all
close to 1e9 the first three additions can overflow and
become negative when added to the s64.  Cast the first
value to s64 so that all additions are 64 bit.

Change-Id: Ic996d8b6fbef0b72f2d027b0d8ef5259b5c1a540
Signed-off-by: Colin Cross <ccross@android.com>
net: Allow driver to limit number of GSO segments per skb

[ Upstream commit 30b678d844af3305cda5953467005cebb5d7b687 ]

A peer (or local user) may cause TCP to use a nominal MSS of as little
as 88 (actual MSS of 76 with timestamps).  Given that we have a
sufficiently prodigious local sender and the peer ACKs quickly enough,
it is nevertheless possible to grow the window for such a connection
to the point that we will try to send just under 64K at once.  This
results in a single skb that expands to 861 segments.

In some drivers with TSO support, such an skb will require hundreds of
DMA descriptors; a substantial fraction of a TX ring or even more than
a full ring.  The TX queue selected for the skb may stall and trigger
the TX watchdog repeatedly (since the problem skb will be retried
after the TX reset).  This particularly affects sfc, for which the
issue is designated as CVE-2012-3412.

Therefore:
1. Add the field net_device::gso_max_segs holding the device-specific
   limit.
2. In netif_skb_features(), if the number of segments is too high then
   mask out GSO features to force fall back to software GSO.

Signed-off-by: Ben Hutchings <bhutchings@solarflare.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
sfc: Fix maximum number of TSO segments and minimum TX queue size

[ Upstream commit 7e6d06f0de3f74ca929441add094518ae332257c ]

Currently an skb requiring TSO may not fit within a minimum-size TX
queue.  The TX queue selected for the skb may stall and trigger the TX
watchdog repeatedly (since the problem skb will be retried after the
TX reset).  This issue is designated as CVE-2012-3412.

Set the maximum number of TSO segments for our devices to 100.  This
should make no difference to behaviour unless the actual MSS is less
than about 700.  Increase the minimum TX queue size accordingly to
allow for 2 worst-case skbs, so that there will definitely be space
to add an skb after we wake a queue.

To avoid invalidating existing configurations, change
efx_ethtool_set_ringparam() to fix up values that are too small rather
than returning -EINVAL.

Signed-off-by: Ben Hutchings <bhutchings@solarflare.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
tcp: Apply device TSO segment limit earlier

[ Upstream commit 1485348d2424e1131ea42efc033cbd9366462b01 ]

Cache the device gso_max_segs in sock::sk_gso_max_segs and use it to
limit the size of TSO skbs.  This avoids the need to fall back to
software GSO for local TCP senders.

Signed-off-by: Ben Hutchings <bhutchings@solarflare.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
net_sched: gact: Fix potential panic in tcf_gact().

[ Upstream commit 696ecdc10622d86541f2e35cc16e15b6b3b1b67e ]

gact_rand array is accessed by gact->tcfg_ptype whose value
is assumed to less than MAX_RAND, but any range checks are
not performed.

So add a check in tcf_gact_init(). And in tcf_gact(), we can
reduce a branch.

Signed-off-by: Hiroaki SHIMODA <shimoda.hiroaki@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
isdnloop: fix and simplify isdnloop_init()

[ Upstream commit 77f00f6324cb97cf1df6f9c4aaeea6ada23abdb2 ]

Fix a buffer overflow bug by removing the revision and printk.

[   22.016214] isdnloop-ISDN-driver Rev 1.11.6.7
[   22.097508] isdnloop: (loop0) virtual card added
[   22.174400] Kernel panic - not syncing: stack-protector: Kernel stack is corrupted in: ffffffff83244972
[   22.174400]
[   22.436157] Pid: 1, comm: swapper Not tainted 3.5.0-bisect-00018-gfa8bbb1-dirty #129
[   22.624071] Call Trace:
[   22.720558]  [<ffffffff832448c3>] ? CallcNew+0x56/0x56
[   22.815248]  [<ffffffff8222b623>] panic+0x110/0x329
[   22.914330]  [<ffffffff83244972>] ? isdnloop_init+0xaf/0xb1
[   23.014800]  [<ffffffff832448c3>] ? CallcNew+0x56/0x56
[   23.090763]  [<ffffffff8108e24b>] __stack_chk_fail+0x2b/0x30
[   23.185748]  [<ffffffff83244972>] isdnloop_init+0xaf/0xb1

Signed-off-by: Fengguang Wu <fengguang.wu@intel.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
net/core: Fix potential memory leak in dev_set_alias()

[ Upstream commit 7364e445f62825758fa61195d237a5b8ecdd06ec ]

Do not leak memory by updating pointer with potentially NULL realloc return value.

Found by Linux Driver Verification project (linuxtesting.org).

Signed-off-by: Alexey Khoroshilov <khoroshilov@ispras.ru>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
af_packet: remove BUG statement in tpacket_destruct_skb

[ Upstream commit 7f5c3e3a80e6654cf48dfba7cf94f88c6b505467 ]

Here's a quote of the comment about the BUG macro from asm-generic/bug.h:

 Don't use BUG() or BUG_ON() unless there's really no way out; one
 example might be detecting data structure corruption in the middle
 of an operation that can't be backed out of.  If the (sub)system
 can somehow continue operating, perhaps with reduced functionality,
 it's probably not BUG-worthy.

 If you're tempted to BUG(), think again:  is completely giving up
 really the *only* solution?  There are usually better options, where
 users don't need to reboot ASAP and can mostly shut down cleanly.

In our case, the status flag of a ring buffer slot is managed from both sides,
the kernel space and the user space. This means that even though the kernel
side might work as expected, the user space screws up and changes this flag
right between the send(2) is triggered when the flag is changed to
TP_STATUS_SENDING and a given skb is destructed after some time. Then, this
will hit the BUG macro. As David suggested, the best solution is to simply
remove this statement since it cannot be used for kernel side internal
consistency checks. I've tested it and the system still behaves /stable/ in
this case, so in accordance with the above comment, we should rather remove it.

Signed-off-by: Daniel Borkmann <daniel.borkmann@tik.ee.ethz.ch>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>