staging/xback/target, branch master

ipq40xx: mikrotik: wap-ac: describe the ADC

2026-11-13T13:18:45Z

The wAP ac has an ADS7846 like touch screen controller (hard_config: "has TS ADC") on chip select 1 of the SPI, a GPIO (GPIO 1). It measures the input voltage (AUX) and the temperature. Give it a spidev at 1 MHz. The vendor device tree of the wAP R ac (wap2r-dk) has it the same way; only the wAP ac is tested, so the shared dtsi is left alone. Tested on a wAP ac, against a calibrated supply from 12 to 57 V. Assisted-by: Claude Opus 5.5 Signed-off-by: Koen Vandeputte

ath79: mikrotik: describe the ADC of the RB922, wAP R and RB2011

2026-11-13T13:18:45Z

These boards have an ADS7846 like touch screen controller (hard_config: "has TS ADC"), on the RB2011 also for its touch screen. It measures the input voltage (AUX, VBAT on the wAP R) and the temperature. Give it a spidev, at the clock the controller can make: - RB922UAGS-5HPacD: CS2, 2 MHz - wAP R: CS2, 2.5 MHz (AHB 300 MHz / 128 is the slowest) - RB2011UiAS-2HnD: CS2, 3.125 MHz (AHB 400 MHz / 128), its data on GPIO 13 (qca,miso-pin) The SPI mode is set by the user (mode 0: spi-ar934x has no other). Tested on all three, against a calibrated supply from 12 to 27 V. Assisted-by: Claude Opus 5.5 Signed-off-by: Koen Vandeputte

ath79: spi-ar934x: take the data in of a device from its own GPIO

2026-11-13T13:18:45Z

The SPI data in of the AR934x comes from one GPIO, selected in GPIO_IN_ENABLE0: the one of the flash. On the MikroTik RB2011 the touch controller on CS2 sends its data on GPIO 13; the vendor kernel selects that GPIO for the messages to CS2 only. Do the same: with a "gpio-in" register range on the controller, a device with a qca,miso-pin property gets its GPIO selected for its messages. The controller serializes the messages, so the flash never sees it. Tested on a RB2011UiAS-2HnD: the ADC on CS2 reads, GPIO_IN_ENABLE0 is back at 0x908 after each message, the flash and the LCD on CS1 work as before. Assisted-by: Claude Opus 5.5 Signed-off-by: Koen Vandeputte

ath79: mikrotik: rb922: describe the ath10k on pcie1

2026-11-13T09:46:50Z

The QCA9882 of the RB922UAGS-5HPacD sits on the second PCIe root complex, at 0000:01:00.0: 11-ath10k-caldata already loads its calibration data for that address. The first one serves the mini PCIe slot. The wifi@0,0 node was put on pcie0 by the original ath79 port, so it went to whatever card is in the slot, and the ath10k had none. Move the node to pcie1, as the RB911G-5HPacD and RB921GS-5HPacD-15s already have it. Nothing uses it yet, but a property added to it now reaches the ath10k. Tested on a RB922UAGS-5HPacD with an AR958x card in the slot: the ath10k now binds /ahb/pcie@18250000/wifi@0,0, the ath9k has no node, and both radios work as before. Assisted-by: Claude Opus 5.5 Signed-off-by: Koen Vandeputte

ath79: qca955x: fix the address of the second reset register

2026-11-13T09:23:23Z

