On 9 May 2013 23:35, Suman Anna <s-a...@ti.com> wrote: >> >> Perhaps we should change the following >> >> void ipc_link_txdone(struct ipc_link *link, enum xfer_result r) >> to >> void ipc_link_txdone(struct ipc_link *link, enum xfer_result r, void >> *data) >> >> So that the API could pass that onto clients ? > > That's if the controller needs to pass some data back to client. I am > fine with that as well, No, I misunderstood you wanted request_token_t to be replaced with the pointer of request that was executed.
> but I am talking mainly about providing a client > user data ptr back to it during callbacks. > > struct ipc_client { > char *chan_name; > + void *cl_data; /* store it to ipc_chan as well */ > - void (*rxcb)(void *data); > - void (*txcb)(request_token_t t, enum xfer_result r); > + void (*rxcb)(void *cl_data, void *data); > + void (*txcb)(request_token_t t, enum xfer_result r, void *cl_data); > ... > } > > I am obviously interested in the rxcb. The controller implementations do > not see the cl_data. > OK I see what you mean. However the API storing and passing back ad-hoc data to clients doesn't seem very neat. Such purposes are usually served by : - void (*rxcb)(void *data); + void (*rxcb)(struct ipc_client *cl, void *data); /* client for which data was received */ - void (*txcb)(request_token_t t, enum xfer_result r); + void (*txcb)(struct ipc_client *cl, request_token_t t, enum xfer_result r); /* client whose data was sent */ You could then get relevant omap_rproc using container_of() on 'cl', in rxcb() and txcb(). Apart from this, in txcb, perhaps we should drop request_token_t in favor of the request's pointer (void *data) that was last executed. That should make things easier for clients. regards, -jassi -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/