linux-stable.git/drivers/pwm, branch v5.4.78

pwm: img: Fix null pointer access in probe

2020-10-29T08:57:54+00:00

[ Upstream commit b39c0615d0667b3a6f2f5c4bf99ffadf3b518bb1 ]

dev_get_drvdata() is called in img_pwm_runtime_resume() before the
driver data is set.
When pm_runtime_enabled() returns false in img_pwm_probe() it calls
img_pwm_runtime_resume() which results in a null pointer access.

This patch fixes the problem by setting the driver data earlier in the
img_pwm_probe() function.

This crash was seen when booting the Imagination Technologies Creator
Ci40 (Marduk) with kernel 5.4 in OpenWrt.

Fixes: e690ae526216 ("pwm: img: Add runtime PM")
Signed-off-by: Hauke Mehrtens 
Acked-by: Lee Jones 
Signed-off-by: Thierry Reding 
Signed-off-by: Sasha Levin

pwm: lpss: Add range limit check for the base_unit register value

2020-10-29T08:57:38+00:00

[ Upstream commit ef9f60daab309558c8bb3e086a9a11ee40bd6061 ]

When the user requests a high enough period ns value, then the
calculations in pwm_lpss_prepare() might result in a base_unit value of 0.

But according to the data-sheet the way the PWM controller works is that
each input clock-cycle the base_unit gets added to a N bit counter and
that counter overflowing determines the PWM output frequency. Adding 0
to the counter is a no-op. The data-sheet even explicitly states that
writing 0 to the base_unit bits will result in the PWM outputting a
continuous 0 signal.

When the user requestes a low enough period ns value, then the
calculations in pwm_lpss_prepare() might result in a base_unit value
which is bigger then base_unit_range - 1. Currently the codes for this
deals with this by applying a mask:

	base_unit &= (base_unit_range - 1);

But this means that we let the value overflow the range, we throw away the
higher bits and store whatever value is left in the lower bits into the
register leading to a random output frequency, rather then clamping the
output frequency to the highest frequency which the hardware can do.

This commit fixes both issues by clamping the base_unit value to be
between 1 and (base_unit_range - 1).

Fixes: 684309e5043e ("pwm: lpss: Avoid potential overflow of base_unit")
Reviewed-by: Andy Shevchenko 
Acked-by: Thierry Reding 
Signed-off-by: Hans de Goede 
Link: https://patchwork.freedesktop.org/patch/msgid/20200903112337.4113-5-hdegoede@redhat.com
Signed-off-by: Sasha Levin

pwm: lpss: Fix off by one error in base_unit math in pwm_lpss_prepare()

2020-10-29T08:57:38+00:00

[ Upstream commit 181f4d2f44463fe09fe4df02e03095cb87151c29 ]

According to the data-sheet the way the PWM controller works is that
each input clock-cycle the base_unit gets added to a N bit counter and
that counter overflowing determines the PWM output frequency.

So assuming e.g. a 16 bit counter this means that if base_unit is set to 1,
after 65535 input clock-cycles the counter has been increased from 0 to
65535 and it will overflow on the next cycle, so it will overflow after
every 65536 clock cycles and thus the calculations done in
pwm_lpss_prepare() should use 65536 and not 65535.

This commit fixes this. Note this also aligns the calculations in
pwm_lpss_prepare() with those in pwm_lpss_get_state().

