* pull-request: bluetooth-2.6 2010-10-05
From: Gustavo F. Padovan @ 2010-10-05 17:13 UTC (permalink / raw)
To: David Miller; +Cc: linville, marcel, linux-bluetooth, netdev
Hi Dave,
In this patch set we have two fixes for regressions in L2CAP due to ERTM code
we added in L2CAP for 2.6.36, a bugfix in the L2CAP Streaming Mode that was
making the kernel crash. And a fix for a deadlock issue between the sk_sndbuf
and the backlog queue in ERTM. The rest are also needed bug fixes.
For -next pull request things go back to normal and patches go through John.
Thanks!
The following changes since commit 899611ee7d373e5eeda08e9a8632684e1ebbbf00:
Linux 2.6.36-rc6 (2010-09-28 18:01:22 -0700)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/padovan/bluetooth-2.6.git master
Andrei Emeltchenko (1):
Bluetooth: fix MTU L2CAP configuration parameter
Gustavo F. Padovan (5):
Bluetooth: Simplify L2CAP Streaming mode sending
Bluetooth: Fix inconsistent lock state with RFCOMM
Revert "Bluetooth: Don't accept ConfigReq if we aren't in the BT_CONFIG state"
Bluetooth: Fix deadlock in the ERTM logic
Bluetooth: Disallow to change L2CAP_OPTIONS values when connected
Mat Martineau (1):
Bluetooth: Only enable L2CAP FCS for ERTM or streaming
include/net/bluetooth/bluetooth.h | 18 +++++++++++
net/bluetooth/l2cap.c | 62 +++++++++++++++++-------------------
net/bluetooth/rfcomm/sock.c | 4 ++
3 files changed, 51 insertions(+), 33 deletions(-)
--
Gustavo F. Padovan
ProFUSION embedded systems - http://profusion.mobi
^ permalink raw reply
* Re: New Broadcom chip in W510
From: Lu Ran @ 2010-10-05 12:59 UTC (permalink / raw)
To: Marcel Holtmann; +Cc: linux-bluetooth
[-- Attachment #1: Type: text/plain, Size: 764 bytes --]
Hi,
On Tuesday 05 October 2010 08:13:59 you wrote:
> > I put the output ot "cat /proc/bus/usb/devices" in the attachment, I am
> > pretty sure the setup of my software is OK, because now I can use my
> > bluetooth headset with an dongle, but it does not work for the internal
> > chip.
>
> maybe that hardware has some limitations that are unclear to me. Can you
> run hcidump -X -V and give us the output when trying to establish a SCO
> connection.
Here is the output of hcidump. This issue might be related to the usb code,
when I test the dongle, it gives the same error when I connect it through a
usb3 port, it only works with usb2 port, but for the internal broadcom chip,
nothing changes even when I remove the xhci_hcd module.
--
Best Regards,
LR
[-- Attachment #2: hcidump.log --]
[-- Type: text/x-log, Size: 15373 bytes --]
HCI sniffer - Bluetooth packet analyzer ver 1.42
device: hci0 snap_len: 1028 filter: 0xffffffffffffffff
> HCI Event: Connect Request (0x04) plen 10
bdaddr 00:19:7F:D8:6A:C3 class 0x200404 type ACL
< HCI Command: Accept Connection Request (0x01|0x0009) plen 7
bdaddr 00:19:7F:D8:6A:C3 role 0x00
Role: Master
> HCI Event: Command Status (0x0f) plen 4
Accept Connection Request (0x01|0x0009) status 0x00 ncmd 1
> HCI Event: Role Change (0x12) plen 8
status 0x00 bdaddr 00:19:7F:D8:6A:C3 role 0x00
Role: Master
> HCI Event: Link Key Request (0x17) plen 6
bdaddr 00:19:7F:D8:6A:C3
< HCI Command: Link Key Request Reply (0x01|0x000b) plen 22
bdaddr 00:19:7F:D8:6A:C3 key 9741E3A1976D406A2667C8926C02BDBE
> HCI Event: Command Complete (0x0e) plen 10
Link Key Request Reply (0x01|0x000b) ncmd 1
status 0x00 bdaddr 00:19:7F:D8:6A:C3
> HCI Event: Connect Complete (0x03) plen 11
status 0x00 handle 11 bdaddr 00:19:7F:D8:6A:C3 type ACL encrypt 0x01
< HCI Command: Read Remote Supported Features (0x01|0x001b) plen 2
handle 11
> HCI Event: Command Status (0x0f) plen 4
Read Remote Supported Features (0x01|0x001b) status 0x00 ncmd 1
> HCI Event: Read Remote Supported Features (0x0b) plen 11
status 0x00 handle 11
Features: 0xbc 0xe8 0x01 0x00 0x08 0x08 0x00 0x00
> ACL data: handle 11 flags 0x02 dlen 12
L2CAP(s): Connect req: psm 1 scid 0x0040
< ACL data: handle 11 flags 0x02 dlen 16
L2CAP(s): Connect rsp: dcid 0x0040 scid 0x0040 result 1 status 0
Connection pending - No futher information available
< ACL data: handle 11 flags 0x02 dlen 10
L2CAP(s): Info req: type 2
> HCI Event: Number of Completed Packets (0x13) plen 5
handle 11 packets 2
> ACL data: handle 11 flags 0x02 dlen 16
L2CAP(s): Info rsp: type 2 result 0
Extended feature mask 0x0000
< ACL data: handle 11 flags 0x02 dlen 16
L2CAP(s): Connect rsp: dcid 0x0040 scid 0x0040 result 0 status 0
Connection successful
< HCI Command: Remote Name Request (0x01|0x0019) plen 10
bdaddr 00:19:7F:D8:6A:C3 mode 2 clkoffset 0x0000
> HCI Event: Command Status (0x0f) plen 4
Remote Name Request (0x01|0x0019) status 0x00 ncmd 1
> ACL data: handle 11 flags 0x02 dlen 16
L2CAP(s): Config req: dcid 0x0040 flags 0x00 clen 4
MTU 48
< ACL data: handle 11 flags 0x02 dlen 18
L2CAP(s): Config rsp: scid 0x0040 flags 0x00 result 0 clen 4
MTU 48
< ACL data: handle 11 flags 0x02 dlen 12
L2CAP(s): Config req: dcid 0x0040 flags 0x00 clen 0
> HCI Event: Number of Completed Packets (0x13) plen 5
handle 11 packets 2
> ACL data: handle 11 flags 0x02 dlen 14
L2CAP(s): Config rsp: scid 0x0040 flags 0x00 result 0 clen 0
Success
> HCI Event: Remote Name Req Complete (0x07) plen 255
status 0x00 bdaddr 00:19:7F:D8:6A:C3 name 'ATT V521'
> ACL data: handle 11 flags 0x02 dlen 19
L2CAP(d): cid 0x0040 len 15 [psm 1]
SDP SS Req: tid 0x1 len 0xa
pat uuid-32 0x111f (Handsfree AG)
max 40
cont 00
< ACL data: handle 11 flags 0x02 dlen 18
L2CAP(d): cid 0x0040 len 14 [psm 1]
SDP SS Rsp: tid 0x1 len 0x9
count 1
handle 0x10001
cont 00
> HCI Event: Number of Completed Packets (0x13) plen 5
handle 11 packets 2
> ACL data: handle 11 flags 0x02 dlen 21
L2CAP(d): cid 0x0040 len 17 [psm 1]
SDP SA Req: tid 0x2 len 0xc
handle 0x10001
max 38
aid(s) 0x0004 (ProtocolDescList)
cont 00
< ACL data: handle 11 flags 0x02 dlen 31
L2CAP(d): cid 0x0040 len 27 [psm 1]
SDP SA Rsp: tid 0x2 len 0x16
count 19
aid 0x0004 (ProtocolDescList)
< < uuid-16 0x0100 (L2CAP) > <
uuid-16 0x0003 (RFCOMM) uint 0xd > >
cont 00
> ACL data: handle 11 flags 0x02 dlen 12
L2CAP(s): Connect req: psm 3 scid 0x0041
< ACL data: handle 11 flags 0x02 dlen 16
L2CAP(s): Connect rsp: dcid 0x0041 scid 0x0041 result 0 status 0
Connection successful
> HCI Event: Number of Completed Packets (0x13) plen 5
handle 11 packets 2
> ACL data: handle 11 flags 0x02 dlen 16
L2CAP(s): Config req: dcid 0x0041 flags 0x00 clen 4
MTU 132
< ACL data: handle 11 flags 0x02 dlen 18
L2CAP(s): Config rsp: scid 0x0041 flags 0x00 result 0 clen 4
MTU 132
< ACL data: handle 11 flags 0x02 dlen 16
L2CAP(s): Config req: dcid 0x0041 flags 0x00 clen 4
MTU 1013
> HCI Event: Number of Completed Packets (0x13) plen 5
handle 11 packets 2
> ACL data: handle 11 flags 0x02 dlen 18
L2CAP(s): Config rsp: scid 0x0041 flags 0x00 result 0 clen 4
MTU 1013
> ACL data: handle 11 flags 0x02 dlen 8
L2CAP(d): cid 0x0041 len 4 [psm 3]
RFCOMM(s): SABM: cr 1 dlci 0 pf 1 ilen 0 fcs 0x1c
< ACL data: handle 11 flags 0x02 dlen 8
L2CAP(d): cid 0x0041 len 4 [psm 3]
RFCOMM(s): UA: cr 1 dlci 0 pf 1 ilen 0 fcs 0xd7
> ACL data: handle 11 flags 0x02 dlen 18
L2CAP(d): cid 0x0041 len 14 [psm 3]
RFCOMM(s): PN CMD: cr 1 dlci 0 pf 0 ilen 10 fcs 0x70 mcc_len 8
dlci 26 frame_type 0 credit_flow 15 pri 0 ack_timer 0
frame_size 126 max_retrans 0 credits 0
< ACL data: handle 11 flags 0x02 dlen 18
L2CAP(d): cid 0x0041 len 14 [psm 3]
RFCOMM(s): PN RSP: cr 0 dlci 0 pf 0 ilen 10 fcs 0xaa mcc_len 8
dlci 26 frame_type 0 credit_flow 14 pri 0 ack_timer 0
frame_size 126 max_retrans 0 credits 7
> HCI Event: Number of Completed Packets (0x13) plen 5
handle 11 packets 2
> ACL data: handle 11 flags 0x02 dlen 8
L2CAP(d): cid 0x0041 len 4 [psm 3]
RFCOMM(s): SABM: cr 1 dlci 26 pf 1 ilen 0 fcs 0xe7
< HCI Command: Authentication Requested (0x01|0x0011) plen 2
handle 11
> HCI Event: Command Status (0x0f) plen 4
Authentication Requested (0x01|0x0011) status 0x00 ncmd 1
> HCI Event: Link Key Request (0x17) plen 6
bdaddr 00:19:7F:D8:6A:C3
< HCI Command: Link Key Request Reply (0x01|0x000b) plen 22
bdaddr 00:19:7F:D8:6A:C3 key 9741E3A1976D406A2667C8926C02BDBE
> HCI Event: Command Complete (0x0e) plen 10
Link Key Request Reply (0x01|0x000b) ncmd 1
status 0x00 bdaddr 00:19:7F:D8:6A:C3
> HCI Event: Auth Complete (0x06) plen 3
status 0x00 handle 11
< HCI Command: Set Connection Encryption (0x01|0x0013) plen 3
handle 11 encrypt 0x01
> HCI Event: Command Status (0x0f) plen 4
Set Connection Encryption (0x01|0x0013) status 0x00 ncmd 1
> HCI Event: Encrypt Change (0x08) plen 4
status 0x00 handle 11 encrypt 0x01
< ACL data: handle 11 flags 0x02 dlen 8
L2CAP(d): cid 0x0041 len 4 [psm 3]
RFCOMM(s): UA: cr 1 dlci 26 pf 1 ilen 0 fcs 0x2c
< ACL data: handle 11 flags 0x02 dlen 12
L2CAP(d): cid 0x0041 len 8 [psm 3]
RFCOMM(s): MSC CMD: cr 0 dlci 0 pf 0 ilen 4 fcs 0xaa mcc_len 2
dlci 26 fc 0 rtc 1 rtr 1 ic 0 dv 1 b1 1 b2 0 b3 0 len 9
> HCI Event: Number of Completed Packets (0x13) plen 5
handle 11 packets 2
> ACL data: handle 11 flags 0x02 dlen 12
L2CAP(d): cid 0x0041 len 8 [psm 3]
RFCOMM(s): MSC RSP: cr 1 dlci 0 pf 0 ilen 4 fcs 0x70 mcc_len 2
dlci 26 fc 0 rtc 1 rtr 1 ic 0 dv 1 b1 1 b2 0 b3 0 len 9
> ACL data: handle 11 flags 0x02 dlen 12
L2CAP(d): cid 0x0041 len 8 [psm 3]
RFCOMM(s): MSC CMD: cr 1 dlci 0 pf 0 ilen 4 fcs 0x70 mcc_len 2
dlci 26 fc 0 rtc 1 rtr 1 ic 0 dv 0 b1 1 b2 0 b3 0 len 9
< ACL data: handle 11 flags 0x02 dlen 12
L2CAP(d): cid 0x0041 len 8 [psm 3]
RFCOMM(s): MSC RSP: cr 0 dlci 0 pf 0 ilen 4 fcs 0xaa mcc_len 2
dlci 26 fc 0 rtc 1 rtr 1 ic 0 dv 0 b1 1 b2 0 b3 0 len 9
< ACL data: handle 11 flags 0x02 dlen 9
L2CAP(d): cid 0x0041 len 5 [psm 3]
RFCOMM(d): UIH: cr 0 dlci 26 pf 1 ilen 0 fcs 0x22 credits 33
> ACL data: handle 11 flags 0x02 dlen 9
L2CAP(d): cid 0x0041 len 5 [psm 3]
RFCOMM(d): UIH: cr 1 dlci 26 pf 1 ilen 0 fcs 0xf8 credits 15
> HCI Event: Number of Completed Packets (0x13) plen 5
handle 11 packets 2
> ACL data: handle 11 flags 0x02 dlen 12
L2CAP(s): Disconn req: dcid 0x0040 scid 0x0040
< ACL data: handle 11 flags 0x02 dlen 12
L2CAP(s): Disconn rsp: dcid 0x0040 scid 0x0040
> HCI Event: Number of Completed Packets (0x13) plen 5
handle 11 packets 1
> ACL data: handle 11 flags 0x02 dlen 19
L2CAP(d): cid 0x0041 len 15 [psm 3]
RFCOMM(d): UIH: cr 1 dlci 26 pf 0 ilen 11 fcs 0xe4
0000: 41 54 2b 42 52 53 46 3d 32 34 0d AT+BRSF=24.
< ACL data: handle 11 flags 0x02 dlen 22
L2CAP(d): cid 0x0041 len 18 [psm 3]
RFCOMM(d): UIH: cr 0 dlci 26 pf 0 ilen 14 fcs 0x3e
0000: 0d 0a 2b 42 52 53 46 3a 20 33 35 32 0d 0a ..+BRSF: 352..
< ACL data: handle 11 flags 0x02 dlen 14
L2CAP(d): cid 0x0041 len 10 [psm 3]
RFCOMM(d): UIH: cr 0 dlci 26 pf 0 ilen 6 fcs 0x3e
0000: 0d 0a 4f 4b 0d 0a ..OK..
> HCI Event: Number of Completed Packets (0x13) plen 5
handle 11 packets 2
> ACL data: handle 11 flags 0x02 dlen 19
L2CAP(d): cid 0x0041 len 15 [psm 3]
RFCOMM(d): UIH: cr 1 dlci 26 pf 1 ilen 10 fcs 0xf8 credits 2
0000: 41 54 2b 43 49 4e 44 3d 3f 0d AT+CIND=?.
< ACL data: handle 11 flags 0x02 dlen 134
L2CAP(d): cid 0x0041 len 130 [psm 3]
RFCOMM(d): UIH: cr 0 dlci 26 pf 0 ilen 126 fcs 0x3e
0000: 0d 0a 2b 43 49 4e 44 3a 20 28 22 62 61 74 74 63 ..+CIND: ("battc
0010: 68 67 22 2c 28 30 2d 35 29 29 2c 28 22 73 69 67 hg",(0-5)),("sig
0020: 6e 61 6c 22 2c 28 30 2d 35 29 29 2c 28 22 73 65 nal",(0-5)),("se
0030: 72 76 69 63 65 22 2c 28 30 2c 31 29 29 2c 28 22 rvice",(0,1)),("
0040: 63 61 6c 6c 22 2c 28 30 2c 31 29 29 2c 28 22 63 call",(0,1)),("c
0050: 61 6c 6c 73 65 74 75 70 22 2c 28 30 2d 33 29 29 allsetup",(0-3))
0060: 2c 28 22 63 61 6c 6c 68 65 6c 64 22 2c 28 30 2d ,("callheld",(0-
0070: 32 29 29 2c 28 22 72 6f 61 6d 22 2c 28 30 2)),("roam",(0
< ACL data: handle 11 flags 0x02 dlen 14
L2CAP(d): cid 0x0041 len 10 [psm 3]
RFCOMM(d): UIH: cr 0 dlci 26 pf 0 ilen 6 fcs 0x3e
0000: 2c 31 29 29 0d 0a ,1))..
< ACL data: handle 11 flags 0x02 dlen 14
L2CAP(d): cid 0x0041 len 10 [psm 3]
RFCOMM(d): UIH: cr 0 dlci 26 pf 0 ilen 6 fcs 0x3e
0000: 0d 0a 4f 4b 0d 0a ..OK..
> HCI Event: Number of Completed Packets (0x13) plen 5
handle 11 packets 2
> HCI Event: Number of Completed Packets (0x13) plen 5
handle 11 packets 1
> ACL data: handle 11 flags 0x02 dlen 18
L2CAP(d): cid 0x0041 len 14 [psm 3]
RFCOMM(d): UIH: cr 1 dlci 26 pf 1 ilen 9 fcs 0xf8 credits 2
0000: 41 54 2b 43 49 4e 44 3f 0d AT+CIND?.
< ACL data: handle 11 flags 0x02 dlen 32
L2CAP(d): cid 0x0041 len 28 [psm 3]
RFCOMM(d): UIH: cr 0 dlci 26 pf 0 ilen 24 fcs 0x3e
0000: 0d 0a 2b 43 49 4e 44 3a 20 35 2c 35 2c 31 2c 30 ..+CIND: 5,5,1,0
0010: 2c 30 2c 30 2c 30 0d 0a ,0,0,0..
< ACL data: handle 11 flags 0x02 dlen 14
L2CAP(d): cid 0x0041 len 10 [psm 3]
RFCOMM(d): UIH: cr 0 dlci 26 pf 0 ilen 6 fcs 0x3e
0000: 0d 0a 4f 4b 0d 0a ..OK..
> HCI Event: Number of Completed Packets (0x13) plen 5
handle 11 packets 2
> ACL data: handle 11 flags 0x02 dlen 27
> ACL data: handle 11 flags 0x01 dlen 1
L2CAP(d): cid 0x0041 len 24 [psm 3]
RFCOMM(d): UIH: cr 1 dlci 26 pf 1 ilen 19 fcs 0xf8 credits 2
0000: 41 54 2b 43 4d 45 52 3d 33 2c 20 30 2c 20 30 2c AT+CMER=3, 0, 0,
0010: 20 31 0d 1.
< ACL data: handle 11 flags 0x02 dlen 14
L2CAP(d): cid 0x0041 len 10 [psm 3]
RFCOMM(d): UIH: cr 0 dlci 26 pf 0 ilen 6 fcs 0x3e
0000: 0d 0a 4f 4b 0d 0a ..OK..
> HCI Event: Number of Completed Packets (0x13) plen 5
handle 11 packets 1
> ACL data: handle 11 flags 0x02 dlen 19
L2CAP(d): cid 0x0041 len 15 [psm 3]
RFCOMM(d): UIH: cr 1 dlci 26 pf 1 ilen 10 fcs 0xf8 credits 2
0000: 41 54 2b 56 47 53 3d 31 35 0d AT+VGS=15.
< ACL data: handle 11 flags 0x02 dlen 14
L2CAP(d): cid 0x0041 len 10 [psm 3]
RFCOMM(d): UIH: cr 0 dlci 26 pf 0 ilen 6 fcs 0x3e
0000: 0d 0a 4f 4b 0d 0a ..OK..
> HCI Event: Number of Completed Packets (0x13) plen 5
handle 11 packets 1
> HCI Event: Encrypt Change (0x08) plen 4
status 0x00 handle 11 encrypt 0x00
> HCI Event: Role Change (0x12) plen 8
status 0x00 bdaddr 00:19:7F:D8:6A:C3 role 0x01
Role: Slave
> HCI Event: Encrypt Change (0x08) plen 4
status 0x00 handle 11 encrypt 0x01
< HCI Command: Setup Synchronous Connection (0x01|0x0028) plen 17
handle 11 voice setting 0x0060
> HCI Event: Command Status (0x0f) plen 4
Setup Synchronous Connection (0x01|0x0028) status 0x00 ncmd 1
> HCI Event: Synchronous Connect Complete (0x2c) plen 17
status 0x00 handle 1 bdaddr 00:19:7F:D8:6A:C3 type SCO
Air mode: CVSD
< ACL data: handle 11 flags 0x02 dlen 19
L2CAP(d): cid 0x0041 len 15 [psm 3]
RFCOMM(d): UIH: cr 0 dlci 26 pf 0 ilen 11 fcs 0x3e
0000: 0d 0a 2b 56 47 53 3d 31 35 0d 0a ..+VGS=15..
< ACL data: handle 11 flags 0x02 dlen 18
L2CAP(d): cid 0x0041 len 14 [psm 3]
RFCOMM(d): UIH: cr 0 dlci 26 pf 0 ilen 10 fcs 0x3e
0000: 0d 0a 2b 56 47 4d 3d 30 0d 0a ..+VGM=0..
< SCO data: handle 1 flags 0x00 dlen 48
0000: 07 00 fb ff 04 00 fa ff 01 00 fb ff 04 00 fb ff ................
0010: 02 00 fb ff 05 00 fa ff 03 00 fd ff 02 00 fc ff ................
0020: 03 00 fb ff 05 00 fa ff 05 00 fa ff 06 00 fa ff ................
< SCO data: handle 1 flags 0x00 dlen 48
0000: 04 00 fc ff 05 00 f9 ff 07 00 fb ff 05 00 fc ff ................
0010: 05 00 fc ff 07 00 f7 ff 08 00 fd ff 06 00 fb ff ................
0020: 07 00 f8 ff 07 00 f9 ff 09 00 f8 ff 07 00 fa ff ................
< SCO data: handle 1 flags 0x00 dlen 48
0000: 09 00 f9 ff 06 00 f6 ff 0b 00 fa ff 07 00 f6 ff ................
0010: 09 00 f4 ff 07 00 f7 ff 0b 00 f4 ff 0b 00 f5 ff ................
0020: 0a 00 f1 ff 0e 00 f4 ff 0f 00 f6 ff 11 00 f2 ff ................
< SCO data: handle 1 flags 0x00 dlen 48
0000: 13 00 f1 ff 17 00 eb ff 1e 00 eb ff 25 00 d9 ff ............%...
0010: 52 00 b4 00 1e 01 43 00 a8 ff 1d fe 53 01 76 ff R.....C.....S.v.
0020: 37 fe e4 00 a7 fd bb 00 4e ff 4a 01 8b ff 93 01 7.......N.J.....
< SCO data: handle 1 flags 0x00 dlen 48
0000: fa fc 73 ff 04 05 cd 00 27 fc 25 ff 03 01 d9 00 ..s.....'.%.....
0010: cb 03 c0 00 1b fe 83 ff 5b ff d4 fc 12 03 53 fe ........[.....S.
0020: 30 fd c9 fd 40 04 d0 01 95 02 e0 fa 53 00 63 04 0...@.......S.c.
< SCO data: handle 1 flags 0x00 dlen 48
0000: 81 d5 87 d9 a4 de 31 e5 5a eb 2e f2 2d fa b5 01 ......1.Z...-...
0010: 68 08 b4 0f ae 16 01 1c c0 20 f3 24 16 27 a9 27 h........ .$.'.'
0020: 25 28 0f 27 0e 23 98 1e c1 19 14 13 83 0b 05 04 %(.'.#..........
< HCI Command: Disconnect (0x01|0x0006) plen 3
handle 1 reason 0x13
Reason: Remote User Terminated Connection
> HCI Event: Command Status (0x0f) plen 4
Disconnect (0x01|0x0006) status 0x00 ncmd 1
> HCI Event: Disconn Complete (0x05) plen 4
status 0x00 handle 1 reason 0x16
Reason: Connection Terminated by Local Host
^ permalink raw reply
* Re: Sim Access profile server implementation
From: Suraj Sumangala @ 2010-10-05 12:46 UTC (permalink / raw)
To: Marcel Holtmann
Cc: Waldemar.Rymarkiewicz@tieto.com, Suraj Sumangala,
linux-bluetooth@vger.kernel.org, Jothikumar Mothilal,
joakim.xj.ceder@stericsson.com
In-Reply-To: <1286280767.17473.89.camel@aeonflux>
Hi Waldemar,
On 10/5/2010 5:42 PM, Marcel Holtmann wrote:
> Hi Waldemar,
>
> please no top posting on this mailing list.
>
>> I understand you concerns about dbus reliability and I agree with you , but I guess we should find a compromise solution as ofono is not used widely in Linux mobile platforms nowadays.
>>
>> I my view, combination of a bluez plugin for sap and a platform dependend sim driver is a reliable and most available solution so far. The SAP plugin implements BT SAP spec and require simple API (connect, disconnect, apdu, atr, status) which is implemented in SIM driver for a certain platform. This way it's relatively easy to support SAP in different platforms. Ofono can have its own driver as well.
>>
>> What's you view on such design?
>> Can we also have a double solution one in ofono for ofono aware platforms and the second as a plugin for others?
>
> I am fine with starting this in BlueZ and see how far we get. And yes,
> plugin based is a must from my point of view. It is most likely similar
> to our different telephony drivers for Handsfree support.
>
> We will move strongly in the direction of oFono being the main telephony
> stack. So I do care mostly that this work in conjunction with oFono.
> Everything else is just a nice benefit if it doesn't clutter the
> overhaul implementation and requires pointless abstraction everywhere.
>
>> BTW, I already have this implemented and tested with real hardware (STEricsson). Bluez SAP works fine with Nokia 616 carkit :)
>
> Can you share that code with us. And also hardware if you. We are still
> having hard time to find proper hardware to test this on.
>
> Regards
>
> Marcel
>
>
Do let me know if you had to make some changes in the SAP implementation
for it to work.
It will be great if you can share the code in that case. I can update my
implementation accordingly.
Regards
Suraj
^ permalink raw reply
* Re: New Broadcom chip in W510
From: Marcel Holtmann @ 2010-10-05 12:13 UTC (permalink / raw)
To: Lu Ran; +Cc: linux-bluetooth
In-Reply-To: <201010050754.18704.hephooey@gmail.com>
Hi Lu,
> > can you show me the content of /proc/bus/usb/devices (or usbdevices.sh)
> > for that device.
>
> I put the output ot "cat /proc/bus/usb/devices" in the attachment, I am pretty
> sure the setup of my software is OK, because now I can use my bluetooth
> headset with an dongle, but it does not work for the internal chip.
maybe that hardware has some limitations that are unclear to me. Can you
run hcidump -X -V and give us the output when trying to establish a SCO
connection.
Regards
Marcel
^ permalink raw reply
* RE: Sim Access profile server implementation
From: Marcel Holtmann @ 2010-10-05 12:12 UTC (permalink / raw)
To: Waldemar.Rymarkiewicz
Cc: suraj, linux-bluetooth, Jothikumar.Mothilal, joakim.xj.ceder
In-Reply-To: <99B09243E1A5DA4898CDD8B700111448097D01B371@EXMB04.eu.tieto.com>
Hi Waldemar,
please no top posting on this mailing list.
> I understand you concerns about dbus reliability and I agree with you , but I guess we should find a compromise solution as ofono is not used widely in Linux mobile platforms nowadays.
>
> I my view, combination of a bluez plugin for sap and a platform dependend sim driver is a reliable and most available solution so far. The SAP plugin implements BT SAP spec and require simple API (connect, disconnect, apdu, atr, status) which is implemented in SIM driver for a certain platform. This way it's relatively easy to support SAP in different platforms. Ofono can have its own driver as well.
>
> What's you view on such design?
> Can we also have a double solution one in ofono for ofono aware platforms and the second as a plugin for others?
I am fine with starting this in BlueZ and see how far we get. And yes,
plugin based is a must from my point of view. It is most likely similar
to our different telephony drivers for Handsfree support.
We will move strongly in the direction of oFono being the main telephony
stack. So I do care mostly that this work in conjunction with oFono.
Everything else is just a nice benefit if it doesn't clutter the
overhaul implementation and requires pointless abstraction everywhere.
> BTW, I already have this implemented and tested with real hardware (STEricsson). Bluez SAP works fine with Nokia 616 carkit :)
Can you share that code with us. And also hardware if you. We are still
having hard time to find proper hardware to test this on.
Regards
Marcel
^ permalink raw reply
* Re: New Broadcom chip in W510
From: Lu Ran @ 2010-10-05 11:54 UTC (permalink / raw)
To: Marcel Holtmann; +Cc: linux-bluetooth
In-Reply-To: <1286271048.17473.66.camel@aeonflux>
[-- Attachment #1: Type: Text/Plain, Size: 407 bytes --]
Hi Marcel,
On Tuesday 05 October 2010 05:30:48 Marcel Holtmann wrote:
> can you show me the content of /proc/bus/usb/devices (or usbdevices.sh)
> for that device.
I put the output ot "cat /proc/bus/usb/devices" in the attachment, I am pretty
sure the setup of my software is OK, because now I can use my bluetooth
headset with an dongle, but it does not work for the internal chip.
--
Best Regards,
LR
[-- Attachment #2: devices.log --]
[-- Type: text/x-log, Size: 5754 bytes --]
T: Bus=03 Lev=00 Prnt=00 Port=00 Cnt=00 Dev#= 1 Spd=?? MxCh= 4
B: Alloc= 0/900 us ( 0%), #Int= 0, #Iso= 0
D: Ver= 3.00 Cls=09(hub ) Sub=00 Prot=03 MxPS= 9 #Cfgs= 1
P: Vendor=1d6b ProdID=0003 Rev= 2.06
S: Manufacturer=Linux 2.6.35.6 xhci_hcd
S: Product=xHCI Host Controller
S: SerialNumber=0000:0f:00.0
C:* #Ifs= 1 Cfg#= 1 Atr=e0 MxPwr= 0mA
I:* If#= 0 Alt= 0 #EPs= 1 Cls=09(hub ) Sub=00 Prot=00 Driver=hub
E: Ad=81(I) Atr=03(Int.) MxPS= 4 Ivl=12ms
T: Bus=02 Lev=00 Prnt=00 Port=00 Cnt=00 Dev#= 1 Spd=480 MxCh= 3
B: Alloc= 0/800 us ( 0%), #Int= 1, #Iso= 0
D: Ver= 2.00 Cls=09(hub ) Sub=00 Prot=00 MxPS=64 #Cfgs= 1
P: Vendor=1d6b ProdID=0002 Rev= 2.06
S: Manufacturer=Linux 2.6.35.6 ehci_hcd
S: Product=EHCI Host Controller
S: SerialNumber=0000:00:1d.0
C:* #Ifs= 1 Cfg#= 1 Atr=e0 MxPwr= 0mA
I:* If#= 0 Alt= 0 #EPs= 1 Cls=09(hub ) Sub=00 Prot=00 Driver=hub
E: Ad=81(I) Atr=03(Int.) MxPS= 4 Ivl=256ms
T: Bus=02 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#= 2 Spd=480 MxCh= 8
D: Ver= 2.00 Cls=09(hub ) Sub=00 Prot=01 MxPS=64 #Cfgs= 1
P: Vendor=8087 ProdID=0020 Rev= 0.00
C:* #Ifs= 1 Cfg#= 1 Atr=e0 MxPwr= 0mA
I:* If#= 0 Alt= 0 #EPs= 1 Cls=09(hub ) Sub=00 Prot=00 Driver=hub
E: Ad=81(I) Atr=03(Int.) MxPS= 2 Ivl=256ms
T: Bus=01 Lev=00 Prnt=00 Port=00 Cnt=00 Dev#= 1 Spd=480 MxCh= 3
B: Alloc= 4/800 us ( 1%), #Int= 4, #Iso= 0
D: Ver= 2.00 Cls=09(hub ) Sub=00 Prot=00 MxPS=64 #Cfgs= 1
P: Vendor=1d6b ProdID=0002 Rev= 2.06
S: Manufacturer=Linux 2.6.35.6 ehci_hcd
S: Product=EHCI Host Controller
S: SerialNumber=0000:00:1a.0
C:* #Ifs= 1 Cfg#= 1 Atr=e0 MxPwr= 0mA
I:* If#= 0 Alt= 0 #EPs= 1 Cls=09(hub ) Sub=00 Prot=00 Driver=hub
E: Ad=81(I) Atr=03(Int.) MxPS= 4 Ivl=256ms
T: Bus=01 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#= 2 Spd=480 MxCh= 6
D: Ver= 2.00 Cls=09(hub ) Sub=00 Prot=01 MxPS=64 #Cfgs= 1
P: Vendor=8087 ProdID=0020 Rev= 0.00
C:* #Ifs= 1 Cfg#= 1 Atr=e0 MxPwr= 0mA
I:* If#= 0 Alt= 0 #EPs= 1 Cls=09(hub ) Sub=00 Prot=00 Driver=hub
E: Ad=81(I) Atr=03(Int.) MxPS= 1 Ivl=256ms
T: Bus=01 Lev=02 Prnt=02 Port=01 Cnt=01 Dev#= 3 Spd=12 MxCh= 0
D: Ver= 2.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS= 8 #Cfgs= 1
P: Vendor=046d ProdID=c52b Rev=12.01
S: Manufacturer=Logitech
S: Product=USB Receiver
C:* #Ifs= 3 Cfg#= 1 Atr=a0 MxPwr= 98mA
I:* If#= 0 Alt= 0 #EPs= 1 Cls=03(HID ) Sub=01 Prot=01 Driver=usbhid
E: Ad=81(I) Atr=03(Int.) MxPS= 8 Ivl=8ms
I:* If#= 1 Alt= 0 #EPs= 1 Cls=03(HID ) Sub=01 Prot=02 Driver=usbhid
E: Ad=82(I) Atr=03(Int.) MxPS= 8 Ivl=2ms
I:* If#= 2 Alt= 0 #EPs= 1 Cls=03(HID ) Sub=00 Prot=00 Driver=usbhid
E: Ad=83(I) Atr=03(Int.) MxPS= 32 Ivl=2ms
T: Bus=01 Lev=02 Prnt=02 Port=02 Cnt=02 Dev#= 4 Spd=12 MxCh= 0
D: Ver= 1.01 Cls=00(>ifc ) Sub=00 Prot=00 MxPS= 8 #Cfgs= 1
P: Vendor=147e ProdID=2016 Rev= 0.02
S: Manufacturer=UPEK
S: Product=Biometric Coprocessor
C:* #Ifs= 1 Cfg#= 1 Atr=a0 MxPwr=100mA
I:* If#= 0 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=(none)
E: Ad=81(I) Atr=02(Bulk) MxPS= 64 Ivl=0ms
E: Ad=02(O) Atr=02(Bulk) MxPS= 64 Ivl=0ms
E: Ad=83(I) Atr=03(Int.) MxPS= 4 Ivl=20ms
T: Bus=01 Lev=02 Prnt=02 Port=03 Cnt=03 Dev#= 17 Spd=12 MxCh= 0
D: Ver= 2.00 Cls=e0(wlcon) Sub=01 Prot=01 MxPS=64 #Cfgs= 1
P: Vendor=0a5c ProdID=217f Rev= 3.60
S: Manufacturer=Broadcom Corp
S: Product=Broadcom Bluetooth Device
S: SerialNumber=70F395342F29
C:* #Ifs= 4 Cfg#= 1 Atr=e0 MxPwr= 0mA
I:* If#= 0 Alt= 0 #EPs= 3 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E: Ad=81(I) Atr=03(Int.) MxPS= 16 Ivl=1ms
E: Ad=82(I) Atr=02(Bulk) MxPS= 64 Ivl=0ms
E: Ad=02(O) Atr=02(Bulk) MxPS= 64 Ivl=0ms
I:* If#= 1 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E: Ad=83(I) Atr=01(Isoc) MxPS= 0 Ivl=1ms
E: Ad=03(O) Atr=01(Isoc) MxPS= 0 Ivl=1ms
I: If#= 1 Alt= 1 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E: Ad=83(I) Atr=01(Isoc) MxPS= 9 Ivl=1ms
E: Ad=03(O) Atr=01(Isoc) MxPS= 9 Ivl=1ms
I: If#= 1 Alt= 2 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E: Ad=83(I) Atr=01(Isoc) MxPS= 17 Ivl=1ms
E: Ad=03(O) Atr=01(Isoc) MxPS= 17 Ivl=1ms
I: If#= 1 Alt= 3 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E: Ad=83(I) Atr=01(Isoc) MxPS= 32 Ivl=1ms
E: Ad=03(O) Atr=01(Isoc) MxPS= 32 Ivl=1ms
I: If#= 1 Alt= 4 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E: Ad=83(I) Atr=01(Isoc) MxPS= 64 Ivl=1ms
E: Ad=03(O) Atr=01(Isoc) MxPS= 64 Ivl=1ms
I: If#= 1 Alt= 5 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E: Ad=83(I) Atr=01(Isoc) MxPS= 64 Ivl=1ms
E: Ad=03(O) Atr=01(Isoc) MxPS= 64 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)
T: Bus=01 Lev=02 Prnt=02 Port=05 Cnt=04 Dev#= 6 Spd=480 MxCh= 0
D: Ver= 2.00 Cls=ef(misc ) Sub=02 Prot=01 MxPS=64 #Cfgs= 1
P: Vendor=17ef ProdID=480f Rev=23.45
S: Manufacturer=Chicony Electronics Co., Ltd.
S: Product=Integrated Camera
C:* #Ifs= 2 Cfg#= 1 Atr=80 MxPwr=200mA
A: FirstIf#= 0 IfCount= 2 Cls=0e(video) Sub=03 Prot=00
I:* If#= 0 Alt= 0 #EPs= 1 Cls=0e(video) Sub=01 Prot=00 Driver=uvcvideo
E: Ad=81(I) Atr=03(Int.) MxPS= 16 Ivl=16ms
I:* If#= 1 Alt= 0 #EPs= 0 Cls=0e(video) Sub=02 Prot=00 Driver=uvcvideo
I: If#= 1 Alt= 1 #EPs= 1 Cls=0e(video) Sub=02 Prot=00 Driver=uvcvideo
E: Ad=82(I) Atr=05(Isoc) MxPS=1936 Ivl=125us
I: If#= 1 Alt= 2 #EPs= 1 Cls=0e(video) Sub=02 Prot=00 Driver=uvcvideo
E: Ad=82(I) Atr=05(Isoc) MxPS=3012 Ivl=125us
I: If#= 1 Alt= 3 #EPs= 1 Cls=0e(video) Sub=02 Prot=00 Driver=uvcvideo
E: Ad=82(I) Atr=05(Isoc) MxPS=3060 Ivl=125us
I: If#= 1 Alt= 4 #EPs= 1 Cls=0e(video) Sub=02 Prot=00 Driver=uvcvideo
E: Ad=82(I) Atr=05(Isoc) MxPS=3072 Ivl=125us
^ permalink raw reply
* RE: Sim Access profile server implementation
From: Waldemar.Rymarkiewicz @ 2010-10-05 10:45 UTC (permalink / raw)
To: marcel, suraj; +Cc: linux-bluetooth, Jothikumar.Mothilal, joakim.xj.ceder
In-Reply-To: <1286265730.17473.29.camel@aeonflux>
Hi Marcel,
I understand you concerns about dbus reliability and I agree with you , but I guess we should find a compromise solution as ofono is not used widely in Linux mobile platforms nowadays.
I my view, combination of a bluez plugin for sap and a platform dependend sim driver is a reliable and most available solution so far. The SAP plugin implements BT SAP spec and require simple API (connect, disconnect, apdu, atr, status) which is implemented in SIM driver for a certain platform. This way it's relatively easy to support SAP in different platforms. Ofono can have its own driver as well.
What's you view on such design?
Can we also have a double solution one in ofono for ofono aware platforms and the second as a plugin for others?
BTW, I already have this implemented and tested with real hardware (STEricsson). Bluez SAP works fine with Nokia 616 carkit :)
Regards,
/Waldek
>-----Original Message-----
>From: linux-bluetooth-owner@vger.kernel.org
>[mailto:linux-bluetooth-owner@vger.kernel.org] On Behalf Of
>Marcel Holtmann
>Sent: Tuesday, October 05, 2010 10:02 AM
>To: suraj
>Cc: linux-bluetooth@vger.kernel.org; Jothikumar Mothilal
>Subject: Re: Sim Access profile server implementation
>
>Hi Suraj,
>
>> Please find the Git tree for the Sim access profile server role
>> implementation I have been working on at
>>
>> git://gitorious.org/sap-server/sap-server.git
>>
>> Not sure it could be directly used with Bluez. Nevertheless, it has
>> the parser implementation of Bluetooth SAP packet. Someone could
>> possibly reuse it in their implementation.
>
>have you actually tested this with real SAP server capable
>hardware? I am still not convinced at all to push APDU over
>D-Bus. First, there is potential security issue here and
>second the latency that D-Bus introduces seems not be
>acceptable. So what I am getting it, can this be actually used
>in a product that seriously wants to support SAP server?
>
>Regards
>
>Marcel
>
>
>--
>To unsubscribe from this list: send the line "unsubscribe
>linux-bluetooth" in the body of a message to
>majordomo@vger.kernel.org More majordomo info at
>http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply
* Re: New Broadcom chip in W510
From: Marcel Holtmann @ 2010-10-05 9:30 UTC (permalink / raw)
To: Lu Ran; +Cc: linux-bluetooth
In-Reply-To: <201009190926.51131.hephooey@gmail.com>
Hi Lu,
> I am having trouble to make my headset work in my new W510, it works fine in an
> T61, with has almost identical software and setup with the new W510. The only
> difference is I am now using a pure 64 bit system, while the old T61 is a 32
> bit one, and the bluetooth chip is different. the id of the chip in T61 is
> 0A5C:2110, while W510 has a chip from Broadcom with id 0A5C:217F. I noticed
> there is a SCO fix for 0A5C:2110 in btusb.c. I tried to copy the line and
> change the id to 0A5C:217F, but nothing changes. The headset can pair with the
> laptop with no problem, but there seems to be no data transmition. And I get a
> lot error messages in dmesg output like this:
>
> btusb_submit_isoc_urb: hci0 urb ffff880060136e00 submission failed (28)
>
> and
>
> btusb_send_frame: hci0 urb ffff8801320e1a00 submission failed
>
> the output of "hciconfig hci0 version" is
>
> hci0: Type: BR/EDR Bus: USB
> BD Address: 70:F3:95:34:2F:29 ACL MTU: 1021:8 SCO MTU: 64:8
> HCI Version: 2.1 (0x4) Revision: 0x168
> LMP Version: 2.1 (0x4) Subversion: 0x4203
> Manufacturer: Broadcom Corporation (15)
>
> And the output of "lsusb -v" is in the attachment. I will try to provide any
> other information you need to analyse the problem.
can you show me the content of /proc/bus/usb/devices (or usbdevices.sh)
for that device.
Regards
Marcel
^ permalink raw reply
* Re: [PATCH 1/2] Bluetooth: hci open callback for hci UART transport driver
From: Marcel Holtmann @ 2010-10-05 9:27 UTC (permalink / raw)
To: Suraj Sumangala; +Cc: linux-bluetooth, Jothikumar.Mothilal
In-Reply-To: <1285075981-8941-1-git-send-email-suraj@atheros.com>
Hi Suraj,
> This patch provides option for hci transport driver protocol implementation
> to have a callback for hci open.
>
> Signed-off-by: Suraj Sumangala <suraj@atheros.com>
> ---
> drivers/bluetooth/hci_ldisc.c | 5 ++++-
> drivers/bluetooth/hci_uart.h | 1 +
> 2 files changed, 5 insertions(+), 1 deletions(-)
>
> diff --git a/drivers/bluetooth/hci_ldisc.c b/drivers/bluetooth/hci_ldisc.c
> index 998833d..5e02501 100644
> --- a/drivers/bluetooth/hci_ldisc.c
> +++ b/drivers/bluetooth/hci_ldisc.c
> @@ -162,9 +162,12 @@ restart:
> /* Initialize device */
> static int hci_uart_open(struct hci_dev *hdev)
> {
> + struct hci_uart *hu = (struct hci_uart *) hdev->driver_data;
> +
> BT_DBG("%s %p", hdev->name, hdev);
>
> - /* Nothing to do for UART driver */
> + if (hu->proto->hci_open)
> + hu->proto->hci_open(hu);
>
> set_bit(HCI_RUNNING, &hdev->flags);
>
> diff --git a/drivers/bluetooth/hci_uart.h b/drivers/bluetooth/hci_uart.h
> index 99fb352..d0198ec 100644
> --- a/drivers/bluetooth/hci_uart.h
> +++ b/drivers/bluetooth/hci_uart.h
> @@ -51,6 +51,7 @@ struct hci_uart;
> struct hci_uart_proto {
> unsigned int id;
> int (*open)(struct hci_uart *hu);
> + int (*hci_open)(struct hci_uart *hu);
> int (*close)(struct hci_uart *hu);
> int (*flush)(struct hci_uart *hu);
> int (*recv)(struct hci_uart *hu, void *data, int len);
I don't like this. It is not what any other driver is doing. For me this
is just hacking around something that would need to be solved for all
Bluetooth transport drivers. Just trying to solve this for UART based
drivers is not going to help.
So we talked about adding a setup stage to the HCI driver interface.
That is the way you should proceed if doing this in hciattach is not
enough for you.
Regards
Marcel
^ permalink raw reply
* Re: Support for Device ID profile
From: Marcel Holtmann @ 2010-10-05 9:22 UTC (permalink / raw)
To: Rahul Ruikar
Cc: steven bluez, Jose Antonio Santos Cadenas, Luiz Augusto von Dentz,
linux-bluetooth
In-Reply-To: <AANLkTi=pFRQHOvTXSUuWSCEDxbL+4ET9JFJct6BWK2Lh@mail.gmail.com>
Hi Rahul/Luiz,
> Could you please tell me some pointers in code/document where I can
> know about various profiles
> we support here or about profiles for which support is not added yet.
>
> I would like to contribute towards adding support of profiles.
> http://www.bluetooth.com/English/Technology/Works/Pages/Profiles_Overview.aspx
clear warning here guys. STOP top posting.
Regards
Marcel
^ permalink raw reply
* Re: [PATCH 6/6] This patch adds support for using the ST-Ericsson CG2900
From: Marcel Holtmann @ 2010-10-05 9:20 UTC (permalink / raw)
To: pghatwork; +Cc: linux-bluetooth, linux-kernel, linus.walleij, Pavan Savoy
In-Reply-To: <AANLkTimOai9_92VuJUZMo26es9Wsu_6d+z36Sv_Q4i+L@mail.gmail.com>
Hi Par-Gunnar,
> This patch adds support for using the ST-Ericsson CG2900
> connectivity controller as a driver for the BlueZ Bluetooth
> stack.
> This patch registers as a driver into the BlueZ framework and, when
> opened by BlueZ, it registers as user for bt_cmd, bt_acl, and bt_evt
> channels.
>
> Signed-off-by: Par-Gunnar Hjalmdahl <par-gunnar.p.hjalmdahl@stericsson.com>
> ---
> drivers/bluetooth/Kconfig | 7 +
> drivers/bluetooth/Makefile | 2 +
> drivers/bluetooth/cg2900_hci.c | 896 ++++++++++++++++++++++++++++++++++++++++
> 3 files changed, 905 insertions(+), 0 deletions(-)
> create mode 100644 drivers/bluetooth/cg2900_hci.c
>
> diff --git a/drivers/bluetooth/Kconfig b/drivers/bluetooth/Kconfig
> index 02deef4..9ca8d69 100644
> --- a/drivers/bluetooth/Kconfig
> +++ b/drivers/bluetooth/Kconfig
> @@ -219,4 +219,11 @@ config BT_ATH3K
> Say Y here to compile support for "Atheros firmware download driver"
> into the kernel or say M to compile it as module (ath3k).
>
> +config BT_CG2900
> + tristate "ST-Ericsson CG2900 driver"
> + depends on MFD_CG2900 && BT
> + help
> + Select if ST-Ericsson CG2900 Connectivity controller shall be used as
> + Bluetooth controller for BlueZ.
> +
> endmenu
> diff --git a/drivers/bluetooth/Makefile b/drivers/bluetooth/Makefile
> index 71bdf13..a479c16 100644
> --- a/drivers/bluetooth/Makefile
> +++ b/drivers/bluetooth/Makefile
> @@ -19,6 +19,8 @@ obj-$(CONFIG_BT_ATH3K) += ath3k.o
> obj-$(CONFIG_BT_MRVL) += btmrvl.o
> obj-$(CONFIG_BT_MRVL_SDIO) += btmrvl_sdio.o
>
> +obj-$(CONFIG_BT_CG2900) += cg2900_hci.o
> +
Please sort this after ath3k and before btmvrl config.
And for the name either just use cg2900 if it uniquely identifies the
Bluetooth chip used in the combo or use btcg2900.o as module name if it
is the name of the combo module.
We clearly moved into the direction of either unique hardware names
without bt prefix or we have the bt prefix in front of it. The fully
generic term hci will be phased out of the driver names.
> btmrvl-y := btmrvl_main.o
> btmrvl-$(CONFIG_DEBUG_FS) += btmrvl_debugfs.o
>
> diff --git a/drivers/bluetooth/cg2900_hci.c b/drivers/bluetooth/cg2900_hci.c
> new file mode 100644
> index 0000000..de1ada8
> --- /dev/null
> +++ b/drivers/bluetooth/cg2900_hci.c
> @@ -0,0 +1,896 @@
> +/*
> + * drivers/bluetooth/cg2900_hci.c
> + *
> + * Copyright (C) ST-Ericsson SA 2010
> + * Authors:
> + * Par-Gunnar Hjalmdahl (par-gunnar.p.hjalmdahl@stericsson.com) for
> ST-Ericsson.
> + * Henrik Possung (henrik.possung@stericsson.com) for ST-Ericsson.
> + * Josef Kindberg (josef.kindberg@stericsson.com) for ST-Ericsson.
> + * Dariusz Szymszak (dariusz.xd.szymczak@stericsson.com) for ST-Ericsson.
> + * Kjell Andersson (kjell.k.andersson@stericsson.com) for ST-Ericsson.
> + * License terms: GNU General Public License (GPL), version 2
> + *
> + * Linux Bluetooth HCI H:4 Driver for ST-Ericsson CG2900 connectivity
> controller
> + * towards the BlueZ Bluetooth stack.
> + */
Drop the filename in this header and don't bother with the description
towards BlueZ or Bluetooth subsystem. That is clear from the location of
the file.
Also what is up with the "for ST-Ericsson"?
> +
> +#include <linux/module.h>
> +#include <linux/types.h>
> +#include <linux/skbuff.h>
> +#include <asm/byteorder.h>
> +#include <net/bluetooth/bluetooth.h>
> +#include <net/bluetooth/hci.h>
> +#include <net/bluetooth/hci_core.h>
> +
> +#include <linux/workqueue.h>
> +#include <linux/wait.h>
> +#include <linux/time.h>
> +#include <linux/jiffies.h>
> +#include <linux/sched.h>
> +#include <linux/timer.h>
> +
> +#include <linux/mfd/cg2900.h>
> +#include <mach/cg2900_devices.h>
> +
> +/* module_param declared in cg2900_core.c */
> +extern int cg2900_debug_level;
> +
> +#define NAME "CG2900 HCI"
> +
> +/* Debug defines */
> +#define CG2900_DBG_DATA(fmt, arg...) \
> +do { \
> + if (cg2900_debug_level >= 25) \
> + printk(KERN_DEBUG NAME " %s: " fmt "\n" , __func__ , ## arg); \
> +} while (0)
> +
> +#define CG2900_DBG(fmt, arg...) \
> +do { \
> + if (cg2900_debug_level >= 20) \
> + printk(KERN_DEBUG NAME " %s: " fmt "\n" , __func__ , ## arg); \
> +} while (0)
> +
> +#define CG2900_INFO(fmt, arg...) \
> +do { \
> + if (cg2900_debug_level >= 10) \
> + printk(KERN_INFO NAME ": " fmt "\n" , ## arg); \
> +} while (0)
> +
> +#define CG2900_ERR(fmt, arg...) \
> +do { \
> + if (cg2900_debug_level >= 1) \
> + printk(KERN_ERR NAME " %s: " fmt "\n" , __func__ , ## arg); \
> +} while (0)
Remove all this debug stuff. Use BT_DBG, BT_ERR etc.
> +#define CG2900_SET_STATE(__name, __var, __new_state) \
> +do { \
> + CG2900_DBG("New %s: 0x%X", __name, (uint32_t)__new_state); \
> + __var = __new_state; \
> +} while (0)
What is this for? Please don't do that. It just obfuscates the code.
> +/* HCI device type */
> +#define HCI_CG2900 HCI_VIRTUAL
This is the wrong type. Don't do that. And don't create a new define for
it. Use the standard types. I assume that HCI_UART is most likely what
you want here.
> +/* Wait for 5 seconds for a response to our requests */
> +#define RESP_TIMEOUT 5000
> +
> +/* State-setting defines */
> +#define SET_RESET_STATE(__hci_reset_new_state) \
> + CG2900_SET_STATE("reset_state", hci_info->reset_state, \
> + __hci_reset_new_state)
> +#define SET_ENABLE_STATE(__hci_enable_new_state) \
> + CG2900_SET_STATE("enable_state", hci_info->enable_state, \
> + __hci_enable_new_state)
Don't do this. It is just highly obfuscating the code flow.
> +/* Bluetooth error codes */
> +#define HCI_ERR_NO_ERROR 0x00
> +#define HCI_ERR_CMD_DISALLOWED 0x0C
> +
> +/**
> + * enum reset_state - RESET-states of the HCI driver.
> + *
> + * @RESET_IDLE: No reset in progress.
> + * @RESET_ACTIVATED: Reset in progress.
> + * @RESET_UNREGISTERED: hdev is unregistered.
> + */
> +
> +enum reset_state {
> + RESET_IDLE,
> + RESET_ACTIVATED,
> + RESET_UNREGISTERED
> +};
> +
> +/**
> + * enum enable_state - ENABLE-states of the HCI driver.
> + *
> + * @ENABLE_IDLE: The HCI driver is loaded but not opened.
> + * @ENABLE_WAITING_BT_ENABLED_CC: The HCI driver is waiting for a command
> + * complete event from the BT chip as a
> + * response to a BT Enable (true) command.
> + * @ENABLE_BT_ENABLED: The BT chip is enabled.
> + * @ENABLE_WAITING_BT_DISABLED_CC: The HCI driver is waiting for a command
> + * complete event from the BT chip as a
> + * response to a BT Enable (false) command.
> + * @ENABLE_BT_DISABLED: The BT chip is disabled.
> + * @ENABLE_BT_ERROR: The HCI driver is in a bad state, some
> + * thing has failed and is not expected to
> + * work properly.
> + */
> +enum enable_state {
> + ENABLE_IDLE,
> + ENABLE_WAITING_BT_ENABLED_CC,
> + ENABLE_BT_ENABLED,
> + ENABLE_WAITING_BT_DISABLED_CC,
> + ENABLE_BT_DISABLED,
> + ENABLE_BT_ERROR
> +};
> +
> +/**
> + * struct hci_info - Specifies HCI driver private data.
> + *
> + * This type specifies CG2900 HCI driver private data.
> + *
> + * @bt_cmd: Device structure for BT command channel.
> + * @bt_evt: Device structure for BT event channel.
> + * @bt_acl: Device structure for BT ACL channel.
> + * @hdev: Device structure for HCI device.
> + * @reset_state: Device enum for HCI driver reset state.
> + * @enable_state: Device enum for HCI driver BT enable state.
> + */
> +struct hci_info {
> + struct cg2900_device *bt_cmd;
> + struct cg2900_device *bt_evt;
> + struct cg2900_device *bt_acl;
> + struct hci_dev *hdev;
> + enum reset_state reset_state;
> + enum enable_state enable_state;
> +};
> +
> +/**
> + * struct dev_info - Specifies private data used when receiving
> callbacks from CPD.
> + *
> + * @hdev: Device structure for HCI device.
> + * @hci_data_type: Type of data according to BlueZ.
> + */
> +struct dev_info {
> + struct hci_dev *hdev;
> + u8 hci_data_type;
> +};
> +
> +/* Variables where LSB and MSB for bt_enable command is stored */
> +static u16 bt_enable_cmd;
> +
> +static struct hci_info *hci_info;
> +
> +/*
> + * hci_wait_queue - Main Wait Queue in HCI driver.
> + */
> +static DECLARE_WAIT_QUEUE_HEAD(hci_wait_queue);
> +
> +/* Internal function declarations */
> +static int register_to_bluez(void);
Don't use bluez in kernel code. Just use bluetooth or bt.
> +/* Internal functions */
> +
> +/**
> + * remove_bt_users() - Unregister and remove any existing BT users.
> + * @info: HCI driver info structure.
> + */
> +static void remove_bt_users(struct hci_info *info)
> +{
> + if (info->bt_cmd) {
> + kfree(info->bt_cmd->user_data);
> + info->bt_cmd->user_data = NULL;
> + cg2900_deregister_user(info->bt_cmd);
> + info->bt_cmd = NULL;
> + }
> +
> + if (info->bt_evt) {
> + kfree(info->bt_evt->user_data);
> + info->bt_evt->user_data = NULL;
> + cg2900_deregister_user(info->bt_evt);
> + info->bt_evt = NULL;
> + }
> +
> + if (info->bt_acl) {
> + kfree(info->bt_acl->user_data);
> + info->bt_acl->user_data = NULL;
> + cg2900_deregister_user(info->bt_acl);
> + info->bt_acl = NULL;
> + }
> +}
> +
> +/**
> + * hci_read_cb() - Callback for handling data received from CG2900 driver.
> + * @dev: Device receiving data.
> + * @skb: Buffer with data coming from device.
> + */
> +static void hci_read_cb(struct cg2900_device *dev, struct sk_buff *skb)
> +{
> + int err = 0;
> + struct dev_info *dev_info;
> + struct hci_event_hdr *evt;
> + struct hci_ev_cmd_complete *cmd_complete;
> + struct hci_ev_cmd_status *cmd_status;
> + u8 status;
> +
> + if (!skb) {
> + CG2900_ERR("NULL supplied for skb");
> + return;
> + }
> +
> + if (!dev) {
> + CG2900_ERR("dev == NULL");
> + goto fin_free_skb;
> + }
> +
> + dev_info = (struct dev_info *)dev->user_data;
> +
> + if (!dev_info) {
> + CG2900_ERR("dev_info == NULL");
> + goto fin_free_skb;
> + }
> +
> + evt = (struct hci_event_hdr *)skb->data;
> + cmd_complete = (struct hci_ev_cmd_complete *)(skb->data + sizeof(*evt));
> + cmd_status = (struct hci_ev_cmd_status *)(skb->data + sizeof(*evt));
> +
> + /*
> + * Check if HCI Driver it self is expecting a Command Complete packet
> + * from the chip after a BT Enable command.
> + */
> + if ((hci_info->enable_state == ENABLE_WAITING_BT_ENABLED_CC ||
> + hci_info->enable_state == ENABLE_WAITING_BT_DISABLED_CC) &&
> + hci_info->bt_evt->h4_channel == dev->h4_channel &&
> + evt->evt == HCI_EV_CMD_COMPLETE &&
> + le16_to_cpu(cmd_complete->opcode) == bt_enable_cmd) {
> + /*
> + * This is the command complete event for
> + * the HCI_Cmd_VS_Bluetooth_Enable.
> + * Check result and update state.
> + *
> + * The BT chip is enabled/disabled. Either it was enabled/
> + * disabled now (status NO_ERROR) or it was already enabled/
> + * disabled (assuming status CMD_DISALLOWED is already enabled/
> + * disabled).
> + */
> + status = *(skb->data + sizeof(*evt) + sizeof(*cmd_complete));
> + if (status != HCI_ERR_NO_ERROR &&
> + status != HCI_ERR_CMD_DISALLOWED) {
> + CG2900_ERR("Could not enable/disable BT core (0x%X)",
> + status);
> + SET_ENABLE_STATE(ENABLE_BT_ERROR);
> + goto fin_free_skb;
> + }
> +
> + if (hci_info->enable_state == ENABLE_WAITING_BT_ENABLED_CC) {
> + SET_ENABLE_STATE(ENABLE_BT_ENABLED);
> + CG2900_INFO("BT core is enabled");
> + } else {
> + SET_ENABLE_STATE(ENABLE_BT_DISABLED);
> + CG2900_INFO("BT core is disabled");
> + }
> +
> + /* Wake up whom ever is waiting for this result. */
> + wake_up_interruptible(&hci_wait_queue);
> + goto fin_free_skb;
> + } else if ((hci_info->enable_state == ENABLE_WAITING_BT_DISABLED_CC ||
> + hci_info->enable_state == ENABLE_WAITING_BT_ENABLED_CC) &&
> + hci_info->bt_evt->h4_channel == dev->h4_channel &&
> + evt->evt == HCI_EV_CMD_STATUS &&
> + le16_to_cpu(cmd_status->opcode) == bt_enable_cmd) {
> + /*
> + * Clear the status events since the Bluez is not expecting
> + * them.
> + */
> + CG2900_DBG("HCI Driver received Command Status(for "
> + "BT enable): 0x%X", cmd_status->status);
> + /*
> + * This is the command status event for
> + * the HCI_Cmd_VS_Bluetooth_Enable.
> + * Just free the packet.
> + */
> + goto fin_free_skb;
> + } else {
> + bt_cb(skb)->pkt_type = dev_info->hci_data_type;
> + skb->dev = (struct net_device *)dev_info->hdev;
> + /* Update BlueZ stats */
> + dev_info->hdev->stat.byte_rx += skb->len;
> + if (bt_cb(skb)->pkt_type == HCI_ACLDATA_PKT)
> + dev_info->hdev->stat.acl_rx++;
> + else
> + dev_info->hdev->stat.evt_rx++;
> +
> + CG2900_DBG_DATA("Data receive %d bytes", skb->len);
> +
> + /* Provide BlueZ with received frame*/
> + err = hci_recv_frame(skb);
> + /* If err, skb have been freed in hci_recv_frame() */
> + if (err)
> + CG2900_ERR("Failed in supplying packet to BlueZ (%d)",
> + err);
> + }
> +
> + return;
> +
> +fin_free_skb:
> + kfree_skb(skb);
> +}
> +
> +/**
> + * hci_reset_cb() - Callback for handling reset from CG2900 driver.
> + * @dev: CPD device resetting.
> + */
> +static void hci_reset_cb(struct cg2900_device *dev)
> +{
> + int err;
> + struct hci_dev *hdev;
> + struct dev_info *dev_info;
> + struct hci_info *info;
> +
> + CG2900_INFO("BluezDriver: hci_reset_cb");
> +
> + if (!dev) {
> + CG2900_ERR("NULL supplied for dev");
> + return;
> + }
> +
> + dev_info = (struct dev_info *)dev->user_data;
> + if (!dev_info) {
> + CG2900_ERR("NULL supplied for dev_info");
> + return;
> + }
> +
> + hdev = dev_info->hdev;
> + if (!hdev) {
> + CG2900_ERR("NULL supplied for hdev");
> + return;
> + }
> +
> + info = (struct hci_info *)hdev->driver_data;
> + if (!info) {
> + CG2900_ERR("NULL supplied for driver_data");
> + return;
> + }
> +
> + switch (dev_info->hci_data_type) {
> +
> + case HCI_EVENT_PKT:
> + info->bt_evt = NULL;
> + break;
> +
> + case HCI_COMMAND_PKT:
> + info->bt_cmd = NULL;
> + break;
> +
> + case HCI_ACLDATA_PKT:
> + info->bt_acl = NULL;
> + break;
> +
> + default:
> + CG2900_ERR("Unknown HCI data type:%d",
> + dev_info->hci_data_type);
> + return;
> + }
> +
> + SET_RESET_STATE(RESET_ACTIVATED);
> +
> + /* Free userdata as device info structure will be freed by CG2900
> + * when this callback returns */
> + kfree(dev->user_data);
> + dev->user_data = NULL;
> +
> + /*
> + * Continue to deregister hdev if all channels has been reset else
> + * return.
> + */
> + if (info->bt_evt || info->bt_cmd || info->bt_acl)
> + return;
> +
> + /*
> + * Deregister HCI device. Close and Destruct functions should
> + * in turn be called by BlueZ.
> + */
> + CG2900_INFO("Deregister HCI device");
> + err = hci_unregister_dev(hdev);
> + if (err)
> + CG2900_ERR("Can not deregister HCI device! (%d)", err);
> + /*
> + * Now we are in trouble. Try to register a new hdev
> + * anyway even though this will cost some memory.
> + */
> +
> + wait_event_interruptible_timeout(hci_wait_queue,
> + (RESET_UNREGISTERED == hci_info->reset_state),
> + msecs_to_jiffies(RESP_TIMEOUT));
> + if (RESET_UNREGISTERED != hci_info->reset_state)
> + /*
> + * Now we are in trouble. Try to register a new hdev
> + * anyway even though this will cost some memory.
> + */
> + CG2900_ERR("Timeout expired. Could not deregister HCI device");
> +
> + /* Init and register hdev */
> + CG2900_INFO("Register HCI device");
> + err = register_to_bluez();
> + if (err)
> + CG2900_ERR("HCI Device registration error (%d).", err);
> +}
> +
> +/*
> + * struct cg2900_cb - Specifies callback structure for CG2900 user.
> + *
> + * @read_cb: Callback function called when data is received from
> + * the controller.
> + * @reset_cb: Callback function called when the controller has been reset.
> + */
> +static struct cg2900_callbacks cg2900_cb = {
> + .read_cb = hci_read_cb,
> + .reset_cb = hci_reset_cb
> +};
> +
> +/**
> + * open_from_hci() - Open HCI interface.
> + * @hdev: HCI device being opened.
> + *
> + * BlueZ callback function for opening HCI interface to device.
> + *
> + * Returns:
> + * 0 if there is no error.
> + * -EINVAL if NULL pointer is supplied.
> + * -EOPNOTSUPP if supplied packet type is not supported.
> + * -EBUSY if device is already opened.
> + * -EACCES if opening of channels failed.
> + */
> +static int open_from_hci(struct hci_dev *hdev)
> +{
> + struct hci_info *info;
> + struct dev_info *dev_info;
> + struct sk_buff *enable_cmd;
> + int err;
> +
> + CG2900_INFO("Open ST-Ericsson connectivity HCI driver");
> +
> + if (!hdev) {
> + CG2900_ERR("NULL supplied for hdev");
> + return -EINVAL;
> + }
> +
> + info = (struct hci_info *)hdev->driver_data;
> + if (!info) {
> + CG2900_ERR("NULL supplied for driver_data");
> + return -EINVAL;
> + }
> +
> + if (test_and_set_bit(HCI_RUNNING, &(hdev->flags))) {
> + CG2900_ERR("Device already opened!");
> + return -EBUSY;
> + }
> +
> + if (!(info->bt_cmd)) {
> + info->bt_cmd = cg2900_register_user(CG2900_BT_CMD,
> + &cg2900_cb);
> + if (info->bt_cmd) {
> + dev_info = kmalloc(sizeof(*dev_info), GFP_KERNEL);
> + if (dev_info) {
> + dev_info->hdev = hdev;
> + dev_info->hci_data_type = HCI_COMMAND_PKT;
> + }
> + info->bt_cmd->user_data = dev_info;
> + } else {
> + CG2900_ERR("Couldn't register CG2900_BT_CMD to CG2900");
> + err = -EACCES;
> + goto handle_error;
> + }
> + }
> +
> + if (!(info->bt_evt)) {
> + info->bt_evt = cg2900_register_user(CG2900_BT_EVT,
> + &cg2900_cb);
> + if (info->bt_evt) {
> + dev_info = kmalloc(sizeof(*dev_info), GFP_KERNEL);
> + if (dev_info) {
> + dev_info->hdev = hdev;
> + dev_info->hci_data_type = HCI_EVENT_PKT;
> + }
> + info->bt_evt->user_data = dev_info;
> + } else {
> + CG2900_ERR("Couldn't register CG2900_BT_EVT to CG2900");
> + err = -EACCES;
> + goto handle_error;
> + }
> + }
> +
> + if (!(info->bt_acl)) {
> + info->bt_acl = cg2900_register_user(CG2900_BT_ACL,
> + &cg2900_cb);
> + if (info->bt_acl) {
> + dev_info = kmalloc(sizeof(*dev_info), GFP_KERNEL);
> + if (dev_info) {
> + dev_info->hdev = hdev;
> + dev_info->hci_data_type = HCI_ACLDATA_PKT;
> + }
> + info->bt_acl->user_data = dev_info;
> + } else {
> + CG2900_ERR("Couldn't register CG2900_BT_ACL to CG2900");
> + err = -EACCES;
> + goto handle_error;
> + }
> + }
> +
> + if (info->reset_state == RESET_ACTIVATED)
> + SET_RESET_STATE(RESET_IDLE);
> +
> + /*
> + * Call platform specific function that returns the chip dependent
> + * bt enable(true) HCI command.
> + * If NULL is returned, then no bt_enable command should be sent to the
> + * chip.
> + */
> + enable_cmd = cg2900_devices_get_bt_enable_cmd(&bt_enable_cmd, true);
> + if (!enable_cmd) {
> + /* The chip is enabled by default */
> + SET_ENABLE_STATE(ENABLE_BT_ENABLED);
> + return 0;
> + }
> +
> + /* Set the HCI state before sending command to chip. */
> + SET_ENABLE_STATE(ENABLE_WAITING_BT_ENABLED_CC);
> +
> + /* Send command to chip */
> + cg2900_write(info->bt_cmd, enable_cmd);
> +
> + /*
> + * Wait for callback to receive command complete and then wake us up
> + * again.
> + */
> + wait_event_interruptible_timeout(hci_wait_queue,
> + (info->enable_state == ENABLE_BT_ENABLED),
> + msecs_to_jiffies(RESP_TIMEOUT));
> + /* Check the current state to se that it worked. */
> + if (info->enable_state != ENABLE_BT_ENABLED) {
> + CG2900_ERR("Could not enable BT core (%d)", info->enable_state);
> + err = -EACCES;
> + SET_ENABLE_STATE(ENABLE_BT_DISABLED);
> + goto handle_error;
> + }
> +
> + return 0;
> +
> +handle_error:
> + remove_bt_users(info);
> + clear_bit(HCI_RUNNING, &(hdev->flags));
> + return err;
> +
> +}
> +
> +/**
> + * flush_from_hci() - Flush HCI interface.
> + * @hdev: HCI device being flushed.
> + *
> + * Returns:
> + * 0 if there is no error.
> + * -EINVAL if NULL pointer is supplied.
> + */
> +static int flush_from_hci(struct hci_dev *hdev)
> +{
> + CG2900_INFO("flush_from_hci");
> +
> + if (!hdev) {
> + CG2900_ERR("NULL supplied for hdev");
> + return -EINVAL;
> + }
> +
> + return 0;
> +}
> +
> +/**
> + * close_from_hci() - Close HCI interface.
> + * @hdev: HCI device being closed.
> + *
> + * BlueZ callback function for closing HCI interface.
> + * It flushes the interface first.
> + *
> + * Returns:
> + * 0 if there is no error.
> + * -EINVAL if NULL pointer is supplied.
> + * -EOPNOTSUPP if supplied packet type is not supported.
> + * -EBUSY if device is not opened.
> + */
> +static int close_from_hci(struct hci_dev *hdev)
> +{
> + struct hci_info *info = NULL;
> + struct sk_buff *enable_cmd;
> +
> + CG2900_INFO("close_from_hci");
> +
> + if (!hdev) {
> + CG2900_ERR("NULL supplied for hdev");
> + return -EINVAL;
> + }
> +
> + info = (struct hci_info *)hdev->driver_data;
> + if (!info) {
> + CG2900_ERR("NULL supplied for driver_data");
> + return -EINVAL;
> + }
> +
> + if (!test_and_clear_bit(HCI_RUNNING, &(hdev->flags))) {
> + CG2900_ERR("Device already closed!");
> + return -EBUSY;
> + }
> +
> + flush_from_hci(hdev);
> +
> + /* Do not do this if there is an reset ongoing */
> + if (hci_info->reset_state == RESET_ACTIVATED)
> + goto remove_users;
> +
> + /*
> + * Get the chip dependent BT Enable HCI command. The command parameter
> + * shall be set to false to disable the BT core.
> + * If NULL is returned, then no BT Enable command should be sent to the
> + * chip.
> + */
> + enable_cmd = cg2900_devices_get_bt_enable_cmd(&bt_enable_cmd, false);
> + if (!enable_cmd) {
> + /*
> + * The chip is enabled by default and we should not disable it.
> + */
> + SET_ENABLE_STATE(ENABLE_BT_ENABLED);
> + goto remove_users;
> + }
> +
> + /* Set the HCI state before sending command to chip */
> + SET_ENABLE_STATE(ENABLE_WAITING_BT_DISABLED_CC);
> +
> + /* Send command to chip */
> + cg2900_write(info->bt_cmd, enable_cmd);
> +
> + /*
> + * Wait for callback to receive command complete and then wake us up
> + * again.
> + */
> + wait_event_interruptible_timeout(hci_wait_queue,
> + (info->enable_state == ENABLE_BT_DISABLED),
> + msecs_to_jiffies(RESP_TIMEOUT));
> + /* Check the current state to se that it worked. */
> + if (info->enable_state != ENABLE_BT_DISABLED) {
> + CG2900_ERR("Could not disable BT core.");
> + SET_ENABLE_STATE(ENABLE_BT_ENABLED);
> + }
> +
> +remove_users:
> + /* Finally deregister all users and free allocated data */
> + remove_bt_users(info);
> + return 0;
> +}
> +
> +/**
> + * send_from_hci() - Send packet to device.
> + * @skb: sk buffer to be sent.
> + *
> + * BlueZ callback function for sending sk buffer.
> + *
> + * Returns:
> + * 0 if there is no error.
> + * -EINVAL if NULL pointer is supplied.
> + * -EOPNOTSUPP if supplied packet type is not supported.
> + * Error codes from cg2900_write.
> + */
> +static int send_from_hci(struct sk_buff *skb)
> +{
> + struct hci_dev *hdev;
> + struct hci_info *info;
> + int err = 0;
> +
> + if (!skb) {
> + CG2900_ERR("NULL supplied for skb");
> + return -EINVAL;
> + }
> +
> + hdev = (struct hci_dev *)(skb->dev);
> + if (!hdev) {
> + CG2900_ERR("NULL supplied for hdev");
> + return -EINVAL;
> + }
> +
> + info = (struct hci_info *)hdev->driver_data;
> + if (!info) {
> + CG2900_ERR("NULL supplied for info");
> + return -EINVAL;
> + }
> +
> + /* Update BlueZ stats */
> + hdev->stat.byte_tx += skb->len;
> +
> + CG2900_DBG_DATA("Data transmit %d bytes", skb->len);
> +
> + switch (bt_cb(skb)->pkt_type) {
> + case HCI_COMMAND_PKT:
> + CG2900_DBG("Sending HCI_COMMAND_PKT");
> + err = cg2900_write(info->bt_cmd, skb);
> + hdev->stat.cmd_tx++;
> + break;
> + case HCI_ACLDATA_PKT:
> + CG2900_DBG("Sending HCI_ACLDATA_PKT");
> + err = cg2900_write(info->bt_acl, skb);
> + hdev->stat.acl_tx++;
> + break;
> + default:
> + CG2900_ERR("Trying to transmit unsupported packet type "
> + "(0x%.2X)", bt_cb(skb)->pkt_type);
> + err = -EOPNOTSUPP;
> + break;
> + };
> +
> + return err;
> +}
> +
> +/**
> + * destruct_from_hci() - Destruct HCI interface.
> + * @hdev: HCI device being destructed.
> + */
> +static void destruct_from_hci(struct hci_dev *hdev)
> +{
> + CG2900_INFO("destruct_from_hci");
> +
> + if (!hci_info)
> + return;
> +
> + /* When being reset, register a new hdev when hdev is deregistered */
> + if (hci_info->reset_state == RESET_ACTIVATED) {
> + if (hci_info->hdev)
> + hci_free_dev(hci_info->hdev);
> + SET_RESET_STATE(RESET_UNREGISTERED);
> + }
> +}
Please name thse cg2900_destruct or btcg2900_destruct. And not from_hci.
Follow how the other Bluetooth drivers do the naming.
And the destruct callback is for freeing memory. I am also not sure how
reset and unregister/re-register HCI is a good idea.
> +/**
> + * notify_from_hci() - Notification from the HCI interface.
> + * @hdev: HCI device notifying.
> + * @evt: Notification event.
> + */
> +static void notify_from_hci(struct hci_dev *hdev, unsigned int evt)
> +{
> + CG2900_INFO("notify_from_hci - evt = 0x%.2X", evt);
> +}
If you don't use it, then just leave it out.
> +/**
> + * ioctl_from_hci() - Handle IOCTL call to the HCI interface.
> + * @hdev: HCI device.
> + * @cmd: IOCTL command.
> + * @arg: IOCTL argument.
> + *
> + * Returns:
> + * -EINVAL if NULL is supplied for hdev.
> + * -EPERM otherwise since current driver supports no IOCTL.
> + */
> +static int ioctl_from_hci(struct hci_dev *hdev, unsigned int cmd,
> + unsigned long arg)
> +{
> + CG2900_INFO("ioctl_from_hci - cmd 0x%X", cmd);
> + CG2900_DBG("DIR: %d, TYPE: %d, NR: %d, SIZE: %d",
> + _IOC_DIR(cmd), _IOC_TYPE(cmd), _IOC_NR(cmd),
> + _IOC_SIZE(cmd));
> +
> + if (!hdev) {
> + CG2900_ERR("NULL supplied for hdev");
> + return -EINVAL;;
> + }
> +
> + return -EPERM;
> +}
Since you are not using anything with the ioctl, just leave it out. The
Bluetooth subsystem will do the right thing.
> +/**
> + * register_to_bluez() - Initialize module.
> + *
> + * Alloc, init, and register HCI device to BlueZ.
> + *
> + * Returns:
> + * 0 if there is no error.
> + * -ENOMEM if allocation fails.
> + * Error codes from hci_register_dev.
> + */
> +static int register_to_bluez(void)
> +{
> + int err;
> +
> + hci_info->hdev = hci_alloc_dev();
> + if (!hci_info->hdev) {
> + CG2900_ERR("Could not allocate mem for HCI driver");
> + return -ENOMEM;
> + }
> +
> + hci_info->hdev->bus = HCI_CG2900;
> + hci_info->hdev->driver_data = hci_info;
> + hci_info->hdev->owner = THIS_MODULE;
> + hci_info->hdev->open = open_from_hci;
> + hci_info->hdev->close = close_from_hci;
> + hci_info->hdev->flush = flush_from_hci;
> + hci_info->hdev->send = send_from_hci;
> + hci_info->hdev->destruct = destruct_from_hci;
> + hci_info->hdev->notify = notify_from_hci;
> + hci_info->hdev->ioctl = ioctl_from_hci;
> +
> + err = hci_register_dev(hci_info->hdev);
> + if (err) {
> + CG2900_ERR("Can not register HCI device (%d)", err);
> + hci_free_dev(hci_info->hdev);
> + }
> +
> + SET_ENABLE_STATE(ENABLE_IDLE);
> + SET_RESET_STATE(RESET_IDLE);
> +
> + return err;
> +}
So whenever the module is loaded it registers the HCI device. That is
not really useful here. This driver needs to be able to be compiled into
the kernel (or as module) and run on hardware that doesn't have this
chip built in.
> +/**
> + * hci_init() - Initialize module.
> + *
> + * Allocate and initialize private data. Register to BlueZ.
> + *
> + * Returns:
> + * 0 if there is no error.
> + * -ENOMEM if allocation fails.
> + * Error codes from register_to_bluez.
> + */
> +static int __init hci_init(void)
> +{
> + int err;
> + CG2900_INFO("hci_init");
> +
> + /* Initialize private data. */
> + hci_info = kzalloc(sizeof(*hci_info), GFP_KERNEL);
> + if (!hci_info) {
> + CG2900_ERR("Could not alloc hci_info struct.");
> + return -ENOMEM;
> + }
> +
> + /* Init and register hdev */
> + err = register_to_bluez();
> + if (err) {
> + CG2900_ERR("HCI Device registration error (%d)", err);
> + kfree(hci_info);
> + hci_info = NULL;
> + return err;
> + }
> +
> + return 0;
> +}
> +
> +/**
> + * hci_exit() - Remove module.
> + *
> + * Remove HCI device from CG2900 driver.
> + */
> +static void __exit hci_exit(void)
> +{
> + int err = 0;
> +
> + CG2900_INFO("hci_exit");
> +
> + if (!hci_info)
> + return;
> +
> + if (!hci_info->hdev)
> + goto finished;
> +
> + err = hci_unregister_dev(hci_info->hdev);
> + if (err)
> + CG2900_ERR("Can not unregister HCI device (%d)", err);
> + hci_free_dev(hci_info->hdev);
> +
> +finished:
> + kfree(hci_info);
> + hci_info = NULL;
> +}
> +
> +module_init(hci_init);
> +module_exit(hci_exit);
Please use more clear names like cg2900_init or similar.
> +MODULE_AUTHOR("Par-Gunnar Hjalmdahl ST-Ericsson");
> +MODULE_AUTHOR("Henrik Possung ST-Ericsson");
> +MODULE_AUTHOR("Josef Kindberg ST-Ericsson");
> +MODULE_LICENSE("GPL v2");
> +MODULE_DESCRIPTION("Linux Bluetooth HCI H:4 Driver for ST-Ericsson
> controller");
Regards
Marcel
^ permalink raw reply
* Re: Sim Access profile server implementation
From: Suraj Sumangala @ 2010-10-05 9:08 UTC (permalink / raw)
To: Marcel Holtmann
Cc: Suraj Sumangala, linux-bluetooth@vger.kernel.org,
Jothikumar Mothilal
In-Reply-To: <1286265730.17473.29.camel@aeonflux>
Hi Marcel,
On 10/5/2010 1:32 PM, Marcel Holtmann wrote:
> Hi Suraj,
>
>> Please find the Git tree for the Sim access profile server role
>> implementation I have been working on at
>>
>> git://gitorious.org/sap-server/sap-server.git
>>
>> Not sure it could be directly used with Bluez. Nevertheless, it has the
>> parser implementation of Bluetooth SAP packet. Someone could possibly
>> reuse it in their implementation.
>
> have you actually tested this with real SAP server capable hardware? I
> am still not convinced at all to push APDU over D-Bus. First, there is
> potential security issue here and second the latency that D-Bus
> introduces seems not be acceptable. So what I am getting it, can this be
> actually used in a product that seriously wants to support SAP server?
No, This was tested with a dummy Agent and PTS. I am yet to get hold of
a hardware.
The reason for sharing the source code was because any later SAP server
implementation can re-use the SAP packet parser implementation I have
already done.
I think we should be able to change the interface later depending on the
actual hardware/system requirement. But, I believe the internal
implementation could stay the same.
>
> Regards
>
> Marcel
>
>
Regards
Suraj
^ permalink raw reply
* Re: [PATCH 6/6] This patch adds support for using the ST-Ericsson CG2900
From: Marcel Holtmann @ 2010-10-05 8:27 UTC (permalink / raw)
To: Par-Gunnar Hjalmdahl
Cc: Gustavo F. Padovan, linux-bluetooth, linux-kernel, linus.walleij,
Pavan Savoy
In-Reply-To: <AANLkTimdAxaF2gyXXXgYtjQ5+3eXuTpnpQ5n2KFtDwth@mail.gmail.com>
Hi Par-Gunnar,
> > * Par-Gunnar Hjalmdahl <par-gunnar.p.hjalmdahl@stericsson.com> [2010-09-24 15:52:16 +0200]:
> >
> >> This patch adds support for using the ST-Ericsson CG2900
> >> connectivity controller as a driver for the BlueZ Bluetooth
> >> stack.
> >> This patch registers as a driver into the BlueZ framework and, when
> >> opened by BlueZ, it registers as user for bt_cmd, bt_acl, and bt_evt
> >> channels.
> >
> > First of all your your commit message and subject should be improved.
> > The subject should bee something like:
> >
> > "Bluetooth: Add support for ST-Ericsson CG2900"
> >
> > and in the commit message you explain the details of the patch.
> > And normally we do not use the BlueZ word in kernelspace.
> >
>
> OK. This is the first patch I've created within the community and of
> course there are bound to be errors... ;-)
> Since it was part of a big patch delivery I used quite similar names
> across the different patches and I understand that this is an error
> since the different patches are targeting different communities.
>
> >>
> >> Signed-off-by: Par-Gunnar Hjalmdahl <par-gunnar.p.hjalmdahl@stericsson.com>
> >> ---
> >> drivers/bluetooth/Kconfig | 7 +
> >> drivers/bluetooth/Makefile | 2 +
> >> drivers/bluetooth/cg2900_hci.c | 896 ++++++++++++++++++++++++++++++++++++++++
> >> 3 files changed, 905 insertions(+), 0 deletions(-)
> >> create mode 100644 drivers/bluetooth/cg2900_hci.c
> >
> > Your patch looks a way complicated to a UART driver. Look at the others
> > drivers at drivers/bluetooth/ and see how we implemented other UART
> > drivers.
> >
>
> Well, mainly that's because it is not a UART driver. It is a driver
> against CG2900 which currently have only UART as transport but quite
> soon will get SPI as transport as well. For this Bluetooth driver the
> actual physical transport used is not known. It just knows it has a
> reliable transport below which delivers complete Bluetooth packets.
inside the Bluetooth driver please just use BT_DBG. That is hooked up
into dynamic_debug feature of the kernel and you can do whatever you
need for debugging.
I will not accept huge debug frameworks in the Bluetooth subsystem. Use
what the kernel offers you. You selective control based on every single
debug statement. It doesn't get better than that.
Regards
Marcel
^ permalink raw reply
* Re: RFC: btusb firmware load help
From: Marcel Holtmann @ 2010-10-05 8:23 UTC (permalink / raw)
To: Luis R. Rodriguez
Cc: linux-bluetooth, linux-kernel, linux-wireless, Deepak Dhamdhere,
Sree Durbha
In-Reply-To: <20100924230730.GB6566@tux>
Hi Luis,
> Marcel, I was just poked about this thread:
>
> http://www.spinics.net/lists/linux-bluetooth/msg06087.html
>
> The hack is required because our BT hardware does not accept HCI commands
> when the device is plugged in. If I understood your position you did not
> want to accept the patch because our BT USB devices are violating the
> specification by not acceping HCI commands and yet claiming to be BT
> devices, is that right?
you don't have to accept HCI commands when your device has no firmware
loaded. That is just fine. However at that point you should not claim to
be a Bluetooth H:2 device with USB Bluetooth descriptors.
Just having different USB PIDs for without firmware and with firmware
stages would have been fine. The ancient Broadcom 203x devices even got
that part right.
So what about sticking with the current VID:PID for the device without
firmware and we blacklist it in btusb driver. And then the firmware
loading ensures that after reset it uses a different PID for the device
with valid HCI firmware.
Regards
Marcel
^ permalink raw reply
* Re: [PATCH] Fix use of uninitialised variable on legacy pairing
From: Johan Hedberg @ 2010-10-05 8:20 UTC (permalink / raw)
To: Luiz Augusto von Dentz; +Cc: linux-bluetooth
In-Reply-To: <1286264425-24281-1-git-send-email-luiz.dentz@gmail.com>
Hi Luiz,
On Tue, Oct 05, 2010, Luiz Augusto von Dentz wrote:
> From: Luiz Augusto von Dentz <luiz.dentz-von@nokia.com>
>
> Regression caused by e7daece858070d71cecf6ade4f0e3c93272c53ac:
>
> ==23899== Use of uninitialised value of size 4
> ==23899== at 0x49CD888: _itoa_word (_itoa.c:196)
> ==23899== by 0x49D1109: vfprintf (vfprintf.c:1613)
> ==23899== by 0x4A7506C: __vsprintf_chk (vsprintf_chk.c:86)
> ==23899== by 0x4A74FAC: __sprintf_chk (sprintf_chk.c:33)
> ==23899== by 0x4830E08: ba2str (stdio2.h:34)
> ==23899== by 0x1496B3: set_pin_length (security.c:514)
> ==23899== by 0x168399: pincode_cb (dbus-hci.c:179)
> ==23899== by 0x162E0D: pincode_cb (device.c:2135)
> ==23899== by 0x15AD55: pincode_reply (agent.c:416)
> ==23899== by 0x49467E0: ??? (in /lib/libdbus-1.so.3.5.2)
> ==23899== by 0x4934975: ??? (in /lib/libdbus-1.so.3.5.2)
> ==23899== by 0x4937B81: dbus_connection_dispatch (in /lib/libdbus-1.so.3.5.2)
> ==23899==
> ==23899== Conditional jump or move depends on uninitialised value(s)
> ==23899== at 0x49CD893: _itoa_word (_itoa.c:196)
> ==23899== by 0x49D1109: vfprintf (vfprintf.c:1613)
> ==23899== by 0x4A7506C: __vsprintf_chk (vsprintf_chk.c:86)
> ==23899== by 0x4A74FAC: __sprintf_chk (sprintf_chk.c:33)
> ==23899== by 0x4830E08: ba2str (stdio2.h:34)
> ==23899== by 0x1496B3: set_pin_length (security.c:514)
> ==23899== by 0x168399: pincode_cb (dbus-hci.c:179)
> ==23899== by 0x162E0D: pincode_cb (device.c:2135)
> ==23899== by 0x15AD55: pincode_reply (agent.c:416)
> ==23899== by 0x49467E0: ??? (in /lib/libdbus-1.so.3.5.2)
> ==23899== by 0x4934975: ??? (in /lib/libdbus-1.so.3.5.2)
> ==23899== by 0x4937B81: dbus_connection_dispatch (in /lib/libdbus-1.so.3.5.2)
> ---
> src/dbus-hci.c | 1 +
> 1 files changed, 1 insertions(+), 0 deletions(-)
Thanks for the patch. It's now upstream along with another patch to
clean up the logic in this function. Strange that the compiler didn't
catch this issue. Unfortunately we just made a 4.74 release so I guess
there'll be a 4.75 out soonish.
Johan
^ permalink raw reply
* Re: Sim Access profile server implementation
From: Marcel Holtmann @ 2010-10-05 8:02 UTC (permalink / raw)
To: suraj; +Cc: linux-bluetooth@vger.kernel.org, Jothikumar Mothilal
In-Reply-To: <1285657515.12097.7.camel@atheros013-desktop>
Hi Suraj,
> Please find the Git tree for the Sim access profile server role
> implementation I have been working on at
>
> git://gitorious.org/sap-server/sap-server.git
>
> Not sure it could be directly used with Bluez. Nevertheless, it has the
> parser implementation of Bluetooth SAP packet. Someone could possibly
> reuse it in their implementation.
have you actually tested this with real SAP server capable hardware? I
am still not convinced at all to push APDU over D-Bus. First, there is
potential security issue here and second the latency that D-Bus
introduces seems not be acceptable. So what I am getting it, can this be
actually used in a product that seriously wants to support SAP server?
Regards
Marcel
^ permalink raw reply
* Re: [PATCH] Bluetooth: clean up rfcomm code
From: Marcel Holtmann @ 2010-10-05 7:53 UTC (permalink / raw)
To: Emeltchenko Andrei; +Cc: linux-bluetooth
In-Reply-To: <1285923911-12902-1-git-send-email-Andrei.Emeltchenko.news@gmail.com>
Hi Andrei,
> Remove dead code and unused rfcomm thread events
>
> Signed-off-by: Andrei Emeltchenko <andrei.emeltchenko@nokia.com>
> ---
> include/net/bluetooth/rfcomm.h | 5 -----
> net/bluetooth/rfcomm/core.c | 29 ++++++++++++++---------------
> 2 files changed, 14 insertions(+), 20 deletions(-)
>
> diff --git a/include/net/bluetooth/rfcomm.h b/include/net/bluetooth/rfcomm.h
> index a140847..71047bc 100644
> --- a/include/net/bluetooth/rfcomm.h
> +++ b/include/net/bluetooth/rfcomm.h
> @@ -213,11 +213,6 @@ struct rfcomm_dlc {
> #define RFCOMM_DEFER_SETUP 8
>
> /* Scheduling flags and events */
> -#define RFCOMM_SCHED_STATE 0
> -#define RFCOMM_SCHED_RX 1
> -#define RFCOMM_SCHED_TX 2
> -#define RFCOMM_SCHED_TIMEO 3
> -#define RFCOMM_SCHED_AUTH 4
> #define RFCOMM_SCHED_WAKEUP 31
we had some big ambition to use these, but never did in the end or
realized that they are not needed. So I am fine with removing these.
Acked-by: Marcel Holtmann <marcel@holtmann.org>
Regards
Marcel
^ permalink raw reply
* Re: [PATCH] Added firmware load patch to crap directory. This patch loads firmware from btusb when device is plugged in.
From: Marcel Holtmann @ 2010-10-05 7:52 UTC (permalink / raw)
To: Luis R. Rodriguez
Cc: Bala Shanmugam, linux-wireless, linux-bluetooth, linux-kernel
In-Reply-To: <AANLkTinjiJ6FyoAi4aP=8pr9EwV0wpV7LtwQx-hwaOFs@mail.gmail.com>
Hi Luis,
> > Marcel feels that Atheros sflash based BT device
> > +doesn't follow bluetooth H:2 specification and HCI commands should be supported
> > +in firmware if it is detected as bluetooth device. Using HCI command, firmware
> > +should be loaded.
> > +
> > +In sfash based device we don't have enough memory to support HCI commands in firmware.
> > +So load firmware from btusb when the device comes up.
> > +
>
> You should still ask the maintainer for an alternative, otherwise the
> device unusable. Did you submit the patch first in [PATCH] form? If
> not please submit the patch, all I saw as an RFC and no followup at
> all.
I think it is pretty clear how these devices should be designed when it
comes to firmware loading. Just having different USB PIDs for firmware
loading stage and fully functional Bluetooth device stage is not that
hard to do. Other companies have done this.
If you device claims Bluetooth USB class descriptors, then it should
behave like that and offer HCI protocol running on it.
Regards
Marcel
^ permalink raw reply
* Re: [PATCHv1 0/5] Bluetooth: experimental support for pm_limits
From: Marcel Holtmann @ 2010-10-05 7:49 UTC (permalink / raw)
To: Emeltchenko Andrei; +Cc: linux-bluetooth
In-Reply-To: <1285937230-547-1-git-send-email-Andrei.Emeltchenko.news@gmail.com>
Hi Andrei,
> First version of using power constraints interface to achieve
> maximum bluetooth transfer speed. Otherwise HW goes to idle mode
> and speed decreases 3 times.
>
> Use empirical power management analyzer (TM) to define amount
> of time device set high power constraints for.
>
> May include hacks :-)
please send these as [RFC] and not as [PATCH] if they are meant for
review.
Regards
Marcel
^ permalink raw reply
* Re: [PATCH] Added firmware load patch to crap directory.
From: Marcel Holtmann @ 2010-10-05 7:46 UTC (permalink / raw)
To: Bala Shanmugam; +Cc: linux-wireless, linux-bluetooth, linux-kernel
In-Reply-To: <1286118002-2354-1-git-send-email-sbalashanmugam@atheros.com>
Hi Bala,
> This patch in crap directory enables btusb to load firmware
> to device RAM when it is plugged in.
> Signed-off-by: Bala Shanmugam <sbalashanmugam@atheros.com>
> ---
> crap/0003-btusb-Add-fw-load-support.patch | 424 +++++++++++++++++++++++++++++
> 1 files changed, 424 insertions(+), 0 deletions(-)
> create mode 100644 crap/0003-btusb-Add-fw-load-support.patch
>
> diff --git a/crap/0003-btusb-Add-fw-load-support.patch b/crap/0003-btusb-Add-fw-load-support.patch
> new file mode 100644
> index 0000000..6642d6b
> --- /dev/null
> +++ b/crap/0003-btusb-Add-fw-load-support.patch
> @@ -0,0 +1,424 @@
> +Reason for not yet publishing: Marcel feels that Atheros sflash based BT device
> +doesn't follow bluetooth H:2 specification and HCI commands should be supported
> +in firmware if it is detected as bluetooth device. Using HCI command, firmware
> +should be loaded.
> +
> +In sflash based device there is not enough memory to support HCI commands in firmware.
> +So load firmware from btusb when the device comes up.
and why are you just not fixing this properly. You can have a custom
firmware loader with a different product ID. Load the firmware and then
on reset it brings it up with proper Bluetooth USB class identifiers.
Nothing demands that the firmware loading happens via HCI. You can
invent your own protocol easily. See bcm203x firmware loader driver that
has been around since the beginning of Bluetooth.
Regards
Marcel
^ permalink raw reply
* [PATCH] Fix use of uninitialised variable on legacy pairing
From: Luiz Augusto von Dentz @ 2010-10-05 7:40 UTC (permalink / raw)
To: linux-bluetooth
From: Luiz Augusto von Dentz <luiz.dentz-von@nokia.com>
Regression caused by e7daece858070d71cecf6ade4f0e3c93272c53ac:
==23899== Use of uninitialised value of size 4
==23899== at 0x49CD888: _itoa_word (_itoa.c:196)
==23899== by 0x49D1109: vfprintf (vfprintf.c:1613)
==23899== by 0x4A7506C: __vsprintf_chk (vsprintf_chk.c:86)
==23899== by 0x4A74FAC: __sprintf_chk (sprintf_chk.c:33)
==23899== by 0x4830E08: ba2str (stdio2.h:34)
==23899== by 0x1496B3: set_pin_length (security.c:514)
==23899== by 0x168399: pincode_cb (dbus-hci.c:179)
==23899== by 0x162E0D: pincode_cb (device.c:2135)
==23899== by 0x15AD55: pincode_reply (agent.c:416)
==23899== by 0x49467E0: ??? (in /lib/libdbus-1.so.3.5.2)
==23899== by 0x4934975: ??? (in /lib/libdbus-1.so.3.5.2)
==23899== by 0x4937B81: dbus_connection_dispatch (in /lib/libdbus-1.so.3.5.2)
==23899==
==23899== Conditional jump or move depends on uninitialised value(s)
==23899== at 0x49CD893: _itoa_word (_itoa.c:196)
==23899== by 0x49D1109: vfprintf (vfprintf.c:1613)
==23899== by 0x4A7506C: __vsprintf_chk (vsprintf_chk.c:86)
==23899== by 0x4A74FAC: __sprintf_chk (sprintf_chk.c:33)
==23899== by 0x4830E08: ba2str (stdio2.h:34)
==23899== by 0x1496B3: set_pin_length (security.c:514)
==23899== by 0x168399: pincode_cb (dbus-hci.c:179)
==23899== by 0x162E0D: pincode_cb (device.c:2135)
==23899== by 0x15AD55: pincode_reply (agent.c:416)
==23899== by 0x49467E0: ??? (in /lib/libdbus-1.so.3.5.2)
==23899== by 0x4934975: ??? (in /lib/libdbus-1.so.3.5.2)
==23899== by 0x4937B81: dbus_connection_dispatch (in /lib/libdbus-1.so.3.5.2)
---
src/dbus-hci.c | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/src/dbus-hci.c b/src/dbus-hci.c
index b93dbcd..7309883 100644
--- a/src/dbus-hci.c
+++ b/src/dbus-hci.c
@@ -167,6 +167,7 @@ static void pincode_cb(struct agent *agent, DBusError *derr,
bdaddr_t sba, dba;
int err;
+ adapter_get_address(adapter, &sba);
device_get_address(device, &dba);
err = btd_adapter_pincode_reply(adapter, &dba, derr ? NULL : pincode);
--
1.7.1
^ permalink raw reply related
* Re: [PATCH] Bluetooth: Support for new firmware for ath3k USB Bluetooth device
From: Marcel Holtmann @ 2010-10-05 7:38 UTC (permalink / raw)
To: David Vrabel; +Cc: Suraj Sumangala, linux-bluetooth, Jothikumar.Mothilal
In-Reply-To: <4CAACD5A.8040304@csr.com>
Hi David,
> > This patch add support for new ath3k USB Bluetooth device firmare.
> > The firmware implements shared antenna support and
> > fixes few critical bugs.
> [...]
> > static int ath3k_probe(struct usb_interface *intf,
> > const struct usb_device_id *id)
> > {
> > @@ -110,6 +113,8 @@ static int ath3k_probe(struct usb_interface *intf,
> > struct usb_device *udev = interface_to_usbdev(intf);
> > struct ath3k_data *data;
> > int size;
> > + int i;
> > + char fw_file[MAXPATHLEN]
>
> Suggest FW_PATH_LEN here to avoid confusion as most people would expect
> MAXPATHLEN to be enormous.
>
> > BT_DBG("intf %p id %p", intf, id);
> >
> > @@ -122,7 +127,16 @@ static int ath3k_probe(struct usb_interface *intf,
> >
> > data->udev = udev;
> >
> > - if (request_firmware(&firmware, "ath3k-1.fw", &udev->dev) < 0) {
>
> Why not request ath3k-1.fw (for backward compatibility) and ath3k.fw and
> symlink this name to ath3k-2.fw or any future version of firmware?
>
> I think users should be able to update firmware without a kernel update
> where possible.
yes, it is mandatory to support at least the last two firmware version.
Just forcing a firmware update with a new kernel is not going to work.
So NAK on this patch.
Regards
Marcel
^ permalink raw reply
* Re: Inquiry_with_RSSI compatible dongles
From: Marcel Holtmann @ 2010-10-05 7:36 UTC (permalink / raw)
To: Giedo Mak; +Cc: linux-bluetooth
In-Reply-To: <AANLkTi=uuyRQ-9Qj1THDvOroE3yLU7ZBJS_tX26h0O4y@mail.gmail.com>
Hi Giedo,
> I'm working on a bluetooth program with some sort of distance sensing/tracking.
> To make this easier I came across a feature called inquiry_with_RSSI.
> Could somebody tell me what kind of dongles support this feature. I
> mean, does every 2.1 BT dongle support it, or can you only find out
> once you get one in your hands?
in general every Bluetooth 1.2 dongle and later should support Inquiry
with RSSI. I still have to come across a 2.1 dongle that doesn't.
Regards
Marcel
^ permalink raw reply
* Re: pull-request: bluetooth-2.6 2010-09-27
From: David Miller @ 2010-10-05 7:06 UTC (permalink / raw)
To: padovan; +Cc: linville, marcel, linux-bluetooth, netdev
In-Reply-To: <20101004223513.GB3234@vigoh>
From: "Gustavo F. Padovan" <padovan@profusion.mobi>
Date: Mon, 4 Oct 2010 19:35:13 -0300
> Follow the output of git show for that change, if we agree on the change I
> can append it to the bluetooth pull request.
That makes sense to me, thanks for doing this audit.
Append that commit and send a new pull request.
Thanks!
^ permalink raw reply
* Re: [PATCH] Bluetooth: Support for new firmware for ath3k USB Bluetooth device
From: David Vrabel @ 2010-10-05 7:01 UTC (permalink / raw)
To: Suraj Sumangala; +Cc: linux-bluetooth, Jothikumar.Mothilal
In-Reply-To: <1286259436-25424-1-git-send-email-suraj@atheros.com>
On 05/10/2010 07:17, Suraj Sumangala wrote:
> This patch add support for new ath3k USB Bluetooth device firmare.
> The firmware implements shared antenna support and
> fixes few critical bugs.
[...]
> static int ath3k_probe(struct usb_interface *intf,
> const struct usb_device_id *id)
> {
> @@ -110,6 +113,8 @@ static int ath3k_probe(struct usb_interface *intf,
> struct usb_device *udev = interface_to_usbdev(intf);
> struct ath3k_data *data;
> int size;
> + int i;
> + char fw_file[MAXPATHLEN]
Suggest FW_PATH_LEN here to avoid confusion as most people would expect
MAXPATHLEN to be enormous.
> BT_DBG("intf %p id %p", intf, id);
>
> @@ -122,7 +127,16 @@ static int ath3k_probe(struct usb_interface *intf,
>
> data->udev = udev;
>
> - if (request_firmware(&firmware, "ath3k-1.fw", &udev->dev) < 0) {
Why not request ath3k-1.fw (for backward compatibility) and ath3k.fw and
symlink this name to ath3k-2.fw or any future version of firmware?
I think users should be able to update firmware without a kernel update
where possible.
David
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox