linux-toradex.git/drivers/bluetooth/hci_h5.c, branch v6.5-rc4 Linux kernel for Apalis and Colibri modules Bluetooth: hci_h5: Complements reliable packet processing logic 2023-04-24T05:00:04+00:00 Qiqi Zhang eddy.zhang@rock-chips.com 2023-04-04T02:27:11+00:00 3c0d41f141c97e516d986f0571b0d7a745a4e2a8 As shown in the schematic diagram below.There may be a critical scenario in the current code. If the device does not receive an pure ack sent by the host due to insufficient receive buffer or other reasons and triggers a retransmission, the host will always be in an 'out-of-order' state.The state machine will get stuck. host device SEQ3,ACK4 ---------> <--------- SEQ4,ACK4 pure ACK ---------> (not received) (out-of-order) <--------- SEQ4,ACK4(retransmission) ........ (out-of-order) <--------- SEQ4,ACK4(retransmission) According to the description in the core specification: "whenever a reliable packet is received, an acknowledgment shall be generated." So set H5_TX_ACK_REQ bit to trigger retransmission of pure ack packet when "out-of-order" occurs. Signed-off-by: Qiqi Zhang <eddy.zhang@rock-chips.com> Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com> 
As shown in the schematic diagram below.There may be a critical
scenario in the current code. If the device does not receive an
pure ack sent by the host due to insufficient receive buffer or
other reasons and triggers a retransmission, the host will always
be in an 'out-of-order' state.The state machine will get stuck.

       host                 device
     SEQ3,ACK4 --------->
               <--------- SEQ4,ACK4
     pure ACK  ---------> (not received)
(out-of-order) <--------- SEQ4,ACK4(retransmission)
                ........
(out-of-order) <--------- SEQ4,ACK4(retransmission)

According to the description in the core specification: "whenever
a reliable packet is received, an acknowledgment shall be generated."
So set H5_TX_ACK_REQ bit to trigger retransmission of pure ack packet
when "out-of-order" occurs.

Signed-off-by: Qiqi Zhang <eddy.zhang@rock-chips.com>
Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
Bluetooth: btrtl: add support for the RTL8723CS 2023-04-24T04:50:24+00:00 Vasily Khoruzhick anarsoul@gmail.com 2023-03-07T22:17:31+00:00 c0123cb6c4c7fc2a42ead6cd7d3e82b8e1c25c6f The Realtek RTL8723CS is a SDIO WiFi chip. It also contains a Bluetooth module which is connected via UART to the host. It shares lmp subversion with 8703B, so Realtek's userspace initialization tool (rtk_hciattach) differentiates varieties of RTL8723CS (CG, VF, XX) with RTL8703B using vendor's command to read chip type. Also this chip declares support for some features it doesn't support so add a quirk to indicate that these features are broken. Signed-off-by: Vasily Khoruzhick <anarsoul@gmail.com> Signed-off-by: Bastian Germann <bage@debian.org> Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com> 
The Realtek RTL8723CS is a SDIO WiFi chip. It also contains a Bluetooth
module which is connected via UART to the host.

It shares lmp subversion with 8703B, so Realtek's userspace
initialization tool (rtk_hciattach) differentiates varieties of RTL8723CS
(CG, VF, XX) with RTL8703B using vendor's command to read chip type.

Also this chip declares support for some features it doesn't support
so add a quirk to indicate that these features are broken.

Signed-off-by: Vasily Khoruzhick <anarsoul@gmail.com>
Signed-off-by: Bastian Germann <bage@debian.org>
Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
Bluetooth: hci_h5: don't call kfree_skb() under spin_lock_irqsave() 2022-12-12T22:19:25+00:00 Yang Yingliang yangyingliang@huawei.com 2022-12-07T02:18:32+00:00 383630cc6758d619874c2e8bb2f68a61f3f9ef6e 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: 43eb12d78960 ("Bluetooth: Fix/implement Three-wire reliable packet sending") Signed-off-by: Yang Yingliang <yangyingliang@huawei.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 interrupts being disabled. So replace kfree_skb()
with dev_kfree_skb_irq() under spin_lock_irqsave().

