Re: [PATCH v3 5/5] arm64: dts: imx8mq-librem5: Correct link frequency list

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 3 potential issue(s) to consider:
- [High] Strict equality check failure due to integer truncation precision loss
- [Medium] Device Tree ABI / Backward Compatibility break
- [Low] Mathematical error in commit message derivation
--

commit e44214657fa2d9bae2190f57c8fa133a21051c14
Author: Pengyu Luo <mitltlatltl@gmail.com>

arm64: dts: imx8mq-librem5: Correct link frequency list

This commit updates the device tree binding for the imx8mq-librem5 board
to correct the supported link frequencies for the hi846 camera sensor.

>     According to the hi846 datasheet and the register lists, they are
>     
>     mclk / prediv * multiplier / post_div1 / post_div2 =
>     25Mhz / 3 * 90 / 1 / {1,2} = 187.5Mhz, 375Mhz

Is this calculation completely accurate?

Mathematically, 25 / 3 * 90 / 1 / 1 equals 750 MHz, not 375 MHz. To achieve
187.5 MHz and 375 MHz, does the post_div1 divisor need to be 2 instead of 1?

> diff --git a/arch/arm64/boot/dts/freescale/imx8mq-librem5.dtsi b/arch/arm64/boot/dts/freescale/imx8mq-librem5.dtsi
> index eee390c272105..959a5c8dcd0d3 100644
> --- a/arch/arm64/boot/dts/freescale/imx8mq-librem5.dtsi
> +++ b/arch/arm64/boot/dts/freescale/imx8mq-librem5.dtsi

[ ... ]

> @@ -1122,7 +1122,7 @@ port {
>  			camera1_ep: endpoint {
>  				data-lanes = <1 2>;
>  				link-frequencies = /bits/ 64
> -					<80000000 200000000 300000000>;
> +					<187500000 375000000>;

Could this exact value specification cause the driver probe to fail due to
integer truncation?

The hi846 driver calculates the expected link frequency using the formula 
mclk / 3 * 90 / post_div1 / post_div2. Because mclk is exactly 25,000,000, 
the C integer division 25000000 / 3 evaluates to 8,333,333. After the 
subsequent multiplications and divisions, the evaluated link frequencies are 
187,499,992 Hz and 374,999,984 Hz.

Since hi846_check_link_freqs() performs a strict equality check against the
device tree values, this mismatch could cause it to reject the frequencies
and fail probing.

Additionally, does completely removing the old values break backward
compatibility for older kernels?

Prior to the driver update that dynamically calculates link frequencies, the
hi846 driver strictly required the hardcoded frequencies 80000000 and
200000000 to be present in the device tree. Appending the new values while
keeping the old ones might preserve backward compatibility.

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260511090924.269106-1-mitltlatltl@gmail.com?part=5