Since the jumbo frame preparation the driver can work on fragments
and not only on complete packets in the receive path. This might be
implementet in the transmit patch in the future too. So a chunk of
data is best described as a fragment. Rename all occurrences.
Link: https://github.com/openwrt/openwrt/pull/24346
Signed-off-by: Markus Stockhausen <markus.stockhausen@gmx.de>
Wire the HS104 controller (0x0d) on the PSE i2c-gpio bus and attach the
four PoE PHYs (lan1-4) via PHY_C45_PSE; lan5 is not PoE. Add the STC8 LED
MCU (0x4d) with per-port PoE LED triggers, and pull the HS104 PSE and STC8
kmods into the image.
Signed-off-by: Carlo Szelinsky <github@szelinsky.de>
Link: https://github.com/openwrt/openwrt/pull/22245
Signed-off-by: Jonas Jelonek <jelonek.jonas@gmail.com>
Wire the two HS104 controllers (0x0d/0x15) on the i2c_sys bus and attach
the 8 PoE PHYs via PHY_C45_PSE. Add the STC8 LED MCU (0x4d) with per-port
PoE LED triggers, enable LEDS_SYSCON, and pull the PSE and STC8 kmods into
the image.
Signed-off-by: Carlo Szelinsky <github@szelinsky.de>
Link: https://github.com/openwrt/openwrt/pull/22245
Signed-off-by: Jonas Jelonek <jelonek.jonas@gmail.com>
Wire the two HS104 controllers on the i2c-gpio bus and attach the 8 PoE
PHYs via a new PHY_C45_PSE macro. Add the STC8 syscon with its per-port
PoE LED triggers, enable LEDS_SYSCON, and pull the PSE and STC8 kmods
into the image.
Signed-off-by: Carlo Szelinsky <github@szelinsky.de>
Link: https://github.com/openwrt/openwrt/pull/22245
Signed-off-by: Jonas Jelonek <jelonek.jonas@gmail.com>
Direct-I2C driver for the HS104 PSE chip (unlike the MCU-fronted
realtek-pse-mcu family). Packaged as kmod-pse-hasivo-hs104.
This driver will be submitted upstream once the pending PSE-core
patches it builds on (above) have landed.
Signed-off-by: Carlo Szelinsky <github@szelinsky.de>
Link: https://github.com/openwrt/openwrt/pull/22245
Signed-off-by: Jonas Jelonek <jelonek.jonas@gmail.com>
Add kmod packages to support accessing the fTPM (in-firmware TPM) which
can be implemented in the boot firmware of most modern platforms.
- kmod-optee: Open Portable Trusted Execution Environment
- kmod-optee-rng: OP-TEE random number generator client
- kmod-rtc-optee: OP-TEE real-time clock client
- kmod-scmi-transport-optee: SCMI OP-TEE transport
- kmod-tee: Generic Trusted Execution Environment
- kmod-tee-stmm-efi: EFI variable service Trusted Application
- kmod-tpm-ftpm-tee: Microsoft fTPM Trusted Application
Using the TPM 2.0 can be useful for various security applications,
such as encrypting on-disk credentials. OP-TEE itself alone is also
useful as it can provide a PKCS#11 token for authentication (eg. to
connect to a VPN) and significantly lower the risk of leaking secrets
used for authentication. Also, on some platforms RNG and RTC can only be
accessed via OP-TEE, and some ARM SystemReady platforms require EFI
variables to be access via a TA.
Signed-off-by: Daniel Golle <daniel@makrotopia.org>
The driver ring handling consists of two parts:
- rx_data: DMA coherent data shared with the SoC
- rx_qs: driver internal handling data
It is unclear what "qs" stands for. Rename that part to "rx_info".
While we are here:
- relocate slot from rx_data to rx_info as it is only needed by
the driver and not the SoC.
- rename page_pool to pool because there is only this single pool
inside the driver.
Link: https://github.com/openwrt/openwrt/pull/24245
Signed-off-by: Markus Stockhausen <markus.stockhausen@gmx.de>
The Realtek SoC hardware can split incoming packets over multiple buffers.
This allows to receive packets that are larger than the current 2K page
pool limit without changing the design to higher order pages. Add a logic
to handle these fragments.
As a first proof of concept simulate fragmentation by reducing the buffer
size down to 400 bytes. With the current support for standard MTU (1500)
the packets might consist of up to 4 fragments.
Link: https://github.com/openwrt/openwrt/pull/24245
Signed-off-by: Markus Stockhausen <markus.stockhausen@gmx.de>
Reorder the code around napi_gro_receive() so that it fits nicely
for the upcoming fragment handling. For this relocate the FCS
stripping and eth_type_trans() calls short before the handover
when the packet is fully built.
Link: https://github.com/openwrt/openwrt/pull/24245
Signed-off-by: Markus Stockhausen <markus.stockhausen@gmx.de>
Until now the driver packs each received packet into one ring buffer.
In the future jumbo packets will be split into multiple fragments.
Prepare the ring counters for this:
- Add the more flag to SoC packet header. This denotes if a packet
has more data after the current fragment.
- Ring counters must be handled per packet and not per fragment.
Increase work_done after each packet and not after each fragment.
Link: https://github.com/openwrt/openwrt/pull/24245
Signed-off-by: Markus Stockhausen <markus.stockhausen@gmx.de>
Testing shows that the existing performance boost by aligning the data
to 2 bytes (NET_IP_ALIGN) breaks fragment handling on RTL838x devices. The
SoC silently drops 2 bytes between each fragment. Use this tricky alignment
only when it is supported. This will bring down performance on RTL838x SoCs
by 30%. All other SoCs are unaffected. This is a legitimate tradeoff for
allowing multiple fragments. While we are here make clearer what the
definies are about and rename them to a SKB_ prefix.
Link: https://github.com/openwrt/openwrt/pull/24245
Signed-off-by: Markus Stockhausen <markus.stockhausen@gmx.de>
Add a helper to simplify SKB freeing and rx counter handling. If SKB
is given, it is freed and the pointer is set to zero. The return value
is the number of freed SKBs (0/1). With this the existing cleanup and
error handling can be simplified like
dev->stats.tx_errors += rteth_free_skb(&packet->skb);
Link: https://github.com/openwrt/openwrt/pull/24245
Signed-off-by: Markus Stockhausen <markus.stockhausen@gmx.de>
Free the per-port segment strings on unregister to avoid leaking them
across device rebind. Drop the dead (phys < 0) check and guard the
kstrdup allocation against failure.
Move swconfig_create_led_trigger() before list_add_tail() in
register_switch so a failing registration never publishes the device on
the global swdevs list with dangling portmap/portbuf pointers (a
use-after-free for any swdevs iterator). Route both the LED trigger
failure and the -ENFILE (swdev id exhaustion) failure paths through a
shared cleanup that frees portbuf, portmap, and the per-port segment
strings instead of leaking them.
Reorder the frees in unregister_switch to run after list_del so the
buffers are not freed while the device is still reachable from swdevs.
Signed-off-by: Rosen Penev <rosenp@gmail.com>
Link: https://github.com/openwrt/openwrt/pull/24246
Signed-off-by: Jonas Jelonek <jelonek.jonas@gmail.com>
Upstream has marked it as BROKEN. Quote:
This driver is harmful:
- It is much slower than the CPU.
- It Has a history of bugs.
- It does not have exclusive access to the hardware, causing races
with the secure world.
- It register its implementations with too low a cra_priority for them
to be actually used.
Signed-off-by: Rosen Penev <rosenp@gmail.com>
Link: https://github.com/openwrt/openwrt/pull/24326
Signed-off-by: Jonas Jelonek <jelonek.jonas@gmail.com>
The nvmem cell for the MT7663 (5 GHz) radio was too small. The MT7663 EEPROM at
offset 0x8000 requires the full MT7615_EEPROM_FULL_SIZE (0x4da8), but the cell
only declared 0x200 bytes.
The driver always requests the full buffer, also for the MT7663, so the undersized
cell makes the nvmem read fail with -EINVAL. The driver then falls back to default
values, which limits TX power to 3 dBm.
Fix this by enlarging the cell to 0x4da8. The offset 0x8000 was already correct —
offset 0x0 holds the MT7628 (2.4 GHz) calibration data.
Fixes: #23632
Signed-off-by: Frank Lang <Frank_Lang@outlook.de>
Link: https://github.com/openwrt/openwrt/pull/24284
Signed-off-by: Jonas Jelonek <jelonek.jonas@gmail.com>
The eth0 assignment never takes effect. 05_set_preinit_iface brings eth0
up in its default case before 10_fix_eth_mac.sh runs, and the kernel
refuses a MAC change on a running interface, so ip link fails with EBUSY.
This script cannot run any earlier either, since it needs /tmp/tp_data
mounted by 09_mount_cfg_part.
Nothing is lost by dropping it: the DSA user ports carry their own
addresses, which the lan1-3 assignments below already take care of, and
br-lan takes its address from them.
Verified on a BE450 running an image built from main: eth0 comes up with
a different random address on every boot regardless of this line, while
lan1-3 and br-lan keep the label MAC across reboots even with no macaddr
in /etc/config/network.
Fixes: 1513da34bb ("mediatek: filogic: set eth0 and LAN port MACs on TP-Link BE450")
Signed-off-by: Semih Baskan <strst.gs@gmail.com>
Link: https://github.com/openwrt/openwrt/pull/24325
Signed-off-by: Jonas Jelonek <jelonek.jonas@gmail.com>
The label-mac-device alias cannot work on this device: it is resolved
by reading the mac-address property of the aliased DT node, but gmac0
never has one. The MAC is stored in a file inside the tp_data UBIFS
volume, so there is no fixed flash offset an nvmem-layout could point
at, and the vendor bootloader does not fix up the FDT either. Drop the
dead alias.
Record the label MAC in board.d instead and assign it to the lan
interface, as is already done for the other devices reading
/tmp/tp_data/default-mac (Mercusys MR90X v1, Archer AX80 v1,
RE6000XD). The explicit lan MAC also makes the br-lan address
independent of the order of the bridge ports.
Suggested-by: Felix Baumann <felix.bau@gmx.de>
Signed-off-by: Semih Baskan <strst.gs@gmail.com>
Link: https://github.com/openwrt/openwrt/pull/24180
Signed-off-by: Jonas Jelonek <jelonek.jonas@gmail.com>
eth0 (gmac0) is declared label-mac-device, but nothing assigns its MAC,
so it and the DSA lan ports come up with a random locally administered
address that changes every boot. Assign the base MAC from tp_data
default-mac to eth0 and the lan ports, as is already done for eth1 and
eth2.
Each lan port needs its own assignment: a DSA user port copies the
conduit's MAC once when it is created, at driver probe before preinit
runs, and ignores later changes to eth0.
Run-tested on a BE450 on 25.12.5, where the case is identical.
Two boots without the fix each came up with a different
random address; with the fix applied, eth0 and the lan ports get the
label MAC and keep it across reboots.
Signed-off-by: Semih Baskan <strst.gs@gmail.com>
Link: https://github.com/openwrt/openwrt/pull/24180
Signed-off-by: Jonas Jelonek <jelonek.jonas@gmail.com>
For LEDs that have no network trigger configuration in Device Tree
(no mode or family properties), net_activate() infers the family
from the LED name or function string. If that inference fails,
the trigger previously returned -EINVAL and refused to activate.
This is too strict for manual activation via sysfs (e.g.
echo "network" > /sys/class/leds/<led>/trigger) on LEDs that
were not declared for the network trigger in DT. In that case
the user expects the trigger to load with sensible defaults.
Change the non-DT activation path to fall back to NET_TRIG_WLAN
instead of failing, while keeping the condition visible via pr_warn().
Device Tree paths with dt_mode or dt_family are left unchanged
and continue to fail on invalid parameters
Signed-off-by: Mieczyslaw Nalewaj <namiltd@yahoo.com>
Link: https://github.com/openwrt/openwrt/pull/24235
Signed-off-by: Jonas Jelonek <jelonek.jonas@gmail.com>
fe_poll_rx() takes the packet length directly from the RX descriptor and
passes it to skb_put() without checking that it fits in the allocated
buffer. A malformed or stale descriptor can therefore extend the skb
beyond its tailroom and corrupt memory.
Reject lengths larger than skb_tailroom(), account the packet in
rx_length_errors and rx_dropped, free the affected skb, and continue by
installing the replacement descriptor.
Signed-off-by: Nickolay Savchenko <n.savchenko@axioma.lv>
Link: https://github.com/openwrt/openwrt/pull/24268
Signed-off-by: Jonas Jelonek <jelonek.jonas@gmail.com>
fe_txd_unmap() uses dma_len0 and dma_len1 to decide whether each TX
mapping must be passed to dma_unmap_page(). After unmapping, however,
the code passed the dma_addr0 and dma_addr1 field identifiers to
dma_unmap_len_set().
This leaves the actual length fields unchanged. A reused descriptor
slot can therefore retain a non-zero length and attempt to unmap an old
DMA mapping again.
Clear dma_len0 and dma_len1 after the mappings have been released.
Signed-off-by: Nickolay Savchenko <n.savchenko@axioma.lv>
Link: https://github.com/openwrt/openwrt/pull/24268
Signed-off-by: Jonas Jelonek <jelonek.jonas@gmail.com>
The return value of device_get_match_data was still explicitly casted to
the driver-internal type. However, since this function returns 'const
void *' and in C void pointers are automatically casted, this isn't
needed. Thus, drop it.
Link: https://github.com/openwrt/openwrt/pull/24310
Signed-off-by: Jonas Jelonek <jelonek.jonas@gmail.com>
For 10GBase-R and 2500Base-X, the patching sequences for the slower
modes are also applied. This mirrors the SDK which uses some automatic
detection and only does a one-time initialization. However, Linux works
different. The PCS is configured to a specific mode on demand. Thus,
there is no need to apply the other patching when it isn't really
needed.
Those patching sequences seem to initialize AFE blocks within the
SerDes, thus a 1G AFE shouldn't be needed for 10GBase-R. Testing
confirms this so far, no difference in any link characteristics when
e.g. 1G and 2.5G sequences aren't applied for a 10GBase-R link.
Link: https://github.com/openwrt/openwrt/pull/24310
Signed-off-by: Jonas Jelonek <jelonek.jonas@gmail.com>
So far, the 10GBase-R configuration mirrored the SDK which in addition
also sets up 1000Base-X and lets it run in a special mode having
autodetection of 10G/1G. This doesn't make that much sense given that
Linux will trigger PCS reconfiguration once the interface mode has
changed. Thus, we should only provide that for each mode standalone, not
for some proprietary and special mixed auto mode.
Link: https://github.com/openwrt/openwrt/pull/24310
Signed-off-by: Jonas Jelonek <jelonek.jonas@gmail.com>
The mode configuration calls LEQ/DFE reset and RX reset before doing
USXGMII configuration. Though the SDK does that similar, these calls are
actually unneeded because essentially the same is executed later again
in the attachment configuration. This is also the place where it
rather belongs. Thus, drop those calls in mode configuration.
Link: https://github.com/openwrt/openwrt/pull/24310
Signed-off-by: Jonas Jelonek <jelonek.jonas@gmail.com>
Drop the unused helper rtpcs_931x_sds_reset because it is unused and -
if it was used - would actively mess with the defined SerDes
deactivation/activation in pcs_config.
Link: https://github.com/openwrt/openwrt/pull/24310
Signed-off-by: Jonas Jelonek <jelonek.jonas@gmail.com>
Commit 7899dfa6ef ("realtek: pcs: rtl931x: separate and reuse
1000base-x config") introduced an issue by accident, using the register
value 0x12 instead of 0x13. A regression hasn't been noticed before, for
yet unknown reasons the 1000Base-X still worked here and there. Probably
due to some external setup.
However, this currently breaks 1000Base-X functionality on at least one
switch. Correcting the register value instantly restores 1000Base-X,
allowing the link to come up. It is unclear yet what this field means,
according to the SerDes register defines from related RTL8295 this might
be TX mode configuration field.
Also add another write which is present in several SDK versions.
Referring from related RTL8295, this might be a field called
EN_LINK_FIB1G, enabling 1000Base-X operation.
Fixes: 7899dfa6ef ("realtek: pcs: rtl931x: separate and reuse 1000base-x config")
Link: https://github.com/openwrt/openwrt/pull/24310
Signed-off-by: Jonas Jelonek <jelonek.jonas@gmail.com>
The two packages rtl826x-firmware and rtl826x-lp-firmware are built
from the same source, yet have 'VERSION=xxx' overrides that modify
the package name and metadata. This causes issues with apk, as
it always selects the package with the higher version number (the
'-lp-' one), irrespective of which package is desired.
Remove the VERSION overrides and use the actual package version so
that apk can install the correct package. The binary contents of
the packages remain unaffect, this only changes the package file
name and metadata related to versioning.
Before
rtl826x-firmware-20221115.apk
rtl826x-lp-firmware-20240729.apk
After
rtl826x-firmware-2026.01.24~0cd4abe2-r4.apk
rtl826x-lp-firmware-2026.01.24~0cd4abe2-r4.apk
Fixes: https://github.com/openwrt/openwrt/issues/24145
Signed-off-by: Eric Fahlgren <ericfahlgren@gmail.com>
Link: https://github.com/openwrt/openwrt/pull/24201
Signed-off-by: Jonas Jelonek <jelonek.jonas@gmail.com>
Tianling Shen