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

[Luiz Augusto von Dentz]

Hi Zijun,

On Tue, Jul 14, 2026 at 9:48 AM Zijun Hu <zijun.hu@xxxxxxxxxxxxxxxx> wrote:
>
> 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.

Well they are still HCI commands/events aren't they? If they properly
use the vendor command/event range I don't see a problem here. Also,
if you pre-process, it will skip sending to the monitor, making
debugging much harder.

> 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.

We have vendor diagostic packets already in the form of HCI_DIAG_PKT.

> 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().

Yeah, that is price tag of pre-processing, but even for vendor packets
if they don't reach hci_send_to_monitor you won't be able to see on
the likes of btmon.

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


-- 
Luiz Augusto von Dentz