[rt2x00-users] [RFC/RFT 4/4] rt2800: radio 3xxxx: channel switch RX/TX calibration fixes

Gertjan van Wingerde gwingerde at gmail.com
Thu Jan 26 02:50:32 AEDT 2012

On Wed, Jan 25, 2012 at 4:41 PM, Andreas Hartmann
<andihartmann at 01019freenet.de> wrote:
> Gertjan van Wingerde schrieb:
>> On Wed, Jan 25, 2012 at 2:43 PM, Stanislaw Gruszka <sgruszka at redhat.com> wrote:
>>> Hi Gertjan
>>> On Tue, Jan 24, 2012 at 10:55:40PM +0100, Gertjan van Wingerde wrote:
>>>> On 01/24/12 15:06, Stanislaw Gruszka wrote:
>>>>> Signed-off-by: Stanislaw Gruszka <sgruszka at redhat.com>
>>>> NAK. This doesn't seem to be correct for any chipset.
>>>> The change to the RFCSR24 programming is correct, but the RFCSR31
>>>> programming seems odd here, as the Ralink driver does not program
>>>> both RF CSRs with the same value, and on RT33xx it seems that fixed
>>>> values are programmed into these RF CSRs (although this is difficult to
>>>> determine due to the flow inside the Ralink driver.
>>>> On RT30xx I'm wondering why the Ralink driver is programming RFCSR31 at
>>>> all, as it doesn't seem to be programmed with any sane value (it is
>>>> taking the value of an uninitialized stack variable.
>>>> I would argue that RFCSR31 is only to be programmed for RT33xx, and that
>>>> the Ralink RT30xx code for this is just sloppy and doing unnecessary things.
>>>> Please double-check my analysis as the Ralink code for this is not very
>>>> accessible.
>>> Patch is kinda correct (except 3390), we program R31 and R24
>>> with the same values (calRFValue) on both chips/rt33xx.c and chips/rt30xx.c.
>>> Below is corresponding Ralink driver code.
>>> What needs to be fixed in my patch is 3390 case.
>> OK. You're right. I misread that piece of code and didn't see the
>> re-use of the previous read
>> (and manipulated) value of calRFValue (what a nasty piece of code is that :-()
> Well, I'm really happy to have this nasty code (subjective)! If I hadn't
> this code, I couldn't use my WUSB600Nv2 e.g.

Well, that remains to be seen, as that piece of code is not executed
for the RT3572
chipset. So, that piece of code is not executed at all for the WUSB600Nv2.

Also, nasty code doesn't mean incorrect, but only that it is difficult
to understand.


More information about the users mailing list