A particular touchpad (SIPODEV SP1064) refuses to supply the HID
descriptors. This patch provides the framework for overriding these
descriptors based on DMI data. It also includes the descriptors for
said touchpad, which were extracted by listening to the traffic of the
windows filter driver, as well as the DMI data for the laptops known
to use this device.

Relevant Bug: https://bugzilla.redhat.com/show_bug.cgi?id=1526312

Cc: Hans de Goede <hdegoede@redhat.com>
Reported-and-tested-by: ahormann@gmx.net
Reported-and-tested-by: NBruno Jesus <bruno.fl.jesus@gmail.com>
Reported-and-tested-by: NDietrich <enaut.w@googlemail.com>
Reported-and-tested-by: kloxdami@yahoo.com
Signed-off-by: NJulian Sax <jsbc@gmx.de>
Reviewed-by: NBenjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

Commit 52cf93e6 ("HID: i2c-hid: Don't reset device upon system resume")
removes the need for the RESEND_REPORT_DESCR quirk for Raydium devices, but
kept it for the SIS device id 10FB touchscreens, as the author of that
commit could not determine if the quirk is still necessary there.

I've tested suspend/resume on a Toshiba Click Mini L9W-B which is the
device for which this quirk was added in the first place and with the
"Don't reset device upon system resume" fix the quirk is no longer
necessary, so this commit removes it.

Note even better I also had some other devices with SIS touchscreens which
suspend/resume issues, where the RESEND_REPORT_DESCR quirk did not help.

I've also tested these devices with the "Don't reset device upon system
resume" fix and I'm happy to report that that fix also fixes touchscreen
resume on the following devices:

Asus T100HA
Asus T200TA
Peaq C1010

Cc: Kai-Heng Feng <kai.heng.feng@canonical.com>
Acked-by: NBenjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: NHans de Goede <hdegoede@redhat.com>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

This hantick HTIX5288 touchpad can quickly fall in a wrong state if
there are too many open/close operations. This will either make it stop
reporting any input, or will shift all the input reads by a few bytes,
making it impossible to decode.

Here, we never release the probed touchpad runtime pm while the driver
is loaded, which should disable all runtime pm suspend/resumes.

This fast repetition of sleep/wakeup is also more likely to happen when
using runtime PM, which is why the quirk is done there, and not for all
power downs, which would include suspend or module removal.
Signed-off-by: NAnisse Astier <anisse@astier.eu>
Cc: stable@vger.kernel.org
Acked-by: NBenjamin Tissoires <benjamin.tissoires@redhat.com>
Reviewed-by: NHans de Goede <hdegoede@redhat.com>
Tested-by: NPhilip Müller <philm@manjaro.org>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

Raydium touchscreen triggers interrupt storm after system-wide suspend:

	[ 179.085033] i2c_hid i2c-CUST0000:00: i2c_hid_get_input: incomplete report (58/65535)

According to Raydium, Windows driver does not reset the device after system
resume.

The HID over I2C spec does specify a reset should be used at intialization, but
it doesn't specify if reset is required for system suspend.

Tested this patch on other i2c-hid touchpanels I have and those touchpanels do
work after S3 without doing reset. If any regression happens to other
touchpanel vendors, we can use quirk for Raydium devices.

There's still one device uses I2C_HID_QUIRK_RESEND_REPORT_DESCR so keep it
there.

Cc: Aaron Ma <aaron.ma@canonical.com>
Cc: AceLan Kao <acelan.kao@canonical.com>
Signed-off-by: NKai-Heng Feng <kai.heng.feng@canonical.com>
Reviewed-by: NBenjamin Tissoires <benjamin.tissoires@gmail.com>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

The incomplete report flooded after S3 and touchscreen becomes
malfunctioned.
[ 1367.646244] i2c_hid i2c-CUST0000:00: i2c_hid_get_input: incomplete report (58/18785)
[ 1367.649471] i2c_hid i2c-CUST0000:00: i2c_hid_get_input: incomplete report (58/28743)
[ 1367.651092] i2c_hid i2c-CUST0000:00: i2c_hid_get_input: incomplete report (58/26757)
[ 1367.652658] i2c_hid i2c-CUST0000:00: i2c_hid_get_input: incomplete report (58/52280)
[ 1367.654287] i2c_hid i2c-CUST0000:00: i2c_hid_get_input: incomplete report (58/56059)

