linux-kernel - RE: [PATCH v4 2/2] Bluetooth: btusb: Support Bluetooth Reset for Mediatek Chip(MT7921)

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: <SL2PR03MB4457B4B5FFE8A3A7529D08BFB3E99@SL2PR03MB4457.apcprd03.prod.outlook.com>
Date:   Tue, 27 Jul 2021 15:16:25 +0000
From:   Mark-YW Chen (陳揚文) <Mark-YW.Chen@...iatek.com>
To:     Marcel Holtmann <marcel@...tmann.org>
CC:     Johan Hedberg <johan.hedberg@...il.com>,
        Chris Lu (陸稚泓) <Chris.Lu@...iatek.com>,
        Will-CY Lee (李政穎) <Will-CY.Lee@...iatek.com>,
        Sean Wang <Sean.Wang@...iatek.com>,
        Bluetooth Kernel Mailing List 
        <linux-bluetooth@...r.kernel.org>,
        "linux-mediatek@...ts.infradead.org" 
        <linux-mediatek@...ts.infradead.org>,
        open list <linux-kernel@...r.kernel.org>,
        "michaelfsun@...gle.com" <michaelfsun@...gle.com>,
        "shawnku@...gle.com" <shawnku@...gle.com>,
        "jemele@...gle.com" <jemele@...gle.com>,
        "apusaka@...gle.com" <apusaka@...gle.com>
Subject: RE: [PATCH v4 2/2] Bluetooth: btusb: Support Bluetooth Reset for
 Mediatek Chip(MT7921)

Hi Marcel,

> 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.
I agree with your comment, The vendor should create the vendor.c for their specific behavior.

First, I add the prefix into these patches.
After these patches merged, we will create the btmtk.c to handle Mediatek stuff.

With best regards,
Mark

-----Original Message-----
From: Marcel Holtmann [mailto:marcel@...tmann.org]
Sent: Thursday, July 22, 2021 10:04 PM
To: Mark-YW Chen (陳揚文)
Cc: Johan Hedberg; Chris Lu (陸稚泓); Will-CY Lee (李政穎); Sean Wang; Bluetooth Kernel Mailing List; linux-mediatek@...ts.infradead.org; open list; michaelfsun@...gle.com; shawnku@...gle.com; jemele@...gle.com; apusaka@...gle.com
Subject: Re: [PATCH v4 2/2] Bluetooth: btusb: Support Bluetooth Reset for Mediatek Chip(MT7921)

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@...iatek.com>
> ---
> 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