summaryrefslogtreecommitdiff
path: root/drivers/platform/chrome/cros_ec_ishtp.c
AgeCommit message (Collapse)Author
2020-06-30platform/chrome: cros_ec_ishtp: Fix a double-unlock issueQiushi Wu
In function cros_ec_ishtp_probe(), "up_write" is already called before function "cros_ec_dev_init". But "up_write" will be called again after the calling of the function "cros_ec_dev_init" failed. Thus add a call of the function “down_write” in this if branch for the completion of the exception handling. Fixes: 26a14267aff2 ("platform/chrome: Add ChromeOS EC ISHTP driver") Signed-off-by: Qiushi Wu <wu000273@umn.edu> Tested-by: Mathew King <mathewk@chromium.org> Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
2020-04-13platform/chrome: cros_ec_ishtp: free ishtp buffer before sending eventJett Rink
Recycle the ISH buffer before notifying of a response or an event. Often a new message is sent in response to an event and in high traffic scenarios this can lead to exhausting all available buffers. We can ensure we are using the fewest buffers possible by freeing buffers as soon as they are used. Signed-off-by: Jett Rink <jettrink@chromium.org> Signed-off-by: Mathew King <mathewk@chromium.org> Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
2020-04-13platform/chrome: cros_ec_ishtp: skip old cros_ec responsesJett Rink
The ISHTP layer can give us old responses that we already gave up on. We do not want to interpret these old responses as the current response we are waiting for. The cros_ish should only have one request in flight at a time. We send the request and wait for the response from the ISH. If the ISH is too slow to respond we give up on that request and we can send a new request. The ISH may still send the response to the request that timed out and without this we treat the old response as the response to the current command. This is a condition that should not normally happen but it has been observed with a bad ISH image. So add a token to the request header which is copied into the response header when the ISH processes the message to ensure that response is for the current request. Signed-off-by: Jett Rink <jettrink@chromium.org> Signed-off-by: Mathew King <mathewk@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>
2019-12-19platform/chrome: cros_ec_ishtp: Make init_lock staticBen Dooks (Codethink)
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>
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-09-07Merge tag 'tag-chrome-platform-fixes-for-v5.3-rc6' into for-nextBenson Leung
chrome-platform fixes for v5.3-rc6 Fixes: 1. platform/chrome: cros_ec_ishtp: fix crash during suspend - Fixes a kernel crash during suspend/resume of cros_ec_ishtp Signed-off-by: Benson Leung <bleung@chromium.org>
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>
2019-07-29platform/chrome: cros_ec_ishtp: fix crash during suspendHyungwoo Yang
Kernel crashes during suspend due to wrong conversion in suspend and resume functions. Use the proper helper to get ishtp_cl_device instance. Cc: <stable@vger.kernel.org> # 5.2.x: b12bbdc5: HID: intel-ish-hid: fix wrong driver_data usage Signed-off-by: Hyungwoo Yang <hyungwoo.yang@intel.com> Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
2019-05-20platform/chrome: Add ChromeOS EC ISHTP driverRushikesh S Kadam
This driver implements a slim layer to enable the ChromeOS EC kernel stack (cros_ec) to communicate with ChromeOS EC firmware running on the Intel Integrated Sensor Hub (ISH). The driver registers a ChromeOS EC MFD device to connect with cros_ec kernel stack (upper layer), and it registers a client with the ISH Transport Protocol bus (lower layer) to talk with the ISH firwmare. See description of the ISHTP protocol at Documentation/hid/intel-ish-hid.txt Signed-off-by: Rushikesh S Kadam <rushikesh.s.kadam@intel.com> Acked-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com> Reviewed-by: Jett Rink <jettrink@chromium.org> Tested-by: Jett Rink <jettrink@chromium.org> Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>