* Re: [PATCH] IrMC sync server support
From: Marcel J.E. Mol @ 2010-08-16 17:22 UTC (permalink / raw)
To: Marcel Holtmann; +Cc: linux-bluetooth
In-Reply-To: <1281613299.12579.266.camel@localhost.localdomain>
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset*=utf-8''%E2%80%9Cus-ascii, Size: 2008 bytes --]
On Thu, Aug 12, 2010 at 07:41:39AM -0400, Marcel Holtmann wrote:
> Hi Marcel,
>
> > A reasonable working IrMC SYNC server (only full phonebook sync support)
> > Support for cal and note by just returning nothing.
> > ---
> > Makefile.am | 3 +
> > plugins/irmc.c | 488 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++
> > src/main.c | 12 ++-
> > src/obex.h | 1 +
> > 4 files changed, 502 insertions(+), 2 deletions(-)
> > create mode 100644 plugins/irmc.c
> >
> > diff --git a/Makefile.am b/Makefile.am
> > index 73e2f28..ce8c675 100644
> > --- a/Makefile.am
> > +++ b/Makefile.am
> > @@ -58,6 +58,9 @@ builtin_sources += plugins/pbap.c plugins/phonebook.h \
> > builtin_modules += syncevolution
> > builtin_sources += plugins/syncevolution.c
> >
> > +builtin_modules += irmc
> > +builtin_sources += plugins/irmc.c plugins/phonebook.h
> > +
> > builtin_nodist += plugins/phonebook.c
> >
> > libexec_PROGRAMS += src/obexd
> > diff --git a/plugins/irmc.c b/plugins/irmc.c
> > new file mode 100644
> > index 0000000..96fd807
> > --- /dev/null
> > +++ b/plugins/irmc.c
> > @@ -0,0 +1,488 @@
> > +/*
> > + *
> > + * OBEX IrMC Sync Server
> > ...
> > +#include "dbus.h"
> > +
> > +#define IRMC_CHANNEL 17
>
> we did have a list of defined RFCOMM channels for various protocols, but
> just don't remember where it is.
>
> Johan, we should put that into the doc/ directory actually. Can you dig
> up that list and commit it as text file.
>
Any news on this one? Is 17 the correct channel for IrMC?
-Marcel
--
======-------- Marcel J.E. Mol MESA Consulting B.V.
=======--------- ph. +31-(0)6-54724868 P.O. Box 112
=======--------- marcel@mesa.nl 2630 AC Nootdorp
__==== www.mesa.nl ---____U_n_i_x______I_n_t_e_r_n_e_t____ The Netherlands ____
They couldn't think of a number, Linux user 1148 -- counter.li.org
so they gave me a name! -- Rupert Hine -- www.ruperthine.com
^ permalink raw reply
* Re: [PATCH] Fix problem with filling ADR with unneeded semicolons
From: Johan Hedberg @ 2010-08-16 15:16 UTC (permalink / raw)
To: Lukasz Pawlik; +Cc: linux-bluetooth
In-Reply-To: <1281969490-22315-1-git-send-email-lucas.pawlik@gmail.com>
Hi Lucasz,
On Mon, Aug 16, 2010, Lukasz Pawlik wrote:
> Previously in a phonebook pull request ADR was filled with six
> semicolons when contact address entry was empty in phonebook. This
> patch fixes this problem. Address is send as an empty string.
> ---
> plugins/vcard.c | 25 +++++++++++++++++++++++++
> 1 files changed, 25 insertions(+), 0 deletions(-)
Thanks for the patch, but it'll need some coding style cleanup before
going upstream:
> +static gboolean address_fields_present(struct phonebook_contact * contact)
No space after *
> + if (contact->country && strlen(contact->country))
> + return TRUE;
> +
The last line isn't really empty byt has an extra tab. Please remove it.
> + if (address_fields_present(contact) == FALSE) {
> + vcard_printf(vcards, "ADR:");
> + return;
There's an extra tab at the end of the line. Please remove it.
> + }
> +
Same here.
Johan
^ permalink raw reply
* [PATCH] Fix problem with filling ADR with unneeded semicolons
From: Lukasz Pawlik @ 2010-08-16 14:38 UTC (permalink / raw)
To: linux-bluetooth; +Cc: Lukasz Pawlik
Previously in a phonebook pull request ADR was filled with six
semicolons when contact address entry was empty in phonebook. This
patch fixes this problem. Address is send as an empty string.
---
plugins/vcard.c | 25 +++++++++++++++++++++++++
1 files changed, 25 insertions(+), 0 deletions(-)
diff --git a/plugins/vcard.c b/plugins/vcard.c
index 80f8265..7333a68 100644
--- a/plugins/vcard.c
+++ b/plugins/vcard.c
@@ -155,6 +155,26 @@ static gboolean contact_fields_present(struct phonebook_contact * contact)
return FALSE;
}
+static gboolean address_fields_present(struct phonebook_contact * contact)
+{
+ if (contact->pobox && strlen(contact->pobox))
+ return TRUE;
+ if (contact->extended && strlen(contact->extended))
+ return TRUE;
+ if (contact->street && strlen(contact->street))
+ return TRUE;
+ if (contact->locality && strlen(contact->locality))
+ return TRUE;
+ if (contact->region && strlen(contact->region))
+ return TRUE;
+ if (contact->postal && strlen(contact->postal))
+ return TRUE;
+ if (contact->country && strlen(contact->country))
+ return TRUE;
+
+ return FALSE;
+}
+
static void vcard_printf_name(GString *vcards,
struct phonebook_contact *contact)
{
@@ -253,6 +273,11 @@ static void vcard_printf_email(GString *vcards, const char *email)
static void vcard_printf_adr(GString *vcards, struct phonebook_contact *contact)
{
+ if (address_fields_present(contact) == FALSE) {
+ vcard_printf(vcards, "ADR:");
+ return;
+ }
+
vcard_printf(vcards, "ADR:%s;%s;%s;%s;%s;%s;%s", contact->pobox,
contact->extended, contact->street,
contact->locality, contact->region,
--
1.7.0.4
^ permalink raw reply related
* Re: [GSoC'10] : New Command Line Tool(s) for bluez
From: alok barsode @ 2010-08-16 13:35 UTC (permalink / raw)
To: Alexander Orlenko; +Cc: Bastien Nocera, Andrei Emeltchenko, linux-bluetooth
In-Reply-To: <AANLkTimPuCLfU5Xq8vH4+w3Ketf35RXN0P=Z0X50v6V8@mail.gmail.com>
Hi Alexander,
On Mon, Aug 16, 2010 at 5:36 PM, Alexander Orlenko <zxteam@gmail.com> wrote:
>> Shame, but I won't hold you against that :)
Its a lil joke ;) Bastien maintains (iirc) the gnome-bluetooth project.
No hard feelings ( I hope:) )
> Why? I wrote tool to generate gobjects from bluez/obexd doc api files.
> And my implementation has methods for easy properties access and
> supports properties caching (for example), and some others features.
>
> On 16 August 2010 20:40, Bastien Nocera <hadess@hadess.net> wrote:
>> On Mon, 2010-08-16 at 10:24 +1100, Alexander Orlenko wrote:
>>> Hi everyone,
>>>
>>> I updated project info page at http://hostisdown.org/gsoc/projects/bluez-tools
>>> Created project home page: http://code.google.com/p/bluez-tools
>>> Current release available for download: 0.1.18-6432
>>>
>>> Code of my project does not based on non-GTK parts of
>>> libgnome-bluetooth. I wrote glib gobjects for all bluez dbus
>>> interfaces.
>>
>> Shame, but I won't hold you against that :)
>>
>>> I will continue developing my project after end of GSoC.
>>
>> Hopefully people will package it for distributions so we don't get as
>> many requests for command-line pairing agents :)
>>
>> Cheers
>>
>>
> --
> 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
>
Cheers,
Alok.
^ permalink raw reply
* Re: [PATCH] Fix empty contact in missed calls problem
From: Johan Hedberg @ 2010-08-16 13:23 UTC (permalink / raw)
To: Radoslaw Jablonski; +Cc: linux-bluetooth
In-Reply-To: <1281963827-20375-1-git-send-email-ext-jablonski.radoslaw@nokia.com>
Hi Radek,
On Mon, Aug 16, 2010, Radoslaw Jablonski wrote:
> Fixed problem with tracker queries for calls history - previously call
> without contact in phonebook was missing in some scenario for pull
> requests.
> ---
> plugins/phonebook-tracker.c | 28 ++++------------------------
> 1 files changed, 4 insertions(+), 24 deletions(-)
Thanks. The patch is now upstream.
Johan
^ permalink raw reply
* [PATCH] Fix empty contact in missed calls problem
From: Radoslaw Jablonski @ 2010-08-16 13:03 UTC (permalink / raw)
To: linux-bluetooth; +Cc: Radoslaw Jablonski
Fixed problem with tracker queries for calls history - previously call
without contact in phonebook was missing in some scenario for pull
requests.
---
plugins/phonebook-tracker.c | 28 ++++------------------------
1 files changed, 4 insertions(+), 24 deletions(-)
diff --git a/plugins/phonebook-tracker.c b/plugins/phonebook-tracker.c
index 705460d..618ce8d 100644
--- a/plugins/phonebook-tracker.c
+++ b/plugins/phonebook-tracker.c
@@ -96,7 +96,7 @@
"} GROUP BY ?c"
#define MISSED_CALLS_QUERY \
- "SELECT ?v nco:fullname(?c) " \
+ "SELECT nco:phoneNumber(?h) nco:fullname(?c) " \
"nco:nameFamily(?c) nco:nameGiven(?c) " \
"nco:nameAdditional(?c) nco:nameHonorificPrefix(?c) " \
"nco:nameHonorificSuffix(?c) nco:emailAddress(?e) " \
@@ -115,10 +115,6 @@
"?h a nco:FaxNumber ; " \
"nco:phoneNumber ?f . " \
"}" \
- "OPTIONAL {" \
- "?h a nco:VoicePhoneNumber ; " \
- "nco:phoneNumber ?v" \
- "} " \
"} " \
"OPTIONAL { ?c nco:hasEmailAddress ?e . } " \
"OPTIONAL { ?c nco:hasPostalAddress ?p . } " \
@@ -143,7 +139,7 @@
"} ORDER BY DESC(nmo:receivedDate(?call))"
#define INCOMING_CALLS_QUERY \
- "SELECT ?v nco:fullname(?c) " \
+ "SELECT nco:phoneNumber(?h) nco:fullname(?c) " \
"nco:nameFamily(?c) nco:nameGiven(?c) " \
"nco:nameAdditional(?c) nco:nameHonorificPrefix(?c) " \
"nco:nameHonorificSuffix(?c) nco:emailAddress(?e) " \
@@ -162,10 +158,6 @@
"?h a nco:FaxNumber ; " \
"nco:phoneNumber ?f . " \
"}" \
- "OPTIONAL {" \
- "?h a nco:VoicePhoneNumber ; " \
- "nco:phoneNumber ?v" \
- "} " \
"} " \
"OPTIONAL { ?c nco:hasEmailAddress ?e . } " \
"OPTIONAL { ?c nco:hasPostalAddress ?p . } " \
@@ -190,7 +182,7 @@
"} ORDER BY DESC(nmo:receivedDate(?call))"
#define OUTGOING_CALLS_QUERY \
- "SELECT ?v nco:fullname(?c) " \
+ "SELECT nco:phoneNumber(?h) nco:fullname(?c) " \
"nco:nameFamily(?c) nco:nameGiven(?c) " \
"nco:nameAdditional(?c) nco:nameHonorificPrefix(?c) " \
"nco:nameHonorificSuffix(?c) nco:emailAddress(?e) " \
@@ -208,10 +200,6 @@
"?h a nco:FaxNumber ; " \
"nco:phoneNumber ?f . " \
"}" \
- "OPTIONAL {" \
- "?h a nco:VoicePhoneNumber ; " \
- "nco:phoneNumber ?v" \
- "} " \
"} " \
"OPTIONAL { ?c nco:hasEmailAddress ?e . } " \
"OPTIONAL { ?c nco:hasPostalAddress ?p . } " \
@@ -235,7 +223,7 @@
"} ORDER BY DESC(nmo:sentDate(?call))"
#define COMBINED_CALLS_QUERY \
- "SELECT ?v nco:fullname(?c) " \
+ "SELECT nco:phoneNumber(?h) nco:fullname(?c) " \
"nco:nameFamily(?c) nco:nameGiven(?c) " \
"nco:nameAdditional(?c) nco:nameHonorificPrefix(?c) " \
"nco:nameHonorificSuffix(?c) nco:emailAddress(?e) " \
@@ -254,10 +242,6 @@
"?h a nco:FaxNumber ; " \
"nco:phoneNumber ?f . " \
"}" \
- "OPTIONAL {" \
- "?h a nco:VoicePhoneNumber ; " \
- "nco:phoneNumber ?v" \
- "} " \
"} " \
"OPTIONAL { ?c nco:hasEmailAddress ?e . } " \
"OPTIONAL { ?c nco:hasPostalAddress ?p . } " \
@@ -275,10 +259,6 @@
"?h a nco:FaxNumber ; " \
"nco:phoneNumber ?f . " \
"}" \
- "OPTIONAL {" \
- "?h a nco:VoicePhoneNumber ; " \
- "nco:phoneNumber ?v" \
- "} " \
"} " \
"OPTIONAL { ?c nco:hasEmailAddress ?e . } " \
"OPTIONAL { ?c nco:hasPostalAddress ?p . } " \
--
1.7.0.4
^ permalink raw reply related
* Re: [GSoC'10] : New Command Line Tool(s) for bluez
From: Alexander Orlenko @ 2010-08-16 12:06 UTC (permalink / raw)
To: Bastien Nocera; +Cc: Andrei Emeltchenko, linux-bluetooth
In-Reply-To: <1281951653.9775.7.camel@localhost.localdomain>
> Shame, but I won't hold you against that :)
Why? I wrote tool to generate gobjects from bluez/obexd doc api files.
And my implementation has methods for easy properties access and
supports properties caching (for example), and some others features.
On 16 August 2010 20:40, Bastien Nocera <hadess@hadess.net> wrote:
> On Mon, 2010-08-16 at 10:24 +1100, Alexander Orlenko wrote:
>> Hi everyone,
>>
>> I updated project info page at http://hostisdown.org/gsoc/projects/bluez-tools
>> Created project home page: http://code.google.com/p/bluez-tools
>> Current release available for download: 0.1.18-6432
>>
>> Code of my project does not based on non-GTK parts of
>> libgnome-bluetooth. I wrote glib gobjects for all bluez dbus
>> interfaces.
>
> Shame, but I won't hold you against that :)
>
>> I will continue developing my project after end of GSoC.
>
> Hopefully people will package it for distributions so we don't get as
> many requests for command-line pairing agents :)
>
> Cheers
>
>
^ permalink raw reply
* Re: [PATCH 2/2] Fix not storing tty id on pnatd plugin
From: Johan Hedberg @ 2010-08-16 11:23 UTC (permalink / raw)
To: Luiz Augusto von Dentz; +Cc: linux-bluetooth
In-Reply-To: <1281957191-6964-2-git-send-email-luiz.dentz@gmail.com>
Hi Luiz,
On Mon, Aug 16, 2010, Luiz Augusto von Dentz wrote:
> From: Luiz Augusto von Dentz <luiz.dentz-von@nokia.com>
>
> The code used to create the port stored the id in a local variable
> instead of storing it in the client data which is used to release the
> port once disconnected.
Nice catch. The patch is now upstream.
Johan
^ permalink raw reply
* Re: [PATCH 1/2] Fix using wrong argument in test-serial
From: Johan Hedberg @ 2010-08-16 11:22 UTC (permalink / raw)
To: Luiz Augusto von Dentz; +Cc: linux-bluetooth
In-Reply-To: <1281957191-6964-1-git-send-email-luiz.dentz@gmail.com>
Hi Luiz,
On Mon, Aug 16, 2010, Luiz Augusto von Dentz wrote:
> From: Luiz Augusto von Dentz <luiz.dentz-von@nokia.com>
>
> ---
> test/test-serial | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/test/test-serial b/test/test-serial
> index ed151dc..cc496df 100755
> --- a/test/test-serial
> +++ b/test/test-serial
> @@ -29,7 +29,7 @@ if (len(args) < 1):
> print "Usage: %s <address> [service]" % (sys.argv[0])
> sys.exit(1)
>
> -address = sys.argv[0]
> +address = args[0]
>
> if (len(args) < 2):
> service = "spp"
The patch is now upstream. Thanks.
Johan
^ permalink raw reply
* [PATCH 2/2] Fix not storing tty id on pnatd plugin
From: Luiz Augusto von Dentz @ 2010-08-16 11:13 UTC (permalink / raw)
To: linux-bluetooth
In-Reply-To: <1281957191-6964-1-git-send-email-luiz.dentz@gmail.com>
From: Luiz Augusto von Dentz <luiz.dentz-von@nokia.com>
The code used to create the port stored the id in a local variable
instead of storing it in the client data which is used to release the
port once disconnected.
---
plugins/pnat.c | 9 +++++----
1 files changed, 5 insertions(+), 4 deletions(-)
diff --git a/plugins/pnat.c b/plugins/pnat.c
index f9136a4..3f5222f 100644
--- a/plugins/pnat.c
+++ b/plugins/pnat.c
@@ -238,7 +238,7 @@ static gboolean create_tty(struct dun_server *server)
{
struct dun_client *client = &server->client;
struct rfcomm_dev_req req;
- int dev, sk = g_io_channel_unix_get_fd(client->io);
+ int sk = g_io_channel_unix_get_fd(client->io);
memset(&req, 0, sizeof(req));
req.dev_id = -1;
@@ -251,13 +251,14 @@ static gboolean create_tty(struct dun_server *server)
BT_IO_OPT_DEST_CHANNEL, &req.channel,
BT_IO_OPT_INVALID);
- dev = ioctl(sk, RFCOMMCREATEDEV, &req);
- if (dev < 0) {
+ client->tty_id = ioctl(sk, RFCOMMCREATEDEV, &req);
+ if (client->tty_id < 0) {
error("Can't create RFCOMM TTY: %s", strerror(errno));
return FALSE;
}
- snprintf(client->tty_name, PATH_MAX - 1, "/dev/rfcomm%d", dev);
+ snprintf(client->tty_name, PATH_MAX - 1, "/dev/rfcomm%d",
+ client->tty_id);
client->tty_tries = TTY_TRIES;
--
1.7.0.4
^ permalink raw reply related
* [PATCH 1/2] Fix using wrong argument in test-serial
From: Luiz Augusto von Dentz @ 2010-08-16 11:13 UTC (permalink / raw)
To: linux-bluetooth
From: Luiz Augusto von Dentz <luiz.dentz-von@nokia.com>
---
test/test-serial | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/test/test-serial b/test/test-serial
index ed151dc..cc496df 100755
--- a/test/test-serial
+++ b/test/test-serial
@@ -29,7 +29,7 @@ if (len(args) < 1):
print "Usage: %s <address> [service]" % (sys.argv[0])
sys.exit(1)
-address = sys.argv[0]
+address = args[0]
if (len(args) < 2):
service = "spp"
--
1.7.0.4
^ permalink raw reply related
* Re: [GSoC'10] : New Command Line Tool(s) for bluez
From: Bastien Nocera @ 2010-08-16 9:40 UTC (permalink / raw)
To: Alexander Orlenko; +Cc: Andrei Emeltchenko, linux-bluetooth
In-Reply-To: <AANLkTimW1SmfZ+j=F7kTSwosdz=kh+g9ofcqdTeGE7CB@mail.gmail.com>
On Mon, 2010-08-16 at 10:24 +1100, Alexander Orlenko wrote:
> Hi everyone,
>
> I updated project info page at http://hostisdown.org/gsoc/projects/bluez-tools
> Created project home page: http://code.google.com/p/bluez-tools
> Current release available for download: 0.1.18-6432
>
> Code of my project does not based on non-GTK parts of
> libgnome-bluetooth. I wrote glib gobjects for all bluez dbus
> interfaces.
Shame, but I won't hold you against that :)
> I will continue developing my project after end of GSoC.
Hopefully people will package it for distributions so we don't get as
many requests for command-line pairing agents :)
Cheers
^ permalink raw reply
* Re: [GSoC'10] : New Command Line Tool(s) for bluez
From: Alexander Orlenko @ 2010-08-15 23:24 UTC (permalink / raw)
To: Andrei Emeltchenko; +Cc: Bastien Nocera, linux-bluetooth
In-Reply-To: <AANLkTik3d0rY2QNrhevwzPz28VQwKuj7A5s-9l152H4Y@mail.gmail.com>
Hi everyone,
I updated project info page at http://hostisdown.org/gsoc/projects/bluez-tools
Created project home page: http://code.google.com/p/bluez-tools
Current release available for download: 0.1.18-6432
Code of my project does not based on non-GTK parts of
libgnome-bluetooth. I wrote glib gobjects for all bluez dbus
interfaces.
I will continue developing my project after end of GSoC.
On 21 May 2010 18:29, Andrei Emeltchenko
<andrei.emeltchenko.news@gmail.com> wrote:
>
> On Thu, May 20, 2010 at 4:08 PM, Bastien Nocera <hadess@hadess.net> wrote:
> > On Fri, 2010-05-21 at 00:04 +1100, Alexander Orlenko wrote:
> >> Hi everyone,
> >>
> >> My name is Alexander Orlenko, I am a GSoC student of this year. I am
> >> doing a project "bluez-tools",
> >> http://hostisdown.org/gsoc/projects/bluez-tools (a little more info
> >> about the project). I need some feedback about what approach should I
> >> take.
> >
> > I'm not sure whether you'd be interested, but you could base your code
> > on the non-GTK parts of libgnome-bluetooth, which already implements a
> > number of those things, and would just need to be wrapped up.
>
> There is also python code in bluez/test repository.
>
> -- Andrei
>
> >
> > Cheers
> >
> > --
> > To unsubscribe from this list: send the line "unsubscribe linux-bluetooth" in
> > the body of a message to majordomo@vger.kernel.org
> > More majordomo info at http://vger.kernel.org/majordomo-info.html
> >
^ permalink raw reply
* Re: [PATCH] Bluetooth: Fix inconsistent lock state with RFCOMM
From: Marcel Holtmann @ 2010-08-14 19:39 UTC (permalink / raw)
To: Gustavo F. Padovan; +Cc: linux-bluetooth, Gustavo F. Padovan
In-Reply-To: <1281797213-10940-1-git-send-email-gustavo@padovan.org>
Hi Gustavo,
> When receiving a rfcomm connection with the old dund deamon the following
> inconsistent lock state happens:
>
> [ 811.702999] =================================
> [ 811.702999] [ INFO: inconsistent lock state ]
> [ 811.702999] 2.6.35-rc1-01743-g41069ad-dirty #1
> [ 811.702999] ---------------------------------
> [ 811.702999] inconsistent {IN-SOFTIRQ-W} -> {SOFTIRQ-ON-W} usage.
> [ 811.702999] krfcommd/3892 [HC0[0]:SC0[0]:HE1:SE1] takes:
> [ 811.702999] (slock-AF_BLUETOOTH){+.?...}, at: [<ffffffffa0189b56>] rfcomm_sk_state_change+0x46/0x170 [rfcomm]
> [ 811.702999] {IN-SOFTIRQ-W} state was registered at:
> [ 811.702999] [<ffffffff8108dfa6>] __lock_acquire+0x5b6/0x1560
> [ 811.702999] [<ffffffff8108efaa>] lock_acquire+0x5a/0x70
> [ 811.702999] [<ffffffff81387b2c>] _raw_spin_lock+0x2c/0x40
> [ 811.702999] [<ffffffffa0043092>] 0xffffffffa0043092
> [ 811.702999] [<ffffffffa0044a3f>] 0xffffffffa0044a3f
> [ 811.702999] [<ffffffffa0047183>] 0xffffffffa0047183
> [ 811.702999] [<ffffffffa004798b>] 0xffffffffa004798b
> [ 811.702999] [<ffffffffa000db4b>] 0xffffffffa000db4b
> [ 811.702999] [<ffffffff81067efb>] tasklet_action+0xcb/0xe0
> [ 811.702999] [<ffffffff810685ee>] __do_softirq+0xae/0x150
> [ 811.702999] [<ffffffff81029c0c>] call_softirq+0x1c/0x30
> [ 811.702999] [<ffffffff8102bd75>] do_softirq+0x75/0xb0
> [ 811.702999] [<ffffffff8106823d>] irq_exit+0x8d/0xa0
> [ 811.702999] [<ffffffff8102b330>] do_IRQ+0x70/0xf0
> [ 811.702999] [<ffffffff81388513>] ret_from_intr+0x0/0xf
> [ 811.702999] [<ffffffff81027dfa>] cpu_idle+0x5a/0xb0
> [ 811.702999] [<ffffffff81382934>] start_secondary+0x211/0x254
> [ 811.702999] irq event stamp: 411
> [ 811.702999] hardirqs last enabled at (411): [<ffffffff81068432>] local_bh_enable_ip+0x82/0xe0
> [ 811.702999] hardirqs last disabled at (409): [<ffffffff8106860e>] __do_softirq+0xce/0x150
> [ 811.702999] softirqs last enabled at (410): [<ffffffff8106863e>] __do_softirq+0xfe/0x150
> [ 811.702999] softirqs last disabled at (391): [<ffffffff81029c0c>] call_softirq+0x1c/0x30
> [ 811.702999]
> [ 811.702999] other info that might help us debug this:
> [ 811.702999] 2 locks held by krfcommd/3892:
> [ 811.702999] #0: (rfcomm_mutex){+.+.+.}, at: [<ffffffffa0188744>] rfcomm_run+0x174/0xb20 [rfcomm]
> [ 811.702999] #1: (&(&d->lock)->rlock){+.+...}, at: [<ffffffffa0186223>] rfcomm_dlc_accept+0x53/0x100 [rfcomm]
> [ 811.702999]
> [ 811.702999] stack backtrace:
> [ 811.702999] Pid: 3892, comm: krfcommd Tainted: G W 2.6.35-rc1-01743-g41069ad-dirty #1
> [ 811.702999] Call Trace:
> [ 811.702999] [<ffffffff8108c541>] print_usage_bug+0x171/0x180
> [ 811.702999] [<ffffffff8108d323>] mark_lock+0x333/0x400
> [ 811.702999] [<ffffffff8108e02a>] __lock_acquire+0x63a/0x1560
> [ 811.702999] [<ffffffff8108e515>] ? __lock_acquire+0xb25/0x1560
> [ 811.702999] [<ffffffff8108efaa>] lock_acquire+0x5a/0x70
> [ 811.702999] [<ffffffffa0189b56>] ? rfcomm_sk_state_change+0x46/0x170 [rfcomm]
> [ 811.702999] [<ffffffff81387b2c>] _raw_spin_lock+0x2c/0x40
> [ 811.702999] [<ffffffffa0189b56>] ? rfcomm_sk_state_change+0x46/0x170 [rfcomm]
> [ 811.702999] [<ffffffffa0189b56>] rfcomm_sk_state_change+0x46/0x170 [rfcomm]
> [ 811.702999] [<ffffffffa0186239>] rfcomm_dlc_accept+0x69/0x100 [rfcomm]
> [ 811.702999] [<ffffffffa0186a49>] rfcomm_check_accept+0x59/0xd0 [rfcomm]
> [ 811.702999] [<ffffffffa0187cab>] rfcomm_recv_frame+0x9fb/0x1320 [rfcomm]
> [ 811.702999] [<ffffffff8138827b>] ? _raw_spin_unlock_irqrestore+0x3b/0x60
> [ 811.702999] [<ffffffff8108d72d>] ? trace_hardirqs_on_caller+0x13d/0x180
> [ 811.702999] [<ffffffff8108d77d>] ? trace_hardirqs_on+0xd/0x10
> [ 811.702999] [<ffffffffa01887f1>] rfcomm_run+0x221/0xb20 [rfcomm]
> [ 811.702999] [<ffffffff81385667>] ? schedule+0x267/0x5d0
> [ 811.702999] [<ffffffffa01885d0>] ? rfcomm_run+0x0/0xb20 [rfcomm]
> [ 811.702999] [<ffffffff8107afae>] kthread+0x8e/0xa0
> [ 811.702999] [<ffffffff81029b14>] kernel_thread_helper+0x4/0x10
> [ 811.702999] [<ffffffff813885bc>] ? restore_args+0x0/0x30
> [ 811.702999] [<ffffffff8107af20>] ? kthread+0x0/0xa0
> [ 811.702999] [<ffffffff81029b10>] ? kernel_thread_helper+0x0/0x10
>
> Signed-off-by: Gustavo F. Padovan <padovan@profusion.mobi>
> ---
> net/bluetooth/rfcomm/sock.c | 6 ++++--
> 1 files changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a/net/bluetooth/rfcomm/sock.c b/net/bluetooth/rfcomm/sock.c
> index 44a6232..30cd80b 100644
> --- a/net/bluetooth/rfcomm/sock.c
> +++ b/net/bluetooth/rfcomm/sock.c
> @@ -82,12 +82,14 @@ static void rfcomm_sk_data_ready(struct rfcomm_dlc *d, struct sk_buff *skb)
> static void rfcomm_sk_state_change(struct rfcomm_dlc *d, int err)
> {
> struct sock *sk = d->owner, *parent;
> + unsigned long flags;
> +
> if (!sk)
> return;
>
> BT_DBG("dlc %p state %ld err %d", d, d->state, err);
>
> - bh_lock_sock(sk);
> + spin_lock_irqsave(&sk->sk_lock.slock, flags);
>
> if (err)
> sk->sk_err = err;
> @@ -107,7 +109,7 @@ static void rfcomm_sk_state_change(struct rfcomm_dlc *d, int err)
> sk->sk_state_change(sk);
> }
>
> - bh_unlock_sock(sk);
> + spin_unlock_irqrestore(&sk->sk_lock.slock, flags);
>
> if (parent && sock_flag(sk, SOCK_ZAPPED)) {
> /* We have to drop DLC lock here, otherwise
I am missing an explanation why you fixed it this way. And also why thi
sis the right way to fix it. Directly referencing sk->sk_lock seems
pretty much wrong to me.
Regards
Marcel
^ permalink raw reply
* [PATCH] Bluetooth: Fix inconsistent lock state with RFCOMM
From: Gustavo F. Padovan @ 2010-08-14 14:46 UTC (permalink / raw)
To: linux-bluetooth; +Cc: marcel, Gustavo F. Padovan
From: Gustavo F. Padovan <padovan@profusion.mobi>
When receiving a rfcomm connection with the old dund deamon the following
inconsistent lock state happens:
[ 811.702999] =================================
[ 811.702999] [ INFO: inconsistent lock state ]
[ 811.702999] 2.6.35-rc1-01743-g41069ad-dirty #1
[ 811.702999] ---------------------------------
[ 811.702999] inconsistent {IN-SOFTIRQ-W} -> {SOFTIRQ-ON-W} usage.
[ 811.702999] krfcommd/3892 [HC0[0]:SC0[0]:HE1:SE1] takes:
[ 811.702999] (slock-AF_BLUETOOTH){+.?...}, at: [<ffffffffa0189b56>] rfcomm_sk_state_change+0x46/0x170 [rfcomm]
[ 811.702999] {IN-SOFTIRQ-W} state was registered at:
[ 811.702999] [<ffffffff8108dfa6>] __lock_acquire+0x5b6/0x1560
[ 811.702999] [<ffffffff8108efaa>] lock_acquire+0x5a/0x70
[ 811.702999] [<ffffffff81387b2c>] _raw_spin_lock+0x2c/0x40
[ 811.702999] [<ffffffffa0043092>] 0xffffffffa0043092
[ 811.702999] [<ffffffffa0044a3f>] 0xffffffffa0044a3f
[ 811.702999] [<ffffffffa0047183>] 0xffffffffa0047183
[ 811.702999] [<ffffffffa004798b>] 0xffffffffa004798b
[ 811.702999] [<ffffffffa000db4b>] 0xffffffffa000db4b
[ 811.702999] [<ffffffff81067efb>] tasklet_action+0xcb/0xe0
[ 811.702999] [<ffffffff810685ee>] __do_softirq+0xae/0x150
[ 811.702999] [<ffffffff81029c0c>] call_softirq+0x1c/0x30
[ 811.702999] [<ffffffff8102bd75>] do_softirq+0x75/0xb0
[ 811.702999] [<ffffffff8106823d>] irq_exit+0x8d/0xa0
[ 811.702999] [<ffffffff8102b330>] do_IRQ+0x70/0xf0
[ 811.702999] [<ffffffff81388513>] ret_from_intr+0x0/0xf
[ 811.702999] [<ffffffff81027dfa>] cpu_idle+0x5a/0xb0
[ 811.702999] [<ffffffff81382934>] start_secondary+0x211/0x254
[ 811.702999] irq event stamp: 411
[ 811.702999] hardirqs last enabled at (411): [<ffffffff81068432>] local_bh_enable_ip+0x82/0xe0
[ 811.702999] hardirqs last disabled at (409): [<ffffffff8106860e>] __do_softirq+0xce/0x150
[ 811.702999] softirqs last enabled at (410): [<ffffffff8106863e>] __do_softirq+0xfe/0x150
[ 811.702999] softirqs last disabled at (391): [<ffffffff81029c0c>] call_softirq+0x1c/0x30
[ 811.702999]
[ 811.702999] other info that might help us debug this:
[ 811.702999] 2 locks held by krfcommd/3892:
[ 811.702999] #0: (rfcomm_mutex){+.+.+.}, at: [<ffffffffa0188744>] rfcomm_run+0x174/0xb20 [rfcomm]
[ 811.702999] #1: (&(&d->lock)->rlock){+.+...}, at: [<ffffffffa0186223>] rfcomm_dlc_accept+0x53/0x100 [rfcomm]
[ 811.702999]
[ 811.702999] stack backtrace:
[ 811.702999] Pid: 3892, comm: krfcommd Tainted: G W 2.6.35-rc1-01743-g41069ad-dirty #1
[ 811.702999] Call Trace:
[ 811.702999] [<ffffffff8108c541>] print_usage_bug+0x171/0x180
[ 811.702999] [<ffffffff8108d323>] mark_lock+0x333/0x400
[ 811.702999] [<ffffffff8108e02a>] __lock_acquire+0x63a/0x1560
[ 811.702999] [<ffffffff8108e515>] ? __lock_acquire+0xb25/0x1560
[ 811.702999] [<ffffffff8108efaa>] lock_acquire+0x5a/0x70
[ 811.702999] [<ffffffffa0189b56>] ? rfcomm_sk_state_change+0x46/0x170 [rfcomm]
[ 811.702999] [<ffffffff81387b2c>] _raw_spin_lock+0x2c/0x40
[ 811.702999] [<ffffffffa0189b56>] ? rfcomm_sk_state_change+0x46/0x170 [rfcomm]
[ 811.702999] [<ffffffffa0189b56>] rfcomm_sk_state_change+0x46/0x170 [rfcomm]
[ 811.702999] [<ffffffffa0186239>] rfcomm_dlc_accept+0x69/0x100 [rfcomm]
[ 811.702999] [<ffffffffa0186a49>] rfcomm_check_accept+0x59/0xd0 [rfcomm]
[ 811.702999] [<ffffffffa0187cab>] rfcomm_recv_frame+0x9fb/0x1320 [rfcomm]
[ 811.702999] [<ffffffff8138827b>] ? _raw_spin_unlock_irqrestore+0x3b/0x60
[ 811.702999] [<ffffffff8108d72d>] ? trace_hardirqs_on_caller+0x13d/0x180
[ 811.702999] [<ffffffff8108d77d>] ? trace_hardirqs_on+0xd/0x10
[ 811.702999] [<ffffffffa01887f1>] rfcomm_run+0x221/0xb20 [rfcomm]
[ 811.702999] [<ffffffff81385667>] ? schedule+0x267/0x5d0
[ 811.702999] [<ffffffffa01885d0>] ? rfcomm_run+0x0/0xb20 [rfcomm]
[ 811.702999] [<ffffffff8107afae>] kthread+0x8e/0xa0
[ 811.702999] [<ffffffff81029b14>] kernel_thread_helper+0x4/0x10
[ 811.702999] [<ffffffff813885bc>] ? restore_args+0x0/0x30
[ 811.702999] [<ffffffff8107af20>] ? kthread+0x0/0xa0
[ 811.702999] [<ffffffff81029b10>] ? kernel_thread_helper+0x0/0x10
Signed-off-by: Gustavo F. Padovan <padovan@profusion.mobi>
---
net/bluetooth/rfcomm/sock.c | 6 ++++--
1 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/net/bluetooth/rfcomm/sock.c b/net/bluetooth/rfcomm/sock.c
index 44a6232..30cd80b 100644
--- a/net/bluetooth/rfcomm/sock.c
+++ b/net/bluetooth/rfcomm/sock.c
@@ -82,12 +82,14 @@ static void rfcomm_sk_data_ready(struct rfcomm_dlc *d, struct sk_buff *skb)
static void rfcomm_sk_state_change(struct rfcomm_dlc *d, int err)
{
struct sock *sk = d->owner, *parent;
+ unsigned long flags;
+
if (!sk)
return;
BT_DBG("dlc %p state %ld err %d", d, d->state, err);
- bh_lock_sock(sk);
+ spin_lock_irqsave(&sk->sk_lock.slock, flags);
if (err)
sk->sk_err = err;
@@ -107,7 +109,7 @@ static void rfcomm_sk_state_change(struct rfcomm_dlc *d, int err)
sk->sk_state_change(sk);
}
- bh_unlock_sock(sk);
+ spin_unlock_irqrestore(&sk->sk_lock.slock, flags);
if (parent && sock_flag(sk, SOCK_ZAPPED)) {
/* We have to drop DLC lock here, otherwise
--
1.7.1.1
^ permalink raw reply related
* [PATCH] Bluetooth: Implement LE Set Advertise Enable cmd
From: Anderson Briglia @ 2010-08-13 21:01 UTC (permalink / raw)
To: linux-bluetooth; +Cc: Anderson Briglia
This patch implements LE Set Advertise Enable command for dual mode and
Low Energy hci controllers.
Signed-off-by: Anderson Briglia <anderson.briglia@openbossa.org>
---
include/net/bluetooth/hci.h | 7 +++++++
net/bluetooth/hci_core.c | 15 +++++++++++++++
net/bluetooth/hci_event.c | 27 +++++++++++++++++++++++++++
net/bluetooth/hci_sock.c | 1 +
4 files changed, 50 insertions(+), 0 deletions(-)
diff --git a/include/net/bluetooth/hci.h b/include/net/bluetooth/hci.h
index bcbdd6d..1713849 100644
--- a/include/net/bluetooth/hci.h
+++ b/include/net/bluetooth/hci.h
@@ -76,6 +76,7 @@ enum {
HCI_INQUIRY,
HCI_RAW,
+ HCI_LE_ADV,
};
/* HCI ioctl defines */
@@ -104,6 +105,7 @@ enum {
#define HCIUNBLOCKADDR _IOW('H', 231, int)
#define HCIINQUIRY _IOR('H', 240, int)
+#define HCILESETADV _IOR('H', 241, int)
/* HCI timeouts */
#define HCI_CONNECT_TIMEOUT (40000) /* 40 seconds */
@@ -593,6 +595,11 @@ struct hci_rp_read_bd_addr {
bdaddr_t bdaddr;
} __packed;
+/* --- HCI LE Commands --- */
+#define HCI_OP_LE_SET_ADVERTISE_ENABLE 0x200a
+ #define ADVERTISE_ENABLED 0x01
+ #define ADVERTISE_DISABLED 0x00
+
/* ---- HCI Events ---- */
#define HCI_EV_INQUIRY_COMPLETE 0x01
diff --git a/net/bluetooth/hci_core.c b/net/bluetooth/hci_core.c
index c52f091..2bdb954 100644
--- a/net/bluetooth/hci_core.c
+++ b/net/bluetooth/hci_core.c
@@ -294,6 +294,16 @@ static void hci_linkpol_req(struct hci_dev *hdev, unsigned long opt)
hci_send_cmd(hdev, HCI_OP_WRITE_DEF_LINK_POLICY, 2, &policy);
}
+static void hci_le_advertise_req(struct hci_dev *hdev, unsigned long opt)
+{
+ __u8 leadv = opt;
+
+ BT_DBG("%s %x", hdev->name, leadv);
+
+ /* LE Advertising mode */
+ hci_send_cmd(hdev, HCI_OP_LE_SET_ADVERTISE_ENABLE, 1, &leadv);
+}
+
/* Get HCI device by index.
* Device is held on return. */
struct hci_dev *hci_dev_get(int index)
@@ -739,6 +749,11 @@ int hci_dev_cmd(unsigned int cmd, void __user *arg)
hdev->sco_pkts = *((__u16 *) &dr.dev_opt + 0);
break;
+ case HCILESETADV:
+ err = hci_request(hdev, hci_le_advertise_req, dr.dev_opt,
+ msecs_to_jiffies(HCI_INIT_TIMEOUT));
+ break;
+
default:
err = -EINVAL;
break;
diff --git a/net/bluetooth/hci_event.c b/net/bluetooth/hci_event.c
index bfef5ba..c86c655 100644
--- a/net/bluetooth/hci_event.c
+++ b/net/bluetooth/hci_event.c
@@ -822,6 +822,29 @@ static void hci_cs_exit_sniff_mode(struct hci_dev *hdev, __u8 status)
hci_dev_unlock(hdev);
}
+static void hci_cc_le_set_advertise(struct hci_dev *hdev, struct sk_buff *skb)
+{
+ __u8 status = *((__u8 *) skb->data);
+ void *sent;
+
+ BT_DBG("%s status 0x%x", hdev->name, status);
+
+ sent = hci_sent_cmd_data(hdev, HCI_OP_LE_SET_ADVERTISE_ENABLE);
+ if (!sent)
+ return;
+
+ if (!status) {
+ __u8 param = *((__u8 *) sent);
+
+ clear_bit(HCI_LE_ADV, &hdev->flags);
+
+ if (param & ADVERTISE_ENABLED)
+ set_bit(HCI_LE_ADV, &hdev->flags);
+ }
+
+ hci_req_complete(hdev, status);
+}
+
static inline void hci_inquiry_complete_evt(struct hci_dev *hdev, struct sk_buff *skb)
{
__u8 status = *((__u8 *) skb->data);
@@ -1310,6 +1333,10 @@ static inline void hci_cmd_complete_evt(struct hci_dev *hdev, struct sk_buff *sk
hci_cc_read_bd_addr(hdev, skb);
break;
+ case HCI_OP_LE_SET_ADVERTISE_ENABLE:
+ hci_cc_le_set_advertise(hdev, skb);
+ break;
+
default:
BT_DBG("%s opcode 0x%x", hdev->name, opcode);
break;
diff --git a/net/bluetooth/hci_sock.c b/net/bluetooth/hci_sock.c
index 83acd16..0286d32 100644
--- a/net/bluetooth/hci_sock.c
+++ b/net/bluetooth/hci_sock.c
@@ -335,6 +335,7 @@ static int hci_sock_ioctl(struct socket *sock, unsigned int cmd, unsigned long a
case HCISETLINKMODE:
case HCISETACLMTU:
case HCISETSCOMTU:
+ case HCILESETADV:
if (!capable(CAP_NET_ADMIN))
return -EACCES;
return hci_dev_cmd(cmd, argp);
--
1.7.0.4
^ permalink raw reply related
* Re: [RFC 3/7] Bluetooth: Add FCS awareness to L2CAP HCI fragmentation.
From: Gustavo F. Padovan @ 2010-08-13 15:41 UTC (permalink / raw)
To: Mat Martineau; +Cc: linux-bluetooth, marcel, rshaffer
In-Reply-To: <alpine.DEB.2.00.1008121626340.8460@linux-sea-02>
Hi Mat,
* Mat Martineau <mathewm@codeaurora.org> [2010-08-12 16:36:57 -0700]:
>
>
> On Wed, 11 Aug 2010, Gustavo F. Padovan wrote:
>
> >Hi Mat,
> >
> >* Gustavo F. Padovan <gustavo@padovan.org> [2010-08-11 00:35:41 -0300]:
> >
> >>* Mat Martineau <mathewm@codeaurora.org> [2010-08-10 12:15:00 -0700]:
> >>
> >>>In order to not limit ERTM and streaming mode PDUs to the HCI MTU
> >>>size, L2CAP must be able to split PDUs in to multple HCI fragments.
> >>>This is done by allocating space for the FCS in the last fragment.
> >>>
> >>>Signed-off-by: Mat Martineau <mathewm@codeaurora.org>
> >>>---
> >>> net/bluetooth/l2cap.c | 39 ++++++++++++++++++++++++++++++++++-----
> >>> 1 files changed, 34 insertions(+), 5 deletions(-)
> >>>
> >>>diff --git a/net/bluetooth/l2cap.c b/net/bluetooth/l2cap.c
> >>>index aa69c84..b485c4a 100644
> >>>--- a/net/bluetooth/l2cap.c
> >>>+++ b/net/bluetooth/l2cap.c
> >>>@@ -1664,31 +1664,63 @@ static inline int l2cap_skbuff_fromiovec(struct sock *sk, struct msghdr *msg, in
> >>> {
> >>> struct l2cap_conn *conn = l2cap_pi(sk)->conn;
> >>> struct sk_buff **frag;
> >>>+ struct sk_buff *final;
> >>> int err, sent = 0;
> >>>
> >>>+ BT_DBG("sk %p, msg %p, len %d, count %d, skb %p", sk,
> >>>+ msg, (int)len, (int)count, skb);
> >>>+
> >>> if (memcpy_fromiovec(skb_put(skb, count), msg->msg_iov, count))
> >>> return -EFAULT;
> >>>
> >>> sent += count;
> >>> len -= count;
> >>>+ final = skb;
> >>>
> >>> /* Continuation fragments (no L2CAP header) */
> >>> frag = &skb_shinfo(skb)->frag_list;
> >>> while (len) {
> >>>+ int skblen;
> >>> count = min_t(unsigned int, conn->mtu, len);
> >>>
> >>>- *frag = bt_skb_send_alloc(sk, count, msg->msg_flags & MSG_DONTWAIT, &err);
> >>>+ /* Add room for the FCS if it fits */
> >>>+ if (l2cap_pi(sk)->fcs == L2CAP_FCS_CRC16 &&
> >>>+ len + L2CAP_FCS_SIZE <= conn->mtu)
> >>
> >>You don't need to check for (len + L2CAP_FCS_SIZE <= conn=mtu) here.
> >>Section 5.1 point that:
> >>
> >>"Unlike the B-Frame length field, the I-frame length field may be greater
> >>than the configured MTU because it includes the octet lengths of the
> >>Control, L2CAP SDU Length (when present), and frame check sequence
> >>fields as well as the Information octets."
> >>
> >>From that I understand "len <=" and not "len + L2CAP_FCS_SIZE <="
> >
> >So here you might want to the check if we support FCS, and then add 2 to
> >skblen.
>
> That's what the code does, without violating the HCI MTU.
Yes, you are right!
>
> >>>+ skblen = count + L2CAP_FCS_SIZE;
> >>>+ else
> >>>+ skblen = count;
> >>>+
> >>>+ *frag = bt_skb_send_alloc(sk, skblen,
> >>>+ msg->msg_flags & MSG_DONTWAIT, &err);
> >>> if (!*frag)
> >>> return -EFAULT;
> >>>- if (memcpy_fromiovec(skb_put(*frag, count), msg->msg_iov, count))
> >>>+
> >>>+ if (memcpy_fromiovec(skb_put(*frag, count),
> >>>+ msg->msg_iov, count))
> >>> return -EFAULT;
> >>>
> >>> sent += count;
> >>> len -= count;
> >>>
> >>>+ final = *frag;
> >>>+
> >>> frag = &(*frag)->next;
> >>> }
> >>>
> >>>+ if (l2cap_pi(sk)->fcs == L2CAP_FCS_CRC16) {
> >>>+ if (skb_tailroom(final) < L2CAP_FCS_SIZE) {
> >>>+ *frag = bt_skb_send_alloc(sk, L2CAP_FCS_SIZE,
> >>>+ msg->msg_flags & MSG_DONTWAIT,
> >>>+ &err);
> >
> >Why do we need to check for FCS again? We already added it required
> >space to the last fragment.
> >
>
> If there was room in the HCI fragment, count+2 bytes were allocated
> with bt_skb_send_alloc. However, only count bytes were used by
> skb_put.
>
> This final block of code is doing two things:
>
> 1. Allocating a final HCI fragment for the FCS if there was not
> room for the FCS in the last data fragment.
>
> 2. Doing the skb_put for the FCS bytes.
>
> I will add some comments to this code to help clarify what's going on.
Ok, and do the other way around in the if:
if (l2cap_pi(sk)->fcs != L2CAP_FCS_CRC16)
return sent;
if (skb_tailroom(...
--
Gustavo F. Padovan
http://padovan.org
^ permalink raw reply
* [PATCH v2] Firmware download for Qualcomm Bluetooth devices
From: Matthew Wilson @ 2010-08-13 15:33 UTC (permalink / raw)
To: linux-bluetooth; +Cc: marcel, johan.hedberg, rshaffer, Matthew Wilson
In-Reply-To: <4C620A8A.9030707@codeaurora.org>
Configures device address from hciattach parameter.
UART speed limited to 115200.
Requires separate device specific firmware.
---
Makefile.tools | 3 +-
tools/hciattach.c | 8 ++
tools/hciattach.h | 1 +
tools/hciattach_qualcomm.c | 279 ++++++++++++++++++++++++++++++++++++++++++++
4 files changed, 290 insertions(+), 1 deletions(-)
create mode 100644 tools/hciattach_qualcomm.c
diff --git a/Makefile.tools b/Makefile.tools
index 2dbf925..0ce7b75 100644
--- a/Makefile.tools
+++ b/Makefile.tools
@@ -23,7 +23,8 @@ tools_l2ping_LDADD = lib/libbluetooth.la
tools_hciattach_SOURCES = tools/hciattach.c tools/hciattach.h \
tools/hciattach_st.c \
tools/hciattach_ti.c \
- tools/hciattach_tialt.c
+ tools/hciattach_tialt.c \
+ tools/hciattach_qualcomm.c
tools_hciattach_LDADD = lib/libbluetooth.la
tools_hciconfig_SOURCES = tools/hciconfig.c tools/csr.h tools/csr.c \
diff --git a/tools/hciattach.c b/tools/hciattach.c
index 81aea7b..4d4b0a1 100644
--- a/tools/hciattach.c
+++ b/tools/hciattach.c
@@ -299,6 +299,11 @@ static int texasalt(int fd, struct uart_t *u, struct termios *ti)
return texasalt_init(fd, u->speed, ti);
}
+static int qualcomm(int fd, struct uart_t *u, struct termios *ti)
+{
+ return qualcomm_init(fd, u->speed, ti, u->bdaddr);
+}
+
static int read_check(int fd, void *buf, int count)
{
int res;
@@ -1073,6 +1078,9 @@ struct uart_t uart[] = {
/* Broadcom BCM2035 */
{ "bcm2035", 0x0A5C, 0x2035, HCI_UART_H4, 115200, 460800, FLOW_CTL, NULL, bcm2035 },
+ /* QUALCOMM BTS */
+ { "qualcomm", 0x0000, 0x0000, HCI_UART_H4, 115200, 115200, FLOW_CTL, NULL, qualcomm },
+
{ NULL, 0 }
};
diff --git a/tools/hciattach.h b/tools/hciattach.h
index c0b80a1..3d5605b 100644
--- a/tools/hciattach.h
+++ b/tools/hciattach.h
@@ -49,3 +49,4 @@ int texas_post(int fd, struct termios *ti);
int texasalt_init(int fd, int speed, struct termios *ti);
int stlc2500_init(int fd, bdaddr_t *bdaddr);
int bgb2xx_init(int dd, bdaddr_t *bdaddr);
+int qualcomm_init(int fd, int speed, struct termios *ti, const char *bdaddr);
diff --git a/tools/hciattach_qualcomm.c b/tools/hciattach_qualcomm.c
new file mode 100644
index 0000000..31ca3c8
--- /dev/null
+++ b/tools/hciattach_qualcomm.c
@@ -0,0 +1,279 @@
+/*
+ *
+ * BlueZ - Bluetooth protocol stack for Linux
+ *
+ * Copyright (C) 2005-2010 Marcel Holtmann <marcel@holtmann.org>
+ * Copyright (c) 2010, Code Aurora Forum. All rights reserved.
+ *
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA
+ *
+ */
+
+#ifdef HAVE_CONFIG_H
+#include <config.h>
+#endif
+
+#include <stdio.h>
+#include <errno.h>
+#include <fcntl.h>
+#include <unistd.h>
+#include <stdlib.h>
+#include <string.h>
+#include <signal.h>
+#include <syslog.h>
+#include <termios.h>
+#include <time.h>
+#include <sys/time.h>
+#include <sys/poll.h>
+#include <sys/param.h>
+#include <sys/ioctl.h>
+#include <sys/socket.h>
+#include <sys/uio.h>
+
+#include <bluetooth/bluetooth.h>
+#include <bluetooth/hci.h>
+#include <bluetooth/hci_lib.h>
+
+#include "hciattach.h"
+
+#define FAILIF(x, args...) do { \
+ if (x) { \
+ fprintf(stderr, ##args); \
+ return -1; \
+ } \
+} while(0)
+
+typedef struct {
+ uint8_t uart_prefix;
+ hci_event_hdr hci_hdr;
+ evt_cmd_complete cmd_complete;
+ uint8_t status;
+ uint8_t data[16];
+} __attribute__((packed)) command_complete_t;
+
+
+static int read_command_complete(int fd, unsigned short opcode, unsigned char len) {
+ command_complete_t resp;
+ unsigned char vsevent[512];
+ int n;
+
+ /* Read reply. */
+ n = read_hci_event(fd, vsevent, sizeof(vsevent));
+ FAILIF(n < 0, "Failed to read response");
+
+ FAILIF(vsevent[1] != 0xFF, "Failed to read response");
+
+ n = read_hci_event(fd, (unsigned char *)&resp, sizeof(resp));
+ FAILIF(n < 0, "Failed to read response");
+
+ FAILIF(resp.hci_hdr.evt != EVT_CMD_COMPLETE, /* event must be event-complete */
+ "Error in response: not a cmd-complete event, "
+ "but 0x%02x!\n", resp.hci_hdr.evt);
+
+ FAILIF(resp.hci_hdr.plen < 4, /* plen >= 4 for EVT_CMD_COMPLETE */
+ "Error in response: plen is not >= 4, but 0x%02x!\n",
+ resp.hci_hdr.plen);
+
+ /* cmd-complete event: opcode */
+ FAILIF(resp.cmd_complete.opcode != 0,
+ "Error in response: opcode is 0x%04x, not 0!",
+ resp.cmd_complete.opcode);
+
+ return resp.status == 0 ? 0 : -1;
+}
+
+static int qualcomm_load_firmware(int fd, const char *firmware, const char *bdaddr_s) {
+
+ int fw = open(firmware, O_RDONLY);
+
+ fprintf(stdout, "Opening firmware file: %s\n", firmware);
+
+ FAILIF(fw < 0,
+ "Could not open firmware file %s: %s (%d).\n",
+ firmware, strerror(errno), errno);
+
+ fprintf(stdout, "Uploading firmware...\n");
+ do {
+ /* Read each command and wait for a response. */
+ unsigned char data[1024];
+ unsigned char cmdp[1 + sizeof(hci_command_hdr)];
+ hci_command_hdr *cmd = (hci_command_hdr *)(cmdp + 1);
+ int nr;
+ nr = read(fw, cmdp, sizeof(cmdp));
+ if (!nr)
+ break;
+ FAILIF(nr != sizeof(cmdp), "Could not read H4 + HCI header!\n");
+ FAILIF(*cmdp != HCI_COMMAND_PKT, "Command is not an H4 command packet!\n");
+
+ FAILIF(read(fw, data, cmd->plen) != cmd->plen,
+ "Could not read %d bytes of data for command with opcode %04x!\n",
+ cmd->plen,
+ cmd->opcode);
+
+ if ((data[0] == 1) && (data[1] == 2) && (data[2] == 6)) {
+ bdaddr_t bdaddr;
+ if (bdaddr_s != NULL) {
+ (void) str2ba(bdaddr_s, &bdaddr);
+ memcpy(&data[3], &bdaddr, sizeof(bdaddr_t));
+ }
+ }
+
+ {
+ int nw;
+ struct iovec iov_cmd[2];
+ iov_cmd[0].iov_base = cmdp;
+ iov_cmd[0].iov_len = sizeof(cmdp);
+ iov_cmd[1].iov_base = data;
+ iov_cmd[1].iov_len = cmd->plen;
+ nw = writev(fd, iov_cmd, 2);
+ FAILIF(nw != (int) sizeof(cmdp) + cmd->plen,
+ "Could not send entire command (sent only %d bytes)!\n",
+ nw);
+ }
+
+ /* Wait for response */
+ if (read_command_complete(fd,
+ cmd->opcode,
+ cmd->plen) < 0) {
+ return -1;
+ }
+
+ } while(1);
+ fprintf(stdout, "Firmware upload successful.\n");
+
+ close(fw);
+ return 0;
+}
+
+int qualcomm_init(int fd, int speed, struct termios *ti, const char *bdaddr)
+{
+ struct timespec tm = {0, 50000};
+ char cmd[5];
+ unsigned char resp[100]; /* Response */
+ char fw[100];
+ int n;
+
+ memset(resp,'\0', 100);
+
+ /* Get Manufacturer and LMP version */
+ cmd[0] = HCI_COMMAND_PKT;
+ cmd[1] = 0x01;
+ cmd[2] = 0x10;
+ cmd[3] = 0x00;
+
+ do {
+ n = write(fd, cmd, 4);
+ if (n < 0) {
+ perror("Failed to write init command (READ_LOCAL_VERSION_INFORMATION)");
+ return -1;
+ }
+ if (n < 4) {
+ fprintf(stderr, "Wanted to write 4 bytes, could only write %d. Stop\n", n);
+ return -1;
+ }
+
+ /* Read reply. */
+ if (read_hci_event(fd, resp, 100) < 0) {
+ perror("Failed to read init response (READ_LOCAL_VERSION_INFORMATION)");
+ return -1;
+ }
+
+ /* Wait for command complete event for our Opcode */
+ } while (resp[4] != cmd[1] && resp[5] != cmd[2]);
+
+ /* Verify manufacturer */
+ if ((resp[11] & 0xFF) != 0x1d)
+ fprintf(stderr,"WARNING : module's manufacturer is not Qualcomm\n");
+
+ /* Print LMP version */
+ fprintf(stderr, "Qualcomm module LMP version : 0x%02x\n", resp[10] & 0xFF);
+
+ /* Print LMP subversion */
+ {
+ unsigned short lmp_subv = resp[13] | (resp[14] << 8);
+
+ fprintf(stderr, "Qualcomm module LMP sub-version : 0x%04x\n", lmp_subv);
+
+ }
+
+ /* Get SoC type */
+ cmd[0] = HCI_COMMAND_PKT;
+ cmd[1] = 0x00;
+ cmd[2] = 0xFC;
+ cmd[3] = 0x01;
+ cmd[4] = 0x06;
+
+ do {
+ n = write(fd, cmd, 5);
+ if (n < 0) {
+ perror("Failed to write init command");
+ return -1;
+ }
+ if (n < 5) {
+ fprintf(stderr, "Wanted to write 5 bytes, could only write %d. Stop\n", n);
+ return -1;
+ }
+
+ /* Read reply. */
+ if ((n = read_hci_event(fd, resp, 100)) < 0) {
+ perror("Failed to read init response");
+ return -1;
+ }
+
+ } while (resp[3] != 0 && resp[4] != 2);
+
+ snprintf(fw, sizeof(fw),
+ "/etc/firmware/%c%c%c%c%c%c_%c%c%c%c.bin",
+ resp[18], resp[19], resp[20], resp[21],
+ resp[22], resp[23],
+ resp[32], resp[33], resp[34], resp[35]);
+
+ /* Wait for command complete event for our Opcode */
+ if (read_hci_event(fd, resp, 100) < 0) {
+ perror("Failed to read init response");
+ return -1;
+ }
+
+ qualcomm_load_firmware(fd, fw, bdaddr);
+
+ /* Reset */
+ cmd[0] = HCI_COMMAND_PKT;
+ cmd[1] = 0x03;
+ cmd[2] = 0x0C;
+ cmd[3] = 0x00;
+
+ do {
+ n = write(fd, cmd, 4);
+ if (n < 0) {
+ perror("Failed to write reset command");
+ return -1;
+ }
+ if (n < 4) {
+ fprintf(stderr, "Wanted to write 4 bytes, could only write %d. Stop\n", n);
+ return -1;
+ }
+
+ /* Read reply. */
+ if ((n = read_hci_event(fd, resp, 100)) < 0) {
+ perror("Failed to read reset response");
+ return -1;
+ }
+
+ } while (resp[4] != cmd[1] && resp[5] != cmd[2]);
+
+ nanosleep(&tm, NULL);
+ return 0;
+}
--
1.7.1.1
--
Matthew Wilson
Employee of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum
^ permalink raw reply related
* Re: resending patch to retry reset in case it failed
From: Ville Tervo @ 2010-08-13 14:08 UTC (permalink / raw)
To: Oliver Neukum; +Cc: Marcel Holtmann, linux-bluetooth, linux-usb
In-Reply-To: <201008131556.22623.oneukum@suse.de>
Hi Oliver,
On Fri, Aug 13, 2010 at 9:56 AM, Oliver Neukum <oneukum@suse.de> wrote:
>>
>> Could you share also "hciconfig hci0 revision" and "hciconfig hci0
>> version" info. And laptop model you have the chip build in.
>
> The device reported:
>
> localhost:/tmp # hciconfig hci0 version
> hci0: =A0 Type: USB
> =A0 =A0 =A0 =A0BD Address: 00:27:13:98:49:7E ACL MTU: 1021:8 SCO MTU: 64:=
1
> =A0 =A0 =A0 =A0HCI Ver: 3.0 (0x5) HCI Rev: 0x1e1 LMP Ver: 3.0 (0x5) LMP S=
ubver: 0x4203
> =A0 =A0 =A0 =A0Manufacturer: Broadcom Corporation (15)
> localhost:/tmp # hciconfig hci0 revision
> hci0: =A0 Type: USB
> =A0 =A0 =A0 =A0BD Address: 00:27:13:98:49:7E ACL MTU: 1021:8 SCO MTU: 64:=
1
> =A0 =A0 =A0 =A0Firmware 225.66 / 3
>
> The laptop is a prototype. All laptops it was installed in showed the sam=
e
> problem.
Thanks. I don't have access to that hardware and cannot do much without.
hcidump from chip initialization might reveal something. Could you
send the dump also?
--=20
Ville
^ permalink raw reply
* Re: resending patch to retry reset in case it failed
From: Oliver Neukum @ 2010-08-13 13:56 UTC (permalink / raw)
To: Ville Tervo; +Cc: Marcel Holtmann, linux-bluetooth, linux-usb
In-Reply-To: <AANLkTi=odMckPT4pAOiQJm+1NWbk0diL=-9=yKBfj66W@mail.gmail.com>
Am Freitag, 13. August 2010, 15:20:08 schrieb Ville Tervo:
> On Thu, Aug 12, 2010 at 8:16 AM, Oliver Neukum <oneukum@suse.de> wrote:
> > Am Donnerstag, 12. August 2010, 13:25:23 schrieb Marcel Holtmann:
> >> Hi Oliver,
> >>
> >> > may I ask what happened to this patch?
> >> > Do you take it, want modifications or reject it?
> >> >
> >> > Regards
> >> > Oliver
> >> >
> >> > From af61f0663f095599003290b13ad6fadee1d4fb25 Mon Sep 17 00:00:00 2001
> >> > From: Oliver Neukum <oliver@neukum.org>
> >> > Date: Tue, 6 Jul 2010 08:08:42 +0200
> >> > Subject: [PATCH] bluetooth: retry reset for devices that fail
> >> >
> >> > Some devices fail to reset properly at the first attempt to reset
> >> > them under unknown circumstances. Failures can be identified by
> >> > an invalid btaddr. Retry in those cases.
> >>
> >> I was pondering about it and haven't really made up my mind with this
> >> stuff. To be honest, I don't like the patch a little bit. I can see your
> >> point why you want it, but the patch is a bit too ugly for my taste.
> >
> > I am very open to alternatives. But without that it is needed to make the
> > hardware work.
> >
> >> Tell me which device is causing this and I might be able to reproduce
> >> this and find small less ugly fix.
> >
> >
> > I happens with this hardware from Broadcom. There may be others I don't
> > know about. It is an internal dongle. I don't know whether it can be found in
> > external hardware.
> >
>
> Could you share also "hciconfig hci0 revision" and "hciconfig hci0
> version" info. And laptop model you have the chip build in.
The device reported:
localhost:/tmp # hciconfig hci0 version
hci0: Type: USB
BD Address: 00:27:13:98:49:7E ACL MTU: 1021:8 SCO MTU: 64:1
HCI Ver: 3.0 (0x5) HCI Rev: 0x1e1 LMP Ver: 3.0 (0x5) LMP Subver: 0x4203
Manufacturer: Broadcom Corporation (15)
localhost:/tmp # hciconfig hci0 revision
hci0: Type: USB
BD Address: 00:27:13:98:49:7E ACL MTU: 1021:8 SCO MTU: 64:1
Firmware 225.66 / 3
The laptop is a prototype. All laptops it was installed in showed the same
problem.
Regards
Oliver
^ permalink raw reply
* Re: [PATCH 1/3] Add mode callback to btd_adapter
From: Daniel Örstadius @ 2010-08-13 13:43 UTC (permalink / raw)
To: linux-bluetooth
In-Reply-To: <20100813124102.GA3546@jh-x301>
[-- Attachment #1: Type: text/plain, Size: 846 bytes --]
On Fri, Aug 13, 2010 at 3:41 PM, Johan Hedberg <johan.hedberg@gmail.com> wrote:
> On Fri, Aug 13, 2010, Daniel Örstadius wrote:
>> +typedef void (*btd_adapter_mode_cb) (struct btd_adapter *adapter,
>> + gboolean powered);
>> +void btd_adapter_register_mode_callback(struct btd_adapter *adapter,
>> + btd_adapter_mode_cb cb);
>
> In general this seems fine, but I think for completeness there should
> also be a unregister function. Also, since we've traditionally used the
> term mode to include also the discoverable state the name should
> probably be something like btd_adapter_register_powered_callback and
> btd_adapter_powered_cb.
>
Thanks for the feedback. Replaced 'mode' with 'powered' and added the
unregister function.
/Daniel
[-- Attachment #2: 0001-Add-powered-callback-to-btd_adapter.patch --]
[-- Type: text/x-patch, Size: 3090 bytes --]
From ead124babce407c4ec25cdce073b456979e5d431 Mon Sep 17 00:00:00 2001
From: Daniel Orstadius <daniel.orstadius@nokia.com>
Date: Fri, 13 Aug 2010 16:38:08 +0300
Subject: [PATCH] Add powered callback to btd_adapter
With this patch callback functions can be registered to the
btd_adapter struct. The functions are then called when the powered
state of the adapter changes, with a boolean argument indicating
the new state. The reason for adding the functionality is that the
Maemo6 MCE plugin needs to be notified when the adapter is powered
on or off.
---
src/adapter.c | 32 ++++++++++++++++++++++++++++++++
src/adapter.h | 7 +++++++
2 files changed, 39 insertions(+), 0 deletions(-)
diff --git a/src/adapter.c b/src/adapter.c
index fc1e123..4ad4165 100644
--- a/src/adapter.c
+++ b/src/adapter.c
@@ -135,6 +135,8 @@ struct btd_adapter {
gboolean cache_enable;
gint ref;
+
+ GSList *powered_callbacks;
};
static void adapter_set_pairable_timeout(struct btd_adapter *adapter,
@@ -2203,6 +2205,18 @@ static void adapter_disable_cod_cache(struct btd_adapter *adapter)
adapter->pending_cod = adapter->wanted_cod;
}
+static void call_adapter_powered_callbacks(struct btd_adapter *adapter,
+ gboolean powered)
+{
+ GSList *l;
+
+ for (l = adapter->powered_callbacks; l; l = l->next) {
+ btd_adapter_powered_cb cb = l->data;
+
+ cb(adapter, powered);
+ }
+}
+
static int adapter_up(struct btd_adapter *adapter, const char *mode)
{
char srcaddr[18];
@@ -2283,6 +2297,8 @@ proceed:
ADAPTER_INTERFACE, "Powered",
DBUS_TYPE_BOOLEAN, &powered);
+ call_adapter_powered_callbacks(adapter, TRUE);
+
adapter_disable_cod_cache(adapter);
return 0;
@@ -2487,6 +2503,8 @@ int adapter_stop(struct btd_adapter *adapter)
adapter->cache_enable = TRUE;
adapter->pending_cod = 0;
+ call_adapter_powered_callbacks(adapter, FALSE);
+
info("Adapter %s has been disabled", adapter->path);
return 0;
@@ -3422,3 +3440,17 @@ int adapter_ops_setup(void)
return adapter_ops->setup();
}
+
+void btd_adapter_register_powered_callback(struct btd_adapter *adapter,
+ btd_adapter_powered_cb cb)
+{
+ adapter->powered_callbacks =
+ g_slist_append(adapter->powered_callbacks, cb);
+}
+
+void btd_adapter_unregister_powered_callback(struct btd_adapter *adapter,
+ btd_adapter_powered_cb cb)
+{
+ adapter->powered_callbacks =
+ g_slist_remove(adapter->powered_callbacks, cb);
+}
diff --git a/src/adapter.h b/src/adapter.h
index a7eca0e..58853ac 100644
--- a/src/adapter.h
+++ b/src/adapter.h
@@ -188,3 +188,10 @@ struct btd_adapter_ops {
int btd_register_adapter_ops(struct btd_adapter_ops *btd_adapter_ops);
void btd_adapter_cleanup_ops(struct btd_adapter_ops *btd_adapter_ops);
int adapter_ops_setup(void);
+
+typedef void (*btd_adapter_powered_cb) (struct btd_adapter *adapter,
+ gboolean powered);
+void btd_adapter_register_powered_callback(struct btd_adapter *adapter,
+ btd_adapter_powered_cb cb);
+void btd_adapter_unregister_powered_callback(struct btd_adapter *adapter,
+ btd_adapter_powered_cb cb);
--
1.6.0.4
^ permalink raw reply related
* Re: resending patch to retry reset in case it failed
From: Ville Tervo @ 2010-08-13 13:20 UTC (permalink / raw)
To: Oliver Neukum; +Cc: Marcel Holtmann, linux-bluetooth, linux-usb
In-Reply-To: <201008121416.31808.oneukum@suse.de>
On Thu, Aug 12, 2010 at 8:16 AM, Oliver Neukum <oneukum@suse.de> wrote:
> Am Donnerstag, 12. August 2010, 13:25:23 schrieb Marcel Holtmann:
>> Hi Oliver,
>>
>> > may I ask what happened to this patch?
>> > Do you take it, want modifications or reject it?
>> >
>> > =A0 =A0 Regards
>> > =A0 =A0 =A0 =A0 =A0 =A0 Oliver
>> >
>> > From af61f0663f095599003290b13ad6fadee1d4fb25 Mon Sep 17 00:00:00 2001
>> > From: Oliver Neukum <oliver@neukum.org>
>> > Date: Tue, 6 Jul 2010 08:08:42 +0200
>> > Subject: [PATCH] bluetooth: retry reset for devices that fail
>> >
>> > Some devices fail to reset properly at the first attempt to reset
>> > them under unknown circumstances. Failures can be identified by
>> > an invalid btaddr. Retry in those cases.
>>
>> I was pondering about it and haven't really made up my mind with this
>> stuff. To be honest, I don't like the patch a little bit. I can see your
>> point why you want it, but the patch is a bit too ugly for my taste.
>
> I am very open to alternatives. But without that it is needed to make the
> hardware work.
>
>> Tell me which device is causing this and I might be able to reproduce
>> this and find small less ugly fix.
>
>
> I happens with this hardware from Broadcom. There may be others I don't
> know about. It is an internal dongle. I don't know whether it can be foun=
d in
> external hardware.
>
Could you share also "hciconfig hci0 revision" and "hciconfig hci0
version" info. And laptop model you have the chip build in.
--=20
Ville
^ permalink raw reply
* Re: [PATCH 1/3] Add mode callback to btd_adapter
From: Johan Hedberg @ 2010-08-13 12:41 UTC (permalink / raw)
To: Daniel Örstadius; +Cc: linux-bluetooth
In-Reply-To: <AANLkTi=Jh5fsqye6-Ry+VSNWftufDFCdyNEn6fcNrW84@mail.gmail.com>
Hi Daniel,
On Fri, Aug 13, 2010, Daniel Örstadius wrote:
> +typedef void (*btd_adapter_mode_cb) (struct btd_adapter *adapter,
> + gboolean powered);
> +void btd_adapter_register_mode_callback(struct btd_adapter *adapter,
> + btd_adapter_mode_cb cb);
In general this seems fine, but I think for completeness there should
also be a unregister function. Also, since we've traditionally used the
term mode to include also the discoverable state the name should
probably be something like btd_adapter_register_powered_callback and
btd_adapter_powered_cb.
Johan
^ permalink raw reply
* Re: bluetooth profile source code
From: Marcel Holtmann @ 2010-08-13 12:20 UTC (permalink / raw)
To: Viral Mehta; +Cc: linux-bluetooth@vger.kernel.org
In-Reply-To: <70376CA23424B34D86F1C7DE6B99734306D4C3CC13@VSHINMSMBX01.vshodc.lntinfotech.com>
Hi Viral,
> I am looking for some BT profile source code.
> I was able to find out for OBEX source code,
>
> But, I could not find any source cod for
> Headset Profile
> A2DP profile
> HandsFree Profile
>
> Surprisingly, is there no open source code for all these profiles ?
> Or I am just not able to google properly !!??
seems your Google Mojo is not high enough:
http://git.kernel.org/?p=bluetooth/bluez.git;a=summary
http://git.kernel.org/?p=bluetooth/obexd.git;a=summary
Regards
Marcel
^ permalink raw reply
* Re: [PATCH] Add support for FAX number in phonebook-tracker.c
From: Johan Hedberg @ 2010-08-13 12:19 UTC (permalink / raw)
To: Radoslaw Jablonski; +Cc: linux-bluetooth
In-Reply-To: <1281697117-23072-1-git-send-email-ext-jablonski.radoslaw@nokia.com>
Hi Radek,
On Fri, Aug 13, 2010, Radoslaw Jablonski wrote:
> Previously all fax numbers were treated as home phone numbers. Now
> fetching fax field as additional column in tracker query. Data from this
> column is filled as phone number with FAX type set. All pull queries are
> modified that way to suport fax number type.
> ---
> plugins/phonebook-tracker.c | 129 +++++++++++++++++++++++++++++++++---------
> 1 files changed, 101 insertions(+), 28 deletions(-)
Thanks. This patch is now also upstream.
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