Backport Lantiq and Maxlineat PHY level statistics support. These
statistics count frames dropped by the PHY due to invalid symbols
on layer 1.
Tested on Lantiq/Maxlinear GPY111:
root@OpenWrt:~# ethtool -S lan3 --groups eth-phy
Standard stats for lan3:
eth-phy-SymbolErrorDuringCarrier: 856
Signed-off-by: Aleksander Jan Bajkowski <olek2@wp.pl>
Link: https://github.com/openwrt/openwrt/pull/25282
Signed-off-by: Robert Marko <robimarko@gmail.com>
Backport upstream commit e9f850ba66cd ("rtc: cmos: Use
platform_get_irq_optional() in cmos_platform_probe()"),
which landed in v7.1.
The rtc-cmos driver can live without an IRQ and returning an error
code from platform_get_irq() is not a problem for it in general, so
make it call platform_get_irq_optional() in cmos_platform_probe()
instead of platform_get_irq() to avoid a confusing error message
printed by the latter if an IRQ cannot be found for index 0, which
is possible on x86 platforms.
Additionally, on x86, if the IRQ is not defined and the system has
a legacy PIC, hardcode it to RTC_IRQ, which should be safe then (and
which is what the dropped PNP code did).
Fixes: https://github.com/openwrt/openwrt/issues/25248
Signed-off-by: Andy Chiang <AndyChiang_git@outlook.com>
Link: https://github.com/openwrt/openwrt/pull/25264
Signed-off-by: Robert Marko <robimarko@gmail.com>
Linux 6.18.46 included stable commit 29dbb4e29e1f ("ksmbd: Fix
to handle removal of rfc1002 header from smb_hdr"), a backport of
upstream commit 0a70cac78967.
The upstream change depends on SMB1 header refactoring that removed the
RFC1002 length field from struct smb_hdr. Those prerequisites are not
present in 6.18.y, where struct smb_hdr still contains smb_buf_length.
Consequently, smb_get_msg() advances the buffer by four bytes before
it is cast to a structure that already includes the RFC1002 field. This
creates a four-byte offset mismatch while parsing and constructing the
initial SMB1 multi-protocol negotiate response. Windows clients receive
a malformed response and abort the connection.
Apply the revert provided by ksmbd maintainer Namjae Jeon to restore
consistent SMB1 buffer handling in 6.18.y.
Drop this patch with the kernel bump that includes the stable revert.
Fixes: 87e5289908 ("kernel: bump 6.18 to 6.18.46")
Link: https://git.kernel.org/torvalds/c/83bfbd0bb9025f98fa62b44f93bd67466773d1db
Link: https://git.kernel.org/torvalds/c/0a70cac7896712a08e3cd22c16f44be976d40dbf
Tested-by: Andrea Pesaresi <andreapesaresi82@gmail.com>
Tested-on: GL.iNet GL-MT3000
Signed-off-by: Andrea Pesaresi <andreapesaresi82@gmail.com>
Link: https://github.com/openwrt/openwrt/pull/25271
Signed-off-by: Robert Marko <robimarko@gmail.com>
Both drivers implement the phylink tx_lpi methods but never fill
phylink_config.lpi_interfaces, so phylink decides at creation time
that the MAC does not support EEE and locks userspace out of enabling
it. On mt753x that has been the state since the conversion to phylink
managed EEE; on mtk_eth_soc since EEE was added there, which was
already in managed form.
Both fixes are in net:
https://git.kernel.org/netdev/net/c/3c18e3c9a54ehttps://git.kernel.org/netdev/net/c/d876c9cb2d16
The mtk_eth_soc fix is taken as upstream applied it. The mt7530 one is
adapted: upstream guards the block with an extra priv->id != ID_EN7528
arm, and that symbol only exists once econet's local EN7528 patch adds
it, so the generic backport drops the arm and the patch header records
that. The mtk_eth_soc fix lands ahead of three patches that touch the
same part of mtk_add_mac and the same capability enum, so 737-10,
795-05 and the mt7987 platform patch are refreshed for it; 795-05 also
loses a declaration hunk that this fix makes redundant. Seven more
mtk_eth_soc patches (702, hack 730, 732-00, 732-03, 737-09, 738-01 and
795-04) are refreshed for hunk offsets only.
The mtk_eth_soc fix fills lpi_interfaces only on SoCs carrying a new
MTK_GMAC_EEE capability, and only MT7981 sets it: the LPI wake-up times
the driver programs are borrowed from MT7531 and have been measured on
MT7981 alone, so the other SoCs keep EEE unreachable until someone
confirms them.
The econet EN7528 patch is rebased on top of the mt7530 fix: both
rewrite the same block in mt753x_phylink_get_caps(), and generic
applies first, so the EN7528 guard now sits on the reworked condition.
The behavior for EN7528 is unchanged: its LPI capabilities stay empty
and phylink keeps EEE disabled there.
Tested on an MT7981B board with an MT7531 switch: ethtool sees EEE on
every port where it saw nothing before, enabling it negotiates EEE
against a partner that advertises it, and a port whose partner does
not advertise settles at "enabled - inactive".
Assisted-by: LLM
Signed-off-by: Aleksei Sviridkin <f@lex.la>
Link: https://github.com/openwrt/openwrt/pull/24863
Signed-off-by: Jonas Jelonek <jonas@jonasjelonek.de>
The Quectel EG060W (Cat 6 LTE) modem, as used by the Cudy LT700 Outdoor,
exposes its DIAG, NMEA and AT command interfaces as vendor-specific
(ff/00/00) under product ID 0x6004. Without a matching entry the option
driver does not bind these interfaces, so no /dev/ttyUSB* ports are
created and the modem cannot be configured.
Backport the upstream commit adding the 0x6004 product ID. The CDC-NCM
data interfaces use a standard class and are not affected.
Also refresh hack-6.18/780-usb-net-MeigLink_modem_support.patch, whose
option.c hunks are applied after this change and shift by one line.
Signed-off-by: Carlo Szelinsky <github@szelinsky.de>
Link: https://github.com/openwrt/openwrt/pull/24689
Signed-off-by: Jonas Jelonek <jonas@jonasjelonek.de>
It showed up after a kernel refresh on qualcommax, as it only shows up
with ALL_KMODS.
So, to avoid dropping it again from target config, move it to generic.
Fixes: 4f9740c734 ("qualcommax: refresh config")
Signed-off-by: Robert Marko <robimarko@gmail.com>
After a kernel config refresh for qualcommax it showed up again.
Instead of disabling it per target. disable by default in generic.
Signed-off-by: Robert Marko <robimarko@gmail.com>
6.18.45 pulled in b5964aac51e0 ("netfilter: flowtable: consolidate xmit
path") as a dependency of the CVE fix 8aecf0bbcc72. Since then the
FLOW_OFFLOAD_XMIT_NEIGH path no longer transmits on the dst device, it
looks the output device up by flow_offload_tuple.ifidx, which is fed from
route->tuple[dir].out.ifindex.
That field is only assigned in nft_dev_forward_path() when the forward
path could be discovered, nft_default_forward_path() never sets it. A
flow whose egress path cannot be resolved is therefore offloaded with an
interface index of 0, nf_flow_offload_ip_hook() drops the packet and
tears the flow down, the flow_offload expression offloads it again right
away and the loss repeats instead of settling.
Bridged Wi-Fi is the common case: mac80211 fails .ndo_fill_forward_path
with -EOPNOTSUPP unless the driver implements .net_fill_forward_path, and
with WED the path ends in DEV_PATH_MTK_WDMA, which the parser does not
handle either, so both ways end up without an output device. This matches
the reports of sporadic packet loss towards wireless clients with
software flow offloading enabled on mediatek/filogic.
Add a patch that falls back to the dst device, which is the device the
neighbour is looked up on and the device the packets were transmitted on
before the xmit paths were merged. Mainline avoids the situation
differently since 871df5007eda ("netfilter: flowtable: bail out if
forward path cannot be discovered"), which sits on top of the forward
path discovery rework and does not apply to 6.18.y. 6.12 does not carry
the rework and is not affected.
Fixes: da5c83ece675 ("kernel: bump 6.18 to 6.18.45")
Assisted-by: Claude:claude-opus-5
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
Link: https://github.com/openwrt/openwrt/pull/24800
Signed-off-by: Robert Marko <robimarko@gmail.com>
Since 6.18.45 backported b5964aac51e0 ("netfilter: flowtable: consolidate
xmit path"), FLOW_OFFLOAD_XMIT_NEIGH looks the output device up by
route->tuple[dir].out.ifindex instead of transmitting on the dst device.
Our copy of the route setup sets that field only for
FLOW_OFFLOAD_XMIT_DIRECT and only discovers the forward path when both
directions are FLOW_OFFLOAD_XMIT_NEIGH, so a flow with an undiscoverable
path, a non-ethernet egress or an xfrm dst in one direction gets an
ifindex of 0: every packet is dropped, the flow is torn down and
offloaded again.
Set the ifindex for every xmit type and look each direction up on its
own, as upstream does in the nftables path (b5964aac51e0 and 2bdc536c9da7
"netfilter: always set route tuple out ifindex"), and fall back to the
dst device where upstream leaves the ifindex at 0, so those flows stay
offloaded.
Fixes: da5c83ece675 ("kernel: bump 6.18 to 6.18.45")
Assisted-by: Claude:claude-opus-5
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
Link: https://github.com/openwrt/openwrt/pull/24800
Signed-off-by: Robert Marko <robimarko@gmail.com>
The use of a modulo operation on 64-bit integers broke the build on
32-bit targets which do not provide such operations.
Seen on the buildbots as:
mips-openwrt-linux-musl-ld: drivers/mtd/parsers/routerbootpart.o:
in function `routerboot_partitions_parse':
drivers/mtd/parsers/routerbootpart.c:
(.text.routerboot_partitions_parse+0x58c):
undefined reference to `__umoddi3'
Fix this by using mtd_mod_by_eb() instead of open-coding the alginment
check.
Fixes: ada1dcb2b4 ("generic: mikrotik: size RouterBoot partitions so they are usable")
Signed-off-by: Daniel Golle <daniel@makrotopia.org>
Two fixes to the RouterBoot partition handling, both found on a MikroTik
Chateau 5G R17 ax but neither device specific.
hard_config is not guaranteed to fit within RB_BLOCK_SIZE. On this board
the tag list spans 5576 bytes, because the WLAN calibration tag alone
carries 5100 bytes of LZ77 compressed data, so truncating the partition
makes that tag unreadable. Walk the tag list to its terminating null node
and size the partition accordingly. The result never shrinks below
RB_BLOCK_SIZE, so devices whose tag list already fits are unaffected.
soft_config carries the boot settings and is the one RouterBoot segment
meant to be written, but at RB_BLOCK_SIZE (4 KiB) on a flash with 64 KiB
erase blocks MTD always forces it read-only. Grow it to a full erase
block where the space is free, checked against the following partition so
that erasing it cannot destroy a neighbour.
That growth alone would break the checksum, because rb_softconfig derives
everything from the partition size while RouterBoot validates the CRC32
over its own 4 KiB. Introduce RB_SC_CFG_SIZE and keep reads, CRC and write
back within it; the erase still covers the whole partition.
With both in place, writing boot_device followed by commit persists across
a reboot and "ethonce" triggers a real etherboot.
Signed-off-by: André Valentin <avalentin@marcant.net>
Link: https://github.com/openwrt/openwrt/pull/24335
Signed-off-by: Robert Marko <robimarko@gmail.com>
Backport upstream commit a3729e0df005 ("net/sched: sch_cake: skip
clearing unused tins during rate adjustment"), which landed in v7.2.
cake_configure_rates() is called from the dequeue path with
rate_adjust=true, where cake_clear_tin() overwrites q->cur_tin and
q->cur_flow while cake_dequeue() is using them, and purging the unused
tins adds overhead to the hot path. Skipping the loop restores loaded
latency to pre-15c2715a5264 levels; on IPQ8074A in besteffort mode the
loaded latency drops from ~470 ms to ~4 ms in Flent's tcp_nup test.
Refresh the sync_time debugfs hack patch, whose hunks shift by two
lines.
Signed-off-by: Jonas Köppeler <j.koeppeler@tu-berlin.de>
Link: https://github.com/openwrt/openwrt/pull/25182
Signed-off-by: Robert Marko <robimarko@gmail.com>
Add kernel packages for DVB adapters, frontends and tuners. Not
everything is covered, but the list can grow over the time.
Userspace uses these through /dev/dvb, for example tvheadend from the
packages feed, which streams the tuners to network clients over HTTP
and HTSP.
Remote controller support (kmod-rc-core) goes into the Input modules
menu: rc-core depends only on INPUT and is not DVB specific.
Enabling DVB_CORE and RC_CORE makes parts of the media driver menu
visible which nothing in the tree has enabled so far, so kconfig has
no answer for them and stops for input. Add the 98 missing symbols to
the generic config. CONFIG_MEDIA_RC_SUPPORT, CONFIG_VIDEO_V4L2,
CONFIG_DVB_HD29L2, CONFIG_DVB_USB_FRIIO and CONFIG_IR_SIR do not exist
in kernel 6.18 anymore and are removed.
Tested on kernel 6.18.44, all 78 packages build with CONFIG_ALL_KMODS
and their module paths and kernel symbols were verified against the
kernel tree.
Signed-off-by: Michal Hrusecky <michal.hrusecky@nic.cz>
Signed-off-by: Karel Kočí <karel.koci@nic.cz>
Signed-off-by: Josef Schlehofer <pepe.schlehofer@gmail.com>
Link: https://github.com/openwrt/openwrt/pull/24788
Signed-off-by: Robert Marko <robimarko@gmail.com>
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>
Zhengping Zhang
Aleksander Jan Bajkowski
Andy Chiang
Andrea Pesaresi
Aleksei Sviridkin
Carlo Szelinsky
Robert Marko
John Audia
Hauke Mehrtens
Daniel Golle
André Valentin
Jonas Köppeler
Michal Hrusecky
Rosen Penev
George Moussalem
Matt Eaton
Julius Bairaktaris
Qingfang Deng
Vitaliy Sochnev
Jan Hoffmann
Shiji Yang
Markus Stockhausen
Jonas Jelonek
Edoardo Pinci
Frank Wunderlich
Semih Baskan
Ivan Rainbolt