* 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
* Re: Possible regression with skb_clone() in 2.6.36
From: Gustavo F. Padovan @ 2010-09-21 4:10 UTC (permalink / raw)
To: Andrew Morton; +Cc: linux-bluetooth, netdev, linux-kernel, marcel
In-Reply-To: <20100917153440.474b93e4.akpm@linux-foundation.org>
* Andrew Morton <akpm@linux-foundation.org> [2010-09-17 15:34:40 -0700]:
> On Mon, 30 Aug 2010 20:10:23 -0300
> "Gustavo F. Padovan" <padovan@profusion.mobi> wrote:
>
> > I've been experiencing some problems when running the L2CAP Streaming mode in
> > 2.6.36. The system quickly runs in an Out Of Memory condition and crash. That
> > wasn't happening before, so I think we may have a regression here (I didn't find
> > where yet). The crash log is below.
>
> So 2.6.35 was OK?
>
> > The following patch does not fix the regression, but shows that removing the
> > skb_clone() call from l2cap_streaming_send() makes the problem goes away. The
> > patch is good anyway since it saves memory and time when sending Streaming mode
> > packets.
>
> How does "make it go away" differ from "fix the regression" :)
>
> But yes, if we don't understand the source of the bug then it may well
> still be there. Did you make any progress in understanding the cause?
I did some progress and found that this really fix the bug. We are fine
here then. :)
--
Gustavo F. Padovan
ProFUSION embedded systems - http://profusion.mobi
^ permalink raw reply
* Re: Need complete docs on PAN and DUN with bluez 4.66
From: Arun Kumar @ 2010-09-21 3:56 UTC (permalink / raw)
To: Mumia W; +Cc: linux-bluetooth
In-Reply-To: <AANLkTi=hD_U-19oPnQzQemt5wBgAqip3h7esJZpgkr4e@mail.gmail.com>
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 ...
...
Best Regards,
Arun Kumar Singh
www.crazydaks.com
> On Tue, Sep 21, 2010 at 6:20 AM, Mumia W <mumia.w.18.spam@earthlink.net> wrote:
>>>From: Mumia W <mumia.w.18.spam@earthlink.net>
>>>Sent: Sep 19, 2010 4:49 PM
>>>To: linux-bluetooth@vger.kernel.org
>>>Subject: Need complete docs on PAN and DUN with bluez 4.66
>>>
>>>Where is the documentation on how to use PAN and DUN
>>>with bluez 4.66 (without using the legacy drivers)?
>>>
>>>
>>
>> Evidently the documents do not exist.
>>
>> Does anyone have any advice on how I use PAN with bluez 4.66?
>>
>>
>> --
>>
>> --
>> 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
>>
>
>
>
> --
>
--
Best Regards,
Arun Kumar Singh
www.crazydaks.com
^ permalink raw reply
* Re: Need complete docs on PAN and DUN with bluez 4.66
From: Mumia W @ 2010-09-21 0:50 UTC (permalink / raw)
To: linux-bluetooth
>From: Mumia W <mumia.w.18.spam@earthlink.net>
>Sent: Sep 19, 2010 4:49 PM
>To: linux-bluetooth@vger.kernel.org
>Subject: Need complete docs on PAN and DUN with bluez 4.66
>
>Where is the documentation on how to use PAN and DUN
>with bluez 4.66 (without using the legacy drivers)?
>
>
Evidently the documents do not exist.
Does anyone have any advice on how I use PAN with bluez 4.66?
--
^ permalink raw reply
* Re: [PATCH 0/4 v6] L2CAP updates for valid PSMs, SOCK_STREAM reads
From: Ron Shaffer @ 2010-09-20 21:14 UTC (permalink / raw)
To: Mat Martineau; +Cc: linux-bluetooth, marcel, gustavo, linux-arm-msm
In-Reply-To: <1283965529-17068-1-git-send-email-mathewm@codeaurora.org>
On 9/8/2010 12:05 PM, Mat Martineau wrote:
> This patch set is the same as 'v5', with a fix to PSM validation.
>
>
> [PATCH 1/4] Bluetooth: Validate PSM values in calls to connect() and bind()
>
> Modified to bypass PSM validation for SOCK_RAW (bonding) sockets.
>
>
> [PATCH 2/4] Bluetooth: Add common code for stream-oriented recvmsg()
> [PATCH 3/4] Bluetooth: Use common SOCK_STREAM receive code in RFCOMM
> [PATCH 4/4] Bluetooth: Use a stream-oriented recvmsg with SOCK_STREAM L2CAP sockets.
>
> These patches change the read behavior of SOCK_STREAM L2CAP sockets to
> allow reading of partial SDUs. Same as the 'v5' patches.
>
Ping
--
Ron Shaffer
Employee of the Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.
^ permalink raw reply
* Re: [PATCH v3] Bluetooth: Add socket option definitions for AMP
From: Ron Shaffer @ 2010-09-20 21:13 UTC (permalink / raw)
To: Mat Martineau; +Cc: linux-bluetooth, marcel, gustavo, haijun.liu, linux-arm-msm
In-Reply-To: <1283966193-17831-1-git-send-email-mathewm@codeaurora.org>
On 9/8/2010 12:16 PM, Mat Martineau wrote:
> This adds a new BT_AMP socket option to control the use of AMP channels.
> It is for use with the SOL_BLUETOOTH option level on L2CAP sockets.
>
> Available option values are defined as:
>
> BT_AMP_REQUIRE_BR_EDR
> * Default
> * AMP controllers cannot be used
> * Channel move requests from the remote device are denied
> * If the L2CAP channel is currently using AMP, move the channel to
> BR/EDR
>
> BT_AMP_PREFER_AMP
> * Allow use of AMP controllers
> * If the L2CAP channel is currently on BR/EDR and AMP controller
> resources are available, initiate a channel move to AMP
> * Channel move requests from the remote device are allowed
> * If the L2CAP socket has not been connected yet, try to create
> and configure the channel directly on an AMP controller rather
> than BR/EDR
>
> BT_AMP_PREFER_BR_EDR
> * Allow use of AMP controllers
> * If the L2CAP channel is currently on AMP, move it to BR/EDR
> * Channel move requests from the remote device are allowed
>
> Signed-off-by: Mat Martineau <mathewm@codeaurora.org>
> ---
> include/net/bluetooth/bluetooth.h | 28 ++++++++++++++++++++++++++++
> 1 files changed, 28 insertions(+), 0 deletions(-)
>
> diff --git a/include/net/bluetooth/bluetooth.h b/include/net/bluetooth/bluetooth.h
> index 27a902d..d2c62dc 100644
> --- a/include/net/bluetooth/bluetooth.h
> +++ b/include/net/bluetooth/bluetooth.h
> @@ -64,6 +64,34 @@ struct bt_security {
>
> #define BT_DEFER_SETUP 7
>
> +
> +#define BT_AMP_POLICY 8
> +
> +/* Require BR/EDR (default policy)
> + * AMP controllers cannot be used
> + * Channel move requests from the remote device are denied
> + * If the L2CAP channel is currently using AMP, move the channel to BR/EDR
> + */
> +#define BT_AMP_POLICY_REQUIRE_BR_EDR 0
> +
> +/* Prefer AMP
> + * Allow use of AMP controllers
> + * If the L2CAP channel is currently on BR/EDR and AMP controller
> + * resources are available, initiate a channel move to AMP
> + * Channel move requests from the remote device are allowed
> + * If the L2CAP socket has not been connected yet, try to create
> + * and configure the channel directly on an AMP controller rather
> + * than BR/EDR
> + */
> +#define BT_AMP_POLICY_PREFER_AMP 1
> +
> +/* Prefer BR/EDR
> + * Allow use of AMP controllers
> + * If the L2CAP channel is currently on AMP, move it to BR/EDR
> + * Channel move requests from the remote device are allowed
> + */
> +#define BT_AMP_POLICY_PREFER_BR_EDR 2
> +
> #define BT_INFO(fmt, arg...) printk(KERN_INFO "Bluetooth: " fmt "\n" , ## arg)
> #define BT_ERR(fmt, arg...) printk(KERN_ERR "%s: " fmt "\n" , __func__ , ## arg)
> #define BT_DBG(fmt, arg...) pr_debug("%s: " fmt "\n" , __func__ , ## arg)
Ping
--
Ron Shaffer
Employee of the Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.
^ permalink raw reply
* Re: >net-wireless/bluez-4.63 unable to connect audio streams due commit
From: Johan Hedberg @ 2010-09-20 18:49 UTC (permalink / raw)
To: Pacho Ramos; +Cc: linux-bluetooth
In-Reply-To: <1285006436.15378.2.camel@localhost.localdomain>
Hi,
On Mon, Sep 20, 2010, Pacho Ramos wrote:
> Reporter found that the problem with his dongle was introduced in commit
> aee26b30bbc24cde464ba1a557c2b258ddec6432 "Make BtIO default security
> level MEDIUM", he asked here, on upstream mailing list, but didn't get
> any reply clarifying this:
> http://marc.info/?l=linux-bluetooth&m=127893935109510&w=2
The important piece of info missing here is an HCI trace of the failure
(i.e. output of hcidump). There was a similar issue reported on IRC a
few days back and the hcidump there revealed a LMP response timeout
after BlueZ issues a HCI_Set_Connection_Encryption command. This would
seem to indicate a bug either in the local adapter or the remote device
(headset). Only an airtrace would really reveal what's going on.
However, I suspect it might be possible to work around this by looking
into possibilities of changing the ordering and timing of when the
kernel sends the encryption request.
Johan
^ permalink raw reply
* >net-wireless/bluez-4.63 unable to connect audio streams due commit
From: Pacho Ramos @ 2010-09-20 18:13 UTC (permalink / raw)
To: linux-bluetooth
[-- Attachment #1: Type: text/plain, Size: 1492 bytes --]
Hello
This is an "old" issue that was reported downstream some time ago at:
http://bugs.gentoo.org/show_bug.cgi?id=327705
Getting errors like:
bluetoothd[23165]: State
changed /org/bluez/23165/hci0/dev_00_19_7F_1B_E8_BE: \
HEADSET_STATE_DISCONNECTED -> HEADSET_STATE_CONNECTING
bluetoothd[23165]: \
link_key_request (sba=00:19:86:00:10:FE, dba=00:19:7F:1B:E8:BE)
bluetoothd[23165]: \
kernel auth requirements = 0x00 bluetoothd[23165]: stored link key type
= 0x00
bluetoothd[23165]: adapter_get_device(00:19:7F:1B:E8:BE)
bluetoothd[23165]: Discovered Handsfree service on channel 1
bluetoothd[23165]: /org/bluez/23165/hci0/dev_00_19_7F_1B_E8_BE:
Connecting to \
00:19:7F:1B:E8:BE channel 1 bluetoothd[23165]:
hcid_dbus_bonding_process_complete: \
status=00 bluetoothd[23165]: adapter_get_device(00:19:7F:1B:E8:BE)
bluetoothd[23165]: hcid_dbus_bonding_process_complete: no pending auth
request # Here \
is really long pause, 1-2 seconds bluetoothd[23165]: Function not
implemented (38)
bluetoothd[23165]: State
changed /org/bluez/23165/hci0/dev_00_19_7F_1B_E8_BE: \
HEADSET_STATE_CONNECTING -> HEADSET_STATE_DISCONNECTED
Reporter found that the problem with his dongle was introduced in commit
aee26b30bbc24cde464ba1a557c2b258ddec6432 "Make BtIO default security
level MEDIUM", he asked here, on upstream mailing list, but didn't get
any reply clarifying this:
http://marc.info/?l=linux-bluetooth&m=127893935109510&w=2
Thanks a lot for your help :-)
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 198 bytes --]
^ 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