We should send hci reset command before bt turn off, which can reset bt
firmware status.
Signed-off-by: Rocky Liao <quic_rjliao@quicinc.com>
Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
It is not allowed to call kfree_skb() from hardware interrupt
context or with hardware interrupts being disabled.
So replace kfree_skb() with dev_kfree_skb_irq() under
spin_lock_irqsave(). Compile tested only.
Fixes: baac6276c0 ("Bluetooth: btusb: handle mSBC audio over USB Endpoints")
Signed-off-by: Jinjie Ruan <ruanjinjie@huawei.com>
Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
The quirks table was named "blacklist_table" which isn't a good
description for that table as devices detected using it weren't ignored
by the driver.
Rename the table to match what it actually does.
Signed-off-by: Bastien Nocera <hadess@hadess.net>
Reviewed-by: Paul Menzel <pmenzel@molgen.mpg.de>
Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
btusb_recv_event_intel is specific to Intel controllers therefore it
shall be placed inside btintel.c so btusb don't have a mix of vendor
specific code with the generic parts.
Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
This patch implement function .coredump() and dmp_hdr() in btusb
driver for MediaTek controller. FW core dump was triggered by FW
specific event to show something unexpected happened in the controller.
The driver would be responsible for collecting and uploading the device
core dump pieces in hci driver using core dump API. Once we finished
the whole process, the driver would reset the controller to recover the
kind of fatal error.
Co-developed-by: Chris Lu <chris.lu@mediatek.com>
Signed-off-by: Chris Lu <chris.lu@mediatek.com>
Co-developed-by: Sean Wang <sean.wang@mediatek.com>
Signed-off-by: Sean Wang <sean.wang@mediatek.com>
Signed-off-by: Jing Cai <jing.cai@mediatek.com>
Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
Introduce btmtk_reset_work which can be called whenever the firmware abort,
HCI command timeout, other fatal error happen.
Co-developed-by: Chris Lu <chris.lu@mediatek.com>
Signed-off-by: Chris Lu <chris.lu@mediatek.com>
Co-developed-by: Sean Wang <sean.wang@mediatek.com>
Signed-off-by: Sean Wang <sean.wang@mediatek.com>
Signed-off-by: Jing Cai <jing.cai@mediatek.com>
Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
Use readx_poll_timeout instead of open coding to poll the hardware reset
status until it is done.
Signed-off-by: Sean Wang <sean.wang@mediatek.com>
Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
New Intel platforms supports reset of Bluetooth device via ACPI DSM
methods. The legacy reset mechanism via GPIO will be deprecated in
future. This patch checks the platform support for reset methods and if
supported uses the same instead of legacy GPIO toggling method.
ACPI firmware supports two types of reset method based on NIC card.
(Discrete or Integrated).
1. VSEC Type - Vendor Specific Extended Capability. Here BT_EN and
BT_IF_SELECT lines are driven by a register in PCH cluster. This
interface is supported on discrete BT solution.
2. WDISABLE2 - In this soluton, W_DISABLE2 pin in M.2 is connected to
physical GPIO from PCH. The DSM interface shall toggle this to recover
from error.
Signed-off-by: Kiran K <kiran.k@intel.com>
Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
Catch debug exception from controller and driver, and trigger a
devcoredump using hci devcoredump APIs. The debug exception data
will be parsed in userspace.
Signed-off-by: Alex Lu <alex_lu@realsil.com.cn>
Signed-off-by: Hilda Wu <hildawu@realtek.com>
Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
Commit c13380a555 ("Bluetooth: btusb: Do not require hardcoded
interface numbers") inadvertedly broke bluetooth on Intel Macbook 2014.
The intention was to keep behavior intact when BTUSB_IFNUM_2 is set and
otherwise allow any interface numbers. The problem is that the new logic
condition omits the case where bInterfaceNumber is 0.
Fix BTUSB_IFNUM_2 handling by allowing both interface number 0 and 2
when the flag is set.
Fixes: c13380a555 ("Bluetooth: btusb: Do not require hardcoded interface numbers")
Reported-by: John Holland <johnbholland@icloud.com>
Closes: https://bugzilla.kernel.org/show_bug.cgi?id=217651
Signed-off-by: Tomasz Moń <tomasz.mon@nordicsemi.no>
Tested-by: John Holland<johnbholland@icloud.com>
Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
Adding the device ID from the Asus Ally gets the bluetooth working
on the device.
Signed-off-by: Matthew Anderson <ruinairas1992@gmail.com>
Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
WCN6855 will report memdump via ACL data or HCI event when
it get crashed, so we collect memdump to debug firmware.
Signed-off-by: Tim Jiang <quic_tjiang@quicinc.com>
Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
The ATS2851 based controller advertises support for command "LE Set Random
Private Address Timeout" but does not actually implement it, impeding the
controller initialization.
Add the quirk HCI_QUIRK_BROKEN_SET_RPA_TIMEOUT to unblock the controller
initialization.
< HCI Command: LE Set Resolvable Private... (0x08|0x002e) plen 2
Timeout: 900 seconds
> HCI Event: Command Status (0x0f) plen 4
LE Set Resolvable Private Address Timeout (0x08|0x002e) ncmd 1
Status: Unknown HCI Command (0x01)
Co-developed-by: imoc <wzj9912@gmail.com>
Signed-off-by: imoc <wzj9912@gmail.com>
Signed-off-by: Raul Cheleguini <raul.cheleguini@gmail.com>
Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
Intercept debug exception events from the controller and put them into
a devcoredump using hci devcoredump APIs. The debug exception contains
data in a TLV format and it will be parsed in userspace.
Signed-off-by: Abhishek Pandit-Subedi <abhishekpandit@chromium.org>
Signed-off-by: Manish Mandlik <mmandlik@google.com>
Reviewed-by: Abhishek Pandit-Subedi <abhishekpandit@chromium.org>
Reviewed-by: Chethan Tumkur Narayan <chethan.tumkur.narayan@intel.com>
Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
This patch implements the btusb driver side .coredump() callback to
trigger a devcoredump via sysfs.
Signed-off-by: Manish Mandlik <mmandlik@google.com>
Reviewed-by: Abhishek Pandit-Subedi <abhishekpandit@chromium.org>
Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
Add two more quirks to resume the device initialization and basic
operation as the device seems not to support "Read Transmit Power"
and "Set Extended Scan Parameters".
< HCI Command: LE Read Transmit Power (0x08|0x004b) plen 0
> HCI Event: Command Status (0x0f) plen 4
LE Read Transmit Power (0x08|0x004b) ncmd 1
Status: Unknown HCI Command (0x01)
< HCI Command: LE Set Extended Scan Parameters (0x08|0x0041) plen 8
Own address type: Random (0x01)
Filter policy: Accept all advertisement (0x00)
PHYs: 0x01
Entry 0: LE 1M
Type: Active (0x01)
Interval: 11.250 msec (0x0012)
Window: 11.250 msec (0x0012)
> HCI Event: Command Status (0x0f) plen 4
LE Set Extended Scan Parameters (0x08|0x0041) ncmd 1
Status: Unknown HCI Command (0x01)
Signed-off-by: Raul Cheleguini <rcheleguini@google.com>
Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
Remove hardcoded interface number check because Bluetooth specification
since version 4.0 only recommends and no longer requires specific
interface numbers.
While earlier Bluetooth versions, i.e. 2.1 + EDR and 3.0 + HS, contain
required configuration table in Volume 4 - Host Controller Interface
Part B - USB Transport Layer, Bluetooth Core Specification Addendum 2
changes the table from required to recommended configuration.
Signed-off-by: Tomasz Moń <tomasz.mon@nordicsemi.no>
Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
This removes the code introduced by
14202eff21 as hci_recv_frame is now able
to detect ACL packets that are in fact ISO packets.
Fixes: 14202eff21 ("Bluetooth: btusb: Detect if an ACL packet is in fact an ISO packet")
Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
It is not allowed to call kfree_skb() from hardware interrupt
context or with interrupts being disabled. So replace kfree_skb()
with dev_kfree_skb_irq() under spin_lock_irqsave().
Fixes: 803b58367f ("Bluetooth: btusb: Implement driver internal packet reassembly")
Signed-off-by: Yang Yingliang <yangyingliang@huawei.com>
Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
This fix the following warnings detect with make W=1 C=1:
drivers/bluetooth/btusb.c:3426:28: warning: cast to restricted __le32
Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
This fix the following warnings detect with make W=1 C=1:
drivers/bluetooth/btusb.c:2212:9: warning: cast to restricted __le16
drivers/bluetooth/btusb.c:2212:9: warning: cast to restricted __le16
drivers/bluetooth/btusb.c:2245:18: warning: cast to restricted __le16
drivers/bluetooth/btusb.c:2249:18: warning: cast to restricted __le16
drivers/bluetooth/btusb.c:2253:18: warning: cast to restricted __le16
drivers/bluetooth/btusb.c:2257:18: warning: cast to restricted __le16
drivers/bluetooth/btusb.c:2261:18: warning: cast to restricted __le16
drivers/bluetooth/btusb.c:2267:18: warning: cast to restricted __le16
Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
Add IDs to usb_device_id table for WCN6855. IDs are extracted from Windows
driver of Lenovo Thinkpad T14 Gen 2(Driver version 1.0.0.1205 Windows 10)
Windows driver download address:
https://pcsupport.lenovo.com/us/en/products/laptops-and-netbooks/
thinkpad-t-series-laptops/thinkpad-t14-gen-2-type-20xk-20xl/downloads
/driver-list/
Signed-off-by: Shengyu Qu <wiagn233@outlook.com>
Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
This adds CONFIG_BT_HCIBTUSB_POLL_SYNC which can be used to set the
default behavior of Bluetooth USB controller with respect to poll
synchronization of its endpoits.
Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
Tested-by: Tedd Ho-Jeong An <tedd.an@intel.com>
For USB ALT 6 settings some Realtek chips need to transmit mSBC data
continuously without the zero length of USB packets.
In this commit, create BTUSB_ALT6_CONTINUOUS_TX to manage the behavior.
Therefore, create REALTEK_ALT6_CONTINUOUS_TX_CHIP to manage the specific
chip model for the behavior.
Signed-off-by: Max Chou <max.chou@realtek.com>
Signed-off-by: Hilda Wu <hildawu@realtek.com>
Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
This patch adds a data structure for btrealtek object, and the
definition of vendor behavior flags. It also adds macros to set/test/get
the flags.
Signed-off-by: Hilda Wu <hildawu@realtek.com>
Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
The USB interface between the host and the bluetooth adapter used for
SCO packets uses an USB isochronous endpoint with a fragmentation scheme
that does not tolerate errors. Except USB isochronous transfers do
not provide a reliable stream with guaranteed delivery. (There is no
retry on error, see USB spec v2.0 5.6 and 8.5.5.)
To fragment a packet, the bluetooth HCI simply splits it in parts and
transfer them as-is. The receiver is expected to reconstruct the packet
by assuming the first fragment contains the header and parsing its size
field. There is no error detection either.
If a fragment is lost, the end result is that the kernel is no longer
synchronized and will pass malformed data to the upper layers, since it
has no way to tell if the first fragment is an actual first fragment or
a continuation fragment. Resynchronization can only happen by luck and
requires an unbounded amount of time.
The typical symptom for a HSP/HFP bluetooth headset is that the
microphone stops working and dmesg contains piles of rate-limited
"Bluetooth: hci0: SCO packet for unknown connection handle XXXX"
errors for an indeterminate amount of time, until the kernel accidentally
resynchronize.
A workaround is to ask the upper layer to prevalidate the first fragment
header. This is not possible with user channels so this workaround is
disabled in this case.
This problem is the most severe when using an ath3k adapter on an i.MX 6
board, where packet loss occur regularly, possibly because it is an USB1
device connected on an USB2 hub and this is a special case requiring
split transactions.
Signed-off-by: Nicolas Cavallari <nicolas.cavallari@green-communications.fr>
Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
On cmd_timeout with no reset_gpio, reset the USB port as a last
resort.
This patch changes the behavior of btusb_intel_cmd_timeout and
btusb_rtl_cmd_timeout.
Signed-off-by: Archie Pusaka <apusaka@chromium.org>
Reviewed-by: Abhishek Pandit-Subedi <abhishekpandit@google.com>
Reviewed-by: Ying Hsu <yinghsu@chromium.org>
Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
In case of suspend/resume and HCI_RESET (BT On and Off),
ISOC endpoint set to alt setting 0 when no SCO connection exists.
This patch shall avoid resetting of ISOC endpoint to alt setting to 0.
Signed-off-by: Chethan Tumkur Narayan <chethan.tumkur.narayan@intel.com>
Signed-off-by: Kiran K <kiran.k@intel.com>
Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
The rationale of showing this is that it's potentially critical
information to diagnose and find more CSR compatibility bugs in the
future and it will save a lot of headaches.
Given that clones come from a wide array of vendors (some are actually
Barrot, some are something else) and these numbers are what let us find
differences between actual and fake ones, it will be immensely helpful
to scour the Internet looking for this pattern and building an actual
database to find correlations and improve the checks.
Cc: stable@vger.kernel.org
Cc: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Ismael Ferreras Morezuelas <swyterzone@gmail.com>
Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
A patch series by a Qualcomm engineer essentially removed my
quirk/workaround because they thought it was unnecessary.
It wasn't, and it broke everything again:
https://patchwork.kernel.org/project/netdevbpf/list/?series=661703&archive=both&state=*
He argues that the quirk is not necessary because the code should check
if the dongle says if it's supported or not. The problem is that for
these Chinese CSR clones they say that it would work:
= New Index: 00:00:00:00:00:00 (Primary,USB,hci0)
= Open Index: 00:00:00:00:00:00
< HCI Command: Read Local Version Information (0x04|0x0001) plen 0
> HCI Event: Command Complete (0x0e) plen 12
> [hci0] 11.276039
Read Local Version Information (0x04|0x0001) ncmd 1
Status: Success (0x00)
HCI version: Bluetooth 5.0 (0x09) - Revision 2064 (0x0810)
LMP version: Bluetooth 5.0 (0x09) - Subversion 8978 (0x2312)
Manufacturer: Cambridge Silicon Radio (10)
...
< HCI Command: Read Local Supported Features (0x04|0x0003) plen 0
> HCI Event: Command Complete (0x0e) plen 68
> [hci0] 11.668030
Read Local Supported Commands (0x04|0x0002) ncmd 1
Status: Success (0x00)
Commands: 163 entries
...
Read Default Erroneous Data Reporting (Octet 18 - Bit 2)
Write Default Erroneous Data Reporting (Octet 18 - Bit 3)
...
...
< HCI Command: Read Default Erroneous Data Reporting (0x03|0x005a) plen 0
= Close Index: 00:1A:7D:DA:71:XX
So bring it back wholesale.
Fixes: 63b1a7dd38 ("Bluetooth: hci_sync: Remove HCI_QUIRK_BROKEN_ERR_DATA_REPORTING")
Fixes: e168f69008 ("Bluetooth: btusb: Remove HCI_QUIRK_BROKEN_ERR_DATA_REPORTING for fake CSR")
Fixes: 766ae2422b ("Bluetooth: hci_sync: Check LMP feature bit instead of quirk")
Cc: stable@vger.kernel.org
Cc: Zijun Hu <quic_zijuhu@quicinc.com>
Cc: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
Cc: Hans de Goede <hdegoede@redhat.com>
Tested-by: Ismael Ferreras Morezuelas <swyterzone@gmail.com>
Signed-off-by: Ismael Ferreras Morezuelas <swyterzone@gmail.com>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