Adding device ID, 04F3:30CC, to the quirk to re-send report description
after resume.

Cc: stable@vger.kernel.org
Signed-off-by: NAceLan Kao <acelan.kao@canonical.com>
Reviewed-by: NBenjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

Commit ac75a041 ("HID: i2c-hid: fix size check and type usage") started
writing messages when the ret_size is <= 2 from i2c_master_recv.  However, my
device i2c-DLL07D1 returns 2 for a short period of time (~0.5s) after I stop
moving the pointing stick or touchpad.  It varies, but you get ~50 messages
each time which spams the log hard.

[  95.925055] i2c_hid i2c-DLL07D1:01: i2c_hid_get_input: incomplete report (83/2)

This has also been observed with a i2c-ALP0017.

[ 1781.266353] i2c_hid i2c-ALP0017:00: i2c_hid_get_input: incomplete report (30/2)

Only print the message when ret_size is totally invalid and less than 2 to cut
down on the log spam.

Fixes: ac75a041 ("HID: i2c-hid: fix size check and type usage")
Reported-by: NJohn Smith <john-s-84@gmx.net>
Cc: stable@vger.kernel.org
Signed-off-by: NJason Andryuk <jandryuk@gmail.com>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

Some wacom w9013 devices have a vddl supply for "low valtage"
requirements. Add support in this driver to turn on this low voltage
supply. We can also drop a handful of error messages because the
regulator core is already printing an error when bulk regulators fail to
enable or disable.

Cc: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Cc: Hans de Goede <hdegoede@redhat.com>
Cc: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Cc: Dmitry Torokhov <dtor@chromium.org>
Cc: Doug Anderson <dianders@chromium.org>
Acked-by: NRob Herring <robh@kernel.org>
Cc: <devicetree@vger.kernel.org>
Signed-off-by: NStephen Boyd <swboyd@chromium.org>
Acked-by: NBenjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

Use devm here to save some lines and prepare for bulk regulator usage in
this driver. Otherwise, when we devm bulk get regulators we'll free the
containing i2c_hid structure and try to put regulator pointers from
freed memory.

Cc: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Cc: Hans de Goede <hdegoede@redhat.com>
Cc: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Cc: Dmitry Torokhov <dtor@chromium.org>
Cc: Doug Anderson <dianders@chromium.org>
Signed-off-by: NStephen Boyd <swboyd@chromium.org>
Acked-by: NBenjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

