Received-SPF: pass (google.com: best guess record for domain of linux-bluetooth-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
Content-Type: text/plain;
        charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.60.0.2.5\))
Subject: Re: [PATCH] Bluetooth: Do not cancel advertising when starting a scan
From:   Marcel Holtmann <marcel@holtmann.org>
In-Reply-To: <CAO1O6sdfdVavo9U0UKewbS9YAjCVzdXDYms-OJZNEJVzMmkgMg@mail.gmail.com>
Date:   Wed, 18 Mar 2020 12:54:54 +0100
Cc:     Manish Mandlik <mmandlik@google.com>,
        Yoni Shavit <yshavit@chromium.org>,
        Alain Michaud <alainm@chromium.org>,
        Miao-chen Chou <mcchou@chromium.org>,
        Bluez mailing list <linux-bluetooth@vger.kernel.org>,
        Dmitry Grinberg <dmitrygr@google.com>,
        "David S. Miller" <davem@davemloft.net>,
        Johan Hedberg <johan.hedberg@gmail.com>,
        Network Development <netdev@vger.kernel.org>,
        LKML <linux-kernel@vger.kernel.org>,
        Jakub Kicinski <kuba@kernel.org>
Content-Transfer-Encoding: 8BIT
Message-Id: <F5E108DF-2004-4C52-8A5B-12A392D2416D@holtmann.org>
References: <20200316224023.1.I002569822232363cfbb5af1f33a293ea390c24c7@changeid>
 <4DF7C709-1AD3-42FF-A0C2-EF488D82F083@holtmann.org>
 <CAO1O6sdfdVavo9U0UKewbS9YAjCVzdXDYms-OJZNEJVzMmkgMg@mail.gmail.com>
To:     Emil Lenngren <emil.lenngren@gmail.com>
Sender: linux-bluetooth-owner@vger.kernel.org
Precedence: bulk

Hi Emil,

>>> BlueZ cancels adv when starting a scan, but does not cancel a scan when
>>> starting to adv. Neither is required, so this brings both to a
>>> consistent state (of not affecting each other). Some very rare (I've
>>> never seen one) BT 4.0 chips will fail to do both at once. Even this is
>>> ok since the command that will fail will be the second one, and thus the
>>> common sense logic of first-come-first-served is preserved for BLE
>>> requests.
>>> 
>>> Signed-off-by: Dmitry Grinberg <dmitrygr@google.com>
>>> Signed-off-by: Manish Mandlik <mmandlik@google.com>
>>> ---
>>> 
>>> net/bluetooth/hci_request.c | 17 -----------------
>>> 1 file changed, 17 deletions(-)
>> 
>> patch has been applied to bluetooth-next tree.
>> 
>> If you know the controller that doesn’t support this, can we blacklist that one and just disable advertising (peripheral mode) for that controller.
> 
> Can't the "LE Supported States" be inspected instead to figure out
> what simultaneous capabilities are supported? It seems a bit rough to
> always assume the worst.

if there are not false-positives, then yes, by all means. However my statement still applies. If a controller can do scanning and advertising at the same time, we should just not indicate support for peripheral mode.

Regards

Marcel