From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wr1-f42.google.com (mail-wr1-f42.google.com [209.85.221.42]) (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 4881831E85A for ; Thu, 12 Mar 2026 05:59:11 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.221.42 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1773295153; cv=none; b=Va5shbwRM6qGDisViq5sLT3te4jFJvrEPH7UE6scgzPKvXqX0gHW6OoNYmA1N9yp90zZNiMYVRctiWIK3VAQjOk+qHeuk1UBxP12gLpc60BD7tWIVVi2Is3BOZIwjGbHtqNPRDN/+hFGmCxLWhmezls2hslGdsotALfE2WINd84= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1773295153; c=relaxed/simple; bh=NLMMegbnQTHbmAF+7SbxSKcGy39ej+LeM8wtlSGWn4k=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Message-Id:References:To; b=Z/DSkfFQJ91OnZRfQupdwTII+12r58szW9Um5GjcXgAz2ytgn+eX59TPWXUaxVUOKqFDUNrUUbVs1zuyWPRM+jqHvfyl0obL9JMaoWCZU2WcEva4MW3HYztUGN0ADGG0AE/vKSt2ekECWxnfDOcQmHsAE/rtHFKndwAu1nZSMVw= 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=REoL3Uhw; arc=none smtp.client-ip=209.85.221.42 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="REoL3Uhw" Received: by mail-wr1-f42.google.com with SMTP id ffacd0b85a97d-439c9bdc1eeso493631f8f.3 for ; Wed, 11 Mar 2026 22:59:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1773295150; x=1773899950; 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=+MSnagWEumlAjQd4aKb/Z/ZIHp+uVB86nTpw0CtuMsU=; b=REoL3Uhwbsr6ma5LUE/BqQ/h9qH30yz12Mvrbd4mqAn+v+wdItZX2P/tc3dNkYqfnp O9ANvRbLhuo1pf7vAepChpfc/DDjZWCEU4DTAKOAZoBADYIah9ykg+lkN0MZN5i8PkaG p3vR40MCoHn4pMc0VdFVzzJAZx94USIYTIWOWdc3lsyZHjopi8vN7e5h+n1n/Gzm/JED v44YDGD171KzF37h06DSBYohMo6QVi3PCP5Rq/SS85dpeDHIzvDgQ6OtRU9n01c91zGq 8ijvIscP4DVP81p6XorFj2tKs24LCrsD9X/EeD7PwbqiHrfB1nw+klIXT119/QU0nwYF /QZg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1773295150; x=1773899950; 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=+MSnagWEumlAjQd4aKb/Z/ZIHp+uVB86nTpw0CtuMsU=; b=cBhGaB5gN7QTr56mh4ZGXx8CHvq/6GOdQREPqxJlZpUYUDoYGJ8wu4b5wux2B9JFs7 ToDDdgqBpI2C+ytuHWEGnq+tCzNcT/2F77nojS0y5D18xD8gZ2K6Eh0Ew/7/lN7rCi6l pAOXBH/ox1/DOED7KtcS5+521g1cWZbTKtiRcFueQAbAGWwV9JHWXy+p6sk9fZLpyFrU 5xfWdCJRjLOM0MUHclg86cN7CHpYG3NQDhbyldZsamiZRZG6NdePkijvas9cN5Q3qfLL 87UKkVbGeH4P5xZyWgh53S02jZWq5n99MWWtu/CP/2ARMhzWMIU5HSb7l4VKbJ3iFSEw nhjw== X-Forwarded-Encrypted: i=1; AJvYcCXWwNEG1fOj1aH6faAGqG2CrXCf9/r0b1wdzks7PRuPkrIPqcb/haXBeT+dacX4O7fKVmQHE8mr0ZfOFes=@vger.kernel.org X-Gm-Message-State: AOJu0YyZCjo+TxQXCA95OYgtxCm1iBOSWh2wUvBwuG6d+WYqpF0AFL15 yBARbzEb5umilYIsomv+HDMppQvdsOv2ydY/C6KhCpfWzzNGt98LzNyF7AdTFg== X-Gm-Gg: ATEYQzzZLzT30NR4fAkZh9+6EWwICbAZYYWOUUSRirkIR8IT3ylbh5tDU0Qe1bWCNOU O2+8F0mOLMJ/vvNvpRWrSwD6SipP5d2GS70OUuIVhpHW8WEtDoDqSSyFI8cX1TgO0jN5Cwv9jOv Eq9E3kkLKBmSLwmzakemhTixd3EkMV19Bw3Ikl6pabmvOuuPzkKaqntUwh/7qoOPR45yEJeKZhf CKLrS+fxwwZmvbSooRi+uT7vQvm1KI/GOWq8NdnYdNqfqOsrhw6qfAiF9dpzeKq3lxWxFyhorHs NzYySErmJpgPvlJy+PUeQ/EQ5iyqMWWTSZcDa8D6UKNN7DN9elrCA5oIg5vIZXb4fWHEgH+sSST nJE1am5wvGGM0oWqYwf2u1G3RYbch/1sG7KoyGrajsF4FHU4WmaZPgUHBDulDct3wOJ6A289esb +1NHWGtamuOWS2+CyG5viCwZgQl2KmNeXXqXGt/JI6rrw3Q95DKjPp X-Received: by 2002:a5d:5d84:0:b0:439:b6bd:558d with SMTP id ffacd0b85a97d-439f842aab9mr9896146f8f.30.1773295149402; Wed, 11 Mar 2026 22:59:09 -0700 (PDT) Received: from smtpclient.apple ([87.200.95.144]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-439fe20c0b4sm5848964f8f.25.2026.03.11.22.59.07 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Wed, 11 Mar 2026 22:59:08 -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: Thu, 12 Mar 2026 09:58:55 +0400 Cc: Bitterblue Smith , "linux-wireless@vger.kernel.org" , "linux-kernel@vger.kernel.org" Content-Transfer-Encoding: quoted-printable Message-Id: <62487266-6846-4E3D-9947-33CB6FE408BF@gmail.com> 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 12 Mar 2026, at 6:22=E2=80=AFam, Ping-Ke Shih = wrote: >=20 > Christian Hewitt wrote: >>> 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 >>> 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? >>=20 >> 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. >=20 > I have heard people about changing sequence/time of kernel modules, so > I'd like you can try this method.=20 >=20 > I did ask AI, it said it is possible to create a .conf file under > /etc/modprobe.d/ and use `softdep` syntax to ensure loading sequence. > Could you try this? I can test this, but even if it works it=E2=80=99s not a fix because = modprobe confs configured in userspace are only used with loadable modules that have been compiled with =3Dm, not build-in modules that are resident in kernel memory and compiled with =3Dy; and distros are free to choose how their kernel is configured. NB: I=E2=80=99m not sure if there are any = general kernel rules for this, but I=E2=80=99d expect there to be general = principle of modules being resilient to transient host states and not depending on userspace packaging to load correctly? >> In addition, did below messages not appear in these experiments? >>>=20 >>> [ 7.864148] rtw89_8852be 0002:21:00.0: fw security fail >>> [ 7.864154] rtw89_8852be 0002:21:00.0: download firmware fail >>=20 >> 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. >=20 > Additional question for downloading firmware. As you reported this > issue initially (load modules at boot time in parallel), it seems=20 > appear this message by chance. Since this driver will retry to = download > firmware, will it successfully downloads firmware finally? Or it still > fails to download after 5 times retry? I have only seen firmware load fail a handful of times in many hundreds of boots and each time one retry attempt resulted in success. To be clear; I have am not reporting firwmare loading as a problem, it is not an issue for me. I=E2=80=99ve mentioned it only for context, i.e. it = shows that a simple retry mechanism is effective at handling the similar issue with efuse map. Christian