RE: [PATCH] rtlwifi: rtl8188ee: drop RTX_POWER_BEFORE_IQK_A and RTX_POWER_AFTER_IQK_A reads

[Ping-Ke Shih <pkshih@realtek.com>]

> -----Original Message-----
> From: Larry Finger <larry.finger@gmail.com> On Behalf Of Larry Finger
> Sent: Wednesday, May 31, 2023 2:55 AM
> To: Dmitry Antipov <dmantipov@yandex.ru>; Ping-Ke Shih <pkshih@realtek.com>
> Cc: Kalle Valo <kvalo@kernel.org>; linux-wireless@vger.kernel.org; lvc-project@linuxtesting.org; Dmitriy
> Antipov <Dmitriy.Antipov@softline.com>
> Subject: Re: [PATCH] rtlwifi: rtl8188ee: drop RTX_POWER_BEFORE_IQK_A and RTX_POWER_AFTER_IQK_A reads
> 
> On 5/30/23 13:26, Dmitry Antipov wrote:
> > On 5/30/23 20:42, Larry Finger wrote:
> >
> >> I do not know the answer to this question either, but how does
> >> your tool know that the statements between the first read and
> >> the second have not caused the firmware to change the contents > of the BB
> >> registers?
> >
> > This tool is a static analysis software and has no special knowledge
> > about any particular hardware. So I do not strongly insist on this
> > change which should be treated as a subject to more detailed consideration.
> >
> > I've noticed 6c75eab0417b9e5b05a18dbfc373e27a8ef876d8 where rtl_get_bbreg()
> > is preserved but the result is ignored. Would the similar thing be a kind
> > of a cleanup for this case as well?
> >
> 
> Yes, you could ignore the output from rtl_get_bbreg() for lines 1484 and 1485.
> 

Another way is to add a debug message to show them, and then static checker
shouldn't warn this. Also, people can diagnose IQK & LOK results if needed. 

--- a/drivers/net/wireless/realtek/rtlwifi/rtl8188ee/phy.c
+++ b/drivers/net/wireless/realtek/rtlwifi/rtl8188ee/phy.c
@@ -1479,6 +1479,10 @@ static u8 _rtl88e_phy_path_a_rx_iqk(struct ieee80211_hw *hw, bool config_pathb)
        reg_e9c = rtl_get_bbreg(hw, RTX_POWER_AFTER_IQK_A, MASKDWORD);
        reg_ea4 = rtl_get_bbreg(hw, RRX_POWER_BEFORE_IQK_A_2, MASKDWORD);

+       rtl_dbg(rtlpriv, COMP_IQK, DBG_LOUD,
+               "Path A Rx LOK & IQK results 0xeac=0x%x 0xe94=0x%x 0xe9c=0x%x 0xea4=0x%x\n",
+               reg_eac, reg_e94, reg_e9c, reg_ea4);
+
        if (!(reg_eac & BIT(27)) &&
            (((reg_ea4 & 0x03FF0000) >> 16) != 0x132) &&
            (((reg_eac & 0x03FF0000) >> 16) != 0x36))

Ping-Ke