* Re: [PATCH 3/4] HCI command to read size of LE White List
From: Anderson Lizardo @ 2011-01-24 11:47 UTC (permalink / raw)
To: Sumit Kumar BAJPAI; +Cc: linux-bluetooth@vger.kernel.org
In-Reply-To: <4765B7BC10CB4C488A56C73E15D6FBA31DA570022B@EXDCVYMBSTM005.EQ1STM.local>
Hi,
On Mon, Jan 24, 2011 at 5:59 AM, Sumit Kumar BAJPAI
<sumitkumar.bajpai@stericsson.com> wrote:
> ---
> lib/hci.c | 28 ++++++++++++++++++++++++++++
> lib/hci_lib.h | 1 +
> tools/hcitool.c | 41 +++++++++++++++++++++++++++++++++++++++++
> 3 files changed, 70 insertions(+), 0 deletions(-)
>
> diff --git a/lib/hci.c b/lib/hci.c
> index 11b47b3..ec8d48e 100755
> --- a/lib/hci.c
> +++ b/lib/hci.c
> @@ -1349,6 +1349,34 @@ int hci_le_remove_from_white_list(int dd, const bdaddr_t* bdaddr, uint8_t type)
> return 0;
> }
>
> +int hci_le_read_white_list_size(int dd, int* size)
int* size -> int *size
(No C++ style declarations)
> +{
> + struct hci_request rq;
> + le_read_white_list_size_rp rp;
> +
> + memset(&rp, 0, sizeof(rp));
> + rp.size=0;
Missing whitespace around "=".
> +
> + memset(&rq, 0, sizeof(rq));
> + rq.ogf = OGF_LE_CTL;
> + rq.ocf = OCF_LE_READ_WHITE_LIST_SIZE;
> + rq.rparam = &rp;
> + rq.rlen = LE_READ_WHITE_LIST_SIZE_RP_SIZE;
> +
> + if (hci_send_req(dd, &rq, 1000) < 0)
> + return -1;
> +
> + if (rp.status) {
> + errno = EIO;
> + return -1;
> + }
> +
> + if(size)
> + *size=rp.size;
Missing whitespace before "(".
Missing whitespace around "="
> +
> + return 0;
> +}
> +
> int hci_read_local_name(int dd, int len, char *name, int to)
> {
> read_local_name_rp rp;
> diff --git a/lib/hci_lib.h b/lib/hci_lib.h
> index e64a431..f0325b2 100755
> --- a/lib/hci_lib.h
> +++ b/lib/hci_lib.h
> @@ -129,6 +129,7 @@ int hci_le_create_conn(int dd, uint16_t interval, uint16_t window,
> uint16_t *handle, int to);
> int hci_le_add_to_white_list(int dd, const bdaddr_t* bdaddr, uint8_t type);
> int hci_le_remove_from_white_list(int dd, const bdaddr_t* bdaddr, uint8_t type);
> +int hci_le_read_white_list_size(int dd, int* size);
int* size -> int *size
>
> int hci_for_each_dev(int flag, int(*func)(int dd, int dev_id, long arg), long arg);
> int hci_get_route(bdaddr_t *bdaddr);
> diff --git a/tools/hcitool.c b/tools/hcitool.c
> index 038d05e..e80c7a3 100755
> --- a/tools/hcitool.c
> +++ b/tools/hcitool.c
> @@ -2563,6 +2563,46 @@ static void cmd_lermwl(int dev_id, int argc, char **argv)
> }
> }
>
> +static struct option lerdwlsz_options[] = {
> + { "help", 0, 0, 'h' },
> + { 0, 0, 0, 0 }
> +};
> +
> +static const char *lerdwlsz_help =
> + "Usage:\n"
> + "\tlerdwlsz\n";
> +
> +static void cmd_lerdwlsz(int dev_id, int argc, char **argv)
> +{
> + int err, dd, opt, size;
> +
> + for_each_opt(opt, lerdwlsz_options, NULL) {
> + switch (opt) {
> + default:
> + printf("%s", lerdwlsz_help);
> + return;
> + }
> + }
> + helper_arg(0, 0, &argc, &argv, lermwl_help);
> +
> + if (dev_id < 0)
> + dev_id = hci_get_route(NULL);
> +
> + dd = hci_open_dev(dev_id);
> + if (dd < 0) {
> + perror("Could not open device");
> + exit(1);
> + }
> +
> + err = hci_le_read_white_list_size(dd, &size);
> + hci_close_dev(dd);
> +
> + if (err < 0) {
> + perror("Cant read white list size");
> + exit(1);
> + }
> +}
> +
> static struct option ledc_options[] = {
> { "help", 0, 0, 'h' },
> { 0, 0, 0, 0 }
> @@ -2641,6 +2681,7 @@ static struct {
> { "lescan", cmd_lescan, "Start LE scan" },
> { "leaddwl", cmd_leaddwl, "Add this device to white list" },
> { "lermwl", cmd_lermwl, "Remove this device from white list" },
> + { "lerdwlsz", cmd_lerdwlsz, "Read white list size" },
> { "lecc", cmd_lecc, "Create a LE Connection", },
> { "ledc", cmd_ledc, "Disconnect a LE Connection", },
> { NULL, NULL, 0 }
> --
> 1.6.5
> --
> 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
>
--
Anderson Lizardo
OpenBossa Labs - INdT
Manaus - Brazil
^ permalink raw reply
* Re: [PATCH 2/4] HCI command to remove device from LE White List
From: Anderson Lizardo @ 2011-01-24 11:42 UTC (permalink / raw)
To: Sumit Kumar BAJPAI; +Cc: linux-bluetooth@vger.kernel.org
In-Reply-To: <4765B7BC10CB4C488A56C73E15D6FBA31DA5700224@EXDCVYMBSTM005.EQ1STM.local>
Hi,
On Mon, Jan 24, 2011 at 5:58 AM, Sumit Kumar BAJPAI
<sumitkumar.bajpai@stericsson.com> wrote:
> ---
> lib/hci.c | 29 +++++++++++++++++++++++++++++
> lib/hci_lib.h | 1 +
> tools/hcitool.c | 47 +++++++++++++++++++++++++++++++++++++++++++++++
> 3 files changed, 77 insertions(+), 0 deletions(-)
>
> diff --git a/lib/hci.c b/lib/hci.c
> index b75f612..11b47b3 100755
> --- a/lib/hci.c
> +++ b/lib/hci.c
> @@ -1320,6 +1320,35 @@ int hci_le_add_to_white_list(int dd, const bdaddr_t* bdaddr, uint8_t type)
> return 0;
> }
>
> +int hci_le_remove_from_white_list(int dd, const bdaddr_t* bdaddr, uint8_t type)
Coding style issue:
bdaddr_t* bdaddr -> bdaddr_t *bdaddr
(no C++ style declarations)
> +{
> + struct hci_request rq;
> + le_remove_device_from_white_list_cp cp;
> + uint8_t status;
> +
> + memset(&cp, 0, sizeof(cp));
> + cp.bdaddr_type = type;
> + bacpy(&cp.bdaddr,bdaddr);
bacpy(&cp.bdaddr,bdaddr); -> bacpy(&cp.bdaddr, bdaddr);
(missing whitespace after comma)
> +
> + memset(&rq, 0, sizeof(rq));
> + rq.ogf = OGF_LE_CTL;
> + rq.ocf = OCF_LE_REMOVE_DEVICE_FROM_WHITE_LIST;
> + rq.cparam = &cp;
> + rq.clen = LE_REMOVE_DEVICE_FROM_WHITE_LIST_CP_SIZE;
> + rq.rparam = &status;
> + rq.rlen = 1;
> +
> + if (hci_send_req(dd, &rq, 1000) < 0)
> + return -1;
> +
> + if (status) {
> + errno = EIO;
> + return -1;
> + }
> +
> + return 0;
> +}
> +
> int hci_read_local_name(int dd, int len, char *name, int to)
> {
> read_local_name_rp rp;
> diff --git a/lib/hci_lib.h b/lib/hci_lib.h
> index dd995dd..e64a431 100755
> --- a/lib/hci_lib.h
> +++ b/lib/hci_lib.h
> @@ -128,6 +128,7 @@ int hci_le_create_conn(int dd, uint16_t interval, uint16_t window,
> uint16_t min_ce_length, uint16_t max_ce_length,
> uint16_t *handle, int to);
> int hci_le_add_to_white_list(int dd, const bdaddr_t* bdaddr, uint8_t type);
> +int hci_le_remove_from_white_list(int dd, const bdaddr_t* bdaddr, uint8_t type);
bdaddr_t* bdaddr -> bdaddr_t *bdaddr
>
> int hci_for_each_dev(int flag, int(*func)(int dd, int dev_id, long arg), long arg);
> int hci_get_route(bdaddr_t *bdaddr);
> diff --git a/tools/hcitool.c b/tools/hcitool.c
> index 9147995..038d05e 100755
> --- a/tools/hcitool.c
> +++ b/tools/hcitool.c
> @@ -2517,6 +2517,52 @@ static void cmd_leaddwl(int dev_id, int argc, char **argv)
> }
> }
>
> +static struct option lermwl_options[] = {
> + { "help", 0, 0, 'h' },
> + { 0, 0, 0, 0 }
> +};
> +
> +static const char *lermwl_help =
> + "Usage:\n"
> + "\tlermwl <bdaddr>\n";
> +
> +static void cmd_lermwl(int dev_id, int argc, char **argv)
> +{
> + int err, opt, dd;
> + bdaddr_t bdaddr;
> + le_device_addr_type bdaddr_type;
> +
> + for_each_opt(opt, lermwl_options, NULL) {
> + switch (opt) {
> + default:
> + printf("%s", lermwl_help);
> + return;
> + }
> + }
> +
> + helper_arg(1, 1, &argc, &argv, lermwl_help);
> +
> + if (dev_id < 0)
> + dev_id = hci_get_route(NULL);
> +
> + dd = hci_open_dev(dev_id);
> + if (dd < 0) {
> + perror("Could not open device");
> + exit(1);
> + }
> +
> + str2ba(argv[0], &bdaddr);
> + bdaddr_type = LE_PUBLIC_DEVICE_ADDR;
> +
> + err = hci_le_remove_from_white_list(dd, &bdaddr, bdaddr_type);
> + hci_close_dev(dd);
> +
> + if (err < 0) {
> + perror("Cant remove from white list");
> + exit(1);
> + }
> +}
> +
> static struct option ledc_options[] = {
> { "help", 0, 0, 'h' },
> { 0, 0, 0, 0 }
> @@ -2594,6 +2640,7 @@ static struct {
> { "clock", cmd_clock, "Read local or remote clock" },
> { "lescan", cmd_lescan, "Start LE scan" },
> { "leaddwl", cmd_leaddwl, "Add this device to white list" },
> + { "lermwl", cmd_lermwl, "Remove this device from white list" },
> { "lecc", cmd_lecc, "Create a LE Connection", },
> { "ledc", cmd_ledc, "Disconnect a LE Connection", },
> { NULL, NULL, 0 }
> --
> 1.6.5
> --
> 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
>
--
Anderson Lizardo
OpenBossa Labs - INdT
Manaus - Brazil
^ permalink raw reply
* [PATCH 4/4] HCI command to clear LE White List
From: Sumit Kumar BAJPAI @ 2011-01-24 9:59 UTC (permalink / raw)
To: linux-bluetooth@vger.kernel.org
---
lib/hci.c | 22 ++++++++++++++++++++++
lib/hci_lib.h | 1 +
tools/hcitool.c | 42 ++++++++++++++++++++++++++++++++++++++++++
3 files changed, 65 insertions(+), 0 deletions(-)
diff --git a/lib/hci.c b/lib/hci.c
index ec8d48e..71a96ea 100755
--- a/lib/hci.c
+++ b/lib/hci.c
@@ -1377,6 +1377,28 @@ int hci_le_read_white_list_size(int dd, int* size)
return 0;
}
+int hci_le_clear_white_list(int dd)
+{
+ struct hci_request rq;
+ uint8_t status;
+
+ memset(&rq, 0, sizeof(rq));
+ rq.ogf = OGF_LE_CTL;
+ rq.ocf = OCF_LE_CLEAR_WHITE_LIST;
+ rq.rparam = &status;
+ rq.rlen = 1;
+
+ if (hci_send_req(dd, &rq, 1000) < 0)
+ return -1;
+
+ if (status) {
+ errno = EIO;
+ return -1;
+ }
+
+ return 0;
+}
+
int hci_read_local_name(int dd, int len, char *name, int to)
{
read_local_name_rp rp;
diff --git a/lib/hci_lib.h b/lib/hci_lib.h
index f0325b2..718e8a6 100755
--- a/lib/hci_lib.h
+++ b/lib/hci_lib.h
@@ -130,6 +130,7 @@ int hci_le_create_conn(int dd, uint16_t interval, uint16_t window,
int hci_le_add_to_white_list(int dd, const bdaddr_t* bdaddr, uint8_t type);
int hci_le_remove_from_white_list(int dd, const bdaddr_t* bdaddr, uint8_t type);
int hci_le_read_white_list_size(int dd, int* size);
+int hci_le_clear_white_list(int dd);
int hci_for_each_dev(int flag, int(*func)(int dd, int dev_id, long arg), long arg);
int hci_get_route(bdaddr_t *bdaddr);
diff --git a/tools/hcitool.c b/tools/hcitool.c
index e80c7a3..f29bb47 100755
--- a/tools/hcitool.c
+++ b/tools/hcitool.c
@@ -2603,6 +2603,47 @@ static void cmd_lerdwlsz(int dev_id, int argc, char **argv)
}
}
+static struct option leclrwl_options[] = {
+ { "help", 0, 0, 'h' },
+ { 0, 0, 0, 0 }
+};
+
+static const char *leclrwl_help =
+ "Usage:\n"
+ "\tleclrwl\n";
+
+static void cmd_leclrwl(int dev_id, int argc, char **argv)
+{
+ int err, dd, opt;
+
+ for_each_opt(opt, leclrwl_options, NULL) {
+ switch (opt) {
+ default:
+ printf("%s", leclrwl_help);
+ return;
+ }
+ }
+
+ helper_arg(0, 0, &argc, &argv, leclrwl_help);
+
+ if (dev_id < 0)
+ dev_id = hci_get_route(NULL);
+
+ dd = hci_open_dev(dev_id);
+ if (dd < 0) {
+ perror("Could not open device");
+ exit(1);
+ }
+
+ err = hci_le_clear_white_list(dd);
+ hci_close_dev(dd);
+
+ if (err < 0) {
+ perror("Cant clear white list");
+ exit(1);
+ }
+}
+
static struct option ledc_options[] = {
{ "help", 0, 0, 'h' },
{ 0, 0, 0, 0 }
@@ -2682,6 +2723,7 @@ static struct {
{ "leaddwl", cmd_leaddwl, "Add this device to white list" },
{ "lermwl", cmd_lermwl, "Remove this device from white list" },
{ "lerdwlsz", cmd_lerdwlsz, "Read white list size" },
+ { "leclrwl", cmd_leclrwl, "Clear white list" },
{ "lecc", cmd_lecc, "Create a LE Connection", },
{ "ledc", cmd_ledc, "Disconnect a LE Connection", },
{ NULL, NULL, 0 }
--
1.6.5
^ permalink raw reply related
* [PATCH 3/4] HCI command to read size of LE White List
From: Sumit Kumar BAJPAI @ 2011-01-24 9:59 UTC (permalink / raw)
To: linux-bluetooth@vger.kernel.org
---
lib/hci.c | 28 ++++++++++++++++++++++++++++
lib/hci_lib.h | 1 +
tools/hcitool.c | 41 +++++++++++++++++++++++++++++++++++++++++
3 files changed, 70 insertions(+), 0 deletions(-)
diff --git a/lib/hci.c b/lib/hci.c
index 11b47b3..ec8d48e 100755
--- a/lib/hci.c
+++ b/lib/hci.c
@@ -1349,6 +1349,34 @@ int hci_le_remove_from_white_list(int dd, const bdaddr_t* bdaddr, uint8_t type)
return 0;
}
+int hci_le_read_white_list_size(int dd, int* size)
+{
+ struct hci_request rq;
+ le_read_white_list_size_rp rp;
+
+ memset(&rp, 0, sizeof(rp));
+ rp.size=0;
+
+ memset(&rq, 0, sizeof(rq));
+ rq.ogf = OGF_LE_CTL;
+ rq.ocf = OCF_LE_READ_WHITE_LIST_SIZE;
+ rq.rparam = &rp;
+ rq.rlen = LE_READ_WHITE_LIST_SIZE_RP_SIZE;
+
+ if (hci_send_req(dd, &rq, 1000) < 0)
+ return -1;
+
+ if (rp.status) {
+ errno = EIO;
+ return -1;
+ }
+
+ if(size)
+ *size=rp.size;
+
+ return 0;
+}
+
int hci_read_local_name(int dd, int len, char *name, int to)
{
read_local_name_rp rp;
diff --git a/lib/hci_lib.h b/lib/hci_lib.h
index e64a431..f0325b2 100755
--- a/lib/hci_lib.h
+++ b/lib/hci_lib.h
@@ -129,6 +129,7 @@ int hci_le_create_conn(int dd, uint16_t interval, uint16_t window,
uint16_t *handle, int to);
int hci_le_add_to_white_list(int dd, const bdaddr_t* bdaddr, uint8_t type);
int hci_le_remove_from_white_list(int dd, const bdaddr_t* bdaddr, uint8_t type);
+int hci_le_read_white_list_size(int dd, int* size);
int hci_for_each_dev(int flag, int(*func)(int dd, int dev_id, long arg), long arg);
int hci_get_route(bdaddr_t *bdaddr);
diff --git a/tools/hcitool.c b/tools/hcitool.c
index 038d05e..e80c7a3 100755
--- a/tools/hcitool.c
+++ b/tools/hcitool.c
@@ -2563,6 +2563,46 @@ static void cmd_lermwl(int dev_id, int argc, char **argv)
}
}
+static struct option lerdwlsz_options[] = {
+ { "help", 0, 0, 'h' },
+ { 0, 0, 0, 0 }
+};
+
+static const char *lerdwlsz_help =
+ "Usage:\n"
+ "\tlerdwlsz\n";
+
+static void cmd_lerdwlsz(int dev_id, int argc, char **argv)
+{
+ int err, dd, opt, size;
+
+ for_each_opt(opt, lerdwlsz_options, NULL) {
+ switch (opt) {
+ default:
+ printf("%s", lerdwlsz_help);
+ return;
+ }
+ }
+ helper_arg(0, 0, &argc, &argv, lermwl_help);
+
+ if (dev_id < 0)
+ dev_id = hci_get_route(NULL);
+
+ dd = hci_open_dev(dev_id);
+ if (dd < 0) {
+ perror("Could not open device");
+ exit(1);
+ }
+
+ err = hci_le_read_white_list_size(dd, &size);
+ hci_close_dev(dd);
+
+ if (err < 0) {
+ perror("Cant read white list size");
+ exit(1);
+ }
+}
+
static struct option ledc_options[] = {
{ "help", 0, 0, 'h' },
{ 0, 0, 0, 0 }
@@ -2641,6 +2681,7 @@ static struct {
{ "lescan", cmd_lescan, "Start LE scan" },
{ "leaddwl", cmd_leaddwl, "Add this device to white list" },
{ "lermwl", cmd_lermwl, "Remove this device from white list" },
+ { "lerdwlsz", cmd_lerdwlsz, "Read white list size" },
{ "lecc", cmd_lecc, "Create a LE Connection", },
{ "ledc", cmd_ledc, "Disconnect a LE Connection", },
{ NULL, NULL, 0 }
--
1.6.5
^ permalink raw reply related
* [PATCH 2/4] HCI command to remove device from LE White List
From: Sumit Kumar BAJPAI @ 2011-01-24 9:58 UTC (permalink / raw)
To: linux-bluetooth@vger.kernel.org
---
lib/hci.c | 29 +++++++++++++++++++++++++++++
lib/hci_lib.h | 1 +
tools/hcitool.c | 47 +++++++++++++++++++++++++++++++++++++++++++++++
3 files changed, 77 insertions(+), 0 deletions(-)
diff --git a/lib/hci.c b/lib/hci.c
index b75f612..11b47b3 100755
--- a/lib/hci.c
+++ b/lib/hci.c
@@ -1320,6 +1320,35 @@ int hci_le_add_to_white_list(int dd, const bdaddr_t* bdaddr, uint8_t type)
return 0;
}
+int hci_le_remove_from_white_list(int dd, const bdaddr_t* bdaddr, uint8_t type)
+{
+ struct hci_request rq;
+ le_remove_device_from_white_list_cp cp;
+ uint8_t status;
+
+ memset(&cp, 0, sizeof(cp));
+ cp.bdaddr_type = type;
+ bacpy(&cp.bdaddr,bdaddr);
+
+ memset(&rq, 0, sizeof(rq));
+ rq.ogf = OGF_LE_CTL;
+ rq.ocf = OCF_LE_REMOVE_DEVICE_FROM_WHITE_LIST;
+ rq.cparam = &cp;
+ rq.clen = LE_REMOVE_DEVICE_FROM_WHITE_LIST_CP_SIZE;
+ rq.rparam = &status;
+ rq.rlen = 1;
+
+ if (hci_send_req(dd, &rq, 1000) < 0)
+ return -1;
+
+ if (status) {
+ errno = EIO;
+ return -1;
+ }
+
+ return 0;
+}
+
int hci_read_local_name(int dd, int len, char *name, int to)
{
read_local_name_rp rp;
diff --git a/lib/hci_lib.h b/lib/hci_lib.h
index dd995dd..e64a431 100755
--- a/lib/hci_lib.h
+++ b/lib/hci_lib.h
@@ -128,6 +128,7 @@ int hci_le_create_conn(int dd, uint16_t interval, uint16_t window,
uint16_t min_ce_length, uint16_t max_ce_length,
uint16_t *handle, int to);
int hci_le_add_to_white_list(int dd, const bdaddr_t* bdaddr, uint8_t type);
+int hci_le_remove_from_white_list(int dd, const bdaddr_t* bdaddr, uint8_t type);
int hci_for_each_dev(int flag, int(*func)(int dd, int dev_id, long arg), long arg);
int hci_get_route(bdaddr_t *bdaddr);
diff --git a/tools/hcitool.c b/tools/hcitool.c
index 9147995..038d05e 100755
--- a/tools/hcitool.c
+++ b/tools/hcitool.c
@@ -2517,6 +2517,52 @@ static void cmd_leaddwl(int dev_id, int argc, char **argv)
}
}
+static struct option lermwl_options[] = {
+ { "help", 0, 0, 'h' },
+ { 0, 0, 0, 0 }
+};
+
+static const char *lermwl_help =
+ "Usage:\n"
+ "\tlermwl <bdaddr>\n";
+
+static void cmd_lermwl(int dev_id, int argc, char **argv)
+{
+ int err, opt, dd;
+ bdaddr_t bdaddr;
+ le_device_addr_type bdaddr_type;
+
+ for_each_opt(opt, lermwl_options, NULL) {
+ switch (opt) {
+ default:
+ printf("%s", lermwl_help);
+ return;
+ }
+ }
+
+ helper_arg(1, 1, &argc, &argv, lermwl_help);
+
+ if (dev_id < 0)
+ dev_id = hci_get_route(NULL);
+
+ dd = hci_open_dev(dev_id);
+ if (dd < 0) {
+ perror("Could not open device");
+ exit(1);
+ }
+
+ str2ba(argv[0], &bdaddr);
+ bdaddr_type = LE_PUBLIC_DEVICE_ADDR;
+
+ err = hci_le_remove_from_white_list(dd, &bdaddr, bdaddr_type);
+ hci_close_dev(dd);
+
+ if (err < 0) {
+ perror("Cant remove from white list");
+ exit(1);
+ }
+}
+
static struct option ledc_options[] = {
{ "help", 0, 0, 'h' },
{ 0, 0, 0, 0 }
@@ -2594,6 +2640,7 @@ static struct {
{ "clock", cmd_clock, "Read local or remote clock" },
{ "lescan", cmd_lescan, "Start LE scan" },
{ "leaddwl", cmd_leaddwl, "Add this device to white list" },
+ { "lermwl", cmd_lermwl, "Remove this device from white list" },
{ "lecc", cmd_lecc, "Create a LE Connection", },
{ "ledc", cmd_ledc, "Disconnect a LE Connection", },
{ NULL, NULL, 0 }
--
1.6.5
^ permalink raw reply related
* Re: [PATCH] Fix initialization when adapter is already up
From: Johan Hedberg @ 2011-01-24 9:56 UTC (permalink / raw)
To: Luiz Augusto von Dentz; +Cc: linux-bluetooth, marcel
In-Reply-To: <1295860387-10608-1-git-send-email-luiz.dentz@gmail.com>
Hi Luiz,
On Mon, Jan 24, 2011, Luiz Augusto von Dentz wrote:
> When handling HCI_DEV_REG event it should not be necessary to generate a
> HCI_DEV_UP since init_known_adapters already does it in case the adapter
> is ulready up.
> ---
> plugins/hciops.c | 26 ++------------------------
> 1 files changed, 2 insertions(+), 24 deletions(-)
Thanks for the patch. It has been pushed upstream with a minor typo fix
in the commit message.
Marcel, I think this would be reason enough to make another release.
Johan
^ permalink raw reply
* RE: [PATCH] HCI Commands for LE White List
From: Sumit Kumar BAJPAI @ 2011-01-24 9:56 UTC (permalink / raw)
To: Claudio Takahasi; +Cc: linux-bluetooth@vger.kernel.org
In-Reply-To: <AANLkTinjXceSM7NDVqWyyDGfgvtmAaFbMXdz829g311c@mail.gmail.com>
SGkgQ2xhdWRpbywgDQoNCg0KIA0KPiA8c25pcD4NCj4gDQo+ID4gSXMgdXNpbmcgYSBzZXBhcmF0
ZSB2YXJpYWJsZSBlcnIgZm9yIHJldHVybiB0eXBlIG9mIGEgZnVuY3Rpb24NCj4gcHJvYmxlbSBo
ZXJlPw0KPiBJIGRpZG4ndCB1bmRlcnN0YW5kIHlvdXIgcXVlc3Rpb24gaGVyZS4NCj4gaGNpXyog
ZnVuY3Rpb25zIHJldHVybiAwIG9uIHN1Y2Nlc3Mgb3IgLTEgb24gZmFpbHVyZS4gT24gZmFpbHVy
ZSBlcnJubw0KPiBjYW4gYmUgcmVhZCB0byBnZXQgdGhlIGVycm9yIG51bWJlci4NCj4gDQo+ID4g
SSBjb3VsZCBzZWUgc2FtZSBjb2Rpbmcgc3R5bGUgb2YgZGVmaW5pbmcgYSB2YXJpYWJsZSB0byBj
YXJyeSB0aGUNCj4gZXJyb3Igc3RhdHVzIGluIGhjaXRvb2wuYyBmdW5jdGlvbiBjbWRfbGVjYy4N
Cj4gPiBQbGVhc2UgY29uZmlybS4NCj4gVGhlIGNvZGluZyBzdHlsZSBpc3N1ZSBpcyB0aGUgaWYg
ZWxzZToNCj4gQXQgdGhpcyBwb2ludCAiZWxzZSIgaXMgbm90IG5lZWRlZDogdGhlcmUgaXMgYSAi
ZXhpdCgxKSIgaW5zaWRlIHRoZQ0KPiAiaWYiIGJsb2NrLiBCdXQgaWYgeW91IG5lZWQgZWxzZSB0
aGUgY29ycmVjdCBjb2Rpbmcgc3R5bGUgaXM6DQo+IC4uLg0KPiB9IGVsc2Ugew0KPiAuLi4NCj4g
DQo+IEluc3RlYWQgb2YNCj4gLi4uDQo+IH0NCj4gZWxzZSB7DQo+IC4uLg0KPiANCj4gPHNuaXA+
DQo+IA0KPiA+PiA+ICsgwqAgwqAgwqAgZXJyID0gaGNpX2xlX3JlbW92ZV9mcm9tX3doaXRlX2xp
c3QoZGQsIGJkYWRkcg0KPiAsYmRhZGRyX3R5cGUpOw0KPiA+PiA+ICsgwqAgwqAgwqAgaWYgKGVy
ciA8IDApIHsNCj4gPj4gPiArIMKgIMKgIMKgIMKgIMKgIMKgIMKgIHBlcnJvcigiQ2FudCByZW1v
dmUgZnJvbSB3aGl0ZSBsaXN0Iik7DQo+ID4+ID4gKyDCoCDCoCDCoCDCoCDCoCDCoCDCoCBleGl0
KDEpOw0KPiA+PiA+ICsgwqAgwqAgwqAgfQ0KPiA+PiA+ICsgwqAgwqAgwqAgwqBlbHNlIHsNCj4g
Pj4gPiArIMKgIMKgIMKgIMKgIMKgIMKgIMKgIHByaW50ZigiRGV2aWNlIHJlbW92ZWQgZnJvbSB3
aGl0ZSBsaXN0Iik7DQo+ID4+ID4gKyDCoCDCoCDCoCB9DQo+ID4+ID4gKw0KPiA+PiA+ICsgwqAg
wqAgwqAgaGNpX2Nsb3NlX2RldihkZCk7DQo+ID4+IFNhbWUgY29kaW5nIHN0eWxlIGlzc3VlIGFu
ZCBjbG9zZSAiZGQiDQo+ID4+DQo+ID4NCj4gPg0KPiA+IE9rLiBHb29kIHBvaW50LiBCdXQgSSBj
b3VsZCBzdGlsbCBmaW5kIHByZW1hdHVyZSByZXR1cm5zIG9uIGVycm9yDQo+IGNvbmRpdGlvbnMg
dmlhIGV4aXRzIGF0IHNldmVyYWwgcGxhY2VzIGluIGhjaXRvb2wuYy4gQ2FuIEkgc3VibWl0IGEN
Cj4gc2VwYXJhdGUgcGF0Y2ggZm9yIHJlY3RpZnlpbmcgYWxsIHN1Y2ggZXJyb3IgY29uZGl0aW9u
cyB0b28/DQo+IA0KPiBzdXJlIQ0KPiANCg0KQXMgcGVyIHlvdXIgY29tbWVudHMsIEkgYW0gcG9z
dGluZyA0IHBhdGNoZXMgc2VwYXJhdGVseS4gDQo=
^ permalink raw reply
* [PATCH] Fix initialization when adapter is already up
From: Luiz Augusto von Dentz @ 2011-01-24 9:13 UTC (permalink / raw)
To: linux-bluetooth
From: Luiz Augusto von Dentz <luiz.dentz-von@nokia.com>
When handling HCI_DEV_REG event it should not be necessary to generate a
HCI_DEV_UP since init_known_adapters already does it in case the adapter
is ulready up.
---
plugins/hciops.c | 26 ++------------------------
1 files changed, 2 insertions(+), 24 deletions(-)
diff --git a/plugins/hciops.c b/plugins/hciops.c
index 7240d51..260ac7d 100644
--- a/plugins/hciops.c
+++ b/plugins/hciops.c
@@ -2253,25 +2253,6 @@ fail:
exit(1);
}
-static void device_devreg_setup(int index)
-{
- struct hci_dev_info di;
-
- DBG("hci%d", index);
-
- init_device(index);
-
- memset(&di, 0, sizeof(di));
-
- if (hci_devinfo(index, &di) < 0)
- return;
-
- if (ignore_device(&di))
- return;
-
- devs[index].already_up = hci_test_bit(HCI_UP, &di.flags);
-}
-
static void init_conn_list(int index)
{
struct dev_info *dev = &devs[index];
@@ -2318,11 +2299,7 @@ static void device_event(int event, int index)
switch (event) {
case HCI_DEV_REG:
info("HCI dev %d registered", index);
- device_devreg_setup(index);
- if (devs[index].already_up) {
- init_conn_list(index);
- device_event(HCI_DEV_UP, index);
- }
+ init_device(index);
break;
case HCI_DEV_UNREG:
@@ -2418,6 +2395,7 @@ static gboolean init_known_adapters(gpointer user_data)
if (!dev->already_up)
continue;
+ init_conn_list(dr->dev_id);
hciops_stop_inquiry(dr->dev_id);
dev->pending = 0;
--
1.7.1
^ permalink raw reply related
* [PATCHv3] Bluetooth: fix crash by disabling tasklet in sock accept
From: Emeltchenko Andrei @ 2011-01-24 8:53 UTC (permalink / raw)
To: linux-bluetooth
From: Andrei Emeltchenko <andrei.emeltchenko@nokia.com>
Crash can happen when tasklet handling connect/disconnect requests
preempts socket accept. Can be reproduced with "l2test -r" on one
side and several "l2test -c -b 1000 -i hci0 -P 10 <bdaddr>" on the
other side.
disable taskets in socket accept and change lock_sock and release_sock
to bh_lock_sock and bh_unlock_sock since we have to use spinlocks and
there is no need to mark sock as owned by user.
...
[ 3555.897247] Unable to handle kernel NULL pointer dereference at virtual
address 000000bc
[ 3555.915039] pgd = cab9c000
[ 3555.917785] [000000bc] *pgd=8bf3d031, *pte=00000000, *ppte=00000000
[ 3555.928314] Internal error: Oops: 17 [#1] PREEMPT
[ 3555.999786] CPU: 0 Not tainted (2.6.32.21-13874-g67918ef #65)
...
[ 3556.005981] PC is at bt_accept_unlink+0x20/0x58 [bluetooth]
[ 3556.011627] LR is at bt_accept_dequeue+0x3c/0xe8 [bluetooth]
...
[ 3556.161285] [<bf0007fc>] (bt_accept_unlink+0x20/0x58 [bluetooth]) from
[<bf000870>] (bt_accept_dequeue+0x3c/0xe8 [bluetooth])
[ 3556.172729] [<bf000870>] (bt_accept_dequeue+0x3c/0xe8 [bluetooth]) from
[<bf324df8>] (l2cap_sock_accept+0x100/0x15c [l2cap])
[ 3556.184082] [<bf324df8>] (l2cap_sock_accept+0x100/0x15c [l2cap]) from
[<c026a0a8>] (sys_accept4+0x120/0x1e0)
[ 3556.193969] [<c026a0a8>] (sys_accept4+0x120/0x1e0) from [<c002c9a0>]
(ret_fast_syscall+0x0/0x2c)
[ 3556.202819] Code: e5813000 e5901164 e580c160 e580c15c (e1d13bbc)
...
Signed-off-by: Andrei Emeltchenko <andrei.emeltchenko@nokia.com>
---
net/bluetooth/af_bluetooth.c | 13 +++++++++----
1 files changed, 9 insertions(+), 4 deletions(-)
diff --git a/net/bluetooth/af_bluetooth.c b/net/bluetooth/af_bluetooth.c
index a6732b5..2abfe2f 100644
--- a/net/bluetooth/af_bluetooth.c
+++ b/net/bluetooth/af_bluetooth.c
@@ -199,14 +199,15 @@ struct sock *bt_accept_dequeue(struct sock *parent, struct socket *newsock)
BT_DBG("parent %p", parent);
+ local_bh_disable();
list_for_each_safe(p, n, &bt_sk(parent)->accept_q) {
sk = (struct sock *) list_entry(p, struct bt_sock, accept_q);
- lock_sock(sk);
+ bh_lock_sock(sk);
/* FIXME: Is this check still needed */
if (sk->sk_state == BT_CLOSED) {
- release_sock(sk);
+ bh_unlock_sock(sk);
bt_accept_unlink(sk);
continue;
}
@@ -216,12 +217,16 @@ struct sock *bt_accept_dequeue(struct sock *parent, struct socket *newsock)
bt_accept_unlink(sk);
if (newsock)
sock_graft(sk, newsock);
- release_sock(sk);
+
+ bh_unlock_sock(sk);
+ local_bh_enable();
return sk;
}
- release_sock(sk);
+ bh_unlock_sock(sk);
}
+ local_bh_enable();
+
return NULL;
}
EXPORT_SYMBOL(bt_accept_dequeue);
--
1.7.1
^ permalink raw reply related
* Re: [PATCH] Set connection state to BT_DISCONN to avoid multiple responses
From: Liang Bao @ 2011-01-24 5:09 UTC (permalink / raw)
To: Gustavo F. Padovan; +Cc: linux-bluetooth
In-Reply-To: <AANLkTimGdeu17sn8bxtp5TNd8i_0hpwpsmRy0wc98y8v@mail.gmail.com>
Hi, Gustavo,
2011/1/20 Liang Bao <tim.bao@gmail.com>:
> 2011/1/20 Gustavo F. Padovan <padovan@profusion.mobi>:
>> Hi Bao,
>>
>> * tim.bao@gmail.com <tim.bao@gmail.com> [2011-01-19 21:22:09 +0800]:
>>
>>> From: Bao Liang <tim.bao@gmail.com>
>>>
>>> This patch fixes a minor issue that two connection responses will be sent
>>> for one L2CAP connection request. If the L2CAP connection request is first
>>> blocked due to security reason and responded with reason "security block",
>>> the state of the connection remains BT_CONNECT2. If a pairing procedure
>>> completes successfully before the ACL connection is down, local host will
>>> send another connection complete response. See the following packets
>>> captured by hcidump.
>>>
>>> 2010-12-07 22:21:24.928096 < ACL data: handle 12 flags 0x00 dlen 16
>>> 0000: 0c 00 01 00 03 19 08 00 41 00 53 00 03 00 00 00 ........A.S.....
>>> ... ...
>>>
>>> 2010-12-07 22:21:35.791747 > HCI Event: Auth Complete (0x06) plen 3
>>> status 0x00 handle 12
>>> ... ...
>>>
>>> 2010-12-07 22:21:35.872372 > ACL data: handle 12 flags 0x02 dlen 16
>>> L2CAP(s): Connect rsp: dcid 0x0054 scid 0x0040 result 0 status 0
>>> Connection successful
>>
>> Please provide a more helpful hcidump showing at least the connection request
>> and the two connection response.
> Sure, here's the full log of one try with the following steps:
> - Unpair from the host side while KB is connected.(2010-12-07 22:21:13.133047)
> - Press the "Connect" button of Logitech V470, the mouse will try to
> connect back although it's put into discoverable mode
> meanwhile(2010-12-07 22:21:24.459891).
> - HID control channel will be asked to UNPLUG but the HID interrupt
> channel will be refused for reason security block. See 2010-12-07
> 22:21:24.928096 - no idea why it's not decoded into ASCII format by
> hcidump but FTS4BT can decode it as "Result: Refused - Security
> block"
> - Quickly start pair from phone side before the ACL link is down. For
> dev purpose, the ACL timeout is increased but the phenomenon is still
> observable with a starndard version if start pair quickly enough.
> Pairing will complete without error. See 2010-12-07 22:21:35.791747
> - Immediately after "auth complete", host side will respond to the
> V470 with "connection successful". See 2010-12-07 22:21:35.872372
>
> I also post log of multiple tries (including this) to
> http://pastebin.com/TPHgNUKd for your reference.
>
> It's not a big issue and connection can be finally made by a second
> try in most cases. However, removing this will set the state to closed
> because the host actually declined the connection request and hence a
> second rsp to the l2cap_conn_req shall not be sent. Just my two cents.
>
> 2010-12-07 22:21:13.099872 > HCI Event: Disconn Complete (0x05) plen 4
> status 0x00 handle 11 reason 0x16
> Reason: Connection Terminated by Local Host
> 2010-12-07 22:21:13.125585 < HCI Command: Delete Stored Link Key
> (0x03|0x0012) plen 7
> bdaddr 00:1F:20:01:C9:B8 all 0
> 2010-12-07 22:21:13.133047 > HCI Event: Command Complete (0x0e) plen 6
> Delete Stored Link Key (0x03|0x0012) ncmd 1
> status 0x00 deleted 0
> 2010-12-07 22:21:24.459891 > HCI Event: Connect Request (0x04) plen 10
> bdaddr 00:1F:20:01:C9:B8 class 0x002580 type ACL
> 2010-12-07 22:21:24.460063 < HCI Command: Accept Connection Request
> (0x01|0x0009) plen 7
> bdaddr 00:1F:20:01:C9:B8 role 0x00
> Role: Master
> 2010-12-07 22:21:24.470041 > HCI Event: Command Status (0x0f) plen 4
> Accept Connection Request (0x01|0x0009) status 0x00 ncmd 1
> 2010-12-07 22:21:24.629984 > HCI Event: Role Change (0x12) plen 8
> status 0x00 bdaddr 00:1F:20:01:C9:B8 role 0x00
> Role: Master
> 2010-12-07 22:21:24.780008 > HCI Event: Connect Complete (0x03) plen 11
> status 0x00 handle 12 bdaddr 00:1F:20:01:C9:B8 type ACL encrypt 0x00
> 2010-12-07 22:21:24.780135 < HCI Command: Read Remote Supported
> Features (0x01|0x001b) plen 2
> handle 12
> 2010-12-07 22:21:24.792511 > HCI Event: Command Status (0x0f) plen 4
> Read Remote Supported Features (0x01|0x001b) status 0x00 ncmd 1
> 2010-12-07 22:21:24.792546 > HCI Event: Read Remote Supported Features
> (0x0b) plen 11
> status 0x00 handle 12
> Features: 0xbc 0x02 0x04 0x38 0x08 0x00 0x00 0x00
> 2010-12-07 22:21:24.815529 > ACL data: handle 12 flags 0x02 dlen 12
> L2CAP(s): Connect req: psm 17 scid 0x0052
> 2010-12-07 22:21:24.815727 < ACL data: handle 12 flags 0x00 dlen 16
> 0C 00 01 00 03 17 08 00 40 00 52 00 01 00 00 00
> 2010-12-07 22:21:24.815848 < ACL data: handle 12 flags 0x00 dlen 10
> 06 00 01 00 0A 01 02 00 02 00
> 2010-12-07 22:21:24.822141 < HCI Command: Remote Name Request
> (0x01|0x0019) plen 10
> bdaddr 00:1F:20:01:C9:B8 mode 2 clkoffset 0x0000
> 2010-12-07 22:21:24.832574 > HCI Event: Number of Completed Packets
> (0x13) plen 5
> handle 12 packets 2
> 2010-12-07 22:21:24.832597 > HCI Event: Command Status (0x0f) plen 4
> Remote Name Request (0x01|0x0019) status 0x00 ncmd 1
> 2010-12-07 22:21:24.832602 > ACL data: handle 12 flags 0x02 dlen 16
> L2CAP(s): Info rsp: type 2 result 0
> Extended feature mask 0x0004
> Bi-directional QoS
> 2010-12-07 22:21:24.832756 < ACL data: handle 12 flags 0x00 dlen 16
> 0C 00 01 00 03 17 08 00 40 00 52 00 00 00 00 00
> 2010-12-07 22:21:24.879811 > ACL data: handle 12 flags 0x02 dlen 16
> L2CAP(s): Config req: dcid 0x0040 flags 0x00 clen 4
> MTU 185
> 2010-12-07 22:21:24.879871 < ACL data: handle 12 flags 0x00 dlen 18
> 0E 00 01 00 05 18 0A 00 52 00 00 00 00 00 01 02 B9 00
> 2010-12-07 22:21:24.879960 < ACL data: handle 12 flags 0x00 dlen 12
> 08 00 01 00 04 02 04 00 52 00 00 00
> 2010-12-07 22:21:24.899815 > HCI Event: Number of Completed Packets
> (0x13) plen 5
> handle 12 packets 2
> 2010-12-07 22:21:24.899828 > HCI Event: Remote Name Req Complete (0x07) plen 255
> status 0x00 bdaddr 00:1F:20:01:C9:B8 name 'Bluetooth Laser Travel Mouse'
> 2010-12-07 22:21:24.919852 > ACL data: handle 12 flags 0x02 dlen 18
> L2CAP(s): Config rsp: scid 0x0040 flags 0x00 result 0 clen 4
> Success
> MTU 185
> 2010-12-07 22:21:24.919865 > ACL data: handle 12 flags 0x02 dlen 12
> L2CAP(s): Connect req: psm 19 scid 0x0053
> 2010-12-07 22:21:24.919951 < ACL data: handle 12 flags 0x00 dlen 16
> 0C 00 01 00 03 19 08 00 41 00 53 00 01 00 02 00
> 2010-12-07 22:21:24.920192 < ACL data: handle 12 flags 0x00 dlen 5
> 01 00 52 00 15
> 2010-12-07 22:21:24.920308 < ACL data: handle 12 flags 0x00 dlen 12
> 08 00 01 00 06 03 04 00 52 00 40 00
> 2010-12-07 22:21:24.928096 < ACL data: handle 12 flags 0x00 dlen 16
> 0C 00 01 00 03 19 08 00 41 00 53 00 03 00 00 00
> 2010-12-07 22:21:24.929844 > HCI Event: Number of Completed Packets
> (0x13) plen 5
> handle 12 packets 2
> 2010-12-07 22:21:24.929857 > HCI Event: Number of Completed Packets
> (0x13) plen 5
> handle 12 packets 2
> 2010-12-07 22:21:24.939857 > ACL data: handle 12 flags 0x02 dlen 12
> L2CAP(s): Disconn rsp: dcid 0x0052 scid 0x0040
> 2010-12-07 22:21:25.109941 > HCI Event: Number of Completed Packets
> (0x13) plen 5
> handle 12 packets 1
> 2010-12-07 22:21:27.273753 < HCI Command: Authentication Requested
> (0x01|0x0011) plen 2
> handle 12
> 2010-12-07 22:21:27.290059 > HCI Event: Command Status (0x0f) plen 4
> Authentication Requested (0x01|0x0011) status 0x00 ncmd 1
> 2010-12-07 22:21:27.290081 > HCI Event: Link Key Request (0x17) plen 6
> bdaddr 00:1F:20:01:C9:B8
> 2010-12-07 22:21:27.291243 < HCI Command: Link Key Request Negative
> Reply (0x01|0x000c) plen 6
> bdaddr 00:1F:20:01:C9:B8
> 2010-12-07 22:21:27.300072 > HCI Event: Command Complete (0x0e) plen 10
> Link Key Request Negative Reply (0x01|0x000c) ncmd 1
> status 0x00 bdaddr 00:1F:20:01:C9:B8
> 2010-12-07 22:21:27.300101 > HCI Event: PIN Code Request (0x16) plen 6
> bdaddr 00:1F:20:01:C9:B8
> 2010-12-07 22:21:35.678564 < HCI Command: PIN Code Request Reply
> (0x01|0x000d) plen 23
> bdaddr 00:1F:20:01:C9:B8 len 4 pin '0000'
> 2010-12-07 22:21:35.692679 > HCI Event: Command Complete (0x0e) plen 10
> PIN Code Request Reply (0x01|0x000d) ncmd 1
> status 0x00 bdaddr 00:1F:20:01:C9:B8
> 2010-12-07 22:21:35.791738 > HCI Event: Link Key Notification (0x18) plen 23
> bdaddr 00:1F:20:01:C9:B8 key EFA3DFDFC773E2B4C5D5C3E409DA84A9 type 0
> 2010-12-07 22:21:35.791747 > HCI Event: Auth Complete (0x06) plen 3
> status 0x00 handle 12
> 2010-12-07 22:21:35.791829 < ACL data: handle 12 flags 0x00 dlen 16
> 0C 00 01 00 03 19 08 00 41 00 53 00 00 00 00 00
> 2010-12-07 22:21:35.817243 < ACL data: handle 12 flags 0x00 dlen 12
> 08 00 01 00 02 04 04 00 01 00 40 00
> 2010-12-07 22:21:35.832388 > HCI Event: Number of Completed Packets
> (0x13) plen 5
> handle 12 packets 2
> 2010-12-07 22:21:35.872372 > ACL data: handle 12 flags 0x02 dlen 16
> L2CAP(s): Connect rsp: dcid 0x0054 scid 0x0040 result 0 status 0
> Connection successful
> 2010-12-07 22:21:35.872429 < ACL data: handle 12 flags 0x00 dlen 12
> 08 00 01 00 04 05 04 00 54 00 00 00
> 2010-12-07 22:21:35.902318 > ACL data: handle 12 flags 0x02 dlen 18
> L2CAP(s): Config rsp: scid 0x0040 flags 0x00 result 0 clen 4
> Success
> MTU 185
> 2010-12-07 22:21:35.902330 > ACL data: handle 12 flags 0x02 dlen 16
> L2CAP(s): Config req: dcid 0x0040 flags 0x00 clen 4
> MTU 185
> 2010-12-07 22:21:35.902407 < ACL data: handle 12 flags 0x00 dlen 18
> 0E 00 01 00 05 1A 0A 00 54 00 00 00 00 00 01 02 B9 00
> 2010-12-07 22:21:35.902707 < ACL data: handle 12 flags 0x00 dlen 24
> 14 00 54 00 06 00 00 00 0F 35 03 19 01 00 FF FF 35 05 0A 00
> 00 FF FF 00
> 2010-12-07 22:21:35.923249 > HCI Event: Number of Completed Packets
> (0x13) plen 5
> handle 12 packets 2
> 2010-12-07 22:21:36.042451 > ACL data: handle 12 flags 0x02 dlen 27
> 2010-12-07 22:21:36.042480 > ACL data: handle 12 flags 0x01 dlen 27
> 2010-12-07 22:21:36.042487 > ACL data: handle 12 flags 0x01 dlen 27
> 2010-12-07 22:21:36.052466 > ACL data: handle 12 flags 0x01 dlen 27
> 2010-12-07 22:21:36.052485 > ACL data: handle 12 flags 0x01 dlen 24
> L2CAP(d): cid 0x0040 len 128 [psm 0]
> 07 00 00 00 7B 00 76 36 01 C0 36 01 60 09 00 00 0A 00 01 00
> 00 09 00 01 35 03 19 11 24 09 00 04 35 0D 35 06 19 01 00 09
> 00 11 35 03 19 00 11 09 00 05 35 03 19 10 02 09 00 06 35 09
> 09 65 6E 09 00 6A 09 01 00 09 00 09 35 08 35 06 19 11 24 09
> 01 00 09 00 0D 35 0F 35 0D 35 06 19 01 00 09 00 13 35 03 19
> 00 11 09 01 00 25 22 4C 6F 67 69 74 65 63 68 20 56 34 37 30
> 20 43 6F 72 64 02 00 76
> 2010-12-07 22:21:36.053674 < ACL data: handle 12 flags 0x00 dlen 26
> 16 00 54 00 06 00 01 00 11 35 03 19 01 00 FF FF 35 05 0A 00
> 00 FF FF 02 00 76
> 2010-12-07 22:21:36.062537 > HCI Event: Number of Completed Packets
> (0x13) plen 5
> handle 12 packets 2
> 2010-12-07 22:21:36.180597 > ACL data: handle 12 flags 0x02 dlen 27
> 2010-12-07 22:21:36.180613 > ACL data: handle 12 flags 0x01 dlen 27
> 2010-12-07 22:21:36.180621 > ACL data: handle 12 flags 0x01 dlen 27
> 2010-12-07 22:21:36.180625 > ACL data: handle 12 flags 0x01 dlen 27
> 2010-12-07 22:21:36.192515 > ACL data: handle 12 flags 0x01 dlen 24
> L2CAP(d): cid 0x0040 len 128 [psm 0]
> 07 00 01 00 7B 00 76 6C 65 73 73 20 4C 61 73 65 72 20 4D 6F
> 75 73 65 09 01 01 25 0F 42 6C 75 65 74 6F 6F 74 68 20 4D 6F
> 75 73 65 09 01 02 25 08 4C 6F 67 69 74 65 63 68 09 02 00 09
> 01 00 09 02 01 09 01 11 09 02 02 08 80 09 02 03 08 21 09 02
> 04 28 01 09 02 05 28 01 09 02 06 35 68 35 66 08 22 25 62 05
> 01 09 02 A1 01 85 02 09 01 A1 00 05 09 19 01 29 08 15 00 25
> 01 75 01 95 08 02 00 EC
> 2010-12-07 22:21:36.193599 < ACL data: handle 12 flags 0x00 dlen 26
> 16 00 54 00 06 00 02 00 11 35 03 19 01 00 FF FF 35 05 0A 00
> 00 FF FF 02 00 EC
> 2010-12-07 22:21:36.300605 > ACL data: handle 12 flags 0x02 dlen 27
> 2010-12-07 22:21:36.300622 > ACL data: handle 12 flags 0x01 dlen 27
> 2010-12-07 22:21:36.312521 > ACL data: handle 12 flags 0x01 dlen 27
> 2010-12-07 22:21:36.312539 > ACL data: handle 12 flags 0x01 dlen 27
> 2010-12-07 22:21:36.312543 > ACL data: handle 12 flags 0x01 dlen 24
> L2CAP(d): cid 0x0040 len 128 [psm 0]
> 07 00 02 00 7B 00 76 81 02 05 01 09 30 09 31 16 01 F8 26 FF
> 07 75 0C 95 02 81 06 09 38 15 81 25 7F 75 08 95 01 81 06 05
> 0C 0A 38 02 75 08 95 01 81 06 C0 C0 06 00 FF 09 01 A1 01 85
> 10 75 08 95 06 15 00 26 FF 00 09 01 81 00 09 01 91 00 C0 09
> 02 07 35 08 35 06 09 04 09 09 01 00 09 02 08 28 00 09 02 09
> 28 01 09 02 0A 28 01 09 02 0B 09 01 00 09 02 0C 09 0C 80 09
> 02 0D 28 00 09 02 01 62
> 2010-12-07 22:21:36.313630 < ACL data: handle 12 flags 0x00 dlen 26
> 16 00 54 00 06 00 03 00 11 35 03 19 01 00 FF FF 35 05 0A 00
> 00 FF FF 02 01 62
> 2010-12-07 22:21:36.322432 > HCI Event: Number of Completed Packets
> (0x13) plen 5
> handle 12 packets 2
> 2010-12-07 22:21:36.440618 > ACL data: handle 12 flags 0x02 dlen 27
> 2010-12-07 22:21:36.440635 > ACL data: handle 12 flags 0x01 dlen 27
> 2010-12-07 22:21:36.440639 > ACL data: handle 12 flags 0x01 dlen 27
> 2010-12-07 22:21:36.440643 > ACL data: handle 12 flags 0x01 dlen 27
> 2010-12-07 22:21:36.452517 > ACL data: handle 12 flags 0x01 dlen 1
> L2CAP(d): cid 0x0040 len 105 [psm 0]
> 07 00 03 00 64 00 61 02 0E 28 01 36 00 5A 09 00 00 0A 00 01
> 00 01 09 00 01 35 03 19 12 00 09 00 04 35 0D 35 06 19 01 00
> 09 00 01 35 03 19 00 01 09 00 05 35 03 19 10 02 09 00 09 35
> 08 35 06 19 12 00 09 01 00 09 02 00 09 01 00 09 02 01 09 04
> 6D 09 02 02 09 B0 08 09 02 03 09 03 17 09 02 04 28 01 09 02
> 05 09 00 02 00
> 2010-12-07 22:21:36.484591 < ACL data: handle 12 flags 0x00 dlen 24
> 14 00 54 00 06 00 04 00 0F 35 03 19 12 00 FF FF 35 05 0A 00
> 00 FF FF 00
> 2010-12-07 22:21:36.592512 > ACL data: handle 12 flags 0x02 dlen 27
> 2010-12-07 22:21:36.592536 > ACL data: handle 12 flags 0x01 dlen 27
> 2010-12-07 22:21:36.592540 > ACL data: handle 12 flags 0x01 dlen 27
> 2010-12-07 22:21:36.592550 > ACL data: handle 12 flags 0x01 dlen 27
> L2CAP(d): cid 0x0040 len 104 [psm 0]
> 07 00 04 00 63 00 60 36 00 5D 36 00 5A 09 00 00 0A 00 01 00
> 01 09 00 01 35 03 19 12 00 09 00 04 35 0D 35 06 19 01 00 09
> 00 01 35 03 19 00 01 09 00 05 35 03 19 10 02 09 00 09 35 08
> 35 06 19 12 00 09 01 00 09 02 00 09 01 00 09 02 01 09 04 6D
> 09 02 02 09 B0 08 09 02 03 09 03 17 09 02 04 28 01 09 02 05
> 09 00 02 00
> 2010-12-07 22:21:36.666846 < ACL data: handle 12 flags 0x00 dlen 12
> 08 00 01 00 02 06 04 00 11 00 42 00
> 2010-12-07 22:21:36.672425 > HCI Event: Number of Completed Packets
> (0x13) plen 5
> handle 12 packets 2
> 2010-12-07 22:21:36.702399 > ACL data: handle 12 flags 0x02 dlen 16
> L2CAP(s): Connect rsp: dcid 0x0000 scid 0x0042 result 4 status 0
> Connection refused - no resources available
> 2010-12-07 22:21:38.422526 > ACL data: handle 12 flags 0x02 dlen 12
> L2CAP(s): Disconn req: dcid 0x0040 scid 0x0054
> 2010-12-07 22:21:38.422675 < ACL data: handle 12 flags 0x00 dlen 12
> 08 00 01 00 07 1B 04 00 40 00 54 00
> 2010-12-07 22:21:38.602501 > HCI Event: Number of Completed Packets
> (0x13) plen 5
> handle 12 packets 1
> 2010-12-07 22:21:38.602523 > HCI Event: Disconn Complete (0x05) plen 4
> status 0x00 handle 12 reason 0x16
> Reason: Connection Terminated by Local Host
Please let me know if there's any information needed. Thanks.
>>
>> --
>> Gustavo F. Padovan
>> http://profusion.mobi
>>
>
^ permalink raw reply
* Re: Attribute Server and Client TODOs
From: Erin Yueh @ 2011-01-22 7:21 UTC (permalink / raw)
To: Brian Gix; +Cc: claudio.takahasi, linux-bluetooth
In-Reply-To: <1295654876.1774.24.camel@ubuntuLab1>
Hi Brian,
On Sat, Jan 22, 2011 at 08:07, Brian Gix <bgix@codeaurora.org> wrote:
> Hi Claudio, etc,
>
> Sorry for the repeat --> I sent it to the incorrect list the first time.
>
> We are starting to look at the adopted LE profiles, and it is becoming
> clear that Higher layer (Applications etc) server support will be needed
> for some of the significant use cases such as Proximity. Is anybody
> currently working on a D-Bus interface to the Attribute Server? I know
> there is nothing in code that has been up-streamed yet, but I was
> wondering if anyone has put some thought into what a D-Bus interface for
> the Attribute Server might look like?
>
yup, I was studying how to use LE in bluez recently. I can run Attribute server/
client on two Ubuntu machines. Then, I use gatttool to verify the primary and
characteristics data. I wrote my notes in my blog. If you have interests, you
could read for reference.
http://i-miss-erin.blogspot.com/2010/12/gatt-related-dbus-api.html
> Also, one of my compatriots is telling me that she cannot get the GATT
> Client D-Bus interface to work. I don't know if this is a simple lack
> of Introspection Data (required by d-feet), or if there is a build or
> configuration parameter that needs to be setup. I have just been using
> the gatttool to run my tests, and not going through D-Bus. If anybody
> has been using D-Bus for GATT Client testing, I would be interested in
> finding out if there is some setup requirements that I am missing.
>
I only modified EnableLE and AttributeServer two values in main.conf and
add --enable-attribute on building bluez. Then, it can work. I can use dbus-send
to query data. I also wrote the notes about setting up gatttool in bluez over
BR/EDR.
http://i-miss-erin.blogspot.com/2010/12/gatttool-in-bluez-over-bredr.html
> Thanks for your time.
>
>
> --
> Brian Gix
> bgix@codeaurora.org
> Employee of Qualcomm Innovation Center, Inc.
> Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum
>
> --
> 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
>
Thanks,
Erin Yueh
^ permalink raw reply
* Attribute Server and Client TODOs
From: Brian Gix @ 2011-01-22 0:07 UTC (permalink / raw)
To: claudio.takahasi; +Cc: linux-bluetooth
Hi Claudio, etc,
Sorry for the repeat --> I sent it to the incorrect list the first time.
We are starting to look at the adopted LE profiles, and it is becoming
clear that Higher layer (Applications etc) server support will be needed
for some of the significant use cases such as Proximity. Is anybody
currently working on a D-Bus interface to the Attribute Server? I know
there is nothing in code that has been up-streamed yet, but I was
wondering if anyone has put some thought into what a D-Bus interface for
the Attribute Server might look like?
Also, one of my compatriots is telling me that she cannot get the GATT
Client D-Bus interface to work. I don't know if this is a simple lack
of Introspection Data (required by d-feet), or if there is a build or
configuration parameter that needs to be setup. I have just been using
the gatttool to run my tests, and not going through D-Bus. If anybody
has been using D-Bus for GATT Client testing, I would be interested in
finding out if there is some setup requirements that I am missing.
Thanks for your time.
--
Brian Gix
bgix@codeaurora.org
Employee of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum
^ permalink raw reply
* Re: [RFC 0/2] remove BT references from TI_ST
From: Pavan Savoy @ 2011-01-21 21:10 UTC (permalink / raw)
To: Gustavo F. Padovan, Pavan Savoy; +Cc: marcel, linux-kernel, linux-bluetooth
In-Reply-To: <20110121182749.GE2400@joana>
Gustavo,
On Fri, Jan 21, 2011 at 11:57 PM, Gustavo F. Padovan
<padovan@profusion.mobi> wrote:
> Hi Pavan,
>
> * Pavan Savoy <pavan_savoy@sify.com> [2011-01-21 23:10:28 +0530]:
>
>> >> > If this is alright, I will send out a modified patch with updated
>> >> > subject to lkml/Greg for linux-next.
>> >
>> > Ok. Go ahead. Then tell me when I'll be able to apply your patch. (I need to
>> > have the core modifications in my tree first). Or I just ack the patch and it
>> > finds its way to mainline through Greg's tree.
>>
>> Yes, I will post a patch to lkml against linux-next to greg KH, and
>> based on that send a
>> separate patch to linux-bluetooth for the btwilink..
>
> Actually send everything to Greg KH, will work out better. Otherwise you will
> have to one release cycle to merge it here (until the other patches reach my
> tree). Then I just Ack it.
Thanks, I will do that.
I will fix up the btwilink comments too...
I have few other patches on TI ST lined up as well. (kind of reviewed
by Samuel Ortiz too...).
So I will put them all together and post them within couple of days.
Thanks a lot.
> --
> Gustavo F. Padovan
> http://profusion.mobi
>
^ permalink raw reply
* Re: [RFC 0/2] remove BT references from TI_ST
From: Gustavo F. Padovan @ 2011-01-21 18:27 UTC (permalink / raw)
To: Pavan Savoy; +Cc: marcel, linux-kernel, linux-bluetooth
In-Reply-To: <AANLkTimGNjfMtf+6XBMfKHo_F0sEnAJVdWjobfxDWoe7@mail.gmail.com>
Hi Pavan,
* Pavan Savoy <pavan_savoy@sify.com> [2011-01-21 23:10:28 +0530]:
> >> > If this is alright, I will send out a modified patch with updated
> >> > subject to lkml/Greg for linux-next.
> >
> > Ok. Go ahead. Then tell me when I'll be able to apply your patch. (I need to
> > have the core modifications in my tree first). Or I just ack the patch and it
> > finds its way to mainline through Greg's tree.
>
> Yes, I will post a patch to lkml against linux-next to greg KH, and
> based on that send a
> separate patch to linux-bluetooth for the btwilink..
Actually send everything to Greg KH, will work out better. Otherwise you will
have to one release cycle to merge it here (until the other patches reach my
tree). Then I just Ack it.
--
Gustavo F. Padovan
http://profusion.mobi
^ permalink raw reply
* Re: [RFC 2/2] Bluetooth: btwilink driver
From: Gustavo F. Padovan @ 2011-01-21 17:57 UTC (permalink / raw)
To: pavan_savoy; +Cc: marcel, linux-kernel, linux-bluetooth
In-Reply-To: <1294138788-10307-3-git-send-email-pavan_savoy@ti.com>
Hi Pavan,
* pavan_savoy@ti.com <pavan_savoy@ti.com> [2011-01-04 04:59:48 -0600]:
> From: Pavan Savoy <pavan_savoy@ti.com>
>
> -- patch description --
>
> This is the bluetooth protocol driver for the TI WiLink7 chipsets.
> Texas Instrument's WiLink chipsets combine wireless technologies
> like BT, FM, GPS and WLAN onto a single chip.
>
> This Bluetooth driver works on top of the TI_ST shared transport
> line discipline driver which also allows other drivers like
> FM V4L2 and GPS character driver to make use of the same UART interface.
>
> Kconfig and Makefile modifications to enable the Bluetooth
> driver for Texas Instrument's WiLink 7 chipset.
>
> Signed-off-by: Pavan Savoy <pavan_savoy@ti.com>
> ---
> drivers/bluetooth/Kconfig | 10 +
> drivers/bluetooth/Makefile | 1 +
> drivers/bluetooth/btwilink.c | 397 ++++++++++++++++++++++++++++++++++++++++++
> 3 files changed, 408 insertions(+), 0 deletions(-)
> create mode 100644 drivers/bluetooth/btwilink.c
>
> diff --git a/drivers/bluetooth/Kconfig b/drivers/bluetooth/Kconfig
> index 02deef4..8e0de9a 100644
> --- a/drivers/bluetooth/Kconfig
> +++ b/drivers/bluetooth/Kconfig
> @@ -219,4 +219,14 @@ config BT_ATH3K
> Say Y here to compile support for "Atheros firmware download driver"
> into the kernel or say M to compile it as module (ath3k).
>
> +config BT_WILINK
> + tristate "Texas Instruments WiLink7 driver"
> + depends on TI_ST
> + help
> + This enables the Bluetooth driver for Texas Instrument's BT/FM/GPS
> + combo devices. This makes use of shared transport line discipline
> + core driver to communicate with the BT core of the combo chip.
> +
> + Say Y here to compile support for Texas Instrument's WiLink7 driver
> + into the kernel or say M to compile it as module.
> endmenu
> diff --git a/drivers/bluetooth/Makefile b/drivers/bluetooth/Makefile
> index 71bdf13..f4460f4 100644
> --- a/drivers/bluetooth/Makefile
> +++ b/drivers/bluetooth/Makefile
> @@ -18,6 +18,7 @@ obj-$(CONFIG_BT_HCIBTSDIO) += btsdio.o
> obj-$(CONFIG_BT_ATH3K) += ath3k.o
> obj-$(CONFIG_BT_MRVL) += btmrvl.o
> obj-$(CONFIG_BT_MRVL_SDIO) += btmrvl_sdio.o
> +obj-$(CONFIG_BT_WILINK) += btwilink.o
>
> btmrvl-y := btmrvl_main.o
> btmrvl-$(CONFIG_DEBUG_FS) += btmrvl_debugfs.o
> diff --git a/drivers/bluetooth/btwilink.c b/drivers/bluetooth/btwilink.c
> new file mode 100644
> index 0000000..0201aca
> --- /dev/null
> +++ b/drivers/bluetooth/btwilink.c
> @@ -0,0 +1,397 @@
> +/*
> + * Texas Instrument's Bluetooth Driver For Shared Transport.
> + *
> + * Bluetooth Driver acts as interface between HCI core and
> + * TI Shared Transport Layer.
> + *
> + * Copyright (C) 2009-2010 Texas Instruments
> + * Author: Raja Mani <raja_mani@ti.com>
> + * Pavan Savoy <pavan_savoy@ti.com>
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> + * GNU General Public License for more details.
> + *
> + * You should have received a copy of the GNU General Public License
> + * along with this program; if not, write to the Free Software
> + * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
> + *
> + */
> +
> +#include <linux/platform_device.h>
> +#include <net/bluetooth/bluetooth.h>
> +#include <net/bluetooth/hci_core.h>
> +
> +#include <linux/ti_wilink_st.h>
> +
> +/* Bluetooth Driver Version */
> +#define VERSION "1.0"
> +
> +/* Number of seconds to wait for registration completion
> + * when ST returns PENDING status.
> + */
> +#define BT_REGISTER_TIMEOUT 6000 /* 6 sec */
> +
> +/**
> + * struct ti_st - driver operation structure
> + * @hdev: hci device pointer which binds to bt driver
> + * @reg_status: ST registration callback status
> + * @st_write: write function provided by the ST driver
> + * to be used by the driver during send_frame.
> + * @wait_reg_completion - completion sync between ti_st_open
> + * and ti_st_registration_completion_cb.
> + */
> +struct ti_st {
> + struct hci_dev *hdev;
> + char reg_status;
> + long (*st_write) (struct sk_buff *);
> + struct completion wait_reg_completion;
> +};
> +
> +/* Increments HCI counters based on pocket ID (cmd,acl,sco) */
> +static inline void ti_st_tx_complete(struct ti_st *hst, int pkt_type)
> +{
> + struct hci_dev *hdev = hst->hdev;
> +
> + /* Update HCI stat counters */
> + switch (pkt_type) {
> + case HCI_COMMAND_PKT:
> + hdev->stat.cmd_tx++;
> + break;
> +
> + case HCI_ACLDATA_PKT:
> + hdev->stat.acl_tx++;
> + break;
> +
> + case HCI_SCODATA_PKT:
> + hdev->stat.sco_tx++;
> + break;
> + }
> +}
> +
> +/* ------- Interfaces to Shared Transport ------ */
> +
> +/* Called by ST layer to indicate protocol registration completion
> + * status.ti_st_open() function will wait for signal from this
> + * API when st_register() function returns ST_PENDING.
> + */
> +static void st_registration_completion_cb(void *priv_data, char data)
> +{
> + struct ti_st *lhst = priv_data;
> +
> + /* Save registration status for use in ti_st_open() */
> + lhst->reg_status = data;
> + /* complete the wait in ti_st_open() */
> + complete(&lhst->wait_reg_completion);
> +}
> +
> +/* Called by Shared Transport layer when receive data is
> + * available */
> +static long st_receive(void *priv_data, struct sk_buff *skb)
> +{
> + struct ti_st *lhst = priv_data;
> + int err;
> +
> + if (!skb)
> + return -EFAULT;
> +
> + if (!lhst) {
> + kfree_skb(skb);
> + return -EFAULT;
> + }
> +
> + skb->dev = (void *) lhst->hdev;
> +
> + /* Forward skb to HCI core layer */
> + err = hci_recv_frame(skb);
> + if (err < 0) {
> + BT_ERR("Unable to push skb to HCI core(%d)", err);
> + return err;
> + }
> +
> + lhst->hdev->stat.byte_rx += skb->len;
> +
> + return 0;
> +}
> +
> +/* ------- Interfaces to HCI layer ------ */
> +/* protocol structure registered with shared transport */
> +static struct st_proto_s ti_st_proto[3] = {
> + {
> + .chnl_id = 0x02, /* ACL */
Please create macros for the chnl_id in the core driver.
> + .recv = st_receive,
> + .reg_complete_cb = st_registration_completion_cb,
> + .hdr_len = 4,
> + .offset_len_in_hdr = 2,
> + .len_size = 2,
> + .reserve = 8,
> + },
> + {
> + .chnl_id = 0x03, /* SCO */
> + .recv = st_receive,
> + .reg_complete_cb = st_registration_completion_cb,
> + .hdr_len = 3,
> + .offset_len_in_hdr = 2,
> + .len_size = 1,
> + .reserve = 8,
> + },
> + {
> + .chnl_id = 0x04, /* HCI Events */
> + .recv = st_receive,
> + .reg_complete_cb = st_registration_completion_cb,
> + .hdr_len = 2,
> + .offset_len_in_hdr = 1,
> + .len_size = 1,
> + .reserve = 8,
> + },
> +};
> +
> +/* Called from HCI core to initialize the device */
> +static int ti_st_open(struct hci_dev *hdev)
> +{
> + unsigned long timeleft;
> + struct ti_st *hst;
> + int err, i;
> +
> + BT_DBG("%s %p", hdev->name, hdev);
Blank line here.
> + if (test_and_set_bit(HCI_RUNNING, &hdev->flags)) {
> + BT_ERR("btwilink already opened");
No need for this BT_ERR. It already returns -EBUSY.
> + return -EBUSY;
> + }
> +
> + /* provide contexts for callbacks from ST */
> + hst = hdev->driver_data;
> +
> + for (i = 0; i < 3; i++) {
> + ti_st_proto[i].priv_data = hst;
> + ti_st_proto[i].max_frame_size = HCI_MAX_FRAME_SIZE;
> +
> + err = st_register(&ti_st_proto[i]);
Let's change the order here. First
if (!err)
goto to "hst->st_write = ti_st_proto[i].write"
if (err != -EINPROGRESS) {
}
then here code for err == -EINPROGRESS
> + if (err == -EINPROGRESS) {
> + /* ST is busy with either protocol
> + * registration or firmware download.
> + */
> + /* Prepare wait-for-completion handler data structures.
> + */
> + init_completion(&hst->wait_reg_completion);
> +
> + /* Reset ST registration callback status flag,
> + * this value will be updated in
> + * ti_st_registration_completion_cb()
> + * function whenever it called from ST driver.
> + */
> + hst->reg_status = -EINPROGRESS;
> +
> + BT_DBG("waiting for registration "
> + "completion signal from ST");
> + timeleft = wait_for_completion_timeout
> + (&hst->wait_reg_completion,
> + msecs_to_jiffies(BT_REGISTER_TIMEOUT));
> + if (!timeleft) {
> + clear_bit(HCI_RUNNING, &hdev->flags);
> + BT_ERR("Timeout(%d sec),didn't get reg "
> + "completion signal from ST",
> + BT_REGISTER_TIMEOUT / 1000);
> + return -ETIMEDOUT;
> + }
> +
> + /* Is ST registration callback
> + * called with ERROR status? */
> + if (hst->reg_status != 0) {
> + clear_bit(HCI_RUNNING, &hdev->flags);
> + BT_ERR("ST registration completed with invalid "
> + "status %d", hst->reg_status);
> + return -EAGAIN;
> + }
> + err = 0;
remove this err = 0; and return 0 in the end of the function.
> + } else if (err != 0) {
> + clear_bit(HCI_RUNNING, &hdev->flags);
> + BT_ERR("st_register failed %d", err);
> + return err;
> + }
Blank line here.
> + hst->st_write = ti_st_proto[i].write;
> + if (!hst->st_write) {
> + BT_ERR("undefined ST write function");
> + clear_bit(HCI_RUNNING, &hdev->flags);
> +
> + /* Undo registration with ST */
> + err = st_unregister(&ti_st_proto[i]);
> + if (err)
> + BT_ERR("st_unregister() failed with "
> + "error %d", err);
You are unregistering only one protocol here, if the fail happens in the third
one you will leak two of them.
> +
> + hst->st_write = NULL;
> + /* ti_st_proto.write is filled up by the
> + * underlying shared transport driver
> + * upon registration
> + */
> + return err;
> + }
> + }
> +
> + return err;
> +}
> +
> +/* Close device */
> +static int ti_st_close(struct hci_dev *hdev)
> +{
> + int err, i;
> + struct ti_st *hst = hdev->driver_data;
> +
> + if (!test_and_clear_bit(HCI_RUNNING, &hdev->flags))
> + return 0;
> +
> + for (i = 0; i < 3; i++) {
> + /* continue to unregister from transport */
This comment is pointless.
> + err = st_unregister(&ti_st_proto[i]);
> + if (err)
> + BT_ERR("st_unregister() failed with error %d", err);
> + }
> +
> + hst->st_write = NULL;
> +
> + return err;
err is will report the error if it happens in the first or second unregister.
--
Gustavo F. Padovan
http://profusion.mobi
^ permalink raw reply
* Re: [PATCH 5/7] Add transport option to interactive gatttool
From: Anderson Lizardo @ 2011-01-21 17:50 UTC (permalink / raw)
To: Sheldon Demario; +Cc: linux-bluetooth
In-Reply-To: <1295617586-3398-5-git-send-email-sheldon.demario@openbossa.org>
On Fri, Jan 21, 2011 at 9:46 AM, Sheldon Demario
<sheldon.demario@openbossa.org> wrote:
> ---
> attrib/igatttool.c | 18 ++++++++++++++++++
> 1 files changed, 18 insertions(+), 0 deletions(-)
>
> diff --git a/attrib/igatttool.c b/attrib/igatttool.c
> index 29290ed..e0d8b44 100644
> --- a/attrib/igatttool.c
> +++ b/attrib/igatttool.c
> @@ -137,6 +137,23 @@ static void cmd_exit(char **cmd)
> g_main_loop_quit(main_loop);
> }
>
> +static void cmd_transport(char **cmd)
You can call this parameter "opt" for consistency with other commands.
> +{
> + if (cmd[1] == NULL)
> + return;
> +
> + if (conn_state != STATE_DISCONNECTED)
> + return;
> +
> + if (strcasecmp(cmd[1], "le") == 0)
> + opt_le = TRUE;
> + else if (strcasecmp(cmd[1], "br") == 0)
> + opt_le = FALSE;
I've noticed every command callback has the two lines below. Would be
possible to move them to after the callback is called ?
> +
> + rl_set_prompt(get_prompt());
> + rl_redisplay();
> +}
> +
Regards,
--
Anderson Lizardo
OpenBossa Labs - INdT
Manaus - Brazil
^ permalink raw reply
* Re: [RFC 0/2] remove BT references from TI_ST
From: Pavan Savoy @ 2011-01-21 17:40 UTC (permalink / raw)
To: Gustavo F. Padovan; +Cc: marcel, linux-kernel, linux-bluetooth
In-Reply-To: <20110121171857.GC2400@joana>
Gustavo,
On Fri, Jan 21, 2011 at 10:48 PM, Gustavo F. Padovan
<padovan@profusion.mobi> wrote:
> Hi Pavan,
>
> * Pavan Savoy <pavan_savoy@sify.com> [2011-01-19 23:56:29 +0530]:
>
>> Gustavo,
>>
>> On Tue, Jan 4, 2011 at 4:29 PM, =C2=A0<pavan_savoy@ti.com> wrote:
>> > From: Pavan Savoy <pavan_savoy@ti.com>
>> >
>> > Gustavo,
>> >
>> > Based on your comments, that the underlying shared transport driver
>> > for btwilink driver made use of the BT references to peek into the pac=
kets
>> > I have modified the TI_ST.
>>
>> Since there lacks a generic way to parse the packets coming in from the
>> UART into BT, FM or GPS, we have to look into the data to fragment assem=
bled
>> data or assemble fragmented data.
>>
>> Please have a look, Please suggest whether something like this is requir=
ed,
>> If not, please also suggest, if including BT headers is a problem ?
>
> Not really. The real problem is to break the abstraction between drivers
> layers (core and bluetooth drivers in this case)
ok, fine. Although I myself personally would prefer the older way ...
But its fine, I understand why references to bluetooth headers doesn't look=
good
at shared transport level...
>>
>> Because I just include the BT headers and don't have a build
>> dependency as such on
>> BT/HCI and don't use any functions from hci_core in my shared transport =
driver.
>>
>> > For this reason, Now the above lying protocol drivers like BT, FM and =
GPS
>> > would send details about their packet types and header information whi=
ch
>> > would assist shared transport driver to parse the data.
>
> Fair enough. This new approach is way better.
Ok, So there is no problem with BT driver doing this multiple calls to
st_register (or a single call
with info array of ACL, SCO, Event to st_register) ?
This would only hold true for BT.
For FM or GPS there would be only 1 set of info sent across from protocol
drivers to the shared transport drivers...
Also, during firmware download, is hard-coding of few parameters
pertaining to HCI-Event alright ?
because this needs to happen even if say BT doesn't plan to use the
shared transport and only FM
V4L2 is at works..
>> >
>> > Gustavo, please also notice the change in btwilink driver in and aroun=
d,
>> > st_register and suggest if something like this is OK.
>> > btwilink can also be modified to send in all the packet specific data
>> > in one shot, if that is preferred.
>> >
>> > Please review and provide comments..
>> >
>> > Note:
>> > If this is alright, I will send out a modified patch with updated
>> > subject to lkml/Greg for linux-next.
>
> Ok. Go ahead. Then tell me when I'll be able to apply your patch. (I need=
to
> have the core modifications in my tree first). Or I just ack the patch an=
d it
> finds its way to mainline through Greg's tree.
Yes, I will post a patch to lkml against linux-next to greg KH, and
based on that send a
separate patch to linux-bluetooth for the btwilink..
> --
> Gustavo F. Padovan
> http://profusion.mobi
>
^ permalink raw reply
* Re: [Patch] Kill off warning: ‘inline’ is not at beginning of declaration
From: Joel Becker @ 2011-01-21 17:31 UTC (permalink / raw)
To: Jesper Juhl
Cc: linux-kernel, trivial, alsa-devel, linux-wireless, netdev,
ocfs2-devel, linux-edac, linux-bluetooth, oprofile-list,
Andi Kleen, David Teigland, Jens Axboe, Stephen Hemminger,
Greg Kroah-Hartman, Takashi Iwai, Jaroslav Kysela,
John W. Linville, Johannes Berg, Patrick McHardy,
Hideaki YOSHIFUJI, James Morris, Pekka Savola (ipv6),
Alexey Kuznetsov, David S. Miller, Frederic Weisbecker,
Mark Fasheh, Mauro Carvalho Chehab, Gustavo F. Padovan,
Marcel Holtmann, x86, H. Peter Anvin, Ingo Molnar,
Thomas Gleixner, Robert Richter
In-Reply-To: <alpine.LNX.2.00.1101170000270.13377@swampdragon.chaosbits.net>
On Mon, Jan 17, 2011 at 12:09:38AM +0100, Jesper Juhl wrote:
> Fix a bunch of
> warning: ‘inline’ is not at beginning of declaration
> messages when building a 'make allyesconfig' kernel with -Wextra.
>
> These warnings are trivial to kill, yet rather annoying when building with
> -Wextra.
> The more we can cut down on pointless crap like this the better (IMHO).
>
> A previous patch to do this for a 'allnoconfig' build has already been
> merged. This just takes the cleanup a little further.
>
> Signed-off-by: Jesper Juhl <jj@chaosbits.net>
Acked for fs/ocfs2
Joel
--
^ permalink raw reply
* Re: [RFC 0/2] remove BT references from TI_ST
From: Gustavo F. Padovan @ 2011-01-21 17:18 UTC (permalink / raw)
To: Pavan Savoy; +Cc: marcel, linux-kernel, linux-bluetooth, Pavan Savoy
In-Reply-To: <AANLkTinPC-i2xi9pCQ-RzGWuwZ5uTM3NXG7y6gwTnPYv@mail.gmail.com>
Hi Pavan,
* Pavan Savoy <pavan_savoy@sify.com> [2011-01-19 23:56:29 +0530]:
> Gustavo,
>
> On Tue, Jan 4, 2011 at 4:29 PM, <pavan_savoy@ti.com> wrote:
> > From: Pavan Savoy <pavan_savoy@ti.com>
> >
> > Gustavo,
> >
> > Based on your comments, that the underlying shared transport driver
> > for btwilink driver made use of the BT references to peek into the packets
> > I have modified the TI_ST.
>
> Since there lacks a generic way to parse the packets coming in from the
> UART into BT, FM or GPS, we have to look into the data to fragment assembled
> data or assemble fragmented data.
>
> Please have a look, Please suggest whether something like this is required,
> If not, please also suggest, if including BT headers is a problem ?
Not really. The real problem is to break the abstraction between drivers
layers (core and bluetooth drivers in this case)
>
> Because I just include the BT headers and don't have a build
> dependency as such on
> BT/HCI and don't use any functions from hci_core in my shared transport driver.
>
> > For this reason, Now the above lying protocol drivers like BT, FM and GPS
> > would send details about their packet types and header information which
> > would assist shared transport driver to parse the data.
Fair enough. This new approach is way better.
> >
> > Gustavo, please also notice the change in btwilink driver in and around,
> > st_register and suggest if something like this is OK.
> > btwilink can also be modified to send in all the packet specific data
> > in one shot, if that is preferred.
> >
> > Please review and provide comments..
> >
> > Note:
> > If this is alright, I will send out a modified patch with updated
> > subject to lkml/Greg for linux-next.
Ok. Go ahead. Then tell me when I'll be able to apply your patch. (I need to
have the core modifications in my tree first). Or I just ack the patch and it
finds its way to mainline through Greg's tree.
--
Gustavo F. Padovan
http://profusion.mobi
^ permalink raw reply
* Re: [PATCHv4] Bluetooth: Use non-flushable by default L2CAP data packets
From: Gustavo F. Padovan @ 2011-01-21 17:10 UTC (permalink / raw)
To: Emeltchenko Andrei; +Cc: linux-bluetooth
In-Reply-To: <1294046076-3712-2-git-send-email-Andrei.Emeltchenko.news@gmail.com>
Hi Andrei,
* Emeltchenko Andrei <Andrei.Emeltchenko.news@gmail.com> [2011-01-03 11:14:36 +0200]:
> From: Andrei Emeltchenko <andrei.emeltchenko@nokia.com>
>
> Modification of Nick Pelly <npelly@google.com> patch.
>
> With Bluetooth 2.1 ACL packets can be flushable or non-flushable. This commit
> makes ACL data packets non-flushable by default on compatible chipsets, and
> adds the BT_FLUSHABLE socket option to explicitly request flushable ACL
> data packets for a given L2CAP socket. This is useful for A2DP data which can
> be safely discarded if it can not be delivered within a short time (while
> other ACL data should not be discarded).
>
> Note that making ACL data flushable has no effect unless the automatic flush
> timeout for that ACL link is changed from its default of 0 (infinite).
>
> Default packet types (for compatible chipsets):
> Frame 34: 13 bytes on wire (104 bits), 13 bytes captured (104 bits)
> Bluetooth HCI H4
> Bluetooth HCI ACL Packet
> .... 0000 0000 0010 = Connection Handle: 0x0002
> ..00 .... .... .... = PB Flag: First Non-automatically Flushable Packet (0)
> 00.. .... .... .... = BC Flag: Point-To-Point (0)
> Data Total Length: 8
> Bluetooth L2CAP Packet
>
> After setting BT_FLUSHABLE
> (sock.setsockopt(274 /*SOL_BLUETOOTH*/, 8 /* BT_FLUSHABLE */, 1 /* flush */))
> Frame 34: 13 bytes on wire (104 bits), 13 bytes captured (104 bits)
> Bluetooth HCI H4
> Bluetooth HCI ACL Packet
> .... 0000 0000 0010 = Connection Handle: 0x0002
> ..10 .... .... .... = PB Flag: First Automatically Flushable Packet (2)
> 00.. .... .... .... = BC Flag: Point-To-Point (0)
> Data Total Length: 8
> Bluetooth L2CAP Packet
>
> Signed-off-by: Andrei Emeltchenko <andrei.emeltchenko@nokia.com>
> ---
> include/net/bluetooth/bluetooth.h | 5 +++
> include/net/bluetooth/hci.h | 2 +
> include/net/bluetooth/hci_core.h | 1 +
> include/net/bluetooth/l2cap.h | 1 +
> net/bluetooth/hci_core.c | 7 +++-
> net/bluetooth/l2cap.c | 59 ++++++++++++++++++++++++++++++++++--
> 6 files changed, 69 insertions(+), 6 deletions(-)
Patch has been applied to bluetooth-next-2.6. Thanks.
--
Gustavo F. Padovan
http://profusion.mobi
^ permalink raw reply
* Re: [PATCHv2] Bluetooth: fix crash by disabling tasklet in sock accept
From: Gustavo F. Padovan @ 2011-01-21 16:11 UTC (permalink / raw)
To: Emeltchenko Andrei; +Cc: linux-bluetooth
In-Reply-To: <1295512687-30352-1-git-send-email-Andrei.Emeltchenko.news@gmail.com>
Hi Andrei,
* Emeltchenko Andrei <Andrei.Emeltchenko.news@gmail.com> [2011-01-20 10:38:07 +0200]:
> From: Andrei Emeltchenko <andrei.emeltchenko@nokia.com>
>
> Crash can happen when tasklet handling connect/disconnect requests
> preempts socket accept. Can be reproduced with "l2test -r" on one
> side and several "l2test -c -b 1000 -i hci0 -P 10 <bdaddr>" on the
> other side.
>
> disable taskets in socket accept and change lock_sock and release_sock
> to bh_lock_sock and bh_unlock_sock since we have to use spinlocks and
> there is no need to mark sock as owned by user.
>
> ...
> [ 3555.897247] Unable to handle kernel NULL pointer dereference at virtual
> address 000000bc
> [ 3555.915039] pgd = cab9c000
> [ 3555.917785] [000000bc] *pgd=8bf3d031, *pte=00000000, *ppte=00000000
> [ 3555.928314] Internal error: Oops: 17 [#1] PREEMPT
> [ 3555.999786] CPU: 0 Not tainted (2.6.32.21-13874-g67918ef #65)
> ...
> [ 3556.005981] PC is at bt_accept_unlink+0x20/0x58 [bluetooth]
> [ 3556.011627] LR is at bt_accept_dequeue+0x3c/0xe8 [bluetooth]
> ...
> [ 3556.161285] [<bf0007fc>] (bt_accept_unlink+0x20/0x58 [bluetooth]) from
> [<bf000870>] (bt_accept_dequeue+0x3c/0xe8 [bluetooth])
> [ 3556.172729] [<bf000870>] (bt_accept_dequeue+0x3c/0xe8 [bluetooth]) from
> [<bf324df8>] (l2cap_sock_accept+0x100/0x15c [l2cap])
> [ 3556.184082] [<bf324df8>] (l2cap_sock_accept+0x100/0x15c [l2cap]) from
> [<c026a0a8>] (sys_accept4+0x120/0x1e0)
> [ 3556.193969] [<c026a0a8>] (sys_accept4+0x120/0x1e0) from [<c002c9a0>]
> (ret_fast_syscall+0x0/0x2c)
> [ 3556.202819] Code: e5813000 e5901164 e580c160 e580c15c (e1d13bbc)
> ...
>
> Signed-off-by: Andrei Emeltchenko <andrei.emeltchenko@nokia.com>
> ---
> net/bluetooth/af_bluetooth.c | 12 ++++++++----
> 1 files changed, 8 insertions(+), 4 deletions(-)
>
> diff --git a/net/bluetooth/af_bluetooth.c b/net/bluetooth/af_bluetooth.c
> index a6732b5..f545566 100644
> --- a/net/bluetooth/af_bluetooth.c
> +++ b/net/bluetooth/af_bluetooth.c
> @@ -199,14 +199,15 @@ struct sock *bt_accept_dequeue(struct sock *parent, struct socket *newsock)
>
> BT_DBG("parent %p", parent);
>
> + local_bh_disable();
> list_for_each_safe(p, n, &bt_sk(parent)->accept_q) {
> sk = (struct sock *) list_entry(p, struct bt_sock, accept_q);
>
> - lock_sock(sk);
> + bh_lock_sock(sk);
>
> /* FIXME: Is this check still needed */
> if (sk->sk_state == BT_CLOSED) {
> - release_sock(sk);
> + bh_unlock_sock(sk);
> bt_accept_unlink(sk);
> continue;
> }
> @@ -216,12 +217,15 @@ struct sock *bt_accept_dequeue(struct sock *parent, struct socket *newsock)
> bt_accept_unlink(sk);
> if (newsock)
> sock_graft(sk, newsock);
> - release_sock(sk);
Please add an extra line here, them patch should be ok to upstream.
> + bh_unlock_sock(sk);
> + local_bh_enable();
> return sk;
--
Gustavo F. Padovan
http://profusion.mobi
^ permalink raw reply
* Re: How to close bluetooth? Using rfkill?
From: zhangfei gao @ 2011-01-21 14:38 UTC (permalink / raw)
To: linux-bluetooth, Marcel Holtmann; +Cc: Johan Hedberg
In-Reply-To: <AANLkTi=z1DPguiO7B39CRoj-wqi5r3nXLixCe3Yo34aV@mail.gmail.com>
On Fri, Jan 21, 2011 at 12:51 AM, zhangfei gao <zhangfei.gao@gmail.com> wrote:
> Hi Johan,
>
> Is there any general method to open/close bluetooth, using rfkill or
> pm_runtime_get/put_* API.
>
> Currently we use rfkill to close bluetooth, however we met dead lock
> issue, for mutex_lock(&rfkill_global_mutex).
> So we use workaround to rmmod bt.ko first, or revert the rfkill patch
> in hci_core.c.
>
> BT/WIFI device have chip select pin, we register one rfkill with
> sd8x_set_block, and control chip select pin to open/close bt/wifi/fm.
> for example:
> rfkill unblock bluetooth to open bt
> rfkill block bluetooth to close bt
>
> When "rfkill block bluetooth",
> rfkill_fop_write->mutex_lock(&rfkill_global_mutex)->rfkill_set_block->sd8x_set_block->waiting
> for card is freed.
> BT driver will call
> hci_unregister_dev->rfkill_unregister->mutex_lock(&rfkill_global_mutex);
> So mutex_lock(&rfkill_global_mutex) will be dead locked.
>
> If so, do we have to use other method to control chip select pin to
> control bt power, such as pm_runtime_get/put_* API.
>
> Thanks in advance.
>
Hi, Marcel
Do you have some suggestion?
When we use "rfkill block bluetooth" to disable bt, bt driver call
hci_unregister_dev to free driver.
The dead lock happens for acquiring mutex_lock(&rfkill_global_mutex).
One in rfkill_unregister from hci_unregister_dev, the other in
rfkill_fop_write from "rfkill block bluetooth" .
Is this the correct method to open/close bluetooth.
Thanks
^ permalink raw reply
* [PATCH 7/7] Initial primary service discovery in igatttool
From: Sheldon Demario @ 2011-01-21 13:46 UTC (permalink / raw)
To: linux-bluetooth; +Cc: Sheldon Demario
In-Reply-To: <1295617586-3398-1-git-send-email-sheldon.demario@openbossa.org>
---
Makefile.am | 3 ++-
attrib/igatttool.c | 44 +++++++++++++++++++++++++++++++++++++++++++-
2 files changed, 45 insertions(+), 2 deletions(-)
diff --git a/Makefile.am b/Makefile.am
index f9e05fd..ef9afb2 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -188,7 +188,8 @@ bin_PROGRAMS += attrib/igatttool
attrib_igatttool_SOURCES = attrib/igatttool.c btio/btio.c \
attrib/gtcommon.h attrib/gtcommon.c \
- src/glib-helper.h src/glib-helper.c
+ src/glib-helper.h src/glib-helper.c \
+ attrib/gattrib.c attrib/att.c attrib/gatt.c
attrib_igatttool_LDADD = lib/libbluetooth.la @GLIB_LIBS@ @READLINE_LIBS@
endif
diff --git a/attrib/igatttool.c b/attrib/igatttool.c
index e0d8b44..d3084d6 100644
--- a/attrib/igatttool.c
+++ b/attrib/igatttool.c
@@ -30,8 +30,12 @@
#include <bluetooth/bluetooth.h>
#include <bluetooth/hci.h>
#include <bluetooth/sdp.h>
+#include <bluetooth/sdp_lib.h>
+#include "gattrib.h"
+#include "gatt.h"
#include "btio.h"
+#include "att.h"
#include "gtcommon.h"
@@ -39,6 +43,7 @@ GIOChannel *iochannel = NULL;
GMainLoop *main_loop = NULL;
gboolean status = FALSE;
GString *prompt = NULL;
+GAttrib *attrib = NULL;
enum state {
STATE_DISCONNECTED,
@@ -96,9 +101,32 @@ static void connect_cb(GIOChannel *io, GError *gerr, gpointer user_data)
return;
}
+ attrib = g_attrib_new(iochannel);
set_state(STATE_CONNECTED);
}
+static void primary_all_cb(GSList *services, guint8 status, gpointer user_data)
+{
+ GSList *l;
+
+ if (status) {
+ show_message("Discover all primary services failed: %s\n",
+ att_ecode2str(status));
+ return;
+ }
+
+ rl_save_prompt();
+ for (l = services; l; l = l->next) {
+ struct att_primary *prim = l->data;
+ rl_message("attr handle = 0x%04x, end grp handle = 0x%04x "
+ "uuid: %s\n", prim->start, prim->end, prim->uuid);
+ rl_on_new_line();
+ }
+
+ rl_restore_prompt();
+ rl_forced_update_display();
+}
+
static void cmd_connect(char **cmd)
{
if (conn_state != STATE_DISCONNECTED)
@@ -125,6 +153,9 @@ static void cmd_disconnect(char **cmd)
if (conn_state == STATE_DISCONNECTED)
return;
+ g_attrib_unref(attrib);
+ attrib = NULL;
+
g_io_channel_shutdown(iochannel, FALSE, NULL);
g_io_channel_unref(iochannel);
iochannel = NULL;
@@ -166,6 +197,16 @@ static void cmd_psm(char **opt)
rl_redisplay();
}
+static void cmd_primary(char **cmd)
+{
+ if (conn_state != STATE_CONNECTED) {
+ show_message("Fail: disconnected\n");
+ return;
+ }
+
+ gatt_discover_primary(attrib, NULL, primary_all_cb, NULL);
+}
+
static struct {
char *cmd;
void (*func)(char **cmd);
@@ -177,6 +218,7 @@ static struct {
{ "exit", cmd_exit, NULL, "Exit"},
{ "transport", cmd_transport, "<LE | BR>", "Set transport"},
{ "psm", cmd_psm, "<psm>", "Set psm"},
+ { "primary", cmd_primary, NULL, "Primary Service Discovery"},
{ NULL, NULL, NULL, NULL}
};
@@ -234,7 +276,6 @@ int main(int argc, char *argv[])
}
main_loop = g_main_loop_new(NULL, FALSE);
-
prompt = g_string_new(NULL);
pchan = g_io_channel_unix_new(fileno(stdin));
@@ -247,6 +288,7 @@ int main(int argc, char *argv[])
g_main_loop_run(main_loop);
cmd_disconnect(NULL);
+ g_attrib_unref(attrib);
rl_callback_handler_remove();
g_io_channel_unref(pchan);
g_main_loop_unref(main_loop);
--
1.7.1
^ permalink raw reply related
* [PATCH 6/7] Add autoconf macro for interactive gatttool
From: Sheldon Demario @ 2011-01-21 13:46 UTC (permalink / raw)
To: linux-bluetooth; +Cc: Claudio Takahasi
In-Reply-To: <1295617586-3398-1-git-send-email-sheldon.demario@openbossa.org>
From: Claudio Takahasi <claudio.takahasi@openbossa.org>
Interactive gatttool will be built automatically if readline library
is found and attribute plugin is enabled.
---
Makefile.am | 8 ++++++--
acinclude.m4 | 8 ++++++++
configure.ac | 1 +
3 files changed, 15 insertions(+), 2 deletions(-)
diff --git a/Makefile.am b/Makefile.am
index 79365ad..f9e05fd 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -175,7 +175,7 @@ builtin_sources += plugins/service.c
endif
if ATTRIBPLUGIN
-bin_PROGRAMS += attrib/gatttool attrib/igatttool
+bin_PROGRAMS += attrib/gatttool
attrib_gatttool_SOURCES = attrib/gatttool.c attrib/att.c attrib/gatt.c \
attrib/gattrib.c btio/btio.c \
@@ -183,10 +183,14 @@ attrib_gatttool_SOURCES = attrib/gatttool.c attrib/att.c attrib/gatt.c \
attrib/gtcommon.h attrib/gtcommon.c
attrib_gatttool_LDADD = lib/libbluetooth.la @GLIB_LIBS@
+if IGATTTOOL
+bin_PROGRAMS += attrib/igatttool
+
attrib_igatttool_SOURCES = attrib/igatttool.c btio/btio.c \
attrib/gtcommon.h attrib/gtcommon.c \
src/glib-helper.h src/glib-helper.c
-attrib_igatttool_LDADD = lib/libbluetooth.la @GLIB_LIBS@ -lreadline
+attrib_igatttool_LDADD = lib/libbluetooth.la @GLIB_LIBS@ @READLINE_LIBS@
+endif
builtin_modules += attrib
builtin_sources += attrib/main.c \
diff --git a/acinclude.m4 b/acinclude.m4
index ecf4b4b..2b4b515 100644
--- a/acinclude.m4
+++ b/acinclude.m4
@@ -153,6 +153,13 @@ AC_DEFUN([AC_PATH_SNDFILE], [
AC_SUBST(SNDFILE_LIBS)
])
+AC_DEFUN([AC_PATH_READLINE], [
+ AC_CHECK_LIB(readline, main,
+ [ readline_found=yes
+ AC_SUBST(READLINE_LIBS, "-lreadline")
+ ], readline_found=no)
+])
+
AC_DEFUN([AC_PATH_OUI], [
AC_ARG_WITH(ouifile,
AS_HELP_STRING([--with-ouifile=PATH],[Path to the oui.txt file @<:@auto@:>@]),
@@ -357,6 +364,7 @@ AC_DEFUN([AC_ARG_BLUEZ], [
AM_CONDITIONAL(MCAP, test "${health_enable}" = "yes")
AM_CONDITIONAL(HAL, test "${hal_enable}" = "yes")
AM_CONDITIONAL(ATTRIBPLUGIN, test "${attrib_enable}" = "yes")
+ AM_CONDITIONAL(IGATTTOOL, test "${attrib_enable}" = "yes" && test "${readline_found}" = "yes")
AM_CONDITIONAL(ECHOPLUGIN, test "no" = "yes")
AM_CONDITIONAL(PNATPLUGIN, test "${pnat_enable}" = "yes")
AM_CONDITIONAL(TRACER, test "${tracer_enable}" = "yes")
diff --git a/configure.ac b/configure.ac
index 4a979f0..6925344 100644
--- a/configure.ac
+++ b/configure.ac
@@ -41,6 +41,7 @@ AC_PATH_ALSA
AC_PATH_GSTREAMER
AC_PATH_USB
AC_PATH_SNDFILE
+AC_PATH_READLINE
AC_PATH_OUI
AC_ARG_BLUEZ
--
1.7.1
^ permalink raw reply related
* [PATCH 5/7] Add transport option to interactive gatttool
From: Sheldon Demario @ 2011-01-21 13:46 UTC (permalink / raw)
To: linux-bluetooth; +Cc: Sheldon Demario
In-Reply-To: <1295617586-3398-1-git-send-email-sheldon.demario@openbossa.org>
---
attrib/igatttool.c | 18 ++++++++++++++++++
1 files changed, 18 insertions(+), 0 deletions(-)
diff --git a/attrib/igatttool.c b/attrib/igatttool.c
index 29290ed..e0d8b44 100644
--- a/attrib/igatttool.c
+++ b/attrib/igatttool.c
@@ -137,6 +137,23 @@ static void cmd_exit(char **cmd)
g_main_loop_quit(main_loop);
}
+static void cmd_transport(char **cmd)
+{
+ if (cmd[1] == NULL)
+ return;
+
+ if (conn_state != STATE_DISCONNECTED)
+ return;
+
+ if (strcasecmp(cmd[1], "le") == 0)
+ opt_le = TRUE;
+ else if (strcasecmp(cmd[1], "br") == 0)
+ opt_le = FALSE;
+
+ rl_set_prompt(get_prompt());
+ rl_redisplay();
+}
+
static void cmd_psm(char **opt)
{
if (opt[1] == NULL)
@@ -158,6 +175,7 @@ static struct {
{ "connect", cmd_connect, "<bdaddr>", "Connect"},
{ "disconnect", cmd_disconnect, NULL, "Disconnect"},
{ "exit", cmd_exit, NULL, "Exit"},
+ { "transport", cmd_transport, "<LE | BR>", "Set transport"},
{ "psm", cmd_psm, "<psm>", "Set psm"},
{ NULL, NULL, NULL, NULL}
};
--
1.7.1
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox