* pull request: bluetooth-2.6 2010-11-01
From: Gustavo F. Padovan @ 2010-12-01 21:11 UTC (permalink / raw)
To: linville; +Cc: marcel, linux-wireless, linux-bluetooth
Hi John,
Here goes 3 simple patches intended to 2.6.37. First one is from myself
and fix some trivial return values. Then we also have a fix from Stefan
Seyfried on btusb to avoid emitting an err when we USB is autosupended.
Last, a patch from Bala Shanmugam that fix the firmware loading process
for the ath3k driver.
Please pull, or let me know if you disagree with the patches. Thanks a
lot. ;)
The following changes since commit 916448e77f6bcaaa7f13c3de0c3851783ae2bfd0:
ath9k: Fix STA disconnect issue due to received MIC failed bcast frames (2010-11-30 13:45:02 -0500)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/padovan/bluetooth-2.6.git master
Bala Shanmugam (1):
Bluetooth: Add new PID for Atheros 3011
Gustavo F. Padovan (1):
Bluetooth: Fix not returning proper error in SCO
Stefan Seyfried (1):
Bluetooth: Fix log spamming in btusb due to autosuspend
drivers/bluetooth/ath3k.c | 4 ++++
drivers/bluetooth/btusb.c | 12 +++++++++---
net/bluetooth/sco.c | 6 +++---
3 files changed, 16 insertions(+), 6 deletions(-)
--
Gustavo F. Padovan
http://profusion.mobi
^ permalink raw reply
* Re: [RFC 1/4] Bluetooth: clean up sco code
From: Gustavo F. Padovan @ 2010-12-01 21:16 UTC (permalink / raw)
To: Andrei Emeltchenko; +Cc: Anderson Lizardo, linux-bluetooth
In-Reply-To: <AANLkTikfeMqq-4fTRHwmL81TDnF2=sQsMhL9o7GoEcX2@mail.gmail.com>
Hi Andrei,
* Andrei Emeltchenko <andrei.emeltchenko.news@gmail.com> [2010-12-01 15:44:50 +0200]:
> Hi,
>
> On Fri, Nov 26, 2010 at 6:14 PM, Anderson Lizardo
> <anderson.lizardo@openbossa.org> wrote:
> > Hi Andrei,
> >
> > On Fri, Nov 26, 2010 at 11:22 AM, Emeltchenko Andrei
> > <Andrei.Emeltchenko.news@gmail.com> wrote:
> >> @@ -828,13 +831,14 @@ static void sco_chan_del(struct sock *sk, int err)
> >>
> >> static void sco_conn_ready(struct sco_conn *conn)
> >> {
> >> - struct sock *parent, *sk;
> >> + struct sock *parent;
> >> + struct sock *sk = conn->sk;
> >
> > I wonder if there is a problem with accessing conn->sk here outside
> > the lock protection?
>
> I believe here is a safe access. We just acquire pointer and possible
> protected operations
> are executed inside lock.
Agreed.
--
Gustavo F. Padovan
http://profusion.mobi
^ permalink raw reply
* Re: [PATCHv2 1/5] Bluetooth: clean up sco code
From: Gustavo F. Padovan @ 2010-12-01 21:20 UTC (permalink / raw)
To: Emeltchenko Andrei; +Cc: linux-bluetooth
In-Reply-To: <1291215506-11398-2-git-send-email-Andrei.Emeltchenko.news@gmail.com>
Hi Andrei,
* Emeltchenko Andrei <Andrei.Emeltchenko.news@gmail.com> [2010-12-01 16:58:22 +0200]:
> From: Andrei Emeltchenko <andrei.emeltchenko@nokia.com>
>
> Do not use assignments in IF condition, remove extra spaces
>
> Signed-off-by: Andrei Emeltchenko <andrei.emeltchenko@nokia.com>
> ---
> include/net/bluetooth/sco.h | 8 ++++----
> net/bluetooth/sco.c | 22 +++++++++++++---------
> 2 files changed, 17 insertions(+), 13 deletions(-)
>
> diff --git a/include/net/bluetooth/sco.h b/include/net/bluetooth/sco.h
> index e28a2a7..ea5c664 100644
> --- a/include/net/bluetooth/sco.h
> +++ b/include/net/bluetooth/sco.h
> @@ -55,11 +55,11 @@ struct sco_conninfo {
> struct sco_conn {
> struct hci_conn *hcon;
>
> - bdaddr_t *dst;
> - bdaddr_t *src;
> -
> + bdaddr_t *dst;
> + bdaddr_t *src;
> +
> spinlock_t lock;
> - struct sock *sk;
> + struct sock *sk;
>
> unsigned int mtu;
> };
> diff --git a/net/bluetooth/sco.c b/net/bluetooth/sco.c
> index 66b9e5c..960c6d1 100644
> --- a/net/bluetooth/sco.c
> +++ b/net/bluetooth/sco.c
> @@ -44,7 +44,7 @@
> #include <net/sock.h>
>
> #include <asm/system.h>
> -#include <asm/uaccess.h>
> +#include <linux/uaccess.h>
>
> #include <net/bluetooth/bluetooth.h>
> #include <net/bluetooth/hci_core.h>
> @@ -52,7 +52,7 @@
>
> #define VERSION "0.6"
>
> -static int disable_esco = 0;
> +static int disable_esco;
I don't think this change is right. Can we be sure that disable_esco
will be 0 by default?
>
> static const struct proto_ops sco_sock_ops;
>
> @@ -138,16 +138,17 @@ static inline struct sock *sco_chan_get(struct sco_conn *conn)
>
> static int sco_conn_del(struct hci_conn *hcon, int err)
> {
> - struct sco_conn *conn;
> + struct sco_conn *conn = hcon->sco_data;
> struct sock *sk;
>
> - if (!(conn = hcon->sco_data))
> + if (!conn)
> return 0;
>
> BT_DBG("hcon %p conn %p, err %d", hcon, conn, err);
>
> /* Kill socket */
> - if ((sk = sco_chan_get(conn))) {
> + sk = sco_chan_get(conn);
> + if (sk) {
> bh_lock_sock(sk);
> sco_sock_clear_timer(sk);
> sco_chan_del(sk, err);
> @@ -185,7 +186,8 @@ static int sco_connect(struct sock *sk)
>
> BT_DBG("%s -> %s", batostr(src), batostr(dst));
>
> - if (!(hdev = hci_get_route(dst, src)))
> + hdev = hci_get_route(dst, src);
> + if (!hdev)
> return -EHOSTUNREACH;
>
> hci_dev_lock_bh(hdev);
> @@ -510,7 +512,8 @@ static int sco_sock_connect(struct socket *sock, struct sockaddr *addr, int alen
> /* Set destination address and psm */
> bacpy(&bt_sk(sk)->dst, &sa->sco_bdaddr);
>
> - if ((err = sco_connect(sk)))
> + err = sco_connect(sk);
> + if (err)
> goto done;
>
> err = bt_sock_wait_state(sk, BT_CONNECTED,
> @@ -828,13 +831,14 @@ static void sco_chan_del(struct sock *sk, int err)
>
> static void sco_conn_ready(struct sco_conn *conn)
> {
> - struct sock *parent, *sk;
> + struct sock *parent;
> + struct sock *sk = conn->sk;
>
> BT_DBG("conn %p", conn);
>
> sco_conn_lock(conn);
>
> - if ((sk = conn->sk)) {
> + if (sk) {
> sco_sock_clear_timer(sk);
> bh_lock_sock(sk);
> sk->sk_state = BT_CONNECTED;
Otherwise looks good.
--
Gustavo F. Padovan
http://profusion.mobi
^ permalink raw reply
* Re: [PATCHv2 3/5] Bluetooth: clean up l2cap code
From: Gustavo F. Padovan @ 2010-12-01 21:21 UTC (permalink / raw)
To: Emeltchenko Andrei; +Cc: linux-bluetooth
In-Reply-To: <1291215506-11398-4-git-send-email-Andrei.Emeltchenko.news@gmail.com>
* Emeltchenko Andrei <Andrei.Emeltchenko.news@gmail.com> [2010-12-01 16:58:24 +0200]:
> From: Andrei Emeltchenko <andrei.emeltchenko@nokia.com>
>
> Do not initialize static vars to zero, macros with complex values
> shall be enclosed with (), remove unneeded braces.
>
> Signed-off-by: Andrei Emeltchenko <andrei.emeltchenko@nokia.com>
> ---
> include/net/bluetooth/l2cap.h | 10 +++++-----
> net/bluetooth/l2cap.c | 7 +++----
> 2 files changed, 8 insertions(+), 9 deletions(-)
>
> diff --git a/include/net/bluetooth/l2cap.h b/include/net/bluetooth/l2cap.h
> index c819c8b..217bb91 100644
> --- a/include/net/bluetooth/l2cap.h
> +++ b/include/net/bluetooth/l2cap.h
> @@ -417,11 +417,11 @@ static inline int l2cap_tx_window_full(struct sock *sk)
> return sub == pi->remote_tx_win;
> }
>
> -#define __get_txseq(ctrl) ((ctrl) & L2CAP_CTRL_TXSEQ) >> 1
> -#define __get_reqseq(ctrl) ((ctrl) & L2CAP_CTRL_REQSEQ) >> 8
> -#define __is_iframe(ctrl) !((ctrl) & L2CAP_CTRL_FRAME_TYPE)
> -#define __is_sframe(ctrl) (ctrl) & L2CAP_CTRL_FRAME_TYPE
> -#define __is_sar_start(ctrl) ((ctrl) & L2CAP_CTRL_SAR) == L2CAP_SDU_START
> +#define __get_txseq(ctrl) (((ctrl) & L2CAP_CTRL_TXSEQ) >> 1)
> +#define __get_reqseq(ctrl) (((ctrl) & L2CAP_CTRL_REQSEQ) >> 8)
> +#define __is_iframe(ctrl) (!((ctrl) & L2CAP_CTRL_FRAME_TYPE))
> +#define __is_sframe(ctrl) ((ctrl) & L2CAP_CTRL_FRAME_TYPE)
> +#define __is_sar_start(ctrl) (((ctrl) & L2CAP_CTRL_SAR) == L2CAP_SDU_START)
>
> void l2cap_load(void);
>
> diff --git a/net/bluetooth/l2cap.c b/net/bluetooth/l2cap.c
> index 12b4aa2..d4b4fbd 100644
> --- a/net/bluetooth/l2cap.c
> +++ b/net/bluetooth/l2cap.c
> @@ -57,7 +57,7 @@
>
> #define VERSION "2.15"
>
> -static int disable_ertm = 0;
> +static int disable_ertm;
Same issue here.
--
Gustavo F. Padovan
http://profusion.mobi
^ permalink raw reply
* Re: [PATCHv2 1/5] Bluetooth: clean up sco code
From: Anderson Lizardo @ 2010-12-01 21:31 UTC (permalink / raw)
To: Gustavo F. Padovan; +Cc: Emeltchenko Andrei, linux-bluetooth
In-Reply-To: <20101201212034.GE16125@vigoh>
On Wed, Dec 1, 2010 at 5:20 PM, Gustavo F. Padovan
<padovan@profusion.mobi> wrote:
>> -static int disable_esco = 0;
>> +static int disable_esco;
>
> I don't think this change is right. Can we be sure that disable_esco
> will be 0 by default?
I think Andrei's patch is ok. IIRC kernel zeroes BSS on init, that's
why checkpatch.pl complains when you initialize it explicitely.
Regards,
--
Anderson Lizardo
OpenBossa Labs - INdT
Manaus - Brazil
^ permalink raw reply
* Re: [PATCHv2 5/5] Bluetooth: clean up legal text
From: Gustavo F. Padovan @ 2010-12-01 21:42 UTC (permalink / raw)
To: Emeltchenko Andrei; +Cc: linux-bluetooth
In-Reply-To: <1291215506-11398-6-git-send-email-Andrei.Emeltchenko.news@gmail.com>
Hi Andrei,
* Emeltchenko Andrei <Andrei.Emeltchenko.news@gmail.com> [2010-12-01 16:58:26 +0200]:
> From: Andrei Emeltchenko <andrei.emeltchenko@nokia.com>
>
> Remove extra spaces from legal text so that legal stuff looks
> the same for all bluetooth code.
>
> Signed-off-by: Andrei Emeltchenko <andrei.emeltchenko@nokia.com>
> ---
> include/net/bluetooth/hci.h | 12 ++++++------
> include/net/bluetooth/l2cap.h | 12 ++++++------
> include/net/bluetooth/rfcomm.h | 14 +++++++-------
> include/net/bluetooth/sco.h | 12 ++++++------
> 4 files changed, 25 insertions(+), 25 deletions(-)
This one is applied. Thanks.
--
Gustavo F. Padovan
http://profusion.mobi
^ permalink raw reply
* Re: [PATCHv2 1/5] Bluetooth: clean up sco code
From: Gustavo F. Padovan @ 2010-12-01 21:44 UTC (permalink / raw)
To: Anderson Lizardo; +Cc: Emeltchenko Andrei, linux-bluetooth
In-Reply-To: <AANLkTi==oXHyrtkjRD_mbmRFsDnTH7+S_JOFHRemXJLG@mail.gmail.com>
Hi Anderson,
* Anderson Lizardo <anderson.lizardo@openbossa.org> [2010-12-01 17:31:15 -0400]:
> On Wed, Dec 1, 2010 at 5:20 PM, Gustavo F. Padovan
> <padovan@profusion.mobi> wrote:
> >> -static int disable_esco = 0;
> >> +static int disable_esco;
> >
> > I don't think this change is right. Can we be sure that disable_esco
> > will be 0 by default?
>
> I think Andrei's patch is ok. IIRC kernel zeroes BSS on init, that's
> why checkpatch.pl complains when you initialize it explicitely.
Great, I didn't know about that. Applied then. Thanks all!
--
Gustavo F. Padovan
http://profusion.mobi
^ permalink raw reply
* Re: [PATCHv2 2/5] Bluetooth: clean up rfcomm code
From: Gustavo F. Padovan @ 2010-12-01 21:52 UTC (permalink / raw)
To: Emeltchenko Andrei; +Cc: linux-bluetooth
In-Reply-To: <1291215506-11398-3-git-send-email-Andrei.Emeltchenko.news@gmail.com>
Hi Andrei,
* Emeltchenko Andrei <Andrei.Emeltchenko.news@gmail.com> [2010-12-01 16:58:23 +0200]:
> From: Andrei Emeltchenko <andrei.emeltchenko@nokia.com>
>
> Remove extra spaces, assignments in if statement, zeroing static
> variables, extra braces. Fix includes.
>
> Signed-off-by: Andrei Emeltchenko <andrei.emeltchenko@nokia.com>
> ---
> include/net/bluetooth/rfcomm.h | 4 ++--
> net/bluetooth/rfcomm/core.c | 8 ++++----
> net/bluetooth/rfcomm/sock.c | 5 +++--
> net/bluetooth/rfcomm/tty.c | 28 ++++++++++++++++------------
> 4 files changed, 25 insertions(+), 20 deletions(-)
Applied, thanks for clean up this.
--
Gustavo F. Padovan
http://profusion.mobi
^ permalink raw reply
* Re: [PATCHv2 3/5] Bluetooth: clean up l2cap code
From: Gustavo F. Padovan @ 2010-12-01 21:53 UTC (permalink / raw)
To: Emeltchenko Andrei; +Cc: linux-bluetooth
In-Reply-To: <1291215506-11398-4-git-send-email-Andrei.Emeltchenko.news@gmail.com>
Hi Andrei,
* Emeltchenko Andrei <Andrei.Emeltchenko.news@gmail.com> [2010-12-01 16:58:24 +0200]:
> From: Andrei Emeltchenko <andrei.emeltchenko@nokia.com>
>
> Do not initialize static vars to zero, macros with complex values
> shall be enclosed with (), remove unneeded braces.
>
> Signed-off-by: Andrei Emeltchenko <andrei.emeltchenko@nokia.com>
> ---
> include/net/bluetooth/l2cap.h | 10 +++++-----
> net/bluetooth/l2cap.c | 7 +++----
> 2 files changed, 8 insertions(+), 9 deletions(-)
Applied, thanks for clean up this.
--
Gustavo F. Padovan
http://profusion.mobi
^ permalink raw reply
* Re: [PATCHv2 4/5] Bluetooth: clean up hci code
From: Gustavo F. Padovan @ 2010-12-01 21:53 UTC (permalink / raw)
To: Emeltchenko Andrei; +Cc: linux-bluetooth
In-Reply-To: <1291215506-11398-5-git-send-email-Andrei.Emeltchenko.news@gmail.com>
Hi Andrei,
* Emeltchenko Andrei <Andrei.Emeltchenko.news@gmail.com> [2010-12-01 16:58:25 +0200]:
> From: Andrei Emeltchenko <andrei.emeltchenko@nokia.com>
>
> Do not use assignment in IF condition, remove extra spaces,
> fixing typos, simplify code.
>
> Signed-off-by: Andrei Emeltchenko <andrei.emeltchenko@nokia.com>
> ---
> include/net/bluetooth/hci.h | 4 +-
> include/net/bluetooth/hci_core.h | 14 ++++----
> net/bluetooth/hci_conn.c | 23 ++++++++----
> net/bluetooth/hci_core.c | 66 ++++++++++++++++++++++++--------------
> net/bluetooth/hci_event.c | 8 +++--
> net/bluetooth/hci_sock.c | 17 ++++++---
> 6 files changed, 82 insertions(+), 50 deletions(-)
Applied.
--
Gustavo F. Padovan
http://profusion.mobi
^ permalink raw reply
* pull request: bluetooth-next-2.6 2010-11-01
From: Gustavo F. Padovan @ 2010-12-02 0:32 UTC (permalink / raw)
To: linville; +Cc: linux-wireless, linux-bluetooth
Hi John,
Here are the first batch for 2.6.38, biggest change here is the move of
the Remote Name Request to the kernel to fix some synchronization
problems with other commands sent during the connection setup in
Bluetooth. The rest is just bug fixes and clean ups in the whole stack,
no big feature this time.
This pull request includes the patches that I sent in the pull request
to 2.6.37, but you should expect no problem when merging everything in
wireless-next-2.6.
Please pull or let me know anything wrong. Thanks.
The following changes since commit 61790c5f3c5f158821821a00797d94504531839f:
iwlagn: fix microcode error on 4965 (2010-11-30 13:58:18 -0500)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/padovan/bluetooth-next-2.6.git master
Anderson Lizardo (1):
Bluetooth: Fix error handling for l2cap_init()
Andrei Emeltchenko (8):
Bluetooth: Check sk is not owned before freeing l2cap_conn
Bluetooth: timer check sk is not owned before freeing
Bluetooth: do not use assignment in if condition
Bluetooth: clean up sco code
Bluetooth: clean up rfcomm code
Bluetooth: clean up l2cap code
Bluetooth: clean up hci code
Bluetooth: clean up legal text
Bala Shanmugam (1):
Bluetooth: Add new PID for Atheros 3011
Gustavo F. Padovan (4):
Bluetooth: Fix not returning proper error in SCO
Merge git://git.kernel.org/.../padovan/bluetooth-2.6 into test
Bluetooth: Get rid of __l2cap_get_sock_by_psm()
Bluetooth: Get rid of __rfcomm_get_sock_by_channel()
Johan Hedberg (3):
Bluetooth: Simplify remote features callback function logic
Bluetooth: Create a unified authentication request function
Bluetooth: Automate remote name requests
Stefan Seyfried (1):
Bluetooth: Fix log spamming in btusb due to autosuspend
Vasiliy Kulikov (3):
Bluetooth: bnep: fix information leak to userland
Bluetooth: cmtp: fix information leak to userland
Bluetooth: hidp: fix information leak to userland
drivers/bluetooth/ath3k.c | 4 +
drivers/bluetooth/btusb.c | 12 ++-
include/net/bluetooth/hci.h | 16 ++--
include/net/bluetooth/hci_core.h | 14 ++--
include/net/bluetooth/l2cap.h | 22 +++---
include/net/bluetooth/rfcomm.h | 18 ++--
include/net/bluetooth/sco.h | 20 ++--
net/bluetooth/bnep/core.c | 1 +
net/bluetooth/cmtp/core.c | 1 +
net/bluetooth/hci_conn.c | 23 +++--
net/bluetooth/hci_core.c | 66 +++++++++-----
net/bluetooth/hci_event.c | 177 +++++++++++++++++++++++++++-----------
net/bluetooth/hci_sock.c | 17 +++--
net/bluetooth/hidp/core.c | 2 +-
net/bluetooth/l2cap.c | 94 ++++++++++++++-------
net/bluetooth/rfcomm/core.c | 8 +-
net/bluetooth/rfcomm/sock.c | 24 ++---
net/bluetooth/rfcomm/tty.c | 28 ++++---
net/bluetooth/sco.c | 28 ++++---
19 files changed, 363 insertions(+), 212 deletions(-)
--
Gustavo F. Padovan
http://profusion.mobi
^ permalink raw reply
* Re: [PATCH v7] Bluetooth: btwilink driver
From: Pavan Savoy @ 2010-12-02 0:48 UTC (permalink / raw)
To: Gustavo F. Padovan; +Cc: marcel, linux-bluetooth, linux-kernel
In-Reply-To: <AANLkTiktDkjFH=aGbu3f+mkVUgmFDwB6xLW3e1VNXKtz@mail.gmail.com>
Gustavo,
On Tue, Nov 30, 2010 at 9:30 PM, Pavan Savoy <pavan_savoy@ti.com> wrote:
>>> Marcel, Gustavo,
>>> comments attended to from v5 and v6,
There was 1 solution which was proposed for this,
See in tty_receive/st_int_recv() - we pretty much want only the
packet_id, header length and
the offset of the payload in the header structure.
this is to pack together the data coming in single frame or sets of
multiple frames...
so if bt driver can do something like,
st_register(acl_proto) -> where ACL_PKT=3D0x2, acl_hdr.len and
acl_hdr.payload_offset is sent to ST
st_register(sco_proto) -> where SCO_PKT=3D0x3, sco_hdr.len and
sco_hdr.payload_offset is sent to ST
st_register(evt_proto) -> where EVT_PKT=3D0x2, sco_hdr.len and
evt_hdr.payload_offset is sent to ST
and all 3 map to same st_recv() functions from ST, then
the ST driver as you suggested can be generic enough not to include
any net/bluetooth/ stuff,
and also can be ignorant about any bluetooth, fm or gps stuff in general...
So please suggest if this seems a valid solution, we had previously
declined it because it made bt_driver
sort of register to ST 3 times instead of 1 time like now....
Thanks,
Pavan
>>> 1. Inside ti_st_open, I previously only checked for EINPROGRESS & EPERM=
,
>>> Now I handle for EINPROGRESS - which is not really an error and
>>> return during all other error cases.
>>>
>>> 2. _write is still a function pointer and not an exported function, I
>>> need to change the underlying driver's code for this.
>>> However, previous lkml comments on the underlying driver's code
>>> suggested it to be kept as a function pointer and not EXPORT.
>>> Gustavo, Marcel - Please comment on this.
>>> Is this absolutely required? If so why?
>>>
>>> 3. test_and_set_bit of HCI_RUNNING is done at beginning of
>>> ti_st_open, and did not see issues during firmware download.
>>> However ideally I would still like to set HCI_RUNNING once the firmware
>>> download is done, because I don't want to allow a _send_frame during
>>> firmware download - Marcel, Gustavo - Please comment.
>>>
>>> 4. test_and_clear of HCI_RUNNING now done @ beginning of close.
>>>
>>> 5. EAGAIN on failure of st_write is to suggest to try and write again.
>>> I have never this happen - However only if UART goes bad this case may
>>> occur.
>>>
>>> 6. ti_st_tx_complete is very similar to hci_ldisc's tx_complete - in
>>> fact the code is pretty much borrowed from there.
>>> Marcel, Gustavo - Please suggest where should it be done? If not here.
>>>
>>> 7. comments cleaned-up + hst memory leak fixed when hci_alloc_dev fails=
.
>>>
>>> 8. platform_driver registration inside module_init now is similar to
>>> other drivers.
>>>
>>> 9. Dan Carpenter's comments on leaking hst memory on failed
>>> hci_register_dev and empty space after quotes in debug statements
>>> fixed.
>>>
>>> Thanks for the comments...
>>> Sorry, for previously not being very clear on which comments were
>>> handled and which were not.
>>>
>>> -- 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=A0363 ++++++++++++++++++++++++=
++++++++++++++++++
>>> =C2=A03 files changed, 374 insertions(+), 0 deletions(-)
>>> =C2=A0create mode 100644 drivers/bluetooth/btwilink.c
>>
>> So as part of reviewing this I took a look at your underlying driver and
>> I didn't like what I saw there, you are handling Bluetooth stuff inside
>> the core driver and that is just wrong. You have a Bluetooth driver here
>> then you have to leave the Bluetooth data handling to the Bluetooth
>> driver and do not do that in the core.
>
> Thanks for reviewing this and the underlying driver.
> yes, we do have Bluetooth/FM/GPS handling inside the TI ST driver, on
> addition of further technologies
> we do plan to have them inside the ST driver too.
>
> The understanding of BT or FM or GPS is required for the ST driver
> because, the data coming from the chip
> can either be of these technologies, further-more the data might not
> come in a set.
> As in, an a2dp/ftp ACL frame might come in 2 frames instead of 1, and
> in other cases,
> there might be a HCI-EVENT + FM CH8 data in a single frame received by th=
e UART.
>
>> So I'm going to clear NACK this. Your TI ST driver architecture is
>> a mess, Ideally you should not have any #include <net/bluetoooth/...>
>> there. Implement a core driver that only gets the Shared Transport
>> data and pass it to the right driver without look into the data and
>> process it. Process the data is not the role of the core driver.
>
> So as I see it the tty_receive which translates to st_int_recv() in
> TI-ST is the area of concern for
> you ...
> So any suggestions as to how we can go about just abstracting the BT,
> FM and GPS data part to their individual drivers?
>
>> Please fix this and come back when you have a proper solution for your
>> driver.
>>
>> --
>> Gustavo F. Padovan
>> http://profusion.mobi
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-bluetoot=
h" 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: [PATCHv2 1/5] Bluetooth: clean up sco code
From: Johan Hedberg @ 2010-12-02 7:12 UTC (permalink / raw)
To: Gustavo F. Padovan; +Cc: Emeltchenko Andrei, linux-bluetooth
In-Reply-To: <20101201212034.GE16125@vigoh>
Hi Gustavo,
On Wed, Dec 01, 2010, Gustavo F. Padovan wrote:
> > -static int disable_esco = 0;
> > +static int disable_esco;
>
> I don't think this change is right. Can we be sure that disable_esco
> will be 0 by default?
AFAIK we can since static variables are initialized to 0 by default.
However, I've understood that it's good style to have this
initialization explicit in the code so imho the code should be left as
it is.
Johan
^ permalink raw reply
* Re: [PATCHv2 1/5] Bluetooth: clean up sco code
From: Johan Hedberg @ 2010-12-02 7:14 UTC (permalink / raw)
To: Anderson Lizardo; +Cc: Gustavo F. Padovan, Emeltchenko Andrei, linux-bluetooth
In-Reply-To: <AANLkTi==oXHyrtkjRD_mbmRFsDnTH7+S_JOFHRemXJLG@mail.gmail.com>
Hi Anderson,
On Wed, Dec 01, 2010, Anderson Lizardo wrote:
> On Wed, Dec 1, 2010 at 5:20 PM, Gustavo F. Padovan
> <padovan@profusion.mobi> wrote:
> >> -static int disable_esco = 0;
> >> +static int disable_esco;
> >
> > I don't think this change is right. Can we be sure that disable_esco
> > will be 0 by default?
>
> I think Andrei's patch is ok. IIRC kernel zeroes BSS on init, that's
> why checkpatch.pl complains when you initialize it explicitely.
That's interesting. It'd be nice to have some comment from Marcel on
this since at least on the user space side it's considered a good thing
to explicitly initialize static variables to zero.
Johan
^ permalink raw reply
* Re: [PATCHv2 1/5] Bluetooth: clean up sco code
From: Marcel Holtmann @ 2010-12-02 7:49 UTC (permalink / raw)
To: Johan Hedberg; +Cc: Gustavo F. Padovan, Emeltchenko Andrei, linux-bluetooth
In-Reply-To: <20101202071224.GA15525@jh-x301>
Hi Johan,
> > > -static int disable_esco = 0;
> > > +static int disable_esco;
> >
> > I don't think this change is right. Can we be sure that disable_esco
> > will be 0 by default?
>
> AFAIK we can since static variables are initialized to 0 by default.
> However, I've understood that it's good style to have this
> initialization explicit in the code so imho the code should be left as
> it is.
personally I prefer to initialize the variables to an initial value to
make it clear what their default is.
That said, this comes with a cost in case of a 0 or NULL initialization
since the compiler has to store extra code to do so. Not doing an
explicit initialization saves code size in this case.
The general kernel recommendation is to not initialize and I am fine
with following that one.
Regards
Marcel
^ permalink raw reply
* [PATCH] Fix deinitializing telephony backend when it wasn't initialized
From: Luiz Augusto von Dentz @ 2010-12-02 8:46 UTC (permalink / raw)
To: linux-bluetooth
From: Luiz Augusto von Dentz <luiz.dentz-von@nokia.com>
Telephony driver is now deinitialized on headset adapter driver remove so
telephony_exit should not be called on plugin exit anymore.
---
audio/manager.c | 4 +---
1 files changed, 1 insertions(+), 3 deletions(-)
diff --git a/audio/manager.c b/audio/manager.c
index 12671c7..035656b 100644
--- a/audio/manager.c
+++ b/audio/manager.c
@@ -1264,10 +1264,8 @@ void audio_manager_exit(void)
if (enabled.media)
btd_unregister_adapter_driver(&media_server_driver);
- if (enabled.headset) {
+ if (enabled.headset)
btd_unregister_adapter_driver(&headset_server_driver);
- telephony_exit();
- }
if (enabled.gateway)
btd_unregister_adapter_driver(&gateway_server_driver);
--
1.7.1
^ permalink raw reply related
* Re: [PATCH] Fix deinitializing telephony backend when it wasn't initialized
From: Johan Hedberg @ 2010-12-02 9:04 UTC (permalink / raw)
To: Luiz Augusto von Dentz; +Cc: linux-bluetooth
In-Reply-To: <1291279564-16615-1-git-send-email-luiz.dentz@gmail.com>
Hi Luiz,
On Thu, Dec 02, 2010, Luiz Augusto von Dentz wrote:
> From: Luiz Augusto von Dentz <luiz.dentz-von@nokia.com>
>
> Telephony driver is now deinitialized on headset adapter driver remove so
> telephony_exit should not be called on plugin exit anymore.
> ---
> audio/manager.c | 4 +---
> 1 files changed, 1 insertions(+), 3 deletions(-)
Pushed upstream. Thanks.
Johan
^ permalink raw reply
* Re: [PATCH 1/3] Initial attribute permission implementation
From: Johan Hedberg @ 2010-12-02 10:10 UTC (permalink / raw)
To: Anderson Lizardo; +Cc: linux-bluetooth, Bruna Moreira
In-Reply-To: <1291219986-29913-2-git-send-email-anderson.lizardo@openbossa.org>
Hi,
On Wed, Dec 01, 2010, Anderson Lizardo wrote:
> + attrib_db_add(0x0685, &uuid, ATT_ACCESS(ATT_READ, ATT_NONE), atval,
> + len);
<snip>
> +/* Access permissions */
> +#define ATT_READ 1
> +#define ATT_WRITE 2
> +/* Authentication/Authorization permissions */
> +#define ATT_NONE 0
> +#define ATT_AUTHENTICATION 2
> +#define ATT_AUTHORIZATION 4
> +/* Build bit mask for permission checks */
> +#define ATT_ACCESS(x, y) (((x) << y) | (x))
The last macro doesn't make any sense to me. Based the core spec it
seems that the values for the different permission types are
implementation specific and not exposed publicly (vol 2, part G, 2.5.1:
"Attribute Permissions is part of the Attribute that cannot be read from
or written to using the Attribute Protocol"). Why not make sure that
they are all orthogonal from the start instead of ssigning the same
value for authentication and writability like you do now. I.e. instead
you could have:
none 0
read 1
write 2
authentication 4
authorization 8
Then you can just or together whatever you want without having any
complex macros for producing the final permissions value. Alternatively
you could also have a simple enum and use set_bit/test_bit marcos (see
lib/hci_lib.h).
Johan
^ permalink raw reply
* Re: [PATCH 1/3] Initial attribute permission implementation
From: Anderson Lizardo @ 2010-12-02 13:33 UTC (permalink / raw)
To: Anderson Lizardo, linux-bluetooth, Bruna Moreira
In-Reply-To: <20101202101031.GB18808@jh-x301>
On Thu, Dec 2, 2010 at 6:10 AM, Johan Hedberg <johan.hedberg@gmail.com> wrote:
> Hi,
>
> On Wed, Dec 01, 2010, Anderson Lizardo wrote:
>> + attrib_db_add(0x0685, &uuid, ATT_ACCESS(ATT_READ, ATT_NONE), atval,
>> + len);
> <snip>
>> +/* Access permissions */
>> +#define ATT_READ 1
>> +#define ATT_WRITE 2
>> +/* Authentication/Authorization permissions */
>> +#define ATT_NONE 0
>> +#define ATT_AUTHENTICATION 2
>> +#define ATT_AUTHORIZATION 4
>> +/* Build bit mask for permission checks */
>> +#define ATT_ACCESS(x, y) (((x) << y) | (x))
>
> The last macro doesn't make any sense to me. Based the core spec it
> seems that the values for the different permission types are
> implementation specific and not exposed publicly (vol 2, part G, 2.5.1:
> "Attribute Permissions is part of the Attribute that cannot be read from
> or written to using the Attribute Protocol").
Correct. The permission implementation is internal.
> Why not make sure that
> they are all orthogonal from the start instead of ssigning the same
> value for authentication and writability like you do now. I.e. instead
> you could have:
>
> none 0
> read 1
> write 2
> authentication 4
> authorization 8
This was the first attempt (as it seemed obvious). But see vol 3, part
F, section 4:
"For example, an attribute value may be allowed to be read by any device, but
only written by an authenticated device. An implementation should take this
into account, and not assume that just because it can read an attribute’s value,
it will also be able to write the value. [...]"
This makes it clear that the authentication/authorization permissions
are not orthogonal. Further on it is confirmed by the attribute
permissions of "Client Characteristic Configuration" (vol 3, part G,
3.3.3.4):
* Readable with no authentication or authorization.
* Writable with authentication and authorization defined by a higher
layer specification or is implementation specific.
The scheme implemented in this patch set is just a compacted version
of unix permissions using a 2-bit grouping (not sure if it will look
nice to read):
5 4 3 2 1 0 bit
| | | | | \_ Read
| | | | \___ Write
| | | \_____ Authenticated read
| | \_______ Authenticated write
| \_________ Authorized read
\___________ Authorized write
With an addition that, if the authenticated/authorized read/write bits
are set, the "none" read/write bits are set as well (I think the
reason is obvious).
> Then you can just or together whatever you want without having any
> complex macros for producing the final permissions value. Alternatively
> you could also have a simple enum and use set_bit/test_bit marcos (see
> lib/hci_lib.h).
If you have ideas to reuse the hci_lib.h macros and keep the semantics
defined in the spec at the same time, let us know.
>
> Johan
>
Regards,
--
Anderson Lizardo
OpenBossa Labs - INdT
Manaus - Brazil
^ permalink raw reply
* [PATCH 1/4] Sim Access Profile API
From: Waldemar Rymarkiewicz @ 2010-12-02 14:14 UTC (permalink / raw)
To: linux-bluetooth, Marcel Holtmann, Johan Hedberg; +Cc: Waldemar Rymarkiewicz
New API for Sim Access Profile.
---
Makefile.am | 2 +-
doc/sap-api.txt | 34 ++++++++++++++++++++++++++++++++++
2 files changed, 35 insertions(+), 1 deletions(-)
create mode 100644 doc/sap-api.txt
diff --git a/Makefile.am b/Makefile.am
index 5f96975..97345a3 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -354,7 +354,7 @@ EXTRA_DIST += doc/manager-api.txt \
doc/service-api.txt doc/agent-api.txt doc/attribute-api.txt \
doc/serial-api.txt doc/network-api.txt \
doc/input-api.txt doc/audio-api.txt doc/control-api.txt \
- doc/hfp-api.txt doc/assigned-numbers.txt
+ doc/hfp-api.txt doc/assigned-numbers.txt doc/sap-api.txt
AM_YFLAGS = -d
diff --git a/doc/sap-api.txt b/doc/sap-api.txt
new file mode 100644
index 0000000..b8b7253
--- /dev/null
+++ b/doc/sap-api.txt
@@ -0,0 +1,34 @@
+BlueZ D-Bus Sim Access Profile API description
+***********************************
+
+Copyright (C) 2010 ST-Ericsson SA
+
+
+Sim Access Profile hierarchy
+============================
+
+Service org.bluez
+Interface org.bluez.SimAccess
+Object path [variable prefix]/{hci0,hci1,...}
+
+Methods void Disconnect()
+
+ Disconnects SAP client from the server.
+
+ Possible errors: org.bluez.Error.Failed
+
+ 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 Connected [readonly]
+
+ Indicates if SAP client is connected to the server.
--
1.7.0.4
^ permalink raw reply related
* Re: [PATCH 1/3] Initial attribute permission implementation
From: Johan Hedberg @ 2010-12-02 14:58 UTC (permalink / raw)
To: Anderson Lizardo; +Cc: linux-bluetooth, Bruna Moreira
In-Reply-To: <AANLkTinbiQyXTKKPc+jfpEtfuJAFCZphzR6Dcwm3Qaj+@mail.gmail.com>
Hi Anderson,
On Thu, Dec 02, 2010, Anderson Lizardo wrote:
> > Why not make sure that they are all orthogonal from the start
> > instead of assigning the same value for authentication and
> > writability like you do now. I.e. instead you could have:
> >
> > none 0
> > read 1
> > write 2
> > authentication 4
> > authorization 8
>
> This was the first attempt (as it seemed obvious). But see vol 3, part
> F, section 4:
>
> "For example, an attribute value may be allowed to be read by any device, but
> only written by an authenticated device. An implementation should take this
> into account, and not assume that just because it can read an attribute’s value,
> it will also be able to write the value. [...]"
>
> This makes it clear that the authentication/authorization permissions
> are not orthogonal. Further on it is confirmed by the attribute
> permissions of "Client Characteristic Configuration" (vol 3, part G,
> 3.3.3.4):
>
> * Readable with no authentication or authorization.
> * Writable with authentication and authorization defined by a higher
> layer specification or is implementation specific.
>
> The scheme implemented in this patch set is just a compacted version
> of unix permissions using a 2-bit grouping (not sure if it will look
> nice to read):
>
> 5 4 3 2 1 0 bit
> | | | | | \_ Read
> | | | | \___ Write
> | | | \_____ Authenticated read
> | | \_______ Authenticated write
> | \_________ Authorized read
> \___________ Authorized write
Ok, now I understand what you were trying to accomplish. If you had put
all this into the commit message or as a code comment we'd have avoided
some confusion ;)
> With an addition that, if the authenticated/authorized read/write bits
> are set, the "none" read/write bits are set as well (I think the
> reason is obvious).
Wouldn't it be the other way around, i.e. if the "none" bits are set
(i.e. no special authentication or authentication requirements) then
for higher security (authenticated or authorized) reads and writes would
also succeed.
Anyway, if the requirement checks are really supposed to be so flexible
and up to the profile implementation you will still have some gaps with
your scheme. It's not e.g. possible to say "allow write only if *both*
authenticated *and* authorized". So, for ultimate flexibility, I don't
think there's any other choice then have a profile specific callback
function that makes the decision. The callback would at least get the
attempted operation (read/write) as well as the current level of
security (authorized/authenticated) as parameters. Any thoughts on this?
Johan
^ permalink raw reply
* Re: [PATCH 1/4] Sim Access Profile API
From: Gustavo F. Padovan @ 2010-12-02 15:19 UTC (permalink / raw)
To: Waldemar Rymarkiewicz; +Cc: linux-bluetooth, Marcel Holtmann, Johan Hedberg
In-Reply-To: <1291299261-26016-1-git-send-email-waldemar.rymarkiewicz@tieto.com>
Hi Waldemar,
* Waldemar Rymarkiewicz <waldemar.rymarkiewicz@tieto.com> [2010-12-02 15:14:21 +0100]:
> New API for Sim Access Profile.
> ---
> Makefile.am | 2 +-
> doc/sap-api.txt | 34 ++++++++++++++++++++++++++++++++++
> 2 files changed, 35 insertions(+), 1 deletions(-)
> create mode 100644 doc/sap-api.txt
>
> diff --git a/Makefile.am b/Makefile.am
> index 5f96975..97345a3 100644
> --- a/Makefile.am
> +++ b/Makefile.am
> @@ -354,7 +354,7 @@ EXTRA_DIST += doc/manager-api.txt \
> doc/service-api.txt doc/agent-api.txt doc/attribute-api.txt \
> doc/serial-api.txt doc/network-api.txt \
> doc/input-api.txt doc/audio-api.txt doc/control-api.txt \
> - doc/hfp-api.txt doc/assigned-numbers.txt
> + doc/hfp-api.txt doc/assigned-numbers.txt doc/sap-api.txt
Leave assigned-numbers.txt in the end.
>
> AM_YFLAGS = -d
>
> diff --git a/doc/sap-api.txt b/doc/sap-api.txt
> new file mode 100644
> index 0000000..b8b7253
> --- /dev/null
> +++ b/doc/sap-api.txt
> @@ -0,0 +1,34 @@
> +BlueZ D-Bus Sim Access Profile API description
> +***********************************
> +
> +Copyright (C) 2010 ST-Ericsson SA
> +
> +
> +Sim Access Profile hierarchy
> +============================
> +
> +Service org.bluez
> +Interface org.bluez.SimAccess
> +Object path [variable prefix]/{hci0,hci1,...}
> +
> +Methods void Disconnect()
> +
> + Disconnects SAP client from the server.
> +
> + Possible errors: org.bluez.Error.Failed
Don't you need a Connect() method?
--
Gustavo F. Padovan
http://profusion.mobi
^ permalink raw reply
* RE: [PATCH 1/4] Sim Access Profile API
From: Waldemar.Rymarkiewicz @ 2010-12-02 15:23 UTC (permalink / raw)
To: padovan; +Cc: linux-bluetooth, marcel, johan.hedberg
In-Reply-To: <20101202151938.GA32133@vigoh>
Hi Gustavo,
>-----Original Message-----
>From: Gustavo F. Padovan [mailto:pao@profusion.mobi] On Behalf=20
>Of Gustavo F. Padovan
>Sent: Thursday, December 02, 2010 4:20 PM
>To: Rymarkiewicz Waldemar
>Cc: linux-bluetooth@vger.kernel.org; Marcel Holtmann; Johan Hedberg
>Subject: Re: [PATCH 1/4] Sim Access Profile API
>
>Hi Waldemar,
>
>* Waldemar Rymarkiewicz <waldemar.rymarkiewicz@tieto.com>=20
>[2010-12-02 15:14:21 +0100]:
>
>> New API for Sim Access Profile.
>> ---
>> Makefile.am | 2 +-
>> doc/sap-api.txt | 34 ++++++++++++++++++++++++++++++++++
>> 2 files changed, 35 insertions(+), 1 deletions(-) create=20
>mode 100644=20
>> doc/sap-api.txt
>>=20
>> diff --git a/Makefile.am b/Makefile.am index 5f96975..97345a3 100644
>> --- a/Makefile.am
>> +++ b/Makefile.am
>> @@ -354,7 +354,7 @@ EXTRA_DIST +=3D doc/manager-api.txt \
>> doc/service-api.txt doc/agent-api.txt=20
>doc/attribute-api.txt \
>> doc/serial-api.txt doc/network-api.txt \
>> doc/input-api.txt doc/audio-api.txt=20
>doc/control-api.txt \
>> - doc/hfp-api.txt doc/assigned-numbers.txt
>> + doc/hfp-api.txt doc/assigned-numbers.txt doc/sap-api.txt
>
>Leave assigned-numbers.txt in the end.
> =20
>> AM_YFLAGS =3D -d
>> =20
>> diff --git a/doc/sap-api.txt b/doc/sap-api.txt new file mode 100644=20
>> index 0000000..b8b7253
>> --- /dev/null
>> +++ b/doc/sap-api.txt
>> @@ -0,0 +1,34 @@
>> +BlueZ D-Bus Sim Access Profile API description
>> +***********************************
>> +
>> +Copyright (C) 2010 ST-Ericsson SA
>> +
>> +
>> +Sim Access Profile hierarchy
>> +=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D
>> +
>> +Service org.bluez
>> +Interface org.bluez.SimAccess
>> +Object path [variable prefix]/{hci0,hci1,...}
>> +
>> +Methods void Disconnect()
>> +
>> + Disconnects SAP client from the server.
>> +
>> + Possible errors: org.bluez.Error.Failed
>
>Don't you need a Connect() method?
It'a a server, not a client. We will never initialize a connection.
Thanks,
/Waldek
^ permalink raw reply
* [PATCH] Optimize tracker queries for PBAP
From: Radoslaw Jablonski @ 2010-12-02 16:02 UTC (permalink / raw)
To: linux-bluetooth; +Cc: Radoslaw Jablonski
Now data from tracker is fetched without redundand fields. Also
determining which type has phone, address and email (work or home) is
done in backend code - no tracker sub-query is used for that case. Now
queries are about 6 times faster for any amount of data( call history
queries, which were heavy loaded with OPTIONAL sub-queries are even 10
times faster than before)
---
plugins/phonebook-tracker.c | 514 ++++++++++++++-----------------------------
1 files changed, 166 insertions(+), 348 deletions(-)
diff --git a/plugins/phonebook-tracker.c b/plugins/phonebook-tracker.c
index a6b9e72..cdc1008 100644
--- a/plugins/phonebook-tracker.c
+++ b/plugins/phonebook-tracker.c
@@ -43,30 +43,32 @@
#define TRACKER_RESOURCES_INTERFACE "org.freedesktop.Tracker1.Resources"
#define TRACKER_DEFAULT_CONTACT_ME "http://www.semanticdesktop.org/ontologies/2007/03/22/nco#default-contact-me"
+#define AFFILATION_HOME "Home"
+#define AFFILATION_WORK "Work"
#define ADDR_FIELD_AMOUNT 7
-#define PULL_QUERY_COL_AMOUNT 48
+#define PULL_QUERY_COL_AMOUNT 40
#define COUNT_QUERY_COL_AMOUNT 1
-#define COL_HOME_NUMBER 0
+#define COL_PHONE_NUMBER 0
#define COL_FULL_NAME 1
#define COL_FAMILY_NAME 2
#define COL_GIVEN_NAME 3
#define COL_ADDITIONAL_NAME 4
#define COL_NAME_PREFIX 5
#define COL_NAME_SUFFIX 6
-#define COL_HOME_EMAIL 7
-#define COL_WORK_NUMBER 8
+#define COL_EMAIL 7
+#define COL_CELL_NUMBER 8
-#define COL_HOME_ADDR_POBOX 9
-#define COL_HOME_ADDR_EXT 10
-#define COL_HOME_ADDR_STREET 11
-#define COL_HOME_ADDR_LOCALITY 12
-#define COL_HOME_ADDR_REGION 13
-#define COL_HOME_ADDR_CODE 14
-#define COL_HOME_ADDR_COUNTRY 15
+#define COL_ADDR_POBOX 9
+#define COL_ADDR_EXT 10
+#define COL_ADDR_STREET 11
+#define COL_ADDR_LOCALITY 12
+#define COL_ADDR_REGION 13
+#define COL_ADDR_CODE 14
+#define COL_ADDR_COUNTRY 15
#define COL_FAX_NUMBER 16
-#define COL_WORK_EMAIL 17
+#define COL_AFF_TYPE 17
#define COL_BIRTH_DATE 18
#define COL_NICKNAME 19
#define COL_URL 20
@@ -76,51 +78,39 @@
#define COL_ORG_DEPARTMENT 23
#define COL_ORG_ROLE 24
-#define COL_WORK_ADDR_POBOX 25
-#define COL_WORK_ADDR_EXT 26
-#define COL_WORK_ADDR_STREET 27
-#define COL_WORK_ADDR_LOCALITY 28
-#define COL_WORK_ADDR_REGION 29
-#define COL_WORK_ADDR_CODE 30
-#define COL_WORK_ADDR_COUNTRY 31
-
-#define COL_UID 32
-#define COL_TITLE 33
-#define COL_OTHER_NUMBER 34
-
-#define COL_OTHER_ADDR_POBOX 35
-#define COL_OTHER_ADDR_EXT 36
-#define COL_OTHER_ADDR_STREET 37
-#define COL_OTHER_ADDR_LOCALITY 38
-#define COL_OTHER_ADDR_REGION 39
-#define COL_OTHER_ADDR_CODE 40
-#define COL_OTHER_ADDR_COUNTRY 41
-
-#define COL_OTHER_EMAIL 42
-#define COL_CELL_NUMBER 43
-#define COL_DATE 44
-#define COL_SENT 45
-#define COL_ANSWERED 46
-#define CONTACTS_ID_COL 47
+#define COL_UID 25
+#define COL_TITLE 26
+#define COL_OTHER_NUMBER 27
+
+#define COL_OTHER_ADDR_POBOX 28
+#define COL_OTHER_ADDR_EXT 29
+#define COL_OTHER_ADDR_STREET 30
+#define COL_OTHER_ADDR_LOCALITY 31
+#define COL_OTHER_ADDR_REGION 32
+#define COL_OTHER_ADDR_CODE 33
+#define COL_OTHER_ADDR_COUNTRY 34
+
+#define COL_OTHER_EMAIL 35
+#define COL_DATE 36
+#define COL_SENT 37
+#define COL_ANSWERED 38
+#define CONTACTS_ID_COL 39
#define CONTACT_ID_PREFIX "contact:"
#define CONTACTS_QUERY_ALL \
"SELECT nco:phoneNumber(?v) nco:fullname(?c) " \
"nco:nameFamily(?c) nco:nameGiven(?c) " \
"nco:nameAdditional(?c) nco:nameHonorificPrefix(?c) " \
- "nco:nameHonorificSuffix(?c) nco:emailAddress(?e) " \
- "nco:phoneNumber(?w) nco:pobox(?p) nco:extendedAddress(?p) " \
+ "nco:nameHonorificSuffix(?c) nco:emailAddress(?e) ?vc " \
+ "nco:pobox(?p) nco:extendedAddress(?p) " \
"nco:streetAddress(?p) nco:locality(?p) nco:region(?p) " \
- "nco:postalcode(?p) nco:country(?p) ?f nco:emailAddress(?ew) " \
+ "nco:postalcode(?p) nco:country(?p) ?f ?affType " \
"nco:birthDate(?c) nco:nickname(?c) nco:url(?c) " \
"?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) " \
+ "nco:role(?a) nco:contactUID(?c) " \
"nco:title(?a) ?t nco:pobox(?po) nco:extendedAddress(?po) " \
"nco:streetAddress(?po) nco:locality(?po) nco:region(?po) " \
- "nco:postalcode(?po) nco:country(?po) nco:emailAddress(?eo) " \
- "?vc " \
+ "nco:postalcode(?po) nco:country(?po) nco:emailAddress(?eo) " \
"\"NOTACALL\" \"false\" \"false\" ?c " \
"WHERE { " \
"?c a nco:PersonContact . " \
@@ -144,16 +134,10 @@
"}" \
"OPTIONAL { " \
"?c nco:hasAffiliation ?a . " \
- "OPTIONAL { ?a rdfs:label \"Work\" . " \
- "OPTIONAL { ?a nco:hasEmailAddress ?ew . } " \
- "OPTIONAL { ?a nco:hasPostalAddress ?pw . } " \
- "OPTIONAL { ?a nco:hasPhoneNumber ?w . } " \
- "}" \
- "OPTIONAL { ?a rdfs:label \"Home\" . " \
+ "OPTIONAL { ?a rdfs:label ?affType .}" \
"OPTIONAL { ?a nco:hasEmailAddress ?e . } " \
"OPTIONAL { ?a nco:hasPostalAddress ?p . } " \
"OPTIONAL { ?a nco:hasPhoneNumber ?v . } " \
- "}" \
"OPTIONAL { ?a nco:org ?o . } " \
"} " \
"OPTIONAL { ?c nco:hasPostalAddress ?po . } " \
@@ -175,22 +159,19 @@
"} GROUP BY ?c"
#define MISSED_CALLS_QUERY \
- "SELECT ?h nco:fullname(?c) " \
+ "SELECT nco:phoneNumber(?ap) nco:fullname(?c) " \
"nco:nameFamily(?c) nco:nameGiven(?c) " \
"nco:nameAdditional(?c) nco:nameHonorificPrefix(?c) " \
- "nco:nameHonorificSuffix(?c) nco:emailAddress(?e) " \
- "?w nco:pobox(?p) nco:extendedAddress(?p) " \
+ "nco:nameHonorificSuffix(?c) nco:emailAddress(?e) ?vc " \
+ "nco:pobox(?p) nco:extendedAddress(?p) " \
"nco:streetAddress(?p) nco:locality(?p) nco:region(?p) " \
- "nco:postalcode(?p) nco:country(?p) \"\" nco:emailAddress(?ew) "\
+ "nco:postalcode(?p) nco:country(?p) \"\" ?affType " \
"nco:birthDate(?c) nco:nickname(?c) nco:url(?c) " \
"?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) " \
- "?title nco:phoneNumber(?t) nco:pobox(?po) " \
- "nco:extendedAddress(?po) nco:streetAddress(?po) " \
- "nco:locality(?po) nco:region(?po) nco:postalcode(?po) " \
- "nco:country(?po) nco:emailAddress(?eo) ?vc " \
+ "nco:role(?a) nco:contactUID(?c) " \
+ "nco:title(?a) nco:phoneNumber(?t) nco:pobox(?po) nco:extendedAddress(?po) " \
+ "nco:streetAddress(?po) nco:locality(?po) nco:region(?po) " \
+ "nco:postalcode(?po) nco:country(?po) nco:emailAddress(?eo) " \
"nmo:receivedDate(?call) " \
"nmo:isSent(?call) nmo:isAnswered(?call) ?x " \
"WHERE { " \
@@ -215,63 +196,30 @@
"OPTIONAL { ?c nco:hasEmailAddress ?eo . } " \
"OPTIONAL { " \
"?c nco:hasAffiliation ?a . " \
- "OPTIONAL { " \
- "?a rdfs:label \"Work\" . " \
- "OPTIONAL { ?a nco:hasEmailAddress ?ew . } " \
- "OPTIONAL { ?a nco:hasPostalAddress ?pw . } " \
"OPTIONAL { ?a nco:title ?title } " \
- "}" \
- "OPTIONAL { " \
- "?a rdfs:label \"Home\" . " \
"OPTIONAL { ?a nco:hasEmailAddress ?e . } " \
"OPTIONAL { ?a nco:hasPostalAddress ?p . } " \
- "} " \
"OPTIONAL { ?a nco:org ?o . } " \
"} " \
"} UNION { " \
"?x a nco:Contact . " \
- "?x nco:hasPhoneNumber ?tmp . " \
+ "?x nco:hasPhoneNumber ?ap . " \
"?call a nmo:Call ; " \
"nmo:from ?x ; " \
"nmo:isSent false ; " \
"nmo:isAnswered false . " \
"?c a nco:PersonContact . " \
"?c nco:hasAffiliation ?a . " \
- "?a nco:hasPhoneNumber ?tmp . " \
+ "?a nco:hasPhoneNumber ?ap . " \
"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 . } " \
- "OPTIONAL { ?a nco:hasPostalAddress ?pw . } " \
- "OPTIONAL { ?a nco:org ?o . } " \
- "OPTIONAL { ?a nco:title ?title } " \
- "{ " \
- "SELECT ?p ?e ?c WHERE { " \
- "?c nco:hasAffiliation ?b . " \
- "OPTIONAL {?b rdfs:label \"Home\" . " \
- "OPTIONAL {?b nco:hasEmailAddress ?e . } " \
- "OPTIONAL {?b nco:hasPostalAddress ?p . }}} " \
- "} " \
- "}" \
- "OPTIONAL { " \
- "?a rdfs:label \"Home\" . " \
- "?tmp nco:phoneNumber ?h . " \
- "OPTIONAL { ?a nco:hasEmailAddress ?e . } " \
- "OPTIONAL { ?a nco:hasPostalAddress ?p . } " \
- "OPTIONAL { ?a nco:org ?o . } " \
- "{ " \
- "SELECT ?pw ?ew ?title ?c WHERE { " \
- "?c nco:hasAffiliation ?b . " \
- "OPTIONAL {?b rdfs:label \"Work\" . " \
- "OPTIONAL {?b nco:hasEmailAddress ?ew . } " \
- "OPTIONAL {?b nco:title ?title } " \
- "OPTIONAL {?b nco:hasPostalAddress ?pw . }}} " \
- "} " \
- "}" \
+ "OPTIONAL {?a rdfs:label ?affType . }" \
+ "OPTIONAL {?a nco:hasEmailAddress ?e . } " \
+ "OPTIONAL {?a nco:hasPostalAddress ?p . }" \
+ "OPTIONAL { ?a nco:org ?o . } " \
+ "OPTIONAL { ?a nco:title ?title } " \
"OPTIONAL { ?c nco:hasPostalAddress ?po . } " \
"OPTIONAL { ?c nco:hasEmailAddress ?eo . } " \
"} UNION { " \
@@ -327,22 +275,20 @@
"} GROUP BY ?call ORDER BY DESC(nmo:receivedDate(?call))"
#define INCOMING_CALLS_QUERY \
- "SELECT ?h nco:fullname(?c) " \
+ "SELECT nco:phoneNumber(?ap) nco:fullname(?c) " \
"nco:nameFamily(?c) nco:nameGiven(?c) " \
"nco:nameAdditional(?c) nco:nameHonorificPrefix(?c) " \
- "nco:nameHonorificSuffix(?c) nco:emailAddress(?e) " \
- "?w nco:pobox(?p) nco:extendedAddress(?p) " \
+ "nco:nameHonorificSuffix(?c) nco:emailAddress(?e) ?vc " \
+ "nco:pobox(?p) nco:extendedAddress(?p) " \
"nco:streetAddress(?p) nco:locality(?p) nco:region(?p) " \
- "nco:postalcode(?p) nco:country(?p) \"\" nco:emailAddress(?ew) "\
+ "nco:postalcode(?p) nco:country(?p) \"\" ?affType " \
"nco:birthDate(?c) nco:nickname(?c) nco:url(?c) " \
"?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) " \
- "?title nco:phoneNumber(?t) nco:pobox(?po) " \
- "nco:extendedAddress(?po) nco:streetAddress(?po) " \
- "nco:locality(?po) nco:region(?po) nco:postalcode(?po) " \
- "nco:country(?po) nco:emailAddress(?eo) ?vc " \
+ "nco:role(?a) nco:contactUID(?c) " \
+ "nco:title(?a) nco:phoneNumber(?t) nco:pobox(?po) " \
+ "nco:extendedAddress(?po) " \
+ "nco:streetAddress(?po) nco:locality(?po) nco:region(?po) " \
+ "nco:postalcode(?po) nco:country(?po) nco:emailAddress(?eo) " \
"nmo:receivedDate(?call) " \
"nmo:isSent(?call) nmo:isAnswered(?call) ?x " \
"WHERE { " \
@@ -367,63 +313,30 @@
"OPTIONAL { ?c nco:hasEmailAddress ?eo . } " \
"OPTIONAL { " \
"?c nco:hasAffiliation ?a . " \
- "OPTIONAL { " \
- "?a rdfs:label \"Work\" . " \
"OPTIONAL { ?a nco:title ?title } " \
- "OPTIONAL { ?a nco:hasEmailAddress ?ew . } " \
- "OPTIONAL { ?a nco:hasPostalAddress ?pw . } " \
- "}" \
- "OPTIONAL { " \
- "?a rdfs:label \"Home\" . " \
"OPTIONAL { ?a nco:hasEmailAddress ?e . } " \
"OPTIONAL { ?a nco:hasPostalAddress ?p . } " \
- "} " \
"OPTIONAL { ?a nco:org ?o . } " \
"} " \
"} UNION { " \
"?x a nco:Contact . " \
- "?x nco:hasPhoneNumber ?tmp . " \
+ "?x nco:hasPhoneNumber ?ap . " \
"?call a nmo:Call ; " \
"nmo:from ?x ; " \
"nmo:isSent false ; " \
"nmo:isAnswered true . " \
"?c a nco:PersonContact . " \
"?c nco:hasAffiliation ?a . " \
- "?a nco:hasPhoneNumber ?tmp . " \
+ "?a nco:hasPhoneNumber ?ap . " \
"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 . } " \
- "OPTIONAL { ?a nco:hasPostalAddress ?pw . } " \
- "OPTIONAL { ?a nco:org ?o . } " \
- "OPTIONAL { ?a nco:title ?title } " \
- "{ " \
- "SELECT ?p ?e ?c WHERE { " \
- "?c nco:hasAffiliation ?b . " \
- "OPTIONAL {?b rdfs:label \"Home\" . " \
- "OPTIONAL {?b nco:hasEmailAddress ?e . } " \
- "OPTIONAL {?b nco:hasPostalAddress ?p . }}} " \
- "} " \
- "}" \
- "OPTIONAL { " \
- "?a rdfs:label \"Home\" . " \
- "?tmp nco:phoneNumber ?h . " \
- "OPTIONAL { ?a nco:hasEmailAddress ?e . } " \
- "OPTIONAL { ?a nco:hasPostalAddress ?p . } " \
- "OPTIONAL { ?a nco:org ?o . } " \
- "{ " \
- "SELECT ?pw ?ew ?title ?c WHERE { " \
- "?c nco:hasAffiliation ?b . " \
- "OPTIONAL {?b rdfs:label \"Work\" . " \
- "OPTIONAL {?b nco:hasEmailAddress ?ew . } " \
- "OPTIONAL {?b nco:title ?title } " \
- "OPTIONAL {?b nco:hasPostalAddress ?pw . }}} " \
- "} " \
- "}" \
+ "OPTIONAL {?a rdfs:label ?affType . }" \
+ "OPTIONAL {?a nco:hasEmailAddress ?e . } " \
+ "OPTIONAL {?a nco:hasPostalAddress ?p . }" \
+ "OPTIONAL { ?a nco:org ?o . } " \
+ "OPTIONAL { ?a nco:title ?title } " \
"OPTIONAL { ?c nco:hasPostalAddress ?po . } " \
"OPTIONAL { ?c nco:hasEmailAddress ?eo . } " \
"} UNION { " \
@@ -478,22 +391,20 @@
"} GROUP BY ?call ORDER BY DESC(nmo:receivedDate(?call))"
#define OUTGOING_CALLS_QUERY \
- "SELECT ?h nco:fullname(?c) " \
+ "SELECT nco:phoneNumber(?ap) nco:fullname(?c) " \
"nco:nameFamily(?c) nco:nameGiven(?c) " \
"nco:nameAdditional(?c) nco:nameHonorificPrefix(?c) " \
- "nco:nameHonorificSuffix(?c) nco:emailAddress(?e) " \
- "?w nco:pobox(?p) nco:extendedAddress(?p) " \
+ "nco:nameHonorificSuffix(?c) nco:emailAddress(?e) ?vc " \
+ "nco:pobox(?p) nco:extendedAddress(?p) " \
"nco:streetAddress(?p) nco:locality(?p) nco:region(?p) " \
- "nco:postalcode(?p) nco:country(?p) \"\" nco:emailAddress(?ew) "\
+ "nco:postalcode(?p) nco:country(?p) \"\" ?affType " \
"nco:birthDate(?c) nco:nickname(?c) nco:url(?c) " \
"?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) " \
- "?title nco:phoneNumber(?t) nco:pobox(?po) " \
- "nco:extendedAddress(?po) nco:streetAddress(?po) " \
- "nco:locality(?po) nco:region(?po) nco:postalcode(?po) " \
- "nco:country(?po) nco:emailAddress(?eo) ?vc " \
+ "nco:role(?a) nco:contactUID(?c) " \
+ "nco:title(?a) nco:phoneNumber(?t) nco:pobox(?po) " \
+ "nco:extendedAddress(?po) " \
+ "nco:streetAddress(?po) nco:locality(?po) nco:region(?po) " \
+ "nco:postalcode(?po) nco:country(?po) nco:emailAddress(?eo) " \
"nmo:receivedDate(?call) " \
"nmo:isSent(?call) nmo:isAnswered(?call) ?x " \
"WHERE { " \
@@ -517,62 +428,29 @@
"OPTIONAL { ?c nco:hasEmailAddress ?eo . } " \
"OPTIONAL { " \
"?c nco:hasAffiliation ?a . " \
- "OPTIONAL { " \
- "?a rdfs:label \"Work\" . " \
- "OPTIONAL { ?a nco:hasEmailAddress ?ew . } " \
- "OPTIONAL { ?a nco:hasPostalAddress ?pw . } " \
"OPTIONAL { ?a nco:title ?title } " \
- "}" \
- "OPTIONAL { " \
- "?a rdfs:label \"Home\" . " \
"OPTIONAL { ?a nco:hasEmailAddress ?e . } " \
"OPTIONAL { ?a nco:hasPostalAddress ?p . } " \
- "} " \
"OPTIONAL { ?a nco:org ?o . } " \
"} " \
"} UNION { " \
"?x a nco:Contact . " \
- "?x nco:hasPhoneNumber ?tmp . " \
+ "?x nco:hasPhoneNumber ?ap . " \
"?call a nmo:Call ; " \
"nmo:to ?x ; " \
"nmo:isSent true . " \
"?c a nco:PersonContact . " \
"?c nco:hasAffiliation ?a . " \
- "?a nco:hasPhoneNumber ?tmp . " \
+ "?a nco:hasPhoneNumber ?ap . " \
"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 . } " \
- "OPTIONAL { ?a nco:hasPostalAddress ?pw . } " \
- "OPTIONAL { ?a nco:org ?o . } " \
- "OPTIONAL { ?a nco:title ?title } " \
- "{ " \
- "SELECT ?p ?e ?c WHERE { " \
- "?c nco:hasAffiliation ?b . " \
- "OPTIONAL {?b rdfs:label \"Home\" . " \
- "OPTIONAL {?b nco:hasEmailAddress ?e . } " \
- "OPTIONAL {?b nco:hasPostalAddress ?p . }}} " \
- "} " \
- "}" \
- "OPTIONAL { " \
- "?a rdfs:label \"Home\" . " \
- "?tmp nco:phoneNumber ?h . " \
- "OPTIONAL { ?a nco:hasEmailAddress ?e . } " \
- "OPTIONAL { ?a nco:hasPostalAddress ?p . } " \
- "OPTIONAL { ?a nco:org ?o . } " \
- "{ " \
- "SELECT ?pw ?ew ?title ?c WHERE { " \
- "?c nco:hasAffiliation ?b . " \
- "OPTIONAL {?b rdfs:label \"Work\" . " \
- "OPTIONAL {?b nco:hasEmailAddress ?ew . } " \
- "OPTIONAL { ?a nco:title ?title } " \
- "OPTIONAL {?b nco:hasPostalAddress ?pw . }}} " \
- "} " \
- "}" \
+ "OPTIONAL {?a rdfs:label ?affType . }" \
+ "OPTIONAL {?a nco:hasEmailAddress ?e . } " \
+ "OPTIONAL {?a nco:hasPostalAddress ?p . }" \
+ "OPTIONAL { ?a nco:org ?o . } " \
+ "OPTIONAL { ?a nco:title ?title } " \
"OPTIONAL { ?c nco:hasPostalAddress ?po . } " \
"OPTIONAL { ?c nco:hasEmailAddress ?eo . } " \
"} UNION { " \
@@ -623,22 +501,20 @@
"} GROUP BY ?call ORDER BY DESC(nmo:sentDate(?call))"
#define COMBINED_CALLS_QUERY \
- "SELECT ?h nco:fullname(?c) " \
+ "SELECT nco:phoneNumber(?ap) nco:fullname(?c) " \
"nco:nameFamily(?c) nco:nameGiven(?c) " \
"nco:nameAdditional(?c) nco:nameHonorificPrefix(?c) " \
- "nco:nameHonorificSuffix(?c) nco:emailAddress(?e) " \
- "?w nco:pobox(?p) nco:extendedAddress(?p) " \
+ "nco:nameHonorificSuffix(?c) nco:emailAddress(?e) ?vc " \
+ "nco:pobox(?p) nco:extendedAddress(?p) " \
"nco:streetAddress(?p) nco:locality(?p) nco:region(?p) " \
- "nco:postalcode(?p) nco:country(?p) \"\" nco:emailAddress(?ew) "\
+ "nco:postalcode(?p) nco:country(?p) \"\" ?affType " \
"nco:birthDate(?c) nco:nickname(?c) nco:url(?c) " \
"?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) " \
- "?title nco:phoneNumber(?t) nco:pobox(?po) " \
- "nco:extendedAddress(?po) nco:streetAddress(?po) " \
- "nco:locality(?po) nco:region(?po) nco:postalcode(?po) " \
- "nco:country(?po) nco:emailAddress(?eo) ?vc " \
+ "nco:role(?a) nco:contactUID(?c) " \
+ "nco:title(?a) nco:phoneNumber(?t) nco:pobox(?po) " \
+ "nco:extendedAddress(?po) " \
+ "nco:streetAddress(?po) nco:locality(?po) nco:region(?po) " \
+ "nco:postalcode(?po) nco:country(?po) nco:emailAddress(?eo) " \
"nmo:receivedDate(?call) " \
"nmo:isSent(?call) nmo:isAnswered(?call) ?x " \
"WHERE { " \
@@ -662,62 +538,29 @@
"OPTIONAL { ?c nco:hasEmailAddress ?eo . } " \
"OPTIONAL { " \
"?c nco:hasAffiliation ?a . " \
- "OPTIONAL { " \
- "?a rdfs:label \"Work\" . " \
- "OPTIONAL { ?a nco:hasEmailAddress ?ew . } " \
- "OPTIONAL { ?a nco:hasPostalAddress ?pw . } " \
"OPTIONAL { ?a nco:title ?title } " \
- "}" \
- "OPTIONAL { " \
- "?a rdfs:label \"Home\" . " \
"OPTIONAL { ?a nco:hasEmailAddress ?e . } " \
"OPTIONAL { ?a nco:hasPostalAddress ?p . } " \
- "} " \
"OPTIONAL { ?a nco:org ?o . } " \
"} " \
"} UNION { " \
"?x a nco:Contact . " \
- "?x nco:hasPhoneNumber ?tmp . " \
+ "?x nco:hasPhoneNumber ?ap . " \
"?call a nmo:Call ; " \
"nmo:to ?x ; " \
"nmo:isSent true . " \
"?c a nco:PersonContact . " \
"?c nco:hasAffiliation ?a . " \
- "?a nco:hasPhoneNumber ?tmp . " \
+ "?a nco:hasPhoneNumber ?ap . " \
"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 . } " \
- "OPTIONAL { ?a nco:hasPostalAddress ?pw . } " \
- "OPTIONAL { ?a nco:org ?o . } " \
- "OPTIONAL { ?a nco:title ?title } " \
- "{ " \
- "SELECT ?p ?e ?c WHERE { " \
- "?c nco:hasAffiliation ?b . " \
- "OPTIONAL {?b rdfs:label \"Home\" . " \
- "OPTIONAL {?b nco:hasEmailAddress ?e . } " \
- "OPTIONAL {?b nco:hasPostalAddress ?p . }}} " \
- "} " \
- "}" \
- "OPTIONAL { " \
- "?a rdfs:label \"Home\" . " \
- "?tmp nco:phoneNumber ?h . " \
- "OPTIONAL { ?a nco:hasEmailAddress ?e . } " \
- "OPTIONAL { ?a nco:hasPostalAddress ?p . } " \
- "OPTIONAL { ?a nco:org ?o . } " \
- "{ " \
- "SELECT ?pw ?ew ?title ?c WHERE { " \
- "?c nco:hasAffiliation ?b . " \
- "OPTIONAL {?b rdfs:label \"Work\" . " \
- "OPTIONAL {?b nco:hasEmailAddress ?ew . } " \
- "OPTIONAL {?b nco:title ?title } " \
- "OPTIONAL {?b nco:hasPostalAddress ?pw . }}} " \
- "} " \
- "}" \
+ "OPTIONAL {?a rdfs:label ?affType . }" \
+ "OPTIONAL {?a nco:hasEmailAddress ?e . } " \
+ "OPTIONAL {?a nco:hasPostalAddress ?p . }" \
+ "OPTIONAL { ?a nco:org ?o . } " \
+ "OPTIONAL { ?a nco:title ?title } " \
"OPTIONAL { ?c nco:hasPostalAddress ?po . } " \
"OPTIONAL { ?c nco:hasEmailAddress ?eo . } " \
"} UNION { " \
@@ -752,62 +595,29 @@
"OPTIONAL { ?c nco:hasEmailAddress ?eo . } " \
"OPTIONAL { " \
"?c nco:hasAffiliation ?a . " \
- "OPTIONAL { " \
- "?a rdfs:label \"Work\" . " \
- "OPTIONAL { ?a nco:hasEmailAddress ?ew . } " \
- "OPTIONAL { ?a nco:hasPostalAddress ?pw . } " \
"OPTIONAL { ?a nco:title ?title } " \
- "}" \
- "OPTIONAL { " \
- "?a rdfs:label \"Home\" . " \
"OPTIONAL { ?a nco:hasEmailAddress ?e . } " \
"OPTIONAL { ?a nco:hasPostalAddress ?p . } " \
- "} " \
"OPTIONAL { ?a nco:org ?o . } " \
"} " \
"} UNION { " \
"?x a nco:Contact . " \
- "?x nco:hasPhoneNumber ?tmp . " \
+ "?x nco:hasPhoneNumber ?ap . " \
"?call a nmo:Call ; " \
"nmo:from ?x ; " \
"nmo:isSent false . " \
"?c a nco:PersonContact . " \
"?c nco:hasAffiliation ?a . " \
- "?a nco:hasPhoneNumber ?tmp . " \
+ "?a nco:hasPhoneNumber ?ap . " \
"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 . } " \
- "OPTIONAL { ?a nco:hasPostalAddress ?pw . } " \
- "OPTIONAL { ?a nco:org ?o . } " \
- "OPTIONAL { ?a nco:title ?title } " \
- "{ " \
- "SELECT ?p ?e ?c WHERE { " \
- "?c nco:hasAffiliation ?b . " \
- "OPTIONAL {?b rdfs:label \"Home\" . " \
- "OPTIONAL {?b nco:hasEmailAddress ?e . } " \
- "OPTIONAL {?b nco:hasPostalAddress ?p . }}} " \
- "} " \
- "}" \
- "OPTIONAL { " \
- "?a rdfs:label \"Home\" . " \
- "?tmp nco:phoneNumber ?h . " \
- "OPTIONAL { ?a nco:hasEmailAddress ?e . } " \
- "OPTIONAL { ?a nco:hasPostalAddress ?p . } " \
- "OPTIONAL { ?a nco:org ?o . } " \
- "{ " \
- "SELECT ?pw ?ew ?title ?c WHERE { " \
- "?c nco:hasAffiliation ?b . " \
- "OPTIONAL {?b rdfs:label \"Work\" . " \
- "OPTIONAL {?b nco:hasEmailAddress ?ew . } " \
- "OPTIONAL {?b nco:title ?title } " \
- "OPTIONAL {?b nco:hasPostalAddress ?pw . }}} " \
- "} " \
- "}" \
+ "OPTIONAL {?a rdfs:label ?affType . }" \
+ "OPTIONAL {?a nco:hasEmailAddress ?e . } " \
+ "OPTIONAL {?a nco:hasPostalAddress ?p . }" \
+ "OPTIONAL { ?a nco:org ?o . } " \
+ "OPTIONAL { ?a nco:title ?title } " \
"OPTIONAL { ?c nco:hasPostalAddress ?po . } " \
"OPTIONAL { ?c nco:hasEmailAddress ?eo . } " \
"} UNION { " \
@@ -880,23 +690,20 @@
"} GROUP BY ?call ORDER BY DESC(nmo:receivedDate(?call))"
#define CONTACTS_QUERY_FROM_URI \
- "SELECT nco:phoneNumber(?v) nco:fullname(<%s>) " \
- "nco:nameFamily(<%s>) nco:nameGiven(<%s>) " \
- "nco:nameAdditional(<%s>) nco:nameHonorificPrefix(<%s>) " \
- "nco:nameHonorificSuffix(<%s>) nco:emailAddress(?e) " \
- "nco:phoneNumber(?w) nco:pobox(?p) nco:extendedAddress(?p) " \
+ "SELECT nco:phoneNumber(?v) nco:fullname(<%s>) " \
+ "nco:nameFamily(<%s>) nco:nameGiven(<%s>) " \
+ "nco:nameAdditional(<%s>) nco:nameHonorificPrefix(<%s>) " \
+ "nco:nameHonorificSuffix(<%s>) nco:emailAddress(?e) ?vc " \
+ "nco:pobox(?p) nco:extendedAddress(?p) " \
"nco:streetAddress(?p) nco:locality(?p) nco:region(?p) " \
- "nco:postalcode(?p) nco:country(?p) ?f nco:emailAddress(?ew) " \
+ "nco:postalcode(?p) nco:country(?p) ?f ?affType " \
"nco:birthDate(<%s>) nco:nickname(<%s>) nco:url(<%s>) " \
"?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>) " \
+ "nco:role(?a) nco:contactUID(<%s>) " \
"nco:title(?a) ?t nco:pobox(?po) nco:extendedAddress(?po) " \
"nco:streetAddress(?po) nco:locality(?po) nco:region(?po) " \
- "nco:postalcode(?po) nco:country(?po) nco:emailAddress(?eo) " \
- "?vc " \
- "\"NOTACALL\" \"false\" \"false\" <%s> " \
+ "nco:postalcode(?po) nco:country(?po) nco:emailAddress(?eo) " \
+ "\"NOTACALL\" \"false\" \"false\" <%s> " \
"WHERE { " \
"<%s> a nco:PersonContact . " \
"OPTIONAL { " \
@@ -919,16 +726,10 @@
"}" \
"OPTIONAL { " \
"<%s> nco:hasAffiliation ?a . " \
- "OPTIONAL { ?a rdfs:label \"Work\" . " \
- "OPTIONAL { ?a nco:hasEmailAddress ?ew . } " \
- "OPTIONAL { ?a nco:hasPostalAddress ?pw . } " \
- "OPTIONAL { ?a nco:hasPhoneNumber ?w . } " \
- "}" \
- "OPTIONAL { ?a rdfs:label \"Home\" . " \
+ "OPTIONAL { ?a rdfs:label ?affType .}" \
"OPTIONAL { ?a nco:hasEmailAddress ?e . } " \
"OPTIONAL { ?a nco:hasPostalAddress ?p . } " \
"OPTIONAL { ?a nco:hasPhoneNumber ?v . } " \
- "}" \
"OPTIONAL { ?a nco:org ?o . } " \
"} " \
"OPTIONAL { <%s> nco:hasPostalAddress ?po . } " \
@@ -939,7 +740,7 @@
"SELECT \"\" \"\" \"\" \"\" \"\" \"\" \"\" \"\" \"\" \"\" \"\" "\
"\"\" \"\" \"\" \"\" \"\" \"\" \"\" \"\" \"\" \"\" \"\" \"\" " \
"\"\" \"\" \"\" \"\" \"\" \"\" \"\" \"\" \"\" \"\" \"\" " \
- "\"\" \"\" \"\" \"\" \"\" \"\" \"\" \"\" \"\" " \
+ "\"\" " \
"nco:phoneNumber(?t) \"NOTACALL\" \"false\" \"false\" <%s> " \
"WHERE { " \
"<%s> a nco:Contact . " \
@@ -1491,57 +1292,75 @@ static void contact_init(struct phonebook_contact *contact, char **reply)
reply[COL_ANSWERED]);
}
+static enum phonebook_number_type get_phone_type(const char *affilation)
+{
+ if (g_strcmp0(AFFILATION_HOME, affilation) == 0)
+ return TEL_TYPE_HOME;
+ else if (g_strcmp0(AFFILATION_WORK, affilation) == 0)
+ return TEL_TYPE_WORK;
+
+ return TEL_TYPE_OTHER;
+}
+
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_PHONE_NUMBER],
+ get_phone_type(reply[COL_AFF_TYPE]));
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)
return;
- if (g_strcmp0(reply[COL_OTHER_NUMBER], reply[COL_WORK_NUMBER]) == 0)
- return;
-
- if (g_strcmp0(reply[COL_OTHER_NUMBER], reply[COL_HOME_NUMBER]) == 0)
+ if (g_strcmp0(reply[COL_OTHER_NUMBER], reply[COL_PHONE_NUMBER]) == 0)
return;
add_phone_number(contact, reply[COL_OTHER_NUMBER], TEL_TYPE_OTHER);
}
+static enum phonebook_email_type get_email_type(const char *affilation)
+{
+ if (g_strcmp0(AFFILATION_HOME, affilation) == 0)
+ return EMAIL_TYPE_HOME;
+ else if (g_strcmp0(AFFILATION_WORK, affilation) == 0)
+ return EMAIL_TYPE_WORK;
+
+ return EMAIL_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_EMAIL],
+ get_email_type(reply[COL_AFF_TYPE]));
add_email(contact, reply[COL_OTHER_EMAIL], EMAIL_TYPE_OTHER);
}
+static enum phonebook_address_type get_addr_type(const char *affilation)
+{
+ if (g_strcmp0(AFFILATION_HOME, affilation) == 0)
+ return ADDR_TYPE_HOME;
+ else if (g_strcmp0(AFFILATION_WORK, affilation) == 0)
+ return ADDR_TYPE_WORK;
+
+ return ADDR_TYPE_HOME;
+}
+
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]);
+ char *main_addr, *other_addr;
+
+ main_addr = g_strdup_printf("%s;%s;%s;%s;%s;%s;%s",
+ reply[COL_ADDR_POBOX],
+ reply[COL_ADDR_EXT],
+ reply[COL_ADDR_STREET],
+ reply[COL_ADDR_LOCALITY],
+ reply[COL_ADDR_REGION],
+ reply[COL_ADDR_CODE],
+ reply[COL_ADDR_COUNTRY]);
other_addr = g_strdup_printf("%s;%s;%s;%s;%s;%s;%s",
reply[COL_OTHER_ADDR_POBOX],
@@ -1552,12 +1371,11 @@ static void contact_add_addresses(struct phonebook_contact *contact,
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, main_addr, get_addr_type(reply[COL_AFF_TYPE]));
+
add_address(contact, other_addr, ADDR_TYPE_OTHER);
- g_free(home_addr);
- g_free(work_addr);
+ g_free(main_addr);
g_free(other_addr);
}
--
1.7.0.4
^ permalink raw reply related
* Re: [PATCH] Optimize tracker queries for PBAP
From: Johan Hedberg @ 2010-12-02 16:22 UTC (permalink / raw)
To: Radoslaw Jablonski; +Cc: linux-bluetooth
In-Reply-To: <1291305728-3463-1-git-send-email-ext-jablonski.radoslaw@nokia.com>
Hi Radek,
On Thu, Dec 02, 2010, Radoslaw Jablonski wrote:
> Now data from tracker is fetched without redundand fields. Also
> determining which type has phone, address and email (work or home) is
> done in backend code - no tracker sub-query is used for that case. Now
> queries are about 6 times faster for any amount of data( call history
> queries, which were heavy loaded with OPTIONAL sub-queries are even 10
> times faster than before)
> ---
> plugins/phonebook-tracker.c | 514 ++++++++++++++-----------------------------
> 1 files changed, 166 insertions(+), 348 deletions(-)
Pushed upstream. Thanks.
Johan
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox