* Re: [PATCH] Bluetooth: Make hci_blacklist_clear function static
From: Johan Hedberg @ 2014-02-28 7:32 UTC (permalink / raw)
To: Marcel Holtmann; +Cc: linux-bluetooth
In-Reply-To: <1393558554-42295-1-git-send-email-marcel@holtmann.org>
Hi Marcel,
On Thu, Feb 27, 2014, Marcel Holtmann wrote:
> The hci_blacklist_clear function is not used outside of hci_core.c and
> can be made static.
>
> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
> ---
> include/net/bluetooth/hci_core.h | 1 -
> net/bluetooth/hci_core.c | 2 +-
> 2 files changed, 1 insertion(+), 2 deletions(-)
Applied to bluetooth-next. Thanks.
Johan
^ permalink raw reply
* Re: [PATCH BlueZ] core: retry connect_dbus() several times
From: Adam Lee @ 2014-02-28 7:31 UTC (permalink / raw)
To: Marcel Holtmann; +Cc: linux-bluetooth
In-Reply-To: <04802ECE-6B8D-4DF4-BFFD-EABBD42BD30F@holtmann.org>
On Thu, Feb 27, 2014 at 11:15:01PM -0800, Marcel Holtmann wrote:
> Hi Adadm,
>
> > Sometimes the hardware, especially which needs firmware patching, is not
> > yet ready when connect_dbus().
>
> this makes no sense. Connecting to D-Bus has nothing to do with
> firmware patching. What are you exactly fixing here?
connect_dbus() fails sometimes with Intel 7260 bluetooth, sleeping 0.5s
before executing bluetoothd workarounds it. I assume the firmware
patching slows down hardware initialization then fails to connect.
Any other possibility? I'm not a D-Bus guru :)
--
Adam Lee
http://adam8157.info
^ permalink raw reply
* Re: [PATCH BlueZ] core: retry connect_dbus() several times
From: Marcel Holtmann @ 2014-02-28 7:15 UTC (permalink / raw)
To: Adam Lee; +Cc: linux-bluetooth
In-Reply-To: <1393571362-27898-1-git-send-email-adam8157@gmail.com>
Hi Adadm,
> Sometimes the hardware, especially which needs firmware patching, is not
> yet ready when connect_dbus().
this makes no sense. Connecting to D-Bus has nothing to do with firmware patching. What are you exactly fixing here?
Regards
Marcel
^ permalink raw reply
* Re: [PATCHv2 4/8] shared/hfp: Add implementation of precessing commands
From: Marcel Holtmann @ 2014-02-28 7:13 UTC (permalink / raw)
To: Marcin Kraglak; +Cc: linux-bluetooth
In-Reply-To: <1393494006-20363-5-git-send-email-marcin.kraglak@tieto.com>
Hi Marcin,
> It will process both extended and basic commands.
> ---
> src/shared/hfp.c | 96 ++++++++++++++++++++++++++++++++++++++++++++++++++++++--
> 1 file changed, 94 insertions(+), 2 deletions(-)
>
> diff --git a/src/shared/hfp.c b/src/shared/hfp.c
> index cf54a8f..6a39a36 100644
> --- a/src/shared/hfp.c
> +++ b/src/shared/hfp.c
> @@ -29,6 +29,7 @@
> #include <unistd.h>
> #include <string.h>
> #include <stdarg.h>
> +#include <ctype.h>
>
> #include "src/shared/util.h"
> #include "src/shared/ringbuf.h"
> @@ -135,14 +136,105 @@ static void wakeup_writer(struct hfp_gw *hfp)
> hfp->writer_active = true;
> }
>
> +static enum hfp_cmd_type get_cmd_type(struct hfp_gw_result *result)
> +{
> + if (result->data[result->offset] == '=') {
> + result->offset++;
> + if (result->data[result->offset] == '?') {
> + result->offset++;
> + return HFP_AT_TEST;
> + } else {
> + return HFP_AT_SET;
> + }
can we please keep the kernel coding style out of user space. And I hate it when both if parts use return.
if (blah) {
xxxx
return x;
}
return y.
> + } else if (result->data[result->offset] == '?') {
And this else if is pointless as well. You are leaving the function in the first if part no matter what.
> + result->offset++;
> + return HFP_AT_READ;
> + } else {
> + return HFP_AT_COMMAND;
> + }
Same here.
> +}
> +
> static bool process_basic(struct hfp_gw *hfp, struct hfp_gw_result *result)
> {
> - return false;
> + const char *prefix = result->data + result->offset;
> + struct prefix_handler_data *handler;
> + enum hfp_cmd_type type;
> + char lookup_prefix[4];
> + uint8_t pref_len = 0;
> + int i;
> +
> + /* Check if first sign is character */
> + if (isalpha(prefix[pref_len])) {
> + /* Handle S-parameter prefix */
> + if (toupper(prefix[pref_len]) == 'S') {
> + do {
> + pref_len++;
> + } while (isdigit(prefix[pref_len]));
> + /*S-parameter must be followed with number*/
> + if (pref_len == 1)
> + pref_len—;
Where is the S parameter stuff coming from? I did ask this before and never got an answer to it.
Regards
Marcel
^ permalink raw reply
* [PATCH BlueZ] core: retry connect_dbus() several times
From: Adam Lee @ 2014-02-28 7:09 UTC (permalink / raw)
To: linux-bluetooth; +Cc: Marcel Holtmann
Sometimes the hardware, especially which needs firmware patching, is not
yet ready when connect_dbus().
Signed-off-by: Adam Lee <adam8157@gmail.com>
---
src/main.c | 15 ++++++++++++---
1 file changed, 12 insertions(+), 3 deletions(-)
diff --git a/src/main.c b/src/main.c
index b3136fc..cf1f8fa 100644
--- a/src/main.c
+++ b/src/main.c
@@ -491,6 +491,7 @@ int main(int argc, char *argv[])
GKeyFile *config;
guint signal, watchdog;
const char *watchdog_usec;
+ uint8_t reconnect_times = 3;
init_defaults();
@@ -527,9 +528,17 @@ int main(int argc, char *argv[])
parse_config(config);
- if (connect_dbus() < 0) {
- error("Unable to get on D-Bus");
- exit(1);
+ /* Reconnect several times in case the hardware is not ready */
+ while (reconnect_times--) {
+ if (connect_dbus() == 0)
+ break;
+
+ if (reconnect_times != 1) {
+ usleep(500 * 1000);
+ } else {
+ error("Unable to get on D-Bus");
+ exit(1);
+ }
}
if (option_experimental)
--
1.9.0
^ permalink raw reply related
* Re: [PATCHv2 1/8] shared/hfp: Fix parsing line with few commands
From: Marcin Kraglak @ 2014-02-28 7:08 UTC (permalink / raw)
To: Marcel Holtmann; +Cc: linux-bluetooth@vger.kernel.org development
In-Reply-To: <AE23C6FB-1A02-4C3C-9E43-DE569BF3F90D@holtmann.org>
Hi Marcel,
On 28 February 2014 08:00, Marcel Holtmann <marcel@holtmann.org> wrote:
> Hi Marcin,
>
>> If hfp_gw received line with few commands, it called command
>> handler one time, for first command. Next comamnd was processed
>> only if next line was received.
>> Now, after every response from gw, we call proces_input to be
>> sure that all data has been be processed.
>> It will process next command only if response for previous was sent.
>> ---
>> src/shared/hfp.c | 16 +++++++++-------
>> 1 file changed, 9 insertions(+), 7 deletions(-)
>>
>> diff --git a/src/shared/hfp.c b/src/shared/hfp.c
>> index 854cf46..0681b19 100644
>> --- a/src/shared/hfp.c
>> +++ b/src/shared/hfp.c
>> @@ -121,23 +121,21 @@ static void process_input(struct hfp_gw *hfp)
>>
>> *ptr = '\0';
>> count = asprintf(&ptr, "%s%s", str, str2);
>> - str = ptr;
>> } else {
>> - count = ptr - str;
>> *ptr = '\0';
>> + count = asprintf(&ptr, "%s", str);
>> }
>
> the whole point here is to not allocate a string if the command is not wrapped in the ring buffer. No idea what you are fixing here. And it is also not described in the commit message.
>
>> hfp->result_pending = true;
>>
>> + len = ringbuf_drain(hfp->read_buf, count + 1);
>> +
>> if (hfp->command_callback)
>> - hfp->command_callback(str, hfp->command_data);
>> + hfp->command_callback(ptr, hfp->command_data);
>> else
>> hfp_gw_send_result(hfp, HFP_RESULT_ERROR);
>>
>> - len = ringbuf_drain(hfp->read_buf, count + 1);
>> -
>> - if (str == ptr)
>> - free(ptr);
>> + free(ptr);
>> }
>>
>> static void read_watch_destroy(void *user_data)
>> @@ -341,6 +339,8 @@ bool hfp_gw_send_result(struct hfp_gw *hfp, enum hfp_result result)
>>
>> hfp->result_pending = false;
>>
>> + process_input(hfp);
>> +
>> return true;
>> }
>>
>> @@ -356,6 +356,8 @@ bool hfp_gw_send_error(struct hfp_gw *hfp, enum hfp_error error)
>>
>> hfp->result_pending = false;
>>
>> + process_input(hfp);
>> +
>> return true;
>> }
>
> We can certainly do this, but normally AT commands work that you get one, send a response and then get the next one. Except for unsolicited notification, but in HFP gateway case, we are the ones sending these and not the headset.
>
> What is this all fixing?
>
> Regards
>
> Marcel
>
If we can receive one command in time, lets just ignore this patch
BR
Marcin
^ permalink raw reply
* Re: [PATCHv2 2/8] shared/hfp: Add prefix handlers functionality
From: Marcel Holtmann @ 2014-02-28 7:06 UTC (permalink / raw)
To: Marcin Kraglak; +Cc: linux-bluetooth
In-Reply-To: <1393494006-20363-3-git-send-email-marcin.kraglak@tieto.com>
Hi Marcin,
> Add two functions: hfp_gw_set_prefix_handler() and
> hfp_gw_remove_prefix_handler(). It will allow user to register for
> specific command. Current implementation just adds or removes data
> from hfp_gw structure.
> ---
> Makefile.tools | 1 +
> src/shared/hfp.c | 84 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++
> src/shared/hfp.h | 17 ++++++++++++
> 3 files changed, 102 insertions(+)
>
> diff --git a/Makefile.tools b/Makefile.tools
> index 9f7ba9f..31e1093 100644
> --- a/Makefile.tools
> +++ b/Makefile.tools
> @@ -63,6 +63,7 @@ emulator_hfp_SOURCES = emulator/hfp.c \
> monitor/mainloop.h monitor/mainloop.c \
> src/shared/io.h src/shared/io-mainloop.c \
> src/shared/util.h src/shared/util.c \
> + src/shared/queue.h src/shared/queue.c \
> src/shared/ringbuf.h src/shared/ringbuf.c \
> src/shared/hfp.h src/shared/hfp.c
>
> diff --git a/src/shared/hfp.c b/src/shared/hfp.c
> index 0681b19..e164dd6 100644
> --- a/src/shared/hfp.c
> +++ b/src/shared/hfp.c
> @@ -32,6 +32,7 @@
>
> #include "src/shared/util.h"
> #include "src/shared/ringbuf.h"
> +#include "src/shared/queue.h"
> #include "src/shared/io.h"
> #include "src/shared/hfp.h"
>
> @@ -42,6 +43,7 @@ struct hfp_gw {
> struct io *io;
> struct ringbuf *read_buf;
> struct ringbuf *write_buf;
> + struct queue *prefix_handlers;
> bool writer_active;
> bool permissive_syntax;
> bool result_pending;
> @@ -60,6 +62,37 @@ struct hfp_gw {
> bool destroyed;
> };
>
> +struct prefix_handler_data {
> + char *prefix;
> + void *user_data;
> + hfp_destroy_func_t destroy;
> + hfp_result_func_t callback;
> +};
> +
> +static void destroy_prefix_handler_data(void *data)
> +{
> + struct prefix_handler_data *handler = data;
> +
> + if (handler->destroy)
> + handler->destroy(handler->user_data);
> +
> + free(handler);
> +}
> +
> +static bool match_handler_prefix(const void *a, const void *b)
> +{
> + const struct prefix_handler_data *handler = a;
> + const char *prefix = b;
> +
> + if (strlen(handler->prefix) != strlen(prefix))
> + return false;
> +
> + if (memcmp(handler->prefix, prefix, strlen(prefix)))
> + return false;
> +
> + return true;
> +}
> +
> static void write_watch_destroy(void *user_data)
> {
> struct hfp_gw *hfp = user_data;
> @@ -194,8 +227,19 @@ struct hfp_gw *hfp_gw_new(int fd)
> return NULL;
> }
>
> + hfp->prefix_handlers = queue_new();
> + if (!hfp->prefix_handlers) {
> + io_destroy(hfp->io);
> + ringbuf_free(hfp->write_buf);
> + ringbuf_free(hfp->read_buf);
> + free(hfp);
> + return NULL;
> + }
> +
> if (!io_set_read_handler(hfp->io, can_read_data,
> hfp, read_watch_destroy)) {
> + queue_destroy(hfp->prefix_handlers,
> + destroy_prefix_handler_data);
> io_destroy(hfp->io);
> ringbuf_free(hfp->write_buf);
> ringbuf_free(hfp->read_buf);
> @@ -248,6 +292,9 @@ void hfp_gw_unref(struct hfp_gw *hfp)
> ringbuf_free(hfp->write_buf);
> hfp->write_buf = NULL;
>
> + queue_destroy(hfp->prefix_handlers, destroy_prefix_handler_data);
> + hfp->prefix_handlers = NULL;
> +
> if (!hfp->in_disconnect) {
> free(hfp);
> return;
> @@ -407,6 +454,43 @@ bool hfp_gw_set_command_handler(struct hfp_gw *hfp,
> return true;
> }
>
> +bool hfp_gw_set_prefix_handler(struct hfp_gw *hfp, hfp_result_func_t callback,
> + char *prefix, void *user_data,
> + hfp_destroy_func_t destroy)
> +{
it is either add and remove or register and unregister, but never set and remove. If you set something, the next call to set would overwrite it.
Regards
Marcel
^ permalink raw reply
* Re: [PATCHv2 3/8] shared/hfp: Add initial implementiation of processing commands
From: Marcel Holtmann @ 2014-02-28 7:05 UTC (permalink / raw)
To: Marcin Kraglak; +Cc: linux-bluetooth
In-Reply-To: <1393494006-20363-4-git-send-email-marcin.kraglak@tieto.com>
Hi Marcin,
> ---
> src/shared/hfp.c | 55 +++++++++++++++++++++++++++++++++++++++++++++++++++----
> 1 file changed, 51 insertions(+), 4 deletions(-)
>
> diff --git a/src/shared/hfp.c b/src/shared/hfp.c
> index e164dd6..cf54a8f 100644
> --- a/src/shared/hfp.c
> +++ b/src/shared/hfp.c
> @@ -69,6 +69,11 @@ struct prefix_handler_data {
> hfp_result_func_t callback;
> };
>
> +struct hfp_gw_result {
> + const char *data;
> + int offset;
> +};
> +
> static void destroy_prefix_handler_data(void *data)
> {
> struct prefix_handler_data *handler = data;
> @@ -130,6 +135,46 @@ static void wakeup_writer(struct hfp_gw *hfp)
> hfp->writer_active = true;
> }
>
> +static bool process_basic(struct hfp_gw *hfp, struct hfp_gw_result *result)
> +{
> + return false;
> +}
> +
> +static bool process_extended(struct hfp_gw *hfp, struct hfp_gw_result *result)
> +{
> + return false;
> +}
> +
> +static void skip_whitespace(struct hfp_gw_result *result)
> +{
> + while (result->data[result->offset] == ' ')
> + result->offset++;
> +}
> +
> +static bool call_prefix_handler(struct hfp_gw *hfp, const char *data)
> +{
> + struct hfp_gw_result result;
> +
> + result.offset = 0;
> + result.data = data;
> +
> + skip_whitespace(&result);
I would just do the skip leading whitespace here without bothering putting it into a separate function. There is really no point.
> +
> + if (strlen(data + result.offset) < 3)
> + return false;
> +
> + if (strncmp(data + result.offset, "AT", 2))
> + if (strncmp(data + result.offset, "at", 2))
> + return false;
> +
> + result.offset += 2;
> +
> + if (data[result.offset] == '+')
> + return process_extended(hfp, &result);
> + else
> + return process_basic(hfp, &result);
Please do not do this. I mentioned this before, this basic vs extended is pointless.
Command matching should be either based on commands like “D” or “+BRSF” and not bother trying to treat the + any special. See how src/emulator.c in oFono registers all the handlers.
Regards
Marcel
^ permalink raw reply
* Re: [PATCHv2 1/8] shared/hfp: Fix parsing line with few commands
From: Marcel Holtmann @ 2014-02-28 7:00 UTC (permalink / raw)
To: Marcin Kraglak; +Cc: linux-bluetooth
In-Reply-To: <1393494006-20363-2-git-send-email-marcin.kraglak@tieto.com>
Hi Marcin,
> If hfp_gw received line with few commands, it called command
> handler one time, for first command. Next comamnd was processed
> only if next line was received.
> Now, after every response from gw, we call proces_input to be
> sure that all data has been be processed.
> It will process next command only if response for previous was sent.
> ---
> src/shared/hfp.c | 16 +++++++++-------
> 1 file changed, 9 insertions(+), 7 deletions(-)
>
> diff --git a/src/shared/hfp.c b/src/shared/hfp.c
> index 854cf46..0681b19 100644
> --- a/src/shared/hfp.c
> +++ b/src/shared/hfp.c
> @@ -121,23 +121,21 @@ static void process_input(struct hfp_gw *hfp)
>
> *ptr = '\0';
> count = asprintf(&ptr, "%s%s", str, str2);
> - str = ptr;
> } else {
> - count = ptr - str;
> *ptr = '\0';
> + count = asprintf(&ptr, "%s", str);
> }
the whole point here is to not allocate a string if the command is not wrapped in the ring buffer. No idea what you are fixing here. And it is also not described in the commit message.
> hfp->result_pending = true;
>
> + len = ringbuf_drain(hfp->read_buf, count + 1);
> +
> if (hfp->command_callback)
> - hfp->command_callback(str, hfp->command_data);
> + hfp->command_callback(ptr, hfp->command_data);
> else
> hfp_gw_send_result(hfp, HFP_RESULT_ERROR);
>
> - len = ringbuf_drain(hfp->read_buf, count + 1);
> -
> - if (str == ptr)
> - free(ptr);
> + free(ptr);
> }
>
> static void read_watch_destroy(void *user_data)
> @@ -341,6 +339,8 @@ bool hfp_gw_send_result(struct hfp_gw *hfp, enum hfp_result result)
>
> hfp->result_pending = false;
>
> + process_input(hfp);
> +
> return true;
> }
>
> @@ -356,6 +356,8 @@ bool hfp_gw_send_error(struct hfp_gw *hfp, enum hfp_error error)
>
> hfp->result_pending = false;
>
> + process_input(hfp);
> +
> return true;
> }
We can certainly do this, but normally AT commands work that you get one, send a response and then get the next one. Except for unsolicited notification, but in HFP gateway case, we are the ones sending these and not the headset.
What is this all fixing?
Regards
Marcel
^ permalink raw reply
* Re: Background scanning and white list usage
From: Marcel Holtmann @ 2014-02-28 6:51 UTC (permalink / raw)
To: Johan Hedberg; +Cc: linux-bluetooth
In-Reply-To: <20140228064422.GA28466@localhost.P-661HNU-F1>
Hi Johan,
>> The complicated part comes into play when we have devices with LE
>> Privacy enabled and when they are using resolvable private addresses.
>> Meaning when our IRK list is populated with identity addresses and
>> their IRKs. The only way to make this work with the current available
>> controller features is if we program the RPA into the white list.
>> Since that RPA is going to change over time, we need to stop scanning
>> with the white list filter every now and then, scan for all devices
>> and resolve the RPA. If we see a new RPA for a know IRK, we have to
>> replace the old RPA in the white list with the new RPA. And then we go
>> back to scanning with the white list filter policy.
>>
>> Now the important question is what are good enough intervals to make
>> this work smoothly. Devices using LE Privacy will take a hit in their
>> re-connection time, but that is what we have to trade in for compared
>> to waking up the host for every single advertising packet.
>>
>> My initial idea is to scan 5 minutes using the white list, then scan
>> 10 seconds without the white list, then back to 5 minutes using the
>> white list and so on.
>>
>> The default value for the PRA lifetime according to the specification
>> is 15 minutes. I timed recent iOS devices which seem to be using 9
>> minutes intervals. So we have to play a little bit with this and see
>> what are good values.
>>
>> Maybe 3 minutes white list scan and 5 seconds without white list is
>> better. Things to try out.
>
> I don't think this is a good idea at all. With LE starting advertising
> is typically seen as the initiating action of connection creation
> (unlike with BR/EDR where HCI_Create_Connection is the initiating
> action). Typically peripherals mean "connect to me now!" when they start
> connectable advertising.
>
> Let's stay you switch on your peripheral device, or it comes into range
> you haven't used it for some time (hours or even days). If it's using
> RPAs it's pretty much guaranteed to have a different one than what we
> know of and even if we're using 3 minutes white list scanning the user
> is on average going to have to wait for 1.5 minutes for the device to
> get connected which is not acceptable behavior (the extreme example
> would be if this is a keyboard or a mouse which you start using for the
> first time in the morning - moving the mouse or pressing a key on the
> keyboard should certainly get you a connection in less than 1 second).
HID devices would suffer the most here. Fully agree here.
However since neither Microsoft Windows nor OS X can deal with RPAs at the moment, I do not think we are entering a dangerous zone here from an interoperability point of view. Actually Windows 8.1 is not able to connect to any random address for that matter.
My point is that we certainly not make it worse.
> I fully understand the desire to use the white list as it's a very nice
> power saving feature, but I don't think we can win here as long as we
> don't have a way to have the controller do the resolving for us.
>
> One thing we could potentially try to do (but which I doubt is really
> worth it in the end) is to track the age of resolved RPAs. If we have an
> RPA which was resolved say less than 5 minutes ago we consider it
> appropriate to place into the white list. Otherwise we skip using the
> white list.
I was thinking about this as well. Over time we could learn the age of a RPA and thus schedule the scanning without white list times most efficient. Frankly, I want to get the white list usage going first. As long as you only have public or static addresses, it is the way to go. And then we optimize it when we have to deal with RPAs.
We can not close our eyes to iOS devices using RPAs and I am not willing to take the power hit of getting flooded with advertising reports.
Regards
Marcel
^ permalink raw reply
* Re: Background scanning and white list usage
From: Johan Hedberg @ 2014-02-28 6:44 UTC (permalink / raw)
To: Marcel Holtmann; +Cc: linux-bluetooth
In-Reply-To: <BFAEE1C5-E74F-40F0-A1A4-8F4907FBDCF4@holtmann.org>
Hi Marcel,
On Thu, Feb 27, 2014, Marcel Holtmann wrote:
> The complicated part comes into play when we have devices with LE
> Privacy enabled and when they are using resolvable private addresses.
> Meaning when our IRK list is populated with identity addresses and
> their IRKs. The only way to make this work with the current available
> controller features is if we program the RPA into the white list.
> Since that RPA is going to change over time, we need to stop scanning
> with the white list filter every now and then, scan for all devices
> and resolve the RPA. If we see a new RPA for a know IRK, we have to
> replace the old RPA in the white list with the new RPA. And then we go
> back to scanning with the white list filter policy.
>
> Now the important question is what are good enough intervals to make
> this work smoothly. Devices using LE Privacy will take a hit in their
> re-connection time, but that is what we have to trade in for compared
> to waking up the host for every single advertising packet.
>
> My initial idea is to scan 5 minutes using the white list, then scan
> 10 seconds without the white list, then back to 5 minutes using the
> white list and so on.
>
> The default value for the PRA lifetime according to the specification
> is 15 minutes. I timed recent iOS devices which seem to be using 9
> minutes intervals. So we have to play a little bit with this and see
> what are good values.
>
> Maybe 3 minutes white list scan and 5 seconds without white list is
> better. Things to try out.
I don't think this is a good idea at all. With LE starting advertising
is typically seen as the initiating action of connection creation
(unlike with BR/EDR where HCI_Create_Connection is the initiating
action). Typically peripherals mean "connect to me now!" when they start
connectable advertising.
Let's stay you switch on your peripheral device, or it comes into range
you haven't used it for some time (hours or even days). If it's using
RPAs it's pretty much guaranteed to have a different one than what we
know of and even if we're using 3 minutes white list scanning the user
is on average going to have to wait for 1.5 minutes for the device to
get connected which is not acceptable behavior (the extreme example
would be if this is a keyboard or a mouse which you start using for the
first time in the morning - moving the mouse or pressing a key on the
keyboard should certainly get you a connection in less than 1 second).
I fully understand the desire to use the white list as it's a very nice
power saving feature, but I don't think we can win here as long as we
don't have a way to have the controller do the resolving for us.
One thing we could potentially try to do (but which I doubt is really
worth it in the end) is to track the age of resolved RPAs. If we have an
RPA which was resolved say less than 5 minutes ago we consider it
appropriate to place into the white list. Otherwise we skip using the
white list.
Johan
^ permalink raw reply
* [PATCH 4/4] Bluetooth: Track LE white list modification via HCI commands
From: Marcel Holtmann @ 2014-02-28 4:37 UTC (permalink / raw)
To: linux-bluetooth
When the LE white list gets changed via HCI commands make sure that
the internal storage of the white list entries gets updated.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
---
net/bluetooth/hci_event.c | 55 +++++++++++++++++++++++++++++++++++++++++++++++
1 file changed, 55 insertions(+)
diff --git a/net/bluetooth/hci_event.c b/net/bluetooth/hci_event.c
index 40e5bfebb484..e3d7151e808e 100644
--- a/net/bluetooth/hci_event.c
+++ b/net/bluetooth/hci_event.c
@@ -1038,6 +1038,49 @@ static void hci_cc_le_read_white_list_size(struct hci_dev *hdev,
hdev->le_white_list_size = rp->size;
}
+static void hci_cc_le_clear_white_list(struct hci_dev *hdev,
+ struct sk_buff *skb)
+{
+ __u8 status = *((__u8 *) skb->data);
+
+ BT_DBG("%s status 0x%2.2x", hdev->name, status);
+
+ if (!status)
+ hci_white_list_clear(hdev);
+}
+
+static void hci_cc_le_add_to_white_list(struct hci_dev *hdev,
+ struct sk_buff *skb)
+{
+ struct hci_cp_le_add_to_white_list *sent;
+ __u8 status = *((__u8 *) skb->data);
+
+ BT_DBG("%s status 0x%2.2x", hdev->name, status);
+
+ sent = hci_sent_cmd_data(hdev, HCI_OP_LE_ADD_TO_WHITE_LIST);
+ if (!sent)
+ return;
+
+ if (!status)
+ hci_white_list_add(hdev, &sent->bdaddr, sent->bdaddr_type);
+}
+
+static void hci_cc_le_del_from_white_list(struct hci_dev *hdev,
+ struct sk_buff *skb)
+{
+ struct hci_cp_le_del_from_white_list *sent;
+ __u8 status = *((__u8 *) skb->data);
+
+ BT_DBG("%s status 0x%2.2x", hdev->name, status);
+
+ sent = hci_sent_cmd_data(hdev, HCI_OP_LE_DEL_FROM_WHITE_LIST);
+ if (!sent)
+ return;
+
+ if (!status)
+ hci_white_list_del(hdev, &sent->bdaddr, sent->bdaddr_type);
+}
+
static void hci_cc_le_read_supported_states(struct hci_dev *hdev,
struct sk_buff *skb)
{
@@ -2378,6 +2421,18 @@ static void hci_cmd_complete_evt(struct hci_dev *hdev, struct sk_buff *skb)
hci_cc_le_read_white_list_size(hdev, skb);
break;
+ case HCI_OP_LE_CLEAR_WHITE_LIST:
+ hci_cc_le_clear_white_list(hdev, skb);
+ break;
+
+ case HCI_OP_LE_ADD_TO_WHITE_LIST:
+ hci_cc_le_add_to_white_list(hdev, skb);
+ break;
+
+ case HCI_OP_LE_DEL_FROM_WHITE_LIST:
+ hci_cc_le_del_from_white_list(hdev, skb);
+ break;
+
case HCI_OP_LE_READ_SUPPORTED_STATES:
hci_cc_le_read_supported_states(hdev, skb);
break;
--
1.8.5.3
^ permalink raw reply related
* [PATCH 3/4] Bluetooth: Add support for storing LE white list entries
From: Marcel Holtmann @ 2014-02-28 4:37 UTC (permalink / raw)
To: linux-bluetooth
The current LE white list entries require storing in the HCI controller
structure. So provide a storage and access functions for it. In addition
export the current list via debugfs.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
---
include/net/bluetooth/hci_core.h | 7 ++++
net/bluetooth/hci_core.c | 90 ++++++++++++++++++++++++++++++++++++++++
2 files changed, 97 insertions(+)
diff --git a/include/net/bluetooth/hci_core.h b/include/net/bluetooth/hci_core.h
index 55ee2a5ca503..0c63a7e12d90 100644
--- a/include/net/bluetooth/hci_core.h
+++ b/include/net/bluetooth/hci_core.h
@@ -284,6 +284,7 @@ struct hci_dev {
struct list_head long_term_keys;
struct list_head identity_resolving_keys;
struct list_head remote_oob_data;
+ struct list_head le_white_list;
struct list_head le_conn_params;
struct list_head pend_le_conns;
@@ -799,6 +800,12 @@ struct bdaddr_list *hci_blacklist_lookup(struct hci_dev *hdev,
int hci_blacklist_add(struct hci_dev *hdev, bdaddr_t *bdaddr, u8 type);
int hci_blacklist_del(struct hci_dev *hdev, bdaddr_t *bdaddr, u8 type);
+struct bdaddr_list *hci_white_list_lookup(struct hci_dev *hdev,
+ bdaddr_t *bdaddr, u8 type);
+void hci_white_list_clear(struct hci_dev *hdev);
+int hci_white_list_add(struct hci_dev *hdev, bdaddr_t *bdaddr, u8 type);
+int hci_white_list_del(struct hci_dev *hdev, bdaddr_t *bdaddr, u8 type);
+
struct hci_conn_params *hci_conn_params_lookup(struct hci_dev *hdev,
bdaddr_t *addr, u8 addr_type);
int hci_conn_params_add(struct hci_dev *hdev, bdaddr_t *addr, u8 addr_type,
diff --git a/net/bluetooth/hci_core.c b/net/bluetooth/hci_core.c
index c6cbe78e685f..32c0c2c58f66 100644
--- a/net/bluetooth/hci_core.c
+++ b/net/bluetooth/hci_core.c
@@ -702,6 +702,31 @@ static const struct file_operations force_static_address_fops = {
.llseek = default_llseek,
};
+static int white_list_show(struct seq_file *f, void *ptr)
+{
+ struct hci_dev *hdev = f->private;
+ struct bdaddr_list *b;
+
+ hci_dev_lock(hdev);
+ list_for_each_entry(b, &hdev->le_white_list, list)
+ seq_printf(f, "%pMR (type %u)\n", &b->bdaddr, b->bdaddr_type);
+ hci_dev_unlock(hdev);
+
+ return 0;
+}
+
+static int white_list_open(struct inode *inode, struct file *file)
+{
+ return single_open(file, white_list_show, inode->i_private);
+}
+
+static const struct file_operations white_list_fops = {
+ .open = white_list_open,
+ .read = seq_read,
+ .llseek = seq_lseek,
+ .release = single_release,
+};
+
static int identity_resolving_keys_show(struct seq_file *f, void *ptr)
{
struct hci_dev *hdev = f->private;
@@ -1786,6 +1811,8 @@ static int __hci_init(struct hci_dev *hdev)
debugfs_create_u8("white_list_size", 0444, hdev->debugfs,
&hdev->le_white_list_size);
+ debugfs_create_file("white_list", 0444, hdev->debugfs, hdev,
+ &white_list_fops);
debugfs_create_file("identity_resolving_keys", 0400,
hdev->debugfs, hdev,
&identity_resolving_keys_fops);
@@ -3293,6 +3320,67 @@ int hci_blacklist_del(struct hci_dev *hdev, bdaddr_t *bdaddr, u8 type)
return mgmt_device_unblocked(hdev, bdaddr, type);
}
+struct bdaddr_list *hci_white_list_lookup(struct hci_dev *hdev,
+ bdaddr_t *bdaddr, u8 type)
+{
+ struct bdaddr_list *b;
+
+ list_for_each_entry(b, &hdev->le_white_list, list) {
+ if (!bacmp(&b->bdaddr, bdaddr) && b->bdaddr_type == type)
+ return b;
+ }
+
+ return NULL;
+}
+
+void hci_white_list_clear(struct hci_dev *hdev)
+{
+ struct list_head *p, *n;
+
+ list_for_each_safe(p, n, &hdev->le_white_list) {
+ struct bdaddr_list *b = list_entry(p, struct bdaddr_list, list);
+
+ list_del(p);
+ kfree(b);
+ }
+}
+
+int hci_white_list_add(struct hci_dev *hdev, bdaddr_t *bdaddr, u8 type)
+{
+ struct bdaddr_list *entry;
+
+ if (!bacmp(bdaddr, BDADDR_ANY))
+ return -EBADF;
+
+ entry = kzalloc(sizeof(struct bdaddr_list), GFP_KERNEL);
+ if (!entry)
+ return -ENOMEM;
+
+ bacpy(&entry->bdaddr, bdaddr);
+ entry->bdaddr_type = type;
+
+ list_add(&entry->list, &hdev->le_white_list);
+
+ return 0;
+}
+
+int hci_white_list_del(struct hci_dev *hdev, bdaddr_t *bdaddr, u8 type)
+{
+ struct bdaddr_list *entry;
+
+ if (!bacmp(bdaddr, BDADDR_ANY))
+ return -EBADF;
+
+ entry = hci_white_list_lookup(hdev, bdaddr, type);
+ if (!entry)
+ return -ENOENT;
+
+ list_del(&entry->list);
+ kfree(entry);
+
+ return 0;
+}
+
/* This function requires the caller holds hdev->lock */
struct hci_conn_params *hci_conn_params_lookup(struct hci_dev *hdev,
bdaddr_t *addr, u8 addr_type)
@@ -3691,6 +3779,7 @@ struct hci_dev *hci_alloc_dev(void)
INIT_LIST_HEAD(&hdev->long_term_keys);
INIT_LIST_HEAD(&hdev->identity_resolving_keys);
INIT_LIST_HEAD(&hdev->remote_oob_data);
+ INIT_LIST_HEAD(&hdev->le_white_list);
INIT_LIST_HEAD(&hdev->le_conn_params);
INIT_LIST_HEAD(&hdev->pend_le_conns);
INIT_LIST_HEAD(&hdev->conn_hash.list);
@@ -3893,6 +3982,7 @@ void hci_unregister_dev(struct hci_dev *hdev)
hci_smp_ltks_clear(hdev);
hci_smp_irks_clear(hdev);
hci_remote_oob_data_clear(hdev);
+ hci_white_list_clear(hdev);
hci_conn_params_clear(hdev);
hci_pend_le_conns_clear(hdev);
hci_dev_unlock(hdev);
--
1.8.5.3
^ permalink raw reply related
* [PATCH 2/4] Bluetooth: Clear all LE white list entries when powering controller
From: Marcel Holtmann @ 2014-02-28 4:37 UTC (permalink / raw)
To: linux-bluetooth
When starting up a controller make sure that all LE white list entries
are cleared. Normally the HCI Reset takes care of this. This is just
in case no HCI Reset has been executed.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
---
net/bluetooth/hci_core.c | 7 +++++--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/net/bluetooth/hci_core.c b/net/bluetooth/hci_core.c
index b0aa4eaa4660..c6cbe78e685f 100644
--- a/net/bluetooth/hci_core.c
+++ b/net/bluetooth/hci_core.c
@@ -1346,14 +1346,17 @@ static void le_setup(struct hci_request *req)
/* Read LE Local Supported Features */
hci_req_add(req, HCI_OP_LE_READ_LOCAL_FEATURES, 0, NULL);
+ /* Read LE Supported States */
+ hci_req_add(req, HCI_OP_LE_READ_SUPPORTED_STATES, 0, NULL);
+
/* Read LE Advertising Channel TX Power */
hci_req_add(req, HCI_OP_LE_READ_ADV_TX_POWER, 0, NULL);
/* Read LE White List Size */
hci_req_add(req, HCI_OP_LE_READ_WHITE_LIST_SIZE, 0, NULL);
- /* Read LE Supported States */
- hci_req_add(req, HCI_OP_LE_READ_SUPPORTED_STATES, 0, NULL);
+ /* Clear LE White List */
+ hci_req_add(req, HCI_OP_LE_CLEAR_WHITE_LIST, 0, NULL);
/* LE-only controllers have LE implicitly enabled */
if (!lmp_bredr_capable(hdev))
--
1.8.5.3
^ permalink raw reply related
* [PATCH 1/4] Bluetooth: Add definitions for LE white list HCI commands
From: Marcel Holtmann @ 2014-02-28 4:37 UTC (permalink / raw)
To: linux-bluetooth
Add the definitions for clearing the LE white list, adding entries to
the LE white list and removing entries from the LE white list.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
---
include/net/bluetooth/hci.h | 14 ++++++++++++++
1 file changed, 14 insertions(+)
diff --git a/include/net/bluetooth/hci.h b/include/net/bluetooth/hci.h
index 4755a28ace85..0cedc92cda47 100644
--- a/include/net/bluetooth/hci.h
+++ b/include/net/bluetooth/hci.h
@@ -1205,6 +1205,20 @@ struct hci_rp_le_read_white_list_size {
__u8 size;
} __packed;
+#define HCI_OP_LE_CLEAR_WHITE_LIST 0x2010
+
+#define HCI_OP_LE_ADD_TO_WHITE_LIST 0x2011
+struct hci_cp_le_add_to_white_list {
+ __u8 bdaddr_type;
+ bdaddr_t bdaddr;
+} __packed;
+
+#define HCI_OP_LE_DEL_FROM_WHITE_LIST 0x2012
+struct hci_cp_le_del_from_white_list {
+ __u8 bdaddr_type;
+ bdaddr_t bdaddr;
+} __packed;
+
#define HCI_OP_LE_CONN_UPDATE 0x2013
struct hci_cp_le_conn_update {
__le16 handle;
--
1.8.5.3
^ permalink raw reply related
* [PATCH] Bluetooth: Make hci_blacklist_clear function static
From: Marcel Holtmann @ 2014-02-28 3:35 UTC (permalink / raw)
To: linux-bluetooth
The hci_blacklist_clear function is not used outside of hci_core.c and
can be made static.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
---
include/net/bluetooth/hci_core.h | 1 -
net/bluetooth/hci_core.c | 2 +-
2 files changed, 1 insertion(+), 2 deletions(-)
diff --git a/include/net/bluetooth/hci_core.h b/include/net/bluetooth/hci_core.h
index f1652430dee8..55ee2a5ca503 100644
--- a/include/net/bluetooth/hci_core.h
+++ b/include/net/bluetooth/hci_core.h
@@ -796,7 +796,6 @@ int hci_inquiry(void __user *arg);
struct bdaddr_list *hci_blacklist_lookup(struct hci_dev *hdev,
bdaddr_t *bdaddr, u8 type);
-void hci_blacklist_clear(struct hci_dev *hdev);
int hci_blacklist_add(struct hci_dev *hdev, bdaddr_t *bdaddr, u8 type);
int hci_blacklist_del(struct hci_dev *hdev, bdaddr_t *bdaddr, u8 type);
diff --git a/net/bluetooth/hci_core.c b/net/bluetooth/hci_core.c
index ba888e2ef39e..b0aa4eaa4660 100644
--- a/net/bluetooth/hci_core.c
+++ b/net/bluetooth/hci_core.c
@@ -3237,7 +3237,7 @@ struct bdaddr_list *hci_blacklist_lookup(struct hci_dev *hdev,
return NULL;
}
-void hci_blacklist_clear(struct hci_dev *hdev)
+static void hci_blacklist_clear(struct hci_dev *hdev)
{
struct list_head *p, *n;
--
1.8.5.3
^ permalink raw reply related
* Background scanning and white list usage
From: Marcel Holtmann @ 2014-02-28 3:20 UTC (permalink / raw)
To: linux-bluetooth
Hi Andre,
with the background scanning and auto-connect patches now merged, I want to move into the direction of utilizing the white list for background scanning.
For every devices where we have an auto-connect entry, the device should be placed into the white list. From our management side, it makes sense to only allow auto-connect entries for identity addresses (meaning public or static addresses).
If our identity addresses are not using LE Privacy this is pretty much straight forward. We just put the identity address into the white list and scan with the white list filter policy. This should be our first target. Start using the white list and populate it with our identity addresses.
The complicated part comes into play when we have devices with LE Privacy enabled and when they are using resolvable private addresses. Meaning when our IRK list is populated with identity addresses and their IRKs. The only way to make this work with the current available controller features is if we program the RPA into the white list. Since that RPA is going to change over time, we need to stop scanning with the white list filter every now and then, scan for all devices and resolve the RPA. If we see a new RPA for a know IRK, we have to replace the old RPA in the white list with the new RPA. And then we go back to scanning with the white list filter policy.
Now the important question is what are good enough intervals to make this work smoothly. Devices using LE Privacy will take a hit in their re-connection time, but that is what we have to trade in for compared to waking up the host for every single advertising packet.
My initial idea is to scan 5 minutes using the white list, then scan 10 seconds without the white list, then back to 5 minutes using the white list and so on.
The default value for the PRA lifetime according to the specification is 15 minutes. I timed recent iOS devices which seem to be using 9 minutes intervals. So we have to play a little bit with this and see what are good values.
Maybe 3 minutes white list scan and 5 seconds without white list is better. Things to try out.
First task now should be to track the white list inside the kernel. I want a debugfs entry that tells us exactly what devices are in the white list. And second step is to make sure that when adding devices with auto-connect enabled, they get added to the white list, same as they get removed when connected or no longer have auto-connect enabled.
Regards
Marcel
^ permalink raw reply
* [RFC] Bluetooth: Use __le64 type for LE random numbers
From: Marcel Holtmann @ 2014-02-28 0:00 UTC (permalink / raw)
To: linux-bluetooth
The random numbers in Bluetooth Low Energy are 64-bit numbers and should
also be little endian since the HCI specification is little endian.
Change the whole Low Energy pairing to use __le64 instead of a byte
array.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
---
include/net/bluetooth/hci.h | 4 ++--
include/net/bluetooth/hci_core.h | 8 ++++----
include/net/bluetooth/mgmt.h | 2 +-
net/bluetooth/hci_conn.c | 6 +++---
net/bluetooth/hci_core.c | 13 ++++++-------
net/bluetooth/hci_event.c | 2 +-
net/bluetooth/mgmt.c | 2 +-
net/bluetooth/smp.c | 22 ++++++++++------------
net/bluetooth/smp.h | 2 +-
9 files changed, 29 insertions(+), 32 deletions(-)
diff --git a/include/net/bluetooth/hci.h b/include/net/bluetooth/hci.h
index c3834d3aecbb..4755a28ace85 100644
--- a/include/net/bluetooth/hci.h
+++ b/include/net/bluetooth/hci.h
@@ -1219,7 +1219,7 @@ struct hci_cp_le_conn_update {
#define HCI_OP_LE_START_ENC 0x2019
struct hci_cp_le_start_enc {
__le16 handle;
- __u8 rand[8];
+ __le64 rand;
__le16 ediv;
__u8 ltk[16];
} __packed;
@@ -1631,7 +1631,7 @@ struct hci_ev_le_conn_complete {
#define HCI_EV_LE_LTK_REQ 0x05
struct hci_ev_le_ltk_req {
__le16 handle;
- __u8 random[8];
+ __le64 rand;
__le16 ediv;
} __packed;
diff --git a/include/net/bluetooth/hci_core.h b/include/net/bluetooth/hci_core.h
index 093d05eeb3fa..f1652430dee8 100644
--- a/include/net/bluetooth/hci_core.h
+++ b/include/net/bluetooth/hci_core.h
@@ -99,7 +99,7 @@ struct smp_ltk {
u8 type;
u8 enc_size;
__le16 ediv;
- u8 rand[8];
+ __le64 rand;
u8 val[16];
};
@@ -822,11 +822,11 @@ void hci_link_keys_clear(struct hci_dev *hdev);
struct link_key *hci_find_link_key(struct hci_dev *hdev, bdaddr_t *bdaddr);
int hci_add_link_key(struct hci_dev *hdev, struct hci_conn *conn, int new_key,
bdaddr_t *bdaddr, u8 *val, u8 type, u8 pin_len);
-struct smp_ltk *hci_find_ltk(struct hci_dev *hdev, __le16 ediv, u8 rand[8],
+struct smp_ltk *hci_find_ltk(struct hci_dev *hdev, __le16 ediv, __le64 rand,
bool master);
struct smp_ltk *hci_add_ltk(struct hci_dev *hdev, bdaddr_t *bdaddr,
u8 addr_type, u8 type, u8 authenticated,
- u8 tk[16], u8 enc_size, __le16 ediv, u8 rand[8]);
+ u8 tk[16], u8 enc_size, __le16 ediv, __le64 rand);
struct smp_ltk *hci_find_ltk_by_addr(struct hci_dev *hdev, bdaddr_t *bdaddr,
u8 addr_type, bool master);
int hci_remove_ltk(struct hci_dev *hdev, bdaddr_t *bdaddr, u8 bdaddr_type);
@@ -1287,7 +1287,7 @@ struct hci_sec_filter {
void hci_le_conn_update(struct hci_conn *conn, u16 min, u16 max,
u16 latency, u16 to_multiplier);
-void hci_le_start_enc(struct hci_conn *conn, __le16 ediv, __u8 rand[8],
+void hci_le_start_enc(struct hci_conn *conn, __le16 ediv, __le64 rand,
__u8 ltk[16]);
int hci_update_random_address(struct hci_request *req, bool require_privacy,
diff --git a/include/net/bluetooth/mgmt.h b/include/net/bluetooth/mgmt.h
index 62d560624e3d..0326648fd799 100644
--- a/include/net/bluetooth/mgmt.h
+++ b/include/net/bluetooth/mgmt.h
@@ -187,7 +187,7 @@ struct mgmt_ltk_info {
__u8 master;
__u8 enc_size;
__le16 ediv;
- __u8 rand[8];
+ __le64 rand;
__u8 val[16];
} __packed;
diff --git a/net/bluetooth/hci_conn.c b/net/bluetooth/hci_conn.c
index 7d6f05e3cae8..5b0802994cbb 100644
--- a/net/bluetooth/hci_conn.c
+++ b/net/bluetooth/hci_conn.c
@@ -231,7 +231,7 @@ void hci_le_conn_update(struct hci_conn *conn, u16 min, u16 max,
hci_send_cmd(hdev, HCI_OP_LE_CONN_UPDATE, sizeof(cp), &cp);
}
-void hci_le_start_enc(struct hci_conn *conn, __le16 ediv, __u8 rand[8],
+void hci_le_start_enc(struct hci_conn *conn, __le16 ediv, __le64 rand,
__u8 ltk[16])
{
struct hci_dev *hdev = conn->hdev;
@@ -242,9 +242,9 @@ void hci_le_start_enc(struct hci_conn *conn, __le16 ediv, __u8 rand[8],
memset(&cp, 0, sizeof(cp));
cp.handle = cpu_to_le16(conn->handle);
- memcpy(cp.ltk, ltk, sizeof(cp.ltk));
+ cp.rand = rand;
cp.ediv = ediv;
- memcpy(cp.rand, rand, sizeof(cp.rand));
+ memcpy(cp.ltk, ltk, sizeof(cp.ltk));
hci_send_cmd(hdev, HCI_OP_LE_START_ENC, sizeof(cp), &cp);
}
diff --git a/net/bluetooth/hci_core.c b/net/bluetooth/hci_core.c
index 7113d4cc085f..ba888e2ef39e 100644
--- a/net/bluetooth/hci_core.c
+++ b/net/bluetooth/hci_core.c
@@ -740,10 +740,10 @@ static int long_term_keys_show(struct seq_file *f, void *ptr)
hci_dev_lock(hdev);
list_for_each_safe(p, n, &hdev->long_term_keys) {
struct smp_ltk *ltk = list_entry(p, struct smp_ltk, list);
- seq_printf(f, "%pMR (type %u) %u 0x%02x %u %.4x %*phN %*phN\n",
+ seq_printf(f, "%pMR (type %u) %u 0x%02x %u %.4x %.16llx %*phN\n",
<k->bdaddr, ltk->bdaddr_type, ltk->authenticated,
ltk->type, ltk->enc_size, __le16_to_cpu(ltk->ediv),
- 8, ltk->rand, 16, ltk->val);
+ __le64_to_cpu(ltk->rand), 16, ltk->val);
}
hci_dev_unlock(hdev);
@@ -2891,14 +2891,13 @@ static bool ltk_type_master(u8 type)
return false;
}
-struct smp_ltk *hci_find_ltk(struct hci_dev *hdev, __le16 ediv, u8 rand[8],
+struct smp_ltk *hci_find_ltk(struct hci_dev *hdev, __le16 ediv, __le64 rand,
bool master)
{
struct smp_ltk *k;
list_for_each_entry(k, &hdev->long_term_keys, list) {
- if (k->ediv != ediv ||
- memcmp(rand, k->rand, sizeof(k->rand)))
+ if (k->ediv != ediv || k->rand != rand)
continue;
if (ltk_type_master(k->type) != master)
@@ -3016,7 +3015,7 @@ int hci_add_link_key(struct hci_dev *hdev, struct hci_conn *conn, int new_key,
struct smp_ltk *hci_add_ltk(struct hci_dev *hdev, bdaddr_t *bdaddr,
u8 addr_type, u8 type, u8 authenticated,
- u8 tk[16], u8 enc_size, __le16 ediv, u8 rand[8])
+ u8 tk[16], u8 enc_size, __le16 ediv, __le64 rand)
{
struct smp_ltk *key, *old_key;
bool master = ltk_type_master(type);
@@ -3036,9 +3035,9 @@ struct smp_ltk *hci_add_ltk(struct hci_dev *hdev, bdaddr_t *bdaddr,
memcpy(key->val, tk, sizeof(key->val));
key->authenticated = authenticated;
key->ediv = ediv;
+ key->rand = rand;
key->enc_size = enc_size;
key->type = type;
- memcpy(key->rand, rand, sizeof(key->rand));
return key;
}
diff --git a/net/bluetooth/hci_event.c b/net/bluetooth/hci_event.c
index 162235633bf5..40e5bfebb484 100644
--- a/net/bluetooth/hci_event.c
+++ b/net/bluetooth/hci_event.c
@@ -3788,7 +3788,7 @@ static void hci_le_ltk_request_evt(struct hci_dev *hdev, struct sk_buff *skb)
if (conn == NULL)
goto not_found;
- ltk = hci_find_ltk(hdev, ev->ediv, ev->random, conn->out);
+ ltk = hci_find_ltk(hdev, ev->ediv, ev->rand, conn->out);
if (ltk == NULL)
goto not_found;
diff --git a/net/bluetooth/mgmt.c b/net/bluetooth/mgmt.c
index 78ac7c864044..a271c482ecdc 100644
--- a/net/bluetooth/mgmt.c
+++ b/net/bluetooth/mgmt.c
@@ -4995,11 +4995,11 @@ void mgmt_new_ltk(struct hci_dev *hdev, struct smp_ltk *key)
ev.key.type = key->authenticated;
ev.key.enc_size = key->enc_size;
ev.key.ediv = key->ediv;
+ ev.key.rand = key->rand;
if (key->type == HCI_SMP_LTK)
ev.key.master = 1;
- memcpy(ev.key.rand, key->rand, sizeof(key->rand));
memcpy(ev.key.val, key->val, sizeof(key->val));
mgmt_event(MGMT_EV_NEW_LONG_TERM_KEY, hdev, &ev, sizeof(ev), NULL);
diff --git a/net/bluetooth/smp.c b/net/bluetooth/smp.c
index 0de98fe23330..6ace0b48dc6a 100644
--- a/net/bluetooth/smp.c
+++ b/net/bluetooth/smp.c
@@ -517,11 +517,9 @@ static void random_work(struct work_struct *work)
}
if (hcon->out) {
- u8 stk[16], rand[8];
- __le16 ediv;
-
- memset(rand, 0, sizeof(rand));
- ediv = 0;
+ u8 stk[16];
+ __le64 rand = 0;
+ __le16 ediv = 0;
smp_s1(tfm, smp->tk, smp->rrnd, smp->prnd, key);
swap128(key, stk);
@@ -537,11 +535,9 @@ static void random_work(struct work_struct *work)
hci_le_start_enc(hcon, ediv, rand, stk);
hcon->enc_key_size = smp->enc_key_size;
} else {
- u8 stk[16], r[16], rand[8];
- __le16 ediv;
-
- memset(rand, 0, sizeof(rand));
- ediv = 0;
+ u8 stk[16], r[16];
+ __le16 rand = 0;
+ __le16 ediv = 0;
swap128(smp->prnd, r);
smp_send_cmd(conn, SMP_CMD_PAIRING_RANDOM, sizeof(r), r);
@@ -1205,20 +1201,22 @@ int smp_distribute_keys(struct l2cap_conn *conn)
struct smp_ltk *ltk;
u8 authenticated;
__le16 ediv;
+ __le64 rand;
get_random_bytes(enc.ltk, sizeof(enc.ltk));
get_random_bytes(&ediv, sizeof(ediv));
- get_random_bytes(ident.rand, sizeof(ident.rand));
+ get_random_bytes(&rand, sizeof(rand));
smp_send_cmd(conn, SMP_CMD_ENCRYPT_INFO, sizeof(enc), &enc);
authenticated = hcon->sec_level == BT_SECURITY_HIGH;
ltk = hci_add_ltk(hdev, &hcon->dst, hcon->dst_type,
HCI_SMP_LTK_SLAVE, authenticated, enc.ltk,
- smp->enc_key_size, ediv, ident.rand);
+ smp->enc_key_size, ediv, rand);
smp->slave_ltk = ltk;
ident.ediv = ediv;
+ ident.rand = rand;
smp_send_cmd(conn, SMP_CMD_MASTER_IDENT, sizeof(ident), &ident);
diff --git a/net/bluetooth/smp.h b/net/bluetooth/smp.h
index 1b8af35b292c..a11d4281542c 100644
--- a/net/bluetooth/smp.h
+++ b/net/bluetooth/smp.h
@@ -78,7 +78,7 @@ struct smp_cmd_encrypt_info {
#define SMP_CMD_MASTER_IDENT 0x07
struct smp_cmd_master_ident {
__le16 ediv;
- __u8 rand[8];
+ __le64 rand;
} __packed;
#define SMP_CMD_IDENT_INFO 0x08
--
1.8.5.3
^ permalink raw reply related
* Re: [PATCH] bluetooth: ath3k: added Atheros AR3012 with ID 0x0b05:0x17d0
From: Marcel Holtmann @ 2014-02-27 23:19 UTC (permalink / raw)
To: Bela Hausmann; +Cc: linux-bluetooth
In-Reply-To: <530FC224.90305@gmail.com>
Hi Bela,
> Hi Marcel,
>
> sorry for the messed up tabs.
>
> Here is /sys/kernel/debug/usb/devices:
> T: Bus=02 Lev=02 Prnt=02 Port=03 Cnt=02 Dev#= 4 Spd=12 MxCh= 0
> D: Ver= 1.10 Cls=e0(wlcon) Sub=01 Prot=01 MxPS=64 #Cfgs= 1
> P: Vendor=0b05 ProdID=17d0 Rev= 0.02
> C:* #Ifs= 2 Cfg#= 1 Atr=e0 MxPwr=100mA
> I:* If#= 0 Alt= 0 #EPs= 3 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
> E: Ad=81(I) Atr=03(Int.) MxPS= 16 Ivl=1ms
> E: Ad=82(I) Atr=02(Bulk) MxPS= 64 Ivl=0ms
> E: Ad=02(O) Atr=02(Bulk) MxPS= 64 Ivl=0ms
> I:* If#= 1 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
> E: Ad=83(I) Atr=01(Isoc) MxPS= 0 Ivl=1ms
> E: Ad=03(O) Atr=01(Isoc) MxPS= 0 Ivl=1ms
> I: If#= 1 Alt= 1 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
> E: Ad=83(I) Atr=01(Isoc) MxPS= 9 Ivl=1ms
> E: Ad=03(O) Atr=01(Isoc) MxPS= 9 Ivl=1ms
> I: If#= 1 Alt= 2 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
> E: Ad=83(I) Atr=01(Isoc) MxPS= 17 Ivl=1ms
> E: Ad=03(O) Atr=01(Isoc) MxPS= 17 Ivl=1ms
> I: If#= 1 Alt= 3 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
> E: Ad=83(I) Atr=01(Isoc) MxPS= 25 Ivl=1ms
> E: Ad=03(O) Atr=01(Isoc) MxPS= 25 Ivl=1ms
> I: If#= 1 Alt= 4 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
> E: Ad=83(I) Atr=01(Isoc) MxPS= 33 Ivl=1ms
> E: Ad=03(O) Atr=01(Isoc) MxPS= 33 Ivl=1ms
> I: If#= 1 Alt= 5 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
> E: Ad=83(I) Atr=01(Isoc) MxPS= 49 Ivl=1ms
> E: Ad=03(O) Atr=01(Isoc) MxPS= 49 Ivl=1ms
>
> An again the patch.
>
> Best wishes,
> Bela
why don’t you use git-format-patch and git-send-email. Just save the email you send as raw text and see what happens if you apply it with git-am and then look at git-log.
Regards
Marcel
^ permalink raw reply
* Re: [PATCH] bluetooth: ath3k: added Atheros AR3012 with ID 0x0b05:0x17d0
From: Bela Hausmann @ 2014-02-27 22:54 UTC (permalink / raw)
To: Marcel Holtmann; +Cc: linux-bluetooth
In-Reply-To: <613439C8-AFCE-4B23-81FE-AD4B91A27768@holtmann.org>
Hi Marcel,
sorry for the messed up tabs.
Here is /sys/kernel/debug/usb/devices:
T: Bus=02 Lev=02 Prnt=02 Port=03 Cnt=02 Dev#= 4 Spd=12 MxCh= 0
D: Ver= 1.10 Cls=e0(wlcon) Sub=01 Prot=01 MxPS=64 #Cfgs= 1
P: Vendor=0b05 ProdID=17d0 Rev= 0.02
C:* #Ifs= 2 Cfg#= 1 Atr=e0 MxPwr=100mA
I:* If#= 0 Alt= 0 #EPs= 3 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E: Ad=81(I) Atr=03(Int.) MxPS= 16 Ivl=1ms
E: Ad=82(I) Atr=02(Bulk) MxPS= 64 Ivl=0ms
E: Ad=02(O) Atr=02(Bulk) MxPS= 64 Ivl=0ms
I:* If#= 1 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E: Ad=83(I) Atr=01(Isoc) MxPS= 0 Ivl=1ms
E: Ad=03(O) Atr=01(Isoc) MxPS= 0 Ivl=1ms
I: If#= 1 Alt= 1 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E: Ad=83(I) Atr=01(Isoc) MxPS= 9 Ivl=1ms
E: Ad=03(O) Atr=01(Isoc) MxPS= 9 Ivl=1ms
I: If#= 1 Alt= 2 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E: Ad=83(I) Atr=01(Isoc) MxPS= 17 Ivl=1ms
E: Ad=03(O) Atr=01(Isoc) MxPS= 17 Ivl=1ms
I: If#= 1 Alt= 3 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E: Ad=83(I) Atr=01(Isoc) MxPS= 25 Ivl=1ms
E: Ad=03(O) Atr=01(Isoc) MxPS= 25 Ivl=1ms
I: If#= 1 Alt= 4 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E: Ad=83(I) Atr=01(Isoc) MxPS= 33 Ivl=1ms
E: Ad=03(O) Atr=01(Isoc) MxPS= 33 Ivl=1ms
I: If#= 1 Alt= 5 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E: Ad=83(I) Atr=01(Isoc) MxPS= 49 Ivl=1ms
E: Ad=03(O) Atr=01(Isoc) MxPS= 49 Ivl=1ms
An again the patch.
Best wishes,
Bela
This adds support for the Atheros AR3012 chipset on the ASUS Z87-Pro (C2) mainboard (ID 0x0b05:0x17d0).
Signed-off-by: Bela Hausmann <bela.hausmann@gmail.com>
---
diff -uprN -X linux-3.13.5-gentoo/Documentation/dontdiff linux-3.13.5-gentoo/drivers/bluetooth/ath3k.c linux-3.13.5-gentoo-bela/drivers/bluetooth/ath3k.c
--- linux-3.13.5-gentoo/drivers/bluetooth/ath3k.c 2014-01-20 03:40:07.000000000 +0100
+++ linux-3.13.5-gentoo-bela/drivers/bluetooth/ath3k.c 2014-02-27 20:09:33.047878117 +0100
@@ -97,6 +97,7 @@ static const struct usb_device_id ath3k_
{ USB_DEVICE(0x13d3, 0x3402) },
{ USB_DEVICE(0x0cf3, 0x3121) },
{ USB_DEVICE(0x0cf3, 0xe003) },
+ { USB_DEVICE(0x0b05, 0x17d0) },
/* Atheros AR5BBU12 with sflash firmware */
{ USB_DEVICE(0x0489, 0xE02C) },
@@ -140,6 +141,7 @@ static const struct usb_device_id ath3k_
{ USB_DEVICE(0x13d3, 0x3402), .driver_info = BTUSB_ATH3012 },
{ USB_DEVICE(0x0cf3, 0x3121), .driver_info = BTUSB_ATH3012 },
{ USB_DEVICE(0x0cf3, 0xe003), .driver_info = BTUSB_ATH3012 },
+ { USB_DEVICE(0x0b05, 0x17d0), .driver_info = BTUSB_ATH3012 },
/* Atheros AR5BBU22 with sflash firmware */
{ USB_DEVICE(0x0489, 0xE03C), .driver_info = BTUSB_ATH3012 },
diff -uprN -X linux-3.13.5-gentoo/Documentation/dontdiff linux-3.13.5-gentoo/drivers/bluetooth/btusb.c linux-3.13.5-gentoo-bela/drivers/bluetooth/btusb.c
--- linux-3.13.5-gentoo/drivers/bluetooth/btusb.c 2014-01-20 03:40:07.000000000 +0100
+++ linux-3.13.5-gentoo-bela/drivers/bluetooth/btusb.c 2014-02-27 20:10:20.825905643 +0100
@@ -164,6 +164,7 @@ static const struct usb_device_id blackl
{ USB_DEVICE(0x13d3, 0x3402), .driver_info = BTUSB_ATH3012 },
{ USB_DEVICE(0x0cf3, 0x3121), .driver_info = BTUSB_ATH3012 },
{ USB_DEVICE(0x0cf3, 0xe003), .driver_info = BTUSB_ATH3012 },
+ { USB_DEVICE(0x0b05, 0x17d0), .driver_info = BTUSB_ATH3012 },
/* Atheros AR5BBU12 with sflash firmware */
{ USB_DEVICE(0x0489, 0xe02c), .driver_info = BTUSB_IGNORE },
On 27/02/14 23:43, Marcel Holtmann wrote:
> Hi Bela,
>
>> This adds support for the Atheros AR3012 chipset on the ASUS Z87-Pro (C2) mainboard (ID 0x0b05:0x17d0).
>
> include the content of /sys/kernel/debug/usb/devices for this controller.
>
>>
>> Signed-off-by: Bela Hausmann <bela.hausmann@gmail.com>
>> ---
>> diff -uprN -X linux-3.13.5-gentoo/Documentation/dontdiff linux-3.13.5-gentoo/drivers/bluetooth/ath3k.c linux-3.13.5-gentoo-bela/drivers/bluetooth/ath3k.c
>> --- linux-3.13.5-gentoo/drivers/bluetooth/ath3k.c 2014-01-20 03:40:07.000000000 +0100
>> +++ linux-3.13.5-gentoo-bela/drivers/bluetooth/ath3k.c 2014-02-27 20:09:33.047878117 +0100
>> @@ -97,6 +97,7 @@ static const struct usb_device_id ath3k_
>> { USB_DEVICE(0x13d3, 0x3402) },
>> { USB_DEVICE(0x0cf3, 0x3121) },
>> { USB_DEVICE(0x0cf3, 0xe003) },
>> + { USB_DEVICE(0x0b05, 0x17d0) },
>
> Make sure that you email client does not screw up tabs. This looks pretty much like it is messed up.
>
> Regards
>
> Marcel
>
>
^ permalink raw reply
* Re: [PATCH] bluetooth: ath3k: added Atheros AR3012 with ID 0x0b05:0x17d0
From: Marcel Holtmann @ 2014-02-27 22:43 UTC (permalink / raw)
To: Bela Hausmann; +Cc: linux-bluetooth
In-Reply-To: <530FB0CA.4070309@gmail.com>
Hi Bela,
> This adds support for the Atheros AR3012 chipset on the ASUS Z87-Pro (C2) mainboard (ID 0x0b05:0x17d0).
include the content of /sys/kernel/debug/usb/devices for this controller.
>
> Signed-off-by: Bela Hausmann <bela.hausmann@gmail.com>
> ---
> diff -uprN -X linux-3.13.5-gentoo/Documentation/dontdiff linux-3.13.5-gentoo/drivers/bluetooth/ath3k.c linux-3.13.5-gentoo-bela/drivers/bluetooth/ath3k.c
> --- linux-3.13.5-gentoo/drivers/bluetooth/ath3k.c 2014-01-20 03:40:07.000000000 +0100
> +++ linux-3.13.5-gentoo-bela/drivers/bluetooth/ath3k.c 2014-02-27 20:09:33.047878117 +0100
> @@ -97,6 +97,7 @@ static const struct usb_device_id ath3k_
> { USB_DEVICE(0x13d3, 0x3402) },
> { USB_DEVICE(0x0cf3, 0x3121) },
> { USB_DEVICE(0x0cf3, 0xe003) },
> + { USB_DEVICE(0x0b05, 0x17d0) },
Make sure that you email client does not screw up tabs. This looks pretty much like it is messed up.
Regards
Marcel
^ permalink raw reply
* [bluez-5.14] connect fails with 'org.bluez.Error.NotAvailable'
From: Tobias Jakobi @ 2014-02-27 22:25 UTC (permalink / raw)
To: linux-bluetooth
Hello,
I'm trying to establish a BT connection between two systems. The client
is running bluez-5.14 and I'm using bluetoothctl to interface with the
daemon.
The server system provides a NAP, plus dnsmasq, so that connecting
clients receive an IP. For reference, this works perfectly on an Android
smartphone. When connecting to the server system, the bnep device is
created on the server and added to the bridge. The Android bluetooth
stack then gets an IP via dnsmasq and voila... TCP/IP connection.
On this client however, this doesn't work at all. Plus, I'm not getting
any kind of meaningful error message.
That's the server:
[bluetooth]# info 00:02:72:C6:43:11
Device 00:02:72:C6:43:11
Name: chidori-bt
Alias: chidori-bt
Class: 0x020000
Paired: yes
Trusted: yes
Blocked: no
Connected: no
LegacyPairing: no
UUID: A/V Remote Control Target (0000110c-0000-1000-8000-00805f9b34fb)
UUID: A/V Remote Control (0000110e-0000-1000-8000-00805f9b34fb)
UUID: NAP (00001116-0000-1000-8000-00805f9b34fb)
UUID: PnP Information (00001200-0000-1000-8000-00805f9b34fb)
UUID: Generic Access Profile (00001800-0000-1000-8000-00805f9b34fb)
UUID: Generic Attribute Profile (00001801-0000-1000-8000-00805f9b34fb)
Modalias: usb:v1D6Bp0246d0509
And here's how connecting goes:
[bluetooth]# connect 00:02:72:C6:43:11
Attempting to connect to 00:02:72:C6:43:11
[CHG] Device 00:02:72:C6:43:11 Connected: yes
[CHG] Device 00:02:72:C6:43:11 Modalias: usb:v1D6Bp0246d0509
Failed to connect: org.bluez.Error.NotAvailable
[CHG] Device 00:02:72:C6:43:11 Connected: no
So, it looks like that it briefly connect, but then drops the connection
again. I haven't been able to figure out what exaclty is 'NotAvailable'
at this moment. The server at least is.
This is something from the bt daemon (client):
leena bluetoothd[26910]: Bluetooth daemon 5.14
leena bluetoothd[26910]: Starting SDP server
leena bluetoothd[26910]: Bluetooth management interface 1.3 initialized
leena bluetoothd[26910]: Sap driver initialization failed.
leena bluetoothd[26910]: sap-server: Operation not permitted (1)
leena bluetoothd[26910]: Can't add /org/bluez/hci0/dev_00_02_72_C6_43_11
to non-LE capable adapter connect list
I'm not sure if the 'non-LE' message has something to do with the issue.
Any idea on how to proceed here?
Greets,
Tobias
PS: More info:
[bluetooth]# show
Controller B4:82:FE:65:22:8E
Name: leena-bt
Alias: leena-bt
Class: 0x00010c
Powered: yes
Discoverable: no
Pairable: yes
UUID: PnP Information (00001200-0000-1000-8000-00805f9b34fb)
UUID: Generic Access Profile (00001800-0000-1000-8000-00805f9b34fb)
UUID: Generic Attribute Profile (00001801-0000-1000-8000-00805f9b34fb)
UUID: A/V Remote Control (0000110e-0000-1000-8000-00805f9b34fb)
UUID: A/V Remote Control Target (0000110c-0000-1000-8000-00805f9b34fb)
Modalias: usb:v1D6Bp0246d050E
Discovering: no
^ permalink raw reply
* Re: [PATCH BlueZ v7 07/11] gatt: Add external services tracking
From: Claudio Takahasi @ 2014-02-27 21:47 UTC (permalink / raw)
To: Anderson Lizardo, Johan Hedberg; +Cc: BlueZ development, Claudio Takahasi
In-Reply-To: <20140225062656.GA3288@localhost.P-661HNU-F1>
Hi Johan/Lizardo:
On Tue, Feb 25, 2014 at 3:26 AM, Johan Hedberg <johan.hedberg@gmail.com> wrote:
> Hi Lizardo,
>
> On Mon, Feb 24, 2014, Anderson Lizardo wrote:
>> On Mon, Feb 24, 2014 at 8:49 AM, Anderson Lizardo
>> <anderson.lizardo@openbossa.org> wrote:
>> > Hi Johan,
>> >
>> > On Mon, Feb 24, 2014 at 4:33 AM, Johan Hedberg <johan.hedberg@gmail.com> wrote:
>> >> This whole timer thing seems too hackish to me.
>> >>
>> >> A better way to fix this might be to have something like
>> >> g_dbus_client_set_proxies_complete_watch (or some better name) to let
>> >> the code wait until GetManagedObjects has returned and the initial
>> >> proxies added. Do you agree?
>> >
>> > We came up with this workaround during development, but we forgot to
>> > highlight on the cover letter. Indeed a function like the one you
>> > propose should be enough.
>> >
>> > Regarding the name for the function, I was thinking as
>> > "g_dbus_client_proxies_ready_watch()". What do you think?
>>
>> Or "g_dbus_client_set_proxies_ready_watch()" to be consistent.
>
> That sounds good enough to me.
>
> Johan
I spent some time investigating (and prototyping) alternatives to
avoid inserting a new gdbus helper, but all of them have drawbacks.
Even using DBus properties (without object manager) extending the
RegisterService() method to include an array of the object paths in
the options doesn't help. New proxies/properties are reported
individually through callbacks, consequently extra logic is required
in the "gdbus user" to detect when all objects are "received" and to
validate each object. Another issue of using property "watch" is to
manage when it first appeared and when it is property changed.
*Maybe* foreach helper plus the "ready" callback is another acceptable approach.
Keeping the object manager approach, what we need is way to figure out
if proxy_added is reporting the "last" proxy, otherwise timer is still
needed.
So, the proposed ready callback should be called after reporting the
last proxy. I will implement the suggested helper
(g_dbus_client_set_proxies_ready_watch) and see how far we go.
Regards,
Claudio.
^ permalink raw reply
* [PATCH] bluetooth: ath3k: added Atheros AR3012 with ID 0x0b05:0x17d0
From: Bela Hausmann @ 2014-02-27 21:40 UTC (permalink / raw)
To: linux-bluetooth
This adds support for the Atheros AR3012 chipset on the ASUS Z87-Pro (C2) mainboard (ID 0x0b05:0x17d0).
Signed-off-by: Bela Hausmann <bela.hausmann@gmail.com>
---
diff -uprN -X linux-3.13.5-gentoo/Documentation/dontdiff linux-3.13.5-gentoo/drivers/bluetooth/ath3k.c linux-3.13.5-gentoo-bela/drivers/bluetooth/ath3k.c
--- linux-3.13.5-gentoo/drivers/bluetooth/ath3k.c 2014-01-20 03:40:07.000000000 +0100
+++ linux-3.13.5-gentoo-bela/drivers/bluetooth/ath3k.c 2014-02-27 20:09:33.047878117 +0100
@@ -97,6 +97,7 @@ static const struct usb_device_id ath3k_
{ USB_DEVICE(0x13d3, 0x3402) },
{ USB_DEVICE(0x0cf3, 0x3121) },
{ USB_DEVICE(0x0cf3, 0xe003) },
+ { USB_DEVICE(0x0b05, 0x17d0) },
/* Atheros AR5BBU12 with sflash firmware */
{ USB_DEVICE(0x0489, 0xE02C) },
@@ -140,6 +141,7 @@ static const struct usb_device_id ath3k_
{ USB_DEVICE(0x13d3, 0x3402), .driver_info = BTUSB_ATH3012 },
{ USB_DEVICE(0x0cf3, 0x3121), .driver_info = BTUSB_ATH3012 },
{ USB_DEVICE(0x0cf3, 0xe003), .driver_info = BTUSB_ATH3012 },
+ { USB_DEVICE(0x0b05, 0x17d0), .driver_info = BTUSB_ATH3012 },
/* Atheros AR5BBU22 with sflash firmware */
{ USB_DEVICE(0x0489, 0xE03C), .driver_info = BTUSB_ATH3012 },
diff -uprN -X linux-3.13.5-gentoo/Documentation/dontdiff linux-3.13.5-gentoo/drivers/bluetooth/btusb.c linux-3.13.5-gentoo-bela/drivers/bluetooth/btusb.c
--- linux-3.13.5-gentoo/drivers/bluetooth/btusb.c 2014-01-20 03:40:07.000000000 +0100
+++ linux-3.13.5-gentoo-bela/drivers/bluetooth/btusb.c 2014-02-27 20:10:20.825905643 +0100
@@ -164,6 +164,7 @@ static const struct usb_device_id blackl
{ USB_DEVICE(0x13d3, 0x3402), .driver_info = BTUSB_ATH3012 },
{ USB_DEVICE(0x0cf3, 0x3121), .driver_info = BTUSB_ATH3012 },
{ USB_DEVICE(0x0cf3, 0xe003), .driver_info = BTUSB_ATH3012 },
+ { USB_DEVICE(0x0b05, 0x17d0), .driver_info = BTUSB_ATH3012 },
/* Atheros AR5BBU12 with sflash firmware */
{ USB_DEVICE(0x0489, 0xe02c), .driver_info = BTUSB_IGNORE },
^ permalink raw reply
* Re: [PATCH 00/13] Android HAL GATT Server API Commands
From: Szymon Janc @ 2014-02-27 21:16 UTC (permalink / raw)
To: Grzegorz Kolodziejczyk; +Cc: linux-bluetooth
In-Reply-To: <1393507731-1974-1-git-send-email-grzegorz.kolodziejczyk@tieto.com>
Hi Grzegorz,
On Thursday 27 February 2014 14:28:38 Grzegorz Kolodziejczyk wrote:
> This serie of hal-gatt-api patches updates hal-ipc-api document and
> hal-msg header in parallel. Should be applied on top of GATT client
> patches.
>
> Grzegorz Kolodziejczyk (13):
> android/hal-gatt-api: Add Server Register
> android/hal-gatt-api: Add Server Unregister
> android/hal-gatt-api: Add Server Connect
> android/hal-gatt-api: Add Server Disconnect
> android/hal-gatt-api: Add Server Service
> android/hal-gatt-api: Add Server Included Service
> android/hal-gatt-api: Add Server Characteristic
> android/hal-gatt-api: Add Server Descriptor
> android/hal-gatt-api: Add Server Start Service
> android/hal-gatt-api: Add Server Stop Service
> android/hal-gatt-api: Add Server Delete Service
> android/hal-gatt-api: Add Server Send Indication
> android/hal-gatt-api: Add Server Send Response
>
> android/hal-ipc-api.txt | 119
> ++++++++++++++++++++++++++++++++++++++++++++++++ android/hal-msg.h |
> 93 +++++++++++++++++++++++++++++++++++++ 2 files changed, 212 insertions(+)
All patches applied, thanks.
--
Szymon K. Janc
szymon.janc@gmail.com
^ 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