- 01 Jul, 2019 1 commit
-
-
Nathan Huckleberry authored
Clang produces the following warning drivers/input/touchscreen/atmel_mxt_ts.c:259:42: warning: unused variable 'mxt_video_fops' [-Wunused-const-variable] static const struct v4l2_file_operations mxt_video_fops = { Since mxt_video_fops is only used inside an ifdef. It should be moved inside the ifdef. Link: https://github.com/ClangBuiltLinux/linux/issues/527Signed-off-by:Nathan Huckleberry <nhuck@google.com> Reviewed-by:
Nick Desaulniers <ndesaulniers@google.com> Signed-off-by:
Dmitry Torokhov <dmitry.torokhov@gmail.com>
-
- 30 Jun, 2019 5 commits
-
-
Alexander Tsoy authored
Extend event signature matching to catch more input devices emulated by BMC firmwares, QEMU and VMware. Signed-off-by:
Alexander Tsoy <alexander@tsoy.me> Signed-off-by:
-
Jeffrey Hugo authored
There needs to be coordination between hid-quirks and the elan_i2c driver about which devices are handled by what drivers. Currently, both use whitelists, which results in valid devices being unhandled by default, when they should not be rejected by hid-quirks. This is quickly becoming an issue. Since elan_i2c has a maintained whitelist of what devices it will handle, which is now in a header file that hid-quirks can access, use that to implement a blacklist in hid-quirks so that only the devices that need to be handled by elan_i2c get rejected by hid-quirks, and everything else is handled by default. Suggested-by:
Benjamin Tissoires <benjamin.tissoires@redhat.com> Signed-off-by:
Jeffrey Hugo <jeffrey.l.hugo@gmail.com> Acked-by:
-
Jeffrey Hugo authored
Elan_i2c and hid-quirks work in conjunction to decide which devices each driver will handle. Elan_i2c has a whitelist of devices that should be consumed by hid-quirks so that there is one master list of devices to handoff between the drivers. Put the ids in a header file so that hid-quirks can consume it instead of duplicating the list. Signed-off-by:
-
Dmitry Torokhov authored
Instead of doing conversion by hand, let's use the proper accessors. Reviewed-by:
Andy Shevchenko <andy.shevchenko@gmail.com> Tested-by:
Benoit Parrot <bparrot@ti.com> Signed-off-by:
-
Dmitry Torokhov authored
Bring in improvements to driver for I-Force devices.
-
- 23 Jun, 2019 22 commits
-
-
Tim Schumacher authored
This is added based on the fact that this is an iforce-based device and that the Windows driver for the R440 works for the Logitech WingMan Formula Force after replacing the device/vendor IDs. Signed-off-by:
Tim Schumacher <timschumi@gmx.de> Signed-off-by:
-
Dmitry Torokhov authored
Instead of open-coding conversion from/to little-endian, let's use proper accessors. Tested-by:
-
Dmitry Torokhov authored
Transport initialization code now deals mostly with transport-specific data, so we can drop couple of temporary variables. Tested-by:
-
Dmitry Torokhov authored
It is not needed anymore as behavior is controlled by the transport operations set up for given device. Tested-by:
-
Dmitry Torokhov authored
USB transport has to use cache line-aligned buffers for transfers to avoid DMA issues; serio doe snot have such restrictions. Let's move "data_in" buffer from main driver structure into transport modules and make sure USB requirements are respected. Tested-by:
-
Dmitry Torokhov authored
We want to move buffer handling into transport layers as the properties of buffers (DMA-safety, alignment, etc) are different for different transports. To allow this, let's allow caller to specify their own buffers for the results of iforce_get_id_packet() and let transport drivers to figure what buffers they need to use for transfers. Tested-by:
-
Dmitry Torokhov authored
It is excessive to check if device is fully initialized in iforce_process_packet(), as for USB-conected devices we do not start collecting reports until the device is fully initialized. Let's change serio transport code to not call iforce_process_packet() until device initialization is done. Tested-by:
-
Dmitry Torokhov authored
Signalling command completion from iforce_process_packet() does not make sense, as not all transport use the same data path for both commands and motion data form the device, that is why USB code already has to signal command completion iforce_usb_out(). Let's move signalling completion into individual transport modules. Tested-by:
-
Dmitry Torokhov authored
Current code combines packet type and data length into single argument to iforce_process_packet() and then has to untangle it. It is much clearer to simply use separate arguments. Tested-by:
-
Dmitry Torokhov authored
This makes code clearer a bit. Tested-by:
-
Dmitry Torokhov authored
According to our coding style case labels in switch statements should be aligned with the switch keyword. Tested-by:
-
Dmitry Torokhov authored
When working with USB devices we need to use DMA-safe buffers, and iforce->edata is not one. Let's rework the code to allocate temporary buffer (iforce_get_id() is called only during initialization so there is no reason to have permanent buffer) and use it. While at it, let's utilize usb_control_msg() API which simplifies code. Tested-by:
-
Dmitry Torokhov authored
Now that we have moved enough transport details into separate source files we can change them into transport modules so that they are only loaded when needed. Tested-by:
-
Dmitry Torokhov authored
This moves transport-specific data from main iforce structure into transport modules. Tested-by:
-
Dmitry Torokhov authored
Note that the parent device for the USB-connected controllers is now USB interface instead of USB device. Tested-by:
-
Dmitry Torokhov authored
Add start_io() and stop_io() transport methods so that core does not have to know the details. Tested-by:
-
Dmitry Torokhov authored
Continue teasing apart protocol-specific bits from core into transport modules. This time move RS232-specific command completion handling from core to iforce-serio module. Tested-by:
-
Dmitry Torokhov authored
To avoid #ifdef-ing out parts of the code and having conditionals in normal control flow, let's define "get_id" transport method and move implementation into respective transport modules. Tested-by:
-
Dmitry Torokhov authored
In order to tease apart the driver into core and transport modules, let's introduce transport operations and make "xmit" the very first one such operation. Tested-by:
-
Dmitry Torokhov authored
The kernel is supposed to handle multiple devices, static flags in packet handling code will never work. Tested-by:
-
Gustavo A. R. Silva authored
One of the more common cases of allocation size calculations is finding the size of a structure that has a zero-sized array at the end, along with memory for some number of elements for that array. For example: struct gpio_keys_drvdata { ... struct gpio_button_data data[0]; }; size = sizeof(struct gpio_keys_drvdata) + count * sizeof(struct gpio_button_data); instance = devm_kzalloc(dev, size, GFP_KERNEL); Instead of leaving these open-coded and prone to type mistakes, we can now use the new struct_size() helper: instance = devm_kzalloc(dev, struct_size(instance, data, count), GFP_KERNEL); Notice that, in this case, variable size is not necessary, hence it is removed. This code was detected with the help of Coccinelle. Signed-off-by:Gustavo A. R. Silva <gustavo@embeddedor.com> Signed-off-by:
-
Gustavo A. R. Silva authored
One of the more common cases of allocation size calculations is finding the size of a structure that has a zero-sized array at the end, along with memory for some number of elements for that array. For example: struct gpio_keys_polled_dev { ... struct gpio_keys_button_data data[0]; }; size = sizeof(struct gpio_keys_polled_dev) + count * sizeof(struct gpio_keys_button_data); instance = devm_kzalloc(dev, size, GFP_KERNEL); Instead of leaving these open-coded and prone to type mistakes, we can now use the new struct_size() helper: instance = devm_kzalloc(dev, struct_size(instance, data, count), GFP_KERNEL); Notice that, in this case, variable size is not necessary, hence it is removed. This code was detected with the help of Coccinelle. Signed-off-by:
-
- 28 May, 2019 11 commits
-
-
YueHaibing authored
Fixes gcc '-Wunused-but-set-variable' warning: drivers/input/keyboard/tca8418_keypad.c: In function tca8418_keypad_probe: drivers/input/keyboard/tca8418_keypad.c:269:24: warning: variable max_keys set but not used [-Wunused-but-set-variable] It's not used since commit 16ff7cb1 ("Input: tca8418-keypad - switch to using managed resources") Signed-off-by:
YueHaibing <yuehaibing@huawei.com> Signed-off-by:
-
YueHaibing authored
Fixes gcc '-Wunused-but-set-variable' warning: drivers/input/rmi4/rmi_f12.c: In function rmi_f12_read_sensor_tuning: drivers/input/rmi4/rmi_f12.c:76:6: warning: variable sensor_flags set but not used [-Wunused-but-set-variable] It's not used since introduction in commit b43d2c1e ("Input: synaptics-rmi4 - add support for F12") Signed-off-by:
-
Benjamin Tissoires authored
Both now works correctly over SMBus. Let's use this driver so we can update all five fingers every 8ms. Signed-off-by:
-
Benjamin Tissoires authored
Some models have a middle button, we should export it as well. Signed-off-by:
-
Benjamin Tissoires authored
The recent touchpads might not have all the information regarding the characteristics through the I2C port. On some Lenovo t480s, this results in the touchpad not being detected as a clickpad, and on the Lenovo P52, this results in a failure while fetching the resolution through I2C. We need to imitate the Windows behavior: fetch the data under PS/2, and limit the querries under I2C. This patch prepares this by exporting the info from PS/2. Signed-off-by:
-
Benjamin Tissoires authored
See the previous patch for a long explanation. TL;DR: the P52 and the t480s from Lenovo can't rely on I2C to fetch the information, so we need it from PS/2. Signed-off-by:
-
Benjamin Tissoires authored
Some new touchpads IC are connected through PS/2 and I2C. On some of these new IC, the I2C part doesn't have all of the information available. We need to be able to forward the touchpad parameters from PS/2 and thus, we need those new optional properties. Signed-off-by:
-
Benjamin Tissoires authored
Looks like the new generation of Lenovo machine also need to be added to the PnPID whitelist. This is definitively not going to scale, as there is nothing that tells us currently if a touchpad supports a true physical middle button. Consider that all new touchpads that are not clickpads (so matching ETP_NEW_IC_SMBUS_HOST_NOTIFY) are handling 3 physical buttons. Signed-off-by:
-
Benjamin Tissoires authored
We check for this bit all over the code, better have it defined once for all. Signed-off-by:
-
Benjamin Tissoires authored
For the latest generation of Elantech touchpads, we need to forward the min/max information from PS/2 to SMBus. Prepare this work by fetching the information before creating the SMBus companion device. Signed-off-by:
-
Dmitry Torokhov authored
Sync up with 'for-linus' branch to avoid merge conflicts with following patches to Elan touchpad drivers.
-
- 23 May, 2019 1 commit
-
-
Axel Lin authored
Calling i2c_set_clientdata() is enough. Signed-off-by:
Axel Lin <axel.lin@ingics.com> Acked-by:
Jeff LaBundy <jeff@labundy.com> Signed-off-by:
-
