When trying to destroy platform data after destruction of SMbus companion,
we need to make sure that we are actually dealing with an SMB companion
device, and not some random I2C client device.

Fixes: 8eb92e5c ("Input: psmouse - add support for SMBus companions")
Reported-by: NBenjamin Tissoires <benjamin.tissoires@redhat.com>
Tested-by: NBenjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>

This essentially reverts commit baf28d91 ("Input: bma150 - avoid
binding to bma180 if IIO bma180 driver present") and commit ef3714fd
("Input: bma150 - extend chip detection for bma180")

Rationale: initially (2012) the GTA04 device using a bma180 chip simply
referenced the bma150 platform driver in its board file [1] which happened
to work in all scenarios that were tested.

When conversion to DT started (2014), we needed to make the driver be still
recognised. Hence we introduced the compatibility to the bma180 chip in
Linux 3.15-rc5 [2] without further checks if it is really 100% compatible.
This worked flawlessly for years with the GTA04 device.

Recently (2016), Hans de Goede pointed out that the chips are not as
similar as they appeared and the driver works with the bma180 for the GTA04
only by good luck. He proposed to remove the bma180 support completely [3],
but we still did need it until we have a replacement. Thus, a conditional
compile was added.

We have now developed a generic iio-input-bridge which works with any 2 or
3 axis iio based accelerometer. It has been tested on GTA04 and Pyra and
works as expected. Therefore we can remove the bma180 support from this
driver completely. User-space API compatibility can be restored by using
the iio-input-bridge.

Maybe it is time to convert the bma150 driver to iio as well and retire the
accelerometer input drivers completely but this is a different story and
task.

[1]: https://github.com/neilbrown/linux/blob/gta04/3.2.y/arch/arm/mach-omap2/board-omap3gta04.c#L976
[2]: https://patchwork.kernel.org/patch/3961171/
[3]: https://patchwork.kernel.org/patch/9325481/Signed-off-by: NH. Nikolaus Schaller <hns@goldelico.com>
Reviewed-by: NHans de Goede <hdegoede@redhat.com>
Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>

Add missing documentation of max11801-ts dt-binding details.
Signed-off-by: NJagan Teki <jagan@amarulasolutions.com>
Acked-by: NRob Herring <robh@kernel.org>
Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>

Added missing of_match_table for max11801_ts driver with compatible as
"maxim,max11801_ts"
Signed-off-by: NJagan Teki <jagan@amarulasolutions.com>
Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>

The gpio-matrix-keypad driver normally sets inactive columns as inputs
while scanning. This does not work for all hardware, which may require
the inactive columns to be actively driven in order to overcome any
pull-ups/downs on the columns.
Signed-off-by: NDavid Rivshin <drivshin@allworx.com>
Acked-by: NRob Herring <robh@kernel.org>
Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>

Try a quick read from the device in mip4_query_device() to make sure
that the device is there, as we do not consider failures to retrieve
product name or resolution fatal.
Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>

Each time the HWMON devices are read (e.g. battery voltage) while the
touchscreen is held pressed, extra pen-up and pen-down events are
generated. This is fixed by avoiding the UP event when the touchscreen is
stopped.
Signed-off-by: NDavid Jander <david@protonic.nl>
Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>

Most of the Synaptics devices are connected through PS/2 and a different
bus (SMBus or HID over I2C). The secondary bus capability is indicated by
the InterTouch bit in extended capability 0x0C.

We only enable the InterTouch device to be created for the laptops
registered with the top software button property or those we know that are
functional. In the future, we might change the default to always rely on
the InterTouch bus. Currently, users can enable/disable the feature with
the psmouse parameter synaptics_intertouch.
Signed-off-by: NBenjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>

In preparation for SMBus/Intertouch 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.

Also stop using "unsigned long", everything fits into 32 bit chunks.
Reviewed-by: NBenjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>

This provides glue between PS/2 devices that enumerate the RMI4 devices
and Elan touchpads to the RMI4 (or Elan) SMBus driver.

The SMBus devices keep their PS/2 connection alive. If the initialization
process goes too far (psmouse_activate called), the device disconnects
from the I2C bus and stays on the PS/2 bus, that is why we explicitly
disable PS/2 device reporting (by calling psmouse_deactivate) before
trying to register SMBus companion device.

The HID over I2C devices are enumerated through the ACPI DSDT, and
their PS/2 device also exports the InterTouch bit in the extended
capability 0x0C. However, the firmware keeps its I2C connection open
even after going further in the PS/2 initialization. We don't need
to take extra precautions with those device, especially because they
block their PS/2 communication when HID over I2C is used.
Signed-off-by: NBenjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>

Prepare PS/2 mouse drivers to work with devices that are accessible both
via PS/2 and SMBus, which provides higher bandwidth, and thus suits better
for modern multi-touch devices.

We expect that SMBus drivers will take control over the device, so when
we detect SMBus "protocol" we forego registering input device, or enabling
PS/2 device reports (as it usually makes device unresponsive to access over
SMBus).
Reviewed-by: NBenjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>

Instead of storing only protocol "type" in pmsouse structure, store pointer
to the protocol structure, so that we have access to more data without
having to copy it over to psmouse structure.
Reviewed-by: NBenjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>

Make use of serio's fast reconnect option and allow psmouse protocol
handler's to implement fast reconnect handlers that will be called during
system resume.
Reviewed-by: NBenjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>

Devices connected to serio bus are quite slow, and to improve apparent
speed of resume process, serio core resumes (reconnects) its devices
asynchronously, by posting port reconnect requests to a workqueue.
Unfortunately this means that if there is a dependent device of a given
serio port (for example SMBus part of touchpad connected via both PS/2 and
SMBus), we do not have a good way of ensuring resume order.

This change allows drivers to define "fast reconnect" handlers that would
be called in-line during system resume. Drivers need to ensure that these
handlers are truly "fast".
Reviewed-by: NBenjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>

Let's stop using !!x to reduce value of trackstick button expression to 0/1
and use shift instead. This removes the following sparse warning:

  CHECK   drivers/input/mouse/synaptics.c
drivers/input/mouse/synaptics.c:943:79: warning: dubious: !x | y

Also, the bits we are testing are not capabilities, so lets drop "_CAP"
suffix from macro names.
Reviewed-by: NBenjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>

The driver doesn't have a struct of_device_id table but supported devices
are registered via Device Trees. This is working on the assumption that a
I2C device registered via OF will always match a legacy I2C device ID and
that the MODALIAS reported will always be of the form i2c:<device>.

But this could change in the future so the correct approach is to have an
OF device ID table if the devices are registered via OF.

The compatible strings don't have a vendor prefix because that's how it's
used currently, and changing this will be a Device Tree ABI break.
Signed-off-by: NJavier Martinez Canillas <javier@osg.samsung.com>
Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>

The driver doesn't have a struct of_device_id table but supported devices
are registered via Device Trees. This is working on the assumption that a
I2C device registered via OF will always match a legacy I2C device ID and
that the MODALIAS reported will always be of the form i2c:<device>.

But this could change in the future so the correct approach is to have an
OF device ID table if the devices are registered via OF.
Signed-off-by: NJavier Martinez Canillas <javier@osg.samsung.com>
Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>

The driver doesn't have a struct of_device_id table but supported devices
are registered via Device Trees. This is working on the assumption that a
I2C device registered via OF will always match a legacy I2C device ID and
that the MODALIAS reported will always be of the form i2c:<device>.

But this could change in the future so the correct approach is to have an
OF device ID table if the devices are registered via OF.

As pointed by Hans de Goede, there's no mssl1680 and this is just used in
some ACPI systems to identify the gsl1680 chip. So isn't included in the
OF device ID table since a DT should use the proper device name instead.
Signed-off-by: NJavier Martinez Canillas <javier@osg.samsung.com>
Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>

To enable eventual removal of pr_warning

This makes pr_warn use consistent for drivers/input

Prior to this patch, there were 8 uses of pr_warning and
17 uses of pr_warn in drivers/input
Signed-off-by: NJoe Perches <joe@perches.com>
Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>

Windows 10 tablets with gpio buttons will typically use the ACPI 6.0
Generic Button Device with a HID of ACPI0011 for these buttons.

The ACPI description for these in the ACPI0011 devices _DSD object uses
something resembling HID descriptors, except that instead of indicating
a bit index into a HID input report, the index indicates the _CRS index
for the GPIO.

The use of 1 interrupt per button, some of which need to be wakeup
sources, instead of using input reports makes it impossible to use the
HID subsystem for this.

This really is just another gpio-keys input device with the platform
data described in ACPI, so this commit adds parsing for this new way
to describe gpio-keys to the soc_button_array driver.
Signed-off-by: NHans de Goede <hdegoede@redhat.com>
Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>

Count how much gpio_keys we actually need, this is a preparation patch
for adding support for the new Win10 / ACPI-6.0 "Generic Buttons Device"
support.
Signed-off-by: NHans de Goede <hdegoede@redhat.com>
Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>

Update the code to use devm_* API so that driver core will manage
resources.
Signed-off-by: NYegor Yefremov <yegorslists@googlemail.com>
Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>

Using devm_* APIs simpifies error handling and device teardown.
Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>

Now that sparse keymap uses managed memory, we no longer need to clean it
up manually.
Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>

Now that sparse keymap uses managed memory, we no longer need to clean it
up manually.
Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>

This brings in version of sparse keymap code that uses managed memory.

The gpiolib-acpi code is becoming more strict and connection-IDs
may only be used with devices which have a _DSD with matching IDs
in there. Since the soc_button_array ACPI binding is pure index
based pass in NULL as connection-ID to avoid the more strict cheks
resulting in gpiod_count and gpiod_get_index not returning any gpios.
Signed-off-by: NHans de Goede <hdegoede@redhat.com>
Reviewed-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>

On some systems (Intel tablets with axp288 pmic) the powerbutton is
also connected to a gpio pin of the SoC, advertised through the
"INTCFD9" / "PNP0C40" acpi device. This leads to double reporting
of powerbutton events, which is undesirable, so one driver needs
to not report input events in this case.

Since the soc_button_array driver for the "PNP0C40" acpi device
also handles wake from suspend on these tablets and since the
axp20x-pel driver requires relative expensive i2c accrsses,
it is best for the axp20x-pek driver to not register an input device
in this case.

Note that this commit leaves the axp20x-driver bound to the
device, rather then returning -ENODEV, this is done so that the
sysfs attributes it offers are kept around.
Signed-off-by: NHans de Goede <hdegoede@redhat.com>
Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>

Move all input device related initialization into a new
axp20x_pek_probe_input_device helper function.

This introduces one functional change, the input device is now
registered before the sysfs attr get registered. This is not a problem
as the sysfs attr are to configure some long press settings (forced
poweroff) in the hardware and do not interact with the input_device.

This is a preparation patch for not always registering the input dev.
Signed-off-by: NHans de Goede <hdegoede@redhat.com>
Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>

Before this commit axp20x-pek was mixing 2 style error reporting calls:
dev_err(&pdev->dev, ...);
dev_err(axp20x->dev, ...);

But the second is our parent device, not our own device, so switch to
using &pdev->dev everywhere.
Signed-off-by: NHans de Goede <hdegoede@redhat.com>
Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>

As the driver is using generic device properties, it should work
properly when CONFIG_OF is turned off. This patch removes the
ifdef CONFIGOF and make sure the driver always have of_match_table.
Signed-off-by: NJingkui Wang <jkwang@google.com>
Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>

Some platform drivers use devm_input_allocate_device() together with
sparse_keymap_setup() in their .probe callbacks.  While using the former
simplifies error handling, using the latter necessitates calling
sparse_keymap_free() in the error path and upon module unloading to
avoid leaking the copy of the keymap allocated by sparse_keymap_setup().

To help prevent such leaks and enable simpler error handling, make
sparse_keymap_setup() use devm_kmemdup() to create the keymap copy so
that it gets automatically freed.

This works for both managed and non-managed input devices as the keymap
is freed after the last reference to the input device is dropped.

Note that actions previously taken by sparse_keymap_free(), i.e. taking
the input device's mutex and zeroing its keycode and keycodemax fields,
are now redundant because the managed keymap will always be freed after
the input device is unregistered.
Signed-off-by: NMichał Kępień <kernel@kempniu.pl>
Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>

Extend the pwm-beeper driver to support customized frequency for SND_BELL
from device properties.
Signed-off-by: NGuan Ben <ben.guan@cn.bosch.com>
Signed-off-by: NMark Jonas <mark.jonas@de.bosch.com>
Signed-off-by: NHeiko Schocher <hs@denx.de>
Acked-by: NRob Herring <robh@kernel.org>
Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>

Sort all devices in alps_model_data by signature and remove
command_mode_resp which is not used anymore.
Signed-off-by: NPali Rohár <pali.rohar@gmail.com>
Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>

Support for devices with ALPS_PROTO_V9 is not implemented yet but we can
detect these alps touchpads and warn users about it.
Signed-off-by: NPali Rohár <pali.rohar@gmail.com>
Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>

Like for other protocols create alps_v4_protocol_data and use it in
alps_identify() function.
Signed-off-by: NPali Rohár <pali.rohar@gmail.com>
Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>

Instead of manipulating capabilities bits of input device directly, let's
use input_set_capability() API.

Also, stop setting ABS_X/Y bits explicitly as input_set_abs_params() does
this for us.
Acked-by: NMichael Hennerich <michael.hennerich@analog.com>
Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>

We have switched the driver to use generic device properties API, so there
is no need to check for presence of DT node before trying parse properties.
Acked-by: NMichael Hennerich <michael.hennerich@analog.com>
Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>

With the switch to devm, there is no need for ad7879_probe() to return the
touchscreen structure, we can use plain error code. This also fixes issue
introduced with devm concersion, where we returned 0 on success (which
worked OK since IS_ERR(0) would not trigger, but was not correct
regardless).

Fixes: 381f688eee3d ("Input: ad7879 - use more devm interfaces")
Acked-by: NMichael Hennerich <michael.hennerich@analog.com>
Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>

The conversion to devm accidentally removed setting up of I2C client data
upon successful probe of the touchscreen. Let's move this setting into the
core, so we do not forger about it again.

Fixes: 381f688eee3d ("Input: ad7879 - use more devm interfaces")
Acked-by: NMichael Hennerich <michael.hennerich@analog.com>
Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>