kernel/linux.git/drivers/pwm, branch v6.18.33

pwm: atmel-tcb: Cache clock rates and mark chip as atomic

2026-05-23T11:07:03+00:00

[ Upstream commit 68637b68afcc3cb4d56aca14a3a1d1b47b879369 ] atmel_tcb_pwm_apply() holds tcbpwmc->lock as a spinlock via guard(spinlock)() and then calls atmel_tcb_pwm_config(), which calls clk_get_rate() twice. clk_get_rate() acquires clk_prepare_lock (a mutex), so this is a sleep-in-atomic-context violation. On CONFIG_DEBUG_ATOMIC_SLEEP kernels every pwm_apply_state() that enables or reconfigures the PWM triggers a "BUG: sleeping function called from invalid context" warning. Acquire exclusive control over the clock rates with clk_rate_exclusive_get() at probe time and cache the rates in struct atmel_tcb_pwm_chip, then read the cached rates from atmel_tcb_pwm_config(). This keeps the spinlock-based mutual exclusion introduced in commit 37f7707077f5 ("pwm: atmel-tcb: Fix race condition and convert to guards") and removes the sleeping calls from the atomic section. With no sleeping calls left in .apply() and the regmap-mmio bus already running with fast_io=true, also mark the chip as atomic so consumers can use pwm_apply_atomic() from atomic context. Fixes: 37f7707077f5 ("pwm: atmel-tcb: Fix race condition and convert to guards") Signed-off-by: Sangyun Kim Link: https://patch.msgid.link/20260419080838.3192357-1-sangyun.kim@snu.ac.kr [ukleinek: Ensure .clk is enabled before calling clk_get_rate on it.] Signed-off-by: Uwe Kleine-König Signed-off-by: Sasha Levin

pwm: stm32: Fix rounding issue for requests with inverted polarity

2026-05-23T11:06:59+00:00

[ Upstream commit 5d087c485b6ecf200a9ebb2a032bf8571d330250 ] The calculation of the number of pwm clk ticks from a time length in nanoseconds involves a division and thus some rounding. That might result in duty_ticks + offset_ticks < period_ticks despite duty_length_ns + duty_offset_ns >= period_length_ns . The stm32 PWM cannot configure offset_ticks freely, it can only select 0 or period_length_ns - duty_length_ns---that is the classic normal and inverted polarity. The decision to select the hardware polarity must be done using the ticks values and not the nanoseconds times to adhere to the rounding rules by the pwm core. With the pwm clk running at 208900 kHz on my test machine (stm32mp135f-dk), a test case that was handled wrong is: # pwmround -P 9999962 -O 24970 -D 9974992 period_length = 9999962 duty_length = 9974840 duty_offset = 25123 With this change applied the rounding is done correctly: # pwmround -P 9999962 -O 24970 -D 9974992 period_length = 9999962 duty_length = 9974840 duty_offset = 0 Fixes: deaba9cff809 ("pwm: stm32: Implementation of the waveform callbacks") Signed-off-by: Uwe Kleine-König Link: https://patch.msgid.link/c5e7767cee821b5f6e00f95bd14a5e13015646fb.1776264104.git.u.kleine-koenig@baylibre.com Signed-off-by: Uwe Kleine-König Signed-off-by: Sasha Levin

pwm: imx-tpm: Count the number of enabled channels in probe

2026-05-07T04:11:49+00:00

commit 3962c24f2d14e8a7f8a23f56b7ce320523947342 upstream. On a soft reset TPM PWM IP may preserve its internal state from previous runtime, therefore on a subsequent OS boot and driver probe "enable_count" value and TPM PWM IP internal channels "enabled" states may get unaligned. In consequence on a suspend/resume cycle the call "if (--tpm->enable_count == 0)" may lead to "enable_count" overflow the system being blocked from entering suspend due to: if (tpm->enable_count > 0) return -EBUSY; Fix the problem by counting the enabled channels in probe function. Signed-off-by: Viorel Suman (OSS) Fixes: 738a1cfec2ed ("pwm: Add i.MX TPM PWM driver support") Link: https://patch.msgid.link/20260311123309.348904-1-viorel.suman@oss.nxp.com Cc: stable@vger.kernel.org Signed-off-by: Uwe Kleine-König Signed-off-by: Greg Kroah-Hartman

pwm: tiehrpwm: Enable pwmchip's parent device before setting configuration

2026-02-26T22:59:14+00:00

[ Upstream commit 75e7ed52ac7c1da90f304dcda2906636404df921 ] The period and duty cycle configurations on J7200 and J784S4 SoCs does not get reflected after setting them using sysfs nodes. This is because at the end of ehrpwm_pwm_config function, the put_sync function is called which resets the hardware. Hold the PWM controller out of low-power mode during .apply() to make sure it accepts the writes to its registers. This renders the calls to pm_runtime_get_sync() and pm_runtime_put_sync() in ehrpwm_pwm_config() into no-ops, so these can be dropped. Fixes: 5f027d9b83db ("pwm: tiehrpwm: Implement .apply() callback") Signed-off-by: Gokul Praveen Suggested-by: Uwe Kleine-König Link: https://patch.msgid.link/20260121061134.15466-1-g-praveen@ti.com Signed-off-by: Uwe Kleine-König Signed-off-by: Sasha Levin

