kernel/linux.git/include/linux/pwm.h, branch v6.19.11

Merge branch 'pwm/th1520' into pwm/for-next

2025-11-14T10:56:14+00:00

pwm: Drop unused function pwm_apply_args()

2025-11-14T10:56:14+00:00

The function pwm_apply_args() was introduced with the concept of atomic PWM configuration and needed for drivers not using this concept yet. Now all drivers are converted accordingly and so no callers are left which allows to remove this function. Signed-off-by: Uwe Kleine-König Link: https://patch.msgid.link/20250922094327.1143944-2-u.kleine-koenig@baylibre.com Signed-off-by: Uwe Kleine-König

pwm: Export `pwmchip_release` for external use

2025-11-07T09:03:53+00:00

The upcoming Rust abstraction layer for the PWM subsystem uses a custom `dev->release` handler to safely manage the lifetime of its driver data. To prevent leaking the memory of the `struct pwm_chip` (allocated by `pwmchip_alloc`), this custom handler must also call the original `pwmchip_release` function to complete the cleanup. Make `pwmchip_release` a global, exported function so that it can be called from the Rust FFI bridge. This involves removing the `static` keyword, adding a prototype to the public header, and exporting the symbol. Reviewed-by: Elle Rhumsaa Signed-off-by: Michal Wilczynski Link: https://patch.msgid.link/20251016-rust-next-pwm-working-fan-for-sending-v16-1-a5df2405d2bd@samsung.com Signed-off-by: Uwe Kleine-König

pwm: Provide a gpio device for waveform drivers

2025-09-15T09:39:44+00:00

A PWM is a more general concept than an output-only GPIO. When using duty_length = period_length the PWM looks like an active GPIO, with duty_length = 0 like an inactive GPIO. With the waveform abstraction there is enough control over the configuration to ensure that PWMs that cannot generate a constant signal at both levels error out. The pwm-pca9685 driver already provides a gpio chip. When this driver is converted to the waveform callbacks, the gpio part can just be dropped. Signed-off-by: Uwe Kleine-König Reviewed-by: Bartosz Golaszewski Link: https://lore.kernel.org/r/20250717151117.1828585-2-u.kleine-koenig@baylibre.com Signed-off-by: Uwe Kleine-König

pwm: Expose PWM_WFHWSIZE in public header

2025-07-07T06:39:36+00:00

The WFHWSIZE constant defines the maximum size for the hardware-specific waveform representation buffer. It is currently local to drivers/pwm/core.c, which makes it inaccessible to external tools like bindgen. Move the constant to include/linux/pwm.h to make it part of the public API. As part of this change, rename it to PWM_WFHWSIZE to follow standard kernel conventions for namespacing macros in public headers. This allows bindgen to automatically generate a corresponding constant for the Rust PWM abstractions, ensuring the value remains synchronized between the C core and Rust code and preventing future maintenance issues. Signed-off-by: Michal Wilczynski Link: https://lore.kernel.org/r/20250702-rust-next-pwm-working-fan-for-sending-v7-1-67ef39ff1d29@samsung.com Signed-off-by: Uwe Kleine-König

pwm: Add support for pwmchip devices for faster and easier userspace access

2025-07-07T06:39:33+00:00

With this change each pwmchip defining the new-style waveform callbacks can be accessed from userspace via a character device. Compared to the sysfs-API this is faster and allows to pass the whole configuration in a single ioctl allowing atomic application and thus reducing glitches. On an STM32MP13 I see: root@DistroKit:~ time pwmtestperf real 0m 1.27s user 0m 0.02s sys 0m 1.21s root@DistroKit:~ rm /dev/pwmchip0 root@DistroKit:~ time pwmtestperf real 0m 3.61s user 0m 0.27s sys 0m 3.26s pwmtestperf does essentially: for i in 0 .. 50000: pwm_set_waveform(duty_length_ns=i, period_length_ns=50000, duty_offset_ns=0) and in the presence of /dev/pwmchip0 is uses the ioctls introduced here, without that device it uses /sys/class/pwm/pwmchip0. Signed-off-by: Uwe Kleine-König Link: https://lore.kernel.org/r/ad4a4e49ae3f8ea81e23cac1ac12b338c3bf5c5b.1746010245.git.u.kleine-koenig@baylibre.com Signed-off-by: Uwe Kleine-König

pwm: Fix various formatting issues in kernel-doc

2025-04-24T14:43:54+00:00

Add Return and (where interesting) Context sections, fix some formatting and drop documenting the internal function __pwm_apply(). Signed-off-by: Uwe Kleine-König Link: https://lore.kernel.org/r/20250417181611.2693599-2-u.kleine-koenig@baylibre.com Signed-off-by: Uwe Kleine-König

pwm: Make chip parameter to pwmchip_get_drvdata() a const pointer

2025-04-14T06:03:16+00:00

dev_get_drvdata()'s parameter is a const pointer, so the chip passed to pwmchip_get_drvdata() can be const, too. Signed-off-by: Uwe Kleine-König Link: https://lore.kernel.org/r/20250403151134.266388-2-u.kleine-koenig@baylibre.com Signed-off-by: Uwe Kleine-König

pwm: Check for CONFIG_PWM using IS_REACHABLE() in main header

2025-02-28T22:56:07+00:00

Preparing CONFIG_PWM becoming tristate the right magic to check for the availability of the pwm functions is using IS_REACHABLE() and not IS_ENABLED(). The latter gives the wrong result for built-in code with CONFIG_PWM=m. Signed-off-by: Uwe Kleine-König Link: https://lore.kernel.org/r/20250217102504.687916-2-u.kleine-koenig@baylibre.com Signed-off-by: Uwe Kleine-König

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

2025-01-27T23:45:29+00:00

Pull pwm fixes from Uwe Kleine-König: "Two fixes. Conor Dooley found and fixed a problem in the pwm-microchip-core driver that existed since the driver's birth in v6.5-rc1. It's about a corner case that only happens if two pwm devices of the same chip are set to the same long period. The other problem is about the new pwm API that currently is only supported by two hardware drivers. The fix prevents a NULL pointer exception if one of the new functions is called for a pwm device with a driver that only provides the old callbacks" * tag 'pwm/for-6.14-rc1-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/ukleinek/linux: pwm: Ensure callbacks exist before calling them pwm: microchip-core: fix incorrect comparison with max period