Linux bluetooth development
 help / color / mirror / Atom feed
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

  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