summaryrefslogtreecommitdiff
path: root/include/linux/platform_data/cros_ec_proto.h
AgeCommit message (Collapse)Author
2021-10-31platform/chrome: cros_ec_proto: Use EC struct for featuresPrashant Malani
The Chrome EC's features are returned through an ec_response_get_features struct, but they are stored in an independent array. Although the two are effectively the same at present (2 unsigned 32 bit ints), there is the possibility that they could go out of sync. Avoid this by only using the EC struct to store the features. Signed-off-by: Prashant Malani <pmalani@chromium.org> Link: https://lore.kernel.org/r/20211004170716.86601-1-pmalani@chromium.org Signed-off-by: Benson Leung <bleung@chromium.org>
2021-09-30platform/chrome: cros_ec_proto: Add version for ec_commandPrashant Malani
Add a version parameter to cros_ec_command() for callers that may want to specify which version of the host command they would like to use. Signed-off-by: Prashant Malani <pmalani@chromium.org> Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com> Link: https://lore.kernel.org/r/20210930022403.3358070-5-pmalani@chromium.org
2021-09-30platform/chrome: cros_ec_proto: Make data pointers voidPrashant Malani
Convert the input and output data pointers for cros_ec_command() to void pointers so that the callers don't have to cast their custom structs to uint8_t *. Signed-off-by: Prashant Malani <pmalani@chromium.org> Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com> Link: https://lore.kernel.org/r/20210930022403.3358070-4-pmalani@chromium.org
2021-09-30platform/chrome: cros_usbpd_notify: Move ec_command()Prashant Malani
cros_ec_command() can be used by other modules too. So, move it to a common location and export it. This patch does not introduce any functional changes. Signed-off-by: Prashant Malani <pmalani@chromium.org> Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com> Link: https://lore.kernel.org/r/20210930022403.3358070-3-pmalani@chromium.org
2021-09-23platform/chrome: cros_ec_proto: Fix check_features ret valPrashant Malani
The kerneldoc for cros_ec_check_features() states that it returns 1 or 0 depedending on whether a feature is supported or not, but it instead returns a negative error number in one case, and a non-1 bitmask in other cases. Since all call-sites only check for a 1 or 0 return value, update the function to return boolean values. Signed-off-by: Prashant Malani <pmalani@chromium.org> Reviewed-by: Guenter Roeck <groeck@chromium.org> Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com> Link: https://lore.kernel.org/r/20210916014632.2662612-1-pmalani@chromium.org
2020-10-29platform/chrome: cros_ec_proto: Replace zero-length array with ↵Gustavo A. R. Silva
flexible-array member There is a regular need in the kernel to provide a way to declare having a dynamically sized set of trailing elements in a structure. Kernel code should always use “flexible array members”[1] for these cases. The older style of one-element or zero-length arrays should no longer be used[2]. [1] https://en.wikipedia.org/wiki/Flexible_array_member [2] https://www.kernel.org/doc/html/v5.9-rc1/process/deprecated.html#zero-length-and-one-element-arrays Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org>
2020-07-23platform/chrome: cros_ec_proto: Do not export cros_ec_cmd_xfer()Enric Balletbo i Serra
Now that all the remaining users of cros_ec_cmd_xfer() has been removed, make this function private to the cros_ec_proto module. Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
2020-02-11platform/chrome: cros_ec: Query EC protocol version if EC transitions ↵Yicheng Li
between RO/RW RO and RW of EC may have different EC protocol version. If EC transitions between RO and RW, but AP does not reboot (this is true for fingerprint microcontroller / cros_fp, but not true for main ec / cros_ec), the AP still uses the protocol version queried before transition, which can cause problems. In the case of fingerprint microcontroller, this causes AP to send the wrong version of EC_CMD_GET_NEXT_EVENT to RO in the interrupt handler, which in turn prevents RO to clear the interrupt line to AP, in an infinite loop. Once an EC_HOST_EVENT_INTERFACE_READY is received, we know that there might have been a transition between RO and RW, so re-query the protocol. Signed-off-by: Yicheng Li <yichengli@chromium.org> Tested-by: Marek Szyprowski <m.szyprowski@samsung.com> Reviewed-by: Gwendal Grignou <gwendal@chromium.org> Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
2020-02-03platform/chrome: cros_ec: Match implementation with headersEnric Balletbo i Serra
The 'cros_ec' core driver is the common interface for the cros_ec transport drivers to do the shared operations to register, unregister, suspend, resume and handle_event. The interface is provided by including the header 'include/linux/platform_data/cros_ec_proto.h', however, instead of have the implementation of these functions in cros_ec_proto.c, it is in 'cros_ec.c', which is a different kernel module. Apart from being a bad practice, this can induce confusions allowing the users of the cros_ec protocol to call these functions. The register, unregister, suspend, resume and handle_event functions *should* only be called by the different transport drivers (i2c, spi, lpc, etc.), so make this a bit less confusing by moving these functions from the public in-kernel space to a private include in platform/chrome, and then, the interface for cros_ec module and for the cros_ec_proto module is clean. Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com> Signed-off-by: Benson Leung <bleung@chromium.org>
2020-01-07cros_ec: treewide: Remove 'include/linux/mfd/cros_ec.h'Enric Balletbo i Serra
This header file now only includes the cros_ec_dev struct, however, is the 'include/linux/platform_data/cros_ec_proto.h' who contains the definition of all the Chrome OS EC related structs. There is no reason to have a separate include for this struct so move to the place where other structs are defined. That way, we can remove the include itself, but also simplify the common pattern #include <linux/mfd/cros_ec.h> #include <linux/platform_data/cros_ec_proto.h> for a single include #include <linux/platform_data/cros_ec_proto.h> The changes to remove the cros_ec.h include were generated with the following shell script: git grep -l "<linux/mfd/cros_ec.h>" | xargs sed -i '/<linux\/mfd\/cros_ec.h>/d' Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com> Acked-by: Lee Jones <lee.jones@linaro.org> Acked-by: Alexandre Belloni <alexandre.belloni@bootlin.com> Acked-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Acked-by: Sebastian Reichel <sre@kernel.org> Acked-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
2019-11-21platform/chrome: cros_ec: handle MKBP more events flagEnrico Granata
The ChromeOS EC has support for signaling to the host that a single IRQ can serve multiple MKBP (Matrix KeyBoard Protocol) events. Doing this serves an optimization purpose, as it minimizes the number of round-trips into the interrupt handling machinery, and it proves beneficial to sensor timestamping as it keeps the desired synchronization of event times between the two processors. This patch adds kernel support for this EC feature, allowing the ec_irq to loop until all events have been served. Signed-off-by: Enrico Granata <egranata@chromium.org> Signed-off-by: Gwendal Grignou <gwendal@chromium.org> Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Acked-by: Lee Jones <lee.jones@linaro.org> Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
2019-11-21platform/chrome: cros-ec: Record event timestamp in the hard irqGwendal Grignou
To improve sensor timestamp precision, given EC and AP are in different time domains, the AP needs to try to record the exact moment an event was signalled to the AP by the EC as soon as possible after it happens. First thing in the hard irq is the best place for this. Signed-off-by: Gwendal Grignou <gwendal@chromium.org> Acked-by: Jonathan Cameron <Jonathan.Cameron@kernel.org> Acked-by: Lee Jones <lee.jones@linaro.org> Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
2019-11-21mfd / platform / iio: cros_ec: Register sensor through sensorhubGwendal Grignou
Remove the duplicated code in MFD, since MFD just registers cros-ec-sensorhub if at least one sensor is present. Change IIO cros-ec driver to get the pointer to the cros-ec-dev through cros-ec-sensorhub. Signed-off-by: Gwendal Grignou <gwendal@chromium.org> Acked-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Acked-by: Lee Jones <lee.jones@linaro.org> Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
2019-11-21mfd / platform: cros_ec: Add sensor_count and make check_features publicGwendal Grignou
Add a new function to return the number of MEMS sensors available in a ChromeOS Embedded Controller. It uses MOTIONSENSE_CMD_DUMP if available or a specific memory map ACPI registers to find out. Also, make check_features public as it can be useful for other drivers to know what the Embedded Controller supports. Signed-off-by: Gwendal Grignou <gwendal@chromium.org> Acked-by: Lee Jones <lee.jones@linaro.org> Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
2019-11-21platform/chrome: cros_ec: Put docs with the codeGwendal Grignou
To avoid doc rot, put function documentations with code, not header. Use kernel-doc style comments for exported functions. Signed-off-by: Gwendal Grignou <gwendal@chromium.org> Acked-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
2019-09-02mfd / platform: cros_ec: Reorganize platform and mfd includesEnric Balletbo i Serra
There is a bit of mess between cros-ec mfd includes and platform includes. For example, we have a linux/mfd/cros_ec.h include that exports the interface implemented in platform/chrome/cros_ec_proto.c. Or we have a linux/mfd/cros_ec_commands.h file that is non related to the multifunction device (in the sense that is not exporting any function of the mfd device). This causes crossed includes between mfd and platform/chrome subsystems and makes the code difficult to read, apart from creating 'curious' situations where a platform/chrome driver includes a linux/mfd/cros_ec.h file just to get the exported functions that are implemented in another platform/chrome driver. In order to have a better separation on what the cros-ec multifunction driver does and what the cros-ec core provides move and rework the affected includes doing: - Move cros_ec_commands.h to include/linux/platform_data/cros_ec_commands.h - Get rid of the parts that are implemented in the platform/chrome/cros_ec_proto.c driver from include/linux/mfd/cros_ec.h to a new file include/linux/platform_data/cros_ec_proto.h - Update all the drivers with the new includes, so - Drivers that only need to know about the protocol include - linux/platform_data/cros_ec_proto.h - linux/platform_data/cros_ec_commands.h - Drivers that need to know about the cros-ec mfd device also include - linux/mfd/cros_ec.h Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com> Acked-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Acked-by: Mark Brown <broonie@kernel.org> Acked-by: Wolfram Sang <wsa@the-dreams.de> Acked-by: Neil Armstrong <narmstrong@baylibre.com> Acked-by: Alexandre Belloni <alexandre.belloni@bootlin.com> Acked-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Acked-by: Benjamin Tissoires <benjamin.tissoires@redhat.com> Acked-by: Dmitry Torokhov <dmitry.torokhov@gmail.com> Acked-by: Sebastian Reichel <sebastian.reichel@collabora.com> Acked-by: Chanwoo Choi <cw00.choi@samsung.com> Reviewed-by: Gwendal Grignou <gwendal@chromium.org> Tested-by: Gwendal Grignou <gwendal@chromium.org> Series changes: 3 - Fix dereferencing pointer to incomplete type 'struct cros_ec_dev' (lkp) Signed-off-by: Lee Jones <lee.jones@linaro.org>