summaryrefslogtreecommitdiff
path: root/drivers/platform/chrome/cros_ec_proto.c
AgeCommit message (Collapse)AuthorFilesLines
2023-10-04platform/chrome: cros_ec_proto: Mark outdata as constStephen Boyd1-1/+1
The 'outdata' is copied to the data buffer in cros_ec_cmd() before being sent over to the EC. Mark the argument as const so that callers can pass const pointers to this function and so that callers know the data won't be modified. Cc: Prashant Malani <pmalani@chromium.org> Signed-off-by: Stephen Boyd <swboyd@chromium.org> Acked-by: Prashant Malani <pmalani@chromium.org> Link: https://lore.kernel.org/r/20231003003429.1378109-5-swboyd@chromium.org Signed-off-by: Tzung-Bi Shih <tzungbi@kernel.org>
2022-08-15platform/chrome: cros_ec_proto: Update version on GET_NEXT_EVENT failurePatryk Duda1-0/+32
Some EC based devices (e.g. Fingerpint MCU) can jump to RO part of the firmware (intentionally or due to device reboot). The RO part doesn't change during the device lifecycle, so it won't support newer version of EC_CMD_GET_NEXT_EVENT command. Function cros_ec_query_all() is responsible for finding maximum supported MKBP event version. It's usually called when the device is running RW part of the firmware, so the command version can be potentially higher than version supported by the RO. The problem was fixed by updating maximum supported version when the device returns EC_RES_INVALID_VERSION (mapped to -ENOPROTOOPT). That way the kernel will use highest common version supported by RO and RW. Fixes: 3300fdd630d4 ("platform/chrome: cros_ec: handle MKBP more events flag") Cc: <stable@vger.kernel.org> # 5.10+ Reviewed-by: Guenter Roeck <groeck@chromium.org> Signed-off-by: Patryk Duda <pdk@semihalf.com> Signed-off-by: Tzung-Bi Shih <tzungbi@kernel.org> Link: https://lore.kernel.org/r/20220802154128.21175-1-pdk@semihalf.com
2022-07-20platform/chrome: cros_ec_proto: return -EPROTO if empty payloadTzung-Bi Shih1-0/+5
cros_ec_wait_until_complete() sends EC_CMD_GET_COMMS_STATUS which expects to receive sizeof(struct ec_response_get_comms_status) from cros_ec_xfer_command(). Return -EPROTO if cros_ec_xfer_command() returns 0. Reviewed-by: Guenter Roeck <groeck@chromium.org> Signed-off-by: Tzung-Bi Shih <tzungbi@kernel.org> Link: https://lore.kernel.org/r/20220718050914.2267370-11-tzungbi@kernel.org
2022-07-20platform/chrome: cros_ec_proto: return -EAGAIN when retries timed outTzung-Bi Shih1-0/+3
While EC_COMMS_STATUS_PROCESSING flag is still on after it tries EC_COMMAND_RETRIES times for sending EC_CMD_GET_COMMS_STATUS, cros_ec_wait_until_complete() doesn't return an error code. Return -EAGAIN in the case instead. Signed-off-by: Tzung-Bi Shih <tzungbi@kernel.org> Reviewed-by: Guenter Roeck <groeck@chromium.org> Link: https://lore.kernel.org/r/20220718050914.2267370-9-tzungbi@kernel.org
2022-07-20platform/chrome: cros_ec_proto: separate cros_ec_wait_until_complete()Tzung-Bi Shih1-39/+35
EC returns EC_RES_IN_PROGRESS if the host command needs more time to complete. Whenever receives the return code, cros_ec_send_command() sends EC_CMD_GET_COMMS_STATUS to query the command status. Separate cros_ec_wait_until_complete() from cros_ec_send_command(). It sends EC_CMD_GET_COMMS_STATUS and waits until the previous command was completed, or encountered error, or timed out. Signed-off-by: Tzung-Bi Shih <tzungbi@kernel.org> Reviewed-by: Guenter Roeck <groeck@chromium.org> Link: https://lore.kernel.org/r/20220718050914.2267370-7-tzungbi@kernel.org
2022-07-20platform/chrome: cros_ec_proto: separate cros_ec_xfer_command()Tzung-Bi Shih1-3/+10
cros_ec_send_command() has extra logic to handle EC_RES_IN_PROGRESS. Separate the command transfer part into cros_ec_xfer_command() so that other functions can re-use it. Reviewed-by: Guenter Roeck <groeck@chromium.org> Signed-off-by: Tzung-Bi Shih <tzungbi@kernel.org> Link: https://lore.kernel.org/r/20220718050914.2267370-6-tzungbi@kernel.org
2022-07-20platform/chrome: cros_ec_proto: add "cros_ec_" prefix to send_command()Tzung-Bi Shih1-8/+7
To be neat, add "cros_ec_" prefix to static function send_command(). Reviewed-by: Guenter Roeck <groeck@chromium.org> Signed-off-by: Tzung-Bi Shih <tzungbi@kernel.org> Link: https://lore.kernel.org/r/20220718050914.2267370-3-tzungbi@kernel.org
2022-06-14platform/chrome: cros_ec_proto: Fix spelling mistake "unknwon" -> "unknown"Colin Ian King1-1/+1
There is a spelling mistake in a dev_dbg message. Fix it. Signed-off-by: Colin Ian King <colin.i.king@gmail.com> Signed-off-by: Tzung-Bi Shih <tzungbi@kernel.org> Link: https://lore.kernel.org/r/20220614064909.47804-1-colin.i.king@gmail.com
2022-06-10platform/chrome: cros_ec_proto: handle empty payload in getting wake maskTzung-Bi Shih1-10/+14
cros_ec_get_host_event_wake_mask() expects to receive sizeof(struct ec_response_host_event_mask) from send_command(). The payload is valid only if the return value is positive. Return -EPROTO if send_command() returns 0 in cros_ec_get_host_event_wake_mask(). Reviewed-by: Guenter Roeck <groeck@chromium.org> Signed-off-by: Tzung-Bi Shih <tzungbi@kernel.org> Link: https://lore.kernel.org/r/20220609084957.3684698-22-tzungbi@kernel.org
2022-06-10platform/chrome: cros_ec_proto: return 0 on getting wake mask successTzung-Bi Shih1-1/+2
cros_ec_get_host_event_wake_mask() used to return value from send_command() which is number of bytes for input payload on success (i.e. sizeof(struct ec_response_host_event_mask)). However, the callers don't need to know how many bytes are available. Don't return number of available bytes. Instead, return 0 on success; otherwise, negative integers on error. Reviewed-by: Guenter Roeck <groeck@chromium.org> Signed-off-by: Tzung-Bi Shih <tzungbi@kernel.org> Link: https://lore.kernel.org/r/20220609084957.3684698-20-tzungbi@kernel.org
2022-06-10platform/chrome: cros_ec_proto: handle empty payload in getting cmd maskTzung-Bi Shih1-0/+5
cros_ec_get_host_command_version_mask() expects to receive sizeof(struct ec_response_get_cmd_versions) from send_command(). The payload is valid only if the return value is positive. Return -EPROTO if send_command() returns 0 in cros_ec_get_host_command_version_mask(). Reviewed-by: Guenter Roeck <groeck@chromium.org> Signed-off-by: Tzung-Bi Shih <tzungbi@kernel.org> Link: https://lore.kernel.org/r/20220609084957.3684698-19-tzungbi@kernel.org
2022-06-10platform/chrome: cros_ec_proto: check `msg->result` in getting cmd maskTzung-Bi Shih1-8/+13
cros_ec_get_host_command_version_mask() should check if EC wasn't happy by checking `msg->result`. Use cros_ec_map_error() and return the error code if any. Reviewed-by: Guenter Roeck <groeck@chromium.org> Signed-off-by: Tzung-Bi Shih <tzungbi@kernel.org> Link: https://lore.kernel.org/r/20220609084957.3684698-17-tzungbi@kernel.org
2022-06-10platform/chrome: cros_ec_proto: return 0 on getting cmd mask successTzung-Bi Shih1-8/+5
cros_ec_get_host_command_version_mask() used to return value from send_command() which is number of available bytes for input payload on success (i.e. sizeof(struct ec_response_get_cmd_versions)). However, the callers don't need to know how many bytes are available. Don't return number of available bytes. Instead, return 0 on success; otherwise, negative integers on error. Also remove the unneeded `ver_mask` initialization as the callers should take it only if cros_ec_get_host_command_version_mask() returns 0. Reviewed-by: Guenter Roeck <groeck@chromium.org> Signed-off-by: Tzung-Bi Shih <tzungbi@kernel.org> Link: https://lore.kernel.org/r/20220609084957.3684698-15-tzungbi@kernel.org
2022-06-10platform/chrome: cros_ec_proto: don't show MKBP version if unsupportedTzung-Bi Shih1-4/+4
It wrongly showed the following message when it doesn't support MKBP: "MKBP support version 4294967295". Fix it. Reviewed-by: Guenter Roeck <groeck@chromium.org> Signed-off-by: Tzung-Bi Shih <tzungbi@kernel.org> Link: https://lore.kernel.org/r/20220609084957.3684698-14-tzungbi@kernel.org
2022-06-10platform/chrome: cros_ec_proto: handle empty payload in getting info legacyTzung-Bi Shih1-3/+9
cros_ec_get_proto_info_legacy() expects to receive sizeof(struct ec_response_hello) from send_command(). The payload is valid only if the return value is positive. Return -EPROTO if send_command() returns 0 in cros_ec_get_proto_info_legacy(). Reviewed-by: Guenter Roeck <groeck@chromium.org> Signed-off-by: Tzung-Bi Shih <tzungbi@kernel.org> Link: https://lore.kernel.org/r/20220609084957.3684698-13-tzungbi@kernel.org
2022-06-10platform/chrome: cros_ec_proto: separate cros_ec_get_proto_info_legacy()Tzung-Bi Shih1-39/+33
Rename cros_ec_host_command_proto_query_v2() to cros_ec_get_proto_info_legacy() and make it responsible for setting `ec_dev` fields for EC protocol v2. Reviewed-by: Guenter Roeck <groeck@chromium.org> Signed-off-by: Tzung-Bi Shih <tzungbi@kernel.org> Link: https://lore.kernel.org/r/20220609084957.3684698-11-tzungbi@kernel.org
2022-06-10platform/chrome: cros_ec_proto: handle empty payload in getting proto infoTzung-Bi Shih1-0/+5
cros_ec_get_proto_info() expects to receive sizeof(struct ec_response_get_protocol_info) from send_command(). The payload is valid only if the return value is positive. Return -EPROTO if send_command() returns 0 in cros_ec_get_proto_info(). Reviewed-by: Guenter Roeck <groeck@chromium.org> Signed-off-by: Tzung-Bi Shih <tzungbi@kernel.org> Link: https://lore.kernel.org/r/20220609084957.3684698-10-tzungbi@kernel.org
2022-06-10platform/chrome: cros_ec_proto: separate cros_ec_get_proto_info()Tzung-Bi Shih1-69/+65
Rename cros_ec_host_command_proto_query() to cros_ec_get_proto_info() and make it responsible for setting `ec_dev` fields according to the response protocol info. Also make cros_ec_get_host_event_wake_mask() allocate its own message buffer. It was lucky that size of `struct ec_response_host_event_mask` is less than `struct ec_response_get_protocol_info`. Thus, the buffer wasn't overflow. Reviewed-by: Guenter Roeck <groeck@chromium.org> Signed-off-by: Tzung-Bi Shih <tzungbi@kernel.org> Link: https://lore.kernel.org/r/20220609084957.3684698-8-tzungbi@kernel.org
2022-06-10platform/chrome: cros_ec_proto: use cros_ec_map_error()Tzung-Bi Shih1-5/+4
Use cros_ec_map_error() in cros_ec_get_host_event_wake_mask(). The behavior of cros_ec_get_host_event_wake_mask() slightly changed. It is acceptable because the caller only needs it returns negative integers for indicating errors. Especially, the EC_RES_INVALID_COMMAND still maps to -EOPNOTSUPP. Reviewed-by: Guenter Roeck <groeck@chromium.org> Signed-off-by: Tzung-Bi Shih <tzungbi@kernel.org> Link: https://lore.kernel.org/r/20220609084957.3684698-7-tzungbi@kernel.org
2022-06-10platform/chrome: cros_ec_proto: remove redundant NULL checkTzung-Bi Shih1-3/+0
send_command() already checks if `ec_dev->pkt_xfer` is NULL. Remove the redundant check. Reviewed-by: Guenter Roeck <groeck@chromium.org> Signed-off-by: Tzung-Bi Shih <tzungbi@kernel.org> Link: https://lore.kernel.org/r/20220609084957.3684698-6-tzungbi@kernel.org
2022-06-10platform/chrome: cros_ec_proto: assign buffer size from protocol infoTzung-Bi Shih1-6/+2
`din_size` is calculated from `ec_dev->max_response`. `ec_dev->max_response` is further calculated from the protocol info. To make it clear, assign `din_size` and `dout_size` from protocol info directly. Reviewed-by: Guenter Roeck <groeck@chromium.org> Signed-off-by: Tzung-Bi Shih <tzungbi@kernel.org> Link: https://lore.kernel.org/r/20220609084957.3684698-5-tzungbi@kernel.org
2022-06-10platform/chrome: use macros for passthru indexesTzung-Bi Shih1-3/+3
Move passthru indexes for EC and PD devices to common header. Also use them instead of literal constants. Reviewed-by: Guenter Roeck <groeck@chromium.org> Signed-off-by: Tzung-Bi Shih <tzungbi@kernel.org> Link: https://lore.kernel.org/r/20220609084957.3684698-4-tzungbi@kernel.org
2022-06-08platform/chrome: cros_ec_proto: Update size arg typesPrashant Malani1-2/+2
cros_ec_cmd() takes 2 size arguments. Update them to be of the more appropriate type size_t. Suggested-by: Stephen Boyd <swboyd@chromium.org> Signed-off-by: Prashant Malani <pmalani@chromium.org> Reviewed-by: Stephen Boyd <swboyd@chromium.org> Reviewed-by: Guenter Roeck <groeck@chromium.org> Signed-off-by: Tzung-Bi Shih <tzungbi@kernel.org> Link: https://lore.kernel.org/r/20220606201825.763788-4-pmalani@chromium.org
2022-06-08platform/chrome: cros_ec_proto: Rename cros_ec_command functionPrashant Malani1-11/+11
cros_ec_command() is the name of a function as well as a struct, as such it can confuse indexing tools (like ctags). Avoid this by renaming it to cros_ec_cmd(). Update all the callsites to use the new name. This patch is a find-and-replace, so should not introduce any functional changes. Suggested-by: Stephen Boyd <swboyd@chromium.org> Signed-off-by: Prashant Malani <pmalani@chromium.org> Acked-by: Lee Jones <lee.jones@linaro.org> Reviewed-by: Stephen Boyd <swboyd@chromium.org> Reviewed-by: Guenter Roeck <groeck@chromium.org> Signed-off-by: Tzung-Bi Shih <tzungbi@kernel.org> Link: https://lore.kernel.org/r/20220606201825.763788-3-pmalani@chromium.org
2022-06-06platform/chrome: cros_ec_proto: update cros_ec_check_result() commentTzung-Bi Shih1-2/+5
At first glance, cros_ec_check_result() is quite like cros_ec_map_error(). They check for `ec_msg->result` and return corresponding errors. However, as calling from `pkt_xfer` and `cmd_xfer`, cros_ec_check_result() should not report furthermore errors. -EAGAIN is the only exception. See [1][2][3] for some known userland programs' code. The return code from ioctl only denotes the EC communication status. Userland programs would further analyze the `result` in struct cros_ec_command* for follow-up actions (e.g. [4]). To clarify, update the function comment. [1]: https://crrev.com/54400e93a75ef440a83d6eaac2cec066daf99cf0/util/comm-dev.c#154 [2]: https://crrev.com/fe32670a89bf59e1aff84bba9dd3295657b85e9b/cros_ec_dev.c#296 [3]: https://crrev.com/4e19eb1d89de0422ff1bbd3f7260b131c761098c/drivers/google/cros_ec_dev.c#120 [4]: https://crrev.com/54400e93a75ef440a83d6eaac2cec066daf99cf0/util/comm-dev.c#164 Signed-off-by: Tzung-Bi Shih <tzungbi@kernel.org> Reviewed-by: Guenter Roeck <groeck@chromium.org> Link: https://lore.kernel.org/r/20220518091814.2028579-4-tzungbi@kernel.org
2022-06-06platform/chrome: cros_ec_proto: factor legacy out from cros_ec_prepare_tx()Tzung-Bi Shih1-23/+28
cros_ec_prepare_tx() mixed the code for both versions. To be neat and to make it clear, factor the legacy part out as a separate function, rename the function, and update the comments. Specifically, - prepare_tx(), for current protocol version (i.e. 3). - prepare_tx_legacy(), for protocol version <= 2. Signed-off-by: Tzung-Bi Shih <tzungbi@kernel.org> Reviewed-by: Guenter Roeck <groeck@chromium.org> Link: https://lore.kernel.org/r/20220518091814.2028579-3-tzungbi@kernel.org
2022-05-16platform/chrome: cros_ec_proto: drop BUG_ON() in cros_ec_get_host_event()Tzung-Bi Shih1-1/+2
It is overkill to crash the kernel if the `ec_dev` doesn't support MKBP event but gets called into cros_ec_get_host_event(). Drop the BUG_ON() and return error (0 in the case) instead. Reviewed-by: Guenter Roeck <groeck@chromium.org> Signed-off-by: Tzung-Bi Shih <tzungbi@kernel.org> Link: https://lore.kernel.org/r/20220513044143.1045728-5-tzungbi@kernel.org
2022-05-16platform/chrome: cros_ec_proto: drop BUG_ON() in cros_ec_prepare_tx()Tzung-Bi Shih1-2/+5
It is overkill to crash the kernel if the given message is oversize. Drop the BUG_ON() and return -EINVAL instead. Reviewed-by: Guenter Roeck <groeck@chromium.org> Signed-off-by: Tzung-Bi Shih <tzungbi@kernel.org> Link: https://lore.kernel.org/r/20220513044143.1045728-4-tzungbi@kernel.org
2022-05-16platform/chrome: correct cros_ec_prepare_tx() usageTzung-Bi Shih1-1/+1
cros_ec_prepare_tx() returns either: - >= 0 for number of prepared bytes. - < 0 for -errno. Correct the comment and make sure all callers check the return code. Reviewed-by: Guenter Roeck <groeck@chromium.org> Signed-off-by: Tzung-Bi Shih <tzungbi@kernel.org> Link: https://lore.kernel.org/r/20220513044143.1045728-3-tzungbi@kernel.org
2022-05-16platform/chrome: cros_ec_proto: drop unneeded BUG_ON() in prepare_packet()Tzung-Bi Shih1-1/+0
prepare_packet() gets called if `ec_dev->proto_version` > 2. For now, it must be equivalent to EC_HOST_REQUEST_VERSION. Drop the BUG_ON(). Reviewed-by: Guenter Roeck <groeck@chromium.org> Signed-off-by: Tzung-Bi Shih <tzungbi@kernel.org> Link: https://lore.kernel.org/r/20220513044143.1045728-2-tzungbi@kernel.org
2022-04-19platform/chrome: Re-introduce cros_ec_cmd_xfer and use it for ioctlsGuenter Roeck1-9/+41
Commit 413dda8f2c6f ("platform/chrome: cros_ec_chardev: Use cros_ec_cmd_xfer_status helper") inadvertendly changed the userspace ABI. Previously, cros_ec ioctls would only report errors if the EC communication failed, and otherwise return success and the result of the EC communication. An EC command execution failure was reported in the EC response field. The above mentioned commit changed this behavior, and the ioctl itself would fail. This breaks userspace commands trying to analyze the EC command execution error since the actual EC command response is no longer reported to userspace. Fix the problem by re-introducing the cros_ec_cmd_xfer() helper, and use it to handle ioctl messages. Fixes: 413dda8f2c6f ("platform/chrome: cros_ec_chardev: Use cros_ec_cmd_xfer_status helper") Cc: Daisuke Nojiri <dnojiri@chromium.org> Cc: Rob Barnes <robbarnes@google.com> Cc: Rajat Jain <rajatja@google.com> Cc: Brian Norris <briannorris@chromium.org> Cc: Parth Malkan <parthmalkan@google.com> Reviewed-by: Daisuke Nojiri <dnojiri@chromium.org> Reviewed-by: Brian Norris <briannorris@chromium.org> Signed-off-by: Guenter Roeck <linux@roeck-us.net> Signed-off-by: Tzung-Bi Shih <tzungbi@kernel.org>
2021-11-01platform/chrome: cros_ec_proto: Use ec_command for check_featuresPrashant Malani1-17/+3
Use the existing cros_ec_command() for cros_ec_check_features(). This eliminates an unnecessary duplication of the memory allocation/free and memory copy code. Signed-off-by: Prashant Malani <pmalani@chromium.org> Link: https://lore.kernel.org/r/20211004170716.86601-2-pmalani@chromium.org Signed-off-by: Benson Leung <bleung@chromium.org>
2021-11-01platform/chrome: cros_ec_proto: Use EC struct for featuresPrashant Malani1-7/+8
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 Malani1-0/+3
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 Malani1-2/+2
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 Malani1-0/+45
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 Malani1-5/+7
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
2021-07-27platform/chrome: cros_ec_proto: Send command again when timeout occursPatryk Duda1-0/+9
Sometimes kernel is trying to probe Fingerprint MCU (FPMCU) when it hasn't initialized SPI yet. This can happen because FPMCU is restarted during system boot and kernel can send message in short window eg. between sysjump to RW and SPI initialization. Cc: <stable@vger.kernel.org> # 4.4+ Signed-off-by: Patryk Duda <pdk@semihalf.com> Link: https://lore.kernel.org/r/20210518140758.29318-1-pdk@semihalf.com Signed-off-by: Benson Leung <bleung@chromium.org>
2021-01-20platform/chrome: cros_ec_proto: Add LID and BATTERY to default maskEvan Benn1-1/+3
After 'platform/chrome: cros_ec_proto: Use EC_HOST_EVENT_MASK not BIT' some of the flags are not quite correct. LID_CLOSED is used to suspend the device, so it makes sense to ignore that. BATTERY events are also frequent and causing spurious wakes on elm/hana mt8173 devices. Fixes: c214e564acb2 ("platform/chrome: cros_ec_proto: ignore unnecessary wakeups on old ECs") Signed-off-by: Evan Benn <evanbenn@chromium.org> Reviewed-by: Brian Norris <briannorris@chromium.org> Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com> Link: https://lore.kernel.org/r/20201209220306.2.I3291bf83e4884c206b097ede34780e014fa3e265@changeid
2021-01-20platform/chrome: cros_ec_proto: Use EC_HOST_EVENT_MASK not BITEvan Benn1-5/+5
The host_event_code enum is 1-based, use EC_HOST_EVENT_MASK not BIT to generate the intended mask. This patch changes the behaviour of the mask, a following patch will restore the intended behaviour: 'Add LID and BATTERY to default mask' Fixes: c214e564acb2 ("platform/chrome: cros_ec_proto: ignore unnecessary wakeups on old ECs") Signed-off-by: Evan Benn <evanbenn@chromium.org> Reviewed-by: Brian Norris <briannorris@chromium.org> Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com> Link: https://lore.kernel.org/r/20201209220306.1.I6133572c0ab3c6b95426f804bac2d3833e24acb1@changeid
2020-11-12platform/chrome: Don't treat RTC events as wakeup sourcesStephen Boyd1-5/+9
The EC sends an RTC host event when the RTC fires, but we don't need to treat that as a wakeup event here. The RTC class already properly handles activating and deactivating a wakeup source in rtc_update_irq() by calling pm_stay_awake() at the start of processing and pm_relax() once all expired RTC timers have been processed. This reduces one wakeup increment but not much else. I noticed this while debugging RTC wakeups and how they always incremented the wakeup count by two instead of one because this is duplicated. Signed-off-by: Stephen Boyd <swboyd@chromium.org> Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com> Cc: Guenter Roeck <groeck@chromium.org> Cc: Alessandro Zummo <a.zummo@towertech.it> Cc: Alexandre Belloni <alexandre.belloni@bootlin.com> Cc: <linux-rtc@vger.kernel.org> Link: https://lore.kernel.org/r/20201030232523.2654478-1-swboyd@chromium.org
2020-09-21platform/chrome: cros_ec_proto: Drop cros_ec_cmd_xfer()Prashant Malani1-33/+11
Since cros_ec_cmd_xfer_status() now returns Linux error codes and all other files use that command, remove the now-unused function cros_ec_cmd_xfer(). Signed-off-by: Prashant Malani <pmalani@chromium.org> Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
2020-09-21platform/chrome: cros_ec_proto: Update cros_ec_cmd_xfer() call-sitesPrashant Malani1-11/+4
Since all the other call-sites of cros_ec_cmd_xfer() have been converted to use cros_ec_cmd_xfer_status() instead, update the remaining call-sites to prepare for the merge of cros_ec_cmd_xfer() into cros_ec_cmd_xfer_status(). As part of this update, change the error handling inside cros_ec_get_sensor_count() such that the legacy LPC interface is tried on all error values, not just when msg->result != EC_RESULT_SUCCESS. Note that there is a slight change in API in cros_ec_get_sensor_count(): it will return a negative number of sensors when there are no sensors on arm platform when MOTIONSENSE_CMD_DUMP is not supported (typical for sensorless chromebook) instead of 0. However, this is not a problem when probing the EC as we ignore errors only looking for cros_ec_get_sensor_count() returning a positive number of sensors. Signed-off-by: Prashant Malani <pmalani@chromium.org> Reviewed-by: Gwendal Grignou <gwendal@chromium.org> Tested-by: Gwendal Grignou <gwendal@chromium.org> Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
2020-08-24platform/chrome: cros_ec_proto: Convert EC error codes to Linux error codesGuenter Roeck1-11/+46
The EC reports a variety of error codes. Most of those, with the exception of EC_RES_INVALID_VERSION, are converted to -EPROTO. As result, the actual EC error code gets lost. Introduce cros_ec_map_error() to map EC error codes to Linux error codes, and use it in cros_ec_cmd_xfer_status() to report more meaningful errors to the caller. With this change, callers of cros_ec_cmd_xfer_status() can implement a more distinguished action without having to rely on the EC error code. At the same time, debugging is improved in situations where the Linux error code is reported to userspace and/or in the kernel log. Cc: Gwendal Grignou <gwendal@chromium.org> Cc: Yu-Hsuan Hsu <yuhsuan@chromium.org> Cc: Prashant Malani <pmalani@chromium.org> Cc: Brian Norris <briannorris@chromium.org> Signed-off-by: Guenter Roeck <linux@roeck-us.net> Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
2020-08-24platform/input: cros_ec: Replace -ENOTSUPP with -ENOPROTOOPTGuenter Roeck1-2/+2
-ENOTSUPP is not a SUSV4 error code and should not be used. Use -ENOPROTOOPT instead to report EC_RES_INVALID_VERSION responses from the EC. This matches match the NFS response for unsupported protocol versions. Cc: Gwendal Grignou <gwendal@chromium.org> Cc: Yu-Hsuan Hsu <yuhsuan@chromium.org> Cc: Prashant Malani <pmalani@chromium.org> Cc: Brian Norris <briannorris@chromium.org> Acked-by: Dmitry Torokhov <dmitry.torokhov@gmail.com> Signed-off-by: Guenter Roeck <linux@roeck-us.net> Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
2020-07-31platform/chrome: cros_ec_proto: check for missing ↵Brian Norris1-0/+13
EC_CMD_HOST_EVENT_GET_WAKE_MASK As with cros_ec_cmd_xfer_status(), etc., it's not enough to simply check for the return status of send_command() -- that only covers transport or other similarly-fatal errors. One must also check the ->result field, to see whether the command really succeeded. If not, we can't use the data it returns. The caller of cros_ec_get_host_event_wake_mask() ignores this, and so for example, on EC's where the command is not implemented, we're using junk (or in practice, all zeros) for our wake-mask. We should be using a non-zero default (currently, it's supposed to be all-1's). Fix this by checking the ->result field and returning -EPROTO for errors. I might label this as fixing commit 29d99b966d60 ("cros_ec: Don't signal wake event for non-wake host events"), except that this fix alone actually may make things worse, as it now allows for a lot more spurious wakeups. The patch "platform/chrome: cros_ec_proto: ignore battery/AC wakeups on old ECs" helps to mitigate this. Signed-off-by: Brian Norris <briannorris@chromium.org> Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
2020-07-31platform/chrome: cros_ec_proto: ignore unnecessary wakeups on old ECsBrian Norris1-6/+18
ECs that don't implement EC_CMD_HOST_EVENT_GET_WAKE_MASK should still have some reasonable default mask -- otherwise, they'll treat a variety of EC signals as spurious wakeups. Battery and AC events can be especially common, for devices that have been sitting at full charge plugged into AC for a long time, as they may cycle their charging off and on, or their battery may start reporting failures as it ages. Treating these as wakeups does not serve a useful purpose, and is instead often counterproductive. And indeed, later ECs (that implement the mask) don't include these events in their wake-mask. Note that this patch doesn't do anything without the subsequent patch ("platform/chrome: cros_ec_proto: check for missing EC_CMD_HOST_EVENT_GET_WAKE_MASK"), because cros_ec_get_host_event_wake_mask() currently does not return an error if EC_CMD_HOST_EVENT_GET_WAKE_MASK is not implemented. Some additional notes: While the EC typically knows not to wake the CPU for these unimportant events once the CPU reaches a sleep state, it doesn't really have a way to know that the CPU is "almost" asleep, unless it has support for EC_CMD_HOST_SLEEP_EVENT. Alas, these older ECs do not support that command either, so this solution is not 100% complete. Signed-off-by: Brian Norris <briannorris@chromium.org> Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
2020-07-23platform/chrome: cros_ec_proto: Do not export cros_ec_cmd_xfer()Enric Balletbo i Serra1-3/+2
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-03-02platform/chrome: cros_ec_proto: Report command not supportedEnric Balletbo i Serra1-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>
2019-12-10platform/chrome: cros_ec_proto: Add response tracingRaul E Rangel1-2/+4
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>