Many of the Elantech devices are connected through PS/2 and a different
bus (SMBus or plain I2C).
To not break any existing device, we only enable SMBus based
on a module parameter. If some laptops require the quirk to
be set, we will have to rely on a list of PNPIds or MDI matching
to individually expose those hardware over SMBus.
the parameter mentioned above is elantech_smbus from the psmouse
module.
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Acked-by: KT Liao <kt.liao@emc.com.tw>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
The command ETP_RESOLUTION_QUERY also contains the bus information.
It is better to fetch it once, while we are querying for device
information.
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Acked-by: KT Liao <kt.liao@emc.com.tw>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
In preparation for SMBus 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.
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Acked-by: KT Liao <kt.liao@emc.com.tw>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
The Elan touchpads over I2C/SMBus also can handle a trackstick.
Unfortunately, nothing tells us if the device supports trackstick (the
information lies in the PS/2 node), so rely on device properties to
determine whether to enable the trackstick node.
Link: https://bugzilla.redhat.com/show_bug.cgi?id=1313939
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Acked-by: Rob Herring <robh@kernel.org>
Acked-by: KT Liao <kt.liao@emc.com.tw>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Allow querying of the firmware revision of the device
example:
4.10
Tested on ZII RDU2 platform and on Intel x86_64 PC.
Signed-off-by: Nick Dyer <nick@shmanahar.org>
Tested-by: Nikita Yushchenko <nikita.yoush@cogentembedded.com>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Change hardcoded string "input_set_capability" in pr_err() function call,
replace it with "%s" __func__ instead.
Signed-off-by: Nick Simonov <nicksimonovv@gmail.com>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
The ChipOne icn8505 is an i2c capacitive touchscreen controller typically
used in cheap x86 tablets, this commit adds a driver for it.
Note the icn8505 is somewhat similar to the icn8318 and I started with
modifying that driver to support both, but in the end the differences were
too large and I decided to write a new driver instead.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
input_set_capability() and input_set_abs_param() will do it for you.
Signed-off-by: Marcus Folkesson <marcus.folkesson@gmail.com>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
input_set_capability() and input_set_abs_param() will do it for you.
Signed-off-by: Marcus Folkesson <marcus.folkesson@gmail.com>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
input_set_capability() and input_set_abs_param() will do it for you.
Signed-off-by: Marcus Folkesson <marcus.folkesson@gmail.com>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Fix some coding style issues reported by checkpatch.pl. Mostly brackets
in macros, spacing and comment style.
Signed-off-by: Leo Sperling <leosperling97@gmail.com>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Remove cite "Not sure what this does, but it is absolutely essential".
Extract initialization of trackstick part when touchpad is in passthrough
mode for v3 and v6 protocols into own function. Initialization for v3 is:
setscale11, setscale11, setscale11, nibble 0x9, nibble 0x4. Initialization
for v6 is: setscale11, setscale11, setscale11, setrate 0xC8, setrate 0x14.
Nibbles 0x9 and 0x4 for v3 protocol correspond to setrate 0xC8 and 0x14,
therefore these sequences are same.
When touchpad is in passthrough mode, then OS communicates with trackstick
and this sequence is some magic vendor PS/2 command to put trackstick into
"extended" mode. After that sequence trackstick starts reporting packets in
some vendor 4 bytes format (first byte is always 0xE8).
Next step after configuring trackstick to be in "extended" mode, is to
configure touchpad for v3 protocol to expect that trackstick reports data
in "extended" mode. For v3 protocol this is done by setting bit 1 in
register 0xC2C8 (offset 0x08 from base address 0xC2C0).
When both touchpad and trackstick are not configured for "extended" mode
then touchpad reports trackstick packets in different format, which is not
supported by psmouse/alps driver (yet).
In Cirque documentation GP-AN- 130823 INTERFACING TO GEN4 OVER I2C (PDF)
available at http://www.cirque.com/gen4-dev-resources is Logical Address
0xC2C8 named as PS2AuxControl and Bit Number 1 as ProcessAuxExtendedData
with description: Auxiliary device data is assumed to be extended data when
set.
Signed-off-by: Pali Rohár <pali.rohar@gmail.com>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Now that there are no users of custom Atmel platform data, and everyone
has switched to the generic device properties, we can remove support for
the platform data.
Acked-by: Nick Dyer <nick@shmanahar.org>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Signed-off-by: Benson Leung <bleung@chromium.org>
Move older ChromeOS devices describing Atmel controllers in ACPI, but not
providing enough details to configure the controllers properly, from
platform data over to generic device properties. This will allow us
remove support for platform data later on, leaving only generic device
properties in place.
Acked-by: Nick Dyer <nick@shmanahar.org>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Signed-off-by: Benson Leung <bleung@chromium.org>
Instead of using OF-specific APIs to fecth device properties, let's switch
to generic device properties API. This will allow us to use device
properties on legacy ChromeOS devices and get rid of platform data down
the road.
Acked-by: Nick Dyer <nick@shmanahar.org>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Signed-off-by: Benson Leung <bleung@chromium.org>
The way we are supposed to put controller to sleep and wake it up does not
depend on the platform, but rather on controller itself, so we want to get
rid of suspend mode in platform data (and eventually get rid of platform
data completely). Unfortunately some early chromebooks (the original Pixel,
Acer C720) were shipped with config that requires manually re-enabling
touch reporting in T9. We will sort it out, but in the meantime let's
switch to a simple DMI quirk.
We'll keep pdata->suspend_mode for now and remove it when we rework
chromeos-laptop driver.
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Signed-off-by: Benson Leung <bleung@chromium.org>
The touch sensor buttons on Sony VAIO VGN-CS series laptops (e.g.
VGN-CS31S) are a separate PS/2 device. As the MUX is disabled for all
VAIO machines by the nomux blacklist, the data from touch sensor
buttons and touchpad are combined. The protocol used by the buttons is
probably similar to the touchpad protocol (both are Synaptics) so both
devices get enabled. The controller combines the data, creating a mess
which results in random button clicks, touchpad stopping working and
lost sync error messages:
psmouse serio1: TouchPad at isa0060/serio1/input0 lost sync at byte 4
psmouse serio1: TouchPad at isa0060/serio1/input0 lost sync at byte 1
psmouse serio1: TouchPad at isa0060/serio1/input0 lost sync at byte 1
psmouse serio1: TouchPad at isa0060/serio1/input0 lost sync at byte 1
psmouse serio1: TouchPad at isa0060/serio1/input0 lost sync at byte 1
psmouse serio1: issuing reconnect request
Add a new i8042_dmi_forcemux_table whitelist with VGN-CS.
With MUX enabled, touch sensor buttons are detected as separate device
(and left disabled as there's currently no driver), fixing all touchpad
problems.
Signed-off-by: Ondrej Zary <linux@rainbow-software.org>
Cc: stable@vger.kernel.org
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Because I will be leaving Samsung soon, for reachability update
my reference e-mail to etezian.org.
Signed-off-by: Andi Shyti <andi.shyti@samsung.com>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Executing stmfts_power_on() function lasts over 2 seconds, what
significantly slows down the boot and resume processes if driver is
compiled in. Avoid this delay by forcing this driver to be probed
and suspended/resumed asynchronously.
Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
ALPS v3 and v7 packet formats reports trackstick pressure. This information
is already parsed in unused "z" variable.
ALPS SS4 S2 devices already reports trackstick pressure as ABS_PRESSURE
attribute, therefore reports pressure in the same way also for v3 and v7.
This patch also updates parsing v3 pressure information, it is also stored
in 7 bits.
Signed-off-by: Pali Rohár <pali.rohar@gmail.com>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
This driver let you plug in your RC controller to the adapter and
use it as input device in various RC simulators.
Signed-off-by: Marcus Folkesson <marcus.folkesson@gmail.com>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
If the device is unused and suspended, a call to open will cause the
device to autoresume through the call to usb_autopm_get_interface().
input_dev->users is already incremented by the input subsystem,
therefore this expression will always be evaluated to true:
if (input->users || usbtouch->type->irq_always)
result = usb_submit_urb(usbtouch->irq, GFP_NOIO);
The same URB will then be fail when resubmitted in usbtouch_open().
Introduce usbtouch->is_open to keep track of the state instead.
Signed-off-by: Marcus Folkesson <marcus.folkesson@gmail.com>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
usb_autopm_get_interface() that is called in usbtouch_open() does an
autoresume if the device is suspended.
input_dev->mutex used in usbtouch_resume() is in this case already
taken by the input subsystem and will cause a deadlock.
Signed-off-by: Marcus Folkesson <marcus.folkesson@gmail.com>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
If the device is unused and suspended, a call to open will cause the
device to autoresume through the call to usb_autopm_get_interface().
input_dev->users is already incremented by the input subsystem,
therefore this expression will always be evaluated to true:
if (pegasus->dev->users && usb_submit_urb(pegasus->irq, GFP_NOIO) < 0)
retval = -EIO;
The same URB will then be fail when resubmitted in pegasus_open().
Introduce pegasus->is_open to keep track of the state instead.
Signed-off-by: Marcus Folkesson <marcus.folkesson@gmail.com>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
usb_autopm_get_interface() that is called in pegasus_open() does an
autoresume if the device is suspended.
input_dev->mutex used in pegasus_resume() is in this case already
taken by the input subsystem and will cause a deadlock.
Signed-off-by: Marcus Folkesson <marcus.folkesson@gmail.com>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
If the device is unused and suspended, a call to open will cause the
device to autoresume through the call to usb_autopm_get_interface().
input_dev->users is already incremented by the input subsystem,
therefore this expression will always be evaluated to true:
if ((input_dev->users || (synusb->flags & SYNUSB_IO_ALWAYS)) &&
usb_submit_urb(synusb->urb, GFP_NOIO) < 0) {
retval = -EIO;
}
The same URB will then be fail when resubmitted in synusb_open().
Introduce synusb->is_open to keep track of the state instead.
Signed-off-by: Marcus Folkesson <marcus.folkesson@gmail.com>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
usb_autopm_get_interface() that is called in synusb_open() does an
autoresume if the device is suspended.
input_dev->mutex used in synusb_resume() is in this case already
taken by the input subsystem and will cause a deadlock.
Signed-off-by: Marcus Folkesson <marcus.folkesson@gmail.com>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Add support for specifying event actions to trigger wakeup when using
the gpio-keys input device as a wakeup source.
This would allow the device to configure when to wakeup the system. For
example a gpio-keys input device for pen insert, may only want to wakeup
the system when ejecting the pen.
Suggested-by: Brian Norris <briannorris@chromium.org>
Signed-off-by: Jeffy Chen <jeffy.chen@rock-chips.com>
Reviewed-by: Rob Herring <robh@kernel.org>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Assign true or false to boolean variables instead of an integer value.
This issue was detected with the help of Coccinelle.
Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
-----BEGIN PGP SIGNATURE-----
iQFSBAABCAA8FiEEq68RxlopcLEwq+PEeb4+QwBBGIYFAlqceRweHHRvcnZhbGRz
QGxpbnV4LWZvdW5kYXRpb24ub3JnAAoJEHm+PkMAQRiG59gH/0CVX4x6EobO/PQu
CzLVtAoRGFuIghB6Gmbx3Q1Ck4sn4q2SqUKTtkf03yauRGvnJsEmd6wEZ8f2IOHy
f30nX9s+4irzpQUIum4rH9KP6SMVJfNXlSVSisnamA6MbhPre3/NRcAIBUxdE4cK
lP81TaT6Nvp5cOySlPjPdWSbN4B1froFQ6rZ/lvG406QzqCvKvlS39h6IYjOF7Ds
zB/h3RkyuK9YyxFUO338RTEQ583esc0jTiTN4Pzb6nH3x8aTawDqGrwI2B4mkTLw
vNSPPE2VW9to0cZX+J7TH+uusPNXIlHZCD9tXwqWe5M+sCrE2FuydnmpZIf1A2LY
aWs0KQs=
=4nyn
-----END PGP SIGNATURE-----
Merge tag 'v4.16-rc4' into next
Sync up with mainline to bring in RAVE MFD device core.
Pull input fixes from Dmitry Torokhov:
- we are reverting patch that was switched touchpad on Lenovo T460P
over to native RMI because on these boxes BIOS messes up with SMBus
controller state. We might re-enable it later once SMBus issue is
resolved
- disabling interrupts in matrix_keypad driver was racy
- mms114 now has SPDX header and matching MODULE_LICENSE
* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/dtor/input:
Revert "Input: synaptics - Lenovo Thinkpad T460p devices should use RMI"
Input: matrix_keypad - fix race when disabling interrupts
Input: mms114 - add SPDX identifier
Input: mms114 - fix license module information
This reverts commit 4828296982 which
caused the following issues:
1. On T460p with BIOS version 2.22 touchpad and trackpoint stop working
after suspend-resume cycle. Due to strange state of the device another
suspend is impossible.
The following dmesg errors can be observed:
thinkpad_acpi: EC reports that Thermal Table has changed
rmi4_smbus 7-002c: failed to get SMBus version number!
rmi4_physical rmi4-00: rmi_driver_reset_handler: Failed to read current IRQ mask.
rmi4_f01 rmi4-00.fn01: Failed to restore normal operation: -16.
rmi4_f01 rmi4-00.fn01: Resume failed with code -16.
rmi4_physical rmi4-00: Failed to suspend functions: -16
rmi4_smbus 7-002c: Failed to resume device: -16
PM: resume devices took 0.640 seconds
rmi4_f03 rmi4-00.fn03: rmi_f03_pt_write: Failed to write to F03 TX register (-16).
rmi4_physical rmi4-00: rmi_driver_clear_irq_bits: Failed to change enabled interrupts!
rmi4_physical rmi4-00: rmi_driver_set_irq_bits: Failed to change enabled interrupts!
psmouse: probe of serio3 failed with error -1
2. On another T460p with BIOS version 2.15 two finger scrolling gesture
on the touchpad stops working after suspend-resume cycle (about 75%
reproducibility, when it still works, the scrolling gesture becomes
laggy). Nothing suspicious appears in the dmesg.
Analysis form Richard Schütz:
"RMI is unreliable on the ThinkPad T460p because the device is affected
by the firmware behavior addressed in a7ae81952c ("i2c: i801: Allow
ACPI SystemIO OpRegion to conflict with PCI BAR")."
The affected devices often show:
i801_smbus 0000:00:1f.4: BIOS is accessing SMBus registers
i801_smbus 0000:00:1f.4: Driver SMBus register access inhibited
Reported-by: Richard Schütz <rschuetz@uni-koblenz.de>
Signed-off-by: Arkadiusz Hiler <arkadiusz.hiler@intel.com>
Tested-by: Martin Peres <martin.peres@linux.intel.com>
Tested-by: Arkadiusz Hiler <arkadiusz.hiler@intel.com>
Cc: stable@vger.kernel.org
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
This is the mindless scripted replacement of kernel use of POLL*
variables as described by Al, done by this script:
for V in IN OUT PRI ERR RDNORM RDBAND WRNORM WRBAND HUP RDHUP NVAL MSG; do
L=`git grep -l -w POLL$V | grep -v '^t' | grep -v /um/ | grep -v '^sa' | grep -v '/poll.h$'|grep -v '^D'`
for f in $L; do sed -i "-es/^\([^\"]*\)\(\<POLL$V\>\)/\\1E\\2/" $f; done
done
with de-mangling cleanups yet to come.
NOTE! On almost all architectures, the EPOLL* constants have the same
values as the POLL* constants do. But they keyword here is "almost".
For various bad reasons they aren't the same, and epoll() doesn't
actually work quite correctly in some cases due to this on Sparc et al.
The next patch from Al will sort out the final differences, and we
should be all done.
Scripted-by: Al Viro <viro@zeniv.linux.org.uk>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
If matrix_keypad_stop() is executing and the keypad interrupt is triggered,
disable_row_irqs() may be called by both matrix_keypad_interrupt() and
matrix_keypad_stop() at the same time, causing interrupts to be disabled
twice and the keypad being "stuck" after resuming.
Take lock when setting keypad->stopped to ensure that ISR will not race
with matrix_keypad_stop() disabling interrupts.
Signed-off-by: Zhang Bo <zbsdta@126.com>
Cc: stable@vger.kernel.org
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
We do not need to call ps2_command() several times in a row, transmitting
every byte as it were a command byte, we can often pack it all in a single
command.
Also, now that ps2_command() handles retransmission, we do not need to do
it ourselves in trackpoint_power_on_reset().
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
When we probe PS/2 devices we first issue "Get ID" command and only if we
receive what we consider a valid keyboard or mouse ID we disable the device
and continue with protocol detection. That means that the device may be
transmitting motion or keystroke data, while we expect ACK response.
Instead of signaling failure if we see anything but ACK/NAK let's ignore
"garbage" response until we see ACK for the command byte (first byte). The
checks for subsequent ACKs of command parameters will continue be strict.
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
The devices are allowed to respond to either command byte or command
parameter with a NAK (0xfe), and the host is supposed to resend the
"correct" byte. The device then will either respond with ACK or ERR (0xfc).
Let's teach libps2 to handle the NAK responses properly, so that individual
drivers do not need to handle them.
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Debugging via i8042.debug and analyzing raw PS/2 data stream may be
cumbersome as you need to locate the boundaries of commands, decipher the
sliced commands, etc, etc. Let's add a bit more high level debug statements
for ps2_sendbyte(), ps2_command(), and ps2_sliced_command().
We do not introduce a new module parameter, but rater rely on the kernel
having dynamic debug facility enabled (which most everyone has nowadays).
Enable with:
echo "file libps2.c +pf" > /sys/kernel/debug/dynamic_debug/control
or add "libps2.dyndbg=+pf" to the kernel command line.
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
In preparation to adding some debugging statements to PS/2 control
sequences let's move psmouse_sliced_command() into libps2 and rename it
to ps2_sliced_command().
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Instead of using unsigned char for the byte data switch to using u8. Also
use unsigned int for the command codes and timeouts, and have
ps2_handle_ack() and ps2_handle_response() return bool instead of int, as
they do not return error codes but rather signal whether a byte was handled
or not handled. ps2_is_keyboard_id() now returns bool as well.
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Individual labels of switch statements should have the same indentation
level as the switch statement itself.
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
This Far-Eastern company's PS/2 mice use a deviant format for the data
relating to movement of the scroll wheels for, at least, their dual wheel
mice, such as their "Optical GreatEye Wheelmouse" model "WOP-35". This
product has five "buttons" (one of which is the click action on the first
wheel) and TWO scroll wheels. However for a byte comprising d0-d7 instead
of setting one of d6-7 in the forth byte of the mouse data packet and a
twos complement number of scroll steps in the remaining d5-d0 (or d3-d0
should there be a fourth (BTN_SIDE - d4) or fifth (BTN_EXTRA - d5) button
to report; they only report a single +/- event for each wheel and use a bit
pattern that corresponds to +/-1 for the first wheel and +/- 2 for the
second in the lower nibble of the fourth byte.
The effect with existing code is that the second mouse wheel merely repeats
the effect of the first but providing two steps per click rather than the
one of the first wheel - so there is no HORIZONTAL scroll wheel movement
detected from the device as far as the rest of the kernel sees it.
This patch, if enabled by the "a4tech_workaround" module parameter modifies
the handling just for mice of type PSMOUSE_IMEX so that the second scroll
wheel movement gets correctly reported as REL_HWHEEL events. Should this
module parameter be activated for other mice of the same PSMOUSE_IMEX type
then it is possible that at the point where the mouse reports more than a
single movement step the user may start seeing horizontal rather than
vertical wheel events, but should the movement steps get to be more than
two at a time the hack will get immediately deactivated and the behaviour
will revert to the past code.
This was discussed around *fifteen* *years* *ago* on the LKML and the best
summary is in post https://lkml.org/lkml/2002/7/18/111 "Re: PS2 Input Core
Support" by Vojtech Pavlik. I was not able to locate any discussion later
than this on this topic.
Given that most users of the "psmouse" module will NOT want this additional
feature enabled I have taken the apparently erroneous step of defaulting
the module parameter that enables it to be "disabled" - this functionality
may interfere with the operation of "normal" mice of this type (until a
large enough scroll wheel movement is detected) so I cannot see how it
would want to be enabled for "normal" users - i.e. everyone without this
brand of mouse.
I am using this patch at the moment and I can confirm that it is working
for me as both a module and compiled into the kernel for my mouse that is
of the type (WOP-35) described - I note that it is still available from
certain on-line retailers and that the manufacturers site does not list
GNU/Linux as being supported on the product page - this patch however does
enable full use of this product:
http://www.a4tech.com/product.asp?cid=3D1&scid=3D8&id=3D22
Signed-off-by: Stephen Lyons <slysven@virginmedia.com>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
- use u8 instead of unsigned char for byte data
- use input_set_capability() instead of manipulating capabilities bits
directly
- do not abuse -1 as error code, propagate errors from various calls.
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
- switch to using BIT() macros
- use u8 instead of unsigned char for byte data
- use input_set_capability() instead of manipulating capabilities bits
directly
- use sign_extend32() when extracting wheel data.
- do not abuse -1 as error code, propagate errors from various calls.
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
