Commit 10e9b32d authored by Uwe Kleine-König's avatar Uwe Kleine-König Committed by Uwe Kleine-König
Browse files

docs: pwm: Adapt Locking paragraph to reality 



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

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

Signed-off-by: default avatarUwe 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: default avatarUwe Kleine-König <ukleinek@kernel.org>
parent 2c06a217

Documentation/driver-api/pwm.rst

+9 −4
Original line number Diff line number Diff line
@@ -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

-------