linux-toradex.git/net/bluetooth, branch v2.6.35.4 Linux kernel for Apalis and Colibri modules Bluetooth: Update sec_level/auth_type for already existing connections 2010-07-08T23:35:31+00:00 Ville Tervo ville.tervo@nokia.com 2010-06-15T12:56:05+00:00 045309820afe047920a50de25634dab46a1e851d Update auth level for already existing connections if it is lower than required by new connection. Signed-off-by: Ville Tervo <ville.tervo@nokia.com> Reviewed-by: Emeltchenko Andrei <andrei.emeltchenko@nokia.com> Signed-off-by: Luciano Coelho <luciano.coelho@nokia.com> Signed-off-by: Andrei Emeltchenko <andrei.emeltchenko@nokia.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org> 
Update auth level for already existing connections if it is lower
than required by new connection.

Signed-off-by: Ville Tervo <ville.tervo@nokia.com>
Reviewed-by: Emeltchenko Andrei <andrei.emeltchenko@nokia.com>
Signed-off-by: Luciano Coelho <luciano.coelho@nokia.com>
Signed-off-by: Andrei Emeltchenko <andrei.emeltchenko@nokia.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Bluetooth: Reset the security level after an authentication failure 2010-07-08T23:35:27+00:00 Johan Hedberg johan.hedberg@nokia.com 2010-06-18T08:08:56+00:00 da213f41cdd445d3df468f8fe7f24fe4f4c48508 When authentication fails for a connection the assumed security level should be set back to BT_SECURITY_LOW so that subsequent connect attempts over the same link don't falsely assume that security is adequate enough. Signed-off-by: Johan Hedberg <johan.hedberg@nokia.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org> 
When authentication fails for a connection the assumed security level
should be set back to BT_SECURITY_LOW so that subsequent connect
attempts over the same link don't falsely assume that security is
adequate enough.

Signed-off-by: Johan Hedberg <johan.hedberg@nokia.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Bluetooth: Check L2CAP pending status before sending connect request 2010-07-08T23:35:23+00:00 Andrei Emeltchenko andrei.emeltchenko@nokia.com 2010-07-08T09:14:41+00:00 e501d0553a7580fcc6654d7f58a5f061d31d00af Due to race condition in L2CAP state machine L2CAP Connection Request may be sent twice for SDP with the same source channel id. Problems reported connecting to Apple products, some carkit, Blackberry phones. ... 2010-06-07 21:18:03.651031 < ACL data: handle 1 flags 0x02 dlen 12 L2CAP(s): Connect req: psm 1 scid 0x0040 2010-06-07 21:18:03.653473 > HCI Event: Number of Completed Packets (0x13) plen 5 handle 1 packets 1 2010-06-07 21:18:03.653808 > HCI Event: Auth Complete (0x06) plen 3 status 0x00 handle 1 2010-06-07 21:18:03.653869 < ACL data: handle 1 flags 0x02 dlen 12 L2CAP(s): Connect req: psm 1 scid 0x0040 ... Patch uses L2CAP_CONF_CONNECT_PEND flag to mark that L2CAP Connection Request has been sent already. Modified version of patch from Ville Tervo. Signed-off-by: Andrei Emeltchenko <andrei.emeltchenko@nokia.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org> 
Due to race condition in L2CAP state machine L2CAP Connection Request
may be sent twice for SDP with the same source channel id. Problems
reported connecting to Apple products, some carkit, Blackberry phones.

...
2010-06-07 21:18:03.651031 < ACL data: handle 1 flags 0x02 dlen 12
    L2CAP(s): Connect req: psm 1 scid 0x0040
2010-06-07 21:18:03.653473 > HCI Event: Number of Completed Packets (0x13) plen 5
    handle 1 packets 1
2010-06-07 21:18:03.653808 > HCI Event: Auth Complete (0x06) plen 3
    status 0x00 handle 1
2010-06-07 21:18:03.653869 < ACL data: handle 1 flags 0x02 dlen 12
    L2CAP(s): Connect req: psm 1 scid 0x0040
...

Patch uses L2CAP_CONF_CONNECT_PEND flag to mark that L2CAP Connection
Request has been sent already.

Modified version of patch from Ville Tervo.

Signed-off-by: Andrei Emeltchenko <andrei.emeltchenko@nokia.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Bluetooth: Bring back var 'i' increment 2010-06-25T05:08:37+00:00 Gustavo F. Padovan padovan@profusion.mobi 2010-06-18T14:24:00+00:00 1a61a83ff59378a5613d8c706c4a660c353b62a8 commit ff6e2163f28a1094fb5ca5950fe2b43c3cf6bc7a accidentally added a regression on the bnep code. Fixing it. Signed-off-by: Gustavo F. Padovan <padovan@profusion.mobi> Signed-off-by: David S. Miller <davem@davemloft.net> 
commit ff6e2163f28a1094fb5ca5950fe2b43c3cf6bc7a accidentally added a
regression on the bnep code. Fixing it.

Signed-off-by: Gustavo F. Padovan <padovan@profusion.mobi>
Signed-off-by: David S. Miller <davem@davemloft.net>
net: Remove unnecessary returns from void function()s 2010-05-18T06:23:14+00:00 Joe Perches joe@perches.com 2010-05-18T06:08:21+00:00 3fa21e07e6acefa31f974d57fba2b6920a7ebd1a This patch removes from net/ (but not any netfilter files) all the unnecessary return; statements that precede the last closing brace of void functions. It does not remove the returns that are immediately preceded by a label as gcc doesn't like that. Done via: $ grep -rP --include=*.[ch] -l "return;\n}" net/ | \ xargs perl -i -e 'local $/ ; while (<>) { s/\n[ \t\n]+return;\n}/\n}/g; print; }' Signed-off-by: Joe Perches <joe@perches.com> Signed-off-by: David S. Miller <davem@davemloft.net> 
This patch removes from net/ (but not any netfilter files)
all the unnecessary return; statements that precede the
last closing brace of void functions.

