* [PATCH] Fix Headset Audio gateway SDP record.
From: Jaikumar Ganesh @ 2010-09-22 0:05 UTC (permalink / raw)
To: linux-bluetooth; +Cc: Jaikumar Ganesh
Headset Audio Gateway does not have the Supported Features
in the SDP records according to the HSP specification.
---
tools/sdptool.c | 6 +-----
1 files changed, 1 insertions(+), 5 deletions(-)
diff --git a/tools/sdptool.c b/tools/sdptool.c
index d06b159..140a46a 100644
--- a/tools/sdptool.c
+++ b/tools/sdptool.c
@@ -1477,8 +1477,7 @@ static int add_headset_ag(sdp_session_t *session, svc_info_t *si)
sdp_list_t *aproto, *proto[2];
sdp_record_t record;
uint8_t u8 = si->channel ? si->channel : 7;
- uint16_t u16 = 0x17;
- sdp_data_t *channel, *features;
+ sdp_data_t *channel;
uint8_t netid = si->network ? si->network : 0x01; // ???? profile document
sdp_data_t *network = sdp_data_alloc(SDP_UINT8, &netid);
int ret = 0;
@@ -1511,9 +1510,6 @@ static int add_headset_ag(sdp_session_t *session, svc_info_t *si)
proto[1] = sdp_list_append(proto[1], channel);
apseq = sdp_list_append(apseq, proto[1]);
- features = sdp_data_alloc(SDP_UINT16, &u16);
- sdp_attr_add(&record, SDP_ATTR_SUPPORTED_FEATURES, features);
-
aproto = sdp_list_append(0, apseq);
sdp_set_access_protos(&record, aproto);
--
1.6.5.7
^ permalink raw reply related
* Re: [PATCH] Fix Headset Audio gateway SDP record.
From: jaikumar Ganesh @ 2010-09-22 0:05 UTC (permalink / raw)
To: y; +Cc: linux-bluetooth, Jaikumar Ganesh
In-Reply-To: <4447611680690660620@unknownmsgid>
Please ignore. Sending again with a valid "to address".
On Tue, Sep 21, 2010 at 4:50 PM, <y@google.com> wrote:
> From: Jaikumar Ganesh <jaikumar@google.com>
>
> Headset Audio Gateway does not have the Supported Features
> in the SDP records according to the HSP specification.
> ---
> tools/sdptool.c | 6 +-----
> 1 files changed, 1 insertions(+), 5 deletions(-)
>
> diff --git a/tools/sdptool.c b/tools/sdptool.c
> index d06b159..140a46a 100644
> --- a/tools/sdptool.c
> +++ b/tools/sdptool.c
> @@ -1477,8 +1477,7 @@ static int add_headset_ag(sdp_session_t *session, svc_info_t *si)
> sdp_list_t *aproto, *proto[2];
> sdp_record_t record;
> uint8_t u8 = si->channel ? si->channel : 7;
> - uint16_t u16 = 0x17;
> - sdp_data_t *channel, *features;
> + sdp_data_t *channel;
> uint8_t netid = si->network ? si->network : 0x01; // ???? profile document
> sdp_data_t *network = sdp_data_alloc(SDP_UINT8, &netid);
> int ret = 0;
> @@ -1511,9 +1510,6 @@ static int add_headset_ag(sdp_session_t *session, svc_info_t *si)
> proto[1] = sdp_list_append(proto[1], channel);
> apseq = sdp_list_append(apseq, proto[1]);
>
> - features = sdp_data_alloc(SDP_UINT16, &u16);
> - sdp_attr_add(&record, SDP_ATTR_SUPPORTED_FEATURES, features);
> -
> aproto = sdp_list_append(0, apseq);
> sdp_set_access_protos(&record, aproto);
>
> --
> 1.6.5.7
>
> --
> 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
* Fw: 2.6.35.4 + rfcomm -> segfault
From: Andrew Morton @ 2010-09-21 23:52 UTC (permalink / raw)
To: linux-bluetooth; +Cc: Martin Pirker
Begin forwarded message:
Date: Mon, 30 Aug 2010 10:00:37 +0200
From: Martin Pirker <lkml.collector@gmail.com>
To: LKML <linux-kernel@vger.kernel.org>
Subject: 2.6.35.4 + rfcomm -> segfault
Hi...
given a Notebook with Bluetooth connection to mobile phone for GPRS Internet:
Aug 28 11:43:16 h kernel: [ 1520.976793] general protection fault:
0000 [#1] SMP
Aug 28 11:43:16 h kernel: [ 1520.976802] last sysfs file:
/sys/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:09/PNP0C09:00/PNP0C0A:00/power_supply/BAT0/curre
nt_now
Aug 28 11:43:16 h kernel: [ 1520.976808] CPU 1
Aug 28 11:43:16 h kernel: [ 1520.976811] Modules linked in:
ppp_deflate zlib_deflate bsd_comp ppp_async crc_ccitt sco bridge stp
bnep rfcomm l2cap joydev arc4 iw
lagn i915 iwlcore snd_hda_codec_intelhdmi snd_hda_codec_conexant
mac80211 drm_kms_helper snd_hda_intel snd_hda_codec drm btusb
snd_hwdep bluetooth cfg80211 snd_pcm p
smouse pcspkr snd_timer serio_raw thinkpad_acpi tpm_tis i2c_i801 snd
iTCO_wdt led_class tpm tpm_bios nvram e1000e soundcore
iTCO_vendor_support snd_page_alloc i2c_al
go_bit cfbcopyarea intel_agp cfbimgblt cfbfillrect video
Aug 28 11:43:16 h kernel: [ 1520.976897]
Aug 28 11:43:16 h kernel: [ 1520.976902] Pid: 4223, comm: wvdial Not
tainted 2.6.35.4 #1 5413A13/5413A13
Aug 28 11:43:16 h kernel: [ 1520.976907] RIP:
0010:[<ffffffff8147b0fd>] [<ffffffff8147b0fd>]
sock_sendmsg+0xed/0x120
Aug 28 11:43:16 h kernel: [ 1520.976921] RSP: 0018:ffff880130ea78a8
EFLAGS: 00010246
Aug 28 11:43:16 h kernel: [ 1520.976925] RAX: dead4ead00002020 RBX:
ffff8801379c9140 RCX: 0000000000000004
Aug 28 11:43:16 h kernel: [ 1520.976929] RDX: ffff880130ea7a48 RSI:
ffff8801379c9140 RDI: ffff880130ea78a8
Aug 28 11:43:16 h kernel: [ 1520.976934] RBP: ffff880130ea7a18 R08:
0000000000000004 R09: ffff8801379c9140
Aug 28 11:43:16 h kernel: [ 1520.976938] R10: 0000000000000001 R11:
2222222222222222 R12: ffff880130ea7a48
Aug 28 11:43:16 h kernel: [ 1520.976942] R13: 0000000000000004 R14:
ffff880132695000 R15: ffff88012e0bc870
Aug 28 11:43:16 h kernel: [ 1520.976947] FS: 00007ff03bb66720(0000)
GS:ffff880002680000(0000) knlGS:0000000000000000
Aug 28 11:43:16 h kernel: [ 1520.976952] CS: 0010 DS: 0000 ES: 0000
CR0: 0000000080050033
Aug 28 11:43:16 h kernel: [ 1520.976956] CR2: 00007f5edee18000 CR3:
000000012bdfb000 CR4: 00000000000006e0
Aug 28 11:43:16 h kernel: [ 1520.976961] DR0: 0000000000000000 DR1:
0000000000000000 DR2: 0000000000000000
Aug 28 11:43:16 h kernel: [ 1520.976965] DR3: 0000000000000000 DR6:
00000000ffff0ff0 DR7: 0000000000000400
Aug 28 11:43:16 h kernel: [ 1520.976970] Process wvdial (pid: 4223,
threadinfo ffff880130ea6000, task ffff88013060bfc0)
Aug 28 11:43:16 h kernel: [ 1520.976974] Stack:
Aug 28 11:43:16 h kernel: [ 1520.976976] 0000000000015cc0
0000000000015cc0 0000000000000000 ffffffff00000001
Aug 28 11:43:16 h kernel: [ 1520.976984] <0> 0000000000000000
0000000000000000 0000000000000000 0000000000000000
Aug 28 11:43:16 h kernel: [ 1520.976993] <0> 0000000000000000
ffff88013060bfc0 0000000000000000 0000000000000931
Aug 28 11:43:16 h kernel: [ 1520.977003] Call Trace:
Aug 28 11:43:16 h kernel: [ 1520.977013] [<ffffffff8147b171>]
kernel_sendmsg+0x41/0x60
Aug 28 11:43:16 h kernel: [ 1520.977022] [<ffffffffa014314b>]
rfcomm_send_frame+0x3b/0x40 [rfcomm]
Aug 28 11:43:16 h kernel: [ 1520.977030] [<ffffffffa01431b3>]
rfcomm_send_disc+0x63/0x70 [rfcomm]
Aug 28 11:43:16 h kernel: [ 1520.977038] [<ffffffffa014429c>]
__rfcomm_dlc_close+0x25c/0x2b0 [rfcomm]
Aug 28 11:43:16 h kernel: [ 1520.977048] [<ffffffff81583d05>] ?
mutex_lock_nested+0x35/0x40
Aug 28 11:43:16 h kernel: [ 1520.977055] [<ffffffffa0144555>]
rfcomm_dlc_close+0x35/0x50 [rfcomm]
Aug 28 11:43:16 h kernel: [ 1520.977064] [<ffffffffa0148a8e>]
rfcomm_tty_close+0x4e/0x100 [rfcomm]
Aug 28 11:43:16 h kernel: [ 1520.977071] [<ffffffff813530ee>]
tty_release+0x17e/0x720
Aug 28 11:43:16 h kernel: [ 1520.977080] [<ffffffff812be59e>] ?
do_raw_spin_unlock+0x5e/0xb0
Aug 28 11:43:16 h kernel: [ 1520.977088] [<ffffffff81585aab>] ?
_raw_spin_unlock+0x2b/0x40
Aug 28 11:43:16 h kernel: [ 1520.977096] [<ffffffffa0148d83>] ?
rfcomm_tty_open+0x243/0x330 [rfcomm]
Aug 28 11:43:16 h kernel: [ 1520.977105] [<ffffffff810502c0>] ?
default_wake_function+0x0/0x20
Aug 28 11:43:16 h kernel: [ 1520.977111] [<ffffffff813544be>]
tty_open+0x52e/0x600
Aug 28 11:43:16 h kernel: [ 1520.977121] [<ffffffff8114fd27>]
chrdev_open+0xf7/0x210
Aug 28 11:43:16 h kernel: [ 1520.977128] [<ffffffff81585aab>] ?
_raw_spin_unlock+0x2b/0x40
Aug 28 11:43:16 h kernel: [ 1520.977134] [<ffffffff8114fc30>] ?
chrdev_open+0x0/0x210
Aug 28 11:43:16 h kernel: [ 1520.977141] [<ffffffff8114a4f4>]
__dentry_open+0xe4/0x330
Aug 28 11:43:16 h kernel: [ 1520.977150] [<ffffffff81286708>] ?
devcgroup_inode_permission+0x48/0x190
Aug 28 11:43:16 h kernel: [ 1520.977160] [<ffffffff8125c34f>] ?
security_inode_permission+0x1f/0x30
Aug 28 11:43:16 h kernel: [ 1520.977167] [<ffffffff8114a854>]
nameidata_to_filp+0x54/0x70
Aug 28 11:43:16 h kernel: [ 1520.977173] [<ffffffff81158445>]
do_last+0x3e5/0x720
Aug 28 11:43:16 h kernel: [ 1520.977180] [<ffffffff8115a867>]
do_filp_open+0x207/0x680
Aug 28 11:43:16 h kernel: [ 1520.977186] [<ffffffff812be59e>] ?
do_raw_spin_unlock+0x5e/0xb0
Aug 28 11:43:16 h kernel: [ 1520.977193] [<ffffffff81585aab>] ?
_raw_spin_unlock+0x2b/0x40
Aug 28 11:43:16 h kernel: [ 1520.977201] [<ffffffff81165e6a>] ?
alloc_fd+0xfa/0x140
Aug 28 11:43:16 h kernel: [ 1520.977207] [<ffffffff8114a2c9>]
do_sys_open+0x69/0x140
Aug 28 11:43:16 h kernel: [ 1520.977214] [<ffffffff81585062>] ?
trace_hardirqs_on_thunk+0x3a/0x3f
Aug 28 11:43:16 h kernel: [ 1520.977220] [<ffffffff8114a3e0>]
sys_open+0x20/0x30
Aug 28 11:43:16 h kernel: [ 1520.977229] [<ffffffff8100b072>]
system_call_fastpath+0x16/0x1b
Aug 28 11:43:16 h kernel: [ 1520.977233] Code: ad 74 ff ff ff 44 89 ea
4c 89 e6 48 89 df e8 7b 0c de ff 85 c0 75 1a 48 8b 43 28 48 8d bd 90
fe ff ff 4c 89 e9 4c 89 e2 48 89 de <ff> 90 88 00 00 00 3d ef fd ff ff
74 16 48 8b 5d e8 4c 8b 65 f0
Aug 28 11:43:16 h kernel: [ 1520.977313] RIP [<ffffffff8147b0fd>]
sock_sendmsg+0xed/0x120
Aug 28 11:43:16 h kernel: [ 1520.977319] RSP <ffff880130ea78a8>
Aug 28 11:43:16 h kernel: [ 1520.977325] ---[ end trace b38fcf1132041c2a ]---
I remember this happened also on older kernels, but so far it happens
so rarely I didn't bother.
Maybe the stack trace is of help to you...
Martin
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
^ permalink raw reply
* [PATCH] Fix Headset Audio gateway SDP record.
From: y @ 2010-09-21 23:50 UTC (permalink / raw)
To: linux-bluetooth; +Cc: Jaikumar Ganesh
From: Jaikumar Ganesh <jaikumar@google.com>
Headset Audio Gateway does not have the Supported Features
in the SDP records according to the HSP specification.
---
tools/sdptool.c | 6 +-----
1 files changed, 1 insertions(+), 5 deletions(-)
diff --git a/tools/sdptool.c b/tools/sdptool.c
index d06b159..140a46a 100644
--- a/tools/sdptool.c
+++ b/tools/sdptool.c
@@ -1477,8 +1477,7 @@ static int add_headset_ag(sdp_session_t *session, svc_info_t *si)
sdp_list_t *aproto, *proto[2];
sdp_record_t record;
uint8_t u8 = si->channel ? si->channel : 7;
- uint16_t u16 = 0x17;
- sdp_data_t *channel, *features;
+ sdp_data_t *channel;
uint8_t netid = si->network ? si->network : 0x01; // ???? profile document
sdp_data_t *network = sdp_data_alloc(SDP_UINT8, &netid);
int ret = 0;
@@ -1511,9 +1510,6 @@ static int add_headset_ag(sdp_session_t *session, svc_info_t *si)
proto[1] = sdp_list_append(proto[1], channel);
apseq = sdp_list_append(apseq, proto[1]);
- features = sdp_data_alloc(SDP_UINT16, &u16);
- sdp_attr_add(&record, SDP_ATTR_SUPPORTED_FEATURES, features);
-
aproto = sdp_list_append(0, apseq);
sdp_set_access_protos(&record, aproto);
--
1.6.5.7
^ permalink raw reply related
* [PATCH] Bluetooth: Fix deadlock in the ERTM logic
From: Gustavo F. Padovan @ 2010-09-21 21:20 UTC (permalink / raw)
To: netdev; +Cc: linux-bluetooth, linux-kernel, padovan, marcel, davem, mathewm
In-Reply-To: <1285104013-9946-1-git-send-email-padovan@profusion.mobi>
The Enhanced Retransmission Mode(ERTM) is a realiable mode of operation
of the Bluetooth L2CAP layer. Think on it like a simplified version of
TCP.
The problem we were facing here was a deadlock. ERTM uses a backlog
queue to queue incomimg packets while the user is helding the lock. The
problem is that at some moment the user doesn't have memory anymore to
do alloc new skbs and sleep with the lock to wait for memory, that
stalls the ERTM connection once we can't read the acknowledgements
packets in the backlog queue to free memory and make the allocation of
outcoming skb successful.
I'm thinking on this patch more like a proof of concept than a real fix
to the deadlock in ERTM.
Signed-off-by: Gustavo F. Padovan <padovan@profusion.mobi>
---
net/bluetooth/l2cap.c | 4 ++++
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/net/bluetooth/l2cap.c b/net/bluetooth/l2cap.c
index 44a8fb0..dd406b5 100644
--- a/net/bluetooth/l2cap.c
+++ b/net/bluetooth/l2cap.c
@@ -1633,7 +1633,9 @@ static inline int l2cap_skbuff_fromiovec(struct sock *sk, struct msghdr *msg, in
while (len) {
count = min_t(unsigned int, conn->mtu, len);
+ release_sock(sk);
*frag = bt_skb_send_alloc(sk, count, msg->msg_flags & MSG_DONTWAIT, &err);
+ lock_sock(sk);
if (!*frag)
return -EFAULT;
if (memcpy_fromiovec(skb_put(*frag, count), msg->msg_iov, count))
@@ -1724,8 +1726,10 @@ static struct sk_buff *l2cap_create_iframe_pdu(struct sock *sk, struct msghdr *m
hlen += 2;
count = min_t(unsigned int, (conn->mtu - hlen), len);
+ release_sock(sk);
skb = bt_skb_send_alloc(sk, count + hlen,
msg->msg_flags & MSG_DONTWAIT, &err);
+ lock_sock(sk);
if (!skb)
return ERR_PTR(-ENOMEM);
--
1.7.3
^ permalink raw reply related
* Deadlock in Bluetooth code in 2.6.36
From: Gustavo F. Padovan @ 2010-09-21 21:20 UTC (permalink / raw)
To: netdev; +Cc: linux-bluetooth, linux-kernel, padovan, marcel, davem, mathewm
Hi,
I would like to discuss here a problem we are having in the Bluetooth Layer.
There we have the Enhanced Retransmission Mode(ERTM) which is a reliable mode
of operation of the Bluetooth L2CAP layer. Think on it like a simplified
version of TCP.
The problem we were facing was a deadlock. ERTM uses a backlog queue to
queue incoming packets while the user held the lock. The problem is that
at some moment the user doesn't have memory anymore to alloc new skbs and
sleeps to wait for memory with the lock held, that stalls the ERTM connection
because we can't read the acknowledgements packets in the backlog queue to
free memory and then make the allocation of outcoming skb successful.
Looks like the solution to this issue is release the lock before go to sleep
waiting for memory and then lock the sock lock again when we wake up and have
memory. That's the solution TCP does through sk_stream_alloc_skb() and
sk_stream_wait_memory(). The sock lock is released and locked again inside
sk_wait_event() macro.
For bluetooth we do that in different way, we alloc memory through
sock_alloc_send_skb() which differently from sk_stream_alloc_skb() sleeps
with the lock held when waiting for memory.
The following patch is more like a proof of concept that sleeping
without the lock fixes the problem for L2CAP. Mat Martineau also found out
that some time ago.
My questions here is on how to fix this properly. Maybe
sock_alloc_send_skb() should not be used with SOCK_STREAM and reliable
protocols and I'm not aware of that? And should I use something like
sk_stream_alloc_skb() instead?
Any comments are welcome. With lucky we can fix that for 2.6.36 and
together with others fixes we have queued deliver a fully functional
L2CAP layer on 2.6.36.
Thanks,
---
Gustavo F. Padovan (1):
Bluetooth: Fix deadlock in the ERTM logic
net/bluetooth/l2cap.c | 4 ++++
1 files changed, 4 insertions(+), 0 deletions(-)
^ permalink raw reply
* Re: [PATCH] Simplify linker script
From: Lucas De Marchi @ 2010-09-21 20:41 UTC (permalink / raw)
To: Lucas De Marchi, linux-bluetooth, barbieri
In-Reply-To: <20100921201402.GA29547@jh-x301>
On Tue, Sep 21, 2010 at 5:14 PM, Johan Hedberg <johan.hedberg@gmail.com> wrote:
> Thanks for the patch. It has been pushed to the upstream tree. Could you
> provide one for obexd too?
It seems that obexd does not have a linker script like connman, ofono
and bluez. Which functions should I export in that case?
Regards
Lucas De Marchi
^ permalink raw reply
* Re: Need complete docs on PAN and DUN with bluez 4.66
From: Mumia W @ 2010-09-21 20:21 UTC (permalink / raw)
To: list-linux-bluetooth
>From: Arun Kumar <arunkat@gmail.com>
>
>[...] Alternatively if the use case is to simply set up the device in
>nap role with bluez, for instance,
>pand -s -r NAP -M -n could well be used. It would set up the device
>in NAP role after auto registering same with SDP.
>
>[...]
Thanks. I'm hoping that "pand" isn't the only way for an
end-user to do that.
--
^ permalink raw reply
* Re: Need complete docs on PAN and DUN with bluez 4.66
From: Mumia W @ 2010-09-21 20:16 UTC (permalink / raw)
To: list-linux-bluetooth
>From: Luiz Augusto von Dentz <luiz.dentz@gmail.com>
>Sent: Sep 21, 2010 6:06 AM
>To: Arun Kumar <arunkat@gmail.com>
>Cc: Mumia W <mumia.w.18.spam@earthlink.net>, linux-bluetooth@vger.kernel.org
>Subject: Re: Need complete docs on PAN and DUN with bluez 4.66
>
>Hi,
>
>On Tue, Sep 21, 2010 at 6:56 AM, Arun Kumar <arunkat@gmail.com> wrote:
>> Depends on what role you want to use pand for ...pand is launched as a
>> daemon via command line with set of options you may want to use it for
>> your requirements ...
>
>I wouldn't suggest using pand nor dund because they are deprecated.
>
>PAN is really dead simple, Network.Connect() returns the network
>interface in case of success and both NetworkManager and connman
>should be able to use them, in fact I think both already have specif
>PAN support to connect from their ui.
>
I'm not using Network manager. How do I enable PAN from the command line? I'm an end-user right now.
>DUN is a bit more complicated, it rely on Serial.Connect("dun") which
>creates a RFCOMM port to talk to the modem, but there need to be some
>process that has an AT command engine to handle all the configuration,
>in NetworkManager case there is ModemManager that is supposed to do
>that but I have tried not long ago and it failed for me, I think we
>might want to have ofono to handle this in connman case
What is ofono?
>but so far
>there the support for this is not complete (Gustavo Padovan has been
>working on it).
>
>Both Network and Serial interface are documented in doc/ diretory,
>there is also test-network and test-serial under test/ that can be
>used to manually connect to those profiles.
>
Thank you.
--
^ permalink raw reply
* Re: [PATCH] Simplify linker script
From: Johan Hedberg @ 2010-09-21 20:14 UTC (permalink / raw)
To: Lucas De Marchi; +Cc: linux-bluetooth, barbieri
In-Reply-To: <1285094816-1683-1-git-send-email-lucas.demarchi@profusion.mobi>
Hi Lucas,
On Tue, Sep 21, 2010, Lucas De Marchi wrote:
> Version linker scripts support function names and globs, so there's no
> need to rely on nm tool to gather the exported symbols.
> ---
> .gitignore | 1 -
> Makefile.am | 14 +-------------
> configure.ac | 2 +-
> src/bluetooth.ver.in | 10 ++++++++++
> 4 files changed, 12 insertions(+), 15 deletions(-)
> create mode 100644 src/bluetooth.ver.in
Thanks for the patch. It has been pushed to the upstream tree. Could you
provide one for obexd too?
Johan
^ permalink raw reply
* Re: [PATCH 2/2] Bluetooth: support to send power management enable during hci open
From: Pavan Savoy @ 2010-09-21 19:52 UTC (permalink / raw)
To: Suraj Sumangala; +Cc: linux-bluetooth, Jothikumar.Mothilal
In-Reply-To: <1285075981-8941-2-git-send-email-suraj@atheros.com>
On Tue, Sep 21, 2010 at 8:33 AM, Suraj Sumangala <suraj@atheros.com> wrote:
> This patch enables HCI_UART_ATH3K transport driver to support
> sending Vendor specific hci commands during hci open
> to enable or disable power management feature.
Why? shouldn't this be done from the hciattach? like for the other
manufacturers?
If you want it to be sent before hci0 interface is exposed, send it
over ttyXX, you have your _init function and if you require it to be
sent after the hci0 is exposed - do it in the _post function.
> Signed-off-by: Suraj Sumangala <suraj@atheros.com>
> ---
> drivers/bluetooth/hci_ath.c | 59 +++++++++++++++++++++++++++++++++++++++++++
> 1 files changed, 59 insertions(+), 0 deletions(-)
>
> diff --git a/drivers/bluetooth/hci_ath.c b/drivers/bluetooth/hci_ath.c
> index 6a160c1..d4b0653 100644
> --- a/drivers/bluetooth/hci_ath.c
> +++ b/drivers/bluetooth/hci_ath.c
> @@ -49,6 +49,37 @@ struct ath_struct {
> struct work_struct ctxtsw;
> };
>
> +/* Form HCI command */
> +static struct sk_buff *form_hci_cmd(struct hci_dev *hdev, __u16 opcode,
> + __u32 plen, void *param)
> +{
> + int len = HCI_COMMAND_HDR_SIZE + plen;
> + struct hci_command_hdr *hdr;
> + struct sk_buff *skb;
> +
> + BT_DBG("%s opcode 0x%x plen %d", hdev->name, opcode, plen);
> +
> + skb = bt_skb_alloc(len, GFP_ATOMIC);
> + if (!skb) {
> + BT_ERR("%s no memory for command", hdev->name);
> + return NULL;
> + }
> +
> + hdr = (struct hci_command_hdr *) skb_put(skb, HCI_COMMAND_HDR_SIZE);
> + hdr->opcode = cpu_to_le16(opcode);
> + hdr->plen = plen;
> +
> + if (plen)
> + memcpy(skb_put(skb, plen), param, plen);
> +
> + BT_DBG("skb len %d", skb->len);
> +
> + bt_cb(skb)->pkt_type = HCI_COMMAND_PKT;
> + skb->dev = (void *) hdev;
> +
> + return skb;
> +}
> +
> static int ath_wakeup_ar3k(struct tty_struct *tty)
> {
> struct termios settings;
> @@ -81,6 +112,26 @@ static int ath_wakeup_ar3k(struct tty_struct *tty)
> return status;
> }
>
> +#define HCI_OP_SLEEP_SET 0xFC04
> +static void ath_hci_init_driver(struct hci_uart *hu)
> +{
> + struct ath_struct *ath = hu->priv;
> + struct hci_dev *hdev = hu->hdev;
> + struct sk_buff *skb;
> +
> + if (!hdev)
> + return;
> +
> + if (!ath)
> + return;
> +
> + skb = form_hci_cmd(hdev, HCI_OP_SLEEP_SET, 1, &ath->cur_sleep);
> + if (!skb)
> + return;
> +
> + skb_queue_head(&hdev->driver_init, skb);
> +}
> +
> static void ath_hci_uart_work(struct work_struct *work)
> {
> int status;
> @@ -126,6 +177,13 @@ static int ath_open(struct hci_uart *hu)
> return 0;
> }
>
> +static int ath_hci_open(struct hci_uart *hu)
> +{
> + ath_hci_init_driver(hu);
> +
> + return 0;
> +}
> +
> /* Flush protocol data */
> static int ath_flush(struct hci_uart *hu)
> {
> @@ -210,6 +268,7 @@ static int ath_recv(struct hci_uart *hu, void *data, int count)
> static struct hci_uart_proto athp = {
> .id = HCI_UART_ATH3K,
> .open = ath_open,
> + .hci_open = ath_hci_open,
> .close = ath_close,
> .recv = ath_recv,
> .enqueue = ath_enqueue,
> --
> 1.7.0.4
>
> --
> 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
* [PATCH] Simplify linker script
From: Lucas De Marchi @ 2010-09-21 18:46 UTC (permalink / raw)
To: linux-bluetooth; +Cc: barbieri, Lucas De Marchi
Version linker scripts support function names and globs, so there's no
need to rely on nm tool to gather the exported symbols.
---
.gitignore | 1 -
Makefile.am | 14 +-------------
configure.ac | 2 +-
src/bluetooth.ver.in | 10 ++++++++++
4 files changed, 12 insertions(+), 15 deletions(-)
create mode 100644 src/bluetooth.ver.in
diff --git a/.gitignore b/.gitignore
index e12508e..db6c3f3 100644
--- a/.gitignore
+++ b/.gitignore
@@ -34,7 +34,6 @@ bluez.pc
lib/bluetooth
src/builtin.h
src/bluetoothd
-src/bluetooth.exp
src/bluetooth.ver
audio/telephony.c
scripts/bluetooth.rules
diff --git a/Makefile.am b/Makefile.am
index 05bc8fc..1c70e5d 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -258,7 +258,7 @@ builtin_files = src/builtin.h $(builtin_nodist)
nodist_src_bluetoothd_SOURCES = $(builtin_files)
-CLEANFILES += src/bluetooth.ver src/bluetooth.exp $(builtin_files)
+CLEANFILES += $(builtin_files)
man_MANS = src/bluetoothd.8
@@ -392,18 +392,6 @@ src/plugin.$(OBJEXT): src/builtin.h
src/builtin.h: src/genbuiltin $(builtin_sources)
$(AM_V_GEN)$(srcdir)/src/genbuiltin $(builtin_modules) > $@
-src/bluetooth.exp: $(src_bluetoothd_OBJECTS)
- $(AM_V_GEN)$(NM) $^ | $(AWK) '{ print $$3 }' | sort -u | \
- $(EGREP) -e '^btd_' -e '^g_dbus_' > $@
- $(AM_V_at)echo -e "info" >> $@
- $(AM_V_at)echo -e "error" >> $@
- $(AM_V_at)echo -e "debug" >> $@
-
-src/bluetooth.ver: src/bluetooth.exp
- $(AM_V_at)echo "{ global:" > $@
- $(AM_V_GEN)$(SED) -e "s/\(.*\)/\1;/" $< >> $@
- $(AM_V_at)echo "local: *; };" >> $@
-
audio/telephony.c: audio/@TELEPHONY_DRIVER@
$(AM_V_GEN)$(LN_S) $(abs_top_srcdir)/$< $@
diff --git a/configure.ac b/configure.ac
index 6fda7fe..08f4877 100644
--- a/configure.ac
+++ b/configure.ac
@@ -65,5 +65,5 @@ if (test "${enable_netlink}" = "yes"); then
fi
AM_CONDITIONAL(NETLINK, test "${enable_netlink}" = "yes")
-AC_OUTPUT(Makefile scripts/bluetooth.rules doc/version.xml
+AC_OUTPUT(Makefile scripts/bluetooth.rules doc/version.xml src/bluetooth.ver
src/bluetoothd.8 bluez.pc)
diff --git a/src/bluetooth.ver.in b/src/bluetooth.ver.in
new file mode 100644
index 0000000..b71c70d
--- /dev/null
+++ b/src/bluetooth.ver.in
@@ -0,0 +1,10 @@
+{
+ global:
+ btd_*;
+ g_dbus_*;
+ info;
+ error;
+ debug;
+ local:
+ *;
+};
--
1.7.2.3
^ permalink raw reply related
* Re: Need complete docs on PAN and DUN with bluez 4.66
From: Arun Kumar @ 2010-09-21 18:16 UTC (permalink / raw)
To: Luiz Augusto von Dentz; +Cc: Mumia W, linux-bluetooth
In-Reply-To: <AANLkTikwvCiCLj4Hvr=zSQHOm33e059z2W6MA0T5C2ZO@mail.gmail.com>
Hi,
> Hi,
>
> On Tue, Sep 21, 2010 at 6:56 AM, Arun Kumar <arunkat@gmail.com> wrote:
>> Depends on what role you want to use pand for ...pand is launched as a
>> daemon via command line with set of options you may want to use it for
>> your requirements ...
>
> I wouldn't suggest using pand nor dund because they are deprecated.
I understand that dun and its apis are deprecated from bluez but not
sure on pan. I guess its api's are still exported on dbus as network
api's- unless there are plans to deprecate it too in near future...
> PAN is really dead simple, Network.Connect() returns the network
> interface in case of success
isnt it what Network.Connect() is supposed to return?
>and both NetworkManager and connman
> should be able to use them, in fact I think both already have specif
> PAN support to connect from their ui.
Well its entirely upto to the use-case & sub-system above d-bus on how
to use network api's and implement pan. In case of Meego and ui based
PAN use case, it may be true, but there are still platforms and
subsystems that use vanilla pand to setup pan as GN/nap etc via a
daemon process.
> Both Network and Serial interface are documented in doc/ diretory,
> there is also test-network and test-serial under test/ that can be
> used to manually connect to those profiles.
True. Alternatively if the use case is to simply set up the device in
nap role with bluez, for instance,
pand -s -r NAP -M -n could well be used. It would set up the device
in NAP role after auto registering same with SDP.
> Luiz Augusto von Dentz
> Computer Engineer
>
Best Regards,
Arun Kumar Singh
www.crazydaks.com
^ permalink raw reply
* Re: [PATCH] Fixes potential lockup while finding latency
From: Johan Hedberg @ 2010-09-21 18:09 UTC (permalink / raw)
To: Elvis Pfützenreuter; +Cc: linux-bluetooth
In-Reply-To: <1285087553-11868-1-git-send-email-epx@signove.com>
Hi Elvis,
On Tue, Sep 21, 2010, Elvis Pfützenreuter wrote:
> (To be applied after Jose reorganization patch)
>
> This patch fixes a potential infinite loop while finding the
> BT/system clock read latency. If the adapter is removed exactly
> at that moment, BT clock simply can't be read and it must quit.
> This is handled as a temporary failure (if a new connection is
> made, adapter is probably in place again).
> ---
> health/mcap_sync.c | 46 ++++++++++++++++++++++++++++++++++++++++------
> 1 files changed, 40 insertions(+), 6 deletions(-)
Thanks. This patch has also been pushed upstream. In the future please
use the format "Fix ..." instead of "Fixes ..." in the summary message
to be consistent with the rest of the commit history. I changed it
manually this time before pushing upstream.
Johan
^ permalink raw reply
* Re: [PATCH] Code reorganization to avoid unnecessary forward declarations
From: Johan Hedberg @ 2010-09-21 18:04 UTC (permalink / raw)
To: Jose Antonio Santos Cadenas; +Cc: linux-bluetooth
In-Reply-To: <1285083152-27170-1-git-send-email-santoscadenas@gmail.com>
Hi,
On Tue, Sep 21, 2010, Jose Antonio Santos Cadenas wrote:
> ---
> health/mcap_sync.c | 355 +++++++++++++++++++++++++---------------------------
> 1 files changed, 173 insertions(+), 182 deletions(-)
Thanks. The patch is now upstream.
Johan
^ permalink raw reply
* [PATCH] Fixes potential lockup while finding latency
From: Elvis Pfützenreuter @ 2010-09-21 16:45 UTC (permalink / raw)
To: linux-bluetooth; +Cc: epx
(To be applied after Jose reorganization patch)
This patch fixes a potential infinite loop while finding the
BT/system clock read latency. If the adapter is removed exactly
at that moment, BT clock simply can't be read and it must quit.
This is handled as a temporary failure (if a new connection is
made, adapter is probably in place again).
---
health/mcap_sync.c | 46 ++++++++++++++++++++++++++++++++++++++++------
1 files changed, 40 insertions(+), 6 deletions(-)
diff --git a/health/mcap_sync.c b/health/mcap_sync.c
index 0943e41..670260b 100644
--- a/health/mcap_sync.c
+++ b/health/mcap_sync.c
@@ -360,7 +360,7 @@ uint32_t mcap_get_btclock(struct mcap_mcl *mcl)
return btclock;
}
-static void initialize_caps(struct mcap_mcl *mcl)
+static gboolean initialize_caps(struct mcap_mcl *mcl)
{
struct timespec t1, t2;
int latencies[20];
@@ -368,6 +368,7 @@ static void initialize_caps(struct mcap_mcl *mcl)
uint32_t btclock;
uint16_t btaccuracy;
int i;
+ int retries;
clock_getres(CLK, &t1);
@@ -383,10 +384,12 @@ static void initialize_caps(struct mcap_mcl *mcl)
/* Do clock read a number of times and measure latency */
avg = 0;
- for (i = 0; i < 20; ++i) {
+ retries = 10;
+ for (i = 0; i < 20 && retries > 0; ++i) {
clock_gettime(CLK, &t1);
if (!read_btclock(mcl, &btclock, &btaccuracy)) {
--i;
+ --retries;
continue;
}
clock_gettime(CLK, &t2);
@@ -395,9 +398,12 @@ static void initialize_caps(struct mcap_mcl *mcl)
latencies[i] = latency;
avg += latency;
}
- avg /= 20;
- /* Calculate deviation */
+ if (retries <= 0)
+ return FALSE;
+
+ /* Calculate average and deviation */
+ avg /= 20;
dev = 0;
for (i = 0; i < 20; ++i)
dev += abs(latencies[i] - avg);
@@ -418,12 +424,16 @@ static void initialize_caps(struct mcap_mcl *mcl)
_caps.syncleadtime_ms = latency * 50 / 1000;
csp_caps_initialized = TRUE;
+ return TRUE;
}
static struct csp_caps *caps(struct mcap_mcl *mcl)
{
if (!csp_caps_initialized)
- initialize_caps(mcl);
+ if (!initialize_caps(mcl)) {
+ /* Temporary failure in reading BT clock */
+ return NULL;
+ }
return &_caps;
}
@@ -465,6 +475,12 @@ static void proc_sync_cap_req(struct mcap_mcl *mcl, uint8_t *cmd, uint32_t len)
return;
}
+ if (!caps(mcl)) {
+ send_sync_cap_rsp(mcl, MCAP_RESOURCE_UNAVAILABLE,
+ 0, 0, 0, 0);
+ return;
+ }
+
req = (mcap_md_sync_cap_req *) cmd;
required_accuracy = ntohs(req->timest);
our_accuracy = caps(mcl)->ts_acc;
@@ -514,11 +530,16 @@ static gboolean get_all_clocks(struct mcap_mcl *mcl, uint32_t *btclock,
struct timespec *base_time,
uint64_t *timestamp)
{
- int latency = caps(mcl)->preempt_thresh + 1;
+ int latency;
int retry = 5;
uint16_t btres;
struct timespec t0;
+ if (!caps(mcl))
+ return FALSE;
+
+ latency = caps(mcl)->preempt_thresh + 1;
+
while (latency > caps(mcl)->preempt_thresh && --retry >= 0) {
clock_gettime(CLK, &t0);
@@ -553,6 +574,9 @@ static gboolean sync_send_indication(gpointer user_data)
mcl = user_data;
+ if (!caps(mcl))
+ return FALSE;
+
if (!get_all_clocks(mcl, &btclock, &base_time, &tmstamp))
return FALSE;
@@ -600,6 +624,11 @@ static gboolean proc_sync_set_req_phase2(gpointer user_data)
ind_freq = data->ind_freq;
role = data->role;
+ if (!caps(mcl)) {
+ send_sync_set_rsp(mcl, MCAP_UNSPECIFIED_ERROR, 0, 0, 0);
+ return FALSE;
+ }
+
if (!get_all_clocks(mcl, &btclock, &base_time, &tmstamp)) {
send_sync_set_rsp(mcl, MCAP_UNSPECIFIED_ERROR, 0, 0, 0);
return FALSE;
@@ -688,6 +717,11 @@ static void proc_sync_set_req(struct mcap_mcl *mcl, uint8_t *cmd, uint32_t len)
return;
}
+ if (!caps(mcl)) {
+ send_sync_set_rsp(mcl, MCAP_UNSPECIFIED_ERROR, 0, 0, 0);
+ return;
+ }
+
if (!read_btclock_retry(mcl, &cur_btclock, &btres)) {
send_sync_set_rsp(mcl, MCAP_UNSPECIFIED_ERROR, 0, 0, 0);
return;
--
1.7.0.4
^ permalink raw reply related
* [PATCH] Code reorganization to avoid unnecessary forward declarations
From: Jose Antonio Santos Cadenas @ 2010-09-21 15:32 UTC (permalink / raw)
To: linux-bluetooth; +Cc: Jose Antonio Santos Cadenas
In-Reply-To: <AANLkTi=L_iB7Evf9OdRxhVH+-dwdH8sdJ79Mu5tab8Oj@mail.gmail.com>
---
health/mcap_sync.c | 355 +++++++++++++++++++++++++---------------------------
1 files changed, 173 insertions(+), 182 deletions(-)
diff --git a/health/mcap_sync.c b/health/mcap_sync.c
index 25fc2d4..0943e41 100644
--- a/health/mcap_sync.c
+++ b/health/mcap_sync.c
@@ -111,15 +111,6 @@ static inline uint64_t ntoh64(uint64_t n)
static gboolean csp_caps_initialized = FALSE;
struct csp_caps _caps;
-static void proc_sync_cap_req(struct mcap_mcl *mcl, uint8_t *cmd, uint32_t len);
-static void proc_sync_set_req(struct mcap_mcl *mcl, uint8_t *cmd, uint32_t len);
-static void proc_sync_cap_rsp(struct mcap_mcl *mcl, uint8_t *cmd, uint32_t len);
-static void proc_sync_set_rsp(struct mcap_mcl *mcl, uint8_t *cmd, uint32_t len);
-static void proc_sync_info_ind(struct mcap_mcl *mcl, uint8_t *cmd, uint32_t len);
-
-static gboolean sync_send_indication(gpointer user_data);
-static gboolean proc_sync_set_req_phase2(gpointer user_data);
-
static int send_sync_cmd(struct mcap_mcl *mcl, const void *buf, uint32_t size)
{
int sock;
@@ -161,39 +152,6 @@ static int send_unsupported_set_req(struct mcap_mcl *mcl)
return sent;
}
-void proc_sync_cmd(struct mcap_mcl *mcl, uint8_t *cmd, uint32_t len)
-{
- if (!mcl->ms->csp_enabled || !mcl->csp) {
- switch (cmd[0]) {
- case MCAP_MD_SYNC_CAP_REQ:
- send_unsupported_cap_req(mcl);
- break;
- case MCAP_MD_SYNC_SET_REQ:
- send_unsupported_set_req(mcl);
- break;
- }
- return;
- }
-
- switch (cmd[0]) {
- case MCAP_MD_SYNC_CAP_REQ:
- proc_sync_cap_req(mcl, cmd, len);
- break;
- case MCAP_MD_SYNC_CAP_RSP:
- proc_sync_cap_rsp(mcl, cmd, len);
- break;
- case MCAP_MD_SYNC_SET_REQ:
- proc_sync_set_req(mcl, cmd, len);
- break;
- case MCAP_MD_SYNC_SET_RSP:
- proc_sync_set_rsp(mcl, cmd, len);
- break;
- case MCAP_MD_SYNC_INFO_IND:
- proc_sync_info_ind(mcl, cmd, len);
- break;
- }
-}
-
static void reset_tmstamp(struct mcap_csp *csp, struct timespec *base_time,
uint64_t new_tmstamp)
{
@@ -552,126 +510,6 @@ static int send_sync_set_rsp(struct mcap_mcl *mcl, uint8_t rspcode,
return sent;
}
-static void proc_sync_set_req(struct mcap_mcl *mcl, uint8_t *cmd, uint32_t len)
-{
- mcap_md_sync_set_req *req;
- uint32_t sched_btclock, cur_btclock;
- uint16_t btres;
- uint8_t update;
- uint64_t timestamp;
- struct sync_set_data *set_data;
- int phase2_delay, ind_freq, when;
-
- if (len != sizeof(mcap_md_sync_set_req)) {
- send_sync_set_rsp(mcl, MCAP_INVALID_PARAM_VALUE, 0, 0, 0);
- return;
- }
-
- req = (mcap_md_sync_set_req *) cmd;
- sched_btclock = ntohl(req->btclock);
- update = req->timestui;
- timestamp = ntoh64(req->timestst);
-
- if (sched_btclock != MCAP_BTCLOCK_IMMEDIATE &&
- !valid_btclock(sched_btclock)) {
- send_sync_set_rsp(mcl, MCAP_INVALID_PARAM_VALUE, 0, 0, 0);
- return;
- }
-
- if (update > 1) {
- send_sync_set_rsp(mcl, MCAP_INVALID_PARAM_VALUE, 0, 0, 0);
- return;
- }
-
- if (!mcl->csp->remote_caps) {
- /* Remote side did not ask our capabilities yet */
- send_sync_set_rsp(mcl, MCAP_INVALID_PARAM_VALUE, 0, 0, 0);
- return;
- }
-
- if (!read_btclock_retry(mcl, &cur_btclock, &btres)) {
- send_sync_set_rsp(mcl, MCAP_UNSPECIFIED_ERROR, 0, 0, 0);
- return;
- }
-
- if (sched_btclock == MCAP_BTCLOCK_IMMEDIATE)
- phase2_delay = 0;
- else {
- phase2_delay = btdiff(cur_btclock, sched_btclock);
-
- if (phase2_delay < 0) {
- /* can not reset in the past tense */
- send_sync_set_rsp(mcl, MCAP_INVALID_PARAM_VALUE,
- 0, 0, 0);
- return;
- }
-
- /* Convert to miliseconds */
- phase2_delay = bt2ms(phase2_delay);
-
- if (phase2_delay > 61*1000) {
- /* More than 60 seconds in the future */
- send_sync_set_rsp(mcl, MCAP_INVALID_PARAM_VALUE,
- 0, 0, 0);
- return;
- } else if (phase2_delay < caps(mcl)->latency / 1000) {
- /* Too fast for us to do in time */
- send_sync_set_rsp(mcl, MCAP_INVALID_PARAM_VALUE,
- 0, 0, 0);
- return;
- }
- }
-
- if (update) {
- /* Indication frequency: required accuracy divided by ours */
- /* Converted to milisseconds */
- ind_freq = (1000 * mcl->csp->rem_req_acc) / caps(mcl)->ts_acc;
-
- if (ind_freq < MAX(caps(mcl)->latency * 2 / 1000, 100)) {
- /* Too frequent, we can't handle */
- send_sync_set_rsp(mcl, MCAP_INVALID_PARAM_VALUE,
- 0, 0, 0);
- return;
- }
-
- DBG("CSP: indication every %dms", ind_freq);
- } else
- ind_freq = 0;
-
- if (mcl->csp->ind_timer) {
- /* Old indications are no longer sent */
- g_source_remove(mcl->csp->ind_timer);
- mcl->csp->ind_timer = 0;
- }
-
- if (!mcl->csp->set_data)
- mcl->csp->set_data = g_new0(struct sync_set_data, 1);
-
- set_data = (struct sync_set_data *) mcl->csp->set_data;
-
- set_data->update = update;
- set_data->sched_btclock = sched_btclock;
- set_data->timestamp = timestamp;
- set_data->ind_freq = ind_freq;
- set_data->role = get_btrole(mcl);
-
- /* TODO is there some way to schedule a call based directly on
- * a BT clock value, instead of this estimation that uses
- * the SO clock? */
-
- if (phase2_delay > 0) {
- when = phase2_delay + caps(mcl)->syncleadtime_ms;
- mcl->csp->set_timer = g_timeout_add(when,
- proc_sync_set_req_phase2,
- mcl);
- } else
- proc_sync_set_req_phase2(mcl);
-
- /* First indication is immediate */
- if (update)
- sync_send_indication(mcl);
-}
-
static gboolean get_all_clocks(struct mcap_mcl *mcl, uint32_t *btclock,
struct timespec *base_time,
uint64_t *timestamp)
@@ -701,6 +539,36 @@ static gboolean get_all_clocks(struct mcap_mcl *mcl, uint32_t *btclock,
return TRUE;
}
+static gboolean sync_send_indication(gpointer user_data)
+{
+ struct mcap_mcl *mcl;
+ mcap_md_sync_info_ind *cmd;
+ uint32_t btclock;
+ uint64_t tmstamp;
+ struct timespec base_time;
+ int sent;
+
+ if (!user_data)
+ return FALSE;
+
+ mcl = user_data;
+
+ if (!get_all_clocks(mcl, &btclock, &base_time, &tmstamp))
+ return FALSE;
+
+ cmd = g_new0(mcap_md_sync_info_ind, 1);
+
+ cmd->op = MCAP_MD_SYNC_INFO_IND;
+ cmd->btclock = htonl(btclock);
+ cmd->timestst = hton64(tmstamp);
+ cmd->timestsa = htons(caps(mcl)->latency);
+
+ sent = send_sync_cmd(mcl, cmd, sizeof(*cmd));
+ g_free(cmd);
+
+ return !sent;
+}
+
static gboolean proc_sync_set_req_phase2(gpointer user_data)
{
struct mcap_mcl *mcl;
@@ -783,34 +651,124 @@ static gboolean proc_sync_set_req_phase2(gpointer user_data)
return FALSE;
}
-static gboolean sync_send_indication(gpointer user_data)
+static void proc_sync_set_req(struct mcap_mcl *mcl, uint8_t *cmd, uint32_t len)
{
- struct mcap_mcl *mcl;
- mcap_md_sync_info_ind *cmd;
- uint32_t btclock;
- uint64_t tmstamp;
- struct timespec base_time;
- int sent;
+ mcap_md_sync_set_req *req;
+ uint32_t sched_btclock, cur_btclock;
+ uint16_t btres;
+ uint8_t update;
+ uint64_t timestamp;
+ struct sync_set_data *set_data;
+ int phase2_delay, ind_freq, when;
- if (!user_data)
- return FALSE;
+ if (len != sizeof(mcap_md_sync_set_req)) {
+ send_sync_set_rsp(mcl, MCAP_INVALID_PARAM_VALUE, 0, 0, 0);
+ return;
+ }
- mcl = user_data;
+ req = (mcap_md_sync_set_req *) cmd;
+ sched_btclock = ntohl(req->btclock);
+ update = req->timestui;
+ timestamp = ntoh64(req->timestst);
- if (!get_all_clocks(mcl, &btclock, &base_time, &tmstamp))
- return FALSE;
+ if (sched_btclock != MCAP_BTCLOCK_IMMEDIATE &&
+ !valid_btclock(sched_btclock)) {
+ send_sync_set_rsp(mcl, MCAP_INVALID_PARAM_VALUE, 0, 0, 0);
+ return;
+ }
- cmd = g_new0(mcap_md_sync_info_ind, 1);
+ if (update > 1) {
+ send_sync_set_rsp(mcl, MCAP_INVALID_PARAM_VALUE, 0, 0, 0);
+ return;
+ }
- cmd->op = MCAP_MD_SYNC_INFO_IND;
- cmd->btclock = htonl(btclock);
- cmd->timestst = hton64(tmstamp);
- cmd->timestsa = htons(caps(mcl)->latency);
+ if (!mcl->csp->remote_caps) {
+ /* Remote side did not ask our capabilities yet */
+ send_sync_set_rsp(mcl, MCAP_INVALID_PARAM_VALUE, 0, 0, 0);
+ return;
+ }
- sent = send_sync_cmd(mcl, cmd, sizeof(*cmd));
- g_free(cmd);
+ if (!read_btclock_retry(mcl, &cur_btclock, &btres)) {
+ send_sync_set_rsp(mcl, MCAP_UNSPECIFIED_ERROR, 0, 0, 0);
+ return;
+ }
- return !sent;
+ if (sched_btclock == MCAP_BTCLOCK_IMMEDIATE)
+ phase2_delay = 0;
+ else {
+ phase2_delay = btdiff(cur_btclock, sched_btclock);
+
+ if (phase2_delay < 0) {
+ /* can not reset in the past tense */
+ send_sync_set_rsp(mcl, MCAP_INVALID_PARAM_VALUE,
+ 0, 0, 0);
+ return;
+ }
+
+ /* Convert to miliseconds */
+ phase2_delay = bt2ms(phase2_delay);
+
+ if (phase2_delay > 61*1000) {
+ /* More than 60 seconds in the future */
+ send_sync_set_rsp(mcl, MCAP_INVALID_PARAM_VALUE,
+ 0, 0, 0);
+ return;
+ } else if (phase2_delay < caps(mcl)->latency / 1000) {
+ /* Too fast for us to do in time */
+ send_sync_set_rsp(mcl, MCAP_INVALID_PARAM_VALUE,
+ 0, 0, 0);
+ return;
+ }
+ }
+
+ if (update) {
+ /* Indication frequency: required accuracy divided by ours */
+ /* Converted to milisseconds */
+ ind_freq = (1000 * mcl->csp->rem_req_acc) / caps(mcl)->ts_acc;
+
+ if (ind_freq < MAX(caps(mcl)->latency * 2 / 1000, 100)) {
+ /* Too frequent, we can't handle */
+ send_sync_set_rsp(mcl, MCAP_INVALID_PARAM_VALUE,
+ 0, 0, 0);
+ return;
+ }
+
+ DBG("CSP: indication every %dms", ind_freq);
+ } else
+ ind_freq = 0;
+
+ if (mcl->csp->ind_timer) {
+ /* Old indications are no longer sent */
+ g_source_remove(mcl->csp->ind_timer);
+ mcl->csp->ind_timer = 0;
+ }
+
+ if (!mcl->csp->set_data)
+ mcl->csp->set_data = g_new0(struct sync_set_data, 1);
+
+ set_data = (struct sync_set_data *) mcl->csp->set_data;
+
+ set_data->update = update;
+ set_data->sched_btclock = sched_btclock;
+ set_data->timestamp = timestamp;
+ set_data->ind_freq = ind_freq;
+ set_data->role = get_btrole(mcl);
+
+ /* TODO is there some way to schedule a call based directly on
+ * a BT clock value, instead of this estimation that uses
+ * the SO clock? */
+
+ if (phase2_delay > 0) {
+ when = phase2_delay + caps(mcl)->syncleadtime_ms;
+ mcl->csp->set_timer = g_timeout_add(when,
+ proc_sync_set_req_phase2,
+ mcl);
+ } else
+ proc_sync_set_req_phase2(mcl);
+
+ /* First indication is immediate */
+ if (update)
+ sync_send_indication(mcl);
}
static void proc_sync_cap_rsp(struct mcap_mcl *mcl, uint8_t *cmd, uint32_t len)
@@ -937,6 +895,39 @@ static void proc_sync_info_ind(struct mcap_mcl *mcl, uint8_t *cmd, uint32_t len)
mcl->ms->mcl_sync_infoind_cb(mcl, &data);
}
+void proc_sync_cmd(struct mcap_mcl *mcl, uint8_t *cmd, uint32_t len)
+{
+ if (!mcl->ms->csp_enabled || !mcl->csp) {
+ switch (cmd[0]) {
+ case MCAP_MD_SYNC_CAP_REQ:
+ send_unsupported_cap_req(mcl);
+ break;
+ case MCAP_MD_SYNC_SET_REQ:
+ send_unsupported_set_req(mcl);
+ break;
+ }
+ return;
+ }
+
+ switch (cmd[0]) {
+ case MCAP_MD_SYNC_CAP_REQ:
+ proc_sync_cap_req(mcl, cmd, len);
+ break;
+ case MCAP_MD_SYNC_CAP_RSP:
+ proc_sync_cap_rsp(mcl, cmd, len);
+ break;
+ case MCAP_MD_SYNC_SET_REQ:
+ proc_sync_set_req(mcl, cmd, len);
+ break;
+ case MCAP_MD_SYNC_SET_RSP:
+ proc_sync_set_rsp(mcl, cmd, len);
+ break;
+ case MCAP_MD_SYNC_INFO_IND:
+ proc_sync_info_ind(mcl, cmd, len);
+ break;
+ }
+}
+
void mcap_sync_cap_req(struct mcap_mcl *mcl, uint16_t reqacc,
mcap_sync_cap_cb cb, gpointer user_data,
GError **err)
--
1.7.0.4
^ permalink raw reply related
* [PATCH 2/2] Bluetooth: support to send power management enable during hci open
From: Suraj Sumangala @ 2010-09-21 13:33 UTC (permalink / raw)
To: linux-bluetooth; +Cc: Jothikumar.Mothilal, Suraj Sumangala
In-Reply-To: <1285075981-8941-1-git-send-email-suraj@atheros.com>
This patch enables HCI_UART_ATH3K transport driver to support
sending Vendor specific hci commands during hci open
to enable or disable power management feature.
Signed-off-by: Suraj Sumangala <suraj@atheros.com>
---
drivers/bluetooth/hci_ath.c | 59 +++++++++++++++++++++++++++++++++++++++++++
1 files changed, 59 insertions(+), 0 deletions(-)
diff --git a/drivers/bluetooth/hci_ath.c b/drivers/bluetooth/hci_ath.c
index 6a160c1..d4b0653 100644
--- a/drivers/bluetooth/hci_ath.c
+++ b/drivers/bluetooth/hci_ath.c
@@ -49,6 +49,37 @@ struct ath_struct {
struct work_struct ctxtsw;
};
+/* Form HCI command */
+static struct sk_buff *form_hci_cmd(struct hci_dev *hdev, __u16 opcode,
+ __u32 plen, void *param)
+{
+ int len = HCI_COMMAND_HDR_SIZE + plen;
+ struct hci_command_hdr *hdr;
+ struct sk_buff *skb;
+
+ BT_DBG("%s opcode 0x%x plen %d", hdev->name, opcode, plen);
+
+ skb = bt_skb_alloc(len, GFP_ATOMIC);
+ if (!skb) {
+ BT_ERR("%s no memory for command", hdev->name);
+ return NULL;
+ }
+
+ hdr = (struct hci_command_hdr *) skb_put(skb, HCI_COMMAND_HDR_SIZE);
+ hdr->opcode = cpu_to_le16(opcode);
+ hdr->plen = plen;
+
+ if (plen)
+ memcpy(skb_put(skb, plen), param, plen);
+
+ BT_DBG("skb len %d", skb->len);
+
+ bt_cb(skb)->pkt_type = HCI_COMMAND_PKT;
+ skb->dev = (void *) hdev;
+
+ return skb;
+}
+
static int ath_wakeup_ar3k(struct tty_struct *tty)
{
struct termios settings;
@@ -81,6 +112,26 @@ static int ath_wakeup_ar3k(struct tty_struct *tty)
return status;
}
+#define HCI_OP_SLEEP_SET 0xFC04
+static void ath_hci_init_driver(struct hci_uart *hu)
+{
+ struct ath_struct *ath = hu->priv;
+ struct hci_dev *hdev = hu->hdev;
+ struct sk_buff *skb;
+
+ if (!hdev)
+ return;
+
+ if (!ath)
+ return;
+
+ skb = form_hci_cmd(hdev, HCI_OP_SLEEP_SET, 1, &ath->cur_sleep);
+ if (!skb)
+ return;
+
+ skb_queue_head(&hdev->driver_init, skb);
+}
+
static void ath_hci_uart_work(struct work_struct *work)
{
int status;
@@ -126,6 +177,13 @@ static int ath_open(struct hci_uart *hu)
return 0;
}
+static int ath_hci_open(struct hci_uart *hu)
+{
+ ath_hci_init_driver(hu);
+
+ return 0;
+}
+
/* Flush protocol data */
static int ath_flush(struct hci_uart *hu)
{
@@ -210,6 +268,7 @@ static int ath_recv(struct hci_uart *hu, void *data, int count)
static struct hci_uart_proto athp = {
.id = HCI_UART_ATH3K,
.open = ath_open,
+ .hci_open = ath_hci_open,
.close = ath_close,
.recv = ath_recv,
.enqueue = ath_enqueue,
--
1.7.0.4
^ permalink raw reply related
* [PATCH 1/2] Bluetooth: hci open callback for hci UART transport driver
From: Suraj Sumangala @ 2010-09-21 13:33 UTC (permalink / raw)
To: linux-bluetooth; +Cc: Jothikumar.Mothilal, Suraj Sumangala
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);
--
1.7.0.4
^ permalink raw reply related
* Re: [PATCH] Some code reordering in mcap_sync
From: Jose Antonio Santos Cadenas @ 2010-09-21 11:07 UTC (permalink / raw)
To: Jose Antonio Santos Cadenas, linux-bluetooth
In-Reply-To: <20100921110529.GA10156@jh-x301>
2010/9/21 Johan Hedberg <johan.hedberg@gmail.com>:
> Hi,
>
> On Tue, Sep 21, 2010, Jose Antonio Santos Cadenas wrote:
>> Declaration, defines and struct definitions are moved to the begining
>> of the file. Just for make the code more readable.
>> ---
>> health/mcap_sync.c | 86 +++++++++++++++++++++++++--------------------------
>> 1 files changed, 42 insertions(+), 44 deletions(-)
>
> Thanks, the patch is now upstream. While you're at it, please also
> remove any unnecessary forward declarations, like these:
Ok, I'll work on it.
>
>> +static void proc_sync_cap_req(struct mcap_mcl *mcl, uint8_t *cmd, uint32_t len);
>> +static void proc_sync_set_req(struct mcap_mcl *mcl, uint8_t *cmd, uint32_t len);
>> +static void proc_sync_cap_rsp(struct mcap_mcl *mcl, uint8_t *cmd, uint32_t len);
>> +static void proc_sync_set_rsp(struct mcap_mcl *mcl, uint8_t *cmd, uint32_t len);
>> +static void proc_sync_info_ind(struct mcap_mcl *mcl, uint8_t *cmd, uint32_t len);
>
> Only in very rare cases are forward declarations needed. Whenever
> possible order the functions so that the dependencies of a function are
> defined above the function in the C file.
>
>> +static gboolean sync_send_indication(gpointer user_data);
>> +static gboolean proc_sync_set_req_phase2(gpointer user_data);
>
> Same here.
>
> Johan
>
^ permalink raw reply
* Re: Need complete docs on PAN and DUN with bluez 4.66
From: Luiz Augusto von Dentz @ 2010-09-21 11:06 UTC (permalink / raw)
To: Arun Kumar; +Cc: Mumia W, linux-bluetooth
In-Reply-To: <AANLkTi=gRJgyFD2uC-UsjzjQCU11326SSsN4+nsTxk9-@mail.gmail.com>
Hi,
On Tue, Sep 21, 2010 at 6:56 AM, Arun Kumar <arunkat@gmail.com> wrote:
> Depends on what role you want to use pand for ...pand is launched as a
> daemon via command line with set of options you may want to use it for
> your requirements ...
I wouldn't suggest using pand nor dund because they are deprecated.
PAN is really dead simple, Network.Connect() returns the network
interface in case of success and both NetworkManager and connman
should be able to use them, in fact I think both already have specif
PAN support to connect from their ui.
DUN is a bit more complicated, it rely on Serial.Connect("dun") which
creates a RFCOMM port to talk to the modem, but there need to be some
process that has an AT command engine to handle all the configuration,
in NetworkManager case there is ModemManager that is supposed to do
that but I have tried not long ago and it failed for me, I think we
might want to have ofono to handle this in connman case but so far
there the support for this is not complete (Gustavo Padovan has been
working on it).
Both Network and Serial interface are documented in doc/ diretory,
there is also test-network and test-serial under test/ that can be
used to manually connect to those profiles.
--
Luiz Augusto von Dentz
Computer Engineer
^ permalink raw reply
* Re: [PATCH] Some code reordering in mcap_sync
From: Johan Hedberg @ 2010-09-21 11:05 UTC (permalink / raw)
To: Jose Antonio Santos Cadenas; +Cc: linux-bluetooth
In-Reply-To: <1285056861-10099-1-git-send-email-santoscadenas@gmail.com>
Hi,
On Tue, Sep 21, 2010, Jose Antonio Santos Cadenas wrote:
> Declaration, defines and struct definitions are moved to the begining
> of the file. Just for make the code more readable.
> ---
> health/mcap_sync.c | 86 +++++++++++++++++++++++++--------------------------
> 1 files changed, 42 insertions(+), 44 deletions(-)
Thanks, the patch is now upstream. While you're at it, please also
remove any unnecessary forward declarations, like these:
> +static void proc_sync_cap_req(struct mcap_mcl *mcl, uint8_t *cmd, uint32_t len);
> +static void proc_sync_set_req(struct mcap_mcl *mcl, uint8_t *cmd, uint32_t len);
> +static void proc_sync_cap_rsp(struct mcap_mcl *mcl, uint8_t *cmd, uint32_t len);
> +static void proc_sync_set_rsp(struct mcap_mcl *mcl, uint8_t *cmd, uint32_t len);
> +static void proc_sync_info_ind(struct mcap_mcl *mcl, uint8_t *cmd, uint32_t len);
Only in very rare cases are forward declarations needed. Whenever
possible order the functions so that the dependencies of a function are
defined above the function in the C file.
> +static gboolean sync_send_indication(gpointer user_data);
> +static gboolean proc_sync_set_req_phase2(gpointer user_data);
Same here.
Johan
^ permalink raw reply
* [PATCH] Some code reordering in mcap_sync
From: Jose Antonio Santos Cadenas @ 2010-09-21 8:14 UTC (permalink / raw)
To: linux-bluetooth; +Cc: Jose Antonio Santos Cadenas
Declaration, defines and struct definitions are moved to the begining
of the file. Just for make the code more readable.
---
health/mcap_sync.c | 86 +++++++++++++++++++++++++--------------------------
1 files changed, 42 insertions(+), 44 deletions(-)
diff --git a/health/mcap_sync.c b/health/mcap_sync.c
index 260cd71..25fc2d4 100644
--- a/health/mcap_sync.c
+++ b/health/mcap_sync.c
@@ -44,6 +44,11 @@
#include "mcap_lib.h"
#include "mcap_internal.h"
+#define MCAP_BTCLOCK_HALF (MCAP_BTCLOCK_FIELD / 2)
+#define CLK CLOCK_MONOTONIC
+
+#define MCAP_CSP_ERROR g_quark_from_static_string("mcap-csp-error-quark")
+
struct mcap_csp {
uint64_t base_tmstamp; /* CSP base timestamp */
struct timespec base_time; /* CSP base time when timestamp set */
@@ -60,8 +65,31 @@ struct mcap_csp {
void *csp_priv_data; /* CSP-Master: In-flight request data */
};
-#define MCAP_BTCLOCK_HALF (MCAP_BTCLOCK_FIELD / 2)
-#define CLK CLOCK_MONOTONIC
+struct mcap_sync_cap_cbdata {
+ mcap_sync_cap_cb cb;
+ gpointer user_data;
+};
+
+struct mcap_sync_set_cbdata {
+ mcap_sync_set_cb cb;
+ gpointer user_data;
+};
+
+struct csp_caps {
+ int ts_acc; /* timestamp accuracy */
+ int ts_res; /* timestamp resolution */
+ int latency; /* Read BT clock latency */
+ int preempt_thresh; /* Preemption threshold for latency */
+ int syncleadtime_ms; /* SyncLeadTime in ms */
+};
+
+struct sync_set_data {
+ uint8_t update;
+ uint32_t sched_btclock;
+ uint64_t timestamp;
+ int ind_freq;
+ gboolean role;
+};
/* Ripped from lib/sdp.c */
@@ -80,6 +108,18 @@ static inline uint64_t ntoh64(uint64_t n)
#define hton64(x) ntoh64(x)
+static gboolean csp_caps_initialized = FALSE;
+struct csp_caps _caps;
+
+static void proc_sync_cap_req(struct mcap_mcl *mcl, uint8_t *cmd, uint32_t len);
+static void proc_sync_set_req(struct mcap_mcl *mcl, uint8_t *cmd, uint32_t len);
+static void proc_sync_cap_rsp(struct mcap_mcl *mcl, uint8_t *cmd, uint32_t len);
+static void proc_sync_set_rsp(struct mcap_mcl *mcl, uint8_t *cmd, uint32_t len);
+static void proc_sync_info_ind(struct mcap_mcl *mcl, uint8_t *cmd, uint32_t len);
+
+static gboolean sync_send_indication(gpointer user_data);
+static gboolean proc_sync_set_req_phase2(gpointer user_data);
+
static int send_sync_cmd(struct mcap_mcl *mcl, const void *buf, uint32_t size)
{
int sock;
@@ -121,24 +161,6 @@ static int send_unsupported_set_req(struct mcap_mcl *mcl)
return sent;
}
-static void proc_sync_cap_req(struct mcap_mcl *mcl, uint8_t *cmd, uint32_t len);
-static void proc_sync_set_req(struct mcap_mcl *mcl, uint8_t *cmd, uint32_t len);
-static void proc_sync_cap_rsp(struct mcap_mcl *mcl, uint8_t *cmd, uint32_t len);
-static void proc_sync_set_rsp(struct mcap_mcl *mcl, uint8_t *cmd, uint32_t len);
-static void proc_sync_info_ind(struct mcap_mcl *mcl, uint8_t *cmd, uint32_t len);
-
-#define MCAP_CSP_ERROR g_quark_from_static_string("mcap-csp-error-quark")
-
-struct mcap_sync_cap_cbdata {
- mcap_sync_cap_cb cb;
- gpointer user_data;
-};
-
-struct mcap_sync_set_cbdata {
- mcap_sync_set_cb cb;
- gpointer user_data;
-};
-
void proc_sync_cmd(struct mcap_mcl *mcl, uint8_t *cmd, uint32_t len)
{
if (!mcl->ms->csp_enabled || !mcl->csp) {
@@ -319,7 +341,6 @@ static gboolean read_btclock(struct mcap_mcl *mcl, uint32_t *btclock,
return ret < 0 ? FALSE : TRUE;
}
-
static gboolean read_btclock_retry(struct mcap_mcl *mcl, uint32_t *btclock,
uint16_t *btaccuracy)
{
@@ -381,17 +402,6 @@ uint32_t mcap_get_btclock(struct mcap_mcl *mcl)
return btclock;
}
-struct csp_caps {
- int ts_acc; /* timestamp accuracy */
- int ts_res; /* timestamp resolution */
- int latency; /* Read BT clock latency */
- int preempt_thresh; /* Preemption threshold for latency */
- int syncleadtime_ms; /* SyncLeadTime in ms */
-};
-
-static struct csp_caps _caps;
-static gboolean csp_caps_initialized = FALSE;
-
static void initialize_caps(struct mcap_mcl *mcl)
{
struct timespec t1, t2;
@@ -542,18 +552,6 @@ static int send_sync_set_rsp(struct mcap_mcl *mcl, uint8_t rspcode,
return sent;
}
-static gboolean proc_sync_set_req_phase2(gpointer user_data);
-
-struct sync_set_data {
- uint8_t update;
- uint32_t sched_btclock;
- uint64_t timestamp;
- int ind_freq;
- gboolean role;
-};
-
-static gboolean sync_send_indication(gpointer user_data);
-
static void proc_sync_set_req(struct mcap_mcl *mcl, uint8_t *cmd, uint32_t len)
{
mcap_md_sync_set_req *req;
--
1.7.0.4
^ permalink raw reply related
* Re: [PATCH 2/2] Bluetooth: Update conf_state before send config_req out.
From: Ville Tervo @ 2010-09-21 6:05 UTC (permalink / raw)
To: ext haijun liu; +Cc: linux-bluetooth@vger.kernel.org, dantian.ip
In-Reply-To: <AANLkTimQtkORjmsiO3wPULRErNXORBtHATbBvdCEsY27@mail.gmail.com>
On Mon, Sep 20, 2010 at 03:33:31AM +0200, ext haijun liu wrote:
> Update conf_state with L2CAP_CONF_REQ_SENT before send config_req out.
>
>
> Signed-off-by: Haijun.Liu <Haijun.Liu@Atheros.com>
Acked-by: Ville Tervo <ville.tervo@nokia.com>
> ---
> net/bluetooth/l2cap.c | 1 +
> 1 files changed, 1 insertions(+), 0 deletions(-)
>
> diff --git a/net/bluetooth/l2cap.c b/net/bluetooth/l2cap.c
> index 076d1af..9d1225d 100644
> --- a/net/bluetooth/l2cap.c
> +++ b/net/bluetooth/l2cap.c
> @@ -3164,6 +3164,7 @@ static inline int l2cap_config_req(struct
> l2cap_conn *conn, struct l2cap_cmd_hdr
> u8 buf[64];
> + l2cap_pi(sk)->conf_state |= L2CAP_CONF_REQ_SENT;
> l2cap_send_cmd(conn, l2cap_get_ident(conn), L2CAP_CONF_REQ,
> l2cap_build_conf_req(sk, buf), buf);
> l2cap_pi(sk)->num_conf_req++;
> }
>
> --
> 1.6.3.3
>
>
> --
> Haijun Liu
> --
> 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: [PATCH 1/2] Bluetooth: Remove duplicate code.
From: Ville Tervo @ 2010-09-21 5:41 UTC (permalink / raw)
To: ext haijun liu; +Cc: linux-bluetooth@vger.kernel.org, dantian.ip
In-Reply-To: <AANLkTim_N7sA6NqmNqWsrW2dQmnwkm-NSGuFz191SQCT@mail.gmail.com>
On Mon, Sep 20, 2010 at 03:26:14AM +0200, ext haijun liu wrote:
> Remove duplicate code, it's already in l2cap_send_disconn_req().
>
>
> Signed-off-by: Haijun.Liu <Haijun.Liu@Atheros.com>
Acked-by: Ville Tervo <ville.tervo@nokia.com>
> ---
> net/bluetooth/l2cap.c | 1 -
> 1 files changed, 0 insertions(+), 1 deletions(-)
>
> diff --git a/net/bluetooth/l2cap.c b/net/bluetooth/l2cap.c
> index 725744b..076d1af 100644
> --- a/net/bluetooth/l2cap.c
> +++ b/net/bluetooth/l2cap.c
> @@ -3222,7 +3222,6 @@ static inline int l2cap_config_rsp(struct
> l2cap_conn *conn, struct l2cap_cmd_hdr
> }
>
> default:
> - sk->sk_err = ECONNRESET;
> l2cap_sock_set_timer(sk, HZ * 5);
> l2cap_send_disconn_req(conn, sk, ECONNRESET);
> goto done;
> --
> 1.6.3.3
>
>
> --
> Haijun Liu
> --
> 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
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