28 May, 2020
1 commit
-
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
23 Apr, 2020
8 commits
-
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 -
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 0481Signed-off-by: Hans de Goede
Signed-off-by: Marcel Holtmann -
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 -
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 -
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 -
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 -
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 -
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
10 Jan, 2020
1 commit
-
This patches fixes two warnings of checkpatch.pl, both of the type
WARNING: Missing a blank line after declarationsSigned-off-by: Changqi Du
Signed-off-by: Marcel Holtmann
27 Nov, 2019
1 commit
-
Add BCM vendor specific command to configure PCM parameters. The new
vendor opcode allows us to set the sco routing, the pcm interface rate,
and a few other pcm specific options (frame sync, sync mode, and clock
mode). See broadcom-bluetooth.txt in Documentation for more information
about valid values for those settings.Here is an example trace where this opcode was used to configure
a BCM4354:< HCI Command: Vendor (0x3f|0x001c) plen 5
01 02 00 01 01
> HCI Event: Command Complete (0x0e) plen 4
Vendor (0x3f|0x001c) ncmd 1
Status: Success (0x00)We can read back the values as well with ocf 0x001d to confirm the
values that were set:
$ hcitool cmd 0x3f 0x001d
< HCI Command: ogf 0x3f, ocf 0x001d, plen 0
> HCI Event: 0x0e plen 9
01 1D FC 00 01 02 00 01 01Signed-off-by: Abhishek Pandit-Subedi
Signed-off-by: Marcel Holtmann
Signed-off-by: Johan Hedberg
22 Nov, 2019
1 commit
-
Some devices ship with the controller default address, like the
Orange Pi 3 (BCM4345C5).Allow the bootloader to set a valid address through the device tree.
Signed-off-by: Andre Heider
Signed-off-by: Marcel Holtmann
21 Nov, 2019
1 commit
-
This patch adds the device ID for the BCM4335A0 module
(part of the AMPAK AP6335 WIFI/Bluetooth combo)hciconfig output:
```
hci1: Type: Primary Bus: UART
BD Address: 43:35:B0:07:1F:AC ACL MTU: 1021:8 SCO MTU: 64:1
UP RUNNING
RX bytes:5079 acl:0 sco:0 events:567 errors:0
TX bytes:69065 acl:0 sco:0 commands:567 errors:0
Features: 0xbf 0xfe 0xcf 0xff 0xdf 0xff 0x7b 0x87
Packet type: DM1 DM3 DM5 DH1 DH3 DH5 HV1 HV2 HV3
Link policy: RSWITCH SNIFF
Link mode: SLAVE ACCEPT
Name: 'alarm'
Class: 0x000000
Service Classes: Unspecified
Device Class: Miscellaneous,
HCI Version: 4.0 (0x6) Revision: 0x161
LMP Version: 4.0 (0x6) Subversion: 0x4106
Manufacturer: Broadcom Corporation (15)
```Signed-off-by: Mohammad Rasim
Signed-off-by: Marcel Holtmann
19 Nov, 2019
1 commit
-
Add the device ID for the WiFi/BT/FM combo chip BCM4334 (rev B0).
The chip seems to use 43:34:b0:00:00:00 as default address,
so add it to the list of default addresses and leave it up
to the user to configure a valid one.Signed-off-by: Stephan Gerhold
Signed-off-by: Marcel Holtmann
05 Sep, 2019
1 commit
-
Detect BCM4345C5 and load a corresponding firmware file.
Signed-off-by: Ondrej Jirman
Signed-off-by: Marcel Holtmann
06 Jul, 2019
1 commit
-
The BCM4359C0 BT/Wi-Fi compo chip needs an entry to be discovered
by the btbcm driver.Tested using an AP6398S module from Ampak.
Signed-off-by: Neil Armstrong
Signed-off-by: Marcel Holtmann
31 May, 2019
1 commit
-
Based on 1 normalized pattern(s):
this program is free software you can redistribute it and or modify
it under the terms of the gnu general public license as published by
the free software foundation either version 2 of the license or at
your option any later version this program is distributed in the
hope that it will be useful but without any warranty without even
the implied warranty of merchantability or fitness for a particular
purpose see the gnu general public license for more details you
should have received a copy of the gnu general public license along
with this program if not write to the free software foundation inc
59 temple place suite 330 boston ma 02111 1307 usaextracted by the scancode license scanner the SPDX license identifier
GPL-2.0-or-later
has been chosen to replace the boilerplate/reference in 1334 file(s).
Signed-off-by: Thomas Gleixner
Reviewed-by: Allison Randal
Reviewed-by: Richard Fontana
Cc: linux-spdx@vger.kernel.org
Link: https://lkml.kernel.org/r/20190527070033.113240726@linutronix.de
Signed-off-by: Greg Kroah-Hartman
06 May, 2019
1 commit
-
BCM2076B1 appears to use 20:76:A0:00:56:79 as default address.
This address is used by at least 5 devices with the AMPAK AP6476
module and is also suspicious because it starts with the chip name
2076 (followed by a different revision A0 for some reason).Add it to the list of default addresses and leave it up to the
user to configure a valid one.Signed-off-by: Stephan Gerhold
Signed-off-by: Marcel Holtmann
24 Apr, 2019
2 commits
-
Add the device ID for the BT/FM/GPS combo chip BCM2076 (rev B1)
used in the AMPAK AP6476 WiFi/BT/FM/GPS module.Signed-off-by: Stephan Gerhold
Signed-off-by: Marcel Holtmann -
The BCM43341B has the default MAC address 43:34:1B:00:1F:AC if none
is given. This address was found when enabling Bluetooth on multiple
Intel Edison modules. It also contains the sequence 43341B, the name
the chip identifies itself as. Using the same BD_ADDR is problematic
when having multiple Intel Edison modules in each others range.
The default address also has the LAA (locally administered address)
bit set which prevents a BNEP device from being created, needed for
BT tethering.Add this to the list of black listed default MAC addresses and let
the user configure a valid one using f.i.
`btmgmt -i hci0 public-addr xx:xx:xx:xx:xx:xx`Suggested-by: Andy Shevchenko
Signed-off-by: Ferry Toth
Reviewed-by: Andy Shevchenko
Signed-off-by: Marcel Holtmann
19 Dec, 2018
3 commits
-
This patch adds the device ID for the BCM 4329 combo module used
in the Samsung Aries based phones (Galaxy S and it's variants).```
[ 11.508980] Bluetooth: hci0: BCM: chip id 41
[ 11.518975] Bluetooth: hci0: BCM: features 0x04
[ 11.550132] Bluetooth: hci0: BCM4329B1
[ 11.557046] Bluetooth: hci0: BCM4329B1 (002.002.023) build 0000
[ 13.737071] Bluetooth: hci0: BCM4329B1 (002.002.023) build 0744
```Output from hciconfig
```
hci0: Type: Primary Bus: UART
BD Address: 43:29:B1:55:00:00 ACL MTU: 1021:6 SCO MTU: 64:1
UP RUNNING
RX bytes:1675 acl:0 sco:0 events:145 errors:0
TX bytes:20426 acl:0 sco:0 commands:146 errors:0
Features: 0xbf 0xfe 0x8f 0xfe 0x9b 0xff 0x79 0x83
Packet type: DM1 DM3 DM5 DH1 DH3 DH5 HV1 HV2 HV3
Link policy: RSWITCH SNIFF
Link mode: SLAVE ACCEPT
Name: 'aries'
Class: 0x000000
Service Classes: Unspecified
Device Class: Miscellaneous,
HCI Version: 2.1 (0x4) Revision: 0x2e8
LMP Version: 2.1 (0x4) Subversion: 0x4217
Manufacturer: Broadcom Corporation (15)
```Signed-off-by: Paweł Chmiel
Signed-off-by: Marcel Holtmann -
The BCM43430A0 has the default MAC address 43:43:A0:12:1F:AC if none
is given. This address was found when enabling Bluetooth on a bunch of
boards with the AMPAK AP6210 module, all sharing the same address. It
also contains the sequence 4343A0, which is suspicious as that is also
the name the chip identifies itself as.Add this to the list of default MAC addresses and leave it to the user
to configure a valid one.Signed-off-by: Chen-Yu Tsai
Signed-off-by: Marcel Holtmann -
The BCM20702A1 chip is a single-chip Bluetooth 4.0 controller and
transceiver. It is found in the AMPAK AP6210 WiFi+BT package.Signed-off-by: Maxime Ripard
Tested-by: Ondrej Jirman
Signed-off-by: Chen-Yu Tsai
Signed-off-by: Marcel Holtmann
27 Sep, 2018
1 commit
-
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
18 May, 2018
6 commits
-
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 -
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 -
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 -
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 -
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 -
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
18 Jan, 2018
1 commit
-
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
30 Oct, 2017
1 commit
-
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
14 Oct, 2017
1 commit
-
This patch adds the device ID for the bluetooth chip used in the
Broadcom BCM4356 PCI-E WiFi / UART BT chip.Successfully tested using Firmware version 0273
The upper nibble of the rev field is 2 on this device, so this commit
also adds handling of 2 to the switch-case done on the upper nibble.Signed-off-by: Hans de Goede
Signed-off-by: Marcel Holtmann
10 Oct, 2017
1 commit
-
The MINIX NEO Z83-4 and MINIX NEO Z83-4 Pro devices use an AP6255 chip
for wifi and bluetooth. Bluetooth requires an ACPI device id of BCM2EA4
with BCM4345 rev C0 firmware.This patch defines the firmware subversion.
Signed-off-by: Ian W MORRISON
Signed-off-by: Marcel Holtmann
17 Aug, 2017
1 commit
-
The commands that read the basic vendor information about the Broadcom
controller are duplicated for UART and USB devices. Combine them into a
single function to reduce the code complexity.Signed-off-by: Marcel Holtmann
Signed-off-by: Johan Hedberg
29 Jun, 2017
1 commit
-
This patch adds the device ID for the bluetooth chip used in the
Broadcom BCM43430 SDIO WiFi / UART BT chip.Successfully tested using Firmware version 0x0182
Signed-off-by: Ian Molton
Reported-by: Loic Poulain
Signed-off-by: Marcel Holtmann
12 Jun, 2017
1 commit
-
Read the Broadcom specific controller features during configuration and
print them for informational purposes.< HCI Command: Broadcom Read Controller Features (0x3f|0x006e) plen 0
> HCI Event: Command Complete (0x0e) plen 12
Broadcom Read Controller Features (0x3f|0x006e) ncmd 1
Status: Success (0x00)
Features: 0x07 0x00 0x00 0x00 0x00 0x00 0x00 0x00
Multi-AV transport bandwidth reducer
WBS SBC
FW LC-PLCSigned-off-by: Marcel Holtmann
Signed-off-by: Szymon Janc
17 Feb, 2017
1 commit
-
Some btbcm devices require more time to complete its reset process.
They won't reply any hci command until reset is done.[ 17.218554] Bluetooth: hci0 command 0x1001 tx timeout
[ 25.214999] Bluetooth: hci0: BCM: Reading local version info failed (-110)Signed-off-by: Wen-chien Jesse Sung
Signed-off-by: Marcel Holtmann
24 Feb, 2016
1 commit
-
If the call to request_firmware() fails in btbcm_setup_patchram(),
the BCM chip will be operating with its default firmware.In this case, btbcm_setup_patchram() should not return immediately
but instead should skip to btbcm_check_bdaddr() and quirk setup.Signed-off-by: Petri Gynther
Signed-off-by: Marcel Holtmann
21 Oct, 2015
1 commit
-
For the Apple Bluetooth devices, read the USB product information and
print them. This allows for easy mapping of chip and USB details.Signed-off-by: Marcel Holtmann
Signed-off-by: Johan Hedberg