cros_ec_cmd_xfer(9)
π cros_ec_cmd_xfer(9) β kernel API manual, bestie edition
okay so real talk, this is a page straight out of the Kernel API Manual, and it's about cros_ec_cmd_xfer β say that five times fast, i literally can't. it's giving "lowkey important glue function" and honestly? iconic. let's get into it π«Ά
β¨ NAME β¨
cros_ec_cmd_xfer β Send a command to the ChromeOS EC.
like, that's the whole job. it sends a command. to the EC. on ChromeOS. slay π
πΈ SYNOPSIS πΈ
int cros_ec_cmd_xfer (struct cros_ec_device *ec_dev , struct
cros_ec_command *msg );
two pointers, one int, zero drama. π«
π¦ ARGUMENTS π¦
ec_devβ the EC device. your little ChromeOS embedded controller buddy. this is who you're talking to πmsgβ the message to write. like, the actual thing you're sending out into the world π¨
π₯ DESCRIPTION π₯
so the way that you use this is: you call cros_ec_cmd_xfer when you need to send a command to the ChromeOS EC. that's it, that's the vibe. β¨
but β and this is the part where you gotta listen, bestie β you should use this instead of calling the EC's cmd_xfer callback directly. do not go behind its back, do not pass go, do not collect $200. use the function, it's literally right there π
now here's the plot twist that makes some people cry: this function does not convert EC command execution error codes to Linux error codes. no cap. it just does not do that. if that's what you were hoping for, sorry babe π
most in-kernel users will want cros_ec_cmd_xfer_status instead, because that function implements the conversion. so unless you specifically know you want the raw behavior, go hang out with cros_ec_cmd_xfer_status. iykyk π
π RETURN π
three possible vibes, let's go:
>0β the EC command was executed successfully π and the return value is the number of bytes returned by the EC (excluding the header, don't @ me). so a positive number = success and a byte count, dual-purpose king behavior π=0β EC communication was successful β but the actual EC command execution results are reported inmsg->result. that result will beEC_RES_SUCCESSif the command was executed successfully, or it'll report an EC command execution error. so like, communication said "we good" but the payload might be saying something else. checkmsg->result, fr fr π<0β EC communication error π the return value is the Linux error code. something went wrong on the talking-to-the-hardware level.
β οΈ friendly reminder from your girl:=0does not automatically mean the command worked. it means the communication worked. the actual result lives inmsg->result. do not confuse the two or you will have a bad time π
π SEE ALSO π
the kernel file where all the magic lives:
Kernel file ./drivers/platform/chrome/cros_ec_proto.c
and the whole friend group, all of them, in order, no one left out:
cros_ec_prepare_tx(9)cros_ec_check_result(9)cros_ec_get_host_event_wake_mask(9)cros_ec_get_host_command_version_mask(9)cros_ec_query_all(9)cros_ec_cmd_xfer_status(9)cros_ec_get_next_event(9)cros_ec_get_host_event(9)cros_ec_read_features(9)cros_ec_check_features(9)cros_ec_get_sensor_count(9)cros_ec_cmd(9)cros_ec_cmd_readmem(9)cros_ec_get_cmd_versions(9)cros_ec_device_registered(9)
aaaand that's the page!! π§ this whole thing lives under ./drivers/platform/chrome, dated October 2026, and it's the cros_ec_cmd_xfer(9) page. mwah, go forth and xfer responsibly πβ¨π
π¦ where this page comes from
- nixpkgs unstable: linux-manual 7.3.1
- π girlified by deepseek-ai/DeepSeek-V4.1-Flash-1017 on : a language model's rewrite of the original, under its terms