* Re: [PATCHv2] Fix handling nco affiliation fields
From: Johan Hedberg @ 2010-10-29 14:40 UTC (permalink / raw)
To: Lukasz Pawlik; +Cc: linux-bluetooth
In-Reply-To: <1288361066-21203-1-git-send-email-lucas.pawlik@gmail.com>
Hi Lukasz,
On Fri, Oct 29, 2010, Lukasz Pawlik wrote:
> Previously when contact record was divided into separate replies,
> phonebook-tracker would use first reply and merge only phone numbers,
> addresses and emails from next. Now it's merging all fields dependent on the
> nco:hasAffiliation as well.
> ---
> plugins/phonebook-tracker.c | 16 ++++++++++++++++
> 1 files changed, 16 insertions(+), 0 deletions(-)
Pushed upstream with a couple of minor tweaks.
Johan
^ permalink raw reply
* [PATCHv2] Fix handling nco affiliation fields
From: Lukasz Pawlik @ 2010-10-29 14:04 UTC (permalink / raw)
To: linux-bluetooth; +Cc: Lukasz Pawlik
Previously when contact record was divided into separate replies,
phonebook-tracker would use first reply and merge only phone numbers,
addresses and emails from next. Now it's merging all fields dependent on the
nco:hasAffiliation as well.
---
plugins/phonebook-tracker.c | 16 ++++++++++++++++
1 files changed, 16 insertions(+), 0 deletions(-)
diff --git a/plugins/phonebook-tracker.c b/plugins/phonebook-tracker.c
index 96290a4..30be895 100644
--- a/plugins/phonebook-tracker.c
+++ b/plugins/phonebook-tracker.c
@@ -982,6 +982,15 @@ static void add_phone_number(struct phonebook_contact *contact,
contact->numbers = g_slist_append(contact->numbers, number);
}
+static void add_affiliation(char **field, const char *value)
+{
+ if (strlen(*field) > 0 || value == NULL || strlen(value) == 0)
+ return;
+
+ g_free(*field);
+ *field = g_strdup(value);
+}
+
static struct phonebook_email *find_email(GSList *emails, const char *address,
int type)
{
@@ -1196,6 +1205,13 @@ add_numbers:
g_free(home_addr);
g_free(work_addr);
+ /* Adding fields connected by nco:hasAffiliation - they may be in
+ * separate replies */
+ add_affiliation(&contact->title, reply[33]);
+ add_affiliation(&contact->company, reply[22]);
+ add_affiliation(&contact->department, reply[23]);
+ add_affiliation(&contact->role, reply[24]);
+
DBG("contact %p", contact);
/* Adding contacts data to wrapper struct - this data will be used to
--
1.7.0.4
^ permalink raw reply related
* Re: [PATCH] Fix issue when setting limited discoverable mode
From: Johan Hedberg @ 2010-10-29 13:57 UTC (permalink / raw)
To: Luiz Augusto von Dentz; +Cc: linux-bluetooth
In-Reply-To: <1288357083-24664-1-git-send-email-luiz.dentz@gmail.com>
Hi Luiz,
On Fri, Oct 29, 2010, Luiz Augusto von Dentz wrote:
> When setting limited discoverable mode it will always switch to
> discoverable on adapter_mode_changed which doesn't match the pending mode
> requested.
>
> To fix this MODE_LIMITED was removed since it didn't represent a real
> scan mode but a discoverable mode so that limited discoverable and
> general discoverable are now both represented by MODE_DISCOVERABLE.
>
> Also limited bits are now set at same point the timeout start and removed
> when mode change to something different then discoverable or when
> discoverable timeout is removed permanently (set to 0).
> ---
> src/adapter.c | 76 +++++++++++++++++++++++++-------------------------------
> src/hcid.h | 1 -
> 2 files changed, 34 insertions(+), 43 deletions(-)
The patch has been pushed upstream. Thanks.
Johan
^ permalink raw reply
* Re: [PATCH] Fix handling nco affiliation fields
From: Johan Hedberg @ 2010-10-29 13:53 UTC (permalink / raw)
To: Lukasz Pawlik; +Cc: linux-bluetooth
In-Reply-To: <1288344619-18133-1-git-send-email-lucas.pawlik@gmail.com>
Hi Lukasz,
On Fri, Oct 29, 2010, Lukasz Pawlik wrote:
> Previously when contact record was divided into separate replies,
> phonebook-tracker would use first reply and merge only phone numbers,
> addresses and emails from next. Now it's merging all fields dependent on the
> nco:hasAffiliation as well.
> ---
> plugins/phonebook-tracker.c | 15 +++++++++++++++
> 1 files changed, 15 insertions(+), 0 deletions(-)
You'll need to fix the coding style before this goes upstream:
> +static void add_affiliation(char **field, const char *value)
> +{
> + if(strlen(*field) != 0 || value == NULL || strlen(value) == 0)
Space between "if" and "(". Also, I'd prefer > 0 instead of != 0 for the
first strlen check. Then, you're also using spaces instead of tabs for
the indentation of all code in this patch. Did you forget to switch your
editor into bluez/kernel mode?
Johan
^ permalink raw reply
* [PATCHv3 2/2] Bluetooth: timer check sk is not owned before freeing
From: Emeltchenko Andrei @ 2010-10-29 13:43 UTC (permalink / raw)
To: linux-bluetooth
In-Reply-To: <1288359781-4059-1-git-send-email-Andrei.Emeltchenko.news@gmail.com>
From: Andrei Emeltchenko <andrei.emeltchenko@nokia.com>
In timer context we might delete l2cap channel used by krfcommd.
The check makes sure that sk is not owned. If sk is owned we
restart timer for HZ/5.
Signed-off-by: Andrei Emeltchenko <andrei.emeltchenko@nokia.com>
---
net/bluetooth/l2cap.c | 32 ++++++++++++++++++++------------
1 files changed, 20 insertions(+), 12 deletions(-)
diff --git a/net/bluetooth/l2cap.c b/net/bluetooth/l2cap.c
index b1344d8..c67b3c6 100644
--- a/net/bluetooth/l2cap.c
+++ b/net/bluetooth/l2cap.c
@@ -83,6 +83,18 @@ static struct sk_buff *l2cap_build_cmd(struct l2cap_conn *conn,
static int l2cap_ertm_data_rcv(struct sock *sk, struct sk_buff *skb);
/* ---- L2CAP timers ---- */
+static void l2cap_sock_set_timer(struct sock *sk, long timeout)
+{
+ BT_DBG("sk %p state %d timeout %ld", sk, sk->sk_state, timeout);
+ sk_reset_timer(sk, &sk->sk_timer, jiffies + timeout);
+}
+
+static void l2cap_sock_clear_timer(struct sock *sk)
+{
+ BT_DBG("sock %p state %d", sk, sk->sk_state);
+ sk_stop_timer(sk, &sk->sk_timer);
+}
+
static void l2cap_sock_timeout(unsigned long arg)
{
struct sock *sk = (struct sock *) arg;
@@ -92,6 +104,14 @@ static void l2cap_sock_timeout(unsigned long arg)
bh_lock_sock(sk);
+ if (sock_owned_by_user(sk)) {
+ /* sk is owned by user. Try again later */
+ l2cap_sock_set_timer(sk, HZ / 5);
+ bh_unlock_sock(sk);
+ sock_put(sk);
+ return;
+ }
+
if (sk->sk_state == BT_CONNECTED || sk->sk_state == BT_CONFIG)
reason = ECONNREFUSED;
else if (sk->sk_state == BT_CONNECT &&
@@ -108,18 +128,6 @@ static void l2cap_sock_timeout(unsigned long arg)
sock_put(sk);
}
-static void l2cap_sock_set_timer(struct sock *sk, long timeout)
-{
- BT_DBG("sk %p state %d timeout %ld", sk, sk->sk_state, timeout);
- sk_reset_timer(sk, &sk->sk_timer, jiffies + timeout);
-}
-
-static void l2cap_sock_clear_timer(struct sock *sk)
-{
- BT_DBG("sock %p state %d", sk, sk->sk_state);
- sk_stop_timer(sk, &sk->sk_timer);
-}
-
/* ---- L2CAP channels ---- */
static struct sock *__l2cap_get_chan_by_dcid(struct l2cap_chan_list *l, u16 cid)
{
--
1.7.0.4
^ permalink raw reply related
* [PATCHv3 1/2] Bluetooth: Check sk is not owned before freeing l2cap_conn
From: Emeltchenko Andrei @ 2010-10-29 13:43 UTC (permalink / raw)
To: linux-bluetooth
In-Reply-To: <1288359781-4059-1-git-send-email-Andrei.Emeltchenko.news@gmail.com>
From: Andrei Emeltchenko <andrei.emeltchenko@nokia.com>
Check that socket sk is not locked in user process before removing
l2cap connection handler.
lock_sock and release_sock do not hold a normal spinlock directly but
instead hold the owner field. This means bh_lock_sock can still execute
even if the socket is "locked". More info can be found here:
http://www.linuxfoundation.org/collaborate/workgroups/networking/socketlocks
krfcommd kernel thread may be preempted with l2cap tasklet which remove
l2cap_conn structure. If krfcommd is in process of sending of RFCOMM reply
(like "RFCOMM UA" reply to "RFCOMM DISC") then kernel crash happens.
...
[ 694.175933] Unable to handle kernel NULL pointer dereference at virtual address 00000000
[ 694.184936] pgd = c0004000
[ 694.187683] [00000000] *pgd=00000000
[ 694.191711] Internal error: Oops: 5 [#1] PREEMPT
[ 694.196350] last sysfs file: /sys/devices/platform/hci_h4p/firmware/hci_h4p/loading
[ 694.260375] CPU: 0 Not tainted (2.6.32.10 #1)
[ 694.265106] PC is at l2cap_sock_sendmsg+0x43c/0x73c [l2cap]
[ 694.270721] LR is at 0xd7017303
...
[ 694.525085] Backtrace:
[ 694.527587] [<bf266be0>] (l2cap_sock_sendmsg+0x0/0x73c [l2cap]) from [<c02f2cc8>] (sock_sendmsg+0xb8/0xd8)
[ 694.537292] [<c02f2c10>] (sock_sendmsg+0x0/0xd8) from [<c02f3044>] (kernel_sendmsg+0x48/0x80)
Signed-off-by: Andrei Emeltchenko <andrei.emeltchenko@nokia.com>
---
net/bluetooth/l2cap.c | 26 ++++++++++++++++++++++++++
1 files changed, 26 insertions(+), 0 deletions(-)
diff --git a/net/bluetooth/l2cap.c b/net/bluetooth/l2cap.c
index 6f931cc..b1344d8 100644
--- a/net/bluetooth/l2cap.c
+++ b/net/bluetooth/l2cap.c
@@ -3078,6 +3078,14 @@ static inline int l2cap_connect_rsp(struct l2cap_conn *conn, struct l2cap_cmd_hd
break;
default:
+ /* don't delete l2cap channel if sk is owned by user */
+ if (sock_owned_by_user(sk)) {
+ sk->sk_state = BT_DISCONN;
+ l2cap_sock_clear_timer(sk);
+ l2cap_sock_set_timer(sk, HZ);
+ break;
+ }
+
l2cap_chan_del(sk, ECONNREFUSED);
break;
}
@@ -3283,6 +3291,15 @@ static inline int l2cap_disconnect_req(struct l2cap_conn *conn, struct l2cap_cmd
sk->sk_shutdown = SHUTDOWN_MASK;
+ /* don't delete l2cap channel if sk is owned by user */
+ if (sock_owned_by_user(sk)) {
+ sk->sk_state = BT_DISCONN;
+ l2cap_sock_clear_timer(sk);
+ l2cap_sock_set_timer(sk, HZ);
+ bh_unlock_sock(sk);
+ return 0;
+ }
+
l2cap_chan_del(sk, ECONNRESET);
bh_unlock_sock(sk);
@@ -3305,6 +3322,15 @@ static inline int l2cap_disconnect_rsp(struct l2cap_conn *conn, struct l2cap_cmd
if (!sk)
return 0;
+ /* don't delete l2cap channel if sk is owned by user */
+ if (sock_owned_by_user(sk)) {
+ sk->sk_state = BT_DISCONN;
+ l2cap_sock_clear_timer(sk);
+ l2cap_sock_set_timer(sk, HZ);
+ bh_unlock_sock(sk);
+ return 0;
+ }
+
l2cap_chan_del(sk, 0);
bh_unlock_sock(sk);
--
1.7.0.4
^ permalink raw reply related
* [PATCHv3 0/2] Fix kernel crash in rfcomm/l2cap
From: Emeltchenko Andrei @ 2010-10-29 13:42 UTC (permalink / raw)
To: linux-bluetooth
From: Andrei Emeltchenko <andrei.emeltchenko@nokia.com>
Yet another version of patches fixing kernel crash in RFCOMM / L2CAP.
Do not delete l2cap channel and socket sk when sk is owned by user.
To delete l2cap channel standard timer is used.
lock_sock and release_sock do not hold a normal spinlock directly but
instead hold the owner field. This means bh_lock_sock can still execute
even if the socket is "locked". More info can be found here:
http://www.linuxfoundation.org/collaborate/workgroups/networking/socketlocks
When sending following sequence:
...
No. Time Source Destination Protocol Info
89 1.951202 RFCOMM Rcvd DISC DLCI=20
90 1.951324 RFCOMM Sent UA DLCI=20
91 1.959381 HCI_EVT Number of Completed Packets
92 1.966461 RFCOMM Rcvd DISC DLCI=0
93 1.966492 L2CAP Rcvd Disconnect Request
94 1.972595 L2CAP Sent Disconnect Response
...
krfcommd kernel thread is preempted with l2cap tasklet which remove l2cap_conn
(L2CAP connection handler structure). Then rfcomm thread tries to send RFCOMM
UA which is reply to RFCOMM DISC and when de-referencing l2cap_conn crash
happens.
Andrei Emeltchenko (2):
Bluetooth: Check sk is not owned before freeing l2cap_conn
Bluetooth: timer check sk is not owned before freeing
net/bluetooth/l2cap.c | 58 ++++++++++++++++++++++++++++++++++++++----------
1 files changed, 46 insertions(+), 12 deletions(-)
^ permalink raw reply
* Re: [PATCH 2/6] Bluetooth: fix receiving L2CAP packets over LE
From: Vinicius Gomes @ 2010-10-29 13:41 UTC (permalink / raw)
To: Ville Tervo; +Cc: ext Anderson Briglia, linux-bluetooth@vger.kernel.org
In-Reply-To: <20101029104435.GQ15050@null>
Hi Ville,
On Fri, Oct 29, 2010 at 6:44 AM, Ville Tervo <ville.tervo@nokia.com> wrote:
> Hi Anderson,
>
> On Sat, Oct 23, 2010 at 01:56:56AM +0200, ext Anderson Briglia wrote:
>> From: Vinicius Costa Gomes <vinicius.gomes@openbossa.org>
>>
>> As L2CAP packets coming over LE don't have any more encapsulation,
>> other than L2CAP, we are able to process them as soon as they arrive.
>
> Why is this change needed? Was something broken without this patch?
>
This change is needed because without it the receiving side would
always think that it was receiving continuation frames.
As the flags parameter is zero, it would fall into the "} else {"
condition, and because no frame was received before, conn->rx_len
would be zero and the frame would be discarded. Without this patch I
was seeing those "Unexpected continuation frame ..." messages on the
receiving side.
>
>
>>
>> Signed-off-by: Vinicius Costa Gomes <vinicius.gomes@openbossa.org>
>> ---
>> net/bluetooth/l2cap.c | 17 +++++++++++++++--
>> 1 files changed, 15 insertions(+), 2 deletions(-)
>>
>> diff --git a/net/bluetooth/l2cap.c b/net/bluetooth/l2cap.c
>> index 2bf083e..1ac44f4 100644
>> --- a/net/bluetooth/l2cap.c
>> +++ b/net/bluetooth/l2cap.c
>> @@ -4768,17 +4768,30 @@ static int l2cap_security_cfm(struct hci_conn *hcon, u8 status, u8 encrypt)
>> static int l2cap_recv_acldata(struct hci_conn *hcon, struct sk_buff *skb, u16 flags)
>> {
>> struct l2cap_conn *conn = hcon->l2cap_data;
>> + struct l2cap_hdr *hdr;
>> + int len;
>>
>> if (!conn && !(conn = l2cap_conn_add(hcon, 0)))
>> goto drop;
>>
>> BT_DBG("conn %p len %d flags 0x%x", conn, skb->len, flags);
>>
>> + if (hcon->type == LE_LINK) {
>> + hdr = (struct l2cap_hdr *) skb->data;
>> + len = __le16_to_cpu(hdr->len) + L2CAP_HDR_SIZE;
>> +
>> + if (len == skb->len) {
>> + /* Complete frame received */
>> + l2cap_recv_frame(conn, skb);
>> + return 0;
>> + }
>> +
>> + goto drop;
>> + }
>> +
>> if (flags & ACL_START) {
>> - struct l2cap_hdr *hdr;
>> struct sock *sk;
>> u16 cid;
>> - int len;
>>
>> if (conn->rx_len) {
>> BT_ERR("Unexpected start frame (len %d)", skb->len);
>> --
>> 1.7.0.4
>>
>> --
>> 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
>
> --
> Ville
>
Cheers,
--
Vinicius
^ permalink raw reply
* Re: [RFC] AVRCP 1.4 : Design proposal for future on Target Role
From: Luiz Augusto von Dentz @ 2010-10-29 13:16 UTC (permalink / raw)
To: shivendra.agrawal@stericsson.com; +Cc: linux-bluetooth
In-Reply-To: <AANLkTikzecKtx3ib-03n3f8_2u4KF0Y+PSmEJgccEg-i@mail.gmail.com>
Hi,
On Wed, Oct 27, 2010 at 11:23 AM, shivendra.agrawal@stericsson.com
<ag.shivendra@gmail.com> wrote:
> Hi All,
>
> ST-Ericsson plans to implement the commands to support target role of
> AVRCP 1.4 Profile, and we would like to contribute it to BlueZ.
> With our initial discussion, I would be aligning with BlueZ
> contributors and would propose for the ideas that has not been
> touched/developed so far, in order to have a design/implementation
> that can be accepted.
>
> As a very first, and very rough, design proposal for the BlueZ parts:
> - A new SDP record for AVRCP 1.4 would be added to inform CT of the
> version and features supported by target.
> - A new callback to accept browsing channel establishment.
> - Enhancing similar to bt_io_listen for browsing PSM.
> - A new browsing command handler
> - Incremental addition to AVRCP 1.4 commands.
>
> Any feedback is very much appreciated!
>
> Ref: Previous discussion subject: "AVRCP 1.4 : Future on Target Role"
I guess for all people that are interested in AVRCP 1.4 we can start
adding items to TODO list, to make it easier to share development
between us. Since this may be too much to handle in a single global
TODO maybe we can have a separated file like audio/TODO.
--
Luiz Augusto von Dentz
Computer Engineer
^ permalink raw reply
* [PATCH] Fix issue when setting limited discoverable mode
From: Luiz Augusto von Dentz @ 2010-10-29 12:58 UTC (permalink / raw)
To: linux-bluetooth
From: Luiz Augusto von Dentz <luiz.dentz-von@nokia.com>
When setting limited discoverable mode it will always switch to
discoverable on adapter_mode_changed which doesn't match the pending mode
requested.
To fix this MODE_LIMITED was removed since it didn't represent a real
scan mode but a discoverable mode so that limited discoverable and
general discoverable are now both represented by MODE_DISCOVERABLE.
Also limited bits are now set at same point the timeout start and removed
when mode change to something different then discoverable or when
discoverable timeout is removed permanently (set to 0).
---
src/adapter.c | 76 +++++++++++++++++++++++++-------------------------------
src/hcid.h | 1 -
2 files changed, 34 insertions(+), 43 deletions(-)
diff --git a/src/adapter.c b/src/adapter.c
index 1b03ef1..32c74d1 100644
--- a/src/adapter.c
+++ b/src/adapter.c
@@ -410,7 +410,6 @@ static const char *mode2str(uint8_t mode)
case MODE_CONNECTABLE:
return "connectable";
case MODE_DISCOVERABLE:
- case MODE_LIMITED:
return "discoverable";
default:
return "unknown";
@@ -425,8 +424,6 @@ static uint8_t get_mode(const bdaddr_t *bdaddr, const char *mode)
return MODE_CONNECTABLE;
else if (strcasecmp("discoverable", mode) == 0)
return MODE_DISCOVERABLE;
- else if (strcasecmp("limited", mode) == 0)
- return MODE_LIMITED;
else if (strcasecmp("on", mode) == 0) {
char onmode[14], srcaddr[18];
@@ -439,12 +436,33 @@ static uint8_t get_mode(const bdaddr_t *bdaddr, const char *mode)
return MODE_UNKNOWN;
}
+static void adapter_set_limited_discoverable(struct btd_adapter *adapter,
+ gboolean limited)
+{
+ DBG("%s", limited ? "TRUE" : "FALSE");
+
+ /* Check if limited bit needs to be set/reset */
+ if (limited)
+ adapter->wanted_cod |= LIMITED_BIT;
+ else
+ adapter->wanted_cod &= ~LIMITED_BIT;
+
+ /* If we dont need the toggling, save an unnecessary CoD write */
+ if (adapter->pending_cod ||
+ adapter->wanted_cod == adapter->current_cod)
+ return;
+
+ if (adapter_ops->set_limited_discoverable(adapter->dev_id,
+ adapter->wanted_cod, limited) == 0)
+ adapter->pending_cod = adapter->wanted_cod;
+}
+
static void adapter_remove_discov_timeout(struct btd_adapter *adapter)
{
if (!adapter)
return;
- if(adapter->discov_timeout_id == 0)
+ if (adapter->discov_timeout_id == 0)
return;
g_source_remove(adapter->discov_timeout_id);
@@ -470,33 +488,23 @@ static void adapter_set_discov_timeout(struct btd_adapter *adapter,
adapter->discov_timeout_id = 0;
}
- if (interval == 0)
+ if (interval == 0) {
+ adapter_set_limited_discoverable(adapter, FALSE);
return;
+ }
+
+ /* Set limited discoverable if pairable and interval between 0 to 60
+ sec */
+ if (adapter->pairable && interval <= 60)
+ adapter_set_limited_discoverable(adapter, TRUE);
+ else
+ adapter_set_limited_discoverable(adapter, FALSE);
adapter->discov_timeout_id = g_timeout_add_seconds(interval,
discov_timeout_handler,
adapter);
}
-static void adapter_set_limited_discoverable(struct btd_adapter *adapter,
- gboolean limited)
-{
- /* Check if limited bit needs to be set/reset */
- if (limited)
- adapter->wanted_cod |= LIMITED_BIT;
- else
- adapter->wanted_cod &= ~LIMITED_BIT;
-
- /* If we dont need the toggling, save an unnecessary CoD write */
- if (adapter->pending_cod ||
- adapter->wanted_cod == adapter->current_cod)
- return;
-
- if (adapter_ops->set_limited_discoverable(adapter->dev_id,
- adapter->wanted_cod, limited) == 0)
- adapter->pending_cod = adapter->wanted_cod;
-}
-
static struct session_req *session_ref(struct session_req *req)
{
req->refcount++;
@@ -551,9 +559,6 @@ static int adapter_set_mode(struct btd_adapter *adapter, uint8_t mode)
if (adapter->discov_timeout)
adapter_set_discov_timeout(adapter, adapter->discov_timeout);
- if (mode != MODE_LIMITED && adapter->mode == MODE_LIMITED)
- adapter_set_limited_discoverable(adapter, FALSE);
-
return 0;
}
@@ -629,11 +634,6 @@ static DBusMessage *set_discoverable(DBusConnection *conn, DBusMessage *msg,
mode = discoverable ? MODE_DISCOVERABLE : MODE_CONNECTABLE;
- if (mode == MODE_DISCOVERABLE && adapter->pairable &&
- adapter->discov_timeout > 0 &&
- adapter->discov_timeout <= 60)
- mode = MODE_LIMITED;
-
if (mode == adapter->mode)
return dbus_message_new_method_return(msg);
@@ -673,7 +673,6 @@ static DBusMessage *set_pairable(DBusConnection *conn, DBusMessage *msg,
gboolean pairable, void *data)
{
struct btd_adapter *adapter = data;
- uint8_t mode;
int err;
if (adapter->scan_mode == SCAN_DISABLED)
@@ -685,11 +684,7 @@ static DBusMessage *set_pairable(DBusConnection *conn, DBusMessage *msg,
if (!(adapter->scan_mode & SCAN_INQUIRY))
goto store;
- mode = (pairable && adapter->discov_timeout > 0 &&
- adapter->discov_timeout <= 60) ?
- MODE_LIMITED : MODE_DISCOVERABLE;
-
- err = set_mode(adapter, mode, NULL);
+ err = set_mode(adapter, MODE_DISCOVERABLE, NULL);
if (err < 0 && msg)
return failed_strerror(msg, -err);
@@ -3255,10 +3250,7 @@ void adapter_mode_changed(struct btd_adapter *adapter, uint8_t scan_mode)
ADAPTER_INTERFACE, "Pairable",
DBUS_TYPE_BOOLEAN, &pairable);
- if (discoverable && adapter->pairable && adapter->discov_timeout > 0 &&
- adapter->discov_timeout <= 60)
- adapter_set_limited_discoverable(adapter, TRUE);
- else if (!discoverable)
+ if (!discoverable)
adapter_set_limited_discoverable(adapter, FALSE);
emit_property_changed(connection, path,
diff --git a/src/hcid.h b/src/hcid.h
index 040411b..c73fe80 100644
--- a/src/hcid.h
+++ b/src/hcid.h
@@ -39,7 +39,6 @@
#define MODE_OFF 0x00
#define MODE_CONNECTABLE 0x01
#define MODE_DISCOVERABLE 0x02
-#define MODE_LIMITED 0x03
#define MODE_UNKNOWN 0xff
struct main_opts {
--
1.7.1
^ permalink raw reply related
* Re: [PATCH] Fix handling nco affiliation fields
From: Anderson Lizardo @ 2010-10-29 12:46 UTC (permalink / raw)
To: Lukasz Pawlik; +Cc: linux-bluetooth
In-Reply-To: <1288344619-18133-1-git-send-email-lucas.pawlik@gmail.com>
On Fri, Oct 29, 2010 at 5:30 AM, Lukasz Pawlik <lucas.pawlik@gmail.com> wrote:
> Previously when contact record was divided into separate replies,
> phonebook-tracker would use first reply and merge only phone numbers,
> addresses and emails from next. Now it's merging all fields dependent on the
> nco:hasAffiliation as well.
> ---
> plugins/phonebook-tracker.c | 15 +++++++++++++++
> 1 files changed, 15 insertions(+), 0 deletions(-)
>
> diff --git a/plugins/phonebook-tracker.c b/plugins/phonebook-tracker.c
> index 96290a4..f37ed5a 100644
> --- a/plugins/phonebook-tracker.c
> +++ b/plugins/phonebook-tracker.c
> @@ -982,6 +982,14 @@ static void add_phone_number(struct phonebook_contact *contact,
> contact->numbers = g_slist_append(contact->numbers, number);
> }
>
> +static void add_affiliation(char **field, const char *value)
> +{
> + if(strlen(*field) != 0 || value == NULL || strlen(value) == 0)
> + return;
Is *field always non-NULL ? If yes, then the next g_strdup() will leak
one byte (the "\0"). If not, strlen() will segfault on a NULL pointer.
> +
> + *field = g_strdup(value);
> +}
> +
> static struct phonebook_email *find_email(GSList *emails, const char *address,
> int type)
> {
> @@ -1196,6 +1204,13 @@ add_numbers:
> g_free(home_addr);
> g_free(work_addr);
>
> + /* Adding fields connected by nco:hasAffiliation - they may be in
> + * separate replies */
> + add_affiliation(&contact->title, reply[33]);
> + add_affiliation(&contact->company, reply[22]);
> + add_affiliation(&contact->department, reply[23]);
> + add_affiliation(&contact->role, reply[24]);
> +
> DBG("contact %p", contact);
>
> /* Adding contacts data to wrapper struct - this data will be used to
> --
> 1.7.0.4
>
> --
> 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
>
Regards,
--
Anderson Lizardo
OpenBossa Labs - INdT
Manaus - Brazil
^ permalink raw reply
* Re: Kernel panic in rfcomm_run - unbalanced refcount on rfcomm_session
From: Simantini Bhattacharya @ 2010-10-29 12:34 UTC (permalink / raw)
To: Andrei Emeltchenko
Cc: Nick Pelly, Ville Tervo, Dave Young, Bluettooth Linux,
Marcel Holtmann
In-Reply-To: <508e92ca1003190133m1e2769ev36430d3c3b28504@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 6961 bytes --]
Hi All ,
I have seen a similar issue when testing my device with Motorola 17 mono
headset . The use-case tried was as follows :
1)Pair connect device to Motorola H17
2)Power up Bluetooth on my device
3)Power back Bluetooth on the device .
On repeating this sequence for around 10-15 times I see the following kernel
panic . Trace shown as below .
Can you let me know your comments on this ?
<6>[ 1100.245300] Bluetooth:
<6>[ 1100.247985] Bluetooth:
<6>[ 1100.251068] Bluetooth: sock ca817360, sk cbe32e00
<6>[ 1100.263336] Bluetooth: sock ca817360, sk cbe32e00
<6>[ 1100.268524] Bluetooth: sock cbe32e00 state 4
<6>[ 1100.273468] Bluetooth: sk cbe32e00 state 4 socket ca817360
<6>[ 1100.279296] Bluetooth: parent cbe32e00
<6>[ 1100.283325] Bluetooth: sock d3832080 state 7
<6>[ 1100.287872] Bluetooth: hu db514b00 count 52 rx_state 0 rx_count 0
<6>[ 1100.294372] Bluetooth: Event packet
<6>[ 1100.298126] Bluetooth: Event header: evt 0x13 plen 5
<6>[ 1100.303375] Bluetooth: len 5 room 1078
<6>[ 1100.307403] Bluetooth: Complete data
<6>[ 1100.311218] Bluetooth: Event packet
<6>[ 1100.314941] Bluetooth: Event header: evt 0x13 plen 5
<6>[ 1100.320281] Bluetooth: hci0
<6>[ 1100.323272] Bluetooth: hdev cbe32980 len 7
<6>[ 1100.327606] Bluetooth: hci0 num_hndl 1
<6>[ 1100.331665] Bluetooth: hci0 acl 3 sco 4
<6>[ 1100.335723] Bluetooth: hci0
<6>[ 1100.338714] Bluetooth: conn (null) quote 0
<6>[ 1100.343139] Bluetooth: hci0
<6>[ 1100.346099] Bluetooth: conn (null) quote 0
<6>[ 1100.350463] Bluetooth: hci0
<6>[ 1100.353515] Bluetooth: conn (null) quote 0
<6>[ 1100.357849] Bluetooth: len 5 room 1078
<6>[ 1100.361846] Bluetooth: Complete data
<6>[ 1100.365722] Bluetooth: ACL packet
<6>[ 1100.369262] Bluetooth: ACL header: dlen 14
<6>[ 1100.373596] Bluetooth: hci0
<6>[ 1100.376586] Bluetooth: hdev cbe32980 len 7
<6>[ 1100.381011] Bluetooth: hci0 num_hndl 1
<6>[ 1100.384979] Bluetooth: hci0 acl 4 sco 4
<6>[ 1100.389038] Bluetooth: hci0
<6>[ 1100.392089] Bluetooth: conn (null) quote 0
<6>[ 1100.396453] Bluetooth: hci0
<6>[ 1100.399414] Bluetooth: conn (null) quote 0
<6>[ 1100.403839] Bluetooth: hci0
<6>[ 1100.406799] Bluetooth: conn (null) quote 0
<6>[ 1100.411163] Bluetooth: len 14 room 1076
<6>[ 1100.415283] Bluetooth: Complete data
<6>[ 1100.419097] Bluetooth: ACL packet
<6>[ 1100.422637] Bluetooth: ACL header: dlen 24
<6>[ 1100.427032] Bluetooth: hci0
<6>[ 1100.430023] Bluetooth: hdev cbe32980 len 18
<6>[ 1100.434448] Bluetooth: hci0 ACL data packet
<6>[ 1100.438934] Bluetooth: hci0 len 14 handle 0x1 flags 0x2
<6>[ 1100.444458] Bluetooth: conn d3a0f5c0 mode 0
<6>[ 1100.448913] Bluetooth: conn db5473c0 len 14 flags 0x2
<6>[ 1100.454284] Bluetooth: len 10, cid 0x0001
<6>[ 1100.458557] Bluetooth: conn db5473c0
<6>[ 1100.462341] Bluetooth: code 0x05 len 6 id 0x02
<6>[ 1100.467132] Bluetooth: scid 0x0040 flags 0x00 result 0x00
<6>[ 1100.472808] Bluetooth: sk d3832080, parent (null)
<6>[ 1100.477874] Bluetooth: sock d3832080 state 1
<6>[ 1100.482421] Bluetooth: len 24 room 1076
<6>[ 1100.487579] Bluetooth: sock ca817b08
<6>[ 1100.491485] Bluetooth: cmd 400448ca arg 0
<6>[ 1100.498565] Bluetooth: sk d3832080 state 1 socket (null)
<6>[ 1100.504699] Bluetooth: 0
<6>[ 1100.507415] Bluetooth: hci0 cbe32980
<6>[ 1100.511230] Bluetooth: hci0 err 0x13
<6>[ 1100.515014] Bluetooth: cache cbe32bc0
<6>[ 1100.518981] Bluetooth: hdev hci0
<6>[ 1100.522430] Bluetooth: hcon d3a0f5c0 reason 22
<6>[ 1100.527130] Bluetooth: hcon d3a0f5c0 conn db5473c0, err 103
<6>[ 1100.533081] Bluetooth: sock d3832080 state 1
<6>[ 1100.537597] Bluetooth: sk d3832080, conn db5473c0, err 103
<6>[ 1100.543487] Bluetooth: sk d3832080 state 9
<6>[ 1100.547821] Bluetooth: sk d3832080
<6>[ 1100.551452] Bluetooth: hcon d3a0f5c0 reason 22
<6>[ 1100.556213] Bluetooth: hci0 conn d3a0f5c0 handle 1
<6>[ 1100.561279] Bluetooth: conn d3a0f5c0
<1>[ 1100.566925] Unable to handle kernel paging request at virtual address
6b6b6b6b
<1>[ 1100.574584] pgd = c0004000
<1>[ 1100.577453] [6b6b6b6b] *pgd=00000000
<0>[ 1100.581420] Internal error: Oops: 5 [#1] PREEMPT
<0>[ 1100.586303] last sysfs file:
/sys/devices/system/cpu/cpu0/cpufreq/stats/time_in_state
<4>[ 1100.594573] Modules linked in: em_u32 sch_htb cls_u32 act_police
sch_ingress act_mirred ifb sec
<4>[ 1100.604522] CPU: 0 Tainted: G W (2.6.32.9-g09b2432-dirty
#1)
<4>[ 1100.611602] PC is at release_sock+0x60/0xf0
<4>[ 1100.616088] LR is at release_sock+0x18/0xf0
<4>[ 1101.576324] [<c0309930>] (release_sock+0x60/0xf0) from [<c03e9f40>]
(__l2cap_sock_close+0x8c/0x31c)
<4>[ 1101.585876] [<c03e9f40>] (__l2cap_sock_close+0x8c/0x31c) from
[<c03ed9b4>] (l2cap_sock_shutdown+0x5c/0xa0)
<4>[ 1101.596069] [<c03ed9b4>] (l2cap_sock_shutdown+0x5c/0xa0) from
[<c03eda2c>] (l2cap_sock_release+0x34/0x90)
<4>[ 1101.606170] [<c03eda2c>] (l2cap_sock_release+0x34/0x90) from
[<c0307ccc>] (sock_release+0x20/0xb0)
<4>[ 1101.615570] [<c0307ccc>] (sock_release+0x20/0xb0) from [<c0307d7c>]
(sock_close+0x20/0x2c)
<4>[ 1101.624267] [<c0307d7c>] (sock_close+0x20/0x2c) from [<c00c978c>]
(__fput+0x11c/0x218)
<4>[ 1101.632659] [<c00c978c>] (__fput+0x11c/0x218) from [<c00c65a8>]
(filp_close+0x6c/0x78)
<4>[ 1101.641052] [<c00c65a8>] (filp_close+0x6c/0x78) from [<c0068f38>]
(put_files_struct+0x88/0xf0)
<4>[ 1101.650085] [<c0068f38>] (put_files_struct+0x88/0xf0) from
[<c006a7bc>] (do_exit+0x1b0/0x698)
<4>[ 1101.659088] [<c006a7bc>] (do_exit+0x1b0/0x698) from [<c006ad54>]
(do_group_exit+0xb0/0xdc)
<4>[ 1101.667846] [<c006ad54>] (do_group_exit+0xb0/0xdc) from [<c006ad90>]
(sys_exit_group+0x10/0x18)
<4>[ 1101.677032] [<c006ad90>] (sys_exit_group+0x10/0x18) from [<c0034f40>]
(ret_fast_syscall+0x0/0x2c)
On Fri, Mar 19, 2010 at 2:03 PM, Andrei Emeltchenko <
andrei.emeltchenko.news@gmail.com> wrote:
> Hi,
>
> On Tue, Mar 9, 2010 at 9:31 AM, Nick Pelly <npelly@google.com> wrote:
> > On Mon, Mar 8, 2010 at 11:19 PM, Ville Tervo <ville.tervo@nokia.com>
> wrote:
> >> Tervo Ville (Nokia-D/Helsinki) wrote:
> >>>
> >>> l2cap socket status might change while rfcomm is processing frames. And
> >>> that makes rfcomm_process_rx to do double rfcomm_session_put() for
> incoming
> >>> session reference. We cannot use sk_state.
> >>>
> >>> Could you try with this patch if it helps to your problems also? My OPP
> >>> problems went away with this patch.
> >>>
> >>> I moved rfcomm_session_put() for incoming session to
> rfcomm_session_close
> >>> in order to get more clear _hold()/_put() pairs.
> >>>
> >>>
> >>
> >> Any comments about the patch in previous mail?
> >
> > Your patch looks sane to me, although I know enough of the Bluez
> > rfcomm state machine to know that I don't know it that well :)
>
> We have tested this patch and it looks to be working. Shall we apply it?
>
> Regards,
> Andrei
> --
> 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
>
[-- Attachment #2: Type: text/html, Size: 8861 bytes --]
^ permalink raw reply
* Re: [PATCH 5/9] mfd: Add UART support for the ST-Ericsson CG2900.
From: Par-Gunnar Hjalmdahl @ 2010-10-29 12:08 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Alan Cox, linus.walleij, linux-bluetooth, linux-kernel,
Lukasz.Rymanowski
In-Reply-To: <AANLkTinh3D8V8UaN8FyCouwUQ98A4RRWEHXU7Tr9XMbs@mail.gmail.com>
2010/10/29 Par-Gunnar Hjalmdahl <pghatwork@gmail.com>:
> 2010/10/28 Arnd Bergmann <arnd@arndb.de>:
>> On Friday 22 October 2010, Par-Gunnar Hjalmdahl wrote:
>>
>>> >
>>> > So - NAK this for the moment, it needs to be split cleanly into ldisc
>>> > (thing which speaks the protocol and eg sees "speed change required" and
>>> > acts on it) and device (thing which knows about the hardware).
>>>
>>> OK. We will try to figure out a new design.
>>> I'm not too happy about putting the ldisc part in Bluetooth though
>>> since it is only partly Bluetooth, it is also GPS and FM. Better could
>>> maybe be under char/?
>>
>> After getting a better idea of what the base mfd driver does, my impression
>> is now that you should not register a second N_HCI line discipline at all,
>> but instead extend the existing line discipline with this number.
>>
>> I'm not sure what happens if you need two modules that try to register
>> the same ldisc number, but I imagine it is not good.
>>
>> Shouldn't you instead be using the drivers/bluetooth/hci_{ldisc,h4} code?
>>
>> Arnd
>>
>
> We also need the ldisc code to handle events from FM and GPS and since
> that is chip specific we cannot add that to the generic hci_ldisc
> code.
> I agree that we might run into problems if two drivers try to register
> the same line discipline. It might then be better to introduce a new
> line discipline then even though that could cause other problems. I do
> not know if it is possible to add a condition in Kconfig otherwise so
> the CG2900 ldisc cannot be active while the "normal" ldisc driver is
> selected.
>
> /P-G
>
Hi again,
I might have been a bit too quick there.
The actual channel matching and packet creation is done in hci_h4.c
while ldisc registration is done in hci_ldisc.c.
So it might to be enough to create a new hci_h4-cg2900.c (or similar
name) that can separate the right channels. We must however do changes
to hci_ldisc as well since it seems to always register to the
Bluetooth stack here, which we definitely don't want since that is
handled by btcg2900.c.
Also note that this ldisc issue is only valid when using UART as
transport. We will also support SPI and then we will probably run into
completely new, interesting problems. :-)
/P-G
^ permalink raw reply
* Re: [PATCH 5/9] mfd: Add UART support for the ST-Ericsson CG2900.
From: Par-Gunnar Hjalmdahl @ 2010-10-29 11:58 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Alan Cox, linus.walleij, linux-bluetooth, linux-kernel,
Lukasz.Rymanowski
In-Reply-To: <201010281422.46687.arnd@arndb.de>
2010/10/28 Arnd Bergmann <arnd@arndb.de>:
> On Friday 22 October 2010, Par-Gunnar Hjalmdahl wrote:
>
>> >
>> > So - NAK this for the moment, it needs to be split cleanly into ldisc
>> > (thing which speaks the protocol and eg sees "speed change required" and
>> > acts on it) and device (thing which knows about the hardware).
>>
>> OK. We will try to figure out a new design.
>> I'm not too happy about putting the ldisc part in Bluetooth though
>> since it is only partly Bluetooth, it is also GPS and FM. Better could
>> maybe be under char/?
>
> After getting a better idea of what the base mfd driver does, my impression
> is now that you should not register a second N_HCI line discipline at all,
> but instead extend the existing line discipline with this number.
>
> I'm not sure what happens if you need two modules that try to register
> the same ldisc number, but I imagine it is not good.
>
> Shouldn't you instead be using the drivers/bluetooth/hci_{ldisc,h4} code?
>
> Arnd
>
We also need the ldisc code to handle events from FM and GPS and since
that is chip specific we cannot add that to the generic hci_ldisc
code.
I agree that we might run into problems if two drivers try to register
the same line discipline. It might then be better to introduce a new
line discipline then even though that could cause other problems. I do
not know if it is possible to add a condition in Kconfig otherwise so
the CG2900 ldisc cannot be active while the "normal" ldisc driver is
selected.
/P-G
^ permalink raw reply
* Re: [PATCH 5/9] mfd: Add UART support for the ST-Ericsson CG2900.
From: Par-Gunnar Hjalmdahl @ 2010-10-29 11:53 UTC (permalink / raw)
To: Alan Cox; +Cc: linus.walleij, linux-bluetooth, linux-kernel
In-Reply-To: <20101022135130.617f0ce8@lxorguk.ukuu.org.uk>
2010/10/22 Alan Cox <alan@lxorguk.ukuu.org.uk>:
>> +
>> +/**
>> + * create_work_item() - Create work item and add it to the work queue.
>> + * @wq: work queue struct where the work will be added.
>> + * @work_func: Work function.
>> + * @data: Private data for the work.
>> + *
>> + * Returns:
>> + * 0 if there is no error.
>> + * -EBUSY if not possible to queue work.
>> + * -ENOMEM if allocation fails.
>> + */
>> +static int create_work_item(struct workqueue_struct *wq, work_func_t work_func,
>> + void *data)
>> +{
>> + struct uart_work_struct *new_work;
>> + int err;
>> +
>> + new_work = kmalloc(sizeof(*new_work), GFP_ATOMIC);
>
> So instead of a tiny object embedded in your device you've got a whole
> error path to worry about, a printk disguised in a macro and a text
> string longer than the struct size ? Surely this should be part of the
> device
>
I've tried now to use 3 separate work_structs in the device (one for
each work function used), but this doesn't work out.
The reason is that the work is generated so often that a work is not
finished before next work of same type comes. This is especially true
for transmit and receive. Then I get 0 back when queuing the work and
there is no real way to solve it from what I can see than to allocate
new work structures every time.
/P-G
^ permalink raw reply
* Re: [PATCH 2/6] Bluetooth: fix receiving L2CAP packets over LE
From: Ville Tervo @ 2010-10-29 10:44 UTC (permalink / raw)
To: ext Anderson Briglia
Cc: linux-bluetooth@vger.kernel.org, Vinicius Costa Gomes
In-Reply-To: <1287791820-22693-3-git-send-email-anderson.briglia@openbossa.org>
Hi Anderson,
On Sat, Oct 23, 2010 at 01:56:56AM +0200, ext Anderson Briglia wrote:
> From: Vinicius Costa Gomes <vinicius.gomes@openbossa.org>
>
> As L2CAP packets coming over LE don't have any more encapsulation,
> other than L2CAP, we are able to process them as soon as they arrive.
Why is this change needed? Was something broken without this patch?
>
> Signed-off-by: Vinicius Costa Gomes <vinicius.gomes@openbossa.org>
> ---
> net/bluetooth/l2cap.c | 17 +++++++++++++++--
> 1 files changed, 15 insertions(+), 2 deletions(-)
>
> diff --git a/net/bluetooth/l2cap.c b/net/bluetooth/l2cap.c
> index 2bf083e..1ac44f4 100644
> --- a/net/bluetooth/l2cap.c
> +++ b/net/bluetooth/l2cap.c
> @@ -4768,17 +4768,30 @@ static int l2cap_security_cfm(struct hci_conn *hcon, u8 status, u8 encrypt)
> static int l2cap_recv_acldata(struct hci_conn *hcon, struct sk_buff *skb, u16 flags)
> {
> struct l2cap_conn *conn = hcon->l2cap_data;
> + struct l2cap_hdr *hdr;
> + int len;
>
> if (!conn && !(conn = l2cap_conn_add(hcon, 0)))
> goto drop;
>
> BT_DBG("conn %p len %d flags 0x%x", conn, skb->len, flags);
>
> + if (hcon->type == LE_LINK) {
> + hdr = (struct l2cap_hdr *) skb->data;
> + len = __le16_to_cpu(hdr->len) + L2CAP_HDR_SIZE;
> +
> + if (len == skb->len) {
> + /* Complete frame received */
> + l2cap_recv_frame(conn, skb);
> + return 0;
> + }
> +
> + goto drop;
> + }
> +
> if (flags & ACL_START) {
> - struct l2cap_hdr *hdr;
> struct sock *sk;
> u16 cid;
> - int len;
>
> if (conn->rx_len) {
> BT_ERR("Unexpected start frame (len %d)", skb->len);
> --
> 1.7.0.4
>
> --
> 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
--
Ville
^ permalink raw reply
* [PATCH] Fix handling nco affiliation fields
From: Lukasz Pawlik @ 2010-10-29 9:30 UTC (permalink / raw)
To: linux-bluetooth; +Cc: Lukasz Pawlik
Previously when contact record was divided into separate replies,
phonebook-tracker would use first reply and merge only phone numbers,
addresses and emails from next. Now it's merging all fields dependent on the
nco:hasAffiliation as well.
---
plugins/phonebook-tracker.c | 15 +++++++++++++++
1 files changed, 15 insertions(+), 0 deletions(-)
diff --git a/plugins/phonebook-tracker.c b/plugins/phonebook-tracker.c
index 96290a4..f37ed5a 100644
--- a/plugins/phonebook-tracker.c
+++ b/plugins/phonebook-tracker.c
@@ -982,6 +982,14 @@ static void add_phone_number(struct phonebook_contact *contact,
contact->numbers = g_slist_append(contact->numbers, number);
}
+static void add_affiliation(char **field, const char *value)
+{
+ if(strlen(*field) != 0 || value == NULL || strlen(value) == 0)
+ return;
+
+ *field = g_strdup(value);
+}
+
static struct phonebook_email *find_email(GSList *emails, const char *address,
int type)
{
@@ -1196,6 +1204,13 @@ add_numbers:
g_free(home_addr);
g_free(work_addr);
+ /* Adding fields connected by nco:hasAffiliation - they may be in
+ * separate replies */
+ add_affiliation(&contact->title, reply[33]);
+ add_affiliation(&contact->company, reply[22]);
+ add_affiliation(&contact->department, reply[23]);
+ add_affiliation(&contact->role, reply[24]);
+
DBG("contact %p", contact);
/* Adding contacts data to wrapper struct - this data will be used to
--
1.7.0.4
^ permalink raw reply related
* btusb Headset Microphone not working
From: Michael Kopp @ 2010-10-29 8:41 UTC (permalink / raw)
To: linux-bluetooth
Hello,
I upgraded my notebook recently and as of now the headset microphone
is not working anymore. When trying arecord no data is being recorded.
I already tried several versions of bluez up and to including 4.75
with kernels 2.6.32, 2.6.34 2.6.35, no joy.
I get the following error in dmesg
btusb_submit_isoc_urb: hci0 urb f359fe00 submission failed (28)
btusb_submit_isoc_urb: hci0 urb f5f37200 submission failed (28)
/var/log/messages reveals a little more
ct 29 08:40:54 mkopp bluetoothd[5751]: link_key_request
(sba=1C:65:9D:02:DE:E0, dba=00:16:94:09:DB:88)
Oct 29 08:40:54 mkopp bluetoothd[5751]: link_key_request
(sba=1C:65:9D:02:DE:E0, dba=00:16:94:09:DB:88)
Oct 29 08:40:57 mkopp kernel: input: 00:16:94:09:DB:88 as
/devices/virtual/input/input16
Oct 29 08:42:21 mkopp kernel: btusb_submit_isoc_urb: hci0 urb f359fe00
submission failed (28)
Oct 29 08:43:28 mkopp bluetoothd[5751]: No matching connection found
for handle 6
Oct 29 08:45:28 mkopp kernel: btusb_submit_isoc_urb: hci0 urb f5f37200
submission failed (28)
Oct 29 08:45:50 mkopp bluetoothd[5751]: No matching connection found
for handle 6
Oct 29 08:49:19 mkopp kernel: input: 00:16:94:09:DB:88 as
/devices/virtual/input/input17
Oct 29 08:49:20 mkopp bluetoothd[5751]: Disconnected from
00:16:94:09:DB:88, /org/bluez/5751/hci0/dev_00_16_94_09_DB_88
Audio output works for both AD2P and SCO, input works on neither
although the headset supports it and works on my cell phone.
my .asoundrc is as simple as it gets
pcm.bluetooth {
type bluetooth
device "00:16:94:09:DB:88"
profile "voice"
}
I've tried google and all sorts of forums but although I've seen this
error several times I was not able to find a solution. I would be
grateful if somebody could point me towards a solution.
Best regards
Michael Kopp
^ permalink raw reply
* Re: Unable to get on D-Bus: bluez 4.77
From: Puneet Pant @ 2010-10-29 7:30 UTC (permalink / raw)
Cc: linux-bluetooth
In-Reply-To: <AANLkTi=H+zqzZb6f303VJRXA_zmibiG=Zec0unxy5b-=@mail.gmail.com>
Hello,
On Thu, Oct 28, 2010 at 10:48 PM, Puneet Pant <pant.puneet464@gmail.com> wrote:
> Hi Gustavo,
>
> On Thu, Oct 28, 2010 at 5:39 PM, Gustavo F. Padovan
> <padovan@profusion.mobi> wrote:
>> Hi Puneet,
>>
>> * Puneet Pant <pant.puneet464@gmail.com> [2010-10-28 17:02:48 +0530]:
>>
>>> Hello,
>>>
>>> I have compiled Bluez 4.77. But I'm getting the following error when
>>> trying to start Bluetooth Daemon:
>>>
>>> root@puneet-VirtualBox:/home/puneet/packages/bluez-4.77/src#
>>> dbus-daemon --system
>>> root@puneet-VirtualBox:/home/puneet/packages/bluez-4.77/src# ./bluetoothd -nd
>>> bluetoothd[11819]: Bluetooth deamon 4.77
>>> bluetoothd[11819]: src/main.c:parse_config() parsing main.conf
>>> bluetoothd[11819]: src/main.c:parse_config() discovto=0
>>> bluetoothd[11819]: src/main.c:parse_config() pairto=0
>>> bluetoothd[11819]: src/main.c:parse_config() pageto=8192
>>> bluetoothd[11819]: src/main.c:parse_config() name=%h-%d
>>> bluetoothd[11819]: src/main.c:parse_config() class=0x000100
>>> bluetoothd[11819]: src/main.c:parse_config() discov_interval=0
>>> bluetoothd[11819]: src/main.c:parse_config() Key file does not have
>>> key 'DeviceID'
>>> bluetoothd[11819]: Unable to get on D-Bus
>>
>> One of the reasons could be that you already have the bluetoothd daemon
>> running.
>>
>
> I did "ps -e | grep bluetooth" and found no bluetoothd running.
> Could this be related to D-Bus library version incompatibility with ubuntu.
> As I see, Ubuntu 10.10 comes with Dbus 1.4.0 installed, but when I run
> ./configure for bluez, it does not detect the installed D-Bus. I had
> to manually download and install D-Bus 1.2.24 for bluez configure to
> detect and compile?
>
>> --
I am able to resolve the issue by installing appropriate D-Bus library
headers through Synaptic Manager on Ubuntu 10.10 and rebuilding Bluez
code.
Installing Dbus separately seems to have caused the problem.
After building the code, bluetooth daemon is working fine.
>> Gustavo F. Padovan
>> ProFUSION embedded systems - http://profusion.mobi
>>
>
> Thanks,
> Puneet
>
Thanks,
Puneet
^ permalink raw reply
* AVRCP 1.4 Patch
From: John Crosbie @ 2010-10-29 5:23 UTC (permalink / raw)
To: João Paulo Rechi Vita; +Cc: linux-bluetooth
João Paulo,
I have been working with your AVRCP 1.4 patches that are posted on
GSOC. I found a problem in one of your patch files that I thought I
would relate:
in [PATCH 03/10] AVRCP: Handle GetCapabilities PDU
at line 48
+ metadata = (struct metadata_header *) avrcp + AVRCP_HEADER_LENGTH + 3;
the pointer arithmetic is broken and should be something like:
+ metadata = (struct metadata_header *)((uint8_t*)avrcp +
AVRCP_HEADER_LENGTH + 3);
Now the device (CT) Requests CAP_COMPANY_ID and CAP_EVENTS_SUPPORTED
as expected but doesn't do anything more so I will continue digging.
I am working with a Sony Ericsson MW600 device. It claims to have
AVRCP 1.4 support but I have not confirmed that it works as yet.
If I am working with old code please let me know.
Regards,
John Crosbie
Excelfore
^ permalink raw reply
* Re: [PATCH 3/5] Fix setting Discoverable when adapter is down
From: Johan Hedberg @ 2010-10-28 19:00 UTC (permalink / raw)
To: Luiz Augusto von Dentz; +Cc: linux-bluetooth
In-Reply-To: <1288252859-10337-3-git-send-email-luiz.dentz@gmail.com>
Hi Luiz,
On Thu, Oct 28, 2010, Luiz Augusto von Dentz wrote:
> From: Luiz Augusto von Dentz <luiz.dentz-von@nokia.com>
>
> This cause an error because adapter_up will load the mode from storage
> ignoring pending mode which cause modes to mismatch.
>
> To fix this behavior now when attempting to change mode we first store
> the new mode and wait DEVUP to complete set the mode stored.
> ---
> src/adapter.c | 19 +++++++++++--------
> 1 files changed, 11 insertions(+), 8 deletions(-)
Patches 3/5, 4/5 and 5/5 have also been pushed upstream. Thanks.
Johan
^ permalink raw reply
* Re: RFCOMM connection from android device to desktop pc
From: jaikumar Ganesh @ 2010-10-28 18:47 UTC (permalink / raw)
To: Leandro de Oliveira; +Cc: linux-bluetooth
In-Reply-To: <AANLkTimU3vT0MiqiTk0E8mFhVJJWXB5xJ50RosiYHCBy@mail.gmail.com>
Hi Leandro:
Debugging this is on my list. I will get back to you.
Thanks
On Thu, Oct 28, 2010 at 11:11 AM, Leandro de Oliveira
<lehphyro@gmail.com> wrote:
> So, any ideas? Don't you find it strange that bluez can't communicate
> with itself?
>
> 2010/10/22 Leandro de Oliveira <lehphyro@gmail.com>:
>> Hi,
>>
>> I'm trying to open an RFCOMM connection from my android device to my
>> desktop pc running Ubuntu 10.04, send some data, close the connection
>> and then do it again. My desktop program is written in Java and relies
>> on BlueCove[1] to handle bluetooth details which calls Bluez 4.x in
>> this case.
>>
>> The problem is that I get a successful connection and data transfer in
>> the first communication attempt but nothing in subsequent attempts.
>>
>> There is this thread[2] in the android-platform mailing list with much
>> more detail, but I think you could just take a look at this hcidump
>> that has been requested there to let me know if this is a problem in
>> bluez on the android or desktop side:
>> http://dl.dropbox.com/u/1401233/pc-hcidump.txt
>>
>> Please, let me know if you need more info.
>>
>> The same program works perfectly when the android application connects
>> to it running on Windows 7 using the Microsoft Bluetooth Stack.
>>
>> [1] http://www.bluecove.org/
>> [2] http://groups.google.com/group/android-platform/browse_thread/thread/485db57409304d3e?hl=en
>>
>> Thank you very much
>>
> --
> 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 2/5] Fix not waiting mode change when setting powered property
From: Johan Hedberg @ 2010-10-28 18:28 UTC (permalink / raw)
To: Luiz Augusto von Dentz; +Cc: linux-bluetooth
In-Reply-To: <1288252859-10337-2-git-send-email-luiz.dentz@gmail.com>
Hi Luiz,
On Thu, Oct 28, 2010, Luiz Augusto von Dentz wrote:
> From: Luiz Augusto von Dentz <luiz.dentz-von@nokia.com>
>
> This may cause errors if the user application immediately set another
> mode.
> ---
> src/adapter.c | 84 +++++++++++++++++++++++++++++---------------------------
> 1 files changed, 43 insertions(+), 41 deletions(-)
This patch has been pushed upstream. Thanks.
Johan
^ permalink raw reply
* Re: [PATCH 1/5] Fix issue when setting limited discoverable mode
From: Johan Hedberg @ 2010-10-28 18:24 UTC (permalink / raw)
To: Luiz Augusto von Dentz; +Cc: linux-bluetooth
In-Reply-To: <1288252859-10337-1-git-send-email-luiz.dentz@gmail.com>
Hi Luiz,
On Thu, Oct 28, 2010, Luiz Augusto von Dentz wrote:
> if (discoverable && adapter->pairable && adapter->discov_timeout > 0 &&
> - adapter->discov_timeout <= 60)
> + adapter->discov_timeout <= 60) {
> + adapter->mode = MODE_LIMITED;
> adapter_set_limited_discoverable(adapter, TRUE);
Wouldn't it make more sense to do the fix to adapter->mode inside the
adapter_set_limited_discoverable function?
Johan
^ permalink raw reply
* Re: RFCOMM connection from android device to desktop pc
From: Leandro de Oliveira @ 2010-10-28 18:11 UTC (permalink / raw)
To: linux-bluetooth
In-Reply-To: <AANLkTinBqjTmLiXwd5LkzZRXOkuYkfS=48m6gWQ9AQO7@mail.gmail.com>
So, any ideas? Don't you find it strange that bluez can't communicate
with itself?
2010/10/22 Leandro de Oliveira <lehphyro@gmail.com>:
> Hi,
>
> I'm trying to open an RFCOMM connection from my android device to my
> desktop pc running Ubuntu 10.04, send some data, close the connection
> and then do it again. My desktop program is written in Java and relies
> on BlueCove[1] to handle bluetooth details which calls Bluez 4.x in
> this case.
>
> The problem is that I get a successful connection and data transfer in
> the first communication attempt but nothing in subsequent attempts.
>
> There is this thread[2] in the android-platform mailing list with much
> more detail, but I think you could just take a look at this hcidump
> that has been requested there to let me know if this is a problem in
> bluez on the android or desktop side:
> http://dl.dropbox.com/u/1401233/pc-hcidump.txt
>
> Please, let me know if you need more info.
>
> The same program works perfectly when the android application connects
> to it running on Windows 7 using the Microsoft Bluetooth Stack.
>
> [1] http://www.bluecove.org/
> [2] http://groups.google.com/group/android-platform/browse_thread/thread/485db57409304d3e?hl=en
>
> Thank you very much
>
^ 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