* [RFC] Bluetooth: Provide access to reassembled Rx packets
From: Suraj Sumangala @ 2010-07-26 6:02 UTC (permalink / raw)
To: linux-bluetooth; +Cc: Jothikumar.Mothilal, Suraj Sumangala
Provide the HCI transport driver access to reassembled Rx packets before
sending to Host.
Signed-off-by: Suraj Sumangala <suraj@atheros.com>
---
include/net/bluetooth/hci_core.h | 1 +
net/bluetooth/hci_core.c | 4 ++++
2 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/include/net/bluetooth/hci_core.h b/include/net/bluetooth/hci_core.h
index 350b3e6..769530b 100644
--- a/include/net/bluetooth/hci_core.h
+++ b/include/net/bluetooth/hci_core.h
@@ -156,6 +156,7 @@ struct hci_dev {
int (*close)(struct hci_dev *hdev);
int (*flush)(struct hci_dev *hdev);
int (*send)(struct sk_buff *skb);
+ int (*recv)(struct hci_dev *hdev, struct sk_buff *skb);
void (*destruct)(struct hci_dev *hdev);
void (*notify)(struct hci_dev *hdev, unsigned int evt);
int (*ioctl)(struct hci_dev *hdev, unsigned int cmd, unsigned long arg);
diff --git a/net/bluetooth/hci_core.c b/net/bluetooth/hci_core.c
index 995c9f9..8d74f9d 100644
--- a/net/bluetooth/hci_core.c
+++ b/net/bluetooth/hci_core.c
@@ -1132,6 +1132,10 @@ static int hci_reassembly(struct hci_dev *hdev, int type, void *data,
/* Complete frame */
bt_cb(skb)->pkt_type = type;
+
+ if (hdev->recv)
+ hdev->recv(hdev, skb);
+
hci_recv_frame(skb);
hdev->reassembly[index] = NULL;
--
1.7.0.4
^ permalink raw reply related
* Re: [RFC] Bluetooth: Provide access to reassembled Rx packets
From: Marcel Holtmann @ 2010-07-26 6:13 UTC (permalink / raw)
To: Suraj Sumangala; +Cc: linux-bluetooth, Jothikumar.Mothilal
In-Reply-To: <1280124157-16693-1-git-send-email-suraj@atheros.com>
Hi Suraj,
> Provide the HCI transport driver access to reassembled Rx packets before
> sending to Host.
>
> Signed-off-by: Suraj Sumangala <suraj@atheros.com>
> ---
> include/net/bluetooth/hci_core.h | 1 +
> net/bluetooth/hci_core.c | 4 ++++
> 2 files changed, 5 insertions(+), 0 deletions(-)
>
> diff --git a/include/net/bluetooth/hci_core.h b/include/net/bluetooth/hci_core.h
> index 350b3e6..769530b 100644
> --- a/include/net/bluetooth/hci_core.h
> +++ b/include/net/bluetooth/hci_core.h
> @@ -156,6 +156,7 @@ struct hci_dev {
> int (*close)(struct hci_dev *hdev);
> int (*flush)(struct hci_dev *hdev);
> int (*send)(struct sk_buff *skb);
> + int (*recv)(struct hci_dev *hdev, struct sk_buff *skb);
besides the fact that skb->dev == hdev, why would be doing something
like this? This is highly inefficient.
Regards
Marcel
^ permalink raw reply
* Re: [RFC] Bluetooth: Provide access to reassembled Rx packets
From: Suraj @ 2010-07-26 6:27 UTC (permalink / raw)
To: Marcel Holtmann
Cc: Suraj Sumangala, linux-bluetooth@vger.kernel.org,
Jothikumar Mothilal
In-Reply-To: <1280124788.2621.37.camel@localhost.localdomain>
Hi Marcel,
On 7/26/2010 11:43 AM, Marcel Holtmann wrote:
> Hi Suraj,
>
>> Provide the HCI transport driver access to reassembled Rx packets before
>> sending to Host.
>>
>> Signed-off-by: Suraj Sumangala<suraj@atheros.com>
>> ---
>> include/net/bluetooth/hci_core.h | 1 +
>> net/bluetooth/hci_core.c | 4 ++++
>> 2 files changed, 5 insertions(+), 0 deletions(-)
>>
>> diff --git a/include/net/bluetooth/hci_core.h b/include/net/bluetooth/hci_core.h
>> index 350b3e6..769530b 100644
>> --- a/include/net/bluetooth/hci_core.h
>> +++ b/include/net/bluetooth/hci_core.h
>> @@ -156,6 +156,7 @@ struct hci_dev {
>> int (*close)(struct hci_dev *hdev);
>> int (*flush)(struct hci_dev *hdev);
>> int (*send)(struct sk_buff *skb);
>> + int (*recv)(struct hci_dev *hdev, struct sk_buff *skb);
>
> besides the fact that skb->dev == hdev, why would be doing something
> like this? This is highly inefficient.
The idea was to provide the driver access the hci_dev structure.
Yes, as long as we have "skb->dev == hdev", called should be able to
extract it from the skbuff.
>
> Regards
>
> Marcel
>
Regards
Suraj
^ permalink raw reply
* [RFC v2] Bluetooth: Provide access to reassembled Rx packets
From: Suraj Sumangala @ 2010-07-26 6:34 UTC (permalink / raw)
To: linux-bluetooth; +Cc: Jothikumar.Mothilal, Suraj Sumangala
Provide the HCI transport driver access to reassembled Rx packets before
sending to Host.
Signed-off-by: Suraj Sumangala <suraj@atheros.com>
---
include/net/bluetooth/hci_core.h | 1 +
net/bluetooth/hci_core.c | 4 ++++
2 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/include/net/bluetooth/hci_core.h b/include/net/bluetooth/hci_core.h
index 350b3e6..532169c 100644
--- a/include/net/bluetooth/hci_core.h
+++ b/include/net/bluetooth/hci_core.h
@@ -156,6 +156,7 @@ struct hci_dev {
int (*close)(struct hci_dev *hdev);
int (*flush)(struct hci_dev *hdev);
int (*send)(struct sk_buff *skb);
+ int (*recv)(struct sk_buff *skb);
void (*destruct)(struct hci_dev *hdev);
void (*notify)(struct hci_dev *hdev, unsigned int evt);
int (*ioctl)(struct hci_dev *hdev, unsigned int cmd, unsigned long arg);
diff --git a/net/bluetooth/hci_core.c b/net/bluetooth/hci_core.c
index 995c9f9..85e09ef 100644
--- a/net/bluetooth/hci_core.c
+++ b/net/bluetooth/hci_core.c
@@ -1132,6 +1132,10 @@ static int hci_reassembly(struct hci_dev *hdev, int type, void *data,
/* Complete frame */
bt_cb(skb)->pkt_type = type;
+
+ if (hdev->recv)
+ hdev->recv(skb);
+
hci_recv_frame(skb);
hdev->reassembly[index] = NULL;
--
1.7.0.4
^ permalink raw reply related
* Notification of SDP changes to device drivers
From: Jose Antonio Santos Cadenas @ 2010-07-26 7:55 UTC (permalink / raw)
To: linux-bluetooth
Hi all,
This patch is the one that I mentioned that was needed to HDP for
updating the services. When a search services is performed using the
device API, the stored records will be compared with the new found and
if there are any diferences the driver will receive a notification.
I've made this optional in order to keep backwards compatibility, so no extra
changes are needed in the drivers if they don't care about the SDP changes.
Regards
^ permalink raw reply
* [PATCH] Notify to device drivers when the SDP records change
From: Jose Antonio Santos Cadenas @ 2010-07-26 7:55 UTC (permalink / raw)
To: linux-bluetooth; +Cc: Jose Antonio Santos Cadenas
In-Reply-To: <1280130927-4137-1-git-send-email-santoscadenas@gmail.com>
When the remote SDP records that make a driver to be loaded change
(added, remove, or updated) And the driver is not going to be
removed, a notification is sent to the device driver. This
notification is optional annnd does not fail if the driver does
not implemment it.
---
src/device.c | 179 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++-
src/device.h | 1 +
2 files changed, 178 insertions(+), 2 deletions(-)
diff --git a/src/device.c b/src/device.c
index 6af76d1..b8d5e26 100644
--- a/src/device.c
+++ b/src/device.c
@@ -99,7 +99,11 @@ struct browse_req {
GSList *match_uuids;
GSList *profiles_added;
GSList *profiles_removed;
+ GSList *profiles_updated;
sdp_list_t *records;
+ sdp_list_t *records_added;
+ sdp_list_t *records_removed;
+ sdp_list_t *records_changed;
int search_uuid;
int reconnect_attempt;
guint listener_id;
@@ -1328,6 +1332,30 @@ static void device_remove_drivers(struct btd_device *device, GSList *uuids)
sdp_list_free(records, (sdp_free_func_t) sdp_record_free);
}
+static void device_update_drivers(struct btd_device *device, GSList *profiles)
+{
+ GSList *l;
+
+ DBG("Update drivers for %s", device->path);
+
+ for (l = device->drivers; l; l = l->next) {
+ struct btd_driver_data *driver_data = l->data;
+ struct btd_device_driver *driver = driver_data->driver;
+ GSList *updated_uuids;
+
+ DBG("Updating device %s", device->path);
+
+ updated_uuids = device_match_driver(device, driver, profiles);
+
+ if (!updated_uuids)
+ continue;
+
+ DBG("No updated uuids");
+ if (driver->update)
+ driver->update(device, updated_uuids);
+ }
+}
+
static void services_changed(struct btd_device *device)
{
DBusConnection *conn = get_dbus_connection();
@@ -1353,11 +1381,50 @@ static int rec_cmp(const void *a, const void *b)
return r1->handle - r2->handle;
}
+static void check_changes(struct browse_req *req, sdp_list_t *stored_recs,
+ sdp_record_t *rec)
+{
+ sdp_list_t *prev_rec, *remove;
+ sdp_buf_t new_buf, prev_buf;
+
+ prev_rec = sdp_list_find(stored_recs, rec, rec_cmp);
+ if (!prev_rec) {
+ req->records_added = sdp_list_append(req->records_added,
+ sdp_copy_record(rec));
+ return;
+ } else if ((remove = sdp_list_find(req->records_removed, rec, rec_cmp))){
+ req->records_removed = sdp_list_remove(req->records_removed,
+ remove->data);
+ sdp_record_free(remove->data);
+ }
+
+ if (sdp_gen_record_pdu(rec, &new_buf) < 0)
+ return;
+ if (sdp_gen_record_pdu(prev_rec->data, &prev_buf) < 0) {
+ free(new_buf.data);
+ return;
+ }
+
+ if (new_buf.data_size != prev_buf.data_size)
+ goto change;
+
+ if (memcmp(new_buf.data, prev_buf.data, new_buf.data_size) == 0)
+ goto end;
+
+change:
+ req->records_changed = sdp_list_append(req->records_changed,
+ sdp_copy_record(rec));
+
+end:
+ free(new_buf.data);
+ free(prev_buf.data);
+}
+
static void update_services(struct browse_req *req, sdp_list_t *recs)
{
struct btd_device *device = req->device;
struct btd_adapter *adapter = device_get_adapter(device);
- sdp_list_t *seq;
+ sdp_list_t *seq, *stored_recs;
char srcaddr[18], dstaddr[18];
bdaddr_t src;
@@ -1365,6 +1432,8 @@ static void update_services(struct browse_req *req, sdp_list_t *recs)
ba2str(&src, srcaddr);
ba2str(&device->bdaddr, dstaddr);
+ stored_recs = read_records(&src, &req->device->bdaddr);
+
for (seq = recs; seq; seq = seq->next) {
sdp_record_t *rec = (sdp_record_t *) seq->data;
sdp_list_t *svcclass = NULL;
@@ -1418,6 +1487,8 @@ static void update_services(struct browse_req *req, sdp_list_t *recs)
continue;
}
+ check_changes(req, stored_recs, rec);
+
store_record(srcaddr, dstaddr, rec);
/* Copy record */
@@ -1439,6 +1510,8 @@ static void update_services(struct browse_req *req, sdp_list_t *recs)
sdp_list_free(svcclass, free);
}
+
+ sdp_list_free(stored_recs, (sdp_free_func_t)sdp_record_free);
}
static void store_profiles(struct btd_device *device)
@@ -1473,6 +1546,97 @@ static void create_device_reply(struct btd_device *device, struct browse_req *re
g_dbus_send_message(req->conn, reply);
}
+static void remove_record(void *a, void *b)
+{
+ sdp_record_t *rec = a;
+ struct btd_device *device = b;
+ char srcaddr[18], dstaddr[18];
+ bdaddr_t src;
+
+ adapter_get_address(device_get_adapter(device), &src);
+ ba2str(&src, srcaddr);
+ ba2str(&device->bdaddr, dstaddr);
+
+ delete_record(srcaddr, dstaddr, rec->handle);
+}
+
+static void extract_updated_uuids(struct browse_req *req, sdp_record_t *rec)
+{
+ sdp_list_t *svcclass = NULL;
+ gchar *profile_uuid;
+ GSList *l;
+
+ if (sdp_get_service_classes(rec, &svcclass) < 0)
+ return;
+
+ /* Check for empty service classes list */
+ if (svcclass == NULL) {
+ DBG("Skipping record with no service classes");
+ return;
+ }
+
+ /* Extract the first element and skip the remainning */
+ profile_uuid = bt_uuid2string(svcclass->data);
+ if (!profile_uuid) {
+ sdp_list_free(svcclass, free);
+ return;
+ }
+
+ l = g_slist_find_custom(req->profiles_added, profile_uuid,
+ (GCompareFunc) strcmp);
+ if (l)
+ goto end;
+
+ l = g_slist_find_custom(req->profiles_removed, profile_uuid,
+ (GCompareFunc) strcmp);
+ if (l)
+ goto end;
+
+ l = g_slist_find_custom(req->profiles_updated, profile_uuid,
+ (GCompareFunc) strcmp);
+ if (l)
+ goto end;
+
+ req->profiles_updated = g_slist_append(req->profiles_updated,
+ profile_uuid);
+
+end:
+ g_free(profile_uuid);
+ sdp_list_free(svcclass, free);
+}
+
+static void get_updated_uuids(struct browse_req *req)
+{
+ sdp_list_t *l;
+
+ for (l = req->records_added; l; l = l->next) {
+ extract_updated_uuids(req, l->data);
+ }
+
+ for (l = req->records_removed; l; l = l->next) {
+ extract_updated_uuids(req, l->data);
+ }
+
+ for (l = req->records_changed; l; l = l->next) {
+ extract_updated_uuids(req, l->data);
+ }
+
+ if (req->records_added)
+ sdp_list_free(req->records_added,
+ (sdp_free_func_t)sdp_record_free);
+
+ if (req->records_changed)
+ sdp_list_free(req->records_changed,
+ (sdp_free_func_t)sdp_record_free);
+
+ if (req->records_removed) {
+ sdp_list_foreach(req->records_removed, remove_record,
+ req->device);
+ sdp_list_free(req->records_removed,
+ (sdp_free_func_t)sdp_record_free);
+ }
+}
+
static void search_cb(sdp_list_t *recs, int err, gpointer user_data)
{
struct browse_req *req = user_data;
@@ -1493,7 +1657,10 @@ static void search_cb(sdp_list_t *recs, int err, gpointer user_data)
device->tmp_records = req->records;
req->records = NULL;
- if (!req->profiles_added && !req->profiles_removed) {
+ get_updated_uuids(req);
+
+ if (!req->profiles_added && !req->profiles_removed &&
+ !req->profiles_updated) {
DBG("%s: No service update", device->path);
goto send_reply;
}
@@ -1506,6 +1673,10 @@ static void search_cb(sdp_list_t *recs, int err, gpointer user_data)
if (req->profiles_removed)
device_remove_drivers(device, req->profiles_removed);
+ /* Notify the UUIDS whoose SDP records have changed */
+ if (req->profiles_updated)
+ device_update_drivers(device, req->profiles_updated);
+
/* Propagate services changes */
services_changed(req->device);
@@ -1574,6 +1745,7 @@ done:
static void init_browse(struct browse_req *req, gboolean reverse)
{
GSList *l;
+ bdaddr_t src;
/* If we are doing reverse-SDP don't try to detect removed profiles
* since some devices hide their service records while they are
@@ -1585,6 +1757,9 @@ static void init_browse(struct browse_req *req, gboolean reverse)
for (l = req->device->uuids; l; l = l->next)
req->profiles_removed = g_slist_append(req->profiles_removed,
l->data);
+
+ adapter_get_address(device_get_adapter(req->device), &src);
+ req->records_removed = read_records(&src, &req->device->bdaddr);
}
int device_browse(struct btd_device *device, DBusConnection *conn,
diff --git a/src/device.h b/src/device.h
index 5f75e61..72593c4 100644
--- a/src/device.h
+++ b/src/device.h
@@ -103,6 +103,7 @@ struct btd_device_driver {
const char **uuids;
int (*probe) (struct btd_device *device, GSList *uuids);
void (*remove) (struct btd_device *device);
+ void (*update) (struct btd_device *device, GSList *uuids);
};
int btd_register_device_driver(struct btd_device_driver *driver);
--
1.7.1
^ permalink raw reply related
* Re: [PATCH v2] watch: Free service data in service_reply
From: Johan Hedberg @ 2010-07-26 9:33 UTC (permalink / raw)
To: Zhenhua Zhang; +Cc: linux-bluetooth
In-Reply-To: <1280106672-4796-1-git-send-email-zhenhua.zhang@intel.com>
Hi,
On Mon, Jul 26, 2010, Zhenhua Zhang wrote:
> Avoid the memory leak of server_data.
> ---
> gdbus/watch.c | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/gdbus/watch.c b/gdbus/watch.c
> index 1d479fa..29f23e2 100644
> --- a/gdbus/watch.c
> +++ b/gdbus/watch.c
> @@ -533,7 +533,7 @@ static void check_service(DBusConnection *connection, const char *name,
> goto done;
> }
>
> - dbus_pending_call_set_notify(call, service_reply, data, NULL);
> + dbus_pending_call_set_notify(call, service_reply, data, g_free);
>
> dbus_pending_call_unref(call);
Thanks for the updated patch. It has now been pushed both to bluez and
obexd upstream trees with a fixed commit message (e.g. your summary line
was not truthful anymore since the data isn't being freed in
service_reply but by libdbus itself.
Johan
^ permalink raw reply
* RE: [PATCH v2] watch: Free service data in service_reply
From: Zhang, Zhenhua @ 2010-07-26 9:38 UTC (permalink / raw)
To: Johan Hedberg; +Cc: linux-bluetooth@vger.kernel.org
In-Reply-To: <20100726093354.GA20357@jh-x301>
Hi Johan,
Johan Hedberg wrote:
> Hi,
>
> On Mon, Jul 26, 2010, Zhenhua Zhang wrote:
>> Avoid the memory leak of server_data.
>> ---
>> gdbus/watch.c | 2 +-
>> 1 files changed, 1 insertions(+), 1 deletions(-)
>>
>> diff --git a/gdbus/watch.c b/gdbus/watch.c
>> index 1d479fa..29f23e2 100644
>> --- a/gdbus/watch.c
>> +++ b/gdbus/watch.c
>> @@ -533,7 +533,7 @@ static void check_service(DBusConnection
>> *connection, const char *name, goto done; }
>>
>> - dbus_pending_call_set_notify(call, service_reply, data, NULL);
>> + dbus_pending_call_set_notify(call, service_reply, data, g_free);
>>
>> dbus_pending_call_unref(call);
>
> Thanks for the updated patch. It has now been pushed both to bluez and
> obexd upstream trees with a fixed commit message (e.g. your summary
> line was not truthful anymore since the data isn't being freed in
> service_reply but by libdbus itself.
>
> Johan
Thanks. Will pay attention to the commit title next time.
Regards,
Zhenhua
^ permalink raw reply
* Re: [PATCH v4 0/5] Enhanced support for extended inquiry response
From: Johan Hedberg @ 2010-07-26 9:44 UTC (permalink / raw)
To: ingas; +Cc: linux-bluetooth, rshaffer, marcel
In-Reply-To: <b622ef9ae078ace2da7a8a6748823d2f.squirrel@www.codeaurora.org>
Hi Inga,
On Sun, Jul 25, 2010, ingas@codeaurora.org wrote:
> It seems my comment for this patch submisiion was not specific enough (my
> apologies). The extended support for EIR update was meant for the cases
> when d-bus methods "AddRecord", "RemoveRecord" and "Update Record" were
> called. I did verify the problems that you indicated in EIR update when
> using sdptool. However, this is a pre-existing condition not related to
> the extensions that I submitted. sdptool uses different mechanism for EIR
> update that was not affected by my changes. That needs to be fixed in a
> separate patch set, IMO.
Both the D-Bus interface as well as sdptool trigger the same code paths
in src/sdpd-service.c. I.e. it doesn't make sense to solve this twice
when it can be solved once by targetting the common lower layer. We
already do this for the service class bits with update_svclass_list() in
sdpd-service.c. The need to update the EIR data is very similar to the
need to update the service class bits so the existing code is probably a
good place to take example of.
And yes, please make your commit messages more verbose. It's far less of
a crime to have too verbose messages than not having them descriptive
enough: it doesn't just help the reviewers right now in understanding
the purpose of the patches but will also help anybody looking through
the commit history a few years from now when the details of the matter
have been forgotten.
Johan
^ permalink raw reply
* [PATCH v3] Bluetooth: Defer SCO setup if mode change is pending
From: Ron Shaffer @ 2010-07-26 14:06 UTC (permalink / raw)
To: linux-bluetooth; +Cc: marcel, johan.hedberg, Ron Shaffer
In-Reply-To: <1280083316.2621.24.camel@localhost.localdomain>
From: Marcel Holtmann <marcel@holtmann.org>
Certain headsets such as the Motorola H350 will reject SCO and eSCO
connection requests while the ACL is transitioning from sniff mode
to active mode. Add synchronization so that SCO and eSCO connection
requests will wait until the ACL has fully transitioned to active mode.
< HCI Command: Exit Sniff Mode (0x02|0x0004) plen 2
handle 12
> HCI Event: Command Status (0x0f) plen 4
Exit Sniff Mode (0x02|0x0004) status 0x00 ncmd 1
< HCI Command: Setup Synchronous Connection (0x01|0x0028) plen 17
handle 12 voice setting 0x0040
> HCI Event: Command Status (0x0f) plen 4
Setup Synchronous Connection (0x01|0x0028) status 0x00 ncmd 1
> HCI Event: Number of Completed Packets (0x13) plen 5
handle 12 packets 1
> HCI Event: Mode Change (0x14) plen 6
status 0x00 handle 12 mode 0x00 interval 0
Mode: Active
> HCI Event: Synchronous Connect Complete (0x2c) plen 17
status 0x10 handle 14 bdaddr 00:1A:0E:50:28:A4 type SCO
Error: Connection Accept Timeout Exceeded
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Ron Shaffer <rshaffer@codeaurora.org>
---
include/net/bluetooth/hci_core.h | 2 ++
net/bluetooth/hci_conn.c | 32 ++++++++++++++++++++++++++++----
net/bluetooth/hci_event.c | 33 +++++++++++++++++----------------
3 files changed, 47 insertions(+), 20 deletions(-)
diff --git a/include/net/bluetooth/hci_core.h b/include/net/bluetooth/hci_core.h
index e42f6ed..edf3dfe 100644
--- a/include/net/bluetooth/hci_core.h
+++ b/include/net/bluetooth/hci_core.h
@@ -250,6 +250,7 @@ enum {
HCI_CONN_ENCRYPT_PEND,
HCI_CONN_RSWITCH_PEND,
HCI_CONN_MODE_CHANGE_PEND,
+ HCI_CONN_SCO_SETUP_PEND,
};
static inline void hci_conn_hash_init(struct hci_dev *hdev)
@@ -330,6 +331,7 @@ void hci_acl_connect(struct hci_conn *conn);
void hci_acl_disconn(struct hci_conn *conn, __u8 reason);
void hci_add_sco(struct hci_conn *conn, __u16 handle);
void hci_setup_sync(struct hci_conn *conn, __u16 handle);
+void hci_sco_setup(struct hci_conn *conn, __u8 status);
struct hci_conn *hci_conn_add(struct hci_dev *hdev, int type, bdaddr_t *dst);
int hci_conn_del(struct hci_conn *conn);
diff --git a/net/bluetooth/hci_conn.c b/net/bluetooth/hci_conn.c
index b10e3cd..805a22c 100644
--- a/net/bluetooth/hci_conn.c
+++ b/net/bluetooth/hci_conn.c
@@ -155,6 +155,27 @@ void hci_setup_sync(struct hci_conn *conn, __u16 handle)
hci_send_cmd(hdev, HCI_OP_SETUP_SYNC_CONN, sizeof(cp), &cp);
}
+/* Device _must_ be locked */
+void hci_sco_setup(struct hci_conn *conn, __u8 status)
+{
+ struct hci_conn *sco = conn->link;
+
+ BT_DBG("%p", conn);
+
+ if (!sco)
+ return;
+
+ if (!status) {
+ if (lmp_esco_capable(conn->hdev))
+ hci_setup_sync(sco, conn->handle);
+ else
+ hci_add_sco(sco, conn->handle);
+ } else {
+ hci_proto_connect_cfm(sco, status);
+ hci_conn_del(sco);
+ }
+}
+
static void hci_conn_timeout(unsigned long arg)
{
struct hci_conn *conn = (void *) arg;
@@ -380,10 +401,13 @@ struct hci_conn *hci_connect(struct hci_dev *hdev, int type, bdaddr_t *dst, __u8
acl->power_save = 1;
hci_conn_enter_active_mode(acl);
- if (lmp_esco_capable(hdev))
- hci_setup_sync(sco, acl->handle);
- else
- hci_add_sco(sco, acl->handle);
+ if (test_bit(HCI_CONN_MODE_CHANGE_PEND, &acl->pend)) {
+ /* defer SCO setup until mode change completed */
+ set_bit(HCI_CONN_SCO_SETUP_PEND, &acl->pend);
+ return sco;
+ }
+
+ hci_sco_setup(acl, 0x00);
}
return sco;
diff --git a/net/bluetooth/hci_event.c b/net/bluetooth/hci_event.c
index 6c57fc7..4fda049 100644
--- a/net/bluetooth/hci_event.c
+++ b/net/bluetooth/hci_event.c
@@ -785,9 +785,14 @@ static void hci_cs_sniff_mode(struct hci_dev *hdev, __u8 status)
hci_dev_lock(hdev);
conn = hci_conn_hash_lookup_handle(hdev, __le16_to_cpu(cp->handle));
- if (conn)
+ if (conn) {
clear_bit(HCI_CONN_MODE_CHANGE_PEND, &conn->pend);
+ if (test_and_clear_bit(HCI_CONN_SCO_SETUP_PEND,
+ &conn->pend))
+ hci_sco_setup(conn, status);
+ }
+
hci_dev_unlock(hdev);
}
@@ -808,9 +813,14 @@ static void hci_cs_exit_sniff_mode(struct hci_dev *hdev, __u8 status)
hci_dev_lock(hdev);
conn = hci_conn_hash_lookup_handle(hdev, __le16_to_cpu(cp->handle));
- if (conn)
+ if (conn) {
clear_bit(HCI_CONN_MODE_CHANGE_PEND, &conn->pend);
+ if (test_and_clear_bit(HCI_CONN_SCO_SETUP_PEND,
+ &conn->pend))
+ hci_sco_setup(conn, status);
+ }
+
hci_dev_unlock(hdev);
}
@@ -915,20 +925,8 @@ static inline void hci_conn_complete_evt(struct hci_dev *hdev, struct sk_buff *s
} else
conn->state = BT_CLOSED;
- if (conn->type == ACL_LINK) {
- struct hci_conn *sco = conn->link;
- if (sco) {
- if (!ev->status) {
- if (lmp_esco_capable(hdev))
- hci_setup_sync(sco, conn->handle);
- else
- hci_add_sco(sco, conn->handle);
- } else {
- hci_proto_connect_cfm(sco, ev->status);
- hci_conn_del(sco);
- }
- }
- }
+ if (conn->type == ACL_LINK)
+ hci_sco_setup(conn, ev->status);
if (ev->status) {
hci_proto_connect_cfm(conn, ev->status);
@@ -1479,6 +1477,9 @@ static inline void hci_mode_change_evt(struct hci_dev *hdev, struct sk_buff *skb
else
conn->power_save = 0;
}
+
+ if (test_and_clear_bit(HCI_CONN_SCO_SETUP_PEND, &conn->pend))
+ hci_sco_setup(conn, ev->status);
}
hci_dev_unlock(hdev);
--
1.7.0.2
--
Ron Shaffer
Employee of the Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.
^ permalink raw reply related
* Re: [RFC v2] Bluetooth: Provide access to reassembled Rx packets
From: Marcel Holtmann @ 2010-07-26 15:13 UTC (permalink / raw)
To: Suraj Sumangala; +Cc: linux-bluetooth, Jothikumar.Mothilal
In-Reply-To: <1280126094-18004-1-git-send-email-suraj@atheros.com>
Hi Suraj,
> Provide the HCI transport driver access to reassembled Rx packets before
> sending to Host.
you still haven't answered my question on why you want this. It makes no
sense to me to relay all packets back to the driver. That is just a
waste of CPU cycles.
Regards
Marcel
^ permalink raw reply
* Re: [PATCH] Driver-core: Always create class directories for classses that support namespaces.
From: Greg KH @ 2010-07-26 18:07 UTC (permalink / raw)
To: Eric W. Biederman
Cc: Linus Torvalds, Johannes Berg, Kay Sievers, Andrew Morton,
Rafael J. Wysocki, Maciej W. Rozycki, netdev,
<linux-kernel@vger.kernel.org> Marcel Holtmann,
linux-bluetooth, Greg KH
In-Reply-To: <m1tynonmk8.fsf_-_@fess.ebiederm.org>
On Sat, Jul 24, 2010 at 10:43:35PM -0700, Eric W. Biederman wrote:
> p.s. Linus my apologies for sending this directly but I have gotten an
> incredible amount of flak trying to fix this problem, and I would like
> not to leave an accidental regression whose cause is well known in
> 2.6.35 if I can help it.
"flak"?
{sigh}
No, it's just been an issue of fixing the issue in the correct manner.
You sent this patch a mere 2 days prior, and I've been away since then
and haven't even _had_ the chance to apply it to my tree and run it
through any testing.
Heck, it hasn't even been in the linux-next tree, and seen if it blows
up Andrew's notorious machine.
Next time, give me a chance to at least build your patch before getting
upset and routing around me. The other 2 patches you have sent me have
had testing in linux-next and will go to Linus later today, and I have
half-a-mind to revert this one, but I just know you will be willing to
fix up any problems found in it now :)
What a nice way to return from a 3day vacation...
greg k-h
^ permalink raw reply
* [PATCH 1/2] test-serial: fix position of the address argument
From: Gustavo F. Padovan @ 2010-07-26 18:20 UTC (permalink / raw)
To: linux-bluetooth
---
test/test-serial | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/test/test-serial b/test/test-serial
index ed151dc..1c7078c 100755
--- a/test/test-serial
+++ b/test/test-serial
@@ -29,7 +29,7 @@ if (len(args) < 1):
print "Usage: %s <address> [service]" % (sys.argv[0])
sys.exit(1)
-address = sys.argv[0]
+address = sys.argv[1]
if (len(args) < 2):
service = "spp"
--
1.7.1.1
^ permalink raw reply related
* [PATCH 2/2] test-serial: fix service value attribution
From: Gustavo F. Padovan @ 2010-07-26 18:21 UTC (permalink / raw)
To: linux-bluetooth
In-Reply-To: <1280168460-18374-1-git-send-email-gustavo@padovan.org>
---
test/test-serial | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/test/test-serial b/test/test-serial
index 1c7078c..fd55b81 100755
--- a/test/test-serial
+++ b/test/test-serial
@@ -34,7 +34,7 @@ address = sys.argv[1]
if (len(args) < 2):
service = "spp"
else:
- service = args[1]
+ service = sys.argv[2]
path = adapter.FindDevice(address)
--
1.7.1.1
^ permalink raw reply related
* Re: [RFC v2] Bluetooth: Provide access to reassembled Rx packets
From: Suraj @ 2010-07-26 18:23 UTC (permalink / raw)
To: Marcel Holtmann
Cc: Suraj Sumangala, linux-bluetooth@vger.kernel.org,
Jothikumar Mothilal
In-Reply-To: <1280157203.2621.48.camel@localhost.localdomain>
Hi Marcel,
On 7/26/2010 8:43 PM, Marcel Holtmann wrote:
> Hi Suraj,
>
>> Provide the HCI transport driver access to reassembled Rx packets before
>> sending to Host.
>
> you still haven't answered my question on why you want this. It makes no
> sense to me to relay all packets back to the driver. That is just a
> waste of CPU cycles.
>
> Regards
>
> Marcel
>
>
The requirement is simple. The driver need to know the status of certain
vendor specific commands by checking the parameters of Command complete
events.
We also have a requirements to verify the status of HCI RESET command to
update power management feature.
If you are concerned about CPU cycle, we can limit this only for HCI
events and not for ACL/SCO packets.
Please do let me know if you think there is an alternate way so that the
HCI transport driver can access to HCI events.
Regards
Suraj
^ permalink raw reply
* Re: [RFC v2] Bluetooth: Provide access to reassembled Rx packets
From: Marcel Holtmann @ 2010-07-26 22:42 UTC (permalink / raw)
To: Suraj; +Cc: Suraj Sumangala, linux-bluetooth@vger.kernel.org,
Jothikumar Mothilal
In-Reply-To: <4C4DD292.60001@Atheros.com>
Hi Suraj,
> >> Provide the HCI transport driver access to reassembled Rx packets before
> >> sending to Host.
> >
> > you still haven't answered my question on why you want this. It makes no
> > sense to me to relay all packets back to the driver. That is just a
> > waste of CPU cycles.
>
> The requirement is simple. The driver need to know the status of certain
> vendor specific commands by checking the parameters of Command complete
> events.
then implement something that handles vendor specific commands and
events properly. This proposal is insane and will not get merged.
> We also have a requirements to verify the status of HCI RESET command to
> update power management feature.
Then implement something that can track the status of HCI reset
properly.
> If you are concerned about CPU cycle, we can limit this only for HCI
> events and not for ACL/SCO packets.
>
> Please do let me know if you think there is an alternate way so that the
> HCI transport driver can access to HCI events.
So first of all, lets make something perfectly clear. All Bluetooth
drivers are _transport_ drivers. They don't need to know what they are
transporting. And in addition you should not look into the packets that
you are sending or receiving. The Bluetooth core does that HCI packet
parsing.
This is how I want it and how this is going to stay. Everything else is
an insane approach and cost every single driver overhead. In addition
the lifetime rules of SKBs become more and more complicated. That is a
pretty bad thing. It will result in excessive memory usage and will
cause problems.
Regards
Marcel
^ permalink raw reply
* Re: [RFC v2] Bluetooth: Provide access to reassembled Rx packets
From: Suraj @ 2010-07-27 2:23 UTC (permalink / raw)
To: Marcel Holtmann
Cc: Suraj Sumangala, linux-bluetooth@vger.kernel.org,
Jothikumar Mothilal
In-Reply-To: <1280184169.2621.63.camel@localhost.localdomain>
Hi Marcel,
On 7/27/2010 4:12 AM, Marcel Holtmann wrote:
> Hi Suraj,
>
>>>> Provide the HCI transport driver access to reassembled Rx packets before
>>>> sending to Host.
>>>
>>> you still haven't answered my question on why you want this. It makes no
>>> sense to me to relay all packets back to the driver. That is just a
>>> waste of CPU cycles.
>>
>> The requirement is simple. The driver need to know the status of certain
>> vendor specific commands by checking the parameters of Command complete
>> events.
>
> then implement something that handles vendor specific commands and
> events properly. This proposal is insane and will not get merged.
>
>> We also have a requirements to verify the status of HCI RESET command to
>> update power management feature.
>
> Then implement something that can track the status of HCI reset
> properly.
Is there any option for the transport driver to get status of certain
commands from the HCI core?
if it is not there, can you advice how that can be done efficiently?
>
>> If you are concerned about CPU cycle, we can limit this only for HCI
>> events and not for ACL/SCO packets.
>>
>> Please do let me know if you think there is an alternate way so that the
>> HCI transport driver can access to HCI events.
>
> So first of all, lets make something perfectly clear. All Bluetooth
> drivers are _transport_ drivers. They don't need to know what they are
> transporting. And in addition you should not look into the packets that
> you are sending or receiving. The Bluetooth core does that HCI packet
> parsing.
If that is the case, should we be implementing something similar to the
way HCI_LL protocol does it? By defining custom packet types and parsing
it to get board specific information?
>
> This is how I want it and how this is going to stay. Everything else is
> an insane approach and cost every single driver overhead. In addition
> the lifetime rules of SKBs become more and more complicated. That is a
> pretty bad thing. It will result in excessive memory usage and will
> cause problems.
>
> Regards
>
> Marcel
>
>
Regards
Suraj
^ permalink raw reply
* Re: [RFC v2] Bluetooth: Provide access to reassembled Rx packets
From: Suraj @ 2010-07-27 4:48 UTC (permalink / raw)
To: Marcel Holtmann
Cc: Suraj Sumangala, linux-bluetooth@vger.kernel.org,
Jothikumar Mothilal
In-Reply-To: <1280184169.2621.63.camel@localhost.localdomain>
Hi Marcel,
On 7/27/2010 4:12 AM, Marcel Holtmann wrote:
> So first of all, lets make something perfectly clear. All Bluetooth
> drivers are _transport_ drivers. They don't need to know what they are
> transporting. And in addition you should not look into the packets that
> you are sending or receiving. The Bluetooth core does that HCI packet
> parsing.
>
> This is how I want it and how this is going to stay. Everything else is
> an insane approach and cost every single driver overhead. In addition
> the lifetime rules of SKBs become more and more complicated. That is a
> pretty bad thing. It will result in excessive memory usage and will
> cause problems.
I understand the point that you are making. But If I am not mistaken,
HCI transport driver is the only part of the system that could be vendor
specific ( HCI ATH3K, HCI LL etc). So a vendor specific command or event
makes more sense to a transport driver than anybody else.
Is there anyway this requirement can be sufficed without causing the
issues you have mentioned above?
>
> Regards
>
> Marcel
>
>
Regards
Suraj
^ permalink raw reply
* Re: [RFC v2] Bluetooth: Provide access to reassembled Rx packets
From: Marcel Holtmann @ 2010-07-27 5:14 UTC (permalink / raw)
To: Suraj; +Cc: Suraj Sumangala, linux-bluetooth@vger.kernel.org,
Jothikumar Mothilal
In-Reply-To: <4C4E650D.4080806@Atheros.com>
Hi Suraj,
> > So first of all, lets make something perfectly clear. All Bluetooth
> > drivers are _transport_ drivers. They don't need to know what they are
> > transporting. And in addition you should not look into the packets that
> > you are sending or receiving. The Bluetooth core does that HCI packet
> > parsing.
> >
> > This is how I want it and how this is going to stay. Everything else is
> > an insane approach and cost every single driver overhead. In addition
> > the lifetime rules of SKBs become more and more complicated. That is a
> > pretty bad thing. It will result in excessive memory usage and will
> > cause problems.
>
> I understand the point that you are making. But If I am not mistaken,
> HCI transport driver is the only part of the system that could be vendor
> specific ( HCI ATH3K, HCI LL etc). So a vendor specific command or event
> makes more sense to a transport driver than anybody else.
>
> Is there anyway this requirement can be sufficed without causing the
> issues you have mentioned above?
so you might be able to convince me if you implement something proper
for handling vendor commands. The basic assumption is still that a HCI
driver is a pure transport driver.
However you have access to hci_dev. So if you create some functions to
execute vendor commands and retrieve the results then this might be a
way. The core already processes vendor commands and events. But keep in
mind that there is no requirement to get a command status or command
complete event for vendor commands. For example CSR doesn't send them
for their vendor commands.
Regards
Marcel
^ permalink raw reply
* Re: [PATCH] Bluetooth: Use hci_recv_stream_fragment() in UART driver
From: Ville Tervo @ 2010-07-27 8:25 UTC (permalink / raw)
To: ext Gustavo F. Padovan
Cc: linux-bluetooth@vger.kernel.org, marcel@holtmann.org,
Gustavo F. Padovan
In-Reply-To: <1279946817-18060-1-git-send-email-gustavo@padovan.org>
On 07/24/2010 07:46 AM, ext Gustavo F. Padovan wrote:
> From: Gustavo F. Padovan<padovan@profusion.mobi>
>
> Use the new hci_recv_stream_fragment() to reassembly incoming UART
> streams.
>
> Signed-off-by: Gustavo F. Padovan<padovan@profusion.mobi>
> ---
I tried with h4 transport over usb serial. Seems to work like earlier.
Tested-by: Ville Tervo <ville.tervo@nokia.com>
--
Ville
^ permalink raw reply
* L2CAP unknown options
From: Ville Tervo @ 2010-07-27 9:07 UTC (permalink / raw)
To: linux-bluetooth@vger.kernel.org; +Cc: Gustavo F. Padovan
Hi,
I found following problem with bluetooth-next-2.6.
Kernel disconnects if remote device replies with "unknown options"
result code. I guess in that case a new config req should be sent
without unknown option. I didn't check the spec yet.
The remote device is Nokia 9300.
2010-07-27 11:44:07.364827 < ACL data: handle 11 flags 0x02 dlen 10
L2CAP(s): Info req: type 2
2010-07-27 11:44:07.365337 < HCI Command: Remote Name Request
(0x01|0x0019) plen 10
bdaddr 00:12:37:F0:F1:77 mode 2 clkoffset 0x0000
2010-07-27 11:44:07.367793 > HCI Event: Command Status (0x0f) plen 4
Remote Name Request (0x01|0x0019) status 0x00 ncmd 1
2010-07-27 11:44:07.384797 > HCI Event: Max Slots Change (0x1b) plen 3
handle 11 slots 5
2010-07-27 11:44:07.406820 > ACL data: handle 11 flags 0x02 dlen 12
L2CAP(s): Info rsp: type 2 result 1
Not supported
2010-07-27 11:44:07.406849 < ACL data: handle 11 flags 0x02 dlen 12
L2CAP(s): Connect req: psm 1 scid 0x0040
2010-07-27 11:44:07.431790 > HCI Event: Remote Name Req Complete (0x07)
plen 255
status 0x00 bdaddr 00:12:37:F0:F1:77 name 'vt-m'
2010-07-27 11:44:07.433780 > HCI Event: Number of Completed Packets
(0x13) plen 5
handle 11 packets 2
2010-07-27 11:44:07.474801 > ACL data: handle 11 flags 0x02 dlen 16
L2CAP(s): Connect rsp: dcid 0x0042 scid 0x0040 result 1 status 2
Connection pending - Authorization pending
2010-07-27 11:44:07.668818 > ACL data: handle 11 flags 0x02 dlen 16
L2CAP(s): Connect rsp: dcid 0x0042 scid 0x0040 result 0 status 0
Connection successful
2010-07-27 11:44:07.668851 < ACL data: handle 11 flags 0x02 dlen 23
L2CAP(s): Config req: dcid 0x0042 flags 0x00 clen 11
RFC 0x00 (Basic)
2010-07-27 11:44:07.669814 > ACL data: handle 11 flags 0x02 dlen 12
L2CAP(s): Config req: dcid 0x0040 flags 0x00 clen 0
2010-07-27 11:44:07.669840 < ACL data: handle 11 flags 0x02 dlen 18
L2CAP(s): Config rsp: scid 0x0042 flags 0x00 result 0 clen 4
MTU 672
2010-07-27 11:44:07.675794 > HCI Event: Number of Completed Packets
(0x13) plen 5
handle 11 packets 2
2010-07-27 11:44:07.682822 > ACL data: handle 11 flags 0x02 dlen 19
L2CAP(s): Config rsp: scid 0x0040 flags 0x00 result 3 clen 5
Failure - unknown options
RFC QoS 0f 00 42
2010-07-27 11:44:07.682843 < ACL data: handle 11 flags 0x02 dlen 12
L2CAP(s): Disconn req: dcid 0x0042 scid 0x0040
2010-07-27 11:44:07.693823 > ACL data: handle 11 flags 0x02 dlen 12
L2CAP(s): Disconn rsp: dcid 0x0042 scid 0x0040
^ permalink raw reply
* obexd 0.29 and N900 PC Suite
From: Harald Schmitt @ 2010-07-27 11:27 UTC (permalink / raw)
To: linux-bluetooth@vger.kernel.org
Hi,
there are several users who test obexd 0.29 on the Nokia N900 running
Maemo in order to have PBAP support. There are success reports with
PBAP, but at the same time they cannot usb sync via Nokia PC Suite
anymore. Is there any chance to get PC Suite working again in a future
obexd version or does this depend on a non free Nokia code?
Can you give any hints where to look at?
In a forum a user posted success (with 0.19) and failure (with 0.29) logs:
http://talk.maemo.org/showthread.php?p=763550#post763550
Best regards,
Harald
^ permalink raw reply
* [PATCH] De-register pbap drivers on init failure scenarios
From: Counihan, Tom @ 2010-07-27 11:28 UTC (permalink / raw)
To: linux-bluetooth@vger.kernel.org
Unwind the driver registration/phonebook initialization stack on pbap plugin init failure scenarios.
---
plugins/pbap.c | 25 ++++++++++++++++++++-----
1 files changed, 20 insertions(+), 5 deletions(-)
diff --git a/plugins/pbap.c b/plugins/pbap.c
index af4b452..2d3bebd 100644
--- a/plugins/pbap.c
+++ b/plugins/pbap.c
@@ -892,21 +892,36 @@ static int pbap_init(void)
err = phonebook_init();
if (err < 0)
- return err;
+ goto fail_pb_init;
err = obex_mime_type_driver_register(&mime_pull);
if (err < 0)
- return err;
+ goto fail_mime_pull;
err = obex_mime_type_driver_register(&mime_list);
if (err < 0)
- return err;
+ goto fail_mime_list;
err = obex_mime_type_driver_register(&mime_vcard);
if (err < 0)
- return err;
+ goto fail_mime_vcard;
+
+ err = obex_service_driver_register(&pbap);
+ if (err < 0)
+ goto fail_pbap_reg;
- return obex_service_driver_register(&pbap);
+ return 0;
+
+fail_pbap_reg:
+ obex_mime_type_driver_unregister(&mime_vcard);
+fail_mime_vcard:
+ obex_mime_type_driver_unregister(&mime_list);
+fail_mime_list:
+ obex_mime_type_driver_unregister(&mime_pull);
+fail_mime_pull:
+ phonebook_exit();
+fail_pb_init:
+ return err;
}
static void pbap_exit(void)
--
1.7.1.1
--------------------------------------------------------------
Intel Shannon Limited
Registered in Ireland
Registered Office: Collinstown Industrial Park, Leixlip, County Kildare
Registered Number: 308263
Business address: Dromore House, East Park, Shannon, Co. Clare
This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies.
^ permalink raw reply related
* Re: [PATCH 1/3] Add BT3 AMP device support, by Atheros Linux BT3 team.
From: David Vrabel @ 2010-07-27 12:00 UTC (permalink / raw)
To: Dan Tian; +Cc: linux-bluetooth@vger.kernel.org, Haijun Liu, Luis Rodriguez
In-Reply-To: <CDAFEDABF718A54BABD0DA5476695307CE881EC1@SHEXMB-01.global.atheros.com>
What kernel were these diffed against? I'd like to try them out but
they don't apply to mainline.
David
--
David Vrabel, Senior Software Engineer, Drivers
CSR, Churchill House, Cambridge Business Park, Tel: +44 (0)1223 692562
Cowley Road, Cambridge, CB4 0WZ http://www.csr.com/
Member of the CSR plc group of companies. CSR plc registered in England and Wales, registered number 4187346, registered office Churchill House, Cambridge Business Park, Cowley Road, Cambridge, CB4 0WZ, United Kingdom
^ permalink raw reply
* Re: [PATCH] De-register pbap drivers on init failure scenarios
From: Johan Hedberg @ 2010-07-27 12:31 UTC (permalink / raw)
To: Counihan, Tom; +Cc: linux-bluetooth@vger.kernel.org
In-Reply-To: <B09AD526409DF14F8DA79CC5429052C299EE0FC7@irsmsx505.ger.corp.intel.com>
Hi Tom,
On Tue, Jul 27, 2010, Counihan, Tom wrote:
> Unwind the driver registration/phonebook initialization stack on pbap plugin init failure scenarios.
>
>
> ---
> plugins/pbap.c | 25 ++++++++++++++++++++-----
> 1 files changed, 20 insertions(+), 5 deletions(-)
Thanks for the patch! It's now upstream. In the future please pay
attention to your commit message line length. It shouldn't exceed 74
characters (or so) in order to be nicely viewable on a 80-character wide
terminal using git log. I fixed it this time for you manually.
Johan
^ 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