2007-12-11 08:17:01

by Ohad Ben-Cohen

[permalink] [raw]
Subject: [PATCH][RESUBMIT] TI's BRF chips: always send explicit wake-up acks

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 <[email protected]>

---

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


2007-12-19 11:24:42

by Ohad Ben-Cohen

[permalink] [raw]
Subject: [PATCH 2.6.24][RERESEND] TI's BRF chips: always send explicit wake-up acks

Still got no response, so I send the patch the third time (now attached).

Marcel - is there a problem with it ?


On 12/11/07, Ohad Ben-Cohen <[email protected]> wrote:
> 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 <[email protected]>
>
> ---
>
> 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
>
>
>
>


Attachments:
(No filename) (2.92 kB)
to-marcel (1.90 kB)
Download all attachments