Age | Commit message (Collapse) | Author |
|
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>
|
|
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: a841178445bb ('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 bff3c624dc7261a084a4d25a0b09c3fb0fec872a.
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>
|
|
attributes
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>
|
|
Use to_platform_device() instead of open-coding it.
Signed-off-by: Geliang Tang <geliangtang@163.com>
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 d80d134182ba ("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: d80d134182ba ("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 6db07b633658 ("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 d12bbcd3ea44 ("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>
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/dtor/input
Pull input subsystem updates from Dmitry Torokhov:
"Drivers, drivers, drivers... No interesting input core changes this
time"
* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/dtor/input: (74 commits)
Input: elan_i2c - use iap_version to get firmware information
Input: max8997_haptic - fix module alias
Input: elan_i2c - fix typos for validpage_count
Input: psmouse - add small delay for IBM trackpoint pass-through mode
Input: synaptics - fix handling of disabling gesture mode
Input: elan_i2c - enable ELAN0100 acpi panels
Input: gpio-keys - report error when disabling unsupported key
Input: sur40 - fix error return code
Input: sentelic - silence some underflow warnings
Input: zhenhua - switch to using bitrev8()
Input: cros_ec_keyb - replace KEYBOARD_CROS_EC dependency
Input: cap11xx - add LED support
Input: elants_i2c - fix for devm_gpiod_get API change
Input: elan_i2c - enable asynchronous probing
Input: elants_i2c - enable asynchronous probing
Input: elants_i2c - wire up regulator support
Input: do not emit unneeded EV_SYN when suspending
Input: elants_i2c - disable idle mode before updating firmware
MAINTAINERS: Add maintainer for atmel_mxt_ts
Input: atmel_mxt_ts - remove warning on zero T44 count
...
|
|
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 1b84f2a4cd4a ("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>
|
|
Fix the following sparse warning:
drivers/platform/chrome/cros_ec_dev.c:64:45: sparse: Unknown escape '%'
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>
|
|
A platform_driver does not need to set an owner, it will be populated by the
driver core.
Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
|
|
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>
|
|
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/168130
Signed-off-by: Benson Leung <bleung@chromium.org>
Signed-off-by: Olof 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: Michael Mullin <masmullin@gmail.com>
Reviewed-by: Benson Leung <bleung@chromium.org>
Signed-off-by: Olof Johansson <olof@lixom.net>
|