[PATCH v11 01/12] drm/i915: Use 64-bit division macro

[PATCH v11 01/12] drm/i915: Use 64-bit division macro

[Guru Das Srinagesh]

Since the PWM framework is switching struct pwm_state.duty_cycle's
datatype to u64, prepare for this transition by using DIV_ROUND_UP_ULL
to handle a 64-bit dividend.

Cc: Jani Nikula <jani.nikula@linux.intel.com>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Cc: David Airlie <airlied@linux.ie>
Cc: Daniel Vetter <daniel@ffwll.ch>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: "Ville Syrjälä" <ville.syrjala@linux.intel.com>
Cc: intel-gfx@lists.freedesktop.org
Cc: dri-devel@lists.freedesktop.org

Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Guru Das Srinagesh <gurus@codeaurora.org>
---
 drivers/gpu/drm/i915/display/intel_panel.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/display/intel_panel.c b/drivers/gpu/drm/i915/display/intel_panel.c
index bc14e9c..843cac1 100644
--- a/drivers/gpu/drm/i915/display/intel_panel.c
+++ b/drivers/gpu/drm/i915/display/intel_panel.c
@@ -1868,7 +1868,7 @@ static int pwm_setup_backlight(struct intel_connector *connector,
 
 	panel->backlight.min = 0; /* 0% */
 	panel->backlight.max = 100; /* 100% */
-	panel->backlight.level = DIV_ROUND_UP(
+	panel->backlight.level = DIV_ROUND_UP_ULL(
 				 pwm_get_duty_cycle(panel->backlight.pwm) * 100,
 				 CRC_PMIC_PWM_PERIOD_NS);
 	panel->backlight.enabled = panel->backlight.level != 0;
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

[PATCH v11 02/12] hwmon: pwm-fan: Use 64-bit division macro

[Guru Das Srinagesh]

Since the PWM framework is switching struct pwm_args.period's datatype
to u64, prepare for this transition by using DIV_ROUND_UP_ULL to handle
a 64-bit dividend.

Cc: Kamil Debski <kamil@wypas.org>
Cc: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
Cc: Jean Delvare <jdelvare@suse.com>
Cc: Guenter Roeck <linux@roeck-us.net>
Cc: Liam Girdwood <lgirdwood@gmail.com>
Cc: Mark Brown <broonie@kernel.org>
Cc: linux-hwmon@vger.kernel.org

Signed-off-by: Guru Das Srinagesh <gurus@codeaurora.org>
Acked-by: Guenter Roeck <linux@roeck-us.net>
---
 drivers/hwmon/pwm-fan.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/hwmon/pwm-fan.c b/drivers/hwmon/pwm-fan.c
index 42ffd2e..283423a 100644
--- a/drivers/hwmon/pwm-fan.c
+++ b/drivers/hwmon/pwm-fan.c
@@ -437,7 +437,7 @@ static int pwm_fan_resume(struct device *dev)
 		return 0;
 
 	pwm_get_args(ctx->pwm, &pargs);
-	duty = DIV_ROUND_UP(ctx->pwm_value * (pargs.period - 1), MAX_PWM);
+	duty = DIV_ROUND_UP_ULL(ctx->pwm_value * (pargs.period - 1), MAX_PWM);
 	ret = pwm_config(ctx->pwm, duty, pargs.period);
 	if (ret)
 		return ret;
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

[PATCH v11 03/12] ir-rx51: Use 64-bit division macro

[Guru Das Srinagesh]

Since the PWM framework is switching struct pwm_state.period's datatype
to u64, prepare for this transition by using DIV_ROUND_CLOSEST_ULL to
handle a 64-bit dividend.

Cc: Mauro Carvalho Chehab <mchehab@kernel.org>
Cc: Richard Fontana <rfontana@redhat.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Kate Stewart <kstewart@linuxfoundation.org>
Cc: Allison Randal <allison@lohutok.net>
Cc: linux-media@vger.kernel.org

Signed-off-by: Guru Das Srinagesh <gurus@codeaurora.org>
Acked-by: Sean Young <sean@mess.org>
---
 drivers/media/rc/ir-rx51.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/media/rc/ir-rx51.c b/drivers/media/rc/ir-rx51.c
index 8574eda..9a5dfd7 100644
--- a/drivers/media/rc/ir-rx51.c
+++ b/drivers/media/rc/ir-rx51.c
@@ -241,7 +241,8 @@ static int ir_rx51_probe(struct platform_device *dev)
 	}
 
 	/* Use default, in case userspace does not set the carrier */
-	ir_rx51.freq = DIV_ROUND_CLOSEST(pwm_get_period(pwm), NSEC_PER_SEC);
+	ir_rx51.freq = DIV_ROUND_CLOSEST_ULL(pwm_get_period(pwm),
+			NSEC_PER_SEC);
 	pwm_put(pwm);
 
 	hrtimer_init(&ir_rx51.timer, CLOCK_MONOTONIC, HRTIMER_MODE_REL);
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

[PATCH v11 04/12] pwm: clps711x: Cast period to u32 before use as divisor

[Guru Das Srinagesh]

Since the PWM framework is switching struct pwm_args.period's datatype
to u64, prepare for this transition by typecasting it to u32.

Also, since the dividend is still a 32-bit number, any divisor greater
than UINT_MAX will cause the quotient to be zero, so return 0 in that
case to efficiently skip the division.

Cc: Alexander Shiyan <shc_work@mail.ru>
Cc: Arnd Bergmann <arnd@arndb.de>

Signed-off-by: Guru Das Srinagesh <gurus@codeaurora.org>
---
 drivers/pwm/pwm-clps711x.c | 5 ++++-
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/drivers/pwm/pwm-clps711x.c b/drivers/pwm/pwm-clps711x.c
index 924d39a..f34f1f3 100644
--- a/drivers/pwm/pwm-clps711x.c
+++ b/drivers/pwm/pwm-clps711x.c
@@ -43,7 +43,10 @@ static void clps711x_pwm_update_val(struct clps711x_chip *priv, u32 n, u32 v)
 static unsigned int clps711x_get_duty(struct pwm_device *pwm, unsigned int v)
 {
 	/* Duty cycle 0..15 max */
-	return DIV_ROUND_CLOSEST(v * 0xf, pwm->args.period);
+	if (pwm->args.period > UINT_MAX)
+		return 0;
+
+	return DIV_ROUND_CLOSEST(v * 0xf, (u32)pwm->args.period);
 }
 
 static int clps711x_pwm_request(struct pwm_chip *chip, struct pwm_device *pwm)
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

[PATCH v11 05/12] pwm: pwm-imx-tpm: Use 64-bit division macro

[Guru Das Srinagesh]

Since the PWM framework is switching struct pwm_state.period's datatype
to u64, prepare for this transition by using DIV64_U64_ROUND_CLOSEST to
handle a 64-bit divisor.

Cc: Shawn Guo <shawnguo@kernel.org>
Cc: Sascha Hauer <s.hauer@pengutronix.de>
Cc: Pengutronix Kernel Team <kernel@pengutronix.de>
Cc: Fabio Estevam <festevam@gmail.com>
Cc: NXP Linux Team <linux-imx@nxp.com>

Signed-off-by: Guru Das Srinagesh <gurus@codeaurora.org>
---
 drivers/pwm/pwm-imx-tpm.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/pwm/pwm-imx-tpm.c b/drivers/pwm/pwm-imx-tpm.c
index 9145f61..53bf364 100644
--- a/drivers/pwm/pwm-imx-tpm.c
+++ b/drivers/pwm/pwm-imx-tpm.c
@@ -126,7 +126,7 @@ static int pwm_imx_tpm_round_state(struct pwm_chip *chip,
 		real_state->duty_cycle = state->duty_cycle;
 
 	tmp = (u64)p->mod * real_state->duty_cycle;
-	p->val = DIV_ROUND_CLOSEST_ULL(tmp, real_state->period);
+	p->val = DIV64_U64_ROUND_CLOSEST(tmp, real_state->period);
 
 	real_state->polarity = state->polarity;
 	real_state->enabled = state->enabled;
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

[PATCH v11 06/12] pwm: imx27: Use 64-bit division macro and function

[Guru Das Srinagesh]

Since the PWM framework is switching struct pwm_state.period's
datatype to u64, prepare for this transition by using
DIV_ROUND_UP_ULL to handle a 64-bit dividend, and div64_u64 to handle a
64-bit divisor.

Cc: Shawn Guo <shawnguo@kernel.org>
Cc: Sascha Hauer <s.hauer@pengutronix.de>
Cc: Pengutronix Kernel Team <kernel@pengutronix.de>
Cc: Fabio Estevam <festevam@gmail.com>
Cc: NXP Linux Team <linux-imx@nxp.com>

Signed-off-by: Guru Das Srinagesh <gurus@codeaurora.org>
---
 drivers/pwm/pwm-imx27.c | 5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/drivers/pwm/pwm-imx27.c b/drivers/pwm/pwm-imx27.c
index 35a7ac42..b7d38d0 100644
--- a/drivers/pwm/pwm-imx27.c
+++ b/drivers/pwm/pwm-imx27.c
@@ -208,7 +208,7 @@ static void pwm_imx27_wait_fifo_slot(struct pwm_chip *chip,
 	sr = readl(imx->mmio_base + MX3_PWMSR);
 	fifoav = FIELD_GET(MX3_PWMSR_FIFOAV, sr);
 	if (fifoav == MX3_PWMSR_FIFOAV_4WORDS) {
-		period_ms = DIV_ROUND_UP(pwm_get_period(pwm),
+		period_ms = DIV_ROUND_UP_ULL(pwm_get_period(pwm),
 					 NSEC_PER_MSEC);
 		msleep(period_ms);
 
@@ -240,8 +240,7 @@ static int pwm_imx27_apply(struct pwm_chip *chip, struct pwm_device *pwm,
 
 	period_cycles /= prescale;
 	c = (unsigned long long)period_cycles * state->duty_cycle;
-	do_div(c, state->period);
-	duty_cycles = c;
+	duty_cycles = div64_u64(c, state->period);
 
 	/*
 	 * according to imx pwm RM, the real period value should be PERIOD
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

[PATCH v11 07/12] pwm: sifive: Use 64-bit division macro

[Guru Das Srinagesh]

Since the PWM framework is switching struct pwm_args.period's datatype
to u64, prepare for this transition by using DIV64_U64_ROUND_CLOSEST to
handle a 64-bit divisor.

Cc: Palmer Dabbelt <palmer@dabbelt.com>
Cc: Paul Walmsley <paul.walmsley@sifive.com>
Cc: linux-riscv@lists.infradead.org
Cc: Yash Shah <yash.shah@sifive.com>
Cc: Atish Patra <atish.patra@wdc.com>

Signed-off-by: Guru Das Srinagesh <gurus@codeaurora.org>
---
 drivers/pwm/pwm-sifive.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/pwm/pwm-sifive.c b/drivers/pwm/pwm-sifive.c
index cc63f9b..62de0bb 100644
--- a/drivers/pwm/pwm-sifive.c
+++ b/drivers/pwm/pwm-sifive.c
@@ -181,7 +181,7 @@ static int pwm_sifive_apply(struct pwm_chip *chip, struct pwm_device *pwm,
 	 * consecutively
 	 */
 	num = (u64)duty_cycle * (1U << PWM_SIFIVE_CMPWIDTH);
-	frac = DIV_ROUND_CLOSEST_ULL(num, state->period);
+	frac = DIV64_U64_ROUND_CLOSEST(num, state->period);
 	/* The hardware cannot generate a 100% duty cycle */
 	frac = min(frac, (1U << PWM_SIFIVE_CMPWIDTH) - 1);
 
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

[PATCH v11 08/12] pwm: stm32-lp: Use %llu format specifier for period

[Guru Das Srinagesh]

Since the PWM framework is switching struct pwm_args.period's
datatype to u64, prepare for this transition by using the right
specifier for printing a 64-bit value.

Cc: Fabrice Gasnier <fabrice.gasnier@st.com>
Cc: Maxime Coquelin <mcoquelin.stm32@gmail.com>
Cc: Alexandre Torgue <alexandre.torgue@st.com>

Reported-by: kbuild test robot <lkp@intel.com>
Signed-off-by: Guru Das Srinagesh <gurus@codeaurora.org>
---
 drivers/pwm/pwm-stm32-lp.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/pwm/pwm-stm32-lp.c b/drivers/pwm/pwm-stm32-lp.c
index 67fca62..134c146 100644
--- a/drivers/pwm/pwm-stm32-lp.c
+++ b/drivers/pwm/pwm-stm32-lp.c
@@ -61,7 +61,7 @@ static int stm32_pwm_lp_apply(struct pwm_chip *chip, struct pwm_device *pwm,
 	do_div(div, NSEC_PER_SEC);
 	if (!div) {
 		/* Clock is too slow to achieve requested period. */
-		dev_dbg(priv->chip.dev, "Can't reach %u ns\n",	state->period);
+		dev_dbg(priv->chip.dev, "Can't reach %llu ns\n", state->period);
 		return -EINVAL;
 	}
 
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

[PATCH v11 09/12] pwm: sun4i: Use 64-bit division function

[Guru Das Srinagesh]

Since the PWM framework is switching struct pwm_state.period's datatype
to u64, prepare for this transition by using div_u64 to handle a 64-bit
dividend instead of a straight division operation.

Cc: Maxime Ripard <mripard@kernel.org>
Cc: Chen-Yu Tsai <wens@csie.org>
Cc: Philipp Zabel <p.zabel@pengutronix.de>

Signed-off-by: Guru Das Srinagesh <gurus@codeaurora.org>
Acked-by: Chen-Yu Tsai <wens@csie.org>
---
 drivers/pwm/pwm-sun4i.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/pwm/pwm-sun4i.c b/drivers/pwm/pwm-sun4i.c
index 3e3efa6..772fdf4 100644
--- a/drivers/pwm/pwm-sun4i.c
+++ b/drivers/pwm/pwm-sun4i.c
@@ -286,7 +286,7 @@ static int sun4i_pwm_apply(struct pwm_chip *chip, struct pwm_device *pwm,
 	val = (duty & PWM_DTY_MASK) | PWM_PRD(period);
 	sun4i_pwm_writel(sun4i_pwm, val, PWM_CH_PRD(pwm->hwpwm));
 	sun4i_pwm->next_period[pwm->hwpwm] = jiffies +
-		usecs_to_jiffies(cstate.period / 1000 + 1);
+		usecs_to_jiffies(div_u64(cstate.period, 1000) + 1);
 	sun4i_pwm->needs_delay[pwm->hwpwm] = true;
 
 	if (state->polarity != PWM_POLARITY_NORMAL)
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

[PATCH v11 10/12] backlight: pwm_bl: Use 64-bit division function

[Guru Das Srinagesh]

Since the PWM framework is switching struct pwm_state.period's datatype
to u64, prepare for this transition by using div_u64 to handle a 64-bit
dividend instead of a straight division operation.

Cc: Lee Jones <lee.jones@linaro.org>
Cc: Daniel Thompson <daniel.thompson@linaro.org>
Cc: Jingoo Han <jingoohan1@gmail.com>
Cc: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
Cc: linux-pwm@vger.kernel.org
Cc: dri-devel@lists.freedesktop.org
Cc: linux-fbdev@vger.kernel.org

Signed-off-by: Guru Das Srinagesh <gurus@codeaurora.org>
Reviewed-by: Daniel Thompson <daniel.thompson@linaro.org>
---
 drivers/video/backlight/pwm_bl.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/video/backlight/pwm_bl.c b/drivers/video/backlight/pwm_bl.c
index efb4efc..3e5dbcf 100644
--- a/drivers/video/backlight/pwm_bl.c
+++ b/drivers/video/backlight/pwm_bl.c
@@ -625,7 +625,8 @@ static int pwm_backlight_probe(struct platform_device *pdev)
 		pb->scale = data->max_brightness;
 	}
 
-	pb->lth_brightness = data->lth_brightness * (state.period / pb->scale);
+	pb->lth_brightness = data->lth_brightness * (div_u64(state.period,
+				pb->scale));
 
 	props.type = BACKLIGHT_RAW;
 	props.max_brightness = data->max_brightness;
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

[PATCH v11 11/12] clk: pwm: Assign u64 divisor to unsigned int before use

[Guru Das Srinagesh]

Since the PWM framework is switching struct pwm_args.period's datatype
to u64, prepare for this transition by assigning the 64-bit divisor to
an unsigned int variable to use as the divisor. This is being done
because the divisor is a 32-bit constant and the quotient will be zero
if the divisor exceeds 2^32.

Cc: Michael Turquette <mturquette@baylibre.com>
Cc: Stephen Boyd <sboyd@kernel.org>
Cc: linux-clk@vger.kernel.org
Cc: David Laight <David.Laight@ACULAB.COM>

Reported-by: kbuild test robot <lkp@intel.com>
Signed-off-by: Guru Das Srinagesh <gurus@codeaurora.org>
---
 drivers/clk/clk-pwm.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/clk/clk-pwm.c b/drivers/clk/clk-pwm.c
index 87fe0b0e..c0b5da3 100644
--- a/drivers/clk/clk-pwm.c
+++ b/drivers/clk/clk-pwm.c
@@ -72,6 +72,7 @@ static int clk_pwm_probe(struct platform_device *pdev)
 	struct pwm_device *pwm;
 	struct pwm_args pargs;
 	const char *clk_name;
+	unsigned int period;
 	int ret;
 
 	clk_pwm = devm_kzalloc(&pdev->dev, sizeof(*clk_pwm), GFP_KERNEL);
@@ -88,8 +89,9 @@ static int clk_pwm_probe(struct platform_device *pdev)
 		return -EINVAL;
 	}
 
+	period = pargs.period;
 	if (of_property_read_u32(node, "clock-frequency", &clk_pwm->fixed_rate))
-		clk_pwm->fixed_rate = NSEC_PER_SEC / pargs.period;
+		clk_pwm->fixed_rate = NSEC_PER_SEC / period;
 
 	if (pargs.period != NSEC_PER_SEC / clk_pwm->fixed_rate &&
 	    pargs.period != DIV_ROUND_UP(NSEC_PER_SEC, clk_pwm->fixed_rate)) {
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

[PATCH v11 12/12] pwm: core: Convert period and duty cycle to u64

[Guru Das Srinagesh]

Because period and duty cycle are defined as ints with units of
nanoseconds, the maximum time duration that can be set is limited to
~2.147 seconds. Change their definitions to u64 in the structs of the
PWM framework so that higher durations may be set.

Signed-off-by: Guru Das Srinagesh <gurus@codeaurora.org>
---
 drivers/pwm/core.c  |  4 ++--
 drivers/pwm/sysfs.c |  8 ++++----
 include/linux/pwm.h | 12 ++++++------
 3 files changed, 12 insertions(+), 12 deletions(-)

diff --git a/drivers/pwm/core.c b/drivers/pwm/core.c
index 5a7f659..81aa3c2 100644
--- a/drivers/pwm/core.c
+++ b/drivers/pwm/core.c
@@ -1163,8 +1163,8 @@ static void pwm_dbg_show(struct pwm_chip *chip, struct seq_file *s)
 		if (state.enabled)
 			seq_puts(s, " enabled");
 
-		seq_printf(s, " period: %u ns", state.period);
-		seq_printf(s, " duty: %u ns", state.duty_cycle);
+		seq_printf(s, " period: %llu ns", state.period);
+		seq_printf(s, " duty: %llu ns", state.duty_cycle);
 		seq_printf(s, " polarity: %s",
 			   state.polarity ? "inverse" : "normal");
 
diff --git a/drivers/pwm/sysfs.c b/drivers/pwm/sysfs.c
index 2389b86..449dbc0 100644
--- a/drivers/pwm/sysfs.c
+++ b/drivers/pwm/sysfs.c
@@ -42,7 +42,7 @@ static ssize_t period_show(struct device *child,
 
 	pwm_get_state(pwm, &state);
 
-	return sprintf(buf, "%u\n", state.period);
+	return sprintf(buf, "%llu\n", state.period);
 }
 
 static ssize_t period_store(struct device *child,
@@ -52,10 +52,10 @@ static ssize_t period_store(struct device *child,
 	struct pwm_export *export = child_to_pwm_export(child);
 	struct pwm_device *pwm = export->pwm;
 	struct pwm_state state;
-	unsigned int val;
+	u64 val;
 	int ret;
 
-	ret = kstrtouint(buf, 0, &val);
+	ret = kstrtou64(buf, 0, &val);
 	if (ret)
 		return ret;
 
@@ -77,7 +77,7 @@ static ssize_t duty_cycle_show(struct device *child,
 
 	pwm_get_state(pwm, &state);
 
-	return sprintf(buf, "%u\n", state.duty_cycle);
+	return sprintf(buf, "%llu\n", state.duty_cycle);
 }
 
 static ssize_t duty_cycle_store(struct device *child,
diff --git a/include/linux/pwm.h b/include/linux/pwm.h
index 0ef808d..b53f13d 100644
--- a/include/linux/pwm.h
+++ b/include/linux/pwm.h
@@ -39,7 +39,7 @@ enum pwm_polarity {
  * current PWM hardware state.
  */
 struct pwm_args {
-	unsigned int period;
+	u64 period;
 	enum pwm_polarity polarity;
 };
 
@@ -56,8 +56,8 @@ enum {
  * @enabled: PWM enabled status
  */
 struct pwm_state {
-	unsigned int period;
-	unsigned int duty_cycle;
+	u64 period;
+	u64 duty_cycle;
 	enum pwm_polarity polarity;
 	bool enabled;
 };
@@ -105,13 +105,13 @@ static inline bool pwm_is_enabled(const struct pwm_device *pwm)
 	return state.enabled;
 }
 
-static inline void pwm_set_period(struct pwm_device *pwm, unsigned int period)
+static inline void pwm_set_period(struct pwm_device *pwm, u64 period)
 {
 	if (pwm)
 		pwm->state.period = period;
 }
 
-static inline unsigned int pwm_get_period(const struct pwm_device *pwm)
+static inline u64 pwm_get_period(const struct pwm_device *pwm)
 {
 	struct pwm_state state;
 
@@ -126,7 +126,7 @@ static inline void pwm_set_duty_cycle(struct pwm_device *pwm, unsigned int duty)
 		pwm->state.duty_cycle = duty;
 }
 
-static inline unsigned int pwm_get_duty_cycle(const struct pwm_device *pwm)
+static inline u64 pwm_get_duty_cycle(const struct pwm_device *pwm)
 {
 	struct pwm_state state;
 
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

Re: [PATCH v11 08/12] pwm: stm32-lp: Use %llu format specifier for period

[Joe Perches]

On Thu, 2020-03-19 at 18:41 -0700, Guru Das Srinagesh wrote:
> Since the PWM framework is switching struct pwm_args.period's
> datatype to u64, prepare for this transition by using the right
> specifier for printing a 64-bit value.
[]
> diff --git a/drivers/pwm/pwm-stm32-lp.c b/drivers/pwm/pwm-stm32-lp.c
[]
> @@ -61,7 +61,7 @@ static int stm32_pwm_lp_apply(struct pwm_chip *chip, struct pwm_device *pwm,
>  	do_div(div, NSEC_PER_SEC);
>  	if (!div) {
>  		/* Clock is too slow to achieve requested period. */
> -		dev_dbg(priv->chip.dev, "Can't reach %u ns\n",	state->period);
> +		dev_dbg(priv->chip.dev, "Can't reach %llu ns\n", state->period);
>  		return -EINVAL;
>  	}

Doesn't this introduce a warning now without the
actual change to the type of state->period?

Likely these patches should either not be separated
or this should also use a cast to avoid introducing
intermediate compilation warnings.

Re: [PATCH v11 10/12] backlight: pwm_bl: Use 64-bit division function

[Lee Jones]

On Thu, 19 Mar 2020, Guru Das Srinagesh wrote:

> Since the PWM framework is switching struct pwm_state.period's datatype
> to u64, prepare for this transition by using div_u64 to handle a 64-bit
> dividend instead of a straight division operation.
> 
> Cc: Lee Jones <lee.jones@linaro.org>
> Cc: Daniel Thompson <daniel.thompson@linaro.org>
> Cc: Jingoo Han <jingoohan1@gmail.com>
> Cc: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
> Cc: linux-pwm@vger.kernel.org
> Cc: dri-devel@lists.freedesktop.org
> Cc: linux-fbdev@vger.kernel.org
> 
> Signed-off-by: Guru Das Srinagesh <gurus@codeaurora.org>
> Reviewed-by: Daniel Thompson <daniel.thompson@linaro.org>
> ---
>  drivers/video/backlight/pwm_bl.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)

Can this patch be taken on its own?

> diff --git a/drivers/video/backlight/pwm_bl.c b/drivers/video/backlight/pwm_bl.c
> index efb4efc..3e5dbcf 100644
> --- a/drivers/video/backlight/pwm_bl.c
> +++ b/drivers/video/backlight/pwm_bl.c
> @@ -625,7 +625,8 @@ static int pwm_backlight_probe(struct platform_device *pdev)
>  		pb->scale = data->max_brightness;
>  	}
>  
> -	pb->lth_brightness = data->lth_brightness * (state.period / pb->scale);
> +	pb->lth_brightness = data->lth_brightness * (div_u64(state.period,
> +				pb->scale));
>  
>  	props.type = BACKLIGHT_RAW;
>  	props.max_brightness = data->max_brightness;

-- 
Lee Jones [李琼斯]
Linaro Services Technical Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog

Re: [PATCH v11 11/12] clk: pwm: Assign u64 divisor to unsigned int before use

[Arnd Bergmann]

On Fri, Mar 20, 2020 at 2:42 AM Guru Das Srinagesh <gurus@codeaurora.org> wrote:
>
> Since the PWM framework is switching struct pwm_args.period's datatype
> to u64, prepare for this transition by assigning the 64-bit divisor to
> an unsigned int variable to use as the divisor. This is being done
> because the divisor is a 32-bit constant and the quotient will be zero
> if the divisor exceeds 2^32.
>
> Cc: Michael Turquette <mturquette@baylibre.com>
> Cc: Stephen Boyd <sboyd@kernel.org>
> Cc: linux-clk@vger.kernel.org
> Cc: David Laight <David.Laight@ACULAB.COM>
>
> Reported-by: kbuild test robot <lkp@intel.com>
> Signed-off-by: Guru Das Srinagesh <gurus@codeaurora.org>
> ---
>  drivers/clk/clk-pwm.c | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/clk/clk-pwm.c b/drivers/clk/clk-pwm.c
> index 87fe0b0e..c0b5da3 100644
> --- a/drivers/clk/clk-pwm.c
> +++ b/drivers/clk/clk-pwm.c
> @@ -72,6 +72,7 @@ static int clk_pwm_probe(struct platform_device *pdev)
>         struct pwm_device *pwm;
>         struct pwm_args pargs;
>         const char *clk_name;
> +       unsigned int period;
>         int ret;
>
>         clk_pwm = devm_kzalloc(&pdev->dev, sizeof(*clk_pwm), GFP_KERNEL);
> @@ -88,8 +89,9 @@ static int clk_pwm_probe(struct platform_device *pdev)
>                 return -EINVAL;
>         }
>
> +       period = pargs.period;
>         if (of_property_read_u32(node, "clock-frequency", &clk_pwm->fixed_rate))
> -               clk_pwm->fixed_rate = NSEC_PER_SEC / pargs.period;
> +               clk_pwm->fixed_rate = NSEC_PER_SEC / period;
>
>         if (pargs.period != NSEC_PER_SEC / clk_pwm->fixed_rate &&
>             pargs.period != DIV_ROUND_UP(NSEC_PER_SEC, clk_pwm->fixed_rate)) {

Doesn't this one need a check for "pargs.period>UINT_MAX" or
"pargs.period > NSEC_PER_SEC"?

It looks like truncating the 64-bit value to a 32-bit type can result in
unexpected behavior.

       Arnd

Re: [PATCH v11 09/12] pwm: sun4i: Use 64-bit division function

[Arnd Bergmann]

On Fri, Mar 20, 2020 at 2:42 AM Guru Das Srinagesh <gurus@codeaurora.org> wrote:
>         sun4i_pwm->next_period[pwm->hwpwm] = jiffies +
> -               usecs_to_jiffies(cstate.period / 1000 + 1);
> +               usecs_to_jiffies(div_u64(cstate.period, 1000) + 1);
>         sun4i_pwm->needs_delay[pwm->hwpwm] = true;
>

This one looks like it should use nsecs_to_jiffies(cstate.period) to avoid
having two 64-bit divisions.

       Arnd

Re: [PATCH v11 06/12] pwm: imx27: Use 64-bit division macro and function

[Arnd Bergmann]

On Fri, Mar 20, 2020 at 2:42 AM Guru Das Srinagesh <gurus@codeaurora.org> wrote:

> @@ -240,8 +240,7 @@ static int pwm_imx27_apply(struct pwm_chip *chip, struct pwm_device *pwm,
>
>         period_cycles /= prescale;
>         c = (unsigned long long)period_cycles * state->duty_cycle;
> -       do_div(c, state->period);
> -       duty_cycles = c;
> +       duty_cycles = div64_u64(c, state->period);
>

This change looks fine, but I wonder if the code directly above it

        c = clk_get_rate(imx->clk_per);
        c *= state->period;
        do_div(c, 1000000000);
        period_cycles = c;

might run into an overflow when both the clock rate and the period
are large numbers.

      Arnd

Re: [PATCH v11 04/12] pwm: clps711x: Cast period to u32 before use as divisor

[Arnd Bergmann]

On Fri, Mar 20, 2020 at 2:41 AM Guru Das Srinagesh <gurus@codeaurora.org> wrote:
>
> Since the PWM framework is switching struct pwm_args.period's datatype
> to u64, prepare for this transition by typecasting it to u32.
>
> Also, since the dividend is still a 32-bit number, any divisor greater
> than UINT_MAX will cause the quotient to be zero, so return 0 in that
> case to efficiently skip the division.
>
> Cc: Alexander Shiyan <shc_work@mail.ru>
> Cc: Arnd Bergmann <arnd@arndb.de>
>
> Signed-off-by: Guru Das Srinagesh <gurus@codeaurora.org>

Reviewed-by: Arnd Bergmann <arnd@arndb.de>

RE: [PATCH v11 11/12] clk: pwm: Assign u64 divisor to unsigned int before use

[David Laight]

From: Arnd Bergmann
> Sent: 20 March 2020 17:01
> On Fri, Mar 20, 2020 at 2:42 AM Guru Das Srinagesh <gurus@codeaurora.org> wrote:
> >
> > Since the PWM framework is switching struct pwm_args.period's datatype
> > to u64, prepare for this transition by assigning the 64-bit divisor to
> > an unsigned int variable to use as the divisor. This is being done
> > because the divisor is a 32-bit constant and the quotient will be zero
> > if the divisor exceeds 2^32.
> >
> > Cc: Michael Turquette <mturquette@baylibre.com>
> > Cc: Stephen Boyd <sboyd@kernel.org>
> > Cc: linux-clk@vger.kernel.org
> > Cc: David Laight <David.Laight@ACULAB.COM>
> >
> > Reported-by: kbuild test robot <lkp@intel.com>
> > Signed-off-by: Guru Das Srinagesh <gurus@codeaurora.org>
> > ---
> >  drivers/clk/clk-pwm.c | 4 +++-
> >  1 file changed, 3 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/clk/clk-pwm.c b/drivers/clk/clk-pwm.c
> > index 87fe0b0e..c0b5da3 100644
> > --- a/drivers/clk/clk-pwm.c
> > +++ b/drivers/clk/clk-pwm.c
> > @@ -72,6 +72,7 @@ static int clk_pwm_probe(struct platform_device *pdev)
> >         struct pwm_device *pwm;
> >         struct pwm_args pargs;
> >         const char *clk_name;
> > +       unsigned int period;
> >         int ret;
> >
> >         clk_pwm = devm_kzalloc(&pdev->dev, sizeof(*clk_pwm), GFP_KERNEL);
> > @@ -88,8 +89,9 @@ static int clk_pwm_probe(struct platform_device *pdev)
> >                 return -EINVAL;
> >         }
> >
> > +       period = pargs.period;
> >         if (of_property_read_u32(node, "clock-frequency", &clk_pwm->fixed_rate))
> > -               clk_pwm->fixed_rate = NSEC_PER_SEC / pargs.period;
> > +               clk_pwm->fixed_rate = NSEC_PER_SEC / period;
> >
> >         if (pargs.period != NSEC_PER_SEC / clk_pwm->fixed_rate &&
> >             pargs.period != DIV_ROUND_UP(NSEC_PER_SEC, clk_pwm->fixed_rate)) {
> 
> Doesn't this one need a check for "pargs.period>UINT_MAX" or
> "pargs.period > NSEC_PER_SEC"?
> 
> It looks like truncating the 64-bit value to a 32-bit type can result in
> unexpected behavior.

I also suspect the last two lines ought to use the 32bit copy.
And there is a chance that the division will explode.

This whole series is failing to differentiate between the type of
the variables and the domain on the valid values.

	David

-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)

Re: [PATCH v11 10/12] backlight: pwm_bl: Use 64-bit division function

[Lee Jones]

On Fri, 20 Mar 2020, Lee Jones wrote:

> On Thu, 19 Mar 2020, Guru Das Srinagesh wrote:
> 
> > Since the PWM framework is switching struct pwm_state.period's datatype
> > to u64, prepare for this transition by using div_u64 to handle a 64-bit
> > dividend instead of a straight division operation.
> > 
> > Cc: Lee Jones <lee.jones@linaro.org>
> > Cc: Daniel Thompson <daniel.thompson@linaro.org>
> > Cc: Jingoo Han <jingoohan1@gmail.com>
> > Cc: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
> > Cc: linux-pwm@vger.kernel.org
> > Cc: dri-devel@lists.freedesktop.org
> > Cc: linux-fbdev@vger.kernel.org
> > 
> > Signed-off-by: Guru Das Srinagesh <gurus@codeaurora.org>
> > Reviewed-by: Daniel Thompson <daniel.thompson@linaro.org>
> > ---
> >  drivers/video/backlight/pwm_bl.c | 3 ++-
> >  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> Can this patch be taken on its own?

Hellooooo ...

> > diff --git a/drivers/video/backlight/pwm_bl.c b/drivers/video/backlight/pwm_bl.c
> > index efb4efc..3e5dbcf 100644
> > --- a/drivers/video/backlight/pwm_bl.c
> > +++ b/drivers/video/backlight/pwm_bl.c
> > @@ -625,7 +625,8 @@ static int pwm_backlight_probe(struct platform_device *pdev)
> >  		pb->scale = data->max_brightness;
> >  	}
> >  
> > -	pb->lth_brightness = data->lth_brightness * (state.period / pb->scale);
> > +	pb->lth_brightness = data->lth_brightness * (div_u64(state.period,
> > +				pb->scale));
> >  
> >  	props.type = BACKLIGHT_RAW;
> >  	props.max_brightness = data->max_brightness;
> 

-- 
Lee Jones [李琼斯]
Linaro Services Technical Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog

Re: [PATCH v11 10/12] backlight: pwm_bl: Use 64-bit division function

[Uwe Kleine-König]

Hello Lee,

On Tue, Mar 24, 2020 at 11:07:10AM +0000, Lee Jones wrote:
> On Fri, 20 Mar 2020, Lee Jones wrote:
> 
> > On Thu, 19 Mar 2020, Guru Das Srinagesh wrote:
> > 
> > > Since the PWM framework is switching struct pwm_state.period's datatype
> > > to u64, prepare for this transition by using div_u64 to handle a 64-bit
> > > dividend instead of a straight division operation.
> > > 
> > > Cc: Lee Jones <lee.jones@linaro.org>
> > > Cc: Daniel Thompson <daniel.thompson@linaro.org>
> > > Cc: Jingoo Han <jingoohan1@gmail.com>
> > > Cc: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
> > > Cc: linux-pwm@vger.kernel.org
> > > Cc: dri-devel@lists.freedesktop.org
> > > Cc: linux-fbdev@vger.kernel.org
> > > 
> > > Signed-off-by: Guru Das Srinagesh <gurus@codeaurora.org>
> > > Reviewed-by: Daniel Thompson <daniel.thompson@linaro.org>
> > > ---
> > >  drivers/video/backlight/pwm_bl.c | 3 ++-
> > >  1 file changed, 2 insertions(+), 1 deletion(-)
> > 
> > Can this patch be taken on its own?
> 
> Hellooooo ...

Conceptually it can. As the last patch depends on this one (and the
others) some coordination might be beneficial. But that's up to Thierry
to decide how (and if) he want this series to be applied.

Best regards
Uwe

-- 
Pengutronix e.K.                           | Uwe Kleine-König            |
Industrial Linux Solutions                 | https://www.pengutronix.de/ |

Re: [PATCH v11 10/12] backlight: pwm_bl: Use 64-bit division function

[Daniel Thompson]

On Tue, Mar 24, 2020 at 01:57:35PM +0100, Uwe Kleine-König wrote:
> Hello Lee,
> 
> On Tue, Mar 24, 2020 at 11:07:10AM +0000, Lee Jones wrote:
> > On Fri, 20 Mar 2020, Lee Jones wrote:
> > 
> > > On Thu, 19 Mar 2020, Guru Das Srinagesh wrote:
> > > 
> > > > Since the PWM framework is switching struct pwm_state.period's datatype
> > > > to u64, prepare for this transition by using div_u64 to handle a 64-bit
> > > > dividend instead of a straight division operation.
> > > > 
> > > > Cc: Lee Jones <lee.jones@linaro.org>
> > > > Cc: Daniel Thompson <daniel.thompson@linaro.org>
> > > > Cc: Jingoo Han <jingoohan1@gmail.com>
> > > > Cc: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
> > > > Cc: linux-pwm@vger.kernel.org
> > > > Cc: dri-devel@lists.freedesktop.org
> > > > Cc: linux-fbdev@vger.kernel.org
> > > > 
> > > > Signed-off-by: Guru Das Srinagesh <gurus@codeaurora.org>
> > > > Reviewed-by: Daniel Thompson <daniel.thompson@linaro.org>
> > > > ---
> > > >  drivers/video/backlight/pwm_bl.c | 3 ++-
> > > >  1 file changed, 2 insertions(+), 1 deletion(-)
> > > 
> > > Can this patch be taken on its own?
> > 
> > Hellooooo ...
> 
> Conceptually it can. As the last patch depends on this one (and the
> others) some coordination might be beneficial. But that's up to Thierry
> to decide how (and if) he want this series to be applied.

... and on the backlight side we definitely need to know about the "if"
otherwise there's no point in taking it.


Daniel.

Re: [PATCH v11 10/12] backlight: pwm_bl: Use 64-bit division function

[Lee Jones]

On Tue, 24 Mar 2020, Daniel Thompson wrote:

> On Tue, Mar 24, 2020 at 01:57:35PM +0100, Uwe Kleine-König wrote:
> > Hello Lee,
> > 
> > On Tue, Mar 24, 2020 at 11:07:10AM +0000, Lee Jones wrote:
> > > On Fri, 20 Mar 2020, Lee Jones wrote:
> > > 
> > > > On Thu, 19 Mar 2020, Guru Das Srinagesh wrote:
> > > > 
> > > > > Since the PWM framework is switching struct pwm_state.period's datatype
> > > > > to u64, prepare for this transition by using div_u64 to handle a 64-bit
> > > > > dividend instead of a straight division operation.
> > > > > 
> > > > > Cc: Lee Jones <lee.jones@linaro.org>
> > > > > Cc: Daniel Thompson <daniel.thompson@linaro.org>
> > > > > Cc: Jingoo Han <jingoohan1@gmail.com>
> > > > > Cc: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
> > > > > Cc: linux-pwm@vger.kernel.org
> > > > > Cc: dri-devel@lists.freedesktop.org
> > > > > Cc: linux-fbdev@vger.kernel.org
> > > > > 
> > > > > Signed-off-by: Guru Das Srinagesh <gurus@codeaurora.org>
> > > > > Reviewed-by: Daniel Thompson <daniel.thompson@linaro.org>
> > > > > ---
> > > > >  drivers/video/backlight/pwm_bl.c | 3 ++-
> > > > >  1 file changed, 2 insertions(+), 1 deletion(-)
> > > > 
> > > > Can this patch be taken on its own?
> > > 
> > > Hellooooo ...
> > 
> > Conceptually it can. As the last patch depends on this one (and the
> > others) some coordination might be beneficial. But that's up to Thierry
> > to decide how (and if) he want this series to be applied.
> 
> ... and on the backlight side we definitely need to know about the "if"
> otherwise there's no point in taking it.

Right.

I'm happy to wait for Thierry.  Although this isn't the only set he's
currently blocking.  Is he okay?  On holiday perhaps?

-- 
Lee Jones [李琼斯]
Linaro Services Technical Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog

Re: [PATCH v11 10/12] backlight: pwm_bl: Use 64-bit division function

[Uwe Kleine-König]

On Tue, Mar 24, 2020 at 02:24:41PM +0000, Lee Jones wrote:
> On Tue, 24 Mar 2020, Daniel Thompson wrote:
> 
> > On Tue, Mar 24, 2020 at 01:57:35PM +0100, Uwe Kleine-König wrote:
> > > Hello Lee,
> > > 
> > > On Tue, Mar 24, 2020 at 11:07:10AM +0000, Lee Jones wrote:
> > > > On Fri, 20 Mar 2020, Lee Jones wrote:
> > > > 
> > > > > On Thu, 19 Mar 2020, Guru Das Srinagesh wrote:
> > > > > 
> > > > > > Since the PWM framework is switching struct pwm_state.period's datatype
> > > > > > to u64, prepare for this transition by using div_u64 to handle a 64-bit
> > > > > > dividend instead of a straight division operation.
> > > > > > 
> > > > > > Cc: Lee Jones <lee.jones@linaro.org>
> > > > > > Cc: Daniel Thompson <daniel.thompson@linaro.org>
> > > > > > Cc: Jingoo Han <jingoohan1@gmail.com>
> > > > > > Cc: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
> > > > > > Cc: linux-pwm@vger.kernel.org
> > > > > > Cc: dri-devel@lists.freedesktop.org
> > > > > > Cc: linux-fbdev@vger.kernel.org
> > > > > > 
> > > > > > Signed-off-by: Guru Das Srinagesh <gurus@codeaurora.org>
> > > > > > Reviewed-by: Daniel Thompson <daniel.thompson@linaro.org>
> > > > > > ---
> > > > > >  drivers/video/backlight/pwm_bl.c | 3 ++-
> > > > > >  1 file changed, 2 insertions(+), 1 deletion(-)
> > > > > 
> > > > > Can this patch be taken on its own?
> > > > 
> > > > Hellooooo ...
> > > 
> > > Conceptually it can. As the last patch depends on this one (and the
> > > others) some coordination might be beneficial. But that's up to Thierry
> > > to decide how (and if) he want this series to be applied.
> > 
> > ... and on the backlight side we definitely need to know about the "if"
> > otherwise there's no point in taking it.
> 
> Right.
> 
> I'm happy to wait for Thierry.  Although this isn't the only set he's
> currently blocking.  Is he okay?  On holiday perhaps?

The newest commit by him in next is from last week. My guess is he
just didn't come around yet to care for the PWM duties.

Best regards
Uwe

-- 
Pengutronix e.K.                           | Uwe Kleine-König            |
Industrial Linux Solutions                 | https://www.pengutronix.de/ |

Re: [PATCH v11 08/12] pwm: stm32-lp: Use %llu format specifier for period

[Guru Das Srinagesh]

On Fri, Mar 20, 2020 at 03:45:35AM -0700, Joe Perches wrote:
> On Thu, 2020-03-19 at 18:41 -0700, Guru Das Srinagesh wrote:
> > Since the PWM framework is switching struct pwm_args.period's
> > datatype to u64, prepare for this transition by using the right
> > specifier for printing a 64-bit value.
> []
> > diff --git a/drivers/pwm/pwm-stm32-lp.c b/drivers/pwm/pwm-stm32-lp.c
> []
> > @@ -61,7 +61,7 @@ static int stm32_pwm_lp_apply(struct pwm_chip *chip, struct pwm_device *pwm,
> >  	do_div(div, NSEC_PER_SEC);
> >  	if (!div) {
> >  		/* Clock is too slow to achieve requested period. */
> > -		dev_dbg(priv->chip.dev, "Can't reach %u ns\n",	state->period);
> > +		dev_dbg(priv->chip.dev, "Can't reach %llu ns\n", state->period);
> >  		return -EINVAL;
> >  	}
> 
> Doesn't this introduce a warning now without the
> actual change to the type of state->period?

You're right, it does.

> Likely these patches should either not be separated
> or this should also use a cast to avoid introducing
> intermediate compilation warnings.

Only this patch has this specific issue, so I'll squish it with the
final patch in this series ("pwm: core: Convert period and duty cycle to
u64") that modifies the framework structs. Thanks for pointing this out.

Thank you.

Guru Das.

Re: [PATCH v11 06/12] pwm: imx27: Use 64-bit division macro and function

[Guru Das Srinagesh]

On Fri, Mar 20, 2020 at 06:09:39PM +0100, Arnd Bergmann wrote:
> On Fri, Mar 20, 2020 at 2:42 AM Guru Das Srinagesh <gurus@codeaurora.org> wrote:
> 
> > @@ -240,8 +240,7 @@ static int pwm_imx27_apply(struct pwm_chip *chip, struct pwm_device *pwm,
> >
> >         period_cycles /= prescale;
> >         c = (unsigned long long)period_cycles * state->duty_cycle;
> > -       do_div(c, state->period);
> > -       duty_cycles = c;
> > +       duty_cycles = div64_u64(c, state->period);
> >
> 
> This change looks fine, but I wonder if the code directly above it
> 
>         c = clk_get_rate(imx->clk_per);
>         c *= state->period;
>         do_div(c, 1000000000);
>         period_cycles = c;
> 
> might run into an overflow when both the clock rate and the period
> are large numbers.

Hmm. Seems to me like addressing this would be outside the scope of this
patch series.

Thank you.

Guru Das.

Re: [PATCH v11 06/12] pwm: imx27: Use 64-bit division macro and function

[Arnd Bergmann]

On Mon, Mar 30, 2020 at 10:44 PM Guru Das Srinagesh
<gurus@codeaurora.org> wrote:
>
> On Fri, Mar 20, 2020 at 06:09:39PM +0100, Arnd Bergmann wrote:
> > On Fri, Mar 20, 2020 at 2:42 AM Guru Das Srinagesh <gurus@codeaurora.org> wrote:
> >
> > > @@ -240,8 +240,7 @@ static int pwm_imx27_apply(struct pwm_chip *chip, struct pwm_device *pwm,
> > >
> > >         period_cycles /= prescale;
> > >         c = (unsigned long long)period_cycles * state->duty_cycle;
> > > -       do_div(c, state->period);
> > > -       duty_cycles = c;
> > > +       duty_cycles = div64_u64(c, state->period);
> > >
> >
> > This change looks fine, but I wonder if the code directly above it
> >
> >         c = clk_get_rate(imx->clk_per);
> >         c *= state->period;
> >         do_div(c, 1000000000);
> >         period_cycles = c;
> >
> > might run into an overflow when both the clock rate and the period
> > are large numbers.
>
> Hmm. Seems to me like addressing this would be outside the scope of this
> patch series.

I think it should be part of the same series, addressing bugs that
were introduced
by the change to 64-bit period. If it's not getting fixed along with
the other regressions,
I fear nobody is going to go back and fix it later.

      Arnd

Re: [PATCH v11 06/12] pwm: imx27: Use 64-bit division macro and function

[Guru Das Srinagesh]

On Tue, Mar 31, 2020 at 05:24:52PM +0200, Arnd Bergmann wrote:
> On Mon, Mar 30, 2020 at 10:44 PM Guru Das Srinagesh
> <gurus@codeaurora.org> wrote:
> >
> > On Fri, Mar 20, 2020 at 06:09:39PM +0100, Arnd Bergmann wrote:
> > > On Fri, Mar 20, 2020 at 2:42 AM Guru Das Srinagesh <gurus@codeaurora.org> wrote:
> > >
> > > > @@ -240,8 +240,7 @@ static int pwm_imx27_apply(struct pwm_chip *chip, struct pwm_device *pwm,
> > > >
> > > >         period_cycles /= prescale;
> > > >         c = (unsigned long long)period_cycles * state->duty_cycle;
> > > > -       do_div(c, state->period);
> > > > -       duty_cycles = c;
> > > > +       duty_cycles = div64_u64(c, state->period);
> > > >
> > >
> > > This change looks fine, but I wonder if the code directly above it
> > >
> > >         c = clk_get_rate(imx->clk_per);
> > >         c *= state->period;
> > >         do_div(c, 1000000000);
> > >         period_cycles = c;
> > >
> > > might run into an overflow when both the clock rate and the period
> > > are large numbers.
> >
> > Hmm. Seems to me like addressing this would be outside the scope of this
> > patch series.
> 
> I think it should be part of the same series, addressing bugs that
> were introduced
> by the change to 64-bit period. If it's not getting fixed along with
> the other regressions,
> I fear nobody is going to go back and fix it later.

Makes sense, I agree. Would this be an acceptable fix?

Instead of multiplying c and state->period first and then dividing by
10^9, first divide state->period by 10^9 and then multiply the quotient
of that division with c and assign it to period_cycles. Like so:

	c = clk_get_rate(imx->clk_per);
	c *= div_u64(state->period, 1000000000);
	period_cycles = c;

This should take care of overflow not happening because state->period is
converted from nanoseconds to seconds early on and so becomes a small
number.

Thank you.

Guru Das.

Re: [PATCH v11 06/12] pwm: imx27: Use 64-bit division macro and function

[Thierry Reding]

[-- Attachment #1: Type: text/plain, Size: 2184 bytes --]

On Tue, Mar 31, 2020 at 01:20:58PM -0700, Guru Das Srinagesh wrote:
> On Tue, Mar 31, 2020 at 05:24:52PM +0200, Arnd Bergmann wrote:
> > On Mon, Mar 30, 2020 at 10:44 PM Guru Das Srinagesh
> > <gurus@codeaurora.org> wrote:
> > >
> > > On Fri, Mar 20, 2020 at 06:09:39PM +0100, Arnd Bergmann wrote:
> > > > On Fri, Mar 20, 2020 at 2:42 AM Guru Das Srinagesh <gurus@codeaurora.org> wrote:
> > > >
> > > > > @@ -240,8 +240,7 @@ static int pwm_imx27_apply(struct pwm_chip *chip, struct pwm_device *pwm,
> > > > >
> > > > >         period_cycles /= prescale;
> > > > >         c = (unsigned long long)period_cycles * state->duty_cycle;
> > > > > -       do_div(c, state->period);
> > > > > -       duty_cycles = c;
> > > > > +       duty_cycles = div64_u64(c, state->period);
> > > > >
> > > >
> > > > This change looks fine, but I wonder if the code directly above it
> > > >
> > > >         c = clk_get_rate(imx->clk_per);
> > > >         c *= state->period;
> > > >         do_div(c, 1000000000);
> > > >         period_cycles = c;
> > > >
> > > > might run into an overflow when both the clock rate and the period
> > > > are large numbers.
> > >
> > > Hmm. Seems to me like addressing this would be outside the scope of this
> > > patch series.
> > 
> > I think it should be part of the same series, addressing bugs that
> > were introduced
> > by the change to 64-bit period. If it's not getting fixed along with
> > the other regressions,
> > I fear nobody is going to go back and fix it later.
> 
> Makes sense, I agree. Would this be an acceptable fix?
> 
> Instead of multiplying c and state->period first and then dividing by
> 10^9, first divide state->period by 10^9 and then multiply the quotient
> of that division with c and assign it to period_cycles. Like so:
> 
> 	c = clk_get_rate(imx->clk_per);
> 	c *= div_u64(state->period, 1000000000);
> 	period_cycles = c;
> 
> This should take care of overflow not happening because state->period is
> converted from nanoseconds to seconds early on and so becomes a small
> number.

Doesn't that mean that anything below a 1 second period will be clamped
to just 0?

Thierry

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [PATCH v11 06/12] pwm: imx27: Use 64-bit division macro and function

[Guru Das Srinagesh]

On Tue, Mar 31, 2020 at 10:49:29PM +0200, Thierry Reding wrote:
> On Tue, Mar 31, 2020 at 01:20:58PM -0700, Guru Das Srinagesh wrote:
> > On Tue, Mar 31, 2020 at 05:24:52PM +0200, Arnd Bergmann wrote:
> > > On Mon, Mar 30, 2020 at 10:44 PM Guru Das Srinagesh
> > > <gurus@codeaurora.org> wrote:
> > > >
> > > > On Fri, Mar 20, 2020 at 06:09:39PM +0100, Arnd Bergmann wrote:
> > > > > On Fri, Mar 20, 2020 at 2:42 AM Guru Das Srinagesh <gurus@codeaurora.org> wrote:
> > > > >
> > > > > > @@ -240,8 +240,7 @@ static int pwm_imx27_apply(struct pwm_chip *chip, struct pwm_device *pwm,
> > > > > >
> > > > > >         period_cycles /= prescale;
> > > > > >         c = (unsigned long long)period_cycles * state->duty_cycle;
> > > > > > -       do_div(c, state->period);
> > > > > > -       duty_cycles = c;
> > > > > > +       duty_cycles = div64_u64(c, state->period);
> > > > > >
> > > > >
> > > > > This change looks fine, but I wonder if the code directly above it
> > > > >
> > > > >         c = clk_get_rate(imx->clk_per);
> > > > >         c *= state->period;
> > > > >         do_div(c, 1000000000);
> > > > >         period_cycles = c;
> > > > >
> > > > > might run into an overflow when both the clock rate and the period
> > > > > are large numbers.
> > > >
> > > > Hmm. Seems to me like addressing this would be outside the scope of this
> > > > patch series.
> > > 
> > > I think it should be part of the same series, addressing bugs that
> > > were introduced
> > > by the change to 64-bit period. If it's not getting fixed along with
> > > the other regressions,
> > > I fear nobody is going to go back and fix it later.
> > 
> > Makes sense, I agree. Would this be an acceptable fix?
> > 
> > Instead of multiplying c and state->period first and then dividing by
> > 10^9, first divide state->period by 10^9 and then multiply the quotient
> > of that division with c and assign it to period_cycles. Like so:
> > 
> > 	c = clk_get_rate(imx->clk_per);
> > 	c *= div_u64(state->period, 1000000000);
> > 	period_cycles = c;
> > 
> > This should take care of overflow not happening because state->period is
> > converted from nanoseconds to seconds early on and so becomes a small
> > number.
> 
> Doesn't that mean that anything below a 1 second period will be clamped
> to just 0?

True. How about this then?

int pwm_imx27_calc_period_cycles(struct pwm_state state,
				 unsigned long clk_rate,
				 unsigned long *period_cycles)
{
	u64 c1, c2;

	c1 = clk_rate;
	c2 = state->period;
	if (c2 > c1) {
		c2 = c1;
		c1 = state->period;
	}

	if (!c1 || !c2) {
		pr_err("clk rate and period should be nonzero\n");
		return -EINVAL;
	}

	if (c2 <= div64_u64(U64_MAX, c1)) {
		c = c1 * c2;
		do_div(c, 1000000000);
	} else if (c2 <= div64_u64(U64_MAX, div64_u64(c1, 1000))) {
		do_div(c1, 1000);
		c = c1 * c2;
		do_div(c, 1000000);
	} else if (c2 <= div64_u64(U64_MAX, div64_u64(c1, 1000000))) {
		do_div(c1, 1000000);
		c = c1 * c2;
		do_div(c, 1000);
	} else if (c2 <= div64_u64(U64_MAX, div64_u64(c1, 1000000000))) {
		do_div(c1, 1000000000);
		c = c1 * c2;
	}

	*period_cycles = c;

	return 0;
}

...

ret = pwm_imx27_calc_period_cycles(state, clk_get_rate(imx->clk_per),
				   &period_cycles);
if (ret)
	return ret;

I unit tested this logic out by calculating period_cycles using both the
existing logic and the proposed one, and the results are as below.

--------------------------------------------------------------------------------
 clk_rate		period		  existing 	      proposed
--------------------------------------------------------------------------------
1000000000	18446744073709551615	 18446744072 	18446744073000000000
                      (U64_MAX)
--------------------------------------------------------------------------------
1000000000	     4294967291		 4294967291	    4294967291
--------------------------------------------------------------------------------

Overflow occurs in the first case with the existing logic, whereas the
proposed logic handles it correctly. As for the second case where there are
more typical values of period, the proposed logic handles that correctly
too.

Thank you.

Guru Das.

Re: [PATCH v11 06/12] pwm: imx27: Use 64-bit division macro and function

[Guru Das Srinagesh]

On Thu, Apr 02, 2020 at 01:16:54PM -0700, Guru Das Srinagesh wrote:
> On Tue, Mar 31, 2020 at 10:49:29PM +0200, Thierry Reding wrote:
> > On Tue, Mar 31, 2020 at 01:20:58PM -0700, Guru Das Srinagesh wrote:
> > > On Tue, Mar 31, 2020 at 05:24:52PM +0200, Arnd Bergmann wrote:
> > > > On Mon, Mar 30, 2020 at 10:44 PM Guru Das Srinagesh
> > > > <gurus@codeaurora.org> wrote:
> > > > >
> > > > > On Fri, Mar 20, 2020 at 06:09:39PM +0100, Arnd Bergmann wrote:
> > > > > > On Fri, Mar 20, 2020 at 2:42 AM Guru Das Srinagesh <gurus@codeaurora.org> wrote:
> > > > > >
> > > > > > > @@ -240,8 +240,7 @@ static int pwm_imx27_apply(struct pwm_chip *chip, struct pwm_device *pwm,
> > > > > > >
> > > > > > >         period_cycles /= prescale;
> > > > > > >         c = (unsigned long long)period_cycles * state->duty_cycle;
> > > > > > > -       do_div(c, state->period);
> > > > > > > -       duty_cycles = c;
> > > > > > > +       duty_cycles = div64_u64(c, state->period);
> > > > > > >
> > > > > >
> > > > > > This change looks fine, but I wonder if the code directly above it
> > > > > >
> > > > > >         c = clk_get_rate(imx->clk_per);
> > > > > >         c *= state->period;
> > > > > >         do_div(c, 1000000000);
> > > > > >         period_cycles = c;
> > > > > >
> > > > > > might run into an overflow when both the clock rate and the period
> > > > > > are large numbers.
> > > > >
> > > > > Hmm. Seems to me like addressing this would be outside the scope of this
> > > > > patch series.
> > > > 
> > > > I think it should be part of the same series, addressing bugs that
> > > > were introduced
> > > > by the change to 64-bit period. If it's not getting fixed along with
> > > > the other regressions,
> > > > I fear nobody is going to go back and fix it later.
> > > 
> > > Makes sense, I agree. Would this be an acceptable fix?
> > > 
> > > Instead of multiplying c and state->period first and then dividing by
> > > 10^9, first divide state->period by 10^9 and then multiply the quotient
> > > of that division with c and assign it to period_cycles. Like so:
> > > 
> > > 	c = clk_get_rate(imx->clk_per);
> > > 	c *= div_u64(state->period, 1000000000);
> > > 	period_cycles = c;
> > > 
> > > This should take care of overflow not happening because state->period is
> > > converted from nanoseconds to seconds early on and so becomes a small
> > > number.
> > 
> > Doesn't that mean that anything below a 1 second period will be clamped
> > to just 0?
> 
> True. How about this then?
> 
> int pwm_imx27_calc_period_cycles(struct pwm_state state,
> 				 unsigned long clk_rate,
> 				 unsigned long *period_cycles)
> {
> 	u64 c1, c2;
> 
> 	c1 = clk_rate;
> 	c2 = state->period;
> 	if (c2 > c1) {
> 		c2 = c1;
> 		c1 = state->period;
> 	}
> 
> 	if (!c1 || !c2) {
> 		pr_err("clk rate and period should be nonzero\n");
> 		return -EINVAL;
> 	}
> 
> 	if (c2 <= div64_u64(U64_MAX, c1)) {
> 		c = c1 * c2;
> 		do_div(c, 1000000000);
> 	} else if (c2 <= div64_u64(U64_MAX, div64_u64(c1, 1000))) {
> 		do_div(c1, 1000);
> 		c = c1 * c2;
> 		do_div(c, 1000000);
> 	} else if (c2 <= div64_u64(U64_MAX, div64_u64(c1, 1000000))) {
> 		do_div(c1, 1000000);
> 		c = c1 * c2;
> 		do_div(c, 1000);
> 	} else if (c2 <= div64_u64(U64_MAX, div64_u64(c1, 1000000000))) {
> 		do_div(c1, 1000000000);
> 		c = c1 * c2;
> 	}
> 
> 	*period_cycles = c;
> 
> 	return 0;
> }
> 
> ...
> 
> ret = pwm_imx27_calc_period_cycles(state, clk_get_rate(imx->clk_per),
> 				   &period_cycles);
> if (ret)
> 	return ret;
> 
> I unit tested this logic out by calculating period_cycles using both the
> existing logic and the proposed one, and the results are as below.
> 
> --------------------------------------------------------------------------------
>  clk_rate		period		  existing 	      proposed
> --------------------------------------------------------------------------------
> 1000000000	18446744073709551615	 18446744072 	18446744073000000000
>                       (U64_MAX)
> --------------------------------------------------------------------------------
> 1000000000	     4294967291		 4294967291	    4294967291
> --------------------------------------------------------------------------------
> 
> Overflow occurs in the first case with the existing logic, whereas the
> proposed logic handles it correctly. 

Well, not "correctly" exactly, but a best-effort attempt to handle the
overflow with som loss of precision.

Thank you.

Guru Das.

Re: [PATCH v11 06/12] pwm: imx27: Use 64-bit division macro and function

[Arnd Bergmann]

On Thu, Apr 2, 2020 at 10:16 PM Guru Das Srinagesh <gurus@codeaurora.org> wrote:
> On Tue, Mar 31, 2020 at 10:49:29PM +0200, Thierry Reding wrote:
> > Doesn't that mean that anything below a 1 second period will be clamped
> > to just 0?
>
> True. How about this then?
>
> int pwm_imx27_calc_period_cycles(struct pwm_state state,
>                                  unsigned long clk_rate,
>                                  unsigned long *period_cycles)
> {
>         u64 c1, c2;
>
>         c1 = clk_rate;
>         c2 = state->period;
>         if (c2 > c1) {
>                 c2 = c1;
>                 c1 = state->period;
>         }
>
>         if (!c1 || !c2) {
>                 pr_err("clk rate and period should be nonzero\n");
>                 return -EINVAL;
>         }
>
>         if (c2 <= div64_u64(U64_MAX, c1)) {
>                 c = c1 * c2;
>                 do_div(c, 1000000000);
>         } else if (c2 <= div64_u64(U64_MAX, div64_u64(c1, 1000))) {
>                 do_div(c1, 1000);
>                 c = c1 * c2;
>                 do_div(c, 1000000);
>         } else if (c2 <= div64_u64(U64_MAX, div64_u64(c1, 1000000))) {
>                 do_div(c1, 1000000);
>                 c = c1 * c2;
>                 do_div(c, 1000);
>         } else if (c2 <= div64_u64(U64_MAX, div64_u64(c1, 1000000000))) {
>                 do_div(c1, 1000000000);
>                 c = c1 * c2;
>         }
>
>         *period_cycles = c;
>
>         return 0;
> }
>
> ...
>
> ret = pwm_imx27_calc_period_cycles(state, clk_get_rate(imx->clk_per),
>                                    &period_cycles);
> if (ret)
>         return ret;
>
> I unit tested this logic out by calculating period_cycles using both the
> existing logic and the proposed one, and the results are as below.
>
> --------------------------------------------------------------------------------
>  clk_rate               period            existing            proposed
> --------------------------------------------------------------------------------
> 1000000000      18446744073709551615     18446744072    18446744073000000000
>                       (U64_MAX)
> --------------------------------------------------------------------------------
> 1000000000           4294967291          4294967291         4294967291
> --------------------------------------------------------------------------------
>
> Overflow occurs in the first case with the existing logic, whereas the
> proposed logic handles it correctly. As for the second case where there are
> more typical values of period, the proposed logic handles that correctly
> too.

This looks correct, but very expensive, and you don't really have to
go this far, given that c1 is guaranteed to be a 32-bit number, and
you divide by a constant in the end.

Why not do something like

#define SHIFT 41 /* arbitrarily picked, not too big, not too small */
#define MUL 2199 /* 2^SHIFT / NSEC_PER_SEC */
period_cycles = clk_get_rate(imx->clk_per) * ((state->period * MUL) >> SHIFT);

        Arnd

Re: [PATCH v11 06/12] pwm: imx27: Use 64-bit division macro and function

[Guru Das Srinagesh]

On Thu, Apr 02, 2020 at 11:16:22PM +0200, Arnd Bergmann wrote:
> This looks correct, but very expensive, and you don't really have to
> go this far, given that c1 is guaranteed to be a 32-bit number, and
> you divide by a constant in the end.
> 
> Why not do something like
> 
> #define SHIFT 41 /* arbitrarily picked, not too big, not too small */
> #define MUL 2199 /* 2^SHIFT / NSEC_PER_SEC */
> period_cycles = clk_get_rate(imx->clk_per) * ((state->period * MUL) >> SHIFT);

I have two concerns with this:

1. This actually results in the division by 1000010575.5125057 instead
   of NSECS_PER_SEC whereas both the existing as well as the proposed logic
   divide exactly by NSECS_PER_SEC.
2. What method shall be used to pick the SHIFT value? How is this to be
   chosen?

Also, this seems sort of similar to my initial attempt at this
problem, where period was being pre-divided prior to the multiplication,
which was (rightly) NACKed.

	c *= div_u64(state->period, 1000000000);

Thank you.

Guru Das.

Re: [PATCH v11 06/12] pwm: imx27: Use 64-bit division macro and function

[Arnd Bergmann]

On Fri, Apr 3, 2020 at 7:37 PM Guru Das Srinagesh <gurus@codeaurora.org> wrote:
>
> On Thu, Apr 02, 2020 at 11:16:22PM +0200, Arnd Bergmann wrote:
> > This looks correct, but very expensive, and you don't really have to
> > go this far, given that c1 is guaranteed to be a 32-bit number, and
> > you divide by a constant in the end.
> >
> > Why not do something like
> >
> > #define SHIFT 41 /* arbitrarily picked, not too big, not too small */
> > #define MUL 2199 /* 2^SHIFT / NSEC_PER_SEC */
> > period_cycles = clk_get_rate(imx->clk_per) * ((state->period * MUL) >> SHIFT);
>
> I have two concerns with this:
>
> 1. This actually results in the division by 1000010575.5125057 instead
>    of NSECS_PER_SEC whereas both the existing as well as the proposed logic
>    divide exactly by NSECS_PER_SEC.
> 2. What method shall be used to pick the SHIFT value? How is this to be
>    chosen?

I picked one that would result in a fairly accurate rounding and did not
seem too likely to overflow.

> Also, this seems sort of similar to my initial attempt at this
> problem, where period was being pre-divided prior to the multiplication,
> which was (rightly) NACKed.
>
>         c *= div_u64(state->period, 1000000000);

Ah, right, I did make the same mistake here. What I actually indended
was to do two separate shifts that add up to 41. I suppose there is also still
the fundamental problem that without bounds checking the calculation can
always overflow for large inputs.

       Arnd

Re: [PATCH v11 04/12] pwm: clps711x: Cast period to u32 before use as divisor

[Guru Das Srinagesh]

On Fri, Mar 20, 2020 at 06:11:42PM +0100, Arnd Bergmann wrote:
> On Fri, Mar 20, 2020 at 2:41 AM Guru Das Srinagesh <gurus@codeaurora.org> wrote:
> >
> > Since the PWM framework is switching struct pwm_args.period's datatype
> > to u64, prepare for this transition by typecasting it to u32.
> >
> > Also, since the dividend is still a 32-bit number, any divisor greater
> > than UINT_MAX will cause the quotient to be zero, so return 0 in that
> > case to efficiently skip the division.
> >
> > Cc: Alexander Shiyan <shc_work@mail.ru>
> > Cc: Arnd Bergmann <arnd@arndb.de>
> >
> > Signed-off-by: Guru Das Srinagesh <gurus@codeaurora.org>
> 
> Reviewed-by: Arnd Bergmann <arnd@arndb.de>

The stated aim of adding the if condition is to determine when the
division operation may be skipped as the quotient would be zero anyway
[1]. That said, I think the current if condition is incorrect. The
quotient would be zero only when the denominator of the division exceeds
(v * 0xf) and not UINT_MAX. In fact, UINT_MAX has no bearing on whether
the quotient becomes zero or not.

Therefore, the correct if condition should be:

-       return DIV_ROUND_CLOSEST(v * 0xf, pwm->args.period);
+       if ((u32)pwm->args.period > (v * 0xf))
+               return 0;
+
+       return DIV_ROUND_CLOSEST(v * 0xf, (u32)pwm->args.period);

What do you think?

[1] https://www.spinics.net/lists/linux-pwm/msg11908.html

Thank you.

Guru Das.

Re: [PATCH v11 11/12] clk: pwm: Assign u64 divisor to unsigned int before use

[Guru Das Srinagesh]

On Fri, Mar 20, 2020 at 06:42:39PM +0000, David Laight wrote:
> From: Arnd Bergmann
> > Sent: 20 March 2020 17:01
> > On Fri, Mar 20, 2020 at 2:42 AM Guru Das Srinagesh <gurus@codeaurora.org> wrote:
> > >
> > > Since the PWM framework is switching struct pwm_args.period's datatype
> > > to u64, prepare for this transition by assigning the 64-bit divisor to
> > > an unsigned int variable to use as the divisor. This is being done
> > > because the divisor is a 32-bit constant and the quotient will be zero
> > > if the divisor exceeds 2^32.

Correction: The quotient will be zero when the denominator exceeds the
numerator, i.e. NSECS_PER_SEC, and not U32_MAX. For this to happen, the
property "clock-frequency" must be specified to be more than
NSEC_PER_SEC, i.e. 1 GHz. Just observed that currently in the device
tree, all instances of this driver (compatible string "pwm-clock") are
setting this property to values within that limit.

> > >
> > > Cc: Michael Turquette <mturquette@baylibre.com>
> > > Cc: Stephen Boyd <sboyd@kernel.org>
> > > Cc: linux-clk@vger.kernel.org
> > > Cc: David Laight <David.Laight@ACULAB.COM>
> > >
> > > Reported-by: kbuild test robot <lkp@intel.com>
> > > Signed-off-by: Guru Das Srinagesh <gurus@codeaurora.org>
> > > ---
> > >  drivers/clk/clk-pwm.c | 4 +++-
> > >  1 file changed, 3 insertions(+), 1 deletion(-)
> > >
> > > diff --git a/drivers/clk/clk-pwm.c b/drivers/clk/clk-pwm.c
> > > index 87fe0b0e..c0b5da3 100644
> > > --- a/drivers/clk/clk-pwm.c
> > > +++ b/drivers/clk/clk-pwm.c
> > > @@ -72,6 +72,7 @@ static int clk_pwm_probe(struct platform_device *pdev)
> > >         struct pwm_device *pwm;
> > >         struct pwm_args pargs;
> > >         const char *clk_name;
> > > +       unsigned int period;
> > >         int ret;
> > >
> > >         clk_pwm = devm_kzalloc(&pdev->dev, sizeof(*clk_pwm), GFP_KERNEL);
> > > @@ -88,8 +89,9 @@ static int clk_pwm_probe(struct platform_device *pdev)
> > >                 return -EINVAL;
> > >         }
> > >
> > > +       period = pargs.period;
> > >         if (of_property_read_u32(node, "clock-frequency", &clk_pwm->fixed_rate))
> > > -               clk_pwm->fixed_rate = NSEC_PER_SEC / pargs.period;
> > > +               clk_pwm->fixed_rate = NSEC_PER_SEC / period;
> > >
> > >         if (pargs.period != NSEC_PER_SEC / clk_pwm->fixed_rate &&
> > >             pargs.period != DIV_ROUND_UP(NSEC_PER_SEC, clk_pwm->fixed_rate)) {
> > 
> > Doesn't this one need a check for "pargs.period>UINT_MAX" or
> > "pargs.period > NSEC_PER_SEC"?
> > 

With the assignment of period to unsigned int, wouldn't doing
s/pargs.period/period suffice?

Also, will add a check to ensure that clk_pwm->fixed_rate is non-zero. If it
is zero, fail probe.

> > It looks like truncating the 64-bit value to a 32-bit type can result in
> > unexpected behavior.
> 
> I also suspect the last two lines ought to use the 32bit copy.
> And there is a chance that the division will explode.

The check mentioned above will ensure that the division will not
explode.

What do you guys think?

Thank you.

Guru Das.

Re: [PATCH v11 10/12] backlight: pwm_bl: Use 64-bit division function

[Lee Jones]

On Tue, 24 Mar 2020, Uwe Kleine-König wrote:

> On Tue, Mar 24, 2020 at 02:24:41PM +0000, Lee Jones wrote:
> > On Tue, 24 Mar 2020, Daniel Thompson wrote:
> > 
> > > On Tue, Mar 24, 2020 at 01:57:35PM +0100, Uwe Kleine-König wrote:
> > > > Hello Lee,
> > > > 
> > > > On Tue, Mar 24, 2020 at 11:07:10AM +0000, Lee Jones wrote:
> > > > > On Fri, 20 Mar 2020, Lee Jones wrote:
> > > > > 
> > > > > > On Thu, 19 Mar 2020, Guru Das Srinagesh wrote:
> > > > > > 
> > > > > > > Since the PWM framework is switching struct pwm_state.period's datatype
> > > > > > > to u64, prepare for this transition by using div_u64 to handle a 64-bit
> > > > > > > dividend instead of a straight division operation.
> > > > > > > 
> > > > > > > Cc: Lee Jones <lee.jones@linaro.org>
> > > > > > > Cc: Daniel Thompson <daniel.thompson@linaro.org>
> > > > > > > Cc: Jingoo Han <jingoohan1@gmail.com>
> > > > > > > Cc: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
> > > > > > > Cc: linux-pwm@vger.kernel.org
> > > > > > > Cc: dri-devel@lists.freedesktop.org
> > > > > > > Cc: linux-fbdev@vger.kernel.org
> > > > > > > 
> > > > > > > Signed-off-by: Guru Das Srinagesh <gurus@codeaurora.org>
> > > > > > > Reviewed-by: Daniel Thompson <daniel.thompson@linaro.org>
> > > > > > > ---
> > > > > > >  drivers/video/backlight/pwm_bl.c | 3 ++-
> > > > > > >  1 file changed, 2 insertions(+), 1 deletion(-)
> > > > > > 
> > > > > > Can this patch be taken on its own?
> > > > > 
> > > > > Hellooooo ...
> > > > 
> > > > Conceptually it can. As the last patch depends on this one (and the
> > > > others) some coordination might be beneficial. But that's up to Thierry
> > > > to decide how (and if) he want this series to be applied.
> > > 
> > > ... and on the backlight side we definitely need to know about the "if"
> > > otherwise there's no point in taking it.
> > 
> > Right.
> > 
> > I'm happy to wait for Thierry.  Although this isn't the only set he's
> > currently blocking.  Is he okay?  On holiday perhaps?
> 
> The newest commit by him in next is from last week. My guess is he
> just didn't come around yet to care for the PWM duties.

Looks like we missed the last release.

Let's hope we don't miss the next one also.

-- 
Lee Jones [李琼斯]
Linaro Services Technical Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog