kernel/linux.git/drivers/pwm, branch master

Merge tag 'pwm/fixes-7.1-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/ukleinek/linux

2026-04-23T15:37:07+00:00

Pull pwm fixes from Uwe Kleine-König: "Two driver fixes After having added some more code to libpwm checking the pwm rounding rules for the userspace interface I spotted an issue in the pwm-stm32 driver where in some cases involving inverted polarity the wrong hardware settings for the duty offset are chosen. I think it has little practical effect because the duty offset is in most cases an artificial property of the output waveform. Still it's relevant to get this fixed because this driver serves as a reference implementation for the still young waveform API. The second fix addresses a sleep-in-atomic issue in the pwm-atmel-tcb driver" * tag 'pwm/fixes-7.1-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/ukleinek/linux: pwm: atmel-tcb: Cache clock rates and mark chip as atomic pwm: stm32: Fix rounding issue for requests with inverted polarity

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

2026-04-22T05:24:33+00:00

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

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

2026-04-16T05:25:15+00:00

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

Merge tag 'pwm/for-7.1-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/ukleinek/linux

2026-04-15T21:13:31+00:00

Pull pwm updates from Uwe Kleine-König: "Just two minor fixes, a device tree binding addition to support a few more SoCs (without the need for driver adaptions), a driver include cleanup and the addition of the #linux-pwm irc channel to MAINTAINERS" * tag 'pwm/for-7.1-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/ukleinek/linux: pwm: th1520: fix `CLIPPY=1` warning pwm: jz4740: Drop unused include MAINTAINERS: Add #linux-pwm irc channel to pwm entry dt-bindings: pwm: amlogic: Document A4 A5 and T7 PWM pwm: imx-tpm: Count the number of enabled channels in probe

pwm: th1520: remove impl Send/Sync for Th1520PwmDriverData

2026-04-03T09:57:35+00:00

Now that clk implements Send and Sync, we no longer need to manually implement these traits for Th1520PwmDriverData. Thus remove the implementations. Reviewed-by: Gary Guo Reviewed-by: Daniel Almeida Acked-by: Uwe Kleine-König Reviewed-by: Michal Wilczynski Signed-off-by: Alice Ryhl Link: https://patch.msgid.link/20260223-clk-send-sync-v5-3-181bf2f35652@google.com Signed-off-by: Miguel Ojeda

pwm: th1520: fix `CLIPPY=1` warning

2026-03-29T07:37:13+00:00

The Rust kernel code should be kept `CLIPPY=1`-clean [1]. Clippy reports: error: this pattern reimplements `Option::unwrap_or` --> drivers/pwm/pwm_th1520.rs:64:5 | 64 | / (match ns.checked_mul(rate_hz) { 65 | | Some(product) => product, 66 | | None => u64::MAX, 67 | | }) / NSEC_PER_SEC_U64 | |______^ help: replace with: `ns.checked_mul(rate_hz).unwrap_or(u64::MAX)` | = help: for further information visit https://rust-lang.github.io/rust-clippy/rust-1.92.0/index.html#manual_unwrap_or = note: `-D clippy::manual-unwrap-or` implied by `-D warnings` = help: to override `-D warnings` add `#[allow(clippy::manual_unwrap_or)]` Applying the suggestion then triggers: error: manual saturating arithmetic --> drivers/pwm/pwm_th1520.rs:64:5 | 64 | ns.checked_mul(rate_hz).unwrap_or(u64::MAX) / NSEC_PER_SEC_U64 | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ help: consider using `saturating_mul`: `ns.saturating_mul(rate_hz)` | = help: for further information visit https://rust-lang.github.io/rust-clippy/rust-1.92.0/index.html#manual_saturating_arithmetic = note: `-D clippy::manual-saturating-arithmetic` implied by `-D warnings` = help: to override `-D warnings` add `#[allow(clippy::manual_saturating_arithmetic)]` Thus fix it by using saturating arithmetic, which simplifies the code as well. Link: https://rust-for-linux.com/contributing#submit-checklist-addendum [1] Fixes: e03724aac758 ("pwm: Add Rust driver for T-HEAD TH1520 SoC") Signed-off-by: Miguel Ojeda Reviewed-by: Danilo Krummrich Reviewed-by: Michal Wilczynski Link: https://patch.msgid.link/20260121183719.71659-1-ojeda@kernel.org Signed-off-by: Uwe Kleine-König

pwm: jz4740: Drop unused include

2026-03-21T22:34:37+00:00

This driver includes the legacy header but does not use any symbols from it. Drop the inclusion. Signed-off-by: Andy Shevchenko Acked-by: Paul Cercueil Link: https://patch.msgid.link/20260320220644.3237290-1-andriy.shevchenko@linux.intel.com Signed-off-by: Uwe Kleine-König

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

2026-03-13T08:56:28+00:00

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

Convert 'alloc_flex' family to use the new default GFP_KERNEL argument

2026-02-22T01:09:51+00:00

This is the exact same thing as the 'alloc_obj()' version, only much smaller because there are a lot fewer users of the *alloc_flex() interface. As with alloc_obj() version, this was done entirely with mindless brute force, using the same script, except using 'flex' in the pattern rather than 'objs*'. Signed-off-by: Linus Torvalds

Convert 'alloc_obj' family to use the new default GFP_KERNEL argument

2026-02-22T01:09:51+00:00

This was done entirely with mindless brute force, using git grep -l '\