kernel/git/stable/linux-stable.git/drivers/bluetooth/btbcm.c, branch linux-4.19.y

Bluetooth: btbcm: Add 2 missing models to subver tables

2020-06-22T07:05:13+00:00

[ Upstream commit c03ee9af4e07112bd3fc688daca9e654f41eca93 ] Currently the bcm_uart_subver_ and bcm_usb_subver_table-s lack entries for the BCM4324B5 and BCM20703A1 chipsets. This makes the code use just "BCM" as prefix for the filename to pass to request-firmware, making it harder for users to figure out which firmware they need. This especially is problematic with the UART attached BCM4324B5 where this leads to the filename being just "BCM.hcd". Add the 2 missing devices to subver tables. This has been tested on: 1. A Dell XPS15 9550 where this makes btbcm.c try to load "BCM20703A1-0a5c-6410.hcd" before it tries to load "BCM-0a5c-6410.hcd". 2. A Thinkpad 8 where this makes btbcm.c try to load "BCM4324B5.hcd" before it tries to load "BCM.hcd" Signed-off-by: Hans de Goede Signed-off-by: Marcel Holtmann Signed-off-by: Sasha Levin

Bluetooth: btbcm: Add entry for BCM4335C0 UART bluetooth

2018-11-13T19:08:25+00:00

[ Upstream commit a357ea098c9605f60d92a66a9073f56ce25726da ] This patch adds the device ID for the AMPAK AP6335 combo module used in the 1st generation WeTek Hub Android/LibreELEC HTPC box. The WiFI chip identifies itself as BCM4339, while Bluetooth identifies itself as BCM4335 (rev C0): ``` [ 4.864248] Bluetooth: hci0: BCM: chip id 86 [ 4.866388] Bluetooth: hci0: BCM: features 0x2f [ 4.889317] Bluetooth: hci0: BCM4335C0 [ 4.889332] Bluetooth: hci0: BCM4335C0 (003.001.009) build 0000 [ 9.778383] Bluetooth: hci0: BCM4335C0 (003.001.009) build 0268 ``` Output from hciconfig: ``` hci0: Type: Primary Bus: UART BD Address: 43:39:00:00:1F:AC ACL MTU: 1021:8 SCO MTU: 64:1 UP RUNNING RX bytes:7567 acl:234 sco:0 events:386 errors:0 TX bytes:53844 acl:77 sco:0 commands:304 errors:0 Features: 0xbf 0xfe 0xcf 0xfe 0xdb 0xff 0x7b 0x87 Packet type: DM1 DM3 DM5 DH1 DH3 DH5 HV1 HV2 HV3 Link policy: RSWITCH SNIFF Link mode: SLAVE ACCEPT Name: 'HUB' Class: 0x0c0000 Service Classes: Rendering, Capturing Device Class: Miscellaneous, HCI Version: 4.0 (0x6) Revision: 0x10c LMP Version: 4.0 (0x6) Subversion: 0x6109 Manufacturer: Broadcom Corporation (15) ``` Signed-off-by: Christian Hewitt Signed-off-by: Marcel Holtmann Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman

Bluetooth: btbcm: btbcm_initialize(): Initialize hw_name to "BCM"

2018-05-18T04:37:51+00:00

Initialize hw_name to "BCM", this avoids the need for a number of NULL checks on hw_name later. Signed-off-by: Hans de Goede Signed-off-by: Marcel Holtmann

Bluetooth: btbcm: Remove duplicate code from btbcm_setup_patchram()

2018-05-18T04:37:51+00:00

btbcm_setup_patchram() starts with initializing the controller (and getting the firmware filename) and then after loading the firmware, does a re-init. This almost entirely duplicates the code in btbcm_initialize(), use that function instead. Signed-off-by: Hans de Goede Signed-off-by: Marcel Holtmann

Bluetooth: btbcm: Allow using btbcm_initialize() for reinit

2018-05-18T04:37:51+00:00

