Debian changelog:
* Update Mozilla certificate authority bundle to version 2.82
The following certificate authorities were added (+):
+ TrustAsia TLS ECC Root CA
+ TrustAsia TLS RSA Root CA
+ SwissSign RSA TLS Root CA 2022 - 1
+ OISTE Server Root ECC G1
+ OISTE Server Root RSA G1
The following certificate authorities were removed (-):
- GlobalSign Root CA
- Entrust.net Premium 2048 Secure Server CA
- Baltimore CyberTrust Root (closes: #1121936)
- Comodo AAA Services root
- XRamp Global CA Root
- Go Daddy Class 2 CA
- Starfield Class 2 CA
- CommScope Public Trust ECC Root-01
- CommScope Public Trust ECC Root-02
- CommScope Public Trust RSA Root-01
- CommScope Public Trust RSA Root-02
* Use dh_usrlocal to create /usr/local/share/ca-certificates
(closes: #1127100)
Signed-off-by: Fengyu Wu <saldry@proton.me>
Link: https://github.com/openwrt/openwrt/pull/23155
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
The rtldsa_port_xstp_state_set() function offers a generic interface
to its callers to set the bridge state of one port. While it calls
device specific helpers in the background it runs the data mapping
for each architecture with a family_id check on its own. So the
hardware abstraction is done in two places
- rtldsa_port_xstp_state_set() translates one half
- its helper translate the other half
Convert the signature of the device specific helpers so that this
function does not need to know any hardware details. Instead move
the table/offset/bit calculations into the helpers. This way the
code path uses a consistent hardware abstraction.
- rtldsa_port_xstp_state_set() calls the helpers
- helpers do the hardware translation
Signed-off-by: Markus Stockhausen <markus.stockhausen@gmx.de>
Link: https://github.com/openwrt/openwrt/pull/23080
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
Add support to signing each package's .apk file into SDK.
This adds into SDK the feature added by f20794a to the normal builds.
Currently SDK does not sign the compiled packages, causing untrusted
package errors at package installation. The reason is the logic of
defaulting to 'n' in BUILDBOT and 'y' elsewhere. As downloadable SDKs
are compiled by the buildbot, the option gets 'n' set as the default.
And the option is not among the few build options exposed in the SDK
menuconfig, so the user can't easily change it.
Enable the feature by default:
* Exclude the SIGN_EACH_PACKAGE option from sdk/convert-config.pl
* Default to 'y' and expose the option in the SDK config menu.
(Avoiding untrusted errors naturally requires the user to copy the
public key into the router, quite similar as with full builds.)
Signed-off-by: Hannu Nyman <hannu.nyman@iki.fi>
Link: https://github.com/openwrt/openwrt/pull/23104
Signed-off-by: Robert Marko <robert.marko@sartura.hr>
Currently, moving from a port on one LAN8814 PHY package to another results
in a no traffic flowing on that new port.
It was tracked down to upstream change that fixed the issue that QSGMII
was soft reset on .config_init of each of 4 PHY-s in the package resulting
in a temporary traffic loss until QSGMII resynced.
However, it seems that the QSGMII soft reset timing is crucial and doing
the reset during probe only cause the QSGMII link to become partially
unsynced (Like 2 or 3 lanes are not synced).
So, add an upstream pending patch[1] to fix this, patch was modified as we
dont have the inband caps currently.
[1] https://patchwork.kernel.org/project/netdevbpf/patch/20260428134138.1741253-1-robert.marko@sartura.hr/
Signed-off-by: Robert Marko <robert.marko@sartura.hr>
The dropbear init script uses pidof, but BusyBox may be built
without it. Add a Kconfig dependency on BUSYBOX_CONFIG_PIDOF
to ensure the applet is available at runtime.
Signed-off-by: Ivan Romanov <drizt72@zoho.eu>
Link: https://github.com/openwrt/openwrt/pull/23128
Signed-off-by: Robert Marko <robimarko@gmail.com>
The Kconfig symbol help text prompts:
Disable this to get a possibly more secure configuration, but that
might not be backward compatible with previous kernels.
If backward compatibility is not an issue, then it is safe and
recommended to say N here.
For OpenWrt, when updating firmware, we always update the kernel and
recreate the overlay partition. Therefore, compatibility is not a
problem.
Signed-off-by: Shiji Yang <yangshiji66@outlook.com>
Link: https://github.com/openwrt/openwrt/pull/23126
Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
For some reason, /etc/config/dropbear is enumerated as a
conffile for dropbear packaging, but /etc/dropbear/ is
part of base-files packaging. If you're an openssh-server
user, then you don't have this directory on your router in
any case.
Signed-off-by: Philip Prindeville <philipp@redfish-solutions.com>
Link: https://github.com/openwrt/openwrt/pull/23041
Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
Airoha reported some bug in the TX/RX descriptor handling and PPE. Backport
the fix for such bug merged in net staging tree.
It's expected that these patch will be dropped in future minor kernel
version when submitted to stable staging tree.
All affected patch automatically refreshed.
Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
The nRESET pins of the RTL8224 PHY on the MCX3 are wired to GPIO6 of the
SoC, but this was never described in the devicetree.
Commit c99a30668d ("realtek: add RTL8224 initialization to Realtek
driver") introduced support for reinitializing RTL8224 PHYs, and commit
084da38a2e ("realtek: mdio: activate multiple busses") allowed the MDIO
bus provider load the devicetree properties to the bus, including reset
descriptors. With both in place, a bus level PHY reset via the hardware pin
is now correctly triggered before reinitialization.
Add the missing reset-gpios property so the PHY can be reset via the
hardware pin.
Signed-off-by: Sven Eckelmann <sven@narfation.org>
Link: https://github.com/openwrt/openwrt/pull/22966
Signed-off-by: Robert Marko <robimarko@gmail.com>
FIPS 140-3 recommends that all crypto implementations should be tested
before first use. Testmanager performs initial tests based on existing
test vectors. Not all algorithms have defined test vectors, so to improve
this situation, this commit backports recently added test vectors for
some cipher suites.
These vectors were calculated using a software implementation and then
double-checked on Mediatek MT7981 (safexcel) and NXP P2020 (talitos).
Both platforms passed self-tests.
Signed-off-by: Aleksander Jan Bajkowski <olek2@wp.pl>
Link: https://github.com/openwrt/openwrt/pull/23012
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
Use regmap_assign_bits() where it improves readability. With this
there is no need to calculate masks and values in separate lines.
Splitting the single update_bits() in rtmdio_931x_setup_polling()
into two separate assign_bits() is uncritical.
Signed-off-by: Markus Stockhausen <markus.stockhausen@gmx.de>
Link: https://github.com/openwrt/openwrt/pull/23099
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
Add the registers, family id and cpu port defines to the mach header.
Since RTL96xx SoCs has additional "subtype" info, add the respective
property to soc_info struct to be used in prom file.
The same way as rtl838x, the chip_info register requires 0xa to be
written. Similarly, 0xb must be written to get the subtype info.
There doesn't seem any check for testchip in RTL96xx so, we ignore it.
Add subtype information to set_system_type function if it is present
using the added subtype variable.
There are some RTL9607 chips out there with 512MB so add the check
for RTL9607 in the prepare_highmem. The registers are the same as
in RTL9300 so nothing else need to be changed.
Signed-off-by: Rustam Adilov <adilov@tutamail.com>
Link: https://github.com/openwrt/openwrt/pull/23023
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
Add patches to improve support for using 3rd-party DSA switches
like MaxLinear MxL862xx with MediaTek's mtk_eth_soc being the
conduit. This involves reorganizing hardware queues to avoid
overlap (currently dp->index is used -- if there is more than one
DSA switch this is problematic), and correctly programming flows
of the non-MTK DSA users ports in the PPE offloading engine.
Signed-off-by: Daniel Golle <daniel@makrotopia.org>
Fix dependency for kmod-drm-client-lib module:
error: recursive dependency detected!
symbol LINUX_6_18 is selected by PACKAGE_kmod-drm-client-lib
symbol PACKAGE_kmod-drm-client-lib is selected by LINUX_6_18
Fixes: e75ba35ed8 ("modules: video: introduce DRM client setup module")
Signed-off-by: Paweł Owoc <frut3k7@gmail.com>
Link: https://github.com/openwrt/openwrt/pull/23124
Signed-off-by: Robert Marko <robimarko@gmail.com>
The USXGMII_10GDXGMII and USXGMII_10GQXGMII early-return was added
when the submode register was not yet programmed, making those modes
effectively unconfigurable. With the submode now wired up at probe
time and written from the set_mode path, the gating is no longer
needed.
Keep the XSGMII gate - RTL8218D/E bring-up through the proprietary
10G SGMII path is still unimplemented - and rewrite the surrounding
comment accordingly.
Signed-off-by: Jonas Jelonek <jelonek.jonas@gmail.com>
Link: https://github.com/openwrt/openwrt/pull/23120
Signed-off-by: Robert Marko <robimarko@gmail.com>
Complete the USXGMII submode table with the four values that were
missing so far:
0x01 10GDX (2 x 5G)
0x03 5GSX (1 x 5G)
0x04 5GDX (2 x 2.5G)
0x05 2_5GSX (1 x 2.5G)
Together with the existing 10GSX (0x00) and 10GQX (0x02) this covers
all six USXGMII modes the driver declares. Add a corresponding mapping
to the hw_mode table too to cover them properly there.
Replace the switch in rtpcs_93xx_sds_apply_usxgmii_submode() with a
sparse lookup table indexed by hw_mode, using -1 as the sentinel for
modes without a submode value. Non-USXGMII modes silently no-op as
before; a USXGMII mode hitting a SerDes without an allocated submode
register now returns -EOPNOTSUPP, catching configuration mismatches
that would previously have been silently dropped.
Signed-off-by: Jonas Jelonek <jelonek.jonas@gmail.com>
Link: https://github.com/openwrt/openwrt/pull/23120
Signed-off-by: Robert Marko <robimarko@gmail.com>
USXGMII submode (10GSX vs 10GQX) is selected through a dedicated
register at 0x13e8, independent of the MAC and IP mode registers.
Without programming it, USXGMII-QX ports initialise as single-lane
SX and fail to link up correctly; MAC and IP mode alone are
insufficient for a working USXGMII setup.
The register packs 12 x 5-bit entries for SerDes 2..13, six per
32-bit word, non-straddling (bits 0..29 used, 30..31 padded). This
matches the available register dumps and the SDK's
reg_array_field_write() non-CROSS_REGISTERS path, which derives the
bit position as ((index - larray) % (32 / width)) * width and
accesses only a single 32-bit word. The submode values are identical
to RTL930x, so the shared RTPCS_93XX_SDS_USXGMII_SUBMODE_* defines
are reused.
Allocate the regmap_field at probe time with coordinates computed
from the SerDes ID; the regular packing needs no lookup table. Call
rtpcs_93xx_sds_apply_usxgmii_submode() from the set_mode dispatcher
after set_ip_mode - the helper's null-guard and mode filter leave
non-USXGMII paths unchanged.
Signed-off-by: Jonas Jelonek <jelonek.jonas@gmail.com>
Link: https://github.com/openwrt/openwrt/pull/23120
Signed-off-by: Robert Marko <robimarko@gmail.com>
This patch backports a small but important part of the upstream commit:
b3f1b9e2aa07 build: Remove INCLUDE_MEMORY [PR117737]
Its original commit message fails to mention that the commit also moves
the `#include <memory>` to an earlier position within system.h,
which is the actual change that we're after in this patch.
Building our GCC 14.3 with host GCC 16, the inclusion order starts to matter,
which is an issue that was also touched upon by the upstream commits:
9970b576b7e4 Include safe-ctype.h after C++ standard headers, to avoid over-poisoning
f6e00226a4ca build: Move sstream include above safe-ctype.h {PR117771]
Signed-off-by: Lars Gierth <larsg@systemli.org>
Link: https://github.com/openwrt/openwrt/pull/23095
Signed-off-by: Robert Marko <robimarko@gmail.com>
PHY drivers might need access to NVMEM or the filesystem to load
calibration/initialization data. The driver will then return -EPROBE_DEFER
to signal to the device core that the probe should be retried multiple
times again in the 10s driver_deferred_probe_timeout.
But when the switch driver calls dsa_register_switch(), it needs to connect
the PHYs directly. As result, all PHYs without an driver will automatically
get the default driver (either `genphy_c45_driver` or `genphy_driver`)
assigned and initialized. But for PHYs with the additional initialization
data from NVMEM/fs, this will usually result in not working PHYs.
Since there are Realtek based boards with RTL826x PHYs and the new driver
loads the initialization/patch values from rootfs, it is necessary to check
in the beginning of the probe function whether the PHYs are ready and the
probing can continue.
If some driver is still without driver after the deferred probe period
ended, the loading will just continue and the generic PHY drivers will
still be used.
Closes: #22811
Co-authored-by: Jonas Jelonek <jelonek.jonas@gmail.com>
Co-authored-by: Markus Stockhausen <markus.stockhausen@gmx.de>
Signed-off-by: Sven Eckelmann <sven@narfation.org>
Link: https://github.com/openwrt/openwrt/pull/23075
Signed-off-by: Robert Marko <robimarko@gmail.com>
RTL930x and RTL931x share a set of extras around MAC mode writes:
- a post-write delay (kept for consistency with the original RTL930x
behaviour; harmless on RTL931x)
- the force-mode bit (RTL931x only, nullable field)
Add rtpcs_93xx_sds_set_mac_mode() as a shared wrapper around the
generic rtpcs_sds_set_mac_mode() that applies each of these extras
unconditionally; the nullable field makes the force-bit write a no-op
on RTL930x.
Route the three RTL93xx call sites (the 930x and 931x set_mode
dispatchers, and 931x set_ip_mode's OFF transition) through the
wrapper, removing the duplicated force-bit handling from each.
The USXGMII submode write stays out of the wrapper and is called
explicitly from the 930x dispatcher via rtpcs_93xx_sds_apply_usxgmii_submode().
Keeping submode as a separate step leaves room for RTL931x to apply it
from its IP-mode path once the submode register is wired up, without
retrofitting a MAC-mode wrapper with side effects.
Signed-off-by: Jonas Jelonek <jelonek.jonas@gmail.com>
Link: https://github.com/openwrt/openwrt/pull/23040
Signed-off-by: Robert Marko <robimarko@gmail.com>
RTL931x uses a regular 8-bit-per-SerDes layout in SERDES_MODE_CTRL, so
the reg_field can be computed in the probe hook with simple arithmetic.
The 8-bit-per-SerDes field is split into a 7-bit mac_mode (bits 0..6)
and a 1-bit mac_mode_force (bit 7), each written independently via its
own regmap_field. The mac_mode is widened to 7 bits (rather than the
5 bits strictly needed for the mode value) so MAC mode writes also
clear bit 5 (FEC enable) and bit 6 (10G speedup), matching the original
behaviour where the full 8-bit mask cleared these bits on every mode
change. FEC and speedup are mode-dependent and not yet programmed by
the driver; keeping them cleared leaves headroom for future support
without changing the effective register value.
rtpcs_931x_sds_reset() is updated to save and restore both fields
across the off/on cycle, preserving the original force-bit handling.
rtpcs_931x_sds_set_mode() uses the generic rtpcs_sds_set_mac_mode() and
sets the force bit explicitly; the same sequence also appears in
rtpcs_931x_sds_set_ip_mode()'s OFF transition. Both are folded into
the shared RTL93xx wrapper in a later commit.
Signed-off-by: Jonas Jelonek <jelonek.jonas@gmail.com>
Link: https://github.com/openwrt/openwrt/pull/23040
Signed-off-by: Robert Marko <robimarko@gmail.com>
RTL930x packs 5-bit mode fields across four registers at irregular
positions. Express this as a static reg_field table indexed by SerDes
ID; the probe hook allocates the corresponding regmap_field. The
USXGMII submode register follows the same pattern with its own
reg_field table, allocated only for 10G-capable SerDes (id 2..9).
The generic rtpcs_sds_set_mac_mode() replaces the old
__rtpcs_930x_sds_set_mac_mode() helper. The previous behaviour of
writing OFF before the target mode is intentionally dropped — it was
RTL930x-specific and not required by the hardware.
The variant-level rtpcs_930x_sds_set_mode() is kept as a pure dispatch
between the IP mode path (set_ip_mode) and the MAC mode path. The
USXGMII submode write is factored into rtpcs_93xx_sds_apply_usxgmii_submode(),
which derives the submode value from hw_mode and no-ops on SerDes
without the submode register.
The __rtpcs_930x_sds_get_mac_mode() and __rtpcs_930x_sds_get_usxgmii_submode()
helpers are dropped. They were __always_unused and depended on the
removed parallel arrays. A future get_mode path will be added if a
caller needs it, likely mirroring the setter's wrapper shape.
Signed-off-by: Jonas Jelonek <jelonek.jonas@gmail.com>
Link: https://github.com/openwrt/openwrt/pull/23040
Signed-off-by: Robert Marko <robimarko@gmail.com>
RTL839x packs the SerDes MAC mode in MAC_SERDES_IF_CTRL with a regular
per-SerDes layout, so the regmap_field can be computed directly in the
probe hook rather than declared as a static table.
Mode values (currently only OFF and QSGMII) move into a static
rtpcs_839x_sds_hw_mode_vals[] table. Values for 100BASEX, 1000BASEX
and SGMII from the vendor SDK are kept as comments for future
reference — they are not yet exercised here.
With no variant-specific extras (no force bit, no companion register,
no submode), rtpcs_839x_sds_set_mode() is removed; setup_serdes calls
the generic rtpcs_sds_set_mac_mode() directly.
Signed-off-by: Jonas Jelonek <jelonek.jonas@gmail.com>
Link: https://github.com/openwrt/openwrt/pull/23040
Signed-off-by: Robert Marko <robimarko@gmail.com>
Replace rtpcs_838x_sds_set_mode()'s inline shift/mask arithmetic with
a regmap_field computed and allocated at probe time. The field layout
is regular (5-bit per SerDes, reverse-packed in SDS_MODE_SEL), so the
position can be derived arithmetically from the SerDes ID rather than
declared in a table.
The function keeps its wrapper role because SerDes 4 and 5 have a
second companion register (INT_MODE_CTRL) with its own per-mode value
encoding. Since RTL838x is the only variant with this quirk and the
register is written from only one call site, it is kept inline rather
than abstracted into its own config table.
Signed-off-by: Jonas Jelonek <jelonek.jonas@gmail.com>
Link: https://github.com/openwrt/openwrt/pull/23040
Signed-off-by: Robert Marko <robimarko@gmail.com>
All four Realtek PCS variants (RTL838x, RTL839x, RTL930x, RTL931x)
configure the SerDes MAC mode by writing a register field whose layout
varies per variant — different base registers, different bit positions,
and in some cases per-SerDes packing that isn't arithmetically regular.
Add the common infrastructure to express this uniformly:
- per-SerDes regmap_field pointers in a new 'swcore_regs' anonymous
struct on rtpcs_serdes: mac_mode, mac_mode_force (931x only, nullable)
and usxgmii_submode (930x only, nullable).
- a per-variant mode-value table pointer (sds_hw_mode_vals) on
rtpcs_config, keyed by enum rtpcs_sds_mode. Values are s16 with -1 as
the "unsupported" sentinel — u8 with 0 would collide with RTL839x's
OFF value (0x0).
- a generic rtpcs_sds_set_mac_mode() that looks up the value for the
requested mode and writes it via the regmap_field.
Variant-specific extras (post-write delay, force bit, companion register
writes, USXGMII submode handling) will be added in per-variant wrappers
in the following commits.
Signed-off-by: Jonas Jelonek <jelonek.jonas@gmail.com>
Link: https://github.com/openwrt/openwrt/pull/23040
Signed-off-by: Robert Marko <robimarko@gmail.com>
John Audia
Fil Dunsky
Fengyu Wu
Markus Stockhausen
Hannu Nyman
Robert Marko
Ivan Romanov
Christoph Krapp
Rosen Penev
Shiji Yang
Philip Prindeville
Christian Marangi
Zoltan HERPAI
Sven Eckelmann
Mieczyslaw Nalewaj
Carsten Schuette
Daniel Golle
Aleksander Jan Bajkowski
Rustam Adilov
Jonas Jelonek
Paweł Owoc
Alexandru Ardelean
Lars Gierth
Pawel Dembicki