* [PATCH 3/3] btio: Add ifndef/endif guard for btio.h
From: Zhenhua Zhang @ 2010-09-10 2:49 UTC (permalink / raw)
To: linux-bluetooth
In-Reply-To: <1284086984-17072-1-git-send-email-zhenhua.zhang@intel.com>
To avoid circular inclusion of include file.
---
btio/btio.h | 3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/btio/btio.h b/btio/btio.h
index 81fda8e..d373ed1 100644
--- a/btio/btio.h
+++ b/btio/btio.h
@@ -21,6 +21,8 @@
* Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA
*
*/
+#ifndef BT_IO_H
+#define BT_IO_H
#include <glib.h>
@@ -92,3 +94,4 @@ GIOChannel *bt_io_listen(BtIOType type, BtIOConnect connect,
GDestroyNotify destroy, GError **err,
BtIOOption opt1, ...);
+#endif
--
1.7.0.4
^ permalink raw reply related
* Re: Possible regression with skb_clone() in 2.6.36
From: Jarek Poplawski @ 2010-09-10 10:15 UTC (permalink / raw)
To: Gustavo F. Padovan; +Cc: netdev, linux-kernel, marcel, davem, linux-bluetooth
In-Reply-To: <1283988727-1456-1-git-send-email-padovan@profusion.mobi>
On 2010-09-09 01:32, Gustavo F. Padovan wrote:
> I've been experiencing some problems when running the L2CAP Streaming mode in
> 2.6.36. The system quickly runs in an Out Of Memory condition and crash. That
> wasn't happening before, so I think we may have a regression here (I didn't
> find where yet). The crash log is below.
>
> The following patch does not fix the regression, but shows that removing the
> skb_clone() call from l2cap_streaming_send() we workaround the problem. The
> patch is good anyway because it saves memory and time.
>
> By now I have no idea on how to fix this.
My suggestion is to check the length of conn->data_q in hci_send_acl()
while this happens, and maybe try to set some limit here.
Jarek P.
^ permalink raw reply
* [PATCH] Fix dict_append_array to accept types other than string
From: Luiz Augusto von Dentz @ 2010-09-10 11:50 UTC (permalink / raw)
To: linux-bluetooth
From: Luiz Augusto von Dentz <luiz.dentz-von@nokia.com>
---
src/dbus-common.c | 16 +++++++++++-----
1 files changed, 11 insertions(+), 5 deletions(-)
diff --git a/src/dbus-common.c b/src/dbus-common.c
index 0484450..5e4813c 100644
--- a/src/dbus-common.c
+++ b/src/dbus-common.c
@@ -210,8 +210,6 @@ static void append_array_variant(DBusMessageIter *iter, int type, void *val,
DBusMessageIter variant, array;
char type_sig[2] = { type, '\0' };
char array_sig[3] = { DBUS_TYPE_ARRAY, type, '\0' };
- const char ***str_array = val;
- int i;
dbus_message_iter_open_container(iter, DBUS_TYPE_VARIANT,
array_sig, &variant);
@@ -219,9 +217,17 @@ static void append_array_variant(DBusMessageIter *iter, int type, void *val,
dbus_message_iter_open_container(&variant, DBUS_TYPE_ARRAY,
type_sig, &array);
- for (i = 0; i < n_elements; i++)
- dbus_message_iter_append_basic(&array, type,
- &((*str_array)[i]));
+ if (dbus_type_is_fixed(type) == TRUE) {
+ dbus_message_iter_append_fixed_array(&array, type, val,
+ n_elements);
+ } else if (type == DBUS_TYPE_STRING || type == DBUS_TYPE_OBJECT_PATH) {
+ const char ***str_array = (const char ***) val;
+ int i;
+
+ for (i = 0; i < n_elements; i++)
+ dbus_message_iter_append_basic(&array, type,
+ &((*str_array)[i]));
+ }
dbus_message_iter_close_container(&variant, &array);
--
1.7.1
^ permalink raw reply related
* Re: [PATCH] Fix dict_append_array to accept types other than string
From: Johan Hedberg @ 2010-09-10 11:58 UTC (permalink / raw)
To: Luiz Augusto von Dentz; +Cc: linux-bluetooth
In-Reply-To: <1284119403-9367-1-git-send-email-luiz.dentz@gmail.com>
Hi Luiz,
On Fri, Sep 10, 2010, Luiz Augusto von Dentz wrote:
> From: Luiz Augusto von Dentz <luiz.dentz-von@nokia.com>
>
> ---
> src/dbus-common.c | 16 +++++++++++-----
> 1 files changed, 11 insertions(+), 5 deletions(-)
The patch is now upstream, with the following minor change that I did
for you:
> + const char ***str_array = (const char ***) val;
Since val is void * there's no need to do the type cast (the original
code didn't do it either).
Johan
^ permalink raw reply
* Request for input regarding new driver in MFD for GPS_Bluetooth_FM controller CG2900
From: Par-Gunnar Hjalmdahl @ 2010-09-10 12:53 UTC (permalink / raw)
To: linux-kernel, linux-bluetooth; +Cc: linus.walleij
Hi,
Me and my colleagues here at ST-Ericsson SA are working on a Linux
driver for our connectivity combo chip CG2900
(http://www.stericsson.com/product/223489.jsp).
CG2900 is a controller containing GPS, Bluetooth, and FM radio (also
called GBF-controller), which can be connected to the platform using
UART or SPI as transport. The communication towards the different
functionalities is done via so-called HCI H:4 channels, where the
first byte in the message determines the channel being used for the
particular message. Channels 1, 2, 3, and 4 are used for Bluetooth
(Command, ACL, SCO, and Event) according to Bluetooth specification
while 8 is used for FM radio and 9 is used for GPS. There are also a
few other channels used for various debug purposes.
Since there are multiple functionalities we thought that a good place
to put this driver is as a MFD driver. I hope you agree?
As can be seen below there is also a driver for the BlueZ stack, cg2900_hci.
The architecture of the driver is as follows:
- cg2900_core: Implements driver API. Keeps track of opened channels,
registered chip handlers, and transport used. When first user
registers it requests startup of chip. When last user deregisters it
requests shutdown of chip. Uses Bluetooth HCI Local Version
Information to determine chip connected.
- cg2900_chip: Implements chip specific features for the CG2900.
Downloads patches and settings during chip startup.
- stlc2690_chip: As cg2900_chip but for STLC2690 controller (BT/FM combo).
- cg2900_uart: Registers as a driver for the TTY Line Discipline
N_HCI. When transport is opened from User Space, e.g. from hciattach,
it registers as transport to cg2900_core.
- cg2900_spi: Registers to the SPI driver. When being probed it
registers as transport to cg2900_core.
- cg2900_char_device: Exposes all channels as character devices so
they can be used by user space stacks.
- cg2900_hci: Registers to BlueZ (i.e. not a MFD driver) and to the
CG2900 MFD driver. Acts as a connector for Bluetooth functionality
between BlueZ and CG2900 MFD driver.
The API as it is now contains functions for:
- register
- deregister
- alloc_skb
- write
- reset
- get_chip_revision
For a user the normal way to work would be:
- Register to the driver. The user supplies a name to the channel for
look-up and a set of callbacks for receiving data and detecting reset.
The register function returns, if successful, a pointer to a device
structure used when calling the other functions.
- Send data to the chip using the write function, supplying device
structure and sk_buffer.
- Receive data from the chip through the read callback, which
supplies device structure and sk_buffer.
- Perform reset of the chip of a lock-up is detected by the stack.
- Deregister from the driver.
Compared to other MFD drivers there are some major differences:
- The CG2900 driver does not use the MFD core functions, such as
mfd_add_devices, but that could be changed quite easily by replacing
register and deregister with users using the MFD device probe instead.
This could however collide with the next difference.
- The CG2900 driver is made with freedom of choice and usage in mind.
It is possible to dynamically open and close channels and even
transports. This means that you could open a channel first from Kernel
space (using API), then it could be closed and another user could open
it from User space (using char dev). From what I've heard this is not
very popular among the Linux community, but I really like the way it
works. Note that any channel can only have one user at a time.
I know that there are also other HCI combo chips with Linux drivers,
e.g by TI. If there is a wish we could modify this driver from cg2900
to e.g. hci_combo and make it neutral inside cg2900_core from which
chip is actually being used. This way any manufacturer could use it as
a generic framework for their multifunction HCI combo devices.
So if you've been able to read through this long message I would like
you to think through and voice your opinion about what I've presented
above. Especially:
- Shall I use the MFD functions instead of our own API?
- Is it OK to dynamically use the channels either from Kernel or User space?
- Would you prefer this to be a ST-Ericsson CG2900 chip driver only
or would you like an HCI-Combo framework where you could add your own
chips?
Best regards,
Pär-Gunnar Hjälmdahl
Senior Staff Engineer
ST-Ericsson SA
Lund, Sweden
^ permalink raw reply
* Re: Request for input regarding new driver in MFD for GPS_Bluetooth_FM controller CG2900
From: Alan Cox @ 2010-09-10 13:38 UTC (permalink / raw)
To: pghatwork
Cc: par-gunnar.p.hjalmdahl, linux-kernel, linux-bluetooth,
linus.walleij
In-Reply-To: <AANLkTikTBdr4U1bPtfXWhgLgdvWDMPJrFjBCktPL40dg@mail.gmail.com>
> - Is it OK to dynamically use the channels either from Kernel or User space?
Quite a few devices do this. In most cases it makes no sense to burden
the user with channel management so its only natural that opening the tty
or direct interfaces should "just work"
^ permalink raw reply
* Re: set LE advertise not working...
From: Anderson Briglia @ 2010-09-10 13:40 UTC (permalink / raw)
To: Pavan Savoy; +Cc: linux-bluetooth
In-Reply-To: <AANLkTikJFwwjs53_2F6NuBd-e00p1AnYahPMwYNgrveE@mail.gmail.com>
Hi Pavan,
Try to make a hciconfig reset before setting leadv.
Are you using that kernel patches I send before, right?
Regards,
Anderson Briglia
On 09/09/2010 03:58 PM, Pavan Savoy wrote:
> I have an LE enabled BT controller, and I happened to send across a
> simple "leadv" from the recently updated hciconfig
> I got back the following data
> "4 e 5 1 a 20 c 3a" and hence
> "Can't set advertise mode on hci0: Success (0)"
> and 0xC I guess by the BT spec means the command is disallowed (for
> reasons unknown?....)
>
> So I'm just wondering, am I supposed to run some HCI-VS commands to
> enable LE? I mean I should ask my vendor I agree, but anyone who has
> got it working.. do they run some VS commands before enabling LE
> advertising?
> --
> 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
>
^ permalink raw reply
* [PATCH] Removing role field from ORG tag
From: Rafal Michalski @ 2010-09-10 14:12 UTC (permalink / raw)
To: linux-bluetooth; +Cc: Rafal Michalski
Previously role field was under ORG tag. Now it's single field under
ROLE tag.
---
plugins/phonebook-tracker.c | 2 +-
plugins/vcard.c | 12 ++++++------
plugins/vcard.h | 2 +-
3 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/plugins/phonebook-tracker.c b/plugins/phonebook-tracker.c
index 41df840..43c2e28 100644
--- a/plugins/phonebook-tracker.c
+++ b/plugins/phonebook-tracker.c
@@ -863,7 +863,7 @@ add_entry:
contact->photo = g_strdup(reply[21]);
contact->company = g_strdup(reply[22]);
contact->department = g_strdup(reply[23]);
- contact->title = g_strdup(reply[24]);
+ contact->role = g_strdup(reply[24]);
contact->uid = g_strdup(reply[32]);
set_call_type(contact, reply[COL_DATE], reply[COL_SENT],
diff --git a/plugins/vcard.c b/plugins/vcard.c
index 4a77eb3..e277ced 100644
--- a/plugins/vcard.c
+++ b/plugins/vcard.c
@@ -357,9 +357,6 @@ static gboolean org_fields_present(struct phonebook_contact *contact)
if (contact->department && strlen(contact->department))
return TRUE;
- if (contact->title && strlen(contact->title))
- return TRUE;
-
return FALSE;
}
@@ -371,8 +368,8 @@ static void vcard_printf_org(GString *vcards,
return;
}
- vcard_printf(vcards, "ORG:%s;%s;%s", contact->company,
- contact->department, contact->title);
+ vcard_printf(vcards, "ORG:%s;%s", contact->company,
+ contact->department);
}
static void vcard_printf_address(GString *vcards, uint8_t format,
@@ -539,6 +536,9 @@ void phonebook_add_contact(GString *vcards, struct phonebook_contact *contact,
if (filter & FILTER_ORG)
vcard_printf_org(vcards, contact);
+ if (filter & FILTER_ROLE)
+ vcard_printf_tag(vcards, format, "ROLE", NULL, contact->role);
+
if (filter & FILTER_X_IRMC_CALL_DATETIME)
vcard_printf_datetime(vcards, contact);
@@ -596,7 +596,7 @@ void phonebook_contact_free(struct phonebook_contact *contact)
g_free(contact->photo);
g_free(contact->company);
g_free(contact->department);
- g_free(contact->title);
+ g_free(contact->role);
g_free(contact->datetime);
g_free(contact);
}
diff --git a/plugins/vcard.h b/plugins/vcard.h
index 4d134c2..0ed51b9 100644
--- a/plugins/vcard.h
+++ b/plugins/vcard.h
@@ -78,7 +78,7 @@ struct phonebook_contact {
char *photo;
char *company;
char *department;
- char *title;
+ char *role;
char *datetime;
int calltype;
};
--
1.6.3.3
^ permalink raw reply related
* [PATCH v2 1/2] Bluetooth: Implement LE Set Advertise Enable cmd
From: Anderson Briglia @ 2010-09-10 15:14 UTC (permalink / raw)
To: linux-bluetooth; +Cc: Anderson Briglia
This patch implements LE Set Advertise Enable command for dual mode and
Low Energy hci controllers. It also adds new HCI flags in order to
indicate the Advertising state for userland applications and kernel
itself.
Signed-off-by: Anderson Briglia <anderson.briglia@openbossa.org>
---
include/net/bluetooth/hci.h | 7 +++++++
net/bluetooth/hci_event.c | 27 +++++++++++++++++++++++++++
2 files changed, 34 insertions(+), 0 deletions(-)
diff --git a/include/net/bluetooth/hci.h b/include/net/bluetooth/hci.h
index bcbdd6d..a28e92b 100644
--- a/include/net/bluetooth/hci.h
+++ b/include/net/bluetooth/hci.h
@@ -76,6 +76,8 @@ enum {
HCI_INQUIRY,
HCI_RAW,
+
+ HCI_LE_ADV,
};
/* HCI ioctl defines */
@@ -593,6 +595,11 @@ struct hci_rp_read_bd_addr {
bdaddr_t bdaddr;
} __packed;
+/* --- HCI LE Commands --- */
+#define HCI_OP_LE_SET_ADVERTISE_ENABLE 0x200a
+ #define ADVERTISE_ENABLED 0x01
+ #define ADVERTISE_DISABLED 0x00
+
/* ---- HCI Events ---- */
#define HCI_EV_INQUIRY_COMPLETE 0x01
diff --git a/net/bluetooth/hci_event.c b/net/bluetooth/hci_event.c
index bfef5ba..51e2776 100644
--- a/net/bluetooth/hci_event.c
+++ b/net/bluetooth/hci_event.c
@@ -822,6 +822,29 @@ static void hci_cs_exit_sniff_mode(struct hci_dev *hdev, __u8 status)
hci_dev_unlock(hdev);
}
+static void hci_cc_le_set_advertise(struct hci_dev *hdev, struct sk_buff *skb)
+{
+ __u8 status = *((__u8 *) skb->data);
+ void *sent;
+
+ BT_DBG("%s status 0x%x", hdev->name, status);
+
+ sent = hci_sent_cmd_data(hdev, HCI_OP_LE_SET_ADVERTISE_ENABLE);
+ if (!sent)
+ return;
+
+ if (!status) {
+ __u8 param = *((__u8 *) sent);
+
+ if (param & ADVERTISE_ENABLED)
+ set_bit(HCI_LE_ADV, &hdev->flags);
+ else
+ clear_bit(HCI_LE_ADV, &hdev->flags);
+ }
+
+ hci_req_complete(hdev, status);
+}
+
static inline void hci_inquiry_complete_evt(struct hci_dev *hdev, struct sk_buff *skb)
{
__u8 status = *((__u8 *) skb->data);
@@ -1310,6 +1333,10 @@ static inline void hci_cmd_complete_evt(struct hci_dev *hdev, struct sk_buff *sk
hci_cc_read_bd_addr(hdev, skb);
break;
+ case HCI_OP_LE_SET_ADVERTISE_ENABLE:
+ hci_cc_le_set_advertise(hdev, skb);
+ break;
+
default:
BT_DBG("%s opcode 0x%x", hdev->name, opcode);
break;
--
1.7.0.4
^ permalink raw reply related
* [PATCH v2 2/2] Bluetooth: Implement LE Set Scan Enable cmd
From: Anderson Briglia @ 2010-09-10 15:14 UTC (permalink / raw)
To: linux-bluetooth; +Cc: Anderson Briglia
In-Reply-To: <1284131696-26117-1-git-send-email-anderson.briglia@openbossa.org>
This patch implements LE Set Scan Enable command for dual
mode and Low Energy hci controllers. It also adds new HCI flags
in order to indicate the LE Scanning state for userland applications
and kernel itself.
Signed-off-by: Anderson Briglia <anderson.briglia@openbossa.org>
---
include/net/bluetooth/hci.h | 5 +++++
net/bluetooth/hci_event.c | 27 +++++++++++++++++++++++++++
2 files changed, 32 insertions(+), 0 deletions(-)
diff --git a/include/net/bluetooth/hci.h b/include/net/bluetooth/hci.h
index a28e92b..752c942 100644
--- a/include/net/bluetooth/hci.h
+++ b/include/net/bluetooth/hci.h
@@ -78,6 +78,7 @@ enum {
HCI_RAW,
HCI_LE_ADV,
+ HCI_LE_SCAN,
};
/* HCI ioctl defines */
@@ -600,6 +601,10 @@ struct hci_rp_read_bd_addr {
#define ADVERTISE_ENABLED 0x01
#define ADVERTISE_DISABLED 0x00
+#define HCI_OP_LE_SET_SCAN_ENABLE 0x200c
+ #define LE_SCAN_ENABLED 0x01
+ #define LE_SCAN_DISABLED 0x00
+
/* ---- HCI Events ---- */
#define HCI_EV_INQUIRY_COMPLETE 0x01
diff --git a/net/bluetooth/hci_event.c b/net/bluetooth/hci_event.c
index 51e2776..c4bfbdc 100644
--- a/net/bluetooth/hci_event.c
+++ b/net/bluetooth/hci_event.c
@@ -845,6 +845,29 @@ static void hci_cc_le_set_advertise(struct hci_dev *hdev, struct sk_buff *skb)
hci_req_complete(hdev, status);
}
+static void hci_cc_le_set_scan(struct hci_dev *hdev, struct sk_buff *skb)
+{
+ __u8 status = *((__u8 *) skb->data);
+ void *sent;
+
+ BT_DBG("%s status 0x%x", hdev->name, status);
+
+ sent = hci_sent_cmd_data(hdev, HCI_OP_LE_SET_SCAN_ENABLE);
+ if (!sent)
+ return;
+
+ if (!status) {
+ __u8 param = *((__u8 *) sent);
+
+ if (param & LE_SCAN_ENABLED)
+ set_bit(HCI_LE_SCAN, &hdev->flags);
+ else
+ clear_bit(HCI_LE_SCAN, &hdev->flags);
+ }
+
+ hci_req_complete(hdev, status);
+}
+
static inline void hci_inquiry_complete_evt(struct hci_dev *hdev, struct sk_buff *skb)
{
__u8 status = *((__u8 *) skb->data);
@@ -1337,6 +1360,10 @@ static inline void hci_cmd_complete_evt(struct hci_dev *hdev, struct sk_buff *sk
hci_cc_le_set_advertise(hdev, skb);
break;
+ case HCI_OP_LE_SET_SCAN_ENABLE:
+ hci_cc_le_set_scan(hdev, skb);
+ break;
+
default:
BT_DBG("%s opcode 0x%x", hdev->name, opcode);
break;
--
1.7.0.4
^ permalink raw reply related
* Re: set LE advertise not working...
From: Pavan Savoy @ 2010-09-10 16:53 UTC (permalink / raw)
To: Anderson Briglia; +Cc: linux-bluetooth
In-Reply-To: <4C8A3537.2010606@openbossa.org>
Nope, I haven't applied the kernel patches...
But my kernel diff to the latest kernel is only regarding the "block"
and "unblock" to black list devices....
do I need some patches in kernel for enabling/disabling BLE too ?
I thought it just sends out the commands to controller...
On Fri, Sep 10, 2010 at 8:40 AM, Anderson Briglia
<anderson.briglia@openbossa.org> wrote:
> Hi Pavan,
>
> Try to make a hciconfig reset before setting leadv.
> Are you using that kernel patches I send before, right?
>
> Regards,
>
> Anderson Briglia
>
> On 09/09/2010 03:58 PM, Pavan Savoy wrote:
>>
>> I have an LE enabled BT controller, and I happened to send across a
>> simple "leadv" from the recently updated hciconfig
>> I got back the following data
>> "4 e 5 1 a 20 c 3a" and hence
>> "Can't set advertise mode on hci0: Success (0)"
>> and 0xC I guess by the BT spec means the command is disallowed (for
>> reasons unknown?....)
>>
>> So I'm just wondering, am I supposed to run some HCI-VS commands to
>> enable LE? I mean I should ask my vendor I agree, but anyone who has
>> got it working.. do they run some VS commands before enabling LE
>> advertising?
>> --
>> 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
>>
>
>
^ permalink raw reply
* Re: Possible regression with skb_clone() in 2.6.36
From: Mat Martineau @ 2010-09-10 16:53 UTC (permalink / raw)
To: Gustavo F. Padovan; +Cc: linux-bluetooth, netdev, linux-kernel, marcel, davem
In-Reply-To: <1283988727-1456-1-git-send-email-padovan@profusion.mobi>
Gustavo -
I'm not sure why the streaming code used to work, but this does not
look like an skb_clone() problem. Your patch to remove the
skb_clone() call in l2cap_streaming_send() addresses the root cause of
this crash.
On Wed, 8 Sep 2010, Gustavo F. Padovan wrote:
> I've been experiencing some problems when running the L2CAP Streaming mode in
> 2.6.36. The system quickly runs in an Out Of Memory condition and crash. That
> wasn't happening before, so I think we may have a regression here (I didn't
> find where yet). The crash log is below.
>
> The following patch does not fix the regression, but shows that removing the
> skb_clone() call from l2cap_streaming_send() we workaround the problem. The
> patch is good anyway because it saves memory and time.
>
> By now I have no idea on how to fix this.
>
> <snip>
This has to do with the sk->sk_wmem_alloc accounting that controls the
amount of write buffer space used on the socket.
When the L2CAP streaming mode socket segments its data, it allocates
memory using sock_alloc_send_skb() (via bt_skb_send_alloc()). Before
that allocation call returns, skb_set_owner_w() is called on the new
skb. This adds to sk->sk_wmem_alloc and sets skb->destructor so that
sk->sk_wmem_alloc is correctly updated when the skb is freed.
When that skb is cloned, the clone is not "owned" by the write buffer.
The clone's destructor is set to NULL in __skb_clone(). The version
of l2cap_streaming_send() that runs out of memory is passing the
non-owned skb clone down to the HCI layer. The original skb (the one
that's "owned by w") is immediately freed, which adjusts
sk->sk_wmem_alloc back down - the socket thinks it has unlimited write
buffer space. As a result, bt_skb_send_alloc() never blocks waiting
for buffer space (or returns EAGAIN for nonblocking writes) and the
HCI send queue keeps growing.
This isn't a problem for the ERTM sends, because the original skbs are
kept in the ERTM tx queue until they are acked. Once they're acked,
the write buffer space is freed and additional skbs can be allocated.
Regards,
--
Mat Martineau
Employee of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum
^ permalink raw reply
* Re: [PATCH] Removing role field from ORG tag
From: Johan Hedberg @ 2010-09-10 16:55 UTC (permalink / raw)
To: Rafal Michalski; +Cc: linux-bluetooth
In-Reply-To: <1284127974-8230-1-git-send-email-michalski.raf@gmail.com>
Hi Rafal,
On Fri, Sep 10, 2010, Rafal Michalski wrote:
> Previously role field was under ORG tag. Now it's single field under
> ROLE tag.
> ---
> plugins/phonebook-tracker.c | 2 +-
> plugins/vcard.c | 12 ++++++------
> plugins/vcard.h | 2 +-
> 3 files changed, 8 insertions(+), 8 deletions(-)
The patch has been pushed upstream. Thanks.
Johan
^ permalink raw reply
* RE: set LE advertise not working...
From: Mike Tsai @ 2010-09-10 17:49 UTC (permalink / raw)
To: Pavan Savoy, Anderson Briglia; +Cc: linux-bluetooth@vger.kernel.org
In-Reply-To: <AANLkTin02sOL89MuUhWe1_nOg4umytfJKRfc=Z_dhpRq@mail.gmail.com>
Is it possible that BT controller is not in standby state. i.e. it could be already in scanning or advertising sate by default?
Mike
-----Original Message-----
From: linux-bluetooth-owner@vger.kernel.org [mailto:linux-bluetooth-owner@vger.kernel.org] On Behalf Of Pavan Savoy
Sent: Friday, September 10, 2010 9:53 AM
To: Anderson Briglia
Cc: linux-bluetooth@vger.kernel.org
Subject: Re: set LE advertise not working...
Nope, I haven't applied the kernel patches...
But my kernel diff to the latest kernel is only regarding the "block"
and "unblock" to black list devices....
do I need some patches in kernel for enabling/disabling BLE too ?
I thought it just sends out the commands to controller...
On Fri, Sep 10, 2010 at 8:40 AM, Anderson Briglia
<anderson.briglia@openbossa.org> wrote:
> Hi Pavan,
>
> Try to make a hciconfig reset before setting leadv.
> Are you using that kernel patches I send before, right?
>
> Regards,
>
> Anderson Briglia
>
> On 09/09/2010 03:58 PM, Pavan Savoy wrote:
>>
>> I have an LE enabled BT controller, and I happened to send across a
>> simple "leadv" from the recently updated hciconfig
>> I got back the following data
>> "4 e 5 1 a 20 c 3a" and hence
>> "Can't set advertise mode on hci0: Success (0)"
>> and 0xC I guess by the BT spec means the command is disallowed (for
>> reasons unknown?....)
>>
>> So I'm just wondering, am I supposed to run some HCI-VS commands to
>> enable LE? I mean I should ask my vendor I agree, but anyone who has
>> got it working.. do they run some VS commands before enabling LE
>> advertising?
>> --
>> 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
>>
>
>
--
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
^ permalink raw reply
* Re: MAP implementation status
From: Gustavo F. Padovan @ 2010-09-10 18:12 UTC (permalink / raw)
To: Radoslaw Jablonski; +Cc: linux-bluetooth@vger.kernel.org
In-Reply-To: <4C88D729.7050803@nokia.com>
Hi Radoslaw,
* Radoslaw Jablonski <ext-jablonski.radoslaw@nokia.com> [2010-09-09 15:46:33 +0300]:
>
> Hi all,
> We plan to start implementation of Message Access Profile Server as
> obexd plugin. Before we start with coding part I need to check if
> someone else started implementing MAP Server, MNS Server of Map client.
> If some code is already available, then we could combine our forces to
> add MAP support for OBEXD.
We had a Google Summer of Code Project on MAP this year. Vinicius was
the mentor, he can talk about.
--
Gustavo F. Padovan
ProFUSION embedded systems - http://profusion.mobi
^ permalink raw reply
* Re: set LE advertise not working...
From: Anderson Briglia @ 2010-09-10 18:14 UTC (permalink / raw)
To: Pavan Savoy; +Cc: linux-bluetooth
In-Reply-To: <AANLkTin02sOL89MuUhWe1_nOg4umytfJKRfc=Z_dhpRq@mail.gmail.com>
On 09/10/2010 12:53 PM, Pavan Savoy wrote:
> Nope, I haven't applied the kernel patches...
> But my kernel diff to the latest kernel is only regarding the "block"
> and "unblock" to black list devices....
>
> do I need some patches in kernel for enabling/disabling BLE too ?
> I thought it just sends out the commands to controller...
>
You are right. You don't need to have the kernel patches.
I did some tests here and everything goes ok.
Check the hcidump output below:
2010-09-10 14:13:19.032099 < HCI Command: Unknown (0x08|0x000a) plen 1
0000: 01 .
2010-09-10 14:13:19.070320 > HCI Event: Command Complete (0x0e) plen 4
Unknown (0x08|0x000a) ncmd 2
0000: 00
I just did a hciconfig hci0 leadv
Regards,
Anderson Briglia
> On Fri, Sep 10, 2010 at 8:40 AM, Anderson Briglia
> <anderson.briglia@openbossa.org> wrote:
>
>> Hi Pavan,
>>
>> Try to make a hciconfig reset before setting leadv.
>> Are you using that kernel patches I send before, right?
>>
>> Regards,
>>
>> Anderson Briglia
>>
>> On 09/09/2010 03:58 PM, Pavan Savoy wrote:
>>
>>> I have an LE enabled BT controller, and I happened to send across a
>>> simple "leadv" from the recently updated hciconfig
>>> I got back the following data
>>> "4 e 5 1 a 20 c 3a" and hence
>>> "Can't set advertise mode on hci0: Success (0)"
>>> and 0xC I guess by the BT spec means the command is disallowed (for
>>> reasons unknown?....)
>>>
>>> So I'm just wondering, am I supposed to run some HCI-VS commands to
>>> enable LE? I mean I should ask my vendor I agree, but anyone who has
>>> got it working.. do they run some VS commands before enabling LE
>>> advertising?
>>> --
>>> 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
>>>
>>>
>>
>>
^ permalink raw reply
* Re: [PATCH v2 1/2] Bluetooth: Implement LE Set Advertise Enable cmd
From: Gustavo F. Padovan @ 2010-09-10 18:20 UTC (permalink / raw)
To: Anderson Briglia; +Cc: linux-bluetooth
In-Reply-To: <1284131696-26117-1-git-send-email-anderson.briglia@openbossa.org>
Hi Anderson,
* Anderson Briglia <anderson.briglia@openbossa.org> [2010-09-10 11:14:55 -0400]:
> This patch implements LE Set Advertise Enable command for dual mode and
> Low Energy hci controllers. It also adds new HCI flags in order to
> indicate the Advertising state for userland applications and kernel
> itself.
>
> Signed-off-by: Anderson Briglia <anderson.briglia@openbossa.org>
> ---
> include/net/bluetooth/hci.h | 7 +++++++
> net/bluetooth/hci_event.c | 27 +++++++++++++++++++++++++++
> 2 files changed, 34 insertions(+), 0 deletions(-)
>
> diff --git a/include/net/bluetooth/hci.h b/include/net/bluetooth/hci.h
> index bcbdd6d..a28e92b 100644
> --- a/include/net/bluetooth/hci.h
> +++ b/include/net/bluetooth/hci.h
> @@ -76,6 +76,8 @@ enum {
> HCI_INQUIRY,
>
> HCI_RAW,
> +
> + HCI_LE_ADV,
> };
>
> /* HCI ioctl defines */
> @@ -593,6 +595,11 @@ struct hci_rp_read_bd_addr {
> bdaddr_t bdaddr;
> } __packed;
>
> +/* --- HCI LE Commands --- */
> +#define HCI_OP_LE_SET_ADVERTISE_ENABLE 0x200a
> + #define ADVERTISE_ENABLED 0x01
> + #define ADVERTISE_DISABLED 0x00
Just make these LE_ADVERTISE_ENABLED and LE_ADVERTISE_DISABLED then we
should be fine with this patch.
--
Gustavo F. Padovan
ProFUSION embedded systems - http://profusion.mobi
^ permalink raw reply
* Re: MAP implementation status
From: Luiz Augusto von Dentz @ 2010-09-10 18:26 UTC (permalink / raw)
To: Gustavo F. Padovan; +Cc: Radoslaw Jablonski, linux-bluetooth@vger.kernel.org
In-Reply-To: <20100910181259.GA19693@vigoh>
Hi,
On Fri, Sep 10, 2010 at 9:12 PM, Gustavo F. Padovan
<padovan@profusion.mobi> wrote:
> Hi Radoslaw,
>
> * Radoslaw Jablonski <ext-jablonski.radoslaw@nokia.com> [2010-09-09 15:46:33 +0300]:
>
>>
>> Hi all,
>> We plan to start implementation of Message Access Profile Server as
>> obexd plugin. Before we start with coding part I need to check if
>> someone else started implementing MAP Server, MNS Server of Map client.
>> If some code is already available, then we could combine our forces to
>> add MAP support for OBEXD.
>
> We had a Google Summer of Code Project on MAP this year. Vinicius was
> the mentor, he can talk about.
iirc it was mainly a MAP client, the other parts that are missing is:
- MAP plugin + drivers
- Backend infrastructure
- Backends
--
Luiz Augusto von Dentz
Computer Engineer
^ permalink raw reply
* Re: set LE advertise not working...
From: Pavan Savoy @ 2010-09-10 19:01 UTC (permalink / raw)
To: Anderson Briglia; +Cc: linux-bluetooth
In-Reply-To: <4C8A758B.1060708@openbossa.org>
No, I don't suppose my controller was in a advertising state.. even if
it was why the return 0x0c? (command disallowed ..)
I wanted to know whether you have some HCI-VS commands which sort of
enable the LE (AMP/radio/controller) ?
Is it only then the leadv command works? Or does it just works right-away.
I have one of those all in 1 chips.. bt/fm-rx-tx/gps so I am wondering
should I do something to enable BLE and is it some sort of un-spoken
standard?
On Fri, Sep 10, 2010 at 1:14 PM, Anderson Briglia
<anderson.briglia@openbossa.org> wrote:
> On 09/10/2010 12:53 PM, Pavan Savoy wrote:
>>
>> Nope, I haven't applied the kernel patches...
>> But my kernel diff to the latest kernel is only regarding the "block"
>> and "unblock" to black list devices....
>>
>> do I need some patches in kernel for enabling/disabling BLE too ?
>> I thought it just sends out the commands to controller...
>>
>
> You are right. You don't need to have the kernel patches.
> I did some tests here and everything goes ok.
> Check the hcidump output below:
>
> 2010-09-10 14:13:19.032099 < HCI Command: Unknown (0x08|0x000a) plen 1
> 0000: 01 .
> 2010-09-10 14:13:19.070320 > HCI Event: Command Complete (0x0e) plen 4
> Unknown (0x08|0x000a) ncmd 2
> 0000: 00
>
> I just did a hciconfig hci0 leadv
>
> Regards,
>
> Anderson Briglia
>>
>> On Fri, Sep 10, 2010 at 8:40 AM, Anderson Briglia
>> <anderson.briglia@openbossa.org> wrote:
>>
>>>
>>> Hi Pavan,
>>>
>>> Try to make a hciconfig reset before setting leadv.
>>> Are you using that kernel patches I send before, right?
>>>
>>> Regards,
>>>
>>> Anderson Briglia
>>>
>>> On 09/09/2010 03:58 PM, Pavan Savoy wrote:
>>>
>>>>
>>>> I have an LE enabled BT controller, and I happened to send across a
>>>> simple "leadv" from the recently updated hciconfig
>>>> I got back the following data
>>>> "4 e 5 1 a 20 c 3a" and hence
>>>> "Can't set advertise mode on hci0: Success (0)"
>>>> and 0xC I guess by the BT spec means the command is disallowed (for
>>>> reasons unknown?....)
>>>>
>>>> So I'm just wondering, am I supposed to run some HCI-VS commands to
>>>> enable LE? I mean I should ask my vendor I agree, but anyone who has
>>>> got it working.. do they run some VS commands before enabling LE
>>>> advertising?
>>>> --
>>>> 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
>>>>
>>>>
>>>
>>>
>
>
^ permalink raw reply
* Re: Request for input regarding new driver in MFD for GPS_Bluetooth_FM controller CG2900
From: Pavan Savoy @ 2010-09-10 19:07 UTC (permalink / raw)
To: Alan Cox
Cc: pghatwork, par-gunnar.p.hjalmdahl, linux-kernel, linux-bluetooth,
linus.walleij
In-Reply-To: <20100910143813.4af0a3ce@lxorguk.ukuu.org.uk>
Can you directly make use of the ti-st driver which is currently staged?
It has _EXACTLY_ the same thing.... which is REALLY REALLY surprising !!!
On Fri, Sep 10, 2010 at 8:38 AM, Alan Cox <alan@lxorguk.ukuu.org.uk> wrote:
>> - Is it OK to dynamically use the channels either from Kernel or User space?
>
> Quite a few devices do this. In most cases it makes no sense to burden
> the user with channel management so its only natural that opening the tty
> or direct interfaces should "just work"
> --
> 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
>
^ permalink raw reply
* Re: Request for input regarding new driver in MFD for GPS_Bluetooth_FM controller CG2900
From: Pavan Savoy @ 2010-09-10 19:25 UTC (permalink / raw)
To: Alan Cox, linus.walleij, par-gunnar.p.hjalmdahl
Cc: pghatwork, linux-kernel, linux-bluetooth
In-Reply-To: <AANLkTikXFmaZs+XzrOWjWoLPhyUy0CEXfOQMqP=Xp1cO@mail.gmail.com>
ok bit more of information ....
We don;t use the hciattach, instead we have our own daemon which opens
up the UART and installs the line discipline (not N_HCI, but similar
one called N_SHARED) when the hciconfig hci0 up happens or even when
/dev/radio0 (FM V4L2 device) happens or when generic GPS character
device (/dev/tigps) happens...
There is non-mailine driver which gets modified to get into mainline @
http://git.omapzoom.org/?p=kernel/omap.git;a=tree;f=drivers/misc/ti-st;h=028ff4a739d7b59b94d0c613b5ef510ff338b65d;hb=refs/heads/p-android-omap-2.6.32
feel free to have a look at it...
Yes our solution too works with BlueZ and non-exactly a MFD driver but
it is a simple platform device driver .. by looks of things the driver
can run as is for your chip too .. (except for the firmware search and
download part .. may be...).
and note when we would want to support SPI transport for the same, we
plan a SPI-TTY driver ('ala usb-serial) where-in we can install this
N_TI_WL line discipline on that /dev/ttySPI0 device, and the SPI
related stuff to be handled by the spi-tty.c which registers itself as
a tty_device and a tty_driver ....
regards,
Pavan
On Fri, Sep 10, 2010 at 2:07 PM, Pavan Savoy <pavan_savoy@sify.com> wrote:
> Can you directly make use of the ti-st driver which is currently staged?
> It has _EXACTLY_ the same thing.... which is REALLY REALLY surprising !!!
>
> On Fri, Sep 10, 2010 at 8:38 AM, Alan Cox <alan@lxorguk.ukuu.org.uk> wrote:
>>> - Is it OK to dynamically use the channels either from Kernel or User space?
>>
>> Quite a few devices do this. In most cases it makes no sense to burden
>> the user with channel management so its only natural that opening the tty
>> or direct interfaces should "just work"
>> --
>> 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
>>
>
^ permalink raw reply
* Re: Possible regression with skb_clone() in 2.6.36
From: Gustavo F. Padovan @ 2010-09-10 19:45 UTC (permalink / raw)
To: Mat Martineau; +Cc: linux-bluetooth, netdev, linux-kernel, marcel, davem
In-Reply-To: <alpine.DEB.2.00.1009100920270.14322@linux-sea-02>
Hi Mat,
* Mat Martineau <mathewm@codeaurora.org> [2010-09-10 09:53:31 -0700]:
>
> Gustavo -
>
> I'm not sure why the streaming code used to work, but this does not
> look like an skb_clone() problem. Your patch to remove the
> skb_clone() call in l2cap_streaming_send() addresses the root cause of
> this crash.
>
> On Wed, 8 Sep 2010, Gustavo F. Padovan wrote:
>
> > I've been experiencing some problems when running the L2CAP Streaming mode in
> > 2.6.36. The system quickly runs in an Out Of Memory condition and crash. That
> > wasn't happening before, so I think we may have a regression here (I didn't
> > find where yet). The crash log is below.
> >
> > The following patch does not fix the regression, but shows that removing the
> > skb_clone() call from l2cap_streaming_send() we workaround the problem. The
> > patch is good anyway because it saves memory and time.
> >
> > By now I have no idea on how to fix this.
> >
> > <snip>
>
> This has to do with the sk->sk_wmem_alloc accounting that controls the
> amount of write buffer space used on the socket.
>
> When the L2CAP streaming mode socket segments its data, it allocates
> memory using sock_alloc_send_skb() (via bt_skb_send_alloc()). Before
> that allocation call returns, skb_set_owner_w() is called on the new
> skb. This adds to sk->sk_wmem_alloc and sets skb->destructor so that
> sk->sk_wmem_alloc is correctly updated when the skb is freed.
>
> When that skb is cloned, the clone is not "owned" by the write buffer.
> The clone's destructor is set to NULL in __skb_clone(). The version
> of l2cap_streaming_send() that runs out of memory is passing the
> non-owned skb clone down to the HCI layer. The original skb (the one
> that's "owned by w") is immediately freed, which adjusts
> sk->sk_wmem_alloc back down - the socket thinks it has unlimited write
> buffer space. As a result, bt_skb_send_alloc() never blocks waiting
> for buffer space (or returns EAGAIN for nonblocking writes) and the
> HCI send queue keeps growing.
If the problem is what you are saying, add a skb_set_owner_w(skb, sk) on
the cloned skb should solve the problem, but it doesn't. That's exactly
what tcp_transmit_skb() does. Also that just appeared in 2.6.36, is was
working fine before, i.e, we have a regression here.
>
> This isn't a problem for the ERTM sends, because the original skbs are
> kept in the ERTM tx queue until they are acked. Once they're acked,
> the write buffer space is freed and additional skbs can be allocated.
It affects ERTM as well, but in that case the kernel doesn't crash
because ERTM block on sending trying to allocate memory. Then we are not
able to receive any ack (everything stays queued in sk_backlog_queue as
the sk is owned by the user) and ERTM stalls.
--
Gustavo F. Padovan
ProFUSION embedded systems - http://profusion.mobi
^ permalink raw reply
* Re: set LE advertise not working...
From: Anderson Lizardo @ 2010-09-10 20:35 UTC (permalink / raw)
To: Pavan Savoy; +Cc: Anderson Briglia, linux-bluetooth
In-Reply-To: <AANLkTi=v3ZbVv2PkgCnSKxMRBPmbZCM5JA+bBXfDEd5x@mail.gmail.com>
On Fri, Sep 10, 2010 at 3:01 PM, Pavan Savoy <pavan_savoy@sify.com> wrote:
> No, I don't suppose my controller was in a advertising state.. even if
> it was why the return 0x0c? (command disallowed ..)
>
> I wanted to know whether you have some HCI-VS commands which sort of
> enable the LE (AMP/radio/controller) ?
> Is it only then the leadv command works? Or does it just works right-away.
> I have one of those all in 1 chips.. bt/fm-rx-tx/gps so I am wondering
> should I do something to enable BLE and is it some sort of un-spoken
> standard?
Does LE scan work for this same hardware?
Do you have some windows software to test this hardware ? if so, you
can try putting one device in advertise mode there , then attempt
lescan on the other (from linux)... If it works, most probably the
hardware might require some initialization...
At least some hardware requires firmware upload and vendor specific
one-time initialization which (I think) is out of scope for hciconfig.
Regards,
--
Anderson Lizardo
OpenBossa Labs - INdT
Manaus - Brazil
^ permalink raw reply
* Re: set LE advertise not working...
From: Claudio Takahasi @ 2010-09-10 21:03 UTC (permalink / raw)
To: Anderson Lizardo; +Cc: Pavan Savoy, Anderson Briglia, linux-bluetooth
In-Reply-To: <AANLkTi=8nM_nh_4riZaCj77LLzaqRie0dPjGswqpSFz-@mail.gmail.com>
On Fri, Sep 10, 2010 at 5:35 PM, Anderson Lizardo
<anderson.lizardo@openbossa.org> wrote:
> On Fri, Sep 10, 2010 at 3:01 PM, Pavan Savoy <pavan_savoy@sify.com> wrote:
>> No, I don't suppose my controller was in a advertising state.. even if
>> it was why the return 0x0c? (command disallowed ..)
>>
>> I wanted to know whether you have some HCI-VS commands which sort of
>> enable the LE (AMP/radio/controller) ?
>> Is it only then the leadv command works? Or does it just works right-away.
>> I have one of those all in 1 chips.. bt/fm-rx-tx/gps so I am wondering
>> should I do something to enable BLE and is it some sort of un-spoken
>> standard?
>
> Does LE scan work for this same hardware?
>
> Do you have some windows software to test this hardware ? if so, you
> can try putting one device in advertise mode there , then attempt
> lescan on the other (from linux)... If it works, most probably the
> hardware might require some initialization...
>
> At least some hardware requires firmware upload and vendor specific
> one-time initialization which (I think) is out of scope for hciconfig.
>
> Regards,
> --
> Anderson Lizardo
> OpenBossa Labs - INdT
> Manaus - Brazil
> --
> 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
>
Hi All,
I noticed that some LE hardwares don't allow to enable scanning or
advertising when inquiry scan and/or page scan are enabled.
Try to disable it using hciconfig or the D-Bus method before to start
LE operations.
Regards,
Claudio.
^ permalink raw reply
* RE: set LE advertise not working...
From: Mike Tsai @ 2010-09-10 21:35 UTC (permalink / raw)
To: Claudio Takahasi, Anderson Lizardo
Cc: Pavan Savoy, Anderson Briglia, linux-bluetooth@vger.kernel.org
In-Reply-To: <AANLkTinUCN-MSEffR5mshV7PiB3AW=d+3pA8hXK8-68L@mail.gmail.com>
-----Original Message-----
From: linux-bluetooth-owner@vger.kernel.org [mailto:linux-bluetooth-owner@vger.kernel.org] On Behalf Of Claudio Takahasi
Sent: Friday, September 10, 2010 2:03 PM
To: Anderson Lizardo
Cc: Pavan Savoy; Anderson Briglia; linux-bluetooth@vger.kernel.org
Subject: Re: set LE advertise not working...
On Fri, Sep 10, 2010 at 5:35 PM, Anderson Lizardo
<anderson.lizardo@openbossa.org> wrote:
> On Fri, Sep 10, 2010 at 3:01 PM, Pavan Savoy <pavan_savoy@sify.com> wrote:
>> No, I don't suppose my controller was in a advertising state.. even if
>> it was why the return 0x0c? (command disallowed ..)
>>
>> I wanted to know whether you have some HCI-VS commands which sort of
>> enable the LE (AMP/radio/controller) ?
>> Is it only then the leadv command works? Or does it just works right-away.
>> I have one of those all in 1 chips.. bt/fm-rx-tx/gps so I am wondering
>> should I do something to enable BLE and is it some sort of un-spoken
>> standard?
>
> Does LE scan work for this same hardware?
>
> Do you have some windows software to test this hardware ? if so, you
> can try putting one device in advertise mode there , then attempt
> lescan on the other (from linux)... If it works, most probably the
> hardware might require some initialization...
>
> At least some hardware requires firmware upload and vendor specific
> one-time initialization which (I think) is out of scope for hciconfig.
>
> Regards,
> --
> Anderson Lizardo
> OpenBossa Labs - INdT
> Manaus - Brazil
> --
> 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
>
> Hi All,
> I noticed that some LE hardwares don't allow to enable scanning or
> advertising when inquiry scan and/or page scan are enabled.
> Try to disable it using hciconfig or the D-Bus method before to start
> LE operations.
> Regards,
> Claudio.
Hello,
Now I remember, dual mode devices (BR/EDR/LE) are not allowed to work as peripheral (or slave) device. The default advertising mode is "connectable indirect advertising mode". When you try to enable the advertising, you are trying to make this dual mode device as a potential slave to other LE masters and that's why the controller rejects the command.
Scan should work though.
I don't think you can ever connect 2 dual mode devices together, you need a single mode device (LE only) as the slave,
Cheers,
Mike
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
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox