From: "Kordian Chmielewski (mlody1212)" <kudzo51@gmail.com>
To: dev@deq.rocks
Cc: arend.vanspriel@broadcom.com, asahi@lists.linux.dev,
brcm80211-dev-list.pdl@broadcom.com, brcm80211@lists.linux.dev,
j@jannau.net, linux-kernel@vger.kernel.org,
linux-wireless@vger.kernel.org, marcan@marcan.st,
michael.reeves077@gmail.com, sebastian.reichel@collabora.com
Subject: Re: [PATCH 4/4] wifi: brcmfmac: msgbuf: send the flowring delete without waiting for tx status
Date: Wed, 11 Nov 2026 00:12:47 +0100 [thread overview]
Message-ID: <20261110231248.206892-1-kudzo51@gmail.com> (raw)
In-Reply-To: <20261107154810.89780-5-dev@deq.rocks>
On Sat, Nov 07, 2026 at 15:48 UTC, Andre Eikmeyer wrote:
> The BCM4377 firmware returns the tx status of queued packets only when
> it gets the flowring delete request.
The same happens on a BCM43684 (firmware 17.10.188.75, an access point
with about 15 clients on two radios; this chip also needs patches for
its BCA firmware that I haven't posted yet). In 10.5 hours the wait
timed out 23 times. 2835 frames were still out when their flowring was
deleted, and every one of them was completed later, at most 81 s after
it was posted. No pktid was lost, so the 100 ms wait did not help here
either.
What I can't tell from these numbers is whether a tx status can still
come after the delete response. If it can, it lands on a new ring that
got the same flowid in the meantime and decrements its outstanding_tx,
which also drives brcmf_msgbuf_schedule_txdata(). Do you know how the
firmware orders them? In my tree each tx pktid keeps the generation of
its flowring for that case; I can send it on top of your patch if it
turns out to be needed.
Kordian
prev parent reply other threads:[~2026-11-10 23:12 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-11-07 15:48 [PATCH 0/4] wifi: brcmfmac: pcie: S3 suspend and resume on the T2 Mac chips Andre Eikmeyer
2026-11-07 15:48 ` [PATCH 1/4] wifi: brcmfmac: pcie: set the state before D0_INFORM on resume Andre Eikmeyer
2026-11-07 15:48 ` [PATCH 2/4] wifi: brcmfmac: pcie: skip the host ready doorbell at init once it is a capability Andre Eikmeyer
2026-11-07 15:48 ` [PATCH 3/4] wifi: brcmfmac: pcie: probe again after a resume through firmware Andre Eikmeyer
2026-11-07 15:48 ` [PATCH 4/4] wifi: brcmfmac: msgbuf: send the flowring delete without waiting for tx status Andre Eikmeyer
2026-11-10 23:12 ` Kordian Chmielewski (mlody1212) [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20261110231248.206892-1-kudzo51@gmail.com \
--to=kudzo51@gmail.com \
--cc=arend.vanspriel@broadcom.com \
--cc=asahi@lists.linux.dev \
--cc=brcm80211-dev-list.pdl@broadcom.com \
--cc=brcm80211@lists.linux.dev \
--cc=dev@deq.rocks \
--cc=j@jannau.net \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-wireless@vger.kernel.org \
--cc=marcan@marcan.st \
--cc=michael.reeves077@gmail.com \
--cc=sebastian.reichel@collabora.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®