Fixes: 43eb12d78960 ("Bluetooth: Fix/implement Three-wire reliable packet sending")
Signed-off-by: Yang Yingliang <yangyingliang@huawei.com>
Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
Bluetooth: hci_uart: add missing NULL check in h5_enqueue 2022-03-18T16:12:07+00:00 Pavel Skripkin paskripkin@gmail.com 2022-03-13T17:49:36+00:00 32cb08e958696908a9aad5e49a78d74f7e32fffb Syzbot hit general protection fault in __pm_runtime_resume(). The problem was in missing NULL check. hu->serdev can be NULL and we should not blindly pass &serdev->dev somewhere, since it will cause GPF. Reported-by: syzbot+b9bd12fbed3485a3e51f@syzkaller.appspotmail.com Fixes: d9dd833cf6d2 ("Bluetooth: hci_h5: Add runtime suspend") Signed-off-by: Pavel Skripkin <paskripkin@gmail.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org> 
Syzbot hit general protection fault in __pm_runtime_resume(). The problem
was in missing NULL check.

hu->serdev can be NULL and we should not blindly pass &serdev->dev
somewhere, since it will cause GPF.

Reported-by: syzbot+b9bd12fbed3485a3e51f@syzkaller.appspotmail.com
Fixes: d9dd833cf6d2 ("Bluetooth: hci_h5: Add runtime suspend")
Signed-off-by: Pavel Skripkin <paskripkin@gmail.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Bluetooth: hci_h5: Add power reset via gpio in h5_btrtl_open 2022-01-26T13:39:35+00:00 Vyacheslav Bocharov adeep@lexina.in 2022-01-26T07:39:05+00:00 adce573b927adf827f2f8627f05c2ba90031ebc9 Add power reset for bluetooth via enable-gpios in h5_btrtl_open function. While testing the RTL8822CS SDIO WiFi/BT adapter, it was found that in some cases the kernel could not initialize BT firmware. However, manually resetting the adapter via gpio (off/on sequence) allows it to start correctly. Apparently, when the system starts, the adapter is in an undefined state (including unknown gpio state after starting uboot). A forced reset helps to initialize the adapter in most cases. It has been found experimentally that 100 ms is sufficient for a reset. Signed-off-by: Vyacheslav Bocharov <adeep@lexina.in> Signed-off-by: Marcel Holtmann <marcel@holtmann.org> 
Add power reset for bluetooth via enable-gpios in h5_btrtl_open function.

While testing the RTL8822CS SDIO WiFi/BT adapter, it was found that in
some cases the kernel could not initialize BT firmware. However,
manually resetting the adapter via gpio (off/on sequence) allows it to
start correctly.
Apparently, when the system starts, the adapter is in an undefined state
(including unknown gpio state after starting uboot). A forced reset helps
to initialize the adapter in most cases. It has been found experimentally
that 100 ms is sufficient for a reset.

Signed-off-by: Vyacheslav Bocharov <adeep@lexina.in>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Bluetooth: hci_h5: directly return hci_uart_register_device() ret-val 2021-09-24T09:48:02+00:00 Hans de Goede hdegoede@redhat.com 2021-09-24T09:41:06+00:00 6fc165337b0d06670b3b266fc217dd72b080c870 Since the hci_uart_register_device() call is the last thing we do in h5_serdev_probe() we can simply directly return its return-value. Cc: Archie Pusaka <apusaka@google.com> Suggested-by: Archie Pusaka <apusaka@google.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org> 
Since the hci_uart_register_device() call is the last thing we do in
h5_serdev_probe() we can simply directly return its return-value.

Cc: Archie Pusaka <apusaka@google.com>
Suggested-by: Archie Pusaka <apusaka@google.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Bluetooth: hci_h5: Fix (runtime)suspend issues on RTL8723BS HCIs 2021-09-24T09:35:53+00:00 Hans de Goede hdegoede@redhat.com 2021-09-20T12:57:39+00:00 9a9023f314873241a43b5a2b96e9c0caaa958433 The recently added H5_WAKEUP_DISABLE h5->flags flag gets checked in h5_btrtl_open(), but it gets set in h5_serdev_probe() *after* calling hci_uart_register_device() and thus after h5_btrtl_open() is called, set this flag earlier. Also on devices where suspend/resume involves fully re-probing the HCI, runtime-pm suspend should not be used, make the runtime-pm setup conditional on the H5_WAKEUP_DISABLE flag too. This fixes the HCI being removed and then re-added every 10 seconds because it was being reprobed as soon as it was runtime-suspended. Fixes: 66f077dde749 ("Bluetooth: hci_h5: add WAKEUP_DISABLE flag") Fixes: d9dd833cf6d2 ("Bluetooth: hci_h5: Add runtime suspend") Signed-off-by: Hans de Goede <hdegoede@redhat.com> Reviewed-by: Archie Pusaka <apusaka@chromium.org> Signed-off-by: Marcel Holtmann <marcel@holtmann.org> 
The recently added H5_WAKEUP_DISABLE h5->flags flag gets checked in
h5_btrtl_open(), but it gets set in h5_serdev_probe() *after*
calling  hci_uart_register_device() and thus after h5_btrtl_open()
is called, set this flag earlier.

