summaryrefslogtreecommitdiffstats
path: root/tools
diff options
context:
space:
mode:
authorThierry Reding <treding@nvidia.com>2019-11-08 17:07:46 +0100
committerGreg Kroah-Hartman <gregkh@linuxfoundation.org>2019-12-01 09:16:09 +0100
commit7cb8ee734c18eec586c8ed061696b6211a7f158c (patch)
treed768966ff76ca8bcc9bd61415e070f5b71f2fefa /tools
parent70d594d17ebb5c4e98bba6da2ec665fdbf82b0cb (diff)
downloadlinux-stable-7cb8ee734c18eec586c8ed061696b6211a7f158c.tar.gz
linux-stable-7cb8ee734c18eec586c8ed061696b6211a7f158c.tar.bz2
linux-stable-7cb8ee734c18eec586c8ed061696b6211a7f158c.zip
gpio: max77620: Fixup debounce delays
commit b0391479ae04dfcbd208b9571c375064caad9a57 upstream. When converting milliseconds to microseconds in commit fffa6af94894 ("gpio: max77620: Use correct unit for debounce times") some ~1 ms gaps were introduced between the various ranges supported by the controller. Fix this by changing the start of each range to the value immediately following the end of the previous range. This way a debounce time of, say 8250 us will translate into 16 ms instead of returning an -EINVAL error. Typically the debounce delay is only ever set through device tree and specified in milliseconds, so we can never really hit this issue because debounce times are always a multiple of 1000 us. The only notable exception for this is drivers/mmc/host/mmc-spi.c where the CD GPIO is requested, which passes a 1 us debounce time. According to a comment preceeding that code this should actually be 1 ms (i.e. 1000 us). Reported-by: Pavel Machek <pavel@denx.de> Signed-off-by: Thierry Reding <treding@nvidia.com> Acked-by: Pavel Machek <pavel@denx.de> Cc: <stable@vger.kernel.org> Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Diffstat (limited to 'tools')
0 files changed, 0 insertions, 0 deletions