Alex Elder [Mon, 1 Dec 2014 13:53:08 +0000 (07:53 -0600)]
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>
Alex Elder [Mon, 1 Dec 2014 13:53:07 +0000 (07:53 -0600)]
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>
Alex Elder [Mon, 1 Dec 2014 13:53:06 +0000 (07:53 -0600)]
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...
Alex Elder [Tue, 25 Nov 2014 22:54:04 +0000 (16:54 -0600)]
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>
Alex Elder [Tue, 25 Nov 2014 22:54:03 +0000 (16:54 -0600)]
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>
Alex Elder [Tue, 25 Nov 2014 22:54:02 +0000 (16:54 -0600)]
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>
Alex Elder [Tue, 25 Nov 2014 19:06:45 +0000 (13:06 -0600)]
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>
Alex Elder [Tue, 25 Nov 2014 19:06:44 +0000 (13:06 -0600)]
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>
Alex Elder [Tue, 25 Nov 2014 17:33:15 +0000 (11:33 -0600)]
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>
Alex Elder [Tue, 25 Nov 2014 17:33:14 +0000 (11:33 -0600)]
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>
Alex Elder [Tue, 25 Nov 2014 17:33:13 +0000 (11:33 -0600)]
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>
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.
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>
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: 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>
Alex Elder [Sat, 22 Nov 2014 01:29:20 +0000 (19:29 -0600)]
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>
Alex Elder [Sat, 22 Nov 2014 01:29:19 +0000 (19:29 -0600)]
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>
Alex Elder [Sat, 22 Nov 2014 01:29:18 +0000 (19:29 -0600)]
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>
Alex Elder [Sat, 22 Nov 2014 01:29:17 +0000 (19:29 -0600)]
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>
Alex Elder [Sat, 22 Nov 2014 01:29:16 +0000 (19:29 -0600)]
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>
Alex Elder [Sat, 22 Nov 2014 01:29:15 +0000 (19:29 -0600)]
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>
Alex Elder [Sat, 22 Nov 2014 01:29:14 +0000 (19:29 -0600)]
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>
Alex Elder [Sat, 22 Nov 2014 01:29:13 +0000 (19:29 -0600)]
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>
Alex Elder [Sat, 22 Nov 2014 01:29:12 +0000 (19:29 -0600)]
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>
Alex Elder [Thu, 20 Nov 2014 22:09:18 +0000 (16:09 -0600)]
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>
Alex Elder [Thu, 20 Nov 2014 22:09:17 +0000 (16:09 -0600)]
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>
Alex Elder [Thu, 20 Nov 2014 22:09:16 +0000 (16:09 -0600)]
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>
Alex Elder [Thu, 20 Nov 2014 22:09:14 +0000 (16:09 -0600)]
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>
Alex Elder [Thu, 20 Nov 2014 22:09:13 +0000 (16:09 -0600)]
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>
Alex Elder [Thu, 20 Nov 2014 21:37:07 +0000 (15:37 -0600)]
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>
Alex Elder [Thu, 20 Nov 2014 21:37:06 +0000 (15:37 -0600)]
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>
Alex Elder [Wed, 19 Nov 2014 23:55:05 +0000 (17:55 -0600)]
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>
Alex Elder [Wed, 19 Nov 2014 23:55:03 +0000 (17:55 -0600)]
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>
Alex Elder [Wed, 19 Nov 2014 23:55:02 +0000 (17:55 -0600)]
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>
Alex Elder [Wed, 19 Nov 2014 23:55:01 +0000 (17:55 -0600)]
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>
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.
Alex Elder [Wed, 19 Nov 2014 22:29:14 +0000 (16:29 -0600)]
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>
Alex Elder [Wed, 19 Nov 2014 18:27:17 +0000 (12:27 -0600)]
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>
Alex Elder [Wed, 19 Nov 2014 18:27:16 +0000 (12:27 -0600)]
greybus: use "operation_id" for certain values
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>
Alex Elder [Wed, 19 Nov 2014 18:27:14 +0000 (12:27 -0600)]
greybus: tidy up svc_in_callback() and cport_in_callback()
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>
Alex Elder [Wed, 19 Nov 2014 18:27:13 +0000 (12:27 -0600)]
greybus: explicitly mark cookies as opaque
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>
Alex Elder [Tue, 18 Nov 2014 19:26:54 +0000 (13:26 -0600)]
greybus: pass gfp_flags for message allocation
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>
Alex Elder [Tue, 18 Nov 2014 19:26:53 +0000 (13:26 -0600)]
greybus: stop storing dest_cport_id in message
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>
Alex Elder [Tue, 18 Nov 2014 19:26:52 +0000 (13:26 -0600)]
greybus: stop storing hd in message
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>
Alex Elder [Tue, 18 Nov 2014 19:26:51 +0000 (13:26 -0600)]
greybus: kill the last gbuf remnants
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>
Alex Elder [Tue, 18 Nov 2014 19:26:50 +0000 (13:26 -0600)]
greybus: rework receve handling
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>
Alex Elder [Tue, 18 Nov 2014 19:26:46 +0000 (13:26 -0600)]
greybus: send buffers without gbufs
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>
Alex Elder [Tue, 18 Nov 2014 19:26:45 +0000 (13:26 -0600)]
greybus: stash hd as context for all URBs
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>
Alex Elder [Tue, 18 Nov 2014 19:26:44 +0000 (13:26 -0600)]
greybus: cancel buffers via magic cookie
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>
Alex Elder [Tue, 18 Nov 2014 19:26:42 +0000 (13:26 -0600)]
greybus: allocate space without gbufs
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>
Alex Elder [Tue, 18 Nov 2014 19:26:41 +0000 (13:26 -0600)]
greybus: fill in destination data at send time
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>
Alex Elder [Tue, 18 Nov 2014 19:26:40 +0000 (13:26 -0600)]
greybus: improve data buffer alignment
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>
Alex Elder [Tue, 18 Nov 2014 19:26:39 +0000 (13:26 -0600)]
greybus: prepend cport byte for all gbufs
Treat communication buffers for both inbound and outbound data the
same way, prepending a "destination cport id" byte before the data
in the buffer. Currently this is done only for outbound data
buffers.
This isn't needed for inbound data, but handling it this way
allows the free routine to work without knowing whether the
buffer was used for sending or receiving.
Signed-off-by: Alex Elder <elder@linaro.org> Signed-off-by: Greg Kroah-Hartman <greg@kroah.com>
Alex Elder [Tue, 18 Nov 2014 19:26:38 +0000 (13:26 -0600)]
greybus: fix an allocation flag bug
We allocate message buffers with GFP_KERNEL allocation flags if
possible. However when an incoming request message is received we
can be in interrupt context, so we must use GFP_ATOMIC in that case.
The computation of gfp_flags in gb_operation_message_init() is
wrong. It is needlessly using GFP_ATOMIC when allocating outbound
response buffers. Fix the flawed logic.
Change the name of "data_out" to be "outbound" to be consistent with
usage elsewhere. (Data/messages are "inbound" or "outbound";
requests are "incoming" or "outgoing".)
Signed-off-by: Alex Elder <elder@linaro.org> Signed-off-by: Greg Kroah-Hartman <greg@kroah.com>
Alex Elder [Tue, 18 Nov 2014 00:08:34 +0000 (18:08 -0600)]
greybus: use null gbuf->transfer_buffer
Make sure gbuf->transfer_buffer gets reset to NULL when the buffer
is freed. We can leverage that to do a little extra error checking.
We'll also use a null transfer buffer in the next patch to indicate
an unused gbuf.
Signed-off-by: Alex Elder <elder@linaro.org> Signed-off-by: Greg Kroah-Hartman <greg@kroah.com>
Alex Elder [Tue, 18 Nov 2014 00:08:33 +0000 (18:08 -0600)]
greybus: move gbuf initialization to caller
Change greybus_alloc_gbuf() so all it does is allocate the gbuf data
structure. Move all of the initialization of the gbuf structure in
the caller. Do the inverse in the caller prior to freeing the gbuf
structure via greybus_free_gbuf(). Use a null gbuf->transfer_buffer
pointer rather than a null gbuf pointer to indicate an unused gbuf.
Signed-off-by: Alex Elder <elder@linaro.org> Signed-off-by: Greg Kroah-Hartman <greg@kroah.com>
Alex Elder [Tue, 18 Nov 2014 00:08:32 +0000 (18:08 -0600)]
greybus: start using struct gb_message
This converts some of the operation code to start leveraging the
new gb_message type. Instead of creating the request and response
gbufs, we initialize (and tear down with a new function) the
request and response message structures.
Signed-off-by: Alex Elder <elder@linaro.org> Signed-off-by: Greg Kroah-Hartman <greg@kroah.com>
Alex Elder [Tue, 18 Nov 2014 00:08:31 +0000 (18:08 -0600)]
greybus: define struct gb_message
A Greybus buffer (gbuf) is a generic buffer used for data transfer
over a Greybus interconnect. We only ever use gbufs in operations,
which always involve exactly two of them. The lifetime of a gbuf is
therefore directly connected to the lifetime of an operation, so
there no real need to manage gbufs separate from operations.
This patch begins the process of removing the gbuf abstraction, on
favor of a new data type, gb_message. The purpose of a gb_message
is--like a gbuf--to represent data to be transferred over Greybus.
However a gb_message is oriented toward the more restrictive way
we do Greybus transfers--as operation messages (either a request or
a response).
This patch simply defines the structure in its initial form, and
defines the request and response fields in a Greybus operation
structure as embedded instances of that type. The gbuf pointer
is defined within the gb_message structure, and as a result lots
of code needs to be tweaked to reference the request and response
gbufs as subfields of the request and response structures.
Signed-off-by: Alex Elder <elder@linaro.org> Signed-off-by: Greg Kroah-Hartman <greg@kroah.com>
Alex Elder [Tue, 18 Nov 2014 00:08:30 +0000 (18:08 -0600)]
greybus: move the definition of struct gbuf
We no longer need struct gbuf defined in "greybus.h". An upcoming
patch will embed a gbuf struct (not a pointer) into the operation
structure, and to do that we'll need the struct defined prior to the
operation. Just move the gbuf definition into "operation.h".
Signed-off-by: Alex Elder <elder@linaro.org> Signed-off-by: Greg Kroah-Hartman <greg@kroah.com>
Alex Elder [Tue, 18 Nov 2014 00:08:29 +0000 (18:08 -0600)]
greybus: kill gbuf->kref
Since there is only ever one reference to a gbuf, we don't need a
kref to figure out when it can be freed. Get rid of the kref and
its supporting code.
Signed-off-by: Alex Elder <elder@linaro.org> Signed-off-by: Greg Kroah-Hartman <greg@kroah.com>
Alex Elder [Tue, 18 Nov 2014 00:08:28 +0000 (18:08 -0600)]
greybus: kill greybus_{get,put}_gbuf()
These functions are never used, so we can get rid of them.
Since there's no reference-getting function any more, we no
longer need "gbuf_mutex" to avoid racing gets and puts, so
get rid of that too.
Signed-off-by: Alex Elder <elder@linaro.org> Signed-off-by: Greg Kroah-Hartman <greg@kroah.com>
This driver implements the Greybus vibrator protocol, as defined in the
Greybus protocol specification. It interacts to userspace with a single
sysfs file, "timeout", and a separate "class" called "vibrator". That
interface can/should be changed in the future depending on what Android
wants for its HAL, but for now should be good enough to test with.
There are some changes needed to kernel_ver.h to support some
sysfs/driver core changes that happened after the 3.10 kernel was
released to try to make the code simpler. Even with those changes,
there are #ifdefs in the code to do different things depending on the
kernel version to implement the same userspace api.
greybus: greybus_manifest.h: update with full list of protocols
The protocol values had gotten out of sync with the Greybus Protocol
specification document, so bring them back into sync by changing a few
values, and adding the missing values.
Alex Elder [Mon, 17 Nov 2014 14:08:45 +0000 (08:08 -0600)]
greybus: get rid of cport_id_map_lock
The only time we get a cport id is when setting up a new connection.
We already have a (coarser-grained) spin lock that's used to protect
the connection lists, and we can use that same lock for protecting
the hd's connection id map.
Signed-off-by: Alex Elder <elder@linaro.org> Signed-off-by: Greg Kroah-Hartman <greg@kroah.com>
Alex Elder [Mon, 17 Nov 2014 14:08:44 +0000 (08:08 -0600)]
greybus: use a simple list of hd connections
First of all, there's a bug in _gb_hd_connection_insert, which
Viresh found. But pointing out that problem just called attention
to the fact that I have planning to to remove the affected block of
code.
The set of connections associated with a host device is currently
maintained in a red-black tree. The number of connections we're
likely to have is on the order of a hundred, and at least for now
isn't even going to approach that. When this code first went in,
Greg asserted that using a list is speedier than a red-black tree
for smallish numbers of elements (maybe up to a few hundred?).
So this patch just removes the host device's red-black tree of
connections, using a simple list instead.
Signed-off-by: Alex Elder <elder@linaro.org> Signed-off-by: Greg Kroah-Hartman <greg@kroah.com>
projects / karo-tx-linux.git / log