| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
After commit 9e45524a0111 ("Bluetooth: btusb: Fix suspend issue for
Realtek devices") both WiFi and Bluetooth stop working after reboot:
[ 34.322617] usb 1-8: reset full-speed USB device number 3 using xhci_hcd
[ 34.450401] usb 1-8: device descriptor read/64, error -71
[ 34.694375] usb 1-8: device descriptor read/64, error -71
...
[ 44.599111] rtw_pci 0000:02:00.0: failed to poll offset=0x5 mask=0x3 value=0x0
[ 44.599113] rtw_pci 0000:02:00.0: mac power on failed
[ 44.599114] rtw_pci 0000:02:00.0: failed to power on mac
[ 44.599114] rtw_pci 0000:02:00.0: leave idle state failed
[ 44.599492] rtw_pci 0000:02:00.0: failed to leave ips state
[ 44.599493] rtw_pci 0000:02:00.0: failed to leave idle state
That commit removed USB_QUIRK_RESET_RESUME, which not only resets the USB
device after resume, it also prevents the device from being runtime
suspended by USB core. My experiment shows if the Realtek btusb device
ever runtime suspends once, the entire wireless module becomes useless
after reboot.
So let's explicitly disable runtime suspend on Realtek btusb device for
now.
Fixes: 9e45524a0111 ("Bluetooth: btusb: Fix suspend issue for Realtek devices")
Signed-off-by: Kai-Heng Feng <kai.heng.feng@canonical.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
|
|
Currently the error return path when the call to btusb_mtk_hci_wmt_sync
fails does not free fw. Fix this by returning via the error_release_fw
label that performs the free'ing.
Addresses-Coverity: ("Resource leak")
Fixes: a1c49c434e15 ("Bluetooth: btusb: Add protocol support for MediaTek MT7668U USB devices")
Signed-off-by: Colin Ian King <colin.king@canonical.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
|
|
USB completion handlers are called in atomic context and must
specifically not allocate memory using GFP_KERNEL.
Fixes: a1c49c434e15 ("Bluetooth: btusb: Add protocol support for MediaTek MT7668U USB devices")
Cc: stable <stable@vger.kernel.org> # 5.3
Cc: Sean Wang <sean.wang@mediatek.com>
Signed-off-by: Johan Hovold <johan@kernel.org>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
|
|
BCM chips may require configuration of PCM to operate correctly and
there is a vendor specific HCI command to do this. Add support in the
hci_bcm driver to parse this from devicetree and configure the chip.
Signed-off-by: Abhishek Pandit-Subedi <abhishekpandit@chromium.org>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
|
|
Add BCM vendor specific command to configure PCM parameters. The new
vendor opcode allows us to set the sco routing, the pcm interface rate,
and a few other pcm specific options (frame sync, sync mode, and clock
mode). See broadcom-bluetooth.txt in Documentation for more information
about valid values for those settings.
Here is an example trace where this opcode was used to configure
a BCM4354:
< HCI Command: Vendor (0x3f|0x001c) plen 5
01 02 00 01 01
> HCI Event: Command Complete (0x0e) plen 4
Vendor (0x3f|0x001c) ncmd 1
Status: Success (0x00)
We can read back the values as well with ocf 0x001d to confirm the
values that were set:
$ hcitool cmd 0x3f 0x001d
< HCI Command: ogf 0x3f, ocf 0x001d, plen 0
> HCI Event: 0x0e plen 9
01 1D FC 00 01 02 00 01 01
Signed-off-by: Abhishek Pandit-Subedi <abhishekpandit@chromium.org>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
|
|
Without updating the patchram, the BCM4354 does not support a higher
operating speed. The normal bcm_setup follows the correct order
(init_speed, patchram and then oper_speed) but the serdev driver will
set the operating speed before calling the hu->setup function. Thus,
for the BCM4354, don't set the operating speed before patchram.
Signed-off-by: Abhishek Pandit-Subedi <abhishekpandit@chromium.org>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
|
|
It should be pull low and pull high on the physical line for the Realtek
Bluetooth reset. gpiod_set_value_cansleep() takes ACTIVE_LOW status for
the logical value settings, so the original commit should be corrected.
Signed-off-by: Max Chou <max.chou@realtek.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
|
|
Some devices ship with the controller default address, like the
Orange Pi 3 (BCM4345C5).
Allow the bootloader to set a valid address through the device tree.
Signed-off-by: Andre Heider <a.heider@gmail.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
|
|
This patch adds the device ID for the BCM4335A0 module
(part of the AMPAK AP6335 WIFI/Bluetooth combo)
hciconfig output:
```
hci1: Type: Primary Bus: UART
BD Address: 43:35:B0:07:1F:AC ACL MTU: 1021:8 SCO MTU: 64:1
UP RUNNING
RX bytes:5079 acl:0 sco:0 events:567 errors:0
TX bytes:69065 acl:0 sco:0 commands:567 errors:0
Features: 0xbf 0xfe 0xcf 0xff 0xdf 0xff 0x7b 0x87
Packet type: DM1 DM3 DM5 DH1 DH3 DH5 HV1 HV2 HV3
Link policy: RSWITCH SNIFF
Link mode: SLAVE ACCEPT
Name: 'alarm'
Class: 0x000000
Service Classes: Unspecified
Device Class: Miscellaneous,
HCI Version: 4.0 (0x6) Revision: 0x161
LMP Version: 4.0 (0x6) Subversion: 0x4106
Manufacturer: Broadcom Corporation (15)
```
Signed-off-by: Mohammad Rasim <mohammad.rasim96@gmail.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
|
|
Add the device ID for the WiFi/BT/FM combo chip BCM4334 (rev B0).
The chip seems to use 43:34:b0:00:00:00 as default address,
so add it to the list of default addresses and leave it up
to the user to configure a valid one.
Signed-off-by: Stephan Gerhold <stephan@gerhold.net>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
|
|
If setup() fails a reference for runtime PM has already
been taken. Proper use of the error handling in btusb_open()is needed.
You cannot just return.
Fixes: ace31982585a3 ("Bluetooth: btusb: Add setup callback for chip init on USB")
Signed-off-by: Oliver Neukum <oneukum@suse.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
|
|
This patch add support for WCN3991 i.e. current values and fw download
support.
Signed-off-by: Balakrishna Godavarthi <bgodavar@codeaurora.org>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
|
|
Variables which are named with rome are commonly used for all the
BT SoC's. Instead of continuing further, renamed them to generic
name.
Signed-off-by: Balakrishna Godavarthi <bgodavar@codeaurora.org>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
|
|
This adds the missing MODULE_DEVICE_TABLE() for SDIO IDs. While certain
platforms using this driver indeed have HW issues causing problems if
the module is loaded too early - this should be handled from user-space
by blacklisting it or delaying the loading.
Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
|
|
Syzbot reported an invalid-free that I introduced fixing a memleak.
bcsp_recv() also frees bcsp->rx_skb but never nullifies its value.
Nullify bcsp->rx_skb every time it is freed.
Signed-off-by: Tomas Bortoli <tomasbortoli@gmail.com>
Reported-by: syzbot+a0d209a4676664613e76@syzkaller.appspotmail.com
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
|
|
Add PM suspend/resume callbacks for hci_qca driver.
BT host will make sure both Rx and Tx go into sleep state in
qca_suspend. Without this, Tx may still remain in awake state, which
prevents BTSOC from entering deep sleep. For example, BlueZ will send
Set Event Mask to device when suspending and this will wake the device
Rx up. However, the Tx idle timeout on the host side is 2000 ms. If the
host is suspended before its Tx idle times out, it won't send
HCI_IBS_SLEEP_IND to the device and the device Rx will remain awake.
We implement this by canceling relevant work in workqueue, sending
HCI_IBS_SLEEP_IND to the device and then waiting HCI_IBS_SLEEP_IND sent
by the device.
In order to prevent the device from being awaken again after qca_suspend
is called, we introduce QCA_SUSPEND flag. QCA_SUSPEND is set in the
beginning of qca_suspend to indicate system is suspending and that we'd
like to ignore any further wake events.
With QCA_SUSPEND and spinlock, we can avoid race condition, e.g. if
qca_enqueue acquires qca->hci_ibs_lock before qca_suspend calls
cancel_work_sync and then qca_enqueue adds a new qca->ws_awake_device
work after the previous one is cancelled.
If BTSOC wants to wake the whole system up after qca_suspend is called,
it will keep sending HCI_IBS_WAKE_IND and uart driver will take care of
waking the system. For example, uart driver will reconfigure its Rx pin
to a normal GPIO pin and enable irq wake on that pin when suspending.
Once host detects Rx falling, the system will begin resuming. Then, the
BT host clears QCA_SUSPEND flag in qca_resume and begins dealing with
normal HCI packets. By doing so, only a few HCI_IBS_WAKE_IND packets are
lost and there is no data packet loss.
Signed-off-by: Claire Chang <tientzu@chromium.org>
Reviewed-by: Balakrishna Godavarthi <bgodavar@codeaurora.org>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
|
|
The BCM43540 chip is a 802.11 a/b/g/n/ac + Bluetooth 4.1 combo module.
This patch adds a compatible string match to the serdev driver for the
Bluetooth part of the chip.
Signed-off-by: Abhishek Pandit-Subedi <abhishekpandit@chromium.org>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
|
|
Remove unneeded semicolon.
This is detected by coccinelle.
Signed-off-by: YueHaibing <yuehaibing@huawei.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
|
|
The RPi 4 uses the hardware handshake lines for CYW43455, but the chip
doesn't react to HCI requests during DT probe. The reason is the inproper
handling of the RTS line during startup. According to the startup
signaling sequence in the CYW43455 datasheet, the hosts RTS line must
be driven after BT_REG_ON and BT_HOST_WAKE.
Signed-off-by: Stefan Wahren <wahrenst@gmx.net>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
|
|
This reverts commit cde9dde6e11a5ab54b6462cd46d82878926783bc.
The frame reassembly errors were root caused to a transient gpio issue.
The missing response was root caused to an issue with properly managing
RFR in the uart driver. Addressing those root causes occurs outside of
hci_qca and eliminates the need for the 50ms delay, so remove it.
Signed-off-by: Jeffrey Hugo <jeffrey.l.hugo@gmail.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
|
|
When building with Clang and CONFIG_BT_INTEL unset, the following error
occurs:
In file included from drivers/bluetooth/hci_ldisc.c:34:
drivers/bluetooth/btintel.h:188:2: error: void function
'btintel_reset_to_bootloader' should not return a value [-Wreturn-type]
return -EOPNOTSUPP;
^ ~~~~~~~~~~~
1 error generated.
Remove the unneeded return statement to fix this.
Fixes: b9a2562f4918 ("Bluetooth: btusb: Trigger Intel FW download error recovery")
Link: https://github.com/ClangBuiltLinux/linux/issues/743
Reported-by: <ci_notify@linaro.org>
Reported-by: Stephen Rothwell <sfr@canb.auug.org.au>
Signed-off-by: Nathan Chancellor <natechancellor@gmail.com>
Reviewed-by: Nick Desaulniers <ndesaulniers@google.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
|
|
Split and rename qca_power_setup() in order to simplify each code path
and to clarify that it is unrelated to qca_power_off() and
qca_power_setup().
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
|
|
With the regulator_set_load() and regulator_set_voltage() out of the
enable/disable code paths the code can now use the standard
regulator bulk enable/disable API.
By cloning num_vregs into struct qca_power there's no need to lug around
a reference to the struct qca_vreg_data, which further simplifies
qca_power_setup().
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
|
|
Devices with specific voltage requirements should not request voltage
from the driver, but instead rely on the system configuration to define
appropriate voltages for each rail.
This ensures that PMIC and board variations are accounted for, something
that the 0.1V range in the hci_qca driver currently tries to address.
But on the Lenovo Yoga C630 (with wcn3990) vddch0 is 3.1V, which means
the driver will fail to set the voltage.
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
|
|
Since the introduction of '5451781dadf8 ("regulator: core: Only count
load for enabled consumers")' in v5.0, the requested load of a regulator
consumer is only accounted for when said consumer is voted enabled.
So there's no need to vote for load ever time the regulator is
enabled or disabled.
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
|
|
On the msm8998 mtp, the response to the baudrate change command is never
received. On the Lenovo Miix 630, the response to the baudrate change
command is corrupted - "Frame reassembly failed (-84)".
Adding a 50ms delay before re-enabling flow to receive the baudrate change
command response from the wcn3990 addesses both issues, and allows
bluetooth to become functional.
Signed-off-by: Jeffrey Hugo <jeffrey.l.hugo@gmail.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
|
|
Sometimes during FW data download stage, in case of an error is
encountered the controller device could not be recovered. To recover
from such failures send Intel hard Reset to re-trigger FW download in
following error scenarios:
1. Intel Read version command error
2. Firmware download timeout
3. Failure in Intel Soft Reset for switching to operational FW
4. Boot timeout for switching to operaional FW
Signed-off-by: Raghuram Hegde <raghuram.hegde@intel.com>
Signed-off-by: Chethan T N <chethan.tumkur.narayan@intel.com>
Signed-off-by: Amit K Bag <amit.k.bag@intel.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
|
|
All users of this driver have been converted to the serdev based
hci_ll driver. The unused driver can be safely dropped now.
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
|
|
As nice as it would be to update firmware faster, that patch broke
at least two different boards, an OMAP4+WL1285 based Motorola Droid
4, as reported by Sebasian Reichel and the Logic PD i.MX6Q +
WL1837MOD.
This reverts commit a2e02f38eff84f199c8e32359eb213f81f270047.
Signed-off-by: Adam Ford <aford173@gmail.com>
Acked-by: Sebastian Reichel <sebastian.reichel@collabora.com>
Cc: stable@vger.kernel.org
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
|
|
For the different hardware support options, it is better to use
IS_ENABLED check. Let the compiler do the needed optimizations.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
|
|
The btusb_rtl_cmd_timeout() function is used inside of an
ifdef, leading to a warning when this part is hidden
from the compiler:
drivers/bluetooth/btusb.c:530:13: error: unused function 'btusb_rtl_cmd_timeout' [-Werror,-Wunused-function]
Use an IS_ENABLED() check instead so the compiler can see
the code and then discard it silently.
Fixes: d7ef0d1e3968 ("Bluetooth: btusb: Use cmd_timeout to reset Realtek device")
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
|
|
After FW download there is no print to confirm the current
FW version. Add print to check FW version incase of FW download.
Signed-off-by: Amit K Bag <amit.k.bag@intel.com>
Signed-off-by: Yoni Shavit <yshavit@chromium.org>
Signed-off-by: Chethan Tumkur Narayan <chethan.tumkur.narayan@intel.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
|
|
It does not need the '-' for PTR_ERR(skb) because PTR_ERR(skb) will
return the negative value during errors.
Signed-off-by: Max Chou <max.chou@realtek.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
|
|
'skb_pad()' a few lines above already initializes the "padded" byte to 0.
So there is no need to do it twice.
All what is needed is to increase the len of the skb. So 'skb_put(..., 1)'
is enough here.
Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
|
|
Minor overlapping changes in the btusb and ixgbe drivers.
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
Realtek Bluetooth controller provides a BT_DIS reset pin for hardware
reset of it. The cmd_timeout is helpful on Realtek bluetooth controller
where the firmware gets stuck.
Signed-off-by: Alex Lu <alex_lu@realsil.com.cn>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
|
|
Fix the issue that when the FW size is 32K+, it will fail for the download
process because of the incorrect index.
When firmware patch length is over 32K, "dl_cmd->index" may >= 0x80. It
will be thought as "data end" that download process will not complete.
However, driver should recount the index from 1.
Signed-off-by: Max Chou <max.chou@realtek.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
|
|
These printing macros already add a trailing newline, so drop these
unnecessary additional newlines.
Signed-off-by: Alex Lu <alex_lu@realsil.com.cn>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
|
|
the rtl: or RTL: prefix in the string is pointless. The rtl_dev_* macros
already does that.
Signed-off-by: Alex Lu <alex_lu@realsil.com.cn>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
|
|
This patch is used to print fw version for debug convenience
Signed-off-by: Alex Lu <alex_lu@realsil.com.cn>
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: Alex Lu <alex_lu@realsil.com.cn>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
|
|
When SoC receives pre shut down command, it share the same
with other COEX shared clients. So SoC needs a short time
after sending VS pre shutdown command before turning off
the regulators and sending the power off pulse. Along with
short delay, needs to wait for command complete event for
Pre shutdown VS command
Signed-off-by: Harish Bandi <c-hbandi@codeaurora.org>
Reviewed-by: Balakrishna Godavarthi <bgodavar@codeaurora.org>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
|
|
Some supported devices need more time to come out of reset (eg.
BCM4345C5 in AP6256).
I don't have/found a datasheet, so the value was arrive at
experimentally with the Oprange Pi 3 board. Without increased delay,
I got intermittent failures during probe. This is a Bluetooth 5.0
device, so maybe that's why it takes longer to initialize than the
others.
Signed-off-by: Ondrej Jirman <megous@megous.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
|
|
Detect BCM4345C5 and load a corresponding firmware file.
Signed-off-by: Ondrej Jirman <megous@megous.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
|
|
QCA UART Bluetooth controllers can do both LE scan and BR/EDR inquiry
at once, need to set HCI_QUIRK_SIMULTANEOUS_DISCOVERY quirk.
Signed-off-by: Rocky Liao <rjliao@codeaurora.org>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
|
|
Static structure qca_proto, of type hci_uart_proto, is used four times:
as the last argument in function hci_uart_register_device(), and as the
only argument to functions hci_uart_register_proto() and
hci_uart_unregister_proto(). In all three of these functions, the
parameter corresponding to qca_proto is declared as constant. Therefore,
make qca_proto itself constant as well in order to protect it from
unintended modification.
Issue found with Coccinelle.
Signed-off-by: Nishka Dasgupta <nishkadg.linux@gmail.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
|
|
From the perspective of controller, global suspend means there is no
SET_FEATURE (DEVICE_REMOTE_WAKEUP) and controller would drop the
firmware. It would consume less power. So we should not send this kind
of SET_FEATURE when host goes to suspend state.
Otherwise, when making device enter selective suspend, host should send
SET_FEATURE to make sure the firmware remains.
Signed-off-by: Alex Lu <alex_lu@realsil.com.cn>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
|
|
If CONFIG_ACPI is not set, gcc warn this:
drivers/bluetooth/hci_bcm.c:831:39: warning:
acpi_bcm_int_last_gpios defined but not used [-Wunused-const-variable=]
drivers/bluetooth/hci_bcm.c:838:39: warning:
acpi_bcm_int_first_gpios defined but not used [-Wunused-const-variable=]
move them to #ifdef CONFIG_ACPI block.
Reported-by: Hulk Robot <hulkci@huawei.com>
Signed-off-by: YueHaibing <yuehaibing@huawei.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
|
|
The qca_data structure is allocated with kzalloc() and hence
zero-initialized. Remove a bunch of unnecessary explicit
initializations of struct members to zero.
Signed-off-by: Matthias Kaehlcke <mka@chromium.org>
Reviewed-by: Balakrishna Godavarthi <bgodavar@codeaurora.org>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
|
|
When returning from bpa10x_send_frame, it is necessary to propagate any
potential errno returned from usb_submit_urb.
Signed-off-by: Navid Emamdoost <navid.emamdoost@gmail.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
|
Kai-Heng Feng
Colin Ian King
Johan Hovold
Abhishek Pandit-Subedi
Max Chou
Andre Heider
Mohammad Rasim
Stephan Gerhold
Oliver Neukum
Balakrishna Godavarthi
Bartosz Golaszewski
Tomas Bortoli
Claire Chang
YueHaibing
Stefan Wahren
Jeffrey Hugo
Nathan Chancellor
Bjorn Andersson
Amit K Bag
Sebastian Reichel
Adam Ford
Marcel Holtmann
Arnd Bergmann
Christophe JAILLET
David S. Miller
Alex Lu
Harish Bandi
Ondrej Jirman
Rocky Liao
Nishka Dasgupta
Matthias Kaehlcke
Navid Emamdoost