Linux kernel stable tree (mirror) https://git.radix-linux.su/kernel/linux.git/atom?h=v5.15.7 2021-11-18T18:17:01+00:00 2021-11-18T18:17:01+00:00 John Keeping john@metanate.com 2021-10-06T18:06:03+00:00 urn:sha1:d36d2c35fd98259de4b4f44d877365369eb19534 [ Upstream commit 2667f6b7af99e81958fa97c03bb519fcb09d0055 ] I have a ST1633 touch controller which fails to probe due to a timeout waiting for the controller to become ready. Increasing the minimum delay to 100ms ensures that the probe sequence completes successfully. The ST1633 datasheet says nothing about the maximum delay here and the ST1232 I2C protocol document says "wait until" with no notion of a timeout. Since this only runs once during probe, being generous with the timout seems reasonable and most likely the device will become ready eventually. (It may be worth noting that I saw this issue with a PREEMPT_RT patched kernel which probably has tighter wakeups from usleep_range() than other preemption models.) Fixes: f605be6a57b4 ("Input: st1232 - wait until device is ready before reading resolution") Signed-off-by: John Keeping <john@metanate.com> Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be> Link: https://lore.kernel.org/r/20210929152609.2421483-1-john@metanate.com Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com> Signed-off-by: Sasha Levin <sashal@kernel.org> 2021-11-18T18:16:59+00:00 Mark Brown broonie@kernel.org 2021-10-02T04:20:49+00:00 urn:sha1:1721649965e4ec2a656d505191b59120c9f813f5 [ Upstream commit 5c4c2c8e6fac26fa0b80c234d6e9f75d637193af ] Currently autoloading for SPI devices does not use the DT ID table, it uses SPI modalises. Supporting OF modalises is going to be difficult if not impractical, an attempt was made but has been reverted, so ensure that module autoloading works for this driver by adding a SPI device ID table. Fixes: 96c8395e2166 ("spi: Revert modalias changes") Signed-off-by: Mark Brown <broonie@kernel.org> Link: https://lore.kernel.org/r/20210927134104.38648-1-broonie@kernel.org Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com> Signed-off-by: Sasha Levin <sashal@kernel.org> 2021-11-18T18:15:51+00:00 Takashi Iwai tiwai@suse.de 2021-11-03T07:00:19+00:00 urn:sha1:82e2f47f26a2e6589c3f95956232ac0242d29a6f commit 16e28abb7290c4ca3b3a0f333ba067f34bb18c86 upstream. Fujitsu Lifebook T725 laptop requires, like a few other similar models, the nomux and notimeout options to probe the touchpad properly. This patch adds the corresponding quirk entries. BugLink: https://bugzilla.suse.com/show_bug.cgi?id=1191980 Tested-by: Neal Gompa <ngompa13@gmail.com> Cc: <stable@vger.kernel.org> Signed-off-by: Takashi Iwai <tiwai@suse.de> Link: https://lore.kernel.org/r/20211103070019.13374-1-tiwai@suse.de Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 2021-11-18T18:15:51+00:00 Phoenix Huang phoenix@emc.com.tw 2021-11-08T06:00:03+00:00 urn:sha1:4f43e1c69280313f121283cb5c16e5e0b1036b3a commit be896bd3b72b44126c55768f14c22a8729b0992e upstream. Some firmwares occasionally report bogus data from trackpoint, with X or Y displacement being too large (outside of [-127, 127] range). Let's drop such packets so that we do not generate jumps. Signed-off-by: Phoenix Huang <phoenix@emc.com.tw> Tested-by: Yufei Du <yufeidu@cs.unc.edu> Link: https://lore.kernel.org/r/20210729010940.5752-1-phoenix@emc.com.tw Cc: stable@vger.kernel.org Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 2021-11-18T18:15:51+00:00 Johan Hovold johan@kernel.org 2021-11-10T06:58:01+00:00 urn:sha1:6655277462f3aba630181eb4697bd1dccba371c9 commit 744d0090a5f6dfa4c81b53402ccdf08313100429 upstream. USB control-message timeouts are specified in milliseconds and should specifically not vary with CONFIG_HZ. Fixes: 487358627825 ("Input: iforce - use DMA-safe buffer when getting IDs from USB") Signed-off-by: Johan Hovold <johan@kernel.org> Cc: stable@vger.kernel.org # 5.3 Link: https://lore.kernel.org/r/20211025115501.5190-1-johan@kernel.org Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 2021-10-18T02:57:06+00:00 Linus Torvalds torvalds@linux-foundation.org 2021-10-18T02:57:06+00:00 urn:sha1:12dbbfadd8f4e54607463414b06f9416a5c6d981 Pull input fixes from Dmitry Torokhov: - a new product ID for the xpad joystick driver - fixes to resistive-adc-touch and snvs_pwrkey drivers - a change to touchscreen helpers to make clang happier * 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/dtor/input: Input: touchscreen - avoid bitwise vs logical OR warning Input: xpad - add support for another USB ID of Nacon GC-100 Input: resistive-adc-touch - fix division by zero error on z1 == 0 Input: snvs_pwrkey - add clk handling 2021-10-16T05:22:54+00:00 Nathan Chancellor nathan@kernel.org 2021-10-15T20:13:06+00:00 urn:sha1:a02dcde595f7cbd240ccd64de96034ad91cffc40 A new warning in clang points out a few places in this driver where a bitwise OR is being used with boolean types: drivers/input/touchscreen.c:81:17: warning: use of bitwise '|' with boolean operands [-Wbitwise-instead-of-logical] data_present = touchscreen_get_prop_u32(dev, "touchscreen-min-x", ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ This use of a bitwise OR is intentional, as bitwise operations do not short circuit, which allows all the calls to touchscreen_get_prop_u32() to happen so that the last parameter is initialized while coalescing the results of the calls to make a decision after they are all evaluated. To make this clearer to the compiler, use the '|=' operator to assign the result of each touchscreen_get_prop_u32() call to data_present, which keeps the meaning of the code the same but makes it obvious that every one of these calls is expected to happen. Signed-off-by: Nathan Chancellor <nathan@kernel.org> Reported-by: Nick Desaulniers <ndesaulniers@google.com> Reviewed-by: Nick Desaulniers <ndesaulniers@google.com> Link: https://lore.kernel.org/r/20211014205757.3474635-1-nathan@kernel.org Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com> 2021-10-16T05:11:04+00:00 Michael Cullen michael@michaelcullen.name 2021-10-15T20:17:50+00:00 urn:sha1:3378a07daa6cdd11e042797454c706d1c69f9ca6 The Nacon GX100XF is already mapped, but it seems there is a Nacon GC-100 (identified as NC5136Wht PCGC-100WHITE though I believe other colours exist) with a different USB ID when in XInput mode. Signed-off-by: Michael Cullen <michael@michaelcullen.name> Link: https://lore.kernel.org/r/20211015192051.5196-1-michael@michaelcullen.name Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com> 2021-10-16T05:11:03+00:00 Oleksij Rempel o.rempel@pengutronix.de 2021-10-16T04:12:06+00:00 urn:sha1:fe0a7e3d012738b0034b3c97ddb0e8bc0a3ff0e6 For proper pressure calculation we need at least x and z1 to be non zero. Even worse, in case z1 we may run in to division by zero error. Fixes: 60b7db914ddd ("Input: resistive-adc-touch - rework mapping of channels") Signed-off-by: Oleksij Rempel <o.rempel@pengutronix.de> Link: https://lore.kernel.org/r/20211007095727.29579-1-o.rempel@pengutronix.de Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com> 2021-10-16T05:11:01+00:00 Uwe Kleine-König u.kleine-koenig@pengutronix.de 2021-10-16T04:19:33+00:00 urn:sha1:d997cc1715df7b6c3df798881fb9941acf0079f8 On i.MX7S and i.MX8M* (but not i.MX6*) the pwrkey device has an associated clock. Accessing the registers requires that this clock is enabled. Binding the driver on at least i.MX7S and i.MX8MP while not having the clock enabled results in a complete hang of the machine. (This usually only happens if snvs_pwrkey is built as a module and the rtc-snvs driver isn't already bound because at bootup the required clk is on and only gets disabled when the clk framework disables unused clks late during boot.) This completes the fix in commit 135be16d3505 ("ARM: dts: imx7s: add snvs clock to pwrkey"). Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Link: https://lore.kernel.org/r/20211013062848.2667192-1-u.kleine-koenig@pengutronix.de Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>