From: Ohad Ben-Cohen <ohad@bencohen.org>
To: Marcel Holtmann <marcel@holtmann.org>
Cc: BlueZ development <bluez-devel@lists.sourceforge.net>
Subject: [PATCH][RESUBMIT] TI's BRF chips: always send explicit wake-up acks
Date: Tue, 11 Dec 2007 10:17:01 +0200 (IST) [thread overview]
Message-ID: <tkrat.69449f8105b06085@bencohen.org> (raw)
Hi Marcel,
I have posted this 2.6.24 patch weeks ago but got no response,
and it's already rc5 out there.
This is a small but important fix for the BRF's driver. It has
been tested extensively on both the BRF6350 and the BRF6300.
Please tell me if there's anything I can do to help
processing this patch.
Thanks,
Ohad.
[Bluetooth] TI's BRF chips: always send explicit wake-up acks
In the (rare) event of simultaneous mutual wake up requests,
do send the chip an explicit wake-up ack. This is required
for Texas Instruments's BRF6350 chip.
Signed-off-by: Ohad Ben-Cohen <ohad@bencohen.org>
---
drivers/bluetooth/hci_ll.c | 23 ++++++++++++++---------
1 files changed, 14 insertions(+), 9 deletions(-)
diff --git a/drivers/bluetooth/hci_ll.c b/drivers/bluetooth/hci_ll.c
index 8c3e62a..b91d45a 100644
--- a/drivers/bluetooth/hci_ll.c
+++ b/drivers/bluetooth/hci_ll.c
@@ -204,6 +204,19 @@ static void ll_device_want_to_wakeup(struct hci_uart *hu)
spin_lock_irqsave(&ll->hcill_lock, flags);
switch (ll->hcill_state) {
+ case HCILL_ASLEEP_TO_AWAKE:
+ /*
+ * This state means that both the host and the BRF chip
+ * have simultaneously sent a wake-up-indication packet.
+ * Traditionaly, in this case, receiving a wake-up-indication
+ * was enough and an additional wake-up-ack wasn't needed.
+ * This has changed with the BRF6350, which does require an
+ * explicit wake-up-ack. Other BRF versions, which do not
+ * require an explicit ack here, do accept it, thus it is
+ * perfectly safe to always send one.
+ */
+ BT_DBG("dual wake-up-indication");
+ /* deliberate fall-through - do not add break */
case HCILL_ASLEEP:
/* acknowledge device wake up */
if (send_hcill_cmd(HCILL_WAKE_UP_ACK, hu) < 0) {
@@ -211,16 +224,8 @@ static void ll_device_want_to_wakeup(struct hci_uart *hu)
goto out;
}
break;
- case HCILL_ASLEEP_TO_AWAKE:
- /*
- * this state means that a wake-up-indication
- * is already on its way to the device,
- * and will serve as the required wake-up-ack
- */
- BT_DBG("dual wake-up-indication");
- break;
default:
- /* any other state are illegal */
+ /* any other state is illegal */
BT_ERR("received HCILL_WAKE_UP_IND in state %ld", ll->hcill_state);
break;
}
--
1.4.4.2
next reply other threads:[~2007-12-11 8:17 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-12-11 8:17 Ohad Ben-Cohen [this message]
2007-12-19 11:24 ` [PATCH 2.6.24][RERESEND] TI's BRF chips: always send explicit wake-up acks Ohad Ben-Cohen
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=tkrat.69449f8105b06085@bencohen.org \
--to=ohad@bencohen.org \
--cc=bluez-devel@lists.sourceforge.net \
--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).