linux-toradex.git/drivers/pwm/core.c, branch v6.11-rc3

pwm: Allow pwm state transitions from an invalid state

2024-07-10T15:53:52+00:00

While driving a PWM via the sysfs API it's hard to determine the right
order of writes to the pseudo files "period" and "duty_cycle":

If you want to go from duty_cycle/period = 50/100 to 150/300 you have to
write period first (because 150/100 is invalid). If however you start at
400/500 the duty_cycle must be configured first. The rule that works is:
If you increase period write period first, otherwise write duty_cycle
first. A complication however is that it's usually sensible to configure
the polarity before both period and duty_cycle. This can only be done if
the current state's duty_cycle and period configuration isn't bogus
though. It is still worse (but I think only theoretic) if you have a PWM
that only supports inverted polarity and you start with period = 0 and
polarity = normal. Then you can change neither period (because polarity
= normal is refused) nor polarity (because there is still period = 0).

To simplify the corner cases for userspace, let invalid target states
pass if the current state is invalid already.

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

pwm: Use guards for pwm_lookup_lock instead of explicity mutex_lock + mutex_unlock

2024-07-10T15:53:52+00:00

With the compiler caring for unlocking the mutex several functions can
be simplified. Benefit from that.

Signed-off-by: Uwe Kleine-König 
Link: https://lore.kernel.org/r/28807cb5d9dbce66860f74829c0f57cd9c01373e.1719520143.git.u.kleine-koenig@baylibre.com
Signed-off-by: Uwe Kleine-König

pwm: Use guards for export->lock instead of explicity mutex_lock + mutex_unlock

2024-07-10T15:53:52+00:00

With the compiler caring for unlocking the mutex several functions can
be simplified. Benefit from that.

There is just one caller left for mutex_lock(&export->lock). The code
flow is too complicated there to convert it to the compiler assisted
variant.

Signed-off-by: Uwe Kleine-König 
Link: https://lore.kernel.org/r/210010f2e579a92476462726e18e0135f6854909.1719520143.git.u.kleine-koenig@baylibre.com
Signed-off-by: Uwe Kleine-König

pwm: Use guards for pwm_lock instead of explicity mutex_lock + mutex_unlock

2024-07-10T15:53:51+00:00

With the compiler caring for unlocking the mutex several functions can
be simplified. Benefit from that.

Signed-off-by: Uwe Kleine-König 
Link: https://lore.kernel.org/r/2102fe8189bdf1f02ff3785b551a69be27a65af4.1719520143.git.u.kleine-koenig@baylibre.com
Signed-off-by: Uwe Kleine-König

pwm: Register debugfs operations after the pwm class

2024-07-10T15:53:51+00:00

While the debugfs operations don't technically depend on an initialized
class, they loop over the idr that only can get entries when the class
is properly initialized.

This also fixes the ugly (but harmless) corner case that the debugfs
file stays around after the pwm class failed to initialize.

While at it, add an appropriate error message when class initialization
fails.

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

pwm: Make pwm_request_from_chip() private to the core

2024-07-10T15:52:47+00:00

The last user of this function outside of core.c is gone, so it can be
made static.

Signed-off-by: Uwe Kleine-König 
Reviewed-by: Tzung-Bi Shih 
Link: https://lore.kernel.org/r/20240607084416.897777-8-u.kleine-koenig@baylibre.com
Signed-off-by: Uwe Kleine-König

pwm: Make use of a symbol namespace for the core

2024-07-10T15:52:47+00:00

Define all pwm core's symbols in the namespace "PWM". The necessary
module import statement is just added to the main header, this way every
file that knows about the public functions automatically has this
namespace available.

Thanks to Biju Das for pointing out a cut'n'paste failure in my initial
patch.

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

pwm: Don't check pointer for being non-NULL after use

2024-04-30T16:56:55+00:00

After assigning chip = pwm->chip; the compiler is free to assume that
pwm is non-NULL and so can optimize out the check for pwm against NULL.

While it's probably a programming error to pass a NULL pointer to
pwm_put() this shouldn't be dropped without careful consideration and
wasn't intended.

So assign chip only after the NULL check.

Reported-by: David Lechner 
Link: https://lore.kernel.org/r/66a6f562-1fdd-4e45-995a-e7995432aa0c@baylibre.com
Fixes: 4c56b1434b81 ("pwm: Add a struct device to struct pwm_chip")
Link: https://lore.kernel.org/r/20240329101648.544155-2-u.kleine-koenig@pengutronix.de
Reviewed-by: David Lechner 
Signed-off-by: Uwe Kleine-König

pwm: Add a struct device to struct pwm_chip

2024-04-26T19:29:17+00:00

This replaces the formerly dynamically allocated struct device. This
allows to additionally use it to track the lifetime of the struct
pwm_chip. Otherwise the new struct device provides the same sysfs API as
was provided by the dynamic device before.

Link: https://lore.kernel.org/r/35c65ea7f6de789a568ff39d7b6b4ce80de4b7dc.1710670958.git.u.kleine-koenig@pengutronix.de
Signed-off-by: Uwe Kleine-König

pwm: Ensure a struct pwm has the same lifetime as its pwm_chip

2024-04-26T19:29:17+00:00

It's required to not free the memory underlying a requested PWM
while a consumer still has a reference to it. While currently a pwm_chip
doesn't live long enough in all cases, linking the struct pwm to the
pwm_chip results in the right lifetime as soon as the pwmchip is living
long enough. This happens with the following commits.

Note this is a breaking change for all pwm drivers that don't use
pwmchip_alloc().

Reviewed-by: Gustavo A. R. Silva  # for struct_size() and __counted_by()
Link: https://lore.kernel.org/r/7e9e958841f049026c0023b309cc9deecf0ab61d.1710670958.git.u.kleine-koenig@pengutronix.de
Signed-off-by: Uwe Kleine-König