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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox