On resume from suspend there is a possibility for multi-byte scancodes
to be handled incorrectly. atkbd_reconnect disables the processing of
scancodes in software by calling atkbd_disable, but the keyboard may
still be active because no disconnect command was sent. Later, software
handling is re-enabled. If a multi-byte scancode sent from the keyboard
straddles the re-enable, only the latter byte(s) will be handled.

In practice, this leads to cases where multi-byte break codes (ex. "e0
4d" - break code for right-arrow) are misread as make codes ("4d" - make
code for numeric 6), leading to one or more unwanted, untyped characters
being interpreted.

The solution implemented here involves sending command f5 (reset
disable) to the keyboard prior to disabling software handling of codes.
Later, the command to re-enable the keyboard is sent only after we are
prepared to handle scancodes.

Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>

Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>

I believe that "trying to access hardware" is more correct English
than "trying access hardware".

Signed-off-by: Jesper Juhl <jj@chaosbits.net>
Signed-off-by: Dmitry Torokhov <dtor@mail.ru>

With commit 67d0a0754455f89ef3946946159d8ec9e45ce33a we mark strict_strtox
as obsolete. Convert all remaining such uses in drivers/input/.

Also change long to appropriate types, and return error conditions
from kstrtox separately, as Dmitry sugguests.

Signed-off-by: JJ Ding <dgdunix@gmail.com>
Signed-off-by: Dmitry Torokhov <dtor@mail.ru>

We only care about if there is a successful match from the table (or
no match at all), so let's make dmi_check_system return immediately
instead of iterating thorough the whole table.

Make the dmi callback function return 1 then dmi_check_system
will return immediately if we have a successful match.

Signed-off-by: Axel Lin <axel.lin@gmail.com>
Signed-off-by: Dmitry Torokhov <dtor@mail.ru>

Many of the IBM Terminal keyboards from the 1980s and early 1990s communicate
using a protocol similar, but not identical to the AT keyboard protocol.
(Models known to be like this include 6110344, 6110668, 1390876, 1386887, and
possibly others.)

When the connector is rewired or adapter to an AT-DIN or PS/2 connector, they
can be connected to a standard PC, with three caveats:

a) They can only use scancode set 3; requests to use anything else are
quietly ignored.
b) The AT Command to request Make, Break and Repeat codes is not properly
interpreted.
c) The top function keys on a 122 key keyboard, and the arrow/edit keys in
the middle of the board send non-standard scancodes.

C) is easily taken care of in userspace, by use of setkeycodes
B) can be taken care of by a userspace hack (that makes the kernel complain
in dmesg)
A) is fixable in theory, but on the keyboard i tested on (6110668), it seems
to be detected unoverridably as Set 2, causing userspace oddities that make
it harder to fix C).

Enclosed is a small patch to the kernel that fixes A) and B) in the kernel,
making it much easier to fix C) in userspace. It adds a single kernel
command line parameter that overrides the detection that sets these boards
as set 2, and instead of sending the Make-break-repeat command to the
keyboard, it sends the make-break command, which is properly recognized by
these keyboards. Software level key repeating seems to make up for the lack
of hardware repeat codes perfectly.

Without manually setting the command line parameter (tentatively named
atkbd.terminal), this code has no effect, and the driver works exactly as
before.

See also:

http://www.seasip.info/VintagePC/ibm_1390876.html
http://www.seasip.info/VintagePC/ibm_6110344.html
http://geekhack.org/showwiki.php?title=Island:7306

Signed-off-by: Erika Quinn <erikas.aubade@gmail.com>
Signed-off-by: Benjamin LaHaise <bcrl@kvack.org>
Signed-off-by: Dmitry Torokhov <dtor@mail.ru>

Keycodes in 248 - 254 range were reserved for special needs (scrolling)
of atkbd driver. Now that the driver has been switched to use unsigned
short keycodes instead of unsigned char we can release this range back
into pull. We keep code 255 (ATKBD_KEY_NULL) reserved since users may
have been using it to silence keys they do not care about since atkbd
silently drops scancodes mapped to this keycode.

Signed-off-by: Dmitry Torokhov <dtor@mail.ru>

dev_err(), dev_warn() and dev_dbg() ensure consistency in driver messages.
Also switch to using bool where appropriate and fix some formatting issues.

Signed-off-by: Dmitry Torokhov <dtor@mail.ru>

We need to first unregister input device and only then cancel event work
since events can arrive (and cause event work to get scheduled again)
until input_unregister_device() returns.

Signed-off-by: Dmitry Torokhov <dtor@mail.ru>