* [RFC v4] doc: Add management commands and events for privacy support
From: Marcel Holtmann @ 2014-02-16 20:13 UTC (permalink / raw)
To: linux-bluetooth
---
doc/mgmt-api.txt | 175 +++++++++++++++++++++++++++++++++++++++++++++++++++++++
1 file changed, 175 insertions(+)
diff --git a/doc/mgmt-api.txt b/doc/mgmt-api.txt
index 697336092798..554ff2b706cd 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
@@ -1386,6 +1398,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.
@@ -1475,6 +1496,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
======================
@@ -1640,6 +1731,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
+ long term key will not be provided.
+
Currently defined Key_Type values are:
0x00 Unauthenticated key
@@ -1669,6 +1772,11 @@ Event Parameters Address (6 Octets)
This event indicates that a successful baseband connection has
been created to the remote device.
+ The EIR_Data might contain the LE Bluetooth Device Address type
+ providing the identity address and identity address type. For
+ random resolvable address where the identity resolving key is
+ known, the identity information will be provided this way.
+
Device Disconnected Event
=========================
@@ -1822,6 +1930,11 @@ Event Parameters Address (6 Octets)
false-positives for this flag so user space should be able to
handle getting something else as a PIN Request when pairing.
+ The EIR_Data might contain the LE Bluetooth Device Address type
+ providing the identity address and identity address type. For
+ random resolvable address where the identity resolving key is
+ known, the identity information will be provided this way.
+
Discovering Event
=================
@@ -1898,3 +2011,65 @@ 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)
+ Flags (4 Octets)
+ EIR_Data_Length (2 Octets)
+ EIR_Data (0-65535 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 Reserved (not in use)
+ 2 LE Random
+
+ The following bits are defined for the Flags parameter:
+ 0 Reserved (not in use)
+ 1 Reserved (not in use)
+
+ During pairing the remote device can provide identity information
+ and identity resolving key. In that case this event will provide
+ the new identity information matching the random resolvable address.
+
+ This event can also be send at any time a new random resolvable
+ address has been found and during scanning and then successfully
+ resolved into an identity.
+
+ The EIR_Data contains the LE Bluetooth Device Address type
+ providing the identity address and identity address type.
+
+
+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
* [RFC v2] doc: Add management commands and events for privacy support
From: Marcel Holtmann @ 2014-02-16 19:48 UTC (permalink / raw)
To: linux-bluetooth
---
doc/mgmt-api.txt | 139 +++++++++++++++++++++++++++++++++++++++++++++++++++++++
1 file changed, 139 insertions(+)
diff --git a/doc/mgmt-api.txt b/doc/mgmt-api.txt
index 73c560692dce..cc20e7031ea2 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.
@@ -1379,6 +1380,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.
@@ -1468,6 +1478,68 @@ 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.
+
+ The provided Address and Address_Type are the identity of
+ a device. So either its public address or static random address.
+
+ 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
======================
@@ -1655,6 +1727,11 @@ Event Parameters Address (6 Octets)
This event indicates that a successful baseband connection has
been created to the remote device.
+ The EIR_Data might contain the LE Bluetooth Device Address type
+ providing the identity address and identity address type. For
+ random resolvable address where the identity resolving key is
+ known, the identity information will be provided this way.
+
Device Disconnected Event
=========================
@@ -1808,6 +1885,11 @@ Event Parameters Address (6 Octets)
false-positives for this flag so user space should be able to
handle getting something else as a PIN Request when pairing.
+ The EIR_Data might contain the LE Bluetooth Device Address type
+ providing the identity address and identity address type. For
+ random resolvable address where the identity resolving key is
+ known, the identity information will be provided this way.
+
Discovering Event
=================
@@ -1884,3 +1966,60 @@ 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)
+ Flags (4 Octets)
+ EIR_Data_Length (2 Octets)
+ EIR_Data (0-65535 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 Reserved (not in use)
+ 2 LE Random
+
+ The following bits are defined for the Flags parameter:
+ 0 Reserved (not in use)
+ 1 Reserved (not in use)
+
+ During pairing the remote device can provide identity information
+ and identity resolving key. In that case this event will provide
+ the new identity information matching the random resolvable address.
+
+ This event can also be send at any time a new random resolvable
+ address has been found and during scanning and then successfully
+ resolved into an identity.
+
+ The EIR_Data contains the LE Bluetooth Device Address type
+ providing the identity address and identity address type.
+
+
+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 provided Address and Address_Type are the identity of
+ a device. So either its public address or static random address.
+
+ The Store_Hint parameter indicates whether the host is expected
+ to store the key persistently or not.
--
1.8.5.3
^ permalink raw reply related
* Re: Some patches applied on Fedora that maybe should be considered for being applied upstream
From: Pacho Ramos @ 2014-02-16 19:06 UTC (permalink / raw)
To: Bastien Nocera; +Cc: BlueZ development
In-Reply-To: <1392125277.22732.1.camel@nuvo>
El mar, 11-02-2014 a las 14:27 +0100, Bastien Nocera escribió:
> On Mon, 2014-02-10 at 21:01 +0100, Pacho Ramos wrote:
> > El lun, 10-02-2014 a las 14:40 +0100, Bastien Nocera escribió:
> > > On Sun, 2014-02-09 at 09:53 +0100, Pacho Ramos wrote:
> > > > Hello
> > > >
> > > > I was looking at bluez package and found some patches that maybe could
> > > > be upstreamed. Also, I would like to know the reasons for not accepting
> > > > them to ensure they are safe to be applied downstream by us too :)
> > > >
> > > > http://pkgs.fedoraproject.org/cgit/bluez.git/tree/0001-Allow-using-obexd-without-systemd-in-the-user-sessio.patch -> Does this cause any issues with systemd --user setups?
> > >
> > > Giovanni already posted this patch earlier. There's no distribution
> > > using systemd sessions, so this doesn't work yet.
> > >
> > > > http://pkgs.fedoraproject.org/cgit/bluez.git/tree/0001-obex-Use-GLib-helper-function-to-manipulate-paths.patch
> > > > http://pkgs.fedoraproject.org/cgit/bluez.git/tree/0002-autopair-Don-t-handle-the-iCade.patch
> > > > http://pkgs.fedoraproject.org/cgit/bluez.git/tree/0004-agent-Assert-possible-infinite-loop.patch
> > > > -> Any reason for not applying it upstream too?
> > >
> > > I've posted those patches to the list as well.
> >
> > And, do you know why they weren't accepted? (it's for trying to get them
> > merged and not needing to carry them forever)
>
> Read the threads for the various patches?
>
> Mailing-lists, awful at tracking patches since forever...
>
But, for example for the patch allowing to run without systemd --user:
http://marc.info/?t=138159296100001&r=1&w=2
What is the point in providing a "--disable-systemd" configure flag that
needs this patches to be applied to be really working? Looks like
"--enable-systemd" will be needed if we don't apply that patches
downstream...
Also:
http://www.spinics.net/lists/linux-bluetooth/msg40136.html
http://www.spinics.net/lists/linux-bluetooth/msg41264.html
Look to have no reply at all
And for 0004-agent-Assert-possible-infinite-loop.patch I can't find the
relevant thread :(
^ permalink raw reply
* Re: Some patches applied on Fedora that maybe should be considered for being applied upstream
From: Pacho Ramos @ 2014-02-16 18:58 UTC (permalink / raw)
To: Bastien Nocera; +Cc: BlueZ development
In-Reply-To: <1392062509.4911.0.camel@belkin5>
El lun, 10-02-2014 a las 21:01 +0100, Pacho Ramos escribió:
> [...]
> > > http://pkgs.fedoraproject.org/cgit/bluez.git/tree/0001-work-around-Logitech-diNovo-Edge-keyboard-firmware-i.patch
> > > -> Taking care this looks to be a really old issue, maybe using the
> > > workaround would be the only option for now :/
> >
> > I have no hardware to test this on, I snatched it from Ubuntu's bluez 4
> > package.
> >
> > Cheers
>
> OK, thanks :)
>
Looks to be still needed:
https://bugs.gentoo.org/show_bug.cgi?id=501120
^ permalink raw reply
* Re: [PATCH v3] btusb.c - Add IMC Networks (Broadcom based)
From: Jurgen Kramer @ 2014-02-16 8:19 UTC (permalink / raw)
To: Marcel Holtmann; +Cc: bluez mailin list (linux-bluetooth@vger.kernel.org)
In-Reply-To: <5A7ECA4A-ADC4-4587-8DC1-20784328A5F0@holtmann.org>
Hi Marcel,
On Sat, 2014-02-15 at 11:54 -0800, Marcel Holtmann wrote:
> Hi Jurgen,
>
> the subject should start with Bluetooth: for patches.
>
> > Add support for IMC Networks (Broadcom based) to btusb.c.
> >
> > v3: Switch to using USB_VENDOR_AND_INTERFACE_INFO.
>
> This belong after --- in git patches.
OK, will do next time.
>
> >
> > Below the output of /sys/kernel/debug/usb/devices for this device:
> >
> > T: Bus=01 Lev=02 Prnt=02 Port=04 Cnt=01 Dev#= 3 Spd=12 MxCh= 0
> > D: Ver= 2.00 Cls=ff(vend.) Sub=01 Prot=01 MxPS=64 #Cfgs= 1
> > P: Vendor=13d3 ProdID=3404 Rev= 1.12
> > S: Manufacturer=Broadcom Corp
> > S: Product=BCM20702A0
> > S: SerialNumber=240A649F8246
> > C:* #Ifs= 4 Cfg#= 1 Atr=e0 MxPwr= 0mA
> > I:* If#= 0 Alt= 0 #EPs= 3 Cls=ff(vend.) 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=ff(vend.) 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=ff(vend.) 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=ff(vend.) 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=ff(vend.) 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=ff(vend.) 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=ff(vend.) 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
> > I:* If#= 2 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=(none)
> > E: Ad=84(I) Atr=02(Bulk) MxPS= 32 Ivl=0ms
> > E: Ad=04(O) Atr=02(Bulk) MxPS= 32 Ivl=0ms
> > I:* If#= 3 Alt= 0 #EPs= 0 Cls=fe(app. ) Sub=01 Prot=01 Driver=(none)
> >
> > Signed-off-by: Jurgen Kramer <gtmkramer@xs4all.nl>
> > ---
> > drivers/bluetooth/btusb.c | 3 +++
> > 1 file changed, 3 insertions(+)
> >
> > diff --git a/drivers/bluetooth/btusb.c b/drivers/bluetooth/btusb.c
> > index 3980fd1..a372df8 100644
> > --- a/drivers/bluetooth/btusb.c
> > +++ b/drivers/bluetooth/btusb.c
> > @@ -116,6 +116,9 @@ static const struct usb_device_id btusb_table[] = {
> > /* Belkin F8065bf - Broadcom based */
> > { USB_VENDOR_AND_INTERFACE_INFO(0x050d, 0xff, 0x01, 0x01) },
> >
> > + /* IMC Networks - Broadcom based */
> > + { USB_VENDOR_AND_INTERFACE_INFO(0x13d3, 0xff, 0x01, 0x01 },
> > +
>
> CC drivers/bluetooth/btusb.o
> drivers/bluetooth/btusb.c:1716:0: error: unterminated argument list invoking macro "USB_VENDOR_AND_INTERFACE_INFO"
> MODULE_LICENSE("GPL");
> ^
> drivers/bluetooth/btusb.c:120:4: error: ‘USB_VENDOR_AND_INTERFACE_INFO’ undeclared here (not in a function)
> { USB_VENDOR_AND_INTERFACE_INFO(0x13d3, 0xff, 0x01, 0x01 },
> ^
> drivers/bluetooth/btusb.c:120:2: error: expected ‘}’ at end of input
> { USB_VENDOR_AND_INTERFACE_INFO(0x13d3, 0xff, 0x01, 0x01 },
> ^
>
> > { } /* Terminating entry */
> > };
>
> I fixed this all up for you now and applied the patch to bluetooth-next tree.
>
> However next time, at least compile test the patch before sending it. Otherwise you are wasting everyones time.
Sorry about that. Thanks for fixing.
Regards,
Jurgen
^ permalink raw reply
* Re: [PATCH v2] Bluetooth: Add hci_h4p driver
From: Pavel Machek @ 2014-02-15 22:30 UTC (permalink / raw)
To: Sebastian Reichel
Cc: Pali Rohár, Ben Hutchings,
Ивайло Димитров,
linux-kernel, linux-bluetooth@vger.kernel.org development
In-Reply-To: <20140214172802.GA26969@earth.universe>
Hi!
> > >> > Firmware files are available for download from nemo project:
> > >> >
> > >> > https://api.merproject.org/public/source/nemo:devel:hw:ti:om
> > >> > ap3:n900/bcm-bt-firmware/bcm-bt-firmware-0.21rc3.tar.bz2
> > >> > https://api.merproject.org/public/source/nemo:devel:hw:ti:o
> > >> > map3:n950-n9/ti-wl1273-bt-firmware/bt-firmware-ti1273_0.23+0
> > >> > m6.tar.gz
> > >>
> > >> Would be nice to have them added to the linux-firmware.git.
> > >
> > Now when driver is queued for staging, can somebody add firmware files
> > to linux-firmware repository? Note that without firmware files, driver
> > not working...
>
> I just had a look at the file for the Nokia N900
> (bcm-bt-firmware-0.21rc3.tar.bz2) and I think the license is too
> restrictive for linux-firmware.git. Actually I can't see any
> statement allowing redistribution. For reference this is the license
> text:
>
> Copyright (c) Nokia Corporation 2010
> All Rights Reserved.
>
> This material, including documentation and any related computer programs, is
> protected by copyright controlled by Nokia Corporation. All rights are
> reserved. Modifying, adapting and/or translating, any or all of this material
> requires the prior written consent of Nokia. Distribution for commercial
> purposes not allowed without prior written approval from Nokia.
With my lingvistics hat on, this says "distribution for non-commercial
purposes is ok". (Because otherwise, they would say "Distribution not
allowed without ...")
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
^ permalink raw reply
* Re: partial success with PS3 sixaxis
From: Andrea @ 2014-02-15 20:49 UTC (permalink / raw)
To: Szymon Janc; +Cc: linux-bluetooth
In-Reply-To: <52FFD116.2080902@gmail.com>
On 15/02/14 20:41, Andrea wrote:
> On 13/02/14 09:25, Szymon Janc wrote:
>> Hi Andrea,
>>
>>
>> I assume you are using bluetoothctl so do:
>> agent on
>> default-agent
>>
>> Then you should get authorization request in bluetoothctl when DS3 is connecting.
>>
>
> Hi,
>
> I have tried on a different laptop (no more the raspberry pi, where I still have the issues I
> reported in the other email), running Fedora 19.
>
> I compiled bluez 5.14 and run it.
> It is more stable and /dev/input/js0 is usable.
>
> It is still not able to set the LEDs. This gets written in the output
>
> Feb 15 16:55:02 localhost.localdomain bluetoothd[24620]: sixaxis: compatible device connected:
> PLAYSTATION(R)3 Contr
> Feb 15 16:55:02 localhost.localdomain kernel: input: PLAYSTATION(R)3 Controller as
> /devices/pci0000:00/0000:00:1d.1/
> Feb 15 16:55:02 localhost.localdomain kernel: sony 0005:054C:0268.000E: input,hidraw0: BLUETOOTH HID
> v1.00 Joystick
> Feb 15 16:55:02 localhost.localdomain bluetoothd[24620]: sixaxis: failed to set LEDS (0 bytes written)
>
> I have tried to log the traffic for bluez and sixad (where the LEDs work), to see you can find any
> difference.
>
> http://pastebin.com/pExywtUk (this is the log from bluez where LEDs keep flashing)
> http://pastebin.com/BgRUnamS (log from sixad where LEDs are set)
>
> Happy to provide more if it can be of any help.
>
> Andrea
>
and this is the log from bluez 5.14 running on raspberry pi
where /dev/input/js0 disappears after a few seconds.
http://pastebin.com/Rxsv3php
Andrea
^ permalink raw reply
* Re: partial success with PS3 sixaxis
From: Andrea @ 2014-02-15 20:41 UTC (permalink / raw)
To: Szymon Janc; +Cc: linux-bluetooth
In-Reply-To: <2534491.XllyezJg3g@uw000953>
On 13/02/14 09:25, Szymon Janc wrote:
> Hi Andrea,
>
>
> I assume you are using bluetoothctl so do:
> agent on
> default-agent
>
> Then you should get authorization request in bluetoothctl when DS3 is connecting.
>
Hi,
I have tried on a different laptop (no more the raspberry pi, where I still have the issues I
reported in the other email), running Fedora 19.
I compiled bluez 5.14 and run it.
It is more stable and /dev/input/js0 is usable.
It is still not able to set the LEDs. This gets written in the output
Feb 15 16:55:02 localhost.localdomain bluetoothd[24620]: sixaxis: compatible device connected:
PLAYSTATION(R)3 Contr
Feb 15 16:55:02 localhost.localdomain kernel: input: PLAYSTATION(R)3 Controller as
/devices/pci0000:00/0000:00:1d.1/
Feb 15 16:55:02 localhost.localdomain kernel: sony 0005:054C:0268.000E: input,hidraw0: BLUETOOTH HID
v1.00 Joystick
Feb 15 16:55:02 localhost.localdomain bluetoothd[24620]: sixaxis: failed to set LEDS (0 bytes written)
I have tried to log the traffic for bluez and sixad (where the LEDs work), to see you can find any
difference.
http://pastebin.com/pExywtUk (this is the log from bluez where LEDs keep flashing)
http://pastebin.com/BgRUnamS (log from sixad where LEDs are set)
Happy to provide more if it can be of any help.
Andrea
^ permalink raw reply
* Re: [PATCH v3] btusb.c - Add IMC Networks (Broadcom based)
From: Marcel Holtmann @ 2014-02-15 19:54 UTC (permalink / raw)
To: Jurgen Kramer; +Cc: bluez mailin list (linux-bluetooth@vger.kernel.org)
In-Reply-To: <1392462069-3093-1-git-send-email-gtmkramer@xs4all.nl>
Hi Jurgen,
the subject should start with Bluetooth: for patches.
> Add support for IMC Networks (Broadcom based) to btusb.c.
>
> v3: Switch to using USB_VENDOR_AND_INTERFACE_INFO.
This belong after --- in git patches.
>
> Below the output of /sys/kernel/debug/usb/devices for this device:
>
> T: Bus=01 Lev=02 Prnt=02 Port=04 Cnt=01 Dev#= 3 Spd=12 MxCh= 0
> D: Ver= 2.00 Cls=ff(vend.) Sub=01 Prot=01 MxPS=64 #Cfgs= 1
> P: Vendor=13d3 ProdID=3404 Rev= 1.12
> S: Manufacturer=Broadcom Corp
> S: Product=BCM20702A0
> S: SerialNumber=240A649F8246
> C:* #Ifs= 4 Cfg#= 1 Atr=e0 MxPwr= 0mA
> I:* If#= 0 Alt= 0 #EPs= 3 Cls=ff(vend.) 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=ff(vend.) 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=ff(vend.) 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=ff(vend.) 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=ff(vend.) 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=ff(vend.) 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=ff(vend.) 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
> I:* If#= 2 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=(none)
> E: Ad=84(I) Atr=02(Bulk) MxPS= 32 Ivl=0ms
> E: Ad=04(O) Atr=02(Bulk) MxPS= 32 Ivl=0ms
> I:* If#= 3 Alt= 0 #EPs= 0 Cls=fe(app. ) Sub=01 Prot=01 Driver=(none)
>
> Signed-off-by: Jurgen Kramer <gtmkramer@xs4all.nl>
> ---
> drivers/bluetooth/btusb.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/drivers/bluetooth/btusb.c b/drivers/bluetooth/btusb.c
> index 3980fd1..a372df8 100644
> --- a/drivers/bluetooth/btusb.c
> +++ b/drivers/bluetooth/btusb.c
> @@ -116,6 +116,9 @@ static const struct usb_device_id btusb_table[] = {
> /* Belkin F8065bf - Broadcom based */
> { USB_VENDOR_AND_INTERFACE_INFO(0x050d, 0xff, 0x01, 0x01) },
>
> + /* IMC Networks - Broadcom based */
> + { USB_VENDOR_AND_INTERFACE_INFO(0x13d3, 0xff, 0x01, 0x01 },
> +
CC drivers/bluetooth/btusb.o
drivers/bluetooth/btusb.c:1716:0: error: unterminated argument list invoking macro "USB_VENDOR_AND_INTERFACE_INFO"
MODULE_LICENSE("GPL");
^
drivers/bluetooth/btusb.c:120:4: error: ‘USB_VENDOR_AND_INTERFACE_INFO’ undeclared here (not in a function)
{ USB_VENDOR_AND_INTERFACE_INFO(0x13d3, 0xff, 0x01, 0x01 },
^
drivers/bluetooth/btusb.c:120:2: error: expected ‘}’ at end of input
{ USB_VENDOR_AND_INTERFACE_INFO(0x13d3, 0xff, 0x01, 0x01 },
^
> { } /* Terminating entry */
> };
I fixed this all up for you now and applied the patch to bluetooth-next tree.
However next time, at least compile test the patch before sending it. Otherwise you are wasting everyones time.
Regards
Marcel
^ permalink raw reply
* [RFC v2] doc: Add management commands and events for privacy support
From: Marcel Holtmann @ 2014-02-15 18:06 UTC (permalink / raw)
To: linux-bluetooth
---
doc/mgmt-api.txt | 88 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++
1 file changed, 88 insertions(+)
diff --git a/doc/mgmt-api.txt b/doc/mgmt-api.txt
index c5c84291a044..b21ddfbb7e78 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.
@@ -1379,6 +1380,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.
@@ -1468,6 +1478,65 @@ 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.
+
+ 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
======================
@@ -1884,3 +1953,22 @@ 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.
+
+
+New Identity Resolving Key Event
+================================
+
+Event Code 0x0018
+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.
--
1.8.5.3
^ permalink raw reply related
* Re: partial success with PS3 sixaxis
From: Andrea @ 2014-02-15 12:10 UTC (permalink / raw)
To: Szymon Janc; +Cc: linux-bluetooth
In-Reply-To: <2534491.XllyezJg3g@uw000953>
On 13/02/14 09:25, Szymon Janc wrote:
> Hi Andrea,
>
> This should "just work". Since 5.14 there is authorization needed when DS3 is
> connecting (device is not marked as trusted when connected on USB) so please
> make sure you have default agent registered.
>
> I assume you are using bluetoothctl so do:
> agent on
> default-agent
>
> Then you should get authorization request in bluetoothctl when DS3 is connecting.
>
I think the problem is not authorisation (I do not get such a request, by I did use the trust
command, so maybe it is not necessary any more). It gets connected, it creates /dev/input/js0 but it
deletes it shortly after.
I run bluetoothd in debug mode and this is what it prints
bluetoothd[13678]: src/adapter.c:connected_callback() hci0 device 00:1B:FB:63:F2:64 connected eir_len 5
bluetoothd[13678]: profiles/input/server.c:connect_event_cb() Incoming connection from
00:1B:FB:63:F2:64 on PSM 17
bluetoothd[13678]: profiles/input/device.c:input_device_set_channel() idev 0x1dec160 psm 17
bluetoothd[13678]: profiles/input/server.c:confirm_event_cb()
bluetoothd[13678]: profiles/input/server.c:connect_event_cb() Incoming connection from
00:1B:FB:63:F2:64 on PSM 19
bluetoothd[13678]: profiles/input/device.c:input_device_set_channel() idev 0x1dec160 psm 19
bluetoothd[13678]: src/service.c:change_state() 0x1deb1c0: device 00:1B:FB:63:F2:64 profile
input-hid state changed: disconnected -> connected (0)
bluetoothd[13678]: sixaxis: compatible device connected: PLAYSTATION(R)3 Controller (054C:0268)
< ===================================== here I disconnect manually, as /dev/input/js0 has already
been deleted>
bluetoothd[13678]: src/service.c:change_state() 0x1deb1c0: device 00:1B:FB:63:F2:64 profile
input-hid state changed: connected -> disconnecting (0)
bluetoothd[13678]: profiles/input/device.c:input_device_disconnect()
bluetoothd[13678]: Input: disconnect /org/bluez/hci0/dev_00_1B_FB_63_F2_64
bluetoothd[13678]: profiles/input/device.c:ctrl_watch_cb() Device 00:1B:FB:63:F2:64 disconnected
bluetoothd[13678]: profiles/input/device.c:intr_watch_cb() Device 00:1B:FB:63:F2:64 disconnected
bluetoothd[13678]: src/service.c:change_state() 0x1deb1c0: device 00:1B:FB:63:F2:64 profile
input-hid state changed: disconnecting -> disconnected (0)
bluetoothd[13678]: profiles/input/device.c:input_device_enter_reconnect_mode()
path=/org/bluez/hci0/dev_00_1B_FB_63_F2_64 reconnect_mode=device
bluetoothd[13678]: src/adapter.c:dev_disconnected() Device 00:1B:FB:63:F2:64 disconnected, reason 2
bluetoothd[13678]: src/adapter.c:adapter_remove_connection()
bluetoothd[13678]: src/adapter.c:bonding_attempt_complete() hci0 bdaddr 00:1B:FB:63:F2:64 type 0
status 0xe
bluetoothd[13678]: src/device.c:device_bonding_complete() bonding (nil) status 0x0e
bluetoothd[13678]: src/device.c:device_bonding_failed() status 14
bluetoothd[13678]: src/adapter.c:resume_discovery()
Halfway through I disconnected the controller with
disconnect XX:XX:XX:XX:XX in bluetoothtcl
at the same time in the kernel log I can see
Feb 15 12:08:29 alarmpi kernel: sony 0005:054C:0268.0010: Fixing up Sony Sixaxis report descriptor
Feb 15 12:08:29 alarmpi kernel: sony 0005:054C:0268.0010: unknown main item tag 0x0
Feb 15 12:08:29 alarmpi kernel: input: PLAYSTATION(R)3 Controller as
/devices/platform/bcm2708_usb/usb1/1-1/1-1.3/1-1.3.1/1-1.3.1:1.0/blu
Feb 15 12:08:29 alarmpi kernel: sony 0005:054C:0268.0010: input,hidraw0: BLUETOOTH HID v1.00
Joystick [PLAYSTATION(R)3 Controller] on 00:
Feb 15 12:08:39 alarmpi kernel: sony: probe of 0005:054C:0268.0010 failed with error -5
which mention some issues with descriptor, tag and probe.
I am not too familiar with whom is responsible for /dev/input/js0? kernel? bluez? the sixaxis plugin?
Since this controller always works with the alternative sixad daemon, can I log the traffic and
compare it? or maybe post it here so some of you guys can help me?
thank you
^ permalink raw reply
* [PATCH v3] btusb.c - Add IMC Networks (Broadcom based)
From: Jurgen Kramer @ 2014-02-15 11:01 UTC (permalink / raw)
To: linux-bluetooth; +Cc: marcel, Jurgen Kramer
Add support for IMC Networks (Broadcom based) to btusb.c.
v3: Switch to using USB_VENDOR_AND_INTERFACE_INFO.
Below the output of /sys/kernel/debug/usb/devices for this device:
T: Bus=01 Lev=02 Prnt=02 Port=04 Cnt=01 Dev#= 3 Spd=12 MxCh= 0
D: Ver= 2.00 Cls=ff(vend.) Sub=01 Prot=01 MxPS=64 #Cfgs= 1
P: Vendor=13d3 ProdID=3404 Rev= 1.12
S: Manufacturer=Broadcom Corp
S: Product=BCM20702A0
S: SerialNumber=240A649F8246
C:* #Ifs= 4 Cfg#= 1 Atr=e0 MxPwr= 0mA
I:* If#= 0 Alt= 0 #EPs= 3 Cls=ff(vend.) 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=ff(vend.) 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=ff(vend.) 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=ff(vend.) 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=ff(vend.) 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=ff(vend.) 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=ff(vend.) 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
I:* If#= 2 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=(none)
E: Ad=84(I) Atr=02(Bulk) MxPS= 32 Ivl=0ms
E: Ad=04(O) Atr=02(Bulk) MxPS= 32 Ivl=0ms
I:* If#= 3 Alt= 0 #EPs= 0 Cls=fe(app. ) Sub=01 Prot=01 Driver=(none)
Signed-off-by: Jurgen Kramer <gtmkramer@xs4all.nl>
---
drivers/bluetooth/btusb.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/bluetooth/btusb.c b/drivers/bluetooth/btusb.c
index 3980fd1..a372df8 100644
--- a/drivers/bluetooth/btusb.c
+++ b/drivers/bluetooth/btusb.c
@@ -116,6 +116,9 @@ static const struct usb_device_id btusb_table[] = {
/* Belkin F8065bf - Broadcom based */
{ USB_VENDOR_AND_INTERFACE_INFO(0x050d, 0xff, 0x01, 0x01) },
+ /* IMC Networks - Broadcom based */
+ { USB_VENDOR_AND_INTERFACE_INFO(0x13d3, 0xff, 0x01, 0x01 },
+
{ } /* Terminating entry */
};
--
1.8.5.3
^ permalink raw reply related
* [RFC] doc: Add management commands and events for privacy support
From: Marcel Holtmann @ 2014-02-15 10:53 UTC (permalink / raw)
To: linux-bluetooth
---
doc/mgmt-api.txt | 82 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++
1 file changed, 82 insertions(+)
diff --git a/doc/mgmt-api.txt b/doc/mgmt-api.txt
index c5c84291a044..004d2f2965ad 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.
@@ -1468,6 +1469,68 @@ Set Debug Keys Command
Invalid Index
+Set Privacy Command
+===================
+
+ Command Code: 0x002F
+ Controller Index: <controller id>
+ Command Parameters: Privacy (1 Octet)
+ Identity_Address_Type (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.
+
+ Possible values for the Identity_Address_Type parameter:
+ 1 LE Public
+ 2 LE Random
+
+ With LE Public, the controller's public address will be used as
+ identity address. With LE Random, the configured static address
+ will be used as identity address.
+
+ 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.
+
+ 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
======================
@@ -1884,3 +1947,22 @@ 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.
+
+
+New Identity Resolving Key Event
+================================
+
+Event Code 0x0018
+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.
--
1.8.5.3
^ permalink raw reply related
* Re: [RFC v8 04/10] Bluetooth: Remove unused function
From: Marcel Holtmann @ 2014-02-14 22:28 UTC (permalink / raw)
To: Andre Guedes; +Cc: bluez mailin list (linux-bluetooth@vger.kernel.org)
In-Reply-To: <1391639006-26311-4-git-send-email-andre.guedes@openbossa.org>
Hi Andre,
> This patch removes hci_create_le_conn() since it is not used anymore.
>
> Signed-off-by: Andre Guedes <andre.guedes@openbossa.org>
> ---
> net/bluetooth/hci_conn.c | 32 --------------------------------
> 1 file changed, 32 deletions(-)
>
> diff --git a/net/bluetooth/hci_conn.c b/net/bluetooth/hci_conn.c
> index 166d7a5..70f4226 100644
> --- a/net/bluetooth/hci_conn.c
> +++ b/net/bluetooth/hci_conn.c
> @@ -551,38 +551,6 @@ done:
> hci_dev_unlock(hdev);
> }
>
> -static int hci_create_le_conn(struct hci_conn *conn)
> -{
> - struct hci_dev *hdev = conn->hdev;
> - struct hci_cp_le_create_conn cp;
> - struct hci_request req;
> - int err;
> -
> - hci_req_init(&req, hdev);
> -
> - memset(&cp, 0, sizeof(cp));
> - cp.scan_interval = cpu_to_le16(hdev->le_scan_interval);
> - cp.scan_window = cpu_to_le16(hdev->le_scan_window);
> - bacpy(&cp.peer_addr, &conn->dst);
> - cp.peer_addr_type = conn->dst_type;
> - cp.own_address_type = conn->src_type;
> - cp.conn_interval_min = cpu_to_le16(conn->le_conn_min_interval);
> - cp.conn_interval_max = cpu_to_le16(conn->le_conn_max_interval);
> - cp.supervision_timeout = __constant_cpu_to_le16(0x002a);
> - cp.min_ce_len = __constant_cpu_to_le16(0x0000);
> - cp.max_ce_len = __constant_cpu_to_le16(0x0000);
> -
> - hci_req_add(&req, HCI_OP_LE_CREATE_CONN, sizeof(cp), &cp);
> -
> - err = hci_req_run(&req, create_le_conn_complete);
> - if (err) {
> - hci_conn_del(conn);
> - return err;
> - }
> -
> - return 0;
> -}
> -
> static void create_le_conn_req(struct hci_request *req, struct hci_conn *conn)
> {
> struct hci_cp_le_create_conn cp;
not about this patch, but with my other comment, this one might be better renamed into hci_req_add_le_create_conn at some point. Not urgent though.
Regards
Marcel
^ permalink raw reply
* Re: [RFC v8 02/10] Bluetooth: Declare le_conn_failed in hci_core.h
From: Marcel Holtmann @ 2014-02-14 22:26 UTC (permalink / raw)
To: Andre Guedes; +Cc: bluez mailin list (linux-bluetooth@vger.kernel.org)
In-Reply-To: <1391639006-26311-2-git-send-email-andre.guedes@openbossa.org>
Hi Andre,
> This patch adds the "hci_" prefix to le_conn_failed() helper and
> declares it in hci_core.h so it can be reused in hci_event.c.
>
> Signed-off-by: Andre Guedes <andre.guedes@openbossa.org>
> ---
> include/net/bluetooth/hci_core.h | 2 ++
> net/bluetooth/hci_conn.c | 4 ++--
> net/bluetooth/hci_event.c | 6 +-----
> 3 files changed, 5 insertions(+), 7 deletions(-)
>
> diff --git a/include/net/bluetooth/hci_core.h b/include/net/bluetooth/hci_core.h
> index 8aff7f9..6e5062c 100644
> --- a/include/net/bluetooth/hci_core.h
> +++ b/include/net/bluetooth/hci_core.h
> @@ -627,6 +627,8 @@ int hci_conn_switch_role(struct hci_conn *conn, __u8 role);
>
> void hci_conn_enter_active_mode(struct hci_conn *conn, __u8 force_active);
>
> +void hci_le_conn_failed(struct hci_conn *conn, u8 status);
> +
> /*
> * hci_conn_get() and hci_conn_put() are used to control the life-time of an
> * "hci_conn" object. They do not guarantee that the hci_conn object is running,
> diff --git a/net/bluetooth/hci_conn.c b/net/bluetooth/hci_conn.c
> index 6797292..4f5029c 100644
> --- a/net/bluetooth/hci_conn.c
> +++ b/net/bluetooth/hci_conn.c
> @@ -515,7 +515,7 @@ struct hci_dev *hci_get_route(bdaddr_t *dst, bdaddr_t *src)
> EXPORT_SYMBOL(hci_get_route);
>
> /* This function requires the caller holds hdev->lock */
> -static void le_conn_failed(struct hci_conn *conn, u8 status)
> +void hci_le_conn_failed(struct hci_conn *conn, u8 status)
> {
> struct hci_dev *hdev = conn->hdev;
>
> @@ -545,7 +545,7 @@ static void create_le_conn_complete(struct hci_dev *hdev, u8 status)
> if (!conn)
> goto done;
>
> - le_conn_failed(conn, status);
> + hci_le_conn_failed(conn, status);
>
> done:
> hci_dev_unlock(hdev);
> diff --git a/net/bluetooth/hci_event.c b/net/bluetooth/hci_event.c
> index d2c6878..df58cde 100644
> --- a/net/bluetooth/hci_event.c
> +++ b/net/bluetooth/hci_event.c
> @@ -3601,11 +3601,7 @@ static void hci_le_conn_complete_evt(struct hci_dev *hdev, struct sk_buff *skb)
> }
>
> if (ev->status) {
> - mgmt_connect_failed(hdev, &conn->dst, conn->type,
> - conn->dst_type, ev->status);
> - hci_proto_connect_cfm(conn, ev->status);
> - conn->state = BT_CLOSED;
> - hci_conn_del(conn);
> + hci_le_conn_failed(conn, ev->status);
> goto unlock;
> }
what is the difference between a le_conn_failed and a generic conn_failed.
I am not sure about the naming of this function if we make it non-static. Not that I have a better name at the moment. So we might just go ahead with it.
Regards
Marcel
^ permalink raw reply
* Re: [RFC v8 01/10] Bluetooth: Create hci_stop_le_scan_req() helper
From: Marcel Holtmann @ 2014-02-14 22:21 UTC (permalink / raw)
To: Andre Guedes; +Cc: bluez mailin list (linux-bluetooth@vger.kernel.org)
In-Reply-To: <1391639006-26311-1-git-send-email-andre.guedes@openbossa.org>
Hi Andre,
> This patch moves stop LE scanning duplicate code to one single
> place and reuses it. This will avoid more duplicate code in
> upcoming patches.
>
> Signed-off-by: Andre Guedes <andre.guedes@openbossa.org>
> ---
> include/net/bluetooth/hci_core.h | 2 ++
> net/bluetooth/hci_core.c | 14 ++++++++++----
> net/bluetooth/mgmt.c | 6 +-----
> 3 files changed, 13 insertions(+), 9 deletions(-)
>
> diff --git a/include/net/bluetooth/hci_core.h b/include/net/bluetooth/hci_core.h
> index 92fa75f..8aff7f9 100644
> --- a/include/net/bluetooth/hci_core.h
> +++ b/include/net/bluetooth/hci_core.h
> @@ -1212,4 +1212,6 @@ void hci_le_start_enc(struct hci_conn *conn, __le16 ediv, __u8 rand[8],
> #define SCO_AIRMODE_CVSD 0x0000
> #define SCO_AIRMODE_TRANSP 0x0003
>
> +void hci_stop_le_scan_req(struct hci_request *req);
> +
this should be close to hci_req_add definition.
> #endif /* __HCI_CORE_H */
> diff --git a/net/bluetooth/hci_core.c b/net/bluetooth/hci_core.c
> index e774669..6529f4a 100644
> --- a/net/bluetooth/hci_core.c
> +++ b/net/bluetooth/hci_core.c
> @@ -3058,7 +3058,6 @@ static void le_scan_disable_work(struct work_struct *work)
> {
> struct hci_dev *hdev = container_of(work, struct hci_dev,
> le_scan_disable.work);
> - struct hci_cp_le_set_scan_enable cp;
> struct hci_request req;
> int err;
>
> @@ -3066,9 +3065,7 @@ static void le_scan_disable_work(struct work_struct *work)
>
> hci_req_init(&req, hdev);
>
> - memset(&cp, 0, sizeof(cp));
> - cp.enable = LE_SCAN_DISABLE;
> - hci_req_add(&req, HCI_OP_LE_SET_SCAN_ENABLE, sizeof(cp), &cp);
> + hci_stop_le_scan_req(&req);
>
> err = hci_req_run(&req, le_scan_disable_work_complete);
> if (err)
> @@ -4523,3 +4520,12 @@ static void hci_cmd_work(struct work_struct *work)
> }
> }
> }
> +
> +void hci_stop_le_scan_req(struct hci_request *req)
> +{
> + struct hci_cp_le_set_scan_enable cp;
> +
> + memset(&cp, 0, sizeof(cp));
> + cp.enable = LE_SCAN_DISABLE;
> + hci_req_add(req, HCI_OP_LE_SET_SCAN_ENABLE, sizeof(cp), &cp);
> +}
Can we call this function hci_req_add_le_scan_disable. We should be explicit on what functions are doing. Helpers are just helpers.
> diff --git a/net/bluetooth/mgmt.c b/net/bluetooth/mgmt.c
> index ce7ef33..5c0d55d 100644
> --- a/net/bluetooth/mgmt.c
> +++ b/net/bluetooth/mgmt.c
> @@ -3400,7 +3400,6 @@ static int stop_discovery(struct sock *sk, struct hci_dev *hdev, void *data,
> struct hci_cp_remote_name_req_cancel cp;
> struct inquiry_entry *e;
> struct hci_request req;
> - struct hci_cp_le_set_scan_enable enable_cp;
> int err;
>
> BT_DBG("%s", hdev->name);
> @@ -3436,10 +3435,7 @@ static int stop_discovery(struct sock *sk, struct hci_dev *hdev, void *data,
> } else {
> cancel_delayed_work(&hdev->le_scan_disable);
>
> - memset(&enable_cp, 0, sizeof(enable_cp));
> - enable_cp.enable = LE_SCAN_DISABLE;
> - hci_req_add(&req, HCI_OP_LE_SET_SCAN_ENABLE,
> - sizeof(enable_cp), &enable_cp);
> + hci_stop_le_scan_req(&req);
> }
>
> break;
Regards
Marcel
^ permalink raw reply
* Re: [PATCH 00/24] rfcomm fixes
From: Marcel Holtmann @ 2014-02-14 21:45 UTC (permalink / raw)
To: Peter Hurley
Cc: Gustavo F. Padovan, Johan Hedberg, Gianluca Anzolin,
Alexander Holler, Andrey Vihrov, Sander Eikelenboom,
bluez mailin list (linux-bluetooth@vger.kernel.org), linux-kernel
In-Reply-To: <1391997564-1805-1-git-send-email-peter@hurleysoftware.com>
Hi Peter,
> This patch series addresses a number of previously unknown issues
> with the RFCOMM tty device implementation, in addition to
> addressing the locking regression recently reported [1].
>
> As Gianluca suggested and I agree, this series first reverts
> 3 of the 4 patches of 3.14-rc1 for bluetooth/rfcomm/tty.c.
>
> The reasoning is detailed in the changelog for
> Revert "Bluetooth: Always wait for a connection on RFCOMM open()"
> but the short answer is that it re-implements a long-standing
> bug by blocking on a non-blocking open.
>
> This patch series corrects the reported regressions from 3.13
> (to the extent that correction is required). Specifically,
> the ModemManager regression reported by Gianluca Anzolin [2]
> and the rfcomm bind with wvdial reported by Andrey Vihrov [3].
>
> tty: Fix ref counting for port krefs
> Bluetooth: Fix racy acquire of rfcomm_dev reference
> Bluetooth: Exclude released devices from RFCOMMGETDEVLIST ioctl
> Bluetooth: Release rfcomm_dev only once
> Bluetooth: Fix unreleased rfcomm_dev reference
> These first 5 patches after the reverts
> fix 4 different rfcomm_dev ref count mishandling bugs.
>
> Bluetooth: Fix RFCOMM tty teardown race and
> Bluetooth: Serialize RFCOMMCREATEDEV and RFCOMMRELEASEDEV ioctls
> Fix races which occur due to the design of the rfcomm ioctls
> (note that buses don't have these kinds of races).
>
> Bluetooth: Verify dlci not in use before rfcomm_dev create
> Bluetooth: Simplify RFCOMM session state eval
> Bluetooth: Refactor deferred setup test in rfcomm_dlc_close()
> Bluetooth: Refactor dlc disconnect logic in rfcomm_dlc_close()
> Bluetooth: Directly close dlc for not yet started RFCOMM session
> These 5 patches fix issues with reusing the dlci after
> closing the tty (found by unit test).
>
> Bluetooth: Fix unsafe RFCOMM device parenting
> Bluetooth: Fix RFCOMM parent device for reused dlc
> These 2 patches fix the ModemManager regression.
>
> Bluetooth: Refactor rfcomm_dev_add()
> Bluetooth: Cleanup RFCOMM device registration error handling
> These 2 patches fix an unreleased module reference while
> error handling.
>
> Bluetooth: Rename __rfcomm_dev_get() to __rfcomm_dev_lookup()
> This is a trivial naming patch with no functional impact.
>
> Bluetooth: Force -EIO from tty read/write if .activate() fails
> The tty core provides an existing mechanism for failing
> reads/writes if device activation fails (like an error
> allocating the dlc).
>
> Bluetooth: Don't fail RFCOMM tty writes
> This patch implements buffered writes even if the device
> is not connected.
>
> While unit testing this, I discovered a serious defect in
> the way available space is computed that under-utilizes
> rfcomm i/o and may even halt further tx on that link, which
> is fixed by:
> Bluetooth: Refactor write_room() calculation
> Bluetooth: Fix write_room() calculation
>
>
> Note that this series does not fix the naively inefficient
> method of packetizing tty output; packetizing should be
> done on the krfcommd thread to take advantage of aggregating
> multiple tty writes into 1 or more packets. Look at any
> line-by-line console output to realize how under-utilized
> the rfcomm tty packeting is.
>
> [1] http://www.spinics.net/lists/linux-wireless/msg117818.html
> [2] http://www.spinics.net/lists/linux-bluetooth/msg42075.html
> [3] http://www.spinics.net/lists/linux-bluetooth/msg42057.html
>
>
> Regards,
>
>
> Peter Hurley (24):
> Revert "Bluetooth: Remove rfcomm_carrier_raised()"
> Revert "Bluetooth: Always wait for a connection on RFCOMM open()"
> Revert "Bluetooth: Move rfcomm_get_device() before
> rfcomm_dev_activate()”
these 3 patches are in bluetooth-next to give them extra testing. We will get them into 3.14-rc4 after an extra week of them being in linux-next.
> tty: Fix ref counting for port krefs
I am taking this one with Greg’s ack through bluetooth-next. Unless someone objects.
> Bluetooth: Fix racy acquire of rfcomm_dev reference
> Bluetooth: Exclude released devices from RFCOMMGETDEVLIST ioctl
> Bluetooth: Release rfcomm_dev only once
> Bluetooth: Fix unreleased rfcomm_dev reference
> Bluetooth: Fix RFCOMM tty teardown race
> Bluetooth: Verify dlci not in use before rfcomm_dev create
> Bluetooth: Simplify RFCOMM session state eval
> Bluetooth: Refactor deferred setup test in rfcomm_dlc_close()
> Bluetooth: Refactor dlc disconnect logic in rfcomm_dlc_close()
> Bluetooth: Directly close dlc for not yet started RFCOMM session
> Bluetooth: Fix unsafe RFCOMM device parenting
> Bluetooth: Fix RFCOMM parent device for reused dlc
> Bluetooth: Rename __rfcomm_dev_get() to __rfcomm_dev_lookup()
> Bluetooth: Serialize RFCOMMCREATEDEV and RFCOMMRELEASEDEV ioctls
> Bluetooth: Refactor rfcomm_dev_add()
> Bluetooth: Cleanup RFCOMM device registration error handling
> Bluetooth: Force -EIO from tty read/write if .activate() fails
> Bluetooth: Don't fail RFCOMM tty writes
> Bluetooth: Refactor write_room() calculation
> Bluetooth: Fix write_room() calculation
>
> include/linux/tty.h | 6 +-
> include/net/bluetooth/rfcomm.h | 9 +-
> net/bluetooth/rfcomm/core.c | 88 ++++++++++----
> net/bluetooth/rfcomm/tty.c | 262 ++++++++++++++++++++++-------------------
> 4 files changed, 223 insertions(+), 142 deletions(-)
all patches have been applied to bluetooth-next tree.
Regards
Marcel
^ permalink raw reply
* Re: [PATCH] Bluetooth: Officially enable LE CoC support
From: Marcel Holtmann @ 2014-02-14 21:15 UTC (permalink / raw)
To: Johan Hedberg; +Cc: bluez mailin list (linux-bluetooth@vger.kernel.org)
In-Reply-To: <1392356451-14435-1-git-send-email-johan.hedberg@gmail.com>
Hi Johan,
> Now that the LE Connection oriented Channel support has undergone a
> decent amount of testing we can make it officially supported. This patch
> removes the enable_lecoc debugfs switch which was previously needed to
> enable support for LE CoC.
>
> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
> ---
> net/bluetooth/l2cap_core.c | 11 -----------
> net/bluetooth/l2cap_sock.c | 29 -----------------------------
> 2 files changed, 40 deletions(-)
I had to fix the description a bit ;)
Patch has been applied to bluetooth-next tree.
Regards
Marcel
^ permalink raw reply
* Re: [PATCH] btusb.c add IMC Networks id 13d3:3404 (bcm20702A0) - retry
From: Marcel Holtmann @ 2014-02-14 21:02 UTC (permalink / raw)
To: Jurgen Kramer; +Cc: BlueZ development
In-Reply-To: <1392370354.2437.2.camel@develbox>
Hi Jurgen,
> From 343f62050b33972929db749aee296e98332600d6 Mon Sep 17 00:00:00 2001
> From: Jurgen Kramer <gtmkramer@xs4all.nl>
> Date: Fri, 14 Feb 2014 10:22:51 +0100
> Subject: [PATCH] btusb.c add IMC Networks id 13d3:3404 (bcm20702A0)
>
> ---
> drivers/bluetooth/btusb.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/bluetooth/btusb.c b/drivers/bluetooth/btusb.c
> index 3980fd1..5dce16d 100644
> --- a/drivers/bluetooth/btusb.c
> +++ b/drivers/bluetooth/btusb.c
> @@ -106,6 +106,7 @@ static const struct usb_device_id btusb_table[] = {
> { USB_DEVICE(0x04ca, 0x2003) },
> { USB_DEVICE(0x0489, 0xe042) },
> { USB_DEVICE(0x413c, 0x8197) },
> + { USB_DEVICE(0x13d3, 0x3404) },
>
> /* Foxconn - Hon Hai */
> { USB_VENDOR_AND_INTERFACE_INFO(0x0489, 0xff, 0x01, 0x01) },
> --
> 1.8.5.3
>
> Signed-off-by: Jurgen Kramer <gtm.kramer@xs4all.nl>
>
> Retry. I've included the relevant part of the
> requested /sys/kernel/debug/usb/devices output.
>
> Jurgen
> <sys-kernel-debug-usb-devices-0x13d3-0x3404.txt>
can please create a proper patch with git-format-patch and send it with git-send-email. Look at how others have done it. I want the debug/usb/devices part as part of the commit message.
Also since the vendor id 13d3 belongs to IMC networks, you might want to add a comment saying “IMC Networks (Broadcom based)”. Alternative using USB_VENDOR_AND_INTERFACE_INFO might be an option as well.
Regards
Marcel
^ permalink raw reply
* Re: [PATCHv3] hog: Use HoG device name as uHID input device name
From: Petri Gynther @ 2014-02-14 20:49 UTC (permalink / raw)
To: Johan Hedberg, linux-bluetooth
In-Reply-To: <20140213091902.GA2754@x220.p-661hnu-f1>
Hi Johan,
On Thu, Feb 13, 2014 at 1:19 AM, Johan Hedberg <johan.hedberg@gmail.com> wrote:
> Hi Petri,
>
> On Wed, Jan 29, 2014, Petri Gynther wrote:
>> If HoG BLE device name is known, use it when creating uHID input device.
>> Pass adapter and device addresses to uHID as well.
>
> Could you perhaps elaborate a bit what exactly the "uniq" and "phys"
> members are in the request (possibly with a reference to the uHID
> documentation). That would make it easier to verify that the content
> you're adding to them makes sense.
>
>From linux/include/linux/hid.h:
struct hid_device {
...
char name[128]; /* Device name */
char phys[64]; /* Device physical location */
char uniq[64]; /* Device unique identifier (serial #) */
So, for a Bluetooth HID or HoG device, BT adapter MAC address is good
fit for "phys" and device MAC address is good for "uniq". This is what
hidp module in kernel already does. But, we can be more descriptive
here if we want. These values are readable in sysfs under
/sys/devices/virtual/input/<input-device>.
>> + if (device_name_known(hogdev->device)) {
>> + device_get_name(hogdev->device, (char *) ev.u.create.name,
>> + sizeof(ev.u.create.name) - 1);
>> + } else {
>> + strcpy((char *) ev.u.create.name, "bluez-hog-device");
>> + }
>
> We don't use { } for single line branches, so you can drop these here.
>
I'll fix this.
>> + ba2str(btd_adapter_get_address(device_get_adapter(hogdev->device)),
>> + (char *) ev.u.create.phys);
>
> This is getting a bit messy with the nested function calls. I'd add
> separate adapter variable here to make this a bit more readable.
>
> Also note our coding style wrt split lines: indent the continuation
> lines as much as you can (with tabs) as long as it's under 80 chars.
>
> Also, it might be good to split this up into two patches since you've
> essentially got two independent improvements here. One is making sure
> the name member contains something more useful and the other is adding
> some content to the uniq and phys members.
I'll add name, phys, and uniq variables in struct hog_device, so that
they are easy to pass to uHID when it is time to create the uHID
device.
>
> Johan
^ permalink raw reply
* Re: [PATCH v2] Bluetooth: Add hci_h4p driver
From: Sebastian Reichel @ 2014-02-14 17:28 UTC (permalink / raw)
To: Pali Rohár, Ben Hutchings
Cc: Pavel Machek,
Ивайло Димитров,
linux-kernel, linux-bluetooth@vger.kernel.org development
In-Reply-To: <CAHYPw2EJC9RwgzXmGuQgh5_L6EMtS7MW8N3u2dR8KeVc0kb43g@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 2141 bytes --]
Hi Pali,
On Thu, Feb 13, 2014 at 04:33:28PM +0100, Pali Rohár wrote:
> 2014-01-08 22:36 GMT+01:00 Pali Rohár <pali.rohar@gmail.com>:
> > On Monday 30 December 2013 15:52:51 Sebastian Reichel wrote:
> >> > > > +MODULE_DESCRIPTION("Bluetooth h4 driver with nokia
> >> > > > extensions"); +MODULE_LICENSE("GPL");
> >> > > > +MODULE_AUTHOR("Ville Tervo");
> >> > > > +MODULE_FIRMWARE(FW_NAME_TI1271_PRELE);
> >> > > > +MODULE_FIRMWARE(FW_NAME_TI1271_LE);
> >> > > > +MODULE_FIRMWARE(FW_NAME_TI1271);
> >> > > > +MODULE_FIRMWARE(FW_NAME_BCM2048);
> >> > > > +MODULE_FIRMWARE(FW_NAME_CSR);
> >> > >
> >> > > Do we actually have all these firmware files still
> >> > > available. If not, then focus on the ones we have.
> >> >
> >> > Firmware files are available for download from nemo project:
> >> >
> >> > https://api.merproject.org/public/source/nemo:devel:hw:ti:om
> >> > ap3:n900/bcm-bt-firmware/bcm-bt-firmware-0.21rc3.tar.bz2
> >> > https://api.merproject.org/public/source/nemo:devel:hw:ti:o
> >> > map3:n950-n9/ti-wl1273-bt-firmware/bt-firmware-ti1273_0.23+0
> >> > m6.tar.gz
> >>
> >> Would be nice to have them added to the linux-firmware.git.
> >
> Now when driver is queued for staging, can somebody add firmware files
> to linux-firmware repository? Note that without firmware files, driver
> not working...
I just had a look at the file for the Nokia N900
(bcm-bt-firmware-0.21rc3.tar.bz2) and I think the license is too
restrictive for linux-firmware.git. Actually I can't see any
statement allowing redistribution. For reference this is the license
text:
Copyright (c) Nokia Corporation 2010
All Rights Reserved.
This material, including documentation and any related computer programs, is
protected by copyright controlled by Nokia Corporation. All rights are
reserved. Modifying, adapting and/or translating, any or all of this material
requires the prior written consent of Nokia. Distribution for commercial
purposes not allowed without prior written approval from Nokia.
Anyways, I added Ben to the discussion (maintainer of the
linux-firmware repository)
-- Sebastian
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* [PATCH BlueZ 8/8] doc/obex-api: Update documentation
From: Luiz Augusto von Dentz @ 2014-02-14 15:53 UTC (permalink / raw)
To: linux-bluetooth; +Cc: patrick.ohly
In-Reply-To: <1392393184-15266-1-git-send-email-luiz.dentz@gmail.com>
From: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
This adds Suspend and Resume methods and 'suspended' value as status in
the Transfer interface documentation.
---
doc/obex-api.txt | 18 ++++++++++++++++--
1 file changed, 16 insertions(+), 2 deletions(-)
diff --git a/doc/obex-api.txt b/doc/obex-api.txt
index 1f22fea..0f57ce1 100644
--- a/doc/obex-api.txt
+++ b/doc/obex-api.txt
@@ -90,12 +90,26 @@ Methods void Cancel()
org.bluez.obex.Error.InProgress
org.bluez.obex.Error.Failed
+ void Suspend()
+
+ Suspend transference.
+
+ Possible errors: org.bluez.obex.Error.NotAuthorized
+ org.bluez.obex.Error.NotInProgress
+
+ void Resume()
+
+ Resume transference.
+
+ Possible errors: org.bluez.obex.Error.NotAuthorized
+ org.bluez.obex.Error.NotInProgress
+
Properties string Status [readonly]
Inform the current status of the transfer.
- Possible values: "queued", "active", "complete" or
- "error"
+ Possible values: "queued", "active", "suspended",
+ "complete" or "error"
object Session [readonly]
--
1.8.5.3
^ permalink raw reply related
* [PATCH BlueZ 7/8] gobex: Handle suspending/resuming for GET when SRM is active
From: Luiz Augusto von Dentz @ 2014-02-14 15:53 UTC (permalink / raw)
To: linux-bluetooth; +Cc: patrick.ohly
In-Reply-To: <1392393184-15266-1-git-send-email-luiz.dentz@gmail.com>
From: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
This adds support for suspending/resuming GET requests GET when SRM is
active, in this case suspending the TX queue wont stop the remote
to continue sending packets, to do that SRMP header should be set to wait
so the remote should wait.
---
gobex/gobex-transfer.c | 2 +-
gobex/gobex.c | 56 ++++++++++++++++++++++++++++++++++++++++++++++++--
2 files changed, 55 insertions(+), 3 deletions(-)
diff --git a/gobex/gobex-transfer.c b/gobex/gobex-transfer.c
index b815d60..09f56ba 100644
--- a/gobex/gobex-transfer.c
+++ b/gobex/gobex-transfer.c
@@ -390,7 +390,7 @@ static void transfer_put_req(GObex *obex, GObexPacket *req, gpointer user_data)
rspcode = put_get_bytes(transfer, req);
- /* Don't send continue while in SRM */
+ /* Don't send continue while SRM is active */
if (g_obex_srm_active(transfer->obex) &&
rspcode == G_OBEX_RSP_CONTINUE)
goto done;
diff --git a/gobex/gobex.c b/gobex/gobex.c
index 291ed72..0d9b449 100644
--- a/gobex/gobex.c
+++ b/gobex/gobex.c
@@ -105,6 +105,7 @@ struct pending_pkt {
GObexResponseFunc rsp_func;
gpointer rsp_data;
gboolean cancelled;
+ gboolean suspended;
};
struct req_handler {
@@ -407,7 +408,9 @@ static void setup_srm(GObex *obex, GObexPacket *pkt, gboolean outgoing)
g_obex_header_get_uint8(hdr, &srmp);
g_obex_debug(G_OBEX_DEBUG_COMMAND, "srmp 0x%02x", srmp);
set_srmp(obex, srmp, outgoing);
- } else
+ } else if (obex->pending_req && obex->pending_req->suspended)
+ g_obex_packet_add_uint8(pkt, G_OBEX_HDR_SRMP, G_OBEX_SRMP_WAIT);
+ else
set_srmp(obex, -1, outgoing);
if (final)
@@ -845,24 +848,73 @@ gboolean g_obex_remove_request_function(GObex *obex, guint id)
return TRUE;
}
+static void g_obex_srm_suspend(GObex *obex)
+{
+ struct pending_pkt *p = obex->pending_req;
+ GObexPacket *req;
+
+ g_source_remove(p->timeout_id);
+ p->suspended = TRUE;
+
+ req = g_obex_packet_new(G_OBEX_OP_GET, TRUE,
+ G_OBEX_HDR_SRMP, G_OBEX_SRMP_WAIT,
+ G_OBEX_HDR_INVALID);
+
+ g_obex_send(obex, req, NULL);
+}
+
void g_obex_suspend(GObex *obex)
{
+ struct pending_pkt *req = obex->pending_req;
+
g_obex_debug(G_OBEX_DEBUG_COMMAND, "conn %u", obex->conn_id);
+ if (!g_obex_srm_active(obex) || !req)
+ goto done;
+
+ /* Send SRMP wait in case of GET */
+ if (g_obex_packet_get_operation(req->pkt, NULL) == G_OBEX_OP_GET) {
+ g_obex_srm_suspend(obex);
+ return;
+ }
+
+done:
+ obex->suspended = TRUE;
+
if (obex->write_source > 0) {
g_source_remove(obex->write_source);
obex->write_source = 0;
}
+}
- obex->suspended = TRUE;
+static void g_obex_srm_resume(GObex *obex)
+{
+ struct pending_pkt *p = obex->pending_req;
+ GObexPacket *req;
+
+ p->timeout_id = g_timeout_add_seconds(p->timeout, req_timeout, obex);
+ p->suspended = FALSE;
+
+ req = g_obex_packet_new(G_OBEX_OP_GET, TRUE, G_OBEX_HDR_INVALID);
+
+ g_obex_send(obex, req, NULL);
}
void g_obex_resume(GObex *obex)
{
+ struct pending_pkt *req = obex->pending_req;
+
g_obex_debug(G_OBEX_DEBUG_COMMAND, "conn %u", obex->conn_id);
obex->suspended = FALSE;
+ if (g_obex_srm_active(obex) || !req)
+ goto done;
+
+ if (g_obex_packet_get_operation(req->pkt, NULL) == G_OBEX_OP_GET)
+ g_obex_srm_resume(obex);
+
+done:
if (g_queue_get_length(obex->tx_queue) > 0 || obex->tx_data > 0)
enable_tx(obex);
}
--
1.8.5.3
^ permalink raw reply related
* [PATCH BlueZ 6/8] gobex: Fix not handling SRM properly
From: Luiz Augusto von Dentz @ 2014-02-14 15:53 UTC (permalink / raw)
To: linux-bluetooth; +Cc: patrick.ohly
In-Reply-To: <1392393184-15266-1-git-send-email-luiz.dentz@gmail.com>
From: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
SRM can be enabled but while not active with use of SRMP header so the
handling of this states needs to be separated.
---
gobex/gobex.c | 24 ++++++++++++++++--------
1 file changed, 16 insertions(+), 8 deletions(-)
diff --git a/gobex/gobex.c b/gobex/gobex.c
index 8c08b1e..291ed72 100644
--- a/gobex/gobex.c
+++ b/gobex/gobex.c
@@ -355,9 +355,20 @@ done:
obex->srm = NULL;
}
+static gboolean g_obex_srm_enabled(GObex *obex)
+{
+ if (!obex->use_srm)
+ return FALSE;
+
+ if (obex->srm == NULL)
+ return FALSE;
+
+ return obex->srm->enabled;
+}
+
static void check_srm_final(GObex *obex, guint8 op)
{
- if (obex->srm == NULL || !obex->srm->enabled)
+ if (!g_obex_srm_enabled(obex))
return;
switch (obex->srm->op) {
@@ -423,7 +434,7 @@ static gboolean write_data(GIOChannel *io, GIOCondition cond,
setup_srm(obex, p->pkt, TRUE);
- if (g_obex_srm_active(obex))
+ if (g_obex_srm_enabled(obex))
goto encode;
/* Can't send a request while there's a pending one */
@@ -646,7 +657,7 @@ guint g_obex_send_req(GObex *obex, GObexPacket *req, int timeout,
if (obex->rx_last_op == G_OBEX_RSP_CONTINUE)
goto create_pending;
- if (g_obex_srm_active(obex) && obex->pending_req != NULL)
+ if (g_obex_srm_enabled(obex) && obex->pending_req != NULL)
goto create_pending;
hdr = g_obex_packet_get_header(req, G_OBEX_HDR_CONNECTION);
@@ -860,10 +871,7 @@ gboolean g_obex_srm_active(GObex *obex)
{
gboolean ret = FALSE;
- if (!obex->use_srm)
- return FALSE;
-
- if (obex->srm == NULL || !obex->srm->enabled)
+ if (!g_obex_srm_enabled(obex))
goto done;
if (obex->srm->srmp <= G_OBEX_SRMP_NEXT_WAIT)
@@ -912,7 +920,7 @@ static gboolean parse_response(GObex *obex, GObexPacket *rsp)
setup_srm(obex, rsp, FALSE);
- if (!g_obex_srm_active(obex))
+ if (!g_obex_srm_enabled(obex))
return final;
/*
--
1.8.5.3
^ permalink raw reply related
* [PATCH BlueZ 5/8] unit/test-gobex-transfer: Add /gobex/test_packet_get_req_suspend_resume
From: Luiz Augusto von Dentz @ 2014-02-14 15:53 UTC (permalink / raw)
To: linux-bluetooth; +Cc: patrick.ohly
In-Reply-To: <1392393184-15266-1-git-send-email-luiz.dentz@gmail.com>
From: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
This adds a test to call g_obex_suspend and latter g_obex_resume while
SRM is enabled.
---
unit/test-gobex-transfer.c | 81 +++++++++++++++++++++++++++++++++++++++++++---
1 file changed, 77 insertions(+), 4 deletions(-)
diff --git a/unit/test-gobex-transfer.c b/unit/test-gobex-transfer.c
index 7c9fd43..0d26111 100644
--- a/unit/test-gobex-transfer.c
+++ b/unit/test-gobex-transfer.c
@@ -106,6 +106,9 @@ static guint8 get_req_first_srm_wait[] = { G_OBEX_OP_GET | FINAL_BIT, 0x00, 0x27
0, 'f', 0, 'i', 0, 'l', 0, 'e', 0, '.', 0, 't', 0, 'x', 0, 't', 0, 0,
G_OBEX_HDR_SRMP, 0x01 };
+static guint8 get_req_srm_wait[] = { G_OBEX_OP_GET | FINAL_BIT, 0x00, 0x05,
+ G_OBEX_HDR_SRMP, 0x01 };
+
static guint8 get_req_last[] = { G_OBEX_OP_GET | FINAL_BIT, 0x00, 0x03, };
static guint8 get_rsp_first_app[] = { G_OBEX_RSP_CONTINUE | FINAL_BIT, 0x00, 0x0A,
@@ -124,6 +127,8 @@ static guint8 get_rsp_first_srm_wait_next[] = { G_OBEX_RSP_CONTINUE | FINAL_BIT,
G_OBEX_HDR_SRMP, 0x02,
G_OBEX_HDR_BODY, 0x00, 0x0d,
0, 1, 2, 3, 4, 5, 6, 7, 8, 9 };
+static guint8 get_rsp_srm_wait[] = { G_OBEX_RSP_CONTINUE | FINAL_BIT,
+ 0x00, 0x03 };
static guint8 get_rsp_zero[255] = { G_OBEX_RSP_CONTINUE | FINAL_BIT, 0x00, 0xff,
G_OBEX_HDR_BODY, 0x00, 0xfc };
static guint8 get_rsp_zero_wait_next[255] = { G_OBEX_RSP_CONTINUE | FINAL_BIT,
@@ -191,7 +196,13 @@ static void transfer_complete(GObex *obex, GError *err, gpointer user_data)
static gboolean resume_obex(gpointer user_data)
{
- g_obex_resume(user_data);
+ struct test_data *d = user_data;
+
+ if (!g_main_loop_is_running(d->mainloop))
+ return FALSE;
+
+ g_obex_resume(d->obex);
+
return FALSE;
}
@@ -232,7 +243,7 @@ static gssize provide_eagain(void *buf, gsize len, gpointer user_data)
}
if (d->provide_delay > 0) {
- g_timeout_add(d->provide_delay, resume_obex, d->obex);
+ g_timeout_add(d->provide_delay, resume_obex, d);
d->provide_delay = 0;
return -EAGAIN;
}
@@ -260,7 +271,7 @@ static gssize provide_data(void *buf, gsize len, gpointer user_data)
if (d->provide_delay > 0) {
g_obex_suspend(d->obex);
- g_timeout_add(d->provide_delay, resume_obex, d->obex);
+ g_timeout_add(d->provide_delay, resume_obex, d);
}
d->total += sizeof(body_data);
@@ -852,6 +863,66 @@ static void test_packet_get_req_wait(void)
g_assert_no_error(d.err);
}
+static gboolean rcv_seq_delay(const void *buf, gsize len, gpointer user_data)
+{
+ struct test_data *d = user_data;
+
+ if (d->provide_delay > 0) {
+ g_obex_suspend(d->obex);
+ g_idle_add(resume_obex, d);
+ d->provide_delay = 0;
+ }
+
+ return TRUE;
+}
+
+static void test_packet_get_req_suspend_resume(void)
+{
+ GIOChannel *io;
+ GIOCondition cond;
+ guint io_id, timer_id;
+ GObex *obex;
+ struct test_data d = { 0, NULL, {
+ { get_req_first_srm, sizeof(get_req_first_srm) },
+ { get_req_srm_wait, sizeof(get_req_srm_wait) },
+ { get_req_srm_wait, sizeof(get_req_srm_wait) },
+ { get_req_last, sizeof(get_req_last) } }, {
+ { get_rsp_first_srm, sizeof(get_rsp_first_srm) },
+ { get_rsp_srm_wait, sizeof(get_rsp_srm_wait) },
+ { get_rsp_srm_wait, sizeof(get_rsp_srm_wait) },
+ { get_rsp_last, sizeof(get_rsp_last) } } };
+
+ create_endpoints(&obex, &io, SOCK_SEQPACKET);
+ d.obex = obex;
+ d.provide_delay = 1;
+
+ cond = G_IO_IN | G_IO_HUP | G_IO_ERR | G_IO_NVAL;
+ io_id = g_io_add_watch(io, cond, test_io_cb, &d);
+
+ d.mainloop = g_main_loop_new(NULL, FALSE);
+
+ timer_id = g_timeout_add_seconds(1, test_timeout, &d);
+
+ g_obex_get_req(obex, rcv_seq_delay, transfer_complete, &d, &d.err,
+ G_OBEX_HDR_TYPE, hdr_type, sizeof(hdr_type),
+ G_OBEX_HDR_NAME, "file.txt",
+ G_OBEX_HDR_INVALID);
+ g_assert_no_error(d.err);
+
+ g_main_loop_run(d.mainloop);
+
+ g_assert_cmpuint(d.count, ==, 4);
+
+ g_main_loop_unref(d.mainloop);
+
+ g_source_remove(timer_id);
+ g_io_channel_unref(io);
+ g_source_remove(io_id);
+ g_obex_unref(obex);
+
+ g_assert_no_error(d.err);
+}
+
static void test_packet_get_req_wait_next(void)
{
GIOChannel *io;
@@ -1549,7 +1620,7 @@ static gboolean rcv_data_delay(const void *buf, gsize len, gpointer user_data)
if (d->provide_delay > 0) {
g_obex_suspend(d->obex);
- g_timeout_add(d->provide_delay, resume_obex, d->obex);
+ g_timeout_add(d->provide_delay, resume_obex, d);
}
return TRUE;
@@ -2253,6 +2324,8 @@ int main(int argc, char *argv[])
g_test_add_func("/gobex/test_packet_get_req", test_packet_get_req);
g_test_add_func("/gobex/test_packet_get_req_wait",
test_packet_get_req_wait);
+ g_test_add_func("/gobex/test_packet_get_req_suspend_resume",
+ test_packet_get_req_suspend_resume);
g_test_add_func("/gobex/test_packet_get_req_wait_next",
test_packet_get_req_wait_next);
--
1.8.5.3
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox