[PATCH 2/2] [iwinfo] devices: add device id for Realtek RTL8188CU and RTL8188FTV

2024-03-10 Thread Shiji Yang 
From: Shiji Yang 

Add device ids for Realtek RTL8188CU and RTL8188FTV 802.11n 1x1 USB
Wi-Fi adapter.

Signed-off-by: Shiji Yang 
---
 devices.txt | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/devices.txt b/devices.txt
index 71f73d5..eded184 100644
--- a/devices.txt
+++ b/devices.txt
@@ -238,6 +238,9 @@
 # mt7615/usb.c
 0x 0x 0x0e8d 0x76630  0  "MediaTek" "MT7663U"
 0x 0x 0x043e 0x310c0  0  "LG" "LGSBWAC02"
+# rtl8xxxu/rtl8xxxu_core.c
+0x 0x 0x0bda 0x81760  0  "Realtek" "RTL8188CU"
+0x 0x 0x0bda 0xf1790  0  "Realtek" "RTL8188FTV"
 
 # FDT compatible strings
 # "compatible" | txpower offset | frequency offset | ...
-- 
2.44.0


___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

[PATCH 1/2] [iwinfo] devices: add device id for MediaTek MT7601U

2024-03-10 Thread Shiji Yang 
From: Shiji Yang 

Add device id for MediaTek MT7601U 802.11n 1x1 USB Wi-Fi adapter.

Signed-off-by: Shiji Yang 
---
 devices.txt | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/devices.txt b/devices.txt
index 5c35cb5..71f73d5 100644
--- a/devices.txt
+++ b/devices.txt
@@ -195,6 +195,8 @@
 
 # USB devices
 # 0x | 0x | vendor id | product id | ...
+# mt7601u/usb.c
+0x 0x 0x148f 0x76010  0  "MediaTek" "MT7601U"
 # mt7921/usb.c
 0x 0x 0x0e8d 0x79610  0  "MediaTek" "MT7921AU"
 # mt76x2/usb.c
-- 
2.44.0


___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [PATCH] kernel: of: add DT MAC address bitwise operation support

2023-11-10 Thread Shiji Yang 
On Nov. 10, 2023, 9:46 a.m., Rafał Miłecki wrote:

>On 2023-11-10 10:41, Shiji Yang wrote:
>> From: Shiji Yang 
>> 
>> This patch allow user to perform basic bitwise clear/set operation on
>> OF DT MAC address. We use two new added dt-bindings to specific the
>> MAC address bits clear/set mask. "mac-address-bitwise-set" can be used
>> to set bit. And "mac-address-bitwise-clear" can be used to clear bit.
>
>I'd like this binding to be documented and send upstream for a review.
>
>I know 804-nvmem-core-support-mac-base-fixed-layout-cells.patch is still
>not upstreamed and I'm not proud of it (I'm waiting for upstream NVMEM
>layouts reword). Still we have an /official/ "mac-base" binding at
>least. I'd be nice to have DT guys opinion on binding like this.
>
>-- 
>Rafał Miłecki

Hi!

Thanks for your reply. I'll try to rework and send it upstream when
I have time. Feel free to remove this patch from the patchwork.

Regards,
Shiji Yang

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

[PATCH] kernel: of: add DT MAC address bitwise operation support

2023-11-10 Thread Shiji Yang 
From: Shiji Yang 

This patch allow user to perform basic bitwise clear/set operation on
OF DT MAC address. We use two new added dt-bindings to specific the
MAC address bits clear/set mask. "mac-address-bitwise-set" can be used
to set bit. And "mac-address-bitwise-clear" can be used to clear bit.

Signed-off-by: Shiji Yang 
---

Hi!
This patch can benefit a lot of devices.

Git grep ref:

macaddr_setbit_la
https://git.openwrt.org/?p=openwrt%2Fopenwrt.git=search=HEAD=grep=macaddr_setbit_la=1

macaddr_setbit
https://git.openwrt.org/?p=openwrt%2Fopenwrt.git=search=HEAD=grep=macaddr_setbit=1

macaddr_unsetbit
https://git.openwrt.org/?p=openwrt%2Fopenwrt.git=search=HEAD=grep=macaddr_unsetbit=1

If this hack/idea is unacceptable, please let me know. Thanks!

Regards,
Shiji Yang


 ...-cell-MAC-address-bitwise-operation-.patch | 101 ++
 ...-cell-MAC-address-bitwise-operation-.patch | 101 ++
 2 files changed, 202 insertions(+)
 create mode 100644 
target/linux/generic/hack-5.15/686-of-net-add-NVMEM-cell-MAC-address-bitwise-operation-.patch
 create mode 100644 
target/linux/generic/hack-6.1/686-of-net-add-NVMEM-cell-MAC-address-bitwise-operation-.patch

diff --git 
a/target/linux/generic/hack-5.15/686-of-net-add-NVMEM-cell-MAC-address-bitwise-operation-.patch
 
b/target/linux/generic/hack-5.15/686-of-net-add-NVMEM-cell-MAC-address-bitwise-operation-.patch
new file mode 100644
index 00..396eed8f4a
--- /dev/null
+++ 
b/target/linux/generic/hack-5.15/686-of-net-add-NVMEM-cell-MAC-address-bitwise-operation-.patch
@@ -0,0 +1,101 @@
+From: Shiji Yang 
+Date: Sun, 16 Jul 2023 21:00:15 +0800
+Subject: [PATCH] of: net: add DT MAC address bitwise operation support
+
+This patch allow user to perform basic bitwise clear/set operation on
+OF DT MAC address. We use two new added dt-bindings to specific the
+MAC address bits clear/set mask. "mac-address-bitwise-set" can be used
+to set bit. And "mac-address-bitwise-clear" can be used to clear bit.
+
+The "mac-address-bitwise-*" property consists of two 32-bit(4 Bytes)
+hexadecimal. The first hex number mask the Byte[1-2] and the second
+one mask the Byte[3-6]. Each MAC address bit corresponds to the unique
+mask bit. When setting mask bit to "1", OF driver will clear/set the
+corresponding MAC address bit.
+
+Sample MAC Address and Property Mask:
+AA: BB : CC : DD : EE : FF  -->  mask:  <0xAABB 0xCCDDEEFF>
+^ ^  ^
+Byte[1]   Byte[3]Byte[6]
+
+Usage Example:
+Assuming the base MAC address is "00:11:22:33:44:55", and we have dts
+as follows. then the final MAC address should be "ff:11:22:33:44:66".
+
+0xff1122334466 = 0x001122334455 & (~0x00ff) | 0xff66
+
+ {
+   nvmem-cells = <_base>;
+   nvmem-cell-names = "mac-address";
+   mac-address-bitwise-clear = <0x 0x00ff>;
+   mac-address-bitwise-set = <0xff00 0x0066>;
+};
+
+Signed-off-by: Shiji Yang 
+---
+ net/core/of_net.c | 35 +++
+ 1 file changed, 19 insertions(+), 16 deletions(-)
+
+--- a/net/core/of_net.c
 b/net/core/of_net.c
