11 Apr, 2020

1 commit

  • Add new compatible device RTL8761B. RTL8761B is a USB Bluetooth device,
    with support of BLE and BR/EDR. The USB info is

    T: Bus=03 Lev=04 Prnt=04 Port=00 Cnt=01 Dev#= 29 Spd=12 MxCh= 0
    D: Ver= 1.10 Cls=e0(wlcon) Sub=01 Prot=01 MxPS=64 #Cfgs= 1
    P: Vendor=0bda ProdID=8771 Rev= 2.00
    S: Manufacturer=Realtek
    S: Product=Bluetooth Radio
    S: SerialNumber=XXXXXXXXXXXX
    C:* #Ifs= 2 Cfg#= 1 Atr=e0 MxPwr=500mA
    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=1ms
    E: Ad=02(O) Atr=02(Bulk) MxPS= 64 Ivl=0ms
    E: Ad=82(I) Atr=02(Bulk) MxPS= 64 Ivl=0ms
    I:* If#= 1 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
    E: Ad=03(O) Atr=01(Isoc) MxPS= 0 Ivl=1ms
    E: Ad=83(I) 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=03(O) Atr=01(Isoc) MxPS= 9 Ivl=1ms
    E: Ad=83(I) 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=03(O) Atr=01(Isoc) MxPS= 17 Ivl=1ms
    E: Ad=83(I) 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=03(O) Atr=01(Isoc) MxPS= 25 Ivl=1ms
    E: Ad=83(I) 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=03(O) Atr=01(Isoc) MxPS= 33 Ivl=1ms
    E: Ad=83(I) 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=03(O) Atr=01(Isoc) MxPS= 49 Ivl=1ms
    E: Ad=83(I) Atr=01(Isoc) MxPS= 49 Ivl=1ms

    Signed-off-by: Ziqian SUN (Zamir)
    Signed-off-by: Marcel Holtmann

    Ziqian SUN (Zamir)
     

18 Feb, 2020

1 commit


25 Jan, 2020

1 commit

  • Currently, kmemdup is applied to the firmware data, and it invokes
    kmalloc under the hood. The firmware size and patch_length are big (more
    than PAGE_SIZE), and on some low-end systems (like ASUS E202SA) kmalloc
    may fail to allocate a contiguous chunk under high memory usage and
    fragmentation:

    Bluetooth: hci0: RTL: examining hci_ver=06 hci_rev=000a lmp_ver=06 lmp_subver=8821
    Bluetooth: hci0: RTL: rom_version status=0 version=1
    Bluetooth: hci0: RTL: loading rtl_bt/rtl8821a_fw.bin
    kworker/u9:2: page allocation failure: order:4, mode:0x40cc0(GFP_KERNEL|__GFP_COMP), nodemask=(null),cpuset=/,mems_allowed=0

    As firmware load happens on each resume, Bluetooth will stop working
    after several iterations, when the kernel fails to allocate an order-4
    page.

    This patch replaces kmemdup with kvmalloc+memcpy. It's not required to
    have a contiguous chunk here, because it's not mapped to the device
    directly.

    Signed-off-by: Maxim Mikityanskiy
    Signed-off-by: Marcel Holtmann

    Maxim Mikityanskiy
     

26 Oct, 2019

1 commit


17 Oct, 2019

1 commit


05 Sep, 2019

5 commits


06 Jul, 2019

2 commits

  • This device is functionally equivalent to the BT part of the RTL8723DE,
    uses the same firmware, but the LMP subversion and HCI revision are unique.

    Signed-off-by: Larry Finger
    Signed-off-by: Marcel Holtmann

    Larry Finger
     
  • Realtek RTL8822BE BT chip on ASUS X420FA cannot be turned on correctly
    after on-off several times. Bluetooth daemon sets BT mode failed when
    this issue happens. Scanning must be active while turning off for this
    bug to be hit.

    bluetoothd[1576]: Failed to set mode: Failed (0x03)

    If BT is turned off, then turned on again, it works correctly again.

    According to the vendor driver, the HCI_QUIRK_RESET_ON_CLOSE flag is set
    during probing. So, this patch makes Realtek's BT reset on close to fix
    this issue.

    Link: https://bugzilla.kernel.org/show_bug.cgi?id=203429
    Signed-off-by: Jian-Hong Pan
    Reviewed-by: Daniel Drake
    Signed-off-by: Marcel Holtmann

    Jian-Hong Pan
     

