Message ID | 20221116202856.55847-1-mat.jonczyk@o2.pl |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:adf:f944:0:0:0:0:0 with SMTP id q4csp48797wrr; Wed, 16 Nov 2022 12:31:37 -0800 (PST) X-Google-Smtp-Source: AA0mqf6RRZnxbYl5vGbouqn0VYbR6E0DqD0xgwGaWS7rlfN5+zeDCOUDotOzXZrHg+wtuR1XyNhl X-Received: by 2002:a17:906:eb0c:b0:7ad:e178:de59 with SMTP id mb12-20020a170906eb0c00b007ade178de59mr19097674ejb.449.1668630697776; Wed, 16 Nov 2022 12:31:37 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1668630697; cv=none; d=google.com; s=arc-20160816; b=ZQX4Sb8gOZNKqqDI06+lfQIsG4NBApjryCYIbVli+pRVpqxHozjPhT6Zyxpo0xheHr fPIjoaxNDqe90H8RYs5MPLr7ogCC7tyAAk51if0GJRgHXqSfyecwX7fEEDsu9Ef9w6ay P4FGu98n5fH75sbUsd8aQQ5s5QJ4OXEe2pnscctnNkh8NbkJ1cwNmmkPWrsSox+ufTk3 os7dr4aBe1QsyiAWl/egwz4BywqXdBszUf8yOfa7j80sS9CPKFh1aEcAfLi9Mu8Emiaz dbrMC1Ou5WT99OfNKM8lNqwDc3EEHhr1rFdx4ErEk/3JJGBlOkKCfld7kNJzMvrLtmPm 9kxg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :message-id:date:subject:cc:to:from:dkim-signature; bh=wIPDLnO3IoAeI00Smq/ujtO4jdLyKZdBbvJO81An0Us=; b=hEW44ux9fjjxy3daH4m6NI9OCUKltM9agDGfUarltsanOA7KqyPayN7SJu/BTKLesR 8ftOsgIoIonvWAqhiO3bP+PtM2PVSU1gjpgd35qBeuYKVg9yaQU25OVMZ9fgIqYBNDL4 p57TXXf80Yug6liMF2yBeSEqLK0555EDZ2EpaQ+qVU3IfkJH90kkgsomlWQTKGTJ8zGT KGCLpiJNnnGV5vKt7AvFOAvA4QR5qiKImDutrMLzP2atCbtg7PORk3WI18zhMmCAxXvM 5BNLPTByN7zzfMHy/CSl8tPE9OpA3GkqodiVGHpP9V7ECDkwQCSv1ZaQotRZz/I/vpaB g0cw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass (test mode) header.i=@o2.pl header.s=1024a header.b=ahtEv54o; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=o2.pl Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id nc41-20020a1709071c2900b007878c9d73a2si13359884ejc.426.2022.11.16.12.31.14; Wed, 16 Nov 2022 12:31:37 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass (test mode) header.i=@o2.pl header.s=1024a header.b=ahtEv54o; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=o2.pl Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S233981AbiKPU3c (ORCPT <rfc822;just.gull.subs@gmail.com> + 99 others); Wed, 16 Nov 2022 15:29:32 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:49956 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S233438AbiKPU3b (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Wed, 16 Nov 2022 15:29:31 -0500 Received: from mx-out.tlen.pl (mx-out.tlen.pl [193.222.135.142]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id ADE0CA1A8 for <linux-kernel@vger.kernel.org>; Wed, 16 Nov 2022 12:29:28 -0800 (PST) Received: (wp-smtpd smtp.tlen.pl 10810 invoked from network); 16 Nov 2022 21:29:21 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=o2.pl; s=1024a; t=1668630561; bh=wIPDLnO3IoAeI00Smq/ujtO4jdLyKZdBbvJO81An0Us=; h=From:To:Cc:Subject; b=ahtEv54oe3So5cDD0xuRqhdgCPnPfel5z6Z6Z7TSlT3OpWgOs5pZnaP0cwmLk+IpW v8rF7ca+UmzuCnqMDd/b5sfRS1oZPN4igsdS2juPNG2O3dTRvt76AcqMAxtX+TaXj0 i0VZOc1q14HNBx4pVgvtqeAiiXUrZ/eJIEVwP2tk= Received: from aafn183.neoplus.adsl.tpnet.pl (HELO localhost.localdomain) (mat.jonczyk@o2.pl@[83.4.143.183]) (envelope-sender <mat.jonczyk@o2.pl>) by smtp.tlen.pl (WP-SMTPD) with SMTP for <linux-bluetooth@vger.kernel.org>; 16 Nov 2022 21:29:21 +0100 From: =?utf-8?q?Mateusz_Jo=C5=84czyk?= <mat.jonczyk@o2.pl> To: linux-bluetooth@vger.kernel.org, netdev@vger.kernel.org, linux-kernel@vger.kernel.org Cc: =?utf-8?q?Mateusz_Jo=C5=84czyk?= <mat.jonczyk@o2.pl>, Brian Gix <brian.gix@intel.com>, Luiz Augusto von Dentz <luiz.von.dentz@intel.com>, Marcel Holtmann <marcel@holtmann.org>, Johan Hedberg <johan.hedberg@gmail.com> Subject: [PATCH] Bluetooth: silence a dmesg error message in hci_request.c Date: Wed, 16 Nov 2022 21:28:56 +0100 Message-Id: <20221116202856.55847-1-mat.jonczyk@o2.pl> X-Mailer: git-send-email 2.25.1 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-WP-MailID: cf8b44b908658acece8b81a6ab35ced6 X-WP-AV: skaner antywirusowy Poczty o2 X-WP-SPAM: NO 000000B [0XNk] X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM,SPF_HELO_NONE, SPF_PASS autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: <linux-kernel.vger.kernel.org> X-Mailing-List: linux-kernel@vger.kernel.org X-getmail-retrieved-from-mailbox: =?utf-8?q?INBOX?= X-GMAIL-THRID: =?utf-8?q?1749686102335392619?= X-GMAIL-MSGID: =?utf-8?q?1749686102335392619?= |
Series |
Bluetooth: silence a dmesg error message in hci_request.c
|
|
Commit Message
Mateusz Jończyk
Nov. 16, 2022, 8:28 p.m. UTC
On kernel 6.1-rcX, I have been getting the following dmesg error message
on every boot, resume from suspend and rfkill unblock of the Bluetooth
device:
Bluetooth: hci0: HCI_REQ-0xfcf0
After some investigation, it turned out to be caused by
commit dd50a864ffae ("Bluetooth: Delete unreferenced hci_request code")
which modified hci_req_add() in net/bluetooth/hci_request.c to always
print an error message when it is executed. In my case, the function was
executed by msft_set_filter_enable() in net/bluetooth/msft.c, which
provides support for Microsoft vendor opcodes.
As explained by Brian Gix, "the error gets logged because it is using a
deprecated (but still working) mechanism to issue HCI opcodes" [1]. So
this is just a debugging tool to show that a deprecated function is
executed. As such, it should not be included in the mainline kernel.
See for example
commit 771c035372a0 ("deprecate the '__deprecated' attribute warnings entirely and for good")
Additionally, this error message is cryptic and the user is not able to
do anything about it.
[1]
Link: https://lore.kernel.org/lkml/beb8dcdc3aee4c5c833aa382f35995f17e7961a1.camel@intel.com/
Fixes: dd50a864ffae ("Bluetooth: Delete unreferenced hci_request code")
Signed-off-by: Mateusz Jończyk <mat.jonczyk@o2.pl>
Cc: Brian Gix <brian.gix@intel.com>
Cc: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
Cc: Marcel Holtmann <marcel@holtmann.org>
Cc: Johan Hedberg <johan.hedberg@gmail.com>
---
net/bluetooth/hci_request.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
base-commit: 094226ad94f471a9f19e8f8e7140a09c2625abaa
Comments
Hello: This patch was applied to bluetooth/bluetooth-next.git (master) by Luiz Augusto von Dentz <luiz.von.dentz@intel.com>: On Wed, 16 Nov 2022 21:28:56 +0100 you wrote: > On kernel 6.1-rcX, I have been getting the following dmesg error message > on every boot, resume from suspend and rfkill unblock of the Bluetooth > device: > > Bluetooth: hci0: HCI_REQ-0xfcf0 > > After some investigation, it turned out to be caused by > commit dd50a864ffae ("Bluetooth: Delete unreferenced hci_request code") > which modified hci_req_add() in net/bluetooth/hci_request.c to always > print an error message when it is executed. In my case, the function was > executed by msft_set_filter_enable() in net/bluetooth/msft.c, which > provides support for Microsoft vendor opcodes. > > [...] Here is the summary with links: - Bluetooth: silence a dmesg error message in hci_request.c https://git.kernel.org/bluetooth/bluetooth-next/c/c3fd63f7fe5a You are awesome, thank you!
Hi Mateusz, On Wed, 2022-11-16 at 21:28 +0100, Mateusz Jończyk wrote: > On kernel 6.1-rcX, I have been getting the following dmesg error > message > on every boot, resume from suspend and rfkill unblock of the > Bluetooth > device: > > Bluetooth: hci0: HCI_REQ-0xfcf0 > This has a patch that fixes the usage of the deprecated HCI_REQ mechanism rather than hiding the fact it is being called, as in this case. I am still waiting for someone to give me a "Tested-By:" tag to patch: [PATCH 1/1] Bluetooth: Convert MSFT filter HCI cmd to hci_sync Which will also stop the dmesg error. If you could try that patch, and resend it to the list with a Tested-By tag, it can be applied. We still want to be allerted to deprecated usage situations. > After some investigation, it turned out to be caused by > commit dd50a864ffae ("Bluetooth: Delete unreferenced hci_request > code") > which modified hci_req_add() in net/bluetooth/hci_request.c to always > print an error message when it is executed. In my case, the function > was > executed by msft_set_filter_enable() in net/bluetooth/msft.c, which > provides support for Microsoft vendor opcodes. > > As explained by Brian Gix, "the error gets logged because it is using > a > deprecated (but still working) mechanism to issue HCI opcodes" [1]. > So > this is just a debugging tool to show that a deprecated function is > executed. As such, it should not be included in the mainline kernel. > See for example > commit 771c035372a0 ("deprecate the '__deprecated' attribute warnings > entirely and for good") > Additionally, this error message is cryptic and the user is not able > to > do anything about it. > > [1] > Link: > https://lore.kernel.org/lkml/beb8dcdc3aee4c5c833aa382f35995f17e7961a1.camel@intel.com/ > > Fixes: dd50a864ffae ("Bluetooth: Delete unreferenced hci_request > code") > Signed-off-by: Mateusz Jończyk <mat.jonczyk@o2.pl> > Cc: Brian Gix <brian.gix@intel.com> > Cc: Luiz Augusto von Dentz <luiz.von.dentz@intel.com> > Cc: Marcel Holtmann <marcel@holtmann.org> > Cc: Johan Hedberg <johan.hedberg@gmail.com> > --- > net/bluetooth/hci_request.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/net/bluetooth/hci_request.c > b/net/bluetooth/hci_request.c > index 5a0296a4352e..f7e006a36382 100644 > --- a/net/bluetooth/hci_request.c > +++ b/net/bluetooth/hci_request.c > @@ -269,7 +269,7 @@ void hci_req_add_ev(struct hci_request *req, u16 > opcode, u32 plen, > void hci_req_add(struct hci_request *req, u16 opcode, u32 plen, > const void *param) > { > - bt_dev_err(req->hdev, "HCI_REQ-0x%4.4x", opcode); > + bt_dev_dbg(req->hdev, "HCI_REQ-0x%4.4x", opcode); > hci_req_add_ev(req, opcode, plen, param, 0); > } > > > base-commit: 094226ad94f471a9f19e8f8e7140a09c2625abaa Regards, --Brian Gix
W dniu 17.11.2022 o 21:34, Gix, Brian pisze: > Hi Mateusz, > > On Wed, 2022-11-16 at 21:28 +0100, Mateusz Jończyk wrote: >> On kernel 6.1-rcX, I have been getting the following dmesg error >> message >> on every boot, resume from suspend and rfkill unblock of the >> Bluetooth >> device: >> >> Bluetooth: hci0: HCI_REQ-0xfcf0 >> > This has a patch that fixes the usage of the deprecated HCI_REQ > mechanism rather than hiding the fact it is being called, as in this > case. > > I am still waiting for someone to give me a "Tested-By:" tag to patch: > > [PATCH 1/1] Bluetooth: Convert MSFT filter HCI cmd to hci_sync > > Which will also stop the dmesg error. If you could try that patch, and > resend it to the list with a Tested-By tag, it can be applied. Hello, I did not receive this patch, as I was not on the CC list; I was not aware of it. I will test it shortly. Any guidelines how I should test this functionality? I have a Sony Xperia 10 i4113 mobile phone with LineageOS 19.1 / Android 12L, which according to the spec supports Bluetooth 5.0. Quick Google search tells me that I should do things like hcitool lescan to discover the phone, then use gatttool to list the services, etc. Greetings, Mateusz
Hi Mateusz, On Thu, 2022-11-17 at 22:27 +0100, Mateusz Jończyk wrote: > W dniu 17.11.2022 o 21:34, Gix, Brian pisze: > > On Wed, 2022-11-16 at 21:28 +0100, Mateusz Jończyk wrote: > > > On kernel 6.1-rcX, I have been getting the following dmesg error > > > message > > > on every boot, resume from suspend and rfkill unblock of the > > > Bluetooth > > > device: > > > > > > Bluetooth: hci0: HCI_REQ-0xfcf0 > > > > > This has a patch that fixes the usage of the deprecated HCI_REQ > > mechanism rather than hiding the fact it is being called, as in > > this > > case. > > > > I am still waiting for someone to give me a "Tested-By:" tag to > > patch: > > > > [PATCH 1/1] Bluetooth: Convert MSFT filter HCI cmd to hci_sync > > > > Which will also stop the dmesg error. If you could try that patch, > > and > > resend it to the list with a Tested-By tag, it can be applied. > > Hello, > > I did not receive this patch, as I was not on the CC list; I was not > aware of it. I will test it shortly. > > Any guidelines how I should test this functionality? I have a Sony > Xperia 10 i4113 > mobile phone with LineageOS 19.1 / Android 12L, which according to > the spec supports > Bluetooth 5.0. Quick Google search tells me that I should do things > like > > hcitool lescan > Whatever you were running that produced the "Bluetooth: hci0: HCI_REQ-0xfcf0" error in the dmesg log should be sufficient to determine that the error log is no longer happening. The HCI call is necessary on some platforms, so the absense of other negative behavior should be sufficient to verify that the call is still being made. The code flow itself has not changed, and new coding enforces the HCI command sequence, so that it is more deterministric than it was with hci_request. The hci_request mechanism was an asyncronous request. > to discover the phone, then use gatttool to list the services, etc. > > Greetings, > > Mateusz >
Hi, On Thu, Nov 17, 2022 at 1:45 PM Gix, Brian <brian.gix@intel.com> wrote: > > Hi Mateusz, > > On Thu, 2022-11-17 at 22:27 +0100, Mateusz Jończyk wrote: > > W dniu 17.11.2022 o 21:34, Gix, Brian pisze: > > > On Wed, 2022-11-16 at 21:28 +0100, Mateusz Jończyk wrote: > > > > On kernel 6.1-rcX, I have been getting the following dmesg error > > > > message > > > > on every boot, resume from suspend and rfkill unblock of the > > > > Bluetooth > > > > device: > > > > > > > > Bluetooth: hci0: HCI_REQ-0xfcf0 > > > > > > > This has a patch that fixes the usage of the deprecated HCI_REQ > > > mechanism rather than hiding the fact it is being called, as in > > > this > > > case. > > > > > > I am still waiting for someone to give me a "Tested-By:" tag to > > > patch: > > > > > > [PATCH 1/1] Bluetooth: Convert MSFT filter HCI cmd to hci_sync > > > > > > Which will also stop the dmesg error. If you could try that patch, > > > and > > > resend it to the list with a Tested-By tag, it can be applied. > > > > Hello, > > > > I did not receive this patch, as I was not on the CC list; I was not > > aware of it. I will test it shortly. You can find the patch here: https://patchwork.kernel.org/project/bluetooth/patch/20221102175927.401091-2-brian.gix@intel.com/ > > > > Any guidelines how I should test this functionality? I have a Sony > > Xperia 10 i4113 > > mobile phone with LineageOS 19.1 / Android 12L, which according to > > the spec supports > > Bluetooth 5.0. Quick Google search tells me that I should do things > > like > > > > hcitool lescan > > > > Whatever you were running that produced the > > "Bluetooth: hci0: HCI_REQ-0xfcf0" > > error in the dmesg log should be sufficient to determine that the error > log is no longer happening. The HCI call is necessary on some > platforms, so the absense of other negative behavior should be > sufficient to verify that the call is still being made. The code flow > itself has not changed, and new coding enforces the HCI command > sequence, so that it is more deterministric than it was with > hci_request. The hci_request mechanism was an asyncronous request. > > > to discover the phone, then use gatttool to list the services, etc. > > > > Greetings, > > > > Mateusz > > >
W dniu 16.11.2022 o 22:40, patchwork-bot+bluetooth@kernel.org pisze: > Hello: > > This patch was applied to bluetooth/bluetooth-next.git (master) > by Luiz Augusto von Dentz <luiz.von.dentz@intel.com>: > > On Wed, 16 Nov 2022 21:28:56 +0100 you wrote: >> On kernel 6.1-rcX, I have been getting the following dmesg error message >> on every boot, resume from suspend and rfkill unblock of the Bluetooth >> device: >> >> Bluetooth: hci0: HCI_REQ-0xfcf0 >> >> After some investigation, it turned out to be caused by >> commit dd50a864ffae ("Bluetooth: Delete unreferenced hci_request code") >> which modified hci_req_add() in net/bluetooth/hci_request.c to always >> print an error message when it is executed. In my case, the function was >> executed by msft_set_filter_enable() in net/bluetooth/msft.c, which >> provides support for Microsoft vendor opcodes. >> >> [...] > Here is the summary with links: > - Bluetooth: silence a dmesg error message in hci_request.c > https://git.kernel.org/bluetooth/bluetooth-next/c/c3fd63f7fe5a > > You are awesome, thank you! Hello, Thank you. I would like to ask: is this patch going to be merged for kernel 6.1? The error message that this patch silences will no doubt confuse some users if it will be released in Linux 6.1.0. Greetings, Mateusz
diff --git a/net/bluetooth/hci_request.c b/net/bluetooth/hci_request.c index 5a0296a4352e..f7e006a36382 100644 --- a/net/bluetooth/hci_request.c +++ b/net/bluetooth/hci_request.c @@ -269,7 +269,7 @@ void hci_req_add_ev(struct hci_request *req, u16 opcode, u32 plen, void hci_req_add(struct hci_request *req, u16 opcode, u32 plen, const void *param) { - bt_dev_err(req->hdev, "HCI_REQ-0x%4.4x", opcode); + bt_dev_dbg(req->hdev, "HCI_REQ-0x%4.4x", opcode); hci_req_add_ev(req, opcode, plen, param, 0); }