From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wm1-f51.google.com (mail-wm1-f51.google.com [209.85.128.51]) (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 40E9328640B for ; Wed, 11 Mar 2026 04:20:34 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.128.51 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1773202835; cv=none; b=mMKWwgGa8H3auRhuVmDFbML9CJSj+BuK6uSNFz13RUOmwruTdIGD06JyeUtmBjKcqBmaEBU9YQtr/y+fhhTZRGqm684CMZ/NFsa4vOEDy6FkP3GE1AWhU338h0wvBReD4AiGh6D8Y+qRWXh989i/kgZz5ZqnMklZulCDQFLzLxw= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1773202835; c=relaxed/simple; bh=2ZsTp1IP1Pte0TzT345EUvC4QiGb9Wsf9k+EZZjlBiU=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Message-Id:References:To; b=YEyBNJ1PrWMDiPehXE6GeailYha6CsN4b/tueOEHW331bpNVhcS00upMRe0dB445ghkXSyecxT7pSVqNbmQKfFPw+SQT40HiHdjGYayMGKKvjWdDcBEaaUZFLADluoNgjXCmO9kkuNtuIGnaehC4RfcUhCLTX6m+sglY9RfDM4g= 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=EZfbicqF; arc=none smtp.client-ip=209.85.128.51 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="EZfbicqF" Received: by mail-wm1-f51.google.com with SMTP id 5b1f17b1804b1-4852c9b4158so33275745e9.0 for ; Tue, 10 Mar 2026 21:20:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1773202833; x=1773807633; 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=DIUo63YLFVRvfaF5ty/1RRglNjaZo/S9cXK1lCXCSTg=; b=EZfbicqFdMnxmgQrsKvC4ZGT/YkJHE0m0772CQuL4qFVUr56uo2wd4lemPzLe2I2zR o8HklTgWX3xMOuUhZTKWAvt7+7qLEqziKg150SBM1z8xdCY+2ngUgY5sugreVXPzKF6U CbL0seqQr+fwJYCzhuzNV74a8ECTXiEZoiO9TKVGls/1bmo0+4ALX7jjVyoda5vorYb6 K1A2shX8IwHAenEB3WzoeFcyrkUIsNYDg2fjoU7iPfLQcm21NkzYhi7+oEV7eD9gJcg3 XeGyRnrVYExadyKEUa4YVQOwutLdSkivC0KCPCtmCJ+LyIQ19Ppa9ohdl+OqPl/akTrR Vodw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1773202833; x=1773807633; 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=DIUo63YLFVRvfaF5ty/1RRglNjaZo/S9cXK1lCXCSTg=; b=lAOMEiHwJkBvdGSxMNhkcCIwLJ7JMvKkdUTBbqqUf6wml+gNQisO5GB6OJlXXf49zB 2VPgigAvCZ6FKUct8ORDANcLn5nYPM5Pr/TLX82hdZObM6pnfP+8QY7eAeqhGXz3+cLz k92fJTfWG/dql/dXnOV6ZBLrFCf/7JBOUAeLXVzlqMyvVg68WtTieC3eGHRrnfWJ/Z+I tvryu4agwQTYiI6aIQ1QK8TUwUXwMV/2V/5Q6uUdyhiRok42F1mt6NkkwgpueTUiFqKy lg5fB/gLJ3PrnoaOF8YL4ihoNXK0zZvDrixJAVmfaFDAennCNSuaQ1LbZoGGyFWwq87h SX/g== X-Forwarded-Encrypted: i=1; AJvYcCVa72x9Gyv6zsvjK7Lx2ihS9E9nl3URpdNsRwGUr0sCyX2ijFv8HDA+5zWpXJrN5xGX3OLLDnwhh/iveLA=@vger.kernel.org X-Gm-Message-State: AOJu0Yyumf50BiqaI2MGKoHys2RmkNoL1lnXqbG/x3nDRNzlx0geqMQe et0tR8eU8dA81XLzdELJW9LM0EKkZug6HpjLYacVwkI7kZBuPdeeBsdd X-Gm-Gg: ATEYQzwUPpONc4zJZPwPJ9eYOenI3QxGPcxP2jdpQ1Gv/v5TU9gsaS3xyguHUiJKn/8 UvQoEUM6WDjKCHdilyUtwyN8at9v013z2O8y88GZ+nHzQQMAyRbI/BkkbhHVphGlGfa+T450D8v a5+FuBtKNtllcZhj0qvsOIOnRgP+ncyrKARER8u/f1QlUzSL3x9/pYpnEa8fz9PJKICQNvPpB4g 4WhbzaFdUqz0LOHE70FmcplNiGr0r0dDbPrt7LmmgzoiVh49+5oAGPOppJit2LKtq5GuNcFj7Nf Z+DWlGw0A+n+QzQz+TtecKvzixFim6c9tU16BUNwTNyu0TsBnf8b9QDCG6ifM3OZ6+731tVw5PM S62o5TdwZsk17Gwym2FQXyLN68suXEnzcUdwij1M/itrMYKz1COOQeDHHwBnU3PMvkDpGNz0XUD uPwrw0WZ4QFUz3F4k1BJYWibt2MJtl00p1 X-Received: by 2002:a05:600c:5249:b0:485:40c6:f528 with SMTP id 5b1f17b1804b1-4854b1573admr17945795e9.30.1773202832397; Tue, 10 Mar 2026 21:20:32 -0700 (PDT) Received: from smtpclient.apple ([87.200.95.144]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-4854b6070acsm17046815e9.8.2026.03.10.21.20.30 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 10 Mar 2026 21:20:31 -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: <2ab692371ff94a3f960d41b04288a084@realtek.com> Date: Wed, 11 Mar 2026 08:20:19 +0400 Cc: Bitterblue Smith , "linux-wireless@vger.kernel.org" , "linux-kernel@vger.kernel.org" Content-Transfer-Encoding: quoted-printable Message-Id: References: <20260301042422.195491-1-christianshewitt@gmail.com> <903C7E52-033F-455E-89DC-B78C67C0C732@gmail.com> <5ad1b7d20d1745bab0638d15731e7ccd@realtek.com> <2ab692371ff94a3f960d41b04288a084@realtek.com> To: Ping-Ke Shih X-Mailer: Apple Mail (2.3864.400.21) > On 11 Mar 2026, at 7:05=E2=80=AFam, Ping-Ke Shih = wrote: >=20 > Christian Hewitt wrote: >>=20 >>> On 9 Mar 2026, at 6:35=E2=80=AFam, Ping-Ke Shih = wrote: >>>=20 >>> Christian Hewitt wrote: >>>>=20 >>>>> On 2 Mar 2026, at 10:04=E2=80=AFam, Ping-Ke Shih = wrote: >>>>>=20 >>>>> Christian Hewitt wrote: >>>>>>> On 2 Mar 2026, at 9:47=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 >>>>>>> I'm checking internally how we handle this case. >>>=20 >>> Sorry for the late. >>>=20 >>> We encountered WiFi/BT reading efuse at the same time causing = similar >>> problem as yours. The workaround is like yours, which adds timeout >>> time. >>>=20 >>>>>>>=20 >>>>>>> [...] >>>>>>>=20 >>>>>>>>=20 >>>>>>>> For context, firmware also fails (and recovers) sometimes: >>>>>>>=20 >>>>>>> Did you mean this doesn't always happen? sometimes? >>>>>>=20 >>>>>> It=E2=80=99s another intermittent behaviour observed on this = board (and not >>>>>> related to the issue this patch targets). It occurs less = frequently >>>>>> than the efuse issue and the existing retry mechanism in the = driver >>>>>> ensures firmware load always succeeds. >>>=20 >>> This might be the same cause due to reading efuse in firmware. >>>=20 >>> Though we can add more timeout and retry times as workaround, I = wonder >>> if you can control loading time of WiFi and BT kernel modules? >>>=20 >>> More, can you do experiment that you load BT module first, and then = load >>> WiFi module after 10 seconds (choose a large number intentionally, = or >>> even larger)? >>=20 >> https://paste.libreelec.tv/charmed-turkey.sh >>=20 >> I=E2=80=99ve run the above script ^ which removes the wifi and bt = modules in >> sequence then reloads them in the reverse order with a delay between >> bt and wifi modules loading, then checks for error messages. Over 200 >> test cycles with a 10s delay all were clean (no errors). I also ran >> cycles with a 2 second delay and 0 second delay before starting wifi >> module load and those were clear too. I guess that proves sequencing >> avoids the efuse contention issue? - although it=E2=80=99s not = possible in >> the real-world so not sure there=E2=80=99s huge value in knowing that = :) >=20 > Thanks for the experiments.=20 >=20 > Still want to know is it possible to change sequence/time of loading > kernel modules at boot time from system level? I mean can you adjust > the sequence in the Rock 5B board? I=E2=80=99m not a kernel expert, but I=E2=80=99ve always understood = module probe and load ordering to not be guaranteed; as many things run in parallel and are highly subjective to the specific hardware capabilities and kernel config being used. > In addition, did below messages not appear in these experiments?=20 >=20 > [ 7.864148] rtw89_8852be 0002:21:00.0: fw security fail > [ 7.864154] rtw89_8852be 0002:21:00.0: download firmware fail No, because even if we have a 0s delay between each group of modules being loaded, they are loaded in series, so we workaround the issue. Tweaking the script to background the module load loops so both run in parallel would be closer to normal conditions, and I would expect to start seeing failures and the retry mechanisms within the modules (as added in this patch) being triggered. Christian