linux-toradex.git/include/net, branch tegra-10.9.9

tegra bluesleep: Bluetooth active power management driver

2010-09-24T03:48:14+00:00

A new driver is implemented to actively manage the bluetooth module
power. bluesleep also tries to manage the power of the transport used.

Two signals (GPIOs) are used to manage the power events.

BT_WAKE  : signal from HOST to BT chip to intimate BT chip can sleep.
HOST_WAKE: signal from BT chip to HOST to intimate HOST should wakeup/
activate the transport modules required for BT communication.

Bug 680524, 691608

(cherry picked from commit 111f4ccd3c4cfde2fa52ae4c0c56a2288c3af3a8)

Change-Id: I5edba2aa18c566f0ebfc4ecf9c54149ee3376666
Reviewed-on: http://git-master/r/6850
Reviewed-by: Udaykumar Rameshchan Raval 
Reviewed-by: Bharat Nihalani 
Reviewed-by: Anantha Idapalapati 
Tested-by: Anantha Idapalapati

Merge commit 'v2.6.32.9' into android-2.6.32

2010-03-11T00:38:33+00:00

Bluetooth: Use non-flushable pb flag by default for ACL data on capable chipsets.

2010-03-09T20:09:56+00:00

With Bluetooth 2.1 ACL packets can be flushable or non-flushable. This commit
makes ACL data packets non-flushable by default on compatible chipsets, and
adds the L2CAP_LM_FLUSHABLE socket option to explicitly request flushable ACL
data packets for a given L2CAP socket. This is useful for A2DP data which can
be safely discarded if it can not be delivered within a short time (while
other ACL data should not be discarded).

Note that making ACL data flushable has no effect unless the automatic flush
timeout for that ACL link is changed from its default of 0 (infinite).

Change-Id: Ie3d4befdeaefb8c979de7ae603ff5ec462b3483c
Signed-off-by: Nick Pelly

Revert "Bluetooth: Introduce L2CAP_LM_FLUSHABLE to allow flushing of ACL packets."

2010-03-09T20:09:45+00:00

This reverts commit d7897fd1e9fb3a5df0740dc2dc45ec94ca0965f2.

Change-Id: I3401550b6dc97b683104e9fdac30a617a2db8c8e
Signed-off-by: Nick Pelly

Bluetooth: Allow SCO/eSCO packet type selection for outgoing SCO connections.

2010-02-24T22:40:25+00:00

__u16 sco_pkt_type is introduced to struct sockaddr_sco. It allows bitwise
selection of SCO/eSCO packet types. Currently those bits are:

0x0001 HV1 may be used.
0x0002 HV2 may be used.
0x0004 HV3 may be used.
0x0008 EV3 may be used.
0x0010 EV4 may be used.
0x0020 EV5 may be used.
0x0040 2-EV3 may be used.
0x0080 3-EV3 may be used.
0x0100 2-EV5 may be used.
0x0200 3-EV5 may be used.

This is similar to the Packet Type parameter in the HCI Setup Synchronous
Connection Command, except that we are not reversing the logic on the EDR bits.
This makes the use of sco_pkt_tpye forward portable for the use case of
white-listing packet types, which we expect will be the primary use case.

If sco_pkt_type is zero, or userspace uses the old struct sockaddr_sco,
then the default behavior is to allow all packet types.

Packet type selection is just a request made to the Bluetooth chipset, and
it is up to the link manager on the chipset to negiotiate and decide on the
actual packet types used. Furthermore, when a SCO/eSCO connection is eventually
made there is no way for the host stack to determine which packet type was used
(however it is possible to get the link type of SCO or eSCO).

sco_pkt_type is ignored for incoming SCO connections. It is possible
to add this in the future as a parameter to the Accept Synchronous Connection
Command, however its a little trickier because the kernel does not
currently preserve sockaddr_sco data between userspace calls to accept().

The most common use for sco_pkt_type will be to white-list only SCO packets,
which can be done with the hci.h constant SCO_ESCO_MASK.

