Backport v7.3 phylink patches to the generic target required for the
latest fwnode phylink PCS patches which support multiple (sub-)targets,
including MTK and qualcommax.
This update includes better PCS release logic, switch to full notifier
add/release PCS handling, devres managed PCS provider variant and
general code improvements.
In addition, update every user to the latest fwnode phylink PCS API.
In the latest API, fwnode_pcs_add_provider() returns a pointer to
the provider or the error code instead of the previous plain return
value. As such, update error handling and add a descriptive error
message upon failure. Also the provider remove logic changed and with
the support of devres API, switch every user to devm_ variant.
Signed-off-by: George Moussalem <george.moussalem@outlook.com>
[ improve commit description, refresh patch, update any driver to new API]
Co-Developed-by: Christian Marangi <ansuelsmth@gmail.com>
Link: https://github.com/openwrt/openwrt/pull/24973
Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
CONFIG_RUSTC_HAS_SUSPICIOUS_RUNTIME_SYMBOL_DEFINITIONS is autodetected
based on rustc version, so filter it out of target configs.
Signed-off-by: Robert Marko <robimarko@gmail.com>
RouterBOOT can be told to look for a netboot server for a few seconds
before falling through to the configured boot device, optionally
restricted to a single Netinstall server. RouterOS calls these
preboot-etherboot and preboot-etherboot-server. Neither was modelled
here, so on a board running Linux rather than RouterOS they could not be
read or changed at all.
That matters most on a board where Linux has replaced RouterOS: without
these, the only way to arrange a netboot is boot_device=ethonce, which
is one-shot and must be rewritten before every attempt. preboot-etherboot
is persistent, needs no write per boot, and still falls through to the
boot device when no server answers.
Add both:
preboot_etherboot tag 0x24, 0..30 seconds, zero disabling the wait
preboot_etherboot_server tag 0x25, an IPv4 address, 0.0.0.0 for any
RouterBOOT has no interactive presentation of either setting to mimic:
neither appears in its setup menu, and both can only be written from
RouterOS. Rather than borrow the "disabled" and "any" keywords RouterOS
uses for zero, present both tags as they are stored. RouterOS rejects a
timeout of 31, which is where the upper bound comes from.
Note the server address is stored in network byte order, unlike every
other tag in this record, which is a little-endian u32. 192.168.1.142 is
held as c0 a8 01 8e, so reading it as a u32 would yield 142.1.168.192 -
a valid-looking address pointing at a different host.
Verified on a MikroTik E50UG (hEX refresh):
- the show path decodes a server address written by RouterOS 7.24.2
- a write of 10.20.30.40 lands in flash as 0a 14 1e 28
- out-of-range timeouts and malformed addresses are rejected
- with preboot_etherboot set to 5 from Linux and boot_device left at
flasheth, RouterBOOT netboots; set back to zero, it boots from NAND
Both tag numbers were confirmed by diffing the soft_config record before
and after changing each setting from RouterOS. They have not been
cross-checked against other MikroTik hardware.
Signed-off-by: Matt Eaton <git@divinehawk.com>
Link: https://github.com/openwrt/openwrt/pull/25044
Signed-off-by: Robert Marko <robimarko@gmail.com>
phylink_get_inband_type() omits PHY_INTERFACE_MODE_PSGMII, so
phylink_pcs_neg_mode() returns early with PHYLINK_PCS_NEG_NONE for a
PSGMII port, and the in-band capabilities a PCS advertises are never
consulted: qca-uniphy answers pcs_inband_caps() with
LINK_INBAND_DISABLE | LINK_INBAND_ENABLE for every interface it drives,
PSGMII included.
Backport upstream commit 5ba017f9efef ("net: phylink: treat PSGMII as an
inband capable interface"), which classifies PSGMII as INBAND_CISCO_SGMII
beside SGMII and QSGMII and extends the generic clause 22 PCS helpers to
match, to both kernel copies the tree carries.
No board in the tree declares managed = "in-band-status" on a PSGMII
port, so every PSGMII port moves from PHYLINK_PCS_NEG_NONE to
PHYLINK_PCS_NEG_OUTBAND, PHY-managed and fixed links alike. A PCS
driver can distinguish the two with phylink_expects_phy() and force
its channel only on a fixed link.
The 6.12 copy adapts the phylink_mii_c22_pcs_decode_state() hunk, whose
SGMII case carries no neg_mode guard on that kernel.
Exercised on a Xiaomi AX3600 (IPQ8074, kernel 6.18), whose four ports are
PSGMII channels of one UNIPHY. With two of them declared as fixed links,
the channel force bit the qca-uniphy PCS drives reads 0 without this
patch and 1 with it, the channel speed field following the declared
speed, while the two channels still behind a PHY are untouched either
way. On the unmodified device tree nothing changes: every port links as
before and every channel register reads the value it held.
Assisted-by: Claude:claude-opus-5
Signed-off-by: Julius Bairaktaris <julius@bairaktaris.de>
Link: https://github.com/openwrt/openwrt/pull/24791
Signed-off-by: Robert Marko <robimarko@gmail.com>
A PCS taken from the phylink PCS list is attached to its phylink instance
in phylink_start(), after phylink_mac_initial_config() has already run
.pcs_config() on it, so that first call sees a NULL pcs->phylink. The
.mac_select_pcs() route has no such window: phylink_major_config() sets
pcs->phylink before it configures the PCS, which is what phylink did for
every PCS before the list existed.
DSA has no .mac_select_pcs, so every DSA port whose PCS comes from a
pcs-handle takes the list route. pcs-qca-uniphy reads the back-reference
in .pcs_config(), through phylink_expects_phy(), to tell a fixed link
from a PHY that simply does not negotiate in band, and a Zyxel NBG7815
panics on the wan port as netifd brings it up:
qca-ppe 3a000000.ppe wan: configuring for phy/2500base-x link mode
Unable to handle kernel access to user memory outside uaccess routines
at virtual address 0000000000000044
pc : phylink_expects_phy+0x0/0x38
lr : qca_uniphy_pcs_config_mode.isra.0+0x398/0x45c
Call trace:
phylink_expects_phy+0x0/0x38 (P)
qca_uniphy_pcs_config+0xec/0x13c
phylink_major_config+0x1e8/0x670
phylink_mac_initial_config+0xb8/0x14c
phylink_start+0x4c/0x280
dsa_port_enable_rt+0x48/0xb0
Its four psgmii ports come up first because psgmii has no in-band type at
all, which short-circuits the read, and its 10g port is managed in band.
Link the list where pl->pcs_state has just become PCS_STATE_STARTING, so
the guarantee holds on both routes. A .pcs_change() from a PCS that is
now linked earlier still resolves to nothing: phylink_run_resolve() does
nothing while phylink_disable_state holds PHYLINK_DISABLE_STOPPED, which
only the phylink_enable_and_run_resolve() below clears. The other two
phylink_mac_initial_config() callers are unaffected, both running with
the list already linked - phylink_resume() only takes that path when it
did not stop, and phylink_sfp_set_config() is gated on not being stopped.
The move rides in a patch of its own rather than an edit to the imported
737-02/770-02, so the imported series stays as it was taken. Both kernels
carry that series and both get the patch. No 6.12 target consumes the PCS
list today - the only in-tree filler lives under a files-6.18 directory
and every target that would use one is on 6.18 - so nothing there is
broken by the window; the two copies just have to stay the same patch.
Runtime tested on a Xiaomi AX3600 (IPQ8074, QCA8075 PSGMII, kernel 6.18):
the first .pcs_config() on every channel finds pcs->phylink set, at boot
and again after an admin down and up, which unlinks the list in
phylink_stop() and relinks it on the next start. The panic itself is not
reachable there, since psgmii has no in-band type and the resulting
PHYLINK_PCS_NEG_NONE short-circuits the read before it happens; that arm
runs on the NBG7815 in the report.
Fixes: 18cbd83a14 ("generic: 6.18: import updated standalone PCS handling")
Link: https://github.com/JuliusBairaktaris/openwrt-nss-edma/issues/23
Assisted-by: Claude:claude-opus-5
Signed-off-by: Julius Bairaktaris <julius@bairaktaris.de>
Link: https://github.com/openwrt/openwrt/pull/24791
Signed-off-by: Robert Marko <robimarko@gmail.com>
Currently, the LAN1 LED usually doesn't work on Nokia XG-040G-MD and
Nokia XG-040G-MF devices: it lights up right after boot but goes dark
again as soon as the link renegotiates. Both boards wire LAN1 to a
discrete Airoha EN8811H PHY, whose LED GPIO pins are only ever
configured as outputs once, in en8811h_probe(); every later call to
en8811h_config_init() restarts the PHY's MD32 MCU, which resets that
GPIO configuration back to inputs.
Backport the fix that moves the GPIO-as-output configuration into
en8811h_config_init() so it is reapplied on every MCU restart. This is
a fix to the generic Linux PHY driver (drivers/net/phy/air_en8811h.c),
not something specific to the airoha target: other targets ship the
same PHY via kmod-phy-airoha-en8811h (e.g. mediatek/filogic boards),
so it belongs in target/linux/generic/backport-6.18/ rather than under
target/linux/airoha/.
Merged upstream into net.git by Paolo Abeni as commit 03b4702fc5e3
("net: phy: air_en8811h: move LED GPIO configuration to config_init"),
expected in v7.3. The patch is functionally identical to that commit,
refreshed into OpenWrt's quilt form.
Suggested-by: Mikhail Zhilkin <csharper2005@gmail.com>
Signed-off-by: Vitaliy Sochnev <sochnev.v.74@gmail.com>
Link: https://github.com/openwrt/openwrt/pull/24853
Signed-off-by: Robert Marko <robimarko@gmail.com>
RTL8221B unfortunately suffers from a issue where reading registers from
MMD 30 can break the PHY. Once it is in the broken state, recovery is
only possible by hardware reset.
Add a hack which prevents the kernel from reading MMD 30 while probing
for PHYs when a RTL8221B is detected, based on the ID from MMD 1.
Fixes: https://github.com/openwrt/openwrt/issues/22140
Signed-off-by: Jan Hoffmann <jan@3e8.eu>
Link: https://github.com/openwrt/openwrt/pull/25017
Signed-off-by: Jonas Jelonek <jelonek.jonas@gmail.com>
The notifier patch attached phydev->psec under rtnl_lock() inside
phy_device_register(). Drivers that register their MDIO bus from
ndo_init() (like the lantiq etop) already hold rtnl at that point, so the
attach tried to take rtnl a second time and deadlocked on probe.
Aleksander hit this on lantiq arx100.
Rework 896-03 to use a dedicated mutex instead of rtnl for the psec
attach, the notifier walks and the ethtool PSE paths, so there is no rtnl
recursion any more.
The mutex lives in pse_core.c rather than in phylib: net/ethtool is always
built into vmlinux while PHYLIB is tristate, so net/ethtool/pse-pd.c must
not call a phylib export or CONFIG_PHYLIB=m fails to link. PSE_CONTROLLER
is bool, so pse_core is either in vmlinux or absent and every config can
reach pse_phy_lock()/pse_phy_unlock(); !PSE_CONTROLLER gets no-op stubs in
pse.h.
phy_device_register_locked() is gone with it. It only existed because the
attach took rtnl, and was identical to phy_device_register() apart from an
ASSERT_RTNL(), so sfp.c calls phy_device_register() again and
include/linux/phy.h stays untouched.
Also refresh 897-01 and 897-02, whose hunks shift.
Tested-by: Aleksander Jan Bajkowski <olek2@wp.pl>
Signed-off-by: Carlo Szelinsky <github@szelinsky.de>
Link: https://github.com/openwrt/openwrt/pull/24945
Signed-off-by: Jonas Jelonek <jelonek.jonas@gmail.com>
Provide two hooks in struct mii_bus
- notify_phy_attach(): called in phy_attach_direct() after PHY
hardware has been initialized and just before PHY is resumed.
- notify_phy_detach(): called in phy_detach() right after PHY
has been suspended.
Link: https://github.com/openwrt/openwrt/pull/25009
Signed-off-by: Markus Stockhausen <markus.stockhausen@gmx.de>
Refresh patches to fix CI builds. The refresh was missed with the former
change adding an additional backport patch.
Refreshed with 'make target/linux/refresh V=99'.
Fixes: 5322f1d79b ("generic: 6.18: mxl862xx enable assisted learning on CPU port")
Signed-off-by: Jonas Jelonek <jelonek.jonas@gmail.com>
The GPIO direction was configured via the gpiod flags passed to
devm_fwnode_gpiod_get_index(), i.e. at request time. Restore the prior
behavior of requesting the GPIO as-is (GPIOD_ASIS) and setting the
direction afterwards with gpiod_direction_output_raw() /
gpiod_direction_input().
Note this deliberately does not restore the old skip-and-continue error
handling: before 0ca7895 a failing request or direction setup was skipped
with continue, leaving that GPIO unexported while the rest of the board
still came up. Direction setup failures now abort the probe, consistent
with the request failure handling introduced by 0ca7895. gpiod flags are
also not used for the direction since legacy gpio_request_one() applied
the initial output value raw (ignoring active-low), which
gpiod_direction_output_raw() matches.
Fixes: 0ca7895173 ("kernel: use fwnode for GPIO export driver")
Signed-off-by: Rosen Penev <rosenp@gmail.com>
Link: https://github.com/openwrt/openwrt/pull/24832
Signed-off-by: Jonas Jelonek <jelonek.jonas@gmail.com>
The MxL862xx driver enables FDB isolation but does not enable assisted
learning on the CPU port. Consequently, MAC addresses learned through a
physical switch port are not updated in hardware when the corresponding
station moves to a foreign bridge port, such as a Wi-Fi interface.
The stale hardware FDB entry continues directing return traffic toward
the original physical port. Traffic entering that same port is then
filtered instead of being forwarded to the CPU and software bridge. This
causes downstream unicast traffic, including DHCP OFFER and ACK packets,
to disappear after a client roams to a local wireless interface. The
client eventually considers the connection unusable and disconnects.
Enable assisted CPU-port learning so DSA installs foreign bridge FDB
entries on the CPU port. This keeps the hardware FDB synchronized with
the software bridge and allows return traffic to reach locally attached
Wi-Fi clients after roaming.
Tested on a BPI R4 PRO with a MxL862xx switch and a BE14000 WiFi interface.
- Without patch, wired uplink on lan6 port (mxl path)
Wifi clients connect but roam away not getting DHCP offers
- Without patch, wired uplink on wan port (no mxl path)
Wifi clients connect and roam successfully
- With this patch, uplink on lan6 (mxl path)
Wifi clients connect and roam successfully
Fixes: 340bdf984613 ("net: dsa: mxl862xx: implement bridge offloading")
Signed-off-by: Edoardo Pinci <epinci@outlook.com>
Link: https://patch.msgid.link/DU0P251MB069949C6DEB4D1D51F31FE87C4A02@DU0P251MB0699.EURP251.PROD.OUTLOOK.COM
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Move the existing AS21xxx patch series from the Airoha target to the
generic 6.18 patch set so it is available to all targets.
Promoting the PHY detach patch to the generic patch set changes the patch
application order. Refresh the affected generic, Layerscape, and ramips
patches without functional changes.
Signed-off-by: Pietro Ameruoso <p.ameruoso@live.it>
Signed-off-by: Frank Wunderlich <frank-w@public-files.de>
The USXGMII block of the RTL8261N does not always settle by itself once
the media side link has been established. Where it does not, the link is
dropped again shortly afterwards while autonegotiation on the media side
keeps completing normally, so ethtool reports negotiated speed and duplex
while the link stays down and nothing is logged.
Add the work-around originally written by Bo-Cun Chen for the MediaTek
SDK, which applies it from mtk_mac_link_up() in the MT7988 ethernet
driver. As the quirk is a property of the PHY rather than of the SoC it
is carried in the Realtek driver instead, so that the PHY also behaves
when used on other hosts.
Rather than busy-waiting a flat second and then resetting the block
unconditionally as the SDK does, poll the SerDes link status through the
indirect register window and only pulse the reset while the link is
still down, from a delayed work so that the PHY state machine is never
blocked.
Hook it into both 10Gbps entries which share the base PHY ID. The parts
this was observed on carry an RTL8261BE package marking while binding to
the RTL8261N driver entry, the two being told apart solely by a vendor
version register, so covering only one of them would be fragile.
Signed-off-by: Daniel Golle <daniel@makrotopia.org>
The USB3 port event fix for single-roothub controllers was merged
upstream through the usb-7.3-rc1 pull as commit 3e91ec3e7d80.
Move the patch from pending to backport in both kernels and replace
the header with the upstream commit.
Signed-off-by: Semih Baskan <strst.gs@gmail.com>
Link: https://github.com/openwrt/openwrt/pull/24964
Signed-off-by: Robert Marko <robimarko@gmail.com>
Backport upstream rtl822x PHY LED support so the RTL8221B's LED pins
are exposed as /sys/class/leds with netdev triggers and the LED
speed-select register is programmed in-kernel, instead of needing a
userspace mdio write.
Cherry-picked from Linux v7.2 commit d3aae4d954f9 ("net: phy: realtek:
Add support for PHY LEDs on RTL8221B"). It applies to both supported
kernels - the phy_led framework and the RTL8211x 1G LED support it
builds on are already present in each - and wires the LED ops into the
RTL8221B VB-CG and VM-CG driver entries.
Refresh the realtek PHY patches whose hunk offsets this shifts:
generic/pending-6.12/720-*, generic/pending-6.18/720-*,
generic/pending-6.18/742-* and realtek/patches-6.18/. Those are
offset-only changes, no content is altered.
Needed by the Cudy WR3000P v1, whose front-panel WAN lamp is driven by
the RTL8221B LED1 pin (see the following commit).
Signed-off-by: Ivan Rainbolt <ivan@github.ivanthegeek.com>
Link: https://github.com/openwrt/openwrt/pull/24913
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
DSA discards the return value of of_get_mac_address(), so a user port
whose MAC address comes from an NVMEM provider that is not ready yet
silently inherits the MAC address of its conduit interface. Since
6.18.45 that happens on every boot for cells behind a fixed-layout.
Propagate the deferral instead. Not upstream yet.
Assisted-by: Claude:claude-opus-5
Link: https://github.com/openwrt/openwrt/pull/24924
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
Since 6.18.45 the nvmem fixed-layout parser is a driver on the
nvmem-layout bus, so of_get_ethdev_address() returns -EPROBE_DEFER until
it has bound. drivers/net/ is linked before drivers/nvmem/, so mvneta
hits this on every boot and falls back to a random MAC address.
Backport the fix from Linux 7.1.
Assisted-by: Claude:claude-opus-5
Link: https://github.com/openwrt/openwrt/pull/24924
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
Support for the SerDes ports has been merged upstream, firmware
update support has gained several robustness and recovery features.
Trapping of link-local traffic has also been improved and now allows
multicast snooping to work as expected.
Add more sophisticated ready-state assessment to avoid racing of the
driver with the firmware applying the initial default configuration.
Signed-off-by: Daniel Golle <daniel@makrotopia.org>
Backport a series of upstream patches for the adt7470 hwmon driver,
accepted for kernel v7.3. It exposes the fan control lines via the
generic PWM framework and thermal zone sensors.
Instead of relying on userland scripts, the kernel can now control
the fan speed directly through standard cooling maps and PWM fans
configured in the DTS. Currently in the tree, only edgecore_ecs4100-12ph
seems to use this chip.
Signed-off-by: Luiz Angelo Daros de Luca <luizluca@gmail.com>
Link: https://github.com/openwrt/openwrt/pull/24803
Signed-off-by: Jonas Jelonek <jelonek.jonas@gmail.com>
The FM25G01B/FM25G02B datasheets specify a single dummy byte for the
0xEB Quad I/O read-from-cache, but the generic read_cache_variants set
issues two. The extra dummy byte shifts the data phase and returns
corrupted data with no ECC error, breaking boot on NC-1812/KN-1812.
Use a dedicated read-from-cache variant set with ndummy=1 for 0xEB.
Both the FM25G{01,02}B support (d5a5c9eb2ee9) and this fix
(8211f2d74b35) were merged into the mtd tree (nand/next). Backport both
patches to backport-6.18 using the actual upstream commits, so they
apply to the OpenWrt kernel tree and upstream nand/next as is.
FM25G01B datasheet: https://www.fmsh.com/nvm/FM25G01B_ds_eng.pdf
FM25G02B datasheet: https://www.fmsh.com/nvm/FM25G02B_ds_eng.pdf
Signed-off-by: Aleksandr Mineev <sanderrrs@gmail.com>
Link: https://github.com/openwrt/openwrt/pull/24007
Signed-off-by: Jonas Jelonek <jelonek.jonas@gmail.com>
The HeYangTek HYF1GQ4UDACAE is a 1 Gbit (128 MiB) SLC SPI-NAND with
2048 + 64 byte pages and on-die 4-bit / 512-byte ECC (JEDEC ID 0xc9),
found among others on some Keenetic KN-3411 (Buddy 6) units.
The driver is accepted upstream and sits in the MTD tree heading for
Linux 7.3, so it goes to backport-6.18 as the upstream commit
a837468386 ("mtd: spinand: add support for HeYangTek HYF1GQ4UDACAE").
The Etron and Dosilicon spinand patches are refreshed because the
backport applies before them and touches the same spinand-objs line.
Other SPI-NAND patches in the MediaTek, Airoha, EcoNet and Qualcommax
targets are refreshed for the shifted core offsets.
Signed-off-by: Aleksei Sviridkin <f@lex.la>
Link: https://github.com/openwrt/openwrt/pull/23742
Signed-off-by: Jonas Jelonek <jelonek.jonas@gmail.com>
USB3 port events are dropped whenever the controller has only one roothub.
The check that guards them treats a missing shared hcd as proof the hcd was
removed, which stopped being true with upstream commit 4736ebd7fcaf ("usb:
host: xhci-plat: omit shared hcd if either root hub has no ports"). A
controller whose USB2 root hub has no ports gets a single roothub and never
has a shared one, so every SuperSpeed event is thrown away and nothing
enumerates even though the port reports the device:
0x006a1203 Powered Connected Enabled Link:U0 PortSpeed:4
Broadcom Northstar is such a controller. USB3 works there up to 5.15 and
stops from 5.19 onwards.
Tested on an Asus RT-N18U with kernel 6.18, seven SuperSpeed enumerations,
USB2 unaffected on both ports.
Link: https://github.com/openwrt/openwrt/issues/19592
Signed-off-by: Semih Baskan <strst.gs@gmail.com>
Link: https://github.com/openwrt/openwrt/pull/24547
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
Instead of putting in the target config where each refresh drops it,
lets disable it in the generic config.
Signed-off-by: Robert Marko <robert.marko@sartura.hr>
The Kconfig symbol backing the HiFiBerry Studio driver was renamed
from SND_BCM2708_SOC_HIFIBERRY_STUDIO_DAC8X to
SND_BCM2708_SOC_HIFIBERRY_STUDIO. Update to the new symbol name.
Also add the new CONFIG_TOUCHSCREEN_ST7123 symbol, disabled by
default, to the generic config.
Signed-off-by: Joshua Covington <joshuacov@gmail.com>
Link: https://github.com/openwrt/openwrt/pull/24275
Signed-off-by: Jonas Jelonek <jelonek.jonas@gmail.com>
The patch adds a pre-check to tcp_gro_receive() so that an skb which
cannot be pulled up to the GRO offset is flushed instead of reaching the
BUG() in __skb_pull(). Upstream has since fixed the same bug inside the
callee, which leaves the pre-check with nothing to protect:
commit f2bb3434544454099a5b6dec213567267b05d79d
("net: add pskb_may_pull() to skb_gro_receive_list()")
skb_gro_receive_list() now rejects the short skb itself and pulls with
skb_pull() rather than the __skb_pull() that carries the BUG(). It is
the only function the is_flist branch of tcp_gro_receive() calls, so no
path is left uncovered. The fix is present in both pinned kernels,
6.12.100 and 6.18.41.
Dropping the pre-check also restores upstream's intended handling: on
failure skb_gro_receive_list() sets NAPI_GRO_CB(skb)->flush, so the skb
is delivered through the normal receive path instead of being held as a
new GRO head. Short-circuiting on the local flush skipped that.
The patch keeps applying cleanly only because the fix landed in a
different function.
Assisted-by: Claude:claude-opus-5
Signed-off-by: Julius Bairaktaris <julius@bairaktaris.de>
Link: https://github.com/openwrt/openwrt/pull/24524
Signed-off-by: Jonas Jelonek <jelonek.jonas@gmail.com>
Backport four upstream commits that convert mutex_init() calls to
devm_mutex_init() in the Realtek DSA driver family. With
CONFIG_DEBUG_MUTEXES enabled, mutex_destroy() must be called before a
mutex is discarded; using the devm variant handles this cleanup
automatically and avoids leaking a warning on driver removal/failure.
Added patches (applied to both backport-6.12 and backport-6.18):
- 944-01: net: dsa: realtek: rtl8365mb: use devm_mutex_init for mib_lock
- 944-02: net: dsa: realtek: use devm_mutex_init for regmap lock
- 944-03: net: dsa: realtek: use devm_mutex_init for vlan_lock
- 944-04: net: dsa: realtek: use devm_mutex_init for l2_lock
Signed-off-by: Mieczyslaw Nalewaj <namiltd@yahoo.com>
Link: https://github.com/openwrt/openwrt/pull/24486
Signed-off-by: Jonas Jelonek <jelonek.jonas@gmail.com>
Rename all 942-* backport patches for the Realtek rtl8365mb DSA driver
to prefix the kernel version with "v" (e.g. v7.2 instead of 7.2),
matching the naming convention used elsewhere for backport patches.
Affected patches:
- 942-01: use ERR_PTR
- 942-02: reject unsupported topology
- 942-03: use dsa helpers for port isolation
- 942-04: prepare for multiple sources
- 942-05: add table lookup interface
- 942-06: add VLAN support
- 942-07: add FDB support
- 942-08: add port_bridge_join/leave
- 942-09: add bridge port flags
No functional changes.
Signed-off-by: Mieczyslaw Nalewaj <namiltd@yahoo.com>
Link: https://github.com/openwrt/openwrt/pull/24483
Signed-off-by: Jonas Jelonek <jelonek.jonas@gmail.com>
George Moussalem
Robert Marko
Matt Eaton
Julius Bairaktaris
Qingfang Deng
Vitaliy Sochnev
Jan Hoffmann
Carlo Szelinsky
Shiji Yang
Markus Stockhausen
Andrea Pesaresi
Jonas Jelonek
Rosen Penev
Edoardo Pinci
Frank Wunderlich
Daniel Golle
Semih Baskan
Ivan Rainbolt
Hauke Mehrtens
Luiz Angelo Daros de Luca
Chukun Pan
Aleksandr Mineev
Aleksei Sviridkin
Andrey Trishin
Aleksander Jan Bajkowski
Robert Marko
Joshua Covington
Mieczyslaw Nalewaj
John Audia