Per-CPU data structures consume ~100-200KB each.
On a 4-core system configured to NR_CPUS=4, this frees approx 76 MB
of RAM: (512 - 4) × 150 KB = ~76 MB
Note: CONFIG_NR_CPUS_RANGE_{BEGIN,END}= and CONFIG_NR_CPUS_DEFAULT= are
set by the build system and will default to 2/512/64 per arch/x86/Kconfig
These are harmless metadata and don't affect memory allocation.
John Audia [Mon, 5 Jan 2026 20:02:37 +0000 (15:02 -0500)]
x86/64: 6.18: enable recent MITIGATION options
These mitigations are low-overhead, upstream-supported hardening options
that only activate on CPUs affected by their respective vulnerabilities.
Enabling them provides consistent, defense-in-depth coverage across Intel
and AMD systems without impacting unaffected hardware.
Detailed list:
- CONFIG_MITIGATION_SRSO to guard against known a vulnerability found on
AMD processors (Zen generations 1-4) for sure, maybe others. This is
tracked under CVE-2023-20569.
- CONFIG_MITIGATION_ITS to guard against a bug in BPU on some Intel CPUs
that may allow Spectre V2 style attacks. We never enabled this option
(and its dependencies).
- CONFIG_MITIGATION_SRBDS to guard against Special Register Buffer Data
Sampling on affected Intel CPUs (CVE-2020-0543), preventing cross-core
leakage of RDRAND/RDSEED/EGETKEY values.
- CONFIG_MITIGATION_SLS to guard against Spectre-v4 gadgets on x86 by
inserting speculation barriers around RET/JMP/CALL sites when required
by CPU/microcode state.
- CONFIG_MITIGATION_CALL_DEPTH_TRACKING to guard against speculative
call-stack underflow on x86 by enabling hardware-assisted depth
tracking where supported, reducing exposure to RET-based misprediction
attacks.
- CONFIG_MITIGATION_UNRET_ENTRY to guard against RET-based speculation
attacks on x86 by replacing vulnerable function returns in kernel
entry paths with UNRET sequences when required by CPU/microcode state.
John Audia [Fri, 2 Jan 2026 16:55:24 +0000 (11:55 -0500)]
rtl8812au-ct: restrict to kernels ≤ 6.18
The rtl8812au-ct driver is obsolete and replaced by rtw88. It will need
tons of work to compile against 6.18 so for now limit it to 6.12.
Co-authored-by: Mieczyslaw Nalewaj <namiltd@yahoo.com> Signed-off-by: John Audia <therealgraysky@proton.me> Link: https://github.com/openwrt/openwrt/pull/21078 Signed-off-by: Robert Marko <robimarko@gmail.com>
John Audia [Sun, 21 Dec 2025 14:00:35 +0000 (09:00 -0500)]
kernel: sound: 6.18: update module files
This kernel reorganized HDA drivers into sound/hda/ subdirectories and
split codec drivers into modular components. Core modules moved to
sound/hda/{core,common,codecs,controllers}/ with version conditionals
(@ge6.18/@lt6.18) added for backward compatibility.
John Audia [Sat, 28 Mar 2026 09:38:05 +0000 (05:38 -0400)]
kernel/x86: restore files for v6.12
This is an automatically generated commit which aids following Kernel patch
history, as git will see the move and copy as a rename thus defeating the
purpose.
For the original discussion see:
https://lists.openwrt.org/pipermail/openwrt-devel/2023-October/041673.html
Replace the two-step hrtimer initialization pattern with a single
consolidated call to hrtimer_setup().
The legacy approach of calling hrtimer_init() followed by manual
assignment to timer.function is deprecated. The new hrtimer_setup()
helper atomically initializes the timer and assigns the callback
function in one operation, eliminating the race-prone intermediate
state where the timer is initialized but lacks a handler.
mac80211: ath9k: gpio: adapt to 6.16+ gpio_chip API change
Linux 6.16 changed the return type of gpio_chip.set() from void to int.
Add a version check so the driver builds correctly on both older and
newer kernels[1].
Reintroduce old-style debugfs file_operations for kernels < 6.14 and
switch the drivers to use debugfs_short_fops + debugfs_create_file_aux
on >= 6.14. This restores compatibility with older kernels while keeping
the new debugfs API working on 6.14+.
Kernel since version 6.16 defines `SOCKWQ_ASYNC_NOSPACE` and
SOCKWQ_ASYNC_WAITDATA` in the socket_flags enum, which causes redefinition
errors when compiling the backport package[1].
Since kernel 6.12 also has them defined, the test and definition of these
constants have been completely abandoned. Thanks to this, there are
no compilation errors on either kernel 6.12 or 6.18.
platform/mikrotik: adjust hc_wlan read-callback for 6.18
Include <linux/version.h> and use preprocessor checks to select the appropriate
prototype and definition for hc_wlan_data_bin_read. The third parameter of bin_attribute
read callbacks was changed to 'const struct bin_attribute *' in Linux 6.18; this
change prevents compilation errors on newer kernels while preserving compatibility
with older ones
kbuild: extract modules.builtin.modinfo from vmlinux.o
Partially reverse https://web.git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?h=linux-6.18.y&id=39cfd5b12160be4f57df1c3ba60139741c827616
to prevent generation of empty modules.builtin.modinfo and modules.builtin
files that cause modules compilation errors.
If an out-of-tree package or any kernel-install rule ran modprobe xyz while
the build was still in progress, and xyz had been configured =y, a clean tree
would already have xyz listed in modules.builtin; with the empty file produced
by the buggy rule it was missing, so modprobe emitted "module xyz not found"
even though the code was sitting inside the freshly built vmlinux.
serial: 8250: 6.18: add UPIO_AU case to set_io_from_upio()
This patch fixes the "Unsupported UART type 4" error by adding support
for the UPIO_AU I/O type in set_io_from_upio() (used by Au1x00 and
RT288x). It assigns the correct serial input/output functions
(io_serial_in, io_serial_out) for proper operation when UPIO_AU is
configured.
Backport minor fixes for the eip93 driver from upstream.
Signed-off-by: Aleksander Jan Bajkowski <olek2@wp.pl> Signed-off-by: Chukun Pan <amadeus@jmu.edu.cn> Link: https://github.com/openwrt/openwrt/pull/21078 Signed-off-by: Robert Marko <robimarko@gmail.com>
This patch set introduces support for using the in-tree (mainline)
EIP93 crypto driver for kernel 6.18 and later, along with additional
improvements and fixes:
- Conditional Kconfig/Makefile handling for crypto-hw-eip93 to enable use of the mainline driver with kernel 6.18+.
- Patch 926: Use software AES fallback for small requests in the EIP93 driver.
- Patch 927: Add `mediatek,mtk-eip93` compatible string for upstream kernel device trees.
- change phy_driver_register and phy_driver_unregister function calls
to phy_drivers_register and phy_drivers_unregister for compatibility
with kernel 6.18
- replace PHY_ANY_ID with "MATCH ANY PHY"
This is an automatically generated commit which aids following Kernel patch
history, as git will see the move and copy as a rename thus defeating the
purpose.
For the original discussion see:
https://lists.openwrt.org/pipermail/openwrt-devel/2023-October/041673.html
Kevin Staley [Mon, 29 Dec 2025 13:53:20 +0000 (07:53 -0600)]
kernel: qca8k: fix host FDB on multi-CPU
On qca8k multi-CPU-port setups (e.g. qca8337 with ports 0+6 as CPU),
bridging switch user ports that use different conduits can make the host
reachable only from the ports tied to the last-programmed CPU port.
Add a pending kernel patch which makes qca8k merge CPU/DSA-port FDB
programming, so host FDB entries end up on all relevant CPU ports.
Fixes: openwrt/openwrt#17891 Signed-off-by: Kevin Staley <glaciertablet@gmail.com> Link: https://github.com/openwrt/openwrt/pull/21317 Signed-off-by: Robert Marko <robimarko@gmail.com>
realtek: mdio: provide individual bus probing function
rtmdio_probe() is a do-it-all setup function. It creates one
control structure and one bus. In the future multiple busses
will be created. As a preparation carve out the bus specific
part into an individual probing function.
Until now the central control structure is allocated via a call to
devm_mdiobus_alloc_size(). This will not be possible any longer when
multiple busses will be implemented in a future commit.
Relax that as follows:
- Define a new private "channel" structure for a mdio bus
- Allocate the central control structure with a dedicated alloc()
- Allocate only the channel structure during bus setup
- Link the channel to the central structure via chan->ctrl
Reorganize the probing function so that it becomes clearer that
the control structure is setup first and afterwards the bus is
registered.
Add a new helper macro rtmdio_ctrl_from_bus that encapuslates
the current ctrl=bus->priv lookup. This is a preparation for
the future multi-channel driver architecture. With an upcoming
commit the structures will be changed as follows:
- ctrl: contains the generic data structurs
- chan: contains the channel specific structure
This will involve changing the pointers between them
old lookup chain: ctrl = bus->ctrl
new lookup chain: ctrl = bus->chan->ctrl
The helper macro allows to easily switch the lookup in one
central location. While we are here fix a whitespace issue.
realtek: mdio: setup topology from control structure
The topology setup is bus independent and can be derived completely
from the control structure. Adapt the call parameters accordingly.
The call location is quite confusing at the moment. Being no longer
dependent from the bus call it where it makes most sense. This is
directly after the mapping setup in rtmdio_map_ports(). Doing other
bus dependent setup between these two functions is not needed
any longer.
The port specific attributes of the central control structure
have been moved over to a separate port structure. Do the same
for the (up to 4) busses. Establish a separate bus structure
that will hold data about each bus and use it in the control
structure. As a first usage type move the is_c45 attribute over.
realtek: mdio: move phy_node attribute into port structure
The phy_node attribute is defined per port. Move it into the new
port structure. Now it is clear that it belongs to the port.
While we are here rename it to dn (aka device_node) to align with
upstream style. As all usage locations must be adapted it makes
no sense to make two commits (relocate/rename) to change the
code twice.
realtek: mdio: move smi_addr attribute into port structure
The smi_addr attribute is defined per port. Move it into the new
port structure. As the devices have a maximum of 56 addresses
save some space and convert it to type u8.
While we are here harden the mapping routine that reads these
addresses from the DTS. For this check the value that is read into
smi_addr. This is usually the MDIO standard 0..31. Sadly RTL839x
devices are an exception from that and allow addresses 0..51.
To avoid device specific if/then/else cases for now implement
a "light" consistency check.
realtek: mdio: move smi_bus attribute into port structure
The smi_bus attribute is defined per port. Move it into the new
port structure. As the devices have a maximum of 4 busses save
some space and convert it to type u8.
While we are here fix a whitespace issue and rename the helper
variable in rtmdio_map_ports() to smi_bus to align with the
structure attribute.
The central control structure of the mdio bus holds several
attributes. These target two different objects. Some of them
are for the (up to 56) controller ports, some of them are for
the (up to 4) controller busses.
Establish a separate port structure that will hold data about
each port and use it in the control structure. As a first
usage type move the page attribute over.
Daniel Golle [Thu, 26 Mar 2026 04:00:28 +0000 (04:00 +0000)]
kernel: add DSA driver for MaxLinear MxL862xx switches
Backport upstream driver and apply pending downstream patches to
support using the MaxLinear MxL86252 and MxL86282 switches.
The driver supports a native proprietary 8-byte DSA special tag format
(mxl862xx) as well as using an 802.1Q-based DSA tag (mxl862xx-8021q).
All basic bridge, VLAN and LAG operations are supported. A single port
can be used as mirror port. Hardware counters are made available as
ethtool stats or directly serve as interface counters (bytes,
packets).
The switch runs a complex ZephyrOS-based firmware on an integrated
ARC microcontroller, the driver uses the firmware management API over
MDIO to interact with the switch hardware.
Note that the firmware needs to be rather recent (WSP 1.0.78 or later)
to work well with this driver. It can be updated at runtime using devlink.
Signed-off-by: Daniel Golle <daniel@makrotopia.org>
John Crispin [Thu, 5 Mar 2026 11:57:29 +0000 (12:57 +0100)]
qualcommax: ipq807x: add CMN PLL clock controller support
Add IPQ8074 support to the upstream CMN PLL driver. The CMN PLL block
is identical to IPQ6018 with the same output clocks (bias_pll_cc_clk
at 300 MHz and bias_pll_nss_noc_clk at 416.5 MHz).
John Crispin [Thu, 5 Mar 2026 11:57:22 +0000 (12:57 +0100)]
qualcommax: ipq60xx: add CMN PLL clock controller support
Add IPQ6018 support to the upstream CMN PLL driver. The CMN PLL at
0x9b000 generates the 12 GHz base clock feeding the networking
subsystem. Its output clocks (bias_pll_cc_clk at 300 MHz and
bias_pll_nss_noc_clk at 416.5 MHz) replace the previous fixed-clock
stubs and are found by GCC via global clock name lookup.
John Crispin [Thu, 5 Mar 2026 13:24:30 +0000 (14:24 +0100)]
qualcommax: ipq60xx: mark gcc_xo_clk_src as CLK_IS_CRITICAL
The XO clock source is always-on in hardware and cannot be gated.
Without CLK_IS_CRITICAL, the CMN PLL runtime PM suspend cascades a
disable up to gcc_xo_clk_src, causing a branch status timeout warning.
The IPQ8074 GCC driver already marks this clock as critical.
Dmitry Mostovoy [Mon, 9 Feb 2026 16:43:41 +0000 (11:43 -0500)]
mediatek: add cudy wr3000h-v1 ubootmod
This allows us to use the full size of nand,
which extends ubi size from 64Mb to 122.25Mb.
1. Log in to the device and backup all the partitions,
especially unique "Factory" and "bdata" partitions
from System -> Backup / Flash Firmware -> Save mtdblock contents.
2. Install kmod-mtd-rw to unlock mtd partitions for writing
apk update && apk add kmod-mtd-rw && insmod mtd-rw i_want_a_brick=1
3. Write new OpenWrt (U-Boot Layout) "BL2" and "FIP":
mtd -e BL2 write openwrt-mediatek-filogic-cudy_wr3000h-v1-ubootmod-preloader.bin BL2
mtd -e FIP write openwrt-mediatek-filogic-cudy_wr3000h-v1-ubootmod-bl31-uboot.fip FIP
4. Set static IP on your PC: "192.168.1.254", gateway "192.168.1.1"
5. Serve openwrt-mediatek-filogic-cudy_wr3000h-v1-ubootmod-initramfs-recovery.itb
using TFTP server.
6. Connect Router LAN with PC LAN.
7. Cut off the power and re-engage, wait for TFTP recovery to complete.
8. After OpenWrt initramfs recovery has booted,
clean "/dev/mtd5" ubi partition to utilize maximum of free space:
ubidetach -p /dev/mtd5; ubiformat /dev/mtd5 -y; ubiattach -p /dev/mtd5
ubimkvol /dev/ubi0 -n 0 -N ubootenv -s 128KiB
ubimkvol /dev/ubi0 -n 1 -N ubootenv2 -s 128KiB
9. Perform sysupgrade.
Dmitry Mostovoy [Mon, 9 Feb 2026 09:52:38 +0000 (04:52 -0500)]
mediatek: add cudy wr3000e-v1 ubootmod
This allows us to use the full size of nand,
which extends ubi size from 64Mb to 122.25Mb.
1. Log in to the device and backup all the partitions,
especially unique "Factory" and "bdata" partitions
from System -> Backup / Flash Firmware -> Save mtdblock contents.
2. Install kmod-mtd-rw to unlock mtd partitions for writing
apk update && apk add kmod-mtd-rw && insmod mtd-rw i_want_a_brick=1
3. Write new OpenWrt (U-Boot Layout) "BL2" and "FIP":
mtd -e BL2 write openwrt-mediatek-filogic-cudy_wr3000e-v1-ubootmod-preloader.bin BL2
mtd -e FIP write openwrt-mediatek-filogic-cudy_wr3000e-v1-ubootmod-bl31-uboot.fip FIP
4. Set static IP on your PC: "192.168.1.254", gateway "192.168.1.1"
5. Serve openwrt-mediatek-filogic-cudy_wr3000e-v1-ubootmod-initramfs-recovery.itb
using TFTP server.
6. Connect Router LAN with PC LAN.
7. Cut off the power and re-engage, wait for TFTP recovery to complete.
8. After OpenWrt initramfs recovery has booted,
clean "/dev/mtd5" ubi partition to utilize maximum of free space:
ubidetach -p /dev/mtd5; ubiformat /dev/mtd5 -y; ubiattach -p /dev/mtd5
ubimkvol /dev/ubi0 -n 0 -N ubootenv -s 128KiB
ubimkvol /dev/ubi0 -n 1 -N ubootenv2 -s 128KiB
9. Perform sysupgrade.
Dmitry Mostovoy [Mon, 9 Feb 2026 09:52:03 +0000 (04:52 -0500)]
mediatek: add cudy wr3000s-v1 ubootmod
This allows us to use the full size of nand,
which extends ubi size from 64Mb to 122.25Mb.
1. Log in to the device and backup all the partitions,
especially unique "Factory" and "bdata" partitions
from System -> Backup / Flash Firmware -> Save mtdblock contents.
2. Install kmod-mtd-rw to unlock mtd partitions for writing
apk update && apk add kmod-mtd-rw && insmod mtd-rw i_want_a_brick=1
3. Write new OpenWrt (U-Boot Layout) "BL2" and "FIP":
mtd -e BL2 write openwrt-mediatek-filogic-cudy_wr3000s-v1-ubootmod-preloader.bin BL2
mtd -e FIP write openwrt-mediatek-filogic-cudy_wr3000s-v1-ubootmod-bl31-uboot.fip FIP
4. Set static IP on your PC: "192.168.1.254", gateway "192.168.1.1"
5. Serve openwrt-mediatek-filogic-cudy_wr3000s-v1-ubootmod-initramfs-recovery.itb
using TFTP server.
6. Connect Router LAN with PC LAN.
7. Cut off the power and re-engage, wait for TFTP recovery to complete.
8. After OpenWrt initramfs recovery has booted,
clean "/dev/mtd5" ubi partition to utilize maximum of free space:
ubidetach -p /dev/mtd5; ubiformat /dev/mtd5 -y; ubiattach -p /dev/mtd5
ubimkvol /dev/ubi0 -n 0 -N ubootenv -s 128KiB
ubimkvol /dev/ubi0 -n 1 -N ubootenv2 -s 128KiB
9. Perform sysupgrade.
Dmitry Mostovoy [Mon, 9 Feb 2026 09:51:31 +0000 (04:51 -0500)]
mediatek: add cudy wr3000p-v1 ubootmod
This allows us to use the full size of nand,
which extends ubi size from 64Mb to 122.25Mb.
1. Log in to the device and backup all the partitions,
especially unique "Factory" and "bdata" partitions
from System -> Backup / Flash Firmware -> Save mtdblock contents.
2. Install kmod-mtd-rw to unlock mtd partitions for writing
apk update && apk add kmod-mtd-rw && insmod mtd-rw i_want_a_brick=1
3. Write new OpenWrt (U-Boot Layout) "BL2" and "FIP":
mtd -e BL2 write openwrt-mediatek-filogic-cudy_wr3000p-v1-ubootmod-preloader.bin BL2
mtd -e FIP write openwrt-mediatek-filogic-cudy_wr3000p-v1-ubootmod-bl31-uboot.fip FIP
4. Set static IP on your PC: "192.168.1.254", gateway "192.168.1.1"
5. Serve openwrt-mediatek-filogic-cudy_wr3000p-v1-ubootmod-initramfs-recovery.itb
using TFTP server.
6. Connect Router LAN with PC LAN.
7. Cut off the power and re-engage, wait for TFTP recovery to complete.
8. After OpenWrt initramfs recovery has booted,
clean "/dev/mtd5" ubi partition to utilize maximum of free space:
ubidetach -p /dev/mtd5; ubiformat /dev/mtd5 -y; ubiattach -p /dev/mtd5
ubimkvol /dev/ubi0 -n 0 -N ubootenv -s 128KiB
ubimkvol /dev/ubi0 -n 1 -N ubootenv2 -s 128KiB
9. Perform sysupgrade.
Since there are some similar devices from Cudy (only WR3000P now)
this will allow to create OpenWrt U-Boot layout for all of them
using same DDR4 target.
realtek: eth: remove false security in rteth_remove()
Check for dev in driver remove gives no additional security. The
remove() function is only called if probe() succeeded. Probing
will always call platform_set_drvdata() in the good case. So
remove() will always find dev data via platform_get_drvdata().
The ethernet driver is only loaded via devicetree and makes use
of of_match_table. In this case the probing function is only
called if a matching compatible is set. So pdev->dev.of_node
can never be NULL.
Align the driver and matchtable naming convention to the new
rteth prefix. While we are here autogenerate the module name
by using KBUILD_MODNAME. This is common upstream practice.
Jonas Jelonek [Thu, 26 Mar 2026 13:34:38 +0000 (13:34 +0000)]
realtek: dts: drop trailing semicolons after macro use
Commit d52f7a4ca5 ("realtek: dts: new SWITCH_PORT_LED() macro") introduced
a new macro to simplify switch port definitions and introduces usage of
it for Zyxel XGS1X10-12 devices. However, this change added a DTS syntax
issue because:
> SWITCH_PORT_LED(...);
produces
> port@XX { ... };;
because the macro already includes a trailing semicolon. The DT compiler
doesn't like this so it fails with syntax error. Fix this by dropping the
trailing semicolons after macro usages.
Fixes: d52f7a4ca5 ("realtek: dts: new SWITCH_PORT_LED() macro") Signed-off-by: Jonas Jelonek <jelonek.jonas@gmail.com> Link: https://github.com/openwrt/openwrt/pull/22614 Signed-off-by: Robert Marko <robimarko@gmail.com>
The RTL8261BE 10GbE PHY's `reset-deassert-us` was set to 100ms (100000us),
but the **RTL8261N datasheet (Table 108, parameter t7)** specifies a
minimum **SMI-ready time of 150ms** after nRESET release before the MDIO
(SMI) bus can be used.
Note: Essentially, the RTL8261N and RTL8261BE are architecturally identical
chips, so their initialization parameters should be consistent.
Jonas Jelonek [Wed, 25 Mar 2026 12:51:09 +0000 (13:51 +0100)]
realtek: pcs: rtl930x: improve error propagation
Previous changes refactored the hardware mode configuration for RTL930x
a lot. Now that this is in a better shape, one issue persists: missing
error propagation. Only parts of this function really propagate an
error, others are silently dropped. While this is a known driver-wide
issue, at least make it good here. Propagate the errors from functions
which apply configuration sequences to the caller.
Single writes are still left out on purpose, they need and will be
addressed later.
Decommission a helper for applying config/patch sequences for even/odd
SerDes. Most of these sequences were squashed due to marginal
difference, sharing a lot of common parts. For the marginal differences,
testing showed that the different values were already present on
even/odd. Since those are no reset/trigger bits but just configuration
values, writing them for both should do no harm.
Jonas Jelonek [Mon, 23 Mar 2026 20:44:10 +0000 (21:44 +0100)]
realtek: pcs: rtl930x: squash config sequences even more
Config/patch sequences have been reduced and merged by previous changes.
Now that we have a clearer view on them, we can see that there are still
several similarities between the even and odd variants. Some different
writes for even and odd SerDes remain but one can find out they don't
need to be separate. For example, a write to [0x29, 0x09] is missing for
odd SerDes but testing and a SerDes dump from a running configuration
show that the registers still hold the same value and changes do not
affect functionality. Thus, merge them too to get rid of a lot of
even/odd stuff.
Right now, the config sequences for XSGMII and USXGMII have been
stripped down to their essential parts. Still, they have redundancies.
The XSGMII sequences are 99% equal to the generic ANA_10G sequences
(except for a single write which is DFE/LEQ-related and changed during
calibration later anyway), thus we can drop them completely.
The USXGMII sequences contain the same sequences so they can be removed
there too, all being covered by applying the ANA_10G sequence for those
modes too. One different write (register [0x2e, 0x01]) is integrated into
the ANA_10G sequence since testing has shown that the value is either the
default for that register anyway, or set during SDK setup too for 10GR.
Jonas Jelonek [Wed, 18 Mar 2026 22:58:56 +0000 (23:58 +0100)]
realtek: pcs: rtl930x: move writes to config
Move a few register writes from the ANA_10G patch sequences to the
configuration function. Those write are targeted at digital pages and do
not fully apply for *SGMII modes. To make the ANA_10G sequence really
just deal with analog pages and make it usable for *SGMII modes too,
move out the digital page writes.
Jonas Jelonek [Tue, 17 Mar 2026 22:23:08 +0000 (22:23 +0000)]
realtek: pcs: rtl930x: break up fiber config sequences
The patch/config sequences we took over from the SDK are partially
redundant, i.e. they share common parts which can be separated per
speed. For example, the config for 10GR contains the one for 2500Base-X
but we have a dedicated one for 2500Base-X. This is a first step to
modularize and reverse-engineer those sequences, and decrease the size
they claim.
The sequences are nearly exclusive ordered by ascending pages. This
suggests that those register/writes do not have a hidden function of
performing inline resets but rather are just configuration values.
Likely, they may be applied in rather arbitrary order. Splitting up the
sequences here assumes this is true and does some minor order changes.
Testing shows no behavioral change. Looking at [1] there are no relevant
reset or trigger bits affected by that. Suspiciously ordered writes have
mostly been kept though.
USXGMII setup needs to be adjusted too due to shared sequence parts.
Jonas Jelonek [Wed, 18 Mar 2026 21:02:55 +0000 (22:02 +0100)]
realtek: pcs: rtl930x: move EEE to USXGMII configuration
The patch/config sequences for USXGMII modes contain a register write
which is explicitly labelled as "enable eee". To clean the sequences and
reduce duplication, move this specific write to the USXGMII
configuration function.
While at it, demystify this register write. From [1] we can see that
only a single bit needs to be set for controlling EEE instead of the
whole register. From testing it was seen that the register has a default
value of 0x445C after reset. Thus, there is no other operation hidden in
this write and we're safe to reduce it to setting just the EEE enable
bit.
USXGMII configuration is currently only performed via the patching
sequences although there's a dedicated function which configures several
parameters and assigns meaningful names to some register fields. It was
introduced in dca20f91ea12 ("realtek: add serdes patch for 10G_QXGMII")
but somewhat abandoned later due to a partial revert.
To improve the situation, prioritize usage of the function for USXGMII
variants and remove some parts from the patch sequences which seem to be
exclusive for USXGMII and thus can be covered by this function. Writes
to registers [0x6, 0xE], [0x6, 0x13] and [0x6, 0x14] can be dropped
completely because they are redundant. The bits really affected by
these writes (compared to the default register values aquired from a
dump) are overwritten below again. Testing on real hardware and USXGMII
supports this.
While at it, improve the style a bit and add comments explaining some of
the fields a bit more. Additionally, fix the call situation which
currently is dead code due to early exit. Provide two calls to the
mentioned functions but comment one of them to remain current
functionality. Names and meaning of fields is inferred from [1].
Jonas Jelonek [Wed, 18 Mar 2026 20:20:31 +0000 (21:20 +0100)]
realtek: pcs: rtl930x: carve out common writes
Start deconstructing the patch/config sequences by carving out two
specific writes which are common for non-USXGMII and are special because
they are not in analog SerDes pages.
Jonas Jelonek [Sat, 21 Mar 2026 23:52:09 +0000 (00:52 +0100)]
realtek: pcs: rtl930x: handle QSGMII config early
Handle QSGMII config earlier within the configuration function as a
preparation for subsequent patches in this area. Those will target
splitting up the config sequences and 5G-QSGMII is special there.
Jonas Jelonek [Tue, 17 Mar 2026 21:29:15 +0000 (21:29 +0000)]
realtek: pcs: rtl930x: rename patching function
Rename the function that currently "applies patches" so that it covers
everything it does (and will do). It doesn't only apply patches but in
general performs configuration of a SerDes for a particular hardware
mode.
While at it, remove a print above that call because it is both placed
wrong and redundant due to what the generic pcs_config prints.
Change how patches are applied to reduce redundancy and make the code
more readable. Define a generic function that applies any patch. Within
the RTL930x patch application, define a local macro that helps to get
rid of repeated even/odd checks. While making the code cleaner, it is
also a preparation for further refactoring here.
This adds a local helper macro intended to be only temporary but keeps
the style of the code clean by avoiding a lot of if-else clauses.
Anthony Sepa [Wed, 25 Mar 2026 20:13:43 +0000 (21:13 +0100)]
ipq40xx: fix art partition name WHW03 V1
In the blamed commit, the wrong partition name for ART was used.
It was later discovered that the partition table uses "0:ART" instead of
"art" for the ART partition name thus breaking caldata extraction.
So, fix the partition name.
Fixes: ee5999cf78d8 ("treewide: linksys: use nvmem MAC for hw_mac_addr") Signed-off-by: Anthony Sepa <protectivedad@gmail.com> Signed-off-by: Robert Marko <robimarko@gmail.com>
Allow to configure the LM75 alert pin to active-high instead
of its default active-low. This patch is needed for the D-Link
DGS-1250 series where the alert pin steers the fan speed
between low and high.
Sven Eckelmann [Wed, 11 Mar 2026 17:49:44 +0000 (18:49 +0100)]
realtek: dsa: rtl93xx: avoid LAG transmission on down link
When the link goes down on the other end of a bond, it was noticed that the
switch was still trying to send data over this link.
Problem here is that net_lag_port_dev_txable() uses
bond_is_active_slave_dev() to look the state up. But this is actually
showing if a link is a NOT a backup - not if the link should be really be
TX enabled or not.
As a DSA driver, it is important to consume the DSA information.
dp->lag_tx_enabled must therefore be used for DSA .port_lag_change events.
This variable contains two information from the
struct netdev_lag_lower_state_info:
Damien Dejean [Tue, 24 Mar 2026 20:43:06 +0000 (21:43 +0100)]
realtek: phy: backport pair/polarity order support
Backport four patches merged in netdev-next/main to add pair order [1,2]
and pair polarity [3,4] configuration support for the RTL8224. The
configuration is required when the bootloader doesn't set it up.
projects / thirdparty / openwrt.git / log
