Hi Quentin, On Tue, Jul 21, 2026 at 4:20 PM Quentin Schulz <[email protected]> wrote: > > Hi Alexey, > > On 7/13/26 8:35 PM, Alexey Charkov wrote: > > The TRM defines the fractional PLL adjustment coefficient as a signed > > two's complement number, 16 bits wide, so store it as such to avoid > > confusion. > > > > Yet... > > > Signed-off-by: Alexey Charkov <[email protected]> > > --- > > arch/arm/include/asm/arch-rockchip/clock.h | 2 +- > > drivers/clk/rockchip/clk_pll.c | 3 ++- > > 2 files changed, 3 insertions(+), 2 deletions(-) > > > > diff --git a/arch/arm/include/asm/arch-rockchip/clock.h > > b/arch/arm/include/asm/arch-rockchip/clock.h > > index 95b08bfd046f..f9bfdfb8a6a3 100644 > > --- a/arch/arm/include/asm/arch-rockchip/clock.h > > +++ b/arch/arm/include/asm/arch-rockchip/clock.h > > @@ -104,7 +104,7 @@ struct rockchip_pll_rate_table { > > unsigned int m; > > unsigned int p; > > unsigned int s; > > - unsigned int k; > > + int k; > > ... you use int here instead of s16, any specific reason?
Yes. What matters here is the signedness. The table value never gets written to or read from the hardware without accessor functions, which mask on writes and sign-extend on reads anyway. A generic 'int' usually performs better than a fixed-width type because it aligns better and requires fewer instructions for arithmetic. It also reduces potential churn if this table definition is ever reused for another SoC with a different width for the k coefficient, but this latter point is more theoretical. Shall I reword the commit description accordingly? Happy to set the type to s16 if you believe it's more expressive, though; we aren't doing much arithmetic on the table values anyway. Best regards, Alexey
