Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 48D7AC433EF for ; Mon, 29 Nov 2021 09:06:39 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S242060AbhK2JJz (ORCPT ); Mon, 29 Nov 2021 04:09:55 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:52838 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S240013AbhK2JHy (ORCPT ); Mon, 29 Nov 2021 04:07:54 -0500 Received: from wp530.webpack.hosteurope.de (wp530.webpack.hosteurope.de [IPv6:2a01:488:42:1000:50ed:8234::]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 31224C0619E6; Mon, 29 Nov 2021 00:52:48 -0800 (PST) Received: from [77.23.61.74] (helo=[192.168.66.200]); authenticated by wp530.webpack.hosteurope.de running ExIM with esmtpsa (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) id 1mrcOw-0003yU-Ib; Mon, 29 Nov 2021 09:52:42 +0100 Message-ID: <50735c6a-6a33-e4b8-a15a-b9efec933bef@leemhuis.info> Date: Mon, 29 Nov 2021 09:52:42 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.3.0 Subject: Re: [PATCH v3 1/2] Bluetooth: add quirk disabling LE Read Transmit Power Content-Language: en-BS To: Aditya Garg , Marcel Holtmann Cc: Greg KH , Orlando Chamberlain , Daniel Winkler , Johan Hedberg , "linux-bluetooth@vger.kernel.org" , "linux-kernel@vger.kernel.org" , Luiz Augusto von Dentz , "regressions@lists.linux.dev" , "sonnysasaka@chromium.org" , "stable@vger.kernel.org" References: <3B8E16FA-97BF-40E5-9149-BBC3E2A245FE@live.com> <52DEDC31-EEB2-4F39-905F-D5E3F2BBD6C0@live.com> <8919a36b-e485-500a-2722-529ffa0d2598@leemhuis.info> <20211117124717.12352-1-redecorating@protonmail.com> <40550C00-4EE5-480F-AFD4-A2ACA01F9DBB@live.com> <332a19f1-30f0-7058-ac18-c21cf78759bb@leemhuis.info> <287DE71A-2BF2-402D-98C8-24A9AEEE55CB@live.com> <42E2EC08-1D09-4DDE-B8B8-7855379C23C5@holtmann.org> <6ABF3770-A9E8-4DAF-A22D-DA7113F444F3@live.com> From: Thorsten Leemhuis In-Reply-To: <6ABF3770-A9E8-4DAF-A22D-DA7113F444F3@live.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-bounce-key: webpack.hosteurope.de;regressions@leemhuis.info;1638175968;360f7ded; X-HE-SMSGID: 1mrcOw-0003yU-Ib Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi! Great to see progress for this regression. On 29.11.21 09:32, Aditya Garg wrote: > From: Aditya Garg > > Some devices have a bug causing them to not work if they query > LE tx power on startup. Thus we add a quirk in order to not query it > and default min/max tx power values to HCI_TX_POWER_INVALID. > > Signed-off-by: Aditya Garg > --- FWIW: In case you need to send an improved patch, could you please add this after your 'Signed-off-by:' (see at (¹) below for the reasoning): Reported-by: Orlando Chamberlain Link: https://lore.kernel.org/r/4970a940-211b-25d6-edab-21a815313954@protonmail.com Fixes: 7c395ea521e6 ("Bluetooth: Query LE tx power on startup") And if the patch is already good to go: could the subsystem maintainer please add it when applying? See (¹) for the reasoning. Ciao, Thorsten, your Linux kernel regression tracker. (¹) Long story: The commit message would benefit from a link to the regression report, for reasons explained in Documentation/process/submitting-patches.rst. To quote: ``` If related discussions or any other background information behind the change can be found on the web, add 'Link:' tags pointing to it. In case your patch fixes a bug, for example, add a tag with a URL referencing the report in the mailing list archives or a bug tracker; ``` This concept is old, but the text was reworked recently to make this use case for the Link: tag clearer. For details see: https://git.kernel.org/linus/1f57bd42b77c Yes, that "Link:" is not really crucial; but it's good to have if someone needs to look into the backstory of this change sometime in the future. But I care for a different reason. I'm tracking this regression (and others) with regzbot, my Linux kernel regression tracking bot. This bot will notice if a patch with a Link: tag to a tracked regression gets posted and record that, which allowed anyone looking into the regression to quickly gasp the current status from regzbot's webui (https://linux-regtracking.leemhuis.info/regzbot ) or its reports. The bot will also notice if a commit with a Link: tag to a regression report is applied by Linus and then automatically mark the regression as resolved then. IOW: this tag makes my life a regression tracker a lot easier, as I otherwise have to tell regzbot manually when the fix lands. :-/ P.S.: As a Linux kernel regression tracker I'm getting a lot of reports on my table. I can only look briefly into most of them. Unfortunately therefore I sometimes will get things wrong or miss something important. I hope that's not the case here; if you think it is, don't hesitate to tell me about it in a public reply. That's in everyone's interest, as what I wrote above might be misleading to everyone reading this; any suggestion I gave they thus might sent someone reading this down the wrong rabbit hole, which none of us wants. BTW, I have no personal interest in this issue, which is tracked using regzbot, my Linux kernel regression tracking bot (https://linux-regtracking.leemhuis.info/regzbot/). I'm only posting this mail to get things rolling again and hence don't need to be CC on all further activities wrt to this regression.