* Re: [PATCH] Bluetooth: allocate static minor for vhci
From: Lucas De Marchi @ 2014-02-17 19:01 UTC (permalink / raw)
To: Marcel Holtmann
Cc: Lucas De Marchi,
bluez mailin list (linux-bluetooth@vger.kernel.org), kay.sievers,
gregkh
In-Reply-To: <6D43DF5A-CFA0-4867-8518-ECDA167BDB71@holtmann.org>
[ CC'ing Kay and Greg ]
On Mon, Feb 17, 2014 at 08:34:32AM -0800, Marcel Holtmann wrote:
> Hi Lucas,
>
> > Commit bfacbb9 (Bluetooth: Use devname:vhci module alias for virtual HCI
> > driver) added the module alias to hci_vhci module so it's possible to
> > create the /dev/vhci node. However creating an alias without
> > specifying the minor doesn't allow us to create the node ahead,
> > triggerring module auto-load when it's first accessed.
> >
> > Starting with depmod from kmod 16 we started to warn if there's a
> > devname alias without specifying the major and minor.
> >
> > Let's do the same done for uhid, kvm, fuse and others, specifying a
> > fixed minor. In systems with systemd as the init the following will
> > happen: on early boot systemd will call "kmod static-nodes" to read
> > /lib/modules/$(uname -r)/modules.devname and then create the nodes. When
> > first accessed these "dead" nodes will trigger the module loading.
> >
> > Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
> > ---
> > drivers/bluetooth/hci_vhci.c | 3 ++-
> > include/linux/miscdevice.h | 1 +
> > 2 files changed, 3 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/bluetooth/hci_vhci.c b/drivers/bluetooth/hci_vhci.c
> > index 1ef6990..add1c6a 100644
> > --- a/drivers/bluetooth/hci_vhci.c
> > +++ b/drivers/bluetooth/hci_vhci.c
> > @@ -359,7 +359,7 @@ static const struct file_operations vhci_fops = {
> > static struct miscdevice vhci_miscdev= {
> > .name = "vhci",
> > .fops = &vhci_fops,
> > - .minor = MISC_DYNAMIC_MINOR,
> > + .minor = VHCI_MINOR,
> > };
> >
> > static int __init vhci_init(void)
> > @@ -385,3 +385,4 @@ MODULE_DESCRIPTION("Bluetooth virtual HCI driver ver " VERSION);
> > MODULE_VERSION(VERSION);
> > MODULE_LICENSE("GPL");
> > MODULE_ALIAS("devname:vhci");
> > +MODULE_ALIAS_MISCDEV(VHCI_MINOR);
> > diff --git a/include/linux/miscdevice.h b/include/linux/miscdevice.h
> > index 3737f72..846a317 100644
> > --- a/include/linux/miscdevice.h
> > +++ b/include/linux/miscdevice.h
> > @@ -48,6 +48,7 @@
> > #define LOOP_CTRL_MINOR 237
> > #define VHOST_NET_MINOR 238
> > #define UHID_MINOR 239
> > +#define VHCI_MINOR 240
> > #define MISC_DYNAMIC_MINOR 255
>
> you have read Documentation/devices.txt where it states that 240-254 is reserved for local use.
I haven't seen that. So, are we out of minors or.. can I use e.g.
142, 129 or the ones below 128?
Kay? Greg?
--
Lucas De Marchi
^ permalink raw reply
* [RFC v6] doc: Add management commands and events for privacy support
From: Marcel Holtmann @ 2014-02-17 17:59 UTC (permalink / raw)
To: linux-bluetooth
---
doc/mgmt-api.txt | 161 +++++++++++++++++++++++++++++++++++++++++++++++++++++++
1 file changed, 161 insertions(+)
diff --git a/doc/mgmt-api.txt b/doc/mgmt-api.txt
index 5a8073f6493e..663529effe4d 100644
--- a/doc/mgmt-api.txt
+++ b/doc/mgmt-api.txt
@@ -213,6 +213,7 @@ Read Controller Information Command
11 Advertising
12 Secure Connections
13 Debug Keys
+ 14 Privacy
This command generates a Command Complete event on success or
a Command Status event on failure.
@@ -730,6 +731,17 @@ Load Long Term Keys Command
again upon the receiption of New Long Term Key events since the
kernel updates its list automatically.
+ Possible values for the Address_Type parameter:
+ 0 Reserved (not in use)
+ 1 LE Public
+ 2 LE Random
+
+ The provided Address and Address_Type are the identity of
+ a device. So either its public address or static random address.
+
+ Unresolvable random addresses and resolvable random addresses are
+ not valid and will be rejected.
+
Currently defined Key_Type values are:
0x00 Unauthenticated key
@@ -1456,6 +1468,15 @@ Set Static Address Command
The special BDADDR_ANY address (00:00:00:00:00:00) can be used
to disable the static address.
+ When a controller has a public address (which is required for
+ all dual-mode controllers), this address is not used. Only when
+ the controller information reports BDADDR_ANY (00:00:00:00:00:00),
+ it is required to configure a static address first.
+
+ If privacy mode is enabled and the controller is single mode
+ LE only without a public address, the static random address is
+ used as identity address.
+
This command generates a Command Complete event on success or a
Command Status event on failure.
@@ -1545,6 +1566,76 @@ Set Debug Keys Command
Invalid Index
+Set Privacy Command
+===================
+
+ Command Code: 0x002F
+ Controller Index: <controller id>
+ Command Parameters: Privacy (1 Octet)
+ Identity_Resolving_Key (16 Octets)
+ Return Parameters: Current_Settings (4 Octets)
+
+ This command is used to enable Low Energy Privacy feature using
+ resolvable private addresses.
+
+ The value 0x00 disables privacy mode, the value 0x01 enables
+ privacy mode.
+
+ When the controller has a public address (mandatory for dual-mode
+ controllers) it is used as identity address. In case the controller
+ is single mode LE only without a public address, it is required
+ to configure a static random andress first. The privacy mode can
+ only be enabled when an identity address is available.
+
+ The Identity_Resolving_Key is the local key assigned for the local
+ resolvable private address.
+
+ Possible errors: Busy
+ Not Supported
+ Invalid Parameters
+ Invalid Index
+
+
+Load Identity Resolving Keys Command
+====================================
+
+ Command Code: 0x0030
+ Controller Index: <controller id>
+ Command Parameters: Key_Count (2 Octets)
+ Key1 {
+ Address (6 Octets)
+ Address_Type (1 Octet)
+ Value (16 Octets)
+ }
+ Key2 { }
+ ...
+ Return Parameters:
+
+ This command is used to feed the kernel with currently known
+ identity resolving keys. The command does not need to be called
+ again upon the receiption of New Identity Resolving Key events
+ since the kernel updates its list automatically.
+
+ Possible values for the Address_Type parameter:
+ 0 Reserved (not in use)
+ 1 LE Public
+ 2 LE Random
+
+ The provided Address and Address_Type are the identity of
+ a device. So either its public address or static random address.
+
+ Unresolvable random addresses and resolvable random addresses are
+ not valid and will be rejected.
+
+ This command can be used when the controller is not powered.
+
+ This command generates a Command Complete event on success or
+ a Command Status event on failure.
+
+ Possible errors: Invalid Parameters
+ Invalid Index
+
+
Command Complete Event
======================
@@ -1713,6 +1804,18 @@ Event Parameters Store_Hint (1 Octet)
to store the key persistently or not (e.g. this would not be set
if the authentication requirement was "No Bonding").
+ Possible values for the Address_Type parameter:
+ 0 Reserved (not in use)
+ 1 LE Public
+ 2 LE Random
+
+ The provided Address and Address_Type are the identity of
+ a device. So either its public address or static random address.
+
+ For unresolvable random addresses and resolvable random addresses
+ without identity information and identity resolving key, the
+ Store_Hint will be set to not store the long term key.
+
Currently defined Key_Type values are:
0x00 Unauthenticated key
@@ -2020,3 +2123,61 @@ Event Parameters Address (6 Octets)
The Passkey parameter indicates the passkey to be shown to the
user whereas the Entered parameter indicates how many characters
the user has entered on the remote side.
+
+
+Device Resolved Event
+=====================
+
+Event Code 0x0018
+Controller Index: <controller id>
+Event Parameters Address (6 Octets)
+ Address_Type (1 Octet)
+ Random_Address (6 Octets)
+
+ This event indicates that a random resolvable address has been
+ resolved into an identity of the device.
+
+ Possible values for the Address_Type parameter:
+ 0 Reserved (not in use)
+ 1 LE Public
+ 2 LE Random
+
+ The provided Address and Address_Type are the identity of
+ a device. So either its public address or static random address.
+
+ The Random_Address provides the resolvable random address that
+ was resolved into an identity.
+
+ Once this event was send all resolvable random address that are
+ known will from now on use the identity. This affects events
+ like Device Found, Device Connected, New Long Term key etc.
+
+ When using commands like Unpair Device, Disconnect etc., the
+ identity can be used from now on.
+
+
+New Identity Resolving Key Event
+================================
+
+Event Code 0x0019
+Controller Index <controller id>
+Event Parameters Store_Hint (1 Octet)
+ Key {
+ Address (6 Octets)
+ Address_Type (1 Octet)
+ Value (16 Octets)
+ }
+
+ This event indicates that a new identity resolving key has been
+ generated for a remote device.
+
+ The Store_Hint parameter indicates whether the host is expected
+ to store the key persistently or not.
+
+ Possible values for the Address_Type parameter:
+ 0 Reserved (not in use)
+ 1 LE Public
+ 2 LE Random
+
+ The provided Address and Address_Type are the identity of
+ a device. So either its public address or static random address.
--
1.8.5.3
^ permalink raw reply related
* Reg: Help need on RegisterPlayer in simpleagent python script on bluez 5.7
From: Pradeep Vivekanandan @ 2014-02-17 17:59 UTC (permalink / raw)
To: Marcel Holtmann; +Cc: linux-bluetooth@vger.kernel.org
[-- Attachment #1: Type: text/html, Size: 3618 bytes --]
^ permalink raw reply
* Re: [PATCH 1/2] Bluetooth: Add missing index added event on user channel failure
From: Johan Hedberg @ 2014-02-17 17:49 UTC (permalink / raw)
To: Marcel Holtmann; +Cc: linux-bluetooth
In-Reply-To: <1392657679-32983-1-git-send-email-marcel@holtmann.org>
Hi Marcel,
On Mon, Feb 17, 2014, Marcel Holtmann wrote:
> When the setup of user channel fails, the index added event is not sent
> and will cause issues with user interaction. This problem can be easily
> triggered with a LE only controller without a public address. In that
> case hci_dev_open() fails and that error case is not sending an event
> saying that the controller is available for normal use again.
>
> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
> ---
> net/bluetooth/hci_sock.c | 1 +
> 1 file changed, 1 insertion(+)
Both patches have been applied to bluetooth-next. Thanks.
Johan
^ permalink raw reply
* [PATCH 2/2] Bluetooth: Allow HCI User Channel usage for controllers without address
From: Marcel Holtmann @ 2014-02-17 17:21 UTC (permalink / raw)
To: linux-bluetooth
Trying to setup HCI User Channel usage for LE only controllers without
a public address or configured static address will fail with an error
saying that no address is available.
In case of HCI User Channel the requirement for a valid address is not
needed. So allow skipping this extra validation step.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
---
net/bluetooth/hci_core.c | 7 ++++++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/net/bluetooth/hci_core.c b/net/bluetooth/hci_core.c
index 58d2f9bf241f..b40d52446f8f 100644
--- a/net/bluetooth/hci_core.c
+++ b/net/bluetooth/hci_core.c
@@ -1937,10 +1937,15 @@ static int hci_dev_do_open(struct hci_dev *hdev)
* be able to determine if there is a public address
* or not.
*
+ * In case of user channel usage, it is not important
+ * if a public address or static random address is
+ * available.
+ *
* This check is only valid for BR/EDR controllers
* since AMP controllers do not have an address.
*/
- if (hdev->dev_type == HCI_BREDR &&
+ if (!test_bit(HCI_USER_CHANNEL, &hdev->dev_flags) &&
+ hdev->dev_type == HCI_BREDR &&
!bacmp(&hdev->bdaddr, BDADDR_ANY) &&
!bacmp(&hdev->static_addr, BDADDR_ANY)) {
ret = -EADDRNOTAVAIL;
--
1.8.5.3
^ permalink raw reply related
* [PATCH 1/2] Bluetooth: Add missing index added event on user channel failure
From: Marcel Holtmann @ 2014-02-17 17:21 UTC (permalink / raw)
To: linux-bluetooth
When the setup of user channel fails, the index added event is not sent
and will cause issues with user interaction. This problem can be easily
triggered with a LE only controller without a public address. In that
case hci_dev_open() fails and that error case is not sending an event
saying that the controller is available for normal use again.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
---
net/bluetooth/hci_sock.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/net/bluetooth/hci_sock.c b/net/bluetooth/hci_sock.c
index 7552f9e3089c..68e51a84e72d 100644
--- a/net/bluetooth/hci_sock.c
+++ b/net/bluetooth/hci_sock.c
@@ -716,6 +716,7 @@ static int hci_sock_bind(struct socket *sock, struct sockaddr *addr,
err = hci_dev_open(hdev->id);
if (err) {
clear_bit(HCI_USER_CHANNEL, &hdev->dev_flags);
+ mgmt_index_added(hdev);
hci_dev_put(hdev);
goto done;
}
--
1.8.5.3
^ permalink raw reply related
* Re: [PATCH] Bluetooth: allocate static minor for vhci
From: Marcel Holtmann @ 2014-02-17 16:34 UTC (permalink / raw)
To: Lucas De Marchi
Cc: bluez mailin list (linux-bluetooth@vger.kernel.org),
Lucas De Marchi
In-Reply-To: <1392649945-2338-1-git-send-email-lucas.demarchi@intel.com>
Hi Lucas,
> Commit bfacbb9 (Bluetooth: Use devname:vhci module alias for virtual HCI
> driver) added the module alias to hci_vhci module so it's possible to
> create the /dev/vhci node. However creating an alias without
> specifying the minor doesn't allow us to create the node ahead,
> triggerring module auto-load when it's first accessed.
>
> Starting with depmod from kmod 16 we started to warn if there's a
> devname alias without specifying the major and minor.
>
> Let's do the same done for uhid, kvm, fuse and others, specifying a
> fixed minor. In systems with systemd as the init the following will
> happen: on early boot systemd will call "kmod static-nodes" to read
> /lib/modules/$(uname -r)/modules.devname and then create the nodes. When
> first accessed these "dead" nodes will trigger the module loading.
>
> Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
> ---
> drivers/bluetooth/hci_vhci.c | 3 ++-
> include/linux/miscdevice.h | 1 +
> 2 files changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/bluetooth/hci_vhci.c b/drivers/bluetooth/hci_vhci.c
> index 1ef6990..add1c6a 100644
> --- a/drivers/bluetooth/hci_vhci.c
> +++ b/drivers/bluetooth/hci_vhci.c
> @@ -359,7 +359,7 @@ static const struct file_operations vhci_fops = {
> static struct miscdevice vhci_miscdev= {
> .name = "vhci",
> .fops = &vhci_fops,
> - .minor = MISC_DYNAMIC_MINOR,
> + .minor = VHCI_MINOR,
> };
>
> static int __init vhci_init(void)
> @@ -385,3 +385,4 @@ MODULE_DESCRIPTION("Bluetooth virtual HCI driver ver " VERSION);
> MODULE_VERSION(VERSION);
> MODULE_LICENSE("GPL");
> MODULE_ALIAS("devname:vhci");
> +MODULE_ALIAS_MISCDEV(VHCI_MINOR);
> diff --git a/include/linux/miscdevice.h b/include/linux/miscdevice.h
> index 3737f72..846a317 100644
> --- a/include/linux/miscdevice.h
> +++ b/include/linux/miscdevice.h
> @@ -48,6 +48,7 @@
> #define LOOP_CTRL_MINOR 237
> #define VHOST_NET_MINOR 238
> #define UHID_MINOR 239
> +#define VHCI_MINOR 240
> #define MISC_DYNAMIC_MINOR 255
you have read Documentation/devices.txt where it states that 240-254 is reserved for local use.
Regards
Marcel
^ permalink raw reply
* Re: [PATCH] Bluetooth: hidp: make sure input buffers are big enough
From: Marcel Holtmann @ 2014-02-17 16:32 UTC (permalink / raw)
To: Jiri Kosina
Cc: Gustavo F. Padovan, David Herrmann, open list:HID CORE LAYER,
linux-bluetooth@vger.kernel.org development
In-Reply-To: <alpine.LNX.2.00.1402171506450.1192@pobox.suse.cz>
Hi Jiri,
>>>>>>>> just got back to this, finally ... did you have time to work on this at
>>>>>>>> all, or should I just start from scratch?
>>>>>>>
>>>>>>> Sorry, no. Fosdem is this weekend and I needed to get my code ready
>>>>>>> for that. But I'll finally have time again next week.
>>>>>>
>>>>>> Okay, thanks. I then guess we should proceed with this bandaid (double
>>>>>> allocation) for 3.14
>>>>>
>>>>> It would be really nice if we could get the HIDP patch into 3.14-rc2
>>>>> and backported to stable. There have been quite a bunch of reports now
>>>>> and I dislike adding a GFP_ATOMIC allocation in HID core.
>>>>
>>>> I agree with David; Gustavo, what is your take on this, please?
>>>
>>> I leave this up to Gustavo to get this into wireless tree for 3.14-rc2.
>>>
>>> Acked-by: Marcel Holtmann <marcel@holtmann.org>
>>
>> Thanks a lot.
>>
>> Gustavo, what is your take on this please? I can take it through hid.git
>> in case you don't have anything else queued for -rc2.
>
> ... ping?
>
> In case this doesn't get reacted upon by the end of the week, I am
> inclined to take it through hid.git.
take it through hid.git please.
Regards
Marcel
^ permalink raw reply
* [PATCH 2/2] android: Do not resolve name if we have it in the cache
From: Lukasz Rymanowski @ 2014-02-17 16:26 UTC (permalink / raw)
To: linux-bluetooth; +Cc: Lukasz Rymanowski
In-Reply-To: <1392654390-19913-1-git-send-email-lukasz.rymanowski@tieto.com>
With this patch, deamon will not ask kernel to resolve name of remote
device during inquiry in case device name is already in the local cache.
Instead Android will be updated with already known device name.
---
android/bluetooth.c | 8 ++++++++
1 file changed, 8 insertions(+)
diff --git a/android/bluetooth.c b/android/bluetooth.c
index 1827834..ccfb461 100644
--- a/android/bluetooth.c
+++ b/android/bluetooth.c
@@ -1186,6 +1186,14 @@ static void update_found_device(const bdaddr_t *bdaddr, uint8_t bdaddr_type,
bool resolve_name = true;
ba2str(bdaddr, addr);
+
+ /* Don't need to confirm name if we have it already in cache
+ * Just check if device name is different than bdaddr */
+ if (g_strcmp0(dev->name, addr)) {
+ get_device_name(dev);
+ resolve_name = false;
+ }
+
info("Device %s needs name confirmation (resolve_name=%d)",
addr, resolve_name);
confirm_device_name(bdaddr, bdaddr_type, resolve_name);
--
1.8.4
^ permalink raw reply related
* [PATCH 1/2] android: Add resolve_name parameter to confirm_device_name
From: Lukasz Rymanowski @ 2014-02-17 16:26 UTC (permalink / raw)
To: linux-bluetooth; +Cc: Lukasz Rymanowski
---
android/bluetooth.c | 12 +++++++++---
1 file changed, 9 insertions(+), 3 deletions(-)
diff --git a/android/bluetooth.c b/android/bluetooth.c
index 525fd27..1827834 100644
--- a/android/bluetooth.c
+++ b/android/bluetooth.c
@@ -1012,7 +1012,8 @@ static void mgmt_discovering_event(uint16_t index, uint16_t length,
HAL_EV_DISCOVERY_STATE_CHANGED, sizeof(cp), &cp);
}
-static void confirm_device_name(const bdaddr_t *addr, uint8_t addr_type)
+static void confirm_device_name(const bdaddr_t *addr, uint8_t addr_type,
+ bool resolve_name)
{
struct mgmt_cp_confirm_name cp;
@@ -1020,6 +1021,9 @@ static void confirm_device_name(const bdaddr_t *addr, uint8_t addr_type)
bacpy(&cp.addr.bdaddr, addr);
cp.addr.type = addr_type;
+ if (!resolve_name)
+ cp.name_known = 1;
+
if (mgmt_reply(mgmt_if, MGMT_OP_CONFIRM_NAME, adapter.index,
sizeof(cp), &cp, NULL, NULL, NULL) == 0)
error("Failed to send confirm name request");
@@ -1179,10 +1183,12 @@ static void update_found_device(const bdaddr_t *bdaddr, uint8_t bdaddr_type,
if (confirm) {
char addr[18];
+ bool resolve_name = true;
ba2str(bdaddr, addr);
- info("Device %s needs name confirmation.", addr);
- confirm_device_name(bdaddr, bdaddr_type);
+ info("Device %s needs name confirmation (resolve_name=%d)",
+ addr, resolve_name);
+ confirm_device_name(bdaddr, bdaddr_type, resolve_name);
}
}
--
1.8.4
^ permalink raw reply related
* [PATCH] Bluetooth: allocate static minor for vhci
From: Lucas De Marchi @ 2014-02-17 15:12 UTC (permalink / raw)
To: linux-bluetooth; +Cc: Lucas De Marchi
Commit bfacbb9 (Bluetooth: Use devname:vhci module alias for virtual HCI
driver) added the module alias to hci_vhci module so it's possible to
create the /dev/vhci node. However creating an alias without
specifying the minor doesn't allow us to create the node ahead,
triggerring module auto-load when it's first accessed.
Starting with depmod from kmod 16 we started to warn if there's a
devname alias without specifying the major and minor.
Let's do the same done for uhid, kvm, fuse and others, specifying a
fixed minor. In systems with systemd as the init the following will
happen: on early boot systemd will call "kmod static-nodes" to read
/lib/modules/$(uname -r)/modules.devname and then create the nodes. When
first accessed these "dead" nodes will trigger the module loading.
Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
---
drivers/bluetooth/hci_vhci.c | 3 ++-
include/linux/miscdevice.h | 1 +
2 files changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/bluetooth/hci_vhci.c b/drivers/bluetooth/hci_vhci.c
index 1ef6990..add1c6a 100644
--- a/drivers/bluetooth/hci_vhci.c
+++ b/drivers/bluetooth/hci_vhci.c
@@ -359,7 +359,7 @@ static const struct file_operations vhci_fops = {
static struct miscdevice vhci_miscdev= {
.name = "vhci",
.fops = &vhci_fops,
- .minor = MISC_DYNAMIC_MINOR,
+ .minor = VHCI_MINOR,
};
static int __init vhci_init(void)
@@ -385,3 +385,4 @@ MODULE_DESCRIPTION("Bluetooth virtual HCI driver ver " VERSION);
MODULE_VERSION(VERSION);
MODULE_LICENSE("GPL");
MODULE_ALIAS("devname:vhci");
+MODULE_ALIAS_MISCDEV(VHCI_MINOR);
diff --git a/include/linux/miscdevice.h b/include/linux/miscdevice.h
index 3737f72..846a317 100644
--- a/include/linux/miscdevice.h
+++ b/include/linux/miscdevice.h
@@ -48,6 +48,7 @@
#define LOOP_CTRL_MINOR 237
#define VHOST_NET_MINOR 238
#define UHID_MINOR 239
+#define VHCI_MINOR 240
#define MISC_DYNAMIC_MINOR 255
struct device;
--
1.9.0
^ permalink raw reply related
* Re: [PATCH] Bluetooth: hidp: make sure input buffers are big enough
From: Jiri Kosina @ 2014-02-17 14:07 UTC (permalink / raw)
To: Marcel Holtmann, Gustavo F. Padovan
Cc: David Herrmann, open list:HID CORE LAYER,
linux-bluetooth@vger.kernel.org development
In-Reply-To: <alpine.LNX.2.00.1402051648470.8614@pobox.suse.cz>
On Wed, 5 Feb 2014, Jiri Kosina wrote:
> > >>>>> just got back to this, finally ... did you have time to work on this at
> > >>>>> all, or should I just start from scratch?
> > >>>>
> > >>>> Sorry, no. Fosdem is this weekend and I needed to get my code ready
> > >>>> for that. But I'll finally have time again next week.
> > >>>
> > >>> Okay, thanks. I then guess we should proceed with this bandaid (double
> > >>> allocation) for 3.14
> > >>
> > >> It would be really nice if we could get the HIDP patch into 3.14-rc2
> > >> and backported to stable. There have been quite a bunch of reports now
> > >> and I dislike adding a GFP_ATOMIC allocation in HID core.
> > >
> > > I agree with David; Gustavo, what is your take on this, please?
> >
> > I leave this up to Gustavo to get this into wireless tree for 3.14-rc2.
> >
> > Acked-by: Marcel Holtmann <marcel@holtmann.org>
>
> Thanks a lot.
>
> Gustavo, what is your take on this please? I can take it through hid.git
> in case you don't have anything else queued for -rc2.
... ping?
In case this doesn't get reacted upon by the end of the week, I am
inclined to take it through hid.git.
Thanks,
--
Jiri Kosina
SUSE Labs
^ permalink raw reply
* Re: [PATCH 1/2] Bluetooth: Restrict long term keys to public and static addresses
From: Johan Hedberg @ 2014-02-17 13:59 UTC (permalink / raw)
To: Marcel Holtmann; +Cc: linux-bluetooth
In-Reply-To: <1392584346-64921-1-git-send-email-marcel@holtmann.org>
Hi Marcel,
On Sun, Feb 16, 2014, Marcel Holtmann wrote:
> The long term keys should be associated with an identity address. Valid
> identity addresses are public addresses or static addresses. So only
> allow these two as valid address information for long term keys.
>
> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
> ---
> net/bluetooth/mgmt.c | 16 +++++++++++++---
> 1 file changed, 13 insertions(+), 3 deletions(-)
Both patches have been applied to bluetooth-next. Thanks.
Johan
^ permalink raw reply
* Re: [PATCHv2] emulator/bthost: Check length of received RFCOMM UIH frames
From: Johan Hedberg @ 2014-02-17 13:51 UTC (permalink / raw)
To: Marcin Kraglak; +Cc: linux-bluetooth
In-Reply-To: <1392643682-12370-1-git-send-email-marcin.kraglak@tieto.com>
Hi Marcin,
On Mon, Feb 17, 2014, Marcin Kraglak wrote:
> Add correct calculation of frame length. If frame is too short, ignore it.
> ---
> emulator/bthost.c | 38 ++++++++++++++++++++++++++++++--------
> 1 file changed, 30 insertions(+), 8 deletions(-)
Applied. Thanks.
Johan
^ permalink raw reply
* Re: [PATCH] android: Fix for BT Turn off while pairing
From: Szymon Janc @ 2014-02-17 13:46 UTC (permalink / raw)
To: Lukasz Rymanowski; +Cc: linux-bluetooth
In-Reply-To: <1392288692-5917-1-git-send-email-lukasz.rymanowski@tieto.com>
Hi Łukasz,
On Thursday 13 of February 2014 11:51:32 Lukasz Rymanowski wrote:
> This patch fix an issue when Android disables BT during ongoing
> paring. In this case mgmt did not accept any commands and BT gets
> in some unknown state.
> Since Android turns off BT anyway, it is ok to just cancel all
> the mgmt requests before send power off command.
> ---
> android/bluetooth.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/android/bluetooth.c b/android/bluetooth.c
> index ff41627..ad8cfec 100644
> --- a/android/bluetooth.c
> +++ b/android/bluetooth.c
> @@ -2907,6 +2907,9 @@ static void handle_disable_cmd(const void *buf, uint16_t len)
> goto reply;
> }
>
> + /* Cancel all pending requests. Need it in case of ongoing paring */
> + mgmt_cancel_index(mgmt_if, adapter.index);
> +
> if (!set_mode(MGMT_OP_SET_POWERED, 0x00)) {
> status = HAL_STATUS_FAILED;
> goto reply;
Applied, thanks.
--
Best regards,
Szymon Janc
^ permalink raw reply
* [PATCHv2] emulator/bthost: Check length of received RFCOMM UIH frames
From: Marcin Kraglak @ 2014-02-17 13:28 UTC (permalink / raw)
To: linux-bluetooth
Add correct calculation of frame length. If frame is too short, ignore it.
---
emulator/bthost.c | 38 ++++++++++++++++++++++++++++++--------
1 file changed, 30 insertions(+), 8 deletions(-)
diff --git a/emulator/bthost.c b/emulator/bthost.c
index ab90f4c..6fbabe8 100644
--- a/emulator/bthost.c
+++ b/emulator/bthost.c
@@ -1760,17 +1760,30 @@ static void rfcomm_mcc_recv(struct bthost *bthost, struct btconn *conn,
struct l2conn *l2conn, const void *data, uint16_t len)
{
const struct rfcomm_mcc *mcc = data;
+ const struct rfcomm_msc *msc;
+ const struct rfcomm_pn *pn;
+
+ if (len < sizeof(*mcc))
+ return;
switch (RFCOMM_GET_MCC_TYPE(mcc->type)) {
case RFCOMM_MSC:
+ if (len - sizeof(*mcc) < sizeof(*msc))
+ break;
+
+ msc = data + sizeof(*mcc);
+
rfcomm_msc_recv(bthost, conn, l2conn,
- RFCOMM_TEST_CR(mcc->type) / 2,
- data + sizeof(*mcc));
+ RFCOMM_TEST_CR(mcc->type) / 2, msc);
break;
case RFCOMM_PN:
+ if (len - sizeof(*mcc) < sizeof(*pn))
+ break;
+
+ pn = data + sizeof(*mcc);
+
rfcomm_pn_recv(bthost, conn, l2conn,
- RFCOMM_TEST_CR(mcc->type) / 2,
- data + sizeof(*mcc));
+ RFCOMM_TEST_CR(mcc->type) / 2, pn);
break;
default:
break;
@@ -1781,18 +1794,27 @@ static void rfcomm_uih_recv(struct bthost *bthost, struct btconn *conn,
struct l2conn *l2conn, const void *data,
uint16_t len)
{
- const struct rfcomm_cmd *hdr = data;
+ const struct rfcomm_hdr *hdr = data;
+ uint16_t hdr_len;
const void *p;
+ if (len < sizeof(*hdr))
+ return;
+
if (RFCOMM_GET_DLCI(hdr->address))
return;
if (RFCOMM_TEST_EA(hdr->length))
- p = data + sizeof(struct rfcomm_hdr);
+ hdr_len = sizeof(*hdr);
else
- p = data + sizeof(struct rfcomm_hdr) + sizeof(uint8_t);
+ hdr_len = sizeof(*hdr) + sizeof(uint8_t);
+
+ if (len < hdr_len)
+ return;
+
+ p = data + hdr_len;
- rfcomm_mcc_recv(bthost, conn, l2conn, p, p - data);
+ rfcomm_mcc_recv(bthost, conn, l2conn, p, len - hdr_len);
}
static void process_rfcomm(struct bthost *bthost, struct btconn *conn,
--
1.8.3.1
^ permalink raw reply related
* Re: [PATCH] btsnoop: Remove unused local function and macro
From: Luiz Augusto von Dentz @ 2014-02-17 12:02 UTC (permalink / raw)
To: Andre Guedes; +Cc: linux-bluetooth@vger.kernel.org
In-Reply-To: <1391812080-19529-2-git-send-email-andre.guedes@openbossa.org>
Hi Andre,
On Sat, Feb 8, 2014 at 12:27 AM, Andre Guedes
<andre.guedes@openbossa.org> wrote:
> ---
> tools/btsnoop.c | 13 -------------
> 1 file changed, 13 deletions(-)
>
> diff --git a/tools/btsnoop.c b/tools/btsnoop.c
> index a65d8c5..260dfdb 100644
> --- a/tools/btsnoop.c
> +++ b/tools/btsnoop.c
> @@ -40,19 +40,6 @@
>
> #include "monitor/btsnoop.h"
>
> -static inline uint64_t ntoh64(uint64_t n)
> -{
> - uint64_t h;
> - uint64_t tmp = ntohl(n & 0x00000000ffffffff);
> -
> - h = ntohl(n >> 32);
> - h |= tmp << 32;
> -
> - return h;
> -}
> -
> -#define hton64(x) ntoh64(x)
> -
> struct btsnoop_hdr {
> uint8_t id[8]; /* Identification Pattern */
> uint32_t version; /* Version Number = 1 */
> --
> 1.8.5.3
Applied, thanks.
--
Luiz Augusto von Dentz
^ permalink raw reply
* Re: [PATCH 0/5] Fixes for memory leaks
From: Luiz Augusto von Dentz @ 2014-02-17 12:02 UTC (permalink / raw)
To: Andre Guedes; +Cc: linux-bluetooth@vger.kernel.org
In-Reply-To: <1391812125-19594-1-git-send-email-andre.guedes@openbossa.org>
Hi Andre,
On Sat, Feb 8, 2014 at 12:28 AM, Andre Guedes
<andre.guedes@openbossa.org> wrote:
> Hi all,
>
> This patch set fixes some memory leaks reported by clang static analyzer.
> There is no relation between patches of this set so they can be applied
> independently.
>
> BR,
>
> Andre
>
>
> Andre Guedes (5):
> hcitool: Fix memory leak in cmd_info
> hcidump: Fix memory leak
> cltest: Fix memory leak
> amptest: Fix memory leak
> rctest: Fix memory leak
>
> tools/amptest.c | 12 ++++++++----
> tools/cltest.c | 5 +++--
> tools/hcidump.c | 9 +++++++--
> tools/hcitool.c | 3 +++
> tools/rctest.c | 5 ++++-
> 5 files changed, 25 insertions(+), 9 deletions(-)
>
> --
> 1.8.5.3
Applied, thanks.
--
Luiz Augusto von Dentz
^ permalink raw reply
* Re: [PATCH] health: Fix HealthDevice dbus registration
From: Luiz Augusto von Dentz @ 2014-02-17 12:01 UTC (permalink / raw)
To: Andre Guedes; +Cc: linux-bluetooth@vger.kernel.org
In-Reply-To: <1391812080-19529-1-git-send-email-andre.guedes@openbossa.org>
Hi Andre,
On Sat, Feb 8, 2014 at 12:27 AM, Andre Guedes
<andre.guedes@openbossa.org> wrote:
> For some reason, HealthDevice property table wasn't been registered.
> ---
> profiles/health/hdp.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/profiles/health/hdp.c b/profiles/health/hdp.c
> index 622d95b..48dad52 100644
> --- a/profiles/health/hdp.c
> +++ b/profiles/health/hdp.c
> @@ -2145,7 +2145,8 @@ static struct hdp_device *create_health_device(struct btd_device *device)
> if (!g_dbus_register_interface(btd_get_dbus_connection(),
> path, HEALTH_DEVICE,
> health_device_methods,
> - health_device_signals, NULL,
> + health_device_signals,
> + health_device_properties,
> dev, health_device_destroy)) {
> error("D-Bus failed to register %s interface", HEALTH_DEVICE);
> goto fail;
> --
> 1.8.5.3
Applied, thanks.
--
Luiz Augusto von Dentz
^ permalink raw reply
* Re: [PATCH BlueZ 1/3] gdbus: Fix memory leak
From: Anderson Lizardo @ 2014-02-17 11:56 UTC (permalink / raw)
To: BlueZ development; +Cc: Anderson Lizardo
In-Reply-To: <1392052498-9229-1-git-send-email-anderson.lizardo@openbossa.org>
Hi,
On Mon, Feb 10, 2014 at 1:14 PM, Anderson Lizardo
<anderson.lizardo@openbossa.org> wrote:
> data->conn and data->path must be destroyed before freeing "data".
> ---
> gdbus/object.c | 2 ++
> 1 file changed, 2 insertions(+)
ping.
--
Anderson Lizardo
http://www.indt.org/?lang=en
INdT - Manaus - Brazil
^ permalink raw reply
* Re: [PATCH BlueZ 1/3] lib/sdp: Add missing Service Class ID for GAP
From: Anderson Lizardo @ 2014-02-17 11:55 UTC (permalink / raw)
To: BlueZ development; +Cc: Anderson Lizardo
In-Reply-To: <1391804086-14428-1-git-send-email-anderson.lizardo@openbossa.org>
Hi,
On Fri, Feb 7, 2014 at 4:14 PM, Anderson Lizardo
<anderson.lizardo@openbossa.org> wrote:
> Also reorder last ID so the list remains ordered.
> ---
> lib/sdp.c | 3 ++-
> lib/sdp.h | 7 ++++---
> 2 files changed, 6 insertions(+), 4 deletions(-)
ping.
--
Anderson Lizardo
http://www.indt.org/?lang=en
INdT - Manaus - Brazil
^ permalink raw reply
* Re: [PATCH 5/6] tools/rfcomm-tester: Add RFCOMM client read test case
From: Johan Hedberg @ 2014-02-17 11:32 UTC (permalink / raw)
To: Marcin Kraglak; +Cc: linux-bluetooth
In-Reply-To: <1392205301-4204-6-git-send-email-marcin.kraglak@tieto.com>
Hi Marcin,
On Wed, Feb 12, 2014, Marcin Kraglak wrote:
> + sk = g_io_channel_unix_get_fd(io);
> +
> +
> + if (client_data->data_len != read(sk, buf, client_data->data_len)) {
Coding style with the two consecutive empty lines above. Also consider a
separate ssize_t ret variable before the length comparison.
Johan
^ permalink raw reply
* Re: [PATCH 1/6] emulator/bthost: Add api to handle RFCOMM data on bthost
From: Johan Hedberg @ 2014-02-17 11:31 UTC (permalink / raw)
To: Marcin Kraglak; +Cc: linux-bluetooth
In-Reply-To: <1392205301-4204-2-git-send-email-marcin.kraglak@tieto.com>
Hi Marcin,
On Wed, Feb 12, 2014, Marcin Kraglak wrote:
> With this change user can handle data received on RFCOMM connection.
> ---
> emulator/bthost.c | 70 +++++++++++++++++++++++++++++++++++++++++++++++++++----
> emulator/bthost.h | 8 +++++++
> 2 files changed, 74 insertions(+), 4 deletions(-)
>
> diff --git a/emulator/bthost.c b/emulator/bthost.c
> index 8447817..92ae08a 100644
> --- a/emulator/bthost.c
> +++ b/emulator/bthost.c
> @@ -126,6 +126,13 @@ struct cid_hook {
> struct cid_hook *next;
> };
>
> +struct channel_hook {
Since this is RFCOMM specific and the concept of channels exists also
with L2CAP I'd include "rfcomm" somewhere in the struct name.
> @@ -232,6 +240,12 @@ static void btconn_free(struct btconn *conn)
> conn->cid_hooks = hook->next;
> free(hook);
> }
> + while (conn->channel_hooks) {
Coding style: empty line before the while statement.
> +void bthost_add_channel_hook(struct bthost *bthost, uint16_t handle,
> + uint8_t channel,
> + bthost_channel_hook_func_t func,
> + void *user_data);
Here you should also have "rfcomm" somewhere in the name since it's
RFCOMM specific and we don't people to confuse this with L2CAP.
Johan
^ permalink raw reply
* Re: [PATCH 2/6] tools/rfcomm-tester: Add RFCOMM client write test case
From: Johan Hedberg @ 2014-02-17 11:29 UTC (permalink / raw)
To: Marcin Kraglak; +Cc: linux-bluetooth
In-Reply-To: <1392205301-4204-3-git-send-email-marcin.kraglak@tieto.com>
Hi Marcin,
On Wed, Feb 12, 2014, Marcin Kraglak wrote:
> This will test sending data through RFCOMM socket from client to server.
> ---
> tools/rfcomm-tester.c | 48 +++++++++++++++++++++++++++++++++++++++++++++++-
> 1 file changed, 47 insertions(+), 1 deletion(-)
>
> diff --git a/tools/rfcomm-tester.c b/tools/rfcomm-tester.c
> index 44df7e7..80448cb 100644
> --- a/tools/rfcomm-tester.c
> +++ b/tools/rfcomm-tester.c
> @@ -57,6 +57,9 @@ struct rfcomm_client_data {
> uint8_t server_channel;
> uint8_t client_channel;
> int expected_connect_err;
> + const uint8_t *send_data;
> + const uint8_t *read_data;
> + uint16_t data_len;
> };
>
> struct rfcomm_server_data {
> @@ -294,6 +297,15 @@ const struct rfcomm_client_data connect_success = {
> .client_channel = 0x0c
> };
>
> +const uint8_t data[] = {0, 1, 2, 3, 4, 5, 6, 7, 8};
> +
> +const struct rfcomm_client_data connect_send_success = {
> + .server_channel = 0x0c,
> + .client_channel = 0x0c,
> + .data_len = sizeof(data),
> + .send_data = data
> +};
> +
> const struct rfcomm_client_data connect_nval = {
> .server_channel = 0x0c,
> .client_channel = 0x0e,
> @@ -389,6 +401,13 @@ static gboolean rc_connect_cb(GIOChannel *io, GIOCondition cond,
> return false;
> }
>
> + if (client_data->send_data) {
> + if (client_data->data_len != write(sk, client_data->send_data,
> + client_data->data_len))
I'd rather have a separate ssize_t ret variable before the comparison
here.
> +static void client_hook_func(const void *data, uint16_t len,
> + void *user_data)
> +{
> + struct test_data *test_data = tester_get_data();
> + const struct rfcomm_client_data *client_data = test_data->test_data;
> +
> + if (memcmp(client_data->send_data, data, len))
Missing check of client_data->data_len == len before the memcmp?
Johan
^ permalink raw reply
* Re: [PATCH 3/6] tools/rfcomm-tester: Add RFCOMM server write test case
From: Johan Hedberg @ 2014-02-17 11:28 UTC (permalink / raw)
To: Marcin Kraglak; +Cc: linux-bluetooth
In-Reply-To: <1392205301-4204-4-git-send-email-marcin.kraglak@tieto.com>
Hi Marcin,
On Wed, Feb 12, 2014, Marcin Kraglak wrote:
> This will check data write from server to client.
> ---
> tools/rfcomm-tester.c | 43 +++++++++++++++++++++++++++++++++++++++++++
> 1 file changed, 43 insertions(+)
>
> diff --git a/tools/rfcomm-tester.c b/tools/rfcomm-tester.c
> index 80448cb..1c2563d 100644
> --- a/tools/rfcomm-tester.c
> +++ b/tools/rfcomm-tester.c
> @@ -66,6 +66,9 @@ struct rfcomm_server_data {
> uint8_t server_channel;
> uint8_t client_channel;
> bool expected_status;
> + const uint8_t *send_data;
> + const uint8_t *read_data;
> + uint16_t data_len;
> +static void server_hook_func(const void *data, uint16_t len,
> + void *user_data)
> +{
> + struct test_data *test_data = tester_get_data();
> + const struct rfcomm_server_data *server_data = test_data->test_data;
> +
> + if (memcmp(server_data->send_data, data, len))
Don't you have to first check that server_data->data_len == len?
> + if (server_data->send_data) {
> + if (server_data->data_len != write(new_sk,
> + server_data->send_data,
> + server_data->data_len))
This looks ugly. I'd create a separate ssize_t ret variable, assing the
return value from write to it and then compare with data_len.
Johan
^ 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