pwm: lpss: Add range limit check for the base_unit register value
authorHans de Goede <hdegoede@redhat.com>
Thu, 3 Sep 2020 11:23:24 +0000 (13:23 +0200)
committerHans de Goede <hdegoede@redhat.com>
Sun, 6 Sep 2020 13:37:59 +0000 (15:37 +0200)
commitef9f60daab309558c8bb3e086a9a11ee40bd6061
tree07da20ecca3f6393f6a72f4e0351fdbd8ebc70d8
parent181f4d2f44463fe09fe4df02e03095cb87151c29
pwm: lpss: Add range limit check for the base_unit register value

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 <andriy.shevchenko@linux.intel.com>
Acked-by: Thierry Reding <thierry.reding@gmail.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200903112337.4113-5-hdegoede@redhat.com
drivers/pwm/pwm-lpss.c