Re: [PATCH RFC] Bluetooth: Add generic support for vendor HCI frames

On 7/21/2026 4:52 PM, Zijun Hu wrote:
>>> Hi Luiz
>>> To address the below concerns you raised on previous
>>> discussion, and inspired from your suggestion to add hdev callback:
>>>
>>> - Not use safer skb helper like skb_pull_data()
>>> - It will skip sending to the monitor, making debugging much harder
>>>
>>> Looking forward to your further comments.
>>>
>>> Why hdev->is_vendor() instead of multiplexing vendor frames under a
>>> virtual HCI_VENDOR_PKT + vendor indicator byte ?
>>>
>>> 1) The virtual HCI_VENDOR_PKT isn't used by the core itself
>>>    currently, and may be removed later.
>>> 2) It makes full use of the indicator (hci_skb_pkt_type(skb)) space,
>>>    which is large enough to accommodate vendor frames without an
>>>    extra layer of nesting inside HCI_VENDOR_PKT.
>>> 3) It lets userspace and btmon logs see the exact same frame as it
>>>    appears on the wire.
> As noted above, I chose is_vendor() over Solution A. My reasoning follows,
> for your reference.
> 
> 1) Userspace sees exactly what is on the wire, in the same form as BT-HCI frames — 
>    clear and consistent, as shown below:
>   ┌───────┬──────────┬────────────┬────────────┐
>   │ Frame │ BT-HCI   │ PERI-HCI   │ PERI-HCI   │
>   │       │ existing │ is_vendor()│ Solution A │
>   ├───────┼──────────┼────────────┼────────────┤
>   │ CMD   │ 0x01 …   │ 0x31 …     │ 0xff 0x31… │
>   ├───────┼──────────┼────────────┼────────────┤
>   │ ACL   │ 0x02 …   │ 0x32 …     │ 0xff 0x32… │
>   ├───────┼──────────┼────────────┼────────────┤
>   │ EVENT │ 0x04 …   │ 0x34 …     │ 0xff 0x34… │
>   └───────┴──────────┴────────────┴────────────┘
> 2) is_vendor() puts PERI-HCI on an equal footing with BT-HCI, so userspace and the transport
>    driver can reuse the existing BT-HCI path rather than add a separate encode/decode layer —
>    less effort on both sides.
> 

add one more entry:
  3) It can let transport drivers avoid pre-processing unsolicited BT
     vendor-specific events (VSE) before hci_recv_frame(), which many
     transport drivers currently do (e.g. the QCA memdump event), and
     handle them in recv_vendor() within the stack instead, if put in
     hci_rx_work() as below:

        if (hci_is_vendor_frame(hdev, skb)) {
                BT_DBG("%s Vendor packet with type 0x%2.2x",
                       hdev->name, hci_skb_pkt_type(skb));
                if (hdev->recv_vendor)
                        hdev->recv_vendor(hdev, skb);
                else
                        kfree_skb(skb);
                continue;
        }

        /* Process frame */
        switch (hci_skb_pkt_type(skb)) {
        case HCI_EVENT_PKT:

> Could you please give me a clear direction 
> Solution A or is_vendor()?
> 
> I need it before I can move forward with the remaining QCC2072 btusb development work.
> 
> thank you.