From: Gustavo Padovan <padovan@profusion.mobi>
To: Andre Guedes <andre.guedes@openbossa.org>
Cc: linux-bluetooth@vger.kernel.org
Subject: Re: [PATCH 08/16] Bluetooth: Fix stop_discovery()
Date: Fri, 22 Jul 2011 12:24:59 -0300 [thread overview]
Message-ID: <20110722152459.GA2650@joana> (raw)
In-Reply-To: <CACJA=fUXQ_QgLCr-TURFOr-2aWva8_gCpPfYC1g=oX099V-stQ@mail.gmail.com>
* Andre Guedes <andre.guedes@openbossa.org> [2011-07-14 11:31:01 -0300]:
> Hi Gustavo,
>
> On Wed, Jul 13, 2011 at 5:15 PM, Gustavo Padovan <padovan@profusion.mobi> wrote:
> >> @@ -963,6 +963,11 @@ static inline void hci_cs_inquiry(struct hci_dev *hdev, __u8 status)
> >>
> >> set_bit(HCI_INQUIRY, &hdev->flags);
> >>
> >> + if (mgmt_has_pending_stop_discov(hdev->id)) {
> >
> > Isn't a new bit flag log HCI_INQUIRY_CANCEL better that this? First this has
> > read a list, second it is a really ugly function name.
>
> A flag called HCI_CANCEL_DISCOV would be more appropriated since it
> would be used to cancel the discovery procedure (inquiry/le scan).
Let it be HCI_CANCEL_DISCOV then.
>
> My point is: I don't need a new flag to tell me the same information I already
> have by checking for pending stop discovery command. IMO, traversing the
> pending command list is not a issue today since it isn't that large.
> If that list
> becomes too large in future, then we'll have a bigger issue because lots of
> mgmt commands do traversing the command pending list. In that case we
> would need to come up with some optimization like pending list per hdev,
> for instance.
>
> Besides, I don't think mixing up mgmt layer and hci layer logic is a good
> idea. The whole discovery procedure logic should go in mgmt layer, so no
> discovery logic should be implemented in hci layer.
>
> >> + mgmt_cancel_discovery(hdev->id);
> >
> > Just call hci_send_cmd(HCI_OP_INQUIRY_CANCEL)
>
> It would mix up mgmt and hci layer logic.
No, the only thing mgmt_cancel_discovery does is call hci_send_cmd. So what
you want is do the same thing but with some more functions in your call chain.
Gustavo
next prev parent reply other threads:[~2011-07-22 15:24 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-07-11 21:11 [PATCH 00/16] Full support discovery procedure Andre Guedes
2011-07-11 21:11 ` [PATCH 01/16] Bluetooth: Periodic Inquiry and mgmt discovering event Andre Guedes
2011-07-13 20:21 ` Gustavo Padovan
2011-07-14 14:28 ` Andre Guedes
2011-07-11 21:11 ` [PATCH 02/16] Bluetooth: Add failed/complete functions to discovery commands Andre Guedes
2011-07-11 21:11 ` [PATCH 03/16] Bluetooth: Remove pending " Andre Guedes
2011-07-11 21:11 ` [PATCH 04/16] Bluetooth: Check pending command in start_discovery() Andre Guedes
2011-07-11 21:11 ` [PATCH 05/16] Bluetooth: Check pending commands in stop_discovery() Andre Guedes
2011-07-13 20:20 ` Gustavo Padovan
2011-07-14 14:29 ` Andre Guedes
2011-07-11 21:11 ` [PATCH 06/16] Bluetooth: Create do_inquiry() Andre Guedes
2011-07-11 21:11 ` [PATCH 07/16] Bluetooth: Create cancel_inquiry() Andre Guedes
2011-07-11 21:11 ` [PATCH 08/16] Bluetooth: Fix stop_discovery() Andre Guedes
2011-07-13 20:15 ` Gustavo Padovan
2011-07-14 14:31 ` Andre Guedes
2011-07-22 15:24 ` Gustavo Padovan [this message]
2011-07-11 21:11 ` [PATCH 09/16] Bluetooth: Prepare for full support discovery procedures Andre Guedes
2011-07-13 20:26 ` Gustavo Padovan
2011-07-14 14:31 ` Andre Guedes
2011-07-11 21:11 ` [PATCH 10/16] Bluetooth: Check 'dev_class' in mgmt_device_found() Andre Guedes
2011-07-11 21:11 ` [PATCH 11/16] Bluetooth: Add 'eir_len' param to mgmt_device_found() Andre Guedes
2011-07-11 21:11 ` [PATCH 12/16] Bluetooth: Report LE devices Andre Guedes
2011-07-11 21:11 ` [PATCH 13/16] Bluetooth: Add 'le_scan_timer' to struct hci_dev Andre Guedes
2011-07-11 21:11 ` [PATCH 14/16] Bluetooth: Add LE Scan helper functions Andre Guedes
2011-07-11 21:11 ` [PATCH 15/16] Bluetooth: Support LE-Only discovery procedure Andre Guedes
2011-07-11 21:11 ` [PATCH 16/16] Bluetooth: Support BR/EDR/LE " 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=20110722152459.GA2650@joana \
--to=padovan@profusion.mobi \
--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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.