- - every rpmsg address in the system is bound to an rx callback (so when
- inbound messages arrive, they are dispatched by the rpmsg bus using the
- appropriate callback handler) by means of an rpmsg_endpoint struct.
-
- This function allows drivers to create such an endpoint, and by that,
- bind a callback, and possibly some private data too, to an rpmsg address
- (either one that is known in advance, or one that will be dynamically
- assigned for them).
-
- Simple rpmsg drivers need not call rpmsg_create_ept, because an endpoint
- is already created for them when they are probed by the rpmsg bus
- (using the rx callback they provide when they registered to the rpmsg bus).
-
- So things should just work for simple drivers: they already have an
- endpoint, their rx callback is bound to their rpmsg address, and when
- relevant inbound messages arrive (i.e. messages which their dst address
- equals to the src address of their rpmsg channel), the driver's handler
- is invoked to process it.
-
- That said, more complicated drivers might do need to allocate
- additional rpmsg addresses, and bind them to different rx callbacks.
- To accomplish that, those drivers need to call this function.
- Drivers should provide their channel (so the new endpoint would bind
- to the same remote processor their channel belongs to), an rx callback
- function, an optional private data (which is provided back when the
- rx callback is invoked), and an address they want to bind with the
- callback. If addr is RPMSG_ADDR_ANY, then rpmsg_create_ept will
- dynamically assign them an available rpmsg address (drivers should have
- a very good reason why not to always use RPMSG_ADDR_ANY here).
-
- Returns a pointer to the endpoint on success, or NULL on error.
+
+every rpmsg address in the system is bound to an rx callback (so when
+inbound messages arrive, they are dispatched by the rpmsg bus using the
+appropriate callback handler) by means of an rpmsg_endpoint struct.
+
+This function allows drivers to create such an endpoint, and by that,
+bind a callback, and possibly some private data too, to an rpmsg address
+(either one that is known in advance, or one that will be dynamically
+assigned for them).
+
+Simple rpmsg drivers need not call rpmsg_create_ept, because an endpoint
+is already created for them when they are probed by the rpmsg bus
+(using the rx callback they provide when they registered to the rpmsg bus).
+
+So things should just work for simple drivers: they already have an
+endpoint, their rx callback is bound to their rpmsg address, and when
+relevant inbound messages arrive (i.e. messages which their dst address
+equals to the src address of their rpmsg channel), the driver's handler
+is invoked to process it.
+
+That said, more complicated drivers might do need to allocate
+additional rpmsg addresses, and bind them to different rx callbacks.
+To accomplish that, those drivers need to call this function.
+Drivers should provide their channel (so the new endpoint would bind
+to the same remote processor their channel belongs to), an rx callback
+function, an optional private data (which is provided back when the
+rx callback is invoked), and an address they want to bind with the
+callback. If addr is RPMSG_ADDR_ANY, then rpmsg_create_ept will
+dynamically assign them an available rpmsg address (drivers should have
+a very good reason why not to always use RPMSG_ADDR_ANY here).
+
+Returns a pointer to the endpoint on success, or NULL on error.
+
+::