Files
linux/include/net
Zijun Hu 0bd606b31d Bluetooth: hci_event: Introduce handle_ev_vendor() for HCI_EV_VENDOR
Introduce the hook to solve issues below:

msft_vendor_evt(), the current handler for all VSEs, is unsuitable
since:
- many VSEs are not MSFT ones;
- it always corrupts the non-MSFT VSEs by calling skb_pull_data()
  once the MSFT extension is enabled.

Several issues are caused by many transport drivers pre-processing
VSEs in their RX path, often an IRQ-disabled atomic context. Take
the two typical cases below as examples:

Case 1:
  // no btmon log, no way to reach userspace
  Step 1: handle and free @original_skb directly

Case 2:
  // hurts performance and consumes GFP_ATOMIC memory
  Step 1: cloned_skb = skb_clone(original_skb, GFP_ATOMIC);
  // the VSE is handled here
  Step 2: handle and free @cloned_skb
  Step 3: hci_recv_frame(hdev, original_skb);
  // already handled, but re-enters the stack's event-handling path
  Step 4: hci_event_packet(hdev, original_skb);

Fix by introducing the hook with usage:
1) the transport driver registers the hook for VSEs of interest;
2) the stack calls it in process context, handling the VSE like any
   other event:
   - if interested, handle the VSE - no need to free it - and
     return true;
   - otherwise return false.

Signed-off-by: Zijun Hu <zijun.hu@oss.qualcomm.com>
Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
2026-08-07 15:40:27 -04:00
..
2025-04-24 17:03:45 -07:00
2025-07-08 18:05:25 -07:00
2024-05-08 10:35:09 +01:00
2024-08-26 09:37:23 -07:00
2024-11-13 18:49:50 -08:00
2024-08-26 09:37:23 -07:00
2025-08-26 17:34:31 -07:00
2026-01-21 19:28:32 -08:00
2024-05-07 01:35:55 +02:00
2024-08-26 09:37:23 -07:00
2024-12-06 17:43:08 -08:00
2025-09-18 12:32:06 +02:00
2024-08-26 09:37:23 -07:00
2024-08-26 09:37:23 -07:00
2025-04-11 18:58:10 -07:00
2025-07-04 09:32:35 +02:00
2024-05-30 18:29:38 -07:00
2025-09-08 18:06:21 -07:00
2025-07-11 11:00:57 -07:00
2023-07-28 14:07:59 -07:00
2026-03-13 18:57:44 -07:00