Re: [PATCH] phy: phy-mtk-dp: Fix pdata array members initialized as pointers

[AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>]

On 9/13/26 19:29, Sasha Levin wrote:
> Building arm/arm64/i386 allmodconfig with clang fails:
> 
>    drivers/phy/mediatek/phy-mtk-dp.c:761:18: error: incompatible pointer
>    to integer conversion initializing 'u16' (aka 'unsigned short') with
>    an expression of type 'const u16[4]' [-Wint-conversion]
>    drivers/phy/mediatek/phy-mtk-dp.c:761:18: error: initializer element
>    is not a compile-time constant
>    drivers/phy/mediatek/phy-mtk-dp.c:761:18: error: suggest braces around
>    initialization of subobject [-Werror,-Wmissing-braces]
> 
> 14 errors in total, one set per offending member.
> 
> off_ana_lane, off_dig_lane and driving_params are declared as arrays in
> struct mtk_dp_phy_pdata:
> 
> 	u16 off_ana_lane[MTK_DP_PHY_MAX_LANES];
> 	u16 off_dig_lane[MTK_DP_PHY_MAX_LANES];
> 	u32 driving_params[PHYD_DIG_NUM_DRV_PARA_REGS];
> 
> but the SoC data instances initialize them with compound literals. A
> compound literal is an object, not an initializer list, so this is not
> an array initializer: the member is initialized element-wise from a
> scalar, the first element gets the address of the literal truncated to
> u16/u32, and the remaining elements are zeroed. Hence the three
> diagnostics above - the pointer-to-integer conversion, the address not
> being a compile-time constant, and the missing braces.
> 
> Arrays are the right type here, since both members are indexed per lane
> and driving_params is sized with ARRAY_SIZE(), so drop the casts and use
> plain braced initializers.
> 
> Found by KernelCI builds of the linus-next tree.
> 
> Fixes: ae859204b519 ("phy: phy-mtk-dp: Migrate register offsets to SoC specific pdata")
> Fixes: 7cf38eb0ab59 ("phy: phy-mtk-dp: Add support for digital and analog calibration")
> Fixes: 6fe4d5beac72 ("phy: phy-mtk-dp: Add support for MT8196 eDP PHY")
> Assisted-by: LLM
> Signed-off-by: Sasha Levin <sashal@kernel.org>

Whoops, sorry.

Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>