Modify struct acpi_dev_node to contain a pointer to struct acpi_device
associated with the given device object (that is, its ACPI companion
device) instead of an ACPI handle corresponding to it.  Introduce two
new macros for manipulating that pointer in a CONFIG_ACPI-safe way,
ACPI_COMPANION() and ACPI_COMPANION_SET(), and rework the
ACPI_HANDLE() macro to take the above changes into account.
Drop the ACPI_HANDLE_SET() macro entirely and rework its users to
use ACPI_COMPANION_SET() instead.  For some of them who used to
pass the result of acpi_get_child() directly to ACPI_HANDLE_SET()
introduce a helper routine acpi_preset_companion() doing an
equivalent thing.

The main motivation for doing this is that there are things
represented by struct acpi_device objects that don't have valid
ACPI handles (so called fixed ACPI hardware features, such as
power and sleep buttons) and we would like to create platform
device objects for them and "glue" them to their ACPI companions
in the usual way (which currently is impossible due to the
lack of valid ACPI handles).  However, there are more reasons
why it may be useful.

First, struct acpi_device pointers allow of much better type checking
than void pointers which are ACPI handles, so it should be more
difficult to write buggy code using modified struct acpi_dev_node
and the new macros.  Second, the change should help to reduce (over
time) the number of places in which the result of ACPI_HANDLE() is
passed to acpi_bus_get_device() in order to obtain a pointer to the
struct acpi_device associated with the given "physical" device,
because now that pointer is returned by ACPI_COMPANION() directly.
Finally, the change should make it easier to write generic code that
will build both for CONFIG_ACPI set and unset without adding explicit
compiler directives to it.
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
Acked-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Tested-by: Mika Westerberg <mika.westerberg@linux.intel.com> # on Haswell
Reviewed-by: NMika Westerberg <mika.westerberg@linux.intel.com>
Reviewed-by: Aaron Lu <aaron.lu@intel.com> # for ATA and SDIO part

acpi_evaluate_integer() is an ACPI API introduced to evaluate an
ACPI control method that is known to have an integer return value.
This API can simplify the code because the calling function does not need to
use the specified acpi_buffer structure required by acpi_evaluate_object();

Convert acpi_evaluate_object() to acpi_evaluate_integer()
in drivers/hid/i2c-hid/i2c-hid.c in this patch.
Signed-off-by: NZhang Rui <rui.zhang@intel.com>
Acked-by: NJiri Kosina <jkosina@suse.cz>
Acked-by: NBenjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

ACPI 5.0 specification requires the fourth parameter to the _DSM (Device
Specific Method) to be of type package instead of integer. Failing to do
that we get following warning on the console:

  ACPI Warning: \_SB_.PCI0.I2C1.TPL0._DSM: Argument #4 type mismatch - Found [Integer],
                ACPI requires [Package] (20130517/nsarguments-95)

Fix this by passing an empty package to the _DSM method. The HID over I2C
specification doesn't require any specific values to be passed with this
parameter.
Signed-off-by: NMika Westerberg <mika.westerberg@linux.intel.com>
Reviewed-by: NBenjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

There is no need to pass constants via stack. The width may be explicitly
specified in the format.
Signed-off-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>
Reviewed-by: NBenjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

Add device tree based support for HID over I2C devices.

Tested on an Odroid-X board with a Synaptics touchpad.
Signed-off-by: NBenjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

HID core provides the same functionality, so drop the custom handler.
Besides, the current handler doesn't schedule any outgoing report so it
did not work, anyway.
Signed-off-by: NDavid Herrmann <dh.herrmann@gmail.com>
Reviewed-by: NBenjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

The current i2c hid driver does not support sending HID output reports using
the output register for devices which support receiving reports through this
method. This patch determines which method to use to send output reports based
 on the value of wMaxOutputLength in the device's HID descriptor.
Signed-off-by: NAndrew Duggan <aduggan@synaptics.com>
Reviewed-by: NBenjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

With the current i2c hid driver set/get report does not work
as expected, for e.g sensor hub properties like power state,
frequency etc is not set properly on the device as a result
we do not get events.
The problem is that i2c hid driver in function i2c_hid_request
sets length equal to default buffer size for which the sensor
hub does not respond on get/set commands. Use report length
and calculate it based on report size and id.
Reviewed-by: NMika Westerberg <mika.westerberg@linux.intel.com>
Reviewed-by: NBenjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: NHuzefa Kankroliwala <huzefa.nomanx.kankroliwala@intel.com>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

This allows HID drivers to also get/set reports through hid_hw_request().
Tested-by: NMika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: NBenjamin Tissoires <benjamin.tissoires@gmail.com>
Signed-off-by: NMika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

i2c_hid_output_raw_report is used by hidraw to forward set_report requests.
The current implementation of i2c_hid_set_report needs to take the
report_id as an argument. The report_id is stored in the first byte
of the buffer in argument of i2c_hid_output_raw_report.

Not removing the report_id from the given buffer adds this byte 2 times
in the command, leading to a non working command.
Reported-by: NAndrew Duggan <aduggan@synaptics.com>
Signed-off-by: NBenjamin Tissoires <benjamin.tissoires@gmail.com>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

The HID over I2C protocol specification states that when the device is
enumerated from ACPI the HID descriptor address can be obtained by
executing "_DSM" for the device with function 1. Enable this.
Signed-off-by: NMika Westerberg <mika.westerberg@linux.intel.com>
Reviewed-by: NBenjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

CONFIG_HOTPLUG is going away as an option.  As a result, the __dev*
markings need to be removed.

This change removes the use of __devinit, __devexit_p, __devinitdata,
__devinitconst, and __devexit from these drivers.

Based on patches originally written by Bill Pemberton, but redone by me
in order to handle some of the coding style issues better, by hand.

Cc: Bill Pemberton <wfp5p@virginia.edu>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

We should not enter close function while someone else is in open.
This mutex prevents this race.

There is also no need to override the ret value with -EIO in case of
a failure of i2c_hid_set_power.
Signed-off-by: NBenjamin Tissoires <benjamin.tissoires@gmail.com>
Reviewed-by: NJean Delvare <khali@linux-fr.org>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

ret_count has to be at least 3, as we have to count the 2 bytes that are used
for the size of the reply. Without this, memcpy() might be called with zero or
negative count.
Reported-by: NJean Delvare <khali@linux-fr.org>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

The previous memcpy implementation relied on the size advertized by the
device. There were no guarantees that buf was big enough.

Some gymnastic is also required with the +2/-2 to take into account
the first 2 bytes of the returned buffer where the total returned
length is supplied by the device.
Signed-off-by: NBenjamin Tissoires <benjamin.tissoires@gmail.com>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

There is no point in keeping the irq in i2c_hid as it's already
there in client.
Signed-off-by: NBenjamin Tissoires <benjamin.tissoires@gmail.com>
Reviewed-by: NJean Delvare <khali@linux-fr.org>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

Simplifies i2c_hid_alloc_buffers tests, and makes this function
responsible of the assignment of ihid->bufsize.
The condition for the reallocation in i2c_hid_start is then simpler.
Signed-off-by: NBenjamin Tissoires <benjamin.tissoires@gmail.com>
Reviewed-by: NJean Delvare <khali@linux-fr.org>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

HID descriptors contains 4 bytes of reserved field.
The previous implementation was overriding the next fields in struct i2c_hid.
Signed-off-by: NBenjamin Tissoires <benjamin.tissoires@gmail.com>
Reviewed-by: NJean Delvare <khali@linux-fr.org>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

The pointless WARN_ON() has been removed from i2c_hid_remove(),
so we don't need bug.h any more.
Reported-by: NJean Delvare <khali@linux-fr.org>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

ihid can not be null, so there are no reasons to test it.
Signed-off-by: NBenjamin Tissoires <benjamin.tissoires@gmail.com>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

If i2c_hid_get_report fails, exit i2c_hid_init_report.
The printk log is already called by i2c_hid_get_report, so no need
to add some more printks.
Signed-off-by: NBenjamin Tissoires <benjamin.tissoires@gmail.com>
Reviewed-by: NJean Delvare <khali@linux-fr.org>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

In the case where the hid driver in charge of handling the hid part
of the device (hid-generic for instance) fails at probe, neither
i2c_hid_start nor i2c_hid_stop are called.
Thus, the buffers allocated in i2c_hid_probe are never freed.
Signed-off-by: NBenjamin Tissoires <benjamin.tissoires@gmail.com>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

Signed-off-by: NBenjamin Tissoires <benjamin.tissoires@gmail.com>
Reviewed-by: NJean Delvare <khali@linux-fr.org>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

Forwards appropriate return values.
As noone use the error returned by i2c_hid_get_input, let's make it
returning void.
Signed-off-by: NBenjamin Tissoires <benjamin.tissoires@gmail.com>
Reviewed-by: NJean Delvare <khali@linux-fr.org>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

These definitions are not used here, but are defined by the specification.
Keeping some of them for documentation purposes.
Signed-off-by: NBenjamin Tissoires <benjamin.tissoires@gmail.com>
Reviewed-by: NJean Delvare <khali@linux-fr.org>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

This avoids the problematic case:

if (condition)
	i2c_hid_dbg(ihid, "Blah blah %d\n", i);
else
	do_something_very_important();

Which looks correct, however with the previous macro definition,
this expands to the unexpected:

if (condition) {
	if (debug)	\
		dev_printk(KERN_DEBUG, &ihid->client->dev,
				"Blah blah %d\n", i);
	else
		do_something_very_important();
}
Signed-off-by: NBenjamin Tissoires <benjamin.tissoires@gmail.com>
Reviewed-by: NJean Delvare <khali@linux-fr.org>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

We should not initialize to 0 static declarations.
Signed-off-by: NBenjamin Tissoires <benjamin.tissoires@gmail.com>
Reviewed-by: NJean Delvare <khali@linux-fr.org>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

no I2C driver has "i2c" in its name. It makes more sense to call this
i2c driver "hid".
Signed-off-by: NBenjamin Tissoires <benjamin.tissoires@gmail.com>
Reviewed-by: NJean Delvare <khali@linux-fr.org>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

In case we are returning from i2c_hid_probe() through the 'err' or
'err_mem_free' labels, there is noone freeing the buffers allocated by
i2c_hid_alloc_buffers().
Reviewed-by: NBenjamin Tissoires <benjamin.tissoires@gmail.com>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

Microsoft published the protocol specification of HID over i2c:
http://msdn.microsoft.com/en-us/library/windows/hardware/hh852380.aspx

This patch introduces an implementation of this protocol.

This implementation does not includes the ACPI part of the specification.
This will come when ACPI 5.0 devices enumeration will be available.

Once the ACPI part is done, OEM will not have to declare HID over I2C
devices in their platform specific driver.
Signed-off-by: NBenjamin Tissoires <benjamin.tissoires@gmail.com>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>