greybus: add Linaro copyrights

I was asked to add a Linaro copyright to all Greybus source files
that anyone at Linaro has modified.  This patch does that.

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

greybus: driver matching: Greybus drivers bind to interface blocks, not modules

Because of this, rename greybus_module_id to greybus_interface_block_id.

We still need to add a way for a "class" driver to be bound to an
interface, but for now, all we really need is the vendor/product pair as
the GP Bridge interface block is going to be our main user.

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

greybus: interface: document sysfs files

Yes, an interface has a device id sysfs file, so we need to document it.

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

greybus: connection: document the sysfs files

Document what the sysfs files are for connections, so that people have a
chance to understand what they can be used for.

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

greybus: interface_block: move sysfs files into the interface_block.c file

No need to keep these out in sysfs.c, move them into the
interface_block.c file so that we can see them easier, and remove some
variable definitions by taking advantage of the attribute group macro.

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

greybus: sysfs documentation: Document the greybus interface block sysfs files.

Documentation, what, really?

Yes.

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

greybus: interface_block: rename the sysfs files to not have 'module' in them

The sysfs files for an interface block should not have 'module' in them.
This was a hold-over from when we thought we were going to have
all attributes of a "module" in one directory.  Remove the prefix as
it's not needed, and is confusing considering modules can not have
strings or any of these attributes.

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

greybus: interface_block: s/gb_module/gb_interface_block/

Rename struct gb_module to struct gb_interface_block

It's a complex rename, some functions got their name changed where
needed, but primarily this change is focused on the structure and where
it is used.  Future changes will clean up the remaining usages of the
term "module" in individual changes, this one spanned the whole
subsystem so do it all at once.

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

greybus: interface_block: rename module.[c|h] to interface_block.[c|h]

"modules" in the driver model here, are really "interface blocks" as
that is what they are physically tied to.  So rename the files before we
start changing the code to make it obvious what is going on.

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

greybus: module: remove obsolete gb_tty pointer

We aren't using this anymore, so remove gb_tty from struct gb_module.

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

greybus: module versions: remove them

We removed the module version from the spec, so remove them from the
code as well.  It's still in the manifest as we need to sync with gbsim
/ firmware when we do that, which will happen sometime in the next
weeks.

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

greybus: uart-gb.c: don't include module.h

No need to specifically include the greybus module.h here, greybus.h
already does so and we will be renaming it soon.

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

greybus: switch cport id used for sends

In talking with Perry today I learned that the CPort id expected to
supplied over the HSIC interface to the APB is different from the
way I understood it.

My understanding was that the CPort id to supply always specified
the CPort id on the other end of a connection.  However, Perry says
the mapping between local CPort id and remote CPort id (and device
id) is done by the host UniPro interface.

So whether sending or receiving data, the CPort id that the Greybus
code should supply to the AP Bridge is the one representing the AP
side of a connection.

This patch fixes this.  The receive side already used that CPort id;
it's only the sending code that needed to be changed.

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

greybus: ENODEV can be an expected error too

When probing for i2c devices, a read transfer operation can be used.
In this case, it is expected that some devices will not be found, so
ENODEV is an expected failure.  Don't issue a warning if the return
value is -ENODEV.

Note:  I anticipate we might have to be more precise in identifying
this specific case, but for now this eliminates a bogus warning when
probing i2c devices.

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

greybus: define GB_OP_NONEXISTENT

The i2c protocol needs a way to indicate an i2c device doesn't exist
(which is not necessarily an error).  Define GB_OP_NONEXISTENT to
indicate this, and updating the status<->errno mapping functions
accordingly.

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

greybus: greybus_manifest.h: add FIXME for version

The version field is going to go away, but after the demo, not before.
Note that in the header file.

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

greybus: battery-gb.c: add new functions from Greybus spec document.

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

greybus: record type in operation structure

I've gone back and forth on this, but now that I'm looking at
asynchronous operations I know that the asynchronous callback will
want to know what type of operation it is handling, and right now
that's only available in the message header.

So record an operation's type in the operation structure, and use
it in a few spots where the header type was being used previously.
Pass the type to gb_operation_create_incoming() so it can fill
it in after the operation has been created.

Clean up the crap comments above the definition of the operation
structure.

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

greybus: use null pointer for empty payload

Currently message->payload always points to the address immediately
following the header in a message.  If the payload length is 0, this
is not a valid pointer.

Change the code to assign a null pointer to the payload in this
case.  I have verified that no code dereferences the payload pointer
unless the payload is known to have non-zero size.

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

greybus: only record message payload size

An asynchronous operation will want to know how big the response
message it receives is.  Rather than require the sender to record
that information, expose a new field "payload_size" available to
the protocol code for this purpose.

An operation message consists of a header and a payload.  The size
of the message can be derived from the size of the payload, so
record only the payload size and not the size of the whole message.
Reorder the fields in a message structure.

Update the description of the message header structure.

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

greybus: don't let i2c code assume non-null payload pointer

This is in preparation for an upcoming patch, which makes the
payload pointer be NULL when a message has zero bytes of payload.

It ensures a null payload pointer never gets dereferenced.  To do
this we pass the response structure to gb_i2c_transfer_response()
rather than just its data, and if it's null, returning immediately.

Rearrange the logic in gb_i2c_transfer_operation() a bit.

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

greybus: set up connection->private properly

The connection->private pointer should refer to a protocol-specific
data structure.  Change two protocol drivers (USB and vibrator) so
they now set this.

In addition, because the setup routine may need access to the
data structure, the private pointer should be set early--as
early as possible.  Make the UART, i2c, and GPIO protocol drivers
set the private pointer earlier.

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

greybus: fix an error message

The error message printed by gb_operation_sync() if the operation
fails is wrong.  Fix it.

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

greybus: introduce gb_operation_request_send_sync()

Define a new function used to initiate a synchronous operation.
It sends the operation request message and doesn't return until
the response has been received and/or the operation's result
has been set.

This gets rid of the convention that a null callback pointer
signifies a synchronous operation.

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

greybus: make op_cycle atomic (again)

There's no need to protect updating a connections operation id cycle
counter with the operations spinlock.   That spinlock protects
connection lists, which do not interact with the cycle counter.
All that we require is that it gets updated atomically, and we
can express that requirement in its type.

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

greybus: get rid of pending operations list

A connection has two lists of operations, and an operation is always
on one or the other of them.  One of them contains the operations
that are currently "in flight".

We really don't expect to have very many in-flight operations on any
given connection (in fact, at the moment it's always exactly one).
So there's no significant performance benefit to keeping these in a
separate list.  An in-flight operation can also be distinguished by
its errno field holding -EINPROGRESS.

Get rid of the pending list, and search all operations rather than
the pending list when looking up a response message's operation.
Rename gb_pending_operation_find() accordingly.

There's no longer any need to remove operations from the pending
list, and the insertion function no longer has anything to do with a
pending list.  Just open code what was the insertion function (it
now has only to do with assigning the operation id).

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

greybus: don't use 0 as an operation id

Stop allowing 0x0000 to be used as an operation id.  That id will be
reserved for use by operations that will return no response message.

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

greybus: define the invalid operation type symbolically

Use a symbolic constant (rather than just "0") to represent an
explicitly invalid operation type.  The protocols have all reserved
that value for that purpose--this just makes it explicit in the core
code (since we now leverage its existence).  Fix the code so it uses
the new symbolic value.

Define it in "operation.h" for all to see.  Move the common
definition of the GB_OPERATION_TYPE_RESPONSE flag mask there
as well.

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

greybus: fix a bug in gb_operation_sync()

The memcpy of request data into the request payload was
copying the data into the wrong location.  Fix that.

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

greybus: use little-endian in PWM requests

The PWM config request defines two 32-bit values using u32. All
over-the-wire values have to be in little-endian format.  Fix this.

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

greybus: send operation response messages

Define a helper function gb_operation_response_alloc() and use it
to allocate the response buffer for outgoing operations in
gb_operation_create_common(.

Use it also in  gb_operation_response_send() if the caller has not
allocated a response buffer.

Once a response buffer is allocated, fill in its result code and
send it.

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

greybus: introduce gb_operation_errno_map()

Define gb_operation_errno_map(), which maps an operation->errno
into the u8 value that represents it in the status field of an
operation response header.  It'll be used in an upcoming patch.

Make gb_operation_status_map() a private function.  It's not used
outside "operation.c" and I don't believe it ever should be.

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

greybus: activate incoming request handling

Un-comment gb_operation_request_handle(), which was recently
disabled to avoid distraction.

In gb_connection_recv_request(), activate handling incoming
requests by defining gb_operation_request_handle() as an
incoming operation's callback function.

Incoming operation requests have

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

greybus: set result in gb_operation_response_send()

Change gb_operation_response_send() so it takes an errno to assign
as an operation's result.  This emphasizes that setting the result
should be the last thing done to an incoming operation before
sending its response.

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

greybus: create a slab cache for simple messages

A large number of request and response message types have no payload.
Such "simple" messages have a known, fixed maximum size, so we can
preallocate and use a pool (slab cache) of them.

Here are two benefits to doing this:
    - There can be (small) performance and memory utilization
      benefits to using a slab cache.
    - Error responses can be sent with no payload; the cache is
      likely to have a free entry to use for an error response even
      in a low memory situation.

The plan here is that an incoming request handler that has no
response payload to fill will not need to allocate a response
message.  If no message has been allocated when a response is to be
sent, one will be allocated from the cache by the core code.

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

greybus: enforce a buffer headroom maximum size

Define a maximum size that a host device can use for its private
area ahead of the payload space used by Greybus in a message buffer.

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

greybus: introduce gb_operation_message_init()

Separate the allocation of a message structure from its basic
initialization.  This will allow very common fixed-size operation
response buffers to be allocated from a slab cache.

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

greybus: use operation type 0 to signal incoming data

When incoming data is going to be handled as a request, we create a
new operation whose request buffer will hold the received data.
There is no need to initialize the message header in such a request
buffer because it will be immediately overwritten.

Use operation type value of 0x00 in gb_operation_create_common()
to signal that we are creating an incoming operation, and therefore
do not need to initialize the request message header.  This allows
us to get rid of the Boolean "outgoing" parameter.

As a result, we can stop supplying the "type" parameter to both
gb_operation_create_incoming() and gb_connection_recv_request().

Update the header comments for gb_operation_message_alloc() and
gb_operation_create_common().

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

greybus: enforce non-zero operation type requirement

The operation type 0x00 is reserved as an explicitly invalid
operation type in all protocols.  Enforce this.

Add a check for callers who erroneously have the RESPONSE message
type flag set in the operation type passed in gb_operation_create().

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

greybus: pass result in gb_connection_recv_response()

Pass the operation result to gb_connection_recv_response() as a
parameter.

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

greybus: short message is OK for errors

We enforce a rule that a response message must completely fill the
buffer that's been allocated to hold it.  However, if an error
occurs, the payload is off limits, so we should allow a short
message to convey an error result.

Change gb_connection_recv_response() to require the right message
size only if there's no error.

One other thing:  The arriving data is only being copied into the
response buffer if the request was successful.  That means the
response message header is assumed to have been initialized.  That
isn't a valid assumption.  So change it so that if an error is
seen, the header portion of the message is copied into the
response buffer--but only the header.

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

greybus: move copy of incoming request data

Currently incoming request data is copied into a request message
buffer in gb_connection_recv_request().  Move that--along with the
assignment of the message id--into gb_operation_create_incoming().

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

greybus: operation: fix up sparse warning

gb_connection_recv_request should be static, so mark it as such.

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

greybus: always drop reference in gb_operation_work()

Currently we issue a warning in gb_operation_work() if an operation
has no callback function defined.  But we return without dropping
the reference to the operation as we should.

Stop warning if there's no callback, call it only if it's defined,
and always drop the operation reference before returning.

This means we're now treating a NULL callback pointer as a normal
condition.

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

greybus: drop gfp_mask from gb_message_send()

We will only send messages from process context.  Drop the gfp_mask
parameter from gb_message_send(), and just supply GFP_KERNEL to the
host driver's buffer_send method.

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

greybus: renumber operation result values

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>

greybus: define -EILSEQ to mean implementation error

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>

greybus: enforce max representable message size

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>

greybus: use outgoing flag when creating operation

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>

greybus: usb-gb: import a "buildable" version of the usb-gb.c driver

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>

greybus: protect cookie with a mutex

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>

greybus: ignore a null cookie when canceling buffer

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>

greybus: update operation result atomically

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>

greybus: enforce receive buffer size

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>

greybus: fix some error codes

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>

greybus: use special operation result valus

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>

greybus: first operation error prevails

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>

greybus: encapsulate operation result access

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>

greybus: uart-gb: clean up send_line_coding

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: es1-ap-usb: don't use 'es1' after it is freed

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>

greybus: pwm-gb: convert to use gb_operation_sync

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>

greybus: i2c-gb: convert to use gb_operation_sync

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>

greybus: gpio-gb: convert to use gb_operation_sync

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>

greybus: uart-gb: convert to use gb_operation_sync

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>

greybus: vibrator-gb: convert to use gb_operation_sync

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>

greybus: battery-gb: convert to use gb_operation_sync

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>

greybus: operation: create gb_operation_sync for sending "simple" messages

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>

greybus: rework synchronous operation completion

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>

greybus: kill gb_operation_wait()

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>

greybus: cancel whole operation on interrupt

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>

greybus: cancel operation on timeout

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>

greybus: minor tweak in gb_connection_recv_response()

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>

greybus: add a reference to pending operations

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>

greybus: handle data send errors in workqueue

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>

greybus: abandon incoming requests for now

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>

greybus: use errno for operation result

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>

greybus: Random spell fixes

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>

greybus: rename greybus_cport_in()

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>

greybus: define greybus_data_sent()

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>

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>

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: 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: 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: complete overflow responses

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>

greybus: fix a timeout race

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>

greybus: drop a now-empty structure

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>

greybus: add -Wall to the build flags

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>

greybus: pwm-gb.c: fix up missing { } for else

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>

greybus: uart-gb: fix up typo from previous patch moving the status variable around.

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

greybus: remove status from all responses

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>

greybus: define gb_operation_status_map()

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>

greybus: send operation result in response message header

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>

greybus: distinguish incoming from outgoing requests

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>

greybus: get rid of uart request_operation()

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>

greybus: uart-gb: handle throttle/unthrottle properly

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>

greybus: fix vibrator request_operation()

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>

greybus: fix uart request_operation()

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>

greybus: fix battery_operation()

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>

greybus: operation: don't complete operation twice

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>

greybus: refactor gb_connection_recv()

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>