Update to 2.5.3 and use the official tarball.
Changelog: https://github.com/ppp-project/ppp/releases/tag/v2.5.3
Removed upstreamed:
- 000-pppd-session-fixed-building-with-gcc-15.patch
- 001-pppdump-fixed-building-with-gcc-15.patch
- 501-fix-memcpy-fortify.patch
- 502-remove_mru.patch
Manually rebased:
- 500-add-pptp-plugin.patch
Add a pending patch to relax the check to avoid breaking existing
configurations.
Signed-off-by: Qingfang Deng <dqfext@gmail.com>
Link: https://github.com/openwrt/openwrt/pull/23540
Signed-off-by: Jonas Jelonek <jelonek.jonas@gmail.com>
Published sources archives may contain a mixture of MTIMEs, so taking the time
of the first file found varies based on filesystem order. To fix this, sort all
MTIMEs and take the latest.
Since piping into a file directly creates that file, we also need to
specifically tell `find` to ignore `version.date`.
Furthermore, move this prior to the ./src copy step, since for some packages,
the OpenWrt build system ships extra ./src files, which would introduce the
wrong timestamps again.
Fix: e36c2946b7 build: derive PKG_SOURCE_DATE_EPOCH from the unpacked source tree
Link: https://github.com/openwrt/openwrt/pull/23756
Signed-off-by: Paul Spooren <mail@aparcar.org>
The firmware-version gate in mxl862xx_phylink_get_caps() leaves
config->supported_interfaces empty for the CPU/SerDes ports (9, 13) when
the switch runs firmware older than 1.0.84. phylink rejects an empty
supported_interfaces bitmap, so the switch fails to probe at all:
mxl862xx mdio-bus:10: switch ready after 2480ms, firmware 1.0.70 (build 70)
mxl862xx mdio-bus:10: phylink: error: empty supported_interfaces
error creating PHYLINK: -22
mxl862xx mdio-bus:10: probe with driver mxl862xx failed with error -22
This regresses boards still shipping the older vendor firmware (e.g. the
BananaPi BPi-R4 Pro 8X, which ships 1.0.70) where all LAN ports disappear.
Ungate only the CPU/SerDes ports (9, 13) so the switch probes and the user
can update the firmware; ports 10..12 and 14..16 stay gated as they are
genuinely unsupported by the old firmware.
Tested on a BPi-R4 Pro 8X with switch firmware 1.0.70 (kernel 6.18); the
6.12 patch receives the identical change for parity.
Fixes: 028dc3f57a ("generic: 6.18: update MxL862xx DSA switch driver")
Fixes: 5b69e6a4a6 ("generic: 6.12: update MxL862xx DSA switch driver")
Signed-off-by: Aliaksandr Babrykovich <abobrikovich@gmail.com>
[refreshed patches]
Signed-off-by: Daniel Golle <daniel@makrotopia.org>
The u-boot build for mediatek ARM SoCs doesn't require pylibfdt. We
can use pre-build kernel DTC to save some build time.
Signed-off-by: Shiji Yang <yangshiji66@outlook.com>
Commit 9091c9f8cb ("ath79: mikrotik: compile SWCONFIG and AR8216_PHY
as modules") caused the hybrid PHY/MDIO ar8xxx driver to be built as a
module instead of built-in. On at least MikroTik RouterBOARD 951G-2HnD,
this prevents the kernel from binding the correct PHY driver at boot
because the ar8xxx driver is not yet available when the MDIO bus is
probed:
- before:
ag71xx-legacy 19000000.eth: invalid MAC address, using random address
switch0: Atheros AR8327 rev. 4 switch registered on mdio.0
ag71xx-legacy 19000000.eth: connected to PHY at mdio.0:00 [uid=004dd034, driver=Atheros AR8216/AR8236/AR8316]
eth0: Atheros AG71xx at 0xb9000000, irq 4, mode: rgmii
- after:
ag71xx-legacy 19000000.eth: invalid MAC address, using random address
ag71xx-legacy 19000000.eth: connected to PHY at mdio.0:00 [uid=004dd034, driver=Generic PHY]
eth0: Atheros AG71xx at 0xb9000000, irq 4, mode: rgmii
As the PHY is already bound to the fallback "Generic PHY" driver when
the ar8xxx module is loaded, the switch remains non-functional and the
router has no network connectivity.
Fix by also compiling the MAC driver (ag71xx-legacy) as a module,
deferring switch initialization until control is transferred to
userspace during boot. The configured module autoload priorities
(ar8xxx: 43, ag71xx-legacy: 50) ensure that the ar8xxx driver is loaded
before ag71xx-legacy.
Fixes: https://github.com/openwrt/openwrt/issues/23739
Fixes: 9091c9f8cb ("ath79: mikrotik: compile SWCONFIG and AR8216_PHY as modules")
Suggested-by: Daniel Golle <daniel@makrotopia.org>
Signed-off-by: Michał Kępień <openwrt@kempniu.pl>
Link: https://github.com/openwrt/openwrt/pull/23748
Signed-off-by: Robert Marko <robimarko@gmail.com>
Sometimes redundancy is so obvious that one likely misses it. Trying to
bring all SerDes setup into a unified shape, one thinks twice if
something is really needed or not.
For the RTL838x case, the single writes for take/release reset were still
an outlier. Looking closer at them one can see that the same bits are all
covered already in deactivate/activate. So before, they have been put
into the desired state but those outlier writes mess with them again.
[0, 3, 0x7146/0x7106] just deals with the SOFT_RST bit that is already
covered by rtpcs_838x_sds_reset.
[0, 0, 0xc00] touches multiple bits, amongst the EN_RX/EN_TX bits
already covered in deactivate/active. Moreover, it potentially forces
other bits into a state causing broken functionality, e.g.
INV_HSI/INV_HSO which deal with the polarity. This has no effect right
no right now but might be a latent issue in the future.
Also move the reset call down to the end of the function, doing a
soft/RX reset after every configuration is done. This is likely what the
SDK also intended, and mirrors the 839x behavior.
Link: https://github.com/openwrt/openwrt/pull/23746
Signed-off-by: Jonas Jelonek <jelonek.jonas@gmail.com>
Reduce the per-SerDes patching to a per-mode patching since they share a
lot of similarities, especially for QSGMII.
For fiber patching, the differences are bigger. This takes an approach
to merge the sequences completely despite applying some settings which
weren't applied before on one of the SerDes. Testing and SerDes dumps
showed no or minimal differences, and no practical effect on
functionality. A look at the SerDes register documentation we have shows
reordering the writes isn't problematic because most of the bits aren't
any trigger bits.
With all its users gone, we can now drop also the workaround SDS macro.
Link: https://github.com/openwrt/openwrt/pull/23741
Signed-off-by: Jonas Jelonek <jelonek.jonas@gmail.com>
For an attempt to simplify and reduce patching, carve out two special
writes for SerDes 0/1. While their exact purpose isn't fully known, they
need to match to make QSGMII on those two SerDes work. In order to be
able to merge the per-SerDes QSGMII patching sequences, carve them out
to the patching function one level above.
Link: https://github.com/openwrt/openwrt/pull/23741
Signed-off-by: Jonas Jelonek <jelonek.jonas@gmail.com>
In order to have a unified SerDes setup sequence, align RTL838x to all
other variants. Set the mode after patching has been applied. Testing on
devices showed the order is rather irrelevant.
Link: https://github.com/openwrt/openwrt/pull/23741
Signed-off-by: Jonas Jelonek <jelonek.jonas@gmail.com>
Expand the 838x deactivate/activate helpers to also cover the analog lane
enables (REG0 EN_RX/EN_TX) and the fiber path power-down (FIB_REG0
CFG_FIB_PDOWN), which are operational-state concerns rather than reset
concerns:
- _deactivate: clear EN_RX/EN_TX and set CFG_FIB_PDOWN in addition to
block-level power off.
- _activate: clear CFG_FIB_PDOWN and set EN_RX/EN_TX before block-level
power on. The pulse-start EN=0 is omitted since _deactivate already
established EN=0 and nothing in between touches REG0[1:0].
Shrink rtpcs_838x_sds_reset() accordingly: it now owns only the SOFT_RST
toggle, making it a pure digital reset primitive. The stale "SerDes %d
reset" dev_info was dropped along with the analog/fiber writes.
Behavioural note: the EN and FIB_PDOWN writes now happen *after* the
SOFT_RST release inside rtpcs_838x_sds_reset(), rather than before it as
in the old combined sds_reset. This creates a brief window where the
SerDes is out of digital reset with lanes still disabled, before
activate re-enables them. Consistent with the new
power_off/deactivate -> configure -> reset -> activate/power_on phase
structure, but diverges from the SDK ordering (EN pulse before SOFT_RST
release). Testing on real hardware shows no difference.
Link: https://github.com/openwrt/openwrt/pull/23741
Signed-off-by: Jonas Jelonek <jelonek.jonas@gmail.com>
Add support for TSW202 PoE switch. This is an RTL8380 based switch
with two SFP slots, and 8 PoE 802.3af one every RJ-45 port.
The max budget is 240W.
The vendor firmware configures the PSE
with a per-port budget of 30.0W.
Specifications:
---------------
* SoC: Realtek RTL8380M
* Flash: 16 MiB SPI NOR W25Q80RV, 8Mb_Serial_Flash, low_power
* RAM: 128 MiB Winbond W631GG8NB 151
* Ethernet: 8x 10/100/1000 Mbps with PoE
2x SFP slots
* Buttons: 1 "Reset" button on front panel
* Power: 48V-54V DC barrel jack
* UART: 1 serial header with terminal on the back side.
With ground, rx, tx, and 3.3V
* PoE: 2 XS2184
* LED: 2 i2c SL74HC164
Works:
------
- (8) RJ-45 ethernet ports
- (2) SFP with ethernet or fiber
- Switch functions
TODO:
------
- LEDs are always on
- Power-over-Ethernet are always on
Install via web interface:
-------------------------
The openwrt firmware will not accept and flash the sysupgrade image.
It is recommended to flash with sysupgrade -n -f over ssh.
Dokumantation, Bootlogs, and Fotos can be found on
https://git.f2a.space/patrick/openwrt-24.10-tsw202/-/wikis/home
Signed-off-by: Patrick Grimm <patrick@lunatiki.de>
Link: https://github.com/openwrt/openwrt/pull/21003
Signed-off-by: Jonas Jelonek <jelonek.jonas@gmail.com>
Since 6.18 RTL8261N support was added to the generic Realtek PHY driver
and was dropped from the downstream driver.
So, fix the missing RTL8261N support by including the Realtek PHY kmod
and the relevant firmware.
Signed-off-by: Robert Marko <robert.marko@sartura.hr>
Verify and clean up client ID and global DUID config values before use, in
order to prevent DHCP client malfunction and loss of IPv4 and/or IPv6
connectivity.
- Accept common separators in the string (colon, dash, spaces/tabs, lf)
- Ignore invalid values (non-hex or odd-numbered length)
- Log a warning for invalid settings
The fall back mechanism is as follows:
If a (user-configured) network.<ifname>.clientid setting is found invalid,
ignore and fall back to using network.globals.dhcp_default_duid. In case
that's also invalid (e.g. has been tampered with), don't pass a client
ID to updhc/odhcpc. In that case, udhcpc/odhcpc will use their defaults,
which currently is the i/f MAC address resp. the i/f DUID-LL.
Only error handling is introduced, no behavior change for valid settings.
Signed-off-by: Shine <4c.fce2@proton.me>
Link: https://github.com/openwrt/openwrt/pull/23662
Signed-off-by: Robert Marko <robimarko@gmail.com>
Not needed when using nvmem. All others left alone.
Move some swport nvmem definitions to the root gmac to avoid a
randomized MAC address for the GMAC. The former inherits from the latter anyway.
Signed-off-by: Rosen Penev <rosenp@gmail.com>
Link: https://github.com/openwrt/openwrt/pull/22550
Signed-off-by: Jonas Jelonek <jelonek.jonas@gmail.com>
APK compresses it's helptext using LUA and require `zlib`, which isn't
available on the Buildbots. It thens falls back to `gzip`, which embeds the
MTIME, making the binary itself unreproducible.
This commits adds a downstream patch to run `gzip` with `-n`, setting the time
to 0.
Link: https://github.com/openwrt/openwrt/pull/23736
Signed-off-by: Paul Spooren <mail@aparcar.org>
Original ar71xx has this setup:
define WNDAP360_WMAC0_MAC_OFFSET 0x120c
define WNDAP360_WMAC1_MAC_OFFSET 0x520c
/* Reusing wifi MAC with offset of 1 as eth0 MAC */
ath79_init_mac(ath79_eth0_data.mac_addr,
art + WNDAP360_WMAC0_MAC_OFFSET, 1);
ap94_pci_init(art + WNDAP360_CALDATA0_OFFSET,
art + WNDAP360_WMAC0_MAC_OFFSET,
art + WNDAP360_CALDATA1_OFFSET,
art + WNDAP360_WMAC1_MAC_OFFSET);
The ath79 port made a questionable change for eth0 being just art with
no offset. That MAC ends up being the OUI for Atheros.
WNDAP360_WMAC1_MAC_OFFSET is the same as WNDAP360_WMAC0_MAC_OFFSET
except with the first hex value being subtracted by 2, which is not a
valid OUI.
And newer Netgear firmware seems to assign differently as well,
art_120C as a base and the others incremented by 0x8.
Switch the assignment to the latest firmware and add label-mac-device to
document that the first Wi-FI MAC address is printed on the device.
Signed-off-by: Rosen Penev <rosenp@gmail.com>
Link: https://github.com/openwrt/openwrt/pull/22895
Signed-off-by: Jonas Jelonek <jelonek.jonas@gmail.com>
Convert the last remaining userspace eeprom for ath9k to nvmem. Well,
easily converted at least.
wifi MAC has to be handled in userspace as the kernel nvram driver works
on memory mapped addresses, not mtd ones.
Signed-off-by: Rosen Penev <rosenp@gmail.com>
Link: https://github.com/openwrt/openwrt/pull/14666
Signed-off-by: Jonas Jelonek <jelonek.jonas@gmail.com>
