Re: [PATCH BlueZ v3 3/4] doc/hci-protocol: Add BT_RECV_VENDOR_PKT socket option for HCI_CHANNEL_USER

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

On 9/4/2026 10:31 PM, Luiz Augusto von Dentz wrote:
>> Hi Luiz,
>>
>> Good catch — that socket option is introduced by the below kernel patch, which is still under review:
>> https://lore.kernel.org/all/20260830-btusb_qcc2072-v2-2-5c0e0c9dd98b@oss.qualcomm.com
>> I'll drop this userspace patch in v4 temporarily to avoid confusion.
>>
>>> e.g., HCI_CHANNEL_VENDOR which can then allow packet type rather than
>>> just the known ones.
>> For this new proposal:
>>
>> 1) Is my below understanding correct?
>> - H/W wire: BT and vendor packets are serialized together.
>> - Kernel: splits BT and vendor packets to their own channels.
>> - Userspace: merges both channels on RX, sends to the corresponding channel on TX.
> I guess that is up to us to define, HCI_CHANNEL_VENDOR could just
> serialize everything, so it supersed HCI_CHANNEL_USER which only took
> care of known packet types. That said I don't think it would be an API
> break if we decide HCI_CHANNEL_USER carry everything, but since you
> are trying to introduce BT_RECV_VENDOR_PKT there maybe a reason not to
> enable everything to be send over HCI_CHANNEL_USER.
> 
>> 2) How would a HCI_CHANNEL_USER user, e.g. Chromebook, send and receive vendor packets?
> Would have to switch to use HCI_CHANNEL_VENDOR, just as it would have
> to use BT_RECV_VENDOR_PKT, but then again Id rather do it on
> HCI_CHANNEL_USER if we don't consider it an API breakage.

Good point — I'll drop BT_RECV_VENDOR_PKT from both the kernel and userspace patches and let vendor packets flow over HCI_CHANNEL_USER
unconditionally.

Since HCI_CHANNEL_USER owns the controller exclusively, it should see every packet the controller sends.
There's also precedent for this: HCI_DRV_PKT was introduced over HCI_CHANNEL_USER with no equivalent opt-in gate.

The regression BT_RECV_VENDOR_PKT guarded against is mostly hypothetical anyway — it was added defensively in case some proprietary HCI_CHANNEL_USER
application doesn't handle unknown packet types robustly, not because of any regression we've actually observed. If such an application does break on
vendor packets, it should be fixed to tolerate them, rather than have the packet type gated on its behalf.