summaryrefslogtreecommitdiffstats
path: root/drivers/platform/chrome
Commit message (Collapse)AuthorAgeFilesLines
* platform/chrome: cros_ec_spi: Wait for USECS, not NSECSBenson Leung2020-04-071-1/+1
| | | | | | | | | The use of `delay_usecs` in terminate_request() was replaced with the new `delay` struct used by the SPI subsystem, however the unit was set to SPI_DELAY_UNIT_NSECS instead of SPI_DELAY_UNIT_USECS. This fixes that. Fixes: 7d3ca507fda9 ("platform/chrome: cros_ec_spi: Use new structure for SPI transfer delays") Signed-off-by: Benson Leung <bleung@chromium.org>
* platform/chrome: cros_ec_sensorhub: Add median filterGwendal Grignou2020-03-281-27/+533
| | | | | | | | | | | | | | | | | Events are timestamped in EC time space, their timestamps need to be converted in host time space. The assumption is the time delta between when the interrupt is sent by the EC and when it is receive by the host is a [small] constant. This is not always true, even with hard-wired interrupt. To mitigate worst offenders, add a median filter to weed out bigger than expected delays. Signed-off-by: Gwendal Grignou <gwendal@chromium.org> Acked-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Acked-by: Lee Jones <lee.jones@linaro.org> Acked-by: Andy Shevchenko <andy.shevchenko@gmail.com> Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
* platform/chrome: cros_ec_sensorhub: Add code to spread timestmapGwendal Grignou2020-03-281-8/+109
| | | | | | | | | | | | | | | | | | | | | | | | | | | | EC FIFO can send sensor events in batch. Spread them based on previous (TSa) and currnet timestamp (TSb) EC FIFO iio events +-----------+ | TSa | +-----------+ +---------------------------------------+ | event 1 | | event 1 | TSb - (TSb - TSa)/n * (n-1) | +-----------+ +---------------------------------------+ | event 2 | | event 2 | TSb - (TSb - TSa)/n * (n-2) | +-----------+ +---------------------------------------+ | ... | ------> | .... | | +-----------+ +---------------------------------------+ | event n-1 | | event 2 | TSb - (TSb - TSa)/n | +-----------+ +---------------------------------------+ | event n | | event 2 | TSb | +-----------+ +---------------------------------------+ | TSb | +-----------+ Signed-off-by: Gwendal Grignou <gwendal@chromium.org> Acked-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Acked-by: Lee Jones <lee.jones@linaro.org> Acked-by: Andy Shevchenko <andy.shevchenko@gmail.com> Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
* platform/chrome: cros_ec_sensorhub: Add FIFO supportGwendal Grignou2020-03-283-28/+521
| | | | | | | | | | | | | | cros_ec_sensorhub registers a listener and query motion sense FIFO, spread to iio sensors registers. To test, we can use libiio: iiod& iio_readdev -u ip:localhost -T 10000 -s 25 -b 16 cros-ec-gyro | od -x Signed-off-by: Gwendal Grignou <gwendal@chromium.org> Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Acked-by: Andy Shevchenko <andy.shevchenko@gmail.com> Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
* platform/chrome: cros_ec_sensorhub: Add the number of sensors in sensorhubGwendal Grignou2020-03-281-1/+3
| | | | | | | | To better manage resources, store the number of sensors reported by the EC. Signed-off-by: Gwendal Grignou <gwendal@chromium.org> Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
* platform/chrome: chromeos_laptop: make I2C API conversion completeWolfram Sang2020-03-271-1/+1
| | | | | | | | | When converting to i2c_new_scanned_device(), it was overlooked that a conversion to i2c_new_client_device() was also needed. Fix it. Fixes: c82ebf1bf738 ("platform/chrome: chromeos_laptop: Convert to i2c_new_scanned_device") Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com> Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
* platform/chrome: wilco_ec: event: Replace zero-length array with ↵Gustavo A. R. Silva2020-03-221-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | flexible-array member The current codebase makes use of the zero-length array language extension to the C90 standard, but the preferred mechanism to declare variable-length types such as these ones is a flexible array member[1][2], introduced in C99: struct foo { int stuff; struct boo array[]; }; By making use of the mechanism above, we will get a compiler warning in case the flexible array does not occur last in the structure, which will help us prevent some kind of undefined behavior bugs from being inadvertently introduced[3] to the codebase from now on. Also, notice that, dynamic memory allocations won't be affected by this change: "Flexible array members have incomplete type, and so the sizeof operator may not be applied. As a quirk of the original implementation of zero-length arrays, sizeof evaluates to zero."[1] This issue was found with the help of Coccinelle. [1] https://gcc.gnu.org/onlinedocs/gcc/Zero-Length.html [2] https://github.com/KSPP/linux/issues/21 [3] commit 76497732932f ("cxgb3/l2t: Fix undefined behaviour") Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com> Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
* platform/chrome: cros_ec_chardev: Replace zero-length array with ↵Gustavo A. R. Silva2020-03-221-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | flexible-array member The current codebase makes use of the zero-length array language extension to the C90 standard, but the preferred mechanism to declare variable-length types such as these ones is a flexible array member[1][2], introduced in C99: struct foo { int stuff; struct boo array[]; }; By making use of the mechanism above, we will get a compiler warning in case the flexible array does not occur last in the structure, which will help us prevent some kind of undefined behavior bugs from being inadvertently introduced[3] to the codebase from now on. Also, notice that, dynamic memory allocations won't be affected by this change: "Flexible array members have incomplete type, and so the sizeof operator may not be applied. As a quirk of the original implementation of zero-length arrays, sizeof evaluates to zero."[1] This issue was found with the help of Coccinelle. [1] https://gcc.gnu.org/onlinedocs/gcc/Zero-Length.html [2] https://github.com/KSPP/linux/issues/21 [3] commit 76497732932f ("cxgb3/l2t: Fix undefined behaviour") Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com> Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
* platform/chrome: cros_ec_typec: Update port info from ECPrashant Malani2020-03-221-1/+120
| | | | | | | | | | After registering the ports at probe, get the current port information from EC and update the Type C connector class ports accordingly. Co-developed-by: Jon Flatley <jflat@chromium.org> Signed-off-by: Prashant Malani <pmalani@chromium.org> Reviewed-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
* platform/chrome: Add Type C connector class driverPrashant Malani2020-03-223-0/+250
| | | | | | | | | | | | | | | | | | | | | | | Add a driver to implement the Type C connector class for Chrome OS devices with ECs (Embedded Controllers). The driver relies on firmware device specifications for various port attributes. On ACPI platforms, this is specified using the logical device with HID GOOG0014. On DT platforms, this is specified using the DT node with compatible string "google,cros-ec-typec". The driver reads the device FW node and uses the port attributes to register the typec ports with the Type C connector class framework, but doesn't do much else. Subsequent patches will add more functionality to the driver, including obtaining current port information (polarity, vconn role, current power role etc.) after querying the EC. Co-developed-by: Benson Leung <bleung@chromium.org> Signed-off-by: Prashant Malani <pmalani@chromium.org> Reviewed-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
* platform/chrome: cros_usbpd_notify: Pull PD_HOST_EVENT statusPrashant Malani2020-03-171-3/+83
| | | | | | | | | Read the PD host even status from the EC and send that to the notifier listeners, for more fine-grained event information. Signed-off-by: Prashant Malani <pmalani@chromium.org> Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com> Signed-off-by: Benson Leung <bleung@chromium.org>
* platform/chrome: cros_usbpd_notify: Amend ACPI driver to platPrashant Malani2020-03-171-12/+59
| | | | | | | | | | | | | | | | Convert the ACPI driver into the equivalent platform driver, with the same ACPI match table as before. This allows the device driver to access the parent platform EC device and its cros_ec_device struct, which will be required to communicate with the EC to pull PD Host event information from it. Also change the ACPI driver name to "cros-usbpd-notify-acpi" so that there is no confusion between it and the "regular" platform driver on platforms that have both CONFIG_ACPI and CONFIG_OF enabled. Signed-off-by: Prashant Malani <pmalani@chromium.org> Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com> Signed-off-by: Benson Leung <bleung@chromium.org>
* platform/chrome: cros_usbpd_notify: Add driver data structPrashant Malani2020-03-171-9/+19
| | | | | | | | | | | | | Introduce a device driver data structure, cros_usbpd_notify_data, in which we can store the notifier block object and pointers to the struct cros_ec_device and struct device objects. This will make it more convenient to access these pointers when executing both platform and ACPI callbacks. Signed-off-by: Prashant Malani <pmalani@chromium.org> Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com> Signed-off-by: Benson Leung <bleung@chromium.org>
* platform/chrome: cros_usbpd_notify: Fix cros-usbpd-notify notifierGwendal Grignou2020-03-171-1/+1
| | | | | | | | | | | | cros-usbpd-notify notifier was returning NOTIFY_BAD when no host event was available in the MKBP message. But MKBP messages are used to transmit other information, so return NOTIFY_DONE instead, to allow other notifier to be called. Fixes: ec2daf6e33f9f ("platform: chrome: Add cros-usbpd-notify driver") Signed-off-by: Gwendal Grignou <gwendal@chromium.org> Signed-off-by: Benson Leung <bleung@chromium.org> Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
* platform/chrome: Kconfig: Remove CONFIG_ prefix from MFD_CROS_EC sectionEnric Balletbo i Serra2020-03-061-1/+1
| | | | | | | | | | Remove the CONFIG_ prefix from the select statement for MFD_CROS_EC. Fixes: 2fa2b980e3fe1 ("mfd / platform: cros_ec: Rename config to a better name") Reported-by: Randy Dunlap <rdunlap@infradead.org> Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com> Acked-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Acked-by: Randy Dunlap <rdunlap@infradead.org>
* platform/chrome: cros_ec: Use cros_ec_cmd_xfer_status helperEnric Balletbo i Serra2020-03-021-1/+1
| | | | | | | | | | | This patch makes use of cros_ec_cmd_xfer_status() instead of cros_ec_cmd_xfer(). In this case the change is trivial and the only reason to do it is because we want to make cros_ec_cmd_xfer() a private function for the EC protocol and let people only use the cros_ec_cmd_xfer_status() to return Linux standard error codes. Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com> Tested-by: Prashant Malani <pmalani@chromium.org>
* platform/chrome: cros_ec_lightbar: Use cros_ec_cmd_xfer_status helperEnric Balletbo i Serra2020-03-021-37/+13
| | | | | | | | | | | | This patch makes use of cros_ec_cmd_xfer_status() instead of cros_ec_cmd_xfer(). It allows us to remove some redundand code. In this case, though, we are changing a bit the behaviour because of returning -EINVAL on protocol error we propagate the error return for cros_ec_cmd_xfer_status() function, but I think it will be fine, even more clear as we don't mask the Linux error code. Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com> Tested-by: Prashant Malani <pmalani@chromium.org>
* platform/chrome: cros_ec_sysfs: Use cros_ec_cmd_xfer_status helperEnric Balletbo i Serra2020-03-021-18/+18
| | | | | | | | | | | | | | This patch makes use of cros_ec_cmd_xfer_status() instead of cros_ec_cmd_xfer(). In this case the change is trivial and the only reason to do it is because we want to make cros_ec_cmd_xfer() a private function for the EC protocol and let people only use the cros_ec_cmd_xfer_status() to return Linux standard error codes. Looking at the code I am even unsure that makes sense differentiate these two errors but let's not change the behaviour for now. Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com> Tested-by: Prashant Malani <pmalani@chromium.org>
* platform/chrome: cros_ec_chardev: Use cros_ec_cmd_xfer_status helperEnric Balletbo i Serra2020-03-021-1/+1
| | | | | | | | | | | This patch makes use of cros_ec_cmd_xfer_status() instead of cros_ec_cmd_xfer(). In this case the change is trivial and the only reason to do it is because we want to make cros_ec_cmd_xfer() a private function for the EC protocol and let people only use the cros_ec_cmd_xfer_status() to return Linux standard error codes. Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com> Tested-by: Prashant Malani <pmalani@chromium.org>
* platform/chrome: cros_ec_vbc: Use cros_ec_cmd_xfer_status helperEnric Balletbo i Serra2020-03-021-2/+2
| | | | | | | | | | | This patch makes use of cros_ec_cmd_xfer_status() instead of cros_ec_cmd_xfer(). In this case the change is trivial and the only reason to do it is because we want to make cros_ec_cmd_xfer() a private function for the EC protocol and let people only use the cros_ec_cmd_xfer_status() to return Linux standard error codes. Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com> Tested-by: Prashant Malani <pmalani@chromium.org>
* platform/chrome: cros_ec_proto: Report command not supportedEnric Balletbo i Serra2020-03-021-1/+8
| | | | | | | | | | | | | | | | | | In practice most drivers that use the EC protocol what really care is if the result was successful or not, hence, we introduced a cros_ec_cmd_xfer_status() function that converts EC errors to standard Linux error codes. On some few cases, though, we are interested on know if the command is supported or not, and in such cases, just ignore the error. To achieve this, return a -ENOTSUPP error when the command is not supported. This will allow us to finish the conversion of all users to use the cros_ec_cmd_xfer_status() function instead of cros_ec_cmd_xfer() and make the latest private to the protocol driver, so users of the protocol are not confused in which function they should use. Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com> Tested-by: Prashant Malani <pmalani@chromium.org>
* platform/chrome: cros_ec_spi: Use new structure for SPI transfer delaysSergiu Cuciurean2020-03-021-2/+4
| | | | | | | | | | | | | | | | In a recent change to the SPI subsystem [1], a new `delay` struct was added to replace the `delay_usecs`. This change replaces the current `delay_usecs` with `delay` for this driver. The `spi_transfer_delay_exec()` function [in the SPI framework] makes sure that both `delay_usecs` & `delay` are used (in this order to preserve backwards compatibility). [1] commit bebcfd272df6 ("spi: introduce `delay` field for `spi_transfer` + spi_transfer_delay_exec()") Signed-off-by: Sergiu Cuciurean <sergiu.cuciurean@analog.com> Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
* platform/chrome: cros_ec_rpmsg: Fix race with host eventPi-Hsun Shih2020-03-021-1/+15
| | | | | | | | | | | | | | | Host event can be sent by remoteproc by any time, and cros_ec_rpmsg_callback would be called after cros_ec_rpmsg_create_ept. But the cros_ec_device is initialized after that, which cause host event handler to use cros_ec_device that are not initialized properly yet. Fix this by don't schedule host event handler before cros_ec_register returns. Instead, remember that we have a pending host event, and schedule host event handler after cros_ec_register. Fixes: 71cddb7097e2 ("platform/chrome: cros_ec_rpmsg: Fix race with host command when probe failed.") Signed-off-by: Pi-Hsun Shih <pihsun@chromium.org> Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
* platform/chrome: cros_ec: Query EC protocol version if EC transitions ↵Yicheng Li2020-02-111-0/+30
| | | | | | | | | | | | | | | | | | | | | 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>
* platform/chrome: wilco_ec: Platform data shouldn't include kernel.hAndy Shevchenko2020-02-112-0/+7
| | | | | | | | | | | | | Replace with appropriate types.h. Also there is no need to include device.h, but mutex.h. For the pointers to unknown structures use forward declarations. In the *.c files we need to include all headers that provide APIs being used in the module. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
* Merge branch 'chrome-platform-5.6-fixes' into for-nextEnric Balletbo i Serra2020-02-111-1/+1
|\ | | | | | | | | | | | | Merge 0cbb4f9c6982 ("platform/chrome: wilco_ec: Include asm/unaligned instead of linux/ path") from chrome-platform-5.6-fixes into for-next destined branch. Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
| * platform/chrome: wilco_ec: Include asm/unaligned instead of linux/ pathStephen Boyd2020-02-111-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | It seems that we shouldn't try to include the include/linux/ path to unaligned functions. Just include asm/unaligned.h instead so that we don't run into compilation warnings like below. In file included from drivers/platform/chrome/wilco_ec/properties.c:8:0: include/linux/unaligned/le_memmove.h:7:19: error: redefinition of 'get_unaligned_le16' static inline u16 get_unaligned_le16(const void *p) ^~~~~~~~~~~~~~~~~~ In file included from arch/ia64/include/asm/unaligned.h:5:0, from arch/ia64/include/asm/io.h:23, from arch/ia64/include/asm/smp.h:21, from include/linux/smp.h:68, from include/linux/percpu.h:7, from include/linux/arch_topology.h:9, from include/linux/topology.h:30, from include/linux/gfp.h:9, from include/linux/xarray.h:14, from include/linux/radix-tree.h:18, from include/linux/idr.h:15, from include/linux/kernfs.h:13, from include/linux/sysfs.h:16, from include/linux/kobject.h:20, from include/linux/device.h:16, from include/linux/platform_data/wilco-ec.h:11, from drivers/platform/chrome/wilco_ec/properties.c:6: include/linux/unaligned/le_struct.h:7:19: note: previous definition of 'get_unaligned_le16' was here static inline u16 get_unaligned_le16(const void *p) ^~~~~~~~~~~~~~~~~~ Reported-by: kbuild test robot <lkp@intel.com> Fixes: 60fb8a8e93ca ("platform/chrome: wilco_ec: Allow wilco to be compiled in COMPILE_TEST") Signed-off-by: Stephen Boyd <swboyd@chromium.org> Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
* | platform: chrome: Add cros-usbpd-notify driverJon Flatley2020-02-103-0/+184
|/ | | | | | | | | | | | | | | | | | | | | | | | | ChromiumOS uses ACPI device with HID "GOOG0003" for power delivery related events. The existing cros-usbpd-charger driver relies on these events without ever actually receiving them on ACPI platforms. This is because in the ChromeOS kernel trees, the GOOG0003 device is owned by an ACPI driver that offers firmware updates to USB-C chargers. Introduce a new platform driver under cros-ec, the ChromeOS embedded controller, that handles these PD events and dispatches them appropriately over a notifier chain to all drivers that use them. On platforms that don't have the ACPI device defined, the driver gets instantiated for ECs which support the EC_FEATURE_USB_PD feature bit, and the notification events will get delivered using the MKBP event handling mechanism. Co-Developed-by: Prashant Malani <pmalani@chromium.org> Reviewed-by: Gwendal Grignou <gwendal@chromium.org> Reviewed-by: Benson Leung <bleung@chromium.org> Signed-off-by: Jon Flatley <jflat@chromium.org> Signed-off-by: Prashant Malani <pmalani@chromium.org> Acked-By: Enric Balletbo i Serra <enric.balletbo@collabora.com> Signed-off-by: Benson Leung <bleung@chromium.org>
* platform/chrome: cros_ec: Match implementation with headersEnric Balletbo i Serra2020-02-037-0/+30
| | | | | | | | | | | | | | | | | | | | | 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>
* platform/chrome: cros_ec: Drop unaligned.h includeStephen Boyd2020-01-221-1/+0
| | | | | | | This include isn't used. Remove it. Signed-off-by: Stephen Boyd <swboyd@chromium.org> Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
* platform/chrome: wilco_ec: Allow wilco to be compiled in COMPILE_TESTStephen Boyd2020-01-221-1/+2
| | | | | | | | Enable this Kconfig on COMPILE_TEST enabled configs so we can get more build coverage. Signed-off-by: Stephen Boyd <swboyd@chromium.org> Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
* platform/chrome: wilco_ec: Add newlines to printksStephen Boyd2020-01-224-10/+10
| | | | | | | | | | | printk messages all require newlines, or it looks very odd in the log when messages are not on different lines. Add them. Cc: Nick Crews <ncrews@chromium.org> Cc: Daniel Campello <campello@chromium.org> Cc: Enric Balletbo i Serra <enric.balletbo@collabora.com> Signed-off-by: Stephen Boyd <swboyd@chromium.org> Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
* Merge branch 'chrome-platform-5.5-fixes' into for-kernelciBenson Leung2020-01-101-8/+20
|\ | | | | | | | | | | | | Merge dfb9a8857f4d platform/chrome: wilco_ec: Fix keyboard backlight probing from chrome-platform-5.5-fixes into chrome-platform-5.6 destined branch. Signed-off-by: Benson Leung <bleung@chromium.org>
| * platform/chrome: wilco_ec: Fix keyboard backlight probingDaniel Campello2020-01-101-8/+20
| | | | | | | | | | | | | | | | | | | | | | | | The EC on the Wilco platform responds with 0xFF to commands related to the keyboard backlight on the absence of a keyboard backlight module. This change allows the EC driver to continue loading even if the backlight module is not present. Fixes: 119a3cb6d687 ("platform/chrome: wilco_ec: Add keyboard backlight LED support") Signed-off-by: Daniel Campello <campello@chromium.org> Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com> Signed-off-by: Benson Leung <bleung@chromium.org>
* | platform/chrome: wilco_ec: Fix unregistration orderDaniel Campello2020-01-101-1/+1
| | | | | | | | | | | | | | | | | | | | | | The unregistration should happen in the opposite order of the registration, so change it accordingly. No real issue has been noticed, but it is good practice to keep the correct unregistration order. Signed-off-by: Daniel Campello <campello@chromium.org> Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
* | cros_ec: treewide: Remove 'include/linux/mfd/cros_ec.h'Enric Balletbo i Serra2020-01-077-7/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* | platform/chrome: cros_ec_ishtp: Make init_lock staticBen Dooks (Codethink)2019-12-191-1/+1
| | | | | | | | | | | | | | | | | | | | The init_lock is not declared or used outside of cros_ec_ishtp.c so make it static to avoid the following warning: drivers/platform/chrome/cros_ec_ishtp.c:79:1: warning: symbol 'init_lock' was not declared. Should it be static? Signed-off-by: Ben Dooks (Codethink) <ben.dooks@codethink.co.uk> Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
* | platform/chrome: chromeos_laptop: Convert to i2c_new_scanned_deviceWolfram Sang2019-12-161-8/+10
| | | | | | | | | | | | | | | | Move from the deprecated i2c_new_probed_device() to the new i2c_new_scanned_device(). Make use of the new ERRPTR if suitable. Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com> Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
* | platform/chrome: cros_ec_lpc: Use platform_get_irq_optional() for optional IRQsEnric Balletbo i Serra2019-12-101-1/+1
| | | | | | | | | | | | | | | | | | | | | | As platform_get_irq() now prints an error when the interrupt does not exist, use platform_get_irq_optional() to get the IRQ which is optional to avoid below error message during probe: [ 5.113502] cros_ec_lpcs GOOG0004:00: IRQ index 0 not found Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com> Reviewed-by: Guenter Roeck <groeck@chromium.org>
* | platform/chrome: cros_ec_proto: Add response tracingRaul E Rangel2019-12-103-7/+49
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Add the ability to view response codes as well. I dropped the EVENT_CLASS since there is only one event per class. cros_ec_cmd has now been renamed to cros_ec_request_start. Example: $ echo 1 > /sys/kernel/debug/tracing/events/cros_ec/enable $ cat /sys/kernel/debug/tracing/trace 369.416372: cros_ec_request_start: version: 0, command: EC_CMD_USB_PD_POWER_INFO 369.420528: cros_ec_request_done: version: 0, command: EC_CMD_USB_PD_POWER_INFO, ec result: EC_RES_SUCCESS, retval: 16 369.420529: cros_ec_request_start: version: 0, command: EC_CMD_USB_PD_DISCOVERY 369.421383: cros_ec_request_done: version: 0, command: EC_CMD_USB_PD_DISCOVERY, ec result: EC_RES_SUCCESS, retval: 5 Signed-off-by: Raul E Rangel <rrangel@chromium.org> Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
* | platform/chrome: cros_ec_trace: Match trace commands with EC commandsEnric Balletbo i Serra2019-12-101-7/+66
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | There are some EC commands that are not included yet as trace commands, in order to get all the traces for the all supported commands match the commands accordingly. Note that a change, adding or removing an EC command, should be reflected in the cros_ec_trace.c file in order to avoid mismatches again. The list of current commands is generated using the following script: sed -n 's/^#define \(EC_CMD_[[:alnum:]_]*\)\s.*/\tTRACE_SYMBOL(\1),\\/p' \ include/linux/platform_data/cros_ec_commands.h Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
* | Merge tag 'tag-chrome-platform-for-v5.5' of ↵Linus Torvalds2019-12-0316-84/+912
|\| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | git://git.kernel.org/pub/scm/linux/kernel/git/chrome-platform/linux Pull chrome platform changes from Benson Leung: "CrOS EC / MFD / IIO: - Contains tag-ib-chrome-mfd-iio-input-5.5, which is the first part of a series from Gwendal to refactor sensor code between MFD, CrOS EC, iio and input in order to add a new sensorhub driver and FIFO processing Wilco EC: - Add support for Dell's USB PowerShare policy control, keyboard backlight LED driver, and a new test_event file. - Fixes use after free in wilco_ec's telemetry driver. Misc: - bugfix in cros_usbpd_logger (missing destroy workqueue)" * tag 'tag-chrome-platform-for-v5.5' of git://git.kernel.org/pub/scm/linux/kernel/git/chrome-platform/linux: platform/chrome: wilco_ec: fix use after free issue platform/chrome: cros_ec: Add Kconfig default for cros-ec-sensorhub Revert "Input: cros_ec_keyb: mask out extra flags in event_type" Revert "Input: cros_ec_keyb - add back missing mask for event_type" platform/chrome: cros_ec: handle MKBP more events flag platform/chrome: cros_ec: Do not attempt to register a non-positive IRQ number platform/chrome: cros-ec: Record event timestamp in the hard irq mfd / platform / iio: cros_ec: Register sensor through sensorhub iio / platform: cros_ec: Add cros-ec-sensorhub driver mfd / platform: cros_ec: Add sensor_count and make check_features public platform/chrome: cros_ec: Put docs with the code platform/chrome: cros_usbpd_logger: add missed destroy_workqueue in remove platform/chrome: cros_ec: Fix Kconfig indentation platform/chrome: wilco_ec: Add keyboard backlight LED support platform/chrome: wilco_ec: Add charging config driver platform/chrome: wilco_ec: Add Dell's USB PowerShare Policy control platform/chrome: wilco_ec: Add debugfs test_event file
| * platform/chrome: wilco_ec: fix use after free issueWen Yang2019-12-021-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This is caused by dereferencing 'dev_data' after put_device() in the telem_device_remove() function. This patch just moves the put_device() down a bit to avoid this issue. Fixes: 1210d1e6bad1 ("platform/chrome: wilco_ec: Add telemetry char device interface") Signed-off-by: Wen Yang <wenyang@linux.alibaba.com> Cc: Benson Leung <bleung@chromium.org> Cc: Enric Balletbo i Serra <enric.balletbo@collabora.com> Cc: Nick Crews <ncrews@chromium.org> Cc: linux-kernel@vger.kernel.org Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
| * platform/chrome: cros_ec: Add Kconfig default for cros-ec-sensorhubEnric Balletbo i Serra2019-11-271-1/+2
| | | | | | | | | | | | | | Like the other CrOS EC sub-drivers set that depends on his parent and set default to the parent's value. Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
| * Merge tag 'tag-ib-chrome-mfd-iio-input-5.5' into chrome-platform-5.5Enric Balletbo i Serra2019-11-218-63/+561
| |\ | | | | | | | | | | | | | | | IB between mfd, iio, input and chrome platform for cros-ec-sensorhub Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
| | * platform/chrome: cros_ec: handle MKBP more events flagEnrico Granata2019-11-215-58/+98
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
| | * platform/chrome: cros_ec: Do not attempt to register a non-positive IRQ numberGwendal Grignou2019-11-211-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Add a layer of sanity checking to cros_ec_register against attempting to register IRQ values that are not strictly greater than 0. Signed-off-by: Enrico Granata <egranata@chromium.org> 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>
| | * platform/chrome: cros-ec: Record event timestamp in the hard irqGwendal Grignou2019-11-213-5/+31
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
| | * iio / platform: cros_ec: Add cros-ec-sensorhub driverGwendal Grignou2019-11-213-0/+212
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Similar to HID sensor stack, the new driver sits between cros-ec-dev and the IIO device drivers: The EC based IIO device topology would be: iio:device1 -> ...0/0000:00:1f.0/PNP0C09:00/GOOG0004:00/cros-ec-dev.6.auto/ cros-ec-sensorhub.7.auto/ cros-ec-accel.15.auto/ iio:device1 It will be expanded to control EC sensor FIFO. Signed-off-by: Gwendal Grignou <gwendal@chromium.org> Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> [Fix "unknown type name 'uint32_t'" type errors] Reported-by: kbuild test robot <lkp@intel.com> Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
| | * mfd / platform: cros_ec: Add sensor_count and make check_features publicGwendal Grignou2019-11-211-0/+117
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
generated by cgit v1.2.3 (git 2.25.1) at 2024-11-07 22:52:55 +0000