06 May, 2019
2 commits
-
Rename STATE_IN_BAND_SLEEP_ENABLED to QCA_IBS_ENABLED. The constant
represents a flag (multiple flags can be set at once), not a unique
state of the controller or driver.Also make the flag an enum value instead of a pre-processor constant
(more flags will be added to the enum group by another patch).Signed-off-by: Matthias Kaehlcke
Reviewed-by: Balakrishna Godavarthi
Signed-off-by: Marcel Holtmann -
BCM2076B1 appears to use 20:76:A0:00:56:79 as default address.
This address is used by at least 5 devices with the AMPAK AP6476
module and is also suspicious because it starts with the chip name
2076 (followed by a different revision A0 for some reason).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
Signed-off-by: Marcel Holtmann
03 May, 2019
1 commit
-
Added new compatible for WCN3998 and corresponding voltage
and current values to WCN3998 compatible.
Changed driver code to support WCN3998Signed-off-by: Harish Bandi
Reviewed-by: Matthias Kaehlcke
Reviewed-by: Balakrishna Godavarthi
Signed-off-by: Marcel Holtmann
24 Apr, 2019
18 commits
-
qca_set_baudrate() calls serdev_device_wait_until_sent() assuming that
the HCI is always associated with a serdev device. This isn't true for
ROME controllers instantiated through ldisc, where the call causes a
crash due to a NULL pointer dereferentiation. Only call the function
when we have a serdev device. The timeout for ROME devices at the end
of qca_set_baudrate() is long enough to be reasonably sure that the
command was sent.Fixes: fa9ad876b8e0 ("Bluetooth: hci_qca: Add support for Qualcomm Bluetooth chip wcn3990")
Reported-by: Balakrishna Godavarthi
Reported-by: Rocky Liao
Signed-off-by: Matthias Kaehlcke
Reviewed-by: Rocky Liao
Tested-by: Rocky Liao
Reviewed-by: Balakrishna Godavarthi
Signed-off-by: Marcel Holtmann -
This patch enables enough time to ROME controller to bootup
after we bring the enable pin out of reset.Fixes: 05ba533c5c11 ("Bluetooth: hci_qca: Add serdev support").
Signed-off-by: Balakrishna Godavarthi
Reviewed-by: Rocky Liao
Tested-by: Rocky Liao
Tested-by: Claire Chang
Signed-off-by: Marcel Holtmann -
The code path for Macs goes through bcm_apple_get_resources(), which
skips over the code that sets up the regulator supplies. As a result,
the call to regulator_bulk_enable() / regulator_bulk_disable() results
in a NULL pointer dereference.This was reported on the kernel.org Bugzilla, bug 202963.
Unbreak Broadcom Bluetooth support on Intel Macs by checking if the
supplies were set up before enabling or disabling them.The same does not need to be done for the clocks, as the common clock
framework API checks for NULL pointers.Fixes: 75d11676dccb ("Bluetooth: hci_bcm: Add support for regulator supplies")
Cc: # 5.0.x
Signed-off-by: Chen-Yu Tsai
Tested-by: Imre Kaloz
Signed-off-by: Marcel Holtmann -
Add the device ID for the BT/FM/GPS combo chip BCM2076 (rev B1)
used in the AMPAK AP6476 WiFi/BT/FM/GPS module.Signed-off-by: Stephan Gerhold
Signed-off-by: Marcel Holtmann -
The BCM43341B has the default MAC address 43:34:1B:00:1F:AC if none
is given. This address was found when enabling Bluetooth on multiple
Intel Edison modules. It also contains the sequence 43341B, the name
the chip identifies itself as. Using the same BD_ADDR is problematic
when having multiple Intel Edison modules in each others range.
The default address also has the LAA (locally administered address)
bit set which prevents a BNEP device from being created, needed for
BT tethering.Add this to the list of black listed default MAC addresses and let
the user configure a valid one using f.i.
`btmgmt -i hci0 public-addr xx:xx:xx:xx:xx:xx`Suggested-by: Andy Shevchenko
Signed-off-by: Ferry Toth
Reviewed-by: Andy Shevchenko
Signed-off-by: Marcel Holtmann -
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
Signed-off-by: Marcel Holtmann -
Add runtime PM support to btmtksdio. With this way, there will be the
benefit of the device entering the more power saving state once it is
been a while data traffic is idle.Signed-off-by: Sean Wang
Signed-off-by: Marcel Holtmann -
Accumulate hdev->stat.byte_rx only for valid packets as btmtkuart doing.
Signed-off-by: Sean Wang
Signed-off-by: Marcel Holtmann -
Add a register bit definition about CHLPCR bit 8 because the bit is quite
different in the meaning between reading and writing that bit.The patch adds a definition particularly for the bit read to avoid the
confusion about using write definition to read the bit.Signed-off-by: Sean Wang
Signed-off-by: Marcel Holtmann -
bt_dev logging macros already include a newline at each output
so drop these unnecessary additional newlines in the driver.Signed-off-by: Sean Wang
Signed-off-by: Marcel Holtmann -
There is a spelling mistake in a BT_DBG debug message. Fix it.
Signed-off-by: Colin Ian King
Signed-off-by: Marcel Holtmann -
Fixed warning: incorrect type in assignment reported by kbuild test robot.
The detailed warning is shown as below.make ARCH=x86_64 allmodconfig
make C=1 CF='-fdiagnostic-prefix -D__CHECK_ENDIAN__'All warnings (new ones prefixed by >>):
btmtkuart.c:671:18: sparse: warning: incorrect type in assignment
(different base types)
btmtkuart.c:671:18: sparse: expected unsigned int [usertype] baudrate
btmtkuart.c:671:18: sparse: got restricted __le32 [usertype]sparse warnings: (new ones prefixed by >>)
btmtkuart.c:671:18: sparse: warning: incorrect type in assignment
(different base types)
btmtkuart.c:671:18: sparse: expected unsigned int [usertype] baudrate
btmtkuart.c:671:18: sparse: got restricted __le32 [usertype]vim +671 drivers/bluetooth/btmtkuart.c
659
660 static int btmtkuart_change_baudrate(struct hci_dev *hdev)
661 {
662 struct btmtkuart_dev *bdev = hci_get_drvdata(hdev);
663 struct btmtk_hci_wmt_params wmt_params;
664 u32 baudrate;
665 u8 param;
666 int err;
667
668 /* Indicate the device to enter the probe state the host is
669 * ready to change a new baudrate.
670 */
> 671 baudrate = cpu_to_le32(bdev->desired_speed);
672 wmt_params.op = MTK_WMT_HIF;Fixes: 22eaf6c9946a ("Bluetooth: mediatek: add support for MediaTek MT7663U and MT7668U UART devices")
Reported-by: kernel test robot
Signed-off-by: Sean Wang
Signed-off-by: Marcel Holtmann -
Fixed all the below warnings. They would probably cause the following
error handling path would use the uninitialized value and then produce
unexpected behavior.drivers/bluetooth/btmtksdio.c:470:2: warning: ‘old_len’ may be used
uninitialized in this function [-Wmaybe-uninitialized]
print_hex_dump(KERN_ERR, "err sdio rx: ", DUMP_PREFIX_NONE, 4, 1,
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
old_data, old_len, true);
~~~~~~~~~~~~~~~~~~~~~~~~
drivers/bluetooth/btmtksdio.c:376:15: note: ‘old_len’ was declared here
unsigned int old_len;
^~~~~~~
drivers/bluetooth/btmtksdio.c:470:2: warning: ‘old_data’ may be used
uninitialized in this function [-Wmaybe-uninitialized]
print_hex_dump(KERN_ERR, "err sdio rx: ", DUMP_PREFIX_NONE, 4, 1,
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
old_data, old_len, true);
~~~~~~~~~~~~~~~~~~~~~~~~
drivers/bluetooth/btmtksdio.c:375:17: note: ‘old_data’ was declared here
unsigned char *old_data;
^~~~~~~~v2: Remove old_len and old_data because the error path for sdio_readsb also
seems wrong. And change the prefix from "mediatek" to "btmtksdio".Fixes: d74eef2834b5 ("Bluetooth: mediatek: add support for MediaTek MT7663S and MT7668S SDIO devices")
Reported-by: Dan Carpenter
Reported-by: Marcel Holtmann
Signed-off-by: Sean Wang
Signed-off-by: Marcel Holtmann -
Macro module_sdio_driver is used for drivers whose init and exit paths
only register and unregister to SDIO API. So remove boilerplate code to
make code simpler by using module_sdio_driver.Signed-off-by: Sean Wang
Acked-by: Ulf Hansson
Signed-off-by: Marcel Holtmann -
Macro module_sdio_driver is used for drivers whose init and exit paths
only register and unregister to SDIO API. So remove boilerplate code to
make code simpler by using module_sdio_driver.Suggested-by: Marcel Holtmann
Signed-off-by: Sean Wang
Acked-by: Ulf Hansson
Signed-off-by: Marcel Holtmann -
Rename the misspelled struct 'qca_bardrate' to 'qca_baudrate'
Signed-off-by: Matthias Kaehlcke
Signed-off-by: Marcel Holtmann -
Many functions obtain a 'struct qca_serdev' only to read the btsoc_type
field. Add a helper function that encapsulates this.This also fixes crashes observed on platforms with ROME controllers
that are instantiated through ldisc and not as serdev clients. The
crashes are caused by NULL pointer dereferentiations, which stem from
the driver's assumption that a QCA HCI device is always associated with
a serdev device.Fixes: fa9ad876b8e0 ("Bluetooth: hci_qca: Add support for Qualcomm Bluetooth chip wcn3990")
Reported-by: Balakrishna Godavarthi
Signed-off-by: Matthias Kaehlcke
Signed-off-by: Marcel Holtmann -
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
Signed-off-by: Marcel Holtmann
10 Apr, 2019
1 commit
-
Badly-designed systems might have (for example) active-high wake pins
that default to high (e.g., because of external pull ups) until they
have an active firmware which starts driving it low. This can cause an
interrupt storm in the time between request_irq() and disable_irq().We don't support shared interrupts here, so let's just pre-configure the
interrupt to avoid auto-enabling it.Fixes: fd913ef7ce61 ("Bluetooth: btusb: Add out-of-band wakeup support")
Fixes: 5364a0b4f4be ("arm64: dts: rockchip: move QCA6174A wakeup pin into its USB node")
Signed-off-by: Brian Norris
Reviewed-by: Matthias Kaehlcke
Signed-off-by: Linus Torvalds
03 Mar, 2019
2 commits
-
This adds the support of enabling MT7663U and MT7668U Bluetooth function
running on the top of btmtkuart driver.There are a few differences between MT766[3,8]U and MT7622 where
MT766[3,8]U are standalone devices based on UART transport while MT7622
bluetooth is a built-in device on MediaTek SoC communicating with the host
through BTIF serial transport. Thus, extra setup sequence is necessary
for these standalone devices such as remote regulator and reset control via
GPIO, baud rate changing handshake between the host and device and so on.Signed-off-by: Sean Wang
Signed-off-by: Marcel Holtmann -
The current 300ms delay after a baudrate change is extremely long.
For WCN3990 it is sufficient to wait 10ms after the baudrate change
request has been sent over the wire.Signed-off-by: Matthias Kaehlcke
Signed-off-by: Marcel Holtmann
27 Feb, 2019
5 commits
-
We may need to specify a GPIO wake pin for this device, so add a
compatible property for it.There are at least to USB PID/VID variations of this chip: one with a
Lite-On ID and one with an Atheros ID.Signed-off-by: Brian Norris
Reviewed-by: Matthias Kaehlcke
Signed-off-by: Marcel Holtmann -
Call msleep() in qca_set_baudrate() instead of reimplementing it.
Signed-off-by: Matthias Kaehlcke
Signed-off-by: Marcel Holtmann -
During initialization the power-on pulse is currently sent inmediately
after the prior power-off pulse. With this initialization often fails
at boot time:[ 15.205224] Bluetooth: hci0: setting up wcn3990
[ 17.341062] Bluetooth: hci0: command 0xfc00 tx timeout
[ 22.101453] ERROR: Bluetooth initialization failed
[ 25.337740] Bluetooth: hci0: Reading QCA version information failed (-110)After a power-off pulse wait 10ms to give the controller time to power
off. Remove the previous short settling delay, it isn't needed anymore.Signed-off-by: Matthias Kaehlcke
Reviewed-by: Balakrishna Godavarthi
Signed-off-by: Marcel Holtmann -
After sending a power on pulse the driver has a delay of 100ms
to allow the host controller to boot. Move the delay into
qca_send_power_pulse(), since it is directly related with the
power-on pulse.Signed-off-by: Matthias Kaehlcke
Reviewed-by: Balakrishna Godavarthi
Signed-off-by: Marcel Holtmann -
There are only two types of power pulses 'on' or 'off', pass a boolean
instead of the power pulse 'command'.Signed-off-by: Matthias Kaehlcke
Reviewed-by: Balakrishna Godavarthi
Signed-off-by: Marcel Holtmann
26 Feb, 2019
3 commits
-
Set quirk for wcn3990 to read BD_ADDR from a firmware node property.
Signed-off-by: Matthias Kaehlcke
Tested-by: Balakrishna Godavarthi
Signed-off-by: Marcel Holtmann -
Use the HCI_QUIRK_USE_BDADDR_PROPERTY quirk to let the HCI
core handle the reading of 'local-bd-address'. With this there
is no need to set HCI_QUIRK_INVALID_BDADDR, the case of a
non-existing or invalid fwnode property is handled by the core
code.Signed-off-by: Matthias Kaehlcke
Reviewed-by: Balakrishna Godavarthi
Signed-off-by: Marcel Holtmann -
task A: task B:
hci_uart_set_proto flush_to_ldisc
- p->open(hu) -> h5_open //alloc h5 - receive_buf
- set_bit HCI_UART_PROTO_READY - tty_port_default_receive_buf
- hci_uart_register_dev - tty_ldisc_receive_buf
- hci_uart_tty_receive
- test_bit HCI_UART_PROTO_READY
- h5_recv
- clear_bit HCI_UART_PROTO_READY while() {
- p->open(hu) -> h5_close //free h5
- h5_rx_3wire_hdr
- h5_reset() //use-after-free
}It could use ioctl to set hci uart proto, but there is
a use-after-free issue when hci_uart_register_dev() fail in
hci_uart_set_proto(), see stack above, fix this by setting
HCI_UART_PROTO_READY bit only when hci_uart_register_dev()
return success.Reported-by: syzbot+899a33dc0fa0dbaf06a6@syzkaller.appspotmail.com
Signed-off-by: Kefeng Wang
Reviewed-by: Jeremy Cline
Signed-off-by: Marcel Holtmann
18 Feb, 2019
8 commits
-
Update the setup sequence on MT7622 to apply the same flow with MT7663U
and MT7668U USB [1] as much as possible. These additional commands are
required to parse the corresponding event to determine what current state
the Bluetooth device is on and thus it's necessary to extend
mtk_hci_wmt_sync to support the reading status in the same patch.[1] http://lists.infradead.org/pipermail/linux-mediatek/2019-January/017074.html
Signed-off-by: Sean Wang
Signed-off-by: Marcel Holtmann -
Pass a structure pointer to mtk_hci_wmt_sync rather than several arguments
to avoid take up additional stack area and be better to read the code.Signed-off-by: Sean Wang
Signed-off-by: Marcel Holtmann -
Restore bdev->tx_state with clearing bit BTMTKUART_TX_WAIT_VND_EVT
when there is an error on waiting for the corresponding event.Fixes: 7237c4c9ec92 ("Bluetooth: mediatek: Add protocol support for MediaTek serial devices")
Signed-off-by: Sean Wang
Signed-off-by: Marcel Holtmann -
add a trivial typo fix from speicfic to specific
Fixes: 7237c4c9ec92 ("Bluetooth: mediatek: Add protocol support for MediaTek serial devices")
Signed-off-by: Sean Wang
Signed-off-by: Marcel Holtmann -
The hci_dev struct hdev is referenced in work queues and timers started
by open() in some protocols. This creates a race between the
initialization function and the work or timer which can result hdev
being dereferenced while it is still null.The syzbot report contains a reliable reproducer which causes a null
pointer dereference of hdev in hci_uart_write_work() by making the
memory allocation for hdev fail.To fix this, ensure hdev is valid from before calling a protocol's
open() until after calling a protocol's close().Reported-by: syzbot+257790c15bcdef6fe00c@syzkaller.appspotmail.com
Signed-off-by: Jeremy Cline
Signed-off-by: Marcel Holtmann -
During hci down we observed IBS sleep commands are queued in the Tx
buffer and hci_uart_write_work is sending data to the chip which is
not required as the chip is powered off. This patch will disable IBS
and flush the Tx buffer before we turn off the chip.Signed-off-by: Balakrishna Godavarthi
Reviewed-by: Matthias Kaehlcke
Signed-off-by: Marcel Holtmann -
This patch will help to stop frame reassembly errors while changing
the baudrate. This is because host send a change baudrate request
command to the chip with 115200 bps, Whereas chip will change their
UART clocks to the enable for new baudrate and sends the response
for the change request command with newer baudrate, On host side
we are still operating in 115200 bps which results of reading garbage
data. Here we are pulling RTS line, so that chip we will wait to send data
to host until host change its baudrate.Signed-off-by: Balakrishna Godavarthi
Tested-by: Matthias Kaehlcke
Reviewed-by: Matthias Kaehlcke
Signed-off-by: Marcel Holtmann -
wcn3990 requires a power pulse to turn ON/OFF along with
regulators. Sometimes we are observing the power pulses are sent
out with some time delay, due to queuing these commands. This is
causing synchronization issues with chip, which intern delay the
chip setup or may end up with communication issues.Signed-off-by: Balakrishna Godavarthi
Reviewed-by: Matthias Kaehlcke
Signed-off-by: Marcel Holtmann
