* [PATCH] Fix issues with emails category
From: Lukasz Pawlik @ 2010-08-23 13:45 UTC (permalink / raw)
To: linux-bluetooth
[-- Attachment #1: Type: text/plain, Size: 1 bytes --]
[-- Attachment #2: 0001-Fix-issues-with-emails-category.patch --]
[-- Type: text/x-patch, Size: 5783 bytes --]
From 35e6beaea7a20c42c3bd13af9b18e0883dd33f66 Mon Sep 17 00:00:00 2001
From: Lukasz Pawlik <lucas.pawlik@gmail.com>
Date: Mon, 23 Aug 2010 15:25:20 +0200
Subject: [PATCH] Fix issues with emails category
Previously all emails sent during phonebook pull had the same
category INTERNET. Now email are sent with valid category name
(INTERNET;HOME or INTERNET;WORK)
---
plugins/phonebook-tracker.c | 31 +++++++++++++++++--------
plugins/vcard.c | 53 ++++++++++++++++++++++++++++++++++---------
plugins/vcard.h | 11 +++++++++
3 files changed, 74 insertions(+), 21 deletions(-)
diff --git a/plugins/phonebook-tracker.c b/plugins/phonebook-tracker.c
index 3f63dcb..35742b6 100644
--- a/plugins/phonebook-tracker.c
+++ b/plugins/phonebook-tracker.c
@@ -687,27 +687,38 @@ static void add_phone_number(struct phonebook_contact *contact,
contact->numbers = g_slist_append(contact->numbers, number);
}
-static gchar *find_email(GSList *emails, const char *email)
+static struct phonebook_email *find_email(GSList *emails, const char *address,
+ int type)
{
GSList *l;
- for (l = emails; l; l = l->next)
- if (g_strcmp0(l->data, email) == 0)
- return l->data;
+ for (l = emails; l; l = l->next) {
+ struct phonebook_email *email;
+ email = l->data;
+ if (g_strcmp0(email->address, address) == 0 &&
+ email->type == type)
+ return email;
+ }
return NULL;
}
-static void add_email(struct phonebook_contact *contact, const char *email)
+static void add_email(struct phonebook_contact *contact, const char *address,
+ int type)
{
- if (email == NULL || strlen(email) == 0)
+ struct phonebook_email *email;
+ if (address == NULL || strlen(address) == 0)
return;
/* Not adding email if there is already added with the same value */
- if (find_email(contact->emails, email))
+ if (find_email(contact->emails, address, type))
return;
- contact->emails = g_slist_append(contact->emails, g_strdup(email));
+ email = g_new0(struct phonebook_email, 1);
+ email->address = g_strdup(address);
+ email->type = type;
+
+ contact->emails = g_slist_append(contact->emails, email);
}
static GString *gen_vcards(GSList *contacts,
@@ -817,8 +828,8 @@ add_numbers:
add_phone_number(contact, reply[COL_FAX_NUMBER], TEL_TYPE_FAX);
/* Adding emails */
- add_email(contact, reply[COL_HOME_EMAIL]);
- add_email(contact, reply[COL_WORK_EMAIL]);
+ add_email(contact, reply[COL_HOME_EMAIL], EMAIL_TYPE_HOME);
+ add_email(contact, reply[COL_WORK_EMAIL], EMAIL_TYPE_WORK);
DBG("contact %p", contact);
diff --git a/plugins/vcard.c b/plugins/vcard.c
index 0eed8ae..3b67535 100644
--- a/plugins/vcard.c
+++ b/plugins/vcard.c
@@ -306,19 +306,39 @@ static void vcard_printf_slash_tag(GString *vcards, const char *tag,
vcard_printf(vcards, "%s:%s", buf, field);
}
-static void vcard_printf_email(GString *vcards, const char *email)
+static void vcard_printf_email(GString *vcards, uint8_t format,
+ const char *address,
+ enum phonebook_email_type category)
{
+ const char *category_string = "";
+ char field[LEN_MAX];
int len = 0;
- if (email)
- len = strlen(email);
+ if (!address || !(len = strlen(address)))
+ return;
- if (len) {
- char field[LEN_MAX];
- add_slash(field, email, LEN_MAX, len);
- vcard_printf(vcards,
- "EMAIL;TYPE=INTERNET:%s", field);
+ switch (category){
+ case EMAIL_TYPE_HOME:
+ if (format == FORMAT_VCARD21)
+ category_string = "INTERNET;HOME";
+ else if (format == FORMAT_VCARD30)
+ category_string = "TYPE=INTERNET;TYPE=HOME";
+ break;
+ case EMAIL_TYPE_WORK:
+ if (format == FORMAT_VCARD21)
+ category_string = "INTERNET;WORK";
+ else if (format == FORMAT_VCARD30)
+ category_string = "TYPE=INTERNET;TYPE=WORK";
+ break;
+ default:
+ if (format == FORMAT_VCARD21)
+ category_string = "INTERNET";
+ else if (format == FORMAT_VCARD30)
+ category_string = "TYPE=INTERNET";
}
+
+ add_slash(field, address, LEN_MAX, len);
+ vcard_printf(vcards,"EMAIL;%s:%s", category_string, field);
}
static gboolean org_fields_present(struct phonebook_contact *contact)
@@ -421,8 +441,11 @@ void phonebook_add_contact(GString *vcards, struct phonebook_contact *contact,
if (filter & FILTER_EMAIL) {
GSList *l;
- for (l = contact->emails; l; l = l->next)
- vcard_printf_email(vcards, l->data);
+ for (l = contact->emails; l; l = l->next){
+ struct phonebook_email *email = l->data;
+
+ vcard_printf_email(vcards, format, email->address, email->type);
+ }
}
if (filter & FILTER_ADR)
@@ -459,6 +482,14 @@ static void number_free(gpointer data, gpointer user_data)
g_free(number);
}
+static void email_free(gpointer data, gpointer user_data)
+{
+ struct phonebook_email *email = data;
+
+ g_free(email->address);
+ g_free(email);
+}
+
void phonebook_contact_free(struct phonebook_contact *contact)
{
if (contact == NULL)
@@ -467,7 +498,7 @@ void phonebook_contact_free(struct phonebook_contact *contact)
g_slist_foreach(contact->numbers, number_free, NULL);
g_slist_free(contact->numbers);
- g_slist_foreach(contact->emails, (GFunc) g_free, NULL);
+ g_slist_foreach(contact->emails, email_free, NULL);
g_slist_free(contact->emails);
g_free(contact->fullname);
diff --git a/plugins/vcard.h b/plugins/vcard.h
index 0f52425..a22dfc1 100644
--- a/plugins/vcard.h
+++ b/plugins/vcard.h
@@ -27,6 +27,12 @@ enum phonebook_number_type {
TEL_TYPE_OTHER,
};
+enum phonebook_email_type {
+ EMAIL_TYPE_HOME,
+ EMAIL_TYPE_WORK,
+ EMAIL_TYPE_OTHER,
+};
+
enum phonebook_call_type {
CALL_TYPE_NOT_A_CALL,
CALL_TYPE_MISSED,
@@ -39,6 +45,11 @@ struct phonebook_number {
int type;
};
+struct phonebook_email {
+ char *address;
+ int type;
+};
+
struct phonebook_contact {
char *fullname;
char *given;
--
1.7.0.4
^ permalink raw reply related
* Re: [PATCH v4 0/2] Get and Set Feature Reports on HIDRAW (USB and Bluetooth)
From: Jiri Kosina @ 2010-08-23 13:00 UTC (permalink / raw)
To: Alan Ott
Cc: Stefan Achatz, Antonio Ospite, Alexey Dobriyan, Tejun Heo,
Alan Stern, Greg Kroah-Hartman, Marcel Holtmann, Stephane Chatty,
Michael Poole, David S. Miller, Bastien Nocera, Eric Dumazet,
linux-input, linux-kernel, linux-usb, linux-bluetooth, netdev
In-Reply-To: <1281990059-3562-1-git-send-email-alan@signal11.us>
On Mon, 16 Aug 2010, Alan Ott wrote:
> This is version 4. Built against 2.6.35+ revision 320b2b8de12698 .
>
> Alan Ott (2):
> HID: Add Support for Setting and Getting Feature Reports from hidraw
> Bluetooth: hidp: Add support for hidraw HIDIOCGFEATURE and
> HIDIOCSFEATURE
>
> drivers/hid/hidraw.c | 105 ++++++++++++++++++++++++++++++++++++--
> drivers/hid/usbhid/hid-core.c | 37 +++++++++++++-
> include/linux/hid.h | 3 +
> include/linux/hidraw.h | 3 +
> net/bluetooth/hidp/core.c | 114 +++++++++++++++++++++++++++++++++++++++--
> net/bluetooth/hidp/hidp.h | 8 +++
> 6 files changed, 260 insertions(+), 10 deletions(-)
Marcel, as per our previous discussion -- what is your word on this? I'd
be glad taking it once you Ack the bluetooth bits (which, as far as I
understood from your last mail, don't have strong objections against any
more).
Thanks,
--
Jiri Kosina
SUSE Labs, Novell Inc.
^ permalink raw reply
* Re: [PATCH] Fix issues with emails category
From: Uwe Kleine-König @ 2010-08-23 12:20 UTC (permalink / raw)
To: Lukasz Pawlik; +Cc: linux-bluetooth
In-Reply-To: <AANLkTik_S1g==mJKEQHpKGbFiQALj2nE=UboDBiNfVYY@mail.gmail.com>
Hallo Lukasz,
On Mon, Aug 23, 2010 at 01:18:11PM +0200, Lukasz Pawlik wrote:
> From a537ade2e108a91552e0d9a6c4ff71ca35388e10 Mon Sep 17 00:00:00 2001
> From: Lukasz Pawlik <lucas.pawlik@gmail.com>
> Date: Mon, 23 Aug 2010 12:57:40 +0200
> Subject: [PATCH] Fix issues with emails category
>
> Previously all emails sent during phonebook pull had the same
> category INTERNET. Now email are sent with valid category name
> (INTERNET;HOME or INTERNET;WORK)
> ---
> plugins/phonebook-tracker.c | 30 +++++++++++++++++-------
> plugins/vcard.c | 53 ++++++++++++++++++++++++++++++++++---------
> plugins/vcard.h | 11 +++++++++
> 3 files changed, 74 insertions(+), 20 deletions(-)
>
> diff --git a/plugins/phonebook-tracker.c b/plugins/phonebook-tracker.c
> index 3f63dcb..069e324 100644
> --- a/plugins/phonebook-tracker.c
> +++ b/plugins/phonebook-tracker.c
> @@ -687,27 +687,39 @@ static void add_phone_number(struct phonebook_contact *contact,
> contact->numbers = g_slist_append(contact->numbers, number);
> }
>
> -static gchar *find_email(GSList *emails, const char *email)
> +static struct phonebook_email *find_email(GSList *emails, const char *email,
> + int type)
I assume your tabsize is < 8, because for me "int type" is after the
comma on the preceeding line. I don't know for sure, but I assume bluez
uses the same convention as the kernel, so tabsize is 8. (The functions
below need the same fix.)
Best regards
Uwe
--
Pengutronix e.K. | Uwe Kleine-König |
Industrial Linux Solutions | http://www.pengutronix.de/ |
^ permalink raw reply
* Re: [PATCH] Fix issues with emails category
From: Johan Hedberg @ 2010-08-23 11:42 UTC (permalink / raw)
To: Lukasz Pawlik; +Cc: linux-bluetooth
In-Reply-To: <AANLkTik_S1g==mJKEQHpKGbFiQALj2nE=UboDBiNfVYY@mail.gmail.com>
Hi Lukasz,
On Mon, Aug 23, 2010, Lukasz Pawlik wrote:
> + struct phonebook_email *email_addr;
> +
> + for (l = emails; l; l = l->next) {
> + email_addr = l->data;
Please always define variables in the smallest possible scope. In this
case email_addr can be defined in the beginning of the for-loop instead
of the beginning of the function.
> + if (g_strcmp0(email_addr->email, email) == 0
> + && email_addr->type == type)
> + return email_addr;
Continuation lines should be indented by at least two tabs more than the
original so that they stand out clearly from the actual code that's part
of the subsection. Also, the && goes on the preceeding line.
> -static void add_email(struct phonebook_contact *contact, const char *email)
> +static void add_email(struct phonebook_contact *contact, const char *email,
> + int type)
> {
> + struct phonebook_email *email_addr;
> if (email == NULL || strlen(email) == 0)
> return;
>
> /* Not adding email if there is already added with the same value */
> - if (find_email(contact->emails, email))
> + if (find_email(contact->emails, email, type))
> return;
>
> - contact->emails = g_slist_append(contact->emails, g_strdup(email));
> + email_addr = g_new0(struct phonebook_email, 1);
> + email_addr->email = g_strdup(email);
> + email_addr->type = type;
> +
> + contact->emails = g_slist_append(contact->emails, email_addr);
I'd do some renaming of variables here to make it more readable:
s/email/address/
s/email_address/email/
s/email->email/email->address/
> +struct phonebook_email {
> + char *email;
As mentioned above I'd do a s/email/address/ here.
Johan
^ permalink raw reply
* [PATCH] Fix issues with emails category
From: Lukasz Pawlik @ 2010-08-23 11:18 UTC (permalink / raw)
To: linux-bluetooth
[-- Attachment #1: Type: text/plain, Size: 1 bytes --]
[-- Attachment #2: 0001-Fix-issues-with-emails-category.patch --]
[-- Type: text/x-patch, Size: 5755 bytes --]
From a537ade2e108a91552e0d9a6c4ff71ca35388e10 Mon Sep 17 00:00:00 2001
From: Lukasz Pawlik <lucas.pawlik@gmail.com>
Date: Mon, 23 Aug 2010 12:57:40 +0200
Subject: [PATCH] Fix issues with emails category
Previously all emails sent during phonebook pull had the same
category INTERNET. Now email are sent with valid category name
(INTERNET;HOME or INTERNET;WORK)
---
plugins/phonebook-tracker.c | 30 +++++++++++++++++-------
plugins/vcard.c | 53 ++++++++++++++++++++++++++++++++++---------
plugins/vcard.h | 11 +++++++++
3 files changed, 74 insertions(+), 20 deletions(-)
diff --git a/plugins/phonebook-tracker.c b/plugins/phonebook-tracker.c
index 3f63dcb..069e324 100644
--- a/plugins/phonebook-tracker.c
+++ b/plugins/phonebook-tracker.c
@@ -687,27 +687,39 @@ static void add_phone_number(struct phonebook_contact *contact,
contact->numbers = g_slist_append(contact->numbers, number);
}
-static gchar *find_email(GSList *emails, const char *email)
+static struct phonebook_email *find_email(GSList *emails, const char *email,
+ int type)
{
GSList *l;
- for (l = emails; l; l = l->next)
- if (g_strcmp0(l->data, email) == 0)
- return l->data;
+ struct phonebook_email *email_addr;
+
+ for (l = emails; l; l = l->next) {
+ email_addr = l->data;
+ if (g_strcmp0(email_addr->email, email) == 0
+ && email_addr->type == type)
+ return email_addr;
+ }
return NULL;
}
-static void add_email(struct phonebook_contact *contact, const char *email)
+static void add_email(struct phonebook_contact *contact, const char *email,
+ int type)
{
+ struct phonebook_email *email_addr;
if (email == NULL || strlen(email) == 0)
return;
/* Not adding email if there is already added with the same value */
- if (find_email(contact->emails, email))
+ if (find_email(contact->emails, email, type))
return;
- contact->emails = g_slist_append(contact->emails, g_strdup(email));
+ email_addr = g_new0(struct phonebook_email, 1);
+ email_addr->email = g_strdup(email);
+ email_addr->type = type;
+
+ contact->emails = g_slist_append(contact->emails, email_addr);
}
static GString *gen_vcards(GSList *contacts,
@@ -817,8 +829,8 @@ add_numbers:
add_phone_number(contact, reply[COL_FAX_NUMBER], TEL_TYPE_FAX);
/* Adding emails */
- add_email(contact, reply[COL_HOME_EMAIL]);
- add_email(contact, reply[COL_WORK_EMAIL]);
+ add_email(contact, reply[COL_HOME_EMAIL], EMAIL_TYPE_HOME);
+ add_email(contact, reply[COL_WORK_EMAIL], EMAIL_TYPE_WORK);
DBG("contact %p", contact);
diff --git a/plugins/vcard.c b/plugins/vcard.c
index 0eed8ae..425ac71 100644
--- a/plugins/vcard.c
+++ b/plugins/vcard.c
@@ -306,19 +306,39 @@ static void vcard_printf_slash_tag(GString *vcards, const char *tag,
vcard_printf(vcards, "%s:%s", buf, field);
}
-static void vcard_printf_email(GString *vcards, const char *email)
+static void vcard_printf_email(GString *vcards, uint8_t format,
+ const char *email,
+ enum phonebook_email_type category)
{
+ const char *category_string = "";
+ char field[LEN_MAX];
int len = 0;
- if (email)
- len = strlen(email);
+ if (!email || !(len = strlen(email)))
+ return;
- if (len) {
- char field[LEN_MAX];
- add_slash(field, email, LEN_MAX, len);
- vcard_printf(vcards,
- "EMAIL;TYPE=INTERNET:%s", field);
+ switch (category){
+ case EMAIL_TYPE_HOME:
+ if (format == FORMAT_VCARD21)
+ category_string = "INTERNET;HOME";
+ else if (format == FORMAT_VCARD30)
+ category_string = "TYPE=INTERNET;TYPE=HOME";
+ break;
+ case EMAIL_TYPE_WORK:
+ if (format == FORMAT_VCARD21)
+ category_string = "INTERNET;WORK";
+ else if (format == FORMAT_VCARD30)
+ category_string = "TYPE=INTERNET;TYPE=WORK";
+ break;
+ default:
+ if (format == FORMAT_VCARD21)
+ category_string = "INTERNET";
+ else if (format == FORMAT_VCARD30)
+ category_string = "TYPE=INTERNET";
}
+
+ add_slash(field, email, LEN_MAX, len);
+ vcard_printf(vcards,"EMAIL;%s:%s", category_string, field);
}
static gboolean org_fields_present(struct phonebook_contact *contact)
@@ -421,8 +441,11 @@ void phonebook_add_contact(GString *vcards, struct phonebook_contact *contact,
if (filter & FILTER_EMAIL) {
GSList *l;
- for (l = contact->emails; l; l = l->next)
- vcard_printf_email(vcards, l->data);
+ for (l = contact->emails; l; l = l->next){
+ struct phonebook_email *email = l->data;
+
+ vcard_printf_email(vcards, format, email->email, email->type);
+ }
}
if (filter & FILTER_ADR)
@@ -459,6 +482,14 @@ static void number_free(gpointer data, gpointer user_data)
g_free(number);
}
+static void email_free(gpointer data, gpointer user_data)
+{
+ struct phonebook_email *email = data;
+
+ g_free(email->email);
+ g_free(email);
+}
+
void phonebook_contact_free(struct phonebook_contact *contact)
{
if (contact == NULL)
@@ -467,7 +498,7 @@ void phonebook_contact_free(struct phonebook_contact *contact)
g_slist_foreach(contact->numbers, number_free, NULL);
g_slist_free(contact->numbers);
- g_slist_foreach(contact->emails, (GFunc) g_free, NULL);
+ g_slist_foreach(contact->emails, email_free, NULL);
g_slist_free(contact->emails);
g_free(contact->fullname);
diff --git a/plugins/vcard.h b/plugins/vcard.h
index 0f52425..41423e0 100644
--- a/plugins/vcard.h
+++ b/plugins/vcard.h
@@ -27,6 +27,12 @@ enum phonebook_number_type {
TEL_TYPE_OTHER,
};
+enum phonebook_email_type {
+ EMAIL_TYPE_HOME,
+ EMAIL_TYPE_WORK,
+ EMAIL_TYPE_OTHER,
+};
+
enum phonebook_call_type {
CALL_TYPE_NOT_A_CALL,
CALL_TYPE_MISSED,
@@ -39,6 +45,11 @@ struct phonebook_number {
int type;
};
+struct phonebook_email {
+ char *email;
+ int type;
+};
+
struct phonebook_contact {
char *fullname;
char *given;
--
1.7.0.4
^ permalink raw reply related
* data misalignment in l2cap_get_conf_opt
From: real mz @ 2010-08-23 9:42 UTC (permalink / raw)
To: linux-bluetooth
I met data misalignment exeception when using USB bt card. The fault
address is in l2cap_get_conf_opt() line 2296.
2290 switch (opt->len) {
2291 case 1:
2292 *val = *((u8 *) opt->val);
2293 break;
2294
2295 case 2:
2296 *val = __le16_to_cpu(*((__le16 *) opt->val));
2297 break;
2298
2299 case 4:
2300 *val = __le32_to_cpu(*((__le32 *) opt->val));
2301 break;
The address of opt->val is not 2-bytes aligned. actually this val is
read from conf_req[64] of struct l2cap_info, I think this opt->val can
not guarantee it is 2-bytes or 4-bytes aligned,
2296 *val = __le16_to_cpu(*((__le16 *) opt->val));
2300 *val = __le32_to_cpu(*((__le32 *) opt->val));
will cause misalignment fault in some processor that not support
unaligned access.
l2cap_pinfo struct:
306struct l2cap_pinfo {
307 struct bt_sock bt;
308 __le16 psm;
309 __u16 dcid;
310 __u16 scid;
311
312 __u16 imtu;
313 __u16 omtu;
314 __u16 flush_to;
315 __u8 mode;
316 __u8 num_conf_req;
317 __u8 num_conf_rsp;
318
319 __u8 fcs;
320 __u8 sec_level;
321 __u8 role_switch;
322 __u8 force_reliable;
323
324 __u8 conf_req[64];
...
Steven
^ permalink raw reply
* [RFCOMM] Cannot complete connections into Ubuntu
From: Shreesh Holla @ 2010-08-23 7:22 UTC (permalink / raw)
To: linux-bluetooth
Hi,
I'm running Ubuntu with 2.6.32.24 kernel.
I have a simple RFCOMM program running on Windows Mobile which would connect
into the Ubuntu machine. Of course I have the corresponding service running on
the Ubuntu machine. The RFCOMM port numbers do match up.
This was working a few days back and now with no changes(i.e. the same
executable), it refuses to work anymore.
So is there some configuration needed now?
I have the dongle running in Ubuntu as : hciconfig hci0 noauth noencrypt pscan
Thanks,
Shreesh
^ permalink raw reply
* RE: [PATCH 0/8] Clean up Obex btio.[ch] and make it self contained
From: Zhang, Zhenhua @ 2010-08-23 1:13 UTC (permalink / raw)
To: Luiz Augusto von Dentz; +Cc: linux-bluetooth@vger.kernel.org
In-Reply-To: <AANLkTi=B=GoXrymjfKAnXuRDiTe7Uxqdiqs831nsWRb-@mail.gmail.com>
Hi Luiz,
Luiz Augusto von Dentz wrote:
> Hi,
>
> On Thu, Aug 19, 2010 at 5:21 PM, Zhenhua Zhang
> <zhenhua.zhang@intel.com> wrote:
>> Hi,
>>
>> This series of patches is to seperate btio.[ch] from src to btio
>> directory. To make btio.[ch] self contained for obexd, there're some
>> cleanup work:
>
> Sounds good, this should make it easier to maintain those in sync with
> other projects using it.
>
>> 1. remove unused bt_io_set(). It is neither used by bluez or obexd.
>> 2. remove unused SCO/L2RAW related code for Obexd. Note: BlueZ code
>> requires SCO/L2RAW related functions. We may consider to add them
>> back later.
>
> Im not so sure if we want to have this code removed, obviously after
> that in case of changes/fixes they may not apply cleanly in all
> projects, so keeping them in sync won't be as easy anymore.
You're right. For such code used in BlueZ, I will keep them to make sync easier. So now I am cleaning up BlueZ's btio.[ch]. Before I complete that part, I just want to send out what I plan to change for btio.[ch] to collect review comments earlier. The patches for BlueZ will be send out later.
>> 3. replace void *userdata with gpointer userdata. To make it
>> consistent with bluez btio.c
>> 4. refactor hci_devba into devid2ba. Remove dependence with hci*.h
>> 5. Remove libbluetooth dependence for obexd.
>
> This is fine as long as the other copies have this changes too.
Regards,
Zhenhua
^ permalink raw reply
* Re: 2.6.36-rc1 on zaurus: bluetooth regression
From: Marek Vasut @ 2010-08-21 17:32 UTC (permalink / raw)
To: linux-arm-kernel
Cc: Pavel Machek, rpurdie, lenz, kernel list, arminlitzel,
Cyril Hrubis, thommycheck, dbaryshkov, omegamoon, eric.y.miao,
utx, zaurus-devel, Rafael J. Wysocki, linux-bluetooth
In-Reply-To: <20100821152445.GA1536@ucw.cz>
Dne So 21. srpna 2010 17:24:45 Pavel Machek napsal(a):
> Hi!
>
> Good news is that it boots, suspends and resumes.
>
> Bad news is that bluetooth broke for me. I'm using CF bluetooth
> card.
>
> Socket 0 Bridge: [pxa2xx-pcmcia] (bus ID: pxa2xx-pcmcia)
> Configuration: state: on ready: yes
> Voltage: 3.3V Vcc: 3.3V Vpp: 0.0V
> Socket 0 Device 0: [serial_cs] (bus ID: 0.0)
> Configuration: state: on
> Product Name: Compact Flash Bluetooth Card
> Identification: manf_id: 0x0279 card_id: 0x950b
> function: 2 (serial)
> prod_id(1): "Compact Flash" (0x95521410)
> prod_id(2): "Bluetooth Card" (0x7664fb1d)
> prod_id(3): --- (---)
> prod_id(4): --- (---)
> Socket 1 Bridge: [pxa2xx-pcmcia] (bus ID: pxa2xx-pcmcia)
> Configuration: state: on ready: yes
> Voltage: 3.3V Vcc: 3.3V Vpp: 0.0V
> Socket 1 Device 0: [ide-cs] (bus ID: 1.0)
> Configuration: state: on
> Product Name: HITACHI microdrive
> Identification: manf_id: 0x0319 card_id: 0x0000
> function: 4 (fixed disk)
> prod_id(1): "HITACHI" (0xf4f43949)
> prod_id(2): "microdrive" (0xa6d76178)
> prod_id(3): --- (---)
> prod_id(4): --- (---)
>
>
> In 2.6.35, I have lots of messages in the syslog, and speed is slow,
> but it works.
>
> Aug 19 08:01:06 toy kernel: bcsp_recv: Out-of-order packet arrived, got 3
> expected 2 Aug 19 08:01:06 toy kernel: bcsp_recv: Out-of-order packet
> arrived, got 4 expected 2 Aug 19 08:01:11 toy kernel: bcsp_recv: Short
> BCSP packet
> Aug 19 08:01:11 toy kernel: bcsp_recv: Out-of-order packet arrived, got 3
> expected 2 Aug 19 08:01:11 toy kernel: bcsp_recv: Out-of-order packet
> arrived, got 4 expected 2 Aug 19 08:01:12 toy kernel: bcsp_recv:
> Out-of-order packet arrived, got 5 expected 2 Aug 19 08:01:16 toy kernel:
> bcsp_recv: Short BCSP packet
> Aug 19 08:01:16 toy kernel: bcsp_recv: Out-of-order packet arrived, got 2
> expected 1 Aug 19 08:01:16 toy kernel: bcsp_recv: Out-of-order packet
> arrived, got 3 expected 1 Aug 19 08:01:16 toy kernel: bcsp_recv:
> Out-of-order packet arrived, got 4 expected 1
>
> In 2.6.36-rc1, I get:
>
> Aug 20 08:38:27 toy bluetoothd[1318]: HCI dev 0 down
> Aug 20 08:38:27 toy bluetoothd[1318]: Adapter /org/bluez/1318/hci0 has been
> disabled Aug 20 08:38:27 toy bluetoothd[1318]: Stopping security manager 0
> Aug 20 08:38:27 toy kernel: pcmcia_socket pcmcia_socket0: pccard: card
> ejected from slot 0 Aug 20 08:38:27 toy kernel: PM: Removing info for
> pcmcia:0.0
> Aug 20 08:38:27 toy kernel: PM: Removing info for No Bus:ttyS0
> Aug 20 08:38:27 toy bluetoothd[1318]: HCI dev 0 unregistered
> Aug 20 08:38:27 toy bluetoothd[1318]: Unregister path: /org/bluez/1318/hci0
> Aug 20 08:38:27 toy kernel: PM: Removing info for No Bus:hci0
> Aug 20 08:38:27 toy kernel: PM: Adding info for No Bus:ttyS0
> Aug 20 08:38:31 toy kernel: pcmcia_socket pcmcia_socket0: pccard: PCMCIA
> card inserted into slot 0 Aug 20 08:38:31 toy kernel: pcmcia 0.0: pcmcia:
> registering new device pcmcia0.0 (IRQ: 201) Aug 20 08:38:31 toy kernel:
> PM: Adding info for pcmcia:0.0
> Aug 20 08:38:31 toy kernel: PM: Removing info for No Bus:ttyS0
> Aug 20 08:38:31 toy kernel: 0.0: ttyS0 at I/O 0xc48402f8 (irq = 201) is a
> 16C950/954 Aug 20 08:38:31 toy kernel: PM: Adding info for No Bus:ttyS0
> Aug 20 08:38:36 toy bluetoothd[1318]: HCI dev 0 registered
> Aug 20 08:38:36 toy kernel: PM: Adding info for No Bus:hci0
> Aug 20 08:38:36 toy kernel: bcsp_recv: Out-of-order packet arrived, got 1
> expected 0 Aug 20 08:38:37 toy bluetoothd[1318]: accept: Socket operation
> on non-socket (88) Aug 20 08:38:37 toy bluetoothd[1318]: HCI dev 0 up
> Aug 20 08:38:37 toy bluetoothd[1318]: Starting security manager 0
> Aug 20 08:38:37 toy kernel: bcsp_recv: Short BCSP packet
> Aug 20 08:38:39 toy kernel: PM: Removing info for No Bus:rfcomm1
> Aug 20 08:38:39 toy kernel: PM: Adding info for No Bus:rfcomm1
> Aug 20 08:38:40 toy pand[1546]: Bluetooth PAN daemon version 4.66
> Aug 20 08:38:40 toy pand[1546]: Connecting to 00:21:BA:FF:2D:37
> Aug 20 08:38:40 toy kernel: hci_cmd_task: hci0 command tx timeout
> Aug 20 08:38:42 toy bluetoothd[1318]: Can't read version info for
> /org/bluez/1318/hci0: Connection timed out (110) Aug 20 08:38:44 toy
> modprobe: FATAL: Could not load /lib/modules/2.6.36-rc1/modules.dep: No
> such file or directory
>
> Any ideas?
> Pavel
Could it be due to the PCMCIA timings changes on pxa I did? Try reverting that
change and retry.
^ permalink raw reply
* 2.6.36-rc1 on zaurus: bluetooth regression
From: Pavel Machek @ 2010-08-21 15:24 UTC (permalink / raw)
To: rpurdie, lenz, kernel list, arminlitzel, Cyril Hrubis,
thommycheck, linux-arm-kernel, dbaryshkov, omegamoon, eric.y.miao,
utx, zaurus-devel, Rafael J. Wysocki, linux-bluetooth
Hi!
Good news is that it boots, suspends and resumes.
Bad news is that bluetooth broke for me. I'm using CF bluetooth
card.
Socket 0 Bridge: [pxa2xx-pcmcia] (bus ID: pxa2xx-pcmcia)
Configuration: state: on ready: yes
Voltage: 3.3V Vcc: 3.3V Vpp: 0.0V
Socket 0 Device 0: [serial_cs] (bus ID: 0.0)
Configuration: state: on
Product Name: Compact Flash Bluetooth Card
Identification: manf_id: 0x0279 card_id: 0x950b
function: 2 (serial)
prod_id(1): "Compact Flash" (0x95521410)
prod_id(2): "Bluetooth Card" (0x7664fb1d)
prod_id(3): --- (---)
prod_id(4): --- (---)
Socket 1 Bridge: [pxa2xx-pcmcia] (bus ID: pxa2xx-pcmcia)
Configuration: state: on ready: yes
Voltage: 3.3V Vcc: 3.3V Vpp: 0.0V
Socket 1 Device 0: [ide-cs] (bus ID: 1.0)
Configuration: state: on
Product Name: HITACHI microdrive
Identification: manf_id: 0x0319 card_id: 0x0000
function: 4 (fixed disk)
prod_id(1): "HITACHI" (0xf4f43949)
prod_id(2): "microdrive" (0xa6d76178)
prod_id(3): --- (---)
prod_id(4): --- (---)
In 2.6.35, I have lots of messages in the syslog, and speed is slow,
but it works.
Aug 19 08:01:06 toy kernel: bcsp_recv: Out-of-order packet arrived, got 3 expected 2
Aug 19 08:01:06 toy kernel: bcsp_recv: Out-of-order packet arrived, got 4 expected 2
Aug 19 08:01:11 toy kernel: bcsp_recv: Short BCSP packet
Aug 19 08:01:11 toy kernel: bcsp_recv: Out-of-order packet arrived, got 3 expected 2
Aug 19 08:01:11 toy kernel: bcsp_recv: Out-of-order packet arrived, got 4 expected 2
Aug 19 08:01:12 toy kernel: bcsp_recv: Out-of-order packet arrived, got 5 expected 2
Aug 19 08:01:16 toy kernel: bcsp_recv: Short BCSP packet
Aug 19 08:01:16 toy kernel: bcsp_recv: Out-of-order packet arrived, got 2 expected 1
Aug 19 08:01:16 toy kernel: bcsp_recv: Out-of-order packet arrived, got 3 expected 1
Aug 19 08:01:16 toy kernel: bcsp_recv: Out-of-order packet arrived, got 4 expected 1
In 2.6.36-rc1, I get:
Aug 20 08:38:27 toy bluetoothd[1318]: HCI dev 0 down
Aug 20 08:38:27 toy bluetoothd[1318]: Adapter /org/bluez/1318/hci0 has been disabled
Aug 20 08:38:27 toy bluetoothd[1318]: Stopping security manager 0
Aug 20 08:38:27 toy kernel: pcmcia_socket pcmcia_socket0: pccard: card ejected from slot 0
Aug 20 08:38:27 toy kernel: PM: Removing info for pcmcia:0.0
Aug 20 08:38:27 toy kernel: PM: Removing info for No Bus:ttyS0
Aug 20 08:38:27 toy bluetoothd[1318]: HCI dev 0 unregistered
Aug 20 08:38:27 toy bluetoothd[1318]: Unregister path: /org/bluez/1318/hci0
Aug 20 08:38:27 toy kernel: PM: Removing info for No Bus:hci0
Aug 20 08:38:27 toy kernel: PM: Adding info for No Bus:ttyS0
Aug 20 08:38:31 toy kernel: pcmcia_socket pcmcia_socket0: pccard: PCMCIA card inserted into slot 0
Aug 20 08:38:31 toy kernel: pcmcia 0.0: pcmcia: registering new device pcmcia0.0 (IRQ: 201)
Aug 20 08:38:31 toy kernel: PM: Adding info for pcmcia:0.0
Aug 20 08:38:31 toy kernel: PM: Removing info for No Bus:ttyS0
Aug 20 08:38:31 toy kernel: 0.0: ttyS0 at I/O 0xc48402f8 (irq = 201) is a 16C950/954
Aug 20 08:38:31 toy kernel: PM: Adding info for No Bus:ttyS0
Aug 20 08:38:36 toy bluetoothd[1318]: HCI dev 0 registered
Aug 20 08:38:36 toy kernel: PM: Adding info for No Bus:hci0
Aug 20 08:38:36 toy kernel: bcsp_recv: Out-of-order packet arrived, got 1 expected 0
Aug 20 08:38:37 toy bluetoothd[1318]: accept: Socket operation on non-socket (88)
Aug 20 08:38:37 toy bluetoothd[1318]: HCI dev 0 up
Aug 20 08:38:37 toy bluetoothd[1318]: Starting security manager 0
Aug 20 08:38:37 toy kernel: bcsp_recv: Short BCSP packet
Aug 20 08:38:39 toy kernel: PM: Removing info for No Bus:rfcomm1
Aug 20 08:38:39 toy kernel: PM: Adding info for No Bus:rfcomm1
Aug 20 08:38:40 toy pand[1546]: Bluetooth PAN daemon version 4.66
Aug 20 08:38:40 toy pand[1546]: Connecting to 00:21:BA:FF:2D:37
Aug 20 08:38:40 toy kernel: hci_cmd_task: hci0 command tx timeout
Aug 20 08:38:42 toy bluetoothd[1318]: Can't read version info for /org/bluez/1318/hci0: Connection timed out (110)
Aug 20 08:38:44 toy modprobe: FATAL: Could not load /lib/modules/2.6.36-rc1/modules.dep: No such file or directory
Any ideas?
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
^ permalink raw reply
* Re: [PATCH] Makefile.am fixes
From: Marcel J.E. Mol @ 2010-08-21 12:47 UTC (permalink / raw)
To: Marcel Holtmann; +Cc: linux-bluetooth
In-Reply-To: <1282379964.23399.223.camel@localhost.localdomain>
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset*=utf-8''%E2%80%9Cus-ascii, Size: 1388 bytes --]
On Sat, Aug 21, 2010 at 10:39:24AM +0200, Marcel Holtmann wrote:
> Hi Marcel,
>
> > phonebook.h should not be under _nodist.
>
> yes it should. It is auto-generated.
Hm, I don't think phonebook.h is generated, phonebook.c more
or less is.... But anyway, this part of the change message is bogus.
Phonebook.h was not part of builtin_nodist.
Sorry about that. I'll resend the patch without this sentence.
> > vcard.[ch] is not related to pbap, but to phonebook backend
> > ---
> > Makefile.am | 6 +++---
> > 1 files changed, 3 insertions(+), 3 deletions(-)
>
> Did you verify that "fakeroot make distcheck" still works properly after
> your changes?
This fails with an error message about builtin.h. But the same error
happens without the Makefile.am patch.
(probably because distcheck builds in a separate builddir apart from
the actual source tree and builtin.h is generated in the builddir tree)
Thanks,
-Marcel
--
======-------- Marcel J.E. Mol MESA Consulting B.V.
=======--------- ph. +31-(0)6-54724868 P.O. Box 112
=======--------- marcel@mesa.nl 2630 AC Nootdorp
__==== www.mesa.nl ---____U_n_i_x______I_n_t_e_r_n_e_t____ The Netherlands ____
They couldn't think of a number, Linux user 1148 -- counter.li.org
so they gave me a name! -- Rupert Hine -- www.ruperthine.com
^ permalink raw reply
* Re: [PATCH] Makefile.am fixes
From: Marcel Holtmann @ 2010-08-21 8:39 UTC (permalink / raw)
To: Marcel Mol; +Cc: linux-bluetooth
In-Reply-To: <201008201635.o7KGZLs1009991@joshua.mesa.nl>
Hi Marcel,
> phonebook.h should not be under _nodist.
yes it should. It is auto-generated.
> vcard.[ch] is not related to pbap, but to phonebook backend
> ---
> Makefile.am | 6 +++---
> 1 files changed, 3 insertions(+), 3 deletions(-)
Did you verify that "fakeroot make distcheck" still works properly after
your changes?
Regards
Marcel
^ permalink raw reply
* Re: HCIConfig - BD Address not updated automatically
From: Marcel Holtmann @ 2010-08-21 8:36 UTC (permalink / raw)
To: Cayetanot, Sebastien; +Cc: linux-bluetooth@vger.kernel.org
In-Reply-To: <79C392C3A040A44895195AED5DB296F7AC3F2A46@irsmsx502.ger.corp.intel.com>
Hi Sebastien,
> I'm currently facing an issue regarding the command hciconfig.
>
> On my device :
>
> I have run hciconfig hci0 in order to check if the hci interface is up and to get the BD_Addr.
>
> I sent an hcitool cmd to change the BD_Addr. The command is accepted.
>
> Just after I run the Ifconfig command but the BD_Addr is not changed it still the old one.
>
> If I use a linux laptop to scan BT device, the device is seen with changed BD_Addr.
>
> I have sent the hci command manually to read th BD_Addr on my device and the BD_Addr return is the one modified.
>
> Just after by running Ifconfig, the BD_Addr is updated.
>
> Is it normal that hciconfig never read the BD_Addr automatically ? even if I do a HIC reset.
>
> My feeling is that the BD_Addr is read one time at the beginning and never updated until we manually read the BD_Addr using the hci command.
>
> Any idea?
this pretty simple, only because you change the BD_ADDR with its vendor
command, it is not magically being used. Neither in software nor in the
firmware of the device. You need to do a soft reset to make this address
active. And then ensure that the kernel HCI layer knows that the reset
has happened.
Which hardware manufacture is this and what type of transport are you
using?
Regards
Marcel
^ permalink raw reply
* Re: [PATCH v3] Firmware download for Qualcomm Bluetooth devices
From: Johan Hedberg @ 2010-08-20 22:37 UTC (permalink / raw)
To: Matthew Wilson; +Cc: linux-bluetooth, marcel, rshaffer
In-Reply-To: <1282340251-10676-1-git-send-email-mtwilson@codeaurora.org>
Hi Matt,
On Fri, Aug 20, 2010, Matthew Wilson wrote:
> Configures device address from hciattach parameter.
> UART speed limited to 115200.
> Requires separate device specific firmware.
> ---
> Makefile.tools | 3 +-
> tools/hciattach.c | 10 ++
> tools/hciattach.h | 1 +
> tools/hciattach_qualcomm.c | 279 ++++++++++++++++++++++++++++++++++++++++++++
> 4 files changed, 292 insertions(+), 1 deletions(-)
> create mode 100644 tools/hciattach_qualcomm.c
Thanks, the patch applies cleanly now. However, I spotted a couple of
whitespace/coding style issues that would be good to get fixed before
pushing this upstream:
> +#define FAILIF(x, args...) do { \
> + if (x) { \
> + fprintf(stderr, ##args); \
> + return -1; \
> + } \
> +} while(0)
Before each \ at the end of the line you use a mix of tabs and spaces.
Please just use tabs.
> +typedef struct {
> + uint8_t uart_prefix;
> + hci_event_hdr hci_hdr;
> + evt_cmd_complete cmd_complete;
> + uint8_t status;
> + uint8_t data[16];
> +} __attribute__((packed)) command_complete_t;
> +
> +
Why the two consecutive empty lines? Please remove one.
> +static int read_command_complete(int fd, unsigned short opcode, unsigned char len) {
This one looks like it goes beyond 80 columns. Please split it. Also,
the coding style is to put the opening brace of a function on its own
line.
> + FAILIF(resp.hci_hdr.evt != EVT_CMD_COMPLETE, /* event must be event-complete */
> + "Error in response: not a cmd-complete event, "
> + "but 0x%02x!\n", resp.hci_hdr.evt);
Mixed tabs and spaces for indentation. Please just use tabs.
> + FAILIF(resp.hci_hdr.plen < 4, /* plen >= 4 for EVT_CMD_COMPLETE */
> + "Error in response: plen is not >= 4, but 0x%02x!\n",
> + resp.hci_hdr.plen);
Same here.
> +
> + /* cmd-complete event: opcode */
> + FAILIF(resp.cmd_complete.opcode != 0,
> + "Error in response: opcode is 0x%04x, not 0!",
> + resp.cmd_complete.opcode);
And here.
> +static int qualcomm_load_firmware(int fd, const char *firmware, const char *bdaddr_s) {
This one goes beyond 80 columns too and the opening brace should be on
its own line.
> + FAILIF(fw < 0,
> + "Could not open firmware file %s: %s (%d).\n",
> + firmware, strerror(errno), errno);
Mixed tabs and spaces for indentation.
> + FAILIF(read(fw, data, cmd->plen) != cmd->plen,
> + "Could not read %d bytes of data for command with opcode %04x!\n",
> + cmd->plen,
> + cmd->opcode);
Same here.
> + FAILIF(nw != (int) sizeof(cmdp) + cmd->plen,
> + "Could not send entire command (sent only %d bytes)!\n",
> + nw);
And here.
> + if (read_command_complete(fd,
> + cmd->opcode,
> + cmd->plen) < 0) {
And here. Why do you split it into three lines when it all fits within
80 columns?
Johan
^ permalink raw reply
* HCIConfig - BD Address not updated automatically
From: Cayetanot, Sebastien @ 2010-08-20 22:15 UTC (permalink / raw)
To: linux-bluetooth@vger.kernel.org
All,
I'm currently facing an issue regarding the command hciconfig.
On my device :
I have run hciconfig hci0 in order to check if the hci interface is up and to get the BD_Addr.
I sent an hcitool cmd to change the BD_Addr. The command is accepted.
Just after I run the Ifconfig command but the BD_Addr is not changed it still the old one.
If I use a linux laptop to scan BT device, the device is seen with changed BD_Addr.
I have sent the hci command manually to read th BD_Addr on my device and the BD_Addr return is the one modified.
Just after by running Ifconfig, the BD_Addr is updated.
Is it normal that hciconfig never read the BD_Addr automatically ? even if I do a HIC reset.
My feeling is that the BD_Addr is read one time at the beginning and never updated until we manually read the BD_Addr using the hci command.
Any idea?
Regards
---------------------------------------------------------------------
Intel Corporation SAS (French simplified joint stock company)
Registered headquarters: "Les Montalets"- 2, rue de Paris,
92196 Meudon Cedex, France
Registration Number: 302 456 199 R.C.S. NANTERRE
Capital: 4,572,000 Euros
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
* [PATCH v3] Firmware download for Qualcomm Bluetooth devices
From: Matthew Wilson @ 2010-08-20 21:37 UTC (permalink / raw)
To: linux-bluetooth; +Cc: marcel, johan.hedberg, rshaffer, Matthew Wilson
In-Reply-To: <4C6BFF05.5040506@codeaurora.org>
Configures device address from hciattach parameter.
UART speed limited to 115200.
Requires separate device specific firmware.
---
Makefile.tools | 3 +-
tools/hciattach.c | 10 ++
tools/hciattach.h | 1 +
tools/hciattach_qualcomm.c | 279 ++++++++++++++++++++++++++++++++++++++++++++
4 files changed, 292 insertions(+), 1 deletions(-)
create mode 100644 tools/hciattach_qualcomm.c
diff --git a/Makefile.tools b/Makefile.tools
index 8ee1972..1c46542 100644
--- a/Makefile.tools
+++ b/Makefile.tools
@@ -24,7 +24,8 @@ tools_hciattach_SOURCES = tools/hciattach.c tools/hciattach.h \
tools/hciattach_st.c \
tools/hciattach_ti.c \
tools/hciattach_tialt.c \
- tools/hciattach_ath3k.c
+ tools/hciattach_ath3k.c \
+ tools/hciattach_qualcomm.c
tools_hciattach_LDADD = lib/libbluetooth.la
tools_hciconfig_SOURCES = tools/hciconfig.c tools/csr.h tools/csr.c \
diff --git a/tools/hciattach.c b/tools/hciattach.c
index 5662f57..ad2afa4 100644
--- a/tools/hciattach.c
+++ b/tools/hciattach.c
@@ -312,6 +312,11 @@ static int ath3k_pm(int fd, struct uart_t *u, struct termios *ti)
return ath3k_post(fd, u->pm);
}
+static int qualcomm(int fd, struct uart_t *u, struct termios *ti)
+{
+ return qualcomm_init(fd, u->speed, ti, u->bdaddr);
+}
+
static int read_check(int fd, void *buf, int count)
{
int res;
@@ -1116,6 +1121,11 @@ struct uart_t uart[] = {
{ "ath3k", 0x0000, 0x0000, HCI_UART_ATH3K, 115200, 115200,
FLOW_CTL, DISABLE_PM, NULL, ath3k_ps, ath3k_pm },
+
+ /* QUALCOMM BTS */
+ { "qualcomm", 0x0000, 0x0000, HCI_UART_H4, 115200, 115200,
+ FLOW_CTL, NULL, qualcomm },
+
{ NULL, 0 }
};
diff --git a/tools/hciattach.h b/tools/hciattach.h
index c133321..2d26b77 100644
--- a/tools/hciattach.h
+++ b/tools/hciattach.h
@@ -52,3 +52,4 @@ int stlc2500_init(int fd, bdaddr_t *bdaddr);
int bgb2xx_init(int dd, bdaddr_t *bdaddr);
int ath3k_init(int fd, char *bdaddr, int speed);
int ath3k_post(int fd, int pm);
+int qualcomm_init(int fd, int speed, struct termios *ti, const char *bdaddr);
diff --git a/tools/hciattach_qualcomm.c b/tools/hciattach_qualcomm.c
new file mode 100644
index 0000000..31ca3c8
--- /dev/null
+++ b/tools/hciattach_qualcomm.c
@@ -0,0 +1,279 @@
+/*
+ *
+ * BlueZ - Bluetooth protocol stack for Linux
+ *
+ * Copyright (C) 2005-2010 Marcel Holtmann <marcel@holtmann.org>
+ * Copyright (c) 2010, Code Aurora Forum. All rights reserved.
+ *
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA
+ *
+ */
+
+#ifdef HAVE_CONFIG_H
+#include <config.h>
+#endif
+
+#include <stdio.h>
+#include <errno.h>
+#include <fcntl.h>
+#include <unistd.h>
+#include <stdlib.h>
+#include <string.h>
+#include <signal.h>
+#include <syslog.h>
+#include <termios.h>
+#include <time.h>
+#include <sys/time.h>
+#include <sys/poll.h>
+#include <sys/param.h>
+#include <sys/ioctl.h>
+#include <sys/socket.h>
+#include <sys/uio.h>
+
+#include <bluetooth/bluetooth.h>
+#include <bluetooth/hci.h>
+#include <bluetooth/hci_lib.h>
+
+#include "hciattach.h"
+
+#define FAILIF(x, args...) do { \
+ if (x) { \
+ fprintf(stderr, ##args); \
+ return -1; \
+ } \
+} while(0)
+
+typedef struct {
+ uint8_t uart_prefix;
+ hci_event_hdr hci_hdr;
+ evt_cmd_complete cmd_complete;
+ uint8_t status;
+ uint8_t data[16];
+} __attribute__((packed)) command_complete_t;
+
+
+static int read_command_complete(int fd, unsigned short opcode, unsigned char len) {
+ command_complete_t resp;
+ unsigned char vsevent[512];
+ int n;
+
+ /* Read reply. */
+ n = read_hci_event(fd, vsevent, sizeof(vsevent));
+ FAILIF(n < 0, "Failed to read response");
+
+ FAILIF(vsevent[1] != 0xFF, "Failed to read response");
+
+ n = read_hci_event(fd, (unsigned char *)&resp, sizeof(resp));
+ FAILIF(n < 0, "Failed to read response");
+
+ FAILIF(resp.hci_hdr.evt != EVT_CMD_COMPLETE, /* event must be event-complete */
+ "Error in response: not a cmd-complete event, "
+ "but 0x%02x!\n", resp.hci_hdr.evt);
+
+ FAILIF(resp.hci_hdr.plen < 4, /* plen >= 4 for EVT_CMD_COMPLETE */
+ "Error in response: plen is not >= 4, but 0x%02x!\n",
+ resp.hci_hdr.plen);
+
+ /* cmd-complete event: opcode */
+ FAILIF(resp.cmd_complete.opcode != 0,
+ "Error in response: opcode is 0x%04x, not 0!",
+ resp.cmd_complete.opcode);
+
+ return resp.status == 0 ? 0 : -1;
+}
+
+static int qualcomm_load_firmware(int fd, const char *firmware, const char *bdaddr_s) {
+
+ int fw = open(firmware, O_RDONLY);
+
+ fprintf(stdout, "Opening firmware file: %s\n", firmware);
+
+ FAILIF(fw < 0,
+ "Could not open firmware file %s: %s (%d).\n",
+ firmware, strerror(errno), errno);
+
+ fprintf(stdout, "Uploading firmware...\n");
+ do {
+ /* Read each command and wait for a response. */
+ unsigned char data[1024];
+ unsigned char cmdp[1 + sizeof(hci_command_hdr)];
+ hci_command_hdr *cmd = (hci_command_hdr *)(cmdp + 1);
+ int nr;
+ nr = read(fw, cmdp, sizeof(cmdp));
+ if (!nr)
+ break;
+ FAILIF(nr != sizeof(cmdp), "Could not read H4 + HCI header!\n");
+ FAILIF(*cmdp != HCI_COMMAND_PKT, "Command is not an H4 command packet!\n");
+
+ FAILIF(read(fw, data, cmd->plen) != cmd->plen,
+ "Could not read %d bytes of data for command with opcode %04x!\n",
+ cmd->plen,
+ cmd->opcode);
+
+ if ((data[0] == 1) && (data[1] == 2) && (data[2] == 6)) {
+ bdaddr_t bdaddr;
+ if (bdaddr_s != NULL) {
+ (void) str2ba(bdaddr_s, &bdaddr);
+ memcpy(&data[3], &bdaddr, sizeof(bdaddr_t));
+ }
+ }
+
+ {
+ int nw;
+ struct iovec iov_cmd[2];
+ iov_cmd[0].iov_base = cmdp;
+ iov_cmd[0].iov_len = sizeof(cmdp);
+ iov_cmd[1].iov_base = data;
+ iov_cmd[1].iov_len = cmd->plen;
+ nw = writev(fd, iov_cmd, 2);
+ FAILIF(nw != (int) sizeof(cmdp) + cmd->plen,
+ "Could not send entire command (sent only %d bytes)!\n",
+ nw);
+ }
+
+ /* Wait for response */
+ if (read_command_complete(fd,
+ cmd->opcode,
+ cmd->plen) < 0) {
+ return -1;
+ }
+
+ } while(1);
+ fprintf(stdout, "Firmware upload successful.\n");
+
+ close(fw);
+ return 0;
+}
+
+int qualcomm_init(int fd, int speed, struct termios *ti, const char *bdaddr)
+{
+ struct timespec tm = {0, 50000};
+ char cmd[5];
+ unsigned char resp[100]; /* Response */
+ char fw[100];
+ int n;
+
+ memset(resp,'\0', 100);
+
+ /* Get Manufacturer and LMP version */
+ cmd[0] = HCI_COMMAND_PKT;
+ cmd[1] = 0x01;
+ cmd[2] = 0x10;
+ cmd[3] = 0x00;
+
+ do {
+ n = write(fd, cmd, 4);
+ if (n < 0) {
+ perror("Failed to write init command (READ_LOCAL_VERSION_INFORMATION)");
+ return -1;
+ }
+ if (n < 4) {
+ fprintf(stderr, "Wanted to write 4 bytes, could only write %d. Stop\n", n);
+ return -1;
+ }
+
+ /* Read reply. */
+ if (read_hci_event(fd, resp, 100) < 0) {
+ perror("Failed to read init response (READ_LOCAL_VERSION_INFORMATION)");
+ return -1;
+ }
+
+ /* Wait for command complete event for our Opcode */
+ } while (resp[4] != cmd[1] && resp[5] != cmd[2]);
+
+ /* Verify manufacturer */
+ if ((resp[11] & 0xFF) != 0x1d)
+ fprintf(stderr,"WARNING : module's manufacturer is not Qualcomm\n");
+
+ /* Print LMP version */
+ fprintf(stderr, "Qualcomm module LMP version : 0x%02x\n", resp[10] & 0xFF);
+
+ /* Print LMP subversion */
+ {
+ unsigned short lmp_subv = resp[13] | (resp[14] << 8);
+
+ fprintf(stderr, "Qualcomm module LMP sub-version : 0x%04x\n", lmp_subv);
+
+ }
+
+ /* Get SoC type */
+ cmd[0] = HCI_COMMAND_PKT;
+ cmd[1] = 0x00;
+ cmd[2] = 0xFC;
+ cmd[3] = 0x01;
+ cmd[4] = 0x06;
+
+ do {
+ n = write(fd, cmd, 5);
+ if (n < 0) {
+ perror("Failed to write init command");
+ return -1;
+ }
+ if (n < 5) {
+ fprintf(stderr, "Wanted to write 5 bytes, could only write %d. Stop\n", n);
+ return -1;
+ }
+
+ /* Read reply. */
+ if ((n = read_hci_event(fd, resp, 100)) < 0) {
+ perror("Failed to read init response");
+ return -1;
+ }
+
+ } while (resp[3] != 0 && resp[4] != 2);
+
+ snprintf(fw, sizeof(fw),
+ "/etc/firmware/%c%c%c%c%c%c_%c%c%c%c.bin",
+ resp[18], resp[19], resp[20], resp[21],
+ resp[22], resp[23],
+ resp[32], resp[33], resp[34], resp[35]);
+
+ /* Wait for command complete event for our Opcode */
+ if (read_hci_event(fd, resp, 100) < 0) {
+ perror("Failed to read init response");
+ return -1;
+ }
+
+ qualcomm_load_firmware(fd, fw, bdaddr);
+
+ /* Reset */
+ cmd[0] = HCI_COMMAND_PKT;
+ cmd[1] = 0x03;
+ cmd[2] = 0x0C;
+ cmd[3] = 0x00;
+
+ do {
+ n = write(fd, cmd, 4);
+ if (n < 0) {
+ perror("Failed to write reset command");
+ return -1;
+ }
+ if (n < 4) {
+ fprintf(stderr, "Wanted to write 4 bytes, could only write %d. Stop\n", n);
+ return -1;
+ }
+
+ /* Read reply. */
+ if ((n = read_hci_event(fd, resp, 100)) < 0) {
+ perror("Failed to read reset response");
+ return -1;
+ }
+
+ } while (resp[4] != cmd[1] && resp[5] != cmd[2]);
+
+ nanosleep(&tm, NULL);
+ return 0;
+}
--
1.7.1.1
--
Matthew Wilson
Employee of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum
^ permalink raw reply related
* Re: PAN performance
From: Han @ 2010-08-20 16:52 UTC (permalink / raw)
To: steven bluez; +Cc: linux-bluetooth
In-Reply-To: <AANLkTikch9E6mw-YErX7-85yivWVAh2E2iRS3eBc1hp5@mail.gmail.com>
On Thu, Aug 19, 2010 at 11:59 PM, steven bluez <steven.bluez@gmail.com> wrote:
>
> Hi Han,
> On Fri, Aug 20, 2010 at 9:27 AM, Han <keepsimple@gmail.com> wrote:
>>
>> Hi,
>> I have been using bluetooth PAN to run some personal programs. One
>> thing I noticed is that PAN seems to be very slow (i.e. not up to
>> 3Mbps for BT 2.0). I have bluetooth 2.0 adapters on my laptops and I
>> do SSH over PAN. Whenever I run a GUI application (on sshd server), i
>> see the GUI response is very slow. It is not video or anything so I
>> don't think it needs up to 3Mbps. Is this slowness over PAN expected?
>>
>> Thanks.
>> Han
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-bluetooth"
>> in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
> I think is depending upon the vendor you have. I had a chip which had no
> issues like yours and the 3mbps doesnt come into the scenario you expect
> instead you get 1-2mbps in bluetooth. If it's bidi direction it might
> vary...My experience of pan would be around 1.5mpbs MAX
I noticed the difference between chips as well. But i saw the issue
even with one of mine better BT doggles ;-). Btw, I tried to use
"ssh -C -X" options and now the latency is much better.
>
> Regards,
> Steven
>
^ permalink raw reply
* Re: PAN performance
From: Han @ 2010-08-20 16:50 UTC (permalink / raw)
To: Arun Kumar, linux-bluetooth
In-Reply-To: <AANLkTik5Q0CpUu=wpz_X8An1h6ShTku19xUff3O39Bkx@mail.gmail.com>
Hi Arun,
I was able to transfer pictures and file over BT in fair good speed. I
yet to test the actual bps though. I will check out the
configurations...
thanks
Han
On Thu, Aug 19, 2010 at 10:55 PM, Arun Kumar <arunkat@gmail.com> wrote:
> Hello Han,
>
> just curious--are you able to get good performance[upto 3 Mbps] with non-pan
> bluez profiles? as BT speeds depend on HCI transports too used below viz.
> UARTS. They may not be configured optimally for BR/EDR high speeds...
>
> --
> Best Regards,
> Arun Kumar Singh
>
>
>> On Fri, Aug 20, 2010 at 9:27 AM, Han <keepsimple@gmail.com> wrote:
>>>
>>> Hi,
>>> I have been using bluetooth PAN to run some personal programs. One
>>> thing I noticed is that PAN seems to be very slow (i.e. not up to
>>> 3Mbps for BT 2.0). I have bluetooth 2.0 adapters on my laptops and I
>>> do SSH over PAN. Whenever I run a GUI application (on sshd server), i
>>> see the GUI response is very slow. It is not video or anything so I
>>> don't think it needs up to 3Mbps. Is this slowness over PAN expected?
>>>
>>> Thanks.
>>> Han
>>> --
>>> To unsubscribe from this list: send the line "unsubscribe
>>> linux-bluetooth" in
>>> the body of a message to majordomo@vger.kernel.org
>>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>>
>>
>>
>>
>>
>
>
>
^ permalink raw reply
* [PATCH] Makefile.am fixes
From: Marcel Mol @ 2010-08-20 16:32 UTC (permalink / raw)
To: linux-bluetooth
phonebook.h should not be under _nodist.
vcard.[ch] is not related to pbap, but to phonebook backend
---
Makefile.am | 6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/Makefile.am b/Makefile.am
index 07fc27d..fdc4f7e 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -52,8 +52,7 @@ builtin_modules += ftp
builtin_sources += plugins/ftp.c
builtin_modules += pbap
-builtin_sources += plugins/pbap.c plugins/phonebook.h \
- plugins/vcard.h plugins/vcard.c
+builtin_sources += plugins/pbap.c
builtin_modules += irmc
builtin_sources += plugins/irmc.c
@@ -61,6 +60,8 @@ builtin_sources += plugins/irmc.c
builtin_modules += syncevolution
builtin_sources += plugins/syncevolution.c
+builtin_sources += plugins/phonebook.h plugins/vcard.h plugins/vcard.c
+
builtin_nodist += plugins/phonebook.c
libexec_PROGRAMS += src/obexd
@@ -99,7 +100,6 @@ src/plugin.$(OBJEXT): src/builtin.h
src/builtin.h: src/genbuiltin $(builtin_sources)
$(AM_V_GEN)$(srcdir)/src/genbuiltin $(builtin_modules) > $@
-
endif
if CLIENT
--
1.7.2.1
^ permalink raw reply related
* [PATCH 2nd version] Makefile.am fixes
From: Marcel Mol @ 2010-08-20 16:32 UTC (permalink / raw)
To: linux-bluetooth
vcard.[ch] is not related to pbap, but to phonebook backend
---
Makefile.am | 6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/Makefile.am b/Makefile.am
index 07fc27d..fdc4f7e 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -52,8 +52,7 @@ builtin_modules += ftp
builtin_sources += plugins/ftp.c
builtin_modules += pbap
-builtin_sources += plugins/pbap.c plugins/phonebook.h \
- plugins/vcard.h plugins/vcard.c
+builtin_sources += plugins/pbap.c
builtin_modules += irmc
builtin_sources += plugins/irmc.c
@@ -61,6 +60,8 @@ builtin_sources += plugins/irmc.c
builtin_modules += syncevolution
builtin_sources += plugins/syncevolution.c
+builtin_sources += plugins/phonebook.h plugins/vcard.h plugins/vcard.c
+
builtin_nodist += plugins/phonebook.c
libexec_PROGRAMS += src/obexd
@@ -99,7 +100,6 @@ src/plugin.$(OBJEXT): src/builtin.h
src/builtin.h: src/genbuiltin $(builtin_sources)
$(AM_V_GEN)$(srcdir)/src/genbuiltin $(builtin_modules) > $@
-
endif
if CLIENT
--
1.7.2.1
^ permalink raw reply related
* Re: [PATCH] Remove dup VCard2.1 SDP format for OPP
From: Johan Hedberg @ 2010-08-20 15:58 UTC (permalink / raw)
To: Tom Counihan; +Cc: linux-bluetooth
In-Reply-To: <AANLkTim9y59pMzPGSkZi431oTAjEjdiEtQHnt_-D2z85@mail.gmail.com>
Hi Tom,
On Fri, Aug 20, 2010, Tom Counihan wrote:
> Attaching patch as an attachment - hopefully all should be fine now.
Yes, it was fine. The patch is now upstream. Thanks.
Johan
^ permalink raw reply
* Re: [PATCH] Remove dup VCard2.1 SDP format for OPP
From: Tom Counihan @ 2010-08-20 13:39 UTC (permalink / raw)
To: Tom Counihan, linux-bluetooth
In-Reply-To: <AANLkTi=YeYGdojmXt-0gRdXPafsupP6CZc4r7dj2ufAg@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 973 bytes --]
Hi Johan,
Attaching patch as an attachment - hopefully all should be fine now.
Warm Regards
Tom.
On Fri, Aug 20, 2010 at 2:32 PM, Tom Counihan
<tomcounihan@googlemail.com> wrote:
> On Fri, Aug 20, 2010 at 1:59 PM, Johan Hedberg <johan.hedberg@gmail.com> wrote:
>> Hi Tom,
>>
>> On Fri, Aug 20, 2010, Tom Counihan wrote:
>>> OPP SDP record appears to have a duplicate
>>> entry for Supported Formats List.
>>>
>>> ---
>>> plugins/opp.c | 1 -
>>> 1 files changed, 0 insertions(+), 1 deletions(-)
>>
>> The patch looks fine but doesn't apply against latest git:
>>
>> error: patch failed: plugins/opp.c:83
>> error: plugins/opp.c: patch does not apply
>> Patch failed at 0001 Remove dup VCard2.1 SDP format for OPP
>>
>> Could you make sure that it applies cleanly to latest git and then
>> resend? Thanks.
>
> I'll send again - I'm assuming that the cause here is we had a race
> condition between inbound patches?
>>
>> Johan
>>
>
[-- Attachment #2: 0001-Remove-dup-VCard2.1-SDP-format-for-OPP.patch --]
[-- Type: application/octet-stream, Size: 758 bytes --]
From ab7d7fbf60a016b491200f4c5eaf100188dd5d7b Mon Sep 17 00:00:00 2001
From: Tom Counihan <tomcounihan@googlemail.com>
Date: Fri, 20 Aug 2010 14:20:53 +0100
Subject: [PATCH] Remove dup VCard2.1 SDP format for OPP
OPP SDP record appears to have a duplicate
entry for Supported Formats List.
---
plugins/opp.c | 1 -
1 files changed, 0 insertions(+), 1 deletions(-)
diff --git a/plugins/opp.c b/plugins/opp.c
index cd46464..05f944f 100644
--- a/plugins/opp.c
+++ b/plugins/opp.c
@@ -83,7 +83,6 @@
<attribute id=\"0x0303\"> \
<sequence> \
<uint8 value=\"0x01\"/> \
- <uint8 value=\"0x01\"/> \
<uint8 value=\"0x02\"/> \
<uint8 value=\"0x03\"/> \
<uint8 value=\"0x04\"/> \
--
1.7.1.1
^ permalink raw reply related
* Re: [PATCH] Remove dup VCard2.1 SDP format for OPP
From: Tom Counihan @ 2010-08-20 13:32 UTC (permalink / raw)
To: Tom Counihan, linux-bluetooth
In-Reply-To: <20100820125948.GA16376@jh-x301>
On Fri, Aug 20, 2010 at 1:59 PM, Johan Hedberg <johan.hedberg@gmail.com> wrote:
> Hi Tom,
>
> On Fri, Aug 20, 2010, Tom Counihan wrote:
>> OPP SDP record appears to have a duplicate
>> entry for Supported Formats List.
>>
>> ---
>> plugins/opp.c | 1 -
>> 1 files changed, 0 insertions(+), 1 deletions(-)
>
> The patch looks fine but doesn't apply against latest git:
>
> error: patch failed: plugins/opp.c:83
> error: plugins/opp.c: patch does not apply
> Patch failed at 0001 Remove dup VCard2.1 SDP format for OPP
>
> Could you make sure that it applies cleanly to latest git and then
> resend? Thanks.
I'll send again - I'm assuming that the cause here is we had a race
condition between inbound patches?
>
> Johan
>
^ permalink raw reply
* Re: [PATCH] Remove dup VCard2.1 SDP format for OPP
From: Johan Hedberg @ 2010-08-20 12:59 UTC (permalink / raw)
To: Tom Counihan; +Cc: linux-bluetooth
In-Reply-To: <AANLkTin+CRVwKgC+UaDK6q4PRrw9eGi3c7++PSxWODcu@mail.gmail.com>
Hi Tom,
On Fri, Aug 20, 2010, Tom Counihan wrote:
> OPP SDP record appears to have a duplicate
> entry for Supported Formats List.
>
> ---
> plugins/opp.c | 1 -
> 1 files changed, 0 insertions(+), 1 deletions(-)
The patch looks fine but doesn't apply against latest git:
error: patch failed: plugins/opp.c:83
error: plugins/opp.c: patch does not apply
Patch failed at 0001 Remove dup VCard2.1 SDP format for OPP
Could you make sure that it applies cleanly to latest git and then
resend? Thanks.
Johan
^ permalink raw reply
* [PATCH] Remove dup VCard2.1 SDP format for OPP
From: Tom Counihan @ 2010-08-20 12:34 UTC (permalink / raw)
To: linux-bluetooth
OPP SDP record appears to have a duplicate
entry for Supported Formats List.
---
plugins/opp.c | 1 -
1 files changed, 0 insertions(+), 1 deletions(-)
diff --git a/plugins/opp.c b/plugins/opp.c
index cd46464..05f944f 100644
--- a/plugins/opp.c
+++ b/plugins/opp.c
@@ -83,7 +83,6 @@
<attribute id=\"0x0303\"> \
<sequence> \
<uint8 value=\"0x01\"/> \
- <uint8 value=\"0x01\"/> \
<uint8 value=\"0x02\"/> \
<uint8 value=\"0x03\"/> \
<uint8 value=\"0x04\"/> \
--
1.7.1.1
^ permalink raw reply related
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