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

pwm: sifive: Call pwm_sifive_update_clock() while mutex is held

2023-01-18T10:41:30+00:00

[ Upstream commit 45558b3abb87eeb2cedb8a59cb2699c120b5102a ]

As was documented in commit 0f02f491b786 ("pwm: sifive: Reduce time the
controller lock is held") a caller of pwm_sifive_update_clock() must
hold the mutex. So fix pwm_sifive_clock_notifier() to grab the lock.

While this necessity was only documented later, the race exists since
the driver was introduced.

Fixes: 9e37a53eb051 ("pwm: sifive: Add a driver for SiFive SoC PWM")
Reported-by: Emil Renner Berthing 
Reviewed-by: Emil Renner Berthing 
Link: https://lore.kernel.org/r/20221018061656.1428111-1-u.kleine-koenig@pengutronix.de
Signed-off-by: Uwe Kleine-König 
Signed-off-by: Thierry Reding 
Signed-off-by: Sasha Levin

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

2022-06-14T16:11:51+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-15T12:18:17+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: stm32-lp: Don't modify HW state in .remove() callback

2021-09-26T12:07:13+00:00

[ Upstream commit d44084c93427bb0a9261432db1a8ca76a42d805e ]

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.

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

pwm: rockchip: Don't modify HW state in .remove() callback

2021-09-26T12:07:13+00:00

[ Upstream commit 9d768cd7fd42bb0be16f36aec48548fca5260759 ]

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.

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

pwm: img: Don't modify HW state in .remove() callback

2021-09-26T12:07:13+00:00

[ Upstream commit c68eb29c8e9067c08175dd0414f6984f236f719d ]

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.

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-26T12:07:09+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: sprd: Ensure configuring period and duty_cycle isn't wrongly skipped

2021-07-28T11:30:53+00:00

[ Upstream commit 65e2e6c1c20104ed19060a38f4edbf14e9f9a9a5 ]

As the last call to sprd_pwm_apply() might have exited early if
state->enabled was false, the values for period and duty_cycle stored in
pwm->state might not have been written to hardware and it must be
ensured that they are configured before enabling the PWM.

Fixes: 8aae4b02e8a6 ("pwm: sprd: Add Spreadtrum PWM support")
Signed-off-by: Uwe Kleine-König 
Signed-off-by: Thierry Reding 
Signed-off-by: Sasha Levin

pwm: imx1: Don't disable clocks at device remove time

2021-07-20T14:10:50+00:00

[ Upstream commit 1bc6ea31cb41d50302a3c9b401964cf0a88d41f9 ]

The .remove() callback disables clocks that were not enabled in
.probe(). So just probing and then unbinding the driver results in a clk
enable imbalance.

So just drop the call to disable the clocks. (Which BTW was also in the
wrong order because the call makes the PWM unfunctional and so should
have come only after pwmchip_remove()).

Fixes: 9f4c8f9607c3 ("pwm: imx: Add ipg clock operation")
Signed-off-by: Uwe Kleine-König 
Signed-off-by: Thierry Reding 
Signed-off-by: Sasha Levin

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

2021-07-20T14:10:48+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