staging/xback/target/linux, branch master

ath79: mikrotik: rb922: add the beeper as a GPIO PWM

2026-10-19T14:10:54Z

The RB922UAGS-5HPacD has a passive buzzer on GPIO 4: toggling it clicks, toggling it at audio rate sounds a tone. Describe it as a pwm-gpio (software PWM from hrtimers) and add kmod-gpio-pwm, so a tone can be played through /sys/class/pwm. When disabled the PWM drives the pin low, its current idle state. Signed-off-by: Koen Vandeputte

ath79: mikrotik: enable the PWM core

2026-10-19T14:10:48Z

Lets devices use PWM drivers such as kmod-gpio-pwm (software PWM on a GPIO): the "pwm" target feature, which kmod-gpio-pwm depends on, is derived from CONFIG_PWM. All PWM-related symbols this exposes are already covered by the generic kernel config. Signed-off-by: Koen Vandeputte

ath79: mikrotik: rb922: drop the ath10k gpio-leds node

2026-10-19T14:10:46Z

The green:wlan5g gpio-leds node referenced GPIO 0 of the ath10k chip, but ath10k-ct (the driver this device ships) doesn't register a GPIO controller, so the node never probed ("deferred probe pending: leds-gpio: Failed to get GPIO '/ath10k-leds/wlan5g'") and the 5 GHz LED stayed dark. The LED is on ath10k pin 1: driving the ath10k-ct LED (ath10k-phy0, led_pin 1 for QCA988X) on and off toggled it on a RB922UAGS-5HPacD. That LED is registered by the driver itself with the phy0tpt trigger, so drop the gpio-leds node and the gpio-controller properties that only served it. Signed-off-by: Koen Vandeputte

ath79: ag71xx: SGMII fixup retries exceeded is debug only

2026-10-19T14:10:46Z

The fixup never reaches the state it waits for (0x0f/0x10) with an empty SFP cage or a 1000BASE-X module, while the link works: on RB922 with S-31DLC20D modules it logged "max retries for SGMII fixup exceeded" at every link change despite a working fibre link. Log it with pr_debug instead of as an error. Signed-off-by: Koen Vandeputte

ath79: ag71xx: keep the carrier off without an SFP link

2026-10-19T14:10:44Z

phylib turns the carrier on itself when the (fixed) link comes up, before calling adjust_link, so behind an SFP cage eth1 still reported a carrier without any signal from the module. Turn it back off in adjust_link while the SFP reports no link. Signed-off-by: Koen Vandeputte

ath79: mikrotik: rb92x: fix SFP TX_DISABLE polarity

2026-10-19T14:10:43Z

TX_DISABLE of the SFP cage is inverted on the board: GPIO16 high enables the transmitter. With the GPIO described as active high, the SFP core switched the laser off exactly when it meant to enable it. Measured on two RB922UAGS-5HPacD linked by S-31DLC20D modules: with tx_disable 0 (GPIO16 low) the laser bias was 0 mA and the far end saw -40 dBm with LOS; with tx_disable 1 (GPIO16 high) the bias was 20 mA, -5.4 dBm out, and the far end received -3.3 dBm without LOS. This went unnoticed while nothing attached to the cage: the SFP core keeps TX_DISABLE asserted (GPIO16 high), which left the laser on. Signed-off-by: Koen Vandeputte

ath79: ag71xx: register as upstream of an SFP cage

2026-10-19T14:10:42Z

On the RB92x the SFP cage is wired straight to the SGMII MAC, which runs on a fixed link; the cage is only referenced by an "sfp" property on the placeholder phy_sfp node. Nothing registered as its upstream, so since the SFP core keeps TX_DISABLE asserted until an upstream starts the socket, the module's transmitter stayed off ("Module state: waitdev", "Device state: detached", tx_disable 1) and the port could not link. The fixed link also kept eth1's carrier up with or without a module or fibre. Look up an "sfp" property on the MAC node or on its phy-handle node and register as the cage's upstream: start/stop the socket from ndo_open/ndo_stop, let the carrier follow the module's link (LOS) on top of the fixed link, redo the SGMII fixup when the module reports a link, and expose the bus for "ethtool -m". Boards without an "sfp" property are unchanged. Signed-off-by: Koen Vandeputte

ath79: ag71xx: don't stall the system in the SGMII fixup

2026-10-19T14:10:36Z

The QCA955x SGMII fixup retries up to 21 times, with mdelay(300) each, until the SGMII state reads 0x0f or 0x10. It runs from __ag71xx_link_adjust(), which the phylib link callback calls with ag->lock held and interrupts disabled. When that state never comes, as on the RB922 with an empty SFP cage, the busy-wait froze the whole single-core system for ~6.3 s on every link change: twice per boot, holding up netifd and everything else. Run the fixup from a work item and sleep between the retries instead, cancelling the work when the interface stops and on remove. Also log the SGMII state the fixup gave up on. Signed-off-by: Koen Vandeputte

tty: serial: 8250_exar: Fix redundant pcim_iomap calls during port setup

2026-10-19T12:06:50Z

In exar_pci_probe(), BAR 0 is mapped once at driver initialization using pcim_iomap() and saved in priv->virt. However, the board setup functions (default_setup() and cti_port_setup_common()) subsequently call serial8250_pci_setup_port() for each serial port channel. Inside serial8250_pci_setup_port(), pcim_iomap() is called again to map BAR 0. Modern Linux kernels raise a WARNING in drivers/pci/devres.c (pcim_iomap) when a driver attempts duplicate managed mappings on the same BAR. Fix this by eliminating calls to serial8250_pci_setup_port() in default_setup() and cti_port_setup_common(). Instead, explicitly assign the port's iotype, membase, mapbase, and regshift members directly using the pre-mapped priv->virt pointer. Signed-off-by: Koen Vandeputte

Revert "ath79: mikrotik: compile SWCONFIG and AR8216_PHY as modules"

2026-10-19T12:06:50Z

This reverts commit 9091c9f8cbd9da4fe47477f45668c6a11b24c16d.