From: Marcel Holtmann <marcel@holtmann.org>
To: Rajat Jain <rajatja@google.com>
Cc: Johan Hedberg <johan.hedberg@gmail.com>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
"David S. Miller" <davem@davemloft.net>,
Dmitry Torokhov <dtor@chromium.org>,
Alex Hung <alex.hung@canonical.com>,
linux-bluetooth@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-usb@vger.kernel.org, netdev@vger.kernel.org,
rajatxjain@gmail.com, dtor@google.com, raghuram.hegde@intel.com,
chethan.tumkur.narayan@intel.com, sukumar.ghorai@intel.com
Subject: Re: [PATCH v4 3/5] Bluetooth: Reset Bluetooth chip after multiple command timeouts
Date: Sat, 19 Jan 2019 20:51:06 +0100 [thread overview]
Message-ID: <D1490A23-9076-4BAA-A932-CDE1C073475B@holtmann.org> (raw)
In-Reply-To: <20190118223407.64818-3-rajatja@google.com>
Hi Rajat,
> Add a quirk and a hook to allow the HCI core to reset the BT chip
> if needed (after a number of timed out commands). Use that new hook to
> initiate BT chip reset if the controller fails to respond to certain
> number of commands (currently 5) including the HCI reset commands.
> This is done based on a newly introduced quirk. This is done based
> on some initial work by Intel.
>
> Signed-off-by: Rajat Jain <rajatja@google.com>
> ---
> v4: same as v1
> v3: same as v1
> v2: same as v1
>
> include/net/bluetooth/hci.h | 8 ++++++++
> include/net/bluetooth/hci_core.h | 2 ++
> net/bluetooth/hci_core.c | 15 +++++++++++++--
> 3 files changed, 23 insertions(+), 2 deletions(-)
>
> diff --git a/include/net/bluetooth/hci.h b/include/net/bluetooth/hci.h
> index c36dc1e20556..af02fa5ffe54 100644
> --- a/include/net/bluetooth/hci.h
> +++ b/include/net/bluetooth/hci.h
> @@ -192,6 +192,14 @@ enum {
> *
> */
> HCI_QUIRK_NON_PERSISTENT_SETUP,
> +
> + /* When this quirk is set, hw_reset() would be run to reset the
> + * hardware, after a certain number of commands (currently 5)
> + * time out because the device fails to respond.
> + *
> + * This quirk should be set before hci_register_dev is called.
> + */
> + HCI_QUIRK_HW_RESET_ON_TIMEOUT,
> };
>
> /* HCI device flags */
> diff --git a/include/net/bluetooth/hci_core.h b/include/net/bluetooth/hci_core.h
> index e5ea633ea368..b86218304b80 100644
> --- a/include/net/bluetooth/hci_core.h
> +++ b/include/net/bluetooth/hci_core.h
> @@ -313,6 +313,7 @@ struct hci_dev {
> unsigned int acl_cnt;
> unsigned int sco_cnt;
> unsigned int le_cnt;
> + unsigned int timeout_cnt;
>
> unsigned int acl_mtu;
> unsigned int sco_mtu;
> @@ -437,6 +438,7 @@ struct hci_dev {
> int (*post_init)(struct hci_dev *hdev);
> int (*set_diag)(struct hci_dev *hdev, bool enable);
> int (*set_bdaddr)(struct hci_dev *hdev, const bdaddr_t *bdaddr);
> + void (*hw_reset)(struct hci_dev *hdev);
> };
>
> #define HCI_PHY_HANDLE(handle) (handle & 0xff)
> diff --git a/net/bluetooth/hci_core.c b/net/bluetooth/hci_core.c
> index 7352fe85674b..ab3a6a8b7ba6 100644
> --- a/net/bluetooth/hci_core.c
> +++ b/net/bluetooth/hci_core.c
> @@ -2569,13 +2569,24 @@ static void hci_cmd_timeout(struct work_struct *work)
> struct hci_dev *hdev = container_of(work, struct hci_dev,
> cmd_timer.work);
>
> + hdev->timeout_cnt++;
> if (hdev->sent_cmd) {
> struct hci_command_hdr *sent = (void *) hdev->sent_cmd->data;
> u16 opcode = __le16_to_cpu(sent->opcode);
>
> - bt_dev_err(hdev, "command 0x%4.4x tx timeout", opcode);
> + bt_dev_err(hdev, "command 0x%4.4x tx timeout (cnt = %u)",
> + opcode, hdev->timeout_cnt);
> } else {
> - bt_dev_err(hdev, "command tx timeout");
> + bt_dev_err(hdev, "command tx timeout (cnt = %u)",
> + hdev->timeout_cnt);
> + }
> +
> + if (test_bit(HCI_QUIRK_HW_RESET_ON_TIMEOUT, &hdev->quirks) &&
> + hdev->timeout_cnt >= 5) {
> + hdev->timeout_cnt = 0;
> + if (hdev->hw_reset)
> + hdev->hw_reset(hdev);
> + return;
> }
so I really do not see the need for the quirk here. Either hdev->hw_reset is provided, then execute it, if it is not provided then don’t. The quirk is just duplicate information.
I also don’t like hdev->hw_reset since that implies that the only way of handling a command timeout is a hardware reset. I prefer you call this hdev->cmd_timeout and also scrap the timeout_cnt. Let the driver decide what number of timeouts it wants to react on. The number 5 is just an arbitrary number you picked based on one hardware manufacturer.
Regards
Marcel
next prev parent reply other threads:[~2019-01-19 19:51 UTC|newest]
Thread overview: 56+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-11-17 1:07 [PATCH 0/5] Reset Intel BT controller if it gets stuck Rajat Jain
2018-11-17 1:07 ` [PATCH 1/5] usb: split code locating ACPI companion into port and device Rajat Jain
2018-11-17 1:07 ` [PATCH 2/5] usb: assign ACPI companions for embedded USB devices Rajat Jain
2018-11-17 1:07 ` [PATCH 3/5] Bluetooth: Reset Bluetooth chip after multiple command timeouts Rajat Jain
2018-11-17 1:07 ` [PATCH 4/5] Bluetooth: btusb: Collect the common Intel assignments together Rajat Jain
2018-11-17 1:07 ` [PATCH 5/5] Bluetooth: btusb: Use the hw_reset method to allow resetting the BT chip Rajat Jain
2018-11-19 23:04 ` [PATCH v2 1/5] usb: split code locating ACPI companion into port and device Rajat Jain
2018-11-19 23:04 ` [PATCH v2 2/5] usb: assign ACPI companions for embedded USB devices Rajat Jain
2018-11-19 23:04 ` [PATCH v2 3/5] Bluetooth: Reset Bluetooth chip after multiple command timeouts Rajat Jain
2018-11-19 23:04 ` [PATCH v2 4/5] Bluetooth: btusb: Collect the common Intel assignments together Rajat Jain
2018-11-19 23:04 ` [PATCH v2 5/5] Bluetooth: btusb: Use the hw_reset method to allow resetting the BT chip Rajat Jain
2018-11-21 23:50 ` [PATCH v3 1/5] usb: split code locating ACPI companion into port and device Rajat Jain
2018-11-21 23:50 ` [PATCH v3 2/5] usb: assign ACPI companions for embedded USB devices Rajat Jain
2018-12-05 9:32 ` Greg Kroah-Hartman
2018-12-05 17:19 ` Ghorai, Sukumar
2018-11-21 23:50 ` [PATCH v3 3/5] Bluetooth: Reset Bluetooth chip after multiple command timeouts Rajat Jain
2018-11-21 23:50 ` [PATCH v3 4/5] Bluetooth: btusb: Collect the common Intel assignments together Rajat Jain
2018-11-21 23:50 ` [PATCH v3 5/5] Bluetooth: btusb: Use the hw_reset method to allow resetting the BT chip Rajat Jain
2018-12-20 8:46 ` Rajat Jain
2019-01-18 11:04 ` Marcel Holtmann
2019-01-18 20:51 ` Rajat Jain
2018-12-05 9:32 ` [PATCH v3 1/5] usb: split code locating ACPI companion into port and device Greg Kroah-Hartman
2018-12-05 17:41 ` Ghorai, Sukumar
2019-01-18 22:34 ` [PATCH v4 " Rajat Jain
2019-01-18 22:34 ` [PATCH v4 2/5] usb: assign ACPI companions for embedded USB devices Rajat Jain
2019-01-19 19:51 ` Marcel Holtmann
2019-01-22 22:29 ` Rajat Jain
2019-01-18 22:34 ` [PATCH v4 3/5] Bluetooth: Reset Bluetooth chip after multiple command timeouts Rajat Jain
2019-01-19 19:51 ` Marcel Holtmann [this message]
2019-01-22 22:34 ` Rajat Jain
2019-01-18 22:34 ` [PATCH v4 4/5] Bluetooth: btusb: Collect the common Intel assignments together Rajat Jain
2019-01-19 19:51 ` Marcel Holtmann
2019-01-22 22:35 ` Rajat Jain
2019-01-18 22:34 ` [PATCH v4 5/5] Bluetooth: btusb: Use the hw_reset method to allow resetting the BT chip Rajat Jain
2019-01-19 19:51 ` Marcel Holtmann
2019-01-22 22:36 ` Rajat Jain
2019-01-19 19:51 ` [PATCH v4 1/5] usb: split code locating ACPI companion into port and device Marcel Holtmann
2019-01-22 22:28 ` Rajat Jain
2019-01-22 22:42 ` Dmitry Torokhov
2019-01-23 6:36 ` Greg Kroah-Hartman
2019-01-23 20:57 ` [PATCH v5 1/4] " Rajat Jain
2019-01-23 20:57 ` [PATCH v5 2/4] usb: assign ACPI companions for embedded USB devices Rajat Jain
2019-01-23 20:57 ` [PATCH v5 3/4] Bluetooth: Allow driver specific cmd timeout handling Rajat Jain
2019-01-24 9:36 ` Marcel Holtmann
2019-01-24 20:10 ` Rajat Jain
2019-01-23 20:57 ` [PATCH v5 4/4] Bluetooth: btusb: Use the cmd_timeout method to reset the Intel BT chip Rajat Jain
2019-01-24 9:46 ` Marcel Holtmann
2019-01-24 20:05 ` Rajat Jain
2019-01-24 23:28 ` [PATCH v6 1/4] usb: split code locating ACPI companion into port and device Rajat Jain
2019-01-24 23:28 ` [PATCH v6 2/4] usb: assign ACPI companions for embedded USB devices Rajat Jain
2019-01-25 7:51 ` Marcel Holtmann
2019-01-24 23:28 ` [PATCH v6 3/4] Bluetooth: Allow driver specific cmd timeout handling Rajat Jain
2019-01-25 7:51 ` Marcel Holtmann
2019-01-24 23:28 ` [PATCH v6 4/4] Bluetooth: btusb: Use the cmd_timeout method to reset the Intel BT chip Rajat Jain
2019-01-25 7:51 ` Marcel Holtmann
2019-01-25 7:51 ` [PATCH v6 1/4] usb: split code locating ACPI companion into port and device 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=D1490A23-9076-4BAA-A932-CDE1C073475B@holtmann.org \
--to=marcel@holtmann.org \
--cc=alex.hung@canonical.com \
--cc=chethan.tumkur.narayan@intel.com \
--cc=davem@davemloft.net \
--cc=dtor@chromium.org \
--cc=dtor@google.com \
--cc=gregkh@linuxfoundation.org \
--cc=johan.hedberg@gmail.com \
--cc=linux-bluetooth@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-usb@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=raghuram.hegde@intel.com \
--cc=rajatja@google.com \
--cc=rajatxjain@gmail.com \
--cc=sukumar.ghorai@intel.com \
/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).