- 29 Mar, 2017 2 commits
-
-
David Rivshin authored
The gpio-matrix-keypad driver normally sets inactive columns as inputs while scanning. This does not work for all hardware, which may require the inactive columns to be actively driven in order to overcome any pull-ups/downs on the columns. Signed-off-by: David Rivshin <drivshin@allworx.com> Acked-by: Rob Herring <robh@kernel.org> Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
-
Dmitry Torokhov authored
Try a quick read from the device in mip4_query_device() to make sure that the device is there, as we do not consider failures to retrieve product name or resolution fatal. Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
-
- 25 Mar, 2017 8 commits
-
-
David Jander authored
Each time the HWMON devices are read (e.g. battery voltage) while the touchscreen is held pressed, extra pen-up and pen-down events are generated. This is fixed by avoiding the UP event when the touchscreen is stopped. Signed-off-by: David Jander <david@protonic.nl> Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
-
Benjamin Tissoires authored
Most of the Synaptics devices are connected through PS/2 and a different bus (SMBus or HID over I2C). The secondary bus capability is indicated by the InterTouch bit in extended capability 0x0C. We only enable the InterTouch device to be created for the laptops registered with the top software button property or those we know that are functional. In the future, we might change the default to always rely on the InterTouch bus. Currently, users can enable/disable the feature with the psmouse parameter synaptics_intertouch. Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com> Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
-
Dmitry Torokhov authored
In preparation for SMBus/Intertouch device support, move static device information that we query form the touchpad upon initialization into separate structure. This will allow us to query the device without allocating memory first. Also stop using "unsigned long", everything fits into 32 bit chunks. Reviewed-by: Benjamin Tissoires <benjamin.tissoires@redhat.com> Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
-
Benjamin Tissoires authored
This provides glue between PS/2 devices that enumerate the RMI4 devices and Elan touchpads to the RMI4 (or Elan) SMBus driver. The SMBus devices keep their PS/2 connection alive. If the initialization process goes too far (psmouse_activate called), the device disconnects from the I2C bus and stays on the PS/2 bus, that is why we explicitly disable PS/2 device reporting (by calling psmouse_deactivate) before trying to register SMBus companion device. The HID over I2C devices are enumerated through the ACPI DSDT, and their PS/2 device also exports the InterTouch bit in the extended capability 0x0C. However, the firmware keeps its I2C connection open even after going further in the PS/2 initialization. We don't need to take extra precautions with those device, especially because they block their PS/2 communication when HID over I2C is used. Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com> Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
-
Dmitry Torokhov authored
Prepare PS/2 mouse drivers to work with devices that are accessible both via PS/2 and SMBus, which provides higher bandwidth, and thus suits better for modern multi-touch devices. We expect that SMBus drivers will take control over the device, so when we detect SMBus "protocol" we forego registering input device, or enabling PS/2 device reports (as it usually makes device unresponsive to access over SMBus). Reviewed-by: Benjamin Tissoires <benjamin.tissoires@redhat.com> Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
-
Dmitry Torokhov authored
Instead of storing only protocol "type" in pmsouse structure, store pointer to the protocol structure, so that we have access to more data without having to copy it over to psmouse structure. Reviewed-by: Benjamin Tissoires <benjamin.tissoires@redhat.com> Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
-
Dmitry Torokhov authored
Make use of serio's fast reconnect option and allow psmouse protocol handler's to implement fast reconnect handlers that will be called during system resume. Reviewed-by: Benjamin Tissoires <benjamin.tissoires@redhat.com> Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
-
Dmitry Torokhov authored
Devices connected to serio bus are quite slow, and to improve apparent speed of resume process, serio core resumes (reconnects) its devices asynchronously, by posting port reconnect requests to a workqueue. Unfortunately this means that if there is a dependent device of a given serio port (for example SMBus part of touchpad connected via both PS/2 and SMBus), we do not have a good way of ensuring resume order. This change allows drivers to define "fast reconnect" handlers that would be called in-line during system resume. Drivers need to ensure that these handlers are truly "fast". Reviewed-by: Benjamin Tissoires <benjamin.tissoires@redhat.com> Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
-
- 23 Mar, 2017 4 commits
-
-
Dmitry Torokhov authored
Let's stop using !!x to reduce value of trackstick button expression to 0/1 and use shift instead. This removes the following sparse warning: CHECK drivers/input/mouse/synaptics.c drivers/input/mouse/synaptics.c:943:79: warning: dubious: !x | y Also, the bits we are testing are not capabilities, so lets drop "_CAP" suffix from macro names. Reviewed-by: Benjamin Tissoires <benjamin.tissoires@redhat.com> Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
-
Javier Martinez Canillas authored
The driver doesn't have a struct of_device_id table but supported devices are registered via Device Trees. This is working on the assumption that a I2C device registered via OF will always match a legacy I2C device ID and that the MODALIAS reported will always be of the form i2c:<device>. But this could change in the future so the correct approach is to have an OF device ID table if the devices are registered via OF. The compatible strings don't have a vendor prefix because that's how it's used currently, and changing this will be a Device Tree ABI break. Signed-off-by: Javier Martinez Canillas <javier@osg.samsung.com> Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
-
Javier Martinez Canillas authored
The driver doesn't have a struct of_device_id table but supported devices are registered via Device Trees. This is working on the assumption that a I2C device registered via OF will always match a legacy I2C device ID and that the MODALIAS reported will always be of the form i2c:<device>. But this could change in the future so the correct approach is to have an OF device ID table if the devices are registered via OF. Signed-off-by: Javier Martinez Canillas <javier@osg.samsung.com> Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
-
Javier Martinez Canillas authored
The driver doesn't have a struct of_device_id table but supported devices are registered via Device Trees. This is working on the assumption that a I2C device registered via OF will always match a legacy I2C device ID and that the MODALIAS reported will always be of the form i2c:<device>. But this could change in the future so the correct approach is to have an OF device ID table if the devices are registered via OF. As pointed by Hans de Goede, there's no mssl1680 and this is just used in some ACPI systems to identify the gsl1680 chip. So isn't included in the OF device ID table since a DT should use the proper device name instead. Signed-off-by: Javier Martinez Canillas <javier@osg.samsung.com> Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
-
- 18 Mar, 2017 1 commit
-
-
Joe Perches authored
To enable eventual removal of pr_warning This makes pr_warn use consistent for drivers/input Prior to this patch, there were 8 uses of pr_warning and 17 uses of pr_warn in drivers/input Signed-off-by: Joe Perches <joe@perches.com> Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
-
- 17 Mar, 2017 2 commits
-
-
Hans de Goede authored
Windows 10 tablets with gpio buttons will typically use the ACPI 6.0 Generic Button Device with a HID of ACPI0011 for these buttons. The ACPI description for these in the ACPI0011 devices _DSD object uses something resembling HID descriptors, except that instead of indicating a bit index into a HID input report, the index indicates the _CRS index for the GPIO. The use of 1 interrupt per button, some of which need to be wakeup sources, instead of using input reports makes it impossible to use the HID subsystem for this. This really is just another gpio-keys input device with the platform data described in ACPI, so this commit adds parsing for this new way to describe gpio-keys to the soc_button_array driver. Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
-
Hans de Goede authored
Count how much gpio_keys we actually need, this is a preparation patch for adding support for the new Win10 / ACPI-6.0 "Generic Buttons Device" support. Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
-
- 15 Mar, 2017 1 commit
-
-
Yegor Yefremov authored
Update the code to use devm_* API so that driver core will manage resources. Signed-off-by: Yegor Yefremov <yegorslists@googlemail.com> Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
-
- 09 Mar, 2017 9 commits
-
-
Dmitry Torokhov authored
Using devm_* APIs simpifies error handling and device teardown. Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
-
Dmitry Torokhov authored
Now that sparse keymap uses managed memory, we no longer need to clean it up manually. Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
-
Dmitry Torokhov authored
Now that sparse keymap uses managed memory, we no longer need to clean it up manually. Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
-
Dmitry Torokhov authored
This brings in version of sparse keymap code that uses managed memory.
-
Hans de Goede authored
The gpiolib-acpi code is becoming more strict and connection-IDs may only be used with devices which have a _DSD with matching IDs in there. Since the soc_button_array ACPI binding is pure index based pass in NULL as connection-ID to avoid the more strict cheks resulting in gpiod_count and gpiod_get_index not returning any gpios. Signed-off-by: Hans de Goede <hdegoede@redhat.com> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
-
Hans de Goede authored
On some systems (Intel tablets with axp288 pmic) the powerbutton is also connected to a gpio pin of the SoC, advertised through the "INTCFD9" / "PNP0C40" acpi device. This leads to double reporting of powerbutton events, which is undesirable, so one driver needs to not report input events in this case. Since the soc_button_array driver for the "PNP0C40" acpi device also handles wake from suspend on these tablets and since the axp20x-pel driver requires relative expensive i2c accrsses, it is best for the axp20x-pek driver to not register an input device in this case. Note that this commit leaves the axp20x-driver bound to the device, rather then returning -ENODEV, this is done so that the sysfs attributes it offers are kept around. Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
-
Hans de Goede authored
Move all input device related initialization into a new axp20x_pek_probe_input_device helper function. This introduces one functional change, the input device is now registered before the sysfs attr get registered. This is not a problem as the sysfs attr are to configure some long press settings (forced poweroff) in the hardware and do not interact with the input_device. This is a preparation patch for not always registering the input dev. Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
-
Hans de Goede authored
Before this commit axp20x-pek was mixing 2 style error reporting calls: dev_err(&pdev->dev, ...); dev_err(axp20x->dev, ...); But the second is our parent device, not our own device, so switch to using &pdev->dev everywhere. Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
-
Jingkui Wang authored
As the driver is using generic device properties, it should work properly when CONFIG_OF is turned off. This patch removes the ifdef CONFIGOF and make sure the driver always have of_match_table. Signed-off-by: Jingkui Wang <jkwang@google.com> Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
-
- 08 Mar, 2017 1 commit
-
-
Michał Kępień authored
Some platform drivers use devm_input_allocate_device() together with sparse_keymap_setup() in their .probe callbacks. While using the former simplifies error handling, using the latter necessitates calling sparse_keymap_free() in the error path and upon module unloading to avoid leaking the copy of the keymap allocated by sparse_keymap_setup(). To help prevent such leaks and enable simpler error handling, make sparse_keymap_setup() use devm_kmemdup() to create the keymap copy so that it gets automatically freed. This works for both managed and non-managed input devices as the keymap is freed after the last reference to the input device is dropped. Note that actions previously taken by sparse_keymap_free(), i.e. taking the input device's mutex and zeroing its keycode and keycodemax fields, are now redundant because the managed keymap will always be freed after the input device is unregistered. Signed-off-by: Michał Kępień <kernel@kempniu.pl> Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
-
- 07 Mar, 2017 4 commits
-
-
Guan Ben authored
Extend the pwm-beeper driver to support customized frequency for SND_BELL from device properties. Signed-off-by: Guan Ben <ben.guan@cn.bosch.com> Signed-off-by: Mark Jonas <mark.jonas@de.bosch.com> Signed-off-by: Heiko Schocher <hs@denx.de> Acked-by: Rob Herring <robh@kernel.org> Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
-
Pali Rohár authored
Sort all devices in alps_model_data by signature and remove command_mode_resp which is not used anymore. Signed-off-by: Pali Rohár <pali.rohar@gmail.com> Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
-
Pali Rohár authored
Support for devices with ALPS_PROTO_V9 is not implemented yet but we can detect these alps touchpads and warn users about it. Signed-off-by: Pali Rohár <pali.rohar@gmail.com> Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
-
Pali Rohár authored
Like for other protocols create alps_v4_protocol_data and use it in alps_identify() function. Signed-off-by: Pali Rohár <pali.rohar@gmail.com> Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
-
- 01 Mar, 2017 4 commits
-
-
Dmitry Torokhov authored
Instead of manipulating capabilities bits of input device directly, let's use input_set_capability() API. Also, stop setting ABS_X/Y bits explicitly as input_set_abs_params() does this for us. Acked-by: Michael Hennerich <michael.hennerich@analog.com> Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
-
Dmitry Torokhov authored
We have switched the driver to use generic device properties API, so there is no need to check for presence of DT node before trying parse properties. Acked-by: Michael Hennerich <michael.hennerich@analog.com> Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
-
Dmitry Torokhov authored
With the switch to devm, there is no need for ad7879_probe() to return the touchscreen structure, we can use plain error code. This also fixes issue introduced with devm concersion, where we returned 0 on success (which worked OK since IS_ERR(0) would not trigger, but was not correct regardless). Fixes: 381f688eee3d ("Input: ad7879 - use more devm interfaces") Acked-by: Michael Hennerich <michael.hennerich@analog.com> Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
-
Dmitry Torokhov authored
The conversion to devm accidentally removed setting up of I2C client data upon successful probe of the touchscreen. Let's move this setting into the core, so we do not forger about it again. Fixes: 381f688eee3d ("Input: ad7879 - use more devm interfaces") Acked-by: Michael Hennerich <michael.hennerich@analog.com> Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
-
- 25 Feb, 2017 2 commits
-
-
H. Nikolaus Schaller authored
This moves device tree bindings for ADS7846 together with the other touchscreen bindings. Signed-off-by: H. Nikolaus Schaller <hns@goldelico.com> Acked-by: Rob Herring <robh@kernel.org> Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
-
Randy Dunlap authored
Add header file to fix these build errors: ../drivers/input/touchscreen/ad7879.c: In function 'ad7879_parse_dt': ../drivers/input/touchscreen/ad7879.c:505:2: error: implicit declaration of function 'device_property_read_u32' [-Werror=implicit-function-declaration] err = device_property_read_u32(dev, "adi,resistance-plate-x", &tmp); ^ ../drivers/input/touchscreen/ad7879.c:512:2: error: implicit declaration of function 'device_property_read_u8' [-Werror=implicit-function-declaration] device_property_read_u8(dev, "adi,first-conversion-delay", ^ ../drivers/input/touchscreen/ad7879.c:521:2: error: implicit declaration of function 'device_property_read_bool' [-Werror=implicit-function-declaration] ts->swap_xy = device_property_read_bool(dev, "touchscreen-swapped-x-y"); ^ Signed-off-by: Randy Dunlap <rdunlap@infradead.org> Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
-
- 23 Feb, 2017 2 commits
-
-
Dmitry Torokhov authored
Bring in TSC2007 improvements.
-
Dmitry Torokhov authored
There is no need to tread the same register twice in a row. Fixes: ea4348c8 ("Input: tca8418_keypad - hide gcc-4.9 -Wmaybe-un ...") Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
-