Re: [PATCH] Bluetooth: btusb: Add support for Qualcomm QCC2072

[Zijun Hu <zijun.hu@oss.qualcomm.com>]

On 7/14/2026 4:45 AM, Luiz Augusto von Dentz wrote:
>> To avoid adding large vendor-specific code into the BTUSB main
>> file, add btusb_qcom.c/.h to support multi-subsystem BT chips.
> Ok, so this is not the first time we are seeing the driver want to
> have it own processing of HCI traffic, but instead of doing post host
> processing it is doing pre host, which creates quite a few issues
> since 1. you can use safer skb helper like skb_pull_data and 2.
> requires to do HCI processing of traffic not meant to the driver,
> besides not being able to use something like struct hci_ev table that
> would help to avoid having the same bugs we fixed over the years.
> 
> So what we might have to do is some way to for drivers to register
> their own event table, provided they don't conflict with the host, or
> if it just HCI_EV_VENDOR then perhaps that can be done with just
> hci->vendor_ev callback.

  Hi Luiz,

  Thank you for the advice. Let me clarify the design:

A.  Why pre-host processing?

  QCC2072's endpoints carry non-BT frames (PERI event and PERI ACL) alongside BT frames. btusb_qcom.c must first reassemble the raw byte stream into
  complete frames — of either kind. Once assembled, non-BT frames are intercepted and handled locally; BT frames are passed up to the stack untouched.

B.  What to do with non-BT frames

  There are two options:
  1. Don't let them reach the host stack at all, or
  2. Route them through the stack by an opaque channel such as HCI_VENDOR_PKT — defined by the stack but with no implementation yet.

C.  Why not skb_pull_data() for non-BT frames

  We want to preserve and log the complete frame for diagnostics, so we deliberately avoid skb_pull_data().

  
We'll also look into leveraging hci_ev table for non-BT frame handling in v2.