RST_RESET2 is at 0x180600c4 on QCA955x (QCA9558 datasheet, 10.7.14), not at 0x180600c0 as on QCA956x. The wrong address goes back to the original qca9557.dtsi, which took it from the QCA956x layout. The second PCIe RC, the second USB host and its PHY all take their resets from rst2, so reset_control_status(), assert and deassert on them hit an undocumented register and had no effect. Everything only worked because the bootloader had already released these blocks. On an Archer C7 v2 with Breed, the PCIe controller's link-up bit now drops after an assert/deassert, and the link comes back in about 10 ms, compared with "up" 8 us after a reset that never happened. ath10k on pcie1 and an MT7612U on the second USB port come up on every one of five warm reboots with the new address. Fixes: b1a173d7c3 ("ath79: add support for tl-wr1043nd v2/v3") Assisted-by: LLM Co-Authored-By: Claude Opus 5.5 Claude-Session: https://claude.ai/code/session_01X4fQYZAVx9sEHVTUpfBFRM Signed-off-by: Rosen Penev Link: https://github.com/openwrt/openwrt/pull/23559 Signed-off-by: Robert Marko (cherry picked from commit a0e44e8538c938f43daaeaa28547ed3513b11215) Signed-off-by: Koen Vandeputte

ath79: mikrotik: rb2011: drive the beeper as a GPIO PWM

2026-11-13T08:10:05Z

The RB2011UiAS has a passive buzzer on GPIO 22, described as a gpio-beeper: that can only switch the pin on or off, which makes the buzzer click once instead of sounding. Describe it as a pwm-gpio (software PWM from hrtimers), as on the RB922UAGS-5HPacD, and ship kmod-gpio-pwm instead of kmod-gpio-beeper, so a tone of any pitch can be played through /sys/class/pwm. Assisted-by: Claude Opus 5.5 Signed-off-by: Koen Vandeputte

ath79: mikrotik: rb2011: add a spidev node for the LCD

2026-11-12T15:51:58Z

The RB2011 has a 160x128 TFT with an ST7735 compatible controller on SPI chip select 1 (GPIO 1, clock on GPIO 12, data on GPIO 4, as RouterBOOT sets them up), data/command select on GPIO 0. Its power comes from the AR8327 LED pin of lcd_backlight. Expose it as spidev0.1, for a user space driver: the touch controller on chip select 2 only needs its pen down line (GPIO 16) to tell a touch. Tested on an RB2011UiAS-IN: 160x128 at (1, 2) in the controller's memory, MADCTL 0x60, 16 bit colour, 15 MHz. Assisted-by: Claude Opus 5.5 Signed-off-by: Koen Vandeputte

ath79: mikrotik: rb2011: report the SFP link on switch port 6

2026-11-12T15:03:45Z

The SFP cage hangs off AR8327 port 6, which runs with a forced 1000M link and so was always reported up. The loss of signal line (GPIO 17) only reached the sfp driver, which cannot act on it here: the cage is not attached to a netdev, so the state only showed in debugfs. Hand that line to the switch as qca,port6-link-gpios, as the ar71xx board file did. swconfig now reports port 6 down without fiber or module, and up again with a signal. Tested on an RB2011UiAS-IN with a MikroTik S-31DLC20D to an RB922: traffic over the SFP, port 6 down within a second of unplugging the fiber, up again after plugging it back in. Assisted-by: Claude Opus 5.5 Signed-off-by: Koen Vandeputte

generic: ar8327: take the link of a forced port 6 from a GPIO

2026-11-12T15:03:45Z

Port 6 of the AR8327 runs with a forced link on boards with an SFP cage on it (SGMII). The switch then always reports that port as up, also without a module or fiber. The ar71xx board files solved this with the get_port_link() callback, which ar8216_read_port_link() still calls for forced ports, but which nothing sets since the move to device tree. Give the callback the switch, and let the device tree name a GPIO for the link of port 6: qca,port6-link-gpios, e.g. the SFP's loss of signal line. swconfig then shows the real state of the port. Assisted-by: Claude Opus 5.5 Signed-off-by: Koen Vandeputte

kernel: rmnet: expand the ingress headroom only when it is needed

2026-11-03T17:17:07Z

Add a pending patch (sent upstream, not accepted yet): for an Ethernet type real device, rmnet_map_ingress_handler() reallocated the head of every frame to push ETH_HLEN, also when the headroom was already there. Applies with zero fuzz to 6.18.60 (the upstream patch needed fuzz: its context has a data race annotation 6.18 does not have). Assisted-by: Claude Opus 5.5 Signed-off-by: Koen Vandeputte