kernel/linux.git/drivers/phy/freescale, branch v7.2-rc1

phy: freescale: phy-fsl-imx8qm-lvds-phy: Fix missing pm_runtime_disable() on probe error path

2026-06-11T15:27:07+00:00

If mixel_lvds_phy_reset() fails in probe after pm_runtime_enable(), the function returns directly without calling pm_runtime_disable(), leaving runtime PM permanently enabled for the device. Fix this by using devm_pm_runtime_enable() so that cleanup is automatic on any probe failure or driver unbind. This also allows removing the manual err label and the .remove callback. Fixes: 06ff622d61d2 ("phy: freescale: Add i.MX8qm Mixel LVDS PHY support") Acked-by: Liu Ying Signed-off-by: Felix Gu Reviewed-by: Frank Li Link: https://patch.msgid.link/20260605-lvds-v2-1-3ce7539d1104@gmail.com Signed-off-by: Vinod Koul

phy: freescale: phy-fsl-imx8qm-lvds-phy: Use synchronous PM runtime put in reset

2026-06-11T11:01:22+00:00

The mixel_lvds_phy_reset() function pairs pm_runtime_resume_and_get() with pm_runtime_put(). The asynchronous variant queues a work item to handle the idle check and potential suspend, which can be cancelled by a subsequent pm_runtime_disable() call if probe fails after the reset. Switch to pm_runtime_put_sync() to run the idle check and suspend synchronously. Fixes: 06ff622d61d2 ("phy: freescale: Add i.MX8qm Mixel LVDS PHY support") Reported-by: sashiko Closes: https://sashiko.dev/#/patchset/20260605-lvds-v2-1-3ce7539d1104%40gmail.com Signed-off-by: Felix Gu Reviewed-by: Frank Li Link: https://patch.msgid.link/20260609-lvds-phy-v1-1-6ad790c6d0ea@gmail.com Signed-off-by: Vinod Koul

phy: lynx-10g: new driver

2026-06-11T07:09:47+00:00

Introduce a driver for the networking lanes of the 10G Lynx SerDes block, present on the majority of Layerscape and QorIQ (Freescale/NXP) SoCs. As with the 28G Lynx, the SerDes lanes come pre-initialized out of reset and the consumers use them that way outside the Generic PHY framework (for networking, the static configuration remains for the entire SoC lifetime, whereas for SATA and PCIe, the hardware reconfigures itself automatically for other link speeds). The need for the Generic PHY framework comes specifically for networking use cases where a static lane configuration is not sufficient. For example a network MAC is connected to an SFP cage, where various SFP or SFP+ modules can be connected. Each of them may require a different SerDes protocol (SGMII, 1000Base-X, 10GBase-R), which phylink + sfp-bus are responsible of figuring out. The phylink drivers are: - enetc - felix - dpaa_eth (fman_memac) - dpaa2-eth - dpaa2-switch and they all need to reconfigure the SerDes for the requested link mode, using phy_set_mode_ext() (and phy_validate() to see if it is supported in the first place). Note that SerDes 2 on LS1088A is exclusively non-networking, so there is currently no need for this driver. Therefore we skip matching on its compatible string and do not probe on that device. Co-developed-by: Ioana Ciornei Signed-off-by: Ioana Ciornei Signed-off-by: Vladimir Oltean Link: https://patch.msgid.link/20260610151952.2141019-16-vladimir.oltean@nxp.com Signed-off-by: Vinod Koul

phy: lynx-28g: improve phy_validate() procedure

2026-06-11T07:09:47+00:00

lynx_28g_validate() suffers from the following shortcomings: - Changing the protocol should not be possible if the source protocol of the lane is unsupported. This is because lynx_28g_proto_conf[] only covers the register deltas between any pair of supported lane modes, but that delta is probably incomplete if the source protocol is, say, PCIe (which is currently assimilated by the driver to LANE_MODE_UNKNOWN). lynx_28g_proto_conf() does refuse changing the protocol if the current one is unsupported, but we shouldn't advertise it via phy_validate() at all. The phy_set_mode_ext() call should perform the exact same verifications as phy_validate() did, in case the caller bypassed phy_validate(). So we need to centralize the logic into a common validation. But lynx_28g_set_mode() later needs the lane_mode that this validation needs to compute anyway, so name the common helper lynx_phy_mode_to_lane_mode() and let it return that lane_mode. - Future core sanity checks on phy_validate() will want to differentiate the case where this optional method is not implemented from the case where the mode/submode is really not supported. So we shouldn't return -EOPNOTSUPP from lynx_28g_validate(), but -EINVAL to signal that we do implement the operation: https://lore.kernel.org/linux-phy/aY2lFTIALH7qEJmM@shell.armlinux.org.uk/ Signed-off-by: Vladimir Oltean Link: https://patch.msgid.link/20260610151952.2141019-14-vladimir.oltean@nxp.com Signed-off-by: Vinod Koul

