* Re: 4.76 possible regression: bluetoothd segfaults when launching bluetooth programs
From: Johan Hedberg @ 2010-10-25 20:40 UTC (permalink / raw)
To: Ilya Basin; +Cc: linux-bluetooth
In-Reply-To: <453819375.20101024163802@gmail.com>
Hi Ilya,
On Sun, Oct 24, 2010, Ilya Basin wrote:
> Program received signal SIGSEGV, Segmentation fault.
> 0xb7d3e653 in strlen () from /lib/libc.so.6
> (gdb) bt
> #0 0xb7d3e653 in strlen () from /lib/libc.so.6
> #1 0xb7e5eb10 in ?? () from /usr/lib/libdbus-1.so.3
> #2 0xb7e4a34b in ?? () from /usr/lib/libdbus-1.so.3
> #3 0xb7e4e7a9 in dbus_message_iter_append_basic () from /usr/lib/libdbus-1.so.3
> #4 0xb7fef03d in append_array_variant ()
> #5 0xb7fef799 in emit_array_property_changed ()
> #6 0xb7fe4de4 in adapter_service_ins_rem ()
> #7 0xb7fd7fb1 in sdp_record_add ()
> #8 0xb7fd79de in service_register_req ()
> #9 0xb7fd5dfc in handle_request ()
> #10 0xb7fd496e in io_session_event ()
> #11 0xb7ef7a2b in ?? () from /usr/lib/libglib-2.0.so.0
> #12 0xb7eb0b72 in g_main_context_dispatch () from /usr/lib/libglib-2.0.so.0
> #13 0xb7eb1350 in ?? () from /usr/lib/libglib-2.0.so.0
> #14 0xb7eb1a1b in g_main_loop_run () from /usr/lib/libglib-2.0.so.0
> #15 0xb7fd1bbd in main ()
> (gdb)
Unfortunately this doesn't give too much info since you don't seem to
have all debug symbols enabled. Could you try to reproduce this with
latest bluez git. You don't need to install anything but just compile
(./boostrap-configure && make) and run (src/bluetoothd -nd) from the
source tree directly. Then, it'd also be nice if you could use git
bisect to determine the exact commit between 4.69 and 4.76 that
introduced this regression.
Thanks.
Johan
^ permalink raw reply
* Re: [PATCH 2/6] Bluetooth: Add LE connect support
From: Anderson Lizardo @ 2010-10-25 20:33 UTC (permalink / raw)
To: Ville Tervo; +Cc: linux-bluetooth
In-Reply-To: <1288009280-5149-3-git-send-email-ville.tervo@nokia.com>
Hi,
On Mon, Oct 25, 2010 at 8:21 AM, Ville Tervo <ville.tervo@nokia.com> wrote:
> diff --git a/net/bluetooth/hci_conn.c b/net/bluetooth/hci_conn.c
> index 0b1e460..0944c0c 100644
> --- a/net/bluetooth/hci_conn.c
> +++ b/net/bluetooth/hci_conn.c
> @@ -45,6 +45,32 @@
> #include <net/bluetooth/bluetooth.h>
> #include <net/bluetooth/hci_core.h>
>
> +void hci_le_connect(struct hci_conn *conn)
This function could be made static, right? (just noticed this now)
> +{
> + struct hci_dev *hdev = conn->hdev;
> + struct hci_cp_le_create_conn cp;
> +
> + conn->state = BT_CONNECT;
> + conn->out = 1;
> +
> + memset(&cp, 0, sizeof(cp));
> + cp.scan_interval = cpu_to_le16(0x0004);
> + cp.scan_window = cpu_to_le16(0x0004);
> + bacpy(&cp.peer_addr, &conn->dst);
> + cp.conn_interval_min = cpu_to_le16(0x0008);
> + cp.conn_interval_max = cpu_to_le16(0x0100);
> + cp.supervision_timeout = cpu_to_le16(0x0064);
> + cp.min_ce_len = cpu_to_le16(0x0001);
> + cp.max_ce_len = cpu_to_le16(0x0001);
> +
> + hci_send_cmd(hdev, HCI_OP_LE_CREATE_CONN, sizeof(cp), &cp);
> +}
Regards,
--
Anderson Lizardo
OpenBossa Labs - INdT
Manaus - Brazil
^ permalink raw reply
* RE: [RFC] LE connections and advertising management
From: Brian Redding @ 2010-10-25 19:27 UTC (permalink / raw)
To: 'Claudio Takahasi'; +Cc: 'BlueZ development'
In-Reply-To: <AANLkTinnjXuAOBTY8VZz756VdrDFv0-OVKPNkwWbxi9-@mail.gmail.com>
> GAttrib will not be exposed to the UI. UI needs to access BlueZ GATT
> clients services using D-Bus.
> GATT clients in general will have two pieces:
> 1- UI: Qt, GTK, python, ...
> 2- "module" in the BlueZ for profile specific tasks and D-Bus service
> interface.
> You can find the current attribute API in the file: doc/attribute-api.txt
> Claudio
Hi Claudio,
Are there still interfaces that need to be added to attribute-api.txt to handle client and server characteristic configuration as well as presentation and aggregate formats? I see those as TODO items but wondered if the APIs for them have been defined yet.
One thing to note on the server API is that a GATT-based profile could specify behavior on a characteristic value that when the characteristic value is read to perform some action in a similar way as a hardware register. It appears that the notes I'm reading in the code thus far only consider changes (or writes) to characteristic values for the watch code.
Also does the current API handle included services?
The Bluetooth SIG is beginning to look at 3rd party application developer API's for both client and servers for various platforms so understanding what is currently defined in BlueZ and what still needs to be added would be useful.
Thanks,
Brian
---
Brian A. Redding
Employee of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum
^ permalink raw reply
* Re: [RFC] LE connections and advertising management
From: Claudio Takahasi @ 2010-10-25 18:54 UTC (permalink / raw)
To: Mike Tsai; +Cc: BlueZ development
In-Reply-To: <35B17FE5076C7040809188FBE7913F983F8440581D@SC1EXMB-MBCL.global.atheros.com>
On Mon, Oct 25, 2010 at 3:16 PM, Mike Tsai <Mike.Tsai@atheros.com> wrote:
>
>
> -----Original Message-----
> From: Claudio Takahasi [mailto:claudio.takahasi@openbossa.org]
> Sent: Monday, October 25, 2010 10:56 AM
> To: Mike Tsai
> Cc: BlueZ development
> Subject: Re: [RFC] LE connections and advertising management
>
> On Mon, Oct 25, 2010 at 2:11 PM, Mike Tsai <Mike.Tsai@atheros.com> wrote:
>>
>> -----Original Message-----
>> From: linux-bluetooth-owner@vger.kernel.org [mailto:linux-bluetooth-owner@vger.kernel.org] On Behalf Of Claudio Takahasi
>> Sent: Monday, October 25, 2010 5:53 AM
>> To: BlueZ development
>> Subject: [RFC] LE connections and advertising management
>>
>> Hi all,
>>
>> Interleave BR/EDR/LE discovery is implemented, the next step in the
>> user space is how to manage advertising and LE connections.
>>
>> Some aspects:
>> 1. Only one LE connection is allowed(per peer), meaning only one
>> GAttrib instance will be allowed otherwise it will not be possible to
>> serialize commands/events
>> 2. The remote/Peripheral can support more than one GATT primary service
>> 3. We are planning to use "direct" connections only, meaning that we
>> will not use whitelist and the application interested must inform the
>> remote address/object to connect to.
>> 4. Kernel manages the connection establishment, currently there isn't
>> a way to change the connection parameters. BMI or ioctls will be
>> required to change the default parameters and also to trigger SMP
>> negotiation.
>>
>>
>> Some ideas:
>> 1. implement a characteristic driver: basically to provide an
>> abstraction to GATT clients. ex: Proximity, Health, ...
>> 2. We don't need to implement Proximity and other GATT clients as a
>> plugin at the moment, it can be enabled automatically by
>> --enable-attrib
>> 3. GATT clients could register a watcher/filter for advertising events
>> 4. GATT clients doesn't need to know ATT, in theory it can handle
>> characteristics only
>> 5. GATT clients needs to control/request LE connections based on the
>> advertisement received
>>
>> An initial draft implementing part of this idea is here:
>> git://git.infradead.org/users/cktakahasi/bluez.git devel
>>
>> Comments?
>>
>> Regards,
>> Claudio
>>>>MT comments,
>>
>> 1. Only one LE connection is allowed(per peer), meaning only one
>> GAttrib instance will be allowed otherwise it will not be possible to
>> serialize commands/events
>>
>>>> You mean the master (or client) can only connect to 1 slave (or server) or a slave can only connect to 1 master?
> [Claudio Takahasi]
> The master can be connected to more than one slave. But here, I wanna
> emphasize that only one instance of GAtttrib shall be created to
> represent the physical channel between two LE capable devices. GAttrib
> is the abstraction that we created in BlueZ to represent the GATT/ATT
> connection, it is necessary to address multiple applications/profiles
> and queue commands/events.
> [Mike Tsai]
> I see. In order to handle multiple profiles (as multiple applications running on top of the GAttrib) in a single physical link, you will need something like "application handle" to dispatch the response/identification to the appropriate application correctly.
> May you refer me to the API document that you are opening to the GATT client(s) from this GAttrib?
[Claudio Takahasi]
Hi Mike,
At the moment it is not clear to me if an "application handle" will be
needed, maybe we can also hide it from the higher layers. All requests
are serialized and for each request there is a response, the
exceptions are write without response and notification. Each primary
service representation will have an object path, meaning that maybe it
is possible forward the response to the right source based on the last
request and handle information.
GAttrib will not be exposed to the UI. UI needs to access BlueZ GATT
clients services using D-Bus.
GATT clients in general will have two pieces:
1- UI: Qt, GTK, python, ...
2- "module" in the BlueZ for profile specific tasks and D-Bus service
interface.
You can find the current attribute API in the file: doc/attribute-api.txt
Claudio
>
>>
>> 4. GATT clients doesn't need to know ATT, in theory it can handle
>> characteristics only
>>
>>>> You mean both characteristic value and characteristic descriptors of characteristic?
> [Claudio Takahasi]
> Both. For the GATT client role, an interface can be created exporting
> profile specific details.
> Sometimes GATT clients will also need to access some low level information.
> [Mike Tsai]
> Yes, I will really appreciate if you may show me the planned API for this GAttrib,
>
>
> Regards,
> Claudio
>>
>> Regards,
>>
>> 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
>>
>
--
--
Claudio Takahasi
Instituto Nokia de Tecnologia
Recife - Pernambuco - Brasil
+55 81 30879999
^ permalink raw reply
* Re: [PATCH 2/2] Fix coding style and comment
From: Johan Hedberg @ 2010-10-25 18:50 UTC (permalink / raw)
To: Elvis Pfützenreuter; +Cc: linux-bluetooth
In-Reply-To: <1288024124-24492-2-git-send-email-epx@signove.com>
Hi Elvis,
On Mon, Oct 25, 2010, Elvis Pfützenreuter wrote:
> ---
> health/hdp.c | 2 +-
> health/mcap_sync.c | 2 +-
> 2 files changed, 2 insertions(+), 2 deletions(-)
This one has also been pushed upstream. Thanks.
Johan
^ permalink raw reply
* Re: [PATCH 1/2] Fix fd comparison
From: Johan Hedberg @ 2010-10-25 18:49 UTC (permalink / raw)
To: Elvis Pfützenreuter; +Cc: linux-bluetooth
In-Reply-To: <1288024124-24492-1-git-send-email-epx@signove.com>
Hi Elvis,
On Mon, Oct 25, 2010, Elvis Pfützenreuter wrote:
> ---
> health/hdp.c | 4 ++--
> 1 files changed, 2 insertions(+), 2 deletions(-)
Pushed upstream. Thanks.
Johan
^ permalink raw reply
* RE: [RFC] LE connections and advertising management
From: Mike Tsai @ 2010-10-25 18:16 UTC (permalink / raw)
To: Claudio Takahasi; +Cc: BlueZ development
In-Reply-To: <AANLkTinS-NhD3FhqcnpNRRdHKxn4mm+2zTmysrSeSjW8@mail.gmail.com>
-----Original Message-----
From: Claudio Takahasi [mailto:claudio.takahasi@openbossa.org]
Sent: Monday, October 25, 2010 10:56 AM
To: Mike Tsai
Cc: BlueZ development
Subject: Re: [RFC] LE connections and advertising management
On Mon, Oct 25, 2010 at 2:11 PM, Mike Tsai <Mike.Tsai@atheros.com> wrote:
>
> -----Original Message-----
> From: linux-bluetooth-owner@vger.kernel.org [mailto:linux-bluetooth-owner@vger.kernel.org] On Behalf Of Claudio Takahasi
> Sent: Monday, October 25, 2010 5:53 AM
> To: BlueZ development
> Subject: [RFC] LE connections and advertising management
>
> Hi all,
>
> Interleave BR/EDR/LE discovery is implemented, the next step in the
> user space is how to manage advertising and LE connections.
>
> Some aspects:
> 1. Only one LE connection is allowed(per peer), meaning only one
> GAttrib instance will be allowed otherwise it will not be possible to
> serialize commands/events
> 2. The remote/Peripheral can support more than one GATT primary service
> 3. We are planning to use "direct" connections only, meaning that we
> will not use whitelist and the application interested must inform the
> remote address/object to connect to.
> 4. Kernel manages the connection establishment, currently there isn't
> a way to change the connection parameters. BMI or ioctls will be
> required to change the default parameters and also to trigger SMP
> negotiation.
>
>
> Some ideas:
> 1. implement a characteristic driver: basically to provide an
> abstraction to GATT clients. ex: Proximity, Health, ...
> 2. We don't need to implement Proximity and other GATT clients as a
> plugin at the moment, it can be enabled automatically by
> --enable-attrib
> 3. GATT clients could register a watcher/filter for advertising events
> 4. GATT clients doesn't need to know ATT, in theory it can handle
> characteristics only
> 5. GATT clients needs to control/request LE connections based on the
> advertisement received
>
> An initial draft implementing part of this idea is here:
> git://git.infradead.org/users/cktakahasi/bluez.git devel
>
> Comments?
>
> Regards,
> Claudio
>>>MT comments,
>
> 1. Only one LE connection is allowed(per peer), meaning only one
> GAttrib instance will be allowed otherwise it will not be possible to
> serialize commands/events
>
>>> You mean the master (or client) can only connect to 1 slave (or server) or a slave can only connect to 1 master?
[Claudio Takahasi]
The master can be connected to more than one slave. But here, I wanna
emphasize that only one instance of GAtttrib shall be created to
represent the physical channel between two LE capable devices. GAttrib
is the abstraction that we created in BlueZ to represent the GATT/ATT
connection, it is necessary to address multiple applications/profiles
and queue commands/events.
[Mike Tsai]
I see. In order to handle multiple profiles (as multiple applications running on top of the GAttrib) in a single physical link, you will need something like "application handle" to dispatch the response/identification to the appropriate application correctly.
May you refer me to the API document that you are opening to the GATT client(s) from this GAttrib?
>
> 4. GATT clients doesn't need to know ATT, in theory it can handle
> characteristics only
>
>>> You mean both characteristic value and characteristic descriptors of characteristic?
[Claudio Takahasi]
Both. For the GATT client role, an interface can be created exporting
profile specific details.
Sometimes GATT clients will also need to access some low level information.
[Mike Tsai]
Yes, I will really appreciate if you may show me the planned API for this GAttrib,
Regards,
Claudio
>
> Regards,
>
> 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
* Re: [RFC] LE connections and advertising management
From: Claudio Takahasi @ 2010-10-25 17:55 UTC (permalink / raw)
To: Mike Tsai; +Cc: BlueZ development
In-Reply-To: <35B17FE5076C7040809188FBE7913F983F844057B9@SC1EXMB-MBCL.global.atheros.com>
On Mon, Oct 25, 2010 at 2:11 PM, Mike Tsai <Mike.Tsai@atheros.com> wrote:
>
> -----Original Message-----
> From: linux-bluetooth-owner@vger.kernel.org [mailto:linux-bluetooth-owner@vger.kernel.org] On Behalf Of Claudio Takahasi
> Sent: Monday, October 25, 2010 5:53 AM
> To: BlueZ development
> Subject: [RFC] LE connections and advertising management
>
> Hi all,
>
> Interleave BR/EDR/LE discovery is implemented, the next step in the
> user space is how to manage advertising and LE connections.
>
> Some aspects:
> 1. Only one LE connection is allowed(per peer), meaning only one
> GAttrib instance will be allowed otherwise it will not be possible to
> serialize commands/events
> 2. The remote/Peripheral can support more than one GATT primary service
> 3. We are planning to use "direct" connections only, meaning that we
> will not use whitelist and the application interested must inform the
> remote address/object to connect to.
> 4. Kernel manages the connection establishment, currently there isn't
> a way to change the connection parameters. BMI or ioctls will be
> required to change the default parameters and also to trigger SMP
> negotiation.
>
>
> Some ideas:
> 1. implement a characteristic driver: basically to provide an
> abstraction to GATT clients. ex: Proximity, Health, ...
> 2. We don't need to implement Proximity and other GATT clients as a
> plugin at the moment, it can be enabled automatically by
> --enable-attrib
> 3. GATT clients could register a watcher/filter for advertising events
> 4. GATT clients doesn't need to know ATT, in theory it can handle
> characteristics only
> 5. GATT clients needs to control/request LE connections based on the
> advertisement received
>
> An initial draft implementing part of this idea is here:
> git://git.infradead.org/users/cktakahasi/bluez.git devel
>
> Comments?
>
> Regards,
> Claudio
>>>MT comments,
>
> 1. Only one LE connection is allowed(per peer), meaning only one
> GAttrib instance will be allowed otherwise it will not be possible to
> serialize commands/events
>
>>> You mean the master (or client) can only connect to 1 slave (or server) or a slave can only connect to 1 master?
[Claudio Takahasi]
The master can be connected to more than one slave. But here, I wanna
emphasize that only one instance of GAtttrib shall be created to
represent the physical channel between two LE capable devices. GAttrib
is the abstraction that we created in BlueZ to represent the GATT/ATT
connection, it is necessary to address multiple applications/profiles
and queue commands/events.
>
> 4. GATT clients doesn't need to know ATT, in theory it can handle
> characteristics only
>
>>> You mean both characteristic value and characteristic descriptors of characteristic?
[Claudio Takahasi]
Both. For the GATT client role, an interface can be created exporting
profile specific details.
Sometimes GATT clients will also need to access some low level information.
Regards,
Claudio
>
> Regards,
>
> 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
* RE: [RFC] LE connections and advertising management
From: Mike Tsai @ 2010-10-25 17:11 UTC (permalink / raw)
To: Claudio Takahasi, BlueZ development
In-Reply-To: <AANLkTin8pUACCu4YYuhLpFB7DxCfsYhN3cOpYYaVcTQ6@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: Monday, October 25, 2010 5:53 AM
To: BlueZ development
Subject: [RFC] LE connections and advertising management
Hi all,
Interleave BR/EDR/LE discovery is implemented, the next step in the
user space is how to manage advertising and LE connections.
Some aspects:
1. Only one LE connection is allowed(per peer), meaning only one
GAttrib instance will be allowed otherwise it will not be possible to
serialize commands/events
2. The remote/Peripheral can support more than one GATT primary service
3. We are planning to use "direct" connections only, meaning that we
will not use whitelist and the application interested must inform the
remote address/object to connect to.
4. Kernel manages the connection establishment, currently there isn't
a way to change the connection parameters. BMI or ioctls will be
required to change the default parameters and also to trigger SMP
negotiation.
Some ideas:
1. implement a characteristic driver: basically to provide an
abstraction to GATT clients. ex: Proximity, Health, ...
2. We don't need to implement Proximity and other GATT clients as a
plugin at the moment, it can be enabled automatically by
--enable-attrib
3. GATT clients could register a watcher/filter for advertising events
4. GATT clients doesn't need to know ATT, in theory it can handle
characteristics only
5. GATT clients needs to control/request LE connections based on the
advertisement received
An initial draft implementing part of this idea is here:
git://git.infradead.org/users/cktakahasi/bluez.git devel
Comments?
Regards,
Claudio
>>MT comments,
1. Only one LE connection is allowed(per peer), meaning only one
GAttrib instance will be allowed otherwise it will not be possible to
serialize commands/events
>> You mean the master (or client) can only connect to 1 slave (or server) or a slave can only connect to 1 master?
4. GATT clients doesn't need to know ATT, in theory it can handle
characteristics only
>> You mean both characteristic value and characteristic descriptors of characteristic?
Regards,
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
* Re: [PATCH] Send a proper configuration when a source doesn't have a first reliable
From: Johan Hedberg @ 2010-10-25 16:29 UTC (permalink / raw)
To: Santiago Carot-Nemesio; +Cc: linux-bluetooth
In-Reply-To: <1288014239-10832-1-git-send-email-sancane@gmail.com>
Hi,
On Mon, Oct 25, 2010, Santiago Carot-Nemesio wrote:
> ---
> health/hdp.c | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/health/hdp.c b/health/hdp.c
> index fd3b1ca..10f4c5f 100644
> --- a/health/hdp.c
> +++ b/health/hdp.c
> @@ -1026,7 +1026,7 @@ static uint8_t hdp_mcap_mdl_conn_req_cb(struct mcap_mcl *mcl, uint8_t mdepid,
> case HDP_NO_PREFERENCE_DC:
> if (app->role == HDP_SINK)
> return MCAP_CONFIGURATION_REJECTED;
> - else if (app->chan_type_set)
> + else if (dev->fr && app->chan_type_set)
> *conf = app->chan_type;
> else
> *conf = HDP_RELIABLE_DC;
Pushed upstream. Thanks.
Johan
^ permalink raw reply
* [PATCH 2/2] Fix coding style and comment
From: Elvis Pfützenreuter @ 2010-10-25 16:28 UTC (permalink / raw)
To: linux-bluetooth; +Cc: epx
In-Reply-To: <1288024124-24492-1-git-send-email-epx@signove.com>
---
health/hdp.c | 2 +-
health/mcap_sync.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/health/hdp.c b/health/hdp.c
index eb27613..7332cd5 100644
--- a/health/hdp.c
+++ b/health/hdp.c
@@ -339,7 +339,7 @@ static DBusMessage *manager_create_application(DBusConnection *conn,
"Can't get sender name");
}
- if (!set_app_path(app)){
+ if (!set_app_path(app)) {
free_application(app);
return g_dbus_create_error(msg,
ERROR_INTERFACE ".HealthError",
diff --git a/health/mcap_sync.c b/health/mcap_sync.c
index 49661a7..57ba0fd 100644
--- a/health/mcap_sync.c
+++ b/health/mcap_sync.c
@@ -350,7 +350,7 @@ static gboolean initialize_caps(struct mcap_mcl *mcl)
clock_gettime(CLK, &t1);
read_btclock_retry(mcl, &btclock, &btaccuracy);
- /* Do clock read a number of times and measure latency */
+ /* Read clock a number of times and measure latency */
avg = 0;
i = 0;
retries = MAX_RETRIES;
--
1.7.0.4
^ permalink raw reply related
* [PATCH 1/2] Fix fd comparison
From: Elvis Pfützenreuter @ 2010-10-25 16:28 UTC (permalink / raw)
To: linux-bluetooth; +Cc: epx
---
health/hdp.c | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/health/hdp.c b/health/hdp.c
index fd3b1ca..eb27613 100644
--- a/health/hdp.c
+++ b/health/hdp.c
@@ -477,7 +477,7 @@ static void hdp_mdl_reconn_cb(struct mcap_mdl *mdl, GError *err, gpointer data)
}
fd = mcap_mdl_get_fd(dc_data->hdp_chann->mdl);
- if (fd <= 0)
+ if (fd < 0)
reply = g_dbus_create_error(dc_data->msg,
ERROR_INTERFACE ".HealthError",
"Cannot get file descriptor");
@@ -568,7 +568,7 @@ static DBusMessage *channel_acquire_continue(struct hdp_tmp_dc_data *data,
}
fd = mcap_mdl_get_fd(data->hdp_chann->mdl);
- if (fd > 0)
+ if (fd >= 0)
return g_dbus_create_reply(data->msg, DBUS_TYPE_UNIX_FD, &fd,
DBUS_TYPE_INVALID);
--
1.7.0.4
^ permalink raw reply related
* Re: [PATCH] Provide extra query for vCard single call
From: Johan Hedberg @ 2010-10-25 16:26 UTC (permalink / raw)
To: Rafal Michalski; +Cc: linux-bluetooth
In-Reply-To: <1287997498-2576-1-git-send-email-michalski.raf@gmail.com>
Hi Rafal,
On Mon, Oct 25, 2010, Rafal Michalski wrote:
> This patch makes that additional circumstance is recognized - after
> making a call with number that is out of phonebook it can be downloaded
> as a single vCard containing number with OTHER type.
> ---
> plugins/phonebook-tracker.c | 20 ++++++++++++++++++--
> 1 files changed, 18 insertions(+), 2 deletions(-)
Pushed upstream, but I had to fix your coding style first:
> - query = g_strdup_printf(CONTACTS_QUERY_FROM_URI, id, id, id, id, id,
> - id, id, id, id, id, id, id,
> + if (strncmp(id, CONTACT_ID_PREFIX, strlen(CONTACT_ID_PREFIX)) == 0) {
> + query = g_strdup_printf(CONTACTS_QUERY_FROM_URI, id, id, id, id,
> + id, id, id, id, id, id, id, id,
> id, id, id, id, id);
> + } else {
> + query = g_strdup_printf(CONTACTS_OTHER_QUERY_FROM_URI,
> + id, id, id);
> + }
>
> ret = query_tracker(query, PULL_QUERY_COL_AMOUNT, pull_contacts, data);
Single line branches shouldn't use curly braces.
Johan
^ permalink raw reply
* Re: [PATCH 1/1] Fix fd comparison and comment
From: Johan Hedberg @ 2010-10-25 16:22 UTC (permalink / raw)
To: Elvis Pfützenreuter; +Cc: linux-bluetooth
In-Reply-To: <1288013352-23258-1-git-send-email-epx@signove.com>
Hi Elvis,
On Mon, Oct 25, 2010, Elvis Pfützenreuter wrote:
> ---
> health/hdp.c | 6 +++---
> health/mcap_sync.c | 2 +-
> 2 files changed, 4 insertions(+), 4 deletions(-)
Please don't mix coding style cleanup and real bug fixes into a single
patch. I.e. could you please split these up. Thanks.
Johan
^ permalink raw reply
* [PATCH] Send a proper configuration when a source doesn't have a first reliable
From: Santiago Carot-Nemesio @ 2010-10-25 13:43 UTC (permalink / raw)
To: linux-bluetooth; +Cc: Santiago Carot-Nemesio
---
health/hdp.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/health/hdp.c b/health/hdp.c
index fd3b1ca..10f4c5f 100644
--- a/health/hdp.c
+++ b/health/hdp.c
@@ -1026,7 +1026,7 @@ static uint8_t hdp_mcap_mdl_conn_req_cb(struct mcap_mcl *mcl, uint8_t mdepid,
case HDP_NO_PREFERENCE_DC:
if (app->role == HDP_SINK)
return MCAP_CONFIGURATION_REJECTED;
- else if (app->chan_type_set)
+ else if (dev->fr && app->chan_type_set)
*conf = app->chan_type;
else
*conf = HDP_RELIABLE_DC;
--
1.7.3.1
^ permalink raw reply related
* Re: [RFC] LE connections and advertising management
From: Anderson Lizardo @ 2010-10-25 13:34 UTC (permalink / raw)
To: Claudio Takahasi; +Cc: BlueZ development
In-Reply-To: <AANLkTin8pUACCu4YYuhLpFB7DxCfsYhN3cOpYYaVcTQ6@mail.gmail.com>
On Mon, Oct 25, 2010 at 8:53 AM, Claudio Takahasi
<claudio.takahasi@openbossa.org> wrote:
> 4. Kernel manages the connection establishment, currently there isn't
> a way to change the connection parameters. BMI or ioctls will be
> required to change the default parameters and also to trigger SMP
> negotiation.
Another idea would be to use setsockopt(), like it's currently being
used for HCI filters (see lib/hci.c). E.g.:
hci_filter_clear(&nf);
hci_filter_set_ptype(HCI_EVENT_PKT, &nf);
hci_filter_set_event(EVT_LE_META_EVENT, &nf);
setsockopt(dd, SOL_HCI, HCI_FILTER, &nf, sizeof(nf);
Not sure if the SMP negotiation happens too soon to use it though.
Regards,
--
Anderson Lizardo
OpenBossa Labs - INdT
Manaus - Brazil
^ permalink raw reply
* [PATCH 1/1] Fix fd comparison and comment
From: Elvis Pfützenreuter @ 2010-10-25 13:29 UTC (permalink / raw)
To: linux-bluetooth; +Cc: epx
---
health/hdp.c | 6 +++---
health/mcap_sync.c | 2 +-
2 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/health/hdp.c b/health/hdp.c
index fd3b1ca..7332cd5 100644
--- a/health/hdp.c
+++ b/health/hdp.c
@@ -339,7 +339,7 @@ static DBusMessage *manager_create_application(DBusConnection *conn,
"Can't get sender name");
}
- if (!set_app_path(app)){
+ if (!set_app_path(app)) {
free_application(app);
return g_dbus_create_error(msg,
ERROR_INTERFACE ".HealthError",
@@ -477,7 +477,7 @@ static void hdp_mdl_reconn_cb(struct mcap_mdl *mdl, GError *err, gpointer data)
}
fd = mcap_mdl_get_fd(dc_data->hdp_chann->mdl);
- if (fd <= 0)
+ if (fd < 0)
reply = g_dbus_create_error(dc_data->msg,
ERROR_INTERFACE ".HealthError",
"Cannot get file descriptor");
@@ -568,7 +568,7 @@ static DBusMessage *channel_acquire_continue(struct hdp_tmp_dc_data *data,
}
fd = mcap_mdl_get_fd(data->hdp_chann->mdl);
- if (fd > 0)
+ if (fd >= 0)
return g_dbus_create_reply(data->msg, DBUS_TYPE_UNIX_FD, &fd,
DBUS_TYPE_INVALID);
diff --git a/health/mcap_sync.c b/health/mcap_sync.c
index 49661a7..57ba0fd 100644
--- a/health/mcap_sync.c
+++ b/health/mcap_sync.c
@@ -350,7 +350,7 @@ static gboolean initialize_caps(struct mcap_mcl *mcl)
clock_gettime(CLK, &t1);
read_btclock_retry(mcl, &btclock, &btaccuracy);
- /* Do clock read a number of times and measure latency */
+ /* Read clock a number of times and measure latency */
avg = 0;
i = 0;
retries = MAX_RETRIES;
--
1.7.0.4
^ permalink raw reply related
* Re: [PATCH 3/6] Bluetooth: Implement the first SMP commands
From: Gustavo F. Padovan @ 2010-10-25 13:03 UTC (permalink / raw)
To: Anderson Briglia; +Cc: linux-bluetooth, Vinicius Costa Gomes
In-Reply-To: <1287791820-22693-4-git-send-email-anderson.briglia@openbossa.org>
Hi Vinicius,
* Anderson Briglia <anderson.briglia@openbossa.org> [2010-10-22 19:56:57 -0400]:
> From: Vinicius Costa Gomes <vinicius.gomes@openbossa.org>
>
> These simple commands will allow the SMP procedure to be started
> and terminated with a not supported error. This is the first step
> toward something useful.
>
> Signed-off-by: Vinicius Costa Gomes <vinicius.gomes@openbossa.org>
> ---
> net/bluetooth/l2cap.c | 117 +++++++++++++++++++++++++++++++++++++++++++++++++
> 1 files changed, 117 insertions(+), 0 deletions(-)
>
> diff --git a/net/bluetooth/l2cap.c b/net/bluetooth/l2cap.c
> index 1ac44f4..ba87c84 100644
> --- a/net/bluetooth/l2cap.c
> +++ b/net/bluetooth/l2cap.c
> @@ -54,6 +54,7 @@
> #include <net/bluetooth/bluetooth.h>
> #include <net/bluetooth/hci_core.h>
> #include <net/bluetooth/l2cap.h>
> +#include <net/bluetooth/smp.h>
>
> #define VERSION "2.15"
>
> @@ -307,6 +308,85 @@ static void l2cap_chan_del(struct sock *sk, int err)
> }
> }
>
> +static struct sk_buff *smp_build_cmd(struct l2cap_conn *conn, u8 code,
> + u16 dlen, void *data)
Call this l2cap_smp_build_cmd()
> +{
> + struct sk_buff *skb;
> + struct l2cap_hdr *lh;
> + int len;
> +
> + len = L2CAP_HDR_SIZE + 1 + dlen;
> +
> + if (len > conn->mtu)
> + return NULL;
> +
> + skb = bt_skb_alloc(len, GFP_ATOMIC);
> + if (!skb)
> + return NULL;
> +
> + lh = (struct l2cap_hdr *) skb_put(skb, L2CAP_HDR_SIZE);
> + lh->len = cpu_to_le16(1 + dlen);
cpu_to_le16(len - L2CAP_HDR_SIZE) here
> + lh->cid = cpu_to_le16(L2CAP_CID_SMP);
> +
> + memcpy(skb_put(skb, 1), &code, 1);
> +
> + memcpy(skb_put(skb, dlen), data, dlen);
> +
> + return skb;
> +}
> +
> +static inline void smp_send_cmd(struct l2cap_conn *conn, u8 code, u16 len, void *data)
and this l2cap_smp_send_cmd.
> +{
> + struct sk_buff *skb = smp_build_cmd(conn, code, len, data);
> +
> + BT_DBG("code 0x%2.2x", code);
> +
> + if (!skb)
> + return;
> +
> + hci_send_acl(conn->hcon, skb, 0);
> +}
> +
> +static int smp_conn_security(struct l2cap_conn *conn, __u8 sec_level)
> +{
l2cap_smp_conn_security() here.
> + __u8 authreq;
> +
> + BT_DBG("conn %p hcon %p level 0x%2.2x", conn, conn->hcon, sec_level);
> +
> + switch (sec_level) {
> + case BT_SECURITY_MEDIUM:
> + /* Encrypted, no MITM protection */
> + authreq = 0x01;
> + break;
> +
> + case BT_SECURITY_HIGH:
> + /* Bonding, MITM protection */
> + authreq = 0x05;
> + break;
> +
> + case BT_SECURITY_LOW:
> + default:
> + return 1;
> + }
> +
> + if (conn->hcon->link_mode & HCI_LM_MASTER) {
> + struct smp_cmd_pairing cp;
> + cp.io_capability = 0x00;
> + cp.oob_flag = 0x00;
> + cp.max_key_size = 16;
> + cp.init_key_dist = 0x00;
> + cp.resp_key_dist = 0x00;
> + cp.auth_req = authreq;
> + smp_send_cmd(conn, SMP_CMD_PAIRING_REQ, sizeof(cp), &cp);
> + } else {
> + struct smp_cmd_security_req cp;
> + cp.auth_req = authreq;
> + smp_send_cmd(conn, SMP_CMD_SECURITY_REQ, sizeof(cp), &cp);
> + }
> +
> + return 0;
> +}
> +
> /* Service level security */
> static inline int l2cap_check_security(struct sock *sk)
> {
> @@ -4562,6 +4642,43 @@ done:
> return 0;
> }
>
> +static inline void smp_sig_channel(struct l2cap_conn *conn, struct sk_buff *skb)
l2cap_smp_sig_channel()
--
Gustavo F. Padovan
ProFUSION embedded systems - http://profusion.mobi
^ permalink raw reply
* [RFC] LE connections and advertising management
From: Claudio Takahasi @ 2010-10-25 12:53 UTC (permalink / raw)
To: BlueZ development
Hi all,
Interleave BR/EDR/LE discovery is implemented, the next step in the
user space is how to manage advertising and LE connections.
Some aspects:
1. Only one LE connection is allowed(per peer), meaning only one
GAttrib instance will be allowed otherwise it will not be possible to
serialize commands/events
2. The remote/Peripheral can support more than one GATT primary service
3. We are planning to use "direct" connections only, meaning that we
will not use whitelist and the application interested must inform the
remote address/object to connect to.
4. Kernel manages the connection establishment, currently there isn't
a way to change the connection parameters. BMI or ioctls will be
required to change the default parameters and also to trigger SMP
negotiation.
Some ideas:
1. implement a characteristic driver: basically to provide an
abstraction to GATT clients. ex: Proximity, Health, ...
2. We don't need to implement Proximity and other GATT clients as a
plugin at the moment, it can be enabled automatically by
--enable-attrib
3. GATT clients could register a watcher/filter for advertising events
4. GATT clients doesn't need to know ATT, in theory it can handle
characteristics only
5. GATT clients needs to control/request LE connections based on the
advertisement received
An initial draft implementing part of this idea is here:
git://git.infradead.org/users/cktakahasi/bluez.git devel
Comments?
Regards,
Claudio
^ permalink raw reply
* Re: [PATCH] bluetooth: Fix NULL pointer dereference issue
From: Yuri Ershov @ 2010-10-25 12:23 UTC (permalink / raw)
To: ext Gustavo F. Padovan
Cc: marcel, davem, jprvita, linux-bluetooth, ville.tervo,
andrei.emeltchenko
In-Reply-To: <20101022135859.GA15476@vigoh>
[-- Attachment #1: Type: text/plain, Size: 1732 bytes --]
Hello Gustavo,
The problem appears in case of multiple connect-transfer-disconnect
sequence (e.g. by using l2test). The conditions are the following:
There are 2 BT devices. The first one listens and receives (l2test -r),
the second one makes "connect-disconnect-connect..." sequence (l2test -c
-b 1000 -i hci0 -P 10 <addr>). After some time this will cause the race
between functions bt_accept_dequeue and l2cap_chan_del. The fail sequence:
struct sock *bt_accept_dequeue(struct sock *parent, struct socket *newsock)
{
...
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);
In this time the function l2cap_chan_del sets the socket state to
BT_CLOSED, unlinks and kills the socket.
/* FIXME: Is this check still needed */
if (sk->sk_state == BT_CLOSED) {
release_sock(sk);
bt_accept_unlink(sk);
continue;
}
...
release_sock(sk);
}
return NULL;
}
Regards,
Yuri
ext Gustavo F. Padovan wrote:
> Hi Yuri,
>
> * Yuri Ershov <ext-yuri.ershov@nokia.com> [2010-10-21 20:08:58 +0400]:
>
>
>> This patch fixes NULL pointer dereference at running test with
>> connect-transfer-disconnect in loop. Sometimes sk_state is
>> BT_CLOSED and sk_refcnt equal to 0, so there is oops in
>> bt_accept_unlink. In normal case removed block is not used.
>>
>
> Question here is: Why sk_refcnt is 0 at that point of the code? The
> socket should be destroyed if it ref is 0, but it wasn't, so something
> in another point of the code went is wrong. "Sometimes" is not a good
> description of the problem, you have to show why that happened.
>
>
[-- Attachment #2: Type: text/html, Size: 2746 bytes --]
^ permalink raw reply
* [PATCH 6/6] Bluetooth: Do not send disconn comand over LE links
From: Ville Tervo @ 2010-10-25 12:21 UTC (permalink / raw)
To: linux-bluetooth; +Cc: Ville Tervo
In-Reply-To: <1288009280-5149-1-git-send-email-ville.tervo@nokia.com>
l2cap over LE links can be disconnected without sending
disconnect command first.
Signed-off-by: Ville Tervo <ville.tervo@nokia.com>
---
net/bluetooth/l2cap.c | 15 ++++++++++-----
1 files changed, 10 insertions(+), 5 deletions(-)
diff --git a/net/bluetooth/l2cap.c b/net/bluetooth/l2cap.c
index 3913ba5..2da613b 100644
--- a/net/bluetooth/l2cap.c
+++ b/net/bluetooth/l2cap.c
@@ -873,6 +873,8 @@ static void l2cap_sock_kill(struct sock *sk)
static void __l2cap_sock_close(struct sock *sk, int reason)
{
+ struct l2cap_conn *conn;
+
BT_DBG("sk %p state %d socket %p", sk, sk->sk_state, sk->sk_socket);
switch (sk->sk_state) {
@@ -882,8 +884,10 @@ static void __l2cap_sock_close(struct sock *sk, int reason)
case BT_CONNECTED:
case BT_CONFIG:
- if (sk->sk_type == SOCK_SEQPACKET ||
- sk->sk_type == SOCK_STREAM) {
+ conn = l2cap_pi(sk)->conn;
+ if ((sk->sk_type == SOCK_SEQPACKET ||
+ sk->sk_type == SOCK_STREAM) &&
+ conn->hcon->type != LE_LINK) {
struct l2cap_conn *conn = l2cap_pi(sk)->conn;
l2cap_sock_set_timer(sk, sk->sk_sndtimeo);
@@ -893,9 +897,10 @@ static void __l2cap_sock_close(struct sock *sk, int reason)
break;
case BT_CONNECT2:
- if (sk->sk_type == SOCK_SEQPACKET ||
- sk->sk_type == SOCK_STREAM) {
- struct l2cap_conn *conn = l2cap_pi(sk)->conn;
+ conn = l2cap_pi(sk)->conn;
+ if ((sk->sk_type == SOCK_SEQPACKET ||
+ sk->sk_type == SOCK_STREAM) &&
+ conn->hcon->type != LE_LINK) {
struct l2cap_conn_rsp rsp;
__u16 result;
--
1.7.1
^ permalink raw reply related
* [PATCH 5/6] Bluetooth: Add server socket support for LE connection
From: Ville Tervo @ 2010-10-25 12:21 UTC (permalink / raw)
To: linux-bluetooth; +Cc: Ville Tervo
In-Reply-To: <1288009280-5149-1-git-send-email-ville.tervo@nokia.com>
Add support for LE server sockets.
Signed-off-by: Ville Tervo <ville.tervo@nokia.com>
---
include/net/bluetooth/l2cap.h | 1 +
net/bluetooth/hci_event.c | 10 +++-
net/bluetooth/l2cap.c | 101 +++++++++++++++++++++++++++++++++++++++--
3 files changed, 105 insertions(+), 7 deletions(-)
diff --git a/include/net/bluetooth/l2cap.h b/include/net/bluetooth/l2cap.h
index cc3a140..cba4423 100644
--- a/include/net/bluetooth/l2cap.h
+++ b/include/net/bluetooth/l2cap.h
@@ -38,6 +38,7 @@
#define L2CAP_DEFAULT_MAX_PDU_SIZE 1009 /* Sized for 3-DH5 packet */
#define L2CAP_DEFAULT_ACK_TO 200
#define L2CAP_LOCAL_BUSY_TRIES 12
+#define L2CAP_LE_DEFAULT_MTU 23
#define L2CAP_CONN_TIMEOUT (40000) /* 40 seconds */
#define L2CAP_INFO_TIMEOUT (4000) /* 4 seconds */
diff --git a/net/bluetooth/hci_event.c b/net/bluetooth/hci_event.c
index da23502..464d0cc 100644
--- a/net/bluetooth/hci_event.c
+++ b/net/bluetooth/hci_event.c
@@ -1914,8 +1914,14 @@ static inline void hci_le_conn_complete_evt(struct hci_dev *hdev, struct sk_buff
hci_dev_lock(hdev);
conn = hci_conn_hash_lookup_ba(hdev, LE_LINK, &ev->bdaddr);
- if (!conn)
- goto unlock;
+ if (!conn) {
+ conn = hci_conn_add(hdev, LE_LINK, &ev->bdaddr);
+ if (!conn) {
+ BT_ERR("No memory for new connection");
+ hci_dev_unlock(hdev);
+ return;
+ }
+ }
if (ev->status) {
hci_proto_connect_cfm(conn, ev->status);
diff --git a/net/bluetooth/l2cap.c b/net/bluetooth/l2cap.c
index 18643af..3913ba5 100644
--- a/net/bluetooth/l2cap.c
+++ b/net/bluetooth/l2cap.c
@@ -82,6 +82,8 @@ static struct sk_buff *l2cap_build_cmd(struct l2cap_conn *conn,
static int l2cap_ertm_data_rcv(struct sock *sk, struct sk_buff *skb);
+static void l2cap_le_conn_ready(struct l2cap_conn *conn);
+
/* ---- L2CAP timers ---- */
static void l2cap_sock_timeout(unsigned long arg)
{
@@ -228,8 +230,16 @@ static void __l2cap_chan_add(struct l2cap_conn *conn, struct sock *sk, struct so
l2cap_pi(sk)->conn = conn;
if (sk->sk_type == SOCK_SEQPACKET || sk->sk_type == SOCK_STREAM) {
- /* Alloc CID for connection-oriented socket */
- l2cap_pi(sk)->scid = l2cap_alloc_cid(l);
+ if (conn->hcon->type == LE_LINK) {
+ /* LE connection */
+ l2cap_pi(sk)->omtu = L2CAP_LE_DEFAULT_MTU;
+ l2cap_pi(sk)->scid = L2CAP_CID_LE_DATA;
+ l2cap_pi(sk)->dcid = L2CAP_CID_LE_DATA;
+ } else {
+ /* Alloc CID for connection-oriented socket */
+ l2cap_pi(sk)->scid = l2cap_alloc_cid(l);
+ l2cap_pi(sk)->omtu = L2CAP_DEFAULT_MTU;
+ }
} else if (sk->sk_type == SOCK_DGRAM) {
/* Connectionless socket */
l2cap_pi(sk)->scid = L2CAP_CID_CONN_LESS;
@@ -612,6 +622,9 @@ static void l2cap_conn_ready(struct l2cap_conn *conn)
BT_DBG("conn %p", conn);
+ if (!conn->hcon->out && conn->hcon->type == LE_LINK)
+ l2cap_le_conn_ready(conn);
+
read_lock(&l->lock);
for (sk = l->head; sk; sk = l2cap_pi(sk)->next_c) {
@@ -694,7 +707,8 @@ static struct l2cap_conn *l2cap_conn_add(struct hci_conn *hcon, u8 status)
spin_lock_init(&conn->lock);
rwlock_init(&conn->chan_list.lock);
- setup_timer(&conn->info_timer, l2cap_info_timeout,
+ if (hcon->type != LE_LINK)
+ setup_timer(&conn->info_timer, l2cap_info_timeout,
(unsigned long) conn);
conn->disc_reason = 0x13;
@@ -796,6 +810,37 @@ static void l2cap_sock_destruct(struct sock *sk)
skb_queue_purge(&sk->sk_write_queue);
}
+static inline struct sock *l2cap_get_sock_by_cid(int state, __le16 cid, bdaddr_t *src)
+{
+ struct sock *s;
+ struct sock *sk = NULL, *sk1 = NULL;
+ struct hlist_node *node;
+
+ read_lock(&l2cap_sk_list.lock);
+ sk_for_each(sk, node, &l2cap_sk_list.head) {
+ if (state && sk->sk_state != state)
+ continue;
+
+ if (l2cap_pi(sk)->dcid == cid) {
+ /* Exact match. */
+ if (!bacmp(&bt_sk(sk)->src, src))
+ break;
+
+ /* Closest match */
+ if (!bacmp(&bt_sk(sk)->src, BDADDR_ANY))
+ sk1 = sk;
+ }
+ }
+
+ s = node ? sk : sk1;
+
+ if (s)
+ bh_lock_sock(s);
+ read_unlock(&l2cap_sk_list.lock);
+
+ return s;
+}
+
static void l2cap_sock_cleanup_listen(struct sock *parent)
{
struct sock *sk;
@@ -1008,7 +1053,7 @@ static int l2cap_sock_bind(struct socket *sock, struct sockaddr *addr, int alen)
len = min_t(unsigned int, sizeof(la), alen);
memcpy(&la, addr, len);
- if (la.l2_cid)
+ if (la.l2_cid && la.l2_psm)
return -EINVAL;
lock_sock(sk);
@@ -1050,6 +1095,9 @@ static int l2cap_sock_bind(struct socket *sock, struct sockaddr *addr, int alen)
l2cap_pi(sk)->sec_level = BT_SECURITY_SDP;
}
+ if (la.l2_cid)
+ l2cap_pi(sk)->dcid = la.l2_cid;
+
write_unlock_bh(&l2cap_sk_list.lock);
done:
@@ -1267,7 +1315,7 @@ static int l2cap_sock_listen(struct socket *sock, int backlog)
goto done;
}
- if (!l2cap_pi(sk)->psm) {
+ if (!l2cap_pi(sk)->psm && !l2cap_pi(sk)->dcid) {
bdaddr_t *src = &bt_sk(sk)->src;
u16 psm;
@@ -1377,6 +1425,49 @@ static int l2cap_sock_getname(struct socket *sock, struct sockaddr *addr, int *l
return 0;
}
+static void l2cap_le_conn_ready(struct l2cap_conn *conn)
+{
+ struct l2cap_chan_list *list = &conn->chan_list;
+ struct sock *parent, *uninitialized_var(sk);
+
+ BT_DBG("");
+
+ /* Check if we have socket listening on cid */
+ parent = l2cap_get_sock_by_cid(BT_LISTEN, 0x04, conn->src);
+ if (!parent)
+ goto clean;
+
+ /* Check for backlog size */
+ if (sk_acceptq_is_full(parent)) {
+ BT_DBG("backlog full %d", parent->sk_ack_backlog);
+ goto clean;
+ }
+
+ sk = l2cap_sock_alloc(sock_net(parent), NULL, BTPROTO_L2CAP, GFP_ATOMIC);
+ if (!sk)
+ goto clean;
+
+ write_lock_bh(&list->lock);
+
+ hci_conn_hold(conn->hcon);
+
+ l2cap_sock_init(sk, parent);
+ bacpy(&bt_sk(sk)->src, conn->src);
+ bacpy(&bt_sk(sk)->dst, conn->dst);
+
+ __l2cap_chan_add(conn, sk, parent);
+
+ l2cap_sock_set_timer(sk, sk->sk_sndtimeo);
+
+ sk->sk_state = BT_CONNECTED;
+ parent->sk_data_ready(parent, 0);
+
+ write_unlock_bh(&list->lock);
+
+clean:
+ bh_unlock_sock(parent);
+}
+
static int __l2cap_wait_ack(struct sock *sk)
{
DECLARE_WAITQUEUE(wait, current);
--
1.7.1
^ permalink raw reply related
* [PATCH 4/6] Bluetooth: Add LE connection support to L2CAP
From: Ville Tervo @ 2010-10-25 12:21 UTC (permalink / raw)
To: linux-bluetooth; +Cc: Ville Tervo
In-Reply-To: <1288009280-5149-1-git-send-email-ville.tervo@nokia.com>
Add basic LE connection support to L2CAP. LE
connection can be created by specifying cid
in struct sockaddr_l2
Signed-off-by: Ville Tervo <ville.tervo@nokia.com>
---
include/net/bluetooth/l2cap.h | 3 +++
net/bluetooth/l2cap.c | 32 ++++++++++++++++++++++++--------
2 files changed, 27 insertions(+), 8 deletions(-)
diff --git a/include/net/bluetooth/l2cap.h b/include/net/bluetooth/l2cap.h
index c819c8b..cc3a140 100644
--- a/include/net/bluetooth/l2cap.h
+++ b/include/net/bluetooth/l2cap.h
@@ -160,6 +160,9 @@ struct l2cap_conn_rsp {
/* channel indentifier */
#define L2CAP_CID_SIGNALING 0x0001
#define L2CAP_CID_CONN_LESS 0x0002
+#define L2CAP_CID_LE_DATA 0x0004
+#define L2CAP_CID_LE_SIGNALING 0x0005
+#define L2CAP_CID_SMP 0x0006
#define L2CAP_CID_DYN_START 0x0040
#define L2CAP_CID_DYN_END 0xffff
diff --git a/net/bluetooth/l2cap.c b/net/bluetooth/l2cap.c
index 6f931cc..18643af 100644
--- a/net/bluetooth/l2cap.c
+++ b/net/bluetooth/l2cap.c
@@ -617,6 +617,12 @@ static void l2cap_conn_ready(struct l2cap_conn *conn)
for (sk = l->head; sk; sk = l2cap_pi(sk)->next_c) {
bh_lock_sock(sk);
+ if (conn->hcon->type == LE_LINK) {
+ l2cap_sock_clear_timer(sk);
+ sk->sk_state = BT_CONNECTED;
+ sk->sk_state_change(sk);
+ }
+
if (sk->sk_type != SOCK_SEQPACKET &&
sk->sk_type != SOCK_STREAM) {
l2cap_sock_clear_timer(sk);
@@ -675,7 +681,11 @@ static struct l2cap_conn *l2cap_conn_add(struct hci_conn *hcon, u8 status)
BT_DBG("hcon %p conn %p", hcon, conn);
- conn->mtu = hcon->hdev->acl_mtu;
+ if (hcon->hdev->le_mtu && hcon->type == LE_LINK)
+ conn->mtu = hcon->hdev->le_mtu;
+ else
+ conn->mtu = hcon->hdev->acl_mtu;
+
conn->src = &hcon->hdev->bdaddr;
conn->dst = &hcon->dst;
@@ -1102,8 +1112,13 @@ static int l2cap_do_connect(struct sock *sk)
}
}
- hcon = hci_connect(hdev, ACL_LINK, dst,
+ if (l2cap_pi(sk)->dcid == L2CAP_CID_LE_DATA)
+ hcon = hci_connect(hdev, LE_LINK, dst,
+ l2cap_pi(sk)->sec_level, auth_type);
+ else
+ hcon = hci_connect(hdev, ACL_LINK, dst,
l2cap_pi(sk)->sec_level, auth_type);
+
if (!hcon)
goto done;
@@ -1154,13 +1169,13 @@ static int l2cap_sock_connect(struct socket *sock, struct sockaddr *addr, int al
len = min_t(unsigned int, sizeof(la), alen);
memcpy(&la, addr, len);
- if (la.l2_cid)
+ if (la.l2_cid && la.l2_psm)
return -EINVAL;
lock_sock(sk);
if ((sk->sk_type == SOCK_SEQPACKET || sk->sk_type == SOCK_STREAM)
- && !la.l2_psm) {
+ && !(la.l2_psm || la.l2_cid)) {
err = -EINVAL;
goto done;
}
@@ -1202,14 +1217,15 @@ static int l2cap_sock_connect(struct socket *sock, struct sockaddr *addr, int al
/* PSM must be odd and lsb of upper byte must be 0 */
if ((__le16_to_cpu(la.l2_psm) & 0x0101) != 0x0001 &&
- sk->sk_type != SOCK_RAW) {
+ sk->sk_type != SOCK_RAW && !la.l2_cid) {
err = -EINVAL;
goto done;
}
- /* Set destination address and psm */
+ /* Set destination address and psm or cid */
bacpy(&bt_sk(sk)->dst, &la.l2_bdaddr);
l2cap_pi(sk)->psm = la.l2_psm;
+ l2cap_pi(sk)->dcid = la.l2_cid;
err = l2cap_do_connect(sk);
if (err)
@@ -4525,7 +4541,7 @@ static int l2cap_connect_cfm(struct hci_conn *hcon, u8 status)
BT_DBG("hcon %p bdaddr %s status %d", hcon, batostr(&hcon->dst), status);
- if (hcon->type != ACL_LINK)
+ if (!(hcon->type == ACL_LINK || hcon->type == LE_LINK))
return -EINVAL;
if (!status) {
@@ -4554,7 +4570,7 @@ static int l2cap_disconn_cfm(struct hci_conn *hcon, u8 reason)
{
BT_DBG("hcon %p reason %d", hcon, reason);
- if (hcon->type != ACL_LINK)
+ if (!(hcon->type == ACL_LINK || hcon->type == LE_LINK))
return -EINVAL;
l2cap_conn_del(hcon, bt_err(reason));
--
1.7.1
^ permalink raw reply related
* [PATCH 3/6] Bluetooth: Use LE buffers for LE traffic
From: Ville Tervo @ 2010-10-25 12:21 UTC (permalink / raw)
To: linux-bluetooth; +Cc: Ville Tervo
In-Reply-To: <1288009280-5149-1-git-send-email-ville.tervo@nokia.com>
BLuetooth chips may have separate buffers for
LE traffic. This patch add support to use LE
buffers provided by the chip.
Signed-off-by: Ville Tervo <ville.tervo@nokia.com>
---
include/net/bluetooth/hci.h | 1 +
include/net/bluetooth/hci_core.h | 5 +++
net/bluetooth/hci_conn.c | 5 +++
net/bluetooth/hci_core.c | 74 +++++++++++++++++++++++++++++++++++--
net/bluetooth/hci_event.c | 40 +++++++++++++++++++-
5 files changed, 119 insertions(+), 6 deletions(-)
diff --git a/include/net/bluetooth/hci.h b/include/net/bluetooth/hci.h
index 02055b9..2103731 100644
--- a/include/net/bluetooth/hci.h
+++ b/include/net/bluetooth/hci.h
@@ -189,6 +189,7 @@ enum {
#define LMP_EV4 0x01
#define LMP_EV5 0x02
+#define LMP_LE 0x40
#define LMP_SNIFF_SUBR 0x02
#define LMP_EDR_ESCO_2M 0x20
diff --git a/include/net/bluetooth/hci_core.h b/include/net/bluetooth/hci_core.h
index 2b7f94a..e2d857a 100644
--- a/include/net/bluetooth/hci_core.h
+++ b/include/net/bluetooth/hci_core.h
@@ -103,15 +103,19 @@ struct hci_dev {
atomic_t cmd_cnt;
unsigned int acl_cnt;
unsigned int sco_cnt;
+ unsigned int le_cnt;
unsigned int acl_mtu;
unsigned int sco_mtu;
+ unsigned int le_mtu;
unsigned int acl_pkts;
unsigned int sco_pkts;
+ unsigned int le_pkts;
unsigned long cmd_last_tx;
unsigned long acl_last_tx;
unsigned long sco_last_tx;
+ unsigned long le_last_tx;
struct workqueue_struct *workqueue;
@@ -473,6 +477,7 @@ void hci_conn_del_sysfs(struct hci_conn *conn);
#define lmp_sniffsubr_capable(dev) ((dev)->features[5] & LMP_SNIFF_SUBR)
#define lmp_esco_capable(dev) ((dev)->features[3] & LMP_ESCO)
#define lmp_ssp_capable(dev) ((dev)->features[6] & LMP_SIMPLE_PAIR)
+#define lmp_le_capable(dev) ((dev)->features[4] & LMP_LE)
/* ----- HCI protocols ----- */
struct hci_proto {
diff --git a/net/bluetooth/hci_conn.c b/net/bluetooth/hci_conn.c
index 0944c0c..ddc2e5e 100644
--- a/net/bluetooth/hci_conn.c
+++ b/net/bluetooth/hci_conn.c
@@ -324,6 +324,11 @@ int hci_conn_del(struct hci_conn *conn)
/* Unacked frames */
hdev->acl_cnt += conn->sent;
+ } else if (conn->type == LE_LINK) {
+ if (hdev->le_pkts)
+ hdev->le_cnt += conn->sent;
+ else
+ hdev->acl_cnt += conn->sent;
} else {
struct hci_conn *acl = conn->link;
if (acl) {
diff --git a/net/bluetooth/hci_core.c b/net/bluetooth/hci_core.c
index bc2a052..45c78c2 100644
--- a/net/bluetooth/hci_core.c
+++ b/net/bluetooth/hci_core.c
@@ -254,6 +254,14 @@ static void hci_init_req(struct hci_dev *hdev, unsigned long opt)
hci_send_cmd(hdev, HCI_OP_WRITE_CA_TIMEOUT, 2, ¶m);
}
+static void hci_le_init_req(struct hci_dev *hdev, unsigned long opt)
+{
+ BT_DBG("%s", hdev->name);
+
+ /* Read LE buffer size */
+ hci_send_cmd(hdev, HCI_OP_LE_READ_BUFFER_SIZE, 0, NULL);
+}
+
static void hci_scan_req(struct hci_dev *hdev, unsigned long opt)
{
__u8 scan = opt;
@@ -509,6 +517,10 @@ int hci_dev_open(__u16 dev)
ret = __hci_request(hdev, hci_init_req, 0,
msecs_to_jiffies(HCI_INIT_TIMEOUT));
+ if (lmp_le_capable(hdev))
+ ret = __hci_request(hdev, hci_le_init_req, 0,
+ msecs_to_jiffies(HCI_INIT_TIMEOUT));
+
clear_bit(HCI_INIT, &hdev->flags);
}
@@ -645,7 +657,7 @@ int hci_dev_reset(__u16 dev)
hdev->flush(hdev);
atomic_set(&hdev->cmd_cnt, 1);
- hdev->acl_cnt = 0; hdev->sco_cnt = 0;
+ hdev->acl_cnt = 0; hdev->sco_cnt = 0; hdev->le_cnt = 0;
if (!test_bit(HCI_RAW, &hdev->flags))
ret = __hci_request(hdev, hci_reset_req, 0,
@@ -1456,8 +1468,25 @@ static inline struct hci_conn *hci_low_sent(struct hci_dev *hdev, __u8 type, int
}
if (conn) {
- int cnt = (type == ACL_LINK ? hdev->acl_cnt : hdev->sco_cnt);
- int q = cnt / num;
+ int cnt, q;
+
+ switch (conn->type) {
+ case ACL_LINK:
+ cnt = hdev->acl_cnt;
+ break;
+ case SCO_LINK:
+ case ESCO_LINK:
+ cnt = hdev->sco_cnt;
+ break;
+ case LE_LINK:
+ cnt = hdev->le_mtu ? hdev->le_cnt : hdev->acl_cnt;
+ break;
+ default:
+ cnt = 0;
+ BT_ERR("Unknown link type");
+ }
+
+ q = cnt / num;
*quote = q ? q : 1;
} else
*quote = 0;
@@ -1556,6 +1585,40 @@ static inline void hci_sched_esco(struct hci_dev *hdev)
}
}
+static inline void hci_sched_le(struct hci_dev *hdev)
+{
+ struct hci_conn *conn;
+ struct sk_buff *skb;
+ int quote, cnt;
+
+ BT_DBG("%s", hdev->name);
+
+ if (!test_bit(HCI_RAW, &hdev->flags)) {
+ /* ACL tx timeout must be longer than maximum
+ * link supervision timeout (40.9 seconds) */
+ if (!hdev->le_cnt &&
+ time_after(jiffies, hdev->le_last_tx + HZ * 45))
+ hci_acl_tx_to(hdev);
+ }
+
+ cnt = hdev->le_pkts ? hdev->le_cnt : hdev->acl_cnt;
+ while (cnt && (conn = hci_low_sent(hdev, LE_LINK, "e))) {
+ while (quote-- && (skb = skb_dequeue(&conn->data_q))) {
+ BT_DBG("skb %p len %d", skb, skb->len);
+
+ hci_send_frame(skb);
+ hdev->le_last_tx = jiffies;
+
+ cnt--;
+ conn->sent++;
+ }
+ }
+ if (hdev->le_pkts)
+ hdev->le_cnt = cnt;
+ else
+ hdev->acl_cnt = cnt;
+}
+
static void hci_tx_task(unsigned long arg)
{
struct hci_dev *hdev = (struct hci_dev *) arg;
@@ -1563,7 +1626,8 @@ static void hci_tx_task(unsigned long arg)
read_lock(&hci_task_lock);
- BT_DBG("%s acl %d sco %d", hdev->name, hdev->acl_cnt, hdev->sco_cnt);
+ BT_DBG("%s acl %d sco %d le %d", hdev->name, hdev->acl_cnt,
+ hdev->sco_cnt, hdev->le_cnt);
/* Schedule queues and send stuff to HCI driver */
@@ -1573,6 +1637,8 @@ static void hci_tx_task(unsigned long arg)
hci_sched_esco(hdev);
+ hci_sched_le(hdev);
+
/* Send next queued raw (unknown type) packet */
while ((skb = skb_dequeue(&hdev->raw_q)))
hci_send_frame(skb);
diff --git a/net/bluetooth/hci_event.c b/net/bluetooth/hci_event.c
index 92c8621..da23502 100644
--- a/net/bluetooth/hci_event.c
+++ b/net/bluetooth/hci_event.c
@@ -539,6 +539,26 @@ static void hci_cc_read_bd_addr(struct hci_dev *hdev, struct sk_buff *skb)
hci_req_complete(hdev, rp->status);
}
+static void hci_cc_le_read_buffer_size(struct hci_dev *hdev,
+ struct sk_buff *skb)
+{
+ struct hci_rp_le_read_buffer_size *rp = (void *) skb->data;
+
+ BT_DBG("%s status 0x%x", hdev->name, rp->status);
+
+ if (rp->status)
+ return;
+
+ hdev->le_mtu = __le16_to_cpu(rp->le_mtu);
+ hdev->le_pkts = rp->le_max_pkt;
+
+ hdev->le_cnt = hdev->le_pkts;
+
+ BT_DBG("%s le mtu %d:%d", hdev->name, hdev->le_mtu, hdev->le_pkts);
+
+ hci_req_complete(hdev, rp->status);
+}
+
static inline void hci_cs_inquiry(struct hci_dev *hdev, __u8 status)
{
BT_DBG("%s status 0x%x", hdev->name, status);
@@ -1353,6 +1373,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_READ_BUFFER_SIZE:
+ hci_cc_le_read_buffer_size(hdev, skb);
+ break;
+
default:
BT_DBG("%s opcode 0x%x", hdev->name, opcode);
break;
@@ -1490,10 +1514,22 @@ static inline void hci_num_comp_pkts_evt(struct hci_dev *hdev, struct sk_buff *s
conn->sent -= count;
if (conn->type == ACL_LINK) {
- if ((hdev->acl_cnt += count) > hdev->acl_pkts)
+ hdev->acl_cnt += count;
+ if (hdev->acl_cnt > hdev->acl_pkts)
hdev->acl_cnt = hdev->acl_pkts;
+ } else if (conn->type == LE_LINK) {
+ if (hdev->le_pkts) {
+ hdev->le_cnt += count;
+ if (hdev->le_cnt > hdev->le_pkts)
+ hdev->le_cnt = hdev->le_pkts;
+ } else {
+ hdev->acl_cnt += count;
+ if (hdev->acl_cnt > hdev->acl_pkts)
+ hdev->acl_cnt = hdev->acl_pkts;
+ }
} else {
- if ((hdev->sco_cnt += count) > hdev->sco_pkts)
+ hdev->sco_cnt += count;
+ if (hdev->sco_cnt > hdev->sco_pkts)
hdev->sco_cnt = hdev->sco_pkts;
}
}
--
1.7.1
^ permalink raw reply related
* [PATCH 2/6] Bluetooth: Add LE connect support
From: Ville Tervo @ 2010-10-25 12:21 UTC (permalink / raw)
To: linux-bluetooth; +Cc: Ville Tervo
In-Reply-To: <1288009280-5149-1-git-send-email-ville.tervo@nokia.com>
Bluetooth V4.0 adds support for Low Energy (LE)
connections. Specification introduses new set
of hci commands to control LE connection.
This patch adds logic to create, cancel and
disconnect LE connections
Signed-off-by: Ville Tervo <ville.tervo@nokia.com>
---
include/net/bluetooth/hci.h | 2 +
include/net/bluetooth/hci_core.h | 25 +++++++++--
net/bluetooth/hci_conn.c | 51 +++++++++++++++++++-
net/bluetooth/hci_event.c | 93 ++++++++++++++++++++++++++++++++++++++
4 files changed, 164 insertions(+), 7 deletions(-)
diff --git a/include/net/bluetooth/hci.h b/include/net/bluetooth/hci.h
index ee5beec..02055b9 100644
--- a/include/net/bluetooth/hci.h
+++ b/include/net/bluetooth/hci.h
@@ -159,6 +159,8 @@ enum {
#define SCO_LINK 0x00
#define ACL_LINK 0x01
#define ESCO_LINK 0x02
+/* Low Energy links do not have defined link type. Use invented one */
+#define LE_LINK 0x80
/* LMP features */
#define LMP_3SLOT 0x01
diff --git a/include/net/bluetooth/hci_core.h b/include/net/bluetooth/hci_core.h
index ebec8c9..2b7f94a 100644
--- a/include/net/bluetooth/hci_core.h
+++ b/include/net/bluetooth/hci_core.h
@@ -60,6 +60,7 @@ struct hci_conn_hash {
spinlock_t lock;
unsigned int acl_num;
unsigned int sco_num;
+ unsigned int le_num;
};
struct bdaddr_list {
@@ -272,20 +273,36 @@ static inline void hci_conn_hash_add(struct hci_dev *hdev, struct hci_conn *c)
{
struct hci_conn_hash *h = &hdev->conn_hash;
list_add(&c->list, &h->list);
- if (c->type == ACL_LINK)
+ switch (c->type) {
+ case ACL_LINK:
h->acl_num++;
- else
+ break;
+ case LE_LINK:
+ h->le_num++;
+ break;
+ case SCO_LINK:
+ case ESCO_LINK:
h->sco_num++;
+ break;
+ }
}
static inline void hci_conn_hash_del(struct hci_dev *hdev, struct hci_conn *c)
{
struct hci_conn_hash *h = &hdev->conn_hash;
list_del(&c->list);
- if (c->type == ACL_LINK)
+ switch (c->type) {
+ case ACL_LINK:
h->acl_num--;
- else
+ break;
+ case LE_LINK:
+ h->le_num--;
+ break;
+ case SCO_LINK:
+ case ESCO_LINK:
h->sco_num--;
+ break;
+ }
}
static inline struct hci_conn *hci_conn_hash_lookup_handle(struct hci_dev *hdev,
diff --git a/net/bluetooth/hci_conn.c b/net/bluetooth/hci_conn.c
index 0b1e460..0944c0c 100644
--- a/net/bluetooth/hci_conn.c
+++ b/net/bluetooth/hci_conn.c
@@ -45,6 +45,32 @@
#include <net/bluetooth/bluetooth.h>
#include <net/bluetooth/hci_core.h>
+void hci_le_connect(struct hci_conn *conn)
+{
+ struct hci_dev *hdev = conn->hdev;
+ struct hci_cp_le_create_conn cp;
+
+ conn->state = BT_CONNECT;
+ conn->out = 1;
+
+ memset(&cp, 0, sizeof(cp));
+ cp.scan_interval = cpu_to_le16(0x0004);
+ cp.scan_window = cpu_to_le16(0x0004);
+ bacpy(&cp.peer_addr, &conn->dst);
+ cp.conn_interval_min = cpu_to_le16(0x0008);
+ cp.conn_interval_max = cpu_to_le16(0x0100);
+ cp.supervision_timeout = cpu_to_le16(0x0064);
+ cp.min_ce_len = cpu_to_le16(0x0001);
+ cp.max_ce_len = cpu_to_le16(0x0001);
+
+ hci_send_cmd(hdev, HCI_OP_LE_CREATE_CONN, sizeof(cp), &cp);
+}
+
+static void hci_le_connect_cancel(struct hci_conn *conn)
+{
+ hci_send_cmd(conn->hdev, HCI_OP_LE_CREATE_CONN_CANCEL, 0, NULL);
+}
+
void hci_acl_connect(struct hci_conn *conn)
{
struct hci_dev *hdev = conn->hdev;
@@ -192,8 +218,12 @@ static void hci_conn_timeout(unsigned long arg)
switch (conn->state) {
case BT_CONNECT:
case BT_CONNECT2:
- if (conn->type == ACL_LINK && conn->out)
- hci_acl_connect_cancel(conn);
+ if (conn->out) {
+ if (conn->type == ACL_LINK)
+ hci_acl_connect_cancel(conn);
+ else if (conn->type == LE_LINK)
+ hci_le_connect_cancel(conn);
+ }
break;
case BT_CONFIG:
case BT_CONNECTED:
@@ -359,15 +389,30 @@ struct hci_dev *hci_get_route(bdaddr_t *dst, bdaddr_t *src)
}
EXPORT_SYMBOL(hci_get_route);
-/* Create SCO or ACL connection.
+/* Create SCO, ACL or LE connection.
* Device _must_ be locked */
struct hci_conn *hci_connect(struct hci_dev *hdev, int type, bdaddr_t *dst, __u8 sec_level, __u8 auth_type)
{
struct hci_conn *acl;
struct hci_conn *sco;
+ struct hci_conn *le;
BT_DBG("%s dst %s", hdev->name, batostr(dst));
+ if (type == LE_LINK) {
+ le = hci_conn_hash_lookup_ba(hdev, LE_LINK, dst);
+ if (!le)
+ le = hci_conn_add(hdev, LE_LINK, dst);
+ if (!le)
+ return NULL;
+ if (le->state == BT_OPEN)
+ hci_le_connect(le);
+
+ hci_conn_hold(le);
+
+ return le;
+ }
+
if (!(acl = hci_conn_hash_lookup_ba(hdev, ACL_LINK, dst))) {
if (!(acl = hci_conn_add(hdev, ACL_LINK, dst)))
return NULL;
diff --git a/net/bluetooth/hci_event.c b/net/bluetooth/hci_event.c
index 84093b0..92c8621 100644
--- a/net/bluetooth/hci_event.c
+++ b/net/bluetooth/hci_event.c
@@ -822,6 +822,43 @@ static void hci_cs_exit_sniff_mode(struct hci_dev *hdev, __u8 status)
hci_dev_unlock(hdev);
}
+static void hci_cs_le_create_conn(struct hci_dev *hdev, __u8 status)
+{
+ struct hci_cp_le_create_conn *cp;
+ struct hci_conn *conn;
+
+ BT_DBG("%s status 0x%x", hdev->name, status);
+
+ cp = hci_sent_cmd_data(hdev, HCI_OP_LE_CREATE_CONN);
+ if (!cp)
+ return;
+
+ hci_dev_lock(hdev);
+
+ conn = hci_conn_hash_lookup_ba(hdev, LE_LINK, &cp->peer_addr);
+
+ BT_DBG("%s bdaddr %s conn %p", hdev->name, batostr(&cp->peer_addr),
+ conn);
+
+ if (status) {
+ if (conn && conn->state == BT_CONNECT) {
+ conn->state = BT_CLOSED;
+ hci_proto_connect_cfm(conn, status);
+ hci_conn_del(conn);
+ }
+ } else {
+ if (!conn) {
+ conn = hci_conn_add(hdev, LE_LINK, &cp->peer_addr);
+ if (conn)
+ conn->out = 1;
+ else
+ BT_ERR("No memory for new connection");
+ }
+ }
+
+ hci_dev_unlock(hdev);
+}
+
static inline void hci_inquiry_complete_evt(struct hci_dev *hdev, struct sk_buff *skb)
{
__u8 status = *((__u8 *) skb->data);
@@ -1382,6 +1419,10 @@ static inline void hci_cmd_status_evt(struct hci_dev *hdev, struct sk_buff *skb)
hci_cs_exit_sniff_mode(hdev, ev->status);
break;
+ case HCI_OP_LE_CREATE_CONN:
+ hci_cs_le_create_conn(hdev, ev->status);
+ break;
+
default:
BT_DBG("%s opcode 0x%x", hdev->name, opcode);
break;
@@ -1827,6 +1868,54 @@ static inline void hci_remote_host_features_evt(struct hci_dev *hdev, struct sk_
hci_dev_unlock(hdev);
}
+static inline void hci_le_conn_complete_evt(struct hci_dev *hdev, struct sk_buff *skb)
+{
+ struct hci_ev_le_conn_complete *ev = (void *) skb->data;
+ struct hci_conn *conn;
+
+ BT_DBG("%s status %d", hdev->name, ev->status);
+
+ hci_dev_lock(hdev);
+
+ conn = hci_conn_hash_lookup_ba(hdev, LE_LINK, &ev->bdaddr);
+ if (!conn)
+ goto unlock;
+
+ if (ev->status) {
+ hci_proto_connect_cfm(conn, ev->status);
+ conn->state = BT_CLOSED;
+ hci_conn_del(conn);
+ goto unlock;
+ }
+
+ conn->handle = __le16_to_cpu(ev->handle);
+ conn->state = BT_CONNECTED;
+
+ hci_conn_hold_device(conn);
+ hci_conn_add_sysfs(conn);
+
+ hci_proto_connect_cfm(conn, ev->status);
+
+unlock:
+ hci_dev_unlock(hdev);
+}
+
+static inline void hci_le_meta_evt(struct hci_dev *hdev, struct sk_buff *skb)
+{
+ struct hci_ev_le_meta *le_ev = (void *) skb->data;
+
+ skb_pull(skb, sizeof(*le_ev));
+
+ switch (le_ev->subevent) {
+ case HCI_EV_LE_CONN_COMPLETE:
+ hci_le_conn_complete_evt(hdev, skb);
+ break;
+
+ default:
+ break;
+ }
+}
+
void hci_event_packet(struct hci_dev *hdev, struct sk_buff *skb)
{
struct hci_event_hdr *hdr = (void *) skb->data;
@@ -1963,6 +2052,10 @@ void hci_event_packet(struct hci_dev *hdev, struct sk_buff *skb)
hci_remote_host_features_evt(hdev, skb);
break;
+ case HCI_EV_LE_META:
+ hci_le_meta_evt(hdev, skb);
+ break;
+
default:
BT_DBG("%s event 0x%x", hdev->name, event);
break;
--
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