From: Andre Guedes <andre.guedes@openbossa.org>
To: Marcel Holtmann <marcel@holtmann.org>
Cc: "linux-bluetooth@vger.kernel.org development"
<linux-bluetooth@vger.kernel.org>
Subject: Re: [RFC v2 01/15] Bluetooth: Refactor hci_disconn_complete_evt
Date: Mon, 18 Nov 2013 15:40:57 -0300 [thread overview]
Message-ID: <528A5F39.8010303@openbossa.org> (raw)
In-Reply-To: <227F5D6B-6B76-428E-9893-37ED1562F833@holtmann.org>
Hi Marcel,
On 10/29/2013 07:52 PM, Marcel Holtmann wrote:
> Hi Andre,
>
>> hci_disconn_complete_evt() logic is more complicated than what it
>> should be, making it hard to follow and add new features.
>>
>> So this patch does some code refactoring by handling the error cases
>> in the beginning of the function and by moving the main flow into the
>> first level of function scope. No change is done in the event handling
>> logic itself.
>>
>> Besides organizing this messy code, this patch makes easier to add
>> code for handling LE auto connection (which will be added in a further
>> patch).
>>
>> Signed-off-by: Andre Guedes <andre.guedes@openbossa.org>
>> ---
>> net/bluetooth/hci_event.c | 62 +++++++++++++++++++++++++----------------------
>> 1 file changed, 33 insertions(+), 29 deletions(-)
>>
>> diff --git a/net/bluetooth/hci_event.c b/net/bluetooth/hci_event.c
>> index 5935f74..8b7cd37 100644
>> --- a/net/bluetooth/hci_event.c
>> +++ b/net/bluetooth/hci_event.c
>> @@ -1783,6 +1783,8 @@ static void hci_disconn_complete_evt(struct hci_dev *hdev, struct sk_buff *skb)
>> {
>> struct hci_ev_disconn_complete *ev = (void *) skb->data;
>> struct hci_conn *conn;
>> + u8 type;
>> + bool send_mgmt_event = false;
>>
>> BT_DBG("%s status 0x%2.2x", hdev->name, ev->status);
>>
>> @@ -1792,44 +1794,46 @@ static void hci_disconn_complete_evt(struct hci_dev *hdev, struct sk_buff *skb)
>> if (!conn)
>> goto unlock;
>>
>> - if (ev->status == 0)
>> - conn->state = BT_CLOSED;
>> -
>> if (test_and_clear_bit(HCI_CONN_MGMT_CONNECTED, &conn->flags) &&
>> - (conn->type == ACL_LINK || conn->type == LE_LINK)) {
>> - if (ev->status) {
>> + (conn->type == ACL_LINK || conn->type == LE_LINK))
>> + send_mgmt_event = true;
>> +
>> + if (ev->status) {
>> + if (send_mgmt_event)
>> mgmt_disconnect_failed(hdev, &conn->dst, conn->type,
>> conn->dst_type, ev->status);
>> - } else {
>> - u8 reason = hci_to_mgmt_reason(ev->reason);
>> -
>> - mgmt_device_disconnected(hdev, &conn->dst, conn->type,
>> - conn->dst_type, reason);
>> - }
>> + return;
>> }
>
> so I get the feeling that mgmt_disconnect_failed should check the link type all by itself. Since we are handing it over to the function anyway. And then this send_mgmt_event could be just removed.
>
>> - if (ev->status == 0) {
>> - u8 type = conn->type;
>> + conn->state = BT_CLOSED;
>>
>> - if (type == ACL_LINK && conn->flush_key)
>> - hci_remove_link_key(hdev, &conn->dst);
>> - hci_proto_disconn_cfm(conn, ev->reason);
>> - hci_conn_del(conn);
>> + if (send_mgmt_event) {
>> + u8 reason = hci_to_mgmt_reason(ev->reason);
>>
>> - /* Re-enable advertising if necessary, since it might
>> - * have been disabled by the connection. From the
>> - * HCI_LE_Set_Advertise_Enable command description in
>> - * the core specification (v4.0):
>> - * "The Controller shall continue advertising until the Host
>> - * issues an LE_Set_Advertise_Enable command with
>> - * Advertising_Enable set to 0x00 (Advertising is disabled)
>> - * or until a connection is created or until the Advertising
>> - * is timed out due to Directed Advertising."
>> - */
>> - if (type == LE_LINK)
>> - mgmt_reenable_advertising(hdev);
>> + mgmt_device_disconnected(hdev, &conn->dst, conn->type,
>> + conn->dst_type, reason);
>> }
>
> Same here. Just make sure that mgmt_device_disconneted checks the link type by itself and call it unconditional.
>
>>
>> + if (conn->type == ACL_LINK && conn->flush_key)
>> + hci_remove_link_key(hdev, &conn->dst);
>> +
>> + type = conn->type;
>> + hci_proto_disconn_cfm(conn, ev->reason);
>> + hci_conn_del(conn);
>> +
>> + /* Re-enable advertising if necessary, since it might
>> + * have been disabled by the connection. From the
>> + * HCI_LE_Set_Advertise_Enable command description in
>> + * the core specification (v4.0):
>> + * "The Controller shall continue advertising until the Host
>> + * issues an LE_Set_Advertise_Enable command with
>> + * Advertising_Enable set to 0x00 (Advertising is disabled)
>> + * or until a connection is created or until the Advertising
>> + * is timed out due to Directed Advertising."
>> + */
>> + if (type == LE_LINK)
>> + mgmt_reenable_advertising(hdev);
>> +
>> unlock:
>> hci_dev_unlock(hdev);
>> }
These comments were implemented in the patch set "[RFC 0/5] Disconnect
complete refactoring". That patch set is already pushed upstream.
I'm currently working on a new version of this patch set. All your other
comments will be addressed in v3.
Thanks,
Andre
next prev parent reply other threads:[~2013-11-18 18:40 UTC|newest]
Thread overview: 31+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-10-29 13:25 [RFC v2 00/15] LE auto connection and connection parameters Andre Guedes
2013-10-29 13:25 ` [RFC v2 01/15] Bluetooth: Refactor hci_disconn_complete_evt Andre Guedes
2013-10-29 22:52 ` Marcel Holtmann
2013-11-18 18:40 ` Andre Guedes [this message]
2013-10-29 13:25 ` [RFC v2 02/15] Bluetooth: Save connection interval parameters in hci_conn Andre Guedes
2013-10-29 22:55 ` Marcel Holtmann
2013-10-29 13:25 ` [RFC v2 03/15] Bluetooth: Stop scanning on connection Andre Guedes
2013-10-29 22:58 ` Marcel Holtmann
2013-10-29 13:25 ` [RFC v2 04/15] Bluetooth: Introduce connection parameters list Andre Guedes
2013-10-29 23:03 ` Marcel Holtmann
2013-10-29 13:25 ` [RFC v2 05/15] Bluetooth: Make find_conn_param() helper non-local Andre Guedes
2013-10-29 23:33 ` Marcel Holtmann
2013-10-29 13:25 ` [RFC v2 06/15] Bluetooth: Use connection parameters if any Andre Guedes
2013-10-29 23:04 ` Marcel Holtmann
2013-10-29 13:25 ` [RFC v2 07/15] Bluetooth: Introduce hdev->pending_auto_conn list Andre Guedes
2013-10-29 23:08 ` Marcel Holtmann
2013-10-29 13:25 ` [RFC v2 08/15] Bluetooth: Move is_scan_and_conn_supported() to hci_core Andre Guedes
2013-10-29 23:09 ` Marcel Holtmann
2013-10-29 13:25 ` [RFC v2 09/15] Bluetooth: Introduce LE auto connection infrastructure Andre Guedes
2013-10-29 23:30 ` Marcel Holtmann
2013-10-29 13:25 ` [RFC v2 10/15] Bluetooth: Temporarily stop background scanning on discovery Andre Guedes
2013-10-29 23:19 ` Marcel Holtmann
2013-11-18 18:40 ` Andre Guedes
2013-10-29 13:25 ` [RFC v2 11/15] Bluetooth: Auto connection and power on Andre Guedes
2013-10-29 23:13 ` Marcel Holtmann
2013-10-29 13:25 ` [RFC v2 12/15] Bleutooth: Add support for auto connect options Andre Guedes
2013-10-29 23:15 ` Marcel Holtmann
2013-10-29 13:25 ` [RFC v2 13/15] Bluetooth: Add thread-safe version of helpers Andre Guedes
2013-10-29 23:16 ` Marcel Holtmann
2013-10-29 13:25 ` [RFC v2 14/15] Bluetooth: Mgmt command for adding connection parameters Andre Guedes
2013-10-29 13:26 ` [RFC v2 15/15] Bluetooth: Mgmt command for removing " 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=528A5F39.8010303@openbossa.org \
--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 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.