summaryrefslogtreecommitdiff
path: root/drivers/platform/chrome/cros_ec_lightbar.c
AgeCommit message (Collapse)Author
2017-12-15cros_ec: Move cros_ec_dev module to drivers/mfdThierry Escande
The cros_ec_dev module is responsible for registering the MFD devices attached to the ChromeOS EC. This patch moves this module to drivers/mfd so calls to mfd_add_devices() are not done from outside the MFD subtree anymore. Signed-off-by: Thierry Escande <thierry.escande@collabora.com> Reviewed-by: Gwendal Grignou <gwendal@chromium.org> Tested-by: Guenter Roeck <groeck@chromium.org> Signed-off-by: Lee Jones <lee.jones@linaro.org>
2017-12-15cros_ec: Split cros_ec_devs moduleThierry Escande
This patch splits the cros_ec_devs module in two parts with a cros_ec_dev module responsible for handling MFD devices registration and a cros_ec_ctl module responsible for handling the various user-space interfaces. For consistency purpose, the driver name for the cros_ec_dev module is now cros-ec-dev instead of cros-ec-ctl. In the next commit, the new cros_ec_dev module will be moved to the MFD subtree so mfd_add_devices() calls are not done from outside MFD. Signed-off-by: Thierry Escande <thierry.escande@collabora.com> Reviewed-by: Gwendal Grignou <gwendal@chromium.org> Tested-by: Guenter Roeck <groeck@chromium.org> Signed-off-by: Lee Jones <lee.jones@linaro.org>
2017-06-23platform/chrome: cros_ec_lightbar - Avoid I2C xfer to EC during suspendJeffery Yu
A Mutex lock in cros_ec_cmd_xfer which may be held by frozen Userspace thread during system suspending. So should not call this routine in suspend thread. Signed-off-by: Jeffery Yu <jefferyy@nvidia.com> Signed-off-by: Guenter Roeck <groeck@chromium.org> Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com> Signed-off-by: Benson Leung <bleung@chromium.org>
2017-06-23platform/chrome: cros_ec_lightbar - Add userspace lightbar control bit to ECEric Caruso
Some devices might want to turn off the lightbar if e.g. the system turns the screen off due to idleness. This prevents the kernel from going through its normal suspend/resume pathways. Signed-off-by: Eric Caruso <ejcaruso@chromium.org> Signed-off-by: Guenter Roeck <groeck@chromium.org> Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com> Signed-off-by: Benson Leung <bleung@chromium.org>
2017-06-23platform/chrome: cros_ec_lightbar - Control of suspend/resume lightbar sequenceEric Caruso
Don't let EC control suspend/resume sequence. If the EC controls the lightbar and sets the sequence when it notices the chipset transitioning between states, we can't make exceptions for cases where we don't want to activate the lightbar. Instead, let's move the suspend/resume notifications into the kernel so we can selectively play the sequences. Signed-off-by: Eric Caruso <ejcaruso@chromium.org> Signed-off-by: Guenter Roeck <groeck@chromium.org> Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com> Acked-by: Lee Jones <lee.jones@linaro.org> Signed-off-by: Benson Leung <bleung@chromium.org>
2017-06-23platform/chrome: cros_ec_lightbar - Add lightbar program feature to sysfsEric Caruso
Add a program feature so we can upload and run programs for lightbar sequences. We should be able to use this to shift sequences out of the EC and save space there. $ cat <suitable program bin> > /sys/devices/.../cros_ec/program $ echo program > /sys/devices/.../cros_ec/sequence Signed-off-by: Eric Caruso <ejcaruso@chromium.org> Signed-off-by: Guenter Roeck <groeck@chromium.org> Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com> Acked-by: Lee Jones <lee.jones@linaro.org> Signed-off-by: Benson Leung <bleung@chromium.org>
2016-05-11platform/chrome: cros_ec_lightbar - use name instead of ID to hide lightbar ↵Clinton Sprain
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>
2016-05-11platform/chrome: use to_platform_device()Geliang Tang
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>
2015-10-07platform/chrome: cros_ec: Fix possible leak in led_rgb_store()Christian Engelmayer
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>
2015-10-07platform/chrome: cros_ec: Fix leak in sequence_store()Christian Engelmayer
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>
2015-06-15mfd: cros_ec: Support multiple EC in a systemGwendal Grignou
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>
2015-06-15mfd: cros_ec: rev cros_ec_commands.hStephen Barber
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>
2015-06-15mfd: cros_ec: Use a zero-length array for command dataJavier Martinez Canillas
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>
2015-03-04platform/chrome: cros_ec_lightbar - fix duplicate const warningOlof Johansson
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>
2015-02-26platform/chrome: Expose Chrome OS Lightbar to usersBill Richardson
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>