Message ID | 20230417140358.2240429-1-s.hauer@pengutronix.de |
---|---|
Headers | show |
Series | RTW88 USB bug fixes | expand |
> -----Original Message----- > From: Sascha Hauer <s.hauer@pengutronix.de> > Sent: Monday, April 17, 2023 10:04 PM > To: linux-wireless <linux-wireless@vger.kernel.org> > Cc: Hans Ulli Kroll <linux@ulli-kroll.de>; Larry Finger <Larry.Finger@lwfinger.net>; Ping-Ke Shih > <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 > > 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 Reviewed-by: Ping-Ke Shih <pkshih@realtek.com> > --- > 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
> -----Original Message----- > From: Sascha Hauer <s.hauer@pengutronix.de> > Sent: Monday, April 17, 2023 10:04 PM > To: linux-wireless <linux-wireless@vger.kernel.org> > Cc: Hans Ulli Kroll <linux@ulli-kroll.de>; Larry Finger <Larry.Finger@lwfinger.net>; Ping-Ke Shih > <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> > Subject: [PATCH v3 4/4] wifi: rtw88: call rtw8821c_switch_rf_set() according to chip variant > > We have to call rtw8821c_switch_rf_set() with SWITCH_TO_WLG or > SWITCH_TO_BTG according to the chip variant as denoted in rfe_option. > The information which argument to use for which variant has been > taken from the vendor driver. > > Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de> Reviewed-by: Ping-Ke Shih <pkshih@realtek.com> [...]