[PATCH v2 phy-next 02/15] phy: lynx-28g: move lane mode helpers to new core module

[sashiko-bot at kernel.org]

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [Low] The enum values for `lynx_lane_mode` are globally exposed without proper namespacing, risking build failures due to collisions.
- [Low] Invisible Kconfig symbol contains useless 'help' text.
--

commit afcf6c44814cd194adbadc7748b22b52095d7d42
Author: Vladimir Oltean <vladimir.oltean at nxp.com>

phy: lynx-28g: move lane mode helpers to new core module

This commit extracts lane mode helpers and shared structures from the
lynx-28g driver into a new core module. The lane modes are exported to
a public header to allow coordination with the upcoming lynx-10g driver.

> diff --git a/drivers/phy/freescale/Kconfig b/drivers/phy/freescale/Kconfig
> index 81f53564ee156..a87429f634ea8 100644
> --- a/drivers/phy/freescale/Kconfig
> +++ b/drivers/phy/freescale/Kconfig
> @@ -51,11 +51,18 @@ config PHY_FSL_SAMSUNG_HDMI_PHY
>  	  Enable this to add support for the Samsung HDMI PHY in i.MX8MP.
>  endif
>  
> +config PHY_FSL_LYNX_CORE
> +	tristate
> +	help
> +	  Enable this to add common support code for NXP Lynx 10G and Lynx 28G
> +	  SerDes blocks.

[Severity: Low]
This isn't a bug, but does this invisible Kconfig symbol need a help text?

Since this tristate doesn't have a prompt string, it won't be visible in
menuconfig, making the help text inaccessible to users.

[ ... ]

> diff --git a/include/soc/fsl/phy-fsl-lynx.h b/include/soc/fsl/phy-fsl-lynx.h
> new file mode 100644
> index 0000000000000..92e8272d5ae15
> --- /dev/null
> +++ b/include/soc/fsl/phy-fsl-lynx.h
> @@ -0,0 +1,16 @@
> +/* SPDX-License-Identifier: GPL-2.0+ */
> +/* Copyright 2023-2026 NXP */
> +
> +#ifndef __PHY_FSL_LYNX_H_
> +#define __PHY_FSL_LYNX_H_
> +
> +enum lynx_lane_mode {
> +	LANE_MODE_UNKNOWN,
> +	LANE_MODE_1000BASEX_SGMII,
> +	LANE_MODE_10GBASER,
> +	LANE_MODE_USXGMII,
> +	LANE_MODE_25GBASER,
> +	LANE_MODE_MAX,
> +};

[Severity: Low]
Since this header is now globally accessible under include/soc/, could these
generic enum values cause namespace collisions?

Values like LANE_MODE_UNKNOWN and LANE_MODE_MAX lack a subsystem or
driver-specific prefix (like LYNX_ or FSL_). If another subsystem defines
a macro or enum with the same generic name, it might lead to build failures.

> +
> +#endif /* __PHY_FSL_LYNX_H_ */

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260529171509.1163787-1-vladimir.oltean@nxp.com?part=2