From: Ron Shaffer <rshaffer@codeaurora.org>
To: Marcel Holtmann <marcel@holtmann.org>
Cc: linux-bluetooth@vger.kernel.org
Subject: Re: [PATCH v2] Bluetooth: Defer SCO setup if mode change is pending
Date: Fri, 23 Jul 2010 10:39:33 -0500 [thread overview]
Message-ID: <4C49B7B5.9040802@codeaurora.org> (raw)
In-Reply-To: <1279853339.2621.14.camel@localhost.localdomain>
Marcel:
> Hi Ron,
>
>> diff --git a/net/bluetooth/hci_event.c b/net/bluetooth/hci_event.c
>> index 6c57fc7..9aee8c5 100644
>> --- a/net/bluetooth/hci_event.c
>> +++ b/net/bluetooth/hci_event.c
>> @@ -775,9 +775,6 @@ static void hci_cs_sniff_mode(struct hci_dev *hdev, __u8 status)
>>
>> BT_DBG("%s status 0x%x", hdev->name, status);
>>
>> - if (!status)
>> - return;
>> -
>> cp = hci_sent_cmd_data(hdev, HCI_OP_SNIFF_MODE);
>> if (!cp)
>> return;
>> @@ -785,8 +782,15 @@ static void hci_cs_sniff_mode(struct hci_dev *hdev, __u8 status)
>> hci_dev_lock(hdev);
>>
>> conn = hci_conn_hash_lookup_handle(hdev, __le16_to_cpu(cp->handle));
>> - if (conn)
>> - clear_bit(HCI_CONN_MODE_CHANGE_PEND, &conn->pend);
>> + if (conn) {
>> + if (status) {
>> + clear_bit(HCI_CONN_MODE_CHANGE_PEND, &conn->pend);
>> +
>> + if (test_and_clear_bit(HCI_CONN_SCO_SETUP_PEND,
>> + &conn->pend))
>> + hci_sco_setup(conn, status);
>> + }
>> + }
>>
>> hci_dev_unlock(hdev);
>> }
>
> this change now makes it worse, please revert to initial
>
> if (!status)
> return;
>
> check at the top and the just do
>
> if (conn) {
> clear_bit(HCI_CONN_MODE_CHANGE_PEND, &conn->pend);
>
> if (test_and_clear_bit(HCI_CONN_SCO_SETUP_PEND, &conn->pend))
> hci_sco_setup(conn, status);
> }
>
> The only reason why I moved the status check down, because I was not
> thinking straight and overlooked that in case of success we don't wanna
> do a single thing here.
Makes sense. Done.
>
>> @@ -798,9 +802,6 @@ static void hci_cs_exit_sniff_mode(struct hci_dev *hdev, __u8 status)
>>
>> BT_DBG("%s status 0x%x", hdev->name, status);
>>
>> - if (!status)
>> - return;
>> -
>> cp = hci_sent_cmd_data(hdev, HCI_OP_EXIT_SNIFF_MODE);
>> if (!cp)
>> return;
>> @@ -808,8 +809,15 @@ static void hci_cs_exit_sniff_mode(struct hci_dev *hdev, __u8 status)
>> hci_dev_lock(hdev);
>>
>> conn = hci_conn_hash_lookup_handle(hdev, __le16_to_cpu(cp->handle));
>> - if (conn)
>> - clear_bit(HCI_CONN_MODE_CHANGE_PEND, &conn->pend);
>> + if (conn) {
>> + if (status) {
>> + clear_bit(HCI_CONN_MODE_CHANGE_PEND, &conn->pend);
>> +
>> + if (test_and_clear_bit(HCI_CONN_SCO_SETUP_PEND,
>> + &conn->pend))
>> + hci_sco_setup(conn, status);
>> + }
>> + }
>>
>> hci_dev_unlock(hdev);
>> }
>
> Same applies here btw.
Same. Done.
>
>> @@ -915,20 +923,8 @@ static inline void hci_conn_complete_evt(struct hci_dev *hdev, struct sk_buff *s
>> } else
>> conn->state = BT_CLOSED;
>>
>> - if (conn->type == ACL_LINK) {
>> - struct hci_conn *sco = conn->link;
>> - if (sco) {
>> - if (!ev->status) {
>> - if (lmp_esco_capable(hdev))
>> - hci_setup_sync(sco, conn->handle);
>> - else
>> - hci_add_sco(sco, conn->handle);
>> - } else {
>> - hci_proto_connect_cfm(sco, ev->status);
>> - hci_conn_del(sco);
>> - }
>> - }
>> - }
>> + if (conn->type == ACL_LINK)
>> + hci_sco_setup(conn, ev->status);
>>
>> if (ev->status) {
>> hci_proto_connect_cfm(conn, ev->status);
>> @@ -1478,6 +1474,9 @@ static inline void hci_mode_change_evt(struct hci_dev *hdev, struct sk_buff *skb
>> conn->power_save = 1;
>> else
>> conn->power_save = 0;
>> + } else if (test_and_clear_bit(HCI_CONN_SCO_SETUP_PEND,
>> + &conn->pend)) {
>> + hci_sco_setup(conn, ev->status);
>> }
>> }
>
> Please don't do else if here. Just add a separate check like I had in my
> initial patch. We don't wanna depend on two flags pending flags set
> here. If the SCO setup is pending, then we execute it. No matter how we
> reached that point. It is important that even if we receive a mode
> change without us triggering it, that we clear any potential SCO pending
> flag.
Hmmm. I know I found a bug here, but I can't remember how it manifested
itself. Today, I can't reproduce it, so either I was seeing things or
I'm losing it.
I'll revert it back, and if I run across the issue again, we can fix it
later.
--
Ron Shaffer
Employee of the Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.
next prev parent reply other threads:[~2010-07-23 15:39 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-07-19 18:06 [PATCH] Bluetooth: Defer SCO setup if mode change is pending Marcel Holtmann
2010-07-20 4:44 ` Ron Shaffer
2010-07-20 16:56 ` Marcel Holtmann
2010-07-22 19:45 ` [PATCH v2] " Ron Shaffer
2010-07-23 2:48 ` Marcel Holtmann
2010-07-23 15:39 ` Ron Shaffer [this message]
2010-07-25 18:41 ` Marcel Holtmann
2010-07-26 14:06 ` [PATCH v3] " Ron Shaffer
2010-07-27 19:40 ` Marcel Holtmann
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=4C49B7B5.9040802@codeaurora.org \
--to=rshaffer@codeaurora.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;
as well as URLs for NNTP newsgroup(s).