On 6.09.2023 23:14, Stephen Boyd wrote: > Quoting Konrad Dybcio (2023-09-06 00:33:38) >> On 5.09.2023 22:40, Stephen Boyd wrote: >>> Quoting Devi Priya (2023-09-01 00:00:41) >>>> The round_rate() API returns a long value as the errors are reported using >>>> negative error codes. This leads to long overflow when the clock rate >>>> exceeds 2GHz.As the clock controller treats the clock rate above signed >>>> long max as an error, use determine_rate in place of round_rate as the >>>> determine_rate API does not possess such limitations. >>> >>> Does this fix something, or is it preparing for PLLs that run faster >>> than 2GHz? >> I did some grepping and we already have multiple of these. >> >> E.g. SM8250 CAMCC PLL2 (zonda) goes (or well, should go) up to 3.6 GHz. >> >> Today, only stromer PLL uses determine rate, but perhaps all of them >> should. >> >> I would not at all be surprised if many otherwise inexplicable bugs >> went away with that change. > > Are any of those arm32 systems? It would only matter on arm32 systems > because sizeof(long) is limited to 32-bits and we don't have negative > frequencies. Looking deeper, not sure if we have any armv7 chips falling under this category, but there are definitely arm64 SoCs that can boot arm32 kernels (e.g. 8953). Konrad
