Define a new operation status GB_OP_MALFUNCTION, which will be used
to represent that something unexpected happened while handling an
operation.  This is intended as an indication similar to a BUG()
call--whatever went wrong should *never* happen and because it's
unexpected we need to treat it as a fatal error.

Define another new operation status GB_OP_UNKNOWN_ERROR, which
will represent the case where an operation ended in error, but
the error was not recognized to be properly represented by one
of the other status values.

Renumber the operation status values, defining those that are
produced by core operations code ahead of those that are more
likely to come from operation handlers.  Represent the values in
hexadecimal to emphasize that they must be represented with 8 bits.
The Use 0xff for GB_OP_MALFUNCTION instead of GB_OP_TIMEOUT; the
latter is special, but a malfunction is in a class by itself.

Reorder the cases in gb_operation_status_map() to match their
numeric order.

Map GB_OP_UNKNOWN_ERROR to -EIO in gb_operation_status_map().  Map
GB_OP_MALFUNCTION to -EILSEQ in gb_operation_status_map(), since
that value is used to represent an implementation error.
Signed-off-by: Alex Elder <elder@linaro.org>
Signed-off-by: Greg Kroah-Hartman <greg@kroah.com>

Reserve operation result code -EILSEQ to represent that the code
that implements an operation is broken.  This is used (initially)
for any attempt to set the result to -EBADR (which is reserved for
an operation in initial state), or for an attempt to set the result
of an operation that is *not* in initial state to -EINPROGRESS.

Note that we still use -EIO gb_operation_status_map() to represent a
gb_operation_result value that isn't recognized.

In gb_operation_result(), warn if operation->errno is -EBADR.  That
is another value that indicates the operation is not in a state
where it's valid to query an operation's result.

Update a bunch of comments above gb_operation_result_set() to
explain constraints on operation->errno.
Signed-off-by: Alex Elder <elder@linaro.org>
Signed-off-by: Greg Kroah-Hartman <greg@kroah.com>

We represent the size of a message using a 16-bit field.  It's
possible for a host driver to advertise a maximum message size
that's bigger than that.  If that happens, reduce the host device's
maximum buffer size to the maximum we can represent the first time
a message is allocated.

This information is actually only used by the Greybus code, but
because we're modifying a value that's "owned" by the host driver,
issue a warning when this limit is being imposed

Ensure (at build time) that our own definition is sane as well.
Signed-off-by: Alex Elder <elder@linaro.org>
Signed-off-by: Greg Kroah-Hartman <greg@kroah.com>

In gb_operation_create_common(), a zero response size is still
being used to determine whether to use GFP_KERNEL or GFP_ATOMIC
when allocating a message.  Use the value of the "outgoing"
parameter to decide this instead.
Signed-off-by: Alex Elder <elder@linaro.org>
Signed-off-by: Greg Kroah-Hartman <greg@kroah.com>

Based on Fabien's original driver, this version is converted (mostly) to
the new greybus operation apis.  Lots of things still to do, not the
least being hooking up proper responses...
Signed-off-by: Greg Kroah-Hartman <greg@kroah.com>

When a Greybus message is sent, the host driver supplies a cookie
for Greybus to use to identify the sent message in the event it
needs to be canceled.  The cookie will be non-null while the message
is in flight, and a null pointer otherwise.

There are two problems with this, which arise out of the fact that a
message can be canceled at any time--even concurrent with it getting
sent (such as when Greybus is getting shut down).

First, the host driver's buffer_send method can return an error
value, which is non-null but not a valid cookie.  So we need to
ensure such a bogus cookie is never used to cancel a message.

Second, we can't resolve that problem by assigning message->cookie
only after we've determined it's not an error.  The instant
buffer_send() returns, the message may well be in flight and *should*
be canceled at shutdown, so we need the cookie value to reflect
that.

In order to avoid these problems, protect access to a message's
cookie value with a mutex.  A spin lock can't be used because the
window that needs protecting covers code that can block.  We
reset the cookie value to NULL as soon as the host driver has
notified us it has been sent (or failed to).
Signed-off-by: Alex Elder <elder@linaro.org>
Signed-off-by: Greg Kroah-Hartman <greg@kroah.com>

