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>

One structure, gb_gpio_activate_response, was not deleted even
though it now has no contents.  Delete it.
Signed-off-by: Alex Elder <elder@linaro.org>
Signed-off-by: Greg Kroah-Hartman <greg@kroah.com>

In an attempt to turn on as many options as we can to catch warnings
early, let's enable -Wall.
Signed-off-by: Greg Kroah-Hartman <greg@kroah.com>
Reviewed-by: Alex Elder <elder@linaro.org>

This was a compiler warning, which looked correct, but was trying to
tell us something else...
Signed-off-by: Greg Kroah-Hartman <greg@kroah.com>

Signed-off-by: Greg Kroah-Hartman <greg@kroah.com>

This is a pervasive change, but not really a big one.  However:

        ==============  Pay attention to this ==============
	If you're doing any testing with "gbsim" you need to
	update that program in sync with this change, because
	it changes the protocol used between them.
        ==============  Pay attention to this ==============

The status of a request is now recorded in the header of a response
message.  The previous patch put that header status byte in place,
and this one removes the status byte from all the response
messages.

And finally, since we're modifying all these files anyway...
Use gb_operation_status_map() to come up with a return code
to use, given an operation response.  Right now most errors
simply result in -EIO getting returned.
Signed-off-by: Alex Elder <elder@linaro.org>
Signed-off-by: Greg Kroah-Hartman <greg@kroah.com>

Define a common function that maps an operation status value to a
Linux negative errno.
Signed-off-by: Alex Elder <elder@linaro.org>
Signed-off-by: Greg Kroah-Hartman <greg@kroah.com>

Define a result byte in an operation response message header.

All the protocols now define the mandatory status as the first
byte in their response message.  Assume that, for the moment,
and save that value into the header result field (until we can
get the simulator set up to handle the new protocol).

Record the result from the response header as the result of the
overall operation.

Start enforcing the rule that we ignore all response payload (in
fact, the entire message) if we see a non-zero result value.
Signed-off-by: Alex Elder <elder@linaro.org>
Signed-off-by: Greg Kroah-Hartman <greg@kroah.com>

When we remove the mandatory status byte from response messages we
will no longer be able to use a zero-sized response to indicate
an operation is to be used for an incoming request.

Define a new function gb_operation_create_incoming() to be used
for incoming operations.  Change (and rename) gb_operation_create()
to be a helper that takes a Boolean to indicate which type is to be
created, and use a simple wrapper to expose the outgoing operation
creation routine.
Signed-off-by: Alex Elder <elder@linaro.org>
Signed-off-by: Greg Kroah-Hartman <greg@kroah.com>

In "uart-gb.c", request_operation() function is only used by
get_version().  Since it's not reused, it probably subtracts
rather than adds value.  So just incorporate what it does
into get_version() and get rid of request_operation().
Signed-off-by: Alex Elder <elder@linaro.org>
Signed-off-by: Greg Kroah-Hartman <greg@kroah.com>

This hooks up throttle/unthrottle to properly toggle the RTS line or do
XON/XOFF if that is how the port is set up.

Note, if the UART itself can handle XON/XOFF, we would need to send the
correct character down to it, to have the firmware in the device set up
the chip to use it automatically when needed.  The odds of someone
wanting to use this type of flow control is slim, so this isn't
implemented at this point in time.

Also fill in a few more fields in the get_serial_info ioctl, to make
tools like stty(1) happier.
Signed-off-by: Greg Kroah-Hartman <greg@kroah.com>

And this fixes a problem similar the last two, this time found in
the vibrator protcool driver code.

Change a variable name in get_version() to reflect that it holds
a response message, not a request message.
Signed-off-by: Alex Elder <elder@linaro.org>
Signed-off-by: Greg Kroah-Hartman <greg@kroah.com>

This fixes a problem similar to what was found in the battery
protcool driver code.

There's no need to allocate a local buffer, that already set up
by gb_operation_create().  Just use that instead.

Change a few variable names to reflect that they hold response
messages, not request messages.
Signed-off-by: Alex Elder <elder@linaro.org>
Signed-off-by: Greg Kroah-Hartman <greg@kroah.com>

This patch fixes some problems with the battery protocol driver.

First, when gb_operation_create() is called, it creates buffers of
the requested sizes to hold the operation request and response
messages.  There is therefore no reason to allocate a local response
buffer.  By the time the (synchronous) gb_operation_request_send()
call returns, the operation response buffer will have been filled in.

(In addition, the content of local_response was not being filled
before its contents were used...)

Next, all the message structures are misnamed.  The structures that
are defined are all the content of operation response messages (not
request messages).  So this changes all the types names to properly
reflect their role.

All the local variables using these types are similarly renamed.

I added a new type, gb_generic_battery_response, to be used for
casting the fake_response used in battery_operation().
Signed-off-by: Alex Elder <elder@linaro.org>
Signed-off-by: Greg Kroah-Hartman <greg@kroah.com>

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

Define two helper functions to break down handling of a received
message.  One is used to handle receiving an incoming request
message, the other for a response message.

Three other changes are made:
    - We verify message size recorded in the message header does not
      exceed the amount of data that's arriving.
    - We no longer warn if a request' recorded message size differs
      from the number of bytes that have arrived.
    - We now record the operation id for an incoming request.
Signed-off-by: Alex Elder <elder@linaro.org>
Signed-off-by: Greg Kroah-Hartman <greg@kroah.com>

A message header contains a field "id" that is an operation id.
Since the field doesn't identify the message itself, rename this
field so it's clearer what it's referring to.

Similarly gb_pending_operation_find() has a parameter "id" that
is really an operation id, so rename that as well.
Signed-off-by: Alex Elder <elder@linaro.org>
Signed-off-by: Greg Kroah-Hartman <greg@kroah.com>

We (sort of) maintain the status of each message, but we shouldn't
need to.  Right now we're not using it consistently in any case.

If a message fails to send, the caller will know to destroy the
operation that contained it.

If a message has been sent (i.e., handed to the host device layer)
it'll have a non-null cookie pointer.

If a does complete in error, we can update the status of the
operation that contains it.  That isn't happening right now but
it will soon.
Signed-off-by: Alex Elder <elder@linaro.org>
Signed-off-by: Greg Kroah-Hartman <greg@kroah.com>

The only use of local variable "es1" in in svc_in_callback() and
cport_in_callback() is to get at its hd field.  But we already have
that, so we can get rid of that local variable.

Also, rename the "cport" variable "cport_id" in cport_in_callback()
is to match the convention used elsewhere, and make it the proper
u16 type.
Signed-off-by: Alex Elder <elder@linaro.org>
Signed-off-by: Greg Kroah-Hartman <greg@kroah.com>

Use simple macros to mark the conversion of an URB pointer into an
opaque cookie value (and vice-versa).  We scramble some bits, but
the main point is to make it explicit where we're returning and
using opaque values.
Signed-off-by: Alex Elder <elder@linaro.org>
Signed-off-by: Greg Kroah-Hartman <greg@kroah.com>

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

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