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 2AFE7345EC5 for ; Thu, 23 Jul 2026 18:52:39 +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=1784832764; cv=none; b=CRElnCVPbA5sBqFgVcjtW/Nt5IJ0YFudezZUmwZKJb/9IJsGWet9z6CAneMf+OftVysNoOomkZPNnKtXz+wj/FEYZMnLYfqWbqS2QTaTj5bMwVI6U75teJaBrwzhKI5WuqvtvcQm2gDsTpdjm7/fwxlmpLHN7fOSkov4mrqibeg= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1784832764; c=relaxed/simple; bh=VaD4gNd5X4Wjyy6tXleEa8bVwP3r7+41qmhxFSCdS00=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=rMdbV9iJ6ZMYwCPYMMNSDXjO6IFNb523nWR+FddIE+0Bt6nVT4UVPOY2K58LBhTrt5MV1u/3K4dxGT4j3z6HxYxb49ujdXBNHRYaXBjtcdg5XCzycLQ/CaxFa3Jx3TF/6QxvOsIHZWmPBkTMZFyoHajTtnBV2btAMvsXP26RAmU= 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=RCQbmkl9; dkim=pass (2048-bit key) header.d=oss.qualcomm.com header.i=@oss.qualcomm.com header.b=g9J/dYE8; 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="RCQbmkl9"; dkim=pass (2048-bit key) header.d=oss.qualcomm.com header.i=@oss.qualcomm.com header.b="g9J/dYE8" Received: from pps.filterd (m0279870.ppops.net [127.0.0.1]) by mx0a-0031df01.pphosted.com (8.18.1.11/8.18.1.11) with ESMTP id 66NIm3Hc800594 for ; Thu, 23 Jul 2026 18:52:38 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= Seb4F7fZtpNU6xSkQHlAEJtFAcCH3IYe6nEuksYWwDI=; b=RCQbmkl9RfjckUKP BgLKXX3DOhpWbYQF3Z9qn5Ybvgn5cirOefIvj5jq34Io5QJhfN0o5npiVA5ueeem jMBy8q7P+3C55/KqrX+nk1JAuEr3pyNzm5XfPrsjjt2E7KwjVCS+06QIlriO9Y7C bOVhdbmtaqjvcTtPv7mCzngb8bufO7QRWSUwAMTGwimBvp3QoBuga8hlk0+kzSMV MRrker7fDObCUcR5tHfqUFTid7LwXejXRKisIQc8HLFEsRfy8eS85WDr3OBvIMuE GNTcusrs8yRcJeh2z/XQikInK8iezzLiqli+jScmDJSzEBUfBOeMgGZbZUrli//e aHHwLw== Received: from mail-pf1-f198.google.com (mail-pf1-f198.google.com [209.85.210.198]) by mx0a-0031df01.pphosted.com (PPS) with ESMTPS id 4fke7qk4vb-1 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NOT) for ; Thu, 23 Jul 2026 18:52:38 +0000 (GMT) Received: by mail-pf1-f198.google.com with SMTP id d2e1a72fcca58-848c9eb2954so284719b3a.3 for ; Thu, 23 Jul 2026 11:52:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oss.qualcomm.com; s=google; t=1784832757; x=1785437557; 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=Seb4F7fZtpNU6xSkQHlAEJtFAcCH3IYe6nEuksYWwDI=; b=g9J/dYE8GjAaFYg4d4IQC6XGNnR4Y38e/Vhm+LfBVZ3HFVIu8/e1lLU39hx2M8W6nM 0B0dlrbq85uSArRNP51vHhEHEyE0gl620PahTzFplIrkaVTn+8vAsxv2d+896il5g/tn 53dnPcQfvuEr8m4Idjvz4bOZWmK3MHzHBRp4IyfgpYEyM4VnrzDVmC9uLTlKXLaI5XKo 1GhI8alsVV5ClKtaGdSUMtxUv+Rv94u2XkvXCSxLl5cp9tKdUGLQXHmgyk/7hiXg1t47 IotowDXKvTUSmDe0Ic0pZyOE5DxJW4DFltD4N0Y8hoqvWCPYRcBvyvkbba8YZoq7Qsbz JL6A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1784832757; x=1785437557; 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=Seb4F7fZtpNU6xSkQHlAEJtFAcCH3IYe6nEuksYWwDI=; b=nOT92IaXVfrY8xMEluvg3cxw32IPKOeQT/iObR9uwkKlmDUErngPXGdJY+KSg+4skp 5bZ8mpNpmF8TUd5y6XiR2a/R9hhy35YgduVyj7gGSpVwC80ssiPar3DA5SUCDW1WuIb1 mBrI03hl6j7fB2N2DH7/hldiU4rvgVx4MlphOsojMirPyyZwFobpJ3b2T6qiFo7VFFnO 9wFlBqNVpa9f7tseDMETaOwTE5J1WmjEOVe4qV1Z8DRfI6c7T8VFJYryzWQohDQykxqD MbTqXz9f0dNK4bnAmckxwkGTLTBe5958EKqRICRhqUWxJmONNCQ2j4sbXs33MrJmVpO/ 4bFA== X-Forwarded-Encrypted: i=1; AHgh+RqZxwPKVgKDcI071KLi94tP2R/FxDDt1aaVhWHCo4oB6+hAahiojVifhBPItgYp/SiY1pxrF/BGK1a+V5Y=@vger.kernel.org X-Gm-Message-State: AOJu0YxfgHJGfVs8g3AK2sR8Qzl5E3pnMORqoxnSihdwlpBarawUgmht 6QTM+drXWe/RxE+oRNhY63UC56mJhaqMFWAArPnZNgYoV6ra2XMYpiSLhG4ViPDuIsnneI3KYx9 xTWcizNugbxPiU3hBI94nguOqZr5y3DB4im78gv8g51MlFweqn2yHyfshYrJz9DIJQq8= X-Gm-Gg: AR+sD11iAQxZys828FZpxBqB96L7luVwA+w5s4KrQIfB2kgtUOKISxmHhgbkAu+dH5P DL+Q+QB23/k2mJ24y645V3Oxd4kw3IOpwP4cEW4gClBZn1m/J/iHRUC1V85hZj3FUpazH0EGHqR SfOUXheU0nsLG9og7qRzU+1OzIFkELzowLZE1vAcO8TJjF5ZDys0z2b3ERU8//dJwpsTxYme9xN zTEcpso9iDHWpGROoRifZpUIty6eGvSgsHag/nbKTn3AEgdvGarrdmt5v4SaMcZS8vc1v0/j78d 4mj1oR0J1pdPREGDGb1Bt16c3NSUf65F8A8kqQr93YxddVpSV1q3RehQu+weHgt7W8FFc8yAc7z jaax5ABKd4pzMt6D6ZRpBMAjpDBjgajxHPc3UkyXDN/RxUobAoKfAyB2Mg3EV6MlsEK0= X-Received: by 2002:a05:6a21:648c:b0:3bf:a881:408f with SMTP id adf61e73a8af0-3c44b38a23emr3651594637.8.1784832756691; Thu, 23 Jul 2026 11:52:36 -0700 (PDT) X-Received: by 2002:a05:6a21:648c:b0:3bf:a881:408f with SMTP id adf61e73a8af0-3c44b38a23emr3651560637.8.1784832756064; Thu, 23 Jul 2026 11:52:36 -0700 (PDT) Received: from [10.249.17.165] (tpe-colo-wan-fw-bordernet.qualcomm.com. [103.229.16.4]) by smtp.gmail.com with ESMTPSA id 41be03b00d2f7-cbb8f0ee1e6sm3077178a12.12.2026.07.23.11.52.34 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 23 Jul 2026 11:52:35 -0700 (PDT) Message-ID: <14a35a4f-59c6-470b-a98d-81a38cd66db8@oss.qualcomm.com> Date: Fri, 24 Jul 2026 02:52:32 +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: AW1haW4tMjYwNzIzMDE4NCBTYWx0ZWRfX9abq587YaS9H PQCbvrzsrmcGyR7ar/ZxWSRfJ8T7wzai21CGtHlDFNxhTprXVvszbTUQqrMV9VdMn4PcldbfuX/ TOjaddmf5XY3dConkzhdwKxx/GJ7yMI= X-Authority-Analysis: v=2.4 cv=aYxRWxot c=1 sm=1 tr=0 ts=6a6262f6 cx=c_pps a=m5Vt/hrsBiPMCU0y4gIsQw==:117 a=nuhDOHQX5FNHPW3J6Bj6AA==:17 a=IkcTkHD0fZMA:10 a=RAioF0-LDSMA:10 a=s4-Qcg_JpJYA:10 a=VkNPw1HP01LnGYTKEx00:22 a=u7WPNUs3qKkmUXheDGA7:22 a=gowsoOTTUOVcmtlkKump:22 a=rbelQ3siGXwaCEnk8YYA:9 a=3ZKOabzyN94A:10 a=QEXdDO2ut3YA:10 a=IoOABgeZipijB_acs4fv:22 X-Proofpoint-GUID: 2edpKcx8fI7Wt_OW92g-VNI0NDLXJijf X-Proofpoint-Spam-Details-Enc: AW1haW4tMjYwNzIzMDE4NCBTYWx0ZWRfX69L4340Avazf 6kb2VOmB4HU9H5TrwwXglffyuSywihMdvNPFKjoXufOWwwlPWH/x2zwPfG1siVJbZBL5mTtq9BI Gu3mSrZd0LjfxQfeAGb+2k28Y6cNtt5445IUKu0vW/2Kn3/EX0VRoy683Czu56Uk60tvQCOCeti sCPxbwHin/kto+x8RvREK+1rv0iWtQBTEpcVSyFfihAKoX6CR1RhawWMafnTfMQnKMOons6efOb dqn+76VUZsdKl2ipz9gqy8ZzVBYgbDwpsji0SHbg85dSuJMhWXwJ4a6J3XvqydeW8ZIx0WBcIAH VjguuA7V0WlO4BqN/LpjfGvii4nVNWP89qkPWW6EKdG/dKQ384b1EAq1jax/aL32f8X2V7r6IZb w0VJAud6jtnZ+KRevOicKCxBiiDv9OKM0+riGd0whcmUmmKde1uSd9UKMkw9aXHO7M+RGuEoh74 IHmrQLyaLwVGowTK1Pw== X-Proofpoint-ORIG-GUID: 2edpKcx8fI7Wt_OW92g-VNI0NDLXJijf 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_06,2026-07-22_02,2025-10-01_01 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 priorityscore=1501 impostorscore=0 malwarescore=0 spamscore=0 lowpriorityscore=0 phishscore=0 bulkscore=0 clxscore=1015 adultscore=0 suspectscore=0 classifier=typeunknown authscore=0 authtc= authcc= route=outbound adjust=0 reason=mlx scancount=1 engine=8.22.0-2606150000 definitions=main-2607230184 On 7/23/2026 9:56 PM, Luiz Augusto von Dentz wrote: >> | 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? > Derr, connection traffic is not handled as events and you have the > likes of hdev->classify_pkt_type(hdev, skb); to reclassify them to > HCI_DIAG_PKT. Don't tell me the firmware it generating Connection > Complete, NOCP, or any other event, for these because that is totally > against the spec since the handle wouldn't match any connection. > okay, got your point. so, what about changing recv_vendor_ev() to recv_ev_vendor() to map HCI_EV_VENDOR ? >>>> 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. > Well I already told you that by doing preposing we may expose driver > to the same type of bugs that existed in core in the past, so we maybe > reintroducing parsing errors and since this requires to preserve the > skb it will not be able to use skb_data_pulll (which internally checks > skb->len). > Sorry, my description was misleading. The callback registered by the transport driver is meant to avoid pre-processing: the stack invokes it for the driver's VSEs of interest, and the callback then uses skb_pull_data() to handle the event just as the stack would. >> 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(). > What does btintel have to do with this? Are you saying there are bugs > in it and you are trying to report them here? No, I'm not reporting bugs in btintel. Almost all transport drivers handle these vendor frames the same way show what this callback may improve, using Intel as an example since it came up earlier as a reference. Any further comments ?