linux-toradex.git/drivers/input/rmi4, branch v5.5-rc7 Linux kernel for Apalis and Colibri modules Merge branch 'next' into for-linus 2019-12-06T19:14:23+00:00 Dmitry Torokhov dmitry.torokhov@gmail.com 2019-12-06T19:14:23+00:00 afbd65f5e71a37fc9f46cb3e867e141a65d6ec25 Prepare second round of updates for 5.5 merge window. 
Prepare second round of updates for 5.5 merge window.
Input: synaptics-rmi4 - don't increment rmiaddr for SMBus transfers 2019-12-05T01:58:16+00:00 Hans Verkuil hverkuil-cisco@xs4all.nl 2019-12-02T18:08:12+00:00 a284e11c371e446371675668d8c8120a27227339 This increment of rmi_smbus in rmi_smb_read/write_block() causes garbage to be read/written. The first read of SMB_MAX_COUNT bytes is fine, but after that it is nonsense. Trial-and-error showed that by dropping the increment of rmiaddr everything is fine and the F54 function properly works. I tried a hack with rmi_smb_write_block() as well (writing to the same F54 touchpad data area, then reading it back), and that suggests that there too the rmiaddr increment has to be dropped. It makes sense that if it has to be dropped for read, then it has to be dropped for write as well. It looks like the initial work with F54 was done using i2c, not smbus, and it seems nobody ever tested F54 with smbus. The other functions all read/write less than SMB_MAX_COUNT as far as I can tell, so this issue was never noticed with non-F54 functions. With this change I can read out the touchpad data correctly on my Lenovo X1 Carbon 6th Gen laptop. Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Link: https://lore.kernel.org/r/8dd22e21-4933-8e9c-a696-d281872c8de7@xs4all.nl Cc: stable@vger.kernel.org Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com> 
This increment of rmi_smbus in rmi_smb_read/write_block() causes
garbage to be read/written.

The first read of SMB_MAX_COUNT bytes is fine, but after that
it is nonsense. Trial-and-error showed that by dropping the
increment of rmiaddr everything is fine and the F54 function
properly works.

I tried a hack with rmi_smb_write_block() as well (writing to the
same F54 touchpad data area, then reading it back), and that
suggests that there too the rmiaddr increment has to be dropped.
It makes sense that if it has to be dropped for read, then it has
to be dropped for write as well.

It looks like the initial work with F54 was done using i2c, not smbus,
and it seems nobody ever tested F54 with smbus. The other functions
all read/write less than SMB_MAX_COUNT as far as I can tell, so this
issue was never noticed with non-F54 functions.

With this change I can read out the touchpad data correctly on my
Lenovo X1 Carbon 6th Gen laptop.

Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Link: https://lore.kernel.org/r/8dd22e21-4933-8e9c-a696-d281872c8de7@xs4all.nl
Cc: stable@vger.kernel.org
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Input: synaptics-rmi4 - re-enable IRQs in f34v7_do_reflash 2019-12-05T01:58:16+00:00 Lucas Stach l.stach@pengutronix.de 2019-12-02T17:37:00+00:00 86bcd3a12999447faad60ec59c2d64d18d8e61ac F34 is a bit special as it reinitializes the device and related driver structs during the firmware update. This clears the fn_irq_mask which will then prevent F34 from receiving further interrupts, leading to timeouts during the firmware update. Make sure to reinitialize the IRQ enables at the appropriate times. The issue is in F34 code, but the commit in the fixes tag exposed the issue, as before this commit things would work by accident. Fixes: 363c53875aef (Input: synaptics-rmi4 - avoid processing unknown IRQs) Signed-off-by: Lucas Stach <l.stach@pengutronix.de> Link: https://lore.kernel.org/r/20191129133514.23224-1-l.stach@pengutronix.de Cc: stable@vger.kernel.org Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com> 
F34 is a bit special as it reinitializes the device and related driver
structs during the firmware update. This clears the fn_irq_mask which
will then prevent F34 from receiving further interrupts, leading to
timeouts during the firmware update. Make sure to reinitialize the
IRQ enables at the appropriate times.

The issue is in F34 code, but the commit in the fixes tag exposed the
issue, as before this commit things would work by accident.

Fixes: 363c53875aef (Input: synaptics-rmi4 - avoid processing unknown IRQs)
Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
Link: https://lore.kernel.org/r/20191129133514.23224-1-l.stach@pengutronix.de
Cc: stable@vger.kernel.org
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Merge branch 'next' into for-linus 2019-11-25T21:26:56+00:00 Dmitry Torokhov dmitry.torokhov@gmail.com 2019-11-25T21:26:56+00:00 976e3645923bdd2fe7893aae33fd7a21098bfb28 Prepare input updates for 5.5 merge window. 
Prepare input updates for 5.5 merge window.
Input: synaptics-rmi4 - fix various V4L2 compliance problems in F54 2019-11-23T00:21:52+00:00 Hans Verkuil hverkuil-cisco@xs4all.nl 2019-11-23T00:17:47+00:00 71c296f6d5b33faf9867d04c6c5d75c7e56b886b The v4l2-compliance utility reported several V4L2 API compliance issues: - the sequence counter wasn't filled in - the sequence counter wasn't reset to 0 at the start of streaming - the returned field value wasn't set to V4L2_FIELD_NONE - the timestamp wasn't set - the payload size was undefined if an error was returned - min_buffers_needed doesn't need to be initialized Fix these issues. Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Reviewed-by: Lucas Stach <l.stach@pengutronix.de Link: https://lore.kernel.org/r/20191119105118.54285-3-hverkuil-cisco@xs4all.nl Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com> 
The v4l2-compliance utility reported several V4L2 API compliance
issues:

- the sequence counter wasn't filled in
- the sequence counter wasn't reset to 0 at the start of streaming
- the returned field value wasn't set to V4L2_FIELD_NONE
- the timestamp wasn't set
- the payload size was undefined if an error was returned
- min_buffers_needed doesn't need to be initialized

Fix these issues.

Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Reviewed-by: Lucas Stach <l.stach@pengutronix.de
Link: https://lore.kernel.org/r/20191119105118.54285-3-hverkuil-cisco@xs4all.nl
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Input: synaptics-rmi4 - destroy F54 poller workqueue when removing 2019-11-15T19:46:33+00:00 Chuhong Yuan hslester96@gmail.com 2019-11-15T19:32:36+00:00 ba60cf9f78f0d7c8e73c7390608f7f818ee68aa0 The driver forgets to destroy workqueue in remove() similarly to what is done when probe() fails. Add a call to destroy_workqueue() to fix it. Since unregistration will wait for the work to finish, we do not need to cancel/flush the work instance in remove(). Signed-off-by: Chuhong Yuan <hslester96@gmail.com> Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/20191114023405.31477-1-hslester96@gmail.com Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com> 
The driver forgets to destroy workqueue in remove() similarly to what is
done when probe() fails. Add a call to destroy_workqueue() to fix it.

Since unregistration will wait for the work to finish, we do not need to
cancel/flush the work instance in remove().

Signed-off-by: Chuhong Yuan <hslester96@gmail.com>
Cc: stable@vger.kernel.org
Link: https://lore.kernel.org/r/20191114023405.31477-1-hslester96@gmail.com
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Input: synaptics-rmi4 - clear IRQ enables for F54 2019-11-13T00:49:22+00:00 Lucas Stach l.stach@pengutronix.de 2019-11-13T00:47:08+00:00 549766ac2ac1f6c8bb85906bbcea759541bb19a2 The driver for F54 just polls the status and doesn't even have a IRQ handler registered. Make sure to disable all F54 IRQs, so we don't crash the kernel on a nonexistent handler. Signed-off-by: Lucas Stach <l.stach@pengutronix.de> Link: https://lore.kernel.org/r/20191105114402.6009-1-l.stach@pengutronix.de Cc: stable@vger.kernel.org Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com> 
The driver for F54 just polls the status and doesn't even have a IRQ
handler registered. Make sure to disable all F54 IRQs, so we don't crash
the kernel on a nonexistent handler.

Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
Link: https://lore.kernel.org/r/20191105114402.6009-1-l.stach@pengutronix.de
Cc: stable@vger.kernel.org
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Input: synaptics-rmi4 - simplify data read in rmi_f54_work 2019-11-05T00:12:52+00:00 Lucas Stach l.stach@pengutronix.de 2019-11-04T23:59:38+00:00 d843304b22e84b41dd00663a13cb960d2f4d064d The body of the for loop is only ever run once as the second standard_report element is never changed from its initial zero init, so the loop condition is never satisfies after the first run. Equally the start member of the first element is never changed from 0, so the index offset is always a constant 0. Remove this needless obfuscation of the code and write it in a straight forward manner. Signed-off-by: Lucas Stach <l.stach@pengutronix.de> Link: https://lore.kernel.org/r/20191104114454.10500-3-l.stach@pengutronix.de Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com> 
The body of the for loop is only ever run once as the second standard_report
element is never changed from its initial zero init, so the loop condition is
never satisfies after the first run. Equally the start member of the first
element is never changed from 0, so the index offset is always a constant 0.

Remove this needless obfuscation of the code and write it in a straight
forward manner.

Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
Link: https://lore.kernel.org/r/20191104114454.10500-3-l.stach@pengutronix.de
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Input: synaptics-rmi4 - remove unused result_bits mask 2019-11-05T00:11:51+00:00 Andrew Duggan aduggan@synaptics.com 2019-11-05T00:09:22+00:00 310ca2a61c410b161ae64fd19a3475500ef9eafb The result_bits mask is no longer used by the driver and should be removed. Signed-off-by: Andrew Duggan <aduggan@synaptics.com> Link: https://lore.kernel.org/r/20191025002527.3189-4-aduggan@synaptics.com Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com> 
The result_bits mask is no longer used by the driver and should be
removed.

Signed-off-by: Andrew Duggan <aduggan@synaptics.com>
Link: https://lore.kernel.org/r/20191025002527.3189-4-aduggan@synaptics.com
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Input: synaptics-rmi4 - do not consume more data than we have (F11, F12) 2019-11-05T00:11:50+00:00 Andrew Duggan aduggan@synaptics.com 2019-11-05T00:07:30+00:00 5d40d95e7e64756cc30606c2ba169271704d47cb Currently, rmi_f11_attention() and rmi_f12_attention() functions update the attn_data data pointer and size based on the size of the expected size of the attention data. However, if the actual valid data in the attn buffer is less then the expected value then the updated data pointer will point to memory beyond the end of the attn buffer. Using the calculated valid_bytes instead will prevent this from happening. Signed-off-by: Andrew Duggan <aduggan@synaptics.com> Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/20191025002527.3189-3-aduggan@synaptics.com Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com> 
Currently, rmi_f11_attention() and rmi_f12_attention() functions update
the attn_data data pointer and size based on the size of the expected
size of the attention data. However, if the actual valid data in the
attn buffer is less then the expected value then the updated data
pointer will point to memory beyond the end of the attn buffer. Using
the calculated valid_bytes instead will prevent this from happening.

Signed-off-by: Andrew Duggan <aduggan@synaptics.com>
Cc: stable@vger.kernel.org
Link: https://lore.kernel.org/r/20191025002527.3189-3-aduggan@synaptics.com
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>