<feed xmlns='http://www.w3.org/2005/Atom'>
<title>linux-toradex.git/net/bluetooth, branch imx-android-r12</title>
<subtitle>Linux kernel for Apalis and Colibri modules</subtitle>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/'/>
<entry>
<title>Bluetooth: Add BT_POWER L2CAP socket option.</title>
<updated>2011-03-29T20:57:51+00:00</updated>
<author>
<name>Jaikumar Ganesh</name>
<email>jaikumar@google.com</email>
</author>
<published>2010-11-10T03:07:45+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=32c4262add31d7cadbfa9d5e635c93c5d22976d9'/>
<id>32c4262add31d7cadbfa9d5e635c93c5d22976d9</id>
<content type='text'>
Add BT_POWER socket option used to control the power
characteristics of the underlying ACL link. When the remote end
has put the link in sniff mode and the host stack wants to send
data we need need to explicitly exit sniff mode to work well with
certain devices (For example, A2DP on Plantronics Voyager 855).
However, this causes problems with HID devices.

Hence, moving into active mode when sending data, irrespective
of who set the sniff mode has been made as a socket option. By
default, we will move into active mode. HID devices can set the
L2CAP socket option to prevent this from happening.

Currently, this has been implemented for L2CAP sockets. This has been
tested with incoming and outgoing L2CAP sockets for HID and A2DP.

Based on discussions on linux-bluetooth and patches submitted by
Andrei Emeltchenko.

Signed-off-by: Jaikumar Ganesh &lt;jaikumar@google.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Add BT_POWER socket option used to control the power
characteristics of the underlying ACL link. When the remote end
has put the link in sniff mode and the host stack wants to send
data we need need to explicitly exit sniff mode to work well with
certain devices (For example, A2DP on Plantronics Voyager 855).
However, this causes problems with HID devices.

Hence, moving into active mode when sending data, irrespective
of who set the sniff mode has been made as a socket option. By
default, we will move into active mode. HID devices can set the
L2CAP socket option to prevent this from happening.

Currently, this has been implemented for L2CAP sockets. This has been
tested with incoming and outgoing L2CAP sockets for HID and A2DP.

Based on discussions on linux-bluetooth and patches submitted by
Andrei Emeltchenko.

Signed-off-by: Jaikumar Ganesh &lt;jaikumar@google.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>Bluetooth: Hack: Don't dereference null pointer.</title>
<updated>2011-03-29T20:57:50+00:00</updated>
<author>
<name>Nick Pelly</name>
<email>npelly@google.com</email>
</author>
<published>2010-04-08T23:23:32+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=c558cca242139968e07d91e1858df6318cab98af'/>
<id>c558cca242139968e07d91e1858df6318cab98af</id>
<content type='text'>
This avoids the S305 panic during incoming connection.

S305 sends PSM 25 L2CAP connection request before the L2CAP info response.
When we receive that info response we crash on null pointer here.

Bug: 2127637
Change-Id: Ib637516251f46fa9a9c87ac015dc2f27df5a27fd
Signed-off-by: Nick Pelly &lt;npelly@google.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
This avoids the S305 panic during incoming connection.

S305 sends PSM 25 L2CAP connection request before the L2CAP info response.
When we receive that info response we crash on null pointer here.

Bug: 2127637
Change-Id: Ib637516251f46fa9a9c87ac015dc2f27df5a27fd
Signed-off-by: Nick Pelly &lt;npelly@google.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>Bluetooth: Use non-flushable pb flag by default for ACL data on capable chipsets.</title>
<updated>2011-03-29T20:57:50+00:00</updated>
<author>
<name>Nick Pelly</name>
<email>npelly@google.com</email>
</author>
<published>2009-12-09T03:42:21+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=56f853f2f71593c7ee920ccd653c96c4070940c4'/>
<id>56f853f2f71593c7ee920ccd653c96c4070940c4</id>
<content type='text'>
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 &lt;npelly@google.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
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 &lt;npelly@google.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>Bluetooth: Allow SCO/eSCO packet type selection for outgoing SCO connections.</title>
<updated>2011-03-29T20:57:50+00:00</updated>
<author>
<name>Nick Pelly</name>
<email>npelly@google.com</email>
</author>
<published>2010-02-11T19:54:28+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=323b152a5e15b8ced28d7a5c17ec144f8d03f63b'/>
<id>323b152a5e15b8ced28d7a5c17ec144f8d03f63b</id>
<content type='text'>
__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 &lt;npelly@google.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
__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 &lt;npelly@google.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>Bluetooth: Add ACL MTU, available buffers and total buffers to hci_conn_info.</title>
<updated>2011-03-29T20:57:50+00:00</updated>
<author>
<name>Nick Pelly</name>
<email>npelly@google.com</email>
</author>
<published>2009-12-09T08:15:41+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=2633dcd89fa9442c628b188f51f0ee6a36acc33a'/>
<id>2633dcd89fa9442c628b188f51f0ee6a36acc33a</id>
<content type='text'>
This provides userspace debugging tools access to ACL flow control state.

Signed-off-by: Nick Pelly &lt;npelly@google.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
This provides userspace debugging tools access to ACL flow control state.

Signed-off-by: Nick Pelly &lt;npelly@google.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>Bluetooth: Fallback to SCO on error code 0x10 (Connection Accept Timeout).</title>
<updated>2011-03-29T20:57:50+00:00</updated>
<author>
<name>Nick Pelly</name>
<email>npelly@google.com</email>
</author>
<published>2009-09-22T22:19:46+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=2944102d710ffafe48453794bcdeceffbd6e028c'/>
<id>2944102d710ffafe48453794bcdeceffbd6e028c</id>
<content type='text'>
This is to support the Motorola HF850 carkit which reports the error code 0x10
for an eSCO attempt, even though it advertises eSCO support. Here is the
hcidump:

2009-09-22 15:40:24.492391 &lt; HCI Command: Setup Synchronous Connection
(0x01|0x0028) plen 17
    handle 1 voice setting 0x0060
2009-09-22 15:40:24.493002 &gt; HCI Event: Command Status (0x0f) plen 4
    Setup Synchronous Connection (0x01|0x0028) status 0x00 ncmd 1
2009-09-22 15:40:30.594869 &gt; HCI Event: Synchronous Connect Complete (0x2c)
plen 17
    status 0x10 handle 257 bdaddr 00:50:CD:20:C6:84 type eSCO
    Error: Connection Accept Timeout Exceeded

With this patch we will retry with a SCO connection, which succeeds.

Unfortunately the Moto HF850 also takes 5 seconds to return the error for the
eSCO attempt, so it will still take 5 seconds to fallback to SCO with this
patch.

Signed-off-by: Nick Pelly &lt;npelly@google.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
This is to support the Motorola HF850 carkit which reports the error code 0x10
for an eSCO attempt, even though it advertises eSCO support. Here is the
hcidump:

2009-09-22 15:40:24.492391 &lt; HCI Command: Setup Synchronous Connection
(0x01|0x0028) plen 17
    handle 1 voice setting 0x0060
2009-09-22 15:40:24.493002 &gt; HCI Event: Command Status (0x0f) plen 4
    Setup Synchronous Connection (0x01|0x0028) status 0x00 ncmd 1
2009-09-22 15:40:30.594869 &gt; HCI Event: Synchronous Connect Complete (0x2c)
plen 17
    status 0x10 handle 257 bdaddr 00:50:CD:20:C6:84 type eSCO
    Error: Connection Accept Timeout Exceeded

With this patch we will retry with a SCO connection, which succeeds.

Unfortunately the Moto HF850 also takes 5 seconds to return the error for the
eSCO attempt, so it will still take 5 seconds to fallback to SCO with this
patch.

Signed-off-by: Nick Pelly &lt;npelly@google.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>Bluetooth: Do not attempt to send dlci disconnect when in BT_CONFIG.</title>
<updated>2011-03-29T20:57:50+00:00</updated>
<author>
<name>Nick Pelly</name>
<email>npelly@google.com</email>
</author>
<published>2009-07-09T19:23:44+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=ea851c7aa1641dc34c5eec5a0af653e0bf29204b'/>
<id>ea851c7aa1641dc34c5eec5a0af653e0bf29204b</id>
<content type='text'>
This fixes a bug where shutdown() and close() on a rfcomm socket during ACL
connection would not cause HCI Create Connection Cancel.

Signed-off-by: Nick Pelly &lt;npelly@google.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
This fixes a bug where shutdown() and close() on a rfcomm socket during ACL
connection would not cause HCI Create Connection Cancel.

Signed-off-by: Nick Pelly &lt;npelly@google.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>Paranoid network.</title>
<updated>2011-03-29T20:57:36+00:00</updated>
<author>
<name>Robert Love</name>
<email>rlove@google.com</email>
</author>
<published>2008-10-15T19:35:44+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=6c96f9b2e5856ca420ecacc0bbca787d36d5979b'/>
<id>6c96f9b2e5856ca420ecacc0bbca787d36d5979b</id>
<content type='text'>
With CONFIG_ANDROID_PARANOID_NETWORK, require specific uids/gids to instantiate
network sockets.

Signed-off-by: Robert Love &lt;rlove@google.com&gt;

paranoid networking: Use in_egroup_p() to check group membership

The previous group_search() caused trouble for partners with module builds.
in_egroup_p() is also cleaner.

Signed-off-by: Nick Pelly &lt;npelly@google.com&gt;

Fix 2.6.29 build.

Signed-off-by: Arve Hjønnevåg &lt;arve@android.com&gt;

net: Fix compilation of the IPv6 module

Fix compilation of the IPv6 module -- current-&gt;euid does not exist anymore,
current_euid() is what needs to be used.

Signed-off-by: Steinar H. Gunderson &lt;sesse@google.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
With CONFIG_ANDROID_PARANOID_NETWORK, require specific uids/gids to instantiate
network sockets.

Signed-off-by: Robert Love &lt;rlove@google.com&gt;

paranoid networking: Use in_egroup_p() to check group membership

The previous group_search() caused trouble for partners with module builds.
in_egroup_p() is also cleaner.

Signed-off-by: Nick Pelly &lt;npelly@google.com&gt;

Fix 2.6.29 build.

Signed-off-by: Arve Hjønnevåg &lt;arve@android.com&gt;

net: Fix compilation of the IPv6 module

Fix compilation of the IPv6 module -- current-&gt;euid does not exist anymore,
current_euid() is what needs to be used.

Signed-off-by: Steinar H. Gunderson &lt;sesse@google.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>Bluetooth: Release BTM while sleeping to avoid deadlock</title>
<updated>2011-02-16T18:54:11+00:00</updated>
<author>
<name>Vladislav P</name>
<email>vladisslav@inbox.ru</email>
</author>
<published>2011-02-14T17:21:50+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=840af824b2bf9194ea596e0ddc7aa05066794ca1'/>
<id>840af824b2bf9194ea596e0ddc7aa05066794ca1</id>
<content type='text'>
Signed-off-by: Vladislav P &lt;vladisslav@inbox.ru&gt;
Signed-off-by: Gustavo F. Padovan &lt;padovan@profusion.mobi&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Signed-off-by: Vladislav P &lt;vladisslav@inbox.ru&gt;
Signed-off-by: Gustavo F. Padovan &lt;padovan@profusion.mobi&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>Bluetooth: Set conn state to BT_DISCONN to avoid multiple responses</title>
<updated>2011-02-02T14:47:59+00:00</updated>
<author>
<name>Bao Liang</name>
<email>tim.bao@gmail.com</email>
</author>
<published>2011-01-29T13:39:37+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=e733fb62082b3b187870dfba28d5f6730b8436c4'/>
<id>e733fb62082b3b187870dfba28d5f6730b8436c4</id>
<content type='text'>
This patch fixes a minor issue that two connection responses will be sent
for one L2CAP connection request. If the L2CAP connection request is first
blocked due to security reason and responded with reason "security block",
the state of the connection remains BT_CONNECT2. If a pairing procedure
completes successfully before the ACL connection is down, local host will
send another connection complete response. See the following packets
captured by hcidump.

2010-12-07 22:21:24.928096 &lt; ACL data: handle 12 flags 0x00 dlen 16
    0000: 0c 00 01 00 03 19 08 00  41 00 53 00 03 00 00 00  ........A.S.....
... ...

2010-12-07 22:21:35.791747 &gt; HCI Event: Auth Complete (0x06) plen 3
    status 0x00 handle 12
... ...

2010-12-07 22:21:35.872372 &gt; ACL data: handle 12 flags 0x02 dlen 16
    L2CAP(s): Connect rsp: dcid 0x0054 scid 0x0040 result 0 status 0
      Connection successful

Signed-off-by: Liang Bao &lt;tim.bao@gmail.com&gt;
Acked-by: Ville Tervo &lt;ville.tervo@nokia.com&gt;
Signed-off-by: Gustavo F. Padovan &lt;padovan@profusion.mobi&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
This patch fixes a minor issue that two connection responses will be sent
for one L2CAP connection request. If the L2CAP connection request is first
blocked due to security reason and responded with reason "security block",
the state of the connection remains BT_CONNECT2. If a pairing procedure
completes successfully before the ACL connection is down, local host will
send another connection complete response. See the following packets
captured by hcidump.

2010-12-07 22:21:24.928096 &lt; ACL data: handle 12 flags 0x00 dlen 16
    0000: 0c 00 01 00 03 19 08 00  41 00 53 00 03 00 00 00  ........A.S.....
... ...

2010-12-07 22:21:35.791747 &gt; HCI Event: Auth Complete (0x06) plen 3
    status 0x00 handle 12
... ...

2010-12-07 22:21:35.872372 &gt; ACL data: handle 12 flags 0x02 dlen 16
    L2CAP(s): Connect rsp: dcid 0x0054 scid 0x0040 result 0 status 0
      Connection successful

Signed-off-by: Liang Bao &lt;tim.bao@gmail.com&gt;
Acked-by: Ville Tervo &lt;ville.tervo@nokia.com&gt;
Signed-off-by: Gustavo F. Padovan &lt;padovan@profusion.mobi&gt;
</pre>
</div>
</content>
</entry>
</feed>
