linux-stable.git/drivers/pwm, branch linux-4.9.y

pwm: lp3943: Fix duty calculation in case period was clamped

2022-06-14T14:52:37+00:00

[ Upstream commit 5e3b07ca5cc78cd4a987e78446849e41288d87cb ]

The hardware only supports periods <= 1.6 ms and if a bigger period is
requested it is clamped to 1.6 ms. In this case duty_cycle might be bigger
than 1.6 ms and then the duty cycle register is written with a value
bigger than LP3943_MAX_DUTY. So clamp duty_cycle accordingly.

Fixes: af66b3c0934e ("pwm: Add LP3943 PWM driver")
Signed-off-by: Uwe Kleine-König 
Signed-off-by: Thierry Reding 
Signed-off-by: Sasha Levin

pwm: lpc18xx-sct: Initialize driver data and hardware before pwmchip_add()

2022-04-20T07:06:36+00:00

[ Upstream commit 0401f24cd238ae200a23a13925f98de3d2c883b8 ]

When a driver calls pwmchip_add() it has to be prepared to immediately
get its callbacks called. So move allocation of driver data and hardware
initialization before the call to pwmchip_add().

This fixes a potential NULL pointer exception and a race condition on
register writes.

Fixes: 841e6f90bb78 ("pwm: NXP LPC18xx PWM/SCT driver")
Signed-off-by: Uwe Kleine-König 
Signed-off-by: Thierry Reding 
Signed-off-by: Sasha Levin

pwm: lpc32xx: Don't modify HW state in .probe() after the PWM chip was registered

2021-09-26T11:36:18+00:00

commit 3d2813fb17e5fd0d73c1d1442ca0192bde4af10e upstream.

This fixes a race condition: After pwmchip_add() is called there might
already be a consumer and then modifying the hardware behind the
consumer's back is bad. So set the default before.

(Side-note: I don't know what this register setting actually does, if
this modifies the polarity there is an inconsistency because the
inversed polarity isn't considered if the PWM is already running during
.probe().)

Fixes: acfd92fdfb93 ("pwm: lpc32xx: Set PWM_PIN_LEVEL bit to default value")
Cc: Sylvain Lemieux 
Signed-off-by: Uwe Kleine-König 
Signed-off-by: Thierry Reding 
Signed-off-by: Greg Kroah-Hartman

pwm: tegra: Don't modify HW state in .remove callback

2021-07-20T14:21:14+00:00

[ Upstream commit 86f7fa71cd830d18d7ebcaf719dffd5ddfe1acdd ]

A consumer is expected to disable a PWM before calling pwm_put(). And if
they didn't there is hopefully a good reason (or the consumer needs
fixing). Also if disabling an enabled PWM was the right thing to do,
this should better be done in the framework instead of in each low level
driver.

So drop the hardware modification from the .remove() callback.

Signed-off-by: Uwe Kleine-König 
Signed-off-by: Thierry Reding 
Signed-off-by: Sasha Levin

pwm: spear: Don't modify HW state in .remove callback

2021-07-20T14:21:13+00:00

[ Upstream commit b601a18f12383001e7a8da238de7ca1559ebc450 ]

A consumer is expected to disable a PWM before calling pwm_put(). And if
they didn't there is hopefully a good reason (or the consumer needs
fixing). Also if disabling an enabled PWM was the right thing to do,
this should better be done in the framework instead of in each low level
driver.

So drop the hardware modification from the .remove() callback.

Signed-off-by: Uwe Kleine-König 
Signed-off-by: Thierry Reding 
Signed-off-by: Sasha Levin

pwm: rockchip: rockchip_pwm_probe(): Remove superfluous clk_unprepare()

2021-03-03T16:44:39+00:00

[ Upstream commit d5d8d675865ccddfe4da26c85f22c55cec663bf2 ]

If rockchip_pwm_probe() fails to register a PWM device it calls
clk_unprepare() for the device's PWM clock, without having first disabled
the clock and before jumping to an error handler that also unprepares
it. This is likely to produce warnings from the kernel about the clock
being unprepared when it is still enabled, and then being unprepared when
it has already been unprepared.

Prevent these warnings by removing this unnecessary call to
clk_unprepare().

Fixes: 48cf973cae33 ("pwm: rockchip: Avoid glitches on already running PWMs")
Signed-off-by: Simon South 
Signed-off-by: Thierry Reding 
Signed-off-by: Sasha Levin

pwm: bcm-iproc: handle clk_get_rate() return

2020-08-21T09:02:10+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: bcm2835: Dynamically allocate base

2020-05-02T15:23:07+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-05-02T15:23:07+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-05-02T15:23:04+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