On Sat, 2023-04-29 at 00:11 +0300, Bitterblue Smith wrote: > > On 28/04/2023 09:21, Ping-Ke Shih wrote: > > > > > -----Original Message----- > > > From: Bitterblue Smith <rtl8821cerfe2@xxxxxxxxx> > > > Sent: Wednesday, April 26, 2023 1:28 AM > > > To: linux-wireless@xxxxxxxxxxxxxxx > > > Cc: Jes Sorensen <Jes.Sorensen@xxxxxxxxx>; Ping-Ke Shih <pkshih@xxxxxxxxxxx> > > > Subject: [PATCH] wifi: rtl8xxxu: Support new chip RTL8192FU > > > > > > This is a newer chip, similar to the RTL8710BU in that it uses the same > > > PHY status structs. > > > > > > Features: 2.4 GHz, b/g/n mode, 2T2R, 300 Mbps. > > > > > > It can allegedly have Bluetooth, but that's not implemented here. > > > > > > This chip can have many RFE (RF front end) types, of which type 5 is > > > the only one tested. Many of the other types need different > > > initialisation tables. They can be added if someone wants them. > > > > > > The vendor driver v5.8.6.2_35538.20191028_COEX20190910-0d02 from > > > https://github.com/BrightX/rtl8192fu was used as reference. > > > > > > Signed-off-by: Bitterblue Smith <rtl8821cerfe2@xxxxxxxxx> > > > --- > > > drivers/net/wireless/realtek/rtl8xxxu/Kconfig | 3 +- > > > .../net/wireless/realtek/rtl8xxxu/rtl8xxxu.h | 47 + > > > .../realtek/rtl8xxxu/rtl8xxxu_8188f.c | 3 +- > > > .../realtek/rtl8xxxu/rtl8xxxu_8192f.c | 2081 +++++++++++++++++ > > > .../realtek/rtl8xxxu/rtl8xxxu_8710b.c | 1 + > > > .../realtek/rtl8xxxu/rtl8xxxu_8723b.c | 1 + > > > .../wireless/realtek/rtl8xxxu/rtl8xxxu_core.c | 104 +- > > > .../wireless/realtek/rtl8xxxu/rtl8xxxu_regs.h | 15 + > > > 8 files changed, 2225 insertions(+), 30 deletions(-) > > > create mode 100644 drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_8192f.c > > > > > > > [...] > > > > > +static void rtl8192fu_config_kfree(struct rtl8xxxu_priv *priv, u8 channel) > > > +{ > > > + u8 bb_gain[3] = { EFUSE_UNDEFINED, EFUSE_UNDEFINED, EFUSE_UNDEFINED }; > > > + u8 bb_gain_path_mask[2] = { 0x0f, 0xf0 }; > > > + enum rtl8xxxu_rfpath rfpath; > > > + u8 bb_gain_for_path; > > > + u8 channel_idx; > > > + > > > + if (channel >= 1 && channel <= 3) > > > + channel_idx = 0; > > > + if (channel >= 4 && channel <= 9) > > > + channel_idx = 1; > > > + if (channel >= 10 && channel <= 14) > > > + channel_idx = 2; > > > + > > > + rtl8xxxu_read_efuse8(priv, 0x1ee, &bb_gain[1]); > > > + rtl8xxxu_read_efuse8(priv, 0x1ec, &bb_gain[0]); > > > + rtl8xxxu_read_efuse8(priv, 0x1ea, &bb_gain[2]); > > > > Can you define these fields in struct rtl8192fu_efuse, and access via > > the struct? > > > > They are not in the efuse map. These are "physical" efuse addresses. > I don't know what that means, as I have not studied the efuse stuff. I miss the point. Then, your code is right. "physical" address is just as its name, no more explain. Otherwise, struct rtl8192fu_efuse is "logic" address that is translated from encoded data read from physical starting at 0x0. > I wonder about these: > > #define REG_IQK_RTP_TXA 0xe98 > #define REG_IQK_RTP_RXA 0xea8 > #define REG_IQK_RTP_TXB 0xeb8 > #define REG_IQK_RTP_RXB 0xec8 > > Should they be REG_IQK_RPT_... for "report"? Right, please correct them. > > And these: > > #define REG_REF_OPT62 0x968 > #define REG_REF_OPT 0x920 > > Should they be REG_RFE_... ? > Right, please correct them too. Sorry for the mistakes.
