* [RFC PATCH v0 2/6] Bluetooth: Add helper function to get the uuid type
From: Syam Sidhardhan @ 2013-01-24 5:57 UTC (permalink / raw)
To: linux-bluetooth
In-Reply-To: <1359007079-11724-1-git-send-email-s.syam@samsung.com>
This function will return the particular uuid type
Signed-off-by: Syam Sidhardhan <s.syam@samsung.com>
Tested-by: Chan-yeol Park <chanyeol.park@samsung.com>
---
net/bluetooth/mgmt.c | 21 +++++++++++++++++++++
1 file changed, 21 insertions(+)
diff --git a/net/bluetooth/mgmt.c b/net/bluetooth/mgmt.c
index 4fd45a3..0f32986 100644
--- a/net/bluetooth/mgmt.c
+++ b/net/bluetooth/mgmt.c
@@ -37,6 +37,10 @@ bool enable_hs;
#define MGMT_VERSION 1
#define MGMT_REVISION 2
+#define EIR_TYPE_UUID16 1
+#define EIR_TYPE_UUID32 2
+#define EIR_TYPE_UUID128 3
+
static const u16 mgmt_commands[] = {
MGMT_OP_READ_INDEX_LIST,
MGMT_OP_READ_INFO,
@@ -440,6 +444,23 @@ static u8 bluetooth_base_uuid[] = {
0x00, 0x10, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
};
+static int get_uuid_type(u8 *uuid128)
+{
+ u32 val;
+ int i;
+
+ for (i = 0; i < 12; i++) {
+ if (bluetooth_base_uuid[i] != uuid128[i])
+ return EIR_TYPE_UUID128;
+ }
+
+ val = get_unaligned_le32(&uuid128[12]);
+ if (val > 0xffff)
+ return EIR_TYPE_UUID32;
+ else
+ return EIR_TYPE_UUID16;
+}
+
static u16 get_uuid16(u8 *uuid128)
{
u32 val;
--
1.7.9.5
^ permalink raw reply related
* [RFC PATCH v0 1/6] Bluetooth: Update the uuid list in reverse order
From: Syam Sidhardhan @ 2013-01-24 5:57 UTC (permalink / raw)
To: linux-bluetooth
In-Reply-To: <1359007079-11724-1-git-send-email-s.syam@samsung.com>
If we add uuid in the list head, then initially added uuid's might
get lost because of the possibility of Max limit 240 reaches before
reaching the end of the list parsing.
Signed-off-by: Syam Sidhardhan <s.syam@samsung.com>
Tested-by: Chan-yeol Park <chanyeol.park@samsung.com>
---
net/bluetooth/mgmt.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/bluetooth/mgmt.c b/net/bluetooth/mgmt.c
index e7f944f..4fd45a3 100644
--- a/net/bluetooth/mgmt.c
+++ b/net/bluetooth/mgmt.c
@@ -1330,7 +1330,7 @@ static int add_uuid(struct sock *sk, struct hci_dev *hdev, void *data, u16 len)
memcpy(uuid->uuid, cp->uuid, 16);
uuid->svc_hint = cp->svc_hint;
- list_add(&uuid->list, &hdev->uuids);
+ list_add_tail(&uuid->list, &hdev->uuids);
err = update_class(hdev);
if (err < 0)
--
1.7.9.5
^ permalink raw reply related
* [RFC PATCH v0 0/6] Addd support for EIR 32 bit and 128 bit UUID's in EIR
From: Syam Sidhardhan @ 2013-01-24 5:57 UTC (permalink / raw)
To: linux-bluetooth
This patch enhances the existing code and add support for the
EIR updation for UUID-32 & UUID-128.
Patch 1: changes the order of the parsing inorder to avoid uuid's getting
overwritten in extreem cases. Since we are reversing the order the
mgmt-tester testcase for "UUID-16 multiple 1" will fail. I'll send the
updated fix for the mgmt-tester with UUID128 testcase.
Since I do not have a setup to test these changes using mgmt-tester,
Chen-yeol Park has help me a lot and tested the changes locally and
it is reported working fine. Thanks Johan for the guidence.
Syam Sidhardhan (6):
Bluetooth: Update the uuid list in reverse order
Bluetooth: Add helper function to get the uuid type
Bluetooth: Add helper function to prepare the EIR packet from list
Bluetooth: Add EIR UUID-16 bit parsing for EIR
Bluetooth: Add support for UUID-32 bit parsing for EIR
Bluetooth: Add support for UUID-128 bit parsing for EIR
net/bluetooth/mgmt.c | 352 ++++++++++++++++++++++++++++++++++++++++++++------
1 file changed, 314 insertions(+), 38 deletions(-)
--
1.7.9.5
^ permalink raw reply
* Patch for AR3011 device
From: Isaac Lindgren @ 2013-01-24 3:56 UTC (permalink / raw)
To: Marcel Holtmann; +Cc: Gustavo Padovan, Johan Hedberg, linux-bluetooth
[-- Attachment #1: Type: text/plain, Size: 1563 bytes --]
I was experiencing the problem described on the ath3k Linux wireless page
regarding AR3011 with SFLASH. My device is:
Bus 001 Device 004: ID 04f2:aff1 Chicony Electronics Co., Ltd
To correct this I followed the instructions on the ath3k page and added my
VID/PID to ath3k.c and blacklisted it in btusb.c:
diff -uprN a/drivers/bluetooth/ath3k.c b/drivers/bluetooth/ath3k.c
--- a/drivers/bluetooth/ath3k.c 2013-01-23 20:45:24.946984407 -0600
+++ b/drivers/bluetooth/ath3k.c 2013-01-23 20:45:51.443693307 -0600
@@ -68,6 +68,7 @@ static struct usb_device_id ath3k_table[
{ USB_DEVICE(0x0930, 0x0215) },
{ USB_DEVICE(0x0489, 0xE03D) },
{ USB_DEVICE(0x0489, 0xE027) },
+ { USB_DEVICE(0x04f2, 0xaff1) },
/* Atheros AR9285 Malbec with sflash firmware */
{ USB_DEVICE(0x03F0, 0x311D) },
diff -uprN a/drivers/bluetooth/btusb.c b/drivers/bluetooth/btusb.c
--- a/drivers/bluetooth/btusb.c 2013-01-23 20:45:24.946984407 -0600
+++ b/drivers/bluetooth/btusb.c 2013-01-23 20:45:51.443693307 -0600
@@ -125,6 +125,7 @@ static struct usb_device_id blacklist_ta
{ USB_DEVICE(0x0930, 0x0215), .driver_info = BTUSB_IGNORE },
{ USB_DEVICE(0x0489, 0xe03d), .driver_info = BTUSB_IGNORE },
{ USB_DEVICE(0x0489, 0xe027), .driver_info = BTUSB_IGNORE },
+ { USB_DEVICE(0x04f2, 0xaff1), .driver_info = BTUSB_IGNORE },
/* Atheros AR9285 Malbec with sflash firmware */
{ USB_DEVICE(0x03f0, 0x311d), .driver_info = BTUSB_IGNORE },
My apologies if this is not the correct way to submit a patch.
[-- Attachment #2: Type: text/html, Size: 1861 bytes --]
^ permalink raw reply
* pull request: bluetooth-next 2013-01-24
From: Gustavo Padovan @ 2013-01-24 3:10 UTC (permalink / raw)
To: linville; +Cc: linux-wireless, linux-bluetooth, linux-kernel
[-- Attachment #1: Type: text/plain, Size: 3984 bytes --]
Hi John,
This is my first pull request to 3.9. The biggest changes here are from Johan
Hedberg who made a lot of fixes in the Management interface. The issues arose
due to a new test tool we wrote and the usage of the Management interface as
default in BlueZ 5. The rest of the patches are more clean ups and small
fixes.
Please pull! Thanks!
Gustavo
---
The following changes since commit e7f767a7d9f809c494bfffffeda2bbdbfec110b4:
mwifiex: use map/unmap APIs in TX and RX to reduce memcpy (2013-01-07 15:18:30 -0500)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/bluetooth/bluetooth-next for-upstream
for you to fetch changes up to 9b008c0457e583e10e62d1215bed6ab26ee54906:
Bluetooth: Add support for reading LE supported states (2013-01-23 02:09:16 -0200)
----------------------------------------------------------------
Andrei Emeltchenko (4):
Bluetooth: AMP: Send A2MP Create Phylink Rsp after Assoc write
Bluetooth: AMP: Clean up logical link create / accept
Bluetooth: AMP: Remove dead code
Bluetooth: AMP: Use set_bit / test_bit for amp_mgr state
Gustavo Padovan (1):
Bluetooth: Fix uuid output in debugfs
Johan Hedberg (25):
Bluetooth: Fix missing command complete event for mgmt_confirm_name
Bluetooth: Fix missing command complete for mgmt_load_long_term_keys
Bluetooth: Fix checking for valid device class values
Bluetooth: Fix accepting set_dev_class for non-BR/EDR controllers
Bluetooth: Move non-critical sections outside of the dev lock
Bluetooth: Fix checking for exact values of boolean mgmt parameters
Bluetooth: Fix returning proper command status for start_discovery
Bluetooth: Fix sending incorrect new_settings for mgmt_set_powered
Bluetooth: Add a new workqueue for hci_request operations
Bluetooth: Use req_workqueue for hci_request operations
Bluetooth: Fix using system-global workqueue when not necessary
Bluetooth: Fix Class of Device indication when powering off
Bluetooth: Fix checking for correct mgmt_load_link_keys parameters
Bluetooth: Fix returning proper mgmt status for Load LTKs
Bluetooth: Fix checking for proper key->master value in Load LTKs
Bluetooth: Refactor valid LTK data testing into its own function
Bluetooth: Check for valid key->authenticated value for LTKs
Bluetooth: Add helper functions for testing bdaddr types
Bluetooth: Fix checking for valid address type values in mgmt commands
Bluetooth: Fix checking for valid disconnect parameters in unpair_device
Bluetooth: Fix returning proper cmd_complete for mgmt_disconnect
Bluetooth: Fix returning proper cmd_complete for mgmt_block/unblock
Bluetooth: Add LE Local Features reading support
Bluetooth: Add support for reading LE White List Size
Bluetooth: Add support for reading LE supported states
Rami Rosen (2):
Bluetooth: Remove unnecessary include l2cap.h
Bluetooth: remove an unused variable in a header file
Szymon Janc (3):
Bluetooth: mgmt: Remove not needed restriction on add/remove OOB data
Bluetooth: mgmt: Avoid using magic number in status code
Bluetooth: Fix pair device command reply if adapter is powered off
include/net/bluetooth/a2mp.h | 4 +-
include/net/bluetooth/bluetooth.h | 23 ++++
include/net/bluetooth/hci.h | 18 +++
include/net/bluetooth/hci_core.h | 4 +
include/net/bluetooth/l2cap.h | 1 -
net/bluetooth/a2mp.c | 42 ++++++-
net/bluetooth/amp.c | 25 ++--
net/bluetooth/bnep/core.c | 1 -
net/bluetooth/hci_core.c | 20 ++-
net/bluetooth/hci_event.c | 60 +++++++++
net/bluetooth/hci_sysfs.c | 22 ++--
net/bluetooth/l2cap_core.c | 5 -
net/bluetooth/mgmt.c | 270 ++++++++++++++++++++++++++++------------
13 files changed, 375 insertions(+), 120 deletions(-)
[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: [PATCH] Bluetooth: Fix Class of Device indication when powering off
From: Gustavo Padovan @ 2013-01-23 4:20 UTC (permalink / raw)
To: Johan Hedberg; +Cc: linux-bluetooth
In-Reply-To: <1358345734-17892-1-git-send-email-johan.hedberg@gmail.com>
Hi Johan,
* Johan Hedberg <johan.hedberg@gmail.com> [2013-01-16 16:15:34 +0200]:
> From: Johan Hedberg <johan.hedberg@intel.com>
>
> When a HCI device is powered off the Management interface specification
> dictates that the class of device value is indicated as zero. This patch
> fixes sending of the appropriate class of device changed event when a
> HCI device is powered off.
>
> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
> ---
> net/bluetooth/mgmt.c | 6 ++++++
> 1 file changed, 6 insertions(+)
Patch has been applied to bluetooth-next. Thanks.
Gustavo
^ permalink raw reply
* Re: [PATCH 3/3] Bluetooth: Add support for reading LE supported states
From: Gustavo Padovan @ 2013-01-23 4:12 UTC (permalink / raw)
To: Johan Hedberg; +Cc: linux-bluetooth
In-Reply-To: <1358856121-1928-3-git-send-email-johan.hedberg@gmail.com>
Hi Johan,
* Johan Hedberg <johan.hedberg@gmail.com> [2013-01-22 14:02:01 +0200]:
> From: Johan Hedberg <johan.hedberg@intel.com>
>
> The LE supported states indicate the states and state combinations that
> the link layer supports. This is important information for knowing what
> operations are possible when dealing with multiple connected devices.
> This patch adds reading of the supported states to the HCI init
> sequence.
>
> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
> ---
> include/net/bluetooth/hci.h | 6 ++++++
> include/net/bluetooth/hci_core.h | 1 +
> net/bluetooth/hci_event.c | 20 ++++++++++++++++++++
> 3 files changed, 27 insertions(+)
All 3 patches have been applied. Thanks.
Gustavo
^ permalink raw reply
* Re: [PATCH 10/10 v2] Bluetooth: Fix returning proper cmd_complete for mgmt_block/unblock
From: Gustavo Padovan @ 2013-01-23 4:07 UTC (permalink / raw)
To: Johan Hedberg; +Cc: linux-bluetooth
In-Reply-To: <1358684842-4441-11-git-send-email-johan.hedberg@gmail.com>
Hi Johan,
* Johan Hedberg <johan.hedberg@gmail.com> [2013-01-20 14:27:22 +0200]:
> From: Johan Hedberg <johan.hedberg@intel.com>
>
> The Block/Unblock Device Management commands should return Command
> Complete instead of Command Status whenever possible so that user space
> can distinguish exactly which command failed in the case of multiple
> commands. This patch does the necessary changes in the command handler
> to return the right event to user space.
>
> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
> ---
> net/bluetooth/mgmt.c | 10 ++++++----
> 1 file changed, 6 insertions(+), 4 deletions(-)
All 10 patches have been applied to bluetooth-next. Thanks.
Gustavo
^ permalink raw reply
* Re: [PATCH] Bluetooth: Fix pair device command reply if adapter is powered off
From: Gustavo Padovan @ 2013-01-23 3:45 UTC (permalink / raw)
To: Szymon Janc; +Cc: linux-bluetooth
In-Reply-To: <1358509687-7194-1-git-send-email-szymon.janc@tieto.com>
Hi Szymon,
* Szymon Janc <szymon.janc@tieto.com> [2013-01-18 12:48:07 +0100]:
> According to Bluetooth Management API specification Pair Device Command
> should generate command complete event on both success and failure.
> This fix replying with command status (which lacks address info) when
> adapter is powered off.
>
> Signed-off-by: Szymon Janc <szymon.janc@tieto.com>
> ---
> net/bluetooth/mgmt.c | 12 ++++++------
> 1 file changed, 6 insertions(+), 6 deletions(-)
Patch has been applied to bluetooth-next. Thanks.
Gustavo
^ permalink raw reply
* Re: Thoughts about LE scanning
From: Andre Guedes @ 2013-01-23 1:12 UTC (permalink / raw)
To: Marcel Holtmann; +Cc: linux-bluetooth
In-Reply-To: <1358460154.2089.14.camel@aeonflux>
Hi Marcel,
On Thu, Jan 17, 2013 at 7:02 PM, Marcel Holtmann <marcel@holtmann.org> wrote:
> Hello,
>
> so I have been looking into how we handle LE scanning in central role a
> little bit. And I am not really happy with what we do right now. Instead
> of just adding new profiles, we need to take one step back and get the
> basics right.
>
> The one thing that I stumbled about is that we are trying to use the
> Start Discovery management command to scan for connectable device that
> we are paired with. And it is all triggered by bluetoothd. It tries to
> get this done right, but fails badly at it. Trying to do this ends up in
> a convoluted solution that will just break down eventually.
>
> So Start Discovery and Stop Discovery management commands are for
> finding new devices. They are for finding devices that we want to pair
> with. They are not for checking if a paired device is in range or
> signals connection requests to us. It is called discovery for a reason.
>
> It might have looked like a good idea to just re-use these two commands,
> but what I am seeing when working with multiple paired LE devices is
> just a big mess. The amount of code that is needed to keep track of
> states between running D-Bus commands for discovery, discovery triggered
> management commands, scanning triggered management commands etc. is not
> a good idea.
>
> I am failing to understand why we tried to solve this inside bluetoothd
> and not just let the kernel take full control here. We are loading the
> list of paired LE devices at controller power on anyway. So the kernel
> does know about our paired devices. It can control sensible scan
> intervals and also sync a device discovery with scanning for connection
> triggers from know remote devices. It also can sensible disconnect on
> idle and scan for other devices that requests connections.
We are working on moving this connection management into kernel space
and we should start sending RFCs soon.
> What I think we should have is a management command that allows us to
> load device specific scan parameter configuration into the kernel. And
> then the kernel will execute this on our behalf. We need to decouple the
> commands for device discovery from the commands that scan for known
> devices.
Once we have the connection management working properly we can working
on this new management command to setup the scan parameters.
Regards,
Andre
^ permalink raw reply
* Re: [PATCH BlueZ 2/2] avctp: Receive and silent ignore Vol Up/Down operations
From: Joao Paulo Rechi Vita @ 2013-01-22 19:09 UTC (permalink / raw)
To: Vinicius Costa Gomes
Cc: linux-bluetooth@vger.kernel.org, Luiz Augusto von Dentz
In-Reply-To: <20130122185650.GA1119@samus>
On Tue, Jan 22, 2013 at 3:56 PM, Vinicius Costa Gomes
<vinicius.gomes@openbossa.org> wrote:
> Hi Joao,
>
> On 15:18 Tue 22 Jan, João Paulo Rechi Vita wrote:
>> The AVRCP spec mandates to support 'volume up' and 'volume down'
>> operations when claiming support for Category 2 TG.
>> ---
>> profiles/audio/avctp.c | 5 +++++
>> 1 file changed, 5 insertions(+)
>>
>> diff --git a/profiles/audio/avctp.c b/profiles/audio/avctp.c
>> index f7e607e..4ab6d6d 100644
>> --- a/profiles/audio/avctp.c
>> +++ b/profiles/audio/avctp.c
>> @@ -214,6 +214,8 @@ static struct {
>> uint8_t avc;
>> uint16_t uinput;
>> } key_map[] = {
>> + { "VOLUME UP", AVC_VOLUME_UP, KEY_VOLUMEUP},
>> + { "VOLUME DOWN", AVC_VOLUME_DOWN, KEY_VOLUMEDOWN},
>> { "PLAY", AVC_PLAY, KEY_PLAYCD },
>> { "STOP", AVC_STOP, KEY_STOPCD },
>> { "PAUSE", AVC_PAUSE, KEY_PAUSECD },
>> @@ -968,6 +970,9 @@ static void init_uinput(struct avctp *session)
>>
>> dev = manager_get_audio_device(session->device, FALSE);
>>
>> + session->key_quirks[AVC_VOLUME_UP] |= QUIRK_IGNORE;
>> + session->key_quirks[AVC_VOLUME_DOWN] |= QUIRK_IGNORE;
>> +
>
> Having a quirk that applies to every device, doesn't seem to map to the
> meaning of 'quirk', i.e. if everybody has the same quirk, it is the norm ;-)
>
It is not a _device quirk_ but it is still a _key quirk_, that is, a
special behavior to handle that key. I could also have checked
specifically for the key id, but I find clearer to do it this way.
--
João Paulo Rechi Vita
Openbossa Labs - INdT
^ permalink raw reply
* Re: [PATCH BlueZ 2/2] avctp: Receive and silent ignore Vol Up/Down operations
From: Vinicius Costa Gomes @ 2013-01-22 18:56 UTC (permalink / raw)
To: João Paulo Rechi Vita; +Cc: linux-bluetooth, luiz.dentz
In-Reply-To: <1358878703-8100-3-git-send-email-jprvita@openbossa.org>
Hi Joao,
On 15:18 Tue 22 Jan, João Paulo Rechi Vita wrote:
> The AVRCP spec mandates to support 'volume up' and 'volume down'
> operations when claiming support for Category 2 TG.
> ---
> profiles/audio/avctp.c | 5 +++++
> 1 file changed, 5 insertions(+)
>
> diff --git a/profiles/audio/avctp.c b/profiles/audio/avctp.c
> index f7e607e..4ab6d6d 100644
> --- a/profiles/audio/avctp.c
> +++ b/profiles/audio/avctp.c
> @@ -214,6 +214,8 @@ static struct {
> uint8_t avc;
> uint16_t uinput;
> } key_map[] = {
> + { "VOLUME UP", AVC_VOLUME_UP, KEY_VOLUMEUP},
> + { "VOLUME DOWN", AVC_VOLUME_DOWN, KEY_VOLUMEDOWN},
> { "PLAY", AVC_PLAY, KEY_PLAYCD },
> { "STOP", AVC_STOP, KEY_STOPCD },
> { "PAUSE", AVC_PAUSE, KEY_PAUSECD },
> @@ -968,6 +970,9 @@ static void init_uinput(struct avctp *session)
>
> dev = manager_get_audio_device(session->device, FALSE);
>
> + session->key_quirks[AVC_VOLUME_UP] |= QUIRK_IGNORE;
> + session->key_quirks[AVC_VOLUME_DOWN] |= QUIRK_IGNORE;
> +
Having a quirk that applies to every device, doesn't seem to map to the
meaning of 'quirk', i.e. if everybody has the same quirk, it is the norm ;-)
Cheers,
--
Vinicius
^ permalink raw reply
* [PATCH BlueZ 2/2] avctp: Receive and silent ignore Vol Up/Down operations
From: João Paulo Rechi Vita @ 2013-01-22 18:18 UTC (permalink / raw)
To: linux-bluetooth; +Cc: luiz.dentz, João Paulo Rechi Vita
In-Reply-To: <1358878703-8100-1-git-send-email-jprvita@openbossa.org>
The AVRCP spec mandates to support 'volume up' and 'volume down'
operations when claiming support for Category 2 TG.
---
profiles/audio/avctp.c | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/profiles/audio/avctp.c b/profiles/audio/avctp.c
index f7e607e..4ab6d6d 100644
--- a/profiles/audio/avctp.c
+++ b/profiles/audio/avctp.c
@@ -214,6 +214,8 @@ static struct {
uint8_t avc;
uint16_t uinput;
} key_map[] = {
+ { "VOLUME UP", AVC_VOLUME_UP, KEY_VOLUMEUP},
+ { "VOLUME DOWN", AVC_VOLUME_DOWN, KEY_VOLUMEDOWN},
{ "PLAY", AVC_PLAY, KEY_PLAYCD },
{ "STOP", AVC_STOP, KEY_STOPCD },
{ "PAUSE", AVC_PAUSE, KEY_PAUSECD },
@@ -968,6 +970,9 @@ static void init_uinput(struct avctp *session)
dev = manager_get_audio_device(session->device, FALSE);
+ session->key_quirks[AVC_VOLUME_UP] |= QUIRK_IGNORE;
+ session->key_quirks[AVC_VOLUME_DOWN] |= QUIRK_IGNORE;
+
device_get_name(dev->btd_dev, name, sizeof(name));
if (g_str_equal(name, "Nokia CK-20W")) {
session->key_quirks[AVC_FORWARD] |= QUIRK_NO_RELEASE;
--
1.7.11.7
^ permalink raw reply related
* [PATCH BlueZ 1/2] avctp: Create ignore quirk
From: João Paulo Rechi Vita @ 2013-01-22 18:18 UTC (permalink / raw)
To: linux-bluetooth; +Cc: luiz.dentz, João Paulo Rechi Vita
In-Reply-To: <1358878703-8100-1-git-send-email-jprvita@openbossa.org>
Create a quirk to be able to accept and trow away certain keys.
---
profiles/audio/avctp.c | 8 +++++++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/profiles/audio/avctp.c b/profiles/audio/avctp.c
index 61890cc..f7e607e 100644
--- a/profiles/audio/avctp.c
+++ b/profiles/audio/avctp.c
@@ -58,7 +58,8 @@
#include "avctp.h"
#include "avrcp.h"
-#define QUIRK_NO_RELEASE 1 << 0
+#define QUIRK_NO_RELEASE 1 << 0
+#define QUIRK_IGNORE 1 << 1
/* Message types */
#define AVCTP_COMMAND 0
@@ -287,6 +288,11 @@ static size_t handle_panel_passthrough(struct avctp *session,
key_quirks = session->key_quirks[key_map[i].avc];
+ if (key_quirks & QUIRK_IGNORE) {
+ DBG("AV/C: ignoring %s %s", key_map[i].name, status);
+ break;
+ }
+
if (key_quirks & QUIRK_NO_RELEASE) {
if (!pressed) {
DBG("AV/C: Ignoring release");
--
1.7.11.7
^ permalink raw reply related
* [PATCH BlueZ 0/2] AVRCP: Add support for Vol Up/Down operations on TG
From: João Paulo Rechi Vita @ 2013-01-22 18:18 UTC (permalink / raw)
To: linux-bluetooth; +Cc: luiz.dentz, João Paulo Rechi Vita
This series creates a new quirk called QUIRK_IGNORE to be able to accept and
ignore certain keys. Then it uses this infrastructure to accept and ignore
Volume Up/Down operations, instead of replying with "Not Implemented".
Suport for Volume Up/Down is mandatory on TG side if we claim to support
Category 2 (Monitor / Amplifier). It's also tested by PTS on test
TC_TG_PTT_BV_02_I.
João Paulo Rechi Vita (2):
avctp: Create ignore quirk
avctp: Receive and silent ignore Vol Up/Down operations
profiles/audio/avctp.c | 13 ++++++++++++-
1 file changed, 12 insertions(+), 1 deletion(-)
--
1.7.11.7
^ permalink raw reply
* Re: [RFC] Bluetooth: Fix missing MITM protection when being responding LM
From: Timo Müller @ 2013-01-22 17:36 UTC (permalink / raw)
To: Marcel Holtmann; +Cc: Johan Hedberg, linux-bluetooth, Timo Mueller
In-Reply-To: <1358851002.7365.11.camel@aeonflux>
Hi Johan, Hi Marcel,
Marcel Holtmann wrote, On 22.01.2013 11:36:
> Hi Johan,
>
>>> A MITM protected SSP associaton model can be used for pairing if both
>>> local and remote IO capabilities are set to something other than
>>> NoInputNoOutput.
>>>
>>> With these IO capabilities a MITM protected SSP association model is
>>> used if we are initiating the pairing process (initiating LM).
>>>
>>> When responding to a pairing request - remote device is the initiating
>>> LM - the pairing should also be proteced against MITM attacks.
>>>
>>> Signed-off-by: Timo Mueller <timo.mueller@bmw-carit.de>
>>> ---
>>> When we were testing the iPhone 5 we noticed that the association
>>> model changes depending on which side initiates the pairing. For
>>> example if we paired from the phone "Just Works" was used while if the
>>> phone was the responding LM a "Numeric Comparison" was used instead.
>>>
>>> We'd like to enforce MITM protection in our cars whenever possible.
>>> That is why we want to set the MITM protection even when being the
>>> responding LM. The patch proposes this policy as the default approach.
>>>
>>> Expected SSP accociation model:
>>> |-------------------------------------------|
>>> | Device | SSP assocation model |
>>> |===========================================|
>>> | KeyboardDisplay | Numeric Comparison |
>>> | ------------------------------------------|
>>> | NoInputNoOutput | Just Works |
>>> | ------------------------------------------|
>>> | KeyboardOnly | Passkey Entry |
>>> |-------------------------------------------|
>>>
>>> Tested Devices:
>>> KeyboardDisplay:
>>> iPhone 4 (iOS4), iPhone 5 (iOS6), Nokia N9, HTC One S,
>>> Samsung Galaxy (CM 10.1), Nexus 4, Nokia 6313 Classic,
>>> BlueZ 5 - Simple Agent
>>>
>>> NoInputNoOutput:
>>> BlueZ 5 - Simple Agent
>>>
>>> KeyboardOnly:
>>> Logitech Keyboard Case, BlueZ 5 - Simple Agent
>>>
>>> I've also tested this patch with the following kernels:
>>> 3.8-rc4
>>> 3.4
>>>
>>> Best regards,
>>> Timo
>>>
>>> net/bluetooth/hci_conn.c | 6 +++++-
>>> 1 file changed, 5 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/net/bluetooth/hci_conn.c b/net/bluetooth/hci_conn.c
>>> index 25bfce0..806583b 100644
>>> --- a/net/bluetooth/hci_conn.c
>>> +++ b/net/bluetooth/hci_conn.c
>>> @@ -357,11 +357,15 @@ struct hci_conn *hci_conn_add(struct hci_dev *hdev, int type, bdaddr_t *dst)
>>> conn->type = type;
>>> conn->mode = HCI_CM_ACTIVE;
>>> conn->state = BT_OPEN;
>>> - conn->auth_type = HCI_AT_GENERAL_BONDING;
>>> conn->io_capability = hdev->io_capability;
>>> conn->remote_auth = 0xff;
>>> conn->key_type = 0xff;
>>>
>>> + if (hdev->io_capability == 0x03)
>>> + conn->auth_type = HCI_AT_GENERAL_BONDING;
>>> + else
>>> + conn->auth_type = HCI_AT_GENERAL_BONDING_MITM;
>>> +
>>> set_bit(HCI_CONN_POWER_SAVE, &conn->flags);
>>> conn->disc_timeout = HCI_DISCONN_TIMEOUT;
>>
>> The question that could equally be asked is why does iOS *not* set the
>> MITM flag when initiating pairing to a remote device. If it did this
>> issue would not exist.
>
> because iOS does not support SIM Access Profile. Outside of SIM Access,
> there is really no need to support high security.
>
> The difference between medium security and high security is really only
> the man-in-the-middle protection. From an encryption and link key
> strength point of view they are identical. Both link keys are P-192
> derived and the encryption cipher is still E0.
>
>> Since the over all sequence of the IO capability negotiation with iOS devices
>> when we're on the acceptor side might be a bit unclear to people by just
>> reading your commit message and patch I'll provide here a HCI trace of it:
>>
>> > HCI Event: IO Capability Response (0x32) plen 9
>> Address: 04:F7:E4:xx:xx:xx (OUI 04-F7-E4)
>> IO capability: DisplayYesNo (0x01)
>> OOB data: Authentication data not present (0x00)
>> Authentication: General Bonding - MITM not required (0x04)
>> > HCI Event: IO Capability Request (0x31) plen 6
>> Address: 04:F7:E4:xx:xx:xx (OUI 04-F7-E4)
>> < HCI Command: IO Capability Request Reply (0x01|0x002b) plen 9
>> Address: 04:F7:E4:xx:xx:xx (OUI 04-F7-E4)
>> IO capability: DisplayYesNo (0x01)
>> OOB data: Authentication data not present (0x00)
>> Authentication: General Bonding - MITM not required (0x04)
>>
>> Basically the BlueZ side has so far given the remote initiator the
>> choice whether to do just-works or not. However, I do agree that it's
>> good to strive for a best-possible security in the pairing (within the
>> limits of the available IO capabilities) so setting the MITM flag on our
>> side should be fine.
>
> This is still something we need to think about carefully. I am not sure
> we should just always be doing this. This might actually be better
> solved with a sysfs option or a mgmt command to pick different behavior.
>
> Since this is General Bonding and not Dedicated Bonding, I am not
> convinced that this is a good idea.
>
The BT spec says for both bonding types "parameter *should* (meaning
it's recommended to) be set to MITM Protection Not Required" if
initiator and responder support SSP. For dedicated bonding BlueZ is
already requiring MITM anyway (if possible). I think it would be good to
follow this approach also with general bonding.
Influencing the behaviour for general bonding with a mgmt command could
be an alternative. I will try to add this and send the proposal to the
mailing list.
>> The one thing that I'd still consider improving is to make the setting
>> of the MITM flag also dependent on the remote IO capability and not just
>> the local one, since we do know the remote one before we need to give
>> our own value when we are on the acceptor side of the pairing. Thoughts?
>
> This is a minimum requirement that we check the remote IO capabilities
> here. Since there is no point in trying MITM protection if the other
> side has no capabilities to ever create such a key.
So instead of setting the default association model according to the
local IO capabilities, the hci_get_auth_req method could be modified.
For general bonding the method would figure out the MITM requirement
analogous to the if-block for dedicated bonding. (With the mgmt command,
this would only be done when MITM is required.)
>
> I would be also curious if we still can qualify our own behavior and not
> end up with cases where we can't because we have no way to trigger it.
>
> Regards
>
> Marcel
Best regards,
Timo
^ permalink raw reply
* Re: [PATCH BlueZ] avrcp: Ignore MSB of Absolute Volume parameter
From: Luiz Augusto von Dentz @ 2013-01-22 16:03 UTC (permalink / raw)
To: João Paulo Rechi Vita; +Cc: linux-bluetooth@vger.kernel.org
In-Reply-To: <1358537120-7955-1-git-send-email-jprvita@openbossa.org>
Hi Joao,
On Fri, Jan 18, 2013 at 9:25 PM, João Paulo Rechi Vita
<jprvita@openbossa.org> wrote:
> According to the Section 6.13.1 of the AVRCP 1.5 specification document,
> the most significant bit of the Absolute Volume parameter is reserved
> for future additions, so it should be ignored when parsing parameters of
> the SetAbsoluteVolume command. This is also necessary to pass PTS test
> TC_TG_VLH_BI_02_C.
> ---
> profiles/audio/avrcp.c | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/profiles/audio/avrcp.c b/profiles/audio/avrcp.c
> index 636d3e4..237f176 100644
> --- a/profiles/audio/avrcp.c
> +++ b/profiles/audio/avrcp.c
> @@ -1398,11 +1398,13 @@ static uint8_t avrcp_handle_set_absolute_volume(struct avrcp *session,
> {
> struct avrcp_player *player = session->player;
> uint16_t len = ntohs(pdu->params_len);
> + uint8_t volume;
>
> if (len != 1)
> goto err;
>
> - if (pdu->params[0] > 127)
> + volume = pdu->params[0] & 0x7F;
> + if (volume > 127)
> goto err;
>
> if (!player)
> --
> 1.7.11.7
Patch applied, thanks.
--
Luiz Augusto von Dentz
^ permalink raw reply
* Re: [PATCH] avctp: Add functionality for CT browsing commands
From: Luiz Augusto von Dentz @ 2013-01-22 16:02 UTC (permalink / raw)
To: Alexandros Antonopoulos; +Cc: linux-bluetooth@vger.kernel.org
In-Reply-To: <1358850763-19532-1-git-send-email-alexandros.antonopoulos@oss.bmw-carit.de>
Hi Alexandros,
On Tue, Jan 22, 2013 at 12:32 PM, Alexandros Antonopoulos
<alexandros.antonopoulos@oss.bmw-carit.de> wrote:
> Add the missing functionality for full support of browsing channel
> on the CT side. This is required for AVRCP >= 1.4
> The patch is based on the control channel functionality
>
> ---
> profiles/audio/avctp.c | 140 +++++++++++++++++++++++++++++++++++++++++++++++++
> profiles/audio/avctp.h | 6 +++
> 2 files changed, 146 insertions(+)
>
> diff --git a/profiles/audio/avctp.c b/profiles/audio/avctp.c
> index e65594d..02bee2b 100644
> --- a/profiles/audio/avctp.c
> +++ b/profiles/audio/avctp.c
> @@ -136,6 +136,14 @@ struct avctp_control_req {
> void *user_data;
> };
>
> +struct avctp_browsing_req {
> + struct avctp_pending_req *p;
> + uint8_t *operands;
> + uint16_t operand_count;
> + avctp_browsing_rsp_cb func;
> + void *user_data;
> +};
> +
> typedef int (*avctp_process_cb) (void *data);
>
> struct avctp_pending_req {
> @@ -527,6 +535,44 @@ static int avctp_send(struct avctp_channel *control, uint8_t transaction,
> return err;
> }
>
> +static int avctp_browsing_send(struct avctp_channel *browsing,
> + uint8_t transaction, uint8_t cr,
> + uint8_t *operands, size_t operand_count)
> +{
> + struct avctp_header *avctp;
> + struct msghdr msg;
> + struct iovec iov[2];
> + int sk, err = 0;
> +
> + iov[0].iov_base = browsing->buffer;
> + iov[0].iov_len = sizeof(*avctp);
> + iov[1].iov_base = operands;
> + iov[1].iov_len = operand_count;
> +
> + if (browsing->omtu < (iov[0].iov_len + iov[1].iov_len))
> + return -EOVERFLOW;
> +
> + sk = g_io_channel_unix_get_fd(browsing->io);
> +
> + memset(browsing->buffer, 0, iov[0].iov_len);
> +
> + avctp = (void *) browsing->buffer;
> +
> + avctp->transaction = transaction;
> + avctp->packet_type = AVCTP_PACKET_SINGLE;
> + avctp->cr = cr;
> + avctp->pid = htons(AV_REMOTE_SVCLASS_ID);
> +
> + memset(&msg, 0, sizeof(msg));
> + msg.msg_iov = iov;
> + msg.msg_iovlen = 2;
> +
> + if (sendmsg(sk, &msg, 0) < 0)
> + err = -errno;
> +
> + return err;
> +}
> +
> static void control_req_destroy(void *data)
> {
> struct avctp_control_req *req = data;
> @@ -535,6 +581,14 @@ static void control_req_destroy(void *data)
> g_free(req);
> }
>
> +static void browsing_req_destroy(void *data)
> +{
> + struct avctp_browsing_req *req = data;
> +
> + g_free(req->operands);
> + g_free(req);
> +}
> +
> static gboolean req_timeout(gpointer user_data)
> {
> struct avctp_channel *chan = user_data;
> @@ -563,6 +617,15 @@ static int process_control(void *data)
> req->operands, req->operand_count);
> }
>
> +static int process_browsing(void *data)
> +{
> + struct avctp_browsing_req *req = data;
> + struct avctp_pending_req *p = req->p;
> +
> + return avctp_browsing_send(p->chan, p->transaction, AVCTP_COMMAND,
> + req->operands, req->operand_count);
> +}
> +
> static gboolean process_queue(void *user_data)
> {
> struct avctp_channel *chan = user_data;
> @@ -636,6 +699,48 @@ static void control_response(struct avctp_channel *control,
> }
> }
>
> +static void browsing_response(struct avctp_channel *browsing,
> + struct avctp_header *avctp,
> + uint8_t *operands,
> + size_t operand_count)
> +{
> + struct avctp_pending_req *p = browsing->p;
> + struct avctp_browsing_req *req;
> + GSList *l;
> +
> + if (p && p->transaction == avctp->transaction) {
> + browsing->processed = g_slist_prepend(browsing->processed, p);
> +
> + if (p->timeout > 0) {
> + g_source_remove(p->timeout);
> + p->timeout = 0;
> + }
> +
> + browsing->p = NULL;
> +
> + if (browsing->process_id == 0)
> + browsing->process_id = g_idle_add(process_queue,
> + browsing);
> + }
> +
> + for (l = browsing->processed; l; l = l->next) {
> + p = l->data;
> + req = p->data;
> +
> + if (p->transaction != avctp->transaction)
> + continue;
> +
> + if (req->func && req->func(browsing->session,
> + operands, operand_count,
> + req->user_data))
> + return;
> +
> + browsing->processed = g_slist_remove(browsing->processed, p);
> +
> + return;
> + }
> +}
> +
> static gboolean session_browsing_cb(GIOChannel *chan, GIOCondition cond,
> gpointer data)
> {
> @@ -665,6 +770,11 @@ static gboolean session_browsing_cb(GIOChannel *chan, GIOCondition cond,
> ret -= AVCTP_HEADER_LENGTH;
> operand_count = ret;
>
> + if (avctp->cr == AVCTP_RESPONSE) {
> + browsing_response(browsing, avctp, operands, operand_count);
> + return TRUE;
> + }
> +
> packet_size = AVCTP_HEADER_LENGTH;
> avctp->cr = AVCTP_RESPONSE;
>
> @@ -1294,6 +1404,36 @@ static int avctp_send_req(struct avctp *session, uint8_t code,
> return 0;
> }
>
> +int avctp_send_browsing_req(struct avctp *session,
> + uint8_t *operands, size_t operand_count,
> + avctp_browsing_rsp_cb func, void *user_data)
> +{
> + struct avctp_channel *browsing = session->browsing;
> + struct avctp_pending_req *p;
> + struct avctp_browsing_req *req;
> +
> + if (browsing == NULL)
> + return -ENOTCONN;
> +
> + req = g_new0(struct avctp_browsing_req, 1);
> + req->func = func;
> + req->operands = g_memdup(operands, operand_count);
> + req->operand_count = operand_count;
> + req->user_data = user_data;
> +
> + p = pending_create(browsing, process_browsing, req,
> + browsing_req_destroy);
> +
> + req->p = p;
> +
> + g_queue_push_tail(browsing->queue, p);
> +
> + if (browsing->process_id == 0)
> + browsing->process_id = g_idle_add(process_queue, browsing);
> +
> + return 0;
> +}
> +
> static char *op2str(uint8_t op)
> {
> switch (op & 0x7f) {
> diff --git a/profiles/audio/avctp.h b/profiles/audio/avctp.h
> index c25a3b3..b9107bd 100644
> --- a/profiles/audio/avctp.h
> +++ b/profiles/audio/avctp.h
> @@ -82,6 +82,9 @@ typedef size_t (*avctp_control_pdu_cb) (struct avctp *session,
> typedef gboolean (*avctp_rsp_cb) (struct avctp *session, uint8_t code,
> uint8_t subunit, uint8_t *operands,
> size_t operand_count, void *user_data);
> +typedef gboolean (*avctp_browsing_rsp_cb) (struct avctp *session,
> + uint8_t *operands, size_t operand_count,
> + void *user_data);
> typedef size_t (*avctp_browsing_pdu_cb) (struct avctp *session,
> uint8_t transaction,
> uint8_t *operands, size_t operand_count,
> @@ -116,3 +119,6 @@ int avctp_send_vendordep_req(struct avctp *session, uint8_t code,
> uint8_t subunit, uint8_t *operands,
> size_t operand_count,
> avctp_rsp_cb func, void *user_data);
> +int avctp_send_browsing_req(struct avctp *session,
> + uint8_t *operands, size_t operand_count,
> + avctp_browsing_rsp_cb func, void *user_data);
> --
> 1.8.1
Patch applied, thanks.
--
Luiz Augusto von Dentz
^ permalink raw reply
* Re: [RFC 1/1] avctp: Set browsing channel connection for ct
From: Luiz Augusto von Dentz @ 2013-01-22 16:01 UTC (permalink / raw)
To: Alexandros Antonopoulos; +Cc: linux-bluetooth@vger.kernel.org
In-Reply-To: <1358850844-19752-2-git-send-email-alexandros.antonopoulos@oss.bmw-carit.de>
Hi Alexandros,
On Tue, Jan 22, 2013 at 12:34 PM, Alexandros Antonopoulos
<alexandros.antonopoulos@oss.bmw-carit.de> wrote:
> Add two extra states for the browsing channel and handle the connection
> sequence in avrcp.c
>
> ---
> profiles/audio/avctp.c | 11 +++++++++++
> profiles/audio/avctp.h | 4 +++-
> profiles/audio/avrcp.c | 28 +++++++++++++++++++++++-----
> profiles/audio/device.c | 4 ++++
> 4 files changed, 41 insertions(+), 6 deletions(-)
>
> diff --git a/profiles/audio/avctp.c b/profiles/audio/avctp.c
> index e65594d..753f8fe 100644
> --- a/profiles/audio/avctp.c
> +++ b/profiles/audio/avctp.c
> @@ -476,6 +476,12 @@ static void avctp_set_state(struct avctp *session, avctp_state_t new_state)
> case AVCTP_STATE_CONNECTED:
> DBG("AVCTP Connected");
> break;
> + case AVCTP_STATE_BROWSING_CONNECTING:
> + DBG("AVCTP Browsing Connecting");
> + break;
> + case AVCTP_STATE_BROWSING_CONNECTED:
> + DBG("AVCTP Browsing Connected");
> + break;
> default:
> error("Invalid AVCTP state %d", new_state);
> return;
> @@ -913,9 +919,12 @@ static void avctp_connect_browsing_cb(GIOChannel *chan, GError *err,
> G_IO_IN | G_IO_ERR | G_IO_HUP | G_IO_NVAL,
> (GIOFunc) session_browsing_cb, session);
>
> + avctp_set_state(session, AVCTP_STATE_BROWSING_CONNECTED);
> return;
>
> fail:
> + avctp_set_state(session, AVCTP_STATE_CONNECTED);
> +
> if (session->browsing) {
> avctp_channel_destroy(session->browsing);
> session->browsing = NULL;
> @@ -1648,6 +1657,8 @@ int avctp_connect_browsing(struct avctp *session)
> if (session->browsing != NULL)
> return 0;
>
> + avctp_set_state(session, AVCTP_STATE_BROWSING_CONNECTING);
> +
> io = bt_io_connect(avctp_connect_browsing_cb, session, NULL, &err,
> BT_IO_OPT_SOURCE_BDADDR,
> adapter_get_address(session->server->adapter),
> diff --git a/profiles/audio/avctp.h b/profiles/audio/avctp.h
> index c25a3b3..d1fe693 100644
> --- a/profiles/audio/avctp.h
> +++ b/profiles/audio/avctp.h
> @@ -67,7 +67,9 @@ struct avctp;
> typedef enum {
> AVCTP_STATE_DISCONNECTED = 0,
> AVCTP_STATE_CONNECTING,
> - AVCTP_STATE_CONNECTED
> + AVCTP_STATE_CONNECTED,
> + AVCTP_STATE_BROWSING_CONNECTING,
> + AVCTP_STATE_BROWSING_CONNECTED
> } avctp_state_t;
>
> typedef void (*avctp_state_cb) (struct audio_device *dev,
> diff --git a/profiles/audio/avrcp.c b/profiles/audio/avrcp.c
> index 636d3e4..6cab45f 100644
> --- a/profiles/audio/avrcp.c
> +++ b/profiles/audio/avrcp.c
> @@ -2182,12 +2182,9 @@ static void session_tg_init(struct avrcp *session)
> (1 << AVRCP_EVENT_TRACK_REACHED_END) |
> (1 << AVRCP_EVENT_SETTINGS_CHANGED);
>
> - if (session->version >= 0x0104) {
> + if (session->version >= 0x0104)
> avrcp_register_notification(session,
> AVRCP_EVENT_VOLUME_CHANGED);
> - if (session->features & AVRCP_FEATURE_BROWSING)
> - avctp_connect_browsing(session->conn);
> - }
>
> session->control_id = avctp_register_pdu_handler(session->conn,
> AVC_OP_VENDORDEP,
> @@ -2341,6 +2338,7 @@ static void state_changed(struct audio_device *dev, avctp_state_t old_state,
> {
> struct avrcp_server *server;
> struct avrcp *session;
> + uint8_t browsing_failed = false;
>
> server = find_server(servers, device_get_adapter(dev->btd_dev));
> if (!server)
> @@ -2367,8 +2365,28 @@ static void state_changed(struct audio_device *dev, avctp_state_t old_state,
> if (session == NULL)
> break;
>
> - session->init(session);
> + if (session->version <= 0x0103) {
> + session->init(session);
> + break;
> + }
> +
> + /*AVCRP >= 1.4*/
> + if (old_state == AVCTP_STATE_CONNECTING) {
> + if (avctp_connect_browsing(session->conn) != 0)
> + browsing_failed = true;
> + } else if (old_state == AVCTP_STATE_BROWSING_CONNECTING) {
> + browsing_failed = true;
> + }
>
> + if (browsing_failed)
> + session->init(session);
> + break;
> + case AVCTP_STATE_BROWSING_CONNECTED:
> + if (session == NULL)
> + break;
> +
> + session->init(session);
> + break;
> default:
> return;
> }
> diff --git a/profiles/audio/device.c b/profiles/audio/device.c
> index d4ba6d2..2aa22bb 100644
> --- a/profiles/audio/device.c
> +++ b/profiles/audio/device.c
> @@ -289,6 +289,10 @@ static void device_avctp_cb(struct audio_device *dev,
> break;
> case AVCTP_STATE_CONNECTED:
> break;
> + case AVCTP_STATE_BROWSING_CONNECTING:
> + break;
> + case AVCTP_STATE_BROWSING_CONNECTED:
> + break;
> }
> }
>
> --
> 1.8.1
>
This patch has been applied, thanks.
--
Luiz Augusto von Dentz
^ permalink raw reply
* Re: [PATCH 3/3] Bluetooth: Add support for reading LE supported states
From: Marcel Holtmann @ 2013-01-22 12:05 UTC (permalink / raw)
To: Johan Hedberg; +Cc: linux-bluetooth
In-Reply-To: <1358856121-1928-3-git-send-email-johan.hedberg@gmail.com>
Hi Johan,
> The LE supported states indicate the states and state combinations that
> the link layer supports. This is important information for knowing what
> operations are possible when dealing with multiple connected devices.
> This patch adds reading of the supported states to the HCI init
> sequence.
>
> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
> ---
> include/net/bluetooth/hci.h | 6 ++++++
> include/net/bluetooth/hci_core.h | 1 +
> net/bluetooth/hci_event.c | 20 ++++++++++++++++++++
> 3 files changed, 27 insertions(+)
Acked-by: Marcel Holtmann <marcel@holtmann.org>
Regards
Marcel
^ permalink raw reply
* Re: [PATCH 2/3] Bluetooth: Add support for reading LE White List Size
From: Marcel Holtmann @ 2013-01-22 12:05 UTC (permalink / raw)
To: Johan Hedberg; +Cc: linux-bluetooth
In-Reply-To: <1358856121-1928-2-git-send-email-johan.hedberg@gmail.com>
Hi Johan,
> The LE White List Size is necessary to be known before attempting to
> feed the controller with any addresses intended for the white list. This
> patch adds the necessary HCI command sending to the HCI init sequence.
>
> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
> ---
> include/net/bluetooth/hci.h | 6 ++++++
> include/net/bluetooth/hci_core.h | 1 +
> net/bluetooth/hci_event.c | 20 ++++++++++++++++++++
> 3 files changed, 27 insertions(+)
Acked-by: Marcel Holtmann <marcel@holtmann.org>
Regards
Marcel
^ permalink raw reply
* Re: [PATCH 1/3] Bluetooth: Add LE Local Features reading support
From: Marcel Holtmann @ 2013-01-22 12:04 UTC (permalink / raw)
To: Johan Hedberg; +Cc: linux-bluetooth
In-Reply-To: <1358856121-1928-1-git-send-email-johan.hedberg@gmail.com>
Hi Johan,
> To be able to make the appropriate decisions for some LE procedures we
> need to know the LE features that the local controller supports.
> Therefore, it's important to have the LE Read Local Supported Features
> HCI comand as part of the HCI init sequence.
>
> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
> ---
> include/net/bluetooth/hci.h | 6 ++++++
> include/net/bluetooth/hci_core.h | 1 +
> net/bluetooth/hci_event.c | 20 ++++++++++++++++++++
> 3 files changed, 27 insertions(+)
Acked-by: Marcel Holtmann <marcel@holtmann.org>
Regards
Marcel
^ permalink raw reply
* Re: [PATCH 1/3] health: Fix possible use after free
From: Luiz Augusto von Dentz @ 2013-01-22 12:04 UTC (permalink / raw)
To: Syam Sidhardhan; +Cc: linux-bluetooth@vger.kernel.org
In-Reply-To: <1358775211-31005-1-git-send-email-s.syam@samsung.com>
Hi Syam,
On Mon, Jan 21, 2013 at 3:33 PM, Syam Sidhardhan <s.syam@samsung.com> wrote:
> A pointer to freed memory is dereferenced if we call function
> hdp_get_dcpsm_cb() with out any earlier reference.
> ---
> profiles/health/hdp.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/profiles/health/hdp.c b/profiles/health/hdp.c
> index c15f06a..a42ca48 100644
> --- a/profiles/health/hdp.c
> +++ b/profiles/health/hdp.c
> @@ -542,9 +542,9 @@ static void hdp_get_dcpsm_cb(uint16_t dcpsm, gpointer user_data, GError *err)
> hdp_tmp_dc_data_destroy, &gerr))
> return;
>
> - hdp_tmp_dc_data_unref(hdp_conn);
> hdp_conn->cb(hdp_chann->mdl, err, hdp_conn);
> g_error_free(gerr);
> + hdp_tmp_dc_data_unref(hdp_conn);
> }
>
> static void device_reconnect_mdl_cb(struct mcap_mdl *mdl, GError *err,
> --
> 1.7.9.5
All 3 patches are now upstream, thanks.
--
Luiz Augusto von Dentz
^ permalink raw reply
* [PATCH 3/3] Bluetooth: Add support for reading LE supported states
From: Johan Hedberg @ 2013-01-22 12:02 UTC (permalink / raw)
To: linux-bluetooth
In-Reply-To: <1358856121-1928-1-git-send-email-johan.hedberg@gmail.com>
From: Johan Hedberg <johan.hedberg@intel.com>
The LE supported states indicate the states and state combinations that
the link layer supports. This is important information for knowing what
operations are possible when dealing with multiple connected devices.
This patch adds reading of the supported states to the HCI init
sequence.
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
---
include/net/bluetooth/hci.h | 6 ++++++
include/net/bluetooth/hci_core.h | 1 +
net/bluetooth/hci_event.c | 20 ++++++++++++++++++++
3 files changed, 27 insertions(+)
diff --git a/include/net/bluetooth/hci.h b/include/net/bluetooth/hci.h
index f1766a6..7f12c25f 100644
--- a/include/net/bluetooth/hci.h
+++ b/include/net/bluetooth/hci.h
@@ -1045,6 +1045,12 @@ struct hci_rp_le_ltk_neg_reply {
__le16 handle;
} __packed;
+#define HCI_OP_LE_READ_SUPPORTED_STATES 0x201c
+struct hci_rp_le_read_supported_states {
+ __u8 status;
+ __u8 le_states[8];
+} __packed;
+
/* ---- HCI Events ---- */
#define HCI_EV_INQUIRY_COMPLETE 0x01
diff --git a/include/net/bluetooth/hci_core.h b/include/net/bluetooth/hci_core.h
index d6ed4ac..bcf8ffe 100644
--- a/include/net/bluetooth/hci_core.h
+++ b/include/net/bluetooth/hci_core.h
@@ -154,6 +154,7 @@ struct hci_dev {
__u8 host_features[8];
__u8 le_features[8];
__u8 le_white_list_size;
+ __u8 le_states[8];
__u8 commands[64];
__u8 hci_ver;
__u16 hci_rev;
diff --git a/net/bluetooth/hci_event.c b/net/bluetooth/hci_event.c
index d2fee64..d4fcba6 100644
--- a/net/bluetooth/hci_event.c
+++ b/net/bluetooth/hci_event.c
@@ -617,6 +617,9 @@ static void le_setup(struct hci_dev *hdev)
/* Read LE White List Size */
hci_send_cmd(hdev, HCI_OP_LE_READ_WHITE_LIST_SIZE, 0, NULL);
+
+ /* Read LE Supported States */
+ hci_send_cmd(hdev, HCI_OP_LE_READ_SUPPORTED_STATES, 0, NULL);
}
static void hci_setup(struct hci_dev *hdev)
@@ -1346,6 +1349,19 @@ static void hci_cc_le_ltk_neg_reply(struct hci_dev *hdev, struct sk_buff *skb)
hci_req_complete(hdev, HCI_OP_LE_LTK_NEG_REPLY, rp->status);
}
+static void hci_cc_le_read_supported_states(struct hci_dev *hdev,
+ struct sk_buff *skb)
+{
+ struct hci_rp_le_read_supported_states *rp = (void *) skb->data;
+
+ BT_DBG("%s status 0x%2.2x", hdev->name, rp->status);
+
+ if (!rp->status)
+ memcpy(hdev->le_states, rp->le_states, 8);
+
+ hci_req_complete(hdev, HCI_OP_LE_READ_SUPPORTED_STATES, rp->status);
+}
+
static void hci_cc_write_le_host_supported(struct hci_dev *hdev,
struct sk_buff *skb)
{
@@ -2712,6 +2728,10 @@ static void hci_cmd_complete_evt(struct hci_dev *hdev, struct sk_buff *skb)
hci_cc_le_ltk_neg_reply(hdev, skb);
break;
+ case HCI_OP_LE_READ_SUPPORTED_STATES:
+ hci_cc_le_read_supported_states(hdev, skb);
+ break;
+
case HCI_OP_WRITE_LE_HOST_SUPPORTED:
hci_cc_write_le_host_supported(hdev, skb);
break;
--
1.7.10.4
^ permalink raw reply related
* [PATCH 2/3] Bluetooth: Add support for reading LE White List Size
From: Johan Hedberg @ 2013-01-22 12:02 UTC (permalink / raw)
To: linux-bluetooth
In-Reply-To: <1358856121-1928-1-git-send-email-johan.hedberg@gmail.com>
From: Johan Hedberg <johan.hedberg@intel.com>
The LE White List Size is necessary to be known before attempting to
feed the controller with any addresses intended for the white list. This
patch adds the necessary HCI command sending to the HCI init sequence.
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
---
include/net/bluetooth/hci.h | 6 ++++++
include/net/bluetooth/hci_core.h | 1 +
net/bluetooth/hci_event.c | 20 ++++++++++++++++++++
3 files changed, 27 insertions(+)
diff --git a/include/net/bluetooth/hci.h b/include/net/bluetooth/hci.h
index 521eefa..f1766a6 100644
--- a/include/net/bluetooth/hci.h
+++ b/include/net/bluetooth/hci.h
@@ -1001,6 +1001,12 @@ struct hci_cp_le_create_conn {
#define HCI_OP_LE_CREATE_CONN_CANCEL 0x200e
+#define HCI_OP_LE_READ_WHITE_LIST_SIZE 0x200f
+struct hci_rp_le_read_white_list_size {
+ __u8 status;
+ __u8 size;
+} __packed;
+
#define HCI_OP_LE_CONN_UPDATE 0x2013
struct hci_cp_le_conn_update {
__le16 handle;
diff --git a/include/net/bluetooth/hci_core.h b/include/net/bluetooth/hci_core.h
index 3f607c9..d6ed4ac 100644
--- a/include/net/bluetooth/hci_core.h
+++ b/include/net/bluetooth/hci_core.h
@@ -153,6 +153,7 @@ struct hci_dev {
__u8 features[8];
__u8 host_features[8];
__u8 le_features[8];
+ __u8 le_white_list_size;
__u8 commands[64];
__u8 hci_ver;
__u16 hci_rev;
diff --git a/net/bluetooth/hci_event.c b/net/bluetooth/hci_event.c
index 07c8c79..d2fee64 100644
--- a/net/bluetooth/hci_event.c
+++ b/net/bluetooth/hci_event.c
@@ -614,6 +614,9 @@ static void le_setup(struct hci_dev *hdev)
/* Read LE Advertising Channel TX Power */
hci_send_cmd(hdev, HCI_OP_LE_READ_ADV_TX_POWER, 0, NULL);
+
+ /* Read LE White List Size */
+ hci_send_cmd(hdev, HCI_OP_LE_READ_WHITE_LIST_SIZE, 0, NULL);
}
static void hci_setup(struct hci_dev *hdev)
@@ -1306,6 +1309,19 @@ static void hci_cc_le_set_scan_enable(struct hci_dev *hdev,
}
}
+static void hci_cc_le_read_white_list_size(struct hci_dev *hdev,
+ struct sk_buff *skb)
+{
+ struct hci_rp_le_read_white_list_size *rp = (void *) skb->data;
+
+ BT_DBG("%s status 0x%2.2x size %u", hdev->name, rp->status, rp->size);
+
+ if (!rp->status)
+ hdev->le_white_list_size = rp->size;
+
+ hci_req_complete(hdev, HCI_OP_LE_READ_WHITE_LIST_SIZE, rp->status);
+}
+
static void hci_cc_le_ltk_reply(struct hci_dev *hdev, struct sk_buff *skb)
{
struct hci_rp_le_ltk_reply *rp = (void *) skb->data;
@@ -2684,6 +2700,10 @@ static void hci_cmd_complete_evt(struct hci_dev *hdev, struct sk_buff *skb)
hci_cc_le_set_scan_enable(hdev, skb);
break;
+ case HCI_OP_LE_READ_WHITE_LIST_SIZE:
+ hci_cc_le_read_white_list_size(hdev, skb);
+ break;
+
case HCI_OP_LE_LTK_REPLY:
hci_cc_le_ltk_reply(hdev, skb);
break;
--
1.7.10.4
^ 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