* Re: [PATCHv2 1/5] TODO: remove 'fix MTU exchange' task
From: Johan Hedberg @ 2011-03-18 9:24 UTC (permalink / raw)
To: Bruna Moreira; +Cc: linux-bluetooth
In-Reply-To: <1300373720-14772-1-git-send-email-bruna.moreira@openbossa.org>
Hi Bruna,
On Thu, Mar 17, 2011, Bruna Moreira wrote:
> ---
> TODO | 5 -----
> 1 files changed, 0 insertions(+), 5 deletions(-)
All five patches have now been pushed upstream. Thanks.
Johan
^ permalink raw reply
* Re: [PATCH] Set correct adapter state in cancel_resolve_name
From: Johan Hedberg @ 2011-03-18 9:24 UTC (permalink / raw)
To: Radoslaw Jablonski; +Cc: linux-bluetooth
In-Reply-To: <1300368039-1376-1-git-send-email-ext-jablonski.radoslaw@nokia.com>
Hi Radek,
On Thu, Mar 17, 2011, Radoslaw Jablonski wrote:
> Previously resetting STATE_RESOLVNAME for adapter was missing.
> This was causing problems with discovering devices when discovery
> was quickly turned off/on during resolving name.
> ---
> src/adapter.c | 1 +
> 1 files changed, 1 insertions(+), 0 deletions(-)
Pushed upstream. Thanks.
Johan
^ permalink raw reply
* Re: [PATCH] TODO: set owner of 'Whitelist support' task
From: Johan Hedberg @ 2011-03-18 9:25 UTC (permalink / raw)
To: Andre Guedes; +Cc: linux-bluetooth
In-Reply-To: <1300398914-15146-1-git-send-email-andre.guedes@openbossa.org>
Hi André,
On Thu, Mar 17, 2011, Andre Guedes wrote:
> ---
> TODO | 1 +
> 1 files changed, 1 insertions(+), 0 deletions(-)
Pushed upstream. Thanks.
Johan
^ permalink raw reply
* Re: [PATCH] Recalculate remote SEP if the codec type changes
From: Johan Hedberg @ 2011-03-18 9:43 UTC (permalink / raw)
To: Arun Raghavan; +Cc: linux-bluetooth
In-Reply-To: <1300305957-8139-1-git-send-email-arun.raghavan@collabora.co.uk>
Hi Arun,
On Thu, Mar 17, 2011, Arun Raghavan wrote:
> This forces recalculating the remote SEP if the local SEP's codec type
> is no longer the same as the remote SEP's codec type. This can happen
> after we issue a BT_STOP_STREAM+BT_CLOSE followed by a
> BT_SET_CONFIGURATION with a new SEID.
> ---
> audio/a2dp.c | 9 ++++++++-
> 1 files changed, 8 insertions(+), 1 deletions(-)
Pushed upstream. Thanks.
Johan
^ permalink raw reply
* Re: [PATCH] Fix adapter drivers unload order
From: Bastien Nocera @ 2011-03-18 11:43 UTC (permalink / raw)
To: Dmitriy Paliy; +Cc: linux-bluetooth, szymon.janc
In-Reply-To: <1300436729-3578-1-git-send-email-dmitriy.paliy@nokia.com>
On Fri, 2011-03-18 at 10:25 +0200, Dmitriy Paliy wrote:
> Order of unloading drivers shell be preserved as given in
> audio_manager_exit. It was reverted in 'c772636 Fix unloading of adapter
> drivers', which causes in turn bluetoothd crash on exit.
>
> Removing of media end-point results in removing of A2DP end-point for
> the corresponding A2DP server but not vice versa. Therefore, unregistering
> and destroying A2DP server, which clears all A2DP end-points, before media
> server is incorrect.
> ---
> src/adapter.c | 4 ++--
> 1 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/src/adapter.c b/src/adapter.c
> index 8c368fe..9fa7c4d 100644
> --- a/src/adapter.c
> +++ b/src/adapter.c
> @@ -2258,8 +2258,8 @@ static void probe_driver(struct btd_adapter *adapter, gpointer user_data)
> return;
> }
>
> - adapter->loaded_drivers = g_slist_prepend(adapter->loaded_drivers,
> - driver);
> + adapter->loaded_drivers = g_slist_append(adapter->loaded_drivers,
> + driver);
That's usually g_slist_prepend() followed by a g_slist_reverse(), not a
g_slist_append().
> }
>
> static void load_drivers(struct btd_adapter *adapter)
^ permalink raw reply
* Re: [PATCH] Fix adapter drivers unload order
From: Dmitriy Paliy @ 2011-03-18 11:59 UTC (permalink / raw)
To: ext Bastien Nocera; +Cc: linux-bluetooth, szymon.janc
In-Reply-To: <1300448640.2478.0.camel@novo.hadess.net>
Hi,
> > - adapter->loaded_drivers = g_slist_prepend(adapter->loaded_drivers,
> > - driver);
> > + adapter->loaded_drivers = g_slist_append(adapter->loaded_drivers,
> > + driver);
>
> That's usually g_slist_prepend() followed by a g_slist_reverse(), not a
> g_slist_append().
In this case append looks more appropriate if we want to be consistent
with rest of code. To be more specific with audio_manager_init and
audio_manager_exit, and btd_register_adapter_driver where drivers are
appended
adapter_drivers = g_slist_append(adapter_drivers, driver);
BR,
Dmitriy
^ permalink raw reply
* [PATCH 0/1 v2] Fix adapter drivers unload order
From: Dmitriy Paliy @ 2011-03-18 14:18 UTC (permalink / raw)
To: linux-bluetooth, hadess
Hi,
This patch includes corrections done based on Bastien's comments.
Thanks for reviewing.
BR,
Dmitriy
^ permalink raw reply
* [PATCH] Fix adapter drivers unload order
From: Dmitriy Paliy @ 2011-03-18 14:18 UTC (permalink / raw)
To: linux-bluetooth, hadess; +Cc: Dmitriy Paliy
In-Reply-To: <1300457930-16282-1-git-send-email-dmitriy.paliy@nokia.com>
Order of unloading drivers shell be preserved as given in
audio_manager_exit. It was reverted in 'c772636 Fix unloading of adapter
drivers', which causes in turn bluetoothd crash on exit.
Removing of media end-point results in removing of A2DP end-point for
the corresponding A2DP server but not vice versa. Therefore, unregistering
and destroying A2DP server, which clears all A2DP end-points, before media
server is incorrect.
---
src/adapter.c | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/src/adapter.c b/src/adapter.c
index cc4f43e..3455237 100644
--- a/src/adapter.c
+++ b/src/adapter.c
@@ -2494,6 +2494,7 @@ static void remove_driver(gpointer data, gpointer user_data)
static void unload_drivers(struct btd_adapter *adapter)
{
+ adapter->loaded_drivers = g_slist_reverse(adapter->loaded_drivers);
g_slist_foreach(adapter->loaded_drivers, remove_driver, adapter);
g_slist_free(adapter->loaded_drivers);
adapter->loaded_drivers = NULL;
--
1.7.1
^ permalink raw reply related
* [PATCH 1/2] Add action commands support to TODO
From: luiz.dentz @ 2011-03-18 16:52 UTC (permalink / raw)
To: linux-bluetooth
From: Luiz Augusto von Dentz <luiz.dentz-von@nokia.com>
---
TODO | 26 ++++++++++++++++++++++++++
1 files changed, 26 insertions(+), 0 deletions(-)
create mode 100644 TODO
diff --git a/TODO b/TODO
new file mode 100644
index 0000000..d2bbd1a
--- /dev/null
+++ b/TODO
@@ -0,0 +1,26 @@
+Background
+==========
+
+- Priority scale: High, Medium and Low
+
+- Complexity scale: C1, C2, C4 and C8. The complexity scale is exponential,
+ with complexity 1 being the lowest complexity. Complexity is a function
+ of both task 'complexity' and task 'scope'.
+
+ The general rule of thumb is that a complexity 1 task should take 1-2 weeks
+ for a person very familiar with BlueZ codebase. Higher complexity tasks
+ require more time and have higher uncertainty.
+
+ Higher complexity tasks should be refined into several lower complexity tasks
+ once the task is better understood.
+
+General
+==========
+
+- OBEX Actions are used to perform actions not primarily defined as OBEX
+ commands. This actions include, for example, moving, copying and setting the
+ permissions of objects. OBEX actions would be very useful when implementing
+ virtual filesystems over OBEX.
+
+ Priority: Medium
+ Complexity: C2
--
1.7.1
^ permalink raw reply related
* [PATCH 2/2] Add Single Response Mode to TODO
From: luiz.dentz @ 2011-03-18 16:52 UTC (permalink / raw)
To: linux-bluetooth
In-Reply-To: <1300467167-32442-1-git-send-email-luiz.dentz@gmail.com>
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1069 bytes --]
From: Luiz Augusto von Dentz <luiz.dentz-von@nokia.com>
---
TODO | 15 +++++++++++++++
1 files changed, 15 insertions(+), 0 deletions(-)
diff --git a/TODO b/TODO
index d2bbd1a..8330e71 100644
--- a/TODO
+++ b/TODO
@@ -24,3 +24,18 @@ General
Priority: Medium
Complexity: C2
+
+- Single Response Mode (SRM): The Single Response Mode header shall be used to
+ enable this mode, while the SRMP header may be used to alter the normal
+ processing of SRM for a single request/response exchange during the current
+ operation. The use of the SRMP header is optional; however, GOEP devices that
+ support SRM shall be able to receive and process this header. SRMP headers
+ should be used judiciously as this will impact the overall throughput of the
+ operation using SRM. Receipt of invalid or unexpected Single Response Mode or
+ SRMP header values shall be ignored by the receiving device.
+
+ When SRM is active the action of suspending a request can be notified using SRMP
+ “wait” option (0x01).
+
+ Priority: Low
+ Complexity: C4
--
1.7.1
^ permalink raw reply related
* [PATCH] Fix compilation against latest BlueZ
From: Anderson Lizardo @ 2011-03-18 19:10 UTC (permalink / raw)
To: linux-bluetooth; +Cc: Anderson Lizardo
BlueZ now has ntoh64()/hton64() functions in bluetooth.h, therefore the
hcidump local copy is not necessary.
---
src/hcidump.c | 16 ----------------
1 files changed, 0 insertions(+), 16 deletions(-)
diff --git a/src/hcidump.c b/src/hcidump.c
index af086c7..2023130 100644
--- a/src/hcidump.c
+++ b/src/hcidump.c
@@ -50,22 +50,6 @@
#include "parser/parser.h"
#include "parser/sdp.h"
-#if __BYTE_ORDER == __LITTLE_ENDIAN
-static inline uint64_t ntoh64(uint64_t n)
-{
- uint64_t h;
- uint64_t tmp = ntohl(n & 0x00000000ffffffff);
- h = ntohl(n >> 32);
- h |= tmp << 32;
- return h;
-}
-#elif __BYTE_ORDER == __BIG_ENDIAN
-#define ntoh64(x) (x)
-#else
-#error "Unknown byte order"
-#endif
-#define hton64(x) ntoh64(x)
-
#define SNAP_LEN HCI_MAX_FRAME_SIZE
#define DEFAULT_PORT "10839";
--
1.7.0.4
^ permalink raw reply related
* [PATCH] ath3k: Add ASUS BT Support
From: Lee Trager @ 2011-03-19 9:30 UTC (permalink / raw)
To: marcel, padovan; +Cc: linux-bluetooth
The ASUS USB Bluetooth module that comes with my motherboard(ASUS P8P67
Pro) is simply a re-branded Atheros AR3011. This patch add support for
it in the driver
Signed-off-by: Lee Trager <lt73@cs.drexel.edu>
--- drivers/bluetooth/ath3k.c.old 2011-03-18 04:27:26.160161039 -0400
+++ drivers/bluetooth/ath3k.c 2011-03-18 04:29:05.853945455 -0400
@@ -36,9 +36,12 @@
/* Atheros AR3011 */
{ USB_DEVICE(0x0CF3, 0x3000) },
- /* Atheros AR3011 with sflash firmware*/
+ /* Atheros AR3011 with sflash firmware */
{ USB_DEVICE(0x0CF3, 0x3002) },
+ /* ASUS branded Atheros AR3011 */
+ { USB_DEVICE(0x0B05, 0x179C) },
+
/* Atheros AR9285 Malbec with sflash firmware */
{ USB_DEVICE(0x03F0, 0x311D) },
^ permalink raw reply
* Re: [PATCH v5 2/4] Add support for SAP protocol
From: ANGUS.H @ 2011-03-19 14:57 UTC (permalink / raw)
To: Waldemar.Rymarkiewicz; +Cc: johan.hedberg, linux-bluetooth
In-Reply-To: <99B09243E1A5DA4898CDD8B70011144810830AAEF3@EXMB04.eu.tieto.com>
On Thu, Mar 17, 2011 at 10:50 AM, <Waldemar.Rymarkiewicz@tieto.com> wrote:
> Hi Angus.H,
>
>>A lot of code could be refactored.
>>Quite a few repeatable (logically) blocks in every
>>"...._req()" and "..._rsp()" handlers.
>>
>
> Indeed, but those blocks are not equal in all cases. Thus, I prefere to split it up into seperate functions instead of having one big function with switch-case statement.
> It's not like we can replace those blocks with one generic function without switch-case. I consider this as slightly more readable. However, I'm not strongly opposed to change it one function.
>
> Waldek
>
Hi
I just wanted to say that refactoring of typical req() here could be
seen as 3 or 4 internal prcedure calls,
[ refactoring here == extracting common/repeatable code to new routine ]
typical req example:
static void power_sim_off_req(struct sap_connection *conn)
{
- DBG("SAP_SIM_OFF_REQUEST");
+ DBG("conn %p state %d", conn, conn->state);
+
+ if (conn->state != SAP_STATE_CONNECTED)
+ goto error_rsp;
+
+ if (!is_power_sim_off_req_allowed(conn->processing_req))
+ goto error_rsp;
+
+ conn->processing_req = SAP_POWER_SIM_OFF_REQ;
+ sap_power_sim_off_req(conn);
+
+ return;
+
+error_rsp:
+ error("Processing error (state %d pr 0x%02x)", conn->state,
+ conn->processing_req);
+ sap_error_rsp(conn);
}
could be represented as:
{
validate_req(conn, VALIDATION_RULE)
assign_req(conn,REQ)
send_req(conn, handlers[REQ]) ( where handlers is an array of req/rsp
handlers to sap driver )
error_handling:
}
it's just an example, more readable/maintainable.
/AH
^ permalink raw reply
* Re: [PATCH 1/2] Add action commands support to TODO
From: Johan Hedberg @ 2011-03-19 23:21 UTC (permalink / raw)
To: luiz.dentz; +Cc: linux-bluetooth
In-Reply-To: <1300467167-32442-1-git-send-email-luiz.dentz@gmail.com>
Hi Luiz,
On Fri, Mar 18, 2011, luiz.dentz@gmail.com wrote:
> From: Luiz Augusto von Dentz <luiz.dentz-von@nokia.com>
>
> ---
> TODO | 26 ++++++++++++++++++++++++++
> 1 files changed, 26 insertions(+), 0 deletions(-)
> create mode 100644 TODO
Both patches have been pushed upstream. Thanks.
Johan
^ permalink raw reply
* [PATCH] use correct size to copy 'direction' value
From: Iain Hibbert @ 2011-03-20 20:24 UTC (permalink / raw)
To: linux-bluetooth
frm.in is stored as an uint8_t, so we cannot copy an int there
directly. use an intermediate variable so that it also works
on big-endian systems.
---
src/hcidump.c | 3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/src/hcidump.c b/src/hcidump.c
index af086c7..844720d 100644
--- a/src/hcidump.c
+++ b/src/hcidump.c
@@ -299,7 +299,8 @@ static int process_frames(int dev, int sock, int fd, unsigned long flags)
while (cmsg) {
switch (cmsg->cmsg_type) {
case HCI_CMSG_DIR:
- memcpy(&frm.in, CMSG_DATA(cmsg), sizeof(int));
+ memcpy(&i, CMSG_DATA(cmsg), sizeof(int));
+ frm.in = (uint8_t)i;
break;
case HCI_CMSG_TSTAMP:
memcpy(&frm.ts, CMSG_DATA(cmsg),
--
1.7.3.4
^ permalink raw reply related
* [PATCH] use correct size for direction value
From: Iain Hibbert @ 2011-03-20 20:24 UTC (permalink / raw)
To: linux-bluetooth
frm.in is a uint8_t, so don't copy an int there directly..
use an intermediate variable so that it works on big-endian systems
---
src/hcidump.c | 3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/src/hcidump.c b/src/hcidump.c
index af086c7..844720d 100644
--- a/src/hcidump.c
+++ b/src/hcidump.c
@@ -299,7 +299,8 @@ static int process_frames(int dev, int sock, int fd, unsigned long flags)
while (cmsg) {
switch (cmsg->cmsg_type) {
case HCI_CMSG_DIR:
- memcpy(&frm.in, CMSG_DATA(cmsg), sizeof(int));
+ memcpy(&i, CMSG_DATA(cmsg), sizeof(int));
+ frm.in = (uint8_t)i;
break;
case HCI_CMSG_TSTAMP:
memcpy(&frm.ts, CMSG_DATA(cmsg),
--
1.7.3.4
^ permalink raw reply related
* accessing Link key within the Bluetooth module
From: Suraj Sumangala @ 2011-03-21 8:38 UTC (permalink / raw)
To: Johan Hedberg, linux-bluetooth@vger.kernel.org
Hi,
I am working on a Bluetooth AMP manager module (linked to l2cap module)
that require access to the Link key of the connected(paired) device.
I am trying to use the hci_find_link_key() call with the BDADDR of the
remote device as parameter without success. It looks like the list
"hci_dev.link_keys" is not getting populated in the first place.
Note: The device is already paired with the local device, so the link
key should be available( I do see the link_key_notify_evt getting called).
is there any way to access the link key of a paired device inside the
Bluetooth module?
Regards
Suraj
^ permalink raw reply
* RE: [PATCH] Fix "possible circular locking dependency" in rfcomm
From: Ferraton, Jean RegisX @ 2011-03-21 8:43 UTC (permalink / raw)
To: Gustavo F. Padovan
Cc: marcel@holtmann.org, davem@davemloft.net, eric.dumazet@gmail.com,
xiaosuo@gmail.com, linux-bluetooth@vger.kernel.org,
linux-kernel@vger.kernel.org, netdev@vger.kernel.org
In-Reply-To: <6E42A1B4DD2F7B4D80A1F26BB498BF9F8C9F8C1539@irsmsx501.ger.corp.intel.com>
Any comment?
> -----Original Message-----
> From: linux-bluetooth-owner@vger.kernel.org [mailto:linux-bluetooth-
> owner@vger.kernel.org] On Behalf Of Ferraton, Jean RegisX
> Sent: Monday, March 14, 2011 3:56 PM
> To: Gustavo F. Padovan
> Cc: marcel@holtmann.org; davem@davemloft.net; eric.dumazet@gmail.com;
> xiaosuo@gmail.com; linux-bluetooth@vger.kernel.org; linux-
> kernel@vger.kernel.org; netdev@vger.kernel.org
> Subject: [PATCH] Fix "possible circular locking dependency" in rfcomm
>=20
> No response from original post, submit again, more details below:
>=20
> Changes in sock.c in function __rfcomm_sock_close, to release sock before
> calling rfcomm_dlc_close to avoid possible deadlock when calling
> rfcomm_lock (in rfcomm_dlc_close).
>=20
> Signed-off-by: Jean Regis Ferraton <jrferraton@gmail.com>
>=20
> ---
> net/bluetooth/rfcomm/sock.c | 3 +++
> 1 files changed, 3 insertions(+), 0 deletions(-)
>=20
> diff --git a/net/bluetooth/rfcomm/sock.c b/net/bluetooth/rfcomm/sock.c
> index 66cc1f0..3b5ec09 100644
> --- a/net/bluetooth/rfcomm/sock.c
> +++ b/net/bluetooth/rfcomm/sock.c
> @@ -234,7 +234,10 @@ static void __rfcomm_sock_close(struct sock *sk)
> case BT_CONNECT2:
> case BT_CONFIG:
> case BT_CONNECTED:
> + /* release_sock to avoid deadlock when calling rfcomm_lock()
> */
> + release_sock(sk);
> rfcomm_dlc_close(d, 0);
> + lock_sock(sk);
>=20
> default:
> sock_set_flag(sk, SOCK_ZAPPED);
> --
> 1.6.2.5
>=20
>=20
>=20
> This patch solves a problem of "possible circular locking dependency"
> related to rfcomm. Problem seen on kernel 2.6.37. Maybe it's not a bug,
> just a warning, see the trace below.
>=20
> This problem occurs in 2 cases:
> 1- When initiating a connection from the remote device
> 2- When browsing my BT device from my PC
>=20
> My analysis is the following:
> 1- We call the function rfcomm_sock_shutdown() which locks a socket, an
> after calls __rfcomm_sock_close()
> lock_sock(sk);
> if (!sk->sk_shutdown) {
> sk->sk_shutdown =3D SHUTDOWN_MASK;
> __rfcomm_sock_close(sk);
> 2- In the function __rfcomm_sock_close(), we call rfcomm_dlc_close()
> case BT_CONNECTED:
> rfcomm_dlc_close(d, 0);
> 3- In the function rfcomm_dlc_close(), we call rfcomm_lock() which locks a
> mutex on rfcomm, and this second lock causes the problem.
> rfcomm_lock();
> r =3D __rfcomm_dlc_close(d, err);
>=20
> My message trace is the following (for remote connect):
> [ 113.995511] =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
> [ 114.001897] [ INFO: possible circular locking dependency detected ]
> [ 114.008157] 2.6.37.3jrf_fix #1
> [ 114.011196] -------------------------------------------------------
> [ 114.017457] bluetoothd/511 is trying to acquire lock:
> [ 114.022499] (rfcomm_mutex){+.+.+.}, at: [<c14f281a>]
> rfcomm_dlc_close+0x15/0x30
> [ 114.029887]
> [ 114.029892] but task is already holding lock:
> [ 114.035713] (sk_lock-AF_BLUETOOTH){+.+.+.}, at: [<c14f4cfe>]
> rfcomm_sock_shutdown+0x17/0x5d
> [ 114.044147]
> [ 114.044152] which lock already depends on the new lock.
> [ 114.044158]
> [ 114.052319]
> [ 114.052324] the existing dependency chain (in reverse order) is:
> [ 114.059796]
> [ 114.059801] -> #1 (sk_lock-AF_BLUETOOTH){+.+.+.}:
> [ 114.065967] [<c105d660>] lock_acquire+0xf9/0x135
> [ 114.071184] [<c1445cf3>] lock_sock_nested+0x55/0x65
> [ 114.076662] [<c14ed17d>] l2cap_sock_sendmsg+0x3f/0x606
> [ 114.082400] [<c1443775>] sock_sendmsg+0xc9/0xe0
> [ 114.087530] [<c14437b4>] kernel_sendmsg+0x28/0x37
> [ 114.092833] [<c14f2278>] rfcomm_send_frame+0x2f/0x37
> [ 114.098398] [<c14f232c>] rfcomm_send_ua+0x57/0x59
> [ 114.103701] [<c14f3884>] rfcomm_run+0x431/0xb06
> [ 114.108830] [<c104bc8f>] kthread+0x5f/0x64
> [ 114.113525] [<c1002b7a>] kernel_thread_helper+0x6/0x1a
> [ 114.119265]
> [ 114.119270] -> #0 (rfcomm_mutex){+.+.+.}:
> [ 114.124739] [<c105cff1>] __lock_acquire+0xe03/0x1379
> [ 114.130304] [<c105d660>] lock_acquire+0xf9/0x135
> [ 114.135522] [<c1522bf3>] mutex_lock_nested+0x45/0x286
> [ 114.141171] [<c14f281a>] rfcomm_dlc_close+0x15/0x30
> [ 114.146650] [<c14f4cdb>] __rfcomm_sock_close+0x5e/0x6a
> [ 114.152388] [<c14f4d12>] rfcomm_sock_shutdown+0x2b/0x5d
> [ 114.158212] [<c14f4d5d>] rfcomm_sock_release+0x19/0x60
> [ 114.163951] [<c14445da>] sock_release+0x14/0x5b
> [ 114.169080] [<c144463d>] sock_close+0x1c/0x20
> [ 114.174037] [<c10bdd19>] fput+0xfa/0x19e
> [ 114.178557] [<c10bb3c5>] filp_close+0x51/0x5b
> [ 114.183512] [<c10bb488>] sys_close+0xb9/0xee
> [ 114.188381] [<c1002650>] sysenter_do_call+0x12/0x36
> [ 114.193858]
> [ 114.193863] other info that might help us debug this:
> [ 114.193870]
> [ 114.201860] 1 lock held by bluetoothd/511:
> [ 114.205945] #0: (sk_lock-AF_BLUETOOTH){+.+.+.}, at: [<c14f4cfe>]
> rfcomm_sock_shutdown+0x17/0x5d
> [ 114.214811]
> [ 114.214816] stack backtrace:
> [ 114.219167] Pid: 511, comm: bluetoothd Tainted: G WC
> 2.6.37.3jrf_fix #1
> [ 114.226463] Call Trace:
> [ 114.228913] [<c152108a>] ? printk+0xf/0x11
> [ 114.233086] [<c105bc3b>] print_circular_bug+0x90/0x9c
> [ 114.238211] [<c105cff1>] __lock_acquire+0xe03/0x1379
> [ 114.243260] [<c14f281a>] ? rfcomm_dlc_close+0x15/0x30
> [ 114.248382] [<c105d660>] lock_acquire+0xf9/0x135
> [ 114.253079] [<c14f281a>] ? rfcomm_dlc_close+0x15/0x30
> [ 114.258208] [<c1522bf3>] mutex_lock_nested+0x45/0x286
> [ 114.263338] [<c14f281a>] ? rfcomm_dlc_close+0x15/0x30
> [ 114.268469] [<c105b68d>] ? trace_hardirqs_on_caller+0x100/0x121
> [ 114.274467] [<c1445cf8>] ? lock_sock_nested+0x5a/0x65
> [ 114.279597] [<c105b6b9>] ? trace_hardirqs_on+0xb/0xd
> [ 114.284639] [<c14f281a>] rfcomm_dlc_close+0x15/0x30
> [ 114.289594] [<c14f4cdb>] __rfcomm_sock_close+0x5e/0x6a
> [ 114.294811] [<c14f4d12>] rfcomm_sock_shutdown+0x2b/0x5d
> [ 114.300115] [<c14f4d5d>] rfcomm_sock_release+0x19/0x60
> [ 114.305331] [<c14445da>] sock_release+0x14/0x5b
> [ 114.309937] [<c144463d>] sock_close+0x1c/0x20
> [ 114.314373] [<c10bdd19>] fput+0xfa/0x19e
> [ 114.318371] [<c10bb3c5>] filp_close+0x51/0x5b
> [ 114.322804] [<c10bb488>] sys_close+0xb9/0xee
> [ 114.327151] [<c1002650>] sysenter_do_call+0x12/0x36
> ---------------------------------------------------------------------
> Intel Corporation SAS (French simplified joint stock company)
> Registered headquarters: "Les Montalets"- 2, rue de Paris,
> 92196 Meudon Cedex, France
> Registration Number: 302 456 199 R.C.S. NANTERRE
> Capital: 4,572,000 Euros
>=20
> This e-mail and any attachments may contain confidential material for
> the sole use of the intended recipient(s). Any review or distribution
> by others is strictly prohibited. If you are not the intended
> recipient, please contact the sender and delete all copies.
>=20
> --
> 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
---------------------------------------------------------------------
Intel Corporation SAS (French simplified joint stock company)
Registered headquarters: "Les Montalets"- 2, rue de Paris,=20
92196 Meudon Cedex, France
Registration Number: 302 456 199 R.C.S. NANTERRE
Capital: 4,572,000 Euros
This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.
^ permalink raw reply
* Re: [PATCH] Fix compilation against latest BlueZ
From: Johan Hedberg @ 2011-03-21 9:09 UTC (permalink / raw)
To: Anderson Lizardo; +Cc: linux-bluetooth
In-Reply-To: <1300475419-7009-1-git-send-email-anderson.lizardo@openbossa.org>
Hi Lizardo,
On Fri, Mar 18, 2011, Anderson Lizardo wrote:
> BlueZ now has ntoh64()/hton64() functions in bluetooth.h, therefore the
> hcidump local copy is not necessary.
> ---
> src/hcidump.c | 16 ----------------
> 1 files changed, 0 insertions(+), 16 deletions(-)
Pushed upstream. Thanks.
Johan
^ permalink raw reply
* Re: [RFC] Auto Connections
From: Arun K. Singh @ 2011-03-21 11:00 UTC (permalink / raw)
To: Claudio Takahasi; +Cc: BlueZ development, Ville Tervo, Gustavo F. Padovan
In-Reply-To: <AANLkTin-Tc4s76OuJ26ktQXT7n5f7yMZbYWpMiv-Dfc4@mail.gmail.com>
Hi Claudio,
> to Jaikumar:
> The profiles will indirectly manage the connections providing
> informations such as connection parameters(interval, window, ...) and
> addresses, but the kernel needs to centralize/manage the connections.
As per section 9.3.8, a host can still perform direct connection
establishment procedure
by telling controller to "ignore the White List and process
connectible advertising
packets from a specific single device specified by the Host". Wouldn't
this be same
as letting the host[read profiles] directly manage connections?
> We can't allow the profiles to control the connection directly, a
> remote can implement more than one profile, maybe with different
> constraints. The host can also provide inputs, for instance power
> saving profile or maximum number of LE connections.
Why not? under direct connection establishment procedure, it should be
possible for a host
to establish connection with a remote peer device with host selected connection
configurable parameters. Why should we deprive a bluez host of
establishing such a connection...
Or did I miss something here?
Thanks,
Arun
^ permalink raw reply
* [PATCH 1/4] Add parsing for ATT Find By Type
From: Andre Dieb Martins @ 2011-03-21 12:18 UTC (permalink / raw)
To: linux-bluetooth; +Cc: Andre Dieb Martins
---
parser/att.c | 35 +++++++++++++++++++++++++++++++++++
1 files changed, 35 insertions(+), 0 deletions(-)
diff --git a/parser/att.c b/parser/att.c
index a0fb135..134143c 100644
--- a/parser/att.c
+++ b/parser/att.c
@@ -330,6 +330,35 @@ static void att_find_info_resp_dump(int level, struct frame *frm)
}
}
+static void att_find_by_type_req_dump(int level, struct frame *frm)
+{
+ uint16_t start = btohs(htons(get_u16(frm)));
+ uint16_t end = btohs(htons(get_u16(frm)));
+ uint16_t uuid = btohs(htons(get_u16(frm)));
+
+ p_indent(level, frm);
+ printf("start 0x%4.4x, end 0x%4.4x, uuid 0x%4.4x\n", start, end, uuid);
+
+ p_indent(level, frm);
+ printf("value");
+ while (frm->len > 0) {
+ printf(" 0x%2.2x", get_u8(frm));
+ }
+ printf("\n");
+}
+
+static void att_find_by_type_resp_dump(int level, struct frame *frm)
+{
+ while (frm->len > 0) {
+ uint16_t uuid = btohs(htons(get_u16(frm)));
+ uint16_t end = btohs(htons(get_u16(frm)));
+
+ p_indent(level, frm);
+ printf("Found attr 0x%4.4x, group end handle 0x%4.4x\n",
+ uuid, end);
+ }
+}
+
static void att_read_by_type_req_dump(int level, struct frame *frm)
{
uint16_t start = btohs(htons(get_u16(frm)));
@@ -426,6 +455,12 @@ void att_dump(int level, struct frame *frm)
case ATT_OP_FIND_INFO_RESP:
att_find_info_resp_dump(level + 1, frm);
break;
+ case ATT_OP_FIND_BY_TYPE_REQ:
+ att_find_by_type_req_dump(level + 1, frm);
+ break;
+ case ATT_OP_FIND_BY_TYPE_RESP:
+ att_find_by_type_resp_dump(level + 1, frm);
+ break;
case ATT_OP_READ_BY_TYPE_REQ:
att_read_by_type_req_dump(level + 1, frm);
break;
--
1.7.1
^ permalink raw reply related
* [PATCH 2/4] Add parsing for ATT Read Blob
From: Andre Dieb Martins @ 2011-03-21 12:18 UTC (permalink / raw)
To: linux-bluetooth; +Cc: Andre Dieb Martins
In-Reply-To: <1300709914-2838-1-git-send-email-andre.dieb@signove.com>
---
parser/att.c | 26 ++++++++++++++++++++++++++
1 files changed, 26 insertions(+), 0 deletions(-)
diff --git a/parser/att.c b/parser/att.c
index 134143c..1cba543 100644
--- a/parser/att.c
+++ b/parser/att.c
@@ -415,6 +415,26 @@ static void att_read_req_dump(int level, struct frame *frm)
printf("handle 0x%2.2x\n", handle);
}
+static void att_read_blob_req_dump(int level, struct frame *frm)
+{
+ uint16_t handle = btohs(htons(get_u16(frm)));
+ uint16_t offset = btohs(htons(get_u16(frm)));
+
+ p_indent(level, frm);
+ printf("handle 0x%4.4x offset 0x%4.4x\n", handle, offset);
+}
+
+static void att_read_blob_resp_dump(int level, struct frame *frm)
+{
+ p_indent(level, frm);
+ printf("value");
+
+ while (frm->len > 0) {
+ printf(" 0x%2.2x", get_u8(frm));
+ }
+ printf("\n");
+}
+
static void att_handle_notify_dump(int level, struct frame *frm)
{
uint16_t handle = btohs(htons(get_u16(frm)));
@@ -473,6 +493,12 @@ void att_dump(int level, struct frame *frm)
case ATT_OP_READ_RESP:
raw_dump(level + 1, frm);
break;
+ case ATT_OP_READ_BLOB_REQ:
+ att_read_blob_req_dump(level + 1, frm);
+ break;
+ case ATT_OP_READ_BLOB_RESP:
+ att_read_blob_resp_dump(level + 1, frm);
+ break;
case ATT_OP_HANDLE_NOTIFY:
att_handle_notify_dump(level + 1, frm);
break;
--
1.7.1
^ permalink raw reply related
* [PATCH 3/4] Add parsing for ATT Read By Group
From: Andre Dieb Martins @ 2011-03-21 12:18 UTC (permalink / raw)
To: linux-bluetooth; +Cc: Andre Dieb Martins
In-Reply-To: <1300709914-2838-1-git-send-email-andre.dieb@signove.com>
Additionally, fix Read By Type printf formatting for handles.
---
parser/att.c | 30 ++++++++++++++++++++++++++++--
1 files changed, 28 insertions(+), 2 deletions(-)
diff --git a/parser/att.c b/parser/att.c
index 1cba543..124aaa7 100644
--- a/parser/att.c
+++ b/parser/att.c
@@ -366,11 +366,11 @@ static void att_read_by_type_req_dump(int level, struct frame *frm)
int i;
p_indent(level, frm);
- printf("start 0x%2.2x, end 0x%2.2x\n", start, end);
+ printf("start 0x%4.4x, end 0x%4.4x\n", start, end);
p_indent(level, frm);
if (frm->len == 2) {
- printf("type-uuid 0x%2.2x\n", btohs(htons(get_u16(frm))));
+ printf("type-uuid 0x%4.4x\n", btohs(htons(get_u16(frm))));
} else if (frm->len == 16) {
printf("type-uuid ");
for (i = 0; i < 16; i++) {
@@ -435,6 +435,28 @@ static void att_read_blob_resp_dump(int level, struct frame *frm)
printf("\n");
}
+static void att_read_by_group_resp_dump(int level, struct frame *frm)
+{
+ uint8_t length = get_u8(frm);
+
+ while (frm->len > 0) {
+ uint16_t attr_handle = btohs(htons(get_u16(frm)));
+ uint16_t end_grp_handle = btohs(htons(get_u16(frm)));
+ uint8_t remaining = length - 4;
+
+ p_indent(level, frm);
+ printf("attr handle 0x%4.4x, end group handle 0x%4.4x\n",
+ attr_handle, end_grp_handle);
+
+ p_indent(level, frm);
+ printf("value");
+ while (remaining > 0) {
+ printf(" 0x%2.2x", get_u8(frm));
+ }
+ printf("\n");
+ }
+}
+
static void att_handle_notify_dump(int level, struct frame *frm)
{
uint16_t handle = btohs(htons(get_u16(frm)));
@@ -482,6 +504,7 @@ void att_dump(int level, struct frame *frm)
att_find_by_type_resp_dump(level + 1, frm);
break;
case ATT_OP_READ_BY_TYPE_REQ:
+ case ATT_OP_READ_BY_GROUP_REQ: /* exact same parsing */
att_read_by_type_req_dump(level + 1, frm);
break;
case ATT_OP_READ_BY_TYPE_RESP:
@@ -499,6 +522,9 @@ void att_dump(int level, struct frame *frm)
case ATT_OP_READ_BLOB_RESP:
att_read_blob_resp_dump(level + 1, frm);
break;
+ case ATT_OP_READ_BY_GROUP_RESP:
+ att_read_by_group_resp_dump(level + 1, frm);
+ break;
case ATT_OP_HANDLE_NOTIFY:
att_handle_notify_dump(level + 1, frm);
break;
--
1.7.1
^ permalink raw reply related
* [PATCH 4/4] Add parsing for Read Multiple
From: Andre Dieb Martins @ 2011-03-21 12:18 UTC (permalink / raw)
To: linux-bluetooth; +Cc: Andre Dieb Martins
In-Reply-To: <1300709914-2838-1-git-send-email-andre.dieb@signove.com>
---
parser/att.c | 28 ++++++++++++++++++++++++++++
1 files changed, 28 insertions(+), 0 deletions(-)
diff --git a/parser/att.c b/parser/att.c
index 124aaa7..329a0dc 100644
--- a/parser/att.c
+++ b/parser/att.c
@@ -435,6 +435,28 @@ static void att_read_blob_resp_dump(int level, struct frame *frm)
printf("\n");
}
+static void att_read_multi_req_dump(int level, struct frame *frm)
+{
+ p_indent(level, frm);
+ printf("Handles\n");
+
+ while (frm->len > 0) {
+ p_indent(level, frm);
+ printf("handle 0x%4.4x\n", btohs(htons(get_u16(frm))));
+ }
+}
+
+static void att_read_multi_resp_dump(int level, struct frame *frm)
+{
+ p_indent(level, frm);
+ printf("values");
+
+ while (frm->len > 0) {
+ printf(" 0x%2.2x", get_u8(frm));
+ }
+ printf("\n");
+}
+
static void att_read_by_group_resp_dump(int level, struct frame *frm)
{
uint8_t length = get_u8(frm);
@@ -522,6 +544,12 @@ void att_dump(int level, struct frame *frm)
case ATT_OP_READ_BLOB_RESP:
att_read_blob_resp_dump(level + 1, frm);
break;
+ case ATT_OP_READ_MULTI_REQ:
+ att_read_multi_req_dump(level + 1, frm);
+ break;
+ case ATT_OP_READ_MULTI_RESP:
+ att_read_multi_resp_dump(level + 1, frm);
+ break;
case ATT_OP_READ_BY_GROUP_RESP:
att_read_by_group_resp_dump(level + 1, frm);
break;
--
1.7.1
^ permalink raw reply related
* [PATCH] Fix crash when unregistering a2dp driver before media driver
From: Luiz Augusto von Dentz @ 2011-03-21 12:18 UTC (permalink / raw)
To: linux-bluetooth
From: Luiz Augusto von Dentz <luiz.dentz-von@nokia.com>
Since media driver uses a2dp to register its sep and store a pointer,
this pointer may be invalid/freed when media driver is unregistered.
To fix this now a2dp will also release any sep registered using media
API.
It also protect from future changes on the order of drivers removal by
checking if pointers (sep or endpoint) are still available in the list
before removing them.
---
audio/a2dp.c | 7 +++++++
audio/media.c | 3 +++
2 files changed, 10 insertions(+), 0 deletions(-)
diff --git a/audio/a2dp.c b/audio/a2dp.c
index ea4805c..8595350 100644
--- a/audio/a2dp.c
+++ b/audio/a2dp.c
@@ -1517,6 +1517,9 @@ proceed:
static void a2dp_unregister_sep(struct a2dp_sep *sep)
{
+ if (sep->endpoint)
+ media_endpoint_release(sep->endpoint);
+
avdtp_unregister_sep(sep->lsep);
g_free(sep);
}
@@ -1648,12 +1651,16 @@ void a2dp_remove_sep(struct a2dp_sep *sep)
struct a2dp_server *server = sep->server;
if (sep->type == AVDTP_SEP_TYPE_SOURCE) {
+ if (g_slist_find(server->sources, sep) == NULL)
+ return;
server->sources = g_slist_remove(server->sources, sep);
if (server->sources == NULL && server->source_record_id) {
remove_record_from_server(server->source_record_id);
server->source_record_id = 0;
}
} else {
+ if (g_slist_find(server->sinks, sep) == NULL)
+ return;
server->sinks = g_slist_remove(server->sinks, sep);
if (server->sinks == NULL && server->sink_record_id) {
remove_record_from_server(server->sink_record_id);
diff --git a/audio/media.c b/audio/media.c
index d5fb29c..4b389c6 100644
--- a/audio/media.c
+++ b/audio/media.c
@@ -108,6 +108,9 @@ static void media_endpoint_remove(struct media_endpoint *endpoint)
{
struct media_adapter *adapter = endpoint->adapter;
+ if (g_slist_find(adapter->endpoints, endpoint) == NULL)
+ return;
+
info("Endpoint unregistered: sender=%s path=%s", endpoint->sender,
endpoint->path);
--
1.7.1
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox