iv/linux
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
0be27f7be2
linux/drivers/bluetooth/Kconfig

446 lines
13 KiB
Plaintext
Raw Normal View History

License cleanup: add SPDX GPL-2.0 license identifier to files with no license Many source files in the tree are missing licensing information, which makes it harder for compliance tools to determine the correct license. By default all files without license information are under the default license of the kernel, which is GPL version 2. Update the files which contain no license information with the 'GPL-2.0' SPDX license identifier. The SPDX identifier is a legally binding shorthand, which can be used instead of the full boiler plate text. This patch is based on work done by Thomas Gleixner and Kate Stewart and Philippe Ombredanne. How this work was done: Patches were generated and checked against linux-4.14-rc6 for a subset of the use cases: - file had no licensing information it it. - file was a */uapi/* one with no licensing information in it, - file was a */uapi/* one with existing licensing information, Further patches will be generated in subsequent months to fix up cases where non-standard license headers were used, and references to license had to be inferred by heuristics based on keywords. The analysis to determine which SPDX License Identifier to be applied to a file was done in a spreadsheet of side by side results from of the output of two independent scanners (ScanCode & Windriver) producing SPDX tag:value files created by Philippe Ombredanne. Philippe prepared the base worksheet, and did an initial spot review of a few 1000 files. The 4.13 kernel was the starting point of the analysis with 60,537 files assessed. Kate Stewart did a file by file comparison of the scanner results in the spreadsheet to determine which SPDX license identifier(s) to be applied to the file. She confirmed any determination that was not immediately clear with lawyers working with the Linux Foundation. Criteria used to select files for SPDX license identifier tagging was: - Files considered eligible had to be source code files. - Make and config files were included as candidates if they contained >5 lines of source - File already had some variant of a license header in it (even if <5 lines). All documentation files were explicitly excluded. The following heuristics were used to determine which SPDX license identifiers to apply. - when both scanners couldn't find any license traces, file was considered to have no license information in it, and the top level COPYING file license applied. For non */uapi/* files that summary was: SPDX license identifier # files ---------------------------------------------------|------- GPL-2.0 11139 and resulted in the first patch in this series. If that file was a */uapi/* path one, it was "GPL-2.0 WITH Linux-syscall-note" otherwise it was "GPL-2.0". Results of that was: SPDX license identifier # files ---------------------------------------------------|------- GPL-2.0 WITH Linux-syscall-note 930 and resulted in the second patch in this series. - if a file had some form of licensing information in it, and was one of the */uapi/* ones, it was denoted with the Linux-syscall-note if any GPL family license was found in the file or had no licensing in it (per prior point). Results summary: SPDX license identifier # files ---------------------------------------------------|------ GPL-2.0 WITH Linux-syscall-note 270 GPL-2.0+ WITH Linux-syscall-note 169 ((GPL-2.0 WITH Linux-syscall-note) OR BSD-2-Clause) 21 ((GPL-2.0 WITH Linux-syscall-note) OR BSD-3-Clause) 17 LGPL-2.1+ WITH Linux-syscall-note 15 GPL-1.0+ WITH Linux-syscall-note 14 ((GPL-2.0+ WITH Linux-syscall-note) OR BSD-3-Clause) 5 LGPL-2.0+ WITH Linux-syscall-note 4 LGPL-2.1 WITH Linux-syscall-note 3 ((GPL-2.0 WITH Linux-syscall-note) OR MIT) 3 ((GPL-2.0 WITH Linux-syscall-note) AND MIT) 1 and that resulted in the third patch in this series. - when the two scanners agreed on the detected license(s), that became the concluded license(s). - when there was disagreement between the two scanners (one detected a license but the other didn't, or they both detected different licenses) a manual inspection of the file occurred. - In most cases a manual inspection of the information in the file resulted in a clear resolution of the license that should apply (and which scanner probably needed to revisit its heuristics). - When it was not immediately clear, the license identifier was confirmed with lawyers working with the Linux Foundation. - If there was any question as to the appropriate license identifier, the file was flagged for further research and to be revisited later in time. In total, over 70 hours of logged manual review was done on the spreadsheet to determine the SPDX license identifiers to apply to the source files by Kate, Philippe, Thomas and, in some cases, confirmation by lawyers working with the Linux Foundation. Kate also obtained a third independent scan of the 4.13 code base from FOSSology, and compared selected files where the other two scanners disagreed against that SPDX file, to see if there was new insights. The Windriver scanner is based on an older version of FOSSology in part, so they are related. Thomas did random spot checks in about 500 files from the spreadsheets for the uapi headers and agreed with SPDX license identifier in the files he inspected. For the non-uapi files Thomas did random spot checks in about 15000 files. In initial set of patches against 4.14-rc6, 3 files were found to have copy/paste license identifier errors, and have been fixed to reflect the correct identifier. Additionally Philippe spent 10 hours this week doing a detailed manual inspection and review of the 12,461 patched files from the initial patch version early this week with: - a full scancode scan run, collecting the matched texts, detected license ids and scores - reviewing anything where there was a license detected (about 500+ files) to ensure that the applied SPDX license was correct - reviewing anything where there was no detection but the patch license was not GPL-2.0 WITH Linux-syscall-note to ensure that the applied SPDX license was correct This produced a worksheet with 20 files needing minor correction. This worksheet was then exported into 3 different .csv files for the different types of files to be modified. These .csv files were then reviewed by Greg. Thomas wrote a script to parse the csv files and add the proper SPDX tag to the file, in the format that the file expected. This script was further refined by Greg based on the output to detect more types of files automatically and to distinguish between header and source .c files (which need different comment types.) Finally Greg ran the script using the .csv files to generate the patches. Reviewed-by: Kate Stewart <kstewart@linuxfoundation.org> Reviewed-by: Philippe Ombredanne <pombredanne@nexb.com> Reviewed-by: Thomas Gleixner <tglx@linutronix.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2017-11-01 17:07:57 +03:00
# SPDX-License-Identifier: GPL-2.0
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-17 02:20:36 +04:00
menu "Bluetooth device drivers"
depends on BT
Bluetooth: btintel: Introduce generic Intel Bluetooth support The majority of Intel Bluetooth vendor commands are shared between USB and UART transports. This creates a separate module that eventually will hold all Intel specific commands, but for now just start with the commands to change the Bluetooth public address and check for the default address. Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
2015-04-06 10:52:11 +03:00
config BT_INTEL
tristate
Bluetooth: btintel: Add iBT register access over HCI support Add regmap ibt to support Intel Bluetooth silicon register access over HCI. Intel BT/FM combo chip allows to read/write some registers (e.g. FM registers) via its HCI interface. Read/Write operations are performed via a HCI transaction composed of a HCI command (host->controller) followed by a HCI command complete event (controller->host). Read/Write Command opcodes can be specified to the regmap init function. We define data formats which are intel/vendor specific. Register Read/Write HCI command payload (Host): Field: | REG ADDR | MODE | DATA_LEN | DATA... | size: | 32b | 8b | 8b | 8b* | Register Read HCI command complete event payload (Controller): Field: | CMD STATUS | REG ADDR | DATA... | size: | 8b | 32b | 8b* | Register Write HCI command complete event payload (Controller): Field: | CMD_STATUS | size: | 8b | Since this payload is HCI encapsulated, Little Endian byte order is used. Write/Read Example: If we write 0x0000002a at address 0x00008c04, with opcode_write 0xfc5d, The resulting transaction is (btmon trace): < HCI Command (0x3f|0x005d) plen 10 [hci0] 04 8c 00 00 02 04 2a 00 00 00 > HCI Event (0x0e) plen 4 Unknown (0x3f|0x005d) ncmd 1 00 Then, if we read the same register with opcode_read 0xfc5e: < HCI Command (0x3f|0x005e) plen 6 [hci0] 04 8c 00 00 02 04 > HCI Event (0x0e) plen 12 [hci0] Unknown (0x3f|0x005e) ncmd 1 00 04 8c 00 00 2a 00 00 00 Signed-off-by: Loic Poulain <loic.poulain@intel.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2015-10-01 19:16:21 +03:00
select REGMAP
Bluetooth: btintel: Introduce generic Intel Bluetooth support The majority of Intel Bluetooth vendor commands are shared between USB and UART transports. This creates a separate module that eventually will hold all Intel specific commands, but for now just start with the commands to change the Bluetooth public address and check for the default address. Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
2015-04-06 10:52:11 +03:00
Bluetooth: btbcm: Introduce generic Broadcom Bluetooth support The majority of Broadcom Bluetooth vendor commands are shared between USB and UART transports. This creates a separate module that eventually will hold all Broadcom specific commands, but for now just start with the commands to change the Bluetooth public address and check for the default address. Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
2015-04-06 08:52:10 +03:00
config BT_BCM
tristate
Bluetooth: btbcm: Add support for Broadcom controller setup To unify the controller setup of Broadcom devices between USB and UART transport, add the patchram download support into the Broadcom module. Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
2015-04-06 08:52:13 +03:00
select FW_LOADER
Bluetooth: btbcm: Introduce generic Broadcom Bluetooth support The majority of Broadcom Bluetooth vendor commands are shared between USB and UART transports. This creates a separate module that eventually will hold all Broadcom specific commands, but for now just start with the commands to change the Bluetooth public address and check for the default address. Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
2015-04-06 08:52:10 +03:00
Bluetooth: btrtl: Create separate module for Realtek BT driver As already done for btintel and btbcm export setup as separate function in a vendor-specific module to hold all the Realtek specific commands. Signed-off-by: Carlo Caione <carlo@endlessm.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2015-05-14 11:49:09 +03:00
config BT_RTL
tristate
select FW_LOADER
Bluetooth: btqca: Introduce generic QCA ROME support This is for supporting BT for QCA ROME with vendor specific HCI commands and initialization on the chip. This will have USB/UART implementation both, but for now, adding UART vendor specific commands to patch downloading and set Bluetooth device address using vendor specific command. Signed-off-by: Ben Young Tae Kim <ytkim@qca.qualcomm.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2015-08-11 00:24:12 +03:00
config BT_QCA
tristate
select FW_LOADER
Bluetooth: mediatek: add BT_MTK module Add BT_MTK module that is a preliminary patch to introduce mt7921s support to share the logic betweem btusb and btmtksdio. Signed-off-by: Sean Wang <sean.wang@mediatek.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2021-10-19 00:30:12 +03:00
config BT_MTK
tristate
select FW_LOADER
[Bluetooth] Add generic driver for Bluetooth USB devices This patch adds a new generic driver for Bluetooth USB devices. This driver is still experimental at this point, but it is cleaner and easier to maintain than the current Bluetooth USB driver. It is a much better starting point for power management improvements. Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2007-10-20 16:12:34 +04:00
config BT_HCIBTUSB
[Bluetooth] Add SCO support to btusb driver The new generic driver for Bluetooth USB devices was missing proper SCO support. The driver now claims the second interface for these USB devices to allow the flow of SCO packets. It also handles switching of the alternate setting and re-submission of isochronous URBs. The btusb driver is now a full replacement for hci_usb and thus the experimental tag has been removed and this driver is promoted as preferred one. Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2008-08-18 15:23:52 +04:00
tristate "HCI USB driver"
depends on USB
Bluetooth: btusb: Use generic Intel support for address support The Bluetooth address handling for Intel devices is provided by a generic module now. Start using that module instead of relying it being included in the driver. Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
2015-04-06 10:52:12 +03:00
select BT_INTEL
[Bluetooth] Add generic driver for Bluetooth USB devices This patch adds a new generic driver for Bluetooth USB devices. This driver is still experimental at this point, but it is cleaner and easier to maintain than the current Bluetooth USB driver. It is a much better starting point for power management improvements. Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2007-10-20 16:12:34 +04:00
help
Bluetooth HCI USB driver.
This driver is required if you want to use Bluetooth devices with
USB interface.
Say Y here to compile support for Bluetooth USB devices into the
kernel or say M to compile it as module (btusb).
Bluetooth: btusb: Add a Kconfig option to enable USB autosuspend by default On many laptops the btusb device is the only USB device not having USB autosuspend enabled, this causes not only the HCI but also the USB controller to stay awake, together using aprox. 0.4W of power. Modern ultrabooks idle around 6W (at 50% screen brightness), 3.5W for Apollo Lake devices. 0.4W is a significant chunk of this (7 / 11%). The btusb driver already contains code to allow enabling USB autosuspend, but currently leaves it up to the user / userspace to enable it. This means that for most people it will not be enabled, leading to an unnecessarily high power consumption. Since enabling it is not entirely without risk of regressions, this commit adds a Kconfig option so that Linux distributions can choose to enable it by default. This commit also adds a module option so that when distros receive bugs they can easily ask the user to disable it again for easy debugging. Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2017-11-13 16:44:16 +03:00
config BT_HCIBTUSB_AUTOSUSPEND
Bluetooth: btusb: Fix BT_HCIBTUSB_AUTOSUSPEND Kconfig option name Fix: drivers/bluetooth/Kconfig:35:warning: multi-line strings not supported warning. Reported-by: Stephen Rothwell <sfr@canb.auug.org.au> Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2017-11-14 12:15:23 +03:00
bool "Enable USB autosuspend for Bluetooth USB devices by default"
Bluetooth: btusb: Add a Kconfig option to enable USB autosuspend by default On many laptops the btusb device is the only USB device not having USB autosuspend enabled, this causes not only the HCI but also the USB controller to stay awake, together using aprox. 0.4W of power. Modern ultrabooks idle around 6W (at 50% screen brightness), 3.5W for Apollo Lake devices. 0.4W is a significant chunk of this (7 / 11%). The btusb driver already contains code to allow enabling USB autosuspend, but currently leaves it up to the user / userspace to enable it. This means that for most people it will not be enabled, leading to an unnecessarily high power consumption. Since enabling it is not entirely without risk of regressions, this commit adds a Kconfig option so that Linux distributions can choose to enable it by default. This commit also adds a module option so that when distros receive bugs they can easily ask the user to disable it again for easy debugging. Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2017-11-13 16:44:16 +03:00
depends on BT_HCIBTUSB
help
Say Y here to enable USB autosuspend for Bluetooth USB devices by
default.
This can be overridden by passing btusb.enable_autosuspend=[y|n]
on the kernel commandline.
Bluetooth: btusb: Add option for Broadcom protocol support With the generic Broadcom Bluetooth support module, it is possible to turn support for firmware and patchram download into an optional feature. To keep backwards compatibility with previous kernel configurations, the new option defaults to enabled. Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
2015-04-06 08:52:14 +03:00
config BT_HCIBTUSB_BCM
bool "Broadcom protocol support"
depends on BT_HCIBTUSB
select BT_BCM
default y
help
The Broadcom protocol support enables firmware and patchram
download support for Broadcom Bluetooth controllers.
Say Y here to compile support for Broadcom protocol.
Bluetooth: btusb: Add protocol support for MediaTek MT7668U USB devices This adds the support of enabling MT7668U Bluetooth function running on the top of btusb driver. The information in /sys/kernel/debug/usb/devices about the Bluetooth device is listed as the below. T: Bus=02 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#= 2 Spd=5000 MxCh= 0 D: Ver= 3.00 Cls=ef(misc ) Sub=02 Prot=01 MxPS= 9 #Cfgs= 1 P: Vendor=0e8d ProdID=7668 Rev= 1.00 S: Manufacturer=MediaTek Inc. S: Product=Wireless_Device S: SerialNumber=000000000 C:* #Ifs= 3 Cfg#= 1 Atr=a0 MxPwr=160mA A: FirstIf#= 0 IfCount= 2 Cls=e0(wlcon) Sub=01 Prot=01 I:* If#= 0 Alt= 0 #EPs= 3 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=81(I) Atr=03(Int.) MxPS= 16 Ivl=125us E: Ad=82(I) Atr=02(Bulk) MxPS=1024 Ivl=0ms E: Ad=02(O) Atr=02(Bulk) MxPS=1024 Ivl=0ms I:* If#= 1 Alt= 0 #EPs= 2 Cls=e0(wlcon) 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=e0(wlcon) 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=e0(wlcon) 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=e0(wlcon) 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=e0(wlcon) 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=e0(wlcon) 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#= 1 Alt= 6 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=83(I) Atr=01(Isoc) MxPS= 63 Ivl=1ms E: Ad=03(O) Atr=01(Isoc) MxPS= 63 Ivl=1ms Signed-off-by: Sean Wang <sean.wang@mediatek.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2019-06-02 03:02:48 +03:00
config BT_HCIBTUSB_MTK
bool "MediaTek protocol support"
depends on BT_HCIBTUSB
Bluetooth: mediatek: add BT_MTK module Add BT_MTK module that is a preliminary patch to introduce mt7921s support to share the logic betweem btusb and btmtksdio. Signed-off-by: Sean Wang <sean.wang@mediatek.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2021-10-19 00:30:12 +03:00
select BT_MTK
Bluetooth: btusb: Add protocol support for MediaTek MT7668U USB devices This adds the support of enabling MT7668U Bluetooth function running on the top of btusb driver. The information in /sys/kernel/debug/usb/devices about the Bluetooth device is listed as the below. T: Bus=02 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#= 2 Spd=5000 MxCh= 0 D: Ver= 3.00 Cls=ef(misc ) Sub=02 Prot=01 MxPS= 9 #Cfgs= 1 P: Vendor=0e8d ProdID=7668 Rev= 1.00 S: Manufacturer=MediaTek Inc. S: Product=Wireless_Device S: SerialNumber=000000000 C:* #Ifs= 3 Cfg#= 1 Atr=a0 MxPwr=160mA A: FirstIf#= 0 IfCount= 2 Cls=e0(wlcon) Sub=01 Prot=01 I:* If#= 0 Alt= 0 #EPs= 3 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=81(I) Atr=03(Int.) MxPS= 16 Ivl=125us E: Ad=82(I) Atr=02(Bulk) MxPS=1024 Ivl=0ms E: Ad=02(O) Atr=02(Bulk) MxPS=1024 Ivl=0ms I:* If#= 1 Alt= 0 #EPs= 2 Cls=e0(wlcon) 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=e0(wlcon) 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=e0(wlcon) 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=e0(wlcon) 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=e0(wlcon) 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=e0(wlcon) 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#= 1 Alt= 6 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=83(I) Atr=01(Isoc) MxPS= 63 Ivl=1ms E: Ad=03(O) Atr=01(Isoc) MxPS= 63 Ivl=1ms Signed-off-by: Sean Wang <sean.wang@mediatek.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2019-06-02 03:02:48 +03:00
default n
help
The MediaTek protocol support enables firmware download
support and chip initialization for MediaTek Bluetooth
USB controllers.
Say Y here to compile support for MediaTek protocol.
Bluetooth: btrtl: Create separate module for Realtek BT driver As already done for btintel and btbcm export setup as separate function in a vendor-specific module to hold all the Realtek specific commands. Signed-off-by: Carlo Caione <carlo@endlessm.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2015-05-14 11:49:09 +03:00
config BT_HCIBTUSB_RTL
bool "Realtek protocol support"
depends on BT_HCIBTUSB
select BT_RTL
default y
help
The Realtek protocol support enables firmware and configuration
download support for Realtek Bluetooth controllers.
Say Y here to compile support for Realtek protocol.
[Bluetooth] Add generic driver for Bluetooth SDIO devices This patch adds a generic driver for Bluetooth SDIO devices. It supports Type-A and Type-B devices. Signed-off-by: David Vrabel <david.vrabel@csr.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2007-10-20 16:02:04 +04:00
config BT_HCIBTSDIO
tristate "HCI SDIO driver"
depends on MMC
help
Bluetooth HCI SDIO driver.
This driver is required if you want to use Bluetooth device with
SDIO interface.
Say Y here to compile support for Bluetooth SDIO devices into the
kernel or say M to compile it as module (btsdio).
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-17 02:20:36 +04:00
config BT_HCIUART
tristate "HCI UART driver"
Bluetooth: BT_HCIUART now depends on SERIAL_DEV_BUS It is no longer possible to build BT_HCIUART into the kernel when SERIAL_DEV_BUS is a loadable module, even if none of the SERIAL_DEV_BUS based implementations are selected: drivers/bluetooth/hci_ldisc.o: In function `hci_uart_set_flow_control': hci_ldisc.c:(.text+0xb40): undefined reference to `serdev_device_set_flow_control' hci_ldisc.c:(.text+0xb5c): undefined reference to `serdev_device_set_tiocm' This adds a dependency to avoid the broken configuration. Fixes: 7841d554809b ("Bluetooth: hci_uart_set_flow_control: Fix NULL deref when using serdev") Signed-off-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2017-10-11 16:47:54 +03:00
depends on SERIAL_DEV_BUS || !SERIAL_DEV_BUS
Bluetooth: hciuart: add nvmem dependency When the hci support is built-in, but mvmem is a loadable module, we get a link failure: drivers/bluetooth/hci_ll.o: In function `hci_ti_probe': hci_ll.c:(.text+0x226): undefined reference to `nvmem_cell_get' hci_ll.c:(.text+0x238): undefined reference to `nvmem_cell_read' hci_ll.c:(.text+0x244): undefined reference to `nvmem_cell_put' This adds another Kconfig dependency to enforce valid configurations. Fixes: 0e58d0cdb3eb ("Bluetooth: hci_ll: Add optional nvmem BD address source") Signed-off-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2018-01-02 13:50:30 +03:00
depends on NVMEM || !NVMEM
tty: Added a CONFIG_TTY option to allow removal of TTY The option allows you to remove TTY and compile without errors. This saves space on systems that won't support TTY interfaces anyway. bloat-o-meter output is below. The bulk of this patch consists of Kconfig changes adding "depends on TTY" to various serial devices and similar drivers that require the TTY layer. Ideally, these dependencies would occur on a common intermediate symbol such as SERIO, but most drivers "select SERIO" rather than "depends on SERIO", and "select" does not respect dependencies. bloat-o-meter output comparing our previous minimal to new minimal by removing TTY. The list is filtered to not show removed entries with awk '$3 != "-"' as the list was very long. add/remove: 0/226 grow/shrink: 2/14 up/down: 6/-35356 (-35350) function old new delta chr_dev_init 166 170 +4 allow_signal 80 82 +2 static.__warned 143 142 -1 disallow_signal 63 62 -1 __set_special_pids 95 94 -1 unregister_console 126 121 -5 start_kernel 546 541 -5 register_console 593 588 -5 copy_from_user 45 40 -5 sys_setsid 128 120 -8 sys_vhangup 32 19 -13 do_exit 1543 1526 -17 bitmap_zero 60 40 -20 arch_local_irq_save 137 117 -20 release_task 674 652 -22 static.spin_unlock_irqrestore 308 260 -48 Signed-off-by: Joe Millenbach <jmillenbach@gmail.com> Reviewed-by: Jamey Sharp <jamey@minilop.net> Reviewed-by: Josh Triplett <josh@joshtriplett.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-01-18 10:44:22 +04:00
depends on TTY
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-17 02:20:36 +04:00
help
Bluetooth HCI UART driver.
This driver is required if you want to use Bluetooth devices with
Bluetooth: Remove trailing whitespaces from Kconfig Fixed a coding style issue. Removed trailing whitespaces in drivers/bluetooth/Kconfig. Signed-off-by: Stephan Gabert <stephan.gabert@fau.de> Signed-off-by: Nicolas Pfeiffer <nicolas.pfeiffer@fau.de> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2014-06-16 20:52:25 +04:00
serial port interface. You will also need this driver if you have
UART based Bluetooth PCMCIA and CF devices like Xircom Credit Card
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-17 02:20:36 +04:00
adapter and BrainBoxes Bluetooth PC Card.
Say Y here to compile support for Bluetooth UART devices into the
kernel or say M to compile it as module (hci_uart).
Bluetooth: try to improve CONFIG_SERIAL_DEV_BUS dependency With CONFIG_SERIAL_DEV_BUS=m, the hci_serdev.o file does not actually get built into hci_uart.o as the Makefile doesn't pick it up, leading to a link error with anything referring to it: ERROR: "hci_uart_register_device" [drivers/bluetooth/hci_nokia.ko] undefined! scripts/Makefile.modpost:91: recipe for target '__modpost' failed Changing this in the Makefile would cause another problem when hci_uart itself is built-in and cannot reference symbols from the serdev module. This tries to address both problems by introducing a new hidden Kconfig symbol that controls both the compilation of hci_serdev.o and whether the Nokia driver can be selected. This seems to address the problem for me, though there might be a better way to do it. Fixes: 7bb318680e86 ("Bluetooth: add nokia driver") Signed-off-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2017-04-19 20:50:18 +03:00
config BT_HCIUART_SERDEV
bool
depends on SERIAL_DEV_BUS && BT_HCIUART
default y
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-17 02:20:36 +04:00
config BT_HCIUART_H4
bool "UART (H4) protocol support"
depends on BT_HCIUART
help
Bluetooth: Remove trailing whitespaces from Kconfig Fixed a coding style issue. Removed trailing whitespaces in drivers/bluetooth/Kconfig. Signed-off-by: Stephan Gabert <stephan.gabert@fau.de> Signed-off-by: Nicolas Pfeiffer <nicolas.pfeiffer@fau.de> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2014-06-16 20:52:25 +04:00
UART (H4) is serial protocol for communication between Bluetooth
device and host. This protocol is required for most Bluetooth devices
with UART interface, including PCMCIA and CF cards.
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-17 02:20:36 +04:00
Say Y here to compile support for HCI UART (H4) protocol.
Bluetooth: add nokia driver This adds a driver for the Nokia H4+ protocol, which is used at least on the Nokia N9, N900 & N950. Signed-off-by: Sebastian Reichel <sre@kernel.org> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2017-04-13 03:26:59 +03:00
config BT_HCIUART_NOKIA
tristate "UART Nokia H4+ protocol support"
depends on BT_HCIUART
Bluetooth: try to improve CONFIG_SERIAL_DEV_BUS dependency With CONFIG_SERIAL_DEV_BUS=m, the hci_serdev.o file does not actually get built into hci_uart.o as the Makefile doesn't pick it up, leading to a link error with anything referring to it: ERROR: "hci_uart_register_device" [drivers/bluetooth/hci_nokia.ko] undefined! scripts/Makefile.modpost:91: recipe for target '__modpost' failed Changing this in the Makefile would cause another problem when hci_uart itself is built-in and cannot reference symbols from the serdev module. This tries to address both problems by introducing a new hidden Kconfig symbol that controls both the compilation of hci_serdev.o and whether the Nokia driver can be selected. This seems to address the problem for me, though there might be a better way to do it. Fixes: 7bb318680e86 ("Bluetooth: add nokia driver") Signed-off-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2017-04-19 20:50:18 +03:00
depends on BT_HCIUART_SERDEV
Bluetooth: Depend on rather than select GPIOLIB Commit 27378f4c1b92 ("Bluetooth: Avoid WARN splat due to missing GPIOLIB") amended Kconfig to select GPIOLIB if BT_HCIUART_NOKIA, BT_HCIUART_INTEL or BT_HCIUART_BCM is enabled since all three drivers require it to function. The diagnosis was correct but the treatment was not. As stated in Documentation/gpio/consumer.txt: Guidelines for GPIOs consumers ============================== Drivers that can't work without standard GPIO calls should have Kconfig entries that depend on GPIOLIB. ^^^^^^^^^ Fix it. Reported-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Lukas Wunner <lukas@wunner.de> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2018-01-02 22:08:40 +03:00
depends on GPIOLIB
Bluetooth: add nokia driver This adds a driver for the Nokia H4+ protocol, which is used at least on the Nokia N9, N900 & N950. Signed-off-by: Sebastian Reichel <sre@kernel.org> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2017-04-13 03:26:59 +03:00
depends on PM
Bluetooth: hci_nokia: select BT_HCIUART_H4 We see the following build failure with CONFIG_BT_HCIUART_NOKIA=y and CONFIG_BT_HCIUART_H4=n: drivers/bluetooth/hci_nokia.c: In function 'nokia_recv': drivers/bluetooth/hci_nokia.c:644:18: error: implicit declaration of function 'h4_recv_buf' [-Werror=implicit-function-declaration] ... Fix this by selecting the BT_HCIUART_H4 symbol like all the other users of the protocoll. Fixes: 7bb318680e86 ("Bluetooth: add nokia driver") Signed-off-by: Tobias Regnery <tobias.regnery@gmail.com> Reviewed-by: Sebastian Reichel <sre@kernel.org> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2017-05-08 12:39:11 +03:00
select BT_HCIUART_H4
Bluetooth: hci_nokia: select BT_BCM for btbcm_set_bdaddr() The Nokia devices require the setup of its Public Bluetooth Device Address and for that it is required to depend on vendor specific commands. For Broadcom based Nokia devices, that is part of btbcm module and can be selected via BT_BCM config option. Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Reviewed-by: Sebastian Reichel <sebastian.reichel@collabora.co.uk> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
2017-07-22 12:57:47 +03:00
select BT_BCM
Bluetooth: add nokia driver This adds a driver for the Nokia H4+ protocol, which is used at least on the Nokia N9, N900 & N950. Signed-off-by: Sebastian Reichel <sre@kernel.org> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2017-04-13 03:26:59 +03:00
help
Nokia H4+ is serial protocol for communication between Bluetooth
device and host. This protocol is required for Bluetooth devices
with UART interface in Nokia devices.
Say Y here to compile support for Nokia's H4+ protocol.
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-17 02:20:36 +04:00
config BT_HCIUART_BCSP
bool "BCSP protocol support"
depends on BT_HCIUART
bluetooth/hci_bcsp: fix bitrev Kconfig Fix bluetooth hci_bcsp Kconfig to avoid build errors: drivers/built-in.o: In function `bcsp_prepare_pkt': hci_bcsp.c:(.text+0x7e9ac): undefined reference to `bitrev16' drivers/built-in.o: In function `bcsp_recv': hci_bcsp.c:(.text+0x7f276): undefined reference to `bitrev16' hci_bcsp.c:(.text+0x7f293): undefined reference to `bitrev16' make[1]: *** [.tmp_vmlinux1] Error 1 Signed-off-by: Randy Dunlap <randy.dunlap@oracle.com> Ackey-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: David S. Miller <davem@davemloft.net>
2008-07-15 11:51:45 +04:00
select BITREVERSE
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-17 02:20:36 +04:00
help
Bluetooth: Remove trailing whitespaces from Kconfig Fixed a coding style issue. Removed trailing whitespaces in drivers/bluetooth/Kconfig. Signed-off-by: Stephan Gabert <stephan.gabert@fau.de> Signed-off-by: Nicolas Pfeiffer <nicolas.pfeiffer@fau.de> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2014-06-16 20:52:25 +04:00
BCSP (BlueCore Serial Protocol) is serial protocol for communication
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-17 02:20:36 +04:00
between Bluetooth device and host. This protocol is required for non
USB Bluetooth devices based on CSR BlueCore chip, including PCMCIA and
CF cards.
Say Y here to compile support for HCI BCSP protocol.
Bluetooth: Support for Atheros AR300x serial chip Implements Atheros AR300x serial HCI protocol. This protocol extends H4 serial protocol to implement enhanced power management features supported by Atheros AR300x serial Bluetooth chipsets. Signed-off-by: Suraj Sumangala <suraj@atheros.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2010-07-19 11:04:07 +04:00
config BT_HCIUART_ATH3K
bool "Atheros AR300x serial support"
depends on BT_HCIUART
Bluetooth: hci_uart: Use h4_recv_buf helper for Atheros AR300x Instead of using hci_recv_stream_fragment, use the local available h4_recv_buf helper function. To ensure that the function is available select BT_HCIUART_H4. Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
2015-04-05 07:59:26 +03:00
select BT_HCIUART_H4
Bluetooth: Support for Atheros AR300x serial chip Implements Atheros AR300x serial HCI protocol. This protocol extends H4 serial protocol to implement enhanced power management features supported by Atheros AR300x serial Bluetooth chipsets. Signed-off-by: Suraj Sumangala <suraj@atheros.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2010-07-19 11:04:07 +04:00
help
HCIATH3K (HCI Atheros AR300x) is a serial protocol for
communication between host and Atheros AR300x Bluetooth devices.
This protocol enables AR300x chips to be enabled with
power management support.
Enable this if you have Atheros AR300x serial Bluetooth device.
Say Y here to compile support for HCI UART ATH3K protocol.
[Bluetooth] Add UART driver for Texas Instruments' BRF63xx chips Add support for Texas Instruments' HCI Low Level (HCILL) Bluetooth protocol, which is a power management extension to H4. The HCILL is widely used by TI's BRF63xx Bluetooth chips. Signed-off-by: Ohad Ben-Cohen <ohad@bencohen.org> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2007-10-20 15:42:36 +04:00
config BT_HCIUART_LL
bool "HCILL protocol support"
Bluetooth: hci_uart: fix kconfig dependency We see the following link error with CONFIG_BT_HCIUART=y, CONFIG_BT_HCIUART_LL=y and CONFIG_SERIAL_DEV_BUS=m: drivers/built-in.o: In function 'll_close': supp.c:(.text+0x55add4): undefined reference to 'serdev_device_close' supp.c:(.text+0x55add4): relocation truncated to fit: R_AARCH64_CALL26 against undefined symbol 'serdev_device_close' drivers/built-in.o: In function 'll_open': supp.c:(.text+0x55aed0): undefined reference to 'serdev_device_open' supp.c:(.text+0x55aed0): relocation truncated to fit: R_AARCH64_CALL26 against undefined symbol 'serdev_device_open' drivers/built-in.o: In function `hci_ti_probe': supp.c:(.text+0x55b00c): undefined reference to 'hci_uart_register_device' supp.c:(.text+0x55b00c): relocation truncated to fit: R_AARCH64_CALL26 against undefined symbol 'hci_uart_register_device' drivers/built-in.o: In function `ll_setup': supp.c:(.text+0x55b08c): undefined reference to 'serdev_device_set_flow_control' supp.c:(.text+0x55b08c): relocation truncated to fit: R_AARCH64_CALL26 against undefined symbol 'serdev_device_set_flow_control' supp.c:(.text+0x55b324): undefined reference to 'serdev_device_set_baudrate' supp.c:(.text+0x55b324): relocation truncated to fit: R_AARCH64_CALL26 against undefined symbol 'serdev_device_set_baudrate' drivers/built-in.o: In function 'll_init': supp.c:(.init.text+0x1b508): undefined reference to '__serdev_device_driver_register' supp.c:(.init.text+0x1b508): relocation truncated to fit: R_AARCH64_CALL26 against undefined symbol '__serdev_device_driver_register' Fix this by dependig BT_HCIUART_LL on the BT_HCIUART_SERDEV symbol. This implies a dependency on BT_HCIUART and hci_ll.c is only compiled in if SERIAl_DEV_BUS is built in or SERIAL_DEV_BUS and BT_HCIUART are modules. Fixes: 371805522f87 ("bluetooth: hci_uart: add LL protocol serdev driver support") Signed-off-by: Tobias Regnery <tobias.regnery@gmail.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2017-05-02 16:15:01 +03:00
depends on BT_HCIUART_SERDEV
Bluetooth: hci_ll: Convert to use h4_recv_buf helper The HCILL or eHCILL protocol from TI is actually an H:4 protocol with a few extra events and thus can also use the h4_recv_buf helper. Instead of open coding the same funtionality add the extra events to the packet description table and use h4_recv_buf. Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Tested-by: Tony Lindgren <tony@atomide.com> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
2018-03-24 12:19:52 +03:00
select BT_HCIUART_H4
[Bluetooth] Add UART driver for Texas Instruments' BRF63xx chips Add support for Texas Instruments' HCI Low Level (HCILL) Bluetooth protocol, which is a power management extension to H4. The HCILL is widely used by TI's BRF63xx Bluetooth chips. Signed-off-by: Ohad Ben-Cohen <ohad@bencohen.org> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2007-10-20 15:42:36 +04:00
help
HCILL (HCI Low Level) is a serial protocol for communication
between Bluetooth device and host. This protocol is required for
serial Bluetooth devices that are based on Texas Instruments'
BRF chips.
Say Y here to compile support for HCILL protocol.
Bluetooth: Initial skeleton for Three-wire UART (H5) support This patch adds the initial skeleton for Three-wire UART (H5) support and hooks it up to the HCI UART framework. Signed-off-by: Johan Hedberg <johan.hedberg@intel.com> Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
2012-07-16 17:12:02 +04:00
config BT_HCIUART_3WIRE
bool "Three-wire UART (H5) protocol support"
depends on BT_HCIUART
Bluetooth: h5: Fix missing dependency on BT_HCIUART_SERDEV This driver was recently updated to use serdev, so add the appropriate dependency. Without this one can get compiler warnings like this if CONFIG_SERIAL_DEV_BUS is not enabled: CC [M] drivers/bluetooth/hci_h5.o drivers/bluetooth/hci_h5.c:934:36: warning: ‘h5_serdev_driver’ defined but not used [-Wunused-variable] static struct serdev_device_driver h5_serdev_driver = { ^~~~~~~~~~~~~~~~ Signed-off-by: Johan Hedberg <johan.hedberg@intel.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2018-08-04 23:40:26 +03:00
depends on BT_HCIUART_SERDEV
Bluetooth: Initial skeleton for Three-wire UART (H5) support This patch adds the initial skeleton for Three-wire UART (H5) support and hooks it up to the HCI UART framework. Signed-off-by: Johan Hedberg <johan.hedberg@intel.com> Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
2012-07-16 17:12:02 +04:00
help
The HCI Three-wire UART Transport Layer makes it possible to
user the Bluetooth HCI over a serial port interface. The HCI
Three-wire UART Transport Layer assumes that the UART
communication may have bit errors, overrun errors or burst
errors and thereby making CTS/RTS lines unnecessary.
Say Y here to compile support for Three-wire UART protocol.
Bluetooth: hci_uart: Add support Intel address configuration When using vendor detection, this adds support for the Intel specific address configuration command. Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
2015-04-05 02:13:02 +03:00
config BT_HCIUART_INTEL
bool "Intel protocol support"
depends on BT_HCIUART
Bluetooth: Depend on rather than select GPIOLIB Commit 27378f4c1b92 ("Bluetooth: Avoid WARN splat due to missing GPIOLIB") amended Kconfig to select GPIOLIB if BT_HCIUART_NOKIA, BT_HCIUART_INTEL or BT_HCIUART_BCM is enabled since all three drivers require it to function. The diagnosis was correct but the treatment was not. As stated in Documentation/gpio/consumer.txt: Guidelines for GPIOs consumers ============================== Drivers that can't work without standard GPIO calls should have Kconfig entries that depend on GPIOLIB. ^^^^^^^^^ Fix it. Reported-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Lukas Wunner <lukas@wunner.de> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2018-01-02 22:08:40 +03:00
depends on GPIOLIB
Bluetooth: hci_uart: Add basic support for Intel Lightning Peak devices The Intel Lightning Peak devices do not come with Bluetooth firmware loaded and thus require a full download of the operational Bluetooth firmware when the device is attached via the Bluetooth line discipline. Lightning Peak devices start with a bootloader mode that only accepts a very limited set of HCI commands. The supported commands are enough to identify the hardware and select the right firmware to load. Signed-off-by: Loic Poulain <loic.poulain@intel.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2015-07-01 13:20:26 +03:00
select BT_HCIUART_H4
Bluetooth: hci_uart: Use generic Intel support for address setting The Bluetooth address setting for Intel devices is provided by a generic module now. Start using that module instead of relying it being included in the driver. Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
2015-04-06 10:52:14 +03:00
select BT_INTEL
Bluetooth: hci_uart: Add support Intel address configuration When using vendor detection, this adds support for the Intel specific address configuration command. Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
2015-04-05 02:13:02 +03:00
help
The Intel protocol support enables Bluetooth HCI over serial
port interface for Intel Bluetooth controllers.
Say Y here to compile support for Intel protocol.
Bluetooth: hci_uart: Add support Broadcom address configuration When using vendor detection, this adds support for the Broadcom specific address configuration command. Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
2015-04-05 02:13:03 +03:00
config BT_HCIUART_BCM
bool "Broadcom protocol support"
depends on BT_HCIUART
Bluetooth: hci_bcm: Add serdev support Add basic support for Broadcom serial slave devices. Probe the serial device, retrieve its maximum speed and register a new hci uart device. Tested/compatible with bcm43438 (RPi3). Signed-off-by: Loic Poulain <loic.poulain@gmail.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2017-08-17 20:59:51 +03:00
depends on BT_HCIUART_SERDEV
Bluetooth: avoid silent hci_bcm ACPI PM regression The hci_bcm platform-device hack which was used to implement power management for ACPI devices is being replaced by a serial-device-bus implementation. Unfortunately, when the corresponding change to the ACPI code lands (a change that will stop enumerating and registering the serial-device-node child as a platform device) PM will break silently unless serdev TTY-port controller support has been enabled. Specifically, hciattach (btattach) would still succeed, but power management would no longer work. Although this is strictly a runtime dependency, let's make the driver depend on SERIAL_DEV_CTRL_TTYPORT, which is the particular serdev controller implementation used by the ACPI devices currently managed by this driver, to avoid breaking PM without anyone noticing. Note that the driver already has a (build-time) dependency on the serdev bus code. Signed-off-by: Johan Hovold <johan@kernel.org> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2017-10-10 11:01:52 +03:00
depends on (!ACPI || SERIAL_DEV_CTRL_TTYPORT)
Bluetooth: Depend on rather than select GPIOLIB Commit 27378f4c1b92 ("Bluetooth: Avoid WARN splat due to missing GPIOLIB") amended Kconfig to select GPIOLIB if BT_HCIUART_NOKIA, BT_HCIUART_INTEL or BT_HCIUART_BCM is enabled since all three drivers require it to function. The diagnosis was correct but the treatment was not. As stated in Documentation/gpio/consumer.txt: Guidelines for GPIOs consumers ============================== Drivers that can't work without standard GPIO calls should have Kconfig entries that depend on GPIOLIB. ^^^^^^^^^ Fix it. Reported-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Lukas Wunner <lukas@wunner.de> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2018-01-02 22:08:40 +03:00
depends on GPIOLIB
Bluetooth: hci_uart: Add protocol support for Broadcom UART devices This adds the protocol support for Broadcom based UART devices to enable firmware and patchram download procedure. It is a pretty straight forward H:4 driver with the exception of actually having its own setup and address configuration callbacks. Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
2015-04-06 08:52:18 +03:00
select BT_HCIUART_H4
Bluetooth: hci_uart: Use generic functionality from Broadcom module The new Broadcom Bluetooth support module provides generic functionality for changing and checking the Bluetooth device address. Use these new features instead of keeping a duplicate in the driver. Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
2015-04-06 08:52:12 +03:00
select BT_BCM
Bluetooth: hci_uart: Add support Broadcom address configuration When using vendor detection, this adds support for the Broadcom specific address configuration command. Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
2015-04-05 02:13:03 +03:00
help
The Broadcom protocol support enables Bluetooth HCI over serial
port interface for Broadcom Bluetooth controllers.
Say Y here to compile support for Broadcom protocol.
Bluetooth: Introduce BT_HCIUART_RTL configuration option Like all the other UART protocols, introduce a configuration option for Realtek based serial devices. Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
2018-08-09 11:33:07 +03:00
config BT_HCIUART_RTL
bool "Realtek protocol support"
depends on BT_HCIUART
depends on BT_HCIUART_SERDEV
depends on GPIOLIB
Bluetooth: hci_h5: btrtl: Add support for RTL8822C Add new compatible and FW loading support for RTL8822C. Signed-off-by: Max Chou <max.chou@realtek.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2020-02-17 11:14:55 +03:00
depends on (ACPI || SERIAL_DEV_CTRL_TTYPORT)
Bluetooth: Introduce BT_HCIUART_RTL configuration option Like all the other UART protocols, introduce a configuration option for Realtek based serial devices. Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
2018-08-09 11:33:07 +03:00
select BT_HCIUART_3WIRE
select BT_RTL
help
The Realtek protocol support enables Bluetooth HCI over 3-Wire
Bluetooth: Fix a typo in Kconfig 'internface' has an extra 'n'. Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2020-02-16 14:20:31 +03:00
serial port interface for Realtek Bluetooth controllers.
Bluetooth: Introduce BT_HCIUART_RTL configuration option Like all the other UART protocols, introduce a configuration option for Realtek based serial devices. Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
2018-08-09 11:33:07 +03:00
Say Y here to compile support for Realtek protocol.
Bluetooth: hciuart: Add support QCA chipset for UART QCA61x4 chips have supported sleep feature using In-Band-Sleep commands to enable sleep feature based on H4 protocol. After sending patch/nvm configuration is done, IBS mode will be up and running Signed-off-by: Ben Young Tae Kim <ytkim@qca.qualcomm.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2015-08-11 00:24:17 +03:00
config BT_HCIUART_QCA
bool "Qualcomm Atheros protocol support"
depends on BT_HCIUART
Bluetooth: hci_qca: Add serdev support Add support for Qualcomm serial slave devices. Probe the serial device, retrieve its maximum speed and register a new hci uart device. Signed-off-by: Thierry Escande <thierry.escande@linaro.org> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2018-03-29 22:15:24 +03:00
depends on BT_HCIUART_SERDEV
Bluetooth: hciuart: Add support QCA chipset for UART QCA61x4 chips have supported sleep feature using In-Band-Sleep commands to enable sleep feature based on H4 protocol. After sending patch/nvm configuration is done, IBS mode will be up and running Signed-off-by: Ben Young Tae Kim <ytkim@qca.qualcomm.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2015-08-11 00:24:17 +03:00
select BT_HCIUART_H4
select BT_QCA
help
The Qualcomm Atheros protocol supports HCI In-Band Sleep feature
over serial port interface(H4) between controller and host.
This protocol is required for UART clock control for QCA Bluetooth
devices.
Say Y here to compile support for QCA protocol.
Bluetooth: hci_uart: Add Intel/AG6xx support This driver implements support for iBT2.1 Bluetooth controller embedded in the AG620 communication combo. The controller needs to be configured with bddata and can be patched with a binary patch file (pbn). These operations are performed in manufacturing mode. Signed-off-by: Loic Poulain <loic.poulain@intel.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2016-02-22 12:48:03 +03:00
config BT_HCIUART_AG6XX
bool "Intel AG6XX protocol support"
depends on BT_HCIUART
select BT_HCIUART_H4
select BT_INTEL
help
The Intel/AG6XX protocol support enables Bluetooth HCI over serial
port interface for Intel ibt 2.1 Bluetooth controllers.
Say Y here to compile support for Intel AG6XX protocol.
Bluetooth: hci_uart: Add Marvell support This patch introduces support for Marvell Bluetooth controller over UART (8897 for now). In order to send the final firmware at full speed, a helper firmware is firstly sent. Firmware download is driven by the controller which sends request firmware packets (including expected size). This driver is a global rework of the one proposed by Amitkumar Karwar <akarwar@marvell.com>. Signed-off-by: Loic Poulain <loic.poulain@intel.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2016-09-19 17:29:27 +03:00
config BT_HCIUART_MRVL
bool "Marvell protocol support"
depends on BT_HCIUART
Bluetooth: hci_mrvl: Add serdev support This adds serdev support to the Marvell hci uart driver. Only basic serdev support, none of the fancier features like regulator or enable GPIO support is added for now. Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2019-06-14 10:23:51 +03:00
depends on BT_HCIUART_SERDEV
Bluetooth: hci_uart: Add Marvell support This patch introduces support for Marvell Bluetooth controller over UART (8897 for now). In order to send the final firmware at full speed, a helper firmware is firstly sent. Firmware download is driven by the controller which sends request firmware packets (including expected size). This driver is a global rework of the one proposed by Amitkumar Karwar <akarwar@marvell.com>. Signed-off-by: Loic Poulain <loic.poulain@intel.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2016-09-19 17:29:27 +03:00
select BT_HCIUART_H4
help
Marvell is serial protocol for communication between Bluetooth
device and host. This protocol is required for most Marvell Bluetooth
devices with UART interface.
Say Y here to compile support for HCI MRVL protocol.
Bluetooth: hci_uart: Add Intel/AG6xx support This driver implements support for iBT2.1 Bluetooth controller embedded in the AG620 communication combo. The controller needs to be configured with bddata and can be patched with a binary patch file (pbn). These operations are performed in manufacturing mode. Signed-off-by: Loic Poulain <loic.poulain@intel.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2016-02-22 12:48:03 +03:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-17 02:20:36 +04:00
config BT_HCIBCM203X
tristate "HCI BCM203x USB driver"
depends on USB
select FW_LOADER
help
Bluetooth HCI BCM203x USB driver.
This driver provides the firmware loading mechanism for the Broadcom
Blutonium based devices.
Say Y here to compile support for HCI BCM203x devices into the
kernel or say M to compile it as module (bcm203x).
config BT_HCIBPA10X
tristate "HCI BPA10x USB driver"
Bluetooth: bpa10x: Use separate h4_recv_buf helper When adding the alignment and padding support for H:4 packet processing for the Nokia driver, it broke the h4_recv_buf usage within bpa10x driver. To fix this use a separate helper function and placing it into a dedicated h4_recv.h header file. Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
2018-03-24 12:19:53 +03:00
depends on USB
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-17 02:20:36 +04:00
help
Bluetooth HCI BPA10x USB driver.
This driver provides support for the Digianswer BPA 100/105 Bluetooth
sniffer devices.
Say Y here to compile support for HCI BPA10x devices into the
kernel or say M to compile it as module (bpa10x).
config BT_HCIBFUSB
tristate "HCI BlueFRITZ! USB driver"
depends on USB
select FW_LOADER
help
Bluetooth HCI BlueFRITZ! USB driver.
This driver provides support for Bluetooth USB devices with AVM
interface:
AVM BlueFRITZ! USB
Say Y here to compile support for HCI BFUSB devices into the
kernel or say M to compile it as module (bfusb).
config BT_HCIDTL1
tristate "HCI DTL1 (PC Card) driver"
depends on PCMCIA
help
Bluetooth HCI DTL1 (PC Card) driver.
This driver provides support for Bluetooth PCMCIA devices with
Nokia DTL1 interface:
Nokia Bluetooth Card
Socket Bluetooth CF Card
Say Y here to compile support for HCI DTL1 devices into the
kernel or say M to compile it as module (dtl1_cs).
config BT_HCIBT3C
tristate "HCI BT3C (PC Card) driver"
depends on PCMCIA
select FW_LOADER
help
Bluetooth HCI BT3C (PC Card) driver.
This driver provides support for Bluetooth PCMCIA devices with
3Com BT3C interface:
3Com Bluetooth Card (3CRWB6096)
HP Bluetooth Card
Say Y here to compile support for HCI BT3C devices into the
kernel or say M to compile it as module (bt3c_cs).
config BT_HCIBLUECARD
tristate "HCI BlueCard (PC Card) driver"
depends on PCMCIA
help
Bluetooth HCI BlueCard (PC Card) driver.
This driver provides support for Bluetooth PCMCIA devices with
Anycom BlueCard interface:
Anycom Bluetooth PC Card
Anycom Bluetooth CF Card
Say Y here to compile support for HCI BlueCard devices into the
kernel or say M to compile it as module (bluecard_cs).
config BT_HCIVHCI
tristate "HCI VHCI (Virtual HCI device) driver"
help
Bluetooth Virtual HCI device driver.
This driver is required if you want to use HCI Emulation software.
Say Y here to compile support for virtual HCI devices into the
kernel or say M to compile it as module (hci_vhci).
Bluetooth: Add btmrvl driver for Marvell Bluetooth devices This driver provides basic definitions and library functions to support Marvell Bluetooth enabled devices, such as 88W8688 WLAN/BT combo chip. This patch incorporates a lot of comments given by Nicolas Pitre <nico@marvell.com>. Many thanks to Nicolas Pitre. Signed-off-by: Rahul Tank <rahult@marvell.com> Signed-off-by: Bing Zhao <bzhao@marvell.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2009-06-03 01:29:35 +04:00
config BT_MRVL
tristate "Marvell Bluetooth driver support"
help
The core driver to support Marvell Bluetooth devices.
This driver is required if you want to support
Bluetooth: btmrvl: add support for SD8987 chipset This patch adds support for Marvell 88W8987 chipset with SDIO interface. Register offsets and supported feature flags are updated. The corresponding firmware image file shall be "mrvl/sd8987_uapsta.bin". Signed-off-by: Tamás Szűcs <tszucs@protonmail.ch> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2019-04-14 21:38:14 +03:00
Marvell Bluetooth devices, such as 8688/8787/8797/8887/8897/8977/8987/8997.
Bluetooth: Add btmrvl driver for Marvell Bluetooth devices This driver provides basic definitions and library functions to support Marvell Bluetooth enabled devices, such as 88W8688 WLAN/BT combo chip. This patch incorporates a lot of comments given by Nicolas Pitre <nico@marvell.com>. Many thanks to Nicolas Pitre. Signed-off-by: Rahul Tank <rahult@marvell.com> Signed-off-by: Bing Zhao <bzhao@marvell.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2009-06-03 01:29:35 +04:00
Say Y here to compile Marvell Bluetooth driver
into the kernel or say M to compile it as module.
Bluetooth: Add Marvell BT-over-SDIO driver This driver supports Marvell Bluetooth enabled devices with SDIO interface. Currently only SD8688 chip is supported. The helper/firmware images of SD8688 can be downloaded from this tree: git://git.infradead.org/users/dwmw2/linux-firmware.git This patch incorporates a lot of comments given by Nicolas Pitre <nico@marvell.com>. Many thanks to Nicolas Pitre. Signed-off-by: Rahul Tank <rahult@marvell.com> Signed-off-by: Bing Zhao <bzhao@marvell.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2009-06-03 01:29:36 +04:00
config BT_MRVL_SDIO
tristate "Marvell BT-over-SDIO driver"
depends on BT_MRVL && MMC
Bluetooth: Fix Kconfig for Marvell Bluetooth driver The Marvell driver selects DEBUG_FS and FW_LOADER for its core driver and that is pointless. Don't select DEBUG_FS since it is either enabled or not and it is not for the driver to enable it. Also FW_LOADER is only used within the SDIO driver and so just have that one select the FW_LOADER option. Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2009-06-09 15:42:54 +04:00
select FW_LOADER
Bluetooth: btmrvl add firmware dump support This patch adds firmware dump support for marvell bluetooth chipset. Currently only SD8897 is supported. This is implemented based on dev_coredump, a new mechnism introduced in kernel 3.18rc3 Firmware dump can be trigger by echo 1 > /sys/kernel/debug/bluetooth/hci*/config/fw_dump and when the dump operation is completed, data can be read by cat /sys/class/devcoredump/devcd*/data We have prepared following script to divide fw memory dump data into multiple files based on memory type. [root]# cat btmrvl_split_dump_data.sh #!/bin/bash # usage: ./btmrvl_split_dump_data.sh dump_data fw_dump_data=$1 mem_type="ITCM DTCM SQRAM APU CIU ICU MAC EXT7 EXT8 EXT9 EXT10 EXT11 EXT12 EXT13 EXTLAST" for name in ${mem_type[@]} do sed -n "/Start dump $name/,/End dump/p" $fw_dump_data > tmp.$name.log if [ ! -s tmp.$name.log ] then rm -rf tmp.$name.log else # Remove the describle info "Start dump" and "End dump" sed '1d' tmp.$name.log | sed '$d' > /data/$name.log if [ -s /data/$name.log ] then echo "generate /data/$name.log" else sed '1d' tmp.$name.log | sed '$d' > /var/$name.log echo "generate /var/$name.log" fi rm -rf tmp.$name.log fi done Signed-off-by: Xinming Hu <huxm@marvell.com> Signed-off-by: Cathy Luo <cluo@marvell.com> Signed-off-by: Avinash Patil <patila@marvell.com> Reviewed-by: Johannes Berg <johannes@sipsolutions.net> Reviewed-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Amitkumar Karwar <akarwar@marvell.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2014-11-24 13:40:53 +03:00
select WANT_DEV_COREDUMP
Bluetooth: Add Marvell BT-over-SDIO driver This driver supports Marvell Bluetooth enabled devices with SDIO interface. Currently only SD8688 chip is supported. The helper/firmware images of SD8688 can be downloaded from this tree: git://git.infradead.org/users/dwmw2/linux-firmware.git This patch incorporates a lot of comments given by Nicolas Pitre <nico@marvell.com>. Many thanks to Nicolas Pitre. Signed-off-by: Rahul Tank <rahult@marvell.com> Signed-off-by: Bing Zhao <bzhao@marvell.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2009-06-03 01:29:36 +04:00
help
The driver for Marvell Bluetooth chipsets with SDIO interface.
This driver is required if you want to use Marvell Bluetooth
Bluetooth: btmrvl: add support for SD8987 chipset This patch adds support for Marvell 88W8987 chipset with SDIO interface. Register offsets and supported feature flags are updated. The corresponding firmware image file shall be "mrvl/sd8987_uapsta.bin". Signed-off-by: Tamás Szűcs <tszucs@protonmail.ch> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2019-04-14 21:38:14 +03:00
devices with SDIO interface. Currently SD8688/SD8787/SD8797/SD8887/SD8897/SD8977/SD8987/SD8997
Bluetooth: btmrvl: support Marvell Bluetooth device SD8797 The SD8797 firmware image is shared with mwifiex driver. Whoever gets loaded first will be responsible for firmware downloading. Signed-off-by: Bing Zhao <bzhao@marvell.com> Signed-off-by: Frank Huang <frankh@marvell.com> Signed-off-by: Gustavo F. Padovan <padovan@profusion.mobi>
2011-11-17 08:40:42 +04:00
chipsets are supported.
Bluetooth: Add Marvell BT-over-SDIO driver This driver supports Marvell Bluetooth enabled devices with SDIO interface. Currently only SD8688 chip is supported. The helper/firmware images of SD8688 can be downloaded from this tree: git://git.infradead.org/users/dwmw2/linux-firmware.git This patch incorporates a lot of comments given by Nicolas Pitre <nico@marvell.com>. Many thanks to Nicolas Pitre. Signed-off-by: Rahul Tank <rahult@marvell.com> Signed-off-by: Bing Zhao <bzhao@marvell.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2009-06-03 01:29:36 +04:00
Say Y here to compile support for Marvell BT-over-SDIO driver
into the kernel or say M to compile it as module.
Bluetooth: Add DFU driver for Atheros Bluetooth chipset AR3011 Signed-off-by: Vikram Kandukuri <vikram.kandukuri@atheros.com> Signed-off-by: Alicke Xu <sxu@atheros.com> Reviewed-by: Luis R. Rodriguez <lrodriguez@atheros.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2010-01-06 16:34:15 +03:00
config BT_ATH3K
tristate "Atheros firmware download driver"
depends on BT_HCIBTUSB
select FW_LOADER
help
Bluetooth firmware download driver.
This driver loads the firmware into the Atheros Bluetooth
chipset.
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-17 02:20:36 +04:00
Bluetooth: Add DFU driver for Atheros Bluetooth chipset AR3011 Signed-off-by: Vikram Kandukuri <vikram.kandukuri@atheros.com> Signed-off-by: Alicke Xu <sxu@atheros.com> Reviewed-by: Luis R. Rodriguez <lrodriguez@atheros.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2010-01-06 16:34:15 +03:00
Say Y here to compile support for "Atheros firmware download driver"
into the kernel or say M to compile it as module (ath3k).
Bluetooth: mediatek: add support for MediaTek MT7663S and MT7668S SDIO devices This adds the support of enabling MT7663S and MT7668S SDIO-based Bluetooth function. There are quite many differences between MT766[3,8]S and standard Bluetooth SDIO devices such as Type-A and Type-B devices. For example, MT766[3,8]S have its own SDIO registers layout, definition, SDIO packet format, and the specific flow should be programmed on them to complete the device initialization and low power control and so on. Currently, there are many independent programming sequences from the transport which are exactly the same as the ones in btusb.c about MediaTek support [1] and btmtkuart.c. We can try to split the transport independent Bluetooth setups on the advance, place them into the common files and allow varous transport drivers to reuse them in the future. [1] http://lists.infradead.org/pipermail/linux-mediatek/2019-January/017074.html Signed-off-by: Sean Wang <sean.wang@mediatek.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2019-03-08 04:15:44 +03:00
config BT_MTKSDIO
tristate "MediaTek HCI SDIO driver"
depends on MMC
Bluetooth: btmtksido: rely on BT_MTK module Rely on btmtk module to reduce duplicated code Signed-off-by: Sean Wang <sean.wang@mediatek.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2021-10-19 00:30:13 +03:00
select BT_MTK
Bluetooth: mediatek: add support for MediaTek MT7663S and MT7668S SDIO devices This adds the support of enabling MT7663S and MT7668S SDIO-based Bluetooth function. There are quite many differences between MT766[3,8]S and standard Bluetooth SDIO devices such as Type-A and Type-B devices. For example, MT766[3,8]S have its own SDIO registers layout, definition, SDIO packet format, and the specific flow should be programmed on them to complete the device initialization and low power control and so on. Currently, there are many independent programming sequences from the transport which are exactly the same as the ones in btusb.c about MediaTek support [1] and btmtkuart.c. We can try to split the transport independent Bluetooth setups on the advance, place them into the common files and allow varous transport drivers to reuse them in the future. [1] http://lists.infradead.org/pipermail/linux-mediatek/2019-January/017074.html Signed-off-by: Sean Wang <sean.wang@mediatek.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2019-03-08 04:15:44 +03:00
help
MediaTek Bluetooth HCI SDIO driver.
This driver is required if you want to use MediaTek Bluetooth
with SDIO interface.
Say Y here to compile support for MediaTek Bluetooth SDIO devices
into the kernel or say M to compile it as module (btmtksdio).
Bluetooth: mediatek: Add protocol support for MediaTek serial devices This adds a driver based on serdev driver for the MediaTek serial protocol based on running H:4, which can enable the built-in Bluetooth device inside MT7622 SoC. Signed-off-by: Sean Wang <sean.wang@mediatek.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2018-08-07 20:52:48 +03:00
config BT_MTKUART
tristate "MediaTek HCI UART driver"
depends on SERIAL_DEV_BUS
Bluetooth: btmtkuart: rely on BT_MTK module Rely on btmtk module to reduce duplicated code Signed-off-by: Sean Wang <sean.wang@mediatek.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2022-03-09 03:03:52 +03:00
select BT_MTK
Bluetooth: mediatek: Add protocol support for MediaTek serial devices This adds a driver based on serdev driver for the MediaTek serial protocol based on running H:4, which can enable the built-in Bluetooth device inside MT7622 SoC. Signed-off-by: Sean Wang <sean.wang@mediatek.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2018-08-07 20:52:48 +03:00
help
MediaTek Bluetooth HCI UART driver.
This driver is required if you want to use MediaTek Bluetooth
with serial interface.
Say Y here to compile support for MediaTek Bluetooth UART devices
into the kernel or say M to compile it as module (btmtkuart).
Bluetooth: Introduce Qualcomm WCNSS SMD based HCI driver The Qualcomm WCNSS chip provides two SMD channels to the BT core; one for command and one for event packets. This driver exposes the two channels as a hci device. Signed-off-by: Bjorn Andersson <bjorn.andersson@sonymobile.com> Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2016-08-13 03:01:28 +03:00
config BT_QCOMSMD
tristate "Qualcomm SMD based HCI support"
soc: qcom: smd: Transition client drivers from smd to rpmsg By moving these client drivers to use RPMSG instead of the direct SMD API we can reuse them ontop of the newly added GLINK wire-protocol support found in the 820 and 835 Qualcomm platforms. As the new (RPMSG-based) and old SMD implementations are mutually exclusive we have to change all client drivers in one commit, to make sure we have a working system before and after this transition. Acked-by: Andy Gross <andy.gross@linaro.org> Acked-by: Kalle Valo <kvalo@codeaurora.org> Acked-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org> Signed-off-by: David S. Miller <davem@davemloft.net>
2017-03-28 08:26:33 +03:00
depends on RPMSG || (COMPILE_TEST && RPMSG=n)
Bluetooth: btqcomsmd: fix compile-test dependency compile-testing fails when QCOM_SMD is a loadable module: drivers/bluetooth/built-in.o: In function `btqcomsmd_send': btqca.c:(.text+0xa8): undefined reference to `qcom_smd_send' drivers/bluetooth/built-in.o: In function `btqcomsmd_probe': btqca.c:(.text+0x3ec): undefined reference to `qcom_wcnss_open_channel' btqca.c:(.text+0x46c): undefined reference to `qcom_smd_set_drvdata' This clarifies the dependency to allow compile-testing only when SMD is completely disabled, otherwise the dependency on QCOM_SMD will make sure we can link against it. Fixes: e27ee2b16bad ("Bluetooth: btqcomsmd: Allow driver to build if COMPILE_TEST is enabled") Signed-off-by: Arnd Bergmann <arnd@arndb.de> [bjorn: Restructure and clarify dependency to QCOM_WCNSS_CTRL] Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org> Acked-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: David S. Miller <davem@davemloft.net>
2017-03-21 01:31:10 +03:00
depends on QCOM_WCNSS_CTRL || (COMPILE_TEST && QCOM_WCNSS_CTRL=n)
Bluetooth: Introduce Qualcomm WCNSS SMD based HCI driver The Qualcomm WCNSS chip provides two SMD channels to the BT core; one for command and one for event packets. This driver exposes the two channels as a hci device. Signed-off-by: Bjorn Andersson <bjorn.andersson@sonymobile.com> Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2016-08-13 03:01:28 +03:00
select BT_QCA
help
Qualcomm SMD based HCI driver.
This driver is used to bridge HCI data onto the shared memory
channels to the WCNSS core.
Say Y here to compile support for HCI over Qualcomm SMD into the
kernel or say M to compile as a module.
Bluetooth: btrsi: add new rsi bluetooth driver Redpine bluetooth driver is a thin driver which depends on 'rsi_91x' driver for transmitting and receiving packets to/from device. It creates hci interface when attach() is called from 'rsi_91x' module. Signed-off-by: Prameela Rani Garnepudi <prameela.j04cs@gmail.com> Signed-off-by: Siva Rebbagondla <siva.rebbagondla@redpinesignals.com> Acked-by: Marcel Holtmann <marcel@holtmann.org> Reviewed-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Amitkumar Karwar <amit.karwar@redpinesignals.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
2018-02-27 17:26:15 +03:00
config BT_HCIRSI
Bluetooth: btrsi: rework dependencies The linkage between the bluetooth driver and the wireless driver is not defined properly, leading to build problems such as: warning: (BT_HCIRSI) selects RSI_COEX which has unmet direct dependencies (NETDEVICES && WLAN && WLAN_VENDOR_RSI && BT_HCIRSI && RSI_91X) drivers/net/wireless/rsi/rsi_91x_main.o: In function `rsi_read_pkt': (.text+0x205): undefined reference to `rsi_bt_ops' As the dependency is actually the reverse (RSI_91X uses the BT_RSI driver, not the other way round), this changes the dependency to match, and enables the bluetooth driver from the RSI_COEX symbol. Fixes: 38aa4da50483 ("Bluetooth: btrsi: add new rsi bluetooth driver") Acked-by; Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
2018-03-16 00:18:24 +03:00
tristate
Bluetooth: btrsi: add new rsi bluetooth driver Redpine bluetooth driver is a thin driver which depends on 'rsi_91x' driver for transmitting and receiving packets to/from device. It creates hci interface when attach() is called from 'rsi_91x' module. Signed-off-by: Prameela Rani Garnepudi <prameela.j04cs@gmail.com> Signed-off-by: Siva Rebbagondla <siva.rebbagondla@redpinesignals.com> Acked-by: Marcel Holtmann <marcel@holtmann.org> Reviewed-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Amitkumar Karwar <amit.karwar@redpinesignals.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
2018-02-27 17:26:15 +03:00
help
Redpine BT driver.
This driver handles BT traffic from upper layers and pass
to the RSI_91x coex module for further scheduling to device
Say Y here to compile support for HCI over Redpine into the
kernel or say M to compile as a module.
Bluetooth: Add support for virtio transport driver This adds support for Bluetooth HCI transport over virtio. Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
2021-04-06 22:55:53 +03:00
config BT_VIRTIO
tristate "Virtio Bluetooth driver"
depends on VIRTIO
help
Virtio Bluetooth support driver.
This driver supports Virtio Bluetooth devices.
Say Y here to compile support for HCI over Virtio into the
kernel or say M to compile as a module.
Bluetooth: Add DFU driver for Atheros Bluetooth chipset AR3011 Signed-off-by: Vikram Kandukuri <vikram.kandukuri@atheros.com> Signed-off-by: Alicke Xu <sxu@atheros.com> Reviewed-by: Luis R. Rodriguez <lrodriguez@atheros.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2010-01-06 16:34:15 +03:00
endmenu
Reference in New Issue Copy Permalink