btbcm_finalize() does a re-init of the controller, which is almost the same as the initial init. Modify btbcm_initialize() so that it can be used for this re-init and modify btbcm_finalize() to use it. As an added bonus this also makes the dev_info from btbcm_finalize() use the proper hw_name instead of always printing "BCM". Signed-off-by: Hans de Goede Signed-off-by: Marcel Holtmann

Bluetooth: btbcm: Make btbcm_initialize() also work for USB connected devices

2018-05-18T04:37:51+00:00

Make btbcm_initialize() also work for USB connected device, btbcm_initialize() and btbcm_setup_patchram() are quite similar, this is a preparation patch for making btbcm_setup_patchram() use btbcm_initialize() to remove the code duplication. Signed-off-by: Hans de Goede Signed-off-by: Marcel Holtmann

Bluetooth: btbcm: Factor out common code to determine subversion

2018-05-18T04:37:51+00:00

We are using the same loop in both the UART and USB bus cases, refactor things a bit to share the loop. This is mostly meant to improve readability. Signed-off-by: Hans de Goede Signed-off-by: Marcel Holtmann

Bluetooth: btbcm: Stop using upper nibble of rev to chose between uart/USB paths

2018-05-18T04:37:51+00:00

btbcm_setup_patchram() was using the upper nibble of the revision code to determine if we are dealing with an uart or USB connected bcm-bt device, but just as btbcm_initialize() has started accepting 1 and 2 as uart connected devices, I've now encountered an USB connected device (0a5c:216c) which has 0 in the upper nibble. So it seems that the upper nibble is not really a reliable indicator of the bus type. Instead check hdev->bus which does give us a reliable indication. This fixes the patchram code trying to load the patchram by the fallback BCM.hcd filename, now it correctly requests BCM43142A0-0a5c-216c.hcd. Signed-off-by: Hans de Goede Signed-off-by: Marcel Holtmann

Bluetooth: btbcm: Add entry for BCM4343A0 UART bluetooth

2018-01-18T09:24:38+00:00

This patch adds the device ID for the bluetooth chip used in the AMPAK AP6212 WiFi+Bluetooth module. The AP6212 is used on several BananaPi boards, e.g. M2-Ultra. The AP6212 is a combo module, where the WiFi chip is identified as BCM43430A0 whereas the Bluetooth chip identifies itself as 4343A0. Note, the missing '0' before the 'A0'. The AP6212 needs a firmware blob. Loading the provided firmware file from the BananaPi vendor, the adapter name is printed as 'BCM4343A0 26MHz AP6212_CL1-0061': ''' hci0: Type: Primary Bus: UART BD Address: 43:43:A0:12:1F:AC ACL MTU: 1021:8 SCO MTU: 64:1 UP RUNNING RX bytes:3076 acl:0 sco:0 events:278 errors:0 TX bytes:39726 acl:0 sco:0 commands:279 errors:0 Features: 0xbf 0xfe 0xcf 0xfe 0xdb 0xff 0x7b 0x87 Packet type: DM1 DM3 DM5 DH1 DH3 DH5 HV1 HV2 HV3 Link policy: RSWITCH SNIFF Link mode: SLAVE ACCEPT Name: 'BCM4343A0 26MHz AP6212_CL1-0061' Class: 0x000000 Service Classes: Unspecified Device Class: Miscellaneous, HCI Version: 4.1 (0x7) Revision: 0xf2 LMP Version: 4.1 (0x7) Subversion: 0x2122 Manufacturer: Broadcom Corporation (15) ''' Signed-off-by: Jörg Krause Signed-off-by: Marcel Holtmann

Bluetooth: Use bt_dev_err and bt_dev_info when possible

2017-10-30T10:25:45+00:00

In case of using BT_ERR and BT_INFO, convert to bt_dev_err and bt_dev_info when possible. This allows for controller specific reporting. Signed-off-by: Marcel Holtmann Signed-off-by: Johan Hedberg