Bluetooth: btusb: Add support for Dynex/Insignia USB dongles

The Dynex/Insignia USB dongles are Broadcom BCM20702B0 based and require
firmware update before operation.

T:  Bus=01 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#=  2 Spd=12   MxCh= 0
D:  Ver= 2.00 Cls=ff(vend.) Sub=01 Prot=01 MxPS=64 #Cfgs=  1
P:  Vendor=19ff ProdID=0239 Rev= 1.12
S:  Manufacturer=Broadcom Corp
S:  Product=BCM20702A0
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
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=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=ff(vend.) 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=ff(vend.) 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=ff(vend.) 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=ff(vend.) 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=ff(vend.) 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
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)

Since this is an unsual USB vendor ID (0x19ff), these dongles are added
via USB_DEVICE macro and not USB_VENDOR_AND_INTERFACE_INFO as done for
mainstream Broadcom based dongles.

The latest known working firmware is BCM20702B0_002.001.014.0527.0557.hex
which needs to be converted using hex2hcd utility and then installed
as /lib/firmware/brcm/BCM20702A0-19ff-0239.hcd to make this device fully
operational.

Bluetooth: hci0: BCM: patching hci_ver=06 hci_rev=2000 lmp_ver=06 lmp_subver=410e
Bluetooth: hci0: BCM: firmware hci_ver=06 hci_rev=222d lmp_ver=06 lmp_subver=410e

With this firmware the device reports support for connectionless slave
broadcast (master and slave) feature used by 3D Glasses and TVs.

  < HCI Command: Read Local Extended Features (0x04|0x0004) plen 1
          Page: 2
  > HCI Event: Command Complete (0x0e) plen 14
        Read Local Extended Features (0x04|0x0004) ncmd 1
          Status: Success (0x00)
          Page: 2/2
          Features: 0x0f 0x00 0x00 0x00 0x00 0x00 0x00 0x00
            Connectionless Slave Broadcast - Master
            Connectionless Slave Broadcast - Slave
            Synchronization Train
            Synchronization Scan

However there are some flaws with this feature. The Set Event Mask Page 2
command is actually not supported and with that all connectionless slave
broadcast events are always enabled.

  < HCI Command: Set Event Mask Page 2 (0x03|0x0063) plen 8
          Mask: 0x00000000000f0000
            Synchronization Train Received
            Connectionless Slave Broadcast Receive
            Connectionless Slave Broadcast Timeout
            Truncated Page Complete
  > HCI Event: Command Complete (0x0e) plen 4
        Set Event Mask Page 2 (0x03|0x0063) ncmd 1
          Status: Unknown HCI Command (0x01)

In addition the Synchronization Train Received event is actually broken
on this controller. It mixes up the order of parameters. According to the
Bluetooth Core specification the fields are like this:

  struct hci_ev_sync_train_received {
          __u8     status;
          bdaddr_t bdaddr;
          __le32   offset;
          __u8     map[10];
          __u8     lt_addr;
          __le32   instant;
          __le16   interval;
          __u8     service_data;
  } __packed;

This controller however sends the service_data as 5th parameter instead
of having it as last parameter.

  struct hci_ev_sync_train_received {
          __u8     status;
          bdaddr_t bdaddr;
          __le32   offset;
          __u8     map[10];
          __u8     service_data;
          __u8     lt_addr;
          __le32   instant;
          __le16   interval;
  } __packed;

So anybody trying to use this hardware for utilizing connectionless slave
broadcast receivers (aka 3D Glasses), be warned about this shortcoming.

Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Cc: stable@vger.kernel.org
1 file changed