[PATCH v4 phy-next 03/16] 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 1 potential issue(s) to consider:
- [Low] Global namespace pollution from generic enum values in public header.
--

commit 379cdd0e1e3286bd548f97019e5685a48b3a3ca2
Author: Vladimir Oltean <vladimir.oltean at nxp.com>
Date:   Mon Jun 8 22:16:57 2026 +0000

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

This commit moves lane mode helpers into a new core module as preparation
for the upcoming lynx-10g driver. As part of this refactoring, the lane
modes are exported to a public header to allow coordination with the SoC
driver.

[ ... ]

> 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 enum lynx_lane_mode is moving from a private driver source file to a
public include header, could these generic enum names like LANE_MODE_UNKNOWN
and LANE_MODE_MAX cause namespace collisions with other subsystems?

Would it be better to add a subsystem prefix, such as LYNX_LANE_MODE_ or
FSL_LYNX_LANE_MODE_, to these values now that they are globally visible?

> +
> +#endif /* __PHY_FSL_LYNX_H_ */

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