+@@ -154,17 +154,10 @@ free:
+ */
+ int of_get_mac_address(struct device_node *np, u8 *addr)
+ {
+-  u32 inc_idx, mac_inc, mac_val;
++  u32 inc_idx, mac_inc;
++  u64 mac_val, mac_msk;
+   int ret;
+ 
+-  /* Check first if the increment byte is present and valid.
+-   * If not set assume to increment the last byte if found.
+-   */
+-  if (of_property_read_u32(np, "mac-address-increment-byte", _idx))
+-  inc_idx = 5;
+-  if (inc_idx < 3 || inc_idx > 5)
+-  return -EINVAL;
+-
+   if (!np)
+   return -ENODEV;
+ 
+@@ -185,16 +178,24 @@ int of_get_mac_address(struct device_nod
+   return ret;
+ 
+ found:
++  mac_val = ether_addr_to_u64(addr);
++
++  if (!of_property_read_u64(np, "mac-address-bitwise-clear", _msk))
++  mac_val &= ~mac_msk;
++
++  if (!of_property_read_u64(np, "mac-address-bitwise-set", _msk))
++  mac_val |= mac_msk;
++
+   if (!of_property_read_u32(np, "mac-address-increment", _inc)) {
+-  /* Convert to a contiguous value */
+-  mac_val = (addr[3] << 16) + (addr[4] << 8) + addr[5];
++  /* Check first if the increment byte is present and valid.
++   * If not set assume to increment the last byte if found.
++   */
++  if (of_property_read_u32(np, "mac-address-increment-byte", 
_idx))
++  inc_idx = 5;
++  if (inc_idx < 3 || inc_idx > 5)
++  return -EINVAL;
+   mac_val += mac_inc << 8 * (5-inc_idx);
+ 
+-  /* Apply the incremented value handling overflow case */
+-

[PATCH] kernel: of: remove "mac-address-ascii" support hack

2023-11-10 Thread Shiji Yang 
From: Shiji Yang 

ASCII MAC address can be handled by nvmem "fixed-layout" now. And all
related devices were converted to the new "mac-base" layout format.
It's time to remove this hack.

Signed-off-by: Shiji Yang 
---

Git grep ref:
https://git.openwrt.org/?p=openwrt%2Fopenwrt.git=search=HEAD=grep=mac-address-ascii=1

Regards,
Shiji Yang


 ...of_net-add-mac-address-ascii-support.patch | 116 --
 ...of_net-add-mac-address-ascii-support.patch | 116 --
 2 files changed, 232 deletions(-)
 delete mode 100644 
target/linux/generic/hack-5.15/601-of_net-add-mac-address-ascii-support.patch
 delete mode 100644 
target/linux/generic/hack-6.1/601-of_net-add-mac-address-ascii-support.patch

diff --git 
a/target/linux/generic/hack-5.15/601-of_net-add-mac-address-ascii-support.patch 
b/target/linux/generic/hack-5.15/601-of_net-add-mac-address-ascii-support.patch
deleted file mode 100644
index 55866c3135..00
--- 
a/target/linux/generic/hack-5.15/601-of_net-add-mac-address-ascii-support.patch
+++ /dev/null
@@ -1,116 +0,0 @@
-From: Yousong Zhou 
-Subject: [PATCH] of: net: add nvmem cell mac-address-ascii support
-
-This is needed for devices with mac address stored in ascii format,
-e.g. HiWiFi HC6361 to be ported in the following patch.
-
-Submitted-by: Yousong Zhou 

- net/core/of_net.c | 83 --
- 1 files changed, 72 insertions(+), 11 deletions(-)
-
 a/net/core/of_net.c
-+++ b/net/core/of_net.c
-@@ -57,13 +57,70 @@ static int of_get_mac_addr(struct device
-   return -ENODEV;
- }
- 
-+static void *nvmem_cell_get_mac_address(struct nvmem_cell *cell)
-+{
-+  size_t len;
-+  void *mac;
-+
-+  mac = nvmem_cell_read(cell, );
-+  if (IS_ERR(mac))
-+  return mac;
-+  if (len != ETH_ALEN) {
-+  kfree(mac);
-+  return ERR_PTR(-EINVAL);
-+  }
-+  return mac;
-+}
-+
-+static void *nvmem_cell_get_mac_address_ascii(struct nvmem_cell *cell)
-+{
-+  size_t len;
-+  int ret;
-+  void *mac_ascii;
-+  u8 *mac;
-+
-+  mac_ascii = nvmem_cell_read(cell, );
-+  if (IS_ERR(mac_ascii))
-+  return mac_ascii;
-+  if (len != ETH_ALEN*2+5) {
-+  kfree(mac_ascii);
-+  return ERR_PTR(-EINVAL);
-+  }
-+  mac = kmalloc(ETH_ALEN, GFP_KERNEL);
-+  if (!mac) {
-+  kfree(mac_ascii);
-+  return ERR_PTR(-ENOMEM);
-+  }
-+  ret = sscanf(mac_ascii, "%2hhx:%2hhx:%2hhx:%2hhx:%2hhx:%2hhx",
-+  [0], [1], [2],
-+  [3], [4], [5]);
-+  kfree(mac_ascii);
-+  if (ret == ETH_ALEN)
-+  return mac;
-+  kfree(mac);
-+  return ERR_PTR(-EINVAL);
-+}
-+
-+static struct nvmem_cell_mac_address_property {
-+  char *name;
-+  void *(*read)(struct nvmem_cell *);
-+} nvmem_cell_mac_address_properties[] = {
-+  {
-+  .name = "mac-address",
-+  .read = nvmem_cell_get_mac_address,
-+  }, {
-+  .name = "mac-address-ascii",
-+  .read = nvmem_cell_get_mac_address_ascii,
-+  },
-+};
-+
- static int of_get_mac_addr_nvmem(struct device_node *np, u8 *addr)
- {
-   struct platform_device *pdev = of_find_device_by_node(np);
-+  struct nvmem_cell_mac_address_property *property;
-   struct nvmem_cell *cell;
-   const void *mac;
--  size_t len;
--  int ret;
-+  int ret, i;
- 
-   /* Try lookup by device first, there might be a nvmem_cell_lookup
-* associated with a given device.
-@@ -74,17 +131,26 @@ static int of_get_mac_addr_nvmem(struct
-   return ret;
-   }
- 
--  cell = of_nvmem_cell_get(np, "mac-address");
-+  for (i = 0; i < ARRAY_SIZE(nvmem_cell_mac_address_properties); i++) {
-+  property = _cell_mac_address_properties[i];
-+  cell = of_nvmem_cell_get(np, property->name);
-+  /* For -EPROBE_DEFER don't try other properties.
-+   * We'll get back to this one.
-+   */
-+  if (!IS_ERR(cell) || PTR_ERR(cell) == -EPROBE_DEFER)
-+  break;
-+  }
-+
-   if (IS_ERR(cell))
-   return PTR_ERR(cell);
- 
--  mac = nvmem_cell_read(cell, );
-+  mac = property->read(cell);
-   nvmem_cell_put(cell);
- 
-   if (IS_ERR(mac))
-   return PTR_ERR(mac);
- 
--  if (len != ETH_ALEN || !is_valid_ether_addr(mac)) {
-+  if (!is_valid_ether_addr(mac)) {
-   kfree(mac);
-   return -EINVAL;
-   }
diff --git 
a/target/linux/generic/hack-6.1/601-of_net-add-mac-address-ascii-support.patch 
b/target/linux/generic/hack-6.1/601-of_net-add-mac-address-ascii-support.patch
deleted file mode 100644
index 55866c3135..00
--- 
a/target/linux/generic/hack-6.1/601-of_net-add-mac-address-ascii-support.patch
+++ /dev/null
@@ -1,116 +0,0

[PATCH] ramips: fix mtd partition node names for Phicomm PSG1208

2023-10-01 Thread Shiji Yang 
From: Shiji Yang 

The mtd partition node name should be "partition@${offset}".
However, the offsets of the PSG1208 don't match the partition
'reg' properties. This patch correct the wrong offsets.

Signed-off-by: Shiji Yang 
---
 target/linux/ramips/dts/mt7620a_phicomm_psg1208.dts | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/target/linux/ramips/dts/mt7620a_phicomm_psg1208.dts 
b/target/linux/ramips/dts/mt7620a_phicomm_psg1208.dts
index 4e123c32bd..fc4f1d6258 100644
--- a/target/linux/ramips/dts/mt7620a_phicomm_psg1208.dts
+++ b/target/linux/ramips/dts/mt7620a_phicomm_psg1208.dts
@@ -67,19 +67,19 @@
read-only;
};
 
-   partition@2 {
+   partition@3 {
label = "u-boot-env";
reg = <0x3 0x1>;
read-only;
};
 
-   factory: partition@3 {
+   factory: partition@4 {
label = "factory";
reg = <0x4 0x1>;
read-only;
};
 
-   partition@4 {
+   partition@5 {
compatible = "denx,uimage";
label = "firmware";
reg = <0x5 0x7b>;
-- 
2.39.2


___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

[PATCH] ramips: convert the remaining mtd-mac-address to NVMEM format

2023-10-01 Thread Shiji Yang 
From: Shiji Yang 

`mtd-mac-address` has been abandoned. Therefore, convert them to
NVMEM format. This patch also removes some useless mtd-mac-address
properties.

Signed-off-by: Shiji Yang 
---
 .../ramips/dts/mt7620a_netcore_nw5212.dts | 11 -
 .../ramips/dts/mt7620n_netgear_pr2000.dts | 15 ++--
 .../ramips/dts/mt7621_tplink_mr600-v2-eu.dts  |  1 -
 .../ramips/dts/mt7621_zyxel_lte3301-plus.dts  |  1 -
 .../dts/mt7628an_comfast_cf-wr617ac.dts   | 23 +++
 5 files changed, 36 insertions(+), 15 deletions(-)

diff --git a/target/linux/ramips/dts/mt7620a_netcore_nw5212.dts 
b/target/linux/ramips/dts/mt7620a_netcore_nw5212.dts
index 25287ebc0b..949f686e95 100644
--- a/target/linux/ramips/dts/mt7620a_netcore_nw5212.dts
+++ b/target/linux/ramips/dts/mt7620a_netcore_nw5212.dts
@@ -93,9 +93,16 @@
};
 
factory: partition@4 {
+   compatible = "nvmem-cells";
label = "factory";
reg = <0x4 0x1>;
+   #address-cells = <1>;
+   #size-cells = <1>;
read-only;
+
+   macaddr_factory_28: macaddr@28 {
+   reg = <0x28 0x6>;
+   };
};
 
partition@5 {
@@ -115,8 +122,10 @@
 };
 
  {
-   mtd-mac-address = < 0x28>;
mediatek,portmap = "w";
+
+   nvmem-cells = <_factory_28>;
+   nvmem-cell-names = "mac-address";
 };
 
  {
diff --git a/target/linux/ramips/dts/mt7620n_netgear_pr2000.dts 
b/target/linux/ramips/dts/mt7620n_netgear_pr2000.dts
index 6b4dde5432..97bd5474c2 100644
--- a/target/linux/ramips/dts/mt7620n_netgear_pr2000.dts
+++ b/target/linux/ramips/dts/mt7620n_netgear_pr2000.dts
@@ -110,9 +110,16 @@
};
 
board_data: partition@f7 {
+   compatible = "nvmem-cells";
label = "board_data";
reg = <0xf7 0x1>;
+   #address-cells = <1>;
+   #size-cells = <1>;
read-only;
+
+   macaddr_board_data_b0: macaddr@b0 {
+   reg = <0xb0 0x6>;
+   };
};
 
partition@f8 {
@@ -166,8 +173,10 @@
 };
 
  {
-   mtd-mac-address = <_data 0xb0>;
mediatek,portmap = "w";
+
+   nvmem-cells = <_board_data_b0>;
+   nvmem-cell-names = "mac-address";
 };
 
  {
@@ -180,7 +189,9 @@
 
  {
ralink,mtd-eeprom = < 0x0>;
-   mtd-mac-address = <_data 0xb0>;
+
+   nvmem-cells = <_board_data_b0>;
+   nvmem-cell-names = "mac-address";
 };
 
 _default {
diff --git a/target/linux/ramips/dts/mt7621_tplink_mr600-v2-eu.dts 
b/target/linux/ramips/dts/mt7621_tplink_mr600-v2-eu.dts
index b7475ec15b..69b89e5810 100644
--- a/target/linux/ramips/dts/mt7621_tplink_mr600-v2-eu.dts
+++ b/target/linux/ramips/dts/mt7621_tplink_mr600-v2-eu.dts
@@ -141,7 +141,6 @@
nvmem-cells = <_romfile_f100>;
nvmem-cell-names = "mac-address";
mediatek,mtd-eeprom = < 0x0>;
-   mtd-mac-address = < 0xf100>;
ieee80211-freq-limit = <240 250>;
};
 };
diff --git a/target/linux/ramips/dts/mt7621_zyxel_lte3301-plus.dts 
b/target/linux/ramips/dts/mt7621_zyxel_lte3301-plus.dts
index ed8260534e..120d421b8a 100644
--- a/target/linux/ramips/dts/mt7621_zyxel_lte3301-plus.dts
+++ b/target/linux/ramips/dts/mt7621_zyxel_lte3301-plus.dts
@@ -209,7 +209,6 @@
compatible = "nvmem-cells";
#address-cells = <1>;
#size-cells = <1>;
-   mtd-mac-address = < 0xfe6e>;
 
macaddr_factory_fe6e: macaddr@fe6e {
reg = <0xfe6e 0x6>;
diff --git a/target/linux/ramips/dts/mt7628an_comfast_cf-wr617ac.dts 
b/target/linux/ramips/dts/mt7628an_comfast_cf-wr617ac.dts
index 81734ed4fb..bec9e95182 100644
--- a/target/linux/ramips/dts/mt7628an_comfast_cf-wr617ac.dts
+++ b/target/linux/ramips/dts/mt7628an_comfast_cf-wr617ac.dts
@@ -70,9 +70,20 @@
};
 
factory: partition@4 {
+   compatible = "nvmem-cells";
label = "factory";
reg = <0x4 0x1>;
+   #address-cells = <1>;
+   #s

[PATCH] ramips: add missing mt76 packages for Telco Electronics X1

2023-10-01 Thread Shiji Yang 
From: Shiji Yang 

Telco Electronics X1 has MT7603E and MT7612E PCIe NICs. They are
driven by kmod-mt7603 and kmod-mt76x2.

Ref: 73e0f52b6e4e ("ramips: add support for Telco Electronics X1")
Signed-off-by: Shiji Yang 
---
 target/linux/ramips/image/mt7621.mk | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/target/linux/ramips/image/mt7621.mk 
b/target/linux/ramips/image/mt7621.mk
index 9838810af4..dc9e5515a7 100644
--- a/target/linux/ramips/image/mt7621.mk
+++ b/target/linux/ramips/image/mt7621.mk
@@ -2128,7 +2128,7 @@ define Device/telco-electronics_x1
   IMAGE_SIZE := 16064k
   DEVICE_VENDOR := Telco Electronics
   DEVICE_MODEL := X1
-  DEVICE_PACKAGES := kmod-usb3 kmod-mt76 -uboot-envtools
+  DEVICE_PACKAGES := kmod-usb3 kmod-mt7603 kmod-mt76x2 -uboot-envtools
 endef
 TARGET_DEVICES += telco-electronics_x1
 
-- 
2.39.2


___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

[PATCH] ramips: fix DTS EEPROM property for some MT7628 devices

2023-10-01 Thread Shiji Yang 
From: Shiji Yang 

The MT7628 integrated wireless is driven by `mt76`, so the right
EEPROM property name is `mediatek,mtd-eeprom`.

Signed-off-by: Shiji Yang 
---
 target/linux/ramips/dts/mt7628an_mercury_mac1200r-v2.dts | 1 -
 target/linux/ramips/dts/mt7628an_xiaomi_mi-ra75.dts  | 2 +-
 2 files changed, 1 insertion(+), 2 deletions(-)

diff --git a/target/linux/ramips/dts/mt7628an_mercury_mac1200r-v2.dts 
b/target/linux/ramips/dts/mt7628an_mercury_mac1200r-v2.dts
index 3797565908..f712a280c5 100644
--- a/target/linux/ramips/dts/mt7628an_mercury_mac1200r-v2.dts
+++ b/target/linux/ramips/dts/mt7628an_mercury_mac1200r-v2.dts
@@ -87,7 +87,6 @@
status = "okay";
 
mediatek,mtd-eeprom = < 0x0>;
-   ralink,mtd-eeprom = < 0x0>;
 };
 
  {
diff --git a/target/linux/ramips/dts/mt7628an_xiaomi_mi-ra75.dts 
b/target/linux/ramips/dts/mt7628an_xiaomi_mi-ra75.dts
index 173bcd992d..2dd855bf8f 100644
--- a/target/linux/ramips/dts/mt7628an_xiaomi_mi-ra75.dts
+++ b/target/linux/ramips/dts/mt7628an_xiaomi_mi-ra75.dts
@@ -95,7 +95,7 @@
 };
 
  {
-   ralink,mtd-eeprom = < 0x0>;
+   mediatek,mtd-eeprom = < 0x0>;
 };
 
 
-- 
2.39.2


___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

[PATCH] ramips: fix Gigabit Ethernet port of the HiWiFi HC5861

2023-09-26 Thread Shiji Yang 
From: Shiji Yang 

HiWiFi HC5861 has a GbE port which connected to the RTL8211E PHY
chip. This patch adds the missing Realtek PHY driver package and
sets the correct external PHYs base address to make it work again.

Signed-off-by: Shiji Yang 
---

Hi!

This patch should be backpoted to v22.03 and v23.05 branch. By the
way, I believe a lot of devices need the similar fix. Hope Michael
can have a look.

Thank you!

 target/linux/ramips/dts/mt7620a_hiwifi_hc5861.dts | 6 +-
 target/linux/ramips/image/mt7620.mk   | 2 +-
 2 files changed, 6 insertions(+), 2 deletions(-)

diff --git a/target/linux/ramips/dts/mt7620a_hiwifi_hc5861.dts 
b/target/linux/ramips/dts/mt7620a_hiwifi_hc5861.dts
index 87eacb13d7..8b37162f26 100644
--- a/target/linux/ramips/dts/mt7620a_hiwifi_hc5861.dts
+++ b/target/linux/ramips/dts/mt7620a_hiwifi_hc5861.dts
@@ -70,7 +70,7 @@
 
  {
pinctrl-names = "default";
-   pinctrl-0 = <_pins _pins>;
+   pinctrl-0 = <_pins>, <_pins>;
 
nvmem-cells = <_factory_4>;
nvmem-cell-names = "mac-address";
@@ -93,6 +93,10 @@
};
 };
 
+ {
+   mediatek,ephy-base = /bits/ 8 <12>;
+};
+
  {
status = "okay";
 };
diff --git a/target/linux/ramips/image/mt7620.mk 
b/target/linux/ramips/image/mt7620.mk
index f3f4873d76..f85f3c8521 100644
--- a/target/linux/ramips/image/mt7620.mk
+++ b/target/linux/ramips/image/mt7620.mk
@@ -578,7 +578,7 @@ define Device/hiwifi_hc5861
   DEVICE_VENDOR := HiWiFi
   DEVICE_MODEL := HC5861
   DEVICE_PACKAGES := kmod-mt76x2 kmod-usb2 kmod-usb-ohci kmod-sdhci-mt7620 \
-   kmod-usb-ledtrig-usbport
+   kmod-phy-realtek kmod-usb-ledtrig-usbport
   SUPPORTED_DEVICES += hc5861
 endef
 TARGET_DEVICES += hiwifi_hc5861
-- 
2.39.2


___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

[PATCH] mac80211: rt2x00: fix MT7620 low RSSI issue

2023-09-22 Thread Shiji Yang 
From: Shiji Yang 

Introducing SoC specific RSSI base value to fix the low RSSI issue
on MT7620. With this fix[1], the RSSI value reported by MT7620 will
increase by 10 dB.

[1] 
https://lore.kernel.org/linux-wireless/tyap286mb031571cdb146c414a908a66dbc...@tyap286mb0315.jpnp286.prod.outlook.com/

Fixes: https://github.com/openwrt/openwrt/issues/11036
Signed-off-by: Shiji Yang 
---

The relevant code can be found here. It's not a permanent link so I
don't want to add it to the commit message.
https://github.com/hanwckf/rt-n56u/blob/23387b278a7cf728748af606760758f5d59d1451/trunk/proprietary/rt_wifi/rtsoc/2.7.X.X/rt2860v2/common/cmm_sync.c#L470

 ...ifi-rt2x00-fix-MT7620-low-RSSI-issue.patch | 39 +++
 1 file changed, 39 insertions(+)
 create mode 100644 
package/kernel/mac80211/patches/rt2x00/999-wifi-rt2x00-fix-MT7620-low-RSSI-issue.patch

diff --git 
a/package/kernel/mac80211/patches/rt2x00/999-wifi-rt2x00-fix-MT7620-low-RSSI-issue.patch
 
b/package/kernel/mac80211/patches/rt2x00/999-wifi-rt2x00-fix-MT7620-low-RSSI-issue.patch
new file mode 100644
index 00..8f7343d14e
--- /dev/null
+++ 
b/package/kernel/mac80211/patches/rt2x00/999-wifi-rt2x00-fix-MT7620-low-RSSI-issue.patch
@@ -0,0 +1,39 @@
+From: Shiji Yang 
+Date: Sat, 23 Sep 2023 07:51:39 +0800
+Subject: [PATCH] wifi: rt2x00: fix MT7620 low RSSI issue
+
+On Mediatek vendor driver[1], MT7620 (RT6352) uses different RSSI
+base value '-2' compared to the other RT2x00 chips. This patch
+introduces the SoC specific base value to fix the low RSSI value
+reports on MT7620.
+
+[1] Found on MT76x2E_MT7620_LinuxAP_V3.0.4.0_P3 ConvertToRssi().
+
+Signed-off-by: Shiji Yang 
+---
+ drivers/net/wireless/ralink/rt2x00/rt2800lib.c | 7 ---
+ 1 file changed, 4 insertions(+), 3 deletions(-)
+
+--- a/drivers/net/wireless/ralink/rt2x00/rt2800lib.c
 b/drivers/net/wireless/ralink/rt2x00/rt2800lib.c
+@@ -875,6 +875,7 @@ static int rt2800_agc_to_rssi(struct rt2
+   s8 rssi0 = rt2x00_get_field32(rxwi_w2, RXWI_W2_RSSI0);
+   s8 rssi1 = rt2x00_get_field32(rxwi_w2, RXWI_W2_RSSI1);
+   s8 rssi2 = rt2x00_get_field32(rxwi_w2, RXWI_W2_RSSI2);
++  s8 base_val = rt2x00_rt(rt2x00dev, RT6352) ? -2 : -12;
+   u16 eeprom;
+   u8 offset0;
+   u8 offset1;
+@@ -899,9 +900,9 @@ static int rt2800_agc_to_rssi(struct rt2
+* If the value in the descriptor is 0, it is considered invalid
+* and the default (extremely low) rssi value is assumed
+*/
+-  rssi0 = (rssi0) ? (-12 - offset0 - rt2x00dev->lna_gain - rssi0) : -128;
+-  rssi1 = (rssi1) ? (-12 - offset1 - rt2x00dev->lna_gain - rssi1) : -128;
+-  rssi2 = (rssi2) ? (-12 - offset2 - rt2x00dev->lna_gain - rssi2) : -128;
++  rssi0 = (rssi0) ? (base_val - offset0 - rt2x00dev->lna_gain - rssi0) : 
-128;
++  rssi1 = (rssi1) ? (base_val - offset1 - rt2x00dev->lna_gain - rssi1) : 
-128;
++  rssi2 = (rssi2) ? (base_val - offset2 - rt2x00dev->lna_gain - rssi2) : 
-128;
+ 
+   /*
+* mac80211 only accepts a single RSSI value. Calculating the
-- 
2.39.2


___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

[PATCH] ath79: fix MikroTik CPLD driver build error on kernel 6.1

2023-09-08 Thread Shiji Yang 
From: Shiji Yang 

Since kernel 5.18, the return type in device remove function has
changed from 'int' to 'void'.

Signed-off-by: Shiji Yang 
---
 target/linux/ath79/files/drivers/mfd/rb4xx-cpld.c | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/target/linux/ath79/files/drivers/mfd/rb4xx-cpld.c 
b/target/linux/ath79/files/drivers/mfd/rb4xx-cpld.c
index da18424c63..f10ddef9e2 100644
--- a/target/linux/ath79/files/drivers/mfd/rb4xx-cpld.c
+++ b/target/linux/ath79/files/drivers/mfd/rb4xx-cpld.c
@@ -22,6 +22,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 
@@ -151,9 +152,14 @@ static int rb4xx_cpld_probe(struct spi_device *spi)
NULL, 0, NULL);
 }
 
+#if LINUX_VERSION_CODE >= KERNEL_VERSION(5,18,0)
+static void rb4xx_cpld_remove(struct spi_device *spi)
+{
+#else
 static int rb4xx_cpld_remove(struct spi_device *spi)
 {
return 0;
+#endif
 }
 
 static const struct of_device_id rb4xx_cpld_dt_match[] = {
-- 
2.39.2


___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

[PATCH 22.03] mt76: backport various mt7603 fixes to improve Wi-Fi stability

2023-08-24 Thread Shiji Yang 
From: Shiji Yang 

The SSID of MT7628 will disappear under heavy load, which makes
wireless unusable. These patches can fix this critical issue. Since
the mt76 mainline is no longer compatible with OpenWrt-22.03. So
let's backport them separately.

b14c2351dd wifi: mt76: mt7603: disable A-MSDU tx support on MT7628
85cc58378d wifi: mt76: mt7603: add missing register initialization for MT7628
c03d84c0d0 wifi: mt76: mt7603: improve stuck beacon handling
a8d9553d8f wifi: mt76: mt7603: improve watchdog reset reliablity
80b8bcf0e3 wifi: mt76: mt7603: rework/fix rx pse hang check
7ef4dd12d9 wifi: mt76: mt7603: fix tx filter/flush function
53edfc7aaa wifi: mt76: mt7603: fix beacon interval after disabling a single vif
72b87836d3 Revert "mt76: use IEEE80211_OFFLOAD_ENCAP_ENABLED instead of 
MT_DRV_AMSDU_OFFLOAD"

Fixes: https://github.com/openwrt/openwrt/issues/13283
Fixes: https://github.com/openwrt/openwrt/issues/10074
Fixes: https://github.com/openwrt/openwrt/issues/9219
Fixes: https://github.com/openwrt/openwrt/issues/8757
Fixes: https://github.com/openwrt/openwrt/issues/8314
Fixes: https://github.com/openwrt/openwrt/issues/8184
Signed-off-by: Shiji Yang 
---
 package/kernel/mt76/Makefile  |   2 +-
 ...211_OFFLOAD_ENCAP_ENABLED-instead-of.patch |  71 
 ...ix-beacon-interval-after-disabling-a.patch |  26 +++
 ...-mt7603-fix-tx-filter-flush-function.patch | 134 ++
 ...-mt7603-rework-fix-rx-pse-hang-check.patch |  74 
 ...03-improve-watchdog-reset-reliablity.patch |  73 
 ...mt7603-improve-stuck-beacon-handling.patch | 163 ++
 ...-missing-register-initialization-for.patch |  28 +++
 ...-disable-A-MSDU-tx-support-on-MT7628.patch |  36 
 9 files changed, 606 insertions(+), 1 deletion(-)
 create mode 100644 
package/kernel/mt76/patches/130-Revert-mt76-use-IEEE80211_OFFLOAD_ENCAP_ENABLED-instead-of.patch
 create mode 100644 
package/kernel/mt76/patches/131-wifi-mt76-mt7603-fix-beacon-interval-after-disabling-a.patch
 create mode 100644 
package/kernel/mt76/patches/132-wifi-mt76-mt7603-fix-tx-filter-flush-function.patch
 create mode 100644 
package/kernel/mt76/patches/133-wifi-mt76-mt7603-rework-fix-rx-pse-hang-check.patch
 create mode 100644 
package/kernel/mt76/patches/134-wifi-mt76-mt7603-improve-watchdog-reset-reliablity.patch
 create mode 100644 
package/kernel/mt76/patches/135-wifi-mt76-mt7603-improve-stuck-beacon-handling.patch
 create mode 100644 
package/kernel/mt76/patches/136-wifi-mt76-mt7603-add-missing-register-initialization-for.patch
 create mode 100644 
package/kernel/mt76/patches/137-wifi-mt76-mt7603-disable-A-MSDU-tx-support-on-MT7628.patch

diff --git a/package/kernel/mt76/Makefile b/package/kernel/mt76/Makefile
index 63d3a48085..44cee72f0c 100644
--- a/package/kernel/mt76/Makefile
+++ b/package/kernel/mt76/Makefile
@@ -1,7 +1,7 @@
 include $(TOPDIR)/rules.mk
 
 PKG_NAME:=mt76
-PKG_RELEASE=5
+PKG_RELEASE=6
 
 PKG_LICENSE:=GPLv2
 PKG_LICENSE_FILES:=
diff --git 
a/package/kernel/mt76/patches/130-Revert-mt76-use-IEEE80211_OFFLOAD_ENCAP_ENABLED-instead-of.patch
 
b/package/kernel/mt76/patches/130-Revert-mt76-use-IEEE80211_OFFLOAD_ENCAP_ENABLED-instead-of.patch
new file mode 100644
index 00..4135aedeef
--- /dev/null
+++ 
b/package/kernel/mt76/patches/130-Revert-mt76-use-IEEE80211_OFFLOAD_ENCAP_ENABLED-instead-of.patch
@@ -0,0 +1,71 @@
+From: Ben Greear 
+Date: Sat, 1 Oct 2022 07:19:20 -0700
+Subject: [PATCH] Revert "mt76: use IEEE80211_OFFLOAD_ENCAP_ENABLED instead of
+ MT_DRV_AMSDU_OFFLOAD"
+
+This reverts commit f17f4864504d754bcbf31e4c89412cdf9946c409.
+
+The reverted commit significantly decreases performance when running
+a test where two MT7915 radios have 16 station vdevs each, configured
+for AC mode, and transmitting UDP traffic to AP.
+
+Reported-by: Carson Vandegriffe 
+Signed-off-by: Ben Greear 
+---
+ mac80211.c| 8 ++--
+ mt76.h| 1 +
+ mt7915/mmio.c | 3 ++-
+ mt7921/pci.c  | 3 ++-
+ 4 files changed, 11 insertions(+), 4 deletions(-)
+
+--- a/mac80211.c
 b/mac80211.c
+@@ -443,8 +443,12 @@ mt76_phy_init(struct mt76_phy *phy, stru
+   ieee80211_hw_set(hw, SUPPORTS_CLONED_SKBS);
+   ieee80211_hw_set(hw, SUPPORTS_AMSDU_IN_AMPDU);
+   ieee80211_hw_set(hw, SUPPORTS_REORDERING_BUFFER);
+-  ieee80211_hw_set(hw, TX_AMSDU);
+-  ieee80211_hw_set(hw, TX_FRAG_LIST);
++
++  if (!(dev->drv->drv_flags & MT_DRV_AMSDU_OFFLOAD)) {
++  ieee80211_hw_set(hw, TX_AMSDU);
++  ieee80211_hw_set(hw, TX_FRAG_LIST);
++  }
++
+   ieee80211_hw_set(hw, MFP_CAPABLE);
+   ieee80211_hw_set(hw, AP_LINK_PS);
+   ieee80211_hw_set(hw, REPORTS_TX_ACK_STATUS);
+--- a/mt76.h
 b/mt76.h
+@@ -388,6 +388,7 @@ struct mt76_hw_cap {
+ #define MT_DRV_SW_RX_AIRTIME  BIT(2)
+ #define MT_DRV_RX_DMA_HDR BIT(3)
+ #define MT_DRV_HW_MGMT_TXQBIT(4)
++#define MT_DRV_AMSDU_OFFLOAD  BIT(5)
+ 
+ struct mt76_driv

[PATCH] mac80211: fix MT7620 Wi-Fi channel scanning function

2023-08-21 Thread Shiji Yang 
From: Shiji Yang 

During the channel scanning process, the driver will continuously
switch channels. It seems that the full RF calibration step in
rt2800_config_channel() caused the channel scanning function to
timeout. To fix it, move the RF calibration to rt2800_enable_radio()
so that it is only executed once. This commit also includes some
coding format adjustments to follow the Linux recommended style.

Fixes: 2824fa6963cf ("mac80211: rework MT7620 PA/LNA RF calibration")
Signed-off-by: Shiji Yang 
---
 ...-rework-MT7620-PA-LNA-RF-calibration.patch | 93 +++
 1 file changed, 36 insertions(+), 57 deletions(-)

diff --git 
a/package/kernel/mac80211/patches/rt2x00/998-wifi-rt2x00-rework-MT7620-PA-LNA-RF-calibration.patch
 
b/package/kernel/mac80211/patches/rt2x00/998-wifi-rt2x00-rework-MT7620-PA-LNA-RF-calibration.patch
index 7fdad63976..5f6f5140d9 100644
--- 
a/package/kernel/mac80211/patches/rt2x00/998-wifi-rt2x00-rework-MT7620-PA-LNA-RF-calibration.patch
+++ 
b/package/kernel/mac80211/patches/rt2x00/998-wifi-rt2x00-rework-MT7620-PA-LNA-RF-calibration.patch
@@ -3,8 +3,6 @@ Date: Tue, 25 Jul 2023 20:05:06 +0800
 Subject: [PATCH] wifi: rt2x00: rework MT7620 PA/LNA RF calibration
 
 1. Move MT7620 PA/LNA calibration code to dedicated functions.
-   Calibration stage 1 is executed before configuring channels and
-   stage 2 is executed after configuring channels.
 2. For external PA/LNA devices, restore RF and BBP registers before
R-Calibration.
 3. Do Rx DCOC calibration again before RXIQ calibration.
@@ -21,23 +19,13 @@ Subject: [PATCH] wifi: rt2x00: rework MT7620 PA/LNA RF 
calibration
 
 Signed-off-by: Shiji Yang 
 ---
- .../net/wireless/ralink/rt2x00/rt2800lib.c| 318 +++---
+ .../net/wireless/ralink/rt2x00/rt2800lib.c| 306 ++
  drivers/net/wireless/ralink/rt2x00/rt2x00.h   |   6 +
- 2 files changed, 194 insertions(+), 130 deletions(-)
+ 2 files changed, 182 insertions(+), 130 deletions(-)
 
 --- a/drivers/net/wireless/ralink/rt2x00/rt2800lib.c
 +++ b/drivers/net/wireless/ralink/rt2x00/rt2800lib.c
-@@ -62,6 +62,9 @@ MODULE_PARM_DESC(watchdog, "Enable watch
-   rt2800_regbusy_read((__dev), H2M_MAILBOX_CSR, \
-   H2M_MAILBOX_CSR_OWNER, (__reg))
- 
-+static void rt6352_init_palna_stage1(struct rt2x00_dev *rt2x00dev);
-+static void rt6352_init_palna_stage2(struct rt2x00_dev *rt2x00dev);
-+
- static inline bool rt2800_is_305x_soc(struct rt2x00_dev *rt2x00dev)
- {
-   /* check for rt2872 on SoC */
-@@ -3881,14 +3884,6 @@ static void rt2800_config_channel_rf7620
+@@ -3881,14 +3881,6 @@ static void rt2800_config_channel_rf7620
rfcsr |= tx_agc_fc;
rt2800_rfcsr_write_bank(rt2x00dev, 7, 59, rfcsr);
}
@@ -52,17 +40,7 @@ Signed-off-by: Shiji Yang 
  }
  
  static void rt2800_config_alc_rt6352(struct rt2x00_dev *rt2x00dev,
-@@ -4151,6 +4146,9 @@ static void rt2800_config_channel(struct
-   rt2800_txpower_to_dev(rt2x00dev, rf->channel,
- info->default_power3);
- 
-+  if (rt2x00_rt(rt2x00dev, RT6352))
-+  rt6352_init_palna_stage1(rt2x00dev);
-+
-   switch (rt2x00dev->chip.rt) {
-   case RT3883:
-   rt3883_bbp_adjust(rt2x00dev, rf);
-@@ -4457,89 +4455,65 @@ static void rt2800_config_channel(struct
+@@ -4457,89 +4449,63 @@ static void rt2800_config_channel(struct
usleep_range(1000, 1500);
}
  
@@ -193,12 +171,10 @@ Signed-off-by: Shiji Yang 
 +   * Otherwise it's difficult to pass the WHQL.
 +   */
 +  usleep_range(1000, 1500);
-+
-+  rt6352_init_palna_stage2(rt2x00dev);
}
  
bbp = rt2800_bbp_read(rt2x00dev, 4);
-@@ -5649,43 +5623,6 @@ void rt2800_vco_calibration(struct rt2x0
+@@ -5649,43 +5615,6 @@ void rt2800_vco_calibration(struct rt2x0
}
}
rt2800_register_write(rt2x00dev, TX_PIN_CFG, tx_pin);
@@ -242,7 +218,7 @@ Signed-off-by: Shiji Yang 
  }
  EXPORT_SYMBOL_GPL(rt2800_vco_calibration);
  
-@@ -8650,7 +8587,7 @@ static void rt2800_r_calibration(struct
+@@ -8650,7 +8579,7 @@ static void rt2800_r_calibration(struct
rt2x00_warn(rt2x00dev, "Wait MAC Tx Status to MAX !!!\n");
  
maccfg = rt2800_register_read(rt2x00dev, MAC_SYS_CTRL);
@@ -251,7 +227,7 @@ Signed-off-by: Shiji Yang 
rt2800_register_write(rt2x00dev, MAC_SYS_CTRL, maccfg);
  
if (unlikely(rt2800_wait_bbp_rf_ready(rt2x00dev, 
MAC_STATUS_CFG_BBP_RF_BUSY_RX)))
-@@ -10688,30 +10625,151 @@ static void rt2800_init_rfcsr_6352(struc
+@@ -10688,30 +10617,143 @@ static void rt2800_init_rfcsr_6352(struc
rt2800_rfcsr_write_dccal(rt2x00dev, 5, 0x00);
rt2800_rfcsr_write_dccal(rt2x00dev, 17, 0x7C);
}
@@ -266,7 +242,7 @@ Signed-off-by: Shiji Yang 
 -  rt2800_loft_iq_calibration(rt2x00dev);
 -

[v2 1/2] mac80211: rework MT7620 PA/LNA RF calibration

2023-07-29 Thread Shiji Yang 
From: Shiji Yang 

This patch makes some improvements to the MT7620 RF calibration.

1. Move MT7620 PA/LNA calibration code to dedicated functions.
2. Restore RF and BBP registers before R-Calibration.
3. Do Rx DCOC calibration again before RXIQ calibration.
4. Use SoC specific AGC initial LNA value.
5. Correct MAC_RX_EN mask in rt2800_r_calibration()[1].

[1] This change may fix the "BBP/RF register access failed" error:
ieee80211 phy0: rt2800_wait_bbp_rf_ready: Error - BBP/RF register access 
failed, aborting

Signed-off-by: Shiji Yang 
---
 ...-rework-MT7620-PA-LNA-RF-calibration.patch | 434 ++
 1 file changed, 434 insertions(+)
 create mode 100644 
package/kernel/mac80211/patches/rt2x00/998-wifi-rt2x00-rework-MT7620-PA-LNA-RF-calibration.patch

diff --git 
a/package/kernel/mac80211/patches/rt2x00/998-wifi-rt2x00-rework-MT7620-PA-LNA-RF-calibration.patch
 
b/package/kernel/mac80211/patches/rt2x00/998-wifi-rt2x00-rework-MT7620-PA-LNA-RF-calibration.patch
new file mode 100644
index 00..429d7f24a9
--- /dev/null
+++ 
b/package/kernel/mac80211/patches/rt2x00/998-wifi-rt2x00-rework-MT7620-PA-LNA-RF-calibration.patch
@@ -0,0 +1,434 @@
+From: Shiji Yang 
+Date: Tue, 25 Jul 2023 20:05:06 +0800
+Subject: [PATCH] wifi: rt2x00: rework MT7620 PA/LNA RF calibration
+
+1. Move MT7620 PA/LNA calibration code to dedicated functions.
+   Calibration stage 1 is executed before configuring channels and
+   stage 2 is executed after configuring channels.
+2. For external PA/LNA devices, restore RF and BBP registers before
+   R-Calibration.
+3. Do Rx DCOC calibration again before RXIQ calibration.
+4. Correct MAC_SYS_CTRL register RX mask to 0x08 in R-Calibration
+   function. For MAC_SYS_CTRL register, Bit[2] controls MAC_TX_EN
+   and Bit[3] controls MAC_RX_EN (Bit index starts from 0).
+5. Move the channel configuration code from rt2800_vco_calibration()
+   to the rt2800_config_channel().
+6. Use MT7620 SOC specific AGC initial LNA value instead of the
+   RT5592's value.
+7. Adjust the register operation sequence according to the vendor
+   driver code. This may not be useful, but it can make things
+   clearer when developers try to review it.
+
+Signed-off-by: Shiji Yang 
+---
+ .../net/wireless/ralink/rt2x00/rt2800lib.c| 318 +++---
+ drivers/net/wireless/ralink/rt2x00/rt2x00.h   |   6 +
+ 2 files changed, 194 insertions(+), 130 deletions(-)
+
+--- a/drivers/net/wireless/ralink/rt2x00/rt2800lib.c
 b/drivers/net/wireless/ralink/rt2x00/rt2800lib.c
+@@ -62,6 +62,9 @@ MODULE_PARM_DESC(watchdog, "Enable watch
+   rt2800_regbusy_read((__dev), H2M_MAILBOX_CSR, \
+   H2M_MAILBOX_CSR_OWNER, (__reg))
+ 
++static void rt6352_init_palna_stage1(struct rt2x00_dev *rt2x00dev);
++static void rt6352_init_palna_stage2(struct rt2x00_dev *rt2x00dev);
++
+ static inline bool rt2800_is_305x_soc(struct rt2x00_dev *rt2x00dev)
+ {
+   /* check for rt2872 on SoC */
+@@ -3881,14 +3884,6 @@ static void rt2800_config_channel_rf7620
+   rfcsr |= tx_agc_fc;
+   rt2800_rfcsr_write_bank(rt2x00dev, 7, 59, rfcsr);
+   }
+-
+-  if (conf_is_ht40(conf)) {
+-  rt2800_bbp_glrt_write(rt2x00dev, 141, 0x10);
+-  rt2800_bbp_glrt_write(rt2x00dev, 157, 0x2f);
+-  } else {
+-  rt2800_bbp_glrt_write(rt2x00dev, 141, 0x1a);
+-  rt2800_bbp_glrt_write(rt2x00dev, 157, 0x40);
+-  }
+ }
+ 
+ static void rt2800_config_alc_rt6352(struct rt2x00_dev *rt2x00dev,
+@@ -4151,6 +4146,9 @@ static void rt2800_config_channel(struct
+   rt2800_txpower_to_dev(rt2x00dev, rf->channel,
+ info->default_power3);
+ 
++  if (rt2x00_rt(rt2x00dev, RT6352))
++  rt6352_init_palna_stage1(rt2x00dev);
++
+   switch (rt2x00dev->chip.rt) {
+   case RT3883:
+   rt3883_bbp_adjust(rt2x00dev, rf);
+@@ -4457,89 +4455,65 @@ static void rt2800_config_channel(struct
+   usleep_range(1000, 1500);
+   }
+ 
+-  if (rt2x00_rt(rt2x00dev, RT5592) || rt2x00_rt(rt2x00dev, RT6352)) {
++  if (rt2x00_rt(rt2x00dev, RT5592)) {
+   reg = 0x10;
+-  if (!conf_is_ht40(conf)) {
+-  if (rt2x00_rt(rt2x00dev, RT6352) &&
+-  rt2x00_has_cap_external_lna_bg(rt2x00dev)) {
+-  reg |= 0x5;
+-  } else {
+-  reg |= 0xa;
+-  }
+-  }
++  if (!conf_is_ht40(conf))
++  reg |= 0xa;
+   rt2800_bbp_write(rt2x00dev, 195, 141);
+   rt2800_bbp_write(rt2x00dev, 196, reg);
+ 
+-  /* AGC init.
+-   * Despite the vendor driver using different values here for
+-   * RT6352 chip, we use 0x1c for now. This may have to be changed
+-

[v2 2/2] ramips: pinctrl: support requesting different functions for same group

2023-07-29 Thread Shiji Yang 
From: Shiji Yang 

MT7620 wireless radio needs change the pin group function between
"gpio" and "pa" during the calibration process. However, ralink
pinctrl driver doesn't support requesting different functions for
the same group. This patch enables pinctrl consumers to perform
such operations.

Signed-off-by: Shiji Yang 
---
 ...upport-requesting-different-function.patch | 45 +++
 1 file changed, 45 insertions(+)
 create mode 100644 
target/linux/ramips/patches-5.15/808-pinctrl-mtmips-support-requesting-different-function.patch

diff --git 
a/target/linux/ramips/patches-5.15/808-pinctrl-mtmips-support-requesting-different-function.patch
 
b/target/linux/ramips/patches-5.15/808-pinctrl-mtmips-support-requesting-different-function.patch
new file mode 100644
index 00..047808f1e6
--- /dev/null
+++ 
b/target/linux/ramips/patches-5.15/808-pinctrl-mtmips-support-requesting-different-function.patch
@@ -0,0 +1,45 @@
+From: Shiji Yang 
+Date: Wed, 26 Jul 2023 01:32:55 +0800
+Subject: [PATCH] pinctrl: mtmips: support requesting different functions for
+ same group
+
+Sometimes pinctrl consumers may request different functions for the
+same pin group in different situations. This patch can help to reset
+the group function flag when requesting a different function.
+
+Signed-off-by: Shiji Yang 
+---
+ drivers/pinctrl/ralink/pinctrl-ralink.c | 21 +
+ 1 file changed, 17 insertions(+), 4 deletions(-)
+
+--- a/drivers/pinctrl/ralink/pinctrl-ralink.c
 b/drivers/pinctrl/ralink/pinctrl-ralink.c
+@@ -123,11 +123,24 @@ static int ralink_pmx_group_enable(struc
+   int i;
+   int shift;
+ 
+-  /* dont allow double use */
++  /*
++   * for the same pin group, if request a different function,
++   * then clear the group function flag and continue, else exit.
++   */
+   if (p->groups[group].enabled) {
+-  dev_err(p->dev, "%s is already enabled\n",
+-  p->groups[group].name);
+-  return 0;
++  for (i = 0; i < p->groups[group].func_count; i++) {
++  if (p->groups[group].func[i].enabled == 1) {
++  if (!strcmp(p->func[func]->name,
++  p->groups[group].func[i].name))
++  return 0;
++  p->groups[group].func[i].enabled = 0;
++  break;
++  }
++  }
++
++  /* exit if request the "gpio" function again */
++  if (i == p->groups[group].func_count && func == 0)
++  return 0;
+   }
+ 
+   p->groups[group].enabled = 1;
-- 
2.39.2


___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

[v2 0/2] rework MT7620 PA/LNA RF calibration

2023-07-29 Thread Shiji Yang 
From: Shiji Yang 

This series of patches introduces some fixes to the MT7620 wireless
calibration function:

* rework MT7620 PA/LNA RF calibration
* fix gpio pinmux function during calibration

Changes since v1:
* fix the typo error "inint" to "init"
* Use MT7620 SoC specific AGC initial LNA value.
* Move some channel configuration code to the rt2800_config_channel()
  to ensure that the register operation sequence is consistent with
  the vendor driver.

Shiji Yang (2):
  mac80211: rework MT7620 PA/LNA RF calibration
  ramips: pinctrl: support requesting different functions for same group

 ...-rework-MT7620-PA-LNA-RF-calibration.patch | 434 ++
 ...upport-requesting-different-function.patch |  45 ++
 2 files changed, 479 insertions(+)
 create mode 100644 
package/kernel/mac80211/patches/rt2x00/998-wifi-rt2x00-rework-MT7620-PA-LNA-RF-calibration.patch
 create mode 100644 
target/linux/ramips/patches-5.15/808-pinctrl-mtmips-support-requesting-different-function.patch

-- 
2.39.2


___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

[PATCH 1/2] mac80211: rework MT7620 PA/LNA RF calibration

2023-07-26 Thread Shiji Yang 
From: Shiji Yang 

This patch makes some improvements to the MT7620 RF calibration.

1. Move MT7620 PA/LNA calibration code to dedicated functions.
2. Restore RF and BBP registers before R-Calibration.
3. Do Rx DCOC calibration again before RXIQ calibration.
4. Correct MAC_RX_EN mask in rt2800_r_calibration()[1].

[1] This change may fix the "BBP/RF register access failed" error:
ieee80211 phy0: rt2800_wait_bbp_rf_ready: Error - BBP/RF register access 
failed, aborting

Signed-off-by: Shiji Yang 
---
 ...-rework-MT7620-PA-LNA-RF-calibration.patch | 312 ++
 1 file changed, 312 insertions(+)
 create mode 100644 
package/kernel/mac80211/patches/rt2x00/998-wifi-rt2x00-rework-MT7620-PA-LNA-RF-calibration.patch

diff --git 
a/package/kernel/mac80211/patches/rt2x00/998-wifi-rt2x00-rework-MT7620-PA-LNA-RF-calibration.patch
 
b/package/kernel/mac80211/patches/rt2x00/998-wifi-rt2x00-rework-MT7620-PA-LNA-RF-calibration.patch
new file mode 100644
index 00..0cf34f3a6c
--- /dev/null
+++ 
b/package/kernel/mac80211/patches/rt2x00/998-wifi-rt2x00-rework-MT7620-PA-LNA-RF-calibration.patch
@@ -0,0 +1,312 @@
+From: Shiji Yang 
+Date: Tue, 25 Jul 2023 20:05:06 +0800
+Subject: [PATCH] wifi: rt2x00: rework MT7620 PA/LNA RF calibration
+
+1. Move MT7620 PA/LNA calibration code to dedicated functions.
+   Calibration stage 1 is executed before configuring channels and
+   stage 2 is executed after configuring channels.
+2. For external PA/LNA devices, restore RF and BBP registers before
+   R-Calibration.
+3. Do Rx DCOC calibration again before RXIQ calibration.
+4. Correct MAC_SYS_CTRL register RX mask to 0x08 in R-Calibration
+   function. For MAC_SYS_CTRL register, Bit[2] controls MAC_TX_EN
+   and Bit[3] controls MAC_RX_EN (Bit index starts from 0).
+5. Adjust the register operation sequence according to the vendor
+   driver code. This may not be useful, but it can make things
+   clearer when developers try to review it.
+
+Signed-off-by: Shiji Yang 
+---
+ .../net/wireless/ralink/rt2x00/rt2800lib.c| 220 --
+ drivers/net/wireless/ralink/rt2x00/rt2x00.h   |   6 +
+ 2 files changed, 151 insertions(+), 75 deletions(-)
+
+--- a/drivers/net/wireless/ralink/rt2x00/rt2800lib.c
 b/drivers/net/wireless/ralink/rt2x00/rt2800lib.c
+@@ -62,6 +62,9 @@ MODULE_PARM_DESC(watchdog, "Enable watch
+   rt2800_regbusy_read((__dev), H2M_MAILBOX_CSR, \
+   H2M_MAILBOX_CSR_OWNER, (__reg))
+ 
++static void rt6352_init_palna_stage1(struct rt2x00_dev *rt2x00dev);
++static void rt6352_init_palna_stage2(struct rt2x00_dev *rt2x00dev);
++
+ static inline bool rt2800_is_305x_soc(struct rt2x00_dev *rt2x00dev)
+ {
+   /* check for rt2872 on SoC */
+@@ -4151,6 +4154,9 @@ static void rt2800_config_channel(struct
+   rt2800_txpower_to_dev(rt2x00dev, rf->channel,
+ info->default_power3);
+ 
++  if (rt2x00_rt(rt2x00dev, RT6352))
++  rt6352_init_palna_stage1(rt2x00dev);
++
+   switch (rt2x00dev->chip.rt) {
+   case RT3883:
+   rt3883_bbp_adjust(rt2x00dev, rf);
+@@ -4482,66 +4488,6 @@ static void rt2800_config_channel(struct
+   rt2800_iq_calibrate(rt2x00dev, rf->channel);
+   }
+ 
+-  if (rt2x00_rt(rt2x00dev, RT6352)) {
+-  if (test_bit(CAPABILITY_EXTERNAL_PA_TX0,
+-   >cap_flags)) {
+-  reg = rt2800_register_read(rt2x00dev, RF_CONTROL3);
+-  reg |= 0x0101;
+-  rt2800_register_write(rt2x00dev, RF_CONTROL3, reg);
+-
+-  reg = rt2800_register_read(rt2x00dev, RF_BYPASS3);
+-  reg |= 0x0101;
+-  rt2800_register_write(rt2x00dev, RF_BYPASS3, reg);
+-
+-  rt2800_rfcsr_write_chanreg(rt2x00dev, 43, 0x73);
+-  rt2800_rfcsr_write_chanreg(rt2x00dev, 44, 0x73);
+-  rt2800_rfcsr_write_chanreg(rt2x00dev, 45, 0x73);
+-  rt2800_rfcsr_write_chanreg(rt2x00dev, 46, 0x27);
+-  rt2800_rfcsr_write_chanreg(rt2x00dev, 47, 0xC8);
+-  rt2800_rfcsr_write_chanreg(rt2x00dev, 48, 0xA4);
+-  rt2800_rfcsr_write_chanreg(rt2x00dev, 49, 0x05);
+-  rt2800_rfcsr_write_chanreg(rt2x00dev, 54, 0x27);
+-  rt2800_rfcsr_write_chanreg(rt2x00dev, 55, 0xC8);
+-  rt2800_rfcsr_write_chanreg(rt2x00dev, 56, 0xA4);
+-  rt2800_rfcsr_write_chanreg(rt2x00dev, 57, 0x05);
+-  rt2800_rfcsr_write_chanreg(rt2x00dev, 58, 0x27);
+-  rt2800_rfcsr_write_chanreg(rt2x00dev, 59, 0xC8);
+-  rt2800_rfcsr_write_chanreg(rt2x00dev, 60, 0xA4);
+-  rt2800_rfcsr_write_chanreg(rt2x00dev, 61, 0x05);
+-  rt2800_rfcsr_w

[PATCH 0/2] rework MT7620 PA/LNA RF calibration

2023-07-26 Thread Shiji Yang 
From: Shiji Yang 

This series of patches introduces some fixes to the MT7620 wireless
calibration function:

* rework MT7620 PA/LNA RF calibration
* fix gpio pinmux function during calibration

Shiji Yang (2):
  mac80211: rework MT7620 PA/LNA RF calibration
  ramips: pinctrl: support requesting different functions for same group

 ...-rework-MT7620-PA-LNA-RF-calibration.patch | 312 ++
 ...upport-requesting-different-function.patch |  45 +++
 2 files changed, 357 insertions(+)
 create mode 100644 
package/kernel/mac80211/patches/rt2x00/998-wifi-rt2x00-rework-MT7620-PA-LNA-RF-calibration.patch
 create mode 100644 
target/linux/ramips/patches-5.15/808-pinctrl-mtmips-support-requesting-different-function.patch

-- 
2.39.2


___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

[PATCH 2/2] ramips: pinctrl: support requesting different functions for same group

2023-07-26 Thread Shiji Yang 
From: Shiji Yang 

MT7620 wireless radio needs change the pin group function between
"gpio" and "pa" during the calibration process. However, ralink
pinctrl driver doesn't support requesting different functions for
the same group. This patch enables pinctrl consumers to perform
such operations.

Signed-off-by: Shiji Yang 
---
 ...upport-requesting-different-function.patch | 45 +++
 1 file changed, 45 insertions(+)
 create mode 100644 
target/linux/ramips/patches-5.15/808-pinctrl-mtmips-support-requesting-different-function.patch

diff --git 
a/target/linux/ramips/patches-5.15/808-pinctrl-mtmips-support-requesting-different-function.patch
 
b/target/linux/ramips/patches-5.15/808-pinctrl-mtmips-support-requesting-different-function.patch
new file mode 100644
index 00..047808f1e6
--- /dev/null
+++ 
b/target/linux/ramips/patches-5.15/808-pinctrl-mtmips-support-requesting-different-function.patch
@@ -0,0 +1,45 @@
+From: Shiji Yang 
+Date: Wed, 26 Jul 2023 01:32:55 +0800
+Subject: [PATCH] pinctrl: mtmips: support requesting different functions for
+ same group
+
+Sometimes pinctrl consumers may request different functions for the
+same pin group in different situations. This patch can help to reset
+the group function flag when requesting a different function.
+
+Signed-off-by: Shiji Yang 
+---
+ drivers/pinctrl/ralink/pinctrl-ralink.c | 21 +
+ 1 file changed, 17 insertions(+), 4 deletions(-)
+
+--- a/drivers/pinctrl/ralink/pinctrl-ralink.c
 b/drivers/pinctrl/ralink/pinctrl-ralink.c
+@@ -123,11 +123,24 @@ static int ralink_pmx_group_enable(struc
+   int i;
+   int shift;
+ 
+-  /* dont allow double use */
++  /*
++   * for the same pin group, if request a different function,
++   * then clear the group function flag and continue, else exit.
++   */
+   if (p->groups[group].enabled) {
+-  dev_err(p->dev, "%s is already enabled\n",
+-  p->groups[group].name);
+-  return 0;
++  for (i = 0; i < p->groups[group].func_count; i++) {
++  if (p->groups[group].func[i].enabled == 1) {
++  if (!strcmp(p->func[func]->name,
++  p->groups[group].func[i].name))
++  return 0;
++  p->groups[group].func[i].enabled = 0;
++  break;
++  }
++  }
++
++  /* exit if request the "gpio" function again */
++  if (i == p->groups[group].func_count && func == 0)
++  return 0;
+   }
+ 
+   p->groups[group].enabled = 1;
-- 
2.39.2


___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

[PATCH v2] mac80211: limit MT7620 TX power based on eeprom calibration

2023-07-22 Thread Shiji Yang 
From: Shiji Yang 

This patch adds basic TX power control for the MT7620 and limits its
maximum TX power. This can avoid the link speed decrease caused by
chip overheating.

Signed-off-by: Shiji Yang 
---
Changes since v1:
  * To avoid developers misunderstanding it, rename rt2800_config_alc() to
rt2800_config_alc_rt6352() since it's only used by RT6352(AKA MT7620).


 ...t-MT7620-TX-power-based-on-eeprom-ca.patch | 106 ++
 1 file changed, 106 insertions(+)
 create mode 100644 
package/kernel/mac80211/patches/rt2x00/997-wifi-rt2x00-limit-MT7620-TX-power-based-on-eeprom-ca.patch

diff --git 
a/package/kernel/mac80211/patches/rt2x00/997-wifi-rt2x00-limit-MT7620-TX-power-based-on-eeprom-ca.patch
 
b/package/kernel/mac80211/patches/rt2x00/997-wifi-rt2x00-limit-MT7620-TX-power-based-on-eeprom-ca.patch
new file mode 100644
index 00..fd1b3d8bf3
--- /dev/null
+++ 
b/package/kernel/mac80211/patches/rt2x00/997-wifi-rt2x00-limit-MT7620-TX-power-based-on-eeprom-ca.patch
@@ -0,0 +1,106 @@
+From: Shiji Yang 
+Date: Sat, 22 Jul 2023 21:56:30 +0800
+Subject: [PATCH] wifi: rt2x00: limit MT7620 TX power based on eeprom
+ calibration
+
+In the vendor driver, the current channel power is queried from
+EEPROM_TXPOWER_BG1 and EEPROM_TXPOWER_BG2. And then the mixed value
+will be written into the low half-word of the TX_ALC_CFG_0 register.
+The high half-word of the TX_ALC_CFG_0 is a fixed value 0x2f2f.
+
+We can't get the accurate TX power. Based on my tests and the new
+MediaTek mt76 driver source code, the real TX power is approximately
+equal to channel_power + (max) rate_power. Usually max rate_power is
+the gain of the OFDM 6M rate, which can be readed from the offset
+EEPROM_TXPOWER_BYRATE +1.
+
+Based on these eeprom values, this patch adds basic TX power control
+for the MT7620 and limits its maximum TX power. This can avoid the
+link speed decrease caused by chip overheating. rt2800_config_alc()
+function has also been renamed to rt2800_config_alc_rt6352() because
+it's only used by RT6352(MT7620).
+
+Notice:
+It's still need some work to sync the max channel power to the user
+interface. This part is missing from the rt2x00 driver structure. If
+we set the power exceed the calibration value, it won't take effect.
+
+Signed-off-by: Shiji Yang 
+---
+ .../net/wireless/ralink/rt2x00/rt2800lib.c| 49 +--
+ 1 file changed, 34 insertions(+), 15 deletions(-)
+
+--- a/drivers/net/wireless/ralink/rt2x00/rt2800lib.c
 b/drivers/net/wireless/ralink/rt2x00/rt2800lib.c
+@@ -3891,28 +3891,47 @@ static void rt2800_config_channel_rf7620
+   }
+ }
+ 
+-static void rt2800_config_alc(struct rt2x00_dev *rt2x00dev,
++static void rt2800_config_alc_rt6352(struct rt2x00_dev *rt2x00dev,
+ struct ieee80211_channel *chan,
+ int power_level) {
+-  u16 eeprom, target_power, max_power;
++  u16 eeprom, chan_power, rate_power, target_power;
++  u16 tx_power[2];
++  s8 *power_group[2];
+   u32 mac_sys_ctrl;
+-  u32 reg;
++  u32 cnt, reg;
+   u8 bbp;
+ 
+-  /* hardware unit is 0.5dBm, limited to 23.5dBm */
+-  power_level *= 2;
+-  if (power_level > 0x2f)
+-  power_level = 0x2f;
+-
+-  max_power = chan->max_power * 2;
+-  if (max_power > 0x2f)
+-  max_power = 0x2f;
++  /* get per channel power, 2 channels in total, unit is 0.5dBm */
++  power_level = (power_level - 3) * 2;
++  /*
++   * We can't get the accurate TX power. Based on some tests, the real
++   * TX power is approximately equal to channel_power + (max)rate_power.
++   * Usually max rate_power is the gain of the OFDM 6M rate. The antenna
++   * gain and externel PA gain are not included as we are unable to
++   * obtain these values.
++   */
++  rate_power = rt2800_eeprom_read_from_array(rt2x00dev,
++  EEPROM_TXPOWER_BYRATE, 1) & 0x3f;
++  power_level -= rate_power;
++  if (power_level < 1)
++  power_level = 1;
++  if (power_level > chan->max_power * 2)
++  power_level = chan->max_power * 2;
++
++  power_group[0] = rt2800_eeprom_addr(rt2x00dev, EEPROM_TXPOWER_BG1);
++  power_group[1] = rt2800_eeprom_addr(rt2x00dev, EEPROM_TXPOWER_BG2);
++  for (cnt = 0; cnt < 2; cnt++) {
++  chan_power = power_group[cnt][rt2x00dev->rf_channel - 1];
++  if (chan_power >= 0x20 || chan_power == 0)
++  chan_power = 0x10;
++  tx_power[cnt] = power_level < chan_power ? power_level : 
chan_power;
++  }
+ 
+   reg = rt2800_register_read(rt2x00dev, TX_ALC_CFG_0);
+-  rt2x00_set_field32(, TX_ALC_CFG_0_CH_INIT_0, power_level);
+-  rt2x00_set_field32(, TX_ALC_CFG_0_CH_INIT_1, power_level);
+-  rt2x00_set_field32(, TX_ALC_CFG_0_LIMIT_0, max_power);
+-  rt2x00_set_field32(, TX_ALC_CFG_0_LIMIT_1, m

[PATCH] mac80211: limit MT7620 TX power based on eeprom calibration

2023-07-22 Thread Shiji Yang 
From: Shiji Yang 

This patch adds basic TX power control to the MT7620 and limits its
maximum TX power. This can avoid the link speed decrease caused by
chip overheating.

Signed-off-by: Shiji Yang 
---
 ...t-MT7620-TX-power-based-on-eeprom-ca.patch | 83 +++
 1 file changed, 83 insertions(+)
 create mode 100644 
package/kernel/mac80211/patches/rt2x00/997-wifi-rt2x00-limit-MT7620-TX-power-based-on-eeprom-ca.patch

diff --git 
a/package/kernel/mac80211/patches/rt2x00/997-wifi-rt2x00-limit-MT7620-TX-power-based-on-eeprom-ca.patch
 
b/package/kernel/mac80211/patches/rt2x00/997-wifi-rt2x00-limit-MT7620-TX-power-based-on-eeprom-ca.patch
new file mode 100644
index 00..ecb8577752
--- /dev/null
+++ 
b/package/kernel/mac80211/patches/rt2x00/997-wifi-rt2x00-limit-MT7620-TX-power-based-on-eeprom-ca.patch
@@ -0,0 +1,83 @@
+From: Shiji Yang 
+Date: Sat, 22 Jul 2023 21:56:30 +0800
+Subject: [PATCH] wifi: rt2x00: limit MT7620 TX power based on eeprom
+ calibration
+
+In the vendor driver, the current channel power is queried from
+EEPROM_TXPOWER_BG1 and EEPROM_TXPOWER_BG2. And then the mixed value
+will be written into the low half-word of the TX_ALC_CFG_0 register.
+The high half-word of the TX_ALC_CFG_0 is a fixed value 0x2f2f.
+
+We can't get the accurate TX power. Based on my tests and the new
+MediaTek mt76 driver source code, the real TX power is approximately
+equal to channel_power + (max) rate_power. Usually max rate_power is
+the gain of the OFDM 6M rate, which can be readed from the offset
+EEPROM_TXPOWER_BYRATE +1.
+
+Based on these eeprom values, this patch adds basic TX power control
+to the MT7620 and limits its maximum TX power. This can avoid the
+link speed decrease caused by chip overheating.
+
+Signed-off-by: Shiji Yang 
+---
+ .../net/wireless/ralink/rt2x00/rt2800lib.c| 43 +--
+ 1 file changed, 30 insertions(+), 13 deletions(-)
+
+--- a/drivers/net/wireless/ralink/rt2x00/rt2800lib.c
 b/drivers/net/wireless/ralink/rt2x00/rt2800lib.c
+@@ -3894,25 +3894,42 @@ static void rt2800_config_channel_rf7620
+ static void rt2800_config_alc(struct rt2x00_dev *rt2x00dev,
+ struct ieee80211_channel *chan,
+ int power_level) {
+-  u16 eeprom, target_power, max_power;
++  u16 eeprom, chan_power, rate_power, target_power;
++  u16 tx_power[2];
++  s8 *power_group[2];
+   u32 mac_sys_ctrl;
+-  u32 reg;
++  u32 cnt, reg;
+   u8 bbp;
+ 
+-  /* hardware unit is 0.5dBm, limited to 23.5dBm */
+-  power_level *= 2;
+-  if (power_level > 0x2f)
+-  power_level = 0x2f;
++  /* get per channel power, 2 channels in total, unit is 0.5dBm */
++  power_level = (power_level - 3) * 2;
++  /*
++   * We can't set the accurate TX power. Based on some tests, the real
++   * TX power is approximately equal to channel_power + (max)rate_power.
++   * Usually max rate_power is the gain of the OFDM 6M rate.
++   */
++  rate_power = rt2800_eeprom_read_from_array(rt2x00dev,
++  EEPROM_TXPOWER_BYRATE, 1) & 0x3f;
++  power_level -= rate_power;
++  if (power_level < 1)
++  power_level = 1;
++  if (power_level > chan->max_power * 2)
++  power_level = chan->max_power * 2;
+ 
+-  max_power = chan->max_power * 2;
+-  if (max_power > 0x2f)
+-  max_power = 0x2f;
++  power_group[0] = rt2800_eeprom_addr(rt2x00dev, EEPROM_TXPOWER_BG1);
++  power_group[1] = rt2800_eeprom_addr(rt2x00dev, EEPROM_TXPOWER_BG2);
++  for (cnt = 0; cnt < 2; cnt++) {
++  chan_power = power_group[cnt][rt2x00dev->rf_channel - 1];
++  if (chan_power >= 0x20 || chan_power == 0)
++  chan_power = 0x10;
++  tx_power[cnt] = power_level < chan_power ? power_level : 
chan_power;
++  }
+ 
+   reg = rt2800_register_read(rt2x00dev, TX_ALC_CFG_0);
+-  rt2x00_set_field32(, TX_ALC_CFG_0_CH_INIT_0, power_level);
+-  rt2x00_set_field32(, TX_ALC_CFG_0_CH_INIT_1, power_level);
+-  rt2x00_set_field32(, TX_ALC_CFG_0_LIMIT_0, max_power);
+-  rt2x00_set_field32(, TX_ALC_CFG_0_LIMIT_1, max_power);
++  rt2x00_set_field32(, TX_ALC_CFG_0_CH_INIT_0, tx_power[0]);
++  rt2x00_set_field32(, TX_ALC_CFG_0_CH_INIT_1, tx_power[1]);
++  rt2x00_set_field32(, TX_ALC_CFG_0_LIMIT_0, 0x2f);
++  rt2x00_set_field32(, TX_ALC_CFG_0_LIMIT_1, 0x2f);
+ 
+   eeprom = rt2800_eeprom_read(rt2x00dev, EEPROM_NIC_CONF1);
+   if (rt2x00_get_field16(eeprom, EEPROM_NIC_CONF1_INTERNAL_TX_ALC)) {
-- 
2.39.2


___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

[PATCH] ath79: increase the rfkill debounce interval for TP-Link Archer C7 v2

2023-07-14 Thread Shiji Yang 
From: Shiji Yang 

Due to circuit issue or silicon defect, sometimes the WiFi switch button
of the Archer C7 v2 can be accidentally triggered multiple times in one
second. This will cause WiFi to be unexpectedly shut down and trigger
'irq 23: nobody cared'[1] warning. Increasing the key debounce interval
to 1000 ms can fix this issue. This patch also add the missing rfkill
key label.

[1] Warning Log:
```
[87765.218511] irq 23: nobody cared (try booting with the "irqpoll" option)
[87765.225331] CPU: 0 PID: 317 Comm: irq/23-keys Not tainted 5.15.118 #0
...
[87765.486246] handlers:
[87765.488543] [<85257547>] 0x800c29a0 threaded [<5c6328a2>] 0x80ffe0b8 
[gpio_button_hotplug@4cf73d00+0x1a00]
[87765.498364] Disabling IRQ #23
```

Fixes: https://github.com/openwrt/openwrt/issues/13010
Fixes: https://github.com/openwrt/openwrt/issues/12167
Fixes: https://github.com/openwrt/openwrt/issues/11191
Fixes: https://github.com/openwrt/openwrt/issues/7835

Tested-by: Hans Hasert
Signed-off-by: Shiji Yang 
---
 target/linux/ath79/dts/qca9558_tplink_archer-c7-v2.dts | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/target/linux/ath79/dts/qca9558_tplink_archer-c7-v2.dts 
b/target/linux/ath79/dts/qca9558_tplink_archer-c7-v2.dts
index b7ac902003..1b860dbf2d 100644
--- a/target/linux/ath79/dts/qca9558_tplink_archer-c7-v2.dts
+++ b/target/linux/ath79/dts/qca9558_tplink_archer-c7-v2.dts
@@ -13,10 +13,11 @@
 
  {
rfkill {
+   label = "rfkill";
gpios = < 23 GPIO_ACTIVE_LOW>;
linux,code = ;
linux,input-type = ;
-   debounce-interval = <60>;
+   debounce-interval = <1000>;
};
 };
 
-- 
2.30.2


___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

[PATCH v2 0/2] ath79: fix boot failure on Netgear WNDR4300 v2

2023-07-09 Thread Shiji Yang 
From: Shiji Yang 

---
Changes from v1:
use 'pad-extra 1' instead of 'append-string -e '\xff''

---
These two patches fix the boot failure issue on Netgear WNDR4300 v2
and WNDR4500 v3:

[1] 23.05-rc bricks WNDR4300v2
link: https://github.com/openwrt/openwrt/issues/13050
[2] ath79: NETGEAR WNDR4300v2 Bricked on Power Cycle After Flash
link: https://github.com/openwrt/openwrt/issues/8878

Shiji Yang (2):
  ath79: rework Netgear nand devices image recipe
  ath79: fix first reboot failure on Netgear WNDR4300 v2 and WNDR4500 v3

 .../linux/ath79/dts/qca9563_netgear_wndr.dtsi | 32 +--
 target/linux/ath79/image/nand.mk  | 13 ++--
 .../base-files/etc/board.d/05_compat-version  | 15 +
 3 files changed, 54 insertions(+), 6 deletions(-)
 create mode 100644 
target/linux/ath79/nand/base-files/etc/board.d/05_compat-version

-- 
2.30.2


___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

[PATCH v2 2/2] ath79: fix first reboot issue on Netgear WNDR4300 v2 and WNDR4500 v3

2023-07-09 Thread Shiji Yang 
From: Shiji Yang 

>From the Netgear u-boot GPL code[1]. Bootloader always unconditionally
marks block 768, 1020 - 1023 as bad blocks on each boot. This may lead
to conflicts with the OpenWrt nand driver since these blocks may be good
blocks. In this case, U-boot will override the oob of these blocks so
that break the ubi volume. The system will be damaged after first reboot.
To avoid this issue, manually skip these blocks by using "mtd-concat".

[1] 
https://www.downloads.netgear.com/files/GPL/EX7300v2series-V1.0.0.146_gpl_src.tar.bz2.zip

Fixes: https://github.com/openwrt/openwrt/issues/8878
Tested-by: Yousaf 
Signed-off-by: Shiji Yang 
---
 .../linux/ath79/dts/qca9563_netgear_wndr.dtsi | 32 +--
 target/linux/ath79/image/nand.mk  |  6 
 .../base-files/etc/board.d/05_compat-version  | 15 +
 3 files changed, 50 insertions(+), 3 deletions(-)
 create mode 100644 
target/linux/ath79/nand/base-files/etc/board.d/05_compat-version

diff --git a/target/linux/ath79/dts/qca9563_netgear_wndr.dtsi 
b/target/linux/ath79/dts/qca9563_netgear_wndr.dtsi
index a51fb1964b..9e075e46e0 100644
--- a/target/linux/ath79/dts/qca9563_netgear_wndr.dtsi
+++ b/target/linux/ath79/dts/qca9563_netgear_wndr.dtsi
@@ -90,6 +90,22 @@
linux,default-trigger = "phy1tpt";
};
};
+
+   ubi-concat {
+   compatible = "mtd-concat";
+   devices = < >;
+
+   partitions {
+   compatible = "fixed-partitions";
+   #address-cells = <1>;
+   #size-cells = <1>;
+
+   partition@0 {
+   label = "ubi";
+   reg = <0x0 0x0>;
+   };
+   };
+   };
 };
 
  {
@@ -165,10 +181,20 @@
reg = <0x0 0x40>;
};
 
-   partition@40 {
-   label = "ubi";
-   reg = <0x40 0x7c0>;
+   ubiconcat0: partition@40 {
+   label = "ubiconcat0";
+   reg = <0x40 0x5c0>;
+   };
+
+   ubiconcat1: partition@602 {
+   label = "ubiconcat1";
+   reg = <0x602 0x1f6>;
};
+   /*
+* U-boot always unconditionally marks block 768, 1020 
- 1023 as
+* bad blocks on each boot. To avoid conflicts with the 
nand
+* driver, manually skip them.
+*/
};
};
 };
diff --git a/target/linux/ath79/image/nand.mk b/target/linux/ath79/image/nand.mk
index 67690ca1c6..08afc82d41 100644
--- a/target/linux/ath79/image/nand.mk
+++ b/target/linux/ath79/image/nand.mk
@@ -376,6 +376,9 @@ TARGET_DEVICES += netgear_wndr4300tn
 
 define Device/netgear_wndr4300-v2
   SOC := qca9563
+  DEVICE_COMPAT_VERSION := 1.1
+  DEVICE_COMPAT_MESSAGE := Partition table has been changed to fix the \
+   first reboot issue. Please reflash factory image with nmrp or tftp.
   DEVICE_MODEL := WNDR4300
   DEVICE_VARIANT := v2
   UIMAGE_MAGIC := 0x27051956
@@ -387,6 +390,9 @@ TARGET_DEVICES += netgear_wndr4300-v2
 
 define Device/netgear_wndr4500-v3
   SOC := qca9563
+  DEVICE_COMPAT_VERSION := 1.1
+  DEVICE_COMPAT_MESSAGE := Partition table has been changed to fix the \
+   first reboot issue. Please reflash factory image with nmrp or tftp.
   DEVICE_MODEL := WNDR4500
   DEVICE_VARIANT := v3
   UIMAGE_MAGIC := 0x27051956
diff --git a/target/linux/ath79/nand/base-files/etc/board.d/05_compat-version 
b/target/linux/ath79/nand/base-files/etc/board.d/05_compat-version
new file mode 100644
index 00..238927aa7b
--- /dev/null
+++ b/target/linux/ath79/nand/base-files/etc/board.d/05_compat-version
@@ -0,0 +1,15 @@
+. /lib/functions.sh
+. /lib/functions/uci-defaults.sh
+
+board_config_update
+
+case "$(board_name)" in
+   netgear,wndr4300-v2|\
+   netgear,wndr4500-v3)
+   ucidef_set_compat_version "1.1"
+   ;;
+esac
+
+board_config_flush
+
+exit 0
-- 
2.30.2


___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

[PATCH v2 1/2] ath79: rework Netgear nand devices image recipe

2023-07-09 Thread Shiji Yang 
From: Shiji Yang 

In Netgear u-boot GPL code, nand devices uses this formula to locate the
rootfs offset.

offset = (((128 + KERNEL_SIZE) / BLOCK_SIZE) + 1) * BLOCK_SIZE;

Howerver, WNDR4500 source code incorrectly define the nand block size to
64k. In some cases, it causes u-boot can't get the correct rootfs offset,
which result in boot failure. This patch workaround it by padding kernel
size to (128k * n - 128 - 1). The additional char '\0' is used to ensure
the (128 + KERNEL_SIZE) can't be divided by the BLOCK_SIZE.

Fixes: https://github.com/openwrt/openwrt/issues/13050
Fixes: 3c1512a25d92 ("ath79: optimize the firmware recipe for Netgear NAND 
devices")
Tested-by: Yousaf 
Signed-off-by: Shiji Yang 
---
 target/linux/ath79/image/nand.mk | 7 ---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/target/linux/ath79/image/nand.mk b/target/linux/ath79/image/nand.mk
index 4b0932a100..67690ca1c6 100644
--- a/target/linux/ath79/image/nand.mk
+++ b/target/linux/ath79/image/nand.mk
@@ -285,7 +285,7 @@ define Device/meraki_mr18
 endef
 TARGET_DEVICES += meraki_mr18
 
-# fake rootfs is mandatory, pad-offset 64 equals (1 * uimage_header)
+# fake rootfs is mandatory, pad-offset 129 equals (2 * uimage_header + '\0')
 define Device/netgear_ath79_nand
   DEVICE_VENDOR := NETGEAR
   DEVICE_PACKAGES := kmod-usb2 kmod-usb-ledtrig-usbport
@@ -293,8 +293,9 @@ define Device/netgear_ath79_nand
   BLOCKSIZE := 128k
   PAGESIZE := 2048
   IMAGE_SIZE := 25600k
-  KERNEL := kernel-bin | append-dtb | lzma | uImage lzma | \
-   pad-offset $$(BLOCKSIZE) 64 | append-uImage-fakehdr filesystem 
$$(UIMAGE_MAGIC)
+  KERNEL := kernel-bin | append-dtb | lzma | \
+   pad-offset $$(BLOCKSIZE) 129 | uImage lzma | pad-extra 1 | \
+   append-uImage-fakehdr filesystem $$(UIMAGE_MAGIC)
   IMAGES := sysupgrade.bin factory.img
   IMAGE/factory.img := append-kernel | pad-to (KERNEL_SIZE) | \
append-ubi | check-size | netgear-dni
-- 
2.30.2


___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

[PATCH 2/2] ath79: fix second boot failure issue on Netgear WNDR4300 v2 and WNDR4500 v3

2023-07-08 Thread Shiji Yang 
From: Shiji Yang 

>From the Netgear u-boot GPL code[1]. Bootloader always unconditionally
marks block 768, 1020 - 1023 as bad blocks on each boot. This may lead
to conflicts with the OpenWrt nand driver since these blocks may be good
blocks. In this case, U-boot will override the oob of these blocks so
that break the ubi volume. The system will be damaged on the second boot.
To avoid this issue, manually skip these blocks by using "mtd-concat".

[1] 
https://www.downloads.netgear.com/files/GPL/EX7300v2series-V1.0.0.146_gpl_src.tar.bz2.zip

Fixes: https://github.com/openwrt/openwrt/issues/8878
Tested-by: Yousaf 
Signed-off-by: Shiji Yang 
---
 .../linux/ath79/dts/qca9563_netgear_wndr.dtsi | 32 +--
 target/linux/ath79/image/nand.mk  |  6 
 .../base-files/etc/board.d/05_compat-version  | 15 +
 3 files changed, 50 insertions(+), 3 deletions(-)
 create mode 100644 
target/linux/ath79/nand/base-files/etc/board.d/05_compat-version

diff --git a/target/linux/ath79/dts/qca9563_netgear_wndr.dtsi 
b/target/linux/ath79/dts/qca9563_netgear_wndr.dtsi
index a51fb1964b..9e075e46e0 100644
--- a/target/linux/ath79/dts/qca9563_netgear_wndr.dtsi
+++ b/target/linux/ath79/dts/qca9563_netgear_wndr.dtsi
@@ -90,6 +90,22 @@
linux,default-trigger = "phy1tpt";
};
};
+
+   ubi-concat {
+   compatible = "mtd-concat";
+   devices = < >;
+
+   partitions {
+   compatible = "fixed-partitions";
+   #address-cells = <1>;
+   #size-cells = <1>;
+
+   partition@0 {
+   label = "ubi";
+   reg = <0x0 0x0>;
+   };
+   };
+   };
 };
 
  {
@@ -165,10 +181,20 @@
reg = <0x0 0x40>;
};
 
-   partition@40 {
-   label = "ubi";
-   reg = <0x40 0x7c0>;
+   ubiconcat0: partition@40 {
+   label = "ubiconcat0";
+   reg = <0x40 0x5c0>;
+   };
+
+   ubiconcat1: partition@602 {
+   label = "ubiconcat1";
+   reg = <0x602 0x1f6>;
};
+   /*
+* U-boot always unconditionally marks block 768, 1020 
- 1023 as
+* bad blocks on each boot. To avoid conflicts with the 
nand
+* driver, Manually skip them.
+*/
};
};
 };
diff --git a/target/linux/ath79/image/nand.mk b/target/linux/ath79/image/nand.mk
index 7a3f478281..160394aa45 100644
--- a/target/linux/ath79/image/nand.mk
+++ b/target/linux/ath79/image/nand.mk
@@ -374,6 +374,9 @@ TARGET_DEVICES += netgear_wndr4300tn
 
 define Device/netgear_wndr4300-v2
   SOC := qca9563
+  DEVICE_COMPAT_VERSION := 1.1
+  DEVICE_COMPAT_MESSAGE := Partition table has changed to fix the first \
+   boot issue. Please reflash factory image with nmrp or tftp.
   DEVICE_MODEL := WNDR4300
   DEVICE_VARIANT := v2
   UIMAGE_MAGIC := 0x27051956
@@ -385,6 +388,9 @@ TARGET_DEVICES += netgear_wndr4300-v2
 
 define Device/netgear_wndr4500-v3
   SOC := qca9563
+  DEVICE_COMPAT_VERSION := 1.1
+  DEVICE_COMPAT_MESSAGE := Partition table has changed to fix the first \
+   boot issue. Please reflash factory image with nmrp or tftp.
   DEVICE_MODEL := WNDR4500
   DEVICE_VARIANT := v3
   UIMAGE_MAGIC := 0x27051956
diff --git a/target/linux/ath79/nand/base-files/etc/board.d/05_compat-version 
b/target/linux/ath79/nand/base-files/etc/board.d/05_compat-version
new file mode 100644
index 00..238927aa7b
--- /dev/null
+++ b/target/linux/ath79/nand/base-files/etc/board.d/05_compat-version
@@ -0,0 +1,15 @@
+. /lib/functions.sh
+. /lib/functions/uci-defaults.sh
+
+board_config_update
+
+case "$(board_name)" in
+   netgear,wndr4300-v2|\
+   netgear,wndr4500-v3)
+   ucidef_set_compat_version "1.1"
+   ;;
+esac
+
+board_config_flush
+
+exit 0
-- 
2.30.2


___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

[PATCH 1/2] ath79: rework Netgear nand devices image recipe

2023-07-08 Thread Shiji Yang 
From: Shiji Yang 

In Netgear u-boot GPL code, nand devices uses this formula to locate the
rootfs offset.

offset = (((128 + KERNEL_SIZE) / BLOCK_SIZE) + 1) * BLOCK_SIZE;

Howerver, WNDR4500 source code incorrectly define the nand block size to
64k. In some cases, it causes u-boot can't get the correct rootfs offset,
which result in boot failure. This patch workaround it by padding kernel
size to (128k * n - 128 - 1). The additional char "0xff" is used to
ensure the kernel size is not divisible.

Fixes: https://github.com/openwrt/openwrt/issues/13050
Fixes: 3c1512a25d92 ("ath79: optimize the firmware recipe for Netgear NAND 
devices")
Tested-by: Yousaf 
Signed-off-by: Shiji Yang 
---
 target/linux/ath79/image/nand.mk | 7 ---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/target/linux/ath79/image/nand.mk b/target/linux/ath79/image/nand.mk
index d06b44d6b3..7a3f478281 100644
--- a/target/linux/ath79/image/nand.mk
+++ b/target/linux/ath79/image/nand.mk
@@ -285,7 +285,7 @@ define Device/meraki_mr18
 endef
 TARGET_DEVICES += meraki_mr18
 
-# fake rootfs is mandatory, pad-offset 64 equals (1 * uimage_header)
+# fake rootfs is mandatory, pad-offset 129 equals (2 * uimage_header + 0xff)
 define Device/netgear_ath79_nand
   DEVICE_VENDOR := NETGEAR
   DEVICE_PACKAGES := kmod-usb2 kmod-usb-ledtrig-usbport
@@ -293,8 +293,9 @@ define Device/netgear_ath79_nand
   BLOCKSIZE := 128k
   PAGESIZE := 2048
   IMAGE_SIZE := 25600k
-  KERNEL := kernel-bin | append-dtb | lzma | uImage lzma | \
-   pad-offset $$(BLOCKSIZE) 64 | append-uImage-fakehdr filesystem 
$$(UIMAGE_MAGIC)
+  KERNEL := kernel-bin | append-dtb | lzma | \
+   pad-offset $$(BLOCKSIZE) 129 | uImage lzma | append-string -e '\xff' | \
+   append-uImage-fakehdr filesystem $$(UIMAGE_MAGIC)
   IMAGES := sysupgrade.bin factory.img
   IMAGE/factory.img := append-kernel | pad-to (KERNEL_SIZE) | \
append-ubi | check-size | netgear-dni
-- 
2.30.2


___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

[PATCH 0/2] ath79: fix boot failure on Netgear WNDR4300 v2

2023-07-08 Thread Shiji Yang 
From: Shiji Yang 

These two patches fix the boot failure issue on Netgear WNDR4300 v2
and WNDR4500 v3:

[1] 23.05-rc bricks WNDR4300v2
link: https://github.com/openwrt/openwrt/issues/13050
[2] ath79: NETGEAR WNDR4300v2 Bricked on Power Cycle After Flash
link: https://github.com/openwrt/openwrt/issues/8878

Shiji Yang (2):
  ath79: rework Netgear nand devices image recipe
  ath79: fix second boot failure issue on Netgear WNDR4300 v2 and
WNDR4500 v3

 .../linux/ath79/dts/qca9563_netgear_wndr.dtsi | 32 +--
 target/linux/ath79/image/nand.mk  | 13 ++--
 .../base-files/etc/board.d/05_compat-version  | 15 +
 3 files changed, 54 insertions(+), 6 deletions(-)
 create mode 100644 
target/linux/ath79/nand/base-files/etc/board.d/05_compat-version

-- 
2.30.2


___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

[PATCH v2] ramips: mt7620: fix urngd error by disabling CPU frequency scaling feature

2023-07-01 Thread Shiji Yang 
From: Shiji Yang 

Frequency scaling enables the MT7620 to reduce CPU frequency when receiving
MIPS SI_Sleep signal. However, the current clock driver can't detect the
change of the frequency and always provides a fixed clock frequency. This
may confuse urngd, making it unable to initialize. On the other hand, 580
MHz MIPS processor is already very weak today. Sleep mode may have negative
impact on performance. And energy saving is not significant since most
energy is consumed by peripherals such as WLAN radio. Therefore, disabling
it shoule be a good choice.

The systick driver determines whether to enable this feature based on the
compatible string "ralink,mt7620a-systick", so removing it can safely
disable the sleep mode. In this way, systick will still work in normal mode
just like other ralink SoCs such as MT7628.

This patch fixes the urngd init error:

user.err kernel: [9.961576] urngd: jent-rng init failed, err: 2

Signed-off-by: Shiji Yang 
---
v2:
Apply the fix to another variant mt7620n, too.
---
 target/linux/ramips/dts/mt7620a.dtsi | 2 +-
 target/linux/ramips/dts/mt7620n.dtsi | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/target/linux/ramips/dts/mt7620a.dtsi 
b/target/linux/ramips/dts/mt7620a.dtsi
index 4b6fa60dc8..c0fda35366 100644
--- a/target/linux/ramips/dts/mt7620a.dtsi
+++ b/target/linux/ramips/dts/mt7620a.dtsi
@@ -266,7 +266,7 @@
};
 
systick: systick@d00 {
-   compatible = "ralink,mt7620a-systick", 
"ralink,cevt-systick";
+   compatible = "ralink,cevt-systick";
reg = <0xd00 0x10>;
 
resets = < 28>;
diff --git a/target/linux/ramips/dts/mt7620n.dtsi 
b/target/linux/ramips/dts/mt7620n.dtsi
index 276bc13733..2579b4879e 100644
--- a/target/linux/ramips/dts/mt7620n.dtsi
+++ b/target/linux/ramips/dts/mt7620n.dtsi
@@ -231,7 +231,7 @@
};
 
systick: systick@d00 {
-   compatible = "ralink,mt7620a-systick", 
"ralink,cevt-systick";
+   compatible = "ralink,cevt-systick";
reg = <0xd00 0x10>;
 
resets = < 28>;
-- 
2.30.2


___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

[PATCH] ramips: do not print error log when mdio bus is disabled

2023-06-22 Thread Shiji Yang 
From: Shiji Yang 

The mdio bus is used to control externel switch. In most cases, they are
disabled, which is the normal behavior. Treating this as an error makes
no sense, so we need to change the notification level from error to info.

Fixes: a2acdf960704 ("ramips: mt7620: remove useless GMAC nodes")
Signed-off-by: Shiji Yang 
---
 target/linux/ramips/files/drivers/net/ethernet/ralink/mdio.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/target/linux/ramips/files/drivers/net/ethernet/ralink/mdio.c 
b/target/linux/ramips/files/drivers/net/ethernet/ralink/mdio.c
index a6448443c0..7e896644f8 100644
--- a/target/linux/ramips/files/drivers/net/ethernet/ralink/mdio.c
+++ b/target/linux/ramips/files/drivers/net/ethernet/ralink/mdio.c
@@ -257,7 +257,7 @@ err_free_bus:
 err_put_node:
of_node_put(mii_np);
 err_no_bus:
-   dev_err(priv->dev, "%s disabled", "mdio-bus");
+   dev_info(priv->dev, "%s disabled", "mdio-bus");
priv->mii_bus = NULL;
return err;
 }
-- 
2.30.2


___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

[PATCH] ramips: backport upstream mt762x PCIe driver error log fixes

2023-06-21 Thread Shiji Yang 
From: Shiji Yang 

These patches silence some mt762x PCIe driver error messeges by removing
the useless debugging codes and replacing incorrectly used 'dev_err()'
with 'dev_info()':

PCI: mt7621: Use dev_info() to log PCIe card detection [1]
mips: pci-mt7620: do not print NFTS register value as error log [2]
mips: pci-mt7620: use dev_info() to log PCIe device detection result [3]

Patch [1] has already been merged into the Linux 6.3 branch. Patches [2] and
[3] have been merged into the "mips-next" tree, and they will be part of the
upcoming Linux 6.5.

[1] 
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?h=v6.4-rc7=50233e105a0332ec0f3bc83180c416e6b200471e
[2] 
https://git.kernel.org/pub/scm/linux/kernel/git/mips/linux.git/commit/?id=9f9a035e6156a57d9da062b26d2a48d031744a1e
[3] 
https://git.kernel.org/pub/scm/linux/kernel/git/mips/linux.git/commit/?id=89ec9bbe60b61cc6ae3eddd6d4f43e128f8a88de

Signed-off-by: Shiji Yang 
---
 ...do-not-print-NFTS-register-value-as-.patch | 32 +++
 ...use-dev_info-to-log-PCIe-device-dete.patch | 39 +++
 ...-dev_info-to-log-PCIe-card-detection.patch | 31 +++
 3 files changed, 102 insertions(+)
 create mode 100644 
target/linux/ramips/patches-5.15/010-v6.5-01-mips-pci-mt7620-do-not-print-NFTS-register-value-as-.patch
 create mode 100644 
target/linux/ramips/patches-5.15/010-v6.5-02-mips-pci-mt7620-use-dev_info-to-log-PCIe-device-dete.patch
 create mode 100644 
target/linux/ramips/patches-5.15/110-v6.4-PCI-mt7621-Use-dev_info-to-log-PCIe-card-detection.patch

diff --git 
a/target/linux/ramips/patches-5.15/010-v6.5-01-mips-pci-mt7620-do-not-print-NFTS-register-value-as-.patch
 
b/target/linux/ramips/patches-5.15/010-v6.5-01-mips-pci-mt7620-do-not-print-NFTS-register-value-as-.patch
new file mode 100644
index 00..704e861b82
--- /dev/null
+++ 
b/target/linux/ramips/patches-5.15/010-v6.5-01-mips-pci-mt7620-do-not-print-NFTS-register-value-as-.patch
@@ -0,0 +1,32 @@
+From 9f9a035e6156a57d9da062b26d2a48d031744a1e Mon Sep 17 00:00:00 2001
+From: Shiji Yang 
+Date: Tue, 20 Jun 2023 18:43:22 +0800
+Subject: [PATCH 1/2] mips: pci-mt7620: do not print NFTS register value as
+ error log
+
+These codes are used to read NFTS_TIMEOUT_DELAY register value and
+write it into kernel log after writing the register. they are only
+used for debugging during driver development, so there is no need
+to keep them now.
+
+Tested on MT7628AN router Motorola MWR03.
+
+Signed-off-by: Shiji Yang 
+Reviewed-by: Sergio Paracuellos 
+Signed-off-by: Thomas Bogendoerfer 
+---
+ arch/mips/pci/pci-mt7620.c | 3 ---
+ 1 file changed, 3 deletions(-)
+
+--- a/arch/mips/pci/pci-mt7620.c
 b/arch/mips/pci/pci-mt7620.c
+@@ -274,9 +274,6 @@ static int mt7628_pci_hw_init(struct pla
+   val |= 0x50 << 8;
+   pci_config_write(NULL, 0, 0x70c, 4, val);
+ 
+-  pci_config_read(NULL, 0, 0x70c, 4, );
+-  dev_err(>dev, "Port 0 N_FTS = %x\n", (unsigned int) val);
+-
+   return 0;
+ }
+ 
diff --git 
a/target/linux/ramips/patches-5.15/010-v6.5-02-mips-pci-mt7620-use-dev_info-to-log-PCIe-device-dete.patch
 
b/target/linux/ramips/patches-5.15/010-v6.5-02-mips-pci-mt7620-use-dev_info-to-log-PCIe-device-dete.patch
new file mode 100644
index 00..5898a110ea
--- /dev/null
+++ 
b/target/linux/ramips/patches-5.15/010-v6.5-02-mips-pci-mt7620-use-dev_info-to-log-PCIe-device-dete.patch
@@ -0,0 +1,39 @@
+From 89ec9bbe60b61cc6ae3eddd6d4f43e128f8a88de Mon Sep 17 00:00:00 2001
+From: Shiji Yang 
+Date: Tue, 20 Jun 2023 18:43:23 +0800
+Subject: [PATCH 2/2] mips: pci-mt7620: use dev_info() to log PCIe device
+ detection result
+
+Usually, We only need to print the error log when there is a PCIe card but
+initialization fails. Whether the driver finds the PCIe card or not is the
+expected behavior. So it's better to log these information with dev_info().
+
+Tested on MT7628AN router Motorola MWR03.
+
+Signed-off-by: Shiji Yang 
+Reviewed-by: Sergio Paracuellos 
+Signed-off-by: Thomas Bogendoerfer 
+---
+ arch/mips/pci/pci-mt7620.c | 4 ++--
+ 1 file changed, 2 insertions(+), 2 deletions(-)
+
+--- a/arch/mips/pci/pci-mt7620.c
 b/arch/mips/pci/pci-mt7620.c
+@@ -331,7 +331,7 @@ static int mt7620_pci_probe(struct platf
+   rt_sysc_m32(RALINK_PCIE0_CLK_EN, 0, RALINK_CLKCFG1);
+   if (ralink_soc == MT762X_SOC_MT7620A)
+   rt_sysc_m32(LC_CKDRVPD, PDRV_SW_SET, PPLL_DRV);
+-  dev_err(>dev, "PCIE0 no card, disable it(RST)\n");
++  dev_info(>dev, "PCIE0 no card, disable it(RST)\n");
+   return -1;
+   }
+ 
+@@ -374,7 +374,7 @@ int pcibios_map_irq(const struct pci_dev
+   dev->bus->number, slot);
+   return 0;
+   }
+-  dev_err(>dev, "card - bus=0x%x, slot = 0x%x irq=%d\n",
++  dev_info(>dev, "card - bus=0x%x, slot = 0x%x irq=%d\n",
+

[PATCH] ramips: backport mt7621 PCIs initialization delay patch

2023-02-09 Thread Shiji Yang via openwrt-devel 
The sender domain has a DMARC Reject/Quarantine policy which disallows
sending mailing list messages using the original "From" header.

To mitigate this problem, the original message has been wrapped
automatically by the mailing list software.--- Begin Message ---
Some devices like ZBT WE1326 and ZBT WF3526-P and some Netgear models need
to delay phy port initialization after calling the mt7621_pcie_init_port()
driver function to get into reliable boots for both warm and hard resets.

Signed-off-by: Shiji Yang 
---
 ...t7621-Delay-phy-ports-initialization.patch | 52 +++
 ...t7621-Delay-phy-ports-initialization.patch | 52 +++
 2 files changed, 104 insertions(+)
 create mode 100644 
target/linux/ramips/patches-5.10/108-PCI-mt7621-Delay-phy-ports-initialization.patch
 create mode 100644 
target/linux/ramips/patches-5.15/108-PCI-mt7621-Delay-phy-ports-initialization.patch

diff --git 
a/target/linux/ramips/patches-5.10/108-PCI-mt7621-Delay-phy-ports-initialization.patch
 
b/target/linux/ramips/patches-5.10/108-PCI-mt7621-Delay-phy-ports-initialization.patch
new file mode 100644
index 00..ef03b00444
--- /dev/null
+++ 
b/target/linux/ramips/patches-5.10/108-PCI-mt7621-Delay-phy-ports-initialization.patch
@@ -0,0 +1,52 @@
+From 0cb2a8f3456ff1cc51d571e287a48e8fddc98ec2 Mon Sep 17 00:00:00 2001
+From: Sergio Paracuellos 
+Date: Sat, 31 Dec 2022 08:40:41 +0100
+Subject: PCI: mt7621: Delay phy ports initialization
+
+Some devices like ZBT WE1326 and ZBT WF3526-P and some Netgear models need
+to delay phy port initialization after calling the mt7621_pcie_init_port()
+driver function to get into reliable boots for both warm and hard resets.
+
+The delay required to detect the ports seems to be in the range [75-100]
+milliseconds.
+
+If the ports are not detected the controller is not functional.
+
+There is no datasheet or something similar to really understand why this
+extra delay is needed only for these devices and it is not for most of
+the boards that are built on mt7621 SoC.
+
+This issue has been reported by openWRT community and the complete
+discussion is in [0]. The 100 milliseconds delay has been tested in all
+devices to validate it.
+
+Add the extra 100 milliseconds delay to fix the issue.
+
+[0]: https://github.com/openwrt/openwrt/pull/11220
+
+Link: 
https://lore.kernel.org/r/20221231074041.264738-1-sergio.paracuel...@gmail.com
+Fixes: 2bdd5238e756 ("PCI: mt7621: Add MediaTek MT7621 PCIe host controller 
driver")
+Signed-off-by: Sergio Paracuellos 
+Signed-off-by: Lorenzo Pieralisi 
+---
+ drivers/staging/mt7621-pci/pci-mt7621.c | 2 ++
+ 1 file changed, 2 insertions(+)
+
+--- a/drivers/staging/mt7621-pci/pci-mt7621.c
 b/drivers/staging/mt7621-pci/pci-mt7621.c
+@@ -86,6 +86,7 @@
+ #define MEMORY_BASE   0x0
+ #define PERST_MODE_MASK   GENMASK(11, 10)
+ #define PERST_MODE_GPIO   BIT(10)
++#define INIT_PORTS_DELAY_MS   100
+ #define PERST_DELAY_MS100
+ 
+ /**
+@@ -521,6 +522,7 @@ static void mt7621_pcie_init_ports(struc
+   }
+   }
+ 
++  msleep(INIT_PORTS_DELAY_MS);
+   mt7621_pcie_reset_ep_deassert(pcie);
+ 
+   tmp = NULL;
diff --git 
a/target/linux/ramips/patches-5.15/108-PCI-mt7621-Delay-phy-ports-initialization.patch
 
b/target/linux/ramips/patches-5.15/108-PCI-mt7621-Delay-phy-ports-initialization.patch
new file mode 100644
index 00..de1d4cfc12
--- /dev/null
+++ 
b/target/linux/ramips/patches-5.15/108-PCI-mt7621-Delay-phy-ports-initialization.patch
@@ -0,0 +1,52 @@
+From 0cb2a8f3456ff1cc51d571e287a48e8fddc98ec2 Mon Sep 17 00:00:00 2001
+From: Sergio Paracuellos 
+Date: Sat, 31 Dec 2022 08:40:41 +0100
+Subject: PCI: mt7621: Delay phy ports initialization
+
+Some devices like ZBT WE1326 and ZBT WF3526-P and some Netgear models need
+to delay phy port initialization after calling the mt7621_pcie_init_port()
+driver function to get into reliable boots for both warm and hard resets.
+
+The delay required to detect the ports seems to be in the range [75-100]
+milliseconds.
+
+If the ports are not detected the controller is not functional.
+
+There is no datasheet or something similar to really understand why this
+extra delay is needed only for these devices and it is not for most of
+the boards that are built on mt7621 SoC.
+
+This issue has been reported by openWRT community and the complete
+discussion is in [0]. The 100 milliseconds delay has been tested in all
+devices to validate it.
+
+Add the extra 100 milliseconds delay to fix the issue.
+
+[0]: https://github.com/openwrt/openwrt/pull/11220
+
+Link: 
https://lore.kernel.org/r/20221231074041.264738-1-sergio.paracuel...@gmail.com
+Fixes: 2bdd5238e756 ("PCI: mt7621: Add MediaTek MT7621 PCIe host controller 
driver")
+Signed-off-by: Sergio Paracuellos 
+Signed-off-by: Lorenzo Pieralisi 
+---
+ drivers/pci/controller/pcie-mt7621.c | 2 ++