* Re: [PATCH] linux-firmware: Remove ath3k-2.fw
From: Bala Shanmugam @ 2011-03-01 6:38 UTC (permalink / raw)
To: David Woodhouse
Cc: linux-bluetooth@vger.kernel.org, Jothikumar Mothilal,
Vikram Kandukuri
In-Reply-To: <4D4A60E1.3080000@atheros.com>
On 2/3/2011 1:31 PM, Bala Shanmugam wrote:
> On 2/3/2011 1:13 PM, David Woodhouse wrote:
>> On Fri, 2011-01-28 at 15:03 +0530, Bala Shanmugam wrote:
>>> ath3k-2.fw is obsolete and not use by Atheros chipsets
>>> anymore.
>> Are you telling me that there is no extant hardware, and no old kernels,
>> which would use this? It was added to the linux-firmware tree and
>> *never* used?
>>
> Yes David, no older kernel uses this firmware.
> We thought to have new firmware file for newer versions but
> our driver patch was not accepted and we decided to
> have single firmware for this chipset [ath3k-1.fw].
>
> Thanks and Regards,
> Bala.
>
>
Hi David,
Can you please remove this firmware.
If you have any concerns please let me know.
Regards,
Bala.
^ permalink raw reply
* Re: re "bluetooth disabled" and "[BUG] usb problems in .38-rc3+"
From: Justin Mattock @ 2011-03-01 5:51 UTC (permalink / raw)
To: Mikko Vinni
Cc: linux-bluetooth, Ed Tomlinson, Gustavo F. Padovan, Johan Hedberg
In-Reply-To: <635561.59590.qm@web161820.mail.bf1.yahoo.com>
On Feb 28, 2011, at 2:29 PM, Mikko Vinni wrote:
> Hi all,
>
> Just wondering what is the status of "bluetooth disabled with current
> 2.6.38-rc4"
> from Justin (http://www.spinics.net/lists/linux-bluetooth/msg10745.html
> ) and
> "[BUG] usb problems in .38-rc3+"" (http://marc.info/?t=129693396800003&r=1&w=2
> )
> from Ed? (apologies for not being able to reply to those threads)
>
good im not going crazy!!!(thought I was the only one)
> The first one because I think I see the same problem and the second
> one because
> for me also "hciconfig -a" makes the bluetooth adapter work. Maybe
> they have
> a common cause.
>
> For me, reverting 23bb57633df ("Bluetooth: Fix __hci_request
> synchronization
> for hci_open_dev"; suggested by Justin) on top of
> 2.6.38-rc6-166-g493f335 makes everything work as before.
>
thankfully the revert is not that big.. if/when I get time(in the
process of relocating)
I would not mind going through that commit and plucking things to find
exactly what's causing
the problem then go from there(if somebody gets to that before, Ill
gladly supply info and/or test anything
for them!!)
> bluez version and bluetooth adapter model:
>
> [root@koni ~]# pacman -Qo /usr/sbin/bluetoothd
> /usr/sbin/bluetoothd is owned by bluez 4.89-1
> [root@koni ~]# lsusb | grep i.Tech
> Bus 003 Device 002: ID 13dd:0001 i.Tech Dynamic Limited
>
> Part of bluetoothd -d dump below. The printout only really got
> started when
> I run "hciconfig -a" after 22:01:42 (hciconfig hci0 down and
> hciconfig hci0 up
> can also be used to make it work):
>
> [root@koni ~]# hciconfig
> hci0: Type: BR/EDR Bus: USB
> BD Address: 00:0D:3C:38:xx:yy ACL MTU: 384:8 SCO MTU: 64:8
> UP RUNNING
> RX bytes:356 acl:0 sco:0 events:13 errors:0
> TX bytes:53 acl:0 sco:0 commands:13 errors:0
>
> [root@koni ~]# date
> Mon Feb 28 22:01:42 EET 2011
> [root@koni ~]# hciconfig -a
> hci0: Type: BR/EDR Bus: USB
> BD Address: 00:0D:3C:38:xx:yy ACL MTU: 384:8 SCO MTU: 64:8
> UP RUNNING
> RX bytes:356 acl:0 sco:0 events:13 errors:0
> TX bytes:53 acl:0 sco:0 commands:13 errors:0
> Features: 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
> Packet type: DM1 DH1 HV1
> Link policy:
> Link mode: SLAVE ACCEPT
> Name: 'CSR - bc4'
> Class: 0x000000
> Service Classes: Unspecified
> Device Class: Miscellaneous,
> HCI Version: 2.0 (0x3) Revision: 0x7a6
> LMP Version: 2.0 (0x3) Subversion: 0x7a6
> Manufacturer: Cambridge Silicon Radio (10)
>
>
> Feb 28 21:55:39 koni bluetoothd[3256]: src/rfkill.c:rfkill_event()
> RFKILL event
> idx 0 type 1 op 0 soft 1 hard 0
> Feb 28 21:55:39 koni bluetoothd[3256]: plugins/
> hciops.c:init_known_adapters()
> Feb 28 21:56:14 koni blueman-mechanism: Starting blueman-mechanism
> Feb 28 21:56:14 koni kernel: fuse init (API version 7.16)
> Feb 28 21:56:14 koni blueman-mechanism: reload 0 0
> Feb 28 21:56:15 koni kernel: Bluetooth: RFCOMM TTY layer initialized
> Feb 28 21:56:15 koni kernel: Bluetooth: RFCOMM socket layer
> initialized
> Feb 28 21:56:15 koni kernel: Bluetooth: RFCOMM ver 1.11
> Feb 28 21:56:28 koni kernel: usb 6-1: new full speed USB device
> using ohci_hcd
> and address 2
> Feb 28 21:56:29 koni kernel: usb 6-1: New USB device found,
> idVendor=13dd,
> idProduct=0001
> Feb 28 21:56:29 koni kernel: usb 6-1: New USB device strings: Mfr=1,
> Product=2,
> SerialNumber=0
> Feb 28 21:56:29 koni kernel: usb 6-1: Product: BlueCON U2
> Feb 28 21:56:29 koni kernel: usb 6-1: Manufacturer: i.Tech Dynamic
> Feb 28 21:56:29 koni kernel: Bluetooth: Generic Bluetooth USB driver
> ver 0.6
> Feb 28 21:56:29 koni bluetoothd[3256]: src/rfkill.c:rfkill_event()
> RFKILL event
> idx 1 type 2 op 0 soft 0 hard 0
> Feb 28 21:56:29 koni bluetoothd[3256]: HCI dev 0 registered
> Feb 28 21:56:29 koni bluetoothd[3256]: plugins/
> hciops.c:init_device() hci0
> Feb 28 21:56:29 koni bluetoothd[3256]: Listening for HCI events on
> hci0
> Feb 28 21:56:29 koni bluetoothd[3256]: plugins/
> hciops.c:init_device() child 3317
> forked
> Feb 28 21:56:29 koni bluetoothd[3256]: src/rfkill.c:rfkill_event()
> RFKILL event
> idx 1 type 2 op 2 soft 0 hard 0
> Feb 28 21:56:29 koni kernel: usbcore: registered new interface
> driver btusb
> Feb 28 21:56:29 koni bluetoothd[3256]:
> plugins/hciops.c:read_local_version_complete() Got version for hci0
> Feb 28 21:56:29 koni bluetoothd[3256]: plugins/
> hciops.c:read_bd_addr_complete()
> hci0 status 0
> Feb 28 21:56:29 koni bluetoothd[3256]: plugins/
> hciops.c:read_bd_addr_complete()
> Got bdaddr for hci0
> Feb 28 21:56:29 koni bluetoothd[3256]:
> plugins/hciops.c:read_local_name_complete() hci0 status 0
> Feb 28 21:56:29 koni bluetoothd[3256]:
> plugins/hciops.c:read_local_name_complete() Got name for hci0
> Feb 28 21:56:29 koni bluetoothd[3256]: plugins/hciops.c:child_exit()
> child 3317
> exited
> Feb 28 21:56:29 koni bluetoothd[3256]: HCI dev 0 up
> Feb 28 21:56:29 koni bluetoothd[3256]: plugins/
> hciops.c:device_devup_setup()
> hci0
> Feb 28 21:56:44 koni blueman-mechanism: Exiting
> Feb 28 22:01:45 koni bluetoothd[3256]:
> plugins/hciops.c:read_local_name_complete() hci0 status 0
> Feb 28 22:01:45 koni bluetoothd[3256]:
> plugins/hciops.c:read_local_name_complete() Got name for hci0
> Feb 28 22:01:45 koni bluetoothd[3256]:
> plugins/hciops.c:read_local_features_complete() Got features for hci0
> Feb 28 22:01:45 koni bluetoothd[3256]: src/adapter.c:btd_adapter_ref()
> 0x7f2d7b862e10: ref=1
> Feb 28 22:01:45 koni bluetoothd[3256]: plugins/
> hciops.c:hciops_read_bdaddr()
> hci0
> Feb 28 22:01:45 koni bluetoothd[3256]:
> plugins/hciops.c:hciops_read_local_version() hci0
> Feb 28 22:01:45 koni bluetoothd[3256]:
> plugins/hciops.c:hciops_read_local_features() hci0
> Feb 28 22:01:45 koni bluetoothd[3256]:
> src/sdpd-database.c:sdp_init_services_list()
>
> Feb 28 22:01:45 koni bluetoothd[3256]: plugins/
> hciops.c:hciops_add_uuid() hci0
> Feb 28 22:01:45 koni bluetoothd[3256]: plugins/
> hciops.c:update_service_classes()
> hci0 value 0
> Feb 28 22:01:45 koni bluetoothd[3256]: plugins/
> hciops.c:hciops_add_uuid() hci0
> Feb 28 22:01:45 koni bluetoothd[3256]: plugins/
> hciops.c:update_service_classes()
> hci0 value 0
> Feb 28 22:01:45 koni bluetoothd[3256]: plugins/
> hciops.c:hciops_add_uuid() hci0
> Feb 28 22:01:45 koni bluetoothd[3256]: plugins/
> hciops.c:update_service_classes()
> hci0 value 16
> Feb 28 22:01:45 koni bluetoothd[3256]: plugins/
> hciops.c:hciops_add_uuid() hci0
> Feb 28 22:01:45 koni bluetoothd[3256]: plugins/
> hciops.c:update_service_classes()
> hci0 value 16
> Feb 28 22:01:45 koni bluetoothd[3256]: plugins/
> service.c:register_interface()
> path /org/bluez/3256/hci0
> Feb 28 22:01:45 koni bluetoothd[3256]: plugins/
> service.c:register_interface()
> Registered interface org.bluez.Service on path /org/bluez/3256/hci0
> Feb 28 22:01:45 koni bluetoothd[3256]: network/
> manager.c:network_server_probe()
> path /org/bluez/3256/hci0
> Feb 28 22:01:45 koni bluetoothd[3256]: src/adapter.c:btd_adapter_ref()
> 0x7f2d7b862e10: ref=2
> Feb 28 22:01:45 koni bluetoothd[3256]: network/
> server.c:server_register()
> Registered interface org.bluez.NetworkServer on path /org/bluez/3256/
> hci0
> Feb 28 22:01:45 koni bluetoothd[3256]: serial/
> manager.c:proxy_probe() path
> /org/bluez/3256/hci0
> Feb 28 22:01:45 koni bluetoothd[3256]: src/adapter.c:btd_adapter_ref()
> 0x7f2d7b862e10: ref=3
> Feb 28 22:01:45 koni bluetoothd[3256]: serial/proxy.c:proxy_register()
> Registered interface org.bluez.SerialProxyManager on path /org/bluez/
> 3256/hci0
> Feb 28 22:01:45 koni bluetoothd[3256]: src/adapter.c:btd_adapter_ref()
> 0x7f2d7b862e10: ref=4
> ...
>
> Mikko
>
>
>
^ permalink raw reply
* Re: [PATCH 00/11] mfd and bluetooth: Add CG2900 suppor
From: Linus Walleij @ 2011-02-28 22:43 UTC (permalink / raw)
To: Vitaly Wool, Par-Gunnar Hjalmdahl
Cc: Par-Gunnar HJALMDAHL, Samuel Ortiz, Marcel Holtmann, Lee Jones,
Alan Cox, Arnd Bergmann, linux-bluetooth@vger.kernel.org,
linux-kernel@vger.kernel.org, Lukasz Rymanowski, Pavan Savoy
In-Reply-To: <AANLkTik3hiNj7=K+uE6eQW2CokZtCz7Zwvt-+6PkD_Mo@mail.gmail.com>
On Fri, Feb 25, 2011 at 6:55 PM, Vitaly Wool <vitalywool@gmail.com> wrote:
> Making hardware work is, if course, a valid point, but porting a windows
> driver would do that as well, and it's not the reason to pull windows
> drivers' ports into mainline.
Yeah hm, that sounds like it has "drivers/staging" printed all over it then,
so either we solve these issues or we need to put it into staging so we
can get help from others in fixing it up (we have a similar situation with
the U8500 graphics stuff).
P-G do you think it would be proper to take this into staging for the
moment, or do you prefer to drive it outside the mainline kernel tree until
it lands in the proper place(s)?
Yours,
Linus Walleij
^ permalink raw reply
* re "bluetooth disabled" and "[BUG] usb problems in .38-rc3+"
From: Mikko Vinni @ 2011-02-28 22:29 UTC (permalink / raw)
To: linux-bluetooth
Cc: Justin P. Mattock, Ed Tomlinson, Gustavo F. Padovan,
Johan Hedberg
Hi all,
Just wondering what is the status of "bluetooth disabled with current
2.6.38-rc4"
from Justin (http://www.spinics.net/lists/linux-bluetooth/msg10745.html) and
"[BUG] usb problems in .38-rc3+"" (http://marc.info/?t=129693396800003&r=1&w=2)
from Ed? (apologies for not being able to reply to those threads)
The first one because I think I see the same problem and the second one because
for me also "hciconfig -a" makes the bluetooth adapter work. Maybe they have
a common cause.
For me, reverting 23bb57633df ("Bluetooth: Fix __hci_request synchronization
for hci_open_dev"; suggested by Justin) on top of
2.6.38-rc6-166-g493f335 makes everything work as before.
bluez version and bluetooth adapter model:
[root@koni ~]# pacman -Qo /usr/sbin/bluetoothd
/usr/sbin/bluetoothd is owned by bluez 4.89-1
[root@koni ~]# lsusb | grep i.Tech
Bus 003 Device 002: ID 13dd:0001 i.Tech Dynamic Limited
Part of bluetoothd -d dump below. The printout only really got started when
I run "hciconfig -a" after 22:01:42 (hciconfig hci0 down and hciconfig hci0 up
can also be used to make it work):
[root@koni ~]# hciconfig
hci0: Type: BR/EDR Bus: USB
BD Address: 00:0D:3C:38:xx:yy ACL MTU: 384:8 SCO MTU: 64:8
UP RUNNING
RX bytes:356 acl:0 sco:0 events:13 errors:0
TX bytes:53 acl:0 sco:0 commands:13 errors:0
[root@koni ~]# date
Mon Feb 28 22:01:42 EET 2011
[root@koni ~]# hciconfig -a
hci0: Type: BR/EDR Bus: USB
BD Address: 00:0D:3C:38:xx:yy ACL MTU: 384:8 SCO MTU: 64:8
UP RUNNING
RX bytes:356 acl:0 sco:0 events:13 errors:0
TX bytes:53 acl:0 sco:0 commands:13 errors:0
Features: 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
Packet type: DM1 DH1 HV1
Link policy:
Link mode: SLAVE ACCEPT
Name: 'CSR - bc4'
Class: 0x000000
Service Classes: Unspecified
Device Class: Miscellaneous,
HCI Version: 2.0 (0x3) Revision: 0x7a6
LMP Version: 2.0 (0x3) Subversion: 0x7a6
Manufacturer: Cambridge Silicon Radio (10)
Feb 28 21:55:39 koni bluetoothd[3256]: src/rfkill.c:rfkill_event() RFKILL event
idx 0 type 1 op 0 soft 1 hard 0
Feb 28 21:55:39 koni bluetoothd[3256]: plugins/hciops.c:init_known_adapters()
Feb 28 21:56:14 koni blueman-mechanism: Starting blueman-mechanism
Feb 28 21:56:14 koni kernel: fuse init (API version 7.16)
Feb 28 21:56:14 koni blueman-mechanism: reload 0 0
Feb 28 21:56:15 koni kernel: Bluetooth: RFCOMM TTY layer initialized
Feb 28 21:56:15 koni kernel: Bluetooth: RFCOMM socket layer initialized
Feb 28 21:56:15 koni kernel: Bluetooth: RFCOMM ver 1.11
Feb 28 21:56:28 koni kernel: usb 6-1: new full speed USB device using ohci_hcd
and address 2
Feb 28 21:56:29 koni kernel: usb 6-1: New USB device found, idVendor=13dd,
idProduct=0001
Feb 28 21:56:29 koni kernel: usb 6-1: New USB device strings: Mfr=1, Product=2,
SerialNumber=0
Feb 28 21:56:29 koni kernel: usb 6-1: Product: BlueCON U2
Feb 28 21:56:29 koni kernel: usb 6-1: Manufacturer: i.Tech Dynamic
Feb 28 21:56:29 koni kernel: Bluetooth: Generic Bluetooth USB driver ver 0.6
Feb 28 21:56:29 koni bluetoothd[3256]: src/rfkill.c:rfkill_event() RFKILL event
idx 1 type 2 op 0 soft 0 hard 0
Feb 28 21:56:29 koni bluetoothd[3256]: HCI dev 0 registered
Feb 28 21:56:29 koni bluetoothd[3256]: plugins/hciops.c:init_device() hci0
Feb 28 21:56:29 koni bluetoothd[3256]: Listening for HCI events on hci0
Feb 28 21:56:29 koni bluetoothd[3256]: plugins/hciops.c:init_device() child 3317
forked
Feb 28 21:56:29 koni bluetoothd[3256]: src/rfkill.c:rfkill_event() RFKILL event
idx 1 type 2 op 2 soft 0 hard 0
Feb 28 21:56:29 koni kernel: usbcore: registered new interface driver btusb
Feb 28 21:56:29 koni bluetoothd[3256]:
plugins/hciops.c:read_local_version_complete() Got version for hci0
Feb 28 21:56:29 koni bluetoothd[3256]: plugins/hciops.c:read_bd_addr_complete()
hci0 status 0
Feb 28 21:56:29 koni bluetoothd[3256]: plugins/hciops.c:read_bd_addr_complete()
Got bdaddr for hci0
Feb 28 21:56:29 koni bluetoothd[3256]:
plugins/hciops.c:read_local_name_complete() hci0 status 0
Feb 28 21:56:29 koni bluetoothd[3256]:
plugins/hciops.c:read_local_name_complete() Got name for hci0
Feb 28 21:56:29 koni bluetoothd[3256]: plugins/hciops.c:child_exit() child 3317
exited
Feb 28 21:56:29 koni bluetoothd[3256]: HCI dev 0 up
Feb 28 21:56:29 koni bluetoothd[3256]: plugins/hciops.c:device_devup_setup()
hci0
Feb 28 21:56:44 koni blueman-mechanism: Exiting
Feb 28 22:01:45 koni bluetoothd[3256]:
plugins/hciops.c:read_local_name_complete() hci0 status 0
Feb 28 22:01:45 koni bluetoothd[3256]:
plugins/hciops.c:read_local_name_complete() Got name for hci0
Feb 28 22:01:45 koni bluetoothd[3256]:
plugins/hciops.c:read_local_features_complete() Got features for hci0
Feb 28 22:01:45 koni bluetoothd[3256]: src/adapter.c:btd_adapter_ref()
0x7f2d7b862e10: ref=1
Feb 28 22:01:45 koni bluetoothd[3256]: plugins/hciops.c:hciops_read_bdaddr()
hci0
Feb 28 22:01:45 koni bluetoothd[3256]:
plugins/hciops.c:hciops_read_local_version() hci0
Feb 28 22:01:45 koni bluetoothd[3256]:
plugins/hciops.c:hciops_read_local_features() hci0
Feb 28 22:01:45 koni bluetoothd[3256]:
src/sdpd-database.c:sdp_init_services_list()
Feb 28 22:01:45 koni bluetoothd[3256]: plugins/hciops.c:hciops_add_uuid() hci0
Feb 28 22:01:45 koni bluetoothd[3256]: plugins/hciops.c:update_service_classes()
hci0 value 0
Feb 28 22:01:45 koni bluetoothd[3256]: plugins/hciops.c:hciops_add_uuid() hci0
Feb 28 22:01:45 koni bluetoothd[3256]: plugins/hciops.c:update_service_classes()
hci0 value 0
Feb 28 22:01:45 koni bluetoothd[3256]: plugins/hciops.c:hciops_add_uuid() hci0
Feb 28 22:01:45 koni bluetoothd[3256]: plugins/hciops.c:update_service_classes()
hci0 value 16
Feb 28 22:01:45 koni bluetoothd[3256]: plugins/hciops.c:hciops_add_uuid() hci0
Feb 28 22:01:45 koni bluetoothd[3256]: plugins/hciops.c:update_service_classes()
hci0 value 16
Feb 28 22:01:45 koni bluetoothd[3256]: plugins/service.c:register_interface()
path /org/bluez/3256/hci0
Feb 28 22:01:45 koni bluetoothd[3256]: plugins/service.c:register_interface()
Registered interface org.bluez.Service on path /org/bluez/3256/hci0
Feb 28 22:01:45 koni bluetoothd[3256]: network/manager.c:network_server_probe()
path /org/bluez/3256/hci0
Feb 28 22:01:45 koni bluetoothd[3256]: src/adapter.c:btd_adapter_ref()
0x7f2d7b862e10: ref=2
Feb 28 22:01:45 koni bluetoothd[3256]: network/server.c:server_register()
Registered interface org.bluez.NetworkServer on path /org/bluez/3256/hci0
Feb 28 22:01:45 koni bluetoothd[3256]: serial/manager.c:proxy_probe() path
/org/bluez/3256/hci0
Feb 28 22:01:45 koni bluetoothd[3256]: src/adapter.c:btd_adapter_ref()
0x7f2d7b862e10: ref=3
Feb 28 22:01:45 koni bluetoothd[3256]: serial/proxy.c:proxy_register()
Registered interface org.bluez.SerialProxyManager on path /org/bluez/3256/hci0
Feb 28 22:01:45 koni bluetoothd[3256]: src/adapter.c:btd_adapter_ref()
0x7f2d7b862e10: ref=4
...
Mikko
^ permalink raw reply
* [PATCH 5/5] hcitool: Add command to clear LE White List
From: Claudio Takahasi @ 2011-02-28 18:18 UTC (permalink / raw)
To: linux-bluetooth; +Cc: Arun Kumar Singh
In-Reply-To: <1298917134-8229-1-git-send-email-claudio.takahasi@openbossa.org>
From: Arun Kumar Singh <arunkat@gmail.com>
---
lib/hci.c | 22 ++++++++++++++++++++++
lib/hci_lib.h | 1 +
tools/hcitool.c | 44 ++++++++++++++++++++++++++++++++++++++++++++
3 files changed, 67 insertions(+), 0 deletions(-)
diff --git a/lib/hci.c b/lib/hci.c
index 9184e09..02fc0cf 100644
--- a/lib/hci.c
+++ b/lib/hci.c
@@ -1376,6 +1376,28 @@ int hci_le_read_white_list_size(int dd, uint8_t *size, int to)
return 0;
}
+int hci_le_clear_white_list(int dd, int to)
+{
+ struct hci_request rq;
+ uint8_t status;
+
+ memset(&rq, 0, sizeof(rq));
+ rq.ogf = OGF_LE_CTL;
+ rq.ocf = OCF_LE_CLEAR_WHITE_LIST;
+ rq.rparam = &status;
+ rq.rlen = 1;
+
+ if (hci_send_req(dd, &rq, to) < 0)
+ return -1;
+
+ if (status) {
+ errno = EIO;
+ return -1;
+ }
+
+ return 0;
+}
+
int hci_read_local_name(int dd, int len, char *name, int to)
{
read_local_name_rp rp;
diff --git a/lib/hci_lib.h b/lib/hci_lib.h
index ce1bb6c..de3e636 100644
--- a/lib/hci_lib.h
+++ b/lib/hci_lib.h
@@ -134,6 +134,7 @@ int hci_le_conn_update(int dd, uint16_t handle, uint16_t min_interval,
int hci_le_add_white_list(int dd, const bdaddr_t *bdaddr, uint8_t type, int to);
int hci_le_rm_white_list(int dd, const bdaddr_t *bdaddr, uint8_t type, int to);
int hci_le_read_white_list_size(int dd, uint8_t *size, int to);
+int hci_le_clear_white_list(int dd, int to);
int hci_for_each_dev(int flag, int(*func)(int dd, int dev_id, long arg), long arg);
int hci_get_route(bdaddr_t *bdaddr);
diff --git a/tools/hcitool.c b/tools/hcitool.c
index 427edc2..e79d76b 100644
--- a/tools/hcitool.c
+++ b/tools/hcitool.c
@@ -2702,6 +2702,49 @@ static void cmd_lewlsz(int dev_id, int argc, char **argv)
printf("White list size: %d\n", size);
}
+static struct option lewlclr_options[] = {
+ { "help", 0, 0, 'h' },
+ { 0, 0, 0, 0 }
+};
+
+static const char *lewlclr_help =
+ "Usage:\n"
+ "\tlewlclr\n";
+
+static void cmd_lewlclr(int dev_id, int argc, char **argv)
+{
+ int err, dd, opt;
+
+ for_each_opt(opt, lewlclr_options, NULL) {
+ switch (opt) {
+ default:
+ printf("%s", lewlclr_help);
+ return;
+ }
+ }
+
+ helper_arg(0, 0, &argc, &argv, lewlclr_help);
+
+ if (dev_id < 0)
+ dev_id = hci_get_route(NULL);
+
+ dd = hci_open_dev(dev_id);
+ if (dd < 0) {
+ perror("Could not open device");
+ exit(1);
+ }
+
+ err = hci_le_clear_white_list(dd, 1000);
+ hci_close_dev(dd);
+
+ if (err < 0) {
+ err = errno;
+ fprintf(stderr, "Can't clear white list: %s(%d)\n",
+ strerror(err), err);
+ exit(1);
+ }
+}
+
static struct option ledc_options[] = {
{ "help", 0, 0, 'h' },
{ 0, 0, 0, 0 }
@@ -2866,6 +2909,7 @@ static struct {
{ "lewladd", cmd_lewladd, "Add device to LE White List" },
{ "lewlrm", cmd_lewlrm, "Remove device from LE White List" },
{ "lewlsz", cmd_lewlsz, "Read size of LE White List" },
+ { "lewlclr", cmd_lewlclr, "Clear LE White list" },
{ "lecc", cmd_lecc, "Create a LE Connection" },
{ "ledc", cmd_ledc, "Disconnect a LE Connection" },
{ "lecup", cmd_lecup, "LE Connection Update" },
--
1.7.4.1
^ permalink raw reply related
* [PATCH 4/5] hcitool: Add command to read size of LE White List
From: Claudio Takahasi @ 2011-02-28 18:18 UTC (permalink / raw)
To: linux-bluetooth; +Cc: Arun Kumar Singh
In-Reply-To: <1298917134-8229-1-git-send-email-claudio.takahasi@openbossa.org>
From: Arun Kumar Singh <arunkat@gmail.com>
---
lib/hci.c | 27 +++++++++++++++++++++++++++
lib/hci_lib.h | 1 +
tools/hcitool.c | 47 +++++++++++++++++++++++++++++++++++++++++++++++
3 files changed, 75 insertions(+), 0 deletions(-)
diff --git a/lib/hci.c b/lib/hci.c
index 0e1518c..9184e09 100644
--- a/lib/hci.c
+++ b/lib/hci.c
@@ -1349,6 +1349,33 @@ int hci_le_rm_white_list(int dd, const bdaddr_t *bdaddr, uint8_t type, int to)
return 0;
}
+int hci_le_read_white_list_size(int dd, uint8_t *size, int to)
+{
+ struct hci_request rq;
+ le_read_white_list_size_rp rp;
+
+ memset(&rp, 0, sizeof(rp));
+ memset(&rq, 0, sizeof(rq));
+
+ rq.ogf = OGF_LE_CTL;
+ rq.ocf = OCF_LE_READ_WHITE_LIST_SIZE;
+ rq.rparam = &rp;
+ rq.rlen = LE_READ_WHITE_LIST_SIZE_RP_SIZE;
+
+ if (hci_send_req(dd, &rq, to) < 0)
+ return -1;
+
+ if (rp.status) {
+ errno = EIO;
+ return -1;
+ }
+
+ if (size)
+ *size = rp.size;
+
+ return 0;
+}
+
int hci_read_local_name(int dd, int len, char *name, int to)
{
read_local_name_rp rp;
diff --git a/lib/hci_lib.h b/lib/hci_lib.h
index e894e8e..ce1bb6c 100644
--- a/lib/hci_lib.h
+++ b/lib/hci_lib.h
@@ -133,6 +133,7 @@ int hci_le_conn_update(int dd, uint16_t handle, uint16_t min_interval,
uint16_t supervision_timeout, int to);
int hci_le_add_white_list(int dd, const bdaddr_t *bdaddr, uint8_t type, int to);
int hci_le_rm_white_list(int dd, const bdaddr_t *bdaddr, uint8_t type, int to);
+int hci_le_read_white_list_size(int dd, uint8_t *size, int to);
int hci_for_each_dev(int flag, int(*func)(int dd, int dev_id, long arg), long arg);
int hci_get_route(bdaddr_t *bdaddr);
diff --git a/tools/hcitool.c b/tools/hcitool.c
index bf0f25d..427edc2 100644
--- a/tools/hcitool.c
+++ b/tools/hcitool.c
@@ -2656,6 +2656,52 @@ static void cmd_lewlrm(int dev_id, int argc, char **argv)
}
}
+static struct option lewlsz_options[] = {
+ { "help", 0, 0, 'h' },
+ { 0, 0, 0, 0 }
+};
+
+static const char *lewlsz_help =
+ "Usage:\n"
+ "\tlewlsz\n";
+
+static void cmd_lewlsz(int dev_id, int argc, char **argv)
+{
+ int err, dd, opt;
+ uint8_t size;
+
+ for_each_opt(opt, lewlsz_options, NULL) {
+ switch (opt) {
+ default:
+ printf("%s", lewlsz_help);
+ return;
+ }
+ }
+
+ helper_arg(0, 0, &argc, &argv, lewlsz_help);
+
+ if (dev_id < 0)
+ dev_id = hci_get_route(NULL);
+
+ dd = hci_open_dev(dev_id);
+ if (dd < 0) {
+ perror("Could not open device");
+ exit(1);
+ }
+
+ err = hci_le_read_white_list_size(dd, &size, 1000);
+ hci_close_dev(dd);
+
+ if (err < 0) {
+ err = errno;
+ fprintf(stderr, "Can't read white list size: %s(%d)\n",
+ strerror(err), err);
+ exit(1);
+ }
+
+ printf("White list size: %d\n", size);
+}
+
static struct option ledc_options[] = {
{ "help", 0, 0, 'h' },
{ 0, 0, 0, 0 }
@@ -2819,6 +2865,7 @@ static struct {
{ "lescan", cmd_lescan, "Start LE scan" },
{ "lewladd", cmd_lewladd, "Add device to LE White List" },
{ "lewlrm", cmd_lewlrm, "Remove device from LE White List" },
+ { "lewlsz", cmd_lewlsz, "Read size of LE White List" },
{ "lecc", cmd_lecc, "Create a LE Connection" },
{ "ledc", cmd_ledc, "Disconnect a LE Connection" },
{ "lecup", cmd_lecup, "LE Connection Update" },
--
1.7.4.1
^ permalink raw reply related
* [PATCH 3/5] hcitool: Add command to remove a device from LE white list
From: Claudio Takahasi @ 2011-02-28 18:18 UTC (permalink / raw)
To: linux-bluetooth; +Cc: Arun Kumar Singh
In-Reply-To: <1298917134-8229-1-git-send-email-claudio.takahasi@openbossa.org>
From: Arun Kumar Singh <arunkat@gmail.com>
---
lib/hci.c | 29 +++++++++++++++++++++++++++++
lib/hci_lib.h | 1 +
tools/hcitool.c | 47 +++++++++++++++++++++++++++++++++++++++++++++++
3 files changed, 77 insertions(+), 0 deletions(-)
diff --git a/lib/hci.c b/lib/hci.c
index fc710f4..0e1518c 100644
--- a/lib/hci.c
+++ b/lib/hci.c
@@ -1320,6 +1320,35 @@ int hci_le_add_white_list(int dd, const bdaddr_t *bdaddr, uint8_t type, int to)
return 0;
}
+int hci_le_rm_white_list(int dd, const bdaddr_t *bdaddr, uint8_t type, int to)
+{
+ struct hci_request rq;
+ le_remove_device_from_white_list_cp cp;
+ uint8_t status;
+
+ memset(&cp, 0, sizeof(cp));
+ cp.bdaddr_type = type;
+ bacpy(&cp.bdaddr, bdaddr);
+
+ memset(&rq, 0, sizeof(rq));
+ rq.ogf = OGF_LE_CTL;
+ rq.ocf = OCF_LE_REMOVE_DEVICE_FROM_WHITE_LIST;
+ rq.cparam = &cp;
+ rq.clen = LE_REMOVE_DEVICE_FROM_WHITE_LIST_CP_SIZE;
+ rq.rparam = &status;
+ rq.rlen = 1;
+
+ if (hci_send_req(dd, &rq, to) < 0)
+ return -1;
+
+ if (status) {
+ errno = EIO;
+ return -1;
+ }
+
+ return 0;
+}
+
int hci_read_local_name(int dd, int len, char *name, int to)
{
read_local_name_rp rp;
diff --git a/lib/hci_lib.h b/lib/hci_lib.h
index fb2c7cb..e894e8e 100644
--- a/lib/hci_lib.h
+++ b/lib/hci_lib.h
@@ -132,6 +132,7 @@ int hci_le_conn_update(int dd, uint16_t handle, uint16_t min_interval,
uint16_t max_interval, uint16_t latency,
uint16_t supervision_timeout, int to);
int hci_le_add_white_list(int dd, const bdaddr_t *bdaddr, uint8_t type, int to);
+int hci_le_rm_white_list(int dd, const bdaddr_t *bdaddr, uint8_t type, int to);
int hci_for_each_dev(int flag, int(*func)(int dd, int dev_id, long arg), long arg);
int hci_get_route(bdaddr_t *bdaddr);
diff --git a/tools/hcitool.c b/tools/hcitool.c
index 8945156..bf0f25d 100644
--- a/tools/hcitool.c
+++ b/tools/hcitool.c
@@ -2610,6 +2610,52 @@ static void cmd_lewladd(int dev_id, int argc, char **argv)
}
}
+static struct option lewlrm_options[] = {
+ { "help", 0, 0, 'h' },
+ { 0, 0, 0, 0 }
+};
+
+static const char *lewlrm_help =
+ "Usage:\n"
+ "\tlewlrm <bdaddr>\n";
+
+static void cmd_lewlrm(int dev_id, int argc, char **argv)
+{
+ int err, opt, dd;
+ bdaddr_t bdaddr;
+
+ for_each_opt(opt, lewlrm_options, NULL) {
+ switch (opt) {
+ default:
+ printf("%s", lewlrm_help);
+ return;
+ }
+ }
+
+ helper_arg(1, 1, &argc, &argv, lewlrm_help);
+
+ if (dev_id < 0)
+ dev_id = hci_get_route(NULL);
+
+ dd = hci_open_dev(dev_id);
+ if (dd < 0) {
+ perror("Could not open device");
+ exit(1);
+ }
+
+ str2ba(argv[0], &bdaddr);
+
+ err = hci_le_rm_white_list(dd, &bdaddr, LE_PUBLIC_ADDRESS, 1000);
+ hci_close_dev(dd);
+
+ if (err < 0) {
+ err = errno;
+ fprintf(stderr, "Can't remove from white list: %s(%d)\n",
+ strerror(err), err);
+ exit(1);
+ }
+}
+
static struct option ledc_options[] = {
{ "help", 0, 0, 'h' },
{ 0, 0, 0, 0 }
@@ -2772,6 +2818,7 @@ static struct {
{ "clock", cmd_clock, "Read local or remote clock" },
{ "lescan", cmd_lescan, "Start LE scan" },
{ "lewladd", cmd_lewladd, "Add device to LE White List" },
+ { "lewlrm", cmd_lewlrm, "Remove device from LE White List" },
{ "lecc", cmd_lecc, "Create a LE Connection" },
{ "ledc", cmd_ledc, "Disconnect a LE Connection" },
{ "lecup", cmd_lecup, "LE Connection Update" },
--
1.7.4.1
^ permalink raw reply related
* [PATCH 2/5] hcitool: Change commands struct formating
From: Claudio Takahasi @ 2011-02-28 18:18 UTC (permalink / raw)
To: linux-bluetooth; +Cc: Claudio Takahasi
In-Reply-To: <1298917134-8229-1-git-send-email-claudio.takahasi@openbossa.org>
---
tools/hcitool.c | 58 +++++++++++++++++++++++++++---------------------------
1 files changed, 29 insertions(+), 29 deletions(-)
diff --git a/tools/hcitool.c b/tools/hcitool.c
index 1184b6b..8945156 100644
--- a/tools/hcitool.c
+++ b/tools/hcitool.c
@@ -2746,35 +2746,35 @@ static struct {
void (*func)(int dev_id, int argc, char **argv);
char *doc;
} command[] = {
- { "dev", cmd_dev, "Display local devices" },
- { "inq", cmd_inq, "Inquire remote devices" },
- { "scan", cmd_scan, "Scan for remote devices" },
- { "name", cmd_name, "Get name from remote device" },
- { "info", cmd_info, "Get information from remote device" },
- { "spinq", cmd_spinq, "Start periodic inquiry" },
- { "epinq", cmd_epinq, "Exit periodic inquiry" },
- { "cmd", cmd_cmd, "Submit arbitrary HCI commands" },
- { "con", cmd_con, "Display active connections" },
- { "cc", cmd_cc, "Create connection to remote device" },
- { "dc", cmd_dc, "Disconnect from remote device" },
- { "sr", cmd_sr, "Switch master/slave role" },
- { "cpt", cmd_cpt, "Change connection packet type" },
- { "rssi", cmd_rssi, "Display connection RSSI" },
- { "lq", cmd_lq, "Display link quality" },
- { "tpl", cmd_tpl, "Display transmit power level" },
- { "afh", cmd_afh, "Display AFH channel map" },
- { "lp", cmd_lp, "Set/display link policy settings" },
- { "lst", cmd_lst, "Set/display link supervision timeout" },
- { "auth", cmd_auth, "Request authentication" },
- { "enc", cmd_enc, "Set connection encryption" },
- { "key", cmd_key, "Change connection link key" },
- { "clkoff", cmd_clkoff, "Read clock offset" },
- { "clock", cmd_clock, "Read local or remote clock" },
- { "lescan", cmd_lescan, "Start LE scan" },
- { "lewladd", cmd_lewladd, "Add device to LE White List" },
- { "lecc", cmd_lecc, "Create a LE Connection" },
- { "ledc", cmd_ledc, "Disconnect a LE Connection" },
- { "lecup", cmd_lecup, "LE Connection Update" },
+ { "dev", cmd_dev, "Display local devices" },
+ { "inq", cmd_inq, "Inquire remote devices" },
+ { "scan", cmd_scan, "Scan for remote devices" },
+ { "name", cmd_name, "Get name from remote device" },
+ { "info", cmd_info, "Get information from remote device" },
+ { "spinq", cmd_spinq, "Start periodic inquiry" },
+ { "epinq", cmd_epinq, "Exit periodic inquiry" },
+ { "cmd", cmd_cmd, "Submit arbitrary HCI commands" },
+ { "con", cmd_con, "Display active connections" },
+ { "cc", cmd_cc, "Create connection to remote device" },
+ { "dc", cmd_dc, "Disconnect from remote device" },
+ { "sr", cmd_sr, "Switch master/slave role" },
+ { "cpt", cmd_cpt, "Change connection packet type" },
+ { "rssi", cmd_rssi, "Display connection RSSI" },
+ { "lq", cmd_lq, "Display link quality" },
+ { "tpl", cmd_tpl, "Display transmit power level" },
+ { "afh", cmd_afh, "Display AFH channel map" },
+ { "lp", cmd_lp, "Set/display link policy settings" },
+ { "lst", cmd_lst, "Set/display link supervision timeout" },
+ { "auth", cmd_auth, "Request authentication" },
+ { "enc", cmd_enc, "Set connection encryption" },
+ { "key", cmd_key, "Change connection link key" },
+ { "clkoff", cmd_clkoff, "Read clock offset" },
+ { "clock", cmd_clock, "Read local or remote clock" },
+ { "lescan", cmd_lescan, "Start LE scan" },
+ { "lewladd", cmd_lewladd, "Add device to LE White List" },
+ { "lecc", cmd_lecc, "Create a LE Connection" },
+ { "ledc", cmd_ledc, "Disconnect a LE Connection" },
+ { "lecup", cmd_lecup, "LE Connection Update" },
{ NULL, NULL, 0 }
};
--
1.7.4.1
^ permalink raw reply related
* [PATCH 1/5] hcitool: Add command to add a device to LE White List
From: Claudio Takahasi @ 2011-02-28 18:18 UTC (permalink / raw)
To: linux-bluetooth; +Cc: Arun Kumar Singh
From: Arun Kumar Singh <arunkat@gmail.com>
---
lib/hci.c | 29 +++++++++++++++++++++++++++++
lib/hci.h | 6 ++++++
lib/hci_lib.h | 2 +-
tools/hcitool.c | 47 +++++++++++++++++++++++++++++++++++++++++++++++
4 files changed, 83 insertions(+), 1 deletions(-)
diff --git a/lib/hci.c b/lib/hci.c
index 688b0b4..fc710f4 100644
--- a/lib/hci.c
+++ b/lib/hci.c
@@ -1291,6 +1291,35 @@ int hci_disconnect(int dd, uint16_t handle, uint8_t reason, int to)
return 0;
}
+int hci_le_add_white_list(int dd, const bdaddr_t *bdaddr, uint8_t type, int to)
+{
+ struct hci_request rq;
+ le_add_device_to_white_list_cp cp;
+ uint8_t status;
+
+ memset(&cp, 0, sizeof(cp));
+ cp.bdaddr_type = type;
+ bacpy(&cp.bdaddr, bdaddr);
+
+ memset(&rq, 0, sizeof(rq));
+ rq.ogf = OGF_LE_CTL;
+ rq.ocf = OCF_LE_ADD_DEVICE_TO_WHITE_LIST;
+ rq.cparam = &cp;
+ rq.clen = LE_ADD_DEVICE_TO_WHITE_LIST_CP_SIZE;
+ rq.rparam = &status;
+ rq.rlen = 1;
+
+ if (hci_send_req(dd, &rq, to) < 0)
+ return -1;
+
+ if (status) {
+ errno = EIO;
+ return -1;
+ }
+
+ return 0;
+}
+
int hci_read_local_name(int dd, int len, char *name, int to)
{
read_local_name_rp rp;
diff --git a/lib/hci.h b/lib/hci.h
index 9b5388b..d2d4f77 100644
--- a/lib/hci.h
+++ b/lib/hci.h
@@ -75,6 +75,12 @@ enum {
HCI_RAW,
};
+/* LE address type */
+enum {
+ LE_PUBLIC_ADDRESS = 0x00,
+ LE_RANDOM_ADDRESS = 0x01
+};
+
/* HCI ioctl defines */
#define HCIDEVUP _IOW('H', 201, int)
#define HCIDEVDOWN _IOW('H', 202, int)
diff --git a/lib/hci_lib.h b/lib/hci_lib.h
index 5be8d50..fb2c7cb 100644
--- a/lib/hci_lib.h
+++ b/lib/hci_lib.h
@@ -131,7 +131,7 @@ int hci_le_create_conn(int dd, uint16_t interval, uint16_t window,
int hci_le_conn_update(int dd, uint16_t handle, uint16_t min_interval,
uint16_t max_interval, uint16_t latency,
uint16_t supervision_timeout, int to);
-
+int hci_le_add_white_list(int dd, const bdaddr_t *bdaddr, uint8_t type, int to);
int hci_for_each_dev(int flag, int(*func)(int dd, int dev_id, long arg), long arg);
int hci_get_route(bdaddr_t *bdaddr);
diff --git a/tools/hcitool.c b/tools/hcitool.c
index ebc8448..1184b6b 100644
--- a/tools/hcitool.c
+++ b/tools/hcitool.c
@@ -2564,6 +2564,52 @@ static void cmd_lecc(int dev_id, int argc, char **argv)
hci_close_dev(dd);
}
+static struct option lewladd_options[] = {
+ { "help", 0, 0, 'h' },
+ { 0, 0, 0, 0 }
+};
+
+static const char *lewladd_help =
+ "Usage:\n"
+ "\tlewladd <bdaddr>\n";
+
+static void cmd_lewladd(int dev_id, int argc, char **argv)
+{
+ int err, opt, dd;
+ bdaddr_t bdaddr;
+
+ for_each_opt(opt, lewladd_options, NULL) {
+ switch (opt) {
+ default:
+ printf("%s", lewladd_help);
+ return;
+ }
+ }
+
+ helper_arg(1, 1, &argc, &argv, lewladd_help);
+
+ if (dev_id < 0)
+ dev_id = hci_get_route(NULL);
+
+ dd = hci_open_dev(dev_id);
+ if (dd < 0) {
+ perror("Could not open device");
+ exit(1);
+ }
+
+ str2ba(argv[0], &bdaddr);
+
+ err = hci_le_add_white_list(dd, &bdaddr, LE_PUBLIC_ADDRESS, 1000);
+ hci_close_dev(dd);
+
+ if (err < 0) {
+ err = errno;
+ fprintf(stderr, "Can't add to white list: %s(%d)\n",
+ strerror(err), err);
+ exit(1);
+ }
+}
+
static struct option ledc_options[] = {
{ "help", 0, 0, 'h' },
{ 0, 0, 0, 0 }
@@ -2725,6 +2771,7 @@ static struct {
{ "clkoff", cmd_clkoff, "Read clock offset" },
{ "clock", cmd_clock, "Read local or remote clock" },
{ "lescan", cmd_lescan, "Start LE scan" },
+ { "lewladd", cmd_lewladd, "Add device to LE White List" },
{ "lecc", cmd_lecc, "Create a LE Connection" },
{ "ledc", cmd_ledc, "Disconnect a LE Connection" },
{ "lecup", cmd_lecup, "LE Connection Update" },
--
1.7.4.1
^ permalink raw reply related
* Re: [bluetooth-next 04/15] Bluetooth: Add support for using the crypto subsystem
From: Vinicius Costa Gomes @ 2011-02-28 17:40 UTC (permalink / raw)
To: linux-bluetooth, Anderson Briglia
In-Reply-To: <20110228172801.GB2165@joana>
On 14:28 Mon 28 Feb, Gustavo F. Padovan wrote:
> Hi Vinicius,
>
> * Vinicius Gomes <vinicius.gomes@openbossa.org> [2011-02-27 21:49:39 -0300]:
>
[ ... ]
> >
> > I have a couple of points against it:
> >
> > 1. it's only used for one purpose, it says whether to try or not to
> > allocate the block cypher, which is done during the adapter
> > registration;
> >
> > 2. If the current way is ok, it would mean that I would need to export
> > another method from smp.c, that was something that I tried to
> > minimize;
> >
> > 3. and my weakest argument, seems that there are other similar uses,
> > for example enable_mgmt.
>
> A similar example here is enable_ertm inside l2cap_core.c. It's a L2CAP
> related option and should reside inside L2CAP code.
>
> >
> > But if you think the code will be clearer moving that to smp.c, will
> > be glad to change.
>
> I don't see the point on have it on hci code. SMP and Block cypher has
> not much to do with HCI. I prefer it on smp.c
Fair enough. Will change.
>
> --
> Gustavo F. Padovan
> http://profusion.mobi
Cheers,
--
Vinicius
^ permalink raw reply
* Re: [PATCH] Bluetooth: Log all parameters in cmd_status for easier debugging
From: Gustavo F. Padovan @ 2011-02-28 17:33 UTC (permalink / raw)
To: Szymon Janc; +Cc: linux-bluetooth, par-gunnar.p.hjalmdahl, henrik.possung
In-Reply-To: <1298898608-9110-1-git-send-email-szymon.janc@tieto.com>
Hi Szymon,
* Szymon Janc <szymon.janc@tieto.com> [2011-02-28 14:10:08 +0100]:
> Signed-off-by: Szymon Janc <szymon.janc@tieto.com>
> ---
> net/bluetooth/mgmt.c | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
Applied, thanks.
--
Gustavo F. Padovan
http://profusion.mobi
^ permalink raw reply
* Re: [PATCH] Bluetooth: Fix possible NULL pointer dereference in cmd_complete
From: Gustavo F. Padovan @ 2011-02-28 17:32 UTC (permalink / raw)
To: Szymon Janc; +Cc: linux-bluetooth, par-gunnar.p.hjalmdahl, henrik.possung
In-Reply-To: <1298898590-9052-1-git-send-email-szymon.janc@tieto.com>
Hi Szymon,
* Szymon Janc <szymon.janc@tieto.com> [2011-02-28 14:09:50 +0100]:
> It is now possible to create command complete event without specific
> reply data by passing NULL as reply with len 0. Check pointer before
> calling memcpy to avoid undefined behaviour.
> ---
> net/bluetooth/mgmt.c | 4 +++-
> 1 files changed, 3 insertions(+), 1 deletions(-)
Patch is now applied. Thanks.
--
Gustavo F. Padovan
http://profusion.mobi
^ permalink raw reply
* Re: [PATCH] work around for l2cap NULL dereference in l2cap_conn_start
From: Gustavo F. Padovan @ 2011-02-28 17:30 UTC (permalink / raw)
To: David Fries
Cc: Liang Bao, Andrei Warkentin, linux-bluetooth, linux-kernel,
Feng Tang
In-Reply-To: <20110228050340.GC22204@spacedout.fries.net>
Hi David,
* David Fries <david@fries.net> [2011-02-27 23:03:40 -0600]:
> On Sun, Feb 27, 2011 at 04:15:45PM -0300, Gustavo F. Padovan wrote:
> > I pushed the following patch to bluetooth-2.6 tree. It should fix the problem
> > by avoiding connections to be accepted before a L2CAP info response comes:
>
> Is
> git://git.kernel.org/pub/scm/linux/kernel/git/padovan/bluetooth-2.6.git
> the bluetooth-2.6 tree you mentioned? I don't see your patch there.
> As a side note, the inline patch in your e-mail has the tabs replaced by
> spaces, once I changed them, it applied cleanly.
>
> I first reverted to the base N900 kernel-power-2.6.28 46 (none of my
> changes or debugging), it crashed as expected. I then applied your
> patch 743400e0, and it still crashed. I added back the
> l2cap_conn_start parent check and some debugging in af_bluetooth.c
> dmesg debug output and patches follow.
I want to see a test with this patch and a recent kernel. We added many fixes
to stack in the last two years. Can you test this scenario?
--
Gustavo F. Padovan
http://profusion.mobi
^ permalink raw reply
* Re: [bluetooth-next 04/15] Bluetooth: Add support for using the crypto subsystem
From: Gustavo F. Padovan @ 2011-02-28 17:28 UTC (permalink / raw)
To: Vinicius Gomes; +Cc: linux-bluetooth, Anderson Briglia
In-Reply-To: <AANLkTi=j3REcNM4bXfFJPamPwqazS5k4eGAJf3BpB_Ya@mail.gmail.com>
Hi Vinicius,
* Vinicius Gomes <vinicius.gomes@openbossa.org> [2011-02-27 21:49:39 -0300]:
> Hi Gustavo,
>
> On Sun, Feb 27, 2011 at 5:20 PM, Gustavo F. Padovan
> <padovan@profusion.mobi> wrote:
> > Hi Vinicius,
> >
> > * Vinicius Costa Gomes <vinicius.gomes@openbossa.org> [2011-02-21 14:23:51 -0300]:
> >
> >> This will allow using the crypto subsystem for encrypting data. As SMP
> >> (Security Manager Protocol) is implemented almost entirely on the host
> >> side and the crypto module already implements the needed methods
> >> (AES-128), it makes sense to use it.
> >>
> >> This patch also adds a new Kconfig option to toggle the SMP support.
> >>
> >> Signed-off-by: Vinicius Costa Gomes <vinicius.gomes@openbossa.org>
> >> Signed-off-by: Anderson Briglia <anderson.briglia@openbossa.org>
> >> ---
> >> include/net/bluetooth/hci_core.h | 2 ++
> >> net/bluetooth/Kconfig | 6 ++++++
> >> net/bluetooth/hci_core.c | 22 ++++++++++++++++++++++
> >> net/bluetooth/smp.c | 17 +++++++++++++++--
> >> 4 files changed, 45 insertions(+), 2 deletions(-)
> >>
> >> diff --git a/include/net/bluetooth/hci_core.h b/include/net/bluetooth/hci_core.h
> >> index d5d8454..e8dbde8 100644
> >> --- a/include/net/bluetooth/hci_core.h
> >> +++ b/include/net/bluetooth/hci_core.h
> >> @@ -161,6 +161,8 @@ struct hci_dev {
> >>
> >> __u16 init_last_cmd;
> >>
> >> + struct crypto_blkcipher *tfm;
> >> +
> >> struct inquiry_cache inq_cache;
> >> struct hci_conn_hash conn_hash;
> >> struct list_head blacklist;
> >> diff --git a/net/bluetooth/Kconfig b/net/bluetooth/Kconfig
> >> index c6f9c2f..e9f40af 100644
> >> --- a/net/bluetooth/Kconfig
> >> +++ b/net/bluetooth/Kconfig
> >> @@ -22,6 +22,7 @@ menuconfig BT
> >> BNEP Module (Bluetooth Network Encapsulation Protocol)
> >> CMTP Module (CAPI Message Transport Protocol)
> >> HIDP Module (Human Interface Device Protocol)
> >> + SMP Module (Security Manager Protocol)
> >>
> >> Say Y here to compile Bluetooth support into the kernel or say M to
> >> compile it as module (bluetooth).
> >> @@ -35,11 +36,16 @@ config BT_L2CAP
> >> bool "L2CAP protocol support"
> >> depends on BT
> >> select CRC16
> >> + select CRYPTO_BLKCIPHER
> >> + select CRYPTO_AES
> >> help
> >> L2CAP (Logical Link Control and Adaptation Protocol) provides
> >> connection oriented and connection-less data transport. L2CAP
> >> support is required for most Bluetooth applications.
> >>
> >> + Also included is support for SMP (Security Manager Protocol) which
> >> + is the security layer on top of LE (Low Energy) links.
> >> +
> >> config BT_SCO
> >> bool "SCO links support"
> >> depends on BT
> >> diff --git a/net/bluetooth/hci_core.c b/net/bluetooth/hci_core.c
> >> index b372fb8..ff67843 100644
> >> --- a/net/bluetooth/hci_core.c
> >> +++ b/net/bluetooth/hci_core.c
> >> @@ -42,6 +42,7 @@
> >> #include <linux/notifier.h>
> >> #include <linux/rfkill.h>
> >> #include <linux/timer.h>
> >> +#include <linux/crypto.h>
> >> #include <net/sock.h>
> >>
> >> #include <asm/system.h>
> >> @@ -60,6 +61,8 @@ static void hci_notify(struct hci_dev *hdev, int event);
> >>
> >> static DEFINE_RWLOCK(hci_task_lock);
> >>
> >> +static int enable_smp;
> >> +
> >> /* HCI device list */
> >> LIST_HEAD(hci_dev_list);
> >> DEFINE_RWLOCK(hci_dev_list_lock);
> >> @@ -1077,6 +1080,14 @@ static void hci_cmd_timer(unsigned long arg)
> >> tasklet_schedule(&hdev->cmd_task);
> >> }
> >>
> >> +static struct crypto_blkcipher *alloc_cypher(void)
> >> +{
> >> + if (enable_smp)
> >> + return crypto_alloc_blkcipher("ecb(aes)", 0, CRYPTO_ALG_ASYNC);
> >> +
> >> + return ERR_PTR(-ENOTSUPP);
> >> +}
> >> +
> >> /* Register HCI device */
> >> int hci_register_dev(struct hci_dev *hdev)
> >> {
> >> @@ -1155,6 +1166,11 @@ int hci_register_dev(struct hci_dev *hdev)
> >> if (!hdev->workqueue)
> >> goto nomem;
> >>
> >> + hdev->tfm = alloc_cypher();
> >> + if (IS_ERR(hdev->tfm))
> >> + BT_INFO("Failed to load transform for ecb(aes): %ld",
> >> + PTR_ERR(hdev->tfm));
> >> +
> >> hci_register_sysfs(hdev);
> >>
> >> hdev->rfkill = rfkill_alloc(hdev->name, &hdev->dev,
> >> @@ -1203,6 +1219,9 @@ int hci_unregister_dev(struct hci_dev *hdev)
> >> !test_bit(HCI_SETUP, &hdev->flags))
> >> mgmt_index_removed(hdev->id);
> >>
> >> + if (!IS_ERR(hdev->tfm))
> >> + crypto_free_blkcipher(hdev->tfm);
> >> +
> >> hci_notify(hdev, HCI_DEV_UNREG);
> >>
> >> if (hdev->rfkill) {
> >> @@ -2037,3 +2056,6 @@ static void hci_cmd_task(unsigned long arg)
> >> }
> >> }
> >> }
> >> +
> >> +module_param(enable_smp, bool, 0644);
> >> +MODULE_PARM_DESC(enable_smp, "Enable SMP support (LE only)");
> >
> > This all should be obviously inside smp.c
>
> I have a couple of points against it:
>
> 1. it's only used for one purpose, it says whether to try or not to
> allocate the block cypher, which is done during the adapter
> registration;
>
> 2. If the current way is ok, it would mean that I would need to export
> another method from smp.c, that was something that I tried to
> minimize;
>
> 3. and my weakest argument, seems that there are other similar uses,
> for example enable_mgmt.
A similar example here is enable_ertm inside l2cap_core.c. It's a L2CAP
related option and should reside inside L2CAP code.
>
> But if you think the code will be clearer moving that to smp.c, will
> be glad to change.
I don't see the point on have it on hci code. SMP and Block cypher has
not much to do with HCI. I prefer it on smp.c
--
Gustavo F. Padovan
http://profusion.mobi
^ permalink raw reply
* Re: Do you have a plan to split ERTM into a separate file?
From: Gustavo F. Padovan @ 2011-02-28 17:19 UTC (permalink / raw)
To: Haijun Liu; +Cc: (linux-bluetooth@vger.kernel.org), Dan Tian
In-Reply-To: <6AAC4214B9104E409FF4885ACB62A96101A6A6762B@SHEXMB-01.global.atheros.com>
Hi Haijun,
* Haijun Liu <Haijun.Liu@Atheros.com> [2011-02-24 21:14:42 +0800]:
> Dear Gustavo,
>
> Do you have a plan to split ERTM code into a separate file?
> It may be easier to read/learn ERTM mechanism with loosely coupled code for people.
> Thank you! :)
I don't. But I'll be happy if you send me patches for that. ;)
--
Gustavo F. Padovan
http://profusion.mobi
^ permalink raw reply
* Rfcomm - possible circular locking dependency - Is it a bug???
From: Ferraton, Jean RegisX @ 2011-02-28 15:45 UTC (permalink / raw)
To: linux-bluetooth@vger.kernel.org
Hi,
I've found a problem of "possible circular locking dependency" related to rfcomm.
I'm not sure if it's really a bug or just a warning.
I've inserted the trace below.
This problem occurs in 2 cases:
1- When initiating a connection from the remote device
2- When browsing my BT device from my PC
My analysis is the following:
1- We call the function rfcomm_sock_shutdown() which locks a socket, an after calls __rfcomm_sock_close()
lock_sock(sk);
if (!sk->sk_shutdown) {
sk->sk_shutdown = SHUTDOWN_MASK;
__rfcomm_sock_close(sk);
2- In the function __rfcomm_sock_close(), we call rfcomm_dlc_close()
case BT_CONNECTED:
rfcomm_dlc_close(d, 0);
3- In the function rfcomm_dlc_close(), we call rfcomm_lock() which locks a mutex on rfcomm, and this second lock causes the problem.
rfcomm_lock();
r = __rfcomm_dlc_close(d, err);
After this quick analysis, I'm not sure if it's a real bug which needs to be solved or if it's only a warning.
Anyone could help?
My message trace is the following (for remote connect):
[ 113.995511] =======================================================
[ 114.001897] [ INFO: possible circular locking dependency detected ] [ 114.008157] 2.6.35.3jrf_fix #1 [ 114.011196] -------------------------------------------------------
[ 114.017457] bluetoothd/511 is trying to acquire lock:
[ 114.022499] (rfcomm_mutex){+.+.+.}, at: [<c14f281a>] rfcomm_dlc_close+0x15/0x30 [ 114.029887] [ 114.029892] but task is already holding lock:
[ 114.035713] (sk_lock-AF_BLUETOOTH){+.+.+.}, at: [<c14f4cfe>] rfcomm_sock_shutdown+0x17/0x5d [ 114.044147] [ 114.044152] which lock already depends on the new lock.
[ 114.044158]
[ 114.052319]
[ 114.052324] the existing dependency chain (in reverse order) is:
[ 114.059796]
[ 114.059801] -> #1 (sk_lock-AF_BLUETOOTH){+.+.+.}:
[ 114.065967] [<c105d660>] lock_acquire+0xf9/0x135
[ 114.071184] [<c1445cf3>] lock_sock_nested+0x55/0x65
[ 114.076662] [<c14ed17d>] l2cap_sock_sendmsg+0x3f/0x606
[ 114.082400] [<c1443775>] sock_sendmsg+0xc9/0xe0
[ 114.087530] [<c14437b4>] kernel_sendmsg+0x28/0x37
[ 114.092833] [<c14f2278>] rfcomm_send_frame+0x2f/0x37
[ 114.098398] [<c14f232c>] rfcomm_send_ua+0x57/0x59
[ 114.103701] [<c14f3884>] rfcomm_run+0x431/0xb06
[ 114.108830] [<c104bc8f>] kthread+0x5f/0x64
[ 114.113525] [<c1002b7a>] kernel_thread_helper+0x6/0x1a
[ 114.119265]
[ 114.119270] -> #0 (rfcomm_mutex){+.+.+.}:
[ 114.124739] [<c105cff1>] __lock_acquire+0xe03/0x1379
[ 114.130304] [<c105d660>] lock_acquire+0xf9/0x135
[ 114.135522] [<c1522bf3>] mutex_lock_nested+0x45/0x286
[ 114.141171] [<c14f281a>] rfcomm_dlc_close+0x15/0x30
[ 114.146650] [<c14f4cdb>] __rfcomm_sock_close+0x5e/0x6a
[ 114.152388] [<c14f4d12>] rfcomm_sock_shutdown+0x2b/0x5d
[ 114.158212] [<c14f4d5d>] rfcomm_sock_release+0x19/0x60
[ 114.163951] [<c14445da>] sock_release+0x14/0x5b
[ 114.169080] [<c144463d>] sock_close+0x1c/0x20
[ 114.174037] [<c10bdd19>] fput+0xfa/0x19e
[ 114.178557] [<c10bb3c5>] filp_close+0x51/0x5b
[ 114.183512] [<c10bb488>] sys_close+0xb9/0xee
[ 114.188381] [<c1002650>] sysenter_do_call+0x12/0x36
[ 114.193858]
[ 114.193863] other info that might help us debug this:
[ 114.193870]
[ 114.201860] 1 lock held by bluetoothd/511:
[ 114.205945] #0: (sk_lock-AF_BLUETOOTH){+.+.+.}, at: [<c14f4cfe>] rfcomm_sock_shutdown
+0x17/0x5d
[ 114.214811]
[ 114.214816] stack backtrace:
[ 114.219167] Pid: 511, comm: bluetoothd Tainted: G WC 2.6.35.3jrf_fix #1
[ 114.226463] Call Trace:
[ 114.228913] [<c152108a>] ? printk+0xf/0x11
[ 114.233086] [<c105bc3b>] print_circular_bug+0x90/0x9c
[ 114.238211] [<c105cff1>] __lock_acquire+0xe03/0x1379
[ 114.243260] [<c14f281a>] ? rfcomm_dlc_close+0x15/0x30
[ 114.248382] [<c105d660>] lock_acquire+0xf9/0x135
[ 114.253079] [<c14f281a>] ? rfcomm_dlc_close+0x15/0x30
[ 114.258208] [<c1522bf3>] mutex_lock_nested+0x45/0x286
[ 114.263338] [<c14f281a>] ? rfcomm_dlc_close+0x15/0x30
[ 114.268469] [<c105b68d>] ? trace_hardirqs_on_caller+0x100/0x121
[ 114.274467] [<c1445cf8>] ? lock_sock_nested+0x5a/0x65
[ 114.279597] [<c105b6b9>] ? trace_hardirqs_on+0xb/0xd
[ 114.284639] [<c14f281a>] rfcomm_dlc_close+0x15/0x30
[ 114.289594] [<c14f4cdb>] __rfcomm_sock_close+0x5e/0x6a
[ 114.294811] [<c14f4d12>] rfcomm_sock_shutdown+0x2b/0x5d
[ 114.300115] [<c14f4d5d>] rfcomm_sock_release+0x19/0x60
[ 114.305331] [<c14445da>] sock_release+0x14/0x5b
[ 114.309937] [<c144463d>] sock_close+0x1c/0x20
[ 114.314373] [<c10bdd19>] fput+0xfa/0x19e
[ 114.318371] [<c10bb3c5>] filp_close+0x51/0x5b
[ 114.322804] [<c10bb488>] sys_close+0xb9/0xee
[ 114.327151] [<c1002650>] sysenter_do_call+0x12/0x36
Thanks for any help
Regards
Jean Ferraton
---------------------------------------------------------------------
Intel Corporation SAS (French simplified joint stock company)
Registered headquarters: "Les Montalets"- 2, rue de Paris,
92196 Meudon Cedex, France
Registration Number: 302 456 199 R.C.S. NANTERRE
Capital: 4,572,000 Euros
This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.
^ permalink raw reply
* [PATCH] Fix pulling phonebook entries without last name
From: Lukasz Pawlik @ 2011-02-28 15:19 UTC (permalink / raw)
To: linux-bluetooth; +Cc: Lukasz Pawlik
This patch fix problem with pulling phonebook entries using PBAP without
last name filled. Previously last name was used to sort phonebook data
now only tracker id is used.
---
plugins/phonebook-tracker.c | 5 ++---
1 files changed, 2 insertions(+), 3 deletions(-)
diff --git a/plugins/phonebook-tracker.c b/plugins/phonebook-tracker.c
index 9963aab..bc196b8 100644
--- a/plugins/phonebook-tracker.c
+++ b/plugins/phonebook-tracker.c
@@ -135,11 +135,10 @@
"\"NOTACALL\" \"false\" \"false\" " \
"?_contact " \
"WHERE {" \
-" ?_contact a nco:PersonContact ;" \
-" nco:nameFamily ?_key ." \
+" ?_contact a nco:PersonContact ." \
" OPTIONAL {?_contact nco:hasAffiliation ?_role .}" \
"}" \
-"ORDER BY ?_key tracker:id(?_contact)"
+"ORDER BY tracker:id(?_contact)"
#define CONTACTS_QUERY_ALL_LIST \
"SELECT ?c nco:nameFamily(?c) " \
--
1.7.0.4
^ permalink raw reply related
* Re: [PATCH 00/11] mfd and bluetooth: Add CG2900 suppor
From: Arnd Bergmann @ 2011-02-28 15:01 UTC (permalink / raw)
To: Par-Gunnar HJALMDAHL
Cc: Pavan Savoy, Vitaly Wool, Linus Walleij, Alan Cox, Samuel Ortiz,
Marcel Holtmann, linux-kernel@vger.kernel.org,
linux-bluetooth@vger.kernel.org, Lukasz Rymanowski,
Par-Gunnar Hjalmdahl
In-Reply-To: <AFCDDB4A3EA003429EEF1E7B211FDBBA334A54F4B1@EXDCVYMBSTM005.EQ1STM.local>
Hi Pär-Gunnar,
Sorry for the long delay, this time on my side.
On Thursday 24 February 2011, Par-Gunnar HJALMDAHL wrote:
> I sent the mail below one month ago, but have still not received any answers or further comments.
> Has anyone of you who made comments on the CG2900 patches earlier, any more comments or questions?
I tend to procrastinate replying to emails when it's a lot of work, and
yours dropped off the radar. I have not even read it until now, because
it's too long, has broken line-wraps and does not crop the citations
to a minimum. If you want people to listen to what you have to say, try
following email netiquette and put a little more effort into clear
communication like the rest of us do.
Please excuse my ignorance about topics we have already discussed here,
I don't know much about bluetooth and had to reread all the discussions
and patches.
> It is unclear to me where we stand with the CG2900 patches. I am myself happy with the
> current architecture, but I understand there are differing opinions.
> I would like to know what we need to do in order to get this driver into the Linux Kernel tree.
I have no idea what the current architecture is. In doubt, keep re-posting
the patches until all differences are resolved. If a thread does not
get a new message within a week, you can normally assume that poeple
no longer bother reading, and you should try harder to get feedback,
e.g. by sending a reminder that you are waiting or by resending
the modified patch set.
I still haven't looked at the patches from December, but I assume that
the code has changed in the meantime. Please go ahead and post the
current version again, then we can discuss the new code.
On Monday 17 January 2011, Par-Gunnar HJALMDAHL wrote:
> Arnd Bergmann wrote:
> >
> > Good point about hciattach, you certainly shouldn't need to use that if
> > the kernel already knows that a tty is connected to an HCI and what the
> > parameters are. Even more so if the HCI is not actually on a rs232 line
> > but something like i2c or spi. Automatically binding to the right line
> > discipline should be easily doable in the drivers though.
> >
>
> When having UART as transport you need something to open the UART and set the
> line discipline. If this is hciattach or something else is up to each developer
> to suit what they are doing. I don't see a problem with using hciattach even
> if you don't use the Bluetooth part (if the exe is part of the system anyway),
> but if a company/developer want to use something else they can do that. It's a
> usage of standard interfaces using open() and ioctl().
That's not what I meant. You don't really need to use the ioctl if the
kernel already knows what the device does. Just call tty_set_ldisc from
an appropriate location in the code.
> I still don't think that you should have a line discipline for other transports
> than UART. If I would look at how I would implement an SPI driver for CG2900,
> there would almost be no code that could be used in common between cg2900_uart
> and cg2900_spi. SPI doesn't change baud rate, SPI uses commands for sleep/wake
> instead of Break, SPI packets doesn't need extra packetizing, etc.
If you don't want the others to be handled in a line discipline, you should
start out with a patch that splits the hci uart protocol registration from the
line discipline code in drivers/bluetooth/hci_ldisc.c. Today, you can have
multiple HCI drivers in the system, but only the serial one can have
subprotocols.
> > I don't understand the problem with relying on the hci-uart or hci-h4
> > modules. If the hardware uses the H4 protocol, we certainly should use
> > the kernel module that knows how to deal with H4, and we don't want
> > to have two modules implementing the same protocol.
> >
>
> I must say I don't understand this problem either. Unless the protocol driver is
> activated through ioctl SET_PROTOCOL, the code will not be executed, and the amount
> of ROM needed is negligible.
> If you look at our submission, the hci-h4 could possibly be reused to some extent.
> Basically the packetizing to the Bluetooth H4 channels 1-4 could be re-used. In order
> to allow for vendor specific channels to be handled some new registration system on
> top of hci-h4 plus a callback system for data reception would have to be added (in
> order to facilitate systems that do not want all data to be sent directly to the
> Bluetooth stack such as the CG2900 driver). I'm afraid that we would have a
> significantly more complex system and larger amount of code if we would try to generalize
> the hci-h4 module. I definitely prefer the current model where a vendor specific driver
> replaces the hci-h4 protocol driver.
Then remove the hci-h4 driver from the kernel and make sure that your driver can
handle all the hardware that h4 can today, using identical user interfaces.
Two infrastructure drivers doing almost the same thing are not acceptable.
We sometimes have device drivers that are meant for the same hardware, but
then one of them is going away over time, when it is shown that the new one
does everything we need. For infrastructure, this is not as easy, because
then you get other people writing new backend for both of them and they
won't be interoperable.
> > The one important goal here should be to avoid code duplication.
> > Using the header to get the data structures from separate code
> > means you need to have similar parsing functions in each of the modules
> > using it. Not sharing the header wouldn't help, because then you end
> > up duplicating even more. The real solution, speaking very broadly,
> > must be to have a general module that deals with whatever the more
> > specific modules have in common, and have a header file that defines
> > the interface to it.
> >
>
> In general I agree with you, but there are some problems here.
> The most used BT HCI events are Command Status and Command Complete.
> Command Status could be parsed completely in a good way (retrieving op
> code, nbr of commands allowed, and status of command sent).
> Command Complete is however quite complex since the returned data will
> differ depending on command sent. Op code and nbr of commands allowed can
> be retrieved but everything else have to be extracted differently depending
> on command. This means that there is not much that will be saved here. But
> maybe we could extract some parsing into common functions, but I don't
> think you would gain that much.
>
> Moreover, this would lead to a major reimplementation of the hci_core.c and
> related files, since they do not use any exported common functions as it is
> today. I do not know if they (BlueZ community) would want this and I do not
> think that that should be part of the CG2900 driver to do. It should in that
> case be done separately.
No. If hci_core is not sufficient to work with cg2900, the answer is certainly
not to ignore hci_core and roll your own copy. Can you give an example
of how the command complete logic needs to react to different commands?
Can this be done using callbacks into the code that initially sent the
commands?
> For the CG2900 that is not possible. Even if you are running just GPS you
> still must download patches and settings and that is done through HCI
> commands over the Bluetooth command interface. We also use Bluetooth
> commands to identify the controller.
I don't understand. Do you mean the settings are sent over the wireless
interface in order to control devices that are connected directly to
the HCI? Why would you do that instead of just attaching the
GPS to the HCI on the non-bluetooth side?
Arnd
^ permalink raw reply
* [PATCH] Adjust prefix of contact id for getting pb size
From: Rafal Michalski @ 2011-02-28 13:53 UTC (permalink / raw)
To: linux-bluetooth; +Cc: Rafal Michalski
Getting phonebook size is related to recognizing contacts by their id
prefixes. Previously it was "contact: " and has been changed to
"urn:uuid:". This patch fixes it and allows to get valid phonebook size.
---
plugins/phonebook-tracker.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/plugins/phonebook-tracker.c b/plugins/phonebook-tracker.c
index b204493..99848e3 100644
--- a/plugins/phonebook-tracker.c
+++ b/plugins/phonebook-tracker.c
@@ -809,7 +809,7 @@
"SELECT COUNT(?c) " \
"WHERE {" \
"?c a nco:PersonContact ." \
- "FILTER (regex(str(?c), \"contact:\"))" \
+ "FILTER (regex(str(?c), \"urn:uuid:\"))" \
"}"
#define MISSED_CALLS_COUNT_QUERY \
--
1.6.3.3
^ permalink raw reply related
* [PATCH 4/4] TODO: Add item to implement device type in the DeviceFound signal
From: Claudio Takahasi @ 2011-02-28 13:44 UTC (permalink / raw)
To: linux-bluetooth; +Cc: Claudio Takahasi
In-Reply-To: <1298900653-7567-1-git-send-email-claudio.takahasi@openbossa.org>
---
TODO | 6 ++++++
1 files changed, 6 insertions(+), 0 deletions(-)
diff --git a/TODO b/TODO
index 9f899b0..4e3585e 100644
--- a/TODO
+++ b/TODO
@@ -78,6 +78,12 @@ Low Energy
Priority: Medium
Complexity: C2
+- Add new property in the DeviceFound signal to report the device type:
+ BR/EDR, single mode or dual-mode.
+
+ Priority: Medium
+ Complexity: C1
+
- Privacy: When privacy is enabled in the adapter, LE scanning/connection
should use a private address. StartDiscovery method shall be changed and
new adapter property shall be added.
--
1.7.4.1
^ permalink raw reply related
* [PATCH 3/4] TODO: Add item related to UUID handling
From: Claudio Takahasi @ 2011-02-28 13:44 UTC (permalink / raw)
To: linux-bluetooth; +Cc: Claudio Takahasi
In-Reply-To: <1298900653-7567-1-git-send-email-claudio.takahasi@openbossa.org>
---
TODO | 13 +++++++++++++
1 files changed, 13 insertions(+), 0 deletions(-)
diff --git a/TODO b/TODO
index cf37179..9f899b0 100644
--- a/TODO
+++ b/TODO
@@ -17,6 +17,19 @@ Background
General
==========
+- UUID128 handling: Create new functions to handle UUIDs on host order.
+ Functions should start with prefix "bt_uuid". In the first phase, attribute
+ server/client and gatttool code should be changed to use these new functions.
+ The idea is to keep the consistency for UUID-16, UUID-32 and UUID-128. SDP
+ functions store UUID-16 and UUID-32 on host order, however UUID-128 is stored
+ on network order/big endian. Attribute Protocol uses little endian, while
+ SDP uses big endian. The idea is always store the UUID values on host order
+ and use utility functions to convert to the proper byte order depending on
+ the protocol: ATT or SDP.
+
+ Priority: high
+ Complexity: C1
+
- Rename glib-helper file to a more convenient name. The ideia is try to keep
only sdp helpers functions. bt_* prefix shall be also changed.
--
1.7.4.1
^ permalink raw reply related
* [PATCH 2/4] TODO: Remove item related to Client Characteristic Configuration
From: Claudio Takahasi @ 2011-02-28 13:44 UTC (permalink / raw)
To: linux-bluetooth; +Cc: Claudio Takahasi
In-Reply-To: <1298900653-7567-1-git-send-email-claudio.takahasi@openbossa.org>
Client Characteristic Configuration is already implemented in the
attribute server. Implementation in the attribute client is still
missing.
---
TODO | 9 ---------
1 files changed, 0 insertions(+), 9 deletions(-)
diff --git a/TODO b/TODO
index 45ecb09..cf37179 100644
--- a/TODO
+++ b/TODO
@@ -188,15 +188,6 @@ ATT/GATT
Priority: Low
Complexity: C2
-- Implement Client Characteristic Configuration support in the attribute
- server to manage indications and notications. This is a per client attribute
- to control how the client wants to receive reports of changes in a given
- characteristic value.
- See Volume 3, Part G, section 3.3.3.3 for more information
-
- Priority: Low
- Complexity: C2
-
- Define attribute server API. External applications needs to register,
change attributes and to be notified about changes. Example: Proximity,
Time and Alert Profiles. "Local Service hierarchy" in the attribute-api
--
1.7.4.1
^ permalink raw reply related
* [PATCH 1/4] TODO: Remove item related to ATT transation timeouts
From: Claudio Takahasi @ 2011-02-28 13:44 UTC (permalink / raw)
To: linux-bluetooth; +Cc: Claudio Takahasi
---
TODO | 7 -------
1 files changed, 0 insertions(+), 7 deletions(-)
diff --git a/TODO b/TODO
index 246eb33..45ecb09 100644
--- a/TODO
+++ b/TODO
@@ -205,13 +205,6 @@ ATT/GATT
Priority: Low
Complexity: C2
-- gattrib needs to be extended to handle Attribute Protocol Transactions
- timeout. See Volume 3, Part F, section 3.3.3 and Part G, section 4.14
- for more information.
-
- Priority: Low
- Complexity: C2
-
Management Interface
====================
--
1.7.4.1
^ permalink raw reply related
* Re: [PATCH 2/2] Fix response on adapter RequestSession method
From: Luiz Augusto von Dentz @ 2011-02-28 13:31 UTC (permalink / raw)
To: Dmitriy Paliy; +Cc: linux-bluetooth
In-Reply-To: <1298892865-14930-3-git-send-email-dmitriy.paliy@nokia.com>
Hi Dmitry,
On Mon, Feb 28, 2011 at 8:34 AM, Dmitriy Paliy <dmitriy.paliy@nokia.com> wrote:
> Fixes response on adapter RequestSession method to be sent after mode is
> changed. More specifically change of power off mode to power on is in
> question.
>
> Currenty, response is sent when mode change is confirmed by agent, not by
> response from controller. Such may lead to failed CreateDevice method if
> it is called quickly enough after RequestSession when controller is
> powered off.
> ---
> src/adapter.c | 45 ++++++++++++++++++++++++++++++++++++---------
> 1 files changed, 36 insertions(+), 9 deletions(-)
>
> diff --git a/src/adapter.c b/src/adapter.c
> index 49a23ec..5cdb371 100644
> --- a/src/adapter.c
> +++ b/src/adapter.c
> @@ -510,11 +510,19 @@ done:
>
> DBG("%s", modestr);
>
> - if (msg != NULL)
> - /* Wait for mode change to reply */
> - adapter->pending_mode = create_session(adapter, connection,
> - msg, new_mode, NULL);
> - else
> + if (msg != NULL) {
> + const char *sender = dbus_message_get_sender(msg);
> + struct session_req *req;
> +
> + req = find_session(adapter->mode_sessions, sender);
> + if (req) {
> + adapter->pending_mode = req;
> + session_ref(req);
> + } else
> + /* Wait for mode change to reply */
> + adapter->pending_mode = create_session(adapter,
> + connection, msg, new_mode, NULL);
Im afraid this is wrong, we should get a session which refer to the
same message not only to the same sender, otherwise we can only reply
to the first message that creates the session but the same sender can
call another method in meantime which would not be replied.
> + } else
> /* Nothing to reply just write the new mode */
> adapter->mode = new_mode;
>
> @@ -795,17 +803,31 @@ static void confirm_mode_cb(struct agent *agent, DBusError *derr, void *data)
> return;
> }
>
> - err = set_mode(req->adapter, req->mode, NULL);
> - if (err < 0)
> + err = set_mode(req->adapter, req->mode, req->msg);
> + if (err < 0) {
> reply = btd_error_failed(req->msg, strerror(-err));
> - else
> + goto proceed;
> + }
> +
> + if (!req->adapter->pending_mode) {
> reply = dbus_message_new_method_return(req->msg);
> + goto proceed;
> + }
> +
> + goto done;
>
> +proceed:
> + /*
> + * Send reply immidiately only if there was an error changing
> + * mode, or change is not needed. Otherwise, reply is sent in
> + * set_mode_complete.
> + */
> g_dbus_send_message(req->conn, reply);
>
> dbus_message_unref(req->msg);
> req->msg = NULL;
>
> +done:
> if (!find_session(req->adapter->mode_sessions, req->owner))
> session_unref(req);
> }
> @@ -2485,7 +2507,12 @@ static void set_mode_complete(struct btd_adapter *adapter)
> if (strcmp(dbus_message_get_member(msg),
> "SetProperty") == 0)
> adapter->global_mode = adapter->mode;
> - reply = g_dbus_create_reply(msg, DBUS_TYPE_INVALID);
> +
> + if (strcmp(dbus_message_get_member(msg),
> + "RequestSession") == 0)
> + reply = dbus_message_new_method_return(msg);
> + else
> + reply = g_dbus_create_reply(msg, DBUS_TYPE_INVALID);
Do we really need this? Afaik g_dbus_create_reply do call
dbus_message_new_method_return internally, so perhaps the if clause
for RequestSession is not really necessary since the else clause is
already generating the very same reply.
> }
>
> g_dbus_send_message(connection, reply);
> --
> 1.7.1
>
>
--
Luiz Augusto von Dentz
Computer Engineer
^ permalink raw reply
* [PATCH] Bluetooth: Log all parameters in cmd_status for easier debugging
From: Szymon Janc @ 2011-02-28 13:10 UTC (permalink / raw)
To: linux-bluetooth; +Cc: par-gunnar.p.hjalmdahl, henrik.possung, Szymon Janc
Signed-off-by: Szymon Janc <szymon.janc@tieto.com>
---
net/bluetooth/mgmt.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/net/bluetooth/mgmt.c b/net/bluetooth/mgmt.c
index 34f58f4..e6efaae 100644
--- a/net/bluetooth/mgmt.c
+++ b/net/bluetooth/mgmt.c
@@ -49,7 +49,7 @@ static int cmd_status(struct sock *sk, u16 index, u16 cmd, u8 status)
struct mgmt_hdr *hdr;
struct mgmt_ev_cmd_status *ev;
- BT_DBG("sock %p", sk);
+ BT_DBG("sock %p, index %u, cmd %u, status %u", sk, index, cmd, status);
skb = alloc_skb(sizeof(*hdr) + sizeof(*ev), GFP_ATOMIC);
if (!skb)
--
1.7.0.4
on behalf of ST-Ericsson
^ 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