* Re: [PATCH] Input: mcs_touchkey - use struct_size() in kzalloc()
From: Gustavo A. R. Silva @ 2019-01-14 17:27 UTC (permalink / raw)
To: Dmitry Torokhov; +Cc: linux-input, linux-kernel
In-Reply-To: <20190114063102.GA217283@dtor-ws>
On 1/14/19 12:31 AM, Dmitry Torokhov wrote:
>>
>> Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com>
>
> Applied, thank you.
>
Thanks, Dmitry.
--
Gustavo
^ permalink raw reply
* Re: [PATCH 3/3] input: touchscreen: fix link error
From: Dmitry Torokhov @ 2019-01-14 18:32 UTC (permalink / raw)
To: Anders Roxell; +Cc: linux-input, linux-kernel
In-Reply-To: <20190114095754.23175-1-anders.roxell@linaro.org>
On Mon, Jan 14, 2019 at 10:57:54AM +0100, Anders Roxell wrote:
> Fix link error when TOUCHSCREEN_RASPBERRYPI_FW is enabled as a module
> and the dependent module is built-in.
> The 'depends on RASPBERRYPI_FIRMWARE' by itself prevents the touchscreen
> driver from being built-in when the firmware is configured as a module.
> However, the '|| COMPILE_TEST' still allows it unless we explicitly
> prevent that configuration with '|| (RASPBERRYPI_FIRMWARE=n &&
> COMPILE_TEST)'
>
> ld: drivers/input/touchscreen/raspberrypi-ts.o: in function `rpi_ts_probe':
> raspberrypi-ts.c:(.text+0x3a8): undefined reference to `rpi_firmware_get'
> ld: raspberrypi-ts.c:(.text+0x3a8): relocation truncated to fit: R_AARCH64_CALL26 against undefined symbol `rpi_firmware_get'
> ld: raspberrypi-ts.c:(.text+0x4c8): undefined reference to `rpi_firmware_property'
> ld: raspberrypi-ts.c:(.text+0x4c8): relocation truncated to fit: R_AARCH64_CALL26 against undefined symbol `rpi_firmware_property'
>
> Rework so that TOUCHSCREEN_RASPBERRYPI_FW depends on
> RASPBERRYPI_FIRMWARE=n if COMPILE_TEST is enabled.
>
> Suggested-by: Arnd Bergmann <arnd@arndb.de>
> Signed-off-by: Anders Roxell <anders.roxell@linaro.org>
Applied, thank you.
> ---
> drivers/input/touchscreen/Kconfig | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/input/touchscreen/Kconfig b/drivers/input/touchscreen/Kconfig
> index af6027cc7bbf..068dbbc610fc 100644
> --- a/drivers/input/touchscreen/Kconfig
> +++ b/drivers/input/touchscreen/Kconfig
> @@ -698,7 +698,7 @@ config TOUCHSCREEN_EDT_FT5X06
>
> config TOUCHSCREEN_RASPBERRYPI_FW
> tristate "Raspberry Pi's firmware base touch screen support"
> - depends on RASPBERRYPI_FIRMWARE || COMPILE_TEST
> + depends on RASPBERRYPI_FIRMWARE || (RASPBERRYPI_FIRMWARE=n && COMPILE_TEST)
> help
> Say Y here if you have the official Raspberry Pi 7 inch screen on
> your system.
> --
> 2.19.2
>
--
Dmitry
^ permalink raw reply
* Re: [PATCH] Input: synaptics - add PNP IDs for Dell XPS models to forcepad
From: Dmitry Torokhov @ 2019-01-14 18:40 UTC (permalink / raw)
To: Kim Phillips, Benjamin Tissoires; +Cc: linux-kernel, Paul Menzel, linux-input
In-Reply-To: <22e2d619-0622-1816-2057-c9005288b46b@kimphillips.com>
On Sat, Jan 12, 2019 at 04:04:36PM -0600, Kim Phillips wrote:
> On 1/11/19 7:40 PM, Dmitry Torokhov wrote:
> > Hi Kim,
>
> Hi Dmitry,
>
> > On Fri, Jan 11, 2019 at 02:54:30PM -0600, Kim Phillips wrote:
> >> This patch is the result of seeing this message:
> >>
> >> psmouse serio1: synaptics: Your touchpad (PNP: DLL087c PNP0f13) says it can support a different bus. If i2c-hid and hid-rmi are not used, you might want to try setting psmouse.synaptics_intertouch to 1 and report this to linux-input@vger.kernel.org.
> >>
> >> If I set psmouse.synaptics_intertouch=1, or add the PNP ID to
> >> smbus_pnp_ids, the touchpad continues to work, and the above message
> >> goes away, but we now get:
> >>
> >> psmouse serio1: synaptics: Trying to set up SMBus access
> >> psmouse serio1: synaptics: SMbus companion is not ready yet
> >>
> >> With this patch applied, i.e., the PNP IDs are added to the forcepad
> >> array, the touchpad continues to work and all of the above messages
> >> disappear.
> >
> > Are you sure the touchpad in XPSes is a forcepad (i.e. it does not have
> > physical button underneath it)? As far as I know there were only couple
> > of HP laptops with forcepads and when switching to RMI mode forcepads
> > need F21 handler that we do not currently have in the kernel.
>
> I see, no, I'm not sure, but assuming you're right, the IDs
> should be added to the smbus array instead, after fixing
> the SMbus "companion not ready" problem? Pointers for that and
> the below interrupts when touchpad idle after resume, welcome.
>
> Also, the link to get the RMI4 spec in
> Documentation/devicetree/bindings/input/rmi4/rmi_2d_sensor.txt
> is broken. Any pointers for that also appreciated.
OK, sorting it all out some more:
- because we do not have support for F21 necessary for forcepads adding
APIC ID to forcepad list actuallty disables SMbus companion mode, that
is why you no longer see "companion not ready" messages vs. setting
psmouse.synaptics_intertouch=1 module parameter.
- this does not really matter as your touchpad ends up being driven by
i2c-hid and hid-multitouch drivers, and that is how we wait it to
work, as we do not want to deviate from behavior on Windows since OEM
tested it (the device and firmware) in tha configuration.
- we need to figure out issue with interrupts on resume, maybe Benjamin
have seen it?
Thanks.
--
Dmitry
^ permalink raw reply
* UBSAN: Undefined behaviour in drivers/input/misc/uinput.c
From: Kyungtae Kim @ 2019-01-14 21:19 UTC (permalink / raw)
To: Dmitry Torokhov, rydberg
Cc: Byoungyoung Lee, DaeRyong Jeong, syzkaller, linux-kernel,
linux-input
We report a bug in linux-4.19.13: "UBSAN: Undefined behaviour in
drivers/input/misc/uinput.c"
kernel config: https://kt0755.github.io/etc/config_4.19.13
repro: https://kt0755.github.io/etc/repro.c4925.c
An integer overflow arose in uinput_validate_absinfo
(drivers/input/misc/uinput.c:420).
To be specific, "if (abs->flat > max - min)" cannot be represented in
type 'int'.
Thing is, in this case, abs->flat, max and min come from user supplied input.
To fix, an appropriate sanity check of that calculation should be
placed right before the usage.
=========================================
UBSAN: Undefined behaviour in drivers/input/misc/uinput.c:420:22
signed integer overflow:
841280591 - -1832774988 cannot be represented in type 'int'
CPU: 0 PID: 7372 Comm: syz-executor3 Not tainted 4.19.13 #1
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
Call Trace:
__dump_stack lib/dump_stack.c:77 [inline]
dump_stack+0xd2/0x148 lib/dump_stack.c:113
ubsan_epilogue+0x12/0x94 lib/ubsan.c:159
handle_overflow+0x1cf/0x21a lib/ubsan.c:190
__ubsan_handle_sub_overflow+0x2a/0x31 lib/ubsan.c:206
uinput_validate_absinfo.isra.2+0x194/0x1a0 drivers/input/misc/uinput.c:420
uinput_abs_setup drivers/input/misc/uinput.c:503 [inline]
uinput_ioctl_handler+0xa57/0x1bf0 drivers/input/misc/uinput.c:1036
uinput_ioctl+0x2d/0x40 drivers/input/misc/uinput.c:1048
vfs_ioctl fs/ioctl.c:46 [inline]
do_vfs_ioctl+0x1aa/0x1160 fs/ioctl.c:690
ksys_ioctl+0x9e/0xb0 fs/ioctl.c:705
__do_sys_ioctl fs/ioctl.c:712 [inline]
__se_sys_ioctl fs/ioctl.c:710 [inline]
__x64_sys_ioctl+0x7e/0xc0 fs/ioctl.c:710
do_syscall_64+0xc4/0x510 arch/x86/entry/common.c:290
entry_SYSCALL_64_after_hwframe+0x49/0xbe
RIP: 0033:0x4497b9
Code: e8 8c 9f 02 00 48 83 c4 18 c3 0f 1f 80 00 00 00 00 48 89 f8 48
89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d
01 f0 ff ff 0f 83 9b 6b fc ff c3 66 2e 0f 1f 84 00 00 00 00
RSP: 002b:00007f7b273c3c68 EFLAGS: 00000246 ORIG_RAX: 0000000000000010
RAX: ffffffffffffffda RBX: 00007f7b273c46cc RCX: 00000000004497b9
RDX: 0000000020000000 RSI: 0000004040105504 RDI: 0000000000000013
RBP: 000000000071bea0 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000246 R12: 00000000ffffffff
R13: 0000000000005ca0 R14: 00000000006eed40 R15: 00007f7b273c4700
=========================================
Thanks,
Kyungtae Kim
^ permalink raw reply
* [PATCH] Input: uinput - fix undefined behavior in uinput_validate_absinfo()
From: Dmitry Torokhov @ 2019-01-14 22:04 UTC (permalink / raw)
To: linux-input
Cc: Byoungyoung Lee, rydberg, DaeRyong Jeong, syzkaller,
Peter Hutterer, linux-kernel
An integer overflow may arise in uinput_validate_absinfo() if "max - min"
can't be represented by an "int". We should check for overflow before
trying to use the result.
Reported-by: Kyungtae Kim <kt0755@gmail.com>
Cc: stable@vger.kernel.org
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
---
drivers/input/misc/uinput.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/input/misc/uinput.c b/drivers/input/misc/uinput.c
index 8ec483e8688b..26ec603fe220 100644
--- a/drivers/input/misc/uinput.c
+++ b/drivers/input/misc/uinput.c
@@ -39,6 +39,7 @@
#include <linux/init.h>
#include <linux/fs.h>
#include <linux/miscdevice.h>
+#include <linux/overflow.h>
#include <linux/input/mt.h>
#include "../input-compat.h"
@@ -405,7 +406,7 @@ static int uinput_open(struct inode *inode, struct file *file)
static int uinput_validate_absinfo(struct input_dev *dev, unsigned int code,
const struct input_absinfo *abs)
{
- int min, max;
+ int min, max, range;
min = abs->minimum;
max = abs->maximum;
@@ -417,7 +418,7 @@ static int uinput_validate_absinfo(struct input_dev *dev, unsigned int code,
return -EINVAL;
}
- if (abs->flat > max - min) {
+ if (check_sub_overflow(max, min, &range) && abs->flat > range) {
printk(KERN_DEBUG
"%s: abs_flat #%02x out of range: %d (min:%d/max:%d)\n",
UINPUT_NAME, code, abs->flat, min, max);
--
2.20.1.97.g81188d93c3-goog
--
Dmitry
^ permalink raw reply related
* Re: [PATCH] Input: uinput - fix undefined behavior in uinput_validate_absinfo()
From: Dmitry Torokhov @ 2019-01-14 22:07 UTC (permalink / raw)
To: linux-input
Cc: Byoungyoung Lee, rydberg, DaeRyong Jeong, syzkaller,
Peter Hutterer, linux-kernel
In-Reply-To: <20190114220448.GA241112@dtor-ws>
On Mon, Jan 14, 2019 at 02:04:48PM -0800, Dmitry Torokhov wrote:
> An integer overflow may arise in uinput_validate_absinfo() if "max - min"
> can't be represented by an "int". We should check for overflow before
> trying to use the result.
>
> Reported-by: Kyungtae Kim <kt0755@gmail.com>
> Cc: stable@vger.kernel.org
> Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
> ---
> drivers/input/misc/uinput.c | 5 +++--
> 1 file changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/input/misc/uinput.c b/drivers/input/misc/uinput.c
> index 8ec483e8688b..26ec603fe220 100644
> --- a/drivers/input/misc/uinput.c
> +++ b/drivers/input/misc/uinput.c
> @@ -39,6 +39,7 @@
> #include <linux/init.h>
> #include <linux/fs.h>
> #include <linux/miscdevice.h>
> +#include <linux/overflow.h>
> #include <linux/input/mt.h>
> #include "../input-compat.h"
>
> @@ -405,7 +406,7 @@ static int uinput_open(struct inode *inode, struct file *file)
> static int uinput_validate_absinfo(struct input_dev *dev, unsigned int code,
> const struct input_absinfo *abs)
> {
> - int min, max;
> + int min, max, range;
>
> min = abs->minimum;
> max = abs->maximum;
> @@ -417,7 +418,7 @@ static int uinput_validate_absinfo(struct input_dev *dev, unsigned int code,
> return -EINVAL;
> }
>
> - if (abs->flat > max - min) {
> + if (check_sub_overflow(max, min, &range) && abs->flat > range) {
This should be !check_sub_overflow(...) of course.
> printk(KERN_DEBUG
> "%s: abs_flat #%02x out of range: %d (min:%d/max:%d)\n",
> UINPUT_NAME, code, abs->flat, min, max);
> --
> 2.20.1.97.g81188d93c3-goog
>
>
> --
> Dmitry
--
Dmitry
^ permalink raw reply
* Re: [PATCH] Input: uinput - fix undefined behavior in uinput_validate_absinfo()
From: Peter Hutterer @ 2019-01-14 22:41 UTC (permalink / raw)
To: Dmitry Torokhov
Cc: linux-input, Byoungyoung Lee, rydberg, DaeRyong Jeong, syzkaller,
linux-kernel
In-Reply-To: <20190114220756.GF117329@dtor-ws>
On Mon, Jan 14, 2019 at 02:07:56PM -0800, Dmitry Torokhov wrote:
> On Mon, Jan 14, 2019 at 02:04:48PM -0800, Dmitry Torokhov wrote:
> > An integer overflow may arise in uinput_validate_absinfo() if "max - min"
> > can't be represented by an "int". We should check for overflow before
> > trying to use the result.
> >
> > Reported-by: Kyungtae Kim <kt0755@gmail.com>
> > Cc: stable@vger.kernel.org
> > Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
> > ---
> > drivers/input/misc/uinput.c | 5 +++--
> > 1 file changed, 3 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/input/misc/uinput.c b/drivers/input/misc/uinput.c
> > index 8ec483e8688b..26ec603fe220 100644
> > --- a/drivers/input/misc/uinput.c
> > +++ b/drivers/input/misc/uinput.c
> > @@ -39,6 +39,7 @@
> > #include <linux/init.h>
> > #include <linux/fs.h>
> > #include <linux/miscdevice.h>
> > +#include <linux/overflow.h>
> > #include <linux/input/mt.h>
> > #include "../input-compat.h"
> >
> > @@ -405,7 +406,7 @@ static int uinput_open(struct inode *inode, struct file *file)
> > static int uinput_validate_absinfo(struct input_dev *dev, unsigned int code,
> > const struct input_absinfo *abs)
> > {
> > - int min, max;
> > + int min, max, range;
> >
> > min = abs->minimum;
> > max = abs->maximum;
> > @@ -417,7 +418,7 @@ static int uinput_validate_absinfo(struct input_dev *dev, unsigned int code,
> > return -EINVAL;
> > }
> >
> > - if (abs->flat > max - min) {
> > + if (check_sub_overflow(max, min, &range) && abs->flat > range) {
>
> This should be !check_sub_overflow(...) of course.
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net> with that in place,
thanks.
Cheers,
Peter
> > printk(KERN_DEBUG
> > "%s: abs_flat #%02x out of range: %d (min:%d/max:%d)\n",
> > UINPUT_NAME, code, abs->flat, min, max);
> > --
> > 2.20.1.97.g81188d93c3-goog
> >
> >
> > --
> > Dmitry
>
> --
> Dmitry
^ permalink raw reply
* Re: [PATCH v5 2/3] Input: atmel_mxt_ts: Wait for device be ready for communication
From: Dmitry Torokhov @ 2019-01-15 0:42 UTC (permalink / raw)
To: Paweł Chmiel
Cc: nick, robh+dt, mark.rutland, nicolas.ferre, alexandre.belloni,
linux-input, devicetree, linux-arm-kernel, linux-kernel
In-Reply-To: <20181214151214.5391-3-pawel.mikolaj.chmiel@gmail.com>
On Fri, Dec 14, 2018 at 04:12:13PM +0100, Paweł Chmiel wrote:
> According to documentation, device isn't ready for communication,
> until firmware asserts the CHG line. Add missing wait for this.
>
> Signed-off-by: Paweł Chmiel <pawel.mikolaj.chmiel@gmail.com>
> ---
> Changes from v1:
> - Fix checkpatch issues
> ---
> drivers/input/touchscreen/atmel_mxt_ts.c | 11 +++++++++++
> 1 file changed, 11 insertions(+)
>
> diff --git a/drivers/input/touchscreen/atmel_mxt_ts.c b/drivers/input/touchscreen/atmel_mxt_ts.c
> index 55a107fc1b73..e8949c6ceafa 100644
> --- a/drivers/input/touchscreen/atmel_mxt_ts.c
> +++ b/drivers/input/touchscreen/atmel_mxt_ts.c
> @@ -202,6 +202,7 @@ enum t100_type {
> #define MXT_CRC_TIMEOUT 1000 /* msec */
> #define MXT_FW_RESET_TIME 3000 /* msec */
> #define MXT_FW_CHG_TIMEOUT 300 /* msec */
> +#define MXT_POWERON_DELAY 150 /* msec */
>
> /* Command to unlock bootloader */
> #define MXT_UNLOCK_CMD_MSB 0xaa
> @@ -3070,6 +3071,16 @@ static int mxt_regulator_enable(struct mxt_data *data)
> msleep(MXT_REGULATOR_DELAY);
> gpiod_set_value(data->reset_gpio, 1);
> msleep(MXT_RESET_INVALID_CHG);
> +
> +retry_wait:
> + reinit_completion(&data->bl_completion);
> + data->in_bootloader = true;
I think you would want to reinit the ocmpletion and set the flag before
releasing reset line and sleeping, otherwise if interrupt fires too
early you'll be spinning for extra time.
I'd also really want to hear from Nick on this change.
> + error = mxt_wait_for_completion(data, &data->bl_completion,
> + MXT_POWERON_DELAY);
> + if (error == -EINTR)
> + goto retry_wait;
> +
> + data->in_bootloader = false;
> }
>
> return 0;
> --
> 2.17.1
>
Thanks.
--
Dmitry
^ permalink raw reply
* Re: [PATCH v7 0/7] Introduce STPMIC1 PMIC Driver
From: dmitry.torokhov @ 2019-01-15 0:48 UTC (permalink / raw)
To: Lee Jones
Cc: Pascal PAILLET-LME, robh+dt@kernel.org, mark.rutland@arm.com,
lgirdwood@gmail.com, broonie@kernel.org, wim@linux-watchdog.org,
linux@roeck-us.net, linux-input@vger.kernel.org,
devicetree@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-watchdog@vger.kernel.org, benjamin.gaignard@linaro.org,
eballetbo@gmail.com, axel.lin@ingics.com
In-Reply-To: <20181214124701.GZ4497@dell>
On Fri, Dec 14, 2018 at 12:47:01PM +0000, Lee Jones wrote:
> On Fri, 30 Nov 2018, Pascal PAILLET-LME wrote:
>
> > The goal of this patch-set is to propose a driver for the STPMIC1 PMIC from
> > STMicroelectronics.
> > The STPMIC1 regulators supply power to an application processor as well as
> > to external system peripherals such as DDR, Flash memories and system
> > devices. It also features onkey button input and an hardware watchdog.
> > The STPMIC1 is controlled via I2C.
> >
> > Main driver is drivers/mfd/stpmic1 that handle I2C regmap configuration and
> > irqchip. stpmic1_regulator, stpmic1_onkey and stpmic1_wdt need stpmic1 mfd
> > as parent.
> >
> > STPMIC1 MFD and regulator drivers maybe mandatory at boot time.
> >
> > Pascal Paillet (7):
> > changes in v7:
> > * rebase on regul/for-next
> >
> > dt-bindings: mfd: document stpmic1
> > mfd: stpmic1: add stpmic1 driver
> > dt-bindings: input: document stpmic1 pmic onkey
> > input: stpmic1: add stpmic1 onkey driver
> > dt-bindings: watchdog: document stpmic1 pmic watchdog
> > watchdog: stpmic1: add stpmic1 watchdog driver
> > regulator: stpmic1: fix regulator_lock usage
>
> Could you please remove any patches which have been applied and
> [RESEND]?
>
> Also, is Dmitry planning on Acking:
>
> dt-bindings: input: document stpmic1 pmic onkey
>
> ... or is Rob's Ack enough?
For bindings I normally defer to Rob (unless I see something that really
bugs me and then I'll speak up).
Thanks.
--
Dmitry
^ permalink raw reply
* Re: [PATCH V2 2/2] Input: rotaty-encoder - Add DT binding document
From: Dmitry Torokhov @ 2019-01-15 3:52 UTC (permalink / raw)
To: Donghoon Han; +Cc: linux-input, Daniel Mack, linux-kernel, devicetree
In-Reply-To: <20190107164249.2342-3-nazgul33@gmail.com>
On Tue, Jan 08, 2019 at 01:42:49AM +0900, Donghoon Han wrote:
> Add DT binding document for rotary-encoder, keycode options.
>
> Signed-off-by: Donghoon Han <nazgul33@gmail.com>
> Cc: Dmitry Torokhov <dmitry.torokhov@gmail.com>
> Cc: Daniel Mack <daniel@caiaq.de>
> Cc: devicetree@vger.kernel.org
> To: linux-input@vger.kernel.org
> ---
> .../devicetree/bindings/input/rotary-encoder.txt | 12 ++++++++++++
> 1 file changed, 12 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/input/rotary-encoder.txt b/Documentation/devicetree/bindings/input/rotary-encoder.txt
> index f99fe5cdeaec..9986ec2af2d4 100644
> --- a/Documentation/devicetree/bindings/input/rotary-encoder.txt
> +++ b/Documentation/devicetree/bindings/input/rotary-encoder.txt
> @@ -12,6 +12,10 @@ Optional properties:
> - rotary-encoder,relative-axis: register a relative axis rather than an
> absolute one. Relative axis will only generate +1/-1 events on the input
> device, hence no steps need to be passed.
> +- rotary-encoder,relative-keys : generate pair of key events. This setting
> + behaves just like relative-axis, generating key events instead.
> + (Keycodes[2] corresponds to -1/1 events.)
> +- rotary-encoder,relative-keycodes : keycodes for relative-keys
Given that keycodes are linux-specific, I think the property should be
linux,keycodes. Also, I am not sure we need separate
rotary-encoder,relative-keys property as we can infer that we want to
generate keys from presence of linux,keycodes property.
Rob, any comments?
> - rotary-encoder,rollover: Automatic rollover when the rotary value becomes
> greater than the specified steps or smaller than 0. For absolute axis only.
> - rotary-encoder,steps-per-period: Number of steps (stable states) per period.
> @@ -48,3 +52,11 @@ Example:
> rotary-encoder,encoding = "binary";
> rotary-encoder,rollover;
> };
> +
> + rotary@2 {
> + compatible = "rotary-encoder";
> + gpios = <&gpio 21 0>, <&gpio 22 0>;
> + rotary-encoder,relative-keys;
> + rotary-encoder,relative-keycode = <103>, <108>;
> + rotary-encoder,steps-per-period = <2>;
> + };
> --
> 2.17.1
>
Thanks.
--
Dmitry
^ permalink raw reply
* Re: [PATCH V2 2/2] Input: rotaty-encoder - Add DT binding document
From: Dmitry Torokhov @ 2019-01-15 3:53 UTC (permalink / raw)
To: Donghoon Han, Rob Herring
Cc: linux-input, Daniel Mack, linux-kernel, devicetree
In-Reply-To: <20190107164249.2342-3-nazgul33@gmail.com>
[ resending to Rob... ]
On Tue, Jan 08, 2019 at 01:42:49AM +0900, Donghoon Han wrote:
> Add DT binding document for rotary-encoder, keycode options.
>
> Signed-off-by: Donghoon Han <nazgul33@gmail.com>
> Cc: Dmitry Torokhov <dmitry.torokhov@gmail.com>
> Cc: Daniel Mack <daniel@caiaq.de>
> Cc: devicetree@vger.kernel.org
> To: linux-input@vger.kernel.org
> ---
> .../devicetree/bindings/input/rotary-encoder.txt | 12 ++++++++++++
> 1 file changed, 12 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/input/rotary-encoder.txt b/Documentation/devicetree/bindings/input/rotary-encoder.txt
> index f99fe5cdeaec..9986ec2af2d4 100644
> --- a/Documentation/devicetree/bindings/input/rotary-encoder.txt
> +++ b/Documentation/devicetree/bindings/input/rotary-encoder.txt
> @@ -12,6 +12,10 @@ Optional properties:
> - rotary-encoder,relative-axis: register a relative axis rather than an
> absolute one. Relative axis will only generate +1/-1 events on the input
> device, hence no steps need to be passed.
> +- rotary-encoder,relative-keys : generate pair of key events. This setting
> + behaves just like relative-axis, generating key events instead.
> + (Keycodes[2] corresponds to -1/1 events.)
> +- rotary-encoder,relative-keycodes : keycodes for relative-keys
Given that keycodes are linux-specific, I think the property should be
linux,keycodes. Also, I am not sure we need separate
rotary-encoder,relative-keys property as we can infer that we want to
generate keys from presence of linux,keycodes property.
Rob, any comments?
> - rotary-encoder,rollover: Automatic rollover when the rotary value becomes
> greater than the specified steps or smaller than 0. For absolute axis only.
> - rotary-encoder,steps-per-period: Number of steps (stable states) per period.
> @@ -48,3 +52,11 @@ Example:
> rotary-encoder,encoding = "binary";
> rotary-encoder,rollover;
> };
> +
> + rotary@2 {
> + compatible = "rotary-encoder";
> + gpios = <&gpio 21 0>, <&gpio 22 0>;
> + rotary-encoder,relative-keys;
> + rotary-encoder,relative-keycode = <103>, <108>;
> + rotary-encoder,steps-per-period = <2>;
> + };
> --
> 2.17.1
>
Thanks.
--
Dmitry
^ permalink raw reply
* Re: [PATCH] Input: synaptics - add PNP IDs for Dell XPS models to forcepad
From: Benjamin Tissoires @ 2019-01-15 8:57 UTC (permalink / raw)
To: Dmitry Torokhov; +Cc: Kim Phillips, lkml, Paul Menzel, open list:HID CORE LAYER
In-Reply-To: <20190114184012.GC117329@dtor-ws>
On Mon, Jan 14, 2019 at 7:40 PM Dmitry Torokhov
<dmitry.torokhov@gmail.com> wrote:
>
> On Sat, Jan 12, 2019 at 04:04:36PM -0600, Kim Phillips wrote:
> > On 1/11/19 7:40 PM, Dmitry Torokhov wrote:
> > > Hi Kim,
> >
> > Hi Dmitry,
> >
> > > On Fri, Jan 11, 2019 at 02:54:30PM -0600, Kim Phillips wrote:
> > >> This patch is the result of seeing this message:
> > >>
> > >> psmouse serio1: synaptics: Your touchpad (PNP: DLL087c PNP0f13) says it can support a different bus. If i2c-hid and hid-rmi are not used, you might want to try setting psmouse.synaptics_intertouch to 1 and report this to linux-input@vger.kernel.org.
> > >>
> > >> If I set psmouse.synaptics_intertouch=1, or add the PNP ID to
> > >> smbus_pnp_ids, the touchpad continues to work, and the above message
> > >> goes away, but we now get:
> > >>
> > >> psmouse serio1: synaptics: Trying to set up SMBus access
> > >> psmouse serio1: synaptics: SMbus companion is not ready yet
> > >>
> > >> With this patch applied, i.e., the PNP IDs are added to the forcepad
> > >> array, the touchpad continues to work and all of the above messages
> > >> disappear.
> > >
> > > Are you sure the touchpad in XPSes is a forcepad (i.e. it does not have
> > > physical button underneath it)? As far as I know there were only couple
> > > of HP laptops with forcepads and when switching to RMI mode forcepads
> > > need F21 handler that we do not currently have in the kernel.
> >
> > I see, no, I'm not sure, but assuming you're right, the IDs
> > should be added to the smbus array instead, after fixing
> > the SMbus "companion not ready" problem? Pointers for that and
> > the below interrupts when touchpad idle after resume, welcome.
> >
> > Also, the link to get the RMI4 spec in
> > Documentation/devicetree/bindings/input/rmi4/rmi_2d_sensor.txt
> > is broken. Any pointers for that also appreciated.
>
> OK, sorting it all out some more:
>
> - because we do not have support for F21 necessary for forcepads adding
> APIC ID to forcepad list actuallty disables SMbus companion mode, that
> is why you no longer see "companion not ready" messages vs. setting
> psmouse.synaptics_intertouch=1 module parameter.
Yep
>
> - this does not really matter as your touchpad ends up being driven by
> i2c-hid and hid-multitouch drivers, and that is how we wait it to
> work, as we do not want to deviate from behavior on Windows since OEM
> tested it (the device and firmware) in tha configuration.
Yep too. The I2C-hid touchpads from Synaptics do not have the SMBus
wired at all, so we can't enable SMBus for them. Also, the fact that
the device gets loaded over i2c-hid means that we can't know that it
is the case from the psmouse/synaptics point of view.
>
> - we need to figure out issue with interrupts on resume, maybe Benjamin
> have seen it?
First time I see it.
I just tried on a XPS 9360 and kernel v4.18 (fedora) and nothing was a problem.
I then tried on a XPS 9575 with v4.19, and here, the wacom I2C node is
also keeping firing the interrupts, but not the touchpad. However,
here, the interrupts are not stopping when I touch the touchscreen or
if I approach a pen.
Kim, rmmod-ing i2c-hid and modprobing back it with the parameter
debug=1 doesn't show any events processed when the interrupts are
firing. Do you see the same?
Cheers,
Benjamin
^ permalink raw reply
* Re: [PATCH] Input: synaptics - add PNP IDs for Dell XPS models to forcepad
From: Paul Menzel @ 2019-01-15 10:12 UTC (permalink / raw)
To: Benjamin Tissoires, Dmitry Torokhov; +Cc: Kim Phillips, LKML, linux-input
In-Reply-To: <CAO-hwJKCeV5ZEw7aX58=mnfhWex5QtEVYbRdDX7OosfS5+suUw@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 3624 bytes --]
Dear Benjamin,
Thank you for chiming in.
On 01/15/19 09:57, Benjamin Tissoires wrote:
> On Mon, Jan 14, 2019 at 7:40 PM Dmitry Torokhov wrote:
>>
>> On Sat, Jan 12, 2019 at 04:04:36PM -0600, Kim Phillips wrote:
>>> On 1/11/19 7:40 PM, Dmitry Torokhov wrote:
>>>> On Fri, Jan 11, 2019 at 02:54:30PM -0600, Kim Phillips wrote:
>>>>> This patch is the result of seeing this message:
>>>>>
>>>>> psmouse serio1: synaptics: Your touchpad (PNP: DLL087c PNP0f13) says it can support a different bus. If i2c-hid and hid-rmi are not used, you might want to try setting psmouse.synaptics_intertouch to 1 and report this to linux-input@vger.kernel.org.
>>>>>
>>>>> If I set psmouse.synaptics_intertouch=1, or add the PNP ID to
>>>>> smbus_pnp_ids, the touchpad continues to work, and the above message
>>>>> goes away, but we now get:
>>>>>
>>>>> psmouse serio1: synaptics: Trying to set up SMBus access
>>>>> psmouse serio1: synaptics: SMbus companion is not ready yet
>>>>>
>>>>> With this patch applied, i.e., the PNP IDs are added to the forcepad
>>>>> array, the touchpad continues to work and all of the above messages
>>>>> disappear.
>>>>
>>>> Are you sure the touchpad in XPSes is a forcepad (i.e. it does not have
>>>> physical button underneath it)? As far as I know there were only couple
>>>> of HP laptops with forcepads and when switching to RMI mode forcepads
>>>> need F21 handler that we do not currently have in the kernel.
>>>
>>> I see, no, I'm not sure, but assuming you're right, the IDs
>>> should be added to the smbus array instead, after fixing
>>> the SMbus "companion not ready" problem? Pointers for that and
>>> the below interrupts when touchpad idle after resume, welcome.
>>>
>>> Also, the link to get the RMI4 spec in
>>> Documentation/devicetree/bindings/input/rmi4/rmi_2d_sensor.txt
>>> is broken. Any pointers for that also appreciated.
>>
>> OK, sorting it all out some more:
>>
>> - because we do not have support for F21 necessary for forcepads adding
>> APIC ID to forcepad list actuallty disables SMbus companion mode, that
>> is why you no longer see "companion not ready" messages vs. setting
>> psmouse.synaptics_intertouch=1 module parameter.
>
> Yep
>
>>
>> - this does not really matter as your touchpad ends up being driven by
>> i2c-hid and hid-multitouch drivers, and that is how we wait it to
>> work, as we do not want to deviate from behavior on Windows since OEM
>> tested it (the device and firmware) in tha configuration.
>
> Yep too. The I2C-hid touchpads from Synaptics do not have the SMBus
> wired at all, so we can't enable SMBus for them. Also, the fact that
> the device gets loaded over i2c-hid means that we can't know that it
> is the case from the psmouse/synaptics point of view.
>
>> - we need to figure out issue with interrupts on resume, maybe Benjamin
>> have seen it?
>
> First time I see it.
>
> I just tried on a XPS 9360 and kernel v4.18 (fedora) and nothing was
> a problem.
I just wanted to clarify, that I am only able to reproduce the delay
during the *first* suspend/resume cycle. Subsequent tries are fine.
> I then tried on a XPS 9575 with v4.19, and here, the wacom I2C node is
> also keeping firing the interrupts, but not the touchpad. However,
> here, the interrupts are not stopping when I touch the touchscreen or
> if I approach a pen.
>
> Kim, rmmod-ing i2c-hid and modprobing back it with the parameter
> debug=1 doesn't show any events processed when the interrupts are
> firing. Do you see the same?
Kind regards,
Paul
[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 5174 bytes --]
^ permalink raw reply
* Re: [PATCH V2 2/2] Input: rotaty-encoder - Add DT binding document
From: Rob Herring @ 2019-01-15 20:29 UTC (permalink / raw)
To: Dmitry Torokhov
Cc: Donghoon Han, linux-input, Daniel Mack, linux-kernel, devicetree
In-Reply-To: <20190115035221.GA151157@dtor-ws>
On Mon, Jan 14, 2019 at 07:52:21PM -0800, Dmitry Torokhov wrote:
> On Tue, Jan 08, 2019 at 01:42:49AM +0900, Donghoon Han wrote:
> > Add DT binding document for rotary-encoder, keycode options.
> >
> > Signed-off-by: Donghoon Han <nazgul33@gmail.com>
> > Cc: Dmitry Torokhov <dmitry.torokhov@gmail.com>
> > Cc: Daniel Mack <daniel@caiaq.de>
> > Cc: devicetree@vger.kernel.org
> > To: linux-input@vger.kernel.org
> > ---
> > .../devicetree/bindings/input/rotary-encoder.txt | 12 ++++++++++++
> > 1 file changed, 12 insertions(+)
> >
> > diff --git a/Documentation/devicetree/bindings/input/rotary-encoder.txt b/Documentation/devicetree/bindings/input/rotary-encoder.txt
> > index f99fe5cdeaec..9986ec2af2d4 100644
> > --- a/Documentation/devicetree/bindings/input/rotary-encoder.txt
> > +++ b/Documentation/devicetree/bindings/input/rotary-encoder.txt
> > @@ -12,6 +12,10 @@ Optional properties:
> > - rotary-encoder,relative-axis: register a relative axis rather than an
> > absolute one. Relative axis will only generate +1/-1 events on the input
> > device, hence no steps need to be passed.
> > +- rotary-encoder,relative-keys : generate pair of key events. This setting
> > + behaves just like relative-axis, generating key events instead.
> > + (Keycodes[2] corresponds to -1/1 events.)
> > +- rotary-encoder,relative-keycodes : keycodes for relative-keys
>
> Given that keycodes are linux-specific, I think the property should be
> linux,keycodes. Also, I am not sure we need separate
> rotary-encoder,relative-keys property as we can infer that we want to
> generate keys from presence of linux,keycodes property.
>
> Rob, any comments?
Yes, I had similar thoughts.
^ permalink raw reply
* Re: [PATCH] input_event: Provide override for sparc64
From: Arnd Bergmann @ 2019-01-15 21:19 UTC (permalink / raw)
To: Deepa Dinamani
Cc: Dmitry Torokhov, open list:HID CORE LAYER,
Linux Kernel Mailing List, David Miller, y2038 Mailman List
In-Reply-To: <20181229183514.24644-1-deepa.kernel@gmail.com>
On Sat, Dec 29, 2018 at 7:35 PM Deepa Dinamani <deepa.kernel@gmail.com> wrote:
> struct timeval time;
> #define input_event_sec time.tv_sec
> #define input_event_usec time.tv_usec
> #else
> __kernel_ulong_t __sec;
> +#ifdef CONFIG_SPARC64
> + unsigned int __usec;
> +#else
> __kernel_ulong_t __usec;
> +#endif
> #define input_event_sec __sec
> #define input_event_usec __usec
> #endif
Sorry for not having looked at this earlier, I just realized that this
is a mistake
in user space: uapi headers are not allowed to reference CONFIG_* symbols,
since the headers are supposed to be configuration independent and the
CONFIG_* namespace might clash with user space identifiers.
The correct check appears to be
#if defined(__sparc__) && defined(__arch64__)
Arnd
^ permalink raw reply
* Re: [PATCH] input_event: Provide override for sparc64
From: David Miller @ 2019-01-15 21:29 UTC (permalink / raw)
To: arnd; +Cc: y2038, linux-kernel, dmitry.torokhov, deepa.kernel, linux-input
In-Reply-To: <CAK8P3a1YG0+iMBiNy-g7KCusX3myV0tsuCEg1YLWW0cXrjk7PA@mail.gmail.com>
From: Arnd Bergmann <arnd@arndb.de>
Date: Tue, 15 Jan 2019 22:19:27 +0100
> The correct check appears to be
>
> #if defined(__sparc__) && defined(__arch64__)
That is correct.
_______________________________________________
Y2038 mailing list
Y2038@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/y2038
^ permalink raw reply
* Re: [PATCH] input_event: Provide override for sparc64
From: Dmitry Torokhov @ 2019-01-15 22:32 UTC (permalink / raw)
To: Deepa Dinamani
Cc: y2038 Mailman List, David Miller, lkml, Arnd Bergmann,
linux-input@vger.kernel.org
In-Reply-To: <20190115.132928.900198180655535613.davem@davemloft.net>
On Tue, Jan 15, 2019 at 1:29 PM David Miller <davem@davemloft.net> wrote:
>
> From: Arnd Bergmann <arnd@arndb.de>
> Date: Tue, 15 Jan 2019 22:19:27 +0100
>
> > The correct check appears to be
> >
> > #if defined(__sparc__) && defined(__arch64__)
>
> That is correct.
OK. Deepa, could you please send me a fixup as I already pushed out
the original patch?
Thanks.
--
Dmitry
_______________________________________________
Y2038 mailing list
Y2038@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/y2038
^ permalink raw reply
* Re: [PATCH] input_event: Provide override for sparc64
From: Deepa Dinamani @ 2019-01-16 0:10 UTC (permalink / raw)
To: Dmitry Torokhov
Cc: Arnd Bergmann, linux-input@vger.kernel.org, lkml,
y2038 Mailman List, David Miller
In-Reply-To: <CAKdAkRQdO14OP7SgE=D4x5RG7=cjDoCAOmtnCcWw_DrToeEmhA@mail.gmail.com>
> On Jan 15, 2019, at 2:32 PM, Dmitry Torokhov <dmitry.torokhov@gmail.com> wrote:
>
>> On Tue, Jan 15, 2019 at 1:29 PM David Miller <davem@davemloft.net> wrote:
>>
>> From: Arnd Bergmann <arnd@arndb.de>
>> Date: Tue, 15 Jan 2019 22:19:27 +0100
>>
>>> The correct check appears to be
>>>
>>> #if defined(__sparc__) && defined(__arch64__)
>>
>> That is correct.
>
> OK. Deepa, could you please send me a fixup as I already pushed out
> the original patch?
Ok, I’m traveling. I will post an update in a couple of days.
Thanks,
Deepa
^ permalink raw reply
* Re: [PATCH] Input: synaptics - add PNP IDs for Dell XPS models to forcepad
From: Kim Phillips @ 2019-01-16 4:59 UTC (permalink / raw)
To: Benjamin Tissoires, Dmitry Torokhov
Cc: lkml, Paul Menzel, open list:HID CORE LAYER
In-Reply-To: <CAO-hwJKCeV5ZEw7aX58=mnfhWex5QtEVYbRdDX7OosfS5+suUw@mail.gmail.com>
On 1/15/19 2:57 AM, Benjamin Tissoires wrote:
> On Mon, Jan 14, 2019 at 7:40 PM Dmitry Torokhov
> <dmitry.torokhov@gmail.com> wrote:
>>
>> On Sat, Jan 12, 2019 at 04:04:36PM -0600, Kim Phillips wrote:
>>> On 1/11/19 7:40 PM, Dmitry Torokhov wrote:
>>>> Hi Kim,
>>>
>>> Hi Dmitry,
>>>
>>>> On Fri, Jan 11, 2019 at 02:54:30PM -0600, Kim Phillips wrote:
>>>>> This patch is the result of seeing this message:
>>>>>
>>>>> psmouse serio1: synaptics: Your touchpad (PNP: DLL087c PNP0f13) says it can support a different bus. If i2c-hid and hid-rmi are not used, you might want to try setting psmouse.synaptics_intertouch to 1 and report this to linux-input@vger.kernel.org.
>>>>>
>>>>> If I set psmouse.synaptics_intertouch=1, or add the PNP ID to
>>>>> smbus_pnp_ids, the touchpad continues to work, and the above message
>>>>> goes away, but we now get:
>>>>>
>>>>> psmouse serio1: synaptics: Trying to set up SMBus access
>>>>> psmouse serio1: synaptics: SMbus companion is not ready yet
>>>>>
>>>>> With this patch applied, i.e., the PNP IDs are added to the forcepad
>>>>> array, the touchpad continues to work and all of the above messages
>>>>> disappear.
>>>>
>>>> Are you sure the touchpad in XPSes is a forcepad (i.e. it does not have
>>>> physical button underneath it)? As far as I know there were only couple
>>>> of HP laptops with forcepads and when switching to RMI mode forcepads
>>>> need F21 handler that we do not currently have in the kernel.
>>>
>>> I see, no, I'm not sure, but assuming you're right, the IDs
>>> should be added to the smbus array instead, after fixing
>>> the SMbus "companion not ready" problem? Pointers for that and
>>> the below interrupts when touchpad idle after resume, welcome.
>>>
>>> Also, the link to get the RMI4 spec in
>>> Documentation/devicetree/bindings/input/rmi4/rmi_2d_sensor.txt
>>> is broken. Any pointers for that also appreciated.
>>
>> OK, sorting it all out some more:
>>
>> - because we do not have support for F21 necessary for forcepads adding
>> APIC ID to forcepad list actuallty disables SMbus companion mode, that
>> is why you no longer see "companion not ready" messages vs. setting
>> psmouse.synaptics_intertouch=1 module parameter.
>
> Yep
>
>>
>> - this does not really matter as your touchpad ends up being driven by
>> i2c-hid and hid-multitouch drivers, and that is how we wait it to
>> work, as we do not want to deviate from behavior on Windows since OEM
>> tested it (the device and firmware) in tha configuration.
>
> Yep too. The I2C-hid touchpads from Synaptics do not have the SMBus
> wired at all, so we can't enable SMBus for them. Also, the fact that
> the device gets loaded over i2c-hid means that we can't know that it
> is the case from the psmouse/synaptics point of view.
Sigh, OK, I wasn't registering the word "not" when reading
"If i2c-hid and hid-rmi are not used" too quickly.
>> - we need to figure out issue with interrupts on resume, maybe Benjamin
>> have seen it?
>
> First time I see it.
>
> I just tried on a XPS 9360 and kernel v4.18 (fedora) and nothing was a problem.
> I then tried on a XPS 9575 with v4.19, and here, the wacom I2C node is
> also keeping firing the interrupts, but not the touchpad. However,
> here, the interrupts are not stopping when I touch the touchscreen or
> if I approach a pen.
>
> Kim, rmmod-ing i2c-hid and modprobing back it with the parameter
> debug=1 doesn't show any events processed when the interrupts are
> firing. Do you see the same?
After rmmodding i2c_hid, the WCOM488F and SYNA2393 entries in /proc/interrupts
somewhat expectedly disappear, however, the modprobe (with or without debug=1)
fails to bring them back, with these messages left in dmesg:
[ 3882.073222] calling i2c_hid_driver_init+0x0/0x1000 [i2c_hid] @ 3082
[ 3882.180938] i2c_hid i2c-WCOM488F:00: HID over i2c has not been provided an Int IRQ
[ 3882.181060] i2c_hid: probe of i2c-WCOM488F:00 failed with error -22
[ 3882.181065] probe of i2c-WCOM488F:00 returned 0 after 496 usecs
[ 3882.289196] i2c_hid i2c-SYNA2393:00: HID over i2c has not been provided an Int IRQ
[ 3882.289318] i2c_hid: probe of i2c-SYNA2393:00 failed with error -22
[ 3882.289321] probe of i2c-SYNA2393:00 returned 0 after 508 usecs
[ 3882.289418] initcall i2c_hid_driver_init+0x0/0x1000 [i2c_hid] returned 0 after 211119 usecs
In order to work around that problem, I set h2c_hid.debug=1 in the
boot command line, and after a resume, dmesg contains these messages,
relevant to i2c_hid:
[ 267.235673] i2c_hid i2c-WCOM488F:00: calling i2c_hid_resume+0x0/0x140 [i2c_hid] @ 3078, parent: i2c-9
[ 267.235676] input input16: calling input_dev_resume+0x0/0x50 @ 3060, parent: card0
[ 267.235681] input input16: input_dev_resume+0x0/0x50 returned 0 after 0 usecs
[ 267.235682] i2c_hid i2c-WCOM488F:00: i2c_hid_set_power
[ 267.235687] input input17: calling input_dev_resume+0x0/0x50 @ 3060, parent: card0
[ 267.235689] i2c_hid i2c-WCOM488F:00: __i2c_hid_command: cmd=04 00 00 08
[ 267.235693] input input17: input_dev_resume+0x0/0x50 returned 0 after 0 usecs
[ 267.235698] idma64 idma64.1: calling platform_pm_resume+0x0/0x50 @ 3060, parent: 0000:00:15.1
[ 267.235701] idma64 idma64.1: platform_pm_resume+0x0/0x50 returned 0 after 0 usecs
[ 267.235706] i2c_designware i2c_designware.1: calling platform_pm_resume+0x0/0x50 @ 3060, parent: 0000:00:15.1
[ 267.235709] i2c_designware i2c_designware.1: platform_pm_resume+0x0/0x50 returned 0 after 0 usecs
[ 267.235718] rfkill rfkill0: calling rfkill_resume+0x0/0x60 @ 3060, parent: phy0
[ 267.235724] rfkill rfkill0: rfkill_resume+0x0/0x60 returned 0 after 3 usecs
[ 267.235768] i2c_hid i2c-SYNA2393:00: calling i2c_hid_resume+0x0/0x140 [i2c_hid] @ 3108, parent: i2c-10
[ 267.235774] i2c_hid i2c-SYNA2393:00: i2c_hid_set_power
[ 267.235776] i2c_hid i2c-SYNA2393:00: __i2c_hid_command: cmd=22 00 00 08
[ 267.236051] i2c_hid i2c-SYNA2393:00: i2c_hid_set_or_send_report
[ 267.236053] i2c_hid i2c-SYNA2393:00: __i2c_hid_command: cmd=22 00 3d 03 23 00 04 00 0d 00
[ 267.236076] i2c_hid i2c-WCOM488F:00: i2c_hid_set_or_send_report
[ 267.236080] i2c_hid i2c-WCOM488F:00: __i2c_hid_command: cmd=04 00 3b 03 05 00 42 00 0b 00 fd 89 a3 07 f3 02 20 8d 49 06 d7 9c ff ff 80 59 5c 13 d7 9c ff ff 08 00 00 08 d7 9c ff ff 01 00 00 00 00 00 00 00 16 00 00 00 66 69 6c 65 75 74 6c 2e 6d 65 73 73
[ 267.237691] i2c_hid i2c-SYNA2393:00: input: 20 00 03 01 3c 03 a8 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 06 60 01 00
[ 267.238137] i2c_hid i2c-SYNA2393:00: i2c_hid_set_or_send_report
[ 267.238140] i2c_hid i2c-SYNA2393:00: __i2c_hid_command: cmd=22 00 34 03 23 00 04 00 04 03
[ 267.238670] i2c_hid i2c-WCOM488F:00: i2c_hid_get_report
[ 267.238673] i2c_hid i2c-WCOM488F:00: __i2c_hid_command: cmd=04 00 3b 02 05 00
[ 267.239708] i2c_hid i2c-SYNA2393:00: input: 20 00 03 01 3c 03 a8 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 06 60 01 00
[ 267.240084] i2c_hid i2c-SYNA2393:00: i2c_hid_set_or_send_report
[ 267.240087] i2c_hid i2c-SYNA2393:00: __i2c_hid_command: cmd=22 00 36 03 23 00 04 00 06 03
[ 267.241377] i2c_hid i2c-WCOM488F:00: i2c_hid_set_or_send_report
[ 267.241380] i2c_hid i2c-WCOM488F:00: __i2c_hid_command: cmd=04 00 3b 03 05 00 42 00 0b 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
[ 267.241711] i2c_hid i2c-SYNA2393:00: input: 20 00 03 01 3c 03 a8 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 06 60 01 00
[ 267.243279] i2c_hid i2c-SYNA2393:00: input: 20 00 03 01 3c 03 a8 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 06 60 01 00
[ 267.243981] i2c_hid i2c-WCOM488F:00: i2c_hid_get_report
[ 267.243984] i2c_hid i2c-WCOM488F:00: __i2c_hid_command: cmd=04 00 3b 02 05 00
[ 267.244847] i2c_hid i2c-SYNA2393:00: input: 20 00 03 01 3c 03 a8 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 06 60 01 00
[ 267.245360] i2c_hid i2c-SYNA2393:00: i2c_hid_resume+0x0/0x140 [i2c_hid] returned 0 after 9360 usecs
[ 267.245455] input input27: calling input_dev_resume+0x0/0x50 @ 3060, parent: 0018:06CB:7A13.0002
[ 267.245460] input input27: input_dev_resume+0x0/0x50 returned 0 after 0 usecs
[ 267.246773] i2c_hid i2c-WCOM488F:00: i2c_hid_set_or_send_report
[ 267.246777] i2c_hid i2c-WCOM488F:00: __i2c_hid_command: cmd=04 00 3b 03 05 00 42 00 0b 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
[ 267.246919] i2c_hid i2c-SYNA2393:00: input: 20 00 03 01 3c 03 a8 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 06 60 01 00
[ 267.248517] i2c_hid i2c-SYNA2393:00: input: 20 00 03 01 3c 03 a8 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 06 60 01 00
[ 267.249383] i2c_hid i2c-WCOM488F:00: i2c_hid_get_report
[ 267.249386] i2c_hid i2c-WCOM488F:00: __i2c_hid_command: cmd=04 00 3b 02 05 00
[ 267.250116] i2c_hid i2c-SYNA2393:00: input: 20 00 03 01 3c 03 a8 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 06 60 01 00
[ 267.251767] i2c_hid i2c-SYNA2393:00: input: 20 00 03 01 3c 03 a8 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 06 60 01 00
[ 267.252137] i2c_hid i2c-WCOM488F:00: i2c_hid_set_or_send_report
[ 267.252140] i2c_hid i2c-WCOM488F:00: __i2c_hid_command: cmd=04 00 3b 03 05 00 42 00 0b 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
[ 267.253440] i2c_hid i2c-SYNA2393:00: input: 20 00 03 01 3c 03 a8 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 06 60 01 00
[ 267.254734] i2c_hid i2c-WCOM488F:00: i2c_hid_get_report
[ 267.254737] i2c_hid i2c-WCOM488F:00: __i2c_hid_command: cmd=04 00 3b 02 05 00
[ 267.255015] i2c_hid i2c-SYNA2393:00: input: 20 00 03 01 3c 03 a8 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 06 60 01 00
[ 267.256612] i2c_hid i2c-SYNA2393:00: input: 20 00 03 01 3c 03 a8 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 06 60 01 00
[ 267.257475] i2c_hid i2c-WCOM488F:00: i2c_hid_set_or_send_report
[ 267.257478] i2c_hid i2c-WCOM488F:00: __i2c_hid_command: cmd=04 00 3b 03 05 00 42 00 0b 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
[ 267.258275] i2c_hid i2c-SYNA2393:00: input: 20 00 03 01 3c 03 a8 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 06 60 01 00
[ 267.259852] i2c_hid i2c-SYNA2393:00: input: 20 00 03 01 3c 03 a8 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 06 60 01 00
[ 267.260046] i2c_hid i2c-WCOM488F:00: i2c_hid_get_report
[ 267.260049] i2c_hid i2c-WCOM488F:00: __i2c_hid_command: cmd=04 00 3b 02 05 00
[ 267.261441] i2c_hid i2c-SYNA2393:00: input: 20 00 03 01 3c 03 a8 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 06 60 01 00
[ 267.262789] i2c_hid i2c-WCOM488F:00: i2c_hid_set_or_send_report
[ 267.262792] i2c_hid i2c-WCOM488F:00: __i2c_hid_command: cmd=04 00 3b 03 05 00 42 00 0b 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
[ 267.263129] i2c_hid i2c-SYNA2393:00: input: 20 00 03 01 3c 03 a8 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 06 60 01 00
[ 267.264718] i2c_hid i2c-SYNA2393:00: input: 20 00 03 01 3c 03 a8 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 06 60 01 00
[ 267.265410] i2c_hid i2c-WCOM488F:00: i2c_hid_get_report
[ 267.265413] i2c_hid i2c-WCOM488F:00: __i2c_hid_command: cmd=04 00 3b 02 05 00
[ 267.266318] i2c_hid i2c-SYNA2393:00: input: 20 00 03 01 3c 03 a8 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 06 60 01 00
[ 267.267971] i2c_hid i2c-SYNA2393:00: input: 20 00 03 01 3c 03 a8 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 06 60 01 00
[ 267.268169] i2c_hid i2c-WCOM488F:00: i2c_hid_set_or_send_report
[ 267.268172] i2c_hid i2c-WCOM488F:00: __i2c_hid_command: cmd=04 00 3e 03 05 00 05 00 0e 02 00
[ 267.268728] i2c_hid i2c-WCOM488F:00: i2c_hid_resume+0x0/0x140 [i2c_hid] returned 0 after 32273 usecs
[ 267.269575] i2c_hid i2c-SYNA2393:00: input: 20 00 03 01 3c 03 a8 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 06 60 01 00
[ 267.271144] i2c_hid i2c-SYNA2393:00: input: 20 00 03 01 3c 03 a8 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 06 60 01 00
[ 267.272719] i2c_hid i2c-SYNA2393:00: input: 20 00 03 01 3c 03 a8 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 06 60 01 00
[ 267.274298] i2c_hid i2c-SYNA2393:00: input: 20 00 03 01 3c 03 a8 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 06 60 01 00
...and it goes on and on, where that same last line gets
repeated as the interrupts fire, until I start using the touchpad,
thereby stopping the interrupts.
I'm not seeing any such bad behaviour from the WCOM device.
Kim
^ permalink raw reply
* Re: [PATCH v7 0/7] Introduce STPMIC1 PMIC Driver
From: Lee Jones @ 2019-01-16 8:13 UTC (permalink / raw)
To: dmitry.torokhov@gmail.com
Cc: Pascal PAILLET-LME, robh+dt@kernel.org, mark.rutland@arm.com,
lgirdwood@gmail.com, broonie@kernel.org, wim@linux-watchdog.org,
linux@roeck-us.net, linux-input@vger.kernel.org,
devicetree@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-watchdog@vger.kernel.org, benjamin.gaignard@linaro.org,
eballetbo@gmail.com, axel.lin@ingics.com
In-Reply-To: <20190115004856.GL117329@dtor-ws>
On Mon, 14 Jan 2019, dmitry.torokhov@gmail.com wrote:
> On Fri, Dec 14, 2018 at 12:47:01PM +0000, Lee Jones wrote:
> > On Fri, 30 Nov 2018, Pascal PAILLET-LME wrote:
> >
> > > The goal of this patch-set is to propose a driver for the STPMIC1 PMIC from
> > > STMicroelectronics.
> > > The STPMIC1 regulators supply power to an application processor as well as
> > > to external system peripherals such as DDR, Flash memories and system
> > > devices. It also features onkey button input and an hardware watchdog.
> > > The STPMIC1 is controlled via I2C.
> > >
> > > Main driver is drivers/mfd/stpmic1 that handle I2C regmap configuration and
> > > irqchip. stpmic1_regulator, stpmic1_onkey and stpmic1_wdt need stpmic1 mfd
> > > as parent.
> > >
> > > STPMIC1 MFD and regulator drivers maybe mandatory at boot time.
> > >
> > > Pascal Paillet (7):
> > > changes in v7:
> > > * rebase on regul/for-next
> > >
> > > dt-bindings: mfd: document stpmic1
> > > mfd: stpmic1: add stpmic1 driver
> > > dt-bindings: input: document stpmic1 pmic onkey
> > > input: stpmic1: add stpmic1 onkey driver
> > > dt-bindings: watchdog: document stpmic1 pmic watchdog
> > > watchdog: stpmic1: add stpmic1 watchdog driver
> > > regulator: stpmic1: fix regulator_lock usage
> >
> > Could you please remove any patches which have been applied and
> > [RESEND]?
> >
> > Also, is Dmitry planning on Acking:
> >
> > dt-bindings: input: document stpmic1 pmic onkey
> >
> > ... or is Rob's Ack enough?
>
> For bindings I normally defer to Rob (unless I see something that really
> bugs me and then I'll speak up).
I usually do the opposite. Seeing as Rob is pretty heavily laden with
DT patches, I tend to review/apply patches which do not add new DT
properties and/or are obvious/trivial and leave Rob to the rest.
Your train-set though of course, your decision.
--
Lee Jones [李琼斯]
Linaro Services Technical Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
^ permalink raw reply
* Re: [PATCH] HID: i2c-hid: Disable runtime PM on Goodix touchpad
From: Kai Heng Feng @ 2019-01-16 8:21 UTC (permalink / raw)
To: Jiri Kosina; +Cc: benjamin.tissoires, linux-input, linux-kernel
In-Reply-To: <nycvar.YFH.7.76.1901141217550.6626@cbobk.fhfr.pm>
> On Jan 14, 2019, at 19:18, Jiri Kosina <jikos@kernel.org> wrote:
>
> On Mon, 14 Jan 2019, Kai-Heng Feng wrote:
>
>> A Goodix touchpad doesn't work. Touching the touchpad can trigger IRQ
>> but there's no input event from HID subsystem.
>>
>> Turns out it reports some invalid data:
>> [ 22.136630] i2c_hid i2c-DELL091F:00: input: 0b 00 01 00 00 00 00 00 00 00 00
>>
>> After some trial and error, it's another device that doesn't work well
>> with ON/SLEEP commands. Disable runtime PM to fix the issue.
>
> Thanks, I've now applied the patch to for-5.0/upstream-fixes. I am
> wondering though we are we seeing these at all - do other OSes not do the
> runtime PM on i2c at all?
According to the vendor, Windows does use ON/SLEEP, but infrequently.
We can use pm_runtime_use_autosuspend() to reduce the frequency of
ON/SLEEP commands, but it’s just papering over the touchpad firmware
bug.
Kai-Heng
>
> --
> Jiri Kosina
> SUSE Labs
>
^ permalink raw reply
* [PATCH] Input: olpc_apsp - assign priv->dev earlier
From: Lubomir Rintel @ 2019-01-16 9:44 UTC (permalink / raw)
To: Dmitry Torokhov; +Cc: linux-input, linux-kernel, Lubomir Rintel, stable
The dev field needs to be set when serio_register_port() is called,
because the open callback may use it (in the error handling path).
Cc: stable@vger.kernel.org # v4.18+
Fixes: commit af518342effd ("Input: olpc_apsp - check FIFO status on open(), not probe()")
Signed-off-by: Lubomir Rintel <lkundrak@v3.sk>
---
drivers/input/serio/olpc_apsp.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/input/serio/olpc_apsp.c b/drivers/input/serio/olpc_apsp.c
index 0aece9777087..554f4b8228d2 100644
--- a/drivers/input/serio/olpc_apsp.c
+++ b/drivers/input/serio/olpc_apsp.c
@@ -198,6 +198,8 @@ static int olpc_apsp_probe(struct platform_device *pdev)
if (!priv)
return -ENOMEM;
+ priv->dev = &pdev->dev;
+
res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
priv->base = devm_ioremap_resource(&pdev->dev, res);
if (IS_ERR(priv->base)) {
@@ -261,7 +263,6 @@ static int olpc_apsp_probe(struct platform_device *pdev)
goto err_irq;
}
- priv->dev = &pdev->dev;
device_init_wakeup(priv->dev, 1);
platform_set_drvdata(pdev, priv);
--
2.20.1
^ permalink raw reply related
* [GIT PULL] Immutable branch between MFD, IIO and Input due for the v5.1 merge window
From: Lee Jones @ 2019-01-16 12:44 UTC (permalink / raw)
To: Philippe Schenker
Cc: jic23, marcel.ziswiler, stefan, robh, alexandre.torgue, shawnguo,
dmitry.torokhov, thierry.reding, digetx, coquelin.stm32,
Philippe Schenker, Arnd Bergmann, Arnaud Pouliquen, linux-iio,
Mark Brown, Pengutronix Kernel Team, Rob Herring,
Geert Uytterhoeven, William Breathitt Gray, linux-stm32,
Fabio Estevam, Randy Dunlap, Jonathan Cameron,
Freeman Liu <fre>
In-Reply-To: <20181221134638.20600-1-dev@pschenker.ch>
Taken all but the ARM patches.
These need to be reviewed and go in via ARM-SoC.
The following changes since commit bfeffd155283772bbe78c6a05dec7c0128ee500c:
Linux 5.0-rc1 (2019-01-06 17:08:20 -0800)
are available in the Git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/lee/mfd.git ib-mfd-iio-input-v5.1
for you to fetch changes up to 81cdab79818988d27d8aeb162b7988c9e6dde936:
iio: adc: add STMPE ADC devicetree bindings (2019-01-16 12:37:36 +0000)
----------------------------------------------------------------
Immutable branch between MFD, IIO and Input due for the v5.1 merge window
----------------------------------------------------------------
Philippe Schenker (3):
dt-bindings: stmpe: Reformatting parameter list and use tabs only
mfd: stmpe: Move ADC related defines to MFD header
Input: stmpe-ts: preparations for STMPE ADC driver
Stefan Agner (3):
mfd: stmpe: Preparations for STMPE ADC driver
iio: adc: add STMPE ADC driver using IIO framework
iio: adc: add STMPE ADC devicetree bindings
.../devicetree/bindings/iio/adc/stmpe-adc.txt | 21 ++
.../bindings/input/touchscreen/stmpe.txt | 116 +++++--
Documentation/devicetree/bindings/mfd/stmpe.txt | 28 +-
drivers/iio/adc/Kconfig | 7 +
drivers/iio/adc/Makefile | 1 +
drivers/iio/adc/stmpe-adc.c | 363 +++++++++++++++++++++
drivers/input/touchscreen/stmpe-ts.c | 66 +---
drivers/mfd/Kconfig | 3 +-
drivers/mfd/stmpe.c | 68 ++++
include/linux/mfd/stmpe.h | 21 ++
10 files changed, 610 insertions(+), 84 deletions(-)
create mode 100644 Documentation/devicetree/bindings/iio/adc/stmpe-adc.txt
create mode 100644 drivers/iio/adc/stmpe-adc.c
--
Lee Jones [李琼斯]
Linaro Services Technical Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
^ permalink raw reply
* [GIT PULL] Immutable branch between MFD, Input and Watchdog due for the v5.1 merge window
From: Lee Jones @ 2019-01-16 14:04 UTC (permalink / raw)
To: Pascal PAILLET-LME
Cc: dmitry.torokhov@gmail.com, robh+dt@kernel.org,
mark.rutland@arm.com, lgirdwood@gmail.com, broonie@kernel.org,
wim@linux-watchdog.org, linux@roeck-us.net,
linux-input@vger.kernel.org, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org, linux-watchdog@vger.kernel.org,
benjamin.gaignard@linaro.org, eballetbo@gmail.com,
axel.lin@ingics.com
In-Reply-To: <1547460290-21049-1-git-send-email-p.paillet@st.com>
Enjoy!
The following changes since commit bfeffd155283772bbe78c6a05dec7c0128ee500c:
Linux 5.0-rc1 (2019-01-06 17:08:20 -0800)
are available in the Git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/lee/mfd.git ib-mfd-input-watchdog-v5.1
for you to fetch changes up to 28804c2c8fb3401aa4b7f16a883d49dd82f5e377:
watchdog: stpmic1: Add STPMIC1 watchdog driver (2019-01-16 14:01:19 +0000)
----------------------------------------------------------------
Immutable branch between MFD, Input and Watchdog due for the v5.1 merge window
----------------------------------------------------------------
Pascal PAILLET-LME (6):
dt-bindings: mfd: Document STPMIC1
mfd: stpmic1: Add STPMIC1 driver
dt-bindings: input: Document STPMIC1 PMIC onkey
input: stpmic1: Add STPMIC1 onkey driver
dt-bindings: watchdog: document STPMIC1 PMIC watchdog
watchdog: stpmic1: Add STPMIC1 watchdog driver
.../devicetree/bindings/input/st,stpmic1-onkey.txt | 28 +++
.../devicetree/bindings/mfd/st,stpmic1.txt | 61 ++++++
.../bindings/watchdog/st,stpmic1-wdt.txt | 11 ++
drivers/input/misc/Kconfig | 11 ++
drivers/input/misc/Makefile | 2 +
drivers/input/misc/stpmic1_onkey.c | 198 +++++++++++++++++++
drivers/mfd/Kconfig | 16 ++
drivers/mfd/Makefile | 1 +
drivers/mfd/stpmic1.c | 213 +++++++++++++++++++++
drivers/watchdog/Kconfig | 12 ++
drivers/watchdog/Makefile | 1 +
drivers/watchdog/stpmic1_wdt.c | 139 ++++++++++++++
include/dt-bindings/mfd/st,stpmic1.h | 50 +++++
include/linux/mfd/stpmic1.h | 212 ++++++++++++++++++++
14 files changed, 955 insertions(+)
create mode 100644 Documentation/devicetree/bindings/input/st,stpmic1-onkey.txt
create mode 100644 Documentation/devicetree/bindings/mfd/st,stpmic1.txt
create mode 100644 Documentation/devicetree/bindings/watchdog/st,stpmic1-wdt.txt
create mode 100644 drivers/input/misc/stpmic1_onkey.c
create mode 100644 drivers/mfd/stpmic1.c
create mode 100644 drivers/watchdog/stpmic1_wdt.c
create mode 100644 include/dt-bindings/mfd/st,stpmic1.h
create mode 100644 include/linux/mfd/stpmic1.h
--
Lee Jones [李琼斯]
Linaro Services Technical Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
^ permalink raw reply
* [PATCH] input: misc: pwm-vibra: Prevent unbalanced regulator
From: Paweł Chmiel @ 2019-01-16 21:11 UTC (permalink / raw)
To: dmitry.torokhov
Cc: linux-input, linux-kernel, Jonathan Bakker, Paweł Chmiel
From: Jonathan Bakker <xc-racer2@live.ca>
pwm_vibrator_stop disables the regulator, but it can be called from
multiple places, even when the regulator is already disabled. Fix this
by using regulator_is_enabled check when starting and stopping device.
Signed-off-by: Jonathan Bakker <xc-racer2@live.ca>
Signed-off-by: Paweł Chmiel <pawel.mikolaj.chmiel@gmail.com>
---
drivers/input/misc/pwm-vibra.c | 13 ++++++++-----
1 file changed, 8 insertions(+), 5 deletions(-)
diff --git a/drivers/input/misc/pwm-vibra.c b/drivers/input/misc/pwm-vibra.c
index 55da191ae550..66677ee770ca 100644
--- a/drivers/input/misc/pwm-vibra.c
+++ b/drivers/input/misc/pwm-vibra.c
@@ -42,10 +42,12 @@ static int pwm_vibrator_start(struct pwm_vibrator *vibrator)
struct pwm_state state;
int err;
- err = regulator_enable(vibrator->vcc);
- if (err) {
- dev_err(pdev, "failed to enable regulator: %d", err);
- return err;
+ if (!regulator_is_enabled(vibrator->vcc)) {
+ err = regulator_enable(vibrator->vcc);
+ if (err) {
+ dev_err(pdev, "failed to enable regulator: %d", err);
+ return err;
+ }
}
pwm_get_state(vibrator->pwm, &state);
@@ -76,7 +78,8 @@ static int pwm_vibrator_start(struct pwm_vibrator *vibrator)
static void pwm_vibrator_stop(struct pwm_vibrator *vibrator)
{
- regulator_disable(vibrator->vcc);
+ if (regulator_is_enabled(vibrator->vcc))
+ regulator_disable(vibrator->vcc);
if (vibrator->pwm_dir)
pwm_disable(vibrator->pwm_dir);
--
2.17.1
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox