Received-SPF: pass (google.com: best guess record for domain of linux-bluetooth-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
Content-Type: text/plain;
        charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
Subject: Re: [PATCH] Bluetooth: btusb: Use cmd_timeout to reset Realtek device
From:   Marcel Holtmann <marcel@holtmann.org>
In-Reply-To: <20190903094103.GA10714@laptop-alex>
Date:   Wed, 4 Sep 2019 16:23:29 +0200
Cc:     Johan Hedberg <johan.hedberg@gmail.com>,
        linux-bluetooth@vger.kernel.org, linux-kernel@vger.kernel.org,
        Max Chou <max.chou@realtek.com>
Content-Transfer-Encoding: 8BIT
Message-Id: <989DBD04-B5DC-4733-8784-93B45BA9FF15@holtmann.org>
References: <20190903094103.GA10714@laptop-alex>
To:     Alex Lu <alex_lu@realsil.com.cn>
Sender: linux-bluetooth-owner@vger.kernel.org
Precedence: bulk

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