Expose model and fw_version via sysfs. Also query the model
in probe to make sure, that the I2C communication with the
device works before successfully probing the driver.
This is a bit complicated, since EETI devices do not have
a sync interface. Sending the commands and directly reading
does not work. Sending the command and waiting for some time
is also not an option, since there might be touch events in
the mean time.
Last but not least we do not cache the results, since this
interface can be used to check the I2C communication is still
working as expected.
Reviewed-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
Link: https://lore.kernel.org/r/20200805160520.456570-5-sebastian.reichel@collabora.com
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Currently the assignment of -ENOMEM to error is redundant because error
is not being read and -ENOMEM is being hard coded as an error return.
Fix this by returning the error code in variable 'error'; this also
allows the error code from a failed call to input_register_device to
be preserved and returned to the caller rather than just returning
a possibly inappropriate -ENOMEM.
Kudos to Dan Carpenter for the suggestion of an improved fix.
Addresses-Coverity: ("Unused value")
Signed-off-by: Colin Ian King <colin.king@canonical.com>
Reviewed-by: Dan Carpenter <dan.carpenter@oracle.com>
Link: https://lore.kernel.org/r/20200603152151.139337-1-colin.king@canonical.com
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
The workaround of reading all messages until an invalid is received is a
way of forcing the CHG line high, which means that when using
edge-triggered interrupts the interrupt can be acquired.
With level-triggered interrupts the workaround is unnecessary.
Also, most recent maXTouch chips have a feature called RETRIGEN which, when
enabled, reasserts the interrupt line every cycle if there are messages
waiting. This also makes the workaround unnecessary.
Note: the RETRIGEN feature is only in some firmware versions/chips, it's
not valid simply to enable the bit.
Signed-off-by: Nick Dyer <nick.dyer@itdev.co.uk>
Acked-by: Benson Leung <bleung@chromium.org>
Acked-by: Yufeng Shen <miletus@chromium.org>
(cherry picked from ndyer/linux/for-upstream commit 1ae4e8281e491b22442cd5acdfca1862555f8ecb)
[gdavis: Fix conflicts due to v4.6-rc7 commit eb43335c40 ("Input:
atmel_mxt_ts - use mxt_acquire_irq in mxt_soft_reset").]
Signed-off-by: George G. Davis <george_davis@mentor.com>
[jiada: reset use_retrigen_workaround at beginning of mxt_check_retrigen()
call mxt_check_retrigen() after mxt_acquire_irq() in mxt_initialize()
replace white-spaces with tab for MXT_COMMS_RETRIGEN
Changed to check if IRQ is level type]
Signed-off-by: Jiada Wang <jiada_wang@mentor.com>
Link: https://lore.kernel.org/r/20200727151637.23810-1-jiada_wang@mentor.com
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Newer controllers (identified as "pattern" version 2) send higher
resolution reports, with 16-bit X and Y coordinates (previous generations
used 12-bit values). These new high resolution reports use report ID of
0x60.
SMbus controllers use the same buffer size for both the new and old
reports, and because of that high resolution reports no longer carry
area of contact data with SMbus.
Signed-off-by: Jingle Wu <jingle.wu@emc.com.tw>
Link: https://lore.kernel.org/r/20200710054116.5529-1-jingle.wu@emc.com.tw
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
We do not need to constantly re-query pattern ID, we can instead query it
once and then pass to methods that need it.
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
This adds firmware size and page sizes for ic types 0x11, 0x13 and 0x14.
IC 0x14 uses 512-byte firmware page size.
Signed-off-by: Jingle Wu <jingle.wu@emc.com.tw>.
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Newer ICs with IC type value starting with 0x0D and newer bootloader code
use 128-byte firmware pages. Their bootloader also needs to be switched to
proper mode before executing firmware update.
Signed-off-by: Jingle Wu <jingle.wu@emc.com.tw>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Extend fetching and parsing parameters of the controllers to devices with
"patterns" above 1 (which currently should be handled in the same fashion
as devices with pattern 1).
Signed-off-by: Jingle Wu <jingle.wu@emc.com.tw>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
On older controllers IC type is reported in the 2nd byte of
ETP_I2C_OSM_VERSION_CMD, however if controller's firmware is not flashed
correctly it may return incorrect data. Fortunately there is also
ETP_I2C_IAP_VERSION_P0_CMD command that can be used when controller in
either normal or IAP mode, and which is guaranteed to return accurate data,
so let's use it.
Signed-off-by: Jingle Wu <jingle.wu@emc.com.tw>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Not all versions of firmware implement "get pattern" command. When
encountering those assume that the controllers use older pattern.
Signed-off-by: Jingle Wu <jingle.wu@emc.com.tw>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Making module name conflicts a fatal error breaks sparc64 allmodconfig:
Error log:
error: the following would cause module name conflict:
drivers/char/adi.ko
drivers/input/joystick/adi.ko
Renaming one of the modules would solve the problem, but then cause other
problems because neither of them is automatically loaded and changing
the name is likely to break any setup that relies on manually loading
it by name.
As there is probably no sparc64 system with this kind of ancient joystick
attached, work around it by adding a Kconfig dependency that forbids
them from both being modules. It is still possible to build the joystick
driver if the sparc64 adi driver is built-in.
Reported-by: Guenter Roeck <linux@roeck-us.net>
Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Reviewed-by: Guenter Roeck <linux@roeck-us.net>
Link: https://lore.kernel.org/r/20200609100643.1245061-1-arnd@arndb.de
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
This adds a new driver for the Cypress CY8CTMA140 touchscreen.
This driver is inspired by out-of-tree code for the Samsung
GT-S7710 mobile phone.
I have tried to compare the structure and behaviour of this
touchscreen to the existing CYTTSP and CYTTSP4 generics and
it seems pretty different. It is also different in character
from the cy8ctmg110_ts.c. It appears to rather be vaguely
related to the Melfas MMS114 driver, yet distinctly
different.
Dmitry Torokhov rewrote the key scanning code during the
submission process so the driver is a joint work.
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Link: https://lore.kernel.org/r/20200506123435.187432-2-linus.walleij@linaro.org
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
The current codebase makes use of the zero-length array language
extension to the C90 standard, but the preferred mechanism to declare
variable-length types such as these ones is a flexible array member[1][2],
introduced in C99:
struct foo {
int stuff;
struct boo array[];
};
By making use of the mechanism above, we will get a compiler warning
in case the flexible array does not occur last in the structure, which
will help us prevent some kind of undefined behavior bugs from being
inadvertently introduced[3] to the codebase from now on.
Also, notice that, dynamic memory allocations won't be affected by
this change:
"Flexible array members have incomplete type, and so the sizeof operator
may not be applied. As a quirk of the original implementation of
zero-length arrays, sizeof evaluates to zero."[1]
sizeof(flexible-array-member) triggers a warning because flexible array
members have incomplete type[1]. There are some instances of code in
which the sizeof operator is being incorrectly/erroneously applied to
zero-length arrays and the result is zero. Such instances may be hiding
some bugs. So, this work (flexible-array member conversions) will also
help to get completely rid of those sorts of issues.
This issue was found with the help of Coccinelle.
[1] https://gcc.gnu.org/onlinedocs/gcc/Zero-Length.html
[2] https://github.com/KSPP/linux/issues/21
[3] commit 7649773293 ("cxgb3/l2t: Fix undefined behaviour")
Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org>
Link: https://lore.kernel.org/r/20200507185347.GA14499@embeddedor
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