It's possible for an in-flight buffer to be recorded as sent *after*
a thread has begin the process of canceling it.  In that case the
Greybus message cookie will be set to NULL, and that value can end
up getting passed to buffer_cancel().  Change buffer_cancel() so
it properly handles (ignores) a null cookie pointer.
Signed-off-by: Alex Elder <elder@linaro.org>
Signed-off-by: Greg Kroah-Hartman <greg@kroah.com>

An operation result can be set both in and out of interrupt context.
For example, a response message could be arriving at the same time a
timeout of the operation is getting processed.  We therefore need to
ensure the result is accessed atomically.

Protect updates to the errno field using the operations spinlock.
Signed-off-by: Alex Elder <elder@linaro.org>
Signed-off-by: Greg Kroah-Hartman <greg@kroah.com>

When an operation is created its receive buffer size is specified.
In all current cases, the size supplied for the receive buffer is
exactly the size that should be returned.  In other words, if
any fewer than that many bytes arrived in a response, it would be
an error.

So tighten the check on the number of bytes arriving for a response
message, ensuring that the number of bytes received is *exactly the
same* as the number of bytes available (rather than just less than).
We'll expand our interpretation of of -EMSGSIZE to mean "wrong
message size" rather than just "message too long."

If we someday encounter an actual case where we want to be able to
successfully receive something less than the full receive buffer we
can adjust the code to handle that (and give it a way to tell the
receiver how many bytes are present).
Signed-off-by: Alex Elder <elder@linaro.org>
Signed-off-by: Greg Kroah-Hartman <greg@kroah.com>

Change the message result values used in two cases.

First, use -EMSGSIZE rather than -E2BIG to represent a message
that is larger than the buffer intended to hold it.  That is
the proper code for this situation.

Second, use -ECANCELED rather than -EINTR for an operation that
has been canceled.  The definition of that error is literally
"Operation Canceled" so it seems like the right thing to do.
Signed-off-by: Alex Elder <elder@linaro.org>
Signed-off-by: Greg Kroah-Hartman <greg@kroah.com>

This is more or less re-implementing this commit:
    96f95d4 greybus: update gbuf status for completion handlers
But this time we're doing this for an operation, not the gbuf.

Define an initial operation result value (-EBADR) to signify that no
valid result has been set.  Nobody should ever set that value after
the operation is initially created.  Since only the operation core
code sets the result, an attempt to set -EBADR would be a bug.

Define another known operation result value (-EINPROGRESS) for an
outgoing operation whose request has been sent but whose response
has not yet been successfully received.  This should the first
(non-initial) result value set, and it should happen exactly once.
Any other attempt to set this value once set would be a bug.

Finally, once the request message is in flight, the result value
will be set exactly once more, to indicate the final result of
the operation.
Signed-off-by: Alex Elder <elder@linaro.org>
Signed-off-by: Greg Kroah-Hartman <greg@kroah.com>

If an operation already has an error result recorded, don't
overwrite it with a new error code.

In order to ensure a request completes exactly once, return a
Boolean indicating whether setting the result was successful.  If
two threads are racing to complete an operation (for example if a
slow-but-normal response message arrives at the same time timeout
processing commences) only the one that sets the final result
will finish its activity.
Signed-off-by: Alex Elder <elder@linaro.org>
Signed-off-by: Greg Kroah-Hartman <greg@kroah.com>

Hide the setting and getting of the operation result (stored in
operation->errno) behind a pair of accessor functions.  Only the
operation core should be setting the result, but operations that
complete asynchronously will need access to the result so expose
the function that provides that.
Signed-off-by: Alex Elder <elder@linaro.org>
Signed-off-by: Greg Kroah-Hartman <greg@kroah.com>

We always pass the same option to send_line_coding() for the line_coding
structure, which is already in the struct gb_tty variable, so just
remove the second parameter as it's not needed.

This logic came from the cdc-acm.c driver, where it's also not needed
anymore, I'll go fix up that later on when I get a chance.
Signed-off-by: Greg Kroah-Hartman <greg@kroah.com>

greybus_remove_hd() will free memory allocated to 'es1' and so using it after
the routine has returned isn't right.
Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: Greg Kroah-Hartman <greg@kroah.com>

This converts the PWM protocol driver to use gb_operation_sync, removing
lots of places where the create/send/destroy pattern was being used to
send greybus messages.
Signed-off-by: Greg Kroah-Hartman <greg@kroah.com>
Reviewed-by: Alex Elder <elder@linaro.org>

