* [PATCH 5/5] build: Add missing Android files to EXTRA_DIST
From: Szymon Janc @ 2013-10-17 20:28 UTC (permalink / raw)
To: linux-bluetooth; +Cc: Szymon Janc
In-Reply-To: <1382041721-19960-1-git-send-email-szymon.janc@gmail.com>
From: Szymon Janc <szymon.janc@tieto.com>
---
Makefile.android | 19 ++++++++++++++++++-
1 file changed, 18 insertions(+), 1 deletion(-)
diff --git a/Makefile.android b/Makefile.android
index 00d962d..8ae3ddc 100644
--- a/Makefile.android
+++ b/Makefile.android
@@ -48,7 +48,24 @@ android_haltest_CFLAGS = $(AM_CFLAGS) -I$(srcdir)/android
endif
-EXTRA_DIST += android/Android.mk android/log.c
+EXTRA_DIST += android/Android.mk android/log.c android/device.c \
+ android/adapter.c android/main.c android/hal-msg.h \
+ android/hal.h
+
+EXTRA_DIST += android/hal_bt_sock.c android/hal_bluetooth.c
+
+EXTRA_DIST += android/client/terminal.c \
+ android/client/haltest.c \
+ android/client/hwmodule.c \
+ android/client/pollhandler.c \
+ android/client/history.c \
+ android/client/if-bt.c \
+ android/client/textconv.c \
+ android/client/textconv.h \
+ android/client/if-main.h \
+ android/client/pollhandler.h \
+ android/client/history.h \
+ android/client/terminal.h
EXTRA_DIST += android/hal-ipc-api.txt
--
1.8.4.rc3
^ permalink raw reply related
* [PATCH 4/5] gitignore: Add android/haltest
From: Szymon Janc @ 2013-10-17 20:28 UTC (permalink / raw)
To: linux-bluetooth; +Cc: Szymon Janc
In-Reply-To: <1382041721-19960-1-git-send-email-szymon.janc@gmail.com>
From: Szymon Janc <szymon.janc@tieto.com>
---
.gitignore | 1 +
1 file changed, 1 insertion(+)
diff --git a/.gitignore b/.gitignore
index 6b97247..520a3f4 100644
--- a/.gitignore
+++ b/.gitignore
@@ -103,3 +103,4 @@ unit/test-*.log
unit/test-*.trs
android/bluetoothd
+android/haltest
--
1.8.4.rc3
^ permalink raw reply related
* [PATCH 3/5] android: Fix crash in property_get stub
From: Szymon Janc @ 2013-10-17 20:28 UTC (permalink / raw)
To: linux-bluetooth; +Cc: Szymon Janc
In-Reply-To: <1382041721-19960-1-git-send-email-szymon.janc@gmail.com>
From: Szymon Janc <szymon.janc@tieto.com>
If value was not found and default_value was not provided NULL pointer
was passed as argument to strncpy resulting in crash.
---
android/cutils/properties.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/android/cutils/properties.h b/android/cutils/properties.h
index a9f7554..44a712c 100644
--- a/android/cutils/properties.h
+++ b/android/cutils/properties.h
@@ -43,7 +43,7 @@ static inline int property_get(const char *key, char *value,
if (!env)
env = default_value;
- if (!value)
+ if (!value || !env)
return 0;
strncpy(value, env, PROPERTY_VALUE_MAX);
--
1.8.4.rc3
^ permalink raw reply related
* [PATCH 2/5] android: Fix haltest build on Linux
From: Szymon Janc @ 2013-10-17 20:28 UTC (permalink / raw)
To: linux-bluetooth; +Cc: Szymon Janc
In-Reply-To: <1382041721-19960-1-git-send-email-szymon.janc@gmail.com>
From: Szymon Janc <szymon.janc@tieto.com>
On Linux HAL library is build into haltest binary and can be access
directly. Provide simple implementation of hw_get_module() that does
it.
---
Makefile.android | 3 ++-
android/client/hwmodule.c | 27 +++++++++++++++++++++++++++
2 files changed, 29 insertions(+), 1 deletion(-)
create mode 100644 android/client/hwmodule.c
diff --git a/Makefile.android b/Makefile.android
index 3bc95be..00d962d 100644
--- a/Makefile.android
+++ b/Makefile.android
@@ -39,7 +39,8 @@ android_haltest_SOURCES = android/client/haltest.c \
android/client/terminal.c \
android/client/history.c \
android/client/textconv.c \
- android/client/if-bt.c
+ android/client/if-bt.c \
+ android/client/hwmodule.c
android_haltest_LDADD = android/libhal-internal.la
diff --git a/android/client/hwmodule.c b/android/client/hwmodule.c
new file mode 100644
index 0000000..80e7475
--- /dev/null
+++ b/android/client/hwmodule.c
@@ -0,0 +1,27 @@
+/*
+ * Copyright (C) 2013 Intel Corporation
+ *
+ * Licensed under the Apache License, Version 2.0 (the "License");
+ * you may not use this file except in compliance with the License.
+ * You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ *
+*/
+
+#include "hardware/hardware.h"
+
+int hw_get_module(const char *id, const struct hw_module_t **module)
+{
+ extern struct hw_module_t HAL_MODULE_INFO_SYM;
+
+ *module = &HAL_MODULE_INFO_SYM;
+
+ return 0;
+}
--
1.8.4.rc3
^ permalink raw reply related
* [PATCH 1/5] build: Add haltest command line tester
From: Szymon Janc @ 2013-10-17 20:28 UTC (permalink / raw)
To: linux-bluetooth; +Cc: Szymon Janc
From: Szymon Janc <szymon.janc@tieto.com>
This is intended for testing Android daemon and HAL library on Linux.
---
Makefile.android | 14 ++++++++++++++
1 file changed, 14 insertions(+)
diff --git a/Makefile.android b/Makefile.android
index 3459a4d..3bc95be 100644
--- a/Makefile.android
+++ b/Makefile.android
@@ -31,6 +31,20 @@ android_libhal_internal_la_SOURCES = android/hal.h android/hal_bluetooth.c \
android/cutils/log.h \
android/cutils/properties.h
android_libhal_internal_la_CPPFLAGS = -I$(srcdir)/android
+
+noinst_PROGRAMS += android/haltest
+
+android_haltest_SOURCES = android/client/haltest.c \
+ android/client/pollhandler.c \
+ android/client/terminal.c \
+ android/client/history.c \
+ android/client/textconv.c \
+ android/client/if-bt.c
+
+android_haltest_LDADD = android/libhal-internal.la
+
+android_haltest_CFLAGS = $(AM_CFLAGS) -I$(srcdir)/android
+
endif
EXTRA_DIST += android/Android.mk android/log.c
--
1.8.4.rc3
^ permalink raw reply related
* Re: [PATCH] Bluetooth: Add hci_h4p driver
From: Pali Rohár @ 2013-10-17 20:25 UTC (permalink / raw)
To: Marcel Holtmann
Cc: Gustavo Padovan, Johan Hedberg, Pavel Machek, linux-kernel,
linux-bluetooth,
Ивайло Димитров,
Joni Lapilainen, Sebastian Reichel, Aaro Koskinen
In-Reply-To: <1379703710-5757-1-git-send-email-pali.rohar@gmail.com>
[-- Attachment #1: Type: Text/Plain, Size: 1606 bytes --]
On Friday 20 September 2013 21:01:50 Pali Rohár wrote:
> From: Ville Tervo <ville.tervo@nokia.com>
>
> This driver adding support for Nokia N900 bluetooth hardware
>
> Signed-off-by: Ville Tervo <ville.tervo@nokia.com>
> Signed-off-by: Pali Rohár <pali.rohar@gmail.com>
> ---
> drivers/bluetooth/Kconfig | 10 +
> drivers/bluetooth/Makefile | 2 +
> drivers/bluetooth/hci_h4p/Makefile | 7 +
> drivers/bluetooth/hci_h4p/core.c | 1085
> +++++++++++++++++++++++++++++++++
> drivers/bluetooth/hci_h4p/fw-bcm.c | 149 +++++
> drivers/bluetooth/hci_h4p/fw-csr.c | 152 +++++
> drivers/bluetooth/hci_h4p/fw-ti1273.c | 113 ++++
> drivers/bluetooth/hci_h4p/fw.c | 166 +++++
> drivers/bluetooth/hci_h4p/hci_h4p.h | 238 ++++++++
> drivers/bluetooth/hci_h4p/uart.c | 203 ++++++
> include/linux/bluetooth/hci_h4p.h | 41 ++
> 11 files changed, 2166 insertions(+)
> create mode 100644 drivers/bluetooth/hci_h4p/Makefile
> create mode 100644 drivers/bluetooth/hci_h4p/core.c
> create mode 100644 drivers/bluetooth/hci_h4p/fw-bcm.c
> create mode 100644 drivers/bluetooth/hci_h4p/fw-csr.c
> create mode 100644 drivers/bluetooth/hci_h4p/fw-ti1273.c
> create mode 100644 drivers/bluetooth/hci_h4p/fw.c
> create mode 100644 drivers/bluetooth/hci_h4p/hci_h4p.h
> create mode 100644 drivers/bluetooth/hci_h4p/uart.c
> create mode 100644 include/linux/bluetooth/hci_h4p.h
>
Can somebody look & comment this patch? What is needed to be part
of upstream kernel?
--
Pali Rohár
pali.rohar@gmail.com
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply
* Re: [PATCH 5/7] Bluetooth: Create recv_raw() channel callback
From: Marcel Holtmann @ 2013-10-17 19:30 UTC (permalink / raw)
To: Gustavo Padovan; +Cc: linux-bluetooth, Gustavo Padovan
In-Reply-To: <1381950515-25256-5-git-send-email-gustavo@padovan.org>
Hi Gustavo,
> This new callback isolates socket specific code from L2CAP core.
> A dummy version of the callback, l2cap_chan_no_recv_raw() is provided for
> users that do not need to receive raw data.
>
> Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
> ---
> include/net/bluetooth/l2cap.h | 8 ++++++++
> net/bluetooth/a2mp.c | 1 +
> net/bluetooth/l2cap_core.c | 12 +-----------
> net/bluetooth/l2cap_sock.c | 22 ++++++++++++++++++++++
> 4 files changed, 32 insertions(+), 11 deletions(-)
>
> diff --git a/include/net/bluetooth/l2cap.h b/include/net/bluetooth/l2cap.h
> index 3d922b9..af5eb23 100644
> --- a/include/net/bluetooth/l2cap.h
> +++ b/include/net/bluetooth/l2cap.h
> @@ -548,6 +548,8 @@ struct l2cap_ops {
> struct l2cap_chan *(*new_connection) (struct l2cap_chan *chan);
> int (*recv) (struct l2cap_chan * chan,
> struct sk_buff *skb);
> + int (*recv_raw) (struct l2cap_chan * chan,
> + struct sk_buff *skb);
> void (*teardown) (struct l2cap_chan *chan, int err);
> void (*close) (struct l2cap_chan *chan);
> void (*state_change) (struct l2cap_chan *chan,
> @@ -785,6 +787,12 @@ static inline struct l2cap_chan *l2cap_chan_no_new_connection(struct l2cap_chan
> return NULL;
> }
>
> +static inline int l2cap_chan_no_recv_raw(struct l2cap_chan *chan,
> + struct sk_buff *skb)
> +{
> + return 0;
> +}
> +
> static inline void l2cap_chan_no_teardown(struct l2cap_chan *chan, int err)
> {
> }
> diff --git a/net/bluetooth/a2mp.c b/net/bluetooth/a2mp.c
> index efcd108..72540a7 100644
> --- a/net/bluetooth/a2mp.c
> +++ b/net/bluetooth/a2mp.c
> @@ -707,6 +707,7 @@ static struct l2cap_ops a2mp_chan_ops = {
>
> /* Not implemented for A2MP */
> .new_connection = l2cap_chan_no_new_connection,
> + .recv_raw = l2cap_chan_no_recv_raw,
> .teardown = l2cap_chan_no_teardown,
> .ready = l2cap_chan_no_ready,
> .defer = l2cap_chan_no_defer,
> diff --git a/net/bluetooth/l2cap_core.c b/net/bluetooth/l2cap_core.c
> index e30a53a..45fcf5e 100644
> --- a/net/bluetooth/l2cap_core.c
> +++ b/net/bluetooth/l2cap_core.c
> @@ -2797,7 +2797,6 @@ static void l2cap_pass_to_tx_fbit(struct l2cap_chan *chan,
> /* Copy frame to all raw sockets on that connection */
> static void l2cap_raw_recv(struct l2cap_conn *conn, struct sk_buff *skb)
> {
> - struct sk_buff *nskb;
> struct l2cap_chan *chan;
>
> BT_DBG("conn %p", conn);
> @@ -2805,19 +2804,10 @@ static void l2cap_raw_recv(struct l2cap_conn *conn, struct sk_buff *skb)
> mutex_lock(&conn->chan_lock);
>
> list_for_each_entry(chan, &conn->chan_l, list) {
> - struct sock *sk = chan->sk;
> if (chan->chan_type != L2CAP_CHAN_RAW)
> continue;
>
> - /* Don't send frame to the socket it came from */
> - if (skb->sk == sk)
> - continue;
> - nskb = skb_clone(skb, GFP_KERNEL);
> - if (!nskb)
> - continue;
> -
> - if (chan->ops->recv(chan, nskb))
> - kfree_skb(nskb);
> + chan->ops->recv_raw(chan, skb);
> }
>
> mutex_unlock(&conn->chan_lock);
> diff --git a/net/bluetooth/l2cap_sock.c b/net/bluetooth/l2cap_sock.c
> index f5a7c66..b8be4fb 100644
> --- a/net/bluetooth/l2cap_sock.c
> +++ b/net/bluetooth/l2cap_sock.c
> @@ -1078,6 +1078,27 @@ done:
> return err;
> }
>
> +static int l2cap_sock_recv_raw_cb(struct l2cap_chan *chan, struct sk_buff *skb)
> +{
> + struct sock *sk = chan->data;
> + struct sk_buff *nskb;
> + int err;
> +
> + /* Don't send frame to the socket it came from */
> + if (skb->sk == sk)
> + return 0;
> +
> + nskb = skb_clone(skb, GFP_KERNEL);
> + if (!nskb)
> + return -ENOMEM;
> +
> + err = sock_queue_rcv_skb(sk, nskb);
> + if (err < 0)
> + kfree_skb(nskb);
> +
> + return err;
> +}
> +
I do not much like the semantics here. So with recv callback, we essentially hand over the SKB to the callback. If they return 0, then it now owns that SKB. If it returns an error we take care of freeing it.
So recv_raw has different semantics now. We give it an SKB and it can not own it since we need for potential other listeners on the raw channel.
What I think we need to do is to skb_clone in l2cap_core.c and then give that SKB to the recv_raw function. Then if it returns 0, the functions own the skb now. And can give it to sock_queue_rcv_skb. If it returns an error the lcap_core.c caller takes care of freeing the SKB again.
The downside is that we now clone the SKB also for the same socket. However normally we do not have any L2CAP raw sockets anyway. So this penalty seems to be acceptable.
I wonder if it would make sense to have bt_skb_cb(skb)->chan to store the L2CAP channel of every packet we receive. And then we can handle this in l2cap_core.c.
Regards
Marcel
^ permalink raw reply
* [PATCH] Bluetooth: Fix ATT socket backwards compatibility with user space
From: johan.hedberg @ 2013-10-17 19:16 UTC (permalink / raw)
To: linux-bluetooth
From: Johan Hedberg <johan.hedberg@intel.com>
Old user space versions bind the Attribute Protocol socket to
BDADDR_BREDR when they should be using BDADDR_LE_PUBLIC or
BDADDR_LE_RANDOM. The kernel recently introduced stricter checks on the
socket parameters but we need to punch this hole to them to ensure that
old user space versions keep working.
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
---
net/bluetooth/l2cap_sock.c | 19 +++++++++++++++++--
1 file changed, 17 insertions(+), 2 deletions(-)
diff --git a/net/bluetooth/l2cap_sock.c b/net/bluetooth/l2cap_sock.c
index 34e5a58..a43aead 100644
--- a/net/bluetooth/l2cap_sock.c
+++ b/net/bluetooth/l2cap_sock.c
@@ -159,8 +159,23 @@ static int l2cap_sock_connect(struct socket *sock, struct sockaddr *addr,
if (!bdaddr_type_is_valid(la.l2_bdaddr_type))
return -EINVAL;
- if (chan->src_type == BDADDR_BREDR && la.l2_bdaddr_type != BDADDR_BREDR)
- return -EINVAL;
+ if (chan->src_type == BDADDR_BREDR &&
+ la.l2_bdaddr_type != BDADDR_BREDR) {
+ if (!bdaddr_type_is_le(la.l2_bdaddr_type))
+ return -EINVAL;
+
+ /* Old user space versions will try to bind the ATT
+ * socket using BDADDR_BREDR, so we have to allow this
+ * to pass and fix chan->src_type to the correct value.
+ */
+ if (la.l2_cid != __constant_cpu_to_le16(L2CAP_CID_ATT))
+ return -EINVAL;
+
+ if (chan->scid != L2CAP_CID_ATT)
+ return -EINVAL;
+
+ chan->src_type = BDADDR_LE_PUBLIC;
+ }
if (chan->src_type != BDADDR_BREDR && la.l2_bdaddr_type == BDADDR_BREDR)
return -EINVAL;
--
1.8.3.1
^ permalink raw reply related
* [PATCH] Bluetooth: Expose current voice setting in debugfs
From: Marcel Holtmann @ 2013-10-17 19:02 UTC (permalink / raw)
To: linux-bluetooth
For easier debugging of the current voice setting, expose the value
in debugfs if the controller is BR/EDR capable.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
---
net/bluetooth/hci_core.c | 16 ++++++++++++++++
1 file changed, 16 insertions(+)
diff --git a/net/bluetooth/hci_core.c b/net/bluetooth/hci_core.c
index 3c1014c..b7c4ada 100644
--- a/net/bluetooth/hci_core.c
+++ b/net/bluetooth/hci_core.c
@@ -93,6 +93,20 @@ static const struct file_operations inquiry_cache_fops = {
.release = single_release,
};
+static int voice_setting_get(void *data, u64 *val)
+{
+ struct hci_dev *hdev = data;
+
+ hci_dev_lock(hdev);
+ *val = hdev->voice_setting;
+ hci_dev_unlock(hdev);
+
+ return 0;
+}
+
+DEFINE_SIMPLE_ATTRIBUTE(voice_setting_fops, voice_setting_get,
+ NULL, "0x%4.4llx\n");
+
static int auto_accept_delay_set(void *data, u64 val)
{
struct hci_dev *hdev = data;
@@ -833,6 +847,8 @@ static int __hci_init(struct hci_dev *hdev)
if (lmp_bredr_capable(hdev)) {
debugfs_create_file("inquiry_cache", 0444, hdev->debugfs,
hdev, &inquiry_cache_fops);
+ debugfs_create_file("voice_setting", 0444, hdev->debugfs,
+ hdev, &voice_setting_fops);
}
if (lmp_ssp_capable(hdev))
--
1.8.3.1
^ permalink raw reply related
* [PATCH] Bluetooth: Expose static address value for LE capable controllers
From: Marcel Holtmann @ 2013-10-17 18:45 UTC (permalink / raw)
To: linux-bluetooth
For LE capable controllers, the static address can be configured. For
debugging purposes expose the value in debugfs.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
---
net/bluetooth/hci_core.c | 27 +++++++++++++++++++++++++++
1 file changed, 27 insertions(+)
diff --git a/net/bluetooth/hci_core.c b/net/bluetooth/hci_core.c
index bb95ddd..3c1014c 100644
--- a/net/bluetooth/hci_core.c
+++ b/net/bluetooth/hci_core.c
@@ -118,6 +118,29 @@ static int auto_accept_delay_get(void *data, u64 *val)
DEFINE_SIMPLE_ATTRIBUTE(auto_accept_delay_fops, auto_accept_delay_get,
auto_accept_delay_set, "%llu\n");
+static int static_address_show(struct seq_file *f, void *p)
+{
+ struct hci_dev *hdev = f->private;
+
+ hci_dev_lock(hdev);
+ seq_printf(f, "%pMR\n", &hdev->static_addr);
+ hci_dev_unlock(hdev);
+
+ return 0;
+}
+
+static int static_address_open(struct inode *inode, struct file *file)
+{
+ return single_open(file, static_address_show, inode->i_private);
+}
+
+static const struct file_operations static_address_fops = {
+ .open = static_address_open,
+ .read = seq_read,
+ .llseek = seq_lseek,
+ .release = single_release,
+};
+
/* ---- HCI requests ---- */
static void hci_req_sync_complete(struct hci_dev *hdev, u8 result)
@@ -816,6 +839,10 @@ static int __hci_init(struct hci_dev *hdev)
debugfs_create_file("auto_accept_delay", 0644, hdev->debugfs,
hdev, &auto_accept_delay_fops);
+ if (lmp_le_capable(hdev))
+ debugfs_create_file("static_address", 0444, hdev->debugfs,
+ hdev, &static_address_fops);
+
return 0;
}
--
1.8.3.1
^ permalink raw reply related
* [PATCH] Bluetooth: Expose auto_accept_delay debugfs only when SSP is supported
From: Marcel Holtmann @ 2013-10-17 17:54 UTC (permalink / raw)
To: linux-bluetooth
The auto_accept_delay debugfs entry is only valid for BR/EDR capable
controllers that also support SSP. If SSP is not available or it is
a LE-only single mode controller this value has no affect and so do
not expose it.
Since the value can be actually changed, switch the permissions
to 0644 to clearly indicate that the value is indeed writeable.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
---
net/bluetooth/hci_core.c | 29 +++++++++++++++++++++++++++++
net/bluetooth/hci_sysfs.c | 31 -------------------------------
2 files changed, 29 insertions(+), 31 deletions(-)
diff --git a/net/bluetooth/hci_core.c b/net/bluetooth/hci_core.c
index 73c8def..bb95ddd 100644
--- a/net/bluetooth/hci_core.c
+++ b/net/bluetooth/hci_core.c
@@ -93,6 +93,31 @@ static const struct file_operations inquiry_cache_fops = {
.release = single_release,
};
+static int auto_accept_delay_set(void *data, u64 val)
+{
+ struct hci_dev *hdev = data;
+
+ hci_dev_lock(hdev);
+ hdev->auto_accept_delay = val;
+ hci_dev_unlock(hdev);
+
+ return 0;
+}
+
+static int auto_accept_delay_get(void *data, u64 *val)
+{
+ struct hci_dev *hdev = data;
+
+ hci_dev_lock(hdev);
+ *val = hdev->auto_accept_delay;
+ hci_dev_unlock(hdev);
+
+ return 0;
+}
+
+DEFINE_SIMPLE_ATTRIBUTE(auto_accept_delay_fops, auto_accept_delay_get,
+ auto_accept_delay_set, "%llu\n");
+
/* ---- HCI requests ---- */
static void hci_req_sync_complete(struct hci_dev *hdev, u8 result)
@@ -787,6 +812,10 @@ static int __hci_init(struct hci_dev *hdev)
hdev, &inquiry_cache_fops);
}
+ if (lmp_ssp_capable(hdev))
+ debugfs_create_file("auto_accept_delay", 0644, hdev->debugfs,
+ hdev, &auto_accept_delay_fops);
+
return 0;
}
diff --git a/net/bluetooth/hci_sysfs.c b/net/bluetooth/hci_sysfs.c
index 65ecb9e..a141960 100644
--- a/net/bluetooth/hci_sysfs.c
+++ b/net/bluetooth/hci_sysfs.c
@@ -466,35 +466,6 @@ static const struct file_operations uuids_fops = {
.release = single_release,
};
-static int auto_accept_delay_set(void *data, u64 val)
-{
- struct hci_dev *hdev = data;
-
- hci_dev_lock(hdev);
-
- hdev->auto_accept_delay = val;
-
- hci_dev_unlock(hdev);
-
- return 0;
-}
-
-static int auto_accept_delay_get(void *data, u64 *val)
-{
- struct hci_dev *hdev = data;
-
- hci_dev_lock(hdev);
-
- *val = hdev->auto_accept_delay;
-
- hci_dev_unlock(hdev);
-
- return 0;
-}
-
-DEFINE_SIMPLE_ATTRIBUTE(auto_accept_delay_fops, auto_accept_delay_get,
- auto_accept_delay_set, "%llu\n");
-
void hci_init_sysfs(struct hci_dev *hdev)
{
struct device *dev = &hdev->dev;
@@ -531,8 +502,6 @@ int hci_add_sysfs(struct hci_dev *hdev)
debugfs_create_file("uuids", 0444, hdev->debugfs, hdev, &uuids_fops);
- debugfs_create_file("auto_accept_delay", 0444, hdev->debugfs, hdev,
- &auto_accept_delay_fops);
return 0;
}
--
1.8.3.1
^ permalink raw reply related
* Re: [PATCH BlueZ] l2test: Set CID due to socket restrictions for LE
From: Marcel Holtmann @ 2013-10-17 15:30 UTC (permalink / raw)
To: Johan Hedberg; +Cc: Claudio Takahasi, BlueZ development
In-Reply-To: <20131017151446.GA3935@x220.p-661hnu-f1>
Hi Johan,
>>>> At some point we need to infer the adapter address type instead of
>>>> always use public address.
>>>
>>> To be honest, selecting whether to use a random address when scanning or
>>> advertising doesn't at least immediately strike me as something that
>>> should be done through the bind call, but instead something that should
>>> be a global setting for the entire adapter. Having the exact LE address
>>> type in connect() makes sense, but not necessarily for bind().
>>
>> It does make sense to have this. Userspace knows what it is doing.
>> Right now it is pretty simple. Either you have a public address, then
>> that is used. If you do not have a public, then you need to configure
>> a static address first, and then that will be used. So you know the
>> address type that is in use.
>
> I didn't mean that user space wouldn't know what it's doing. It'll be
> able to program a static address or enable privacy if necessary. What
> I'm saying is that this is an adapter-global setting which individual
> sockets may not be aware of (especially if the sockets reside in
> different processes).
>
> Nevertheless, sockets should obviously be able to say at a minimum "LE"
> or "BR/EDR" and that's clearly something that was overlooked and left
> buggy in user space.
I think that we need to have a listen ATT socket for each controller. So if controller hci0 uses a public address, then we bind it to the public address and LE_PUBLIC. If controller hci1 has no public address, then we program the static address and bind it to that address and LE_RANDOM.
If you bind it to BDADDR_ANY and bdaddr_type == BDADDR_ANY we have to use the hack to make old userspace work. And we really only should treat BDADDR_BDEDR as magic "auto" value for CID 0x0004 when BDADDR_ANY. Otherwise we reject things.
>> When adding support for privacy feature then this becomes a bit more
>> complicated, but at all times, the userspace will know how it
>> configured the kernel. Either use public address or use random
>> address.
>
> *If* we were to make this user space interface based on the socket
> information (as opposed to e.g. mgmt commands/settings) there are
> several things that need to be thought of:
>
> Server sockets:
>
> - bind() tells the kernel which address to use for advertising - no
> problems so far
> - What if there are two server sockets, one binding to public and the
> other to random address. Which one do we advertise with?
> - Do we "hide" the random address socket if the ACL was created by
> advertising with our public address?
We can just fail if we bind to LE_PUBLIC, but we are actually using LE_RANDOM. Same way the other way around. Only one of them is possible.
> Client sockets:
>
> - connect() tells the kernel which address to use for scanning - no
> problems (again) so far
Yes it is. It defeats the privacy purpose and you might have different background scanning. I thought about this already. When a controller gets powered on at the point we already made the decision to either use LE_PUBLIC or LE_RANDOM. So binding it to anything else should.
We might need to be nice and just fail on connect() and not on bind(). That is something we can discuss.
> - If there are two client sockets trying to connect to the same device
> but with different local addresses. We could "ride" on the ACL
> creation attempt of the first one, but what about the address
> conflict?
> - If there is an already existing ACL that was created by scanning with
> our public address and a client socket tries to connect by binding to
> our random address. Do we fail?
>
> So these things need at least some thinking and clearly specifying if we
> go the path of letting the local LE socket address type affect scanning
> and advertising behavior.
Not planning on doing. The address type to use is decided when power on.
Regards
Marcel
^ permalink raw reply
* Re: [PATCH BlueZ] l2test: Set CID due to socket restrictions for LE
From: Johan Hedberg @ 2013-10-17 15:14 UTC (permalink / raw)
To: Marcel Holtmann; +Cc: Claudio Takahasi, BlueZ development
In-Reply-To: <4DF07F65-8B30-42CA-809B-1F30440556BA@holtmann.org>
Hi Marcel,
On Thu, Oct 17, 2013, Marcel Holtmann wrote:
> >> At some point we need to infer the adapter address type instead of
> >> always use public address.
> >
> > To be honest, selecting whether to use a random address when scanning or
> > advertising doesn't at least immediately strike me as something that
> > should be done through the bind call, but instead something that should
> > be a global setting for the entire adapter. Having the exact LE address
> > type in connect() makes sense, but not necessarily for bind().
>
> It does make sense to have this. Userspace knows what it is doing.
> Right now it is pretty simple. Either you have a public address, then
> that is used. If you do not have a public, then you need to configure
> a static address first, and then that will be used. So you know the
> address type that is in use.
I didn't mean that user space wouldn't know what it's doing. It'll be
able to program a static address or enable privacy if necessary. What
I'm saying is that this is an adapter-global setting which individual
sockets may not be aware of (especially if the sockets reside in
different processes).
Nevertheless, sockets should obviously be able to say at a minimum "LE"
or "BR/EDR" and that's clearly something that was overlooked and left
buggy in user space.
> When adding support for privacy feature then this becomes a bit more
> complicated, but at all times, the userspace will know how it
> configured the kernel. Either use public address or use random
> address.
*If* we were to make this user space interface based on the socket
information (as opposed to e.g. mgmt commands/settings) there are
several things that need to be thought of:
Server sockets:
- bind() tells the kernel which address to use for advertising - no
problems so far
- What if there are two server sockets, one binding to public and the
other to random address. Which one do we advertise with?
- Do we "hide" the random address socket if the ACL was created by
advertising with our public address?
Client sockets:
- connect() tells the kernel which address to use for scanning - no
problems (again) so far
- If there are two client sockets trying to connect to the same device
but with different local addresses. We could "ride" on the ACL
creation attempt of the first one, but what about the address
conflict?
- If there is an already existing ACL that was created by scanning with
our public address and a client socket tries to connect by binding to
our random address. Do we fail?
So these things need at least some thinking and clearly specifying if we
go the path of letting the local LE socket address type affect scanning
and advertising behavior.
Johan
^ permalink raw reply
* Re: [PATCH 1/2] android: Import Android HAL headers
From: Luiz Augusto von Dentz @ 2013-10-17 14:37 UTC (permalink / raw)
To: Szymon Janc; +Cc: linux-bluetooth@vger.kernel.org
In-Reply-To: <1382004486-24512-1-git-send-email-szymon.janc@tieto.com>
Hi Szymon,
On Thu, Oct 17, 2013 at 1:08 PM, Szymon Janc <szymon.janc@tieto.com> wrote:
> This imports BT HAL headers as of tag android-4.3_r3.1 from
> https://android.googlesource.com/platform/hardware/libhardware
>
> Those files are needed for building HAL library and haltester tool on
> Linux.
> ---
> android/hardware/bluetooth.h | 468 ++++++++++++++++++++++++++++++++++++++
> android/hardware/bt_av.h | 90 ++++++++
> android/hardware/bt_gatt.h | 61 +++++
> android/hardware/bt_gatt_client.h | 275 ++++++++++++++++++++++
> android/hardware/bt_gatt_server.h | 175 ++++++++++++++
> android/hardware/bt_gatt_types.h | 48 ++++
> android/hardware/bt_hf.h | 284 +++++++++++++++++++++++
> android/hardware/bt_hh.h | 179 +++++++++++++++
> android/hardware/bt_hl.h | 123 ++++++++++
> android/hardware/bt_pan.h | 87 +++++++
> android/hardware/bt_rc.h | 234 +++++++++++++++++++
> android/hardware/bt_sock.h | 58 +++++
> android/hardware/hardware.h | 230 +++++++++++++++++++
> 13 files changed, 2312 insertions(+)
> create mode 100644 android/hardware/bluetooth.h
> create mode 100644 android/hardware/bt_av.h
> create mode 100644 android/hardware/bt_gatt.h
> create mode 100644 android/hardware/bt_gatt_client.h
> create mode 100644 android/hardware/bt_gatt_server.h
> create mode 100644 android/hardware/bt_gatt_types.h
> create mode 100644 android/hardware/bt_hf.h
> create mode 100644 android/hardware/bt_hh.h
> create mode 100644 android/hardware/bt_hl.h
> create mode 100644 android/hardware/bt_pan.h
> create mode 100644 android/hardware/bt_rc.h
> create mode 100644 android/hardware/bt_sock.h
> create mode 100644 android/hardware/hardware.h
Pushed, thanks.
^ permalink raw reply
* Re: [PATCH BlueZ] l2test: Set CID due to socket restrictions for LE
From: Marcel Holtmann @ 2013-10-17 14:29 UTC (permalink / raw)
To: Johan Hedberg; +Cc: Claudio Takahasi, BlueZ development
In-Reply-To: <20131017140019.GA361@x220.p-661hnu-f1>
Hi Johan,
>>>> Bluetooth kernel now restricts LE L2CAP sockets to ATT channels only.
>>>> For LE L2CAP socket bind, ATT CID is now mandatory. Reference: kernel patch
>>>> bfe4655f05d7ec4a7c0c1c7e4051862f824cd8ec
>>>> ---
>>>> tools/l2test.c | 2 ++
>>>> 1 file changed, 2 insertions(+)
>>>
>>> Applied thanks.
>>>
>>> Btw, I didn't realize that this check wasn't there before. It seems like
>>> it shouldn't cause any "real life" issues as our btio has always done a
>>> bind with the correct CID. Can you confirm that this should only be an
>>> issue for l2test?
>>>
>>> Johan
>>
>> Yes. btio calls bind with the correct CID.
>>
>> I suspect that the is another issue in bt_io_connect() call inside
>> device_browse_primary(),
>> the source address type is missing (it is mandatory now). I will send
>> a patch to fix it.
>
> Good catch, though we'll likely need to fix this for the kernel too so
> that we don't end up with a kernel release that breaks old user space
> versions.
whoever talked to me about adding bdaddr_type over and over again, and then not bothered to fix this in userspace, needs to stand in a corner and think about it for a long time what he has done now.
I am not amused about this at all.
>> At some point we need to infer the adapter address type instead of
>> always use public address.
>
> To be honest, selecting whether to use a random address when scanning or
> advertising doesn't at least immediately strike me as something that
> should be done through the bind call, but instead something that should
> be a global setting for the entire adapter. Having the exact LE address
> type in connect() makes sense, but not necessarily for bind().
It does make sense to have this. Userspace knows what it is doing. Right now it is pretty simple. Either you have a public address, then that is used. If you do not have a public, then you need to configure a static address first, and then that will be used. So you know the address type that is in use.
When adding support for privacy feature then this becomes a bit more complicated, but at all times, the userspace will know how it configured the kernel. Either use public address or use random address.
Regards
Marcel
^ permalink raw reply
* Re: [PATCH BlueZ] l2test: Set CID due to socket restrictions for LE
From: Johan Hedberg @ 2013-10-17 14:00 UTC (permalink / raw)
To: Claudio Takahasi; +Cc: BlueZ development
In-Reply-To: <CAKT1EBcunESoPak7NhMmW6-r2n3QH8CyJgtg=9W3fXx6sjNmcg@mail.gmail.com>
Hi Claudio,
On Thu, Oct 17, 2013, Claudio Takahasi wrote:
> On Wed, Oct 16, 2013 at 5:35 PM, Johan Hedberg <johan.hedberg@gmail.com> wrote:
> > Hi Claudio,
> >
> > On Wed, Oct 16, 2013, Claudio Takahasi wrote:
> >> Bluetooth kernel now restricts LE L2CAP sockets to ATT channels only.
> >> For LE L2CAP socket bind, ATT CID is now mandatory. Reference: kernel patch
> >> bfe4655f05d7ec4a7c0c1c7e4051862f824cd8ec
> >> ---
> >> tools/l2test.c | 2 ++
> >> 1 file changed, 2 insertions(+)
> >
> > Applied thanks.
> >
> > Btw, I didn't realize that this check wasn't there before. It seems like
> > it shouldn't cause any "real life" issues as our btio has always done a
> > bind with the correct CID. Can you confirm that this should only be an
> > issue for l2test?
> >
> > Johan
>
> Yes. btio calls bind with the correct CID.
>
> I suspect that the is another issue in bt_io_connect() call inside
> device_browse_primary(),
> the source address type is missing (it is mandatory now). I will send
> a patch to fix it.
Good catch, though we'll likely need to fix this for the kernel too so
that we don't end up with a kernel release that breaks old user space
versions.
> At some point we need to infer the adapter address type instead of
> always use public address.
To be honest, selecting whether to use a random address when scanning or
advertising doesn't at least immediately strike me as something that
should be done through the bind call, but instead something that should
be a global setting for the entire adapter. Having the exact LE address
type in connect() makes sense, but not necessarily for bind().
Johan
^ permalink raw reply
* [PATCH BlueZ] core: Fix missing adapter address type
From: Claudio Takahasi @ 2013-10-17 12:53 UTC (permalink / raw)
To: linux-bluetooth; +Cc: Claudio Takahasi
This patch fixes an invalid argument error when connecting to LE
devices. Bind and connect address type must match.
---
src/device.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/src/device.c b/src/device.c
index 457ab64..3dd3584 100644
--- a/src/device.c
+++ b/src/device.c
@@ -3446,6 +3446,7 @@ static int device_browse_primary(struct btd_device *device, DBusMessage *msg)
attcb, NULL, NULL,
BT_IO_OPT_SOURCE_BDADDR,
adapter_get_address(adapter),
+ BT_IO_OPT_SOURCE_TYPE, BDADDR_LE_PUBLIC,
BT_IO_OPT_DEST_BDADDR, &device->bdaddr,
BT_IO_OPT_DEST_TYPE, device->bdaddr_type,
BT_IO_OPT_CID, ATT_CID,
--
1.8.3.1
^ permalink raw reply related
* Re: [PATCH BlueZ] l2test: Set CID due to socket restrictions for LE
From: Claudio Takahasi @ 2013-10-17 12:39 UTC (permalink / raw)
To: Claudio Takahasi, BlueZ development
In-Reply-To: <20131016203518.GA947@x220.p-661hnu-f1>
Hi Johan:
On Wed, Oct 16, 2013 at 5:35 PM, Johan Hedberg <johan.hedberg@gmail.com> wrote:
> Hi Claudio,
>
> On Wed, Oct 16, 2013, Claudio Takahasi wrote:
>> Bluetooth kernel now restricts LE L2CAP sockets to ATT channels only.
>> For LE L2CAP socket bind, ATT CID is now mandatory. Reference: kernel patch
>> bfe4655f05d7ec4a7c0c1c7e4051862f824cd8ec
>> ---
>> tools/l2test.c | 2 ++
>> 1 file changed, 2 insertions(+)
>
> Applied thanks.
>
> Btw, I didn't realize that this check wasn't there before. It seems like
> it shouldn't cause any "real life" issues as our btio has always done a
> bind with the correct CID. Can you confirm that this should only be an
> issue for l2test?
>
> Johan
Yes. btio calls bind with the correct CID.
I suspect that the is another issue in bt_io_connect() call inside
device_browse_primary(),
the source address type is missing (it is mandatory now). I will send
a patch to fix it.
At some point we need to infer the adapter address type instead of
always use public address.
Regards,
Claudio
^ permalink raw reply
* Re: [PATCHv2 1/2] android: trivial typo fix
From: Johan Hedberg @ 2013-10-17 11:59 UTC (permalink / raw)
To: Andrei Emeltchenko; +Cc: linux-bluetooth
In-Reply-To: <1381999828-29649-2-git-send-email-Andrei.Emeltchenko.news@gmail.com>
Hi Andrei,
On Thu, Oct 17, 2013, Andrei Emeltchenko wrote:
> ---
> android/client/if-bt.c | 14 +++++++-------
> 1 file changed, 7 insertions(+), 7 deletions(-)
This patch has been applied. Thanks.
Johan
^ permalink raw reply
* Re: [PATCHv5 2/7] android: Implement read_info_complete callback
From: Johan Hedberg @ 2013-10-17 11:53 UTC (permalink / raw)
To: Andrei Emeltchenko; +Cc: linux-bluetooth
In-Reply-To: <1381998406-16662-3-git-send-email-Andrei.Emeltchenko.news@gmail.com>
Hi Andrei,
On Thu, Oct 17, 2013, Andrei Emeltchenko wrote:
> +static void read_info_complete(uint8_t status, uint16_t length, const void *param,
> + void *user_data)
> +{
> + struct bt_adapter *adapter = user_data;
> + const struct mgmt_rp_read_info *rp = param;
> +
> + DBG("");
> +
> + if (status) {
> + error("Failed to read info for index %u: %s (0x%02x)",
> + 0, mgmt_errstr(status), status);
> + goto failed;
> + }
> +
> + if (length < sizeof(*rp)) {
> + error("Too small read info complete response");
> + goto failed;
> + }
> +
> + if (!bacmp(&rp->bdaddr, BDADDR_ANY)) {
> + error("No Bluetooth address");
> + goto failed;
> + }
> +
> + /* Store adapter information */
> + bacpy(&adapter->bdaddr, &rp->bdaddr);
> + adapter->dev_class = rp->dev_class[0] | (rp->dev_class[1] << 8) |
> + (rp->dev_class[2] << 16);
> + adapter->name = g_strdup((const char *) rp->name);
> +
> + adapter->supported_settings = btohs(rp->supported_settings);
> + adapter->current_settings = btohs(rp->current_settings);
> +
> + /* TODO: Register all event notification handlers */
> +
> + if (adapter->current_settings & MGMT_SETTING_POWERED)
> + bt_adapter_start(adapter);
> +
> + load_link_keys(adapter, NULL);
> +
> + return;
> +
> +failed:
> + default_adapter = NULL;
> +}
This way of setting a variable in main.c to NULL without any other way
of notifying failure seems a bit messed up to me. You'll probably just
want to keep the adapter pointer private (static) to adapter.c.
>From where were you planning to initialize the UNIX socket towards the
HAL? I suppose it makes sense to do that once you've completed the basic
init with the read_info, load_link_keys, etc. If you want adapter.c to
do that there's not much needed, but if you need to notify back to
main.c you'll probably need some kind of callback mechanism.
Johan
^ permalink raw reply
* Re: [PATCHv5 1/7] android: Add capabilities and set userid
From: Andrei Emeltchenko @ 2013-10-17 11:26 UTC (permalink / raw)
To: linux-bluetooth
In-Reply-To: <20131017112010.GA19836@x220.p-661hnu-f1>
Hi Johan,
On Thu, Oct 17, 2013 at 02:20:10PM +0300, Johan Hedberg wrote:
> Hi Andrei,
>
> On Thu, Oct 17, 2013, Andrei Emeltchenko wrote:
> > The patch set UID as standard Bluetooth user for Android (AID_BLUETOOTH).
> > For SDP server we need to bind to lower port, acquire this capability.
>
> Which POSIX capability is "this capability" exactly?
>
> > + cap.effective = cap.permitted =
> > + CAP_TO_MASK(CAP_SETGID) |
> > + CAP_TO_MASK(CAP_NET_RAW) |
> > + CAP_TO_MASK(CAP_NET_ADMIN) |
> > + CAP_TO_MASK(CAP_NET_BIND_SERVICE);
>
> I just checked the kernel L2CAP socket code and all it requires for
> binding to a low L2CAP PSM (needed e.g. by SDP) is CAP_NET_BIND_SERVICE.
> So you'll need to explain what you need these other capabilities for.
>
Have you checked also Android PARANOID kernel code?
Best regards
Andrei Emeltchenko
^ permalink raw reply
* Re: [PATCHv5 1/7] android: Add capabilities and set userid
From: Johan Hedberg @ 2013-10-17 11:20 UTC (permalink / raw)
To: Andrei Emeltchenko; +Cc: linux-bluetooth
In-Reply-To: <1381998406-16662-2-git-send-email-Andrei.Emeltchenko.news@gmail.com>
Hi Andrei,
On Thu, Oct 17, 2013, Andrei Emeltchenko wrote:
> The patch set UID as standard Bluetooth user for Android (AID_BLUETOOTH).
> For SDP server we need to bind to lower port, acquire this capability.
Which POSIX capability is "this capability" exactly?
> + cap.effective = cap.permitted =
> + CAP_TO_MASK(CAP_SETGID) |
> + CAP_TO_MASK(CAP_NET_RAW) |
> + CAP_TO_MASK(CAP_NET_ADMIN) |
> + CAP_TO_MASK(CAP_NET_BIND_SERVICE);
I just checked the kernel L2CAP socket code and all it requires for
binding to a low L2CAP PSM (needed e.g. by SDP) is CAP_NET_BIND_SERVICE.
So you'll need to explain what you need these other capabilities for.
Johan
^ permalink raw reply
* Re: [RFC 7/9] android: Fix building with local cutils/log.h
From: Andrei Emeltchenko @ 2013-10-17 11:20 UTC (permalink / raw)
To: Anderson Lizardo; +Cc: Luiz Augusto von Dentz, BlueZ development
In-Reply-To: <CAJdJm_MNvbK7XaLaapeE_rR4fTxsENjoNouBqx2eLXBOkaTfsQ@mail.gmail.com>
Hi all,
On Thu, Oct 17, 2013 at 06:57:29AM -0400, Anderson Lizardo wrote:
> Hi Luiz,
>
> On Thu, Oct 17, 2013 at 4:55 AM, Luiz Augusto von Dentz
> <luiz.dentz@gmail.com> wrote:
> > From: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
> >
> > android/hal_bt_sock.c: In function 'btsock_listen_rfcomm':
> > android/hal_bt_sock.c:30:47: error: expected ')' before '__func__'
> > ALOGD(__func__);
>
> You can implement ALOGD() using vfprintf() (just like DBG(), but which
> uses vsyslog() instead) and avoid this commit.
I agree here, we are anyway implementing ALOGD, let's implement it
correctly.
Best regards
Andrei Emeltchenko
^ permalink raw reply
* Re: [RFC 7/9] android: Fix building with local cutils/log.h
From: Anderson Lizardo @ 2013-10-17 10:57 UTC (permalink / raw)
To: Luiz Augusto von Dentz; +Cc: BlueZ development
In-Reply-To: <1382000128-23762-8-git-send-email-luiz.dentz@gmail.com>
Hi Luiz,
On Thu, Oct 17, 2013 at 4:55 AM, Luiz Augusto von Dentz
<luiz.dentz@gmail.com> wrote:
> From: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
>
> android/hal_bt_sock.c: In function 'btsock_listen_rfcomm':
> android/hal_bt_sock.c:30:47: error: expected ')' before '__func__'
> ALOGD(__func__);
You can implement ALOGD() using vfprintf() (just like DBG(), but which
uses vsyslog() instead) and avoid this commit.
> ---
> android/hal_bluetooth.c | 52 ++++++++++++++++++++++++-------------------------
> android/hal_bt_sock.c | 2 +-
> 2 files changed, 27 insertions(+), 27 deletions(-)
>
> diff --git a/android/hal_bluetooth.c b/android/hal_bluetooth.c
> index 9bb9dcf..cf8f3ae 100644
> --- a/android/hal_bluetooth.c
> +++ b/android/hal_bluetooth.c
> @@ -44,7 +44,7 @@ static bool start_bt_daemon(void)
> {
> int tries = 40; /* wait 4 seconds for completion */
>
> - ALOGD(__func__);
> + ALOGD("%s",__func__);
In any case, several lines here are missing the space after ",".
Best Regards,
--
Anderson Lizardo
Instituto Nokia de Tecnologia - INdT
Manaus - Brazil
^ permalink raw reply
* Re: [RFC 15/15] Bluetooth: Auto connection and power off/on
From: Marcel Holtmann @ 2013-10-17 10:55 UTC (permalink / raw)
To: Andre Guedes; +Cc: linux-bluetooth
In-Reply-To: <1381965485-9159-16-git-send-email-andre.guedes@openbossa.org>
Hi Andre,
> If hdev is closed (e.g. Mgmt power off command, RFKILL or controller is
> reset), the established connections are dropped and no Disconnection
> Complete Event is sent to host. This way, the background scan is not
> triggered when devices configured with BT_AUTO_CONN_ALWAYS option
> disconnect. To fix this issue, before dropping the LE connections, we
> trigger the background scan for each connected device that requires
> BT_AUTO_CONN_ALWAYS auto connection.
>
> Moreover, once the adapter is powered on, we should start the background
> scan if we have triggers registered. This way, we keep the background
> scan running after a power off and power on sequence.
these are actually two independent patches.
> Signed-off-by: Andre Guedes <andre.guedes@openbossa.org>
> ---
> net/bluetooth/hci_conn.c | 35 +++++++++++++++++++++++++++++++++++
> net/bluetooth/hci_core.c | 2 ++
> 2 files changed, 37 insertions(+)
>
> diff --git a/net/bluetooth/hci_conn.c b/net/bluetooth/hci_conn.c
> index 5caf13b..66823eb 100644
> --- a/net/bluetooth/hci_conn.c
> +++ b/net/bluetooth/hci_conn.c
> @@ -954,6 +954,31 @@ timer:
> msecs_to_jiffies(hdev->idle_timeout));
> }
>
> +static void le_conn_drop_fixup(struct hci_conn *conn)
> +{
> + struct hci_dev *hdev = conn->hdev;
> + struct hci_conn_param *param;
> + int err;
> +
> + param = hci_find_conn_param(hdev, &conn->dst, conn->dst_type);
> + if (!param)
> + return;
> +
> + if (param->auto_connect != BT_AUTO_CONN_ALWAYS)
> + goto done;
> +
> + err = hci_trigger_background_scan(hdev);
> + if (err) {
> + BT_ERR("Failed to trigger background scanning: %d", err);
> + goto done;
> + }
> +
> + param->bg_scan_triggered = true;
> +
> +done:
> + hci_conn_param_put(param);
> +}
> +
> /* Drop all connection on the device */
> void hci_conn_hash_flush(struct hci_dev *hdev)
> {
> @@ -963,6 +988,16 @@ void hci_conn_hash_flush(struct hci_dev *hdev)
> BT_DBG("hdev %s", hdev->name);
>
> list_for_each_entry_safe(c, n, &h->list, list) {
> + /* If this is a LE connection in connected state we should do
> + * some fixup before dropping this connection. Since no
> + * Disconnection Complete Event will be sent to the host, we
> + * have to trigger the background scan in case this is a
> + * BT_AUTO_CONN_ALWAYS device. This is handled by the le_conn_
> + * drop_fixup() helper.
> + */
> + if (c->type == LE_LINK && c->state == BT_CONNECTED)
> + le_conn_drop_fixup(c);
> +
> c->state = BT_CLOSED;
I do not like this part. We already have the case where we need to re-enable advertising after a connection drops. So this should be in a common place. I do not want to hack this in into all kinds of places.
Regards
Marcel
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox