Re: [RFC PATCH] wifi: rt2x00: use VCO_IC 0x2 for RF3053 on 2.4 GHz

[Jie Feng]

On Wed, 14 Oct 2026 at 16:31, Stanislaw Gruszka <stf_xl@xxxxx> wrote:
> > > > RFC for this since I am not sure if it is a generic fix, since the
> > > > vendor driver also doesn't use VCO_IC=0x2.
>
> I looked at vendor driver it does not set VCO_IC=0x2 when switch
> a channel. However it does it after wake up from suspend:
> https://github.com/ashaffer/rt3573sta/blob/09b80e6290769c53736dc09c5ae9025e15bfbe69/chips/rt3593.c#L194
>
> This function: RT3593ReverseRFSleepModeSetup seams to be partially
> the same what NICInitRT3593RFRegisters does.
>
> Also NICInitRT3593RFRegisters it's different from
> rt2800_init_rfcsr_3593() i.e. it set RF_R02 before GPIO_SWITCH.
>
> Could you check if modifying rt2800_init_rfcsr_3593()
> to be more the same with both NICInitRT3593RFRegistersr and
> RT3593ReverseRFSleepModeSetup (regarding RF_R06 change)
> solve the problem?
It didn't solve the problem.

> > The adapter doesn't work on the lower channels in 2.4GHz,
> > channels 8 and below. This looked like an issue with
> > the PLL or something after debugging.
> >
> > By tuning to channels 1-12 and using the debugfs to dump the
> > RFCSR registers, RFCSR4 is always 0x7f on the failing channels
> > consistently. Since there is code to switch RFCSR6 based on
> > channel, I tried the same as the 5GHz code to switch RFCSR6=0x2
> > for lower channels and it worked on all the channels surprisingly.
> >
> > Due to the behaviour of RFCSR4, I think it is a VCO calibration
> > result since it seems to change after enabling the calibration.
> >
> > I could not find any mention of this issue elsewhere, and suspect
> > either this hardware has very few Linux users or my hardware
> > is special in some way, so I can't guarantee that setting
> > it to 0x2 will work with another device even if it is the
> > same WNDA4100 model and chipset, so some testing would
> > be appreciated.
> I do not have RT3573/RT3593 device by myself and ordinary users
> do not read linux-wireless mailing list, so we have rather little
> chance to get more test coverage here.
>
> Anyways, if init change that would make rt2800_init_rfcsr_3593()
> more like vendor driver do not fix the problem, it's ok to modify
> rt2800_config_channel_rf3053().
>
> If we want to be more safe with the change, we can limit it with
> rt2x00_rt_rev() using 'rev' of your tested device.
My concern is that it is just my specific device being at fault here.
It also seems to have an issue where the TX looks to be much weaker
than normal.