Add support in cros_ec.c to handle EC host command protocol v3.
For v3+, probe for maximum shared protocol version and max
request, response, and passthrough sizes. For now, this will
always fall back to v2, since there is no bus-specific code
for handling proto v3 packets.
Signed-off-by: NStephen Barber <smbarber@chromium.org>
Signed-off-by: NJavier Martinez Canillas <javier.martinez@collabora.co.uk>
Reviewed-by: NGwendal Grignou <gwendal@chromium.org>
Tested-by: NGwendal Grignou <gwendal@chromium.org>
Tested-by: NHeiko Stuebner <heiko@sntech.de>
Acked-by: NLee Jones <lee.jones@linaro.org>
Acked-by: NOlof Johansson <olof@lixom.net>
Signed-off-by: NLee Jones <lee.jones@linaro.org>

The MFD driver should only have the logic to instantiate its child devices
and setup any shared resources that will be used by the subdevices drivers.

The cros_ec MFD is more complex than expected since it also has helpers to
communicate with the EC. So the driver will only get more bigger as other
protocols are supported in the future. So move the communication protocol
helpers to its own driver as drivers/platform/chrome/cros_ec_proto.c.
Suggested-by: NLee Jones <lee.jones@linaro.org>
Signed-off-by: NJavier Martinez Canillas <javier.martinez@collabora.co.uk>
Tested-by: NHeiko Stuebner <heiko@sntech.de>
Acked-by: NLee Jones <lee.jones@linaro.org>
Acked-by: NOlof Johansson <olof@lixom.net>
Signed-off-by: NLee Jones <lee.jones@linaro.org>

Update cros_ec_commands.h to the latest version in the EC
firmware sources and add power domain and passthru commands.

Also, update lightbar to use new command names.
Signed-off-by: NStephen Barber <smbarber@chromium.org>
Reviewed-by: NRandall Spangler <rspangler@chromium.org>
Signed-off-by: NJavier Martinez Canillas <javier.martinez@collabora.co.uk>
Tested-by: NHeiko Stuebner <heiko@sntech.de>
Reviewed-by: NGwendal Grignou <gwendal@chromium.org>
Tested-by: NGwendal Grignou <gwendal@chromium.org>
Acked-by: NLee Jones <lee.jones@linaro.org>
Acked-by: NOlof Johansson <olof@lixom.net>
Signed-off-by: NLee Jones <lee.jones@linaro.org>

Commit 1b84f2a4 ("mfd: cros_ec: Use fixed size arrays to transfer
data with the EC") modified the struct cros_ec_command fields to not
use pointers for the input and output buffers and use fixed length
arrays instead.

This change was made because the cros_ec ioctl API uses that struct
cros_ec_command to allow user-space to send commands to the EC and
to get data from the EC. So using pointers made the API not 64-bit
safe. Unfortunately this approach was not flexible enough for all
the use-cases since there may be a need to send larger commands
on newer versions of the EC command protocol.

So to avoid to choose a constant length that it may be too big for
most commands and thus wasting memory and CPU cycles on copy from
and to user-space or having a size that is too small for some big
commands, use a zero-length array that is both 64-bit safe and
flexible. The same buffer is used for both output and input data
so the maximum of these values should be used to allocate it.
Suggested-by: NGwendal Grignou <gwendal@chromium.org>
Signed-off-by: NJavier Martinez Canillas <javier.martinez@collabora.co.uk>
Tested-by: NHeiko Stuebner <heiko@sntech.de>
Acked-by: NLee Jones <lee.jones@linaro.org>
Acked-by: NOlof Johansson <olof@lixom.net>
Signed-off-by: NLee Jones <lee.jones@linaro.org>

Parent and device were pointing to the same device structure.

Parent is unused, removed.
Signed-off-by: NGwendal Grignou <gwendal@chromium.org>
Tested-by: NStephen Barber <smbarber@chromium.org>
Tested-by: NHeiko Stuebner <heiko@sntech.de>
Tested-by: NGwendal Grignou <gwendal@chromium.org>
Reviewed-by: NPuthikorn Voravootivat <puthik@chromium.org>
Signed-off-by: NJavier Martinez Canillas <javier.martinez@collabora.co.uk>
Signed-off-by: NLee Jones <lee.jones@linaro.org>

The new Atmel MXT driver expects i2c client's address contain the
primary (main address) of the chip, and calculates the expected
bootloader address form the primary address. Unfortunately chrome_laptop
does probe the devices and if touchpad (or touchscreen, or both) comes
up in bootloader mode the i2c device gets instantiated with the
bootloader address which confuses the driver.

To work around this issue let's probe the primary address first. If the
device is not detected at the primary address we'll probe alternative
addresses as "dummy" devices. If any of them are found, destroy the
dummy client and instantiate client with proper name at primary address
still.
Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>
Signed-off-by: NOlof Johansson <olof@lixom.net>

The ChromeOS EC is connected by LPC only on x86 platforms and no others,
so add a dependency describing that.

But also build the driver if the COMPILE_TEST option is enabled
to have build coverage in other architectures.
Signed-off-by: NJavier Martinez Canillas <javier.martinez@collabora.co.uk>
[olof: reworded commit message]
Signed-off-by: NOlof Johansson <olof@lixom.net>

The driver uses the inb() and outb() I/O functions so should
include the header file that has these functions definitions.

This patch fixes the following error when the header is not
explicitly included:

drivers/platform/chrome//cros_ec_lpc.c: In function ‘ec_response_timed_out’:
drivers/platform/chrome//cros_ec_lpc.c:40:3: error: implicit declaration of function ‘inb’ [-Werror=implicit-function-declaration]
drivers/platform/chrome//cros_ec_lpc.c: In function ‘cros_ec_cmd_xfer_lpc’:
drivers/platform/chrome//cros_ec_lpc.c:75:3: error: implicit declaration of function ‘outb’ [-Werror=implicit-function-declaration]
Signed-off-by: NJavier Martinez Canillas <javier.martinez@collabora.co.uk>
Signed-off-by: NOlof Johansson <olof@lixom.net>

drivers/platform/chrome/cros_ec_lpc.c:272:3-8: No need to set .owner here. The core will do it.

 Remove .owner field if calls are used which set it automatically

Generated by: scripts/coccinelle/api/platform_no_drv_owner.cocci

CC: Bill Richardson <wfrichar@chromium.org>
Signed-off-by: NFengguang Wu <fengguang.wu@intel.com>
Signed-off-by: NOlof Johansson <olof@lixom.net>

Fix the following sparse warning:

    drivers/platform/chrome/cros_ec_lightbar.c:254:25: sparse: duplicate const
Reported-by: NDan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: NOlof Johansson <olofj@chromium.org>
Reviewed-by: NGwendal Grignou <gwendal@chromium.org>
Signed-off-by: NJavier Martinez Canillas <javier.martinez@collabora.co.uk>
Signed-off-by: NOlof Johansson <olof@lixom.net>

Fix the following sparse warning:

    drivers/platform/chrome/cros_ec_dev.c:64:45: sparse: Unknown escape '%'
Reported-by: NDan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: NOlof Johansson <olofj@chromium.org>
Reviewed-by: NGwendal Grignou <gwendal@chromium.org>
Signed-off-by: NJavier Martinez Canillas <javier.martinez@collabora.co.uk>
Signed-off-by: NOlof Johansson <olof@lixom.net>

This adds some sysfs entries to provide userspace control of the
four-element LED "lightbar" on the Chromebook Pixel. This only instantiates
the lightbar controls if the device actually exists.

To prevent DoS attacks, this interface is limited to 20 accesses/second,
although that rate can be adjusted by a privileged user.

On Chromebooks without a lightbar, this should have no effect. On the
Chromebook Pixel, you should be able to do things like this:

    $ cd /sys/devices/virtual/chromeos/cros_ec/lightbar
    $ echo 0x80 > brightness
    $ echo 255 > brightness
    $
    $ cat sequence
    S0
    $ echo konami > sequence
    $ cat sequence
    KONAMI
    $
    $ cat sequence
    S0

And

    $ cd /sys/devices/virtual/chromeos/cros_ec/lightbar
    $ echo stop > sequence
    $ echo "4 255 255 255" > led_rgb
    $ echo "0 255 0 0  1 0 255 0  2 0 0 255  3 255 255 0" > led_rgb
    $ echo run  > sequence

Test the DoS prevention with this:

    $ cd /sys/devices/virtual/chromeos/cros_ec/lightbar
    $ echo 500 > interval_msec
    $ time (cat version version version version version version version)
Signed-off-by: NBill Richardson <wfrichar@chromium.org>
Reviewed-by: NOlof Johansson <olofj@chromium.org>
Tested-by: NDoug Anderson <dianders@chromium.org>
Reviewed-by: NBenson Leung <bleung@chromium.org>
Signed-off-by: NJavier Martinez Canillas <javier.martinez@collabora.co.uk>
Tested-by: NGwendal Grignou <gwendal@chromium.org>
Reviewed-by: NGwendal Grignou <gwendal@chromium.org>
Signed-off-by: NOlof Johansson <olof@lixom.net>

This adds the first few sysfs attributes for the Chrome OS EC. These
controls are made available under /sys/devices/virtual/chromeos/cros_ec

    flashinfo   - display current flash info
    reboot      - tell the EC to reboot in various ways
    version     - information about the EC software and hardware

Future changes will build on this to add additional controls.

From a root shell, you should be able to do things like this:

    cd /sys/devices/virtual/chromeos/cros_ec
    cat flashinfo
    cat version
    echo rw > reboot
    cat version
    echo ro > reboot
    cat version
    echo rw > reboot
    cat version
    echo cold > reboot

That last command will reboot the AP too.
Signed-off-by: NBill Richardson <wfrichar@chromium.org>
Reviewed-by: NOlof Johansson <olofj@chromium.org>
Signed-off-by: NJavier Martinez Canillas <javier.martinez@collabora.co.uk>
Tested-by: NGwendal Grignou <gwendal@chromium.org>
Reviewed-by: NGwendal Grignou <gwendal@chromium.org>
Signed-off-by: NOlof Johansson <olof@lixom.net>

This patch adds a device interface to access the
Chrome OS Embedded Controller from user-space.
Signed-off-by: NBill Richardson <wfrichar@chromium.org>
Reviewed-by: NSimon Glass <sjg@google.com>
Signed-off-by: NJavier Martinez Canillas <javier.martinez@collabora.co.uk>
Reviewed-by: NGwendal Grignou <gwendal@chromium.org>
Tested-by: NGwendal Grignou <gwendal@chromium.org>
Reviewed-by: NGwendal Grignou <gwendal@chromium.org>
Signed-off-by: NOlof Johansson <olof@lixom.net>

Chromebooks have an Embedded Controller (EC) that is used to
implement various functions such as keyboard, power and battery.

The AP can communicate with the EC through different bus types
such as I2C, SPI or LPC.

The cros_ec mfd driver is then composed of a core driver that
register the sub-devices as mfd cells and provide a high level
communication interface that is used by the rest of the kernel
and bus specific interfaces modules.

Each connection method then has its own driver, which register
with the EC driver interface-agnostic interface.

Currently, there are drivers to communicate with the EC over
I2C and SPI and this driver adds support for LPC.
Signed-off-by: NBill Richardson <wfrichar@chromium.org>
Signed-off-by: NJavier Martinez Canillas <javier.martinez@collabora.co.uk>
Tested-by: NGwendal Grignou <gwendal@chromium.org>
Reviewed-by: NGwendal Grignou <gwendal@chromium.org>
Signed-off-by: NOlof Johansson <olof@lixom.net>

A platform_driver does not need to set an owner, it will be populated by the
driver core.
Signed-off-by: NWolfram Sang <wsa@the-dreams.de>

The existing implementation which encodes the configuration as a binary
blob in platform data is unsatisfactory since it requires a kernel
recompile for the configuration to be changed, and it doesn't deal well
with firmware changes that move values around on the chip.

Atmel define an ASCII format for the configuration which can be exported
from their tools. This patch implements a parser for that format which
loads the configuration via the firmware loader and sends it to the MXT
chip.
Signed-off-by: NNick Dyer <nick.dyer@itdev.co.uk>
Acked-by: NBenson Leung <bleung@chromium.org>
Acked-by: NYufeng Shen <miletus@chromium.org>
Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>

Limit the number of times we allow deferred probing to attempt to add
i2c devices. This will help with some device flakiness at probe time.
For example, some touchpads and touchscreens may be in transition between
bootloader and operational mode and may appear at neither address briefly.

Adapters, however, have no limit as it depends on when the i2c adapter driver
module is loaded. The module may even be loaded manually by the user using
modprobe or insmod.

By default, set MAX_I2C_DEVICE_DEFERALS to 5.

Based on this patch from the chromeos-kernel :
https://chromium-review.googlesource.com/168130Signed-off-by: NBenson Leung <bleung@chromium.org>
Signed-off-by: NOlof Johansson <olof@lixom.net>

Add support for the acer c720p touchscreen.
Tested manually by using the touchscreen on the acer c720p-2664

Based on the following patch by Dave Parker <dparker@chromium.org>:
https://chromium-review.googlesource.com/#/c/167136/Signed-off-by: NMichael Mullin <masmullin@gmail.com>
Reviewed-by: NBenson Leung <bleung@chromium.org>
Signed-off-by: NOlof Johansson <olof@lixom.net>

Turns out that DMI_SYSTEM_VENDOR is actually the native vendor of each
Chromebook/box. I tested the original patch on a Pixel that -- surprise,
has Google as vendor. *facepalm*.

The only other data I can think of to probe on is Google_* in the version
string.  Checking with our firmware team, all systems should have this
and nothing else than Chrome hardware should have the coreboot + Google_*
combination to date.

So, we'll switch to this. For future platforms we are going to move to
using an ACPI device to configure this instead of a DMI table (yay!),
so longer-term that will sort itself out.
Signed-off-by: NOlof Johansson <olof@lixom.net>
Reviewed-by: NBenson Leung <bleung@chromium.org>

added blank lines after declarations in some places
Signed-off-by: NRobin Schroer <sulamiification@gmail.com>
Signed-off-by: NOlof Johansson <olof@lixom.net>

Add support for Leon touch devices, which is the same as
falco/peppy/wolf on the same buses using the LynxPoint-LP I2C
via the i2c-designware-pci driver.

Based on these patches from the chromeos-3.8 kernel:
https://chromium-review.googlesource.com/168351
https://chromium-review.googlesource.com/173445Signed-off-by: NGene Chen <gene.chen@intel.com>
Signed-off-by: NBenson Leung <bleung@chromium.org>
Tested-by: NScot Doyle <lkml14@scotdoyle.com>
Reviewed-by: NMika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: NOlof Johansson <olof@lixom.net>

Add support for Dell Chromebook 11's touch device, which is the same
as falco/peppy on the same bus using the LynxPoint-LP I2C via the
i2c-designware-pci driver.

Based on these patches from the chromeos-3.8 kernel:
https://chromium-review.googlesource.com/#/c/65320/
https://chromium-review.googlesource.com/#/c/174664/Signed-off-by: NMohammed Habibulla <moch@chromium.org>
Signed-off-by: NBenson Leung <bleung@chromium.org>
Reviewed-by: NMika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: NOlof Johansson <olof@lixom.net>

Add support for the trackpad on HP Chromebook 14.
Signed-off-by: NBenson Leung <bleung@chromium.org>
Reviewed-by: NMika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: NOlof Johansson <olof@lixom.net>

Acer C720 has touchpad and light sensor connected to a separate I2C buses.
Since the designware I2C host controller driver has two instances on this
particular machine we need a way to match the correct instance. Add support
for this and then register both C720 touchpad and light sensor.

This code is based on following patch from Benson Leung:

https://patchwork.kernel.org/patch/3074411/Signed-off-by: NMika Westerberg <mika.westerberg@linux.intel.com>
Tested-by: NKirill A. Shutemov <kirill.shutemov@linux.intel.com>
Signed-off-by: NBenson Leung <bleung@chromium.org>
Reviewed-by: NMika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: NOlof Johansson <olof@lixom.net>

By reading the touchscreen configuration from the settings that the
maXTouch chip is actually using, we can remove some platform data.

The matrix size is not used for anything, and results in some rather
confusing code to re-read it because it may change when configuration
is downloaded, so don't print it out.
Signed-off-by: NNick Dyer <nick.dyer@itdev.co.uk>
Acked-by: NBenson Leung <bleung@chromium.org>
Acked-by: NYufeng Shen <miletus@chromium.org>
Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>

 * The mapping of the GPIO numbers into the T19 status byte varies between
   different maXTouch chips. Some have up to 7 GPIOs. Allowing a keycode array
   of up to 8 items is simpler and more generic. So replace #define with
   configurable number of keys which also allows the removal of is_tp.
 * Rename platform data parameters to include "t19" to prevent confusion with
   T15 key array.
 * Probe aborts early on when pdata is NULL, so no need to check.
 * Move "int i" to beginning of function (mixed declarations and code)
 * Use API calls rather than __set_bit()
 * Remove unused dev variable.
Signed-off-by: NNick Dyer <nick.dyer@itdev.co.uk>
Acked-by: NYufeng Shen <miletus@chromium.org>
Reviewed-by: NHenrik Rydberg <rydberg@euromail.se>
Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>

It is not necessary to download these values to the maXTouch chip on every
probe, since they are stored in NVRAM. It makes life difficult when tuning
the device to keep them in sync with the config array/file, and requires a
new kernel build for minor tweaks.

These parameters only represent a tiny subset of the available
configuration options, tracking all of these options in platform data would
be a endless task. In addition, different versions of maXTouch chips may
have these values in different places or may not even have them at all.

Having these values also makes life more complex for device tree and other
platforms where having to define a static configuration isn't helpful.
Signed-off-by: NNick Dyer <nick.dyer@itdev.co.uk>
Acked-by: NBenson Leung <bleung@chromium.org>
Acked-by: NYufeng Shen <miletus@chromium.org>
Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>

We have registered platform driver and device when module
init, and need unregister them when module exit.
Signed-off-by: NWei Yongjun <yongjun_wei@trendmicro.com.cn>
Signed-off-by: NOlof Johansson <olof@lixom.net>

Not used outside of the file, so declaration should be static. Picked up by
sparse:

drivers/platform/chrome/chromeos_laptop.c:44:12: warning: symbol
    'i2c_adapter_names' was not declared. Should it be static?
Signed-off-by: NOlof Johansson <olof@lixom.net>
Reviewed-by: NBenson Leung <bleung@chromium.org>

__initdata tag should be placed between the variable name and equal
sign for the variable to be placed in the intended .init.data section.
Signed-off-by: NBenson Leung <bleung@chromium.org>
Signed-off-by: NOlof Johansson <olof@lixom.net>

Further refactor chromeos_laptop, adding a probe function.
Init will call dmi_check_system, but will only use the match to select
a chromeos_laptop structure of the current board.

Probe will add the devices, and on errors return -EPROBE_DEFER.
If i2c adapters are loaded after chromeos_laptop inits, the deferred
probe will instantiate the peripherals when the bus appears.
Signed-off-by: NBenson Leung <bleung@chromium.org>
Reviewed-by: NAaron Durbin <adurbin@chromium.org>
Signed-off-by: NOlof Johansson <olof@lixom.net>

The previous code had a single DMI matching entry
for each device on a board. Instead provide a single
DMI entry for each board which references a structure
about each board that lists the associated peripherals.
This allows for a lower number of DMI matching sequences
as well making it easier to add new boards.
Signed-off-by: NAaron Durbin <adurbin@chromium.org>
Signed-off-by: NBenson Leung <bleung@chromium.org>
Signed-off-by: NOlof Johansson <olof@lixom.net>

Add the ramoops pstore device so that we get logs of panics across reboots.
Signed-off-by: NOlof Johansson <olof@lixom.net>

It makes sense to split out the Chromebook/Chromebox hardware platform
drivers to a separate subdirectory, since some of it will be shared
between ARM and x86.

This moves over the existing chromeos_laptop driver without making
any other changes, and adds appropriate Kconfig entries for the new
directory. It also adds a MAINTAINERS entry for the new subdir.
Signed-off-by: NOlof Johansson <olof@lixom.net>
Signed-off-by: NMatthew Garrett <matthew.garrett@nebula.com>