This patch is motivated by broken Bluetooth carkits such as the Motorolo
HF850 (it claims to support eSCO, but will actually reject eSCO connections
after 5 seconds) and the 2007/2008 Infiniti G35/37 (fails to route audio
if a 2-EV5 packet type is negiotiated). With this patch userspace can maintain
a list of compatible packet types to workaround remote devices such as these.

Based on a patch by Marcel Holtmann.

Change-Id: I304d8fda5b4145254820a3003820163bf53de5a5
Signed-off-by: Nick Pelly

netfilter: nf_conntrack: fix hash resizing with namespaces

2010-02-23T15:37:53+00:00

commit d696c7bdaa55e2208e56c6f98e6bc1599f34286d upstream.

As noticed by Jon Masters , the conntrack hash
size is global and not per namespace, but modifiable at runtime through
/sys/module/nf_conntrack/hashsize. Changing the hash size will only
resize the hash in the current namespace however, so other namespaces
will use an invalid hash size. This can cause crashes when enlarging
the hashsize, or false negative lookups when shrinking it.

Move the hash size into the per-namespace data and only use the global
hash size to initialize the per-namespace value when instanciating a
new namespace. Additionally restrict hash resizing to init_net for
now as other namespaces are not handled currently.

Signed-off-by: Patrick McHardy 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

netfilter: nf_conntrack: per netns nf_conntrack_cachep

2010-02-23T15:37:53+00:00

commit 5b3501faa8741d50617ce4191c20061c6ef36cb3 upstream.

nf_conntrack_cachep is currently shared by all netns instances, but
because of SLAB_DESTROY_BY_RCU special semantics, this is wrong.

If we use a shared slab cache, one object can instantly flight between
one hash table (netns ONE) to another one (netns TWO), and concurrent
reader (doing a lookup in netns ONE, 'finding' an object of netns TWO)
can be fooled without notice, because no RCU grace period has to be
observed between object freeing and its reuse.

We dont have this problem with UDP/TCP slab caches because TCP/UDP
hashtables are global to the machine (and each object has a pointer to
its netns).

If we use per netns conntrack hash tables, we also *must* use per netns
conntrack slab caches, to guarantee an object can not escape from one
namespace to another one.

Signed-off-by: Eric Dumazet 
[Patrick: added unique slab name allocation]
Signed-off-by: Patrick McHardy 
Signed-off-by: Greg Kroah-Hartman

Revert "Bluetooth: Fix rejected connection not disconnecting ACL link"

2010-02-18T04:46:01+00:00

This reverts commit 9e726b17422bade75fba94e625cd35fd1353e682.

Change-Id: I3bc2e4caa2a0e0c36b9c7de4a09b03276adae4e1
Signed-off-by: Nick Pelly

ax25: netrom: rose: Fix timer oopses

2010-02-09T12:50:56+00:00

[ Upstream commit d00c362f1b0ff54161e0a42b4554ac621a9ef92d ]

Wrong ax25_cb refcounting in ax25_send_frame() and by its callers can
cause timer oopses (first reported with 2.6.29.6 kernel).

Fixes: http://bugzilla.kernel.org/show_bug.cgi?id=14905

Reported-by: Bernard Pidoux 
Tested-by: Bernard Pidoux 
Signed-off-by: Jarek Poplawski 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

Bluetooth: Introduce L2CAP_LM_FLUSHABLE to allow flushing of ACL packets.

2010-02-08T23:36:00+00:00

With Bluetooth 2.1 ACL packets can be flushable or non-flushable. This changes
makes the default ACL packet non-flushable, and allows selection of flushable
packets on a per-L2CAP socket basis with L2CAP_LM_FLUSHABLE.

Note the HCI Write Automatic Flush Timeout command also needs to be issued
to set the flush timeout to non-zero.

Need to featurize this change to Bluetooth 2.1 chipsets only before pushing
upstream.

Signed-off-by: Nick Pelly