Linux bluetooth development
 help / color / mirror / Atom feed
* [PATCH v3 8/8] Bluetooth: Add Slave Page Response Timeout Event
From: Dohyun Pyun @ 2013-10-02 12:09 UTC (permalink / raw)
  To: linux-bluetooth; +Cc: steve.jun, DoHyun Pyun, C S Bhargava
In-Reply-To: <1380715758-10334-1-git-send-email-dh79.pyun@samsung.com>

From: DoHyun Pyun <dh79.pyun@samsung.com>

The Slave Page Response Timeout event indicates to the Host that a
slave page response timeout has occurred in the BR/EDR Controller.

The Core Spec Addendum 4 adds this command in part B Connectionless
Slave Broadcast.

Bluetooth Core Specification Addendum 4 - Page 110

"7.7.67 Synchronization Train Complete Event [New Section]
...
Note: this event will be generated if the slave BR/EDR Controller
responds to a page but does not receive the master FHS packet
(see Baseband, Section 8.3.3) within pagerespTO.

Event Parameters: NONE"

Signed-off-by: Dohyun Pyun <dh79.pyun@samsung.com>
Signed-off-by: C S Bhargava <cs.bhargava@samsung.com>
---
 include/net/bluetooth/hci.h | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/include/net/bluetooth/hci.h b/include/net/bluetooth/hci.h
index 03f2a91..b90eec5 100644
--- a/include/net/bluetooth/hci.h
+++ b/include/net/bluetooth/hci.h
@@ -1510,6 +1510,8 @@ struct hci_ev_sync_train_complete {
 	__u8	status;
 } __packed;
 
+#define HCI_EV_SLAVE_PAGE_RESP_TIMEOUT	0x54
+
 /* Low energy meta events */
 #define LE_CONN_ROLE_MASTER	0x00
 
-- 
1.8.1.2


^ permalink raw reply related

* [PATCH] Bluetooth: Increment management interface revision
From: Marcel Holtmann @ 2013-10-02 12:18 UTC (permalink / raw)
  To: linux-bluetooth

This patch increments the management interface revision due to the
various fixes, improvements and other changes that have gone in
lately.

Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
---
 net/bluetooth/mgmt.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/net/bluetooth/mgmt.c b/net/bluetooth/mgmt.c
index b871632..7a8702d 100644
--- a/net/bluetooth/mgmt.c
+++ b/net/bluetooth/mgmt.c
@@ -33,7 +33,7 @@
 #include <net/bluetooth/smp.h>
 
 #define MGMT_VERSION	1
-#define MGMT_REVISION	3
+#define MGMT_REVISION	4
 
 static const u16 mgmt_commands[] = {
 	MGMT_OP_READ_INDEX_LIST,
-- 
1.8.3.1


^ permalink raw reply related

* Re: [PATCH v3 8/8] Bluetooth: Add Slave Page Response Timeout Event
From: Anderson Lizardo @ 2013-10-02 12:20 UTC (permalink / raw)
  To: Dohyun Pyun; +Cc: BlueZ development, steve.jun, DoHyun Pyun, C S Bhargava
In-Reply-To: <1380715758-10334-9-git-send-email-dh79.pyun@samsung.com>

Hi Dohyun,

On Wed, Oct 2, 2013 at 8:09 AM, Dohyun Pyun <re20sfree@gmail.com> wrote:
> From: DoHyun Pyun <dh79.pyun@samsung.com>
>
> The Slave Page Response Timeout event indicates to the Host that a
> slave page response timeout has occurred in the BR/EDR Controller.
>
> The Core Spec Addendum 4 adds this command in part B Connectionless
> Slave Broadcast.
>
> Bluetooth Core Specification Addendum 4 - Page 110
>
> "7.7.67 Synchronization Train Complete Event [New Section]

The section for this event is actually:

"7.7.72 Slave Page Response Timeout Event [New Section]"

Best Regards,
-- 
Anderson Lizardo
Instituto Nokia de Tecnologia - INdT
Manaus - Brazil

^ permalink raw reply

* Re: [PATCH 1/1] obexd: Fix emitting Type property changed signals for messages
From: Luiz Augusto von Dentz @ 2013-10-02 12:36 UTC (permalink / raw)
  To: Christian Fetzer; +Cc: linux-bluetooth@vger.kernel.org
In-Reply-To: <1380022028-31031-1-git-send-email-christian.fetzer@oss.bmw-carit.de>

Hi Christian,

On Tue, Sep 24, 2013 at 2:27 PM, Christian Fetzer
<christian.fetzer@oss.bmw-carit.de> wrote:
> From: Christian Fetzer <christian.fetzer@bmw-carit.de>
>
> In order to determine if the message Type property has changed,
> the stored type needs to be compared with the parsed type and not with
> the raw value received from the MSE.
>
> This fixes the issue that the property changed signal for the Type
> property is emitted for every message on every ListMessage call.
> ---
>  obexd/client/map.c | 21 +++++++++++----------
>  1 file changed, 11 insertions(+), 10 deletions(-)
>
> diff --git a/obexd/client/map.c b/obexd/client/map.c
> index 9fe872d..d349ef7 100644
> --- a/obexd/client/map.c
> +++ b/obexd/client/map.c
> @@ -920,21 +920,22 @@ static void parse_recipient_address(struct map_msg *msg, const char *value)
>
>  static void parse_type(struct map_msg *msg, const char *value)
>  {
> -       if (g_strcmp0(msg->type, value) == 0)
> -               return;
> -
> -       g_free(msg->type);
> +       const char *type = NULL;
>
>         if (strcasecmp(value, "SMS_GSM") == 0)
> -               msg->type = g_strdup("sms-gsm");
> +               type = "sms-gsm";
>         else if (strcasecmp(value, "SMS_CDMA") == 0)
> -               msg->type = g_strdup("sms-cdma");
> +               type = "sms-cdma";
>         else if (strcasecmp(value, "EMAIL") == 0)
> -               msg->type = g_strdup("email");
> +               type = "email";
>         else if (strcasecmp(value, "MMS") == 0)
> -               msg->type = g_strdup("mms");
> -       else
> -               msg->type = NULL;
> +               type = "mms";
> +
> +       if (g_strcmp0(msg->type, type) == 0)
> +               return;
> +
> +       g_free(msg->type);
> +       msg->type = g_strdup(type);
>
>         g_dbus_emit_property_changed(conn, msg->path,
>                                                 MAP_MSG_INTERFACE, "Type");
> --
> 1.8.3.4

Pushed, thanks.


-- 
Luiz Augusto von Dentz

^ permalink raw reply

* Re: [PATCH] Bluetooth: Use only 2 bits for controller type information
From: Anderson Lizardo @ 2013-10-02 12:41 UTC (permalink / raw)
  To: Marcel Holtmann; +Cc: BlueZ development
In-Reply-To: <CAJdJm_N=sFA8Zz3XBcY2wnp9h4u2k1gWRaU=+cH023pTSdNkhg@mail.gmail.com>

Hi Marcel,

On Mon, Sep 30, 2013 at 7:31 AM, Anderson Lizardo
<anderson.lizardo@openbossa.org> wrote:
> Hi Marcel,
>
> On Mon, Sep 30, 2013 at 12:01 AM, Marcel Holtmann <marcel@holtmann.org> wrote:
>>>> -       di.type     = (hdev->bus & 0x0f) | (hdev->dev_type << 4);
>>>> +       di.type     = (hdev->bus & 0x0f) | ((hdev->dev_type & 0x30) << 4);
>>>
>>> Shouldn't it be (hdev->dev_type & 0x03) here?
>>
>> yes, this it should be 0x03 here. My mistake.
>
> Just a reminder that userspace needs fixing as well.

My mistake, userspace is fine. :)

Best Regards,
-- 
Anderson Lizardo
Instituto Nokia de Tecnologia - INdT
Manaus - Brazil

^ permalink raw reply

* [PATCH] Bluetooth: Fix REJECTED vs NOT_SUPPORTED mgmt responses
From: johan.hedberg @ 2013-10-02 12:45 UTC (permalink / raw)
  To: linux-bluetooth

From: Johan Hedberg <johan.hedberg@intel.com>

The REJECTED management response should mainly be used when the adapter
is in a state where we cannot accept some command or a specific
parameter value. The NOT_SUPPORTED response in turn means that the
adapter really cannot support the command or parameter value.

This patch fixes this distinction and adds two helper functions to
easily get the appropriate LE or BR/EDR related status response.

Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
---
 net/bluetooth/mgmt.c | 76 +++++++++++++++++++++++++++++++++++-----------------
 1 file changed, 51 insertions(+), 25 deletions(-)

diff --git a/net/bluetooth/mgmt.c b/net/bluetooth/mgmt.c
index b871632..461d5bb 100644
--- a/net/bluetooth/mgmt.c
+++ b/net/bluetooth/mgmt.c
@@ -920,20 +920,41 @@ static void cmd_status_rsp(struct pending_cmd *cmd, void *data)
 	mgmt_pending_remove(cmd);
 }
 
