* RE: Which software is responsible for bringing the devices (hci0 .. hcix) up ?
From: Vellemans, Noel @ 2012-08-29 7:20 UTC (permalink / raw)
To: Andrei Emeltchenko; +Cc: linux-bluetooth
In-Reply-To: <20120829071455.GB3937@aemeltch-MOBL1>
Hi,
It is an EXTERNAL USB-device plugged in manually, and if it is plugged
in, the device is recognized.
Regards Noel
<< log>>
Plug in device ... Results in....
# usb wakeup is here
usb 2-1: new full speed USB device using fsl-ehci and address 4
usb 2-1: New USB device found, idVendor=0a12, idProduct=0001
usb 2-1: New USB device strings: Mfr=0, Product=0, SerialNumber=0
#
# lsusb
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 001 Device 002: ID 0eef:7304 D-WAV Scientific Co., Ltd
Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 002 Device 004: ID 0a12:0001 Cambridge Silicon Radio, Ltd Bluetooth
Dongle (HCI mode)
# hciconfig
hci0: Type: BR/EDR Bus: USB
BD Address: 00:00:00:00:00:00 ACL MTU: 0:0 SCO MTU: 0:0
DOWN
RX bytes:0 acl:0 sco:0 events:0 errors:0
TX bytes:0 acl:0 sco:0 commands:0 errors:0
-----Original Message-----
From: Andrei Emeltchenko [mailto:andrei.emeltchenko.news@gmail.com]
Sent: 29Aug12 09:15
To: Vellemans, Noel
Cc: linux-bluetooth@vger.kernel.org
Subject: Re: Which software is responsible for bringing the devices
(hci0 .. hcix) up ?
Hi Noel,
On Wed, Aug 29, 2012 at 09:12:18AM +0200, Vellemans, Noel wrote:
> Hi Andrei,
>
> Any clue what the reason can be, that the device is not comming 'UP'
> automatically ?
It is powered off automatically.
Best regards
Andrei Emeltchenko
>
>
> Regards Noel
>
>
> -----Original Message-----
> From: Andrei Emeltchenko [mailto:andrei.emeltchenko.news@gmail.com]
> Sent: 29Aug12 09:09
> To: Vellemans, Noel
> Cc: linux-bluetooth@vger.kernel.org
> Subject: Re: Which software is responsible for bringing the devices
> (hci0 .. hcix) up ?
>
> Hi Noel,
>
> On Wed, Aug 29, 2012 at 08:58:12AM +0200, Vellemans, Noel wrote:
> > Hi,
> >
> >
> > I have a simple question, I think, But I do not manage to find the
> > answer into the old mailing-list-posts.
> >
> > I'm using bluez-4.99 and Linux kernel 2.6.35.3.
> >
> > When plugging in a device (CSR-device) the device is recognized but
> > it
>
> > is not 'UP'.
> >
> > Can someone tell me what piece of software is NORMALLY setting the
> > device into the 'UP' state?
> > (so that I do not have to type hciconfig hci0 up)
>
> bluetoothd
>
> Best regards
> Andrei Emeltchenko
>
^ permalink raw reply
* Re: Which software is responsible for bringing the devices (hci0 .. hcix) up ?
From: Andrei Emeltchenko @ 2012-08-29 7:15 UTC (permalink / raw)
To: Vellemans, Noel; +Cc: linux-bluetooth
In-Reply-To: <1531E53627F1F749B4FE809BF2A4EB67036F2FAC@WETMEX10.loepfe.com>
Hi Noel,
On Wed, Aug 29, 2012 at 09:12:18AM +0200, Vellemans, Noel wrote:
> Hi Andrei,
>
> Any clue what the reason can be, that the device is not comming 'UP'
> automatically ?
It is powered off automatically.
Best regards
Andrei Emeltchenko
>
>
> Regards Noel
>
>
> -----Original Message-----
> From: Andrei Emeltchenko [mailto:andrei.emeltchenko.news@gmail.com]
> Sent: 29Aug12 09:09
> To: Vellemans, Noel
> Cc: linux-bluetooth@vger.kernel.org
> Subject: Re: Which software is responsible for bringing the devices
> (hci0 .. hcix) up ?
>
> Hi Noel,
>
> On Wed, Aug 29, 2012 at 08:58:12AM +0200, Vellemans, Noel wrote:
> > Hi,
> >
> >
> > I have a simple question, I think, But I do not manage to find the
> > answer into the old mailing-list-posts.
> >
> > I'm using bluez-4.99 and Linux kernel 2.6.35.3.
> >
> > When plugging in a device (CSR-device) the device is recognized but it
>
> > is not 'UP'.
> >
> > Can someone tell me what piece of software is NORMALLY setting the
> > device into the 'UP' state?
> > (so that I do not have to type hciconfig hci0 up)
>
> bluetoothd
>
> Best regards
> Andrei Emeltchenko
>
^ permalink raw reply
* RE: Which software is responsible for bringing the devices (hci0 .. hcix) up ?
From: Vellemans, Noel @ 2012-08-29 7:12 UTC (permalink / raw)
To: Andrei Emeltchenko; +Cc: linux-bluetooth
In-Reply-To: <20120829070853.GA3937@aemeltch-MOBL1>
Hi Andrei,
Any clue what the reason can be, that the device is not comming 'UP'
automatically ?
Regards Noel
-----Original Message-----
From: Andrei Emeltchenko [mailto:andrei.emeltchenko.news@gmail.com]
Sent: 29Aug12 09:09
To: Vellemans, Noel
Cc: linux-bluetooth@vger.kernel.org
Subject: Re: Which software is responsible for bringing the devices
(hci0 .. hcix) up ?
Hi Noel,
On Wed, Aug 29, 2012 at 08:58:12AM +0200, Vellemans, Noel wrote:
> Hi,
>
>
> I have a simple question, I think, But I do not manage to find the
> answer into the old mailing-list-posts.
>
> I'm using bluez-4.99 and Linux kernel 2.6.35.3.
>
> When plugging in a device (CSR-device) the device is recognized but it
> is not 'UP'.
>
> Can someone tell me what piece of software is NORMALLY setting the
> device into the 'UP' state?
> (so that I do not have to type hciconfig hci0 up)
bluetoothd
Best regards
Andrei Emeltchenko
^ permalink raw reply
* Re: Which software is responsible for bringing the devices (hci0 .. hcix) up ?
From: Andrei Emeltchenko @ 2012-08-29 7:08 UTC (permalink / raw)
To: Vellemans, Noel; +Cc: linux-bluetooth
In-Reply-To: <1531E53627F1F749B4FE809BF2A4EB67036F2F97@WETMEX10.loepfe.com>
Hi Noel,
On Wed, Aug 29, 2012 at 08:58:12AM +0200, Vellemans, Noel wrote:
> Hi,
>
>
> I have a simple question, I think, But I do not manage to find the
> answer into the old mailing-list-posts.
>
> I'm using bluez-4.99 and Linux kernel 2.6.35.3.
>
> When plugging in a device (CSR-device) the device is recognized but it
> is not 'UP'.
>
> Can someone tell me what piece of software is NORMALLY setting the
> device into the 'UP' state?
> (so that I do not have to type hciconfig hci0 up)
bluetoothd
Best regards
Andrei Emeltchenko
^ permalink raw reply
* Which software is responsible for bringing the devices (hci0 .. hcix) up ?
From: Vellemans, Noel @ 2012-08-29 6:58 UTC (permalink / raw)
To: linux-bluetooth
Hi,
I have a simple question, I think, But I do not manage to find the
answer into the old mailing-list-posts.
I'm using bluez-4.99 and Linux kernel 2.6.35.3.
When plugging in a device (CSR-device) the device is recognized but it
is not 'UP'.
Can someone tell me what piece of software is NORMALLY setting the
device into the 'UP' state?
(so that I do not have to type hciconfig hci0 up)
# plug in the device ... results in ...
usb wakeup is here
usb 2-1: new full speed USB device using fsl-ehci and address 3
usb 2-1: New USB device found, idVendor=0a12, idProduct=0001
usb 2-1: New USB device strings: Mfr=0, Product=0, SerialNumber=0
# hciconfig
hci0: Type: BR/EDR Bus: USB
BD Address: 00:00:00:00:00:00 ACL MTU: 0:0 SCO MTU: 0:0
DOWN
RX bytes:0 acl:0 sco:0 events:0 errors:0
TX bytes:0 acl:0 sco:0 commands:0 errors:0
After manually executing hciconfig hci0 up the device is working fine.
# hciconfig hci0 up
# hciconfig
hci0: Type: BR/EDR Bus: USB
BD Address: 00:07:80:85:39:07 ACL MTU: 192:8 SCO MTU: 64:8
UP RUNNING
RX bytes:340 acl:0 sco:0 events:11 errors:0
TX bytes:38 acl:0 sco:0 commands:11 errors:0
Regards,
Noel
^ permalink raw reply
* [PATCH] client: Fix crash on map module
From: Srinivasa Ragavan @ 2012-08-29 5:15 UTC (permalink / raw)
To: linux-bluetooth; +Cc: Srinivasa Ragavan
gboolean is expected to hold 0/1. But it is holding int return from strcasecmp
which crashes DBusMessage at _dbus_return_val_if_fail
(*bool_p == 0 || *bool_p == 1, FALSE);
Trace:
0 0x00007ffff7328d95 in __GI_raise (sig=6) at raise.c:64
1 0x00007ffff732a2ab in __GI_abort () at abort.c:93
2 0x00007ffff78d0655 in _dbus_abort () at dbus-sysdeps.c:94
3 0x00007ffff78c75f1 in _dbus_warn_check_failed at dbus-internals.c:289
4 0x00007ffff78ba28b in dbus_message_iter_append_basic at dbus-message.c:2538
5 0x00000000004201c3 in append_variant at client/dbus.c:44
6 0x000000000042024e in obex_dbus_dict_append at client/dbus.c:65
7 0x000000000041dcc9 in parse_read at client/map.c:423
8 0x000000000041dfa7 in msg_element at client/map.c:518
9 0x00007ffff7b323b9 in emit_start_element at gmarkup.c:986
10 0x00007ffff7b33b44 in g_markup_parse_context_parse at gmarkup.c:1323
11 0x000000000041e1ad in message_listing_cb at client/map.c:586
12 0x000000000041744c in session_terminate_transfer client/session.c:743
13 0x00000000004174d7 in session_notify_complete at client/session.c:758
14 0x000000000041755a in transfer_complete at client/session.c:778
15 0x000000000041f57b in xfer_complete at client/transfer.c:521
16 0x000000000040efdf in transfer_complete at gobex/gobex-transfer.c:102
17 0x000000000040f418 in transfer_response at gobex/gobex-transfer.c:221
18 0x000000000040b320 in handle_response at gobex/gobex.c:948
19 0x000000000040bbc1 in incoming_data at gobex/gobex.c:1191
20 0x00007ffff7b2f94a in g_main_dispatch (context=0x62f130) at gmain.c:2515
21 g_main_context_dispatch (context=0x62f130) at gmain.c:3052
22 0x00007ffff7b2fd10 in g_main_context_iterate at gmain.c:3123
23 g_main_context_iterate at gmain.c:3060
24 0x00007ffff7b3010a in g_main_loop_run (loop=0x62e1b0) at gmain.c:3317
25 0x000000000041527d in main at client/main.c:175
---
client/map.c | 8 ++++----
1 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/client/map.c b/client/map.c
index e606cb2..4f07fcb 100644
--- a/client/map.c
+++ b/client/map.c
@@ -400,7 +400,7 @@ static void parse_size(struct map_msg *msg, const char *value,
static void parse_priority(struct map_msg *msg, const char *value,
DBusMessageIter *iter)
{
- gboolean flag = strcasecmp(value, "no");
+ gboolean flag = strcasecmp(value, "no") != 0;
if (flag)
msg->flags |= MAP_MSG_FLAG_PRIORITY;
@@ -413,7 +413,7 @@ static void parse_priority(struct map_msg *msg, const char *value,
static void parse_read(struct map_msg *msg, const char *value,
DBusMessageIter *iter)
{
- gboolean flag = strcasecmp(value, "no");
+ gboolean flag = strcasecmp(value, "no") != 0;
if (flag)
msg->flags |= MAP_MSG_FLAG_READ;
@@ -426,7 +426,7 @@ static void parse_read(struct map_msg *msg, const char *value,
static void parse_sent(struct map_msg *msg, const char *value,
DBusMessageIter *iter)
{
- gboolean flag = strcasecmp(value, "no");
+ gboolean flag = strcasecmp(value, "no") != 0;
if (flag)
msg->flags |= MAP_MSG_FLAG_SENT;
@@ -439,7 +439,7 @@ static void parse_sent(struct map_msg *msg, const char *value,
static void parse_protected(struct map_msg *msg, const char *value,
DBusMessageIter *iter)
{
- gboolean flag = strcasecmp(value, "no");
+ gboolean flag = strcasecmp(value, "no") != 0;
if (flag)
msg->flags |= MAP_MSG_FLAG_PROTECTED;
--
1.7.7
^ permalink raw reply related
* Re: kernel crashes coming from btusb
From: Sonny Rao @ 2012-08-29 4:13 UTC (permalink / raw)
To: Oliver Neukum; +Cc: linux-bluetooth, marcel, vpalatin, keybuk
In-Reply-To: <CAPz6YkXjRAPs1UMGXPqGMDFYjcs_8ggxinF7sYNyjhYfgCBAAQ@mail.gmail.com>
On Mon, Aug 27, 2012 at 8:02 AM, Sonny Rao <sonnyrao@chromium.org> wrote:
> On Mon, Aug 27, 2012 at 6:06 AM, Oliver Neukum <oliver@neukum.org> wrote:
>> On Monday 27 August 2012 03:30:55 Sonny Rao wrote:
>>> Hi, I've been investigating an issue where we were seeing random
>>> kernel crashes soon after resume and after using the great debugging
>>> facilities in SLUB I started getting output which pointed to "use
>>> after free" from the btusb driver.
>>
>> Which kernel version?
>>
>> Regards
>> Oliver
>>
>
> Oops sorry, kernel 3.4
After some more investigation I am seeing the DMA unmap and it looks
like everything is okay as far as the driver tearing down the intr URB
correctly, sorry for the noise stating otherwise. This could be a
hardware issue if the host controller is still dmaing over that
transfer buffer. I'll look into that some more, thanks.
^ permalink raw reply
* Re: [PATCH BlueZ] input: Fix build error due to O_CLOEXEC
From: Anderson Lizardo @ 2012-08-29 0:55 UTC (permalink / raw)
To: Lucas De Marchi; +Cc: linux-bluetooth
In-Reply-To: <CAMOw1v4t_KVBW6dJXracXmKEyCcs3Jg3M82mEwJDvorTt2hV8Q@mail.gmail.com>
Hi Lucas,
On Tue, Aug 28, 2012 at 8:15 PM, Lucas De Marchi
<lucas.demarchi@profusion.mobi> wrote:
>> +#define _GNU_SOURCE
>
> this should be already in our config.h. It seems like we are missing
> the following in our configure.ac:
>
> AC_USE_SYSTEM_EXTENSIONS.
>
> Btw, we should remove the other definitions of _GNU_SOURCE
Nice, I wasn't aware of this feature. Does it require any newer
autoconf version?
I can try this tomorrow and send a new patch set removing the
_GNU_SOURCE defines.
Best Regards,
--
Anderson Lizardo
Instituto Nokia de Tecnologia - INdT
Manaus - Brazil
^ permalink raw reply
* Re: [PATCH BlueZ] input: Fix build error due to O_CLOEXEC
From: Lucas De Marchi @ 2012-08-29 0:15 UTC (permalink / raw)
To: Anderson Lizardo; +Cc: linux-bluetooth
In-Reply-To: <1346164127-22102-1-git-send-email-anderson.lizardo@openbossa.org>
On Tue, Aug 28, 2012 at 11:28 AM, Anderson Lizardo
<anderson.lizardo@openbossa.org> wrote:
> On some (not so old) systems like Ubuntu 10.04 LTS, O_CLOEXEC is only
> defined if _GNU_SOURCE is defined.
>
> This fixes this build error:
>
> profiles/input/hog_device.c: In function 'hog_device_register':
> profiles/input/hog_device.c:712: error: 'O_CLOEXEC' undeclared (first
> use in this function)
> profiles/input/hog_device.c:712: error: (Each undeclared identifier is
> reported only once
> profiles/input/hog_device.c:712: error: for each function it appears
> in.)
> ---
> profiles/input/hog_device.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/profiles/input/hog_device.c b/profiles/input/hog_device.c
> index 000f173..b502274 100644
> --- a/profiles/input/hog_device.c
> +++ b/profiles/input/hog_device.c
> @@ -27,6 +27,7 @@
> #include <config.h>
> #endif
>
> +#define _GNU_SOURCE
this should be already in our config.h. It seems like we are missing
the following in our configure.ac:
AC_USE_SYSTEM_EXTENSIONS.
Btw, we should remove the other definitions of _GNU_SOURCE
> #include <stdlib.h>
> #include <errno.h>
> #include <unistd.h>
Lucas De Marchi
^ permalink raw reply
* Re: [PATCH v2 01/13] Heart Rate Profile API
From: Anderson Lizardo @ 2012-08-28 19:21 UTC (permalink / raw)
To: Anderson Lizardo, Garbat Rafal, linux-bluetooth,
Santiago Carot-Nemesio
In-Reply-To: <CAJdJm_NL5ALYLKcHJ7uzWdtgkC_72++58GWm=CRXea_YEaYcqg@mail.gmail.com>
Hi,
After some discussion with Johan on IRC, I think I understand what he
is proposing, and it makes sense IMHO. The idea is to simply replace
the object path for RegisterWatcher/UnregisterWatcher to [variable
prefix]/{hci0,hci1,...} (adapter path) and have the watcher object
methods accept a "object device" as first argument.
This way, the application that wants to register wacthers will monitor
only for new adapters (and not new devices) and register watchers on
them. The D-Bus interface for RegisterWatcher() will still be profile
specific (e.g. org.bluez.HeartRate in this case).
One issue with this idea (and which still needs to be sorted out if we
proceed with this), is that other methods specific to the profile
(like Reset() for Heart Rate and EnableIntermediateMeasurement() for
Thermometer) need to be in different interfaces.
Johan, do you have any ideas for this?
Regards,
--
Anderson Lizardo
Instituto Nokia de Tecnologia - INdT
Manaus - Brazil
^ permalink raw reply
* Re: [Crash report & Patch obexd 1/1] map: gboolean holds int value which 0/1 crashes in DBusMessage
From: Luiz Augusto von Dentz @ 2012-08-28 18:37 UTC (permalink / raw)
To: Venkateswaran, Srinivasa Ragavan; +Cc: linux-bluetooth
In-Reply-To: <CAEd0BX-_PbMs1JV4g8_bYf43KScnHHKwsXaci=0cuqHcR-FGhg@mail.gmail.com>
Hi,
On Tue, Aug 28, 2012 at 2:37 PM, Venkateswaran, Srinivasa Ragavan
<srinivasa.ragavan.venkateswaran@intel.com> wrote:
> Hi,
>
> I was testing MAP and I came across a crash (trace attached). I
> figured out that the crash is because dbus expects gboolean to be 0/1
> where as it holds the 'int' results from strcasecmp. I've attached the
> patch that fixed the problem for me. This is my first message/patch to
> this list, sorry if it isn't in the right/expected format, just
> suggest me and I could put it right.
Interesting that I did not run into this bug before, can you do a some
changes to the commit message:
1. Add a prefix to the first line of the commit e.g: client: Fix crash
on map module
2. Add a description what you are fixing e.g. you can use the
backtrace and state this is caused by line _dbus_return_val_if_fail
(*bool_p == 0 || *bool_p == 1, FALSE);
3. How about using your intel email?
After you are done with that you can send us the patch with git
format-email + git send-email
--
Luiz Augusto von Dentz
^ permalink raw reply
* Re: [Crash report & Patch obexd 1/1] map: gboolean holds int value which 0/1 crashes in DBusMessage
From: Vinicius Costa Gomes @ 2012-08-28 18:36 UTC (permalink / raw)
To: Venkateswaran, Srinivasa Ragavan; +Cc: linux-bluetooth
In-Reply-To: <CAEd0BX-_PbMs1JV4g8_bYf43KScnHHKwsXaci=0cuqHcR-FGhg@mail.gmail.com>
Hi Srini,
On 17:07 Tue 28 Aug, Venkateswaran, Srinivasa Ragavan wrote:
> Hi,
>
> I was testing MAP and I came across a crash (trace attached). I
> figured out that the crash is because dbus expects gboolean to be 0/1
> where as it holds the 'int' results from strcasecmp. I've attached the
> patch that fixed the problem for me. This is my first message/patch to
> this list, sorry if it isn't in the right/expected format, just
> suggest me and I could put it right.
The patch in itself looks good.
Some changes: please use git send-email to send the patch (it is much
easier to look at inlined patches); please use a shorter subject line,
e.g. "map: Fix sending a D-Bus message with invalid parameters", and you
could attach the backtrace in the commit message.
>
> Thanks,
> -Srini.
> Thread 1 (Thread 0x7ffff7fce700 (LWP 6124)):
> #0 0x00007ffff7328d95 in __GI_raise (sig=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:64
> #1 0x00007ffff732a2ab in __GI_abort () at abort.c:93
> #2 0x00007ffff78d0655 in _dbus_abort () at dbus-sysdeps.c:94
> #3 0x00007ffff78c75f1 in _dbus_warn_check_failed (format=0x7ffff78d6920 "arguments to %s() were incorrect, assertion \"%s\" failed in file %s line %d.\nThis is normally a bug in some application using the D-Bus library.\n") at dbus-internals.c:289
> #4 0x00007ffff78ba28b in dbus_message_iter_append_basic (iter=0x7fffffffd320, type=<optimized out>, value=0x7fffffffd43c) at dbus-message.c:2538
> #5 0x00000000004201c3 in append_variant (iter=0x7fffffffd3b0, type=98, value=0x7fffffffd43c) at client/dbus.c:44
> #6 0x000000000042024e in obex_dbus_dict_append (dict=0x7fffffffd480, key=0x4252bb "Read", type=98, value=0x7fffffffd43c) at client/dbus.c:65
> #7 0x000000000041dcc9 in parse_read (msg=0x63c650, value=0x63be00 "yes", iter=0x7fffffffd480) at client/map.c:423
> #8 0x000000000041dfa7 in msg_element (ctxt=0x63bc50, element=0x63bd70 "msg", names=0x7fffffffd5f0, values=0x7fffffffd560, user_data=0x6347b0, gerr=0x7fffffffd680) at client/map.c:518
> #9 0x00007ffff7b323b9 in emit_start_element (context=0x63bc50, error=0x0) at gmarkup.c:986
> #10 0x00007ffff7b33b44 in g_markup_parse_context_parse (context=0x63bc50, text=<optimized out>, text_len=<optimized out>, error=0x0) at gmarkup.c:1323
> #11 0x000000000041e1ad in message_listing_cb (session=0x631450, transfer=0x633fd0, err=0x0, user_data=0x638b60) at client/map.c:586
> #12 0x000000000041744c in session_terminate_transfer (session=0x631450, transfer=0x633fd0, gerr=0x0) at client/session.c:743
> #13 0x00000000004174d7 in session_notify_complete (session=0x631450, transfer=0x633fd0) at client/session.c:758
> #14 0x000000000041755a in transfer_complete (transfer=0x633fd0, err=0x0, user_data=0x631450) at client/session.c:778
> #15 0x000000000041f57b in xfer_complete (obex=0x634660, err=0x0, user_data=0x633fd0) at client/transfer.c:521
> #16 0x000000000040efdf in transfer_complete (transfer=0x63b260, err=0x0) at gobex/gobex-transfer.c:102
> #17 0x000000000040f418 in transfer_response (obex=0x634660, err=0x0, rsp=0x633d00, user_data=0x63b260) at gobex/gobex-transfer.c:221
> #18 0x000000000040b320 in handle_response (obex=0x634660, err=0x0, rsp=0x633d00) at gobex/gobex.c:948
> #19 0x000000000040bbc1 in incoming_data (io=0x638da0, cond=G_IO_IN, user_data=0x634660) at gobex/gobex.c:1191
> #20 0x00007ffff7b2f94a in g_main_dispatch (context=0x62f130) at gmain.c:2515
> #21 g_main_context_dispatch (context=0x62f130) at gmain.c:3052
> #22 0x00007ffff7b2fd10 in g_main_context_iterate (dispatch=1, block=<optimized out>, context=0x62f130, self=<optimized out>) at gmain.c:3123
> #23 g_main_context_iterate (context=0x62f130, block=<optimized out>, dispatch=1, self=<optimized out>) at gmain.c:3060
> #24 0x00007ffff7b3010a in g_main_loop_run (loop=0x62e1b0) at gmain.c:3317
> #25 0x000000000041527d in main (argc=1, argv=0x7fffffffdca8) at client/main.c:175
> (gdb)
Cheers,
--
Vinicius
^ permalink raw reply
* Re: [PATCH v2 01/13] Heart Rate Profile API
From: Anderson Lizardo @ 2012-08-28 18:23 UTC (permalink / raw)
To: Anderson Lizardo, Garbat Rafal, linux-bluetooth,
Santiago Carot-Nemesio
In-Reply-To: <20120828181041.GA7686@x220.sheraton.com>
Hi Johan,
On Tue, Aug 28, 2012 at 2:10 PM, Johan Hedberg <johan.hedberg@gmail.com> wrote:
>> The registered "watcher" object will have different interface
>> depending on the profile. The application which will call
>> RegisterWatcher() needs to check that the device supports the expected
>> GATT service (e.g. by checking the "UUIDs" property of that device
>> object) before using the org.bluez.HeartRate interface, therefore
>> IMHO it makes sense to have RegisterWatcher() on the device object
>> path.
>
> I'm not quite following. You'd still have per-profile interfaces on the
> adapter path.
What I meant, is that, before using RegisterWatcher(), you need to
check the "UUIDs" property on the device path. So you still need to
either enumerate all device objects and read their "UUIDs" property,
or monitor the "PropertiesChanged" signal (once the new Property API
is upstream).
So IMHO ff you need to access the device object, there is no gain in
moving the method to adapter object.
>> Unless you are proposing a generic Watcher API that could somehow be
>> shared by all profiles (including a single shared interface for the
>> watcher object)? How to represent data from profiles which are not
>> "measurement" based?
>
> I suppose you were directing this at Rafal and not me? I don't think it
> makes sense to merge these. I was only saying that the interfaces should
> go from Device to Adapter.
No, I was commenting specifically on your suggestion to move
RegisterWatcher() to the adapter path and have a "device" parameter to
select the device. The user of this API would still need to check if
the device actually supports that wanted GATT service (using the UUIDs
device property) before registering any watcher.
Regards,
--
Anderson Lizardo
Instituto Nokia de Tecnologia - INdT
Manaus - Brazil
^ permalink raw reply
* Re: [PATCH v2 01/13] Heart Rate Profile API
From: Johan Hedberg @ 2012-08-28 18:10 UTC (permalink / raw)
To: Anderson Lizardo; +Cc: Garbat Rafal, linux-bluetooth, Santiago Carot-Nemesio
In-Reply-To: <CAJdJm_PWn--HEsaex1zqL_CqEBvjKQXSABBnPeYP9CVKgeA6Wg@mail.gmail.com>
Hi Lizardo,
On Tue, Aug 28, 2012, Anderson Lizardo wrote:
> On Tue, Aug 28, 2012 at 12:56 PM, Johan Hedberg <johan.hedberg@gmail.com> wrote:
> > On Tue, Aug 28, 2012, Garbat Rafal wrote:
> >> I guess that moving RegisterWatcher methods to the adapter iface
> >> sounds reasonable, but we need to think how to do it i.e. to
> >> properly handle devices that support several profiles based on
> >> registering watchers (do we want to register watcher for all the
> >> profiles or have a parameter for Watcher methods to specify the
> >> target), etc.
> >> Correct me if I'm wrong or missing something.
> >> I'd suggest merging heartrate as this profile is quite similar to
> >> the thermometer and it works (and no one have any objections to the
> >> code) and re-factor this later on.
> >> Unfortunately I'll be off for the next three weeks, but I can get
> >> back to this when I'm back.
> >
> > Since it's not just a refactoring but an API change/break I'd rather get
> > this right from the start. The thermometer API should also be updated to
> > be per-adapter for our next release (BlueZ 5).
>
> The registered "watcher" object will have different interface
> depending on the profile. The application which will call
> RegisterWatcher() needs to check that the device supports the expected
> GATT service (e.g. by checking the "UUIDs" property of that device
> object) before using the org.bluez.HeartRate interface, therefore
> IMHO it makes sense to have RegisterWatcher() on the device object
> path.
I'm not quite following. You'd still have per-profile interfaces on the
adapter path.
> Unless you are proposing a generic Watcher API that could somehow be
> shared by all profiles (including a single shared interface for the
> watcher object)? How to represent data from profiles which are not
> "measurement" based?
I suppose you were directing this at Rafal and not me? I don't think it
makes sense to merge these. I was only saying that the interfaces should
go from Device to Adapter.
Johan
^ permalink raw reply
* Re: [PATCH v2 01/13] Heart Rate Profile API
From: Anderson Lizardo @ 2012-08-28 17:55 UTC (permalink / raw)
To: Garbat Rafal, linux-bluetooth, Santiago Carot-Nemesio
In-Reply-To: <20120828165650.GA3165@x220.sheraton.com>
Hi Johan,
On Tue, Aug 28, 2012 at 12:56 PM, Johan Hedberg <johan.hedberg@gmail.com> wrote:
> On Tue, Aug 28, 2012, Garbat Rafal wrote:
>> I guess that moving RegisterWatcher methods to the adapter iface
>> sounds reasonable, but we need to think how to do it i.e. to
>> properly handle devices that support several profiles based on
>> registering watchers (do we want to register watcher for all the
>> profiles or have a parameter for Watcher methods to specify the
>> target), etc.
>> Correct me if I'm wrong or missing something.
>> I'd suggest merging heartrate as this profile is quite similar to
>> the thermometer and it works (and no one have any objections to the
>> code) and re-factor this later on.
>> Unfortunately I'll be off for the next three weeks, but I can get
>> back to this when I'm back.
>
> Since it's not just a refactoring but an API change/break I'd rather get
> this right from the start. The thermometer API should also be updated to
> be per-adapter for our next release (BlueZ 5).
The registered "watcher" object will have different interface
depending on the profile. The application which will call
RegisterWatcher() needs to check that the device supports the expected
GATT service (e.g. by checking the "UUIDs" property of that device
object) before using the org.bluez.HeartRate interface, therefore
IMHO it makes sense to have RegisterWatcher() on the device object
path.
Unless you are proposing a generic Watcher API that could somehow be
shared by all profiles (including a single shared interface for the
watcher object)? How to represent data from profiles which are not
"measurement" based?
Best Regards,
--
Anderson Lizardo
Instituto Nokia de Tecnologia - INdT
Manaus - Brazil
^ permalink raw reply
* Re: [PATCH 1/2] Fix redundant NULL checks in convert_raw_attr_to_xml_func
From: Johan Hedberg @ 2012-08-28 17:30 UTC (permalink / raw)
To: Szymon Janc; +Cc: linux-bluetooth
In-Reply-To: <1346160796-23277-1-git-send-email-szymon.janc@tieto.com>
Hi Szymon,
On Tue, Aug 28, 2012, Szymon Janc wrote:
> Param data can't be NULL and was already dereferenced before check.
>
> ---
> src/sdp-xml.c | 5 +----
> 1 file changed, 1 insertion(+), 4 deletions(-)
Both patches have been applied. Thanks.
Johan
^ permalink raw reply
* Re: [PATCH] Bluetooth: btmrvl: remove pointless conditional before kfree_skb()
From: Gustavo Padovan @ 2012-08-28 17:24 UTC (permalink / raw)
To: Wei Yongjun; +Cc: marcel, johan.hedberg, yongjun_wei, linux-bluetooth
In-Reply-To: <CAPgLHd-R2t_9aDOQ8Q-Q0nz6k4KZEBPVEO4SMea7T=ANbTOLnQ@mail.gmail.com>
Hi Wei,
* Wei Yongjun <weiyj.lk@gmail.com> [2012-08-28 21:12:48 +0800]:
> From: Wei Yongjun <yongjun_wei@trendmicro.com.cn>
>
> Remove pointless conditional before kfree_skb().
>
> Signed-off-by: Wei Yongjun <yongjun_wei@trendmicro.com.cn>
> ---
> drivers/bluetooth/btmrvl_sdio.c | 3 +--
> 1 file changed, 1 insertion(+), 2 deletions(-)
Patch has been applied to bluetooth-next. Thanks.
Gustavo
^ permalink raw reply
* Re: [PATCH] Bluetooth: btmrvl: remove pointless conditional before kfree_skb()
From: Marcel Holtmann @ 2012-08-28 17:10 UTC (permalink / raw)
To: Wei Yongjun; +Cc: gustavo, johan.hedberg, yongjun_wei, linux-bluetooth
In-Reply-To: <CAPgLHd-R2t_9aDOQ8Q-Q0nz6k4KZEBPVEO4SMea7T=ANbTOLnQ@mail.gmail.com>
Hi Wei,
> Remove pointless conditional before kfree_skb().
>
> Signed-off-by: Wei Yongjun <yongjun_wei@trendmicro.com.cn>
> ---
> drivers/bluetooth/btmrvl_sdio.c | 3 +--
> 1 file changed, 1 insertion(+), 2 deletions(-)
Acked-by: Marcel Holtmann <marcel@holtmann.org>
Regards
Marcel
^ permalink raw reply
* Re: [PATCH v2 01/13] Heart Rate Profile API
From: Johan Hedberg @ 2012-08-28 16:56 UTC (permalink / raw)
To: Garbat Rafal; +Cc: linux-bluetooth, Santiago Carot-Nemesio
In-Reply-To: <503CE72D.2030501@tieto.com>
Hi Rafal,
On Tue, Aug 28, 2012, Garbat Rafal wrote:
> >>I'm wondering if it wouldn't make more sense to have these
> >>RegisterWatcher APIs (thermometer, heart rate, others?) per-adapter
> >>instead of per-device. That would be much friendlier to applications in
> >>that they wouldn't need to separately search for paired/configured
> >>devices supporting a specific service. Moving this to be per-adapter
> >>would also mean that the first parameter of the Watcher methods would be
> >>the object path of which device is in question.
> >So any comments on this? I'd like to get this moving forward and finally
> >merged upstream.
>
> Sorry for a late reply.
> I guess that moving RegisterWatcher methods to the adapter iface
> sounds reasonable, but we need to think how to do it i.e. to
> properly handle devices that support several profiles based on
> registering watchers (do we want to register watcher for all the
> profiles or have a parameter for Watcher methods to specify the
> target), etc.
> Correct me if I'm wrong or missing something.
> I'd suggest merging heartrate as this profile is quite similar to
> the thermometer and it works (and no one have any objections to the
> code) and re-factor this later on.
> Unfortunately I'll be off for the next three weeks, but I can get
> back to this when I'm back.
Since it's not just a refactoring but an API change/break I'd rather get
this right from the start. The thermometer API should also be updated to
be per-adapter for our next release (BlueZ 5).
Johan
^ permalink raw reply
* Re: [PATCH v2 01/13] Heart Rate Profile API
From: Garbat Rafal @ 2012-08-28 15:43 UTC (permalink / raw)
To: linux-bluetooth, Santiago Carot-Nemesio
In-Reply-To: <20120828152058.GA18913@x220.sheraton.com>
Hi,
On 08/28/2012 05:20 PM, Johan Hedberg wrote:
> Hi,
>
> On Tue, Aug 14, 2012, Johan Hedberg wrote:
>> Hi,
>>
>> On Mon, Aug 13, 2012, Rafal Garbat wrote:
>>> +Heart Rate Profile hierarchy
>>> +============================
>>> +
>>> +Service org.bluez
>>> +Interface org.bluez.HeartRate
>>> +Object path [variable prefix]/{hci0,hci1,...}/dev_XX_XX_XX_XX_XX_XX
>>> +
>>> +Methods dict GetProperties()
>>> +
>>> + Returns all properties for the interface. See the
>>> + Properties section for the available properties.
>>> +
>>> + RegisterWatcher(object agent)
>>> +
>>> + Registers a watcher to monitor heart rate measurements.
>>> +
>>> + Possible Errors: org.bluez.Error.InvalidArguments
>> I'm wondering if it wouldn't make more sense to have these
>> RegisterWatcher APIs (thermometer, heart rate, others?) per-adapter
>> instead of per-device. That would be much friendlier to applications in
>> that they wouldn't need to separately search for paired/configured
>> devices supporting a specific service. Moving this to be per-adapter
>> would also mean that the first parameter of the Watcher methods would be
>> the object path of which device is in question.
> So any comments on this? I'd like to get this moving forward and finally
> merged upstream.
>
> Johan
> --
> 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
Sorry for a late reply.
I guess that moving RegisterWatcher methods to the adapter iface sounds
reasonable, but we need to think how to do it i.e. to properly handle
devices that support several profiles based on registering watchers (do
we want to register watcher for all the profiles or have a parameter for
Watcher methods to specify the target), etc.
Correct me if I'm wrong or missing something.
I'd suggest merging heartrate as this profile is quite similar to the
thermometer and it works (and no one have any objections to the code)
and re-factor this later on.
Unfortunately I'll be off for the next three weeks, but I can get back
to this when I'm back.
BR,
Rafal
^ permalink raw reply
* Re: [PATCH v2 01/13] Heart Rate Profile API
From: Johan Hedberg @ 2012-08-28 15:20 UTC (permalink / raw)
To: Rafal Garbat, linux-bluetooth, Santiago Carot-Nemesio
In-Reply-To: <20120814095636.GA7055@x220>
Hi,
On Tue, Aug 14, 2012, Johan Hedberg wrote:
> Hi,
>
> On Mon, Aug 13, 2012, Rafal Garbat wrote:
> > +Heart Rate Profile hierarchy
> > +============================
> > +
> > +Service org.bluez
> > +Interface org.bluez.HeartRate
> > +Object path [variable prefix]/{hci0,hci1,...}/dev_XX_XX_XX_XX_XX_XX
> > +
> > +Methods dict GetProperties()
> > +
> > + Returns all properties for the interface. See the
> > + Properties section for the available properties.
> > +
> > + RegisterWatcher(object agent)
> > +
> > + Registers a watcher to monitor heart rate measurements.
> > +
> > + Possible Errors: org.bluez.Error.InvalidArguments
>
> I'm wondering if it wouldn't make more sense to have these
> RegisterWatcher APIs (thermometer, heart rate, others?) per-adapter
> instead of per-device. That would be much friendlier to applications in
> that they wouldn't need to separately search for paired/configured
> devices supporting a specific service. Moving this to be per-adapter
> would also mean that the first parameter of the Watcher methods would be
> the object path of which device is in question.
So any comments on this? I'd like to get this moving forward and finally
merged upstream.
Johan
^ permalink raw reply
* [PATCH BlueZ] input: Fix build error due to O_CLOEXEC
From: Anderson Lizardo @ 2012-08-28 14:28 UTC (permalink / raw)
To: linux-bluetooth; +Cc: Anderson Lizardo
On some (not so old) systems like Ubuntu 10.04 LTS, O_CLOEXEC is only
defined if _GNU_SOURCE is defined.
This fixes this build error:
profiles/input/hog_device.c: In function 'hog_device_register':
profiles/input/hog_device.c:712: error: 'O_CLOEXEC' undeclared (first
use in this function)
profiles/input/hog_device.c:712: error: (Each undeclared identifier is
reported only once
profiles/input/hog_device.c:712: error: for each function it appears
in.)
---
profiles/input/hog_device.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/profiles/input/hog_device.c b/profiles/input/hog_device.c
index 000f173..b502274 100644
--- a/profiles/input/hog_device.c
+++ b/profiles/input/hog_device.c
@@ -27,6 +27,7 @@
#include <config.h>
#endif
+#define _GNU_SOURCE
#include <stdlib.h>
#include <errno.h>
#include <unistd.h>
--
1.7.9.5
^ permalink raw reply related
* [PATCH 2/2] Fix error reporting in sdp_service_search_attr_req
From: Szymon Janc @ 2012-08-28 13:33 UTC (permalink / raw)
To: linux-bluetooth; +Cc: Szymon Janc
In-Reply-To: <1346160796-23277-1-git-send-email-szymon.janc@tieto.com>
This function reports error code via errno not return value.
---
lib/sdp.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/lib/sdp.c b/lib/sdp.c
index 9807c8d..36b4d08 100644
--- a/lib/sdp.c
+++ b/lib/sdp.c
@@ -4346,7 +4346,8 @@ int sdp_service_search_attr_req(sdp_session_t *session, const sdp_list_t *search
seqlen = gen_attridseq_pdu(pdata, attrids,
reqtype == SDP_ATTR_REQ_INDIVIDUAL ? SDP_UINT16 : SDP_UINT32);
if (seqlen == -1) {
- status = EINVAL;
+ errno = EINVAL;
+ status = -1;
goto end;
}
pdata += seqlen;
--
1.7.9.5
^ permalink raw reply related
* [PATCH 1/2] Fix redundant NULL checks in convert_raw_attr_to_xml_func
From: Szymon Janc @ 2012-08-28 13:33 UTC (permalink / raw)
To: linux-bluetooth; +Cc: Szymon Janc
Param data can't be NULL and was already dereferenced before check.
---
src/sdp-xml.c | 5 +----
1 file changed, 1 insertion(+), 4 deletions(-)
diff --git a/src/sdp-xml.c b/src/sdp-xml.c
index d7b2aef..52df285 100644
--- a/src/sdp-xml.c
+++ b/src/sdp-xml.c
@@ -377,10 +377,7 @@ static void convert_raw_attr_to_xml_func(void *val, void *data)
value->attrId);
cd->appender(cd->data, buf);
- if (data)
- convert_raw_data_to_xml(value, 2, cd->data, cd->appender);
- else
- cd->appender(cd->data, "\t\tNULL\n");
+ convert_raw_data_to_xml(value, 2, cd->data, cd->appender);
cd->appender(cd->data, "\t</attribute>\n");
}
--
1.7.9.5
^ permalink raw reply related
* [PATCH] Bluetooth: btmrvl: remove pointless conditional before kfree_skb()
From: Wei Yongjun @ 2012-08-28 13:12 UTC (permalink / raw)
To: marcel, gustavo, johan.hedberg; +Cc: yongjun_wei, linux-bluetooth
From: Wei Yongjun <yongjun_wei@trendmicro.com.cn>
Remove pointless conditional before kfree_skb().
Signed-off-by: Wei Yongjun <yongjun_wei@trendmicro.com.cn>
---
drivers/bluetooth/btmrvl_sdio.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/bluetooth/btmrvl_sdio.c b/drivers/bluetooth/btmrvl_sdio.c
index 6a9e971..48ae86f 100644
--- a/drivers/bluetooth/btmrvl_sdio.c
+++ b/drivers/bluetooth/btmrvl_sdio.c
@@ -600,8 +600,7 @@ static int btmrvl_sdio_card_to_host(struct btmrvl_private *priv)
exit:
if (ret) {
hdev->stat.err_rx++;
- if (skb)
- kfree_skb(skb);
+ kfree_skb(skb);
}
return ret;
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox