| Message ID | 1d1a8ede-e789-bc4d-2dcd-9d06d2df4061@gmail.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | pwm: pwm-meson: fix handling of period/duty if greater than UINT_MAX | expand |
hello, On Wed, May 03, 2023 at 09:58:17PM +0200, Heiner Kallweit wrote: > state->period/duty are of type u64, and if their value is greater than > UINT_MAX, then the cast to uint will cause problems. Fix this by > changing the type of the respective local variables to u64. > > Fixes: b79c3670e120 ("pwm: meson: Don't duplicate the polarity internally") > Cc: stable@vger.kernel.org > Suggested-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> > Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com> Reviewed-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Thanks! Uwe
On Wed, May 3, 2023 at 9:58 PM Heiner Kallweit <hkallweit1@gmail.com> wrote: > > state->period/duty are of type u64, and if their value is greater than > UINT_MAX, then the cast to uint will cause problems. Fix this by > changing the type of the respective local variables to u64. > > Fixes: b79c3670e120 ("pwm: meson: Don't duplicate the polarity internally") > Cc: stable@vger.kernel.org > Suggested-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> > Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com> Reviewed-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
On 08.05.2023 21:46, Martin Blumenstingl wrote: > On Wed, May 3, 2023 at 9:58 PM Heiner Kallweit <hkallweit1@gmail.com> wrote: >> >> state->period/duty are of type u64, and if their value is greater than >> UINT_MAX, then the cast to uint will cause problems. Fix this by >> changing the type of the respective local variables to u64. >> >> Fixes: b79c3670e120 ("pwm: meson: Don't duplicate the polarity internally") >> Cc: stable@vger.kernel.org >> Suggested-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> >> Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com> > Reviewed-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com> Not sure about the process in pwm subsystem: When will these patches make it to linux-next? Because I'd like to submit follow-ups with a dependency only after pending patches have been applied.
On Mon, May 15, 2023 at 10:32 PM Heiner Kallweit <hkallweit1@gmail.com> wrote: > > On 08.05.2023 21:46, Martin Blumenstingl wrote: > > On Wed, May 3, 2023 at 9:58 PM Heiner Kallweit <hkallweit1@gmail.com> wrote: > >> > >> state->period/duty are of type u64, and if their value is greater than > >> UINT_MAX, then the cast to uint will cause problems. Fix this by > >> changing the type of the respective local variables to u64. > >> > >> Fixes: b79c3670e120 ("pwm: meson: Don't duplicate the polarity internally") > >> Cc: stable@vger.kernel.org > >> Suggested-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> > >> Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com> > > Reviewed-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com> > > Not sure about the process in pwm subsystem: When will these patches make > it to linux-next? Because I'd like to submit follow-ups with a dependency > only after pending patches have been applied. I'm also not sure. Personally I would take all patches that fix the existing driver code, bundle them into a series and re-send that (collecting all Reviewed-by, etc. along the way). The idea is to make Thierry's life easier as he just has to apply the series (no need to worry about the patch order, ...).
On 23.05.2023 22:51, Martin Blumenstingl wrote: > On Mon, May 15, 2023 at 10:32 PM Heiner Kallweit <hkallweit1@gmail.com> wrote: >> >> On 08.05.2023 21:46, Martin Blumenstingl wrote: >>> On Wed, May 3, 2023 at 9:58 PM Heiner Kallweit <hkallweit1@gmail.com> wrote: >>>> >>>> state->period/duty are of type u64, and if their value is greater than >>>> UINT_MAX, then the cast to uint will cause problems. Fix this by >>>> changing the type of the respective local variables to u64. >>>> >>>> Fixes: b79c3670e120 ("pwm: meson: Don't duplicate the polarity internally") >>>> Cc: stable@vger.kernel.org >>>> Suggested-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> >>>> Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com> >>> Reviewed-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com> >> >> Not sure about the process in pwm subsystem: When will these patches make >> it to linux-next? Because I'd like to submit follow-ups with a dependency >> only after pending patches have been applied. > I'm also not sure. Personally I would take all patches that fix the > existing driver code, bundle them into a series and re-send that > (collecting all Reviewed-by, etc. along the way). The idea is to make > Thierry's life easier as he just has to apply the series (no need to > worry about the patch order, ...). Sounds like a plan, I think I'll follow this suggestion.
diff --git a/drivers/pwm/pwm-meson.c b/drivers/pwm/pwm-meson.c index 3865538dd..33107204a 100644 --- a/drivers/pwm/pwm-meson.c +++ b/drivers/pwm/pwm-meson.c @@ -156,8 +156,9 @@ static int meson_pwm_calc(struct meson_pwm *meson, struct pwm_device *pwm, const struct pwm_state *state) { struct meson_pwm_channel *channel = &meson->channels[pwm->hwpwm]; - unsigned int duty, period, pre_div, cnt, duty_cnt; + unsigned int pre_div, cnt, duty_cnt; unsigned long fin_freq; + u64 duty, period; duty = state->duty_cycle; period = state->period; @@ -179,19 +180,19 @@ static int meson_pwm_calc(struct meson_pwm *meson, struct pwm_device *pwm, dev_dbg(meson->chip.dev, "fin_freq: %lu Hz\n", fin_freq); - pre_div = div64_u64(fin_freq * (u64)period, NSEC_PER_SEC * 0xffffLL); + pre_div = div64_u64(fin_freq * period, NSEC_PER_SEC * 0xffffLL); if (pre_div > MISC_CLK_DIV_MASK) { dev_err(meson->chip.dev, "unable to get period pre_div\n"); return -EINVAL; } - cnt = div64_u64(fin_freq * (u64)period, NSEC_PER_SEC * (pre_div + 1)); + cnt = div64_u64(fin_freq * period, NSEC_PER_SEC * (pre_div + 1)); if (cnt > 0xffff) { dev_err(meson->chip.dev, "unable to get period cnt\n"); return -EINVAL; } - dev_dbg(meson->chip.dev, "period=%u pre_div=%u cnt=%u\n", period, + dev_dbg(meson->chip.dev, "period=%llu pre_div=%u cnt=%u\n", period, pre_div, cnt); if (duty == period) { @@ -204,14 +205,13 @@ static int meson_pwm_calc(struct meson_pwm *meson, struct pwm_device *pwm, channel->lo = cnt; } else { /* Then check is we can have the duty with the same pre_div */ - duty_cnt = div64_u64(fin_freq * (u64)duty, - NSEC_PER_SEC * (pre_div + 1)); + duty_cnt = div64_u64(fin_freq * duty, NSEC_PER_SEC * (pre_div + 1)); if (duty_cnt > 0xffff) { dev_err(meson->chip.dev, "unable to get duty cycle\n"); return -EINVAL; } - dev_dbg(meson->chip.dev, "duty=%u pre_div=%u duty_cnt=%u\n", + dev_dbg(meson->chip.dev, "duty=%llu pre_div=%u duty_cnt=%u\n", duty, pre_div, duty_cnt); channel->pre_div = pre_div;
state->period/duty are of type u64, and if their value is greater than UINT_MAX, then the cast to uint will cause problems. Fix this by changing the type of the respective local variables to u64. Fixes: b79c3670e120 ("pwm: meson: Don't duplicate the polarity internally") Cc: stable@vger.kernel.org Suggested-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com> --- drivers/pwm/pwm-meson.c | 14 +++++++------- 1 file changed, 7 insertions(+), 7 deletions(-)