rpmsg_create_ept(9)

📦 version 7.3.1, in nixpkgs unstable

🎀 NAME 🎀

rpmsg_create_ept — bestie, it literally creates a brand new rpmsg_endpoint. That's the whole vibe. (This is the Kernel API Manual, iykyk 💅)

✨ SYNOPSIS ✨

struct rpmsg_endpoint * rpmsg_create_ept (struct rpmsg_device *rpdev ,
rpmsg_rx_cb_t cb , void *priv , struct rpmsg_channel_info chinfo );

🦋 ARGUMENTS 🦋

  • rpdev — the rpmsg channel device, aka the main character of this whole operation 🫶
  • cb — the rx callback handler, the lil function that goes off when mail arrives 💌
  • priv — private data, just for the driver's own use, no questions asked 🙈
  • chinfo — the channel_info carrying the local rpmsg address you wanna bind with cb 🎀

🌸 DESCRIPTION 🌸

okay so picture this: every single rpmsg address in the system is bound to an rx callback — that's just how it is, no cap. So when inbound messages show up, the rpmsg bus dispatches them using the appropriate callback handler. And the way it does that? Through an rpmsg_endpoint struct. iconic behavior honestly ✨

This function is literally the plug — it lets drivers create one of those endpoints, and by doing that, bind a callback (plus maybe some private data too, why not) to an rpmsg address. And that address can be either one that's known in advance, or one that gets dynamically assigned for them. Either way, slay 💅

Now, simple rpmsg drivers? They do not need to call rpmsg_create_ept. Not even a little. Because an endpoint is already created for them when they get probed by the rpmsg bus — using the rx callback they provided when they registered to the rpmsg bus. Built-in. Free. Gorgeous 🌈

So things should just work for simple drivers, fr fr: they already have an endpoint, their rx callback is bound to their rpmsg address, and when relevant inbound messages arrive — meaning messages where their dst address equals the src address of their rpmsg channel — the driver's handler gets invoked to process it. Chef's kiss 🔥

That said 👀 more complicated drivers might need to allocate additional rpmsg addresses and bind them to different rx callbacks. To accomplish that, those drivers need to call this function. That's the whole reason it exists, bestie.

So here's what drivers should provide:

  • their rpdev channel (so the new endpoint belongs to the same remote processor their channel belongs to — matching energy 💜)
  • an rx callback function
  • an optional private data (which gets provided back to you when the rx callback is invoked, cute right?)
  • and the address they wanna bind with the callback

And here's the tea ☕ if addr is RPMSG_ADDR_ANY, then rpmsg_create_ept will dynamically assign them an available rpmsg address. Which is usually what you want! Drivers should have a very good reason why not to always use RPMSG_ADDR_ANY here. Like, a really good one. 👑

⭐ RETURN ⭐

A pointer to the endpoint on success 🎉 — or NULL on error 😭 (yes it's giving "no thoughts head empty" but that's just how it is).

👑 SEE ALSO 👑

Kernel file ./drivers/rpmsg/rpmsg_core.c, plus the whole friend group:

🫶 that's the whole page, bestie — go forth and bind those callbacks

mwah 💋 this gem lives in ./drivers/rpmsg, dated October 2026, and it's a rpmsg_create_ept(9) situation through and through 🧚‍♀️💖

📦 where this page comes from