linux/kernel/git/baikal/linux.git, branch for-landau-next

Merge branches 'clk', 'pvt', 'dmac', 'uart', 'spi', 'i2c', 'boot', 'edma', 'pcie-lo', 'edac-bt1', 'xgmac-bt1', 'mips-bpf', 'mips-eva' and 'bsp' into for-landau-next

2026-08-13T20:10:09+00:00

net: stmmac: Add Baikal-T1 GMAC/XGMAC support

2026-08-13T17:38:43+00:00

Baikal-T1 is equipped with two DW GMAC v3.73a controllers synthesized with RGMII interface, MDIO bus, 16KB MTL Rx/Tx FIFO, 8 MAC address perfect filter slots, HW-based SA/VLAN/CRC insertion, 1xGPO and 1xGPI, EEE logic, IEEE 1588 Timestamping with Advanced capabilities, PMT capability with MagicPacket and Remote Wake-up support, Full Tx/Rx CSUM, IPv4 ARP offload, no hash-table and no L3/L4 filter logic. In addition to that there is DW XGMAC v2.11a and DW XPCS 3.11b synthesized with 10GBase-KR and 10GBase-KX4 physical interface, no MDIO bus, 32KB MTL Rx/Tx FIFO, 8 MAC address perfect filter slots, 64 slot in the Hash-based DA filter, VLAN Hash-based filter, 2x L3/L4 filters, 2x TCs, 2x Tx MTL Queues, 4x Rx MTL Queues, DCB feature, TSO and SPH for TCP/IP packets, Full Tx/Rx CSUM Offload, IPv4 ARP offload, 64-entries RSS table, IEEE 1588 Timestamping with Advanced capabilities, no PMT. Most of that is more-or-less supported by the STMMAC driver. The only thing left to do is to add the Baikal-T1 platform-specific glue driver for it. The LLDD is mainly responsible for the standard STMMAC driver pre-initialization and the platform device probing. There are some peculiar Baikal-T1 GMAC-specific actions performed aside of that though. First of all we need to enable/disable the RGMII Tx clock and tune its rate up based on the RGMII interface mode. Secondly due to the having the most of the Baikal-T1 platforms using the embedded GPO for the attached PHYs reset we have to make sure the DW GMAC core isn't reset after the device is probed otherwise any PHY initializations performed afterwards will be lost. In order to do that the custom DW GMAC software reset callback is introduced. Finally for the same reason we've added a custom MDIO bus reset method so the GPO would be set to a mainly valid value before the platform Ethernet PHYs are actually probed. Note the custom MDIO/COre reset methods is a temporary solution until we get to clean the STMMAC driver up and introduce a fully generic GPIO interface for the driver core. Signed-off-by: Serge Semin

dt-bindings: net: Add Baikal-T1 XGMAC bindings

2026-08-13T17:38:43+00:00

Baikal-T1 SoC is equipped with one DW XGMAC v2.11a-based 10GBE interface synthesized with: XGMII-bus connected to DW XPCS v3.11b, AXI3-DMA and APB3 CSR, 32KB Tx/Rx MTL FIFOs with up two 4 MTL Rx Queues and 2 MTL Tx Queue using two DMA-interfaces for Tx and Rx, PTP, PMT, TCP/IP CoE, TSO, up to 8 outstanding AXI read/write requests, maximum AXI burst length of 16 beats (due to AXI3 constraints), up to eight MAC address slots and 64-bits hash -based MAC-address filter. Let's add the respective DT-bindings so the device tree sources could be correctly verified. The STMMAC/Baikal XGMAC platform driver will be added next. Signed-off-by: Serge Semin

dt-bindings: net: Add Baikal-T1 GMAC bindings

2026-08-13T17:38:43+00:00

Baikal-T1 SoC is equipped with two DW GMAC v3.73a-based 1GBE Ethernet interfaces synthesized with: RGMII PHY interface, AXI-DMA and APB3 CSR, 16KB Tx/Rx FIFOs and PBL up to half of that, PTP, PMT, TCP/IP CoE, up to 4 outstanding AXI read/write requests, maximum AXI burst length of 16 beats, up to eight MAC address slots, one GPI and one GPO ports. Let's add the respective DT-bindings so the device tree sources could be correctly verified. The STMMAC/Baikal GMAC platform driver will be added next. Signed-off-by: Serge Semin Reviewed-by: Rob Herring