phy: lynx-28g: optimize read-modify-write operation

2026-06-11T07:09:47+00:00

It is unnecessary to rewrite a register if the masked field already contains the desired value upon reading. The hardware behaviour does not depend upon register writes with identical values. Signed-off-by: Vladimir Oltean Link: https://patch.msgid.link/20260610151952.2141019-13-vladimir.oltean@nxp.com Signed-off-by: Vinod Koul

phy: lynx-28g: add support for big endian register maps

2026-06-11T07:09:47+00:00

Some 10G Lynx SerDes blocks are big endian and require byte swapping because the CPUs are little endian armv8 (LS1046A). Parse the "big-endian" device tree property, and modify the base lynx_read() and lynx_write() accessors to test this property before issuing either the ioread32() or ioread32be() variants (as per Documentation/driver-api/device-io.rst). All other accessors - lynx_rmw(), lynx_lane_read(), lynx_lane_write(), lynx_lane_rmw(), lynx_pll_read() - need to go through these endian-aware helpers. Signed-off-by: Vladimir Oltean Link: https://patch.msgid.link/20260610151952.2141019-12-vladimir.oltean@nxp.com Signed-off-by: Vinod Koul

phy: lynx-28g: common probe() and remove()

2026-06-11T07:09:47+00:00

Factor the device-agnostic logic from lynx_28g_probe() and lynx_28g_remove() into lynx_probe() and lynx_remove() inside phy-fsl-lynx-core.c. These will be shared with the 10G Lynx driver. Since the PLL configuration, lane configuration and CDR lock detection procedure are going to be different, introduce lynx_info function pointers so that this code remains in the 28G Lynx driver. Signed-off-by: Vladimir Oltean Link: https://patch.msgid.link/20260610151952.2141019-11-vladimir.oltean@nxp.com Signed-off-by: Vinod Koul

phy: lynx-28g: make lynx_28g_pll_read_configuration() callable per PLL

2026-06-11T07:09:47+00:00

In a future change, lynx_28g_pll_read_configuration() and lynx_28g_lane_read_configuration() will be made methods of struct lynx_info. There is no functional reason, but lynx_28g_lane_read_configuration() is called per lane and lynx_28g_pll_read_configuration() iterates over PLLs internally. So the API exported by the lynx_info structure would not be uniform. Change lynx_28g_pll_read_configuration() to also permit reading the PLL configuration individually, and move the for loop at the call site. Signed-off-by: Vladimir Oltean Link: https://patch.msgid.link/20260610151952.2141019-10-vladimir.oltean@nxp.com Signed-off-by: Vinod Koul

phy: lynx-28g: move struct lynx_info definitions downwards

2026-06-11T07:09:46+00:00

We need to be able to reference more function pointers in upcoming patches. The struct lynx_info definitions are currently placed a bit up in lynx-28g.c in order to be able to do that without function prototype forward declarations, so move them downward to avoid that situation. No functional change intended. Signed-off-by: Vladimir Oltean Link: https://patch.msgid.link/20260610151952.2141019-9-vladimir.oltean@nxp.com Signed-off-by: Vinod Koul

phy: lynx-28g: provide default lynx_lane_supports_mode() implementation

2026-06-11T07:09:46+00:00

For the 28G Lynx, there are situations where a protocol is not supported on a lane despite there being a PCCR register and protocol converter available: - LX2160A SerDes 1: reference manual documents PCCD fields E25GC_CFG and E25GD_CFG and protocol converter registers E25GCCR1..E25GCCR3 / E25GDCR1..E25GDCR3, but nonetheless, Table 289. SerDes 1 protocol mapping shows no RCW[SRDS_PRTCL_S1] value for which lanes C and D support 25G - when using the "fsl,lynx-28g" fallback compatible string, we don't want to offer 25GbE because we don't know if the lane supports it, even though we know how to reach the PCCR and protocol converter registers for it. But for the upcoming 10G Lynx SerDes, the above situations don't exist. There, if we know how to reach the PCCR and protocol converter registers on a lane, we implicitly know that the protocol is supported there, so implementing priv->info->lane_supports_mode() would be redundant. Implement lynx_lane_supports_mode_default() which decides whether a lane mode is supported just based on priv->info->get_pccr() and priv->info->get_pcvt_offset(). Signed-off-by: Vladimir Oltean Link: https://patch.msgid.link/20260610151952.2141019-8-vladimir.oltean@nxp.com Signed-off-by: Vinod Koul