All of lore.kernel.org
 help / color / mirror / Atom feed
From: Sascha Hauer <s.hauer@pengutronix.de>
To: linux-wireless <linux-wireless@vger.kernel.org>
Cc: Hans Ulli Kroll <linux@ulli-kroll.de>,
	Larry Finger <Larry.Finger@lwfinger.net>,
	Pkshih <pkshih@realtek.com>, Tim K <tpkuester@gmail.com>,
	"Alex G ." <mr.nuke.me@gmail.com>,
	Nick Morrow <morrownr@gmail.com>,
	Viktor Petrenko <g0000ga@gmail.com>,
	Andreas Henriksson <andreas@fatal.se>,
	ValdikSS <iam@valdikss.org.ru>,
	kernel@pengutronix.de, Sascha Hauer <s.hauer@pengutronix.de>,
	stable@vger.kernel.org
Subject: [PATCH v3 2/4] wifi: rtw88: rtw8821c: Fix rfe_option field width
Date: Mon, 17 Apr 2023 16:03:56 +0200	[thread overview]
Message-ID: <20230417140358.2240429-3-s.hauer@pengutronix.de> (raw)
In-Reply-To: <20230417140358.2240429-1-s.hauer@pengutronix.de>

On my RTW8821CU chipset rfe_option reads as 0x22. Looking at the
vendor driver suggests that the field width of rfe_option is 5 bit,
so rfe_option should be masked with 0x1f.

Without this the rfe_option comparisons with 2 further down the
driver evaluate as false when they should really evaluate as true.
The effect is that 2G channels do not work.

rfe_option is also used as an array index into rtw8821c_rfe_defs[].
rtw8821c_rfe_defs[34] (0x22) was added as part of adding USB support,
likely because rfe_option reads as 0x22. As this now becomes 0x2,
rtw8821c_rfe_defs[34] is no longer used and can be removed.

Note that this might not be the whole truth. In the vendor driver
there are indeed places where the unmasked rfe_option value is used.
However, the driver has several places where rfe_option is tested
with the pattern if (rfe_option == 2 || rfe_option == 0x22) or
if (rfe_option == 4 || rfe_option == 0x24), so that rfe_option BIT(5)
has no influence on the code path taken. We therefore mask BIT(5)
out from rfe_option entirely until this assumption is proved wrong
by some chip variant we do not know yet.

Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
Tested-by: Alexandru gagniuc <mr.nuke.me@gmail.com>
Tested-by: Larry Finger <Larry.Finger@lwfinger.net>
Tested-by: ValdikSS <iam@valdikss.org.ru>
Cc: stable@vger.kernel.org
---
 drivers/net/wireless/realtek/rtw88/rtw8821c.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/drivers/net/wireless/realtek/rtw88/rtw8821c.c b/drivers/net/wireless/realtek/rtw88/rtw8821c.c
index 17f800f6efbd0..67efa58dd78ee 100644
--- a/drivers/net/wireless/realtek/rtw88/rtw8821c.c
+++ b/drivers/net/wireless/realtek/rtw88/rtw8821c.c
@@ -47,7 +47,7 @@ static int rtw8821c_read_efuse(struct rtw_dev *rtwdev, u8 *log_map)
 
 	map = (struct rtw8821c_efuse *)log_map;
 
-	efuse->rfe_option = map->rfe_option;
+	efuse->rfe_option = map->rfe_option & 0x1f;
 	efuse->rf_board_option = map->rf_board_option;
 	efuse->crystal_cap = map->xtal_k;
 	efuse->pa_type_2g = map->pa_type;
@@ -1537,7 +1537,6 @@ static const struct rtw_rfe_def rtw8821c_rfe_defs[] = {
 	[2] = RTW_DEF_RFE_EXT(8821c, 0, 0, 2),
 	[4] = RTW_DEF_RFE_EXT(8821c, 0, 0, 2),
 	[6] = RTW_DEF_RFE(8821c, 0, 0),
-	[34] = RTW_DEF_RFE(8821c, 0, 0),
 };
 
 static struct rtw_hw_reg rtw8821c_dig[] = {
-- 
2.39.2


  parent reply	other threads:[~2023-04-17 14:04 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-04-17 14:03 [PATCH v3 0/4] RTW88 USB bug fixes Sascha Hauer
2023-04-17 14:03 ` [PATCH v3 1/4] wifi: rtw88: usb: fix priority queue to endpoint mapping Sascha Hauer
2023-04-18  0:32   ` Ping-Ke Shih
2023-04-20 12:34   ` Kalle Valo
2023-04-17 14:03 ` Sascha Hauer [this message]
2023-04-18  0:32   ` [PATCH v3 2/4] wifi: rtw88: rtw8821c: Fix rfe_option field width Ping-Ke Shih
2023-04-17 14:03 ` [PATCH v3 3/4] wifi: rtw88: set pkg_type correctly for specific rtw8821c variants Sascha Hauer
2023-04-18  0:36   ` Ping-Ke Shih
2023-04-18  8:58     ` Sascha Hauer
2023-04-19  0:20       ` Ping-Ke Shih
2023-04-19  7:21         ` Sascha Hauer
2023-04-17 14:03 ` [PATCH v3 4/4] wifi: rtw88: call rtw8821c_switch_rf_set() according to chip variant Sascha Hauer
2023-04-18  0:37   ` Ping-Ke Shih

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20230417140358.2240429-3-s.hauer@pengutronix.de \
    --to=s.hauer@pengutronix.de \
    --cc=Larry.Finger@lwfinger.net \
    --cc=andreas@fatal.se \
    --cc=g0000ga@gmail.com \
    --cc=iam@valdikss.org.ru \
    --cc=kernel@pengutronix.de \
    --cc=linux-wireless@vger.kernel.org \
    --cc=linux@ulli-kroll.de \
    --cc=morrownr@gmail.com \
    --cc=mr.nuke.me@gmail.com \
    --cc=pkshih@realtek.com \
    --cc=stable@vger.kernel.org \
    --cc=tpkuester@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.