A lot of definitions in the global mach include have been taken over
to the individual drivers. Only a few of the definitions are really
used nowadays. Remove all the unneeded lines.
Elbert Mai [Sat, 12 Jul 2025 12:58:59 +0000 (05:58 -0700)]
bcm2712: add kmod-r8169 and kmod-usb-net-rtl8152
Boards such as [1] and [2] add an extra Ethernet port to Raspberry Pi (CM)5.
These typically use Realtek PCIe or USB Ethernet NICs. Include kmod-r8169 and
kmod-usb-net-rtl8152 by default to make it easy to configure LAN/WAN ports
with these parts on Raspberry Pi 5.
Because CM5 can fit in the same carrier boards as CM4, also ensure that both
devices have the same Ethernet NIC kmods.
Zoltan HERPAI [Mon, 11 Aug 2025 16:58:20 +0000 (18:58 +0200)]
sunxi: enable at24 support
Certain boards have an at24(-compatible) EEPROM for storing various
parameters like MAC addresses. Enable support for this hardware across
the whole target.
Zoltan HERPAI [Mon, 11 Aug 2025 16:59:04 +0000 (18:59 +0200)]
uboot-sunxi: randomize ethaddr on Olimex A20 boards
While these boards have an at24 EEPROM for storing the MAC address,
early revisions (up until about 2017) did not contain actual addresses.
Create a random address to have ethernet function properly in u-boot.
airoha: backport upstream fixes for pinctrl PHY LED and MDIO
Backport fixes for Airoha pinctrl driver for PHY LED and MDIO bus. This
fix a copy-paste error for PHY LED and a misconfiguration for MT7530
embedded Switch MDIO bus GPIO pin to permit usage of external PHYs.
Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
Jan Kardell [Mon, 8 Sep 2025 06:52:40 +0000 (08:52 +0200)]
libxml2: Add abi version
The version of libxml2 was bumped from 2.13.6 to 2.14.5. Since version
2.14, libxml2 is not binary compatible with older versions. Therefore
add an abi version.
From the NEWS file:
Binary compatibility is restricted to versions 2.14 or newer. On ELF
systems, the soname was bumped from libxml2.so.2 to libxml2.so.16.
gettext-full only provides libintl which is not licensed under
GPL-3.0.-or-later but under LGPL-2.1-or-later as stated in
gettext-runtime/intl/COPYING.LIB
Fixes: c10d97484a43375a0446dafc8cb4072e26502f37 (Add more license tags with SPDX identifiers) Signed-off-by: Fabrice Fontaine <fontaine.fabrice@gmail.com> Link: https://github.com/openwrt/openwrt/pull/19943 Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
elfutils libraries are not licensed under GPL-3.0-or-later, they are dual
licensed: GPL-2.0-or-later OR LGPL-3.0-or-later as clearly stated in
source files as well as on https://sourceware.org/elfutils:
The libraries and backends are dual GPLv2+/LGPLv3+. The utilities are GPLv3+.
Installation:
* Upload factory image through the tftp recovery mode.
Notes:
* This device has a dual-boot partition scheme, if installing with the
stock web interface method will flash only on the inactive ubi partitions
which are kernel and rootfs, newly flashed kernel didn't know the proper
rootfs partition so the booted kernel will panic.
Tested-by: Rhnn Hur <hurrhnn@icmp.kr> Signed-off-by: Rhnn Hur <hurrhnn@icmp.kr> Link: https://github.com/openwrt/openwrt/pull/16643 Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
All devices supported by the Zynq target have either a Realtek or Marvell
PHY. The Vitesse PHY was enabled when the target was created (2d45ad07fc64).
It's not used here, so it's safe to disable it.
Ethernet PHYs used by individual devices are listed below.
Mikhail Zhilkin [Thu, 14 Aug 2025 16:15:09 +0000 (19:15 +0300)]
uboot-mediatek: add support for FudanMicro FM25S01A
This patch adds support for FudanMicro FM25S01A SPI NAND. It's required
for some CMCC RAX3000Me hardware revisions.
The patch was partially taken from ImmortalWrt.
Link:
https://raw.githubusercontent.com/immortalwrt/immortalwrt/refs/heads/master/package/boot/uboot-mediatek/patches/342-mtd-spinand-Support-fmsh.patch
Michal Halva [Sat, 2 Aug 2025 18:46:14 +0000 (20:46 +0200)]
mediatek: filogic: add support for Cudy WR3000P v1
Hardware
--------
MediaTek MT7981 WiSoC
512MB DDR4 RAM
128MB SPI-NAND
MediaTek MT7981 2x2 DBDC 802.11ax 2T2R (2.4 / 5)
4 LAN MediaTek MT7531 PHY
1 WAN RTL8221B-VB-CG 2.5Gbps PHY
UART: 115200 8N1 3.3V
USB2 Port
PoE on WAN Port
MAC:
LAN MAC: label mac
WAN MAC: label mac + 1
2.4G MAC: label mac
5G MAC: label mac + 1 with LA bit set
Gotchas:
WAN LED does not light up (might require further DTS tweaks)
PoE on WAN port was not tested
This commit is heavily based on WR3000H one, I've just ported DTS differences
from the official image to get USB support and proper LED mapping.
Installation
------------
[Untested as I've received and used a transitional image from Cudy]
1. Connect to the serial port as described in the "Hardware" section.
2. Power on the device + press reset pin. Keep pressing reset pin to enter the U-Boot shell.
3. Download the OpenWrt initramfs image. Place it on an TFTP server
connected to the Cudy LAN ports. Make sure the server is reachable at
192.168.1.88. Rename the image to "cudy3000p.bin"
So much code was distributed between phy/ethernet/dsa drivers. A lot
was already cleand up before. With this step the mdio bus gets its
own space and is no longer hidden inside the ethernet driver.
This commit is mostly a copy/paste that includes only minor changes.
- define prefixes are renamed to RTMDIO
- The driver is totally self contained (does not rely on SoC include)
- The DTS structure (mdio node below ethernet node) was kept
- The driver is added to the kernel config of all subtargets.
The ethernet and mdio code will be splitted. The dsa driver depends
on proper loading of both, before switch setup can start. Sadly there
are severe cleanup issues in the probe() function if one of the
required devices is not available.
As a temporary workaround provide a dedicated check function that
verifies if the ethernet platform device driver is loaded and can
be used.
At the end of RX NAPI polling the counter and mask registers are
cleaned up. Although this might run in parallel there is no
synchronization and the register modifications are some wild mix.
RTL83xx enables only the interrupt of a single ring while RTL93xx
just reactivates all interrupts (even for other NAPI threads).
Make use of the driver lock and only modify the interrupt bits that
the current thread owns.
Now that the counter registers work fine there is no need to
free buffers in software. Hardware will automatically block
input processing when software processing is too slow.
realtek: RTL93xx: Make use of correct ring size counters
The receive path of the RTL93xx SoCs is currently discarding packets
in software. Analysis gives the following explanation:
- RX ring size registers are setup with the full software ring size
- When packets are received the packet counter registers are increased
- After RX processing the counter registers are changed the wrong way
- From then SOC is allowed to receive more packets than software allows
- Overflow interrupts are fired
- As a reaction to that the software drops packets
Change the processing as follows:
- Setup ring size registers with a headroom of 2 buffers
- Decrease the counter registers with the real work done
With this change no more overflow interrupts occur because the SoC
disables the queues before they can overflow or hit a buffer that is
still owned by the CPU.
Benchmark from single stream iperf3 run, with server process running
on ZyXEL XGS1210 (RTL930x).
realtek: drop RTL8226/RTL8221B downstream PHY driver
Since we are using upstream PHY drivers there is no more need
for the downstream version. Side effect is that the SoC dependent
polling functions are no longer needed. This was always wrong
in this driver.
kernel: update and move net bridge patch to backport folder
Update patch 642-net-bridge-locally-receive-all-multicast-packets-if-.patch to upstream version
and move to backport folder as 625-v6.16-net-bridge-locally-receive-all-multicast-packets-if-.patch
because kernel 6.16 already includes it.
A new version of the ZyXEL XGS1210-12 has been discovered in
the wild. It includes at least two known hardware changes
- lan9/lan10 use RTL8221B instead of RTL8226
- lan9/lan10 use different SMI busses
Pave the new device the way by splitting the existing DTS.
According to the vendor website the models are named
- A1 (first version): not explicetly labeled
- B1 (second version): Label Rev. B1 on device
Rename the current OpenWrt device definition to A1 as it was
made for the first version. To stay compatible with older
installations, add the old device name to the list of
supported devices.
realtek: rt-loader: add ROM uImage lookup (aka standalone)
The rt-loader currently only supports booting piggy backed lzma
compressed kernels. This requires a data layout where the kernel
directly follows the loader. That might not be sufficient for
more complex flash layouts.
Especially bootbase devices (like ZyXEL GS1920) will need some
kind of chain loading that needs to be explored yet.
Enhance the rt-loader as follows:
- Allow to build as standalone version
- In this case a flash start address is given
- During boot loader will search the ROM starting from that address
- If it finds a uImage this will be loaded into RAM
- Afterwards it will be decompressed to its load address
- While we are here add uncompressed uImage support
As always the implementation tries to be as simple as possible.
- uImage detection works without magics
- uImage will be loaded to highest possible memory address
- Documentation in Makefile has been adapted accordingly
Funny side fact: A standalone rt-loader can chain load a piggy
backed rt-loader from flash.
During bootup loader will show
rt-loader
Running on RTL8380M (chip id 6275C) with 256MB
Relocate 15760 bytes from 0x82000000 to 0x8ffa0000
Searching for uImage starting at 0xb45a0000 ...
uImage 'MIPS OpenWrt Linux-6.12.40' found at 0xb45a0000 with load address 0x80100000
Copy 2923034 bytes of image data to 0x8fcd61e6 ...
Extract image with 2923034 bytes from 0x8fcd61e6 to 0x80100000 ...
Final kernel size is 2923034 bytes
Booting kernel from 0x80100000 ...
Registers must not be accessed in parallel by multiple drivers.
Read-modify-write operations are not atomic, and the result of parallel
access is undefined.
The MAC_L2_GLOBAL_CTRL2 register is essentially a pin configuration
register and is represented by a pinmux node in the devicetree. Operations
on this register by the realtek,rtl838x-eth driver must therefore also be
reflected in the devicetree.
Since the MDIO sets used are board-specific, the pins must be enabled in
the board’s devicetree. This can be achieved using the pinctrl properties
for the realtek,rtl83xx-switch.
Sven Eckelmann [Wed, 20 Aug 2025 03:19:31 +0000 (05:19 +0200)]
realtek: rtl931x: Add LED Sync configuration
The pinmux-related registers on the RTL931X SoC family are spread across
various non-consecutive registers. It might be tempting to modify them
directly in a specific driver (SPI, LED, etc.), but this would cause issues
with parallel, non-locked read-modify-write operations, which are required
to update individual portions of these registers.
Instead, it is better to use the devicetree pinctrl properties to define
the correct configurations for the various operation modes.
One important setting here is the LED Sync bit. This allows the LED
controller to generate an additional positive edge on the `STCP`
("STore Clock Pin", also known as `RCLK`) of the LED shift register after
the actual content has already been shifted in using the normal shift
clock. The LED shift register is then expected to copy the content from the
shift register section into the storage registers, which act as the actual
LED output control. This functionality is available in, and commonly used
with, the SNx4HC595 family of shift registers.
To activate it, simply register it in the default state of the
"realtek,rtl83xx-switch" node:
It would be nicer when this can be directly added to the led subnode. But
for this to work, `realtek,rtl9300-leds` must first be an actual driver
(known to the driver core).
Suggested-by: Bevan Weiss <bevan.weiss@gmail.com> Signed-off-by: Sven Eckelmann <sven@narfation.org> Link: https://github.com/openwrt/openwrt/pull/19815 Signed-off-by: Robert Marko <robimarko@gmail.com>
The MAC_L2_GLOBAL_CTRL2 register is primarily used for pin configuration.
It is necessary to select specific modes for pins or to free them for use
as GPIOs.
Fixes: 9dbc04785c4e ("realtek: add rtl8231-aux to rtl931x.dtsi") Signed-off-by: Sven Eckelmann <sven@narfation.org> Link: https://github.com/openwrt/openwrt/pull/19815 Signed-off-by: Robert Marko <robimarko@gmail.com>
The pinmux-related registers on the RTL930X SoC family are spread across
various non-consecutive registers. It might be tempting to modify them
directly in a specific driver (SPI, LED, etc.), but this would cause issues
with parallel, non-locked read-modify-write operations, which are required
to update individual portions of these registers.
Instead, it is better to use the devicetree pinctrl properties to define
the correct configurations for the various operation modes.
One important setting here is the LED Sync bit. This allows the LED
controller to generate an additional positive edge on the `STCP`
("STore Clock Pin", also known as `RCLK`) of the LED shift register after
the actual content has already been shifted in using the normal shift
clock. The LED shift register is then expected to copy the content from the
shift register section into the storage registers, which act as the actual
LED output control. This functionality is available in, and commonly used
with, the SNx4HC595 family of shift registers.
To activate it, simply register it in the default state of the
"realtek,rtl83xx-switch" node:
It would be nicer when this can be directly added to the led subnode. But
for this to work, `realtek,rtl9300-leds` must first be an actual driver
(known to the driver core).
Suggested-by: Bevan Weiss <bevan.weiss@gmail.com> Signed-off-by: Sven Eckelmann <sven@narfation.org> Link: https://github.com/openwrt/openwrt/pull/19815 Signed-off-by: Robert Marko <robimarko@gmail.com>
firmware: Add support for Airoha EN7581 NPU firmware
Add support for Airoha EN7581 NPU firmware present in linux-firmware.
Support for it is fully upstream with the Ethernet part fully pushed and
the Wireless Offload currently in progress for various WiFi chip.
generic: backport support for Aeonsemi AS21xxx PHY
Backport support for Aeonsemi AS121xxx PHY. The PHY require dedicated
firmware to be loaded to correctly work and support a big family of
Aeonsemi PHY that provide from 1G to 10G speed.
Automatically refresh all affected patch and file (rtl PHY).
airoha: replace thermal patch with upstream version
Replace thermal patch with upstream version. The thermal maintainer
reported that the sysfs entry are considered deprecated and that slope
and offset should be handled internally to the driver.
Jonas Jelonek [Tue, 2 Sep 2025 07:38:51 +0000 (09:38 +0200)]
realtek: fix model for TP-Link TL-ST1008F v2.0
Fix the model name in DTS compatible, Makefiles and board scripts by
using dash instead of comma or underscore. This aligns it with other
examples in OpenWrt and makes in consistent in all places where the
board model is used.
wifi-scripts: ucode: set default wildcard mac for wifi-station
When creating the PSK file, the old script sets `mac` to
`00:00:00:00:00:00` when `mac` is not specified (see [here][1]),
creating hostapd configuration lines like:
vlanid=10 00:00:00:00:00:00 MyStrongPassword
That matches any MAC address (a wildcard). The `ucode` script alternative
misses the default, so set it.
In the later example the frontend/backend mapping code is already
in our new functions. So swap the calculation logic and use the
new access functions. This allows to finally drop the old access
functions without mapping.
From now on all RTL931x SerDes functions will use a consistent
frontend view.
realtek: convert access to RTL931x "digital 2" serdes pages
The RTL931x has 14 frontend and at least 26 backend serdes. Currently
the programming functions always need to determine the right backend
serdes from the given frontend serdes on their own. We plan to provide
a consistent serdes mapping to all callers.
As the third step make use of these new functions whenever we want to
access the "digital 2" pages. The pages are mapped starting at 0x200.
So the function conversion is as simple as this:
The more we step down into the SerDes deeps the more confusing it
gets. Nevertheless it is not to late to fix a wrong assumption.
Until now it seemed as if the frontend/backend SerDes mapping is
totally without intersection. This is not true.
The backend SerDes mapping is also dependent on the mode. Especially
the proprietary Realtek XSGMII mode stands out from all other
mappings. So fix the descriptions and the calculation of the third
page package (digital 2 aka XSGMII 2).
As it was not yet used it had no impact.
Fixes: a4cbb44c1b ("realtek: convert access to RTL931x analog serdes pages") Signed-off-by: Markus Stockhausen <markus.stockhausen@gmx.de> Link: https://github.com/openwrt/openwrt/pull/19873 Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
realtek: convert access to RTL931x "digital 1" serdes pages
The RTL931x has 14 frontend and at least 26 backend serdes. Currently
the programming functions always need to determine the right backend
serdes from the given frontend serdes on their own. We plan to provide
a consistent serdes mapping to all callers.
As the second step make use of these new functions whenever we
want to access the digital 1 pages. The pages are mapped starting
at 0x100. So the function conversion is as simple as this:
For some reason 3 of the 4 mdio access functions contain an
artifical delay of 10ms. While it might have been part of
older Realtek SDKs it can no longer be found in current ones.
Remove the delays.
While we are here remove the pre-access bus ready checks.
It is sufficient to run them after the command start. If
anything fails the caller will get an error. This is the
same behaviour as for the other targets.
Finally cleanup the error handling. Something like this makes
no sense at all.
update patch to upstream function change
bcm53x/patches-6.6/180-usb-xhci-add-support-for-performing-fake-doorbell.patch
changed function xhci_disable_and_free_slot() upstream [3]
projects / thirdparty / openwrt.git / log