pwm: max7360: Populate missing .sizeof_wfhw in max7360_pwm_ops

2026-01-30T09:32:12+00:00

[ Upstream commit 63faf32666e03a78cc985bcbae196418cf7d7938 ] The sizeof_wfhw field wasn't populated in max7360_pwm_ops so it was set to 0 by default. While this is ok for now because: sizeof(struct max7360_pwm_waveform) < PWM_WFHWSIZE in the future, if struct max7360_pwm_waveform grows, it could lead to stack corruption. Fixes: d93a75d94b79 ("pwm: max7360: Add MAX7360 PWM support") Signed-off-by: Richard Genoud Link: https://patch.msgid.link/20260113163907.368919-1-richard.genoud@bootlin.com Signed-off-by: Uwe Kleine-König Signed-off-by: Sasha Levin

pwm: Ensure ioctl() returns a negative errno on error

2026-01-30T09:32:12+00:00

[ Upstream commit c198b7773ca5bc3bdfb15b85e414fb9a99a5e5ba ] copy_to_user() returns the number of bytes not copied, thus if there is a problem a positive number. However the ioctl callback is supposed to return a negative error code on error. This error is a unfortunate as strictly speaking it became ABI with the introduction of pwm character devices. However I never saw the issue in real life -- I found this by code inspection -- and it only affects an error case where readonly memory is passed to the ioctls or the address mapping changes while the ioctl is active. Also there are already error cases returning negative values, so the calling code must be prepared to see such values already. Fixes: 9c06f26ba5f5 ("pwm: Add support for pwmchip devices for faster and easier userspace access") Signed-off-by: Uwe Kleine-König Link: https://patch.msgid.link/20260119151325.571857-2-u.kleine-koenig@baylibre.com Signed-off-by: Uwe Kleine-König Signed-off-by: Sasha Levin

pwm: rzg2l-gpt: Allow checking period_tick cache value only if sibling channel is enabled

2026-01-02T11:57:29+00:00

commit fae00ea9f00367771003ace78f29549dead58fc7 upstream. The rzg2l_gpt_config() tests the rzg2l_gpt->period_tick variable when both channels of a hardware channel are in use. This check is not valid if rzg2l_gpt_config() is called after disabling all the channels, as it tests against the cached value. Hence, allow checking and setting the cached value only if the sibling channel is enabled. While at it, drop else after return statement to fix the check patch warning. Cc: stable@kernel.org Fixes: 061f087f5d0b ("pwm: Add support for RZ/G2L GPT") Signed-off-by: Biju Das Link: https://patch.msgid.link/20251126104308.142302-1-biju.das.jz@bp.renesas.com Signed-off-by: Uwe Kleine-König Signed-off-by: Greg Kroah-Hartman

pwm: bcm2835: Make sure the channel is enabled after pwm_request()

2025-12-18T13:03:06+00:00

[ Upstream commit cda323dbda76600bf9761970d58517648f0de67d ] The .free callback cleared among others the enable bit PWENx in the control register. When the PWM is requested later again this bit isn't restored but the core assumes the PWM is enabled and thus skips a request to configure the same state as before. To fix that don't touch the hardware configuration in .free(). For symmetry also drop .request() and configure the mode completely in .apply(). Fixes: e5a06dc5ac1f ("pwm: Add BCM2835 PWM driver") Signed-off-by: Uwe Kleine-König Reviewed-by: Florian Fainelli Link: https://patch.msgid.link/20251118174303.1761577-2-u.kleine-koenig@baylibre.com Signed-off-by: Uwe Kleine-König Signed-off-by: Sasha Levin

pwm: Use %u to printf unsigned int pwm_chip::npwm and pwm_chip::id

2025-12-18T13:03:00+00:00

[ Upstream commit 5f7ff902e7f324c10f2b64c5ba2e5e2d0bc4e07e ] %u is the right conversion specifier to emit an unsigned int value. Fixes: 62099abf67a2 ("pwm: Add debugfs interface") Fixes: 0360a4873372 ("pwm: Mention PWM chip ID in /sys/kernel/debug/pwm") Signed-off-by: Uwe Kleine-König Link: https://patch.msgid.link/20251006133525.2457171-2-u.kleine-koenig@baylibre.com Signed-off-by: Uwe Kleine-König Signed-off-by: Sasha Levin

pwm: Simplify printf to emit chip->npwm in $debugfs/pwm

2025-12-18T13:03:00+00:00

[ Upstream commit 3cf8e55894b51c14f8500cae5e68ed48b1b0f3fd ] Instead of caring to correctly pluralize "PWM device(s)" using (chip->npwm != 1) ? "s" : "" or str_plural(chip->npwm) just simplify the format to not need a plural-s. Signed-off-by: Uwe Kleine-König Link: https://patch.msgid.link/20250926165702.321514-2-u.kleine-koenig@baylibre.com Signed-off-by: Uwe Kleine-König Stable-dep-of: 5f7ff902e7f3 ("pwm: Use %u to printf unsigned int pwm_chip::npwm and pwm_chip::id") Signed-off-by: Sasha Levin