* (reminder) Re: [PATCH v4] Bluetooth: btwilink driver
From: Pavan Savoy @ 2010-10-28 4:04 UTC (permalink / raw)
To: padovan, marcel; +Cc: linux-bluetooth, linux-kernel, Pavan Savoy
On Tue, Oct 19, 2010 at 6:06 PM, <pavan_savoy@ti.com> wrote:
> From: Pavan Savoy <pavan_savoy@ti.com>
>
> v4 comments
>
> module init now returns what platform_driver_register returns.
> type casting of void* private data has been removed
>
Marcel, Gustavo,
Any comments on this?
Was really hoping this would get in for 2.6.37 ...
PS:
deliberately editing the subject..
regards,
Pavan Savoy
> 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,
>
> Marcel, Gustavo, & list,
> Please review this version of patch.
>
> 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=A0411 ++++++++++++++++++++++++++=
++++++++++++++++
> =C2=A03 files changed, 422 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..218efd6
> --- /dev/null
> +++ b/drivers/bluetooth/btwilink.c
> @@ -0,0 +1,411 @@
> +/*
> + * =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;
> +};
> +
> +static int reset;
> +
> +/* 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;
> + =C2=A0 =C2=A0 =C2=A0 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 int err;
> + =C2=A0 =C2=A0 =C2=A0 struct ti_st *lhst =3D priv_data;
> +
> + =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 (struct net_device *)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) {
> + =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("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=
,
> + =C2=A0 =C2=A0 =C2=A0 .priv_data =3D NULL,
> +};
> +
> +/* 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 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 set_bit(HCI_RUNNING, &hdev->flags);
> +
> + =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 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 if (!skb)
> + =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 return -ENOMEM;
> +
> + =C2=A0 =C2=A0 =C2=A0 hdev =3D (struct hci_dev *)skb->dev;
> + =C2=A0 =C2=A0 =C2=A0 if (!hdev)
> + =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 return -ENODEV;
> +
> + =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 if (!hst->st_write) {
> + =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(" Could not wri=
te to ST (st_write is NULL)");
> + =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 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 if (!hdev)
> + =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 return;
> +
> + =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;
> +}
> +
> +/* Creates new HCI device */
> +static int ti_st_register_dev(struct ti_st *hst)
> +{
> + =C2=A0 =C2=A0 =C2=A0 int err;
> + =C2=A0 =C2=A0 =C2=A0 struct hci_dev *hdev;
> +
> + =C2=A0 =C2=A0 =C2=A0 /* Initialize and register HCI device */
> + =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 if (reset)
> + =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 set_bit(HCI_QUIRK_NO_R=
ESET, &hdev->quirks);
> +
> + =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 return 0;
> +}
> +
> +
> +static int bt_ti_probe(struct platform_device *pdev)
> +{
> + =C2=A0 =C2=A0 =C2=A0 int err;
> + =C2=A0 =C2=A0 =C2=A0 static struct ti_st *hst;
> +
> + =C2=A0 =C2=A0 =C2=A0 BT_DBG(" Bluetooth Driver Version %s", VERSION);
> +
> + =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 err =3D ti_st_register_dev(hst);
> + =C2=A0 =C2=A0 =C2=A0 if (err) {
> + =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 kfree(hst);
> + =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 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 ti_st *hst;
> + =C2=A0 =C2=A0 =C2=A0 struct hci_dev *hdev;
> +
> + =C2=A0 =C2=A0 =C2=A0 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 /* Deallocate local resource's memory =C2=A0*/
> + =C2=A0 =C2=A0 =C2=A0 hdev =3D hst->hdev;
> +
> + =C2=A0 =C2=A0 =C2=A0 if (!hdev) {
> + =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 BT_ERR("Invalid hdev m=
emory");
> + =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 kfree(hst);
> + =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 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 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 bt_drv_init(void)
> +{
> + =C2=A0 =C2=A0 =C2=A0 long ret;
> +
> + =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 bt_drv_exit(void)
> +{
> + =C2=A0 =C2=A0 =C2=A0 platform_driver_unregister(&btwilink_driver);
> +}
> +
> +module_init(bt_drv_init);
> +module_exit(bt_drv_exit);
> +
> +/* ------ Module Info ------ */
> +
> +module_param(reset, bool, 0644);
> +MODULE_PARM_DESC(reset, "Send HCI reset command on initialization");
> +MODULE_AUTHOR("Raja Mani <raja_mani@ti.com>");
> +MODULE_DESCRIPTION("Bluetooth Driver for TI Shared Transport" VERSION);
> +MODULE_VERSION(VERSION);
> +MODULE_LICENSE("GPL");
> --
> 1.6.5
>
> --
> 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: HFP Pulseaudio Source destroyed "too quickly" at the end of a call
From: Johan Hedberg @ 2010-10-27 22:26 UTC (permalink / raw)
To: Thomas Wälti; +Cc: linux-bluetooth, Krisztian.Litkey, Jyri.Sarha
In-Reply-To: <AANLkTikQqPqJdFgLpUrKiqyAC0HNUFnj+8NtbPxazY18@mail.gmail.com>
Hi Tom,
On Wed, Oct 27, 2010, Thomas Wälti wrote:
> I'm developing an application that records all kinds of audio using GStreamer.
> Target platform is the Nokia N900, the app is called Recaller
> (http://maemo.org/downloads/product/Maemo5/recaller/)
Looks like a pretty cool app!
> All works well except when ending the recording of Bluetooth
> Conversations: Once a party hangs up the call, the PulseAudio source
> and sink disappear before I can stop GStreamer recording (I'm
> listening to D-Bus events). Unfortunately, this causes my GStreamer
> pipeline to crash.
>
> Is there a way to either delay the destruction of the sink/source by
> Bluez or a D-Bus message I could intercept/attach to? How can I "win
> the race"?
Probably this isn't really BlueZ related, but the audio policy module
(on the PulseAudio side) in the N900 kicks in and requests these changes
to the audio streams. Unfortunately I'm not really an expert with that
code (and afaik the audio policy part is closed) so I can't really offer
more insight on the issue. Just speculating, but you might be able to
accomplish something by hacking in some delays into the pulse bluetooth
modules (but again, I'm not really familiar with them so this might not
be a feasible approach).
Johan
^ permalink raw reply
* Re: Downstream patches
From: Johan Hedberg @ 2010-10-27 22:16 UTC (permalink / raw)
To: Bastien Nocera; +Cc: BlueZ development, marcel
In-Reply-To: <1288202527.30124.107.camel@novo.hadess.net>
Hi Bastien,
On Wed, Oct 27, 2010, Bastien Nocera wrote:
> 0001-systemd-install-systemd-unit-files.patch installs a systemd unit,
> which, when systemd is used, replaces the udev rule to launch
> bluetoothd. This was pretty heavily tested as part of the alpha for
> Fedora 14, though systemd was not included in the end.
>
> This patch is used in Fedora 15 now.
I'll let Marcel comment on this since IIRC he had previously some issues
with systemd related patches.
> 0002-build-Fix-parallel-build.patch fixes a parallel build problem I
> encountered on my machine, running "make -j8".
This one has been pushed upstream. Thanks.
Johan
^ permalink raw reply
* RE: [RFC] LE connections and advertising management
From: Mike Tsai @ 2010-10-27 22:01 UTC (permalink / raw)
To: Claudio Takahasi; +Cc: BlueZ development
In-Reply-To: <AANLkTim7iLhzALuxX07veEwVEObwcfVFuQEpnjTVABAn@mail.gmail.com>
Hi Claudio,
-----Original Message-----
From: Claudio Takahasi [mailto:claudio.takahasi@openbossa.org]
Sent: Tuesday, October 26, 2010 6:02 PM
To: Mike Tsai
Cc: BlueZ development
Subject: Re: [RFC] LE connections and advertising management
Hi Mike,
On Tue, Oct 26, 2010 at 6:10 PM, Mike Tsai <Mike.Tsai@atheros.com> wrote:
> [Mike Tsai]
> Hi Claudio,
>
> I look at the API and it is well-defined with high level of abstraction. However, I did have a few questions here, hopefully you can answer them,
>
> On Client side:
>
> 1. I see you didn't offer any service discovery API for client to discover the server service database (basically to get the attribute handles). So I assume that you consider GATT discovery procedure works the same way as SDP, done automatically by GATT after link is established without application's initiative. Am I correct?
>
> 2. The characteristic descriptor set via SetProperty API is limited to the 6 characteristic descriptors defined in GATT spec. However, there could be profile specific characteristic descriptors beyond these, will the SetProperty able to support these?
>
> 3. The characteristic monitoring is set up via 128 bits UUID. Do you have mechanism to handle duplicated characteristic within a server's database? How do you identify them via your API?
>
>
> On Server side:
>
> 1. Is there an API that allows server application to register new attributes? (primary service, characteristic, included service, et al),
>
> Regards,
>
> Mike
Client side:
Yes. ALL characteristics are fetched after "create the device"
procedure. This approach is wrong, some characteristics requires
encryption, authentication or authorization. Another aspect is that we
need to avoid excessive transactions. The idea now is try to search
for the primary service information only and "probe" the clients that
match with the registered service UUID. When "probed" the clients will
receive the GAttrib instance and the primary service handles range. It
is up to them to decide which attributes are relevant. Note that the
clients are only another "layer" implementing profile specific
features inside BlueZ.
[Mike Tsai]Thanks for the detailed info, I know understand more about your architecture approach. More questions below:
1. So these "clients" (profiles) will be below d-bus and linked directly with GAttrib?
2. Will these clients cache the discovered attribute handles that it is interested in and respond to "service change" event sent by server? Since we really want to limit the attribute handle discovery only once (same as pairing).
3. Will these clients check the security (attribute permission) for each characteristic too?
It is a little bit unclear to me at the moment, but we can expose
Profile specific features. Such as threshold, alert level, ...
[Mike Tsai] Yes, perhaps need to open up the characteristic descriptor for client to register with GAttrib so GAttrib knows to forward to client same as existing 6 characteristic descriptors.
Is it allowed duplicated UUIDs for the same primary service? We are
not handling this right now.
It seems that you already have a proprietary implementation ;-)
[Mike Tsai] I think it is probably not allowed to duplicate characteristic within the same primary services. However, there may be duplicated primary services within a server or duplicated included service within a server, or same characteristic inside 2 different primary services. So I don't know if you have any mechanism to let GAttrib get the correct characteristic within all these duplicated services by just passing the 128 bits UUID?
Server side:
No API. We wrote an attribute server for testing purpose only. But we
will address this soon.
Regards,
Claudio
^ permalink raw reply
* HFP Pulseaudio Source destroyed "too quickly" at the end of a call
From: Thomas Wälti @ 2010-10-27 20:03 UTC (permalink / raw)
To: linux-bluetooth
Hello all
I'm developing an application that records all kinds of audio using GStreamer.
Target platform is the Nokia N900, the app is called Recaller
(http://maemo.org/downloads/product/Maemo5/recaller/)
All works well except when ending the recording of Bluetooth
Conversations: Once a party hangs up the call, the PulseAudio source
and sink disappear before I can stop GStreamer recording (I'm
listening to D-Bus events). Unfortunately, this causes my GStreamer
pipeline to crash.
Is there a way to either delay the destruction of the sink/source by
Bluez or a D-Bus message I could intercept/attach to? How can I "win
the race"?
Thank you for your support and hints (and for the outstanding work you
all do on Bluez - a fascinating part of the Linux ecosystem!)
-Tom
^ permalink raw reply
* Re: [PATCH 5/6] Bluetooth: Add server socket support for LE connection
From: Anderson Lizardo @ 2010-10-27 19:09 UTC (permalink / raw)
To: Ville Tervo; +Cc: linux-bluetooth
In-Reply-To: <1288009280-5149-6-git-send-email-ville.tervo@nokia.com>
On Mon, Oct 25, 2010 at 8:21 AM, Ville Tervo <ville.tervo@nokia.com> wrote:
> +static void l2cap_le_conn_ready(struct l2cap_conn *conn)
> +{
> + struct l2cap_chan_list *list = &conn->chan_list;
> + struct sock *parent, *uninitialized_var(sk);
> +
> + BT_DBG("");
> +
> + /* Check if we have socket listening on cid */
> + parent = l2cap_get_sock_by_cid(BT_LISTEN, 0x04, conn->src);
You can use L2CAP_CID_LE_DATA instead of 0x04.
Regards,
--
Anderson Lizardo
OpenBossa Labs - INdT
Manaus - Brazil
^ permalink raw reply
* Re: [PATCH v2] Fix obexd crash for empty listing invalid cache
From: Johan Hedberg @ 2010-10-27 19:03 UTC (permalink / raw)
To: Dmitriy Paliy; +Cc: linux-bluetooth
In-Reply-To: <1288202201-861-1-git-send-email-dmitriy.paliy@nokia.com>
Hi Dmitriy,
On Wed, Oct 27, 2010, Dmitriy Paliy wrote:
> This fixes obexd crash in 3-way calling scenario when listing response is
> empty. Valid cache and empty pbap buffer mean that cache was already attempted
> to be created within a single session, but no data was available. Hence, it
> is not notified and no such file error returned. New cache is not created
> within current obex session or unless path is changed. Such removes necessity
> of querying and filtering contacts for each incoming call in the other case,
> which is extensive for large phone books. On the other hand, if user updates
> contacts, cache will not be renewed till obex session is closed or path is
> changed. Therefore TODO: note is added that clear of cache should be defined
> besides of end of session or change of path.
The commit message seems to have a max width of 78 characters which
means that it's not viewable with git log on a 80 character terminal
(git log indents the output by 4 characters). Please keep the max commit
message width to 74 characters or so. Also, if possible try to split it
up into multiple paragraphs. Paragraphs longer than 6 lines tend to be a
bit harder to follow.
> + * TODO: Define clear cache besides end of session or change
> + * of path.
That doesn't sound like proper english to me and I'm not sure what
you're trying to say. Should it be "Define a clear distinction between
end of session and change of path"?
Johan
^ permalink raw reply
* Downstream patches
From: Bastien Nocera @ 2010-10-27 18:02 UTC (permalink / raw)
To: BlueZ development
[-- Attachment #1: Type: text/plain, Size: 467 bytes --]
Heya,
2 small patches for the current master.
0001-systemd-install-systemd-unit-files.patch installs a systemd unit,
which, when systemd is used, replaces the udev rule to launch
bluetoothd. This was pretty heavily tested as part of the alpha for
Fedora 14, though systemd was not included in the end.
This patch is used in Fedora 15 now.
0002-build-Fix-parallel-build.patch fixes a parallel build problem I
encountered on my machine, running "make -j8".
Cheers
[-- Attachment #2: 0001-systemd-install-systemd-unit-files.patch --]
[-- Type: text/x-patch, Size: 3847 bytes --]
>From b3483ab0b821d29bbeb6aa5630b36bc126a89441 Mon Sep 17 00:00:00 2001
From: Lennart Poettering <lennart@poettering.net>
Date: Wed, 21 Jul 2010 19:20:44 +0200
Subject: [PATCH 3/3] systemd: install systemd unit files
This also enables bus activation for bluetoothd, but only if systemd is
running. Only if that's the case we can make sure in a race-free fashion
that bluetoothd is not started twice at the same time.
---
Makefile.am | 21 ++++++++++++++++++---
configure.ac | 9 +++++++++
scripts/.gitignore | 1 +
scripts/bluetooth.service.in | 12 ++++++++++++
scripts/org.bluez.service | 5 +++++
5 files changed, 45 insertions(+), 3 deletions(-)
create mode 100644 scripts/.gitignore
create mode 100644 scripts/bluetooth.service.in
create mode 100644 scripts/org.bluez.service
diff --git a/Makefile.am b/Makefile.am
index e855713..1edd6a2 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -344,7 +344,8 @@ endif
CLEANFILES += $(rules_DATA)
EXTRA_DIST += scripts/bluetooth.rules \
- scripts/bluetooth-hid2hci.rules scripts/bluetooth-serial.rules
+ scripts/bluetooth-hid2hci.rules scripts/bluetooth-serial.rules \
+ scripts/bluetooth.service.in scripts/org.bluez.service
if PCMCIA
udevdir = $(libexecdir)/udev
@@ -352,6 +353,20 @@ udevdir = $(libexecdir)/udev
dist_udev_SCRIPTS = scripts/bluetooth_serial
endif
+if HAVE_SYSTEMD
+systemdsystemunit_DATA = \
+ scripts/bluetooth.service
+
+scripts/bluetooth.service: scripts/bluetooth.service.in
+ @$(SED) -e "s|\@sbindir\@|$(sbindir)|" $< >$@
+
+dbussystemservicesdir = $(datadir)/dbus-1/system-services
+
+dbussystemservices_DATA = \
+ scripts/org.bluez.service
+
+endif
+
EXTRA_DIST += doc/manager-api.txt \
doc/adapter-api.txt doc/device-api.txt \
doc/service-api.txt doc/agent-api.txt doc/attribute-api.txt \
@@ -376,9 +391,9 @@ pkgconfigdir = $(libdir)/pkgconfig
pkgconfig_DATA = bluez.pc
-DISTCHECK_CONFIGURE_FLAGS = --disable-udevrules --enable-attrib
+DISTCHECK_CONFIGURE_FLAGS = --disable-udevrules --enable-attrib --with-systemdsystemunitdir=
-DISTCLEANFILES = $(pkgconfig_DATA)
+DISTCLEANFILES = $(pkgconfig_DATA) scripts/bluetooth.service
MAINTAINERCLEANFILES = Makefile.in \
aclocal.m4 configure config.h.in config.sub config.guess \
diff --git a/configure.ac b/configure.ac
index d375ac9..6619a42 100644
--- a/configure.ac
+++ b/configure.ac
@@ -56,5 +56,14 @@ if (test "${enable_capng}" = "yes"); then
AC_DEFINE(HAVE_CAPNG, 1, [Define to 1 if you have capabilities library.])
fi
+# systemd
+
+AC_ARG_WITH([systemdsystemunitdir],
+ AS_HELP_STRING([--with-systemdsystemunitdir=DIR], [Directory for systemd service files]),
+ [],
+ [with_systemdsystemunitdir=$($PKG_CONFIG --variable=systemdsystemunitdir systemd)])
+AC_SUBST([systemdsystemunitdir], [$with_systemdsystemunitdir])
+AM_CONDITIONAL(HAVE_SYSTEMD, [test -n "$with_systemdsystemunitdir"])
+
AC_OUTPUT(Makefile scripts/bluetooth.rules doc/version.xml
src/bluetoothd.8 bluez.pc)
diff --git a/scripts/.gitignore b/scripts/.gitignore
new file mode 100644
index 0000000..4b9f765
--- /dev/null
+++ b/scripts/.gitignore
@@ -0,0 +1 @@
+bluetooth.service
diff --git a/scripts/bluetooth.service.in b/scripts/bluetooth.service.in
new file mode 100644
index 0000000..f95b0b0
--- /dev/null
+++ b/scripts/bluetooth.service.in
@@ -0,0 +1,12 @@
+[Unit]
+Description=Bluetooth Manager
+After=syslog.target
+
+[Service]
+Type=dbus
+BusName=org.bluez
+ExecStart=@sbindir@/bluetoothd -n
+StandardOutput=syslog
+
+[Install]
+WantedBy=bluetooth.target
diff --git a/scripts/org.bluez.service b/scripts/org.bluez.service
new file mode 100644
index 0000000..2a3b057
--- /dev/null
+++ b/scripts/org.bluez.service
@@ -0,0 +1,5 @@
+[D-BUS Service]
+Name=org.bluez
+Exec=/bin/false
+User=root
+SystemdService=bluetooth.service
--
1.7.3.1
[-- Attachment #3: 0002-build-Fix-parallel-build.patch --]
[-- Type: text/x-patch, Size: 1058 bytes --]
>From ad21a880935863d3592cae708147ef54c796222d Mon Sep 17 00:00:00 2001
From: Bastien Nocera <hadess@hadess.net>
Date: Wed, 27 Oct 2010 18:54:49 +0100
Subject: [PATCH 2/3] build: Fix parallel build
Fix parallel build where parser.h won't have been generated when
we're trying to compile kword itself.
YACC tools/parser.c
LEX tools/lexer.c
conflicts: 3 shift/reduce
CC tools/kword.o
tools/kword.c:36:20: fatal error: parser.h: No such file or directory
compilation terminated.
---
Makefile.tools | 2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/Makefile.tools b/Makefile.tools
index 405a42b..797b53d 100644
--- a/Makefile.tools
+++ b/Makefile.tools
@@ -12,6 +12,8 @@ sbin_PROGRAMS += tools/hciattach tools/hciconfig
noinst_PROGRAMS += tools/avinfo tools/ppporc \
tools/hcieventmask tools/hcisecfilter
+tools/kword.c: tools/parser.h
+
tools_rfcomm_SOURCES = tools/main.c tools/parser.y tools/lexer.l \
tools/kword.h tools/kword.c
EXTRA_tools_rfcomm_SOURCES = tools/parser.h tools/parser.c \
--
1.7.3.1
^ permalink raw reply related
* [PATCH v2] Fix obexd crash for empty listing invalid cache
From: Dmitriy Paliy @ 2010-10-27 17:56 UTC (permalink / raw)
To: linux-bluetooth; +Cc: Dmitriy Paliy
This fixes obexd crash in 3-way calling scenario when listing response is
empty. Valid cache and empty pbap buffer mean that cache was already attempted
to be created within a single session, but no data was available. Hence, it
is not notified and no such file error returned. New cache is not created
within current obex session or unless path is changed. Such removes necessity
of querying and filtering contacts for each incoming call in the other case,
which is extensive for large phone books. On the other hand, if user updates
contacts, cache will not be renewed till obex session is closed or path is
changed. Therefore TODO: note is added that clear of cache should be defined
besides of end of session or change of path.
---
plugins/pbap.c | 14 ++++++++++++++
1 files changed, 14 insertions(+), 0 deletions(-)
diff --git a/plugins/pbap.c b/plugins/pbap.c
index 11cb678..2a90d4d 100644
--- a/plugins/pbap.c
+++ b/plugins/pbap.c
@@ -751,6 +751,20 @@ static void *vobject_list_open(const char *name, int oflag, mode_t mode,
/* PullvCardListing always get the contacts from the cache */
if (pbap->cache.valid) {
+ /*
+ * Valid cache and empty buffer mean that cache was already
+ * created within a single session, but no data is available.
+ * New cache will not be created in current obex session or
+ * unless path is changed. If user updates contacts, cache
+ * will not be renewed, and, therefore:
+ * TODO: Define clear cache besides end of session or change
+ * of path.
+ */
+ if (!pbap->buffer) {
+ ret = -ENOENT;
+ goto fail;
+ }
+
cache_ready_notify(pbap);
goto done;
}
--
1.7.0.4
^ permalink raw reply related
* [PATCH] Bluetooth: Automate remote name requests
From: johan.hedberg @ 2010-10-27 16:25 UTC (permalink / raw)
To: linux-bluetooth; +Cc: Johan Hedberg
From: Johan Hedberg <johan.hedberg@nokia.com>
In Bluetooth there are no automatic updates of remote device names when
they get changed on the remote side. Instead, it is a good idea to do a
manual name request when a new connection gets created (for whatever
reason) since at this point it is very cheap (no costly baseband
connection creation needed just for the sake of the name request).
So far userspace has been responsible for this extra name request but
tighter control is needed in order not to flood Bluetooth controllers
with two many commands during connection creation. It has been shown
that some controllers simply fail to function correctly if they get too
many (almost) simultaneous commands during connection creation. The
simplest way to acheive better control of these commands is to move
their sending completely to the kernel side.
This patch inserts name requests into the sequence of events that the
kernel performs during connection creation. It does this after the
remote features have been successfully requested and before any pending
authentication requests are performed. The code will work sub-optimally
with userspace versions that still do the name requesting themselves (it
shouldn't break anything though) so it is recommended to combine this
with a userspace software version that doesn't have automated name
requests.
Signed-off-by: Johan Hedberg <johan.hedberg@nokia.com>
---
net/bluetooth/hci_event.c | 66 ++++++++++++++++++++++++++++++++++++++++----
1 files changed, 60 insertions(+), 6 deletions(-)
diff --git a/net/bluetooth/hci_event.c b/net/bluetooth/hci_event.c
index 84093b0..05ad699 100644
--- a/net/bluetooth/hci_event.c
+++ b/net/bluetooth/hci_event.c
@@ -677,9 +677,51 @@ static void hci_cs_set_conn_encrypt(struct hci_dev *hdev, __u8 status)
hci_dev_unlock(hdev);
}
+static void request_outgoing_auth(struct hci_dev *hdev, bdaddr_t *bdaddr)
+{
+ struct hci_cp_auth_requested cp;
+ struct hci_conn *conn;
+
+ conn = hci_conn_hash_lookup_ba(hdev, ACL_LINK, bdaddr);
+ if (!conn)
+ return;
+
+ if (conn->state != BT_CONFIG || !conn->out)
+ return;
+
+ if (conn->sec_level == BT_SECURITY_SDP)
+ return;
+
+ /* Only request authentication for SSP connections or non-SSP
+ * devices with sec_level HIGH */
+ if (!(hdev->ssp_mode > 0 && conn->ssp_mode > 0) &&
+ conn->sec_level != BT_SECURITY_HIGH)
+ return;
+
+ cp.handle = __cpu_to_le16(conn->handle);
+ hci_send_cmd(hdev, HCI_OP_AUTH_REQUESTED, sizeof(cp), &cp);
+}
+
static void hci_cs_remote_name_req(struct hci_dev *hdev, __u8 status)
{
+ struct hci_cp_remote_name_req *cp;
+
BT_DBG("%s status 0x%x", hdev->name, status);
+
+ /* If successful wait for the name req complete event before
+ * checking for the need to do authentication */
+ if (status == 0)
+ return;
+
+ cp = hci_sent_cmd_data(hdev, HCI_OP_REMOTE_NAME_REQ);
+ if (!cp)
+ return;
+
+ hci_dev_lock(hdev);
+
+ request_outgoing_auth(hdev, &cp->bdaddr);
+
+ hci_dev_unlock(hdev);
}
static void hci_cs_read_remote_features(struct hci_dev *hdev, __u8 status)
@@ -1090,9 +1132,17 @@ static inline void hci_auth_complete_evt(struct hci_dev *hdev, struct sk_buff *s
static inline void hci_remote_name_evt(struct hci_dev *hdev, struct sk_buff *skb)
{
+ struct hci_ev_remote_name *ev = (void *) skb->data;
+
BT_DBG("%s", hdev->name);
hci_conn_check_pending(hdev);
+
+ hci_dev_lock(hdev);
+
+ request_outgoing_auth(hdev, &ev->bdaddr);
+
+ hci_dev_unlock(hdev);
}
static inline void hci_encrypt_change_evt(struct hci_dev *hdev, struct sk_buff *skb)
@@ -1177,9 +1227,11 @@ static inline void hci_remote_features_evt(struct hci_dev *hdev, struct sk_buff
sizeof(cp), &cp);
} else if (!ev->status && conn->out &&
conn->sec_level == BT_SECURITY_HIGH) {
- struct hci_cp_auth_requested cp;
- cp.handle = ev->handle;
- hci_send_cmd(hdev, HCI_OP_AUTH_REQUESTED,
+ struct hci_cp_remote_name_req cp;
+ memset(&cp, 0, sizeof(cp));
+ bacpy(&cp.bdaddr, &conn->dst);
+ cp.pscan_rep_mode = 0x02;
+ hci_send_cmd(hdev, HCI_OP_REMOTE_NAME_REQ,
sizeof(cp), &cp);
} else {
conn->state = BT_CONNECTED;
@@ -1660,9 +1712,11 @@ static inline void hci_remote_ext_features_evt(struct hci_dev *hdev, struct sk_b
if (!ev->status && hdev->ssp_mode > 0 &&
conn->ssp_mode > 0 && conn->out &&
conn->sec_level != BT_SECURITY_SDP) {
- struct hci_cp_auth_requested cp;
- cp.handle = ev->handle;
- hci_send_cmd(hdev, HCI_OP_AUTH_REQUESTED,
+ struct hci_cp_remote_name_req cp;
+ memset(&cp, 0, sizeof(cp));
+ bacpy(&cp.bdaddr, &conn->dst);
+ cp.pscan_rep_mode = 0x02;
+ hci_send_cmd(hdev, HCI_OP_REMOTE_NAME_REQ,
sizeof(cp), &cp);
} else {
conn->state = BT_CONNECTED;
--
1.7.1
^ permalink raw reply related
* Re: [PATCH 1/9] mfd: Add support for the ST-Ericsson CG2900.
From: Linus Walleij @ 2010-10-27 14:58 UTC (permalink / raw)
To: Arnd Bergmann; +Cc: Par-Gunnar Hjalmdahl, linux-bluetooth, linux-kernel
In-Reply-To: <201010261406.10996.arnd@arndb.de>
2010/10/26 Arnd Bergmann <arnd@arndb.de>:
> If CG2900 is a single
> piece of silicon that always looks the same way, it's probably an MFD.
It is:
http://www.stericsson.com/product/223489.jsp
So atleast we have that part right :-)
(And thanks for all the good feedback Arnd, really appreciated!)
Yours,
Linus Walleij
^ permalink raw reply
* Re: [PATCH 2/2] Remove redundant code in phonebook module
From: Johan Hedberg @ 2010-10-27 13:51 UTC (permalink / raw)
To: Rafał Michalski; +Cc: linux-bluetooth
In-Reply-To: <AANLkTinnbp6DFvivhX1WC6cvE5G1tzTSV5VhNNphieqn@mail.gmail.com>
Hi Rafal,
On Wed, Oct 27, 2010, Rafał Michalski wrote:
> Some extra code is redundant and not needed anymore. It is an effect
> of call history queries optimization.
> ---
> plugins/phonebook-tracker.c | 18 ++----------------
> 1 files changed, 2 insertions(+), 16 deletions(-)
This patch has also been pushed upstream. Thanks.
Johan
^ permalink raw reply
* Re: [PATCH 1/2] Optimize call history queries
From: Johan Hedberg @ 2010-10-27 13:49 UTC (permalink / raw)
To: Rafał Michalski; +Cc: linux-bluetooth
In-Reply-To: <AANLkTikwCntXxSzqc1VpA1L27UChsHK=GLmhcHXb8coX@mail.gmail.com>
Hi Rafal,
On Wed, Oct 27, 2010, Rafał Michalski wrote:
> This patch optimizes call history queries - now there is no redundant
> results of invoking them.
> ---
> plugins/phonebook-tracker.c | 74 ++++++++++++++++++++----------------------
> 1 files changed, 35 insertions(+), 39 deletions(-)
Pushed upstream. Thanks. Btw, if possible please send the patches in the
message body instead of an attachment (use e.g. git send-email for
this). This would make your patch submissions more consistent with the
rest and ease my work (by not having to always check if I should pipe
the main message or the attachment to git am).
Johan
^ permalink raw reply
* [PATCH 2/2] Remove redundant code in phonebook module
From: Rafał Michalski @ 2010-10-27 8:53 UTC (permalink / raw)
To: linux-bluetooth; +Cc: Rafał Michalski
[-- Attachment #1: Type: text/plain, Size: 1 bytes --]
[-- Attachment #2: 0002-Remove-redundant-code-in-phonebook-module.patch --]
[-- Type: text/x-patch, Size: 1448 bytes --]
From 93465ab642893a508b8543edc4919a1bcd47436b Mon Sep 17 00:00:00 2001
From: Rafal Michalski <michalski.raf@gmail.com>
Date: Wed, 27 Oct 2010 09:20:00 +0200
Subject: [PATCH 2/2] Remove redundant code in phonebook module
Some extra code is redundant and not needed anymore. It is an effect
of call history queries optimization.
---
plugins/phonebook-tracker.c | 18 ++----------------
1 files changed, 2 insertions(+), 16 deletions(-)
diff --git a/plugins/phonebook-tracker.c b/plugins/phonebook-tracker.c
index e037677..96290a4 100644
--- a/plugins/phonebook-tracker.c
+++ b/plugins/phonebook-tracker.c
@@ -949,24 +949,10 @@ static struct phonebook_contact *find_contact(GSList *contacts, const char *id)
static struct phonebook_number *find_phone(GSList *numbers, const char *phone,
int type)
{
- GSList *l = numbers;
+ GSList *l;
struct phonebook_number *pb_num;
- if (g_slist_length(l) == 1 && (pb_num = l->data) &&
- g_strcmp0(pb_num->tel, phone) == 0) {
-
- if ((type == TEL_TYPE_HOME || type == TEL_TYPE_WORK) &&
- pb_num->type == TEL_TYPE_OTHER) {
- pb_num->type = type;
- return pb_num;
- }
-
- if (type == TEL_TYPE_OTHER && (pb_num->type == TEL_TYPE_HOME ||
- pb_num->type == TEL_TYPE_WORK))
- return pb_num;
- }
-
- for (; l; l = l->next) {
+ for (l = numbers; l; l = l->next) {
pb_num = l->data;
/* Returning phonebook number if phone values and type values
* are equal */
--
1.6.3.3
^ permalink raw reply related
* [PATCH 1/2] Optimize call history queries
From: Rafał Michalski @ 2010-10-27 8:53 UTC (permalink / raw)
To: linux-bluetooth; +Cc: Rafał Michalski
[-- Attachment #1: Type: text/plain, Size: 1 bytes --]
[-- Attachment #2: 0001-Optimize-call-history-queries.patch --]
[-- Type: text/x-patch, Size: 5575 bytes --]
From 59bad107ec51e6824b0c4450f4c67ab1e4505cff Mon Sep 17 00:00:00 2001
From: Rafal Michalski <michalski.raf@gmail.com>
Date: Wed, 27 Oct 2010 09:19:21 +0200
Subject: [PATCH 1/2] Optimize call history queries
This patch optimizes call history queries - now there is no redundant
results of invoking them.
---
plugins/phonebook-tracker.c | 74 ++++++++++++++++++++----------------------
1 files changed, 35 insertions(+), 39 deletions(-)
diff --git a/plugins/phonebook-tracker.c b/plugins/phonebook-tracker.c
index 3367e49..e037677 100644
--- a/plugins/phonebook-tracker.c
+++ b/plugins/phonebook-tracker.c
@@ -128,6 +128,13 @@
"WHERE { " \
"{ " \
"?x a nco:Contact . " \
+ "?x nco:hasPhoneNumber ?t . " \
+ "?call a nmo:Call ; " \
+ "nmo:from ?x ; " \
+ "nmo:isSent false ; " \
+ "nmo:isAnswered false . " \
+ "} UNION { " \
+ "?x a nco:Contact . " \
"?x nco:hasPhoneNumber ?h . " \
"?call a nmo:Call ; " \
"nmo:from ?x ; " \
@@ -158,15 +165,8 @@
"OPTIONAL { ?a nco:hasEmailAddress ?ew . } " \
"OPTIONAL { ?a nco:hasPostalAddress ?pw . } " \
"OPTIONAL { ?a nco:org ?o . } " \
- "} UNION { " \
- "?x a nco:Contact . " \
- "?x nco:hasPhoneNumber ?t . " \
- "?call a nmo:Call ; " \
- "nmo:from ?x ; " \
- "nmo:isSent false ; " \
- "nmo:isAnswered false . " \
"} " \
- "} ORDER BY DESC(nmo:receivedDate(?call)) "
+ "} GROUP BY ?call ORDER BY DESC(nmo:receivedDate(?call)) "
#define MISSED_CALLS_LIST \
"SELECT ?c nco:nameFamily(?c) " \
@@ -221,6 +221,13 @@
"WHERE { " \
"{ " \
"?x a nco:Contact . " \
+ "?x nco:hasPhoneNumber ?t . " \
+ "?call a nmo:Call ; " \
+ "nmo:from ?x ; " \
+ "nmo:isSent false ; " \
+ "nmo:isAnswered true . " \
+ "} UNION { " \
+ "?x a nco:Contact . " \
"?x nco:hasPhoneNumber ?h . " \
"?call a nmo:Call ; " \
"nmo:from ?x ; " \
@@ -251,15 +258,8 @@
"OPTIONAL { ?a nco:hasEmailAddress ?ew . } " \
"OPTIONAL { ?a nco:hasPostalAddress ?pw . } " \
"OPTIONAL { ?a nco:org ?o . } " \
- "} UNION { " \
- "?x a nco:Contact . " \
- "?x nco:hasPhoneNumber ?t . " \
- "?call a nmo:Call ; " \
- "nmo:from ?x ; " \
- "nmo:isSent false ; " \
- "nmo:isAnswered true . " \
"} " \
- "} ORDER BY DESC(nmo:receivedDate(?call)) "
+ "} GROUP BY ?call ORDER BY DESC(nmo:receivedDate(?call)) "
#define INCOMING_CALLS_LIST \
"SELECT ?c nco:nameFamily(?c) " \
@@ -314,6 +314,12 @@
"WHERE { " \
"{ " \
"?x a nco:Contact . " \
+ "?x nco:hasPhoneNumber ?t . " \
+ "?call a nmo:Call ; " \
+ "nmo:to ?x ; " \
+ "nmo:isSent true . " \
+ "} UNION { " \
+ "?x a nco:Contact . " \
"?x nco:hasPhoneNumber ?h . " \
"?call a nmo:Call ; " \
"nmo:to ?x ; " \
@@ -342,14 +348,8 @@
"OPTIONAL { ?a nco:hasEmailAddress ?ew . } " \
"OPTIONAL { ?a nco:hasPostalAddress ?pw . } " \
"OPTIONAL { ?a nco:org ?o . } " \
- "} UNION { " \
- "?x a nco:Contact . " \
- "?x nco:hasPhoneNumber ?t . " \
- "?call a nmo:Call ; " \
- "nmo:to ?x ; " \
- "nmo:isSent true . " \
"} " \
- "} ORDER BY DESC(nmo:sentDate(?call)) "
+ "} GROUP BY ?call ORDER BY DESC(nmo:sentDate(?call)) "
#define OUTGOING_CALLS_LIST \
"SELECT ?c nco:nameFamily(?c) " \
@@ -400,7 +400,12 @@
"nmo:isSent(?call) nmo:isAnswered(?call) ?x " \
"WHERE { " \
"{ " \
- "{ " \
+ "?x a nco:Contact . " \
+ "?x nco:hasPhoneNumber ?t . " \
+ "?call a nmo:Call ; " \
+ "nmo:to ?x ; " \
+ "nmo:isSent true . " \
+ "} UNION { " \
"?x a nco:Contact . " \
"?x nco:hasPhoneNumber ?h . " \
"?call a nmo:Call ; " \
@@ -416,7 +421,7 @@
"OPTIONAL { ?a nco:hasPostalAddress ?pw . } " \
"OPTIONAL { ?a nco:org ?o . } " \
"} " \
- "} UNION { " \
+ "} UNION { " \
"?x a nco:Contact . " \
"?x nco:hasPhoneNumber ?w . " \
"?call a nmo:Call ; " \
@@ -430,15 +435,13 @@
"OPTIONAL { ?a nco:hasEmailAddress ?ew . } " \
"OPTIONAL { ?a nco:hasPostalAddress ?pw . } " \
"OPTIONAL { ?a nco:org ?o . } " \
- "} UNION { " \
+ "} UNION { " \
"?x a nco:Contact . " \
"?x nco:hasPhoneNumber ?t . " \
"?call a nmo:Call ; " \
- "nmo:to ?x ; " \
- "nmo:isSent true . " \
- "} " \
+ "nmo:from ?x ; " \
+ "nmo:isSent false . " \
"} UNION { " \
- "{ " \
"?x a nco:Contact . " \
"?x nco:hasPhoneNumber ?h . " \
"?call a nmo:Call ; " \
@@ -454,7 +457,7 @@
"OPTIONAL { ?a nco:hasPostalAddress ?pw . } " \
"OPTIONAL { ?a nco:org ?o . } " \
"} " \
- "} UNION { " \
+ "} UNION { " \
"?x a nco:Contact . " \
"?x nco:hasPhoneNumber ?w . " \
"?call a nmo:Call ; " \
@@ -468,15 +471,8 @@
"OPTIONAL { ?a nco:hasEmailAddress ?ew . } " \
"OPTIONAL { ?a nco:hasPostalAddress ?pw . } " \
"OPTIONAL { ?a nco:org ?o . } " \
- "} UNION { " \
- "?x a nco:Contact . " \
- "?x nco:hasPhoneNumber ?t . " \
- "?call a nmo:Call ; " \
- "nmo:from ?x ; " \
- "nmo:isSent false . " \
- "} " \
"} " \
- "} ORDER BY DESC(nmo:receivedDate(?call)) "
+ "} GROUP BY ?call ORDER BY DESC(nmo:receivedDate(?call)) "
#define COMBINED_CALLS_LIST \
"SELECT ?c nco:nameFamily(?c) nco:nameGiven(?c) " \
--
1.6.3.3
^ permalink raw reply related
* Re: AVRCP 1.4 : Future on Target Role
From: shivendra.agrawal@stericsson.com @ 2010-10-27 8:46 UTC (permalink / raw)
To: linux-bluetooth
In-Reply-To: <AANLkTi=ThA2ojhj8PBHK_VybmFcHO91K0g=y7nhfTBAO@mail.gmail.com>
2010/10/23 João Paulo Rechi Vita <jprvita@gmail.com>:
> Hello all,
>
> I've seen some discuss regarding how to add support for AVRCP 1.3 and
> 1.4 versions on the ML lately, and some expectations over the related
> work I've done in BlueZ. Sorry for the long delay on replying, I've
> been pretty busy lately and just didn't got the time. I'm planing to
> put some effort again on this work on the coming weeks.
>
> On Tue, Oct 19, 2010 at 14:14, Luiz Augusto von Dentz
> <luiz.dentz@gmail.com> wrote:
>> Hi,
>>
>> On Tue, Oct 19, 2010 at 12:47 PM, Sander van Grieken
>> <sander@outrightsolutions.nl> wrote:
>>> I am very much in favor of not directly depending on MPRIS, but instead letting
>>> applications registering themselves as a target. For two reasons:
>>>
>>> - AVRCP seems to be a superset of MPRIS (which is very limited IMO), and might have
>>> different semantics, especially w.r.t. event notifications. So we would limit ourselves to
>>> the intersecting subset of both technologies.
>>> - A separate AVRCP/TG <-> MPRIS bridge agent would still allow controlling all MPRIS-
>>> enabled players, so we can have both full implementation of the AVRCP spec, AND generic
>>> MPRIS support.
>>
>> Sounds good to me, we can use Media API to register players as well.
>>
>
> I agree with Sander's opinion that MPRIS seems a bit limited for 1.4.
> OTOH it's an already defined and under-adoption standard. If we have
> applications registering themselves directly with us, we'll have to
> define a new interface for that and push this to the player
> applications. Do you guys already have a draft of these interfaces
> (for the applications and extensions to the Media API)? I guess we
> should try to define exactly what we need first, and them see what's
> missing from MPRIS.
>
>>>> > I am keen to receive your feedback with some ideas and thoughts to put
>>>> > my effort in right direction.
>>>> >
>>>> > Question:
>>>> > Is anyone working on AVRCP 1.4 Target role profile development?
>>>>
>>>> Joao Paulo (http://jprvita.wordpress.com/2010/07/22/avrcp-metadata/)
>>>
>>> Actually, the metadata work is not part of v1.4 of the spec, but 1.3
>>>
>>> Second, I have already added some boilerplate stuff (like a DBUS Connect method for RCP and
>>> some fixes for CT commands), but I've based on Joao's branch, so I have to wait until his
>>> stuff gets merged. Alternatively, I could rebase that stuff on HEAD, but that would overlap
>>> and conflict with Joao's stuff, so I'm hesitant to go there.
>>
>
> Have you published this code somewhere?
>
>> I hope to see this code being push upstream soon, I will try to
>> contact Joao Paulo to get an idea if the code is ready to be
>> reviewed/pushed so we get the things rolling.
>>
>
> I'm finally here :) I've focused mostly in the 1.3 version of the spec
> and having pulseaudio as a middle-man in my work, and have written
> most of the code in pulseaudio to handle these new functionality. Even
> if we take the approach described above for 1.4, IMO it makes sense to
> upstream this so we can have earlier support for 1.3 and also to
> support Sander's work. Luiz, Johan, what do you think?
>
> I'll review the code once more, since I've written it a few months
> ago, but my main concern about pushing it upstream right now is that
> it hasn't been tested yet. I have no device to test against and PTS
> can't give us no guarantee whether the code really works in practice
> or not (but it's still better than nothing). Sander, David, have you
> tested my code against any real device?
>
I have requested some inputs from all to start exchange our ideas as
Subject: [RFC] AVRCP 1.4 : Design proposal for future on Target Role
I would be keen to receive your feedback. Thanks in advance.
^ permalink raw reply
* [RFC] AVRCP 1.4 : Design proposal for future on Target Role
From: shivendra.agrawal@stericsson.com @ 2010-10-27 8:23 UTC (permalink / raw)
To: linux-bluetooth
Hi All,
ST-Ericsson plans to implement the commands to support target role of
AVRCP 1.4 Profile, and we would like to contribute it to BlueZ.
With our initial discussion, I would be aligning with BlueZ
contributors and would propose for the ideas that has not been
touched/developed so far, in order to have a design/implementation
that can be accepted.
As a very first, and very rough, design proposal for the BlueZ parts:
- A new SDP record for AVRCP 1.4 would be added to inform CT of the
version and features supported by target.
- A new callback to accept browsing channel establishment.
- Enhancing similar to bt_io_listen for browsing PSM.
- A new browsing command handler
- Incremental addition to AVRCP 1.4 commands.
Any feedback is very much appreciated!
Ref: Previous discussion subject: "AVRCP 1.4 : Future on Target Role"
Regards,
Shivendra
^ permalink raw reply
* Re: AVRCP 1.4 : Future on Target Role
From: Gustavo F. Padovan @ 2010-10-27 7:33 UTC (permalink / raw)
To: shivendra.agrawal@stericsson.com; +Cc: linux-bluetooth
In-Reply-To: <AANLkTinodSvkAffPKrHT_Yd9nwXwAdQoqacD9vJt-F96@mail.gmail.com>
Hi Shivendra,
* shivendra.agrawal@stericsson.com <ag.shivendra@gmail.com> [2010-10-27 12:27:54 +0530]:
> Hi All,
>
> ST-Ericsson plans to implement the commands to support target role of
> AVRCP 1.4 Profile, and we would like to contribute it to BlueZ.
> With our initial discussion, I would be aligning with BlueZ
> contributors and would propose for the ideas that has not been
> touched/developed so far, in order to have a design/implementation
> that can be accepted.
>
> As a very first, and very rough, design proposal for the BlueZ parts:
> - A new SDP record for AVRCP 1.4 would be added to inform CT of the
> version and features supported by target.
> - A new callback to accept browsing channel establishment.
> - Enhancing similar to bt_io_listen for browsing PSM.
> - A new browsing command handler
> - Incremental addition to AVRCP 1.4 commands.
>
> Any feedback is very much appreciated!
Top posting is not allowed in this mailing list. Thanks. ;)
--
Gustavo F. Padovan
ProFUSION embedded systems - http://profusion.mobi
^ permalink raw reply
* Re: AVRCP 1.4 : Future on Target Role
From: shivendra.agrawal@stericsson.com @ 2010-10-27 6:57 UTC (permalink / raw)
To: linux-bluetooth
In-Reply-To: <AANLkTi=g+8UDsSQBnqBWk=Ly=xCmfvwX_ZCMsn_kU9Fb@mail.gmail.com>
Hi All,
ST-Ericsson plans to implement the commands to support target role of
AVRCP 1.4 Profile, and we would like to contribute it to BlueZ.
With our initial discussion, I would be aligning with BlueZ
contributors and would propose for the ideas that has not been
touched/developed so far, in order to have a design/implementation
that can be accepted.
As a very first, and very rough, design proposal for the BlueZ parts:
- A new SDP record for AVRCP 1.4 would be added to inform CT of the
version and features supported by target.
- A new callback to accept browsing channel establishment.
- Enhancing similar to bt_io_listen for browsing PSM.
- A new browsing command handler
- Incremental addition to AVRCP 1.4 commands.
Any feedback is very much appreciated!
Regards,
Shivendra
2010/10/25 João Paulo Rechi Vita <jprvita@gmail.com>:
> 2010/10/25 Shivendra Agrawal <ag.shivendra@gmail.com>:
>> 2010/10/23 João Paulo Rechi Vita <jprvita@gmail.com>:
>>> Hello all,
>>>
>>> I've seen some discuss regarding how to add support for AVRCP 1.3 and
>>> 1.4 versions on the ML lately, and some expectations over the related
>>> work I've done in BlueZ. Sorry for the long delay on replying, I've
>>> been pretty busy lately and just didn't got the time. I'm planing to
>>> put some effort again on this work on the coming weeks.
>>>
>>> On Tue, Oct 19, 2010 at 14:14, Luiz Augusto von Dentz
>>> <luiz.dentz@gmail.com> wrote:
>>>> Hi,
>>>>
>>>> On Tue, Oct 19, 2010 at 12:47 PM, Sander van Grieken
>>>> <sander@outrightsolutions.nl> wrote:
>>>>> I am very much in favor of not directly depending on MPRIS, but instead letting
>>>>> applications registering themselves as a target. For two reasons:
>>>>>
>>>>> - AVRCP seems to be a superset of MPRIS (which is very limited IMO), and might have
>>>>> different semantics, especially w.r.t. event notifications. So we would limit ourselves to
>>>>> the intersecting subset of both technologies.
>>>>> - A separate AVRCP/TG <-> MPRIS bridge agent would still allow controlling all MPRIS-
>>>>> enabled players, so we can have both full implementation of the AVRCP spec, AND generic
>>>>> MPRIS support.
>>>>
>>>> Sounds good to me, we can use Media API to register players as well.
>>>>
>>>
>>> I agree with Sander's opinion that MPRIS seems a bit limited for 1.4.
>>> OTOH it's an already defined and under-adoption standard. If we have
>>> applications registering themselves directly with us, we'll have to
>>> define a new interface for that and push this to the player
>>> applications. Do you guys already have a draft of these interfaces
>>> (for the applications and extensions to the Media API)? I guess we
>>> should try to define exactly what we need first, and them see what's
>>> missing from MPRIS.
>>>
>>>>>> > I am keen to receive your feedback with some ideas and thoughts to put
>>>>>> > my effort in right direction.
>>>>>> >
>>>>>> > Question:
>>>>>> > Is anyone working on AVRCP 1.4 Target role profile development?
>>>>>>
>>>>>> Joao Paulo (http://jprvita.wordpress.com/2010/07/22/avrcp-metadata/)
>>>>>
>>>>> Actually, the metadata work is not part of v1.4 of the spec, but 1.3
>>>>>
>>>>> Second, I have already added some boilerplate stuff (like a DBUS Connect method for RCP and
>>>>> some fixes for CT commands), but I've based on Joao's branch, so I have to wait until his
>>>>> stuff gets merged. Alternatively, I could rebase that stuff on HEAD, but that would overlap
>>>>> and conflict with Joao's stuff, so I'm hesitant to go there.
>>>>
>>>
>>> Have you published this code somewhere?
>>>
>>>> I hope to see this code being push upstream soon, I will try to
>>>> contact Joao Paulo to get an idea if the code is ready to be
>>>> reviewed/pushed so we get the things rolling.
>>>>
>>>
>>> I'm finally here :) I've focused mostly in the 1.3 version of the spec
>>> and having pulseaudio as a middle-man in my work, and have written
>>> most of the code in pulseaudio to handle these new functionality. Even
>>> if we take the approach described above for 1.4, IMO it makes sense to
>>> upstream this so we can have earlier support for 1.3 and also to
>>> support Sander's work. Luiz, Johan, what do you think?
>>>
>>> I'll review the code once more, since I've written it a few months
>>> ago, but my main concern about pushing it upstream right now is that
>>> it hasn't been tested yet. I have no device to test against and PTS
>>> can't give us no guarantee whether the code really works in practice
>>> or not (but it's still better than nothing). Sander, David, have you
>>> tested my code against any real device?
>>
>> You are right, PTS does not guarantee, but I guess, PTS viewer can support
>> checking the frame that is sent is as per protocol.
>> This could give a safe hands of the implementation. Does that assumption helps?
>
> Yes, you can view what is passing by the bluetooth radio, but it's
> still the same as testing against the PTS only. The best would be to
> have device which someone could test against.
>
> --
> João Paulo Rechi Vita
> http://jprvita.wordpress.com/
>
^ permalink raw reply
* Re: [RFC] LE connections and advertising management
From: Claudio Takahasi @ 2010-10-27 1:01 UTC (permalink / raw)
To: Mike Tsai; +Cc: BlueZ development
In-Reply-To: <35B17FE5076C7040809188FBE7913F983F84405C72@SC1EXMB-MBCL.global.atheros.com>
Hi Mike,
On Tue, Oct 26, 2010 at 6:10 PM, Mike Tsai <Mike.Tsai@atheros.com> wrote:
> [Mike Tsai]
> Hi Claudio,
>
> I look at the API and it is well-defined with high level of abstraction. However, I did have a few questions here, hopefully you can answer them,
>
> On Client side:
>
> 1. I see you didn't offer any service discovery API for client to discover the server service database (basically to get the attribute handles). So I assume that you consider GATT discovery procedure works the same way as SDP, done automatically by GATT after link is established without application's initiative. Am I correct?
>
> 2. The characteristic descriptor set via SetProperty API is limited to the 6 characteristic descriptors defined in GATT spec. However, there could be profile specific characteristic descriptors beyond these, will the SetProperty able to support these?
>
> 3. The characteristic monitoring is set up via 128 bits UUID. Do you have mechanism to handle duplicated characteristic within a server's database? How do you identify them via your API?
>
>
> On Server side:
>
> 1. Is there an API that allows server application to register new attributes? (primary service, characteristic, included service, et al),
>
> Regards,
>
> Mike
Client side:
Yes. ALL characteristics are fetched after "create the device"
procedure. This approach is wrong, some characteristics requires
encryption, authentication or authorization. Another aspect is that we
need to avoid excessive transactions. The idea now is try to search
for the primary service information only and "probe" the clients that
match with the registered service UUID. When "probed" the clients will
receive the GAttrib instance and the primary service handles range. It
is up to them to decide which attributes are relevant. Note that the
clients are only another "layer" implementing profile specific
features inside BlueZ.
It is a little bit unclear to me at the moment, but we can expose
Profile specific features. Such as threshold, alert level, ...
Is it allowed duplicated UUIDs for the same primary service? We are
not handling this right now.
It seems that you already have a proprietary implementation ;-)
Server side:
No API. We wrote an attribute server for testing purpose only. But we
will address this soon.
Regards,
Claudio
^ permalink raw reply
* RE: [RFC] LE connections and advertising management
From: Mike Tsai @ 2010-10-26 21:10 UTC (permalink / raw)
To: Claudio Takahasi; +Cc: BlueZ development
In-Reply-To: <AANLkTinnjXuAOBTY8VZz756VdrDFv0-OVKPNkwWbxi9-@mail.gmail.com>
LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IENsYXVkaW8gVGFrYWhhc2kgW21haWx0
bzpjbGF1ZGlvLnRha2FoYXNpQG9wZW5ib3NzYS5vcmddIA0KU2VudDogTW9uZGF5LCBPY3RvYmVy
IDI1LCAyMDEwIDExOjU1IEFNDQpUbzogTWlrZSBUc2FpDQpDYzogQmx1ZVogZGV2ZWxvcG1lbnQN
ClN1YmplY3Q6IFJlOiBbUkZDXSBMRSBjb25uZWN0aW9ucyBhbmQgYWR2ZXJ0aXNpbmcgbWFuYWdl
bWVudA0KDQpPbiBNb24sIE9jdCAyNSwgMjAxMCBhdCAzOjE2IFBNLCBNaWtlIFRzYWkgPE1pa2Uu
VHNhaUBhdGhlcm9zLmNvbT4gd3JvdGU6DQo+DQo+DQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0t
LS0tDQo+IEZyb206IENsYXVkaW8gVGFrYWhhc2kgW21haWx0bzpjbGF1ZGlvLnRha2FoYXNpQG9w
ZW5ib3NzYS5vcmddDQo+IFNlbnQ6IE1vbmRheSwgT2N0b2JlciAyNSwgMjAxMCAxMDo1NiBBTQ0K
PiBUbzogTWlrZSBUc2FpDQo+IENjOiBCbHVlWiBkZXZlbG9wbWVudA0KPiBTdWJqZWN0OiBSZTog
W1JGQ10gTEUgY29ubmVjdGlvbnMgYW5kIGFkdmVydGlzaW5nIG1hbmFnZW1lbnQNCj4NCj4gT24g
TW9uLCBPY3QgMjUsIDIwMTAgYXQgMjoxMSBQTSwgTWlrZSBUc2FpIDxNaWtlLlRzYWlAYXRoZXJv
cy5jb20+IHdyb3RlOg0KPj4NCj4+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+PiBGcm9t
OiBsaW51eC1ibHVldG9vdGgtb3duZXJAdmdlci5rZXJuZWwub3JnIFttYWlsdG86bGludXgtYmx1
ZXRvb3RoLW93bmVyQHZnZXIua2VybmVsLm9yZ10gT24gQmVoYWxmIE9mIENsYXVkaW8gVGFrYWhh
c2kNCj4+IFNlbnQ6IE1vbmRheSwgT2N0b2JlciAyNSwgMjAxMCA1OjUzIEFNDQo+PiBUbzogQmx1
ZVogZGV2ZWxvcG1lbnQNCj4+IFN1YmplY3Q6IFtSRkNdIExFIGNvbm5lY3Rpb25zIGFuZCBhZHZl
cnRpc2luZyBtYW5hZ2VtZW50DQo+Pg0KPj4gSGkgYWxsLA0KPj4NCj4+IEludGVybGVhdmUgQlIv
RURSL0xFIGRpc2NvdmVyeSBpcyBpbXBsZW1lbnRlZCwgdGhlIG5leHQgc3RlcCBpbiB0aGUNCj4+
IHVzZXIgc3BhY2UgaXMgaG93IHRvIG1hbmFnZSBhZHZlcnRpc2luZyBhbmQgTEUgY29ubmVjdGlv
bnMuDQo+Pg0KPj4gU29tZSBhc3BlY3RzOg0KPj4gMS4gT25seSBvbmUgTEUgY29ubmVjdGlvbiBp
cyBhbGxvd2VkKHBlciBwZWVyKSwgbWVhbmluZyBvbmx5IG9uZQ0KPj4gR0F0dHJpYiBpbnN0YW5j
ZSB3aWxsIGJlIGFsbG93ZWQgb3RoZXJ3aXNlIGl0IHdpbGwgbm90IGJlIHBvc3NpYmxlIHRvDQo+
PiBzZXJpYWxpemUgY29tbWFuZHMvZXZlbnRzDQo+PiAyLiBUaGUgcmVtb3RlL1BlcmlwaGVyYWwg
Y2FuIHN1cHBvcnQgbW9yZSB0aGFuIG9uZSBHQVRUIHByaW1hcnkgc2VydmljZQ0KPj4gMy4gV2Ug
YXJlIHBsYW5uaW5nIHRvIHVzZSAiZGlyZWN0IiBjb25uZWN0aW9ucyBvbmx5LCBtZWFuaW5nIHRo
YXQgd2UNCj4+IHdpbGwgbm90IHVzZSB3aGl0ZWxpc3QgYW5kIHRoZSBhcHBsaWNhdGlvbiBpbnRl
cmVzdGVkIG11c3QgaW5mb3JtIHRoZQ0KPj4gcmVtb3RlIGFkZHJlc3Mvb2JqZWN0IHRvIGNvbm5l
Y3QgdG8uDQo+PiA0LiBLZXJuZWwgbWFuYWdlcyB0aGUgY29ubmVjdGlvbiBlc3RhYmxpc2htZW50
LCBjdXJyZW50bHkgdGhlcmUgaXNuJ3QNCj4+IGEgwqB3YXkgdG8gY2hhbmdlIHRoZSBjb25uZWN0
aW9uIHBhcmFtZXRlcnMuIEJNSSBvciBpb2N0bHMgd2lsbCBiZQ0KPj4gcmVxdWlyZWQgdG8gY2hh
bmdlIHRoZSBkZWZhdWx0IHBhcmFtZXRlcnMgYW5kIGFsc28gdG8gdHJpZ2dlciBTTVANCj4+IG5l
Z290aWF0aW9uLg0KPj4NCj4+DQo+PiBTb21lIGlkZWFzOg0KPj4gMS4gaW1wbGVtZW50IGEgY2hh
cmFjdGVyaXN0aWMgZHJpdmVyOiBiYXNpY2FsbHkgdG8gcHJvdmlkZSBhbg0KPj4gYWJzdHJhY3Rp
b24gdG8gR0FUVCBjbGllbnRzLiBleDogUHJveGltaXR5LCBIZWFsdGgsIC4uLg0KPj4gMi4gV2Ug
ZG9uJ3QgbmVlZCB0byBpbXBsZW1lbnQgUHJveGltaXR5IGFuZCBvdGhlciBHQVRUIGNsaWVudHMg
YXMgYQ0KPj4gcGx1Z2luIGF0IHRoZSBtb21lbnQsIGl0IGNhbiBiZSBlbmFibGVkIGF1dG9tYXRp
Y2FsbHkgYnkNCj4+IC0tZW5hYmxlLWF0dHJpYg0KPj4gMy4gR0FUVCBjbGllbnRzIGNvdWxkIHJl
Z2lzdGVyIGEgd2F0Y2hlci9maWx0ZXIgZm9yIGFkdmVydGlzaW5nIGV2ZW50cw0KPj4gNC4gR0FU
VCBjbGllbnRzIGRvZXNuJ3QgbmVlZCB0byBrbm93IEFUVCwgaW4gdGhlb3J5IGl0IGNhbiBoYW5k
bGUNCj4+IGNoYXJhY3RlcmlzdGljcyBvbmx5DQo+PiA1LiBHQVRUIGNsaWVudHMgbmVlZHMgdG8g
Y29udHJvbC9yZXF1ZXN0IExFIGNvbm5lY3Rpb25zIGJhc2VkIG9uIHRoZQ0KPj4gYWR2ZXJ0aXNl
bWVudCByZWNlaXZlZA0KPj4NCj4+IEFuIGluaXRpYWwgZHJhZnQgaW1wbGVtZW50aW5nIHBhcnQg
b2YgdGhpcyBpZGVhIGlzIGhlcmU6DQo+PiBnaXQ6Ly9naXQuaW5mcmFkZWFkLm9yZy91c2Vycy9j
a3Rha2FoYXNpL2JsdWV6LmdpdCBkZXZlbA0KPj4NCj4+IENvbW1lbnRzPw0KPj4NCj4+IFJlZ2Fy
ZHMsDQo+PiBDbGF1ZGlvDQo+Pj4+TVQgY29tbWVudHMsDQo+Pg0KPj4gMS4gT25seSBvbmUgTEUg
Y29ubmVjdGlvbiBpcyBhbGxvd2VkKHBlciBwZWVyKSwgbWVhbmluZyBvbmx5IG9uZQ0KPj4gR0F0
dHJpYiBpbnN0YW5jZSB3aWxsIGJlIGFsbG93ZWQgb3RoZXJ3aXNlIGl0IHdpbGwgbm90IGJlIHBv
c3NpYmxlIHRvDQo+PiBzZXJpYWxpemUgY29tbWFuZHMvZXZlbnRzDQo+Pg0KPj4+PiBZb3UgbWVh
biB0aGUgbWFzdGVyIChvciBjbGllbnQpIGNhbiBvbmx5IGNvbm5lY3QgdG8gMSBzbGF2ZSAob3Ig
c2VydmVyKSBvciBhIHNsYXZlIGNhbiBvbmx5IGNvbm5lY3QgdG8gMSBtYXN0ZXI/DQo+IFtDbGF1
ZGlvIFRha2FoYXNpXQ0KPiBUaGUgbWFzdGVyIGNhbiBiZSBjb25uZWN0ZWQgdG8gbW9yZSB0aGFu
IG9uZSBzbGF2ZS4gQnV0IGhlcmUsIEkgd2FubmENCj4gZW1waGFzaXplIHRoYXQgb25seSBvbmUg
aW5zdGFuY2Ugb2YgR0F0dHRyaWIgc2hhbGwgYmUgY3JlYXRlZCB0bw0KPiByZXByZXNlbnQgdGhl
IHBoeXNpY2FsIGNoYW5uZWwgYmV0d2VlbiB0d28gTEUgY2FwYWJsZSBkZXZpY2VzLiBHQXR0cmli
DQo+IGlzIHRoZSBhYnN0cmFjdGlvbiB0aGF0IHdlIGNyZWF0ZWQgaW4gQmx1ZVogdG8gcmVwcmVz
ZW50IHRoZSBHQVRUL0FUVA0KPiBjb25uZWN0aW9uLCBpdCBpcyBuZWNlc3NhcnkgdG8gYWRkcmVz
cyBtdWx0aXBsZSBhcHBsaWNhdGlvbnMvcHJvZmlsZXMNCj4gYW5kIHF1ZXVlIGNvbW1hbmRzL2V2
ZW50cy4NCj4gW01pa2UgVHNhaV0NCj4gSSBzZWUuIEluIG9yZGVyIHRvIGhhbmRsZSBtdWx0aXBs
ZSBwcm9maWxlcyAoYXMgbXVsdGlwbGUgYXBwbGljYXRpb25zIHJ1bm5pbmcgb24gdG9wIG9mIHRo
ZSBHQXR0cmliKSBpbiBhIHNpbmdsZSBwaHlzaWNhbCBsaW5rLCB5b3Ugd2lsbCBuZWVkIHNvbWV0
aGluZyBsaWtlICJhcHBsaWNhdGlvbiBoYW5kbGUiIHRvIGRpc3BhdGNoIHRoZSByZXNwb25zZS9p
ZGVudGlmaWNhdGlvbiB0byB0aGUgYXBwcm9wcmlhdGUgYXBwbGljYXRpb24gY29ycmVjdGx5Lg0K
PiBNYXkgeW91IHJlZmVyIG1lIHRvIHRoZSBBUEkgZG9jdW1lbnQgdGhhdCB5b3UgYXJlIG9wZW5p
bmcgdG8gdGhlIEdBVFQgY2xpZW50KHMpIGZyb20gdGhpcyBHQXR0cmliPw0KW0NsYXVkaW8gVGFr
YWhhc2ldDQpIaSBNaWtlLA0KDQpBdCB0aGUgbW9tZW50IGl0IGlzIG5vdCBjbGVhciB0byBtZSBp
ZiBhbiAiYXBwbGljYXRpb24gaGFuZGxlIiB3aWxsIGJlDQpuZWVkZWQsIG1heWJlIHdlIGNhbiBh
bHNvIGhpZGUgaXQgZnJvbSB0aGUgaGlnaGVyIGxheWVycy4gQWxsIHJlcXVlc3RzDQphcmUgc2Vy
aWFsaXplZCBhbmQgZm9yIGVhY2ggcmVxdWVzdCB0aGVyZSBpcyBhIHJlc3BvbnNlLCB0aGUNCmV4
Y2VwdGlvbnMgYXJlIHdyaXRlIHdpdGhvdXQgcmVzcG9uc2UgYW5kIG5vdGlmaWNhdGlvbi4gRWFj
aCBwcmltYXJ5DQpzZXJ2aWNlIHJlcHJlc2VudGF0aW9uIHdpbGwgaGF2ZSBhbiBvYmplY3QgcGF0
aCwgbWVhbmluZyB0aGF0IG1heWJlIGl0DQppcyBwb3NzaWJsZSBmb3J3YXJkIHRoZSByZXNwb25z
ZSB0byB0aGUgcmlnaHQgc291cmNlIGJhc2VkIG9uIHRoZSBsYXN0DQpyZXF1ZXN0IGFuZCBoYW5k
bGUgaW5mb3JtYXRpb24uDQoNCkdBdHRyaWIgd2lsbCBub3QgYmUgZXhwb3NlZCB0byB0aGUgVUku
IFVJIG5lZWRzIHRvIGFjY2VzcyBCbHVlWiBHQVRUDQpjbGllbnRzIHNlcnZpY2VzIHVzaW5nIEQt
QnVzLg0KR0FUVCBjbGllbnRzIGluIGdlbmVyYWwgd2lsbCBoYXZlIHR3byBwaWVjZXM6DQogMS0g
VUk6IFF0LCBHVEssIHB5dGhvbiwgLi4uDQogMi0gIm1vZHVsZSIgaW4gdGhlIEJsdWVaIGZvciBw
cm9maWxlIHNwZWNpZmljIHRhc2tzIGFuZCBELUJ1cyBzZXJ2aWNlDQppbnRlcmZhY2UuDQoNCllv
dSBjYW4gZmluZCB0aGUgY3VycmVudCBhdHRyaWJ1dGUgQVBJIGluIHRoZSBmaWxlOiBkb2MvYXR0
cmlidXRlLWFwaS50eHQNCg0KQ2xhdWRpbw0KDQpbTWlrZSBUc2FpXQ0KSGkgQ2xhdWRpbywNCg0K
CUkgbG9vayBhdCB0aGUgQVBJIGFuZCBpdCBpcyB3ZWxsLWRlZmluZWQgd2l0aCBoaWdoIGxldmVs
IG9mIGFic3RyYWN0aW9uLiBIb3dldmVyLCBJIGRpZCBoYXZlIGEgZmV3IHF1ZXN0aW9ucyBoZXJl
LCBob3BlZnVsbHkgeW91IGNhbiBhbnN3ZXIgdGhlbSwNCg0KCU9uIENsaWVudCBzaWRlOg0KDQoJ
CTEuIEkgc2VlIHlvdSBkaWRuJ3Qgb2ZmZXIgYW55IHNlcnZpY2UgZGlzY292ZXJ5IEFQSSBmb3Ig
Y2xpZW50IHRvIGRpc2NvdmVyIHRoZSBzZXJ2ZXIgc2VydmljZSBkYXRhYmFzZSAoYmFzaWNhbGx5
IHRvIGdldCB0aGUgYXR0cmlidXRlIGhhbmRsZXMpLiBTbyBJIGFzc3VtZSB0aGF0IHlvdSBjb25z
aWRlciBHQVRUIGRpc2NvdmVyeSBwcm9jZWR1cmUgd29ya3MgdGhlIHNhbWUgd2F5IGFzIFNEUCwg
ZG9uZSBhdXRvbWF0aWNhbGx5IGJ5IEdBVFQgYWZ0ZXIgbGluayBpcyBlc3RhYmxpc2hlZCB3aXRo
b3V0IGFwcGxpY2F0aW9uJ3MgaW5pdGlhdGl2ZS4gQW0gSSBjb3JyZWN0Pw0KDQoJCTIuIFRoZSBj
aGFyYWN0ZXJpc3RpYyBkZXNjcmlwdG9yIHNldCB2aWEgU2V0UHJvcGVydHkgQVBJIGlzIGxpbWl0
ZWQgdG8gdGhlIDYgY2hhcmFjdGVyaXN0aWMgZGVzY3JpcHRvcnMgZGVmaW5lZCBpbiBHQVRUIHNw
ZWMuIEhvd2V2ZXIsIHRoZXJlIGNvdWxkIGJlIHByb2ZpbGUgc3BlY2lmaWMgY2hhcmFjdGVyaXN0
aWMgZGVzY3JpcHRvcnMgYmV5b25kIHRoZXNlLCB3aWxsIHRoZSBTZXRQcm9wZXJ0eSBhYmxlIHRv
IHN1cHBvcnQgdGhlc2U/DQoNCgkJMy4gVGhlIGNoYXJhY3RlcmlzdGljIG1vbml0b3JpbmcgaXMg
c2V0IHVwIHZpYSAxMjggYml0cyBVVUlELiBEbyB5b3UgaGF2ZSBtZWNoYW5pc20gdG8gaGFuZGxl
IGR1cGxpY2F0ZWQgY2hhcmFjdGVyaXN0aWMgd2l0aGluIGEgc2VydmVyJ3MgZGF0YWJhc2U/IEhv
dyBkbyB5b3UgaWRlbnRpZnkgdGhlbSB2aWEgeW91ciBBUEk/DQoNCg0KCU9uIFNlcnZlciBzaWRl
Og0KDQoJCTEuIElzIHRoZXJlIGFuIEFQSSB0aGF0IGFsbG93cyBzZXJ2ZXIgYXBwbGljYXRpb24g
dG8gcmVnaXN0ZXIgbmV3IGF0dHJpYnV0ZXM/IChwcmltYXJ5IHNlcnZpY2UsIGNoYXJhY3Rlcmlz
dGljLCBpbmNsdWRlZCBzZXJ2aWNlLCBldCBhbCksDQoNClJlZ2FyZHMsDQoNCk1pa2UNCg0KDQo+
DQo+Pg0KPj4gNC4gR0FUVCBjbGllbnRzIGRvZXNuJ3QgbmVlZCB0byBrbm93IEFUVCwgaW4gdGhl
b3J5IGl0IGNhbiBoYW5kbGUNCj4+IGNoYXJhY3RlcmlzdGljcyBvbmx5DQo+Pg0KPj4+PiBZb3Ug
bWVhbiBib3RoIGNoYXJhY3RlcmlzdGljIHZhbHVlIGFuZCBjaGFyYWN0ZXJpc3RpYyBkZXNjcmlw
dG9ycyBvZiBjaGFyYWN0ZXJpc3RpYz8NCj4gW0NsYXVkaW8gVGFrYWhhc2ldDQo+IEJvdGguIEZv
ciB0aGUgR0FUVCBjbGllbnQgcm9sZSwgYW4gaW50ZXJmYWNlIGNhbiBiZSBjcmVhdGVkIGV4cG9y
dGluZw0KPiBwcm9maWxlIHNwZWNpZmljIGRldGFpbHMuDQo+IFNvbWV0aW1lcyBHQVRUIGNsaWVu
dHMgd2lsbCBhbHNvIG5lZWQgdG8gYWNjZXNzIHNvbWUgbG93IGxldmVsIGluZm9ybWF0aW9uLg0K
PiBbTWlrZSBUc2FpXQ0KPiBZZXMsIEkgd2lsbCByZWFsbHkgYXBwcmVjaWF0ZSBpZiB5b3UgbWF5
IHNob3cgbWUgdGhlIHBsYW5uZWQgQVBJIGZvciB0aGlzIEdBdHRyaWIsDQo+DQo+DQo+IFJlZ2Fy
ZHMsDQo+IENsYXVkaW8NCj4+DQo+PiBSZWdhcmRzLA0KPj4NCj4+IE1pa2UNCj4+DQo+PiAtLQ0K
Pj4gVG8gdW5zdWJzY3JpYmUgZnJvbSB0aGlzIGxpc3Q6IHNlbmQgdGhlIGxpbmUgInVuc3Vic2Ny
aWJlIGxpbnV4LWJsdWV0b290aCIgaW4NCj4+IHRoZSBib2R5IG9mIGEgbWVzc2FnZSB0byBtYWpv
cmRvbW9Admdlci5rZXJuZWwub3JnDQo+PiBNb3JlIG1ham9yZG9tbyBpbmZvIGF0IMKgaHR0cDov
L3ZnZXIua2VybmVsLm9yZy9tYWpvcmRvbW8taW5mby5odG1sDQo+Pg0KPg0KDQoNCg0KLS0gDQot
LQ0KQ2xhdWRpbyBUYWthaGFzaQ0KSW5zdGl0dXRvIE5va2lhIGRlIFRlY25vbG9naWENClJlY2lm
ZSAtIFBlcm5hbWJ1Y28gLSBCcmFzaWwNCis1NSA4MSAzMDg3OTk5OQ0K
^ permalink raw reply
* RE: [RFC] LE connections and advertising management
From: Brian Redding @ 2010-10-26 20:26 UTC (permalink / raw)
To: 'Claudio Takahasi'; +Cc: 'BlueZ development'
In-Reply-To: <AANLkTimTgRV=Ang1JFQpOKXc0bVA6PSOA8WAUo4B7_Wv@mail.gmail.com>
> -----Original Message-----
> From: Claudio Takahasi [mailto:claudio.takahasi@openbossa.org]
> Sent: Monday, October 25, 2010 9:52 PM
>
> Hi Brian,
>
> On Mon, Oct 25, 2010 at 4:27 PM, Brian Redding
> <bredding@codeaurora.org> wrote:
> > Hi Claudio,
> >
> > Are there still interfaces that need to be added to attribute-api.txt
> > to handle client and server characteristic configuration as well as
> > presentation and aggregate formats? I see those as TODO items but
> > wondered if the APIs for them have been defined yet.
> >
> > One thing to note on the server API is that a GATT-based profile
> > could specify behavior on a characteristic value that when the
> > characteristic value is read to perform some action in a similar way as
> > a hardware register. It appears that the notes I'm reading in the code
> > thus far only consider changes (or writes) to characteristic values for
> > the watch code.
> >
> > Also does the current API handle included services?
> >
> > The Bluetooth SIG is beginning to look at 3rd party application
> > developer API's for both client and servers for various platforms so
> > understanding what is currently defined in BlueZ and what still needs
> > to be added would be useful.
> >
> > Thanks,
> > Brian
>
> The API to address characteristic descriptors is still being defined.
> We are focusing in the advertising and connection management at the
> moment. If you have suggestion of how to represent the descriptors in
> the attribute API, suggestions are welcome!
Once I feel more comfortable with the current API approach, I will see
if I can suggest something. One thing to note is that GATT only list
the current characteristic descriptors. Profiles can specify additional
ones or a group of generic ones could also be adopted in the future.
One example of this is a characteristic descriptor that defines triggers
that cause a particular behavior to occur when a condition on the characteristic
value occurs.
>
> There isn't a server API at the moment, we implemented a server for
> testing purpose only. But we will need to define it soon.
> Which pages/section of the spec describes this read characteristic
> behavior?
The GATT does not specify the read characteristic behavior but it can be
specified by a profile. I just wanted to point that out so that the design
takes that into account. You may need to have a call back when a characteristic
value is read as well as written.
>
> Included services are not supported by our client. How important is
> it? It is mandatory for qualification?
It is only mandatory on the server.
>
> Regards,
> Claudio.
Cheers,
Brian
---
Brian A. Redding
Employee of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum
^ permalink raw reply
* Re[4]: 4.76 possible regression: bluetoothd segfaults when launching bluetooth programs
From: Ilya Basin @ 2010-10-26 19:02 UTC (permalink / raw)
To: Johan Hedberg; +Cc: linux-bluetooth
In-Reply-To: <20101026141913.GA11973@jh-x301>
Hi Johan. The patch works, many thanks.
^ permalink raw reply
* Re: [PATCH] Fix a2dp play when sample rate changed
From: Johan Hedberg @ 2010-10-26 15:57 UTC (permalink / raw)
To: John Crosbie; +Cc: linux-bluetooth
In-Reply-To: <AANLkTikksLAeocFsM5vO0rnvphgOo_CoF1ZA_wkABY=c@mail.gmail.com>
Hi John,
On Tue, Oct 26, 2010, John Crosbie wrote:
> I have found that playing a 48KHz wav file immediately after playing a
> 44.1K file (or vice-versa) with aplay will fail. After this failure
> no a2dp stream will play. The problem is that after determining the
> current avdtp stream doesn't match the new configuration the stream is
> closed and a reconfiguration is attempted but fails because
> setup->rsep is null. The patch below fixes the reconfiguration.
Thanks for the patch. In the future, please follow the proper coding
style (e.g. space between "if" and "(") and prepare the patches using
git format-patch. I went ahead and did this work manually for you this
time instead of asking you to resend since we're in the process of
preparing the next bluez release.
Johan
^ permalink raw reply
* RE: [PATCH v4] Bluetooth: btwilink driver
From: Savoy, Pavan @ 2010-10-26 15:49 UTC (permalink / raw)
To: Pavan Savoy, padovan@profusion.mobi, marcel@holtmann.org
Cc: linux-bluetooth@vger.kernel.org, linux-kernel@vger.kernel.org
In-Reply-To: <AANLkTintn2pFAWP679=fmyEdGzMwZWdqyoG4YCdB_9Y9@mail.gmail.com>
> -----Original Message-----
> From: Pavan Savoy [mailto:pavan_savoy@sify.com]
> Sent: Thursday, October 21, 2010 8:26 AM
> To: padovan@profusion.mobi; marcel@holtmann.org
> Cc: linux-bluetooth@vger.kernel.org; linux-kernel@vger.kernel.org; Savoy,
> Pavan
> Subject: Re: [PATCH v4] Bluetooth: btwilink driver
>
Gustavo, Marcel,
Please review and provide comments.
If it is fine, please pull it in.
>
> On Tue, Oct 19, 2010 at 6:06 PM, <pavan_savoy@ti.com> wrote:
> > From: Pavan Savoy <pavan_savoy@ti.com>
> >
> > v4 comments
> >
> > module init now returns what platform_driver_register returns.
> > type casting of void* private data has been removed
>
> If there are no more critical comments, can it go in?
> Please review.
>
> Thanks,
> Pavan
>
> > 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,
> >
> > Marcel, Gustavo, & list,
> > Please review this version of patch.
> >
> > The other few like -EPERM for platform driver registration is to keep
> > it similar to other drivers, type casting is maintained just to feel sa=
fe
> > 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>
> > ---
> > drivers/bluetooth/Kconfig | 10 +
> > drivers/bluetooth/Makefile | 1 +
> > drivers/bluetooth/btwilink.c | 411
> ++++++++++++++++++++++++++++++++++++++++++
> > 3 files changed, 422 insertions(+), 0 deletions(-)
> > create 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
> > Say Y here to compile support for "Atheros firmware download
> driver"
> > into the kernel or say M to compile it as module (ath3k).
> >
> > +config BT_WILINK
> > + tristate "Texas Instruments WiLink7 driver"
> > + depends on TI_ST
> > + help
> > + This enables the Bluetooth driver for Texas Instrument's BT/F=
M/GPS
> > + combo devices. This makes use of shared transport line discip=
line
> > + core driver to communicate with the BT core of the combo chip=
.
> > +
> > + Say Y here to compile support for Texas Instrument's WiLink7
> driver
> > + into the kernel or say M to compile it as module.
> > endmenu
> > 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) +=3D btsdio.o
> > obj-$(CONFIG_BT_ATH3K) +=3D ath3k.o
> > obj-$(CONFIG_BT_MRVL) +=3D btmrvl.o
> > obj-$(CONFIG_BT_MRVL_SDIO) +=3D btmrvl_sdio.o
> > +obj-$(CONFIG_BT_WILINK) +=3D btwilink.o
> >
> > btmrvl-y :=3D btmrvl_main.o
> > btmrvl-$(CONFIG_DEBUG_FS) +=3D btmrvl_debugfs.o
> > diff --git a/drivers/bluetooth/btwilink.c b/drivers/bluetooth/btwilink.=
c
> > new file mode 100644
> > index 0000000..218efd6
> > --- /dev/null
> > +++ b/drivers/bluetooth/btwilink.c
> > @@ -0,0 +1,411 @@
> > +/*
> > + * Texas Instrument's Bluetooth Driver For Shared Transport.
> > + *
> > + * Bluetooth Driver acts as interface between HCI core and
> > + * TI Shared Transport Layer.
> > + *
> > + * Copyright (C) 2009-2010 Texas Instruments
> > + * Author: Raja Mani <raja_mani@ti.com>
> > + * Pavan Savoy <pavan_savoy@ti.com>
> > + *
> > + * This program is free software; you can redistribute it and/or modi=
fy
> > + * it under the terms of the GNU General Public License version 2 as
> > + * published by the Free Software Foundation.
> > + *
> > + * This program is distributed in the hope that it will be useful,
> > + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> > + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> > + * GNU General Public License for more details.
> > + *
> > + * You should have received a copy of the GNU General Public License
> > + * along with this program; if not, write to the Free Software
> > + * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-13=
07
> USA
> > + *
> > + */
> > +
> > +#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 "1.0"
> > +
> > +/* Number of seconds to wait for registration completion
> > + * when ST returns PENDING status.
> > + */
> > +#define BT_REGISTER_TIMEOUT 6000 /* 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
> > + * to be used by the driver during send_frame.
> > + * @wait_reg_completion - completion sync between ti_st_open
> > + * and ti_st_registration_completion_cb.
> > + */
> > +struct ti_st {
> > + struct hci_dev *hdev;
> > + char reg_status;
> > + long (*st_write) (struct sk_buff *);
> > + struct completion wait_reg_completion;
> > +};
> > +
> > +static int reset;
> > +
> > +/* Increments HCI counters based on pocket ID (cmd,acl,sco) */
> > +static inline void ti_st_tx_complete(struct ti_st *hst, int pkt_type)
> > +{
> > + struct hci_dev *hdev;
> > + hdev =3D hst->hdev;
> > +
> > + /* Update HCI stat counters */
> > + switch (pkt_type) {
> > + case HCI_COMMAND_PKT:
> > + hdev->stat.cmd_tx++;
> > + break;
> > +
> > + case HCI_ACLDATA_PKT:
> > + hdev->stat.acl_tx++;
> > + break;
> > +
> > + case HCI_SCODATA_PKT:
> > + hdev->stat.sco_tx++;
> > + break;
> > + }
> > +}
> > +
> > +/* ------- 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)
> > +{
> > + struct ti_st *lhst =3D priv_data;
> > +
> > + /* Save registration status for use in ti_st_open() */
> > + lhst->reg_status =3D data;
> > + /* complete the wait in ti_st_open() */
> > + 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)
> > +{
> > + int err;
> > + struct ti_st *lhst =3D priv_data;
> > +
> > + if (!skb)
> > + return -EFAULT;
> > +
> > + if (!lhst) {
> > + kfree_skb(skb);
> > + return -EFAULT;
> > + }
> > +
> > + skb->dev =3D (struct net_device *)lhst->hdev;
> > +
> > + /* Forward skb to HCI core layer */
> > + err =3D hci_recv_frame(skb);
> > + if (err) {
> > + kfree_skb(skb);
> > + BT_ERR("Unable to push skb to HCI core(%d)", err);
> > + return err;
> > + }
> > +
> > + lhst->hdev->stat.byte_rx +=3D skb->len;
> > +
> > + return 0;
> > +}
> > +
> > +/* ------- Interfaces to HCI layer ------ */
> > +/* protocol structure registered with shared transport */
> > +static struct st_proto_s ti_st_proto =3D {
> > + .type =3D ST_BT,
> > + .recv =3D st_receive,
> > + .reg_complete_cb =3D st_registration_completion_cb,
> > + .priv_data =3D NULL,
> > +};
> > +
> > +/* Called from HCI core to initialize the device */
> > +static int ti_st_open(struct hci_dev *hdev)
> > +{
> > + unsigned long timeleft;
> > + struct ti_st *hst;
> > + int err;
> > +
> > + BT_DBG("%s %p", hdev->name, hdev);
> > +
> > + /* provide contexts for callbacks from ST */
> > + hst =3D hdev->driver_data;
> > + ti_st_proto.priv_data =3D hst;
> > +
> > + err =3D st_register(&ti_st_proto);
> > + if (err =3D=3D -EINPROGRESS) {
> > + /* Prepare wait-for-completion handler data structures.
> > + * Needed to synchronize this and
> > + * st_registration_completion_cb() functions.
> > + */
> > + init_completion(&hst->wait_reg_completion);
> > +
> > + /* Reset ST registration callback status flag , this va=
lue
> > + * will be updated in ti_st_registration_completion_cb(=
)
> > + * function whenever it called from ST driver.
> > + */
> > + hst->reg_status =3D -EINPROGRESS;
> > +
> > + /* ST is busy with either protocol registration or firm=
ware
> > + * download. Wait until the registration callback is ca=
lled
> > + */
> > + BT_DBG(" waiting for registration completion signal fro=
m
> ST");
> > +
> > + timeleft =3D wait_for_completion_timeout
> > + (&hst->wait_reg_completion,
> > + msecs_to_jiffies(BT_REGISTER_TIMEOUT));
> > + if (!timeleft) {
> > + BT_ERR("Timeout(%d sec),didn't get reg "
> > + "completion signal from ST",
> > + BT_REGISTER_TIMEOUT / 1000);
> > + return -ETIMEDOUT;
> > + }
> > +
> > + /* Is ST registration callback called with ERROR status=
? */
> > + if (hst->reg_status !=3D 0) {
> > + BT_ERR("ST registration completed with invalid =
"
> > + "status %d", hst->reg_status);
> > + return -EAGAIN;
> > + }
> > + err =3D 0;
> > + } else if (err =3D=3D -EPERM) {
> > + BT_ERR("st_register failed %d", err);
> > + return err;
> > + }
> > +
> > + hst->st_write =3D ti_st_proto.write;
> > + if (!hst->st_write) {
> > + BT_ERR("undefined ST write function");
> > +
> > + /* Undo registration with ST */
> > + err =3D st_unregister(ST_BT);
> > + if (err)
> > + BT_ERR("st_unregister() failed with error %d", =
err);
> > +
> > + hst->st_write =3D NULL;
> > + return err;
> > + }
> > +
> > + /* Registration with ST layer is successful,
> > + * hardware is ready to accept commands from HCI core.
> > + */
> > + set_bit(HCI_RUNNING, &hdev->flags);
> > +
> > + return err;
> > +}
> > +
> > +/* Close device */
> > +static int ti_st_close(struct hci_dev *hdev)
> > +{
> > + int err;
> > + struct ti_st *hst =3D hdev->driver_data;
> > +
> > + /* continue to unregister from transport */
> > + err =3D st_unregister(ST_BT);
> > + if (err)
> > + BT_ERR("st_unregister() failed with error %d", err);
> > +
> > + hst->st_write =3D NULL;
> > +
> > + return err;
> > +}
> > +
> > +static int ti_st_send_frame(struct sk_buff *skb)
> > +{
> > + struct hci_dev *hdev;
> > + struct ti_st *hst;
> > + long len;
> > +
> > + if (!skb)
> > + return -ENOMEM;
> > +
> > + hdev =3D (struct hci_dev *)skb->dev;
> > + if (!hdev)
> > + return -ENODEV;
> > +
> > + if (!test_bit(HCI_RUNNING, &hdev->flags))
> > + return -EBUSY;
> > +
> > + hst =3D hdev->driver_data;
> > +
> > + /* Prepend skb with frame type */
> > + memcpy(skb_push(skb, 1), &bt_cb(skb)->pkt_type, 1);
> > +
> > + BT_DBG(" %s: type %d len %d", hdev->name, bt_cb(skb)->pkt_type,
> > + skb->len);
> > +
> > + /* Insert skb to shared transport layer's transmit queue.
> > + * Freeing skb memory is taken care in shared transport layer,
> > + * so don't free skb memory here.
> > + */
> > + if (!hst->st_write) {
> > + kfree_skb(skb);
> > + BT_ERR(" Could not write to ST (st_write is NULL)");
> > + return -EAGAIN;
> > + }
> > +
> > + len =3D hst->st_write(skb);
> > + if (len < 0) {
> > + kfree_skb(skb);
> > + BT_ERR(" ST write failed (%ld)", len);
> > + return -EAGAIN;
> > + }
> > +
> > + /* ST accepted our skb. So, Go ahead and do rest */
> > + hdev->stat.byte_tx +=3D len;
> > + ti_st_tx_complete(hst, bt_cb(skb)->pkt_type);
> > +
> > + return 0;
> > +}
> > +
> > +static void ti_st_destruct(struct hci_dev *hdev)
> > +{
> > + if (!hdev)
> > + return;
> > +
> > + BT_DBG("%s", hdev->name);
> > +
> > + /* free ti_st memory */
> > + kfree(hdev->driver_data);
> > +
> > + return;
> > +}
> > +
> > +/* Creates new HCI device */
> > +static int ti_st_register_dev(struct ti_st *hst)
> > +{
> > + int err;
> > + struct hci_dev *hdev;
> > +
> > + /* Initialize and register HCI device */
> > + hdev =3D hci_alloc_dev();
> > + if (!hdev)
> > + return -ENOMEM;
> > +
> > + BT_DBG("hdev %p", hdev);
> > +
> > + hst->hdev =3D hdev;
> > + hdev->bus =3D HCI_UART;
> > + hdev->driver_data =3D hst;
> > + hdev->open =3D ti_st_open;
> > + hdev->close =3D ti_st_close;
> > + hdev->flush =3D NULL;
> > + hdev->send =3D ti_st_send_frame;
> > + hdev->destruct =3D ti_st_destruct;
> > + hdev->owner =3D THIS_MODULE;
> > +
> > + if (reset)
> > + set_bit(HCI_QUIRK_NO_RESET, &hdev->quirks);
> > +
> > + err =3D hci_register_dev(hdev);
> > + if (err < 0) {
> > + BT_ERR("Can't register HCI device error %d", err);
> > + hci_free_dev(hdev);
> > + return err;
> > + }
> > +
> > + BT_DBG(" HCI device registered (hdev %p)", hdev);
> > + return 0;
> > +}
> > +
> > +
> > +static int bt_ti_probe(struct platform_device *pdev)
> > +{
> > + int err;
> > + static struct ti_st *hst;
> > +
> > + BT_DBG(" Bluetooth Driver Version %s", VERSION);
> > +
> > + hst =3D kzalloc(sizeof(struct ti_st), GFP_KERNEL);
> > + if (!hst)
> > + return -ENOMEM;
> > +
> > + /* Expose "hciX" device to user space */
> > + err =3D ti_st_register_dev(hst);
> > + if (err) {
> > + kfree(hst);
> > + return err;
> > + }
> > +
> > + dev_set_drvdata(&pdev->dev, hst);
> > + return err;
> > +}
> > +
> > +static int bt_ti_remove(struct platform_device *pdev)
> > +{
> > + struct ti_st *hst;
> > + struct hci_dev *hdev;
> > +
> > + hst =3D dev_get_drvdata(&pdev->dev);
> > +
> > + if (!hst)
> > + return -EFAULT;
> > +
> > + /* Deallocate local resource's memory */
> > + hdev =3D hst->hdev;
> > +
> > + if (!hdev) {
> > + BT_ERR("Invalid hdev memory");
> > + kfree(hst);
> > + return -EFAULT;
> > + }
> > +
> > + ti_st_close(hdev);
> > + hci_unregister_dev(hdev);
> > + /* Free HCI device memory */
> > + hci_free_dev(hdev);
> > +
> > + return 0;
> > +}
> > +
> > +static struct platform_driver btwilink_driver =3D {
> > + .probe =3D bt_ti_probe,
> > + .remove =3D bt_ti_remove,
> > + .driver =3D {
> > + .name =3D "btwilink",
> > + .owner =3D THIS_MODULE,
> > + },
> > +};
> > +
> > +/* ------- Module Init/Exit interfaces ------ */
> > +static int __init bt_drv_init(void)
> > +{
> > + long ret;
> > +
> > + ret =3D platform_driver_register(&btwilink_driver);
> > + if (ret !=3D 0) {
> > + BT_ERR("btwilink platform driver registration failed");
> > + return ret;
> > + }
> > + return 0;
> > +}
> > +
> > +static void __exit bt_drv_exit(void)
> > +{
> > + platform_driver_unregister(&btwilink_driver);
> > +}
> > +
> > +module_init(bt_drv_init);
> > +module_exit(bt_drv_exit);
> > +
> > +/* ------ Module Info ------ */
> > +
> > +module_param(reset, bool, 0644);
> > +MODULE_PARM_DESC(reset, "Send HCI reset command on initialization");
> > +MODULE_AUTHOR("Raja Mani <raja_mani@ti.com>");
> > +MODULE_DESCRIPTION("Bluetooth Driver for TI Shared Transport" VERSION)=
;
> > +MODULE_VERSION(VERSION);
> > +MODULE_LICENSE("GPL");
> > --
> > 1.6.5
> >
> > --
> > To unsubscribe from this list: send the line "unsubscribe linux-bluetoo=
th"
> 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
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