From: Mehmet Fide <mehmet.fide@gmail.com>
To: Ping-Ke Shih <pkshih@realtek.com>
Cc: Bitterblue Smith <rtl8821cerfe2@gmail.com>,
linux-wireless@vger.kernel.org, linux-kernel@vger.kernel.org,
Mehmet Fide <mehmet.fide@screeningeagle.com>
Subject: Re: [PATCH rtw-next 2/2] wifi: rtw88: usb: only let the frames a dozing station needs use the after-DTIM queue
Date: Sun, 6 Sep 2026 10:20:20 +0200 [thread overview]
Message-ID: <20260906082020.909598-1-mehmet.fide@gmail.com> (raw)
In-Reply-To: <e0c709bd661044d799c3f04ec7348c4d@realtek.com>
Hi Ping-Ke,
> The existing is messed already. But could please put them in increasing
> alphabet order? (only apply the part of '#include <linux/*')
Will do.
> In reverse X'mas tree order. If you want keep 'struct' and 'unsigned int'
> together individually. We can have
> struct ieee80211_hdr *hdr = (struct ieee80211_hdr *)skb->data;
> struct ieee80211_tx_info *info = IEEE80211_SKB_CB(skb);
> unsigned int paylen = sizeof(rfc1042_header) + sizeof(__be16);
> unsigned int hdrlen = ieee80211_hdrlen(hdr->frame_control);
Will use exactly that order (fewer of them after the change below).
> Can we just 'skb->protocol == htons(ETH_P_ARP)' ?
Yes. mac80211 keeps skb->protocol and the network header offset from the
netdev path (ieee80211_build_hdr() only pushes the 802.11 and SNAP headers
in front, the offsets are relative to skb->head), so the SNAP parsing, the
hw_key->iv_len handling and the unaligned.h include can go entirely. For
EAPOL I will test IEEE80211_TX_CTRL_PORT_CTRL_PROTO like
rtw89_core_tx_btc_spec_pkt_notify() does, which also covers a non-default
control port protocol.
> udphdr = udp_hdr(skb); ?
> reference to rtw89_core_tx_btc_spec_pkt_notify().
Will do: skb->protocol == htons(ETH_P_IP), ip_hdr(skb)->protocol ==
IPPROTO_UDP, then udp_hdr(skb) for the 67/68 ports, same shape as the rtw89
helper. The transport header is set by the IP stack for the frames this
matters for (the AP's own DHCP replies).
v2 early next week, with the changes to 1/2 and, if you agree with the
proposal in the other thread, a third patch for REG_ATIMWND.
Mehmet
prev parent reply other threads:[~2026-09-06 8:20 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-02 10:41 [PATCH rtw-next 0/2] wifi: rtw88: usb: keep bmc traffic from exhausting the TX page pool Mehmet Fide
2026-09-02 10:41 ` [PATCH rtw-next 1/2] wifi: rtw88: usb: bound what the driver feeds the after-DTIM queue Mehmet Fide
2026-09-06 3:41 ` Ping-Ke Shih
2026-09-06 8:20 ` Mehmet Fide
2026-09-02 10:41 ` [PATCH rtw-next 2/2] wifi: rtw88: usb: only let the frames a dozing station needs use " Mehmet Fide
2026-09-06 3:51 ` Ping-Ke Shih
2026-09-06 8:20 ` Mehmet Fide [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=20260906082020.909598-1-mehmet.fide@gmail.com \
--to=mehmet.fide@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-wireless@vger.kernel.org \
--cc=mehmet.fide@screeningeagle.com \
--cc=pkshih@realtek.com \
--cc=rtl8821cerfe2@gmail.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