- 29 Apr, 2020 1 commit
-
-
Gwendal Grignou authored
Allocate callbacks array before enumerating the sensors: The probe routine for these sensors (for instance cros_ec_sensors_probe) can be called within the sensorhub probe routine (cros_ec_sensors_probe()) Fixes: 145d59ba ("platform/chrome: cros_ec_sensorhub: Add FIFO support") Signed-off-by:
Gwendal Grignou <gwendal@chromium.org> Reported-by:
Douglas Anderson <dianders@chromium.org> Tested-by:
Enric Balletbo i Serra <enric.balletbo@collabora.com>
-
- 13 Apr, 2020 2 commits
-
-
Christophe JAILLET authored
Message logged by 'dev_xxx()' or 'pr_xxx()' should end with a '\n'. Fixes: 145d59ba ("platform/chrome: cros_ec_sensorhub: Add FIFO support") Signed-off-by:
Christophe JAILLET <christophe.jaillet@wanadoo.fr> Signed-off-by:
-
Dan Carpenter authored
The sensorhub->push_data[] array has sensorhub->sensor_num elements. It's allocated in cros_ec_sensorhub_ring_add(). So the > should be >= to prevent a read one element beyond the end of the array. Fixes: 145d59ba ("platform/chrome: cros_ec_sensorhub: Add FIFO support") Signed-off-by:
Dan Carpenter <dan.carpenter@oracle.com> Reviewed-by:
Guenter Roeck <groeck@chromium.org> Signed-off-by:
-
- 07 Apr, 2020 1 commit
-
-
Benson Leung authored
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: 7d3ca507 ("platform/chrome: cros_ec_spi: Use new structure for SPI transfer delays") Signed-off-by:
Benson Leung <bleung@chromium.org>
-
- 30 Mar, 2020 1 commit
-
-
Gwendal Grignou authored
To be compliant with other sensors, set and get sensor sampling frequency in Hz, not mHz. Fixes: ae7b02ad ("iio: common: cros_ec_sensors: Expose cros_ec_sensors frequency range via iio sysfs") Signed-off-by:
Jonathan Cameron <Jonathan.Cameron@huawei.com> Signed-off-by:
-
- 28 Mar, 2020 10 commits
-
-
Gwendal Grignou authored
Report the maximum amount of sample the EC can hold. This is not tunable, but can be useful for application to find out the maximum amount of time it can sleep when hwfifo_timeout is set to a large number. Signed-off-by:
-
Gwendal Grignou authored
Expose EC minimal interrupt period through buffer/hwfifo_timeout: - Maximal timeout is limited to 65s. - When timeout for all sensors is set to 0, EC will not send events, even if the sensor sampling rate is greater than 0. Rename frequency to sampling_frequency to match IIO ABI. Signed-off-by:
-
Gwendal Grignou authored
Since cros_ec_sensorhub is shutting down the FIFO when the device suspends, no need to slow down the EC sampling period rate. It was necesseary to do that before command CMD_FIFO_INT_ENABLE was introduced, but now all supported chromebooks have it. Signed-off-by:
Lee Jones <lee.jones@linaro.org> Signed-off-by:
-
Gwendal Grignou authored
When EC supports FIFO, each IIO device registers a callback, to put samples in the buffer when they arrives from the FIFO. When no FIFO, the user space app needs to call trigger_new, or better register a high precision timer. Signed-off-by:
-
Gwendal Grignou authored
Some IIO devices may want to override the default (realtime) to another clock source by default. It can beneficial when timestamps coming from the hardware or underlying drivers are already in that format. It can always be overridden by attribute current_timestamp_clock. Signed-off-by:
-
Gwendal Grignou authored
To prevent comment rot, move function description to cros_ec_sensors_core.c. Signed-off-by:
-
Gwendal Grignou authored
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:
Andy Shevchenko <andy.shevchenko@gmail.com> Signed-off-by:
-
Gwendal Grignou authored
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 authored
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 authored
To better manage resources, store the number of sensors reported by the EC. Signed-off-by:
-
- 27 Mar, 2020 1 commit
-
-
Wolfram Sang authored
When converting to i2c_new_scanned_device(), it was overlooked that a conversion to i2c_new_client_device() was also needed. Fix it. Fixes: c82ebf1b ("platform/chrome: chromeos_laptop: Convert to i2c_new_scanned_device") Signed-off-by:
Wolfram Sang <wsa+renesas@sang-engineering.com> Signed-off-by:
-
- 22 Mar, 2020 4 commits
-
-
Gustavo A. R. Silva authored
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 76497732 ("cxgb3/l2t: Fix undefined behaviour") Signed-off-by:Gustavo A. R. Silva <gustavo@embeddedor.com> Signed-off-by:
-
Gustavo A. R. Silva authored
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 76497732 ("cxgb3/l2t: Fix undefined behaviour") Signed-off-by: -
Prashant Malani authored
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:
-
Prashant Malani authored
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:
-
- 17 Mar, 2020 4 commits
-
-
Prashant Malani authored
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 authored
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 authored
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:
-
Gwendal Grignou authored
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: ec2daf6e ("platform: chrome: Add cros-usbpd-notify driver") Signed-off-by:
-
- 06 Mar, 2020 1 commit
-
-
Enric Balletbo i Serra authored
Remove the CONFIG_ prefix from the select statement for MFD_CROS_EC. Fixes: 2fa2b980 ("mfd / platform: cros_ec: Rename config to a better name") Reported-by:
Randy Dunlap <rdunlap@infradead.org> Signed-off-by:
Andy Shevchenko <andriy.shevchenko@linux.intel.com> Acked-by:
-
- 02 Mar, 2020 8 commits
-
-
Enric Balletbo i Serra authored
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 authored
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 authored
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 authored
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 authored
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 authored
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:
-
Sergiu Cuciurean authored
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 bebcfd27 ("spi: introduce `delay` field for `spi_transfer` + spi_transfer_delay_exec()") Signed-off-by:
Sergiu Cuciurean <sergiu.cuciurean@analog.com> Signed-off-by:
-
Pi-Hsun Shih authored
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: 71cddb70 ("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:
-
- 11 Feb, 2020 4 commits
-
-
Yicheng Li authored
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:
-
Andy Shevchenko authored
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:
-
Enric Balletbo i Serra authored
Merge 0cbb4f9c ("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:
-
Stephen Boyd authored
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: 60fb8a8e ("platform/chrome: wilco_ec: Allow wilco to be compiled in COMPILE_TEST") Signed-off-by:
Stephen Boyd <swboyd@chromium.org> Signed-off-by:
-
- 10 Feb, 2020 3 commits
-
-
Jon Flatley authored
There's a bug on ACPI platforms where host events from the ECPD ACPI device never make their way to the cros-ec-usbpd-charger driver. This makes it so the only time the charger driver updates its state is when user space accesses its sysfs attributes. Now that these events have been unified into a single notifier chain on both ACPI and non-ACPI platforms, update the charger driver to use this new notifier. Reviewed-by:
Sebastian Reichel <sebastian.reichel@collabora.com> Signed-off-by:
-
Jon Flatley authored
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:
-
Linus Torvalds authored
-
