From mboxrd@z Thu Jan 1 00:00:00 1970 Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.remote-ip=91.218.175.250 ARC-Seal: i=1; d=subspace.kernel.org; s=arc20261015; a=rsa-sha256; cv=none; t=1793377385; b=dg+4GNEC2h1EdOHs9tn59ITmHdi7cXVMdNiZfwqw//0IviqtbJT2hez4hhY7W7lB3vOG ++nWj/na0lO0a5rZGmO2t3xGnerycHiBTxgQt4MQ03RzrXWopz/QJ61phSK3i3RTDgR0M ggwqc+j6L/nlfWqebMg44KbejkWT7qXp34eqLQZyGdeiVStZIhFIFPApu8XDQiZQqQifM WSnNBNvH8GslIsqzokC0nGYSpHpXALRMftv2WvQ8eqDCI0ts7M6rNbYHOGxgTrNxee+qu 5U+LbYskvGLNJBK5EjT/8APiIfmOEDeIfsy6oqsNhmIL0J0PwT+9VCTb55Jt9KK9OjQ== ARC-Message-Signature: i=1; d=subspace.kernel.org; s=arc20261015; a=rsa-sha256; c=relaxed/relaxed; t=1793377385; h=DMARC-Filter:X-Envelope-To:DKIM-Signature:X-Envelope-To:Received: X-Mizu-Trace-ID:X-Migadu-Flow:MIME-Version:Date:Content-Type: Content-Transfer-Encoding:From:Message-ID:TLS-Required:Subject:To:Cc: In-Reply-To:References; bh=NUAlT/mfqIGpNEfFOjDdTkobzVzrPdeXJsRuK6pgwqw=; b=jNipQE9p8llhI636PnVQj50gnFy/5hXeJIoHkJcy2kyqF7q5XbZ4cNNCiA7N9fn3uh0k OWnuZVmxIYLxkbYxXfi0bcGw1ostCZf/UFZXayKDBYhFiMwtFFeBTOs/G3TQ1OQRyh3UB hMsqZLVSm2oOMSxbly3ghnqzNCIJKgm+yUCcn/CRsUzziyU0pu6SpvuGAdhy39QEDaTML bmD13mLY7obRRFzD0ND3aLHIPqEfbb3T2hc3KgwWjo3fUmnSZbo/28rfjt0VlPjdp4ZOk ds6quus09q7BTx2/kpfVbd6rxAr9vmr9S6/HA5K4M0tYFde+FMSgRgSDqUsprb5r1bw== ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass header.from=linux.dev; spf=pass smtp.mailfrom=linux.dev; dkim=pass header.d=linux.dev header.i=@linux.dev header.a=rsa-sha256 header.s=key1 header.b=IZzRfX1A; arc=none smtp.remote-ip=91.218.175.250 Received: from mta0.migadu.com (out-250.mta0.migadu.com [91.218.175.250]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature ECDSA (prime256v1) server-digest SHA256) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 533EC606A31A for ; Fri, 30 Oct 2026 16:23:03 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.2 smtp.subspace.kernel.org 533EC606A31A Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.dev Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linux.dev Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key, unprotected) header.d=linux.dev header.i=@linux.dev header.a=rsa-sha256 header.s=key1 header.b=IZzRfX1A X-Envelope-To: linux-kernel@vger.kernel.org DKIM-Signature: a=rsa-sha256; bh=USiWebNAZxwrsn3gPO+qaXyNBHhXDNdUkPKJ8DQ/5Y4=; c=simple/simple; d=linux.dev; h=from:to:subject:date:message-id:mime-version:content-type; s=key1; t=1793377381; v=1; x=1793982181; b=IZzRfX1AmJLqcrQdUzs2Cl8zaJhzUrvU2u0a/DDN9lJOiGu0286T6QhQ0mfNIwKYBVAlzVKK BNR+J7awoeUu2L9c9LwUuru7q4yQbA/EvvgqZ/duf9FbLLEl51LvgKeJipbmjGqBhb7rRPBpV4c rpRwilY1lePXMuNv5RXZmECc= X-Envelope-To: linux-kernel@vger.kernel.org Received: by smtp.migadu.com with ESMTPS id aa47b306ce4c97cd; Fri, 30 Oct 2026 16:23:01 +0000 X-Mizu-Trace-ID: aa47b306ce4c97cd X-Migadu-Flow: FLOW_OUT X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Post: List-Help: List-Subscribe: List-Unsubscribe: List-Owner: Precedence: list MIME-Version: 1.0 Date: Fri, 30 Oct 2026 16:23:01 +0000 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: "Luka Gejak" Message-ID: <6a4c37826646abbf833e49aadee7701a3dd4e96a@linux.dev> TLS-Required: No Subject: Re: [PATCH rtw-next v9 3/3] wifi: rtw88: time the countdown downloads from the TBTT To: "Mehmet Fide" , "Ping-Ke Shih" Cc: "Bitterblue Smith" , linux-wireless@vger.kernel.org, linux-kernel@vger.kernel.org, mehmet.fide@screeningeagle.com In-Reply-To: <20261026152940.1274382-4-mehmet.fide@gmail.com> References: <20261026152940.1274382-1-mehmet.fide@gmail.com> <20261026152940.1274382-4-mehmet.fide@gmail.com> Hi Mehmet, Looking at this patch again, I found something I missed on v8. October 26, 2026 at 4:29 PM, "Mehmet Fide" wrote: > diff --git a/drivers/net/wireless/realtek/rtw88/fw.c b/drivers/net/wire= less/realtek/rtw88/fw.c > index 2d81aaeed0d7..9ba4f1c244ec 100644 > --- a/drivers/net/wireless/realtek/rtw88/fw.c > +++ b/drivers/net/wireless/realtek/rtw88/fw.c [ ... ] > +static void rtw_fw_csa_queue(struct rtw_dev *rtwdev, struct ieee80211_= vif *vif, > + bool start) > { > u32 interval =3D ieee80211_tu_to_usec(vif->bss_conf.beacon_int); > + u64 tsf =3D rtw_fw_read_tsf(rtwdev); > s64 delay; > + u32 rem; > + > + if (start) { > + div_u64_rem(tsf, interval, &rem); > + rtwdev->csa_tbtt =3D tsf - rem + interval; > + /* a TBTT just passed may have sent the first count */ > + if (rem < RTW_CSA_TBTT_MARGIN_US) > + rtwdev->csa_tbtt -=3D interval; As far as I can see, the TSF is only read here once the whole page download and the H2C are done: rtw_ops_bss_info_changed() rtw_fw_download_rsvd_page() rtw_send_rsvd_page_h2c() rtw_fw_csa_start() rtw_fw_csa_queue(rtwdev, vif, true) You measured about 3.3 ms for a download on USB, and on PCIe it is just a DMA and some register polling. So most of the 10 ms margin lies before the download started. A TBTT there sent the old beacon, but it is still taken as the one that sent the first count, and with the usual beacon interval the work replaces that count before it is ever sent. With a count of 2 the first fetch already carries count 1. So if I read it right, the work then finds ieee80211_beacon_cntdwn_is_complete() true and calls ieee80211_csa_finish() before any beacon with the CSA element went out. Before this patch the first work ran a full interval after the download, so the count 1 beacon went out first. With bigger counts the first count just gets lost. Could the TSF also be read before rtw_fw_download_rsvd_page(), so that only a TBTT after the download started is taken as one that may have sent the first count? Maybe this could also be checked on the 8822CE once it arrives. Best regards, Luka Gejak