From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mx0b-0031df01.pphosted.com (mx0b-0031df01.pphosted.com [205.220.180.131]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 3343F45DF7B for ; Thu, 23 Jul 2026 11:18:28 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=205.220.180.131 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1784805512; cv=none; b=Y9Np9vH/g9kuIFSutaTTN/SMqiMHzE4JqyhXjgcDIjHH/ZiikYlzDq0JYae88LxLLJGWFCShUyIAnfAPytYeXkGpZoE2YghwI9ZRu7I1IjqLJIgjwUQhLp5zHZ/FYwiWMBeS+CiOoD9ZOjS2INAGM37yz7TZRsGAPy3qDQ91Pdw= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1784805512; c=relaxed/simple; bh=1kK754C6DIq905tXo1G0GWpWAdhBNFss+tgn5B7F5lM=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=MNjSY9DCkz0I1mdwhzScELNH2so7fV0qoQgxxr85mXbuL+qzS/gSWmh1dkADKhPnrV/6ydSqwYtIj7AY1CVhLAkQheVF7G12lqub24KmGNVlNqxac/GY3/QCQygw5GsZQUHfjHSfS/bk1jClkADTkCDlYvQDDgKXtzay9lD0pu4= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=oss.qualcomm.com; spf=pass smtp.mailfrom=oss.qualcomm.com; dkim=pass (2048-bit key) header.d=qualcomm.com header.i=@qualcomm.com header.b=dlNV2efX; dkim=pass (2048-bit key) header.d=oss.qualcomm.com header.i=@oss.qualcomm.com header.b=GZWwMl7W; arc=none smtp.client-ip=205.220.180.131 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=oss.qualcomm.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=oss.qualcomm.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=qualcomm.com header.i=@qualcomm.com header.b="dlNV2efX"; dkim=pass (2048-bit key) header.d=oss.qualcomm.com header.i=@oss.qualcomm.com header.b="GZWwMl7W" Received: from pps.filterd (m0279873.ppops.net [127.0.0.1]) by mx0a-0031df01.pphosted.com (8.18.1.11/8.18.1.11) with ESMTP id 66N8qbGI3489432 for ; Thu, 23 Jul 2026 11:18:27 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=qualcomm.com; h= cc:content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to; s=qcppdkim1; bh= ItUM4hhcjDTFOB8mblvsJ6pDULGNPhKo1DxExHccibw=; b=dlNV2efXkAN0kc8Z 8RWBqyBkgMKWFQAtplsIy0BjosNjy/HgjqZ9mcontzg+NAyYA7dcEjgkDYsGd/yc jf8d3miEug70gR0/W3MeTvrCorxq7ZjGA10S19ZAiFHSLXtmX5XW4IAAVNAHL84b B2wC/kyp2j8SnYfbRqTGguV/A7xOSFcYbbPHR8beVhTsfKR/mIWZzrZdXZib7eRV qtNEvx4FMlMKW4tgPWHY3nl4BlQbhEeCN6jKP0v27QT5EybhRLPAzidodD48D0ji 32DLd8Tz1rWi+tppSU8mjZDOt7+eD+vshWU1He89uNX+yVNJeOyH83YlHhochOqj zMMaNA== Received: from mail-pl1-f198.google.com (mail-pl1-f198.google.com [209.85.214.198]) by mx0a-0031df01.pphosted.com (PPS) with ESMTPS id 4fk28vkt0n-1 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NOT) for ; Thu, 23 Jul 2026 11:18:27 +0000 (GMT) Received: by mail-pl1-f198.google.com with SMTP id d9443c01a7336-2cc7ea29141so2830085ad.1 for ; Thu, 23 Jul 2026 04:18:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oss.qualcomm.com; s=google; t=1784805507; x=1785410307; darn=vger.kernel.org; h=content-transfer-encoding:content-type:in-reply-to:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to :content-type; bh=ItUM4hhcjDTFOB8mblvsJ6pDULGNPhKo1DxExHccibw=; b=GZWwMl7WyDYTCfkoomscRjk5qraEUEApaWEq3VPjj3GHwwqj+v2qF0sM4/uk2Jyehm TJo72ojcUUwx8bnGi8HogmltUWuScdMHd/DQM6vxQd1tSvixsyrqQ8Osrke7A0Tuxk0D vvBrQGH2IdkPeF4cmtHbTr3zK8kIXs+oOt1G3fNk5q2jJzw62mU9QFpU5wnT8vZzB0j7 09O4tTiZaIM9us49GuoVi6DYs3KO5Ik506Eno10SoOeyue0wmVFtHcYTT9cWXJSn5/YZ dijZpHT6amIisRFoyG8t4fVKnIXSuWI/ZdUBYhCA77taxSv/HqS7etKaBXwuhQaT8VmD XpdA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1784805507; x=1785410307; h=content-transfer-encoding:content-type:in-reply-to:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to:content-type; bh=ItUM4hhcjDTFOB8mblvsJ6pDULGNPhKo1DxExHccibw=; b=XjHPRm5U3AoTbXnCfz1WTuxKcWfdITTEPY7ClJkt3SbjTb+pbDMdpJUj1EKB/El4tM +E5P/1uBLvii20xR0Wzz082jW6qTChoOLGyYDwxnsXQDMBmR0QIOhg5I21VbpIS+dN86 N3aCZAbK6Dnc0GR+jqkU+F9O/S/7Rlw+i+HaH6iOh/QHjKA5RgqpiI2Knx4BAVNXtZ9g OpZ76CcQZtHRQrxoaLzmiKPildgo5jvkTPvN1gf69VCluyd4555zxheErVJirRg31Llm 4DPATQM4tAhky/vKug1omuRX5fiEeUluZHJHsUdsnlKz+rD8w/MnS7gJFCBoztv7JZLs /cyQ== X-Forwarded-Encrypted: i=1; AHgh+RpbWAt5pVxHX/BOQ6arqPnvkKbtAoCU0RZySZh/0oA/dpIaQ93ZMvX9YRDUWVPt51RCSrR3F+XnCL0RqdE=@vger.kernel.org X-Gm-Message-State: AOJu0Yyjat+2rwry2Li09InsbyMW8FJs4XxMMIiKWwTxGwV/zZ2R+wHm 610W9p5+kU/E5c0ckHMtm5ujEQtv7PDrQ9iYbH3hmZWwmipD7P4zd3xO7dRlg6sY9XnR8esNaQ7 DEGLR63fra2W59pKtdkFuInp09CF/yJKl4LTgAW8fmT2ATDLJUrIix8z5YsRTtICn6Sc= X-Gm-Gg: AR+sD137VNm1bf53tWhEhKfX/WhMrASbQjrK5CA2QtKZDinOrh2CSYhJlp+lLc9PmwU mO6aEPUUEJCA3hbS0yDmlx2bdqbuRBT9R8sLiNBQOzG8RTe1q/Eo3Ms2JSACZEJPE9g2FVmCPsr +O0HfMWRtCidb7y7dY+16wyZ+Qh9c1ZlZY/xjh8KghCTzpPA9SaP3mN/l7MFbbygXBkxHcPNk2m stzbvTEp3zxYwqJb+Gb131h2AVpe6z3kpQU1wYUmjsnSxy0DFKKAciCZtTZpPjhxssMbMKOP7Il wJAb7p+d/WZ/51B2K9+SUEJ+jtgzAkzOlstcusg2sAVTFwp01u1X18e6Mxs1TTuRVo+6F7gMUJ4 na8LH2Nx3vMgreJ5Sb7uvTaAf7vuNy5B5+woVzIqkaz1hCpkdRMtC9bjrm5eLhG9SOg== X-Received: by 2002:a17:903:124c:b0:2cc:e648:7e0c with SMTP id d9443c01a7336-2cfa6f8c2ffmr23522405ad.7.1784805506542; Thu, 23 Jul 2026 04:18:26 -0700 (PDT) X-Received: by 2002:a17:903:124c:b0:2cc:e648:7e0c with SMTP id d9443c01a7336-2cfa6f8c2ffmr23522065ad.7.1784805506044; Thu, 23 Jul 2026 04:18:26 -0700 (PDT) Received: from [10.133.33.62] (tpe-colo-wan-fw-bordernet.qualcomm.com. [103.229.16.4]) by smtp.gmail.com with ESMTPSA id d9443c01a7336-2cf8f3b46absm31470715ad.80.2026.07.23.04.18.23 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 23 Jul 2026 04:18:25 -0700 (PDT) Message-ID: Date: Thu, 23 Jul 2026 19:18:22 +0800 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH RFC v2 3/3] Bluetooth: Add hdev->recv_bt_vendor() to handle BT vendor frames To: Luiz Augusto von Dentz Cc: Marcel Holtmann , Zijun Hu , linux-bluetooth@vger.kernel.org, linux-kernel@vger.kernel.org References: <20260722-support_vendor_hci-v2-0-132b506460a4@oss.qualcomm.com> <20260722-support_vendor_hci-v2-3-132b506460a4@oss.qualcomm.com> Content-Language: en-US From: Zijun Hu In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Proofpoint-Spam-Info: AW1haW4tMjYwNzIzMDExMSBTYWx0ZWRfX6TAm9Mloq384 MpCGCr0fMmgzYbX7YRM28kNBIqv5AwCLr0vawCzpzjdyWlJb+Ulm76ndH9dhjSopwON4xVZMtU7 Af9TdEC05sf7pqqA+qZg03IesoXlfiA= X-Proofpoint-Spam-Details-Enc: AW1haW4tMjYwNzIzMDExMSBTYWx0ZWRfX76G/qfRbOpmB KmODCtQeokBl5IOqRypI5K6Gp/OkiEhfujeu5TuRWbuW3XEtSouA78IIrmVodnHgBzXMIWD0nAi 5LoJ+xcbET25ZFau3vKBnI3DgKJnt5DlWX/3loSeiGGYkNZOV9fYFkwfOtJwcIa1kVbtZFmc+bS JjMX27+G1ue6wp7PO3j1O434ZFaFFUmWM7CkhRDMnYo2SxMDMI5xuopj7ugxOk0xzsDMtfBo7nD FybrbBFp2+kAsqtYCx+H+1hFAOh26XgOU+By7vdwPLDd0LEcvGA17GCw+E0jzqBO8jNt0/Nzkr7 /Ory9u3fu6BdV1YWoGdaiRk3tyHXKE3OQnCaA8Y1QjrOqHMajkkNbRluCJPMX9GMhCSvb7nD9Vo mssGI95se9rS+O/3qq8cpOzMGlN6jNYaQ25Smc6FD5gxq0WGlVccu1Zk8D0mgOHkM0ODJWWEJFA b+XPGUBsok41yw/ZSxA== X-Proofpoint-ORIG-GUID: wL4NzJ6D17lP77DR5HZaaNW2ehHw23Qn X-Proofpoint-GUID: wL4NzJ6D17lP77DR5HZaaNW2ehHw23Qn X-Authority-Analysis: v=2.4 cv=D4V37PRj c=1 sm=1 tr=0 ts=6a61f883 cx=c_pps a=MTSHoo12Qbhz2p7MsH1ifg==:117 a=nuhDOHQX5FNHPW3J6Bj6AA==:17 a=IkcTkHD0fZMA:10 a=RAioF0-LDSMA:10 a=s4-Qcg_JpJYA:10 a=VkNPw1HP01LnGYTKEx00:22 a=u7WPNUs3qKkmUXheDGA7:22 a=rJkE3RaqiGZ5pbrm-msn:22 a=ai_aT568vvjzOLvgrnMA:9 a=3ZKOabzyN94A:10 a=QEXdDO2ut3YA:10 a=GvdueXVYPmCkWapjIL-Q:22 X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.293,Aquarius:18.0.1143,Hydra:6.1.134,FMLib:17.12.100.49 definitions=2026-07-23_03,2026-07-22_02,2025-10-01_01 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 lowpriorityscore=0 malwarescore=0 adultscore=0 priorityscore=1501 phishscore=0 spamscore=0 bulkscore=0 suspectscore=0 impostorscore=0 clxscore=1015 classifier=typeunknown authscore=0 authtc= authcc= route=outbound adjust=0 reason=mlx scancount=1 engine=8.22.0-2606150000 definitions=main-2607230111 On 7/23/2026 12:46 AM, Luiz Augusto von Dentz wrote: >> diff --git a/include/net/bluetooth/hci_core.h b/include/net/bluetooth/hci_core.h >> index 428261591288..12f3720f6cc8 100644 >> --- a/include/net/bluetooth/hci_core.h >> +++ b/include/net/bluetooth/hci_core.h >> @@ -646,6 +646,8 @@ struct hci_dev { >> int (*setup)(struct hci_dev *hdev); >> int (*shutdown)(struct hci_dev *hdev); >> int (*send)(struct hci_dev *hdev, struct sk_buff *skb); >> + /* Return true if @skb was consumed, false otherwise */ >> + bool (*recv_bt_vendor)(struct hci_dev *hdev, struct sk_buff *skb); > This should be probably called recv_vendor_ev or something like that. > For BT, besides VSEs, some vendors also reserve ACL handles for special usages, e.g.: | Vendor | Coredump | Other | |--------|----------|-----------------------------------------| | QCOM | 0xEDD | Enhanced Logging (0xEDC) | | MTK | 0xFC6F | Firmware debug logging (0x05FF, 0x05FE) | | NXP | 0xFFF | — | So this hook may need to cover both. Any suggestion for a good name? >> void (*recv_vendor_pkt)(struct hci_dev *hdev, struct sk_buff *skb); >> void (*notify)(struct hci_dev *hdev, unsigned int evt); >> void (*hw_error)(struct hci_dev *hdev, u8 code); >> @@ -2329,6 +2331,7 @@ static inline int hci_check_conn_params(u16 min, u16 max, u16 latency, >> int hci_register_cb(struct hci_cb *hcb); >> int hci_unregister_cb(struct hci_cb *hcb); >> >> +bool hci_recv_bt_vendor(struct hci_dev *hdev, struct sk_buff *skb); >> int hci_send_vendor_frame(struct hci_dev *hdev, struct iov_iter *iter); >> [...] >> static bool hci_req_is_complete(struct hci_dev *hdev) >> { >> struct sk_buff *skb; >> diff --git a/net/bluetooth/hci_event.c b/net/bluetooth/hci_event.c >> index ea858391c789..94c02b66bdfa 100644 >> --- a/net/bluetooth/hci_event.c >> +++ b/net/bluetooth/hci_event.c >> @@ -7801,6 +7801,11 @@ void hci_event_packet(struct hci_dev *hdev, struct sk_buff *skb) >> goto done; >> } >> >> + if (hci_recv_bt_vendor(hdev, skb)) { >> + hdev->stat.evt_rx++; >> + return; >> + } > This seems too early actually, I would have expected it to run after > hci_event_func or within it if ev->func is NULL, that said we I don't think running it after hci_event_func() works, because the VSE has already been corrupted by then, as explained below: msft_vendor_evt() is the handler for all vendor events called by hci_event_func(), but many VSEs are not MSFT ones. Once the MSFT extension is enabled, it always calls skb_pull_data() and corrupts the non-MSFT VSEs. Besides, running it there is asymmetric with the ACL path: the event header is already pulled, but the ACL header isn't. For ev->func is NULL: it may mean we don't need to care about that event, so the current behavior of ignoring it is reasonable. > currently assume HCI_EV_VENDOR=msft_vendor_evt which is probably not > valid, or maybe it is which then screw the whole idea that 0xff is > only used with 1 vendor specific domain, now if we try to squeesh both > a vendor event and a msft event handler their opcodes shall not > collide otherwise the whole thing doesn't work. > let me explain more for recv_bt_vendor() for BT as below: Design idea: let the transport driver consume whatever frames it is interested in first; for the rest, don't care how the stack handles them — it doesn't matter even if they are corrupted. Motivation: For the VSEs and vendor-reserved-handle ACLs that transport drivers are interested in, move their handling from the transport driver's RX path (IRQ-disabled context) to the stack's process context — i.e. avoid pre-processing them. Advantages: -) Avoid skb_clone() in IRQ-disabled context of RX-path to improve performance take INTEL diagnostic events as an example, btintel_diagnostics() skb_clone() them -) Avoid re-processing VSEs that the driver has already handled. Intel diagnostic events still arrive at hci_event_packet() in hci_rx_work(), even though they have already been handled by btintel_diagnostics(). -) Log them via btmon to help debugging  Several existing transport drivers consume these frames directly without btmon logging I'd welcome your thoughts — especially on the hook name (point 1) and whether the placement/design here is acceptable. Happy to rework it based on your guidance. > Anyway, I had the impression you would be using a vendor packet not a > vendor event, or you use both? > My PERI-HCI requirement is already addressed by recv_vendor_pkt() in [PATCH 2/3] This hook, recv_bt_vendor(), addresses concerns raised during the BT-HCI discussion. The same problem exists in many transport drivers, so it tries to address them for BT along the way I'd like to use it in the upcoming QCC2072 support as well, once these concerns are resolved. >> hci_dev_lock(hdev); >> kfree_skb(hdev->recv_event); >> hdev->recv_event = skb_clone(skb, GFP_KERNEL);