* Re: [BUG] usb problems in .38-rc3+
From: Ed Tomlinson @ 2011-02-06 4:27 UTC (permalink / raw)
To: Alan Stern; +Cc: linux-kernel, linux-bluetooth, linux-usb
In-Reply-To: <Pine.LNX.4.44L0.1102051515330.4210-100000@netrider.rowland.org>
On Saturday 05 February 2011 15:16:19 Alan Stern wrote:
> On Sat, 5 Feb 2011, Ed Tomlinson wrote:
>
> > Hi,
> >
> > My bluetooth usb dongle has stopped working in .38-rc3+
> >
> > Bus 002 Device 008: ID 0a12:0001 Cambridge Silicon Radio, Ltd Bluetooth Dongle (HCI mode)
> >
> > and in dmesg
> >
> > [108495.369056] usb 5-1: new full speed USB device using ohci_hcd and address 3
> > [108495.573077] usb 5-1: New USB device found, idVendor=0a12, idProduct=0001
> > [108495.580099] usb 5-1: New USB device strings: Mfr=0, Product=0, SerialNumber=0
> > [108652.971977] usb 5-1: USB disconnect, address 3
> > [108652.972718] btusb_bulk_complete: hci0 urb ffff8800684e99c0 failed to resubmit (19)
> > [108652.973725] btusb_bulk_complete: hci0 urb ffff8800684e9c00 failed to resubmit (19)
> > [108652.974707] btusb_intr_complete: hci0 urb ffff8800684e9840 failed to resubmit (19)
> > [108653.001690] btusb_send_frame: hci0 urb ffff8800bb42a240 submission failed
> > [108657.007541] usb 2-4.7: new full speed USB device using ehci_hcd and address 8
> > [108657.147736] usb 2-4.7: New USB device found, idVendor=0a12, idProduct=0001
> > [108657.154954] usb 2-4.7: New USB device strings: Mfr=0, Product=0, SerialNumber=0
> >
> > Its been working for years here.
> >
> > Any ideas on what to try or additional info to gather?
>
> Does it still work with earlier kernels or on other computers?
Alan,
yes its working fine with .37 so the hw is ok. It looks to be a change in .38 that triggered the failure.
Ed
.37 dmesg follows:
[ 10.515289] usb 2-4.7: new full speed USB device using ehci_hcd and address 5
[ 10.648949] usb 2-4.7: New USB device found, idVendor=0a12, idProduct=0001
[ 10.648952] usb 2-4.7: New USB device strings: Mfr=0, Product=0, SerialNumber=0
[ 10.832380] Bluetooth: Core ver 2.15
[ 10.832418] NET: Registered protocol family 31
[ 10.832421] Bluetooth: HCI device and connection manager initialized
[ 10.832425] Bluetooth: HCI socket layer initialized
[ 10.871896] Bluetooth: Generic Bluetooth USB driver ver 0.6
[ 10.872246] usbcore: registered new interface driver btusb
[ 11.816907] input: ov519 as /devices/pci0000:00/0000:00:12.1/usb4/4-1/input/input6
[ 11.817153] gspca: video0 created
[ 11.817382] usbcore: registered new interface driver usbserial_generic
[ 11.817385] usbserial: USB Serial Driver core
[ 11.818128] usbcore: registered new interface driver ov519
[ 11.820102] USB Serial support registered for pl2303
[ 11.820200] pl2303 5-3:1.0: PL-2303 hack: descriptors matched but endpoints did not
[ 11.820234] pl2303 5-3:1.1: pl2303 converter detected
[ 11.841717] usb 5-3: pl2303 converter now attached to ttyUSB0
[ 11.841742] usbcore: registered new interface driver pl2303
[ 11.841745] pl2303: Prolific PL2303 USB to serial adaptor driver
[ 28.477896] sr0: scsi3-mmc drive: 40x/40x writer cd/rw xa/form2 cdda tray
[ 28.477900] cdrom: Uniform CD-ROM driver Revision: 3.20
[ 28.478226] sr 6:0:0:0: Attached scsi CD-ROM sr0
[ 30.195117] powernow-k8: Found 1 AMD Phenom(tm) II X4 940 Processor (4 cpu cores) (version 2.20.00)
[ 30.195167] powernow-k8: 0 : pstate 0 (3000 MHz)
[ 30.195169] powernow-k8: 1 : pstate 1 (2300 MHz)
[ 30.195172] powernow-k8: 2 : pstate 2 (1800 MHz)
[ 30.195174] powernow-k8: 3 : pstate 3 (800 MHz)
[ 30.899098] EXT4-fs (sdb3): re-mounted. Opts: (null)
[ 31.194619] EXT4-fs (sdc3): mounted filesystem with ordered data mode. Opts: (null)
[ 33.673078] Bluetooth: L2CAP ver 2.15
[ 33.673090] Bluetooth: L2CAP socket layer initialized
[ 33.727139] Bluetooth: RFCOMM TTY layer initialized
[ 33.727168] Bluetooth: RFCOMM socket layer initialized
[ 33.727177] Bluetooth: RFCOMM ver 1.11
[ 33.814213] Bluetooth: BNEP (Ethernet Emulation) ver 1.3
[ 33.814223] Bluetooth: BNEP filters: protocol multicast
[ 33.861898] Bluetooth: SCO (Voice Link) ver 0.6
[ 33.861907] Bluetooth: SCO socket layer initialized
[ 35.600125] sky2 0000:02:00.0: eth0: enabling interface
[ 36.103536] Adding 5986300k swap on /dev/sdc2. Priority:-1 extents:1 across:5986300k
[ 36.116190] Adding 1020120k swap on /dev/sda2. Priority:-2 extents:1 across:1020120k
[ 37.355836] NET: Registered protocol family 10
[ 37.357093] lo: Disabled Privacy Extensions
[ 37.357355] ADDRCONF(NETDEV_UP): eth0: link is not ready
[ 38.198205] sky2 0000:02:00.0: eth0: Link is up at 1000 Mbps, full duplex, flow control both
[ 38.203688] ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
[ 47.727778] IPv6 over IPv4 tunneling driver
[ 47.728551] sit0: Disabled Privacy Extensions
[ 47.761803] tun: Universal TUN/TAP device driver, 1.6
[ 47.761813] tun: (C) 1999-2004 Max Krasnyansky <maxk@qualcomm.com>
[ 48.434301] eth0: no IPv6 routers present
[ 48.960936] sixxs: Disabled Privacy Extensions
[ 79.568088] Bluetooth: HIDP (Human Interface Emulation) ver 1.2
[ 79.593964] input: Apple Wireless Mouse as /devices/pci0000:00/0000:00:13.2/usb2/2-4/2-4.7/2-4.7:1.0/bluetooth/hci0/hci0:41/input7
[ 79.595105] magicmouse 0005:05AC:030D.0004: input,hidraw3: BLUETOOTH HID v0.84 Mouse [Apple Wireless Mouse] on 00:0A:3A:55:07:5A
^ permalink raw reply
* [PATCH] Bluetooth: Use proper timer for hci command timout
From: Ville Tervo @ 2011-02-07 8:26 UTC (permalink / raw)
To: linux-bluetooth; +Cc: Ville Tervo
Use proper timer instead of hci command flow control to timeout
failed hci commands. Otherwise stack ends up sending commands
when flow control is used to block new commands.
2010-09-01 18:29:41.592132 < HCI Command: Remote Name Request (0x01|0x0019) plen 10
bdaddr 00:16:CF:E1:C7:D7 mode 2 clkoffset 0x0000
2010-09-01 18:29:41.592681 > HCI Event: Command Status (0x0f) plen 4
Remote Name Request (0x01|0x0019) status 0x00 ncmd 0
2010-09-01 18:29:51.022033 < HCI Command: Remote Name Request Cancel (0x01|0x001a) plen 6
bdaddr 00:16:CF:E1:C7:D7
Signed-off-by: Ville Tervo <ville.tervo@nokia.com>
---
include/net/bluetooth/hci.h | 3 +++
include/net/bluetooth/hci_core.h | 12 +++++++++++-
net/bluetooth/hci_core.c | 21 +++++++++++++++------
net/bluetooth/hci_event.c | 6 ++++++
4 files changed, 35 insertions(+), 7 deletions(-)
diff --git a/include/net/bluetooth/hci.h b/include/net/bluetooth/hci.h
index 4bee030..e3f0c7d 100644
--- a/include/net/bluetooth/hci.h
+++ b/include/net/bluetooth/hci.h
@@ -119,6 +119,7 @@ enum {
#define HCI_PAIRING_TIMEOUT (60000) /* 60 seconds */
#define HCI_IDLE_TIMEOUT (6000) /* 6 seconds */
#define HCI_INIT_TIMEOUT (10000) /* 10 seconds */
+#define HCI_CMD_TIMEOUT (1000) /* 1 secs */
/* HCI data types */
#define HCI_COMMAND_PKT 0x01
@@ -242,6 +243,8 @@ enum {
#define HCI_AT_GENERAL_BONDING_MITM 0x05
/* ----- HCI Commands ---- */
+#define HCI_OP_NOP 0x0000
+
#define HCI_OP_INQUIRY 0x0401
struct hci_cp_inquiry {
__u8 lap[3];
diff --git a/include/net/bluetooth/hci_core.h b/include/net/bluetooth/hci_core.h
index 6163bff..42105f9 100644
--- a/include/net/bluetooth/hci_core.h
+++ b/include/net/bluetooth/hci_core.h
@@ -128,7 +128,6 @@ struct hci_dev {
unsigned int acl_pkts;
unsigned int sco_pkts;
- unsigned long cmd_last_tx;
unsigned long acl_last_tx;
unsigned long sco_last_tx;
@@ -138,6 +137,7 @@ struct hci_dev {
struct work_struct power_off;
struct timer_list off_timer;
+ struct timer_list cmd_timer;
struct tasklet_struct cmd_task;
struct tasklet_struct rx_task;
struct tasklet_struct tx_task;
@@ -417,6 +417,16 @@ static inline void hci_conn_put(struct hci_conn *conn)
}
}
+static inline void hci_start_cmd_timer(struct timer_list *timer)
+{
+ mod_timer(timer, jiffies + msecs_to_jiffies(HCI_CMD_TIMEOUT));
+}
+
+static inline void hci_stop_cmd_timer(struct timer_list *timer)
+{
+ del_timer(timer);
+}
+
/* ----- HCI Devices ----- */
static inline void __hci_dev_put(struct hci_dev *d)
{
diff --git a/net/bluetooth/hci_core.c b/net/bluetooth/hci_core.c
index 2f00322..dd8ca64 100644
--- a/net/bluetooth/hci_core.c
+++ b/net/bluetooth/hci_core.c
@@ -41,6 +41,7 @@
#include <linux/interrupt.h>
#include <linux/notifier.h>
#include <linux/rfkill.h>
+#include <linux/timer.h>
#include <net/sock.h>
#include <asm/system.h>
@@ -611,6 +612,7 @@ static int hci_dev_do_close(struct hci_dev *hdev)
/* Drop last sent command */
if (hdev->sent_cmd) {
+ del_timer_sync(&hdev->cmd_timer);
kfree_skb(hdev->sent_cmd);
hdev->sent_cmd = NULL;
}
@@ -1054,6 +1056,16 @@ int hci_remove_link_key(struct hci_dev *hdev, bdaddr_t *bdaddr)
return 0;
}
+/* HCI command timer function */
+static void hci_cmd_timer(unsigned long arg)
+{
+ struct hci_dev *hdev = (void *) arg;
+
+ BT_ERR("%s command tx timeout", hdev->name);
+ atomic_set(&hdev->cmd_cnt, 1);
+ tasklet_schedule(&hdev->cmd_task);
+}
+
/* Register HCI device */
int hci_register_dev(struct hci_dev *hdev)
{
@@ -1100,6 +1112,8 @@ int hci_register_dev(struct hci_dev *hdev)
skb_queue_head_init(&hdev->cmd_q);
skb_queue_head_init(&hdev->raw_q);
+ setup_timer(&hdev->cmd_timer, hci_cmd_timer, (unsigned long) hdev);
+
for (i = 0; i < NUM_REASSEMBLY; i++)
hdev->reassembly[i] = NULL;
@@ -1936,11 +1950,6 @@ static void hci_cmd_task(unsigned long arg)
BT_DBG("%s cmd %d", hdev->name, atomic_read(&hdev->cmd_cnt));
- if (!atomic_read(&hdev->cmd_cnt) && time_after(jiffies, hdev->cmd_last_tx + HZ)) {
- BT_ERR("%s command tx timeout", hdev->name);
- atomic_set(&hdev->cmd_cnt, 1);
- }
-
/* Send queued commands */
if (atomic_read(&hdev->cmd_cnt)) {
skb = skb_dequeue(&hdev->cmd_q);
@@ -1953,7 +1962,7 @@ static void hci_cmd_task(unsigned long arg)
if (hdev->sent_cmd) {
atomic_dec(&hdev->cmd_cnt);
hci_send_frame(skb);
- hdev->cmd_last_tx = jiffies;
+ hci_start_cmd_timer(&hdev->cmd_timer);
} else {
skb_queue_head(&hdev->cmd_q, skb);
tasklet_schedule(&hdev->cmd_task);
diff --git a/net/bluetooth/hci_event.c b/net/bluetooth/hci_event.c
index cee46cb..021f889 100644
--- a/net/bluetooth/hci_event.c
+++ b/net/bluetooth/hci_event.c
@@ -1672,6 +1672,9 @@ static inline void hci_cmd_complete_evt(struct hci_dev *hdev, struct sk_buff *sk
break;
}
+ if (ev->opcode != HCI_OP_NOP)
+ hci_stop_cmd_timer(&hdev->cmd_timer);
+
if (ev->ncmd) {
atomic_set(&hdev->cmd_cnt, 1);
if (!skb_queue_empty(&hdev->cmd_q))
@@ -1743,6 +1746,9 @@ static inline void hci_cmd_status_evt(struct hci_dev *hdev, struct sk_buff *skb)
break;
}
+ if (ev->opcode != HCI_OP_NOP)
+ hci_stop_cmd_timer(&hdev->cmd_timer);
+
if (ev->ncmd) {
atomic_set(&hdev->cmd_cnt, 1);
if (!skb_queue_empty(&hdev->cmd_q))
--
1.7.2.3
^ permalink raw reply related
* Status of MAP and AVRCP
From: Deepak Saxena @ 2011-02-07 9:08 UTC (permalink / raw)
To: linux-bluetooth
Hi,
I am wondering about the status of AVRCP and MAP profile support
in the current BlueZ tree. It looks like ther were a few GSOC
projects related to adding/extending these last year, but from
my quick skim, it does not look like these were integrated
upstream. Was an attempt made to push these changes and did
they get reject? Is someone still driving this work within the
BlueZ community to make sure it goes upstream?
Thanks,
~Deepak
--
"People think all we need to fix our predicament is a free source of
energy, but I think we need to change out behaviour. More energy would
just deplete the Earth's lifeblood faster." - Janine Benyius
^ permalink raw reply
* Re: [BUG] usb problems in .38-rc3+
From: Oliver Neukum @ 2011-02-07 9:09 UTC (permalink / raw)
To: Ed Tomlinson; +Cc: linux-kernel, linux-bluetooth, linux-usb
In-Reply-To: <201102051417.58953.edt@aei.ca>
Am Samstag, 5. Februar 2011, 20:17:57 schrieb Ed Tomlinson:
> Hi,
>
> My bluetooth usb dongle has stopped working in .38-rc3+
>
> Bus 002 Device 008: ID 0a12:0001 Cambridge Silicon Radio, Ltd Bluetooth Dongle (HCI mode)
>
> and in dmesg
>
> [108495.369056] usb 5-1: new full speed USB device using ohci_hcd and address 3
> [108495.573077] usb 5-1: New USB device found, idVendor=0a12, idProduct=0001
> [108495.580099] usb 5-1: New USB device strings: Mfr=0, Product=0, SerialNumber=0
> [108652.971977] usb 5-1: USB disconnect, address 3
> [108652.972718] btusb_bulk_complete: hci0 urb ffff8800684e99c0 failed to resubmit (19)
> [108652.973725] btusb_bulk_complete: hci0 urb ffff8800684e9c00 failed to resubmit (19)
> [108652.974707] btusb_intr_complete: hci0 urb ffff8800684e9840 failed to resubmit (19)
> [108653.001690] btusb_send_frame: hci0 urb ffff8800bb42a240 submission failed
> [108657.007541] usb 2-4.7: new full speed USB device using ehci_hcd and address 8
> [108657.147736] usb 2-4.7: New USB device found, idVendor=0a12, idProduct=0001
> [108657.154954] usb 2-4.7: New USB device strings: Mfr=0, Product=0, SerialNumber=0
>
> Its been working for years here.
>
> Any ideas on what to try or additional info to gather?
Please test what happens if you disable runtime power management.
Regards
Oliver
^ permalink raw reply
* [PATCH] Bluetooth: btwilink driver
From: pavan_savoy @ 2011-02-07 10:38 UTC (permalink / raw)
To: linux-bluetooth, padovan; +Cc: marcel, Pavan Savoy
From: Pavan Savoy <pavan_savoy@ti.com>
Gustavo,
As suggested, the modifications to TI ST driver to remove the bluetooth
references have been made and the changes have been merged to the
linux-next tree.
Find below the patch for the btwilink driver,
I have taken care of your following comments,
1. channel IDs and the offsets are now being taken from the
header file hci.h.
2. removed the un-necessary BT_ERR.
3. changed the order during return from st_register.
4. continue to unregister even if 1st unregister fails.
Please review and provide comments,
Thanks & Regards,
Pavan Savoy
-- patch description --
This is the bluetooth protocol driver for the TI WiLink7 chipsets.
Texas Instrument's WiLink chipsets combine wireless technologies
like BT, FM, GPS and WLAN onto a single chip.
This Bluetooth driver works on top of the TI_ST shared transport
line discipline driver which also allows other drivers like
FM V4L2 and GPS character driver to make use of the same UART interface.
Kconfig and Makefile modifications to enable the Bluetooth
driver for Texas Instrument's WiLink 7 chipset.
Signed-off-by: Pavan Savoy <pavan_savoy@ti.com>
---
drivers/bluetooth/Kconfig | 10 +
drivers/bluetooth/Makefile | 1 +
drivers/bluetooth/btwilink.c | 397 ++++++++++++++++++++++++++++++++++++++++++
3 files changed, 408 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..c75d8af
--- /dev/null
+++ b/drivers/bluetooth/btwilink.c
@@ -0,0 +1,397 @@
+/*
+ * 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
+ *
+ */
+
+#include <linux/platform_device.h>
+#include <net/bluetooth/bluetooth.h>
+#include <net/bluetooth/hci_core.h>
+#include <net/bluetooth/hci.h>
+
+#include <linux/ti_wilink_st.h>
+
+/* Bluetooth Driver Version */
+#define VERSION "1.0"
+#define MAX_BT_CHNL_IDS 3
+
+/* 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[MAX_BT_CHNL_IDS] = {
+ {
+ .chnl_id = HCI_ACLDATA_PKT, /* ACL */
+ .recv = st_receive,
+ .reg_complete_cb = st_registration_completion_cb,
+ .hdr_len = sizeof(struct hci_acl_hdr),
+ .offset_len_in_hdr = offsetof(struct hci_acl_hdr, dlen),
+ .len_size = 2, /* sizeof(dlen) in struct hci_acl_hdr */
+ .reserve = 8,
+ },
+ {
+ .chnl_id = HCI_SCODATA_PKT, /* SCO */
+ .recv = st_receive,
+ .reg_complete_cb = st_registration_completion_cb,
+ .hdr_len = sizeof(struct hci_sco_hdr),
+ .offset_len_in_hdr = offsetof(struct hci_sco_hdr, dlen),
+ .len_size = 1, /* sizeof(dlen) in struct hci_sco_hdr */
+ .reserve = 8,
+ },
+ {
+ .chnl_id = HCI_EVENT_PKT, /* HCI Events */
+ .recv = st_receive,
+ .reg_complete_cb = st_registration_completion_cb,
+ .hdr_len = sizeof(struct hci_event_hdr),
+ .offset_len_in_hdr = offsetof(struct hci_event_hdr, plen),
+ .len_size = 1, /* sizeof(plen) in struct hci_event_hdr */
+ .reserve = 8,
+ },
+};
+
+/* 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, i;
+
+ BT_DBG("%s %p", hdev->name, hdev);
+
+ if (test_and_set_bit(HCI_RUNNING, &hdev->flags))
+ return -EBUSY;
+
+ /* provide contexts for callbacks from ST */
+ hst = hdev->driver_data;
+
+ for (i = 0; i < MAX_BT_CHNL_IDS; i++) {
+ ti_st_proto[i].priv_data = hst;
+ ti_st_proto[i].max_frame_size = HCI_MAX_FRAME_SIZE;
+
+ err = st_register(&ti_st_proto[i]);
+ if (!err)
+ goto done_downloading_firmware;
+
+ if (err != -EINPROGRESS) {
+ clear_bit(HCI_RUNNING, &hdev->flags);
+ BT_ERR("st_register failed %d", err);
+ return err;
+ } else {
+ /* ST is busy with either protocol
+ * registration or firmware download.
+ */
+ /* Prepare wait-for-completion handler data structures.
+ */
+ 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;
+
+ 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) {
+ clear_bit(HCI_RUNNING, &hdev->flags);
+ 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) {
+ clear_bit(HCI_RUNNING, &hdev->flags);
+ BT_ERR("ST registration completed with invalid "
+ "status %d", hst->reg_status);
+ return -EAGAIN;
+ }
+ }
+
+done_downloading_firmware:
+ hst->st_write = ti_st_proto[i].write;
+ if (!hst->st_write) {
+ BT_ERR("undefined ST write function");
+ clear_bit(HCI_RUNNING, &hdev->flags);
+ for (i = 0; i < MAX_BT_CHNL_IDS; i++) {
+ /* Undo registration with ST */
+ err = st_unregister(&ti_st_proto[i]);
+ if (err)
+ BT_ERR("st_unregister() failed with "
+ "error %d", err);
+ hst->st_write = NULL;
+ }
+ return -EIO;
+ }
+ }
+ return 0;
+}
+
+/* Close device */
+static int ti_st_close(struct hci_dev *hdev)
+{
+ int err, i;
+ struct ti_st *hst = hdev->driver_data;
+
+ if (!test_and_clear_bit(HCI_RUNNING, &hdev->flags))
+ return 0;
+
+ for (i = 0; i < MAX_BT_CHNL_IDS; i++) {
+ err = st_unregister(&ti_st_proto[i]);
+ if (err)
+ BT_ERR("st_unregister(%d) failed with error %d",
+ ti_st_proto[i].chnl_id, err);
+ }
+
+ hst->st_write = NULL;
+
+ 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);
+ /* Try Again, would only fail if UART has gone bad */
+ return -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);
+
+ return 0;
+}
+
+static void ti_st_destruct(struct hci_dev *hdev)
+{
+ BT_DBG("%s", hdev->name);
+ kfree(hdev->driver_data);
+}
+
+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) {
+ kfree(hst);
+ return -ENOMEM;
+ }
+
+ 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);
+ kfree(hst);
+ 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);
+
+ hci_free_dev(hdev);
+ 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)
+{
+ BT_INFO("Bluetooth Driver for TI WiLink - Version %s", VERSION);
+
+ return platform_driver_register(&btwilink_driver);
+}
+
+static void __exit btwilink_exit(void)
+{
+ platform_driver_unregister(&btwilink_driver);
+}
+
+module_init(btwilink_init);
+module_exit(btwilink_exit);
+
+/* ------ Module Info ------ */
+
+MODULE_AUTHOR("Raja Mani <raja_mani@ti.com>");
+MODULE_DESCRIPTION("Bluetooth Driver for TI Shared Transport" VERSION);
+MODULE_VERSION(VERSION);
+MODULE_LICENSE("GPL");
--
1.6.3.3
^ permalink raw reply related
* Re: [PATCH] Bluetooth: btwilink driver
From: Ville Tervo @ 2011-02-07 10:54 UTC (permalink / raw)
To: ext pavan_savoy@ti.com; +Cc: linux-bluetooth, padovan, marcel
In-Reply-To: <1297075132-4694-1-git-send-email-pavan_savoy@ti.com>
Hi Pavan,
On Mon, Feb 07, 2011 at 04:38:52AM -0600, ext pavan_savoy@ti.com wrote:
> From: Pavan Savoy <pavan_savoy@ti.com>
>
> Gustavo,
>
> As suggested, the modifications to TI ST driver to remove the bluetooth
> references have been made and the changes have been merged to the
> linux-next tree.
>
> Find below the patch for the btwilink driver,
> I have taken care of your following comments,
> 1. channel IDs and the offsets are now being taken from the
> header file hci.h.
> 2. removed the un-necessary BT_ERR.
> 3. changed the order during return from st_register.
> 4. continue to unregister even if 1st unregister fails.
>
> Please review and provide comments,
Will do. Some comment
> +/* 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, i;
> +
> + BT_DBG("%s %p", hdev->name, hdev);
> +
> + if (test_and_set_bit(HCI_RUNNING, &hdev->flags))
> + return -EBUSY;
> +
> + /* provide contexts for callbacks from ST */
> + hst = hdev->driver_data;
> +
> + for (i = 0; i < MAX_BT_CHNL_IDS; i++) {
> + ti_st_proto[i].priv_data = hst;
> + ti_st_proto[i].max_frame_size = HCI_MAX_FRAME_SIZE;
> +
> + err = st_register(&ti_st_proto[i]);
> + if (!err)
> + goto done_downloading_firmware;
> +
> + if (err != -EINPROGRESS) {
> + clear_bit(HCI_RUNNING, &hdev->flags);
> + BT_ERR("st_register failed %d", err);
> + return err;
> + } else {
No need for else. Less indentation looks better to me at least.
> + /* ST is busy with either protocol
> + * registration or firmware download.
> + */
> + /* Prepare wait-for-completion handler data structures.
> + */
> + init_completion(&hst->wait_reg_completion);
init_completion should be done before startin action which executes complete().
IOW this should be before st_register if I understood this correctly.
Otherwise the started action might call complete before init_completion and
wait_for_completion_timeout will just time even everything went fine.
--
Ville
^ permalink raw reply
* Re: [PATCH] Bluetooth: btwilink driver
From: Pavan Savoy @ 2011-02-07 11:00 UTC (permalink / raw)
To: Ville Tervo; +Cc: linux-bluetooth, padovan, marcel
In-Reply-To: <20110207105453.GZ874@null>
On Mon, Feb 7, 2011 at 4:24 PM, Ville Tervo <ville.tervo@nokia.com> wrote:
> Hi Pavan,
>
> On Mon, Feb 07, 2011 at 04:38:52AM -0600, ext pavan_savoy@ti.com wrote:
>> From: Pavan Savoy <pavan_savoy@ti.com>
>>
>> Gustavo,
>>
>> As suggested, the modifications to TI ST driver to remove the bluetooth
>> references have been made and the changes have been merged to the
>> linux-next tree.
>>
>> Find below the patch for the btwilink driver,
>> I have taken care of your following comments,
>> 1. channel IDs and the offsets are now being taken from the
>> header file hci.h.
>> 2. removed the un-necessary BT_ERR.
>> 3. changed the order during return from st_register.
>> 4. continue to unregister even if 1st unregister fails.
>>
>> Please review and provide comments,
>
> Will do. Some comment
>
>> +/* 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, i;
>> +
>> + BT_DBG("%s %p", hdev->name, hdev);
>> +
>> + if (test_and_set_bit(HCI_RUNNING, &hdev->flags))
>> + return -EBUSY;
>> +
>> + /* provide contexts for callbacks from ST */
>> + hst = hdev->driver_data;
>> +
>> + for (i = 0; i < MAX_BT_CHNL_IDS; i++) {
>> + ti_st_proto[i].priv_data = hst;
>> + ti_st_proto[i].max_frame_size = HCI_MAX_FRAME_SIZE;
>> +
>> + err = st_register(&ti_st_proto[i]);
>> + if (!err)
>> + goto done_downloading_firmware;
>> +
>> + if (err != -EINPROGRESS) {
>> + clear_bit(HCI_RUNNING, &hdev->flags);
>> + BT_ERR("st_register failed %d", err);
>> + return err;
>> + } else {
>
> No need for else. Less indentation looks better to me at least.
OK, can do this.
>> + /* ST is busy with either protocol
>> + * registration or firmware download.
>> + */
>> + /* Prepare wait-for-completion handler data structures.
>> + */
>> + init_completion(&hst->wait_reg_completion);
>
> init_completion should be done before startin action which executes complete().
> IOW this should be before st_register if I understood this correctly.
>
> Otherwise the started action might call complete before init_completion and
> wait_for_completion_timeout will just time even everything went fine.
Humn, May be, However I would want to wait only when I am supposed to,
As in if EINPROGRESS happens (i.e firmware is already being downloaded because
of say FM or GPS..) then I would want to wait, Or else - I continue.
But Yes, may be having the INIT_COMPLETION before would not hurt in
that case either. (Haven't seen it fail though !! - even after testing
FM/GPS with BT multiple times..)
> --
> Ville
> --
> To unsubscribe from this list: send the line "unsubscribe linux-bluetooth" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply
* usb webcam, usb bluetooth dongle conflict
From: Episteme PROMENEUR @ 2011-02-07 11:34 UTC (permalink / raw)
To: linux-bluetooth
my webcam
Bus 002 Device 004: ID 046d:0850 Logitech, Inc. QuickCam Web
module : STV06xx
my bluetooth dongle :
Bus 002 Device 006: ID 0a12:0001 Cambridge Silicon Radio, Ltd Bluetooth Dongle
(HCI mode)
motherboard : Asus M2N, bios 803
Mandriva 2010.2 32 bit
kde 4.5.5
bluedevil 1.02
bluez 4.64
if i plug my bluetooth dongle
then
my webcam does not work
if i unplug my bluetooth dongle
then
my webcam works
if i activate my bluetooth dongle
then
my webcam does not work
if i unactivate my bluetooth dongle
then
my webcam works
^ permalink raw reply
* [PATCH v9] Bluetooth: btwilink driver
From: pavan_savoy @ 2011-02-07 12:12 UTC (permalink / raw)
To: linux-bluetooth, padovan; +Cc: marcel, Pavan Savoy
From: Pavan Savoy <pavan_savoy@ti.com>
Gustavo,
Find below the patch version v9.
Have taken care of Ville's comments.
In addition fixed the issue seen when built as module, with
repeated probe/remove of the platform driver.
patch v8 comments taken care,
As suggested, the modifications to TI ST driver to remove the bluetooth
references have been made and the changes have been merged to the
linux-next tree.
Find below the patch for the btwilink driver,
I have taken care of your following comments,
1. channel IDs and the offsets are now being taken from the
header file hci.h.
2. removed the un-necessary BT_ERR.
3. changed the order during return from st_register.
4. continue to unregister even if 1st unregister fails.
Please review and provide comments,
Thanks & Regards,
Pavan Savoy
-- patch description --
This is the bluetooth protocol driver for the TI WiLink7 chipsets.
Texas Instrument's WiLink chipsets combine wireless technologies
like BT, FM, GPS and WLAN onto a single chip.
This Bluetooth driver works on top of the TI_ST shared transport
line discipline driver which also allows other drivers like
FM V4L2 and GPS character driver to make use of the same UART interface.
Kconfig and Makefile modifications to enable the Bluetooth
driver for Texas Instrument's WiLink 7 chipset.
Signed-off-by: Pavan Savoy <pavan_savoy@ti.com>
---
drivers/bluetooth/Kconfig | 10 +
drivers/bluetooth/Makefile | 1 +
drivers/bluetooth/btwilink.c | 397 ++++++++++++++++++++++++++++++++++++++++++
3 files changed, 408 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..79c70c2
--- /dev/null
+++ b/drivers/bluetooth/btwilink.c
@@ -0,0 +1,397 @@
+/*
+ * 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 DEBUG
+#include <linux/platform_device.h>
+#include <net/bluetooth/bluetooth.h>
+#include <net/bluetooth/hci_core.h>
+#include <net/bluetooth/hci.h>
+
+#include <linux/ti_wilink_st.h>
+
+/* Bluetooth Driver Version */
+#define VERSION "1.0"
+#define MAX_BT_CHNL_IDS 3
+
+/* 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 st_reg_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_reg_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[MAX_BT_CHNL_IDS] = {
+ {
+ .chnl_id = HCI_ACLDATA_PKT, /* ACL */
+ .hdr_len = sizeof(struct hci_acl_hdr),
+ .offset_len_in_hdr = offsetof(struct hci_acl_hdr, dlen),
+ .len_size = 2, /* sizeof(dlen) in struct hci_acl_hdr */
+ .reserve = 8,
+ },
+ {
+ .chnl_id = HCI_SCODATA_PKT, /* SCO */
+ .hdr_len = sizeof(struct hci_sco_hdr),
+ .offset_len_in_hdr = offsetof(struct hci_sco_hdr, dlen),
+ .len_size = 1, /* sizeof(dlen) in struct hci_sco_hdr */
+ .reserve = 8,
+ },
+ {
+ .chnl_id = HCI_EVENT_PKT, /* HCI Events */
+ .hdr_len = sizeof(struct hci_event_hdr),
+ .offset_len_in_hdr = offsetof(struct hci_event_hdr, plen),
+ .len_size = 1, /* sizeof(plen) in struct hci_event_hdr */
+ .reserve = 8,
+ },
+};
+
+/* 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, i;
+
+ BT_DBG("%s %p", hdev->name, hdev);
+
+ if (test_and_set_bit(HCI_RUNNING, &hdev->flags))
+ return -EBUSY;
+
+ /* provide contexts for callbacks from ST */
+ hst = hdev->driver_data;
+
+ for (i = 0; i < MAX_BT_CHNL_IDS; i++) {
+ ti_st_proto[i].priv_data = hst;
+ ti_st_proto[i].max_frame_size = HCI_MAX_FRAME_SIZE;
+ ti_st_proto[i].recv = st_receive;
+ ti_st_proto[i].reg_complete_cb = st_reg_completion_cb;
+
+ /* Prepare wait-for-completion handler */
+ init_completion(&hst->wait_reg_completion);
+
+ err = st_register(&ti_st_proto[i]);
+ if (!err)
+ goto done_downloading_firmware;
+
+ if (err != -EINPROGRESS) {
+ clear_bit(HCI_RUNNING, &hdev->flags);
+ BT_ERR("st_register failed %d", err);
+ return err;
+ }
+
+ /* ST is busy with either protocol
+ * registration or firmware download.
+ */
+
+ /* Reset ST registration callback status flag,
+ * this value will be updated in
+ * st_reg_completion_cb()
+ * function whenever it called from ST driver.
+ */
+ hst->reg_status = -EINPROGRESS;
+
+ 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) {
+ clear_bit(HCI_RUNNING, &hdev->flags);
+ 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) {
+ clear_bit(HCI_RUNNING, &hdev->flags);
+ BT_ERR("ST registration completed with invalid "
+ "status %d", hst->reg_status);
+ return -EAGAIN;
+ }
+
+done_downloading_firmware:
+ hst->st_write = ti_st_proto[i].write;
+ if (!hst->st_write) {
+ BT_ERR("undefined ST write function");
+ clear_bit(HCI_RUNNING, &hdev->flags);
+ for (i = 0; i < MAX_BT_CHNL_IDS; i++) {
+ /* Undo registration with ST */
+ err = st_unregister(&ti_st_proto[i]);
+ if (err)
+ BT_ERR("st_unregister() failed with "
+ "error %d", err);
+ hst->st_write = NULL;
+ }
+ return -EIO;
+ }
+ }
+ return 0;
+}
+
+/* Close device */
+static int ti_st_close(struct hci_dev *hdev)
+{
+ int err, i;
+ struct ti_st *hst = hdev->driver_data;
+
+ if (!test_and_clear_bit(HCI_RUNNING, &hdev->flags))
+ return 0;
+
+ for (i = 0; i < MAX_BT_CHNL_IDS; i++) {
+ err = st_unregister(&ti_st_proto[i]);
+ if (err)
+ BT_ERR("st_unregister(%d) failed with error %d",
+ ti_st_proto[i].chnl_id, err);
+ }
+
+ hst->st_write = NULL;
+
+ 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);
+ /* Try Again, would only fail if UART has gone bad */
+ return -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);
+
+ return 0;
+}
+
+static void ti_st_destruct(struct hci_dev *hdev)
+{
+ BT_DBG("%s", hdev->name);
+ /* do nothing here, since platform remove
+ * would free the hdev->driver_data
+ */
+}
+
+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) {
+ kfree(hst);
+ return -ENOMEM;
+ }
+
+ 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);
+ kfree(hst);
+ 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;
+
+ BT_DBG("%s", hst->hdev->name);
+
+ hdev = hst->hdev;
+ ti_st_close(hdev);
+ hci_unregister_dev(hdev);
+
+ hci_free_dev(hdev);
+ 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)
+{
+ BT_INFO("Bluetooth Driver for TI WiLink - Version %s", VERSION);
+
+ return platform_driver_register(&btwilink_driver);
+}
+
+static void __exit btwilink_exit(void)
+{
+ platform_driver_unregister(&btwilink_driver);
+}
+
+module_init(btwilink_init);
+module_exit(btwilink_exit);
+
+/* ------ Module Info ------ */
+
+MODULE_AUTHOR("Raja Mani <raja_mani@ti.com>");
+MODULE_DESCRIPTION("Bluetooth Driver for TI Shared Transport" VERSION);
+MODULE_VERSION(VERSION);
+MODULE_LICENSE("GPL");
--
1.6.3.3
^ permalink raw reply related
* [PATCH 1/3] Add return value to reply_list_foreach_t in phonebook-tracker
From: Radoslaw Jablonski @ 2011-02-07 12:27 UTC (permalink / raw)
To: linux-bluetooth; +Cc: Radoslaw Jablonski
This changes are needed for notyfying that fetching data
from tracker should be stopped.
This will be usable in scenarios like:
*some error occurred during processing data
*maximum number of results already processed (due to pbap
maxlistcount parameter)
*suspending processing data if pbap buffer is too large
---
plugins/phonebook-tracker.c | 53 ++++++++++++++++++++++++++-----------------
1 files changed, 32 insertions(+), 21 deletions(-)
diff --git a/plugins/phonebook-tracker.c b/plugins/phonebook-tracker.c
index e116175..44cedfc 100644
--- a/plugins/phonebook-tracker.c
+++ b/plugins/phonebook-tracker.c
@@ -890,7 +890,7 @@
"} GROUP BY ?call ORDER BY DESC(nmo:receivedDate(?call)) " \
"LIMIT 40"
-typedef void (*reply_list_foreach_t) (const char **reply, int num_fields,
+typedef int (*reply_list_foreach_t) (const char **reply, int num_fields,
void *user_data);
typedef void (*add_field_t) (struct phonebook_contact *contact,
@@ -1042,6 +1042,7 @@ static void async_query_cursor_next_cb(GObject *source, GAsyncResult *result,
GError *error = NULL;
gboolean success;
const char **node;
+ int err;
success = tracker_sparql_cursor_next_finish(
TRACKER_SPARQL_CURSOR(source),
@@ -1061,17 +1062,22 @@ static void async_query_cursor_next_cb(GObject *source, GAsyncResult *result,
}
node = string_array_from_cursor(cursor, pending->num_fields);
- pending->callback(node, pending->num_fields, pending->user_data);
+ err = pending->callback(node, pending->num_fields, pending->user_data);
g_free(node);
-
- /* getting next row from query results */
- cancellable = g_cancellable_new();
- update_cancellable(pending->user_data, cancellable);
- tracker_sparql_cursor_next_async(cursor, cancellable,
+ /* Fetch next result only if processing current chunk ended with
+ * success. Sometimes during processing data, we are able to determine
+ * if there is no need to get more data from tracker - by example
+ * stored amount of data parts is big enough for sending and we might
+ * want to suspend processing or just some error occurred. */
+ if (!err) {
+ cancellable = g_cancellable_new();
+ update_cancellable(pending->user_data, cancellable);
+ tracker_sparql_cursor_next_async(cursor, cancellable,
async_query_cursor_next_cb,
pending);
- return;
+ return;
+ }
failed:
g_object_unref(cursor);
@@ -1330,23 +1336,24 @@ static GString *gen_vcards(GSList *contacts,
return vcards;
}
-static void pull_contacts_size(const char **reply, int num_fields,
+static int pull_contacts_size(const char **reply, int num_fields,
void *user_data)
{
struct phonebook_data *data = user_data;
if (num_fields < 0) {
data->cb(NULL, 0, num_fields, 0, data->user_data);
- return;
+ return -1;
}
if (reply != NULL) {
data->index = atoi(reply[0]);
- return;
+ return 0;
}
data->cb(NULL, 0, data->index, data->newmissedcalls, data->user_data);
+ return -1;
/*
* phonebook_data is freed in phonebook_req_finalize. Useful in
* cases when call is terminated.
@@ -1550,7 +1557,7 @@ static void contact_add_organization(struct phonebook_contact *contact,
add_affiliation(&contact->role, reply[COL_ORG_ROLE]);
}
-static void pull_contacts(const char **reply, int num_fields, void *user_data)
+static int pull_contacts(const char **reply, int num_fields, void *user_data)
{
struct phonebook_data *data = user_data;
const struct apparam_field *params = data->params;
@@ -1593,7 +1600,7 @@ static void pull_contacts(const char **reply, int num_fields, void *user_data)
if (i == num_fields - 4 && !g_str_equal(reply[CONTACTS_ID_COL],
TRACKER_DEFAULT_CONTACT_ME))
- return;
+ return 0;
if (g_strcmp0(temp_id, reply[CONTACTS_ID_COL])) {
data->index++;
@@ -1606,7 +1613,7 @@ static void pull_contacts(const char **reply, int num_fields, void *user_data)
if ((data->index <= params->liststartoffset ||
data->index > last_index) &&
params->maxlistcount > 0)
- return;
+ return 0;
add_entry:
contact = g_new0(struct phonebook_contact, 1);
@@ -1630,7 +1637,7 @@ add_numbers:
data->contacts = g_slist_append(data->contacts, contact_data);
}
- return;
+ return 0;
done:
vcards = gen_vcards(data->contacts, params);
@@ -1645,13 +1652,14 @@ fail:
g_free(temp_id);
temp_id = NULL;
+ return -1;
/*
* phonebook_data is freed in phonebook_req_finalize. Useful in
* cases when call is terminated.
*/
}
-static void add_to_cache(const char **reply, int num_fields, void *user_data)
+static int add_to_cache(const char **reply, int num_fields, void *user_data)
{
struct phonebook_data *data = user_data;
char *formatted;
@@ -1668,7 +1676,7 @@ static void add_to_cache(const char **reply, int num_fields, void *user_data)
if (i == num_fields &&
!g_str_equal(reply[0], TRACKER_DEFAULT_CONTACT_ME))
- return;
+ return 0;
if (i == 6)
formatted = g_strdup(reply[6]);
@@ -1687,12 +1695,13 @@ static void add_to_cache(const char **reply, int num_fields, void *user_data)
g_free(formatted);
- return;
+ return 0;
done:
if (num_fields <= 0)
data->ready_cb(data->user_data);
+ return -1;
/*
* phonebook_data is freed in phonebook_req_finalize. Useful in
* cases when call is terminated.
@@ -1834,7 +1843,7 @@ static void gstring_free_helper(gpointer data, gpointer user_data)
g_string_free(data, TRUE);
}
-static void pull_newmissedcalls(const char **reply, int num_fields,
+static int pull_newmissedcalls(const char **reply, int num_fields,
void *user_data)
{
struct phonebook_data *data = user_data;
@@ -1854,7 +1863,7 @@ static void pull_newmissedcalls(const char **reply, int num_fields,
number);
}
}
- return;
+ return 0;
done:
DBG("newmissedcalls %d", data->newmissedcalls);
@@ -1864,7 +1873,7 @@ done:
if (num_fields < 0) {
data->cb(NULL, 0, num_fields, 0, data->user_data);
- return;
+ return -1;
}
if (data->params->maxlistcount == 0) {
@@ -1880,6 +1889,8 @@ done:
query_tracker(query, col_amount, pull_cb, data, &err);
if (err < 0)
data->cb(NULL, 0, err, 0, data->user_data);
+
+ return -1;
}
void *phonebook_pull(const char *name, const struct apparam_field *params,
--
1.7.0.4
^ permalink raw reply related
* [PATCH 2/3] Remove unnecessary checking for num_fields in pull_contact
From: Radoslaw Jablonski @ 2011-02-07 12:27 UTC (permalink / raw)
To: linux-bluetooth; +Cc: Radoslaw Jablonski
In-Reply-To: <1297081658-30573-1-git-send-email-ext-jablonski.radoslaw@nokia.com>
This check is no longer needed - it was used to ensure that no
error occured in querying tracker. This is redundant because
checking for that case is located in the beginning of pull_contacts
function.
---
plugins/phonebook-tracker.c | 4 +---
1 files changed, 1 insertions(+), 3 deletions(-)
diff --git a/plugins/phonebook-tracker.c b/plugins/phonebook-tracker.c
index 44cedfc..61c7e90 100644
--- a/plugins/phonebook-tracker.c
+++ b/plugins/phonebook-tracker.c
@@ -1642,9 +1642,7 @@ add_numbers:
done:
vcards = gen_vcards(data->contacts, params);
- if (num_fields == 0)
- data->cb(vcards->str, vcards->len,
- g_slist_length(data->contacts),
+ data->cb(vcards->str, vcards->len, g_slist_length(data->contacts),
data->newmissedcalls, data->user_data);
g_string_free(vcards, TRUE);
--
1.7.0.4
^ permalink raw reply related
* [PATCH 3/3] Support for stop fetching data when maxlistcount is achieved
From: Radoslaw Jablonski @ 2011-02-07 12:27 UTC (permalink / raw)
To: linux-bluetooth; +Cc: Radoslaw Jablonski
In-Reply-To: <1297081658-30573-1-git-send-email-ext-jablonski.radoslaw@nokia.com>
When desired number of results has been already processed,
then sending already collected data and stopping fetching
more results from tracker (previously in this scenario
unnecessarily processing data continued untill end of results
in db)
---
plugins/phonebook-tracker.c | 12 +++++++++---
1 files changed, 9 insertions(+), 3 deletions(-)
diff --git a/plugins/phonebook-tracker.c b/plugins/phonebook-tracker.c
index 61c7e90..f00d23c 100644
--- a/plugins/phonebook-tracker.c
+++ b/plugins/phonebook-tracker.c
@@ -1610,11 +1610,17 @@ static int pull_contacts(const char **reply, int num_fields, void *user_data)
last_index = params->liststartoffset + params->maxlistcount;
- if ((data->index <= params->liststartoffset ||
- data->index > last_index) &&
- params->maxlistcount > 0)
+ if (data->index <= params->liststartoffset)
return 0;
+ /* max number of results achieved - need send vcards data that was
+ * already collected and stop further data processing (these operations
+ * will be invoked in "done" section) */
+ if (data->index > last_index && params->maxlistcount > 0) {
+ DBG("Maxlistcount achieved");
+ goto done;
+ }
+
add_entry:
contact = g_new0(struct phonebook_contact, 1);
contact_init(contact, reply);
--
1.7.0.4
^ permalink raw reply related
* [PATCH] Sim Access Profile API
From: Harald Schmitt @ 2011-02-07 12:41 UTC (permalink / raw)
To: linux-bluetooth
New API for Sim Access Profile by Waldemar Rymarkiewicz
---
Makefile.am | 3 ++-
doc/sap-api.txt | 34 ++++++++++++++++++++++++++++++++++
2 files changed, 36 insertions(+), 1 deletions(-)
create mode 100644 doc/sap-api.txt
diff --git a/Makefile.am b/Makefile.am
index e6639a7..7975dfa 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -354,7 +354,8 @@ EXTRA_DIST += doc/manager-api.txt \
doc/service-api.txt doc/agent-api.txt doc/attribute-api.txt \
doc/serial-api.txt doc/network-api.txt \
doc/input-api.txt doc/audio-api.txt doc/control-api.txt \
- doc/hfp-api.txt doc/health-api.txt doc/assigned-numbers.txt
+ doc/hfp-api.txt doc/health-api.txt doc/sap-api.txt \
+ doc/assigned-numbers.txt
AM_YFLAGS = -d
diff --git a/doc/sap-api.txt b/doc/sap-api.txt
new file mode 100644
index 0000000..b8b7253
--- /dev/null
+++ b/doc/sap-api.txt
@@ -0,0 +1,34 @@
+BlueZ D-Bus Sim Access Profile API description
+***********************************
+
+Copyright (C) 2010 ST-Ericsson SA
+
+
+Sim Access Profile hierarchy
+============================
+
+Service org.bluez
+Interface org.bluez.SimAccess
+Object path [variable prefix]/{hci0,hci1,...}
+
+Methods void Disconnect()
+
+ Disconnects SAP client from the server.
+
+ Possible errors: org.bluez.Error.Failed
+
+ dict GetProperties()
+
+ Return all properties for the interface. See the
+ properties section for available properties.
+
+ Possible Errors: org.bluez.Error.Failed
+
+Signals PropertyChanged(string name, variant value)
+
+ This signal indicates a changed value of the given
+ property.
+
+Properties boolean Connected [readonly]
+
+ Indicates if SAP client is connected to the server.
--
1.7.1
^ permalink raw reply related
* Re: [PATCH] Sim Access Profile API
From: Harald Schmitt @ 2011-02-07 12:49 UTC (permalink / raw)
To: linux-bluetooth
In-Reply-To: <4D4FE85E.4010108@hschmitt.de>
Am 07.02.2011 13:41, schrieb Harald Schmitt:
> New API for Sim Access Profile by Waldemar Rymarkiewicz
> ---
> Makefile.am | 3 ++-
> doc/sap-api.txt | 34 ++++++++++++++++++++++++++++++++++
> 2 files changed, 36 insertions(+), 1 deletions(-)
> create mode 100644 doc/sap-api.txt
>
> diff --git a/Makefile.am b/Makefile.am
> index e6639a7..7975dfa 100644
> --- a/Makefile.am
> +++ b/Makefile.am
> @@ -354,7 +354,8 @@ EXTRA_DIST += doc/manager-api.txt \
> doc/service-api.txt doc/agent-api.txt doc/attribute-api.txt \
> doc/serial-api.txt doc/network-api.txt \
> doc/input-api.txt doc/audio-api.txt doc/control-api.txt \
> - doc/hfp-api.txt doc/health-api.txt doc/assigned-numbers.txt
> + doc/hfp-api.txt doc/health-api.txt doc/sap-api.txt \
> + doc/assigned-numbers.txt
> AM_YFLAGS = -d
> diff --git a/doc/sap-api.txt b/doc/sap-api.txt
> new file mode 100644
> index 0000000..b8b7253
> --- /dev/null
> +++ b/doc/sap-api.txt
> @@ -0,0 +1,34 @@
> +BlueZ D-Bus Sim Access Profile API description
> +***********************************
> +
> +Copyright (C) 2010 ST-Ericsson SA
> +
> +
> +Sim Access Profile hierarchy
> +============================
> +
> +Service org.bluez
> +Interface org.bluez.SimAccess
> +Object path [variable prefix]/{hci0,hci1,...}
> +
> +Methods void Disconnect()
> +
> + Disconnects SAP client from the server.
> +
> + Possible errors: org.bluez.Error.Failed
> +
> + dict GetProperties()
> +
> + Return all properties for the interface. See the
> + properties section for available properties.
> +
> + Possible Errors: org.bluez.Error.Failed
> +
> +Signals PropertyChanged(string name, variant value)
> +
> + This signal indicates a changed value of the given
> + property.
> +
> +Properties boolean Connected [readonly]
> +
> + Indicates if SAP client is connected to the server.
I took the patch from Waldemar Rymarkiewicz (2010-12-02) and did the
restructuring in Makefile.am as commented from Gustavo F. Padovan.
Are there any other comments?
Best regards,
Harald
^ permalink raw reply
* RE: [PATCH] Sim Access Profile API
From: Waldemar.Rymarkiewicz @ 2011-02-07 13:31 UTC (permalink / raw)
To: linux, linux-bluetooth
In-Reply-To: <4D4FEA59.9010607@hschmitt.de>
Hi,
>Am 07.02.2011 13:41, schrieb Harald Schmitt:
>> New API for Sim Access Profile by Waldemar Rymarkiewicz
>> ---
>> Makefile.am | 3 ++-
>> doc/sap-api.txt | 34 ++++++++++++++++++++++++++++++++++
>> 2 files changed, 36 insertions(+), 1 deletions(-) create
>mode 100644
>> doc/sap-api.txt
>>
>> diff --git a/Makefile.am b/Makefile.am index e6639a7..7975dfa 100644
>> --- a/Makefile.am
>> +++ b/Makefile.am
>> @@ -354,7 +354,8 @@ EXTRA_DIST += doc/manager-api.txt \
>> doc/service-api.txt doc/agent-api.txt
>doc/attribute-api.txt \
>> doc/serial-api.txt doc/network-api.txt \
>> doc/input-api.txt doc/audio-api.txt
>doc/control-api.txt \
>> - doc/hfp-api.txt doc/health-api.txt
>doc/assigned-numbers.txt
>> + doc/hfp-api.txt doc/health-api.txt doc/sap-api.txt \
>> + doc/assigned-numbers.txt
>> AM_YFLAGS = -d
>> diff --git a/doc/sap-api.txt b/doc/sap-api.txt new file mode 100644
>> index 0000000..b8b7253
>> --- /dev/null
>> +++ b/doc/sap-api.txt
>> @@ -0,0 +1,34 @@
>> +BlueZ D-Bus Sim Access Profile API description
>> +***********************************
>> +
>> +Copyright (C) 2010 ST-Ericsson SA
>> +
>> +
>> +Sim Access Profile hierarchy
>> +============================
>> +
>> +Service org.bluez
>> +Interface org.bluez.SimAccess
>> +Object path [variable prefix]/{hci0,hci1,...}
>> +
>> +Methods void Disconnect()
>> +
>> + Disconnects SAP client from the server.
>> +
>> + Possible errors: org.bluez.Error.Failed
>> +
>> + dict GetProperties()
>> +
>> + Return all properties for the interface. See the
>> + properties section for available properties.
>> +
>> + Possible Errors: org.bluez.Error.Failed
>> +
>> +Signals PropertyChanged(string name, variant value)
>> +
>> + This signal indicates a changed value
>of the given
>> + property.
>> +
>> +Properties boolean Connected [readonly]
>> +
>> + Indicates if SAP client is connected to
>the server.
>
>I took the patch from Waldemar Rymarkiewicz (2010-12-02) and
>did the restructuring in Makefile.am as commented from Gustavo
>F. Padovan.
>Are there any other comments?
What kind of restructuring did you do? I cannot notice any difference.
Is this just a rebase ?
Thanks,
/Waldek
^ permalink raw reply
* Re: [PATCH] Sim Access Profile API
From: Harald Schmitt @ 2011-02-07 13:44 UTC (permalink / raw)
To: linux-bluetooth; +Cc: Waldemar.Rymarkiewicz
In-Reply-To: <99B09243E1A5DA4898CDD8B700111448107E6AB9F2@EXMB04.eu.tieto.com>
Am 07.02.2011 14:31, schrieb Waldemar.Rymarkiewicz@tieto.com:
> Hi,
>
>> Am 07.02.2011 13:41, schrieb Harald Schmitt:
>>> New API for Sim Access Profile by Waldemar Rymarkiewicz
>>> ---
>>> Makefile.am | 3 ++-
>>> doc/sap-api.txt | 34 ++++++++++++++++++++++++++++++++++
>>> 2 files changed, 36 insertions(+), 1 deletions(-) create
>> mode 100644
>>> doc/sap-api.txt
>>>
>>> diff --git a/Makefile.am b/Makefile.am index e6639a7..7975dfa 100644
>>> --- a/Makefile.am
>>> +++ b/Makefile.am
>>> @@ -354,7 +354,8 @@ EXTRA_DIST += doc/manager-api.txt \
>>> doc/service-api.txt doc/agent-api.txt
>> doc/attribute-api.txt \
>>> doc/serial-api.txt doc/network-api.txt \
>>> doc/input-api.txt doc/audio-api.txt
>> doc/control-api.txt \
>>> - doc/hfp-api.txt doc/health-api.txt
>> doc/assigned-numbers.txt
>>> + doc/hfp-api.txt doc/health-api.txt doc/sap-api.txt \
>>> + doc/assigned-numbers.txt
>>> AM_YFLAGS = -d
>>> diff --git a/doc/sap-api.txt b/doc/sap-api.txt new file mode 100644
>>> index 0000000..b8b7253
>>> --- /dev/null
>>> +++ b/doc/sap-api.txt
>>> @@ -0,0 +1,34 @@
>>> +BlueZ D-Bus Sim Access Profile API description
>>> +***********************************
>>> +
>>> +Copyright (C) 2010 ST-Ericsson SA
>>> +
>>> +
>>> +Sim Access Profile hierarchy
>>> +============================
>>> +
>>> +Service org.bluez
>>> +Interface org.bluez.SimAccess
>>> +Object path [variable prefix]/{hci0,hci1,...}
>>> +
>>> +Methods void Disconnect()
>>> +
>>> + Disconnects SAP client from the server.
>>> +
>>> + Possible errors: org.bluez.Error.Failed
>>> +
>>> + dict GetProperties()
>>> +
>>> + Return all properties for the interface. See the
>>> + properties section for available properties.
>>> +
>>> + Possible Errors: org.bluez.Error.Failed
>>> +
>>> +Signals PropertyChanged(string name, variant value)
>>> +
>>> + This signal indicates a changed value
>> of the given
>>> + property.
>>> +
>>> +Properties boolean Connected [readonly]
>>> +
>>> + Indicates if SAP client is connected to
>> the server.
>>
>> I took the patch from Waldemar Rymarkiewicz (2010-12-02) and
>> did the restructuring in Makefile.am as commented from Gustavo
>> F. Padovan.
>> Are there any other comments?
>
>
> What kind of restructuring did you do? I cannot notice any difference.
> Is this just a rebase ?
>
It is a rebase in the end. The only change is that I put
doc/assigned-numbers.txt at the end of EXTRA_DIST as commented by
Gustavo. Feel free to submit it again with your credentials. I just
wanted to see if this very, very small change prevented your patch from
being pushed. As I am very keen to see a progress on SimAccess.
Best regards,
Harald
^ permalink raw reply
* RE: [PATCH] Sim Access Profile API
From: Waldemar.Rymarkiewicz @ 2011-02-07 13:58 UTC (permalink / raw)
To: linux, linux-bluetooth, marcel; +Cc: padovan, johan.hedberg
In-Reply-To: <4D4FF756.4030001@hschmitt.de>
Hi,
>> What kind of restructuring did you do? I cannot notice any=20
>difference.
>> Is this just a rebase ?
>>=20
>It is a rebase in the end. The only change is that I put=20
>doc/assigned-numbers.txt at the end of EXTRA_DIST as commented=20
>by Gustavo. Feel free to submit it again with your=20
>credentials. I just wanted to see if this very, very small=20
>change prevented your patch from being pushed. As I am very=20
>keen to see a progress on SimAccess.
I see. I guess that's not the blocking point in this case.
@Marcel\Gustavo: Could you find some time to put your comment on this api? =
=20
If it's fine I'll adjust server code to that API.
Thanks,
/Waldek
^ permalink raw reply
* Re: Problems trying to connecf HFP device
From: Franz Glauber @ 2011-02-07 15:27 UTC (permalink / raw)
To: linux-bluetooth
In-Reply-To: <AANLkTim_XfH9jTQLhCVtf4BJd8BJ9pV_2FQzqfOJO6kR@mail.gmail.com>
I've talked this through with Padovan, but had no success on setting
up a new HFP device.
I can pair it, it recognizes the services Audio and Headset. I am also
able to connect the Headset service using D-Feet. When it does,
Pulseaudio is notified and attempt to configure it for use. The
revelant part seems to be this negotiation:
On bluetoothd:
bluetoothd[9596]: audio/unix.c:server_cb() Accepted new client
connection on unix socket (fd=24)
bluetoothd[9596]: audio/unix.c:client_cb() Audio API: BT_REQUEST <-
BT_GET_CAPABILITIES
bluetoothd[9596]: audio/unix.c:unix_ipc_sendmsg() Audio API:
BT_RESPONSE -> BT_GET_CAPABILITIES
bluetoothd[9596]: audio/unix.c:client_cb() Audio API: BT_REQUEST <-
BT_GET_CAPABILITIES
bluetoothd[9596]: audio/unix.c:unix_ipc_sendmsg() Audio API:
BT_RESPONSE -> BT_GET_CAPABILITIES
bluetoothd[9596]: audio/unix.c:client_cb() Audio API: BT_REQUEST <- BT_OPEN
bluetoothd[9596]: audio/unix.c:handle_sco_open() open sco -
object=/org/bluez/9596/hci0/dev_88_88_00_B9_CC_DD source=ANY
destination=ANY lock=readwrite
bluetoothd[9596]: audio/unix.c:unix_ipc_sendmsg() Audio API:
BT_RESPONSE -> BT_OPEN
bluetoothd[9596]: audio/unix.c:client_cb() Audio API: BT_REQUEST <-
BT_SET_CONFIGURATION
bluetoothd[9596]: audio/unix.c:unix_ipc_sendmsg() Audio API:
BT_RESPONSE -> BT_SET_CONFIGURATION
bluetoothd[9596]: audio/unix.c:client_cb() Audio API: BT_REQUEST <-
BT_START_STREAM
bluetoothd[9596]: audio/headset.c:headset_set_state() State changed
/org/bluez/9596/hci0/dev_88_88_00_B9_CC_DD: HEADSET_STATE_CONNECTED ->
HEADSET_STATE_PLAY_IN_PROGRESS
bluetoothd[9596]: audio/headset.c:handle_event() Received AT+CLIP=1
On pulseaudio:
D: module-bluetooth-discover.c: Loading module-bluetooth-device
address="88:88:00:B9:CC:DD"
path="/org/bluez/9596/hci0/dev_88_88_00_B9_CC_DD"
I: card.c: Created 1 "bluez_card.88_88_00_B9_CC_DD"
D: module-bluetooth-device.c: Connected to the bluetooth audio service
D: module-bluetooth-device.c: Sending BT_REQUEST -> BT_GET_CAPABILITIES
D: module-bluetooth-device.c: Trying to receive message from audio service...
D: module-bluetooth-device.c: Received BT_RESPONSE <- BT_GET_CAPABILITIES
D: module-bluetooth-device.c: Payload size is 9 6
D: module-bluetooth-device.c: Sending BT_REQUEST -> BT_GET_CAPABILITIES
D: module-bluetooth-device.c: Trying to receive message from audio service...
D: module-bluetooth-device.c: Received BT_RESPONSE <- BT_GET_CAPABILITIES
D: module-bluetooth-device.c: Payload size is 9 6
D: module-bluetooth-device.c: Got device capabilities
D: module-bluetooth-device.c: Sending BT_REQUEST -> BT_OPEN
D: module-bluetooth-device.c: Trying to receive message from audio service...
D: module-bluetooth-device.c: Received BT_RESPONSE <- BT_OPEN
D: module-bluetooth-device.c: Sending BT_REQUEST -> BT_SET_CONFIGURATION
D: module-bluetooth-device.c: Trying to receive message from audio service...
D: module-bluetooth-device.c: Received BT_RESPONSE <- BT_SET_CONFIGURATION
D: module-bluetooth-device.c: Connection to the device configured
D: module-bluetooth-device.c: Got the stream socket
I: sink.c: Created sink 1 "bluez_sink.88_88_00_B9_CC_DD" with sample
spec s16le 1ch 8000Hz and channel map mono
I: sink.c: bluetooth.protocol = "sco"
I: sink.c: device.intended_roles = "phone"
I: sink.c: device.description = "G688"
I: sink.c: device.string = "88:88:00:B9:CC:DD"
I: sink.c: device.api = "bluez"
I: sink.c: device.class = "sound"
I: sink.c: device.bus = "bluetooth"
I: sink.c: device.form_factor = "headset"
I: sink.c: bluez.path = "/org/bluez/9596/hci0/dev_88_88_00_B9_CC_DD"
I: sink.c: bluez.class = "0x200404"
I: sink.c: bluez.name = "G688"
I: sink.c: device.icon_name = "audio-headset-bluetooth"
I: source.c: Created source 2 "bluez_sink.88_88_00_B9_CC_DD.monitor"
with sample spec s16le 1ch 8000Hz and channel map mono
I: source.c: device.description = "Monitor of G688"
I: source.c: device.class = "monitor"
I: source.c: device.string = "88:88:00:B9:CC:DD"
I: source.c: device.api = "bluez"
I: source.c: device.bus = "bluetooth"
I: source.c: device.form_factor = "headset"
I: source.c: bluez.path = "/org/bluez/9596/hci0/dev_88_88_00_B9_CC_DD"
I: source.c: bluez.class = "0x200404"
I: source.c: bluez.name = "G688"
I: source.c: device.icon_name = "audio-headset-bluetooth"
I: source.c: device.intended_roles = "phone"
I: source.c: Created source 3 "bluez_source.88_88_00_B9_CC_DD" with
sample spec s16le 1ch 8000Hz and channel map mono
I: source.c: bluetooth.protocol = "hsp"
I: source.c: device.intended_roles = "phone"
I: source.c: device.description = "G688"
I: source.c: device.string = "88:88:00:B9:CC:DD"
I: source.c: device.api = "bluez"
I: source.c: device.class = "sound"
I: source.c: device.bus = "bluetooth"
I: source.c: device.form_factor = "headset"
I: source.c: bluez.path = "/org/bluez/9596/hci0/dev_88_88_00_B9_CC_DD"
I: source.c: bluez.class = "0x200404"
I: source.c: bluez.name = "G688"
I: source.c: device.icon_name = "audio-headset-bluetooth"
D: module-bluetooth-device.c: IO Thread starting up
I: core-util.c: Successfully enabled SCHED_RR scheduling for thread,
with priority 4, which is lower than the requested 5.
D: module-bluetooth-device.c: Sending BT_REQUEST -> BT_START_STREAM
D: module-bluetooth-device.c: Trying to receive message from audio service...
After this, pulseaudio keeps waiting, but nothing is sent from the
device/bluez except thta AT+CLIP=1 signal, so it gives up and die.
bluetoothd[9596]: HUP or ERR on socket
bluetoothd[9596]: headset_resume_complete: resume failed
bluetoothd[9596]: audio/unix.c:unix_ipc_error() sending error
Input/output error(5)
bluetoothd[9596]: audio/unix.c:unix_ipc_sendmsg() Audio API: BT_ERROR
-> BT_START_STREAM
on pulseaudio:
D: module-bluetooth-device.c: Received BT_ERROR <- BT_START_STREAM
E: module-bluetooth-device.c: Received error condition: Input/output
error *translated back to english
D: module-bluetooth-device.c: IO thread failed
D: module-suspend-on-idle.c: Sink bluez_sink.88_88_00_B9_CC_DD becomes
idle, timeout in 5 seconds.
D: module-suspend-on-idle.c: Source bluez_source.88_88_00_B9_CC_DD
becomes idle, timeout in 5 seconds.
I: module.c: Loaded "module-bluetooth-device" (index: #18; argument:
"address="88:88:00:B9:CC:DD"
path="/org/bluez/9596/hci0/dev_88_88_00_B9_CC_DD"").
D: module-console-kit.c: dbus: interface=org.bluez.Audio,
path=/org/bluez/9596/hci0/dev_88_88_00_B9_CC_DD,
member=PropertyChanged
I: module-device-restore.c: Storing volume/mute/port for device
sink:bluez_sink.88_88_00_B9_CC_DD.
I: module-device-restore.c: Storing volume/mute/port for device
source:bluez_sink.88_88_00_B9_CC_DD.monitor.
I: module-device-restore.c: Storing volume/mute/port for device
source:bluez_source.88_88_00_B9_CC_DD.
I: module.c: Unloading "module-bluetooth-device" (index: #18).
D: module-rescue-streams.c: No sink inputs to move away.
D: module-rescue-streams.c: No source outputs to move away.
D: module-rescue-streams.c: No source outputs to move away.
D: module-bluetooth-device.c: IO thread shutting down
I: sink.c: Freeing sink 1 "bluez_sink.88_88_00_B9_CC_DD"
I: source.c: Freeing source 2 "bluez_sink.88_88_00_B9_CC_DD.monitor"
I: source.c: Freeing source 3 "bluez_source.88_88_00_B9_CC_DD"
I: card.c: Freed 1 "bluez_card.88_88_00_B9_CC_DD"
I: module.c: Unloaded "module-bluetooth-device" (index: #18).
D: bluetooth-util.c: dbus: interface=(null), path=(null), member=(null)
D: module-console-kit.c: dbus: interface=(null), path=(null), member=(null)
D: bluetooth-util.c: dbus: interface=(null), path=(null), member=(null)
D: module-console-kit.c: dbus: interface=(null), path=(null), member=(null)
I: module-device-restore.c: Synced.
Any ideas?
--
Franz
http://ciudaddelpico.com
^ permalink raw reply
* [PATCH] Fix crash on badly formated AT+VTS command
From: Dmitriy Paliy @ 2011-02-07 17:07 UTC (permalink / raw)
To: linux-bluetooth; +Cc: Dmitriy Paliy
This fixes bluetoothd crash when AT+VTS command is badly formatted,
e.g. as AT+VTS\xfe\xfe[...]=1
---
audio/headset.c | 8 +++++++-
1 files changed, 7 insertions(+), 1 deletions(-)
diff --git a/audio/headset.c b/audio/headset.c
index 0270e2c..da499d8 100644
--- a/audio/headset.c
+++ b/audio/headset.c
@@ -1015,12 +1015,18 @@ int telephony_transmit_dtmf_rsp(void *telephony_device, cme_error_t err)
static int dtmf_tone(struct audio_device *device, const char *buf)
{
+ char *pch;
+
if (strlen(buf) < 8) {
error("Too short string for DTMF tone");
return -EINVAL;
}
- telephony_transmit_dtmf_req(device, buf[7]);
+ pch = strchr(&buf[6],'=');
+ if (pch)
+ telephony_transmit_dtmf_req(device, *(++pch));
+ else
+ return -EINVAL;
return 0;
}
--
1.7.0.4
^ permalink raw reply related
* Re: [PATCH] Fix crash on badly formated AT+VTS command
From: Johan Hedberg @ 2011-02-07 18:30 UTC (permalink / raw)
To: Dmitriy Paliy; +Cc: linux-bluetooth
In-Reply-To: <1297098456-30695-1-git-send-email-dmitriy.paliy@nokia.com>
Hi Dmitriy,
On Mon, Feb 07, 2011, Dmitriy Paliy wrote:
> This fixes bluetoothd crash when AT+VTS command is badly formatted,
> e.g. as AT+VTS\xfe\xfe[...]=1
> ---
> audio/headset.c | 8 +++++++-
> 1 files changed, 7 insertions(+), 1 deletions(-)
>
> diff --git a/audio/headset.c b/audio/headset.c
> index 0270e2c..da499d8 100644
> --- a/audio/headset.c
> +++ b/audio/headset.c
> @@ -1015,12 +1015,18 @@ int telephony_transmit_dtmf_rsp(void *telephony_device, cme_error_t err)
>
> static int dtmf_tone(struct audio_device *device, const char *buf)
> {
> + char *pch;
> +
> if (strlen(buf) < 8) {
> error("Too short string for DTMF tone");
> return -EINVAL;
> }
>
> - telephony_transmit_dtmf_req(device, buf[7]);
> + pch = strchr(&buf[6],'=');
> + if (pch)
> + telephony_transmit_dtmf_req(device, *(++pch));
> + else
> + return -EINVAL;
>
> return 0;
> }
Nack. You need to think about this a bit more. Firstly, you should just
reject a command which isn't properly formatted. What you're now doing
is adding code to handle this particular incorrectly formated command
while leaving the code still open for exploitation with differently
incorrectly formated commands.
The cause of the crash would seem to be that if the value of the tone
character is greater than 127 it creates a string in
telephony_transmit_dtmf_req (telephony-maemo6.c) which isn't valid
UTF-8. DBUS_TYPE_STRING parameters need to be valid UTF-8 and if they
aren't D-Bus will just disconnect you (which in turn will cause
bluetoothd to exit). So it seems bluetoothd shouldn't crash in this
scenario but just exit.
So, the appropriate fix would be to add checks that reject (return ERROR
response) if the character immediately after AT+VGS isn't '=' or if the
character after '=' isn't less than 128 in value (if it's greater than
127 it would result in an invalid UTF-8 string in telephony-maemo6.c).
Johan
^ permalink raw reply
* [PATCH] Update gatt listen mode.
From: Andre Dieb Martins @ 2011-02-07 20:11 UTC (permalink / raw)
To: linux-bluetooth; +Cc: Andre Dieb Martins
Update gatt's listen-mode flag whenever connect_cb() is called again.
---
attrib/client.c | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/attrib/client.c b/attrib/client.c
index 44638d3..ec5fcf2 100644
--- a/attrib/client.c
+++ b/attrib/client.c
@@ -356,6 +356,7 @@ static int l2cap_connect(struct gatt_service *gatt, GError **gerr,
if (gatt->attrib != NULL) {
gatt->attrib = g_attrib_ref(gatt->attrib);
+ gatt->listen = listen;
return 0;
}
--
1.7.1
^ permalink raw reply related
* Re: [PATCH] Fix control channel shutdown in case of errors.
From: Johan Hedberg @ 2011-02-07 23:41 UTC (permalink / raw)
To: jaikumar; +Cc: linux-bluetooth
In-Reply-To: <1296856305-54896-1-git-send-email-jaikumar@google.com>
Hi Jaikumar,
On Fri, Feb 04, 2011, jaikumar@google.com wrote:
> When there are connection errors, like host is down, when
> establishing the control channel connection, the control io
> channel was not being shutdown. This will cause future
> connections to fail.
> ---
> input/device.c | 1 +
> 1 files changed, 1 insertions(+), 0 deletions(-)
Thanks, there were several other issues present (which we already
discussed) so a little bit different (and more comprehensive) patch has
now been pushed upstream.
Johan
^ permalink raw reply
* Re: [BUG] usb problems in .38-rc3+
From: Ed Tomlinson @ 2011-02-08 0:20 UTC (permalink / raw)
To: Oliver Neukum; +Cc: linux-kernel, linux-bluetooth, linux-usb
In-Reply-To: <201102071009.51238.oneukum@suse.de>
On Monday 07 February 2011 04:09:51 Oliver Neukum wrote:
> Am Samstag, 5. Februar 2011, 20:17:57 schrieb Ed Tomlinson:
> > Hi,
> >
> > My bluetooth usb dongle has stopped working in .38-rc3+
> >
> > Bus 002 Device 008: ID 0a12:0001 Cambridge Silicon Radio, Ltd Bluetooth Dongle (HCI mode)
> >
> > and in dmesg
> >
> > [108495.369056] usb 5-1: new full speed USB device using ohci_hcd and address 3
> > [108495.573077] usb 5-1: New USB device found, idVendor=0a12, idProduct=0001
> > [108495.580099] usb 5-1: New USB device strings: Mfr=0, Product=0, SerialNumber=0
> > [108652.971977] usb 5-1: USB disconnect, address 3
> > [108652.972718] btusb_bulk_complete: hci0 urb ffff8800684e99c0 failed to resubmit (19)
> > [108652.973725] btusb_bulk_complete: hci0 urb ffff8800684e9c00 failed to resubmit (19)
> > [108652.974707] btusb_intr_complete: hci0 urb ffff8800684e9840 failed to resubmit (19)
> > [108653.001690] btusb_send_frame: hci0 urb ffff8800bb42a240 submission failed
> > [108657.007541] usb 2-4.7: new full speed USB device using ehci_hcd and address 8
> > [108657.147736] usb 2-4.7: New USB device found, idVendor=0a12, idProduct=0001
> > [108657.154954] usb 2-4.7: New USB device strings: Mfr=0, Product=0, SerialNumber=0
> >
> > Its been working for years here.
> >
> > Any ideas on what to try or additional info to gather?
>
> Please test what happens if you disable runtime power management.
After a pointer from Oliver I booted with usbcore.autosuspend=30000 and verified the device used
the parm via /sys/bus... Still did not work. Bisect or are there some other things to try?
Thanks
Ed
^ permalink raw reply
* Frequent SM test failure at UPF
From: Brian Gix @ 2011-02-08 0:26 UTC (permalink / raw)
To: linux-bluetooth, vinicius.gomes
Testing of Shorter than 16 octet keys.
In smp_cmd_pairing_random() when the STK is generated, it needs to be
truncated to the MIN of conn->preq[4] and conn->pres[4].
This Min value may need to be saved for later as well, because it needs
to also limit the LTK key exchange.
This failure showed up with the PTS tool, and at least one other device
during the days testing. I have mocked up a fix, but have not had a
chance to test it yet.
--
Brian Gix
bgix@codeaurora.org
Employee of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum
^ permalink raw reply
* Re: Frequent SM test failure at UPF
From: Brian Gix @ 2011-02-08 1:22 UTC (permalink / raw)
To: linux-bluetooth, vinicius.gomes
In-Reply-To: <4D508DC2.60003@codeaurora.org>
On 2/7/2011 4:26 PM, Brian Gix wrote:
>
> Testing of Shorter than 16 octet keys.
>
> In smp_cmd_pairing_random() when the STK is generated, it needs to be
> truncated to the MIN of conn->preq[4] and conn->pres[4].
>
> This Min value may need to be saved for later as well, because it needs
> to also limit the LTK key exchange.
>
> This failure showed up with the PTS tool, and at least one other device
> during the days testing. I have mocked up a fix, but have not had a
> chance to test it yet.
>
>
PTS also did not like that we request No Bonding, but request to
exchange keys. I am not sure who is at fault there. At first glance,
exchanging keys insinuates a bonded relationship, so I don't know what
it means to request key exchange but not bond. I think both sides need
to agree to bond (bit 0x01 in offset 3 (4th octet) of the req and res)
to remember the exchanged keys, but exchanging keys should still be OK
for the duration of that session at least. They would then be discarded
when the connection ended.
It also may not make sense to request Bonding, but not have keys to
exchange, because I am not sure if you are really bonded if you have no
keys exchanged with the remote device. You could always just remember
the remote device's BD Addr, I suppose and choose to accept or reject
no-security connections based on that.
I am sorry, the above is mostly just me thinking out loud. I don't know
for sure if any of that is actually correct.
--
Brian Gix
bgix@codeaurora.org
Employee of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum
^ 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