[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <SJ0P222MB01077015D90D0B2D7F995552A1E19@SJ0P222MB0107.NAMP222.PROD.OUTLOOK.COM>
Date: Thu, 15 Dec 2022 13:43:53 +0000
From: Kenneth Sloat <ksloat@...ignlinxhs.com>
To: Michal Simek <michal.simek@....com>,
"sean.anderson@...o.com" <sean.anderson@...o.com>,
"michal.simek@...inx.com" <michal.simek@...inx.com>,
"linux-arm-kernel@...ts.infradead.org"
<linux-arm-kernel@...ts.infradead.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
Kenneth Sloat <ksloat@...ignlinxhs.com>
Subject: Re: [PATCH] pwm: xilinx: Fix overflow issue in 32-bit width PWM mode.
Hi Michal thanks for your reply.
> On 12/12/22 14:59, Kenneth Sloat wrote:
>> This timer HW supports 8, 16 and 32-bit timer widths. This
>> driver uses a u32 to store the max value of the timer.
>> Because addition is done to this max value, when operating
>> in 32-bit mode, this will result in overflow that makes it
>> impossible to set the timer period and thus the PWM itself.
>>
>> To fix this, simply make max a u64. This was tested on a
>> Zynq UltraScale+.
> Can you please be more accurate where that overflow is happening.
> I see that value is set only at probe like
>
> priv->max = BIT_ULL(width) - 1;
>
>
> No doubt that there are calculation based on u64 types.
>
>
It actually does not happen in probe but when applying the PWM settings, here:
period_cycles = min_t(u64, period_cycles, priv->max + 2);
if (period_cycles < 2)
return -ERANGE;
If the timer is 32 bit, priv->max + 2 will roll over to 1, and thus will always be rejected as out of range. So, likely at minimum, a cast on priv->max would be needed here first.
duty_cycles would also have the same issue:
duty_cycles = min_t(u64, duty_cycles, priv->max + 2);
>>
>> Signed-off-by: Ken Sloat <ksloat@...ignlinxhs.com>
>> ---
>> include/clocksource/timer-xilinx.h | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/include/clocksource/timer-xilinx.h b/include/clocksource/timer-xilinx.h
>> index c0f56fe6d22a..d116f18de899 100644
>> --- a/include/clocksource/timer-xilinx.h
>> +++ b/include/clocksource/timer-xilinx.h
>> @@ -41,7 +41,7 @@ struct regmap;
>> struct xilinx_timer_priv {
>> struct regmap *map;
>> struct clk *clk;
>> - u32 max;
>> + u64 max;
>> };
>>
>> /**
>> --
>> 2.17.1
>>
>
> Thanks,
> Michal
Are you are good with the code change as is? If so, what do you propose? Should I amend the commit message with more details about where the overflow is occurring?
Thanks
Sincerely,
Ken Sloat
Powered by blists - more mailing lists