* [PATCH v2 3/9] Remove btd_device_add_service function
From: Claudio Takahasi @ 2011-04-11 18:24 UTC (permalink / raw)
To: linux-bluetooth; +Cc: Claudio Takahasi
In-Reply-To: <1302197414-833-3-git-send-email-claudio.takahasi@openbossa.org>
btd_device_add_service is no longer necessary if the object paths for
the primary services can be returned during the registration.
---
attrib/client.c | 16 ++++++++--------
attrib/client.h | 2 +-
src/device.c | 11 ++---------
src/device.h | 1 -
4 files changed, 11 insertions(+), 19 deletions(-)
diff --git a/attrib/client.c b/attrib/client.c
index 28e5704..2dd70c9 100644
--- a/attrib/client.c
+++ b/attrib/client.c
@@ -1020,11 +1020,11 @@ static GDBusMethodTable prim_methods[] = {
{ }
};
-static void register_primaries(struct gatt_service *gatt, GSList *primaries)
+static GSList *register_primaries(struct gatt_service *gatt, GSList *primaries)
{
- GSList *l;
+ GSList *l, *paths;
- for (l = primaries; l; l = l->next) {
+ for (paths = NULL, l = primaries; l; l = l->next) {
struct att_primary *att = l->data;
struct primary *prim;
@@ -1040,12 +1040,14 @@ static void register_primaries(struct gatt_service *gatt, GSList *primaries)
DBG("Registered: %s", prim->path);
gatt->primary = g_slist_append(gatt->primary, prim);
- btd_device_add_service(gatt->dev, prim->path);
+ paths = g_slist_append(paths, g_strdup(prim->path));
load_characteristics(prim, gatt);
}
+
+ return paths;
}
-int attrib_client_register(DBusConnection *connection,
+GSList *attrib_client_register(DBusConnection *connection,
struct btd_device *device, int psm,
GAttrib *attrib, GSList *primaries)
{
@@ -1069,11 +1071,9 @@ int attrib_client_register(DBusConnection *connection,
if (attrib)
gatt->attrib = g_attrib_ref(attrib);
- register_primaries(gatt, primaries);
-
gatt_services = g_slist_append(gatt_services, gatt);
- return 0;
+ return register_primaries(gatt, primaries);
}
void attrib_client_unregister(struct btd_device *device)
diff --git a/attrib/client.h b/attrib/client.h
index b4a4ecc..b29797c 100644
--- a/attrib/client.h
+++ b/attrib/client.h
@@ -22,7 +22,7 @@
*
*/
-int attrib_client_register(DBusConnection *connection,
+GSList *attrib_client_register(DBusConnection *connection,
struct btd_device *device, int psm,
GAttrib *attrib, GSList *primaries);
void attrib_client_unregister(struct btd_device *device);
diff --git a/src/device.c b/src/device.c
index f9b7a73..efe9938 100644
--- a/src/device.c
+++ b/src/device.c
@@ -2336,18 +2336,11 @@ void device_set_authorizing(struct btd_device *device, gboolean auth)
device->authorizing = auth;
}
-void btd_device_add_service(struct btd_device *device, const char *path)
-{
- if (g_slist_find_custom(device->services, path, (GCompareFunc) strcmp))
- return;
-
- device->services = g_slist_append(device->services, g_strdup(path));
-}
-
void device_register_services(DBusConnection *conn, struct btd_device *device,
GSList *prim_list, int psm)
{
- attrib_client_register(conn, device, psm, NULL, prim_list);
+ device->services = attrib_client_register(conn, device, psm, NULL,
+ prim_list);
device->primaries = g_slist_concat(device->primaries, prim_list);
}
diff --git a/src/device.h b/src/device.h
index 285364f..2432884 100644
--- a/src/device.h
+++ b/src/device.h
@@ -56,7 +56,6 @@ void device_probe_drivers(struct btd_device *device, GSList *profiles);
const sdp_record_t *btd_device_get_record(struct btd_device *device,
const char *uuid);
GSList *btd_device_get_primaries(struct btd_device *device);
-void btd_device_add_service(struct btd_device *device, const char *path);
void device_register_services(DBusConnection *conn, struct btd_device *device,
GSList *prim_list, int psm);
void btd_device_add_uuid(struct btd_device *device, const char *uuid);
--
1.7.4.1
^ permalink raw reply related
* [PATCH v2 2/9] Cleanup primary service registration from storage
From: Claudio Takahasi @ 2011-04-11 18:24 UTC (permalink / raw)
To: linux-bluetooth; +Cc: Claudio Takahasi
In-Reply-To: <1302197414-833-2-git-send-email-claudio.takahasi@openbossa.org>
---
src/adapter.c | 9 +--------
src/device.c | 20 ++++++--------------
src/device.h | 4 ++--
3 files changed, 9 insertions(+), 24 deletions(-)
diff --git a/src/adapter.c b/src/adapter.c
index c400bfd..6caff9a 100644
--- a/src/adapter.c
+++ b/src/adapter.c
@@ -58,8 +58,6 @@
#include "storage.h"
#include "attrib-server.h"
#include "att.h"
-#include "gattrib.h"
-#include "attrib/client.h"
/* Interleaved discovery window: 5.12 sec */
#define GAP_INTER_DISCOV_WIN 5120
@@ -2193,16 +2191,11 @@ static void create_stored_device_from_primary(char *key, char *value,
for (l = services, uuids = NULL; l; l = l->next) {
struct att_primary *prim = l->data;
uuids = g_slist_append(uuids, prim->uuid);
-
- device_add_primary(device, prim);
}
- /* FIXME: Need the correct psm */
- attrib_client_register(connection, device, -1, NULL, services);
-
device_probe_drivers(device, uuids);
+ device_register_services(connection, device, services, -1);
- g_slist_free(services);
g_slist_free(uuids);
}
diff --git a/src/device.c b/src/device.c
index ecd1861..f9b7a73 100644
--- a/src/device.c
+++ b/src/device.c
@@ -1406,14 +1406,6 @@ static GSList *primary_from_record(struct btd_device *device, GSList *profiles)
return prim_list;
}
-static void register_primary_services(DBusConnection *conn,
- struct btd_device *device, GSList *prim_list)
-{
- /* TODO: PSM is hardcoded */
- attrib_client_register(conn, device, 31, NULL, prim_list);
- device->primaries = g_slist_concat(device->primaries, prim_list);
-}
-
static void search_cb(sdp_list_t *recs, int err, gpointer user_data)
{
struct browse_req *req = user_data;
@@ -1450,7 +1442,7 @@ static void search_cb(sdp_list_t *recs, int err, gpointer user_data)
list = primary_from_record(device, req->profiles_added);
if (list)
- register_primary_services(req->conn, device, list);
+ device_register_services(req->conn, device, list, 31);
}
/* Remove drivers for services removed */
@@ -1592,13 +1584,11 @@ static void primary_cb(GSList *services, guint8 status, gpointer user_data)
for (l = services; l; l = l->next) {
struct att_primary *prim = l->data;
uuids = g_slist_append(uuids, prim->uuid);
- device_add_primary(device, prim);
}
device_probe_drivers(device, uuids);
- /* FIXME: Need the correct psm */
- attrib_client_register(req->conn, device, -1, req->attrib, services);
+ device_register_services(req->conn, device, services, -1);
g_slist_free(uuids);
@@ -2354,9 +2344,11 @@ void btd_device_add_service(struct btd_device *device, const char *path)
device->services = g_slist_append(device->services, g_strdup(path));
}
-void device_add_primary(struct btd_device *device, struct att_primary *prim)
+void device_register_services(DBusConnection *conn, struct btd_device *device,
+ GSList *prim_list, int psm)
{
- device->primaries = g_slist_append(device->primaries, prim);
+ attrib_client_register(conn, device, psm, NULL, prim_list);
+ device->primaries = g_slist_concat(device->primaries, prim_list);
}
GSList *btd_device_get_primaries(struct btd_device *device)
diff --git a/src/device.h b/src/device.h
index 3ce212b..285364f 100644
--- a/src/device.h
+++ b/src/device.h
@@ -25,7 +25,6 @@
#define DEVICE_INTERFACE "org.bluez.Device"
struct btd_device;
-struct att_primary;
typedef enum {
AUTH_TYPE_PINCODE,
@@ -58,7 +57,8 @@ const sdp_record_t *btd_device_get_record(struct btd_device *device,
const char *uuid);
GSList *btd_device_get_primaries(struct btd_device *device);
void btd_device_add_service(struct btd_device *device, const char *path);
-void device_add_primary(struct btd_device *device, struct att_primary *prim);
+void device_register_services(DBusConnection *conn, struct btd_device *device,
+ GSList *prim_list, int psm);
void btd_device_add_uuid(struct btd_device *device, const char *uuid);
struct btd_adapter *device_get_adapter(struct btd_device *device);
void device_get_address(struct btd_device *device, bdaddr_t *bdaddr);
--
1.7.4.1
^ permalink raw reply related
* [PATCH v2 1/9] Register primary services exported over basic rate
From: Claudio Takahasi @ 2011-04-11 18:24 UTC (permalink / raw)
To: linux-bluetooth; +Cc: Claudio Takahasi
In-Reply-To: <BANLkTikZia_V1pVN_EqF8cpk0xu6GF9ZCg@mail.gmail.com>
This patch registers the object paths for primary services exported
through SDP. PSM, start and end handle information are available in
the Protocol Descriptor List.
---
attrib/gatt.c | 78 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++
attrib/gatt.h | 6 ++++
src/device.c | 56 ++++++++++++++++++++++++++++++++++++++++-
3 files changed, 139 insertions(+), 1 deletions(-)
diff --git a/attrib/gatt.c b/attrib/gatt.c
index 0b69daf..360218b 100644
--- a/attrib/gatt.c
+++ b/attrib/gatt.c
@@ -23,8 +23,11 @@
*/
#include <stdint.h>
+#include <stdlib.h>
#include <glib.h>
#include <bluetooth/uuid.h>
+#include <bluetooth/sdp.h>
+#include <bluetooth/sdp_lib.h>
#include "att.h"
#include "gattrib.h"
@@ -575,3 +578,78 @@ guint gatt_write_cmd(GAttrib *attrib, uint16_t handle, uint8_t *value, int vlen,
return g_attrib_send(attrib, 0, ATT_OP_WRITE_CMD, buf, plen, NULL,
user_data, notify);
}
+
+static sdp_data_t *proto_seq_find(sdp_list_t *proto_list)
+{
+ sdp_list_t *list;
+ uuid_t proto;
+
+ sdp_uuid16_create(&proto, ATT_UUID);
+
+ for (list = proto_list; list; list = list->next) {
+ sdp_list_t *p;
+ for (p = list->data; p; p = p->next) {
+ sdp_data_t *seq = p->data;
+ if (seq && seq->dtd == SDP_UUID16 &&
+ sdp_uuid16_cmp(&proto, &seq->val.uuid) == 0)
+ return seq->next;
+ }
+ }
+
+ return NULL;
+}
+
+static gboolean parse_proto_params(sdp_list_t *proto_list, uint16_t *psm,
+ uint16_t *start, uint16_t *end)
+{
+ sdp_data_t *seq1, *seq2;
+
+ if (psm)
+ *psm = sdp_get_proto_port(proto_list, L2CAP_UUID);
+
+ /* Getting start and end handle */
+ seq1 = proto_seq_find(proto_list);
+ if (!seq1 || seq1->dtd != SDP_UINT16)
+ return FALSE;
+
+ seq2 = seq1->next;
+ if (!seq2 || seq2->dtd != SDP_UINT16)
+ return FALSE;
+
+ if (start)
+ *start = seq1->val.uint16;
+
+ if (end)
+ *end = seq2->val.uint16;
+
+ return TRUE;
+}
+
+gboolean gatt_parse_record(const sdp_record_t *rec,
+ uuid_t *prim_uuid, uint16_t *psm,
+ uint16_t *start, uint16_t *end)
+{
+ sdp_list_t *list;
+ uuid_t uuid;
+ gboolean ret;
+
+ if (sdp_get_service_classes(rec, &list) < 0)
+ return FALSE;
+
+ memcpy(&uuid, list->data, sizeof(uuid));
+ sdp_list_free(list, free);
+
+ if (sdp_get_access_protos(rec, &list) < 0)
+ return FALSE;
+
+ ret = parse_proto_params(list, psm, start, end);
+
+ sdp_list_foreach(list, (sdp_list_func_t) sdp_list_free, NULL);
+ sdp_list_free(list, NULL);
+
+ /* FIXME: replace by bt_uuid_t after uuid_t/sdp code cleanup */
+ if (ret && prim_uuid)
+ memcpy(prim_uuid, &uuid, sizeof(uuid_t));
+
+ return ret;
+}
diff --git a/attrib/gatt.h b/attrib/gatt.h
index 221d94d..2c2f38c 100644
--- a/attrib/gatt.h
+++ b/attrib/gatt.h
@@ -24,6 +24,8 @@
#define GATT_CID 4
+#include <bluetooth/sdp.h>
+
typedef void (*gatt_cb_t) (GSList *l, guint8 status, gpointer user_data);
guint gatt_discover_primary(GAttrib *attrib, bt_uuid_t *uuid, gatt_cb_t func,
@@ -51,3 +53,7 @@ guint gatt_read_char_by_uuid(GAttrib *attrib, uint16_t start, uint16_t end,
guint gatt_exchange_mtu(GAttrib *attrib, uint16_t mtu, GAttribResultFunc func,
gpointer user_data);
+
+gboolean gatt_parse_record(const sdp_record_t *rec,
+ uuid_t *prim_uuid, uint16_t *psm,
+ uint16_t *start, uint16_t *end);
diff --git a/src/device.c b/src/device.c
index d567952..ecd1861 100644
--- a/src/device.c
+++ b/src/device.c
@@ -1367,6 +1367,53 @@ static void create_device_reply(struct btd_device *device, struct browse_req *re
g_dbus_send_message(req->conn, reply);
}
+static GSList *primary_from_record(struct btd_device *device, GSList *profiles)
+{
+ GSList *l, *prim_list = NULL;
+ char *att_uuid;
+ uuid_t proto_uuid;
+
+ sdp_uuid16_create(&proto_uuid, ATT_UUID);
+ att_uuid = bt_uuid2string(&proto_uuid);
+
+ for (l = profiles; l; l = l->next) {
+ const char *profile_uuid = l->data;
+ const sdp_record_t *rec;
+ struct att_primary *prim;
+ uint16_t start = 0, end = 0, psm = 0;
+ uuid_t prim_uuid;
+
+ rec = btd_device_get_record(device, profile_uuid);
+ if (!rec)
+ continue;
+
+ if (!record_has_uuid(rec, att_uuid))
+ continue;
+
+ if (!gatt_parse_record(rec, &prim_uuid, &psm, &start, &end))
+ continue;
+
+ prim = g_new0(struct att_primary, 1);
+ prim->start = start;
+ prim->end = end;
+ sdp_uuid2strn(&prim_uuid, prim->uuid, sizeof(prim->uuid));
+
+ prim_list = g_slist_append(prim_list, prim);
+ }
+
+ g_free(att_uuid);
+
+ return prim_list;
+}
+
+static void register_primary_services(DBusConnection *conn,
+ struct btd_device *device, GSList *prim_list)
+{
+ /* TODO: PSM is hardcoded */
+ attrib_client_register(conn, device, 31, NULL, prim_list);
+ device->primaries = g_slist_concat(device->primaries, prim_list);
+}
+
static void search_cb(sdp_list_t *recs, int err, gpointer user_data)
{
struct browse_req *req = user_data;
@@ -1396,9 +1443,16 @@ static void search_cb(sdp_list_t *recs, int err, gpointer user_data)
}
/* Probe matching drivers for services added */
- if (req->profiles_added)
+ if (req->profiles_added) {
+ GSList *list;
+
device_probe_drivers(device, req->profiles_added);
+ list = primary_from_record(device, req->profiles_added);
+ if (list)
+ register_primary_services(req->conn, device, list);
+ }
+
/* Remove drivers for services removed */
if (req->profiles_removed)
device_remove_drivers(device, req->profiles_removed);
--
1.7.4.1
^ permalink raw reply related
* [PATCH] Fix race condition on gatttool
From: Sheldon Demario @ 2011-04-11 17:57 UTC (permalink / raw)
To: linux-bluetooth; +Cc: Sheldon Demario
When the connect_cb() takes too long to be called the event_loop goes to idle
state and executes the callback too early
---
attrib/gatttool.c | 128 +++++++++++++++++++++++++---------------------------
1 files changed, 62 insertions(+), 66 deletions(-)
diff --git a/attrib/gatttool.c b/attrib/gatttool.c
index be91967..cf052db 100644
--- a/attrib/gatttool.c
+++ b/attrib/gatttool.c
@@ -63,6 +63,7 @@ static gboolean opt_char_write_req = FALSE;
static gboolean opt_interactive = FALSE;
static GMainLoop *event_loop;
static gboolean got_error = FALSE;
+static GSourceFunc operation;
struct characteristic_data {
GAttrib *attrib;
@@ -70,13 +71,68 @@ struct characteristic_data {
uint16_t end;
};
+static void events_handler(const uint8_t *pdu, uint16_t len, gpointer user_data)
+{
+ GAttrib *attrib = user_data;
+ uint8_t opdu[ATT_MAX_MTU];
+ uint16_t handle, i, olen = 0;
+
+ handle = att_get_u16(&pdu[1]);
+
+ switch (pdu[0]) {
+ case ATT_OP_HANDLE_NOTIFY:
+ g_print("Notification handle = 0x%04x value: ", handle);
+ break;
+ case ATT_OP_HANDLE_IND:
+ g_print("Indication handle = 0x%04x value: ", handle);
+ break;
+ default:
+ g_print("Invalid opcode\n");
+ return;
+ }
+
+ for (i = 3; i < len; i++)
+ g_print("%02x ", pdu[i]);
+
+ g_print("\n");
+
+ if (pdu[0] == ATT_OP_HANDLE_NOTIFY)
+ return;
+
+ olen = enc_confirmation(opdu, sizeof(opdu));
+
+ if (olen > 0)
+ g_attrib_send(attrib, 0, opdu[0], opdu, olen, NULL, NULL, NULL);
+}
+
+static gboolean listen_start(gpointer user_data)
+{
+ GAttrib *attrib = user_data;
+
+ g_attrib_register(attrib, ATT_OP_HANDLE_NOTIFY, events_handler,
+ attrib, NULL);
+ g_attrib_register(attrib, ATT_OP_HANDLE_IND, events_handler,
+ attrib, NULL);
+
+ return FALSE;
+}
+
static void connect_cb(GIOChannel *io, GError *err, gpointer user_data)
{
+ GAttrib *attrib;
+
if (err) {
g_printerr("%s\n", err->message);
got_error = TRUE;
g_main_loop_quit(event_loop);
}
+
+ attrib = g_attrib_new(io);
+
+ if (opt_listen)
+ g_idle_add(listen_start, attrib);
+
+ operation(attrib);
}
static void primary_all_cb(GSList *services, guint8 status, gpointer user_data)
@@ -120,52 +176,6 @@ done:
g_main_loop_quit(event_loop);
}
-static void events_handler(const uint8_t *pdu, uint16_t len, gpointer user_data)
-{
- GAttrib *attrib = user_data;
- uint8_t opdu[ATT_MAX_MTU];
- uint16_t handle, i, olen = 0;
-
- handle = att_get_u16(&pdu[1]);
-
- switch (pdu[0]) {
- case ATT_OP_HANDLE_NOTIFY:
- g_print("Notification handle = 0x%04x value: ", handle);
- break;
- case ATT_OP_HANDLE_IND:
- g_print("Indication handle = 0x%04x value: ", handle);
- break;
- default:
- g_print("Invalid opcode\n");
- return;
- }
-
- for (i = 3; i < len; i++)
- g_print("%02x ", pdu[i]);
-
- g_print("\n");
-
- if (pdu[0] == ATT_OP_HANDLE_NOTIFY)
- return;
-
- olen = enc_confirmation(opdu, sizeof(opdu));
-
- if (olen > 0)
- g_attrib_send(attrib, 0, opdu[0], opdu, olen, NULL, NULL, NULL);
-}
-
-static gboolean listen_start(gpointer user_data)
-{
- GAttrib *attrib = user_data;
-
- g_attrib_register(attrib, ATT_OP_HANDLE_NOTIFY, events_handler,
- attrib, NULL);
- g_attrib_register(attrib, ATT_OP_HANDLE_IND, events_handler,
- attrib, NULL);
-
- return FALSE;
-}
-
static gboolean primary(gpointer user_data)
{
GAttrib *attrib = user_data;
@@ -527,9 +537,7 @@ int main(int argc, char *argv[])
GOptionContext *context;
GOptionGroup *gatt_group, *params_group, *char_rw_group;
GError *gerr = NULL;
- GAttrib *attrib;
GIOChannel *chan;
- GSourceFunc callback;
opt_sec_level = g_strdup("low");
@@ -570,17 +578,17 @@ int main(int argc, char *argv[])
}
if (opt_primary)
- callback = primary;
+ operation = primary;
else if (opt_characteristics)
- callback = characteristics;
+ operation = characteristics;
else if (opt_char_read)
- callback = characteristics_read;
+ operation = characteristics_read;
else if (opt_char_write)
- callback = characteristics_write;
+ operation = characteristics_write;
else if (opt_char_write_req)
- callback = characteristics_write_req;
+ operation = characteristics_write_req;
else if (opt_char_desc)
- callback = characteristics_desc;
+ operation = characteristics_desc;
else {
gchar *help = g_option_context_get_help(context, TRUE, NULL);
g_print("%s\n", help);
@@ -596,24 +604,12 @@ int main(int argc, char *argv[])
goto done;
}
- attrib = g_attrib_new(chan);
- g_io_channel_unref(chan);
-
event_loop = g_main_loop_new(NULL, FALSE);
- if (opt_listen)
- g_idle_add(listen_start, attrib);
-
- g_idle_add(callback, attrib);
-
g_main_loop_run(event_loop);
- g_attrib_unregister_all(attrib);
-
g_main_loop_unref(event_loop);
- g_attrib_unref(attrib);
-
done:
g_option_context_free(context);
g_free(opt_src);
--
1.7.1
^ permalink raw reply related
* Re: Endless print of uhci_result_common: failed with status 440000
From: Zdenek Kabelac @ 2011-04-11 17:32 UTC (permalink / raw)
To: Alan Stern
Cc: USB list, Linux Kernel Mailing List, Thomas Gleixner,
linux-bluetooth
In-Reply-To: <BANLkTinfr5_9hw=296TXPu6_HZ=QEOVcig@mail.gmail.com>
2011/4/11 Zdenek Kabelac <zdenek.kabelac@gmail.com>:
> 2011/4/11 Alan Stern <stern@rowland.harvard.edu>:
>> On Mon, 11 Apr 2011, Zdenek Kabelac wrote:
>>
>>> Ok - add some more memory debug:
>>>
>>> [ 13.347268] usb 1-1: USB disconnect, device number 3
>>> [ 13.348113] btusb_bulk_complete: hci0 urb ffff8801367f6528 failed
>>> to resubmit (19)
>>> [ 13.349111] btusb_intr_complete: hci0 urb ffff8801367f6840 failed
>>> to resubmit (19)
>>> [ 13.349143] btusb_bulk_complete: hci0 urb ffff8801367fa630 failed
>>> to resubmit (19)
>>> [ 13.409856] general protection fault: 0000 [#1] PREEMPT SMP
>>> [ 13.413340] last sysfs file:
>>> /sys/devices/pci0000:00/0000:00:19.0/net/eth0/uevent
>>> [ 13.413340] CPU 0
>>> [ 13.413340] Modules linked in: ipt_REJECT xt_physdev xt_state
>>> iptable_filter ipt_MASQUERADE iptable_nat nf_nat nf_conntrack_ipv4
>>> nf_conntrack nf_defrag_ipv4 ip_tables x_tables dm_mirror
>>> dm_region_hash dm_log dm_mod snd_hda_codec_analog btusb bluetooth
>>> virtio_net kvm_intel kvm arc4 ecb crypto_blkcipher cryptomgr aead
>>> crypto_algapi iwl3945 iwl_legacy snd_hda_intel snd_hda_codec usbhid
>>> snd_seq snd_seq_device mac80211 hid iTCO_wdt iTCO_vendor_support
>>> snd_pcm psmouse i2c_i801 serio_raw cfg80211 thinkpad_acpi snd_timer
>>> snd e1000e soundcore snd_page_alloc nvram wmi evdev i915
>>> drm_kms_helper drm i2c_algo_bit i2c_core uinput autofs4 pcmcia
>>> uhci_hcd ehci_hcd sdhci_pci sdhci sr_mod mmc_core yenta_socket cdrom
>>> usbcore video backlight [last unloaded: scsi_wait_scan]
>>> [ 13.413340]
>>> [ 13.413340] Pid: 815, comm: bluetoothd Not tainted
>>> 2.6.39-rc2-00144-gca71856 #121 LENOVO 6464CTO/6464CTO
>>> [ 13.413340] RIP: 0010:[<ffffffff8109ae43>] [<ffffffff8109ae43>]
>>> module_put+0x33/0x1b0
>>> [ 13.413340] RSP: 0018:ffff8801389e1d68 EFLAGS: 00010296
>>> [ 13.413340] RAX: ffffffffa04a32a6 RBX: 6b6b6b6b6b6b6b6b RCX: 0000000000000000
>>> [ 13.413340] RDX: 0000000000000000 RSI: ffffffffa04a32a6 RDI: ffffffff8109ae43
>>> [ 13.413340] RBP: ffff8801389e1d98 R08: 0000000000000000 R09: 0000000000000000
>>> [ 13.413340] R10: 0000000000000000 R11: 0000000000000000 R12: ffff88013b028590
>>> [ 13.413340] R13: 00000000ffffffed R14: ffff8801390ac7b0 R15: 000000000000000a
>>> [ 13.413340] FS: 00007fe99d67d720(0000) GS:ffff88013ba00000(0000)
>>> knlGS:0000000000000000
>>> [ 13.413340] CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b
>>> [ 13.413340] CR2: 00007fe99d4902b0 CR3: 0000000134dea000 CR4: 00000000000006f0
>>> [ 13.413340] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
>>> [ 13.413340] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
>>> [ 13.413340] Process bluetoothd (pid: 815, threadinfo
>>> ffff8801389e0000, task ffff8801387d23a0)
>>> [ 13.413340] Stack:
>>> [ 13.413340] ffff88013b028000 ffff88013b028000 ffff88013b028590
>>> 00000000ffffffed
>>> [ 13.413340] ffff8801390ac7b0 000000000000000a ffff8801389e1de8
>>> ffffffffa04a32a6
>>> [ 13.413340] ffff8801389e1db8 ffffffff8124f11a ffff8801389e1dd8
>>> 00000000400448c9
>>> [ 13.413340] Call Trace:
>>> [ 13.413340] [<ffffffffa04a32a6>] hci_dev_open+0x96/0x3f0 [bluetooth]
>>> [ 13.413340] [<ffffffff8124f11a>] ? security_capable+0x2a/0x30
>>> [ 13.413340] [<ffffffffa04b0172>] hci_sock_ioctl+0x1e2/0x4b0 [bluetooth]
>>
>>> So - it looks like disabling BT in runtime is not enough to avoid problems ;)
>>>
>>> So I've blacklisted bluetooth & btusb - and made quite several
>>> suspend/resume cycles -
>>> and without a single problem.
>>>
>>> So I'll keep an eye on this - but so far complete deactivation of BT
>>> either in BIOS or modules blacklisting solves the problem of weird
>>> USB deadlocking.
>>
>> Clearly there's something going wrong in the Bluetooth drivers. You
>> should try posting some of this on the linux-bluetooth mailing list.
>
> I've created:
>
> https://bugzilla.kernel.org/show_bug.cgi?id=33062
>
> and I'm cc-ing linux-bluetooth.
>
In fact this Ooops might be related to:
http://marc.info/?l=linux-kernel&m=130207593728273&w=2
Zdenek
^ permalink raw reply
* Re: Endless print of uhci_result_common: failed with status 440000
From: Zdenek Kabelac @ 2011-04-11 17:24 UTC (permalink / raw)
To: Alan Stern
Cc: USB list, Linux Kernel Mailing List, Thomas Gleixner,
linux-bluetooth
In-Reply-To: <Pine.LNX.4.44L0.1104111217560.1975-100000@iolanthe.rowland.org>
2011/4/11 Alan Stern <stern@rowland.harvard.edu>:
> On Mon, 11 Apr 2011, Zdenek Kabelac wrote:
>
>> Ok - add some more memory debug:
>>
>> [ 13.347268] usb 1-1: USB disconnect, device number 3
>> [ 13.348113] btusb_bulk_complete: hci0 urb ffff8801367f6528 failed
>> to resubmit (19)
>> [ 13.349111] btusb_intr_complete: hci0 urb ffff8801367f6840 failed
>> to resubmit (19)
>> [ 13.349143] btusb_bulk_complete: hci0 urb ffff8801367fa630 failed
>> to resubmit (19)
>> [ 13.409856] general protection fault: 0000 [#1] PREEMPT SMP
>> [ 13.413340] last sysfs file:
>> /sys/devices/pci0000:00/0000:00:19.0/net/eth0/uevent
>> [ 13.413340] CPU 0
>> [ 13.413340] Modules linked in: ipt_REJECT xt_physdev xt_state
>> iptable_filter ipt_MASQUERADE iptable_nat nf_nat nf_conntrack_ipv4
>> nf_conntrack nf_defrag_ipv4 ip_tables x_tables dm_mirror
>> dm_region_hash dm_log dm_mod snd_hda_codec_analog btusb bluetooth
>> virtio_net kvm_intel kvm arc4 ecb crypto_blkcipher cryptomgr aead
>> crypto_algapi iwl3945 iwl_legacy snd_hda_intel snd_hda_codec usbhid
>> snd_seq snd_seq_device mac80211 hid iTCO_wdt iTCO_vendor_support
>> snd_pcm psmouse i2c_i801 serio_raw cfg80211 thinkpad_acpi snd_timer
>> snd e1000e soundcore snd_page_alloc nvram wmi evdev i915
>> drm_kms_helper drm i2c_algo_bit i2c_core uinput autofs4 pcmcia
>> uhci_hcd ehci_hcd sdhci_pci sdhci sr_mod mmc_core yenta_socket cdrom
>> usbcore video backlight [last unloaded: scsi_wait_scan]
>> [ 13.413340]
>> [ 13.413340] Pid: 815, comm: bluetoothd Not tainted
>> 2.6.39-rc2-00144-gca71856 #121 LENOVO 6464CTO/6464CTO
>> [ 13.413340] RIP: 0010:[<ffffffff8109ae43>] [<ffffffff8109ae43>]
>> module_put+0x33/0x1b0
>> [ 13.413340] RSP: 0018:ffff8801389e1d68 EFLAGS: 00010296
>> [ 13.413340] RAX: ffffffffa04a32a6 RBX: 6b6b6b6b6b6b6b6b RCX: 0000000000000000
>> [ 13.413340] RDX: 0000000000000000 RSI: ffffffffa04a32a6 RDI: ffffffff8109ae43
>> [ 13.413340] RBP: ffff8801389e1d98 R08: 0000000000000000 R09: 0000000000000000
>> [ 13.413340] R10: 0000000000000000 R11: 0000000000000000 R12: ffff88013b028590
>> [ 13.413340] R13: 00000000ffffffed R14: ffff8801390ac7b0 R15: 000000000000000a
>> [ 13.413340] FS: 00007fe99d67d720(0000) GS:ffff88013ba00000(0000)
>> knlGS:0000000000000000
>> [ 13.413340] CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b
>> [ 13.413340] CR2: 00007fe99d4902b0 CR3: 0000000134dea000 CR4: 00000000000006f0
>> [ 13.413340] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
>> [ 13.413340] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
>> [ 13.413340] Process bluetoothd (pid: 815, threadinfo
>> ffff8801389e0000, task ffff8801387d23a0)
>> [ 13.413340] Stack:
>> [ 13.413340] ffff88013b028000 ffff88013b028000 ffff88013b028590
>> 00000000ffffffed
>> [ 13.413340] ffff8801390ac7b0 000000000000000a ffff8801389e1de8
>> ffffffffa04a32a6
>> [ 13.413340] ffff8801389e1db8 ffffffff8124f11a ffff8801389e1dd8
>> 00000000400448c9
>> [ 13.413340] Call Trace:
>> [ 13.413340] [<ffffffffa04a32a6>] hci_dev_open+0x96/0x3f0 [bluetooth]
>> [ 13.413340] [<ffffffff8124f11a>] ? security_capable+0x2a/0x30
>> [ 13.413340] [<ffffffffa04b0172>] hci_sock_ioctl+0x1e2/0x4b0 [bluetooth]
>
>> So - it looks like disabling BT in runtime is not enough to avoid problems ;)
>>
>> So I've blacklisted bluetooth & btusb - and made quite several
>> suspend/resume cycles -
>> and without a single problem.
>>
>> So I'll keep an eye on this - but so far complete deactivation of BT
>> either in BIOS or modules blacklisting solves the problem of weird
>> USB deadlocking.
>
> Clearly there's something going wrong in the Bluetooth drivers. You
> should try posting some of this on the linux-bluetooth mailing list.
I've created:
https://bugzilla.kernel.org/show_bug.cgi?id=33062
and I'm cc-ing linux-bluetooth.
Zdenek
^ permalink raw reply
* Re: [RFC 1/2] Add Type property to Device
From: Claudio Takahasi @ 2011-04-11 17:18 UTC (permalink / raw)
To: Andre Dieb Martins, linux-bluetooth; +Cc: Gustavo F. Padovan
In-Reply-To: <20110411160058.GB2195@joana>
Hi guys,
On Mon, Apr 11, 2011 at 4:00 PM, Gustavo F. Padovan
<padovan@profusion.mobi> wrote:
> * Andre Dieb Martins <andre.dieb@signove.com> [2011-03-30 15:33:55 -0300]:
>
>> ---
>> doc/device-api.txt | 4 ++++
>> src/device.c | 18 ++++++++++++++++++
>> src/device.h | 2 ++
>> 3 files changed, 24 insertions(+), 0 deletions(-)
>>
>> diff --git a/doc/device-api.txt b/doc/device-api.txt
>> index d1feb18..a667296 100644
>> --- a/doc/device-api.txt
>> +++ b/doc/device-api.txt
>> @@ -130,6 +130,10 @@ Properties string Address [readonly]
>> Proposed icon name according to the freedesktop.org
>> icon naming specification.
>>
>> + string Type [readonly]
>> +
>> + Device type (BR/EDR, LE, BR/EDR/LE).
>> +
>> uint32 Class [readonly]
>>
>> The Bluetooth class of device of the remote device.
>> diff --git a/src/device.c b/src/device.c
>> index d567952..96683de 100644
>> --- a/src/device.c
>> +++ b/src/device.c
>> @@ -228,6 +228,20 @@ static void device_free(gpointer user_data)
>> g_free(device);
>> }
>>
>> +const char *devtype2str(device_type_t type)
>> +{
>> + switch (type) {
>> + case DEVICE_TYPE_BREDR:
>> + return "BR/EDR";
>> + case DEVICE_TYPE_LE:
>> + return "LE";
>> + case DEVICE_TYPE_DUALMODE:
>> + return "BR/EDR/LE";
>
> I think that use "Dual Mode" is much better here.
>
> --
> Gustavo F. Padovan
> http://profusion.mobi
> --
Marcel asked me to wait until we have a request from UI developers.
This property is more useful in the DeviceFound() signal, since it is
not clear how to guess the type of the device found. For the Adapter
and Device objects it is less relevant at the moment.
BR,
Claudio
^ permalink raw reply
* Re: 2.6.39-rc2 regression: X201s fails to resume b77dcf8460ae57d4eb9fd3633eb4f97b8fb20716
From: Vinicius Gomes @ 2011-04-11 16:59 UTC (permalink / raw)
To: Alan Cox; +Cc: Keith Packard, Thomas Gleixner, linux-kernel, linux-bluetooth
In-Reply-To: <20110411173409.1567679c@lxorguk.ukuu.org.uk>
Hi Gustavo,
On Mon, Apr 11, 2011 at 1:34 PM, Alan Cox <alan@lxorguk.ukuu.org.uk> wrote:
>> I took a shot at it and just sent a patch (also attached for convenience)
>> that should solve the problem.
>
> Well its reverting too much but its also looking pretty bogus to me
>
> - /* Stop timer, it might be running */
> - del_timer_sync(&hdev->cmd_timer);
> -
> if (!test_and_clear_bit(HCI_UP, &hdev->flags)) {
> hci_req_unlock(hdev);
> return 0;
>
> So you've now got a path where you leave the timer running and didn't
> before - not it appears one that is a good idea.
>
> Certainly not the kind of change that should be considered for a
> regression fix for an rc kernel. It's far too big a behavioural change to
> be safe.
Considering what was said and that this patch didn't hit your public tree yet,
I guess that this patch should be ignored.
Will send a proper fix soon. Thanks all.
>
> Alan
>
Cheers,
--
Vinicius
^ permalink raw reply
* Re: 2.6.39-rc2 regression: X201s fails to resume b77dcf8460ae57d4eb9fd3633eb4f97b8fb20716
From: Alan Cox @ 2011-04-11 16:34 UTC (permalink / raw)
To: Vinicius Costa Gomes
Cc: Keith Packard, Thomas Gleixner, linux-kernel, linux-bluetooth
In-Reply-To: <20110409000857.GB25581@piper>
> I took a shot at it and just sent a patch (also attached for convenience)
> that should solve the problem.
Well its reverting too much but its also looking pretty bogus to me
- /* Stop timer, it might be running */
- del_timer_sync(&hdev->cmd_timer);
-
if (!test_and_clear_bit(HCI_UP, &hdev->flags)) {
hci_req_unlock(hdev);
return 0;
So you've now got a path where you leave the timer running and didn't
before - not it appears one that is a good idea.
Certainly not the kind of change that should be considered for a
regression fix for an rc kernel. It's far too big a behavioural change to
be safe.
Alan
^ permalink raw reply
* Re: 2.6.39-rc2 regression: X201s fails to resume b77dcf8460ae57d4eb9fd3633eb4f97b8fb20716
From: Thomas Gleixner @ 2011-04-11 16:13 UTC (permalink / raw)
To: Gustavo F. Padovan
Cc: Keith Packard, Vinicius Costa Gomes, linux-kernel,
linux-bluetooth
In-Reply-To: <20110411155826.GA2195@joana>
On Mon, 11 Apr 2011, Gustavo F. Padovan wrote:
> * Keith Packard <keithp@keithp.com> [2011-04-08 19:03:25 -0700]:
>
> > On Fri, 8 Apr 2011 21:08:57 -0300, Vinicius Costa Gomes <vinicius.gomes@openbossa.org> wrote:
> >
> > > I took a shot at it and just sent a patch (also attached for convenience)
> > > that should solve the problem.
> >
> > Thanks much! I applied this to -rc2 and it appears to work fine in some
> > brief testing (a dozen suspend/resume cycles)
> >
> > > Reported-by: Keith Packard <keithp@keithp.com>
> > > Signed-off-by: Vinicius Costa Gomes <vinicius.gomes@openbossa.org>
> >
> > Tested-by: Keith Packard <keithp@keithp.com>
>
> I applied the patch to bluetooth-2.6. Thank you all.
Sigh. Is actually anyone trying to read what I wrote ?
^ permalink raw reply
* Re: 2.6.39-rc2 regression: X201s fails to resume b77dcf8460ae57d4eb9fd3633eb4f97b8fb20716
From: Thomas Gleixner @ 2011-04-11 16:12 UTC (permalink / raw)
To: Vinicius Costa Gomes; +Cc: Keith Packard, linux-kernel, linux-bluetooth
In-Reply-To: <20110409000857.GB25581@piper>
On Fri, 8 Apr 2011, Vinicius Costa Gomes wrote:
> Hi Keith,
>
> On 16:13 Fri 08 Apr, Keith Packard wrote:
> > On Fri, 8 Apr 2011 23:44:51 +0200 (CEST), Thomas Gleixner <tglx@linutronix.de> wrote:
> >
> > > Can the bluetooth folks please have a look at that ASAP? The obvious
> > > fast fix for Linus tree is to revert the second hunk for now, but this
> > > needs to be fixed proper.
> >
> > Who will submit this patch? I'd rather have your name on it so that
> > people come complain at you...
>
> I took a shot at it and just sent a patch (also attached for convenience)
> that should solve the problem.
Aaarg. No. That patch reverts both hunks.
--- a/net/bluetooth/hci_core.c
+++ b/net/bluetooth/hci_core.c
@@ -586,9 +586,6 @@ static int hci_dev_do_close(struct hci_dev *hdev)
hci_req_cancel(hdev, ENODEV);
hci_req_lock(hdev);
- /* Stop timer, it might be running */
- del_timer_sync(&hdev->cmd_timer);
-
if (!test_and_clear_bit(HCI_UP, &hdev->flags)) {
hci_req_unlock(hdev);
return 0;
As I said before you need that first hunk to stay for the case where
there is no device up and you return via the !HCI_UP check. You just
moved back to the state before as the stupid timer is active for
whatever reason even when HCI_UP is not set.
@@ -618,6 +615,9 @@ static int hci_dev_do_close(struct hci_dev *hdev)
clear_bit(HCI_INIT, &hdev->flags);
}
+ /* Stop timer, it might be running */
+ del_timer_sync(&hdev->cmd_timer);
+
/* Kill cmd task */
tasklet_kill(&hdev->cmd_task);
^ permalink raw reply
* Re: [RFC 1/2] Add Type property to Device
From: Gustavo F. Padovan @ 2011-04-11 16:00 UTC (permalink / raw)
To: Andre Dieb Martins; +Cc: linux-bluetooth
In-Reply-To: <1301510036-17282-1-git-send-email-andre.dieb@signove.com>
* Andre Dieb Martins <andre.dieb@signove.com> [2011-03-30 15:33:55 -0300]:
> ---
> doc/device-api.txt | 4 ++++
> src/device.c | 18 ++++++++++++++++++
> src/device.h | 2 ++
> 3 files changed, 24 insertions(+), 0 deletions(-)
>
> diff --git a/doc/device-api.txt b/doc/device-api.txt
> index d1feb18..a667296 100644
> --- a/doc/device-api.txt
> +++ b/doc/device-api.txt
> @@ -130,6 +130,10 @@ Properties string Address [readonly]
> Proposed icon name according to the freedesktop.org
> icon naming specification.
>
> + string Type [readonly]
> +
> + Device type (BR/EDR, LE, BR/EDR/LE).
> +
> uint32 Class [readonly]
>
> The Bluetooth class of device of the remote device.
> diff --git a/src/device.c b/src/device.c
> index d567952..96683de 100644
> --- a/src/device.c
> +++ b/src/device.c
> @@ -228,6 +228,20 @@ static void device_free(gpointer user_data)
> g_free(device);
> }
>
> +const char *devtype2str(device_type_t type)
> +{
> + switch (type) {
> + case DEVICE_TYPE_BREDR:
> + return "BR/EDR";
> + case DEVICE_TYPE_LE:
> + return "LE";
> + case DEVICE_TYPE_DUALMODE:
> + return "BR/EDR/LE";
I think that use "Dual Mode" is much better here.
--
Gustavo F. Padovan
http://profusion.mobi
^ permalink raw reply
* Re: 2.6.39-rc2 regression: X201s fails to resume b77dcf8460ae57d4eb9fd3633eb4f97b8fb20716
From: Gustavo F. Padovan @ 2011-04-11 15:58 UTC (permalink / raw)
To: Keith Packard
Cc: Vinicius Costa Gomes, Thomas Gleixner, linux-kernel,
linux-bluetooth
In-Reply-To: <yunipuouqoi.fsf@aiko.keithp.com>
* Keith Packard <keithp@keithp.com> [2011-04-08 19:03:25 -0700]:
> On Fri, 8 Apr 2011 21:08:57 -0300, Vinicius Costa Gomes <vinicius.gomes@openbossa.org> wrote:
>
> > I took a shot at it and just sent a patch (also attached for convenience)
> > that should solve the problem.
>
> Thanks much! I applied this to -rc2 and it appears to work fine in some
> brief testing (a dozen suspend/resume cycles)
>
> > Reported-by: Keith Packard <keithp@keithp.com>
> > Signed-off-by: Vinicius Costa Gomes <vinicius.gomes@openbossa.org>
>
> Tested-by: Keith Packard <keithp@keithp.com>
I applied the patch to bluetooth-2.6. Thank you all.
--
Gustavo F. Padovan
http://profusion.mobi
^ permalink raw reply
* Re: [RFC 1/2] Add Type property to Device
From: Elvis Pfutzenreuter @ 2011-04-11 13:08 UTC (permalink / raw)
To: Claudio Takahasi, linux-bluetooth
In-Reply-To: <AANLkTinpZ4OsJMVjpMX=VYUfzG=sgTVk9uUUGFW0t=4Q@mail.gmail.com>
2011/3/31 Claudio Takahasi <claudio.takahasi@openbossa.org>
>
> Hi Marcel/Johan/Luiz,
>
> We need opinions for this change...
>
> Why this information is needed: Appearance characteristic is not
> available in the advertising. Currently, BlueZ implements interleaved
> discovery: 5.12sec inquiring + 5.12sec scanning.
> Found devices are reported through the DeviceFound() signal. The user
> space needs to check the "Broadcaster" property inside the DeviceFound
> signal to check if the device is Basic Rate or LE, which is not
> acceptable(in my opinion). We need a meaningful property to
> distinguish LE devices.
>
> Before we push these patches upstream we need to define which
> information it exposes: Operational Mode or host/controller
> capability?
>
> My opinion:
> 1. for the Adapter it should represent the operational mode, a
> controller can support LE, but the host can disable it. Setting
> EnableLE = false(main.conf) should "disable" LE functionalities.
> 2. for DeviceFound(), the UI needs this info only to distinguish LE
> devices. In my opinion UUIDs and Broadcaster properties are not
> enough/appropriated for this purpose. "Qualified" devices will not
> enable inquiry scan and advertising at same time. Our main target is
> to connect to LE only devices. "BR/EDR/LE" can be confusing in this
> context. Suggestions here?
> 3. for the Device, I am not sure if we need to expose this information
> to the users, appearance characteristic is mandatory, if a Device
> "object" exists in the system the appearance value will be
> available(it will be retrieved after discovery primary services)
>
> Comments?
Any news on this?
>
> Andre:
> You need to check the adapter features, old adapters doesn't support EDR.
Andre is on vacation (lucky guy), so I will do the fixes once we have
settled the other questions.
>
> Claudio.
>
> On Wed, Mar 30, 2011 at 6:33 PM, Andre Dieb Martins
> <andre.dieb@signove.com> wrote:
> > ---
> > doc/device-api.txt | 4 ++++
> > src/device.c | 18 ++++++++++++++++++
> > src/device.h | 2 ++
> > 3 files changed, 24 insertions(+), 0 deletions(-)
> >
> > diff --git a/doc/device-api.txt b/doc/device-api.txt
> > index d1feb18..a667296 100644
> > --- a/doc/device-api.txt
> > +++ b/doc/device-api.txt
> > @@ -130,6 +130,10 @@ Properties string Address [readonly]
> > Proposed icon name according to the freedesktop.org
> > icon naming specification.
> >
> > + string Type [readonly]
> > +
> > + Device type (BR/EDR, LE, BR/EDR/LE).
> > +
> > uint32 Class [readonly]
> >
> > The Bluetooth class of device of the remote device.
> > diff --git a/src/device.c b/src/device.c
> > index d567952..96683de 100644
> > --- a/src/device.c
> > +++ b/src/device.c
> > @@ -228,6 +228,20 @@ static void device_free(gpointer user_data)
> > g_free(device);
> > }
> >
> > +const char *devtype2str(device_type_t type)
>
> If the plan is to use the same type(device_type_t) for devices and
> adapters we should rename this type.
>
>
> > +{
> > + switch (type) {
> > + case DEVICE_TYPE_BREDR:
> > + return "BR/EDR";
> > + case DEVICE_TYPE_LE:
> > + return "LE";
> > + case DEVICE_TYPE_DUALMODE:
> > + return "BR/EDR/LE";
> > + default:
> > + return "Unknown";
> > + }
> > +}
> > +
> > gboolean device_is_paired(struct btd_device *device)
> > {
> > return device->paired;
> > @@ -302,6 +316,10 @@ static DBusMessage *get_properties(DBusConnection *conn,
> > DBUS_TYPE_STRING, &icon);
> > }
> >
> > + /* Type */
> > + ptr = devtype2str(device->type);
> > + dict_append_entry(&dict, "Type", DBUS_TYPE_STRING, &ptr);
> > +
> > /* Paired */
> > boolean = device_is_paired(device);
> > dict_append_entry(&dict, "Paired", DBUS_TYPE_BOOLEAN, &boolean);
> > diff --git a/src/device.h b/src/device.h
> > index 3ce212b..b385070 100644
> > --- a/src/device.h
> > +++ b/src/device.h
> > @@ -41,6 +41,8 @@ typedef enum {
> > DEVICE_TYPE_DUALMODE
> > } device_type_t;
> >
> > +const char *devtype2str(device_type_t type);
> > +
> > struct btd_device *device_create(DBusConnection *conn,
> > struct btd_adapter *adapter,
> > const gchar *address, device_type_t type);
> > --
> > 1.7.1
> >
> > --
> > To unsubscribe from this list: send the line "unsubscribe linux-bluetooth" in
> > the body of a message to majordomo@vger.kernel.org
> > More majordomo info at http://vger.kernel.org/majordomo-info.html
> >
> --
> 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: Bug report in Obex code
From: Slawomir Bochenski @ 2011-04-11 11:42 UTC (permalink / raw)
To: Claudiu Coman; +Cc: linux-bluetooth
In-Reply-To: <BANLkTikULKr_9PjxdxFDRoHQF04xLDdzBg@mail.gmail.com>
On Mon, Apr 11, 2011 at 12:56 AM, Claudiu Coman <claud.coman@gmail.com> wrote:
> Hello,
>
> While doing some documentation for my GSOC application, I found a small
> bug in the Obex code, in src/obex.c, function "obex_write_stream".
> There's the declaration:
> "uint8_t hi;"
> If the "if" statement body between lines 640-648 is executed, after the jump
> to the "add_header" tag, the switch statement will test an
> uninitialized variable.
> At first I thought about sending a patch myself, but I don't know what value
> the header index variable should be initialized with.
>
> Cheers,
> Claudiu
> --
> 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
>
In this case, I'd say that for a quick fix setting it to OBEX_HDR_BODY will do.
However I believe that this if block doesn't actually do anything now. Does it?
I think it was needed for old folder listing support (introduced in
commit c42eff92a9c2c177f788dd1ec429250e64f69a78) when the ftp plugin
was using os->buf directly. It doesn't seem that anything uses this
approach any more. Also not a single piece of code using os->finished
(this was for some old PBAP version). I think we can get rid of this
code. What do you think, guys?
--
Slawomir Bochenski
^ permalink raw reply
* Bug report in Obex code
From: Claudiu Coman @ 2011-04-10 22:56 UTC (permalink / raw)
To: linux-bluetooth
Hello,
While doing some documentation for my GSOC application, I found a small
bug in the Obex code, in src/obex.c, function "obex_write_stream".
There's the declaration:
"uint8_t hi;"
If the "if" statement body between lines 640-648 is executed, after the jump
to the "add_header" tag, the switch statement will test an
uninitialized variable.
At first I thought about sending a patch myself, but I don't know what value
the header index variable should be initialized with.
Cheers,
Claudiu
^ permalink raw reply
* [PATCH 4/4] Remove 16 byte limit for PIN codes returned by agents
From: David Herrmann @ 2011-04-10 17:11 UTC (permalink / raw)
To: linux-bluetooth; +Cc: johan.hedberg, hadess, dforsi, David Herrmann
In-Reply-To: <1302455477-27664-1-git-send-email-dh.herrmann@googlemail.com>
Agents can now return PIN codes longer than 16 characters. The
pin parser automatically truncates all PINs to 16 characters, but
allows hexadecimal PINs to be longer than 16 characters because
each two hexdecimal encoded bytes are parsed into one output byte.
---
src/agent.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/src/agent.c b/src/agent.c
index f87f253..40495bf 100644
--- a/src/agent.c
+++ b/src/agent.c
@@ -403,7 +403,7 @@ static void pincode_reply(DBusPendingCall *call, void *user_data)
len = strlen(pin);
dbus_error_init(&err);
- if (len > 16 || len < 1) {
+ if (len < 1) {
error("Invalid PIN length (%zu) from agent", len);
dbus_set_error_const(&err, "org.bluez.Error.InvalidArgs",
"Invalid passkey length");
--
1.7.4.4
^ permalink raw reply related
* [PATCH 3/4] Parse pin codes starting with '$' as hexadecimal encoded strings
From: David Herrmann @ 2011-04-10 17:11 UTC (permalink / raw)
To: linux-bluetooth; +Cc: johan.hedberg, hadess, dforsi, David Herrmann
In-Reply-To: <1302455477-27664-1-git-send-email-dh.herrmann@googlemail.com>
If a pin code is retrieved from an agent and the first character is
a dollar sign '$', then the pin is decoded as following:
- The first character (dollar sign) is stripped from the pin
- The rest is parsed as hexadecimal numbers, where each two characters
will be converted into a one byte integer. If an odd number of
characters follows, then the last character is stripped. Empty
pins are valid. Parser is case insensitive.
Pins not starting with '$' are parsed as usual.
For instance:
pin: $0A3e005067
is decoded into a 5 byte pin:
decoded: 0x0a 0x3e 0x00 0x50 0x67
---
src/event.c | 43 ++++++++++++++++++++++++++++++++++++++++++-
1 files changed, 42 insertions(+), 1 deletions(-)
diff --git a/src/event.c b/src/event.c
index 248fb78..f2fc688 100644
--- a/src/event.c
+++ b/src/event.c
@@ -101,12 +101,52 @@ static gboolean get_adapter_and_device(bdaddr_t *src, bdaddr_t *dst,
*
*****************************************************************/
+static char hex2dec(char c)
+{
+ if (c >= '0' && c <= '9')
+ return c - '0';
+ else if (c >= 'A' && c <= 'F')
+ return c - 'A' + 10;
+ else if (c >= 'a' && c <= 'f')
+ return c - 'a' + 10;
+ else
+ return 0;
+}
+
+static size_t decode_hex(const char *pin, char *out)
+{
+ size_t i;
+
+ for (i = 0; i < 16 && pin[i * 2] && pin[i * 2 + 1]; ++i)
+ out[i] = hex2dec(pin[i * 2]) * 16 + hex2dec(pin[i * 2 + 1]);
+ return i;
+}
+
+static size_t decode_pin(const char *pin, char *out)
+{
+ size_t len;
+
+ if (!pin) {
+ return 0;
+ }
+ else if (pin[0] == '$') {
+ len = decode_hex(&pin[1], out);
+ }
+ else {
+ len = strnlen(pin, 16);
+ memcpy(out, pin, len);
+ }
+ return len;
+}
+
static void pincode_cb(struct agent *agent, DBusError *derr,
const char *pincode, struct btd_device *device)
{
struct btd_adapter *adapter = device_get_adapter(device);
bdaddr_t sba, dba;
int err;
+ size_t len;
+ char rawpin[16];
device_get_address(device, &dba);
@@ -117,7 +157,8 @@ static void pincode_cb(struct agent *agent, DBusError *derr,
return;
}
- err = btd_adapter_pincode_reply(adapter, &dba, pincode, pincode ? strlen(pincode) : 0);
+ len = decode_pin(pincode, rawpin);
+ err = btd_adapter_pincode_reply(adapter, &dba, rawpin, len);
if (err < 0)
goto fail;
--
1.7.4.4
^ permalink raw reply related
* [PATCH 2/4] Make adapter API accept binary pincodes
From: David Herrmann @ 2011-04-10 17:11 UTC (permalink / raw)
To: linux-bluetooth; +Cc: johan.hedberg, hadess, dforsi, David Herrmann
In-Reply-To: <1302455477-27664-1-git-send-email-dh.herrmann@googlemail.com>
Add pin-length argument to adapter API to allow passing binary pins
containing \0 characters to the hci handler.
---
src/adapter.c | 4 ++--
src/adapter.h | 2 +-
src/event.c | 6 +++---
3 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/src/adapter.c b/src/adapter.c
index 83f3217..14516ac 100644
--- a/src/adapter.c
+++ b/src/adapter.c
@@ -3701,9 +3701,9 @@ int btd_adapter_remove_bonding(struct btd_adapter *adapter, bdaddr_t *bdaddr)
}
int btd_adapter_pincode_reply(struct btd_adapter *adapter, bdaddr_t *bdaddr,
- const char *pin)
+ const char *pin, size_t pinlen)
{
- return adapter_ops->pincode_reply(adapter->dev_id, bdaddr, pin, pin ? strlen(pin) : 0);
+ return adapter_ops->pincode_reply(adapter->dev_id, bdaddr, pin, pinlen);
}
int btd_adapter_confirm_reply(struct btd_adapter *adapter, bdaddr_t *bdaddr,
diff --git a/src/adapter.h b/src/adapter.h
index fd2fc12..b507506 100644
--- a/src/adapter.h
+++ b/src/adapter.h
@@ -273,7 +273,7 @@ int btd_adapter_disconnect_device(struct btd_adapter *adapter,
int btd_adapter_remove_bonding(struct btd_adapter *adapter, bdaddr_t *bdaddr);
int btd_adapter_pincode_reply(struct btd_adapter *adapter, bdaddr_t *bdaddr,
- const char *pin);
+ const char *pin, size_t pinlen);
int btd_adapter_confirm_reply(struct btd_adapter *adapter, bdaddr_t *bdaddr,
gboolean success);
int btd_adapter_passkey_reply(struct btd_adapter *adapter, bdaddr_t *bdaddr,
diff --git a/src/event.c b/src/event.c
index 4ca1be5..248fb78 100644
--- a/src/event.c
+++ b/src/event.c
@@ -111,13 +111,13 @@ static void pincode_cb(struct agent *agent, DBusError *derr,
device_get_address(device, &dba);
if (derr) {
- err = btd_adapter_pincode_reply(adapter, &dba, NULL);
+ err = btd_adapter_pincode_reply(adapter, &dba, NULL, 0);
if (err < 0)
goto fail;
return;
}
- err = btd_adapter_pincode_reply(adapter, &dba, pincode);
+ err = btd_adapter_pincode_reply(adapter, &dba, pincode, pincode ? strlen(pincode) : 0);
if (err < 0)
goto fail;
@@ -142,7 +142,7 @@ int btd_event_request_pin(bdaddr_t *sba, bdaddr_t *dba)
memset(pin, 0, sizeof(pin));
pinlen = read_pin_code(sba, dba, pin);
if (pinlen > 0) {
- btd_adapter_pincode_reply(adapter, dba, pin);
+ btd_adapter_pincode_reply(adapter, dba, pin, pinlen);
return 0;
}
--
1.7.4.4
^ permalink raw reply related
* [PATCH 1/4] Add length argument to hci pincode reply
From: David Herrmann @ 2011-04-10 17:11 UTC (permalink / raw)
To: linux-bluetooth; +Cc: johan.hedberg, hadess, dforsi, David Herrmann
In-Reply-To: <1302455477-27664-1-git-send-email-dh.herrmann@googlemail.com>
This adds a new "length" argument to the hci pincode reply to allow
sending binary pins including \0 characters.
---
plugins/hciops.c | 9 ++++-----
plugins/mgmtops.c | 14 ++++++--------
src/adapter.c | 2 +-
src/adapter.h | 2 +-
4 files changed, 12 insertions(+), 15 deletions(-)
diff --git a/plugins/hciops.c b/plugins/hciops.c
index 93f6f21..afac330 100644
--- a/plugins/hciops.c
+++ b/plugins/hciops.c
@@ -3296,7 +3296,7 @@ static int hciops_remove_bonding(int index, bdaddr_t *bdaddr)
return 0;
}
-static int hciops_pincode_reply(int index, bdaddr_t *bdaddr, const char *pin)
+static int hciops_pincode_reply(int index, bdaddr_t *bdaddr, const char *pin, size_t pinlen)
{
struct dev_info *dev = &devs[index];
char addr[18];
@@ -3307,14 +3307,13 @@ static int hciops_pincode_reply(int index, bdaddr_t *bdaddr, const char *pin)
if (pin) {
pin_code_reply_cp pr;
- size_t len = strlen(pin);
- dev->pin_length = len;
+ dev->pin_length = pinlen;
memset(&pr, 0, sizeof(pr));
bacpy(&pr.bdaddr, bdaddr);
- memcpy(pr.pin_code, pin, len);
- pr.pin_len = len;
+ memcpy(pr.pin_code, pin, pinlen);
+ pr.pin_len = pinlen;
err = hci_send_cmd(dev->sk, OGF_LINK_CTL,
OCF_PIN_CODE_REPLY,
PIN_CODE_REPLY_CP_SIZE, &pr);
diff --git a/plugins/mgmtops.c b/plugins/mgmtops.c
index 042afc5..d03a29d 100644
--- a/plugins/mgmtops.c
+++ b/plugins/mgmtops.c
@@ -493,7 +493,7 @@ static void mgmt_connect_failed(int sk, uint16_t index, void *buf, size_t len)
btd_event_bonding_complete(&info->bdaddr, &ev->bdaddr, ev->status);
}
-static int mgmt_pincode_reply(int index, bdaddr_t *bdaddr, const char *pin)
+static int mgmt_pincode_reply(int index, bdaddr_t *bdaddr, const char *pin, size_t pinlen)
{
char buf[MGMT_HDR_SIZE + sizeof(struct mgmt_cp_pin_code_reply)];
struct mgmt_hdr *hdr = (void *) buf;
@@ -501,7 +501,7 @@ static int mgmt_pincode_reply(int index, bdaddr_t *bdaddr, const char *pin)
char addr[18];
ba2str(bdaddr, addr);
- DBG("index %d addr %s pin %s", index, addr, pin ? pin : "<none>");
+ DBG("index %d addr %s pinlen %lu", index, addr, pinlen);
memset(buf, 0, sizeof(buf));
@@ -518,10 +518,8 @@ static int mgmt_pincode_reply(int index, bdaddr_t *bdaddr, const char *pin)
buf_len = sizeof(*hdr) + sizeof(*cp);
} else {
struct mgmt_cp_pin_code_reply *cp;
- size_t pin_len;
- pin_len = strlen(pin);
- if (pin_len > 16)
+ if (pinlen > 16)
return -EINVAL;
hdr->opcode = htobs(MGMT_OP_PIN_CODE_REPLY);
@@ -530,8 +528,8 @@ static int mgmt_pincode_reply(int index, bdaddr_t *bdaddr, const char *pin)
cp = (void *) &buf[sizeof(*hdr)];
bacpy(&cp->bdaddr, bdaddr);
- cp->pin_len = pin_len;
- memcpy(cp->pin_code, pin, pin_len);
+ cp->pin_len = pinlen;
+ memcpy(cp->pin_code, pin, pinlen);
buf_len = sizeof(*hdr) + sizeof(*cp);
}
@@ -568,7 +566,7 @@ static void mgmt_pin_code_request(int sk, uint16_t index, void *buf, size_t len)
err = btd_event_request_pin(&info->bdaddr, &ev->bdaddr);
if (err < 0) {
error("btd_event_request_pin: %s", strerror(-err));
- mgmt_pincode_reply(index, &ev->bdaddr, NULL);
+ mgmt_pincode_reply(index, &ev->bdaddr, NULL, 0);
}
}
diff --git a/src/adapter.c b/src/adapter.c
index c400bfd..83f3217 100644
--- a/src/adapter.c
+++ b/src/adapter.c
@@ -3703,7 +3703,7 @@ int btd_adapter_remove_bonding(struct btd_adapter *adapter, bdaddr_t *bdaddr)
int btd_adapter_pincode_reply(struct btd_adapter *adapter, bdaddr_t *bdaddr,
const char *pin)
{
- return adapter_ops->pincode_reply(adapter->dev_id, bdaddr, pin);
+ return adapter_ops->pincode_reply(adapter->dev_id, bdaddr, pin, pin ? strlen(pin) : 0);
}
int btd_adapter_confirm_reply(struct btd_adapter *adapter, bdaddr_t *bdaddr,
diff --git a/src/adapter.h b/src/adapter.h
index 308af75..fd2fc12 100644
--- a/src/adapter.h
+++ b/src/adapter.h
@@ -221,7 +221,7 @@ struct btd_adapter_ops {
int (*read_local_features) (int index, uint8_t *features);
int (*disconnect) (int index, bdaddr_t *bdaddr);
int (*remove_bonding) (int index, bdaddr_t *bdaddr);
- int (*pincode_reply) (int index, bdaddr_t *bdaddr, const char *pin);
+ int (*pincode_reply) (int index, bdaddr_t *bdaddr, const char *pin, size_t pinlen);
int (*confirm_reply) (int index, bdaddr_t *bdaddr, gboolean success);
int (*passkey_reply) (int index, bdaddr_t *bdaddr, uint32_t passkey);
int (*enable_le) (int index);
--
1.7.4.4
^ permalink raw reply related
* [RFC][PATCH 0/4] Allow hexadecimal encoded pins
From: David Herrmann @ 2011-04-10 17:11 UTC (permalink / raw)
To: linux-bluetooth; +Cc: johan.hedberg, hadess, dforsi, David Herrmann
This patch series adds support for hexadecimal encoded pins. This is
no final patch and I would be glad to get some feedback.
This patch series solves the problem that the current bluez implementation
does not allow binary PINs that contain ASCII \0 characters. This is needed
for several devices that take bluetooth addresses as PINs. I had the
following ideas to implement binary pins:
- Hard coding binary pins into bluetoothd by detecting the device with
PnP VID/PID information as suggested by Marcel Holtmann.
However, this is not possible (as noted by Bastien Nocera) because
devices may refuse to offer SDP information for unpaired hosts.
Furthermore, SDP records are retrieved after pairing with the remote
device unless they're cached.
- Adding a new dbus agent interface that returns pins as byte-arrays
instead of 0-terminated strings. However, this either breaks backward-
compatibility or needs _huge_ additions to the dbus interface.
- Adding escape-sequences to pins or special pin parsing. This does break
backward-compatibility but may be implemented in a way that reduces
problems to a minimum.
I implemented the first approach a week ago as discussed on the mailing list
which turned out to be not appropriate. The second approach is probably the
cleanest one but requires huge dbus API additions. This patch series
implements the third approach. See patch 3/4 for details on the suggested
PIN encoding.
Pin encoding with the dollar sign is just a temporary approach which makes
the implementation quite easy and shows the idea of this patch. However,
the encoding is of course open for discussion.
Binary pin support is inspired by getting Nintendo Wiimote pairing support.
To test wiimote pairing with this patch series, do the following:
- assume the local bdaddr is: 01:23:45:67:89:ab
and the wiimote bdaddr is: ba:98:76:54:32:10
- Pairing with red-sync button, use pin: $ab8967452301 (host addr. backwards)
- Pairing with 1+2 buttons, use pin: $1032547698ba (wiimote addr backwards)
Automatic reconnection is only enabled in the wiimote when synced with the
red-sync button. The 1+2 button method is only for temporary connections.
Regards
David
^ permalink raw reply
* [PATCH] Remove unnecessary code from pin handler
From: David Herrmann @ 2011-04-10 15:48 UTC (permalink / raw)
To: linux-bluetooth; +Cc: johan.hedberg, David Herrmann
The source address is not used inside the pin handler and, thus,
can be skipped.
---
src/event.c | 4 +---
1 files changed, 1 insertions(+), 3 deletions(-)
diff --git a/src/event.c b/src/event.c
index 4ca1be5..5373e33 100644
--- a/src/event.c
+++ b/src/event.c
@@ -105,7 +105,7 @@ static void pincode_cb(struct agent *agent, DBusError *derr,
const char *pincode, struct btd_device *device)
{
struct btd_adapter *adapter = device_get_adapter(device);
- bdaddr_t sba, dba;
+ bdaddr_t dba;
int err;
device_get_address(device, &dba);
@@ -121,8 +121,6 @@ static void pincode_cb(struct agent *agent, DBusError *derr,
if (err < 0)
goto fail;
- adapter_get_address(adapter, &sba);
-
return;
fail:
--
1.7.4.4
^ permalink raw reply related
* Re: [PATCH v2] Add sap_disconnect_ind interface for sap-sim drivers
From: Johan Hedberg @ 2011-04-09 18:12 UTC (permalink / raw)
To: Waldemar.Rymarkiewicz; +Cc: linux-bluetooth
In-Reply-To: <99B09243E1A5DA4898CDD8B7001114481085FBEEE1@EXMB04.eu.tieto.com>
Hi Waldek,
On Tue, Apr 05, 2011, Waldemar.Rymarkiewicz@tieto.com wrote:
> >> The original idea was to have Disconnect(type) method in
> >server.c, but
> >> finally, in a discussion, we came to the conclusion that the
> >immediate
> >> disconnect should not be used by user. Driver should handle this if
> >> it's needed.
> >>
> >> So, sap-api.txt stays unchanged, and dummy-driver is changed to be
> >> able to pass some of PTS tests.
> >
> >Ok, sounds fine to me.
>
> Are you going to push upstram this patch ?
It's pushed upstream now. Sorry for the delay.
Johan
^ permalink raw reply
* Re: [PATCH] Add temporary workaround to skip wrong OMTU for basic rate
From: Johan Hedberg @ 2011-04-09 17:49 UTC (permalink / raw)
To: Claudio Takahasi; +Cc: linux-bluetooth
In-Reply-To: <1302197508-893-1-git-send-email-claudio.takahasi@openbossa.org>
Hi Claudio,
On Thu, Apr 07, 2011, Claudio Takahasi wrote:
> This patch is required until MTU kernel patch is not integrated. Kernel
> is returning zero for basic rate OMTU.
> ---
> attrib/gattrib.c | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
Pushed upstream with a minor tweak to the commit message: this can't
really be considered so temporary if there are kernels out there that
return the wrong value. In that case we'll need to keep the workaround
for quite some time.
Johan
^ permalink raw reply
* Re: [PATCH] Fix setting of mode after discovery times out.
From: Johan Hedberg @ 2011-04-09 17:35 UTC (permalink / raw)
To: Jaikumar Ganesh; +Cc: linux-bluetooth
In-Reply-To: <1302050692-24497-1-git-send-email-jaikumar@google.com>
Hi Jaikumar,
On Tue, Apr 05, 2011, Jaikumar Ganesh wrote:
> diff --git a/src/adapter.c b/src/adapter.c
> index c400bfd..014cc0c 100644
> --- a/src/adapter.c
> +++ b/src/adapter.c
> @@ -156,6 +156,8 @@ struct btd_adapter {
>
> static void adapter_set_pairable_timeout(struct btd_adapter *adapter,
> guint interval);
> +static DBusMessage *set_discoverable(DBusConnection *conn, DBusMessage *msg,
> + gboolean discoverable, void *data);
>
> static int found_device_cmp(const struct remote_dev_info *d1,
> const struct remote_dev_info *d2)
> @@ -374,7 +376,7 @@ static gboolean discov_timeout_handler(gpointer user_data)
>
> adapter->discov_timeout_id = 0;
>
> - adapter_ops->set_discoverable(adapter->dev_id, FALSE);
> + set_discoverable(NULL, NULL, FALSE, user_data);
>
> return FALSE;
I don't think it's appropriate to reuse set_discoverable here since it's
a D-Bus method callback. It can e.g. result in passing the DBusMessage
parameter to btd_error_failed which might cause a crash with a NULL
pointer. I think duplicating some code from set_discoverable would make
more sense, either within discov_timeout_handler or as a separate static
function.
Johan
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox