Only change torch state if it really has changed from
 previous setting (removes flicker when using Torch) Also
 add a high mode (100%) as an alternative to default (79%).
 
https://github.com/kalltkaffe/galaxy-2636/commit/5199682cf751ddf2278606615387ce7b1efda56d
net:bridge patches

bridge: Have tx_bytes count headers like rx_bytes.
(backport from android-3.0
commit: 3bc18c7)
ashishsharma@google.com

bridge: Always flood broadcast packets
As is_multicast_ether_addr returns true on broadcast packets as
well, we need to explicitly exclude broadcast packets so that
they're always flooded.  This wasn't an issue before as broadcast
packets were considered to be an unregistered multicast group,
which were always flooded.  However, as we now only flood such
packets to router ports, this is no longer acceptable.
herbert@gondor.apana.org.au

bridge: send proper message_age in config BPDU
commit 0c03150 upstream.

A bridge topology with three systems:

      +------+  +------+
      | A(2) |--| B(1) |
      +------+  +------+
           \    /
          +------+
          | C(3) |
          +------+

What is supposed to happen:
 * bridge with the lowest ID is elected root (for example: B)
 * C detects that A->C is higher cost path and puts in blocking state

What happens. Bridge with lowest id (B) is elected correctly as
root and things start out fine initially. But then config BPDU
doesn't get transmitted from A -> C. Because of that
the link from A-C is transistioned to the forwarding state.

The root cause of this is that the configuration messages
is generated with bogus message age, and dropped before
sending.

In the standardmessage_age is supposed to be:
  the time since the generation of the Configuration BPDU by
  the Root that instigated the generation of this Configuration BPDU.

Reimplement this by recording the timestamp (age + jiffies) when
recording config information. The old code incorrectly used the time
elapsed on the ageing timer which was incorrect.
See also:
  https://bugzilla.vyatta.com/show_bug.cgi?id=7164
Signed-off-by: Stephen Hemminger <shemminger@vyatta.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

IGMP snooping: set mrouters_only flag for IPv4 traffic properly
Upon reception of a IGMP/IGMPv2 membership report the kernel sets the
mrouters_only flag in a skb that may be a clone of the original skb,
which
means that sometimes the bridge loses track of membership report packets
(cb
buffers are tied to a specific skb and not shared) and it ends up
forwading
join requests to the bridge interface.

This can cause unexpected membership timeouts and intermitent/permanent
loss
of connectivity as described in RFC 4541 [2.1.1. IGMP Forwarding Rules]:

    A snooping switch should forward IGMP Membership Reports only to
    those ports where multicast routers are attached.
    [...]
    Sending membership reports to other hosts can result, for IGMPv1
    and IGMPv2, in unintentionally preventing a host from joining a
    specific multicast group.

Signed-off-by: Fernando Luis Vazquez Cao <fernando@oss.ntt.co.jp>
Tested-by: Hayato Kakuta <kakuta.hayato@oss.ntt.co.jp>
Signed-off-by: David S. Miller <davem@conan.davemloft.net>
Bluetooth: bnep: Fix bad ether addresses
According to the Ethernet spec, the least significant bit of the
most significant byte identifies whether an address is multicast
or unicast. In other words, on a NIC, the 6th byte must always
be even.

Copying the address from hci0 to bnep0 was resulting in odd
6th-byte assignments, which were rejected by both the local
ethernet layer and remote hosts. So before validating the address,
make sure this particular problem doesn't exist.
luetooth: Fixed wrong L2CAP Sock timer value (2.6.36.4)
L2CAP connection timeout needs to be assigned as miliseconds
and not as jiffies.

[krc - made same change as in 57a6ed for 2.6.36 kernels)
Signed-off-by: Chen Ganir <chen.ganir@ti.com>
Signed-off-by: Gustavo F. Padovan <padovan@profusion.mobi>
tcp: Don't nuke connections for the wrong protocol
Currently, calling tcp_nuke_addr to reset IPv6 connections
resets IPv4 connections as well, because all Android
framework sockets are dual-stack (i.e., IPv6) sockets, and
we don't check the source address to see if the connection
was in fact an IPv4 connection.

Fix this by checking the source address and not resetting
the connection if it's a mapped address.

Also slightly tweak the IPv4 code path, which doesn't check
for mapped addresses either. This was not causing any
problems because tcp_is_local normally always returns true
for LOOPBACK4_IPV6 (127.0.0.6), because the loopback
interface is configured as as 127.0.0.0/8. However,
checking explicitly for LOOPBACK4_IPV6 makes the code a bit
more robust.

Bug: 5535055
Change-Id: I4d6ed3497c5b8643c864783cf681f088cf6b8d2a
Signed-off-by: Lorenzo Colitti <lorenzo@google.com>
netfilter: ipv6: fix crash caused by ipv6_find_hdr()
(backport from android-3.0
commit: 4f3824a)

When calling:
    ipv6_find_hdr(skb, &thoff, -1, NULL)
on a fragmented packet, thoff would be left with a random
value causing callers to read random memory offsets with:
    skb_header_pointer(skb, thoff, ...)

Now we force ipv6_find_hdr() to return a failure in this case.
Calling:
  ipv6_find_hdr(skb, &thoff, -1, &fragoff)
will set fragoff as expected, and not return a failure.

Change-Id: Ib474e8a4267dd2b300feca325811330329684a88
Signed-off-by: JP Abgrall <jpa@google.com>
Netfilter: enabled data limit function
Massive wireless and wifi driver merge
referenced repo: https://github.com/pershoot/galaxy-2636

1) Upgraded Broadcom wifi driver from stock bcm4330 to bcmdhd
5.90.195.35

2) net: backport wireless from moto's 2.6.39
-use https://github.com/kcrudup/Xoom-OC-CP (ics-2.6.39)
-reference mauimauer's backport against 2.6.36
 retain include/linux/netdevice.h and net/core/net-sysfs.c from his
backport
defconfig changes for upgrade of Broadcom wifi driver from stock bcm4330
to bcmdhd 5.90.195.35
ASoC: tegra: Cross check the connection state on receiving interrupt
Filter out any spurious interrupt by checking with the previous state.

Bug 865473
ALSA: hrtimer: handle delayed timer interrupts
commit b1d4f7f upstream.

If a timer interrupt was delayed too much, hrtimer_forward_now() will
forward the timer expiry more than once.  When this happens, the
additional number of elapsed ALSA timer ticks must be passed to
snd_timer_interrupt() to prevent the ALSA timer from falling behind.

This mostly fixes MIDI slowdown problems on highly-loaded systems with
badly behaved interrupt handlers.

Signed-off-by: Clemens Ladisch <clemens@ladisch.de>
Reported-and-tested-by: Arthur Marsh <arthur.marsh@internode.on.net>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
ALSA: HDA: Fix dmesg output of HDMI supported bits
commit d757534 upstream.

This typo caused the dmesg output of the supported bits of HDMI
to be cut off early.

Signed-off-by: David Henningsson <david.henningsson@canonical.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
ALSA: hda - Fix memory leaks in conexant jack arrays
commit 70f7db1 upstream.

The Conexant codec driver adds the jack arrays in init callback which
may be called also in each PM resume.  This results in the addition of
new jack element at each time.

The fix is to check whether the requested jack is already present in
the array.

Reference: Novell bug 668929
	https://bugzilla.novell.com/show_bug.cgi?id=668929

Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>