Re: [PATCH v5 rtw-next 2/7] wifi: rtw88: assign the RCR per chip in rtw_core_init

[Bitterblue Smith <rtl8821cerfe2@gmail.com>]

On 01/10/2026 00:29, Luka Gejak wrote:
> September 30, 2026 at 23:27, "Bitterblue Smith" <rtl8821cerfe2@gmail.com mailto:rtl8821cerfe2@gmail.com?to=%22Bitterblue%20Smith%22%20%3Crtl8821cerfe2%40gmail.com%3E > wrote:
> 
> 
>>
>> On 30/09/2026 23:36, Luka Gejak wrote:
>>
>>>
>>> September 30, 2026 at 20:03, "Bitterblue Smith" <rtl8821cerfe2@gmail.com mailto:rtl8821cerfe2@gmail.com?to=%22Bitterblue%20Smith%22%20%3Crtl8821cerfe2%40gmail.com%3E > wrote:
>>>  
>>>  
>>>
>>>>
>>>> On 30/09/2026 12:15, Luka Gejak wrote:
>>>>
>>>  The receive control word is the same for every chip today. The generic
>>>  default is written in rtw_core_init(), so a chip that needs a different
>>>  value has to overwrite it afterwards, in its own init path, far away
>>>  from where the default is decided.
>>>
>>>>
>>>> I still don't understand why RTL8723B(S) would need a different value.
>>>>
>>>  
>>>  Because 0x700060ce is what the vendor driver leaves in REG_RCR for this
>>>  chip, and it is what rtw8723x_mac_init() already writes for it. I have
>>>  both from tracing this card: a register dump at the end of
>>>  rtl8723bs_hal_init prints RCR=0x700060ce, and the same dump in rtw88
>>>  matched it field for field.
>>>  
>>>  The default is a different filter. It sets BIT_PKTCTL_DLEN, which the
>>>  8723B vendor HAL and rtlwifi's rtl8723be never set, and it clears
>>>  BIT_AMF, BIT_CBSSID_DATA and BIT_CBSSID_BCN, which the vendor value
>>>  sets. Four bits in total.
>>>
>> It will work fine...
>>
> 
> Want me to drop the patch?

Yes. If you check the vendor drivers for the other chips,
they're all in the same situation.

> 
>>>
>>> That value does not survive rtw_core_start(), which writes REG_RCR from
>>>  hal.rcr after power_on. The field is what keeps it. BIT_APP_FCS is the only
>>>  bit added on top, because rtw88 advertises RX_INCLUDES_FCS.
>>>  
>>>  Best regards,
>>>  Luka Gejak
>>>
>>