| Message ID | 20230404022711.86515-1-eddy.zhang@rock-chips.com |
|---|---|
| State | Accepted |
| Commit | 13a6ebae665dd8d372dfa3c74e43a54b9e9f1d60 |
| Headers | show |
| Series | [v2] Bluetooth: hci_h5: Complements reliable packet processing logic | expand |
This is automated email and please do not reply to this email! Dear submitter, Thank you for submitting the patches to the linux bluetooth mailing list. This is a CI test results with your patch series: PW Link:https://patchwork.kernel.org/project/bluetooth/list/?series=736626 ---Test result--- Test Summary: CheckPatch PASS 0.68 seconds GitLint PASS 0.34 seconds SubjectPrefix PASS 0.12 seconds BuildKernel PASS 31.71 seconds CheckAllWarning PASS 35.53 seconds CheckSparse PASS 40.03 seconds CheckSmatch PASS 108.41 seconds BuildKernel32 PASS 30.93 seconds TestRunnerSetup PASS 442.02 seconds TestRunner_l2cap-tester PASS 16.15 seconds TestRunner_iso-tester PASS 16.08 seconds TestRunner_bnep-tester PASS 5.29 seconds TestRunner_mgmt-tester PASS 108.93 seconds TestRunner_rfcomm-tester PASS 8.43 seconds TestRunner_sco-tester PASS 7.88 seconds TestRunner_ioctl-tester PASS 9.12 seconds TestRunner_mesh-tester PASS 6.71 seconds TestRunner_smp-tester PASS 7.78 seconds TestRunner_userchan-tester PASS 5.58 seconds IncrementalBuild PASS 29.74 seconds --- Regards, Linux Bluetooth
Hello: This patch was applied to bluetooth/bluetooth-next.git (master) by Luiz Augusto von Dentz <luiz.von.dentz@intel.com>: On Tue, 4 Apr 2023 10:27:11 +0800 you wrote: > 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) > > [...] Here is the summary with links: - [v2] Bluetooth: hci_h5: Complements reliable packet processing logic https://git.kernel.org/bluetooth/bluetooth-next/c/13a6ebae665d You are awesome, thank you!
diff --git a/drivers/bluetooth/hci_h5.c b/drivers/bluetooth/hci_h5.c index 6455bc4fb5bb..d05eaeaa4516 100644 --- a/drivers/bluetooth/hci_h5.c +++ b/drivers/bluetooth/hci_h5.c @@ -463,6 +463,8 @@ static int h5_rx_3wire_hdr(struct hci_uart *hu, unsigned char c) if (H5_HDR_RELIABLE(hdr) && H5_HDR_SEQ(hdr) != h5->tx_ack) { bt_dev_err(hu->hdev, "Out-of-order packet arrived (%u != %u)", H5_HDR_SEQ(hdr), h5->tx_ack); + set_bit(H5_TX_ACK_REQ, &h5->flags); + hci_uart_tx_wakeup(hu); h5_reset_rx(h5); return 0; }
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> --- Changes in v2: - Fixed build bot warning. --- --- drivers/bluetooth/hci_h5.c | 2 ++ 1 file changed, 2 insertions(+)