Re: [PATCH rtw-next v8 5/7] wifi: rtw88: 8723b: add the RTL8723B chip driver

["Luka Gejak" <luka.gejak@linux.dev>]

On Fri Oct 9, 2026 at 2:40 PM CEST, Bitterblue Smith wrote:
> On 06/10/2026 16:06, Luka Gejak wrote:
>> Add the Realtek RTL8723B 802.11n chip driver: the chip operations, the
>> power sequences, the efuse layout, the RF and IQ calibration, and the
>> chip specific coexistence handling.
[...]
>> +{
>> +	/*
>> +	 * The 8723B PHY status does not report the channel, so we must
>> +	 * mark it invalid to allow mac80211/rtw88 to parse it from the IE
>> +	 * during scanning.
>> +	 */
>> +	pkt_stat->channel_invalid = true;
>
> After testing RTL8723BU for a bit, I think this is wrong.
>
> mac80211 thinks there is massive beacon loss when connected to a network
> with 40 MHz channel width, but phy_info in debugfs shows that beacons are
> being received. The beacons are handed over to mac80211 with a wrong
> frequency in struct ieee80211_rx_status. In my case, the correct frequency
> is 2472 MHz, but after rtw_update_rx_freq_from_ie() the frequency is set
> to 2462 MHz. mac80211 is probably discarding the beacons because of this.
> Removing this line fixes the problem.
>
> I think channel_invalid is only for chips which do hardware scan offload
> (RTL8822C). With the chips that only do software scanning the driver
> should always know what channel it's on and rtw_update_rx_freq_from_ie()
> is not needed.
>

You are right, and thanks for chasing this down.

The assignment causes it. With channel_invalid set, the frequency handed
to mac80211 comes from rtwdev->hal.current_channel, which
rtw_update_channel() sets to the center channel rather than the primary.
At 40 MHz those differ, so mac80211 drops the beacon in
ieee80211_rx_beacon_freq_valid(). Data frames are not checked, so
traffic keeps flowing and only beacon loss builds up.

On the RTL8723BS I could not reproduce it, because there the update is a
no-op. rtw_sdio_rx_skb() copies the status into skb->cb before it calls
rtw_update_rx_freq_for_invalid() and never copies it back, so the change
is discarded. usb.c and pci.c call it before their memcpy into skb->cb,
which is why you see it on the RTL8723BU. With the SDIO path made to
apply it I got your symptom exactly (2452 instead of 2462, beacon rx 0,
beacon loss 26, while rtw88 still counted the beacons), and removing
channel_invalid put it back to 2462 with no beacon loss.

I will send a patch removing the assignment and the comment above it.

Best regards,
Luka Gejak