kernel/drivers/pwm, branch linux-5.8.y

pwm: img: Fix null pointer access in probe

2020-10-29T09:08:06Z

[ Upstream commit b39c0615d0667b3a6f2f5c4bf99ffadf3b518bb1 ] dev_get_drvdata() is called in img_pwm_runtime_resume() before the driver data is set. When pm_runtime_enabled() returns false in img_pwm_probe() it calls img_pwm_runtime_resume() which results in a null pointer access. This patch fixes the problem by setting the driver data earlier in the img_pwm_probe() function. This crash was seen when booting the Imagination Technologies Creator Ci40 (Marduk) with kernel 5.4 in OpenWrt. Fixes: e690ae526216 ("pwm: img: Add runtime PM") Signed-off-by: Hauke Mehrtens Acked-by: Lee Jones Signed-off-by: Thierry Reding Signed-off-by: Sasha Levin

pwm: rockchip: Keep enabled PWMs running while probing

2020-10-29T09:08:06Z

[ Upstream commit 457f74abbed060a0395f75ab5297f2d76cada516 ] Following commit cfc4c189bc70 ("pwm: Read initial hardware state at request time") the Rockchip PWM driver can no longer assume a device's pwm_state structure has been populated after a call to pwmchip_add(). Consequently, the test in rockchip_pwm_probe() intended to prevent the driver from stopping PWM devices already enabled by the bootloader no longer functions reliably and this can lead to the kernel hanging during startup, particularly on devices like the Pinebook Pro that use a PWM-controlled backlight for their display. Avoid this by querying the device directly at probe time to determine whether or not it is enabled. Fixes: cfc4c189bc70 ("pwm: Read initial hardware state at request time") Signed-off-by: Simon South Reviewed-by: Uwe Kleine-König Reviewed-by: Heiko Stuebner Signed-off-by: Thierry Reding Signed-off-by: Sasha Levin

pwm: lpss: Add range limit check for the base_unit register value

2020-10-29T09:07:35Z

[ Upstream commit ef9f60daab309558c8bb3e086a9a11ee40bd6061 ] When the user requests a high enough period ns value, then the calculations in pwm_lpss_prepare() might result in a base_unit value of 0. But according to the data-sheet the way the PWM controller works is that each input clock-cycle the base_unit gets added to a N bit counter and that counter overflowing determines the PWM output frequency. Adding 0 to the counter is a no-op. The data-sheet even explicitly states that writing 0 to the base_unit bits will result in the PWM outputting a continuous 0 signal. When the user requestes a low enough period ns value, then the calculations in pwm_lpss_prepare() might result in a base_unit value which is bigger then base_unit_range - 1. Currently the codes for this deals with this by applying a mask: base_unit &= (base_unit_range - 1); But this means that we let the value overflow the range, we throw away the higher bits and store whatever value is left in the lower bits into the register leading to a random output frequency, rather then clamping the output frequency to the highest frequency which the hardware can do. This commit fixes both issues by clamping the base_unit value to be between 1 and (base_unit_range - 1). Fixes: 684309e5043e ("pwm: lpss: Avoid potential overflow of base_unit") Reviewed-by: Andy Shevchenko Acked-by: Thierry Reding Signed-off-by: Hans de Goede Link: https://patchwork.freedesktop.org/patch/msgid/20200903112337.4113-5-hdegoede@redhat.com Signed-off-by: Sasha Levin

pwm: lpss: Fix off by one error in base_unit math in pwm_lpss_prepare()

2020-10-29T09:07:34Z

