linux-kernel - Re: [PATCH] Bluetooth: btusb: Use cmd

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-Id: <989DBD04-B5DC-4733-8784-93B45BA9FF15@holtmann.org>
Date:   Wed, 4 Sep 2019 16:23:29 +0200
From:   Marcel Holtmann <marcel@...tmann.org>
To:     Alex Lu <alex_lu@...lsil.com.cn>
Cc:     Johan Hedberg <johan.hedberg@...il.com>,
        linux-bluetooth@...r.kernel.org, linux-kernel@...r.kernel.org,
        Max Chou <max.chou@...ltek.com>
Subject: Re: [PATCH] Bluetooth: btusb: Use cmd_timeout to reset Realtek device

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@...lsil.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