Gustavo,
On Wed, Nov 17, 2010 at 4:24 AM, Gustavo F. Padovan
<padovan@xxxxxxxxxxxxxx> wrote:
> Hi Pavan,
>
> * pavan_savoy@xxxxxx <pavan_savoy@xxxxxx> [2010-11-10 08:07:26 -0500]:
>
>> From: Pavan Savoy <pavan_savoy@xxxxxx>
>>
>> Marcel,
>>
>> Thanks for the comments...
>> This patch contains,
>> v5 comments :-
>> declaration and assiging of variables and private data fixed up.
>> proper casting.
>> removed redundant un-necessary checks in send_frame.
>> HCI_RUNNING fixes in terms of test_and_set/clear bit instead of set and
>> clear.
>> removed redundant checks for hdev, skb being NULL.
>> removed module_param of reset, also WiLink don't need HCI_RESET anyways.
>> removed ti_st_register_dev function and functionality moved to _probe.
>> module_init/exit function names fixed up.
>>
>> stat byte counter increments and tx_complete is similar to hci_ldisc.
>> Also I have not implemented the flush routine, since the functionality
>> which needs to be done in flush routine is done in the underlying driver
>> which is the shared transport driver and moreover the btwilink driver by
>> itself doesn't maintains queue or data relevant to transport, so nothing
>> to do.
>>
>> And Yes, I have verified this driver with multiple up/down reset on
>> hci0.
>> Also I generally test a2dp/ftp to verify large data transfers.
>
> Before re-submit a patch you have to fix all issues reported by the
> reviewer or reply to patch thread why do you think you right and don't
> want to change that. That is not happening with your patches, you are
> not fixing all the stuff before re-submiting and it is not the first
> time. ÂIf you do it right we can review it fast and your code goes
> earlier to mainline.
> You should also answer the questions first Âlike "Where is the
> ti_st_proto.write coming from?" You just ignored the
> review and submitted a new patch.
This is the reason, I tend to keep the patch comments in the mail.
I have mentioned here the
1. comments I have taken care of,
2. few comments which I don't understand why it is like that and which
are not taken care of.
Also the question on ti_st_proto.write, I have answered it twice in
mail, once to you and once to marcel, for more clarity I have even
added it in the code comments, Please have a look @ line
>> + /* ti_st_proto.write is filled up by the underlying shared
>> + * transport driver upon registration
>> + */
As to why this function is not EXPORT_SYMBOL and just an function
pointer, Yes I had it as function pointer - But since something like
_read is callback from the protocol driver perspective - to maintain
uniformity I have this as function pointer.
(Note: comments to other drivers which are based on ST driver intended
read/write to be pointers which register/unregister to be EXPORTs).
Ok, apart from this there was an open question as why I am checking
for only 2 error conditions, it is because the underlying driver only
can send those 2 errors and nothing else (st_register has few errors
it can throw...)
I understand my problem with test_and_set_bit, I will correct it, But
I still feel I do nothing critical before test/set so as to return
error if already opened - But will correct it and do it at the
beginning ...
Also what should I be doing regarding the deferred stats update? I
checked up hci_ldisc which is what this code is pretty much based on,
and see that it does pretty much the same thing ....
hci_uart_tx_complete is called after the tty->ops->write correct ?
I also now understand the issue in module_init regarding the
platform_driver registration and will fix that.
Thanks,
Pavan
>>
>> v4 comments :-
>> module init now returns what platform_driver_register returns.
>> type casting of void* private data has been removed
>>
>> v3 comments :-
>> Lizardo,
>> I have taken care of most of the comments you had.
>> Have re-wrote some of the code commenting you've mentioned.
>> Thanks for the comments,
>>
>> The other few like -EPERM for platform driver registration is to keep
>> it similar to other drivers, type casting is maintained just to feel safe
>> and have style similar to other drivers.
>> BT_WILINK in Kconfig is similar to BT_MRVL.
>> I hope those aren't too critical.
>>
>> -- patch description --
>>
>> This is the bluetooth protocol driver for the TI WiLink7 chipsets.
>> Texas Instrument's WiLink chipsets combine wireless technologies
>> like BT, FM, GPS and WLAN onto a single chip.
>>
>> This Bluetooth driver works on top of the TI_ST shared transport
>> line discipline driver which also allows other drivers like
>> FM V4L2 and GPS character driver to make use of the same UART interface.
>>
>> Kconfig and Makefile modifications to enable the Bluetooth
>> driver for Texas Instrument's WiLink 7 chipset.
>>
>> Signed-off-by: Pavan Savoy <pavan_savoy@xxxxxx>
>> ---
>> Âdrivers/bluetooth/Kconfig  Â|  10 +
>> Âdrivers/bluetooth/Makefile  |  Â1 +
>> Âdrivers/bluetooth/btwilink.c | Â379 ++++++++++++++++++++++++++++++++++++++++++
>> Â3 files changed, 390 insertions(+), 0 deletions(-)
>> Âcreate mode 100644 drivers/bluetooth/btwilink.c
>>
>> diff --git a/drivers/bluetooth/Kconfig b/drivers/bluetooth/Kconfig
>> index 02deef4..8e0de9a 100644
>> --- a/drivers/bluetooth/Kconfig
>> +++ b/drivers/bluetooth/Kconfig
>> @@ -219,4 +219,14 @@ config BT_ATH3K
>> Â Â Â Â Say Y here to compile support for "Atheros firmware download driver"
>> Â Â Â Â into the kernel or say M to compile it as module (ath3k).
>>
>> +config BT_WILINK
>> + Â Â tristate "Texas Instruments WiLink7 driver"
>> + Â Â depends on TI_ST
>> + Â Â help
>> + Â Â Â This enables the Bluetooth driver for Texas Instrument's BT/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..f4460f4 100644
>> --- a/drivers/bluetooth/Makefile
>> +++ b/drivers/bluetooth/Makefile
>> @@ -18,6 +18,7 @@ obj-$(CONFIG_BT_HCIBTSDIO) Â+= btsdio.o
>> Âobj-$(CONFIG_BT_ATH3K) Â Â Â Â Â Â Â += ath3k.o
>> Âobj-$(CONFIG_BT_MRVL) Â Â Â Â Â Â Â Â+= btmrvl.o
>> Âobj-$(CONFIG_BT_MRVL_SDIO) Â += btmrvl_sdio.o
>> +obj-$(CONFIG_BT_WILINK) Â Â Â Â Â Â Â+= btwilink.o
>>
>> Âbtmrvl-y           := btmrvl_main.o
>> Âbtmrvl-$(CONFIG_DEBUG_FS) Â Â+= btmrvl_debugfs.o
>> diff --git a/drivers/bluetooth/btwilink.c b/drivers/bluetooth/btwilink.c
>> new file mode 100644
>> index 0000000..1b1c4bc
>> --- /dev/null
>> +++ b/drivers/bluetooth/btwilink.c
>> @@ -0,0 +1,379 @@
>> +/*
>> + * Â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@xxxxxx>
>> + * Â Pavan Savoy <pavan_savoy@xxxxxx>
>> + *
>> + * Â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 <linux/platform_device.h>
>> +#include <net/bluetooth/bluetooth.h>
>> +#include <net/bluetooth/hci_core.h>
>> +
>> +#include <linux/ti_wilink_st.h>
>> +
>> +/* Bluetooth Driver Version */
>> +#define VERSION Â Â Â Â Â Â Â "1.0"
>> +
>> +/* Number of seconds to wait for registration completion
>> + * when ST returns PENDING status.
>> + */
>> +#define BT_REGISTER_TIMEOUT Â 6000 Â /* 6 sec */
>> +
>> +/**
>> + * struct ti_st - driver operation structure
>> + * @hdev: hci device pointer which binds to bt driver
>> + * @reg_status: ST registration callback status
>> + * @st_write: write function provided by the ST driver
>> + * Â to be used by the driver during send_frame.
>> + * @wait_reg_completion - completion sync between ti_st_open
>> + * Â and ti_st_registration_completion_cb.
>> + */
>> +struct ti_st {
>> + Â Â struct hci_dev *hdev;
>> + Â Â char reg_status;
>> + Â Â long (*st_write) (struct sk_buff *);
>> + Â Â struct completion wait_reg_completion;
>> +};
>> +
>> +/* Increments HCI counters based on pocket ID (cmd,acl,sco) */
>> +static inline void ti_st_tx_complete(struct ti_st *hst, int pkt_type)
>> +{
>> + Â Â struct hci_dev *hdev = hst->hdev;
>> +
>> + Â Â /* Update HCI stat counters */
>> + Â Â switch (pkt_type) {
>> + Â Â case HCI_COMMAND_PKT:
>> + Â Â Â Â Â Â hdev->stat.cmd_tx++;
>> + Â Â Â Â Â Â break;
>> +
>> + Â Â case HCI_ACLDATA_PKT:
>> + Â Â Â Â Â Â hdev->stat.acl_tx++;
>> + Â Â Â Â Â Â break;
>> +
>> + Â Â case HCI_SCODATA_PKT:
>> + Â Â Â Â Â Â hdev->stat.sco_tx++;
>> + Â Â Â Â Â Â break;
>> + Â Â }
>> +}
>> +
>> +/* ------- Interfaces to Shared Transport ------ */
>> +
>> +/* Called by ST layer to indicate protocol registration completion
>> + * status.ti_st_open() function will wait for signal from this
>> + * API when st_register() function returns ST_PENDING.
>> + */
>> +static void st_registration_completion_cb(void *priv_data, char data)
>> +{
>> + Â Â struct ti_st *lhst = priv_data;
>> +
>> + Â Â /* Save registration status for use in ti_st_open() */
>> + Â Â lhst->reg_status = data;
>> + Â Â /* complete the wait in ti_st_open() */
>> + Â Â complete(&lhst->wait_reg_completion);
>> +}
>> +
>> +/* Called by Shared Transport layer when receive data is
>> + * available */
>> +static long st_receive(void *priv_data, struct sk_buff *skb)
>> +{
>> + Â Â struct ti_st *lhst = priv_data;
>> + Â Â int err;
>> +
>> + Â Â if (!skb)
>> + Â Â Â Â Â Â return -EFAULT;
>> +
>> + Â Â if (!lhst) {
>> + Â Â Â Â Â Â kfree_skb(skb);
>> + Â Â Â Â Â Â return -EFAULT;
>> + Â Â }
>> +
>> + Â Â skb->dev = (void *) lhst->hdev;
>> +
>> + Â Â /* Forward skb to HCI core layer */
>> + Â Â err = hci_recv_frame(skb);
>> + Â Â if (err < 0) {
>> + Â Â Â Â Â Â BT_ERR("Unable to push skb to HCI core(%d)", err);
>> + Â Â Â Â Â Â return err;
>> + Â Â }
>> +
>> + Â Â lhst->hdev->stat.byte_rx += skb->len;
>> +
>> + Â Â return 0;
>> +}
>> +
>> +/* ------- Interfaces to HCI layer ------ */
>> +/* protocol structure registered with shared transport */
>> +static struct st_proto_s ti_st_proto = {
>> + Â Â .type = ST_BT,
>> + Â Â .recv = st_receive,
>> + Â Â .reg_complete_cb = st_registration_completion_cb,
>> +};
>> +
>> +/* Called from HCI core to initialize the device */
>> +static int ti_st_open(struct hci_dev *hdev)
>> +{
>> + Â Â unsigned long timeleft;
>> + Â Â struct ti_st *hst;
>> + Â Â int err;
>> +
>> + Â Â BT_DBG("%s %p", hdev->name, hdev);
>> +
>> + Â Â /* provide contexts for callbacks from ST */
>> + Â Â hst = hdev->driver_data;
>> + Â Â ti_st_proto.priv_data = hst;
>> +
>> + Â Â err = st_register(&ti_st_proto);
>> + Â Â if (err == -EINPROGRESS) {
>> + Â Â Â Â Â Â /* Prepare wait-for-completion handler data structures.
>> + Â Â Â Â Â Â Â* Needed to synchronize this and
>> + Â Â Â Â Â Â Â* st_registration_completion_cb() functions.
>> + Â Â Â Â Â Â Â*/
>> + Â Â Â Â Â Â init_completion(&hst->wait_reg_completion);
>> +
>> + Â Â Â Â Â Â /* Reset ST registration callback status flag , this value
>> + Â Â Â Â Â Â Â* will be updated in ti_st_registration_completion_cb()
>> + Â Â Â Â Â Â Â* function whenever it called from ST driver.
>> + Â Â Â Â Â Â Â*/
>> + Â Â Â Â Â Â hst->reg_status = -EINPROGRESS;
>> +
>> + Â Â Â Â Â Â /* ST is busy with either protocol registration or firmware
>> + Â Â Â Â Â Â Â* download. Wait until the registration callback is called
>> + Â Â Â Â Â Â Â*/
>> + Â Â Â Â Â Â BT_DBG(" waiting for registration completion signal from ST");
>> +
>> + Â Â Â Â Â Â timeleft = wait_for_completion_timeout
>> + Â Â Â Â Â Â Â Â Â Â (&hst->wait_reg_completion,
>> + Â Â Â Â Â Â Â Â Â Â Âmsecs_to_jiffies(BT_REGISTER_TIMEOUT));
>> + Â Â Â Â Â Â if (!timeleft) {
>> + Â Â Â Â Â Â Â Â Â Â BT_ERR("Timeout(%d sec),didn't get reg "
>> + Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â "completion signal from ST",
>> + Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â BT_REGISTER_TIMEOUT / 1000);
>> + Â Â Â Â Â Â Â Â Â Â return -ETIMEDOUT;
>> + Â Â Â Â Â Â }
>> +
>> + Â Â Â Â Â Â /* Is ST registration callback called with ERROR status? */
>> + Â Â Â Â Â Â if (hst->reg_status != 0) {
>> + Â Â Â Â Â Â Â Â Â Â BT_ERR("ST registration completed with invalid "
>> + Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â "status %d", hst->reg_status);
>> + Â Â Â Â Â Â Â Â Â Â return -EAGAIN;
>> + Â Â Â Â Â Â }
>> + Â Â Â Â Â Â err = 0;
>> + Â Â } else if (err == -EPERM) {
>> + Â Â Â Â Â Â BT_ERR("st_register failed %d", err);
>> + Â Â Â Â Â Â return err;
>> + Â Â }
>
>
> Again, you are checking for only EPERM and EINPROGRESS. You should check
> for everything. I actually don't undertand why you have a special check
> for EPERM.
>
>> +
>> + Â Â /* ti_st_proto.write is filled up by the underlying shared
>> + Â Â Â* transport driver upon registration
>> + Â Â Â*/
>> + Â Â hst->st_write = ti_st_proto.write;
>
> I do not like that, the underlying should export the write function.
>
>> + Â Â if (!hst->st_write) {
>> + Â Â Â Â Â Â BT_ERR("undefined ST write function");
>> +
>> + Â Â Â Â Â Â /* Undo registration with ST */
>> + Â Â Â Â Â Â err = st_unregister(ST_BT);
>> + Â Â Â Â Â Â if (err)
>> + Â Â Â Â Â Â Â Â Â Â BT_ERR("st_unregister() failed with error %d", err);
>> +
>> + Â Â Â Â Â Â hst->st_write = NULL;
>> + Â Â Â Â Â Â return err;
>> + Â Â }
>> +
>> + Â Â /* Registration with ST layer is successful,
>> + Â Â Â* hardware is ready to accept commands from HCI core.
>> + Â Â Â*/
>> + Â Â if (test_and_set_bit(HCI_RUNNING, &hdev->flags)) {
>> + Â Â Â Â Â Â clear_bit(HCI_RUNNING, &hdev->flags);
>> + Â Â Â Â Â Â err = st_unregister(ST_BT);
>> + Â Â Â Â Â Â if (err)
>> + Â Â Â Â Â Â Â Â Â Â BT_ERR("st_unregister() failed with error %d", err);
>> + Â Â Â Â Â Â hst->st_write = NULL;
>> + Â Â }
>
>
> What are you trying to do here? test_and_set_bit() result doesn't say
> nothing about error and you shall put test_and_set_bit should be in the
> beginning, to know if your device is already opened or not and then
> clear_bit if some error ocurrs during the function.
>
>> +
>> + Â Â return err;
>> +}
>> +
>> +/* Close device */
>> +static int ti_st_close(struct hci_dev *hdev)
>> +{
>> + Â Â int err;
>> + Â Â struct ti_st *hst = hdev->driver_data;
>> +
>> + Â Â /* continue to unregister from transport */
>> + Â Â err = st_unregister(ST_BT);
>> + Â Â if (err)
>> + Â Â Â Â Â Â BT_ERR("st_unregister() failed with error %d", err);
>> +
>> + Â Â hst->st_write = NULL;
>> +
>> + Â Â if (!test_and_clear_bit(HCI_RUNNING, &hdev->flags))
>> + Â Â Â Â Â Â return 0;
>
> test_and_clear_bit should come first to check if your device is already
> closed.
>
>> +
>> + Â Â return err;
>> +}
>> +
>> +static int ti_st_send_frame(struct sk_buff *skb)
>> +{
>> + Â Â struct hci_dev *hdev;
>> + Â Â struct ti_st *hst;
>> + Â Â long len;
>> +
>> + Â Â hdev = (struct hci_dev *)skb->dev;
>> +
>> + Â Â if (!test_bit(HCI_RUNNING, &hdev->flags))
>> + Â Â Â Â Â Â return -EBUSY;
>> +
>> + Â Â hst = hdev->driver_data;
>> +
>> + Â Â /* Prepend skb with frame type */
>> + Â Â memcpy(skb_push(skb, 1), &bt_cb(skb)->pkt_type, 1);
>> +
>> + Â Â BT_DBG(" %s: type %d len %d", hdev->name, bt_cb(skb)->pkt_type,
>> + Â Â Â Â Â Â Â Â Â Â skb->len);
>> +
>> + Â Â /* Insert skb to shared transport layer's transmit queue.
>> + Â Â Â* Freeing skb memory is taken care in shared transport layer,
>> + Â Â Â* so don't free skb memory here.
>> + Â Â Â*/
>> + Â Â len = hst->st_write(skb);
>> + Â Â if (len < 0) {
>> + Â Â Â Â Â Â kfree_skb(skb);
>> + Â Â Â Â Â Â BT_ERR(" ST write failed (%ld)", len);
>> + Â Â Â Â Â Â return -EAGAIN;
>
> Why EAGAIN?
>
>> + Â Â }
>> +
>> + Â Â /* ST accepted our skb. So, Go ahead and do rest */
>> + Â Â hdev->stat.byte_tx += len;
>> + Â Â ti_st_tx_complete(hst, bt_cb(skb)->pkt_type);
>
> From Marcel in the other thread:
> "What is the reason for this deferred stats update. That code looks
> pretty much hackish to me."
>
>> +
>> + Â Â return 0;
>> +}
>> +
>> +static void ti_st_destruct(struct hci_dev *hdev)
>> +{
>> + Â Â BT_DBG("%s", hdev->name);
>> +
>> + Â Â /* free ti_st memory */
>
> get ride of the comment, it's pointless
>
>> + Â Â kfree(hdev->driver_data);
>> +
>> + Â Â return;
>
> No return; here
>
>> +}
>> +
>> +static int bt_ti_probe(struct platform_device *pdev)
>> +{
>> + Â Â static struct ti_st *hst;
>> + Â Â struct hci_dev *hdev;
>> + Â Â int err;
>> +
>> + Â Â hst = kzalloc(sizeof(struct ti_st), GFP_KERNEL);
>> + Â Â if (!hst)
>> + Â Â Â Â Â Â return -ENOMEM;
>> +
>> + Â Â /* Expose "hciX" device to user space */
>> + Â Â hdev = hci_alloc_dev();
>> + Â Â if (!hdev)
>> + Â Â Â Â Â Â return -ENOMEM;
>
> You are leaking hst, if hci_alloc_dev() fails.
>
>> +
>> + Â Â BT_DBG("hdev %p", hdev);
>> +
>> + Â Â hst->hdev = hdev;
>> + Â Â hdev->bus = HCI_UART;
>> + Â Â hdev->driver_data = hst;
>> + Â Â hdev->open = ti_st_open;
>> + Â Â hdev->close = ti_st_close;
>> + Â Â hdev->flush = NULL;
>> + Â Â hdev->send = ti_st_send_frame;
>> + Â Â hdev->destruct = ti_st_destruct;
>> + Â Â hdev->owner = THIS_MODULE;
>> +
>> + Â Â err = hci_register_dev(hdev);
>> + Â Â if (err < 0) {
>> + Â Â Â Â Â Â BT_ERR("Can't register HCI device error %d", err);
>> + Â Â Â Â Â Â hci_free_dev(hdev);
>> + Â Â Â Â Â Â return err;
>> + Â Â }
>> +
>> + Â Â BT_DBG(" HCI device registered (hdev %p)", hdev);
>> +
>> + Â Â dev_set_drvdata(&pdev->dev, hst);
>> + Â Â return err;
>> +}
>> +
>> +static int bt_ti_remove(struct platform_device *pdev)
>> +{
>> + Â Â struct hci_dev *hdev;
>> + Â Â struct ti_st *hst = dev_get_drvdata(&pdev->dev);
>> +
>> + Â Â if (!hst)
>> + Â Â Â Â Â Â return -EFAULT;
>> +
>> + Â Â hdev = hst->hdev;
>> + Â Â ti_st_close(hdev);
>> + Â Â hci_unregister_dev(hdev);
>> +
>> + Â Â /* Free HCI device memory */
>> + Â Â hci_free_dev(hdev);
>> +
>> + Â Â /* Free driver data memory */
>
> get ride of both commnets here. The name of the funcion is already
> saying that.
>
>> + Â Â kfree(hst);
>> +
>> + Â Â dev_set_drvdata(&pdev->dev, NULL);
>> + Â Â return 0;
>> +}
>> +
>> +static struct platform_driver btwilink_driver = {
>> + Â Â .probe = bt_ti_probe,
>> + Â Â .remove = bt_ti_remove,
>> + Â Â .driver = {
>> + Â Â Â Â Â Â .name = "btwilink",
>> + Â Â Â Â Â Â .owner = THIS_MODULE,
>> + Â Â },
>> +};
>> +
>> +/* ------- Module Init/Exit interfaces ------ */
>> +static int __init btwilink_init(void)
>> +{
>> + Â Â long ret;
>> +
>> + Â Â BT_INFO(" Bluetooth Driver for TI WiLink - Version %s", VERSION);
>> +
>> + Â Â ret = platform_driver_register(&btwilink_driver);
>> + Â Â if (ret != 0) {
>> + Â Â Â Â Â Â BT_ERR("btwilink platform driver registration failed");
>> + Â Â Â Â Â Â return ret;
>> + Â Â }
>> + Â Â return 0;
>
> Old issue again:
>
> From Marcel: please just do like we do with all other drivers;
>
> Â Â Â ÂBT_INFO(...)
>
> Â Â Â Âreturn platform_driver_register(&btwilink_driver);
>
> --
> Gustavo F. Padovan
> http://profusion.mobi
> --
> To unsubscribe from this list: send the line "unsubscribe linux-bluetooth" in
> the body of a message to majordomo@xxxxxxxxxxxxxxx
> More majordomo info at Âhttp://vger.kernel.org/majordomo-info.html
>
--
To unsubscribe from this list: send the line "unsubscribe linux-bluetooth" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
