* [PATCH] input: Implement idle timeout for fakehid.
From: Jeff Hansen @ 2012-08-27 14:19 UTC (permalink / raw)
To: linux-bluetooth; +Cc: Jeff Hansen
The batteries on my BD remote would die in a few days without this patch.
Now they've been going for weeks (hopefully months).
---
profiles/input/device.c | 6 ++++++
profiles/input/device.h | 4 ++++
profiles/input/fakehid.c | 18 ++++++++++++++++++
3 files changed, 28 insertions(+), 0 deletions(-)
diff --git a/profiles/input/device.c b/profiles/input/device.c
index 48d397a..31c970d 100644
--- a/profiles/input/device.c
+++ b/profiles/input/device.c
@@ -638,6 +638,7 @@ static int hidp_add_connection(const struct input_device *idev,
fake->disconnect = fake_hid_disconnect;
fake->priv = fake_hid;
fake->idev = idev;
+ fake->timeout = iconn->timeout * 1000;
fake = fake_hid_connadd(fake, iconn->intr_io, fake_hid);
if (fake == NULL)
err = -ENOMEM;
@@ -1307,3 +1308,8 @@ int input_device_close_channels(const bdaddr_t *src, const bdaddr_t *dst)
return 0;
}
+
+void input_device_request_disconnect(const struct input_device *idev)
+{
+ device_request_disconnect(idev->device, NULL);
+}
diff --git a/profiles/input/device.h b/profiles/input/device.h
index 509a353..1b490b4 100644
--- a/profiles/input/device.h
+++ b/profiles/input/device.h
@@ -37,6 +37,8 @@ struct fake_input {
int (*disconnect) (struct input_conn *iconn);
void *priv;
const struct input_device *idev;
+ guint idle_timeout;
+ uint32_t timeout;
};
int fake_input_register(DBusConnection *conn, struct btd_device *device,
@@ -49,3 +51,5 @@ int input_device_unregister(const char *path, const char *uuid);
int input_device_set_channel(const bdaddr_t *src, const bdaddr_t *dst, int psm,
GIOChannel *io);
int input_device_close_channels(const bdaddr_t *src, const bdaddr_t *dst);
+
+void input_device_request_disconnect(const struct input_device *idev);
diff --git a/profiles/input/fakehid.c b/profiles/input/fakehid.c
index 3be1489..a92622f 100644
--- a/profiles/input/fakehid.c
+++ b/profiles/input/fakehid.c
@@ -199,6 +199,13 @@ error:
return -1;
}
+static gboolean ps3remote_idle(gpointer data)
+{
+ struct fake_input *fake = data;
+ input_device_request_disconnect(fake->idev);
+ return FALSE;
+}
+
static gboolean ps3remote_event(GIOChannel *chan, GIOCondition cond,
gpointer data)
{
@@ -209,6 +216,13 @@ static gboolean ps3remote_event(GIOChannel *chan, GIOCondition cond,
char buff[50];
int fd;
+ if (fake->idle_timeout) {
+ g_source_remove(fake->idle_timeout);
+ fake->idle_timeout = 0;
+ }
+ if (fake->timeout)
+ fake->idle_timeout = g_timeout_add(fake->timeout, ps3remote_idle, fake);
+
if (cond & G_IO_NVAL)
return FALSE;
@@ -328,6 +342,10 @@ static gboolean fake_hid_common_connect(struct fake_input *fake, GError **err)
static int fake_hid_common_disconnect(struct fake_input *fake)
{
+ if (fake->idle_timeout) {
+ g_source_remove(fake->idle_timeout);
+ fake->idle_timeout = 0;
+ }
return 0;
}
--
1.7.8.6
^ permalink raw reply related
* Re: [PATCH] Bluetooth: Add support for Apple vendor-specific devices
From: Gustavo Padovan @ 2012-08-27 13:38 UTC (permalink / raw)
To: Henrik Rydberg; +Cc: linux-bluetooth, linux-kernel
In-Reply-To: <1345915686-3915-1-git-send-email-rydberg@euromail.se>
Hi Henrik,
* Henrik Rydberg <rydberg@euromail.se> [2012-08-25 19:28:06 +0200]:
> As pointed out by Gustavo and Marcel, all Apple-specific Broadcom
> devices seen so far have the same interface class, subclass and
> protocol numbers. This patch adds an entry which matches all of them,
> using the new USB_VENDOR_AND_INTERFACE_INFO() macro.
>
> In particular, this patch adds support for the MacBook Pro Retina
> (05ac:8286), which is not in the present list.
>
> Signed-off-by: Henrik Rydberg <rydberg@euromail.se>
> ---
> Hi Gustavo,
>
> here is a patch for the Apple devices, utilizing commit d81a5d19, for
> 3.6. Tested on the MacBookPro10,1 (Retina). If you want, I can
> follow-up with a patch for 3.7 which removes the specific entries. I
> have verified the lsusb output of all of them, except MacMini5,1.
>
> Thanks,
> Henrik
>
> drivers/bluetooth/btusb.c | 3 +++
> 1 file changed, 3 insertions(+)
Patch has been applied to the bluetooth tree. Thanks.
Gustavo
^ permalink raw reply
* [PATCH 3/3] rctest: add option to save received data to file
From: Gustavo Padovan @ 2012-08-27 13:14 UTC (permalink / raw)
To: linux-bluetooth; +Cc: Gustavo Padovan
In-Reply-To: <1346073291-7001-1-git-send-email-gustavo@padovan.org>
From: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
works only for automated test option for now
---
test/rctest.c | 55 ++++++++++++++++++++++++++++++++++++++++++++++++++++---
1 file changed, 52 insertions(+), 3 deletions(-)
diff --git a/test/rctest.c b/test/rctest.c
index 4aca99a..280da10 100644
--- a/test/rctest.c
+++ b/test/rctest.c
@@ -78,6 +78,8 @@ static uint16_t uuid = 0x0000;
static uint8_t channel = 10;
static char *filename = NULL;
+static char *savefile = NULL;
+static int save_fd = 0;
static int master = 0;
static int auth = 0;
@@ -448,6 +450,23 @@ static void dump_mode(int sk)
syslog(LOG_INFO, "Received %d bytes", len);
}
+static void save_mode(int sk)
+{
+ int len, ret;
+ char *b;
+
+ b = malloc(data_size);
+ if (!b)
+ syslog(LOG_ERR, "Failed to open file to save recv data");
+
+ syslog(LOG_INFO, "Receiving ...");
+ while ((len = read(sk, b, data_size)) > 0) {
+ ret = write(save_fd, b, len);
+ if (!ret)
+ return;
+ }
+}
+
static void recv_mode(int sk)
{
struct timeval tv_beg, tv_end, tv_diff;
@@ -603,7 +622,20 @@ static void automated_send_recv()
char device[18];
if (fork()) {
- do_listen(recv_mode);
+ if (!savefile) {
+ do_listen(recv_mode);
+ return;
+ }
+
+ save_fd = open(savefile, O_CREAT | O_WRONLY,
+ S_IRUSR | S_IWUSR);
+ if (!save_fd)
+ syslog(LOG_ERR, "Failed to open file to save "
+ "recv data");
+
+ do_listen(save_mode);
+
+ close(save_fd);
} else {
ba2str(&bdaddr, device);
@@ -614,6 +646,15 @@ static void automated_send_recv()
}
}
+static void sig_child_exit(int code)
+{
+ syslog(LOG_INFO, "Exit");
+ exit(0);
+
+ if (save_fd)
+ close(save_fd);
+}
+
static void usage(void)
{
printf("rctest - RFCOMM testing\n"
@@ -635,6 +676,7 @@ static void usage(void)
"\t[-L seconds] enabled SO_LINGER option\n"
"\t[-W seconds] enable deferred setup\n"
"\t[-B filename] use data packets from file\n"
+ "\t[-O filename] save received data to file\n"
"\t[-N num] number of frames to send\n"
"\t[-C num] send num frames before delay (default = 1)\n"
"\t[-D milliseconds] delay after sending num frames (default = 0)\n"
@@ -654,7 +696,7 @@ int main(int argc, char *argv[])
bacpy(&bdaddr, BDADDR_ANY);
bacpy(&auto_bdaddr, BDADDR_ANY);
- while ((opt=getopt(argc,argv,"rdscuwmna:b:i:P:U:B:N:MAESL:W:C:D:Y:T")) != EOF) {
+ while ((opt=getopt(argc,argv,"rdscuwmna:b:i:P:U:B:O:N:MAESL:W:C:D:Y:T")) != EOF) {
switch (opt) {
case 'r':
mode = RECV;
@@ -754,6 +796,10 @@ int main(int argc, char *argv[])
filename = strdup(optarg);
break;
+ case 'O':
+ savefile = strdup(optarg);
+ break;
+
case 'N':
num_frames = atoi(optarg);
break;
@@ -791,7 +837,10 @@ int main(int argc, char *argv[])
}
memset(&sa, 0, sizeof(sa));
- sa.sa_handler = SIG_IGN;
+ if (mode == AUTO)
+ sa.sa_handler = sig_child_exit;
+ else
+ sa.sa_handler = SIG_IGN;
sa.sa_flags = SA_NOCLDSTOP;
sigaction(SIGCHLD, &sa, NULL);
--
1.7.11.2
^ permalink raw reply related
* [PATCH 2/3] rctest: add automated test
From: Gustavo Padovan @ 2012-08-27 13:14 UTC (permalink / raw)
To: linux-bluetooth; +Cc: Gustavo Padovan
In-Reply-To: <1346073291-7001-1-git-send-email-gustavo@padovan.org>
From: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
adds -a option to enable automated tests. We use the -i option to define
the receiving side and the -a define the sending side:
./rctest -i hci0 -a hci1
---
test/rctest.c | 46 ++++++++++++++++++++++++++++++++++++++++++----
1 file changed, 42 insertions(+), 4 deletions(-)
diff --git a/test/rctest.c b/test/rctest.c
index f82d2cc..4aca99a 100644
--- a/test/rctest.c
+++ b/test/rctest.c
@@ -55,7 +55,8 @@ enum {
DUMP,
CONNECT,
CRECV,
- LSEND
+ LSEND,
+ AUTO
};
static unsigned char *buf;
@@ -72,6 +73,7 @@ static unsigned long delay = 0;
/* Default addr and channel */
static bdaddr_t bdaddr;
+static bdaddr_t auto_bdaddr;
static uint16_t uuid = 0x0000;
static uint8_t channel = 10;
@@ -162,7 +164,11 @@ static int do_connect(const char *svr)
/* Bind to local address */
memset(&addr, 0, sizeof(addr));
addr.rc_family = AF_BLUETOOTH;
- bacpy(&addr.rc_bdaddr, &bdaddr);
+
+ if (bacmp(&auto_bdaddr, BDADDR_ANY))
+ bacpy(&addr.rc_bdaddr, &auto_bdaddr);
+ else
+ bacpy(&addr.rc_bdaddr, &bdaddr);
if (bind(sk, (struct sockaddr *) &addr, sizeof(addr)) < 0) {
syslog(LOG_ERR, "Can't bind socket: %s (%d)",
@@ -591,6 +597,23 @@ static void multi_connect_mode(int argc, char *argv[])
}
}
+static void automated_send_recv()
+{
+ int sk;
+ char device[18];
+
+ if (fork()) {
+ do_listen(recv_mode);
+ } else {
+ ba2str(&bdaddr, device);
+
+ sk = do_connect(device);
+ if (sk < 0)
+ exit(1);
+ send_mode(sk);
+ }
+}
+
static void usage(void)
{
printf("rctest - RFCOMM testing\n"
@@ -604,7 +627,8 @@ static void usage(void)
"\t-u connect and receive\n"
"\t-n connect and be silent\n"
"\t-c connect, disconnect, connect, ...\n"
- "\t-m multiple connects\n");
+ "\t-m multiple connects\n"
+ "\t-a automated test (receive hcix as parameter)\n");
printf("Options:\n"
"\t[-b bytes] [-i device] [-P channel] [-U uuid]\n"
@@ -628,8 +652,9 @@ int main(int argc, char *argv[])
int opt, sk, mode = RECV, need_addr = 0;
bacpy(&bdaddr, BDADDR_ANY);
+ bacpy(&auto_bdaddr, BDADDR_ANY);
- while ((opt=getopt(argc,argv,"rdscuwmnb:i:P:U:B:N:MAESL:W:C:D:Y:T")) != EOF) {
+ while ((opt=getopt(argc,argv,"rdscuwmna:b:i:P:U:B:N:MAESL:W:C:D:Y:T")) != EOF) {
switch (opt) {
case 'r':
mode = RECV;
@@ -668,6 +693,15 @@ int main(int argc, char *argv[])
need_addr = 1;
break;
+ case 'a':
+ mode = AUTO;
+
+ if (!strncasecmp(optarg, "hci", 3))
+ hci_devba(atoi(optarg + 3), &auto_bdaddr);
+ else
+ str2ba(optarg, &auto_bdaddr);
+ break;
+
case 'b':
data_size = atoi(optarg);
break;
@@ -804,6 +838,10 @@ int main(int argc, char *argv[])
exit(1);
dump_mode(sk);
break;
+
+ case AUTO:
+ automated_send_recv();
+ break;
}
syslog(LOG_INFO, "Exit");
--
1.7.11.2
^ permalink raw reply related
* [PATCH 1/3] rctest: fix typo
From: Gustavo Padovan @ 2012-08-27 13:14 UTC (permalink / raw)
To: linux-bluetooth; +Cc: Gustavo Padovan
From: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
recevied -> received
---
test/rctest.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/test/rctest.c b/test/rctest.c
index 4d7c90a..f82d2cc 100644
--- a/test/rctest.c
+++ b/test/rctest.c
@@ -439,7 +439,7 @@ static void dump_mode(int sk)
syslog(LOG_INFO, "Receiving ...");
while ((len = read(sk, buf, data_size)) > 0)
- syslog(LOG_INFO, "Recevied %d bytes", len);
+ syslog(LOG_INFO, "Received %d bytes", len);
}
static void recv_mode(int sk)
--
1.7.11.2
^ permalink raw reply related
* Re: kernel crashes coming from btusb
From: Oliver Neukum @ 2012-08-27 13:06 UTC (permalink / raw)
To: Sonny Rao; +Cc: linux-bluetooth, marcel, vpalatin, keybuk
In-Reply-To: <CAPz6YkVEwWzosE5Tda+SvtmV1=0Q9g5uyW+RZsOVgOxT79c15Q@mail.gmail.com>
On Monday 27 August 2012 03:30:55 Sonny Rao wrote:
> Hi, I've been investigating an issue where we were seeing random
> kernel crashes soon after resume and after using the great debugging
> facilities in SLUB I started getting output which pointed to "use
> after free" from the btusb driver.
Which kernel version?
Regards
Oliver
^ permalink raw reply
* Re: [PATCH v3] storage: Fix Discoverable mode not updated on storage.
From: Luiz Augusto von Dentz @ 2012-08-27 12:59 UTC (permalink / raw)
To: chanyeol.park; +Cc: linux-bluetooth
In-Reply-To: <1346068966-8077-1-git-send-email-chanyeol.park@samsung.com>
Hi Chanyeol,
On Mon, Aug 27, 2012 at 3:02 PM, <chanyeol.park@samsung.com> wrote:
> From: Chan-yeol Park <chanyeol.park@samsung.com>
>
> This patch fixes the problem that storage's Discoverable value is
> not updated like hciconfig when BlueZ receives the MGMT adapter mode
> changed event after DiscoverableTimeout has been expired.
>
> This problem occurs because no longer bluetoothd does not take on
> requesting part to disable discoverable when the timer expires.
> ---
> src/adapter.c | 15 +++++----------
> 1 file changed, 5 insertions(+), 10 deletions(-)
>
> diff --git a/src/adapter.c b/src/adapter.c
> index 69ec821..7d06633 100644
> --- a/src/adapter.c
> +++ b/src/adapter.c
> @@ -2249,6 +2249,11 @@ static void set_mode_complete(struct btd_adapter *adapter)
> adapter->mode_sessions = NULL;
> }
>
> + modestr = mode2str(adapter->mode);
> + write_device_mode(&adapter->bdaddr, modestr);
> +
> + DBG("%s", modestr);
> +
> if (adapter->pending_mode == NULL)
> return;
>
> @@ -2273,16 +2278,6 @@ static void set_mode_complete(struct btd_adapter *adapter)
> g_dbus_send_message(connection, reply);
> }
>
> - modestr = mode2str(adapter->mode);
> -
> - DBG("%s", modestr);
> -
> - /* restore if the mode doesn't matches the pending */
> - if (err != 0) {
> - write_device_mode(&adapter->bdaddr, modestr);
> - error("unable to set mode: %s", mode2str(pending->mode));
> - }
> -
> session_unref(pending);
> }
>
> --
> 1.7.9.5
Ive changed a little bit the commit message to be more clear about
what we are fixing, but it is now pushed upstream.
--
Luiz Augusto von Dentz
^ permalink raw reply
* [PATCH v3] storage: Fix Discoverable mode not updated on storage.
From: chanyeol.park @ 2012-08-27 12:02 UTC (permalink / raw)
To: linux-bluetooth
In-Reply-To: <1346059192-6114-1-git-send-email-chanyeol.park@samsung.com>
From: Chan-yeol Park <chanyeol.park@samsung.com>
This patch fixes the problem that storage's Discoverable value is
not updated like hciconfig when BlueZ receives the MGMT adapter mode
changed event after DiscoverableTimeout has been expired.
This problem occurs because no longer bluetoothd does not take on
requesting part to disable discoverable when the timer expires.
---
src/adapter.c | 15 +++++----------
1 file changed, 5 insertions(+), 10 deletions(-)
diff --git a/src/adapter.c b/src/adapter.c
index 69ec821..7d06633 100644
--- a/src/adapter.c
+++ b/src/adapter.c
@@ -2249,6 +2249,11 @@ static void set_mode_complete(struct btd_adapter *adapter)
adapter->mode_sessions = NULL;
}
+ modestr = mode2str(adapter->mode);
+ write_device_mode(&adapter->bdaddr, modestr);
+
+ DBG("%s", modestr);
+
if (adapter->pending_mode == NULL)
return;
@@ -2273,16 +2278,6 @@ static void set_mode_complete(struct btd_adapter *adapter)
g_dbus_send_message(connection, reply);
}
- modestr = mode2str(adapter->mode);
-
- DBG("%s", modestr);
-
- /* restore if the mode doesn't matches the pending */
- if (err != 0) {
- write_device_mode(&adapter->bdaddr, modestr);
- error("unable to set mode: %s", mode2str(pending->mode));
- }
-
session_unref(pending);
}
--
1.7.9.5
^ permalink raw reply related
* kernel crashes coming from btusb
From: Sonny Rao @ 2012-08-27 10:30 UTC (permalink / raw)
To: linux-bluetooth; +Cc: marcel, vpalatin, keybuk
Hi, I've been investigating an issue where we were seeing random
kernel crashes soon after resume and after using the great debugging
facilities in SLUB I started getting output which pointed to "use
after free" from the btusb driver.
Here's an example output:
[ 5805.135620] ===============================================================
[ 5805.135627] BUG kmalloc-16 (Not tainted): Poison overwritten
[ 5805.135631] -------------------------------------------------------------
[ 5805.135633]
[ 5805.135638] INFO: 0xf4f0ae40-0xf4f0ae4e. First byte 0xe instead of 0x6b
[ 5805.135647] INFO: Allocated in 0xf8dab31c age=130 cpu=0 pid=27759
[ 5805.135657] __slab_alloc.constprop.71+0x27c/0x2b7
[ 5805.135663] __kmalloc+0xc4/0x12c
[ 5805.135666] 0xf8dab31c
[ 5805.135668] 0xf8dac6d4
[ 5805.135677] hci_dev_open+0xcc/0x2a6 [bluetooth]
[ 5805.135685] hci_dev_open+0x25c/0x2a6 [bluetooth]
[ 5805.135690] process_one_work+0x142/0x227
[ 5805.135694] worker_thread+0xfc/0x1cc
[ 5805.135698] kthread+0x6c/0x71
[ 5805.135705] kernel_thread_helper+0x6/0x10
[ 5805.135712] INFO: Freed in urb_destroy+0x19/0x23 age=60 cpu=0 pid=1434
[ 5805.135718] __slab_free+0x33/0x1af
[ 5805.135722] kfree+0xb5/0xbe
[ 5805.135725] urb_destroy+0x19/0x23
[ 5805.135729] usb_free_urb+0x1c/0x1e
[ 5805.135734] usb_kill_anchored_urbs+0x34/0x4b
[ 5805.135737] 0xf8dac5dc
[ 5805.135744] hci_alloc_dev+0x29d/0x491 [bluetooth]
[ 5805.135751] hci_dev_close+0x43/0x56 [bluetooth]
[ 5805.135759] mgmt_device_unblocked+0x6ce/0xddd [bluetooth]
[ 5805.135765] sock_ioctl+0x1ca/0x1ec
[ 5805.135770] do_vfs_ioctl+0x455/0x489
[ 5805.135775] sys_ioctl+0x46/0x67
[ 5805.135780] sysenter_do_call+0x12/0x26
[ 5805.135785] INFO: Slab 0xf6e9a140 objects=21 used=21 fp=0x (null)
flags=0x6800080
[ 5805.135790] INFO: Object 0xf4f0ae40 @offset=3648 fp=0xf4f0a180
[ 5805.135792]
[ 5805.135796] Bytes b4 f4f0ae30: 14 00 00 00 9e 1c 54 00 5a 5a 5a 5a
5a 5a 5a 5a ......T.ZZZZZZZZ
[ 5805.135801] Object f4f0ae40: 0e 0e 01 04 10 00 01 01 00 00 00 00
00 00 00 00 ................
[ 5805.135806] Redzone f4f0ae50: bb bb bb bb
....
[ 5805.135810] Padding f4f0aef8: 5a 5a 5a 5a 5a 5a 5a 5a
ZZZZZZZZ
[ 5805.135816] Pid: 16386, comm: grep Not tainted 3.4.0 #1
[ 5805.135819] Call Trace:
from my tracing it looks like the object in kmalloc-16 was the
transfer buffer from the intr urb as far as I can tell there isn't an
actual use after free issue with the code, but rather it looks like
sometimes hardware is still dma'ing over that buffer after the kernel
has freed it which is what causes this issue.
I'm not very familiar with USB, but I tried to trace when that URB and
it's transfer buffer get unmapped from dma and I wasn't able to see
where that happens. I was looking for a call to unmap_urb_for_dma()
in drivers/usb/core/hcd.c.
Is it possible btusb isn't properly disabling the URB somehow before
close and the USB host controller continues to process interrupts for
that URB after it has been freed?
Unfortunately this can be difficult to reproduce because the
suspend/resume crash is only happening after a few hundred suspend
resume cycles on average. However, I'm also able to get a large number
of kernel crashes (not necessarily the use after free poison overwritten
detection) which might be related to whether or not things are being
properly shut down, if I do this:
while true ; rmmod btusb ; modprobe btusb; done
while bluetoothd is active in the background.
That's so far the best way I've found to see issues here,
Thanks for any assistance!
Sonny
^ permalink raw reply
* [PATCH v2] Fix Discoverable mode is not updated on storage.
From: chanyeol.park @ 2012-08-27 9:19 UTC (permalink / raw)
To: linux-bluetooth
In-Reply-To: <50321EA8.5000504@samsung.com>
From: Chan-yeol Park <chanyeol.park@samsung.com>
This patch fixes the problem that storage's Discoverable value is
not updated like hciconfig when BlueZ receives the MGMT adapter mode
changed event after DiscoverableTimeout has been expired.
---
src/adapter.c | 9 +++++----
1 file changed, 5 insertions(+), 4 deletions(-)
diff --git a/src/adapter.c b/src/adapter.c
index 69ec821..673cee8 100644
--- a/src/adapter.c
+++ b/src/adapter.c
@@ -2249,6 +2249,11 @@ static void set_mode_complete(struct btd_adapter *adapter)
adapter->mode_sessions = NULL;
}
+ modestr = mode2str(adapter->mode);
+ write_device_mode(&adapter->bdaddr, modestr);
+
+ DBG("%s", modestr);
+
if (adapter->pending_mode == NULL)
return;
@@ -2273,10 +2278,6 @@ static void set_mode_complete(struct btd_adapter *adapter)
g_dbus_send_message(connection, reply);
}
- modestr = mode2str(adapter->mode);
-
- DBG("%s", modestr);
-
/* restore if the mode doesn't matches the pending */
if (err != 0) {
write_device_mode(&adapter->bdaddr, modestr);
--
1.7.9.5
^ permalink raw reply related
* Re: [PATCH obexd v0] client-doc: Guarantee prefix in transfer paths
From: Luiz Augusto von Dentz @ 2012-08-27 7:00 UTC (permalink / raw)
To: Mikel Astiz; +Cc: linux-bluetooth, Mikel Astiz
In-Reply-To: <1345533815-5611-1-git-send-email-mikel.astiz.oss@gmail.com>
Hi Mikel,
On Tue, Aug 21, 2012 at 10:23 AM, Mikel Astiz <mikel.astiz.oss@gmail.com> wrote:
> From: Mikel Astiz <mikel.astiz@bmw-carit.de>
>
> The client D-Bus documentation should mention that all transfer paths
> contain a prefix consisting of the path of the session they belong to.
>
> This can be conveniently used by clients to install D-Bus signal matches
> that concentrate on the relevant signals.
> ---
> doc/client-api.txt | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/doc/client-api.txt b/doc/client-api.txt
> index 839a78c..7ca65cc 100644
> --- a/doc/client-api.txt
> +++ b/doc/client-api.txt
> @@ -466,7 +466,7 @@ Transfer hierarchy
>
> Service org.bluez.obex.client
> Interface org.bluez.obex.Transfer
> -Object path [variable prefix]/{transfer0,transfer1,...}
> +Object path [variable prefix]/{session0,session1,...}/{transfer0,...}
>
> Methods dict GetProperties()
>
> --
> 1.7.7.6
I went ahead and applied this patch.
--
Luiz Augusto von Dentz
^ permalink raw reply
* Re: [PATCH] Bluetooth: Add support for Apple vendor-specific devices
From: Marcel Holtmann @ 2012-08-26 17:08 UTC (permalink / raw)
To: Henrik Rydberg; +Cc: Gustavo Padovan, linux-bluetooth, linux-kernel
In-Reply-To: <1345915686-3915-1-git-send-email-rydberg@euromail.se>
Hi Henrik,
> As pointed out by Gustavo and Marcel, all Apple-specific Broadcom
> devices seen so far have the same interface class, subclass and
> protocol numbers. This patch adds an entry which matches all of them,
> using the new USB_VENDOR_AND_INTERFACE_INFO() macro.
>
> In particular, this patch adds support for the MacBook Pro Retina
> (05ac:8286), which is not in the present list.
>
> Signed-off-by: Henrik Rydberg <rydberg@euromail.se>
> ---
> Hi Gustavo,
>
> here is a patch for the Apple devices, utilizing commit d81a5d19, for
> 3.6. Tested on the MacBookPro10,1 (Retina). If you want, I can
> follow-up with a patch for 3.7 which removes the specific entries. I
> have verified the lsusb output of all of them, except MacMini5,1.
>
> Thanks,
> Henrik
>
> drivers/bluetooth/btusb.c | 3 +++
> 1 file changed, 3 insertions(+)
Acked-by: Marcel Holtmann <marcel@holtmann.org>
Regards
Marcel
^ permalink raw reply
* Re: [PATCH BlueZ] Fix trivial coding style issues on pointer declarations and casting
From: Johan Hedberg @ 2012-08-26 12:20 UTC (permalink / raw)
To: Anderson Lizardo; +Cc: linux-bluetooth
In-Reply-To: <1345564164-15930-1-git-send-email-anderson.lizardo@openbossa.org>
Hi Lizardo,
On Tue, Aug 21, 2012, Anderson Lizardo wrote:
> Avoid using C++ style pointer declarations like "char* ptr", as most
> BlueZ code uses "char *ptr".
> ---
>
> This is a very trivial patch, but changes are so small that it was worthy to
> fix.
>
> I avoided touching tools/ubcsp.c because it has even more coding style issues.
>
>
> audio/gstavdtpsink.h | 2 +-
> audio/gstsbcutil.h | 8 ++++----
> lib/sdp.c | 4 ++--
> profiles/input/sixpair.c | 6 +++---
> test/l2test.c | 4 ++--
> tools/hciattach.h | 2 +-
> tools/hciattach_ti.c | 22 +++++++++++++---------
> tools/ppporc.c | 2 +-
> tools/rfcomm.c | 4 ++--
> 9 files changed, 29 insertions(+), 25 deletions(-)
Applied. Thanks.
Johan
^ permalink raw reply
* Re: [PATCH BlueZ v0] Add Nordic Semiconductor copyright
From: Johan Hedberg @ 2012-08-26 7:36 UTC (permalink / raw)
To: Claudio Takahasi; +Cc: linux-bluetooth
In-Reply-To: <1345485231-28681-1-git-send-email-claudio.takahasi@openbossa.org>
Hi Claudio,
On Mon, Aug 20, 2012, Claudio Takahasi wrote:
> ---
> profiles/input/hog_device.c | 1 +
> profiles/input/hog_device.h | 1 +
> profiles/input/hog_manager.c | 1 +
> 3 files changed, 3 insertions(+), 0 deletions(-)
Applied (with an added "input:" prefix). Thanks.
Johan
^ permalink raw reply
* Re: [PATCH BlueZ] core: Fix memory leak
From: Johan Hedberg @ 2012-08-26 7:30 UTC (permalink / raw)
To: Vinicius Costa Gomes; +Cc: linux-bluetooth
In-Reply-To: <1345852298-9204-1-git-send-email-vinicius.gomes@openbossa.org>
Hi Vinicius,
On Fri, Aug 24, 2012, Vinicius Costa Gomes wrote:
> When ignoring a LE device that is not in a discoverable state 'alias'
> is leaking.
> ---
> src/adapter.c | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
Applied. Thanks.
Johan
^ permalink raw reply
* Re: [PATCH BlueZ] input: Fix signedness issue on POSIX error code usage
From: Johan Hedberg @ 2012-08-26 7:29 UTC (permalink / raw)
To: Anderson Lizardo; +Cc: linux-bluetooth
In-Reply-To: <1345842229-11935-1-git-send-email-anderson.lizardo@openbossa.org>
Hi Lizardo,
On Fri, Aug 24, 2012, Anderson Lizardo wrote:
> By convention, error variables containing POSIX error code (usually
> called "err") are negative. This commit fixes a couple of places where
> positive values are expected.
> ---
> profiles/input/hog_device.c | 2 +-
> profiles/input/server.c | 2 +-
> 2 files changed, 2 insertions(+), 2 deletions(-)
Applied. Thanks.
Johan
^ permalink raw reply
* Re: [PATCH] Bluetooth: Power the device up after a rfkill unblock
From: Johan Hedberg @ 2012-08-26 7:28 UTC (permalink / raw)
To: Vinicius Costa Gomes; +Cc: linux-bluetooth
In-Reply-To: <1345838290-26796-1-git-send-email-vinicius.gomes@openbossa.org>
Hi Vinicius,
On Fri, Aug 24, 2012, Vinicius Costa Gomes wrote:
> With the HCI_SETUP patches, this is all that is needed to make the
> case when a adapter is added with Bluetooth blocked in rfkill to work.
>
> When rfkill is unblocked, the device will be powered on if the device
> is in HCI_SETUP state, meaning that it was never properly initialized.
> If the device is not used by userspace, the HCI_AUTO_OFF flag will
> take care of powering it off.
>
> Signed-off-by: Vinicius Costa Gomes <vinicius.gomes@openbossa.org>
> ---
> net/bluetooth/hci_core.c | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/net/bluetooth/hci_core.c b/net/bluetooth/hci_core.c
> index fa974a1..ef69d8b 100644
> --- a/net/bluetooth/hci_core.c
> +++ b/net/bluetooth/hci_core.c
> @@ -1061,8 +1061,10 @@ static int hci_rfkill_set_block(void *data, bool blocked)
>
> BT_DBG("%p name %s blocked %d", hdev, hdev->name, blocked);
>
> - if (!blocked)
> + if (!blocked && test_bit(HCI_SETUP, &hdev->dev_flags)) {
> + schedule_work(&hdev->power_on);
> return 0;
> + }
>
> hci_dev_do_close(hdev);
This still isn't right. Now you'd be calling hci_dev_do_close() when
unblocking a device that doesn't have HCI_SETUP set. The test_bit needs
to be inside the if-branch. Btw, this all implies that you're not
properly testing your patches. Please always do that.
Johan
^ permalink raw reply
* Re: [PATCH v4 01/10] Battery: Add Battery Service Gatt Client
From: Chen Ganir @ 2012-08-26 7:04 UTC (permalink / raw)
To: Luiz Augusto von Dentz; +Cc: linux-bluetooth
In-Reply-To: <CABBYNZ+bn__fjNMSwix3J7ntRyTahEQca+z9EeWg2PPEwt3S1A@mail.gmail.com>
Luiz,
On 08/20/2012 04:03 PM, Luiz Augusto von Dentz wrote:
> Hi Chen, Johan,
>
> On Thu, Aug 16, 2012 at 10:24 PM, Johan Hedberg <johan.hedberg@gmail.com> wrote:
>> Hi Chen,
>>
>> On Thu, Aug 16, 2012, Chen Ganir wrote:
>>>>> However, i fail to understand why the object manager prevents this
>>>> >from getting accepted - do you have a time estimation when the
>>>>> object manager should be active or available ?
>>>>
>>>> By the time of our next release (as per the content under the BlueZ 5
>>>> section in our TODO file).
>>>
>>> Is there anywhere some documentation or instructions how to adapt
>>> the API for the new object manager ? Is it backward compatible to
>>> what we have today ? Do we really hold back DBUS additions until we
>>> change the DBUS API ?
>>
>> As an unrelated thing (but since I saw it in your commit messages too):
>> please spell D-Bus as D-Bus, not DBUS, DBus, or anything else in natural
>> written language. This keeps it consistent with the rest of our
>> documentation as well as how the D-Bus project itself spells the name.
>>
>> Regarding the Object Manager interface the implementation details you'd
>> get from Lucas and Luiz who are working on it whereas the API spec is
>> available here:
>>
>> http://dbus.freedesktop.org/doc/dbus-specification.html#standard-interfaces-objectmanager
>
> With object manager we have to keep 2 things in mind while designing
> new interfaces:
>
> 1. In case of returning new objects, as in CreateDevice, always
> include the interfaces and properties e.g. D-Bus signature oa{sa{sv}}
> (we will probably have a gdbus helper to do that) which is the
> equivalent to InterfacesAdded signal. This avoid having to call
> GetManagedObjects.
> 2. No need to keep a list of objects or emit signals when one is
> created/destroyed, gdbus will take care of this automatically.
>
> Now if this is really relevant here Im not sure.
>
Is there any current implementation of this object manager in the bluez
tree ? Is it already implemented ?
>>>>> I prefer this way of putting the batteries below the device, since it
>>>>> is obvious which battery belongs to each device.
>>>>
>>>> I fully agree with this. It's not what I had an issue with. However, if
>>>> we really want to make this clear you could additionally have a "Device"
>>>> property for each battery object pointing back to the parent object.
>>> I can do that, if it helps. Although it is not necessary, since the
>>> object path for a battery already contains the device objec path in
>>> it :
>>> [variable prefix]/{hci0,..}/dev_XX_XX_XX_XX_XX_XX/BATT-NN-DDDD
>>> Adding a device object path as a property will be redundant.
>>
>> Even though we do have such a hierarchical construction of the paths I
>> don't think we should encourage this kind of magic tricks in trying look
>> into actual values of object paths to infer their relation to each
>> other. However, since the battery object paths would be discovered
>> through the device object there might not be any need for such a
>> backwards reference.
>>
>>>>> The other option i can think of is to have another interface
>>>>> registered on the device object path:
>>>>>
>>>>> Service org.bluez
>>>>> Interface org.bluez.Batteries
>>>>> Object path [variable prefix]/{hci0,..}/dev_XX_XX_XX_XX_XX_XX
>>>>>
>>>>> Methods dict GetProperties()
>>>>>
>>>>> Returns all properties for the interface. See the
>>>>> Properties section for the available properties.
>>>>>
>>>>> Signals ProperyChanged(string name, variant value)
>>>>>
>>>>> This signal indicates a changed value of the given
>>>>> property.
>>>>>
>>>>> Properties array{object} Batteries [readonly]
>>>>>
>>>>> List of device battery object paths that represents the available
>>>>> batteries on the remote devices.
>>>>>
>>>>>
>>>>> Service org.bluez
>>>>> Interface org.bluez.Battery
>>>>> Object path [variable prefix]/{hci0,..}/dev_XX_XX_XX_XX_XX_XX/BATT-NN-DDDD
>>>>>
>>>>>
>>>>> Methods dict GetProperties()
>>>>>
>>>>> Returns all properties for the interface. See the
>>>>> Properties section for the available properties.
>>>>>
>>>>> Signals PropertyChanged(string name, variant value)
>>>>>
>>>>> This signal indicates a changed value of the given
>>>>> property.
>>>>>
>>>>> Properties byte Level [readonly]
>>>>>
>>>>> Battery level (0-100).
>>>>>
>>>>> Any other suggestion ?
>>>>
>>>> That would work, although both of these interfaces are rather
>>>> light-weight in that they only contain a single property which begs the
>>>> question whether this is a bit over-kill.
>>> I know. I believe so as well, but if you want to separate the
>>> interfaces, it is a must.
>>>
>>>>
>>>> Another option is to do away with the per-battery object somehow and
>>>> expose all batteries through a single interface. I'm not so sure that's
>>>> a good idea though since it could prevent future extensibility of the
>>>> API and doesn't reuse the common tools we have for object-like
>>>> abstractions (which a battery certainly is).
>>> If we do what you suggest, a battery name (namespace+descriptor)
>>> will be the property name, and the value should be the battery
>>> level. i'm not too comfortable with it, and it is different than
>>> what we used to do up until now.
>>>
>>> So where do we go from here ?
>>
>> Some extra opinions/view points could help. Maybe Marcel or Luiz have
>> some preferences/ideas on how to do this.
>
> Im trying to think how having multiple objects could be useful for the
> UI, most likely it only gonna show a single meter aggregating all the
> batteries.
>
So what do you suggest here ? Calculating an average ? How shoudl it be
done ? If 2 batteries are available, first is 100% and the second is
50%, we should simply set the value as 75%? I'm not so sure that we
should make such decisions for the end user.
> Another thing that worth adding is that there are other profiles that
> do support battery status such as HFP and AVRCP, so I think this
> should be made generic enough so other sources could be supported.
>
The internal device API uses the device_add_battery(...) and
device_remove_battery(...) to allow adding/removing batteries to the
device battery list, but it is the responsibility of the profile to
register a D-Bus interface, and update.
I could redesign this, to add a generic battery API, which will expose a
new API, such as battery_add(battery_struct* batt),
battery_remove(battery_struct* batt) and battery_update(battery_struct*
batt) which will allow a more generic approach. This Battery module will
be responsible for registering/unregistering the D-Bus API, and profiles
which need to use it will simply use the exposed API to
add/remove/update. The batt_structure will also include some callback
functions to be called when a value is queried for example, or if a
device is removed. The LE Battery plugin will use the GATT to
read/write/receive notification, and use the Generic Battery interface
to interface with the external world. What do you think about it ?
BR,
Chen Ganir
^ permalink raw reply
* Re: [PATCH] Bluetooth: Add support for Apple vendor-specific devices
From: Shea Levy @ 2012-08-25 19:04 UTC (permalink / raw)
To: Henrik Rydberg; +Cc: Gustavo Padovan, linux-bluetooth, linux-kernel
In-Reply-To: <1345915686-3915-1-git-send-email-rydberg@euromail.se>
On 08/25/2012 01:28 PM, Henrik Rydberg wrote:
> As pointed out by Gustavo and Marcel, all Apple-specific Broadcom
> devices seen so far have the same interface class, subclass and
> protocol numbers. This patch adds an entry which matches all of them,
> using the new USB_VENDOR_AND_INTERFACE_INFO() macro.
>
> In particular, this patch adds support for the MacBook Pro Retina
> (05ac:8286), which is not in the present list.
>
> Signed-off-by: Henrik Rydberg<rydberg@euromail.se>
> ---
> Hi Gustavo,
>
> here is a patch for the Apple devices, utilizing commit d81a5d19, for
> 3.6. Tested on the MacBookPro10,1 (Retina). If you want, I can
> follow-up with a patch for 3.7 which removes the specific entries. I
> have verified the lsusb output of all of them, except MacMini5,1.
>
> Thanks,
> Henrik
>
> drivers/bluetooth/btusb.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/drivers/bluetooth/btusb.c b/drivers/bluetooth/btusb.c
> index 12075ad..1fae607 100644
> --- a/drivers/bluetooth/btusb.c
> +++ b/drivers/bluetooth/btusb.c
> @@ -52,6 +52,9 @@ static struct usb_device_id btusb_table[] = {
> /* Generic Bluetooth USB device */
> { USB_DEVICE_INFO(0xe0, 0x01, 0x01) },
>
> + /* Apple-specific (Broadcom) devices */
> + { USB_VENDOR_AND_INTERFACE_INFO(0x05ac, 0xff, 0x01, 0x01) },
> +
> /* Broadcom SoftSailing reporting vendor specific */
> { USB_DEVICE(0x0a5c, 0x21e1) },
>
Tested on my Macbook Pro 9,2, usb-devices output:
T: Bus=04 Lev=04 Prnt=04 Port=02 Cnt=01 Dev#= 9 Spd=12 MxCh= 0
D: Ver= 2.00 Cls=ff(vend.) Sub=01 Prot=01 MxPS=64 #Cfgs= 1
P: Vendor=05ac ProdID=821d Rev=00.86
S: Manufacturer=Apple Inc.
S: Product=Bluetooth USB Host Controller
C: #Ifs= 4 Cfg#= 1 Atr=e0 MxPwr=0mA
I: If#= 0 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=01 Prot=01 Driver=btusb
I: If#= 1 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
I: If#= 2 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=(none)
I: If#= 3 Alt= 0 #EPs= 0 Cls=fe(app. ) Sub=01 Prot=01 Driver=(none)
So:
Tested-by: Shea Levy <shea@shealevy.com>
^ permalink raw reply
* Re: [PATCH] Bluetooth: Add support for Apple vendor-specific devices
From: Henrik Rydberg @ 2012-08-25 18:35 UTC (permalink / raw)
To: Shea Levy; +Cc: Gustavo Padovan, linux-bluetooth, linux-kernel
In-Reply-To: <5039179D.6010909@shealevy.com>
> I'm getting a build error due to lack of
> USB_VENDOR_AND_INTERFACE_INFO macro when patching 3.5.2 with that
> patch. Which kernel tree should I patch with this patch to test?
The macro is in the pipe to 3.5.x, probably only a couple of days
away. The patch is for 3.6, as stated, meaning it applies on top of
Linus's tree.
Henrik
^ permalink raw reply
* Re: [PATCH] Bluetooth: Add support for Apple vendor-specific devices
From: Shea Levy @ 2012-08-25 18:21 UTC (permalink / raw)
To: Henrik Rydberg; +Cc: Gustavo Padovan, linux-bluetooth, linux-kernel
In-Reply-To: <20120825174342.GA4057@polaris.bitmath.org>
Hi
On 08/25/2012 01:43 PM, Henrik Rydberg wrote:
> On Sat, Aug 25, 2012 at 01:28:52PM -0400, Shea Levy wrote:
>> Hello,
>>
>> On 08/25/2012 01:28 PM, Henrik Rydberg wrote:
>>> + /* Apple-specific (Broadcom) devices */
>>> + { USB_VENDOR_AND_INTERFACE_INFO(0x05ac, 0xff, 0x01, 0x01) },
>>> +
>>>
>> Would this subsume https://lkml.org/lkml/2012/8/22/689 ?
> Yes, it will make 05ac:821d work as well. If you are able to test it
> successfully, we can append the commit message and add your Tested-by.
I'm getting a build error due to lack of USB_VENDOR_AND_INTERFACE_INFO
macro when patching 3.5.2 with that patch. Which kernel tree should I
patch with this patch to test?
> Thanks,
> Henrik
> --
> To unsubscribe from this list: send the line "unsubscribe linux-bluetooth" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
Thanks,
Shea
^ permalink raw reply
* Re: [PATCH] Bluetooth: Add support for Apple vendor-specific devices
From: Henrik Rydberg @ 2012-08-25 17:43 UTC (permalink / raw)
To: Shea Levy; +Cc: Gustavo Padovan, linux-bluetooth, linux-kernel
In-Reply-To: <50390B54.4040706@shealevy.com>
On Sat, Aug 25, 2012 at 01:28:52PM -0400, Shea Levy wrote:
> Hello,
>
> On 08/25/2012 01:28 PM, Henrik Rydberg wrote:
> >+ /* Apple-specific (Broadcom) devices */
> >+ { USB_VENDOR_AND_INTERFACE_INFO(0x05ac, 0xff, 0x01, 0x01) },
> >+
> >
>
> Would this subsume https://lkml.org/lkml/2012/8/22/689 ?
Yes, it will make 05ac:821d work as well. If you are able to test it
successfully, we can append the commit message and add your Tested-by.
Thanks,
Henrik
^ permalink raw reply
* Re: [PATCH] Bluetooth: Add support for Apple vendor-specific devices
From: Shea Levy @ 2012-08-25 17:28 UTC (permalink / raw)
To: Henrik Rydberg; +Cc: Gustavo Padovan, linux-bluetooth, linux-kernel
In-Reply-To: <1345915686-3915-1-git-send-email-rydberg@euromail.se>
Hello,
On 08/25/2012 01:28 PM, Henrik Rydberg wrote:
> + /* Apple-specific (Broadcom) devices */
> + { USB_VENDOR_AND_INTERFACE_INFO(0x05ac, 0xff, 0x01, 0x01) },
> +
>
Would this subsume https://lkml.org/lkml/2012/8/22/689 ?
Thanks,
Shea Levy
^ permalink raw reply
* [PATCH] Bluetooth: Add support for Apple vendor-specific devices
From: Henrik Rydberg @ 2012-08-25 17:28 UTC (permalink / raw)
To: Gustavo Padovan; +Cc: linux-bluetooth, linux-kernel, Henrik Rydberg
As pointed out by Gustavo and Marcel, all Apple-specific Broadcom
devices seen so far have the same interface class, subclass and
protocol numbers. This patch adds an entry which matches all of them,
using the new USB_VENDOR_AND_INTERFACE_INFO() macro.
In particular, this patch adds support for the MacBook Pro Retina
(05ac:8286), which is not in the present list.
Signed-off-by: Henrik Rydberg <rydberg@euromail.se>
---
Hi Gustavo,
here is a patch for the Apple devices, utilizing commit d81a5d19, for
3.6. Tested on the MacBookPro10,1 (Retina). If you want, I can
follow-up with a patch for 3.7 which removes the specific entries. I
have verified the lsusb output of all of them, except MacMini5,1.
Thanks,
Henrik
drivers/bluetooth/btusb.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/bluetooth/btusb.c b/drivers/bluetooth/btusb.c
index 12075ad..1fae607 100644
--- a/drivers/bluetooth/btusb.c
+++ b/drivers/bluetooth/btusb.c
@@ -52,6 +52,9 @@ static struct usb_device_id btusb_table[] = {
/* Generic Bluetooth USB device */
{ USB_DEVICE_INFO(0xe0, 0x01, 0x01) },
+ /* Apple-specific (Broadcom) devices */
+ { USB_VENDOR_AND_INTERFACE_INFO(0x05ac, 0xff, 0x01, 0x01) },
+
/* Broadcom SoftSailing reporting vendor specific */
{ USB_DEVICE(0x0a5c, 0x21e1) },
--
1.7.12
^ permalink raw reply related
* Re: [PATCH v2] btusb: add another Foxconn/Hon Hai ID
From: Marcel Holtmann @ 2012-08-25 11:32 UTC (permalink / raw)
To: Johannes Berg; +Cc: Gustavo Padovan, Johan Hedberg, linux-bluetooth
In-Reply-To: <1345880448.13280.1.camel@jlt4.sipsolutions.net>
Hi Johannes,
> I found a device using 0xe052 for idProduct:
>
> T: Bus=01 Lev=02 Prnt=02 Port=02 Cnt=02 Dev#= 4 Spd=12 MxCh= 0
> D: Ver= 2.00 Cls=ff(vend.) Sub=01 Prot=01 MxPS=64 #Cfgs= 1
> P: Vendor=0489 ProdID=e052 Rev= 1.12
> S: Manufacturer=Broadcom Corp
> S: Product=BCM20702A0
> S: SerialNumber=C01885B16F75
> C:* #Ifs= 4 Cfg#= 1 Atr=e0 MxPwr= 0mA
> I:* If#= 0 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=01 Prot=01 Driver=(none)
> E: Ad=81(I) Atr=03(Int.) MxPS= 16 Ivl=1ms
> E: Ad=82(I) Atr=02(Bulk) MxPS= 64 Ivl=0ms
> E: Ad=02(O) Atr=02(Bulk) MxPS= 64 Ivl=0ms
> I:* If#= 1 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=01 Prot=01 Driver=(none)
> E: Ad=83(I) Atr=01(Isoc) MxPS= 0 Ivl=1ms
> E: Ad=03(O) Atr=01(Isoc) MxPS= 0 Ivl=1ms
> I: If#= 1 Alt= 1 #EPs= 2 Cls=ff(vend.) Sub=01 Prot=01 Driver=(none)
> E: Ad=83(I) Atr=01(Isoc) MxPS= 9 Ivl=1ms
> E: Ad=03(O) Atr=01(Isoc) MxPS= 9 Ivl=1ms
> I: If#= 1 Alt= 2 #EPs= 2 Cls=ff(vend.) Sub=01 Prot=01 Driver=(none)
> E: Ad=83(I) Atr=01(Isoc) MxPS= 17 Ivl=1ms
> E: Ad=03(O) Atr=01(Isoc) MxPS= 17 Ivl=1ms
> I: If#= 1 Alt= 3 #EPs= 2 Cls=ff(vend.) Sub=01 Prot=01 Driver=(none)
> E: Ad=83(I) Atr=01(Isoc) MxPS= 25 Ivl=1ms
> E: Ad=03(O) Atr=01(Isoc) MxPS= 25 Ivl=1ms
> I: If#= 1 Alt= 4 #EPs= 2 Cls=ff(vend.) Sub=01 Prot=01 Driver=(none)
> E: Ad=83(I) Atr=01(Isoc) MxPS= 33 Ivl=1ms
> E: Ad=03(O) Atr=01(Isoc) MxPS= 33 Ivl=1ms
> I: If#= 1 Alt= 5 #EPs= 2 Cls=ff(vend.) Sub=01 Prot=01 Driver=(none)
> E: Ad=83(I) Atr=01(Isoc) MxPS= 49 Ivl=1ms
> E: Ad=03(O) Atr=01(Isoc) MxPS= 49 Ivl=1ms
> I:* If#= 2 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=(none)
> E: Ad=84(I) Atr=02(Bulk) MxPS= 32 Ivl=0ms
> E: Ad=04(O) Atr=02(Bulk) MxPS= 32 Ivl=0ms
> I:* If#= 3 Alt= 0 #EPs= 0 Cls=fe(app. ) Sub=01 Prot=01 Driver=(none)
>
> Add it to the list in the driver.
>
> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
> ---
> drivers/bluetooth/btusb.c | 1 +
> 1 file changed, 1 insertion(+)
Acked-by: Marcel Holtmann <marcel@holtmann.org>
Regards
Marcel
^ 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