<feed xmlns='http://www.w3.org/2005/Atom'>
<title>linux-toradex.git/include/net/bluetooth, branch tegra-10.7.1</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: Use non-flushable pb flag by default for ACL data on capable chipsets.</title>
<updated>2010-03-09T20:09:56+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=a47633bdbcc9b87f2a72e9bdf317f05e2e6c8051'/>
<id>a47633bdbcc9b87f2a72e9bdf317f05e2e6c8051</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>Revert "Bluetooth: Introduce L2CAP_LM_FLUSHABLE to allow flushing of ACL packets."</title>
<updated>2010-03-09T20:09:45+00:00</updated>
<author>
<name>Nick Pelly</name>
<email>npelly@google.com</email>
</author>
<published>2010-03-09T20:08:00+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=71682ea19f8d5d96034ce113acbbf83ac58173e6'/>
<id>71682ea19f8d5d96034ce113acbbf83ac58173e6</id>
<content type='text'>
This reverts commit d7897fd1e9fb3a5df0740dc2dc45ec94ca0965f2.

Change-Id: I3401550b6dc97b683104e9fdac30a617a2db8c8e
Signed-off-by: Nick Pelly &lt;npelly@google.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
This reverts commit d7897fd1e9fb3a5df0740dc2dc45ec94ca0965f2.

Change-Id: I3401550b6dc97b683104e9fdac30a617a2db8c8e
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>2010-02-24T22:40:25+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=3b077241e02041b1f03fee912896b8de1d7ac096'/>
<id>3b077241e02041b1f03fee912896b8de1d7ac096</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>Revert "Bluetooth: Fix rejected connection not disconnecting ACL link"</title>
<updated>2010-02-18T04:46:01+00:00</updated>
<author>
<name>Nick Pelly</name>
<email>npelly@google.com</email>
</author>
<published>2010-02-18T04:45:48+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=ce1c698ea8a242f386d03f236fac1af4f0e83495'/>
<id>ce1c698ea8a242f386d03f236fac1af4f0e83495</id>
<content type='text'>
This reverts commit 9e726b17422bade75fba94e625cd35fd1353e682.

Change-Id: I3bc2e4caa2a0e0c36b9c7de4a09b03276adae4e1
Signed-off-by: Nick Pelly &lt;npelly@google.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
This reverts commit 9e726b17422bade75fba94e625cd35fd1353e682.

Change-Id: I3bc2e4caa2a0e0c36b9c7de4a09b03276adae4e1
Signed-off-by: Nick Pelly &lt;npelly@google.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>Bluetooth: Introduce L2CAP_LM_FLUSHABLE to allow flushing of ACL packets.</title>
<updated>2010-02-08T23:36:00+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=d7897fd1e9fb3a5df0740dc2dc45ec94ca0965f2'/>
<id>d7897fd1e9fb3a5df0740dc2dc45ec94ca0965f2</id>
<content type='text'>
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 &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 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 &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>2010-02-08T23:36:00+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=7b75ff3c3f0b0014dd22c1db05ca916cd4b886e8'/>
<id>7b75ff3c3f0b0014dd22c1db05ca916cd4b886e8</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: Increase timeout for legacy pairing from 10 seconds to 40 seconds.</title>
<updated>2010-02-08T23:35:57+00:00</updated>
<author>
<name>Nick Pelly</name>
<email>npelly@google.com</email>
</author>
<published>2009-09-19T01:29:23+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=1f39bbdd42999892f5f6ef8aeb03b3fff6d1ebd6'/>
<id>1f39bbdd42999892f5f6ef8aeb03b3fff6d1ebd6</id>
<content type='text'>
Legacy pairing is a bit of a problem because on the incoming end it is
impossible to know pairing has begun:

2009-09-18 18:29:24.115692 &gt; HCI Event: Connect Request (0x04) plen 10
    bdaddr 00:23:D4:04:51:7A class 0x58020c type ACL
2009-09-18 18:29:24.115966 &lt; HCI Command: Accept Connection Request (0x01|0x0009) plen 7
    bdaddr 00:23:D4:04:51:7A role 0x00
    Role: Master
2009-09-18 18:29:24.117065 &gt; HCI Event: Command Status (0x0f) plen 4
    Accept Connection Request (0x01|0x0009) status 0x00 ncmd 1
2009-09-18 18:29:24.282928 &gt; HCI Event: Role Change (0x12) plen 8
    status 0x00 bdaddr 00:23:D4:04:51:7A role 0x00
    Role: Master
2009-09-18 18:29:24.291534 &gt; HCI Event: Connect Complete (0x03) plen 11
    status 0x00 handle 1 bdaddr 00:23:D4:04:51:7A type ACL encrypt 0x00
