staging/stintel/target/linux, branch master

airoha: an7583: fix AN7583 PCS port count

2026-07-16T12:30:21Z

The AN7583 PCS match data does not initialize num_port. This leaves it at zero, so probe allocates a zero-sized ports array and a later PCS lookup returns a pointer derived from NULL. Set the number of ports for each AN7583 PCS instance. Also reject out-of-range PCS indices defensively. Fixes kernel crashing on boot once ethernet starts probing on AN7583. Signed-off-by: Robert Marko

airoha: an7583: update ethernet node for new PCS implementation

2026-07-16T09:42:02Z

With new PCS implementation, the pcs property needs to be updated to the new name of 'pcs-handle' to correctly work with PCS fwnode consumer/provider. Fixes: 4d5f579a8120 ("airoha: update PCS node in DTSI for new PCS implementation") Signed-off-by: Robert Marko

qualcommbe: i2c-an7581: depend only on target

2026-07-16T09:33:02Z

i2c-an7581 (In reality its just i2c-mt7621) should depend on the airoha target in general and not on an7581 as an7583 also uses it. Signed-off-by: Robert Marko

qualcommbe: an7583: correct I2C controller compatible

2026-07-16T09:33:02Z

AN7583 DTS currently uses a non existant compatible that only exists in the Airoha SDK. It should just be changed to the generic MT7621 compatible as AN7581 uses as well. Signed-off-by: Robert Marko

mpc85xx: use regulator for USB power

2026-07-15T18:25:52Z

Use upstream solution for managing GPIO power for USB devices. A small patch is needed to make the whole thing work as this is an older USB driver that does not use the PHY framework. Signed-off-by: Rosen Penev Link: https://github.com/openwrt/openwrt/pull/16842 Signed-off-by: Jonas Jelonek

kernel: disable pcrypt

2026-07-15T18:18:09Z

The obsolete pcrypt module is being removed upstream. Signed-off-by: Qingfang Deng Link: https://github.com/openwrt/openwrt/pull/24222 Signed-off-by: Jonas Jelonek

ath79: fix u-boot-env nvmem-layout on enterasys,ws-ap3705i

2026-07-15T18:13:11Z

The u-boot-env0 partition on this board stores a redundant U-Boot environment (4-byte CRC32 + 1-byte flag + data), with the flag byte differing between the u-boot-env0/u-boot-env1 copies (0x00 vs 0x01). The actual environment size used by U-Boot for the CRC calculation is 0x1000 bytes, not the full 0x10000 byte partition. The DTS declared this as the plain, non-redundant "u-boot,env" layout with no env-size, so the kernel's u-boot-env nvmem-layout driver miscomputes the CRC and fails to probe: u-boot-env-layout ...nvmem-layout: Invalid calculated CRC32: 0xbc490a68 (expected: 0xfae56b95) u-boot-env-layout ...nvmem-layout: probe with driver u-boot-env-layout failed with error -22 Because the probe fails, the macaddr_uboot_ethaddr nvmem cell is never created, so eth0's nvmem-cells reference never resolves and the ag71xx-legacy platform device is stuck in "deferred probe pending" forever - the device boots with no functioning Ethernet interface at all. Switch to "u-boot,env-redundant-count" (matching the redundant-env layout already used on other boards from this vendor lineage, e.g. qca9557_extreme-networks_ws-ap3805i.dts) and set env-size to the verified 0x1000, which fixes CRC validation and lets eth0 probe successfully. Verified on real hardware: before the fix, eth0 never comes up (confirmed against the official 25.12.5 release, matching CRC values exactly); after the fix, eth0 links up normally and dmesg is free of any CRC/nvmem-layout errors. Signed-off-by: Zoltan Szalay Signed-off-by: Zoltan Szalay Link: https://github.com/openwrt/openwrt/pull/24134 Signed-off-by: Jonas Jelonek

realtek: pcs: rtl930x: gate WDIG 10G-mode bit on real baud rate

2026-07-15T17:37:01Z

This bit was set unconditionally for any 10G-capable SerDes regardless of hw_mode, including SGMII/1000BASEX/2500BASEX running on 10G-capable silicon. The vendor SDK's dal_longan_construct_mac_default_10gmedia_fiber gates it on the port's declared protocol class instead, applying it to PHY-attached XSGMII/USXGMII as well as genuine fiber - the "medium to fiber" naming doesn't match its actual condition. Gate on speed == RTPCS_SDS_PLL_SPD_10000 instead, matching the real 10G-class protocol family, and actively clear it for 1G/2.5G modes so a prior 10G-class configuration doesn't leave it stuck across a runtime downshift. 0 also matches this register's confirmed hardware reset default on an unconfigured SerDes. Link: https://github.com/openwrt/openwrt/pull/24232 Signed-off-by: Jonas Jelonek

realtek: pcs: rtl930x: gate TX tuning on attachment and baud rate

2026-07-15T17:37:01Z

TX amp/pre-emphasis tuning depends on the SerDes' real baud rate class rather than hw_mode, so key config_attachment's dispatch on that instead. At 1G/2.5G, attachment doesn't change meaningful: even a non-adaptive fiber receiver needs little compensation on a short trace, so PHY-attached and fiber links already use the same config there. At 10G, real channel loss is high enough that it matters: PHY-attached links equalize on the PHY's own far-end receiver and need less amp drive, while genuine fiber/DAC links, which have no adaptive receiver downstream, need the full config. Real DAC-vs-fiber detection doesn't exist yet, so both of those still share one config for now. Make use of the PLL speed enum for now, though it is a bit blurry and may not represent the real baud rate in some cases, e.g. QSGMII (1.25G PLL with multiplier -> 5G). Link: https://github.com/openwrt/openwrt/pull/24232 Signed-off-by: Jonas Jelonek

realtek: pcs: rtl930x: refactor TX config

2026-07-15T17:37:01Z

Replace the on-stack, hardcoded pre/main/post-amp locals with static const rtpcs_sds_tx_config data, one struct per speed class (1g, 2g5, 10g), instead of duplicating the same literals inline on every call. Move the decision logic about which values are applied to the config_media function. The tx_config should only be about what is set, decision logic is handled one layer above. This also prepares further refactoring. Link: https://github.com/openwrt/openwrt/pull/24232 Signed-off-by: Jonas Jelonek