Since commit 85ae9113 ("HID: i2c-hid: remove custom locking from
i2c_hid_open/close") there are no more users of i2c_hid_open_mut.
Remove the unused mutex.

Cc: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Cc: Jiri Kosina <jikos@kernel.org>
Signed-off-by: NSebastian Andrzej Siewior <bigeasy@linutronix.de>
Reviewed-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

On many Chromebooks touch devices are multi-sourced; the components are
electrically compatible and one can be freely swapped for another without
changing the OS image or firmware.

To avoid bunch of scary messages when device is not actually present in the
system let's try testing basic communication with it and if there is no
response terminate probe early with -ENXIO.
Signed-off-by: NDmitry Torokhov <dtor@chromium.org>
Reviewed-by: NBenjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

The 0457:10fb touchscreen found on the Toshiba Click Mini L9W-B needs
to have a report-decriptors command send to it on resume in order for
the touchscreen to start generating events again on resume.
Signed-off-by: NHans de Goede <hdegoede@redhat.com>
Acked-by: NBenjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

i2c_hid_command() returns non-zero in error cases (the actual
errno). Error handling in for I2C_HID_QUIRK_RESEND_REPORT_DESCR
case in i2c_hid_resume() had the check inverted; fix that.

Fixes: 3e83eda4 ("HID: i2c-hid: Fix resume issue on Raydium touchscreen device")
Reported-by: NDan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

The CHPN0001 ACPI device has a _CID of PNP0C50 and even has the _DSM to
get the HID descriptor address, but it is not a HID device at all.

It uses its own protocol which is handled by the (still being upstreamed)
chipone_icn8505 driver. I guess the _CID and the _DSM are the result of
a copy and paste job when the vendor was building the ACPI tables.

Before this patch the i2c_hid_driver's probe function will fail with a
"hid_descr_cmd failed" error.

This commit makes the i2c_hid_driver's probe function instead silently
ignored devices with an ACPI id of CHPN0001.
Signed-off-by: NHans de Goede <hdegoede@redhat.com>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

Log an error in all error paths of i2c_hid_acpi_pdata() instead of having
the caller log a generic error.

This is a preparation patch for allowing i2c_hid_acpi_pdata() to fail
silently under certain conditions.
Signed-off-by: NHans de Goede <hdegoede@redhat.com>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

When Rayd touchscreen resumed from S3, it issues too many errors like:
i2c_hid i2c-RAYD0001:00: i2c_hid_get_input: incomplete report (58/5442)

And all the report data are corrupted, touchscreen is unresponsive.

Fix this by re-sending report description command after resume.
Add device ID as a quirk.

Cc: stable@vger.kernel.org
Signed-off-by: NAaron Ma <aaron.ma@canonical.com>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

When convert char array with signed int, if the inbuf[x] is negative then
upper bits will be set to 1. Fix this by using u8 instead of char.

ret_size has to be at least 3, hid_input_report use it after minus 2 bytes.

Cc: stable@vger.kernel.org
Signed-off-by: NAaron Ma <aaron.ma@canonical.com>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

Instead of doing additional checks and functional calls,
just get ACPI companion device directly.
Signed-off-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

The property "post-power-on-delay-ms" allows a platform to specify
the delay needed after power-on, but only via device trees currently.
Use device_property_* instead of of_* reads to allow ACPI systems to
also provide the same information. This is useful for Wacom hardware
on ACPI systems.
Signed-off-by: NRajat Jain <rajatja@google.com>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

Several cheap Apollo Lake based laptops / 2-in-1s use an i2c-hid mt
touchpad which is advertised by the DSDT with an ACPI HID of "SYNA3602",
this touchpad can be found on e.g. the Cube Thinker and the EZBook 3 Pro.

On my "T-bao Tbook air" the i2c-hid driver fails to bind to this touchpad:
"i2c_hid i2c-SYNA3602:00: failed to reset device.".

After some debuging this it seems that this touchpad simply never sends
an interrupt after a reset as expected by the i2c hid driver. This commit
adds a quirk for this device, making i2c_hid_command sleep 100ms after
a reset instead of waiting for an irq, fixing i2c-hid failing to bind to
this touchpad.
Signed-off-by: NHans de Goede <hdegoede@redhat.com>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

The buffer allocation is not currently accounting for an extra byte for
the report id. This can cause an out of bounds access in function
i2c_hid_set_or_send_report() with reportID > 15.

Cc: stable@vger.kernel.org
Signed-off-by: NAdrian Salido <salidoa@google.com>
Reviewed-by: NBenson Leung <bleung@chromium.org>
Signed-off-by: NGuenter Roeck <groeck@chromium.org>
Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

Although HID itself is transport-agnostic, occasionally a driver may
want to interact with the low-level transport that a device is connected
through. To do this, we need to know what kind of bus is in use. The
first guess may be to look at the 'bus' field of the 'struct hid_device',
but this field may be emulated in some cases (e.g. uhid).

More ideally, we can check which ll_driver a device is using. This
function introduces a 'hid_is_using_ll_driver' function and makes the
'struct hid_ll_driver' of the four most common transports accessible
through hid.h.
Signed-off-by: NJason Gerecke <jason.gerecke@wacom.com>
Acked-By: NBenjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

Now that HID core enforces serialization of transport driver open/close
calls we can remove custom locking from i2c-hid driver.
Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>
Reviewed-by: NAndy Shevchenko <andy.shevchenko@gmail.com>
Reviewed-by: NBenjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

acpi_evaluate_dsm() and friends take a pointer to a raw buffer of 16
bytes. Instead we convert them to use guid_t type. At the same time we
convert current users.

acpi_str_to_uuid() becomes useless after the conversion and it's safe to
get rid of it.
Acked-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
Cc: Borislav Petkov <bp@suse.de>
Acked-by: NDan Williams <dan.j.williams@intel.com>
Cc: Amir Goldstein <amir73il@gmail.com>
Reviewed-by: NJarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
Reviewed-by: NJani Nikula <jani.nikula@intel.com>
Acked-by: NJani Nikula <jani.nikula@intel.com>
Cc: Ben Skeggs <bskeggs@redhat.com>
Acked-by: NBenjamin Tissoires <benjamin.tissoires@redhat.com>
Acked-by: NJoerg Roedel <jroedel@suse.de>
Acked-by: NAdrian Hunter <adrian.hunter@intel.com>
Cc: Yisen Zhuang <yisen.zhuang@huawei.com>
Acked-by: NBjorn Helgaas <bhelgaas@google.com>
Acked-by: NFelipe Balbi <felipe.balbi@linux.intel.com>
Acked-by: NMathias Nyman <mathias.nyman@linux.intel.com>
Reviewed-by: NHeikki Krogerus <heikki.krogerus@linux.intel.com>
Acked-by: NMark Brown <broonie@kernel.org>
Signed-off-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: NChristoph Hellwig <hch@lst.de>

For ACPI devices which do not have a _PSC method, the ACPI subsys cannot
query their initial state at boot, so these devices are assumed to have
been put in D0 by the BIOS, but for touchscreens that is not always true.

This commit adds a call to acpi_device_fix_up_power to explicitly put
devices without a _PSC method into D0 state (for devices with a _PSC
method it is a nop). Note we only need to do this on probe, after a
resume the ACPI subsys knows the device is in D3 and will properly
put it in D0.

This fixes the SIS0817 i2c-hid touchscreen on a Peaq C1010 2-in-1
device failing to probe with a "hid_descr_cmd failed" error.
Acked-by: NBenjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: NHans de Goede <hdegoede@redhat.com>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

include/linux/i2c is not for client devices. Move the header file to a
more appropriate location.
Signed-off-by: NWolfram Sang <wsa@the-dreams.de>
Acked-by: NBenjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

It looks like a bunch of devices do not like to be polled
for their reports at init time. When you look into the details,
it seems that for those that are requiring the quirk
HID_QUIRK_NO_INIT_REPORTS, the driver fails to retrieve part
of the features/inputs while others (more generic) work.

IMO, it should be acceptable to remove the need for the quirk
in the general case. On the small amount of cases where
we actually need to read the current values, the driver
in charge (hid-mt or wacom) already retrieves the features
manually.

There are 2 cases where we might need to retrieve the reports at
init:
1. hiddev devices with specific use-space tool
2. a device that would require the driver to fetch a specific
   feature/input at plug

For case 2, I have seen this a few time on hid-multitouch. It
is solved in hid-multitouch directly by fetching the feature.
I hope it won't be too common and this can be solved on a per-case
basis (crossing fingers).

For case 1, we moved the implementation of HID_QUIRK_NO_INIT_REPORTS
in hiddev. When somebody starts calling ioctls that needs an initial
update, the hiddev device will fetch the initial state of the reports
to mimic the current behavior. This adds a small amount of time during
the first HIDIOCGUSAGE(S), but it should be acceptable in
most cases. To keep the currently known broken devices, we have to
keep around HID_QUIRK_NO_INIT_REPORTS, but the scope will only be
for hiddev.

Note that I don't think hidraw would be affected and I checked that
the FF drivers that need to interact with the report fields are all
using output reports, which are not initialized by
usbhid_init_reports().

NO_INIT_INPUT_REPORTS is then replaced by HID_QUIRK_NO_INIT_REPORTS:
there is no point keeping it for just one device.
Signed-off-by: NBenjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

According to error handling in this function, it is likely that some
resources should be freed before returning.
Replace 'return ret', with 'goto err'.

While at it, remove some spaces at the beginning of the lines to be more
consistent.

Fixes: ead0687fe304a ("HID: i2c-hid: support regulator power on/off")
Signed-off-by: NChristophe JAILLET <christophe.jaillet@wanadoo.fr>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

On some boards, we need to enable a regulator before using the HID, and
it's also nice to save power in suspend by disabling it. Support an
optional "vdd-supply" and a companion initialization delay.
Signed-off-by: NBrian Norris <briannorris@chromium.org>
Signed-off-by: NCaesar Wang <wxt@rock-chips.com>
Acked-by: NBenjamin Tissoires <benjamin.tissoires@redhat.com>
Reviewed-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>
Cc: Jiri Kosina <jikos@kernel.org>
Cc: linux-input@vger.kernel.org
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

Support for the Asus Touchpad was recently added. It turns out this
device can fail initialisation (and become unusable) when the RESET
command is sent too soon after the POWER ON command.

Unfortunately the i2c-hid specification does not specify the need for
a delay between these two commands. But it was discovered the Windows
driver has a 1ms delay.

As a result, this patch modifies the i2c-hid module to add a sleep
inbetween the POWER ON and RESET commands which lasts between 1ms and 5ms.

See https://github.com/vlasenko/hid-asus-dkms/issues/24 for further
details.
Signed-off-by: NBrendan McGrath <redmcg@redmandi.dyndns.org>
Reviewed-by: NBenjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

commit ba18a931 ("Revert "HID: i2c-hid: Add support for ACPI GPIO
interrupts"") removed the need for storing the irq in struct i2c_hid.

But then commit de3c99488609 ("HID: i2c-hid: Disable IRQ before freeing
buffers") forgot to update the location of the irq.

Fix this by using the actual I2C client irq.
Reported-by: Nkbuild test robot <fengguang.wu@intel.com>
Signed-off-by: NBenjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

Add a forgotten include that I've by mistake omitted when resolving
merge conflict in ead0687fe30 ("HID: i2c-hid: support regulator power
on/off").

Fixes: ead0687fe30 ("HID: i2c-hid: support regulator power on/off")
Reported-by: Nkbuild test robot <fengguang.wu@intel.com>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

The HID report buffers that are initially allocated on i2c_hid_probe()
might not be big enough to hold the HID reports from a specific device,
in which case they will be freed and new ones will be allocated in
i2c_hid_start(), at point which the device's report size is known. But
at this point ihid->irq is already running, and may call
i2c_hid_get_input() which passes ihid->inbuf to i2c_master_recv(). Since
this handler runs in a separate thread, ihid->inbuf may be freed at this
very moment, and i2c_master_recv() will write on memory which may be
already owned by a different part of the kernel, corrupting its data.

This problem has been observed on an Asus UX360UA laptop which has an
I2C touchpad, and results in a complete system freeze or an unusable
slowness with a lof of "BUG: unable to handle kernel paging request at
<address>" warnings. Enabling SLUB debugging shows a use-after-free
warning on memory allocated in i2c_hid_alloc_buffers() and freed in
i2c_hid_free_buffers():

=============================================================================
BUG kmalloc-64 (Not tainted): Poison overwritten
-----------------------------------------------------------------------------
Disabling lock debugging due to kernel taint
INFO: 0xffff880264083273-0xffff88026408329e. first byte 0x0 instead of 0x6b
INFO: Allocated in i2c_hid_alloc_buffers+0x25/0xa0 [i2c_hid] age=35793 cpu=2 pid=430
	___slab_alloc+0x41e/0x460
	__slab_alloc+0x20/0x40
	__kmalloc+0x210/0x280
	i2c_hid_alloc_buffers+0x25/0xa0 [i2c_hid]
	i2c_hid_probe+0x12f/0x5e0 [i2c_hid]
	i2c_device_probe+0x10a/0x1b0
	driver_probe_device+0x220/0x4a0
	__device_attach_driver+0x71/0xa0
	bus_for_each_drv+0x67/0xb0
	__device_attach+0xdc/0x170
	device_initial_probe+0x13/0x20
	bus_probe_device+0x92/0xa0
	device_add+0x4aa/0x670
	device_register+0x1a/0x20
	i2c_new_device+0x18e/0x230
	acpi_i2c_add_device+0x1a0/0x210
INFO: Freed in i2c_hid_free_buffers+0x16/0x60 [i2c_hid] age=7552 cpu=1 pid=1473
	__slab_free+0x221/0x330
	kfree+0x139/0x160
	i2c_hid_free_buffers+0x16/0x60 [i2c_hid]
	i2c_hid_start+0x2a9/0x2df [i2c_hid]
	mt_probe+0x160/0x22e [hid_multitouch]
	hid_device_probe+0xd7/0x150 [hid]
	driver_probe_device+0x220/0x4a0
	__driver_attach+0x84/0x90
	bus_for_each_dev+0x6c/0xc0
	driver_attach+0x1e/0x20
	bus_add_driver+0x1c3/0x280
	driver_register+0x60/0xe0
	__hid_register_driver+0x53/0x90 [hid]
	0xffffffffc004f01e
	do_one_initcall+0xb3/0x1f0
	do_init_module+0x5f/0x1d0
INFO: Slab 0xffffea0009902080 objects=20 used=20 fp=0x          (null) flags=0x17fff8000004080
INFO: Object 0xffff880264083260 @offset=4704 fp=0x          (null)
Bytes b4 ffff880264083250: 8d e6 fe ff 00 00 00 00 5a 5a 5a 5a 5a 5a 5a 5a  ........ZZZZZZZZ
Object ffff880264083260: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b  kkkkkkkkkkkkkkkk
Object ffff880264083270: 6b 6b 6b 00 00 00 00 00 00 00 00 00 00 00 00 00  kkk.............
Object ffff880264083280: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
Object ffff880264083290: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
Redzone ffff8802640832a0: bb bb bb bb bb bb bb bb                          ........
Padding ffff8802640833e0: 5a 5a 5a 5a 5a 5a 5a 5a                          ZZZZZZZZ
CPU: 1 PID: 1503 Comm: python3 Tainted: G    B           4.4.21+ #10
Hardware name: ASUSTeK COMPUTER INC. UX360UA/UX360UA, BIOS UX360UA.200 05/05/2016
 0000000000000086 00000000622d48a2 ffff88026061ba38 ffffffff813f6044
 ffff880264082010 ffff880264083260 ffff88026061ba78 ffffffff811e8eab
 0000000000000008 ffff880200000001 ffff88026408329f ffff88026a007700
Call Trace:
 [<ffffffff813f6044>] dump_stack+0x63/0x8f
 [<ffffffff811e8eab>] print_trailer+0x14b/0x1f0
 [<ffffffff811e94c1>] check_bytes_and_report+0xc1/0x100
 [<ffffffff811e96c4>] check_object+0x1c4/0x240
 [<ffffffff81293fde>] ? ext4_htree_store_dirent+0x3e/0x120
 [<ffffffff811e9b44>] alloc_debug_processing+0x104/0x180
 [<ffffffff811eb7be>] ___slab_alloc+0x41e/0x460
 [<ffffffff81293fde>] ? ext4_htree_store_dirent+0x3e/0x120
 [<ffffffff8124590b>] ? __getblk_gfp+0x2b/0x60
 [<ffffffff8129b969>] ? ext4_getblk+0xa9/0x190
 [<ffffffff811eb820>] __slab_alloc+0x20/0x40
 [<ffffffff811ed320>] __kmalloc+0x210/0x280
 [<ffffffff81293fde>] ? ext4_htree_store_dirent+0x3e/0x120
 [<ffffffff812c1602>] ? ext4fs_dirhash+0xc2/0x2a0
 [<ffffffff81293fde>] ext4_htree_store_dirent+0x3e/0x120
 [<ffffffff812a4f47>] htree_dirblock_to_tree+0x187/0x1b0
 [<ffffffff812a5fd2>] ext4_htree_fill_tree+0xb2/0x2e0
 [<ffffffff811ebb7a>] ? kmem_cache_alloc_trace+0x1fa/0x220
 [<ffffffff81293e45>] ? ext4_readdir+0x775/0x8b0
 [<ffffffff81293cb1>] ext4_readdir+0x5e1/0x8b0
 [<ffffffff81221c82>] iterate_dir+0x92/0x120
 [<ffffffff81222118>] SyS_getdents+0x98/0x110
 [<ffffffff81221d10>] ? iterate_dir+0x120/0x120
 [<ffffffff818157f2>] entry_SYSCALL_64_fastpath+0x16/0x71
FIX kmalloc-64: Restoring 0xffff880264083273-0xffff88026408329e=0x6b
FIX kmalloc-64: Marking all objects used
Signed-off-by: NJoão Paulo Rechi Vita <jprvita@endlessm.com>
Reviewed-by: NBenjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

Instead of forcing the level trigger of the IRQ, we can count
on ACPI or OF to set it up for us.

The first release of the HID over I2C specification mentioned
that the level trigger needed to be active low. In the latest
version of the specification, there is no such explicit mention,
so it's better to not assume one.
Signed-off-by: NBenjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

Certain devices produced by Weida Tech need to have a wakeup command sent to
them before powering on. The call itself will come back with error, but the
device can be powered on afterwards.

[jkosina@suse.cz: rewrite changelog]
[jkosina@suse.cz: remove unused device ID addition]
Signed-off-by: NHungNien Chen <hn.chen@weidahitech.com>
Reviewed-by: NBenjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

When i2c-core doesn't find the IRQ associated to the GPIO because
the gpiochip is not available, it assigns -EPROBE_DEFER to the irq.
We need to bail out there and on any other error in an IRQ.
Signed-off-by: NDavid Arcari <darcari@redhat.com>
Signed-off-by: NBenjamin Tissoires <benjamin.tissoires@redhat.com>
Reviewed-by: NMika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

This reverts commit a485923e ("HID: i2c-hid: Add support for ACPI
GPIO interrupts") and commit a7d2bf25 ("HID: i2c-hid: Do not fail
probing if gpiolib is not enabled") at the same time.

Since commit c884fbd4 ("gpio / ACPI: Add support for retrieving
GpioInt resources from a device") i2c_core already set the IRQ by
looking into the ACPI tree and retrieving the gpioInt. So we just
have some boiler-plate here that is not needed anymore.

The only downside effect here is that now we are not exiting early
enough if the irq is set to -EPROBE_DEFER or any other error, but
this is going to be fixed in the following patch.
Signed-off-by: NDavid Arcari <darcari@redhat.com>
Signed-off-by: NBenjamin Tissoires <benjamin.tissoires@redhat.com>
Reviewed-by: NMika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

Add i2c_hid_shutdown for i2c-hid driver to send suspend cmd & free
irq before device shutdown.

Some HW design (i.e. Umaro, a chromebook model) is that the power to
i2c hid device won't down after device shutdown. Also the i2c-hid driver
do not send suspend cmd to the hid i2c device and free its irq before
shutdown.So if We touch the touchscreen or some other i2c hid device,
the power consumtion will be go up even when the device is in shutdown
state.

Though the root cause maybe a HW issue. But it seems that it is a
good pratice to set power sleep for i2c-hid device before shutdown.
Signed-off-by: NGuohua Zhong <ghzhong@yifangdigital.com>
Acked-By: NBenjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

i2c-hid devices' suspend/resume are usually time-consuming process.
For example, the touch controller(i2c-ATML1000:00) on ASUS T100 tablet
takes about 160ms for suspending and 120ms for resuming. This patch
enables i2c-hid devices to suspend/resume asynchronously. This will
take advantage of multicore and speed up system suspend/resume process.
Signed-off-by: NZhonghui Fu <zhonghui.fu@linux.intel.com>
Acked-by: NBenjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

Even though hid_hw_* checks that passed in data_len is less than
HID_MAX_BUFFER_SIZE it is not enough, as i2c-hid does not necessarily
allocate buffers of HID_MAX_BUFFER_SIZE but rather checks all device
reports and select largest size. In-kernel users normally just send as much
data as report needs, so there is no problem, but hidraw users can do
whatever they please:

BUG: KASAN: slab-out-of-bounds in memcpy+0x34/0x54 at addr ffffffc07135ea80
Write of size 4101 by task syz-executor/8747
CPU: 2 PID: 8747 Comm: syz-executor Tainted: G    BU         3.18.0 #37
Hardware name: Google Tegra210 Smaug Rev 1,3+ (DT)
Call trace:
[<ffffffc00020ebcc>] dump_backtrace+0x0/0x258 arch/arm64/kernel/traps.c:83
[<ffffffc00020ee40>] show_stack+0x1c/0x2c arch/arm64/kernel/traps.c:172
[<     inline     >] __dump_stack lib/dump_stack.c:15
[<ffffffc001958114>] dump_stack+0x90/0x140 lib/dump_stack.c:50
[<     inline     >] print_error_description mm/kasan/report.c:97
[<     inline     >] kasan_report_error mm/kasan/report.c:278
[<ffffffc0004597dc>] kasan_report+0x268/0x530 mm/kasan/report.c:305
[<ffffffc0004592e8>] __asan_storeN+0x20/0x150 mm/kasan/kasan.c:718
[<ffffffc0004594e0>] memcpy+0x30/0x54 mm/kasan/kasan.c:299
[<ffffffc001306354>] __i2c_hid_command+0x2b0/0x7b4 drivers/hid/i2c-hid/i2c-hid.c:178
[<     inline     >] i2c_hid_set_or_send_report drivers/hid/i2c-hid/i2c-hid.c:321
[<ffffffc0013079a0>] i2c_hid_output_raw_report.isra.2+0x3d4/0x4b8 drivers/hid/i2c-hid/i2c-hid.c:589
[<ffffffc001307ad8>] i2c_hid_output_report+0x54/0x68 drivers/hid/i2c-hid/i2c-hid.c:602
[<     inline     >] hid_hw_output_report include/linux/hid.h:1039
[<ffffffc0012cc7a0>] hidraw_send_report+0x400/0x414 drivers/hid/hidraw.c:154
[<ffffffc0012cc7f4>] hidraw_write+0x40/0x64 drivers/hid/hidraw.c:177
[<ffffffc0004681dc>] vfs_write+0x1d4/0x3cc fs/read_write.c:534
[<     inline     >] SYSC_pwrite64 fs/read_write.c:627
[<ffffffc000468984>] SyS_pwrite64+0xec/0x144 fs/read_write.c:614
Object at ffffffc07135ea80, in cache kmalloc-512
Object allocated with size 268 bytes.

Let's check data length against the buffer size before attempting to copy
data over.

Cc: stable@vger.kernel.org
Reported-by: NAlexander Potapenko <glider@google.com>
Signed-off-by: NDmitry Torokhov <dtor@chromium.org>
Reviewed-by: NBenjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

On ACPI-based systems ACPI power domain code runtime resumes device before
calling suspend method, which ensures that i2c-hid suspend code starts with
device not in low-power state and with interrupts enabled.

On other systems, especially if device is not a part of any power domain,
we may end up calling driver's system-level suspend routine while the
device is runtime-suspended (with controller in presumably low power state
and interrupts disabled). This will result in interrupts being essentially
disabled twice, and we will only re-enable them after both system resume
and runtime resume methods complete. Unfortunately i2c_hid_resume() calls
i2c_hid_hwreset() and that only works properly if interrupts are enabled.

Also if device is runtime-suspended driver's suspend code may fail if it
tries to issue I/O requests.

Let's fix it by runtime-resuming the device if we need to run HID driver's
suspend code and also disabling interrupts only if device is not already
runtime-suspended. Also on resume we mark the device as running at full
power (since that is what resetting will do to it).
Reviewed-by: NBenson Leung <bleung@chromium.org>
Tested-by: NMika Westerberg <mika.westerberg@linux.intel.com>
Acked-by: NBenjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: NDoug Anderson <dianders@chromium.org>
Signed-off-by: NDmitry Torokhov <dtor@chromium.org>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>