net: stmmac: xgmac: Add display_ring() desc operation

2026-08-13T17:38:43+00:00

It might get to be handy to print out the DMA descriptors content during the initial DMA interface initialization. Thus let's add the display_ring() callback then in the similar way as it's done for the rest of the DW {XG}MAC controllers. Signed-off-by: Serge Semin

net: stmmac: xgmac: Use interrupt mode INTM=1 for multi-MSI

2026-08-13T17:38:43+00:00

The INTM=0 interrupt mode causes both respective per-channel sbd_perch_[tx|rx]_intr_o and common sbd_intr_o signals being triggered on the RI/TI status bits change. The later event is not only redundant in this case but less efficient since both IRQs handlers will be called due to a single event thus wasting the CPU resources. Let's enable the INTM=1 mode which implies triggering the per-channel signals only on the normal RI/TI IRQs. Note a similar fix has been incorporated to the DW GMAC4 sub-module in the commit 6ccf12ae111e ("net: stmmac: use interrupt mode INTM=1 for multi-MSI"). Signed-off-by: Serge Semin

net: stmmac: xgmac: Fix PHY-interface select naming

2026-08-13T17:38:43+00:00

In accordance with [1] the phy_intf_sel_i[1:0] signal is encoded as follows: 00: non-RGMII interface (XGMII/GMII/MII) 01: RGMII interface 10: RMII Interface 11: Reserved So convert convert PHY_INTF_GMII to being PHY_INTF_XGMII with multi-variant MII-based name and add PHY_INTF_RMII interface name to comply with the official DW XGMAC databook. [1] DesignWare® Cores XGMAC - 10G Ethernet MAC, Revision 3.20a, October 2022, p. 424. Signed-off-by: Serge Semin

net: stmmac: Add platform-specific multi-channel TSO flag

2026-08-13T17:38:43+00:00

It's possible to have more than a single DMA-channel supporting the TCP-segmentation offloading. The driver currently doesn't support anything to detected and utilize that. In the meantime the feature may greatly improve the TCP/IP traffic transfer performance. Let's fix that by introducing a platform-specific flag STMMAC_FLAG_TSO_FULL which would indicate such feature availability and permit selecting any Tx-channel to send TCP/UDP/IP traffic with the TSO engine. Signed-off-by: Serge Semin

net: stmmac: Add per-DMA-channels platform IRQs support

2026-08-13T17:38:42+00:00

The main part of the functionality was added in the framework of the commit b42446b9b37b ("stmmac: intel: add support for multi-vector msi and msi-x"). But for some reason it was done for the PCI-based netword device only meanwhile the per-DMA-channel IRQs can be available on the normal platforms too. Let's fix the stmmac_get_platform_resources() method so one would request the DMA Tx/Rx platform IRQs. The DW *MAC DT-bindings requires them to have the names "(rx|tx)-queue-[0-9]". The IRQs request and per-channel ISR setup will be performed later in the stmmac_main.c driver. Note even though the driver and DT-bindings call them per-MTL-queue IRQs in fact these are the DMA per-channel IRQs. The driver just maps DMA channel and MTL queues one-on-one so the IRQs turn out to be raised as if for the respective queues too. Alas nothing can be done at this stage to fix the naming since the DT-bindings has already being defined. Changing the names would make the DT-schema even more messy than it already is. Signed-off-by: Serge Semin

net: stmmac: Use pclk to set MDC clock frequency

2026-08-13T17:38:42+00:00

In accordance with [1] the MDC clock frequency is supposed to be selected with respect to the CSR clock frequency. CSR clock can be either tied to the DW MAC system clock (GMAC main clock) or supplied via a dedicated clk_csr_i signal. Current MDC clock selection procedure handles the former case while having no support of the later one. That's wrong for the devices which have separate system and CSR clocks. Let's fix it by first trying to get the synchro-signal rate from the "pclk" clock, if it hasn't been specified then fall-back to the "stmmaceth" clock. [1] DesignWare Cores Ethernet MAC Universal Databook, Revision 3.73a, October 2013, p. 424. Signed-off-by: Serge Semin