STRUCT CROS_EC_DEVICE(9)

πŸ“¦ version 7.3.1, in nixpkgs unstable

NAME

struct cros_ec_device β€” from the Kernel API Manual β€” is literally the whole vibe check on a ChromeOS EC device, bestie. It's giving "all the info you need" and we're obsessed.


SYNOPSIS

Okay so here's the whole struct, exact and no cap:

       struct cros_ec_device {
           const char *phys_name;
           struct device *dev;
           struct class *cros_class;
           int (*cmd_readmem)(struct cros_ec_device *ec, unsigned int offset,
       unsigned int bytes, void *dest);
           u16 max_request;
           u16 max_response;
           u16 max_passthru;
           u16 proto_version;
           void *priv;
           int irq;
           u8 *din;
           u8 *dout;
           int din_size;
           int dout_size;
           bool wake_enabled;
           bool suspended;
           bool registered;
           int (*cmd_xfer)(struct cros_ec_device *ec, struct cros_ec_command
       *msg);
           int (*pkt_xfer)(struct cros_ec_device *ec, struct cros_ec_command
       *msg);
           struct lock_class_key lockdep_key;
           struct mutex lock;
           u8 mkbp_event_supported;
           bool host_sleep_v1;
           struct blocking_notifier_head event_notifier;
           struct ec_response_get_next_event_v3 event_data;
           int event_size;
           u32 host_event_wake_mask;
           u32 last_resume_result;
           u16 suspend_timeout_ms;
           ktime_t last_event_time;
           struct notifier_block notifier_ready;
           struct platform_device *ec;
           struct platform_device *pd;
           struct blocking_notifier_head panic_notifier;
        };

🧚 Members 🧚

  • phys_name β€” the name of the physical comms layer, like 'i2c-4'. Iconic little label energy.
  • dev β€” the device pointer for the physical comms device.
  • cros_class β€” the class structure for this device.
  • cmd_readmem β€” direct read of the EC memory-mapped region, if it's supported. Slay when available.
  • max_request β€” max size of the message requested.
  • max_response β€” max size of the message response.
  • max_passthru β€” max size of the passthru message.
  • proto_version β€” the protocol version used for this device.
  • priv β€” private data. mysterious. love that.
  • irq β€” the interrupt to use.
  • din β€” input buffer, for data coming from the EC. This buffer will always be dword-aligned and include enough space for up to 7 word-alignment bytes also, so we can ensure that the body of the message is always dword-aligned (64-bit). We use this alignment to keep ARM and x86 happy. Probably word alignment would be OK, there might be a small performance advantage to using dword. fr fr, alignment lore.
  • dout β€” output buffer, for data going to the EC. This buffer will always be dword-aligned and include enough space for up to 7 word-alignment bytes also, so we can ensure that the body of the message is always dword-aligned (64-bit). We use this alignment to keep ARM and x86 happy. Probably word alignment would be OK, there might be a small performance advantage to using dword. same energy, different direction πŸ’….
  • din_size β€” size of the din buffer to allocate (zero to use static din).
  • dout_size β€” size of the dout buffer to allocate (zero to use static dout).
  • wake_enabled β€” true if this device can wake the system from sleep.
  • suspended β€” true if this device had been suspended.
  • registered β€” true if this device had been registered.
  • cmd_xfer β€” send a command to the EC and get the response. Returns the number of bytes received if the communication succeeded, but that doesn't mean the EC was happy with the command. The caller should check msg.result for the EC's result code.
⚠️ real talk: cmd_xfer returning bytes received is not the same as the EC approving. check msg.result, bestie 😭
  • pkt_xfer β€” send a packet to the EC and get the response.
  • lockdep_key β€” lockdep class for each instance. Unused if CONFIG_LOCKDEP is not enabled.
  • lock β€” one transaction at a time. periodt.
  • mkbp_event_supported β€” 0 if MKBP is not supported. Otherwise its value is the maximum supported version of the MKBP host event command + 1.
  • host_sleep_v1 β€” true if this EC supports the sleep v1 command.
  • event_notifier β€” interrupt event notifier for transport devices.
  • event_data β€” raw payload transferred with the MKBP event.
  • event_size β€” size in bytes of the event data.
  • host_event_wake_mask β€” mask of host events that cause wake from suspend.
  • last_resume_result β€” the number of sleep power signal transitions that occurred since the suspend message. The high bit indicates a timeout occurred. See also struct ec_response_host_sleep_event_v1 in cros_ec_commands.h.
  • suspend_timeout_ms β€” the timeout in milliseconds between when the sleep event is received and when the EC will declare sleep transition failure if the sleep signal is not asserted. See also struct ec_params_host_sleep_event_v1 in cros_ec_commands.h.
  • last_event_time β€” exact time from the hard irq when we got notified of a new event.
  • notifier_ready β€” the notifier_block to let the kernel re-query EC communication protocol when the EC sends EC_HOST_EVENT_INTERFACE_READY.
  • ec β€” the platform_device used by the mfd driver to interface with the main EC.
  • pd β€” the platform_device used by the mfd driver to interface with the PD behind an EC.
  • panic_notifier β€” EC panic notifier. dramatic, but necessary.

🌈 SEE ALSO 🌈

The kernel file ./include/linux/platform_data/cros_ec_proto.h is the plug, and it points you at struct cros_ec_command(9), struct cros_ec_platform(9), struct cros_ec_dev(9), and cros_ec_get_time_ns(9). iykyk πŸ’–


byeee 🫢 β€” source/version is ./include/linux/platform_data, dated October 2026, and this page is struct cros_ec_device(9). stay aligned, bestie πŸ’…βœ¨

πŸ“¦ where this page comes from