From: Thierry Reding <thierry.reding@gmail.com>
To: "Uwe Kleine-König" <uwe@kleine-koenig.org>
Cc: Johannes Pointner <h4nn35.work@gmail.com>,
Lee Jones <lee.jones@linaro.org>,
linux-pwm@vger.kernel.org, kernel@pengutronix.de,
Fabio Estevam <festevam@gmail.com>,
NXP Linux Team <linux-imx@nxp.com>
Subject: Re: [PATCH] pwm: imx27: fix overflow for bigger periods
Date: Thu, 10 Dec 2020 18:34:07 +0100 [thread overview]
Message-ID: <X9JcD5y4U/bLCc0N@ulmo> (raw)
In-Reply-To: <20201207141324.25945-1-uwe@kleine-koenig.org>
[-- Attachment #1: Type: text/plain, Size: 1639 bytes --]
On Mon, Dec 07, 2020 at 03:13:24PM +0100, Uwe Kleine-König wrote:
> The second parameter of do_div is an u32 and NSEC_PER_SEC * prescale
> overflows this for bigger periods. Assuming the usual pwm input clk rate
> of 66 MHz this happens starting at requested period > 606060 ns.
>
> Splitting the division into two operations doesn't loose any precision.
> It doesn't need to be feared that c / NSEC_PER_SEC doesn't fit into the
> unsigned long variable "duty_cycles" because in this case the assignment
> above to period_cycles would already have been overflowing as
> period >= duty_cycle and then the calculation is moot anyhow.
>
> Fixes: aef1a3799b5c ("pwm: imx27: Fix rounding behavior")
> Signed-off-by: Uwe Kleine-König <uwe@kleine-koenig.org>
> ---
> Hello,
>
> for a similar patch I said "that looses more precision than I thought at
> first", but I think this was wrong. And if it looses precision the same
> applies to the calculation of period_cycles which uses the same
> operations.
>
> I'm a bit at doubt how urgent this patch is. The regression was
> introduced in 5.8-rc1.
Well, given that this has been broken in v5.8 and v5.9 and was only
reported a couple of days ago, it doesn't seem like this is very urgent.
At the same time, it's a regression, so we should get this fixed as soon
as possible.
That said, I'm reluctant to send this to Linus without a bit of soak
time in linux-next. So let me put it in linux-next for now and if
there's an rc8 I'll send a PR next week. Otherwise it'll get picked up
into an early stable release and that's probably okay as well.
Thierry
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
prev parent reply other threads:[~2020-12-10 17:35 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-12-07 14:13 [PATCH] pwm: imx27: fix overflow for bigger periods Uwe Kleine-König
2020-12-07 15:20 ` Johannes Pointner
2020-12-10 17:34 ` Thierry Reding [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=X9JcD5y4U/bLCc0N@ulmo \
--to=thierry.reding@gmail.com \
--cc=festevam@gmail.com \
--cc=h4nn35.work@gmail.com \
--cc=kernel@pengutronix.de \
--cc=lee.jones@linaro.org \
--cc=linux-imx@nxp.com \
--cc=linux-pwm@vger.kernel.org \
--cc=uwe@kleine-koenig.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.