This converts the I2C protocol driver to use gb_operation_sync, removing
lots of places where the create/send/destroy pattern was being used to
send greybus messages.
Signed-off-by: Greg Kroah-Hartman <greg@kroah.com>
Reviewed-by: Alex Elder <elder@linaro.org>

This converts the GPIO protocol driver to use gb_operation_sync,
removing lots of places where the create/send/destroy pattern was being
used to send greybus messages.
Signed-off-by: Greg Kroah-Hartman <greg@kroah.com>
Reviewed-by: Alex Elder <elder@linaro.org>

This converts the UART protocol driver to use gb_operation_sync,
removing lots of places where the create/send/destroy pattern was being
used to send greybus messages.
Signed-off-by: Greg Kroah-Hartman <greg@kroah.com>
Reviewed-by: Alex Elder <elder@linaro.org>

This converts the vibrator protocol driver to use gb_operation_sync,
removing the hand-rolled version of the same function, as well as
removing an open-coded version for a request when turning on the
vibrator motor.
Signed-off-by: Greg Kroah-Hartman <greg@kroah.com>
Reviewed-by: Alex Elder <elder@linaro.org>

This converts the battery protocol driver to use gb_operation_sync,
removing the hand-rolled version of the same function.
Signed-off-by: Greg Kroah-Hartman <greg@kroah.com>
Reviewed-by: Alex Elder <elder@linaro.org>

Everyone keeps doing the same create/send/destroy logic all over the
place, so abstract that out to a simple function that can handle any
arbritrary request and/or response.  This will let us save lots of
duplicated logic in the protocol drivers.
Signed-off-by: Greg Kroah-Hartman <greg@kroah.com>
Reviewed-by: Alex Elder <elder@linaro.org>

The only time we need a completion signaled on a request is when the
request provided no callback function.  In that case, we wait for
a completion on behalf of the caller.

If an interrupt occurs, we attempt to cancel the message that's
been sent, but we don't actually complete the operation as required.

Instead of simply waiting for the completion, put in place a
special callback function for the synchronous operation.  The
only job the callback has is to signal completion, allowing the
waiter to know it's done.

This means gb_operation_complete() will always have a non-null
callback pointer, so it becomes a simple wrapper, and we can get rid
of it and invoke the callback directly, in gb_operation_work().

Be defensive by checking for a null callback pointer, and reset
it to NULL once it's been called.
Signed-off-by: Alex Elder <elder@linaro.org>
Signed-off-by: Greg Kroah-Hartman <greg@kroah.com>

When a caller wants an operation to complete synchronously, there is
generally no need for any other threads to wait for the operation's
completion.  So here's no need for gb_operation_wait() to be
available for synchronous requests.  At the moment, all operations
are done synchronously.

Knowing that, get rid of the public gb_operation_wait() function,
and open-code it in gb_operation_request_send().  The public wait
function can be re-implemented when it's really needed.

With that function gone, the only waiter for the completion of an
operation is the submitter itself, and only then if it's
synchronous.  So rather than complete_all(), we can simply use
complete() to signal the submitter.
Signed-off-by: Alex Elder <elder@linaro.org>
Signed-off-by: Greg Kroah-Hartman <greg@kroah.com>

Cancel the operation--not just the request message--if waiting
for a synchronous operation to complete is interrupted.  Return
the operation result (which in that case will be -EINTR).  The
cancelation will result in the normal operation completion path
being taken before returning.

Make gb_operation_wait() private, since it's only ever used for
for synchronous operations.
Signed-off-by: Alex Elder <elder@linaro.org>
Signed-off-by: Greg Kroah-Hartman <greg@kroah.com>

If an operation times out, we need to cancel whatever message it
has in-flight.  Do that instead of completing the operation, in the
timeout handler.  When the in-flight request message is canceled its
completion function will lead to the proper completion of the
operation.

Change gb_operation_cancel() so it takes the errno that it's
supposed to assign as the result of the operation.

Note that we want to preserve the original -ETIMEDOUT error, so
don't overwrite the operation result value if it has already been
set.
Signed-off-by: Alex Elder <elder@linaro.org>
Signed-off-by: Greg Kroah-Hartman <greg@kroah.com>

Any time we queue work on the operation work queue we need to have
set the operation errno first.

