Linux bluetooth development
 help / color / mirror / Atom feed
From: Marcel Holtmann <marcel@holtmann.org>
To: Andre Guedes <andre.guedes@openbossa.org>
Cc: linux-bluetooth@vger.kernel.org
Subject: Re: [PATCH 6/6] Bluetooth: Support LE-Only discovery procedure
Date: Thu, 17 Nov 2011 06:45:38 +0900	[thread overview]
Message-ID: <1321479940.15441.550.camel@aeonflux> (raw)
In-Reply-To: <A37EF08F-5B90-43F3-AA5B-BE0FD282E3D7@openbossa.org>

Hi Andre,

> >> Signed-off-by: Andre Guedes <andre.guedes@openbossa.org>
> >> ---
> >> include/net/bluetooth/hci.h      |    1 +
> >> include/net/bluetooth/hci_core.h |    1 +
> >> net/bluetooth/hci_event.c        |   25 ++++++++++++++++++++++---
> >> net/bluetooth/mgmt.c             |   25 +++++++++++++++++++++++--
> >> 4 files changed, 47 insertions(+), 5 deletions(-)
> >> 
> >> diff --git a/include/net/bluetooth/hci.h b/include/net/bluetooth/hci.h
> >> index bd3cecd..ca09998 100644
> >> --- a/include/net/bluetooth/hci.h
> >> +++ b/include/net/bluetooth/hci.h
> >> @@ -210,6 +210,7 @@ enum {
> >> 
> >> #define LMP_EV4		0x01
> >> #define LMP_EV5		0x02
> >> +#define LMP_NO_BREDR	0x20
> >> #define LMP_LE		0x40
> >> 
> >> #define LMP_SNIFF_SUBR	0x02
> >> diff --git a/include/net/bluetooth/hci_core.h b/include/net/bluetooth/hci_core.h
> >> index 9da5b69..55b78ec 100644
> >> --- a/include/net/bluetooth/hci_core.h
> >> +++ b/include/net/bluetooth/hci_core.h
> >> @@ -678,6 +678,7 @@ void hci_conn_del_sysfs(struct hci_conn *conn);
> >> #define lmp_ssp_capable(dev)       ((dev)->features[6] & LMP_SIMPLE_PAIR)
> >> #define lmp_no_flush_capable(dev)  ((dev)->features[6] & LMP_NO_FLUSH)
> >> #define lmp_le_capable(dev)        ((dev)->features[4] & LMP_LE)
> >> +#define lmp_bredr_capable(dev)     (!((dev)->features[4] & LMP_NO_BREDR))
> > 
> > can you just split this into a separate patch first. We can just go
> > ahead and merge it.
> > 
> >> /* ----- Extended LMP capabilities ----- */
> >> #define lmp_host_le_capable(dev)   ((dev)->extfeatures[0] & LMP_HOST_LE)
> >> diff --git a/net/bluetooth/hci_event.c b/net/bluetooth/hci_event.c
> >> index dcbbffe..037c7c0 100644
> >> --- a/net/bluetooth/hci_event.c
> >> +++ b/net/bluetooth/hci_event.c
> >> @@ -954,24 +954,43 @@ static void hci_cc_le_set_scan_enable(struct hci_dev *hdev,
> >> 
> >> 	BT_DBG("%s status 0x%x", hdev->name, status);
> >> 
> >> -	if (status)
> >> -		return;
> >> -
> >> 	cp = hci_sent_cmd_data(hdev, HCI_OP_LE_SET_SCAN_ENABLE);
> >> 	if (!cp)
> >> 		return;
> >> 
> >> 	if (cp->enable == 0x01) {
> >> +		if (status) {
> >> +			hci_dev_lock(hdev);
> >> +			mgmt_start_discovery_failed(hdev, status);
> >> +			hci_dev_unlock(hdev);
> >> +			return;
> >> +		}
> >> +
> >> 		set_bit(HCI_LE_SCAN, &hdev->hci_flags);
> >> 
> >> 		del_timer(&hdev->adv_timer);
> >> 
> >> 		hci_dev_lock(hdev);
> >> +
> >> +		mgmt_discovering(hdev, 1);
> >> +
> >> 		hci_adv_entries_clear(hdev);
> >> +
> >> 		hci_dev_unlock(hdev);
> >> 	} else if (cp->enable == 0x00) {
> >> +		if (status) {
> >> +			hci_dev_lock(hdev);
> >> +			mgmt_stop_discovery_failed(hdev, status);
> >> +			hci_dev_unlock(hdev);
> >> +			return;
> >> +		}
> >> +
> >> 		clear_bit(HCI_LE_SCAN, &hdev->hci_flags);
> >> 
> >> +		hci_dev_lock(hdev);
> >> +		mgmt_discovering(hdev, 0);
> >> +		hci_dev_unlock(hdev);
> >> +
> >> 		mod_timer(&hdev->adv_timer, jiffies + ADV_CLEAR_TIMEOUT);
> >> 	}
> >> }
> > 
> > This part looks fine to me.
> > 
> >> diff --git a/net/bluetooth/mgmt.c b/net/bluetooth/mgmt.c
> >> index b63a7d0..6ca6e5d 100644
> >> --- a/net/bluetooth/mgmt.c
> >> +++ b/net/bluetooth/mgmt.c
> >> @@ -32,7 +32,16 @@
> >> #define MGMT_VERSION	0
> >> #define MGMT_REVISION	1
> >> 
> >> -#define INQUIRY_LEN_BREDR 0x08 /* TGAP(100) */
> >> +/*
> >> + * These LE scan and inquiry parameters were chosen according to LE General
> >> + * Discovery Procedure specification.
> >> + */
> >> +#define LE_SCAN_TYPE 0x01
> >> +#define LE_SCAN_WIN 0x12
> >> +#define LE_SCAN_INT 0x12
> >> +#define LE_SCAN_TIMEOUT_LE_ONLY 10240		/* TGAP(gen_disc_scan_min) */
> >> +
> >> +#define INQUIRY_LEN_BREDR 0x08			/* TGAP(100) */
> >> 
> >> struct pending_cmd {
> >> 	struct list_head list;
> >> @@ -1669,7 +1678,16 @@ static int start_discovery(struct sock *sk, u16 index)
> >> 		goto failed;
> >> 	}
> >> 
> >> -	err = hci_do_inquiry(hdev, INQUIRY_LEN_BREDR);
> >> +	if (lmp_host_le_capable(hdev)) {
> >> +		if (lmp_bredr_capable(hdev))
> >> +			err = -ENOSYS;
> >> +		else
> >> +			err = hci_do_le_scan(hdev, LE_SCAN_TYPE, LE_SCAN_INT,
> >> +					LE_SCAN_WIN, LE_SCAN_TIMEOUT_LE_ONLY);
> >> +	} else {
> >> +		err = hci_do_inquiry(hdev, INQUIRY_LEN_BREDR);
> >> +	}
> >> +
> >> 	if (err < 0)
> >> 		mgmt_pending_remove(cmd);
> >> 
> >> @@ -1701,6 +1719,9 @@ static int stop_discovery(struct sock *sk, u16 index)
> >> 	}
> >> 
> >> 	err = hci_cancel_inquiry(hdev);
> >> +	if (err == -EPERM)
> >> +		err = hci_cancel_le_scan(hdev);
> >> +
> > 
> > And here, I have a serious problem with how the code is done. I realize
> > that from using hdev->flags this ends up this crappy, but this is not
> > how I wanna see things done.
> > 
> > What you are doing is this:
> > 
> > - We call a complete unrelated function anyway
> > - And if it fails with a specific error code then we call something
> >  else instead
> > 
> > I think it becomes pretty obvious now that we should just have had
> > hdev->mgmt_flags that tell us with discovery procedure is running right
> > now. And thus we know how to cancel it.
> 
> I'm not sure this will help us in case we have a interleaved discovery
> running. My point is, even if we know what discovery procedure is running,
> we need to know what the controller is doing right now (inquiring or le
> scanning) so we can properly stop it, and, therefore, stop the ongoing
> discovery procedure. IOW, telling us we have a interleaved discovery
> running does not help us to decide the right function to call
> (hci_cancel_inquiry or hci_cancel_le_scan).
> 
> So, I think we need to check the controller flags (HCI_INQUIRY and
> HCI_LE_SCAN) in order to stop the ongoing discovery procedure properly.

I have nothing against separate flags. That makes fully sense. I have
something against weirdly calling one function and expecting it to error
out. Relying on an error is a bad idea. You want to keep track of what
is currently going on.

Regards

Marcel



  reply	other threads:[~2011-11-16 21:45 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-11-11 22:50 [PATCH 0/6] LE-Only discovery procedure support Andre Guedes
2011-11-11 22:50 ` [PATCH 1/6] Bluetooth: Add hci_flags to struct hci_dev Andre Guedes
2011-11-11 23:09   ` Marcel Holtmann
2011-11-16 17:42     ` Andre Guedes
2011-11-16 21:44       ` Marcel Holtmann
2011-11-16 21:50         ` Andre Guedes
2011-11-11 22:50 ` [PATCH 2/6] Bluetooth: Add LE Set Scan Parameter Command Andre Guedes
2011-11-11 23:10   ` Marcel Holtmann
2011-11-11 22:50 ` [PATCH 3/6] Bluetooth: LE scan infra-structure Andre Guedes
2011-11-11 23:13   ` Marcel Holtmann
2011-11-18 23:04     ` Andre Guedes
2011-11-19  6:11       ` Marcel Holtmann
2011-11-21 17:24         ` Andre Guedes
2011-11-11 22:50 ` [PATCH 4/6] Bluetooth: Add 'eir_len' param to mgmt_device_found() Andre Guedes
2011-11-11 22:50 ` [PATCH 5/6] Bluetooth: Report LE devices Andre Guedes
2011-11-11 23:14   ` Marcel Holtmann
2011-11-23 20:15     ` Vinicius Costa Gomes
2011-11-11 22:50 ` [PATCH 6/6] Bluetooth: Support LE-Only discovery procedure Andre Guedes
2011-11-12  6:43   ` Marcel Holtmann
2011-11-16 20:25     ` Andre Guedes
2011-11-16 21:45       ` Marcel Holtmann [this message]
2011-11-16 22:41         ` Andre Guedes
2011-11-17  0:59           ` Marcel Holtmann
2011-11-12  9:54   ` Johan Hedberg
2011-11-16 21:04     ` Andre Guedes
2011-11-14 10:08   ` Andrei Emeltchenko
2011-11-16 20:36     ` Andre Guedes
2011-11-17  8:59       ` Andrei Emeltchenko
2011-11-17 16:40         ` 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=1321479940.15441.550.camel@aeonflux \
    --to=marcel@holtmann.org \
    --cc=andre.guedes@openbossa.org \
    --cc=linux-bluetooth@vger.kernel.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