From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wm1-f41.google.com (mail-wm1-f41.google.com [209.85.128.41]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 223D3263F34 for ; Mon, 16 Mar 2026 11:03:30 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.128.41 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1773659011; cv=none; b=RF7OuP6sBGzmnkvobyuSSry95Q7yELGMz6C2diWlbMImigbw/RnrbC0k4f/LHEwk+DOEEHqdDxL4jOa6Tn+atfIzno3UxJqyvufMRWdS7u2dtLxDdhxxGAxN5Y83LMPUZzRE9FNOi3yECgcCn+VGixfRO3CcQ7N/iqBekY0jrq8= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1773659011; c=relaxed/simple; bh=XxGoizpqpSsLsjJkBY4+gF72PBU8BRAmqqkpAdkoFYI=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Message-Id:References:To; b=EYBmMGe4cCeB2Rx5wnoI0tHI/DZlZpcDnnEIPHBUxLLUkRv8JaguiNlAIjbOsxj4BUDMyOxok6vAtKQLTipvqlX/npwZdjCCDnGtcgnH8xmXK57f4wl4SbO2rkIGNfv15+Q648yhpqueJKr5wdHiJdAfjyonwoiYgNVCLsCjgl0= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=PIFaznI0; arc=none smtp.client-ip=209.85.128.41 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="PIFaznI0" Received: by mail-wm1-f41.google.com with SMTP id 5b1f17b1804b1-48539d21b76so31041385e9.1 for ; Mon, 16 Mar 2026 04:03:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1773659008; x=1774263808; darn=vger.kernel.org; h=to:references:message-id:content-transfer-encoding:cc:date :in-reply-to:from:subject:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=KBSmBV6S8JTwvGaEVUkXvibGMkQHgn3CnUkn+Fh7WWs=; b=PIFaznI0FmWJHOKsCKbW+5pqslxXgebhtCwmkzvxIDZmYwxZXPtYAOjlzmvZCmjICG 3DWYvBpyPfO64OvMeWZHaD8a9GM3MegzE7aTNJ3CHqk5J65Mbnqka2DdMXxCgYW+Xj4p gbVFupjQNy48nUypzBvhZGQZZe0OtkA4tZotBKbRaLh/XLrBgiv+74AkkqRIK3EYIezp 6ey6Ki9s9ryFURQf2AatGIyOk9RYpiODKrbw+PGicUOqOdr6/1SAInbmNXeZmXA1e3Mv 6A62iIZBa737Cwdevcs04DLeMPIUy3nJ/hm/Jrv6R1fIFI8z/yp9wX6Ilu6OnJIhma23 uV/Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1773659008; x=1774263808; h=to:references:message-id:content-transfer-encoding:cc:date :in-reply-to:from:subject:mime-version:x-gm-gg:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=KBSmBV6S8JTwvGaEVUkXvibGMkQHgn3CnUkn+Fh7WWs=; b=J2HA2uNR0EvT+JMUtysFTcFNf3XPWx1uWw/DSezaHfiZStI3GE3GffQWmsLZaRnGWV 7luUGtiKNq8sJ4mX4OYtY67Ern997bl9+E4n7/fncGV3/cxiBR5Cwr7Ow0VU7Qa9Zcf0 SxtxMThGplEcbOKRpZGNFWv5nHce+x+JywcwcwLSTmQQzml0mD3SGENlW9P9m1LNkSl1 nQQioLa7i9sMQTMPMnVdmPIrL60kB6Ld3ienaKFRfyeRbVnxWz7PXdHLMADfPZVHhZ4y DjV+PdApw7FJmupGo0wj4vm/dkB1s3RRMGK5Jdkxvzs/KuF2RQ3psiw+xqMNfcoDRvIZ n4qA== X-Forwarded-Encrypted: i=1; AJvYcCXhb3scQW0v3sie7gmEeuUTIvKqzDlzy4O4xCmkJPTktd6vzT/46GuCjoWE++X+N00PNxVr+XEIZtGaZtI=@vger.kernel.org X-Gm-Message-State: AOJu0YyNwH6dhrqke4BkyVDWP8DVGaqNMI2lxjH6DQPPFpY0i8DbhXsW iGwjuAYEPyUnCAnt93n9AOHE3uy0eeCVbi7gXlCEk9vCo3gZOUSY5MGR X-Gm-Gg: ATEYQzzu06Sx6iU7cyh4H0GlfyB7+4KXAsw6p8tqfwYQX677uyOHh2IOHtZYqriEHny Z/I2QYqogPBBFiGKzSAozy88oNo1jUr/s6moLTzpzaRIDs6r71ZwVA8Y/ddNE8/kn/Ol1orY+7X GSIm193NeXerhZAnIWXFR7EkI3XC8obgZtPOMNx0PIOKFptozXhUgcIMUPPAnj6AhR7I4yRZhaz o2h8g8dF/ZFIipIsOIkvesM9z68uNuB44l4g0h064QbFGZsIbJW2BilSb94wIebWEhLnHN/ONuB oqyzRUrcfICYIGhSWO3XOPeeXgnM5o+R3Yzfsih+WJ1HuKUwiQ62tzC7hze+xwHSJh6fUeBSb3N Sij56lSbXL5nBhIH/327s/ZJbZ8xUJDl3xnrMH6qgBVJNU+do6uoVu4HFl0V2beBCQ2j9vemxJu 055tU8n2gbHM4Ge4y72u/Ur9WGbbKA/6FKkUe+clTQ+lz4rVzhzkQd7OV6Ynva+gnKSXDjVDyOX MB5e7hi540va/DKbJtsHgP6RQU= X-Received: by 2002:a05:600c:4514:b0:485:2f6a:6ed with SMTP id 5b1f17b1804b1-4855670b701mr197056835e9.28.1773659008190; Mon, 16 Mar 2026 04:03:28 -0700 (PDT) Received: from smtpclient.apple (static.253.36.98.91.clients.your-server.de. [91.98.36.253]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-48558fd09d8sm257030845e9.7.2026.03.16.04.03.24 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Mon, 16 Mar 2026 04:03:25 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3864.400.21\)) Subject: Re: [PATCH] wifi: rtw89: retry efuse physical map dump on transient failure From: Christian Hewitt In-Reply-To: Date: Mon, 16 Mar 2026 15:03:12 +0400 Cc: Bitterblue Smith , "linux-wireless@vger.kernel.org" , "linux-kernel@vger.kernel.org" Content-Transfer-Encoding: quoted-printable Message-Id: <86F91944-A4B0-46D6-B2DE-7391EB5B38A7@gmail.com> References: <20260301042422.195491-1-christianshewitt@gmail.com> To: Ping-Ke Shih X-Mailer: Apple Mail (2.3864.400.21) > On 16 Mar 2026, at 9:32=E2=80=AFam, Ping-Ke Shih = wrote: >=20 > Christian Hewitt wrote: >> On Radxa Rock 5B with a RTL8852BE combo WiFi/BT card, the efuse >> physical map dump intermittently fails with -EBUSY during probe. >> The failure occurs in rtw89_dump_physical_efuse_map_ddv() where >> read_poll_timeout_atomic() times out waiting for the B_AX_EF_RDY >> bit after 1 second. >>=20 >> The root cause is a timing race during boot: the WiFi driver's >> chip initialization (firmware download via PCIe) overlaps with the >> Bluetooth firmware download to the same combo chip over USB. This >> can leave the efuse controller temporarily unavailable when the >> WiFi driver attempts to read the efuse map. >>=20 >> Add a retry loop (up to 3 attempts with 500ms delays) around the >> physical efuse map dump in rtw89_parse_efuse_map_ax(). The firmware >> download path already retries up to 5 times, but the efuse read >> that follows has no retry logic, making it the weak link in the >> probe sequence. >=20 > I'd prefer adding a wrapper to retry 5 times without delay as bottom > changes for reference. If you want to limit retry only for > 'dav =3D=3D false' case, it is also fine to me. >=20 >>=20 >> Signed-off-by: Christian Hewitt >=20 > [...] >=20 >>=20 >> drivers/net/wireless/realtek/rtw89/efuse.c | 13 ++++++++++++- >> 1 file changed, 12 insertions(+), 1 deletion(-) >>=20 >> diff --git a/drivers/net/wireless/realtek/rtw89/efuse.c >> b/drivers/net/wireless/realtek/rtw89/efuse.c >> index a2757a88d55d..d506f04ffd6c 100644 >> --- a/drivers/net/wireless/realtek/rtw89/efuse.c >> +++ b/drivers/net/wireless/realtek/rtw89/efuse.c >> @@ -270,6 +270,7 @@ int rtw89_parse_efuse_map_ax(struct rtw89_dev = *rtwdev) >> u8 *log_map =3D NULL; >> u8 *dav_phy_map =3D NULL; >> u8 *dav_log_map =3D NULL; >> + int retry; >> int ret; >>=20 >> if (rtw89_read16(rtwdev, R_AX_SYS_WL_EFUSE_CTRL) & = B_AX_AUTOLOAD_SUS) >> @@ -289,7 +290,17 @@ int rtw89_parse_efuse_map_ax(struct rtw89_dev = *rtwdev) >> goto out_free; >> } >>=20 >> - ret =3D rtw89_dump_physical_efuse_map(rtwdev, phy_map, 0, = phy_size, >> false); >> + for (retry =3D 0; retry < 3; retry++) { >> + if (retry) { >> + rtw89_warn(rtwdev, "efuse dump failed, = retrying >> (%d)\n", >> + retry); >> + fsleep(500000); >> + } >> + ret =3D rtw89_dump_physical_efuse_map(rtwdev, = phy_map, 0, >> + phy_size, false); >> + if (!ret) >> + break; >> + } >> if (ret) { >> rtw89_warn(rtwdev, "failed to dump efuse physical = map\n"); >> goto out_free; >> -- >> 2.43.0 >=20 > How about retrying 5 times without fsleep(500000)? >=20 > diff --git a/drivers/net/wireless/realtek/rtw89/efuse.c = b/drivers/net/wireless/realtek/rtw89/efuse.c > index a2757a88d55d..89d4b1b865f8 100644 > --- a/drivers/net/wireless/realtek/rtw89/efuse.c > +++ b/drivers/net/wireless/realtek/rtw89/efuse.c > @@ -185,8 +185,8 @@ static int = rtw89_dump_physical_efuse_map_dav(struct rtw89_dev *rtwdev, u8 *map, > return 0; > } >=20 > -static int rtw89_dump_physical_efuse_map(struct rtw89_dev *rtwdev, u8 = *map, > - u32 dump_addr, u32 dump_size, = bool dav) > +static int __rtw89_dump_physical_efuse_map(struct rtw89_dev *rtwdev, = u8 *map, > + u32 dump_addr, u32 = dump_size, bool dav) > { > int ret; >=20 > @@ -208,6 +208,25 @@ static int rtw89_dump_physical_efuse_map(struct = rtw89_dev *rtwdev, u8 *map, > return 0; > } >=20 > +static int rtw89_dump_physical_efuse_map(struct rtw89_dev *rtwdev, u8 = *map, > + u32 dump_addr, u32 dump_size, = bool dav) > +{ > + int retry; > + int ret; > + > + for (retry =3D 0; retry < 5; retry++) { > + ret =3D __rtw89_dump_physical_efuse_map(rtwdev, map, = dump_addr, > + dump_size, dav); > + if (!ret) > + return 0; > + > + rtw89_warn(rtwdev, "efuse dump (dav=3D%d) failed, = retrying (%d)\n", > + dav, retry); > + } > + > + return ret; > +} > + > #define invalid_efuse_header(hdr1, hdr2) \ > ((hdr1) =3D=3D 0xff || (hdr2) =3D=3D 0xff) > #define invalid_efuse_content(word_en, i) \ I=E2=80=99ve run some boot tests and this also resolves my efuse map = use-case, e.g. ROCK5B:~ # dmesg | grep rtw89 [ 6.506375] rtw89_8852be 0002:21:00.0: loaded firmware = rtw89/rtw8852b_fw-1.bin [ 6.506539] rtw89_8852be 0002:21:00.0: enabling device (0000 -> 0003) [ 6.516069] rtw89_8852be 0002:21:00.0: Firmware version 0.29.29.15 = (6fb3ec41), cmd version 0, type 5 [ 6.516083] rtw89_8852be 0002:21:00.0: Firmware version 0.29.29.15 = (6fb3ec41), cmd version 0, type 3 [ 10.153731] rtw89_8852be 0002:21:00.0: efuse dump (dav=3D0) failed, = retrying (0) [ 10.405347] rtw89_8852be 0002:21:00.0: chip info CID: 0, CV: 1, AID: = 0, ACV: 1, RFE: 1 [ 10.408311] rtw89_8852be 0002:21:00.0: rfkill hardware state changed = to enable So far I haven=E2=80=99t observed more than 1x retry being required, and = there are no issues with loading the BT module. Would you like me to send a v2 using your revised version? - or? Christian=