This patch moves the assignment of that field to be immediately
prior to the queue_work() call in gb_connection_recv_response(),
so it is easier to see at a glance that this has been done.
Signed-off-by: Alex Elder <elder@linaro.org>
Signed-off-by: Greg Kroah-Hartman <greg@kroah.com>

Grab an extra reference to an operation before sending it.  Drop
that reference at the end of its completion handling.

It turns out gb_operation_get() got deleted along the way, so this
re-introduces it.  We're assuming we only get a reference when
there's at least one in existence so we don't need a semaphore to
protect it.  Emphasize this by *not* returning a pointer to
the referenced operation.
Signed-off-by: Alex Elder <elder@linaro.org>
Signed-off-by: Greg Kroah-Hartman <greg@kroah.com>

The data sent callback can execute in atomic context.  If an error
occurred, we shouldn't be completing the operation right then and
there.  Instead, hand it off to the operation workqueue to complete
the operation.
Signed-off-by: Alex Elder <elder@linaro.org>
Signed-off-by: Greg Kroah-Hartman <greg@kroah.com>

Change the operation "receive workqueue" to be just the operation
"workqueue".  All it does is complete an operation in non-atomic
context.  This is all that's required for an outgoing request.

Similarly, ignore any notion that a response will only exist
for outgoing requests in gb_operation_cancel().

I'm doing this in the interest of getting the outgoing request path
verified without the encumbrance of any preconceptions about how
incoming requests need to work.  When I finally turn my full
attenion to incoming requests I'll adapt the code as needed.
Signed-off-by: Alex Elder <elder@linaro.org>
Signed-off-by: Greg Kroah-Hartman <greg@kroah.com>

An in-core operation structure tracks the progress of an operation.
Currently it holds a result field that was intended to take the
status value that arrives in an operation response message header.

But operations can fail for reasons other than that, and it's
inconvenient to try to represent those using the operation status
codes.

So change the operation->result field to be an int, and switch to
storing negative errno values in it.  Rename it "errno" to make
it obvious how to interpret the value.

This patch makes another change, which simplifies the protocol drivers
a lot.  It's being done as part of this patch because it affects all
the same code as the above change does.  If desired I can split this
into two separate patches.

If a caller makes a synchronous gb_operation_request_send() request
(i.e., no callback function is supplied), and the operation request
and response messages were transferred successfully, have
gb_operation_request_send() return the result of the request (i.e.,
operation->errno).  This allows the caller (or more generally, any
caller of gb_request_wait() to avoid having to look at this field
for every successful send.

Any caller that does an asynchronous request will of course need
to look at request->errno in the callback function to see the
result of the operation.
Signed-off-by: Alex Elder <elder@linaro.org>
Signed-off-by: Greg Kroah-Hartman <greg@kroah.com>

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

This function is associated with a host device (interface), not a
CPort.  Change its name to reflect that, and to match its "sent"
callback counterpart.
Signed-off-by: Alex Elder <elder@linaro.org>
Signed-off-by: Greg Kroah-Hartman <greg@kroah.com>

Define greybus_data_sent(), which is a callback the host driver
makes when a buffer send request has completed.  The main use for
this is to actively detect errors that can occur while sending.
(Something like this existed at one time and was removed.)

This also defines gb_hd_message_find(), which looks up a message
pointer associated with a buffer sent over a given host device.
This is now a pretty trival mapping.
Signed-off-by: Alex Elder <elder@linaro.org>
Signed-off-by: Greg Kroah-Hartman <greg@kroah.com>

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>

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>

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>

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>

If a response arrives for an operation request and the allotted
buffer isn't big enough we report the error, but we don't finish
processing the response.

Instead, set the operation result, but then finish processing
the response (no different from any other operation error).

This will allow the normal completion handling to occur for
this error case.
Signed-off-by: Alex Elder <elder@linaro.org>
Signed-off-by: Greg Kroah-Hartman <greg@kroah.com>

Whenever we send a request message we start a timer to ensure the
we don't wait too long for the matching response to arrive.
Currently we set up the timeout *after* sending the message, but
that is subject to a race--the response could arrive (and the
timeout prematurely disabled) before the timeout is even set up.

Set up the timeout before sending the message.
Signed-off-by: Alex Elder <elder@linaro.org>
Signed-off-by: Greg Kroah-Hartman <greg@kroah.com>