* Re: [PATCH] return value checking of e_book_async_get_contacts() was wrong.
From: Johan Hedberg @ 2010-08-09 20:55 UTC (permalink / raw)
To: Marcel Mol; +Cc: linux-bluetooth
In-Reply-To: <201008092047.o79KlQDL015265@joshua.mesa.nl>
Hi Marcel,
On Mon, Aug 09, 2010, Marcel Mol wrote:
> phonebook_create_cache() failed because checking the return value
> e_book_async_get_contacts() was wrong. This would lead to a core dump
> as the data was freed but was still used in the callbacks.
> ---
> plugins/phonebook-ebook.c | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/plugins/phonebook-ebook.c b/plugins/phonebook-ebook.c
> index 3c24107..1598d5f 100644
> --- a/plugins/phonebook-ebook.c
> +++ b/plugins/phonebook-ebook.c
> @@ -459,7 +459,7 @@ int phonebook_create_cache(const char *name, phonebook_entry_cb entry_cb,
>
> ret = e_book_async_get_contacts(ebook, query, cache_cb, data);
> e_book_query_unref(query);
> - if (ret == FALSE) {
> + if (ret != FALSE) {
> g_free(data);
> return -EFAULT;
> }
Thanks for catching this. The patch is now upstream.
Johan
^ permalink raw reply
* [PATCH] return value checking of e_book_async_get_contacts() was wrong.
From: Marcel Mol @ 2010-08-09 20:43 UTC (permalink / raw)
To: linux-bluetooth
phonebook_create_cache() failed because checking the return value
e_book_async_get_contacts() was wrong. This would lead to a core dump
as the data was freed but was still used in the callbacks.
---
plugins/phonebook-ebook.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/plugins/phonebook-ebook.c b/plugins/phonebook-ebook.c
index 3c24107..1598d5f 100644
--- a/plugins/phonebook-ebook.c
+++ b/plugins/phonebook-ebook.c
@@ -459,7 +459,7 @@ int phonebook_create_cache(const char *name, phonebook_entry_cb entry_cb,
ret = e_book_async_get_contacts(ebook, query, cache_cb, data);
e_book_query_unref(query);
- if (ret == FALSE) {
+ if (ret != FALSE) {
g_free(data);
return -EFAULT;
}
--
1.7.2
^ permalink raw reply related
* Re: Question about BlueZ licenses (LGPL and Apache)
From: Pavan Savoy @ 2010-08-09 19:37 UTC (permalink / raw)
To: Luiz Augusto von Dentz; +Cc: Madhavi Manchala, linux-bluetooth
In-Reply-To: <AANLkTinUKu+GrAnJvZoZmhcb9=6ZOxhTBZhRv5i5NKBs@mail.gmail.com>
As long as we are updating, can the liba2dp be abstracted out of not
only the sbc encoding part but also the sending over UART part (as in
transport ...)
chips are getting smarter and the sbc codecs are moving to either a
co-processor/dsp or even inside the BT chip itself, so we might have
to send the PCM raw data somewhere else for the dsp to encode to sbc
and send it over the air ...
currently the data (sbc/pcm) and the control (connection
establishment) is too tightly sort of coded in together.. isn't it ?
for something like the above to happen our liba2dp had to be almost
re-written ...
On 8/9/10, Luiz Augusto von Dentz <luiz.dentz@gmail.com> wrote:
> Hi,
>
> On Fri, Aug 6, 2010 at 6:44 PM, Madhavi Manchala
> <madhavi.linux@gmail.com> wrote:
>> Dear All,
>>
>> I am trying to implement a custom voice codec on the android bluetooth
>> platform by linking it, into the A2DP module. I have heard different
>> versions from different people regarding the licenses (like LGPL and
>> Apache License). So, before starting my work, I would like to know if
>> I would be forced to reveal my source code, once I implement my codec
>> on BlueZ stack. Please let me know, so that I can choose my platform,
>> before starting my work.
>
> If you are just implementing a new codec then you might have to link
> to GPL code which basically makes your code GPL too, but we have plans
> to support this over dbus which wouldn't require you to link to any
> GPL, instead you register an endpoint which will be used to configure
> streams.
>
> This code can be found here:
>
> http://gitorious.org/~vudentz/bluez/vudentzs-clone/commits/endpoint
>
> This depend on dbus 1.3.1 and latter which will probably only reach
> upstream once we have a dbus 1.4 release.
>
> --
> Luiz Augusto von Dentz
> Computer Engineer
> --
> 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
* [PATCH] Bluetooth: Support SDIO devices that are AMP controllers
From: David Vrabel @ 2010-08-09 18:57 UTC (permalink / raw)
To: linux-bluetooth; +Cc: Marcel Holtmann
Signed-off-by: David Vrabel <david.vrabel@csr.com>
---
drivers/bluetooth/btsdio.c | 4 ++++
include/linux/mmc/sdio_ids.h | 1 +
2 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/drivers/bluetooth/btsdio.c b/drivers/bluetooth/btsdio.c
index 76e5127..061e0a4 100644
--- a/drivers/bluetooth/btsdio.c
+++ b/drivers/bluetooth/btsdio.c
@@ -46,6 +46,9 @@ static const struct sdio_device_id btsdio_table[] = {
/* Generic Bluetooth Type-B SDIO device */
{ SDIO_DEVICE_CLASS(SDIO_CLASS_BT_B) },
+ /* Generic Bluetooth AMP controller */
+ { SDIO_DEVICE_CLASS(SDIO_CLASS_BT_AMP) },
+
{ } /* Terminating entry */
};
@@ -327,6 +330,7 @@ static int btsdio_probe(struct sdio_func *func,
}
hdev->bus = HCI_SDIO;
+ hdev->dev_type = (id->class == SDIO_CLASS_BT_AMP) ? HCI_AMP : HCI_BREDR;
hdev->driver_data = data;
data->hdev = hdev;
diff --git a/include/linux/mmc/sdio_ids.h b/include/linux/mmc/sdio_ids.h
index 33b2ea0..a36ab3b 100644
--- a/include/linux/mmc/sdio_ids.h
+++ b/include/linux/mmc/sdio_ids.h
@@ -18,6 +18,7 @@
#define SDIO_CLASS_PHS 0x06 /* PHS standard interface */
#define SDIO_CLASS_WLAN 0x07 /* WLAN interface */
#define SDIO_CLASS_ATA 0x08 /* Embedded SDIO-ATA std interface */
+#define SDIO_CLASS_BT_AMP 0x09 /* Type-A Bluetooth AMP interface */
/*
* Vendors and devices. Sort key: vendor first, device next.
--
1.5.4.3
--
David Vrabel, Senior Software Engineer, Drivers
CSR, Churchill House, Cambridge Business Park, Tel: +44 (0)1223 692562
Cowley Road, Cambridge, CB4 0WZ http://www.csr.com/
Member of the CSR plc group of companies. CSR plc registered in England and Wales, registered number 4187346, registered office Churchill House, Cambridge Business Park, Cowley Road, Cambridge, CB4 0WZ, United Kingdom
^ permalink raw reply related
* [PATCH] Bluetooth: HCI devices are either BR/EDR or AMP radios
From: David Vrabel @ 2010-08-09 18:55 UTC (permalink / raw)
To: linux-bluetooth; +Cc: Marcel Holtmann
HCI transport drivers may not know what type of radio an AMP device has
so only say whether they're BR/EDR or AMP devices.
Signed-off-by: David Vrabel <david.vrabel@csr.com>
---
include/net/bluetooth/hci.h | 2 +-
net/bluetooth/hci_sysfs.c | 4 ++--
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/include/net/bluetooth/hci.h b/include/net/bluetooth/hci.h
index ca2518e..cc14731 100644
--- a/include/net/bluetooth/hci.h
+++ b/include/net/bluetooth/hci.h
@@ -54,7 +54,7 @@
/* HCI controller types */
#define HCI_BREDR 0x00
-#define HCI_80211 0x01
+#define HCI_AMP 0x01
/* HCI device quirks */
enum {
diff --git a/net/bluetooth/hci_sysfs.c b/net/bluetooth/hci_sysfs.c
index ce44c47..4e9ca9b 100644
--- a/net/bluetooth/hci_sysfs.c
+++ b/net/bluetooth/hci_sysfs.c
@@ -196,8 +196,8 @@ static inline char *host_typetostr(int type)
switch (type) {
case HCI_BREDR:
return "BR/EDR";
- case HCI_80211:
- return "802.11";
+ case HCI_AMP:
+ return "AMP";
default:
return "UNKNOWN";
}
--
1.5.4.3
--
David Vrabel, Senior Software Engineer, Drivers
CSR, Churchill House, Cambridge Business Park, Tel: +44 (0)1223 692562
Cowley Road, Cambridge, CB4 0WZ http://www.csr.com/
Member of the CSR plc group of companies. CSR plc registered in England and Wales, registered number 4187346, registered office Churchill House, Cambridge Business Park, Cowley Road, Cambridge, CB4 0WZ, United Kingdom
^ permalink raw reply related
* Re: [PATCH 1/9] Bluetooth: Only enable for L2CAP FCS for ERTM or streaming.
From: Mat Martineau @ 2010-08-09 16:50 UTC (permalink / raw)
To: Gustavo F. Padovan, Marcel Holtmann
Cc: linux-bluetooth, rshaffer, linux-arm-msm
In-Reply-To: <20100809131254.GB3817@vigoh>
On Mon, 9 Aug 2010, Gustavo F. Padovan wrote:
> Hi Marcel,
>
> * Marcel Holtmann <marcel@holtmann.org> [2010-08-08 22:43:00 -0400]:
>
>> Hi Mat,
>>
>>> This fixes a bug which caused the FCS setting to show L2CAP_FCS_CRC16
>>> with L2CAP modes other than ERTM or streaming. At present, this only
>>> affects the FCS value shown with getsockopt() for basic mode.
>>>
>>> Signed-off-by: Mat Martineau <mathewm@codeaurora.org>
>>> ---
>>> net/bluetooth/l2cap.c | 16 ++++++++++++----
>>> 1 files changed, 12 insertions(+), 4 deletions(-)
>>>
>>> diff --git a/net/bluetooth/l2cap.c b/net/bluetooth/l2cap.c
>>> index 3e3cd9d..bc10be8 100644
>>> --- a/net/bluetooth/l2cap.c
>>> +++ b/net/bluetooth/l2cap.c
>>> @@ -3072,6 +3072,16 @@ static inline int l2cap_connect_rsp(struct l2cap_conn *conn, struct l2cap_cmd_hd
>>> return 0;
>>> }
>>>
>>> +static inline int l2cap_fcs_needed(struct l2cap_pinfo *pi)
>>> +{
>>> + if (pi->mode != L2CAP_MODE_ERTM && pi->mode != L2CAP_MODE_STREAMING)
>>> + return 0;
>>> +
>>> + /* FCS is enabled if one or both sides request it. */
>>> + return !(pi->conf_state & L2CAP_CONF_NO_FCS_RECV) ||
>>> + pi->fcs == L2CAP_FCS_CRC16;
>>> +}
>>
>> so I think a switch statement is easier to read:
>>
>> switch (pi->mode) {
>> case L2CAP_MODE_ERTM:
>> case L2CAP_MODE_STREAMING:
>> return !(pi->conf_state & L2CAP_CONF_NO_FCS_RECV) ||
>> pi->fcs == L2CAP_FCS_CRC16;
>> }
>>
>> return 0;
>>
>>> static inline int l2cap_config_req(struct l2cap_conn *conn, struct l2cap_cmd_hdr *cmd, u16 cmd_len, u8 *data)
>>> {
>>> struct l2cap_conf_req *req = (struct l2cap_conf_req *) data;
>>> @@ -3136,8 +3146,7 @@ static inline int l2cap_config_req(struct l2cap_conn *conn, struct l2cap_cmd_hdr
>>> goto unlock;
>>>
>>> if (l2cap_pi(sk)->conf_state & L2CAP_CONF_INPUT_DONE) {
>>> - if (!(l2cap_pi(sk)->conf_state & L2CAP_CONF_NO_FCS_RECV) ||
>>> - l2cap_pi(sk)->fcs != L2CAP_FCS_NONE)
>>> + if (l2cap_fcs_needed(l2cap_pi(sk)))
>>> l2cap_pi(sk)->fcs = L2CAP_FCS_CRC16;
>>
>> While this is just fine, I think we might should make this a lot
>> simpler:
>>
>> if (l2cap_pi(sk)->conf_state & L2CAP_CONF_INPUT_DONE) {
>> set_default_fcs(pi);
>>
>> ...
>> }
>>
>> With then set_default_fcs() doing all the checks etc. and setting either
>> FCS_NONE or FCS_CRC16.
>>
>> Would this work or do we have to deal with some funny default behavior?
>
> That will work. ;)
Agreed - that's much more readable.
--
Mat Martineau
Employee of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum
^ permalink raw reply
* Re: [PATCH 2/2] Fix multiple phone number problem in pull vcard
From: Johan Hedberg @ 2010-08-09 14:01 UTC (permalink / raw)
To: Radoslaw Jablonski; +Cc: linux-bluetooth
In-Reply-To: <1281352651-30943-1-git-send-email-ext-jablonski.radoslaw@nokia.com>
Hi Radek,
On Mon, Aug 09, 2010, Radoslaw Jablonski wrote:
> This fixes problem with pull vcard when contact has more than one home or
> work number defined in tracker - more than one VCARD was generated in
> response for pull vcard request. This was caused by nature of the data
> retrieved from tracker - contact with multiple numbers set was returned as
> many entries with identical id. Previously VCARDs was generated on the fly
> - now added contact-data caching and checking for contact id. VCARD is now
> generated when all responses of tracker were processed - and only one vcard
> is returned for one contact entry.
> ---
> plugins/phonebook-tracker.c | 134 ++++++++++++++++++++++++++++++++++++-------
> 1 files changed, 112 insertions(+), 22 deletions(-)
Some coding style issue that need fixing:
> +struct contact_data
> +{
The { shouldn't go on it's own line, i.e. put it in the above line.
> +static struct phonebook_contact *find_contact (GSList *contacts,char *id)
> +{
Remove the space after "find_contact", add a space after ",". Since
you're not modifying id in the function it should probably be const char *
instead of char *.
> + GSList *it;
Usually simple list iterators are called just "l".
> + for(it = contacts; it; it = it->next) {
Space between for and (
> + for(it = numbers; it; it = it->next) {
Same here, and call the list variable "l".
> +static GString * gen_vcards(GSList *contacts,
> + const struct apparam_field *params)
No space between * and gen_vcards.
> + GSList *it;
Again, call it "l".
> + for(it = contacts; it; it = it->next) {
Space between for and (
> + if (!cdata_present) {
> + contact_data = g_new0(struct contact_data, 1);
> + contact_data->contact = contact;
> + contact_data->id = g_strdup(reply[CONTACTS_ID_COL]);
> + data->contacts = g_slist_append(data->contacts, contact_data);
> + }
> return;
Add an empty line before the return
> data = g_new0(struct phonebook_data, 1);
> - data->vcards = g_string_new(NULL);
> data->params = params;
> data->user_data = user_data;
> data->cb = cb;
> + data->contacts = NULL;
Since you used g_new0 setting to NULL seems redundant.
Johan
^ permalink raw reply
* Re: [PATCH 1/2] Fix multiple phone numbers problem in vcard-listing
From: Johan Hedberg @ 2010-08-09 13:55 UTC (permalink / raw)
To: Radoslaw Jablonski; +Cc: linux-bluetooth
In-Reply-To: <1281352623-30856-1-git-send-email-ext-jablonski.radoslaw@nokia.com>
Hi Radek,
On Mon, Aug 09, 2010, Radoslaw Jablonski wrote:
> This fixes displaying problem in vcard-listing when contact had multiple
> home or work phone set(one contact was displayed more than one time in
> vcard-listing. Now query is changed and additional entries are omitted.
> ---
> plugins/phonebook-tracker.c | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/plugins/phonebook-tracker.c b/plugins/phonebook-tracker.c
> index 41d7fde..f2b9649 100644
> --- a/plugins/phonebook-tracker.c
> +++ b/plugins/phonebook-tracker.c
> @@ -76,7 +76,7 @@
> "?c nco:hasAffiliation ?a . " \
> "?a nco:hasPhoneNumber ?h . " \
> "} " \
> - "}"
> + "} GROUP BY ?c"
>
> #define MISSED_CALLS_QUERY \
> "SELECT nco:phoneNumber(?h) nco:fullname(?c) " \
This patch is now upstream. Thanks.
Johan
^ permalink raw reply
* Re: Workaround for buggy BT dongles
From: Marcel Holtmann @ 2010-08-09 13:36 UTC (permalink / raw)
To: Andrei Emeltchenko; +Cc: Bluettooth Linux
In-Reply-To: <AANLkTimt4CN6Oegrnf3Z5mhb0L7QLiiaPdHCSdp=rLTw@mail.gmail.com>
Hi Andrei,
> We have experienced L2CAP disconnections with A-Link BT dongles (lsusb
> shows Broadcom Corp. BCM2046B1 chip).
>
> There is race condition in a controller so that sometimes "L2CAP
> Connect Req" is received after "HCI Encryption Change":
> ...
> 2308 *REF* HCI_EVT
> Simple Pairing Complete
> 2309 0.089720 HCI_EVT
> Link Key Notification
> 2310 0.126607 L2CAP
> Rcvd Connection Request
> 2311 0.126721 L2CAP
> Sent Connection Response
> 2312 0.127278 HCI_EVT
> Encrypt Change
> ...
>
> This is correct behavior since all non-SDP connections shall be
> encrypted for SSP devices.
>
> If we send "L2CAP Connect Request" with a little delay the problem
> disappears (this is of course too hackish way).
>
> Shall we address this problem? I do not see good way of dealing with the chip.
I would prefer to address this problem as follows. Open your window and
through the dongle out that same window ;)
Regards
Marcel
^ permalink raw reply
* Workaround for buggy BT dongles
From: Andrei Emeltchenko @ 2010-08-09 13:21 UTC (permalink / raw)
To: Bluettooth Linux
Hi,
We have experienced L2CAP disconnections with A-Link BT dongles (lsusb
shows Broadcom Corp. BCM2046B1 chip).
There is race condition in a controller so that sometimes "L2CAP
Connect Req" is received after "HCI Encryption Change":
...
2308 *REF* HCI_EVT
Simple Pairing Complete
2309 0.089720 HCI_EVT
Link Key Notification
2310 0.126607 L2CAP
Rcvd Connection Request
2311 0.126721 L2CAP
Sent Connection Response
2312 0.127278 HCI_EVT
Encrypt Change
...
This is correct behavior since all non-SDP connections shall be
encrypted for SSP devices.
If we send "L2CAP Connect Request" with a little delay the problem
disappears (this is of course too hackish way).
Shall we address this problem? I do not see good way of dealing with the chip.
Regards,
Andrei
^ permalink raw reply
* Re: [PATCH 1/9] Bluetooth: Only enable for L2CAP FCS for ERTM or streaming.
From: Gustavo F. Padovan @ 2010-08-09 13:12 UTC (permalink / raw)
To: Marcel Holtmann; +Cc: Mat Martineau, linux-bluetooth, rshaffer, linux-arm-msm
In-Reply-To: <1281321780.12579.184.camel@localhost.localdomain>
Hi Marcel,
* Marcel Holtmann <marcel@holtmann.org> [2010-08-08 22:43:00 -0400]:
> Hi Mat,
>
> > This fixes a bug which caused the FCS setting to show L2CAP_FCS_CRC16
> > with L2CAP modes other than ERTM or streaming. At present, this only
> > affects the FCS value shown with getsockopt() for basic mode.
> >
> > Signed-off-by: Mat Martineau <mathewm@codeaurora.org>
> > ---
> > net/bluetooth/l2cap.c | 16 ++++++++++++----
> > 1 files changed, 12 insertions(+), 4 deletions(-)
> >
> > diff --git a/net/bluetooth/l2cap.c b/net/bluetooth/l2cap.c
> > index 3e3cd9d..bc10be8 100644
> > --- a/net/bluetooth/l2cap.c
> > +++ b/net/bluetooth/l2cap.c
> > @@ -3072,6 +3072,16 @@ static inline int l2cap_connect_rsp(struct l2cap_conn *conn, struct l2cap_cmd_hd
> > return 0;
> > }
> >
> > +static inline int l2cap_fcs_needed(struct l2cap_pinfo *pi)
> > +{
> > + if (pi->mode != L2CAP_MODE_ERTM && pi->mode != L2CAP_MODE_STREAMING)
> > + return 0;
> > +
> > + /* FCS is enabled if one or both sides request it. */
> > + return !(pi->conf_state & L2CAP_CONF_NO_FCS_RECV) ||
> > + pi->fcs == L2CAP_FCS_CRC16;
> > +}
>
> so I think a switch statement is easier to read:
>
> switch (pi->mode) {
> case L2CAP_MODE_ERTM:
> case L2CAP_MODE_STREAMING:
> return !(pi->conf_state & L2CAP_CONF_NO_FCS_RECV) ||
> pi->fcs == L2CAP_FCS_CRC16;
> }
>
> return 0;
>
> > static inline int l2cap_config_req(struct l2cap_conn *conn, struct l2cap_cmd_hdr *cmd, u16 cmd_len, u8 *data)
> > {
> > struct l2cap_conf_req *req = (struct l2cap_conf_req *) data;
> > @@ -3136,8 +3146,7 @@ static inline int l2cap_config_req(struct l2cap_conn *conn, struct l2cap_cmd_hdr
> > goto unlock;
> >
> > if (l2cap_pi(sk)->conf_state & L2CAP_CONF_INPUT_DONE) {
> > - if (!(l2cap_pi(sk)->conf_state & L2CAP_CONF_NO_FCS_RECV) ||
> > - l2cap_pi(sk)->fcs != L2CAP_FCS_NONE)
> > + if (l2cap_fcs_needed(l2cap_pi(sk)))
> > l2cap_pi(sk)->fcs = L2CAP_FCS_CRC16;
>
> While this is just fine, I think we might should make this a lot
> simpler:
>
> if (l2cap_pi(sk)->conf_state & L2CAP_CONF_INPUT_DONE) {
> set_default_fcs(pi);
>
> ...
> }
>
> With then set_default_fcs() doing all the checks etc. and setting either
> FCS_NONE or FCS_CRC16.
>
> Would this work or do we have to deal with some funny default behavior?
That will work. ;)
--
Gustavo F. Padovan
http://padovan.org
^ permalink raw reply
* [PATCH 2/2] Fix multiple phone number problem in pull vcard
From: Radoslaw Jablonski @ 2010-08-09 11:17 UTC (permalink / raw)
To: linux-bluetooth; +Cc: Radoslaw Jablonski
This fixes problem with pull vcard when contact has more than one home or
work number defined in tracker - more than one VCARD was generated in
response for pull vcard request. This was caused by nature of the data
retrieved from tracker - contact with multiple numbers set was returned as
many entries with identical id. Previously VCARDs was generated on the fly
- now added contact-data caching and checking for contact id. VCARD is now
generated when all responses of tracker were processed - and only one vcard
is returned for one contact entry.
---
plugins/phonebook-tracker.c | 134 ++++++++++++++++++++++++++++++++++++-------
1 files changed, 112 insertions(+), 22 deletions(-)
diff --git a/plugins/phonebook-tracker.c b/plugins/phonebook-tracker.c
index f2b9649..1e197d7 100644
--- a/plugins/phonebook-tracker.c
+++ b/plugins/phonebook-tracker.c
@@ -43,6 +43,9 @@
#define TRACKER_RESOURCES_INTERFACE "org.freedesktop.Tracker1.Resources"
#define TRACKER_DEFAULT_CONTACT_ME "http://www.semanticdesktop.org/ontologies/2007/03/22/nco#default-contact-me"
+#define CONTACTS_ID_COL 19
+#define PHONE_ID_HOME 0
+#define PHONE_ID_WORK 3
#define CONTACTS_QUERY_ALL \
"SELECT nco:phoneNumber(?h) nco:fullname(?c) " \
@@ -275,13 +278,19 @@ struct pending_reply {
int num_fields;
};
+struct contact_data
+{
+ char *id;
+ struct phonebook_contact *contact;
+};
+
struct phonebook_data {
- GString *vcards;
phonebook_cb cb;
void *user_data;
int index;
gboolean vcardentry;
const struct apparam_field *params;
+ GSList *contacts;
};
struct cache_data {
@@ -545,20 +554,103 @@ static void set_call_type(struct phonebook_contact *contact,
contact->datetime = iso8601_utc_to_localtime(datetime);
}
+static struct phonebook_contact *find_contact (GSList *contacts,char *id)
+{
+ GSList *it;
+ struct contact_data *c_data;
+
+ for(it = contacts; it; it = it->next) {
+ c_data = it->data;
+ if (g_strcmp0(c_data->id, id) == 0)
+ return c_data->contact;
+ }
+
+ return NULL;
+}
+
+static struct phonebook_number *find_phone(GSList *numbers, char *phone,
+ int type)
+{
+ GSList *it;
+ struct phonebook_number *pb_num;
+
+ for(it = numbers; it; it = it->next) {
+ pb_num = it->data;
+ /* Returning phonebook number if phone values and type values
+ * are equal */
+ if (g_strcmp0(pb_num->tel, phone) == 0 && pb_num->type == type)
+ return pb_num;
+ }
+
+ return NULL;
+}
+
+static void add_phone_number(struct phonebook_contact *contact, char *phone,
+ int type)
+{
+ struct phonebook_number *number;
+
+ if (phone == NULL || strlen(phone) == 0)
+ return;
+
+ /* Not adding number if there is already added with the same value */
+ if (find_phone(contact->numbers, phone, type))
+ return;
+
+ number = g_new0(struct phonebook_number, 1);
+ number->tel = g_strdup(phone);
+ number->type = type;
+
+ contact->numbers = g_slist_append(contact->numbers, number);
+}
+
+static GString * gen_vcards(GSList *contacts,
+ const struct apparam_field *params)
+{
+ GSList *it;
+ GString *vcards;
+ struct contact_data *c_data;
+
+ vcards = g_string_new(NULL);
+
+ /* Generating VCARD string from contacts and freeing used contacts */
+ for(it = contacts; it; it = it->next) {
+ c_data = it->data;
+ phonebook_add_contact(vcards, c_data->contact,
+ params->filter, params->format);
+
+ g_free(c_data->id);
+ phonebook_contact_free(c_data->contact);
+ }
+
+ return vcards;
+}
+
static void pull_contacts(char **reply, int num_fields, void *user_data)
{
struct phonebook_data *data = user_data;
const struct apparam_field *params = data->params;
struct phonebook_contact *contact;
- struct phonebook_number *number;
- GString *vcards = data->vcards;
+ struct contact_data *contact_data;
+ GString *vcards;
int last_index, i;
+ gboolean cdata_present = FALSE;
DBG("reply %p", reply);
if (reply == NULL)
goto done;
+ /* Trying to find contact in recently added contacts. It is needed for
+ * contacts that have more than one telephone number filled */
+ contact = find_contact(data->contacts, reply[CONTACTS_ID_COL]);
+
+ /* If contact is already created then adding only new phone numbers */
+ if (contact) {
+ cdata_present = TRUE;
+ goto add_numbers;
+ }
+
/* We are doing a PullvCardEntry, no need for those checks */
if (data->vcardentry)
goto add_entry;
@@ -603,33 +695,31 @@ add_entry:
set_call_type(contact, reply[16], reply[17], reply[18]);
- number = g_new0(struct phonebook_number, 1);
- number->tel = g_strdup(reply[0]);
- number->type = 0; /* HOME */
-
- contact->numbers = g_slist_append(contact->numbers, number);
-
- /* Has WORK Phonenumber */
- if (strlen(reply[8])) {
- number = g_new0(struct phonebook_number, 1);
- number->tel = g_strdup(reply[8]);
- number->type = 3; /* WORK */
-
- contact->numbers = g_slist_append(contact->numbers, number);
- }
+add_numbers:
+ /* Adding phone numbers to contact struct */
+ add_phone_number(contact, reply[0], PHONE_ID_HOME);
+ add_phone_number(contact, reply[8], PHONE_ID_WORK);
DBG("contact %p", contact);
- phonebook_add_contact(vcards, contact, params->filter, params->format);
- phonebook_contact_free(contact);
-
+ /* Adding contacts data to wrapper struct - this data will be used to
+ * generate vcard list */
+ if (!cdata_present) {
+ contact_data = g_new0(struct contact_data, 1);
+ contact_data->contact = contact;
+ contact_data->id = g_strdup(reply[CONTACTS_ID_COL]);
+ data->contacts = g_slist_append(data->contacts, contact_data);
+ }
return;
done:
+ vcards = gen_vcards(data->contacts, params);
+
if (num_fields == 0)
data->cb(vcards->str, vcards->len, data->index, 0,
data->user_data);
+ g_slist_free(data->contacts);
g_string_free(vcards, TRUE);
g_free(data);
}
@@ -775,10 +865,10 @@ int phonebook_pull(const char *name, const struct apparam_field *params,
return -ENOENT;
data = g_new0(struct phonebook_data, 1);
- data->vcards = g_string_new(NULL);
data->params = params;
data->user_data = user_data;
data->cb = cb;
+ data->contacts = NULL;
return query_tracker(query, 20, pull_contacts, data);
}
@@ -794,11 +884,11 @@ int phonebook_get_entry(const char *folder, const char *id,
DBG("folder %s id %s", folder, id);
data = g_new0(struct phonebook_data, 1);
- data->vcards = g_string_new(NULL);
data->user_data = user_data;
data->params = params;
data->cb = cb;
data->vcardentry = TRUE;
+ data->contacts = NULL;
query = g_strdup_printf(CONTACTS_QUERY_FROM_URI, id, id, id, id, id,
id, id, id, id, id, id, id);
--
1.7.0.4
^ permalink raw reply related
* [PATCH 1/2] Fix multiple phone numbers problem in vcard-listing
From: Radoslaw Jablonski @ 2010-08-09 11:17 UTC (permalink / raw)
To: linux-bluetooth; +Cc: Radoslaw Jablonski
This fixes displaying problem in vcard-listing when contact had multiple
home or work phone set(one contact was displayed more than one time in
vcard-listing. Now query is changed and additional entries are omitted.
---
plugins/phonebook-tracker.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/plugins/phonebook-tracker.c b/plugins/phonebook-tracker.c
index 41d7fde..f2b9649 100644
--- a/plugins/phonebook-tracker.c
+++ b/plugins/phonebook-tracker.c
@@ -76,7 +76,7 @@
"?c nco:hasAffiliation ?a . " \
"?a nco:hasPhoneNumber ?h . " \
"} " \
- "}"
+ "} GROUP BY ?c"
#define MISSED_CALLS_QUERY \
"SELECT nco:phoneNumber(?h) nco:fullname(?c) " \
--
1.7.0.4
^ permalink raw reply related
* Re: Question about BlueZ licenses (LGPL and Apache)
From: Siarhei Siamashka @ 2010-08-09 11:02 UTC (permalink / raw)
To: Madhavi Manchala; +Cc: Alan Carvalho de Assis, linux-bluetooth, Marcel Holtmann
In-Reply-To: <AANLkTi=fSfwijpK-OR-6yTr30USFQbcgknrd1FaU99oH@mail.gmail.com>
On Monday 09 August 2010 07:38:17 Madhavi Manchala wrote:
> By the way, please let me clarify one thing. I think, the input for
> the SBC module is the RAW stream. Am I correct?
As I understand it, you are not happy about something in bluez so that you are
considering to hook in your own SBC implementation. Could you please share your
concerns? Do you have problems with sound quality? Performance in general?
Performance on some particular hardware? Anything else? Are you interested in
SBC encoder or decoder?
Starting a new topic about these technical things may be a good idea.
--
Best regards,
Siarhei Siamashka
^ permalink raw reply
* Re: [PATCH] Changes in HDP API.
From: Santiago Carot-Nemesio @ 2010-08-09 10:33 UTC (permalink / raw)
Cc: linux-bluetooth
In-Reply-To: <1281016183-4547-1-git-send-email-santoscadenas@gmail.com>
On 08/05/10 15:49, Jose Antonio Santos Cadenas wrote:
> Now the connection is made directly to a device and bluetoothd daemon
> guess the PSM connection and the MDEPID based on the data get from the
> SDP record.
> ---
> doc/health-api.txt | 105 ++++++++++++++++++++--------------------------------
> 1 files changed, 40 insertions(+), 65 deletions(-)
>
> diff --git a/doc/health-api.txt b/doc/health-api.txt
> index f469df3..89df8bd 100644
> --- a/doc/health-api.txt
> +++ b/doc/health-api.txt
> @@ -14,12 +14,9 @@ Object path /org/bluez/
>
> Methods:
>
> - object CreateApplication(dict config, object agent)
> + object CreateApplication(dict config)
>
> - Returns the path of the new registered application. The agent
> - parameter is the path of the object with the callbacks to
> - notify events (see org.bluez.HealthAgent at the end
> - of this document).
> + Returns the path of the new registered application.
>
> Dict is defined as bellow:
> {
> @@ -39,32 +36,33 @@ Methods:
>
> Closes the HDP application identified by the object path. Also
> application will be closed if the process that started it leaves
> - the bus.
> + the bus. Only the creator of the application will be able to
> + destroy it.
>
> Possible errors: org.bluez.Error.InvalidArguments
> org.bluez.Error.NotFound
> + org.bluez.Error.NotAllowed
>
> --------------------------------------------------------------------------------
>
> Service org.bluez
> -Interface org.bluez.HealthApplication
> -Object path [variable prefix]/health_app_ZZZZ
> +Interface org.bluez.HealthDevice
> +Object path [variable prefix]/{hci0,hci1,...}/dev_XX_XX_XX_XX_XX_XX
>
> Methods:
>
> - void Echo(object service)
> + Boolean Echo()
>
> Sends an echo petition to the remote service. Returns True if
> response matches with the buffer sent. If some error is detected
> - False value is returned and the associated MCL is closed.
> + False value is returned.
>
> Possible errors: org.bluez.Error.InvalidArguments
> org.bluez.Error.OutOfRange
>
> - object CreateChannel(object service, string type)
> + object CreateChannel(object application, string configuration)
>
> - Creates a new data channel with the indicated config to the
> - remote Service.
> + Creates a new data channel.
> The configuration should indicate the channel quality of
> service using one of this values "Reliable", "Streaming", "Any".
>
> @@ -76,16 +74,27 @@ Methods:
>
> void DestroyChannel(object channel)
>
> - Destroys the data channel object.
> + Destroys the data channel object. Only the creator of the
> + channel or the creator of the HealtApplication that received the
> + data channel will be able to destroy it
>
> Possible errors: org.bluez.Error.InvalidArguments
> - orb.bluez.Error.NotFound
> + org.bluez.Error.NotFound
> + org.bluez.Error.NotAllowed
>
> ---------------------------------------------------------------------------------
> +Signals:
>
> -Service org.bluez
> -Interface org.bluez.HealthService
> -Object path [variable prefix]/{hci0,hci1,...}/dev_XX_XX_XX_XX_XX_XX/hdp_YYYY
> + void ChannelConnected(object channel)
> +
> + This signal is launched when a new data channel is created or
> + when a known data channel is reconnected.
> +
> + void ChannelDeleted(object channel)
> +
> + This signal is launched when a data channel is deleted.
> +
> + After this signal the data channel path will not be valid and
> + its path can be reused for future data channels.
>
> --------------------------------------------------------------------------------
>
> @@ -94,6 +103,9 @@ Interface org.bluez.HealthChannel
> Object path [variable prefix]/{hci0,hci1,...}/dev_XX_XX_XX_XX_XX_XX/
> hdp_YYYY/channel_ZZ
>
> +Only the process that created the data channel or the creator of the
> +HealthApplication that received it will be able to call this methods.
> +
> Methods:
>
> dict GetProperties()
> @@ -101,17 +113,23 @@ Methods:
> Returns all properties for the interface. See the properties
> section for available properties.
>
> + Posible errors: org.bluez.Error.NotAllowed
> +
> fd Acquire()
>
> Returns the file descriptor for this data channel. If the data
> channel is not connected it will also reconnect.
>
> Possible errors: org.bluez.Error.NotConnected
> + org.bluez.Error.NotAllowed
>
> void Release()
>
> Releases the fd. Application should also need to close() it.
>
> + Possible errors: org.bluez.Error.NotAcquired
> + org.bluez.Error.NotAllowed
> +
> Properties:
>
> string Type (read only)
> @@ -119,50 +137,7 @@ Properties:
> The quality of service of the data channel. ("Reliable" or
> "Streaming")
In HDP specification there is a special mention for first data channel
opened that it shall be used for sending specific protocol data. Using
this API it is impossible diferentiate it from another reliable data
channels when it changes after a MCL reconnection. For applications
using HDP is mandatory sending this kind of traffic through the first
reliable data channel.
I suggest use an special Type for it in addition to "Reliable" and
"Streaming" such as "Main".
Due that main data channel can change after a MCL reconnection, we need
notify it to applications. We can expose a new signal similar to hfp-api
to announce property changes, for example something like this:
+Signals PropertyChanged(string new_value)
+
+ This signal indicates a property changed value.
Comments are welcome.
Regards.
^ permalink raw reply
* Re: Question about BlueZ licenses (LGPL and Apache)
From: Luiz Augusto von Dentz @ 2010-08-09 9:31 UTC (permalink / raw)
To: Madhavi Manchala; +Cc: linux-bluetooth
In-Reply-To: <AANLkTimiBsL60-8w4MPoP=g8Fo_+U-SrSBTa9--aqEK4@mail.gmail.com>
Hi,
On Fri, Aug 6, 2010 at 6:44 PM, Madhavi Manchala
<madhavi.linux@gmail.com> wrote:
> Dear All,
>
> I am trying to implement a custom voice codec on the android bluetooth
> platform by linking it, into the A2DP module. I have heard different
> versions from different people regarding the licenses (like LGPL and
> Apache License). So, before starting my work, I would like to know if
> I would be forced to reveal my source code, once I implement my codec
> on BlueZ stack. Please let me know, so that I can choose my platform,
> before starting my work.
If you are just implementing a new codec then you might have to link
to GPL code which basically makes your code GPL too, but we have plans
to support this over dbus which wouldn't require you to link to any
GPL, instead you register an endpoint which will be used to configure
streams.
This code can be found here:
http://gitorious.org/~vudentz/bluez/vudentzs-clone/commits/endpoint
This depend on dbus 1.3.1 and latter which will probably only reach
upstream once we have a dbus 1.4 release.
--
Luiz Augusto von Dentz
Computer Engineer
^ permalink raw reply
* Re: Question about BlueZ licenses (LGPL and Apache)
From: Madhavi Manchala @ 2010-08-09 9:28 UTC (permalink / raw)
To: Siarhei Siamashka
Cc: Alan Carvalho de Assis, linux-bluetooth, Marcel Holtmann
In-Reply-To: <201008091102.28980.siarhei.siamashka@gmail.com>
On Mon, Aug 9, 2010 at 4:32 PM, Siarhei Siamashka
<siarhei.siamashka@gmail.com> wrote:
> On Monday 09 August 2010 07:38:17 Madhavi Manchala wrote:
>> By the way, please let me clarify one thing. I think, the input for
>> the SBC module is the RAW stream. Am I correct?
>
> As I understand it, you are not happy about something in bluez so that you are
> considering to hook in your own SBC implementation. Could you please share your
> concerns? Do you have problems with sound quality? Performance in general?
> Performance on some particular hardware? Anything else? Are you interested in
> SBC encoder or decoder?
Actually, I am not trying to hook a new SBC implementation. I am
trying to work on a new custom codec, and in case the SINK devices do
not support my custom codec, I want the src to reroute the stream
through the SBC encoder, so that all the SINK devices will work
without any problem. Since SBC is mandatory in the A2DP
implementation, I thought about using SBC as the alternate codec.
Please let me know if I am missing something.
Thanks and Regards,
Madhavi M.
^ permalink raw reply
* Re: [PATCH 9/9] Bluetooth: Use 3-DH5 payload size for default ERTM max PDU size.
From: Marcel Holtmann @ 2010-08-09 8:44 UTC (permalink / raw)
To: Mat Martineau; +Cc: linux-bluetooth, gustavo, rshaffer, linux-arm-msm
In-Reply-To: <1281048867-32630-10-git-send-email-mathewm@codeaurora.org>
Hi Mat,
> The previous value of 672 for L2CAP_DEFAULT_MAX_PDU_SIZE is based on
> the default L2CAP MTU. That default MTU is calculated from the size
> of two DH5 packets, minus ACL and L2CAP b-frame header overhead.
>
> ERTM is used with newer basebands that typically support larger 3-DH5
> packets, and i-frames and s-frames have more header overhead. With
> clean RF conditions, basebands will typically attempt to use 1021-byte
> 3-DH5 packets for maximum throughput. Adjusting for 2 bytes of ACL
> headers plus 10 bytes of worst-case L2CAP headers yields 1009 bytes
> of payload.
>
> This PDU size imposes less overhead for header bytes and gives the
> baseband the option to choose 3-DH5 packets, but is small enough for
> ERTM traffic to interleave well with other L2CAP or SCO data.
> 672-byte payloads do not allow the most efficient over-the-air
> packet choice, and cannot achieve maximum throughput over BR/EDR.
>
> Signed-off-by: Mat Martineau <mathewm@codeaurora.org>
> ---
> include/net/bluetooth/l2cap.h | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
patch has been applied. Thanks.
Regards
Marcel
^ permalink raw reply
* Re: [PATCH 5/9] Bluetooth: Fix incorrect setting of remote_tx_win for L2CAP ERTM.
From: Marcel Holtmann @ 2010-08-09 8:41 UTC (permalink / raw)
To: Mat Martineau; +Cc: linux-bluetooth, gustavo, rshaffer, linux-arm-msm
In-Reply-To: <1281048867-32630-6-git-send-email-mathewm@codeaurora.org>
Hi Mat,
> remote_tx_win is intended to be set on receipt of an L2CAP
> configuration request. The value is used to determine the size of the
> transmit window on the remote side of an ERTM connection, so L2CAP
> can stop sending frames when that remote window is full.
>
> An incorrect remote_tx_win value will cause the stack to not fully
> utilize the tx window (performance impact), or to overfill the remote
> tx window (causing dropped frames or a disconnect).
>
> This patch removes an extra setting of remote_tx_win when a
> configuration response is received. The transmit window has a
> different meaning in a response - it is an informational value
> less than or equal to the local tx_win.
>
> Signed-off-by: Mat Martineau <mathewm@codeaurora.org>
> ---
> net/bluetooth/l2cap.c | 2 --
> 1 files changed, 0 insertions(+), 2 deletions(-)
patch has been applied. Thanks.
Regards
Marcel
^ permalink raw reply
* Re: [PATCH 2/9] Bluetooth: Change default ERTM retransmit timeout.
From: Marcel Holtmann @ 2010-08-09 8:37 UTC (permalink / raw)
To: Mat Martineau; +Cc: linux-bluetooth, gustavo, rshaffer, linux-arm-msm
In-Reply-To: <1281048867-32630-3-git-send-email-mathewm@codeaurora.org>
Hi Mat,
> The L2CAP spec requires that the ERTM retransmit timeout be at least 2
> seconds for BR/EDR connections.
>
> Signed-off-by: Mat Martineau <mathewm@codeaurora.org>
> ---
> include/net/bluetooth/l2cap.h | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
patch has been applied. Thanks.
Regards
Marcel
^ permalink raw reply
* Re: [PATCH 4/9] Bluetooth: Fix endianness issue with L2CAP MPS configuration.
From: Marcel Holtmann @ 2010-08-09 8:36 UTC (permalink / raw)
To: Mat Martineau; +Cc: linux-bluetooth, gustavo, rshaffer, linux-arm-msm
In-Reply-To: <1281048867-32630-5-git-send-email-mathewm@codeaurora.org>
Hi Mat,
> Incoming configuration values must be converted to native CPU order
> before use. This fixes a bug where a little-endian MPS value is
> compared to a native CPU value. On big-endian processors, this
> can cause ERTM and streaming mode segmentation to produce PDUs
> that are larger than the remote stack is expecting, or that would
> produce fragmented skbs that the current FCS code cannot handle.
>
> Signed-off-by: Mat Martineau <mathewm@codeaurora.org>
> ---
> net/bluetooth/l2cap.c | 9 +++++----
> 1 files changed, 5 insertions(+), 4 deletions(-)
patch has been applied. Thanks.
Regards
Marcel
^ permalink raw reply
* Re: Question about BlueZ licenses (LGPL and Apache)
From: Madhavi Manchala @ 2010-08-09 7:38 UTC (permalink / raw)
To: Alan Carvalho de Assis; +Cc: linux-bluetooth, Marcel Holtmann
In-Reply-To: <AANLkTimLW5SUmx4OvzY4M51HjV3mf3=pbBtAgHoeiReZ@mail.gmail.com>
On Sat, Aug 7, 2010 at 6:58 PM, Alan Carvalho de Assis
<acassis@gmail.com> wrote:
> Hi Madhavi,
>
> On 8/7/10, Marcel Holtmann <marcel@holtmann.org> wrote:
>> Hi Madhavi,
>>
>>> I am trying to implement a custom voice codec on the android bluetooth
>>> platform by linking it, into the A2DP module. I have heard different
>>> versions from different people regarding the licenses (like LGPL and
>>> Apache License). So, before starting my work, I would like to know if
>>> I would be forced to reveal my source code, once I implement my codec
>>> on BlueZ stack. Please let me know, so that I can choose my platform,
>>> before starting my work.
>
> As you asked this same question in Android mailing list I suggest you
> to forward Marcel reply to here as well. This way many other people in
> that list will be aware of it.
>
> Best Regards,
>
> Alan
Thanks to Marcel and Alan.
By the way, please let me clarify one thing. I think, the input for
the SBC module is the RAW stream. Am I correct?
Thanks and Regards,
Madhavi M.
^ permalink raw reply
* [PATCH] Bluetooth: Use controller workqueue to create sysfs entries for links
From: Marcel Holtmann @ 2010-08-09 3:07 UTC (permalink / raw)
To: linux-bluetooth
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
---
include/net/bluetooth/hci_core.h | 3 --
net/bluetooth/hci_sysfs.c | 73 +++++++++++++++-----------------------
2 files changed, 29 insertions(+), 47 deletions(-)
diff --git a/include/net/bluetooth/hci_core.h b/include/net/bluetooth/hci_core.h
index 005f9ce..cd039c9 100644
--- a/include/net/bluetooth/hci_core.h
+++ b/include/net/bluetooth/hci_core.h
@@ -190,9 +190,6 @@ struct hci_conn {
struct timer_list disc_timer;
struct timer_list idle_timer;
- struct work_struct work_add;
- struct work_struct work_del;
-
struct device dev;
atomic_t devref;
diff --git a/net/bluetooth/hci_sysfs.c b/net/bluetooth/hci_sysfs.c
index 95a8038..78c9614 100644
--- a/net/bluetooth/hci_sysfs.c
+++ b/net/bluetooth/hci_sysfs.c
@@ -87,11 +87,35 @@ static struct device_type bt_link = {
.release = bt_link_release,
};
-static void add_conn(struct work_struct *work)
+/*
+ * The rfcomm tty device will possibly retain even when conn
+ * is down, and sysfs doesn't support move zombie device,
+ * so we should move the device before conn device is destroyed.
+ */
+static int __match_tty(struct device *dev, void *data)
+{
+ return !strncmp(dev_name(dev), "rfcomm", 6);
+}
+
+void hci_conn_init_sysfs(struct hci_conn *conn)
{
- struct hci_conn *conn = container_of(work, struct hci_conn, work_add);
struct hci_dev *hdev = conn->hdev;
+ BT_DBG("conn %p", conn);
+
+ conn->dev.type = &bt_link;
+ conn->dev.class = bt_class;
+ conn->dev.parent = &hdev->dev;
+
+ device_initialize(&conn->dev);
+}
+
+void hci_conn_add_sysfs(struct hci_conn *conn)
+{
+ struct hci_dev *hdev = conn->hdev;
+
+ BT_DBG("conn %p", conn);
+
dev_set_name(&conn->dev, "%s:%d", hdev->name, conn->handle);
dev_set_drvdata(&conn->dev, conn);
@@ -104,21 +128,12 @@ static void add_conn(struct work_struct *work)
hci_dev_hold(hdev);
}
-/*
- * The rfcomm tty device will possibly retain even when conn
- * is down, and sysfs doesn't support move zombie device,
- * so we should move the device before conn device is destroyed.
- */
-static int __match_tty(struct device *dev, void *data)
-{
- return !strncmp(dev_name(dev), "rfcomm", 6);
-}
-
-static void del_conn(struct work_struct *work)
+void hci_conn_del_sysfs(struct hci_conn *conn)
{
- struct hci_conn *conn = container_of(work, struct hci_conn, work_del);
struct hci_dev *hdev = conn->hdev;
+ BT_DBG("conn %p", conn);
+
if (!device_is_registered(&conn->dev))
return;
@@ -138,36 +153,6 @@ static void del_conn(struct work_struct *work)
hci_dev_put(hdev);
}
-void hci_conn_init_sysfs(struct hci_conn *conn)
-{
- struct hci_dev *hdev = conn->hdev;
-
- BT_DBG("conn %p", conn);
-
- conn->dev.type = &bt_link;
- conn->dev.class = bt_class;
- conn->dev.parent = &hdev->dev;
-
- device_initialize(&conn->dev);
-
- INIT_WORK(&conn->work_add, add_conn);
- INIT_WORK(&conn->work_del, del_conn);
-}
-
-void hci_conn_add_sysfs(struct hci_conn *conn)
-{
- BT_DBG("conn %p", conn);
-
- queue_work(conn->hdev->workqueue, &conn->work_add);
-}
-
-void hci_conn_del_sysfs(struct hci_conn *conn)
-{
- BT_DBG("conn %p", conn);
-
- queue_work(conn->hdev->workqueue, &conn->work_del);
-}
-
static inline char *host_bustostr(int bus)
{
switch (bus) {
--
1.6.6.1
^ permalink raw reply related
* [PATCH] Bluetooth: Process HCI events in a workqueue instead of a tasklet
From: Marcel Holtmann @ 2010-08-09 3:06 UTC (permalink / raw)
To: linux-bluetooth
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
---
include/net/bluetooth/hci_core.h | 2 +
net/bluetooth/hci_core.c | 58 ++++++++++++++++++++++++++++++++-----
2 files changed, 52 insertions(+), 8 deletions(-)
diff --git a/include/net/bluetooth/hci_core.h b/include/net/bluetooth/hci_core.h
index e17849e..005f9ce 100644
--- a/include/net/bluetooth/hci_core.h
+++ b/include/net/bluetooth/hci_core.h
@@ -109,12 +109,14 @@ struct hci_dev {
struct workqueue_struct *workqueue;
+ struct work_struct evt_work;
struct tasklet_struct cmd_task;
struct tasklet_struct rx_task;
struct tasklet_struct tx_task;
struct sk_buff_head rx_q;
struct sk_buff_head raw_q;
+ struct sk_buff_head evt_q;
struct sk_buff_head cmd_q;
struct sk_buff *sent_cmd;
diff --git a/net/bluetooth/hci_core.c b/net/bluetooth/hci_core.c
index 8b4baac..7e3fc60 100644
--- a/net/bluetooth/hci_core.c
+++ b/net/bluetooth/hci_core.c
@@ -50,6 +50,7 @@
#include <net/bluetooth/bluetooth.h>
#include <net/bluetooth/hci_core.h>
+static void hci_evt_work(struct work_struct *work);
static void hci_cmd_task(unsigned long arg);
static void hci_rx_task(unsigned long arg);
static void hci_tx_task(unsigned long arg);
@@ -521,7 +522,9 @@ int hci_dev_open(__u16 dev)
tasklet_kill(&hdev->rx_task);
tasklet_kill(&hdev->tx_task);
tasklet_kill(&hdev->cmd_task);
+ cancel_work_sync(&hdev->evt_work);
+ skb_queue_purge(&hdev->evt_q);
skb_queue_purge(&hdev->cmd_q);
skb_queue_purge(&hdev->rx_q);
@@ -570,6 +573,7 @@ static int hci_dev_do_close(struct hci_dev *hdev)
hdev->flush(hdev);
/* Reset device */
+ skb_queue_purge(&hdev->evt_q);
skb_queue_purge(&hdev->cmd_q);
atomic_set(&hdev->cmd_cnt, 1);
if (!test_bit(HCI_RAW, &hdev->flags)) {
@@ -579,11 +583,13 @@ static int hci_dev_do_close(struct hci_dev *hdev)
clear_bit(HCI_INIT, &hdev->flags);
}
- /* Kill cmd task */
+ /* Kill cmd task and evt work */
tasklet_kill(&hdev->cmd_task);
+ cancel_work_sync(&hdev->evt_work);
/* Drop queues */
skb_queue_purge(&hdev->rx_q);
+ skb_queue_purge(&hdev->evt_q);
skb_queue_purge(&hdev->cmd_q);
skb_queue_purge(&hdev->raw_q);
@@ -634,6 +640,7 @@ int hci_dev_reset(__u16 dev)
/* Drop queues */
skb_queue_purge(&hdev->rx_q);
+ skb_queue_purge(&hdev->evt_q);
skb_queue_purge(&hdev->cmd_q);
hci_dev_lock_bh(hdev);
@@ -905,11 +912,14 @@ int hci_register_dev(struct hci_dev *hdev)
hdev->sniff_max_interval = 800;
hdev->sniff_min_interval = 80;
+ INIT_WORK(&hdev->evt_work, hci_evt_work);
+
tasklet_init(&hdev->cmd_task, hci_cmd_task,(unsigned long) hdev);
tasklet_init(&hdev->rx_task, hci_rx_task, (unsigned long) hdev);
tasklet_init(&hdev->tx_task, hci_tx_task, (unsigned long) hdev);
skb_queue_head_init(&hdev->rx_q);
+ skb_queue_head_init(&hdev->evt_q);
skb_queue_head_init(&hdev->cmd_q);
skb_queue_head_init(&hdev->raw_q);
@@ -1022,9 +1032,19 @@ int hci_recv_frame(struct sk_buff *skb)
/* Time stamp */
__net_timestamp(skb);
- /* Queue frame for rx task */
- skb_queue_tail(&hdev->rx_q, skb);
- tasklet_schedule(&hdev->rx_task);
+ switch (bt_cb(skb)->pkt_type) {
+ case HCI_EVENT_PKT:
+ /* Queue frame for event processing */
+ skb_queue_tail(&hdev->evt_q, skb);
+ queue_work(hdev->workqueue, &hdev->evt_work);
+ break;
+
+ default:
+ /* Queue frame for rx task */
+ skb_queue_tail(&hdev->rx_q, skb);
+ tasklet_schedule(&hdev->rx_task);
+ break;
+ }
return 0;
}
@@ -1614,10 +1634,6 @@ static void hci_rx_task(unsigned long arg)
/* Process frame */
switch (bt_cb(skb)->pkt_type) {
- case HCI_EVENT_PKT:
- hci_event_packet(hdev, skb);
- break;
-
case HCI_ACLDATA_PKT:
BT_DBG("%s ACL data packet", hdev->name);
hci_acldata_packet(hdev, skb);
@@ -1663,3 +1679,29 @@ static void hci_cmd_task(unsigned long arg)
}
}
}
+
+static void hci_evt_work(struct work_struct *work)
+{
+ struct hci_dev *hdev = container_of(work, struct hci_dev, evt_work);
+ struct sk_buff *skb;
+
+ BT_DBG("%s", hdev->name);
+
+ read_lock(&hci_task_lock);
+
+ while ((skb = skb_dequeue(&hdev->evt_q))) {
+ if (atomic_read(&hdev->promisc)) {
+ /* Send copy to the sockets */
+ hci_send_to_sock(hdev, skb);
+ }
+
+ if (test_bit(HCI_RAW, &hdev->flags)) {
+ kfree_skb(skb);
+ continue;
+ }
+
+ hci_event_packet(hdev, skb);
+ }
+
+ read_unlock(&hci_task_lock);
+}
--
1.6.6.1
^ permalink raw reply related
* Re: [PATCH 8/9] Bluetooth: Use a stream-oriented recvmsg with SOCK_STREAM L2CAP sockets.
From: Marcel Holtmann @ 2010-08-09 2:50 UTC (permalink / raw)
To: Mat Martineau; +Cc: linux-bluetooth, gustavo, rshaffer, linux-arm-msm
In-Reply-To: <1281048867-32630-9-git-send-email-mathewm@codeaurora.org>
Hi Mat,
> L2CAP ERTM sockets can be opened with the SOCK_STREAM socket type,
> which is a mandatory request for ERTM mode.
>
> However, these sockets still have SOCK_SEQPACKET read semantics when
> bt_sock_recvmsg() is used to pull data from the receive queue. If the
> application is only reading part of a frame, then the unread portion
> of the frame is discarded. If the application requests more bytes
> than are in the current frame, only the current frame's data is
> returned.
>
> This patch utilizes common code derived from RFCOMM's recvmsg()
> function to make L2CAP SOCK_STREAM reads behave like RFCOMM reads (and
> other SOCK_STREAM sockets in general). The application may read one
> byte at a time from the input stream and not lose any data, and may
> also read across L2CAP frame boundaries.
>
> Signed-off-by: Mat Martineau <mathewm@codeaurora.org>
> ---
> net/bluetooth/l2cap.c | 5 ++++-
> 1 files changed, 4 insertions(+), 1 deletions(-)
>
> diff --git a/net/bluetooth/l2cap.c b/net/bluetooth/l2cap.c
> index 43e0eae..cd0e150 100644
> --- a/net/bluetooth/l2cap.c
> +++ b/net/bluetooth/l2cap.c
> @@ -1956,7 +1956,10 @@ static int l2cap_sock_recvmsg(struct kiocb *iocb, struct socket *sock, struct ms
>
> release_sock(sk);
>
> - return bt_sock_recvmsg(iocb, sock, msg, len, flags);
> + if (sock->type == SOCK_STREAM)
> + return bt_sock_stream_recvmsg(iocb, sock, msg, len, flags);
> + else
> + return bt_sock_recvmsg(iocb, sock, msg, len, flags);
> }
>
> static int l2cap_sock_setsockopt_old(struct socket *sock, int optname, char __user *optval, unsigned int optlen)
this is more a style issue, but I clearly prefer this:
if (sock->type == SOCK_STREAM)
return bt_sock_stream_recvmsg(iocb, sock, msg, len, flags);
return bt_sock_recvmsg(iocb, sock, msg, len, flags);
Regards
Marcel
^ 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