linux.git/drivers/bluetooth/btbcm.c, branch v5.13

Bluetooth: btbcm: Added 003.006.007, changed 001.003.015

2020-05-28T08:28:12+00:00

Added new Broadcom device BCM4350C5, changed BCM4354A2 to BCM4356A2.

Based on Broadcom Windows drivers 001.003.015 should be BCM4356A2. I
have user report that firmware name is misplaced
(https://github.com/winterheart/broadcom-bt-firmware/issues/3).

Signed-off-by: Azamat H. Hackimov 
Signed-off-by: Marcel Holtmann

Bluetooth: btbcm: Add 2 missing models to subver tables

2020-04-22T17:43:59+00:00

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

Bluetooth: btbcm: Try multiple Patch filenames when loading the Patch firmware

2020-04-22T17:43:58+00:00

Currently the bcm_uart_subver_ and bcm_usb_subver_table-s lack entries
for various newer 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 a problem with
UART attached devices where this leads to the filename being "BCM.hcd".

If we add new entries to the subver-tables now, then this will change
what firmware file the kernel looks for, e.g. currently linux-firmware
contains a brcm/BCM-0bb4-0306.hcd file. If we add the info for the
BCM20703A1 to the subver table, then this will change to
brcm/BCM20703A1-0bb4-0306.hcd. This will cause the file to no longer
get loaded breaking Bluetooth for existing users, going against the
no regressions policy.

To avoid this regression make the btbcm code try multiple filenames,
first try the fullname, e.g. BCM20703A1-0bb4-0306.hcd and if that is
not found, then fallback to the name with just BCM as prefix.

This commit also adds an info message which filename was used,
this makes the output look like this for example:

[   57.387867] Bluetooth: hci0: BCM20703A1
[   57.387870] Bluetooth: hci0: BCM20703A1 (001.001.005) build 0000
[   57.389438] Bluetooth: hci0: BCM20703A1 'brcm/BCM20703A1-0a5c-6410.hcd' Patch
[   58.681769] Bluetooth: hci0: BCM20703A1 Generic USB 20Mhz fcbga_BU
[   58.681772] Bluetooth: hci0: BCM20703A1 (001.001.005) build 0481

Signed-off-by: Hans de Goede 
Signed-off-by: Marcel Holtmann

Bluetooth: btbcm: Bail sooner from btbcm_initialize() when not loading fw

2020-04-22T17:43:58+00:00

If we have already loaded the firmware/patchram and btbcm_initialize()
is called to re-init the HCI after this then there is no need to get
the USB device-ids and build a firmware-filename out of these.

Signed-off-by: Hans de Goede 
Signed-off-by: Marcel Holtmann

Bluetooth: btbcm: Make btbcm_setup_patchram use btbcm_finalize

2020-04-22T17:43:58+00:00

On UART attached devices we do:

1. btbcm_initialize()
2. Setup UART baudrate, etc.
3. btbcm_finalize()

After our previous changes we can now also use btbcm_finalize() from
the btbcm_setup_patchram() function used on USB devices without any
functional changes. This completes unifying the USB and UART paths
as much as possible.

Signed-off-by: Hans de Goede 
Signed-off-by: Marcel Holtmann

Bluetooth: btbcm: Make btbcm_initialize() print local-name on re-init too

2020-04-22T17:43:58+00:00

Make btbcm_initialize() get and print the device's local-name on re-init
too, this will make us also print the local-name after loading the
Patch on UART attached devices making things more consistent.

This also removes some code duplication from btbcm_setup_patchram()
and allows more code duplication removal there in a follow-up patch.

Signed-off-by: Hans de Goede 
Signed-off-by: Marcel Holtmann

Bluetooth: btbcm: Fold Patch loading + applying into btbcm_initialize()

2020-04-22T17:43:58+00:00

Instead of having btbcm_initialize() fill a passed in fw_name buffer
and then have its callers use that to request the firmware + load
it into the HCI, make btbcm_initialize() do this itself the first
time it is called (its get called a second time to reset the HCI
after the firmware has been loaded).

This removes some code duplication and makes it easier for further
patches in this series to try more then 1 firmware filename.

Signed-off-by: Hans de Goede 
Signed-off-by: Marcel Holtmann

Bluetooth: btbcm: Move setting of USE_BDADDR_PROPERTY quirk to hci_bcm.c

2020-04-22T17:43:58+00:00

btbcm_finalize() is currently only used by UART attached BCM devices.

Move the setting of the USE_BDADDR_PROPERTY quirk, which we only want
for UART attached devices to hci_bcm in preparation for using
btbcm_finalize() for USB attached devices too.

Signed-off-by: Hans de Goede 
Signed-off-by: Marcel Holtmann

Bluetooth: btbcm: Drop upper nibble version check from btbcm_initialize()

2020-04-22T17:43:58+00:00

btbcm_initialize() must either return an error; or fill the passed in
fw_name, otherwise we end up passing uninitialized stack memory to
request_firmware().

Since we have a fallback hw_name of "BCM" not having a known version
in the subver field does not matter, drop the check so that we always
fill the passed in fw_name.

Signed-off-by: Hans de Goede 
Signed-off-by: Marcel Holtmann

Bluetooth: btbcm : Fix warning about missing blank lines after declarations

2020-01-09T20:24:47+00:00

This patches fixes two warnings of checkpatch.pl, both of the type
WARNING: Missing a blank line after declarations

Signed-off-by: Changqi Du 
Signed-off-by: Marcel Holtmann