31 May, 2019

1 commit

  • Based on 3 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

    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 [author] [kishon] [vijay] [abraham]
    [i] [kishon]@[ti] [com] 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

    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 [author] [graeme] [gregory]
    [gg]@[slimlogic] [co] [uk] [author] [kishon] [vijay] [abraham] [i]
    [kishon]@[ti] [com] [based] [on] [twl6030]_[usb] [c] [author] [hema]
    [hk] [hemahk]@[ti] [com] 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

    extracted by the scancode license scanner the SPDX license identifier

    GPL-2.0-or-later

    has been chosen to replace the boilerplate/reference in 1105 file(s).

    Signed-off-by: Thomas Gleixner
    Reviewed-by: Allison Randal
    Reviewed-by: Richard Fontana
    Reviewed-by: Kate Stewart
    Cc: linux-spdx@vger.kernel.org
    Link: https://lkml.kernel.org/r/20190527070033.202006027@linutronix.de
    Signed-off-by: Greg Kroah-Hartman

    Thomas Gleixner
     

28 Jan, 2019

1 commit

  • Realtek bluetooth may not work after reboot:
    [ 12.446130] Bluetooth: hci0: RTL: rtl: unknown IC info, lmp subver a99e, hci rev 826c, hci ver 0008

    This is a regression introduced by commit 26503ad25de8 ("Bluetooth:
    btrtl: split the device initialization into smaller parts"). The new
    logic errors out early when no matching IC info can be found, in this
    case it means the firmware is already loaded.

    So let's assume the firmware is already loaded when we can't find
    matching IC info, like the old logic did.

    Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=201921
    Fixes: 26503ad25de8 ("Bluetooth: btrtl: split the device initialization into smaller parts")
    Cc: stable@vger.kernel.org # 4.19+
    Signed-off-by: Kai-Heng Feng
    Signed-off-by: Marcel Holtmann

    Kai-Heng Feng
     

27 Sep, 2018

2 commits


03 Aug, 2018

6 commits

  • The contents of the rtl_bt/rtlXXXX_config.bin file may be board specific
    allow the caller of btrtl_initialize to specify a postfix identifying
    the board, which if specified will make btrtl_initialize look for
    rtl_bt/rtlXXXX_config-.bin instead.

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

    Hans de Goede
     
  • The Realtek RTL8723BS and RTL8723DS chipsets are SDIO wifi chips. They
    also contain a Bluetooth module which is connected via UART to the host.

    Realtek's userspace initialization tool (rtk_hciattach) differentiates
    these two via the HCI version and revision returned by the
    HCI_OP_READ_LOCAL_VERSION command.
    Additionally we apply these checks only the for UART devices. Everything
    else is assumed to be a "RTL8723B" which was originally supported by the
    driver (communicating via USB).

    Signed-off-by: Martin Blumenstingl
    Signed-off-by: Jeremy Cline
    Signed-off-by: Hans de Goede
    Signed-off-by: Marcel Holtmann

    Martin Blumenstingl
     
  • The UART settings are embedded in the config blob. This has to be parsed
    to successfully initialize the Bluetooth part of the RTL8723BS (which is
    an SDIO chip, but the Bluetooth part is connected via UART).

    The Realtek "rtl8723bs_bt" and "rtl8723ds_bt" userspace Bluetooth UART
    initialization tools (rtk_hciattach) use the following sequence:
    - send H5 sync pattern (already supported by hci_h5)
    - get LMP version (already supported by btrtl)
    - get ROM version (already supported by btrtl)
    - load the firmware and config for the current chipset (already
    supported by btrtl)
    - read UART settings from the config blob (part of this patch)
    - send UART settings via a vendor command to the device (which changes
    the baudrate of the device and enables or disables flow control
    depending on the config)
    - change the baudrate and flow control settings on the host
    - send the firmware and config blob to the device (already supported by
    btrtl)

    Sending the last firmware and config blob download command
    (rtl_download_cmd) fails if the UART settings are not updated
    beforehand. This is presumably because the device applies the config
    right after the firmware and config blob download - which means that at
    this point the host is using different UART settings than the device
    (which will obviously result in non-working communication).

    Signed-off-by: Martin Blumenstingl
    Signed-off-by: Jeremy Cline
    Signed-off-by: Hans de Goede
    Signed-off-by: Marcel Holtmann

    Martin Blumenstingl
     
  • Consistently use rtl_dev_err and rtl_dev_info everywhere for messages.

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

    Hans de Goede
     
  • This prepares the btrtl code so it can be used to initialize Bluetooth
    modules connected via UART (these are found for example on the RTL8723BS
    and RTL8723DS SDIO chips, which come with an embedded UART Bluetooth
    module).

    The Realtek "rtl8723bs_bt" and "rtl8723ds_bt" userspace Bluetooth UART
    initialization tools (rtk_hciattach) use the following sequence:
    1) send H5 sync pattern (already supported by hci_h5)
    2) get LMP version (already supported by btrtl)
    3) get ROM version (already supported by btrtl)
    4) load the firmware and config for the current chipset (already
    supported by btrtl)
    5) read UART settings from the config blob (currently not supported)
    6) send UART settings via a vendor command to the device (which changes
    the baudrate of the device and enables or disables flow control
    depending on the config)
    7) change the baudrate and flow control settings on the host
    8) send the firmware and config blob to the device (already supported by
    btrtl)

    The main reason why the initialization has to be split is step #7. This
    requires changes to the underlying "bus", which should be kept outside
    of the "generic" btrtl driver.
    The idea for this split is borrowed from the btbcm driver but adjusted
    where needed (the btrtl driver for example needs two blobs: firmware and
    config, while the btbcm only needs one).

    This also prepares the code for step #5 (parsing the config blob) by
    centralizing the code which loads the firmware and config blobs and
    storing the result in the new struct btrtl_device_info.

    Signed-off-by: Martin Blumenstingl
    Signed-off-by: Jeremy Cline
    Signed-off-by: Hans de Goede
    Signed-off-by: Marcel Holtmann

    Martin Blumenstingl
     
  • This makes the firmware names show up in modinfo.

    Signed-off-by: Martin Blumenstingl
    Signed-off-by: Jeremy Cline
    Signed-off-by: Hans de Goede
    Signed-off-by: Marcel Holtmann

    Martin Blumenstingl
     

