* RE: [PATCH] network: Check full BNEP UUID
From: Par-Gunnar HJALMDAHL @ 2012-08-15 11:17 UTC (permalink / raw)
To: Johan Hedberg; +Cc: linux-bluetooth@vger.kernel.org, Anurag GUPTA-1
In-Reply-To: <20120815103912.GA26379@x220>
Hi and thanks for you comments Johan,
> -----Original Message-----
> From: Johan Hedberg [mailto:johan.hedberg@gmail.com]
> Sent: den 15 augusti 2012 12:39
> To: Par-Gunnar HJALMDAHL
> Cc: linux-bluetooth@vger.kernel.org; Anurag GUPTA-1
> Subject: Re: [PATCH] network: Check full BNEP UUID
>
> There are a couple of things that bug me a bit with this patch. One is
> the re-definition of bluetooth_base_uuid which really should only exist
> in one central place (lib/uuid.c). Another is the way the code logic
> goes. It seems you want to test for two things:
>
> 1) That the UUID is a Bluetooth UUID. This is the memcmp
> with
> the last 12 bytes of the Bluetooth base UUID for the UUID128
> case. 16 and 32 bit values are already implicitly assumed to
> be
> Bluetooth UUIDs as they don't contain any information to
> reveal
> this as such.
>
> 2) That the (now determined) Bluetooth UUID has a value less
> than or equal to 0xffff. This is quite awkwardly tested for
> by
> comparing with the two first bytes from bluetooth_base_uuid,
> which are both zeros. Based on your code comment it sounds
> like
> this test should really be covered by bnep_setup_chk().
>
> If you really want to have the "<= 0xffff" test be in bnep_setup_decode
> then I'd propose something like the attached patch. However, testing
> for the exact value of the Bluetooth UUID (once the UUID has been
> determined to be a Bluetooth UUID) seems like the task of
> bnep_setup_chk from the way you've laid out the functions.
>
> Johan
Basically I tried to keep the patch to a minimum since it was quite a
simple issue to fix.
I have no problems to use the UUID in lib/uuid.c. I could add a 2 new
exported functions for retrieving base UUID, one for little endian and
one for big endian, since uuid.c endian depends on CPU endian while
PAN endian is always big endian. So:
void get_le_bt_base_uuid(uint128_t *uuid);
void get_be_bt_base_uuid(uint128_t *uuid);
Your suggestion looks fine. It's a bit more effective than my original
code. The reason I did the check in bnep_setup_decode() rather than in
bnep_setup_chk is that only 16 bits are kept when exiting the function
(bnep_setup_decode is the only function aware of the UUID size) and I
thought that was a quite straightforward design.
If it's OK with you I can create a new patch with suggestion above
plus your patch.
/P-G
^ permalink raw reply
* Re: [PATCH] network: Check full BNEP UUID
From: Johan Hedberg @ 2012-08-15 10:39 UTC (permalink / raw)
To: Par-Gunnar Hjalmdahl; +Cc: linux-bluetooth, Anurag Gupta
In-Reply-To: <1343380000-24935-1-git-send-email-par-gunnar.hjalmdahl@stericsson.com>
[-- Attachment #1: Type: text/plain, Size: 2916 bytes --]
Hi,
On Fri, Jul 27, 2012, Par-Gunnar Hjalmdahl wrote:
> This patch fixes an issue where only the 2 bytes containing
> the service ID was checked from the BNEP UUID.
> Fixes behavior for BT testcases TP/PAN/MISC/UUID/BV-01-C &
> TP/PAN/MISC/UUID/BV-02-C.
> ---
> profiles/network/server.c | 21 +++++++++++++++++++++
> 1 file changed, 21 insertions(+)
>
> diff --git a/profiles/network/server.c b/profiles/network/server.c
> index 480c7e2..15ea1cb 100644
> --- a/profiles/network/server.c
> +++ b/profiles/network/server.c
> @@ -54,6 +54,11 @@
> #define NETWORK_SERVER_INTERFACE "org.bluez.NetworkServer"
> #define SETUP_TIMEOUT 1
>
> +static uint128_t bluetooth_base_uuid = {
> + .data = {0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x10, 0x00,
> + 0x80, 0x00, 0x00, 0x80, 0x5F, 0x9B, 0x34, 0xFB}
> +};
> +
> /* Pending Authorization */
> struct network_session {
> bdaddr_t dst; /* Remote Bluetooth Address */
> @@ -313,6 +318,22 @@ static uint16_t bnep_setup_decode(struct bnep_setup_conn_req *req,
> break;
> case 4: /* UUID32 */
> case 16: /* UUID128 */
> + /*
> + * Check that the bytes in the UUID, except the service ID itself, are
> + * correct. The service ID is checked in bnep_setup_chk().
> + */
> + if (memcmp(dest, bluetooth_base_uuid.data, 2))
> + return BNEP_CONN_INVALID_DST;
> + if (memcmp(source, bluetooth_base_uuid.data, 2))
> + return BNEP_CONN_INVALID_SRC;
> +
> + if (req->uuid_size == 16) {
> + if (memcmp(&dest[4], &bluetooth_base_uuid.data[4], 12))
> + return BNEP_CONN_INVALID_DST;
> + if (memcmp(&source[4], &bluetooth_base_uuid.data[4], 12))
> + return BNEP_CONN_INVALID_SRC;
> + }
> +
> *dst_role = bt_get_be32(dest);
> *src_role = bt_get_be32(source);
> break;
There are a couple of things that bug me a bit with this patch. One is
the re-definition of bluetooth_base_uuid which really should only exist
in one central place (lib/uuid.c). Another is the way the code logic
goes. It seems you want to test for two things:
1) That the UUID is a Bluetooth UUID. This is the memcmp with
the last 12 bytes of the Bluetooth base UUID for the UUID128
case. 16 and 32 bit values are already implicitly assumed to be
Bluetooth UUIDs as they don't contain any information to reveal
this as such.
2) That the (now determined) Bluetooth UUID has a value less
than or equal to 0xffff. This is quite awkwardly tested for by
comparing with the two first bytes from bluetooth_base_uuid,
which are both zeros. Based on your code comment it sounds like
this test should really be covered by bnep_setup_chk().
If you really want to have the "<= 0xffff" test be in bnep_setup_decode
then I'd propose something like the attached patch. However, testing for
the exact value of the Bluetooth UUID (once the UUID has been determined
to be a Bluetooth UUID) seems like the task of bnep_setup_chk from the
way you've laid out the functions.
Johan
[-- Attachment #2: 0001-network-Check-full-BNEP-UUID.patch --]
[-- Type: text/plain, Size: 2064 bytes --]
>From 52fd85377f6784d69beec0ec7911bdf4b9621077 Mon Sep 17 00:00:00 2001
From: Par-Gunnar Hjalmdahl <par-gunnar.hjalmdahl@stericsson.com>
Date: Fri, 27 Jul 2012 11:06:40 +0200
Subject: [PATCH] network: Check full BNEP UUID
This patch fixes an issue where only the 2 bytes containing the service
ID was checked from the BNEP UUID. Fixes behavior for BT test cases
TP/PAN/MISC/UUID/BV-01-C & TP/PAN/MISC/UUID/BV-02-C.
---
profiles/network/server.c | 26 +++++++++++++++++++++++---
1 file changed, 23 insertions(+), 3 deletions(-)
diff --git a/profiles/network/server.c b/profiles/network/server.c
index 480c7e2..8ae608c 100644
--- a/profiles/network/server.c
+++ b/profiles/network/server.c
@@ -301,7 +301,10 @@ static uint16_t bnep_setup_chk(uint16_t dst_role, uint16_t src_role)
static uint16_t bnep_setup_decode(struct bnep_setup_conn_req *req,
uint16_t *dst_role, uint16_t *src_role)
{
+ const uint8_t bt_base[] = { 0x00, 0x00, 0x10, 0x00, 0x80, 0x00,
+ 0x00, 0x80, 0x5F, 0x9B, 0x34, 0xFB };
uint8_t *dest, *source;
+ uint32_t val;
dest = req->service;
source = req->service + req->uuid_size;
@@ -311,10 +314,27 @@ static uint16_t bnep_setup_decode(struct bnep_setup_conn_req *req,
*dst_role = bt_get_be16(dest);
*src_role = bt_get_be16(source);
break;
- case 4: /* UUID32 */
case 16: /* UUID128 */
- *dst_role = bt_get_be32(dest);
- *src_role = bt_get_be32(source);
+ /* Check that the bytes in the UUID, except the service ID
+ * itself, are correct. The service ID is checked in
+ * bnep_setup_chk(). */
+ if (memcmp(&dest[4], bt_base, sizeof(bt_base)) != 0)
+ return BNEP_CONN_INVALID_DST;
+ if (memcmp(&source[4], bt_base, sizeof(bt_base)) != 0)
+ return BNEP_CONN_INVALID_SRC;
+
+ /* Intentional no-break */
+
+ case 4: /* UUID32 */
+ val = bt_get_be32(dest);
+ if (val > 0xffff)
+ return BNEP_CONN_INVALID_DST;
+ *dst_role = val;
+
+ val = bt_get_be32(source);
+ if (val > 0xffff)
+ return BNEP_CONN_INVALID_SRC;
+ *src_role = val;
break;
default:
return BNEP_CONN_INVALID_SVC;
--
1.7.11.2
^ permalink raw reply related
* Re: [PATCHv1 4/4] Bluetooth: trivial: Use preferred method for NULL check
From: Andrei Emeltchenko @ 2012-08-15 9:57 UTC (permalink / raw)
To: Gustavo Padovan, linux-bluetooth
In-Reply-To: <20120815041655.GD3344@joana>
Hi Gustavo,
On Wed, Aug 15, 2012 at 01:16:55AM -0300, Gustavo Padovan wrote:
> > From: Andrei Emeltchenko <andrei.emeltchenko@intel.com>
> >
> > Use standard bluetooth way to check NULL pointer !var instead of
> > var == NULL.
> >
> > Signed-off-by: Andrei Emeltchenko <andrei.emeltchenko@intel.com>
> > ---
> > net/bluetooth/af_bluetooth.c | 4 ++--
> > 1 file changed, 2 insertions(+), 2 deletions(-)
>
> I applied patches 2, 3 and 4 to bluetooth-next. Patch 1 needs rebase. Thanks.
Patches 1 and 3 needs patch from linux-next and wireless-testing
<------8<------------------------------------------------------------------
| vsprintf: add %pMR for Bluetooth MAC address
|
| author Andrei Emeltchenko <andrei.emeltchenko@intel.com>
| Mon, 30 Jul 2012 21:40:23 +0000 (14:40 -0700)
| committer Linus Torvalds <torvalds@linux-foundation.org>
| Tue, 31 Jul 2012 00:25:14 +0000 (17:25 -0700)
| Bluetooth uses mostly LE byte order which is reversed for visual
| interpretation. Currently in Bluetooth in use unsafe batostr function.
|
| This is a slightly modified version of Joe's patch (sent Sat, Dec 4,
| 2010).
|
| Signed-off-by: Andrei Emeltchenko <andrei.emeltchenko@intel.com>
| Cc: Joe Perches <joe@perches.com>
| Cc: Marcel Holtmann <marcel@holtmann.org>
| Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
| Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
|
<------8<------------------------------------------------------------------
which adds actual specifier.
Best regards
Andrei Emeltchenko
^ permalink raw reply
* Re: [PATCH BlueZ v2 1/3] att: Add prepare write support
From: Johan Hedberg @ 2012-08-15 9:27 UTC (permalink / raw)
To: Eder Ruiz Maria; +Cc: linux-bluetooth
In-Reply-To: <1343669655-12586-1-git-send-email-eder.ruiz@openbossa.org>
Hi Eder,
On Mon, Jul 30, 2012, Eder Ruiz Maria wrote:
> Add functions for encoding/decoding Prepare Write Request and
> Response PDUs.
> ---
> attrib/att.c | 54 ++++++++++++++++++++++++++++++++++++++++++++++++++++++
> attrib/att.h | 5 +++++
> 2 files changed, 59 insertions(+)
All three patches have been applied. Thanks.
I also went ahead and finally updated the entire attrib code base to use
proper size_t, ssize_t, off_t etc variables where appropriate. This
means that any unapplied attrib patches may need rebasing (and fixing to
follow the same convention).
Johan
^ permalink raw reply
* Re: [PATCH] add support bluetooth usb 0489:e046 Foxconn / Hon Hai
From: Gustavo Padovan @ 2012-08-15 4:41 UTC (permalink / raw)
To: aborigines; +Cc: marcel, padovan, linux-bluetooth, linux-kernel
In-Reply-To: <1344757304-11555-1-git-send-email-7aborigines7@gmail.com>
* aborigines <7aborigines7@gmail.com> [2012-08-12 14:41:44 +0700]:
> $ usb-deveices
> T: Bus=01 Lev=02 Prnt=02 Port=02 Cnt=03 Dev#= 5 Spd=12 MxCh= 0
> D: Ver= 2.00 Cls=ff(vend.) Sub=01 Prot=01 MxPS=64 #Cfgs= 1
> P: Vendor=0489 ProdID=e046 Rev=01.12
> S: Manufacturer=Broadcom Corp
> S: Product=BCM20702A0
> S: SerialNumber=C01885F67F9E
> 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)
> I: If#= 1 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=01 Prot=01 Driver=(none)
> 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)
>
> $ lsusb
> Bus 001 Device 005: ID 0489:e046 Foxconn / Hon Hai
> ---
> drivers/bluetooth/btusb.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/bluetooth/btusb.c b/drivers/bluetooth/btusb.c
> index fc4bcd6..fb54c70 100644
> --- a/drivers/bluetooth/btusb.c
> +++ b/drivers/bluetooth/btusb.c
> @@ -110,6 +110,7 @@ static struct usb_device_id btusb_table[] = {
>
> /* Foxconn - Hon Hai */
> { USB_DEVICE(0x0489, 0xe033) },
> + { USB_DEVICE(0x0489, 0xe046) },
>
> { } /* Terminating entry */
> };
Can you try the following patch and see if it works for you.
Gustavo
---
commit 8d2952f43af434f0aa5d109a9ae50c5886a9322c (HEAD, master)
Author: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
Date: Wed Aug 15 01:38:11 2012 -0300
Bluetooth: Add USB_VENDOR_AND_INTERFACE_INFO() for Broadcom/Foxconn
Foxconn devices has a vendor specific class of device, we will match them
differently now.
Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
diff --git a/drivers/bluetooth/btusb.c b/drivers/bluetooth/btusb.c
index f637c25..f077f4d 100644
--- a/drivers/bluetooth/btusb.c
+++ b/drivers/bluetooth/btusb.c
@@ -101,7 +101,7 @@ static struct usb_device_id btusb_table[] = {
{ USB_DEVICE(0x413c, 0x8197) },
/* Foxconn - Hon Hai */
- { USB_DEVICE(0x0489, 0xe033) },
+ { USB_VENDOR_AND_INTERFACE_INFO(0x0489, 0xff, 0x01, 0x01) },
{ } /* Terminating entry */
};
^ permalink raw reply related
* Re: [RFC v4 3/3] Bluetooth: mgmt: Add device disconnect reason
From: Gustavo Padovan @ 2012-08-15 4:32 UTC (permalink / raw)
To: Mikel Astiz; +Cc: linux-bluetooth, Mikel Astiz
In-Reply-To: <1344498750-2698-4-git-send-email-mikel.astiz.oss@gmail.com>
Hi Mikel,
* Mikel Astiz <mikel.astiz.oss@gmail.com> [2012-08-09 09:52:30 +0200]:
> From: Mikel Astiz <mikel.astiz@bmw-carit.de>
>
> MGMT_EV_DEVICE_DISCONNECTED will now expose the disconnection reason to
> userland, distinguishing four possible values:
>
> 0x00 Reason not known or unspecified
> 0x01 Connection timeout
> 0x02 Connection terminated by local host
> 0x03 Connection terminated by remote host
>
> Note that the local/remote distinction just determines which side
> terminated the low-level connection, regardless of the disconnection of
> the higher-level profiles.
>
> This can sometimes be misleading and thus must be used with care. For
> example, some hardware combinations would report a locally initiated
> disconnection even if the user turned Bluetooth off in the remote side.
>
> Signed-off-by: Mikel Astiz <mikel.astiz@bmw-carit.de>
> ---
> include/net/bluetooth/hci_core.h | 2 +-
> include/net/bluetooth/mgmt.h | 9 +++++++++
> net/bluetooth/hci_event.c | 26 +++++++++++++++++++++++---
> net/bluetooth/mgmt.c | 9 +++++----
> 4 files changed, 38 insertions(+), 8 deletions(-)
All 3 patches have been applied to bluetooth-next. Thanks.
Gustavo
^ permalink raw reply
* Re: [RFC BlueZ] doc: Introduce Alert API
From: Gustavo Padovan @ 2012-08-15 4:27 UTC (permalink / raw)
To: Anderson Lizardo; +Cc: linux-bluetooth
In-Reply-To: <1344450186-14961-1-git-send-email-anderson.lizardo@openbossa.org>
Hi Anderson,
* Anderson Lizardo <anderson.lizardo@openbossa.org> [2012-08-08 14:23:06 -0400]:
> This API will be implemented and initially used by Phone Alert Status
> and Alert Notification GATT profiles (server role).
> ---
> doc/alert-api.txt | 95 +++++++++++++++++++++++++++++++++++++++++++++++++++++
> 1 file changed, 95 insertions(+)
> create mode 100644 doc/alert-api.txt
>
> diff --git a/doc/alert-api.txt b/doc/alert-api.txt
> new file mode 100644
> index 0000000..209c4da
> --- /dev/null
> +++ b/doc/alert-api.txt
> @@ -0,0 +1,95 @@
> +BlueZ D-Bus Alert API description
> +*********************************
> +
> +Copyright (C) 2012 Instituto Nokia de Tecnologia - INdT
> +
> +Introduction
> +------------
> +
> +Currently, there are two different GATT server profiles that depend on
> +receiving alerts or notifications from the platform: Phone Alert Status (PASP)
> +and Alert Notification (ANP). Additionally, PASP is very specific to mobile
> +phones, and also allow limited control to alerts (i.e. mute once, or switch to
> +a silent mode).
> +
> +This document presents a unified API that allows to register,
Is there some missing text here?
> +
> +Alert hierarchy
> +===============
> +
> +Service org.bluez
> +Interface org.bluez.Alert
> +Object path /org/bluez
> +
> +Methods void RegisterAlert(string category)
> +
> + Register a new alert category. This means the
> + application will be responsible for notifying BlueZ of
> + any alerts of that category, using the Alert() method.
> +
> + Supported categories: generic, email, news, call,
> + missed_call, sms_mms, voice_mail, schedule,
> + instant_message, ringer, vibrate, display.
> +
> + Possible Errors: org.bluez.Error.InvalidArguments
> +
> + void RegisterAgent(string category, object agent)
> +
> + Register a new agent for the alert category. The agent
> + object methods to be called depend on the category. The
> + currently supported category is "ringer", with methods
> + MuteOnce() and SetRingerMode().
> +
> + Possible Errors: org.bluez.Error.InvalidArguments
If I got this right you RegisterAlert() and then RegisterAgent() in the
sequence, right? Why can't you merge both calls into one.
> +
> + void NewAlert(string category, string description)
> +
> + Notify BlueZ of a new alert for the given category. The
> + description can be sender name, called ID, title, or
> + other information specific to the alert. For ringer,
> + vibrate and display categories, valid descriptions are
> + "active" and "not active".
The way I understand it I see many NewAlert() calls happening almost at the
same time. Isn't possible to pass a dict with many {string category, string
description} inside?
> +
> + Possible Errors: org.bluez.Error.InvalidArguments
> +
> + void UnreadAlertCount(string category, uint16 count)
> +
> + Some services (like SMS and e-mail) keep track of
> + number of unread items. This method allows to update
> + this counter, so peer devices can read it using Alert
> + Notification Profile.
> +
> + Note that just calling NewAlert() will not implicitly
> + increment the unread count for a category. The
> + application must call this method to increase or
> + decrease the unread counter.
Is there a good reason for not increment the count on NewAlert()?
Gustavo
^ permalink raw reply
* Re: [PATCHv1 4/4] Bluetooth: trivial: Use preferred method for NULL check
From: Gustavo Padovan @ 2012-08-15 4:16 UTC (permalink / raw)
To: Andrei Emeltchenko; +Cc: linux-bluetooth
In-Reply-To: <1344351906-27563-5-git-send-email-Andrei.Emeltchenko.news@gmail.com>
Hi Andrei,
* Andrei Emeltchenko <Andrei.Emeltchenko.news@gmail.com> [2012-08-07 18:05:06 +0300]:
> From: Andrei Emeltchenko <andrei.emeltchenko@intel.com>
>
> Use standard bluetooth way to check NULL pointer !var instead of
> var == NULL.
>
> Signed-off-by: Andrei Emeltchenko <andrei.emeltchenko@intel.com>
> ---
> net/bluetooth/af_bluetooth.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
I applied patches 2, 3 and 4 to bluetooth-next. Patch 1 needs rebase. Thanks.
Gustavo
^ permalink raw reply
* Re: [PATCH v2] Bluetooth: Add support for Sony Vaio T-Series
From: Gustavo Padovan @ 2012-08-15 4:08 UTC (permalink / raw)
To: Mohammed Shafi Shajakhan; +Cc: marcel, linux-bluetooth, yevgeniy.melnichuk
In-Reply-To: <1344349090-4397-1-git-send-email-mohammed@qca.qualcomm.com>
Hi Mohammed,
* Mohammed Shafi Shajakhan <mohammed@qca.qualcomm.com> [2012-08-07 19:48:10 +0530]:
> From: Yevgeniy Melnichuk <yevgeniy.melnichuk@googlemail.com>
>
> Add Sony Vaio T-Series Bluetooth Module( 0x489:0xE036) to
> the blacklist of btusb module and add it to the ath3k module.
>
> output of cat /sys/kernel/debug/usb/devices
>
> T: Bus=01 Lev=02 Prnt=02 Port=01 Cnt=01 Dev#= 5 Spd=12 MxCh= 0
> D: Ver= 1.10 Cls=e0(wlcon) Sub=01 Prot=01 MxPS=64 #Cfgs= 1
> P: Vendor=0489 ProdID=e036 Rev= 0.02
> S: Manufacturer=Atheros Communications
> S: Product=Bluetooth USB Host Controller
> S: SerialNumber=Alaska Day 2006
> C:* #Ifs= 2 Cfg#= 1 Atr=e0 MxPwr=100mA
> I:* If#= 0 Alt= 0 #EPs= 3 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
> 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=e0(wlcon) Sub=01 Prot=01 Driver=btusb
> 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=e0(wlcon) Sub=01 Prot=01 Driver=btusb
> 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=e0(wlcon) Sub=01 Prot=01 Driver=btusb
> 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=e0(wlcon) Sub=01 Prot=01 Driver=btusb
> 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=e0(wlcon) Sub=01 Prot=01 Driver=btusb
> 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=e0(wlcon) Sub=01 Prot=01 Driver=btusb
> E: Ad=83(I) Atr=01(Isoc) MxPS= 49 Ivl=1ms
> E: Ad=03(O) Atr=01(Isoc) MxPS= 49 Ivl=1ms
>
> Signed-off-by: Yevgeniy Melnichuk <yevgeniy.melnichuk@googlemail.com>
> Signed-off-by: Mohammed Shafi Shajakhan <mohammed@qca.qualcomm.com>
> ---
> drivers/bluetooth/ath3k.c | 2 ++
> drivers/bluetooth/btusb.c | 1 +
> 2 files changed, 3 insertions(+), 0 deletions(-)
Patch has been applied to bluetooth.git. Thanks.
Gustavo
^ permalink raw reply
* Re: [PATCH] Bluetooth: Fix use-after-free bug in SMP
From: Gustavo Padovan @ 2012-08-15 4:07 UTC (permalink / raw)
To: Andre Guedes; +Cc: linux-bluetooth
In-Reply-To: <1343864055-23154-1-git-send-email-andre.guedes@openbossa.org>
Hi Andre,
* Andre Guedes <andre.guedes@openbossa.org> [2012-08-01 20:34:15 -0300]:
> If SMP fails, we should always cancel security_timer delayed work.
> Otherwise, security_timer function may run after l2cap_conn object
> has been freed.
>
> This patch fixes the following warning reported by ODEBUG:
>
> WARNING: at lib/debugobjects.c:261 debug_print_object+0x7c/0x8d()
> Hardware name: Bochs
> ODEBUG: free active (active state 0) object type: timer_list hint: delayed_work_timer_fn+0x0/0x27
> Modules linked in: btusb bluetooth
> Pid: 440, comm: kworker/u:2 Not tainted 3.5.0-rc1+ #4
> Call Trace:
> [<ffffffff81174600>] ? free_obj_work+0x4a/0x7f
> [<ffffffff81023eb8>] warn_slowpath_common+0x7e/0x97
> [<ffffffff81023f65>] warn_slowpath_fmt+0x41/0x43
> [<ffffffff811746b1>] debug_print_object+0x7c/0x8d
> [<ffffffff810394f0>] ? __queue_work+0x241/0x241
> [<ffffffff81174fdd>] debug_check_no_obj_freed+0x92/0x159
> [<ffffffff810ac08e>] slab_free_hook+0x6f/0x77
> [<ffffffffa0019145>] ? l2cap_conn_del+0x148/0x157 [bluetooth]
> [<ffffffff810ae408>] kfree+0x59/0xac
> [<ffffffffa0019145>] l2cap_conn_del+0x148/0x157 [bluetooth]
> [<ffffffffa001b9a2>] l2cap_recv_frame+0xa77/0xfa4 [bluetooth]
> [<ffffffff810592f9>] ? trace_hardirqs_on_caller+0x112/0x1ad
> [<ffffffffa001c86c>] l2cap_recv_acldata+0xe2/0x264 [bluetooth]
> [<ffffffffa0002b2f>] hci_rx_work+0x235/0x33c [bluetooth]
> [<ffffffff81038dc3>] ? process_one_work+0x126/0x2fe
> [<ffffffff81038e22>] process_one_work+0x185/0x2fe
> [<ffffffff81038dc3>] ? process_one_work+0x126/0x2fe
> [<ffffffff81059f2e>] ? lock_acquired+0x1b5/0x1cf
> [<ffffffffa00028fa>] ? le_scan_work+0x11d/0x11d [bluetooth]
> [<ffffffff81036fb6>] ? spin_lock_irq+0x9/0xb
> [<ffffffff81039209>] worker_thread+0xcf/0x175
> [<ffffffff8103913a>] ? rescuer_thread+0x175/0x175
> [<ffffffff8103cfe0>] kthread+0x95/0x9d
> [<ffffffff812c5054>] kernel_threadi_helper+0x4/0x10
> [<ffffffff812c36b0>] ? retint_restore_args+0x13/0x13
> [<ffffffff8103cf4b>] ? flush_kthread_worker+0xdb/0xdb
> [<ffffffff812c5050>] ? gs_change+0x13/0x13
>
> This bug can be reproduced using hctool lecc or l2test tools and
> bluetoothd not running.
>
> Signed-off-by: Andre Guedes <andre.guedes@openbossa.org>
> ---
> net/bluetooth/smp.c | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
Patch has been applied to bluetooth.git. Thanks.
Gustavo
^ permalink raw reply
* Re: [PATCH v3 7/7] Bluetooth: Add type information to the hci_connect() debug statement
From: Gustavo Padovan @ 2012-08-15 4:04 UTC (permalink / raw)
To: Vinicius Costa Gomes; +Cc: linux-bluetooth
In-Reply-To: <1343428380-32705-8-git-send-email-vinicius.gomes@openbossa.org>
Hi Vinicius,
* Vinicius Costa Gomes <vinicius.gomes@openbossa.org> [2012-07-27 19:33:00 -0300]:
> Now that we have a "connect" function for each link type, we should be
> able to indentify which function is going to be called.
>
> Signed-off-by: Vinicius Costa Gomes <vinicius.gomes@openbossa.org>
> ---
> net/bluetooth/hci_conn.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
all 7 patches have been applied to bluetooth-next. Thanks.
Gustavo
^ permalink raw reply
* [RFC][PATCH 2/2] Cache firmware images for later use
From: Jesse Sung @ 2012-08-15 1:16 UTC (permalink / raw)
To: linux-bluetooth
In-Reply-To: <cover.1344992721.git.jesse.sung@canonical.com>
From: Wen-chien Jesse Sung <jesse.sung@canonical.com>
Since request_firmware() may fail when resume from suspend, store
used firmware image in ram to make sure that we can have what we need
on resume.
Signed-off-by: Wen-chien Jesse Sung <jesse.sung@canonical.com>
---
drivers/bluetooth/btusb.c | 77 +++++++++++++++++++++++++++++++++++----------
1 file changed, 60 insertions(+), 17 deletions(-)
diff --git a/drivers/bluetooth/btusb.c b/drivers/bluetooth/btusb.c
index b60a2ae..6559c1b 100644
--- a/drivers/bluetooth/btusb.c
+++ b/drivers/bluetooth/btusb.c
@@ -218,18 +218,34 @@ MODULE_FIRMWARE(FW_0A5C_21F3);
MODULE_FIRMWARE(FW_0A5C_21F4);
MODULE_FIRMWARE(FW_413C_8197);
+struct firmware_cache {
+ const char *filename;
+ u8* data;
+ size_t size;
+};
+
+static struct firmware_cache firmware[] = {
+ { .filename = FW_0A5C_21D3, },
+ { .filename = FW_0A5C_21D7, },
+ { .filename = FW_413C_8197, },
+ { .filename = FW_0489_E031, },
+ { .filename = FW_0A5C_21E6, },
+ { .filename = FW_0A5C_21F3, },
+ { .filename = FW_0A5C_21F4, },
+};
+
static struct usb_device_id patchram_table[] = {
/* Dell DW1704 */
- { USB_DEVICE(0x0a5c, 0x21d3), .driver_info = (kernel_ulong_t) FW_0A5C_21D3 },
- { USB_DEVICE(0x0a5c, 0x21d7), .driver_info = (kernel_ulong_t) FW_0A5C_21D7 },
+ { USB_DEVICE(0x0a5c, 0x21d3), .driver_info = (kernel_ulong_t) &firmware[0] },
+ { USB_DEVICE(0x0a5c, 0x21d7), .driver_info = (kernel_ulong_t) &firmware[1] },
/* Dell DW380 */
- { USB_DEVICE(0x413c, 0x8197), .driver_info = (kernel_ulong_t) FW_413C_8197 },
+ { USB_DEVICE(0x413c, 0x8197), .driver_info = (kernel_ulong_t) &firmware[2] },
/* FoxConn Hon Hai */
- { USB_DEVICE(0x0489, 0xe031), .driver_info = (kernel_ulong_t) FW_0489_E031 },
+ { USB_DEVICE(0x0489, 0xe031), .driver_info = (kernel_ulong_t) &firmware[3] },
/* Lenovo */
- { USB_DEVICE(0x0a5c, 0x21e6), .driver_info = (kernel_ulong_t) FW_0A5C_21E6 },
- { USB_DEVICE(0x0a5c, 0x21f3), .driver_info = (kernel_ulong_t) FW_0A5C_21F3 },
- { USB_DEVICE(0x0a5c, 0x21f4), .driver_info = (kernel_ulong_t) FW_0A5C_21F4 },
+ { USB_DEVICE(0x0a5c, 0x21e6), .driver_info = (kernel_ulong_t) &firmware[4] },
+ { USB_DEVICE(0x0a5c, 0x21f3), .driver_info = (kernel_ulong_t) &firmware[5] },
+ { USB_DEVICE(0x0a5c, 0x21f4), .driver_info = (kernel_ulong_t) &firmware[6] },
};
#define BTUSB_MAX_ISOC_FRAMES 10
@@ -953,14 +969,27 @@ static inline void load_patchram_fw(struct usb_device *udev, const struct usb_de
{
size_t pos = 0;
int err = 0;
- const struct firmware *fw;
+ struct firmware_cache *fwcache;
unsigned char reset_cmd[] = { 0x03, 0x0c, 0x00 };
unsigned char download_cmd[] = { 0x2e, 0xfc, 0x00 };
- if (request_firmware(&fw, (const char *) id->driver_info, &udev->dev) < 0) {
- BT_INFO("can't load firmware, may not work correctly");
- return;
+ fwcache = (struct firmware_cache *)id->driver_info;
+ if (!fwcache->data) {
+ const struct firmware *fw;
+ if (request_firmware(&fw, fwcache->filename, &udev->dev) < 0) {
+ BT_INFO("can't load firmware, may not work correctly");
+ return;
+ }
+ fwcache->data = kmalloc(fw->size, GFP_KERNEL);
+ if (!fwcache->data) {
+ BT_INFO("OOM");
+ release_firmware(fw);
+ return;
+ }
+ fwcache->size = fw->size;
+ memcpy(fwcache->data, fw->data, fwcache->size);
+ release_firmware(fw);
}
if (usb_control_msg(udev, usb_sndctrlpipe(udev, 0), 0, USB_TYPE_CLASS, 0, 0,
@@ -977,12 +1006,12 @@ static inline void load_patchram_fw(struct usb_device *udev, const struct usb_de
}
msleep(300);
- while (pos < fw->size) {
+ while (pos < fwcache->size) {
size_t len;
- len = fw->data[pos + 2] + 3;
- if ((pos + len > fw->size) ||
+ len = fwcache->data[pos + 2] + 3;
+ if ((pos + len > fwcache->size) ||
(usb_control_msg(udev, usb_sndctrlpipe(udev, 0), 0,
- USB_TYPE_CLASS, 0, 0, (void *)fw->data + pos, len,
+ USB_TYPE_CLASS, 0, 0, (void *)(fwcache->data + pos), len,
PATCHRAM_TIMEOUT) < 0)) {
err = -1;
goto out;
@@ -995,7 +1024,6 @@ static inline void load_patchram_fw(struct usb_device *udev, const struct usb_de
out:
if (err)
BT_INFO("fail to load firmware, may not work correctly");
- release_firmware(fw);
}
static int btusb_probe(struct usb_interface *intf,
@@ -1326,7 +1354,22 @@ static struct usb_driver btusb_driver = {
.disable_hub_initiated_lpm = 1,
};
-module_usb_driver(btusb_driver);
+static int __init btusb_init(void)
+{
+ return usb_register(&btusb_driver);
+}
+
+static void __exit btusb_exit(void)
+{
+ int i;
+ for (i = 0; i < sizeof(firmware) / sizeof(firmware[0]); i++)
+ if (firmware[i].data)
+ kfree(firmware[i].data);
+ usb_deregister(&btusb_driver);
+}
+
+module_init(btusb_init);
+module_exit(btusb_exit);
module_param(ignore_dga, bool, 0644);
MODULE_PARM_DESC(ignore_dga, "Ignore devices with id 08fd:0001");
--
1.7.9.5
^ permalink raw reply related
* [RFC][PATCH 1/2] Implement broadcom patchram firmware loader
From: Jesse Sung @ 2012-08-15 1:15 UTC (permalink / raw)
To: linux-bluetooth
In-Reply-To: <cover.1344992721.git.jesse.sung@canonical.com>
From: Wen-chien Jesse Sung <jesse.sung@canonical.com>
Signed-off-by: Wen-chien Jesse Sung <jesse.sung@canonical.com>
---
drivers/bluetooth/btusb.c | 109 ++++++++++++++++++++++++++++++++++++++++++---
1 file changed, 103 insertions(+), 6 deletions(-)
diff --git a/drivers/bluetooth/btusb.c b/drivers/bluetooth/btusb.c
index cef3bac..b60a2ae 100644
--- a/drivers/bluetooth/btusb.c
+++ b/drivers/bluetooth/btusb.c
@@ -23,6 +23,8 @@
#include <linux/module.h>
#include <linux/usb.h>
+#include <linux/delay.h>
+#include <linux/firmware.h>
#include <net/bluetooth/bluetooth.h>
#include <net/bluetooth/hci_core.h>
@@ -47,6 +49,7 @@ static struct usb_driver btusb_driver;
#define BTUSB_BROKEN_ISOC 0x20
#define BTUSB_WRONG_SCO_MTU 0x40
#define BTUSB_ATH3012 0x80
+#define BTUSB_BCM_PATCHRAM 0x100
static struct usb_device_id btusb_table[] = {
/* Generic Bluetooth USB device */
@@ -93,13 +96,16 @@ static struct usb_device_id btusb_table[] = {
{ USB_DEVICE(0x0c10, 0x0000) },
/* Broadcom BCM20702A0 */
+ { USB_DEVICE(0x0489, 0xe031), .driver_info = BTUSB_BCM_PATCHRAM },
{ USB_DEVICE(0x0489, 0xe042) },
+ { USB_DEVICE(0x0a5c, 0x21d3), .driver_info = BTUSB_BCM_PATCHRAM },
+ { USB_DEVICE(0x0a5c, 0x21d7), .driver_info = BTUSB_BCM_PATCHRAM },
{ USB_DEVICE(0x0a5c, 0x21e3) },
- { USB_DEVICE(0x0a5c, 0x21e6) },
+ { USB_DEVICE(0x0a5c, 0x21e6), .driver_info = BTUSB_BCM_PATCHRAM },
{ USB_DEVICE(0x0a5c, 0x21e8) },
- { USB_DEVICE(0x0a5c, 0x21f3) },
- { USB_DEVICE(0x0a5c, 0x21f4) },
- { USB_DEVICE(0x413c, 0x8197) },
+ { USB_DEVICE(0x0a5c, 0x21f3), .driver_info = BTUSB_BCM_PATCHRAM },
+ { USB_DEVICE(0x0a5c, 0x21f4), .driver_info = BTUSB_BCM_PATCHRAM },
+ { USB_DEVICE(0x413c, 0x8197), .driver_info = BTUSB_BCM_PATCHRAM },
/* Foxconn - Hon Hai */
{ USB_DEVICE(0x0489, 0xe033) },
@@ -195,6 +201,37 @@ static struct usb_device_id blacklist_table[] = {
{ } /* Terminating entry */
};
+#define PATCHRAM_TIMEOUT 1000
+#define FW_0489_E031 "fw-0489_e031.hcd"
+#define FW_0A5C_21D3 "fw-0a5c_21d3.hcd"
+#define FW_0A5C_21D7 "fw-0a5c_21d7.hcd"
+#define FW_0A5C_21E6 "fw-0a5c_21e6.hcd"
+#define FW_0A5C_21F3 "fw-0a5c_21f3.hcd"
+#define FW_0A5C_21F4 "fw-0a5c_21f4.hcd"
+#define FW_413C_8197 "fw-413c_8197.hcd"
+
+MODULE_FIRMWARE(FW_0489_E031);
+MODULE_FIRMWARE(FW_0A5C_21D3);
+MODULE_FIRMWARE(FW_0A5C_21D7);
+MODULE_FIRMWARE(FW_0A5C_21E6);
+MODULE_FIRMWARE(FW_0A5C_21F3);
+MODULE_FIRMWARE(FW_0A5C_21F4);
+MODULE_FIRMWARE(FW_413C_8197);
+
+static struct usb_device_id patchram_table[] = {
+ /* Dell DW1704 */
+ { USB_DEVICE(0x0a5c, 0x21d3), .driver_info = (kernel_ulong_t) FW_0A5C_21D3 },
+ { USB_DEVICE(0x0a5c, 0x21d7), .driver_info = (kernel_ulong_t) FW_0A5C_21D7 },
+ /* Dell DW380 */
+ { USB_DEVICE(0x413c, 0x8197), .driver_info = (kernel_ulong_t) FW_413C_8197 },
+ /* FoxConn Hon Hai */
+ { USB_DEVICE(0x0489, 0xe031), .driver_info = (kernel_ulong_t) FW_0489_E031 },
+ /* Lenovo */
+ { USB_DEVICE(0x0a5c, 0x21e6), .driver_info = (kernel_ulong_t) FW_0A5C_21E6 },
+ { USB_DEVICE(0x0a5c, 0x21f3), .driver_info = (kernel_ulong_t) FW_0A5C_21F3 },
+ { USB_DEVICE(0x0a5c, 0x21f4), .driver_info = (kernel_ulong_t) FW_0A5C_21F4 },
+};
+
#define BTUSB_MAX_ISOC_FRAMES 10
#define BTUSB_INTR_RUNNING 0
@@ -912,6 +949,55 @@ static void btusb_waker(struct work_struct *work)
usb_autopm_put_interface(data->intf);
}
+static inline void load_patchram_fw(struct usb_device *udev, const struct usb_device_id *id)
+{
+ size_t pos = 0;
+ int err = 0;
+ const struct firmware *fw;
+
+ unsigned char reset_cmd[] = { 0x03, 0x0c, 0x00 };
+ unsigned char download_cmd[] = { 0x2e, 0xfc, 0x00 };
+
+ if (request_firmware(&fw, (const char *) id->driver_info, &udev->dev) < 0) {
+ BT_INFO("can't load firmware, may not work correctly");
+ return;
+ }
+
+ if (usb_control_msg(udev, usb_sndctrlpipe(udev, 0), 0, USB_TYPE_CLASS, 0, 0,
+ reset_cmd, sizeof(reset_cmd), PATCHRAM_TIMEOUT) < 0) {
+ err = -1;
+ goto out;
+ }
+ msleep(300);
+
+ if (usb_control_msg(udev, usb_sndctrlpipe(udev, 0), 0, USB_TYPE_CLASS, 0, 0,
+ download_cmd, sizeof(download_cmd), PATCHRAM_TIMEOUT) < 0) {
+ err = -1;
+ goto out;
+ }
+ msleep(300);
+
+ while (pos < fw->size) {
+ size_t len;
+ len = fw->data[pos + 2] + 3;
+ if ((pos + len > fw->size) ||
+ (usb_control_msg(udev, usb_sndctrlpipe(udev, 0), 0,
+ USB_TYPE_CLASS, 0, 0, (void *)fw->data + pos, len,
+ PATCHRAM_TIMEOUT) < 0)) {
+ err = -1;
+ goto out;
+ }
+ pos += len;
+ }
+
+ err = (usb_control_msg(udev, usb_sndctrlpipe(udev, 0), 0, USB_TYPE_CLASS, 0, 0,
+ reset_cmd, sizeof(reset_cmd), PATCHRAM_TIMEOUT) < 0);
+out:
+ if (err)
+ BT_INFO("fail to load firmware, may not work correctly");
+ release_firmware(fw);
+}
+
static int btusb_probe(struct usb_interface *intf,
const struct usb_device_id *id)
{
@@ -1076,15 +1162,26 @@ static int btusb_probe(struct usb_interface *intf,
}
}
+ usb_set_intfdata(intf, data);
+
+ if (id->driver_info & BTUSB_BCM_PATCHRAM) {
+ const struct usb_device_id *match;
+ match = usb_match_id(intf, patchram_table);
+ if (match) {
+ btusb_open(hdev);
+ load_patchram_fw(interface_to_usbdev(intf), match);
+ btusb_close(hdev);
+ }
+ }
+
err = hci_register_dev(hdev);
if (err < 0) {
hci_free_dev(hdev);
+ usb_set_intfdata(intf, NULL);
kfree(data);
return err;
}
- usb_set_intfdata(intf, data);
-
return 0;
}
--
1.7.9.5
^ permalink raw reply related
* [RFC][PATCH 0/2] broadcom patchram firmware loader
From: Jesse Sung @ 2012-08-15 1:15 UTC (permalink / raw)
To: linux-bluetooth
From: Wen-chien Jesse Sung <jesse.sung@canonical.com>
There is an user space firmware loading tool which can be found at
http://marc.info/?l=linux-bluetooth&m=132039175324993&w=2
This tool requires hci device to do the firmware loading, but this
may cause some race condition between patchram tool and bluetoothd
or something that also works on hci interface.
Also it needs some hooks to make firmware loads after bootup, s3,
s4, rfkill, and device hotplug events. Implement this loader in kernel
module would make things more easier.
Wen-chien Jesse Sung (2):
Implement broadcom patchram firmware loader
Cache firmware images for later use
drivers/bluetooth/btusb.c | 154 ++++++++++++++++++++++++++++++++++++++++++---
1 file changed, 147 insertions(+), 7 deletions(-)
--
1.7.9.5
^ permalink raw reply
* Re: [RFC][PATCH 0/2] broadcom patchram firmware loader
From: Jesse Sung @ 2012-08-15 1:14 UTC (permalink / raw)
To: Joao Paulo Rechi Vita; +Cc: linux-bluetooth
In-Reply-To: <CAAngNMZn-XqrmOjErhkUqfSKqg2WhdfgDCs-DtZkAyNtBX7XRg@mail.gmail.com>
Hi Joao,
Thanks for your reply. I'll send these patches again and make them inline.
Regards,
Jesse
2012/8/15 Joao Paulo Rechi Vita <jprvita@openbossa.org>:
> Hello Jesse,
>
> On Tue, Aug 14, 2012 at 11:24 AM, Jesse Sung <jesse.sung@canonical.com> wrote:
>>
>> There is a user space firmware loading tool which can be found at
>> http://article.gmane.org/gmane.linux.bluez.kernel/17932
>>
>> This tool requires hci device to do the firmware loading, but this
>> may cause some race condition between patchram tool and bluetoothd
>> or something that also works on hci interface.
>>
>> Also it needs some hooks to make firmware loads after bootup, s3,
>> s4, rfkill, and device hotplug events. Implement this loader in kernel
>> module would make things more easier.
>>
>>
>> Wen-chien Jesse Sung (2):
>> Implement broadcom patchram firmware loader
>> Cache firmware images for later use
>>
>
> Can you please re-send the patches inline? This way it's easier for
> people to comment on the mailing list and there is increased chance it
> gets merged sooner. 'git send-email' is the best way to do that.
>
> Thanks.
>
> --
> João Paulo Rechi Vita
> Openbossa Labs - INdT
^ permalink raw reply
* [PATCH] Bluetooth: mgmt: Fix returning a list with invalid indexes
From: Vinicius Costa Gomes @ 2012-08-14 23:59 UTC (permalink / raw)
To: linux-bluetooth; +Cc: Vinicius Costa Gomes
When a device is in the HCI_SETUP state, it was being counted as
a valid device, but it wasn't included in the list returned to
userspace.
This can be reproduced when you add an adapter after doing
'rfkill block all', for example.
This commit also has the (intended) effect of making
'btmgmt power on' work after the rfkill block has been lifted.
Signed-off-by: Vinicius Costa Gomes <vinicius.gomes@openbossa.org>
---
net/bluetooth/mgmt.c | 3 ---
1 file changed, 3 deletions(-)
diff --git a/net/bluetooth/mgmt.c b/net/bluetooth/mgmt.c
index a3329cb..c500b59 100644
--- a/net/bluetooth/mgmt.c
+++ b/net/bluetooth/mgmt.c
@@ -350,9 +350,6 @@ static int read_index_list(struct sock *sk, struct hci_dev *hdev, void *data,
i = 0;
list_for_each_entry(d, &hci_dev_list, list) {
- if (test_bit(HCI_SETUP, &d->dev_flags))
- continue;
-
if (!mgmt_valid_hdev(d))
continue;
--
1.7.11.4
^ permalink raw reply related
* Re: Backports mailing list
From: Luis R. Rodriguez @ 2012-08-14 23:00 UTC (permalink / raw)
To: sedat.dilek
Cc: David Miller, linux-kernel, linux-wireless, linux-bluetooth,
lf_driver_backport, Julia Lawall, Jesper Andersen,
Ozan Çağlayan, Hauke Mehrtens
In-Reply-To: <CAB=NE6Wad1yNhUrvJZn0p62gZHAhpTjYaf5qNjjkdOboOiQ=Xg@mail.gmail.com>
On Tue, Aug 14, 2012 at 9:33 AM, Luis R. Rodriguez <mcgrof@frijolero.org> wrote:
> On Tue, Aug 14, 2012 at 9:00 AM, Luis R. Rodriguez <mcgrof@frijolero.org> wrote:
>> For more details please see:
>>
>> http://www.do-not-panic.com/2012/08/automatically-backporting-linux-kernel.html
>> http://www.do-not-panic.com/2012/08/optimizing-backporting-collateral.html
>>
>> Luis
>
> All that said, please use the shiny new mailing list:
> backports@vger.kernel.org for patches for compat / compat-drivers.
Furthermore, the project git tree has changed to be renamed to
compat-drivers as well now, and the new wiki page should be used
moving forward:
https://backports.wiki.kernel.org
git://github.com/mcgrof/compat-drivers.git
Luis
^ permalink raw reply
* Re: [PATCH BlueZ] mgmt: Add LE scanning callback
From: Joao Paulo Rechi Vita @ 2012-08-14 17:59 UTC (permalink / raw)
To: Johan Hedberg, linux-bluetooth, Claudio Takahasi
In-Reply-To: <20120814103043.GB8175@x220>
On Tue, Aug 14, 2012 at 7:30 AM, Johan Hedberg <johan.hedberg@gmail.com> wrote:
> Hi,
>
> On Tue, Aug 14, 2012, Johan Hedberg wrote:
>> On Fri, Aug 03, 2012, João Paulo Rechi Vita wrote:
>> > From: Claudio Takahasi <claudio.takahasi@openbossa.org>
>> >
>> > This patch adds a new callback to allow the adapter to control LE
>> > scanning. The current approach uses the active scanning with default
>> > windows and intervals defined by the core spec without any filtering.
>> > ---
>> > src/mgmt.c | 32 ++++++++++++++++++++++++++++++++
>> > src/mgmt.h | 1 +
>> > 2 files changed, 33 insertions(+)
>> >
>> > diff --git a/src/mgmt.c b/src/mgmt.c
>> > index 8ae86d3..5ceeaa8 100644
>> > --- a/src/mgmt.c
>> > +++ b/src/mgmt.c
>> > @@ -1999,6 +1999,38 @@ int mgmt_start_discovery(int index)
>> > return 0;
>> > }
>> >
>> > +int mgmt_start_scanning(int index)
>> > +{
>> > + char buf[MGMT_HDR_SIZE + sizeof(struct mgmt_cp_start_discovery)];
>> > + struct mgmt_hdr *hdr = (void *) buf;
>> > + struct mgmt_cp_start_discovery *cp = (void *) &buf[sizeof(*hdr)];
>> > + struct controller_info *info = &controllers[index];
>> > +
>> > + DBG("index %d", index);
>> > +
>> > + info->discov_type = 0;
>> > +
>> > + if (mgmt_low_energy(info->current_settings)) {
>> > + hci_set_bit(BDADDR_LE_PUBLIC, &info->discov_type);
>> > + hci_set_bit(BDADDR_LE_RANDOM, &info->discov_type);
>> > + }
>>
>> Shouldn't you just return an error here (e.g. -ENOTSUP) if LE is not
>> supported/enabled?
>>
>> Have there been any patches sent that would use this API? At least I
>> didn't see any after a quick scan of the mailing list.
>
> I see that these users are part of the original thread sent on Jul 27th.
> I got confused since you renamed the subjects in a way that there was no
> other indication to the original thread except the References: header.
>
> The point about returning an error still remains though.
>
Ok, as soon as Claudio fixes this I'll send an updated revision of the
whole series tagged with 'v2'.
--
João Paulo Rechi Vita
Openbossa Labs - INdT
^ permalink raw reply
* Re: [PATCH BlueZ] mgmt: print error message when start_discovery fails
From: Joao Paulo Rechi Vita @ 2012-08-14 17:53 UTC (permalink / raw)
To: João Paulo Rechi Vita, linux-bluetooth
In-Reply-To: <20120814102812.GA8175@x220>
On Tue, Aug 14, 2012 at 7:28 AM, Johan Hedberg <johan.hedberg@gmail.com> wrote:
> Hi,
>
> On Tue, Aug 14, 2012, Johan Hedberg wrote:
>> On Fri, Aug 03, 2012, João Paulo Rechi Vita wrote:
>> > If we fail to communicate with the MGMT socket is better to print the
>> > error message on the mgmtops plugin, where it really happened, instead
>> > of leaving this job to its users.
>> > ---
>> > src/adapter.c | 6 +-----
>> > src/mgmt.c | 7 +++++--
>> > 2 files changed, 6 insertions(+), 7 deletions(-)
>>
>> How do these two patches differ from patches 02/14 and 07/14 of the
>> patch set that was sent on July 27th? Why were these two patches resent
>> separately? A cover letter would have been quite useful here.
>
> Nevermind. I see that they reference the original thread and are
> probably updates based on received comments. Anyway, it would have been
> clearer if you'd have added "v2" to the subject and kept the xx/yy
> numbering.
>
Sorry, I thought that using "--in-reply-to <message_id>" was enough
for you to figure out what was going without problems. I've only
re-generated these two when re-sending, that's why they got a
different numbering. I'll be more caution next time.
--
João Paulo Rechi Vita
Openbossa Labs - INdT
^ permalink raw reply
* Re: [RFCv0 04/21] Bluetooth: Process create response and connect response identically
From: Mat Martineau @ 2012-08-14 17:25 UTC (permalink / raw)
To: Andrei Emeltchenko; +Cc: linux-bluetooth, gustavo, pkrystad
In-Reply-To: <20120814101213.GA18949@aemeltch-MOBL1>
Hi Andrei -
On Tue, 14 Aug 2012, Andrei Emeltchenko wrote:
> Hi Mat,
>
> On Wed, Jul 25, 2012 at 04:50:56PM -0700, Mat Martineau wrote:
> ...
>> -static inline int l2cap_create_channel_rsp(struct l2cap_conn *conn,
>> - struct l2cap_cmd_hdr *cmd, void *data)
>> -{
>> - BT_DBG("conn %p", conn);
>> -
>> - return l2cap_connect_rsp(conn, cmd, data);
>> -}
>> -
>> static void l2cap_send_move_chan_rsp(struct l2cap_conn *conn, u8 ident,
>> u16 icid, u16 result)
>> {
>> @@ -4249,6 +4241,7 @@ static inline int l2cap_bredr_sig_cmd(struct l2cap_conn *conn,
>> break;
>>
>> case L2CAP_CONN_RSP:
>> + case L2CAP_CREATE_CHAN_RSP:
>> err = l2cap_connect_rsp(conn, cmd, data);
> ...
>
> We might rename l2cap_connect_rsp to something like
> l2cap_connect_create_rsp
Ok, I'll update that function name.
--
Mat Martineau
Employee of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum
^ permalink raw reply
* Re: [RFC][PATCH 0/2] broadcom patchram firmware loader
From: Joao Paulo Rechi Vita @ 2012-08-14 17:14 UTC (permalink / raw)
To: Jesse Sung; +Cc: linux-bluetooth
In-Reply-To: <cover.1344952391.git.jesse.sung@canonical.com>
Hello Jesse,
On Tue, Aug 14, 2012 at 11:24 AM, Jesse Sung <jesse.sung@canonical.com> wrote:
>
> There is a user space firmware loading tool which can be found at
> http://article.gmane.org/gmane.linux.bluez.kernel/17932
>
> This tool requires hci device to do the firmware loading, but this
> may cause some race condition between patchram tool and bluetoothd
> or something that also works on hci interface.
>
> Also it needs some hooks to make firmware loads after bootup, s3,
> s4, rfkill, and device hotplug events. Implement this loader in kernel
> module would make things more easier.
>
>
> Wen-chien Jesse Sung (2):
> Implement broadcom patchram firmware loader
> Cache firmware images for later use
>
Can you please re-send the patches inline? This way it's easier for
people to comment on the mailing list and there is increased chance it
gets merged sooner. 'git send-email' is the best way to do that.
Thanks.
--
João Paulo Rechi Vita
Openbossa Labs - INdT
^ permalink raw reply
* Re: Backports mailing list
From: Luis R. Rodriguez @ 2012-08-14 16:33 UTC (permalink / raw)
To: sedat.dilek
Cc: David Miller, linux-kernel, linux-wireless, linux-bluetooth,
lf_driver_backport, Julia Lawall, Jesper Andersen,
Ozan Çağlayan, Hauke Mehrtens
In-Reply-To: <CAB=NE6V=4J7yKbPdb4gVT6BBjdewhYRNEwrNdMd4XE5Ocg4SeQ@mail.gmail.com>
On Tue, Aug 14, 2012 at 9:00 AM, Luis R. Rodriguez <mcgrof@frijolero.org> wrote:
> For more details please see:
>
> http://www.do-not-panic.com/2012/08/automatically-backporting-linux-kernel.html
> http://www.do-not-panic.com/2012/08/optimizing-backporting-collateral.html
>
> Luis
All that said, please use the shiny new mailing list:
backports@vger.kernel.org for patches for compat / compat-drivers.
Luis
^ permalink raw reply
* Re: Backports mailing list
From: Luis R. Rodriguez @ 2012-08-14 16:00 UTC (permalink / raw)
To: sedat.dilek
Cc: David Miller, linux-kernel, linux-wireless, linux-bluetooth,
lf_driver_backport, Julia Lawall, Jesper Andersen,
Ozan Çağlayan, Hauke Mehrtens
In-Reply-To: <CA+icZUU9qT9H2jy_H8_6Bk1XUbuV0N6_pGRoQbSJhnikewTc0Q@mail.gmail.com>
On Tue, Aug 14, 2012 at 2:34 AM, Sedat Dilek <sedat.dilek@gmail.com> wrote:
> On Mon, Aug 13, 2012 at 10:42 PM, Luis R. Rodriguez
> <mcgrof@frijolero.org> wrote:
>> David,
>>
>> The compat [0] / compat-wireless [1] [2] projects have received quite
>> a bit of love of the years to the point we now have 3 subsystems
>> backported: Ethernet, Bluetooth and 802.11. Ozan Çağlayan, a Linux
>> Foundation Google Summer of Code student is folding in right now drm
>> driver support. At the request of the community, specifically those
>> part of the Linux Foundation driver working group [3], we are going to
>> be renaming the project to compat-drivers soon after drm is integrated
>> and will be housing documentation under the kernel.org infrastructure
>> [4] under this new name. It'll take some time for us to migrate the
>> documentation / releases but do not see major issues with that, it
>> will just take a bit of time but hope to have it done for the next
>> stable release based on the next kernel stable release. At this time
>> for patches we do have a Linux Foundation mailing list but have had
>> issues with it for a while now so we keep using linux-wireless for
>> patches. Given that our focus is to always prioritize upstream and
>> always try to work with solutions that ensure vendors are focusing on
>> upstream solutions and prioritizing upstream [5] I was hoping we can
>> get a mailing list set up on vger for the project, perhaps
>> backports@vger.kernel.org, so we don't flood the other mailing lists
>> with random kernel backport junk. Please let me know if this is
>> reasonable.
>>
>> [0] https://github.com/mcgrof/compat
>> [1] http://wireless.kernel.org/en/users/Download/
>> [2] http://wireless.kernel.org/en/users/Download/stable/
>> [3] http://www.linuxfoundation.org/collaborate/workgroups/driver-backport/group
>> [4] https://backports.wiki.kernel.org
>> [5] http://wireless.kernel.org/en/users/Download/stable/#Additional_patches_to_stable_releases
>>
>
> Hi,
>
> I am wondering why people are not consistent in naming - here again a
> good example.
>
> The workgroup at Linux Foundation is called "driver-backport".
> You (Luis) are talking about a rename to "compat-drivers".
> And then the ML and wiki have the name "backports".
>
> So "backports" is for me is a bit confusing!
> That reminds me when I first read about "AAArgh64!!!" stuff which was
> in the end called mips64 to keep consistency to other existing arches.
>
> So, just to fool the world a bit more:
> What about "linux-backports" or why didn't you keep the "driver-backport" name?
>
> Just my 0.02EUR.
To start off with the compat-drivers name came as a recommendation
from the workgroup and it follows the old name evolution:
compat-wireless --> compat-drivers. The reason for not having a long
similar alias for the mailing list is vger.kernel.org already implies
Linux kernel so backports is nice and short. Another reason is that
the backporting project already has 2 target source code projects:
* compat - a shared module
* compat-drivers - the drivers we pull and backport
When folks send patches they can prepend their patches with the
project name as a prefix to the patch.
For more details please see:
http://www.do-not-panic.com/2012/08/automatically-backporting-linux-kernel.html
http://www.do-not-panic.com/2012/08/optimizing-backporting-collateral.html
Luis
^ permalink raw reply
* [RFC][PATCH 2/2] Cache firmware images for later use
From: Jesse Sung @ 2012-08-14 14:24 UTC (permalink / raw)
To: linux-bluetooth
In-Reply-To: <cover.1344952391.git.jesse.sung@canonical.com>
[-- Attachment #1: Type: text/plain, Size: 44 bytes --]
This is a multi-part message in MIME format.
[-- Attachment #2: Type: text/plain, Size: 348 bytes --]
Since request_firmware() may fail when resume from suspend, store
used firmware image in ram to make sure that we can have what we need
on resume.
Signed-off-by: Wen-chien Jesse Sung <jesse.sung@canonical.com>
---
drivers/bluetooth/btusb.c | 77 +++++++++++++++++++++++++++++++++++----------
1 file changed, 60 insertions(+), 17 deletions(-)
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #3: 0002-Cache-firmware-images-for-later-use.patch --]
[-- Type: text/x-patch; name="0002-Cache-firmware-images-for-later-use.patch", Size: 4390 bytes --]
diff --git a/drivers/bluetooth/btusb.c b/drivers/bluetooth/btusb.c
index b60a2ae..6559c1b 100644
--- a/drivers/bluetooth/btusb.c
+++ b/drivers/bluetooth/btusb.c
@@ -218,18 +218,34 @@ MODULE_FIRMWARE(FW_0A5C_21F3);
MODULE_FIRMWARE(FW_0A5C_21F4);
MODULE_FIRMWARE(FW_413C_8197);
+struct firmware_cache {
+ const char *filename;
+ u8* data;
+ size_t size;
+};
+
+static struct firmware_cache firmware[] = {
+ { .filename = FW_0A5C_21D3, },
+ { .filename = FW_0A5C_21D7, },
+ { .filename = FW_413C_8197, },
+ { .filename = FW_0489_E031, },
+ { .filename = FW_0A5C_21E6, },
+ { .filename = FW_0A5C_21F3, },
+ { .filename = FW_0A5C_21F4, },
+};
+
static struct usb_device_id patchram_table[] = {
/* Dell DW1704 */
- { USB_DEVICE(0x0a5c, 0x21d3), .driver_info = (kernel_ulong_t) FW_0A5C_21D3 },
- { USB_DEVICE(0x0a5c, 0x21d7), .driver_info = (kernel_ulong_t) FW_0A5C_21D7 },
+ { USB_DEVICE(0x0a5c, 0x21d3), .driver_info = (kernel_ulong_t) &firmware[0] },
+ { USB_DEVICE(0x0a5c, 0x21d7), .driver_info = (kernel_ulong_t) &firmware[1] },
/* Dell DW380 */
- { USB_DEVICE(0x413c, 0x8197), .driver_info = (kernel_ulong_t) FW_413C_8197 },
+ { USB_DEVICE(0x413c, 0x8197), .driver_info = (kernel_ulong_t) &firmware[2] },
/* FoxConn Hon Hai */
- { USB_DEVICE(0x0489, 0xe031), .driver_info = (kernel_ulong_t) FW_0489_E031 },
+ { USB_DEVICE(0x0489, 0xe031), .driver_info = (kernel_ulong_t) &firmware[3] },
/* Lenovo */
- { USB_DEVICE(0x0a5c, 0x21e6), .driver_info = (kernel_ulong_t) FW_0A5C_21E6 },
- { USB_DEVICE(0x0a5c, 0x21f3), .driver_info = (kernel_ulong_t) FW_0A5C_21F3 },
- { USB_DEVICE(0x0a5c, 0x21f4), .driver_info = (kernel_ulong_t) FW_0A5C_21F4 },
+ { USB_DEVICE(0x0a5c, 0x21e6), .driver_info = (kernel_ulong_t) &firmware[4] },
+ { USB_DEVICE(0x0a5c, 0x21f3), .driver_info = (kernel_ulong_t) &firmware[5] },
+ { USB_DEVICE(0x0a5c, 0x21f4), .driver_info = (kernel_ulong_t) &firmware[6] },
};
#define BTUSB_MAX_ISOC_FRAMES 10
@@ -953,14 +969,27 @@ static inline void load_patchram_fw(struct usb_device *udev, const struct usb_de
{
size_t pos = 0;
int err = 0;
- const struct firmware *fw;
+ struct firmware_cache *fwcache;
unsigned char reset_cmd[] = { 0x03, 0x0c, 0x00 };
unsigned char download_cmd[] = { 0x2e, 0xfc, 0x00 };
- if (request_firmware(&fw, (const char *) id->driver_info, &udev->dev) < 0) {
- BT_INFO("can't load firmware, may not work correctly");
- return;
+ fwcache = (struct firmware_cache *)id->driver_info;
+ if (!fwcache->data) {
+ const struct firmware *fw;
+ if (request_firmware(&fw, fwcache->filename, &udev->dev) < 0) {
+ BT_INFO("can't load firmware, may not work correctly");
+ return;
+ }
+ fwcache->data = kmalloc(fw->size, GFP_KERNEL);
+ if (!fwcache->data) {
+ BT_INFO("OOM");
+ release_firmware(fw);
+ return;
+ }
+ fwcache->size = fw->size;
+ memcpy(fwcache->data, fw->data, fwcache->size);
+ release_firmware(fw);
}
if (usb_control_msg(udev, usb_sndctrlpipe(udev, 0), 0, USB_TYPE_CLASS, 0, 0,
@@ -977,12 +1006,12 @@ static inline void load_patchram_fw(struct usb_device *udev, const struct usb_de
}
msleep(300);
- while (pos < fw->size) {
+ while (pos < fwcache->size) {
size_t len;
- len = fw->data[pos + 2] + 3;
- if ((pos + len > fw->size) ||
+ len = fwcache->data[pos + 2] + 3;
+ if ((pos + len > fwcache->size) ||
(usb_control_msg(udev, usb_sndctrlpipe(udev, 0), 0,
- USB_TYPE_CLASS, 0, 0, (void *)fw->data + pos, len,
+ USB_TYPE_CLASS, 0, 0, (void *)(fwcache->data + pos), len,
PATCHRAM_TIMEOUT) < 0)) {
err = -1;
goto out;
@@ -995,7 +1024,6 @@ static inline void load_patchram_fw(struct usb_device *udev, const struct usb_de
out:
if (err)
BT_INFO("fail to load firmware, may not work correctly");
- release_firmware(fw);
}
static int btusb_probe(struct usb_interface *intf,
@@ -1326,7 +1354,22 @@ static struct usb_driver btusb_driver = {
.disable_hub_initiated_lpm = 1,
};
-module_usb_driver(btusb_driver);
+static int __init btusb_init(void)
+{
+ return usb_register(&btusb_driver);
+}
+
+static void __exit btusb_exit(void)
+{
+ int i;
+ for (i = 0; i < sizeof(firmware) / sizeof(firmware[0]); i++)
+ if (firmware[i].data)
+ kfree(firmware[i].data);
+ usb_deregister(&btusb_driver);
+}
+
+module_init(btusb_init);
+module_exit(btusb_exit);
module_param(ignore_dga, bool, 0644);
MODULE_PARM_DESC(ignore_dga, "Ignore devices with id 08fd:0001");
^ permalink raw reply related
* [RFC][PATCH 1/2] Implement broadcom patchram firmware loader
From: Jesse Sung @ 2012-08-14 14:24 UTC (permalink / raw)
To: linux-bluetooth
In-Reply-To: <cover.1344952391.git.jesse.sung@canonical.com>
[-- Attachment #1: Type: text/plain, Size: 44 bytes --]
This is a multi-part message in MIME format.
[-- Attachment #2: Type: text/plain, Size: 200 bytes --]
Signed-off-by: Wen-chien Jesse Sung <jesse.sung@canonical.com>
---
drivers/bluetooth/btusb.c | 109 ++++++++++++++++++++++++++++++++++++++++++---
1 file changed, 103 insertions(+), 6 deletions(-)
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #3: 0001-Implement-broadcom-patchram-firmware-loader.patch --]
[-- Type: text/x-patch; name="0001-Implement-broadcom-patchram-firmware-loader.patch", Size: 5096 bytes --]
diff --git a/drivers/bluetooth/btusb.c b/drivers/bluetooth/btusb.c
index cef3bac..b60a2ae 100644
--- a/drivers/bluetooth/btusb.c
+++ b/drivers/bluetooth/btusb.c
@@ -23,6 +23,8 @@
#include <linux/module.h>
#include <linux/usb.h>
+#include <linux/delay.h>
+#include <linux/firmware.h>
#include <net/bluetooth/bluetooth.h>
#include <net/bluetooth/hci_core.h>
@@ -47,6 +49,7 @@ static struct usb_driver btusb_driver;
#define BTUSB_BROKEN_ISOC 0x20
#define BTUSB_WRONG_SCO_MTU 0x40
#define BTUSB_ATH3012 0x80
+#define BTUSB_BCM_PATCHRAM 0x100
static struct usb_device_id btusb_table[] = {
/* Generic Bluetooth USB device */
@@ -93,13 +96,16 @@ static struct usb_device_id btusb_table[] = {
{ USB_DEVICE(0x0c10, 0x0000) },
/* Broadcom BCM20702A0 */
+ { USB_DEVICE(0x0489, 0xe031), .driver_info = BTUSB_BCM_PATCHRAM },
{ USB_DEVICE(0x0489, 0xe042) },
+ { USB_DEVICE(0x0a5c, 0x21d3), .driver_info = BTUSB_BCM_PATCHRAM },
+ { USB_DEVICE(0x0a5c, 0x21d7), .driver_info = BTUSB_BCM_PATCHRAM },
{ USB_DEVICE(0x0a5c, 0x21e3) },
- { USB_DEVICE(0x0a5c, 0x21e6) },
+ { USB_DEVICE(0x0a5c, 0x21e6), .driver_info = BTUSB_BCM_PATCHRAM },
{ USB_DEVICE(0x0a5c, 0x21e8) },
- { USB_DEVICE(0x0a5c, 0x21f3) },
- { USB_DEVICE(0x0a5c, 0x21f4) },
- { USB_DEVICE(0x413c, 0x8197) },
+ { USB_DEVICE(0x0a5c, 0x21f3), .driver_info = BTUSB_BCM_PATCHRAM },
+ { USB_DEVICE(0x0a5c, 0x21f4), .driver_info = BTUSB_BCM_PATCHRAM },
+ { USB_DEVICE(0x413c, 0x8197), .driver_info = BTUSB_BCM_PATCHRAM },
/* Foxconn - Hon Hai */
{ USB_DEVICE(0x0489, 0xe033) },
@@ -195,6 +201,37 @@ static struct usb_device_id blacklist_table[] = {
{ } /* Terminating entry */
};
+#define PATCHRAM_TIMEOUT 1000
+#define FW_0489_E031 "fw-0489_e031.hcd"
+#define FW_0A5C_21D3 "fw-0a5c_21d3.hcd"
+#define FW_0A5C_21D7 "fw-0a5c_21d7.hcd"
+#define FW_0A5C_21E6 "fw-0a5c_21e6.hcd"
+#define FW_0A5C_21F3 "fw-0a5c_21f3.hcd"
+#define FW_0A5C_21F4 "fw-0a5c_21f4.hcd"
+#define FW_413C_8197 "fw-413c_8197.hcd"
+
+MODULE_FIRMWARE(FW_0489_E031);
+MODULE_FIRMWARE(FW_0A5C_21D3);
+MODULE_FIRMWARE(FW_0A5C_21D7);
+MODULE_FIRMWARE(FW_0A5C_21E6);
+MODULE_FIRMWARE(FW_0A5C_21F3);
+MODULE_FIRMWARE(FW_0A5C_21F4);
+MODULE_FIRMWARE(FW_413C_8197);
+
+static struct usb_device_id patchram_table[] = {
+ /* Dell DW1704 */
+ { USB_DEVICE(0x0a5c, 0x21d3), .driver_info = (kernel_ulong_t) FW_0A5C_21D3 },
+ { USB_DEVICE(0x0a5c, 0x21d7), .driver_info = (kernel_ulong_t) FW_0A5C_21D7 },
+ /* Dell DW380 */
+ { USB_DEVICE(0x413c, 0x8197), .driver_info = (kernel_ulong_t) FW_413C_8197 },
+ /* FoxConn Hon Hai */
+ { USB_DEVICE(0x0489, 0xe031), .driver_info = (kernel_ulong_t) FW_0489_E031 },
+ /* Lenovo */
+ { USB_DEVICE(0x0a5c, 0x21e6), .driver_info = (kernel_ulong_t) FW_0A5C_21E6 },
+ { USB_DEVICE(0x0a5c, 0x21f3), .driver_info = (kernel_ulong_t) FW_0A5C_21F3 },
+ { USB_DEVICE(0x0a5c, 0x21f4), .driver_info = (kernel_ulong_t) FW_0A5C_21F4 },
+};
+
#define BTUSB_MAX_ISOC_FRAMES 10
#define BTUSB_INTR_RUNNING 0
@@ -912,6 +949,55 @@ static void btusb_waker(struct work_struct *work)
usb_autopm_put_interface(data->intf);
}
+static inline void load_patchram_fw(struct usb_device *udev, const struct usb_device_id *id)
+{
+ size_t pos = 0;
+ int err = 0;
+ const struct firmware *fw;
+
+ unsigned char reset_cmd[] = { 0x03, 0x0c, 0x00 };
+ unsigned char download_cmd[] = { 0x2e, 0xfc, 0x00 };
+
+ if (request_firmware(&fw, (const char *) id->driver_info, &udev->dev) < 0) {
+ BT_INFO("can't load firmware, may not work correctly");
+ return;
+ }
+
+ if (usb_control_msg(udev, usb_sndctrlpipe(udev, 0), 0, USB_TYPE_CLASS, 0, 0,
+ reset_cmd, sizeof(reset_cmd), PATCHRAM_TIMEOUT) < 0) {
+ err = -1;
+ goto out;
+ }
+ msleep(300);
+
+ if (usb_control_msg(udev, usb_sndctrlpipe(udev, 0), 0, USB_TYPE_CLASS, 0, 0,
+ download_cmd, sizeof(download_cmd), PATCHRAM_TIMEOUT) < 0) {
+ err = -1;
+ goto out;
+ }
+ msleep(300);
+
+ while (pos < fw->size) {
+ size_t len;
+ len = fw->data[pos + 2] + 3;
+ if ((pos + len > fw->size) ||
+ (usb_control_msg(udev, usb_sndctrlpipe(udev, 0), 0,
+ USB_TYPE_CLASS, 0, 0, (void *)fw->data + pos, len,
+ PATCHRAM_TIMEOUT) < 0)) {
+ err = -1;
+ goto out;
+ }
+ pos += len;
+ }
+
+ err = (usb_control_msg(udev, usb_sndctrlpipe(udev, 0), 0, USB_TYPE_CLASS, 0, 0,
+ reset_cmd, sizeof(reset_cmd), PATCHRAM_TIMEOUT) < 0);
+out:
+ if (err)
+ BT_INFO("fail to load firmware, may not work correctly");
+ release_firmware(fw);
+}
+
static int btusb_probe(struct usb_interface *intf,
const struct usb_device_id *id)
{
@@ -1076,15 +1162,26 @@ static int btusb_probe(struct usb_interface *intf,
}
}
+ usb_set_intfdata(intf, data);
+
+ if (id->driver_info & BTUSB_BCM_PATCHRAM) {
+ const struct usb_device_id *match;
+ match = usb_match_id(intf, patchram_table);
+ if (match) {
+ btusb_open(hdev);
+ load_patchram_fw(interface_to_usbdev(intf), match);
+ btusb_close(hdev);
+ }
+ }
+
err = hci_register_dev(hdev);
if (err < 0) {
hci_free_dev(hdev);
+ usb_set_intfdata(intf, NULL);
kfree(data);
return err;
}
- usb_set_intfdata(intf, data);
-
return 0;
}
^ permalink raw reply related
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