On Tue, Apr 06, 2021 at 09:30:36AM +0200, Uwe Kleine-König wrote: > Given that lowlevel drivers usually cannot implement exactly what a > consumer requests with pwm_apply_state() there is some rounding involved. > > pwm_get_state() traditionally returned the setting that was requested most > recently by the consumer (opposed to what was actually implemented in > hardware in reply to the last request). To make this semantic obvious > rename the function. > > Signed-off-by: Uwe Kleine-König > --- > Documentation/driver-api/pwm.rst | 6 +++- > drivers/clk/clk-pwm.c | 2 +- > drivers/gpu/drm/i915/display/intel_panel.c | 4 +-- > drivers/input/misc/da7280.c | 2 +- > drivers/input/misc/pwm-beeper.c | 2 +- > drivers/input/misc/pwm-vibra.c | 4 +-- > drivers/pwm/core.c | 4 +-- > drivers/pwm/pwm-atmel-hlcdc.c | 2 +- > drivers/pwm/pwm-atmel.c | 2 +- > drivers/pwm/pwm-imx27.c | 2 +- > drivers/pwm/pwm-rockchip.c | 2 +- > drivers/pwm/pwm-stm32-lp.c | 4 +-- > drivers/pwm/pwm-sun4i.c | 2 +- > drivers/pwm/sysfs.c | 18 ++++++------ > drivers/regulator/pwm-regulator.c | 4 +-- > drivers/video/backlight/pwm_bl.c | 10 +++---- > include/linux/pwm.h | 34 ++++++++++++++-------- > 17 files changed, 59 insertions(+), 45 deletions(-) Honestly, I don't think this is worth the churn. If you think people will easily get confused by this then a better solution might be to more explicitly document the pwm_get_state() function to say exactly what it returns. But there's no need to make life difficult for everyone by renaming this to something as cumbersome as this. Thierry