Re: [PATCH] Bluetooth: btusb: Use cmd_timeout to reset Realtek device

[Marcel Holtmann <marcel@holtmann.org>]

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@realsil.com.cn>
> ---
> 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