From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-13.8 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_CR_TRAILER,INCLUDES_PATCH, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 89334C43381 for ; Thu, 4 Mar 2021 00:08:47 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 6214564F8A for ; Thu, 4 Mar 2021 00:08:47 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1354003AbhCDAG2 (ORCPT ); Wed, 3 Mar 2021 19:06:28 -0500 Received: from coyote.holtmann.net ([212.227.132.17]:40213 "EHLO mail.holtmann.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1388526AbhCCVKt (ORCPT ); Wed, 3 Mar 2021 16:10:49 -0500 Received: from marcel-macbook.holtmann.net (p4ff9fb90.dip0.t-ipconnect.de [79.249.251.144]) by mail.holtmann.org (Postfix) with ESMTPSA id 58E05CED0A; Wed, 3 Mar 2021 22:17:37 +0100 (CET) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.60.0.2.21\)) Subject: Re: [PATCH] Bluetooth: Allow scannable adv with extended MGMT APIs From: Marcel Holtmann In-Reply-To: <20210303111505.1.I3108b046a478cb4f1b85aeb84edb0f127cff81a8@changeid> Date: Wed, 3 Mar 2021 22:10:02 +0100 Cc: Bluetooth Kernel Mailing List , CrosBT Upstreaming , Alain Michaud , Sonny Sasaka , Miao-chen Chou , "David S. Miller" , Jakub Kicinski , Johan Hedberg , Luiz Augusto von Dentz , LKML , netdev@vger.kernel.org Content-Transfer-Encoding: 7bit Message-Id: References: <20210303111505.1.I3108b046a478cb4f1b85aeb84edb0f127cff81a8@changeid> To: Daniel Winkler X-Mailer: Apple Mail (2.3654.60.0.2.21) Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Daniel, > An issue was found, where if a bluetooth client requests a broadcast > advertisement with scan response data, it will not be properly > registered with the controller. This is because at the time that the > hci_cp_le_set_scan_param structure is created, the scan response will > not yet have been received since it comes in a second MGMT call. With > empty scan response, the request defaults to a non-scannable PDU type. > On some controllers, the subsequent scan response request will fail due > to incorrect PDU type, and others will succeed and not use the scan > response. > > This fix allows the advertising parameters MGMT call to include a flag > to let the kernel know whether a scan response will be coming, so that > the correct PDU type is used in the first place. A bluetoothd change is > also incoming to take advantage of it. > > To test this, I created a broadcast advertisement with scan response > data and registered it on the hatch chromebook. Without this change, the > request fails, and with it will succeed. > > Reviewed-by: Alain Michaud > Reviewed-by: Sonny Sasaka > Reviewed-by: Miao-chen Chou > Signed-off-by: Daniel Winkler > --- > > include/net/bluetooth/mgmt.h | 1 + > net/bluetooth/hci_request.c | 3 ++- > net/bluetooth/mgmt.c | 1 + > 3 files changed, 4 insertions(+), 1 deletion(-) patch has been applied to bluetooth-next tree. Regards Marcel