Re: [PATCH v3 0/4] Bluetooth: btusb: Support Qualcomm multi-subsystem QCC2072
From: Luiz Augusto von Dentz
Date: Tue Sep 08 2026 - 12:52:30 EST
Hi Zijun,
On Mon, Sep 7, 2026 at 4:45 AM Zijun Hu <zijun.hu@xxxxxxxxxxxxxxxx> wrote:
>
> Hi Luiz,
>
> This revision addresses issues reported by Sashiko. Fixes are listed in
> the changelog below; false positives are addressed as Q&A further down.
>
> Could you take a look at this new revision when you get a chance, and let
> me know if you have any further comments?
>
> False positives (no code change):
>
> Q: Does this explicit padding with null bytes break userspace crash dump
> analysis for btqcom_submit_memdump()?
>
> A: No — this header is internal and appended as dump data. Its fixed
> 512-byte size is enough to delimit it from the dump data, so it doesn't
> need the text end marking like the external file header.
>
> Q: Does mixing goto statements with guard() declarations in
> qperi_try_wakeup() violate the scope-based cleanup guidelines?
>
> A: No — all the gotos happen after guard(spinlock)() is taken, at
> function scope. Since every goto stays inside that same scope, it
> doesn't violate cleanup.h's guidance.
>
> Q: Could this cause a kernel panic if a zero-length packet is received
> for btqcom_recv_vendor_pkt()?
>
> A: No — not reachable from a socket write, recv_vendor_pkt() only runs
> on the RX side. And skb->len can't be 0 anyway: btusb_upward_frame()
> pushes 1 byte onto the skb right before tagging it HCI_VENDOR_PKT.
>
> Q: Can this lead to a null pointer dereference on the transmit path
> for btusb_qcom_send_frame()?
>
> A: No — skb->len can't be 0 here. Both producers of a HCI_VENDOR_PKT
> skb already reject zero length before reaching hdev->send():
> hci_sock_sendmsg's "len < 4" check for userspace writes, and
> hci_send_vendor_frame's own "!len" check for kernel-internal senders.
>
> This patch series supports Qualcomm multi-subsystem QCC2072. The first
> 3 commits are simple dependencies of the last one.
>
> Signed-off-by: Zijun Hu <zijun.hu@xxxxxxxxxxxxxxxx>
> ---
> Changes in v3:
> - Remove socket option BT_RECV_VENDOR_PKT
> - Fix heap overflow in hci_send_vendor_frame()
> - Fix a stray NUL byte in the memdump file header
> - Fix PM reference leak in btusb_do_reset_work()
> - Don't mix goto with scoped_guard() in __qperi_tx_sync_evt()
> - Don't mix goto with scoped_guard() in qperi_handle_evt()
> - Prepare btusb_qcom for bulk serialization mode support.
> - Link to v2: https://patch.msgid.link/20260830-btusb_qcc2072-v2-0-5c0e0c9dd98b@xxxxxxxxxxxxxxxx
>
> ---
> Zijun Hu (4):
> Bluetooth: btusb: Add recv_intr() hook to btusb_data
> Bluetooth: Add generic support for vendor packets
> Bluetooth: btusb: Build the driver from multiple source files
> Bluetooth: btusb: Add support for Qualcomm multi-subsystem QCC2072
>
> drivers/bluetooth/Kconfig | 14 +
> drivers/bluetooth/Makefile | 3 +
> drivers/bluetooth/{btusb.c => btusb_main.c} | 126 +-
> drivers/bluetooth/btusb_qcom.c | 4514 +++++++++++++++++++++++++++
> drivers/bluetooth/btusb_qcom.h | 99 +
> include/net/bluetooth/hci_core.h | 5 +
> include/net/bluetooth/hci_mon.h | 2 +
> net/bluetooth/hci_core.c | 45 +
> net/bluetooth/hci_sock.c | 8 +
> 9 files changed, 4814 insertions(+), 2 deletions(-)
> ---
> base-commit: 755cf7adf8dd2d12627cb7de223d35b12228e2f5
> change-id: 20260824-btusb_qcc2072-abb918ab4220
>
> Best regards,
> --
> Zijun Hu <zijun.hu@xxxxxxxxxxxxxxxx>
Sashiko flagged a few more issues:
https://sashiko.dev/#/patchset/20260907-btusb_qcc2072-v3-0-1f65350b03b8%40oss.qualcomm.com
--
Luiz Augusto von Dentz