* Re: [PATCH] gdbus: fix not handling bus disconnects
From: Marcel Holtmann @ 2010-10-13 12:52 UTC (permalink / raw)
To: Luiz Augusto von Dentz; +Cc: linux-bluetooth
In-Reply-To: <1286971606-11790-1-git-send-email-luiz.dentz@gmail.com>
Hi Luiz,
> We where not dispatching data when a bus disconnects which cause
> Disconnected signal to not be processed and thus causing the process to
> either not exit or to not trigger callbacks registered with
> g_dbus_set_disconnect_function.
>
> To fix this now we always schedule a dispatch which will make sure data
> still not processed will make its way to the proper handlers even if
> disconnected.
this looks fine to me. Went ahead and applied to all repositories.
Regards
Marcel
^ permalink raw reply
* [PATCH] Fix problem with operator name length
From: Lukasz Pawlik @ 2010-10-13 12:49 UTC (permalink / raw)
To: linux-bluetooth; +Cc: Lukasz Pawlik
To follow the HFP specification we must ensure that network operator name
will have at maximum 16 characters. In current implementation we do not
check this constraint. This patch fix this. Now operator name with more
than 16 characters will be truncated to 16 characters.
---
audio/telephony-maemo6.c | 3 +--
1 files changed, 1 insertions(+), 2 deletions(-)
diff --git a/audio/telephony-maemo6.c b/audio/telephony-maemo6.c
index 1aac034..bbd2d2f 100644
--- a/audio/telephony-maemo6.c
+++ b/audio/telephony-maemo6.c
@@ -1498,8 +1498,7 @@ static void update_operator_name(const char *name)
return;
g_free(net.operator_name);
- net.operator_name = g_strdup(name);
-
+ net.operator_name = g_strndup(name, 16);
DBG("telephony-maemo6: operator name updated: %s", name);
}
--
1.7.0.4
^ permalink raw reply related
* [PATCH] Fix telephony-maemo6: call notification with call on hold
From: Daniel Örstadius @ 2010-10-13 12:38 UTC (permalink / raw)
To: linux-bluetooth
[-- Attachment #1: Type: text/plain, Size: 1 bytes --]
[-- Attachment #2: 0001-Fix-telephony-maemo6-call-notification-with-call-on.patch --]
[-- Type: text/x-patch, Size: 1205 bytes --]
From fc43271937812cf668b450dc07f77f5688ef6c87 Mon Sep 17 00:00:00 2001
From: Daniel Orstadius <daniel.orstadius@nokia.com>
Date: Tue, 12 Oct 2010 14:09:55 +0300
Subject: [PATCH] Fix telephony-maemo6: call notification with call on hold
BlueZ sends +CLIP and RING when there is an incoming call and no
currently active call. If there is an active call it sends AT+CCWA
(call waiting notification).
Modification to send AT+CCWA instead of +CLIP and RING also when
there is a call on hold (the incoming call goes into the waiting
state).
---
audio/telephony-maemo6.c | 3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/audio/telephony-maemo6.c b/audio/telephony-maemo6.c
index 05ff332..f0273ee 100644
--- a/audio/telephony-maemo6.c
+++ b/audio/telephony-maemo6.c
@@ -910,7 +910,8 @@ static void handle_incoming_call(DBusMessage *msg)
telephony_update_indicator(maemo_indicators, "callsetup",
EV_CALLSETUP_INCOMING);
- if (find_call_with_status(CSD_CALL_STATUS_ACTIVE))
+ if (find_call_with_status(CSD_CALL_STATUS_ACTIVE) ||
+ find_call_with_status(CSD_CALL_STATUS_HOLD))
telephony_call_waiting_ind(call->number,
number_type(call->number));
else
--
1.6.0.4
^ permalink raw reply related
* Re: [PATCH] Fix suspend stream on opening if no data
From: Johan Hedberg @ 2010-10-13 12:30 UTC (permalink / raw)
To: Dmitriy Paliy; +Cc: linux-bluetooth
In-Reply-To: <1286972456-6168-2-git-send-email-dmitriy.paliy@nokia.com>
Hi Dmitriy,
On Wed, Oct 13, 2010, Dmitriy Paliy wrote:
> Fix write to stream and suspend it immidiately if there is no data
> available.
> ---
> src/obex.c | 14 +++++++++++++-
> 1 files changed, 13 insertions(+), 1 deletions(-)
Looks good. The patch has been pushed upstream. Do pay attention to
whitespace issues in the future though. I got this when applying it:
Applying: Fix suspend stream on opening if no data
/home/jh/src/obexd/.git/rebase-apply/patch:18: trailing whitespace.
warning: 1 line applied after fixing whitespace errors.
This came from the empty line with two tabs after the AddHeader call:
> OBEX_ObjectAddHeader (obex, obj, OBEX_HDR_BODY,
> hd, 0, OBEX_FL_STREAM_START);
> +
Johan
^ permalink raw reply
* Re: [PATCH] Fix suspend stream on opening if no data
From: Bastien Nocera @ 2010-10-13 12:24 UTC (permalink / raw)
To: Dmitriy Paliy; +Cc: linux-bluetooth
In-Reply-To: <1286972456-6168-2-git-send-email-dmitriy.paliy@nokia.com>
On Wed, 2010-10-13 at 15:20 +0300, Dmitriy Paliy wrote:
> + /* Try to write to stream and suspend the stream
> immidiately
Should be immediately (and in the log message as well)
^ permalink raw reply
* [PATCH] Fix suspend stream on opening if no data
From: Dmitriy Paliy @ 2010-10-13 12:20 UTC (permalink / raw)
To: linux-bluetooth; +Cc: Dmitriy Paliy
In-Reply-To: <1286972456-6168-1-git-send-email-dmitriy.paliy@nokia.com>
Fix write to stream and suspend it immidiately if there is no data
available.
---
src/obex.c | 14 +++++++++++++-
1 files changed, 13 insertions(+), 1 deletions(-)
diff --git a/src/obex.c b/src/obex.c
index c7d0753..71bcba8 100644
--- a/src/obex.c
+++ b/src/obex.c
@@ -813,10 +813,22 @@ static void cmd_get(struct obex_session *os, obex_t *obex, obex_object_t *obj)
os->obj = obj;
os->driver->set_io_watch(os->object, handle_async_io, os);
return;
- } else
+ } else {
/* Standard data stream */
OBEX_ObjectAddHeader (obex, obj, OBEX_HDR_BODY,
hd, 0, OBEX_FL_STREAM_START);
+
+ /* Try to write to stream and suspend the stream immidiately
+ * if no data available to send. */
+ err = obex_write_stream(os, obex, obj);
+ if (err == -EAGAIN) {
+ OBEX_SuspendRequest(obex, obj);
+ os->obj = obj;
+ os->driver->set_io_watch(os->object, handle_async_io,
+ os);
+ return;
+ }
+ }
done:
os_set_response(obj, err);
--
1.7.0.4
^ permalink raw reply related
* [PATCH 0/1] Fix suspend stream on opening if no data
From: Dmitriy Paliy @ 2010-10-13 12:20 UTC (permalink / raw)
To: linux-bluetooth
Hi,
This patch is to suspend obex stream on opening if there is no data
available yet to be sent. In such way unnecessary trafic is avoided
and IOP is improved with certain headsets. More specifically call
histories get requests from BH-902 are fixed.
Br,
Dmitriy
^ permalink raw reply
* Re: [PATCH 3/7] Bluetooth: LE disconnection and connect cancel support
From: Ville Tervo @ 2010-10-13 12:10 UTC (permalink / raw)
To: ext Marcel Holtmann; +Cc: linux-bluetooth@vger.kernel.org
In-Reply-To: <1286449467.6145.97.camel@aeonflux>
Hi Marcel,
On Thu, Oct 07, 2010 at 01:04:27PM +0200, ext Marcel Holtmann wrote:
> Hi Ville,
>
> > Add supprt to cancel and disconnet connections.
> >
> > Signed-off-by: Ville Tervo <ville.tervo@nokia.com>
> > ---
> > include/net/bluetooth/hci.h | 5 ++---
> > include/net/bluetooth/hci_core.h | 3 +++
> > net/bluetooth/hci_conn.c | 30 ++++++++++++++++++++++++++++++
> > 3 files changed, 35 insertions(+), 3 deletions(-)
> >
> > diff --git a/include/net/bluetooth/hci.h b/include/net/bluetooth/hci.h
> > index b326240..d04ecea 100644
> > --- a/include/net/bluetooth/hci.h
> > +++ b/include/net/bluetooth/hci.h
> > @@ -191,6 +191,8 @@ enum {
> >
> > #define LMP_EV4 0x01
> > #define LMP_EV5 0x02
> > +#define LMP_NO_BR 0x20
> > +#define LMP_LE 0x40
>
> Keep these in sync with the constants we use in userspace.
I changed these to match userspace ones.
> > #define LMP_SNIFF_SUBR 0x02
> > #define LMP_EDR_ESCO_2M 0x20
> > @@ -627,9 +629,6 @@ struct hci_cp_le_create_conn {
> > } __packed;
> >
> > #define HCI_OP_LE_CREATE_CONN_CANCEL 0x200e
> > -struct hci_cp_le_create_conn_cancel {
> > - __u8 status;
> > -} __packed;
> >
> > #define HCI_OP_LE_SET_ADVERTISE_ENABLE 0x200a
> > #define LE_ADVERTISE_ENABLED 0x01
> > diff --git a/include/net/bluetooth/hci_core.h b/include/net/bluetooth/hci_core.h
> > index 89f4b10..a430a57 100644
> > --- a/include/net/bluetooth/hci_core.h
> > +++ b/include/net/bluetooth/hci_core.h
> > @@ -455,10 +455,13 @@ void hci_conn_del_sysfs(struct hci_conn *conn);
> > #define lmp_rswitch_capable(dev) ((dev)->features[0] & LMP_RSWITCH)
> > #define lmp_encrypt_capable(dev) ((dev)->features[0] & LMP_ENCRYPT)
> > #define lmp_sniff_capable(dev) ((dev)->features[0] & LMP_SNIFF)
> > +#define lmp_br_capable(dev) (!((dev)->features[4] & LMP_NO_BR))
>
> This makes no sense to me. And leave this out for now. This is more
> complicated when running on LE only.
ok
> > +#define lmp_le_capable(dev) ((dev)->features[4] & LMP_LE)
>
> I would just add this at the end of the list and not intermix it with
> sniff and sniffsubr defines.
>
> > #define lmp_sniffsubr_capable(dev) ((dev)->features[5] & LMP_SNIFF_SUBR)
> > #define lmp_esco_capable(dev) ((dev)->features[3] & LMP_ESCO)
> > #define lmp_ssp_capable(dev) ((dev)->features[6] & LMP_SIMPLE_PAIR)
> >
> > +
> > /* ----- HCI protocols ----- */
> > struct hci_proto {
> > char *name;
> > diff --git a/net/bluetooth/hci_conn.c b/net/bluetooth/hci_conn.c
> > index cb41d64..50f8973 100644
> > --- a/net/bluetooth/hci_conn.c
> > +++ b/net/bluetooth/hci_conn.c
> > @@ -66,6 +66,31 @@ void hci_le_connect(struct hci_conn *conn)
> > hci_send_cmd(hdev, HCI_OP_LE_CREATE_CONN, sizeof(cp), &cp);
> > }
> >
> > +static void hci_le_connect_cancel(struct hci_conn *conn)
> > +{
> > + struct hci_dev *hdev = conn->hdev;
> > +
> > + BT_DBG("%p", conn);
> > +
> > + if (!lmp_le_capable(hdev))
> > + return;
>
> This should not be needed. We should not have tried to establish a LE
> link if we don't support LE in the first place.
ok
> > +
> > + hci_send_cmd(conn->hdev, HCI_OP_LE_CREATE_CONN_CANCEL, 0, NULL);
> > +}
> > +
> > +void hci_le_disconn(struct hci_conn *conn, __u8 reason)
> > +{
> > + struct hci_cp_disconnect cp;
> > +
> > + BT_DBG("%p", conn);
> > +
> > + conn->le_state = BT_DISCONN;
> > +
> > + cp.handle = cpu_to_le16(conn->handle);
> > + cp.reason = reason;
> > + hci_send_cmd(conn->hdev, HCI_OP_DISCONNECT, sizeof(cp), &cp);
> > +}
>
> When just using conn->state, then this becomes obsolete and we can use
> the generic one.
I removed whole function.
> > +
> > void hci_acl_connect(struct hci_conn *conn)
> > {
> > struct hci_dev *hdev = conn->hdev;
> > @@ -221,6 +246,8 @@ static void hci_conn_timeout(unsigned long arg)
> > case BT_CONNECT2:
> > if (conn->type == ACL_LINK && conn->out)
> > hci_acl_connect_cancel(conn);
> > + if (conn->type == LE_LINK && conn->out)
> > + hci_le_connect_cancel(conn);
>
> This should be redone with as this:
>
> if (conn->out) {
> if (ACL_LINK)
> ...
> else if (LE_LINK)
> ...
> }
Done
> > break;
> > case BT_CONFIG:
> > case BT_CONNECTED:
> > @@ -397,6 +424,9 @@ struct hci_conn *hci_connect(struct hci_dev *hdev, int type, bdaddr_t *dst, __u8
> > BT_DBG("%s dst %s", hdev->name, batostr(dst));
> >
> > if (type == LE_LINK) {
> > + if (!lmp_le_capable(hdev))
> > + return NULL;
> > +
> > le = hci_conn_hash_lookup_ba(hdev, LE_LINK, dst);
> >
> > if (!le)
>
> We might need to move that lmp_le_capable check into L2CAP. Since
> otherwise we can not give a proper return value if someone tries to use
> LE on a BR/EDR only controller.
Check removed from from here. However I left lmp_le_capable() to code so it can
be used in l2cap patches.
--
Ville
^ permalink raw reply
* [PATCH] gdbus: fix not handling bus disconnects
From: Luiz Augusto von Dentz @ 2010-10-13 12:06 UTC (permalink / raw)
To: linux-bluetooth
From: Luiz Augusto von Dentz <luiz.dentz-von@nokia.com>
We where not dispatching data when a bus disconnects which cause
Disconnected signal to not be processed and thus causing the process to
either not exit or to not trigger callbacks registered with
g_dbus_set_disconnect_function.
To fix this now we always schedule a dispatch which will make sure data
still not processed will make its way to the proper handlers even if
disconnected.
---
gdbus/mainloop.c | 4 ++++
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/gdbus/mainloop.c b/gdbus/mainloop.c
index ec10ab0..862c434 100644
--- a/gdbus/mainloop.c
+++ b/gdbus/mainloop.c
@@ -95,6 +95,7 @@ static gboolean watch_func(GIOChannel *chan, GIOCondition cond, gpointer data)
{
struct watch_info *info = data;
unsigned int flags = 0;
+ DBusDispatchStatus status;
dbus_connection_ref(info->conn);
@@ -105,6 +106,9 @@ static gboolean watch_func(GIOChannel *chan, GIOCondition cond, gpointer data)
dbus_watch_handle(info->watch, flags);
+ status = dbus_connection_get_dispatch_status(info->conn);
+ queue_dispatch(info->conn, status);
+
dbus_connection_unref(info->conn);
return TRUE;
--
1.7.1
^ permalink raw reply related
* Re: [PATCH] Bluetooth: Check for SCO type before setting retr. effort
From: Gustavo F. Padovan @ 2010-10-13 12:04 UTC (permalink / raw)
To: Emeltchenko Andrei; +Cc: linux-bluetooth
In-Reply-To: <1284724018-26731-1-git-send-email-Andrei.Emeltchenko.news@gmail.com>
Hi Andrei,
* Emeltchenko Andrei <Andrei.Emeltchenko.news@gmail.com> [2010-09-17 14:46:58 +0300]:
> From: Andrei Emeltchenko <andrei.emeltchenko@nokia.com>
>
> Check eSCO / SCO type before setting retransmission effort flag
> in Setup SCO command. We found that 0x01 is better for power
> consupmtion but we cannot use it always since controller tries
> to setup eSCO even for old devices.
>
> Might be controller-specific.
>
> Signed-off-by: Andrei Emeltchenko <andrei.emeltchenko@nokia.com>
> ---
> net/bluetooth/hci_conn.c | 8 +++++++-
> 1 files changed, 7 insertions(+), 1 deletions(-)
>
> diff --git a/net/bluetooth/hci_conn.c b/net/bluetooth/hci_conn.c
> index 0b1e460..145993f 100644
> --- a/net/bluetooth/hci_conn.c
> +++ b/net/bluetooth/hci_conn.c
> @@ -150,7 +150,13 @@ void hci_setup_sync(struct hci_conn *conn, __u16 handle)
> cp.rx_bandwidth = cpu_to_le32(0x00001f40);
> cp.max_latency = cpu_to_le16(0xffff);
> cp.voice_setting = cpu_to_le16(hdev->voice_setting);
> - cp.retrans_effort = 0xff;
> +
> + /* If remote device supports eSCO use optimization for power
> + retransmission effort, otherwise use standard flag do-not-care */
> + if (conn->link->features[3] & LMP_ESCO)
This should be lmp_esco_capable()
--
Gustavo F. Padovan
ProFUSION embedded systems - http://profusion.mobi
^ permalink raw reply
* Re: [PATCH] Fix problem with hanging up held call
From: Johan Hedberg @ 2010-10-13 12:03 UTC (permalink / raw)
To: Lukasz Pawlik; +Cc: linux-bluetooth
In-Reply-To: <AANLkTimEv+RYqUC76dOYc7t4ciwC2FSi-AYG0d8KdaUn@mail.gmail.com>
Hi Lukasz,
On Wed, Oct 13, 2010, Lukasz Pawlik wrote:
> There was an error in my patch. Patch attached to this mail fix it.
Thanks. The (updated) patch has been pushed upstream.
Johan
^ permalink raw reply
* Re: Firmware versioning best practices: ath3k-2.fw rename or replace ath3k-1.fw ?
From: Marcel Holtmann @ 2010-10-13 10:06 UTC (permalink / raw)
To: Henry Ptasinski
Cc: Luis R. Rodriguez, Suraj Sumangala, Luis Rodriguez,
David Woodhouse, linux-bluetooth, linux-kernel@vger.kernel.org,
linux-wireless
In-Reply-To: <20101012211726.GE2678@broadcom.com>
Hi Henry,
> > > Marcel had answered me before. It makes sense to have same file name.
> > > Other ways we end up changing the driver whenever there is a firmware
> > > change.
> >
> > > > I last tried to document a thread we had over this here:
> > > >
> > > > http://wireless.kernel.org/en/developers/Documentation/firmware-versioning
> > > >
> >
> > Thanks, I've updated that link above to document bug fixing does not require
> > a filename change.
>
> I don't really understand why you would not want to change the code revision
> part of the filename.
>
> I totally agree that you don't want to change the driver every time the
> firmware gets a bug fix, but wasn't that the whole point of splitting the name
> into API and code revisions portions, and symlinking the file to one that just
> has the API version?
>
> What's the issue with using the process as originally documented?
as I stated before, for Bluetooth this makes no sense. You don't need
API version numbers since the API is a STANDARD. It is called HCI. So
please don't use API version numbers in the firmware files.
I will reject firmware file versions for upstream drivers.
Regards
Marcel
^ permalink raw reply
* Re: [PATCH 3/3] bluetooth: Enable USB autosuspend by default on btusb
From: Marcel Holtmann @ 2010-10-13 10:00 UTC (permalink / raw)
To: Matthew Garrett; +Cc: linux-bluetooth, linux-usb
In-Reply-To: <1284659895-27984-3-git-send-email-mjg@redhat.com>
Hi Matthew,
> We've done this for a while in Fedora without any obvious problems other
> than some interaction with input devices. Those should be fixed now, so
> let's try this in mainline.
>
> Signed-off-by: Matthew Garrett <mjg@redhat.com>
sounds good to me.
Acked-by: Marcel Holtmann <marcel@holtmann.org>
Regards
Marcel
^ permalink raw reply
* Re: [PATCH] Fix problem with hanging up held call
From: Lukasz Pawlik @ 2010-10-13 9:33 UTC (permalink / raw)
To: johan.hedberg; +Cc: linux-bluetooth
In-Reply-To: <1286959079-3566-1-git-send-email-lucas.pawlik@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1376 bytes --]
There was an error in my patch. Patch attached to this mail fix it.
2010/10/13 Lukasz Pawlik <lucas.pawlik@gmail.com>:
> According to the HFP specification AT+CHUP command should not have impact
> on the state of any held calls. Previously held call was terminated when
> there was second alerting call. This patch fix this problem. AT+CHUP
> command will go towards alerting call.
> ---
> audio/telephony-maemo6.c | 4 ++++
> 1 files changed, 4 insertions(+), 0 deletions(-)
>
> diff --git a/audio/telephony-maemo6.c b/audio/telephony-maemo6.c
> index 05ff332..00a4b25 100644
> --- a/audio/telephony-maemo6.c
> +++ b/audio/telephony-maemo6.c
> @@ -498,6 +498,7 @@ void telephony_last_dialed_number_req(void *telephony_device)
> void telephony_terminate_call_req(void *telephony_device)
> {
> struct csd_call *call;
> + struct csd_call *alerting;
> int err;
>
> call = find_call_with_status(CSD_CALL_STATUS_ACTIVE);
> @@ -511,6 +512,9 @@ void telephony_terminate_call_req(void *telephony_device)
> return;
> }
>
> + alerting = find_call_with_status(CSD_CALL_STATUS_MO_ALERTING);
> + if (call->on_hold && alerting)
> + err = release_call(alerting);
> if (call->conference)
> err = release_conference();
> else
> --
> 1.7.0.4
>
>
[-- Attachment #2: 0001-Fix-problem-with-hanging-up-held-call.patch --]
[-- Type: text/x-patch, Size: 1344 bytes --]
From 7b7c4adf982a0c98df14331bf357619d1b483227 Mon Sep 17 00:00:00 2001
From: Lukasz Pawlik <lucas.pawlik@gmail.com>
Date: Wed, 13 Oct 2010 10:54:21 +0200
Subject: [PATCH] Fix problem with hanging up held call
According to the HFP specification AT+CHUP command should not have impact
on the state of any held calls. Previously held call was terminated when
there was second alerting call. This patch fix this problem. AT+CHUP
command will go towards alerting call.
---
audio/telephony-maemo6.c | 6 +++++-
1 files changed, 5 insertions(+), 1 deletions(-)
diff --git a/audio/telephony-maemo6.c b/audio/telephony-maemo6.c
index 05ff332..1aac034 100644
--- a/audio/telephony-maemo6.c
+++ b/audio/telephony-maemo6.c
@@ -498,6 +498,7 @@ void telephony_last_dialed_number_req(void *telephony_device)
void telephony_terminate_call_req(void *telephony_device)
{
struct csd_call *call;
+ struct csd_call *alerting;
int err;
call = find_call_with_status(CSD_CALL_STATUS_ACTIVE);
@@ -511,7 +512,10 @@ void telephony_terminate_call_req(void *telephony_device)
return;
}
- if (call->conference)
+ alerting = find_call_with_status(CSD_CALL_STATUS_MO_ALERTING);
+ if (call->on_hold && alerting)
+ err = release_call(alerting);
+ else if (call->conference)
err = release_conference();
else
err = release_call(call);
--
1.7.0.4
^ permalink raw reply related
* Re: [PATCH 1/3] bluetooth: Take a runtime pm reference on hid connections
From: Marcel Holtmann @ 2010-10-13 9:32 UTC (permalink / raw)
To: Matthew Garrett; +Cc: linux-bluetooth, linux-usb
In-Reply-To: <1284659895-27984-1-git-send-email-mjg@redhat.com>
Hi Matthew,
> Bluetooth runtime PM interacts badly with input devices - the connection
> will be dropped if the device becomes idle, resulting in noticable lag when
> the user interacts with the input device again. Bump the pm runtime count
> when the device is associated and release it when it's disassociated in
> order to avoid this.
we already have hci_conn_hold_device() and hci_conn_put_device() calls
for HID to hold reference of the ACL connection. Why do we need more?
Regards
Marcel
^ permalink raw reply
* [PATCH] Fix problem with hanging up held call
From: Lukasz Pawlik @ 2010-10-13 8:37 UTC (permalink / raw)
To: linux-bluetooth; +Cc: Lukasz Pawlik
According to the HFP specification AT+CHUP command should not have impact
on the state of any held calls. Previously held call was terminated when
there was second alerting call. This patch fix this problem. AT+CHUP
command will go towards alerting call.
---
audio/telephony-maemo6.c | 4 ++++
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/audio/telephony-maemo6.c b/audio/telephony-maemo6.c
index 05ff332..00a4b25 100644
--- a/audio/telephony-maemo6.c
+++ b/audio/telephony-maemo6.c
@@ -498,6 +498,7 @@ void telephony_last_dialed_number_req(void *telephony_device)
void telephony_terminate_call_req(void *telephony_device)
{
struct csd_call *call;
+ struct csd_call *alerting;
int err;
call = find_call_with_status(CSD_CALL_STATUS_ACTIVE);
@@ -511,6 +512,9 @@ void telephony_terminate_call_req(void *telephony_device)
return;
}
+ alerting = find_call_with_status(CSD_CALL_STATUS_MO_ALERTING);
+ if (call->on_hold && alerting)
+ err = release_call(alerting);
if (call->conference)
err = release_conference();
else
--
1.7.0.4
^ permalink raw reply related
* pull request: bluetooth-next-2.6 2010-10-13
From: Gustavo F. Padovan @ 2010-10-13 3:48 UTC (permalink / raw)
To: linville; +Cc: marcel, linux-wireless, linux-bluetooth
Hi John,
Here goes the Bluetooth patches for the next merge window. In this
patchset we have a new stream-oriented recvmsg() which is used in L2CAP
and RFCOMM. Support for two new MacBookPro devices. A buffer overflow
check for L2CAP to prevent frames exceeding the receiving MTU. All the
rest are simple bugfixes. No big features this time.
One notable change is in the MAINTAINERS file, From now and on I'm going
to maintain the Bluetooth trees as well as send the pull requests to you.
Despite this maintenance change, Marcel will remain helping with patch
review, and ACK/NAK in the Bluetooth subsystem as he always did. Not a
big change in the end. ;)
Thanks,
The following changes since commit 29b4433d991c88d86ca48a4c1cc33c671475be4b:
net: percpu net_device refcount (2010-10-12 12:35:25 -0700)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/padovan/bluetooth-next-2.6.git master
Andrei Emeltchenko (4):
Bluetooth: remove extra newline from debug output
Bluetooth: check L2CAP length in first ACL fragment
Bluetooth: check for l2cap header in start fragment
Bluetooth: clean up rfcomm code
David Vrabel (2):
Bluetooth: HCI devices are either BR/EDR or AMP radios
Bluetooth: Support SDIO devices that are AMP controllers
Gustavo F. Padovan (4):
Bluetooth: remove unused variable from cmtp
Bluetooth: make batostr() print in the right order
Bluetooth: Use the proper error value from bt_skb_send_alloc()
Bluetooth: update MAINTAINERS for Bluetooth subsys
Haijun Liu (1):
Bluetooth: Update conf_state before send config_req out
Johan Hedberg (1):
Bluetooth: Don't clear the blacklist when closing the HCI device
Karl Beldan (1):
Bluetooth: hci_uart: Fix typo in stats for sco tx
Mat Martineau (4):
Bluetooth: Validate PSM values in calls to connect() and bind()
Bluetooth: Add common code for stream-oriented recvmsg()
Bluetooth: Use common SOCK_STREAM receive code in RFCOMM
Bluetooth: Use a stream-oriented recvmsg with SOCK_STREAM L2CAP sockets.
Nobuhiro Iwamatsu (2):
Bluetooth: Add support Bluetooth controller of MacbookPro 6,2
Bluetooth: Add support Bluetooth controller of MacbookPro 7,1
Yuri Kululin (1):
Bluetooth: Fix RFCOMM RPN negotiation
MAINTAINERS | 5 ++-
drivers/bluetooth/btmrvl_main.c | 4 +-
drivers/bluetooth/btsdio.c | 8 +++
drivers/bluetooth/btusb.c | 6 ++
drivers/bluetooth/hci_ldisc.c | 2 +-
include/linux/mmc/sdio_ids.h | 1 +
include/net/bluetooth/bluetooth.h | 2 +
include/net/bluetooth/hci.h | 2 +-
include/net/bluetooth/rfcomm.h | 5 --
net/bluetooth/af_bluetooth.c | 109 +++++++++++++++++++++++++++++++++++++
net/bluetooth/cmtp/core.c | 6 +--
net/bluetooth/hci_core.c | 1 -
net/bluetooth/hci_sysfs.c | 21 ++-----
net/bluetooth/hidp/core.c | 8 +--
net/bluetooth/l2cap.c | 56 ++++++++++++++++---
net/bluetooth/lib.c | 4 +-
net/bluetooth/rfcomm/core.c | 39 +++++++-------
net/bluetooth/rfcomm/sock.c | 104 ++---------------------------------
net/bluetooth/rfcomm/tty.c | 4 +-
19 files changed, 218 insertions(+), 169 deletions(-)
--
Gustavo F. Padovan
ProFUSION embedded systems - http://profusion.mobi
^ permalink raw reply
* Re: Firmware versioning best practices: ath3k-2.fw rename or replace ath3k-1.fw ?
From: Henry Ptasinski @ 2010-10-12 21:17 UTC (permalink / raw)
To: Luis R. Rodriguez
Cc: Suraj Sumangala, Luis Rodriguez, David Woodhouse, Marcel Holtmann,
linux-bluetooth, linux-kernel@vger.kernel.org, linux-wireless,
Henry Ptasinski
In-Reply-To: <20101008181508.GM10149@tux>
On Fri, Oct 08, 2010 at 11:15:08AM -0700, Luis R. Rodriguez wrote:
> On Fri, Oct 08, 2010 at 10:27:36AM -0700, Suraj Sumangala wrote:
> > Marcel had answered me before. It makes sense to have same file name.
> > Other ways we end up changing the driver whenever there is a firmware
> > change.
>
> > > I last tried to document a thread we had over this here:
> > >
> > > http://wireless.kernel.org/en/developers/Documentation/firmware-versioning
> > >
>
> Thanks, I've updated that link above to document bug fixing does not require
> a filename change.
I don't really understand why you would not want to change the code revision
part of the filename.
I totally agree that you don't want to change the driver every time the
firmware gets a bug fix, but wasn't that the whole point of splitting the name
into API and code revisions portions, and symlinking the file to one that just
has the API version?
What's the issue with using the process as originally documented?
- Henry
^ permalink raw reply
* RE: RFC: btusb firmware load help
From: Kevin Hayes @ 2010-10-12 13:38 UTC (permalink / raw)
To: Marcel Holtmann, Shanmugamkamatchi Balashanmugam
Cc: Shanmugamkamatchi Balashanmugam, Luis Rodriguez, Johannes Berg,
linux-bluetooth, linux-kernel@vger.kernel.org,
linux-wireless@vger.kernel.org, Deepak Dhamdhere, Sree Durbha
In-Reply-To: <1286469741.6145.165.camel@aeonflux>
SGkgTWFyY2VsLCBCYWxhLA0KDQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJv
bTogbGludXgtYmx1ZXRvb3RoLW93bmVyQHZnZXIua2VybmVsLm9yZyBbbWFpbHRvOmxpbnV4LWJs
dWV0b290aC0NCj4gb3duZXJAdmdlci5rZXJuZWwub3JnXSBPbiBCZWhhbGYgT2YgTWFyY2VsIEhv
bHRtYW5uDQo+IFNlbnQ6IFRodXJzZGF5LCBPY3RvYmVyIDA3LCAyMDEwIDk6NDIgQU0NCj4gVG86
IFNoYW5tdWdhbWthbWF0Y2hpIEJhbGFzaGFubXVnYW0NCj4gQ2M6IFNoYW5tdWdhbWthbWF0Y2hp
IEJhbGFzaGFubXVnYW07IEx1aXMgUm9kcmlndWV6OyBKb2hhbm5lcyBCZXJnOw0KPiBsaW51eC1i
bHVldG9vdGg7IGxpbnV4LWtlcm5lbEB2Z2VyLmtlcm5lbC5vcmc7IGxpbnV4LQ0KPiB3aXJlbGVz
c0B2Z2VyLmtlcm5lbC5vcmc7IERlZXBhayBEaGFtZGhlcmU7IFNyZWUgRHVyYmhhDQo+IFN1Ympl
Y3Q6IFJlOiBSRkM6IGJ0dXNiIGZpcm13YXJlIGxvYWQgaGVscA0KPiANCj4gSGkgQmFsYSwNCj4g
DQo+ID4gPj4gVGhhbmtzIEpvaGFubmVzLiAgVGhpcyB3b3VsZCBiZSBiZXR0ZXIgb3B0aW9uIHRv
IGNoYW5nZSBQSUQgaW4NCj4gZmlybXdhcmUNCj4gPiA+PiBhcyBibGFja2xpc3RpbmcgMzAwMiBt
aWdodCBjcmVhdGUgcHJvYmxlbXMgZm9yIDMwMTEgY2hpcHNldHMuDQo+ID4gPj4gV2lsbCB0cnkg
YW5kIGxldCB5b3UgcGVvcGxlIGtub3cuDQo+ID4gPiBUaGUgbWlzYmVoYXZpbmcgMzAwMiBuZWVk
cyB0byBiZSBibGFja2xpc3RlZCBpbiBidHVzYi5jIGFueXdheS4NCj4gSG93ZXZlcg0KPiA+ID4g
YWZ0ZXIgbG9hZGluZyB0aGUgZmlybXdhcmUgdG8gMzAwMiBkZXZpY2UsIGl0IHNob3VsZCBjaGFu
Z2UgaXRzIFBJRA0KPiB0bw0KPiA+ID4gc29tZXRoaW5nIGVsc2UuDQo+ID4gPg0KPiA+ID4gSSBh
bSBzdGlsbCB0cnlpbmcgdG8gZmlndXJlIG91dCBpZiB0aGlzIGlzIG9uZSBzdGFnZSBmaXJtd2Fy
ZQ0KPiBsb2FkaW5nIG9yDQo+ID4gPiBhIHR3byBzdGFnZSBmaXJtd2FyZSBsb2FkaW5nLiBUaGlz
IGlzIGFsbCBwcmV0dHkgdW5jbGVhciBhbmQgbm9ib2R5DQo+IGhhcw0KPiA+ID4gYW5zd2VyZWQg
dGhpcyBjbGVhcmx5IHNvIGZhci4NCj4gPg0KPiA+IGVlcHJvbSBiYXNlZCAzMDExIGNoaXBzIGNv
bWVzIHVwIHdpdGggUElEIDMwMDAgZ2l2aW5nIGNvbnRyb2wgdG8gREZVDQo+ID4gZHJpdmVyIFth
dGgza10uICBhdGgzayBkb3dubG9hZHMgdGhlDQo+ID4gZmlybXdhcmUgY2hhbmdpbmcgUElEIHRv
IDMwMDIuICBOb3cgYnR1c2IgZ2V0cyBjb250cm9sLg0KPiA+DQo+ID4gSW4gc2ZsYXNoIGJhc2Vk
IGRldmljZXMgdG8gcmVkdWNlIHdpbmRvd3Mgc3VzcGVuZC9yZXN1bWUgdGltZSB3ZSBoYWQNCj4g
YQ0KPiA+IHNtYWxsIGZpcm13YXJlIGluIGZsYXNoIHdoaWNoDQo+ID4gZW5hYmxlcyB0aGUgZGV2
aWNlIHRvIGdldCBkZXRlY3RlZCBhcyBHZW5lcmljIEJsdWV0b290aCBVU0IgZGV2aWNlDQo+IHdp
dGgNCj4gPiBQSUQgMzAwMi4gIFNvIGNvbnRyb2wgcmVhY2hlcyBidHVzYiB3aGVuIGRldmljZSBp
cyBwbHVnZ2VkIGluLA0KPiBsZWF2aW5nDQo+ID4gbm8gb3B0aW9uIGZvciB1cyB0byBsb2FkIHRo
ZSBhY3R1YWwgZmlybXdhcmUuDQo+ID4NCj4gPiBTb2x1dGlvbiB3b3VsZCBiZSB0byBibGFja2xp
c3QgMzAwMiBpbiBidHVzYiwgZW5hYmxlIGF0aDNrIHRvIGdldA0KPiA+IGNvbnRyb2wgZm9yIGJv
dGggdGhlIGRldmljZXMsIGRvd25sb2FkIHRoZSBmaXJtd2FyZSBhbmQgY2hhbmdlIFBJRCB0bw0K
PiA+IDMwMDMgc28gdGhhdCBjb250cm9sIHdpdGggY29tZSB0byBidHVzYi4NCj4gDQo+IHNvIGhl
cmUgaXMgdGhlIHRoaW5nIHRoYXQgbmVlZHMgdG8gYmUgZG9uZS4NCj4gDQo+IGEpIEdldCBhIGZp
cm13YXJlIGZvciBQSUQgMzAwMCBkZXZpY2VzIHRoYXQgY2hhbmdlIHRoZSBmaXJtd2FyZSB0byBz
b21lDQo+IG90aGVyIFBJRC4gU2luY2UgMzAwMyBpcyBhbHJlYWR5IGluIHVzZSBhcyB3ZWxsLCB1
c2luZyAzMDA0IG9yIGxhdGVyIGlzDQo+IGJldHRlciBhcHByb2FjaC4NCj4gDQo+IGIpIEJsYWNr
bGlzdCBQSUQgMzAwMiBpbiBidHVzYi5jLg0KPiANCj4gYykgSGFuZGxlIHNwZWNpYWwgZmlybXdh
cmUgbG9hZGluZyBjYXNlIGZvciBQSUQgMzAwMiBzZmxhc2ggZGV2aWNlcy4gSWYNCj4gZmlybXdh
cmUgaXMgbG9hZGVkIGNoYW5nZWQgdG8gMzAwNSBvciBvdGhlci4NCj4gDQo+IEFuZCBhcyBhIGdl
bmVyYWwgbm90ZSwgSSBwcmVmZXIgdGhhdCB0aGUgUElEIGFmdGVyIGxvYWRpbmcgZmlybXdhcmUg
aXMNCj4gZGlmZmVyZW50IGlmIHlvdSBkb24ndCBoYXBwZW4gdG8gYWN0dWFsbHkgbG9hZCB0aGUg
c2FtZSBmaXJtd2FyZS4NCj4gDQo+IFNvIHBsZWFzZSBzb3J0IG91dCB5b3VyIFVTQiBQSUQgYXNz
aWdubWVudCBmb3IgQmx1ZXRvb3RoIGluIGdlbmVyYWwuDQo+IFRoaXMgc2VlbXMgdG8gYmUgYSBt
ZXNzIHRoYXQgaXMgbm90IHRob3VnaHQgdGhyb3VnaCBwcm9wZXJseS4NCj4gDQo+IFJlZ2FyZHMN
Cj4gDQo+IE1hcmNlbA0KPiANCg0KWWVzLCBpdCBpcyBhIGdvb2QgaWRlYSB0byBsZXQgdGhlIGRv
d25sb2FkYWJsZSBmaXJtd2FyZSBzZXQgYSBuZXcgUElELCBhbG9uZyB3aXRoIHRoZSBibGFja2xp
c3Qgb24gdGhlIDMwMDIgUElEIGZvciB0aGUgZmlyc3QgZ28gcm91bmQuICBJIGVtcGhhc2l6ZSwg
aXQgaXMgdGhlIGRvd25sb2FkZWQgZmlybXdhcmUgdGhhdCB3aWxsIGJlIHJlcXVpcmVkIHRvIGRv
IHRoZSBQSUQgc3dpenpsaW5nLCBub3QgdGhlIHNmbGFzaCBmaXJtd2FyZS4gIEFuZCBJIGFncmVl
IHdlIHNob3VsZCBoYXZlIGEgbWFwIG9mIHRoZSBQSURzIGluIHVzZSBhbmQgd2hhdCB0aGV5IGFy
ZSB1c2VkIGZvciwgb25jZSB3ZSBnZXQgdGhyb3VnaCB0aGlzIGltbWVkaWF0ZSBmaXhpbmcgcGhh
c2UuDQoNClRoYW5rcywNCg0KCUsrKw0KDQoNCg0K
^ permalink raw reply
* Re: [PATCH 2/7] Bluetooth: Add LE connect support
From: Ville Tervo @ 2010-10-12 12:50 UTC (permalink / raw)
To: ext Gustavo F. Padovan; +Cc: Marcel Holtmann, linux-bluetooth@vger.kernel.org
In-Reply-To: <20101007163619.GB4893@vigoh>
On Thu, Oct 07, 2010 at 06:36:20PM +0200, ext Gustavo F. Padovan wrote:
> Hi Ville,
>
> * Marcel Holtmann <marcel@holtmann.org> [2010-10-07 12:58:09 +0200]:
>
> > Hi Ville,
> >
> > > Add logic to create LE connections.
>
>
> Could you be more verbose on the commit message, that way people can
> understand better what you are doing in the patch. ;)
Sure.
>
> > >
> > > Signed-off-by: Ville Tervo <ville.tervo@nokia.com>
> > > ---
> > > include/net/bluetooth/hci.h | 1 +
> > > include/net/bluetooth/hci_core.h | 6 ++-
> > > net/bluetooth/hci_conn.c | 38 ++++++++++++++-
> > > net/bluetooth/hci_event.c | 100 +++++++++++++++++++++++++++++++++++++-
> > > 4 files changed, 141 insertions(+), 4 deletions(-)
> > >
> > > diff --git a/include/net/bluetooth/hci.h b/include/net/bluetooth/hci.h
> > > index b86aed5..b326240 100644
> > > --- a/include/net/bluetooth/hci.h
> > > +++ b/include/net/bluetooth/hci.h
> > > @@ -162,6 +162,7 @@ enum {
> > > #define SCO_LINK 0x00
> > > #define ACL_LINK 0x01
> > > #define ESCO_LINK 0x02
> > > +#define LE_LINK 0x03
> >
> > this is not a value defined by the specification, while the others are.
> > And some functions match these to HCI event. So if wanna do it like
> > this, then using something like 0x80 is better.
>
> A comment in the code saying that is also a good ideia.
Done
--
VIlle
^ permalink raw reply
* Re: [PATCH 2/7] Bluetooth: Add LE connect support
From: Ville Tervo @ 2010-10-12 12:50 UTC (permalink / raw)
To: ext Marcel Holtmann; +Cc: linux-bluetooth@vger.kernel.org
In-Reply-To: <1286449089.6145.91.camel@aeonflux>
Hi Marcel,
Thanks for the review. Could you comments on hci_connect?
On Thu, Oct 07, 2010 at 12:58:09PM +0200, ext Marcel Holtmann wrote:
> Hi Ville,
>
> > Add logic to create LE connections.
> >
> > Signed-off-by: Ville Tervo <ville.tervo@nokia.com>
> > ---
> > include/net/bluetooth/hci.h | 1 +
> > include/net/bluetooth/hci_core.h | 6 ++-
> > net/bluetooth/hci_conn.c | 38 ++++++++++++++-
> > net/bluetooth/hci_event.c | 100 +++++++++++++++++++++++++++++++++++++-
> > 4 files changed, 141 insertions(+), 4 deletions(-)
> >
> > diff --git a/include/net/bluetooth/hci.h b/include/net/bluetooth/hci.h
> > index b86aed5..b326240 100644
> > --- a/include/net/bluetooth/hci.h
> > +++ b/include/net/bluetooth/hci.h
> > @@ -162,6 +162,7 @@ enum {
> > #define SCO_LINK 0x00
> > #define ACL_LINK 0x01
> > #define ESCO_LINK 0x02
> > +#define LE_LINK 0x03
>
> this is not a value defined by the specification, while the others are.
> And some functions match these to HCI event. So if wanna do it like
> this, then using something like 0x80 is better.
Done with some explanation why 0x80 is used.
> > /* LMP features */
> > #define LMP_3SLOT 0x01
> > diff --git a/include/net/bluetooth/hci_core.h b/include/net/bluetooth/hci_core.h
> > index ebec8c9..89f4b10 100644
> > --- a/include/net/bluetooth/hci_core.h
> > +++ b/include/net/bluetooth/hci_core.h
> > @@ -170,6 +170,7 @@ struct hci_conn {
> > bdaddr_t dst;
> > __u16 handle;
> > __u16 state;
> > + __u16 le_state;
>
> I don't see the need for a separate state here. The LE link is different
> from an ACL link and also from a SCO link. We will create a new hci_conn
> for each type of link.
I removed le_state completely.
> > __u8 mode;
> > __u8 type;
> > __u8 out;
> > @@ -203,6 +204,7 @@ struct hci_conn {
> > struct hci_dev *hdev;
> > void *l2cap_data;
> > void *sco_data;
> > + void *le_data;
> > void *priv;
>
> What is the use of le_data here?
No use. Some left over earlier version.
> > struct hci_conn *link;
> > @@ -272,7 +274,7 @@ static inline void hci_conn_hash_add(struct hci_dev *hdev, struct hci_conn *c)
> > {
> > struct hci_conn_hash *h = &hdev->conn_hash;
> > list_add(&c->list, &h->list);
> > - if (c->type == ACL_LINK)
> > + if (c->type == ACL_LINK || c->type == LE_LINK)
> > h->acl_num++;
> > else
> > h->sco_num++;
> > @@ -282,7 +284,7 @@ static inline void hci_conn_hash_del(struct hci_dev *hdev, struct hci_conn *c)
> > {
> > struct hci_conn_hash *h = &hdev->conn_hash;
> > list_del(&c->list);
> > - if (c->type == ACL_LINK)
> > + if (c->type == ACL_LINK || c->type == LE_LINK)
> > h->acl_num--;
> > else
> > h->sco_num--;
>
> I would assume that counting LE connection separately would be way
> better. We could have ACL link to one device and LE link to another.
Done
> > diff --git a/net/bluetooth/hci_conn.c b/net/bluetooth/hci_conn.c
> > index 145993f..cb41d64 100644
> > --- a/net/bluetooth/hci_conn.c
> > +++ b/net/bluetooth/hci_conn.c
> > @@ -45,6 +45,27 @@
> > #include <net/bluetooth/bluetooth.h>
> > #include <net/bluetooth/hci_core.h>
> >
> > +void hci_le_connect(struct hci_conn *conn)
> > +{
> > + struct hci_dev *hdev = conn->hdev;
> > + struct hci_cp_le_create_conn cp;
> > +
> > + conn->le_state = BT_CONNECT;
> > + conn->out = 1;
> > +
> > + memset(&cp, 0, sizeof(cp));
> > + cp.scan_interval = cpu_to_le16(0x0004);
> > + cp.scan_window = cpu_to_le16(0x0004);
> > + bacpy(&cp.peer_addr, &conn->dst);
> > + cp.conn_interval_min = cpu_to_le16(0x0008);
> > + cp.conn_interval_max = cpu_to_le16(0x0100);
> > + cp.supervision_timeout = cpu_to_le16(0x0064);
> > + cp.min_ce_len = cpu_to_le16(0x0001);
> > + cp.max_ce_len = cpu_to_le16(0xffff);
> > +
> > + hci_send_cmd(hdev, HCI_OP_LE_CREATE_CONN, sizeof(cp), &cp);
> > +}
> > +
> > void hci_acl_connect(struct hci_conn *conn)
> > {
> > struct hci_dev *hdev = conn->hdev;
> > @@ -365,15 +386,30 @@ struct hci_dev *hci_get_route(bdaddr_t *dst, bdaddr_t *src)
> > }
> > EXPORT_SYMBOL(hci_get_route);
> >
> > -/* Create SCO or ACL connection.
> > +/* Create SCO, ACL or LE connection.
> > * Device _must_ be locked */
> > struct hci_conn *hci_connect(struct hci_dev *hdev, int type, bdaddr_t *dst, __u8 sec_level, __u8 auth_type)
> > {
> > struct hci_conn *acl;
> > struct hci_conn *sco;
> > + struct hci_conn *le;
> >
> > BT_DBG("%s dst %s", hdev->name, batostr(dst));
> >
> > + if (type == LE_LINK) {
> > + le = hci_conn_hash_lookup_ba(hdev, LE_LINK, dst);
> > +
> > + if (!le)
> > + le = hci_conn_add(hdev, LE_LINK, dst);
> > +
> > + if (!le)
> > + return NULL;
> > +
> > + hci_le_connect(le);
> > +
> > + return le;
> > + }
> > +
> > if (!(acl = hci_conn_hash_lookup_ba(hdev, ACL_LINK, dst))) {
> > if (!(acl = hci_conn_add(hdev, ACL_LINK, dst)))
> > return NULL;
>
> No liking it this much. We might have to re-think on how to do things
> here.
Could you eloborate which part you dislike? I'm leaving this currently like it was.
> > diff --git a/net/bluetooth/hci_event.c b/net/bluetooth/hci_event.c
> > index d3c68de..0b979ae 100644
> > --- a/net/bluetooth/hci_event.c
> > +++ b/net/bluetooth/hci_event.c
> > @@ -868,6 +868,44 @@ static void hci_cc_le_set_scan(struct hci_dev *hdev, struct sk_buff *skb)
> > hci_req_complete(hdev, status);
> > }
> >
> > +static void hci_cs_le_create_conn(struct hci_dev *hdev, __u8 status)
> > +{
> > + struct hci_cp_le_create_conn *cp;
> > + struct hci_conn *conn;
> > +
> > + BT_DBG("%s status 0x%x", hdev->name, status);
> > +
> > + cp = hci_sent_cmd_data(hdev, HCI_OP_LE_CREATE_CONN);
> > + if (!cp)
> > + return;
> > +
> > + hci_dev_lock(hdev);
> > +
> > + conn = hci_conn_hash_lookup_ba(hdev, LE_LINK, &cp->peer_addr);
> > +
> > + BT_DBG("%s bdaddr %s conn %p", hdev->name, batostr(&cp->peer_addr),
> > + conn);
> > +
> > + if (status) {
> > + if (conn && conn->le_state == BT_CONNECT) {
> > + conn->le_state = BT_CLOSED;
> > + hci_proto_connect_cfm(conn, status);
> > + hci_conn_del(conn);
> > + }
> > + } else {
> > + if (!conn) {
> > + conn = hci_conn_add(hdev, LE_LINK, &cp->peer_addr);
> > + if (conn) {
> > + conn->out = 1;
> > + conn->link_mode |= HCI_LM_MASTER;
> > + } else
> > + BT_ERR("No memory for new connection");
> > + }
> > + }
> > +
> > + hci_dev_unlock(hdev);
> > +}
>
> Do we have the master/slave association with LE?
Yes. But it cannot be changed like in legacy bluetooth connection. conn->out
and conn->link_mode |= HCI_LM_MASTER are redutant information. I removed
conn->link_mode setting.
> > static inline void hci_inquiry_complete_evt(struct hci_dev *hdev, struct sk_buff *skb)
> > {
> > __u8 status = *((__u8 *) skb->data);
> > @@ -1069,7 +1107,10 @@ static inline void hci_disconn_complete_evt(struct hci_dev *hdev, struct sk_buff
> >
> > conn = hci_conn_hash_lookup_handle(hdev, __le16_to_cpu(ev->handle));
> > if (conn) {
> > - conn->state = BT_CLOSED;
> > + if (conn->type == LE_LINK)
> > + conn->le_state = BT_CLOSED;
> > + else
> > + conn->state = BT_CLOSED;
>
> If we would just use conn->state then this should not be needed.
>
> > hci_proto_disconn_cfm(conn, ev->reason);
> > hci_conn_del(conn);
> > @@ -1430,6 +1471,10 @@ static inline void hci_cmd_status_evt(struct hci_dev *hdev, struct sk_buff *skb)
> > hci_cs_exit_sniff_mode(hdev, ev->status);
> > break;
> >
> > + case HCI_OP_LE_CREATE_CONN:
> > + hci_cs_le_create_conn(hdev, ev->status);
> > + break;
> > +
> > default:
> > BT_DBG("%s opcode 0x%x", hdev->name, opcode);
> > break;
> > @@ -1875,6 +1920,55 @@ static inline void hci_remote_host_features_evt(struct hci_dev *hdev, struct sk_
> > hci_dev_unlock(hdev);
> > }
> >
> > +static inline void hci_le_conn_complete_evt(struct hci_dev *hdev, struct sk_buff *skb)
> > +{
> > + struct hci_ev_le_conn_complete *ev = (void *) skb->data;
> > + struct hci_conn *conn;
> > +
> > + BT_DBG("%s status %d", hdev->name, ev->status);
> > +
> > + hci_dev_lock(hdev);
> > +
> > + conn = hci_conn_hash_lookup_ba(hdev, LE_LINK, &ev->bdaddr);
> > +
> > + if (!conn)
> > + goto unlock;
>
> The empty line between conn assignment and check should be removed.
Done
>
> > +
> > + if (ev->status) {
> > + hci_proto_connect_cfm(conn, ev->status);
> > + conn->le_state = BT_CLOSED;
> > + hci_conn_del(conn);
> > + goto unlock;
> > + }
> > +
> > + conn->handle = __le16_to_cpu(ev->handle);
> > + conn->le_state = BT_CONNECTED;
> > +
> > + hci_conn_hold_device(conn);
> > + hci_conn_add_sysfs(conn);
> > +
> > + hci_proto_connect_cfm(conn, ev->status);
> > +unlock:
> > + hci_dev_unlock(hdev);
>
> And here you should have an empty line between the label and the last
> statement before the label.
Done
> > +}
> > +
> > +static inline void hci_le_meta_evt(struct hci_dev *hdev, struct sk_buff *skb)
> > +{
> > + struct hci_ev_le_meta *le_ev = (void *) skb->data;
> > + __u8 event = le_ev->subevent;
>
> Why?
>
> > +
> > + skb_pull(skb, sizeof(*le_ev));
> > +
> > + switch (event) {
>
> Using le_ev->subevent would be just fine here.
Done
> > + case HCI_EV_LE_CONN_COMPLETE:
> > + hci_le_conn_complete_evt(hdev, skb);
> > + break;
> > +
> > + default:
> > + break;
> > + }
> > +}
> > +
> > void hci_event_packet(struct hci_dev *hdev, struct sk_buff *skb)
> > {
> > struct hci_event_hdr *hdr = (void *) skb->data;
> > @@ -2011,6 +2105,10 @@ void hci_event_packet(struct hci_dev *hdev, struct sk_buff *skb)
> > hci_remote_host_features_evt(hdev, skb);
> > break;
> >
> > + case HCI_EV_LE_META:
> > + hci_le_meta_evt(hdev, skb);
> > + break;
> > +
> > default:
> > BT_DBG("%s event 0x%x", hdev->name, event);
> > break;
>
--
Ville
^ permalink raw reply
* Re: Pull request git://gitorious.org/bluez-mcap-hdp/mcap-hdp.git for_upstream
From: Johan Hedberg @ 2010-10-12 10:15 UTC (permalink / raw)
To: Jose Antonio Santos Cadenas; +Cc: linux-bluetooth
In-Reply-To: <AANLkTikapHztx_w9mWxotJBuofYHnxMExd88V+8ng40E@mail.gmail.com>
Hi Jose,
On Tue, Oct 12, 2010, Jose Antonio Santos Cadenas wrote:
> >> On Tue, Oct 12, 2010, Jose Antonio Santos Cadenas wrote:
> >>> I'm sorry but I can't connect to the IRC rigth now. Nevertheless, I
> >>> think that I've found the issues:
> >>>
> >>> - The iochannel should be unrefereed when the watcher is explicitly removed
> >>
> >> Yes, though do you need to have a reference at all? As long as you have
> >> the GLib watch callback GLib itself holds a reference, so if you don't
> >> need one just remove chan->echo_chan and do an unref after calling
> >> add_watch.
> >
> > Sorry I've forgot this one. Gonna solve it.
>
> Solved, I've removed the chan->echo_chan attribute and directly unref
> the io_channel once the watcher is set.
Thanks. The patches have now been pushed upstream.
Johan
^ permalink raw reply
* Re: Pull request git://gitorious.org/bluez-mcap-hdp/mcap-hdp.git for_upstream
From: Jose Antonio Santos Cadenas @ 2010-10-12 10:10 UTC (permalink / raw)
To: Jose Antonio Santos Cadenas, linux-bluetooth; +Cc: Johan Hedberg
In-Reply-To: <AANLkTikPOQm0MBQVL7Ax=v8nfp5wJCY+W5=9Fqn384Ur@mail.gmail.com>
2010/10/12 Jose Antonio Santos Cadenas <santoscadenas@gmail.com>:
> 2010/10/12 Johan Hedberg <johan.hedberg@gmail.com>:
>> Hi Jose,
>>
>> On Tue, Oct 12, 2010, Jose Antonio Santos Cadenas wrote:
>>> I'm sorry but I can't connect to the IRC rigth now. Nevertheless, I
>>> think that I've found the issues:
>>>
>>> - The iochannel should be unrefereed when the watcher is explicitly removed
>>
>> Yes, though do you need to have a reference at all? As long as you have
>> the GLib watch callback GLib itself holds a reference, so if you don't
>> need one just remove chan->echo_chan and do an unref after calling
>> add_watch.
>
> Sorry I've forgot this one. Gonna solve it.
Solved, I've removed the chan->echo_chan attribute and directly unref
the io_channel once the watcher is set.
>
>>
>>> - The commit message s/paramter/parameter
>>>
>>> Are there any more?
>>
>> s/Imcoming/Incoming/
>> s/DBus/D-Bus/
>>
>> And the following doesn't make much sense to me:
>>
>> "Delete all channels DBus interface when the instance is removed"
>>
>> Could you rephrase it somehow, maybe by putting most of it in the
>> message body instead of the summary line. Is it trying to say "Delete
>> the D-Bus interfaces of all channels"? The summary line shouldn't be too
>> complex. You can just say "Fix D-Bus channel removal when removing
>> instances" and then in the message body do the more detailed
>> explanation.
>>
>> Johan
>>
>
^ permalink raw reply
* Re: Pull request git://gitorious.org/bluez-mcap-hdp/mcap-hdp.git for_upstream
From: Jose Antonio Santos Cadenas @ 2010-10-12 10:02 UTC (permalink / raw)
To: Jose Antonio Santos Cadenas, linux-bluetooth; +Cc: Johan Hedberg
In-Reply-To: <20101012093531.GA22165@jh-x301>
2010/10/12 Johan Hedberg <johan.hedberg@gmail.com>:
> Hi Jose,
>
> On Tue, Oct 12, 2010, Jose Antonio Santos Cadenas wrote:
>> I'm sorry but I can't connect to the IRC rigth now. Nevertheless, I
>> think that I've found the issues:
>>
>> - The iochannel should be unrefereed when the watcher is explicitly removed
>
> Yes, though do you need to have a reference at all? As long as you have
> the GLib watch callback GLib itself holds a reference, so if you don't
> need one just remove chan->echo_chan and do an unref after calling
> add_watch.
Sorry I've forgot this one. Gonna solve it.
>
>> - The commit message s/paramter/parameter
>>
>> Are there any more?
>
> s/Imcoming/Incoming/
> s/DBus/D-Bus/
>
> And the following doesn't make much sense to me:
>
> "Delete all channels DBus interface when the instance is removed"
>
> Could you rephrase it somehow, maybe by putting most of it in the
> message body instead of the summary line. Is it trying to say "Delete
> the D-Bus interfaces of all channels"? The summary line shouldn't be too
> complex. You can just say "Fix D-Bus channel removal when removing
> instances" and then in the message body do the more detailed
> explanation.
>
> Johan
>
^ permalink raw reply
* Re: Pull request git://gitorious.org/bluez-mcap-hdp/mcap-hdp.git for_upstream
From: Jose Antonio Santos Cadenas @ 2010-10-12 9:57 UTC (permalink / raw)
To: Jose Antonio Santos Cadenas, linux-bluetooth
In-Reply-To: <20101012093531.GA22165@jh-x301>
Hi,
2010/10/12 Johan Hedberg <johan.hedberg@gmail.com>:
> Hi Jose,
>
> On Tue, Oct 12, 2010, Jose Antonio Santos Cadenas wrote:
>> I'm sorry but I can't connect to the IRC rigth now. Nevertheless, I
>> think that I've found the issues:
>>
>> - The iochannel should be unrefereed when the watcher is explicitly removed
>
> Yes, though do you need to have a reference at all? As long as you have
> the GLib watch callback GLib itself holds a reference, so if you don't
> need one just remove chan->echo_chan and do an unref after calling
> add_watch.
>
>> - The commit message s/paramter/parameter
>>
>> Are there any more?
>
> s/Imcoming/Incoming/
Solved this one
> s/DBus/D-Bus/
>
> And the following doesn't make much sense to me:
>
> "Delete all channels DBus interface when the instance is removed"
>
> Could you rephrase it somehow, maybe by putting most of it in the
> message body instead of the summary line. Is it trying to say "Delete
> the D-Bus interfaces of all channels"? The summary line shouldn't be too
> complex. You can just say "Fix D-Bus channel removal when removing
> instances" and then in the message body do the more detailed
> explanation.
I've changed the commit message and added an explanation. I hope now is clearer.
>
> Johan
>
Regards.
Jose.
^ 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