* Re: [PATCH 1/4] mod_devicetable: helper macro for declaring oftree module device table
From: Frank Rowand @ 2019-04-29 19:48 UTC (permalink / raw)
To: Enrico Weigelt, metux IT consult, Dmitry Torokhov,
Enrico Weigelt, metux IT consult
Cc: linux-kernel, linux-input
In-Reply-To: <fc747fb3-e670-79a2-f4bc-b989dee469fa@metux.net>
On 4/24/19 3:48 AM, Enrico Weigelt, metux IT consult wrote:
> On 19.04.19 09:40, Dmitry Torokhov wrote:
>> Hi Enrico,
>>
>> On Tue, Apr 16, 2019 at 09:57:22PM +0200, Enrico Weigelt, metux IT consult wrote:
>>> Little helper macro that declares an oftree module device table,
>>> if CONFIG_OF is enabled. Otherwise it's just noop.
>>>
>>> This is also helpful if some drivers can be built w/ or w/o
>>> oftree support.
>>
>> This should go to OF folks, please.
>
> hmm, they should be CCed, if my script works right.
> This one is only needed for the 4th patch (skip oftree...).
Your script did not work (BTDT). I just happened to notice this on lkml.
-Frank
>
>
> --mtx
>
^ permalink raw reply
* Re: [PATCH 4/4] input: keyboard: gpio-keys-polled: skip oftree code when CONFIG_OF disabled
From: Enrico Weigelt, metux IT consult @ 2019-04-29 21:40 UTC (permalink / raw)
To: Frank Rowand, Enrico Weigelt, metux IT consult, linux-kernel
Cc: dmitry.torokhov, linux-input
In-Reply-To: <2a760b29-9f0b-ffa7-03dd-47ddb074563a@gmail.com>
On 29.04.19 21:44, Frank Rowand wrote:
> On 4/16/19 12:57 PM, Enrico Weigelt, metux IT consult wrote:
>> we don't need to build in oftree probing stuff when oftree isn't
>> enabled at all.
>>
>> Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
>> ---
>> drivers/input/keyboard/gpio_keys_polled.c | 8 +++++++-
>> 1 file changed, 7 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/input/keyboard/gpio_keys_polled.c b/drivers/input/keyboard/gpio_keys_polled.c
>> index 3f773b2..fbccb89 100644
>> --- a/drivers/input/keyboard/gpio_keys_polled.c
>> +++ b/drivers/input/keyboard/gpio_keys_polled.c
>> @@ -147,6 +147,7 @@ static void gpio_keys_polled_close(struct input_polled_dev *dev)
>> static struct gpio_keys_platform_data *
>> gpio_keys_polled_get_devtree_pdata(struct device *dev)
>> {
>> +#ifdef CONFIG_OF
>> struct gpio_keys_platform_data *pdata;
>> struct gpio_keys_button *button;
>> struct fwnode_handle *child;
>> @@ -200,6 +201,9 @@ static void gpio_keys_polled_close(struct input_polled_dev *dev)
>> }
>>
>> return pdata;
>> +#else /* CONFIG_OF */
>> + return ERR_PTR(-ENOENT);
>> +#endif /* CONFIG_OF */
>> }
>>
>> static void gpio_keys_polled_set_abs_params(struct input_dev *input,
>> @@ -226,7 +230,7 @@ static void gpio_keys_polled_set_abs_params(struct input_dev *input,
>> { .compatible = "gpio-keys-polled", },
>> { },
>> };
>
>
>> -MODULE_DEVICE_TABLE(of, gpio_keys_polled_of_match);
>> +MODULE_DEVICE_TABLE_OF(gpio_keys_polled_of_match);
>
> Not needed, when you use of_match_ptr() -- see below.
Shall I remove the MODULE_DEVICE_TABLE... line completely ?
I'd like to have nothing of-related compiled in, when oftree isn't
enabled.
>> static struct gpio_desc *gpio_keys_polled_get_gpiod_fwnode(
>> struct device *dev,
>> @@ -452,7 +456,9 @@ static int gpio_keys_polled_probe(struct platform_device *pdev)
>> .probe = gpio_keys_polled_probe,
>> .driver = {
>> .name = DRV_NAME,
>
>> +#ifdef CONFIG_OF
>> .of_match_table = gpio_keys_polled_of_match,
>> +#endif /* CONFIG_OF */
>
> No need for the #ifdef, use of_match_ptr():
>
> .of_match_table = of_match_ptr(gpio_keys_polled_of_match),
Ok, thanks.
--mtx
--
Enrico Weigelt, metux IT consult
Free software and Linux embedded engineering
info@metux.net -- +49-151-27565287
^ permalink raw reply
* PROBLEM: Elan touchpad regression on Kernel 5.0.10
From: Outvi V @ 2019-04-30 4:20 UTC (permalink / raw)
To: dmitry.torokhov; +Cc: linux-input, linux-kernel
Hello,
[1.] One line summary of the problem: Elan touchpad regression on Kernel 5.0.10
[2.] Full description of the problem/report:
Elan touchpad does not work on 5.0.10 while working on 5.0.9
[3.] Keywords: elan_i2c_core elan i2c touchpad 5.0.10
[4.] Kernel information
[4.1.] Kernel version:
Linux version 5.0.10-arch1-1-ARCH (builduser@heftig-2592) (gcc version 8.3.0 (GCC)) #1 SMP PREEMPT Sat Apr 27 20:06:45 UTC 2019
[4.2.] Kernel .config file:
I'm not sure, but I think it may be referring to
https://git.archlinux.org/svntogit/packages.git/tree/trunk/config?h=packages/linux
[5.] Most recent kernel version which did not have the bug: 5.0.9
[6.] Output of Oops.. message (if applicable) with symbolic information
resolved (Not appliable)
[7.] A small shell script or example program which triggers the
problem: (Not appliable)
[8.] Environment
[8.1.] Software (add the output of the ver_linux script here)
Linux sheltty 5.0.10-arch1-1-ARCH #1 SMP PREEMPT Sat Apr 27 20:06:45 UTC 2019 x86_64 GNU/Linux
GNU C 8.3.0
GNU Make 4.2.1
Binutils 2.32
Util-linux 2.33.2
Mount 2.33.2
Module-init-tools 26
E2fsprogs 1.45.0
Jfsutils 1.1.15
Reiserfsprogs 3.6.27
Xfsprogs 4.20.0
PPP 2.4.7
Linux C Library 2.29
Dynamic linker (ldd) 2.29
Linux C++ Library 6.0.25
Procps 3.3.15
Kbd 2.0.4
Console-tools 2.0.4
Sh-utils 8.31
Udev 242
Modules Loaded 8021q 8250_dw ac ac97_bus acpi_thermal_rel aesni_intel aes_x86_64 agpgart ahci arc4 atkbd battery bbswitch bluetooth btbcm btintel btrtl btusb cfg80211 coretemp crc16 crc32c_generic crc32c_intel crc32_pclmul crct10dif_pclmul cryptd crypto_simd crypto_user drm drm_kms_helper ecdh_generic elan_i2c evdev ext4 fat fb_sys_fops fscrypto garp ghash_clmulni_intel glue_helper hid hid_generic i2c_algo_bit i2c_hid i2c_i801 i8042 i915 idma64 input_leds int3400_thermal int3403_thermal int340x_thermal_zone intel_cstate intel_gtt intel_lpss intel_lpss_pci intel_pch_thermal intel_powerclamp intel_rapl intel_rapl_perf intel_soc_dts_iosf intel_uncore intel_wmi_thunderbolt ip_tables irqbypass iTCO_vendor_support iTCO_wdt jbd2 joydev kvm kvmgt kvm_intel ledtrig_audio libahci libata libphy libps2 llc mac80211 mac_hid mbcache mdev media mei mei_me mousedev mrp nls_cp437 nls_iso8859_1 pcc_cpufreq processor_thermal_device r8169 r8822be realtek rfkill rng_core scsi_mod serio serio_raw snd snd_compress snd_hda_codec snd_hda_codec_generic snd_hda_codec_hdmi snd_hda_codec_realtek snd_hda_core snd_hda_ext_core snd_hda_intel snd_hwdep snd_pcm snd_pcm_dmaengine snd_soc_acpi snd_soc_acpi_intel_match snd_soc_core snd_soc_hdac_hda snd_soc_skl snd_soc_skl_ipc snd_soc_sst_dsp snd_soc_sst_ipc snd_timer soundcore stp syscopyarea sysfillrect sysimgblt tpm tpm_crb tpm_tis tpm_tis_core typec typec_ucsi ucsi_acpi usbhid uvcvideo vfat vfio vfio_iommu_type1 vfio_mdev videobuf2_common videobuf2_memops videobuf2_v4l2 videobuf2_vmalloc videodev wmi wmi_bmof x86_pkg_temp_thermal xhci_hcd xhci_pci x_tables
[8.2.] Processor information (from /proc/cpuinfo): (Maybe not appliable)
[8.3.] Module information (from /proc/modules):
(Parts related to i2c and elan:)
i2c_algo_bit 16384 1 i915, Live 0x0000000000000000
i2c_hid 32768 0 - Live 0x0000000000000000
hid 147456 3 hid_generic,usbhid,i2c_hid, Live 0x0000000000000000
elan_i2c 49152 0 - Live 0x0000000000000000
i2c_i801 36864 0 - Live 0x0000000000000000
[8.4.] Loaded driver and hardware information (/proc/ioports, /proc/iomem)
/proc/ioports:
0000-0000 : PCI Bus 0000:00
0000-0000 : dma1
0000-0000 : pic1
0000-0000 : iTCO_wdt
0000-0000 : timer0
0000-0000 : timer1
0000-0000 : keyboard
0000-0000 : PNP0C09:00
0000-0000 : EC data
0000-0000 : keyboard
0000-0000 : PNP0C09:00
0000-0000 : EC cmd
0000-0000 : rtc0
0000-0000 : dma page reg
0000-0000 : pic2
0000-0000 : dma2
0000-0000 : fpu
0000-0000 : PNP0C04:00
0000-0000 : iTCO_wdt
0000-0000 : pnp 00:02
0000-0000 : PCI conf1
0000-0000 : PCI Bus 0000:00
0000-0000 : pnp 00:02
0000-0000 : pnp 00:00
0000-0000 : ACPI PM1a_EVT_BLK
0000-0000 : ACPI PM1a_CNT_BLK
0000-0000 : ACPI PM_TMR
0000-0000 : ACPI CPU throttle
0000-0000 : ACPI PM2_CNT_BLK
0000-0000 : pnp 00:04
0000-0000 : ACPI GPE0_BLK
0000-0000 : pnp 00:01
0000-0000 : PCI Bus 0000:08
0000-0000 : 0000:08:00.0
0000-0000 : PCI Bus 0000:07
0000-0000 : 0000:07:00.0
0000-0000 : r8822be
0000-0000 : PCI Bus 0000:01
0000-0000 : 0000:01:00.0
0000-0000 : 0000:00:02.0
0000-0000 : 0000:00:1f.4
0000-0000 : i801_smbus
0000-0000 : 0000:00:17.0
0000-0000 : ahci
0000-0000 : 0000:00:17.0
0000-0000 : ahci
0000-0000 : 0000:00:17.0
0000-0000 : ahci
[8.5.] PCI information
It seems to be long (over 700 lines) and unrelated to this regression. Omitted to avoid flooding. I've kept an archive so feel free to ask me to post it if needed.
[8.6.] SCSI information (from /proc/scsi/scsi): (Empty)
[8.7.] Other information that might be relevant to the problem:
dmesg is constantly showing "elan_i2c i2c-ELAN061B:00: invalid report id data (d)".
I checked the git log and it is likely to be related to commit "95df599f95f398b0a34d081dadfdee3126e58163".
I'm using Arch Linux, its kernel repository link: [1]
I checked the related file "elan_i2c_core.c" in Arch Linux's kernel repository [2], and it is the same as in 5.0.10 on kernel.org.
My laptop is a Lenovo Legion Y7000.
Links:
[1]. https://git.archlinux.org/linux.git
[2]. https://git.archlinux.org/linux.git/tree/drivers/input/mouse/elan_i2c_core.c?h=v5.0.10-arch1
Please don't hesitate if more information or operation is needed.
^ permalink raw reply
* Re: [SOLVED] PROBLEM: Elan touchpad regression on Kernel 5.0.10
From: Outvi V @ 2019-04-30 6:16 UTC (permalink / raw)
To: dmitry.torokhov; +Cc: linux-input, linux-kernel
In-Reply-To: <0c87e12c-c964-40a3-b97e-af2286c318c4@www.fastmail.com>
Hello,
After a cold restart, this problems seem to be solved automatically on kernel 5.0.10.
Regards,
On Tue, Apr 30, 2019, at 12:21, Outvi V wrote:
> Hello,
>
> [1.] One line summary of the problem: Elan touchpad regression on Kernel 5.0.10
>
> [2.] Full description of the problem/report:
> Elan touchpad does not work on 5.0.10 while working on 5.0.9
>
> [3.] Keywords: elan_i2c_core elan i2c touchpad 5.0.10
>
> [4.] Kernel information
> [4.1.] Kernel version:
> Linux version 5.0.10-arch1-1-ARCH (builduser@heftig-2592) (gcc
> version 8.3.0 (GCC)) #1 SMP PREEMPT Sat Apr 27 20:06:45 UTC 2019
> [4.2.] Kernel .config file:
> I'm not sure, but I think it may be referring to
>
> https://git.archlinux.org/svntogit/packages.git/tree/trunk/config?h=packages/linux
> [5.] Most recent kernel version which did not have the bug: 5.0.9
>
> [6.] Output of Oops.. message (if applicable) with symbolic information
> resolved (Not appliable)
> [7.] A small shell script or example program which triggers the
> problem: (Not appliable)
>
> [8.] Environment
> [8.1.] Software (add the output of the ver_linux script here)
>
> Linux sheltty 5.0.10-arch1-1-ARCH #1 SMP PREEMPT Sat Apr 27 20:06:45
> UTC 2019 x86_64 GNU/Linux
>
> GNU C 8.3.0
> GNU Make 4.2.1
> Binutils 2.32
> Util-linux 2.33.2
> Mount 2.33.2
> Module-init-tools 26
> E2fsprogs 1.45.0
> Jfsutils 1.1.15
> Reiserfsprogs 3.6.27
> Xfsprogs 4.20.0
> PPP 2.4.7
> Linux C Library 2.29
> Dynamic linker (ldd) 2.29
> Linux C++ Library 6.0.25
> Procps 3.3.15
> Kbd 2.0.4
> Console-tools 2.0.4
> Sh-utils 8.31
> Udev 242
> Modules Loaded 8021q 8250_dw ac ac97_bus acpi_thermal_rel
> aesni_intel aes_x86_64 agpgart ahci arc4 atkbd battery bbswitch
> bluetooth btbcm btintel btrtl btusb cfg80211 coretemp crc16
> crc32c_generic crc32c_intel crc32_pclmul crct10dif_pclmul cryptd
> crypto_simd crypto_user drm drm_kms_helper ecdh_generic elan_i2c evdev
> ext4 fat fb_sys_fops fscrypto garp ghash_clmulni_intel glue_helper hid
> hid_generic i2c_algo_bit i2c_hid i2c_i801 i8042 i915 idma64 input_leds
> int3400_thermal int3403_thermal int340x_thermal_zone intel_cstate
> intel_gtt intel_lpss intel_lpss_pci intel_pch_thermal intel_powerclamp
> intel_rapl intel_rapl_perf intel_soc_dts_iosf intel_uncore
> intel_wmi_thunderbolt ip_tables irqbypass iTCO_vendor_support iTCO_wdt
> jbd2 joydev kvm kvmgt kvm_intel ledtrig_audio libahci libata libphy
> libps2 llc mac80211 mac_hid mbcache mdev media mei mei_me mousedev mrp
> nls_cp437 nls_iso8859_1 pcc_cpufreq processor_thermal_device r8169
> r8822be realtek rfkill rng_core scsi_mod serio serio_raw snd
> snd_compress snd_hda_codec snd_hda_codec_generic snd_hda_codec_hdmi
> snd_hda_codec_realtek snd_hda_core snd_hda_ext_core snd_hda_intel
> snd_hwdep snd_pcm snd_pcm_dmaengine snd_soc_acpi
> snd_soc_acpi_intel_match snd_soc_core snd_soc_hdac_hda snd_soc_skl
> snd_soc_skl_ipc snd_soc_sst_dsp snd_soc_sst_ipc snd_timer soundcore stp
> syscopyarea sysfillrect sysimgblt tpm tpm_crb tpm_tis tpm_tis_core
> typec typec_ucsi ucsi_acpi usbhid uvcvideo vfat vfio vfio_iommu_type1
> vfio_mdev videobuf2_common videobuf2_memops videobuf2_v4l2
> videobuf2_vmalloc videodev wmi wmi_bmof x86_pkg_temp_thermal xhci_hcd
> xhci_pci x_tables
>
> [8.2.] Processor information (from /proc/cpuinfo): (Maybe not appliable)
> [8.3.] Module information (from /proc/modules):
>
> (Parts related to i2c and elan:)
>
> i2c_algo_bit 16384 1 i915, Live 0x0000000000000000
> i2c_hid 32768 0 - Live 0x0000000000000000
> hid 147456 3 hid_generic,usbhid,i2c_hid, Live 0x0000000000000000
> elan_i2c 49152 0 - Live 0x0000000000000000
> i2c_i801 36864 0 - Live 0x0000000000000000
>
> [8.4.] Loaded driver and hardware information (/proc/ioports, /proc/iomem)
>
> /proc/ioports:
> 0000-0000 : PCI Bus 0000:00
> 0000-0000 : dma1
> 0000-0000 : pic1
> 0000-0000 : iTCO_wdt
> 0000-0000 : timer0
> 0000-0000 : timer1
> 0000-0000 : keyboard
> 0000-0000 : PNP0C09:00
> 0000-0000 : EC data
> 0000-0000 : keyboard
> 0000-0000 : PNP0C09:00
> 0000-0000 : EC cmd
> 0000-0000 : rtc0
> 0000-0000 : dma page reg
> 0000-0000 : pic2
> 0000-0000 : dma2
> 0000-0000 : fpu
> 0000-0000 : PNP0C04:00
> 0000-0000 : iTCO_wdt
> 0000-0000 : pnp 00:02
> 0000-0000 : PCI conf1
> 0000-0000 : PCI Bus 0000:00
> 0000-0000 : pnp 00:02
> 0000-0000 : pnp 00:00
> 0000-0000 : ACPI PM1a_EVT_BLK
> 0000-0000 : ACPI PM1a_CNT_BLK
> 0000-0000 : ACPI PM_TMR
> 0000-0000 : ACPI CPU throttle
> 0000-0000 : ACPI PM2_CNT_BLK
> 0000-0000 : pnp 00:04
> 0000-0000 : ACPI GPE0_BLK
> 0000-0000 : pnp 00:01
> 0000-0000 : PCI Bus 0000:08
> 0000-0000 : 0000:08:00.0
> 0000-0000 : PCI Bus 0000:07
> 0000-0000 : 0000:07:00.0
> 0000-0000 : r8822be
> 0000-0000 : PCI Bus 0000:01
> 0000-0000 : 0000:01:00.0
> 0000-0000 : 0000:00:02.0
> 0000-0000 : 0000:00:1f.4
> 0000-0000 : i801_smbus
> 0000-0000 : 0000:00:17.0
> 0000-0000 : ahci
> 0000-0000 : 0000:00:17.0
> 0000-0000 : ahci
> 0000-0000 : 0000:00:17.0
> 0000-0000 : ahci
>
>
> [8.5.] PCI information
> It seems to be long (over 700 lines) and unrelated to this
> regression. Omitted to avoid flooding. I've kept an archive so feel
> free to ask me to post it if needed.
>
> [8.6.] SCSI information (from /proc/scsi/scsi): (Empty)
> [8.7.] Other information that might be relevant to the problem:
>
> dmesg is constantly showing "elan_i2c i2c-ELAN061B:00: invalid report
> id data (d)".
> I checked the git log and it is likely to be related to commit
> "95df599f95f398b0a34d081dadfdee3126e58163".
> I'm using Arch Linux, its kernel repository link: [1]
> I checked the related file "elan_i2c_core.c" in Arch Linux's kernel
> repository [2], and it is the same as in 5.0.10 on kernel.org.
> My laptop is a Lenovo Legion Y7000.
>
> Links:
> [1]. https://git.archlinux.org/linux.git
> [2].
> https://git.archlinux.org/linux.git/tree/drivers/input/mouse/elan_i2c_core.c?h=v5.0.10-arch1
>
> Please don't hesitate if more information or operation is needed.
^ permalink raw reply
* Re: [PATCH v5 2/3] Input: add a driver for GPIO controllable vibrators
From: Dmitry Torokhov @ 2019-04-30 7:14 UTC (permalink / raw)
To: Luca Weiss
Cc: Rob Herring, Mark Rutland, Mauro Carvalho Chehab,
Pascal PAILLET-LME, Coly Li, Lee Jones, Xiaotong Lu, Brian Masney,
Rob Herring, Baolin Wang, David Brown,
open list:ARM/QUALCOMM SUPPORT,
open list:INPUT (KEYBOARD, MOUSE, JOYSTICK, TOUCHSCREEN)...,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
open list
In-Reply-To: <20190426194747.22256-2-luca@z3ntu.xyz>
On Fri, Apr 26, 2019 at 09:47:46PM +0200, Luca Weiss wrote:
> Provide a simple driver for GPIO controllable vibrators.
> It will be used by the Fairphone 2.
>
> Signed-off-by: Luca Weiss <luca@z3ntu.xyz>
Applied, thank you.
> ---
> drivers/input/misc/Kconfig | 12 ++
> drivers/input/misc/Makefile | 1 +
> drivers/input/misc/gpio-vibra.c | 209 ++++++++++++++++++++++++++++++++
> 3 files changed, 222 insertions(+)
> create mode 100644 drivers/input/misc/gpio-vibra.c
>
> diff --git a/drivers/input/misc/Kconfig b/drivers/input/misc/Kconfig
> index e15ed1bb8558..6dfe9e2fe5b1 100644
> --- a/drivers/input/misc/Kconfig
> +++ b/drivers/input/misc/Kconfig
> @@ -290,6 +290,18 @@ config INPUT_GPIO_DECODER
> To compile this driver as a module, choose M here: the module
> will be called gpio_decoder.
>
> +config INPUT_GPIO_VIBRA
> + tristate "GPIO vibrator support"
> + depends on GPIOLIB || COMPILE_TEST
> + select INPUT_FF_MEMLESS
> + help
> + Say Y here to get support for GPIO based vibrator devices.
> +
> + If unsure, say N.
> +
> + To compile this driver as a module, choose M here: the module will be
> + called gpio-vibra.
> +
> config INPUT_IXP4XX_BEEPER
> tristate "IXP4XX Beeper support"
> depends on ARCH_IXP4XX
> diff --git a/drivers/input/misc/Makefile b/drivers/input/misc/Makefile
> index b936c5b1d4ac..f38ebbdb05e2 100644
> --- a/drivers/input/misc/Makefile
> +++ b/drivers/input/misc/Makefile
> @@ -36,6 +36,7 @@ obj-$(CONFIG_INPUT_DRV2667_HAPTICS) += drv2667.o
> obj-$(CONFIG_INPUT_GP2A) += gp2ap002a00f.o
> obj-$(CONFIG_INPUT_GPIO_BEEPER) += gpio-beeper.o
> obj-$(CONFIG_INPUT_GPIO_DECODER) += gpio_decoder.o
> +obj-$(CONFIG_INPUT_GPIO_VIBRA) += gpio-vibra.o
> obj-$(CONFIG_INPUT_HISI_POWERKEY) += hisi_powerkey.o
> obj-$(CONFIG_HP_SDC_RTC) += hp_sdc_rtc.o
> obj-$(CONFIG_INPUT_IMS_PCU) += ims-pcu.o
> diff --git a/drivers/input/misc/gpio-vibra.c b/drivers/input/misc/gpio-vibra.c
> new file mode 100644
> index 000000000000..b76c81015de9
> --- /dev/null
> +++ b/drivers/input/misc/gpio-vibra.c
> @@ -0,0 +1,209 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +/*
> + * GPIO vibrator driver
> + *
> + * Copyright (C) 2019 Luca Weiss <luca@z3ntu.xyz>
> + *
> + * Based on PWM vibrator driver:
> + * Copyright (C) 2017 Collabora Ltd.
> + *
> + * Based on previous work from:
> + * Copyright (C) 2012 Dmitry Torokhov <dmitry.torokhov@gmail.com>
> + *
> + * Based on PWM beeper driver:
> + * Copyright (C) 2010, Lars-Peter Clausen <lars@metafoo.de>
> + */
> +
> +#include <linux/gpio/consumer.h>
> +#include <linux/input.h>
> +#include <linux/kernel.h>
> +#include <linux/module.h>
> +#include <linux/of_device.h>
> +#include <linux/platform_device.h>
> +#include <linux/property.h>
> +#include <linux/regulator/consumer.h>
> +#include <linux/slab.h>
> +
> +struct gpio_vibrator {
> + struct input_dev *input;
> + struct gpio_desc *gpio;
> + struct regulator *vcc;
> +
> + struct work_struct play_work;
> + bool running;
> + bool vcc_on;
> +};
> +
> +static int gpio_vibrator_start(struct gpio_vibrator *vibrator)
> +{
> + struct device *pdev = vibrator->input->dev.parent;
> + int err;
> +
> + if (!vibrator->vcc_on) {
> + err = regulator_enable(vibrator->vcc);
> + if (err) {
> + dev_err(pdev, "failed to enable regulator: %d\n", err);
> + return err;
> + }
> + vibrator->vcc_on = true;
> + }
> +
> + gpiod_set_value_cansleep(vibrator->gpio, 1);
> +
> + return 0;
> +}
> +
> +static void gpio_vibrator_stop(struct gpio_vibrator *vibrator)
> +{
> + gpiod_set_value_cansleep(vibrator->gpio, 0);
> +
> + if (vibrator->vcc_on) {
> + regulator_disable(vibrator->vcc);
> + vibrator->vcc_on = false;
> + }
> +}
> +
> +static void gpio_vibrator_play_work(struct work_struct *work)
> +{
> + struct gpio_vibrator *vibrator =
> + container_of(work, struct gpio_vibrator, play_work);
> +
> + if (vibrator->running)
> + gpio_vibrator_start(vibrator);
> + else
> + gpio_vibrator_stop(vibrator);
> +}
> +
> +static int gpio_vibrator_play_effect(struct input_dev *dev, void *data,
> + struct ff_effect *effect)
> +{
> + struct gpio_vibrator *vibrator = input_get_drvdata(dev);
> +
> + int level = effect->u.rumble.strong_magnitude;
> +
> + if (!level)
> + level = effect->u.rumble.weak_magnitude;
> +
> + if (level)
> + vibrator->running = true;
> + else
> + vibrator->running = false;
> +
> + schedule_work(&vibrator->play_work);
> +
> + return 0;
> +}
> +
> +static void gpio_vibrator_close(struct input_dev *input)
> +{
> + struct gpio_vibrator *vibrator = input_get_drvdata(input);
> +
> + cancel_work_sync(&vibrator->play_work);
> + gpio_vibrator_stop(vibrator);
> + vibrator->running = false;
> +}
> +
> +static int gpio_vibrator_probe(struct platform_device *pdev)
> +{
> + struct gpio_vibrator *vibrator;
> + int err;
> +
> + vibrator = devm_kzalloc(&pdev->dev, sizeof(*vibrator), GFP_KERNEL);
> + if (!vibrator)
> + return -ENOMEM;
> +
> + vibrator->input = devm_input_allocate_device(&pdev->dev);
> + if (!vibrator->input)
> + return -ENOMEM;
> +
> + vibrator->vcc = devm_regulator_get(&pdev->dev, "vcc");
> + err = PTR_ERR_OR_ZERO(vibrator->vcc);
> + if (err) {
> + if (err != -EPROBE_DEFER)
> + dev_err(&pdev->dev, "Failed to request regulator: %d\n",
> + err);
> + return err;
> + }
> +
> + vibrator->gpio = devm_gpiod_get(&pdev->dev, "enable", GPIOD_OUT_LOW);
> + err = PTR_ERR_OR_ZERO(vibrator->gpio);
> + if (err) {
> + if (err != -EPROBE_DEFER)
> + dev_err(&pdev->dev, "Failed to request main gpio: %d\n",
> + err);
> + return err;
> + }
> +
> + INIT_WORK(&vibrator->play_work, gpio_vibrator_play_work);
> +
> + vibrator->input->name = "gpio-vibrator";
> + vibrator->input->id.bustype = BUS_HOST;
> + vibrator->input->close = gpio_vibrator_close;
> +
> + input_set_drvdata(vibrator->input, vibrator);
> + input_set_capability(vibrator->input, EV_FF, FF_RUMBLE);
> +
> + err = input_ff_create_memless(vibrator->input, NULL,
> + gpio_vibrator_play_effect);
> + if (err) {
> + dev_err(&pdev->dev, "Couldn't create FF dev: %d\n", err);
> + return err;
> + }
> +
> + err = input_register_device(vibrator->input);
> + if (err) {
> + dev_err(&pdev->dev, "Couldn't register input dev: %d\n", err);
> + return err;
> + }
> +
> + platform_set_drvdata(pdev, vibrator);
> +
> + return 0;
> +}
> +
> +static int __maybe_unused gpio_vibrator_suspend(struct device *dev)
> +{
> + struct gpio_vibrator *vibrator = dev_get_drvdata(dev);
> +
> + cancel_work_sync(&vibrator->play_work);
> + if (vibrator->running)
> + gpio_vibrator_stop(vibrator);
> +
> + return 0;
> +}
> +
> +static int __maybe_unused gpio_vibrator_resume(struct device *dev)
> +{
> + struct gpio_vibrator *vibrator = dev_get_drvdata(dev);
> +
> + if (vibrator->running)
> + gpio_vibrator_start(vibrator);
> +
> + return 0;
> +}
> +
> +static SIMPLE_DEV_PM_OPS(gpio_vibrator_pm_ops,
> + gpio_vibrator_suspend, gpio_vibrator_resume);
> +
> +#ifdef CONFIG_OF
> +static const struct of_device_id gpio_vibra_dt_match_table[] = {
> + { .compatible = "gpio-vibrator" },
> + {}
> +};
> +MODULE_DEVICE_TABLE(of, gpio_vibra_dt_match_table);
> +#endif
> +
> +static struct platform_driver gpio_vibrator_driver = {
> + .probe = gpio_vibrator_probe,
> + .driver = {
> + .name = "gpio-vibrator",
> + .pm = &gpio_vibrator_pm_ops,
> + .of_match_table = of_match_ptr(gpio_vibra_dt_match_table),
> + },
> +};
> +module_platform_driver(gpio_vibrator_driver);
> +
> +MODULE_AUTHOR("Luca Weiss <luca@z3ntu.xy>");
> +MODULE_DESCRIPTION("GPIO vibrator driver");
> +MODULE_LICENSE("GPL");
> +MODULE_ALIAS("platform:gpio-vibrator");
> --
> 2.21.0
>
--
Dmitry
^ permalink raw reply
* Re: [PATCH v10 00/11] mfd: add support for max77650 PMIC
From: Bartosz Golaszewski @ 2019-04-30 9:11 UTC (permalink / raw)
To: Lee Jones
Cc: Linux Kernel Mailing List, open list:GPIO SUBSYSTEM, devicetree,
Linux Input, Linux LED Subsystem, Jacek Anaszewski,
Dmitry Torokhov, Linus Walleij, Linux PM list, Rob Herring,
Bartosz Golaszewski, Greg Kroah-Hartman, Liam Girdwood,
Sebastian Reichel, Pavel Machek, Mark Rutland
In-Reply-To: <20190423090451.23711-1-brgl@bgdev.pl>
wt., 23 kwi 2019 o 11:04 Bartosz Golaszewski <brgl@bgdev.pl> napisał(a):
>
> From: Bartosz Golaszewski <bgolaszewski@baylibre.com>
>
> This series adds support for max77650 ultra low-power PMIC. It provides
> the core mfd driver and a set of five sub-drivers for the regulator,
> power supply, gpio, leds and input subsystems.
>
> Patches 1-4 add the DT binding documents. Patch 5 documents mfd_add_devices().
> Patches 6-10 add all drivers. Last patch adds a MAINTAINERS entry for this
> device.
>
> The regulator part is already upstream.
>
> v1 -> v2:
> =========
>
> General:
> - use C++ style comments for the SPDX license identifier and the
> copyright header
> - s/MODULE_LICENSE("GPL")/MODULE_LICENSE("GPL v2")/
> - lookup the virtual interrupt numbers in the MFD driver, setup
> resources for child devices and use platform_get_irq_byname()
> in sub-drivers
> - picked up review tags
> - use devm_request_any_context_irq() for interrupt requests
>
> LEDs:
> - changed the max77650_leds_ prefix to max77650_led_
> - drop the max77650_leds structure as the only field it held was the
> regmap pointer, move said pointer to struct max77650_led
> - change the driver name to "max77650-led"
> - drop the last return value check and return the result of
> regmap_write() directly
> - change the labeling scheme to one consistent with other LED drivers
>
> ONKEY:
> - drop the key reporting helper and call the input functions directly
> from interrupt handlers
> - rename the rv local variable to error
> - drop parent device asignment
>
> Regulator:
> - drop the unnecessary init_data lookup from the driver code
> - drop unnecessary include
>
> Charger:
> - disable the charger on driver remove
> - change the power supply type to POWER_SUPPLY_TYPE_USB
>
> GPIO:
> - drop interrupt support until we have correct implementation of hierarchical
> irqs in gpiolib
>
> v2 -> v3:
> =========
>
> General:
> - dropped regulator patches as they're already in Mark Brown's branch
>
> LED:
> - fix the compatible string in the DT binding example
> - use the max_brightness property
> - use a common prefix ("MAX77650_LED") for all defines in the driver
>
> MFD:
> - add the MODULE_DEVICE_TABLE()
> - add a sentinel to the of_device_id array
> - constify the pointers to irq names
> - use an enum instead of defines for interrupt indexes
>
> v3 -> v4:
> =========
>
> GPIO:
> - as discussed with Linus Walleij: the gpio-controller is now part of
> the core mfd module (we don't spawn a sub-node anymore), the binding
> document for GPIO has been dropped, the GPIO properties have been
> defined in the binding document for the mfd core, the interrupt
> functionality has been reintroduced with the irq directly passed from
> the mfd part
> - due to the above changes the Reviewed-by tag from Linus was dropped
>
> v4 -> v5:
> =========
>
> General:
> - add a patch documenting mfd_add_devices()
>
> MFD:
> - pass the regmap irq_chip irq domain to mfd over mfd_add_devices so that
> the hw interrupts from resources can be correctly mapped to virtual irqs
> - remove the enum listing cell indexes
> - extend Kconfig help
> - add a link to the programming manual
> - use REGMAP_IRQ_REG() for regmap interrupts (except for GPI which has
> is composed of two hw interrupts for rising and falling edge)
> - add error messages in probe
> - use PLATFORM_DEVID_NONE constant in devm_mfd_add_devices()
> - set irq_base to 0 in regmap_add_irq_chip() as other users to, it's only
> relevant if it's > 0
>
> Charger:
> - use non-maxim specific property names for minimum input voltage and current
> limit
> - code shrink by using the enable/disable charger helpers everywhere
> - use more descriptive names for constants
>
> Onkey:
> - use EV_SW event type for slide mode
>
> LED:
> - remove stray " from Kconfig help
>
> v5 -> v6:
> =========
>
> MFD:
> - remove stray spaces in the binding document
> - rename the example dt node
> - remove unnecessary interrupt-parent property from the bindings
>
> LED:
> - add a missing dependency on LEDS_CLASS to Kconfig
>
> Onkey:
> - use boolean for the slide button property
>
> Charger:
> - fix the property names in DT example
> - make constants even more readable
>
> v6 -> v7:
> =========
>
> Charger:
> - rename the current limit property to current-limit-microamp
>
> v7 -> v8:
> =========
>
> General:
> - collected acks from Lee
> - changed the documentation for mfd_add_devices() as suggested by Lee
> - rebased on top of v5.1-rc3
>
> v8 > v9:
> ========
>
> General:
> - collected new tags
> - rebased on top of v5.1-rc4
>
> MFD:
> - various improvements in error messages
> - coding style tweaks
>
> Charger:
> - named the two optional properties in a more descriptive way, so that
> we can make them generic for charger bindings if more potential users
> appear
>
> v9 -> v10:
> ==========
>
> General:
> - added the review tag from Sebastian
> - rebased on top of v5.1-rc6
>
> Charger:
> - fixed the example in the binding document
>
> Bartosz Golaszewski (11):
> dt-bindings: mfd: add DT bindings for max77650
> dt-bindings: power: supply: add DT bindings for max77650
> dt-bindings: leds: add DT bindings for max77650
> dt-bindings: input: add DT bindings for max77650
> mfd: core: document mfd_add_devices()
> mfd: max77650: new core mfd driver
> power: supply: max77650: add support for battery charger
> gpio: max77650: add GPIO support
> leds: max77650: add LEDs support
> input: max77650: add onkey support
> MAINTAINERS: add an entry for max77650 mfd driver
>
> .../bindings/input/max77650-onkey.txt | 26 ++
> .../bindings/leds/leds-max77650.txt | 57 +++
> .../devicetree/bindings/mfd/max77650.txt | 46 +++
> .../power/supply/max77650-charger.txt | 28 ++
> MAINTAINERS | 14 +
> drivers/gpio/Kconfig | 7 +
> drivers/gpio/Makefile | 1 +
> drivers/gpio/gpio-max77650.c | 190 +++++++++
> drivers/input/misc/Kconfig | 9 +
> drivers/input/misc/Makefile | 1 +
> drivers/input/misc/max77650-onkey.c | 121 ++++++
> drivers/leds/Kconfig | 6 +
> drivers/leds/Makefile | 1 +
> drivers/leds/leds-max77650.c | 147 +++++++
> drivers/mfd/Kconfig | 14 +
> drivers/mfd/Makefile | 1 +
> drivers/mfd/max77650.c | 232 +++++++++++
> drivers/mfd/mfd-core.c | 13 +
> drivers/power/supply/Kconfig | 7 +
> drivers/power/supply/Makefile | 1 +
> drivers/power/supply/max77650-charger.c | 368 ++++++++++++++++++
> include/linux/mfd/max77650.h | 59 +++
> 22 files changed, 1349 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/input/max77650-onkey.txt
> create mode 100644 Documentation/devicetree/bindings/leds/leds-max77650.txt
> create mode 100644 Documentation/devicetree/bindings/mfd/max77650.txt
> create mode 100644 Documentation/devicetree/bindings/power/supply/max77650-charger.txt
> create mode 100644 drivers/gpio/gpio-max77650.c
> create mode 100644 drivers/input/misc/max77650-onkey.c
> create mode 100644 drivers/leds/leds-max77650.c
> create mode 100644 drivers/mfd/max77650.c
> create mode 100644 drivers/power/supply/max77650-charger.c
> create mode 100644 include/linux/mfd/max77650.h
>
> --
> 2.21.0
>
Hi Lee,
just a gentle ping before I leave on vacation.
All the relevant Acks are there. Any chance of getting this in for
v5.2? Obviously this cannot cause any regressions so it shouldn't be
too late in the release cycle.
Thanks in advance,
Bartosz Golaszewski
^ permalink raw reply
* Re: [PATCH][next] HID: logitech-dj: fix spelling mistake "Unexpect" -> "Unexpected"
From: Jiri Kosina @ 2019-04-30 13:32 UTC (permalink / raw)
To: Colin King; +Cc: Benjamin Tissoires, linux-input, kernel-janitors, linux-kernel
In-Reply-To: <20190426131631.26692-1-colin.king@canonical.com>
On Fri, 26 Apr 2019, Colin King wrote:
> From: Colin Ian King <colin.king@canonical.com>
>
> There is a spelling mistake in a hid_err error message, fix it.
>
> Signed-off-by: Colin Ian King <colin.king@canonical.com>
Applied to for-5.2/logitech. Thanks,
--
Jiri Kosina
SUSE Labs
^ permalink raw reply
* [PATCH] i2c: Prevent runtime suspend of adapter when Host Notify is required
From: Jarkko Nikula @ 2019-04-30 14:23 UTC (permalink / raw)
To: linux-i2c
Cc: Wolfram Sang, Keijo Vaara, linux-input, Bjorn Helgaas,
Rafael J . Wysocki, Jarkko Nikula, stable
Multiple users have reported their Synaptics touchpad has stopped
working between v4.20.1 and v4.20.2 when using SMBus interface.
The culprit for this appeared to be commit c5eb1190074c ("PCI / PM: Allow
runtime PM without callback functions") that fixed the runtime PM for
i2c-i801 SMBus adapter. Those Synaptics touchpad are using i2c-i801
for SMBus communication and testing showed they are able to get back
working by preventing the runtime suspend of adapter.
Normally when i2c-i801 SMBus adapter transmits with the client it resumes
before operation and autosuspends after.
However, if client requires SMBus Host Notify protocol, what those
Synaptics touchpads do, then the host adapter must not go to runtime
suspend since then it cannot process incoming SMBus Host Notify commands
the client may send.
Fix this by keeping I2C/SMBus adapter active in case client requires
Host Notify.
Reported-by: Keijo Vaara <ferdasyn@rocketmail.com>
Link: https://bugzilla.kernel.org/show_bug.cgi?id=203297
Fixes: c5eb1190074c ("PCI / PM: Allow runtime PM without callback functions")
Cc: stable@vger.kernel.org # v4.20+
Signed-off-by: Jarkko Nikula <jarkko.nikula@linux.intel.com>
---
Keijo: could you test this does it fix the issue you reported? This is
practically the same diff I sent earlier what you probably haven't tested yet.
I wanted to send a commitable fix in case it works since I'll be out of
office in a few coming days.
---
drivers/i2c/i2c-core-base.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/drivers/i2c/i2c-core-base.c b/drivers/i2c/i2c-core-base.c
index 38af18645133..8149c9e32b69 100644
--- a/drivers/i2c/i2c-core-base.c
+++ b/drivers/i2c/i2c-core-base.c
@@ -327,6 +327,8 @@ static int i2c_device_probe(struct device *dev)
if (client->flags & I2C_CLIENT_HOST_NOTIFY) {
dev_dbg(dev, "Using Host Notify IRQ\n");
+ /* Keep adapter active when Host Notify is required */
+ pm_runtime_get_sync(&client->adapter->dev);
irq = i2c_smbus_host_notify_to_irq(client);
} else if (dev->of_node) {
irq = of_irq_get_byname(dev->of_node, "irq");
@@ -431,6 +433,8 @@ static int i2c_device_remove(struct device *dev)
device_init_wakeup(&client->dev, false);
client->irq = client->init_irq;
+ if (client->flags & I2C_CLIENT_HOST_NOTIFY)
+ pm_runtime_put(&client->adapter->dev);
return status;
}
--
2.20.1
^ permalink raw reply related
* Re: [PATCH] i2c: Prevent runtime suspend of adapter when Host Notify is required
From: Rafael J. Wysocki @ 2019-04-30 15:42 UTC (permalink / raw)
To: Jarkko Nikula
Cc: linux-i2c, Wolfram Sang, Keijo Vaara, linux-input, Bjorn Helgaas,
Rafael J . Wysocki, Stable
In-Reply-To: <20190430142322.15013-1-jarkko.nikula@linux.intel.com>
On Tue, Apr 30, 2019 at 4:23 PM Jarkko Nikula
<jarkko.nikula@linux.intel.com> wrote:
>
> Multiple users have reported their Synaptics touchpad has stopped
> working between v4.20.1 and v4.20.2 when using SMBus interface.
>
> The culprit for this appeared to be commit c5eb1190074c ("PCI / PM: Allow
> runtime PM without callback functions") that fixed the runtime PM for
> i2c-i801 SMBus adapter. Those Synaptics touchpad are using i2c-i801
> for SMBus communication and testing showed they are able to get back
> working by preventing the runtime suspend of adapter.
>
> Normally when i2c-i801 SMBus adapter transmits with the client it resumes
> before operation and autosuspends after.
>
> However, if client requires SMBus Host Notify protocol, what those
> Synaptics touchpads do, then the host adapter must not go to runtime
> suspend since then it cannot process incoming SMBus Host Notify commands
> the client may send.
>
> Fix this by keeping I2C/SMBus adapter active in case client requires
> Host Notify.
>
> Reported-by: Keijo Vaara <ferdasyn@rocketmail.com>
> Link: https://bugzilla.kernel.org/show_bug.cgi?id=203297
> Fixes: c5eb1190074c ("PCI / PM: Allow runtime PM without callback functions")
> Cc: stable@vger.kernel.org # v4.20+
> Signed-off-by: Jarkko Nikula <jarkko.nikula@linux.intel.com>
Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Or please let me know if you want me to take this.
> ---
> Keijo: could you test this does it fix the issue you reported? This is
> practically the same diff I sent earlier what you probably haven't tested yet.
> I wanted to send a commitable fix in case it works since I'll be out of
> office in a few coming days.
> ---
> drivers/i2c/i2c-core-base.c | 4 ++++
> 1 file changed, 4 insertions(+)
>
> diff --git a/drivers/i2c/i2c-core-base.c b/drivers/i2c/i2c-core-base.c
> index 38af18645133..8149c9e32b69 100644
> --- a/drivers/i2c/i2c-core-base.c
> +++ b/drivers/i2c/i2c-core-base.c
> @@ -327,6 +327,8 @@ static int i2c_device_probe(struct device *dev)
>
> if (client->flags & I2C_CLIENT_HOST_NOTIFY) {
> dev_dbg(dev, "Using Host Notify IRQ\n");
> + /* Keep adapter active when Host Notify is required */
> + pm_runtime_get_sync(&client->adapter->dev);
> irq = i2c_smbus_host_notify_to_irq(client);
> } else if (dev->of_node) {
> irq = of_irq_get_byname(dev->of_node, "irq");
> @@ -431,6 +433,8 @@ static int i2c_device_remove(struct device *dev)
> device_init_wakeup(&client->dev, false);
>
> client->irq = client->init_irq;
> + if (client->flags & I2C_CLIENT_HOST_NOTIFY)
> + pm_runtime_put(&client->adapter->dev);
>
> return status;
> }
> --
> 2.20.1
>
^ permalink raw reply
* [PATCH 1/2] input: edt-ft5x06 - add polled input support
From: Nicolas Saenz Julienne @ 2019-04-30 18:58 UTC (permalink / raw)
To: linux-kernel; +Cc: Nicolas Saenz Julienne, Dmitry Torokhov, linux-input
Some hardware configurations might pass on providing an interrupt line.
In that case there is always the option to use a polled input approach.
This patch adapts the driver for it.
The polled approach is only triggered if no interrupt is provided by the
firmware or platform data.
Signed-off-by: Nicolas Saenz Julienne <nsaenzjulienne@suse.de>
---
drivers/input/touchscreen/edt-ft5x06.c | 100 ++++++++++++++++++-------
1 file changed, 72 insertions(+), 28 deletions(-)
diff --git a/drivers/input/touchscreen/edt-ft5x06.c b/drivers/input/touchscreen/edt-ft5x06.c
index 702bfda7ee77..e58645c72c2f 100644
--- a/drivers/input/touchscreen/edt-ft5x06.c
+++ b/drivers/input/touchscreen/edt-ft5x06.c
@@ -39,6 +39,7 @@
#include <linux/gpio/consumer.h>
#include <linux/input/mt.h>
#include <linux/input/touchscreen.h>
+#include <linux/input-polldev.h>
#include <linux/of_device.h>
#define WORK_REGISTER_THRESHOLD 0x00
@@ -97,6 +98,7 @@ struct edt_reg_addr {
struct edt_ft5x06_ts_data {
struct i2c_client *client;
struct input_dev *input;
+ struct input_polled_dev *poll_dev;
struct touchscreen_properties prop;
u16 num_x;
u16 num_y;
@@ -181,9 +183,8 @@ static bool edt_ft5x06_ts_check_crc(struct edt_ft5x06_ts_data *tsdata,
return true;
}
-static irqreturn_t edt_ft5x06_ts_isr(int irq, void *dev_id)
+static void edt_ft5x06_process(struct edt_ft5x06_ts_data *tsdata)
{
- struct edt_ft5x06_ts_data *tsdata = dev_id;
struct device *dev = &tsdata->client->dev;
u8 cmd;
u8 rdbuf[63];
@@ -210,7 +211,7 @@ static irqreturn_t edt_ft5x06_ts_isr(int irq, void *dev_id)
break;
default:
- goto out;
+ return;
}
memset(rdbuf, 0, sizeof(rdbuf));
@@ -222,7 +223,7 @@ static irqreturn_t edt_ft5x06_ts_isr(int irq, void *dev_id)
if (error) {
dev_err_ratelimited(dev, "Unable to fetch data, error: %d\n",
error);
- goto out;
+ return;
}
/* M09/M12 does not send header or CRC */
@@ -232,11 +233,11 @@ static irqreturn_t edt_ft5x06_ts_isr(int irq, void *dev_id)
dev_err_ratelimited(dev,
"Unexpected header: %02x%02x%02x!\n",
rdbuf[0], rdbuf[1], rdbuf[2]);
- goto out;
+ return;
}
if (!edt_ft5x06_ts_check_crc(tsdata, rdbuf, datalen))
- goto out;
+ return;
}
for (i = 0; i < tsdata->max_support_points; i++) {
@@ -273,11 +274,23 @@ static irqreturn_t edt_ft5x06_ts_isr(int irq, void *dev_id)
input_mt_report_pointer_emulation(tsdata->input, true);
input_sync(tsdata->input);
+}
-out:
+static irqreturn_t edt_ft5x06_ts_isr(int irq, void *dev_id)
+{
+ struct edt_ft5x06_ts_data *tsdata = dev_id;
+
+ edt_ft5x06_process(tsdata);
return IRQ_HANDLED;
}
+static void edt_ft5x06_poll(struct input_polled_dev *dev)
+{
+ struct edt_ft5x06_ts_data *tsdata = dev->private;
+
+ edt_ft5x06_process(tsdata);
+}
+
static int edt_ft5x06_register_write(struct edt_ft5x06_ts_data *tsdata,
u8 addr, u8 value)
{
@@ -1059,7 +1072,9 @@ static int edt_ft5x06_ts_probe(struct i2c_client *client,
const struct i2c_device_id *id)
{
const struct edt_i2c_chip_data *chip_data;
+ struct input_polled_dev *poll_dev = NULL;
struct edt_ft5x06_ts_data *tsdata;
+ bool polled = !(client->irq);
struct input_dev *input;
unsigned long irq_flags;
int error;
@@ -1112,15 +1127,38 @@ static int edt_ft5x06_ts_probe(struct i2c_client *client,
msleep(300);
}
- input = devm_input_allocate_device(&client->dev);
- if (!input) {
- dev_err(&client->dev, "failed to allocate input device.\n");
- return -ENOMEM;
+ if (polled) {
+ poll_dev = devm_input_allocate_polled_device(&client->dev);
+ if (!poll_dev) {
+ dev_err(&client->dev,
+ "failed to allocate polled input device.\n");
+ return -ENOMEM;
+ }
+
+ poll_dev->poll = edt_ft5x06_poll;
+ poll_dev->private = tsdata;
+
+ tsdata->poll_dev = poll_dev;
+ tsdata->input = poll_dev->input;
+
+ input = poll_dev->input;
+
+ device_property_read_u32(&client->dev, "poll-interval",
+ &poll_dev->poll_interval);
+
+ } else {
+ input = devm_input_allocate_device(&client->dev);
+ if (!input) {
+ dev_err(&client->dev,
+ "failed to allocate input device.\n");
+ return -ENOMEM;
+ }
+
+ tsdata->input = input;
}
mutex_init(&tsdata->mutex);
tsdata->client = client;
- tsdata->input = input;
tsdata->factory_mode = false;
error = edt_ft5x06_ts_identify(client, tsdata, fw_version);
@@ -1167,26 +1205,32 @@ static int edt_ft5x06_ts_probe(struct i2c_client *client,
i2c_set_clientdata(client, tsdata);
- irq_flags = irq_get_trigger_type(client->irq);
- if (irq_flags == IRQF_TRIGGER_NONE)
- irq_flags = IRQF_TRIGGER_FALLING;
- irq_flags |= IRQF_ONESHOT;
-
- error = devm_request_threaded_irq(&client->dev, client->irq,
- NULL, edt_ft5x06_ts_isr, irq_flags,
- client->name, tsdata);
- if (error) {
- dev_err(&client->dev, "Unable to request touchscreen IRQ.\n");
- return error;
- }
-
error = devm_device_add_group(&client->dev, &edt_ft5x06_attr_group);
if (error)
return error;
- error = input_register_device(input);
- if (error)
- return error;
+ if (polled) {
+ error = input_register_polled_device(poll_dev);
+ if (error)
+ return error;
+ } else {
+ irq_flags = irq_get_trigger_type(client->irq);
+ if (irq_flags == IRQF_TRIGGER_NONE)
+ irq_flags = IRQF_TRIGGER_FALLING;
+ irq_flags |= IRQF_ONESHOT;
+
+ error = devm_request_threaded_irq(&client->dev, client->irq,
+ NULL, edt_ft5x06_ts_isr, irq_flags,
+ client->name, tsdata);
+ if (error) {
+ dev_err(&client->dev, "Unable to request touchscreen IRQ.\n");
+ return error;
+ }
+
+ error = input_register_device(input);
+ if (error)
+ return error;
+ }
edt_ft5x06_ts_prepare_debugfs(tsdata, dev_driver_string(&client->dev));
device_init_wakeup(&client->dev, 1);
--
2.21.0
^ permalink raw reply related
* [PATCH 2/2] Input: edt-ft5x06 - add support for polled configuration
From: Nicolas Saenz Julienne @ 2019-04-30 18:58 UTC (permalink / raw)
To: linux-kernel
Cc: Nicolas Saenz Julienne, Dmitry Torokhov, Rob Herring,
Mark Rutland, linux-input, devicetree
In-Reply-To: <20190430185859.24015-1-nsaenzjulienne@suse.de>
Some devices might not provide an interrupt line for the touchscreen.
In that case the driver defaults to using a polled interface.
Signed-off-by: Nicolas Saenz Julienne <nsaenzjulienne@suse.de>
---
.../devicetree/bindings/input/touchscreen/edt-ft5x06.txt | 8 ++++++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/Documentation/devicetree/bindings/input/touchscreen/edt-ft5x06.txt b/Documentation/devicetree/bindings/input/touchscreen/edt-ft5x06.txt
index 870b8c5cce9b..2605994a1257 100644
--- a/Documentation/devicetree/bindings/input/touchscreen/edt-ft5x06.txt
+++ b/Documentation/devicetree/bindings/input/touchscreen/edt-ft5x06.txt
@@ -24,10 +24,14 @@ Required properties:
or: "focaltech,ft6236"
- reg: I2C slave address of the chip (0x38)
- - interrupts: interrupt specification for the touchdetect
- interrupt
Optional properties:
+- interrupts: interrupt specification for the touchdetect interrupt, if not
+ supplied the driver will deafult to polling.
+
+- poll-interval: Poll interval time in milliseconds, only relevant if no
+ interrupt was provided.
+
- reset-gpios: GPIO specification for the RESET input
- wake-gpios: GPIO specification for the WAKE input
--
2.21.0
^ permalink raw reply related
* Re: [PATCH v2] Input: uinput: Avoid Object-Already-Free with a global lock
From: Mukesh Ojha @ 2019-05-01 7:50 UTC (permalink / raw)
To: Al Viro
Cc: dmitry.torokhov@gmail.com, linux-input, linux-kernel,
Gaurav Kohli, Peter Hutterer, Martin Kepplinger, Paul E. McKenney
In-Reply-To: <20190424225641.GQ2217@ZenIV.linux.org.uk>
Sorry to come late on this
On 4/25/2019 4:26 AM, Al Viro wrote:
> On Wed, Apr 24, 2019 at 07:39:03PM +0530, Mukesh Ojha wrote:
>
>> This was my simple program no multithreading just to understand f_counting
>>
>> int main()
>> {
>> int fd = open("/dev/uinput", O_WRONLY | O_NONBLOCK);
>> ioctl(fd, UI_SET_EVBIT, EV_KEY);
>> close(fd);
>> return 0;
>> }
>>
>> uinput-532 [002] .... 45.312044: SYSC_ioctl: 2 <= f_count
> Er... So how does it manage to hit ioctl(2) before open(2)? Confused...
I was confused too about this earlier, but after printing fd got to know
this is not for the same fd
opening for /dev/uinput, may it is for something while running the
executable.
>
>>> <After fdget()
>> uinput-532 [002] .... 45.312055: SYSC_ioctl: 2
>> <After fdput()
>> uinput-532 [004] .... 45.313766: uinput_open: uinput: 1 /*
>> This is from the uinput driver uinput_open()*/
>>
>> =>>>> /* All the above calls happened for the
>> open() in userspace*/
>>
>> uinput-532 [004] .... 45.313783: SYSC_ioctl: 1 /* This print
>> is for the trace, i put after fdget */
>> uinput-532 [004] .... 45.313788: uinput_ioctl_handler:
>> uinput: uinput_ioctl_handler, 1 /* This print is from the uinput_ioctl
>> driver */
>>
>> uinput-532 [004] .... 45.313835: SYSC_ioctl: 1 /* This print
>> is for the trace, i put after fdput*/
>> uinput-532 [004] .... 45.313843: uinput_release: uinput: 0
>> /* And this is from the close() */
>>
>>
>> Should fdget not suppose to increment the f_count here, as it is coming 1 ?
>> This f_count to one is done at the open, but i have no idea how this below
>> f_count 2 came before open() for
>> this simple program.
> If descriptor table is not shared, fdget() will simply return you the reference
> from there, without bothering to bump the refcount. _And_ having it marked
> "don't drop refcount" in struct fd.
>
> Rationale: since it's not shared, nobody other than our process can modify
> it. So unless we remove (and drop) the reference from it ourselves (which
> we certainly have no business doing in ->ioctl() and do not do anywhere
> in drivers/input), it will remain there until we return from syscall.
>
> Nobody is allowed to modify descriptor table other than their own.
> And if it's not shared, no other owners can appear while the only
> existing one is in the middle of syscall other than clone() (with
> CLONE_FILES in flags, at that).
>
> For shared descriptor table fdget() bumps file refcount, since there
> the reference in descriptor table itself could be removed and dropped
> by another thread.
>
> And fdget() marks whether fput() is needed in fd.flags, so that
> fdput() does the right thing.
Thanks Al, it is quite clear that issue can't happen while a ioctl is in
progress.
Actually the issue seems to be a race while glue_dir input is removed.
114.339374] input: syz1 as /devices/virtual/input/input278
[ 114.345619] input: syz1 as /devices/virtual/input/input279
[ 114.353502] input: syz1 as /devices/virtual/input/input280
[ 114.361907] input: syz1 as /devices/virtual/input/input281
[ 114.367276] input: syz1 as /devices/virtual/input/input282
[ 114.382292] input: syz1 as /devices/virtual/input/input283
in our case it is input which is getting removed while a inputxx is
trying make node inside input.
Similar issue https://lkml.org/lkml/2019/5/1/3
Thanks,
Mukesh
^ permalink raw reply
* [REOPENED] PROBLEM: Elan touchpad regression on Kernel 5.0.10
From: Outvi V @ 2019-05-01 13:57 UTC (permalink / raw)
To: dmitry.torokhov; +Cc: linux-input, linux-kernel
In-Reply-To: <9db8c26a-d9fd-4cc9-a3aa-bd593d8f73ac@www.fastmail.com>
Hello,
Sorry for disturbing. But later I find it is not actually solved. It seems to be a regression that randomly happens. Sometimes the touchpad works after starting without any bad logs, while somethime the touchpad is completely unusable.
I have filed a bug on Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=203467
If any detail is needed, please don't hesitate to contact me.
Regards,
On Tue, Apr 30, 2019, at 14:16, Outvi V wrote:
> Hello,
>
> After a cold restart, this problems seem to be solved automatically
> on kernel 5.0.10.
>
> Regards,
>
> On Tue, Apr 30, 2019, at 12:21, Outvi V wrote:
> > Hello,
> >
> > [1.] One line summary of the problem: Elan touchpad regression on Kernel 5.0.10
> >
> > [2.] Full description of the problem/report:
> > Elan touchpad does not work on 5.0.10 while working on 5.0.9
> >
> > [3.] Keywords: elan_i2c_core elan i2c touchpad 5.0.10
> >
> > [4.] Kernel information
> > [4.1.] Kernel version:
> > Linux version 5.0.10-arch1-1-ARCH (builduser@heftig-2592) (gcc
> > version 8.3.0 (GCC)) #1 SMP PREEMPT Sat Apr 27 20:06:45 UTC 2019
> > [4.2.] Kernel .config file:
> > I'm not sure, but I think it may be referring to
> >
> > https://git.archlinux.org/svntogit/packages.git/tree/trunk/config?h=packages/linux
> > [5.] Most recent kernel version which did not have the bug: 5.0.9
> >
> > [6.] Output of Oops.. message (if applicable) with symbolic information
> > resolved (Not appliable)
> > [7.] A small shell script or example program which triggers the
> > problem: (Not appliable)
> >
> > [8.] Environment
> > [8.1.] Software (add the output of the ver_linux script here)
> >
> > Linux sheltty 5.0.10-arch1-1-ARCH #1 SMP PREEMPT Sat Apr 27 20:06:45
> > UTC 2019 x86_64 GNU/Linux
> >
> > GNU C 8.3.0
> > GNU Make 4.2.1
> > Binutils 2.32
> > Util-linux 2.33.2
> > Mount 2.33.2
> > Module-init-tools 26
> > E2fsprogs 1.45.0
> > Jfsutils 1.1.15
> > Reiserfsprogs 3.6.27
> > Xfsprogs 4.20.0
> > PPP 2.4.7
> > Linux C Library 2.29
> > Dynamic linker (ldd) 2.29
> > Linux C++ Library 6.0.25
> > Procps 3.3.15
> > Kbd 2.0.4
> > Console-tools 2.0.4
> > Sh-utils 8.31
> > Udev 242
> > Modules Loaded 8021q 8250_dw ac ac97_bus acpi_thermal_rel
> > aesni_intel aes_x86_64 agpgart ahci arc4 atkbd battery bbswitch
> > bluetooth btbcm btintel btrtl btusb cfg80211 coretemp crc16
> > crc32c_generic crc32c_intel crc32_pclmul crct10dif_pclmul cryptd
> > crypto_simd crypto_user drm drm_kms_helper ecdh_generic elan_i2c evdev
> > ext4 fat fb_sys_fops fscrypto garp ghash_clmulni_intel glue_helper hid
> > hid_generic i2c_algo_bit i2c_hid i2c_i801 i8042 i915 idma64 input_leds
> > int3400_thermal int3403_thermal int340x_thermal_zone intel_cstate
> > intel_gtt intel_lpss intel_lpss_pci intel_pch_thermal intel_powerclamp
> > intel_rapl intel_rapl_perf intel_soc_dts_iosf intel_uncore
> > intel_wmi_thunderbolt ip_tables irqbypass iTCO_vendor_support iTCO_wdt
> > jbd2 joydev kvm kvmgt kvm_intel ledtrig_audio libahci libata libphy
> > libps2 llc mac80211 mac_hid mbcache mdev media mei mei_me mousedev mrp
> > nls_cp437 nls_iso8859_1 pcc_cpufreq processor_thermal_device r8169
> > r8822be realtek rfkill rng_core scsi_mod serio serio_raw snd
> > snd_compress snd_hda_codec snd_hda_codec_generic snd_hda_codec_hdmi
> > snd_hda_codec_realtek snd_hda_core snd_hda_ext_core snd_hda_intel
> > snd_hwdep snd_pcm snd_pcm_dmaengine snd_soc_acpi
> > snd_soc_acpi_intel_match snd_soc_core snd_soc_hdac_hda snd_soc_skl
> > snd_soc_skl_ipc snd_soc_sst_dsp snd_soc_sst_ipc snd_timer soundcore stp
> > syscopyarea sysfillrect sysimgblt tpm tpm_crb tpm_tis tpm_tis_core
> > typec typec_ucsi ucsi_acpi usbhid uvcvideo vfat vfio vfio_iommu_type1
> > vfio_mdev videobuf2_common videobuf2_memops videobuf2_v4l2
> > videobuf2_vmalloc videodev wmi wmi_bmof x86_pkg_temp_thermal xhci_hcd
> > xhci_pci x_tables
> >
> > [8.2.] Processor information (from /proc/cpuinfo): (Maybe not appliable)
> > [8.3.] Module information (from /proc/modules):
> >
> > (Parts related to i2c and elan:)
> >
> > i2c_algo_bit 16384 1 i915, Live 0x0000000000000000
> > i2c_hid 32768 0 - Live 0x0000000000000000
> > hid 147456 3 hid_generic,usbhid,i2c_hid, Live 0x0000000000000000
> > elan_i2c 49152 0 - Live 0x0000000000000000
> > i2c_i801 36864 0 - Live 0x0000000000000000
> >
> > [8.4.] Loaded driver and hardware information (/proc/ioports, /proc/iomem)
> >
> > /proc/ioports:
> > 0000-0000 : PCI Bus 0000:00
> > 0000-0000 : dma1
> > 0000-0000 : pic1
> > 0000-0000 : iTCO_wdt
> > 0000-0000 : timer0
> > 0000-0000 : timer1
> > 0000-0000 : keyboard
> > 0000-0000 : PNP0C09:00
> > 0000-0000 : EC data
> > 0000-0000 : keyboard
> > 0000-0000 : PNP0C09:00
> > 0000-0000 : EC cmd
> > 0000-0000 : rtc0
> > 0000-0000 : dma page reg
> > 0000-0000 : pic2
> > 0000-0000 : dma2
> > 0000-0000 : fpu
> > 0000-0000 : PNP0C04:00
> > 0000-0000 : iTCO_wdt
> > 0000-0000 : pnp 00:02
> > 0000-0000 : PCI conf1
> > 0000-0000 : PCI Bus 0000:00
> > 0000-0000 : pnp 00:02
> > 0000-0000 : pnp 00:00
> > 0000-0000 : ACPI PM1a_EVT_BLK
> > 0000-0000 : ACPI PM1a_CNT_BLK
> > 0000-0000 : ACPI PM_TMR
> > 0000-0000 : ACPI CPU throttle
> > 0000-0000 : ACPI PM2_CNT_BLK
> > 0000-0000 : pnp 00:04
> > 0000-0000 : ACPI GPE0_BLK
> > 0000-0000 : pnp 00:01
> > 0000-0000 : PCI Bus 0000:08
> > 0000-0000 : 0000:08:00.0
> > 0000-0000 : PCI Bus 0000:07
> > 0000-0000 : 0000:07:00.0
> > 0000-0000 : r8822be
> > 0000-0000 : PCI Bus 0000:01
> > 0000-0000 : 0000:01:00.0
> > 0000-0000 : 0000:00:02.0
> > 0000-0000 : 0000:00:1f.4
> > 0000-0000 : i801_smbus
> > 0000-0000 : 0000:00:17.0
> > 0000-0000 : ahci
> > 0000-0000 : 0000:00:17.0
> > 0000-0000 : ahci
> > 0000-0000 : 0000:00:17.0
> > 0000-0000 : ahci
> >
> >
> > [8.5.] PCI information
> > It seems to be long (over 700 lines) and unrelated to this
> > regression. Omitted to avoid flooding. I've kept an archive so feel
> > free to ask me to post it if needed.
> >
> > [8.6.] SCSI information (from /proc/scsi/scsi): (Empty)
> > [8.7.] Other information that might be relevant to the problem:
> >
> > dmesg is constantly showing "elan_i2c i2c-ELAN061B:00: invalid report
> > id data (d)".
> > I checked the git log and it is likely to be related to commit
> > "95df599f95f398b0a34d081dadfdee3126e58163".
> > I'm using Arch Linux, its kernel repository link: [1]
> > I checked the related file "elan_i2c_core.c" in Arch Linux's kernel
> > repository [2], and it is the same as in 5.0.10 on kernel.org.
> > My laptop is a Lenovo Legion Y7000.
> >
> > Links:
> > [1]. https://git.archlinux.org/linux.git
> > [2].
> > https://git.archlinux.org/linux.git/tree/drivers/input/mouse/elan_i2c_core.c?h=v5.0.10-arch1
> >
> > Please don't hesitate if more information or operation is needed.
^ permalink raw reply
* Re: [RFC PATCH 1/4] dt-bindings: input: Add support for the MPR121 without interrupt line
From: Rob Herring @ 2019-05-02 0:48 UTC (permalink / raw)
To: Michal Vokáč
Cc: Dmitry Torokhov, Mark Rutland, Shawn Guo, Sascha Hauer,
Fabio Estevam, linux-input, devicetree, linux-kernel,
Pengutronix Kernel Team
In-Reply-To: <1556267420-93219-2-git-send-email-michal.vokac@ysoft.com>
On Fri, Apr 26, 2019 at 10:30:17AM +0200, Michal Vokáč wrote:
> Normally, the MPR121 controller uses separate interrupt line to notify
> the I2C host that a key was touched/released. To support platforms that
> can not use the interrupt line, polling of the MPR121 registers can be
> used.
Other than making the 'interrupts' property optional, that's a driver
change, not a DT change. IOW, we shouldn't need a whole new binding.
>
> Signed-off-by: Michal Vokáč <michal.vokac@ysoft.com>
> ---
> .../bindings/input/mpr121-touchkey-polled.txt | 26 ++++++++++++++++++++++
> 1 file changed, 26 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/input/mpr121-touchkey-polled.txt
>
> diff --git a/Documentation/devicetree/bindings/input/mpr121-touchkey-polled.txt b/Documentation/devicetree/bindings/input/mpr121-touchkey-polled.txt
> new file mode 100644
> index 000000000000..6bb1d312614c
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/input/mpr121-touchkey-polled.txt
> @@ -0,0 +1,26 @@
> +* Freescale MPR121 Controller without interrupt line
> +
> +Required Properties:
> +- compatible: Should be "fsl,mpr121-touchkey-polled"
> +- reg: The I2C slave address of the device.
> +- vdd-supply: Phandle to the Vdd power supply.
> +- linux,keycodes: Specifies an array of numeric keycode values to
> + be used for reporting button presses. The array can
> + contain up to 12 entries.
> +
> +Optional Properties:
> +- autorepeat: Enable autorepeat feature.
> +
> +Example:
> +
> +#include "dt-bindings/input/input.h"
> +
> + touchkeys: keys@5a {
> + compatible = "fsl,mpr121-touchkey-polled";
> + reg = <0x5a>;
> + autorepeat;
> + vdd-supply = <&ldo4_reg>;
> + linux,keycodes = <KEY_0>, <KEY_1>, <KEY_2>, <KEY_3>,
> + <KEY_4> <KEY_5>, <KEY_6>, <KEY_7>,
> + <KEY_8>, <KEY_9>, <KEY_A>, <KEY_B>;
> + };
> --
> 2.1.4
>
^ permalink raw reply
* Re: [PATCH] i2c: Prevent runtime suspend of adapter when Host Notify is required
From: Keijo Vaara @ 2019-05-02 8:07 UTC (permalink / raw)
To: linux-i2c, Jarkko Nikula
Cc: Wolfram Sang, linux-input, Bjorn Helgaas, Rafael J . Wysocki,
stable
In-Reply-To: <20190430142322.15013-1-jarkko.nikula@linux.intel.com>
On Tue, Apr 30, 2019 at 4:23 PM Jarkko Nikula
<jarkko.nikula@linux.intel.com> wrote:
>
> ---
> Keijo: could you test this does it fix the issue you reported? This is
> practically the same diff I sent earlier what you probably haven't tested yet.
> I wanted to send a commitable fix in case it works since I'll be out of
> office in a few coming days.
> ---
> drivers/i2c/i2c-core-base.c | 4 ++++
> 1 file changed, 4 insertions(+)
>
> diff --git a/drivers/i2c/i2c-core-base.c b/drivers/i2c/i2c-core-base.c
> index 38af18645133..8149c9e32b69 100644
> --- a/drivers/i2c/i2c-core-base.c
> +++ b/drivers/i2c/i2c-core-base.c
> @@ -327,6 +327,8 @@ static int i2c_device_probe(struct device *dev)
>
> if (client->flags & I2C_CLIENT_HOST_NOTIFY) {
> dev_dbg(dev, "Using Host Notify IRQ\n");
> + /* Keep adapter active when Host Notify is required */
> + pm_runtime_get_sync(&client->adapter->dev);
> irq = i2c_smbus_host_notify_to_irq(client);
> } else if (dev->of_node) {
> irq = of_irq_get_byname(dev->of_node, "irq");
> @@ -431,6 +433,8 @@ static int i2c_device_remove(struct device *dev)
> device_init_wakeup(&client->dev, false);
>
> client->irq = client->init_irq;
> + if (client->flags & I2C_CLIENT_HOST_NOTIFY)
> + pm_runtime_put(&client->adapter->dev);
>
> return status;
> }
> --
> 2.20.1
>
Thanks guys, I've tested the patch and can confirm it fixes the issue.
^ permalink raw reply
* Re: [PATCH] i2c: Prevent runtime suspend of adapter when Host Notify is required
From: Wolfram Sang @ 2019-05-02 16:43 UTC (permalink / raw)
To: Jarkko Nikula
Cc: linux-i2c, Keijo Vaara, linux-input, Bjorn Helgaas,
Rafael J . Wysocki, stable
In-Reply-To: <20190430142322.15013-1-jarkko.nikula@linux.intel.com>
[-- Attachment #1: Type: text/plain, Size: 1362 bytes --]
On Tue, Apr 30, 2019 at 05:23:22PM +0300, Jarkko Nikula wrote:
> Multiple users have reported their Synaptics touchpad has stopped
> working between v4.20.1 and v4.20.2 when using SMBus interface.
>
> The culprit for this appeared to be commit c5eb1190074c ("PCI / PM: Allow
> runtime PM without callback functions") that fixed the runtime PM for
> i2c-i801 SMBus adapter. Those Synaptics touchpad are using i2c-i801
> for SMBus communication and testing showed they are able to get back
> working by preventing the runtime suspend of adapter.
>
> Normally when i2c-i801 SMBus adapter transmits with the client it resumes
> before operation and autosuspends after.
>
> However, if client requires SMBus Host Notify protocol, what those
> Synaptics touchpads do, then the host adapter must not go to runtime
> suspend since then it cannot process incoming SMBus Host Notify commands
> the client may send.
>
> Fix this by keeping I2C/SMBus adapter active in case client requires
> Host Notify.
>
> Reported-by: Keijo Vaara <ferdasyn@rocketmail.com>
> Link: https://bugzilla.kernel.org/show_bug.cgi?id=203297
> Fixes: c5eb1190074c ("PCI / PM: Allow runtime PM without callback functions")
> Cc: stable@vger.kernel.org # v4.20+
> Signed-off-by: Jarkko Nikula <jarkko.nikula@linux.intel.com>
Applied to for-current-fixed, thanks!
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: [PATCH 2/2] Input: edt-ft5x06 - add support for polled configuration
From: Rob Herring @ 2019-05-02 21:32 UTC (permalink / raw)
Cc: linux-kernel, Nicolas Saenz Julienne, Dmitry Torokhov,
Mark Rutland, linux-input, devicetree
In-Reply-To: <20190430185859.24015-2-nsaenzjulienne@suse.de>
On Tue, 30 Apr 2019 20:58:59 +0200, Nicolas Saenz Julienne wrote:
> Some devices might not provide an interrupt line for the touchscreen.
> In that case the driver defaults to using a polled interface.
>
> Signed-off-by: Nicolas Saenz Julienne <nsaenzjulienne@suse.de>
> ---
> .../devicetree/bindings/input/touchscreen/edt-ft5x06.txt | 8 ++++++--
> 1 file changed, 6 insertions(+), 2 deletions(-)
>
Reviewed-by: Rob Herring <robh@kernel.org>
^ permalink raw reply
* [PATCH] HID: fix A4Tech horizontal scrolling
From: Błażej Szczygieł @ 2019-05-02 21:36 UTC (permalink / raw)
Cc: igorkuo, Błażej Szczygieł, Jiri Kosina,
Benjamin Tissoires, linux-input, linux-kernel
Since recent high resolution scrolling changes the A4Tech driver must
check for the "REL_WHEEL_HI_RES" usage code.
Fixes: 2dc702c991e3774af9d7ce410eef410ca9e2357e (HID: input: use the
Resolution Multiplier for high-resolution scrolling)
Signed-off-by: Błażej Szczygieł <spaz16@wp.pl>
---
drivers/hid/hid-a4tech.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/hid/hid-a4tech.c b/drivers/hid/hid-a4tech.c
index 9428ea7cdf8a..fafb9fa558e7 100644
--- a/drivers/hid/hid-a4tech.c
+++ b/drivers/hid/hid-a4tech.c
@@ -38,7 +38,7 @@ static int a4_input_mapped(struct hid_device *hdev, struct hid_input *hi,
{
struct a4tech_sc *a4 = hid_get_drvdata(hdev);
- if (usage->type == EV_REL && usage->code == REL_WHEEL)
+ if (usage->type == EV_REL && usage->code == REL_WHEEL_HI_RES)
set_bit(REL_HWHEEL, *bit);
if ((a4->quirks & A4_2WHEEL_MOUSE_HACK_7) && usage->hid == 0x00090007)
@@ -60,7 +60,7 @@ static int a4_event(struct hid_device *hdev, struct hid_field *field,
input = field->hidinput->input;
if (a4->quirks & A4_2WHEEL_MOUSE_HACK_B8) {
- if (usage->type == EV_REL && usage->code == REL_WHEEL) {
+ if (usage->type == EV_REL && usage->code == REL_WHEEL_HI_RES) {
a4->delayed_value = value;
return 1;
}
@@ -77,7 +77,7 @@ static int a4_event(struct hid_device *hdev, struct hid_field *field,
return 1;
}
- if (usage->code == REL_WHEEL && a4->hw_wheel) {
+ if (usage->code == REL_WHEEL_HI_RES && a4->hw_wheel) {
input_event(input, usage->type, REL_HWHEEL, value);
return 1;
}
--
2.21.0
^ permalink raw reply related
* Re: [PATCH] HID: fix A4Tech horizontal scrolling
From: Benjamin Tissoires @ 2019-05-03 7:36 UTC (permalink / raw)
To: Błażej Szczygieł
Cc: igorkuo, Jiri Kosina, open list:HID CORE LAYER, lkml
In-Reply-To: <20190502213639.7632-1-spaz16@wp.pl>
Hi,
On Thu, May 2, 2019 at 11:37 PM Błażej Szczygieł <spaz16@wp.pl> wrote:
>
> Since recent high resolution scrolling changes the A4Tech driver must
> check for the "REL_WHEEL_HI_RES" usage code.
>
> Fixes: 2dc702c991e3774af9d7ce410eef410ca9e2357e (HID: input: use the
> Resolution Multiplier for high-resolution scrolling)
>
> Signed-off-by: Błażej Szczygieł <spaz16@wp.pl>
Thanks for the patch. I do not doubt this fixes the issues, but I
still wonder if we should not export REL_HWHEEL_HI_RES instead of
REL_HWHEEL events.
Also, I can not figure out how the events are processed by the kernel.
Could you attach a hid-recorder dump of the mouse wheels with
hid-recorder from https://gitlab.freedesktop.org/libevdev/hid-tools ?
This should give me a better view of the mouse, and I could also add
it to the regression tests I am running for each commit.
Cheers,
Benjamin
> ---
> drivers/hid/hid-a4tech.c | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/hid/hid-a4tech.c b/drivers/hid/hid-a4tech.c
> index 9428ea7cdf8a..fafb9fa558e7 100644
> --- a/drivers/hid/hid-a4tech.c
> +++ b/drivers/hid/hid-a4tech.c
> @@ -38,7 +38,7 @@ static int a4_input_mapped(struct hid_device *hdev, struct hid_input *hi,
> {
> struct a4tech_sc *a4 = hid_get_drvdata(hdev);
>
> - if (usage->type == EV_REL && usage->code == REL_WHEEL)
> + if (usage->type == EV_REL && usage->code == REL_WHEEL_HI_RES)
> set_bit(REL_HWHEEL, *bit);
>
> if ((a4->quirks & A4_2WHEEL_MOUSE_HACK_7) && usage->hid == 0x00090007)
> @@ -60,7 +60,7 @@ static int a4_event(struct hid_device *hdev, struct hid_field *field,
> input = field->hidinput->input;
>
> if (a4->quirks & A4_2WHEEL_MOUSE_HACK_B8) {
> - if (usage->type == EV_REL && usage->code == REL_WHEEL) {
> + if (usage->type == EV_REL && usage->code == REL_WHEEL_HI_RES) {
> a4->delayed_value = value;
> return 1;
> }
> @@ -77,7 +77,7 @@ static int a4_event(struct hid_device *hdev, struct hid_field *field,
> return 1;
> }
>
> - if (usage->code == REL_WHEEL && a4->hw_wheel) {
> + if (usage->code == REL_WHEEL_HI_RES && a4->hw_wheel) {
> input_event(input, usage->type, REL_HWHEEL, value);
> return 1;
> }
> --
> 2.21.0
>
^ permalink raw reply
* Re: [PATCH] HID: fix A4Tech horizontal scrolling
From: Błażej Szczygieł @ 2019-05-03 9:22 UTC (permalink / raw)
To: Benjamin Tissoires; +Cc: igorkuo, Jiri Kosina, open list:HID CORE LAYER, lkml
In-Reply-To: <CAO-hwJLbFv3S9M5N+BKBuafj8H-vToy=2VQd=cvohmaTHLMC3A@mail.gmail.com>
Hi,
I used the hid-record tool and my results are here:
https://gitlab.com/snippets/1853568
Cheers,
Błażej
> Hi,
>
> On Thu, May 2, 2019 at 11:37 PM Błażej Szczygieł <spaz16@wp.pl> wrote:
>>
>> Since recent high resolution scrolling changes the A4Tech driver must
>> check for the "REL_WHEEL_HI_RES" usage code.
>>
>> Fixes: 2dc702c991e3774af9d7ce410eef410ca9e2357e (HID: input: use the
>> Resolution Multiplier for high-resolution scrolling)
>>
>> Signed-off-by: Błażej Szczygieł <spaz16@wp.pl>
>
> Thanks for the patch. I do not doubt this fixes the issues, but I
> still wonder if we should not export REL_HWHEEL_HI_RES instead of
> REL_HWHEEL events.
>
> Also, I can not figure out how the events are processed by the kernel.
> Could you attach a hid-recorder dump of the mouse wheels with
> hid-recorder from https://gitlab.freedesktop.org/libevdev/hid-tools ?
>
> This should give me a better view of the mouse, and I could also add
> it to the regression tests I am running for each commit.
>
> Cheers,
> Benjamin
>
>> ---
>> drivers/hid/hid-a4tech.c | 6 +++---
>> 1 file changed, 3 insertions(+), 3 deletions(-)
>>
>> diff --git a/drivers/hid/hid-a4tech.c b/drivers/hid/hid-a4tech.c
>> index 9428ea7cdf8a..fafb9fa558e7 100644
>> --- a/drivers/hid/hid-a4tech.c
>> +++ b/drivers/hid/hid-a4tech.c
>> @@ -38,7 +38,7 @@ static int a4_input_mapped(struct hid_device *hdev, struct hid_input *hi,
>> {
>> struct a4tech_sc *a4 = hid_get_drvdata(hdev);
>>
>> - if (usage->type == EV_REL && usage->code == REL_WHEEL)
>> + if (usage->type == EV_REL && usage->code == REL_WHEEL_HI_RES)
>> set_bit(REL_HWHEEL, *bit);
>>
>> if ((a4->quirks & A4_2WHEEL_MOUSE_HACK_7) && usage->hid == 0x00090007)
>> @@ -60,7 +60,7 @@ static int a4_event(struct hid_device *hdev, struct hid_field *field,
>> input = field->hidinput->input;
>>
>> if (a4->quirks & A4_2WHEEL_MOUSE_HACK_B8) {
>> - if (usage->type == EV_REL && usage->code == REL_WHEEL) {
>> + if (usage->type == EV_REL && usage->code == REL_WHEEL_HI_RES) {
>> a4->delayed_value = value;
>> return 1;
>> }
>> @@ -77,7 +77,7 @@ static int a4_event(struct hid_device *hdev, struct hid_field *field,
>> return 1;
>> }
>>
>> - if (usage->code == REL_WHEEL && a4->hw_wheel) {
>> + if (usage->code == REL_WHEEL_HI_RES && a4->hw_wheel) {
>> input_event(input, usage->type, REL_HWHEEL, value);
>> return 1;
>> }
>> --
>> 2.21.0
>>
^ permalink raw reply
* Re: [PATCH] HID: fix A4Tech horizontal scrolling
From: Igor Kushnir @ 2019-05-03 9:36 UTC (permalink / raw)
To: Benjamin Tissoires, Błażej Szczygieł
Cc: Jiri Kosina, open list:HID CORE LAYER, lkml
In-Reply-To: <CAO-hwJLbFv3S9M5N+BKBuafj8H-vToy=2VQd=cvohmaTHLMC3A@mail.gmail.com>
Hi Benjamin,
On 5/3/19 10:36 AM, Benjamin Tissoires wrote:
> Hi,
>
> On Thu, May 2, 2019 at 11:37 PM Błażej Szczygieł <spaz16@wp.pl> wrote:
>>
>> Since recent high resolution scrolling changes the A4Tech driver must
>> check for the "REL_WHEEL_HI_RES" usage code.
>>
>> Fixes: 2dc702c991e3774af9d7ce410eef410ca9e2357e (HID: input: use the
>> Resolution Multiplier for high-resolution scrolling)
>>
>> Signed-off-by: Błażej Szczygieł <spaz16@wp.pl>
>
> Thanks for the patch. I do not doubt this fixes the issues, but I
> still wonder if we should not export REL_HWHEEL_HI_RES instead of
> REL_HWHEEL events.
If you mean exporting REL_HWHEEL_HI_RES instead of REL_HWHEEL from
hid-a4tech.c, then it makes sense to me, though I do not know the code
well enough to be certain.
Błażej and I have discussed the bug and the patch here:
https://bugzilla.kernel.org/show_bug.cgi?id=203369
In summary: the patch fixes the bug for both our mice;
the documentation in input/event-codes.rst states that
REL_WHEEL, REL_HWHEEL "are legacy codes and REL_WHEEL_HI_RES and
REL_HWHEEL_HI_RES should be preferred where available."
> Also, I can not figure out how the events are processed by the kernel.
> Could you attach a hid-recorder dump of the mouse wheels with
> hid-recorder from https://gitlab.freedesktop.org/libevdev/hid-tools ?
>
> This should give me a better view of the mouse, and I could also add
> it to the regression tests I am running for each commit.
>
> Cheers,
> Benjamin
After launching hid-recorder for my A4Tech WOP-49Z mouse under kernel
5.0.10 patched with Błażej's patch I:
* scrolled the vertical wheel down ("Wheel: -1");
* scrolled the vertical wheel up ("Wheel: 1");
* scrolled the horizontal wheel "left" ("Wheel: -1");
* scrolled the horizontal wheel "right" ("Wheel: 1").
Note that the horizontal wheel is physically scrolled just like the
vertical one in this mouse (forward/back), so "left" and "right" are the
effects these scrollings make in applications when the kernel supports
the mouse properly.
$ sudo ./hid-recorder /dev/hidraw1
# A4Tech PS/2+USB Mouse
# 0x05, 0x01, // Usage Page (Generic Desktop) 0
# 0x09, 0x02, // Usage (Mouse) 2
# 0xa1, 0x01, // Collection (Application) 4
# 0x09, 0x01, // Usage (Pointer) 6
# 0xa1, 0x00, // Collection (Physical) 8
# 0x05, 0x09, // Usage Page (Button) 10
# 0x19, 0x01, // Usage Minimum (1) 12
# 0x29, 0x07, // Usage Maximum (7) 14
# 0x15, 0x00, // Logical Minimum (0) 16
# 0x25, 0x01, // Logical Maximum (1) 18
# 0x75, 0x01, // Report Size (1) 20
# 0x95, 0x07, // Report Count (7) 22
# 0x81, 0x02, // Input (Data,Var,Abs) 24
# 0x75, 0x01, // Report Size (1) 26
# 0x95, 0x01, // Report Count (1) 28
# 0x81, 0x01, // Input (Cnst,Arr,Abs) 30
# 0x05, 0x01, // Usage Page (Generic Desktop) 32
# 0x09, 0x30, // Usage (X) 34
# 0x09, 0x31, // Usage (Y) 36
# 0x09, 0x38, // Usage (Wheel) 38
# 0x15, 0x81, // Logical Minimum (-127) 40
# 0x25, 0x7f, // Logical Maximum (127) 42
# 0x75, 0x08, // Report Size (8) 44
# 0x95, 0x03, // Report Count (3) 46
# 0x81, 0x06, // Input (Data,Var,Rel) 48
# 0xc0, // End Collection 50
# 0xc0, // End Collection 51
#
R: 52 05 01 09 02 a1 01 09 01 a1 00 05 09 19 01 29 07 15 00 25 01 75 01
95 07 81 02 75 01 95 01 81 01 05 01 09 30 09 31 09 38 15 81 25 7f 75 08
95 03 81 06 c0 c0
N: A4Tech PS/2+USB Mouse
I: 3 09da 0006
# Button: 0 0 0 0 0 0 0 | # | X: 0 | Y: 0 | Wheel: -1
E: 000000.000000 4 00 00 00 ff
# Button: 0 0 0 0 0 0 0 | # | X: 0 | Y: 0 | Wheel: -1
E: 000000.071952 4 00 00 00 ff
# Button: 0 0 0 0 0 0 0 | # | X: 0 | Y: 0 | Wheel: -1
E: 000000.159957 4 00 00 00 ff
# Button: 0 0 0 0 0 0 0 | # | X: 0 | Y: 0 | Wheel: 1
E: 000002.912232 4 00 00 00 01
# Button: 0 0 0 0 0 0 0 | # | X: 0 | Y: 0 | Wheel: 1
E: 000002.952190 4 00 00 00 01
# Button: 0 0 0 0 0 0 0 | # | X: 0 | Y: 0 | Wheel: 1
E: 000004.512359 4 00 00 00 01
# Button: 0 0 0 0 0 0 0 | # | X: 0 | Y: 0 | Wheel: 1
E: 000004.584332 4 00 00 00 01
# Button: 0 0 0 0 0 0 1 | # | X: 0 | Y: 0 | Wheel: -1
E: 000007.528626 4 40 00 00 ff
# Button: 0 0 0 0 0 0 1 | # | X: 0 | Y: 0 | Wheel: -1
E: 000007.568577 4 40 00 00 ff
# Button: 0 0 0 0 0 0 1 | # | X: 0 | Y: 0 | Wheel: -1
E: 000008.256395 4 40 00 00 ff
# Button: 0 0 0 0 0 0 1 | # | X: 0 | Y: 0 | Wheel: -1
E: 000008.336669 4 40 00 00 ff
# Button: 0 0 0 0 0 0 1 | # | X: 0 | Y: 0 | Wheel: -1
E: 000008.400649 4 40 00 00 ff
# Button: 0 0 0 0 0 0 1 | # | X: 0 | Y: 0 | Wheel: 1
E: 000010.936908 4 40 00 00 01
# Button: 0 0 0 0 0 0 1 | # | X: 0 | Y: 0 | Wheel: 1
E: 000010.984864 4 40 00 00 01
# Button: 0 0 0 0 0 0 1 | # | X: 0 | Y: 0 | Wheel: 1
E: 000011.056897 4 40 00 00 01
# Button: 0 0 0 0 0 0 1 | # | X: 0 | Y: 0 | Wheel: 1
E: 000011.528936 4 40 00 00 01
# Button: 0 0 0 0 0 0 1 | # | X: 0 | Y: 0 | Wheel: 1
E: 000011.616923 4 40 00 00 01
Cheers,
Igor
>> ---
>> drivers/hid/hid-a4tech.c | 6 +++---
>> 1 file changed, 3 insertions(+), 3 deletions(-)
>>
>> diff --git a/drivers/hid/hid-a4tech.c b/drivers/hid/hid-a4tech.c
>> index 9428ea7cdf8a..fafb9fa558e7 100644
>> --- a/drivers/hid/hid-a4tech.c
>> +++ b/drivers/hid/hid-a4tech.c
>> @@ -38,7 +38,7 @@ static int a4_input_mapped(struct hid_device *hdev, struct hid_input *hi,
>> {
>> struct a4tech_sc *a4 = hid_get_drvdata(hdev);
>>
>> - if (usage->type == EV_REL && usage->code == REL_WHEEL)
>> + if (usage->type == EV_REL && usage->code == REL_WHEEL_HI_RES)
>> set_bit(REL_HWHEEL, *bit);
>>
>> if ((a4->quirks & A4_2WHEEL_MOUSE_HACK_7) && usage->hid == 0x00090007)
>> @@ -60,7 +60,7 @@ static int a4_event(struct hid_device *hdev, struct hid_field *field,
>> input = field->hidinput->input;
>>
>> if (a4->quirks & A4_2WHEEL_MOUSE_HACK_B8) {
>> - if (usage->type == EV_REL && usage->code == REL_WHEEL) {
>> + if (usage->type == EV_REL && usage->code == REL_WHEEL_HI_RES) {
>> a4->delayed_value = value;
>> return 1;
>> }
>> @@ -77,7 +77,7 @@ static int a4_event(struct hid_device *hdev, struct hid_field *field,
>> return 1;
>> }
>>
>> - if (usage->code == REL_WHEEL && a4->hw_wheel) {
>> + if (usage->code == REL_WHEEL_HI_RES && a4->hw_wheel) {
>> input_event(input, usage->type, REL_HWHEEL, value);
>> return 1;
>> }
>> --
>> 2.21.0
>>
^ permalink raw reply
* Re: [PATCH] HID: fix A4Tech horizontal scrolling
From: Benjamin Tissoires @ 2019-05-03 11:59 UTC (permalink / raw)
To: Igor Kushnir, Peter Hutterer
Cc: Błażej Szczygieł, Jiri Kosina,
open list:HID CORE LAYER, lkml
In-Reply-To: <1a40ea07-368a-93f6-8335-dec7ae50bbf4@gmail.com>
Hi,
On Fri, May 3, 2019 at 11:43 AM Igor Kushnir <igorkuo@gmail.com> wrote:
>
> Hi Benjamin,
>
> On 5/3/19 10:36 AM, Benjamin Tissoires wrote:
> > Hi,
> >
> > On Thu, May 2, 2019 at 11:37 PM Błażej Szczygieł <spaz16@wp.pl> wrote:
> >>
> >> Since recent high resolution scrolling changes the A4Tech driver must
> >> check for the "REL_WHEEL_HI_RES" usage code.
> >>
> >> Fixes: 2dc702c991e3774af9d7ce410eef410ca9e2357e (HID: input: use the
> >> Resolution Multiplier for high-resolution scrolling)
> >>
> >> Signed-off-by: Błażej Szczygieł <spaz16@wp.pl>
> >
> > Thanks for the patch. I do not doubt this fixes the issues, but I
> > still wonder if we should not export REL_HWHEEL_HI_RES instead of
> > REL_HWHEEL events.
>
>
> If you mean exporting REL_HWHEEL_HI_RES instead of REL_HWHEEL from
> hid-a4tech.c, then it makes sense to me, though I do not know the code
> well enough to be certain.
Yep, that's what I meant. I am worried that userspace doesn't know
well how to deal with a device that mixes the new and old REL_WHEEL
events.
>
> Błażej and I have discussed the bug and the patch here:
> https://bugzilla.kernel.org/show_bug.cgi?id=203369
Oh cool.
Then we should add: "Link:
https://bugzilla.kernel.org/show_bug.cgi?id=203369" in the commit
description.
Also, given that the patch will likely see a v2, te format of the
"Fixes" tag is not correct: see
https://www.kernel.org/doc/html/v4.20/process/submitting-patches.html#describe-your-changes
(I have been notified that I tend to not follow the rules here, so I
am trying to do better here :-P )
>
> In summary: the patch fixes the bug for both our mice;
> the documentation in input/event-codes.rst states that
> REL_WHEEL, REL_HWHEEL "are legacy codes and REL_WHEEL_HI_RES and
> REL_HWHEEL_HI_RES should be preferred where available."
>
> > Also, I can not figure out how the events are processed by the kernel.
> > Could you attach a hid-recorder dump of the mouse wheels with
> > hid-recorder from https://gitlab.freedesktop.org/libevdev/hid-tools ?
> >
> > This should give me a better view of the mouse, and I could also add
> > it to the regression tests I am running for each commit.
> >
> > Cheers,
> > Benjamin
>
> After launching hid-recorder for my A4Tech WOP-49Z mouse under kernel
> 5.0.10 patched with Błażej's patch I:
> * scrolled the vertical wheel down ("Wheel: -1");
> * scrolled the vertical wheel up ("Wheel: 1");
> * scrolled the horizontal wheel "left" ("Wheel: -1");
> * scrolled the horizontal wheel "right" ("Wheel: 1").
> Note that the horizontal wheel is physically scrolled just like the
> vertical one in this mouse (forward/back), so "left" and "right" are the
> effects these scrollings make in applications when the kernel supports
> the mouse properly.
>
> $ sudo ./hid-recorder /dev/hidraw1
> # A4Tech PS/2+USB Mouse
> # 0x05, 0x01, // Usage Page (Generic Desktop) 0
> # 0x09, 0x02, // Usage (Mouse) 2
> # 0xa1, 0x01, // Collection (Application) 4
> # 0x09, 0x01, // Usage (Pointer) 6
> # 0xa1, 0x00, // Collection (Physical) 8
> # 0x05, 0x09, // Usage Page (Button) 10
> # 0x19, 0x01, // Usage Minimum (1) 12
> # 0x29, 0x07, // Usage Maximum (7) 14
> # 0x15, 0x00, // Logical Minimum (0) 16
> # 0x25, 0x01, // Logical Maximum (1) 18
> # 0x75, 0x01, // Report Size (1) 20
> # 0x95, 0x07, // Report Count (7) 22
> # 0x81, 0x02, // Input (Data,Var,Abs) 24
> # 0x75, 0x01, // Report Size (1) 26
> # 0x95, 0x01, // Report Count (1) 28
> # 0x81, 0x01, // Input (Cnst,Arr,Abs) 30
> # 0x05, 0x01, // Usage Page (Generic Desktop) 32
> # 0x09, 0x30, // Usage (X) 34
> # 0x09, 0x31, // Usage (Y) 36
> # 0x09, 0x38, // Usage (Wheel) 38
> # 0x15, 0x81, // Logical Minimum (-127) 40
> # 0x25, 0x7f, // Logical Maximum (127) 42
> # 0x75, 0x08, // Report Size (8) 44
> # 0x95, 0x03, // Report Count (3) 46
> # 0x81, 0x06, // Input (Data,Var,Rel) 48
> # 0xc0, // End Collection 50
> # 0xc0, // End Collection 51
> #
> R: 52 05 01 09 02 a1 01 09 01 a1 00 05 09 19 01 29 07 15 00 25 01 75 01
> 95 07 81 02 75 01 95 01 81 01 05 01 09 30 09 31 09 38 15 81 25 7f 75 08
> 95 03 81 06 c0 c0
> N: A4Tech PS/2+USB Mouse
> I: 3 09da 0006
> # Button: 0 0 0 0 0 0 0 | # | X: 0 | Y: 0 | Wheel: -1
> E: 000000.000000 4 00 00 00 ff
> # Button: 0 0 0 0 0 0 0 | # | X: 0 | Y: 0 | Wheel: -1
> E: 000000.071952 4 00 00 00 ff
> # Button: 0 0 0 0 0 0 0 | # | X: 0 | Y: 0 | Wheel: -1
> E: 000000.159957 4 00 00 00 ff
> # Button: 0 0 0 0 0 0 0 | # | X: 0 | Y: 0 | Wheel: 1
> E: 000002.912232 4 00 00 00 01
> # Button: 0 0 0 0 0 0 0 | # | X: 0 | Y: 0 | Wheel: 1
> E: 000002.952190 4 00 00 00 01
> # Button: 0 0 0 0 0 0 0 | # | X: 0 | Y: 0 | Wheel: 1
> E: 000004.512359 4 00 00 00 01
> # Button: 0 0 0 0 0 0 0 | # | X: 0 | Y: 0 | Wheel: 1
> E: 000004.584332 4 00 00 00 01
> # Button: 0 0 0 0 0 0 1 | # | X: 0 | Y: 0 | Wheel: -1
> E: 000007.528626 4 40 00 00 ff
> # Button: 0 0 0 0 0 0 1 | # | X: 0 | Y: 0 | Wheel: -1
> E: 000007.568577 4 40 00 00 ff
> # Button: 0 0 0 0 0 0 1 | # | X: 0 | Y: 0 | Wheel: -1
> E: 000008.256395 4 40 00 00 ff
> # Button: 0 0 0 0 0 0 1 | # | X: 0 | Y: 0 | Wheel: -1
> E: 000008.336669 4 40 00 00 ff
> # Button: 0 0 0 0 0 0 1 | # | X: 0 | Y: 0 | Wheel: -1
> E: 000008.400649 4 40 00 00 ff
> # Button: 0 0 0 0 0 0 1 | # | X: 0 | Y: 0 | Wheel: 1
> E: 000010.936908 4 40 00 00 01
> # Button: 0 0 0 0 0 0 1 | # | X: 0 | Y: 0 | Wheel: 1
> E: 000010.984864 4 40 00 00 01
> # Button: 0 0 0 0 0 0 1 | # | X: 0 | Y: 0 | Wheel: 1
> E: 000011.056897 4 40 00 00 01
> # Button: 0 0 0 0 0 0 1 | # | X: 0 | Y: 0 | Wheel: 1
> E: 000011.528936 4 40 00 00 01
> # Button: 0 0 0 0 0 0 1 | # | X: 0 | Y: 0 | Wheel: 1
> E: 000011.616923 4 40 00 00 01
>
OK, thanks both of you for your logs, this is helpful.
So just in case I need to come back later, the horizontal wheel is
"just" the normal wheel plus a modifier in the report.
Anyway, ideally, can we have a v2 of the patch with the 2 changes
requested above in the commit message and the introduction of
REL_HWHEEL_HI_RES events in addition to REL_HWHEEL?
REL_HWHEEL_HI_RES should report `120*value` and we should also keep
the reporting of REL_WHEEL as it is currently.
Peter, I grepped in the hid code, and it seems hid-cypress.c is having
the exact same issue. Sigh.
Cheers,
Benjamin
^ permalink raw reply
* Re: [PATCH] HID: rmi: fix devm_add_action_or_reset() parameter
From: Jiri Kosina @ 2019-05-03 12:19 UTC (permalink / raw)
To: Fabien Dessenne; +Cc: Benjamin Tissoires, linux-input, linux-kernel
In-Reply-To: <1555073657-24386-1-git-send-email-fabien.dessenne@st.com>
On Fri, 12 Apr 2019, Fabien Dessenne wrote:
> The second parameter of devm_add_action_or_reset() shall be a function,
> not a function address.
>
> Signed-off-by: Fabien Dessenne <fabien.dessenne@st.com>
> ---
> drivers/hid/hid-rmi.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/hid/hid-rmi.c b/drivers/hid/hid-rmi.c
> index 9e33165..8748d4d 100644
> --- a/drivers/hid/hid-rmi.c
> +++ b/drivers/hid/hid-rmi.c
> @@ -623,7 +623,7 @@ static int rmi_setup_irq_domain(struct hid_device *hdev)
> if (!hdata->domain)
> return -ENOMEM;
>
> - ret = devm_add_action_or_reset(&hdev->dev, &rmi_irq_teardown, hdata);
> + ret = devm_add_action_or_reset(&hdev->dev, rmi_irq_teardown, hdata);
Why do you think this is wrong C?
--
Jiri Kosina
SUSE Labs
^ permalink raw reply
* Re: [PATCH] HID: rmi: fix devm_add_action_or_reset() parameter
From: Fabien DESSENNE @ 2019-05-03 12:38 UTC (permalink / raw)
To: Jiri Kosina
Cc: Benjamin Tissoires, linux-input@vger.kernel.org,
linux-kernel@vger.kernel.org
In-Reply-To: <nycvar.YFH.7.76.1905031418510.10635@cbobk.fhfr.pm>
On 03/05/2019 2:19 PM, Jiri Kosina wrote:
> On Fri, 12 Apr 2019, Fabien Dessenne wrote:
>
>> The second parameter of devm_add_action_or_reset() shall be a function,
>> not a function address.
>>
>> Signed-off-by: Fabien Dessenne <fabien.dessenne@st.com>
>> ---
>> drivers/hid/hid-rmi.c | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/drivers/hid/hid-rmi.c b/drivers/hid/hid-rmi.c
>> index 9e33165..8748d4d 100644
>> --- a/drivers/hid/hid-rmi.c
>> +++ b/drivers/hid/hid-rmi.c
>> @@ -623,7 +623,7 @@ static int rmi_setup_irq_domain(struct hid_device *hdev)
>> if (!hdata->domain)
>> return -ENOMEM;
>>
>> - ret = devm_add_action_or_reset(&hdev->dev, &rmi_irq_teardown, hdata);
>> + ret = devm_add_action_or_reset(&hdev->dev, rmi_irq_teardown, hdata);
> Why do you think this is wrong C?
Because I was not aware that both func and &func refer to the same
function pointer.
Now I know :)
>
^ permalink raw reply
* Re: [PATCH] HID: rmi: fix devm_add_action_or_reset() parameter
From: Jiri Kosina @ 2019-05-03 12:42 UTC (permalink / raw)
To: Fabien DESSENNE
Cc: Benjamin Tissoires, linux-input@vger.kernel.org,
linux-kernel@vger.kernel.org
In-Reply-To: <9628edde-5270-d5a5-7db6-c9ec3f47c742@st.com>
On Fri, 3 May 2019, Fabien DESSENNE wrote:
> >> - ret = devm_add_action_or_reset(&hdev->dev, &rmi_irq_teardown, hdata);
> >> + ret = devm_add_action_or_reset(&hdev->dev, rmi_irq_teardown, hdata);
> > Why do you think this is wrong C?
>
> Because I was not aware that both func and &func refer to the same
> function pointer.
>
> Now I know :)
Yup, it's defined in 6.3.2.1.4 in C99.
--
Jiri Kosina
SUSE Labs
^ 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