* Re: [PATCH 3/6] Bluetooth: Set discovery parameters
From: Marcel Holtmann @ 2013-08-10 16:09 UTC (permalink / raw)
To: Andre Guedes; +Cc: linux-bluetooth
In-Reply-To: <1376089954-13639-4-git-send-email-andre.guedes@openbossa.org>
Hi Andre,
> This patch adds support for setting discovery parameters through
> debugfs filesystem.
>
> Signed-off-by: Andre Guedes <andre.guedes@openbossa.org>
> ---
> net/bluetooth/hci_sysfs.c | 45 ++++++++++++++++++++++++++++++++++++++++++++-
> 1 file changed, 44 insertions(+), 1 deletion(-)
>
> diff --git a/net/bluetooth/hci_sysfs.c b/net/bluetooth/hci_sysfs.c
> index 90cb53b..17ebc4a 100644
> --- a/net/bluetooth/hci_sysfs.c
> +++ b/net/bluetooth/hci_sysfs.c
> @@ -553,9 +553,52 @@ static int discovery_parameters_open(struct inode *inode, struct file *file)
> return single_open(file, discovery_parameters_show, inode->i_private);
> }
>
> +static ssize_t discovery_parameters_write(struct file *file,
> + const char __user *data,
> + size_t count, loff_t *offset)
> +{
> + struct seq_file *sfile = file->private_data;
> + struct hci_dev *hdev = sfile->private;
> + struct discovery_param param;
> + char *buf;
> + int n;
> + ssize_t res = 0;
> +
> + /* We don't allow partial writes */
> + if (*offset != 0)
> + return 0;
> +
> + buf = kzalloc(count, GFP_KERNEL);
> + if (!buf)
> + return 0;
> +
> + if (copy_from_user(buf, data, count))
> + goto out;
> +
> + memset(¶m, 0, sizeof(param));
> +
> + n = sscanf(buf, "%hhx %hx %hx %u %u %hhx %hhx",
> + ¶m.scan_type, ¶m.scan_interval, ¶m.scan_window,
> + ¶m.le_scan_duration, ¶m.interleaved_scan_duration,
> + ¶m.interleaved_inquiry_length,
> + ¶m.bredr_inquiry_length);
I am not a huge fan of this crazy. I need a manual to know exactly what to do here. That is just silly. Unless things are a bit self-explanatory on how you can tweak things, I am not really interested here.
Also intermixing LE with BR/EDR is a bit pointless here. I would prefer if they are separate and not that BR/EDR only controller exports LE knobs and and LE only controller exports BR/EDR knobs.
Regards
Marcel
^ permalink raw reply
* [PATCH 6/6] Bluetooth: Add support for setting LE connection parameters via debugfs
From: Andre Guedes @ 2013-08-09 23:12 UTC (permalink / raw)
To: linux-bluetooth; +Cc: Vinicius Costa Gomes
In-Reply-To: <1376089954-13639-1-git-send-email-andre.guedes@openbossa.org>
From: Vinicius Costa Gomes <vinicius.gomes@openbossa.org>
This will allow for much more pratical measures of the impact of
different connection parameters in different scenarios.
Signed-off-by: Vinicius Costa Gomes <vinicius.gomes@openbossa.org>
---
net/bluetooth/hci_sysfs.c | 42 ++++++++++++++++++++++++++++++++++++++++++
1 file changed, 42 insertions(+)
diff --git a/net/bluetooth/hci_sysfs.c b/net/bluetooth/hci_sysfs.c
index 5993150..f3bf419 100644
--- a/net/bluetooth/hci_sysfs.c
+++ b/net/bluetooth/hci_sysfs.c
@@ -620,6 +620,47 @@ static int le_conn_parameters_show(struct seq_file *f, void *p)
return 0;
}
+static ssize_t le_conn_parameters_write(struct file *filp,
+ const char __user *ubuf,
+ size_t cnt, loff_t *ppos)
+{
+ struct seq_file *seqf = filp->private_data;
+ struct hci_dev *hdev = seqf->private;
+ struct le_conn_params params;
+ char buffer[36];
+ int n;
+
+ /* No partial writes */
+ if (*ppos != 0)
+ return 0;
+
+ /* Format: '0x0000 0x0000 0x0000 0x0000 0x0000' length 35 */
+ if (cnt != 35)
+ return -ENOSPC;
+
+ memset(buffer, 0, sizeof(buffer));
+
+ if (copy_from_user(buffer, ubuf, cnt))
+ return 0;
+
+ memset(¶ms, 0, sizeof(params));
+
+ n = sscanf(buffer, "%hx %hx %hx %hx %hx", ¶ms.scan_interval,
+ ¶ms.scan_window, ¶ms.conn_interval_min,
+ ¶ms.conn_interval_max, ¶ms.supervision_timeout);
+
+ if (n < 5)
+ return -EINVAL;
+
+ hci_dev_lock(hdev);
+
+ memcpy(&hdev->le_conn_params, ¶ms, sizeof(params));
+
+ hci_dev_unlock(hdev);
+
+ return cnt;
+}
+
static int le_conn_parameters_open(struct inode *inode, struct file *file)
{
return single_open(file, le_conn_parameters_show, inode->i_private);
@@ -627,6 +668,7 @@ static int le_conn_parameters_open(struct inode *inode, struct file *file)
static const struct file_operations le_conn_parameters_fops = {
.open = le_conn_parameters_open,
+ .write = le_conn_parameters_write,
.read = seq_read,
.llseek = seq_lseek,
.release = single_release,
--
1.8.3.4
^ permalink raw reply related
* [PATCH 5/6] Bluetooth: Add LE connection parameters to debugfs
From: Andre Guedes @ 2013-08-09 23:12 UTC (permalink / raw)
To: linux-bluetooth; +Cc: Vinicius Costa Gomes
In-Reply-To: <1376089954-13639-1-git-send-email-andre.guedes@openbossa.org>
From: Vinicius Costa Gomes <vinicius.gomes@openbossa.org>
Only reading the parameters is supported for now.
Signed-off-by: Vinicius Costa Gomes <vinicius.gomes@openbossa.org>
---
net/bluetooth/hci_sysfs.c | 33 +++++++++++++++++++++++++++++++++
1 file changed, 33 insertions(+)
diff --git a/net/bluetooth/hci_sysfs.c b/net/bluetooth/hci_sysfs.c
index 17ebc4a..5993150 100644
--- a/net/bluetooth/hci_sysfs.c
+++ b/net/bluetooth/hci_sysfs.c
@@ -603,6 +603,35 @@ static const struct file_operations discovery_parameters_fops = {
.release = single_release,
};
+static int le_conn_parameters_show(struct seq_file *f, void *p)
+{
+ struct hci_dev *hdev = f->private;
+ struct le_conn_params *params = &hdev->le_conn_params;
+
+ hci_dev_lock(hdev);
+
+ seq_printf(f, "0x%.4x 0x%.4x 0x%.4x 0x%.4x 0x%.4x\n",
+ params->scan_interval, params->scan_window,
+ params->conn_interval_min, params->conn_interval_max,
+ params->supervision_timeout);
+
+ hci_dev_unlock(hdev);
+
+ return 0;
+}
+
+static int le_conn_parameters_open(struct inode *inode, struct file *file)
+{
+ return single_open(file, le_conn_parameters_show, inode->i_private);
+}
+
+static const struct file_operations le_conn_parameters_fops = {
+ .open = le_conn_parameters_open,
+ .read = seq_read,
+ .llseek = seq_lseek,
+ .release = single_release,
+};
+
void hci_init_sysfs(struct hci_dev *hdev)
{
struct device *dev = &hdev->dev;
@@ -647,6 +676,10 @@ int hci_add_sysfs(struct hci_dev *hdev)
debugfs_create_file("discovery_parameters", 0644, hdev->debugfs, hdev,
&discovery_parameters_fops);
+
+ debugfs_create_file("le_conn_parameters", 0644, hdev->debugfs, hdev,
+ &le_conn_parameters_fops);
+
return 0;
}
--
1.8.3.4
^ permalink raw reply related
* [PATCH 4/6] Bluetooth: Keep the LE connection parameters in its own structure
From: Andre Guedes @ 2013-08-09 23:12 UTC (permalink / raw)
To: linux-bluetooth; +Cc: Vinicius Costa Gomes
In-Reply-To: <1376089954-13639-1-git-send-email-andre.guedes@openbossa.org>
From: Vinicius Costa Gomes <vinicius.gomes@openbossa.org>
This will allow for easier parameterization of these fields. This is
the first step for allowing to change the parameters during runtime.
Signed-off-by: Vinicius Costa Gomes <vinicius.gomes@openbossa.org>
---
include/net/bluetooth/hci_core.h | 10 ++++++++++
net/bluetooth/hci_conn.c | 11 ++++++-----
net/bluetooth/hci_core.c | 8 ++++++++
3 files changed, 24 insertions(+), 5 deletions(-)
diff --git a/include/net/bluetooth/hci_core.h b/include/net/bluetooth/hci_core.h
index 0a02fdb..24b91ae 100644
--- a/include/net/bluetooth/hci_core.h
+++ b/include/net/bluetooth/hci_core.h
@@ -117,6 +117,14 @@ struct oob_data {
u8 randomizer[16];
};
+struct le_conn_params {
+ u16 scan_interval;
+ u16 scan_window;
+ u16 conn_interval_min;
+ u16 conn_interval_max;
+ u16 supervision_timeout;
+};
+
#define HCI_MAX_SHORT_NAME_LENGTH 10
struct amp_assoc {
@@ -287,6 +295,8 @@ struct hci_dev {
struct delayed_work le_scan_disable;
+ struct le_conn_params le_conn_params;
+
__s8 adv_tx_power;
__u8 adv_data[HCI_MAX_AD_LENGTH];
__u8 adv_data_len;
diff --git a/net/bluetooth/hci_conn.c b/net/bluetooth/hci_conn.c
index 6c7f363..f944757 100644
--- a/net/bluetooth/hci_conn.c
+++ b/net/bluetooth/hci_conn.c
@@ -34,6 +34,7 @@
static void hci_le_create_connection(struct hci_conn *conn)
{
struct hci_dev *hdev = conn->hdev;
+ struct le_conn_params *params = &hdev->le_conn_params;
struct hci_cp_le_create_conn cp;
conn->state = BT_CONNECT;
@@ -42,13 +43,13 @@ static void hci_le_create_connection(struct hci_conn *conn)
conn->sec_level = BT_SECURITY_LOW;
memset(&cp, 0, sizeof(cp));
- cp.scan_interval = __constant_cpu_to_le16(0x0060);
- cp.scan_window = __constant_cpu_to_le16(0x0030);
+ cp.scan_interval = __cpu_to_le16(params->scan_interval);
+ cp.scan_window = __cpu_to_le16(params->scan_window);
bacpy(&cp.peer_addr, &conn->dst);
cp.peer_addr_type = conn->dst_type;
- cp.conn_interval_min = __constant_cpu_to_le16(0x0028);
- cp.conn_interval_max = __constant_cpu_to_le16(0x0038);
- cp.supervision_timeout = __constant_cpu_to_le16(0x002a);
+ cp.conn_interval_min = __cpu_to_le16(params->conn_interval_min);
+ cp.conn_interval_max = __cpu_to_le16(params->conn_interval_max);
+ cp.supervision_timeout = __cpu_to_le16(params->supervision_timeout);
cp.min_ce_len = __constant_cpu_to_le16(0x0000);
cp.max_ce_len = __constant_cpu_to_le16(0x0000);
diff --git a/net/bluetooth/hci_core.c b/net/bluetooth/hci_core.c
index 8750663..806d0c3 100644
--- a/net/bluetooth/hci_core.c
+++ b/net/bluetooth/hci_core.c
@@ -2079,6 +2079,7 @@ struct hci_dev *hci_alloc_dev(void)
{
struct hci_dev *hdev;
struct discovery_param *discov;
+ struct le_conn_params *conn_params;
hdev = kzalloc(sizeof(struct hci_dev), GFP_KERNEL);
if (!hdev)
@@ -2134,6 +2135,13 @@ struct hci_dev *hci_alloc_dev(void)
discov->interleaved_inquiry_length = DISCOV_INTERLEAVED_INQUIRY_LEN;
discov->bredr_inquiry_length = DISCOV_BREDR_INQUIRY_LEN;
+ conn_params = &hdev->le_conn_params;
+ conn_params->scan_interval = 0x0060;
+ conn_params->scan_window = 0x0030;
+ conn_params->conn_interval_min = 0x0028;
+ conn_params->conn_interval_max = 0x0038;
+ conn_params->supervision_timeout = 0x002a;
+
return hdev;
}
EXPORT_SYMBOL(hci_alloc_dev);
--
1.8.3.4
^ permalink raw reply related
* [PATCH 3/6] Bluetooth: Set discovery parameters
From: Andre Guedes @ 2013-08-09 23:12 UTC (permalink / raw)
To: linux-bluetooth
In-Reply-To: <1376089954-13639-1-git-send-email-andre.guedes@openbossa.org>
This patch adds support for setting discovery parameters through
debugfs filesystem.
Signed-off-by: Andre Guedes <andre.guedes@openbossa.org>
---
net/bluetooth/hci_sysfs.c | 45 ++++++++++++++++++++++++++++++++++++++++++++-
1 file changed, 44 insertions(+), 1 deletion(-)
diff --git a/net/bluetooth/hci_sysfs.c b/net/bluetooth/hci_sysfs.c
index 90cb53b..17ebc4a 100644
--- a/net/bluetooth/hci_sysfs.c
+++ b/net/bluetooth/hci_sysfs.c
@@ -553,9 +553,52 @@ static int discovery_parameters_open(struct inode *inode, struct file *file)
return single_open(file, discovery_parameters_show, inode->i_private);
}
+static ssize_t discovery_parameters_write(struct file *file,
+ const char __user *data,
+ size_t count, loff_t *offset)
+{
+ struct seq_file *sfile = file->private_data;
+ struct hci_dev *hdev = sfile->private;
+ struct discovery_param param;
+ char *buf;
+ int n;
+ ssize_t res = 0;
+
+ /* We don't allow partial writes */
+ if (*offset != 0)
+ return 0;
+
+ buf = kzalloc(count, GFP_KERNEL);
+ if (!buf)
+ return 0;
+
+ if (copy_from_user(buf, data, count))
+ goto out;
+
+ memset(¶m, 0, sizeof(param));
+
+ n = sscanf(buf, "%hhx %hx %hx %u %u %hhx %hhx",
+ ¶m.scan_type, ¶m.scan_interval, ¶m.scan_window,
+ ¶m.le_scan_duration, ¶m.interleaved_scan_duration,
+ ¶m.interleaved_inquiry_length,
+ ¶m.bredr_inquiry_length);
+ if (n != 7)
+ goto out;
+
+ hci_dev_lock(hdev);
+ memcpy(&hdev->discovery_param, ¶m, sizeof(param));
+ hci_dev_unlock(hdev);
+
+ res = count;
+out:
+ kfree(buf);
+ return res;
+}
+
static const struct file_operations discovery_parameters_fops = {
.open = discovery_parameters_open,
.read = seq_read,
+ .write = discovery_parameters_write,
.llseek = seq_lseek,
.release = single_release,
};
@@ -602,7 +645,7 @@ int hci_add_sysfs(struct hci_dev *hdev)
debugfs_create_file("auto_accept_delay", 0444, hdev->debugfs, hdev,
&auto_accept_delay_fops);
- debugfs_create_file("discovery_parameters", 0444, hdev->debugfs, hdev,
+ debugfs_create_file("discovery_parameters", 0644, hdev->debugfs, hdev,
&discovery_parameters_fops);
return 0;
}
--
1.8.3.4
^ permalink raw reply related
* [PATCH 2/6] Bluetooth: Export discovery parameters on debugfs
From: Andre Guedes @ 2013-08-09 23:12 UTC (permalink / raw)
To: linux-bluetooth
In-Reply-To: <1376089954-13639-1-git-send-email-andre.guedes@openbossa.org>
This patch exports discovery parameters thought debugfs filesystem.
The default values are:
$ cat discovery_parameters
0x01 0x0012 0x0012 10240 5120 0x04 0x08
The file format is the following:
Scanning type
Scanning interval
Scanning window
Scanning duration (in milliseconds) in LE discovery
Scanning duration (in milliseconds) in interleaved discovery
Inquiry length used in interleaved discovery
Inquiry length used in BR/EDR discovery
Signed-off-by: Andre Guedes <andre.guedes@openbossa.org>
---
net/bluetooth/hci_sysfs.c | 32 ++++++++++++++++++++++++++++++++
1 file changed, 32 insertions(+)
diff --git a/net/bluetooth/hci_sysfs.c b/net/bluetooth/hci_sysfs.c
index 7ad6ecf..90cb53b 100644
--- a/net/bluetooth/hci_sysfs.c
+++ b/net/bluetooth/hci_sysfs.c
@@ -531,6 +531,35 @@ 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 discovery_parameters_show(struct seq_file *f, void *ptr)
+{
+ struct hci_dev *hdev = f->private;
+ struct discovery_param *p = &hdev->discovery_param;
+
+ hci_dev_lock(hdev);
+
+ seq_printf(f, "0x%.2x 0x%.4x 0x%.4x %u %u 0x%.2x 0x%.2x\n",
+ p->scan_type, p->scan_interval, p->scan_window,
+ p->le_scan_duration, p->interleaved_scan_duration,
+ p->interleaved_inquiry_length, p->bredr_inquiry_length);
+
+ hci_dev_unlock(hdev);
+
+ return 0;
+}
+
+static int discovery_parameters_open(struct inode *inode, struct file *file)
+{
+ return single_open(file, discovery_parameters_show, inode->i_private);
+}
+
+static const struct file_operations discovery_parameters_fops = {
+ .open = discovery_parameters_open,
+ .read = seq_read,
+ .llseek = seq_lseek,
+ .release = single_release,
+};
+
void hci_init_sysfs(struct hci_dev *hdev)
{
struct device *dev = &hdev->dev;
@@ -572,6 +601,9 @@ int hci_add_sysfs(struct hci_dev *hdev)
debugfs_create_file("auto_accept_delay", 0444, hdev->debugfs, hdev,
&auto_accept_delay_fops);
+
+ debugfs_create_file("discovery_parameters", 0444, hdev->debugfs, hdev,
+ &discovery_parameters_fops);
return 0;
}
--
1.8.3.4
^ permalink raw reply related
* [PATCH 1/6] Bluetooth: Discovery parameters per hci_dev
From: Andre Guedes @ 2013-08-09 23:12 UTC (permalink / raw)
To: linux-bluetooth
In-Reply-To: <1376089954-13639-1-git-send-email-andre.guedes@openbossa.org>
This patch adds discovery parameters to struct hci_dev. This way, we
will be able to configure the discovery parameters per hci device.
Signed-off-by: Andre Guedes <andre.guedes@openbossa.org>
---
include/net/bluetooth/hci_core.h | 13 +++++++++++++
net/bluetooth/hci_core.c | 13 ++++++++++++-
net/bluetooth/mgmt.c | 15 +++++++++------
3 files changed, 34 insertions(+), 7 deletions(-)
diff --git a/include/net/bluetooth/hci_core.h b/include/net/bluetooth/hci_core.h
index f77885e..0a02fdb 100644
--- a/include/net/bluetooth/hci_core.h
+++ b/include/net/bluetooth/hci_core.h
@@ -127,6 +127,17 @@ struct amp_assoc {
__u8 data[HCI_MAX_AMP_ASSOC_SIZE];
};
+struct discovery_param {
+ u8 scan_type;
+ u16 scan_interval;
+ u16 scan_window;
+ unsigned int interleaved_scan_duration;
+ unsigned int le_scan_duration;
+
+ u8 interleaved_inquiry_length;
+ u8 bredr_inquiry_length;
+};
+
#define HCI_MAX_PAGES 3
#define NUM_REASSEMBLY 4
@@ -280,6 +291,8 @@ struct hci_dev {
__u8 adv_data[HCI_MAX_AD_LENGTH];
__u8 adv_data_len;
+ struct discovery_param discovery_param;
+
int (*open)(struct hci_dev *hdev);
int (*close)(struct hci_dev *hdev);
int (*flush)(struct hci_dev *hdev);
diff --git a/net/bluetooth/hci_core.c b/net/bluetooth/hci_core.c
index b821b19..8750663 100644
--- a/net/bluetooth/hci_core.c
+++ b/net/bluetooth/hci_core.c
@@ -2013,6 +2013,7 @@ static void le_scan_disable_work_complete(struct hci_dev *hdev, u8 status)
{
/* General inquiry access code (GIAC) */
u8 lap[3] = { 0x33, 0x8b, 0x9e };
+ struct discovery_param *discov = &hdev->discovery_param;
struct hci_request req;
struct hci_cp_inquiry cp;
int err;
@@ -2034,7 +2035,7 @@ static void le_scan_disable_work_complete(struct hci_dev *hdev, u8 status)
memset(&cp, 0, sizeof(cp));
memcpy(&cp.lap, lap, sizeof(cp.lap));
- cp.length = DISCOV_INTERLEAVED_INQUIRY_LEN;
+ cp.length = discov->interleaved_inquiry_length;
hci_req_add(&req, HCI_OP_INQUIRY, sizeof(cp), &cp);
hci_dev_lock(hdev);
@@ -2077,6 +2078,7 @@ static void le_scan_disable_work(struct work_struct *work)
struct hci_dev *hci_alloc_dev(void)
{
struct hci_dev *hdev;
+ struct discovery_param *discov;
hdev = kzalloc(sizeof(struct hci_dev), GFP_KERNEL);
if (!hdev)
@@ -2123,6 +2125,15 @@ struct hci_dev *hci_alloc_dev(void)
hci_init_sysfs(hdev);
discovery_init(hdev);
+ discov = &hdev->discovery_param;
+ discov->scan_type = LE_SCAN_ACTIVE;
+ discov->scan_interval = DISCOV_LE_SCAN_INT;
+ discov->scan_window = DISCOV_LE_SCAN_WIN;
+ discov->le_scan_duration = DISCOV_LE_TIMEOUT;
+ discov->interleaved_scan_duration = DISCOV_INTERLEAVED_TIMEOUT;
+ discov->interleaved_inquiry_length = DISCOV_INTERLEAVED_INQUIRY_LEN;
+ discov->bredr_inquiry_length = DISCOV_BREDR_INQUIRY_LEN;
+
return hdev;
}
EXPORT_SYMBOL(hci_alloc_dev);
diff --git a/net/bluetooth/mgmt.c b/net/bluetooth/mgmt.c
index fedc539..2b4a3ba 100644
--- a/net/bluetooth/mgmt.c
+++ b/net/bluetooth/mgmt.c
@@ -2642,6 +2642,8 @@ static int mgmt_start_discovery_failed(struct hci_dev *hdev, u8 status)
static void start_discovery_complete(struct hci_dev *hdev, u8 status)
{
+ struct discovery_param *discov = &hdev->discovery_param;
+
BT_DBG("status %d", status);
if (status) {
@@ -2658,12 +2660,12 @@ static void start_discovery_complete(struct hci_dev *hdev, u8 status)
switch (hdev->discovery.type) {
case DISCOV_TYPE_LE:
queue_delayed_work(hdev->workqueue, &hdev->le_scan_disable,
- DISCOV_LE_TIMEOUT);
+ discov->le_scan_duration);
break;
case DISCOV_TYPE_INTERLEAVED:
queue_delayed_work(hdev->workqueue, &hdev->le_scan_disable,
- DISCOV_INTERLEAVED_TIMEOUT);
+ discov->interleaved_scan_duration);
break;
case DISCOV_TYPE_BREDR:
@@ -2678,6 +2680,7 @@ static int start_discovery(struct sock *sk, struct hci_dev *hdev,
void *data, u16 len)
{
struct mgmt_cp_start_discovery *cp = data;
+ struct discovery_param *discov = &hdev->discovery_param;
struct pending_cmd *cmd;
struct hci_cp_le_set_scan_param param_cp;
struct hci_cp_le_set_scan_enable enable_cp;
@@ -2739,7 +2742,7 @@ static int start_discovery(struct sock *sk, struct hci_dev *hdev,
memset(&inq_cp, 0, sizeof(inq_cp));
memcpy(&inq_cp.lap, lap, sizeof(inq_cp.lap));
- inq_cp.length = DISCOV_BREDR_INQUIRY_LEN;
+ inq_cp.length = discov->bredr_inquiry_length;
hci_req_add(&req, HCI_OP_INQUIRY, sizeof(inq_cp), &inq_cp);
break;
@@ -2775,9 +2778,9 @@ static int start_discovery(struct sock *sk, struct hci_dev *hdev,
}
memset(¶m_cp, 0, sizeof(param_cp));
- param_cp.type = LE_SCAN_ACTIVE;
- param_cp.interval = cpu_to_le16(DISCOV_LE_SCAN_INT);
- param_cp.window = cpu_to_le16(DISCOV_LE_SCAN_WIN);
+ param_cp.type = discov->scan_type;
+ param_cp.interval = cpu_to_le16(discov->scan_interval);
+ param_cp.window = cpu_to_le16(discov->scan_window);
hci_req_add(&req, HCI_OP_LE_SET_SCAN_PARAM, sizeof(param_cp),
¶m_cp);
--
1.8.3.4
^ permalink raw reply related
* [PATCH 0/6] LE parameters via debugfs
From: Andre Guedes @ 2013-08-09 23:12 UTC (permalink / raw)
To: linux-bluetooth
Hi all,
This patchset exports discovery and LE connection parameters via debugfs
filesystem. This might be useful for those who would like to do experiments
with different parameters.
BR,
Andre
Andre Guedes (3):
Bluetooth: Discovery parameters per hci_dev
Bluetooth: Export discovery parameters on debugfs
Bluetooth: Set discovery parameters
Vinicius Costa Gomes (3):
Bluetooth: Keep the LE connection parameters in its own structure
Bluetooth: Add LE connection parameters to debugfs
Bluetooth: Add support for setting LE connection parameters via
debugfs
include/net/bluetooth/hci_core.h | 23 ++++++
net/bluetooth/hci_conn.c | 11 +--
net/bluetooth/hci_core.c | 21 +++++-
net/bluetooth/hci_sysfs.c | 150 +++++++++++++++++++++++++++++++++++++++
net/bluetooth/mgmt.c | 15 ++--
5 files changed, 208 insertions(+), 12 deletions(-)
--
1.8.3.4
^ permalink raw reply
* API documentation for BLE?
From: Tim Aerts @ 2013-08-09 16:20 UTC (permalink / raw)
To: linux-bluetooth
Hello everybody,
Starting on Monday, I will need to implement BLE Central capabilities
into a Linux app. On Mac/iOS I have a CoreBluetooth for this. But on
Linux, I wouldn't know where to start. So far, this is my only lead.
I have found some online description to libbluetooth-dev, but it's
pretty old, and does not include anything about BLE. So I'd appreciate
whomever can get me going.
1. Is this the right place? Do I need libbluetooth-dev to create a BLE
capable app?
2. Is there any documentation about this API? Since BT and BLE have
different semantics, I am guessing the BT-related documentation is not
the one I should be looking at?
Thanks in advance!
Tim
^ permalink raw reply
* Re: [PATCH 1/3] sco-tester: Update ECONNABORTED to EOPNOTSUPP
From: Marcel Holtmann @ 2013-08-09 15:53 UTC (permalink / raw)
To: Frédéric Dalleau; +Cc: linux-bluetooth
In-Reply-To: <1376062977-1497-1-git-send-email-frederic.dalleau@linux.intel.com>
Hi Fred,
> Kernel interface has evolved in between.
> ---
> tools/sco-tester.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/tools/sco-tester.c b/tools/sco-tester.c
> index 70b8a5d..1e8351f 100644
> --- a/tools/sco-tester.c
> +++ b/tools/sco-tester.c
> @@ -237,7 +237,7 @@ static const struct sco_client_data connect_success = {
> };
>
> static const struct sco_client_data connect_failure = {
> - .expect_err = ECONNABORTED
> + .expect_err = EOPNOTSUPP
> };
can we please have a proper thread on what error is appropriate to send from a socket interface when this situation happens. I see that we are flipping errors, but my request to discuss this gets ignored.
Please look for a good reference of the error code usage in other socket protocols or manpages
Regards
Marcel
^ permalink raw reply
* [PATCH 3/3] sco-tester: Test transparent data feature bit
From: Frédéric Dalleau @ 2013-08-09 15:42 UTC (permalink / raw)
To: linux-bluetooth; +Cc: Frédéric Dalleau
In-Reply-To: <1376062977-1497-1-git-send-email-frederic.dalleau@linux.intel.com>
---
tools/sco-tester.c | 20 +++++++++++++++-----
1 file changed, 15 insertions(+), 5 deletions(-)
diff --git a/tools/sco-tester.c b/tools/sco-tester.c
index e826d9c..e45956a 100644
--- a/tools/sco-tester.c
+++ b/tools/sco-tester.c
@@ -45,6 +45,7 @@
struct adapter_features {
bool disable_esco;
+ bool enable_transp;
};
struct test_data {
@@ -145,6 +146,7 @@ static void read_index_list_callback(uint8_t status, uint16_t length,
const void *param, void *user_data)
{
struct test_data *data = tester_get_data();
+ uint8_t *features;
tester_print("Read Index List callback");
tester_print(" Status: 0x%02x", status);
@@ -168,14 +170,16 @@ static void read_index_list_callback(uint8_t status, uint16_t length,
tester_print("New hciemu instance created");
- if (data->features.disable_esco) {
- uint8_t *features;
+ features = hciemu_get_features(data->hciemu);
+ if (data->features.disable_esco) {
tester_print("Disabling eSCO packet type support");
+ features[3] &= ~0x80;
+ }
- features = hciemu_get_features(data->hciemu);
- if (features)
- features[3] &= ~0x80;
+ if (data->features.enable_transp) {
+ tester_print("Enabling transparent data support");
+ features[2] |= 0x08;
}
}
@@ -579,6 +583,7 @@ int main(int argc, char *argv[])
tester_init(&argc, &argv);
features.disable_esco = 0;
+ features.enable_transp = 1;
test_sco("Basic Framework - Success", NULL, setup_powered,
test_framework, features);
@@ -598,6 +603,11 @@ int main(int argc, char *argv[])
test_sco("eSCO MSBC - Success", &connect_success, setup_powered,
test_connect_transp, features);
+ features.enable_transp = 0;
+
+ test_sco("eSCO MSBC - Failure", &connect_failure, setup_powered,
+ test_connect_transp, features);
+
features.disable_esco = 1;
test_sco("SCO CVSD 1.1 - Success", &connect_success, setup_powered,
--
1.7.9.5
^ permalink raw reply related
* [PATCH 2/3] sco-tester: Introduce adapter features
From: Frédéric Dalleau @ 2013-08-09 15:42 UTC (permalink / raw)
To: linux-bluetooth; +Cc: Frédéric Dalleau
In-Reply-To: <1376062977-1497-1-git-send-email-frederic.dalleau@linux.intel.com>
---
tools/sco-tester.c | 43 ++++++++++++++++++++++++-------------------
1 file changed, 24 insertions(+), 19 deletions(-)
diff --git a/tools/sco-tester.c b/tools/sco-tester.c
index 1e8351f..e826d9c 100644
--- a/tools/sco-tester.c
+++ b/tools/sco-tester.c
@@ -43,6 +43,10 @@
#include "src/shared/mgmt.h"
#include "src/shared/hciemu.h"
+struct adapter_features {
+ bool disable_esco;
+};
+
struct test_data {
const void *test_data;
struct mgmt *mgmt;
@@ -50,7 +54,7 @@ struct test_data {
struct hciemu *hciemu;
enum hciemu_type hciemu_type;
unsigned int io_id;
- bool disable_esco;
+ struct adapter_features features;
};
struct sco_client_data {
@@ -164,7 +168,7 @@ static void read_index_list_callback(uint8_t status, uint16_t length,
tester_print("New hciemu instance created");
- if (data->disable_esco) {
+ if (data->features.disable_esco) {
uint8_t *features;
tester_print("Disabling eSCO packet type support");
@@ -211,7 +215,7 @@ static void test_data_free(void *test_data)
free(data);
}
-#define test_sco_full(name, data, setup, func, _disable_esco) \
+#define test_sco(name, data, setup, func, feat) \
do { \
struct test_data *user; \
user = malloc(sizeof(struct test_data)); \
@@ -220,17 +224,12 @@ static void test_data_free(void *test_data)
user->hciemu_type = HCIEMU_TYPE_BREDRLE; \
user->io_id = 0; \
user->test_data = data; \
- user->disable_esco = _disable_esco; \
+ user->features = feat; \
tester_add_full(name, data, \
test_pre_setup, setup, func, NULL, \
test_post_teardown, 2, user, test_data_free); \
} while (0)
-#define test_sco(name, data, setup, func) \
- test_sco_full(name, data, setup, func, false)
-
-#define test_sco_11(name, data, setup, func) \
- test_sco_full(name, data, setup, func, true)
static const struct sco_client_data connect_success = {
.expect_err = 0
@@ -575,31 +574,37 @@ end:
int main(int argc, char *argv[])
{
+ static struct adapter_features features;
+
tester_init(&argc, &argv);
+ features.disable_esco = 0;
+
test_sco("Basic Framework - Success", NULL, setup_powered,
- test_framework);
+ test_framework, features);
test_sco("Basic SCO Socket - Success", NULL, setup_powered,
- test_socket);
+ test_socket, features);
test_sco("Basic SCO Get Socket Option - Success", NULL, setup_powered,
- test_getsockopt);
+ test_getsockopt, features);
test_sco("Basic SCO Set Socket Option - Success", NULL, setup_powered,
- test_setsockopt);
+ test_setsockopt, features);
test_sco("eSCO CVSD - Success", &connect_success, setup_powered,
- test_connect);
+ test_connect, features);
test_sco("eSCO MSBC - Success", &connect_success, setup_powered,
- test_connect_transp);
+ test_connect_transp, features);
+
+ features.disable_esco = 1;
- test_sco_11("SCO CVSD 1.1 - Success", &connect_success, setup_powered,
- test_connect);
+ test_sco("SCO CVSD 1.1 - Success", &connect_success, setup_powered,
+ test_connect, features);
- test_sco_11("SCO MSBC 1.1 - Failure", &connect_failure, setup_powered,
- test_connect_transp);
+ test_sco("SCO MSBC 1.1 - Failure", &connect_failure, setup_powered,
+ test_connect_transp, features);
return tester_run();
}
--
1.7.9.5
^ permalink raw reply related
* [PATCH 1/3] sco-tester: Update ECONNABORTED to EOPNOTSUPP
From: Frédéric Dalleau @ 2013-08-09 15:42 UTC (permalink / raw)
To: linux-bluetooth; +Cc: Frédéric Dalleau
Kernel interface has evolved in between.
---
tools/sco-tester.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tools/sco-tester.c b/tools/sco-tester.c
index 70b8a5d..1e8351f 100644
--- a/tools/sco-tester.c
+++ b/tools/sco-tester.c
@@ -237,7 +237,7 @@ static const struct sco_client_data connect_success = {
};
static const struct sco_client_data connect_failure = {
- .expect_err = ECONNABORTED
+ .expect_err = EOPNOTSUPP
};
static void client_connectable_complete(uint16_t opcode, uint8_t status,
--
1.7.9.5
^ permalink raw reply related
* Re: Linux Wireless Mini-Summit in New Orleans -- 19-20 September (6 weeks from today!)
From: John W. Linville @ 2013-08-08 19:04 UTC (permalink / raw)
To: linux-wireless
Cc: johannes, marcel, Samuel Ortiz, Gustavo Padovan, linux-bluetooth,
linux-nfc
In-Reply-To: <20130808185410.GD30925@tuxdriver.com>
Sorry, forgot to copy linux-bluetooth and linux-nfc...
On Thu, Aug 08, 2013 at 02:54:11PM -0400, John W. Linville wrote:
> Greetings!
>
> This is a reminder that we will have a Linux Wireless Mini-Summit in
> New Orleans this year on 19-20 September. This will immediately follow
> LinuxCon and will run concurrently with Linux Plumber's Conference.
> This event includes Linux developers for wireless LAN (802.11),
> Bluetooth, and NFC technologies. Both kernel and userland developers
> are welcomed and heartily encouraged to attend!
>
> http://wireless.kernel.org/en/developers/Summits/New-Orleans-2013
>
> The link above is a Wiki. We are using it to collect discussion
> topics and to negotiate agenda/scheduling options for the event.
> Please go there to record your intent to attend the event and to
> propopse topics for discussion.
>
> Please be aware that in order to attend the event above one must
> register for either LinuxCon or for Linux Plumbers Conference.
> Act now, before those events fill-up and close their registrations!
>
> We are allotted one "large" room (up to ~80 people "theater style"), and
> two "small" rooms (up to ~25 people) for this event. Based on history
> and the numbers of contributors, the larger room will primarily be
> for the 802.11 discussions and any "plenary" topics while the smaller
> rooms will be for Bluetooth, NFC, and any "breakout" topics.
>
> So...thoughts? Topics to discuss?
>
> John
> --
> John W. Linville Someday the world will need a hero, and you
> linville@tuxdriver.com might be all we have. Be ready.
> --
> To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
--
John W. Linville Someday the world will need a hero, and you
linville@tuxdriver.com might be all we have. Be ready.
^ permalink raw reply
* [PATCH BlueZ 3/3] client/transfer: Add proper message to errors
From: Luiz Augusto von Dentz @ 2013-08-08 13:49 UTC (permalink / raw)
To: linux-bluetooth
In-Reply-To: <1375969749-2097-1-git-send-email-luiz.dentz@gmail.com>
From: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
This improve the error message when a transfer fails by using
g_obex_strerror to decode the response code to a human readable string.
---
obexd/client/transfer.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/obexd/client/transfer.c b/obexd/client/transfer.c
index 4b1def3..2e8f7c7 100644
--- a/obexd/client/transfer.c
+++ b/obexd/client/transfer.c
@@ -596,8 +596,8 @@ static void get_xfer_progress_first(GObex *obex, GError *err, GObexPacket *rsp,
rspcode = g_obex_packet_get_operation(rsp, &final);
if (rspcode != G_OBEX_RSP_SUCCESS && rspcode != G_OBEX_RSP_CONTINUE) {
- err = g_error_new(OBC_TRANSFER_ERROR, rspcode,
- "Transfer failed (0x%02x)", rspcode);
+ err = g_error_new(OBC_TRANSFER_ERROR, rspcode, "%s",
+ g_obex_strerror(rspcode));
xfer_complete(obex, err, transfer);
g_error_free(err);
return;
--
1.8.3.1
^ permalink raw reply related
* [PATCH BlueZ 2/3] gobex: Make PUT request with just filler byte to set the final bit
From: Luiz Augusto von Dentz @ 2013-08-08 13:49 UTC (permalink / raw)
To: linux-bluetooth
In-Reply-To: <1375969749-2097-1-git-send-email-luiz.dentz@gmail.com>
From: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
This make PUT request with just filler byte 0x30 to be treated as there
is no data and thus avoid an extra packet to be sent.
Some profiles such as MAP use this to workaround PUT being interpreted as
a delete request:
"5.7.5 Body/EndOfBody
To avoid PUT with empty Body leading to a 'delete' of the related
message these headers shall contain a filler byte. The value of this
byte shall be set to 0x30 (="0")."
Future PIM related specs in development also seems to be following the
use of filler byte.
---
gobex/gobex-packet.c | 14 ++++++++++----
1 file changed, 10 insertions(+), 4 deletions(-)
diff --git a/gobex/gobex-packet.c b/gobex/gobex-packet.c
index 4c14cf7..96f8c76 100644
--- a/gobex/gobex-packet.c
+++ b/gobex/gobex-packet.c
@@ -387,9 +387,15 @@ static gssize get_body(GObexPacket *pkt, guint8 *buf, gsize len)
if (ret < 0)
return ret;
- if (ret > 0)
- buf[0] = G_OBEX_HDR_BODY;
- else
+ if (ret > 0) {
+ /* To avoid PUT with empty Body leading to a 'delete' some
+ * transfer may use a filler byte of 0x30 (="0").
+ */
+ if (ret == 2 && strcmp((char *) buf + 3, "0") == 0)
+ buf[0] = G_OBEX_HDR_BODY_END;
+ else
+ buf[0] = G_OBEX_HDR_BODY;
+ } else
buf[0] = G_OBEX_HDR_BODY_END;
u16 = g_htons(ret + 3);
@@ -440,7 +446,7 @@ gssize g_obex_packet_encode(GObexPacket *pkt, guint8 *buf, gsize len)
ret = get_body(pkt, buf + count, len - count);
if (ret < 0)
return ret;
- if (ret == 0) {
+ if (ret == 0 || buf[count] == G_OBEX_HDR_BODY_END) {
if (pkt->opcode == G_OBEX_RSP_CONTINUE)
buf[0] = G_OBEX_RSP_SUCCESS;
buf[0] |= FINAL_BIT;
--
1.8.3.1
^ permalink raw reply related
* [PATCH BlueZ 1/3] gobex: Add proper message to transfer errors
From: Luiz Augusto von Dentz @ 2013-08-08 13:49 UTC (permalink / raw)
To: linux-bluetooth
From: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
This improve the error message when a transfer fails by using
g_obex_strerror to decode the response code to a human readable string.
---
gobex/gobex-transfer.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/gobex/gobex-transfer.c b/gobex/gobex-transfer.c
index ac8836c..4203fec 100644
--- a/gobex/gobex-transfer.c
+++ b/gobex/gobex-transfer.c
@@ -207,8 +207,8 @@ static void transfer_response(GObex *obex, GError *err, GObexPacket *rsp,
rspcode = g_obex_packet_get_operation(rsp, &final);
if (rspcode != G_OBEX_RSP_SUCCESS && rspcode != G_OBEX_RSP_CONTINUE) {
- err = g_error_new(G_OBEX_ERROR, rspcode,
- "Transfer failed (0x%02x)", rspcode);
+ err = g_error_new(G_OBEX_ERROR, rspcode, "%s",
+ g_obex_strerror(rspcode));
goto failed;
}
--
1.8.3.1
^ permalink raw reply related
* Re: Gatt Thermometer Server Support
From: Anderson Lizardo @ 2013-08-08 13:00 UTC (permalink / raw)
To: ajay.kv; +Cc: linux-bluetooth
In-Reply-To: <41942.172.16.2.1.1375965758.squirrel@gesmail.globaledgesoft.com>
Hi AJay,
On Thu, Aug 8, 2013 at 8:42 AM, <ajay.kv@globaledgesoft.com> wrote:
> Here we could not find the UUID for Thermometer(1809) and heartrate ,
> which we are interested to debug more.
>
> Query:
> How to set the dummy temperature or heartrate values in the server and
> to get them in the Client.?
Unfortunately, the Thermometer role (i.e. "Server") is not supported
in BlueZ. You can only connect and read measurements from other
thermometers. Same applies to Heart Rate Profile.
Best Regards,
--
Anderson Lizardo
Instituto Nokia de Tecnologia - INdT
Manaus - Brazil
^ permalink raw reply
* Re: using the DBus profiles in BlueZ 5
From: Anderson Lizardo @ 2013-08-08 12:54 UTC (permalink / raw)
To: James Baker; +Cc: linux-bluetooth
In-Reply-To: <CAGoJ=AsiXm7=-0rK2Wm6k+DY85wDoM2WN-eCT8qFpm+sy2B62w@mail.gmail.com>
Hi James,
On Wed, Aug 7, 2013 at 10:21 AM, James Baker <j.baker@outlook.com> wrote:
> What I've done (beyond compile 5.7 with the experimental additions):
> Set systemd to launch with the argument -E in order to enable
> experimental profiles (as mentioned in
> https://gitorious.org/~moreira/bluez-le-docs/moreira-bluez-le-docs/blobs/master/bluez-le-howto.tex)
Note that this document, although mostly applicable to BlueZ 5, was
written to showcase an experimental API that is not upstream yet (and
that's why it is in our development trees as we have not published it
yet). In any case, it is not relevant to using the HeartRate API,
which works on latest BlueZ just fine (from my experience).
> Launched d-feet and navigated to org.bluez. Found hci0, enabled
> discovery. Waited to discover the correct device. Connected to the
> device.
> No heartrate information has been presented, and it is seemingly not
> present in the whole of the object tree.
I suggest you take a look on the example Python code: test/test-heartrate
You need to register a agent to receive heart rate measurements, and
this cannot be done with d-feet.
> Executing /test/test-heartrate results in an error such as
> org.freedesktop.DBus.Error.UnknownMethod "RegsterWatcher" with
> signature "s" on interface "org.bluez.HeartRateManager" doesn't exist.
Can you paste the exact error message? The snippet above contains two
typos which I'm not sure if it was on the original error or not:
* RegsterWatcher -> RegisterWatcher
* org.bluez.HeartRateManager -> org.bluez.HeartRateManager1
Make sure the test-heartrate you are using matches the BlueZ version
which is running.
> Does anyone know of anything I've missed? I've been reading the docs
> and they imply the service should have been registered when I
> connected.
>
> The device is definitely exposing itself as a heart rate monitor; I've
> checked with the Bluetooth SIG assigned numbers.
Can you send the raw HCI dump (using "btmon -w btmon.dump" and
attaching the generated *.dump file) from the connection up to when
you try to run test/test-heartrate?
Best Regards,
--
Anderson Lizardo
Instituto Nokia de Tecnologia - INdT
Manaus - Brazil
^ permalink raw reply
* Gatt Thermometer Server Support
From: ajay.kv @ 2013-08-08 12:42 UTC (permalink / raw)
To: linux-bluetooth; +Cc: anderson.lizardo
Hi,
As i am experimenting the BlueZ BLE features. I have some query. I am
using 2 Linux Ubuntu 12.04 Desktop with linux-3.10 kernel and Bluez-5.7
configured with #./configure --enable-experimental
Server_System:
Enabled ThermometerManager->RegisterWatcher (d-feet
application).
#hciconfig 0 leadv
Client_System:
#gatttool -I
[ ][LE]>
[00:02:72:D6:97:79][LE]> connect 00:02:72:D6:97:79
Attempting to connect to 00:02:72:D6:97:79
Connection successful
[00:02:72:D6:97:79][LE]> primary
attr handle: 0x0001, end grp handle: 0x0008 uuid:
00001800-0000-1000-8000-00805f9b34fb
attr handle: 0x0009, end grp handle: 0x000b uuid:
00001803-0000-1000-8000-00805f9b34fb
attr handle: 0x000c, end grp handle: 0x000f uuid:
00001804-0000-1000-8000-00805f9b34fb
attr handle: 0x0010, end grp handle: 0x0010 uuid:
00001801-0000-1000-8000-00805f9b34fb
attr handle: 0x0011, end grp handle: 0x0013 uuid:
00001802-0000-1000-8000-00805f9b34fb
attr handle: 0x0014, end grp handle: 0x0019 uuid:
00001805-0000-1000-8000-00805f9b34fb
attr handle: 0x001a, end grp handle: 0x001e uuid:
00001806-0000-1000-8000-00805f9b34fb
attr handle: 0x001f, end grp handle: 0x0027 uuid:
0000180e-0000-1000-8000-00805f9b34fb
attr handle: 0x0028, end grp handle: 0x0034 uuid:
00001811-0000-1000-8000-00805f9b34fb
Here we could not find the UUID for Thermometer(1809) and heartrate ,
which we are interested to debug more.
Query:
How to set the dummy temperature or heartrate values in the server and
to get them in the Client.?
Thanks in Advance,
Ajay K V
^ permalink raw reply
* [PATCH] Bluetooth: Fix getting SCO socket options in deferred state
From: johan.hedberg @ 2013-08-08 11:53 UTC (permalink / raw)
To: linux-bluetooth
From: Johan Hedberg <johan.hedberg@intel.com>
When a socket is in deferred state there does actually exist an
underlying connection even though the connection state is not yet
BT_CONNECTED. In the deferred state it should therefore be allowed to
get socket options that usually depend on a connection, such as
SCO_OPTIONS and SCO_CONNINFO.
This patch fixes the behavior of some user space code that behaves as
follows without it:
$ sudo tools/btiotest -i 00:1B:DC:xx:xx:xx -d -s
accept=2 reject=-1 discon=-1 defer=1 sec=0 update_sec=0 prio=0 voice=0x0000
Listening for SCO connections
bt_io_get(OPT_DEST): getsockopt(SCO_OPTIONS): Transport endpoint is not connected (107)
Accepting connection
Successfully connected to 60:D8:19:xx:xx:xx. handle=43, class=000000
The conditions that the patch updates the if-statements to is taken from
similar code in l2cap_sock.c which correctly handles the deferred state.
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
---
net/bluetooth/sco.c | 8 ++++++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/net/bluetooth/sco.c b/net/bluetooth/sco.c
index 1170b6e..96bd388 100644
--- a/net/bluetooth/sco.c
+++ b/net/bluetooth/sco.c
@@ -806,7 +806,9 @@ static int sco_sock_getsockopt_old(struct socket *sock, int optname, char __user
switch (optname) {
case SCO_OPTIONS:
- if (sk->sk_state != BT_CONNECTED) {
+ if (sk->sk_state != BT_CONNECTED &&
+ !(sk->sk_state == BT_CONNECT2 &&
+ test_bit(BT_SK_DEFER_SETUP, &bt_sk(sk)->flags))) {
err = -ENOTCONN;
break;
}
@@ -822,7 +824,9 @@ static int sco_sock_getsockopt_old(struct socket *sock, int optname, char __user
break;
case SCO_CONNINFO:
- if (sk->sk_state != BT_CONNECTED) {
+ if (sk->sk_state != BT_CONNECTED &&
+ !(sk->sk_state == BT_CONNECT2 &&
+ test_bit(BT_SK_DEFER_SETUP, &bt_sk(sk)->flags))) {
err = -ENOTCONN;
break;
}
--
1.8.3.1
^ permalink raw reply related
* Re: fail to configure and compile the source of bluez-5.7
From: atar @ 2013-08-08 8:29 UTC (permalink / raw)
To: aji.kumar; +Cc: linux-bluetooth@vger.kernel.org
In-Reply-To: <558B77349A98DB438591B5FD93003409263E702B@048-CH1MPN1-141.048d.mgd.msft.net>
> Hi Atar,
>
>> -----Original Message-----
>> From: linux-bluetooth-owner@vger.kernel.org [mailto:linux-bluetooth-
>> owner@vger.kernel.org] On Behalf Of atar
>> Sent: Wednesday, August 07, 2013 10:06 AM
>> To: linux-bluetooth@vger.kernel.org
>> Subject: fail to configure and compile the source of bluez-5.7
>>
>> Hi there!!
>>
>> My machine is running Debian Wheezy from the live-boot Debian project
>> which
>> is installed on my USB stick.
>>
>> I've downloaded from bluez.org the source of the 5.7 package but when I
>> ran
>> ./configure on it, it emitted an error message at the bottom of all the
>> messages
>> saying:
>>
>> > "checking for GLIB... no
>> > configure: error: GLib >= 2.28 is required"
>>
>> This, although I've the glib libraries installed.
>>
>> How can this problem be solved?
>>
>
> Check the version of the glib library installed, you could use
> "apt-cache show <glib>"
>
> If you need to know the actual package name for glib, do "apt-cache
> search glib" and find out the right package, you could replace that in
> the above line.
>
> If version installed is less than required, you will have to install the
> later versions, the corresponding glib images can be downloaded from
> Ubuntu repositories...
>
>> Thanks in advance!!
>>
>> atar.
>> --
>> To unsubscribe from this list: send the line "unsubscribe
>> linux-bluetooth" in the
>> body of a message to majordomo@vger.kernel.org More majordomo info at
>> http://vger.kernel.org/majordomo-info.html
>
>
> This message is for the designated recipient only and may contain
> privileged, proprietary, or otherwise confidential information. If you
> have received it in error, please notify the sender immediately and
> delete the original. Any other use of the e-mail by you is prohibited.
>
> Where allowed by local law, electronic communications with Accenture and
> its affiliates, including e-mail and instant messaging (including
> content), may be scanned by our systems for the purposes of information
> security and assessment of internal compliance with Accenture policy.
>
> ______________________________________________________________________________________
>
> www.accenture.com
Hi Kumar!
the command 'apt-cache search glib' produces a lot of output. I can't
figure out which line is really related to the glib library in question.
please help.
Thanks in advance!!
atar.
^ permalink raw reply
* using the DBus profiles in BlueZ 5
From: James Baker @ 2013-08-07 14:21 UTC (permalink / raw)
To: linux-bluetooth
I'm using the DBus api in order to attempt to communicating with a Ble
device. This device can masquerade as (among others) a heart rate
monitor or a health thermometer. I'm trying to get BlueZ to detect
this device as being either a heart rate monitor or a health
thermometer (depending on which is flashed).
What I've done (beyond compile 5.7 with the experimental additions):
Set systemd to launch with the argument -E in order to enable
experimental profiles (as mentioned in
https://gitorious.org/~moreira/bluez-le-docs/moreira-bluez-le-docs/blobs/master/bluez-le-howto.tex)
Launched d-feet and navigated to org.bluez. Found hci0, enabled
discovery. Waited to discover the correct device. Connected to the
device.
No heartrate information has been presented, and it is seemingly not
present in the whole of the object tree.
Executing /test/test-heartrate results in an error such as
org.freedesktop.DBus.Error.UnknownMethod "RegsterWatcher" with
signature "s" on interface "org.bluez.HeartRateManager" doesn't exist.
Does anyone know of anything I've missed? I've been reading the docs
and they imply the service should have been registered when I
connected.
The device is definitely exposing itself as a heart rate monitor; I've
checked with the Bluetooth SIG assigned numbers.
James
^ permalink raw reply
* Re: [RFC 0/1] MAP Notification API
From: Luiz Augusto von Dentz @ 2013-08-07 9:15 UTC (permalink / raw)
To: Christian Fetzer; +Cc: linux-bluetooth@vger.kernel.org
In-Reply-To: <CABBYNZJSE_TRBr9YGQEUfncuu5hNNTebz43uxyxgF2WcNLGAKg@mail.gmail.com>
Hi Christian,
On Fri, Jul 12, 2013 at 11:23 AM, Luiz Augusto von Dentz
<luiz.dentz@gmail.com> wrote:
> Hi Christian,
>
> On Fri, Jul 12, 2013 at 11:02 AM, Christian Fetzer
> <christian.fetzer@oss.bmw-carit.de> wrote:
>> Hi Luiz,
>>
>> On 07/10/2013 10:56 AM, Luiz Augusto von Dentz wrote:
>>> Hi Christian,
>>>
>>> On Mon, Jun 24, 2013 at 10:56 AM, Christian Fetzer
>>> <christian.fetzer@oss.bmw-carit.de> wrote:
>>>> From: Christian Fetzer <christian.fetzer@bmw-carit.de>
>>>>
>>>> Now that the MAP MNS support is progressing, I'd like to start the discussion
>>>> on how the MAP event reports should be signaled in the D-Bus API.
>>>>
>>>> I've listed therefore the 9 different event types and the parameters that we
>>>> get from the remote device, together with a proposal on how the API could look
>>>> like.
>>>>
>>>>
>>>> Prerequisite:
>>>>
>>>> The current existing MAP client relies on the fact that the application tracks
>>>> the folder a message belongs to. Since notifications can be received for any
>>>> folder, it would make sense to remove this restriction and provide a 'Folder'
>>>> property for the Message interface. This is needed for the NewMessage,
>>>> MessageDeleted, and MessageShift event.
>>>>
>>>>
>>>> Events:
>>>>
>>>> NewMessage(handle, folder, msg_type):
>>>> - New messages can be signaled by registering a corresponding Message
>>>> interface, that would be announced using the ObjectManager.
>>>> - Since we do not get any meta data, it would make sense to implicitly query
>>>> this information using GetMessagesListing with MaxListCount=1.
>>>> That way, the application would not have to query this data explicitly and
>>>> we would not expose an empty message with no properties set.
>>>
>>> Sound good to me.
>>>
>>>> DeliverySuccess,SendingSuccess,DeliveryFailure,
>>>> SendingFailure(handle, folder, msg_type):
>>>> - This events are only relevant when sending messages (PushMessage).
>>>> Therefore, I'd suggest to register the Message interface already in
>>>> PushMessage for the outgoing message and add a SendingStatus property
>>>> when we receive this events.
>>>
>>> I wonder how this is actually implemented, is there a NewMessage event
>>> when using PushMessage? If yes does it indicates Sent flag or we
>>> should listen to this event and notified when it is sent, anyway the
>>> event doesn't give us detailed error so perhaps we could just set
>>> Status to error or something like that, adding another status would be
>>> confusing IMO.
>>>
>>
>> According to the spec, it should be implemented like this:
>> - The client sends the PushMessage request
>> - In the response, the server sets the OBEX Name parameter of the last
>> response packet to the handle that this message gets on the server.
>> - The server will try to send the message and will inform the client
>> about the status using above notifications. This usually takes some
>> seconds (or longer, especially when the reception is bad).
>>
>> MCE MSE
>> | --- PushMessage_Req ---------------> |
>> | <-- PushMessage_Res(Name=handle) --- |
>> ...
>> MSE tries to deliver message
>> ...
>> | <-- Status event report ------------ |
>>
>> Note that the type of notification also depend on the network.
>> Sometimes, the operator accepts all messages (and you only get
>> SendingSuccess notifications). In error cases, you receive a SMS,
>> saying that the delivery failed. In this case you get a NewMessage
>> notification (but only plain text, no status codes).
>
> So if I understand you correctly the NewMessage is only generated when
> the message is sent, in that case we should probably create the
> message object with the response as you said.
>
>> The idea was, to then register the new message's D-Bus interface
>> as soon as we have transfered the message to the phone (when we received
>> the handle in PushMessage_Res). Later, when we receive
>> a status notification, we update a property in the message.
>> The Status property could be reused as well here if you don't want a
>> dedicated property. Does that make sense for you?
>
> The Status should be used as the status of the message not only for
> receiving status, for direction we have the Sent property. We should
> always try to keep the API as simple as possible so there is less risk
> we need to break APIs, adding those latter is possible but I don't
> think it will the case here.
>
>> I've done some tests with a BB Z10 to verify that the described
>> behavior is correct. (see below for a trace)
>>
>>>> MemoryFull, MemoryAvailable():
>>>> - Add MemoryAvailable property in MessageAccess interface.
>>>
>>> It is not very clear how we would use this? Do you actually have any
>>> stack generating these events? Anyway we could also handle it
>>> internally and do not send any data upon receiving MemoryFull, anyway
>>> lets think about it latter.
>>>
>>
>> I don't think we have to 'handle' anything in case of MemoryFull.
>> This is just an indication for the application/UI that you will
>> not be able to receive / send any new messages.
>
> Lets concentrate on the other events we can come back to this latter.
Anything coming from your side anything soon or are you waiting some feedback?
--
Luiz Augusto von Dentz
^ permalink raw reply
* fail to configure and compile the source of bluez-5.7
From: atar @ 2013-08-07 4:36 UTC (permalink / raw)
To: linux-bluetooth
Hi there!!
My machine is running Debian Wheezy from the live-boot Debian project
which is installed on my USB stick.
I've downloaded from bluez.org the source of the 5.7 package but when I
ran ./configure on it, it emitted an error message at the bottom of all
the messages saying:
> "checking for GLIB... no
> configure: error: GLib >= 2.28 is required"
This, although I've the glib libraries installed.
How can this problem be solved?
Thanks in advance!!
atar.
^ 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