2009-09-18 18:29:24.291839 &lt; HCI Command: Read Remote Supported Features (0x01|0x001b) plen 2
    handle 1
2009-09-18 18:29:24.292144 &gt; HCI Event: Page Scan Repetition Mode Change (0x20) plen 7
    bdaddr 00:23:D4:04:51:7A mode 1
2009-09-18 18:29:24.293823 &gt; HCI Event: Command Status (0x0f) plen 4
    Read Remote Supported Features (0x01|0x001b) status 0x00 ncmd 1
2009-09-18 18:29:24.303588 &gt; HCI Event: Max Slots Change (0x1b) plen 3
    handle 1 slots 5
2009-09-18 18:29:24.309448 &gt; HCI Event: Read Remote Supported Features (0x0b) plen 11
    status 0x00 handle 1
    Features: 0xff 0xff 0x2d 0xfe 0x9b 0xff 0x79 0x83
2009-09-18 18:29:24.345916 &lt; HCI Command: Remote Name Request (0x01|0x0019) plen 10
    bdaddr 00:23:D4:04:51:7A mode 2 clkoffset 0x0000
2009-09-18 18:29:24.346923 &gt; HCI Event: Command Status (0x0f) plen 4
    Remote Name Request (0x01|0x0019) status 0x00 ncmd 1
2009-09-18 18:29:24.375793 &gt; HCI Event: Remote Name Req Complete (0x07) plen 255
    status 0x00 bdaddr 00:23:D4:04:51:7A name 'test'
2009-09-18 18:29:34.332190 &lt; HCI Command: Disconnect (0x01|0x0006) plen 3
    handle 1 reason 0x13

There are some mainline patches such as "Add different pairing timeout for
Legacy Pairing" but they do not address the HCI sequence above.

I think the real solution is to avoid using CreateBond(), and instead make
the profile connection immediately. This way both sides will use a longer
timeout because there is a higher level connection in progress, and we will
not end up with the useless HCI sequence above.

Signed-off-by: Nick Pelly &lt;npelly@google.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Legacy pairing is a bit of a problem because on the incoming end it is
impossible to know pairing has begun:

2009-09-18 18:29:24.115692 &gt; HCI Event: Connect Request (0x04) plen 10
    bdaddr 00:23:D4:04:51:7A class 0x58020c type ACL
2009-09-18 18:29:24.115966 &lt; HCI Command: Accept Connection Request (0x01|0x0009) plen 7
    bdaddr 00:23:D4:04:51:7A role 0x00
    Role: Master
2009-09-18 18:29:24.117065 &gt; HCI Event: Command Status (0x0f) plen 4
    Accept Connection Request (0x01|0x0009) status 0x00 ncmd 1
2009-09-18 18:29:24.282928 &gt; HCI Event: Role Change (0x12) plen 8
    status 0x00 bdaddr 00:23:D4:04:51:7A role 0x00
    Role: Master
2009-09-18 18:29:24.291534 &gt; HCI Event: Connect Complete (0x03) plen 11
    status 0x00 handle 1 bdaddr 00:23:D4:04:51:7A type ACL encrypt 0x00
2009-09-18 18:29:24.291839 &lt; HCI Command: Read Remote Supported Features (0x01|0x001b) plen 2
    handle 1
2009-09-18 18:29:24.292144 &gt; HCI Event: Page Scan Repetition Mode Change (0x20) plen 7
    bdaddr 00:23:D4:04:51:7A mode 1
2009-09-18 18:29:24.293823 &gt; HCI Event: Command Status (0x0f) plen 4
    Read Remote Supported Features (0x01|0x001b) status 0x00 ncmd 1
2009-09-18 18:29:24.303588 &gt; HCI Event: Max Slots Change (0x1b) plen 3
    handle 1 slots 5
2009-09-18 18:29:24.309448 &gt; HCI Event: Read Remote Supported Features (0x0b) plen 11
    status 0x00 handle 1
    Features: 0xff 0xff 0x2d 0xfe 0x9b 0xff 0x79 0x83
2009-09-18 18:29:24.345916 &lt; HCI Command: Remote Name Request (0x01|0x0019) plen 10
    bdaddr 00:23:D4:04:51:7A mode 2 clkoffset 0x0000
2009-09-18 18:29:24.346923 &gt; HCI Event: Command Status (0x0f) plen 4
    Remote Name Request (0x01|0x0019) status 0x00 ncmd 1
2009-09-18 18:29:24.375793 &gt; HCI Event: Remote Name Req Complete (0x07) plen 255
    status 0x00 bdaddr 00:23:D4:04:51:7A name 'test'
2009-09-18 18:29:34.332190 &lt; HCI Command: Disconnect (0x01|0x0006) plen 3
    handle 1 reason 0x13

There are some mainline patches such as "Add different pairing timeout for
Legacy Pairing" but they do not address the HCI sequence above.

I think the real solution is to avoid using CreateBond(), and instead make
the profile connection immediately. This way both sides will use a longer
timeout because there is a higher level connection in progress, and we will
not end up with the useless HCI sequence above.

Signed-off-by: Nick Pelly &lt;npelly@google.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>Bluetooth: Handle L2CAP case when the remote receiver is busy</title>
<updated>2009-08-26T07:12:20+00:00</updated>
<author>
<name>Gustavo F. Padovan</name>
<email>gustavo@las.ic.unicamp.br</email>
</author>
<published>2009-08-26T07:04:02+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=2246b2f1b43f3fbd128e72b129dcbbd3202cc592'/>
<id>2246b2f1b43f3fbd128e72b129dcbbd3202cc592</id>
<content type='text'>
Implement all issues related to RemoteBusy in the RECV state table.

Signed-off-by: Gustavo F. Padovan &lt;gustavo@las.ic.unicamp.br&gt;
Signed-off-by: Marcel Holtmann &lt;marcel@holtmann.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Implement all issues related to RemoteBusy in the RECV state table.

Signed-off-by: Gustavo F. Padovan &lt;gustavo@las.ic.unicamp.br&gt;
Signed-off-by: Marcel Holtmann &lt;marcel@holtmann.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>Bluetooth: Fix rejected connection not disconnecting ACL link</title>
<updated>2009-08-22T22:05:58+00:00</updated>
<author>
<name>Luiz Augusto von Dentz</name>
<email>luiz.dentz@openbossa.org</email>
</author>
<published>2009-07-15T16:50:58+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=9e726b17422bade75fba94e625cd35fd1353e682'/>
<id>9e726b17422bade75fba94e625cd35fd1353e682</id>
<content type='text'>
When using DEFER_SETUP on a RFCOMM socket, a SABM frame triggers
authorization which when rejected send a DM response. This is fine
according to the RFCOMM spec:

    the responding implementation may replace the "proper" response
    on the Multiplexer Control channel with a DM frame, sent on the
    referenced DLCI to indicate that the DLCI is not open, and that
    the responder would not grant a request to open it later either.

But some stacks doesn't seems to cope with this leaving DLCI 0 open after
receiving DM frame.

To fix it properly a timer was introduced to rfcomm_session which is used
to set a timeout when the last active DLC of a session is unlinked, this
will give the remote stack some time to reply with a proper DISC frame on
DLCI 0 avoiding both sides sending DISC to each other on stacks that
follow the specification and taking care of those who don't by taking
down DLCI 0.

Signed-off-by: Luiz Augusto von Dentz &lt;luiz.dentz@openbossa.org&gt;
Signed-off-by: Marcel Holtmann &lt;marcel@holtmann.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
When using DEFER_SETUP on a RFCOMM socket, a SABM frame triggers
authorization which when rejected send a DM response. This is fine
according to the RFCOMM spec:

    the responding implementation may replace the "proper" response
    on the Multiplexer Control channel with a DM frame, sent on the
    referenced DLCI to indicate that the DLCI is not open, and that
    the responder would not grant a request to open it later either.

But some stacks doesn't seems to cope with this leaving DLCI 0 open after
receiving DM frame.

To fix it properly a timer was introduced to rfcomm_session which is used
to set a timeout when the last active DLC of a session is unlinked, this
will give the remote stack some time to reply with a proper DISC frame on
DLCI 0 avoiding both sides sending DISC to each other on stacks that
follow the specification and taking care of those who don't by taking
down DLCI 0.

Signed-off-by: Luiz Augusto von Dentz &lt;luiz.dentz@openbossa.org&gt;
Signed-off-by: Marcel Holtmann &lt;marcel@holtmann.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>Bluetooth: Full support for receiving L2CAP SREJ frames</title>
<updated>2009-08-22T22:03:43+00:00</updated>
<author>
<name>Gustavo F. Padovan</name>
<email>gustavo@las.ic.unicamp.br</email>
</author>
<published>2009-08-21T01:26:04+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=ef54fd937fbd5ebaeb023818524565bd526a5f36'/>
<id>ef54fd937fbd5ebaeb023818524565bd526a5f36</id>
<content type='text'>
Support for receiving of SREJ frames as specified by the state table.

Signed-off-by: Gustavo F. Padovan &lt;gustavo@las.ic.unicamp.br&gt;
Signed-off-by: Marcel Holtmann &lt;marcel@holtmann.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Support for receiving of SREJ frames as specified by the state table.

Signed-off-by: Gustavo F. Padovan &lt;gustavo@las.ic.unicamp.br&gt;
Signed-off-by: Marcel Holtmann &lt;marcel@holtmann.org&gt;
</pre>
</div>
</content>
</entry>
</feed>
