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

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

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?

> > 
> > 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
> >
>