kernel/linux.git/drivers/net/pcs, branch v7.0-rc7

Convert more 'alloc_obj' cases to default GFP_KERNEL arguments

2026-02-22T04:03:00+00:00

This converts some of the visually simpler cases that have been split over multiple lines. I only did the ones that are easy to verify the resulting diff by having just that final GFP_KERNEL argument on the next line. Somebody should probably do a proper coccinelle script for this, but for me the trivial script actually resulted in an assertion failure in the middle of the script. I probably had made it a bit _too_ trivial. So after fighting that far a while I decided to just do some of the syntactically simpler cases with variations of the previous 'sed' scripts. The more syntactically complex multi-line cases would mostly really want whitespace cleanup anyway. Signed-off-by: Linus Torvalds

Convert 'alloc_obj' family to use the new default GFP_KERNEL argument

2026-02-22T01:09:51+00:00

This was done entirely with mindless brute force, using git grep -l '\

treewide: Replace kmalloc with kmalloc_obj for non-scalar types

2026-02-21T09:02:28+00:00

This is the result of running the Coccinelle script from scripts/coccinelle/api/kmalloc_objs.cocci. The script is designed to avoid scalar types (which need careful case-by-case checking), and instead replace kmalloc-family calls that allocate struct or union object instances: Single allocations: kmalloc(sizeof(TYPE), ...) are replaced with: kmalloc_obj(TYPE, ...) Array allocations: kmalloc_array(COUNT, sizeof(TYPE), ...) are replaced with: kmalloc_objs(TYPE, COUNT, ...) Flex array allocations: kmalloc(struct_size(PTR, FAM, COUNT), ...) are replaced with: kmalloc_flex(*PTR, FAM, COUNT, ...) (where TYPE may also be *VAR) The resulting allocations no longer return "void *", instead returning "TYPE *". Signed-off-by: Kees Cook

Merge git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net

2026-01-23T04:14:36+00:00

Cross-merge networking fixes after downstream PR (net-6.19-rc7). Conflicts: drivers/net/ethernet/huawei/hinic3/hinic3_irq.c b35a6fd37a00 ("hinic3: Add adaptive IRQ coalescing with DIM") fb2bb2a1ebf7 ("hinic3: Fix netif_queue_set_napi queue_index input parameter error") https://lore.kernel.org/fc0a7fdf08789a52653e8ad05281a0a849e79206.1768915707.git.zhuyikai1@h-partners.com drivers/net/wireless/ath/ath12k/mac.c drivers/net/wireless/ath/ath12k/wifi7/hw.c 31707572108d ("wifi: ath12k: Fix wrong P2P device link id issue") c26f294fef2a ("wifi: ath12k: Move ieee80211_ops callback to the arch specific module") https://lore.kernel.org/20260114123751.6a208818@canb.auug.org.au Adjacent changes: drivers/net/wireless/ath/ath12k/mac.c 8b8d6ee53dfd ("wifi: ath12k: Fix scan state stuck in ABORTING after cancel_remain_on_channel") 914c890d3b90 ("wifi: ath12k: Add framework for hardware specific ieee80211_ops registration") Signed-off-by: Jakub Kicinski

net: pcs: pcs-mtk-lynxi: report in-band capability for 2500Base-X

2026-01-22T04:01:03+00:00

It turns out that 2500Base-X actually works fine with in-band status on MediaTek's LynxI PCS -- I wrongly concluded it didn't because it is broken in all the copper SFP modules and GPON sticks I used for testing. Hence report LINK_INBAND_ENABLE also for 2500Base-X mode. This reverts most of commit a003c38d9bbb ("net: pcs: pcs-mtk-lynxi: correctly report in-band status capabilities"). The removal of the QSGMII interface mode was correct and is left untouched. Link: https://github.com/openwrt/openwrt/issues/21436 Fixes: a003c38d9bbb ("net: pcs: pcs-mtk-lynxi: correctly report in-band status capabilities") Signed-off-by: Daniel Golle Link: https://patch.msgid.link/b1cf26157b63fee838be09ae810497fb22fd8104.1768961746.git.daniel@makrotopia.org Signed-off-by: Jakub Kicinski

