[PATCH v3 0/4] Bluetooth: btusb: Support Qualcomm multi-subsystem QCC2072

Zijun Hu posted 4 patches 2 weeks, 4 days ago
There is a newer version of this series
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(-)
[PATCH v3 0/4] Bluetooth: btusb: Support Qualcomm multi-subsystem QCC2072
Posted by Zijun Hu 2 weeks, 4 days ago
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@oss.qualcomm.com>
---
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@oss.qualcomm.com

---
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@oss.qualcomm.com>

Re: [PATCH v3 0/4] Bluetooth: btusb: Support Qualcomm multi-subsystem QCC2072
Posted by Luiz Augusto von Dentz 2 weeks, 3 days ago
Hi Zijun,

On Mon, Sep 7, 2026 at 4:45 AM Zijun Hu <zijun.hu@oss.qualcomm.com> 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@oss.qualcomm.com>
> ---
> 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@oss.qualcomm.com
>
> ---
> 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@oss.qualcomm.com>

Sashiko flagged a few more issues:

https://sashiko.dev/#/patchset/20260907-btusb_qcc2072-v3-0-1f65350b03b8%40oss.qualcomm.com

-- 
Luiz Augusto von Dentz