From: Marcel Holtmann <marcel@holtmann.org>
To: Johan Hedberg <johan.hedberg@gmail.com>
Cc: "bluez mailin list (linux-bluetooth@vger.kernel.org)"
<linux-bluetooth@vger.kernel.org>
Subject: Re: [PATCH v2] Bluetooth: Fix advertising address type when toggling connectable
Date: Tue, 25 Feb 2014 09:48:01 -0800 [thread overview]
Message-ID: <1700F292-DB01-4DA1-AF5D-445535741ACA@holtmann.org> (raw)
In-Reply-To: <1393349802-5831-1-git-send-email-johan.hedberg@gmail.com>
Hi Johan,
> When the connectable setting is toggled using mgmt_set_connectable the
> HCI_CONNECTABLE flag will only be set once the related HCI commands
> succeed. When determining what kind of advertising to do we need to
> therefore also check whether there is a pending Set Connectable command
> in addition to the current flag value.
>
> The enable_advertising function was already taking care of this for the
> advertising type with the help of the get_adv_type function, but was
> failing to do the same for the address type selection. This patch
> converts the get_adv_type function to be more generic in that it returns
> the expected connectable state and updates the enable_advertising
> function to use the return value both for the advertising type as well
> as the advertising address type.
>
> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
> ---
> net/bluetooth/mgmt.c | 21 +++++++++++----------
> 1 file changed, 11 insertions(+), 10 deletions(-)
>
> diff --git a/net/bluetooth/mgmt.c b/net/bluetooth/mgmt.c
> index 25b8b278debd..16782b5860c5 100644
> --- a/net/bluetooth/mgmt.c
> +++ b/net/bluetooth/mgmt.c
> @@ -817,10 +817,9 @@ static void update_class(struct hci_request *req)
> hci_req_add(req, HCI_OP_WRITE_CLASS_OF_DEV, sizeof(cod), cod);
> }
>
> -static u8 get_adv_type(struct hci_dev *hdev)
> +static bool get_connectable(struct hci_dev *hdev)
> {
> struct pending_cmd *cmd;
> - bool connectable;
>
> /* If there's a pending mgmt command the flag will not yet have
> * it's final value, so check for this first.
> @@ -828,12 +827,10 @@ static u8 get_adv_type(struct hci_dev *hdev)
> cmd = mgmt_pending_find(MGMT_OP_SET_CONNECTABLE, hdev);
> if (cmd) {
> struct mgmt_mode *cp = cmd->param;
> - connectable = !!cp->val;
> - } else {
> - connectable = test_bit(HCI_CONNECTABLE, &hdev->dev_flags);
> + return cp->val;
> }
>
> - return connectable ? LE_ADV_IND : LE_ADV_NONCONN_IND;
> + return test_bit(HCI_CONNECTABLE, &hdev->dev_flags);
> }
>
> static void enable_advertising(struct hci_request *req)
> @@ -841,17 +838,21 @@ static void enable_advertising(struct hci_request *req)
> struct hci_dev *hdev = req->hdev;
> struct hci_cp_le_set_adv_param cp;
> u8 own_addr_type, enable = 0x01;
> - bool require_privacy;
> + bool connectable;
>
> - require_privacy = !test_bit(HCI_CONNECTABLE, &hdev->dev_flags);
> + connectable = get_connectable(hdev);
>
> - if (hci_update_random_address(req, require_privacy, &own_addr_type) < 0)
> + /* If we're connectable set require_privacy to false as we
> + * shouldn't use NRPAs in that case. If we're non-connectable
> + * however we can allow NRPAs to be used.
> + */
> + if (hci_update_random_address(req, !connectable, &own_addr_type) < 0)
> return;
I really do not want to be pedantic, but this comment is misleading. It is a bit hard to understand. Also I am not sure if it NRPA or URPA. I think using an acronym here is confusing.
/* Set require_privacy to true only when non-connectable advertising
* is used. In that case it is fine to use an unresolvable private
* address.
*/
Regards
Marcel
next prev parent reply other threads:[~2014-02-25 17:48 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-02-25 17:36 [PATCH v2] Bluetooth: Fix advertising address type when toggling connectable johan.hedberg
2014-02-25 17:48 ` Marcel Holtmann [this message]
2014-02-25 17:56 ` Johan Hedberg
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=1700F292-DB01-4DA1-AF5D-445535741ACA@holtmann.org \
--to=marcel@holtmann.org \
--cc=johan.hedberg@gmail.com \
--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