[ Upstream commit 181f4d2f44463fe09fe4df02e03095cb87151c29 ] According to the data-sheet the way the PWM controller works is that each input clock-cycle the base_unit gets added to a N bit counter and that counter overflowing determines the PWM output frequency. So assuming e.g. a 16 bit counter this means that if base_unit is set to 1, after 65535 input clock-cycles the counter has been increased from 0 to 65535 and it will overflow on the next cycle, so it will overflow after every 65536 clock cycles and thus the calculations done in pwm_lpss_prepare() should use 65536 and not 65535. This commit fixes this. Note this also aligns the calculations in pwm_lpss_prepare() with those in pwm_lpss_get_state(). Note this effectively reverts commit 684309e5043e ("pwm: lpss: Avoid potential overflow of base_unit"). The next patch in this series really fixes the potential overflow of the base_unit value. Fixes: 684309e5043e ("pwm: lpss: Avoid potential overflow of base_unit") Reviewed-by: Andy Shevchenko Acked-by: Uwe Kleine-König Acked-by: Thierry Reding Signed-off-by: Hans de Goede Link: https://patchwork.freedesktop.org/patch/msgid/20200903112337.4113-4-hdegoede@redhat.com Signed-off-by: Sasha Levin

pwm: bcm-iproc: handle clk_get_rate() return

2020-08-21T11:15:12Z

[ Upstream commit 6ced5ff0be8e94871ba846dfbddf69d21363f3d7 ] Handle clk_get_rate() returning 0 to avoid possible division by zero. Fixes: daa5abc41c80 ("pwm: Add support for Broadcom iProc PWM controller") Signed-off-by: Rayagonda Kokatanur Signed-off-by: Scott Branden Reviewed-by: Ray Jui Reviewed-by: Uwe Kleine-König Signed-off-by: Thierry Reding Signed-off-by: Sasha Levin

pwm: Add missing "CONFIG_" prefix

2020-06-04T17:09:28Z

The IS_ENABLED() use was missing the CONFIG_ prefix which would have lead to skipping this code. Fixes: 3ad1f3a33286 ("pwm: Implement some checks for lowlevel drivers") Signed-off-by: Kees Cook Reviewed-by: Uwe Kleine-König Signed-off-by: Thierry Reding

pwm: imx27: Fix rounding behavior

2020-06-02T13:50:52Z

To not trigger the warnings provided by CONFIG_PWM_DEBUG - use up-rounding in .get_state() - don't divide by the result of a division - don't use the rounded counter value for the period length to calculate the counter value for the duty cycle Signed-off-by: Uwe Kleine-König Signed-off-by: Thierry Reding

pwm: rockchip: Simplify rockchip_pwm_get_state()

2020-06-02T13:50:52Z

The way state->enabled is computed is rather convoluted and hard to read - both branches of the if() actually do the exact same thing. So remove the if(), and further simplify " ? true : false" to "". Signed-off-by: Rasmus Villemoes Signed-off-by: Thierry Reding

pwm: img: Call pm_runtime_put() in pm_runtime_get_sync() failed case

2020-06-02T13:50:51Z

Even in failed case of pm_runtime_get_sync(), the usage_count is incremented. In order to keep the usage_count with correct value call appropriate pm_runtime_put(). Signed-off-by: Navid Emamdoost Signed-off-by: Thierry Reding

pwm: tegra: Support dynamic clock frequency configuration

2020-06-02T12:25:37Z

Added support for dynamic clock freq configuration in PWM kernel driver. Earlier the PWM driver used to cache boot time clock rate by PWM clock parent during probe. Hence dynamically changing PWM frequency was not possible for all the possible ranges. With this change, dynamic calculation is enabled and it is able to set the requested period from sysfs knob provided the value is supported by clock source. Changes mainly have 2 parts: - Tegra186 and later chips [1] - Tegra210 and prior chips [2] For [1] - Changes implemented to set pwm period dynamically and also checks added to allow only if requested period(ns) is below or equals to higher range. For [2] - Only checks if the requested period(ns) is below or equals to higher range defined by max clock limit. The limitation in Tegra210 or prior chips are due to the reason of having only one PWM controller supporting multiple channels. But later chips have multiple PWM controller instances each having single channel support. Signed-off-by: Sandipan Patra Reviewed-by: Jon Hunter Signed-off-by: Thierry Reding