* [PATCH] Bluetooth: Fix issue with RFCOMM getsockopt operation
From: Marcel Holtmann @ 2013-11-02 9:36 UTC (permalink / raw)
To: linux-bluetooth
The commit 94a86df01082557e2de45865e538d7fb6c46231c seem to have
uncovered a long standing bug that did not trigger so far.
BUG: unable to handle kernel paging request at 00000009dd503502
IP: [<ffffffff815b1868>] rfcomm_sock_getsockopt+0x128/0x200
PGD 0
Oops: 0000 [#1] SMP
Modules linked in: ath5k ath mac80211 cfg80211
CPU: 2 PID: 1459 Comm: bluetoothd Not tainted 3.11.0-133163-gcebd830 #2
Hardware name: System manufacturer System Product Name/P6T DELUXE V2, BIOS
1202 12/22/2010
task: ffff8803304106a0 ti: ffff88033046a000 task.ti: ffff88033046a000
RIP: 0010:[<ffffffff815b1868>] [<ffffffff815b1868>]
rfcomm_sock_getsockopt+0x128/0x200
RSP: 0018:ffff88033046bed8 EFLAGS: 00010246
RAX: 00000009dd503502 RBX: 0000000000000003 RCX: 00007fffa2ed5548
RDX: 0000000000000003 RSI: 0000000000000012 RDI: ffff88032fd37480
RBP: ffff88033046bf28 R08: 00007fffa2ed554c R09: ffff88032f5707d8
R10: 00007fffa2ed5548 R11: 0000000000000202 R12: ffff880330bbd000
R13: 00007fffa2ed5548 R14: 0000000000000003 R15: 00007fffa2ed554c
FS: 00007fc44cfac700(0000) GS:ffff88033fc80000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00000009dd503502 CR3: 00000003304c2000 CR4: 00000000000007e0
Stack:
ffff88033046bf28 ffffffff815b0f2f ffff88033046bf18 0002ffff81105ef6
0000000600000000 ffff88032fd37480 0000000000000012 00007fffa2ed5548
0000000000000003 00007fffa2ed554c ffff88033046bf78 ffffffff814c0380
Call Trace:
[<ffffffff815b0f2f>] ? rfcomm_sock_setsockopt+0x5f/0x190
[<ffffffff814c0380>] SyS_getsockopt+0x60/0xb0
[<ffffffff815e0852>] system_call_fastpath+0x16/0x1b
Code: 02 00 00 00 0f 47 d0 4c 89 ef e8 74 13 cd ff 83 f8 01 19 c9 f7 d1 83 e1
f2 e9 4b ff ff ff 0f 1f 44 00 00 49 8b 84 24 70 02 00 00 <4c> 8b 30 4c 89 c0 e8
2d 19 cd ff 85 c0 49 89 d7 b9 f2 ff ff ff
RIP [<ffffffff815b1868>] rfcomm_sock_getsockopt+0x128/0x200
RSP <ffff88033046bed8>
CR2: 00000009dd503502
It triggers in the following segment of the code:
0x1313 is in rfcomm_sock_getsockopt (net/bluetooth/rfcomm/sock.c:743).
738
739 static int rfcomm_sock_getsockopt_old(struct socket *sock, int optname, char __user *optval, int __user *optlen)
740 {
741 struct sock *sk = sock->sk;
742 struct rfcomm_conninfo cinfo;
743 struct l2cap_conn *conn = l2cap_pi(sk)->chan->conn;
744 int len, err = 0;
745 u32 opt;
746
747 BT_DBG("sk %p", sk);
The l2cap_pi(sk) is wrong here since it should have been rfcomm_pi(sk),
but that socket of course does not contain the low-level connection
details requested here.
Tracking down the actual offending commit, it seems that this has been
introduced when doing some L2CAP refactoring:
commit 8c1d787be4b62d2d1b6f04953eca4bcf7c839d44
Author: Gustavo F. Padovan <padovan@profusion.mobi>
Date: Wed Apr 13 20:23:55 2011 -0300
@@ -743,6 +743,7 @@ static int rfcomm_sock_getsockopt_old(struct socket *sock, int optname, char __u
struct sock *sk = sock->sk;
struct sock *l2cap_sk;
struct rfcomm_conninfo cinfo;
+ struct l2cap_conn *conn = l2cap_pi(sk)->chan->conn;
int len, err = 0;
u32 opt;
@@ -787,8 +788,8 @@ static int rfcomm_sock_getsockopt_old(struct socket *sock, int optname, char __u
l2cap_sk = rfcomm_pi(sk)->dlc->session->sock->sk;
- cinfo.hci_handle = l2cap_pi(l2cap_sk)->conn->hcon->handle;
- memcpy(cinfo.dev_class, l2cap_pi(l2cap_sk)->conn->hcon->dev_class, 3);
+ cinfo.hci_handle = conn->hcon->handle;
+ memcpy(cinfo.dev_class, conn->hcon->dev_class, 3);
The l2cap_sk got accidentally mixed into the sk (which is RFCOMM) and
now causing a problem within getsocketopt() system call. To fix this,
just re-introduce l2cap_sk and make sure the right socket is used for
the low-level connection details.
Reported-by: Fabio Rossi <rossi.f@inwind.it>
Reported-by: Janusz Dziedzic <janusz.dziedzic@gmail.com>
Tested-by: Janusz Dziedzic <janusz.dziedzic@gmail.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
---
net/bluetooth/rfcomm/sock.c | 6 +++++-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/net/bluetooth/rfcomm/sock.c b/net/bluetooth/rfcomm/sock.c
index c4d3d423f89b..0be7619c5e5e 100644
--- a/net/bluetooth/rfcomm/sock.c
+++ b/net/bluetooth/rfcomm/sock.c
@@ -739,8 +739,9 @@ static int rfcomm_sock_setsockopt(struct socket *sock, int level, int optname, c
static int rfcomm_sock_getsockopt_old(struct socket *sock, int optname, char __user *optval, int __user *optlen)
{
struct sock *sk = sock->sk;
+ struct sock *l2cap_sk;
+ struct l2cap_conn *conn;
struct rfcomm_conninfo cinfo;
- struct l2cap_conn *conn = l2cap_pi(sk)->chan->conn;
int len, err = 0;
u32 opt;
@@ -783,6 +784,9 @@ static int rfcomm_sock_getsockopt_old(struct socket *sock, int optname, char __u
break;
}
+ l2cap_sk = rfcomm_pi(sk)->dlc->session->sock->sk;
+ conn = l2cap_pi(l2cap_sk)->chan->conn;
+
memset(&cinfo, 0, sizeof(cinfo));
cinfo.hci_handle = conn->hcon->handle;
memcpy(cinfo.dev_class, conn->hcon->dev_class, 3);
--
1.8.3.1
^ permalink raw reply related
* Re: [PATCH] Bluetooth: Fix issue with RFCOMM getsockopt operation
From: Johan Hedberg @ 2013-11-02 10:30 UTC (permalink / raw)
To: Marcel Holtmann; +Cc: linux-bluetooth
In-Reply-To: <1383384991-63025-1-git-send-email-marcel@holtmann.org>
Hi Marcel,
On Sat, Nov 02, 2013, Marcel Holtmann wrote:
> The commit 94a86df01082557e2de45865e538d7fb6c46231c seem to have
> uncovered a long standing bug that did not trigger so far.
>
> BUG: unable to handle kernel paging request at 00000009dd503502
> IP: [<ffffffff815b1868>] rfcomm_sock_getsockopt+0x128/0x200
> PGD 0
> Oops: 0000 [#1] SMP
> Modules linked in: ath5k ath mac80211 cfg80211
> CPU: 2 PID: 1459 Comm: bluetoothd Not tainted 3.11.0-133163-gcebd830 #2
> Hardware name: System manufacturer System Product Name/P6T DELUXE V2, BIOS
> 1202 12/22/2010
> task: ffff8803304106a0 ti: ffff88033046a000 task.ti: ffff88033046a000
> RIP: 0010:[<ffffffff815b1868>] [<ffffffff815b1868>]
> rfcomm_sock_getsockopt+0x128/0x200
> RSP: 0018:ffff88033046bed8 EFLAGS: 00010246
> RAX: 00000009dd503502 RBX: 0000000000000003 RCX: 00007fffa2ed5548
> RDX: 0000000000000003 RSI: 0000000000000012 RDI: ffff88032fd37480
> RBP: ffff88033046bf28 R08: 00007fffa2ed554c R09: ffff88032f5707d8
> R10: 00007fffa2ed5548 R11: 0000000000000202 R12: ffff880330bbd000
> R13: 00007fffa2ed5548 R14: 0000000000000003 R15: 00007fffa2ed554c
> FS: 00007fc44cfac700(0000) GS:ffff88033fc80000(0000) knlGS:0000000000000000
> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> CR2: 00000009dd503502 CR3: 00000003304c2000 CR4: 00000000000007e0
> Stack:
> ffff88033046bf28 ffffffff815b0f2f ffff88033046bf18 0002ffff81105ef6
> 0000000600000000 ffff88032fd37480 0000000000000012 00007fffa2ed5548
> 0000000000000003 00007fffa2ed554c ffff88033046bf78 ffffffff814c0380
> Call Trace:
> [<ffffffff815b0f2f>] ? rfcomm_sock_setsockopt+0x5f/0x190
> [<ffffffff814c0380>] SyS_getsockopt+0x60/0xb0
> [<ffffffff815e0852>] system_call_fastpath+0x16/0x1b
> Code: 02 00 00 00 0f 47 d0 4c 89 ef e8 74 13 cd ff 83 f8 01 19 c9 f7 d1 83 e1
> f2 e9 4b ff ff ff 0f 1f 44 00 00 49 8b 84 24 70 02 00 00 <4c> 8b 30 4c 89 c0 e8
> 2d 19 cd ff 85 c0 49 89 d7 b9 f2 ff ff ff
> RIP [<ffffffff815b1868>] rfcomm_sock_getsockopt+0x128/0x200
> RSP <ffff88033046bed8>
> CR2: 00000009dd503502
>
> It triggers in the following segment of the code:
>
> 0x1313 is in rfcomm_sock_getsockopt (net/bluetooth/rfcomm/sock.c:743).
> 738
> 739 static int rfcomm_sock_getsockopt_old(struct socket *sock, int optname, char __user *optval, int __user *optlen)
> 740 {
> 741 struct sock *sk = sock->sk;
> 742 struct rfcomm_conninfo cinfo;
> 743 struct l2cap_conn *conn = l2cap_pi(sk)->chan->conn;
> 744 int len, err = 0;
> 745 u32 opt;
> 746
> 747 BT_DBG("sk %p", sk);
>
> The l2cap_pi(sk) is wrong here since it should have been rfcomm_pi(sk),
> but that socket of course does not contain the low-level connection
> details requested here.
>
> Tracking down the actual offending commit, it seems that this has been
> introduced when doing some L2CAP refactoring:
>
> commit 8c1d787be4b62d2d1b6f04953eca4bcf7c839d44
> Author: Gustavo F. Padovan <padovan@profusion.mobi>
> Date: Wed Apr 13 20:23:55 2011 -0300
>
> @@ -743,6 +743,7 @@ static int rfcomm_sock_getsockopt_old(struct socket *sock, int optname, char __u
> struct sock *sk = sock->sk;
> struct sock *l2cap_sk;
> struct rfcomm_conninfo cinfo;
> + struct l2cap_conn *conn = l2cap_pi(sk)->chan->conn;
> int len, err = 0;
> u32 opt;
>
> @@ -787,8 +788,8 @@ static int rfcomm_sock_getsockopt_old(struct socket *sock, int optname, char __u
>
> l2cap_sk = rfcomm_pi(sk)->dlc->session->sock->sk;
>
> - cinfo.hci_handle = l2cap_pi(l2cap_sk)->conn->hcon->handle;
> - memcpy(cinfo.dev_class, l2cap_pi(l2cap_sk)->conn->hcon->dev_class, 3);
> + cinfo.hci_handle = conn->hcon->handle;
> + memcpy(cinfo.dev_class, conn->hcon->dev_class, 3);
>
> The l2cap_sk got accidentally mixed into the sk (which is RFCOMM) and
> now causing a problem within getsocketopt() system call. To fix this,
> just re-introduce l2cap_sk and make sure the right socket is used for
> the low-level connection details.
>
> Reported-by: Fabio Rossi <rossi.f@inwind.it>
> Reported-by: Janusz Dziedzic <janusz.dziedzic@gmail.com>
> Tested-by: Janusz Dziedzic <janusz.dziedzic@gmail.com>
> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
> ---
> net/bluetooth/rfcomm/sock.c | 6 +++++-
> 1 file changed, 5 insertions(+), 1 deletion(-)
Applied to bluetooth-next. Thanks.
Johan
^ permalink raw reply
* Re: BUG in rfcomm_sock_getsockopt+0x128/0x200
From: Fabio Rossi @ 2013-11-02 12:06 UTC (permalink / raw)
To: marcel
Cc: linux-wireless@vger.kernel.org Wireless,
linux-bluetooth@vger.kernel.org development
Hi Marcel,
>I finally managed to reproduce it. It does not always happen. And strangely
enough I can only trigger it when enabling experimental features of bluetoothd
with -E command line switch.
>
>But I have no idea why your bisecting points to that specific commit. And
more important it used to work just fine (see below). However I can tell you
what makes the code crash.
>
>0x1313 is in rfcomm_sock_getsockopt (net/bluetooth/rfcomm/sock.c:743).
>738
>739 static int rfcomm_sock_getsockopt_old(struct socket *sock, int optname,
char __user *optval, int __user *optlen)
>740 {
>741 struct sock *sk = sock->sk;
>742 struct rfcomm_conninfo cinfo;
>743 struct l2cap_conn *conn = l2cap_pi(sk)->chan->conn;
>744 int len, err = 0;
>745 u32 opt;
>746
>747 BT_DBG("sk %p", sk);
>
>The l2cap_pi(sk) is fully broken. That is an rfcomm_pi(sk). The commit that
broke this is actually from an earlier time. I have this one:
>
>commit 8c1d787be4b62d2d1b6f04953eca4bcf7c839d44
>Author: Gustavo F. Padovan <padovan@profusion.mobi>
>Date: Wed Apr 13 20:23:55 2011 -0300
>
> Bluetooth: Move conn to struct l2cap_chan
>
>diff --git a/net/bluetooth/rfcomm/sock.c b/net/bluetooth/rfcomm/sock.c
>index 66cc1f0c3df8..386cfaffd4b7 100644
>--- a/net/bluetooth/rfcomm/sock.c
>+++ b/net/bluetooth/rfcomm/sock.c
>@@ -743,6 +743,7 @@ static int rfcomm_sock_getsockopt_old(struct socket
*sock, int optname, char __u
> struct sock *sk = sock->sk;
> struct sock *l2cap_sk;
> struct rfcomm_conninfo cinfo;
>+ struct l2cap_conn *conn = l2cap_pi(sk)->chan->conn;
> int len, err = 0;
> u32 opt;
>
>@@ -787,8 +788,8 @@ static int rfcomm_sock_getsockopt_old(struct socket
*sock, int optname, char __u
>
> l2cap_sk = rfcomm_pi(sk)->dlc->session->sock->sk;
>
>- cinfo.hci_handle = l2cap_pi(l2cap_sk)->conn->hcon->handle;
>- memcpy(cinfo.dev_class, l2cap_pi(l2cap_sk)->conn->hcon-
>dev_class, 3);
>+ cinfo.hci_handle = conn->hcon->handle;
>+ memcpy(cinfo.dev_class, conn->hcon->dev_class, 3);
>
>The conversion is clearly wrong since we used to have a l2cap_sk that was
pointing to the right socket.
>
>This should have blown up month ago and not just with the latest changes we
have done to the L2CAP layer. Anyhow, you can try this small change and see if
it fixes things for you.
>
>diff --git a/net/bluetooth/rfcomm/sock.c b/net/bluetooth/rfcomm/sock.c
>index c4d3d423f89b..0be7619c5e5e 100644
>--- a/net/bluetooth/rfcomm/sock.c
>+++ b/net/bluetooth/rfcomm/sock.c
>@@ -739,8 +739,9 @@ static int rfcomm_sock_setsockopt(struct socket *sock,
int level, int optname, c
> static int rfcomm_sock_getsockopt_old(struct socket *sock, int optname, char
__user *optval, int __user *optlen)
> {
> struct sock *sk = sock->sk;
>+ struct sock *l2cap_sk;
>+ struct l2cap_conn *conn;
> struct rfcomm_conninfo cinfo;
>- struct l2cap_conn *conn = l2cap_pi(sk)->chan->conn;
> int len, err = 0;
> u32 opt;
>
>@@ -783,6 +784,9 @@ static int rfcomm_sock_getsockopt_old(struct socket
*sock, int optname, char __u
> break;
> }
>
>+ l2cap_sk = rfcomm_pi(sk)->dlc->session->sock->sk;
>+ conn = l2cap_pi(l2cap_sk)->chan->conn;
>+
> memset(&cinfo, 0, sizeof(cinfo));
> cinfo.hci_handle = conn->hcon->handle;
> memcpy(cinfo.dev_class, conn->hcon->dev_class, 3);
>
>Regards
This patch solves the issue, I don't see the crash anymore.
Thanks,
Fabio
^ permalink raw reply
* Re: [RFC 4/5] Bluetooth: Remove unneeded check in hci_disconn_complete_evt()
From: Marcel Holtmann @ 2013-11-02 18:14 UTC (permalink / raw)
To: Andre Guedes; +Cc: linux-bluetooth@vger.kernel.org development
In-Reply-To: <1383170504-16602-5-git-send-email-andre.guedes@openbossa.org>
Hi Andre,
> According to b644ba336 (patch that introduced HCI_CONN_MGMT_CONNECTED
> flag), the HCI_CONN_MGMT_CONNECTED flag tracks when mgmt has been
> notified about the connection.
>
> That being said, there is no point in checking this flag in hci_
> disconn_complete_evt() since neither mgmt_disconnect_failed() nor
> mgmt_device_disconnected() depend on it. Below follows more details:
> * mgmt_disconnect_failed() removes pending MGMT_OP_DISCONNECT
> commands, it doesn't matter if that connection was notified or not.
> * mgmt_device_disconnected() sends the mgmt event only if the link
> type is ACL_LINK or LE_LINK. For those connection type, the flag is
> always set.
>
> So this patch removes the HCI_CONN_MGMT_CONNECTED check.
>
> Signed-off-by: Andre Guedes <andre.guedes@openbossa.org>
> ---
> net/bluetooth/hci_event.c | 16 +++++++---------
> 1 file changed, 7 insertions(+), 9 deletions(-)
>
> diff --git a/net/bluetooth/hci_event.c b/net/bluetooth/hci_event.c
> index 4673cfb..9225a9c 100644
> --- a/net/bluetooth/hci_event.c
> +++ b/net/bluetooth/hci_event.c
> @@ -1795,16 +1795,14 @@ static void hci_disconn_complete_evt(struct hci_dev *hdev, struct sk_buff *skb)
> if (ev->status == 0)
> conn->state = BT_CLOSED;
>
> - if (test_and_clear_bit(HCI_CONN_MGMT_CONNECTED, &conn->flags)) {
> - if (ev->status) {
> - mgmt_disconnect_failed(hdev, &conn->dst, conn->type,
> - conn->dst_type, ev->status);
> - } else {
> - u8 reason = hci_to_mgmt_reason(ev->reason);
> + if (ev->status) {
> + mgmt_disconnect_failed(hdev, &conn->dst, conn->type,
> + conn->dst_type, ev->status);
something went wrong with the coding style here.
> + } else {
> + u8 reason = hci_to_mgmt_reason(ev->reason);
>
> - mgmt_device_disconnected(hdev, &conn->dst, conn->type,
> - conn->dst_type, reason);
> - }
> + mgmt_device_disconnected(hdev, &conn->dst, conn->type,
> + conn->dst_type, reason);
And here.
> }
>
> if (ev->status == 0) {
Regards
Marcel
^ permalink raw reply
* Re: [RFC 0/5] Disconnect complete refactoring
From: Marcel Holtmann @ 2013-11-02 18:17 UTC (permalink / raw)
To: Andre Guedes; +Cc: linux-bluetooth@vger.kernel.org development
In-Reply-To: <1383170504-16602-1-git-send-email-andre.guedes@openbossa.org>
Hi Andre,
> This patch set does some code refactoring in disconnect complete event handler
> and related functions from Mgmt layer.
>
> This refactoring used to be one patch from LE auto connection patch set, but
> since Marcel asked me to do more changes, I put all these refactoring patches
> in its own patch set.
>
> Regards,
>
> Andre Guedes (5):
> Bluetooth: Check address in mgmt_disconnect_failed()
> Bluetooth: Add an extra check in mgmt_device_disconnected()
> Bluetooth: Remove link type check in hci_disconn_complete_evt()
> Bluetooth: Remove unneeded check in hci_disconn_complete_evt()
> Bluetooth: Refactor hci_disconn_complete_evt
>
> net/bluetooth/hci_event.c | 61 ++++++++++++++++++++++-------------------------
> net/bluetooth/mgmt.c | 15 +++++++++++-
> 2 files changed, 43 insertions(+), 33 deletions(-)
I applied the first 3 patches of this series to bluetooth-next tree. You need to fix up patch 4 and resend the rest.
Regards
Marcel
^ permalink raw reply
* Re: Intel 7260 bluetooth malfunction when it is connected to EHCI bus
From: Marcel Holtmann @ 2013-11-02 19:05 UTC (permalink / raw)
To: Hui Wang
Cc: Tedd An, Johan Hedberg, xiong.y.zhang, Gustavo F. Padovan,
linux-bluetooth@vger.kernel.org development, Kun Yang,
Anthony Wong
In-Reply-To: <527371D4.1010305@canonical.com>
Hi Hui,
>>>>>>>>> The problem is:
>>>>>>>>> On the machine which has Intel 7260 BT module, i use it to connect a bluetooth headset,
>>>>>>>>> it can successfully scan and connect to the headset, when i play sound to the bt headset,
>>>>>>>>> the problem comes, if the bt module is connected to the XHCI, it can work very well.
>>>>>>>>>
>>>>>>>>> u@u-Lenovo-B4400:~$ lsusb -t
>>>>>>>>> 1-7:1.0: No such file or directory
>>>>>>>>> /: Bus 02.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/4p, 5000M
>>>>>>>>> /: Bus 01.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/14p, 480M
>>>>>>>>> |__ Port 6: Dev 8, If 0, Class=HID, Driver=usbhid, 1.5M
>>>>>>>>> |__ Port 7: Dev 2, If 0, Class=vend., Driver=, 12M
>>>>>>>>> |__ Port 11: Dev 3, If 0, Class='bInterfaceClass 0xe0 not yet handled', Driver=btusb, 12M
>>>>>>>>> |__ Port 11: Dev 3, If 1, Class='bInterfaceClass 0xe0 not yet handled', Driver=btusb, 12M
>>>>>>>>>
>>>>>>>>> But if the bt module is connected to the EHCI, it always fails to play sound.
>>>>>>>>>
>>>>>>>>> u@u-Lenovo-B4400:~$ lsusb -t
>>>>>>>>> /: Bus 04.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/4p, 5000M
>>>>>>>>> /: Bus 03.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/14p, 480M
>>>>>>>>> /: Bus 02.Port 1: Dev 1, Class=root_hub, Driver=ehci_hcd/3p, 480M
>>>>>>>>> |__ Port 1: Dev 2, If 0, Class=hub, Driver=hub/8p, 480M
>>>>>>>>> /: Bus 01.Port 1: Dev 1, Class=root_hub, Driver=ehci_hcd/3p, 480M
>>>>>>>>> |__ Port 1: Dev 2, If 0, Class=hub, Driver=hub/6p, 480M
>>>>>>>>> |__ Port 5: Dev 3, If 0, Class='bInterfaceClass 0xe0 not yet handled', Driver=btusb, 12M
>>>>>>>>> |__ Port 5: Dev 3, If 1, Class='bInterfaceClass 0xe0 not yet handled', Driver=btusb, 12M
>>>>>>>>> |__ Port 6: Dev 4, If 0, Class='bInterfaceClass 0x0e not yet handled', Driver=uvcvideo, 480M
>>>>>>>>> |__ Port 6: Dev 4, If 1, Class='bInterfaceClass 0x0e not yet handled', Driver=uvcvideo, 480M
>>>>>>>> can you paste /sys/kernel/debug/usb/devices here.
>>>>>>>>
>>>>>>>> If the uvcvideo driver is also using ISOC URBs, we might have just exhausted the bandwidth of the USB bus here or these two devices just do not play nice with each other.
>>>>>>>>
>>>>>>>> Try to unload the uvcvideo driver and try it again.
>>>>>>> Thanks for your reply, follow your instruction, i totally disabled the camera from the BIOS, then the usb tree like this,
>>>>>>> u@u-Lenovo-B4400:~$ lsusb -t
>>>>>>> 1-1.3:1.0: No such file or directory
>>>>>>> /: Bus 04.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/4p, 5000M
>>>>>>> /: Bus 03.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/14p, 480M
>>>>>>> /: Bus 02.Port 1: Dev 1, Class=root_hub, Driver=ehci-pci/3p, 480M
>>>>>>> |__ Port 1: Dev 2, If 0, Class=hub, Driver=hub/8p, 480M
>>>>>>> /: Bus 01.Port 1: Dev 1, Class=root_hub, Driver=ehci-pci/3p, 480M
>>>>>>> |__ Port 1: Dev 2, If 0, Class=hub, Driver=hub/6p, 480M
>>>>>>> |__ Port 2: Dev 3, If 0, Class=HID, Driver=usbhid, 1.5M
>>>>>>> |__ Port 3: Dev 4, If 0, Class=vend., Driver=, 12M
>>>>>>> |__ Port 5: Dev 5, If 0, Class='bInterfaceClass 0xe0 not yet handled', Driver=btusb, 12M
>>>>>>> |__ Port 5: Dev 5, If 1, Class='bInterfaceClass 0xe0 not yet handled', Driver=btusb, 12M
>>>>>>> u@u-Lenovo-B4400:~$ uname -a
>>>>>>> Linux u-Lenovo-B4400 3.12.0-031200rc6-generic #201310191635 SMP Sat Oct 19 20:36:43 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux
>>>>>>>
>>>>>>> I re-did the test, the result is same as before, after the headset is connected and i play audio, no sound is heard from the headset.
>>>>>>> And hciconfig output shows still no SCO packets received by BT driver.
>>>>>>> u@u-Lenovo-B4400:~$ hciconfig
>>>>>>> hci0: Type: BR/EDR Bus: USB
>>>>>>> BD Address: 00:15:00:CC:2D:D2 ACL MTU: 1021:5 SCO MTU: 96:5
>>>>>>> UP RUNNING PSCAN
>>>>>>> RX bytes:5853 acl:61 sco:0 events:298 errors:0
>>>>>>> TX bytes:19212 acl:68 sco:1 commands:179 errors:0
>>>>>> this is strange. The only reason I can think of is that you do not have the firmware installed and or it is not loaded correctly. Does dmesg give any indication that something failed here.
>>>>> I can confirm the firmware file is the /lib/firmware/intel/ibt-hw-37.7.10-fw-1.80.2.3.d.bseq, and it is in the filesystem. And from the dmesg, the firmware was successfully loaded.
>>>>>
>>>>> [ 8.600217] Bluetooth: hci0: Intel Bluetooth firmware file: intel/ibt-hw-37.7.10-fw-1.80.2.3.d.bseq
>>>>> [ 8.653635] kvm: disabled by bios
>>>>> [ 8.672981] psmouse serio1: synaptics: Touchpad model: 1, fw: 8.1, id: 0x1e2b1, caps: 0xd00123/0x840300/0x126c00
>>>>> [ 8.707034] input: SynPS/2 Synaptics TouchPad as /devices/platform/i8042/serio1/input/input13
>>>>> [ 8.717725] Registered led device: phy0-led
>>>>> [ 8.722730] ieee80211 phy0: Selected rate control algorithm 'iwl-mvm-rs'
>>>>> [ 8.752626] Bluetooth: hci0: Intel Bluetooth firmware patch completed and activated
>>>>>
>>>>>> Since this is a 3.12 kernel it should have native support for Intel specific setup routing. Any chance you can run btmon -w <file> before plugging the device into the bus. Maybe something goes wrong with the setup routine on EHCI.
>>>>> Do you mean the hcidump file i just sent in my previous email.
>>>> I do not get this. I specifically asked to run “btmon -w <file>” before plugging in the device. I want to see the early setup process here. What would I do with a hcidump trace.
>>> The attachment is the logfile generated by "btmon -w <file>". And the logfile was generated by below steps,
>>>
>>> 1) boot up the system into the ubuntu desktop
>>> 2) open a terminal and run "sudo btmon -w ~/lenovo-m4400s-btmon.log"
>>> 3) open bluetooth applet and click adding a new device, the bluetooth begin to scan devices
>>> 4) power up the bt headset
>>> 5) laptop bt module find the headset and connect it successfully
>>> 6) open the sound applet, choose bt headset as output device, play sound, but no sound can be heard from bt headset
>>> 7) Ctrl+C to terminate the "btmon -w <file>"
>>>
>>> In case you can't receive the attachment, i decode the logfile and paste the content here.
>> what I need is to see the 7260 controller init. So you need to start btmon -w <file> before the 7260 gets attached to the USB bus or before btusb.ko driver gets loaded.
> Understand now.
>
> The attachment lenovo-k4450-btmon-v0.log is the log of intel 7260 init procedure, generated by "btmon -w <file>; insmod btusb.ko; ctrl+c terminate the btmon".
>
> The attachment lenovo-k4450-btmon-v1.log is the log of intel 7260 init procedure + scan headset + connect headset + play sound.
I looked through the logs and the controller init is just fine. So in theory this should route the SCO audio frames over HCI. For some reason it does not and I have no idea why not.
That it makes a different between EHCI and XHCI is strange. I can not explain this. Maybe Tedd can help you since I have no further insights in our chips at this moment.
Regards
Marcel
^ permalink raw reply
* [PATCH] tools/hci2hid: properly format device path
From: Matthew Monaco @ 2013-11-04 1:46 UTC (permalink / raw)
To: linux-bluetooth
From: Matthew Monaco <matthew.monaco@0x01b.net>
---
Hello! I hope this is the correct place to send a bugfix for bluez.
tools/hid2hci.c | 15 +++++++++------
1 file changed, 9 insertions(+), 6 deletions(-)
diff --git a/tools/hid2hci.c b/tools/hid2hci.c
index bb8a521..8f22047 100644
--- a/tools/hid2hci.c
+++ b/tools/hid2hci.c
@@ -221,18 +221,21 @@ static int usb_switch_dell(int fd, enum mode mode)
static int find_device(struct udev_device *udev_dev)
{
char path[PATH_MAX];
- const char *busnum, *devnum;
+ const char *str;
+ long int busnum, devnum;
int fd;
- busnum = udev_device_get_sysattr_value(udev_dev, "busnum");
- if (!busnum)
+ str = udev_device_get_sysattr_value(udev_dev, "busnum");
+ if (!str)
return -1;
+ busnum = strtol(str, NULL, 0);
- devnum = udev_device_get_sysattr_value(udev_dev, "devnum");
- if (!devnum)
+ str = udev_device_get_sysattr_value(udev_dev, "devnum");
+ if (!str)
return -1;
+ devnum = strtol(str, NULL, 0);
- snprintf(path, sizeof(path), "/dev/bus/usb/%s/%s", busnum, devnum);
+ snprintf(path, sizeof(path), "/dev/bus/usb/%03d/%03d", busnum, devnum);
fd = open(path, O_RDWR, O_CLOEXEC);
if (fd < 0) {
--
1.8.4.2
^ permalink raw reply related
* Re: Intel 7260 bluetooth malfunction when it is connected to EHCI bus
From: Hui Wang @ 2013-11-04 5:59 UTC (permalink / raw)
To: Marcel Holtmann
Cc: Tedd An, Johan Hedberg, xiong.y.zhang, Gustavo F. Padovan,
linux-bluetooth@vger.kernel.org development, Kun Yang,
Anthony Wong
In-Reply-To: <9DFD9618-158E-41C4-8183-134A3FC4E61F@holtmann.org>
On 11/03/2013 03:05 AM, Marcel Holtmann wrote:
> Hi Hui,
>
<snip>
>>
>> The attachment lenovo-k4450-btmon-v1.log is the log of intel 7260 init procedure + scan headset + connect headset + play sound.
> I looked through the logs and the controller init is just fine. So in theory this should route the SCO audio frames over HCI. For some reason it does not and I have no idea why not.
>
> That it makes a different between EHCI and XHCI is strange. I can not explain this. Maybe Tedd can help you since I have no further insights in our chips at this moment.
Thanks Marcel for your kind help and analysis.
Tedd, did you reproduce this issue on the machines with intel 7260 BT
module connected to the EHCI bus? Did you have any idea on this issue?
Thanks,
Hui.
>
> Regards
>
> Marcel
>
>
^ permalink raw reply
* [PATCH] btusb: add realtek 8723 in the blacklist
From: Bruce.Ma @ 2013-11-04 7:20 UTC (permalink / raw)
To: linux-bluetooth
From: Bruce Ma <bruce.ma@canonical.com>
Date: Tue, 04 Nov 2013 11:21:20 +0800
Subject: [PATCH] btusb: add Realtek 8723 in the blacklist
The btusb doesn't work with Realtek 8723 bluetooth device,
so we want to add it to the blacklist.
Signed-off-by: Bruce Ma <bruce.ma@canonical.com>
---
drivers/bluetooth/btusb.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/bluetooth/btusb.c b/drivers/bluetooth/btusb.c
index eae58a1..3097ac8 100644
--- a/drivers/bluetooth/btusb.c
+++ b/drivers/bluetooth/btusb.c
@@ -138,6 +138,9 @@ static struct usb_device_id blacklist_table[] = {
{ USB_DEVICE(0x0489, 0xe03d), .driver_info = BTUSB_IGNORE },
{ USB_DEVICE(0x0489, 0xe027), .driver_info = BTUSB_IGNORE },
+ /* Realtek 8723 Bluetooth */
+ { USB_DEVICE(0x0bda, 0xb728), .driver_info = BTUSB_IGNORE },
+
/* Atheros AR9285 Malbec with sflash firmware */
{ USB_DEVICE(0x03f0, 0x311d), .driver_info = BTUSB_IGNORE },
-- 1.8.1.2
^ permalink raw reply related
* [PATCHv2 1/5] android: Fix typo in get_remote_services command
From: Marcin Kraglak @ 2013-11-04 7:30 UTC (permalink / raw)
To: linux-bluetooth; +Cc: Marcin Kraglak
diff --git a/android/hal-msg.h b/android/hal-msg.h
index 1587ff2..f381862 100644
--- a/android/hal-msg.h
+++ b/android/hal-msg.h
@@ -148,8 +148,8 @@ struct hal_cmd_get_remote_service_rec {
uint8_t uuid[16];
} __attribute__((packed));
-#define HAL_OP_GET_REMOTE_SERVICE 0x0a
-struct hal_cmd_get_remote_service {
+#define HAL_OP_GET_REMOTE_SERVICES 0x0a
+struct hal_cmd_get_remote_services {
uint8_t bdaddr[6];
} __attribute__((packed));
--
1.8.4.1
^ permalink raw reply related
* [PATCHv2 2/5] android/hal: Send get_remote_services cmd
From: Marcin Kraglak @ 2013-11-04 7:30 UTC (permalink / raw)
To: linux-bluetooth; +Cc: Marcin Kraglak
In-Reply-To: <1383550234-14790-1-git-send-email-marcin.kraglak@tieto.com>
diff --git a/android/hal-bluetooth.c b/android/hal-bluetooth.c
index 5fb8846..9022fc2 100644
--- a/android/hal-bluetooth.c
+++ b/android/hal-bluetooth.c
@@ -505,12 +505,18 @@ static int get_remote_service_record(bt_bdaddr_t *remote_addr, bt_uuid_t *uuid)
static int get_remote_services(bt_bdaddr_t *remote_addr)
{
+ struct hal_cmd_get_remote_services cmd;
+
DBG("");
if (!interface_ready())
return BT_STATUS_NOT_READY;
- return BT_STATUS_UNSUPPORTED;
+ memcpy(cmd.bdaddr, remote_addr, sizeof(cmd.bdaddr));
+
+ return hal_ipc_cmd(HAL_SERVICE_ID_BLUETOOTH,
+ HAL_OP_GET_REMOTE_SERVICES, sizeof(cmd),
+ &cmd, 0, NULL, NULL);
}
static int start_discovery(void)
--
1.8.4.1
^ permalink raw reply related
* [PATCHv2 3/5] android: Add stub of get_remote_services command
From: Marcin Kraglak @ 2013-11-04 7:30 UTC (permalink / raw)
To: linux-bluetooth; +Cc: Marcin Kraglak
In-Reply-To: <1383550234-14790-1-git-send-email-marcin.kraglak@tieto.com>
diff --git a/android/adapter.c b/android/adapter.c
index 0797aa0..8df59e6 100644
--- a/android/adapter.c
+++ b/android/adapter.c
@@ -1459,6 +1459,11 @@ static uint8_t ssp_reply(void *buf, uint16_t len)
return status;
}
+static uint8_t get_remote_services(void *buf, uint16_t len)
+{
+ return HAL_STATUS_UNSUPPORTED;
+}
+
void bt_adapter_handle_cmd(GIOChannel *io, uint8_t opcode, void *buf,
uint16_t len)
{
@@ -1563,6 +1568,11 @@ void bt_adapter_handle_cmd(GIOChannel *io, uint8_t opcode, void *buf,
goto error;
break;
+ case HAL_OP_GET_REMOTE_SERVICES:
+ status = get_remote_services(buf, len);
+ if (status != HAL_STATUS_SUCCESS)
+ goto error;
+ break;
default:
DBG("Unhandled command, opcode 0x%x", opcode);
goto error;
--
1.8.4.1
^ permalink raw reply related
* [PATCHv2 4/5] android: Initial implementation of get_remote_services
From: Marcin Kraglak @ 2013-11-04 7:30 UTC (permalink / raw)
To: linux-bluetooth; +Cc: Marcin Kraglak
In-Reply-To: <1383550234-14790-1-git-send-email-marcin.kraglak@tieto.com>
diff --git a/android/adapter.c b/android/adapter.c
index 8df59e6..689dd54 100644
--- a/android/adapter.c
+++ b/android/adapter.c
@@ -35,6 +35,10 @@
#include "src/shared/mgmt.h"
#include "src/glib-helper.h"
#include "src/eir.h"
+#include "lib/sdp.h"
+#include "lib/sdp_lib.h"
+#include "lib/uuid.h"
+#include "src/sdp-client.h"
#include "log.h"
#include "hal-msg.h"
#include "ipc.h"
@@ -45,6 +49,8 @@
#define DEFAULT_IO_CAPABILITY 0x01
static GIOChannel *notification_io = NULL;
+/* This list contains addresses which are asked for records */
+static GList *sdp_req_list;
struct bt_adapter {
uint16_t index;
@@ -63,6 +69,20 @@ struct bt_adapter {
bool discovering;
};
+struct browse_req {
+ bdaddr_t *bdaddr;
+ GSList *uuids;
+ int search_uuid;
+ int reconnect_attempt;
+};
+
+static const uint16_t uuid_list[] = {
+ L2CAP_UUID,
+ PNP_INFO_SVCLASS_ID,
+ PUBLIC_BROWSE_GROUP,
+ 0
+};
+
static struct bt_adapter *adapter;
static GSList *found_devices = NULL;
@@ -1459,9 +1479,80 @@ static uint8_t ssp_reply(void *buf, uint16_t len)
return status;
}
+static void browse_req_free(struct browse_req *req)
+{
+ g_free(req->bdaddr);
+ g_slist_free_full(req->uuids, g_free);
+ g_free(req);
+}
+
+static void update_records(struct browse_req *req, sdp_list_t *recs)
+{
+ /* TODO cache found uuids */
+}
+
+static void browse_cb(sdp_list_t *recs, int err, gpointer user_data)
+{
+ struct browse_req *req = user_data;
+ uuid_t uuid;
+
+ /* If we have a valid response and req->search_uuid == 2, then L2CAP
+ * UUID & PNP searching was successful -- we are done */
+ if (err < 0 || req->search_uuid == 2) {
+ if (err == -ECONNRESET && req->reconnect_attempt < 1) {
+ req->search_uuid--;
+ req->reconnect_attempt++;
+ } else {
+ goto done;
+ }
+ }
+
+ update_records(req, recs);
+
+ /* Search for mandatory uuids */
+ if (uuid_list[req->search_uuid]) {
+ sdp_uuid16_create(&uuid, uuid_list[req->search_uuid++]);
+ bt_search_service(&adapter->bdaddr, req->bdaddr, &uuid,
+ browse_cb, user_data, NULL);
+ return;
+ }
+
+done:
+ sdp_req_list = g_list_remove(sdp_req_list, req->bdaddr);
+ browse_req_free(req);
+}
+
static uint8_t get_remote_services(void *buf, uint16_t len)
{
- return HAL_STATUS_UNSUPPORTED;
+ struct hal_cmd_get_remote_services *cmd = buf;
+ struct browse_req *req;
+ bdaddr_t *addr;
+ uuid_t uuid;
+ int err;
+
+ addr = g_new0(bdaddr_t, 1);
+ android2bdaddr(&cmd->bdaddr, addr);
+
+ if (g_list_find_custom(sdp_req_list, addr, bdaddr_cmp)) {
+ g_free(addr);
+ return HAL_STATUS_DONE;
+ }
+
+ sdp_req_list = g_list_append(sdp_req_list, addr);
+
+ req = g_new0(struct browse_req, 1);
+ req->bdaddr = addr;
+ sdp_uuid16_create(&uuid, uuid_list[req->search_uuid++]);
+
+ err = bt_search_service(&adapter->bdaddr,
+ req->bdaddr, &uuid, browse_cb, req, NULL);
+ if (err) {
+ sdp_req_list = g_list_remove(sdp_req_list, req->bdaddr);
+ browse_req_free(req);
+ return HAL_STATUS_FAILED;
+ }
+
+ return HAL_STATUS_SUCCESS;
}
void bt_adapter_handle_cmd(GIOChannel *io, uint8_t opcode, void *buf,
--
1.8.4.1
^ permalink raw reply related
* [PATCHv2 5/5] android: Pass found uuids to remote_device_properties_cb
From: Marcin Kraglak @ 2013-11-04 7:30 UTC (permalink / raw)
To: linux-bluetooth; +Cc: Marcin Kraglak
In-Reply-To: <1383550234-14790-1-git-send-email-marcin.kraglak@tieto.com>
diff --git a/android/adapter.c b/android/adapter.c
index 689dd54..0b6fc43 100644
--- a/android/adapter.c
+++ b/android/adapter.c
@@ -1486,9 +1486,87 @@ static void browse_req_free(struct browse_req *req)
g_free(req);
}
+static void fill_uuids(GSList *list, void *buf)
+{
+ for (; list; list = (GSList *)g_list_next(list)) {
+ memcpy(buf, list->data, sizeof(uint128_t));
+ buf += sizeof(uint128_t);
+ }
+}
+
+static void remote_uuids_callback(struct browse_req *req)
+{
+ struct hal_ev_remote_device_props *ev;
+ int len;
+
+ len = sizeof(*ev) + sizeof(struct hal_property) + (sizeof(uint128_t) *
+ g_slist_length(req->uuids));
+ ev = g_malloc(len);
+
+ ev->status = HAL_STATUS_SUCCESS;
+ bdaddr2android(req->bdaddr, &ev->bdaddr);
+ ev->num_props = 1;
+ ev->props[0].type = HAL_PROP_DEVICE_UUIDS;
+ ev->props[0].len = sizeof(uint128_t) * g_slist_length(req->uuids);
+ fill_uuids(req->uuids, ev->props[0].val);
+
+ ipc_send(notification_io, HAL_SERVICE_ID_BLUETOOTH,
+ HAL_EV_REMOTE_DEVICE_PROPS, len, ev, -1);
+
+ g_free(ev);
+}
+
+static int uuid_128_cmp(gconstpointer a, gconstpointer b)
+{
+ return memcmp(a, b, sizeof(uint128_t));
+}
+
static void update_records(struct browse_req *req, sdp_list_t *recs)
{
- /* TODO cache found uuids */
+ for (; recs; recs = recs->next) {
+ sdp_record_t *rec = (sdp_record_t *) recs->data;
+ sdp_list_t *svcclass = NULL;
+ uuid_t uuid128;
+ uuid_t *temp;
+ uint8_t *u;
+
+ if (!rec)
+ break;
+
+ if (sdp_get_service_classes(rec, &svcclass) < 0)
+ continue;
+
+ if (svcclass == NULL)
+ continue;
+
+ temp = svcclass->data;
+
+ switch (temp->type) {
+ case SDP_UUID16:
+ sdp_uuid16_to_uuid128(&uuid128, temp);
+ break;
+ case SDP_UUID32:
+ sdp_uuid32_to_uuid128(&uuid128, temp);
+ break;
+ case SDP_UUID128:
+ memcpy(&uuid128, temp, sizeof(uuid_t));
+ break;
+ default:
+ continue;
+ }
+
+ u = g_malloc(16);/* size of 128 bit uuid */
+ memcpy(u, &uuid128.value.uuid128,
+ sizeof(uuid128.value.uuid128));
+
+ /* Check if uuid is already added */
+ if (g_slist_find_custom(req->uuids, u, uuid_128_cmp))
+ g_free(u);
+ else
+ req->uuids = g_slist_append(req->uuids, u);
+
+ sdp_list_free(svcclass, free);
+ }
}
static void browse_cb(sdp_list_t *recs, int err, gpointer user_data)
@@ -1518,6 +1596,7 @@ static void browse_cb(sdp_list_t *recs, int err, gpointer user_data)
}
done:
+ remote_uuids_callback(req);
sdp_req_list = g_list_remove(sdp_req_list, req->bdaddr);
browse_req_free(req);
}
--
1.8.4.1
^ permalink raw reply related
* Re: [PATCHv5 0/7] Improve logging for Android
From: Johan Hedberg @ 2013-11-04 7:34 UTC (permalink / raw)
To: Andrei Emeltchenko; +Cc: linux-bluetooth
In-Reply-To: <1383319159-13060-1-git-send-email-Andrei.Emeltchenko.news@gmail.com>
Hi Andrei,
On Fri, Nov 01, 2013, Andrei Emeltchenko wrote:
> Logging on Android is really important since we do not have specification
> how and in which order hal functions are called, sometimes the only way is
> to examine logs or read Java Bluetooth code.
>
> Changes:
> * v5: Rebased against latest upstream and merged some patches, added several logs.
> * v4: Rebased against latest upstream
> * v3: Merged first two patches.
> * v2: Added thread-safe helpers for printing properties, bdaddr, etc
> after comments that simple printing is not thread-safe. The idea is to
> use TLS (thread local storage) like bionic is doing for strerror for
> example. More info can be found on manpage for pthread_key_create.
>
> This patch series uses debug functions defined already for haltest and
> allows to print very helpful logs on Android target like shown below:
>
> ...
> hal-bluetooth.c:set_adapter_property() prop: type=BT_PROPERTY_ADAPTER_SCAN_MODE len=4 val=BT_SCAN_MODE_NONE
> ...
>
> Andrei Emeltchenko (7):
> android/haltest: Export print property
> android/haltest: Use pointer as parameter for debug
> android/haltest: Fix print device name
> android/hal: Add extra logs to HAL
> android: Add thread-safe helpers
> android: Use thread-safe helpers
> android/daemon: Add logs to trace failed cmd
>
> android/adapter.c | 2 +
> android/client/if-bt.c | 111 +------------------------------------------
> android/client/textconv.c | 114 +++++++++++++++++++++++++++++++++++++++++++++
> android/client/textconv.h | 3 ++
> android/hal-bluetooth.c | 34 +++++++++-----
> android/pthread-local.h | 58 +++++++++++++++++++++++
> 6 files changed, 200 insertions(+), 122 deletions(-)
> create mode 100644 android/pthread-local.h
Patches 1-4 and patch 7 (with a minor modification) have been applied.
Thanks.
Johan
^ permalink raw reply
* Re: [PATCH] btusb: add realtek 8723 in the blacklist
From: Johan Hedberg @ 2013-11-04 7:47 UTC (permalink / raw)
To: Bruce.Ma; +Cc: linux-bluetooth
In-Reply-To: <52774AB7.1010609@canonical.com>
Hi Bruce,
On Mon, Nov 04, 2013, Bruce.Ma wrote:
> From: Bruce Ma <bruce.ma@canonical.com>
> Date: Tue, 04 Nov 2013 11:21:20 +0800
> Subject: [PATCH] btusb: add Realtek 8723 in the blacklist
>
> The btusb doesn't work with Realtek 8723 bluetooth device,
> so we want to add it to the blacklist.
>
> Signed-off-by: Bruce Ma <bruce.ma@canonical.com>
> ---
> drivers/bluetooth/btusb.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/drivers/bluetooth/btusb.c b/drivers/bluetooth/btusb.c
> index eae58a1..3097ac8 100644
> --- a/drivers/bluetooth/btusb.c
> +++ b/drivers/bluetooth/btusb.c
> @@ -138,6 +138,9 @@ static struct usb_device_id blacklist_table[] = {
> { USB_DEVICE(0x0489, 0xe03d), .driver_info = BTUSB_IGNORE },
> { USB_DEVICE(0x0489, 0xe027), .driver_info = BTUSB_IGNORE },
> + /* Realtek 8723 Bluetooth */
> + { USB_DEVICE(0x0bda, 0xb728), .driver_info = BTUSB_IGNORE },
> +
> /* Atheros AR9285 Malbec with sflash firmware */
> { USB_DEVICE(0x03f0, 0x311d), .driver_info = BTUSB_IGNORE },
> -- 1.8.1.2
I suppose after adding the device to the blacklist it still doesn't
work? :)
What I mean is, what's the value of this patch if the experience the
user gets is the same both with and without it? Wouldn't it make more
sense to put some effort into fixing btusb so that this hardware *does*
work with it, or alternatively providing a separate driver to support
the hardware (after which it *would* be ok to add the id to the btusb
blacklist).
Johan
^ permalink raw reply
* Re: [PATCH] btusb: add realtek 8723 in the blacklist
From: Marcel Holtmann @ 2013-11-04 7:49 UTC (permalink / raw)
To: Bruce.Ma; +Cc: linux-bluetooth@vger.kernel.org development
In-Reply-To: <52774AB7.1010609@canonical.com>
Hi Bruce,
> From: Bruce Ma <bruce.ma@canonical.com>
> Date: Tue, 04 Nov 2013 11:21:20 +0800
> Subject: [PATCH] btusb: add Realtek 8723 in the blacklist
>
> The btusb doesn't work with Realtek 8723 bluetooth device,
> so we want to add it to the blacklist.
this is the same answer as last time. I do not randomly blacklist devices for out of tree drivers. Changing the commit message to make this look more innocent is not going to help.
Someone has to do the real work and get the Realtek support integrated into btusb.ko driver.
Regards
Marcel
^ permalink raw reply
* [PATCHv3 1/4] android/hal: Send get_remote_services cmd
From: Marcin Kraglak @ 2013-11-04 8:06 UTC (permalink / raw)
To: linux-bluetooth; +Cc: Marcin Kraglak
diff --git a/android/hal-bluetooth.c b/android/hal-bluetooth.c
index 7334d24..88c7b99 100644
--- a/android/hal-bluetooth.c
+++ b/android/hal-bluetooth.c
@@ -515,12 +515,18 @@ static int get_remote_service_record(bt_bdaddr_t *remote_addr, bt_uuid_t *uuid)
static int get_remote_services(bt_bdaddr_t *remote_addr)
{
+ struct hal_cmd_get_remote_services cmd;
+
DBG("bdaddr: %s", bdaddr2str(remote_addr));
if (!interface_ready())
return BT_STATUS_NOT_READY;
- return BT_STATUS_UNSUPPORTED;
+ memcpy(cmd.bdaddr, remote_addr, sizeof(cmd.bdaddr));
+
+ return hal_ipc_cmd(HAL_SERVICE_ID_BLUETOOTH,
+ HAL_OP_GET_REMOTE_SERVICES, sizeof(cmd), &cmd, 0,
+ NULL, NULL);
}
static int start_discovery(void)
--
1.8.4.1
^ permalink raw reply related
* [PATCHv3 2/4] android: Add stub of get_remote_services command
From: Marcin Kraglak @ 2013-11-04 8:06 UTC (permalink / raw)
To: linux-bluetooth; +Cc: Marcin Kraglak
In-Reply-To: <1383552410-2220-1-git-send-email-marcin.kraglak@tieto.com>
diff --git a/android/adapter.c b/android/adapter.c
index 6f2a061..af62b11 100644
--- a/android/adapter.c
+++ b/android/adapter.c
@@ -1459,6 +1459,11 @@ static uint8_t ssp_reply(void *buf, uint16_t len)
return status;
}
+static uint8_t get_remote_services(void *buf, uint16_t len)
+{
+ return HAL_STATUS_UNSUPPORTED;
+}
+
void bt_adapter_handle_cmd(GIOChannel *io, uint8_t opcode, void *buf,
uint16_t len)
{
@@ -1563,6 +1568,11 @@ void bt_adapter_handle_cmd(GIOChannel *io, uint8_t opcode, void *buf,
goto error;
break;
+ case HAL_OP_GET_REMOTE_SERVICES:
+ status = get_remote_services(buf, len);
+ if (status != HAL_STATUS_SUCCESS)
+ goto error;
+ break;
default:
DBG("Unhandled command, opcode 0x%x", opcode);
goto error;
--
1.8.4.1
^ permalink raw reply related
* [PATCHv3 3/4] android: Initial implementation of get_remote_services
From: Marcin Kraglak @ 2013-11-04 8:06 UTC (permalink / raw)
To: linux-bluetooth; +Cc: Marcin Kraglak
In-Reply-To: <1383552410-2220-1-git-send-email-marcin.kraglak@tieto.com>
diff --git a/android/adapter.c b/android/adapter.c
index af62b11..0470522 100644
--- a/android/adapter.c
+++ b/android/adapter.c
@@ -35,6 +35,10 @@
#include "src/shared/mgmt.h"
#include "src/glib-helper.h"
#include "src/eir.h"
+#include "lib/sdp.h"
+#include "lib/sdp_lib.h"
+#include "lib/uuid.h"
+#include "src/sdp-client.h"
#include "log.h"
#include "hal-msg.h"
#include "ipc.h"
@@ -45,6 +49,8 @@
#define DEFAULT_IO_CAPABILITY 0x01
static GIOChannel *notification_io = NULL;
+/* This list contains addresses which are asked for records */
+static GList *sdp_req_list;
struct bt_adapter {
uint16_t index;
@@ -63,6 +69,20 @@ struct bt_adapter {
bool discovering;
};
+struct browse_req {
+ bdaddr_t *bdaddr;
+ GSList *uuids;
+ int search_uuid;
+ int reconnect_attempt;
+};
+
+static const uint16_t uuid_list[] = {
+ L2CAP_UUID,
+ PNP_INFO_SVCLASS_ID,
+ PUBLIC_BROWSE_GROUP,
+ 0
+};
+
static struct bt_adapter *adapter;
static GSList *found_devices = NULL;
@@ -1459,9 +1479,80 @@ static uint8_t ssp_reply(void *buf, uint16_t len)
return status;
}
+static void browse_req_free(struct browse_req *req)
+{
+ g_free(req->bdaddr);
+ g_slist_free_full(req->uuids, g_free);
+ g_free(req);
+}
+
+static void update_records(struct browse_req *req, sdp_list_t *recs)
+{
+ /* TODO cache found uuids */
+}
+
+static void browse_cb(sdp_list_t *recs, int err, gpointer user_data)
+{
+ struct browse_req *req = user_data;
+ uuid_t uuid;
+
+ /* If we have a valid response and req->search_uuid == 2, then L2CAP
+ * UUID & PNP searching was successful -- we are done */
+ if (err < 0 || req->search_uuid == 2) {
+ if (err == -ECONNRESET && req->reconnect_attempt < 1) {
+ req->search_uuid--;
+ req->reconnect_attempt++;
+ } else {
+ goto done;
+ }
+ }
+
+ update_records(req, recs);
+
+ /* Search for mandatory uuids */
+ if (uuid_list[req->search_uuid]) {
+ sdp_uuid16_create(&uuid, uuid_list[req->search_uuid++]);
+ bt_search_service(&adapter->bdaddr, req->bdaddr, &uuid,
+ browse_cb, user_data, NULL);
+ return;
+ }
+
+done:
+ sdp_req_list = g_list_remove(sdp_req_list, req->bdaddr);
+ browse_req_free(req);
+}
+
static uint8_t get_remote_services(void *buf, uint16_t len)
{
- return HAL_STATUS_UNSUPPORTED;
+ struct hal_cmd_get_remote_services *cmd = buf;
+ struct browse_req *req;
+ bdaddr_t *addr;
+ uuid_t uuid;
+ int err;
+
+ addr = g_new0(bdaddr_t, 1);
+ android2bdaddr(&cmd->bdaddr, addr);
+
+ if (g_list_find_custom(sdp_req_list, addr, bdaddr_cmp)) {
+ g_free(addr);
+ return HAL_STATUS_DONE;
+ }
+
+ sdp_req_list = g_list_append(sdp_req_list, addr);
+
+ req = g_new0(struct browse_req, 1);
+ req->bdaddr = addr;
+ sdp_uuid16_create(&uuid, uuid_list[req->search_uuid++]);
+
+ err = bt_search_service(&adapter->bdaddr,
+ req->bdaddr, &uuid, browse_cb, req, NULL);
+ if (err) {
+ sdp_req_list = g_list_remove(sdp_req_list, req->bdaddr);
+ browse_req_free(req);
+ return HAL_STATUS_FAILED;
+ }
+
+ return HAL_STATUS_SUCCESS;
}
void bt_adapter_handle_cmd(GIOChannel *io, uint8_t opcode, void *buf,
--
1.8.4.1
^ permalink raw reply related
* [PATCHv3 4/4] android: Pass found uuids to remote_device_properties_cb
From: Marcin Kraglak @ 2013-11-04 8:06 UTC (permalink / raw)
To: linux-bluetooth; +Cc: Marcin Kraglak
In-Reply-To: <1383552410-2220-1-git-send-email-marcin.kraglak@tieto.com>
diff --git a/android/adapter.c b/android/adapter.c
index 0470522..9fe7d7d 100644
--- a/android/adapter.c
+++ b/android/adapter.c
@@ -1486,9 +1486,87 @@ static void browse_req_free(struct browse_req *req)
g_free(req);
}
+static void fill_uuids(GSList *list, void *buf)
+{
+ for (; list; list = (GSList *)g_list_next(list)) {
+ memcpy(buf, list->data, sizeof(uint128_t));
+ buf += sizeof(uint128_t);
+ }
+}
+
+static void remote_uuids_callback(struct browse_req *req)
+{
+ struct hal_ev_remote_device_props *ev;
+ int len;
+
+ len = sizeof(*ev) + sizeof(struct hal_property) + (sizeof(uint128_t) *
+ g_slist_length(req->uuids));
+ ev = g_malloc(len);
+
+ ev->status = HAL_STATUS_SUCCESS;
+ bdaddr2android(req->bdaddr, &ev->bdaddr);
+ ev->num_props = 1;
+ ev->props[0].type = HAL_PROP_DEVICE_UUIDS;
+ ev->props[0].len = sizeof(uint128_t) * g_slist_length(req->uuids);
+ fill_uuids(req->uuids, ev->props[0].val);
+
+ ipc_send(notification_io, HAL_SERVICE_ID_BLUETOOTH,
+ HAL_EV_REMOTE_DEVICE_PROPS, len, ev, -1);
+
+ g_free(ev);
+}
+
+static int uuid_128_cmp(gconstpointer a, gconstpointer b)
+{
+ return memcmp(a, b, sizeof(uint128_t));
+}
+
static void update_records(struct browse_req *req, sdp_list_t *recs)
{
- /* TODO cache found uuids */
+ for (; recs; recs = recs->next) {
+ sdp_record_t *rec = (sdp_record_t *) recs->data;
+ sdp_list_t *svcclass = NULL;
+ uuid_t uuid128;
+ uuid_t *temp;
+ uint8_t *u;
+
+ if (!rec)
+ break;
+
+ if (sdp_get_service_classes(rec, &svcclass) < 0)
+ continue;
+
+ if (svcclass == NULL)
+ continue;
+
+ temp = svcclass->data;
+
+ switch (temp->type) {
+ case SDP_UUID16:
+ sdp_uuid16_to_uuid128(&uuid128, temp);
+ break;
+ case SDP_UUID32:
+ sdp_uuid32_to_uuid128(&uuid128, temp);
+ break;
+ case SDP_UUID128:
+ memcpy(&uuid128, temp, sizeof(uuid_t));
+ break;
+ default:
+ continue;
+ }
+
+ u = g_malloc(16);/* size of 128 bit uuid */
+ memcpy(u, &uuid128.value.uuid128,
+ sizeof(uuid128.value.uuid128));
+
+ /* Check if uuid is already added */
+ if (g_slist_find_custom(req->uuids, u, uuid_128_cmp))
+ g_free(u);
+ else
+ req->uuids = g_slist_append(req->uuids, u);
+
+ sdp_list_free(svcclass, free);
+ }
}
static void browse_cb(sdp_list_t *recs, int err, gpointer user_data)
@@ -1518,6 +1596,7 @@ static void browse_cb(sdp_list_t *recs, int err, gpointer user_data)
}
done:
+ remote_uuids_callback(req);
sdp_req_list = g_list_remove(sdp_req_list, req->bdaddr);
browse_req_free(req);
}
--
1.8.4.1
^ permalink raw reply related
* Re: [PATCHv3 2/4] android: Add stub of get_remote_services command
From: Johan Hedberg @ 2013-11-04 8:24 UTC (permalink / raw)
To: Marcin Kraglak; +Cc: linux-bluetooth
In-Reply-To: <1383552410-2220-2-git-send-email-marcin.kraglak@tieto.com>
Hi Marcin,
On Mon, Nov 04, 2013, Marcin Kraglak wrote:
> diff --git a/android/adapter.c b/android/adapter.c
> index 6f2a061..af62b11 100644
> --- a/android/adapter.c
> +++ b/android/adapter.c
> @@ -1459,6 +1459,11 @@ static uint8_t ssp_reply(void *buf, uint16_t len)
> return status;
> }
>
> +static uint8_t get_remote_services(void *buf, uint16_t len)
> +{
> + return HAL_STATUS_UNSUPPORTED;
> +}
> +
> void bt_adapter_handle_cmd(GIOChannel *io, uint8_t opcode, void *buf,
> uint16_t len)
> {
> @@ -1563,6 +1568,11 @@ void bt_adapter_handle_cmd(GIOChannel *io, uint8_t opcode, void *buf,
> goto error;
>
> break;
> + case HAL_OP_GET_REMOTE_SERVICES:
> + status = get_remote_services(buf, len);
> + if (status != HAL_STATUS_SUCCESS)
> + goto error;
> + break;
> default:
> DBG("Unhandled command, opcode 0x%x", opcode);
> goto error;
The first two patches have been applied. I still need to do a more
thorough review of the other two before applying, and right this moment
I didn't have time for that.
Johan
^ permalink raw reply
* Re: [PATCHv3 4/4] android: Pass found uuids to remote_device_properties_cb
From: Szymon Janc @ 2013-11-04 8:32 UTC (permalink / raw)
To: Marcin Kraglak; +Cc: linux-bluetooth
In-Reply-To: <1383552410-2220-4-git-send-email-marcin.kraglak@tieto.com>
Hi Marcin,
> diff --git a/android/adapter.c b/android/adapter.c
> index 0470522..9fe7d7d 100644
> --- a/android/adapter.c
> +++ b/android/adapter.c
> @@ -1486,9 +1486,87 @@ static void browse_req_free(struct browse_req *req)
> g_free(req);
> }
>
> +static void fill_uuids(GSList *list, void *buf)
> +{
> + for (; list; list = (GSList *)g_list_next(list)) {
This should use g_slist_next().
> + memcpy(buf, list->data, sizeof(uint128_t));
> + buf += sizeof(uint128_t);
> + }
> +}
> +
> +static void remote_uuids_callback(struct browse_req *req)
> +{
> + struct hal_ev_remote_device_props *ev;
> + int len;
> +
> + len = sizeof(*ev) + sizeof(struct hal_property) + (sizeof(uint128_t) *
> + g_slist_length(req->uuids));
> + ev = g_malloc(len);
> +
> + ev->status = HAL_STATUS_SUCCESS;
> + bdaddr2android(req->bdaddr, &ev->bdaddr);
> + ev->num_props = 1;
> + ev->props[0].type = HAL_PROP_DEVICE_UUIDS;
> + ev->props[0].len = sizeof(uint128_t) * g_slist_length(req->uuids);
> + fill_uuids(req->uuids, ev->props[0].val);
> +
> + ipc_send(notification_io, HAL_SERVICE_ID_BLUETOOTH,
> + HAL_EV_REMOTE_DEVICE_PROPS, len, ev, -1);
> +
> + g_free(ev);
> +}
> +
> +static int uuid_128_cmp(gconstpointer a, gconstpointer b)
> +{
> + return memcmp(a, b, sizeof(uint128_t));
> +}
> +
> static void update_records(struct browse_req *req, sdp_list_t *recs)
> {
> - /* TODO cache found uuids */
> + for (; recs; recs = recs->next) {
> + sdp_record_t *rec = (sdp_record_t *) recs->data;
> + sdp_list_t *svcclass = NULL;
> + uuid_t uuid128;
> + uuid_t *temp;
> + uint8_t *u;
> +
> + if (!rec)
> + break;
> +
> + if (sdp_get_service_classes(rec, &svcclass) < 0)
> + continue;
> +
> + if (svcclass == NULL)
> + continue;
> +
> + temp = svcclass->data;
> +
> + switch (temp->type) {
> + case SDP_UUID16:
> + sdp_uuid16_to_uuid128(&uuid128, temp);
> + break;
> + case SDP_UUID32:
> + sdp_uuid32_to_uuid128(&uuid128, temp);
> + break;
> + case SDP_UUID128:
> + memcpy(&uuid128, temp, sizeof(uuid_t));
> + break;
> + default:
> + continue;
> + }
> +
> + u = g_malloc(16);/* size of 128 bit uuid */
> + memcpy(u, &uuid128.value.uuid128,
> + sizeof(uuid128.value.uuid128));
> +
> + /* Check if uuid is already added */
> + if (g_slist_find_custom(req->uuids, u, uuid_128_cmp))
> + g_free(u);
> + else
> + req->uuids = g_slist_append(req->uuids, u);
> +
> + sdp_list_free(svcclass, free);
> + }
> }
>
> static void browse_cb(sdp_list_t *recs, int err, gpointer user_data)
> @@ -1518,6 +1596,7 @@ static void browse_cb(sdp_list_t *recs, int err, gpointer user_data)
> }
>
> done:
> + remote_uuids_callback(req);
> sdp_req_list = g_list_remove(sdp_req_list, req->bdaddr);
> browse_req_free(req);
> }
>
--
BR
Szymon Janc
^ permalink raw reply
* Re: [PATCH] android/client: Fix pin reply call when pin argument missing in cmd
From: Jerzy Kasenberg @ 2013-11-04 8:40 UTC (permalink / raw)
To: Ravi kumar Veeramally, linux-bluetooth
In-Reply-To: <20131101131141.GA30191@x220.p-661hnu-f1>
Hi Ravi,
On 1 November 2013 14:11, Johan Hedberg <johan.hedberg@gmail.com> wrote:
> Hi Ravi,
>
> On Fri, Nov 01, 2013, Ravi kumar Veeramally wrote:
>> If condition checks number of arguments properly but still executes
>> EXEC command. It should display error message and return.
>> ---
>> android/client/if-bt.c | 11 +++++++----
>> 1 file changed, 7 insertions(+), 4 deletions(-)
>>
>> diff --git a/android/client/if-bt.c b/android/client/if-bt.c
>> index 3d97458..2c3cc4a 100644
>> --- a/android/client/if-bt.c
>> +++ b/android/client/if-bt.c
>> @@ -719,12 +719,15 @@ static void pin_reply_p(int argc, const char **argv)
>> RETURN_IF_NULL(if_bluetooth);
>> VERIFY_ADDR_ARG(2, &addr);
>>
>> - if (argc > 3) {
>> - accept = 1;
>> - pin_len = strlen(argv[3]);
>> - memcpy(pin.pin, argv[3], pin_len);
>> + if (argc != 4) {
>> + haltest_error("Usage <address> <pin>\n");
>> + return;
>> }
>>
>> + accept = 1;
>> + pin_len = strlen(argv[3]);
>> + memcpy(pin.pin, argv[3], pin_len);
>> +
>> EXEC(if_bluetooth->pin_reply, &addr, accept, pin_len, &pin);
>
> It seems to me that the original code might have been trying to do (if
> it hadn't been broken like it now is) a negative pin reply in the case
> that no parameter was given. At least I don't see any other code trying
> to call if_bluetooth->pin_reply with accept=1 in haltest. So I'd
> consider fixing that instead.
Idea here was: no pin given set accept to 0, so user would not need to
type accept argument at all.
What is missing though, is initialization of accept to 0.
--
Jerzy
^ permalink raw reply
* [RFC] android/daemon: Implement get adapter name
From: Andrei Emeltchenko @ 2013-11-04 9:22 UTC (permalink / raw)
To: linux-bluetooth
From: Andrei Emeltchenko <andrei.emeltchenko@intel.com>
---
android/adapter.c | 29 ++++++++++++++++++++++++-----
1 file changed, 24 insertions(+), 5 deletions(-)
diff --git a/android/adapter.c b/android/adapter.c
index cb92f2f..8210d1a 100644
--- a/android/adapter.c
+++ b/android/adapter.c
@@ -1016,13 +1016,32 @@ static void send_adapter_address(void)
g_free(ev);
}
-static bool get_name(void)
+static bool send_adapter_name(void)
{
- DBG("Not implemented");
+ struct hal_ev_adapter_props_changed *ev;
+ size_t len;
- /* TODO: Add implementation */
+ if (!adapter->name)
+ return false;
- return false;
+ len = sizeof(*ev) + sizeof(struct hal_property) +
+ strlen(adapter->name) + 1;
+
+ ev = g_malloc0(len);
+
+ ev->num_props = 1;
+ ev->status = HAL_STATUS_SUCCESS;
+
+ ev->props[0].type = HAL_PROP_ADAPTER_NAME;
+ ev->props[0].len = strlen(adapter->name) + 1;
+ memcpy(&ev->props[0].val, adapter->name, strlen(adapter->name));
+
+ ipc_send(notification_io, HAL_SERVICE_ID_BLUETOOTH,
+ HAL_EV_ADAPTER_PROPS_CHANGED, len, ev, -1);
+
+ g_free(ev);
+
+ return true;
}
static bool get_uuids(void)
@@ -1097,7 +1116,7 @@ static bool get_property(void *buf, uint16_t len)
send_adapter_address();
return true;
case HAL_PROP_ADAPTER_NAME:
- return get_name();
+ return send_adapter_name();
case HAL_PROP_ADAPTER_UUIDS:
return get_uuids();
case HAL_PROP_ADAPTER_CLASS:
--
1.7.10.4
^ permalink raw reply related
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