Maksytka/linux
1
1
Fork 0
mirror of https://github.com/torvalds/linux.git synced 2025-11-30 23:16:01 +07:00
Code Issues Packages Projects Releases Wiki Activity

docs: pwm: Adapt Locking paragraph to reality

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

Locking in the core was introduced in commit 1cc2e1faaf ("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>
This commit is contained in:
Uwe Kleine-König
2025-06-24 12:05:00 +02:00
committed by Uwe Kleine-König
parent 2c06a21789
commit 10e9b32d9a
1 changed files with 9 additions and 4 deletions
Download Patch File Download Diff File Expand all files Collapse all files

13
Documentation/driver-api/pwm.rst
View File

@@ -173,10 +173,15 @@ Locking
-------
The PWM core list manipulations are protected by a mutex, so pwm_get()
and pwm_put() may not be called from an atomic context. Currently the
PWM core does not enforce any locking to pwm_enable(), pwm_disable() and
pwm_config(), so the calling context is currently driver specific. This
is an issue derived from the former barebone API and should be fixed soon.
and pwm_put() may not be called from an atomic context.
Most functions in the PWM consumer API might sleep and so must not be called
from atomic context. The notable exception is pwm_apply_atomic() which has the
same semantics as pwm_apply_might_sleep() but can be called from atomic context.
(The price for that is that it doesn't work for all PWM devices, use
pwm_might_sleep() to check if a given PWM supports atomic operation.
Locking in the PWM core ensures that callbacks related to a single chip are
serialized.
Helpers
-------