Running with CONFIG_HZ_PERIODIC=y keeps the scheduler tick running
continuously, which produces higher jitter and lower power efficiency.
In contrast, CONFIG_NO_HZ_IDLE=y (the upstream default) stops the tick
only when the CPU is idle, giving lower idle power and normal runtime
jitter.
An Intel N150-based router/firewall was tested using two kernel builds:
one with CONFIG_HZ_PERIODIC=y, and one with CONFIG_NO_HZ_IDLE=y. Power
consumption was measured while the system was essentially idle (no
meaningful traffic). The CONFIG_NO_HZ_IDLE=y build consistently used
less power.
Details: The two power-measurement methods were:
1. PkgWatt from turbostat (software)
2. Wall-power measurement using a Kill-A-Watt (hardware)
The test began by zeroing the Kill-A-Watt and simultaneously running:
turbostat --quiet --Summary --interval 10 --show Busy%,PkgWatt
The test duration was defined by the time required for the Kill-A-Watt
to accumulate 0.005 kWh, after which the average wattage was calculated.
Results:
+----------------------+-----------------+----------------+-----------+
| Metric | HZ_PERIODIC | NO_HZ_IDLE | Delta % |
+----------------------+-----------------+----------------+-----------+
| PkgWatt | 3.59 ± 0.38 | 3.38 ± 0.34 | -5.9 % |
+----------------------+-----------------+----------------+-----------+
| Avg wattage at wall | 12.47 | 12.00 | -3.77 % |
+----------------------+-----------------+----------------+-----------+
The mean PkgWatt difference is 210 mW (5.9%) in favor of
CONFIG_NO_HZ_IDLE=y, with a t-statistic of ~3.17 and p ≈ 0.002.
Wall-power measurements show a 470 mW (3.77%) reduction under
CONFIG_NO_HZ_IDLE=y.
Signed-off-by: John Audia <therealgraysky@proton.me>
Link: https://github.com/openwrt/openwrt/pull/21470
Signed-off-by: Robert Marko <robimarko@gmail.com>
Reading the fibre status of a RTL8214FC needs access to the
page register (31) and the extended page register (30).
The current implementation has two issues.
- The extended page register is not restored after changes
- Instead of register 30 its write-only sibling 29 is used.
This has the following side effect:
During regular polling kernel calls rtl8214fc_read_status
and determines the media status via __rtl8214fc_media_is_fibre.
Writing to register 29 a copy of that value is handed over
to register 30. This makes use of mdio tools for the first
port of the RTL8214FC hard. Register 30 is overwritten with
zero every second.
Change access from register 29 to register 30 and adapt
the sequence to restore register 30 contents at the end.
Signed-off-by: Markus Stockhausen <markus.stockhausen@gmx.de>
Link: https://github.com/openwrt/openwrt/pull/21393
Signed-off-by: Stijn Tintel <stijn@linux-ipv6.be>
The patch that adds MT7987 support to the mtk-2p5ge
driver does the following:
case MTK_2P5GPHY_ID_MT7987:
phy_clear_bits_mmd MTK_PHY_LED_ON_POLARITY
case MTK_2P5GPHY_ID_MT7988:
phy_set_bits_mmd.. MTK_PHY_LED_ON_POLARITY
phy_set_bits_mmd... MTK_PHY_LED_ON_POLARITY | xxx
This clearly resulted in the LED polarity of the 2.5G PHY
on the MT7987 being reversed. Remove redundant MMD operations
to fix the 2.5G PHY LED error on Bananapi BPi-R4 Lite.
Fixes: d62fc50f ("mediatek: import patches from SDK to support MT7987 Ethernet")
Signed-off-by: Chukun Pan <amadeus@jmu.edu.cn>
Drop several leftovers of SerDes configuration from PHY and DSA drivers.
Both drivers can be seen as free from any SoC-side SerDes stuff.
Signed-off-by: Jonas Jelonek <jelonek.jonas@gmail.com>
Link: https://github.com/openwrt/openwrt/pull/21360
Signed-off-by: Stijn Tintel <stijn@linux-ipv6.be>
Add the SerDes setup hooks in the PCS driver for RTL839x so that
pcs_config actually triggers configuration. Adjust the DTS of all
devices accordingly by adding pcs-handles and dropping phy-handles.
Signed-off-by: Jonas Jelonek <jelonek.jonas@gmail.com>
Link: https://github.com/openwrt/openwrt/pull/21360
Signed-off-by: Stijn Tintel <stijn@linux-ipv6.be>
Add a patch sequence needed to properly initialize 10G SerDes. This is
taken from the SDK mostly as-is ([1]).
Exit early from SerDes reset for now because it seems to cause some
issues on lower 5G SerDes.
[1] 30e7d6c8c2/sources/rtk-dms1250/src/dal/cypress/dal_cypress_construct.c (L215)
Co-authored-by: Markus Stockhausen <markus.stockhausen@gmx.de>
Signed-off-by: Jonas Jelonek <jelonek.jonas@gmail.com>
Link: https://github.com/openwrt/openwrt/pull/21360
Signed-off-by: Stijn Tintel <stijn@linux-ipv6.be>
Add basic SerDes setup functionality which determines and sets the
hardware mode of a SerDes, and does a SerDes reset. This is restricted
to the 10G SerDes only as the 5G SerDes are setup properly by default.
Further initialization will be needed for the modes to function properly
Signed-off-by: Jonas Jelonek <jelonek.jonas@gmail.com>
Link: https://github.com/openwrt/openwrt/pull/21360
Signed-off-by: Stijn Tintel <stijn@linux-ipv6.be>
Refactor the previously added SerDes reset sequence. Use the SerDes
MDIO interface instead of plain writes into the switchcore's register
space. Moreover, simplify the sequence because the SDK version is
unnecessarily complex.
Signed-off-by: Jonas Jelonek <jelonek.jonas@gmail.com>
Link: https://github.com/openwrt/openwrt/pull/21360
Signed-off-by: Stijn Tintel <stijn@linux-ipv6.be>
Add SerDes reset sequence mostly as-is from the SDK (except for
adjusting the register write calls to work with regmap).
Signed-off-by: Jonas Jelonek <jelonek.jonas@gmail.com>
Link: https://github.com/openwrt/openwrt/pull/21360
Signed-off-by: Stijn Tintel <stijn@linux-ipv6.be>
Interrupts for DWC3 node were completely mixed up - SPI interrupt 62 is
not listed in reference manual at all. It was also causing dtbs_check
warnings:
ipq5018-rdp432-c2.dtb: usb@8af8800 (qcom,ipq5018-dwc3): interrupt-names:0: 'pwr_event' was expected
ipq5018-rdp432-c2.dtb: usb@8af8800 (qcom,ipq5018-dwc3): interrupt-names: ['hs_phy_irq'] is too short
Warning itself was introduced by commit 53c6d854be4e ("dt-bindings: usb:
dwc3: Clean up hs_phy_irq in binding"), but this was trying to bring
sanity to the interrupts overall, although did a mistake for IPQ5018.
IPQ5018 does not have QUSB2 PHY and its interrupts should rather match
ones used in IPQ5332.
Correct it by using interrupts matching the bindings and reference
manual.
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Signed-off-by: George Moussalem <george.moussalem@outlook.com>
Link: https://github.com/openwrt/openwrt/pull/21454
Signed-off-by: Robert Marko <robimarko@gmail.com>
BDF for EAP623-Outdoor HD v1 was renamed in the repo, but ipq-wifi
was not updated to reflect that, so do it now to fix broken wifi.
Fixes: #21432
Signed-off-by: Robert Marko <robimarko@gmail.com>
In IPQ5018, the reference clock to the CMN PLL block from the on-board
Wi-Fi has its divider set to 2. This divider wasn't taken into
consideration when calculating the CMN PLL clock rate which meant the
resulting clock rate was doubled.
With the reference clock divider being accounted for in the driver,
correct the assigned clock rate to 4.8GHz.
Signed-off-by: George Moussalem <george.moussalem@outlook.com>
Link: https://github.com/openwrt/openwrt/pull/21453
Signed-off-by: Robert Marko <robimarko@gmail.com>
Add missing dt-bindings/include files needed for compilation of driver.
Enable compilation of the CMN PLL driver by adding the symbols to
Kconfig and Makefile.
Fixes: 468975a985 ("qualcommax: ipq50xx: backport upstreamed patches for adding ipq5018 CMN PLL support")
Signed-off-by: George Moussalem <george.moussalem@outlook.com>
Link: https://github.com/openwrt/openwrt/pull/21453
Signed-off-by: Robert Marko <robimarko@gmail.com>
This is tri-band WiFi6E capable router. Also Zyxel Nebula managed so no real local GUI. To open device 4 screws must be located uder the label.
Four latches are on front and two on each side. Better start from ethernet port side where 3 small latches are easy to handle.
FCC shows It's identical to WSQ65 sold as Zyxel Multy M6E but that's nowhare to be found yet. WSQ65 is not covered by this PR
Speficiations:
* SoC: Qualcomm IPQ5018
* RAM: 1GB DDR3
* Flash: Winbond W25N02KWZEIR 256MB
* UART: PCB "J3" is located left from front LED strip
(VCC/TX/RX/ /GND) 3.3V 115200n8
* Wi-Fi1: IPQ5018 (2x2 2.4 Ghz 802.11b/g/n/ax)
* Wi-Fi2: QCN6102 (2x2:2 5 Ghz 802.11an/ac/ax)
* Wi-Fi3: QCN6122 (2x2:2 6 Ghz 802.11an/ac/ax)
* Ethernet: QCA8337 4xLAN 1Gbit / 1xWAN 1Gbit
* Buttons: WPS , Reset
* LEDs: 13 in total
RGB power, RGB wan, RGB status (cloud), RGB wifi, Green wps
* FCCID: I8803891
*Flash Instructions starts with getting root:
connect uart to J3 connector next to the front LEDs
go to failsafe when this shows up in log:
"Press the [f] key and hit [enter] to enter failsafe mode"
execute:
mount_root
passwd -d root
reboot
logon as root:
look for 'Please press Enter to activate this console.'
login is root password is empty
execute:
fw_setenv DebugFlag=0x1
fw_setenv bootdelay=0x2
passwd -d root
backup ubi partition "rootfs" into safe space
reboot
*OpenWrt installation
stop uboot and execute:
setenv ipaddr 192.168.1.1
setenv serverip 192.168.1.10
tftpboot *-factory.ubi
flash rootfs
reset
or:
tftpboot *-initramfs-uImage.itb
bootm
use sysupgrade as usual
*restore OEM from backup
stop uboot and execute:
setenv ipaddr 192.168.1.1
setenv serverip 192.168.1.10
tftpboot *-initramfs-uImage.itb
bootm
transfer rootfs.bin backup and execute:
ubiformat /dev/mtd16 -y -f /tmp/rootfs.bin
Signed-off-by: Robert Senderek <robert.senderek@10g.pl>
Link: https://github.com/openwrt/openwrt/pull/21042
Signed-off-by: Robert Marko <robimarko@gmail.com>
The port media handling introduced before was to some extent just taken
over from the SDK. As a second step, improve that code now. Some code
can be deduplicated, a few statements removed and improved in general.
Signed-off-by: Jonas Jelonek <jelonek.jonas@gmail.com>
Link: https://github.com/openwrt/openwrt/pull/21385
Signed-off-by: Robert Marko <robimarko@gmail.com>
SFP modules still do not work that well across different devices. One
missing piece seems to be the bunch of magic values and bits set by the
SDK depending on which media is used on a port.
Take over code from the SDK for port media handling [1]. This applies
different sequences depending on whether it's 10G fiber, 1G fiber or DAC
cables to make it work best for each variant. Place the call to that
code below the configuration of a SerDes mode but before actually
activating that mode and powering on the SerDes. The SDK and our code
for RTL930x do that similarly.
Though we do not have any notion of media in pcs_config right now, do
similar to some SDK versions and set an appropriate media type for fiber
modes and SGMII (otherwise it doesn't work).
[1] 51c3390e0e/sources/rtk-dms1250/src/hal/phy/phy_rtl9310.c (L2302)
Signed-off-by: Jonas Jelonek <jelonek.jonas@gmail.com>
Link: https://github.com/openwrt/openwrt/pull/21385
Signed-off-by: Robert Marko <robimarko@gmail.com>
The Realtek SDK includes a lot of code around specific port media,
usually having quite some differences between 10G fiber, 1G fiber and
DAC cables. For each type, several magic values are set which in the end
usually make different kinds of links work optimal.
While there is currently no way to get that media information from the
kernel, add some fields as an enum to have a notion of different media
kinds. In additional steps, code for the subtargets can be taken over
from the SDK to handle different media.
Signed-off-by: Jonas Jelonek <jelonek.jonas@gmail.com>
Link: https://github.com/openwrt/openwrt/pull/21385
Signed-off-by: Robert Marko <robimarko@gmail.com>
Drop the '__always_unused' tags from two functions which are actually
used. This was missed during the big transition before.
Signed-off-by: Jonas Jelonek <jelonek.jonas@gmail.com>
Link: https://github.com/openwrt/openwrt/pull/21410
Signed-off-by: Robert Marko <robimarko@gmail.com>
Those config arrays still do not lineup with common conventions in the
driver in terms of naming. They are missing the driver and variant
prefix. Thus, line that up with how RTL930X code looks like.
- add 'rtpcs_' prefix since it's part of the PCS driver
- add '931x_' prefix because it's for RTL931X
- use 'cfg' instead of 'config' to shorten that a bit
Signed-off-by: Jonas Jelonek <jelonek.jonas@gmail.com>
Link: https://github.com/openwrt/openwrt/pull/21410
Signed-off-by: Robert Marko <robimarko@gmail.com>
In the RTL931X configuration code, the array size of configuration
arrays was still calculated with 'sizeof(...) / sizeof(...)'. There's a
dedicated macro in the kernel for exactly that usecase. Use that instead
to avoid possible errors and make the line shorter. The RTL930X code is
already doing it the good way.
Signed-off-by: Jonas Jelonek <jelonek.jonas@gmail.com>
Link: https://github.com/openwrt/openwrt/pull/21410
Signed-off-by: Robert Marko <robimarko@gmail.com>
In kernel coding style, it is highly disregarded to hide structures
behind typedefs ([1]). The PCS driver still contains a typedef for the
sds_config which was taken over from the PHY driver.
- drop the typedef, just declaring it as a struct
- give it the common 'rtpcs_' prefix
- adjust all usage locations
[1] https://www.kernel.org/doc/html/v6.18/process/coding-style.html#typedefs
Signed-off-by: Jonas Jelonek <jelonek.jonas@gmail.com>
Link: https://github.com/openwrt/openwrt/pull/21410
Signed-off-by: Robert Marko <robimarko@gmail.com>
I have contributed quite a lot changes recently and should be made
responsible for most of the code that has been added to the PCS driver
after it has been introduced by Markus.
FWIW, add myself as another module author so anything I produced here
doesn't fall back to someone else, i.e. Markus as currently the single
module author.
Signed-off-by: Jonas Jelonek <jelonek.jonas@gmail.com>
Link: https://github.com/openwrt/openwrt/pull/21410
Signed-off-by: Robert Marko <robimarko@gmail.com>
These patches were actually merged in kernel 6.19 instead of 6.18,
fix them to avoid confusing when moving to new kernel version.
While at it, refresh the RK3528 PCIE L1ss patch since it was
accepted in 6.19 as well.
Signed-off-by: Tianling Shen <cnsztl@immortalwrt.org>
Link: https://github.com/openwrt/openwrt/pull/21419
Signed-off-by: Robert Marko <robimarko@gmail.com>
Only use link-partner advertisement bits for 10GbE modes if they are
actually valid. Check LOCALOK and REMOTEOK bits and clear 10GbE modes
unless both of them are set.
Signed-off-by: Daniel Golle <daniel@makrotopia.org>
Replace downstream hack for RealTek PHYs with a more clean solution
which could make it upstream.
As SGMII in-band AN is broken on some platforms, or simply expected to
be disabled by default in phy/sgmii mode (ie. on-board PHYs with MDIO
for out-of-band configuration and status), a hack for the RealTek PHY
driver was introduced to unconditionally disable SGMII in-band
autonegotiation.
Meanwhile the kernel has gained a proper interface for PHY and PCS to
report in-band AN capabilities and enable/disable in-band, matching
PHY and PCS capabilities.
Thanks to Bevan Weiss' knowledge about how RealTek PHY SerDes registers
are being handled in RealTek's SDK this can now be greatly improved:
- report in-band capabilties
- let phylink set in-band matching PCS and PHY capabilities
- properly abstracted indirect access of SerDes registers
Signed-off-by: Daniel Golle <daniel@makrotopia.org>
RealTek's 2.5G PHYs suffer from an up to now inexplicable problem which
results in the SerDes mode not being properly setup and disabling
in-band AN leading to a timeout waiting for a busy-bit to clear. Up to
now there has been a crude work-around: resetting the PHY and trying
another time.
The cause has now been found as a wrong access to register PHYCR1 on
MDIO_MMD_VEND1 instead of MDIO_MMD_VEND2 when setting up ALDPS as well
as disabling the MDIO broadcast address 0.
In order to access MDIO_MMD_VEND2 on Clause-22-only busses a custom
.read_mmd and .write_mmd ops are implemented, mapping MDIO_MMD_VEND2 to
paged access as this is required.
Also, as ALDPS by design disables the SerDes PCS of the PHY in case the
link has been down for a while, move enabling ALDPS to the end of the
config_init function to not face problems when configuring the interface
mode and in-band AN.
Signed-off-by: Daniel Golle <daniel@makrotopia.org>
Let node unit address same as reg.
Signed-off-by: Ziyang Huang <hzyitc@outlook.com>
Link: https://github.com/openwrt/openwrt/pull/20482
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
Different boards use different port map. For example, some board may use
a GE port as WAN. So defining the led label in board-level is better.
Signed-off-by: Ziyang Huang <hzyitc@outlook.com>
Link: https://github.com/openwrt/openwrt/pull/20482
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
Different boards use different port map. Defining the port labels in
board-level is better.
Signed-off-by: Ziyang Huang <hzyitc@outlook.com>
Link: https://github.com/openwrt/openwrt/pull/20482
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
Some board only use some of them, so enable as necessary in
board-level dts.
Signed-off-by: Ziyang Huang <hzyitc@outlook.com>
Link: https://github.com/openwrt/openwrt/pull/20482
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
Convert all ops structures to the new rteth prefix.
Signed-off-by: Markus Stockhausen <markus.stockhausen@gmx.de>
Link: https://github.com/openwrt/openwrt/pull/21345
Signed-off-by: Robert Marko <robimarko@gmail.com>
Simplify netdev_ops initialization by moving the data
into the configuration structure.
Signed-off-by: Markus Stockhausen <markus.stockhausen@gmx.de>
Link: https://github.com/openwrt/openwrt/pull/21345
Signed-off-by: Robert Marko <robimarko@gmail.com>
The configuration data needs to reference the netdev_ops
in the future. Reorder it in a separate commit to avoid
confusion later.
Signed-off-by: Markus Stockhausen <markus.stockhausen@gmx.de>
Link: https://github.com/openwrt/openwrt/pull/21345
Signed-off-by: Robert Marko <robimarko@gmail.com>
There is no need to set the cpu port depending on the
given family. Remove it from the private control structure
and add the fixed value to the configuration structure.
Signed-off-by: Markus Stockhausen <markus.stockhausen@gmx.de>
Link: https://github.com/openwrt/openwrt/pull/21345
Signed-off-by: Robert Marko <robimarko@gmail.com>
The name of the configuration structure suggests that it
contains a list of registers. As it contains functions too
change the name according to other realtek drivers.
- "Invent" a new driver prefix "rteth"
- Rename the structure and variables to config/cfg
Signed-off-by: Markus Stockhausen <markus.stockhausen@gmx.de>
Link: https://github.com/openwrt/openwrt/pull/21345
Signed-off-by: Robert Marko <robimarko@gmail.com>
These patches fix bugs in a patch we backported.
These patch were cherry picked from upstream Linux because it references
a patch we backported in the fixes tag.
The patches were reordered to match the ordering in the upstream Linux kernel.
Fixes: 93173aee96 ("qualcommbe: ipq95xx: Add initial support for new target")
Link: https://github.com/openwrt/openwrt/pull/21366
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
This patch fixes a bug in a patch we backported.
This patch was cherry picked from upstream Linux because it references a
patch we backported in the fixes tag.
The first two patches are providing function needed by the last patch.
Fixes: 813ecda1f3 ("generic: backport phylink patches for PCS/PHY caps OPs")
Link: https://github.com/openwrt/openwrt/pull/21366
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
This patch fixes a bug in a patch we backported.
This patch was cherry picked from upstream Linux because it references a
patch we backported in the fixes tag.
Fixes: 48c9e55094 ("kernel: backport upstream Realtek PHY patches")
Link: https://github.com/openwrt/openwrt/pull/21366
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
These patches fix bugs in a patch we backported.
These patch were cherry picked from upstream Linux because it references
a patch we backported in the fixes tag.
Fixes: c990f6e156 ("linux: generic: net: dsa: mv88e6xxx LED support")
Link: https://github.com/openwrt/openwrt/pull/21366
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
This patch fixes a bug in a patch we backported.
This patch was cherry picked from upstream Linux because it references a
patch we backported in the fixes tag.
Fixes: 9d3009f426 ("airoha: major backport of Airoha Ethernet driver feature support")
Link: https://github.com/openwrt/openwrt/pull/21366
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
This patch fixes a bug in a patch we backported.
This patch was cherry picked from upstream Linux because it references a
patch we backported in the fixes tag.
The function phy_id_compare_vendor() is needed by the fix.
Refresh 782-05-v6.16-net-phy-Add-support-for-Aeonsemi-AS21xxx-PHYs.patch with the upstream code.
Fixes: 08a616b216 ("generic: backport support for Aeonsemi AS21xxx PHY")
Link: https://github.com/openwrt/openwrt/pull/21366
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
This patch fixes a bug in a patch we backported.
This patch was cherry picked from upstream Linux because it references a
patch we backported in the fixes tag.
Fixes: 813ecda1f3 ("generic: backport phylink patches for PCS/PHY caps OPs")
Link: https://github.com/openwrt/openwrt/pull/21366
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
This patch fixes a bug in some patches we backported.
This patch was cherry picked from upstream Linux because it references a
patch we backported in the fixes tag.
Link: https://github.com/openwrt/openwrt/pull/21366
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
This fixes a bug introduced in a patch we backported.
This patch was cherry picked from upstream Linux because it references a
patch we backported in the fixes tag.
Fixes: 91ce7f606a ("generic: backport upstream v6.16 r8169 patches")
Link: https://github.com/openwrt/openwrt/pull/21366
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
These formally pending patches were merged into upstream Linux some time
ago. Move them to the backports folder and add the kernel version they
were added to the file name.
Link: https://github.com/openwrt/openwrt/pull/21366
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