Also on devices where suspend/resume involves fully re-probing the HCI,
runtime-pm suspend should not be used, make the runtime-pm setup
conditional on the H5_WAKEUP_DISABLE flag too.

This fixes the HCI being removed and then re-added every 10 seconds
because it was being reprobed as soon as it was runtime-suspended.

Fixes: 66f077dde749 ("Bluetooth: hci_h5: add WAKEUP_DISABLE flag")
Fixes: d9dd833cf6d2 ("Bluetooth: hci_h5: Add runtime suspend")
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Archie Pusaka <apusaka@chromium.org>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Bluetooth: hci_uart: fix GPF in h5_recv 2021-09-10T07:38:43+00:00 Pavel Skripkin paskripkin@gmail.com 2021-09-02T20:27:56+00:00 2fc7acb69fa3573d4bf7a90c323296d840daf330 Syzbot hit general protection fault in h5_recv(). The problem was in missing NULL check. hu->serdev can be NULL and we cannot blindly pass &serdev->dev somewhere, since it can cause GPF. Fixes: d9dd833cf6d2 ("Bluetooth: hci_h5: Add runtime suspend") Reported-and-tested-by: syzbot+7d41312fe3f123a6f605@syzkaller.appspotmail.com Signed-off-by: Pavel Skripkin <paskripkin@gmail.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org> 
Syzbot hit general protection fault in h5_recv(). The problem was in
missing NULL check.

hu->serdev can be NULL and we cannot blindly pass &serdev->dev
somewhere, since it can cause GPF.

Fixes: d9dd833cf6d2 ("Bluetooth: hci_h5: Add runtime suspend")
Reported-and-tested-by: syzbot+7d41312fe3f123a6f605@syzkaller.appspotmail.com
Signed-off-by: Pavel Skripkin <paskripkin@gmail.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Bluetooth: hci_h5: Add runtime suspend 2021-07-23T12:10:23+00:00 Archie Pusaka apusaka@chromium.org 2021-07-23T11:31:57+00:00 d9dd833cf6d29695682ec7e7924c0d0992b906bc This patch allows the controller to suspend after a short period of inactivity. Signed-off-by: Archie Pusaka <apusaka@chromium.org> Reviewed-by: Abhishek Pandit-Subedi <abhishekpandit@chromium.org> Reviewed-by: Hilda Wu <hildawu@realtek.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org> 
This patch allows the controller to suspend after a short period of
inactivity.

Signed-off-by: Archie Pusaka <apusaka@chromium.org>
Reviewed-by: Abhishek Pandit-Subedi <abhishekpandit@chromium.org>
Reviewed-by: Hilda Wu <hildawu@realtek.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Bluetooth: hci_h5: btrtl: Maintain flow control if wakeup is enabled 2021-07-23T12:10:23+00:00 Archie Pusaka apusaka@chromium.org 2021-07-23T11:31:56+00:00 30f11dda2d25edcaae5ad34c4b953df4b2ba4faf For chips that doesn't reset on suspend, we need to provide the correct value of flow_control when it resumes. Therefore, store the flow control value when reading from the config file to be reused upon suspend. Signed-off-by: Archie Pusaka <apusaka@chromium.org> Reviewed-by: Abhishek Pandit-Subedi <abhishekpandit@chromium.org> Reviewed-by: Hilda Wu <hildawu@realtek.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org> 
For chips that doesn't reset on suspend, we need to provide the correct
value of flow_control when it resumes. Therefore, store the flow
control value when reading from the config file to be reused upon
suspend.

Signed-off-by: Archie Pusaka <apusaka@chromium.org>
Reviewed-by: Abhishek Pandit-Subedi <abhishekpandit@chromium.org>
Reviewed-by: Hilda Wu <hildawu@realtek.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>