Fine-tune read register for mt7663/mt7921.
For mediatek chip spcific wmt protocol, we add more delay to send EP0
In-Token.
Signed-off-by: Mark Chen <Mark-YW.Chen@mediatek.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
QCA_IBS_DISABLED flag will be set after memorydump started from
controller.Currently qca_suspend() is waiting for SSR to complete
based on flag QCA_IBS_DISABLED.Added to check for QCA_SSR_TRIGGERED
flag too.
Fixes: 2be43abac5 ("Bluetooth: hci_qca: Wait for timeout during suspend")
Signed-off-by: Venkata Lakshmi Narayana Gubba <gubbaven@codeaurora.org>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
By this change, it will enable WBS supported on the specific Realtek BT
devices, such as RTL8822C and RTL8852A.
In the future, it's able to maintain what the Realtek devices support WBS
here.
Tested-by: Hilda Wu <hildawu@realtek.com>
Reviewed-by: Abhishek Pandit-Subedi <abhishekpandit@chromium.org>
Signed-off-by: Max Chou <max.chou@realtek.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Realtek Bluetooth controllers can do both LE scan and BR/EDR inquiry
at once, need to set HCI_QUIRK_SIMULTANEOUS_DISCOVERY quirk.
Signed-off-by: Claire Chang <tientzu@chromium.org>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Fixes both the "splice/sendfile to a tty" and "splice/sendfile from a
tty" regression from 5.10.
* 'tty-splice' of git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux:
tty: teach the n_tty ICANON case about the new "cookie continuations" too
tty: teach n_tty line discipline about the new "cookie continuations"
tty: clean up legacy leftovers from n_tty line discipline
tty: implement read_iter
tty: convert tty_ldisc_ops 'read()' function to take a kernel pointer
tty: implement write_iter
The tty line discipline .read() function was passed the final user
pointer destination as an argument, which doesn't match the 'write()'
function, and makes it very inconvenient to do a splice method for
ttys.
This is a conversion to use a kernel buffer instead.
NOTE! It does this by passing the tty line discipline ->read() function
an additional "cookie" to fill in, and an offset into the cookie data.
The line discipline can fill in the cookie data with its own private
information, and then the reader will repeat the read until either the
cookie is cleared or it runs out of data.
The only real user of this is N_HDLC, which can use this to handle big
packets, even if the kernel buffer is smaller than the whole packet.
Cc: Christoph Hellwig <hch@lst.de>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Al Viro <viro@zeniv.linux.org.uk>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
During SSR after memory dump collection,BT controller will be powered off,
powered on and then FW will be downloaded.During suspend if BT controller
is powered off due to SSR then we should wait until SSR is completed and
then suspend.
Fixes: 2be43abac5 ("Bluetooth: hci_qca: Wait for timeout during suspend")
Signed-off-by: Venkata Lakshmi Narayana Gubba <gubbaven@codeaurora.org>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
When __le32_to_cpu() fails, qca_memdump should be freed
just like when vmalloc() fails.
Fixes: d841502c79 ("Bluetooth: hci_qca: Collect controller memory dump during SSR")
Signed-off-by: Dinghao Liu <dinghao.liu@zju.edu.cn>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
RTL8723DS could be handled by btrtl-driver, so add ability to bind it
using device tree.
Signed-off-by: John-Eric Kamps <johnny86@gmx.de>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
btrtl_dev->ic_info is only available from the controller on cold boot
(the lmp subversion matches the device model and this is used to look up
the ic_info). On warm boots (firmware already loaded),
btrtl_dev->ic_info is null.
Fixes: 05672a2c14 (Bluetooth: btrtl: Enable central-peripheral role)
Signed-off-by: Abhishek Pandit-Subedi <abhishekpandit@chromium.org>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Enable the central-peripheral role on RTL8822CE. This enables creating
connections while there is an existing connection in the slave role.
This change can be confirmed in userspace via `bluetoothctl show` which
will now show "Roles: central-peripheral".
Reviewed-by: Daniel Winkler <danielwinkler@google.com>
Signed-off-by: Abhishek Pandit-Subedi <abhishekpandit@chromium.org>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
This reverts commit a63f23c9d139377833a139b179793fea79ee198f.
get_unaligned_{le16|le32|le64}(p) is meant to replace code of the form
le16_to_cpu(get_unaligned((__le16 *)p)). There is no need to explicitly
do leXX_to_cpu() if get_unaligned_leXX() is used.
https://lwn.net/Articles/277779/
Reported-by: kernel test robot <lkp@intel.com>
Signed-off-by: Kiran K <kiran.k@intel.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
This enables bcm driver to properly handle ISO packets.
Signed-off-by: Jakub Pawlowski <jpawlowski@google.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
The Realtek RTL8822CE Bluetooth controller support Microsoft vendor
extension and it uses 0xFCF0 for VsMsftOpCode.
The following test step was performed.
- Boot the test device with RTL8822CE and verify the INFO print in
dmesg.
Signed-off-by: Miao-chen Chou <mcchou@chromium.org>
Reviewed-by: Abhishek Pandit-Subedi <abhishekpandit@chromium.org>
Reviewed-by: Archie Pusaka <apusaka@chromium.org>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
The Intel JeffersonPeak, HarrisonPeak and CyclonePeak Bluetooth
controllers support the Microsoft vendor extension and they are using
0xFC1E for VsMsftOpCode.
< HCI Command: Vendor (0x3f|0x001e) plen 1
00
> HCI Event: Command Complete (0x0e) plen 15
Vendor (0x3f|0x001e) ncmd 1
Status: Success (0x00)
00 3f 00 00 00 00 00 00 00 01 50
The following test step was performed.
- Boot the test devices with HarrisonPeak and verify INFO print in
dmesg.
Signed-off-by: Miao-chen Chou <mcchou@chromium.org>
Reviewed-by: Abhishek Pandit-Subedi <abhishekpandit@chromium.org>
Reviewed-by: Archie Pusaka <apusaka@chromium.org>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
The following Qualcomm WCN399x Bluetooth controllers support the
Microsoft vendor extension and they are using 0xFD70 for VsMsftOpCode.
-WCN3990
-WCN3991
-WCN3998
< HCI Command: ogf 0x3f, ocf 0x0170, plen 1
00
> HCI Event: 0x0e plen 18
01 70 FD 00 00 1F 00 00 00 00 00 00 00 04 4D 53 46 54
The following test step was performed.
- Boot the device with WCN3991 and verify INFO print in dmesg.
Signed-off-by: Miao-chen Chou <mcchou@chromium.org>
Reviewed-by: Abhishek Pandit-Subedi <abhishekpandit@chromium.org>
Reviewed-by: Archie Pusaka <apusaka@chromium.org>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
we should send hci reset command before bt turn off, which can reset bt
firmware status.
Signed-off-by: Tim Jiang <tjiang@codeaurora.org>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
In hci_uart_write_work, there is a loop/goto checking the value of
HCI_UART_TX_WAKEUP. If HCI_UART_TX_WAKEUP is set again, it keeps trying
hci_uart_dequeue; otherwise, it clears HCI_UART_SENDING and returns.
In hci_uart_tx_wakeup, if HCI_UART_SENDING is already set, it sets
HCI_UART_TX_WAKEUP, skips schedule_work and assumes the running/pending
hci_uart_write_work worker will do hci_uart_dequeue properly.
However, if the HCI_UART_SENDING check in hci_uart_tx_wakeup is done after
the loop breaks, but before HCI_UART_SENDING is cleared in
hci_uart_write_work, the schedule_work is skipped incorrectly.
Fix this race by changing the order of HCI_UART_SENDING and
HCI_UART_TX_WAKEUP modification.
Fixes: 1da177e4c3 ("Linux-2.6.12-rc2")
Fixes: 82f5169bf3 ("Bluetooth: hci_uart: add serdev driver support library")
Signed-off-by: Claire Chang <tientzu@chromium.org>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Add support to read FW build version from debugfs node.
This info can be read from
/sys/kernel/debug/bluetooth/hci0/firmware_info
Signed-off-by: Venkata Lakshmi Narayana Gubba <gubbaven@codeaurora.org>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
When alt mode 6 is not available, fallback to the kernel <= 5.7 behavior
of always using alt mode 1.
Prior to kernel 5.8, btusb would always use alt mode 1 for WBS (Wide
Band Speech aka mSBC aka transparent SCO). In commit baac6276c0
("Bluetooth: btusb: handle mSBC audio over USB Endpoints") this
was changed to use alt mode 6, which is the recommended mode in the
Bluetooth spec (Specifications of the Bluetooth System, v5.0, Vol 4.B
§2.2.1). However, many if not most BT USB adapters do not support alt
mode 6. In fact, I have been unable to find any which do.
In kernel 5.8, this was changed to use alt mode 6, and if not available,
use alt mode 0. But mode 0 has a zero byte max packet length and can
not possibly work. It is just there as a zero-bandwidth dummy mode to
work around a USB flaw that would prevent device enumeration if
insufficient bandwidth were available for the lowest isoc mode
supported.
In effect, WBS was broken for all USB-BT adapters that do not support
alt 6, which appears to nearly all of them.
Then in commit 461f95f04f ("Bluetooth: btusb: USB alternate setting 1 for
WBS") the 5.7 behavior was restored, but only for Realtek adapters.
I've tested a Broadcom BRCM20702A and CSR 8510 adapter, both work with
the 5.7 behavior and do not with the 5.8.
So get rid of the Realtek specific flag and use the 5.7 behavior for all
adapters as a fallback when alt 6 is not available. This was the
kernel's behavior prior to 5.8 and I can find no adapters for which it
is not correct. And even if there is an adapter for which this does not
work, the current behavior would be to fall back to alt 0, which can not
possibly work either, and so is no better.
Signed-off-by: Trent Piepho <tpiepho@gmail.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Some resource should be released in the error handling path of the probe
function, as already done in the remove function.
The remove function was fixed in commit 5052de8def ("soc: qcom: smd:
Transition client drivers from smd to rpmsg")
Fixes: 1511cc750c ("Bluetooth: Introduce Qualcomm WCNSS SMD based HCI driver")
Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
With the recent btusb change to detect and deal with more fake CSR
controllers, I decided to see if fake CSR controllers with Barrot
8041a02 chips would now work.
After much experimentation I came to the conclusion that it works, if I
have autosuspend enabled initially and then disable it after the device
has suspended at least once. Yes this is very weird, but I've tried many
things, like manually clearing the remote-wakeup feature. Doing a
runtime-resume + runtime suspend is the only way to get the receiver
to actually report received data (and/or pairing info) through its
bulk rx endpoint.
But the funkyness of the bulk-endpoint does not stop there, I mainly
found out about this problem, because with autosuspend enabled
(which usually ensures the suspend at least once condition is met),
the receiver stops reporting received data through its bulk rx endpoint
as soon as autosuspend kicks in. So I initially just disabled
autosuspend, but then the receiver does not work at all.
This was with a fake CSR receiver with a Barrot 8041a02 chip with a
bcdDevice value of 0x8891, a lmp_subver of 0x1012, a hci_rev of 0x0810
and a hci_ver of BLUETOOTH_VER_4_0.
Summarizing this specific fake CSR receiver has the following 2 issues:
1. The bulk rx endpoint will never report any data unless
the device was suspended at least once.
2. They will not wakeup when autosuspended and receiving data on their
bulk rx endpoint from e.g. a keyboard or mouse (IOW remote-wakeup support
is broken for the bulk endpoint).
Add a workaround for 1. which enables runtime-suspend, force-suspends
the hci and then wakes-it up by disabling runtime-suspend again.
Add a workaround for 2. which clears the hci's can_wake flag, this way
the hci will still be autosuspended when it is not open.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Commit cde1a8a992 ("Bluetooth: btusb: Fix and detect most of the
Chinese Bluetooth controllers") made the detection of fake controllers
more generic fixing it for much of the newer fakes / clones.
But this does not work for a fake CSR controller with a bcdDevice
value of 0x0134, which was correctly identified as fake before
this change.
Add an extra check for this special case, checking for a combination
of a bcdDevice value of 0x0134, together with a lmp_subver of 0x0c5c
and a hci_ver of BLUETOOTH_VER_2_0.
The chip inside this fake dongle is marked as with "clockwise cw6629d".
Fixes: cde1a8a992 ("Bluetooth: btusb: Fix and detect most of the Chinese Bluetooth controllers")
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
we define many nvm files for wcn6855 btsoc and host driver
should find the correct nvm file based on board ID and then
download it.
Signed-off-by: Tim Jiang <tjiang@codeaurora.org>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Define a new function to construct firmware/ddc filename for new
generation Intel controllers
Signed-off-by: Kiran K <kiran.k@intel.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
mtk_setup_firmware() misses to call release_firmware() in an error
path. Jump to free_fw to fix it.
Fixes: 737cd06072 ("Bluetooth: btmtksdio: fix up firmware download sequence")
Signed-off-by: Jing Xiangfeng <jingxiangfeng@huawei.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
btusb_mtk_setup_firmware() misses to call release_firmware() in an error
path. Jump to err_release_fw to fix it.
Fixes: f645125711 ("Bluetooth: btusb: fix up firmware download sequence")
Signed-off-by: Jing Xiangfeng <jingxiangfeng@huawei.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
This change will allow to use different NVM file based
on WCN3991 BT SoC ID.Need to use different NVM file based on
fab location for WCN3991 BT SoC.
Signed-off-by: Venkata Lakshmi Narayana Gubba <gubbaven@codeaurora.org>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
There have been multiple revisions of the patch fix the h5->rx_skb
leak. Accidentally the first revision (which is buggy) and v5 have
both been merged:
v1 commit 70f259a3f4 ("Bluetooth: hci_h5: close serdev device and free
hu in h5_close");
v5 commit 855af2d74c ("Bluetooth: hci_h5: fix memory leak in h5_close")
The correct v5 makes changes slightly higher up in the h5_close()
function, which allowed both versions to get merged without conflict.
The changes from v1 unconditionally frees the h5 data struct, this
is wrong because in the serdev enumeration case the memory is
allocated in h5_serdev_probe() like this:
h5 = devm_kzalloc(dev, sizeof(*h5), GFP_KERNEL);
So its lifetime is tied to the lifetime of the driver being bound
to the serdev and it is automatically freed when the driver gets
unbound. In the serdev case the same h5 struct is re-used over
h5_close() and h5_open() calls and thus MUST not be free-ed in
h5_close().
The serdev_device_close() added to h5_close() is incorrect in the
same way, serdev_device_close() is called on driver unbound too and
also MUST no be called from h5_close().
This reverts the changes made by merging v1 of the patch, so that
just the changes of the correct v5 remain.
Cc: Anant Thazhemadam <anant.thazhemadam@gmail.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Currently qca_suspend() is relied on IBS mechanism. During
FW download and memory dump collections, IBS will be disabled.
In those cases, driver will allow suspend and still uses the
serdev port, which results to errors. Now added a wait timeout
if suspend is triggered during FW download and memory collections.
Signed-off-by: Venkata Lakshmi Narayana Gubba <gubbaven@codeaurora.org>
Signed-off-by: Balakrishna Godavarthi <bgodavar@codeaurora.org>
Reviewed-by: Abhishek Pandit-Subedi <abhishekpandit@chromium.org>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Currently the check for a failed bt_skb_alloc allocation is incorrectly
checking using IS_ERR and this can lead to a null pointer dereference. Fix
this by checking for a null pointer return using the !skb idiom.
Addresses-Coverity: ("Dereference null return")
Fixes: 1996d9cad6 ("Bluetooth: btrtl: Ask 8821C to drop old firmware")
Signed-off-by: Colin Ian King <colin.king@canonical.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
When using the wl1271 Bluetooth function of am335x, it is found that the
Bluetooth module cannot respond in time after Bluetooth is enabled, and
a small delay is needed to work normally, so whether to add a small
mdelay.
Signed-off-by: Xiaolei Wang <xiaolei.wang@windriver.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Replace symbolic permissions with octal values. Use usleep_range
for small msec values due to the fact that msleep() less than
20ms may have unexpected behavior/sleep longer.
- https://lkml.org/lkml/2016/8/2/1945
- Documentation/timers/timers-howto.rst
Signed-off-by: Nigel Christian <nigel.l.christian@gmail.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Currently driver only retries to download FW if FW downloading
is failed. Sometimes observed command timeout for version request
command, if this happen on some platforms during boot time, then
a reboot is needed to turn ON BT. Instead to avoid a reboot, now
extended retry logic for version request command too.
Signed-off-by: Balakrishna Godavarthi <bgodavar@codeaurora.org>
Reviewed-by: Abhishek Pandit-Subedi <abhishekpandit@chromium.org>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Some platforms keep USB power even when they are powered off and in S5,
this makes Realtek 8821C keep its firmware even after a cold boot, and
make 8821C never load new firmware.
So use vendor specific HCI command to ask 8821C drop its firmware after
system shutdown.
Newer firmware doesn't have this issue so we only use this trick for old
8821C firmware version.
Suggested-by: Max Chou <max.chou@realtek.com>
Signed-off-by: Kai-Heng Feng <kai.heng.feng@canonical.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Enhance the ic_id_table that it's able to maintain regularly.
To judge which chip should be initialized by LMP subversion, HCI revision,
HCI version and HCI bus which were given in the ic_id_table.
Also, refine the incorrect LMP subversion of ROM for RTL8723D and
RTL8723A.
Suggested-by: Alex Lu <alex_lu@realsil.com.cn>
Signed-off-by: Max Chou <max.chou@realtek.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
