Check whether the ChromeOS Embedded Controller is a sensor hub and in
such case issue a command to get the number of sensors and register them
all.
Signed-off-by: Gwendal Grignou <gwendal@chromium.org>
Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
Reviewed-by: Guenter Roeck <groeck@chromium.org>
Acked-by: Olof Johansson <olof@lixom.net>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
Use the EC_CMD_GET_FEATURES message to check the supported features for
each MCU.
Signed-off-by: Vincent Palatin <vpalatin@chromium.org>
[tomeu: adapted to changes in mainline]
Signed-off-by: Tomeu Vizoso <tomeu.vizoso@collabora.com>
[enric: remove references to USB PD feature and do it more generic]
Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
Reviewed-by: Guenter Roeck <groeck@chromium.org>
For the MFD changes:
Acked-by: Lee Jones <lee.jones@linaro.org>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
Newer revisions of the ChromeOS EC add more events besides the keyboard
ones. So handle interrupts in the MFD driver and let consumers register
for notifications for the events they might care.
To keep backward compatibility, if the EC doesn't support MKBP event, we
fall back to the old MKBP key matrix host command.
Cc: Randall Spangler <rspangler@chromium.org>
Cc: Vincent Palatin <vpalatin@chromium.org>
Cc: Benson Leung <bleung@chromium.org>
Signed-off-by: Vic Yang <victoryang@google.com>
Signed-off-by: Tomeu Vizoso <tomeu.vizoso@collabora.com>
Tested-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
Acked-by: Olof Johansson <olof@lixom.net>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
This set of changes improve some aspects of the atomic API as well as
make use of this new API in the regulator framework to allow properly
dealing with critical regulators controlled by a PWM.
Aside from that there's a bunch of updates and cleanups for existing
drivers, as well as the addition of new drivers for the Broadcom iProc,
STMPE and ChromeOS EC controllers.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
iQI2BAABCAAgBQJXpLFKGRx0aGllcnJ5LnJlZGluZ0BnbWFpbC5jb20ACgkQ3SOs
138+s6E2Nw/9FggtgYlVQRS5lzwTKxQI/5HMlOfdyH84S76fUS8uAxvEsZvyHXZ7
NiwCJMkmMqPHMlrfuXacs4nueKz3jvy8csaffH5T2yHf0ZPGmkxBsdX97rvQp3z/
WTUXX8vo8fiEPQSXQOUzIYk10s7CBO2094uL8FBqfYeSySY3Ti35SpmZSQKVd1LS
A1rR/qRgNbIlhI7+L5CotdrNMkHXqHZIHDyXO1dWBDVL+3MU3IPpB//J/WjU/OMs
5MHEtTr7943s8LQYhM1p5PFDn8ehe31L1quSswmMTLuepPrTUjD31476VYW8p8gg
lzOv5JF5b8Rkw0B+4vDC0z/OPZA47tg8DfiS9Sa1SrCGxslOH7pvI7m9dV89FOc2
/hA1n048jBhIrHPylXZ+hUPKNM0WTwFrHVxROgtEb6/wtYskgOFGQrYKpD4FtH+j
zqXxvCRMX4ZLLXy2QO4GAW3dv51pLjiM2yxVWtM1lWFWiKKvRoqHiFcnmCJJwQ4T
NXUPnyt+G/GCtpVHlMtHW9YszJ650ECt+H8I1EhuGLkpOXncCPdmw34oR1wSmMi3
+1yjCvZV8bNJLt2GQDpoFEUc1dqY6g/SLqm9sz+W69QYA0oDt9JpFK+RFw118282
EX24GT9+PYe0kMt1WWopjHeFZ+6HhsG/ODwOUOaG/8kp6qZLB4EKP9k=
=TdEI
-----END PGP SIGNATURE-----
Merge tag 'pwm/for-4.8-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/thierry.reding/linux-pwm
Pull pwm updates from Thierry Reding:
"This set of changes improve some aspects of the atomic API as well as
make use of this new API in the regulator framework to allow properly
dealing with critical regulators controlled by a PWM.
Aside from that there's a bunch of updates and cleanups for existing
drivers, as well as the addition of new drivers for the Broadcom
iProc, STMPE and ChromeOS EC controllers"
* tag 'pwm/for-4.8-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/thierry.reding/linux-pwm: (44 commits)
regulator: pwm: Document pwm-dutycycle-unit and pwm-dutycycle-range
regulator: pwm: Support extra continuous mode cases
pwm: Add ChromeOS EC PWM driver
dt-bindings: pwm: Add binding for ChromeOS EC PWM
mfd: cros_ec: Add EC_PWM function definitions
mfd: cros_ec: Add cros_ec_cmd_xfer_status() helper
pwm: atmel: Use of_device_get_match_data()
pwm: atmel: Fix checkpatch warnings
pwm: atmel: Fix disabling of PWM channels
dt-bindings: pwm: Add R-Car H3 device tree bindings
pwm: rcar: Use ARCH_RENESAS
pwm: tegra: Add support for Tegra186
dt-bindings: pwm: tegra: Add compatible string for Tegra186
pwm: tegra: Avoid overflow when calculating duty cycle
pwm: tegra: Allow 100 % duty cycle
pwm: tegra: Add support for reset control
pwm: tegra: Rename mmio_base to regs
pwm: tegra: Remove useless padding
pwm: tegra: Drop NUM_PWM macro
pwm: lpc32xx: Set PWM_PIN_LEVEL bit to default value
...
So that callers of cros_ec_cmd_xfer() don't have to repeat boilerplate
code when checking for errors from the EC side.
Signed-off-by: Tomeu Vizoso <tomeu.vizoso@collabora.com>
Reviewed-by: Benson Leung <bleung@chromium.org>
Signed-off-by: Brian Norris <briannorris@chromium.org>
Acked-by: Lee Jones <lee.jones@linaro.org>
Tested-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
We verify "u_cmd.outsize" and "u_cmd.insize" but we need to make sure
that those values have not changed between the two copy_from_user()
calls. Otherwise it could lead to a buffer overflow.
Additionally, cros_ec_cmd_xfer() can set s_cmd->insize to a lower value.
We should use the new smaller value so we don't copy too much data to
the user.
Reported-by: Pengfei Wang <wpengfeinudt@gmail.com>
Fixes: a841178445 ('mfd: cros_ec: Use a zero-length array for command data')
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Reviewed-by: Kees Cook <keescook@chromium.org>
Tested-by: Gwendal Grignou <gwendal@chromium.org>
Cc: <stable@vger.kernel.org> # v4.2+
Signed-off-by: Olof Johansson <olof@lixom.net>
This reverts commit bff3c624dc.
Board "Leon" is otherwise known as "Toshiba CB35" and we already have
the entry that supports that board as of this commit :
963cb6f platform/chrome: chromeos_laptop - Add Toshiba CB35 Touch
Remove this duplicate.
Signed-off-by: Benson Leung <bleung@chromium.org>
Signed-off-by: Olof Johansson <olof@lixom.net>
The upcoming Elan Wolf (Dell Chromebook 11) devices need to know to look
for Elan touchpads on the i2c bus so that they will be functional.
Based on the chromeos-kernel commit :
https://chromium-review.googlesource.com/198283
Signed-off-by: Charlie Mooney <charliemooney@chromium.org>
Signed-off-by: Benson Leung <bleung@chromium.org>
Signed-off-by: Olof Johansson <olof@lixom.net>
Add the elan trackpad to the Acer C720 (peppy) list, as it is an alternate
trackpad option. It may exist at i2c address 0x15.
Based on this change from the chromeos kernel :
https://chromium-review.googlesource.com/186253
Signed-off-by: Benson Leung <bleung@chromium.org>
Signed-off-by: Olof Johansson <olof@lixom.net>
compat_ioctl has to be populated for 32 bit userspace applications to work
with 64 bit kernels.
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Tested-by: Brian Norris <briannorris@chromium.org>
Signed-off-by: Olof Johansson <olof@lixom.net>
Lightbar attributes are hidden if the ID of the device is not 0 (the
assumption being that 0 = cros_ec = might have a lightbar, 1 = cros_pd =
hide); however, sometimes these devices get IDs 1 and 2 (or something
else) instead of IDs 0 and 1. This prevents the lightbar attributes from
appearing when they should.
Proposed change is to instead check whether the name assigned to the
device is CROS_EC_DEV_NAME (true for cros_ec, false for cros_pd).
Signed-off-by: Clinton Sprain <clintonsprain@gmail.com>
Signed-off-by: Olof Johansson <olof@lixom.net>
Prevent memory scribble by checking that ioctl buffer size parameters
are sane.
Without this check, on 32 bits system, if .insize = 0xffffffff - 20 and
.outsize the amount to scribble, we would overflow, allocate a small
amounts and be able to write outside of the malloc'ed area.
Adding a hard limit allows argument checking of the ioctl. With the
current EC, it is expected .insize and .outsize to be at around 512 bytes
or less.
Signed-off-by: Gwendal Grignou <gwendal@chromium.org>
Signed-off-by: Olof Johansson <olof@lixom.net>
This is a driver for ACPI-based keyboard backlight LEDs found on
Chromebooks. The driver locates \\_SB.KBLT ACPI device and exports
backlight as "chromeos::kbd_backlight" LED class device in sysfs.
Signed-off-by: Simon Que <sque@chromium.org>
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Tested-by: Evan McClain <aeroevan@gmail.com>
Signed-off-by: Dmitry Torokhov <dtor@chromium.org>
Signed-off-by: Olof Johansson <olof@lixom.net>
Accidentally specified a smaller record size, bring it back
to the same size as we had when we used the config file.
Signed-off-by: Olof Johansson <olofj@chromium.org>
Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
Reviewed-by: Sameer Nanda <snanda@chromium.org>
Signed-off-by: Olof Johansson <olof@lixom.net>
In order to handle the firmware placing the ramoops buffer
in a different location than the kernel is configured to look
probe for an ACPI device specified by GOOG9999 acpi id. If
no device is found or the first memory resource is not defined
properly fall back to the configured base and length.
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Signed-off-by: Ben Zhang <benzh@chromium.org>
Signed-off-by: Filipe Brandenburger <filbranden@chromium.org>
Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
Reviewed-by: Olof Johansson <olofj@chromium.org>
Signed-off-by: Olof Johansson <olof@lixom.net>
Add support for Leon touch devices, which is the same as
slippy/falco/peppy/wolf on the same buses using the LynxPoint-LP I2C via
the i2c-designware-pci driver.
Based on the following patch:
https://chromium-review.googlesource.com/#/c/168351/
Signed-off-by: Gene Chen <gene.chen@intel.com>
Reviewed-by: Benson Leung <bleung@chromium.org>
Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
Signed-off-by: Olof Johansson <olof@lixom.net>
Commit d80d134182 ("i2c: designware: Move common probe code into
i2c_dw_probe()") caused the I2C adapter lookup code here to fail for PCI
enumerated i2c-designware because commit changed the adapter name but
didn't update it here.
Fix the I2C adapter lookup by using the "Synopsys DesignWare I2C adapter"
name.
Reported-by: Jeremiah Mahler <jmmahler@gmail.com>
Fixes: d80d134182 ("i2c: designware: Move common probe code into i2c_dw_probe()")
Signed-off-by: Jarkko Nikula <jarkko.nikula@linux.intel.com>
Tested-by: Jeremiah Mahler <jmmahler@gmail.com>
Signed-off-by: Olof Johansson <olof@lixom.net>
Some EC implementations include a small nvram space used to store
verified boot context data. This patch offers a way to expose this
data to userspace.
Reviewed-by: Javier Martinez Canillas <javier@osg.samsung.com>
Signed-off-by: Emilio López <emilio.lopez@collabora.co.uk>
Signed-off-by: Olof Johansson <olof@lixom.net>
Function led_rgb_store() contains some direct returns in error cases that
leak the already allocated cros_ec_command message structure. Make sure
that 'msg' is freed in all exit paths. Detected by Coverity CID 1309666.
Signed-off-by: Christian Engelmayer <cengelma@gmx.at>
Signed-off-by: Olof Johansson <olof@lixom.net>
The allocated cros_ec_command message structure is not freed in function
sequence_store(). Make sure that 'msg' is freed in all exit paths.
Detected by Coverity CID 1309667.
Signed-off-by: Christian Engelmayer <cengelma@gmx.at>
Signed-off-by: Olof Johansson <olof@lixom.net>
With Chrome running on 64-bit ARM devices, add ARM64 to the list of
supported architectures.
Signed-off-by: Thierry Reding <treding@nvidia.com>
[olof; Fixed up due to addition of COMPILE_TEST]
Signed-off-by: Olof Johansson <olof@lixom.net>
If the cros_ec_dev driver is built as a module, modalias information is
not filled so the module is not autoloaded. Add a platform device table
and use the MODULE_DEVICE_TABLE() macro to export that information in
the module so user-space can match the modalias uevent and autoload it.
Signed-off-by: Javier Martinez Canillas <javier.martinez@collabora.co.uk>
Signed-off-by: Olof Johansson <olof@lixom.net>
Since the verion of ACPI in Google BIOS does not enumerate the devices
in the LPC bus, the cros_ec_lpc driver resorts to DMI data to check if
a system is supported by the driver and autoload if built as a module.
Add information about the Google Pixel 2 to the DMI device table.
Signed-off-by: Javier Martinez Canillas <javier.martinez@collabora.co.uk>
Signed-off-by: Olof Johansson <olof@lixom.net>
Commit 6db07b6336 ("mfd: cros_ec: Check result code from EC messages")
added a common cros_ec_check_result() function that can be used to check
the ec_msg->result for errors and warns about them.
Use the existing function instead of duplicating same check in the driver.
Signed-off-by: Javier Martinez Canillas <javier.martinez@collabora.co.uk>
Reviewed-by: Gwendal Grignou <gwendal@chromium.org>
Tested-by: Gwendal Grignou <gwendal@chromium.org>
Signed-off-by: Olof Johansson <olof@lixom.net>
The ChromeOS EC LPC and chardev drivers depend on CROS_EC_PROTO but
MFD_CROS_EC select CROS_EC_PROTO instead. Mixing select and depends
on is bad practice as it may lead to circular Kconfig dependencies.
Since the platform devices that are matched with these drivers are
registered by the ChromeOS EC mfd driver, they really depend on
MFD_CROS_EC. And because this config option selects CROS_EC_PROTO,
that dependency is met as well. So make the drivers to depend on
MFD_CROS_EC instead of CROS_EC_PROTO.
Signed-off-by: Javier Martinez Canillas <javier@osg.samsung.com>
Signed-off-by: Olof Johansson <olof@lixom.net>
This reverts commit d12bbcd3ea ("platform/chrome: Don't make
CHROME_PLATFORMS depends on X86 || ARM") since it was found to
not be the correct fix for the MFD_CROS_EC config unmet direct
dependencies warning.
The correct solution was to add the needed dependencies to the
MFD_CROS_EC symbol. Besides the revert, this patch extends the
CHROME_PLATFORMS symbol dependencies and adds || COMPILE_TEST
to allow drivers to have build coverage on other architectures.
Suggested-by: Geert Uytterhoeven <geert@linux-m68k.org>
Signed-off-by: Javier Martinez Canillas <javier@osg.samsung.com>
Signed-off-by: Olof Johansson <olof@lixom.net>
The hardcoded 0x83 CTRL setting overrides other settings in that byte,
enabling extra reporting that may not be useful on a particular platform.
Implement improved suspend mechanism via deep sleep. By writing zero to
both the active and idle cycle times the maXTouch device can be put into a
deep sleep mode, using minimal power. It is necessary to issue a calibrate
command after the chip has spent any time in deep sleep, however a soft
reset is unnecessary.
Use the old method on Chromebook Pixel via platform data option.
This patch also deals with the situation where the power configuration is
zero on probe, which would mean that the device never wakes up to execute
commands.
After a config download, the T7 power configuration may have changed so it
is necessary to re-read it.
Signed-off-by: Nick Dyer <nick.dyer@itdev.co.uk>
Acked-by: Benson Leung <bleung@chromium.org>
Acked-by: Yufeng Shen <miletus@chromium.org>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
The Chrome platform support depends on X86 || ARM because there are
only Chromebooks using those architectures. But only some drivers
depend on a given architecture, and the ones that do already have
a dependency on their specific Kconfig symbol entries.
An option is to also make CHROME_PLATFORMS depends on || COMPILE_TEST
but is more future proof to remove the dependency and let the drivers
be built in all architectures if possible to have more build coverage.
Acked-by: Olof Johansson <olof@lixom.net>
Signed-off-by: Javier Martinez Canillas <javier.martinez@collabora.co.uk>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
Chromebooks can have more than one Embedded Controller so the
cros_ec device id has to be incremented for each EC registered.
Add a new structure to represent multiple EC as different char
devices (e.g: /dev/cros_ec, /dev/cros_pd). It connects to
cros_ec_device and allows sysfs inferface for cros_pd.
Also reduce number of allocated objects, make chromeos sysfs
class object a static and add refcounting to prevent object
deletion while command is in progress.
Signed-off-by: Gwendal Grignou <gwendal@chromium.org>
Reviewed-by: Dmitry Torokhov <dtor@chromium.org>
Signed-off-by: Javier Martinez Canillas <javier.martinez@collabora.co.uk>
Tested-by: Heiko Stuebner <heiko@sntech.de>
Acked-by: Lee Jones <lee.jones@linaro.org>
Acked-by: Olof Johansson <olof@lixom.net>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
Add proto v3 support to the SPI, I2C, and LPC.
Signed-off-by: Stephen Barber <smbarber@chromium.org>
Signed-off-by: Javier Martinez Canillas <javier.martinez@collabora.co.uk>
Tested-by: Heiko Stuebner <heiko@sntech.de>
Reviewed-by: Gwendal Grignou <gwendal@chromium.org>
Tested-by: Gwendal Grignou <gwendal@chromium.org>
Acked-by: Lee Jones <lee.jones@linaro.org>
Acked-by: Olof Johansson <olof@lixom.net>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
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: Stephen Barber <smbarber@chromium.org>
Signed-off-by: Javier Martinez Canillas <javier.martinez@collabora.co.uk>
Reviewed-by: Gwendal Grignou <gwendal@chromium.org>
Tested-by: Gwendal Grignou <gwendal@chromium.org>
Tested-by: Heiko Stuebner <heiko@sntech.de>
Acked-by: Lee Jones <lee.jones@linaro.org>
Acked-by: Olof Johansson <olof@lixom.net>
Signed-off-by: Lee 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: Lee Jones <lee.jones@linaro.org>
Signed-off-by: Javier Martinez Canillas <javier.martinez@collabora.co.uk>
Tested-by: Heiko Stuebner <heiko@sntech.de>
Acked-by: Lee Jones <lee.jones@linaro.org>
Acked-by: Olof Johansson <olof@lixom.net>
Signed-off-by: Lee 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: Stephen Barber <smbarber@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Signed-off-by: Javier Martinez Canillas <javier.martinez@collabora.co.uk>
Tested-by: Heiko Stuebner <heiko@sntech.de>
Reviewed-by: Gwendal Grignou <gwendal@chromium.org>
Tested-by: Gwendal Grignou <gwendal@chromium.org>
Acked-by: Lee Jones <lee.jones@linaro.org>
Acked-by: Olof Johansson <olof@lixom.net>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
Commit 1b84f2a4cd ("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: Gwendal Grignou <gwendal@chromium.org>
Signed-off-by: Javier Martinez Canillas <javier.martinez@collabora.co.uk>
Tested-by: Heiko Stuebner <heiko@sntech.de>
Acked-by: Lee Jones <lee.jones@linaro.org>
Acked-by: Olof Johansson <olof@lixom.net>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
Parent and device were pointing to the same device structure.
Parent is unused, removed.
Signed-off-by: Gwendal Grignou <gwendal@chromium.org>
Tested-by: Stephen Barber <smbarber@chromium.org>
Tested-by: Heiko Stuebner <heiko@sntech.de>
Tested-by: Gwendal Grignou <gwendal@chromium.org>
Reviewed-by: Puthikorn Voravootivat <puthik@chromium.org>
Signed-off-by: Javier Martinez Canillas <javier.martinez@collabora.co.uk>
Signed-off-by: Lee 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: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Signed-off-by: Olof 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: Javier Martinez Canillas <javier.martinez@collabora.co.uk>
[olof: reworded commit message]
Signed-off-by: Olof 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: Javier Martinez Canillas <javier.martinez@collabora.co.uk>
Signed-off-by: Olof 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: Fengguang Wu <fengguang.wu@intel.com>
Signed-off-by: Olof Johansson <olof@lixom.net>
Fix the following sparse warning:
drivers/platform/chrome/cros_ec_lightbar.c:254:25: sparse: duplicate const
Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Olof Johansson <olofj@chromium.org>
Reviewed-by: Gwendal Grignou <gwendal@chromium.org>
Signed-off-by: Javier Martinez Canillas <javier.martinez@collabora.co.uk>
Signed-off-by: Olof 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: Bill Richardson <wfrichar@chromium.org>
Reviewed-by: Olof Johansson <olofj@chromium.org>
Tested-by: Doug Anderson <dianders@chromium.org>
Reviewed-by: Benson Leung <bleung@chromium.org>
Signed-off-by: Javier Martinez Canillas <javier.martinez@collabora.co.uk>
Tested-by: Gwendal Grignou <gwendal@chromium.org>
Reviewed-by: Gwendal Grignou <gwendal@chromium.org>
Signed-off-by: Olof 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: Bill Richardson <wfrichar@chromium.org>
Reviewed-by: Olof Johansson <olofj@chromium.org>
Signed-off-by: Javier Martinez Canillas <javier.martinez@collabora.co.uk>
Tested-by: Gwendal Grignou <gwendal@chromium.org>
Reviewed-by: Gwendal Grignou <gwendal@chromium.org>
Signed-off-by: Olof Johansson <olof@lixom.net>
This patch adds a device interface to access the
Chrome OS Embedded Controller from user-space.
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-by: Simon Glass <sjg@google.com>
Signed-off-by: Javier Martinez Canillas <javier.martinez@collabora.co.uk>
Reviewed-by: Gwendal Grignou <gwendal@chromium.org>
Tested-by: Gwendal Grignou <gwendal@chromium.org>
Reviewed-by: Gwendal Grignou <gwendal@chromium.org>
Signed-off-by: Olof 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: Bill Richardson <wfrichar@chromium.org>
Signed-off-by: Javier Martinez Canillas <javier.martinez@collabora.co.uk>
Tested-by: Gwendal Grignou <gwendal@chromium.org>
Reviewed-by: Gwendal Grignou <gwendal@chromium.org>
Signed-off-by: Olof Johansson <olof@lixom.net>
Updates to the Chromebook/box platform drivers:
- A bugfix to pstore registration that makes it also work on non-Google
systems
- Addition of new shipped Chromebooks (later models have more probing
through ACPI so the need for these updates will be less over time).
- A couple of minor coding style updates
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.14 (GNU/Linux)
iQIcBAABAgAGBQJT5v74AAoJEIwa5zzehBx3rwkQAJYMj3E+UXn679bcvoYyuNus
0ljuMIU0ZFGxrnNFmKQncC4fTvR5F+xLgGOXZvjSoDv5vU2fHGF1z9Bt/BphqyXk
oHfF1yRHXqeGJliyFriBLrkaVIRo54eg+QsKOeRYUqmEplC3qdI8GPCuCAjvXHYO
xwTYUCOZ5+SJUCHNMLwM8tJrE01hIou12BAcfD9KbWZbVKxzf0X/7OIMbaQR9ueE
xEgxIDbsMPVCXxa+NN9q1IM7wnQIXVUwlE1mDQgoA04EUphbVfdyao7fsfcnYB2D
3Ejr91YaJXSrUlEu9R5VsbGAlwHjBYGCoTSiHDNWdWSJF99qNhLYsOK7WCBHakKk
9XknM3lq03pkuSrmaNIrdyJvl1YA3VNkmTQTkqUP0r2gJZcaJZMxBFewZQRieUXK
HxbpaUEuSvozaNMN/ghN2pMVS3IhnNi7Wi4pP9bs2CyvwtSZjqFcDg/Bc0Kg8dFy
hBfkia0tjHAqMXc80h+dL9Ly8YAhJyhcX/5W9nYGqVndK0tn3pIkAfmk05in6KzZ
iPZDlBZID5BuFXhmIgCKd1kojk0dfXWq/0Nq1jLx9hHJi6BzvDF8ksHvr0TkK7p6
z45PBDY2H84fCXjRcEajj4YfyFnaRxqMiOVksekoX/7JIgt0ZeLITOKCFMb6nINM
IbK9wUrYlazVfwK9+gGG
=TuFN
-----END PGP SIGNATURE-----
Merge tag 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/olof/chrome-platform
Pull chrome platform updates from Olof Johansson:
"Updates to the Chromebook/box platform drivers:
- a bugfix to pstore registration that makes it also work on
non-Google systems
- addition of new shipped Chromebooks (later models have more probing
through ACPI so the need for these updates will be less over time).
- A couple of minor coding style updates"
* tag 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/olof/chrome-platform:
platform/chrome: chromeos_laptop - Add a limit for deferred retries
platform/chrome: Add support for the acer c720p touchscreen.
platform/chrome: pstore: fix dmi table to match all chrome systems
platform/chrome: coding style fixes
platform/chrome: chromeos_laptop - Add Toshiba CB35 Touch
platform/chrome: chromeos_laptop - Add Dell Chromebook 11 touch
platform/chrome: chromeos_laptop - Add HP Chromebook 14
platform/chrome: chromeos_laptop - Add support for Acer C720
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: Nick Dyer <nick.dyer@itdev.co.uk>
Acked-by: Benson Leung <bleung@chromium.org>
Acked-by: Yufeng Shen <miletus@chromium.org>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Enric Balletbo i Serra