Fix BIND entry with DP=0 issue for Wifi Tx
Without this patch, the PPE entry state could be set to BIND
unexpectedly, adds a check to confirm if the copied entry
state is UNBIND.
[Release-log]
N/A
Change-Id: I49825572617eb804cda18e8f054b9106f26926bb
Reviewed-on: https://gerrit.mediatek.inc/c/openwrt/feeds/mtk_openwrt_feeds/+/8498669
Change qdma dmad from sram to dram
[Release-log]
-dmad in sram and payload in dram may probabilistic cause control
path is incoherent with payload path
-causing the actual packet sent is not the one
you really want
Change-Id: Ieeca5093f3cb24e07d659c8bec10fbaa0bbb336a
Reviewed-on: https://gerrit.mediatek.inc/c/openwrt/feeds/mtk_openwrt_feeds/+/7912387
Remove QDMA global configuration for PKT_RX_WDONE
-- customer corner test case may occur qmda rx hang
-- DE confirm this item may cause qdma rx hang, it is hw bug
[Release-log]
Change-Id: I104ffbcdf140f8f7bf66d20b3f2ad349d733158f
Reviewed-on: https://gerrit.mediatek.inc/c/openwrt/feeds/mtk_openwrt_feeds/+/6270079
Change code for memory free which may cause memory leak
-- memory leak occurs when user use DRAM for DMAD
-- SRAM ==1, no need free ring->dma
-- SRAM ==0, DMAD memory should be freed in mtk_rx_clean
[Release-log]
N/A
Change-Id: I599d3e38c66d67c0e9bfd7afc3e8f773258f97db
Reviewed-on: https://gerrit.mediatek.inc/c/openwrt/feeds/mtk_openwrt_feeds/+/6182630
Change ADMA RX HANG condition
-- ADMA RX HANG condition
- PSE p0 output queue is not zero
- CDM1 FSM indication CDM is from PSE to ADMA status
- ADMA DBG MONITOR show CURR_STAT is zero
- CDM_FIFO_RDY is zero
- remove check RX_FIFO_WCNT is zero because sometimes it is not zero
[Release-log]
N/A
Change-Id: I666d3df5eddc128f6f2fc4df44b9c76aa8b64254
Reviewed-on: https://gerrit.mediatek.inc/c/openwrt/feeds/mtk_openwrt_feeds/+/6182238
Add configurations to enable WDMA Rx ring full drop for
solving Panther AX7800/AX8400 5G(MT7915) WA CPU bound issue.
If without this patch, system might run into WiFi Tx/Rx
deadlock issue or WiFi Tx small packet low throughput issue.
[Release-log]
N/A
Change-Id: I57cd4a8e3ae19bdcb34d7d042989b7c1327ea08e
Reviewed-on: https://gerrit.mediatek.inc/c/openwrt/feeds/mtk_openwrt_feeds/+/6193220
Fix the issue of mistakenly deleting entries in foe_clear_entry.
When packets are forwarded in the 6RD scenario,
HNAT entry is mistakenly deleted.
This patch fix it.
[Release-log]
N/A
Change-Id: I7ece4115f07eaca354d2c0301d6cafb2ba6e539c
Reviewed-on: https://gerrit.mediatek.inc/c/openwrt/feeds/mtk_openwrt_feeds/+/7531312
Fix QDMA TX queue page error issue.
If the TX queue page is changed before hnat_qos_shaper_ebl function,
it may cause the function to set queue config on wrong TX queue page.
In order to avoid this situation, we will check queue ID to
switch to correct TX queue page.
If without this patch, QDMA TX queue config will be wrong
when the numbers of TX queue is greater than 16.
[Release-log]
N/A
Change-Id: I42b013982885830355b4108d6bc49f2feac1ef08
Reviewed-on: https://gerrit.mediatek.inc/c/openwrt/feeds/mtk_openwrt_feeds/+/8203881
Fix refcount underflow issue in the pending_work.
If one of the Ethernet interface is down, the pending_work should not
call to mtk_stop() function again to avoid a refcount underflow.
Without this patch, the ETH may experience the kernel panic which
caused by a refcount underflow.
[Release-log]
N/A
Change-Id: I4e1f40640c09372cddad57994da03f70107f133a
Reviewed-on: https://gerrit.mediatek.inc/c/openwrt/feeds/mtk_openwrt_feeds/+/8324564
This makes Linux use correct switch ports again.
Fixes: fff279f4a712 ("bcm53xx: backport DT changes from v6.5")
Fixes: https://github.com/openwrt/openwrt/issues/13548
Signed-off-by: Rafał Miłecki <rafal@milecki.pl>
(cherry picked from commit a912ee74d6ca08020933dcdb9ce791e74244c25b)
Among other changes this commit makes Linux use correct switch ports
again.
Fixes: fff279f4a712 ("bcm53xx: backport DT changes from v6.5")
Signed-off-by: Rafał Miłecki <rafal@milecki.pl>
(cherry picked from commit a67af19bc84e98588c307af9b08686bde9dd38d5)
We now have all raw ports defined in bcm-ns.dtsi. Leave only lables in
custom device files.
Signed-off-by: Rafał Miłecki <rafal@milecki.pl>
(cherry picked from commit 08ce0c76d7d7daad5e9382d51960d69f4b8b8f3a)
So far every build of a single bcm53xx Target Profile (it means: when
NOT using CONFIG_TARGET_MULTI_PROFILE) resulted in all target devices
images being built. Now it only builds the one matching selected
profile.
Fixes: #13572
Suggested-by: Jonas Gorski <jonas.gorski@gmail.com>
Signed-off-by: Rani Hod <rani.hod@gmail.com>
[rmilecki: update commit subject + body & move PROFILES line]
Signed-off-by: Rafał Miłecki <rafal@milecki.pl>
(cherry picked from commit 802a5f5cb4a7b42d25e82b787d7ab1323a20183f)
ASUS RT-AC3100 is ASUS RT-AC88U without the external switch.
OpenWrt forum users effortless and ktmakwana have confirmed that there are
revisions with either 4366b1 or 4366c0 wireless chips.
Therefore, include firmware for 4366b1 along with 4366c0. This way, all
hardware revisions of the router will be supported by having brcmfmac use
the firmware file for the wireless chip it detects.
Signed-off-by: Arınç ÜNAL <arinc.unal@arinc9.com>
(cherry picked from commit 2214bab3503981fe6168746acd13044a9d5e89e7)
Backport the patch that adds the DT for ASUS RT-AC3100.
Signed-off-by: Arınç ÜNAL <arinc.unal@arinc9.com>
(cherry picked from commit b7ee8c9f83ea0e3b861e6b71b08ed7a62066d149)
Ensure the MAC address for all NanoPi R1 boards is assigned uniquely for
each board.
The vendor ships the device in two variants; one with and one without
eMMC; but both without static mac-addresses.
In order to assign both board types unique MAC addresses, fall back on
the same method used for the NanoPi R2S and R4S in case the EEPROM
chip is not present by generating the board MAC from the SD card CID.
[0] https://wiki.friendlyelec.com/wiki/index.php/NanoPi_R1#Hardware_Spec
Similar too and based on:
commit b5675f500daf ("rockchip: ensure NanoPi R4S has unique MAC address")
Co-authored-by: David Bauer <mail@david-bauer.net>
Signed-off-by: Jan-Niklas Burfeind <git@aiyionpri.me>
Doing a simple ping to my device shows this:
64 bytes from 10.0.253.101: icmp_seq=1 ttl=64 time=2.00 ms
64 bytes from 10.0.253.101: icmp_seq=2 ttl=64 time=2.02 ms
64 bytes from 10.0.253.101: icmp_seq=3 ttl=64 time=1.68 ms
64 bytes from 10.0.253.101: icmp_seq=4 ttl=64 time=1.91 ms
64 bytes from 10.0.253.101: icmp_seq=5 ttl=64 time=1.92 ms
64 bytes from 10.0.253.101: icmp_seq=6 ttl=64 time=2.04 ms
Some users even report higher values on older kernels:
64 bytes from 192.168.1.10: seq=0 ttl=64 time=0.612 ms
64 bytes from 192.168.1.10: seq=1 ttl=64 time=2.852 ms
64 bytes from 192.168.1.10: seq=2 ttl=64 time=2.719 ms
64 bytes from 192.168.1.10: seq=3 ttl=64 time=2.741 ms
64 bytes from 192.168.1.10: seq=4 ttl=64 time=2.808 ms
The problem is that the governor is set to Ondemand, which causes
the CPU to clock all the way down to 48MHz in some cases.
Switching to performance governor:
64 bytes from 10.0.253.101: icmp_seq=1 ttl=64 time=0.528 ms
64 bytes from 10.0.253.101: icmp_seq=2 ttl=64 time=0.561 ms
64 bytes from 10.0.253.101: icmp_seq=3 ttl=64 time=0.633 ms
64 bytes from 10.0.253.101: icmp_seq=4 ttl=64 time=0.526 ms
In theory, using the Performance governor should increase power draw,
but it looks like it really does not matter for this soc.
Using a calibrated precision DC power supply (cpu idle):
Ondemand
24.00V * 0.134A = 3.216 Watts
48.00V * 0.096A = 4.608 Watts
Performance
24.00V * 0.135A = 3.240 Watts
48.00V * 0.096A = 4.608 Watts
Let's simply switch to the Performance governor by default
to fix the general jittery behaviour on devices using this soc.
Tested on: MikroTik wAP ac
Fixes: #13649
Reviewed-by: Robert Marko <robimarko@gmail.com>
Reviewed-by: Thibaut VARÈNE <hacks@slashdirt.org>
Signed-off-by: Koen Vandeputte <koen.vandeputte@citymesh.com>
(cherry picked from commit b8e52852bd62236a2a84663b4592d221ebc64cb4)
The compex WPJ563 actually has both usb controllers wired:
usb0 --> pci-e slot
usb1 --> pin header
As the board exposes it for generic use, enable this controller too.
fixes: #13650
Signed-off-by: Koen Vandeputte <koen.vandeputte@citymesh.com>
(cherry picked from commit 9188c77cbee55a933d0fa75c74e175fbc52c556d)
Adds generic support for sysupgrading on eMMC-based devices.
Provide function emmc_do_upgrade and emmc_copy_config to be used in
/lib/upgrade/platform.sh instead of redundantly implementing the same
logic over and over again.
Similar to generic sysupgrade on NAND, use environment variables
CI_KERNPART, CI_ROOTPART and newly introduce CI_DATAPART to indicate
GPT partition names to be used. On devices with more than one MMC
block device, CI_ROOTDEV can be used to specify the MMC device for
partition name lookups.
Also allow to select block devices directly using EMMC_KERN_DEV,
EMMC_ROOT_DEV and EMMC_DATA_DEV, as using GPT partition names is not
always an option (e.g. when forced to use MBR).
To easily handle writing kernel and rootfs make use of sysupgrade.tar
format convention which is also already used for generic NAND support.
Signed-off-by: Enrico Mioso <mrkiko.rs@gmail.com>
Signed-off-by: Daniel Golle <daniel@makrotopia.org>
CC: Li Zhang <li.zhang@gl-inet.com>
CC: TruongSinh Tran-Nguyen <i@truongsinh.pro>
(cherry picked from commit 57c1f3f9c5c699cc215bebde772552787c632570)
When the membase and pci_dev pointer were moved to a new struct in priv,
the actual membase users were left untouched, and they started reading
out arbitrary memory behind the struct instead of registers. This
unfortunately turned the RNG into a constant number generator, depending
on the content of what was at that offset.
To fix this, update geode_rng_data_{read,present}() to also get the
membase via amd_geode_priv, and properly read from the right addresses
again.
Closes#13417.
Reported-by: Timur I. Davletshin <timur.davletshin@gmail.com>
Tested-by: Timur I. Davletshin <timur.davletshin@gmail.com>
Suggested-by: Jo-Philipp Wich <jo@mein.io>
Signed-off-by: Jonas Gorski <jonas.gorski@gmail.com>
(cherry picked from commit 09d13cd8d87cc50fde67bbe81c6cca4b799b2724)
Add spinlock mechanism for mtk_rmw api.
1. When multiple threads operate on the same register resource
which include multiple pins, it will make the register resource
wrong to control. So we add spinlock to avoid this case.
[Release-log]
This patch adds spinlock mechanism to protect mtk_rmw. Without it,
you may suffer from some unexpected problems such as race conidtion
while interrupt occured. And this will lead to pin setting fail.
Hence, we strongly recommand you to merge this patch in your code
base.
Change-Id: I1128dc16cb683b89c2cd9f9138f32552abb00400
Reviewed-on: https://gerrit.mediatek.inc/c/openwrt/feeds/mtk_openwrt_feeds/+/7962757
