summaryrefslogtreecommitdiffstats
path: root/drivers/bluetooth/btbcm.c (follow)
Commit message (Collapse)AuthorAgeFilesLines
* Bluetooth: btbcm: add patch ram for bluetoothAngus Ainslie2021-08-161-0/+1
| | | | | | | Bluetooth on the BCM43752 needs a patchram file to function correctly. Signed-off-by: Angus Ainslie <angus@akkea.ca> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
* Bluetooth: btbcm: Add entry for BCM43430B0 UART BluetoothMikhail Rudenko2021-06-261-0/+1
| | | | | | | | | This patch adds the device ID for the BCM43430B0 module, found e.g. in certain revisions of AMPAK AP6212 chip. The required firmware file is named 'BCM43430B0.hcd'. Signed-off-by: Mikhail Rudenko <mike.rudenko@gmail.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
* Bluetooth: btbcm: Added 003.006.007, changed 001.003.015Azamat H. Hackimov2020-05-281-1/+2
| | | | | | | | | | | 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 <azamat.hackimov@gmail.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
* Bluetooth: btbcm: Add 2 missing models to subver tablesHans de Goede2020-04-221-0/+2
| | | | | | | | | | | | | | | | | | | | 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 <hdegoede@redhat.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
* Bluetooth: btbcm: Try multiple Patch filenames when loading the Patch firmwareHans de Goede2020-04-221-16/+43
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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 <hdegoede@redhat.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
* Bluetooth: btbcm: Bail sooner from btbcm_initialize() when not loading fwHans de Goede2020-04-221-7/+7
| | | | | | | | | 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 <hdegoede@redhat.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
* Bluetooth: btbcm: Make btbcm_setup_patchram use btbcm_finalizeHans de Goede2020-04-221-19/+8
| | | | | | | | | | | | | | | | 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 <hdegoede@redhat.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
* Bluetooth: btbcm: Make btbcm_initialize() print local-name on re-init tooHans de Goede2020-04-221-9/+10
| | | | | | | | | | | | 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 <hdegoede@redhat.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
* Bluetooth: btbcm: Fold Patch loading + applying into btbcm_initialize()Hans de Goede2020-04-221-20/+30
| | | | | | | | | | | | | | 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 <hdegoede@redhat.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
* Bluetooth: btbcm: Move setting of USE_BDADDR_PROPERTY quirk to hci_bcm.cHans de Goede2020-04-221-6/+0
| | | | | | | | | | | 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 <hdegoede@redhat.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
* Bluetooth: btbcm: Drop upper nibble version check from btbcm_initialize()Hans de Goede2020-04-221-4/+0
| | | | | | | | | | | | | 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 <hdegoede@redhat.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
* Bluetooth: btbcm : Fix warning about missing blank lines after declarationsChangqi Du2020-01-091-0/+2
| | | | | | | | This patches fixes two warnings of checkpatch.pl, both of the type WARNING: Missing a blank line after declarations Signed-off-by: Changqi Du <d.changqi@gmail.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
* Bluetooth: btbcm: Support pcm configurationAbhishek Pandit-Subedi2019-11-271-0/+46
| | | | | | | | | | | | | | | | | | | | | | | | | | | | 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 01 Signed-off-by: Abhishek Pandit-Subedi <abhishekpandit@chromium.org> Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
* Bluetooth: btbcm: Use the BDADDR_PROPERTY quirkAndre Heider2019-11-221-0/+6
| | | | | | | | | | 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 <a.heider@gmail.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
* Bluetooth: btbcm: Add entry for BCM4335A0 UART bluetoothMohammad Rasim2019-11-211-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | 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 <mohammad.rasim96@gmail.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
* Bluetooth: btbcm: Add entry for BCM4334B0 UART BluetoothStephan Gerhold2019-11-191-0/+3
| | | | | | | | | | | 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 <stephan@gerhold.net> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
* bluetooth: bcm: Add support for loading firmware for BCM4345C5Ondrej Jirman2019-09-051-0/+3
| | | | | | | Detect BCM4345C5 and load a corresponding firmware file. Signed-off-by: Ondrej Jirman <megous@megous.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
* Bluetooth: btbcm: Add entry for BCM4359C0 UART bluetoothNeil Armstrong2019-07-061-0/+1
| | | | | | | | | | 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 <narmstrong@baylibre.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
* treewide: Replace GPLv2 boilerplate/reference with SPDX - rule 156Thomas Gleixner2019-05-301-16/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | 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 usa extracted 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 <tglx@linutronix.de> Reviewed-by: Allison Randal <allison@lohutok.net> Reviewed-by: Richard Fontana <rfontana@redhat.com> Cc: linux-spdx@vger.kernel.org Link: https://lkml.kernel.org/r/20190527070033.113240726@linutronix.de Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* Bluetooth: btbcm: Add default address for BCM2076B1Stephan Gerhold2019-05-051-0/+5
| | | | | | | | | | | | | 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 <stephan@gerhold.net> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
* Bluetooth: btbcm: Add entry for BCM2076B1 UART BluetoothStephan Gerhold2019-04-231-0/+1
| | | | | | | | 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 <stephan@gerhold.net> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
* Bluetooth: btbcm: Add default address for BCM43341BFerry Toth2019-04-231-1/+3
| | | | | | | | | | | | | | | | | | | | 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 <andriy.shevchenko@linux.intel.com> Signed-off-by: Ferry Toth <ftoth@exalondelft.nl> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
* Bluetooth: btbcm: Add entry for BCM4329B1 UART bluetoothPaweł Chmiel2018-12-191-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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 <pawel.mikolaj.chmiel@gmail.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
* Bluetooth: btbcm: Add default address for BCM43430A0Chen-Yu Tsai2018-12-191-1/+6
| | | | | | | | | | | | | | 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 <wens@csie.org> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
* Bluetooth: hci_bcm: Add BCM20702A1 variantMaxime Ripard2018-12-191-0/+6
| | | | | | | | | | 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 <maxime.ripard@bootlin.com> Tested-by: Ondrej Jirman <megous@megous.com> Signed-off-by: Chen-Yu Tsai <wens@csie.org> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
* Bluetooth: btbcm: Add entry for BCM4335C0 UART bluetoothChristian Hewitt2018-09-271-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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 <christianshewitt@gmail.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
* Bluetooth: btbcm: btbcm_initialize(): Initialize hw_name to "BCM"Hans de Goede2018-05-181-5/+4
| | | | | | | | 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 <hdegoede@redhat.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
* Bluetooth: btbcm: Remove duplicate code from btbcm_setup_patchram()Hans de Goede2018-05-181-73/+5
| | | | | | | | | | 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 <hdegoede@redhat.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
* Bluetooth: btbcm: Allow using btbcm_initialize() for reinitHans de Goede2018-05-181-23/+10
| | | | | | | | | | | | 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 <hdegoede@redhat.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
* Bluetooth: btbcm: Make btbcm_initialize() also work for USB connected devicesHans de Goede2018-05-181-29/+43
| | | | | | | | | | 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 <hdegoede@redhat.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
* Bluetooth: btbcm: Factor out common code to determine subversionHans de Goede2018-05-181-22/+18
| | | | | | | | | | 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 <hdegoede@redhat.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
* Bluetooth: btbcm: Stop using upper nibble of rev to chose between uart/USB pathsHans de Goede2018-05-181-9/+6
| | | | | | | | | | | | | | | | 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 <hdegoede@redhat.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
* Bluetooth: btbcm: Add entry for BCM4343A0 UART bluetoothJörg Krause2018-01-181-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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 <joerg.krause@embedded.rocks> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
* Bluetooth: Use bt_dev_err and bt_dev_info when possibleMarcel Holtmann2017-10-301-53/+50
| | | | | | | | | 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 <marcel@holtmann.org> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
* Bluetooth: btbcm: Add entry for BCM4356A2 UART bluetoothHans de Goede2017-10-141-0/+2
| | | | | | | | | | | | | 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 <hdegoede@redhat.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
* Bluetooth: btbcm: Add support for MINIX Z83-4 based devicesIan W MORRISON2017-10-101-0/+1
| | | | | | | | | | | 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 <ianwmorrison@gmail.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
* Bluetooth: btbcm: Consolidate the controller information commandsMarcel Holtmann2017-08-171-30/+39
| | | | | | | | | 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 <marcel@holtmann.org> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
* Bluetooth: btbcm: Add entry for BCM43430 UART bluetoothIan Molton2017-06-291-0/+1
| | | | | | | | | | | 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 <ian@mnementh.co.uk> Reported-by: Loic Poulain <loic.poulain@intel.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
* Bluetooth: btbcm: Read controller features during configurationMarcel Holtmann2017-06-121-0/+36
| | | | | | | | | | | | | | | | | 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-PLC Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Szymon Janc <szymon.janc@codecoup.pl>
* Bluetooth: btbcm: Add a delay for module resetWen-chien Jesse Sung2017-02-161-0/+3
| | | | | | | | | | | 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 <jesse.sung@canonical.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
* Bluetooth: btbcm: Fix handling of firmware not foundPetri Gynther2016-02-231-1/+2
| | | | | | | | | | | 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 <pgynther@google.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
* Bluetooth: btbcm: Read USB product information for Apple devicesMarcel Holtmann2015-10-211-0/+9
| | | | | | | | 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 <marcel@holtmann.org> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
* Bluetooth: btbcm: Fix firmware version number calculationMarcel Holtmann2015-10-211-4/+4
| | | | | | | The calculation for the firmware version number is off by one bit. Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
* Bluetooth: btbcm: Read the local name in setup stageMarcel Holtmann2015-10-071-0/+44
| | | | | | | | | | | | | | The Broadcom Bluetooth controllers have the chip name included in the ROM firmware or later in the patchram firmware. For debugging purposes read the local name and print it out. This is only done during setup stage and only once before loading the firmware and once after loading the firmware. For the Broadcom based controllers from Apple, the name is only read once after determining the chip id. Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
* Bluetooth: btbcm: Send HCI Reset before sending Apple specific commandsMarcel Holtmann2015-10-051-2/+8
| | | | | | | | | | | | | | The commit 7bee8b08c428 allows the Read Verbose Config Info to fail gracefully and not cause the controller setup to abort. It seems the reason that command failed in the first place was the missing HCI Reset to bring the controller in full Bluetooth mode. Apple Bluetooth controllers start out in HID mode and when in that mode the Read Verbose Config Info command is not allowed. Sending HCI Reset switches the controller into full HCI mode. Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
* Bluetooth: btbcm: Add BCM4330B1 UART deviceFrederic Danis2015-07-301-1/+7
| | | | | | | | Add "waiting for configuration" address. Add lmp_subver and firmware name for BCM4330B1 controller. Signed-off-by: Frederic Danis <frederic.danis@linux.intel.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
* Bluetooth: btbcm: allow btbcm_read_verbose_config to fail on AppleChris Mason2015-07-141-6/+5
| | | | | | | | | | | | | | | | Commit 1c8ba6d013 moved around the setup code for broadcomm chips, and also added btbcm_read_verbose_config() to read extra information about the hardware. It's returning errors on some macbooks: Bluetooth: hci0: BCM: Read verbose config info failed (-16) Which makes us error out of the setup function. Since this probe isn't critical to operate the chip, this patch just changes things to carry on when it fails. Signed-off-by: Chris Mason <clm@fb.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Cc: stable@vger.kernel.org # v4.1
* Bluetooth: btbcm: Support the BCM4354 Bluetooth UART deviceIlya Faenson2015-06-171-0/+2
| | | | | | | | Support the BCM4354 chip and introduce vendor specific command parameter definitions. Signed-off-by: Ilya Faenson <ifaenson@broadcom.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
* Bluetooth: btbcm: Add helper functions for UART setupFrederic Danis2015-06-061-0/+89
| | | | | | | | | | | | | | | | | | | | Firmware loading may reset the controller UART speed and needs to set host UART speed back to init speed. UART drivers setup is split in 3 parts: - btbcm_initialize() resets the controller and returns the firmware name based on controller revision and sub_version. - btbtcm_patchram() (already existing and public), which takes the firmware name as parameter, requests the firmware and loads it to the controller. - btbcm_finalize() which resets the controller, reads local version and checks if the controller address is a default one or not. Remove firmware name retrieval for UART controllers from btbcm_setup_patchram(). Signed-off-by: Frederic Danis <frederic.danis@linux.intel.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
* Bluetooth: btbcm: Add BCM4324B3 UART deviceFrederic Danis2015-06-061-2/+13
| | | | | | | | Add "waiting for configuration" address. Add lmp_subver and firmware name for BCM4324B3 controller. Signed-off-by: Frederic Danis <frederic.danis@linux.intel.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
generated by cgit v1.2.3 (git 2.39.1) at 2024-12-22 02:17:54 +0100