linux-bluetooth.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Andre Guedes <andre.guedes@openbossa.org>
To: Marcel Holtmann <marcel@holtmann.org>
Cc: BlueZ development <linux-bluetooth@vger.kernel.org>
Subject: Re: [RFC v7 08/11] Bluetooth: Temporarily stop background scanning on discovery
Date: Tue, 04 Feb 2014 15:33:12 -0300	[thread overview]
Message-ID: <1391538792.26488.40.camel@bali> (raw)
In-Reply-To: <9BB5F5F9-6828-491B-B918-B0909BCA2408@holtmann.org>


Hi Marcel,

On Mon, 2014-02-03 at 20:25 -0800, Marcel Holtmann wrote:
> Hi Andre,
> 
> > If the user sends a mgmt start discovery command while the background
> > scanning is running, we should temporarily stop it. Once the discovery
> > finishes, we start the background scanning again.
> > 
> > Signed-off-by: Andre Guedes <andre.guedes@openbossa.org>
> > ---
> > net/bluetooth/hci_core.c |  2 ++
> > net/bluetooth/mgmt.c     | 12 ++++++++----
> > 2 files changed, 10 insertions(+), 4 deletions(-)
> > 
> > diff --git a/net/bluetooth/hci_core.c b/net/bluetooth/hci_core.c
> > index 388a453..222bd07 100644
> > --- a/net/bluetooth/hci_core.c
> > +++ b/net/bluetooth/hci_core.c
> > @@ -1609,6 +1609,8 @@ void hci_discovery_set_state(struct hci_dev *hdev, int state)
> > 
> > 	switch (state) {
> > 	case DISCOVERY_STOPPED:
> > +		hci_update_background_scan(hdev);
> > +
> > 		if (hdev->discovery.state != DISCOVERY_STARTING)
> > 			mgmt_discovering(hdev, 0);
> > 		break;
> > diff --git a/net/bluetooth/mgmt.c b/net/bluetooth/mgmt.c
> > index ce7ef33..83af8de 100644
> > --- a/net/bluetooth/mgmt.c
> > +++ b/net/bluetooth/mgmt.c
> > @@ -3319,11 +3319,15 @@ static int start_discovery(struct sock *sk, struct hci_dev *hdev,
> > 			goto failed;
> > 		}
> > 
> > +		/* If controller is scanning, it means the background scanning
> > +		 * is running. Thus, we should temporarily stop it in order to
> > +		 * set the discovery scanning parameters.
> > +		 */
> > 		if (test_bit(HCI_LE_SCAN, &hdev->dev_flags)) {
> > -			err = cmd_status(sk, hdev->id, MGMT_OP_START_DISCOVERY,
> > -					 MGMT_STATUS_BUSY);
> > -			mgmt_pending_remove(cmd);
> > -			goto failed;
> > +			memset(&enable_cp, 0, sizeof(enable_cp));
> > +			enable_cp.enable = LE_SCAN_DISABLE;
> > +			hci_req_add(&req, HCI_OP_LE_SET_SCAN_ENABLE,
> > +				    sizeof(enable_cp), &enable_cp);
> > 		}
> 
> is the start_discovery protected enough by itself so that we do not accidentally stop some discovery that got triggered which is actually not a background scan.

A few lines above (the diff doesn't show it), we check the discovery
state, ensuring the discovery is not running at this point.

BR,

Andre

  reply	other threads:[~2014-02-04 18:33 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-02-03 16:56 [RFC v7 01/11] Bluetooth: Introduce connection parameters list Andre Guedes
2014-02-03 16:56 ` [RFC v7 02/11] Bluetooth: Use connection parameters if any Andre Guedes
2014-02-04  4:02   ` Marcel Holtmann
2014-02-03 16:56 ` [RFC v7 03/11] Bluetooth: Stop scanning on LE connection Andre Guedes
2014-02-04  4:08   ` Marcel Holtmann
2014-02-04 18:32     ` Andre Guedes
2014-02-03 16:56 ` [RFC v7 04/11] Bluetooth: Remove unused function Andre Guedes
2014-02-03 16:56 ` [RFC v7 05/11] Bluetooth: Introduce hdev->pend_le_conn list Andre Guedes
2014-02-03 16:56 ` [RFC v7 06/11] Bluetooth: Introduce LE auto connection infrastructure Andre Guedes
2014-02-03 16:56 ` [RFC v7 07/11] Bluetooth: Re-enable background scan in case of error Andre Guedes
2014-02-04  4:10   ` Marcel Holtmann
2014-02-04 18:32     ` Andre Guedes
2014-02-03 16:56 ` [RFC v7 08/11] Bluetooth: Temporarily stop background scanning on discovery Andre Guedes
2014-02-04  4:25   ` Marcel Holtmann
2014-02-04 18:33     ` Andre Guedes [this message]
2014-02-03 16:56 ` [RFC v7 09/11] Bluetooth: Introduce LE auto connect options Andre Guedes
2014-02-03 16:56 ` [RFC v7 10/11] Bluetooth: Auto connection and power on Andre Guedes
2014-02-03 16:56 ` [RFC v7 11/11] Bluetooth: Add le_auto_conn file on debugfs Andre Guedes

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1391538792.26488.40.camel@bali \
    --to=andre.guedes@openbossa.org \
    --cc=linux-bluetooth@vger.kernel.org \
    --cc=marcel@holtmann.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).