+static u8 mgmt_bredr_support(struct hci_dev *hdev)
+{
+	if (!lmp_bredr_capable(hdev))
+		return MGMT_STATUS_NOT_SUPPORTED;
+	else if (!test_bit(HCI_BREDR_ENABLED, &hdev->dev_flags))
+		return MGMT_STATUS_REJECTED;
+	else
+		return MGMT_STATUS_SUCCESS;
+}
+
+static u8 mgmt_le_support(struct hci_dev *hdev)
+{
+	if (!lmp_le_capable(hdev))
+		return MGMT_STATUS_NOT_SUPPORTED;
+	else if (!test_bit(HCI_LE_ENABLED, &hdev->dev_flags))
+		return MGMT_STATUS_REJECTED;
+	else
+		return MGMT_STATUS_SUCCESS;
+}
+
 static int set_discoverable(struct sock *sk, struct hci_dev *hdev, void *data,
 			    u16 len)
 {
 	struct mgmt_cp_set_discoverable *cp = data;
 	struct pending_cmd *cmd;
 	u16 timeout;
-	u8 scan;
+	u8 scan, status;
 	int err;
 
 	BT_DBG("request for %s", hdev->name);
 
-	if (!test_bit(HCI_BREDR_ENABLED, &hdev->dev_flags))
+	status = mgmt_bredr_support(hdev);
+	if (status)
 		return cmd_status(sk, hdev->id, MGMT_OP_SET_DISCOVERABLE,
-				 MGMT_STATUS_NOT_SUPPORTED);
+				  status);
 
 	if (cp->val != 0x00 && cp->val != 0x01)
 		return cmd_status(sk, hdev->id, MGMT_OP_SET_DISCOVERABLE,
@@ -1082,14 +1103,15 @@ static int set_connectable(struct sock *sk, struct hci_dev *hdev, void *data,
 	struct mgmt_mode *cp = data;
 	struct pending_cmd *cmd;
 	struct hci_request req;
-	u8 scan;
+	u8 scan, status;
 	int err;
 
 	BT_DBG("request for %s", hdev->name);
 
-	if (!test_bit(HCI_BREDR_ENABLED, &hdev->dev_flags))
+	status = mgmt_bredr_support(hdev);
+	if (status)
 		return cmd_status(sk, hdev->id, MGMT_OP_SET_CONNECTABLE,
-				  MGMT_STATUS_NOT_SUPPORTED);
+				  status);
 
 	if (cp->val != 0x00 && cp->val != 0x01)
 		return cmd_status(sk, hdev->id, MGMT_OP_SET_CONNECTABLE,
@@ -1205,14 +1227,15 @@ static int set_link_security(struct sock *sk, struct hci_dev *hdev, void *data,
 {
 	struct mgmt_mode *cp = data;
 	struct pending_cmd *cmd;
-	u8 val;
+	u8 val, status;
 	int err;
 
 	BT_DBG("request for %s", hdev->name);
 
-	if (!test_bit(HCI_BREDR_ENABLED, &hdev->dev_flags))
+	status = mgmt_bredr_support(hdev);
+	if (status)
 		return cmd_status(sk, hdev->id, MGMT_OP_SET_LINK_SECURITY,
-				  MGMT_STATUS_NOT_SUPPORTED);
+				  status);
 
 	if (cp->val != 0x00 && cp->val != 0x01)
 		return cmd_status(sk, hdev->id, MGMT_OP_SET_LINK_SECURITY,
@@ -1340,13 +1363,14 @@ static int set_hs(struct sock *sk, struct hci_dev *hdev, void *data, u16 len)
 {
 	struct mgmt_mode *cp = data;
 	bool changed;
+	u8 status;
 	int err;
 
 	BT_DBG("request for %s", hdev->name);
 
-	if (!test_bit(HCI_BREDR_ENABLED, &hdev->dev_flags))
-		return cmd_status(sk, hdev->id, MGMT_OP_SET_HS,
-				  MGMT_STATUS_NOT_SUPPORTED);
+	status = mgmt_bredr_support(hdev);
+	if (status)
+		return cmd_status(sk, hdev->id, MGMT_OP_SET_HS, status);
 
 	if (cp->val != 0x00 && cp->val != 0x01)
 		return cmd_status(sk, hdev->id, MGMT_OP_SET_HS,
@@ -2776,6 +2800,7 @@ static int start_discovery(struct sock *sk, struct hci_dev *hdev,
 	struct hci_request req;
 	/* General inquiry access code (GIAC) */
 	u8 lap[3] = { 0x33, 0x8b, 0x9e };
+	u8 status;
 	int err;
 
 	BT_DBG("%s", hdev->name);
@@ -2812,9 +2837,10 @@ static int start_discovery(struct sock *sk, struct hci_dev *hdev,
 
 	switch (hdev->discovery.type) {
 	case DISCOV_TYPE_BREDR:
-		if (!test_bit(HCI_BREDR_ENABLED, &hdev->dev_flags)) {
+		status = mgmt_bredr_support(hdev);
+		if (status) {
 			err = cmd_status(sk, hdev->id, MGMT_OP_START_DISCOVERY,
-					 MGMT_STATUS_NOT_SUPPORTED);
+					 status);
 			mgmt_pending_remove(cmd);
 			goto failed;
 		}
@@ -2836,9 +2862,10 @@ static int start_discovery(struct sock *sk, struct hci_dev *hdev,
 
 	case DISCOV_TYPE_LE:
 	case DISCOV_TYPE_INTERLEAVED:
-		if (!test_bit(HCI_LE_ENABLED, &hdev->dev_flags)) {
+		status = mgmt_le_support(hdev);
+		if (status) {
 			err = cmd_status(sk, hdev->id, MGMT_OP_START_DISCOVERY,
-					 MGMT_STATUS_NOT_SUPPORTED);
+					 status);
 			mgmt_pending_remove(cmd);
 			goto failed;
 		}
@@ -3182,18 +3209,15 @@ static int set_advertising(struct sock *sk, struct hci_dev *hdev, void *data, u1
 	struct mgmt_mode *cp = data;
 	struct pending_cmd *cmd;
 	struct hci_request req;
-	u8 val, enabled;
+	u8 val, enabled, status;
 	int err;
 
 	BT_DBG("request for %s", hdev->name);
 
-	if (!lmp_le_capable(hdev))
-		return cmd_status(sk, hdev->id, MGMT_OP_SET_ADVERTISING,
-				  MGMT_STATUS_NOT_SUPPORTED);
-
-	if (!test_bit(HCI_LE_ENABLED, &hdev->dev_flags))
+	status = mgmt_le_support(hdev);
+	if (status)
 		return cmd_status(sk, hdev->id, MGMT_OP_SET_ADVERTISING,
-				  MGMT_STATUS_REJECTED);
+				  status);
 
 	if (cp->val != 0x00 && cp->val != 0x01)
 		return cmd_status(sk, hdev->id, MGMT_OP_SET_ADVERTISING,
@@ -3252,13 +3276,15 @@ static int set_static_address(struct sock *sk, struct hci_dev *hdev,
 			      void *data, u16 len)
 {
 	struct mgmt_cp_set_static_address *cp = data;
+	u8 status;
 	int err;
 
 	BT_DBG("%s", hdev->name);
 
-	if (!lmp_le_capable(hdev))
+	status = mgmt_le_support(hdev);
+	if (status)
 		return cmd_status(sk, hdev->id, MGMT_OP_SET_STATIC_ADDRESS,
-				  MGMT_STATUS_NOT_SUPPORTED);
+				  status);
 
 	if (hdev_is_powered(hdev))
 		return cmd_status(sk, hdev->id, MGMT_OP_SET_STATIC_ADDRESS,
-- 
1.8.3.1


^ permalink raw reply related

* Re: [PATCH] Bluetooth: Fix REJECTED vs NOT_SUPPORTED mgmt responses
From: Marcel Holtmann @ 2013-10-02 12:53 UTC (permalink / raw)
  To: johan.hedberg; +Cc: linux-bluetooth
In-Reply-To: <1380717922-25142-1-git-send-email-johan.hedberg@gmail.com>

Hi Johan,

> The REJECTED management response should mainly be used when the adapter
> is in a state where we cannot accept some command or a specific
> parameter value. The NOT_SUPPORTED response in turn means that the
> adapter really cannot support the command or parameter value.
> 
> This patch fixes this distinction and adds two helper functions to
> easily get the appropriate LE or BR/EDR related status response.
> 
> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
> ---
> net/bluetooth/mgmt.c | 76 +++++++++++++++++++++++++++++++++++-----------------
> 1 file changed, 51 insertions(+), 25 deletions(-)

patch has been applied to bluetooth-next.

Regards

Marcel


^ permalink raw reply

* [PATCH v4 0/8] Add CSA 4 commands and events in hci.h
From: Dohyun Pyun @ 2013-10-02 12:54 UTC (permalink / raw)
  To: linux-bluetooth; +Cc: steve.jun

Hi all,


This patchset contains several HCI commands and events addition.
These HCI commands and events are included in Bluetooth Core
Specification Addendum 4, and it will be used to implement 3DS
profile.

Also I'm still implementing 3DS profile's master role in the BR/EDR
controller. Summit and I'll send the patchsets about 3DS MGMT APIs
soon.

Regards,
Pyun

* Rebased the patchsets
* Modify the subject and commit message

----------------------------------------------------------------
DoHyun Pyun (8):
      Bluetooth: Add the definition and structure for Set Reserved LT_ADDR
      Bluetooth: Add the definition and structure for Delete Reserved LT_ADDR
      Bluetooth: Add the definition and structure for Set CSB Data
      Bluetooth: Add the structure for Write Sync Train Parameters
      Bluetooth: Add the definition and structure for Set CSB
      Bluetooth: Add the definition for Start Synchronization Train
      Bluetooth: Add the definition and stcuture for Sync Train Complete
      Bluetooth: Add the definition for Slave Page Response Timeout

 include/net/bluetooth/hci.h | 69 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 69 insertions(+)


^ permalink raw reply

* [PATCH v4 1/8] Bluetooth: Add the definition and structure for Set Reserved LT_ADDR
From: Dohyun Pyun @ 2013-10-02 12:54 UTC (permalink / raw)
  To: linux-bluetooth; +Cc: steve.jun, DoHyun Pyun, C S Bhargava
In-Reply-To: <1380718493-4577-1-git-send-email-dh79.pyun@samsung.com>

From: DoHyun Pyun <dh79.pyun@samsung.com>

The Set_Reserved_LT_ADDR command allows the host to request that the
BR/EDR Controller reserve a specific LT_ADDR for Connectionless Slave
Broadcast.

The Core Spec Addendum 4 adds this command in part B Connectionless
Slave Broadcast.

Bluetooth Core Specification Addendum 4 - Page 90

"7.3.86 Set Reserved LT_ADDR Command [New Section]
...
If the LT_ADDR indicated in the LT_ADDR parameter is already in use by the
BR/EDR Controller, it shall return the ACL Connection Already Exists (0x0B)
error code. If the LT_ADDR indicated in the LT_ADDR parameter is out of
range, the controller shall return the Invalid HCI Command Parameters (0x12)
error code. If the command succeeds, then the reserved LT_ADDR shall be
used when issuing subsequent Set Connectionless Slave Broadcast Data and
Set Connectionless Slave Broadcast commands.
To ensure that the reserved LT_ADDR is not already allocated, it is
recommended that this command be issued at some point after HCI_Reset is
issued but before page scanning is enabled or paging is initiated."

Signed-off-by: Dohyun Pyun <dh79.pyun@samsung.com>
Signed-off-by: C S Bhargava <cs.bhargava@samsung.com>
---
 include/net/bluetooth/hci.h | 9 +++++++++
 1 file changed, 9 insertions(+)

diff --git a/include/net/bluetooth/hci.h b/include/net/bluetooth/hci.h
index d7fd825..4d88809 100644
--- a/include/net/bluetooth/hci.h
+++ b/include/net/bluetooth/hci.h
@@ -839,6 +839,15 @@ struct hci_cp_write_le_host_supported {
 	__u8	simul;
 } __packed;
 
+#define HCI_OP_SET_RESERVED_LT_ADDR	0x0c74
+struct hci_cp_set_reserved_lt_addr {
+	__u8	lt_addr;
+} __packed;
+struct hci_rp_set_reserved_lt_addr {
+	__u8	status;
+	__u8	lt_addr;
+} __packed;
+
 #define HCI_OP_READ_SYNC_TRAIN_PARAMS	0x0c77
 
 #define HCI_OP_READ_LOCAL_VERSION	0x1001
-- 
1.8.1.2


^ permalink raw reply related

* [PATCH v4 2/8] Bluetooth: Add the definition and structure for Delete Reserved LT_ADDR
From: Dohyun Pyun @ 2013-10-02 12:54 UTC (permalink / raw)
  To: linux-bluetooth; +Cc: steve.jun, DoHyun Pyun, C S Bhargava
In-Reply-To: <1380718493-4577-1-git-send-email-dh79.pyun@samsung.com>

From: DoHyun Pyun <dh79.pyun@samsung.com>

The Delete_Reserved_LT_ADDR command requests that the BR/EDR
Controller cancel the reservation for a specific LT_ADDR reserved for the
purposes of Connectionless Slave Broadcast.

The Core Spec Addendum 4 adds this command in part B Connectionless
Slave Broadcast.

Bluetooth Core Specification Addendum 4 - Page 92

"7.3.87 Delete Reserved LT_ADDR Command [New Section]
...
If the LT_ADDR indicated in the LT_ADDR parameter is not reserved by the
BR/EDR Controller, it shall return the Unknown Connection Identifier (0x02)
error code.
If connectionless slave broadcast mode is still active, then the Controller
shall return the Command Disallowed (0x0C) error code."

Signed-off-by: Dohyun Pyun <dh79.pyun@samsung.com>
Signed-off-by: C S Bhargava <cs.bhargava@samsung.com>
---
 include/net/bluetooth/hci.h | 9 +++++++++
 1 file changed, 9 insertions(+)

diff --git a/include/net/bluetooth/hci.h b/include/net/bluetooth/hci.h
index 4d88809..9b071f1 100644
--- a/include/net/bluetooth/hci.h
+++ b/include/net/bluetooth/hci.h
@@ -848,6 +848,15 @@ struct hci_rp_set_reserved_lt_addr {
 	__u8	lt_addr;
 } __packed;
 
+#define HCI_OP_DELETE_RESERVED_LT_ADDR	0x0c75
+struct hci_cp_delete_reserved_lt_addr {
+	__u8	lt_addr;
+} __packed;
+struct hci_rp_delete_reserved_lt_addr {
+	__u8	status;
+	__u8	lt_addr;
+} __packed;
+
 #define HCI_OP_READ_SYNC_TRAIN_PARAMS	0x0c77
 
 #define HCI_OP_READ_LOCAL_VERSION	0x1001
-- 
1.8.1.2


^ permalink raw reply related

* [PATCH v4 3/8] Bluetooth: Add the definition and structure for Set CSB Data
From: Dohyun Pyun @ 2013-10-02 12:54 UTC (permalink / raw)
  To: linux-bluetooth; +Cc: steve.jun, DoHyun Pyun, C S Bhargava
In-Reply-To: <1380718493-4577-1-git-send-email-dh79.pyun@samsung.com>

From: DoHyun Pyun <dh79.pyun@samsung.com>

The Set_Connectionless_Slave_Broadcast_Data command provides the
ability for the Host to set Connectionless Slave Broadcast data in
the BR/EDR Controller.

The Core Spec Addendum 4 adds this command in part B Connectionless
Slave Broadcast.

Bluetooth Core Specification Addendum 4 - Page 93

"7.3.88 Set Connectionless Slave Broadcast Data Command [New Section]
...
If connectionless slave broadcast mode is disabled, this data shall be
kept by the BR/EDR Controller and used once connectionless slave broadcast
mode is enabled. If connectionless slave broadcast mode is enabled,
and this command is successful, this data will be sent starting with
the next Connectionless Slave Broadcast instant.

The Data_Length field may be zero, in which case no data needs to be
provided.

The Host may fragment the data using the Fragment field in the command. If
the combined length of the fragments exceeds the capacity of the largest
allowed packet size specified in the Set Connectionless Slave Broadcast
command, all fragments associated with the data being assembled shall be
discarded and the Invalid HCI Command Parameters error (0x12) shall be
returned."

Signed-off-by: Dohyun Pyun <dh79.pyun@samsung.com>
Signed-off-by: C S Bhargava <cs.bhargava@samsung.com>
---
 include/net/bluetooth/hci.h | 14 ++++++++++++++
 1 file changed, 14 insertions(+)

diff --git a/include/net/bluetooth/hci.h b/include/net/bluetooth/hci.h
index 9b071f1..d9e0a84 100644
--- a/include/net/bluetooth/hci.h
+++ b/include/net/bluetooth/hci.h
@@ -35,6 +35,8 @@
 
 #define HCI_MAX_AMP_ASSOC_SIZE	672
 
+#define HCI_MAX_CSB_DATA_SIZE	252
+
 /* HCI dev events */
 #define HCI_DEV_REG			1
 #define HCI_DEV_UNREG			2
@@ -857,6 +859,18 @@ struct hci_rp_delete_reserved_lt_addr {
 	__u8	lt_addr;
 } __packed;
 
+#define HCI_OP_SET_CSB_DATA		0x0c76
+struct hci_cp_set_csb_data {
+	__u8	lt_addr;
+	__u8	fragment;
+	__u8	data_length;
+	__u8	data[HCI_MAX_CSB_DATA_SIZE];
+} __packed;
+struct hci_rp_set_csb_data {
+	__u8	status;
+	__u8	lt_addr;
+} __packed;
+
 #define HCI_OP_READ_SYNC_TRAIN_PARAMS	0x0c77
 
 #define HCI_OP_READ_LOCAL_VERSION	0x1001
-- 
1.8.1.2


^ permalink raw reply related

* [PATCH v4 4/8] Bluetooth: Add the structure for Write Sync Train Parameters
From: Dohyun Pyun @ 2013-10-02 12:54 UTC (permalink / raw)
  To: linux-bluetooth; +Cc: steve.jun, DoHyun Pyun, C S Bhargava
In-Reply-To: <1380718493-4577-1-git-send-email-dh79.pyun@samsung.com>

From: DoHyun Pyun <dh79.pyun@samsung.com>

The Write_Synchronization_Train_Parameters command configures
the Synchronization Train functionality in the BR/EDR Controller.

The Core Spec Addendum 4 adds this command in part B Connectionless
Slave Broadcast.

Bluetooth Core Specification Addendum 4 - Page 97

"7.3.90 Write Synchronization Train Parameters Command [New Section]
...
Note: The AFH_Channel_Map used in the Synchronization Train packets is
configured by the Set_AFH_Channel_Classification command and the local
channel classification in the BR/EDR Controller.

Interval_Min and Interval_Max specify the allowed range of
Sync_Train_Interval. Refer to [Vol. 2], Part B, section 2.7.2 for
a detailed description of Sync_Train_Interval. The BR/EDR Controller shall
select an interval from this range and return it in Sync_Train_Interval.
If the Controller is unable to select a value from this range, it shall
return the Invalid HCI Command Parameters (0x12) error code.

Once started (via the Start_Synchronization_Train Command) the
Synchronization Train will continue until synchronization_trainTO slots have
passed or Connectionless Slave Broadcast has been disabled."

Signed-off-by: Dohyun Pyun <dh79.pyun@samsung.com>
Signed-off-by: C S Bhargava <cs.bhargava@samsung.com>
---
 include/net/bluetooth/hci.h | 12 ++++++++++++
 1 file changed, 12 insertions(+)

diff --git a/include/net/bluetooth/hci.h b/include/net/bluetooth/hci.h
index d9e0a84..cad6ca1 100644
--- a/include/net/bluetooth/hci.h
+++ b/include/net/bluetooth/hci.h
@@ -873,6 +873,18 @@ struct hci_rp_set_csb_data {
 
 #define HCI_OP_READ_SYNC_TRAIN_PARAMS	0x0c77
 
+#define HCI_OP_WRITE_SYNC_TRAIN_PARAMS	0x0c78
+struct hci_cp_write_sync_train_params {
+	__le16	interval_min;
+	__le16	interval_max;
+	__le32	sync_train_tout;
+	__u8	service_data;
+} __packed;
+struct hci_rp_write_sync_train_params {
+	__u8	status;
+	__le16	sync_train_int;
+} __packed;
+
 #define HCI_OP_READ_LOCAL_VERSION	0x1001
 struct hci_rp_read_local_version {
 	__u8     status;
-- 
1.8.1.2


^ permalink raw reply related

* [PATCH v4 5/8] Bluetooth: Add the definition and structure for Set CSB
From: Dohyun Pyun @ 2013-10-02 12:54 UTC (permalink / raw)
  To: linux-bluetooth; +Cc: steve.jun, DoHyun Pyun, C S Bhargava
In-Reply-To: <1380718493-4577-1-git-send-email-dh79.pyun@samsung.com>

From: DoHyun Pyun <dh79.pyun@samsung.com>

he Set_Connectionless_Slave_Broadcast command controls the
Connectionless Slave Broadcast functionality in the BR/EDR
Controller.

The Core Spec Addendum 4 adds this command in part B Connectionless
Slave Broadcast.

Bluetooth Core Specification Addendum 4 - Page 78

"7.1.49 Set Connectionless Slave Broadcast Command [New Section]
...
The LT_ADDR indicated in the Set_Connectionless_Slave_Broadcast shall be
pre-allocated using the HCI_Set_Reserved_LT_ADDR command. If the
LT_ADDR has not been reserved, the Unknown Connection Identifier (0x02)
error code shall be returned. If the controller is unable to reserve
sufficient bandwidth for the requested activity, the Connection Rejected
Due to Limited Resources (0x0D) error code shall be returned.

The LPO_Allowed parameter informs the BR/EDR Controller whether it is
allowed to sleep.

The Packet_Type parameter specifies which packet types are allowed. The
Host shall either enable BR packet types only, or shall enable EDR and DM1
packet types only.

The Interval_Min and Interval_Max parameters specify the range from which
the BR/EDR Controller must select the Connectionless Slave Broadcast
Interval. The selected Interval is returned."

Signed-off-by: Dohyun Pyun <dh79.pyun@samsung.com>
Signed-off-by: C S Bhargava <cs.bhargava@samsung.com>
---
 include/net/bluetooth/hci.h | 16 ++++++++++++++++
 1 file changed, 16 insertions(+)

diff --git a/include/net/bluetooth/hci.h b/include/net/bluetooth/hci.h
index cad6ca1..42d3832 100644
--- a/include/net/bluetooth/hci.h
+++ b/include/net/bluetooth/hci.h
@@ -628,6 +628,22 @@ struct hci_rp_logical_link_cancel {
 	__u8     flow_spec_id;
 } __packed;
 
+#define HCI_OP_SET_CSB			0x0441
+struct hci_cp_set_csb {
+	__u8	enable;
+	__u8	lt_addr;
+	__u8	lpo_allowed;
+	__le16	packet_type;
+	__le16	interval_min;
+	__le16	interval_max;
+	__le16	csb_sv_tout;
+} __packed;
+struct hci_rp_set_csb {
+	__u8	status;
+	__u8	lt_addr;
+	__le16	interval;
+} __packed;
+
 #define HCI_OP_SNIFF_MODE		0x0803
 struct hci_cp_sniff_mode {
 	__le16   handle;
-- 
1.8.1.2


^ permalink raw reply related

* [PATCH v4 6/8] Bluetooth: Add the definition for Start Synchronization Train
From: Dohyun Pyun @ 2013-10-02 12:54 UTC (permalink / raw)
  To: linux-bluetooth; +Cc: steve.jun, DoHyun Pyun, C S Bhargava
In-Reply-To: <1380718493-4577-1-git-send-email-dh79.pyun@samsung.com>

From: DoHyun Pyun <dh79.pyun@samsung.com>

The Start_Synchronization_Train command controls the Synchronization
Train functionality in the BR/EDR Controller.

The Core Spec Addendum 4 adds this command in part B Connectionless
Slave Broadcast.

Bluetooth Core Specification Addendum 4 - Page 86

"7.1.51 Start Synchronization Train Command [New Section]
...
If connectionless slave broadcast mode is not enabled, the Command
Disallowed (0x0C) error code shall be returned. After receiving this
command and returning a Command Status event, the Baseband starts
attempting to send synchronization train packets containing information
related to the enabled Connectionless Slave Broadcast packet timing.

Note: The AFH_Channel_Map used in the synchronization train packets is
configured by the Set_AFH_Channel_Classification command and the local
channel classification in the BR/EDR Controller.

The synchronization train packets will be sent using the parameters
specified by the latest Write_Synchronization_Train_Parameters command.
The Synchronization Train will continue until synchronization_trainTO
slots (as specified in the last Write_Synchronization_Train command)
have passed or until the Host disables the Connectionless Slave Broadcast
logical transport."

Signed-off-by: Dohyun Pyun <dh79.pyun@samsung.com>
Signed-off-by: C S Bhargava <cs.bhargava@samsung.com>
---
 include/net/bluetooth/hci.h | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/include/net/bluetooth/hci.h b/include/net/bluetooth/hci.h
index 42d3832..657d2b0 100644
--- a/include/net/bluetooth/hci.h
+++ b/include/net/bluetooth/hci.h
@@ -644,6 +644,8 @@ struct hci_rp_set_csb {
 	__le16	interval;
 } __packed;
 
+#define HCI_OP_START_SYNC_TRAIN		0x0443
+
 #define HCI_OP_SNIFF_MODE		0x0803
 struct hci_cp_sniff_mode {
 	__le16   handle;
-- 
1.8.1.2


^ permalink raw reply related

* [PATCH v4 7/8] Bluetooth: Add the definition and stcuture for Sync Train Complete
From: Dohyun Pyun @ 2013-10-02 12:54 UTC (permalink / raw)
  To: linux-bluetooth; +Cc: steve.jun, DoHyun Pyun, C S Bhargava
In-Reply-To: <1380718493-4577-1-git-send-email-dh79.pyun@samsung.com>

From: DoHyun Pyun <dh79.pyun@samsung.com>

The Synchronization Train Complete event indicates that the Start
Synchronization Train command has completed.

The Core Spec Addendum 4 adds this command in part B Connectionless
Slave Broadcast.

Bluetooth Core Specification Addendum 4 - Page 103

"7.7.67 Synchronization Train Complete Event [New Section]
...

Event Parameters:

Status 0x00       Start Synchronization Train command completed
                  successfully.
       0x01-0xFF  Start Synchronization Train command failed.
                  See Part D, Error Codes, for error codes and
                  descriptions."

Signed-off-by: Dohyun Pyun <dh79.pyun@samsung.com>
Signed-off-by: C S Bhargava <cs.bhargava@samsung.com>
---
 include/net/bluetooth/hci.h | 5 +++++
 1 file changed, 5 insertions(+)

diff --git a/include/net/bluetooth/hci.h b/include/net/bluetooth/hci.h
index 657d2b0..03f2a91 100644
--- a/include/net/bluetooth/hci.h
+++ b/include/net/bluetooth/hci.h
@@ -1505,6 +1505,11 @@ struct hci_ev_num_comp_blocks {
 	struct hci_comp_blocks_info handles[0];
 } __packed;
 
+#define HCI_EV_SYNC_TRAIN_COMPLETE	0x4F
+struct hci_ev_sync_train_complete {
+	__u8	status;
+} __packed;
+
 /* Low energy meta events */
 #define LE_CONN_ROLE_MASTER	0x00
 
-- 
1.8.1.2


^ permalink raw reply related

* [PATCH v4 8/8] Bluetooth: Add the definition for Slave Page Response Timeout
From: Dohyun Pyun @ 2013-10-02 12:54 UTC (permalink / raw)
  To: linux-bluetooth; +Cc: steve.jun, DoHyun Pyun, C S Bhargava
In-Reply-To: <1380718493-4577-1-git-send-email-dh79.pyun@samsung.com>

From: DoHyun Pyun <dh79.pyun@samsung.com>

The Slave Page Response Timeout event indicates to the Host that a
slave page response timeout has occurred in the BR/EDR Controller.

The Core Spec Addendum 4 adds this command in part B Connectionless
Slave Broadcast.

Bluetooth Core Specification Addendum 4 - Page 110

"7.7.72 Slave Page Response Timeout Event [New Section]
...
Note: this event will be generated if the slave BR/EDR Controller
responds to a page but does not receive the master FHS packet
(see Baseband, Section 8.3.3) within pagerespTO.

Event Parameters: NONE"

Signed-off-by: Dohyun Pyun <dh79.pyun@samsung.com>
Signed-off-by: C S Bhargava <cs.bhargava@samsung.com>
---
 include/net/bluetooth/hci.h | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/include/net/bluetooth/hci.h b/include/net/bluetooth/hci.h
index 03f2a91..b90eec5 100644
--- a/include/net/bluetooth/hci.h
+++ b/include/net/bluetooth/hci.h
@@ -1510,6 +1510,8 @@ struct hci_ev_sync_train_complete {
 	__u8	status;
 } __packed;
 
+#define HCI_EV_SLAVE_PAGE_RESP_TIMEOUT	0x54
+
 /* Low energy meta events */
 #define LE_CONN_ROLE_MASTER	0x00
 
-- 
1.8.1.2


^ permalink raw reply related

* [PATCH] Bluetooth: Fix advertising data flags with disabled BR/EDR
From: johan.hedberg @ 2013-10-02 13:02 UTC (permalink / raw)
  To: linux-bluetooth

From: Johan Hedberg <johan.hedberg@intel.com>

We shouldn't include the simultaneous LE & BR/EDR flags in the LE
advertising data if BR/EDR is disabled on a dual-mode controller. This
patch fixes this issue and ensures that the create_ad function generates
the correct flags when BR/EDR is disabled.

Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
---
 net/bluetooth/hci_core.c | 14 +++++++-------
 1 file changed, 7 insertions(+), 7 deletions(-)

diff --git a/net/bluetooth/hci_core.c b/net/bluetooth/hci_core.c
index 14df032..82dbdc6 100644
--- a/net/bluetooth/hci_core.c
+++ b/net/bluetooth/hci_core.c
@@ -1108,14 +1108,14 @@ static u8 create_ad(struct hci_dev *hdev, u8 *ptr)
 	if (test_bit(HCI_LE_PERIPHERAL, &hdev->dev_flags))
 		flags |= LE_AD_GENERAL;
 
-	if (!test_bit(HCI_BREDR_ENABLED, &hdev->dev_flags))
+	if (test_bit(HCI_BREDR_ENABLED, &hdev->dev_flags)) {
+		if (lmp_le_br_capable(hdev))
+			flags |= LE_AD_SIM_LE_BREDR_CTRL;
+		if (lmp_host_le_br_capable(hdev))
+			flags |= LE_AD_SIM_LE_BREDR_HOST;
+	} else {
 		flags |= LE_AD_NO_BREDR;
-
-	if (lmp_le_br_capable(hdev))
-		flags |= LE_AD_SIM_LE_BREDR_CTRL;
-
-	if (lmp_host_le_br_capable(hdev))
-		flags |= LE_AD_SIM_LE_BREDR_HOST;
+	}
 
 	if (flags) {
 		BT_DBG("adv flags 0x%02x", flags);
-- 
1.8.3.1


^ permalink raw reply related

* Re: [PATCH] Bluetooth: Fix advertising data flags with disabled BR/EDR
From: Marcel Holtmann @ 2013-10-02 13:19 UTC (permalink / raw)
  To: johan.hedberg; +Cc: linux-bluetooth
In-Reply-To: <1380718944-28164-1-git-send-email-johan.hedberg@gmail.com>

Hi Johan,

> We shouldn't include the simultaneous LE & BR/EDR flags in the LE
> advertising data if BR/EDR is disabled on a dual-mode controller. This
> patch fixes this issue and ensures that the create_ad function generates
> the correct flags when BR/EDR is disabled.
> 
> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
> ---
> net/bluetooth/hci_core.c | 14 +++++++-------
> 1 file changed, 7 insertions(+), 7 deletions(-)

patch has been applied to bluetooth-next tree.

Regards

Marcel


^ permalink raw reply

* Re: [PATCH] Bluetooth: Increment management interface revision
From: Johan Hedberg @ 2013-10-02 13:24 UTC (permalink / raw)
  To: Marcel Holtmann; +Cc: linux-bluetooth
In-Reply-To: <1380716311-19403-1-git-send-email-marcel@holtmann.org>

Hi Marcel,

On Wed, Oct 02, 2013, Marcel Holtmann wrote:
> This patch increments the management interface revision due to the
> various fixes, improvements and other changes that have gone in
> lately.
> 
> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
> ---
>  net/bluetooth/mgmt.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)

Applied. Thanks.

Johan

^ permalink raw reply

* [PATCH] Bluetooth: Fix memory leak with L2CAP signal channels
From: Marcel Holtmann @ 2013-10-02 15:28 UTC (permalink / raw)
  To: linux-bluetooth

The wrong type of L2CAP signalling packets on the wrong type of
either BR/EDR or LE links need to be dropped. When that happens
the packet is dropped, but the memory not freed. So actually
free the memory as well.

Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
---
 net/bluetooth/l2cap_core.c | 6 ++++--
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/net/bluetooth/l2cap_core.c b/net/bluetooth/l2cap_core.c
index 6d42498..814563d 100644
--- a/net/bluetooth/l2cap_core.c
+++ b/net/bluetooth/l2cap_core.c
@@ -5330,7 +5330,7 @@ static inline void l2cap_le_sig_channel(struct l2cap_conn *conn,
 	l2cap_raw_recv(conn, skb);
 
 	if (hcon->type != LE_LINK)
-		return;
+		goto drop;
 
 	while (len >= L2CAP_CMD_HDR_SIZE) {
 		u16 cmd_len;
@@ -5363,6 +5363,7 @@ static inline void l2cap_le_sig_channel(struct l2cap_conn *conn,
 		len  -= cmd_len;
 	}
 
+drop:
 	kfree_skb(skb);
 }
 
@@ -5378,7 +5379,7 @@ static inline void l2cap_sig_channel(struct l2cap_conn *conn,
 	l2cap_raw_recv(conn, skb);
 
 	if (hcon->type != ACL_LINK)
-		return;
+		goto drop;
 
 	while (len >= L2CAP_CMD_HDR_SIZE) {
 		u16 cmd_len;
@@ -5411,6 +5412,7 @@ static inline void l2cap_sig_channel(struct l2cap_conn *conn,
 		len  -= cmd_len;
 	}
 
+drop:
 	kfree_skb(skb);
 }
 
-- 
1.8.3.1


^ permalink raw reply related

* [PATCH bluez v2 1/2] plugin: handle ENOSYS as not-supported
From: David Herrmann @ 2013-10-02 15:57 UTC (permalink / raw)
  To: linux-bluetooth; +Cc: Marcel Holtmann, Johan Hedberg, David Herrmann

Allow plugins to return -ENOSYS during registration and handle it as
"not-supported" error. It makes the error messages slightly more useful in
case kernel-support is missing for a particular subsystem.
---
 src/plugin.c | 11 +++++++++--
 1 file changed, 9 insertions(+), 2 deletions(-)

diff --git a/src/plugin.c b/src/plugin.c
index 51c98bc..9c3225e 100644
--- a/src/plugin.c
+++ b/src/plugin.c
@@ -119,6 +119,7 @@ gboolean plugin_init(const char *enable, const char *disable)
 	const char *file;
 	char **cli_disabled, **cli_enabled;
 	unsigned int i;
+	int err;
 
 	/* Make a call to BtIO API so its symbols got resolved before the
 	 * plugins are loaded. */
@@ -196,8 +197,14 @@ start:
 	for (list = plugins; list; list = list->next) {
 		struct bluetooth_plugin *plugin = list->data;
 
-		if (plugin->desc->init() < 0) {
-			error("Failed to init %s plugin", plugin->desc->name);
+		err = plugin->desc->init();
+		if (err < 0) {
+			if (err == -ENOSYS)
+				warn("System does not support %s plugin",
+							plugin->desc->name);
+			else
+				error("Failed to init %s plugin",
+							plugin->desc->name);
 			continue;
 		}
 
-- 
1.8.4

^ permalink raw reply related

* [PATCH bluez v2 2/2] bnep: improve error-msg if bnep.ko is not loaded
From: David Herrmann @ 2013-10-02 15:57 UTC (permalink / raw)
  To: linux-bluetooth; +Cc: Marcel Holtmann, Johan Hedberg, David Herrmann
In-Reply-To: <1380729451-2266-1-git-send-email-dh.herrmann@gmail.com>

bnep.ko, besides others, can be disabled in custom kernels if
network-support is not required. To avoid strange error messages, handle
EPROTONOSUPPORT as a special case and emit a warning that kernel support
is missing.
---
 profiles/network/common.c  |  7 ++++++-
 profiles/network/manager.c | 16 +++++++++++++---
 2 files changed, 19 insertions(+), 4 deletions(-)

diff --git a/profiles/network/common.c b/profiles/network/common.c
index e069892..0b291bd 100644
--- a/profiles/network/common.c
+++ b/profiles/network/common.c
@@ -110,8 +110,13 @@ int bnep_init(void)
 
 	if (ctl < 0) {
 		int err = -errno;
-		error("Failed to open control socket: %s (%d)",
+
+		if (err == -EPROTONOSUPPORT)
+			warn("kernel lacks bnep-protocol support");
+		else
+			error("Failed to open control socket: %s (%d)",
 						strerror(-err), -err);
+
 		return err;
 	}
 
diff --git a/profiles/network/manager.c b/profiles/network/manager.c
index 03b1b3d..6617687 100644
--- a/profiles/network/manager.c
+++ b/profiles/network/manager.c
@@ -25,6 +25,7 @@
 #include <config.h>
 #endif
 
+#include <errno.h>
 #include <stdbool.h>
 
 #include <bluetooth/bluetooth.h>
@@ -169,11 +170,20 @@ static struct btd_profile nap_profile = {
 
 static int network_init(void)
 {
+	int err;
+
 	read_config(CONFIGDIR "/network.conf");
 
-	if (bnep_init()) {
-		error("Can't init bnep module");
-		return -1;
+	err = bnep_init();
+	if (err) {
+		if (err == -EPROTONOSUPPORT) {
+			info("bnep module not available, disabling plugin");
+			err = -ENOSYS;
+		} else {
+			error("Can't init bnep module");
+		}
+
+		return err;
 	}
 
 	/*
-- 
1.8.4

^ permalink raw reply related

* [PATCH] hid2hci: fix regression in /dev format after moving away from libusb
From: Giovanni Campagna @ 2013-10-02 16:00 UTC (permalink / raw)
  To: linux-bluetooth

From: Giovanni Campagna <gcampagna@src.gnome.org>

The paths under /dev, in the default udev configuration, are formatted
with two leading zeros, but the number obtained from sysfs don't have
them, so we must convert them to integers and reformat them.

Signed-off-by: Giovanni Campagna <scampa.giovanni@gmail.com>
---
 tools/hid2hci.c | 15 +++++++++------
 1 file changed, 9 insertions(+), 6 deletions(-)

diff --git a/tools/hid2hci.c b/tools/hid2hci.c
index bb8a521..76d0b5a 100644
--- a/tools/hid2hci.c
+++ b/tools/hid2hci.c
@@ -221,18 +221,21 @@ static int usb_switch_dell(int fd, enum mode mode)
 static int find_device(struct udev_device *udev_dev)
 {
 	char path[PATH_MAX];
-	const char *busnum, *devnum;
+	const char *busnum_s, *devnum_s;
+	int busnum, devnum;
 	int fd;
 
-	busnum = udev_device_get_sysattr_value(udev_dev, "busnum");
-	if (!busnum)
+	busnum_s = udev_device_get_sysattr_value(udev_dev, "busnum");
+	if (!busnum_s)
 		return -1;
+	busnum = strtol(busnum_s, NULL, 10);
 
-	devnum = udev_device_get_sysattr_value(udev_dev, "devnum");
-	if (!devnum)
+	devnum_s = udev_device_get_sysattr_value(udev_dev, "devnum");
+	if (!devnum_s)
 		return -1;
+	devnum = strtol(devnum_s, NULL, 10);
 
-	snprintf(path, sizeof(path), "/dev/bus/usb/%s/%s", busnum, devnum);
+	snprintf(path, sizeof(path), "/dev/bus/usb/%03d/%03d", busnum, devnum);
 
 	fd = open(path, O_RDWR, O_CLOEXEC);
 	if (fd < 0) {
-- 
1.8.3.1


^ permalink raw reply related

* Re: [PATCH v4 0/8] Add CSA 4 commands and events in hci.h
From: Marcel Holtmann @ 2013-10-02 16:57 UTC (permalink / raw)
  To: Dohyun Pyun; +Cc: linux-bluetooth, steve.jun
In-Reply-To: <1380718493-4577-1-git-send-email-dh79.pyun@samsung.com>

Hi Dohyun,

> This patchset contains several HCI commands and events addition.
> These HCI commands and events are included in Bluetooth Core
> Specification Addendum 4, and it will be used to implement 3DS
> profile.
> 
> Also I'm still implementing 3DS profile's master role in the BR/EDR
> controller. Summit and I'll send the patchsets about 3DS MGMT APIs
> soon.
> 
> Regards,
> Pyun
> 
> * Rebased the patchsets
> * Modify the subject and commit message
> 
> ----------------------------------------------------------------
> DoHyun Pyun (8):
>      Bluetooth: Add the definition and structure for Set Reserved LT_ADDR
>      Bluetooth: Add the definition and structure for Delete Reserved LT_ADDR
>      Bluetooth: Add the definition and structure for Set CSB Data
>      Bluetooth: Add the structure for Write Sync Train Parameters
>      Bluetooth: Add the definition and structure for Set CSB
>      Bluetooth: Add the definition for Start Synchronization Train
>      Bluetooth: Add the definition and stcuture for Sync Train Complete
>      Bluetooth: Add the definition for Slave Page Response Timeout
> 
> include/net/bluetooth/hci.h | 69 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
> 1 file changed, 69 insertions(+)

I applied all 8 patches to bluetooth-next tree.

Regards

Marcel


^ permalink raw reply

* Re: [PATCH] Regression fix revert: "Bluetooth: Add missing reset_resume dev_pm_ops"
From: Gustavo Padovan @ 2013-10-02 19:02 UTC (permalink / raw)
  To: Hans de Goede
  Cc: USB list, linux-bluetooth, Shuah Khan, Gustavo Padovan, stable
In-Reply-To: <1380374739-11581-1-git-send-email-hdegoede@redhat.com>

Hi Hans,

2013-09-28 Hans de Goede <hdegoede@redhat.com>:

> Many btusb devices have 2 modes, a hid mode and a bluetooth hci mode. These
> devices default to hid mode for BIOS use. This means that after having been
> reset they will revert to HID mode, and are no longer usable as a HCI.
> 
> Therefor it is a very bad idea to just blindly make reset_resume point to
> the regular resume handler. Note that the btusb driver has no clue how to
> switch these devices from hid to hci mode, this is done in userspace through
> udev rules, so the proper way to deal with this is to not have a reset-resume
> handler and instead let the usb-system re-enumerate the device, and re-run
> the udev rules.
> 
> I must also note, that the commit message for the commit causing this
> problem has a very weak motivation for the change:
> 
> "Add missing reset_resume dev_pm_ops. Missing reset_resume results in the
> following message after power management device test. This change sets
> reset_resume to btusb_resume().
> 
> [ 2506.936134] btusb 1-1.5:1.0: no reset_resume for driver btusb?
> [ 2506.936137] btusb 1-1.5:1.1: no reset_resume for driver btusb?"
> 
> Making a change solely to silence a warning while also changing important
> behavior (normal resume handling versus re-enumeration) requires a commit
> message with a proper explanation why it is safe to do so, which clearly lacks
> here, and unsurprisingly it turns out to not be safe to make this change.
> 
> Reverting the commit in question fixes bt no longer working on my Dell
> E6430 after a suspend/resume, and I believe it likely also fixes the
> following bugs:
> https://bugzilla.redhat.com/show_bug.cgi?id=988481
> https://bugzilla.redhat.com/show_bug.cgi?id=1010649
> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1213239
> 
> This reverts commit 502f769662978a2fe99d0caed5e53e3006107381.
> 
> Cc: Shuah Khan <shuah.kh@samsung.com>
> Cc: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
> Cc: stable@vger.kernel.org
> Signed-off-by: Hans de Goede <hdegoede@redhat.com>
> ---
>  drivers/bluetooth/btusb.c | 1 -
>  1 file changed, 1 deletion(-)

Patch has been applied to bluetooth.git. Thanks.

	Gustavo

^ permalink raw reply


This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox