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>

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>

s/i2c/vibrator/
Signed-off-by: Greg Kroah-Hartman <greg@kroah.com>

The only reason gb_operation_message_init() gets its "outbound"
argument is so we can determine what allocation flags to use.
Just pass the flags in directly instead.
Signed-off-by: Alex Elder <elder@linaro.org>
Signed-off-by: Greg Kroah-Hartman <greg@kroah.com>

We can derive the destination CPort id of any (outbound) message
from the connection it's operation is associated with.  So we don't
need to store that information in every message.

As a result, we no longer need to record it at message initialization
time.
Signed-off-by: Alex Elder <elder@linaro.org>
Signed-off-by: Greg Kroah-Hartman <greg@kroah.com>

The host device pointer doesn't have to be stored in every message.
It can be derived by following up the chain of pointers back to
the operation's connection.
Signed-off-by: Alex Elder <elder@linaro.org>
Signed-off-by: Greg Kroah-Hartman <greg@kroah.com>

All the code has now been adjusted such that we can do away with the
old gbuf structure.

Three unused references remained in "greybus.h", so those are deleted.

Other than that most of the changes were done by simple global
substitution.  The gb_message structure incorporates the fields that
were previously found its embedded gbuf structure.  A few names have
been changed in the process:
    gbuf->transfer_buffer       message->buffer
    gbuf->transfer_buffer_size  message->buffer_size
    gbuf->hcd_data;             message->cookie
Signed-off-by: Alex Elder <elder@linaro.org>
Signed-off-by: Greg Kroah-Hartman <greg@kroah.com>

Rework gb_connection_operation_recv() to be more oriented toward an
operation message, and to no longer use a struct gbuf local variable.
Rename it to be a little more wieldy.
Signed-off-by: Alex Elder <elder@linaro.org>
Signed-off-by: Greg Kroah-Hartman <greg@kroah.com>

Rework greybus_kill_gbuf() to be oriented toward an operation
message rather than a gbuf, and rename it.
Signed-off-by: Alex Elder <elder@linaro.org>
Signed-off-by: Greg Kroah-Hartman <greg@kroah.com>

Rework greybus_submit_gbuf() to be oriented toward an operation
message rather than a gbuf, and rename it accordingly.
Signed-off-by: Alex Elder <elder@linaro.org>
Signed-off-by: Greg Kroah-Hartman <greg@kroah.com>

Rework gb_opreation_message_init() so it doesn't use a struct gbuf
local variable.
Signed-off-by: Alex Elder <elder@linaro.org>
Signed-off-by: Greg Kroah-Hartman <greg@kroah.com>

Change the method that sends messages so that it sends "raw" buffers
rather than gbufs.  To do this, we supply the host device and
destination CPort when sending.  As with other recent patches,
change the name of the method to reflect that we're no longer
dealing with gbufs.

The interface has changed as well.  Now this routine will return a
"cookie" value.  The cookie is used to represent the outgoing
request, and is supplied by the caller if necessary to cancel a
previously-sent buffer.  We'll store the result in gbuf->hcd_data
for now (which produces the same result as before...).
Signed-off-by: Alex Elder <elder@linaro.org>
Signed-off-by: Greg Kroah-Hartman <greg@kroah.com>

This changes the context value stashed with each USB URB so that it
is always the host device pointer.

In cport_out_callback() this allows us to get away with *not*
requiring the gbuf for handling completions any more.  We are
(currently) ignoring the gbuf status value returned anyway, so
we'll skip setting it altogether.

Greg's comments in cport_out_callback() point out that ignoring
this was misguided, and handling send errors will be put in
place in an upcoming patch.

The context is set to the host device pointer for SVC receive and
CPort receive URBs for consistency--because we can.
Signed-off-by: Alex Elder <elder@linaro.org>
Signed-off-by: Greg Kroah-Hartman <greg@kroah.com>

Change the interface for canceling in-flight buffers to take a magic
cookie value as argument rather than a gbuf.  Right now we pass the
gbuf->hcd_data pointer that's assumed to have been set by the submit
routine.  But the next patch will change the submit routine to
return the cookie to be used, and the caller will be responsible for
keeping track of it.
Signed-off-by: Alex Elder <elder@linaro.org>
Signed-off-by: Greg Kroah-Hartman <greg@kroah.com>

Switch the host driver free routine to take a pointer to the
previously-allocated buffer that should be freed.

Rename the method to reflect it's no longer tied to a gbuf.
Signed-off-by: Alex Elder <elder@linaro.org>
Signed-off-by: Greg Kroah-Hartman <greg@kroah.com>

This begins the transition to buffer allocation that does not rely
on the gbuf construct.

The host driver allocation routine will return a pointer to the
buffer to be used, and the caller will be responsible for keeping
track of that pointer, as well as the requested buffer size.

Rename the allocation method to reflect it's no longer tied to a
gbuf.
Signed-off-by: Alex Elder <elder@linaro.org>
Signed-off-by: Greg Kroah-Hartman <greg@kroah.com>

For ES1 we need to insert the destination CPort id before the data
to be sent over UniPro.  Currently this is done at the time the
buffer is created, but there's no need to do so until we're actually
going to send the content of the buffer.

Move the setting of that destination information into submit_gbuf().
Note that this allows us to defer initializing a few other gbuf
fields until after we know the buffer allocation has succeeded.
Signed-off-by: Alex Elder <elder@linaro.org>
Signed-off-by: Greg Kroah-Hartman <greg@kroah.com>

For ES1 we need to insert the destination CPort id in whatever we
supply for sending over UniPro.  Currently we allocate one extra
byte supply the caller with an address that's offset by one from
the beginning of the allocated space.

As a result we always return a poorly-aligned buffer pointer.

Instead, allocate enough space so that we can return a better
aligned buffer to the caller.

Notes:
    - It may be that it's more important to supply an aligned
      address to the hardware.
    - We probably need to be more careful about writing into
      these buffers at unaligned offsets anyway.  (E.g., writing
      a 2-byte value at an odd offset can't be assumed to work.)
Signed-off-by: Alex Elder <elder@linaro.org>
Signed-off-by: Greg Kroah-Hartman <greg@kroah.com>