Hi Alex,
> Realtek Bluetooth controller provides a BT_DIS reset pin for hardware
> reset of it. The cmd_timeout is helpful on Realtek bluetooth controller
> where the firmware gets stuck.
>
> Signed-off-by: Alex Lu <alex_lu@xxxxxxxxxxxxxx>
> ---
> drivers/bluetooth/btusb.c | 29 +++++++++++++++++++++--------
> 1 file changed, 21 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/bluetooth/btusb.c b/drivers/bluetooth/btusb.c
> index 31d3febed187..a626de3a3f4c 100644
> --- a/drivers/bluetooth/btusb.c
> +++ b/drivers/bluetooth/btusb.c
> @@ -489,16 +489,19 @@ struct btusb_data {
> int (*setup_on_usb)(struct hci_dev *hdev);
>
> int oob_wake_irq; /* irq for out-of-band wake-on-bt */
> - unsigned cmd_timeout_cnt;
> + unsigned int cmd_timeout_cnt;
> + unsigned int cmd_timeout_max;
> + unsigned int reset_msecs;
> + int reset_gpio_value;
> };
>
>
> -static void btusb_intel_cmd_timeout(struct hci_dev *hdev)
> +static void btusb_cmd_timeout(struct hci_dev *hdev)
> {
> struct btusb_data *data = hci_get_drvdata(hdev);
> struct gpio_desc *reset_gpio = data->reset_gpio;
>
> - if (++data->cmd_timeout_cnt < 5)
> + if (++data->cmd_timeout_cnt < data->cmd_timeout_max)
> return;
>
> if (!reset_gpio) {
> @@ -519,9 +522,9 @@ static void btusb_intel_cmd_timeout(struct hci_dev *hdev)
> }
>
> bt_dev_err(hdev, "Initiating HW reset via gpio");
> - gpiod_set_value_cansleep(reset_gpio, 1);
> - msleep(100);
> - gpiod_set_value_cansleep(reset_gpio, 0);
> + gpiod_set_value_cansleep(reset_gpio, data->reset_gpio_value);
> + msleep(data->reset_msecs);
> + gpiod_set_value_cansleep(reset_gpio, !data->reset_gpio_value);
> }
I really prefer that no Realtek specifics end up in a callback that is meant for Intel hardware. So this needs to be split.
So can you just provide a btusb_rtl_cmd_timeout callback and set it in case of Realtek hardware.
Regards
Marcel
