Thread (2 messages) 2 messages, 2 authors, 2015-02-05

[PATCH v5 2/7] mailbox: arm_mhu: add driver for ARM MHU controller

From: arnd@arndb.de (Arnd Bergmann)
Date: 2015-02-04 16:42:01
Also in: linux-devicetree

On Wednesday 04 February 2015 21:03:50 Jassi Brar wrote:
On 4 February 2015 at 20:18, Arnd Bergmann [off-list ref] wrote:
quoted
On Wednesday 04 February 2015 20:04:21 Jassi Brar wrote:
quoted
quoted
Using the bits of the pointer as the message instead of pointing
to the message feels like an abuse of the API.
I can see your POV.
Now consider a client, like mine, that sends a u32 value as the data.
But unlike me, the client uses the mailbox api in 'async' mode i.e,
register a callback function, submit a 32bit message and move on. It
is perfectly doable, but doesn't kalloc'ing a u32 for each submission,
seem overkill?
That could easily be done by dereferencing the message data in the
function that queues the asynchronous message: instead of queuing
the pointer, you queue the data in the driver.
The 'void *data' is not queued in the driver, but in the API code. Or
do I not get your point?
My mistake. If the API keeps that pointer after returning to the caller
here, this is indeed a problem for callers that have the message on the
stack.

The solution of storing the message in a circular buffer (in the API)
would in turn require knowing the length of the data.

Another option would be to require that the asynchronous version of the
interface cannot be used with on-stack data and requires the object
lifetime to be managed by the caller, which seems reasonable to me
since you already need the completion callback.

	Arnd
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help