[PATCH v5 phy-next 11/16] phy: lynx-28g: add support for big endian register maps

[sashiko-bot at kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Low] Returning a void expression from a function with a void return type in `lynx_write` violates the C standard and kernel coding best practices, and can cause hard build failures on certain architectures.
--

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

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

This commit adds support for big-endian register maps in the Lynx 28G PHY
driver. It introduces endian-aware lynx_read() and lynx_write() helpers that
conditionally apply byte-swapping based on a device tree property.

> diff --git a/drivers/phy/freescale/phy-fsl-lynx-core.h b/drivers/phy/freescale/phy-fsl-lynx-core.h
> --- a/drivers/phy/freescale/phy-fsl-lynx-core.h
> +++ b/drivers/phy/freescale/phy-fsl-lynx-core.h

[ ... ]

> +static inline void lynx_write(struct lynx_priv *priv, unsigned long off, u32 val)
> +{
> +	void __iomem *reg = priv->base + off;
> +
> +	if (priv->big_endian)
> +		return iowrite32be(val, reg);
> +
> +	return iowrite32(val, reg);
> +}

[Severity: Low]
Is it safe to use the return keyword for these void I/O accessors?

While the compiler might permit returning a void expression, it technically
violates the C standard. If iowrite32be() or iowrite32() are implemented as
non-expression macros (such as a do { ... } while(0) block) on certain
architectures, couldn't this expand into a syntax error and cause a build
regression?

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