Re: [PATCH v2 2/4] Bluetooth: Add generic support for vendor HCI packets

[Zijun Hu]

On 8/31/2026 10:45 PM, Luiz Augusto von Dentz wrote:
>>     Packet type                 BT-HCI indicator   PERI-HCI indicator
>>     -----------------------------------------------------------------
>>     CMD (Host -> Controller)    0x01               0x31
>>     ACL Data (bidirectional)    0x02               0x32
>>     EVENT (Controller -> Host)  0x04               0x34
>>
>> Implement HCI_VENDOR_PKT to generically support vendor HCI packets:
>>
>> - Log them in btmon as they appear on the wire.
>> - Allow userspace to send/receive them over HCI_CHANNEL_USER, gate RX
>>   with the new socket option BT_RECV_VENDOR_PKT, off by default to
>>   avoid regressions for existing applications.
>> - Add hdev->recv_vendor_pkt() to handle them in hci_rx_work().
>> - Add hci_send_vendor_frame() to send an HCI_VENDOR_PKT frame.
> I don't find this one very useful, as btmon already supports handling
> vendor events:
> 
> { 0xff, "Vendor", vendor_evt, 0, false },
> 

This commit actually implements your guidance concluded at 2026-07-20
after discussion:

https://lore.kernel.org/all/CABBYNZL_H2iRAshF-RCX41jbt0jots5i5W=aUUJC_wEN6wzp=w@xxxxxxxxxxxxxx

"I'm fine adding code to the likes of btmon to decode vendor packets, we already have
something similar for Intel although that uses a vendor event not a
vendor packet (both use 0xff, causing the confusion). The user of the
user channel shall be able to read/write starting with 0xff then
decode/encode the next byte as the actual vendor opcode."

Sorry that this patchset comes too late due to refining the last
commit, so it may no longer be top of mind.

vendor_evt() handles HCI_EV_VENDOR, which is very different and
easily distinguished from HCI_VENDOR_PKT, as table below:

+----------------+------------------------+------------------------+
|                | HCI_VENDOR_PKT (0xff)  | HCI_EV_VENDOR (0xff)   |
+----------------+------------------------+------------------------+
| Defined by     | Vendor                 | BT SIG                 |
+----------------+------------------------+------------------------+
| Hierarchy      | Parallel to            | Nested inside          |
|                | HCI_EVENT_PKT(0x04)    | HCI_EVENT_PKT(0x04)    |
+----------------+------------------------+------------------------+
| Direction      | RX and TX              | RX only                |
+----------------+------------------------+------------------------+
| kernel <->     | HCI_VENDOR_PKT, ...    | 0x04, HCI_EV_VENDOR,   |
| userspace      |                        | ...                    |
+----------------+------------------------+------------------------+
| kernel <->     | TX: 22, its payload    | RX: 3, HCI_EV_VENDOR,  |
| monitor        | RX: 23, its payload    | ...                    |
+----------------+------------------------+------------------------+

> This will complicate things because some drivers might label packets
> as vendor while others might inline them as an HCI vendor event. From
> the spec's point of view there is no generic HCI vendor packet, so the
> PERI approach really stands out as a non-compliant solution because it
> uses reserved opcodes.

Vendors sometimes define various HCI_VENDOR_PKTs for their H/W
controller based on their own considerations or requirements, such as
Qualcomm's PERI frames, and BT ACL with vendor-reserved handles, as in
the table below:
+--------+----------+------------------------------------------+
| Vendor | Coredump | Other                                    |
+--------+----------+------------------------------------------+
| QCOM   | 0xEDD    | Enhanced Logging (0xEDC)                 |
+--------+----------+------------------------------------------+
| MTK    | 0xFC6F   | Firmware debug logging (0x05FF, 0x05FE)  |
+--------+----------+------------------------------------------+
| NXP    | 0xFFF    | -                                        |
+--------+----------+------------------------------------------+
These chips have been BT SIG certified and are commercially deployed.

This commit supports them, and also fixes issues similar to what the
commit below fixes for HCI_EV_VENDOR:

0bd606b31d40 ("Bluetooth: hci_event: Introduce handle_ev_vendor()
for HCI_EV_VENDOR")

It is also required infrastructure for supporting Qualcomm's
multi-subsystem chips.

May we address your concern by improving the naming and adding
comments to make each packet type's concept clearer?

May we address your concern by improving the naming and adding
comments to make each packet type's concept clearer in the BlueZ
patchset below:
https://lore.kernel.org/all/20260830-vendor_hci-v2-0-9903760957ab@xxxxxxxxxxxxxxxx

Please take a look when you get a chance, and let me know if you
have any further comments.