Note this effectively reverts commit 684309e5043e ("pwm: lpss: Avoid
potential overflow of base_unit"). The next patch in this series really
fixes the potential overflow of the base_unit value.

Fixes: 684309e5043e ("pwm: lpss: Avoid potential overflow of base_unit")
Reviewed-by: Andy Shevchenko 
Acked-by: Uwe Kleine-König 
Acked-by: Thierry Reding 
Signed-off-by: Hans de Goede 
Link: https://patchwork.freedesktop.org/patch/msgid/20200903112337.4113-4-hdegoede@redhat.com
Signed-off-by: Sasha Levin

pwm: bcm-iproc: handle clk_get_rate() return

2020-08-21T11:05:34+00:00

[ Upstream commit 6ced5ff0be8e94871ba846dfbddf69d21363f3d7 ]

Handle clk_get_rate() returning 0 to avoid possible division by zero.

Fixes: daa5abc41c80 ("pwm: Add support for Broadcom iProc PWM controller")
Signed-off-by: Rayagonda Kokatanur 
Signed-off-by: Scott Branden 
Reviewed-by: Ray Jui 
Reviewed-by: Uwe Kleine-König 
Signed-off-by: Thierry Reding 
Signed-off-by: Sasha Levin

pwm: jz4740: Fix build failure

2020-07-16T06:16:48+00:00

When commit 9017dc4fbd59 ("pwm: jz4740: Enhance precision in calculation
of duty cycle") from v5.8-rc1 was backported to v5.4.x its dependency on
commit ce1f9cece057 ("pwm: jz4740: Use clocks from TCU driver") was not
noticed which made the pwm-jz4740 driver fail to build.

As ce1f9cece057 depends on still more rework, just backport a small part
of this commit to make the driver build again. (There is no dependency
on the functionality introduced in ce1f9cece057, just the rate variable
is needed.)

Signed-off-by: Uwe Kleine-König 
Reported-by: H. Nikolaus Schaller 
Signed-off-by: Greg Kroah-Hartman

pwm: jz4740: Enhance precision in calculation of duty cycle

2020-06-24T15:50:52+00:00

commit 9017dc4fbd59c09463019ce494cfe36d654495a8 upstream.

Calculating the hardware value for the duty from the hardware value of
the period resulted in a precision loss versus calculating it from the
clock rate directly.

(Also remove a cast that doesn't really need to be here)

Fixes: f6b8a5700057 ("pwm: Add Ingenic JZ4740 support")
Cc: 
Suggested-by: Uwe Kleine-König 
Reviewed-by: Uwe Kleine-König 
Signed-off-by: Paul Cercueil 
Signed-off-by: Thierry Reding 
[ukl: backport to v5.4.y and adapt commit log accordingly]
Signed-off-by: Uwe Kleine-König 
Signed-off-by: Greg Kroah-Hartman

pwm: img: Call pm_runtime_put() in pm_runtime_get_sync() failed case

2020-06-24T15:50:18+00:00

[ Upstream commit ca162ce98110b98e7d97b7157328d34dcfdd40a9 ]

Even in failed case of pm_runtime_get_sync(), the usage_count is
incremented. In order to keep the usage_count with correct value call
appropriate pm_runtime_put().

Signed-off-by: Navid Emamdoost 
Signed-off-by: Thierry Reding 
Signed-off-by: Sasha Levin

pwm: bcm2835: Dynamically allocate base

2020-04-29T14:33:02+00:00

[ Upstream commit 2c25b07e5ec119cab609e41407a1fb3fa61442f5 ]

The newer 2711 and 7211 chips have two PWM controllers and failure to
dynamically allocate the PWM base would prevent the second PWM
controller instance being probed for succeeding with an -EEXIST error
from alloc_pwms().

Fixes: e5a06dc5ac1f ("pwm: Add BCM2835 PWM driver")
Signed-off-by: Florian Fainelli 
Acked-by: Uwe Kleine-König 
Reviewed-by: Nicolas Saenz Julienne 
Signed-off-by: Thierry Reding 
Signed-off-by: Sasha Levin

pwm: renesas-tpu: Fix late Runtime PM enablement

2020-04-29T14:33:02+00:00

[ Upstream commit d5a3c7a4536e1329a758e14340efd0e65252bd3d ]

Runtime PM should be enabled before calling pwmchip_add(), as PWM users
can appear immediately after the PWM chip has been added.
Likewise, Runtime PM should always be disabled after the removal of the
PWM chip, even if the latter failed.

Fixes: 99b82abb0a35b073 ("pwm: Add Renesas TPU PWM driver")
Signed-off-by: Geert Uytterhoeven 
Signed-off-by: Thierry Reding 
Signed-off-by: Sasha Levin

pwm: rcar: Fix late Runtime PM enablement

2020-04-29T14:32:58+00:00

[ Upstream commit 1451a3eed24b5fd6a604683f0b6995e0e7e16c79 ]

Runtime PM should be enabled before calling pwmchip_add(), as PWM users
can appear immediately after the PWM chip has been added.
Likewise, Runtime PM should be disabled after the removal of the PWM
chip.

Fixes: ed6c1476bf7f16d5 ("pwm: Add support for R-Car PWM Timer")
Signed-off-by: Geert Uytterhoeven 
Reviewed-by: Uwe Kleine-König 
Reviewed-by: Laurent Pinchart 
Signed-off-by: Thierry Reding 
Signed-off-by: Sasha Levin