* Re: [regression, bisected] Keyboard not responding after resuming from suspend/hibernate
From: Numan Demirdöğen @ 2018-12-18 7:23 UTC (permalink / raw)
To: Pavel Machek
Cc: jason.low2, Waiman.Long, paulmck, tglx, dmitry.torokhov, peterz,
mingo, linux-kernel, linux-input
In-Reply-To: <20181202222809.GA29467@amd>
[-- Attachment #1: Type: text/plain, Size: 2660 bytes --]
Sun, 2 Dec 2018 23:28:09 +0100 tarihinde
Pavel Machek <pavel@ucw.cz> yazdı:
>On Fri 2018-11-30 15:44:55, Numan Demirdöğen wrote:
>> Sun, 28 Oct 2018 22:06:54 +0300 tarihinde
>> Numan Demirdöğen <if.gnu.linux@gmail.com> yazdı:
>>
>> >Thu, 25 Oct 2018 09:49:03 +0200 tarihinde
>> >Pavel Machek <pavel@ucw.cz> yazdı:
>> >
>> >> Hi!
>> >>
>> >> Here's problem bisected down to:
>> >>
>> >> commit 9d659ae14b545c4296e812c70493bfdc999b5c1c
>> >> Author: Peter Zijlstra <peterz@infradead.org>
>> >> Date: Tue Aug 23 14:40:16 2016 +0200
>> >>
>> >> locking/mutex: Add lock handoff to avoid starvation
>> >>
>> >> Implement lock handoff to avoid lock starvation.
>> >>
>> >> Numan, I assume revert of that patch on the 4.18 kernel still
>> >> makes it work?
>> >>
>> >
>> >Unfortunately, I could not revert
>> >9d659ae14b545c4296e812c70493bfdc999b5c1c on kernels from 4.18.16 to
>> >4.10-rc1 because there were too much conflicts, which I could not
>> >solve as an "average Joe". I tried
>> >a3ea3d9b865c2a8f7fe455c7fa26db4b6fd066e3 which is parent of
>> >9d659ae14b545c4296e812c70493bfdc999b5c1c and succeeded to compile
>> >kernel.
>> >
>> >git checkout a3ea3d9b865c2a8f7fe455c7fa26db4b6fd066e3
>> >
>> >Then, I compiled kernel and rebooted with it. I tried a couples of
>> >times suspending and resuming, all of the time keyboard worked as
>> >expected.
>> >
>>
>> With this one line patch from Takashi Iwai, keyboard is working as
>> expected after resuming from suspend/hibernate.
>>
>> --- a/kernel/locking/mutex.c
>> +++ b/kernel/locking/mutex.c
>> @@ -59,7 +59,7 @@ EXPORT_SYMBOL(__mutex_init);
>> * Bit2 indicates handoff has been done and we're waiting for
>> pickup. */
>> #define MUTEX_FLAG_WAITERS 0x01
>> -#define MUTEX_FLAG_HANDOFF 0x02
>> +#define MUTEX_FLAG_HANDOFF 0x00
>> #define MUTEX_FLAG_PICKUP 0x04
>>
>> #define MUTEX_FLAGS 0x07
>>
>>
>> Thanks in advance and regards,
>
>Ok. So it is a regression, and you can ask Linus to apply this
>.. but... that's kind of heavy solution. Peter, do you have any other
>ideas?
>
> Pavel
Hi,
I did not mention the one line patch from Takashi Iwai as a means of fix
but as a hint. Sorry for misunderstanding.
Here is a another hint from another user:
I found that passing the options i8042.reset=1 i8042.dumbkbd=1 i8042.direct=1
results in the keyboard functioning after resume. However, there is a
long delay before the keyboard or mouse will respond to input on the
lock screen.[1]
[1] https://bugzilla.kernel.org/show_bug.cgi?id=195471#c39
--
Numan Demirdöğen
[-- Attachment #2: Dijital OpenPGP imzası --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* Re: [PATCH v4 6/8] iio: adc: add STMPE ADC devicetree bindings
From: Rob Herring @ 2018-12-17 22:15 UTC (permalink / raw)
To: Philippe Schenker
Cc: jic23, marcel.ziswiler, stefan, thierry.reding, Max Krummenacher,
Philippe Schenker, devicetree, linux-iio, Hartmut Knaack,
Alexandre Torgue, linux-input, linux-kernel, Dmitry Torokhov,
Lee Jones, Maxime Coquelin, Mark Rutland, Peter Meerwald-Stadler,
linux-stm32, linux-arm-kernel, Lars-Peter Clausen
In-Reply-To: <20181212130649.15146-6-dev@pschenker.ch>
On Wed, Dec 12, 2018 at 02:06:47PM +0100, Philippe Schenker wrote:
> From: Stefan Agner <stefan@agner.ch>
>
> This adds the devicetree bindings for the STMPE ADC. And corrects a
> typo in st,sample-time it is rather "6 -> 124 clocks" according
> to the datasheet and not 144.
>
> Signed-off-by: Stefan Agner <stefan@agner.ch>
> Signed-off-by: Max Krummenacher <max.krummenacher@toradex.com>
> Signed-off-by: Philippe Schenker <philippe.schenker@toradex.com>
> ---
>
> Changes in v4:
> - Put reformatting in a separate precursor patch.
>
> Changes in v3:
> - Reformatted documentation for touchscreen to use tabs and have a better
> overview of the settings.
> - Added note which adc-settings will take precedence.
> - changed typo in sample-time setting from 144 clocks to 124 clocks, as stated
> in the datasheet.
>
> Changes in v2:
> - Moved the bindings for ADC to the overlying mfd.
> - Reformatted for better readability
>
> .../devicetree/bindings/iio/adc/stmpe-adc.txt | 21 ++++++++++++
> .../bindings/input/touchscreen/stmpe.txt | 32 +++++++++----------
> .../devicetree/bindings/mfd/stmpe.txt | 14 ++++++++
> 3 files changed, 51 insertions(+), 16 deletions(-)
> create mode 100644 Documentation/devicetree/bindings/iio/adc/stmpe-adc.txt
>
> diff --git a/Documentation/devicetree/bindings/iio/adc/stmpe-adc.txt b/Documentation/devicetree/bindings/iio/adc/stmpe-adc.txt
> new file mode 100644
> index 000000000000..480e66422625
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/iio/adc/stmpe-adc.txt
> @@ -0,0 +1,21 @@
> +STMPE ADC driver
> +----------------
> +
> +Required properties:
> + - compatible: "st,stmpe-adc"
> +
> +Optional properties:
> +Note that the ADC is shared with the STMPE touchscreen. ADC related settings
> +have to be done in the mfd.
> +- st,norequest-mask: bitmask specifying which ADC channels should _not_ be
> + requestable due to different usage (e.g. touch)
> +
> +Node name must be stmpe_adc and should be child node of stmpe node to
> +which it belongs.
> +
> +Example:
> +
> + stmpe_adc {
> + compatible = "st,stmpe-adc";
> + st,norequest-mask = <0x0F>; /* dont use ADC CH3-0 */
> + };
> diff --git a/Documentation/devicetree/bindings/input/touchscreen/stmpe.txt b/Documentation/devicetree/bindings/input/touchscreen/stmpe.txt
> index 1d3f84308142..8e2b240882fa 100644
> --- a/Documentation/devicetree/bindings/input/touchscreen/stmpe.txt
> +++ b/Documentation/devicetree/bindings/input/touchscreen/stmpe.txt
> @@ -5,18 +5,6 @@ Required properties:
> - compatible: "st,stmpe-ts"
>
> Optional properties:
> -- st,sample-time : ADC conversion time in number of clock.
> - 0 -> 36 clocks 4 -> 80 clocks (recommended)
> - 1 -> 44 clocks 5 -> 96 clocks
> - 2 -> 56 clocks 6 -> 144 clocks
> - 3 -> 64 clocks
> -- st,mod-12b : ADC Bit mode
> - 0 -> 10bit ADC 1 -> 12bit ADC
> -- st,ref-sel : ADC reference source
> - 0 -> internal 1 -> external
> -- st,adc-freq : ADC Clock speed
> - 0 -> 1.625 MHz 2 || 3 -> 6.5 MHz
> - 1 -> 3.25 MHz
> - st,ave-ctrl : Sample average control
> 0 -> 1 sample
> 1 -> 2 samples
> @@ -40,17 +28,29 @@ Optional properties:
> 0 -> 20 mA (typical 35mA max)
> 1 -> 50 mA (typical 80 mA max)
>
> +Optional properties common with MFD (deprecated):
> + - st,sample-time : ADC conversion time in number of clock.
> + 0 -> 36 clocks 4 -> 80 clocks (recommended)
> + 1 -> 44 clocks 5 -> 96 clocks
> + 2 -> 56 clocks 6 -> 124 clocks
> + 3 -> 64 clocks
> + - st,mod-12b : ADC Bit mode
> + 0 -> 10bit ADC 1 -> 12bit ADC
> + - st,ref-sel : ADC reference source
> + 0 -> internal 1 -> external
> + - st,adc-freq : ADC Clock speed
> + 0 -> 1.625 MHz 2 || 3 -> 6.5 MHz
> + 1 -> 3.25 MHz
> +
> Node name must be stmpe_touchscreen and should be child node of stmpe node to
> which it belongs.
>
> +Note that common ADC settings of stmpe_touchscreen will take precedence.
This isn't clear. The parent or child properties take precedence?
> +
> Example:
>
> stmpe_touchscreen {
> compatible = "st,stmpe-ts";
> - st,sample-time = <4>;
> - st,mod-12b = <1>;
> - st,ref-sel = <0>;
> - st,adc-freq = <1>;
It would be nice to see an example with both ADC and touchscreen.
> st,ave-ctrl = <1>;
> st,touch-det-delay = <2>;
> st,settling = <2>;
> diff --git a/Documentation/devicetree/bindings/mfd/stmpe.txt b/Documentation/devicetree/bindings/mfd/stmpe.txt
> index a46e7177195d..d4408a417193 100644
> --- a/Documentation/devicetree/bindings/mfd/stmpe.txt
> +++ b/Documentation/devicetree/bindings/mfd/stmpe.txt
> @@ -14,6 +14,20 @@ Optional properties:
> - st,autosleep-timeout : Valid entries (ms); 4, 16, 32, 64, 128, 256, 512 and 1024
> - irq-gpio : If present, which GPIO to use for event IRQ
>
> +Optional properties for devices with touch and ADC (STMPE811|STMPE610):
> + - st,sample-time : ADC conversion time in number of clock.
> + 0 -> 36 clocks 4 -> 80 clocks (recommended)
> + 1 -> 44 clocks 5 -> 96 clocks
> + 2 -> 56 clocks 6 -> 124 clocks
> + 3 -> 64 clocks
> + - st,mod-12b : ADC Bit mode
> + 0 -> 10bit ADC 1 -> 12bit ADC
> + - st,ref-sel : ADC reference source
> + 0 -> internal 1 -> external
> + - st,adc-freq : ADC Clock speed
> + 0 -> 1.625 MHz 2 || 3 -> 6.5 MHz
> + 1 -> 3.25 MHz
> +
> Example:
>
> stmpe1601: stmpe1601@40 {
> --
> 2.19.2
>
^ permalink raw reply
* Re: [PATCH v4 1/8] dt-bindings: stmpe: reformatting parameter list and use tabs only
From: Rob Herring @ 2018-12-17 22:06 UTC (permalink / raw)
To: Philippe Schenker
Cc: jic23, marcel.ziswiler, stefan, thierry.reding, Philippe Schenker,
devicetree, Max Krummenacher, Alexandre Torgue, linux-input,
linux-kernel, Dmitry Torokhov, Lee Jones, Maxime Coquelin,
Mark Rutland, linux-stm32, linux-arm-kernel
In-Reply-To: <20181212130649.15146-1-dev@pschenker.ch>
On Wed, Dec 12, 2018 at 02:06:42PM +0100, Philippe Schenker wrote:
> This patch reformats the parameter list for stmpe device in a
> table-style so it is more clear to read.
>
> Signed-off-by: Philippe Schenker <philippe.schenker@toradex.com>
Need to fix the author and S-o-b emails to match.
> ---
>
> Changes in v4:
> - New separate precursor patch for holding reformatting
>
> Changes in v3: None
> Changes in v2: None
>
> .../bindings/input/touchscreen/stmpe.txt | 52 ++++++++++++-------
> .../devicetree/bindings/mfd/stmpe.txt | 14 ++---
> 2 files changed, 41 insertions(+), 25 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/input/touchscreen/stmpe.txt b/Documentation/devicetree/bindings/input/touchscreen/stmpe.txt
> index 127baa31a77a..1d3f84308142 100644
> --- a/Documentation/devicetree/bindings/input/touchscreen/stmpe.txt
> +++ b/Documentation/devicetree/bindings/input/touchscreen/stmpe.txt
> @@ -5,24 +5,40 @@ Required properties:
> - compatible: "st,stmpe-ts"
>
> Optional properties:
> -- st,sample-time: ADC converstion time in number of clock. (0 -> 36 clocks, 1 ->
> - 44 clocks, 2 -> 56 clocks, 3 -> 64 clocks, 4 -> 80 clocks, 5 -> 96 clocks, 6
> - -> 144 clocks), recommended is 4.
> -- st,mod-12b: ADC Bit mode (0 -> 10bit ADC, 1 -> 12bit ADC)
> -- st,ref-sel: ADC reference source (0 -> internal reference, 1 -> external
> - reference)
> -- st,adc-freq: ADC Clock speed (0 -> 1.625 MHz, 1 -> 3.25 MHz, 2 || 3 -> 6.5 MHz)
> -- st,ave-ctrl: Sample average control (0 -> 1 sample, 1 -> 2 samples, 2 -> 4
> - samples, 3 -> 8 samples)
> -- st,touch-det-delay: Touch detect interrupt delay (0 -> 10 us, 1 -> 50 us, 2 ->
> - 100 us, 3 -> 500 us, 4-> 1 ms, 5 -> 5 ms, 6 -> 10 ms, 7 -> 50 ms) recommended
> - is 3
> -- st,settling: Panel driver settling time (0 -> 10 us, 1 -> 100 us, 2 -> 500 us, 3
> - -> 1 ms, 4 -> 5 ms, 5 -> 10 ms, 6 for 50 ms, 7 -> 100 ms) recommended is 2
> -- st,fraction-z: Length of the fractional part in z (fraction-z ([0..7]) = Count of
> - the fractional part) recommended is 7
> -- st,i-drive: current limit value of the touchscreen drivers (0 -> 20 mA typical 35
> - mA max, 1 -> 50 mA typical 80 mA max)
> +- st,sample-time : ADC conversion time in number of clock.
> + 0 -> 36 clocks 4 -> 80 clocks (recommended)
> + 1 -> 44 clocks 5 -> 96 clocks
> + 2 -> 56 clocks 6 -> 144 clocks
> + 3 -> 64 clocks
Just make this a 1 column list
> +- st,mod-12b : ADC Bit mode
> + 0 -> 10bit ADC 1 -> 12bit ADC
> +- st,ref-sel : ADC reference source
> + 0 -> internal 1 -> external
> +- st,adc-freq : ADC Clock speed
> + 0 -> 1.625 MHz 2 || 3 -> 6.5 MHz
> + 1 -> 3.25 MHz
> +- st,ave-ctrl : Sample average control
> + 0 -> 1 sample
> + 1 -> 2 samples
> + 2 -> 4 samples
> + 3 -> 8 samples
> +- st,touch-det-delay : Touch detect interrupt delay (recommended is 3)
> + 0 -> 10 us 5 -> 5 ms
> + 1 -> 50 us 6 -> 10 ms
> + 2 -> 100 us 7 -> 50 ms
> + 3 -> 500 us
> + 4 -> 1 ms
> +- st,settling : Panel driver settling time (recommended is 2)
> + 0 -> 10 us 5 -> 10 ms
> + 1 -> 100 us 6 for 50 ms
> + 2 -> 500 us 7 -> 100 ms
> + 3 -> 1 ms
> + 4 -> 5 ms
> +- st,fraction-z : Length of the fractional part in z (recommended is 7)
> + (fraction-z ([0..7]) = Count of the fractional part)
> +- st,i-drive : current limit value of the touchscreen drivers
> + 0 -> 20 mA (typical 35mA max)
> + 1 -> 50 mA (typical 80 mA max)
>
> Node name must be stmpe_touchscreen and should be child node of stmpe node to
> which it belongs.
> diff --git a/Documentation/devicetree/bindings/mfd/stmpe.txt b/Documentation/devicetree/bindings/mfd/stmpe.txt
> index c797c05cd3c2..a46e7177195d 100644
> --- a/Documentation/devicetree/bindings/mfd/stmpe.txt
> +++ b/Documentation/devicetree/bindings/mfd/stmpe.txt
> @@ -4,15 +4,15 @@ STMPE is an MFD device which may expose the following inbuilt devices: gpio,
> keypad, touchscreen, adc, pwm, rotator.
>
> Required properties:
> - - compatible : "st,stmpe[610|801|811|1600|1601|2401|2403]"
> - - reg : I2C/SPI address of the device
> + - compatible : "st,stmpe[610|801|811|1600|1601|2401|2403]"
> + - reg : I2C/SPI address of the device
>
> Optional properties:
> - - interrupts : The interrupt outputs from the controller
> - - interrupt-controller : Marks the device node as an interrupt controller
> - - wakeup-source : Marks the input device as wakable
> - - st,autosleep-timeout : Valid entries (ms); 4, 16, 32, 64, 128, 256, 512 and 1024
> - - irq-gpio : If present, which GPIO to use for event IRQ
> + - interrupts : The interrupt outputs from the controller
> + - interrupt-controller : Marks the device node as an interrupt controller
> + - wakeup-source : Marks the input device as wakable
> + - st,autosleep-timeout : Valid entries (ms); 4, 16, 32, 64, 128, 256, 512 and 1024
> + - irq-gpio : If present, which GPIO to use for event IRQ
>
> Example:
>
> --
> 2.19.2
>
^ permalink raw reply
* Re: [PATCH] HID: intel-ish-hid: fixes incorrect error handling
From: Jiri Kosina @ 2018-12-17 14:05 UTC (permalink / raw)
To: Pan Bian; +Cc: Srinivas Pandruvada, Benjamin Tissoires, linux-input,
linux-kernel
In-Reply-To: <1542847953-127599-1-git-send-email-bianpan2016@163.com>
On Thu, 22 Nov 2018, Pan Bian wrote:
> The memory chunk allocated by hid_allocate_device() should be released
> by hid_destroy_device(), not kfree().
>
> Fixes: 0b28cb4bcb1("HID: intel-ish-hid: ISH HID client driver")
> Signed-off-by: Pan Bian <bianpan2016@163.com>
> ---
> drivers/hid/intel-ish-hid/ishtp-hid.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/hid/intel-ish-hid/ishtp-hid.c b/drivers/hid/intel-ish-hid/ishtp-hid.c
> index cd23903..e918d78 100644
> --- a/drivers/hid/intel-ish-hid/ishtp-hid.c
> +++ b/drivers/hid/intel-ish-hid/ishtp-hid.c
> @@ -222,7 +222,7 @@ int ishtp_hid_probe(unsigned int cur_hid_dev,
> err_hid_device:
> kfree(hid_data);
> err_hid_data:
> - kfree(hid);
> + hid_destroy_device(hid);
> return rv;
Applied to for-4.20/upstream-fixes. Thanks,
--
Jiri Kosina
SUSE Labs
^ permalink raw reply
* Re: [PATCH v2] HID: asus: Add support for the ASUS T101HA keyboard dock
From: Benjamin Tissoires @ 2018-12-17 13:23 UTC (permalink / raw)
To: kernelrocks; +Cc: Jiri Kosina, open list:HID CORE LAYER, lkml, mbrugger
In-Reply-To: <20181216155319.GA17189@arks.localdomain>
On Sun, Dec 16, 2018 at 4:52 PM Aleix Roca Nonell <kernelrocks@gmail.com> wrote:
>
> The ASUS T101HA keyboard dock generates HID events using the ASUS vendor
> specific UsagePage 0xff31. In consequence, some multimedia keys such as
> brightness up and down are not working with hid-generic.
>
> This commit adds the T101HA dock into the supported device list of the
> hid-asus driver. It also prevents the dock's integrated touchpad to be
> bound with hid-asus given that it is already working fine with
> hid-multitouch.
>
> Signed-off-by: Aleix Roca Nonell <kernelrocks@gmail.com>
> ---
>
> Changes in v2:
> - use the report descriptor's application usage to identify the dock's
> touchpad instead of the usb interface id
Thanks for the quick respin.
Pushed into 4.21/hid-asus.
Cheers,
Benjamin
>
> drivers/hid/hid-asus.c | 8 ++++++++
> drivers/hid/hid-ids.h | 1 +
> 2 files changed, 9 insertions(+)
>
> diff --git a/drivers/hid/hid-asus.c b/drivers/hid/hid-asus.c
> index ab8bd40a77ed..951bb17ae8b2 100644
> --- a/drivers/hid/hid-asus.c
> +++ b/drivers/hid/hid-asus.c
> @@ -70,6 +70,7 @@ MODULE_DESCRIPTION("Asus HID Keyboard and TouchPad");
> #define QUIRK_T100_KEYBOARD BIT(6)
> #define QUIRK_T100CHI BIT(7)
> #define QUIRK_G752_KEYBOARD BIT(8)
> +#define QUIRK_T101HA_DOCK BIT(9)
>
> #define I2C_KEYBOARD_QUIRKS (QUIRK_FIX_NOTEBOOK_REPORT | \
> QUIRK_NO_INIT_REPORTS | \
> @@ -699,6 +700,11 @@ static int asus_probe(struct hid_device *hdev, const struct hid_device_id *id)
> return ret;
> }
>
> + /* use hid-multitouch for T101HA touchpad */
> + if (id->driver_data & QUIRK_T101HA_DOCK &&
> + hdev->collection->usage == HID_GD_MOUSE)
> + return -ENODEV;
> +
> ret = hid_hw_start(hdev, HID_CONNECT_DEFAULT);
> if (ret) {
> hid_err(hdev, "Asus hw start failed: %d\n", ret);
> @@ -830,6 +836,8 @@ static const struct hid_device_id asus_devices[] = {
> { HID_USB_DEVICE(USB_VENDOR_ID_ASUSTEK,
> USB_DEVICE_ID_ASUSTEK_T100TAF_KEYBOARD),
> QUIRK_T100_KEYBOARD | QUIRK_NO_CONSUMER_USAGES },
> + { HID_USB_DEVICE(USB_VENDOR_ID_ASUSTEK,
> + USB_DEVICE_ID_ASUSTEK_T101HA_KEYBOARD), QUIRK_T101HA_DOCK },
> { HID_USB_DEVICE(USB_VENDOR_ID_CHICONY, USB_DEVICE_ID_ASUS_AK1D) },
> { HID_USB_DEVICE(USB_VENDOR_ID_TURBOX, USB_DEVICE_ID_ASUS_MD_5110) },
> { HID_USB_DEVICE(USB_VENDOR_ID_JESS, USB_DEVICE_ID_ASUS_MD_5112) },
> diff --git a/drivers/hid/hid-ids.h b/drivers/hid/hid-ids.h
> index 4206428c0ba2..f1eee2778b70 100644
> --- a/drivers/hid/hid-ids.h
> +++ b/drivers/hid/hid-ids.h
> @@ -184,6 +184,7 @@
> #define USB_DEVICE_ID_ASUSTEK_T100TA_KEYBOARD 0x17e0
> #define USB_DEVICE_ID_ASUSTEK_T100TAF_KEYBOARD 0x1807
> #define USB_DEVICE_ID_ASUSTEK_T100CHI_KEYBOARD 0x8502
> +#define USB_DEVICE_ID_ASUSTEK_T101HA_KEYBOARD 0x183d
> #define USB_DEVICE_ID_ASUSTEK_T304_KEYBOARD 0x184a
> #define USB_DEVICE_ID_ASUSTEK_I2C_KEYBOARD 0x8585
> #define USB_DEVICE_ID_ASUSTEK_I2C_TOUCHPAD 0x0101
> --
> 2.20.0
>
^ permalink raw reply
* [PATCH v4] MAINTAINERS: add maintainers for ChromeOS EC sub-drivers
From: Enric Balletbo i Serra @ 2018-12-17 9:54 UTC (permalink / raw)
To: linux-kernel
Cc: Alessandro Zummo, linux-pwm, linux-iio, Alexandre Belloni,
linux-i2c, groeck, kernel, linux-rtc, Chanwoo Choi, Benson Leung,
Sebastian Reichel, linux-input, Dmitry Torokhov, Jonathan Cameron,
Peter Meerwald-Stadler, devicetree, Thierry Reding, linux-pm,
MyungJoo Ham, Lee Jones, Hartmut Knaack, Rob Herring, Lars
There are multiple ChromeOS EC sub-drivers spread in different
subsystems, as all of them are related to the Chrome stuff add
Benson and myself as a maintainers for all these sub-drivers.
Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
Signed-off-by: Benson Leung <bleung@chromium.org>
Acked-by: Wolfram Sang <wsa@the-dreams.de>
Acked-by: Chanwoo Choi <cw00.choi@samsung.com>
Acked-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Acked-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Acked-by: Lee Jones <lee.jones@linaro.org>
Acked-by: Sebastian Reichel <sebastian.reichel@collabora.com>
Acked-by: Guenter Roeck <groeck@chromium.org>
---
Changes in v4:
- Remove the `for iio parts` from Jonathan's acked-by tag.
- Add more collected acks.
- Use two N patterns.
Changes in v3:
- Add collected acks
- Use a cros[-_]ec pattern instead of list all the files.
- Add Guenter as a reviewer.
Changes in v2:
- Fix typo in Benson email address.
MAINTAINERS | 9 +++++++++
1 file changed, 9 insertions(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index fa6e2ad90568..1e27b24e912e 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -3629,6 +3629,15 @@ S: Maintained
T: git git://git.kernel.org/pub/scm/linux/kernel/git/bleung/chrome-platform.git
F: drivers/platform/chrome/
+CHROMEOS EC SUBDRIVERS
+M: Benson Leung <bleung@chromium.org>
+M: Enric Balletbo i Serra <enric.balletbo@collabora.com>
+R: Guenter Roeck <groeck@chromium.org>
+S: Maintained
+N: cros_ec
+N: cros-ec
+F: drivers/power/supply/cros_usbpd-charger.c
+
CIRRUS LOGIC AUDIO CODEC DRIVERS
M: Brian Austin <brian.austin@cirrus.com>
M: Paul Handrigan <Paul.Handrigan@cirrus.com>
--
2.19.2
^ permalink raw reply related
* Re: Elantech SMBus support regression
From: Kai Heng Feng @ 2018-12-17 7:25 UTC (permalink / raw)
To: Benjamin Tissoires; +Cc: Dmitry Torokhov, open list:HID CORE LAYER, lkml
In-Reply-To: <CAO-hwJ+fshPj7xbJoBvK8uGrhfKCdFSmzicmmOyMJS0cdzAapQ@mail.gmail.com>
Hi,
> On Dec 12, 2018, at 22:25, Benjamin Tissoires <benjamin.tissoires@redhat.com> wrote:
>
> Hi,
>
> sorry for the late reply. I was always meaning to fix this the proper
> way but couldn't dedicate a full day of work to go to the bottom of
> elan_i2c.
>
> Meanwhile, I am thinking at simply having a blacklist of devices that
> we know are not working well (P52, L480, L580 and P72).
>
> Could you get the value of /sys/bus/serio/devices/serio1/firmware_id
> from all of these laptops?
> I know the P52 is LEN2131, but I don't seem to find the other PNPIds.
These are feedbacks from the users:
L480:
cat /sys/bus/serio/devices/serio1/firmware_id
PNP: LEN2036 PNP0f13
P52:
"cat /sys/bus/serio/devices/serio1/firmware_id":
PNP: LEN2132 PNP0f13
So looks like it’s different to LEN2131.
Kai-Heng
>
> Cheers,
> Benjamin
>
> On Thu, Nov 22, 2018 at 5:22 AM Kai Heng Feng
> <kai.heng.feng@canonical.com> wrote:
>>
>> Hi Benjamin,
>>
>> It appears the Elantech SMBus support breaks some users’ touchpad.
>>
>> Please have a look at [1] [2], thanks!
>>
>> [1] https://bugs.launchpad.net/bugs/1803600
>> [2] https://bugs.archlinux.org/task/59714
>>
>> Kai-Heng
^ permalink raw reply
* Re: [PATCH v5 3/3] Input: atmel_mxt_ts: Document optional voltage regulators
From: Sebastian Reichel @ 2018-12-16 22:41 UTC (permalink / raw)
To: Paweł Chmiel
Cc: nick, mark.rutland, devicetree, alexandre.belloni,
dmitry.torokhov, linux-kernel, robh+dt, linux-input,
linux-arm-kernel
In-Reply-To: <20181214151214.5391-4-pawel.mikolaj.chmiel@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1738 bytes --]
Hi,
On Fri, Dec 14, 2018 at 04:12:14PM +0100, Paweł Chmiel wrote:
> Document new optional voltage regulators, which can be used
> to power down/up touchscreen.
>
> Signed-off-by: Paweł Chmiel <pawel.mikolaj.chmiel@gmail.com>
> Reviewed-by: Rob Herring <robh@kernel.org>
Reviewed-by: Sebastian Reichel <sebastian.reichel@collabora.com>
-- Sebastian
> ---
> Changes from v1:
> - Added reviewed-by
> ---
> .../devicetree/bindings/input/atmel,maxtouch.txt | 8 ++++++++
> 1 file changed, 8 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/input/atmel,maxtouch.txt b/Documentation/devicetree/bindings/input/atmel,maxtouch.txt
> index c88919480d37..17930ecadad3 100644
> --- a/Documentation/devicetree/bindings/input/atmel,maxtouch.txt
> +++ b/Documentation/devicetree/bindings/input/atmel,maxtouch.txt
> @@ -31,6 +31,12 @@ Optional properties for main touchpad device:
>
> - reset-gpios: GPIO specifier for the touchscreen's reset pin (active low)
>
> +- avdd-supply: Analog power supply. It powers up the analog channel block
> + of the controller to detect the touches.
> +
> +- vdd-supply: Digital power supply. It powers up the digital block
> + of the controller to enable i2c communication.
> +
> Example:
>
> touch@4b {
> @@ -38,4 +44,6 @@ Example:
> reg = <0x4b>;
> interrupt-parent = <&gpio>;
> interrupts = <TEGRA_GPIO(W, 3) IRQ_TYPE_LEVEL_LOW>;
> + avdd-supply = <&atsp_reg>;
> + vdd-supply = <&tsp_reg>;
> };
> --
> 2.17.1
>
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* [PATCH v2] HID: asus: Add support for the ASUS T101HA keyboard dock
From: Aleix Roca Nonell @ 2018-12-16 15:53 UTC (permalink / raw)
To: Jiri Kosina, Benjamin Tissoires
Cc: linux-input, linux-kernel, mbrugger, kernelrocks
The ASUS T101HA keyboard dock generates HID events using the ASUS vendor
specific UsagePage 0xff31. In consequence, some multimedia keys such as
brightness up and down are not working with hid-generic.
This commit adds the T101HA dock into the supported device list of the
hid-asus driver. It also prevents the dock's integrated touchpad to be
bound with hid-asus given that it is already working fine with
hid-multitouch.
Signed-off-by: Aleix Roca Nonell <kernelrocks@gmail.com>
---
Changes in v2:
- use the report descriptor's application usage to identify the dock's
touchpad instead of the usb interface id
drivers/hid/hid-asus.c | 8 ++++++++
drivers/hid/hid-ids.h | 1 +
2 files changed, 9 insertions(+)
diff --git a/drivers/hid/hid-asus.c b/drivers/hid/hid-asus.c
index ab8bd40a77ed..951bb17ae8b2 100644
--- a/drivers/hid/hid-asus.c
+++ b/drivers/hid/hid-asus.c
@@ -70,6 +70,7 @@ MODULE_DESCRIPTION("Asus HID Keyboard and TouchPad");
#define QUIRK_T100_KEYBOARD BIT(6)
#define QUIRK_T100CHI BIT(7)
#define QUIRK_G752_KEYBOARD BIT(8)
+#define QUIRK_T101HA_DOCK BIT(9)
#define I2C_KEYBOARD_QUIRKS (QUIRK_FIX_NOTEBOOK_REPORT | \
QUIRK_NO_INIT_REPORTS | \
@@ -699,6 +700,11 @@ static int asus_probe(struct hid_device *hdev, const struct hid_device_id *id)
return ret;
}
+ /* use hid-multitouch for T101HA touchpad */
+ if (id->driver_data & QUIRK_T101HA_DOCK &&
+ hdev->collection->usage == HID_GD_MOUSE)
+ return -ENODEV;
+
ret = hid_hw_start(hdev, HID_CONNECT_DEFAULT);
if (ret) {
hid_err(hdev, "Asus hw start failed: %d\n", ret);
@@ -830,6 +836,8 @@ static const struct hid_device_id asus_devices[] = {
{ HID_USB_DEVICE(USB_VENDOR_ID_ASUSTEK,
USB_DEVICE_ID_ASUSTEK_T100TAF_KEYBOARD),
QUIRK_T100_KEYBOARD | QUIRK_NO_CONSUMER_USAGES },
+ { HID_USB_DEVICE(USB_VENDOR_ID_ASUSTEK,
+ USB_DEVICE_ID_ASUSTEK_T101HA_KEYBOARD), QUIRK_T101HA_DOCK },
{ HID_USB_DEVICE(USB_VENDOR_ID_CHICONY, USB_DEVICE_ID_ASUS_AK1D) },
{ HID_USB_DEVICE(USB_VENDOR_ID_TURBOX, USB_DEVICE_ID_ASUS_MD_5110) },
{ HID_USB_DEVICE(USB_VENDOR_ID_JESS, USB_DEVICE_ID_ASUS_MD_5112) },
diff --git a/drivers/hid/hid-ids.h b/drivers/hid/hid-ids.h
index 4206428c0ba2..f1eee2778b70 100644
--- a/drivers/hid/hid-ids.h
+++ b/drivers/hid/hid-ids.h
@@ -184,6 +184,7 @@
#define USB_DEVICE_ID_ASUSTEK_T100TA_KEYBOARD 0x17e0
#define USB_DEVICE_ID_ASUSTEK_T100TAF_KEYBOARD 0x1807
#define USB_DEVICE_ID_ASUSTEK_T100CHI_KEYBOARD 0x8502
+#define USB_DEVICE_ID_ASUSTEK_T101HA_KEYBOARD 0x183d
#define USB_DEVICE_ID_ASUSTEK_T304_KEYBOARD 0x184a
#define USB_DEVICE_ID_ASUSTEK_I2C_KEYBOARD 0x8585
#define USB_DEVICE_ID_ASUSTEK_I2C_TOUCHPAD 0x0101
--
2.20.0
^ permalink raw reply related
* Re: [PATCH v4 6/8] iio: adc: add STMPE ADC devicetree bindings
From: Jonathan Cameron @ 2018-12-16 12:28 UTC (permalink / raw)
To: Philippe Schenker
Cc: marcel.ziswiler, stefan, thierry.reding, Max Krummenacher,
Philippe Schenker, devicetree, linux-iio, Hartmut Knaack,
Alexandre Torgue, linux-input, linux-kernel, Rob Herring,
Dmitry Torokhov, Lee Jones, Maxime Coquelin, Mark Rutland,
Peter Meerwald-Stadler, linux-stm32, linux-arm-kernel,
Lars-Peter Clausen
In-Reply-To: <20181212130649.15146-6-dev@pschenker.ch>
On Wed, 12 Dec 2018 14:06:47 +0100
Philippe Schenker <dev@pschenker.ch> wrote:
> From: Stefan Agner <stefan@agner.ch>
>
> This adds the devicetree bindings for the STMPE ADC. And corrects a
> typo in st,sample-time it is rather "6 -> 124 clocks" according
> to the datasheet and not 144.
>
> Signed-off-by: Stefan Agner <stefan@agner.ch>
> Signed-off-by: Max Krummenacher <max.krummenacher@toradex.com>
> Signed-off-by: Philippe Schenker <philippe.schenker@toradex.com>
This still conflates a couple of different things but we can argue
about patch separation for ever so never mind.
Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
> ---
>
> Changes in v4:
> - Put reformatting in a separate precursor patch.
>
> Changes in v3:
> - Reformatted documentation for touchscreen to use tabs and have a better
> overview of the settings.
> - Added note which adc-settings will take precedence.
> - changed typo in sample-time setting from 144 clocks to 124 clocks, as stated
> in the datasheet.
>
> Changes in v2:
> - Moved the bindings for ADC to the overlying mfd.
> - Reformatted for better readability
>
> .../devicetree/bindings/iio/adc/stmpe-adc.txt | 21 ++++++++++++
> .../bindings/input/touchscreen/stmpe.txt | 32 +++++++++----------
> .../devicetree/bindings/mfd/stmpe.txt | 14 ++++++++
> 3 files changed, 51 insertions(+), 16 deletions(-)
> create mode 100644 Documentation/devicetree/bindings/iio/adc/stmpe-adc.txt
>
> diff --git a/Documentation/devicetree/bindings/iio/adc/stmpe-adc.txt b/Documentation/devicetree/bindings/iio/adc/stmpe-adc.txt
> new file mode 100644
> index 000000000000..480e66422625
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/iio/adc/stmpe-adc.txt
> @@ -0,0 +1,21 @@
> +STMPE ADC driver
> +----------------
> +
> +Required properties:
> + - compatible: "st,stmpe-adc"
> +
> +Optional properties:
> +Note that the ADC is shared with the STMPE touchscreen. ADC related settings
> +have to be done in the mfd.
> +- st,norequest-mask: bitmask specifying which ADC channels should _not_ be
> + requestable due to different usage (e.g. touch)
> +
> +Node name must be stmpe_adc and should be child node of stmpe node to
> +which it belongs.
> +
> +Example:
> +
> + stmpe_adc {
> + compatible = "st,stmpe-adc";
> + st,norequest-mask = <0x0F>; /* dont use ADC CH3-0 */
> + };
> diff --git a/Documentation/devicetree/bindings/input/touchscreen/stmpe.txt b/Documentation/devicetree/bindings/input/touchscreen/stmpe.txt
> index 1d3f84308142..8e2b240882fa 100644
> --- a/Documentation/devicetree/bindings/input/touchscreen/stmpe.txt
> +++ b/Documentation/devicetree/bindings/input/touchscreen/stmpe.txt
> @@ -5,18 +5,6 @@ Required properties:
> - compatible: "st,stmpe-ts"
>
> Optional properties:
> -- st,sample-time : ADC conversion time in number of clock.
> - 0 -> 36 clocks 4 -> 80 clocks (recommended)
> - 1 -> 44 clocks 5 -> 96 clocks
> - 2 -> 56 clocks 6 -> 144 clocks
> - 3 -> 64 clocks
> -- st,mod-12b : ADC Bit mode
> - 0 -> 10bit ADC 1 -> 12bit ADC
> -- st,ref-sel : ADC reference source
> - 0 -> internal 1 -> external
> -- st,adc-freq : ADC Clock speed
> - 0 -> 1.625 MHz 2 || 3 -> 6.5 MHz
> - 1 -> 3.25 MHz
> - st,ave-ctrl : Sample average control
> 0 -> 1 sample
> 1 -> 2 samples
> @@ -40,17 +28,29 @@ Optional properties:
> 0 -> 20 mA (typical 35mA max)
> 1 -> 50 mA (typical 80 mA max)
>
> +Optional properties common with MFD (deprecated):
> + - st,sample-time : ADC conversion time in number of clock.
> + 0 -> 36 clocks 4 -> 80 clocks (recommended)
> + 1 -> 44 clocks 5 -> 96 clocks
> + 2 -> 56 clocks 6 -> 124 clocks
> + 3 -> 64 clocks
> + - st,mod-12b : ADC Bit mode
> + 0 -> 10bit ADC 1 -> 12bit ADC
> + - st,ref-sel : ADC reference source
> + 0 -> internal 1 -> external
> + - st,adc-freq : ADC Clock speed
> + 0 -> 1.625 MHz 2 || 3 -> 6.5 MHz
> + 1 -> 3.25 MHz
> +
> Node name must be stmpe_touchscreen and should be child node of stmpe node to
> which it belongs.
>
> +Note that common ADC settings of stmpe_touchscreen will take precedence.
> +
> Example:
>
> stmpe_touchscreen {
> compatible = "st,stmpe-ts";
> - st,sample-time = <4>;
> - st,mod-12b = <1>;
> - st,ref-sel = <0>;
> - st,adc-freq = <1>;
> st,ave-ctrl = <1>;
> st,touch-det-delay = <2>;
> st,settling = <2>;
> diff --git a/Documentation/devicetree/bindings/mfd/stmpe.txt b/Documentation/devicetree/bindings/mfd/stmpe.txt
> index a46e7177195d..d4408a417193 100644
> --- a/Documentation/devicetree/bindings/mfd/stmpe.txt
> +++ b/Documentation/devicetree/bindings/mfd/stmpe.txt
> @@ -14,6 +14,20 @@ Optional properties:
> - st,autosleep-timeout : Valid entries (ms); 4, 16, 32, 64, 128, 256, 512 and 1024
> - irq-gpio : If present, which GPIO to use for event IRQ
>
> +Optional properties for devices with touch and ADC (STMPE811|STMPE610):
> + - st,sample-time : ADC conversion time in number of clock.
> + 0 -> 36 clocks 4 -> 80 clocks (recommended)
> + 1 -> 44 clocks 5 -> 96 clocks
> + 2 -> 56 clocks 6 -> 124 clocks
> + 3 -> 64 clocks
> + - st,mod-12b : ADC Bit mode
> + 0 -> 10bit ADC 1 -> 12bit ADC
> + - st,ref-sel : ADC reference source
> + 0 -> internal 1 -> external
> + - st,adc-freq : ADC Clock speed
> + 0 -> 1.625 MHz 2 || 3 -> 6.5 MHz
> + 1 -> 3.25 MHz
> +
> Example:
>
> stmpe1601: stmpe1601@40 {
^ permalink raw reply
* [PATCH v3 4/4] Input: goodix - Add GT5663 CTP support
From: Jagan Teki @ 2018-12-15 15:18 UTC (permalink / raw)
To: Dmitry Torokhov
Cc: Chen-Yu Tsai, linux-input, linux-kernel, Michael Trimarchi,
linux-amarula, Jagan Teki
In-Reply-To: <20181215151802.18592-1-jagan@amarulasolutions.com>
GT5663 is capacitive touch controller with customized smart
wakeup gestures.
Add support for it by adding compatible and supported chip data.
The chip data on GT5663 is similar to GT1151, like
- config data register has 0x8050 address
- config data register max len is 240
- config data checksum has 16-bit
Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
---
drivers/input/touchscreen/goodix.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/input/touchscreen/goodix.c b/drivers/input/touchscreen/goodix.c
index 7371f6946098..735ab8e246b6 100644
--- a/drivers/input/touchscreen/goodix.c
+++ b/drivers/input/touchscreen/goodix.c
@@ -218,6 +218,7 @@ static const struct goodix_chip_data *goodix_get_chip_data(u16 id)
{
switch (id) {
case 1151:
+ case 5663:
return >1x_chip_data;
case 911:
@@ -965,6 +966,7 @@ MODULE_DEVICE_TABLE(acpi, goodix_acpi_match);
#ifdef CONFIG_OF
static const struct of_device_id goodix_of_match[] = {
{ .compatible = "goodix,gt1151" },
+ { .compatible = "goodix,gt5663" },
{ .compatible = "goodix,gt911" },
{ .compatible = "goodix,gt9110" },
{ .compatible = "goodix,gt912" },
--
2.18.0.321.gffc6fa0e3
^ permalink raw reply related
* [PATCH v3 3/4] dt-bindings: input: touchscreen: goodix: Add GT5663 compatible
From: Jagan Teki @ 2018-12-15 15:18 UTC (permalink / raw)
To: Dmitry Torokhov
Cc: Chen-Yu Tsai, linux-input, linux-kernel, Michael Trimarchi,
linux-amarula, Jagan Teki
In-Reply-To: <20181215151802.18592-1-jagan@amarulasolutions.com>
GT5663 is capacitive touch controller with customized smart
wakeup gestures, it support chipdata which is similar to
existing GT1151 and require AVDD28 supply for some boards.
Document the compatible for the same.
Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
---
Documentation/devicetree/bindings/input/touchscreen/goodix.txt | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/devicetree/bindings/input/touchscreen/goodix.txt b/Documentation/devicetree/bindings/input/touchscreen/goodix.txt
index c4622c983e08..59c89276e6bb 100644
--- a/Documentation/devicetree/bindings/input/touchscreen/goodix.txt
+++ b/Documentation/devicetree/bindings/input/touchscreen/goodix.txt
@@ -3,6 +3,7 @@ Device tree bindings for Goodix GT9xx series touchscreen controller
Required properties:
- compatible : Should be "goodix,gt1151"
+ or "goodix,gt5663"
or "goodix,gt911"
or "goodix,gt9110"
or "goodix,gt912"
--
2.18.0.321.gffc6fa0e3
^ permalink raw reply related
* [PATCH v3 2/4] Input: goodix - Add AVDD28-supply regulator support
From: Jagan Teki @ 2018-12-15 15:18 UTC (permalink / raw)
To: Dmitry Torokhov
Cc: Chen-Yu Tsai, linux-input, linux-kernel, Michael Trimarchi,
linux-amarula, Jagan Teki
In-Reply-To: <20181215151802.18592-1-jagan@amarulasolutions.com>
Goodix CTP controllers have AVDD28 pin connected to voltage
regulator which may not be turned on by default, like for GT5663.
Add support for such ctp used boards by adding voltage regulator
handling code to goodix ctp driver.
Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
---
drivers/input/touchscreen/goodix.c | 33 +++++++++++++++++++++++++-----
1 file changed, 28 insertions(+), 5 deletions(-)
diff --git a/drivers/input/touchscreen/goodix.c b/drivers/input/touchscreen/goodix.c
index f2d9c2c41885..7371f6946098 100644
--- a/drivers/input/touchscreen/goodix.c
+++ b/drivers/input/touchscreen/goodix.c
@@ -27,6 +27,7 @@
#include <linux/delay.h>
#include <linux/irq.h>
#include <linux/interrupt.h>
+#include <linux/regulator/consumer.h>
#include <linux/slab.h>
#include <linux/acpi.h>
#include <linux/of.h>
@@ -47,6 +48,7 @@ struct goodix_ts_data {
struct touchscreen_properties prop;
unsigned int max_touch_num;
unsigned int int_trigger_type;
+ struct regulator *avdd28;
struct gpio_desc *gpiod_int;
struct gpio_desc *gpiod_rst;
u16 id;
@@ -786,25 +788,41 @@ static int goodix_ts_probe(struct i2c_client *client,
if (error)
return error;
+ ts->avdd28 = devm_regulator_get(&client->dev, "AVDD28");
+ if (IS_ERR(ts->avdd28)) {
+ error = PTR_ERR(ts->avdd28);
+ if (error != -EPROBE_DEFER)
+ dev_err(&client->dev,
+ "Failed to get AVDD28 regulator: %d\n", error);
+ return error;
+ }
+
+ /* power the controller */
+ error = regulator_enable(ts->avdd28);
+ if (error) {
+ dev_err(&client->dev, "Controller fail to enable AVDD28\n");
+ return error;
+ }
+
if (ts->gpiod_int && ts->gpiod_rst) {
/* reset the controller */
error = goodix_reset(ts);
if (error) {
dev_err(&client->dev, "Controller reset failed.\n");
- return error;
+ goto error;
}
}
error = goodix_i2c_test(client);
if (error) {
dev_err(&client->dev, "I2C communication failure: %d\n", error);
- return error;
+ goto error;
}
error = goodix_read_version(ts);
if (error) {
dev_err(&client->dev, "Read version failed.\n");
- return error;
+ goto error;
}
ts->chip = goodix_get_chip_data(ts->id);
@@ -823,23 +841,28 @@ static int goodix_ts_probe(struct i2c_client *client,
dev_err(&client->dev,
"Failed to invoke firmware loader: %d\n",
error);
- return error;
+ goto error;
}
return 0;
} else {
error = goodix_configure_dev(ts);
if (error)
- return error;
+ goto error;
}
return 0;
+
+error:
+ regulator_disable(ts->avdd28);
+ return error;
}
static int goodix_ts_remove(struct i2c_client *client)
{
struct goodix_ts_data *ts = i2c_get_clientdata(client);
+ regulator_disable(ts->avdd28);
if (ts->gpiod_int && ts->gpiod_rst)
wait_for_completion(&ts->firmware_loading_complete);
--
2.18.0.321.gffc6fa0e3
^ permalink raw reply related
* [PATCH v3 1/4] dt-bindings: input: touchscreen: goodix: Document AVDD28-supply property
From: Jagan Teki @ 2018-12-15 15:17 UTC (permalink / raw)
To: Dmitry Torokhov
Cc: Chen-Yu Tsai, linux-input, linux-kernel, Michael Trimarchi,
linux-amarula, Jagan Teki
In-Reply-To: <20181215151802.18592-1-jagan@amarulasolutions.com>
Most of the Goodix CTP controllers are supply with AVDD28 pin.
which need to supply for controllers like GT5663 on some boards
to trigger the power.
So, document the supply property so-that the require boards
that used on GT5663 can enable it via device tree.
Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
---
Documentation/devicetree/bindings/input/touchscreen/goodix.txt | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/devicetree/bindings/input/touchscreen/goodix.txt b/Documentation/devicetree/bindings/input/touchscreen/goodix.txt
index f7e95c52f3c7..c4622c983e08 100644
--- a/Documentation/devicetree/bindings/input/touchscreen/goodix.txt
+++ b/Documentation/devicetree/bindings/input/touchscreen/goodix.txt
@@ -23,6 +23,7 @@ Optional properties:
- touchscreen-inverted-y : Y axis is inverted (boolean)
- touchscreen-swapped-x-y : X and Y axis are swapped (boolean)
(swapping is done after inverting the axis)
+ - AVDD28-supply : Analog power supply regulator on AVDD28 pin
Example:
--
2.18.0.321.gffc6fa0e3
^ permalink raw reply related
* [PATCH v3 0/4] input: touchscreen: Add goodix GT5553 CTP support
From: Jagan Teki @ 2018-12-15 15:17 UTC (permalink / raw)
To: Dmitry Torokhov
Cc: Chen-Yu Tsai, linux-input, linux-kernel, Michael Trimarchi,
linux-amarula, Jagan Teki
This patchset support goodix GT5553 CTP.
Changes for v3:
- add cover-letter
- s/ADVV28/AVDD28 on commit head
- fix few typo
Changes for v2:
- Rename vcc-supply with AVDD28-supply
- disable regulator in remove
- fix to setup regulator in probe code
- add chipdata
- drop example node in dt-bindings
Jagan Teki (4):
dt-bindings: input: touchscreen: goodix: Document AVDD28-supply
property
Input: goodix - Add AVDD28-supply regulator support
dt-bindings: input: touchscreen: goodix: Add GT5663 compatible
Input: goodix - Add GT5663 CTP support
.../bindings/input/touchscreen/goodix.txt | 2 ++
drivers/input/touchscreen/goodix.c | 35 ++++++++++++++++---
2 files changed, 32 insertions(+), 5 deletions(-)
--
2.18.0.321.gffc6fa0e3
^ permalink raw reply
* Re: [PATCH v3 7/8] HID: logitech: Enable high-resolution scrolling on Logitech mice
From: Clément VUCHENER @ 2018-12-15 14:45 UTC (permalink / raw)
To: Harry Cutts
Cc: Peter Hutterer, linux-input, Dmitry Torokhov, Jiri Kosina,
torvalds, Nestor Lopez Casado, lkml, Benjamin Tissoires
In-Reply-To: <CA+jURcuhBRYiqFYHDgK8dDycrPgvzkujTRZfnmYraiHvwE+e6w@mail.gmail.com>
Le ven. 14 déc. 2018 à 19:37, Harry Cutts <hcutts@chromium.org> a écrit :
>
> Hi Clement,
>
> On Fri, 14 Dec 2018 at 05:47, Clément VUCHENER
> <clement.vuchener@gmail.com> wrote:
> > Hi, The G500s (and the G500 too, I think) does support the "scrolling
> > acceleration" bit. If I set it, I get around 8 events for each wheel
> > "click", this is what this driver expects, right? If I understood
> > correctly, I should try this patch with the
> > HIDPP_QUIRK_HI_RES_SCROLL_1P0 quirk set for my mouse.
>
> Thanks for the info! Yes, that should work.
Well, it is not that simple. I get "Device not connected" errors for
both interfaces of the mouse.
logitech-hidpp-device 0003:046D:C24E.000E: Device not connected
logitech-hidpp-device 0003:046D:C24E.000F: Device not connected
Here is the usbmon trace when connecting a G500s:
0cd42cc0 3.313741 C Ii:3:001:1 0:2048 1 =
04
0cd42cc0 3.313750 S Ii:3:001:1 -:2048 4 <
17b49a80 3.313764 S Ci:3:001:0 s a3 00 0000 0002 0004 4 <
17b49a80 3.313775 C Ci:3:001:0 0 4 =
01010100
17b49a80 3.313781 S Co:3:001:0 s 23 01 0010 0002 0000 0
17b49a80 3.313789 C Co:3:001:0 0 0
17b49a80 3.313792 S Ci:3:001:0 s a3 00 0000 0002 0004 4 <
17b49a80 3.313797 C Ci:3:001:0 0 4 =
01010000
17b49a80 3.340415 S Ci:3:001:0 s a3 00 0000 0002 0004 4 <
17b49a80 3.340438 C Ci:3:001:0 0 4 =
01010000
17b49a80 3.367434 S Ci:3:001:0 s a3 00 0000 0002 0004 4 <
17b49a80 3.367448 C Ci:3:001:0 0 4 =
01010000
17b49a80 3.394434 S Ci:3:001:0 s a3 00 0000 0002 0004 4 <
17b49a80 3.394449 C Ci:3:001:0 0 4 =
01010000
17b49a80 3.421416 S Ci:3:001:0 s a3 00 0000 0002 0004 4 <
17b49a80 3.421431 C Ci:3:001:0 0 4 =
01010000
17b49a80 3.421690 S Co:3:001:0 s 23 03 0004 0002 0000 0
17b49a80 3.421707 C Co:3:001:0 0 0
17b49a80 3.483421 S Ci:3:001:0 s a3 00 0000 0002 0004 4 <
17b49a80 3.483436 C Ci:3:001:0 0 4 =
11010000
17b499c0 3.545429 S Ci:3:001:0 s a3 00 0000 0002 0004 4 <
17b499c0 3.545442 C Ci:3:001:0 0 4 =
03011000
17b499c0 3.545448 S Co:3:001:0 s 23 01 0014 0002 0000 0
17b499c0 3.545456 C Co:3:001:0 0 0
17b499c0 3.597659 S Ci:3:000:0 s 80 06 0100 0000 0040 64 <
17b499c0 3.597851 C Ci:3:000:0 0 8 =
12010002 00000008
17b499c0 3.597870 S Co:3:001:0 s 23 03 0004 0002 0000 0
17b499c0 3.597884 C Co:3:001:0 0 0
17b499c0 3.659419 S Ci:3:001:0 s a3 00 0000 0002 0004 4 <
17b499c0 3.659434 C Ci:3:001:0 0 4 =
11010000
17b499c0 3.721421 S Ci:3:001:0 s a3 00 0000 0002 0004 4 <
17b499c0 3.721435 C Ci:3:001:0 0 4 =
03011000
17b499c0 3.721442 S Co:3:001:0 s 23 01 0014 0002 0000 0
17b499c0 3.721451 C Co:3:001:0 0 0
17b49600 3.788420 S Ci:3:007:0 s 80 06 0100 0000 0012 18 <
17b49600 3.788897 C Ci:3:007:0 0 18 =
12010002 00000008 6d044ec2 01840102 0301
. . . . . . . . m . N . . . . . . .
17b49600 3.788920 S Ci:3:007:0 s 80 06 0600 0000 000a 10 <
17b49600 3.789057 C Ci:3:007:0 -32 0
17b49600 3.789092 S Ci:3:007:0 s 80 06 0600 0000 000a 10 <
17b49600 3.789438 C Ci:3:007:0 -32 0
17b49600 3.789459 S Ci:3:007:0 s 80 06 0600 0000 000a 10 <
17b49600 3.789827 C Ci:3:007:0 -32 0
17b49600 3.789850 S Ci:3:007:0 s 80 06 0200 0000 0009 9 <
17b49600 3.790272 C Ci:3:007:0 0 9 =
09023b00 020104a0 31
. . ; . . . . . 1
17b49600 3.790285 S Ci:3:007:0 s 80 06 0200 0000 003b 59 <
17b49600 3.791004 C Ci:3:007:0 0 59 =
09023b00 020104a0 31090400 00010301 02000921 11010001 22430007 05810308
. . ; . . . . . 1 . . . . . . . . . . ! . . . . " C . . . . . .
17b49600 3.791021 S Ci:3:007:0 s 80 06 0300 0000 00ff 255 <
17b49600 3.791203 C Ci:3:007:0 0 4 =
04030904
17b49600 3.791212 S Ci:3:007:0 s 80 06 0302 0409 00ff 255 <
17b49600 3.791829 C Ci:3:007:0 0 50 =
32034700 35003000 30007300 20004c00 61007300 65007200 20004700 61006d00
2 . G . 5 . 0 . 0 . s . . L . a . s . e . r . . G . a . m .
17b49600 3.791844 S Ci:3:007:0 s 80 06 0301 0409 00ff 255 <
17b49600 3.792141 C Ci:3:007:0 0 18 =
12034c00 6f006700 69007400 65006300 6800
. . L . o . g . i . t . e . c . h .
17b49600 3.792154 S Ci:3:007:0 s 80 06 0303 0409 00ff 255 <
17b49600 3.792563 C Ci:3:007:0 0 30 =
1e033300 34004500 31003300 38003500 30003800 36003000 30003000 3900
. . 3 . 4 . E . 1 . 3 . 8 . 5 . 0 . 8 . 6 . 0 . 0 . 0 . 9 .
17b49300 3.795944 S Co:3:007:0 s 00 09 0001 0000 0000 0
17b49300 3.795998 C Co:3:007:0 0 0
17b49300 3.796025 S Ci:3:007:0 s 80 06 0304 0409 00ff 255 <
17b49300 3.796392 C Ci:3:007:0 0 26 =
1a035500 38003400 2e003000 31005f00 42003000 30003000 3900
. . U . 8 . 4 . . . 0 . 1 . _ . B . 0 . 0 . 0 . 9 .
17b49900 3.796473 S Ci:3:007:0 s 80 06 0303 0409 00ff 255 <
17b49900 3.796883 C Ci:3:007:0 0 30 =
1e033300 34004500 31003300 38003500 30003800 36003000 30003000 3900
. . 3 . 4 . E . 1 . 3 . 8 . 5 . 0 . 8 . 6 . 0 . 0 . 0 . 9 .
17b49900 3.796914 S Co:3:007:0 s 21 0a 0000 0000 0000 0
17b49900 3.797027 C Co:3:007:0 -32 0
17b49900 3.797056 S Ci:3:007:0 s 81 06 2200 0000 0043 67 <
17b49900 3.798055 C Ci:3:007:0 0 67 =
05010902 a1010901 a1000509 19012910 15002501 95107501 81020501 16018026
. . . . . . . . . . . . . . ) . . . % . . . u . . . . . . . . &
17b49840 3.798350 S Co:3:007:0 s 21 09 0211 0000 0014 20 =
11ff0011 00000000 00000000 00000000 00000000
17b49840 3.798500 C Co:3:007:0 0 20 >
17b49240 9.289560 S Ci:3:007:0 s 80 06 0303 0409 00ff 255 <
17b49240 9.289999 C Ci:3:007:0 0 30 =
1e033300 34004500 31003300 38003500 30003800 36003000 30003000 3900
. . 3 . 4 . E . 1 . 3 . 8 . 5 . 0 . 8 . 6 . 0 . 0 . 0 . 9 .
17b49240 9.290040 S Co:3:007:0 s 21 0a 0000 0001 0000 0
17b49240 9.290145 C Co:3:007:0 -32 0
17b49240 9.290155 S Ci:3:007:0 s 81 06 2200 0001 007a 122 <
17b49240 9.291756 C Ci:3:007:0 0 122 =
05010906 a1018501 050719e0 29e71500 25017501 95088102 95057508 150026a4
. . . . . . . . . . . . ) . . . % . u . . . . . . . u . . . & .
17b49c00 9.292167 S Co:3:007:0 s 21 09 0211 0001 0014 20 =
11ff0011 00000000 00000000 00000000 00000000
17b49c00 9.292628 C Co:3:007:0 0 20 >
It looks like the mouse is not responding to the
root_get_protocol_version packet. I don't know why, but even if it
did, it would not work correctly. The HID++ reports will only work
with one of the interfaces, the other should be ignored by the driver
instead of being disabled because it failed to respond to the HID++
report. The G500s and G500 HID++ interface also use the device index 0
instead of 0xff.
For comparison, if I use my distribution kernel
(4.19.7-200.fc28.x86_64) and send reports from user-space (using
hidraw) instead of for-4.21/highres-wheel kernel. I get this kind of
trace:
592193c0 0.253975 S Co:3:003:0 s 21 09 0211 0001 0014 20 =
11ff0011 00000000 00000000 00000000 00000000
592193c0 0.254426 C Co:3:003:0 0 20 >
9ee5ff00 0.255859 C Ii:3:003:2 0:1 7 =
10ff8f00 110800
9ee5ff00 0.255867 S Ii:3:003:2 -:1 20 <
592193c0 11.116794 S Co:3:003:0 s 21 09 0211 0001 0014 20 =
11000011 00000000 00000000 00000000 00000000
592193c0 11.117258 C Co:3:003:0 0 20 >
9ee5ff00 11.118023 C Ii:3:003:2 0:1 7 =
10008f00 110100
9ee5ff00 11.118033 S Ii:3:003:2 -:1 20 <
When using device index 0xff the mouse responds with a
ERR_UNKNOWN_DEVICE (0x08) error, when using device index 0 it responds
ERR_INVALID_SUBID (0x01), the expected error for a HID++1.0 device.
Here is the diff from the for-4.21/highres-wheel branch, I only added
the devices to the device list with the required quirk.
diff --git a/drivers/hid/hid-ids.h b/drivers/hid/hid-ids.h
index ed35c9a9a110..a1c431e7841c 100644
--- a/drivers/hid/hid-ids.h
+++ b/drivers/hid/hid-ids.h
@@ -724,6 +724,7 @@
#define USB_DEVICE_ID_LOGITECH_KEYBOARD_G710_PLUS 0xc24d
#define USB_DEVICE_ID_LOGITECH_MOUSE_C01A 0xc01a
#define USB_DEVICE_ID_LOGITECH_MOUSE_C05A 0xc05a
+#define USB_DEVICE_ID_LOGITECH_MOUSE_G500 0xc068
#define USB_DEVICE_ID_LOGITECH_MOUSE_C06A 0xc06a
#define USB_DEVICE_ID_LOGITECH_RUMBLEPAD_CORD 0xc20a
#define USB_DEVICE_ID_LOGITECH_RUMBLEPAD 0xc211
@@ -731,6 +732,7 @@
#define USB_DEVICE_ID_LOGITECH_DUAL_ACTION 0xc216
#define USB_DEVICE_ID_LOGITECH_RUMBLEPAD2 0xc218
#define USB_DEVICE_ID_LOGITECH_RUMBLEPAD2_2 0xc219
+#define USB_DEVICE_ID_LOGITECH_MOUSE_G500S 0xc24e
#define USB_DEVICE_ID_LOGITECH_G29_WHEEL 0xc24f
#define USB_DEVICE_ID_LOGITECH_G920_WHEEL 0xc262
#define USB_DEVICE_ID_LOGITECH_WINGMAN_F3D 0xc283
diff --git a/drivers/hid/hid-logitech-hidpp.c b/drivers/hid/hid-logitech-hidpp.c
index 15ed6177a7a3..b9b34ce455a4 100644
--- a/drivers/hid/hid-logitech-hidpp.c
+++ b/drivers/hid/hid-logitech-hidpp.c
@@ -3416,6 +3416,10 @@ static const struct hid_device_id hidpp_devices[] = {
{ HID_USB_DEVICE(USB_VENDOR_ID_LOGITECH,
USB_DEVICE_ID_LOGITECH_G920_WHEEL),
.driver_data = HIDPP_QUIRK_CLASS_G920 |
HIDPP_QUIRK_FORCE_OUTPUT_REPORTS},
+ { HID_USB_DEVICE(USB_VENDOR_ID_LOGITECH,
USB_DEVICE_ID_LOGITECH_MOUSE_G500),
+ .driver_data = HIDPP_QUIRK_HI_RES_SCROLL_1P0 },
+ { HID_USB_DEVICE(USB_VENDOR_ID_LOGITECH,
USB_DEVICE_ID_LOGITECH_MOUSE_G500S),
+ .driver_data = HIDPP_QUIRK_HI_RES_SCROLL_1P0 },
{}
};
^ permalink raw reply related
* Re: [rfd] saving old mice -- button glitching/debouncing
From: Pavel Machek @ 2018-12-15 10:29 UTC (permalink / raw)
To: Vojtech Pavlik; +Cc: kernel list, jikos, linux-input, dmitry.torokhov
In-Reply-To: <20181215101221.GA23879@suse.com>
[-- Attachment #1: Type: text/plain, Size: 1336 bytes --]
On Sat 2018-12-15 11:12:21, Vojtech Pavlik wrote:
> On Sat, Dec 15, 2018 at 10:47:22AM +0100, Pavel Machek wrote:
>
> > > > b) would it be acceptable if done properly? (cmd line option to
> > > > enable, avoiding duplicate/wrong events?)
> > >
> > > Well, for one, you shouldn't be using a timer, all the debouncing can be
> > > done by math on the event timestamps.
> >
> > Not... really, right? You need to send an release some time after
> > button indicates release if bounce did not happen. It is similar to
> > autorepeat needing a timer.
>
> You can send the first release and ignore all presses and releases in a
> time window after that.
I could, and it would work for glitches on release, but that would do
very bad things if switch glitched on press, right?
"XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX XX " ->
"XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX " ... ok
"XX XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX..." ->
"XX ..." ... bad idea. [Maybe could be
detected with "XX " being unusually short?]
But I believe I see
"XXXXXXXXXXXXXXXXXXXXXXXXXX XXXXXXXXXXXXXXXXXXXXXXX" on X220 device, too.
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]
^ permalink raw reply
* Re: [rfd] saving old mice -- button glitching/debouncing
From: Vojtech Pavlik @ 2018-12-15 10:12 UTC (permalink / raw)
To: Pavel Machek; +Cc: kernel list, jikos, linux-input, dmitry.torokhov
In-Reply-To: <20181215094722.GA5804@amd>
On Sat, Dec 15, 2018 at 10:47:22AM +0100, Pavel Machek wrote:
> > > b) would it be acceptable if done properly? (cmd line option to
> > > enable, avoiding duplicate/wrong events?)
> >
> > Well, for one, you shouldn't be using a timer, all the debouncing can be
> > done by math on the event timestamps.
>
> Not... really, right? You need to send an release some time after
> button indicates release if bounce did not happen. It is similar to
> autorepeat needing a timer.
You can send the first release and ignore all presses and releases in a
time window after that.
> Let me gain some experience with the patch. I don't think hardware
> does as heavy debouncing as you describe.
Microswitches vibrate significantly when clicked. Without hardware
debouncing, you'd have many clicks instead of one even on a new mouse.
--
Vojtech Pavlik
^ permalink raw reply
* Re: [rfd] saving old mice -- button glitching/debouncing
From: Pavel Machek @ 2018-12-15 9:47 UTC (permalink / raw)
To: Vojtech Pavlik; +Cc: kernel list, jikos, linux-input, dmitry.torokhov
In-Reply-To: <20181215085510.GB12930@suse.com>
[-- Attachment #1: Type: text/plain, Size: 1237 bytes --]
Hi!
> > Patch is obviously not ready; but:
> >
> > a) would it be useful to people
>
> Probably not.
>
> Mice already do internal software/hardware debouncing on switches. If you
> see duplicate clicks making it all the way to the kernel driver, something
> is very wrong with the switch, to the point where it'll soon fail
> completely.
It seems mice normally survive 2 years under my use. This one has left
button repaired and middle button failing... If debouncing gives it
one more year, it will be success...
> > b) would it be acceptable if done properly? (cmd line option to
> > enable, avoiding duplicate/wrong events?)
>
> Well, for one, you shouldn't be using a timer, all the debouncing can be
> done by math on the event timestamps.
Not... really, right? You need to send an release some time after
button indicates release if bounce did not happen. It is similar to
autorepeat needing a timer.
Let me gain some experience with the patch. I don't think hardware
does as heavy debouncing as you describe.
Best regards,
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]
^ permalink raw reply
* [PATCH v5] Input: i8042 add i8042_is_mr_coffee() helper to avoid refconut leak
From: Yangtao Li @ 2018-12-15 9:08 UTC (permalink / raw)
To: dmitry.torokhov; +Cc: tiny.windzz, linux-input, linux-kernel
of_find_node_by_path() acquires a reference to the node returned by
it and that reference needs to be dropped by its caller. Add
i8042_is_mr_coffee() helper to avoid refconut leak.
Signed-off-by: Yangtao Li <tiny.windzz@gmail.com>
---
changes in v5:
-fix typo
changes in v4:
-fix typo
changes in v3:
-add i8042_is_mr_coffee
---
drivers/input/serio/i8042-sparcio.h | 20 ++++++++++++++++----
1 file changed, 16 insertions(+), 4 deletions(-)
diff --git a/drivers/input/serio/i8042-sparcio.h b/drivers/input/serio/i8042-sparcio.h
index 796289846204..9e9e512bc432 100644
--- a/drivers/input/serio/i8042-sparcio.h
+++ b/drivers/input/serio/i8042-sparcio.h
@@ -106,11 +106,23 @@ static struct platform_driver sparc_i8042_driver = {
.remove = sparc_i8042_remove,
};
+static inline bool i8042_is_mr_coffee(void)
+{
+ struct device_node *root;
+ bool is_mr_coffee;
+
+ root = of_find_node_by_path("/");
+ is_mr_coffee = !strcmp(root->name, "SUNW,JavaStation-1");
+ of_node_put(root);
+
+ return is_mr_coffee;
+}
+
static int __init i8042_platform_init(void)
{
- struct device_node *root = of_find_node_by_path("/");
+ bool match = i8042_is_mr_coffee();
- if (!strcmp(root->name, "SUNW,JavaStation-1")) {
+ if (match) {
/* Hardcoded values for MrCoffee. */
i8042_kbd_irq = i8042_aux_irq = 13 | 0x20;
kbd_iobase = ioremap(0x71300060, 8);
@@ -138,9 +150,9 @@ static int __init i8042_platform_init(void)
static inline void i8042_platform_exit(void)
{
- struct device_node *root = of_find_node_by_path("/");
+ bool match = i8042_is_mr_coffee();
- if (strcmp(root->name, "SUNW,JavaStation-1"))
+ if (!match)
platform_driver_unregister(&sparc_i8042_driver);
}
--
2.17.0
^ permalink raw reply related
* Re: [rfd] saving old mice -- button glitching/debouncing
From: Vojtech Pavlik @ 2018-12-15 8:55 UTC (permalink / raw)
To: Pavel Machek; +Cc: kernel list, jikos, linux-input, dmitry.torokhov
In-Reply-To: <20181214232437.GA8310@amd>
On Sat, Dec 15, 2018 at 12:24:37AM +0100, Pavel Machek wrote:
> Patch is obviously not ready; but:
>
> a) would it be useful to people
Probably not.
Mice already do internal software/hardware debouncing on switches. If you
see duplicate clicks making it all the way to the kernel driver, something
is very wrong with the switch, to the point where it'll soon fail
completely.
Hence the value of doing extra processing in the kernel is very limited.
> b) would it be acceptable if done properly? (cmd line option to
> enable, avoiding duplicate/wrong events?)
Well, for one, you shouldn't be using a timer, all the debouncing can be
done by math on the event timestamps.
You'd also have a hard time distinguishing between doubleclicks and bounces.
Since the mice already filter the quick bounces and there is significant
delay (100ms on USB, similar on PS/2) between updates from the hardware, a
real doubleclick can look absolutely the same as what you observe as a
bounce.
As such, it couldn't be enabled by default.
If you really want to go this way, a userspace solution is the better choice.
--
Vojtech Pavlik
^ permalink raw reply
* Re: [rfd] saving old mice -- button glitching/debouncing
From: Dmitry Torokhov @ 2018-12-15 0:19 UTC (permalink / raw)
To: Pavel Machek
Cc: kernel list, jikos, Vojtech Pavlik, linux-input@vger.kernel.org
In-Reply-To: <20181214232437.GA8310@amd>
Hi Pavel,
On Fri, Dec 14, 2018 at 3:24 PM Pavel Machek <pavel@ucw.cz> wrote:
>
>
> I believe I have hardware problem, but I'm kind of hoping software
> could help me...?
>
> Mouse wheel on my machine started glitching on my machine, generating
> double-clicks when I click it once. Which unfortunately is quite
> annoying: texts are pasted twice, two tabs are closed instead of one,
> ....
>
> Event: time 1544733054.903129, type 4 (EV_MSC), code 4 (MSC_SCAN), value 90003
> Event: time 1544733054.903129, type 1 (EV_KEY), code 274 (BTN_MIDDLE), value 1
> Event: time 1544733054.903129, -------------- EV_SYN ------------
> 1544733054.967251, type 4 (EV_MSC), code 4 (MSC_SCAN), value 90003
> Event: time 1544733054.967251, type 1 (EV_KEY), code 274 (BTN_MIDDLE), value 0
> Event: time 1544733054.967251, -------------- EV_SYN ------------
> Event: time 1544733054.975144, type 4 (EV_MSC), code 4 (MSC_SCAN), value 90003
> Event: time 1544733054.975144, type 1 (EV_KEY), code 274 (BTN_MIDDLE), value 1
> Event: time 1544733054.975144, -------------- EV_SYN ------------
> : time 1544733065.127190, type 4 (EV_MSC), code 4 (MSC_SCAN), value 90003
> Event: time 1544733065.127190, type 1 (EV_KEY), code 274 (BTN_MIDDLE), value 0
> Event: time 1544733065.127190, -------------- EV_SYN ------------
>
> Now, I could just buy a new mouse, but it seems that most optical mice
> die like this... so maybe it would be nice to have an option to
> debounce the buttons, so that the useful life of mice is extended a
> bit?
>
> (So... I have two mice with that fault -- cheap to replace, but button
> in thinkpad X220 started doing that, too. That one will not be so
> cheap to fix :-( ).
>
> It is possible that some X versions already do something like this.
>
> Patch is obviously not ready; but:
>
> a) would it be useful to people
>
> b) would it be acceptable if done properly? (cmd line option to
> enable, avoiding duplicate/wrong events?)
I'd say if you are attached to failing hardware, solve it in
userspace. Have a utility/daemon that you run (from udev?) that:
- "grabs" input device with EVIOCGRAB
- does the debouncing/filtering/adjusting for the dirty sensor
- reinject events back into kernel with /dev/uinput
It will add some latency, but should be workable.
Thanks.
--
Dmitry
^ permalink raw reply
* [rfd] saving old mice -- button glitching/debouncing
From: Pavel Machek @ 2018-12-14 23:24 UTC (permalink / raw)
To: kernel list, jikos, vojtech, linux-input, dmitry.torokhov
[-- Attachment #1: Type: text/plain, Size: 6821 bytes --]
I believe I have hardware problem, but I'm kind of hoping software
could help me...?
Mouse wheel on my machine started glitching on my machine, generating
double-clicks when I click it once. Which unfortunately is quite
annoying: texts are pasted twice, two tabs are closed instead of one,
....
Event: time 1544733054.903129, type 4 (EV_MSC), code 4 (MSC_SCAN), value 90003
Event: time 1544733054.903129, type 1 (EV_KEY), code 274 (BTN_MIDDLE), value 1
Event: time 1544733054.903129, -------------- EV_SYN ------------
1544733054.967251, type 4 (EV_MSC), code 4 (MSC_SCAN), value 90003
Event: time 1544733054.967251, type 1 (EV_KEY), code 274 (BTN_MIDDLE), value 0
Event: time 1544733054.967251, -------------- EV_SYN ------------
Event: time 1544733054.975144, type 4 (EV_MSC), code 4 (MSC_SCAN), value 90003
Event: time 1544733054.975144, type 1 (EV_KEY), code 274 (BTN_MIDDLE), value 1
Event: time 1544733054.975144, -------------- EV_SYN ------------
: time 1544733065.127190, type 4 (EV_MSC), code 4 (MSC_SCAN), value 90003
Event: time 1544733065.127190, type 1 (EV_KEY), code 274 (BTN_MIDDLE), value 0
Event: time 1544733065.127190, -------------- EV_SYN ------------
Now, I could just buy a new mouse, but it seems that most optical mice
die like this... so maybe it would be nice to have an option to
debounce the buttons, so that the useful life of mice is extended a
bit?
(So... I have two mice with that fault -- cheap to replace, but button
in thinkpad X220 started doing that, too. That one will not be so
cheap to fix :-( ).
It is possible that some X versions already do something like this.
Patch is obviously not ready; but:
a) would it be useful to people
b) would it be acceptable if done properly? (cmd line option to
enable, avoiding duplicate/wrong events?)
Thanks,
Pavel
Signed-off-by: Pavel Machek <pavel@ucw.cz>
diff --git a/drivers/input/input.c b/drivers/input/input.c
index 3304aaa..ce0d081 100644
--- a/drivers/input/input.c
+++ b/drivers/input/input.c
@@ -40,6 +40,11 @@ static DEFINE_IDA(input_ida);
static LIST_HEAD(input_dev_list);
static LIST_HEAD(input_handler_list);
+static void input_repeat_key(struct timer_list *t);
+static void input_debounce_key(struct timer_list *t);
+
+static int debounce = 20;
+
/*
* input_mutex protects access to both input_dev_list and input_handler_list.
* This also causes input_[un]register_device and input_[un]register_handler
@@ -77,6 +82,7 @@ static void input_start_autorepeat(struct input_dev *dev, int code)
if (test_bit(EV_REP, dev->evbit) &&
dev->rep[REP_PERIOD] && dev->rep[REP_DELAY] &&
dev->timer.function) {
+ dev->timer.function = input_repeat_key;
dev->repeat_key = code;
mod_timer(&dev->timer,
jiffies + msecs_to_jiffies(dev->rep[REP_DELAY]));
@@ -88,18 +94,42 @@ static void input_stop_autorepeat(struct input_dev *dev)
del_timer(&dev->timer);
}
+static void input_start_debounce(struct input_dev *dev, int code)
+{
+ dev->timer.function = input_debounce_key;
+ dev->debounce_key = code;
+ mod_timer(&dev->timer,
+ jiffies + msecs_to_jiffies(debounce));
+}
+
+static void input_stop_debounce(struct input_dev *dev)
+{
+ del_timer(&dev->timer);
+ dev->debounce_key = -1;
+}
+
/*
* Pass event first through all filters and then, if event has not been
* filtered out, through all open handles. This function is called with
* dev->event_lock held and interrupts disabled.
*/
-static unsigned int input_to_handler(struct input_handle *handle,
+static unsigned int input_to_handler(struct input_dev *dev, struct input_handle *handle,
struct input_value *vals, unsigned int count)
{
struct input_handler *handler = handle->handler;
struct input_value *end = vals;
struct input_value *v;
+ if (!test_bit(EV_REP, dev->evbit) && test_bit(EV_KEY, dev->evbit) && debounce)
+ for (v = vals; v != vals + count; v++) {
+ if (v->type == EV_KEY && v->value == 0 && dev->debounce_key == -1) {
+ input_start_debounce(dev, v->code);
+ v->code = -2;
+ }
+ if (v->type == EV_KEY && v->value == 1 && dev->debounce_key == v->code)
+ input_stop_debounce(dev);
+ }
+
if (handler->filter) {
for (v = vals; v != vals + count; v++) {
if (handler->filter(handle, v->type, v->code, v->value))
@@ -117,8 +147,9 @@ static unsigned int input_to_handler(struct input_handle *handle,
if (handler->events)
handler->events(handle, vals, count);
else if (handler->event)
- for (v = vals; v != vals + count; v++)
+ for (v = vals; v != vals + count; v++) {
handler->event(handle, v->type, v->code, v->value);
+ }
return count;
}
@@ -141,11 +172,11 @@ static void input_pass_values(struct input_dev *dev,
handle = rcu_dereference(dev->grab);
if (handle) {
- count = input_to_handler(handle, vals, count);
+ count = input_to_handler(dev, handle, vals, count);
} else {
list_for_each_entry_rcu(handle, &dev->h_list, d_node)
if (handle->open) {
- count = input_to_handler(handle, vals, count);
+ count = input_to_handler(dev, handle, vals, count);
if (!count)
break;
}
@@ -203,6 +234,27 @@ static void input_repeat_key(struct timer_list *t)
spin_unlock_irqrestore(&dev->event_lock, flags);
}
+/*
+ * Generate software autorepeat event. Note that we take
+ * dev->event_lock here to avoid racing with input_event
+ * which may cause keys get "stuck".
+ */
+static void input_debounce_key(struct timer_list *t)
+{
+ struct input_dev *dev = from_timer(dev, t, timer);
+ unsigned long flags;
+
+ struct input_value vals[] = {
+ { EV_KEY, dev->debounce_key, 0 },
+ input_value_sync
+ };
+
+ spin_lock_irqsave(&dev->event_lock, flags);
+ input_pass_values(dev, vals, ARRAY_SIZE(vals));
+ input_stop_debounce(dev);
+ spin_unlock_irqrestore(&dev->event_lock, flags);
+}
+
#define INPUT_IGNORE_EVENT 0
#define INPUT_PASS_TO_HANDLERS 1
#define INPUT_PASS_TO_DEVICE 2
@@ -2109,6 +2161,8 @@ int input_register_device(struct input_dev *dev)
/* Every input device generates EV_SYN/SYN_REPORT events. */
__set_bit(EV_SYN, dev->evbit);
+ dev->debounce_key = -1;
+
/* KEY_RESERVED is not supposed to be transmitted to userspace. */
__clear_bit(KEY_RESERVED, dev->keybit);
diff --git a/include/linux/input.h b/include/linux/input.h
index 7c7516e..b2458b2 100644
--- a/include/linux/input.h
+++ b/include/linux/input.h
@@ -150,6 +150,7 @@ struct input_dev {
struct ff_device *ff;
+ int debounce_key;
unsigned int repeat_key;
struct timer_list timer;
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]
^ permalink raw reply related
* mouse driver crashed on 4.15 kernel
From: Yury Norov @ 2018-12-14 19:20 UTC (permalink / raw)
To: Dmitry Torokhov; +Cc: yury.norov, linux-input, linux-kernel, kernel-team
[-- Attachment #1: Type: text/plain, Size: 6329 bytes --]
Hi Dmitry,
It just happened to me on standard Ubuntu laptop (Lenovo X1 gen 5), so
I had to reboot my machine. According to logs, there was also a problem
with the wifi, but wifi driver managed to recover the hardware.
Looking at dmesg I cannot find something useful because it was wiped
with a number of identical warning messages from the mouse and SMBus
drivers.
I'm just a victim, and don't know much, but at least I can recommend to
use dev_warn_once() to avoid spamming the system log if things like this
happen.
Some system information is below, and system log is attached. Hope it
will help.
Thanks,
Yury
$ uname -a
Linux yury-thinkpad 4.15.0-42-generic #45-Ubuntu SMP Thu Nov 15 19:32:57 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux
$ dmesg|grep mouse
[ 1.089631] mousedev: PS/2 mouse device common for all mice
[ 2.553529] psmouse serio1: synaptics: queried max coordinates: x [..5676], y [..4760]
[ 2.584367] psmouse serio1: synaptics: queried min coordinates: x [1266..], y [1094..]
[ 2.584370] psmouse serio1: synaptics: Trying to set up SMBus access
[ 3.115236] psmouse serio2: trackpoint: Elan TrackPoint firmware: 0x04, buttons: 3/3
$ cat /proc/cpuinfo
processor : 0
vendor_id : GenuineIntel
cpu family : 6
model : 142
model name : Intel(R) Core(TM) i7-7600U CPU @ 2.80GHz
stepping : 9
microcode : 0x8e
cpu MHz : 1522.133
cache size : 4096 KB
physical id : 0
siblings : 4
core id : 0
cpu cores : 2
apicid : 0
initial apicid : 0
fpu : yes
fpu_exception : yes
cpuid level : 22
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx pdpe1gb rdtscp lm constant_tsc art arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc cpuid aperfmperf tsc_known_freq pni pclmulqdq dtes64 monitor ds_cpl vmx smx est tm2 ssse3 sdbg fma cx16 xtpr pdcm pcid sse4_1 sse4_2 x2apic movbe popcnt tsc_deadline_timer aes xsave avx f16c rdrand lahf_lm abm 3dnowprefetch cpuid_fault epb invpcid_single pti ssbd ibrs ibpb stibp tpr_shadow vnmi flexpriority ept vpid fsgsbase tsc_adjust bmi1 hle avx2 smep bmi2 erms invpcid rtm mpx rdseed adx smap clflushopt intel_pt xsaveopt xsavec xgetbv1 xsaves dtherm ida arat pln pts hwp hwp_notify hwp_act_window hwp_epp flush_l1d
bugs : cpu_meltdown spectre_v1 spectre_v2 spec_store_bypass l1tf
bogomips : 5808.00
clflush size : 64
cache_alignment : 64
address sizes : 39 bits physical, 48 bits virtual
power management:
processor : 1
vendor_id : GenuineIntel
cpu family : 6
model : 142
model name : Intel(R) Core(TM) i7-7600U CPU @ 2.80GHz
stepping : 9
microcode : 0x8e
cpu MHz : 1345.112
cache size : 4096 KB
physical id : 0
siblings : 4
core id : 1
cpu cores : 2
apicid : 2
initial apicid : 2
fpu : yes
fpu_exception : yes
cpuid level : 22
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx pdpe1gb rdtscp lm constant_tsc art arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc cpuid aperfmperf tsc_known_freq pni pclmulqdq dtes64 monitor ds_cpl vmx smx est tm2 ssse3 sdbg fma cx16 xtpr pdcm pcid sse4_1 sse4_2 x2apic movbe popcnt tsc_deadline_timer aes xsave avx f16c rdrand lahf_lm abm 3dnowprefetch cpuid_fault epb invpcid_single pti ssbd ibrs ibpb stibp tpr_shadow vnmi flexpriority ept vpid fsgsbase tsc_adjust bmi1 hle avx2 smep bmi2 erms invpcid rtm mpx rdseed adx smap clflushopt intel_pt xsaveopt xsavec xgetbv1 xsaves dtherm ida arat pln pts hwp hwp_notify hwp_act_window hwp_epp flush_l1d
bugs : cpu_meltdown spectre_v1 spectre_v2 spec_store_bypass l1tf
bogomips : 5808.00
clflush size : 64
cache_alignment : 64
address sizes : 39 bits physical, 48 bits virtual
power management:
processor : 2
vendor_id : GenuineIntel
cpu family : 6
model : 142
model name : Intel(R) Core(TM) i7-7600U CPU @ 2.80GHz
stepping : 9
microcode : 0x8e
cpu MHz : 1506.644
cache size : 4096 KB
physical id : 0
siblings : 4
core id : 0
cpu cores : 2
apicid : 1
initial apicid : 1
fpu : yes
fpu_exception : yes
cpuid level : 22
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx pdpe1gb rdtscp lm constant_tsc art arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc cpuid aperfmperf tsc_known_freq pni pclmulqdq dtes64 monitor ds_cpl vmx smx est tm2 ssse3 sdbg fma cx16 xtpr pdcm pcid sse4_1 sse4_2 x2apic movbe popcnt tsc_deadline_timer aes xsave avx f16c rdrand lahf_lm abm 3dnowprefetch cpuid_fault epb invpcid_single pti ssbd ibrs ibpb stibp tpr_shadow vnmi flexpriority ept vpid fsgsbase tsc_adjust bmi1 hle avx2 smep bmi2 erms invpcid rtm mpx rdseed adx smap clflushopt intel_pt xsaveopt xsavec xgetbv1 xsaves dtherm ida arat pln pts hwp hwp_notify hwp_act_window hwp_epp flush_l1d
bugs : cpu_meltdown spectre_v1 spectre_v2 spec_store_bypass l1tf
bogomips : 5808.00
clflush size : 64
cache_alignment : 64
address sizes : 39 bits physical, 48 bits virtual
power management:
processor : 3
vendor_id : GenuineIntel
cpu family : 6
model : 142
model name : Intel(R) Core(TM) i7-7600U CPU @ 2.80GHz
stepping : 9
microcode : 0x8e
cpu MHz : 1545.613
cache size : 4096 KB
physical id : 0
siblings : 4
core id : 1
cpu cores : 2
apicid : 3
initial apicid : 3
fpu : yes
fpu_exception : yes
cpuid level : 22
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx pdpe1gb rdtscp lm constant_tsc art arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc cpuid aperfmperf tsc_known_freq pni pclmulqdq dtes64 monitor ds_cpl vmx smx est tm2 ssse3 sdbg fma cx16 xtpr pdcm pcid sse4_1 sse4_2 x2apic movbe popcnt tsc_deadline_timer aes xsave avx f16c rdrand lahf_lm abm 3dnowprefetch cpuid_fault epb invpcid_single pti ssbd ibrs ibpb stibp tpr_shadow vnmi flexpriority ept vpid fsgsbase tsc_adjust bmi1 hle avx2 smep bmi2 erms invpcid rtm mpx rdseed adx smap clflushopt intel_pt xsaveopt xsavec xgetbv1 xsaves dtherm ida arat pln pts hwp hwp_notify hwp_act_window hwp_epp flush_l1d
bugs : cpu_meltdown spectre_v1 spectre_v2 spec_store_bypass l1tf
bogomips : 5808.00
clflush size : 64
cache_alignment : 64
address sizes : 39 bits physical, 48 bits virtual
power management:
[-- Attachment #2: dmesg.oops.gz --]
[-- Type: application/gzip, Size: 14593 bytes --]
^ permalink raw reply
* Re: [PATCH v3 7/8] HID: logitech: Enable high-resolution scrolling on Logitech mice
From: Harry Cutts @ 2018-12-14 18:37 UTC (permalink / raw)
To: Clément VUCHENER
Cc: Peter Hutterer, linux-input, Dmitry Torokhov, Jiri Kosina,
torvalds, Nestor Lopez Casado, lkml, Benjamin Tissoires
In-Reply-To: <CAM4jgCqAh9Pck-9i8F5tO4-Kzpu+SjH-mQnGYThadSf-3b1ikw@mail.gmail.com>
Hi Clement,
On Fri, 14 Dec 2018 at 05:47, Clément VUCHENER
<clement.vuchener@gmail.com> wrote:
> Hi, The G500s (and the G500 too, I think) does support the "scrolling
> acceleration" bit. If I set it, I get around 8 events for each wheel
> "click", this is what this driver expects, right? If I understood
> correctly, I should try this patch with the
> HIDPP_QUIRK_HI_RES_SCROLL_1P0 quirk set for my mouse.
Thanks for the info! Yes, that should work.
Harry Cutts
Chrome OS Touch/Input team
^ permalink raw reply
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