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 <[email protected]> > --- > 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
