* Re: [PATCH] [RFC] HDP: reject MDL reconnection with different MTU
From: Elvis Pfützenreuter @ 2011-01-14 11:27 UTC (permalink / raw)
To: Jose Antonio Santos Cadenas; +Cc: linux-bluetooth
In-Reply-To: <AANLkTikjeQ1Yemc8w1hqemk6NUdGmUr5sSBg1e9KZQR6@mail.gmail.com>
On 14 Jan 2011, at 09:15 , Jose Antonio Santos Cadenas wrote:
> 2011/1/14 Jose Antonio Santos Cadenas <jcaden@libresoft.es>:
>> 2011/1/14 José Antonio Santos Cadenas <jcaden@libresoft.es>
>>>
>>> Hi Elvis,
>>>
>>> On Thu, 13 Jan 2011 21:11:04 -0200, Elvis Pfützenreuter wrote:
>>>>
>>>> From: Elvis Pfutzenreuter <epx@signove.com>
>>>>
>>>> This patch implements refusal of a MDL reconnection if the new L2CAP
>>>> connection presents a different MTU. Accordingly to HDP spec. item 3.5.
>>>>
>>>> It aims to pass the TC_SNK_HCT_BV_07_C PTS test. (It does not pass yet
>>>> because PTS itself seems to have issues. See ticket 7121 for details.)
>>
>
> I finish the tests I'd like to do. Just I'm concerned about why you
> are using just OMTU value instead of both values IMTU and OMTU. Will
> not be better to store and check both of them?
Indeed. I will fix this and submit another round.
^ permalink raw reply
* Re: [PATCH] [RFC] HDP: reject MDL reconnection with different MTU
From: Jose Antonio Santos Cadenas @ 2011-01-14 11:15 UTC (permalink / raw)
To: Elvis Pfützenreuter; +Cc: linux-bluetooth
In-Reply-To: <AANLkTi=3QDhRvEn74radQJXWnN8Sn3KUDDBTHQk6A-Zw@mail.gmail.com>
2011/1/14 Jose Antonio Santos Cadenas <jcaden@libresoft.es>:
> 2011/1/14 José Antonio Santos Cadenas <jcaden@libresoft.es>
>>
>> Hi Elvis,
>>
>> On Thu, 13 Jan 2011 21:11:04 -0200, Elvis Pfützenreuter wrote:
>>>
>>> From: Elvis Pfutzenreuter <epx@signove.com>
>>>
>>> This patch implements refusal of a MDL reconnection if the new L2CAP
>>> connection presents a different MTU. Accordingly to HDP spec. item 3.5.
>>>
>>> It aims to pass the TC_SNK_HCT_BV_07_C PTS test. (It does not pass yet
>>> because PTS itself seems to have issues. See ticket 7121 for details.)
>
I finish the tests I'd like to do. Just I'm concerned about why you
are using just OMTU value instead of both values IMTU and OMTU. Will
not be better to store and check both of them?
Let's see if the PTS issue gets fixed soon :).
Regards.
Jose.
^ permalink raw reply
* Re: [PATCH] Add support for multiple URL in PBAP
From: Johan Hedberg @ 2011-01-14 11:05 UTC (permalink / raw)
To: Radoslaw Jablonski; +Cc: linux-bluetooth
In-Reply-To: <1294919592-2978-1-git-send-email-ext-jablonski.radoslaw@nokia.com>
Hi Radek,
On Thu, Jan 13, 2011, Radoslaw Jablonski wrote:
> Application which stores contact data changed way that
> URL data is stored. Now it is possible for contact to
> have more than one url defined with different types.
> Place where these url are stored has also changed in db.
> This fix changes handling for url in PBAP to make urls
> visible in pull results again.
> ---
> plugins/phonebook-tracker.c | 89 +++++++++++++++++++++++++++++++++++++++----
> plugins/vcard.c | 54 ++++++++++++++++++++++++--
> plugins/vcard.h | 2 +-
> 3 files changed, 132 insertions(+), 13 deletions(-)
The patch has been pushed upstream. Thanks.
Johan
^ permalink raw reply
* Re: [PATCH 1/3] Refactoring of vcard content structures
From: Johan Hedberg @ 2011-01-14 11:05 UTC (permalink / raw)
To: Radoslaw Jablonski; +Cc: linux-bluetooth
In-Reply-To: <1294904341-16047-1-git-send-email-ext-jablonski.radoslaw@nokia.com>
Hi Radek,
On Thu, Jan 13, 2011, Radoslaw Jablonski wrote:
> Structures for holding data about phone numbers, emails and
> addressess were practically identical and there was no sense
> to handle them differently. Now for saving informations about
> field content and type struct "phonebook_field" is used.
> ---
> plugins/phonebook-tracker.c | 59 ++++++++++++++++++------------------------
> plugins/vcard.c | 57 +++++++++++++++--------------------------
> plugins/vcard.h | 28 ++++----------------
> 3 files changed, 52 insertions(+), 92 deletions(-)
All three patches have been pushed upstream. Thanks.
Johan
^ permalink raw reply
* [PATCHv2] Fix plugin close & disconnect functions call order
From: lkslawek @ 2011-01-14 10:04 UTC (permalink / raw)
To: linux-bluetooth; +Cc: Slawomir Bochenski
From: Slawomir Bochenski <lkslawek@gmail.com>
Normally during an OBEX session, calling sequence
service->connect - [driver->open - driver->close]* - service->disconnect
is kept. The only exception to this when the connection is reset
(when no ABORT was sent) during transfer. Then the sequence is:
service->connect - [driver->open - driver->close]* - driver->open -
service->disconnect - driver->close
This patch fixes it, so memory managament of session/transfer data in
service plugin can be easier.
---
src/obex.c | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/src/obex.c b/src/obex.c
index 65f17fc..e45ed74 100644
--- a/src/obex.c
+++ b/src/obex.c
@@ -317,8 +317,6 @@ static void obex_session_free(struct obex_session *os)
{
sessions = g_slist_remove(sessions, os);
- os_reset_session(os);
-
if (os->io)
g_io_channel_unref(os->io);
@@ -1231,6 +1229,8 @@ static void obex_handle_destroy(void *user_data)
os = OBEX_GetUserData(obex);
+ os_reset_session(os);
+
if (os->service && os->service->disconnect)
os->service->disconnect(os, os->service_data);
--
1.7.1
^ permalink raw reply related
* Re: [PATCH] [RFC] HDP: reject MDL reconnection with different MTU
From: Jose Antonio Santos Cadenas @ 2011-01-14 9:45 UTC (permalink / raw)
To: Elvis Pfützenreuter; +Cc: linux-bluetooth
In-Reply-To: <33e10449eddb45a9d7de33c23d05e14f@libresoft.es>
2011/1/14 José Antonio Santos Cadenas <jcaden@libresoft.es>
>
> Hi Elvis,
>
> On Thu, 13 Jan 2011 21:11:04 -0200, Elvis Pfützenreuter wrote:
>>
>> From: Elvis Pfutzenreuter <epx@signove.com>
>>
>> This patch implements refusal of a MDL reconnection if the new L2CAP
>> connection presents a different MTU. Accordingly to HDP spec. item 3.5.
>>
>> It aims to pass the TC_SNK_HCT_BV_07_C PTS test. (It does not pass yet
>> because PTS itself seems to have issues. See ticket 7121 for details.)
Just a little fix, I guess the issue that you mentioned is 7212 and 7214.
Still reviewing...
>
> Nice catch!
>
> The patch seems OK for me, but please, let me some time for review this issue more deeply before pushing the patch.
>
> Regards.
>
> Jose.
>
>> ---
>> health/hdp.c | 17 +++++++++++++++--
>> health/hdp_types.h | 1 +
>> 2 files changed, 16 insertions(+), 2 deletions(-)
>>
>> diff --git a/health/hdp.c b/health/hdp.c
>> index dc1f803..4f89958 100644
>> --- a/health/hdp.c
>> +++ b/health/hdp.c
>> @@ -874,6 +874,7 @@ static gboolean check_channel_conf(struct
>> hdp_channel *chan)
>> GError *err = NULL;
>> GIOChannel *io;
>> uint8_t mode;
>> + uint16_t mtu;
>> int fd;
>>
>> fd = mcap_mdl_get_fd(chan->mdl);
>> @@ -883,6 +884,7 @@ static gboolean check_channel_conf(struct
>> hdp_channel *chan)
>>
>> if (!bt_io_get(io, BT_IO_L2CAP, &err,
>> BT_IO_OPT_MODE, &mode,
>> + BT_IO_OPT_OMTU, &mtu,
>> BT_IO_OPT_INVALID)) {
>> error("Error: %s", err->message);
>> g_io_channel_unref(io);
>> @@ -894,13 +896,24 @@ static gboolean check_channel_conf(struct
>> hdp_channel *chan)
>>
>> switch (chan->config) {
>> case HDP_RELIABLE_DC:
>> - return mode == L2CAP_MODE_ERTM;
>> + if (mode != L2CAP_MODE_ERTM)
>> + return FALSE;
>> + break;
>> case HDP_STREAMING_DC:
>> - return mode == L2CAP_MODE_STREAMING;
>> + if (mode != L2CAP_MODE_STREAMING)
>> + return FALSE;
>> + break;
>> default:
>> error("Error: Connected with unknown configuration");
>> return FALSE;
>> }
>> +
>> + DBG("MDL MTU: %d; Channel MTU: %d", mtu, chan->mtu);
>> +
>> + if (!chan->mtu)
>> + chan->mtu = mtu;
>> +
>> + return chan->mtu == mtu;
>> }
>>
>> static void hdp_mcap_mdl_connected_cb(struct mcap_mdl *mdl, void *data)
>> diff --git a/health/hdp_types.h b/health/hdp_types.h
>> index fffdb32..714cf9a 100644
>> --- a/health/hdp_types.h
>> +++ b/health/hdp_types.h
>> @@ -120,6 +120,7 @@ struct hdp_channel {
>> uint8_t config; /* Channel configuration */
>> uint8_t mdep; /* Remote MDEP */
>> uint16_t mdlid; /* Data channel Id */
>> + uint16_t mtu; /* Channel MTU */
>> struct hdp_echo_data *edata; /* private data used by echo channels */
>> gint ref; /* Reference counter */
>> };
>
> --
> 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] [RFC] HDP: reject MDL reconnection with different MTU
From: José Antonio Santos Cadenas @ 2011-01-14 9:22 UTC (permalink / raw)
To: Elvis Pfützenreuter; +Cc: linux-bluetooth
In-Reply-To: <1294960264-7622-1-git-send-email-epx@signove.com>
Hi Elvis,
On Thu, 13 Jan 2011 21:11:04 -0200, Elvis Pfützenreuter wrote:
> From: Elvis Pfutzenreuter <epx@signove.com>
>
> This patch implements refusal of a MDL reconnection if the new L2CAP
> connection presents a different MTU. Accordingly to HDP spec. item
> 3.5.
>
> It aims to pass the TC_SNK_HCT_BV_07_C PTS test. (It does not pass
> yet
> because PTS itself seems to have issues. See ticket 7121 for
> details.)
Nice catch!
The patch seems OK for me, but please, let me some time for review this
issue more deeply before pushing the patch.
Regards.
Jose.
> ---
> health/hdp.c | 17 +++++++++++++++--
> health/hdp_types.h | 1 +
> 2 files changed, 16 insertions(+), 2 deletions(-)
>
> diff --git a/health/hdp.c b/health/hdp.c
> index dc1f803..4f89958 100644
> --- a/health/hdp.c
> +++ b/health/hdp.c
> @@ -874,6 +874,7 @@ static gboolean check_channel_conf(struct
> hdp_channel *chan)
> GError *err = NULL;
> GIOChannel *io;
> uint8_t mode;
> + uint16_t mtu;
> int fd;
>
> fd = mcap_mdl_get_fd(chan->mdl);
> @@ -883,6 +884,7 @@ static gboolean check_channel_conf(struct
> hdp_channel *chan)
>
> if (!bt_io_get(io, BT_IO_L2CAP, &err,
> BT_IO_OPT_MODE, &mode,
> + BT_IO_OPT_OMTU, &mtu,
> BT_IO_OPT_INVALID)) {
> error("Error: %s", err->message);
> g_io_channel_unref(io);
> @@ -894,13 +896,24 @@ static gboolean check_channel_conf(struct
> hdp_channel *chan)
>
> switch (chan->config) {
> case HDP_RELIABLE_DC:
> - return mode == L2CAP_MODE_ERTM;
> + if (mode != L2CAP_MODE_ERTM)
> + return FALSE;
> + break;
> case HDP_STREAMING_DC:
> - return mode == L2CAP_MODE_STREAMING;
> + if (mode != L2CAP_MODE_STREAMING)
> + return FALSE;
> + break;
> default:
> error("Error: Connected with unknown configuration");
> return FALSE;
> }
> +
> + DBG("MDL MTU: %d; Channel MTU: %d", mtu, chan->mtu);
> +
> + if (!chan->mtu)
> + chan->mtu = mtu;
> +
> + return chan->mtu == mtu;
> }
>
> static void hdp_mcap_mdl_connected_cb(struct mcap_mdl *mdl, void
> *data)
> diff --git a/health/hdp_types.h b/health/hdp_types.h
> index fffdb32..714cf9a 100644
> --- a/health/hdp_types.h
> +++ b/health/hdp_types.h
> @@ -120,6 +120,7 @@ struct hdp_channel {
> uint8_t config; /* Channel configuration */
> uint8_t mdep; /* Remote MDEP */
> uint16_t mdlid; /* Data channel Id */
> + uint16_t mtu; /* Channel MTU */
> struct hdp_echo_data *edata; /* private data used by echo channels
> */
> gint ref; /* Reference counter */
> };
^ permalink raw reply
* Re: [PATCH] Add support for multiple URL in PBAP
From: Mika Linnanoja @ 2011-01-14 8:43 UTC (permalink / raw)
To: Johan Hedberg; +Cc: ext Radoslaw Jablonski, linux-bluetooth
In-Reply-To: <1294919592-2978-1-git-send-email-ext-jablonski.radoslaw@nokia.com>
On 01/13/2011 01:53 PM, ext Radoslaw Jablonski wrote:
> Application which stores contact data changed way that
> URL data is stored. Now it is possible for contact to
> have more than one url defined with different types.
> Place where these url are stored has also changed in db.
> This fix changes handling for url in PBAP to make urls
> visible in pull results again.
Patched version is tested to work.
Please accept.
BR,
Mika
> ---
> plugins/phonebook-tracker.c | 89 +++++++++++++++++++++++++++++++++++++++----
> plugins/vcard.c | 54 ++++++++++++++++++++++++--
> plugins/vcard.h | 2 +-
> 3 files changed, 132 insertions(+), 13 deletions(-)
^ permalink raw reply
* Re: [PATCH] Fix plugin close & disconnect functions call order
From: Luiz Augusto von Dentz @ 2011-01-14 7:59 UTC (permalink / raw)
To: Slawomir Bochenski; +Cc: linux-bluetooth
In-Reply-To: <AANLkTimiV7DRMNPHniyKgja-50fyDc5rSjwGF9Sm6KJk@mail.gmail.com>
Hi,
On Fri, Jan 14, 2011 at 9:13 AM, Slawomir Bochenski <lkslawek@gmail.com> wrote:
> On Thu, Jan 13, 2011 at 6:15 PM, Luiz Augusto von Dentz
> <luiz.dentz@gmail.com> wrote:
>> Hi,
>>
>> On Thu, Jan 13, 2011 at 12:52 PM, <lkslawek@gmail.com> wrote:
>>> From: Slawomir Bochenski <lkslawek@gmail.com>
>>>
>>> Normally during an OBEX session, calling sequence
>>>
>>> service->connect - [driver->open - driver->close]* - service->disconnect
>>>
>>> is kept. The only exception to this when the connection is reset
>>> (when no ABORT was sent) during transfer. Then the sequence is:
>>>
>>> service->connect - [driver->open - driver->close]* - driver->open -
>>> service->disconnect - driver->close
>>>
>>> This patch fixes it, so memory managament of session/transfer data in
>>> service plugin can be easier.
>>> ---
>>> src/obex.c | 2 ++
>>> 1 files changed, 2 insertions(+), 0 deletions(-)
>>>
>>> diff --git a/src/obex.c b/src/obex.c
>>> index 65f17fc..67684fa 100644
>>> --- a/src/obex.c
>>> +++ b/src/obex.c
>>> @@ -1231,6 +1231,8 @@ static void obex_handle_destroy(void *user_data)
>>>
>>> os = OBEX_GetUserData(obex);
>>>
>>> + os_reset_session(os);
>>> +
>>> if (os->service && os->service->disconnect)
>>> os->service->disconnect(os, os->service_data);
>>
>> Looks like a good idea, what about removing from os_session_free?
>>
>>
>> --
>> Luiz Augusto von Dentz
>> Computer Engineer
>>
>
> It looks to me that it could be safely removed from
> obex_session_free(), as when obex_session_free() is called from
> obex_session_start(), struct obex_session *os is in state in which it
> does not need reset. In fact it would be required to remove it from
> there, otherwise service->reset() would be called twice. The only side
> effect is that in case of early error in obex_session_start(),
> service->reset() will not be called at all. So the question is whether
> this last behaviour is really desired (no other service function
> indicating session existence is called before this point)?
If the service was never connected than it is probably ok, actually it
seems broken now because reset can be called after disconnect which is
probably useless.
--
Luiz Augusto von Dentz
Computer Engineer
^ permalink raw reply
* Re: [PATCH] Fix plugin close & disconnect functions call order
From: Slawomir Bochenski @ 2011-01-14 7:13 UTC (permalink / raw)
To: linux-bluetooth; +Cc: Luiz Augusto von Dentz
In-Reply-To: <AANLkTimH2pi+goj0c7Lk6AKRiYDbNQ0fG31WWagz_iZE@mail.gmail.com>
On Thu, Jan 13, 2011 at 6:15 PM, Luiz Augusto von Dentz
<luiz.dentz@gmail.com> wrote:
> Hi,
>
> On Thu, Jan 13, 2011 at 12:52 PM, <lkslawek@gmail.com> wrote:
>> From: Slawomir Bochenski <lkslawek@gmail.com>
>>
>> Normally during an OBEX session, calling sequence
>>
>> service->connect - [driver->open - driver->close]* - service->disconnect
>>
>> is kept. The only exception to this when the connection is reset
>> (when no ABORT was sent) during transfer. Then the sequence is:
>>
>> service->connect - [driver->open - driver->close]* - driver->open -
>> service->disconnect - driver->close
>>
>> This patch fixes it, so memory managament of session/transfer data in
>> service plugin can be easier.
>> ---
>> src/obex.c | 2 ++
>> 1 files changed, 2 insertions(+), 0 deletions(-)
>>
>> diff --git a/src/obex.c b/src/obex.c
>> index 65f17fc..67684fa 100644
>> --- a/src/obex.c
>> +++ b/src/obex.c
>> @@ -1231,6 +1231,8 @@ static void obex_handle_destroy(void *user_data)
>>
>> os = OBEX_GetUserData(obex);
>>
>> + os_reset_session(os);
>> +
>> if (os->service && os->service->disconnect)
>> os->service->disconnect(os, os->service_data);
>
> Looks like a good idea, what about removing from os_session_free?
>
>
> --
> Luiz Augusto von Dentz
> Computer Engineer
>
It looks to me that it could be safely removed from
obex_session_free(), as when obex_session_free() is called from
obex_session_start(), struct obex_session *os is in state in which it
does not need reset. In fact it would be required to remove it from
there, otherwise service->reset() would be called twice. The only side
effect is that in case of early error in obex_session_start(),
service->reset() will not be called at all. So the question is whether
this last behaviour is really desired (no other service function
indicating session existence is called before this point)?
--
Slawomir Bochenski
^ permalink raw reply
* Linux 2.6.22-19 bluetoothd on mediaplayer, works AND hangs
From: Jorgen Lundman @ 2011-01-14 3:34 UTC (permalink / raw)
To: linux-bluetooth
Hello list,
I am trying out the bluetooth drivers on an embedded MIPS media player. The
Linux kenrel version is locked at 2.6.22-19-sigma. Not much I can do there.
As it happens, I did get it all to work, but the "bluetoothd" process, hangs. It
hangs in a strange way where you can not kill it, and "ps" will also hang when
it inspects /proc/$pid-of-bluetoothd/ etc.
If I ignore that bluetoothd process hangs, the bluetooth device does actually
work. The device is made active before the process hangs.
For example:
sh-3.00# ./dbus-daemon --system
sh-3.00# insmod bluetooth.ko
<6>Bluetooth: Core ver 2.11
<6>NET: Registered protocol family 31
<6>Bluetooth: HCI device and connection manager initialized
<6>Bluetooth: HCI socket layer initialized
sh-3.00# insmod l2cap.ko
<6>Bluetooth: L2CAP ver 2.8
<6>Bluetooth: L2CAP socket layer initialized
sh-3.00# insmod hci_usb.ko
<6>Bluetooth: HCI USB driver ver 2.9
<6>usbcore: registered new interface driver hci_usb
sh-3.00# ./bluetoothd
(Not hung yet [1])
sh-3.00# ./usr/sbin/hciconfig -a
hci0: Type: USB
BD Address: 00:1B:DC:00:41:91 ACL MTU: 310:10 SCO MTU: 64:8
UP RUNNING
RX bytes:95 acl:0 sco:0 events:10 errors:0
TX bytes:45 acl:0 sco:0 commands:10 errors:0
Features: 0xff 0xff 0x8f 0xfe 0x9b 0xff 0x59 0x83
Packet type: DM1 DM3 DM5 DH1 DH3 DH5 HV1 HV2 HV3
Link policy:
Link mode: SLAVE ACCEPT
Name: 'PCH-C200-0'
Class: 0x000100
Service Classes: Unspecified
Device Class: Computer, Uncategorized
HCI Ver: 2.1 (0x4) HCI Rev: 0x12e7 LMP Ver: 2.1 (0x4) LMP Subver: 0x12e7
Manufacturer: Cambridge Silicon Radio (10)
Now the 'bluetoothd' process is hung - unkillable etc. What is amusing is that
the bluetooth device keeps working:
sh-3.00# ./wminput
Put Wiimote in discoverable mode now (press 1+2)...
Ready.
<6>input: Nintendo Wiimote as /class/input/input1
I have not yet found anyway to kill bluetoothd, apart from reboot. It is
annoying that is hangs like this, even though I can still use the device. If I
strace the process, I get:
writev(2, [{"bluetoothd[1813]: plugins/hciops."..., 71}, {"\n"...,
1}], 2bluetoothd[1813]: plugins/hciops.c:update_ext_inquiry_response())
= 72
[snip]
open("/var/lib/bluetooth/00:1B:DC:00:41:91/config", O_RDWR) = 17
flock(17, LOCK_EX) = 0
fstat(17, {st_mode=S_IFREG|0644, st_size=13, ...}) = 0
old_mmap(NULL, 13, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_LOCKED, 17, 0
Note the missing return value for old_mmap(). It never comes back. If I take out
update_ext_inquiry_response() entirely, it just dies in another old_mmap(). This
makes me think that the process is locked against itself somewhere earlier, and
dying in mmap() is just a symptom of that.
Are there any known issues with the version of bluetooth module that comes with
2.6.22-19 which could be my issue? Anything know relating to -sigma's kernel
patches even? Although it is peculiar the device keeps working if the problem is
in the kernel module. Debug mode I can turn on?
sh-3.00# lsmod
Module Size Used by Tainted: P
hci_usb 15872 2
l2cap 26576 6
bluetooth 66176 6 hci_usb,l2cap
If I "hciconfig hci0 down" the device, hci_usb module decreases to 1, but I can
never get it to 0 (I would guess bluetoothd holds the other one).
[1] Actually, I tried to kill bluetoothd before I run hciconfig, and even though
it is not yet stuck in mmap, the process does not die even here.
--
Jorgen Lundman | <lundman@lundman.net>
Unix Administrator | +81 (0)3 -5456-2687 ext 1017 (work)
Shibuya-ku, Tokyo | +81 (0)90-5578-8500 (cell)
Japan | +81 (0)3 -3375-1767 (home)
^ permalink raw reply
* [PATCH] bluetooth: Fix failure to release lock in read_index_list() when mem alloc fails.
From: Jesper Juhl @ 2011-01-13 23:18 UTC (permalink / raw)
To: linux-bluetooth
Cc: netdev, linux-kernel, David S. Miller, Gustavo F. Padovan,
Marcel Holtmann
If alloc_skb() fails in read_index_list() we'll return -ENOMEM without
releasing 'hci_dev_list_lock'.
Signed-off-by: Jesper Juhl <jj@chaosbits.net>
---
mgmt.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/net/bluetooth/mgmt.c b/net/bluetooth/mgmt.c
index f827fd9..ace8726 100644
--- a/net/bluetooth/mgmt.c
+++ b/net/bluetooth/mgmt.c
@@ -111,8 +111,10 @@ static int read_index_list(struct sock *sk)
body_len = sizeof(*ev) + sizeof(*rp) + (2 * count);
skb = alloc_skb(sizeof(*hdr) + body_len, GFP_ATOMIC);
- if (!skb)
+ if (!skb) {
+ read_unlock(&hci_dev_list_lock);
return -ENOMEM;
+ }
hdr = (void *) skb_put(skb, sizeof(*hdr));
hdr->opcode = cpu_to_le16(MGMT_EV_CMD_COMPLETE);
--
Jesper Juhl <jj@chaosbits.net> http://www.chaosbits.net/
Don't top-post http://www.catb.org/~esr/jargon/html/T/top-post.html
Plain text mails only, please.
^ permalink raw reply related
* [PATCH] [RFC] HDP: reject MDL reconnection with different MTU
From: Elvis Pfützenreuter @ 2011-01-13 23:11 UTC (permalink / raw)
To: linux-bluetooth; +Cc: epx
From: Elvis Pfutzenreuter <epx@signove.com>
This patch implements refusal of a MDL reconnection if the new L2CAP
connection presents a different MTU. Accordingly to HDP spec. item 3.5.
It aims to pass the TC_SNK_HCT_BV_07_C PTS test. (It does not pass yet
because PTS itself seems to have issues. See ticket 7121 for details.)
---
health/hdp.c | 17 +++++++++++++++--
health/hdp_types.h | 1 +
2 files changed, 16 insertions(+), 2 deletions(-)
diff --git a/health/hdp.c b/health/hdp.c
index dc1f803..4f89958 100644
--- a/health/hdp.c
+++ b/health/hdp.c
@@ -874,6 +874,7 @@ static gboolean check_channel_conf(struct hdp_channel *chan)
GError *err = NULL;
GIOChannel *io;
uint8_t mode;
+ uint16_t mtu;
int fd;
fd = mcap_mdl_get_fd(chan->mdl);
@@ -883,6 +884,7 @@ static gboolean check_channel_conf(struct hdp_channel *chan)
if (!bt_io_get(io, BT_IO_L2CAP, &err,
BT_IO_OPT_MODE, &mode,
+ BT_IO_OPT_OMTU, &mtu,
BT_IO_OPT_INVALID)) {
error("Error: %s", err->message);
g_io_channel_unref(io);
@@ -894,13 +896,24 @@ static gboolean check_channel_conf(struct hdp_channel *chan)
switch (chan->config) {
case HDP_RELIABLE_DC:
- return mode == L2CAP_MODE_ERTM;
+ if (mode != L2CAP_MODE_ERTM)
+ return FALSE;
+ break;
case HDP_STREAMING_DC:
- return mode == L2CAP_MODE_STREAMING;
+ if (mode != L2CAP_MODE_STREAMING)
+ return FALSE;
+ break;
default:
error("Error: Connected with unknown configuration");
return FALSE;
}
+
+ DBG("MDL MTU: %d; Channel MTU: %d", mtu, chan->mtu);
+
+ if (!chan->mtu)
+ chan->mtu = mtu;
+
+ return chan->mtu == mtu;
}
static void hdp_mcap_mdl_connected_cb(struct mcap_mdl *mdl, void *data)
diff --git a/health/hdp_types.h b/health/hdp_types.h
index fffdb32..714cf9a 100644
--- a/health/hdp_types.h
+++ b/health/hdp_types.h
@@ -120,6 +120,7 @@ struct hdp_channel {
uint8_t config; /* Channel configuration */
uint8_t mdep; /* Remote MDEP */
uint16_t mdlid; /* Data channel Id */
+ uint16_t mtu; /* Channel MTU */
struct hdp_echo_data *edata; /* private data used by echo channels */
gint ref; /* Reference counter */
};
--
1.7.0.4
^ permalink raw reply related
* Re: [PATCH] ath3k: reduce memory usage
From: Alexander Holler @ 2011-01-13 21:25 UTC (permalink / raw)
To: Gustavo F. Padovan
Cc: Marcel Holtmann, Alicke Xu, Luis R. Rodriguez, Vikram Kandukuri,
linux-bluetooth
In-Reply-To: <20110113190800.GA13675@vigoh>
Hello,
On 13.01.2011 20:08, Gustavo F. Padovan wrote:
> Hi Alexander,
>
> * Alexander Holler<holler@ahsoftware.de> [2010-11-22 21:09:01 +0100]:
>
>> There is no need to hold the firmware in memory.
>>
>> Signed-off-by: Alexander Holler<holler@ahsoftware.de>
>> ---
>> drivers/bluetooth/ath3k.c | 75 ++++++++++++---------------------------------
>> 1 files changed, 20 insertions(+), 55 deletions(-)
>
> I'm assuming you tested it a lot. Patch has been applied. Thanks.
Yes, I'm using it here haven't had a problem with that patch.
Thanks,
Alexander
^ permalink raw reply
* Re: [PATCH] ath3k: reduce memory usage
From: Gustavo F. Padovan @ 2011-01-13 19:08 UTC (permalink / raw)
To: Alexander Holler
Cc: Marcel Holtmann, Alicke Xu, Luis R. Rodriguez, Vikram Kandukuri,
linux-bluetooth
In-Reply-To: <1290456541-3812-1-git-send-email-holler@ahsoftware.de>
Hi Alexander,
* Alexander Holler <holler@ahsoftware.de> [2010-11-22 21:09:01 +0100]:
> There is no need to hold the firmware in memory.
>
> Signed-off-by: Alexander Holler <holler@ahsoftware.de>
> ---
> drivers/bluetooth/ath3k.c | 75 ++++++++++++---------------------------------
> 1 files changed, 20 insertions(+), 55 deletions(-)
I'm assuming you tested it a lot. Patch has been applied. Thanks.
--
Gustavo F. Padovan
http://profusion.mobi
^ permalink raw reply
* Re: [PATCH] Fix plugin close & disconnect functions call order
From: Luiz Augusto von Dentz @ 2011-01-13 17:15 UTC (permalink / raw)
To: lkslawek; +Cc: linux-bluetooth
In-Reply-To: <1294915924-17068-1-git-send-email-lkslawek@gmail.com>
Hi,
On Thu, Jan 13, 2011 at 12:52 PM, <lkslawek@gmail.com> wrote:
> From: Slawomir Bochenski <lkslawek@gmail.com>
>
> Normally during an OBEX session, calling sequence
>
> service->connect - [driver->open - driver->close]* - service->disconnect
>
> is kept. The only exception to this when the connection is reset
> (when no ABORT was sent) during transfer. Then the sequence is:
>
> service->connect - [driver->open - driver->close]* - driver->open -
> service->disconnect - driver->close
>
> This patch fixes it, so memory managament of session/transfer data in
> service plugin can be easier.
> ---
> src/obex.c | 2 ++
> 1 files changed, 2 insertions(+), 0 deletions(-)
>
> diff --git a/src/obex.c b/src/obex.c
> index 65f17fc..67684fa 100644
> --- a/src/obex.c
> +++ b/src/obex.c
> @@ -1231,6 +1231,8 @@ static void obex_handle_destroy(void *user_data)
>
> os = OBEX_GetUserData(obex);
>
> + os_reset_session(os);
> +
> if (os->service && os->service->disconnect)
> os->service->disconnect(os, os->service_data);
Looks like a good idea, what about removing from os_session_free?
--
Luiz Augusto von Dentz
Computer Engineer
^ permalink raw reply
* Re: [PATCH 1/1] bluetooth: Fix NULL pointer dereference issue
From: Andrei Emeltchenko @ 2011-01-13 14:37 UTC (permalink / raw)
To: Ville Tervo
Cc: Yuri Ershov, ext Gustavo F. Padovan, andrei.emeltchenko,
linux-bluetooth@vger.kernel.org
In-Reply-To: <20101210071716.GK874@null>
Hi,
On Fri, Dec 10, 2010 at 9:17 AM, Ville Tervo <ville.tervo@nokia.com> wrote:
> Hi Yuri,
>
> On Wed, Dec 08, 2010 at 01:52:09PM +0300, Yuri Ershov wrote:
>
>
>> >>>So in which situations (n == p), or (p == p->next)? That should happen only
>> >>>when p is the only element in the list, then p == head, right?
>> >>The (n == p) is in situation, when sk is unlinked by task
>> >>responsible for handling connect/disconnect requests while the
>> >>"bt_accept_dequeue". This condition is indirect checking of sk
>> >>validity.
>> >
>> >Why not using a list lock here instead? Fits a way better.
>> >
>> Yes, it's better. I tried to use the locks in this function, but it
>> slows down the task handling connect/disconnect/etc. events and the
>> task skips some events from fast clients.
What about preventing tasklet from removing socket with disabling bh?
diff --git a/net/bluetooth/af_bluetooth.c b/net/bluetooth/af_bluetooth.c
index 8cfb5a8..7ac4ba5 100644
--- a/net/bluetooth/af_bluetooth.c
+++ b/net/bluetooth/af_bluetooth.c
@@ -199,6 +199,7 @@ struct sock *bt_accept_dequeue(struct sock
*parent, struct socket *newsock)
BT_DBG("parent %p", parent);
+ local_bh_disable();
list_for_each_safe(p, n, &bt_sk(parent)->accept_q) {
sk = (struct sock *) list_entry(p, struct bt_sock, accept_q);
@@ -217,11 +218,14 @@ struct sock *bt_accept_dequeue(struct sock
*parent, struct socket *newsock)
if (newsock)
sock_graft(sk, newsock);
release_sock(sk);
+ local_bh_enable();
return sk;
}
release_sock(sk);
}
+ local_bh_enable();
+
return NULL;
}
EXPORT_SYMBOL(bt_accept_dequeue);
^ permalink raw reply related
* Re: Any flag indicating bt/fm is ready to run "hcitool cmd"
From: Johan Hedberg @ 2011-01-13 12:26 UTC (permalink / raw)
To: zhangfei gao; +Cc: linux-bluetooth
In-Reply-To: <AANLkTi=TREFQbrwpt1QacoM+ehgJK9uZjBHib6t1pk7-@mail.gmail.com>
Hi,
On Thu, Jan 13, 2011, zhangfei gao wrote:
> > The HCIDEVUP ioctl is at least synchronized with the open() callback for
> > the HCI driver so in that sense if the driver is working fine it should
> > be possible to send commands when it returns. There is however an issue
> > with existing kernels that HCIDEVUP doesn't wait for all of the kernels
> > own HCI commands to finish before returning to user space. There was a
> > patch sent for this some time ago which you might be interested in
> > trying: http://marc.info/?l=linux-bluetooth&m=129296529630642&w=4
>
> Really thanks Johan,
> The patch synchronize hci_dev_open, it solve the problem we met, and
> "hcitool cmd" could immediately send after "hciconfig hci0 up" without
> problem.
Good to hear that it's working now.
> By the way, is this patch already in the kernel?
At least it's in the bluetooth-next tree:
http://git.kernel.org/?p=linux/kernel/git/padovan/bluetooth-next-2.6.git;a=commitdiff;h=23bb57633df97ede067ea26f3cdc8a7ba2cd8109
Johan
^ permalink raw reply
* [PATCH] Add support for multiple URL in PBAP
From: Radoslaw Jablonski @ 2011-01-13 11:53 UTC (permalink / raw)
To: linux-bluetooth; +Cc: Radoslaw Jablonski
Application which stores contact data changed way that
URL data is stored. Now it is possible for contact to
have more than one url defined with different types.
Place where these url are stored has also changed in db.
This fix changes handling for url in PBAP to make urls
visible in pull results again.
---
plugins/phonebook-tracker.c | 89 +++++++++++++++++++++++++++++++++++++++----
plugins/vcard.c | 54 ++++++++++++++++++++++++--
plugins/vcard.h | 2 +-
3 files changed, 132 insertions(+), 13 deletions(-)
diff --git a/plugins/phonebook-tracker.c b/plugins/phonebook-tracker.c
index 67e4d40..f51503b 100644
--- a/plugins/phonebook-tracker.c
+++ b/plugins/phonebook-tracker.c
@@ -109,7 +109,12 @@
"}) " \
"nco:birthDate(?_contact) " \
"nco:nickname(?_contact) " \
-"nco:url(?_contact) " \
+"(SELECT GROUP_CONCAT(fn:concat( " \
+ "?url_val, \"\31\", rdfs:label(?_role) " \
+ "), \"\30\") " \
+ "WHERE {" \
+ "?_role nco:url ?url_val . " \
+"})" \
"nie:url(nco:photo(?_contact)) " \
"nco:role(?_role) " \
"nco:contactUID(?_contact) " \
@@ -181,7 +186,14 @@
"}) " \
"nco:birthDate(?_contact) " \
"nco:nickname(?_contact) " \
- "nco:url(?_contact) " \
+"(SELECT GROUP_CONCAT(fn:concat( " \
+ "?url_value, \"\31\", ?aff_type " \
+ "), \"\30\") " \
+ "WHERE {" \
+ "?_contact nco:hasAffiliation ?c_role . " \
+ "?c_role nco:url ?url_value . " \
+ "?c_role rdfs:label ?aff_type . " \
+"})" \
"nie:url(nco:photo(?_contact)) " \
"nco:role(?_role) " \
"nco:contactUID(?_contact) " \
@@ -311,7 +323,14 @@
"}) " \
"nco:birthDate(?_contact) " \
"nco:nickname(?_contact) " \
- "nco:url(?_contact) " \
+"(SELECT GROUP_CONCAT(fn:concat( " \
+ "?url_value, \"\31\", ?aff_type " \
+ "), \"\30\") " \
+ "WHERE {" \
+ "?_contact nco:hasAffiliation ?c_role . " \
+ "?c_role nco:url ?url_value . " \
+ "?c_role rdfs:label ?aff_type . " \
+"})" \
"nie:url(nco:photo(?_contact)) " \
"nco:role(?_role) " \
"nco:contactUID(?_contact) " \
@@ -440,7 +459,14 @@
"}) " \
"nco:birthDate(?_contact) " \
"nco:nickname(?_contact) " \
- "nco:url(?_contact) " \
+"(SELECT GROUP_CONCAT(fn:concat( " \
+ "?url_value, \"\31\", ?aff_type " \
+ "), \"\30\") " \
+ "WHERE {" \
+ "?_contact nco:hasAffiliation ?c_role . " \
+ "?c_role nco:url ?url_value . " \
+ "?c_role rdfs:label ?aff_type . " \
+"})" \
"nie:url(nco:photo(?_contact)) " \
"nco:role(?_role) " \
"nco:contactUID(?_contact) " \
@@ -563,7 +589,14 @@
"}) " \
"nco:birthDate(?_contact) " \
"nco:nickname(?_contact) " \
- "nco:url(?_contact) " \
+"(SELECT GROUP_CONCAT(fn:concat( " \
+ "?url_value, \"\31\", ?aff_type " \
+ "), \"\30\") " \
+ "WHERE {" \
+ "?_contact nco:hasAffiliation ?c_role . " \
+ "?c_role nco:url ?url_value . " \
+ "?c_role rdfs:label ?aff_type . " \
+"})" \
"nie:url(nco:photo(?_contact)) " \
"nco:role(?_role) " \
"nco:contactUID(?_contact) " \
@@ -732,7 +765,12 @@
"}) " \
"nco:birthDate(<%s>) " \
"nco:nickname(<%s>) " \
-"nco:url(<%s>) " \
+"(SELECT GROUP_CONCAT(fn:concat( " \
+ "?url_val, \"\31\", rdfs:label(?_role) " \
+ "), \"\30\") " \
+ "WHERE {" \
+ "?_role nco:url ?url_val . " \
+"})" \
"nie:url(nco:photo(<%s>)) " \
"nco:role(?_role) " \
"nco:contactUID(<%s>) " \
@@ -1255,6 +1293,26 @@ static void add_address(struct phonebook_contact *contact,
contact->addresses = g_slist_append(contact->addresses, addr);
}
+static void add_url(struct phonebook_contact *contact, const char *url_val,
+ int type)
+{
+ struct phonebook_field *url;
+
+ if (url_val == NULL || strlen(url_val) == 0)
+ return;
+
+ /* Not adding url if there is already added with the same value */
+ if (find_field(contact->urls, url_val, type))
+ return;
+
+ url = g_new0(struct phonebook_field, 1);
+
+ url->text = g_strdup(url_val);
+ url->type = type;
+
+ contact->urls = g_slist_append(contact->urls, url);
+}
+
static GString *gen_vcards(GSList *contacts,
const struct apparam_field *params)
{
@@ -1320,7 +1378,6 @@ static void contact_init(struct phonebook_contact *contact, char **reply)
contact->suffix = g_strdup(reply[COL_NAME_SUFFIX]);
contact->birthday = g_strdup(reply[COL_BIRTH_DATE]);
contact->nickname = g_strdup(reply[COL_NICKNAME]);
- contact->website = g_strdup(reply[COL_URL]);
contact->photo = g_strdup(reply[COL_PHOTO]);
contact->company = g_strdup(reply[COL_ORG_NAME]);
contact->department = g_strdup(reply[COL_ORG_DEPARTMENT]);
@@ -1469,6 +1526,21 @@ static void contact_add_addresses(struct phonebook_contact *contact,
g_strfreev(aff_addr);
}
+static void contact_add_urls(struct phonebook_contact *contact, char **reply)
+{
+ char **aff_url;
+ int i;
+
+ /* Addresses from affilation */
+ aff_url = g_strsplit(reply[COL_URL], MAIN_DELIM, MAX_FIELDS);
+
+ if (aff_url)
+ for(i = 0; aff_url[i] != NULL; ++i)
+ add_aff_field(contact, aff_url[i], add_url);
+
+ g_strfreev(aff_url);
+}
+
static void contact_add_organization(struct phonebook_contact *contact,
char **reply)
{
@@ -1546,6 +1618,7 @@ add_numbers:
contact_add_numbers(contact, reply);
contact_add_emails(contact, reply);
contact_add_addresses(contact, reply);
+ contact_add_urls(contact, reply);
contact_add_organization(contact, reply);
DBG("contact %p", contact);
@@ -1854,7 +1927,7 @@ void *phonebook_get_entry(const char *folder, const char *id,
if (strncmp(id, CONTACT_ID_PREFIX, strlen(CONTACT_ID_PREFIX)) == 0)
query = g_strdup_printf(CONTACTS_QUERY_FROM_URI, id, id, id, id,
id, id, id, id, id, id, id, id,
- id, id, id);
+ id, id);
else
query = g_strdup_printf(CONTACTS_OTHER_QUERY_FROM_URI,
id, id, id);
diff --git a/plugins/vcard.c b/plugins/vcard.c
index 261e264..efeba17 100644
--- a/plugins/vcard.c
+++ b/plugins/vcard.c
@@ -349,6 +349,41 @@ static void vcard_printf_email(GString *vcards, uint8_t format,
vcard_printf(vcards,"EMAIL;%s:%s", category_string, field);
}
+static void vcard_printf_url(GString *vcards, uint8_t format,
+ const char *url,
+ enum phonebook_field_type category)
+{
+ const char *category_string = "";
+
+ if (!url || strlen(url) == 0) {
+ vcard_printf(vcards, "URL:");
+ return;
+ }
+
+ switch (category) {
+ case FIELD_TYPE_HOME:
+ if (format == FORMAT_VCARD21)
+ category_string = "INTERNET;HOME";
+ else if (format == FORMAT_VCARD30)
+ category_string = "TYPE=INTERNET;TYPE=HOME";
+ break;
+ case FIELD_TYPE_WORK:
+ if (format == FORMAT_VCARD21)
+ category_string = "INTERNET;WORK";
+ else if (format == FORMAT_VCARD30)
+ category_string = "TYPE=INTERNET;TYPE=WORK";
+ break;
+ default:
+ if (format == FORMAT_VCARD21)
+ category_string = "INTERNET";
+ else if (format == FORMAT_VCARD30)
+ category_string = "TYPE=INTERNET";
+ break;
+ }
+
+ vcard_printf(vcards,"URL;%s:%s", category_string, url);
+}
+
static gboolean org_fields_present(struct phonebook_contact *contact)
{
if (contact->company && strlen(contact->company))
@@ -530,9 +565,18 @@ void phonebook_add_contact(GString *vcards, struct phonebook_contact *contact,
vcard_printf_slash_tag(vcards, format, "NICKNAME", NULL,
contact->nickname);
- if (filter & FILTER_URL)
- vcard_printf_slash_tag(vcards, format, "URL", "INTERNET",
- contact->website);
+ if (filter & FILTER_URL) {
+ GSList *l = contact->urls;
+
+ if (g_slist_length(l) == 0)
+ vcard_printf_url(vcards, format, NULL,
+ FIELD_TYPE_OTHER);
+
+ for (; l; l = l->next) {
+ struct phonebook_field *url = l->data;
+ vcard_printf_url(vcards, format, url->text, url->type);
+ }
+ }
if (filter & FILTER_PHOTO)
vcard_printf_tag(vcards, format, "PHOTO", NULL,
@@ -576,6 +620,9 @@ void phonebook_contact_free(struct phonebook_contact *contact)
g_slist_foreach(contact->addresses, field_free, NULL);
g_slist_free(contact->addresses);
+ g_slist_foreach(contact->urls, field_free, NULL);
+ g_slist_free(contact->urls);
+
g_free(contact->uid);
g_free(contact->fullname);
g_free(contact->given);
@@ -585,7 +632,6 @@ void phonebook_contact_free(struct phonebook_contact *contact)
g_free(contact->suffix);
g_free(contact->birthday);
g_free(contact->nickname);
- g_free(contact->website);
g_free(contact->photo);
g_free(contact->company);
g_free(contact->department);
diff --git a/plugins/vcard.h b/plugins/vcard.h
index 379f92c..88cdbed 100644
--- a/plugins/vcard.h
+++ b/plugins/vcard.h
@@ -58,7 +58,7 @@ struct phonebook_contact {
GSList *addresses;
char *birthday;
char *nickname;
- char *website;
+ GSList *urls;
char *photo;
char *company;
char *department;
--
1.7.0.4
^ permalink raw reply related
* [PATCH] Fix plugin close & disconnect functions call order
From: lkslawek @ 2011-01-13 10:52 UTC (permalink / raw)
To: linux-bluetooth; +Cc: Slawomir Bochenski
From: Slawomir Bochenski <lkslawek@gmail.com>
Normally during an OBEX session, calling sequence
service->connect - [driver->open - driver->close]* - service->disconnect
is kept. The only exception to this when the connection is reset
(when no ABORT was sent) during transfer. Then the sequence is:
service->connect - [driver->open - driver->close]* - driver->open -
service->disconnect - driver->close
This patch fixes it, so memory managament of session/transfer data in
service plugin can be easier.
---
src/obex.c | 2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/src/obex.c b/src/obex.c
index 65f17fc..67684fa 100644
--- a/src/obex.c
+++ b/src/obex.c
@@ -1231,6 +1231,8 @@ static void obex_handle_destroy(void *user_data)
os = OBEX_GetUserData(obex);
+ os_reset_session(os);
+
if (os->service && os->service->disconnect)
os->service->disconnect(os, os->service_data);
--
1.7.1
^ permalink raw reply related
* Re: [PATCH] Bluetooth: Check authorization when sec_level goes high.
From: Matti J. Aaltonen @ 2011-01-13 8:08 UTC (permalink / raw)
To: ext Luiz Augusto von Dentz; +Cc: linux-bluetooth, marcel, padovan
In-Reply-To: <AANLkTikm8_spOCzLAFytNfNEFxxaqNhTxK__YVjkSxe-@mail.gmail.com>
Hello
On Thu, 2011-01-13 at 00:31 +0200, ext Luiz Augusto von Dentz wrote:
> Hi,
>
> On Wed, Jan 12, 2011 at 2:08 PM, Matti J. Aaltonen
> <matti.j.aaltonen@nokia.com> wrote:
> > Initiate authorization check also in cases where the
> > security level of an existing connection changes to
> > BT_SECURITY_HIGH.
> >
> > This patch fixes a bug which makes commands bluez-test-device and
> > bluez-simple-agent fail, if the latter is given before the connection
> > created by bluez-test-device has expired.
> >
> I don't think this fixes the problem properly, the authentication
> request could have been sent before because other levels might require
> it, also Im afraid this can break sockets using the same link since
> the state got reseted to BT_CONFIG when it could previously be
> BT_CONNECTED, what happens if there a socket in use and the link is
> set back to BT_CONFIG after connected?
Yes. One of our bluetooth specialists suggested a simpler and probably
better fix for this. He'll probably send his patch shortly...
Thanks,
Matti
^ permalink raw reply
* [PATCH 3/3] Remove redundant functions for adding addressess and emails
From: Radoslaw Jablonski @ 2011-01-13 7:39 UTC (permalink / raw)
To: linux-bluetooth; +Cc: Radoslaw Jablonski
Functions "add_aff_email" and "add_aff_address" were doing
basically the same thing. Now for splitting fields and
adding them to contact structure "add_aff_field" is used.
---
plugins/phonebook-tracker.c | 42 ++++++++----------------------------------
1 files changed, 8 insertions(+), 34 deletions(-)
diff --git a/plugins/phonebook-tracker.c b/plugins/phonebook-tracker.c
index 204f0fd..67e4d40 100644
--- a/plugins/phonebook-tracker.c
+++ b/plugins/phonebook-tracker.c
@@ -856,6 +856,9 @@
typedef void (*reply_list_foreach_t) (char **reply, int num_fields,
void *user_data);
+typedef void (*add_field_t) (struct phonebook_contact *contact,
+ const char *value, int type);
+
struct pending_reply {
reply_list_foreach_t callback;
void *user_data;
@@ -1403,7 +1406,8 @@ static enum phonebook_field_type get_field_type(const char *affilation)
return FIELD_TYPE_OTHER;
}
-static void add_aff_email(struct phonebook_contact *contact, char *aff_email)
+static void add_aff_field(struct phonebook_contact *contact, char *aff_email,
+ add_field_t add_field_cb)
{
char **email_parts;
char *type, *email;
@@ -1426,7 +1430,7 @@ static void add_aff_email(struct phonebook_contact *contact, char *aff_email)
else
goto failed;
- add_email(contact, email, get_field_type(type));
+ add_field_cb(contact, email, get_field_type(type));
failed:
g_strfreev(email_parts);
@@ -1443,40 +1447,11 @@ static void contact_add_emails(struct phonebook_contact *contact,
if (aff_emails)
for(i = 0; aff_emails[i] != NULL; ++i)
- add_aff_email(contact, aff_emails[i]);
+ add_aff_field(contact, aff_emails[i], add_email);
g_strfreev(aff_emails);
}
-static void add_aff_address(struct phonebook_contact *contact, char *aff_addr)
-{
- char **addr_parts;
- char *type, *address;
-
- /* Addresses from affilation data, are represented as real address
- * string and affilation type - those strings are separated by
- * SUB_DELIM string */
- addr_parts = g_strsplit(aff_addr, SUB_DELIM, 2);
-
- if (!addr_parts)
- return;
-
- if (addr_parts[0])
- address = addr_parts[0];
- else
- goto failed;
-
- if (addr_parts[1])
- type = addr_parts[1];
- else
- goto failed;
-
- add_address(contact, address, get_field_type(type));
-
-failed:
- g_strfreev(addr_parts);
-}
-
static void contact_add_addresses(struct phonebook_contact *contact,
char **reply)
{
@@ -1489,12 +1464,11 @@ static void contact_add_addresses(struct phonebook_contact *contact,
if (aff_addr)
for(i = 0; aff_addr[i] != NULL; ++i)
- add_aff_address(contact, aff_addr[i]);
+ add_aff_field(contact, aff_addr[i], add_address);
g_strfreev(aff_addr);
}
-
static void contact_add_organization(struct phonebook_contact *contact,
char **reply)
{
--
1.7.0.4
^ permalink raw reply related
* [PATCH 2/3] Simplify add numbers/emails/addresses logic in PBAP
From: Radoslaw Jablonski @ 2011-01-13 7:39 UTC (permalink / raw)
To: linux-bluetooth; +Cc: Radoslaw Jablonski
There was 3 diffent functions for doing the same -
checking if some field is already added. Now using only
function named "find_field" for that purpose.
---
plugins/phonebook-tracker.c | 46 +++++++-----------------------------------
1 files changed, 8 insertions(+), 38 deletions(-)
diff --git a/plugins/phonebook-tracker.c b/plugins/phonebook-tracker.c
index 9354a47..204f0fd 100644
--- a/plugins/phonebook-tracker.c
+++ b/plugins/phonebook-tracker.c
@@ -1178,17 +1178,17 @@ static struct phonebook_contact *find_contact(GSList *contacts, const char *id)
return NULL;
}
-static struct phonebook_field *find_phone(GSList *numbers, const char *phone,
+static struct phonebook_field *find_field(GSList *fields, const char *value,
int type)
{
GSList *l;
- for (l = numbers; l; l = l->next) {
- struct phonebook_field *pb_num = l->data;
+ for (l = fields; l; l = l->next) {
+ struct phonebook_field *field = l->data;
/* Returning phonebook number if phone values and type values
* are equal */
- if (g_strcmp0(pb_num->text, phone) == 0 && pb_num->type == type)
- return pb_num;
+ if (g_strcmp0(field->text, value) == 0 && field->type == type)
+ return field;
}
return NULL;
@@ -1203,7 +1203,7 @@ static void add_phone_number(struct phonebook_contact *contact,
return;
/* Not adding number if there is already added with the same value */
- if (find_phone(contact->numbers, phone, type))
+ if (find_field(contact->numbers, phone, type))
return;
number = g_new0(struct phonebook_field, 1);
@@ -1213,21 +1213,6 @@ static void add_phone_number(struct phonebook_contact *contact,
contact->numbers = g_slist_append(contact->numbers, number);
}
-static struct phonebook_field *find_email(GSList *emails, const char *address,
- int type)
-{
- GSList *l;
-
- for (l = emails; l; l = l->next) {
- struct phonebook_field *email = l->data;
- if (g_strcmp0(email->text, address) == 0 &&
- email->type == type)
- return email;
- }
-
- return NULL;
-}
-
static void add_email(struct phonebook_contact *contact, const char *address,
int type)
{
@@ -1237,7 +1222,7 @@ static void add_email(struct phonebook_contact *contact, const char *address,
return;
/* Not adding email if there is already added with the same value */
- if (find_email(contact->emails, address, type))
+ if (find_field(contact->emails, address, type))
return;
email = g_new0(struct phonebook_field, 1);
@@ -1247,21 +1232,6 @@ static void add_email(struct phonebook_contact *contact, const char *address,
contact->emails = g_slist_append(contact->emails, email);
}
-static struct phonebook_field *find_address(GSList *addresses,
- const char *address, int type)
-{
- GSList *l;
-
- for (l = addresses; l; l = l->next) {
- struct phonebook_field *addr = l->data;
- if (g_strcmp0(addr->text, address) == 0 &&
- addr->type == type)
- return addr;
- }
-
- return NULL;
-}
-
static void add_address(struct phonebook_contact *contact,
const char *address, int type)
{
@@ -1271,7 +1241,7 @@ static void add_address(struct phonebook_contact *contact,
return;
/* Not adding address if there is already added with the same value */
- if (find_address(contact->addresses, address, type))
+ if (find_field(contact->addresses, address, type))
return;
addr = g_new0(struct phonebook_field, 1);
--
1.7.0.4
^ permalink raw reply related
* [PATCH 1/3] Refactoring of vcard content structures
From: Radoslaw Jablonski @ 2011-01-13 7:38 UTC (permalink / raw)
To: linux-bluetooth; +Cc: Radoslaw Jablonski
Structures for holding data about phone numbers, emails and
addressess were practically identical and there was no sense
to handle them differently. Now for saving informations about
field content and type struct "phonebook_field" is used.
---
plugins/phonebook-tracker.c | 59 ++++++++++++++++++------------------------
plugins/vcard.c | 57 +++++++++++++++--------------------------
plugins/vcard.h | 28 ++++----------------
3 files changed, 52 insertions(+), 92 deletions(-)
diff --git a/plugins/phonebook-tracker.c b/plugins/phonebook-tracker.c
index 237fb33..9354a47 100644
--- a/plugins/phonebook-tracker.c
+++ b/plugins/phonebook-tracker.c
@@ -1178,16 +1178,16 @@ static struct phonebook_contact *find_contact(GSList *contacts, const char *id)
return NULL;
}
-static struct phonebook_number *find_phone(GSList *numbers, const char *phone,
+static struct phonebook_field *find_phone(GSList *numbers, const char *phone,
int type)
{
GSList *l;
for (l = numbers; l; l = l->next) {
- struct phonebook_number *pb_num = l->data;
+ struct phonebook_field *pb_num = l->data;
/* Returning phonebook number if phone values and type values
* are equal */
- if (g_strcmp0(pb_num->tel, phone) == 0 && pb_num->type == type)
+ if (g_strcmp0(pb_num->text, phone) == 0 && pb_num->type == type)
return pb_num;
}
@@ -1197,7 +1197,7 @@ static struct phonebook_number *find_phone(GSList *numbers, const char *phone,
static void add_phone_number(struct phonebook_contact *contact,
const char *phone, int type)
{
- struct phonebook_number *number;
+ struct phonebook_field *number;
if (phone == NULL || strlen(phone) == 0)
return;
@@ -1206,21 +1206,21 @@ static void add_phone_number(struct phonebook_contact *contact,
if (find_phone(contact->numbers, phone, type))
return;
- number = g_new0(struct phonebook_number, 1);
- number->tel = g_strdup(phone);
+ number = g_new0(struct phonebook_field, 1);
+ number->text = g_strdup(phone);
number->type = type;
contact->numbers = g_slist_append(contact->numbers, number);
}
-static struct phonebook_email *find_email(GSList *emails, const char *address,
+static struct phonebook_field *find_email(GSList *emails, const char *address,
int type)
{
GSList *l;
for (l = emails; l; l = l->next) {
- struct phonebook_email *email = l->data;
- if (g_strcmp0(email->address, address) == 0 &&
+ struct phonebook_field *email = l->data;
+ if (g_strcmp0(email->text, address) == 0 &&
email->type == type)
return email;
}
@@ -1231,7 +1231,7 @@ static struct phonebook_email *find_email(GSList *emails, const char *address,
static void add_email(struct phonebook_contact *contact, const char *address,
int type)
{
- struct phonebook_email *email;
+ struct phonebook_field *email;
if (address == NULL || strlen(address) == 0)
return;
@@ -1240,21 +1240,21 @@ static void add_email(struct phonebook_contact *contact, const char *address,
if (find_email(contact->emails, address, type))
return;
- email = g_new0(struct phonebook_email, 1);
- email->address = g_strdup(address);
+ email = g_new0(struct phonebook_field, 1);
+ email->text = g_strdup(address);
email->type = type;
contact->emails = g_slist_append(contact->emails, email);
}
-static struct phonebook_address *find_address(GSList *addresses,
+static struct phonebook_field *find_address(GSList *addresses,
const char *address, int type)
{
GSList *l;
for (l = addresses; l; l = l->next) {
- struct phonebook_address *addr = l->data;
- if (g_strcmp0(addr->addr, address) == 0 &&
+ struct phonebook_field *addr = l->data;
+ if (g_strcmp0(addr->text, address) == 0 &&
addr->type == type)
return addr;
}
@@ -1265,7 +1265,7 @@ static struct phonebook_address *find_address(GSList *addresses,
static void add_address(struct phonebook_contact *contact,
const char *address, int type)
{
- struct phonebook_address *addr;
+ struct phonebook_field *addr;
if (address == NULL || address_fields_present(address) == FALSE)
return;
@@ -1274,9 +1274,9 @@ static void add_address(struct phonebook_contact *contact,
if (find_address(contact->addresses, address, type))
return;
- addr = g_new0(struct phonebook_address, 1);
+ addr = g_new0(struct phonebook_field, 1);
- addr->addr = g_strdup(address);
+ addr->text = g_strdup(address);
addr->type = type;
contact->addresses = g_slist_append(contact->addresses, addr);
@@ -1423,14 +1423,14 @@ static void contact_add_numbers(struct phonebook_contact *contact,
g_strfreev(aff_numbers);
}
-static enum phonebook_email_type get_email_type(const char *affilation)
+static enum phonebook_field_type get_field_type(const char *affilation)
{
if (g_strcmp0(AFFILATION_HOME, affilation) == 0)
- return EMAIL_TYPE_HOME;
+ return FIELD_TYPE_HOME;
else if (g_strcmp0(AFFILATION_WORK, affilation) == 0)
- return EMAIL_TYPE_WORK;
+ return FIELD_TYPE_WORK;
- return EMAIL_TYPE_OTHER;
+ return FIELD_TYPE_OTHER;
}
static void add_aff_email(struct phonebook_contact *contact, char *aff_email)
@@ -1456,7 +1456,7 @@ static void add_aff_email(struct phonebook_contact *contact, char *aff_email)
else
goto failed;
- add_email(contact, email, get_email_type(type));
+ add_email(contact, email, get_field_type(type));
failed:
g_strfreev(email_parts);
@@ -1478,16 +1478,6 @@ static void contact_add_emails(struct phonebook_contact *contact,
g_strfreev(aff_emails);
}
-static enum phonebook_address_type get_addr_type(const char *affilation)
-{
- if (g_strcmp0(AFFILATION_HOME, affilation) == 0)
- return ADDR_TYPE_HOME;
- else if (g_strcmp0(AFFILATION_WORK, affilation) == 0)
- return ADDR_TYPE_WORK;
-
- return ADDR_TYPE_OTHER;
-}
-
static void add_aff_address(struct phonebook_contact *contact, char *aff_addr)
{
char **addr_parts;
@@ -1511,7 +1501,7 @@ static void add_aff_address(struct phonebook_contact *contact, char *aff_addr)
else
goto failed;
- add_address(contact, address, get_addr_type(type));
+ add_address(contact, address, get_field_type(type));
failed:
g_strfreev(addr_parts);
@@ -1534,6 +1524,7 @@ static void contact_add_addresses(struct phonebook_contact *contact,
g_strfreev(aff_addr);
}
+
static void contact_add_organization(struct phonebook_contact *contact,
char **reply)
{
diff --git a/plugins/vcard.c b/plugins/vcard.c
index 3f69189..261e264 100644
--- a/plugins/vcard.c
+++ b/plugins/vcard.c
@@ -315,7 +315,7 @@ static void vcard_printf_slash_tag(GString *vcards, uint8_t format,
static void vcard_printf_email(GString *vcards, uint8_t format,
const char *address,
- enum phonebook_email_type category)
+ enum phonebook_field_type category)
{
const char *category_string = "";
char field[LEN_MAX];
@@ -326,13 +326,13 @@ static void vcard_printf_email(GString *vcards, uint8_t format,
return;
}
switch (category){
- case EMAIL_TYPE_HOME:
+ case FIELD_TYPE_HOME:
if (format == FORMAT_VCARD21)
category_string = "INTERNET;HOME";
else if (format == FORMAT_VCARD30)
category_string = "TYPE=INTERNET;TYPE=HOME";
break;
- case EMAIL_TYPE_WORK:
+ case FIELD_TYPE_WORK:
if (format == FORMAT_VCARD21)
category_string = "INTERNET;WORK";
else if (format == FORMAT_VCARD30)
@@ -374,7 +374,7 @@ static void vcard_printf_org(GString *vcards,
static void vcard_printf_address(GString *vcards, uint8_t format,
const char *address,
- enum phonebook_address_type category)
+ enum phonebook_field_type category)
{
char buf[LEN_MAX];
char field[ADDR_FIELD_AMOUNT][LEN_MAX];
@@ -388,13 +388,13 @@ static void vcard_printf_address(GString *vcards, uint8_t format,
}
switch (category) {
- case ADDR_TYPE_HOME:
+ case FIELD_TYPE_HOME:
if (format == FORMAT_VCARD21)
category_string = "HOME";
else if (format == FORMAT_VCARD30)
category_string = "TYPE=HOME";
break;
- case ADDR_TYPE_WORK:
+ case FIELD_TYPE_WORK:
if (format == FORMAT_VCARD21)
category_string = "WORK";
else if (format == FORMAT_VCARD30)
@@ -487,9 +487,9 @@ void phonebook_add_contact(GString *vcards, struct phonebook_contact *contact,
TEL_TYPE_OTHER);
for (; l; l = l->next) {
- struct phonebook_number *number = l->data;
+ struct phonebook_field *number = l->data;
- vcard_printf_number(vcards, format, number->tel, 1,
+ vcard_printf_number(vcards, format, number->text, 1,
number->type);
}
}
@@ -499,11 +499,11 @@ void phonebook_add_contact(GString *vcards, struct phonebook_contact *contact,
if (g_slist_length(l) == 0)
vcard_printf_email(vcards, format, NULL,
- EMAIL_TYPE_OTHER);
+ FIELD_TYPE_OTHER);
for (; l; l = l->next){
- struct phonebook_email *email = l->data;
- vcard_printf_email(vcards, format, email->address,
+ struct phonebook_field *email = l->data;
+ vcard_printf_email(vcards, format, email->text,
email->type);
}
}
@@ -513,11 +513,11 @@ void phonebook_add_contact(GString *vcards, struct phonebook_contact *contact,
if (g_slist_length(l) == 0)
vcard_printf_address(vcards, format, NULL,
- ADDR_TYPE_OTHER);
+ FIELD_TYPE_OTHER);
for (; l; l = l->next) {
- struct phonebook_address *addr = l->data;
- vcard_printf_address(vcards, format, addr->addr,
+ struct phonebook_field *addr = l->data;
+ vcard_printf_address(vcards, format, addr->text,
addr->type);
}
}
@@ -553,28 +553,13 @@ void phonebook_add_contact(GString *vcards, struct phonebook_contact *contact,
vcard_printf_end(vcards);
}
-static void number_free(gpointer data, gpointer user_data)
-{
- struct phonebook_number *number = data;
-
- g_free(number->tel);
- g_free(number);
-}
-
-static void email_free(gpointer data, gpointer user_data)
-{
- struct phonebook_email *email = data;
-
- g_free(email->address);
- g_free(email);
-}
-static void address_free(gpointer data, gpointer user_data)
+static void field_free(gpointer data, gpointer user_data)
{
- struct phonebook_address *addr = data;
+ struct phonebook_field *field = data;
- g_free(addr->addr);
- g_free(addr);
+ g_free(field->text);
+ g_free(field);
}
void phonebook_contact_free(struct phonebook_contact *contact)
@@ -582,13 +567,13 @@ void phonebook_contact_free(struct phonebook_contact *contact)
if (contact == NULL)
return;
- g_slist_foreach(contact->numbers, number_free, NULL);
+ g_slist_foreach(contact->numbers, field_free, NULL);
g_slist_free(contact->numbers);
- g_slist_foreach(contact->emails, email_free, NULL);
+ g_slist_foreach(contact->emails, field_free, NULL);
g_slist_free(contact->emails);
- g_slist_foreach(contact->addresses, address_free, NULL);
+ g_slist_foreach(contact->addresses, field_free, NULL);
g_slist_free(contact->addresses);
g_free(contact->uid);
diff --git a/plugins/vcard.h b/plugins/vcard.h
index d1c225e..379f92c 100644
--- a/plugins/vcard.h
+++ b/plugins/vcard.h
@@ -27,10 +27,10 @@ enum phonebook_number_type {
TEL_TYPE_OTHER,
};
-enum phonebook_email_type {
- EMAIL_TYPE_HOME,
- EMAIL_TYPE_WORK,
- EMAIL_TYPE_OTHER,
+enum phonebook_field_type {
+ FIELD_TYPE_HOME,
+ FIELD_TYPE_WORK,
+ FIELD_TYPE_OTHER,
};
enum phonebook_call_type {
@@ -40,24 +40,8 @@ enum phonebook_call_type {
CALL_TYPE_OUTGOING,
};
-enum phonebook_address_type {
- ADDR_TYPE_HOME,
- ADDR_TYPE_WORK,
- ADDR_TYPE_OTHER,
-};
-
-struct phonebook_number {
- char *tel;
- int type;
-};
-
-struct phonebook_email {
- char *address;
- int type;
-};
-
-struct phonebook_address {
- char *addr;
+struct phonebook_field {
+ char *text;
int type;
};
--
1.7.0.4
^ permalink raw reply related
* Re: Any flag indicating bt/fm is ready to run "hcitool cmd"
From: zhangfei gao @ 2011-01-13 6:53 UTC (permalink / raw)
To: Johan Hedberg, linux-bluetooth
In-Reply-To: <20110112083726.GA28156@jh-x301>
On Wed, Jan 12, 2011 at 3:37 AM, Johan Hedberg <johan.hedberg@gmail.com> wrote:
> Hi,
>
> On Wed, Jan 12, 2011, zhangfei gao wrote:
>> Is there any flag indicating bt/fm is ready to run "hcitool cmd", ie,
>> "hciconfig hci0 up" is really finished.
>>
>> We met error "Send failed: File descriptor in bad state", if run
>> hcitool immediately after "hciconfig hci0 up"
>> For example:
>> hciconfig hci0 up
>> hcitool cmd 3f 66 02 26 00 00 00 30
>
> The HCIDEVUP ioctl is at least synchronized with the open() callback for
> the HCI driver so in that sense if the driver is working fine it should
> be possible to send commands when it returns. There is however an issue
> with existing kernels that HCIDEVUP doesn't wait for all of the kernels
> own HCI commands to finish before returning to user space. There was a
> patch sent for this some time ago which you might be interested in
> trying: http://marc.info/?l=linux-bluetooth&m=129296529630642&w=4
Really thanks Johan,
The patch synchronize hci_dev_open, it solve the problem we met, and
"hcitool cmd" could immediately send after "hciconfig hci0 up" without
problem.
By the way, is this patch already in the kernel?
>
> 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