cros_ec_cmd_xfer(9)

πŸ“¦ version 7.3.1, in nixpkgs unstable

πŸ’… 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 in msg->result. that result will be EC_RES_SUCCESS if 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. check msg->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: =0 does not automatically mean the command worked. it means the communication worked. the actual result lives in msg->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:


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