* Re: [PATCH] Fix problem with operator name length
From: Johan Hedberg @ 2010-10-13 14:19 UTC (permalink / raw)
To: Lukasz Pawlik; +Cc: linux-bluetooth
In-Reply-To: <1286974170-12282-1-git-send-email-lucas.pawlik@gmail.com>
Hi Lukasz,
On Wed, Oct 13, 2010, Lukasz Pawlik wrote:
> - net.operator_name = g_strdup(name);
> -
> + net.operator_name = g_strndup(name, 16);
Is it possible that the the format of the name would be such that byte
boundaries are not always the same as character boundaries (e.g. UTF-8)?
If so, using g_strndup sounds dangerous since it assumes one byte per
character.
Johan
^ permalink raw reply
* Re: [PATCH] Fix telephony-maemo6: call notification with call on hold
From: Johan Hedberg @ 2010-10-13 14:16 UTC (permalink / raw)
To: Daniel Örstadius; +Cc: linux-bluetooth
In-Reply-To: <AANLkTimb82Ykv9fg2Oew4YoN1767e5_NX4Tid+3wHOzE@mail.gmail.com>
Hi Daniel,
On Wed, Oct 13, 2010, Daniel Örstadius wrote:
> 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(-)
Pushed upstream. Thanks.
Johan
^ permalink raw reply
* [PATCH] Some code cleanup in hdp
From: Jose Antonio Santos Cadenas @ 2010-10-13 13:54 UTC (permalink / raw)
To: linux-bluetooth; +Cc: Jose Antonio Santos Cadenas
---
health/hdp.c | 38 ++++++++++++++++++++++----------------
health/hdp_util.c | 29 ++++++++++++++++++-----------
2 files changed, 40 insertions(+), 27 deletions(-)
diff --git a/health/hdp.c b/health/hdp.c
index 4a6da78..954b6d6 100644
--- a/health/hdp.c
+++ b/health/hdp.c
@@ -305,11 +305,12 @@ static DBusMessage *manager_create_application(DBusConnection *conn,
const char *name;
DBusMessageIter iter;
GError *err = NULL;
- DBusMessage *reply;
dbus_message_iter_init(msg, &iter);
app = hdp_get_app_config(&iter, &err);
if (err) {
+ DBusMessage *reply;
+
reply = g_dbus_create_error(msg,
ERROR_INTERFACE ".InvalidArguments",
"Invalid arguments: %s", err->message);
@@ -439,12 +440,13 @@ static void abort_mdl_cb(GError *err, gpointer data)
static void hdp_mdl_reconn_cb(struct mcap_mdl *mdl, GError *err, gpointer data)
{
struct hdp_tmp_dc_data *dc_data = data;
- struct hdp_channel *chan = dc_data->hdp_chann;
- GError *gerr = NULL;
DBusMessage *reply;
int fd;
if (err) {
+ struct hdp_channel *chan = dc_data->hdp_chann;
+ GError *gerr = NULL;
+
error("%s", err->message);
reply = g_dbus_create_error(dc_data->msg,
ERROR_INTERFACE ".HealthError",
@@ -633,12 +635,13 @@ static void health_channel_destroy(void *data)
{
struct hdp_channel *hdp_chan = data;
struct hdp_device *dev = hdp_chan->dev;
- char *empty_path;
DBG("Destroy Health Channel %s", hdp_chan->path);
dev->channels = g_slist_remove(dev->channels, hdp_chan);
if (hdp_chan == dev->fr) {
+ char *empty_path;
+
dev->fr = NULL;
empty_path = "";
emit_property_changed(dev->conn, device_get_path(dev->dev),
@@ -754,8 +757,6 @@ static void hdp_mcap_mdl_connected_cb(struct mcap_mdl *mdl, void *data)
{
struct hdp_device *dev = data;
struct hdp_channel *chan;
- GIOChannel *io_chan;
- int fd;
DBG("hdp_mcap_mdl_connected_cb");
if (!dev->ndc)
@@ -769,16 +770,19 @@ static void hdp_mcap_mdl_connected_cb(struct mcap_mdl *mdl, void *data)
dev->channels = g_slist_prepend(dev->channels, chan);
if (chan->mdep == HDP_MDEP_ECHO) {
+ GIOChannel *io;
+ int fd;
+
fd = mcap_mdl_get_fd(chan->mdl);
if (fd < 0)
return;
chan->echo_done = FALSE;
- io_chan = g_io_channel_unix_new(fd);
- chan->wid = g_io_add_watch(io_chan,
+ io = g_io_channel_unix_new(fd);
+ chan->wid = g_io_add_watch(io,
G_IO_ERR | G_IO_HUP | G_IO_NVAL | G_IO_IN,
serve_echo, chan);
- g_io_channel_unref(io_chan);
+ g_io_channel_unref(io);
return;
}
@@ -859,8 +863,6 @@ static uint8_t hdp_mcap_mdl_conn_req_cb(struct mcap_mcl *mcl, uint8_t mdepid,
{
struct hdp_device *dev = data;
struct hdp_application *app;
- struct hdp_channel *chan;
- char *path;
GSList *l;
DBG("Data channel request");
@@ -922,7 +924,9 @@ static uint8_t hdp_mcap_mdl_conn_req_cb(struct mcap_mcl *mcl, uint8_t mdepid,
l = g_slist_find_custom(dev->channels, &mdlid, cmp_chan_mdlid);
if (l) {
- chan = l->data;
+ struct hdp_channel *chan = l->data;
+ char *path;
+
path = g_strdup(chan->path);
g_dbus_unregister_interface(dev->conn, path, HEALTH_CHANNEL);
g_free(path);
@@ -981,16 +985,17 @@ gboolean hdp_set_mcl_cb(struct hdp_device *device, GError **err)
static void mcl_connected(struct mcap_mcl *mcl, gpointer data)
{
- struct hdp_adapter *hdp_adapter = data;
struct hdp_device *hdp_device;
- struct btd_device *device;
bdaddr_t addr;
- char str[18];
GSList *l;
mcap_mcl_get_addr(mcl, &addr);
l = g_slist_find_custom(devices, &addr, cmp_dev_addr);
if (!l) {
+ struct hdp_adapter *hdp_adapter = data;
+ struct btd_device *device;
+ char str[18];
+
ba2str(&addr, str);
device = adapter_get_device(connection,
hdp_adapter->btd_adapter, str);
@@ -1088,7 +1093,6 @@ static void check_devices_mcl()
{
struct hdp_device *dev;
GSList *l, *to_delete = NULL;
- const char *path;
for (l = devices; l; l = l->next) {
dev = l->data;
@@ -1101,6 +1105,8 @@ static void check_devices_mcl()
}
for (l = to_delete; l; l = l->next) {
+ const char *path;
+
path = device_get_path(dev->dev);
g_dbus_unregister_interface(dev->conn, path, HEALTH_DEVICE);
}
diff --git a/health/hdp_util.c b/health/hdp_util.c
index ef76b15..c5dfb01 100644
--- a/health/hdp_util.c
+++ b/health/hdp_util.c
@@ -141,12 +141,14 @@ static gboolean parse_data_type(DBusMessageIter *iter, gpointer data,
GError **err)
{
struct hdp_application *app = data;
- DBusMessageIter *value, variant;
+ DBusMessageIter *value;
int ctype;
ctype = dbus_message_iter_get_arg_type(iter);
value = iter;
if (ctype == DBUS_TYPE_VARIANT) {
+ DBusMessageIter variant;
+
/* Get value inside the variable */
dbus_message_iter_recurse(iter, &variant);
ctype = dbus_message_iter_get_arg_type(&variant);
@@ -167,13 +169,14 @@ static gboolean parse_data_type(DBusMessageIter *iter, gpointer data,
static gboolean parse_role(DBusMessageIter *iter, gpointer data, GError **err)
{
struct hdp_application *app = data;
- DBusMessageIter value;
DBusMessageIter *string;
int ctype;
const char *role;
ctype = dbus_message_iter_get_arg_type(iter);
if (ctype == DBUS_TYPE_VARIANT) {
+ DBusMessageIter value;
+
/* Get value inside the variable */
dbus_message_iter_recurse(iter, &value);
ctype = dbus_message_iter_get_arg_type(&value);
@@ -206,12 +209,14 @@ static gboolean parse_role(DBusMessageIter *iter, gpointer data, GError **err)
static gboolean parse_desc(DBusMessageIter *iter, gpointer data, GError **err)
{
struct hdp_application *app = data;
- DBusMessageIter *string, variant;
+ DBusMessageIter *string;
int ctype;
const char *desc;
ctype = dbus_message_iter_get_arg_type(iter);
if (ctype == DBUS_TYPE_VARIANT) {
+ DBusMessageIter variant;
+
/* Get value inside the variable */
dbus_message_iter_recurse(iter, &variant);
ctype = dbus_message_iter_get_arg_type(&variant);
@@ -234,12 +239,14 @@ static gboolean parse_chan_type(DBusMessageIter *iter, gpointer data,
GError **err)
{
struct hdp_application *app = data;
- DBusMessageIter *value, variant;
+ DBusMessageIter *value;
int ctype;
ctype = dbus_message_iter_get_arg_type(iter);
value = iter;
if (ctype == DBUS_TYPE_VARIANT) {
+ DBusMessageIter variant;
+
/* Get value inside the variable */
dbus_message_iter_recurse(iter, &variant);
ctype = dbus_message_iter_get_arg_type(&variant);
@@ -294,11 +301,11 @@ fail:
static gboolean is_app_role(GSList *app_list, HdpRole role)
{
- struct hdp_application *app;
GSList *l;
for (l = app_list; l; l = l->next) {
- app = l->data;
+ struct hdp_application *app = l->data;
+
if (app->role == role)
return TRUE;
}
@@ -732,7 +739,7 @@ static gboolean check_role(uint8_t rec_role, uint8_t app_role)
static gboolean get_mdep_from_rec(const sdp_record_t *rec, uint8_t role,
uint16_t d_type, uint8_t *mdep, char **desc)
{
- sdp_data_t *list, *feat, *data_type, *mdepid, *role_t, *desc_t;
+ sdp_data_t *list, *feat;
if (!desc && !mdep)
return TRUE;
@@ -744,6 +751,8 @@ static gboolean get_mdep_from_rec(const sdp_record_t *rec, uint8_t role,
return FALSE;
for (feat = list->val.dataseq; feat; feat = feat->next) {
+ sdp_data_t *data_type, *mdepid, *role_t, *desc_t;
+
if (feat->dtd != SDP_SEQ8 && feat->dtd != SDP_SEQ16 &&
feat->dtd != SDP_SEQ32)
continue;
@@ -931,10 +940,9 @@ static gboolean hdp_get_add_prot_desc_list(const sdp_record_t *rec,
static gboolean get_ccpsm(sdp_list_t *recs, uint16_t *ccpsm)
{
sdp_list_t *l;
- sdp_record_t *rec;
for (l = recs; l; l = l->next) {
- rec = l->data;
+ sdp_record_t *rec = l->data;
if (hdp_get_prot_desc_list(rec, ccpsm, NULL))
return TRUE;
@@ -946,10 +954,9 @@ static gboolean get_ccpsm(sdp_list_t *recs, uint16_t *ccpsm)
static gboolean get_dcpsm(sdp_list_t *recs, uint16_t *dcpsm)
{
sdp_list_t *l;
- sdp_record_t *rec;
for (l = recs; l; l = l->next) {
- rec = l->data;
+ sdp_record_t *rec = l->data;
if (hdp_get_add_prot_desc_list(rec, dcpsm))
return TRUE;
--
1.7.1
^ permalink raw reply related
* [PATCH] Fix X-IRMC-CALL-DATETIME format
From: Luiz Augusto von Dentz @ 2010-10-13 13:15 UTC (permalink / raw)
To: linux-bluetooth
From: Luiz Augusto von Dentz <luiz.dentz-von@nokia.com>
Use the format suggested in the spec:
"For instance, a call that was missed on March 20th, 2005 at 10 am would
be stamped: X-IRMC-CALL-DATETIME;MISSED:20050320T100000"
---
plugins/phonebook-tracker.c | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/plugins/phonebook-tracker.c b/plugins/phonebook-tracker.c
index d0cea2e..39e4c81 100644
--- a/plugins/phonebook-tracker.c
+++ b/plugins/phonebook-tracker.c
@@ -705,7 +705,7 @@ static char *iso8601_utc_to_localtime(const char *datetime)
memset(&tm, 0, sizeof(tm));
- nr = sscanf(datetime, "%04u-%02u-%02uT%02u:%02u:%02u%c",
+ nr = sscanf(datetime, "%04u%02u%02uT%02u%02u%02u%c",
&tm.tm_year, &tm.tm_mon, &tm.tm_mday,
&tm.tm_hour, &tm.tm_min, &tm.tm_sec,
&tz);
@@ -726,7 +726,7 @@ static char *iso8601_utc_to_localtime(const char *datetime)
local = localtime(&time);
- strftime(localdate, sizeof(localdate), "%Y-%m-%dT%H:%M:%S", local);
+ strftime(localdate, sizeof(localdate), "%Y%m%dT%H%M%S", local);
return g_strdup(localdate);
}
--
1.7.1
^ permalink raw reply related
* [PATCH] Adjust mce_bt_set flag to gboolean type values
From: Rafal Michalski @ 2010-10-13 13:08 UTC (permalink / raw)
To: linux-bluetooth; +Cc: Rafal Michalski
This patch makes assignment to mce_bt_set flag more readable and makes
sure that it takes only TRUE or FALSE value from gboolean type.
---
plugins/maemo6.c | 5 +++--
1 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/plugins/maemo6.c b/plugins/maemo6.c
index c396db0..0a1e551 100644
--- a/plugins/maemo6.c
+++ b/plugins/maemo6.c
@@ -71,7 +71,8 @@ static gboolean mce_signal_callback(DBusConnection *connection,
/* set the adapter according to the mce signal
and remember the value */
- mce_bt_set = !!(sigvalue & MCE_RADIO_STATE_BLUETOOTH);
+ mce_bt_set = sigvalue & MCE_RADIO_STATE_BLUETOOTH ?
+ TRUE : FALSE;
if (mce_bt_set)
btd_adapter_switch_online(adapter);
@@ -111,7 +112,7 @@ static void read_radio_states_cb(DBusPendingCall *call, void *user_data)
DBG("radio_states: %d", radio_states);
- mce_bt_set = radio_states & MCE_RADIO_STATE_BLUETOOTH;
+ mce_bt_set = radio_states & MCE_RADIO_STATE_BLUETOOTH ? TRUE : FALSE;
/* check if the adapter has not completed the initial power
* cycle, if so delay action to mce_notify_powered */
--
1.6.3.3
^ permalink raw reply related
* 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
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