linux-kernel - Re: [bluetooth] linux-3.x regression (bisected)

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20111228155225.GA23292@joana>
Date:	Wed, 28 Dec 2011 13:52:25 -0200
From:	Gustavo Padovan <padovan@...fusion.mobi>
To:	Rene Herman <rene.herman@...il.com>
Cc:	Andre Guedes <andre.guedes@...nbossa.org>,
	linux-kernel@...r.kernel.org, linux-bluetooth@...r.kernel.org,
	Marcel Holtmann <marcel@...tmann.org>
Subject: Re: [bluetooth] linux-3.x regression (bisected)

Hi Rene,

* Rene Herman <rene.herman@...il.com> [2011-12-28 02:53:26 +0100]:

> On 28-12-11 02:28, Gustavo Padovan wrote:
> 
> >>For some reason your adapter is returning here the same value of
> >>Read Local Features. I would say your device is broken.  The only
> >>fix I have in mind now is throw away the device.
> >
> >Yes, I have one of these ISSC devices, it's completely broken
> >device.
> 
> It worked well upto and including 2.6.29 though.

We never used Extended Features before 2.6.39

> 
> This would seem to be the kind of thing other subsystems use quirk
> handling for. The device identifies itself as "1131:1004":
> 
> Bus 002 Device 002: ID 1131:1004 Integrated System Solution Corp.
> Bluetooth Device
> 
> Do you guys have infra-structure in place for adapter-specific
> (quitk) handling?

I think this patch can do handling, let's see what others think.

	Gustavo


---
Author: Gustavo F. Padovan <padovan@...fusion.mobi>
Date:   Wed Dec 28 13:40:02 2011 -0200

    Bluetooth: Fix lmp_host_le_capable() check for broken devices
    
    Some dongles reports a wrong Local Extended Features leading the kernel
    think that dongle support LE while it don't.
    
    The fix here is just rely on a bit in Local Features (LE Capable) to tell
    us if the device really supports LE.
    
    LE Host Capable is the only bit used from Local Extended Features in our
    kernel.
    
    Signed-off-by: Gustavo F. Padovan <padovan@...fusion.mobi>

diff --git a/include/net/bluetooth/hci_core.h b/include/net/bluetooth/hci_core.h
index 5e2e984..c693111 100644
--- a/include/net/bluetooth/hci_core.h
+++ b/include/net/bluetooth/hci_core.h
@@ -676,7 +676,11 @@ void hci_conn_del_sysfs(struct hci_conn *conn);
 #define lmp_le_capable(dev)        ((dev)->features[4] & LMP_LE)
 
 /* ----- Extended LMP capabilities ----- */
-#define lmp_host_le_capable(dev)   ((dev)->extfeatures[0] & LMP_HOST_LE)
+/* Some crap dongles does not report a proper Local Extended Features causing
+ * the kernel to wrongly init it as a LE device. So first check if it is LE
+ * capable (controller) which is a info from the Local Features */
+#define lmp_host_le_capable(dev)    ( lmp_le_capable(dev) && \
+                                       (dev)->extfeatures[0] & LMP_HOST_LE)
 
 /* ----- HCI protocols ----- */
 static inline int hci_proto_connect_ind(struct hci_dev *hdev, bdaddr_t *bdaddr,
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/