It does not remove the returns that are immediately
preceded by a label as gcc doesn't like that.

Done via:
$ grep -rP --include=*.[ch] -l "return;\n}" net/ | \
  xargs perl -i -e 'local $/ ; while (<>) { s/\n[ \t\n]+return;\n}/\n}/g; print; }'

Signed-off-by: Joe Perches <joe@perches.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Bluetooth: Fix issues where sk_sleep() helper is needed now 2010-05-10T09:33:10+00:00 Marcel Holtmann marcel@holtmann.org 2010-05-10T09:33:10+00:00 2b0b05ddc04b6d45e71cd36405df512075786f1e There were some left-overs that used sk->sk_sleep instead of the new sk_sleep() helper. Signed-off-by: Marcel Holtmann <marcel@holtmann.org> 
There were some left-overs that used sk->sk_sleep instead of the new
sk_sleep() helper.

Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Bluetooth: Use strict_strtoul instead of simple_strtoul 2010-05-10T07:34:04+00:00 Tomas Winkler tomas.winkler@intel.com 2010-03-09T19:38:03+00:00 7b767cad296d17cfe071734f71a3b7b479534c8c Use strict_strtoul as suggested by checkpatch.pl for more strict input checking. Signed-off-by: Tomas Winkler <tomas.winkler@intel.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org> 
Use strict_strtoul as suggested by checkpatch.pl for more strict input
checking.

Signed-off-by: Tomas Winkler <tomas.winkler@intel.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Bluetooth: Create per controller workqueue 2010-05-10T07:34:03+00:00 Marcel Holtmann marcel@holtmann.org 2010-03-20T14:20:04+00:00 f48fd9c8cd746fdb055a97249a209c77dca0f710 Instead of having a global workqueue for all controllers, it makes more sense to have a workqueue per controller. Signed-off-by: Marcel Holtmann <marcel@holtmann.org> 
Instead of having a global workqueue for all controllers, it makes
more sense to have a workqueue per controller.

Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Bluetooth: Fix spec error in the RemoteBusy Logic 2010-05-10T07:28:53+00:00 Gustavo F. Padovan padovan@profusion.mobi 2010-05-05T02:16:01+00:00 844c0972427ee5f661158160aaca10b22b3dda60 On the receipt of an RR(P=1) under RemoteBusy set to TRUE(on the RECV state table) we have to call sendIorRRorRNR(F=1) and just after set RemoteBusy to False. This leads to a freeze in the sending process since it's not allowed send data with RemoteBusy set to true and no one call SendPending-I-Frames after set RemoteBusy to false(The last action for that event). Actually sendIorRRorRNR() calls SendPending-I-Frames but at that moment RemoteBusy is still True and we cannot send any frame, after, no one calls SendPending-I-Frames again and the sending process stops. The solution here is to set RemoteBusy to false inside SendPending-I-Frames just before call SendPending-I-Frames. That will make SendPending-I-Frames able to send frames. This solution is similar to what RR(P=0)(F=0) on the RECV table and RR(P=1) on the SREJ_SENT table do. Actually doesn't make any sense call SendPending-I-Frames if we can send any frame, i. e., RemoteBusy is True. Signed-off-by: Gustavo F. Padovan <padovan@profusion.mobi> Signed-off-by: Marcel Holtmann <marcel@holtmann.org> 
On the receipt of an RR(P=1) under RemoteBusy set to TRUE(on the RECV
state table) we have to call sendIorRRorRNR(F=1) and just after set
RemoteBusy to False. This leads to a freeze in the sending process since
it's not allowed send data with RemoteBusy set to true and no one
call SendPending-I-Frames after set RemoteBusy to false(The last action
for that event).

Actually sendIorRRorRNR() calls SendPending-I-Frames but at that moment
RemoteBusy is still True and we cannot send any frame, after, no one
calls SendPending-I-Frames again and the sending process stops.

The solution here is to set RemoteBusy to false inside
SendPending-I-Frames just before call SendPending-I-Frames. That will
make SendPending-I-Frames able to send frames. This solution is similar
to what RR(P=0)(F=0) on the RECV table and RR(P=1) on the SREJ_SENT
table do.

Actually doesn't make any sense call SendPending-I-Frames if we can send
any frame, i. e., RemoteBusy is True.

Signed-off-by: Gustavo F. Padovan <padovan@profusion.mobi>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Bluetooth: Prevents buffer overflow on l2cap_ertm_reassembly_sdu() 2010-05-10T07:28:53+00:00 Gustavo F. Padovan padovan@profusion.mobi 2010-05-01T19:15:45+00:00 4178ba462a3e8ab5094e69606f01d9e95f2d5ea6 The checks should be done before the the memcpy to avoid buffer overflow. Reported-by: João Paulo Rechi Vita <jprvita@profusion.mobi> Signed-off-by: Gustavo F. Padovan <padovan@profusion.mobi> Signed-off-by: Marcel Holtmann <marcel@holtmann.org> 
The checks should be done before the the memcpy to avoid buffer
overflow.

Reported-by: João Paulo Rechi Vita <jprvita@profusion.mobi>
Signed-off-by: Gustavo F. Padovan <padovan@profusion.mobi>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>