Most devices have a vendor name, product name, and serial number in the
efuse, but it's pretty useless. It duplicates the information already
printed by the USB subsystem:
usb 1-4: New USB device found, idVendor=0bda, idProduct=8178, bcdDevice= 2.00
usb 1-4: New USB device strings: Mfr=1, Product=2, SerialNumber=3
usb 1-4: Product: 802.11n WLAN Adapter
usb 1-4: Manufacturer: Realtek
usb 1-4: SerialNumber: 00e04c000001
-> usb 1-4: Vendor: Realtek
-> usb 1-4: Product: 802.11n WLAN Adapter
usb 1-4: New USB device found, idVendor=0bda, idProduct=818b, bcdDevice= 2.00
usb 1-4: New USB device strings: Mfr=1, Product=2, SerialNumber=3
usb 1-4: Product: 802.11n NIC
usb 1-4: Manufacturer: Realtek
usb 1-4: SerialNumber: 00e04c000001
-> usb 1-4: Vendor: Realtek
-> usb 1-4: Product: 802.11n NIC
-> usb 1-4: Serial not available.
usb 1-4: New USB device found, idVendor=0bda, idProduct=f179, bcdDevice= 0.00
usb 1-4: New USB device strings: Mfr=1, Product=2, SerialNumber=3
usb 1-4: Product: 802.11n
usb 1-4: Manufacturer: Realtek
usb 1-4: SerialNumber: 002E2DC0041F
-> usb 1-4: Vendor: Realtek
-> usb 1-4: Product: 802.11n
usb 1-4: New USB device found, idVendor=0bda, idProduct=8179, bcdDevice= 0.00
usb 1-4: New USB device strings: Mfr=1, Product=2, SerialNumber=3
usb 1-4: Product: 802.11n NIC
usb 1-4: Manufacturer: Realtek
usb 1-4: SerialNumber: 00E04C0001
-> usb 1-4: Vendor: Realtek
-> usb 1-4: Product: 802.11n NIC
-> usb 1-4: Serial: 00E04C0001
Also, that data is not interpreted correctly in all cases:
usb 3-1.1.2: New USB device found, idVendor=0bda, idProduct=8179, bcdDevice= 0.00
usb 3-1.1.2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
usb 3-1.1.2: Product: 802.11n NIC
usb 3-1.1.2: Manufacturer: Realtek
usb 3-1.1.2: Vendor: Realtek
usb 3-1.1.2: Product: \x03802.11n NI
usb 3-1.1.2: Serial: \xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff
Link: https://bugzilla.kernel.org/show_bug.cgi?id=217231
Signed-off-by: Bitterblue Smith <[email protected]>
---
.../realtek/rtl8xxxu/rtl8xxxu_8188e.c | 4 --
.../realtek/rtl8xxxu/rtl8xxxu_8188f.c | 3 --
.../realtek/rtl8xxxu/rtl8xxxu_8192c.c | 5 --
.../realtek/rtl8xxxu/rtl8xxxu_8192e.c | 54 -------------------
.../realtek/rtl8xxxu/rtl8xxxu_8723a.c | 4 --
.../realtek/rtl8xxxu/rtl8xxxu_8723b.c | 3 --
6 files changed, 73 deletions(-)
diff --git a/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_8188e.c b/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_8188e.c
index af8436070ba7..8986783ae8fa 100644
--- a/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_8188e.c
+++ b/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_8188e.c
@@ -568,10 +568,6 @@ static int rtl8188eu_parse_efuse(struct rtl8xxxu_priv *priv)
priv->default_crystal_cap = efuse->xtal_k & 0x3f;
- dev_info(&priv->udev->dev, "Vendor: %.7s\n", efuse->vendor_name);
- dev_info(&priv->udev->dev, "Product: %.11s\n", efuse->device_name);
- dev_info(&priv->udev->dev, "Serial: %.11s\n", efuse->serial);
-
return 0;
}
diff --git a/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_8188f.c b/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_8188f.c
index dfb250adb168..dbdfd7787465 100644
--- a/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_8188f.c
+++ b/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_8188f.c
@@ -734,9 +734,6 @@ static int rtl8188fu_parse_efuse(struct rtl8xxxu_priv *priv)
priv->default_crystal_cap = efuse->xtal_k & 0x3f;
- dev_info(&priv->udev->dev, "Vendor: %.7s\n", efuse->vendor_name);
- dev_info(&priv->udev->dev, "Product: %.7s\n", efuse->device_name);
-
return 0;
}
diff --git a/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_8192c.c b/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_8192c.c
index caeba56241fc..b30a9a513cb8 100644
--- a/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_8192c.c
+++ b/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_8192c.c
@@ -441,11 +441,6 @@ static int rtl8192cu_parse_efuse(struct rtl8xxxu_priv *priv)
efuse->ht20_max_power_offset,
sizeof(efuse->ht20_max_power_offset));
- dev_info(&priv->udev->dev, "Vendor: %.7s\n",
- efuse->vendor_name);
- dev_info(&priv->udev->dev, "Product: %.20s\n",
- efuse->device_name);
-
priv->power_base = &rtl8192c_power_base;
if (efuse->rf_regulatory & 0x20) {
diff --git a/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_8192e.c b/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_8192e.c
index 4498748164af..fcc2926ea938 100644
--- a/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_8192e.c
+++ b/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_8192e.c
@@ -601,43 +601,9 @@ rtl8192e_set_tx_power(struct rtl8xxxu_priv *priv, int channel, bool ht40)
}
}
-static void rtl8192eu_log_next_device_info(struct rtl8xxxu_priv *priv,
- char *record_name,
- char *device_info,
- unsigned int *record_offset)
-{
- char *record = device_info + *record_offset;
-
- /* A record is [ total length | 0x03 | value ] */
- unsigned char l = record[0];
-
- /*
- * The whole device info section seems to be 80 characters, make sure
- * we don't read further.
- */
- if (*record_offset + l > 80) {
- dev_warn(&priv->udev->dev,
- "invalid record length %d while parsing \"%s\" at offset %u.\n",
- l, record_name, *record_offset);
- return;
- }
-
- if (l >= 2) {
- char value[80];
-
- memcpy(value, &record[2], l - 2);
- value[l - 2] = '\0';
- dev_info(&priv->udev->dev, "%s: %s\n", record_name, value);
- *record_offset = *record_offset + l;
- } else {
- dev_info(&priv->udev->dev, "%s not available.\n", record_name);
- }
-}
-
static int rtl8192eu_parse_efuse(struct rtl8xxxu_priv *priv)
{
struct rtl8192eu_efuse *efuse = &priv->efuse_wifi.efuse8192eu;
- unsigned int record_offset;
int i;
if (efuse->rtl_id != cpu_to_le16(0x8129))
@@ -684,26 +650,6 @@ static int rtl8192eu_parse_efuse(struct rtl8xxxu_priv *priv)
priv->default_crystal_cap = priv->efuse_wifi.efuse8192eu.xtal_k & 0x3f;
- /*
- * device_info section seems to be laid out as records
- * [ total length | 0x03 | value ] so:
- * - vendor length + 2
- * - 0x03
- * - vendor string (not null terminated)
- * - product length + 2
- * - 0x03
- * - product string (not null terminated)
- * Then there is one or 2 0x00 on all the 4 devices I own or found
- * dumped online.
- * As previous version of the code handled an optional serial
- * string, I now assume there may be a third record if the
- * length is not 0.
- */
- record_offset = 0;
- rtl8192eu_log_next_device_info(priv, "Vendor", efuse->device_info, &record_offset);
- rtl8192eu_log_next_device_info(priv, "Product", efuse->device_info, &record_offset);
- rtl8192eu_log_next_device_info(priv, "Serial", efuse->device_info, &record_offset);
-
return 0;
}
diff --git a/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_8723a.c b/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_8723a.c
index d219be19d07f..15a30e496221 100644
--- a/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_8723a.c
+++ b/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_8723a.c
@@ -222,10 +222,6 @@ static int rtl8723au_parse_efuse(struct rtl8xxxu_priv *priv)
priv->power_base = &rtl8723a_power_base;
- dev_info(&priv->udev->dev, "Vendor: %.7s\n",
- efuse->vendor_name);
- dev_info(&priv->udev->dev, "Product: %.41s\n",
- efuse->device_name);
return 0;
}
diff --git a/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_8723b.c b/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_8723b.c
index c31c2b52ac77..abc56c7de6f7 100644
--- a/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_8723b.c
+++ b/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_8723b.c
@@ -494,9 +494,6 @@ static int rtl8723bu_parse_efuse(struct rtl8xxxu_priv *priv)
priv->default_crystal_cap = priv->efuse_wifi.efuse8723bu.xtal_k & 0x3f;
- dev_info(&priv->udev->dev, "Vendor: %.7s\n", efuse->vendor_name);
- dev_info(&priv->udev->dev, "Product: %.41s\n", efuse->device_name);
-
return 0;
}
--
2.39.2
Also add rtl8xxxu_write32_mask, rtl8xxxu_write_rfreg_mask.
These helper functions make it easier to modify only parts of a register
by eliminating the call to the register reading function and the bit
manipulations.
Signed-off-by: Bitterblue Smith <[email protected]>
---
.../net/wireless/realtek/rtl8xxxu/rtl8xxxu.h | 12 +++
.../wireless/realtek/rtl8xxxu/rtl8xxxu_core.c | 79 +++++++++++++++++++
2 files changed, 91 insertions(+)
diff --git a/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu.h b/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu.h
index 82a0290ccb29..8eafbf1cee71 100644
--- a/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu.h
+++ b/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu.h
@@ -1953,10 +1953,22 @@ u32 rtl8xxxu_read32(struct rtl8xxxu_priv *priv, u16 addr);
int rtl8xxxu_write8(struct rtl8xxxu_priv *priv, u16 addr, u8 val);
int rtl8xxxu_write16(struct rtl8xxxu_priv *priv, u16 addr, u16 val);
int rtl8xxxu_write32(struct rtl8xxxu_priv *priv, u16 addr, u32 val);
+int rtl8xxxu_write8_set(struct rtl8xxxu_priv *priv, u16 addr, u8 bits);
+int rtl8xxxu_write8_clear(struct rtl8xxxu_priv *priv, u16 addr, u8 bits);
+int rtl8xxxu_write16_set(struct rtl8xxxu_priv *priv, u16 addr, u16 bits);
+int rtl8xxxu_write16_clear(struct rtl8xxxu_priv *priv, u16 addr, u16 bits);
+int rtl8xxxu_write32_set(struct rtl8xxxu_priv *priv, u16 addr, u32 bits);
+int rtl8xxxu_write32_clear(struct rtl8xxxu_priv *priv, u16 addr, u32 bits);
+int rtl8xxxu_write32_mask(struct rtl8xxxu_priv *priv, u16 addr,
+ u32 mask, u32 val);
+
u32 rtl8xxxu_read_rfreg(struct rtl8xxxu_priv *priv,
enum rtl8xxxu_rfpath path, u8 reg);
int rtl8xxxu_write_rfreg(struct rtl8xxxu_priv *priv,
enum rtl8xxxu_rfpath path, u8 reg, u32 data);
+int rtl8xxxu_write_rfreg_mask(struct rtl8xxxu_priv *priv,
+ enum rtl8xxxu_rfpath path, u8 reg,
+ u32 mask, u32 val);
void rtl8xxxu_save_regs(struct rtl8xxxu_priv *priv, const u32 *regs,
u32 *backup, int count);
void rtl8xxxu_restore_regs(struct rtl8xxxu_priv *priv, const u32 *regs,
diff --git a/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c b/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c
index 6106b47d0c37..03c0aaa9141c 100644
--- a/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c
+++ b/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c
@@ -786,6 +786,85 @@ int rtl8xxxu_write32(struct rtl8xxxu_priv *priv, u16 addr, u32 val)
return ret;
}
+int rtl8xxxu_write8_set(struct rtl8xxxu_priv *priv, u16 addr, u8 bits)
+{
+ u8 val8;
+
+ val8 = rtl8xxxu_read8(priv, addr);
+ val8 |= bits;
+ return rtl8xxxu_write8(priv, addr, val8);
+}
+
+int rtl8xxxu_write8_clear(struct rtl8xxxu_priv *priv, u16 addr, u8 bits)
+{
+ u8 val8;
+
+ val8 = rtl8xxxu_read8(priv, addr);
+ val8 &= ~bits;
+ return rtl8xxxu_write8(priv, addr, val8);
+}
+
+int rtl8xxxu_write16_set(struct rtl8xxxu_priv *priv, u16 addr, u16 bits)
+{
+ u16 val16;
+
+ val16 = rtl8xxxu_read16(priv, addr);
+ val16 |= bits;
+ return rtl8xxxu_write16(priv, addr, val16);
+}
+
+int rtl8xxxu_write16_clear(struct rtl8xxxu_priv *priv, u16 addr, u16 bits)
+{
+ u16 val16;
+
+ val16 = rtl8xxxu_read16(priv, addr);
+ val16 &= ~bits;
+ return rtl8xxxu_write16(priv, addr, val16);
+}
+
+int rtl8xxxu_write32_set(struct rtl8xxxu_priv *priv, u16 addr, u32 bits)
+{
+ u32 val32;
+
+ val32 = rtl8xxxu_read32(priv, addr);
+ val32 |= bits;
+ return rtl8xxxu_write32(priv, addr, val32);
+}
+
+int rtl8xxxu_write32_clear(struct rtl8xxxu_priv *priv, u16 addr, u32 bits)
+{
+ u32 val32;
+
+ val32 = rtl8xxxu_read32(priv, addr);
+ val32 &= ~bits;
+ return rtl8xxxu_write32(priv, addr, val32);
+}
+
+int rtl8xxxu_write32_mask(struct rtl8xxxu_priv *priv, u16 addr,
+ u32 mask, u32 val)
+{
+ u32 orig, new, shift;
+
+ shift = __ffs(mask);
+
+ orig = rtl8xxxu_read32(priv, addr);
+ new = (orig & ~mask) | ((val << shift) & mask);
+ return rtl8xxxu_write32(priv, addr, new);
+}
+
+int rtl8xxxu_write_rfreg_mask(struct rtl8xxxu_priv *priv,
+ enum rtl8xxxu_rfpath path, u8 reg,
+ u32 mask, u32 val)
+{
+ u32 orig, new, shift;
+
+ shift = __ffs(mask);
+
+ orig = rtl8xxxu_read_rfreg(priv, path, reg);
+ new = (orig & ~mask) | ((val << shift) & mask);
+ return rtl8xxxu_write_rfreg(priv, path, reg, new);
+}
+
static int
rtl8xxxu_writeN(struct rtl8xxxu_priv *priv, u16 addr, u8 *buf, u16 len)
{
--
2.39.2
The goal of writing 0x6954341e / 0x6955341e to REG_OFDM0_XA_AGC_CORE1
appears to be setting the initial gain, which is stored in bits 0..6.
Bits 7..31 are the same as what the phy init tables write.
Modify only bits 0..6 so that we don't have to care about the values
of the others. This way we don't have to add another "else if" for the
RTL8192FU.
Why we need to change the initial gain from the default 0x20 to 0x1e?
Not sure. Some of the vendor drivers change it to 0x1e before scanning
and then restore it to the original value after.
Signed-off-by: Bitterblue Smith <[email protected]>
---
drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c | 6 ++----
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c b/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c
index 03c0aaa9141c..fd8c8c6d53d6 100644
--- a/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c
+++ b/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c
@@ -7034,10 +7034,8 @@ static int rtl8xxxu_start(struct ieee80211_hw *hw)
rtl8xxxu_write16(priv, REG_RXFLTMAP2, 0xffff);
rtl8xxxu_write16(priv, REG_RXFLTMAP0, 0xffff);
- if (priv->rtl_chip == RTL8188E)
- rtl8xxxu_write32(priv, REG_OFDM0_XA_AGC_CORE1, 0x6955341e);
- else
- rtl8xxxu_write32(priv, REG_OFDM0_XA_AGC_CORE1, 0x6954341e);
+ rtl8xxxu_write32_mask(priv, REG_OFDM0_XA_AGC_CORE1,
+ OFDM0_X_AGC_CORE1_IGI_MASK, 0x1e);
return ret;
--
2.39.2
> -----Original Message-----
> From: Bitterblue Smith <[email protected]>
> Sent: Tuesday, April 18, 2023 1:07 AM
> To: [email protected]
> Cc: Jes Sorensen <[email protected]>; Ping-Ke Shih <[email protected]>
> Subject: [PATCH 2/3] wifi: rtl8xxxu: Add rtl8xxxu_write{8,16,32}_{set,clear}
>
> Also add rtl8xxxu_write32_mask, rtl8xxxu_write_rfreg_mask.
>
> These helper functions make it easier to modify only parts of a register
> by eliminating the call to the register reading function and the bit
> manipulations.
>
> Signed-off-by: Bitterblue Smith <[email protected]>
Reviewed-by: Ping-Ke Shih <[email protected]>
[...]
> -----Original Message-----
> From: Bitterblue Smith <[email protected]>
> Sent: Tuesday, April 18, 2023 1:06 AM
> To: [email protected]
> Cc: Jes Sorensen <[email protected]>; Ping-Ke Shih <[email protected]>
> Subject: [PATCH 1/3] wifi: rtl8xxxu: Don't print the vendor/product/serial
>
> Most devices have a vendor name, product name, and serial number in the
> efuse, but it's pretty useless. It duplicates the information already
> printed by the USB subsystem:
>
> usb 1-4: New USB device found, idVendor=0bda, idProduct=8178, bcdDevice= 2.00
> usb 1-4: New USB device strings: Mfr=1, Product=2, SerialNumber=3
> usb 1-4: Product: 802.11n WLAN Adapter
> usb 1-4: Manufacturer: Realtek
> usb 1-4: SerialNumber: 00e04c000001
> -> usb 1-4: Vendor: Realtek
> -> usb 1-4: Product: 802.11n WLAN Adapter
>
> usb 1-4: New USB device found, idVendor=0bda, idProduct=818b, bcdDevice= 2.00
> usb 1-4: New USB device strings: Mfr=1, Product=2, SerialNumber=3
> usb 1-4: Product: 802.11n NIC
> usb 1-4: Manufacturer: Realtek
> usb 1-4: SerialNumber: 00e04c000001
> -> usb 1-4: Vendor: Realtek
> -> usb 1-4: Product: 802.11n NIC
> -> usb 1-4: Serial not available.
>
> usb 1-4: New USB device found, idVendor=0bda, idProduct=f179, bcdDevice= 0.00
> usb 1-4: New USB device strings: Mfr=1, Product=2, SerialNumber=3
> usb 1-4: Product: 802.11n
> usb 1-4: Manufacturer: Realtek
> usb 1-4: SerialNumber: 002E2DC0041F
> -> usb 1-4: Vendor: Realtek
> -> usb 1-4: Product: 802.11n
>
> usb 1-4: New USB device found, idVendor=0bda, idProduct=8179, bcdDevice= 0.00
> usb 1-4: New USB device strings: Mfr=1, Product=2, SerialNumber=3
> usb 1-4: Product: 802.11n NIC
> usb 1-4: Manufacturer: Realtek
> usb 1-4: SerialNumber: 00E04C0001
> -> usb 1-4: Vendor: Realtek
> -> usb 1-4: Product: 802.11n NIC
> -> usb 1-4: Serial: 00E04C0001
>
> Also, that data is not interpreted correctly in all cases:
>
> usb 3-1.1.2: New USB device found, idVendor=0bda, idProduct=8179, bcdDevice= 0.00
> usb 3-1.1.2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
> usb 3-1.1.2: Product: 802.11n NIC
> usb 3-1.1.2: Manufacturer: Realtek
> usb 3-1.1.2: Vendor: Realtek
> usb 3-1.1.2: Product: \x03802.11n NI
> usb 3-1.1.2: Serial: \xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff
>
> Link: https://bugzilla.kernel.org/show_bug.cgi?id=217231
> Signed-off-by: Bitterblue Smith <[email protected]>
Reviewed-by: Ping-Ke Shih <[email protected]>
[...]
> -----Original Message-----
> From: Bitterblue Smith <[email protected]>
> Sent: Tuesday, April 18, 2023 1:08 AM
> To: [email protected]
> Cc: Jes Sorensen <[email protected]>; Ping-Ke Shih <[email protected]>
> Subject: [PATCH 3/3] wifi: rtl8xxxu: Simplify setting the initial gain
>
> The goal of writing 0x6954341e / 0x6955341e to REG_OFDM0_XA_AGC_CORE1
> appears to be setting the initial gain, which is stored in bits 0..6.
> Bits 7..31 are the same as what the phy init tables write.
>
> Modify only bits 0..6 so that we don't have to care about the values
> of the others. This way we don't have to add another "else if" for the
> RTL8192FU.
>
> Why we need to change the initial gain from the default 0x20 to 0x1e?
> Not sure. Some of the vendor drivers change it to 0x1e before scanning
> and then restore it to the original value after.
When WiFi gets connected, it will try to adjust initial gain for target AP.
If we scan in this situation, change it to 0x1e to have better coverage to
find APs.
>
> Signed-off-by: Bitterblue Smith <[email protected]>
Reviewed-by: Ping-Ke Shih <[email protected]>
> ---
> drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c | 6 ++----
> 1 file changed, 2 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c
> b/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c
> index 03c0aaa9141c..fd8c8c6d53d6 100644
> --- a/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c
> +++ b/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c
> @@ -7034,10 +7034,8 @@ static int rtl8xxxu_start(struct ieee80211_hw *hw)
> rtl8xxxu_write16(priv, REG_RXFLTMAP2, 0xffff);
> rtl8xxxu_write16(priv, REG_RXFLTMAP0, 0xffff);
>
> - if (priv->rtl_chip == RTL8188E)
> - rtl8xxxu_write32(priv, REG_OFDM0_XA_AGC_CORE1, 0x6955341e);
> - else
> - rtl8xxxu_write32(priv, REG_OFDM0_XA_AGC_CORE1, 0x6954341e);
> + rtl8xxxu_write32_mask(priv, REG_OFDM0_XA_AGC_CORE1,
> + OFDM0_X_AGC_CORE1_IGI_MASK, 0x1e);
>
> return ret;
>
> --
> 2.39.2
>
> ------Please consider the environment before printing this e-mail.
On 18/04/2023 04:13, Ping-Ke Shih wrote:
>
>
>> -----Original Message-----
>> From: Bitterblue Smith <[email protected]>
>> Sent: Tuesday, April 18, 2023 1:08 AM
>> To: [email protected]
>> Cc: Jes Sorensen <[email protected]>; Ping-Ke Shih <[email protected]>
>> Subject: [PATCH 3/3] wifi: rtl8xxxu: Simplify setting the initial gain
>>
>> The goal of writing 0x6954341e / 0x6955341e to REG_OFDM0_XA_AGC_CORE1
>> appears to be setting the initial gain, which is stored in bits 0..6.
>> Bits 7..31 are the same as what the phy init tables write.
>>
>> Modify only bits 0..6 so that we don't have to care about the values
>> of the others. This way we don't have to add another "else if" for the
>> RTL8192FU.
>>
>> Why we need to change the initial gain from the default 0x20 to 0x1e?
>> Not sure. Some of the vendor drivers change it to 0x1e before scanning
>> and then restore it to the original value after.
>
> When WiFi gets connected, it will try to adjust initial gain for target AP.
> If we scan in this situation, change it to 0x1e to have better coverage to
> find APs.
>
I see. I'll remember that if I implement the dynamic initial gain.
Bitterblue Smith <[email protected]> wrote:
> Most devices have a vendor name, product name, and serial number in the
> efuse, but it's pretty useless. It duplicates the information already
> printed by the USB subsystem:
>
> usb 1-4: New USB device found, idVendor=0bda, idProduct=8178, bcdDevice= 2.00
> usb 1-4: New USB device strings: Mfr=1, Product=2, SerialNumber=3
> usb 1-4: Product: 802.11n WLAN Adapter
> usb 1-4: Manufacturer: Realtek
> usb 1-4: SerialNumber: 00e04c000001
> -> usb 1-4: Vendor: Realtek
> -> usb 1-4: Product: 802.11n WLAN Adapter
>
> usb 1-4: New USB device found, idVendor=0bda, idProduct=818b, bcdDevice= 2.00
> usb 1-4: New USB device strings: Mfr=1, Product=2, SerialNumber=3
> usb 1-4: Product: 802.11n NIC
> usb 1-4: Manufacturer: Realtek
> usb 1-4: SerialNumber: 00e04c000001
> -> usb 1-4: Vendor: Realtek
> -> usb 1-4: Product: 802.11n NIC
> -> usb 1-4: Serial not available.
>
> usb 1-4: New USB device found, idVendor=0bda, idProduct=f179, bcdDevice= 0.00
> usb 1-4: New USB device strings: Mfr=1, Product=2, SerialNumber=3
> usb 1-4: Product: 802.11n
> usb 1-4: Manufacturer: Realtek
> usb 1-4: SerialNumber: 002E2DC0041F
> -> usb 1-4: Vendor: Realtek
> -> usb 1-4: Product: 802.11n
>
> usb 1-4: New USB device found, idVendor=0bda, idProduct=8179, bcdDevice= 0.00
> usb 1-4: New USB device strings: Mfr=1, Product=2, SerialNumber=3
> usb 1-4: Product: 802.11n NIC
> usb 1-4: Manufacturer: Realtek
> usb 1-4: SerialNumber: 00E04C0001
> -> usb 1-4: Vendor: Realtek
> -> usb 1-4: Product: 802.11n NIC
> -> usb 1-4: Serial: 00E04C0001
>
> Also, that data is not interpreted correctly in all cases:
>
> usb 3-1.1.2: New USB device found, idVendor=0bda, idProduct=8179, bcdDevice= 0.00
> usb 3-1.1.2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
> usb 3-1.1.2: Product: 802.11n NIC
> usb 3-1.1.2: Manufacturer: Realtek
> usb 3-1.1.2: Vendor: Realtek
> usb 3-1.1.2: Product: \x03802.11n NI
> usb 3-1.1.2: Serial: \xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff
>
> Link: https://bugzilla.kernel.org/show_bug.cgi?id=217231
> Signed-off-by: Bitterblue Smith <[email protected]>
> Reviewed-by: Ping-Ke Shih <[email protected]>
3 patches applied to wireless-next.git, thanks.
af8678e6c5bd wifi: rtl8xxxu: Don't print the vendor/product/serial
cd85c8b059c5 wifi: rtl8xxxu: Add rtl8xxxu_write{8,16,32}_{set,clear}
c8bc37602779 wifi: rtl8xxxu: Simplify setting the initial gain
--
https://patchwork.kernel.org/project/linux-wireless/patch/[email protected]/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches