Received-SPF: pass (google.com: domain of linux-wireless-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
MIME-Version: 1.0
References: <bc4cb44d-4c8a-f672-b82d-0ae601bb04ff@yandex.ru>
In-Reply-To: <bc4cb44d-4c8a-f672-b82d-0ae601bb04ff@yandex.ru>
From:   Jonas Gorski <jonas.gorski@gmail.com>
Date:   Tue, 27 Jun 2023 11:23:47 +0200
Message-ID: <CAOiHx=m8NUL_UwK2Gzv3hLeG_zqLw=f7+OZ=oQnkC8nAMz6Q+w@mail.gmail.com>
Subject: Re: On CORDIC arithmetic in b43
To:     Dmitry Antipov <dmantipov@yandex.ru>
Cc:     Larry Finger <Larry.Finger@lwfinger.net>,
        linux-wireless@vger.kernel.org
Content-Type: text/plain; charset="UTF-8"
Precedence: bulk

On Tue, 27 Jun 2023 at 10:40, Dmitry Antipov <dmantipov@yandex.ru> wrote:
>
> To everyone still interested in b43 driver:
>
> In 'lpphy_start_tx_tone()', how 'CORDIC_FLOAT((sample.i * max) & 0xFF)' may
> be non-zero? Basically it is (<32-bit> & 0xff) shifted right by 15 bits.

Looking at other users like e.g.
https://elixir.bootlin.com/linux/latest/source/drivers/net/wireless/broadcom/brcm80211/brcmsmac/phy/phy_lcn.c#L3377
the the result should be masked, and not the argument to
CORDIC_FLOAT().

So that very much looks like a bug and likely should be
'CORDIC_FLOAT(sample.i * max) & 0xFF' or so. Good catch!

Can you send a patch?

Best regards,
Jonas