event_read(9)

✨ event_read(9) — Kernel API Manual ✨

Okay bestie, this is the event_read(9) glow-up from the Kernel API Manual — the callback that passes event data to userspace via read(). It's giving kernel-core, no cap. 💖

---

🎀 NAME 🎀

event_read — Callback for passing event data to userspace via read().

---

🦋 SYNOPSIS 🦋

ssize_t event_read (struct file *filp , char __user *buf , size_t count
, loff_t *pos );

---

🌸 ARGUMENTS 🌸

• filp — The file we are reading from. Main-character file energy, honestly.
• buf — Pointer to userspace buffer to fill with one event. One event, slay.
• count — Number of bytes requested. Must be at least EC_ACPI_MAX_EVENT_SIZE. Not a suggestion, bestie.
• pos — File position pointer, irrelevant since we don't support seeking. It's lowkey just vibing there.

---

💅 DESCRIPTION 💅

So the way this works is: it removes the first event from the queue, and places it in the passed buffer. Periodt. ✨

If there are no events in the queue, then one of two things happens, depending on if the file was opened in nonblocking mode:

• If in nonblocking mode, then return -EAGAIN to say there's no data. No data, no drama. 💀
• If in blocking mode, then block until an event is available. It will literally wait for an event to show up. 🫶

---

🔥 RETURN 🔥

Number of bytes placed in buffer, negative error code on failure. That's the vibe check, and that's the whole return story.

---

🫶 SEE ALSO 🫶

• Kernel file ./drivers/platform/chrome/wilco_ec/event.c — the source of the lore.
• struct ec_event(9)
• struct ec_event_queue(9)
• struct event_device_data(9)
• enqueue_events(9)
• event_device_notify(9)
• free_device_data(9)
• event_device_probe(9)

---

Cute sign-off time: this page is from the source/version string ./drivers/platform/chrome/wilc..., dated October 2026, and it's still event_read(9) — bye bestie, read responsibly 💜