Hi Mark, > When the firmware hang or command no response, driver can reset the > bluetooth mcu via USB to recovery it. The reset steps as follows. > > 1. Cancel USB transfer requests before reset. > 2. It use speicific USB HW Register to reset Bluetooth MCU, at the > same time, the USB Endpoint0 still keep alive. > 3. Poll the USB HW register until reset is completed by Endpoint0. > 4. To recovery unexpected USB state and behavior during resetting the > Bluetooth MCU, the driver need to reset the USB device for MT7921. > 5. After the reset is completed, the Bluetooth MCU need to re-setup, > such as download patch, power-on sequence and etc. > > Signed-off-by: mark-yw.chen <mark-yw.chen@xxxxxxxxxxxx> > --- > drivers/bluetooth/btusb.c | 127 ++++++++++++++++++++++++++++++++++++++ > 1 file changed, 127 insertions(+) > > diff --git a/drivers/bluetooth/btusb.c b/drivers/bluetooth/btusb.c > index b1249b664981..122a928ebcb5 100644 > --- a/drivers/bluetooth/btusb.c > +++ b/drivers/bluetooth/btusb.c > @@ -3076,6 +3076,17 @@ static int btusb_shutdown_intel_new(struct hci_dev *hdev) > return 0; > } > > +/* UHW CR mapping */ > +#define BT_MISC 0x70002510 > +#define BT_SUBSYS_RST 0x70002610 > +#define UDMA_INT_STA_BT 0x74000024 > +#define UDMA_INT_STA_BT1 0x74000308 > +#define BT_WDT_STATUS 0x740003A0 > +#define EP_RST_OPT 0x74011890 > +#define EP_RST_IN_OUT_OPT 0x00010001 > +#define BT_RST_DONE 0x00000100 > +#define BT_RESET_WAIT_MS 100 > +#define BT_RESET_NUM_TRIES 10 you need to prefix these with MTK since otherwise we get confused. And we need to work towards abstracting the vendor specific position out of btusb.c (and I include the Intel part here as well). The btusb.c is getting overloaded with vendor stuff. Regards Marcel
