Add support for PoE functionality using the realtek-pse-mcu driver
(kmod-pse-realtek-mcu-i2c) interfacing the on-board PoE MCU and RTL8239
PSE chips.
This doesn't include any support for PoE-related LEDs.
Link: https://github.com/openwrt/openwrt/pull/23222
Signed-off-by: Jonas Jelonek <jelonek.jonas@gmail.com>
Instead of relying on the userspace implementation, make this device the
first user of the new realtek-pse kernel driver (kmod-pse-realtek-mcu-uart)
based on the PSE-PD framework to interface PoE functionality of that
switch. Control of PoE functionality happens via ethtool / netifd now.
Drop selecting realtek-poe for this device.
This doesn't include any support for PoE-related LEDs.
Link: https://github.com/openwrt/openwrt/pull/23222
Signed-off-by: Jonas Jelonek <jelonek.jonas@gmail.com>
Add a patch which modifies the Realtek PSE MCU driver backport to add a
sysfs control to control detection mode per port. Some older,
bad-designed devices aren't detected properly in standard mode on some
switches, though vendor firmware powers them properly. Testing shows
that enabling the detection of legacy PDs by allowing wider resistance,
more input capacitance and using a wider detection window, solves this
issue.
The legacy detection can be activated by writing 1 to
portN/detection_legacy in the device's sysfs, e.g.
echo 1 > /sys/bus/i2c/devices/3-0020/port0/detection_legacy
This patch is kept downstream for now, upstreaming will be attempted
though it is likely that upstream prefers a generic pse-pd approach.
Link: https://github.com/openwrt/openwrt/pull/23222
Signed-off-by: Jonas Jelonek <jelonek.jonas@gmail.com>
Add pending patches which add a PSE driver for the PSE setup found on
most of Realtek-based switches. An MCU with a Realtek-defined firmware
and protocol fronts one or more PSE chips (from Realtek or Broadcom) as
a management controller.
The driver provides both I2C/SMBus and UART communication, which varies
among our supported switches. There is no need for complicated userspace
handling anymore, the PSE setup is defined in the device tree and
interfaced in userspace via ethtool, netlink and netifd support.
Those patches have progressed far enough upstream, the bindings are
reviewed. Thus, we can keep this intermediate version downstream to open
it up earlier for usage. Only little changes are expected til the final
version lands.
Link: https://github.com/openwrt/openwrt/pull/23222
Signed-off-by: Jonas Jelonek <jelonek.jonas@gmail.com>
Add a backport patch and pending patches needed by upcoming PSE drivers
which are built as modules and probed after the MAC/PHY.
The net effect for module-built PSE controllers: attachment to PHYs
happens via the lifecycle notifier rather than via probe-time
-EPROBE_DEFER coupling, so the MDIO/DSA probe no longer sees any
PSE-originated -EPROBE_DEFER and the probe-retry storm is gone.
Link: https://github.com/openwrt/openwrt/pull/23222
Signed-off-by: Jonas Jelonek <jelonek.jonas@gmail.com>
The EAGLE PCIe WiFi card require PCIe0 to be in 2-lanes mode to correctly
work. Add the missing property to enable this mode and restore correctly
functionality of the WiFi card.
Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
The SCU phandle is mandatory to configure PCIe MUX when PCIe 2-lanes mode
is enabled.
Add the missing property where needed.
Fixes: 7d56183d90 ("airoha: replace PCIe x2-mode patch with new pending version")
Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
The current x2-mode patch is mostly an hack ported from Airoha SDK. Replace
with in favor of a new version posted upstream that better implement
handling of reset and configuring x2-mode. This now use the standard
num-lanes property and dedicated PERSTOUT resets exported by the clk
driver.
All the DTS that used x2-mode are updated.
Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
IPQ60xx and IPQ807x use threaded NAPI for EDMA. The NAPI threads
inherit CPU0 affinity, and running both there can eventually starve the
RX fill ring under sustained traffic.
Add an IPQ60xx smp_affinity service and extend the existing IPQ807x
service to discover the EDMA IRQs and NAPI IDs at runtime. Place RX on
CPU1 and TX on CPU2. Retry EDMA setup asynchronously because its NAPI
threads may appear after the init service runs.
Provide the same UCI enable and logging controls on both subtargets.
IPQ50xx uses a different Ethernet driver and is left unchanged.
Link: https://github.com/openwrt/openwrt/pull/24203
Signed-off-by: Robert Marko <robimarko@gmail.com>
Run the EDMA RX and TX NAPI poll loops in dedicated kernel threads by
default. This allows the threads and their interrupts to be placed on
separate CPUs and avoids overloading a single softirq context.
If thread creation fails, dev_set_threaded() leaves NAPI in softirq mode
and the driver reports the failure.
Link: https://github.com/openwrt/openwrt/pull/24203
Signed-off-by: Robert Marko <robimarko@gmail.com>
A malformed RX preheader can occur repeatedly after the descriptor ring
overruns. Rate-limit the warning to prevent excessive console output
from making the receive stall worse.
Decode the little-endian preheader metadata before printing it and use
consistent hexadecimal formatting.
Link: https://github.com/openwrt/openwrt/pull/24203
Signed-off-by: Robert Marko <robimarko@gmail.com>
RX descriptor fields use little-endian byte order. Decode the DMA
address and status with the matching helpers before consuming them.
This makes the byte order explicit and keeps the code portable. The
conversions remain no-ops on little-endian IPQ60xx.
Link: https://github.com/openwrt/openwrt/pull/24203
Signed-off-by: Robert Marko <robimarko@gmail.com>
While the base NVMEM cell (hw_mac_addr) is already defined in the device tree, it was not being utilized by the actual interfaces.
This patch completes the kernel-level MAC assignment by:
1. Correcting the label-mac-device alias to point to the WAN port (&swport5), ensuring the system reports the sticker MAC address correctly.
2. Assigning the base MAC address (offset 0) to the WAN port (&swport5).
3. Assigning the base MAC address (offset 1) to the LAN ports (&swport1 - &swport4).
4. Configuring the proper NVMEM cell references for the PCIe-attached QCA9984 radio (offset 2) and the built-in ATH11K radio (offset 3).
This eliminates the need for post-boot MAC address manipulation and ensures robust, predictable interface initialization.
Signed-off-by: Jackie264 <jackie.han@gmail.com>
Link: https://github.com/openwrt/openwrt/pull/24193
Signed-off-by: Robert Marko <robimarko@gmail.com>
DSA copies the driver features to slave device, including offload
capabilities. Once a packet is sent through a DSA slave interface,
according to its features, the kernel does not calculate checksums,
expecting that the HW will fill the gaps. DSA adds the defined DSA
tag and sends the tagged packet through the master device.
Ethertype DSA tags expect the driver to calculate checksum based on the
csum_start/csum_offset. However, mtk_soc_eth does not use that info.
It checks the network header and decides if the HW can manage that
packet, unaware that mac layer now contains an extra DSA tag. When
that tag is the Mediatek CPU tag, offload will work as expected.
When it is an incompatible DSA tag or if DSA is stacking two incompatible
DSA tags, the driver will still count on the HW offload. In this case,
packets go to the network with an incorrect checksum.
Before this change, tag_ops->proto == DSA_TAG_PROTO_MTK was used,
which disabled offload for every non-Mediatek tag, including the
RTL8367S switch's RTL8_4 tag that this fix specifically targets.
Replace the hardcoded whitelist with a blacklist scoped to the
RTL8367S: only disable offload for DSA_TAG_PROTO_RTL8_4. The RTL8_4T
(the trailing-tag variant) is left untouched because its rtl8_4t tagger
already checksums the frame in software before appending the tag.
Tags for other DSA-capable switches are left untouched by this fix
and are not claimed to be offload-safe.
Fixes: 3c0a73b4d2 ("ramips: ethernet: ralink: fix offload with diff dsa tag")
Signed-off-by: Mieczyslaw Nalewaj <namiltd@yahoo.com>
Link: https://github.com/openwrt/openwrt/pull/24064
Signed-off-by: Robert Marko <robimarko@gmail.com>
DSA copies the driver features to slave device, including offload
capabilities. Once a packet is sent through a DSA slave interface,
according to its features, the kernel does not calculate checksums,
expecting that the HW will fill the gaps. DSA adds the defined DSA
tag and sends the tagged packet through the master device.
Ethertype DSA tags expect the driver to calculate checksum based on the
csum_start/csum_offset. However, mtk_eth_soc does not use that info.
mtk_eth_soc checks the network header and decides if the HW can manage
that packet, unaware that MAC layer now contains an extra DSA tag. When
that tag is the Mediatek CPU tag, offload will work as expected.
When it is an incompatible DSA tag or if DSA is stacking two incompatible
DSA tags, the driver will still count on the HW offload. In this case,
packets are sent to the network with an incorrect checksum.
This patch adds an extra check that disables offloading only for the
RTL8367S switch's RTL8_4 tag, which is known to break MTK checksum
offload. The RTL8_4T (the trailing-tag variant) is not affected because
its rtl8_4t tagger already checksums the frame in software before appending
the tag, so ip_summed is no longer CHECKSUM_PARTIAL by the time this driver
sees it.
This approach avoids an overly conservative whitelist which would
disable offload for every non-Mediatek tag, regardless of whether
that tag is actually incompatible with MTK checksum offload.
Tags for other DSA-capable switches are left untouched by this fix
and are not claimed to be offload-safe.
Signed-off-by: Luiz Angelo Daros de Luca <luizluca@gmail.com>
Signed-off-by: Schneider Azima <Schneider-Azima12@protonmail.com>
Signed-off-by: Mieczyslaw Nalewaj <namiltd@yahoo.com>
Link: https://github.com/openwrt/openwrt/pull/23996
Signed-off-by: Robert Marko <robimarko@gmail.com>
It was reported that cond.m4 in gnulib is a name clash with
cond.m4 provided by Automake, where they are for completely
different purposes instead of different versions of the same macros.
A quick survey of all the macro files in the build directory reveals that
this is the only case where the gnulib copy is signficantly smaller
than the rest of the copies of the same macro name
distributed in the rest of the build system,
and the only one that name clashes with Automake.
A previous fix added a prefix to all macros from gnulib,
but the name must match how it is described in the respective modules files
as a functional requirement to build certain tools for certain (older) hosts,
so patch the problematic module instead of renaming all macros from gnulib.
Ref: c820f097e0 ("tools: gnulib: install .m4 file with gl_ prefix")
Ref: 78a8cfb577 ("tools: gnulib: fix broken install of .m4 files")
Reported-by: Christian Marangi <ansuelsmth@gmail.com>
Signed-off-by: Michael Pratt <mcpratt@pm.me>
Link: https://github.com/openwrt/openwrt/pull/24136
Signed-off-by: Robert Marko <robimarko@gmail.com>
This is the recommended way for the OF based platform. According to
the original patch, set GPIO to low level to assert the reset, set
GPIO to high level to deassert. Hence, adjust the dts GPIO polarity
to active-low.
Signed-off-by: Shiji Yang <yangshiji66@outlook.com>
Link: https://github.com/openwrt/openwrt/pull/18948
Signed-off-by: Jonas Jelonek <jelonek.jonas@gmail.com>
Add DTSI files defining EDMA, PPE, and UNIPHY nodes for the new PPE
driver bindings on IPQ5018, IPQ6018 and IPQ8074 platforms.
IPQ5018 requires a patch for UNIPHY node as its cmn PLL node is upstream.
These replace the existing NSS-DP ones.
Signed-off-by: John Crispin <john@phrozen.org>
[IPQ5018]
Signed-off-by: George Moussalem <george.moussalem@outlook.com>
[IPQ6018 and IPQ8074]
Link: https://github.com/openwrt/openwrt/pull/22381
Signed-off-by: Robert Marko <robimarko@gmail.com>
Add IPQ5018 DWMAC driver. IP version of this Synopsys DWMAC is 3.7.
This Qualcomm IPQ5018 specific MAC implementation supports link speeds
of 10HD/FD, 100HD/FD, 1,000HD/FD, and 2500FD and SGMII and 2500BASEX
interface modes.
The driver supports the MAC be attached directly to a PHY or via an
optional PCS to a switch or PHY.
Signed-off-by: George Moussalem <george.moussalem@outlook.com>
Link: https://github.com/openwrt/openwrt/pull/22381
Signed-off-by: Robert Marko <robimarko@gmail.com>
Hardware:
- SoC: MediaTek MT7628AN
- Flash: 16 MiB SPI NOR
- RAM: 128 MiB DDR2
- WLAN: 2.4 GHz (MT7628AN, 11n), 5 GHz (MediaTek MT7615E, 11ac)
- Ethernet: 1x10/100 Mbps LAN
- Buttons: 1 Reset button
- LEDs: 8x Green
- LTE: internal USB-connected modem Quectel EC200A
- Serial Console: unpopulated header 115200 8n1
MAC addresses:
+---------+-------------------+-----------+
| | MAC | Algorithm |
+---------+-------------------+-----------+
| LAN | 80:af:ca:xx:xx:x0 | label |
| WLAN 2g | 80:af:ca:xx:xx:x0 | label |
| WLAN 5g | 80:af:ca:xx:xx:x2 | +2 |
+---------+-------------------+-----------+
Migration to OpenWrt:
- Download the RSA signed intermediate firmware:
`openwrt-ramips-mt76x8-cudy_lt500-outdoor-v1-squashfs-flash.bin`
- Connect computer to LAN and flash the intermediate firmware via OEM web interface
- OpenWrt is now accessible via 192.168.1.1
Revert back to OEM firmware:
- Press the reset button while powering on the device
- Connect the LAN port to the PC
- Open 192.168.1.1 in a browser and use the wizard to upload and flash OEM firmware image
- When recovery process is done, OEM firmware is accessible via 192.168.10.1 again
Signed-off-by: rodriguezst <git@rodriguezst.es>
Link: https://github.com/openwrt/openwrt/pull/23752
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
Using UUID-based client IDs for DHCPv4/DHCPv6 with no option of falling
back to hardware IDs (ie. MAC-address or DUID-LL) resp. none at all (IPv4),
is causing regressions in some setups.
Introduce a new setting to override the preferred client ID to be used for
DHCPv4/DHCPv6 on a per-interface basis:
network.<ifname>.sendclientid='auto|global|hardware|none'
- "auto" (default if empty or not present) uses any explicitly defined
client ID, or falls back to the global DUID and finally to the DUID-LL
resp. MAC address (ie. identical to before this commit).
- "global" uses the global default DUID, if configured, for DHCPv4 and
DHCPv6 requests, even if a client ID is explicitly specified for the i/f
- "hardware" will not pass a client ID to udhcpc/odhcp6c, even if a global
default DUID is configured or an explicit client ID specified, resulting
in the i/f MAC address resp. type 3 DUID(-LL) to be used
- "none" (IPv4 only) will not add an option tag 61 to DHCPv4 requests at
all.
Signed-off-by: Shine <4c.fce2@proton.me>
Link: https://github.com/openwrt/openwrt/pull/24107
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
Tianling Shen