12 Feb, 2018

1 commit

  • The Bluetooth parts of RTL8723D and RTL8723B share the same lmp
    subversion, thus we need to check both lmp subversion and hci revision
    to distinguish the two. The same situation is true for RTL8821A and
    RTL8821C. Accordingly, the selection code is revised.

    To improve maintainability, a new id_table struct is defined, and an
    array of such structs is constructed. Adding a new device can thus be
    as simple as adding another value to the table.

    Signed-off-by: Alex Lu
    Signed-off-by: Larry Finger
    Signed-off-by: Marcel Holtmann

    Alex Lu
     

30 Oct, 2017

1 commit


29 Jul, 2017

1 commit


13 Apr, 2017

1 commit

  • The message concerning missing config files for 8723b, 8821a, and
    8761a should have been issued with BT_INFO() rather than BT_ERR() as
    this condition is not fatal. After looking at that code, I have
    reworked the logic to log such messages only if the device needs such a
    config file. At the moment, only the 8822b fits that description.

    Signed-off-by: Larry Finger
    Acked-by: 陆朱伟
    Signed-off-by: Marcel Holtmann

    Larry Finger
     

20 Sep, 2016

1 commit

  • The RTL8822BE is a new Realtek wifi and BT device. Support for the BT
    part is hereby added.

    As this device is similar to most of the other Realtek BT devices, the
    changes are minimal. The main difference is that the 8822BE needs a
    configuration file for enabling and disabling features. Thus code is
    added to select and load this configuration file. Although not needed
    at the moment, hooks are added for the other devices that might need
    such configuration files.

    One additional change is to the routine that tests that the project
    ID contained in the firmware matches the hardware. As the project IDs
    are not sequential, continuing to use the position in the array as the
    expected value of the ID would require adding extra unused entries in
    the table, and any subsequant rearrangment of the array would break the
    code. To fix these problems, the array elements now contain both the
    hardware ID and the expected value for the project ID.

    Signed-off-by: 陆朱伟
    Signed-off-by: Larry Finger
    Signed-off-by: Marcel Holtmann

    Larry Finger
     

14 May, 2015

1 commit