greybus: have greybus allocate its own buffers

Rather than having the host driver allocate the buffers that the
Greybus core uses to hold its data for sending or receiving, have
the host driver define what it requires those buffers to look like.

Two constraints define what the host driver requires: the maximum
number of bytes that the host device can send in a single request;
and a statement of the "headroom" that needs to be present for
use by the host device.

The direct description of the headroom is that it's the extra byte
the host device needs at the beginning of the "data" portion of
the buffer so the ES1 driver can insert the destination CPort id.
But more generally, the host driver could put other data in there
as well.

By stating these two parameters, Greybus can allocate the buffers it
uses by itself.  The host driver still allocates the buffers it uses
for receiving data--the content of those are copied as needed into
Greybus buffers when data arrives.

Signed-off-by: Alex Elder <elder@linaro.org>
Signed-off-by: Greg Kroah-Hartman <greg@kroah.com>
greybus: rename message buffer fields

The beginning of an operation message always contains the message
header.  Rename the "buffer" field in an operation message to
be "header" to reflect this.  Change its type as well.

The size of a message is the combined size of its header and its
payload.  Rename the "buffer_size" field in a message header to
be simply "size", so message->size describes exactly that.

Signed-off-by: Alex Elder <elder@linaro.org>
Signed-off-by: Greg Kroah-Hartman <greg@kroah.com>
greybus: dynamically allocate requests and responses

Have an operation's request and response messages be dynamically
allocated rather than embedded in an operation.

Signed-off-by: Alex Elder <elder@linaro.org>
Signed-off-by: Greg Kroah-Hartman <greg@kroah.com>
greybus: embed message buffer into message structure

Embed the buffer for message data into the message structure itself.
This allows us to use a single allocation for each message, and
more importantly will allow us to derive the message structure
describing a message from the buffer itself.

Signed-off-by: Alex Elder <elder@linaro.org>
Signed-off-by: Greg Kroah-Hartman <greg@kroah.com>