* Re: [PATCH v0 0/2] gdbus introspection fixes
From: Elvis Pfützenreuter @ 2011-01-15 13:31 UTC (permalink / raw)
To: Jose Antonio Santos Cadenas
Cc: Daniel Wagner, Johan Hedberg, linux-bluetooth, Daniel Wagner
In-Reply-To: <AANLkTimj_-AjrC16MzTb+6kMjtkXQkbKjOb5NO9jXCSa@mail.gmail.com>
On Jan 15, 2011, at 11:05 AM, Jose Antonio Santos Cadenas wrote:
> Hi,
>
> 2011/1/14 Daniel Wagner <wagi@monom.org>:
>> From: Daniel Wagner <daniel.wagner@bmw-carit.de>
>>
>> Hi Johan,
>>
>> During some connman debug session I found some small hickups in the
>> introspection code in gdbus. Marcel ask me to check with you first.
>>
>
> I've been thinking about the way that dbus is used in BlueZ and I am
> concerned about why we don't use glib-dbus instead of dbus directly.
> This way the dbus specific code will be maintained by glib-dbus.
>
> I've thought it several times and I've never said anything because is
> a big change and as everything was working I preferred not to make
> noise with this. But now that some bugs appeared we can probably think
> on this changing the BlueZ DBus code and all the plugins interfaces.
> The only problem I see is that this will probably require a version
> change because the way plugins expose their interface will change.
One (big) thing that makes me not to like glib-dbus is having to cope with GObject. ALso, it makes certain things more complicated and convoluted than they are in low-level API (e.g passing an array), it is poorly documented, and, incredibly enough, lacks things like the uint16 type.
My feeling goes the other way round: I wish we had the gdbus API *outside* BlueZ, as a library, so any C application could enjoy it.
^ permalink raw reply
* Re: [PATCH v0 0/2] gdbus introspection fixes
From: Jose Antonio Santos Cadenas @ 2011-01-15 13:05 UTC (permalink / raw)
To: Daniel Wagner; +Cc: Johan Hedberg, linux-bluetooth, Daniel Wagner
In-Reply-To: <1295018061-5849-1-git-send-email-wagi@monom.org>
Hi,
2011/1/14 Daniel Wagner <wagi@monom.org>:
> From: Daniel Wagner <daniel.wagner@bmw-carit.de>
>
> Hi Johan,
>
> During some connman debug session I found some small hickups in the
> introspection code in gdbus. Marcel ask me to check with you first.
>
I've been thinking about the way that dbus is used in BlueZ and I am
concerned about why we don't use glib-dbus instead of dbus directly.
This way the dbus specific code will be maintained by glib-dbus.
I've thought it several times and I've never said anything because is
a big change and as everything was working I preferred not to make
noise with this. But now that some bugs appeared we can probably think
on this changing the BlueZ DBus code and all the plugins interfaces.
The only problem I see is that this will probably require a version
change because the way plugins expose their interface will change.
> cheers,
> daniel
Regards.
Jose.
^ permalink raw reply
* Re: [PATCH resend] Bluetooth: l2cap: fix misuse of logical operation in place of bitop
From: Gustavo F. Padovan @ 2011-01-14 16:30 UTC (permalink / raw)
To: David Sterba
Cc: akpm, marcel, linux-bluetooth, netdev, linux-kernel,
João Paulo Rechi Vita
In-Reply-To: <1295013584-15592-1-git-send-email-dsterba@suse.cz>
Hi all,
* David Sterba <dsterba@suse.cz> [2011-01-14 14:59:44 +0100]:
> CC: Marcel Holtmann <marcel@holtmann.org>
> CC: "Gustavo F. Padovan" <padovan@profusion.mobi>
> CC: Jo=E3o Paulo Rechi Vita <jprvita@profusion.mobi>
> Signed-off-by: David Sterba <dsterba@suse.cz>
> ---
>=20
> Andrew, this has not been picked up by maintainers since 27.12., please c=
onsider it for -mm.
>=20
> net/bluetooth/l2cap.c | 4 ++--
> 1 files changed, 2 insertions(+), 2 deletions(-)
I'm taking care of this. Sorry for the delay, I've been away a bit.
Patch is now applied to Bluetooth tree. Thanks.
--=20
Gustavo F. Padovan
http://profusion.mobi
^ permalink raw reply
* [PATCH v0 2/2] gdbus: Remove root node 'name' attribute in introspection
From: Daniel Wagner @ 2011-01-14 15:14 UTC (permalink / raw)
To: Johan Hedberg; +Cc: linux-bluetooth, Daniel Wagner
In-Reply-To: <1295018061-5849-1-git-send-email-wagi@monom.org>
From: Daniel Wagner <daniel.wagner@bmw-carit.de>
generate_introspection_xml generates the root <node> tags with a
'name' attribute. This seems to be a valid attribute but it is not
consistent with the way the D-Bus daemon generates empty nodes.
For example if we register "/foo/bar", D-Bus daemon will generate for
"/foo" a introspection which looks like this:
<!DOCTYPE node PUBLIC "-//freedesktop//DTD D-BUS Object Introspection 1.0//EN"
"http://www.freedesktop.org/standards/dbus/1.0/introspect.dtd">
<node>
<node name="bar"/>
</node>
and generate_introspection_xml generates for "/foo/bar":
<!DOCTYPE node PUBLIC "-//freedesktop//DTD D-BUS Object Introspection 1.0//EN"
"http://www.freedesktop.org/standards/dbus/1.0/introspect.dtd">
<node name="/foo/bar">
</node>
Just don't add the 'name' attribute to the root node. The GLib
binding for D-Bus does it the same way.
---
gdbus/object.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/gdbus/object.c b/gdbus/object.c
index 49006ec..eaa2e1a 100644
--- a/gdbus/object.c
+++ b/gdbus/object.c
@@ -162,7 +162,7 @@ static void generate_introspection_xml(DBusConnection *conn,
gstr = g_string_new(DBUS_INTROSPECT_1_0_XML_DOCTYPE_DECL_NODE);
- g_string_append_printf(gstr, "<node name=\"%s\">\n", path);
+ g_string_append_printf(gstr, "<node>\n");
for (list = data->interfaces; list; list = list->next) {
struct interface_data *iface = list->data;
--
1.7.3.4
^ permalink raw reply related
* [PATCH v0 1/2] gdbus: invaldate_parent_data: walk the whole path down
From: Daniel Wagner @ 2011-01-14 15:14 UTC (permalink / raw)
To: Johan Hedberg; +Cc: linux-bluetooth, Daniel Wagner
In-Reply-To: <1295018061-5849-1-git-send-email-wagi@monom.org>
From: Daniel Wagner <daniel.wagner@bmw-carit.de>
Assume there is only one object registerd at "/". If we add a new
object at "/foo/bar" the introspection of "/" has to be updated. A new
node has to be added at "/".
invalidate_parent_data stops invaldating the whole path because the
boolean return value of dbus_connection_get_object_path_data is used
wrong.
If we get a TRUE just go on down in the path, if FALSE is return
dbus_connection_get_object_path_data has run out of memory.
---
gdbus/object.c | 7 ++++---
1 files changed, 4 insertions(+), 3 deletions(-)
diff --git a/gdbus/object.c b/gdbus/object.c
index afa904e..49006ec 100644
--- a/gdbus/object.c
+++ b/gdbus/object.c
@@ -475,12 +475,13 @@ static void invalidate_parent_data(DBusConnection *conn, const char *child_path)
if (!strlen(parent_path))
goto done;
- if (!dbus_connection_get_object_path_data(conn, parent_path,
- (void *) &data)) {
- invalidate_parent_data(conn, parent_path);
+ if (dbus_connection_get_object_path_data(conn, parent_path,
+ (void *) &data) == FALSE) {
goto done;
}
+ invalidate_parent_data(conn, parent_path);
+
if (data == NULL)
goto done;
--
1.7.3.4
^ permalink raw reply related
* [PATCH v0 0/2] gdbus introspection fixes
From: Daniel Wagner @ 2011-01-14 15:14 UTC (permalink / raw)
To: Johan Hedberg; +Cc: linux-bluetooth, Daniel Wagner
From: Daniel Wagner <daniel.wagner@bmw-carit.de>
Hi Johan,
During some connman debug session I found some small hickups in the
introspection code in gdbus. Marcel ask me to check with you first.
cheers,
daniel
Daniel Wagner (2):
gdbus: invaldate_parent_data: walk the whole path down
gdbus: Remove root node 'name' attribute in introspection
gdbus/object.c | 9 +++++----
1 files changed, 5 insertions(+), 4 deletions(-)
--
1.7.3.4
^ permalink raw reply
* Proposed interface for Message Access Profile
From: Radoslaw Jablonski @ 2011-01-14 14:28 UTC (permalink / raw)
To: linux-bluetooth@vger.kernel.org
Cc: ext Sławomir Bocheński, Bartosz Szatkowski
[-- Attachment #1: Type: text/plain, Size: 135 bytes --]
Hi!
In the attachment is proposed header with interface for BT MAP plugin
for obexd.
Please let me know your comments.
BR,
Radek
[-- Attachment #2: messages.h --]
[-- Type: text/x-chdr, Size: 8357 bytes --]
/*
*
* Message Access Protocol transport plugin
*
* Copyright (C) 2010-2011 Slawomir Bochenski <lkslawek@gmail.com>
*
*
* This program is free software; you can redistribute it and/or modify
* it under the terms of the GNU General Public License as published by
* the Free Software Foundation; either version 2 of the License, or
* (at your option) any later version.
*
* This program is distributed in the hope that it will be useful,
* but WITHOUT ANY WARRANTY; without even the implied warranty of
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
* GNU General Public License for more details.
*
* You should have received a copy of the GNU General Public License
* along with this program; if not, write to the Free Software
* Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA
*
*/
/* Tags needed to retrieve and set application parameters */
#define MAXLISTCOUNT_TAG 0x01
#define STARTOFFSET_TAG 0x02
#define FILTERMESSAGETYPE_TAG 0x03
#define FILTERPERIODBEGIN_TAG 0x04
#define FILTERPERIODEND_TAG 0x05
#define FILTERREADSTATUS_TAG 0x06
#define FILTERRECIPIENT_TAG 0x07
#define FILTERORIGINATOR_TAG 0x08
#define FILTERPRIORITY_TAG 0x09
#define ATTACHMENT_TAG 0x0A
#define TRANSPARENT_TAG 0x0B
#define RETRY_TAG 0x0C
#define NEWMESSAGE_TAG 0x0D
#define NOTIFICATIONSTATUS_TAG 0x0E
#define MASINSTANCEID_TAG 0x0F
#define PARAMETERMASK_TAG 0x10
#define FOLDERLISTINGSIZE_TAG 0x11
#define MESSAGESLISTINGSIZE_TAG 0x12
#define SUBJECTLENGTH_TAG 0x13
#define CHARSET_TAG 0x14
#define FRACTIONREQUEST_TAG 0x15
#define FRACTIONDELIVER_TAG 0x16
#define STATUSINDICATOR_TAG 0x17
#define STATUSVALUE_TAG 0x18
#define MSETIME_TAG 0x19
/* Those are used by backend to notify transport plugin which properties did it
* send
*/
#define PMASK_SUBJECT 0x0001
#define PMASK_DATETIME 0x0002
#define PMASK_SENDER_NAME 0x0004
#define PMASK_SENDER_ADDRESSING 0x0008
#define PMASK_RECIPIENT_NAME 0x0010
#define PMASK_RECIPIENT_ADDRESSING 0x0020
#define PMASK_TYPE 0x0040
#define PMASK_SIZE 0x0080
#define PMASK_RECEPTION_STATUS 0x0100
#define PMASK_TEXT 0x0200
#define PMASK_ATTACHMENT_SIZE 0x0400
#define PMASK_PRIORITY 0x0800
#define PMASK_READ 0x1000
#define PMASK_SENT 0x2000
#define PMASK_PROTECTED 0x4000
#define PMASK_REPLYTO_ADDRESSING 0x8000
/* This one is used in a response to GetFolderListing. Specification does not
* say anything about required attributes and name is the only one required by
* OBEX DTD for folder-listing. We can also consider size, modified, created and
* accessed.
*/
struct folder_entry {
char *name;
};
/* This one is used in a response to GetMessagesListing. Use PMASK_* values to
* notify the plugin which members are actually set. Backend shall not ommit
* properties required by MAP specification (subject, datetime,
* recipient_addressing, type, size, reception_status, attachment_size) unless
* ordered by PARAMETERMASK. Boolean values should be probably
* always send (need checking). Handle is mandatory. Plugin will filter out any
* properties that were not wanted by MCE.
*
* Handle shall be set to hexadecimal representation with upper-case letters. No
* prefix shall be appended and without leading zeros. This corresponds to PTS
* behaviour described in comments to the MAP specification.
*
* The rest of char * fields shall be set according to the MAP specification
* rules.
*/
struct message_data {
uint32_t mask;
char *handle;
char *subject;
char *datetime;
char *sender_name;
char *sender_addressing;
char *replyto_addressing;
char *recipient_name;
char *recipient_addressing;
char *type; /* XXX: or enum? */
char *reception_status; /* XXX: or enum? */
char *size; /* XXX: int? */
char *attachment_size; /* XXX: int? */
gboolean text;
gboolean read;
gboolean sent;
gboolean protect;
gboolean priority;
};
/* Type of message event to be delivered to MNS server */
enum message_event_type {
MET_NEW_MESSAGE,
MET_DELIVERY_SUCCESS,
MET_SENDING_SUCCESS,
MET_DELIVERY_FAILURE,
MET_SENDING_FAILURE,
MET_MEMORY_FULL,
MET_MEMORY_AVAILABLE,
MET_MESSAGE_DELETED,
MET_MESSAGE_SHIFT
};
/* Data for sending MNS notification. Handle shall be formatted as described in
* message_data.
*/
struct message_event_data {
enum message_event_type type;
uint8_t instance_id;
char *handle;
char *folder;
char *old_folder;
char *msg_type; /* XXX: enum */
};
/* TODO: This will be changed */
void messages_event(struct message_event_data *data);
/* As MAP uses application parameter extensively and actions can change based on
* whether selected parameter was send or not, plugin offers simple access
* functions to those parameters.
*/
/* Replaces value of or adds specified parameter. val should point to variable
* of appropriate type. If val is NULL, removes specified parameter.
*/
gboolean aparams_write(GHashTable *params, int tag, gpointer val);
/* Reads value of specified parameter. val should be NULL or point to variable
* of appropriate type. Returns TRUE if parameter is present. If not, then
* it returns FALSE and does not change value pointed by val.
*/
gboolean aparams_read(GHashTable *params, int tag, gpointer val);
/* See messages_open() below */
enum messages_function_id {
MFID_INVALID = 0,
MFID_SET_NOTIFICATION_REGISTRATION,
MFID_GET_FOLDER_LISTING,
MFID_GET_MESSAGES_LISTING,
MFID_GET_MESSAGE,
MFID_SET_MESSAGE_STATUS,
MFID_PUSH_MESSAGE,
MFID_UPDATE_INBOX,
};
/* Called on session connect.
*
* If session start succeeded, backend shall return non-NULL value. This value
* will be passed in all other calls to backend.
*
* This allows backend to keep track of sessions. It is needed because read
* property changes scope shall be session-limited.
*/
void *messages_connect(int *err);
/* Called on session disconnect.
*
* This call should free buffer reserved by messages_connect.
*/
void messages_disconnect(void *context);
/* INTERFACE: Callback used for GetMessage, GetMessagesListing and
* GetFolderListing. fid and user_data shall be set to those from messages_open
* call.
*
* data:
* GetMessage: const char *body
* Fragment of message body. Backend has the responsibility of
* building proper x-bt/message object.
* GetMessagesListing: const struct message_data *md
* Single entry of message listing.
* GetFolderListing: const struct folder_entry *f
* Single entry of folder listing.
*
* Set err to -EINTR if you don't want transport to start transfer immediately.
* This is especially required if you plan to set outparams -> those will be
* sent only once per request the first time err == 0. If err != 0 && err !=
* -EINTR, request is aborted and response is set accordingly.
*/
typedef void (*messages_cb)
(void *user_data, void *data, int err);
/* INTERFACE: this is called once after server starts */
int messages_init(void);
/* INTERFACE: this is called once before server finishes */
void messages_exit(void);
/* inparams
* application parameters received in the request. Use aparams_read() to
* access.
* outparams
* application parameters to send back in the response. Build with
* aparams_write().
* callback
* currently only for GetMessage, GetMessagesListing, GetFolderListing.
* Backend must call it from asynchronous event for example by using
* g_idle_add_full.
* name
* as delivered by client. Can be NULL.
*/
struct mas_request {
enum messages_function_id fid;
GHashTable *inparams;
GHashTable *outparams;
messages_cb callback; // XXX: removeme
const char *name;
};
/* Called on all GETs/PUTs. Requested function is in data->fid. Functions for
* which data->callback is set must use asynchronous mode. Other functions shall
* be completed in this call.
*
* user_data shall be passed in each callback call.
*
* Return 0 if immediate function succeded or callbacks for asynchronous one
* will follow. If return value < 0 then OBEX error will be set accordlingly and
* no further processing of session will follow.
*/
int messages_open(void *context, struct mas_request *data,
void *user_data);
/* Called always after finished request (also when ABORTed) */
int messages_close(void *context);
/* INTERFACE: sets new folder (see MAP specification for flags) */
int messages_setpath(void *session, const char *name, uint8_t flags);
^ permalink raw reply
* [PATCH resend] Bluetooth: l2cap: fix misuse of logical operation in place of bitop
From: David Sterba @ 2011-01-14 13:59 UTC (permalink / raw)
To: akpm
Cc: marcel, linux-bluetooth, netdev, linux-kernel, David Sterba,
Gustavo F. Padovan, João Paulo Rechi Vita
CC: Marcel Holtmann <marcel@holtmann.org>
CC: "Gustavo F. Padovan" <padovan@profusion.mobi>
CC: João Paulo Rechi Vita <jprvita@profusion.mobi>
Signed-off-by: David Sterba <dsterba@suse.cz>
---
Andrew, this has not been picked up by maintainers since 27.12., please consider it for -mm.
net/bluetooth/l2cap.c | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/net/bluetooth/l2cap.c b/net/bluetooth/l2cap.c
index cd8f6ea..bdfdfdc 100644
--- a/net/bluetooth/l2cap.c
+++ b/net/bluetooth/l2cap.c
@@ -1893,8 +1893,8 @@ static int l2cap_sock_sendmsg(struct kiocb *iocb, struct socket *sock, struct ms
if (pi->mode == L2CAP_MODE_STREAMING) {
l2cap_streaming_send(sk);
} else {
- if (pi->conn_state & L2CAP_CONN_REMOTE_BUSY &&
- pi->conn_state && L2CAP_CONN_WAIT_F) {
+ if ((pi->conn_state & L2CAP_CONN_REMOTE_BUSY) &&
+ (pi->conn_state & L2CAP_CONN_WAIT_F)) {
err = len;
break;
}
--
1.7.3.4.626.g73e7b
^ permalink raw reply related
* Re: [PATCHv2] Fix plugin close & disconnect functions call order
From: Johan Hedberg @ 2011-01-14 11:54 UTC (permalink / raw)
To: lkslawek; +Cc: linux-bluetooth
In-Reply-To: <1294999445-3768-1-git-send-email-lkslawek@gmail.com>
Hi Slawek,
On Fri, Jan 14, 2011, 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 | 4 ++--
> 1 files changed, 2 insertions(+), 2 deletions(-)
Pushed upstream. Thanks.
Johan
^ permalink raw reply
* [PATCH v2] HDP: reject MDL reconnection with different MTU
From: Elvis Pfützenreuter @ 2011-01-14 11:50 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 tickets 7212, 7214 and
7244 for details.)
---
health/hdp.c | 21 +++++++++++++++++++--
health/hdp_types.h | 2 ++
2 files changed, 21 insertions(+), 2 deletions(-)
diff --git a/health/hdp.c b/health/hdp.c
index dc1f803..278db68 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 imtu, omtu;
int fd;
fd = mcap_mdl_get_fd(chan->mdl);
@@ -883,6 +884,8 @@ 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_IMTU, &imtu,
+ BT_IO_OPT_OMTU, &omtu,
BT_IO_OPT_INVALID)) {
error("Error: %s", err->message);
g_io_channel_unref(io);
@@ -894,13 +897,27 @@ 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 imtu %d omtu %d Channel imtu %d omtu %d", imtu, omtu,
+ chan->imtu, chan->omtu);
+
+ if (!chan->imtu)
+ chan->imtu = imtu;
+ if (!chan->omtu)
+ chan->omtu = omtu;
+
+ return chan->imtu == imtu && chan->omtu == omtu;
}
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..7d23293 100644
--- a/health/hdp_types.h
+++ b/health/hdp_types.h
@@ -120,6 +120,8 @@ struct hdp_channel {
uint8_t config; /* Channel configuration */
uint8_t mdep; /* Remote MDEP */
uint16_t mdlid; /* Data channel Id */
+ uint16_t imtu; /* Channel incoming MTU */
+ uint16_t omtu; /* Channel outgoing 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] [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
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