net: pcs: pcs-mtk-lynxi: deprecate "mediatek,pnswap"

2026-01-22T03:46:59+00:00

Prefer the new "rx-polarity" and "tx-polarity" properties, which in this case have the advantage that polarity inversion can be specified per direction (and per protocol, although this isn't useful here). We use the vendor specific ones as fallback if the standard description doesn't exist. Daniel, referring to the Mediatek SDK, clarifies that the combined SGMII_PN_SWAP_TX_RX register field should be split like this: bit 0 is TX and bit 1 is RX: https://lore.kernel.org/linux-phy/aSW--slbJWpXK0nv@makrotopia.org/ Suggested-by: Daniel Golle Signed-off-by: Vladimir Oltean Link: https://patch.msgid.link/20260119091220.1493761-6-vladimir.oltean@nxp.com Signed-off-by: Jakub Kicinski

net: pcs: pcs-mtk-lynxi: pass SGMIISYS OF node to PCS

2026-01-22T03:46:58+00:00

The Mediatek LynxI PCS is used from the MT7530 DSA driver (where it does not have an OF presence) and from mtk_eth_soc, where it does (Documentation/devicetree/bindings/net/pcs/mediatek,sgmiisys.yaml informs of a combined clock provider + SGMII PCS "SGMIISYS" syscon block). Currently, mtk_eth_soc parses the SGMIISYS OF node for the "mediatek,pnswap" property and sets a bit in the "flags" argument of mtk_pcs_lynxi_create() if set. I'd like to deprecate "mediatek,pnswap" in favour of a property which takes the current phy-mode into consideration. But this is only known at mtk_pcs_lynxi_config() time, and not known at mtk_pcs_lynxi_create(), when the SGMIISYS OF node is parsed. To achieve that, we must pass the OF node of the PCS, if it exists, to mtk_pcs_lynxi_create(), and let the PCS take a reference on it and handle property parsing whenever it wants. Use the fwnode API which is more general than OF (in case we ever need to describe the PCS using some other format). This API should be NULL tolerant, so add no particular tests for the mt7530 case. Signed-off-by: Vladimir Oltean Link: https://patch.msgid.link/20260119091220.1493761-5-vladimir.oltean@nxp.com Signed-off-by: Jakub Kicinski

net: pcs: rzn1-miic: Add PHY_LINK active-level configuration support

2026-01-17T23:17:25+00:00

Add support to configure the active level of MIIC PHY_LINK status signals on a per-converter basis using a DT property. MIIC provides dedicated PHY_LINK signals that indicate EtherPHY link-up and link-down status in hardware. These signals are required regardless of whether GMAC or ETHSW is used. With GMAC, link state is retrieved via MDC/MDIO and handled in software, while ETHSW relies on PHY_LINK pins for both CPU-assisted operation and switch-only data paths that do not involve the host. Hardware PHY_LINK signals are also critical for fast reaction to link-down events, for example when running redundancy protocols such as Device Level Ring (DLR), where rapid detection of cable faults is required to switch to an alternate path without software latency. Parse the requested polarity from DT, accumulate the configuration during probing, and apply it to the MIIC_PHY_LINK register once hardware initialization is complete, when the registers can be safely modified. Handle SoC-specific bit layout differences between RZ/N1 and RZ/T2H/N2H within the driver. Signed-off-by: Lad Prabhakar Link: https://patch.msgid.link/20260112173555.1166714-3-prabhakar.mahadev-lad.rj@bp.renesas.com Signed-off-by: Jakub Kicinski

net: pcs: lynx: accept in-band autoneg for 2500base-x

2025-12-01T21:50:15+00:00

Testing in two circumstances: 1. back to back optical SFP+ connection between two LS1028A-QDS ports with the SCH-26908 riser card 2. T1042 with on-board AQR115 PHY using "OCSGMII", as per https://lore.kernel.org/lkml/aIuEvaSCIQdJWcZx@FUE-ALEWI-WINX/ strongly suggests that enabling in-band auto-negotiation is actually possible when the lane baud rate is 3.125 Gbps. It was previously thought that this would not be the case, because it was only tested on 2500base-x links with on-board Aquantia PHYs, where it was noticed that MII_LPA is always reported as zero, and it was thought that this is because of the PCS. Test case #1 above shows it is not, and the configured MII_ADVERTISE on system A ends up in the MII_LPA on system B, when in 2500base-x mode (IF_MODE=0). Test case #2, which uses "SGMII" auto-negotiation (IF_MODE=3) for the 3.125 Gbps lane, is actually a misconfiguration, but it is what led to the discovery. There is actually an old bug in the Lynx PCS driver - it expects all register values to contain their default out-of-reset values, as if the PCS were initialized by the Reset Configuration Word (RCW) settings. There are 2 cases in which this is problematic: - if the bootloader (or previous kexec-enabled Linux) wrote a different IF_MODE value - if dynamically changing the SerDes protocol from 1000base-x to 2500base-x, e.g. by replacing the optical SFP module. Specifically in test case #2, an accidental alignment between the bootloader configuring the PCS to expect SGMII in-band code words, and the AQR115 PHY actually transmitting SGMII in-band code words when operating in the "OCSGMII" system interface protocol, led to the PCS transmitting replicated symbols at 3.125 Gbps baud rate. This could only have happened if the PCS saw and reacted to the SGMII code words in the first place. Since test #2 is invalid from a protocol perspective (there seems to be no standard way of negotiating the data rate of 2500 Mbps with SGMII, and the lower data rates should remain 10/100/1000), in-band auto-negotiation for 2500base-x effectively means Clause 37 (i.e. IF_MODE=0). Make 2500base-x be treated like 1000base-x in this regard, by removing all prior limitations and calling lynx_pcs_config_giga(). This adds a new feature: LINK_INBAND_ENABLE and at the same time fixes the Lynx PCS's long standing problem that the registers (specifically IF_MODE, but others could be misconfigured as well) are not written by the driver to the known valid values for 2500base-x. Co-developed-by: Alexander Wilhelm Signed-off-by: Alexander Wilhelm Signed-off-by: Vladimir Oltean Link: https://patch.msgid.link/20251125103507.749654-1-vladimir.oltean@nxp.com Signed-off-by: Jakub Kicinski

net: pcs: xpcs: Add support for FBNIC 25G, 50G, 100G PMD

2025-11-27T09:41:31+00:00

The fbnic driver is planning to make use of the XPCS driver to enable support for PCS and better integration with phylink. To do this though we will need to enable several workarounds since the PMD interface for fbnic is likely to be unique since it is a mix of two different vendor products with a unique wrapper around the IP. I have generated a PHY identifier based on IEEE 802.3-2022 22.2.4.3.1 using an OUI belonging to Meta Platforms and used with our NICs. Using this we will provide it as the PMD ID via the SW based MDIO interface so that the fbnic device can be identified and necessary workarounds enabled in the XPCS driver. As an initial workaround this change adds an exception so that soft_reset is not set when the driver is initially bound to the PCS. In addition I have added logic to integrate the PMD Rx signal detect state into the link state for the PCS. With this we can avoid the link coming up too soon on the FBNIC PMD and as a result of it being in the training state so we can avoid link flaps. Signed-off-by: Alexander Duyck Link: https://patch.msgid.link/176374321695.959489.6648161125012056619.stgit@ahduyck-xeon-server.home.arpa Signed-off-by: Paolo Abeni