* [PATCHv2] Bluetooth: fix crash by disabling tasklet in sock accept
From: Emeltchenko Andrei @ 2011-01-20 8:38 UTC (permalink / raw)
To: linux-bluetooth
From: Andrei Emeltchenko <andrei.emeltchenko@nokia.com>
Crash can happen when tasklet handling connect/disconnect requests
preempts socket accept. Can be reproduced with "l2test -r" on one
side and several "l2test -c -b 1000 -i hci0 -P 10 <bdaddr>" on the
other side.
disable taskets in socket accept and change lock_sock and release_sock
to bh_lock_sock and bh_unlock_sock since we have to use spinlocks and
there is no need to mark sock as owned by user.
...
[ 3555.897247] Unable to handle kernel NULL pointer dereference at virtual
address 000000bc
[ 3555.915039] pgd = cab9c000
[ 3555.917785] [000000bc] *pgd=8bf3d031, *pte=00000000, *ppte=00000000
[ 3555.928314] Internal error: Oops: 17 [#1] PREEMPT
[ 3555.999786] CPU: 0 Not tainted (2.6.32.21-13874-g67918ef #65)
...
[ 3556.005981] PC is at bt_accept_unlink+0x20/0x58 [bluetooth]
[ 3556.011627] LR is at bt_accept_dequeue+0x3c/0xe8 [bluetooth]
...
[ 3556.161285] [<bf0007fc>] (bt_accept_unlink+0x20/0x58 [bluetooth]) from
[<bf000870>] (bt_accept_dequeue+0x3c/0xe8 [bluetooth])
[ 3556.172729] [<bf000870>] (bt_accept_dequeue+0x3c/0xe8 [bluetooth]) from
[<bf324df8>] (l2cap_sock_accept+0x100/0x15c [l2cap])
[ 3556.184082] [<bf324df8>] (l2cap_sock_accept+0x100/0x15c [l2cap]) from
[<c026a0a8>] (sys_accept4+0x120/0x1e0)
[ 3556.193969] [<c026a0a8>] (sys_accept4+0x120/0x1e0) from [<c002c9a0>]
(ret_fast_syscall+0x0/0x2c)
[ 3556.202819] Code: e5813000 e5901164 e580c160 e580c15c (e1d13bbc)
...
Signed-off-by: Andrei Emeltchenko <andrei.emeltchenko@nokia.com>
---
net/bluetooth/af_bluetooth.c | 12 ++++++++----
1 files changed, 8 insertions(+), 4 deletions(-)
diff --git a/net/bluetooth/af_bluetooth.c b/net/bluetooth/af_bluetooth.c
index a6732b5..f545566 100644
--- a/net/bluetooth/af_bluetooth.c
+++ b/net/bluetooth/af_bluetooth.c
@@ -199,14 +199,15 @@ struct sock *bt_accept_dequeue(struct sock *parent, struct socket *newsock)
BT_DBG("parent %p", parent);
+ local_bh_disable();
list_for_each_safe(p, n, &bt_sk(parent)->accept_q) {
sk = (struct sock *) list_entry(p, struct bt_sock, accept_q);
- lock_sock(sk);
+ bh_lock_sock(sk);
/* FIXME: Is this check still needed */
if (sk->sk_state == BT_CLOSED) {
- release_sock(sk);
+ bh_unlock_sock(sk);
bt_accept_unlink(sk);
continue;
}
@@ -216,12 +217,15 @@ struct sock *bt_accept_dequeue(struct sock *parent, struct socket *newsock)
bt_accept_unlink(sk);
if (newsock)
sock_graft(sk, newsock);
- release_sock(sk);
+ bh_unlock_sock(sk);
+ local_bh_enable();
return sk;
}
- release_sock(sk);
+ bh_unlock_sock(sk);
}
+ local_bh_enable();
+
return NULL;
}
EXPORT_SYMBOL(bt_accept_dequeue);
--
1.7.1
^ permalink raw reply related
* Re: [PATCH] Set connection state to BT_DISCONN to avoid multiple responses
From: Liang Bao @ 2011-01-20 2:31 UTC (permalink / raw)
To: Gustavo F. Padovan; +Cc: linux-bluetooth
In-Reply-To: <20110119180107.GE11083@joana>
2011/1/20 Gustavo F. Padovan <padovan@profusion.mobi>:
> Hi Bao,
>
> * tim.bao@gmail.com <tim.bao@gmail.com> [2011-01-19 21:22:09 +0800]:
>
>> From: Bao Liang <tim.bao@gmail.com>
>>
>> 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 < 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 > HCI Event: Auth Complete (0x06) plen 3
>> status 0x00 handle 12
>> ... ...
>>
>> 2010-12-07 22:21:35.872372 > ACL data: handle 12 flags 0x02 dlen 16
>> L2CAP(s): Connect rsp: dcid 0x0054 scid 0x0040 result 0 status 0
>> Connection successful
>
> Please provide a more helpful hcidump showing at least the connection request
> and the two connection response.
Sure, here's the full log of one try with the following steps:
- Unpair from the host side while KB is connected.(2010-12-07 22:21:13.133047)
- Press the "Connect" button of Logitech V470, the mouse will try to
connect back although it's put into discoverable mode
meanwhile(2010-12-07 22:21:24.459891).
- HID control channel will be asked to UNPLUG but the HID interrupt
channel will be refused for reason security block. See 2010-12-07
22:21:24.928096 - no idea why it's not decoded into ASCII format by
hcidump but FTS4BT can decode it as "Result: Refused - Security
block"
- Quickly start pair from phone side before the ACL link is down. For
dev purpose, the ACL timeout is increased but the phenomenon is still
observable with a starndard version if start pair quickly enough.
Pairing will complete without error. See 2010-12-07 22:21:35.791747
- Immediately after "auth complete", host side will respond to the
V470 with "connection successful". See 2010-12-07 22:21:35.872372
I also post log of multiple tries (including this) to
http://pastebin.com/TPHgNUKd for your reference.
It's not a big issue and connection can be finally made by a second
try in most cases. However, removing this will set the state to closed
because the host actually declined the connection request and hence a
second rsp to the l2cap_conn_req shall not be sent. Just my two cents.
2010-12-07 22:21:13.099872 > HCI Event: Disconn Complete (0x05) plen 4
status 0x00 handle 11 reason 0x16
Reason: Connection Terminated by Local Host
2010-12-07 22:21:13.125585 < HCI Command: Delete Stored Link Key
(0x03|0x0012) plen 7
bdaddr 00:1F:20:01:C9:B8 all 0
2010-12-07 22:21:13.133047 > HCI Event: Command Complete (0x0e) plen 6
Delete Stored Link Key (0x03|0x0012) ncmd 1
status 0x00 deleted 0
2010-12-07 22:21:24.459891 > HCI Event: Connect Request (0x04) plen 10
bdaddr 00:1F:20:01:C9:B8 class 0x002580 type ACL
2010-12-07 22:21:24.460063 < HCI Command: Accept Connection Request
(0x01|0x0009) plen 7
bdaddr 00:1F:20:01:C9:B8 role 0x00
Role: Master
2010-12-07 22:21:24.470041 > HCI Event: Command Status (0x0f) plen 4
Accept Connection Request (0x01|0x0009) status 0x00 ncmd 1
2010-12-07 22:21:24.629984 > HCI Event: Role Change (0x12) plen 8
status 0x00 bdaddr 00:1F:20:01:C9:B8 role 0x00
Role: Master
2010-12-07 22:21:24.780008 > HCI Event: Connect Complete (0x03) plen 11
status 0x00 handle 12 bdaddr 00:1F:20:01:C9:B8 type ACL encrypt 0x00
2010-12-07 22:21:24.780135 < HCI Command: Read Remote Supported
Features (0x01|0x001b) plen 2
handle 12
2010-12-07 22:21:24.792511 > HCI Event: Command Status (0x0f) plen 4
Read Remote Supported Features (0x01|0x001b) status 0x00 ncmd 1
2010-12-07 22:21:24.792546 > HCI Event: Read Remote Supported Features
(0x0b) plen 11
status 0x00 handle 12
Features: 0xbc 0x02 0x04 0x38 0x08 0x00 0x00 0x00
2010-12-07 22:21:24.815529 > ACL data: handle 12 flags 0x02 dlen 12
L2CAP(s): Connect req: psm 17 scid 0x0052
2010-12-07 22:21:24.815727 < ACL data: handle 12 flags 0x00 dlen 16
0C 00 01 00 03 17 08 00 40 00 52 00 01 00 00 00
2010-12-07 22:21:24.815848 < ACL data: handle 12 flags 0x00 dlen 10
06 00 01 00 0A 01 02 00 02 00
2010-12-07 22:21:24.822141 < HCI Command: Remote Name Request
(0x01|0x0019) plen 10
bdaddr 00:1F:20:01:C9:B8 mode 2 clkoffset 0x0000
2010-12-07 22:21:24.832574 > HCI Event: Number of Completed Packets
(0x13) plen 5
handle 12 packets 2
2010-12-07 22:21:24.832597 > HCI Event: Command Status (0x0f) plen 4
Remote Name Request (0x01|0x0019) status 0x00 ncmd 1
2010-12-07 22:21:24.832602 > ACL data: handle 12 flags 0x02 dlen 16
L2CAP(s): Info rsp: type 2 result 0
Extended feature mask 0x0004
Bi-directional QoS
2010-12-07 22:21:24.832756 < ACL data: handle 12 flags 0x00 dlen 16
0C 00 01 00 03 17 08 00 40 00 52 00 00 00 00 00
2010-12-07 22:21:24.879811 > ACL data: handle 12 flags 0x02 dlen 16
L2CAP(s): Config req: dcid 0x0040 flags 0x00 clen 4
MTU 185
2010-12-07 22:21:24.879871 < ACL data: handle 12 flags 0x00 dlen 18
0E 00 01 00 05 18 0A 00 52 00 00 00 00 00 01 02 B9 00
2010-12-07 22:21:24.879960 < ACL data: handle 12 flags 0x00 dlen 12
08 00 01 00 04 02 04 00 52 00 00 00
2010-12-07 22:21:24.899815 > HCI Event: Number of Completed Packets
(0x13) plen 5
handle 12 packets 2
2010-12-07 22:21:24.899828 > HCI Event: Remote Name Req Complete (0x07) plen 255
status 0x00 bdaddr 00:1F:20:01:C9:B8 name 'Bluetooth Laser Travel Mouse'
2010-12-07 22:21:24.919852 > ACL data: handle 12 flags 0x02 dlen 18
L2CAP(s): Config rsp: scid 0x0040 flags 0x00 result 0 clen 4
Success
MTU 185
2010-12-07 22:21:24.919865 > ACL data: handle 12 flags 0x02 dlen 12
L2CAP(s): Connect req: psm 19 scid 0x0053
2010-12-07 22:21:24.919951 < ACL data: handle 12 flags 0x00 dlen 16
0C 00 01 00 03 19 08 00 41 00 53 00 01 00 02 00
2010-12-07 22:21:24.920192 < ACL data: handle 12 flags 0x00 dlen 5
01 00 52 00 15
2010-12-07 22:21:24.920308 < ACL data: handle 12 flags 0x00 dlen 12
08 00 01 00 06 03 04 00 52 00 40 00
2010-12-07 22:21:24.928096 < ACL data: handle 12 flags 0x00 dlen 16
0C 00 01 00 03 19 08 00 41 00 53 00 03 00 00 00
2010-12-07 22:21:24.929844 > HCI Event: Number of Completed Packets
(0x13) plen 5
handle 12 packets 2
2010-12-07 22:21:24.929857 > HCI Event: Number of Completed Packets
(0x13) plen 5
handle 12 packets 2
2010-12-07 22:21:24.939857 > ACL data: handle 12 flags 0x02 dlen 12
L2CAP(s): Disconn rsp: dcid 0x0052 scid 0x0040
2010-12-07 22:21:25.109941 > HCI Event: Number of Completed Packets
(0x13) plen 5
handle 12 packets 1
2010-12-07 22:21:27.273753 < HCI Command: Authentication Requested
(0x01|0x0011) plen 2
handle 12
2010-12-07 22:21:27.290059 > HCI Event: Command Status (0x0f) plen 4
Authentication Requested (0x01|0x0011) status 0x00 ncmd 1
2010-12-07 22:21:27.290081 > HCI Event: Link Key Request (0x17) plen 6
bdaddr 00:1F:20:01:C9:B8
2010-12-07 22:21:27.291243 < HCI Command: Link Key Request Negative
Reply (0x01|0x000c) plen 6
bdaddr 00:1F:20:01:C9:B8
2010-12-07 22:21:27.300072 > HCI Event: Command Complete (0x0e) plen 10
Link Key Request Negative Reply (0x01|0x000c) ncmd 1
status 0x00 bdaddr 00:1F:20:01:C9:B8
2010-12-07 22:21:27.300101 > HCI Event: PIN Code Request (0x16) plen 6
bdaddr 00:1F:20:01:C9:B8
2010-12-07 22:21:35.678564 < HCI Command: PIN Code Request Reply
(0x01|0x000d) plen 23
bdaddr 00:1F:20:01:C9:B8 len 4 pin '0000'
2010-12-07 22:21:35.692679 > HCI Event: Command Complete (0x0e) plen 10
PIN Code Request Reply (0x01|0x000d) ncmd 1
status 0x00 bdaddr 00:1F:20:01:C9:B8
2010-12-07 22:21:35.791738 > HCI Event: Link Key Notification (0x18) plen 23
bdaddr 00:1F:20:01:C9:B8 key EFA3DFDFC773E2B4C5D5C3E409DA84A9 type 0
2010-12-07 22:21:35.791747 > HCI Event: Auth Complete (0x06) plen 3
status 0x00 handle 12
2010-12-07 22:21:35.791829 < ACL data: handle 12 flags 0x00 dlen 16
0C 00 01 00 03 19 08 00 41 00 53 00 00 00 00 00
2010-12-07 22:21:35.817243 < ACL data: handle 12 flags 0x00 dlen 12
08 00 01 00 02 04 04 00 01 00 40 00
2010-12-07 22:21:35.832388 > HCI Event: Number of Completed Packets
(0x13) plen 5
handle 12 packets 2
2010-12-07 22:21:35.872372 > ACL data: handle 12 flags 0x02 dlen 16
L2CAP(s): Connect rsp: dcid 0x0054 scid 0x0040 result 0 status 0
Connection successful
2010-12-07 22:21:35.872429 < ACL data: handle 12 flags 0x00 dlen 12
08 00 01 00 04 05 04 00 54 00 00 00
2010-12-07 22:21:35.902318 > ACL data: handle 12 flags 0x02 dlen 18
L2CAP(s): Config rsp: scid 0x0040 flags 0x00 result 0 clen 4
Success
MTU 185
2010-12-07 22:21:35.902330 > ACL data: handle 12 flags 0x02 dlen 16
L2CAP(s): Config req: dcid 0x0040 flags 0x00 clen 4
MTU 185
2010-12-07 22:21:35.902407 < ACL data: handle 12 flags 0x00 dlen 18
0E 00 01 00 05 1A 0A 00 54 00 00 00 00 00 01 02 B9 00
2010-12-07 22:21:35.902707 < ACL data: handle 12 flags 0x00 dlen 24
14 00 54 00 06 00 00 00 0F 35 03 19 01 00 FF FF 35 05 0A 00
00 FF FF 00
2010-12-07 22:21:35.923249 > HCI Event: Number of Completed Packets
(0x13) plen 5
handle 12 packets 2
2010-12-07 22:21:36.042451 > ACL data: handle 12 flags 0x02 dlen 27
2010-12-07 22:21:36.042480 > ACL data: handle 12 flags 0x01 dlen 27
2010-12-07 22:21:36.042487 > ACL data: handle 12 flags 0x01 dlen 27
2010-12-07 22:21:36.052466 > ACL data: handle 12 flags 0x01 dlen 27
2010-12-07 22:21:36.052485 > ACL data: handle 12 flags 0x01 dlen 24
L2CAP(d): cid 0x0040 len 128 [psm 0]
07 00 00 00 7B 00 76 36 01 C0 36 01 60 09 00 00 0A 00 01 00
00 09 00 01 35 03 19 11 24 09 00 04 35 0D 35 06 19 01 00 09
00 11 35 03 19 00 11 09 00 05 35 03 19 10 02 09 00 06 35 09
09 65 6E 09 00 6A 09 01 00 09 00 09 35 08 35 06 19 11 24 09
01 00 09 00 0D 35 0F 35 0D 35 06 19 01 00 09 00 13 35 03 19
00 11 09 01 00 25 22 4C 6F 67 69 74 65 63 68 20 56 34 37 30
20 43 6F 72 64 02 00 76
2010-12-07 22:21:36.053674 < ACL data: handle 12 flags 0x00 dlen 26
16 00 54 00 06 00 01 00 11 35 03 19 01 00 FF FF 35 05 0A 00
00 FF FF 02 00 76
2010-12-07 22:21:36.062537 > HCI Event: Number of Completed Packets
(0x13) plen 5
handle 12 packets 2
2010-12-07 22:21:36.180597 > ACL data: handle 12 flags 0x02 dlen 27
2010-12-07 22:21:36.180613 > ACL data: handle 12 flags 0x01 dlen 27
2010-12-07 22:21:36.180621 > ACL data: handle 12 flags 0x01 dlen 27
2010-12-07 22:21:36.180625 > ACL data: handle 12 flags 0x01 dlen 27
2010-12-07 22:21:36.192515 > ACL data: handle 12 flags 0x01 dlen 24
L2CAP(d): cid 0x0040 len 128 [psm 0]
07 00 01 00 7B 00 76 6C 65 73 73 20 4C 61 73 65 72 20 4D 6F
75 73 65 09 01 01 25 0F 42 6C 75 65 74 6F 6F 74 68 20 4D 6F
75 73 65 09 01 02 25 08 4C 6F 67 69 74 65 63 68 09 02 00 09
01 00 09 02 01 09 01 11 09 02 02 08 80 09 02 03 08 21 09 02
04 28 01 09 02 05 28 01 09 02 06 35 68 35 66 08 22 25 62 05
01 09 02 A1 01 85 02 09 01 A1 00 05 09 19 01 29 08 15 00 25
01 75 01 95 08 02 00 EC
2010-12-07 22:21:36.193599 < ACL data: handle 12 flags 0x00 dlen 26
16 00 54 00 06 00 02 00 11 35 03 19 01 00 FF FF 35 05 0A 00
00 FF FF 02 00 EC
2010-12-07 22:21:36.300605 > ACL data: handle 12 flags 0x02 dlen 27
2010-12-07 22:21:36.300622 > ACL data: handle 12 flags 0x01 dlen 27
2010-12-07 22:21:36.312521 > ACL data: handle 12 flags 0x01 dlen 27
2010-12-07 22:21:36.312539 > ACL data: handle 12 flags 0x01 dlen 27
2010-12-07 22:21:36.312543 > ACL data: handle 12 flags 0x01 dlen 24
L2CAP(d): cid 0x0040 len 128 [psm 0]
07 00 02 00 7B 00 76 81 02 05 01 09 30 09 31 16 01 F8 26 FF
07 75 0C 95 02 81 06 09 38 15 81 25 7F 75 08 95 01 81 06 05
0C 0A 38 02 75 08 95 01 81 06 C0 C0 06 00 FF 09 01 A1 01 85
10 75 08 95 06 15 00 26 FF 00 09 01 81 00 09 01 91 00 C0 09
02 07 35 08 35 06 09 04 09 09 01 00 09 02 08 28 00 09 02 09
28 01 09 02 0A 28 01 09 02 0B 09 01 00 09 02 0C 09 0C 80 09
02 0D 28 00 09 02 01 62
2010-12-07 22:21:36.313630 < ACL data: handle 12 flags 0x00 dlen 26
16 00 54 00 06 00 03 00 11 35 03 19 01 00 FF FF 35 05 0A 00
00 FF FF 02 01 62
2010-12-07 22:21:36.322432 > HCI Event: Number of Completed Packets
(0x13) plen 5
handle 12 packets 2
2010-12-07 22:21:36.440618 > ACL data: handle 12 flags 0x02 dlen 27
2010-12-07 22:21:36.440635 > ACL data: handle 12 flags 0x01 dlen 27
2010-12-07 22:21:36.440639 > ACL data: handle 12 flags 0x01 dlen 27
2010-12-07 22:21:36.440643 > ACL data: handle 12 flags 0x01 dlen 27
2010-12-07 22:21:36.452517 > ACL data: handle 12 flags 0x01 dlen 1
L2CAP(d): cid 0x0040 len 105 [psm 0]
07 00 03 00 64 00 61 02 0E 28 01 36 00 5A 09 00 00 0A 00 01
00 01 09 00 01 35 03 19 12 00 09 00 04 35 0D 35 06 19 01 00
09 00 01 35 03 19 00 01 09 00 05 35 03 19 10 02 09 00 09 35
08 35 06 19 12 00 09 01 00 09 02 00 09 01 00 09 02 01 09 04
6D 09 02 02 09 B0 08 09 02 03 09 03 17 09 02 04 28 01 09 02
05 09 00 02 00
2010-12-07 22:21:36.484591 < ACL data: handle 12 flags 0x00 dlen 24
14 00 54 00 06 00 04 00 0F 35 03 19 12 00 FF FF 35 05 0A 00
00 FF FF 00
2010-12-07 22:21:36.592512 > ACL data: handle 12 flags 0x02 dlen 27
2010-12-07 22:21:36.592536 > ACL data: handle 12 flags 0x01 dlen 27
2010-12-07 22:21:36.592540 > ACL data: handle 12 flags 0x01 dlen 27
2010-12-07 22:21:36.592550 > ACL data: handle 12 flags 0x01 dlen 27
L2CAP(d): cid 0x0040 len 104 [psm 0]
07 00 04 00 63 00 60 36 00 5D 36 00 5A 09 00 00 0A 00 01 00
01 09 00 01 35 03 19 12 00 09 00 04 35 0D 35 06 19 01 00 09
00 01 35 03 19 00 01 09 00 05 35 03 19 10 02 09 00 09 35 08
35 06 19 12 00 09 01 00 09 02 00 09 01 00 09 02 01 09 04 6D
09 02 02 09 B0 08 09 02 03 09 03 17 09 02 04 28 01 09 02 05
09 00 02 00
2010-12-07 22:21:36.666846 < ACL data: handle 12 flags 0x00 dlen 12
08 00 01 00 02 06 04 00 11 00 42 00
2010-12-07 22:21:36.672425 > HCI Event: Number of Completed Packets
(0x13) plen 5
handle 12 packets 2
2010-12-07 22:21:36.702399 > ACL data: handle 12 flags 0x02 dlen 16
L2CAP(s): Connect rsp: dcid 0x0000 scid 0x0042 result 4 status 0
Connection refused - no resources available
2010-12-07 22:21:38.422526 > ACL data: handle 12 flags 0x02 dlen 12
L2CAP(s): Disconn req: dcid 0x0040 scid 0x0054
2010-12-07 22:21:38.422675 < ACL data: handle 12 flags 0x00 dlen 12
08 00 01 00 07 1B 04 00 40 00 54 00
2010-12-07 22:21:38.602501 > HCI Event: Number of Completed Packets
(0x13) plen 5
handle 12 packets 1
2010-12-07 22:21:38.602523 > HCI Event: Disconn Complete (0x05) plen 4
status 0x00 handle 12 reason 0x16
Reason: Connection Terminated by Local Host
>
> --
> Gustavo F. Padovan
> http://profusion.mobi
>
^ permalink raw reply
* Re: [PATCH 0/3] Add READ_BLOB support to attrib-server
From: Brian Gix @ 2011-01-19 22:05 UTC (permalink / raw)
To: linux-bluetooth
Cc: vinicius.gomes, claudio.takahasi, johan.hedberg, padovan,
rshaffer
In-Reply-To: <1295474453-8495-1-git-send-email-bgix@codeaurora.org>
Hi All -- Correction below.
On Wed, 2011-01-19 at 14:00 -0800, Brian Gix wrote:
> The following patches were cretated off of the working bluez tip at git.kernel.org as of:
>
> commit f0411254277e6c2273d32379e4a2d3742ee05e55
> Author: Johan Hedberg <johan.hedberg@nokia.com>
> Date: Wed Jan 19 22:20:41 2011 +0530
>
> Update NREC callback code to originally intended v2 state
>
>
> Patch 1 adds the default MTU for L2CAP based ATT connections (48) and
> modifies the usages for consistency. This is important when segmenting
> long attribute over multiple transactions, because remote clients will
> typically decide wether to issue subsequent READ_BLOB request based on wether
> the prior read filled the entire MTU. This explicitely does not address
> situations where a larger MTU than the defaults (23 and 48) are used, but
> in practice, there is no evidence that they exist at this time.
>
> Patch 2 is some maintanence to fix the attrib-server to correctly indicate
> the end of the service range, if a primary or secondary service contains
> nothing but the service declaration. This can be seen prior to this patch
> in attrib-server.c in the GATT_PRIM_SVC_UUID definition which sent a service
> range of 0x0010 - 0x0006 instead of 0x0010 - 0x0010.
What I meant was it is the GENERIC_ATTRIB_PROFILE_ID service which is
(prior to this patch) indicating an incorrect and invalid range.
> Patch 3 completes the implementation. It can be tested on the current example
> server by reading attribute 0x0214, which caontains a 25 octet string.
>
--
Brian Gix
bgix@codeaurora.org
Employee of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum
^ permalink raw reply
* [PATCH 3/3] Add READ_BLOB_REQUEST support to attribute server
From: Brian Gix @ 2011-01-19 22:00 UTC (permalink / raw)
To: linux-bluetooth
Cc: vinicius.gomes, claudio.takahasi, johan.hedberg, padovan,
rshaffer, Brian Gix
In-Reply-To: <1295474453-8495-1-git-send-email-bgix@codeaurora.org>
---
attrib/att.c | 44 ++++++++++++++++++++++++++++++++++++++++++++
attrib/att.h | 6 +++++-
src/attrib-server.c | 39 +++++++++++++++++++++++++++++++++++++--
3 files changed, 86 insertions(+), 3 deletions(-)
diff --git a/attrib/att.c b/attrib/att.c
index f8dbc02..dff8597 100644
--- a/attrib/att.c
+++ b/attrib/att.c
@@ -582,6 +582,33 @@ uint16_t dec_read_req(const uint8_t *pdu, int len, uint16_t *handle)
return min_len;
}
+uint16_t dec_read_blob_req(const uint8_t *pdu, int len, uint16_t *handle,
+ uint16_t *offset)
+{
+ const uint16_t min_len = sizeof(pdu[0]) + sizeof(*handle) +
+ sizeof(*offset);
+
+ if (pdu == NULL)
+ return 0;
+
+ if (handle == NULL)
+ return 0;
+
+ if (offset == NULL)
+ return 0;
+
+ if (len < min_len)
+ return 0;
+
+ if (pdu[0] != ATT_OP_READ_BLOB_REQ)
+ return 0;
+
+ *handle = att_get_u16(&pdu[1]);
+ *offset = att_get_u16(&pdu[3]);
+
+ return min_len;
+}
+
uint16_t enc_read_resp(uint8_t *value, int vlen, uint8_t *pdu, int len)
{
if (pdu == NULL)
@@ -600,6 +627,23 @@ uint16_t enc_read_resp(uint8_t *value, int vlen, uint8_t *pdu, int len)
return vlen + 1;
}
+uint16_t enc_read_blob_resp(uint8_t *value, int vlen, uint16_t offset,
+ uint8_t *pdu, int len)
+{
+ if (pdu == NULL)
+ return 0;
+
+ vlen -= offset;
+ if (vlen > len - 1)
+ vlen = len - 1;
+
+ pdu[0] = ATT_OP_READ_BLOB_RESP;
+
+ memcpy(pdu + 1, &value[offset], vlen);
+
+ return vlen + 1;
+}
+
uint16_t dec_read_resp(const uint8_t *pdu, int len, uint8_t *value, int *vlen)
{
if (pdu == NULL)
diff --git a/attrib/att.h b/attrib/att.h
index a4f6ab1..8803ae3 100644
--- a/attrib/att.h
+++ b/attrib/att.h
@@ -217,9 +217,13 @@ uint16_t dec_write_req(const uint8_t *pdu, int len, uint16_t *handle,
uint8_t *value, int *vlen);
uint16_t enc_read_req(uint16_t handle, uint8_t *pdu, int len);
uint16_t enc_read_blob_req(uint16_t handle, uint16_t offset, uint8_t *pdu,
- int len);
+ int len);
uint16_t dec_read_req(const uint8_t *pdu, int len, uint16_t *handle);
+uint16_t dec_read_blob_req(const uint8_t *pdu, int len, uint16_t *handle,
+ uint16_t *offset);
uint16_t enc_read_resp(uint8_t *value, int vlen, uint8_t *pdu, int len);
+uint16_t enc_read_blob_resp(uint8_t *value, int vlen, uint16_t offset,
+ uint8_t *pdu, int len);
uint16_t dec_read_resp(const uint8_t *pdu, int len, uint8_t *value, int *vlen);
uint16_t enc_error_resp(uint8_t opcode, uint16_t handle, uint8_t status,
uint8_t *pdu, int len);
diff --git a/src/attrib-server.c b/src/attrib-server.c
index f38d61a..631b43e 100644
--- a/src/attrib-server.c
+++ b/src/attrib-server.c
@@ -546,6 +546,33 @@ static uint16_t read_value(struct gatt_channel *channel, uint16_t handle,
return enc_read_resp(a->data, a->len, pdu, len);
}
+static uint16_t read_blob(struct gatt_channel *channel, uint16_t handle,
+ uint16_t offset, uint8_t *pdu, int len)
+{
+ struct attribute *a;
+ uint8_t status;
+ GSList *l;
+ guint h = handle;
+
+ l = g_slist_find_custom(database, GUINT_TO_POINTER(h), handle_cmp);
+ if (!l)
+ return enc_error_resp(ATT_OP_READ_BLOB_REQ, handle,
+ ATT_ECODE_INVALID_HANDLE, pdu, len);
+
+ a = l->data;
+
+ if (a->len <= offset)
+ return enc_error_resp(ATT_OP_READ_BLOB_REQ, handle,
+ ATT_ECODE_INVALID_OFFSET, pdu, len);
+
+ status = att_check_reqs(channel, ATT_OP_READ_BLOB_REQ, a->read_reqs);
+ if (status)
+ return enc_error_resp(ATT_OP_READ_BLOB_REQ, handle, status,
+ pdu, len);
+
+ return enc_read_blob_resp(a->data, a->len, offset, pdu, len);
+}
+
static uint16_t write_value(struct gatt_channel *channel, uint16_t handle,
const uint8_t *value, int vlen,
uint8_t *pdu, int len)
@@ -599,7 +626,7 @@ static void channel_handler(const uint8_t *ipdu, uint16_t len,
{
struct gatt_channel *channel = user_data;
uint8_t opdu[ATT_MAX_MTU], value[ATT_MAX_MTU];
- uint16_t length, start, end, mtu;
+ uint16_t length, start, end, mtu, offset;
uuid_t uuid;
uint8_t status = 0;
int vlen;
@@ -634,6 +661,15 @@ static void channel_handler(const uint8_t *ipdu, uint16_t len,
length = read_value(channel, start, opdu, channel->mtu);
break;
+ case ATT_OP_READ_BLOB_REQ:
+ length = dec_read_blob_req(ipdu, len, &start, &offset);
+ if (length == 0) {
+ status = ATT_ECODE_INVALID_PDU;
+ goto done;
+ }
+
+ length = read_blob(channel, start, offset, opdu, channel->mtu);
+ break;
case ATT_OP_MTU_REQ:
length = dec_mtu_req(ipdu, len, &mtu);
if (length == 0) {
@@ -679,7 +715,6 @@ static void channel_handler(const uint8_t *ipdu, uint16_t len,
length = find_by_type(start, end, &uuid, value, vlen,
opdu, channel->mtu);
break;
- case ATT_OP_READ_BLOB_REQ:
case ATT_OP_READ_MULTI_REQ:
case ATT_OP_PREP_WRITE_REQ:
case ATT_OP_EXEC_WRITE_REQ:
--
1.7.1
--
Brian Gix
bgix@codeaurora.org
Employee of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum
^ permalink raw reply related
* [PATCH 2/3] Fix Handle range if Pri/Sec Service is Empty
From: Brian Gix @ 2011-01-19 22:00 UTC (permalink / raw)
To: linux-bluetooth
Cc: vinicius.gomes, claudio.takahasi, johan.hedberg, padovan,
rshaffer, Brian Gix
In-Reply-To: <1295474453-8495-1-git-send-email-bgix@codeaurora.org>
---
src/attrib-server.c | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/src/attrib-server.c b/src/attrib-server.c
index 04bc1ec..f38d61a 100644
--- a/src/attrib-server.c
+++ b/src/attrib-server.c
@@ -242,6 +242,7 @@ static uint16_t read_by_group(struct gatt_channel *channel, uint16_t start,
last_size = a->len;
old = cur;
+ last_handle = cur->handle;
}
if (groups == NULL)
--
1.7.1
--
Brian Gix
bgix@codeaurora.org
Employee of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum
^ permalink raw reply related
* [PATCH 1/3] Fix default GATT/ATT MTU sizes
From: Brian Gix @ 2011-01-19 22:00 UTC (permalink / raw)
To: linux-bluetooth
Cc: vinicius.gomes, claudio.takahasi, johan.hedberg, padovan,
rshaffer, Brian Gix
In-Reply-To: <1295474453-8495-1-git-send-email-bgix@codeaurora.org>
LE and BR/EDR (standard L2CAP) have different default MTU sizes.
The LE deafult is 23, and the L2CAP default is 48. The LE default is
properly used for all GATT Commands, as they have all been designed
to fit within that constraint. However the attribute server should
use the actual MTU of the transport being used.
---
attrib/att.h | 3 ++-
attrib/gatt.c | 28 ++++++++++++++--------------
src/attrib-server.c | 6 +++++-
3 files changed, 21 insertions(+), 16 deletions(-)
diff --git a/attrib/att.h b/attrib/att.h
index a1e0b62..a4f6ab1 100644
--- a/attrib/att.h
+++ b/attrib/att.h
@@ -107,7 +107,8 @@
#define ATT_MAX_MTU 256
-#define ATT_DEFAULT_MTU 23
+#define ATT_DEFAULT_LE_MTU 23
+#define ATT_DEFAULT_L2CAP_MTU 48
/* Requirements for read/write operations */
enum {
diff --git a/attrib/gatt.c b/attrib/gatt.c
index 5d7887e..f3b513e 100644
--- a/attrib/gatt.c
+++ b/attrib/gatt.c
@@ -105,7 +105,7 @@ static void primary_by_uuid_cb(guint8 status, const guint8 *ipdu,
struct discover_primary *dp = user_data;
GSList *ranges, *last;
struct att_range *range;
- uint8_t opdu[ATT_DEFAULT_MTU];
+ uint8_t opdu[ATT_DEFAULT_LE_MTU];
guint16 oplen;
int err = 0;
@@ -195,7 +195,7 @@ static void primary_all_cb(guint8 status, const guint8 *ipdu, guint16 iplen,
err = 0;
if (end != 0xffff) {
- uint8_t opdu[ATT_DEFAULT_MTU];
+ uint8_t opdu[ATT_DEFAULT_LE_MTU];
guint16 oplen = encode_discover_primary(end + 1, 0xffff, NULL,
opdu, sizeof(opdu));
@@ -214,7 +214,7 @@ guint gatt_discover_primary(GAttrib *attrib, uuid_t *uuid, gatt_cb_t func,
gpointer user_data)
{
struct discover_primary *dp;
- uint8_t pdu[ATT_DEFAULT_MTU];
+ uint8_t pdu[ATT_DEFAULT_LE_MTU];
GAttribResultFunc cb;
guint16 plen;
@@ -245,7 +245,7 @@ static void char_discovered_cb(guint8 status, const guint8 *ipdu, guint16 iplen,
struct discover_char *dc = user_data;
struct att_data_list *list;
unsigned int i, err;
- uint8_t opdu[ATT_DEFAULT_MTU];
+ uint8_t opdu[ATT_DEFAULT_LE_MTU];
guint16 oplen;
uuid_t uuid;
uint16_t last = 0;
@@ -314,7 +314,7 @@ done:
guint gatt_discover_char(GAttrib *attrib, uint16_t start, uint16_t end,
gatt_cb_t func, gpointer user_data)
{
- uint8_t pdu[ATT_DEFAULT_MTU];
+ uint8_t pdu[ATT_DEFAULT_LE_MTU];
struct discover_char *dc;
guint16 plen;
uuid_t uuid;
@@ -342,7 +342,7 @@ guint gatt_read_char_by_uuid(GAttrib *attrib, uint16_t start, uint16_t end,
uuid_t *uuid, GAttribResultFunc func,
gpointer user_data)
{
- uint8_t pdu[ATT_DEFAULT_MTU];
+ uint8_t pdu[ATT_DEFAULT_LE_MTU];
guint16 plen;
plen = enc_read_by_type_req(start, end, uuid, pdu, sizeof(pdu));
@@ -381,7 +381,7 @@ static void read_blob_helper(guint8 status, const guint8 *rpdu, guint16 rlen,
gpointer user_data)
{
struct read_long_data *long_read = user_data;
- uint8_t pdu[ATT_DEFAULT_MTU];
+ uint8_t pdu[ATT_DEFAULT_LE_MTU];
guint8 *tmp;
guint16 plen;
guint id;
@@ -402,7 +402,7 @@ static void read_blob_helper(guint8 status, const guint8 *rpdu, guint16 rlen,
long_read->buffer = tmp;
long_read->size += rlen - 1;
- if (rlen < ATT_DEFAULT_MTU)
+ if (rlen < ATT_DEFAULT_LE_MTU)
goto done;
plen = enc_read_blob_req(long_read->handle, long_read->size - 1,
@@ -427,11 +427,11 @@ static void read_char_helper(guint8 status, const guint8 *rpdu,
guint16 rlen, gpointer user_data)
{
struct read_long_data *long_read = user_data;
- uint8_t pdu[ATT_DEFAULT_MTU];
+ uint8_t pdu[ATT_DEFAULT_LE_MTU];
guint16 plen;
guint id;
- if (status != 0 || rlen < ATT_DEFAULT_MTU)
+ if (status != 0 || rlen < ATT_DEFAULT_LE_MTU)
goto done;
long_read->buffer = g_malloc(rlen);
@@ -461,7 +461,7 @@ done:
guint gatt_read_char(GAttrib *attrib, uint16_t handle, GAttribResultFunc func,
gpointer user_data)
{
- uint8_t pdu[ATT_DEFAULT_MTU];
+ uint8_t pdu[ATT_DEFAULT_LE_MTU];
guint16 plen;
guint id;
struct read_long_data *long_read;
@@ -493,7 +493,7 @@ guint gatt_read_char(GAttrib *attrib, uint16_t handle, GAttribResultFunc func,
guint gatt_write_char(GAttrib *attrib, uint16_t handle, uint8_t *value,
int vlen, GAttribResultFunc func, gpointer user_data)
{
- uint8_t pdu[ATT_DEFAULT_MTU];
+ uint8_t pdu[ATT_DEFAULT_LE_MTU];
guint16 plen;
plen = enc_write_req(handle, value, vlen, pdu, sizeof(pdu));
@@ -504,7 +504,7 @@ guint gatt_write_char(GAttrib *attrib, uint16_t handle, uint8_t *value,
guint gatt_find_info(GAttrib *attrib, uint16_t start, uint16_t end,
GAttribResultFunc func, gpointer user_data)
{
- uint8_t pdu[ATT_DEFAULT_MTU];
+ uint8_t pdu[ATT_DEFAULT_LE_MTU];
guint16 plen;
plen = enc_find_info_req(start, end, pdu, sizeof(pdu));
@@ -518,7 +518,7 @@ guint gatt_find_info(GAttrib *attrib, uint16_t start, uint16_t end,
guint gatt_write_cmd(GAttrib *attrib, uint16_t handle, uint8_t *value, int vlen,
GDestroyNotify notify, gpointer user_data)
{
- uint8_t pdu[ATT_DEFAULT_MTU];
+ uint8_t pdu[ATT_DEFAULT_LE_MTU];
guint16 plen;
plen = enc_write_cmd(handle, value, vlen, pdu, sizeof(pdu));
diff --git a/src/attrib-server.c b/src/attrib-server.c
index 7e85d17..04bc1ec 100644
--- a/src/attrib-server.c
+++ b/src/attrib-server.c
@@ -722,8 +722,12 @@ static void connect_event(GIOChannel *io, GError *err, void *user_data)
return;
}
+ if (io == le_io)
+ channel->mtu = ATT_DEFAULT_LE_MTU;
+ else
+ channel->mtu = ATT_DEFAULT_L2CAP_MTU;
+
channel->attrib = g_attrib_new(io);
- channel->mtu = ATT_DEFAULT_MTU;
g_io_channel_unref(io);
channel->id = g_attrib_register(channel->attrib, GATTRIB_ALL_EVENTS,
--
1.7.1
--
Brian Gix
bgix@codeaurora.org
Employee of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum
^ permalink raw reply related
* [PATCH 0/3] Add READ_BLOB support to attrib-server
From: Brian Gix @ 2011-01-19 22:00 UTC (permalink / raw)
To: linux-bluetooth
Cc: vinicius.gomes, claudio.takahasi, johan.hedberg, padovan,
rshaffer
The following patches were cretated off of the working bluez tip at git.kernel.org as of:
commit f0411254277e6c2273d32379e4a2d3742ee05e55
Author: Johan Hedberg <johan.hedberg@nokia.com>
Date: Wed Jan 19 22:20:41 2011 +0530
Update NREC callback code to originally intended v2 state
Patch 1 adds the default MTU for L2CAP based ATT connections (48) and
modifies the usages for consistency. This is important when segmenting
long attribute over multiple transactions, because remote clients will
typically decide wether to issue subsequent READ_BLOB request based on wether
the prior read filled the entire MTU. This explicitely does not address
situations where a larger MTU than the defaults (23 and 48) are used, but
in practice, there is no evidence that they exist at this time.
Patch 2 is some maintanence to fix the attrib-server to correctly indicate
the end of the service range, if a primary or secondary service contains
nothing but the service declaration. This can be seen prior to this patch
in attrib-server.c in the GATT_PRIM_SVC_UUID definition which sent a service
range of 0x0010 - 0x0006 instead of 0x0010 - 0x0010.
Patch 3 completes the implementation. It can be tested on the current example
server by reading attribute 0x0214, which caontains a 25 octet string.
--
Brian Gix
bgix@codeaurora.org
Employee of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum
^ permalink raw reply
* pull request: bluetooth-2.6 2011-01-19
From: Gustavo F. Padovan @ 2011-01-19 19:27 UTC (permalink / raw)
To: linville; +Cc: linux-wireless, linux-bluetooth
Hi John,
Here is the first set of Bluetooth fixes for 2.6.38. It includes a patch from
Alexander Holler to reduce memory usage by the ath3k bluetooth driver. A
misusu of logical operation in L2CAP by David Sterba. There is also a fix to a
RFCOMM crash by Lukáš Turek.
Last we have six patches from Johan Hedberg, the first fix a leak in the
HCI blacklist feature. The other 5 patches, are fixes created against the BITE
tester (used in the Bluetooth qualification process). All of them are very
simple. Worth to note that one of them is a revert and "Bluetooth: Create a
unified auth_type evaluation function" is a very simple refactoring. These
patches makes 2.6.38 ready for the Bluetooth qualification process.
Please merge, or let me know any doubts or problems you find. Thanks.
The following changes since commit 38d59392b29437af3a702209b6a5196ef01f79a8:
iwlwifi: fix valid chain reading from EEPROM (2011-01-18 15:10:31 -0500)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/padovan/bluetooth-2.6.git master
Alexander Holler (1):
Bluetooth: ath3k: reduce memory usage
David Sterba (1):
Bluetooth: l2cap: fix misuse of logical operation in place of bitop
Johan Hedberg (6):
Bluetooth: Fix leaking blacklist when unregistering a hci device
Revert "Bluetooth: Update sec_level/auth_type for already existing connections"
Bluetooth: Fix MITM protection requirement preservation
Bluetooth: Create a unified auth_type evaluation function
Bluetooth: Fix authentication request for L2CAP raw sockets
Bluetooth: Fix race condition with conn->sec_level
Lukáš Turek (1):
Bluetooth: Never deallocate a session when some DLC points to it
drivers/bluetooth/ath3k.c | 75 +++++++++-------------------------
include/net/bluetooth/hci_core.h | 1 +
net/bluetooth/hci_conn.c | 16 ++++---
net/bluetooth/hci_core.c | 4 ++
net/bluetooth/hci_event.c | 9 ++--
net/bluetooth/l2cap.c | 84 ++++++++++++++-----------------------
net/bluetooth/rfcomm/core.c | 3 +-
7 files changed, 73 insertions(+), 119 deletions(-)
--
Gustavo F. Padovan
http://profusion.mobi
^ permalink raw reply
* Problems with L2CAP: deferred setup and MTU
From: Elvis Pfützenreuter @ 2011-01-19 19:10 UTC (permalink / raw)
To: linux-bluetooth
I am currently investigating two problems with L2CAP sockets. Since I am not a kernel guy, I will take an indefinite amount of time to find and fix them; perhaps someone else can find and fix it in 5 minutes, so I think it is worth reporting.
First problem is ERTM x MTU, sockets configured with a MTU != 672. Normal sockets exchange MTU in initialization:
./l2test -P 4099 -I 1000 -O 1000
l2test[3211]: Connect from 00:1B:DC:0F:C8:A9 [imtu 1000, omtu 1000, flush_to 65535, mode 0, handle 12, class 0x480100]
but ERTM sockets seem to ignore the setsockopt() value and exchange the default size (672):
./l2test -P 4099 -I 1000 -O 1000 -X ERTM
l2test[3228]: Connect from 00:1B:DC:0F:C8:A9 [imtu 1000, omtu 672, flush_to 65535, mode 3, handle 11, class 0x480100]
(obviously the initiator side uses the same parameters)
Second problem is about deferred setup in accept()ed sockets. Sometimes POLLOUT times out (or waits forever if timeout is 0). The following read(buf, 1) works, and the connection works normally after this.
The pattern seems to be: the first accept()ed socket of a process works ok regarding POLLOUT; the following connections do not.
This is normally not a problem, but if you try to read MTU using getsockopt() right after connection is set up, and if POLLOUT failed, MTU values are not updated. If you sleep a small amount of time like 0.1s then getsockopt() returns the expected values.
Finally, I have noted that playing with deferred setup sockets yields frequent kernel panics, like 1 in 3 rounds. This has prevented me to find more elaborate patterns (like ERTM x normal sockets etc.). The panics happen at listen() side; the connect() side is not affected. (Tested with 2.6.36 stock and bluetooth-next).
--
Elvis
^ permalink raw reply
* Re: [RFC 0/2] remove BT references from TI_ST
From: Pavan Savoy @ 2011-01-19 18:26 UTC (permalink / raw)
To: padovan, marcel; +Cc: linux-kernel, linux-bluetooth, Pavan Savoy
In-Reply-To: <1294138788-10307-1-git-send-email-pavan_savoy@ti.com>
Gustavo,
On Tue, Jan 4, 2011 at 4:29 PM, <pavan_savoy@ti.com> wrote:
> From: Pavan Savoy <pavan_savoy@ti.com>
>
> Gustavo,
>
> Based on your comments, that the underlying shared transport driver
> for btwilink driver made use of the BT references to peek into the packets
> I have modified the TI_ST.
Since there lacks a generic way to parse the packets coming in from the
UART into BT, FM or GPS, we have to look into the data to fragment assembled
data or assemble fragmented data.
Please have a look, Please suggest whether something like this is required,
If not, please also suggest, if including BT headers is a problem ?
Because I just include the BT headers and don't have a build
dependency as such on
BT/HCI and don't use any functions from hci_core in my shared transport driver.
> For this reason, Now the above lying protocol drivers like BT, FM and GPS
> would send details about their packet types and header information which
> would assist shared transport driver to parse the data.
>
> Gustavo, please also notice the change in btwilink driver in and around,
> st_register and suggest if something like this is OK.
> btwilink can also be modified to send in all the packet specific data
> in one shot, if that is preferred.
>
> Please review and provide comments..
>
> Note:
> If this is alright, I will send out a modified patch with updated
> subject to lkml/Greg for linux-next.
>
> Thanks & Regards,
> Pavan Savoy.
>
> Pavan Savoy (2):
> drivers:misc:ti-st: change protocol parse logic
> Bluetooth: btwilink driver
>
> drivers/bluetooth/Kconfig | 10 +
> drivers/bluetooth/Makefile | 1 +
> drivers/bluetooth/btwilink.c | 397 ++++++++++++++++++++++++++++++++++++++++++
> drivers/misc/ti-st/st_core.c | 355 ++++++++++++--------------------------
> drivers/misc/ti-st/st_kim.c | 56 +++---
> include/linux/ti_wilink_st.h | 40 +++--
> 6 files changed, 575 insertions(+), 284 deletions(-)
> create mode 100644 drivers/bluetooth/btwilink.c
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-bluetooth" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply
* Re: [PATCH] Set connection state to BT_DISCONN to avoid multiple responses
From: Gustavo F. Padovan @ 2011-01-19 18:01 UTC (permalink / raw)
To: tim.bao; +Cc: linux-bluetooth
In-Reply-To: <1295443329-26860-1-git-send-email-tim.bao@gmail.com>
Hi Bao,
* tim.bao@gmail.com <tim.bao@gmail.com> [2011-01-19 21:22:09 +0800]:
> From: Bao Liang <tim.bao@gmail.com>
>
> 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 < 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 > HCI Event: Auth Complete (0x06) plen 3
> status 0x00 handle 12
> ... ...
>
> 2010-12-07 22:21:35.872372 > ACL data: handle 12 flags 0x02 dlen 16
> L2CAP(s): Connect rsp: dcid 0x0054 scid 0x0040 result 0 status 0
> Connection successful
Please provide a more helpful hcidump showing at least the connection request
and the two connection response.
--
Gustavo F. Padovan
http://profusion.mobi
^ permalink raw reply
* Re: [PATCH 4/4 v2] Add proper tracking mechanism to NREC
From: Johan Hedberg @ 2011-01-19 16:51 UTC (permalink / raw)
To: Luiz Augusto von Dentz, linux-bluetooth
In-Reply-To: <20110119152351.GH2112@jh-x301>
Hi Luiz,
On Wed, Jan 19, 2011, Johan Hedberg wrote:
> On Tue, Jan 18, 2011, Luiz Augusto von Dentz wrote:
> > NREC may change during the connections so it has to be tracked in order
> > to signal changes to applications.
> > ---
> > audio/headset.c | 55 ++++++++++++++++++++++++++++++++++++++++++++++++++++-
> > audio/headset.h | 6 +++++
> > audio/transport.c | 19 ++++++++++++++++++
> > 3 files changed, 79 insertions(+), 1 deletions(-)
>
> I didn't realize there was a v2 of this and I already went ahead and
> pushed v1. What was the difference? Can you send a patch to update the
> upstream tree to whatever this v2 does?
Never mind. I went and did this myself.
Johan
^ permalink raw reply
* Re: [PATCH] Bluetooth: fix crash by disabling tasklet in sock accept
From: Gustavo F. Padovan @ 2011-01-19 16:50 UTC (permalink / raw)
To: Andrei Emeltchenko; +Cc: linux-bluetooth
In-Reply-To: <1295451471.9558.2.camel@Nokia-N900>
Hi Andrei,
* Andrei Emeltchenko <andrei.emeltchenko.news@gmail.com> [2011-01-19 17:37:50 +0200]:
> Hi,
>
> > From: Andrei Emeltchenko <andrei.emeltchenko@nokia.com>
> >
> > Crash can happen when tasklet handling connect/disconnect requests
> > preempts socket accept. Can be reproduced with "l2test -r" on one
> > side and several "l2test -c -b 1000 -i hci0 -P 10 <bdaddr>" on the
> > other side.
> >
> > ...
> > [ 3555.897247] Unable to handle kernel NULL pointer dereference at
> > virtual address 000000bc
> > [ 3555.915039] pgd = cab9c000
> > [ 3555.917785] [000000bc] *pgd=8bf3d031, *pte=00000000, *ppte=00000000
> > [ 3555.928314] Internal error: Oops: 17 [#1] PREEMPT
> > [ 3555.999786] CPU: 0 Not tainted (2.6.32.21-13874-g67918ef #65)
> > ...
> > [ 3556.005981] PC is at bt_accept_unlink+0x20/0x58 [bluetooth]
> > [ 3556.011627] LR is at bt_accept_dequeue+0x3c/0xe8 [bluetooth]
> > ...
> > [ 3556.161285] [<bf0007fc>] (bt_accept_unlink+0x20/0x58 [bluetooth]) from
> > [<bf000870>] (bt_accept_dequeue+0x3c/0xe8 [bluetooth])
> > [ 3556.172729] [<bf000870>] (bt_accept_dequeue+0x3c/0xe8 [bluetooth])
> > from [<bf324df8>] (l2cap_sock_accept+0x100/0x15c [l2cap])
> > [ 3556.184082] [<bf324df8>] (l2cap_sock_accept+0x100/0x15c [l2cap]) from
> > [<c026a0a8>] (sys_accept4+0x120/0x1e0)
> > [ 3556.193969] [<c026a0a8>] (sys_accept4+0x120/0x1e0) from [<c002c9a0>]
> > (ret_fast_syscall+0x0/0x2c)
> > [ 3556.202819] Code: e5813000 e5901164 e580c160 e580c15c (e1d13bbc)
> > ...
> >
> > Signed-off-by: Andrei Emeltchenko <andrei.emeltchenko@nokia.com>
> > ---
> > net/bluetooth/af_bluetooth.c | 4 ++++
> > 1 files changed, 4 insertions(+), 0 deletions(-)
> >
> > diff --git a/net/bluetooth/af_bluetooth.c b/net/bluetooth/af_bluetooth.c
> > index a6732b5..86386e9 100644
> > --- a/net/bluetooth/af_bluetooth.c
> > +++ b/net/bluetooth/af_bluetooth.c
> > @@ -199,6 +199,7 @@ struct sock *bt_accept_dequeue(struct sock *parent,
> > struct socket *newsock)
> > BT_DBG("parent %p", parent);
> >
> > + local_bh_disable();
> > list_for_each_safe(p, n, &bt_sk(parent)->accept_q) {
> > sk = (struct sock *) list_entry(p, struct bt_sock, accept_q);
> >
> > @@ -217,11 +218,14 @@ struct sock *bt_accept_dequeue(struct sock
> > *parent, struct socket *newsock) if (newsock)
> > sock_graft(sk, newsock);
> > release_sock(sk);
>
> I will change lock,release_sock to bh_lock,unlock_sock
>
> when bh are disabled we do not need to mark
> socket as owned.
Looks a better idea.
--
Gustavo F. Padovan
http://profusion.mobi
^ permalink raw reply
* Re: [PATCH 5/5] Bluetooth: Fix race condition with conn->sec_level
From: Gustavo F. Padovan @ 2011-01-19 16:44 UTC (permalink / raw)
To: johan.hedberg; +Cc: linux-bluetooth, ville.tervo
In-Reply-To: <1295419012-25717-6-git-send-email-johan.hedberg@gmail.com>
Hi Johan,
* johan.hedberg@gmail.com <johan.hedberg@gmail.com> [2011-01-19 12:06:52 +0530]:
> From: Johan Hedberg <johan.hedberg@nokia.com>
>
> The conn->sec_level value is supposed to represent the current level of
> security that the connection has. However, by assigning to it before
> requesting authentication it will have the wrong value during the
> authentication procedure. To fix this a pending_sec_level variable is
> added which is used to track the desired security level while making
> sure that sec_level always represents the current level of security.
>
> Signed-off-by: Johan Hedberg <johan.hedberg@nokia.com>
> ---
> include/net/bluetooth/hci_core.h | 1 +
> net/bluetooth/hci_conn.c | 8 ++++++--
> net/bluetooth/hci_event.c | 9 +++++----
> 3 files changed, 12 insertions(+), 6 deletions(-)
I rebased my tree and now this patches applies. It is there now. Thanks.
--
Gustavo F. Padovan
http://profusion.mobi
^ permalink raw reply
* Re: [PATCH 4/5] Bluetooth: Fix authentication request for L2CAP raw sockets
From: Gustavo F. Padovan @ 2011-01-19 16:29 UTC (permalink / raw)
To: johan.hedberg; +Cc: linux-bluetooth, ville.tervo
In-Reply-To: <1295419012-25717-5-git-send-email-johan.hedberg@gmail.com>
Hi Johan,
* johan.hedberg@gmail.com <johan.hedberg@gmail.com> [2011-01-19 12:06:51 +0530]:
> From: Johan Hedberg <johan.hedberg@nokia.com>
>
> When there is an existing connection l2cap_check_security needs to be
> called to ensure that the security level of the new socket is fulfilled.
> Normally l2cap_do_start takes care of this, but that function doesn't
> get called for SOCK_RAW type sockets. This patch adds the necessary
> l2cap_check_security call to the appropriate branch in l2cap_do_connect.
>
> Signed-off-by: Johan Hedberg <johan.hedberg@nokia.com>
I applied patches 1 to 4. Patch 5 doesn't apply to bluetooth-2.6. Please
rebase it. Thanks.
--
Gustavo F. Padovan
http://profusion.mobi
^ permalink raw reply
* Re: [Patch] Kill off warning: ‘inline’ is not at beginning of declaration
From: Jesper Juhl @ 2011-01-19 15:45 UTC (permalink / raw)
To: Jiri Kosina
Cc: linux-kernel, alsa-devel, linux-wireless, netdev, ocfs2-devel,
linux-edac, linux-bluetooth, oprofile-list, Andi Kleen,
David Teigland, Jens Axboe, Stephen Hemminger, Greg Kroah-Hartman,
Takashi Iwai, Jaroslav Kysela, John W. Linville, Johannes Berg,
Patrick McHardy, Hideaki YOSHIFUJI, James Morris,
Pekka Savola (ipv6), Alexey Kuznetsov, David S. Miller,
Frederic Weisbecker, Frederic Weisbecker, Joel Becker,
Mark Fasheh, Mauro Carvalho Chehab, Gustavo F. Padovan,
Marcel Holtmann, x86, H. Peter Anvin, Ingo Molnar,
Thomas Gleixner, Robert Richter
In-Reply-To: <alpine.LNX.2.00.1101191543110.26685@pobox.suse.cz>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 1835 bytes --]
On Wed, 19 Jan 2011, Jiri Kosina wrote:
> On Mon, 17 Jan 2011, Jesper Juhl wrote:
>
> > Fix a bunch of
> > warning: ‘inline’ is not at beginning of declaration
> > messages when building a 'make allyesconfig' kernel with -Wextra.
> >
> > These warnings are trivial to kill, yet rather annoying when building with
> > -Wextra.
> > The more we can cut down on pointless crap like this the better (IMHO).
> >
> > A previous patch to do this for a 'allnoconfig' build has already been
> > merged. This just takes the cleanup a little further.
> >
> > Signed-off-by: Jesper Juhl <jj@chaosbits.net>
> > ---
> > arch/x86/oprofile/op_model_p4.c | 2 +-
> > drivers/bluetooth/btusb.c | 4 ++--
> > drivers/cpuidle/sysfs.c | 2 +-
> > drivers/edac/i7300_edac.c | 2 +-
> > fs/ocfs2/dir.c | 2 +-
> > kernel/trace/ring_buffer.c | 2 +-
> > net/ipv6/inet6_hashtables.c | 2 +-
> > net/mac80211/tx.c | 2 +-
> > sound/pci/au88x0/au88x0.h | 4 ++--
> > sound/pci/au88x0/au88x0_core.c | 4 ++--
> > 10 files changed, 13 insertions(+), 13 deletions(-)
> >
>
> Wow, what a huge CC list for such a simple change. Jesper, I think you
> should re-consider this next time. I bet you used get_maintainer script,
> didn't you? :)
>
Yes, I did. I wanted to be sure that everyone whoes code I was modifying
got the mail. I guess I should have broken it up into smaller pieces and
submitted them as a series instead.
> I have applied it to my tree now. If anyone has objections/has already
> applied part of the patch to subsystem tree, please let me know.
>
Thank you.
--
Jesper Juhl <jj@chaosbits.net> http://www.chaosbits.net/
Don't top-post http://www.catb.org/~esr/jargon/html/T/top-post.html
Plain text mails only, please.
^ permalink raw reply
* Re: [PATCH] Bluetooth: fix crash by disabling tasklet in sock accept
From: Andrei Emeltchenko @ 2011-01-19 15:37 UTC (permalink / raw)
To: linux-bluetooth
In-Reply-To: <1295351698-8096-1-git-send-email-Andrei.Emeltchenko.news@gmail.com>
Hi,
> From: Andrei Emeltchenko <andrei.emeltchenko@nokia.com>
>
> Crash can happen when tasklet handling connect/disconnect requests
> preempts socket accept. Can be reproduced with "l2test -r" on one
> side and several "l2test -c -b 1000 -i hci0 -P 10 <bdaddr>" on the
> other side.
>
> ...
> [ 3555.897247] Unable to handle kernel NULL pointer dereference at
> virtual address 000000bc
> [ 3555.915039] pgd = cab9c000
> [ 3555.917785] [000000bc] *pgd=8bf3d031, *pte=00000000, *ppte=00000000
> [ 3555.928314] Internal error: Oops: 17 [#1] PREEMPT
> [ 3555.999786] CPU: 0 Not tainted (2.6.32.21-13874-g67918ef #65)
> ...
> [ 3556.005981] PC is at bt_accept_unlink+0x20/0x58 [bluetooth]
> [ 3556.011627] LR is at bt_accept_dequeue+0x3c/0xe8 [bluetooth]
> ...
> [ 3556.161285] [<bf0007fc>] (bt_accept_unlink+0x20/0x58 [bluetooth]) from
> [<bf000870>] (bt_accept_dequeue+0x3c/0xe8 [bluetooth])
> [ 3556.172729] [<bf000870>] (bt_accept_dequeue+0x3c/0xe8 [bluetooth])
> from [<bf324df8>] (l2cap_sock_accept+0x100/0x15c [l2cap])
> [ 3556.184082] [<bf324df8>] (l2cap_sock_accept+0x100/0x15c [l2cap]) from
> [<c026a0a8>] (sys_accept4+0x120/0x1e0)
> [ 3556.193969] [<c026a0a8>] (sys_accept4+0x120/0x1e0) from [<c002c9a0>]
> (ret_fast_syscall+0x0/0x2c)
> [ 3556.202819] Code: e5813000 e5901164 e580c160 e580c15c (e1d13bbc)
> ...
>
> Signed-off-by: Andrei Emeltchenko <andrei.emeltchenko@nokia.com>
> ---
> net/bluetooth/af_bluetooth.c | 4 ++++
> 1 files changed, 4 insertions(+), 0 deletions(-)
>
> diff --git a/net/bluetooth/af_bluetooth.c b/net/bluetooth/af_bluetooth.c
> index a6732b5..86386e9 100644
> --- a/net/bluetooth/af_bluetooth.c
> +++ b/net/bluetooth/af_bluetooth.c
> @@ -199,6 +199,7 @@ struct sock *bt_accept_dequeue(struct sock *parent,
> struct socket *newsock)
> BT_DBG("parent %p", parent);
>
> + local_bh_disable();
> list_for_each_safe(p, n, &bt_sk(parent)->accept_q) {
> sk = (struct sock *) list_entry(p, struct bt_sock, accept_q);
>
> @@ -217,11 +218,14 @@ struct sock *bt_accept_dequeue(struct sock
> *parent, struct socket *newsock) if (newsock)
> sock_graft(sk, newsock);
> release_sock(sk);
I will change lock,release_sock to bh_lock,unlock_sock
when bh are disabled we do not need to mark
socket as owned.
Other comments about the patch?
> + local_bh_enable();
> return sk;
> }
>
> release_sock(sk);
> }
> + local_bh_enable();
> +
> return NULL;
> }
> EXPORT_SYMBOL(bt_accept_dequeue);
> --
> 1.7.1
>
> --
> To unsubscribe from this list: send the line "unsubscribe
> linux-bluetooth" in the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH 4/4 v2] Add proper tracking mechanism to NREC
From: Johan Hedberg @ 2011-01-19 15:23 UTC (permalink / raw)
To: Luiz Augusto von Dentz; +Cc: linux-bluetooth
In-Reply-To: <1295352671-5533-1-git-send-email-luiz.dentz@gmail.com>
Hi Luiz,
On Tue, Jan 18, 2011, Luiz Augusto von Dentz wrote:
> NREC may change during the connections so it has to be tracked in order
> to signal changes to applications.
> ---
> audio/headset.c | 55 ++++++++++++++++++++++++++++++++++++++++++++++++++++-
> audio/headset.h | 6 +++++
> audio/transport.c | 19 ++++++++++++++++++
> 3 files changed, 79 insertions(+), 1 deletions(-)
I didn't realize there was a v2 of this and I already went ahead and
pushed v1. What was the difference? Can you send a patch to update the
upstream tree to whatever this v2 does?
Johan
^ permalink raw reply
* Re: [PATCH 4/4] Add proper tracking mechanism to NREC
From: Johan Hedberg @ 2011-01-19 15:22 UTC (permalink / raw)
To: Luiz Augusto von Dentz; +Cc: linux-bluetooth
In-Reply-To: <1295344815-1404-4-git-send-email-luiz.dentz@gmail.com>
Hi Luiz,
On Tue, Jan 18, 2011, Luiz Augusto von Dentz wrote:
> NREC may change during the connections so it has to be tracked in order
> to signal changes to applications.
> ---
> audio/headset.c | 62 ++++++++++++++++++++++++++++++++++++++++++++++++++++-
> audio/headset.h | 6 +++++
> audio/transport.c | 17 ++++++++++++++
> 3 files changed, 84 insertions(+), 1 deletions(-)
Pushed upstream. Thanks.
Johan
^ permalink raw reply
* Re: [PATCH 3/4] Add Routing property to MediaTransport interface
From: Johan Hedberg @ 2011-01-19 15:20 UTC (permalink / raw)
To: Luiz Augusto von Dentz; +Cc: linux-bluetooth
In-Reply-To: <1295344815-1404-3-git-send-email-luiz.dentz@gmail.com>
Hi Luiz,
On Tue, Jan 18, 2011, Luiz Augusto von Dentz wrote:
> From: Luiz Augusto von Dentz <luiz.dentz-von@nokia.com>
>
> This should indicate to the endpoint what routing the transport is using
> ---
> audio/transport.c | 4 ++++
> doc/media-api.txt | 6 ++++++
> 2 files changed, 10 insertions(+), 0 deletions(-)
Pushed upstream, though this brings up the question of who should know
the routing setting. There's no standard HCI command for it which makes
it effectively a platform specific feature which either needs to be
statically "known" in some config file or discovered though some
platform specific plugin. Since we've already got platform specific code
on the PulseAudio side (it needs to know where to write the data in the
PCM case) the knowledge might as well be there and that would make the
property unnecessary. Thoughts?
Johan
^ permalink raw reply
* Re: [PATCH 2/4] Updade a2dpsink to use new Acquire API
From: Johan Hedberg @ 2011-01-19 15:16 UTC (permalink / raw)
To: Luiz Augusto von Dentz; +Cc: linux-bluetooth
In-Reply-To: <1295344815-1404-2-git-send-email-luiz.dentz@gmail.com>
Hi Luiz,
On Tue, Jan 18, 2011, Luiz Augusto von Dentz wrote:
> ---
> audio/gstavdtpsink.c | 19 +++++++------------
> 1 files changed, 7 insertions(+), 12 deletions(-)
This one doesn't apply -- probably because of the glib deprecated symbol
patches which I merged first (I had to process them first since
otherwise I can't do any compilation checks on the tree). So please fix
and resend.
Johan
^ permalink raw reply
* Re: [PATCH 1/4] Remove IMTU and OMTU properties and return its values on Acquire reply
From: Johan Hedberg @ 2011-01-19 15:14 UTC (permalink / raw)
To: Luiz Augusto von Dentz; +Cc: linux-bluetooth
In-Reply-To: <1295344815-1404-1-git-send-email-luiz.dentz@gmail.com>
Hi Luiz,
On Tue, Jan 18, 2011, Luiz Augusto von Dentz wrote:
> This should make Acquire blocking friendly since the client no longer has
> to call GetProperties to discover how much it can write/read when using
> the acquired file descriptor.
> ---
> audio/transport.c | 56 +++++++++++++++++++++++++++++++---------------------
> doc/media-api.txt | 13 ++---------
> 2 files changed, 36 insertions(+), 33 deletions(-)
Pushed upstream. Thanks.
Johan
^ permalink raw reply
* Re: [PATCH 1/2] Rename gatt_primary_t to more generic name
From: Johan Hedberg @ 2011-01-19 15:11 UTC (permalink / raw)
To: Bruna Moreira; +Cc: linux-bluetooth
In-Reply-To: <1295293069-29637-1-git-send-email-bruna.moreira@openbossa.org>
Hi Bruna,
On Mon, Jan 17, 2011, Bruna Moreira wrote:
> The gatt_primary_t typedef was renamed to gatt_cb_t because it will be
> used for primary and characteristic callbacks.
> ---
> attrib/gatt.c | 4 ++--
> attrib/gatt.h | 4 ++--
> 2 files changed, 4 insertions(+), 4 deletions(-)
Both patches have been pushed upstream. Thanks.
Johan
^ permalink raw reply
* Re: [PATCH v0 0/2] gdbus introspection fixes
From: Johan Hedberg @ 2011-01-19 15:10 UTC (permalink / raw)
To: Daniel Wagner; +Cc: linux-bluetooth, Daniel Wagner
In-Reply-To: <1295018061-5849-1-git-send-email-wagi@monom.org>
Hi Daniel,
On Fri, Jan 14, 2011, Daniel Wagner wrote:
> During some connman debug session I found some small hickups in the
> introspection code in gdbus. Marcel ask me to check with you first.
>
> cheers,
> daniel
>
> Daniel Wagner (2):
> gdbus: invaldate_parent_data: walk the whole path down
> gdbus: Remove root node 'name' attribute in introspection
>
> gdbus/object.c | 9 +++++----
> 1 files changed, 5 insertions(+), 4 deletions(-)
Both patches have been pushed upstream. Thanks.
Johan
^ permalink raw reply
* Re: Pull request git://gitorious.org/~vudentz/bluez/vudentzs-clone.git for-upstream
From: Johan Hedberg @ 2011-01-19 15:06 UTC (permalink / raw)
To: Luiz Augusto von Dentz; +Cc: linux-bluetooth
In-Reply-To: <AANLkTikmELbxWrZkTe_9UcK0q01cwJoQsmFkMzppsEtV@mail.gmail.com>
Hi Luiz,
On Wed, Jan 19, 2011, Luiz Augusto von Dentz wrote:
> The following changes since commit effe770cd43cf53fa5842291941dbfc82beab645:
>
> Use -DG_DISABLE_DEPRECATED compiler define (2011-01-18 14:56:31 +0100)
>
> are available in the git repository at:
> git://gitorious.org/~vudentz/bluez/vudentzs-clone.git for-upstream
>
> Luiz Augusto von Dentz (7):
> Fix use of deprecated glib on audio plugin
> Fix use of deprecated glib on input plugin
> Fix use of deprecated glib on network plugin
> Fix use of deprecated glib on serial plugin
> Fix use of deprecated glib on hciops plugin
> Fix use of deprecated glib on core
> Fix use of deprecated glib on tests
>
> audio/avdtp.c | 10 ++-
> audio/gstavdtpsink.c | 162 +++++++++++++++++++++++++-------------------------
> audio/headset.c | 13 +++--
> audio/unix.c | 2 +-
> input/device.c | 12 +++-
> input/fakehid.c | 10 ++-
> network/connection.c | 14 ++--
> plugins/hciops.c | 24 ++++---
> serial/proxy.c | 40 ++++++------
> src/rfkill.c | 11 ++--
> src/storage.c | 2 +-
> test/hciemu.c | 15 +++--
> 12 files changed, 168 insertions(+), 147 deletions(-)
All patches have been pushed upstream. Thanks.
Johan
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox