Re: [PATCH RFC] Bluetooth: Add generic support for vendor HCI frames
From: Zijun Hu
Date: Tue Jul 21 2026 - 07:38:01 EST
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.