tjh.dev / kernel
Linux kernel mirror (for testing) git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
kernel os linux
1
fork

Configure Feed

Select the types of activity you want to include in your feed.

docs: pwm: Adapt Locking paragraph to reality

We have the distinction between pwm_apply_atomic() and
pwm_apply_might_sleep() since commit c748a6d77c06 (pwm: Rename
pwm_apply_state() to pwm_apply_might_sleep()) contained in v6.8-rc1.

Locking in the core was introduced in commit 1cc2e1faafb3 ("pwm: Add
more locking", contained in v6.13-rc1) to serialize per-chip callbacks
and device removal.

Signed-off-by: Uwe Kleine-König <u.kleine-koenig@baylibre.com>
Link: https://lore.kernel.org/r/20250624100500.1429163-2-u.kleine-koenig@baylibre.com
Signed-off-by: Uwe Kleine-König <ukleinek@kernel.org>

authored by

Uwe Kleine-König and committed by
Uwe Kleine-König 10e9b32d 2c06a217

+9 -4
+9 -4
Documentation/driver-api/pwm.rst
··· 173 173 ------- 174 174 175 175 The PWM core list manipulations are protected by a mutex, so pwm_get() 176 - and pwm_put() may not be called from an atomic context. Currently the 177 - PWM core does not enforce any locking to pwm_enable(), pwm_disable() and 178 - pwm_config(), so the calling context is currently driver specific. This 179 - is an issue derived from the former barebone API and should be fixed soon. 176 + and pwm_put() may not be called from an atomic context. 177 + Most functions in the PWM consumer API might sleep and so must not be called 178 + from atomic context. The notable exception is pwm_apply_atomic() which has the 179 + same semantics as pwm_apply_might_sleep() but can be called from atomic context. 180 + (The price for that is that it doesn't work for all PWM devices, use 181 + pwm_might_sleep() to check if a given PWM supports atomic operation. 182 + 183 + Locking in the PWM core ensures that callbacks related to a single chip are 184 + serialized. 180 185 181 186 Helpers 182 187 -------