diff mbox series

pwm: pwm-meson: fix handling of period/duty if greater than UINT_MAX

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

Commit Message

Heiner Kallweit May 3, 2023, 7:58 p.m. UTC
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(-)

Comments

Uwe Kleine-König May 3, 2023, 8:24 p.m. UTC | #1
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
Heiner Kallweit May 15, 2023, 8:32 p.m. UTC | #2
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.
Martin Blumenstingl May 23, 2023, 8:51 p.m. UTC | #3
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, ...).
Heiner Kallweit May 24, 2023, 7:11 p.m. UTC | #4
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 mbox series

Patch

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;