* RE: RFC: btusb firmware load help
From: Johannes Berg @ 2010-10-07 15:15 UTC (permalink / raw)
To: Shanmugamkamatchi Balashanmugam
Cc: Luis Rodriguez, Marcel Holtmann, linux-bluetooth,
linux-kernel@vger.kernel.org, linux-wireless@vger.kernel.org,
Deepak Dhamdhere, Sree Durbha
In-Reply-To: <44EE5C37ADC36343B0625A05DD408C4850DAD2CA31@CHEXMB-01.global.atheros.com>
> Thanks Johannes. This would be better option to change PID in firmware
> as blacklisting 3002 might create problems for 3011 chipsets.
What would be the problem with 3011? Does it also use the 3002 ID, but
not use firmware upload???
johannes
^ permalink raw reply
* RE: RFC: btusb firmware load help
From: Shanmugamkamatchi Balashanmugam @ 2010-10-07 15:09 UTC (permalink / raw)
To: Luis Rodriguez, Johannes Berg
Cc: Luis Rodriguez, Marcel Holtmann, linux-bluetooth,
linux-kernel@vger.kernel.org, linux-wireless@vger.kernel.org,
Deepak Dhamdhere, Sree Durbha
In-Reply-To: <20101006183340.GI7070@tux>
________________________________________
From: linux-bluetooth-owner@vger.kernel.org [linux-bluetooth-owner@vger.kernel.org] On Behalf Of Luis R. Rodriguez [lrodriguez@atheros.com]
Sent: Thursday, October 07, 2010 12:03 AM
To: Johannes Berg
Cc: Luis Rodriguez; Marcel Holtmann; linux-bluetooth; linux-kernel@vger.kernel.org; linux-wireless@vger.kernel.org; Deepak Dhamdhere; Sree Durbha
Subject: Re: RFC: btusb firmware load help
On Wed, Oct 06, 2010 at 11:28:17AM -0700, Johannes Berg wrote:
> On Wed, 2010-10-06 at 11:26 -0700, Luis R. Rodriguez wrote:
>
> > > Good idea, I forgot about possible firmware changes :) Lets see if our
> > > team can do that. Thanks for all the feedback.
> >
> > Deepak a proof of concept test can involve simply hex-editing the
> > ath3k-1.fw and replacing 0x3002 to 0x3003, then the above patch might
> > work.
>
> $ hd ath3k-1.fw
> ...
> 00000670 00 00 00 00 00 00 00 00 00 00 00 00 f3 0c 02 30 |...............0|
> 00000680 12 01 10 01 e0 01 01 40 f3 0c 02 30 01 00 00 00 |.......@...0....|
> ...
>
> that looks a lot like the IDs right there, in little endian :-)
>Furthermore another idea by johannes is that if we cannot fix this
>in firmware by changing the exposed device ID, we could just check
>in btusb for some USB component that would come alive once the firmware
>does get loaded, like endpoints, or speed, or whatever. But that would
>be last resort.
> Luis
>--
>To unsubscribe from this list: send the line "unsubscribe linux-bluetooth" in
>the body of a message to majordomo@vger.kernel.org
>More majordomo info at http://vger.kernel.org/majordomo-info.html
Thanks Johannes. This would be better option to change PID in firmware
as blacklisting 3002 might create problems for 3011 chipsets.
Will try and let you people know.
Regards,
Bala.
^ permalink raw reply
* RE: [PATCH 1/2] drivers:bluetooth: TI_ST bluetooth driver
From: Savoy, Pavan @ 2010-10-07 14:59 UTC (permalink / raw)
To: Marcel Holtmann
Cc: linux-bluetooth@vger.kernel.org, johan.hedberg@gmail.com,
greg@kroah.com, linux-kernel@vger.kernel.org
In-Reply-To: <1286445948.6145.70.camel@aeonflux>
> -----Original Message-----
> From: Marcel Holtmann [mailto:marcel@holtmann.org]
> Sent: Thursday, October 07, 2010 5:06 AM
> To: pavan-savoy@ti.com
> Cc: linux-bluetooth@vger.kernel.org; johan.hedberg@gmail.com; greg@kroah.=
com;
> linux-kernel@vger.kernel.org; Savoy, Pavan
> Subject: Re: [PATCH 1/2] drivers:bluetooth: TI_ST bluetooth driver
>
> Hi Pavan,
>
> > 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=
.
> >
> > Signed-off-by: Pavan Savoy <pavan_savoy@ti.com>
> > ---
> > drivers/bluetooth/bt_ti.c | 463 ++++++++++++++++++++++++++++++++=
++++
> > drivers/staging/ti-st/bt_drv.c | 509 --------------------------------=
-----
> ---
> > drivers/staging/ti-st/bt_drv.h | 61 -----
> > 3 files changed, 463 insertions(+), 570 deletions(-)
> > create mode 100644 drivers/bluetooth/bt_ti.c
> > delete mode 100644 drivers/staging/ti-st/bt_drv.c
> > delete mode 100644 drivers/staging/ti-st/bt_drv.h
>
> I don't care about staging at all. So you sort that out with Greg.
>
> Submit your driver for upstream inclusion. And once accepted you can pin
> Greg about removing it.
>
> > diff --git a/drivers/bluetooth/bt_ti.c b/drivers/bluetooth/bt_ti.c
> > new file mode 100644
> > index 0000000..4f3d3aa
> > --- /dev/null
> > +++ b/drivers/bluetooth/bt_ti.c
> > @@ -0,0 +1,463 @@
> > +/*
> > + * 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
> > + *
> > + */
> > +
> > +#define pr_fmt(fmt) "(tibt): " fmt
>
> Don't do this. Just use BT_DBG, BT_ERR, BT_INFO etc.
Yes, Will do it.
> > +#include <net/bluetooth/bluetooth.h>
> > +#include <net/bluetooth/hci_core.h>
> > +
> > +#include <linux/ti_wilink_st.h>
> > +
> > +/* Bluetooth Driver Version */
> > +#define VERSION "1.0"
> > +
> > +/* Defines number of seconds to wait for reg completion
> > + * callback getting called from ST (in case,registration
> > + * with ST returns PENDING status)
> > + */
> > +#define BT_REGISTER_TIMEOUT 6000 /* 6 sec */
> > +
> > +/* BT driver's local status */
> > +#define BT_DRV_RUNNING 0
> > +#define BT_ST_REGISTERED 1
> > +
> > +/**
> > + * struct hci_st - BT driver operation structure
> > + * @hdev: hci device pointer which binds to bt driver
> > + * @flags: used locally,to maintain various BT driver status
> > + * @streg_cbdata: to hold ST registration callback status
> > + * @st_write: write function pointer of ST driver
> > + * @wait_for_btdrv_reg_completion - completion sync between hci_st_ope=
n
> > + * and hci_st_registration_completion_cb.
> > + */
> > +struct hci_st {
> > + struct hci_dev *hdev;
> > + unsigned long flags;
> > + char streg_cbdata;
> > + long (*st_write) (struct sk_buff *);
> > + struct completion wait_for_btdrv_reg_completion;
> > +};
> > +
> > +static struct hci_st *hst;
> > +static int reset;
> > +
> > +/* Increments HCI counters based on pocket ID (cmd,acl,sco) */
> > +static inline void hci_st_tx_complete(struct hci_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.cmd_tx++;
> > + break;
> > + }
> > +}
> > +
> > +/* ------- Interfaces to Shared Transport ------ */
> > +
> > +/* Called by ST layer to indicate protocol registration completion
> > + * status.hci_st_open() function will wait for signal from this
> > + * API when st_register() function returns ST_PENDING.
> > + */
> > +static void hci_st_registration_completion_cb(void *priv_data, char da=
ta)
> > +{
> > + struct hci_st *lhst =3D (struct hci_st *)priv_data;
> > + /* hci_st_open() function needs value of 'data' to know
> > + * the registration status(success/fail),So have a back
> > + * up of it.
> > + */
> > + lhst->streg_cbdata =3D data;
> > +
> > + /* Got a feedback from ST for BT driver registration
> > + * request.Wackup hci_st_open() function to continue
> > + * it's open operation.
> > + */
> > + complete(&lhst->wait_for_btdrv_reg_completion);
> > +}
> > +
> > +/* Called by Shared Transport layer when receive data is
> > + * available */
> > +static long hci_st_receive(void *priv_data, struct sk_buff *skb)
> > +{
> > + int err;
> > + int len;
> > + struct hci_st *lhst =3D (struct hci_st *)priv_data;
> > +
> > + err =3D 0;
> > + len =3D 0;
> > +
> > + if (skb =3D=3D NULL) {
> > + pr_err("Invalid SKB received from ST");
> > + return -EFAULT;
> > + }
> > + if (!lhst) {
> > + kfree_skb(skb);
> > + pr_err("Invalid hci_st memory,freeing SKB");
> > + return -EFAULT;
> > + }
> > + if (!test_bit(BT_DRV_RUNNING, &lhst->flags)) {
> > + kfree_skb(skb);
> > + pr_err("Device is not running,freeing SKB");
> > + return -EINVAL;
> > + }
> > +
> > + len =3D skb->len;
> > + 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);
> > + pr_err("Unable to push skb to HCI CORE(%d),freeing SKB",
> > + err);
> > + return err;
> > + }
> > + lhst->hdev->stat.byte_rx +=3D len;
> > +
> > + return 0;
> > +}
> > +
> > +/* ------- Interfaces to HCI layer ------ */
> > +
> > +/* Called from HCI core to initialize the device */
> > +static int hci_st_open(struct hci_dev *hdev)
> > +{
> > + static struct st_proto_s hci_st_proto;
> > + unsigned long timeleft;
> > + int err;
> > + err =3D 0;
> > +
> > + pr_debug("%s %p", hdev->name, hdev);
> > +
> > + /* Already registered with ST ? */
> > + if (test_bit(BT_ST_REGISTERED, &hst->flags)) {
> > + pr_err("Registered with ST already,open called again?");
> > + return 0;
> > + }
>
> Why are you testing against this. This should be not needed at all.
Oh yes, Agree, the HCI sock/core doesn't allow hci0 to be HCIDEVUP-ed twice=
.
> > + /* Populate BT driver info required by ST */
> > + memset(&hci_st_proto, 0, sizeof(hci_st_proto));
> > +
> > + /* BT driver ID */
> > + hci_st_proto.type =3D ST_BT;
> > +
> > + /* Receive function which called from ST */
> > + hci_st_proto.recv =3D hci_st_receive;
> > +
> > + /* Packet match function may used in future */
> > + hci_st_proto.match_packet =3D NULL;
> > +
> > + /* Callback to be called when registration is pending */
> > + hci_st_proto.reg_complete_cb =3D hci_st_registration_completion_cb;
> > +
> > + /* This is write function pointer of ST. BT driver will make use of
> this
> > + * for sending any packets to chip. ST will assign and give to us, =
so
> > + * make it as NULL */
> > + hci_st_proto.write =3D NULL;
> > +
> > + /* send in the hst to be received at registration complete callback
> > + * and during st's receive
> > + */
> > + hci_st_proto.priv_data =3D hst;
> > +
> > + /* Register with ST layer */
> > + err =3D st_register(&hci_st_proto);
>
> I am still against just claiming the st_ prefix where a company called
> ST is active in the kernel as well. Is the Shared Transport really a
> proper standard?
The driver is called TI_ST, I can rename it no problem, I'm not 100% convin=
ced with this either, any suggestions for names?
> > + if (err =3D=3D -EINPROGRESS) {
> > + /* Prepare wait-for-completion handler data structures.
> > + * Needed to syncronize this and st_registration_completion=
_cb()
> > + * functions.
> > + */
> > + init_completion(&hst->wait_for_btdrv_reg_completion);
> > +
> > + /* Reset ST registration callback status flag , this value
> > + * will be updated in hci_st_registration_completion_cb()
> > + * function whenever it called from ST driver.
> > + */
> > + hst->streg_cbdata =3D -EINPROGRESS;
> > +
> > + /* ST is busy with other protocol registration(may be busy =
with
> > + * firmware download).So,Wait till the registration callbac=
k
> > + * (passed as a argument to st_register() function) getting
> > + * called from ST.
> > + */
> > + pr_debug(" %s waiting for reg completion signal from ST",
> > + __func__);
> > +
> > + timeleft =3D
> > + wait_for_completion_timeout
> > + (&hst->wait_for_btdrv_reg_completion,
> > + msecs_to_jiffies(BT_REGISTER_TIMEOUT));
> > + if (!timeleft) {
> > + pr_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 value? */
> > + if (hst->streg_cbdata !=3D 0) {
> > + pr_err("ST reg completion CB called with invalid"
> > + "status %d", hst->streg_cbdata);
> > + return -EAGAIN;
> > + }
> > + err =3D 0;
> > + } else if (err =3D=3D -1) {
> > + pr_err("st_register failed %d", err);
> > + return -EAGAIN;
> > + }
> > +
> > + /* Do we have proper ST write function? */
> > + if (hci_st_proto.write !=3D NULL) {
> > + /* We need this pointer for sending any Bluetooth pkts */
> > + hst->st_write =3D hci_st_proto.write;
> > + } else {
> > + pr_err("failed to get ST write func pointer");
> > +
> > + /* Undo registration with ST */
> > + err =3D st_unregister(ST_BT);
> > + if (err < 0)
> > + pr_err("st_unregister failed %d", err);
> > +
> > + hst->st_write =3D NULL;
> > + return -EAGAIN;
> > + }
> > +
> > + /* Registration with ST layer is completed successfully,
> > + * now chip is ready to accept commands from HCI CORE.
> > + * Mark HCI Device flag as RUNNING
> > + */
> > + set_bit(HCI_RUNNING, &hdev->flags);
> > +
> > + /* Registration with ST successful */
> > + set_bit(BT_ST_REGISTERED, &hst->flags);
> > +
> > + return err;
> > +}
> > +
> > +/* Close device */
> > +static int hci_st_close(struct hci_dev *hdev)
> > +{
> > + int err;
> > + err =3D 0;
> > +
> > + /* Unregister from ST layer */
> > + if (test_and_clear_bit(BT_ST_REGISTERED, &hst->flags)) {
> > + err =3D st_unregister(ST_BT);
> > + if (err !=3D 0) {
> > + pr_err("st_unregister failed %d", err);
> > + return -EBUSY;
> > + }
> > + }
> > +
> > + hst->st_write =3D NULL;
> > +
> > + /* ST layer would have moved chip to inactive state.
> > + * So,clear HCI device RUNNING flag.
> > + */
> > + if (!test_and_clear_bit(HCI_RUNNING, &hdev->flags))
> > + return 0;
> > +
> > + return err;
> > +}
> > +
> > +/* Called from HCI CORE , Sends frames to Shared Transport */
> > +static int hci_st_send_frame(struct sk_buff *skb)
> > +{
> > + struct hci_dev *hdev;
> > + struct hci_st *hst;
> > + long len;
> > +
> > + if (skb =3D=3D NULL) {
> > + pr_err("Invalid skb received from HCI CORE");
> > + return -ENOMEM;
> > + }
> > + hdev =3D (struct hci_dev *)skb->dev;
> > + if (!hdev) {
> > + pr_err("SKB received for invalid HCI Device (hdev=3DNULL)")=
;
> > + return -ENODEV;
> > + }
> > + if (!test_bit(HCI_RUNNING, &hdev->flags)) {
> > + pr_err("Device is not running");
> > + return -EBUSY;
> > + }
> > +
> > + hst =3D (struct hci_st *)hdev->driver_data;
> > +
> > + /* Prepend skb with frame type */
> > + memcpy(skb_push(skb, 1), &bt_cb(skb)->pkt_type, 1);
> > +
> > + pr_debug(" %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);
> > + pr_err(" Can't write to ST, st_write null?");
> > + return -EAGAIN;
> > + }
> > + len =3D hst->st_write(skb);
> > + if (len < 0) {
> > + /* Something went wrong in st write , free skb memory */
> > + kfree_skb(skb);
> > + pr_err(" ST write failed (%ld)", len);
> > + return -EAGAIN;
> > + }
> > +
> > + /* ST accepted our skb. So, Go ahead and do rest */
> > + hdev->stat.byte_tx +=3D len;
> > + hci_st_tx_complete(hst, bt_cb(skb)->pkt_type);
> > +
> > + return 0;
> > +}
> > +
> > +static void hci_st_destruct(struct hci_dev *hdev)
> > +{
> > + if (!hdev) {
> > + pr_err("Destruct called with invalid HCI Device"
> > + "(hdev=3DNULL)");
> > + return;
> > + }
> > +
> > + pr_debug("%s", hdev->name);
> > +
> > + /* free hci_st memory */
> > + if (hdev->driver_data !=3D NULL)
> > + kfree(hdev->driver_data);
> > +
> > + return;
> > +}
> > +
> > +/* Creates new HCI device */
> > +static int hci_st_register_dev(struct hci_st *hst)
> > +{
> > + struct hci_dev *hdev;
> > +
> > + /* Initialize and register HCI device */
> > + hdev =3D hci_alloc_dev();
> > + if (!hdev) {
> > + pr_err("Can't allocate HCI device");
> > + return -ENOMEM;
> > + }
> > + pr_debug(" HCI device allocated. hdev=3D %p", hdev);
> > +
> > + hst->hdev =3D hdev;
> > + hdev->bus =3D HCI_UART;
> > + hdev->driver_data =3D hst;
> > + hdev->open =3D hci_st_open;
> > + hdev->close =3D hci_st_close;
> > + hdev->flush =3D NULL;
> > + hdev->send =3D hci_st_send_frame;
> > + hdev->destruct =3D hci_st_destruct;
> > + hdev->owner =3D THIS_MODULE;
> > +
> > + if (reset)
> > + set_bit(HCI_QUIRK_NO_RESET, &hdev->quirks);
> > +
> > + if (hci_register_dev(hdev) < 0) {
> > + pr_err("Can't register HCI device");
> > + hci_free_dev(hdev);
> > + return -ENODEV;
> > + }
> > +
> > + pr_debug(" HCI device registered. hdev=3D %p", hdev);
> > + return 0;
> > +}
> > +
> > +/* ------- Module Init interface ------ */
> > +
> > +static int __init bt_drv_init(void)
> > +{
> > + int err;
> > + err =3D 0;
> > +
> > + pr_debug(" Bluetooth Driver Version %s", VERSION);
> > +
> > + /* Allocate local resource memory */
> > + hst =3D kzalloc(sizeof(struct hci_st), GFP_KERNEL);
> > + if (!hst) {
> > + pr_err("Can't allocate control structure");
> > + return -ENFILE;
> > + }
> > +
> > + /* Expose "hciX" device to user space */
> > + err =3D hci_st_register_dev(hst);
> > + if (err) {
> > + /* Release local resource memory */
> > + kfree(hst);
> > +
> > + pr_err("Unable to expose hci0 device(%d)", err);
> > + return err;
> > + }
> > + set_bit(BT_DRV_RUNNING, &hst->flags);
> > + return err;
> > +}
> > +
> > +/* ------- Module Exit interface ------ */
> > +
> > +static void __exit bt_drv_exit(void)
> > +{
> > + /* Deallocate local resource's memory */
> > + if (hst) {
> > + struct hci_dev *hdev =3D hst->hdev;
> > + if (hdev =3D=3D NULL) {
> > + pr_err("Invalid hdev memory");
> > + kfree(hst);
> > + } else {
> > + hci_st_close(hdev);
> > + if (test_and_clear_bit(BT_DRV_RUNNING, &hst->flags)=
) {
> > + /* Remove HCI device (hciX) created
> > + * in module init.
> > + */
> > + hci_unregister_dev(hdev);
> > + /* Free HCI device memory */
> > + hci_free_dev(hdev);
> > + }
> > + }
> > + }
> > +}
>
> Registering the Bluetooth HCI driver in module_init/module_exit is not
> acceptable. Turn your shared transport into a proper bus.
Yes, you did comment on it before, I remember, I did prototype the driver a=
s
a bus driver, However I didn't find any advantages by converting it to a bu=
s
driver.
As in, currently the shared transport driver is a line discipline driver be=
cause
it is the only way it can communicate over TTY without being tightly couple=
d with the UART driver.
> We want to be able to have generic kernels where this module is enabled,
> but no Shared Transport is available.
Oh if this is the reason I cannot have hci_register/_unregister in module_i=
nit/_exit, Can I do this module "depends" on TI_ST, Then it would not
even be visible to build if TI_ST is not selected.
> Regards
>
> Marcel
>
^ permalink raw reply
* Re: [PATCH 1/2] drivers:bluetooth: TI_ST bluetooth driver
From: Greg KH @ 2010-10-07 14:34 UTC (permalink / raw)
To: Marcel Holtmann
Cc: pavan-savoy, linux-bluetooth, johan.hedberg, linux-kernel,
Pavan Savoy
In-Reply-To: <1286445948.6145.70.camel@aeonflux>
On Thu, Oct 07, 2010 at 12:05:48PM +0200, Marcel Holtmann wrote:
> Hi Pavan,
>
> > 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.
> >
> > Signed-off-by: Pavan Savoy <pavan_savoy@ti.com>
> > ---
> > drivers/bluetooth/bt_ti.c | 463 ++++++++++++++++++++++++++++++++++++
> > drivers/staging/ti-st/bt_drv.c | 509 ----------------------------------------
> > drivers/staging/ti-st/bt_drv.h | 61 -----
> > 3 files changed, 463 insertions(+), 570 deletions(-)
> > create mode 100644 drivers/bluetooth/bt_ti.c
> > delete mode 100644 drivers/staging/ti-st/bt_drv.c
> > delete mode 100644 drivers/staging/ti-st/bt_drv.h
>
> I don't care about staging at all. So you sort that out with Greg.
>
> Submit your driver for upstream inclusion. And once accepted you can pin
> Greg about removing it.
The driver is already in staging, this is the request to move it out of
staging and into the "correct" place in the tree. The core of the ti-st
code is now in the drivers/misc/ directory in the linux-next tree, and
this patch is the request to move the bluetooth drive into the proper
drivers/bluetooth/ location.
thanks,
greg k-h
^ permalink raw reply
* [PATCH] TODO: Implement Server Characteristic Configuration
From: Claudio Takahasi @ 2010-10-07 14:12 UTC (permalink / raw)
To: linux-bluetooth; +Cc: Claudio Takahasi
---
TODO | 8 ++++++++
1 files changed, 8 insertions(+), 0 deletions(-)
diff --git a/TODO b/TODO
index 75a929c..d594592 100644
--- a/TODO
+++ b/TODO
@@ -18,6 +18,14 @@ Background
ATT/GATT
========
+- Implement Server characteristic Configuration support in the attribute
+ server to manage characteristic value broadcasting. There is a single
+ instance of the Server Characteristic Configuration for all clients.
+ See Volume 3, Part G, section 3.3.3.4 for more information.
+
+ Priority: Low
+ Complexity: C1
+
- Implement Client Characteristic Configuration support in the attribute
server to manage indications and notications. This is a per client attribute
to control how the client wants to receive reports of changes in a given
--
1.7.3.1
^ permalink raw reply related
* [PATCH 2/2] TODO: Implement Client Characteristic Configuration
From: Claudio Takahasi @ 2010-10-07 13:53 UTC (permalink / raw)
To: linux-bluetooth; +Cc: Claudio Takahasi
In-Reply-To: <1286459639-25194-1-git-send-email-claudio.takahasi@openbossa.org>
---
TODO | 8 ++++++++
1 files changed, 8 insertions(+), 0 deletions(-)
diff --git a/TODO b/TODO
index a9f1339..75a929c 100644
--- a/TODO
+++ b/TODO
@@ -18,6 +18,14 @@ Background
ATT/GATT
========
+- Implement Client Characteristic Configuration support in the attribute
+ server to manage indications and notications. This is a per client attribute
+ to control how the client wants to receive reports of changes in a given
+ characteristic value.
+
+ Priority: Low
+ Complexity: C2
+
- gatttool should have the ability to wait for req responses before
quitting (some servers require a small sleep even with cmd's). Maybe a
--delay-exit or --timeout command line switch.
--
1.7.3.1
^ permalink raw reply related
* [PATCH 1/2] Disable automatic notification/indication for Battery state level
From: Claudio Takahasi @ 2010-10-07 13:53 UTC (permalink / raw)
To: linux-bluetooth; +Cc: Claudio Takahasi
Reports of Battery state attribute in the Attribute sample server is
being disabled while a proper interface between the attribute server
and service implementation is not defined.
---
TODO | 7 -------
attrib/example.c | 2 ++
2 files changed, 2 insertions(+), 7 deletions(-)
diff --git a/TODO b/TODO
index 271fc45..a9f1339 100644
--- a/TODO
+++ b/TODO
@@ -18,13 +18,6 @@ Background
ATT/GATT
========
-- Sample server shouldn't send any indications or notifications without
- the client requesting them
-
- Priority: Medium
- Complexity: C2
- Owner: Claudio Takahasi <claudio.takahasi@openbossa.org>
-
- gatttool should have the ability to wait for req responses before
quitting (some servers require a small sleep even with cmd's). Maybe a
--delay-exit or --timeout command line switch.
diff --git a/attrib/example.c b/attrib/example.c
index c29e1e4..aa249a8 100644
--- a/attrib/example.c
+++ b/attrib/example.c
@@ -70,7 +70,9 @@ static gboolean change_battery_state(gpointer user_data)
/* Battery state is being increased every 10 seconds. */
atval[0] = state++;
sdp_uuid16_create(&uuid, BATTERY_STATE_UUID);
+#if 0
attrib_db_update(0x0110, &uuid, atval, 1);
+#endif
return TRUE;
}
--
1.7.3.1
^ permalink raw reply related
* Re: [PATCH 2/2] Client Characteristic Configuration on attribute server
From: Claudio Takahasi @ 2010-10-07 13:50 UTC (permalink / raw)
To: Claudio Takahasi, linux-bluetooth
In-Reply-To: <20101006214303.GB21610@jh-x301>
On Wed, Oct 6, 2010 at 6:43 PM, Johan Hedberg <johan.hedberg@gmail.com> wrote:
> Hi Claudio,
>
> On Wed, Oct 06, 2010, Claudio Takahasi wrote:
>> Initial implementation of per client attribute configuration for the
>> attribute server. Notification and indication shall be sent to the peer
>> only if Client Characteristic Configuration bit field is set.
>> ---
>> TODO | 7 --
>> src/attrib-server.c | 194 +++++++++++++++++++++++++++++++++++---------------
>> src/storage.c | 44 ++++++++++++
>> src/storage.h | 4 +
>> 4 files changed, 184 insertions(+), 65 deletions(-)
>
> I feel a bit conflicted about this one. Do we really want to have a
> generic storage for all characteristics? I'd think that it'd make sense
> to let each service implementation take care of how to store their state
> persistently (if it needs to be done at all).
>
> Would it be possible for you to create a patch that fixes the
> notification sending to clients that haven't subscribed for them but
> leaves out the storage stuff?
>
> Johan
>
Hi Johan,
"clientconfig" file stores the <<Client Characteristic Configuration>>
attribute only. Each characteristic declaration can have this optional
attribute.
The file format is:
MAC#handle xxxx, where the handle is the <<Client Characteristic
Configuration>> handle.
Only <<Client Characteristic Configuration>> and <<Server
Characteristic Configuration>> descriptors are writeable. If you want
to test this feature, my suggestion is to push this code upstream and
move it to the service implementation if necessary in the future.
Currently, we don't have this API/interface between the attrib server
and service implementation, this is the reason why I implemented the
storage inside the attrib server. IMHO, the attribute server can
manage indications, notifications and broadcasting, otherwise we will
duplicate the code in the services implementations.
I gonna send another patch to disable the automatic
notification/indication in the sample server and it is up to you to
decide which one to apply.
Claudio
^ permalink raw reply
* Re: [PATCH 4/7] Bluetooth: Use LE buffers for LE traffic
From: Marcel Holtmann @ 2010-10-07 11:07 UTC (permalink / raw)
To: Ville Tervo; +Cc: linux-bluetooth
In-Reply-To: <1286390535-27462-5-git-send-email-ville.tervo@nokia.com>
Hi Ville,
> BLuetooth chips may have separate buffers for
> LE traffic. This patch add support to use LE
> buffers provided by the chip.
>
> Signed-off-by: Ville Tervo <ville.tervo@nokia.com>
> ---
> include/net/bluetooth/hci_core.h | 6 +++
> net/bluetooth/hci_conn.c | 11 +++++-
> net/bluetooth/hci_core.c | 77 +++++++++++++++++++++++++++++++++++--
> net/bluetooth/hci_event.c | 34 ++++++++++++++++-
> 4 files changed, 120 insertions(+), 8 deletions(-)
this whole patch needs some re-thinking and proper LE init phase for
combo chips where BR/EDR and LE can share the buffers.
Regards
Marcel
^ permalink raw reply
* Re: [PATCH 3/7] Bluetooth: LE disconnection and connect cancel support
From: Marcel Holtmann @ 2010-10-07 11:04 UTC (permalink / raw)
To: Ville Tervo; +Cc: linux-bluetooth
In-Reply-To: <1286390535-27462-4-git-send-email-ville.tervo@nokia.com>
Hi Ville,
> Add supprt to cancel and disconnet connections.
>
> Signed-off-by: Ville Tervo <ville.tervo@nokia.com>
> ---
> include/net/bluetooth/hci.h | 5 ++---
> include/net/bluetooth/hci_core.h | 3 +++
> net/bluetooth/hci_conn.c | 30 ++++++++++++++++++++++++++++++
> 3 files changed, 35 insertions(+), 3 deletions(-)
>
> diff --git a/include/net/bluetooth/hci.h b/include/net/bluetooth/hci.h
> index b326240..d04ecea 100644
> --- a/include/net/bluetooth/hci.h
> +++ b/include/net/bluetooth/hci.h
> @@ -191,6 +191,8 @@ enum {
>
> #define LMP_EV4 0x01
> #define LMP_EV5 0x02
> +#define LMP_NO_BR 0x20
> +#define LMP_LE 0x40
Keep these in sync with the constants we use in userspace.
> #define LMP_SNIFF_SUBR 0x02
> #define LMP_EDR_ESCO_2M 0x20
> @@ -627,9 +629,6 @@ struct hci_cp_le_create_conn {
> } __packed;
>
> #define HCI_OP_LE_CREATE_CONN_CANCEL 0x200e
> -struct hci_cp_le_create_conn_cancel {
> - __u8 status;
> -} __packed;
>
> #define HCI_OP_LE_SET_ADVERTISE_ENABLE 0x200a
> #define LE_ADVERTISE_ENABLED 0x01
> diff --git a/include/net/bluetooth/hci_core.h b/include/net/bluetooth/hci_core.h
> index 89f4b10..a430a57 100644
> --- a/include/net/bluetooth/hci_core.h
> +++ b/include/net/bluetooth/hci_core.h
> @@ -455,10 +455,13 @@ void hci_conn_del_sysfs(struct hci_conn *conn);
> #define lmp_rswitch_capable(dev) ((dev)->features[0] & LMP_RSWITCH)
> #define lmp_encrypt_capable(dev) ((dev)->features[0] & LMP_ENCRYPT)
> #define lmp_sniff_capable(dev) ((dev)->features[0] & LMP_SNIFF)
> +#define lmp_br_capable(dev) (!((dev)->features[4] & LMP_NO_BR))
This makes no sense to me. And leave this out for now. This is more
complicated when running on LE only.
> +#define lmp_le_capable(dev) ((dev)->features[4] & LMP_LE)
I would just add this at the end of the list and not intermix it with
sniff and sniffsubr defines.
> #define lmp_sniffsubr_capable(dev) ((dev)->features[5] & LMP_SNIFF_SUBR)
> #define lmp_esco_capable(dev) ((dev)->features[3] & LMP_ESCO)
> #define lmp_ssp_capable(dev) ((dev)->features[6] & LMP_SIMPLE_PAIR)
>
> +
> /* ----- HCI protocols ----- */
> struct hci_proto {
> char *name;
> diff --git a/net/bluetooth/hci_conn.c b/net/bluetooth/hci_conn.c
> index cb41d64..50f8973 100644
> --- a/net/bluetooth/hci_conn.c
> +++ b/net/bluetooth/hci_conn.c
> @@ -66,6 +66,31 @@ void hci_le_connect(struct hci_conn *conn)
> hci_send_cmd(hdev, HCI_OP_LE_CREATE_CONN, sizeof(cp), &cp);
> }
>
> +static void hci_le_connect_cancel(struct hci_conn *conn)
> +{
> + struct hci_dev *hdev = conn->hdev;
> +
> + BT_DBG("%p", conn);
> +
> + if (!lmp_le_capable(hdev))
> + return;
This should not be needed. We should not have tried to establish a LE
link if we don't support LE in the first place.
> +
> + hci_send_cmd(conn->hdev, HCI_OP_LE_CREATE_CONN_CANCEL, 0, NULL);
> +}
> +
> +void hci_le_disconn(struct hci_conn *conn, __u8 reason)
> +{
> + struct hci_cp_disconnect cp;
> +
> + BT_DBG("%p", conn);
> +
> + conn->le_state = BT_DISCONN;
> +
> + cp.handle = cpu_to_le16(conn->handle);
> + cp.reason = reason;
> + hci_send_cmd(conn->hdev, HCI_OP_DISCONNECT, sizeof(cp), &cp);
> +}
When just using conn->state, then this becomes obsolete and we can use
the generic one.
> +
> void hci_acl_connect(struct hci_conn *conn)
> {
> struct hci_dev *hdev = conn->hdev;
> @@ -221,6 +246,8 @@ static void hci_conn_timeout(unsigned long arg)
> case BT_CONNECT2:
> if (conn->type == ACL_LINK && conn->out)
> hci_acl_connect_cancel(conn);
> + if (conn->type == LE_LINK && conn->out)
> + hci_le_connect_cancel(conn);
This should be redone with as this:
if (conn->out) {
if (ACL_LINK)
...
else if (LE_LINK)
...
}
> break;
> case BT_CONFIG:
> case BT_CONNECTED:
> @@ -397,6 +424,9 @@ struct hci_conn *hci_connect(struct hci_dev *hdev, int type, bdaddr_t *dst, __u8
> BT_DBG("%s dst %s", hdev->name, batostr(dst));
>
> if (type == LE_LINK) {
> + if (!lmp_le_capable(hdev))
> + return NULL;
> +
> le = hci_conn_hash_lookup_ba(hdev, LE_LINK, dst);
>
> if (!le)
We might need to move that lmp_le_capable check into L2CAP. Since
otherwise we can not give a proper return value if someone tries to use
LE on a BR/EDR only controller.
Regards
Marcel
^ permalink raw reply
* Re: [PATCH 2/7] Bluetooth: Add LE connect support
From: Marcel Holtmann @ 2010-10-07 10:58 UTC (permalink / raw)
To: Ville Tervo; +Cc: linux-bluetooth
In-Reply-To: <1286390535-27462-3-git-send-email-ville.tervo@nokia.com>
Hi Ville,
> Add logic to create LE connections.
>
> Signed-off-by: Ville Tervo <ville.tervo@nokia.com>
> ---
> include/net/bluetooth/hci.h | 1 +
> include/net/bluetooth/hci_core.h | 6 ++-
> net/bluetooth/hci_conn.c | 38 ++++++++++++++-
> net/bluetooth/hci_event.c | 100 +++++++++++++++++++++++++++++++++++++-
> 4 files changed, 141 insertions(+), 4 deletions(-)
>
> diff --git a/include/net/bluetooth/hci.h b/include/net/bluetooth/hci.h
> index b86aed5..b326240 100644
> --- a/include/net/bluetooth/hci.h
> +++ b/include/net/bluetooth/hci.h
> @@ -162,6 +162,7 @@ enum {
> #define SCO_LINK 0x00
> #define ACL_LINK 0x01
> #define ESCO_LINK 0x02
> +#define LE_LINK 0x03
this is not a value defined by the specification, while the others are.
And some functions match these to HCI event. So if wanna do it like
this, then using something like 0x80 is better.
> /* LMP features */
> #define LMP_3SLOT 0x01
> diff --git a/include/net/bluetooth/hci_core.h b/include/net/bluetooth/hci_core.h
> index ebec8c9..89f4b10 100644
> --- a/include/net/bluetooth/hci_core.h
> +++ b/include/net/bluetooth/hci_core.h
> @@ -170,6 +170,7 @@ struct hci_conn {
> bdaddr_t dst;
> __u16 handle;
> __u16 state;
> + __u16 le_state;
I don't see the need for a separate state here. The LE link is different
from an ACL link and also from a SCO link. We will create a new hci_conn
for each type of link.
> __u8 mode;
> __u8 type;
> __u8 out;
> @@ -203,6 +204,7 @@ struct hci_conn {
> struct hci_dev *hdev;
> void *l2cap_data;
> void *sco_data;
> + void *le_data;
> void *priv;
What is the use of le_data here?
> struct hci_conn *link;
> @@ -272,7 +274,7 @@ static inline void hci_conn_hash_add(struct hci_dev *hdev, struct hci_conn *c)
> {
> struct hci_conn_hash *h = &hdev->conn_hash;
> list_add(&c->list, &h->list);
> - if (c->type == ACL_LINK)
> + if (c->type == ACL_LINK || c->type == LE_LINK)
> h->acl_num++;
> else
> h->sco_num++;
> @@ -282,7 +284,7 @@ static inline void hci_conn_hash_del(struct hci_dev *hdev, struct hci_conn *c)
> {
> struct hci_conn_hash *h = &hdev->conn_hash;
> list_del(&c->list);
> - if (c->type == ACL_LINK)
> + if (c->type == ACL_LINK || c->type == LE_LINK)
> h->acl_num--;
> else
> h->sco_num--;
I would assume that counting LE connection separately would be way
better. We could have ACL link to one device and LE link to another.
> diff --git a/net/bluetooth/hci_conn.c b/net/bluetooth/hci_conn.c
> index 145993f..cb41d64 100644
> --- a/net/bluetooth/hci_conn.c
> +++ b/net/bluetooth/hci_conn.c
> @@ -45,6 +45,27 @@
> #include <net/bluetooth/bluetooth.h>
> #include <net/bluetooth/hci_core.h>
>
> +void hci_le_connect(struct hci_conn *conn)
> +{
> + struct hci_dev *hdev = conn->hdev;
> + struct hci_cp_le_create_conn cp;
> +
> + conn->le_state = BT_CONNECT;
> + conn->out = 1;
> +
> + memset(&cp, 0, sizeof(cp));
> + cp.scan_interval = cpu_to_le16(0x0004);
> + cp.scan_window = cpu_to_le16(0x0004);
> + bacpy(&cp.peer_addr, &conn->dst);
> + cp.conn_interval_min = cpu_to_le16(0x0008);
> + cp.conn_interval_max = cpu_to_le16(0x0100);
> + cp.supervision_timeout = cpu_to_le16(0x0064);
> + cp.min_ce_len = cpu_to_le16(0x0001);
> + cp.max_ce_len = cpu_to_le16(0xffff);
> +
> + hci_send_cmd(hdev, HCI_OP_LE_CREATE_CONN, sizeof(cp), &cp);
> +}
> +
> void hci_acl_connect(struct hci_conn *conn)
> {
> struct hci_dev *hdev = conn->hdev;
> @@ -365,15 +386,30 @@ struct hci_dev *hci_get_route(bdaddr_t *dst, bdaddr_t *src)
> }
> EXPORT_SYMBOL(hci_get_route);
>
> -/* Create SCO or ACL connection.
> +/* Create SCO, ACL or LE connection.
> * Device _must_ be locked */
> struct hci_conn *hci_connect(struct hci_dev *hdev, int type, bdaddr_t *dst, __u8 sec_level, __u8 auth_type)
> {
> struct hci_conn *acl;
> struct hci_conn *sco;
> + struct hci_conn *le;
>
> BT_DBG("%s dst %s", hdev->name, batostr(dst));
>
> + if (type == LE_LINK) {
> + le = hci_conn_hash_lookup_ba(hdev, LE_LINK, dst);
> +
> + if (!le)
> + le = hci_conn_add(hdev, LE_LINK, dst);
> +
> + if (!le)
> + return NULL;
> +
> + hci_le_connect(le);
> +
> + return le;
> + }
> +
> if (!(acl = hci_conn_hash_lookup_ba(hdev, ACL_LINK, dst))) {
> if (!(acl = hci_conn_add(hdev, ACL_LINK, dst)))
> return NULL;
No liking it this much. We might have to re-think on how to do things
here.
> diff --git a/net/bluetooth/hci_event.c b/net/bluetooth/hci_event.c
> index d3c68de..0b979ae 100644
> --- a/net/bluetooth/hci_event.c
> +++ b/net/bluetooth/hci_event.c
> @@ -868,6 +868,44 @@ static void hci_cc_le_set_scan(struct hci_dev *hdev, struct sk_buff *skb)
> hci_req_complete(hdev, status);
> }
>
> +static void hci_cs_le_create_conn(struct hci_dev *hdev, __u8 status)
> +{
> + struct hci_cp_le_create_conn *cp;
> + struct hci_conn *conn;
> +
> + BT_DBG("%s status 0x%x", hdev->name, status);
> +
> + cp = hci_sent_cmd_data(hdev, HCI_OP_LE_CREATE_CONN);
> + if (!cp)
> + return;
> +
> + hci_dev_lock(hdev);
> +
> + conn = hci_conn_hash_lookup_ba(hdev, LE_LINK, &cp->peer_addr);
> +
> + BT_DBG("%s bdaddr %s conn %p", hdev->name, batostr(&cp->peer_addr),
> + conn);
> +
> + if (status) {
> + if (conn && conn->le_state == BT_CONNECT) {
> + conn->le_state = BT_CLOSED;
> + hci_proto_connect_cfm(conn, status);
> + hci_conn_del(conn);
> + }
> + } else {
> + if (!conn) {
> + conn = hci_conn_add(hdev, LE_LINK, &cp->peer_addr);
> + if (conn) {
> + conn->out = 1;
> + conn->link_mode |= HCI_LM_MASTER;
> + } else
> + BT_ERR("No memory for new connection");
> + }
> + }
> +
> + hci_dev_unlock(hdev);
> +}
Do we have the master/slave association with LE?
> static inline void hci_inquiry_complete_evt(struct hci_dev *hdev, struct sk_buff *skb)
> {
> __u8 status = *((__u8 *) skb->data);
> @@ -1069,7 +1107,10 @@ static inline void hci_disconn_complete_evt(struct hci_dev *hdev, struct sk_buff
>
> conn = hci_conn_hash_lookup_handle(hdev, __le16_to_cpu(ev->handle));
> if (conn) {
> - conn->state = BT_CLOSED;
> + if (conn->type == LE_LINK)
> + conn->le_state = BT_CLOSED;
> + else
> + conn->state = BT_CLOSED;
If we would just use conn->state then this should not be needed.
> hci_proto_disconn_cfm(conn, ev->reason);
> hci_conn_del(conn);
> @@ -1430,6 +1471,10 @@ static inline void hci_cmd_status_evt(struct hci_dev *hdev, struct sk_buff *skb)
> hci_cs_exit_sniff_mode(hdev, ev->status);
> break;
>
> + case HCI_OP_LE_CREATE_CONN:
> + hci_cs_le_create_conn(hdev, ev->status);
> + break;
> +
> default:
> BT_DBG("%s opcode 0x%x", hdev->name, opcode);
> break;
> @@ -1875,6 +1920,55 @@ static inline void hci_remote_host_features_evt(struct hci_dev *hdev, struct sk_
> hci_dev_unlock(hdev);
> }
>
> +static inline void hci_le_conn_complete_evt(struct hci_dev *hdev, struct sk_buff *skb)
> +{
> + struct hci_ev_le_conn_complete *ev = (void *) skb->data;
> + struct hci_conn *conn;
> +
> + BT_DBG("%s status %d", hdev->name, ev->status);
> +
> + hci_dev_lock(hdev);
> +
> + conn = hci_conn_hash_lookup_ba(hdev, LE_LINK, &ev->bdaddr);
> +
> + if (!conn)
> + goto unlock;
The empty line between conn assignment and check should be removed.
> +
> + if (ev->status) {
> + hci_proto_connect_cfm(conn, ev->status);
> + conn->le_state = BT_CLOSED;
> + hci_conn_del(conn);
> + goto unlock;
> + }
> +
> + conn->handle = __le16_to_cpu(ev->handle);
> + conn->le_state = BT_CONNECTED;
> +
> + hci_conn_hold_device(conn);
> + hci_conn_add_sysfs(conn);
> +
> + hci_proto_connect_cfm(conn, ev->status);
> +unlock:
> + hci_dev_unlock(hdev);
And here you should have an empty line between the label and the last
statement before the label.
> +}
> +
> +static inline void hci_le_meta_evt(struct hci_dev *hdev, struct sk_buff *skb)
> +{
> + struct hci_ev_le_meta *le_ev = (void *) skb->data;
> + __u8 event = le_ev->subevent;
Why?
> +
> + skb_pull(skb, sizeof(*le_ev));
> +
> + switch (event) {
Using le_ev->subevent would be just fine here.
> + case HCI_EV_LE_CONN_COMPLETE:
> + hci_le_conn_complete_evt(hdev, skb);
> + break;
> +
> + default:
> + break;
> + }
> +}
> +
> void hci_event_packet(struct hci_dev *hdev, struct sk_buff *skb)
> {
> struct hci_event_hdr *hdr = (void *) skb->data;
> @@ -2011,6 +2105,10 @@ void hci_event_packet(struct hci_dev *hdev, struct sk_buff *skb)
> hci_remote_host_features_evt(hdev, skb);
> break;
>
> + case HCI_EV_LE_META:
> + hci_le_meta_evt(hdev, skb);
> + break;
> +
> default:
> BT_DBG("%s event 0x%x", hdev->name, event);
> break;
Regards
Marcel
^ permalink raw reply
* Re: [PATCH 1/7] Bluetooth: Add low energy commands and events
From: Marcel Holtmann @ 2010-10-07 10:08 UTC (permalink / raw)
To: Ville Tervo; +Cc: linux-bluetooth
In-Reply-To: <1286390535-27462-2-git-send-email-ville.tervo@nokia.com>
Hi Ville,
> Add needed HCI command and event to create LE connections.
>
> Signed-off-by: Ville Tervo <ville.tervo@nokia.com>
Acked-by: Marcel Holtmann <marcel@holtmann.org>
Regards
Marcel
^ permalink raw reply
* Re: [PATCH 1/2] drivers:bluetooth: TI_ST bluetooth driver
From: Marcel Holtmann @ 2010-10-07 10:05 UTC (permalink / raw)
To: pavan-savoy
Cc: linux-bluetooth, johan.hedberg, greg, linux-kernel, Pavan Savoy
In-Reply-To: <1286404493-23816-2-git-send-email-pavan-savoy@ti.com>
Hi Pavan,
> 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.
>
> Signed-off-by: Pavan Savoy <pavan_savoy@ti.com>
> ---
> drivers/bluetooth/bt_ti.c | 463 ++++++++++++++++++++++++++++++++++++
> drivers/staging/ti-st/bt_drv.c | 509 ----------------------------------------
> drivers/staging/ti-st/bt_drv.h | 61 -----
> 3 files changed, 463 insertions(+), 570 deletions(-)
> create mode 100644 drivers/bluetooth/bt_ti.c
> delete mode 100644 drivers/staging/ti-st/bt_drv.c
> delete mode 100644 drivers/staging/ti-st/bt_drv.h
I don't care about staging at all. So you sort that out with Greg.
Submit your driver for upstream inclusion. And once accepted you can pin
Greg about removing it.
> diff --git a/drivers/bluetooth/bt_ti.c b/drivers/bluetooth/bt_ti.c
> new file mode 100644
> index 0000000..4f3d3aa
> --- /dev/null
> +++ b/drivers/bluetooth/bt_ti.c
> @@ -0,0 +1,463 @@
> +/*
> + * 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 modify
> + * 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-1307 USA
> + *
> + */
> +
> +#define pr_fmt(fmt) "(tibt): " fmt
Don't do this. Just use BT_DBG, BT_ERR, BT_INFO etc.
> +#include <net/bluetooth/bluetooth.h>
> +#include <net/bluetooth/hci_core.h>
> +
> +#include <linux/ti_wilink_st.h>
> +
> +/* Bluetooth Driver Version */
> +#define VERSION "1.0"
> +
> +/* Defines number of seconds to wait for reg completion
> + * callback getting called from ST (in case,registration
> + * with ST returns PENDING status)
> + */
> +#define BT_REGISTER_TIMEOUT 6000 /* 6 sec */
> +
> +/* BT driver's local status */
> +#define BT_DRV_RUNNING 0
> +#define BT_ST_REGISTERED 1
> +
> +/**
> + * struct hci_st - BT driver operation structure
> + * @hdev: hci device pointer which binds to bt driver
> + * @flags: used locally,to maintain various BT driver status
> + * @streg_cbdata: to hold ST registration callback status
> + * @st_write: write function pointer of ST driver
> + * @wait_for_btdrv_reg_completion - completion sync between hci_st_open
> + * and hci_st_registration_completion_cb.
> + */
> +struct hci_st {
> + struct hci_dev *hdev;
> + unsigned long flags;
> + char streg_cbdata;
> + long (*st_write) (struct sk_buff *);
> + struct completion wait_for_btdrv_reg_completion;
> +};
> +
> +static struct hci_st *hst;
> +static int reset;
> +
> +/* Increments HCI counters based on pocket ID (cmd,acl,sco) */
> +static inline void hci_st_tx_complete(struct hci_st *hst, int pkt_type)
> +{
> + struct hci_dev *hdev;
> + hdev = 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.cmd_tx++;
> + break;
> + }
> +}
> +
> +/* ------- Interfaces to Shared Transport ------ */
> +
> +/* Called by ST layer to indicate protocol registration completion
> + * status.hci_st_open() function will wait for signal from this
> + * API when st_register() function returns ST_PENDING.
> + */
> +static void hci_st_registration_completion_cb(void *priv_data, char data)
> +{
> + struct hci_st *lhst = (struct hci_st *)priv_data;
> + /* hci_st_open() function needs value of 'data' to know
> + * the registration status(success/fail),So have a back
> + * up of it.
> + */
> + lhst->streg_cbdata = data;
> +
> + /* Got a feedback from ST for BT driver registration
> + * request.Wackup hci_st_open() function to continue
> + * it's open operation.
> + */
> + complete(&lhst->wait_for_btdrv_reg_completion);
> +}
> +
> +/* Called by Shared Transport layer when receive data is
> + * available */
> +static long hci_st_receive(void *priv_data, struct sk_buff *skb)
> +{
> + int err;
> + int len;
> + struct hci_st *lhst = (struct hci_st *)priv_data;
> +
> + err = 0;
> + len = 0;
> +
> + if (skb == NULL) {
> + pr_err("Invalid SKB received from ST");
> + return -EFAULT;
> + }
> + if (!lhst) {
> + kfree_skb(skb);
> + pr_err("Invalid hci_st memory,freeing SKB");
> + return -EFAULT;
> + }
> + if (!test_bit(BT_DRV_RUNNING, &lhst->flags)) {
> + kfree_skb(skb);
> + pr_err("Device is not running,freeing SKB");
> + return -EINVAL;
> + }
> +
> + len = skb->len;
> + skb->dev = (struct net_device *)lhst->hdev;
> +
> + /* Forward skb to HCI CORE layer */
> + err = hci_recv_frame(skb);
> + if (err) {
> + kfree_skb(skb);
> + pr_err("Unable to push skb to HCI CORE(%d),freeing SKB",
> + err);
> + return err;
> + }
> + lhst->hdev->stat.byte_rx += len;
> +
> + return 0;
> +}
> +
> +/* ------- Interfaces to HCI layer ------ */
> +
> +/* Called from HCI core to initialize the device */
> +static int hci_st_open(struct hci_dev *hdev)
> +{
> + static struct st_proto_s hci_st_proto;
> + unsigned long timeleft;
> + int err;
> + err = 0;
> +
> + pr_debug("%s %p", hdev->name, hdev);
> +
> + /* Already registered with ST ? */
> + if (test_bit(BT_ST_REGISTERED, &hst->flags)) {
> + pr_err("Registered with ST already,open called again?");
> + return 0;
> + }
Why are you testing against this. This should be not needed at all.
> + /* Populate BT driver info required by ST */
> + memset(&hci_st_proto, 0, sizeof(hci_st_proto));
> +
> + /* BT driver ID */
> + hci_st_proto.type = ST_BT;
> +
> + /* Receive function which called from ST */
> + hci_st_proto.recv = hci_st_receive;
> +
> + /* Packet match function may used in future */
> + hci_st_proto.match_packet = NULL;
> +
> + /* Callback to be called when registration is pending */
> + hci_st_proto.reg_complete_cb = hci_st_registration_completion_cb;
> +
> + /* This is write function pointer of ST. BT driver will make use of this
> + * for sending any packets to chip. ST will assign and give to us, so
> + * make it as NULL */
> + hci_st_proto.write = NULL;
> +
> + /* send in the hst to be received at registration complete callback
> + * and during st's receive
> + */
> + hci_st_proto.priv_data = hst;
> +
> + /* Register with ST layer */
> + err = st_register(&hci_st_proto);
I am still against just claiming the st_ prefix where a company called
ST is active in the kernel as well. Is the Shared Transport really a
proper standard?
> + if (err == -EINPROGRESS) {
> + /* Prepare wait-for-completion handler data structures.
> + * Needed to syncronize this and st_registration_completion_cb()
> + * functions.
> + */
> + init_completion(&hst->wait_for_btdrv_reg_completion);
> +
> + /* Reset ST registration callback status flag , this value
> + * will be updated in hci_st_registration_completion_cb()
> + * function whenever it called from ST driver.
> + */
> + hst->streg_cbdata = -EINPROGRESS;
> +
> + /* ST is busy with other protocol registration(may be busy with
> + * firmware download).So,Wait till the registration callback
> + * (passed as a argument to st_register() function) getting
> + * called from ST.
> + */
> + pr_debug(" %s waiting for reg completion signal from ST",
> + __func__);
> +
> + timeleft =
> + wait_for_completion_timeout
> + (&hst->wait_for_btdrv_reg_completion,
> + msecs_to_jiffies(BT_REGISTER_TIMEOUT));
> + if (!timeleft) {
> + pr_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 value? */
> + if (hst->streg_cbdata != 0) {
> + pr_err("ST reg completion CB called with invalid"
> + "status %d", hst->streg_cbdata);
> + return -EAGAIN;
> + }
> + err = 0;
> + } else if (err == -1) {
> + pr_err("st_register failed %d", err);
> + return -EAGAIN;
> + }
> +
> + /* Do we have proper ST write function? */
> + if (hci_st_proto.write != NULL) {
> + /* We need this pointer for sending any Bluetooth pkts */
> + hst->st_write = hci_st_proto.write;
> + } else {
> + pr_err("failed to get ST write func pointer");
> +
> + /* Undo registration with ST */
> + err = st_unregister(ST_BT);
> + if (err < 0)
> + pr_err("st_unregister failed %d", err);
> +
> + hst->st_write = NULL;
> + return -EAGAIN;
> + }
> +
> + /* Registration with ST layer is completed successfully,
> + * now chip is ready to accept commands from HCI CORE.
> + * Mark HCI Device flag as RUNNING
> + */
> + set_bit(HCI_RUNNING, &hdev->flags);
> +
> + /* Registration with ST successful */
> + set_bit(BT_ST_REGISTERED, &hst->flags);
> +
> + return err;
> +}
> +
> +/* Close device */
> +static int hci_st_close(struct hci_dev *hdev)
> +{
> + int err;
> + err = 0;
> +
> + /* Unregister from ST layer */
> + if (test_and_clear_bit(BT_ST_REGISTERED, &hst->flags)) {
> + err = st_unregister(ST_BT);
> + if (err != 0) {
> + pr_err("st_unregister failed %d", err);
> + return -EBUSY;
> + }
> + }
> +
> + hst->st_write = NULL;
> +
> + /* ST layer would have moved chip to inactive state.
> + * So,clear HCI device RUNNING flag.
> + */
> + if (!test_and_clear_bit(HCI_RUNNING, &hdev->flags))
> + return 0;
> +
> + return err;
> +}
> +
> +/* Called from HCI CORE , Sends frames to Shared Transport */
> +static int hci_st_send_frame(struct sk_buff *skb)
> +{
> + struct hci_dev *hdev;
> + struct hci_st *hst;
> + long len;
> +
> + if (skb == NULL) {
> + pr_err("Invalid skb received from HCI CORE");
> + return -ENOMEM;
> + }
> + hdev = (struct hci_dev *)skb->dev;
> + if (!hdev) {
> + pr_err("SKB received for invalid HCI Device (hdev=NULL)");
> + return -ENODEV;
> + }
> + if (!test_bit(HCI_RUNNING, &hdev->flags)) {
> + pr_err("Device is not running");
> + return -EBUSY;
> + }
> +
> + hst = (struct hci_st *)hdev->driver_data;
> +
> + /* Prepend skb with frame type */
> + memcpy(skb_push(skb, 1), &bt_cb(skb)->pkt_type, 1);
> +
> + pr_debug(" %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);
> + pr_err(" Can't write to ST, st_write null?");
> + return -EAGAIN;
> + }
> + len = hst->st_write(skb);
> + if (len < 0) {
> + /* Something went wrong in st write , free skb memory */
> + kfree_skb(skb);
> + pr_err(" ST write failed (%ld)", len);
> + return -EAGAIN;
> + }
> +
> + /* ST accepted our skb. So, Go ahead and do rest */
> + hdev->stat.byte_tx += len;
> + hci_st_tx_complete(hst, bt_cb(skb)->pkt_type);
> +
> + return 0;
> +}
> +
> +static void hci_st_destruct(struct hci_dev *hdev)
> +{
> + if (!hdev) {
> + pr_err("Destruct called with invalid HCI Device"
> + "(hdev=NULL)");
> + return;
> + }
> +
> + pr_debug("%s", hdev->name);
> +
> + /* free hci_st memory */
> + if (hdev->driver_data != NULL)
> + kfree(hdev->driver_data);
> +
> + return;
> +}
> +
> +/* Creates new HCI device */
> +static int hci_st_register_dev(struct hci_st *hst)
> +{
> + struct hci_dev *hdev;
> +
> + /* Initialize and register HCI device */
> + hdev = hci_alloc_dev();
> + if (!hdev) {
> + pr_err("Can't allocate HCI device");
> + return -ENOMEM;
> + }
> + pr_debug(" HCI device allocated. hdev= %p", hdev);
> +
> + hst->hdev = hdev;
> + hdev->bus = HCI_UART;
> + hdev->driver_data = hst;
> + hdev->open = hci_st_open;
> + hdev->close = hci_st_close;
> + hdev->flush = NULL;
> + hdev->send = hci_st_send_frame;
> + hdev->destruct = hci_st_destruct;
> + hdev->owner = THIS_MODULE;
> +
> + if (reset)
> + set_bit(HCI_QUIRK_NO_RESET, &hdev->quirks);
> +
> + if (hci_register_dev(hdev) < 0) {
> + pr_err("Can't register HCI device");
> + hci_free_dev(hdev);
> + return -ENODEV;
> + }
> +
> + pr_debug(" HCI device registered. hdev= %p", hdev);
> + return 0;
> +}
> +
> +/* ------- Module Init interface ------ */
> +
> +static int __init bt_drv_init(void)
> +{
> + int err;
> + err = 0;
> +
> + pr_debug(" Bluetooth Driver Version %s", VERSION);
> +
> + /* Allocate local resource memory */
> + hst = kzalloc(sizeof(struct hci_st), GFP_KERNEL);
> + if (!hst) {
> + pr_err("Can't allocate control structure");
> + return -ENFILE;
> + }
> +
> + /* Expose "hciX" device to user space */
> + err = hci_st_register_dev(hst);
> + if (err) {
> + /* Release local resource memory */
> + kfree(hst);
> +
> + pr_err("Unable to expose hci0 device(%d)", err);
> + return err;
> + }
> + set_bit(BT_DRV_RUNNING, &hst->flags);
> + return err;
> +}
> +
> +/* ------- Module Exit interface ------ */
> +
> +static void __exit bt_drv_exit(void)
> +{
> + /* Deallocate local resource's memory */
> + if (hst) {
> + struct hci_dev *hdev = hst->hdev;
> + if (hdev == NULL) {
> + pr_err("Invalid hdev memory");
> + kfree(hst);
> + } else {
> + hci_st_close(hdev);
> + if (test_and_clear_bit(BT_DRV_RUNNING, &hst->flags)) {
> + /* Remove HCI device (hciX) created
> + * in module init.
> + */
> + hci_unregister_dev(hdev);
> + /* Free HCI device memory */
> + hci_free_dev(hdev);
> + }
> + }
> + }
> +}
Registering the Bluetooth HCI driver in module_init/module_exit is not
acceptable. Turn your shared transport into a proper bus.
We want to be able to have generic kernels where this module is enabled,
but no Shared Transport is available.
Regards
Marcel
^ permalink raw reply
* Re: Inquiry_with_RSSI compatible dongles
From: Marcel Holtmann @ 2010-10-07 9:42 UTC (permalink / raw)
To: Giedo Mak; +Cc: linux-bluetooth
In-Reply-To: <AANLkTinqj=v9CT4RvnekAymtvXL4rFGMGjr5HNjGwUsW@mail.gmail.com>
Hi Giedo,
> I got myself a brandless bluetooth 2.1 dongle (at least, that's what
> is says on the box).
> In hciconfig I got something about HCI version 2.0:
>
> HCI Version: 2.0 (0x3) Revision: 0x44
> LMP Version: 2.0 (0x3) Subversion: 0x3
> Manufacturer: Cambridge Silicon Radio (10)
>
> Does that mean it is a BT 2.0 device?
>
> I would like to ask a second question:
> When I put the device in inqmode 1, (the dongle has the feature
> inquiry with rssi; I checked with hciconfig hci0 features)
>
> Inquiry mode: Inquiry with RSSI
>
> I get 'Inquiry result with RSSI'-events. But these events have a
> constant RSSI value.
> I would like know if this is a known bug, or if there is a setting I
> have to set.
> This is a little hcidump output:
>
> > HCI Event: Inquiry Result with RSSI (0x22) plen 15
> 01 5C 07 D3 D7 23 00 01 02 04 02 5A 7E 70 00
> > HCI Event: Inquiry Result with RSSI (0x22) plen 15
> 01 1C 01 00 81 1F 00 01 02 04 01 02 40 7E 00
> > HCI Event: Inquiry Complete (0x01) plen 1
> 00
> > HCI Event: Inquiry Result with RSSI (0x22) plen 15
> 01 5C 07 D3 D7 23 00 01 02 04 02 5A 7E 70 00
> > HCI Event: Inquiry Result with RSSI (0x22) plen 15
> 01 89 99 66 D0 25 00 01 02 0C 02 5A 61 15 00
> > HCI Event: Inquiry Complete (0x01) plen 1
> 00
> > HCI Event: Inquiry Result with RSSI (0x22) plen 15
> 01 1C 01 00 81 1F 00 01 02 04 01 02 3F 7E 00
> > HCI Event: Inquiry Result with RSSI (0x22) plen 15
> 01 5C 07 D3 D7 23 00 01 02 04 02 5A 7D 70 00
> > HCI Event: Inquiry Result with RSSI (0x22) plen 15
> 01 89 99 66 D0 25 00 01 02 0C 02 5A 61 15 00
> > HCI Event: Inquiry Complete (0x01) plen 1
> 00
>
> If I'm correct the RSSI value should be the last octet, which is always 0.
>
> I've tested also with another bluetooth dongle, this was a 2.0 BT
> dongle also with the inquiry with rssi feature. That dongle gave me
> (valid) RSSI values in the returned events between -40 and -90.
>
> The last dongle is not longer in my possession, so I would like to fix
> the first one.
you just got a bad dongle. Some claim RSSI reporting support, but never
do anything like that. Proper hardware will look like this:
> HCI Event: Inquiry Result with RSSI (0x22) plen 15
bdaddr 00:21:86:47:51:B9 mode 1 clkoffset 0x47f6 class 0x00010c rssi -84
> HCI Event: Inquiry Result with RSSI (0x22) plen 15
bdaddr 00:16:CF:D7:DD:72 mode 1 clkoffset 0x5662 class 0x00010c rssi -85
> HCI Event: Extended Inquiry Result (0x2f) plen 255
bdaddr D8:54:3A:7E:9C:9A mode 1 clkoffset 0x2d71 class 0x5a020c rssi -57
Complete local name: 'Nokia'
Complete service classes: 0x1112 0x111f 0x110a 0x110c 0x110e 0x1103 0x1105 0x1106 0x112f
Regards
Marcel
^ permalink raw reply
* Re: Inquiry_with_RSSI compatible dongles
From: Giedo Mak @ 2010-10-07 9:34 UTC (permalink / raw)
To: Marcel Holtmann; +Cc: linux-bluetooth
In-Reply-To: <1286264216.17473.17.camel@aeonflux>
2010/10/5 Marcel Holtmann <marcel@holtmann.org>
>
> Hi Giedo,
>
> > I'm working on a bluetooth program with some sort of distance sensing/tracking.
> > To make this easier I came across a feature called inquiry_with_RSSI.
> > Could somebody tell me what kind of dongles support this feature. I
> > mean, does every 2.1 BT dongle support it, or can you only find out
> > once you get one in your hands?
>
> in general every Bluetooth 1.2 dongle and later should support Inquiry
> with RSSI. I still have to come across a 2.1 dongle that doesn't.
>
> Regards
>
> Marcel
>
Hello Marcel,
Thanks for your fast response.
I got myself a brandless bluetooth 2.1 dongle (at least, that's what
is says on the box).
In hciconfig I got something about HCI version 2.0:
HCI Version: 2.0 (0x3) Revision: 0x44
LMP Version: 2.0 (0x3) Subversion: 0x3
Manufacturer: Cambridge Silicon Radio (10)
Does that mean it is a BT 2.0 device?
I would like to ask a second question:
When I put the device in inqmode 1, (the dongle has the feature
inquiry with rssi; I checked with hciconfig hci0 features)
Inquiry mode: Inquiry with RSSI
I get 'Inquiry result with RSSI'-events. But these events have a
constant RSSI value.
I would like know if this is a known bug, or if there is a setting I
have to set.
This is a little hcidump output:
> HCI Event: Inquiry Result with RSSI (0x22) plen 15
01 5C 07 D3 D7 23 00 01 02 04 02 5A 7E 70 00
> HCI Event: Inquiry Result with RSSI (0x22) plen 15
01 1C 01 00 81 1F 00 01 02 04 01 02 40 7E 00
> HCI Event: Inquiry Complete (0x01) plen 1
00
> HCI Event: Inquiry Result with RSSI (0x22) plen 15
01 5C 07 D3 D7 23 00 01 02 04 02 5A 7E 70 00
> HCI Event: Inquiry Result with RSSI (0x22) plen 15
01 89 99 66 D0 25 00 01 02 0C 02 5A 61 15 00
> HCI Event: Inquiry Complete (0x01) plen 1
00
> HCI Event: Inquiry Result with RSSI (0x22) plen 15
01 1C 01 00 81 1F 00 01 02 04 01 02 3F 7E 00
> HCI Event: Inquiry Result with RSSI (0x22) plen 15
01 5C 07 D3 D7 23 00 01 02 04 02 5A 7D 70 00
> HCI Event: Inquiry Result with RSSI (0x22) plen 15
01 89 99 66 D0 25 00 01 02 0C 02 5A 61 15 00
> HCI Event: Inquiry Complete (0x01) plen 1
00
If I'm correct the RSSI value should be the last octet, which is always 0.
I've tested also with another bluetooth dongle, this was a 2.0 BT
dongle also with the inquiry with rssi feature. That dongle gave me
(valid) RSSI values in the returned events between -40 and -90.
The last dongle is not longer in my possession, so I would like to fix
the first one.
Regards,
Giedo
^ permalink raw reply
* Re: pull-request: bluetooth-2.6 2010-10-05
From: David Miller @ 2010-10-07 8:02 UTC (permalink / raw)
To: padovan; +Cc: linville, marcel, linux-bluetooth, netdev
In-Reply-To: <20101005171349.GA16520@vigoh>
From: "Gustavo F. Padovan" <padovan@profusion.mobi>
Date: Tue, 5 Oct 2010 14:13:49 -0300
> In this patch set we have two fixes for regressions in L2CAP due to ERTM code
> we added in L2CAP for 2.6.36, a bugfix in the L2CAP Streaming Mode that was
> making the kernel crash. And a fix for a deadlock issue between the sk_sndbuf
> and the backlog queue in ERTM. The rest are also needed bug fixes.
Pulled, thanks.
^ permalink raw reply
* Re: Check for connections and disable bluetooth in shell
From: Jonathan Haug @ 2010-10-07 5:01 UTC (permalink / raw)
To: linux-bluetooth
In-Reply-To: <20100831060429.GA15844@vigoh>
Am Dienstag, den 31.08.2010, 03:04 -0300 schrieb Gustavo F. Padovan:
> >
> > I want to disable bluetooth on my system (via commandline), if there is
> > no active bluetooth connection -- without being root.
> >
> > Therefor I need a way to
> >
> > 1. check if there is an active bluetooth connection
>
> 'hcitool conn' can show that to you.
>
Just to complete this thread:
Thanks Gustavo! I'm now using the following script:
if grep -q off-line /proc/acpi/ac_adapter/ACAD/state; then
if !(hcitool con | grep -q "state"); then
rfkill block bluetooth
fi
fi
May it be helpful for someone.
Greetings
Jonathan
^ permalink raw reply
* [PATCH 2/2] drivers:bluetooth: Kconfig & Makefile for TI BT
From: pavan-savoy @ 2010-10-06 22:34 UTC (permalink / raw)
To: linux-bluetooth, marcel, johan.hedberg; +Cc: greg, linux-kernel, Pavan Savoy
In-Reply-To: <1286404493-23816-2-git-send-email-pavan-savoy@ti.com>
From: Pavan Savoy <pavan_savoy@ti.com>
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 | 11 +++++++++++
drivers/bluetooth/Makefile | 1 +
drivers/staging/ti-st/Kconfig | 14 --------------
drivers/staging/ti-st/Makefile | 5 -----
4 files changed, 12 insertions(+), 19 deletions(-)
delete mode 100644 drivers/staging/ti-st/Kconfig
delete mode 100644 drivers/staging/ti-st/Makefile
diff --git a/drivers/bluetooth/Kconfig b/drivers/bluetooth/Kconfig
index 02deef4..91a18b3 100644
--- a/drivers/bluetooth/Kconfig
+++ b/drivers/bluetooth/Kconfig
@@ -219,4 +219,15 @@ 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_TI
+ tristate "BlueZ bluetooth driver for TI ST"
+ depends on BT && RFKILL
+ select TI_ST
+ help
+ This enables the Bluetooth driver for Texas Instrument's BT/FM/GPS
+ combo devices. This makes use of shared transport line discipline
+ 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..63156da 100644
--- a/drivers/bluetooth/Makefile
+++ b/drivers/bluetooth/Makefile
@@ -28,3 +28,4 @@ hci_uart-$(CONFIG_BT_HCIUART_BCSP) += hci_bcsp.o
hci_uart-$(CONFIG_BT_HCIUART_LL) += hci_ll.o
hci_uart-$(CONFIG_BT_HCIUART_ATH3K) += hci_ath.o
hci_uart-objs := $(hci_uart-y)
+obj-$(CONFIG_BT_TI) := bt_ti.o
diff --git a/drivers/staging/ti-st/Kconfig b/drivers/staging/ti-st/Kconfig
deleted file mode 100644
index 074b8e8..0000000
--- a/drivers/staging/ti-st/Kconfig
+++ /dev/null
@@ -1,14 +0,0 @@
-#
-# TI's shared transport line discipline and the protocol
-# drivers (BT, FM and GPS)
-#
-menu "Texas Instruments shared transport line discipline"
-config ST_BT
- tristate "BlueZ bluetooth driver for ST"
- depends on BT && RFKILL
- select TI_ST
- help
- This enables the Bluetooth driver for TI BT/FM/GPS combo devices.
- This makes use of shared transport line discipline core driver to
- communicate with the BT core of the combo chip.
-endmenu
diff --git a/drivers/staging/ti-st/Makefile b/drivers/staging/ti-st/Makefile
deleted file mode 100644
index 5f11b82..0000000
--- a/drivers/staging/ti-st/Makefile
+++ /dev/null
@@ -1,5 +0,0 @@
-#
-# Makefile for TI's shared transport line discipline
-# and its protocol drivers (BT, FM, GPS)
-#
-obj-$(CONFIG_ST_BT) += bt_drv.o
--
1.6.5
^ permalink raw reply related
* [PATCH 1/2] drivers:bluetooth: TI_ST bluetooth driver
From: pavan-savoy @ 2010-10-06 22:34 UTC (permalink / raw)
To: linux-bluetooth, marcel, johan.hedberg; +Cc: greg, linux-kernel, Pavan Savoy
In-Reply-To: <1286404493-23816-1-git-send-email-pavan-savoy@ti.com>
From: Pavan Savoy <pavan_savoy@ti.com>
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.
Signed-off-by: Pavan Savoy <pavan_savoy@ti.com>
---
drivers/bluetooth/bt_ti.c | 463 ++++++++++++++++++++++++++++++++++++
drivers/staging/ti-st/bt_drv.c | 509 ----------------------------------------
drivers/staging/ti-st/bt_drv.h | 61 -----
3 files changed, 463 insertions(+), 570 deletions(-)
create mode 100644 drivers/bluetooth/bt_ti.c
delete mode 100644 drivers/staging/ti-st/bt_drv.c
delete mode 100644 drivers/staging/ti-st/bt_drv.h
diff --git a/drivers/bluetooth/bt_ti.c b/drivers/bluetooth/bt_ti.c
new file mode 100644
index 0000000..4f3d3aa
--- /dev/null
+++ b/drivers/bluetooth/bt_ti.c
@@ -0,0 +1,463 @@
+/*
+ * 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 modify
+ * 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-1307 USA
+ *
+ */
+
+#define pr_fmt(fmt) "(tibt): " fmt
+#include <net/bluetooth/bluetooth.h>
+#include <net/bluetooth/hci_core.h>
+
+#include <linux/ti_wilink_st.h>
+
+/* Bluetooth Driver Version */
+#define VERSION "1.0"
+
+/* Defines number of seconds to wait for reg completion
+ * callback getting called from ST (in case,registration
+ * with ST returns PENDING status)
+ */
+#define BT_REGISTER_TIMEOUT 6000 /* 6 sec */
+
+/* BT driver's local status */
+#define BT_DRV_RUNNING 0
+#define BT_ST_REGISTERED 1
+
+/**
+ * struct hci_st - BT driver operation structure
+ * @hdev: hci device pointer which binds to bt driver
+ * @flags: used locally,to maintain various BT driver status
+ * @streg_cbdata: to hold ST registration callback status
+ * @st_write: write function pointer of ST driver
+ * @wait_for_btdrv_reg_completion - completion sync between hci_st_open
+ * and hci_st_registration_completion_cb.
+ */
+struct hci_st {
+ struct hci_dev *hdev;
+ unsigned long flags;
+ char streg_cbdata;
+ long (*st_write) (struct sk_buff *);
+ struct completion wait_for_btdrv_reg_completion;
+};
+
+static struct hci_st *hst;
+static int reset;
+
+/* Increments HCI counters based on pocket ID (cmd,acl,sco) */
+static inline void hci_st_tx_complete(struct hci_st *hst, int pkt_type)
+{
+ struct hci_dev *hdev;
+ hdev = 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.cmd_tx++;
+ break;
+ }
+}
+
+/* ------- Interfaces to Shared Transport ------ */
+
+/* Called by ST layer to indicate protocol registration completion
+ * status.hci_st_open() function will wait for signal from this
+ * API when st_register() function returns ST_PENDING.
+ */
+static void hci_st_registration_completion_cb(void *priv_data, char data)
+{
+ struct hci_st *lhst = (struct hci_st *)priv_data;
+ /* hci_st_open() function needs value of 'data' to know
+ * the registration status(success/fail),So have a back
+ * up of it.
+ */
+ lhst->streg_cbdata = data;
+
+ /* Got a feedback from ST for BT driver registration
+ * request.Wackup hci_st_open() function to continue
+ * it's open operation.
+ */
+ complete(&lhst->wait_for_btdrv_reg_completion);
+}
+
+/* Called by Shared Transport layer when receive data is
+ * available */
+static long hci_st_receive(void *priv_data, struct sk_buff *skb)
+{
+ int err;
+ int len;
+ struct hci_st *lhst = (struct hci_st *)priv_data;
+
+ err = 0;
+ len = 0;
+
+ if (skb == NULL) {
+ pr_err("Invalid SKB received from ST");
+ return -EFAULT;
+ }
+ if (!lhst) {
+ kfree_skb(skb);
+ pr_err("Invalid hci_st memory,freeing SKB");
+ return -EFAULT;
+ }
+ if (!test_bit(BT_DRV_RUNNING, &lhst->flags)) {
+ kfree_skb(skb);
+ pr_err("Device is not running,freeing SKB");
+ return -EINVAL;
+ }
+
+ len = skb->len;
+ skb->dev = (struct net_device *)lhst->hdev;
+
+ /* Forward skb to HCI CORE layer */
+ err = hci_recv_frame(skb);
+ if (err) {
+ kfree_skb(skb);
+ pr_err("Unable to push skb to HCI CORE(%d),freeing SKB",
+ err);
+ return err;
+ }
+ lhst->hdev->stat.byte_rx += len;
+
+ return 0;
+}
+
+/* ------- Interfaces to HCI layer ------ */
+
+/* Called from HCI core to initialize the device */
+static int hci_st_open(struct hci_dev *hdev)
+{
+ static struct st_proto_s hci_st_proto;
+ unsigned long timeleft;
+ int err;
+ err = 0;
+
+ pr_debug("%s %p", hdev->name, hdev);
+
+ /* Already registered with ST ? */
+ if (test_bit(BT_ST_REGISTERED, &hst->flags)) {
+ pr_err("Registered with ST already,open called again?");
+ return 0;
+ }
+
+ /* Populate BT driver info required by ST */
+ memset(&hci_st_proto, 0, sizeof(hci_st_proto));
+
+ /* BT driver ID */
+ hci_st_proto.type = ST_BT;
+
+ /* Receive function which called from ST */
+ hci_st_proto.recv = hci_st_receive;
+
+ /* Packet match function may used in future */
+ hci_st_proto.match_packet = NULL;
+
+ /* Callback to be called when registration is pending */
+ hci_st_proto.reg_complete_cb = hci_st_registration_completion_cb;
+
+ /* This is write function pointer of ST. BT driver will make use of this
+ * for sending any packets to chip. ST will assign and give to us, so
+ * make it as NULL */
+ hci_st_proto.write = NULL;
+
+ /* send in the hst to be received at registration complete callback
+ * and during st's receive
+ */
+ hci_st_proto.priv_data = hst;
+
+ /* Register with ST layer */
+ err = st_register(&hci_st_proto);
+ if (err == -EINPROGRESS) {
+ /* Prepare wait-for-completion handler data structures.
+ * Needed to syncronize this and st_registration_completion_cb()
+ * functions.
+ */
+ init_completion(&hst->wait_for_btdrv_reg_completion);
+
+ /* Reset ST registration callback status flag , this value
+ * will be updated in hci_st_registration_completion_cb()
+ * function whenever it called from ST driver.
+ */
+ hst->streg_cbdata = -EINPROGRESS;
+
+ /* ST is busy with other protocol registration(may be busy with
+ * firmware download).So,Wait till the registration callback
+ * (passed as a argument to st_register() function) getting
+ * called from ST.
+ */
+ pr_debug(" %s waiting for reg completion signal from ST",
+ __func__);
+
+ timeleft =
+ wait_for_completion_timeout
+ (&hst->wait_for_btdrv_reg_completion,
+ msecs_to_jiffies(BT_REGISTER_TIMEOUT));
+ if (!timeleft) {
+ pr_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 value? */
+ if (hst->streg_cbdata != 0) {
+ pr_err("ST reg completion CB called with invalid"
+ "status %d", hst->streg_cbdata);
+ return -EAGAIN;
+ }
+ err = 0;
+ } else if (err == -1) {
+ pr_err("st_register failed %d", err);
+ return -EAGAIN;
+ }
+
+ /* Do we have proper ST write function? */
+ if (hci_st_proto.write != NULL) {
+ /* We need this pointer for sending any Bluetooth pkts */
+ hst->st_write = hci_st_proto.write;
+ } else {
+ pr_err("failed to get ST write func pointer");
+
+ /* Undo registration with ST */
+ err = st_unregister(ST_BT);
+ if (err < 0)
+ pr_err("st_unregister failed %d", err);
+
+ hst->st_write = NULL;
+ return -EAGAIN;
+ }
+
+ /* Registration with ST layer is completed successfully,
+ * now chip is ready to accept commands from HCI CORE.
+ * Mark HCI Device flag as RUNNING
+ */
+ set_bit(HCI_RUNNING, &hdev->flags);
+
+ /* Registration with ST successful */
+ set_bit(BT_ST_REGISTERED, &hst->flags);
+
+ return err;
+}
+
+/* Close device */
+static int hci_st_close(struct hci_dev *hdev)
+{
+ int err;
+ err = 0;
+
+ /* Unregister from ST layer */
+ if (test_and_clear_bit(BT_ST_REGISTERED, &hst->flags)) {
+ err = st_unregister(ST_BT);
+ if (err != 0) {
+ pr_err("st_unregister failed %d", err);
+ return -EBUSY;
+ }
+ }
+
+ hst->st_write = NULL;
+
+ /* ST layer would have moved chip to inactive state.
+ * So,clear HCI device RUNNING flag.
+ */
+ if (!test_and_clear_bit(HCI_RUNNING, &hdev->flags))
+ return 0;
+
+ return err;
+}
+
+/* Called from HCI CORE , Sends frames to Shared Transport */
+static int hci_st_send_frame(struct sk_buff *skb)
+{
+ struct hci_dev *hdev;
+ struct hci_st *hst;
+ long len;
+
+ if (skb == NULL) {
+ pr_err("Invalid skb received from HCI CORE");
+ return -ENOMEM;
+ }
+ hdev = (struct hci_dev *)skb->dev;
+ if (!hdev) {
+ pr_err("SKB received for invalid HCI Device (hdev=NULL)");
+ return -ENODEV;
+ }
+ if (!test_bit(HCI_RUNNING, &hdev->flags)) {
+ pr_err("Device is not running");
+ return -EBUSY;
+ }
+
+ hst = (struct hci_st *)hdev->driver_data;
+
+ /* Prepend skb with frame type */
+ memcpy(skb_push(skb, 1), &bt_cb(skb)->pkt_type, 1);
+
+ pr_debug(" %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);
+ pr_err(" Can't write to ST, st_write null?");
+ return -EAGAIN;
+ }
+ len = hst->st_write(skb);
+ if (len < 0) {
+ /* Something went wrong in st write , free skb memory */
+ kfree_skb(skb);
+ pr_err(" ST write failed (%ld)", len);
+ return -EAGAIN;
+ }
+
+ /* ST accepted our skb. So, Go ahead and do rest */
+ hdev->stat.byte_tx += len;
+ hci_st_tx_complete(hst, bt_cb(skb)->pkt_type);
+
+ return 0;
+}
+
+static void hci_st_destruct(struct hci_dev *hdev)
+{
+ if (!hdev) {
+ pr_err("Destruct called with invalid HCI Device"
+ "(hdev=NULL)");
+ return;
+ }
+
+ pr_debug("%s", hdev->name);
+
+ /* free hci_st memory */
+ if (hdev->driver_data != NULL)
+ kfree(hdev->driver_data);
+
+ return;
+}
+
+/* Creates new HCI device */
+static int hci_st_register_dev(struct hci_st *hst)
+{
+ struct hci_dev *hdev;
+
+ /* Initialize and register HCI device */
+ hdev = hci_alloc_dev();
+ if (!hdev) {
+ pr_err("Can't allocate HCI device");
+ return -ENOMEM;
+ }
+ pr_debug(" HCI device allocated. hdev= %p", hdev);
+
+ hst->hdev = hdev;
+ hdev->bus = HCI_UART;
+ hdev->driver_data = hst;
+ hdev->open = hci_st_open;
+ hdev->close = hci_st_close;
+ hdev->flush = NULL;
+ hdev->send = hci_st_send_frame;
+ hdev->destruct = hci_st_destruct;
+ hdev->owner = THIS_MODULE;
+
+ if (reset)
+ set_bit(HCI_QUIRK_NO_RESET, &hdev->quirks);
+
+ if (hci_register_dev(hdev) < 0) {
+ pr_err("Can't register HCI device");
+ hci_free_dev(hdev);
+ return -ENODEV;
+ }
+
+ pr_debug(" HCI device registered. hdev= %p", hdev);
+ return 0;
+}
+
+/* ------- Module Init interface ------ */
+
+static int __init bt_drv_init(void)
+{
+ int err;
+ err = 0;
+
+ pr_debug(" Bluetooth Driver Version %s", VERSION);
+
+ /* Allocate local resource memory */
+ hst = kzalloc(sizeof(struct hci_st), GFP_KERNEL);
+ if (!hst) {
+ pr_err("Can't allocate control structure");
+ return -ENFILE;
+ }
+
+ /* Expose "hciX" device to user space */
+ err = hci_st_register_dev(hst);
+ if (err) {
+ /* Release local resource memory */
+ kfree(hst);
+
+ pr_err("Unable to expose hci0 device(%d)", err);
+ return err;
+ }
+ set_bit(BT_DRV_RUNNING, &hst->flags);
+ return err;
+}
+
+/* ------- Module Exit interface ------ */
+
+static void __exit bt_drv_exit(void)
+{
+ /* Deallocate local resource's memory */
+ if (hst) {
+ struct hci_dev *hdev = hst->hdev;
+ if (hdev == NULL) {
+ pr_err("Invalid hdev memory");
+ kfree(hst);
+ } else {
+ hci_st_close(hdev);
+ if (test_and_clear_bit(BT_DRV_RUNNING, &hst->flags)) {
+ /* Remove HCI device (hciX) created
+ * in module init.
+ */
+ hci_unregister_dev(hdev);
+ /* Free HCI device memory */
+ hci_free_dev(hdev);
+ }
+ }
+ }
+}
+
+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");
diff --git a/drivers/staging/ti-st/bt_drv.c b/drivers/staging/ti-st/bt_drv.c
deleted file mode 100644
index 75065bf..0000000
--- a/drivers/staging/ti-st/bt_drv.c
+++ /dev/null
@@ -1,509 +0,0 @@
-/*
- * Texas Instrument's Bluetooth Driver For Shared Transport.
- *
- * Bluetooth Driver acts as interface between HCI CORE and
- * TI Shared Transport Layer.
- *
- * Copyright (C) 2009 Texas Instruments
- *
- * This program is free software; you can redistribute it and/or modify
- * 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-1307 USA
- *
- */
-
-#include <net/bluetooth/bluetooth.h>
-#include <net/bluetooth/hci_core.h>
-
-#include <linux/ti_wilink_st.h>
-#include "bt_drv.h"
-
-/* Define this macro to get debug msg */
-#undef DEBUG
-
-#ifdef DEBUG
-#define BT_DRV_DBG(fmt, arg...) printk(KERN_INFO "(btdrv):"fmt"\n" , ## arg)
-#define BTDRV_API_START() printk(KERN_INFO "(btdrv): %s Start\n", \
- __func__)
-#define BTDRV_API_EXIT(errno) printk(KERN_INFO "(btdrv): %s Exit(%d)\n", \
- __func__, errno)
-#else
-#define BT_DRV_DBG(fmt, arg...)
-#define BTDRV_API_START()
-#define BTDRV_API_EXIT(errno)
-#endif
-
-#define BT_DRV_ERR(fmt, arg...) printk(KERN_ERR "(btdrv):"fmt"\n" , ## arg)
-
-static int reset;
-static struct hci_st *hst;
-
-/* Increments HCI counters based on pocket ID (cmd,acl,sco) */
-static inline void hci_st_tx_complete(struct hci_st *hst, int pkt_type)
-{
- struct hci_dev *hdev;
-
- BTDRV_API_START();
-
- hdev = 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.cmd_tx++;
- break;
- }
-
- BTDRV_API_EXIT(0);
-}
-
-/* ------- Interfaces to Shared Transport ------ */
-
-/* Called by ST layer to indicate protocol registration completion
- * status.hci_st_open() function will wait for signal from this
- * API when st_register() function returns ST_PENDING.
- */
-static void hci_st_registration_completion_cb(void *priv_data, char data)
-{
- struct hci_st *lhst = (struct hci_st *)priv_data;
- BTDRV_API_START();
-
- /* hci_st_open() function needs value of 'data' to know
- * the registration status(success/fail),So have a back
- * up of it.
- */
- lhst->streg_cbdata = data;
-
- /* Got a feedback from ST for BT driver registration
- * request.Wackup hci_st_open() function to continue
- * it's open operation.
- */
- complete(&lhst->wait_for_btdrv_reg_completion);
-
- BTDRV_API_EXIT(0);
-}
-
-/* Called by Shared Transport layer when receive data is
- * available */
-static long hci_st_receive(void *priv_data, struct sk_buff *skb)
-{
- int err;
- int len;
- struct hci_st *lhst = (struct hci_st *)priv_data;
-
- BTDRV_API_START();
-
- err = 0;
- len = 0;
-
- if (skb == NULL) {
- BT_DRV_ERR("Invalid SKB received from ST");
- BTDRV_API_EXIT(-EFAULT);
- return -EFAULT;
- }
- if (!lhst) {
- kfree_skb(skb);
- BT_DRV_ERR("Invalid hci_st memory,freeing SKB");
- BTDRV_API_EXIT(-EFAULT);
- return -EFAULT;
- }
- if (!test_bit(BT_DRV_RUNNING, &lhst->flags)) {
- kfree_skb(skb);
- BT_DRV_ERR("Device is not running,freeing SKB");
- BTDRV_API_EXIT(-EINVAL);
- return -EINVAL;
- }
-
- len = skb->len;
- skb->dev = (struct net_device *)lhst->hdev;
-
- /* Forward skb to HCI CORE layer */
- err = hci_recv_frame(skb);
- if (err) {
- kfree_skb(skb);
- BT_DRV_ERR("Unable to push skb to HCI CORE(%d),freeing SKB",
- err);
- BTDRV_API_EXIT(err);
- return err;
- }
- lhst->hdev->stat.byte_rx += len;
-
- BTDRV_API_EXIT(0);
- return 0;
-}
-
-/* ------- Interfaces to HCI layer ------ */
-
-/* Called from HCI core to initialize the device */
-static int hci_st_open(struct hci_dev *hdev)
-{
- static struct st_proto_s hci_st_proto;
- unsigned long timeleft;
- int err;
-
- BTDRV_API_START();
-
- err = 0;
-
- BT_DRV_DBG("%s %p", hdev->name, hdev);
-
- /* Already registered with ST ? */
- if (test_bit(BT_ST_REGISTERED, &hst->flags)) {
- BT_DRV_ERR("Registered with ST already,open called again?");
- BTDRV_API_EXIT(0);
- return 0;
- }
-
- /* Populate BT driver info required by ST */
- memset(&hci_st_proto, 0, sizeof(hci_st_proto));
-
- /* BT driver ID */
- hci_st_proto.type = ST_BT;
-
- /* Receive function which called from ST */
- hci_st_proto.recv = hci_st_receive;
-
- /* Packet match function may used in future */
- hci_st_proto.match_packet = NULL;
-
- /* Callback to be called when registration is pending */
- hci_st_proto.reg_complete_cb = hci_st_registration_completion_cb;
-
- /* This is write function pointer of ST. BT driver will make use of this
- * for sending any packets to chip. ST will assign and give to us, so
- * make it as NULL */
- hci_st_proto.write = NULL;
-
- /* send in the hst to be received at registration complete callback
- * and during st's receive
- */
- hci_st_proto.priv_data = hst;
-
- /* Register with ST layer */
- err = st_register(&hci_st_proto);
- if (err == -EINPROGRESS) {
- /* Prepare wait-for-completion handler data structures.
- * Needed to syncronize this and st_registration_completion_cb()
- * functions.
- */
- init_completion(&hst->wait_for_btdrv_reg_completion);
-
- /* Reset ST registration callback status flag , this value
- * will be updated in hci_st_registration_completion_cb()
- * function whenever it called from ST driver.
- */
- hst->streg_cbdata = -EINPROGRESS;
-
- /* ST is busy with other protocol registration(may be busy with
- * firmware download).So,Wait till the registration callback
- * (passed as a argument to st_register() function) getting
- * called from ST.
- */
- BT_DRV_DBG(" %s waiting for reg completion signal from ST",
- __func__);
-
- timeleft =
- wait_for_completion_timeout
- (&hst->wait_for_btdrv_reg_completion,
- msecs_to_jiffies(BT_REGISTER_TIMEOUT));
- if (!timeleft) {
- BT_DRV_ERR("Timeout(%ld sec),didn't get reg"
- "completion signal from ST",
- BT_REGISTER_TIMEOUT / 1000);
- BTDRV_API_EXIT(-ETIMEDOUT);
- return -ETIMEDOUT;
- }
-
- /* Is ST registration callback called with ERROR value? */
- if (hst->streg_cbdata != 0) {
- BT_DRV_ERR("ST reg completion CB called with invalid"
- "status %d", hst->streg_cbdata);
- BTDRV_API_EXIT(-EAGAIN);
- return -EAGAIN;
- }
- err = 0;
- } else if (err == -1) {
- BT_DRV_ERR("st_register failed %d", err);
- BTDRV_API_EXIT(-EAGAIN);
- return -EAGAIN;
- }
-
- /* Do we have proper ST write function? */
- if (hci_st_proto.write != NULL) {
- /* We need this pointer for sending any Bluetooth pkts */
- hst->st_write = hci_st_proto.write;
- } else {
- BT_DRV_ERR("failed to get ST write func pointer");
-
- /* Undo registration with ST */
- err = st_unregister(ST_BT);
- if (err < 0)
- BT_DRV_ERR("st_unregister failed %d", err);
-
- hst->st_write = NULL;
- BTDRV_API_EXIT(-EAGAIN);
- return -EAGAIN;
- }
-
- /* Registration with ST layer is completed successfully,
- * now chip is ready to accept commands from HCI CORE.
- * Mark HCI Device flag as RUNNING
- */
- set_bit(HCI_RUNNING, &hdev->flags);
-
- /* Registration with ST successful */
- set_bit(BT_ST_REGISTERED, &hst->flags);
-
- BTDRV_API_EXIT(err);
- return err;
-}
-
-/* Close device */
-static int hci_st_close(struct hci_dev *hdev)
-{
- int err;
-
- BTDRV_API_START();
-
- err = 0;
-
- /* Unregister from ST layer */
- if (test_and_clear_bit(BT_ST_REGISTERED, &hst->flags)) {
- err = st_unregister(ST_BT);
- if (err != 0) {
- BT_DRV_ERR("st_unregister failed %d", err);
- BTDRV_API_EXIT(-EBUSY);
- return -EBUSY;
- }
- }
-
- hst->st_write = NULL;
-
- /* ST layer would have moved chip to inactive state.
- * So,clear HCI device RUNNING flag.
- */
- if (!test_and_clear_bit(HCI_RUNNING, &hdev->flags)) {
- BTDRV_API_EXIT(0);
- return 0;
- }
-
- BTDRV_API_EXIT(err);
- return err;
-}
-
-/* Called from HCI CORE , Sends frames to Shared Transport */
-static int hci_st_send_frame(struct sk_buff *skb)
-{
- struct hci_dev *hdev;
- struct hci_st *hst;
- long len;
-
- BTDRV_API_START();
-
- if (skb == NULL) {
- BT_DRV_ERR("Invalid skb received from HCI CORE");
- BTDRV_API_EXIT(-ENOMEM);
- return -ENOMEM;
- }
- hdev = (struct hci_dev *)skb->dev;
- if (!hdev) {
- BT_DRV_ERR("SKB received for invalid HCI Device (hdev=NULL)");
- BTDRV_API_EXIT(-ENODEV);
- return -ENODEV;
- }
- if (!test_bit(HCI_RUNNING, &hdev->flags)) {
- BT_DRV_ERR("Device is not running");
- BTDRV_API_EXIT(-EBUSY);
- return -EBUSY;
- }
-
- hst = (struct hci_st *)hdev->driver_data;
-
- /* Prepend skb with frame type */
- memcpy(skb_push(skb, 1), &bt_cb(skb)->pkt_type, 1);
-
- BT_DRV_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_DRV_ERR(" Can't write to ST, st_write null?");
- BTDRV_API_EXIT(-EAGAIN);
- return -EAGAIN;
- }
- len = hst->st_write(skb);
- if (len < 0) {
- /* Something went wrong in st write , free skb memory */
- kfree_skb(skb);
- BT_DRV_ERR(" ST write failed (%ld)", len);
- BTDRV_API_EXIT(-EAGAIN);
- return -EAGAIN;
- }
-
- /* ST accepted our skb. So, Go ahead and do rest */
- hdev->stat.byte_tx += len;
- hci_st_tx_complete(hst, bt_cb(skb)->pkt_type);
-
- BTDRV_API_EXIT(0);
- return 0;
-}
-
-static void hci_st_destruct(struct hci_dev *hdev)
-{
- BTDRV_API_START();
-
- if (!hdev) {
- BT_DRV_ERR("Destruct called with invalid HCI Device"
- "(hdev=NULL)");
- BTDRV_API_EXIT(0);
- return;
- }
-
- BT_DRV_DBG("%s", hdev->name);
-
- /* free hci_st memory */
- if (hdev->driver_data != NULL)
- kfree(hdev->driver_data);
-
- BTDRV_API_EXIT(0);
- return;
-}
-
-/* Creates new HCI device */
-static int hci_st_register_dev(struct hci_st *hst)
-{
- struct hci_dev *hdev;
-
- BTDRV_API_START();
-
- /* Initialize and register HCI device */
- hdev = hci_alloc_dev();
- if (!hdev) {
- BT_DRV_ERR("Can't allocate HCI device");
- BTDRV_API_EXIT(-ENOMEM);
- return -ENOMEM;
- }
- BT_DRV_DBG(" HCI device allocated. hdev= %p", hdev);
-
- hst->hdev = hdev;
- hdev->bus = HCI_UART;
- hdev->driver_data = hst;
- hdev->open = hci_st_open;
- hdev->close = hci_st_close;
- hdev->flush = NULL;
- hdev->send = hci_st_send_frame;
- hdev->destruct = hci_st_destruct;
- hdev->owner = THIS_MODULE;
-
- if (reset)
- set_bit(HCI_QUIRK_NO_RESET, &hdev->quirks);
-
- if (hci_register_dev(hdev) < 0) {
- BT_DRV_ERR("Can't register HCI device");
- hci_free_dev(hdev);
- BTDRV_API_EXIT(-ENODEV);
- return -ENODEV;
- }
-
- BT_DRV_DBG(" HCI device registered. hdev= %p", hdev);
- BTDRV_API_EXIT(0);
- return 0;
-}
-
-/* ------- Module Init interface ------ */
-
-static int __init bt_drv_init(void)
-{
- int err;
-
- BTDRV_API_START();
-
- err = 0;
-
- BT_DRV_DBG(" Bluetooth Driver Version %s", VERSION);
-
- /* Allocate local resource memory */
- hst = kzalloc(sizeof(struct hci_st), GFP_KERNEL);
- if (!hst) {
- BT_DRV_ERR("Can't allocate control structure");
- BTDRV_API_EXIT(-ENFILE);
- return -ENFILE;
- }
-
- /* Expose "hciX" device to user space */
- err = hci_st_register_dev(hst);
- if (err) {
- /* Release local resource memory */
- kfree(hst);
-
- BT_DRV_ERR("Unable to expose hci0 device(%d)", err);
- BTDRV_API_EXIT(err);
- return err;
- }
- set_bit(BT_DRV_RUNNING, &hst->flags);
-
- BTDRV_API_EXIT(err);
- return err;
-}
-
-/* ------- Module Exit interface ------ */
-
-static void __exit bt_drv_exit(void)
-{
- BTDRV_API_START();
-
- /* Deallocate local resource's memory */
- if (hst) {
- struct hci_dev *hdev = hst->hdev;
-
- if (hdev == NULL) {
- BT_DRV_ERR("Invalid hdev memory");
- kfree(hst);
- } else {
- hci_st_close(hdev);
- if (test_and_clear_bit(BT_DRV_RUNNING, &hst->flags)) {
- /* Remove HCI device (hciX) created
- * in module init.
- */
- hci_unregister_dev(hdev);
-
- /* Free HCI device memory */
- hci_free_dev(hdev);
- }
- }
- }
- BTDRV_API_EXIT(0);
-}
-
-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");
diff --git a/drivers/staging/ti-st/bt_drv.h b/drivers/staging/ti-st/bt_drv.h
deleted file mode 100644
index a0beebe..0000000
--- a/drivers/staging/ti-st/bt_drv.h
+++ /dev/null
@@ -1,61 +0,0 @@
-/*
- * Texas Instrument's Bluetooth Driver For Shared Transport.
- *
- * Bluetooth Driver acts as interface between HCI CORE and
- * TI Shared Transport Layer.
- *
- * Copyright (C) 2009 Texas Instruments
- *
- * This program is free software; you can redistribute it and/or modify
- * 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-1307 USA
- *
- */
-
-#ifndef _BT_DRV_H
-#define _BT_DRV_H
-
-/* Bluetooth Driver Version */
-#define VERSION "1.0"
-
-/* Defines number of seconds to wait for reg completion
- * callback getting called from ST (in case,registration
- * with ST returns PENDING status)
- */
-#define BT_REGISTER_TIMEOUT msecs_to_jiffies(6000) /* 6 sec */
-
-/* BT driver's local status */
-#define BT_DRV_RUNNING 0
-#define BT_ST_REGISTERED 1
-
-/* BT driver operation structure */
-struct hci_st {
-
- /* hci device pointer which binds to bt driver */
- struct hci_dev *hdev;
-
- /* used locally,to maintain various BT driver status */
- unsigned long flags;
-
- /* to hold ST registration callback status */
- char streg_cbdata;
-
- /* write function pointer of ST driver */
- long (*st_write) (struct sk_buff *);
-
- /* Wait on comepletion handler needed to synchronize
- * hci_st_open() and hci_st_registration_completion_cb()
- * functions.*/
- struct completion wait_for_btdrv_reg_completion;
-};
-
-#endif
--
1.6.5
^ permalink raw reply related
* [PATCH 0/2] Bluetooth driver for TI WiLink 7
From: pavan-savoy @ 2010-10-06 22:34 UTC (permalink / raw)
To: linux-bluetooth, marcel, johan.hedberg; +Cc: greg, linux-kernel, Pavan Savoy
From: Pavan Savoy <pavan_savoy@ti.com>
Marcel/Johan and the linux-bluetooth list,
I have begun cleaning up the code for the Bluetooth drivers for
Texas Instrument's WiLink 7 chips.
This driver works on top the Texas Instrument's shared transport line
discipline driver.
So, apart from the transport part of it, the driver is like other regular
bluetooth drivers.
These patches is to move it out of staging/ into the drivers/bluetooth/
Please review and provide comments.
Pavan Savoy (2):
drivers:bluetooth: TI_ST bluetooth driver
drivers:bluetooth: Kconfig & Makefile for TI BT
drivers/bluetooth/Kconfig | 11 +
drivers/bluetooth/Makefile | 1 +
drivers/bluetooth/bt_ti.c | 464 ++++++++++++++++++++++++++++++++++++
drivers/staging/ti-st/Kconfig | 14 -
drivers/staging/ti-st/Makefile | 5 -
drivers/staging/ti-st/bt_drv.c | 509 ----------------------------------------
drivers/staging/ti-st/bt_drv.h | 61 -----
7 files changed, 476 insertions(+), 589 deletions(-)
create mode 100644 drivers/bluetooth/bt_ti.c
delete mode 100644 drivers/staging/ti-st/Kconfig
delete mode 100644 drivers/staging/ti-st/Makefile
delete mode 100644 drivers/staging/ti-st/bt_drv.c
delete mode 100644 drivers/staging/ti-st/bt_drv.h
^ permalink raw reply
* Re: [PATCH] TODO: Attribute server should process queued commands at disconnection
From: Johan Hedberg @ 2010-10-06 21:44 UTC (permalink / raw)
To: Claudio Takahasi; +Cc: linux-bluetooth
In-Reply-To: <1286398805-12542-1-git-send-email-claudio.takahasi@openbossa.org>
Hi Claudio,
On Wed, Oct 06, 2010, Claudio Takahasi wrote:
> ---
> TODO | 9 +++++++++
> 1 files changed, 9 insertions(+), 0 deletions(-)
This one has also been pushed upstream.
Johan
^ permalink raw reply
* Re: [PATCH] TODO: Export Client Characteristic Configuration as a property
From: Johan Hedberg @ 2010-10-06 21:43 UTC (permalink / raw)
To: Claudio Takahasi; +Cc: linux-bluetooth
In-Reply-To: <1286397803-12433-1-git-send-email-claudio.takahasi@openbossa.org>
Hi Claudio,
On Wed, Oct 06, 2010, Claudio Takahasi wrote:
> ---
> TODO | 10 ++++++++++
> 1 files changed, 10 insertions(+), 0 deletions(-)
Pushed upstream. Thanks.
Johan
^ permalink raw reply
* Re: [PATCH 2/2] Client Characteristic Configuration on attribute server
From: Johan Hedberg @ 2010-10-06 21:43 UTC (permalink / raw)
To: Claudio Takahasi; +Cc: linux-bluetooth
In-Reply-To: <1286397594-12366-2-git-send-email-claudio.takahasi@openbossa.org>
Hi Claudio,
On Wed, Oct 06, 2010, Claudio Takahasi wrote:
> Initial implementation of per client attribute configuration for the
> attribute server. Notification and indication shall be sent to the peer
> only if Client Characteristic Configuration bit field is set.
> ---
> TODO | 7 --
> src/attrib-server.c | 194 +++++++++++++++++++++++++++++++++++---------------
> src/storage.c | 44 ++++++++++++
> src/storage.h | 4 +
> 4 files changed, 184 insertions(+), 65 deletions(-)
I feel a bit conflicted about this one. Do we really want to have a
generic storage for all characteristics? I'd think that it'd make sense
to let each service implementation take care of how to store their state
persistently (if it needs to be done at all).
Would it be possible for you to create a patch that fixes the
notification sending to clients that haven't subscribed for them but
leaves out the storage stuff?
Johan
^ permalink raw reply
* Re: [PATCH 1/2] Change Battery Service on attribute sample server
From: Johan Hedberg @ 2010-10-06 21:40 UTC (permalink / raw)
To: Claudio Takahasi; +Cc: linux-bluetooth
In-Reply-To: <1286397594-12366-1-git-send-email-claudio.takahasi@openbossa.org>
Hi Claudio,
On Wed, Oct 06, 2010, Claudio Takahasi wrote:
> Add an optional Client Characteristic Configuration attribute for
> Battery State to control which clients want notification/indication
> when this attribute value changes.
> ---
> attrib/example.c | 7 ++++++-
> 1 files changed, 6 insertions(+), 1 deletions(-)
Pushed upstream. Thanks.
Johan
^ permalink raw reply
* Re: [PATCH] TODO: Add attribute permission verification for attribute server
From: Johan Hedberg @ 2010-10-06 21:38 UTC (permalink / raw)
To: Claudio Takahasi; +Cc: linux-bluetooth
In-Reply-To: <1286397282-11921-1-git-send-email-claudio.takahasi@openbossa.org>
Hi Claudio,
On Wed, Oct 06, 2010, Claudio Takahasi wrote:
> ---
> TODO | 7 +++++++
> 1 files changed, 7 insertions(+), 0 deletions(-)
Pushed upstream. Thanks.
Johan
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox