This fixes a common reference counting bug typically along the lines of:
```
uc_value_push(ucv_get(ucv_string_new(...)));
```
This would leave our new string with a reference count of 2, one from
the construction of the string, the other from `ucv_get`. This would
prevent the strings from being correctly cleaned up when it goes out
of scope.
Signed-off-by: Matthew Cather <mattbob4@gmail.com>
(cherry picked from commit f79968ee0f76c41414fb0c08980b9c2a259964d3)
When a feed has submodules, all its submodules are fully cloned whereas
the feed itself is shallowed. Let's be consistent and perform shallow clones
as well for the submodules.
Signed-off-by: Cedric CHEDALEUX <cedric.chedaleux@orange.com>
Link: https://github.com/openwrt/openwrt/pull/18003
Signed-off-by: Robert Marko <robimarko@gmail.com>
(cherry picked from commit 9ec32cfb2733856a2ab4caee07d9b3297568381d)
When a feed is referenced with a specific commit (i.e. <git_url>^<sha1>),
a full clone was performed and a branch was created from the sha1
and named with the sha1. Other git clones operations are shallowed.
As Git does not support clone at a specific commit, let's first perform
a shallow clone to latest commit, then fetch the relevant commit and
finally checkout it (no more 'pseudo' branch).
It saves bandwith and significantly speeds up the feed update process.
Signed-off-by: Cedric CHEDALEUX <cedric.chedaleux@orange.com>
Link: https://github.com/openwrt/openwrt/pull/18003
Signed-off-by: Robert Marko <robimarko@gmail.com>
(cherry picked from commit 32d0a57dc10811a24816e51f10e55963f40fe462)
75a236be122a service: add missing null pointer check
f5341f327539 ubus: add api for generating and validating security tokens
3fab99eab4d5 add udebug support
28d86bd30e97 pex: only respond to update requests when we have network data
8e6f37cc361e pex-msg: ignore no-data responses if version is zero
12e6cf7f63e1 pex: create pex host from update responses
edc8fdae463a ubus: show the local addresses in network status
Signed-off-by: Felix Fietkau <nbd@nbd.name>
(cherry picked from commit ce68f61cb67a4701a108f838f510e72ca63ed78e)
ethtool since version 6.9 introduced support for getting/setting RSS
input transformation supported in Linux since version 6.8.
The now changed kernel ioctl ABI, however, cannot be detected from
userland, and ethtool since version 6.9 simply assumes that a previously
reserved field is now used to set the input transformation.
Unfortunately the default value RXH_XFRM_NO_CHANGE (0xff) used by ethtool
userland creates an incompatibility with older kernels which cannot be
resolved easily without introducing even more ABI breakage.
Work-around the issue and fix support for --set-rxfh and --set-rxfh-indir
ethtool userland tool commands by making the support for input_xfrm
conditional on compile time, and keep it disabled for Linux 6.6.
Fixes: 8c2dcd1518 ("ethtool: update to 6.10")
Signed-off-by: Daniel Golle <daniel@makrotopia.org>
Tested-by: Stijn Segers <foss@volatilesystems.org>
(cherry picked from commit 3a7467ffde413677de5465dde78a62dfa8d6774f)
Version 6.11 - October 8, 2024
* Feature: cmis: print active and inactive firmware versions
* Feature: flash transceiver module firmware (--flash-module-firmware)
* Feature: add T1BRR 10Mb/s mode to link mode tables
* Feature: support for disabling netlink from command line
* Fix: fix lanes parameter format specifier
* Fix: add missing clause 33 PSE manual description
* Fix: qsf: Better handling of Page A2h netlink read failure
* Fix: rss: retrieve ring count using ETHTOOL_GRXRINGS ioctl (-x)
* Misc: man page formatting fix
* changelog here: https://git.kernel.org/pub/scm/network/ethtool/ethtool.git/commit/NEWS?id=c0ea4b70c71334ef038f7a3416b228a50dada406
Tested on gl.inet MT6000, retrieve ring count is now working
Signed-off-by: Andrea Pesaresi <andreapesaresi82@gmail.com>
Link: https://github.com/openwrt/openwrt/pull/17607
Signed-off-by: Robert Marko <robimarko@gmail.com>
(cherry picked from commit 9454331b7fc896704a2c60b28767c282eb9ca0bd)
Specification:
* Mediatek MT7981BA
* 256 MB SPI-NAND
* 512 MB DDR4 RAM
* MT7976CN DBDC AX Wi-Fi
* MediaTek MT7531AE (3x LAN Gigabit ports) + Internal Gbe Phy (1x WAN Gigabit port)
* 4x LED (power, internet, fn, wifi)
* 3x buttons (wps, fn, reset)
* 1x USB 3.0 port
Serial Interface:
* 3 Pins GND, RX, TX
* Settings: 115200, 8N1
Notes:
* The device supports dual boot mode
* Fn led reassigned to wlan 2.4
Flash instruction:
The only way to flash OpenWrt image is to use tftp recovery mode in U-Boot:
1. Configure PC with static IP 192.168.1.2/24 and tftp server.
2. Rename "openwrt-mediatek-filogic-keenetic_kn-3811-squashfs-factory.bin"
to "KN-3811_recovery.bin" and place it in tftp server directory.
3. Connect PC with ethernet port, press the reset button, power up
the device and keep button pressed until status led start blinking.
4. Device will download file from server, write it to flash and reboot.
Signed-off-by: Maxim Anisimov <maxim.anisimov.ua@gmail.com>
Link: https://github.com/openwrt/openwrt/pull/17135
(cherry picked from commit d087a79b7b03fe93a221fd6246ce437c5c5325c3)
Link: https://github.com/openwrt/openwrt/pull/18055
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
Specification:
- MT7981 CPU using 2.4GHz and 5GHz WiFi (both AX)
- 512MB RAM
- 128MB SPI NAND
- 2 LEDs (green, orange)
- 3 buttons (fn, reset, wps)
- 2 2.5Gbit ethernet ports based on Airoha EN8811H phy
Serial Interface:
- 3 Pins GND, RX, TX
- Settings: 115200, 8N1
Notes:
- The device supports dual boot mode
Flash instruction:
The only way to flash OpenWrt image is to use tftp recovery mode in U-Boot:
1. Configure PC with static IP 192.168.1.2/24 and tftp server.
2. Rename "openwrt-mediatek-filogic-keenetic_kn-3911-squashfs-factory.bin"
to "KN-3911_recovery.bin" and place it in tftp server directory.
3. Connect PC with ethernet port, press the reset button, power up
the device and keep button pressed until status led start blinking.
4. Device will download file from server, write it to flash and reboot.
Signed-off-by: Maxim Anisimov <maxim.anisimov.ua@gmail.com>
Link: https://github.com/openwrt/openwrt/pull/16830
(cherry picked from commit 5a4eb56a7bc7d1d8028d103d50b0dba2ff7808c4)
Link: https://github.com/openwrt/openwrt/pull/18055
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
Changes between 3.0.15 and 3.0.16 [11 Feb 2025]
CVE-2024-13176[1] - Fixed timing side-channel in ECDSA signature
computation.
There is a timing signal of around 300 nanoseconds when the top word of
the inverted ECDSA nonce value is zero. This can happen with significant
probability only for some of the supported elliptic curves. In
particular the NIST P-521 curve is affected. To be able to measure this
leak, the attacker process must either be located in the same physical
computer or must have a very fast network connection with low latency.
CVE-2024-9143[2] - Fixed possible OOB memory access with invalid
low-level GF(2^m) elliptic curve parameters.
Use of the low-level GF(2^m) elliptic curve APIs with untrusted explicit
values for the field polynomial can lead to out-of-bounds memory reads
or writes. Applications working with "exotic" explicit binary (GF(2^m))
curve parameters, that make it possible to represent invalid field
polynomials with a zero constant term, via the above or similar APIs,
may terminate abruptly as a result of reading or writing outside of
array bounds. Remote code execution cannot easily be ruled out.
1. https://www.openssl.org/news/vulnerabilities.html#CVE-2024-13176
2. https://www.openssl.org/news/vulnerabilities.html#CVE-2024-9143
Build system: x86/64
Build-tested: bcm27xx/bcm2712
Run-tested: bcm27xx/bcm2712
Signed-off-by: John Audia <therealgraysky@proton.me>
Link: https://github.com/openwrt/openwrt/pull/17947
Signed-off-by: Robert Marko <robimarko@gmail.com>
(cherry picked from commit b4e6fd7b76440076eeff3a0789d40acbb5363ecf)
b43aeb5 wireless-regdb: assert and correct maximum bandwidth within frequency difference
68588bf wireless-regdb: Update regulatory info for Syria (SY) for 2020
0dda57e wireless-regdb: Update regulatory info for Moldova (MD) on 6GHz for 2022
b19ab0b wireless-regdb: Update regulatory info for Azerbaijan (AZ) on 6GHz for 2024
f67f40d wireless-regdb: Update regulatory info for Oman (OM)
bd70876 wireless-regdb: Update regulatory rules for Armenia (AM) on 2.4 and 5 GHz
6c7cbcc wireless-regdb: Permit 320 MHz bandwidth in 6 GHz band in ETSI/CEPT
f9f6b30 wireless-regdb: Update regulatory rules for Austria (AT)
39b47ea wireless-regdb: Update regulatory info for Cayman Islands (KY) for 2024
3dd7ceb wireless-regdb: allow NO-INDOOR flag in db.txt
4d754a1 wireless-regdb: Update regulatory rules for Iran (IR) on both 2.4 and 5Ghz for 2021
8c8308a wireless-regdb: Update frequency range with NO-INDOOR for Oman (OM)
c2f11e2 wireless-regdb: update regulatory database based on preceding changes
Signed-off-by: Rudy Andram <rmandrad@gmail.com>
Link: https://github.com/openwrt/openwrt/pull/17957
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
(cherry picked from commit da2cc98458f46745de95e88b6066620fbd02b190)
The proposed detection method was based on reading the LAUNCH_FREADY core flag.
However, this method only works before the cores are launched.
For this reason, the core number detection method has been changed to a simpler one.
For mt6721s the 17th revision bit is zero, hence we know that it is this chip,
so the number of cores is 1.
Fixes: https://github.com/openwrt/openwrt/issues/17764
Tested-by: Enrico Mioso <mrkiko.rs@gmail.com>
Tested-by: Simon Etzlstorfer <simon@etzi.at>
Tested-by: Mauri Sandberg <maukka@ext.kapsi.fi>
Co-authored-by: Shiji Yang <yangshiji66@qq.com>
Signed-off-by: Mieczyslaw Nalewaj <namiltd@yahoo.com>
Link: https://github.com/openwrt/openwrt/pull/17834
(cherry picked from commit bb84c256e701a21a97443ffe9dd1d510bd6c1c40)
Link: https://github.com/openwrt/openwrt/pull/18015
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
Set the SUPPORTED_DEVICES Device var so that sysupgrade images
are supported without a force.
Signed-off-by: Tim Harvey <tharvey@gateworks.com>
Link: https://github.com/openwrt/openwrt/pull/17964
(cherry picked from commit 5a124ff167ed42e28dba2805793b5ddcece0eb50)
Link: https://github.com/openwrt/openwrt/pull/18093
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
The upstream device-tree files are now using 'gateworks' instead of 'gw'
for compatible. Add this pattern so that the newer boards support
sysupgrade.
Signed-off-by: Tim Harvey <tharvey@gateworks.com>
Link: https://github.com/openwrt/openwrt/pull/17964
(cherry picked from commit ee73d35fbe0f18bfd0f710008de369236a220510)
Link: https://github.com/openwrt/openwrt/pull/18093
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
Both share the same OEM firmware but differ in product_name for safeloader
product_name:MR1800X,product_ver:1.0.0,special_id:45550000
Signed-off-by: Robert Senderek <robert.senderek@10g.pl>
Link: https://github.com/openwrt/openwrt/pull/17965
(cherry picked from commit f93367227e1458fb366304d0f431f12e95d244cd)
Link: https://github.com/openwrt/openwrt/pull/18031
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
By switching to the new RTL8231 driver in commit b7af54d5c18c ("realtek:
Simple conversions to RTL8231 MFD driver"), the bootloader state of the
RTL8231's pins is now maintained. As the bootloader de-asserts the PoE
enable signal, this means PoE output is no longer available.
Add a gpio-hog with high output, restoring the line value from when the
pin was configured (by default) as an input with a pull-up resistor.
This will hard-enable the PoE output, but the individual ports can still
be administratively disabled by realtek-poe or a similar tool.
Signed-off-by: Sander Vanheule <sander@svanheule.net>
(cherry picked from commit 890293c13cc0c7e23577cb92c36edcc9911b4400)
The JG928A has an RTL8231 on the aux mdio bus. Add it to dts to expose
the GPIO pins used to control and monitor the fan speed. To enable speed
control, add the appropriate kernel driver module to DEVICE_PACKAGES.
Of note, this does not control all fans for the unit. The power supply
fans are not controlled.
Signed-off-by: Evan Jobling <evan@jobling.au>
Link: https://github.com/openwrt/openwrt/pull/17699
Signed-off-by: Sander Vanheule <sander@svanheule.net>
(cherry picked from commit cbd1acbad3448280a180640e2a1a37a7144e1fb3)
The old RTL8231 driver integrated the MDIO bus access with the GPIO
control ops, making this driver not very portable to newer platforms.
It depended on the SoC ID instead of the compatible to determine the
MDIO access register, further complicating portability.
A new MFD driver is now available, which offers proper pin config as
well as optional LED support, which can work on any (bitbanged) MDIO
bus. Now that all devices have been migrated, we can drop the old code.
Signed-off-by: Sander Vanheule <sander@svanheule.net>
(cherry picked from commit b410f2216c7a4e6c5646f999d18b952b63c85817)
By switching to the new RTL8231 driver in commit b7af54d5c18c ("realtek:
Simple conversions to RTL8231 MFD driver"), the bootloader state of the
RTL8231's pins is now maintained. As the bootloader de-asserts the PoE
enable signal, this means PoE output is no longer available.
Add a gpio-hog with high output, restoring the line value from when the
pin was configured (by default) as an input with a pull-up resistor.
This will hard-enable the PoE output, but the individual ports can still
be administratively disabled by realtek-poe or a similar tool.
Signed-off-by: Sander Vanheule <sander@svanheule.net>
(cherry picked from commit 807074309dff4eff4097900b9de53abce8684e2f)
Update the common external GPIO DTSI file for the DGS-1210 devices to
use an MDIO device on the auxilairy MDIO bus, as the original driver was
doing behind the screen.
Switching to the new driver will allow for full pin-control and will no
longer reset pin config set by the bootloader.
Signed-off-by: Sander Vanheule <sander@svanheule.net>
(cherry picked from commit 3d6a1a7874c991c4bd9719bf0a92ab6630034c67)
The DTS file for the DGS-1210-10P is slightly different from the other
DGS-1210 devices, in that it didn't specify a gpio-restart node when it
was added. The gpio-restart has been found to work on the DGS-1210-10P
as well, so switch it over to the common definitions.
This converts the last device from the product family to the common
definition for the (external) GPIOs.
Tested-by: Michel Thill <jmthill@gmail.com>
Signed-off-by: Sander Vanheule <sander@svanheule.net>
(cherry picked from commit 7c0d1c1eb10a7040af6478742dd053f40b24a467)
The 'indirect-access-id' property on gpio0 is a remnant from the
original GPIO driver. This property has not been relevant on the SoC's
embedded GPIO controller for a long time, so just drop it.
Signed-off-by: Sander Vanheule <sander@svanheule.net>
(cherry picked from commit 022b7d80bf9de326f02c625f2fdeb2fb9c9203a3)
Change devices with RTL8231 GPIO expander definition that can easily be
translated to the new RTL8231 binding and carry over any gpio-hogs. This
will let them use the new RTL8231 MFD driver, without any functional
changes.
Signed-off-by: Sander Vanheule <sander@svanheule.net>
(cherry picked from commit b7af54d5c18cf74b9b598b506a335443a0bbed87)
Zyxel GS1900-8 v2 devices have been produced more recently than v1
devices. As there are v1 boards with RTL8380M rev. C SoCs, it can likely
safely be assumed that all v2 devices will also have a recent SoC
revision, supporting the hardware auxiliary MDIO controller.
Make the GS1900-8 v1 use an emulated auxiliary MDIO bus, for backward
compatibility with devices containing an RTL8380M rev. A.
Since the devicetrees are otherwise identical, GS1900-8 v1 devices with
an RTL8380M rev. B or C will also be able to use the (more efficient) v2
image. This includes any currently functioning device with OpenWrt, so
include the old compatible as a supported device for the GS1900-8 v2.
Link: https://github.com/openwrt/openwrt/issues/9534
Signed-off-by: Sander Vanheule <sander@svanheule.net>
(cherry picked from commit 7322d3266d84ec4062046254792d78ebca3ea26d)
The mdio-gpio driver is required to support early revision of RTL8380M
slicon (rev A) where the auxilairy MDIO controller does not function
correctly. Add this driver to the rtl838x kernel so devices with old
SoCs are also able to function correctly.
Signed-off-by: Sander Vanheule <sander@svanheule.net>
(cherry picked from commit efffcfa43693b68028a4aed4dea151b82158cc52)
In order to be able to define the external GPIO controller on an
emulated MDIO bus, move the controller definition outside of the main
GS1900 include for RTL838x-based devices.
Additionally, a new DTSI is provided defining the RTL8231 on the
emulated MDIO bus.
Signed-off-by: Sander Vanheule <sander@svanheule.net>
(cherry picked from commit a6a77896f4cddd6e69bcf86d5a6dc190fa82d53d)
Some RTL8380M-based devices have been around for a long time and use an
early A revision of the RTL8380M SoC. This revision has an issue with
the auxiliary MDIO controller, causing it to malfunction. This may lead
to device reboots when the controller is used.
Provide a bit-banged MDIO bus, which muxes the auxiliary MDIO pins to
their GPIO function. Although this will result in lower performance,
there should otherwise be no functional differences.
Link: https://github.com/openwrt/openwrt/issues/9534
Signed-off-by: Sander Vanheule <sander@svanheule.net>
(cherry picked from commit d4bf16a9e1618347709b0dccae71c273e6291a61)
As the bootloader is reconfiguring the RTL8231 on these devices anyway,
no pin state can be maintained over warm reboots. This results in for
example the PoE disable pin always being asserted by the bootloader.
Define the GPIO line linked to the RTL8231's reset so the MDIO subsystem
will also reset the expander on boot and ensure the line in the correct
state.
Signed-off-by: Sander Vanheule <sander@svanheule.net>
(cherry picked from commit b2d17dbb68c232393739e6fb48245f1f4bebb698)
Switch the Zyxel GS1900-48 over to the new MDIO-based driver for the
RTL8231 GPIO expander.
Signed-off-by: Sander Vanheule <sander@svanheule.net>
(cherry picked from commit 45aafe67f385a2b6cf65894b2f46ee8e33d87f92)
Enable the RTL8231 MFD core driver, as well as the pinctrl/gpio driver
to allow RTL839x devices to use it.
Signed-off-by: Sander Vanheule <sander@svanheule.net>
(cherry picked from commit fd5797b7ce6856539ec0f88b25a766fc2ce00c19)
Enable the driver for the Realtek Otto auxiliary MDIO driver so RTL839x
devices can use it. The related node is added to the base devicetree for
rtl839x-based devices, so they can enabled and use it when required.
Signed-off-by: Sander Vanheule <sander@svanheule.net>
(cherry picked from commit cddcc69ddf9c6284d6c9a6399c4ea48d7a044719)
For RTL839x, the driver was producing frequent timeouts on bus accesses.
Increasing the timeout to the one from a recent Realtek SDK resolves
these timeouts. To minimize overhead on different SoCs, each controller
can specify their own timeout.
This also add support for the register format as used on RTL93xx.
Support is added for the RTL930x "ext gpio" controller.
Signed-off-by: Sander Vanheule <sander@svanheule.net>
(cherry picked from commit 52ffef647152578ba89d2e4c1f9f2f869a3fc8a8)
regmap_read_poll_timeout() relies on usleep_range() to time the polling
loop. With the current, rather large, scheduling interval, a short
usleep_range() may take a lot longer than expected, causing performance
issues.
Switch the driver over to using regmap_read_poll_timeout_atomic(), which
uses udelay() to time the polling loop.
For comparision, the 'ethtool -m <dev>' command is about 10 times faster
with the atomic variant.
Using 'perf -r10 ethtool -m lan25':
- Driver using regmap_read_poll_timeout():
2.0117 +- 0.0118 seconds time elapsed ( +- 0.58% )
- Driver using regmap_read_poll_timeout_atomic():
0.1674 +- 0.0250 seconds time elapsed ( +- 14.95% )
Signed-off-by: Sander Vanheule <sander@svanheule.net>
(cherry picked from commit 693c1ea81a314cfa37a60a293568d2e46282b717)
Apply the equivalent of commit f64541db020e ("realtek: HPE 1920 8G PoE+
180W move fans to hwmon") to the 24-ports variants of the HPE 1920 PoE+
switches, with model numbers JG925A and JG926A.
Copy from the original commit message:
Move to using hwmon and gpio-fan. This is by adding gpio_fan_array to
DTS and kmod-hwmon-gpiofan to DEVICE_PACKAGES.
In combination with the new rtl8231 gpio driver the default fan
behaviour will be maximum fan speed.
Bump compat value to 1.1 due to existing config in /etc/config/system
via gpio_switch. Also notify in device compat that fan is now going to
be at bootloader setting (maximum in this case) by default unless turned
down.
As the init script 03_gpio_switches does not perform any action after
removing these devices from it, the file can be dropped.
Link: https://github.com/openwrt/openwrt/pull/17598
Signed-off-by: Fabian Groffen <grobian@gentoo.org>
Signed-off-by: Sander Vanheule <sander@svanheule.net>
(cherry picked from commit 0a7c8ed9d94930ba062c71df79f63c06eeab4543)
Update the base DTS file for the 16 and 24 port HPE 1920 devices
(JG923A, JG924A, JG925A, JG926A), causing the new RTL8231 MFD driver to
be loaded at start-up.
Signed-off-by: Sander Vanheule <sander@svanheule.net>
(cherry picked from commit 96850585e52dfff2c25d8b20b0b5cd192981ed4d)
The GPIO numbering has changed and is not stable. As a result fan
control via gpio_switch is broken, resulting in errors:
"export_store: invalid GPIO 456"
Move to using hwmon and gpio-fan. This is by adding gpio_fan_array to
DTS and kmod-hwmon-gpiofan to DEVICE_PACKAGES.
In combination with the new rtl8231 gpio driver the default fan
behaviour will be maximum fan speed.
Bump compat value to 1.1 due to existing config in /etc/config/system
via gpio_switch. Also notify in device compat that fan is now going to
be at bootloader setting (maximum in this case) by default unless turned
down.
Signed-off-by: Evan Jobling <evan@jobling.au>
Link: https://github.com/openwrt/openwrt/pull/17605
Signed-off-by: Sander Vanheule <sander@svanheule.net>
(cherry picked from commit f64541db020ef5689186609e8b7b7a3bb9755160)
Update the base DTS file for the 8 port HPE 1920 devices (JG920A,
JG921A, JG922A), causing the new RTL8231 MFD driver to be loaded at
start-up.
Signed-off-by: Sander Vanheule <sander@svanheule.net>
(cherry picked from commit e5d1a501cbd0fdda47d9169e9f669c7fb4813f2a)
