* [PATCH v2 2/2] Split pull_contacts to smaller functions
From: Bartosz Szatkowski @ 2010-11-16 13:59 UTC (permalink / raw)
To: linux-bluetooth; +Cc: Bartosz Szatkowski
Parts of pull_contact responsible for filling contact fields moved
to new functions.
---
plugins/phonebook-tracker.c | 159 ++++++++++++++++++++++++------------------
1 files changed, 91 insertions(+), 68 deletions(-)
diff --git a/plugins/phonebook-tracker.c b/plugins/phonebook-tracker.c
index 71ed2f0..e7de001 100644
--- a/plugins/phonebook-tracker.c
+++ b/plugins/phonebook-tracker.c
@@ -1395,6 +1395,92 @@ static void add_affiliation(char **field, const char *value)
*field = g_strdup(value);
}
+static void contact_init(struct phonebook_contact **contact, char **reply)
+{
+ if (*contact == NULL)
+ *contact = g_new0(struct phonebook_contact, 1);
+
+ (*contact)->fullname = g_strdup(reply[COL_FULL_NAME]);
+ (*contact)->family = g_strdup(reply[COL_FAMILY_NAME]);
+ (*contact)->given = g_strdup(reply[COL_GIVEN_NAME]);
+ (*contact)->additional = g_strdup(reply[COL_ADDITIONAL_NAME]);
+ (*contact)->prefix = g_strdup(reply[COL_NAME_PREFIX]);
+ (*contact)->suffix = g_strdup(reply[COL_NAME_SUFFIX]);
+ (*contact)->birthday = g_strdup(reply[COL_BIRTH_DATE]);
+ (*contact)->nickname = g_strdup(reply[COL_NICKNAME]);
+ (*contact)->website = g_strdup(reply[COL_URL]);
+ (*contact)->photo = g_strdup(reply[COL_PHOTO]);
+ (*contact)->company = g_strdup(reply[COL_ORG_NAME]);
+ (*contact)->department = g_strdup(reply[COL_ORG_DEPARTMENT]);
+ (*contact)->role = g_strdup(reply[COL_ORG_ROLE]);
+ (*contact)->uid = g_strdup(reply[COL_UID]);
+ (*contact)->title = g_strdup(reply[COL_TITLE]);
+
+ set_call_type(*contact, reply[COL_DATE], reply[COL_SENT],
+ reply[COL_ANSWERED]);
+}
+
+static void contact_add_numbers(struct phonebook_contact **contact, char **reply)
+{
+ add_phone_number(*contact, reply[COL_HOME_NUMBER], TEL_TYPE_HOME);
+ add_phone_number(*contact, reply[COL_WORK_NUMBER], TEL_TYPE_WORK);
+ add_phone_number(*contact, reply[COL_FAX_NUMBER], TEL_TYPE_FAX);
+ add_phone_number(*contact, reply[COL_CELL_NUMBER], TEL_TYPE_MOBILE);
+ if ((g_strcmp0(reply[COL_OTHER_NUMBER], reply[COL_CELL_NUMBER]) != 0) &&
+ (g_strcmp0(reply[COL_OTHER_NUMBER], reply[COL_WORK_NUMBER]) != 0) &&
+ (g_strcmp0(reply[COL_OTHER_NUMBER], reply[COL_HOME_NUMBER]) != 0))
+ add_phone_number(*contact, reply[COL_OTHER_NUMBER], TEL_TYPE_OTHER);
+}
+
+static void contact_add_emails(struct phonebook_contact **contact, char **reply)
+{
+ add_email(*contact, reply[COL_HOME_EMAIL], EMAIL_TYPE_HOME);
+ add_email(*contact, reply[COL_WORK_EMAIL], EMAIL_TYPE_WORK);
+ add_email(*contact, reply[COL_OTHER_EMAIL], EMAIL_TYPE_OTHER);
+}
+
+static void contact_add_addresses(struct phonebook_contact **contact, char **reply)
+{
+
+ char *home_addr, *work_addr, *other_addr;
+
+ home_addr = g_strdup_printf("%s;%s;%s;%s;%s;%s;%s",
+ reply[COL_HOME_ADDR_POBOX], reply[COL_HOME_ADDR_EXT],
+ reply[COL_HOME_ADDR_STREET], reply[COL_HOME_ADDR_LOCALITY],
+ reply[COL_HOME_ADDR_REGION], reply[COL_HOME_ADDR_CODE],
+ reply[COL_HOME_ADDR_COUNTRY]);
+
+ work_addr = g_strdup_printf("%s;%s;%s;%s;%s;%s;%s",
+ reply[COL_WORK_ADDR_POBOX], reply[COL_WORK_ADDR_EXT],
+ reply[COL_WORK_ADDR_STREET], reply[COL_WORK_ADDR_LOCALITY],
+ reply[COL_WORK_ADDR_REGION], reply[COL_WORK_ADDR_CODE],
+ reply[COL_WORK_ADDR_COUNTRY]);
+
+ other_addr = g_strdup_printf("%s;%s;%s;%s;%s;%s;%s",
+ reply[COL_OTHER_ADDR_POBOX], reply[COL_OTHER_ADDR_EXT],
+ reply[COL_OTHER_ADDR_STREET], reply[COL_OTHER_ADDR_LOCALITY],
+ reply[COL_OTHER_ADDR_REGION], reply[COL_OTHER_ADDR_CODE],
+ reply[COL_OTHER_ADDR_COUNTRY]);
+
+ add_address(*contact, home_addr, ADDR_TYPE_HOME);
+ add_address(*contact, work_addr, ADDR_TYPE_WORK);
+ add_address(*contact, other_addr, ADDR_TYPE_OTHER);
+
+ g_free(home_addr);
+ g_free(work_addr);
+ g_free(other_addr);
+}
+
+static void contact_add_organization(struct phonebook_contact **contact, char **reply)
+{
+ /* Adding fields connected by nco:hasAffiliation - they may be in
+ * separate replies */
+ add_affiliation(&(*contact)->title, reply[COL_TITLE]);
+ add_affiliation(&(*contact)->company, reply[COL_ORG_NAME]);
+ add_affiliation(&(*contact)->department, reply[COL_ORG_DEPARTMENT]);
+ add_affiliation(&(*contact)->role, reply[COL_ORG_ROLE]);
+}
+
static void pull_contacts(char **reply, int num_fields, void *user_data)
{
struct phonebook_data *data = user_data;
@@ -1404,7 +1490,6 @@ static void pull_contacts(char **reply, int num_fields, void *user_data)
GString *vcards;
int last_index, i;
gboolean cdata_present = FALSE;
- char *home_addr, *work_addr, *other_addr;
static char *temp_id = NULL;
if (num_fields < 0) {
@@ -1455,75 +1540,13 @@ static void pull_contacts(char **reply, int num_fields, void *user_data)
return;
add_entry:
- contact = g_new0(struct phonebook_contact, 1);
- contact->fullname = g_strdup(reply[COL_FULL_NAME]);
- contact->family = g_strdup(reply[COL_FAMILY_NAME]);
- contact->given = g_strdup(reply[COL_GIVEN_NAME]);
- contact->additional = g_strdup(reply[COL_ADDITIONAL_NAME]);
- contact->prefix = g_strdup(reply[COL_NAME_PREFIX]);
- contact->suffix = g_strdup(reply[COL_NAME_SUFFIX]);
- contact->birthday = g_strdup(reply[COL_BIRTH_DATE]);
- contact->nickname = g_strdup(reply[COL_NICKNAME]);
- contact->website = g_strdup(reply[COL_URL]);
- contact->photo = g_strdup(reply[COL_PHOTO]);
- contact->company = g_strdup(reply[COL_ORG_NAME]);
- contact->department = g_strdup(reply[COL_ORG_DEPARTMENT]);
- contact->role = g_strdup(reply[COL_ORG_ROLE]);
- contact->uid = g_strdup(reply[COL_UID]);
- contact->title = g_strdup(reply[COL_TITLE]);
-
- set_call_type(contact, reply[COL_DATE], reply[COL_SENT],
- reply[COL_ANSWERED]);
+ contact_init(&contact, reply);
add_numbers:
- /* Adding phone numbers to contact struct */
- add_phone_number(contact, reply[COL_HOME_NUMBER], TEL_TYPE_HOME);
- add_phone_number(contact, reply[COL_WORK_NUMBER], TEL_TYPE_WORK);
- add_phone_number(contact, reply[COL_FAX_NUMBER], TEL_TYPE_FAX);
- add_phone_number(contact, reply[COL_CELL_NUMBER], TEL_TYPE_MOBILE);
- if ((g_strcmp0(reply[COL_OTHER_NUMBER], reply[COL_CELL_NUMBER]) != 0) &&
- (g_strcmp0(reply[COL_OTHER_NUMBER], reply[COL_WORK_NUMBER]) != 0) &&
- (g_strcmp0(reply[COL_OTHER_NUMBER], reply[COL_HOME_NUMBER]) != 0))
- add_phone_number(contact, reply[COL_OTHER_NUMBER], TEL_TYPE_OTHER);
-
- /* Adding emails */
- add_email(contact, reply[COL_HOME_EMAIL], EMAIL_TYPE_HOME);
- add_email(contact, reply[COL_WORK_EMAIL], EMAIL_TYPE_WORK);
- add_email(contact, reply[COL_OTHER_EMAIL], EMAIL_TYPE_OTHER);
-
- /* Adding addresses */
- home_addr = g_strdup_printf("%s;%s;%s;%s;%s;%s;%s",
- reply[COL_HOME_ADDR_POBOX], reply[COL_HOME_ADDR_EXT],
- reply[COL_HOME_ADDR_STREET], reply[COL_HOME_ADDR_LOCALITY],
- reply[COL_HOME_ADDR_REGION], reply[COL_HOME_ADDR_CODE],
- reply[COL_HOME_ADDR_COUNTRY]);
-
- work_addr = g_strdup_printf("%s;%s;%s;%s;%s;%s;%s",
- reply[COL_WORK_ADDR_POBOX], reply[COL_WORK_ADDR_EXT],
- reply[COL_WORK_ADDR_STREET], reply[COL_WORK_ADDR_LOCALITY],
- reply[COL_WORK_ADDR_REGION], reply[COL_WORK_ADDR_CODE],
- reply[COL_WORK_ADDR_COUNTRY]);
-
- other_addr = g_strdup_printf("%s;%s;%s;%s;%s;%s;%s",
- reply[COL_OTHER_ADDR_POBOX], reply[COL_OTHER_ADDR_EXT],
- reply[COL_OTHER_ADDR_STREET], reply[COL_OTHER_ADDR_LOCALITY],
- reply[COL_OTHER_ADDR_REGION], reply[COL_OTHER_ADDR_CODE],
- reply[COL_OTHER_ADDR_COUNTRY]);
-
- add_address(contact, home_addr, ADDR_TYPE_HOME);
- add_address(contact, work_addr, ADDR_TYPE_WORK);
- add_address(contact, other_addr, ADDR_TYPE_OTHER);
-
- g_free(home_addr);
- g_free(work_addr);
- g_free(other_addr);
-
- /* Adding fields connected by nco:hasAffiliation - they may be in
- * separate replies */
- add_affiliation(&contact->title, reply[COL_TITLE]);
- add_affiliation(&contact->company, reply[COL_ORG_NAME]);
- add_affiliation(&contact->department, reply[COL_ORG_DEPARTMENT]);
- add_affiliation(&contact->role, reply[COL_ORG_ROLE]);
+ contact_add_numbers(&contact, reply);
+ contact_add_emails(&contact, reply);
+ contact_add_addresses(&contact, reply);
+ contact_add_organization(&contact, reply);
DBG("contact %p", contact);
--
1.7.0.4
^ permalink raw reply related
* Re: [PATCH] Fix typos in adapter documentation
From: Johan Hedberg @ 2010-11-16 13:41 UTC (permalink / raw)
To: Jose Antonio Santos Cadenas; +Cc: linux-bluetooth
In-Reply-To: <1289846883-8748-1-git-send-email-santoscadenas@gmail.com>
Hi Jose,
On Mon, Nov 15, 2010, Jose Antonio Santos Cadenas wrote:
> ---
> doc/adapter-api.txt | 8 ++++----
> 1 files changed, 4 insertions(+), 4 deletions(-)
Thanks. The patch has been pushed upstream.
Johan
^ permalink raw reply
* Re: Regarding HDP
From: Raul Herbster @ 2010-11-16 13:39 UTC (permalink / raw)
To: steven bluez; +Cc: linux-bluetooth
In-Reply-To: <AANLkTi=ZZcbEP+NX9PxT_K_9XnCQfKbSugCYJa_na=SY@mail.gmail.com>
Hi Steve,
HDP profile is available in PTS for testing. At project wizard, you
have to select the HDP profile option, so HDP test suite is enabled.
In addition, don´t forget to enable option TSPC_ALL at PTS PICS
configuration.
[]´s
--Raul
2010/11/16 steven bluez <steven.bluez@gmail.com>:
> Hi All,
> How to test the following HDP profile with Pts?.Is it
> available in PTs as option or any other way is available??
>
> Thanks,
> Steven.
> --
> To unsubscribe from this list: send the line "unsubscribe linux-bluetooth" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply
* Re: [PATCH 2/2] Split pull_contacts to smaller functions
From: Johan Hedberg @ 2010-11-16 13:37 UTC (permalink / raw)
To: Bartosz Szatkowski; +Cc: linux-bluetooth
In-Reply-To: <1289822497-5338-2-git-send-email-bulislaw@linux.com>
Hi Bartosz,
On Mon, Nov 15, 2010, Bartosz Szatkowski wrote:
> Parts of pull_contact responsible for filling contact fields moved
> to new functions.
> ---
> plugins/phonebook-tracker.c | 159 ++++++++++++++++++++++++------------------
> 1 files changed, 91 insertions(+), 68 deletions(-)
This one doesn't apply cleanly to current git. Could you please resend it?
Johan
^ permalink raw reply
* Re: [PATCH 1/2] Using field names instead of numbers in PBAP
From: Johan Hedberg @ 2010-11-16 13:35 UTC (permalink / raw)
To: Bartosz Szatkowski; +Cc: linux-bluetooth
In-Reply-To: <1289822497-5338-1-git-send-email-bulislaw@linux.com>
Hi Bartosz,
On Mon, Nov 15, 2010, Bartosz Szatkowski wrote:
> Previously addressing via field numbers and field names were mixed in PBAP
> query replies. Now there is defined name for each data base reply field.
> ---
> plugins/phonebook-tracker.c | 104 +++++++++++++++++++++++++++++++-----------
> 1 files changed, 77 insertions(+), 27 deletions(-)
Pushed upstream. Thanks.
Johan
^ permalink raw reply
* Re: [PATCH] Adding a new option to specify medium security level for gatttool
From: Sheldon Demario @ 2010-11-16 13:35 UTC (permalink / raw)
To: linux-bluetooth; +Cc: Johan Hedberg
In-Reply-To: <20101111205448.GA22890@jh-x301>
Hey Johan,
--sec-level seems more clear than --security to me, because it makes
explicit that the option is about "level". But is easy to change if you
want to.
Sheldon
On 11/11/2010 03:54 PM, Johan Hedberg wrote:
> Hi Sheldon,
>
> On Wed, Nov 10, 2010, Sheldon Demario wrote:
>> -- Add command line support to use medium instead of (default) low
>> - security level with gatttool (--sec-level)
>> -
>> - Priority: Low
>> - Complexity: C1
>> -
> <snip>
>> + { "sec-medium", 's', 0, G_OPTION_ARG_NONE,&opt_medium_sec,
>> + "Use medium instead of default low security level",
>> + NULL},
> Maybe the TODO entry should have been more clear, but I'd prefer if the
> option would be of the format "--sec-level<level>" where<level> is
> "low", "medium" or "high". I'm not completely sure I like --sec-level
> either (even though I did write the original TODO entry :) What do you
> think about simply "--security<level>"?
>
> Johan
^ permalink raw reply
* Re: [PATCH v2] Fix pull phonebook with non-zero offset parameter
From: Johan Hedberg @ 2010-11-16 13:34 UTC (permalink / raw)
To: Rafal Michalski; +Cc: linux-bluetooth
In-Reply-To: <1289817700-32136-1-git-send-email-michalski.raf@gmail.com>
Hi Rafal,
On Mon, Nov 15, 2010, Rafal Michalski wrote:
> For non-zero liststartoffset parameter, contacts which index was before
> offset were indexed more than once (e.g. when contact had more than one
> phone number or address etc.), so pulling was started earlier - before
> offset index was reached. This patch fix this problem and each contact
> is indexed only once.
> ---
> plugins/phonebook-tracker.c | 9 ++++++++-
> 1 files changed, 8 insertions(+), 1 deletions(-)
Pushed upstream. Thanks.
Johan
^ permalink raw reply
* [PATCH] Adding a new option to specify security level for gatttool
From: Sheldon Demario @ 2010-11-16 13:20 UTC (permalink / raw)
To: linux-bluetooth; +Cc: Sheldon Demario
---
TODO | 6 ------
attrib/gatttool.c | 15 +++++++++++++--
2 files changed, 13 insertions(+), 8 deletions(-)
diff --git a/TODO b/TODO
index c0a25f1..49a9e76 100644
--- a/TODO
+++ b/TODO
@@ -123,12 +123,6 @@ ATT/GATT
Priority: Low
Complexity: C1
-- Add command line support to use medium instead of (default) low
- security level with gatttool (--sec-level)
-
- Priority: Low
- Complexity: C1
-
- Implement Server characteristic Configuration support in the attribute
server to manage characteristic value broadcasting. There is a single
instance of the Server Characteristic Configuration for all clients.
diff --git a/attrib/gatttool.c b/attrib/gatttool.c
index b9f5138..bb4fb80 100644
--- a/attrib/gatttool.c
+++ b/attrib/gatttool.c
@@ -49,6 +49,7 @@
static gchar *opt_src = NULL;
static gchar *opt_dst = NULL;
static gchar *opt_value = NULL;
+static gchar *opt_sec_level = "low";
static int opt_start = 0x0001;
static int opt_end = 0xffff;
static int opt_handle = -1;
@@ -84,6 +85,7 @@ static GIOChannel *do_connect(gboolean le)
GIOChannel *chan;
bdaddr_t sba, dba;
GError *err = NULL;
+ BtIOSecLevel sec_level;
/* This check is required because currently setsockopt() returns no
* errors for MTU values smaller than the allowed minimum. */
@@ -109,13 +111,20 @@ static GIOChannel *do_connect(gboolean le)
} else
bacpy(&sba, BDADDR_ANY);
+ if (strncmp(opt_sec_level, "medium", 6) == 0)
+ sec_level = BT_IO_SEC_MEDIUM;
+ else if (strncmp(opt_sec_level, "high", 4) == 0)
+ sec_level = BT_IO_SEC_HIGH;
+ else
+ sec_level = BT_IO_SEC_LOW;
+
if (le)
chan = bt_io_connect(BT_IO_L2CAP, connect_cb, NULL, NULL, &err,
BT_IO_OPT_SOURCE_BDADDR, &sba,
BT_IO_OPT_DEST_BDADDR, &dba,
BT_IO_OPT_CID, GATT_CID,
BT_IO_OPT_OMTU, opt_mtu,
- BT_IO_OPT_SEC_LEVEL, BT_IO_SEC_LOW,
+ BT_IO_OPT_SEC_LEVEL, sec_level,
BT_IO_OPT_INVALID);
else
chan = bt_io_connect(BT_IO_L2CAP, connect_cb, NULL, NULL, &err,
@@ -123,7 +132,7 @@ static GIOChannel *do_connect(gboolean le)
BT_IO_OPT_DEST_BDADDR, &dba,
BT_IO_OPT_PSM, opt_psm,
BT_IO_OPT_OMTU, opt_mtu,
- BT_IO_OPT_SEC_LEVEL, BT_IO_SEC_LOW,
+ BT_IO_OPT_SEC_LEVEL, sec_level,
BT_IO_OPT_INVALID);
if (err) {
@@ -519,6 +528,8 @@ static GOptionEntry options[] = {
"Specify the MTU size", "MTU" },
{ "psm", 'p', 0, G_OPTION_ARG_INT, &opt_psm,
"Specify the PSM for GATT/ATT over BR/EDR", "PSM" },
+ { "sec-level", 'l', 0, G_OPTION_ARG_STRING, &opt_sec_level,
+ "Set security level. Default: low", "[low | medium | high]"},
{ NULL },
};
--
1.6.2.rc2
^ permalink raw reply related
* Regarding HDP
From: steven bluez @ 2010-11-16 11:08 UTC (permalink / raw)
To: linux-bluetooth
Hi All,
How to test the following HDP profile with Pts?.Is it
available in PTs as option or any other way is available??
Thanks,
Steven.
^ permalink raw reply
* Re: [PATCH 3/4] Add DBus OOB API documentation.
From: Szymon Janc @ 2010-11-16 10:12 UTC (permalink / raw)
To: jaikumar Ganesh; +Cc: linux-bluetooth@vger.kernel.org
In-Reply-To: <AANLkTik+LOzvJMG=of7cwrQ3j2a0mDvN4Rnq_d4rtwKB@mail.gmail.com>
> >> Why are we enforcing this limitation ?
> >
> > Spec requires that each hash&randomizer values should be used only for one OOB
> > transfer. Implementation enforces that by allowing only one active OOB plugin
> > at time and DBUS OOB plugin only 'expose' plugin API over DBUS. So this
> > limitation is a consequence of that.
>
> I don't think the spec says that. It just says every single time the
> call to read the local adapters hash
> and randomizer is done you get new values. You can use the value that
> you have obtained for as many OOB pairings
> as you wish.
Please see note in Vol2. Part E. 7.3.60:
"Each OOB transfer will have unique C and R values so after each OOB
transfer this command shall be used to obtain a new set of values for the next
OOB transfer."
--
Szymon Janc
^ permalink raw reply
* RE: [RFC] Interface to set LE connection parameters
From: tim.howes @ 2010-11-16 9:56 UTC (permalink / raw)
To: ville.tervo; +Cc: linux-bluetooth
In-Reply-To: <20101115151739.GD16464@null>
Ville,
> > As you note the different profiles would likely have different
> connection parameters. The different profiles may be running on the
> same LE link (indeed the same L2CAP [fixed] channel).
> >
>
> I guess the latency should override power requirements. Low power
> profile can
> operate on low latency link but low latency profile fails on high
> latency. Of
> course this gets much more complicated if there are more requirements.
Agreed.
>
> Are these (latency and power) the only characteristics we need to deal
> with.
> There might be some also. I'm not too familiar with profile drafts.
I think these are the main issues; however I wonder whether link supervision timeout may conflict for different use cases. Even if it is not the link supervision the lifetime of the physical link may differ between profiles (some may want the link up for a long time but send no data). Slightly off-topic; but still it raises issues around the type of API and the arbitration of different profile requirements on the same link.
> > Do you have a view on how the different profiles - on the same link -
> would have different requests arbitrated, and where that arbitration
> would be done? I'd imagine that the API towards the profiles should be
> of the abstract form - such as you mention (eg BT_LE_LOW_LAT). This
> would make it easier to arbitrate the different requests, as compared
> to if the profiles see an API of the "numerical" form (eg interval = N
> ms). I guess the arbitration could happen in user or kernel space; as
> long as there is something with singleton-like semantics to do it.
> >
>
> I think I need to get more details from profile specs and try to find
> out the
> requirements from them.
As an aside, it's not just the application profiles. If you have a link to a device with high latency and need to do more service search using GATT then you might want to lower the latency temporarily. This may impact the type of API control you give GATT applications versus any in-built GATT service discovery.
> Right now I'm trying to find out what would be the right interface from
> kernel
> to user space.
>
> > Also - a quick observation: yes, the connection parameters are only
> for LE links; however they have some semantic similarity with sniff
> mode in BR. Especially in the abstract form ("Low Latency" verus "Low
> Power"). Does BlueZ present an API like this already for BR (I'm new
> to BlueZ...I was more of a Symbian guy ;)? If not it might be worth
> having one API for both BR/Sniff and LE/Connection Parameters - and do
> the appropriate mapping "under the hood".
>
> Actually this has been discussed earlier and we need also some api to
> change
> sniff behaviour. Reason for this is broken devices which does not turn
> on
> normal mode when low latency is needed. I guess Jaikumar had some
> patches
> regarding this?
I think it's a bit deeper than broken devices: the specifications offer no real way for devices to agree why a particular mode (eg active or sniff) is needed at a particular time. This then gives interoperability problems because one side may decide it wants sniff mode; but the other does not know why.
Tim
This message is for the designated recipient only and may contain privileged, proprietary, or otherwise private information. If you have received it in error, please notify the sender immediately and delete the original. Any other use of the email by you is prohibited.
^ permalink raw reply
* HCI UART 3Wire support in Linux
From: Suraj Sumangala @ 2010-11-16 9:47 UTC (permalink / raw)
To: linux-bluetooth@vger.kernel.org; +Cc: Jothikumar Mothilal, Gustavo F. Padovan
Hi,
We are trying to add HCI UART 3Wire support in the transport driver for
AR300x Bluetooth controller.
Is there any driver implementation that support HCI UART 3Wire protocol?
Regards
Suraj
^ permalink raw reply
* Re: [RFC] Interface to set LE connection parameters
From: Ville Tervo @ 2010-11-16 8:56 UTC (permalink / raw)
To: ext Mike Tsai; +Cc: linux-bluetooth@vger.kernel.org
In-Reply-To: <35B17FE5076C7040809188FBE7913F98406D465470@SC1EXMB-MBCL.global.atheros.com>
Hi Mike,
n Mon, Nov 15, 2010 at 07:15:44PM +0100, ext Mike Tsai wrote:
> Hi Ville,
>
> -----Original Message-----
> From: linux-bluetooth-owner@vger.kernel.org [mailto:linux-bluetooth-owner@vger.kernel.org] On Behalf Of Ville Tervo
> Sent: Monday, November 15, 2010 4:07 AM
> To: linux-bluetooth@vger.kernel.org
> Subject: [RFC] Interface to set LE connection parameters
>
> Hi,
>
> LE profiles have different requirements for connection parameters. Mainly
> trying to balance between power consumption and latencies. Probably more will
> factors will be in future.
>
> Currently I have plan to introduce new l2cap socket option which can be used
> before connection creation to set inital settings and also change settings
> while having a connection.
>
> Since there is no equivalents in EDR/BR connection I'm planning to make then
> apply only LE connection.
>
>
> Other question which parameters should be exposed to user space? Connection
> creation and connection update have these common parameters. Connection
> creation has in addition some other parameters also but they should be handled
> in some other way.
>
> __le16 conn_interval_min;
> __le16 conn_interval_max;
> __le16 conn_latency;
> __le16 supervision_timeout;
> __le16 min_ce_len;
> __le16 max_ce_len;
>
> So far I have had two ideas. The first is to simply expose all these fields
> with sock_opt. In that way profiles would be able to define their requirements
> also in future without any sock opt changes.
>
> Second is to define BT_LE_LOW_LAT for low latency connection requirements and
> BT_LE_LOW_POWER connection where the latency is not an issue. It would make
> usage of this sock opt interface simplier. OTOH the only user should be
> bluetoothd so it doesn't need to be as simple as possible.
>
>
> Comments please.
>
> [MTsai] - how about following parameters,
>
> Scan internal,
> Scan window,
> Peer address type,
These are connection creation parameters. Maybe BT_LE_LOW_LAT/BT_LE_LOW_POWER
could be used also for these values. But I think they should defined in some
other way.
--
Ville
^ permalink raw reply
* Re: [PATCH v5] Bluetooth: btwilink driver
From: Pavan Savoy @ 2010-11-16 7:03 UTC (permalink / raw)
To: marcel, padovan; +Cc: linux-bluetooth, linux-kernel, Pavan Savoy
In-Reply-To: <1289394446-14021-1-git-send-email-pavan_savoy@ti.com>
On Wed, Nov 10, 2010 at 6:37 PM, <pavan_savoy@ti.com> wrote:
> From: Pavan Savoy <pavan_savoy@ti.com>
>
Marcel,
Any comments? on this version 5 patch?
> Thanks for the comments...
> This patch contains,
> v5 comments :-
> declaration and assiging of variables and private data fixed up.
> proper casting.
> removed redundant un-necessary checks in send_frame.
> HCI_RUNNING fixes in terms of test_and_set/clear bit instead of set and
> clear.
> removed redundant checks for hdev, skb being NULL.
> removed module_param of reset, also WiLink don't need HCI_RESET anyways.
> removed ti_st_register_dev function and functionality moved to _probe.
> module_init/exit function names fixed up.
>
> stat byte counter increments and tx_complete is similar to hci_ldisc.
> Also I have not implemented the flush routine, since the functionality
> which needs to be done in flush routine is done in the underlying driver
> which is the shared transport driver and moreover the btwilink driver by
> itself doesn't maintains queue or data relevant to transport, so nothing
> to do.
>
> And Yes, I have verified this driver with multiple up/down reset on
> hci0.
> Also I generally test a2dp/ftp to verify large data transfers.
>
> Please review and comment.
>
> Thanks,
> Pavan
>
> v4 comments :-
> module init now returns what platform_driver_register returns.
> type casting of void* private data has been removed
>
> v3 comments :-
> Lizardo,
> I have taken care of most of the comments you had.
> Have re-wrote some of the code commenting you've mentioned.
> Thanks for the comments,
>
> The other few like -EPERM for platform driver registration is to keep
> it similar to other drivers, type casting is maintained just to feel safe
> and have style similar to other drivers.
> BT_WILINK in Kconfig is similar to BT_MRVL.
> I hope those aren't too critical.
>
> -- patch description --
>
> This is the bluetooth protocol driver for the TI WiLink7 chipsets.
> Texas Instrument's WiLink chipsets combine wireless technologies
> like BT, FM, GPS and WLAN onto a single chip.
>
> This Bluetooth driver works on top of the TI_ST shared transport
> line discipline driver which also allows other drivers like
> FM V4L2 and GPS character driver to make use of the same UART interface.
>
> Kconfig and Makefile modifications to enable the Bluetooth
> driver for Texas Instrument's WiLink 7 chipset.
>
> Signed-off-by: Pavan Savoy <pavan_savoy@ti.com>
> ---
> =C2=A0drivers/bluetooth/Kconfig =C2=A0 =C2=A0| =C2=A0 10 +
> =C2=A0drivers/bluetooth/Makefile =C2=A0 | =C2=A0 =C2=A01 +
> =C2=A0drivers/bluetooth/btwilink.c | =C2=A0379 ++++++++++++++++++++++++++=
++++++++++++++++
> =C2=A03 files changed, 390 insertions(+), 0 deletions(-)
> =C2=A0create mode 100644 drivers/bluetooth/btwilink.c
>
> diff --git a/drivers/bluetooth/Kconfig b/drivers/bluetooth/Kconfig
> index 02deef4..8e0de9a 100644
> --- a/drivers/bluetooth/Kconfig
> +++ b/drivers/bluetooth/Kconfig
> @@ -219,4 +219,14 @@ config BT_ATH3K
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Say Y here to compile support for "Athe=
ros firmware download driver"
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0into the kernel or say M to compile it =
as module (ath3k).
>
> +config BT_WILINK
> + =C2=A0 =C2=A0 =C2=A0 tristate "Texas Instruments WiLink7 driver"
> + =C2=A0 =C2=A0 =C2=A0 depends on TI_ST
> + =C2=A0 =C2=A0 =C2=A0 help
> + =C2=A0 =C2=A0 =C2=A0 =C2=A0 This enables the Bluetooth driver for Texas=
Instrument's BT/FM/GPS
> + =C2=A0 =C2=A0 =C2=A0 =C2=A0 combo devices. This makes use of shared tra=
nsport line discipline
> + =C2=A0 =C2=A0 =C2=A0 =C2=A0 core driver to communicate with the BT core=
of the combo chip.
> +
> + =C2=A0 =C2=A0 =C2=A0 =C2=A0 Say Y here to compile support for Texas Ins=
trument's WiLink7 driver
> + =C2=A0 =C2=A0 =C2=A0 =C2=A0 into the kernel or say M to compile it as m=
odule.
> =C2=A0endmenu
> diff --git a/drivers/bluetooth/Makefile b/drivers/bluetooth/Makefile
> index 71bdf13..f4460f4 100644
> --- a/drivers/bluetooth/Makefile
> +++ b/drivers/bluetooth/Makefile
> @@ -18,6 +18,7 @@ obj-$(CONFIG_BT_HCIBTSDIO) =C2=A0 =C2=A0+=3D btsdio.o
> =C2=A0obj-$(CONFIG_BT_ATH3K) =C2=A0 =C2=A0 =C2=A0 =C2=A0 +=3D ath3k.o
> =C2=A0obj-$(CONFIG_BT_MRVL) =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+=3D btmrvl=
.o
> =C2=A0obj-$(CONFIG_BT_MRVL_SDIO) =C2=A0 =C2=A0 +=3D btmrvl_sdio.o
> +obj-$(CONFIG_BT_WILINK) =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=
=C2=A0+=3D btwilink.o
>
> =C2=A0btmrvl-y =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 :=3D btmrvl_main.o
> =C2=A0btmrvl-$(CONFIG_DEBUG_FS) =C2=A0 =C2=A0 =C2=A0+=3D btmrvl_debugfs.o
> diff --git a/drivers/bluetooth/btwilink.c b/drivers/bluetooth/btwilink.c
> new file mode 100644
> index 0000000..1b1c4bc
> --- /dev/null
> +++ b/drivers/bluetooth/btwilink.c
> @@ -0,0 +1,379 @@
> +/*
> + * =C2=A0Texas Instrument's Bluetooth Driver For Shared Transport.
> + *
> + * =C2=A0Bluetooth Driver acts as interface between HCI core and
> + * =C2=A0TI Shared Transport Layer.
> + *
> + * =C2=A0Copyright (C) 2009-2010 Texas Instruments
> + * =C2=A0Author: Raja Mani <raja_mani@ti.com>
> + * =C2=A0 =C2=A0 Pavan Savoy <pavan_savoy@ti.com>
> + *
> + * =C2=A0This program is free software; you can redistribute it and/or m=
odify
> + * =C2=A0it under the terms of the GNU General Public License version 2 =
as
> + * =C2=A0published by the Free Software Foundation.
> + *
> + * =C2=A0This program is distributed in the hope that it will be useful,
> + * =C2=A0but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * =C2=A0MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. =C2=A0See =
the
> + * =C2=A0GNU General Public License for more details.
> + *
> + * =C2=A0You should have received a copy of the GNU General Public Licen=
se
> + * =C2=A0along with this program; if not, write to the Free Software
> + * =C2=A0Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA =C2=A0=
02111-1307 =C2=A0USA
> + *
> + */
> +
> +#include <linux/platform_device.h>
> +#include <net/bluetooth/bluetooth.h>
> +#include <net/bluetooth/hci_core.h>
> +
> +#include <linux/ti_wilink_st.h>
> +
> +/* Bluetooth Driver Version */
> +#define VERSION =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 "1.0"
> +
> +/* Number of seconds to wait for registration completion
> + * when ST returns PENDING status.
> + */
> +#define BT_REGISTER_TIMEOUT =C2=A0 6000 =C2=A0 =C2=A0 /* 6 sec */
> +
> +/**
> + * struct ti_st - driver operation structure
> + * @hdev: hci device pointer which binds to bt driver
> + * @reg_status: ST registration callback status
> + * @st_write: write function provided by the ST driver
> + * =C2=A0 =C2=A0 to be used by the driver during send_frame.
> + * @wait_reg_completion - completion sync between ti_st_open
> + * =C2=A0 =C2=A0 and ti_st_registration_completion_cb.
> + */
> +struct ti_st {
> + =C2=A0 =C2=A0 =C2=A0 struct hci_dev *hdev;
> + =C2=A0 =C2=A0 =C2=A0 char reg_status;
> + =C2=A0 =C2=A0 =C2=A0 long (*st_write) (struct sk_buff *);
> + =C2=A0 =C2=A0 =C2=A0 struct completion wait_reg_completion;
> +};
> +
> +/* Increments HCI counters based on pocket ID (cmd,acl,sco) */
> +static inline void ti_st_tx_complete(struct ti_st *hst, int pkt_type)
> +{
> + =C2=A0 =C2=A0 =C2=A0 struct hci_dev *hdev =3D hst->hdev;
> +
> + =C2=A0 =C2=A0 =C2=A0 /* Update HCI stat counters */
> + =C2=A0 =C2=A0 =C2=A0 switch (pkt_type) {
> + =C2=A0 =C2=A0 =C2=A0 case HCI_COMMAND_PKT:
> + =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 hdev->stat.cmd_tx++;
> + =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 break;
> +
> + =C2=A0 =C2=A0 =C2=A0 case HCI_ACLDATA_PKT:
> + =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 hdev->stat.acl_tx++;
> + =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 break;
> +
> + =C2=A0 =C2=A0 =C2=A0 case HCI_SCODATA_PKT:
> + =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 hdev->stat.sco_tx++;
> + =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 break;
> + =C2=A0 =C2=A0 =C2=A0 }
> +}
> +
> +/* ------- Interfaces to Shared Transport ------ */
> +
> +/* Called by ST layer to indicate protocol registration completion
> + * status.ti_st_open() function will wait for signal from this
> + * API when st_register() function returns ST_PENDING.
> + */
> +static void st_registration_completion_cb(void *priv_data, char data)
> +{
> + =C2=A0 =C2=A0 =C2=A0 struct ti_st *lhst =3D priv_data;
> +
> + =C2=A0 =C2=A0 =C2=A0 /* Save registration status for use in ti_st_open(=
) */
> + =C2=A0 =C2=A0 =C2=A0 lhst->reg_status =3D data;
> + =C2=A0 =C2=A0 =C2=A0 /* complete the wait in ti_st_open() */
> + =C2=A0 =C2=A0 =C2=A0 complete(&lhst->wait_reg_completion);
> +}
> +
> +/* Called by Shared Transport layer when receive data is
> + * available */
> +static long st_receive(void *priv_data, struct sk_buff *skb)
> +{
> + =C2=A0 =C2=A0 =C2=A0 struct ti_st *lhst =3D priv_data;
> + =C2=A0 =C2=A0 =C2=A0 int err;
> +
> + =C2=A0 =C2=A0 =C2=A0 if (!skb)
> + =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 return -EFAULT;
> +
> + =C2=A0 =C2=A0 =C2=A0 if (!lhst) {
> + =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 kfree_skb(skb);
> + =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 return -EFAULT;
> + =C2=A0 =C2=A0 =C2=A0 }
> +
> + =C2=A0 =C2=A0 =C2=A0 skb->dev =3D (void *) lhst->hdev;
> +
> + =C2=A0 =C2=A0 =C2=A0 /* Forward skb to HCI core layer */
> + =C2=A0 =C2=A0 =C2=A0 err =3D hci_recv_frame(skb);
> + =C2=A0 =C2=A0 =C2=A0 if (err < 0) {
> + =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 BT_ERR("Unable to push=
skb to HCI core(%d)", err);
> + =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 return err;
> + =C2=A0 =C2=A0 =C2=A0 }
> +
> + =C2=A0 =C2=A0 =C2=A0 lhst->hdev->stat.byte_rx +=3D skb->len;
> +
> + =C2=A0 =C2=A0 =C2=A0 return 0;
> +}
> +
> +/* ------- Interfaces to HCI layer ------ */
> +/* protocol structure registered with shared transport */
> +static struct st_proto_s ti_st_proto =3D {
> + =C2=A0 =C2=A0 =C2=A0 .type =3D ST_BT,
> + =C2=A0 =C2=A0 =C2=A0 .recv =3D st_receive,
> + =C2=A0 =C2=A0 =C2=A0 .reg_complete_cb =3D st_registration_completion_cb=
,
> +};
> +
> +/* Called from HCI core to initialize the device */
> +static int ti_st_open(struct hci_dev *hdev)
> +{
> + =C2=A0 =C2=A0 =C2=A0 unsigned long timeleft;
> + =C2=A0 =C2=A0 =C2=A0 struct ti_st *hst;
> + =C2=A0 =C2=A0 =C2=A0 int err;
> +
> + =C2=A0 =C2=A0 =C2=A0 BT_DBG("%s %p", hdev->name, hdev);
> +
> + =C2=A0 =C2=A0 =C2=A0 /* provide contexts for callbacks from ST */
> + =C2=A0 =C2=A0 =C2=A0 hst =3D hdev->driver_data;
> + =C2=A0 =C2=A0 =C2=A0 ti_st_proto.priv_data =3D hst;
> +
> + =C2=A0 =C2=A0 =C2=A0 err =3D st_register(&ti_st_proto);
> + =C2=A0 =C2=A0 =C2=A0 if (err =3D=3D -EINPROGRESS) {
> + =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 /* Prepare wait-for-co=
mpletion handler data structures.
> + =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0* Needed to sync=
hronize this and
> + =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0* st_registratio=
n_completion_cb() functions.
> + =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0*/
> + =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 init_completion(&hst->=
wait_reg_completion);
> +
> + =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 /* Reset ST registrati=
on callback status flag , this value
> + =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0* will be update=
d in ti_st_registration_completion_cb()
> + =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0* function whene=
ver it called from ST driver.
> + =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0*/
> + =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 hst->reg_status =3D -E=
INPROGRESS;
> +
> + =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 /* ST is busy with eit=
her protocol registration or firmware
> + =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0* download. Wait=
until the registration callback is called
> + =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0*/
> + =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 BT_DBG(" waiting for r=
egistration completion signal from ST");
> +
> + =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 timeleft =3D wait_for_=
completion_timeout
> + =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 (&hst->wait_reg_completion,
> + =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0msecs_to_jiffies(BT_REGISTER_TIMEOUT));
> + =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 if (!timeleft) {
> + =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 BT_ERR("Timeout(%d sec),didn't get reg "
> + =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 "completion =
signal from ST",
> + =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 BT_REGISTER_=
TIMEOUT / 1000);
> + =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 return -ETIMEDOUT;
> + =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 }
> +
> + =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 /* Is ST registration =
callback called with ERROR status? */
> + =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 if (hst->reg_status !=
=3D 0) {
> + =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 BT_ERR("ST registration completed with invalid "
> + =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 "status %d",=
hst->reg_status);
> + =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 return -EAGAIN;
> + =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 }
> + =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 err =3D 0;
> + =C2=A0 =C2=A0 =C2=A0 } else if (err =3D=3D -EPERM) {
> + =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 BT_ERR("st_register fa=
iled %d", err);
> + =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 return err;
> + =C2=A0 =C2=A0 =C2=A0 }
> +
> + =C2=A0 =C2=A0 =C2=A0 /* ti_st_proto.write is filled up by the underlyin=
g shared
> + =C2=A0 =C2=A0 =C2=A0 =C2=A0* transport driver upon registration
> + =C2=A0 =C2=A0 =C2=A0 =C2=A0*/
> + =C2=A0 =C2=A0 =C2=A0 hst->st_write =3D ti_st_proto.write;
> + =C2=A0 =C2=A0 =C2=A0 if (!hst->st_write) {
> + =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 BT_ERR("undefined ST w=
rite function");
> +
> + =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 /* Undo registration w=
ith ST */
> + =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 err =3D st_unregister(=
ST_BT);
> + =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 if (err)
> + =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 BT_ERR("st_unregister() failed with error %d", err);
> +
> + =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 hst->st_write =3D NULL=
;
> + =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 return err;
> + =C2=A0 =C2=A0 =C2=A0 }
> +
> + =C2=A0 =C2=A0 =C2=A0 /* Registration with ST layer is successful,
> + =C2=A0 =C2=A0 =C2=A0 =C2=A0* hardware is ready to accept commands from =
HCI core.
> + =C2=A0 =C2=A0 =C2=A0 =C2=A0*/
> + =C2=A0 =C2=A0 =C2=A0 if (test_and_set_bit(HCI_RUNNING, &hdev->flags)) {
> + =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 clear_bit(HCI_RUNNING,=
&hdev->flags);
> + =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 err =3D st_unregister(=
ST_BT);
> + =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 if (err)
> + =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 BT_ERR("st_unregister() failed with error %d", err);
> + =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 hst->st_write =3D NULL=
;
> + =C2=A0 =C2=A0 =C2=A0 }
> +
> + =C2=A0 =C2=A0 =C2=A0 return err;
> +}
> +
> +/* Close device */
> +static int ti_st_close(struct hci_dev *hdev)
> +{
> + =C2=A0 =C2=A0 =C2=A0 int err;
> + =C2=A0 =C2=A0 =C2=A0 struct ti_st *hst =3D hdev->driver_data;
> +
> + =C2=A0 =C2=A0 =C2=A0 /* continue to unregister from transport */
> + =C2=A0 =C2=A0 =C2=A0 err =3D st_unregister(ST_BT);
> + =C2=A0 =C2=A0 =C2=A0 if (err)
> + =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 BT_ERR("st_unregister(=
) failed with error %d", err);
> +
> + =C2=A0 =C2=A0 =C2=A0 hst->st_write =3D NULL;
> +
> + =C2=A0 =C2=A0 =C2=A0 if (!test_and_clear_bit(HCI_RUNNING, &hdev->flags)=
)
> + =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 return 0;
> +
> + =C2=A0 =C2=A0 =C2=A0 return err;
> +}
> +
> +static int ti_st_send_frame(struct sk_buff *skb)
> +{
> + =C2=A0 =C2=A0 =C2=A0 struct hci_dev *hdev;
> + =C2=A0 =C2=A0 =C2=A0 struct ti_st *hst;
> + =C2=A0 =C2=A0 =C2=A0 long len;
> +
> + =C2=A0 =C2=A0 =C2=A0 hdev =3D (struct hci_dev *)skb->dev;
> +
> + =C2=A0 =C2=A0 =C2=A0 if (!test_bit(HCI_RUNNING, &hdev->flags))
> + =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 return -EBUSY;
> +
> + =C2=A0 =C2=A0 =C2=A0 hst =3D hdev->driver_data;
> +
> + =C2=A0 =C2=A0 =C2=A0 /* Prepend skb with frame type */
> + =C2=A0 =C2=A0 =C2=A0 memcpy(skb_push(skb, 1), &bt_cb(skb)->pkt_type, 1)=
;
> +
> + =C2=A0 =C2=A0 =C2=A0 BT_DBG(" %s: type %d len %d", hdev->name, bt_cb(sk=
b)->pkt_type,
> + =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 skb->len);
> +
> + =C2=A0 =C2=A0 =C2=A0 /* Insert skb to shared transport layer's transmit=
queue.
> + =C2=A0 =C2=A0 =C2=A0 =C2=A0* Freeing skb memory is taken care in shared=
transport layer,
> + =C2=A0 =C2=A0 =C2=A0 =C2=A0* so don't free skb memory here.
> + =C2=A0 =C2=A0 =C2=A0 =C2=A0*/
> + =C2=A0 =C2=A0 =C2=A0 len =3D hst->st_write(skb);
> + =C2=A0 =C2=A0 =C2=A0 if (len < 0) {
> + =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 kfree_skb(skb);
> + =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 BT_ERR(" ST write fail=
ed (%ld)", len);
> + =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 return -EAGAIN;
> + =C2=A0 =C2=A0 =C2=A0 }
> +
> + =C2=A0 =C2=A0 =C2=A0 /* ST accepted our skb. So, Go ahead and do rest *=
/
> + =C2=A0 =C2=A0 =C2=A0 hdev->stat.byte_tx +=3D len;
> + =C2=A0 =C2=A0 =C2=A0 ti_st_tx_complete(hst, bt_cb(skb)->pkt_type);
> +
> + =C2=A0 =C2=A0 =C2=A0 return 0;
> +}
> +
> +static void ti_st_destruct(struct hci_dev *hdev)
> +{
> + =C2=A0 =C2=A0 =C2=A0 BT_DBG("%s", hdev->name);
> +
> + =C2=A0 =C2=A0 =C2=A0 /* free ti_st memory */
> + =C2=A0 =C2=A0 =C2=A0 kfree(hdev->driver_data);
> +
> + =C2=A0 =C2=A0 =C2=A0 return;
> +}
> +
> +static int bt_ti_probe(struct platform_device *pdev)
> +{
> + =C2=A0 =C2=A0 =C2=A0 static struct ti_st *hst;
> + =C2=A0 =C2=A0 =C2=A0 struct hci_dev *hdev;
> + =C2=A0 =C2=A0 =C2=A0 int err;
> +
> + =C2=A0 =C2=A0 =C2=A0 hst =3D kzalloc(sizeof(struct ti_st), GFP_KERNEL);
> + =C2=A0 =C2=A0 =C2=A0 if (!hst)
> + =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 return -ENOMEM;
> +
> + =C2=A0 =C2=A0 =C2=A0 /* Expose "hciX" device to user space */
> + =C2=A0 =C2=A0 =C2=A0 hdev =3D hci_alloc_dev();
> + =C2=A0 =C2=A0 =C2=A0 if (!hdev)
> + =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 return -ENOMEM;
> +
> + =C2=A0 =C2=A0 =C2=A0 BT_DBG("hdev %p", hdev);
> +
> + =C2=A0 =C2=A0 =C2=A0 hst->hdev =3D hdev;
> + =C2=A0 =C2=A0 =C2=A0 hdev->bus =3D HCI_UART;
> + =C2=A0 =C2=A0 =C2=A0 hdev->driver_data =3D hst;
> + =C2=A0 =C2=A0 =C2=A0 hdev->open =3D ti_st_open;
> + =C2=A0 =C2=A0 =C2=A0 hdev->close =3D ti_st_close;
> + =C2=A0 =C2=A0 =C2=A0 hdev->flush =3D NULL;
> + =C2=A0 =C2=A0 =C2=A0 hdev->send =3D ti_st_send_frame;
> + =C2=A0 =C2=A0 =C2=A0 hdev->destruct =3D ti_st_destruct;
> + =C2=A0 =C2=A0 =C2=A0 hdev->owner =3D THIS_MODULE;
> +
> + =C2=A0 =C2=A0 =C2=A0 err =3D hci_register_dev(hdev);
> + =C2=A0 =C2=A0 =C2=A0 if (err < 0) {
> + =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 BT_ERR("Can't register=
HCI device error %d", err);
> + =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 hci_free_dev(hdev);
> + =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 return err;
> + =C2=A0 =C2=A0 =C2=A0 }
> +
> + =C2=A0 =C2=A0 =C2=A0 BT_DBG(" HCI device registered (hdev %p)", hdev);
> +
> + =C2=A0 =C2=A0 =C2=A0 dev_set_drvdata(&pdev->dev, hst);
> + =C2=A0 =C2=A0 =C2=A0 return err;
> +}
> +
> +static int bt_ti_remove(struct platform_device *pdev)
> +{
> + =C2=A0 =C2=A0 =C2=A0 struct hci_dev *hdev;
> + =C2=A0 =C2=A0 =C2=A0 struct ti_st *hst =3D dev_get_drvdata(&pdev->dev);
> +
> + =C2=A0 =C2=A0 =C2=A0 if (!hst)
> + =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 return -EFAULT;
> +
> + =C2=A0 =C2=A0 =C2=A0 hdev =3D hst->hdev;
> + =C2=A0 =C2=A0 =C2=A0 ti_st_close(hdev);
> + =C2=A0 =C2=A0 =C2=A0 hci_unregister_dev(hdev);
> +
> + =C2=A0 =C2=A0 =C2=A0 /* Free HCI device memory */
> + =C2=A0 =C2=A0 =C2=A0 hci_free_dev(hdev);
> +
> + =C2=A0 =C2=A0 =C2=A0 /* Free driver data memory */
> + =C2=A0 =C2=A0 =C2=A0 kfree(hst);
> +
> + =C2=A0 =C2=A0 =C2=A0 dev_set_drvdata(&pdev->dev, NULL);
> + =C2=A0 =C2=A0 =C2=A0 return 0;
> +}
> +
> +static struct platform_driver btwilink_driver =3D {
> + =C2=A0 =C2=A0 =C2=A0 .probe =3D bt_ti_probe,
> + =C2=A0 =C2=A0 =C2=A0 .remove =3D bt_ti_remove,
> + =C2=A0 =C2=A0 =C2=A0 .driver =3D {
> + =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 .name =3D "btwilink",
> + =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 .owner =3D THIS_MODULE=
,
> + =C2=A0 =C2=A0 =C2=A0 },
> +};
> +
> +/* ------- Module Init/Exit interfaces ------ */
> +static int __init btwilink_init(void)
> +{
> + =C2=A0 =C2=A0 =C2=A0 long ret;
> +
> + =C2=A0 =C2=A0 =C2=A0 BT_INFO(" Bluetooth Driver for TI WiLink - Version=
%s", VERSION);
> +
> + =C2=A0 =C2=A0 =C2=A0 ret =3D platform_driver_register(&btwilink_driver)=
;
> + =C2=A0 =C2=A0 =C2=A0 if (ret !=3D 0) {
> + =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 BT_ERR("btwilink platf=
orm driver registration failed");
> + =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 return ret;
> + =C2=A0 =C2=A0 =C2=A0 }
> + =C2=A0 =C2=A0 =C2=A0 return 0;
> +}
> +
> +static void __exit btwilink_exit(void)
> +{
> + =C2=A0 =C2=A0 =C2=A0 platform_driver_unregister(&btwilink_driver);
> +}
> +
> +module_init(btwilink_init);
> +module_exit(btwilink_exit);
> +
> +/* ------ Module Info ------ */
> +
> +MODULE_AUTHOR("Raja Mani <raja_mani@ti.com>");
> +MODULE_DESCRIPTION("Bluetooth Driver for TI Shared Transport" VERSION);
> +MODULE_VERSION(VERSION);
> +MODULE_LICENSE("GPL");
> --
> 1.5.6.3
>
> --
> 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 =C2=A0http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply
* Re: [PATCH 3/4] Add DBus OOB API documentation.
From: jaikumar Ganesh @ 2010-11-16 4:16 UTC (permalink / raw)
To: Szymon Janc; +Cc: linux-bluetooth@vger.kernel.org
In-Reply-To: <201011150954.23553.szymon.janc@tieto.com>
On Mon, Nov 15, 2010 at 12:54 AM, Szymon Janc <szymon.janc@tieto.com> wrote:
> Hi Jaikumar,
>
>> > + void Deactivate()
>>
>> Would it better to make this a signal ? Deactivate by itself as the
>> only method doesn't seem to be right.
>
> I'll change it to Release() to be consistent with other (Agent) API as
> suggested by Johan.
>
>> > + void RegisterProvider(object provider)
>> > +
>> > + This method registers provider for DBus OOB plug-in.
>> > + When provider is successfully registered plug-in becomes
>> > + active. Only one provider can be registered at time.
>>
>> Why are we enforcing this limitation ?
>
> Spec requires that each hash&randomizer values should be used only for one OOB
> transfer. Implementation enforces that by allowing only one active OOB plugin
> at time and DBUS OOB plugin only 'expose' plugin API over DBUS. So this
> limitation is a consequence of that.
I don't think the spec says that. It just says every single time the
call to read the local adapters hash
and randomizer is done you get new values. You can use the value that
you have obtained for as many OOB pairings
as you wish.
>
> This limitation also allows for (IMHO) simpler plugins implementation as they
> don't have to care about other plugins hanging around to fulfill that
> requirement.
>
>> > + array{bye}, array{byte} UpdateLocalOobData(string address)
>>
>> You are not updating anything here. You are just reading the local
>> adapter OOB data
>
> It is updating hash and randomizer. Underlying functions are called Read* as
> this is how corresponding HCI command is called (see Vol2. Part E. 7.3.60).
> I'll change it to Read to keep all calls name consistent with HCI command name
> and add appropriate note in API documentation as this name may be somewhat
> misleading (yet OOB plugin implementer should be aware of that already).
>
> --
> Szymon Janc
>
^ permalink raw reply
* RE: [PATCH v2 1/7] Fix invalid memory access when EIR field length is zero
From: Inga Stotland @ 2010-11-16 0:41 UTC (permalink / raw)
To: 'Anderson Lizardo', 'Vinicius Costa Gomes',
linux-bluetooth, 'Bruna Moreira'
In-Reply-To: <AANLkTi=J39omUnYYWLpB0ncd6Kd8LukdFopM4WDyWNJ1@mail.gmail.com>
Hi Anderson,
-----Original Message-----
From: linux-bluetooth-owner@vger.kernel.org
[mailto:linux-bluetooth-owner@vger.kernel.org] On Behalf Of Anderson Lizardo
Sent: Friday, November 12, 2010 5:01 PM
To: Inga Stotland; Vinicius Costa Gomes; linux-bluetooth@vger.kernel.org;
Bruna Moreira
Subject: Re: [PATCH v2 1/7] Fix invalid memory access when EIR field length
is zero
On 11/12/10, Johan Hedberg <johan.hedberg@gmail.com> wrote:
> Hi Inga,
>
> On Thu, Nov 11, 2010, Inga Stotland wrote:
>> Was there a bug to begin with? :)
>> The access to eir_data[1] was always valid due to the check (len <
>> EIR_DATA_LENGTH - 1)
>> and the fact that eir_data is a buffer of fixed length of EIR_DATA_LENGTH
>> (240 bytes).
>
> On closer inspection it seems you might be right, however it'd be nice
> to get some comments from the original patch author about this (were
> there e.g. crashes or some valgrind warnings observed or was this just
> speculation based on looking at the code).
There were valgrind "unintialized value" warnings related to this
after we started using it for parsing adv data (which is max 31 bytes
long but may be smaller because spec allows radio to strip non
significant bytes before sending, which explains why we added a length
parameter in a later patch). Actually I dont think the current code is
"safe" as it assumes the EIR data is aways 240 bytes long, which seems
true as per spec , but less data could be sent, causing reading beyond
buffer.
---------------
Just a note...
When Extended Inquiry Response HCI event comes to the upper layer parser
from
HCI layer it is guaranteed to contain 240 bytes where of course the non
significant part is zeroed out. This is ensured by internal implementation
in BlueZ and is spec compliant.
The fix is fine since it takes care of warnings, but personally I am a big
fan of
keeping meaningful variable names :)
Regards,
Inga Stotland
Sent by an employee of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.
^ permalink raw reply
* [PATCH] Fix typos in adapter documentation
From: Jose Antonio Santos Cadenas @ 2010-11-15 18:48 UTC (permalink / raw)
To: linux-bluetooth; +Cc: Jose Antonio Santos Cadenas
---
doc/adapter-api.txt | 8 ++++----
1 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/doc/adapter-api.txt b/doc/adapter-api.txt
index 6a28d30..65e2887 100644
--- a/doc/adapter-api.txt
+++ b/doc/adapter-api.txt
@@ -178,18 +178,18 @@ Signals PropertyChanged(string name, variant value)
DeviceFound(string address, dict values)
- This signal will be send every time an inquiry result
+ This signal will be sent every time an inquiry result
has been found by the service daemon. In general they
only appear during a device discovery.
- The dictionary can contain bascially the same values
- that we be returned by the GetProperties method
+ The dictionary can contain basically the same values
+ that are returned by the GetProperties method
from the org.bluez.Device interface. In addition there
can be values for the RSSI and the TX power level.
DeviceDisappeared(string address)
- This signal will be send when an inquiry session for
+ This signal will be sent when an inquiry session for
a periodic discovery finishes and previously found
devices are no longer in range or visible.
--
1.7.1
^ permalink raw reply related
* RE: [RFC] Interface to set LE connection parameters
From: Mike Tsai @ 2010-11-15 18:15 UTC (permalink / raw)
To: Ville Tervo, linux-bluetooth@vger.kernel.org
In-Reply-To: <20101115120632.GB16464@null>
Hi Ville,
-----Original Message-----
From: linux-bluetooth-owner@vger.kernel.org [mailto:linux-bluetooth-owner@vger.kernel.org] On Behalf Of Ville Tervo
Sent: Monday, November 15, 2010 4:07 AM
To: linux-bluetooth@vger.kernel.org
Subject: [RFC] Interface to set LE connection parameters
Hi,
LE profiles have different requirements for connection parameters. Mainly
trying to balance between power consumption and latencies. Probably more will
factors will be in future.
Currently I have plan to introduce new l2cap socket option which can be used
before connection creation to set inital settings and also change settings
while having a connection.
Since there is no equivalents in EDR/BR connection I'm planning to make then
apply only LE connection.
Other question which parameters should be exposed to user space? Connection
creation and connection update have these common parameters. Connection
creation has in addition some other parameters also but they should be handled
in some other way.
__le16 conn_interval_min;
__le16 conn_interval_max;
__le16 conn_latency;
__le16 supervision_timeout;
__le16 min_ce_len;
__le16 max_ce_len;
So far I have had two ideas. The first is to simply expose all these fields
with sock_opt. In that way profiles would be able to define their requirements
also in future without any sock opt changes.
Second is to define BT_LE_LOW_LAT for low latency connection requirements and
BT_LE_LOW_POWER connection where the latency is not an issue. It would make
usage of this sock opt interface simplier. OTOH the only user should be
bluetoothd so it doesn't need to be as simple as possible.
Comments please.
[MTsai] - how about following parameters,
Scan internal,
Scan window,
Peer address type,
Thanks,
Mike
--
Ville
--
To unsubscribe from this list: send the line "unsubscribe linux-bluetooth" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* RE: [PATCH 1/4] Sim Access Profile API
From: Waldemar.Rymarkiewicz @ 2010-11-15 17:29 UTC (permalink / raw)
To: luiz.dentz, padovan
Cc: marcel, linux-bluetooth, suraj, johan.hedberg, joakim.xj.ceder
In-Reply-To: <AANLkTino6tJbpEMWxz-PLBmOyb8=3KCr1uDm9dxSbp98@mail.gmail.com>
Hi,=20
>Hi,
>>> >> + =A0 =A0 =A0 =A0 =A0void Disconnect(boolean type)
>>> >> +
>>> >> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Disconnect SAP client from the =
server.
>>> >The 'type'
>>> >> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0parameter indicates disconnecti=
on type.
>>> >> +
>>> >> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0True =A0- gracefull disconnecti=
on
>>> >> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0False - immediate disconnection
>>> >> +
>>> >> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Possible errors: org.bluez.Erro=
r.Failed
>>> >
>>> >I don't like this style of method names at all. Using method names=20
>>> >like GracefulDisconnect and ImmediateDisconnect would be better.
>>>
>>> That's fine.
>>>
>>> >However I am not sure we should differentiate here at all.=20
>We should=20
>>> >always to the graceful disconnect. What will the immediate=20
>>> >disconnect bring us?
>>>
>>> That's actually intended for testing only. One of PTS test=20
>cases expects the tester to trigger immediate disconnect.
>>> In practce, it is only used when connection to sim card is=20
>lost, but this is obviously done internally.
>>
>>
>> So this shouldn't be in the API, no one is going to use it. You can=20
>> create something internally for the immediate disconnection that you=20
>> go and set manually inside the code. Make sure to comment in=20
>the code=20
>> why you are adding this there. That can also be a option in some of=20
>> the bluetooth config files. Let's see what others think here.
>
>Actually this looks a lot like virtual cable unplug that PTS=20
>wants to hid, it is just crap that nobody use, so maybe e.g.
>--enable-pts-bullshit would actually make sense to activate=20
>the nonsense that pts wants, well it is still annoying to=20
>recompile just to run PTS tests. For hid the virtual cable=20
>unplug can be emulate via RemoveDevice, so maybe it make sense=20
>to do a immediate disconnect in such case for sap too, but=20
>this is still inconvenient since you have to repair after doing it.
>
So, simply let's get rid of immediate disconnect from sap api and leave if =
for sap-driver (sap-*.c file ) provider. I could extend sap-dummy api just =
for an example.
Service org.bluez=20
Interface org.bluez.SimAccess=20
Object path [variable prefix]/{hci0,hci1,...}
Methods void Disconnect()
Disconnects SAP client from the server.
Possible errors: org.bluez.Error.Failed
void SetProperty(string name, variant value)
Changes the value of the specified property. Only
properties that are listed a read-write are changeable.
Possible Errors: org.bluez.Error.DoesNotExist=20
org.bluez.Error.InvalidArguments
dict GetProperties()
Return all properties for the interface. See the
properties section for available properties.
Possible Errors: org.bluez.Error.Failed
Signals PropertyChanged(string name, variant value)
This signal indicates a changed value of the given
property.
Properties boolean Enabled [readwrite]
Set to true to start-up SAP server and register SDP record for=20
it. Set to false to shutdown SAP server and remove the SDP record.
boolean Connected [readonly]
Indicates if SAP client is connected to the server.=20
More comments ?
Thanks,
/Waldek
^ permalink raw reply
* Re: [RFC] Interface to set LE connection parameters
From: Ville Tervo @ 2010-11-15 15:17 UTC (permalink / raw)
To: ext tim.howes@accenture.com; +Cc: linux-bluetooth@vger.kernel.org
In-Reply-To: <1AFE20D16950C745A2A83986B72E8748011F571E6CE6@EMEXM3131.dir.svc.accenture.com>
Hi Tim,
Please stop top posting on this ml.
On Mon, Nov 15, 2010 at 03:24:29PM +0100, ext tim.howes@accenture.com wrote:
> Hi Ville,
>
> As you note the different profiles would likely have different connection parameters. The different profiles may be running on the same LE link (indeed the same L2CAP [fixed] channel).
>
I guess the latency should override power requirements. Low power profile can
operate on low latency link but low latency profile fails on high latency. Of
course this gets much more complicated if there are more requirements.
Are these (latency and power) the only characteristics we need to deal with.
There might be some also. I'm not too familiar with profile drafts.
> Do you have a view on how the different profiles - on the same link - would have different requests arbitrated, and where that arbitration would be done? I'd imagine that the API towards the profiles should be of the abstract form - such as you mention (eg BT_LE_LOW_LAT). This would make it easier to arbitrate the different requests, as compared to if the profiles see an API of the "numerical" form (eg interval = N ms). I guess the arbitration could happen in user or kernel space; as long as there is something with singleton-like semantics to do it.
>
I think I need to get more details from profile specs and try to find out the
requirements from them.
Right now I'm trying to find out what would be the right interface from kernel
to user space.
> Also - a quick observation: yes, the connection parameters are only for LE links; however they have some semantic similarity with sniff mode in BR. Especially in the abstract form ("Low Latency" verus "Low Power"). Does BlueZ present an API like this already for BR (I'm new to BlueZ...I was more of a Symbian guy ;)? If not it might be worth having one API for both BR/Sniff and LE/Connection Parameters - and do the appropriate mapping "under the hood".
Actually this has been discussed earlier and we need also some api to change
sniff behaviour. Reason for this is broken devices which does not turn on
normal mode when low latency is needed. I guess Jaikumar had some patches
regarding this?
--
Ville
^ permalink raw reply
* RE: [RFC] Interface to set LE connection parameters
From: tim.howes @ 2010-11-15 14:24 UTC (permalink / raw)
To: ville.tervo, linux-bluetooth
In-Reply-To: <20101115120632.GB16464@null>
Hi Ville,
As you note the different profiles would likely have different connection parameters. The different profiles may be running on the same LE link (indeed the same L2CAP [fixed] channel).
Do you have a view on how the different profiles - on the same link - would have different requests arbitrated, and where that arbitration would be done? I'd imagine that the API towards the profiles should be of the abstract form - such as you mention (eg BT_LE_LOW_LAT). This would make it easier to arbitrate the different requests, as compared to if the profiles see an API of the "numerical" form (eg interval = N ms). I guess the arbitration could happen in user or kernel space; as long as there is something with singleton-like semantics to do it.
Also - a quick observation: yes, the connection parameters are only for LE links; however they have some semantic similarity with sniff mode in BR. Especially in the abstract form ("Low Latency" verus "Low Power"). Does BlueZ present an API like this already for BR (I'm new to BlueZ...I was more of a Symbian guy ;)? If not it might be worth having one API for both BR/Sniff and LE/Connection Parameters - and do the appropriate mapping "under the hood".
Cheers,
Tim
-----Original Message-----
From: linux-bluetooth-owner@vger.kernel.org [mailto:linux-bluetooth-owner@vger.kernel.org] On Behalf Of Ville Tervo
Sent: 15 November 2010 12:07
To: linux-bluetooth@vger.kernel.org
Subject: [RFC] Interface to set LE connection parameters
Hi,
LE profiles have different requirements for connection parameters. Mainly
trying to balance between power consumption and latencies. Probably more will
factors will be in future.
Currently I have plan to introduce new l2cap socket option which can be used
before connection creation to set inital settings and also change settings
while having a connection.
Since there is no equivalents in EDR/BR connection I'm planning to make then
apply only LE connection.
Other question which parameters should be exposed to user space? Connection
creation and connection update have these common parameters. Connection
creation has in addition some other parameters also but they should be handled
in some other way.
__le16 conn_interval_min;
__le16 conn_interval_max;
__le16 conn_latency;
__le16 supervision_timeout;
__le16 min_ce_len;
__le16 max_ce_len;
So far I have had two ideas. The first is to simply expose all these fields
with sock_opt. In that way profiles would be able to define their requirements
also in future without any sock opt changes.
Second is to define BT_LE_LOW_LAT for low latency connection requirements and
BT_LE_LOW_POWER connection where the latency is not an issue. It would make
usage of this sock opt interface simplier. OTOH the only user should be
bluetoothd so it doesn't need to be as simple as possible.
Comments please.
--
Ville
--
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
This message is for the designated recipient only and may contain privileged, proprietary, or otherwise private information. If you have received it in error, please notify the sender immediately and delete the original. Any other use of the email by you is prohibited.
^ permalink raw reply
* Re: [PATCH v3 2/4] Advertising data: extract local name
From: Johan Hedberg @ 2010-11-15 14:07 UTC (permalink / raw)
To: Vinicius Costa Gomes; +Cc: linux-bluetooth, Bruna Moreira
In-Reply-To: <1289518769-3009-2-git-send-email-vinicius.gomes@openbossa.org>
Hi,
On Thu, Nov 11, 2010, Vinicius Costa Gomes wrote:
> @@ -3159,6 +3160,12 @@ void adapter_update_device_from_info(struct btd_adapter *adapter,
>
> adapter->found_devices = g_slist_sort(adapter->found_devices,
> (GCompareFunc) dev_rssi_cmp);
> +
> + if (info->length) {
> + char *tmp_name = bt_extract_eir_name(info->data, &type);
> + if (tmp_name)
> + dev->name = tmp_name;
> + }
> }
This looks like a potential memory leak to me. What if dev->name was
already set (e.g. by a previous event for the same device)?
Johan
^ permalink raw reply
* Re: [PATCH v3 1/4] Initial advertising data parsing implementation
From: Johan Hedberg @ 2010-11-15 14:05 UTC (permalink / raw)
To: Vinicius Costa Gomes; +Cc: linux-bluetooth, Bruna Moreira
In-Reply-To: <1289518769-3009-1-git-send-email-vinicius.gomes@openbossa.org>
Hi,
On Thu, Nov 11, 2010, Vinicius Costa Gomes wrote:
> Implement adapter_update_adv() function to parse advertising data
> received by btd_event_adv() function. Add some fields for advertising
> data in remote_device_info struct.
> ---
> plugins/hciops.c | 9 +++------
> src/adapter.c | 26 ++++++++++++++++++++++++++
> src/adapter.h | 6 ++++++
> src/event.c | 13 +++++++++++++
> src/event.h | 1 +
> 5 files changed, 49 insertions(+), 6 deletions(-)
Pushed upstream. Thanks.
Johan
^ permalink raw reply
* [PATCH] Fix fetching contact photo file name
From: Bartosz Szatkowski @ 2010-11-15 13:33 UTC (permalink / raw)
To: linux-bluetooth; +Cc: Bartosz Szatkowski
Previously photo id was fetched. File name may be further converted to
binary data (actual image) if such behavior would be desired in the future.
---
plugins/phonebook-tracker.c | 60 ++++++++++++++++++++++++++++++++++++++----
1 files changed, 54 insertions(+), 6 deletions(-)
diff --git a/plugins/phonebook-tracker.c b/plugins/phonebook-tracker.c
index 672d59f..962cc4d 100644
--- a/plugins/phonebook-tracker.c
+++ b/plugins/phonebook-tracker.c
@@ -69,7 +69,7 @@
"nco:streetAddress(?p) nco:locality(?p) nco:region(?p) " \
"nco:postalcode(?p) nco:country(?p) ?f nco:emailAddress(?ew) " \
"nco:birthDate(?c) nco:nickname(?c) nco:url(?c) " \
- "nco:photo(?c) nco:fullname(?o) nco:department(?a) " \
+ "?file nco:fullname(?o) nco:department(?a) " \
"nco:role(?a) nco:pobox(?pw) nco:extendedAddress(?pw) " \
"nco:streetAddress(?pw) nco:locality(?pw) nco:region(?pw) " \
"nco:postalcode(?pw) nco:country(?pw) nco:contactUID(?c) " \
@@ -80,6 +80,10 @@
"\"NOTACALL\" \"false\" \"false\" ?c " \
"WHERE { " \
"?c a nco:PersonContact . " \
+ "OPTIONAL { " \
+ "?c a nco:PersonContact ; nco:photo ?pht . " \
+ "?pht a nfo:FileDataObject ; nie:url ?file . " \
+ "} " \
"OPTIONAL { ?c nco:hasPhoneNumber ?h . " \
"OPTIONAL {" \
"?h a nco:FaxNumber ; " \
@@ -135,7 +139,7 @@
"nco:streetAddress(?p) nco:locality(?p) nco:region(?p) " \
"nco:postalcode(?p) nco:country(?p) \"\" nco:emailAddress(?ew) "\
"nco:birthDate(?c) nco:nickname(?c) nco:url(?c) " \
- "nco:photo(?c) nco:fullname(?o) nco:department(?a) " \
+ "?file nco:fullname(?o) nco:department(?a) " \
"nco:role(?a) nco:pobox(?pw) nco:extendedAddress(?pw) " \
"nco:streetAddress(?pw) nco:locality(?pw) nco:region(?pw) " \
"nco:postalcode(?pw) nco:country(?pw) nco:contactUID(?c) " \
@@ -156,6 +160,10 @@
"?c a nco:PersonContact . " \
"?c nco:hasPhoneNumber ?t . " \
"OPTIONAL { " \
+ "?c a nco:PersonContact ; nco:photo ?pht . " \
+ "?pht a nfo:FileDataObject ; nie:url ?file . " \
+ "} " \
+ "OPTIONAL { " \
"?t a nco:CellPhoneNumber ; " \
"nco:phoneNumber ?vc . " \
"} " \
@@ -186,6 +194,10 @@
"?c nco:hasAffiliation ?a . " \
"?a nco:hasPhoneNumber ?tmp . " \
"OPTIONAL { " \
+ "?c a nco:PersonContact ; nco:photo ?pht . " \
+ "?pht a nfo:FileDataObject ; nie:url ?file . " \
+ "} " \
+ "OPTIONAL { " \
"?a rdfs:label \"Work\" . " \
"?tmp nco:phoneNumber ?w . " \
"OPTIONAL { ?a nco:hasEmailAddress ?ew . } " \
@@ -274,7 +286,7 @@
"nco:streetAddress(?p) nco:locality(?p) nco:region(?p) " \
"nco:postalcode(?p) nco:country(?p) \"\" nco:emailAddress(?ew) "\
"nco:birthDate(?c) nco:nickname(?c) nco:url(?c) " \
- "nco:photo(?c) nco:fullname(?o) nco:department(?a) " \
+ "?file nco:fullname(?o) nco:department(?a) " \
"nco:role(?a) nco:pobox(?pw) nco:extendedAddress(?pw) " \
"nco:streetAddress(?pw) nco:locality(?pw) nco:region(?pw) " \
"nco:postalcode(?pw) nco:country(?pw) nco:contactUID(?c) " \
@@ -295,6 +307,10 @@
"?c a nco:PersonContact . " \
"?c nco:hasPhoneNumber ?t . " \
"OPTIONAL { " \
+ "?c a nco:PersonContact ; nco:photo ?pht . " \
+ "?pht a nfo:FileDataObject ; nie:url ?file . " \
+ "} " \
+ "OPTIONAL { " \
"?t a nco:CellPhoneNumber ; " \
"nco:phoneNumber ?vc . " \
"} " \
@@ -325,6 +341,10 @@
"?c nco:hasAffiliation ?a . " \
"?a nco:hasPhoneNumber ?tmp . " \
"OPTIONAL { " \
+ "?c a nco:PersonContact ; nco:photo ?pht . " \
+ "?pht a nfo:FileDataObject ; nie:url ?file . " \
+ "} " \
+ "OPTIONAL { " \
"?a rdfs:label \"Work\" . " \
"?tmp nco:phoneNumber ?w . " \
"OPTIONAL { ?a nco:hasEmailAddress ?ew . } " \
@@ -412,7 +432,7 @@
"nco:streetAddress(?p) nco:locality(?p) nco:region(?p) " \
"nco:postalcode(?p) nco:country(?p) \"\" nco:emailAddress(?ew) "\
"nco:birthDate(?c) nco:nickname(?c) nco:url(?c) " \
- "nco:photo(?c) nco:fullname(?o) nco:department(?a) " \
+ "?file nco:fullname(?o) nco:department(?a) " \
"nco:role(?a) nco:pobox(?pw) nco:extendedAddress(?pw) " \
"nco:streetAddress(?pw) nco:locality(?pw) nco:region(?pw) " \
"nco:postalcode(?pw) nco:country(?pw) nco:contactUID(?c) " \
@@ -432,6 +452,10 @@
"?c a nco:PersonContact . " \
"?c nco:hasPhoneNumber ?t . " \
"OPTIONAL { " \
+ "?c a nco:PersonContact ; nco:photo ?pht . " \
+ "?pht a nfo:FileDataObject ; nie:url ?file . " \
+ "} " \
+ "OPTIONAL { " \
"?t a nco:CellPhoneNumber ; " \
"nco:phoneNumber ?vc . " \
"} " \
@@ -461,6 +485,10 @@
"?c nco:hasAffiliation ?a . " \
"?a nco:hasPhoneNumber ?tmp . " \
"OPTIONAL { " \
+ "?c a nco:PersonContact ; nco:photo ?pht . " \
+ "?pht a nfo:FileDataObject ; nie:url ?file . " \
+ "} " \
+ "OPTIONAL { " \
"?a rdfs:label \"Work\" . " \
"?tmp nco:phoneNumber ?w . " \
"OPTIONAL { ?a nco:hasEmailAddress ?ew . } " \
@@ -544,7 +572,7 @@
"nco:streetAddress(?p) nco:locality(?p) nco:region(?p) " \
"nco:postalcode(?p) nco:country(?p) \"\" nco:emailAddress(?ew) "\
"nco:birthDate(?c) nco:nickname(?c) nco:url(?c) " \
- "nco:photo(?c) nco:fullname(?o) nco:department(?a) " \
+ "?file nco:fullname(?o) nco:department(?a) " \
"nco:role(?a) nco:pobox(?pw) nco:extendedAddress(?pw) " \
"nco:streetAddress(?pw) nco:locality(?pw) nco:region(?pw) " \
"nco:postalcode(?pw) nco:country(?pw) nco:contactUID(?c) " \
@@ -564,6 +592,10 @@
"?c a nco:PersonContact . " \
"?c nco:hasPhoneNumber ?t . " \
"OPTIONAL { " \
+ "?c a nco:PersonContact ; nco:photo ?pht . " \
+ "?pht a nfo:FileDataObject ; nie:url ?file . " \
+ "} " \
+ "OPTIONAL { " \
"?t a nco:CellPhoneNumber ; " \
"nco:phoneNumber ?vc . " \
"} " \
@@ -593,6 +625,10 @@
"?c nco:hasAffiliation ?a . " \
"?a nco:hasPhoneNumber ?tmp . " \
"OPTIONAL { " \
+ "?c a nco:PersonContact ; nco:photo ?pht . " \
+ "?pht a nfo:FileDataObject ; nie:url ?file . " \
+ "} " \
+ "OPTIONAL { " \
"?a rdfs:label \"Work\" . " \
"?tmp nco:phoneNumber ?w . " \
"OPTIONAL { ?a nco:hasEmailAddress ?ew . } " \
@@ -641,6 +677,10 @@
"?c a nco:PersonContact . " \
"?c nco:hasPhoneNumber ?t . " \
"OPTIONAL { " \
+ "?c a nco:PersonContact ; nco:photo ?pht . " \
+ "?pht a nfo:FileDataObject ; nie:url ?file . " \
+ "} " \
+ "OPTIONAL { " \
"?t a nco:CellPhoneNumber ; " \
"nco:phoneNumber ?vc . " \
"} " \
@@ -670,6 +710,10 @@
"?c nco:hasAffiliation ?a . " \
"?a nco:hasPhoneNumber ?tmp . " \
"OPTIONAL { " \
+ "?c a nco:PersonContact ; nco:photo ?pht . " \
+ "?pht a nfo:FileDataObject ; nie:url ?file . " \
+ "} " \
+ "OPTIONAL { " \
"?a rdfs:label \"Work\" . " \
"?tmp nco:phoneNumber ?w . " \
"OPTIONAL { ?a nco:hasEmailAddress ?ew . } " \
@@ -775,7 +819,7 @@
"nco:streetAddress(?p) nco:locality(?p) nco:region(?p) " \
"nco:postalcode(?p) nco:country(?p) ?f nco:emailAddress(?ew) " \
"nco:birthDate(<%s>) nco:nickname(<%s>) nco:url(<%s>) " \
- "nco:photo(<%s>) nco:fullname(?o) nco:department(?a) " \
+ "?file nco:fullname(?o) nco:department(?a) " \
"nco:role(?a) nco:pobox(?pw) nco:extendedAddress(?pw) " \
"nco:streetAddress(?pw) nco:locality(?pw) nco:region(?pw) " \
"nco:postalcode(?pw) nco:country(?pw) nco:contactUID(<%s>) " \
@@ -786,6 +830,10 @@
"\"NOTACALL\" \"false\" \"false\" <%s> " \
"WHERE { " \
"<%s> a nco:PersonContact . " \
+ "OPTIONAL { " \
+ "<%s> a nco:PersonContact ; nco:photo ?pht . " \
+ "?pht a nfo:FileDataObject ; nie:url ?file . " \
+ "} " \
"OPTIONAL { <%s> nco:hasPhoneNumber ?h . " \
"OPTIONAL {" \
"?h a nco:FaxNumber ; " \
--
1.7.0.4
^ permalink raw reply related
* [RFC] Interface to set LE connection parameters
From: Ville Tervo @ 2010-11-15 12:06 UTC (permalink / raw)
To: linux-bluetooth
Hi,
LE profiles have different requirements for connection parameters. Mainly
trying to balance between power consumption and latencies. Probably more will
factors will be in future.
Currently I have plan to introduce new l2cap socket option which can be used
before connection creation to set inital settings and also change settings
while having a connection.
Since there is no equivalents in EDR/BR connection I'm planning to make then
apply only LE connection.
Other question which parameters should be exposed to user space? Connection
creation and connection update have these common parameters. Connection
creation has in addition some other parameters also but they should be handled
in some other way.
__le16 conn_interval_min;
__le16 conn_interval_max;
__le16 conn_latency;
__le16 supervision_timeout;
__le16 min_ce_len;
__le16 max_ce_len;
So far I have had two ideas. The first is to simply expose all these fields
with sock_opt. In that way profiles would be able to define their requirements
also in future without any sock opt changes.
Second is to define BT_LE_LOW_LAT for low latency connection requirements and
BT_LE_LOW_POWER connection where the latency is not an issue. It would make
usage of this sock opt interface simplier. OTOH the only user should be
bluetoothd so it doesn't need to be as simple as possible.
Comments please.
--
Ville
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox