STRUCT RPMSG_ENDPOINT(9)

πŸ“¦ version 7.3.1, in nixpkgs unstable

✨ NAME ✨

ok so welcome to the Kernel API Manual bestie πŸ’– this page is all about struct rpmsg_endpoint β€” and what it does is literally bind a local rpmsg address to its user. that's the whole vibe. πŸŽ€


🌸 SYNOPSIS 🌸

here's the struct in all its iconic glory, copy it exactly bestie, no typos:

struct rpmsg_endpoint {
    struct rpmsg_device *rpdev;
    struct kref refcount;
    rpmsg_rx_cb_t cb;
    rpmsg_flowcontrol_cb_t flow_cb;
    struct mutex cb_lock;
    u32 addr;
    void *priv;
    const struct rpmsg_endpoint_ops *ops;
 };

πŸ’… Members πŸ’…

okay let's go through every single one, no skipping, we don't do that here:

  • rpdev β€” the rpmsg channel device. the device bestie. 🫢
  • refcount β€” when this drops to zero, the ept is deallocated. so like… when the count hits 0, it's over, the endpoint is gone, bye. literally. πŸ’€
  • cb β€” the rx callback handler. πŸ‘‘
  • flow_cb β€” the remote flow control callback handler. 🌊
  • cb_lock β€” a mutex that must be taken before accessing/changing cb. not optional, not a suggestion, take the lock fr fr πŸ”’
  • addr β€” local rpmsg address. πŸ“
  • priv β€” private data for the driver's use. that's the driver's own little stash, hands off. πŸ™ˆ
  • ops β€” the ops pointer, const struct rpmsg_endpoint_ops *. ✨

πŸ¦‹ Description πŸ¦‹

so in essence (love that word), an rpmsg endpoint represents a listener on the rpmsg bus, because it binds an rpmsg address with an rx callback handler. that's the whole point of it. it's literally giving "address + callback = besties". πŸ’–

and here's the part that matters: simple rpmsg drivers shouldn't use this struct directly, because things just work. like, the kernel handles it. every rpmsg driver provides an rx callback upon registering to the bus, and that callback is then bound to its rpmsg address when the driver is probed. then when relevant inbound messages arrive β€” i.e. messages which their dst address equals to the src address of the rpmsg channel β€” the driver's handler is invoked to process it. so you never even have to think about it. slay. 🌈

ngl, if you're a simple driver, do NOT touch this struct. it's already handled. stay in your lane (affectionately). 🫢

but the more complicated drivers though β€” the ones that do need to allocate additional rpmsg addresses, and bind them to different rx callbacks β€” those must explicitly create additional endpoints by themselves (see rpmsg_create_ept). that's you, main character energy, you gotta do it manually. πŸ”₯


⭐ SEE ALSO ⭐

go read these next, iykyk:

  • Kernel file ./include/linux/rpmsg.h
  • struct rpmsg_channel_info(9)
  • struct rpmsg_driver(9)
  • module_rpmsg_driver(9)

and that's the page bestie!! πŸŽ€ it lives over in ./include/linux, stamped October 2026, and it's all about struct rpmsg_endpoint(9) β€” go forth and bind those addresses πŸ’œβœ¨

πŸ“¦ where this page comes from