1. 02 Dec, 2014 17 commits
    • Alex Elder's avatar
      greybus: set result in gb_operation_response_send() · d2d2c0fe
      Alex Elder authored
      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: default avatarAlex Elder <elder@linaro.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <greg@kroah.com>
      d2d2c0fe
    • Alex Elder's avatar
      greybus: create a slab cache for simple messages · 0cffcac3
      Alex Elder authored
      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: default avatarAlex Elder <elder@linaro.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <greg@kroah.com>
      0cffcac3
    • Alex Elder's avatar
      greybus: enforce a buffer headroom maximum size · 835fb5e4
      Alex Elder authored
      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: default avatarAlex Elder <elder@linaro.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <greg@kroah.com>
      835fb5e4
    • Alex Elder's avatar
      greybus: introduce gb_operation_message_init() · dc779229
      Alex Elder authored
      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: default avatarAlex Elder <elder@linaro.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <greg@kroah.com>
      dc779229
    • Alex Elder's avatar
      greybus: use operation type 0 to signal incoming data · ea64cd9a
      Alex Elder authored
      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: default avatarAlex Elder <elder@linaro.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <greg@kroah.com>
      ea64cd9a
    • Alex Elder's avatar
      greybus: enforce non-zero operation type requirement · 55f66a88
      Alex Elder authored
      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: default avatarAlex Elder <elder@linaro.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <greg@kroah.com>
      55f66a88
    • Alex Elder's avatar
      greybus: pass result in gb_connection_recv_response() · 64ce39a3
      Alex Elder authored
      Pass the operation result to gb_connection_recv_response() as a
      parameter.
      Signed-off-by: default avatarAlex Elder <elder@linaro.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <greg@kroah.com>
      64ce39a3
    • Alex Elder's avatar
      greybus: short message is OK for errors · f71e1cc1
      Alex Elder authored
      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: default avatarAlex Elder <elder@linaro.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <greg@kroah.com>
      f71e1cc1
    • Alex Elder's avatar
      greybus: move copy of incoming request data · 34db1f91
      Alex Elder authored
      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: default avatarAlex Elder <elder@linaro.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <greg@kroah.com>
      34db1f91
    • Greg Kroah-Hartman's avatar
      greybus: operation: fix up sparse warning · 85a04428
      Greg Kroah-Hartman authored
      gb_connection_recv_request should be static, so mark it as such.
      Signed-off-by: default avatarGreg Kroah-Hartman <greg@kroah.com>
      85a04428
    • Alex Elder's avatar
      greybus: always drop reference in gb_operation_work() · e5fbc073
      Alex Elder authored
      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: default avatarAlex Elder <elder@linaro.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <greg@kroah.com>
      e5fbc073
    • Alex Elder's avatar
      greybus: drop gfp_mask from gb_message_send() · e413614b
      Alex Elder authored
      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: default avatarAlex Elder <elder@linaro.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <greg@kroah.com>
      e413614b
    • Alex Elder's avatar
      greybus: renumber operation result values · 57248fac
      Alex Elder authored
      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: default avatarAlex Elder <elder@linaro.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <greg@kroah.com>
      57248fac
    • Alex Elder's avatar
      greybus: define -EILSEQ to mean implementation error · 2fb2d2a7
      Alex Elder authored
      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: default avatarAlex Elder <elder@linaro.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <greg@kroah.com>
      2fb2d2a7
    • Alex Elder's avatar
      greybus: enforce max representable message size · ab3cf8dc
      Alex Elder authored
      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: default avatarAlex Elder <elder@linaro.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <greg@kroah.com>
      ab3cf8dc
    • Alex Elder's avatar
      greybus: use outgoing flag when creating operation · 94b15d76
      Alex Elder authored
      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: default avatarAlex Elder <elder@linaro.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <greg@kroah.com>
      94b15d76
    • Greg Kroah-Hartman's avatar
      greybus: usb-gb: import a "buildable" version of the usb-gb.c driver · 615772aa
      Greg Kroah-Hartman authored
      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: default avatarGreg Kroah-Hartman <greg@kroah.com>
      615772aa
  2. 25 Nov, 2014 9 commits
    • Alex Elder's avatar
      greybus: protect cookie with a mutex · 43cdae5c
      Alex Elder authored
      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: default avatarAlex Elder <elder@linaro.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <greg@kroah.com>
      43cdae5c
    • Alex Elder's avatar
      greybus: ignore a null cookie when canceling buffer · f34541d7
      Alex Elder authored
      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: default avatarAlex Elder <elder@linaro.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <greg@kroah.com>
      f34541d7
    • Alex Elder's avatar
      greybus: update operation result atomically · 894cbc31
      Alex Elder authored
      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: default avatarAlex Elder <elder@linaro.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <greg@kroah.com>
      894cbc31
    • Alex Elder's avatar
      greybus: enforce receive buffer size · aa3a4d12
      Alex Elder authored
      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: default avatarAlex Elder <elder@linaro.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <greg@kroah.com>
      aa3a4d12
    • Alex Elder's avatar
      greybus: fix some error codes · 1a365154
      Alex Elder authored
      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: default avatarAlex Elder <elder@linaro.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <greg@kroah.com>
      1a365154
    • Alex Elder's avatar
      greybus: use special operation result valus · 3deb37d4
      Alex Elder authored
      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: default avatarAlex Elder <elder@linaro.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <greg@kroah.com>
      3deb37d4
    • Alex Elder's avatar
      greybus: first operation error prevails · abe9a300
      Alex Elder authored
      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: default avatarAlex Elder <elder@linaro.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <greg@kroah.com>
      abe9a300
    • Alex Elder's avatar
      greybus: encapsulate operation result access · ba986b5a
      Alex Elder authored
      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: default avatarAlex Elder <elder@linaro.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <greg@kroah.com>
      ba986b5a
    • Greg Kroah-Hartman's avatar
      greybus: uart-gb: clean up send_line_coding · 9f240f20
      Greg Kroah-Hartman authored
      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: default avatarGreg Kroah-Hartman <greg@kroah.com>
      9f240f20
  3. 24 Nov, 2014 8 commits
  4. 22 Nov, 2014 6 commits
    • Alex Elder's avatar
      greybus: rework synchronous operation completion · 10c69399
      Alex Elder authored
      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: default avatarAlex Elder <elder@linaro.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <greg@kroah.com>
      10c69399
    • Alex Elder's avatar
      greybus: kill gb_operation_wait() · 2cf72a23
      Alex Elder authored
      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: default avatarAlex Elder <elder@linaro.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <greg@kroah.com>
      2cf72a23
    • Alex Elder's avatar
      greybus: cancel whole operation on interrupt · 7035833f
      Alex Elder authored
      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: default avatarAlex Elder <elder@linaro.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <greg@kroah.com>
      7035833f
    • Alex Elder's avatar
      greybus: cancel operation on timeout · f68c05c0
      Alex Elder authored
      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: default avatarAlex Elder <elder@linaro.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <greg@kroah.com>
      f68c05c0
    • Alex Elder's avatar
      greybus: minor tweak in gb_connection_recv_response() · 0e3d0e8f
      Alex Elder authored
      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: default avatarAlex Elder <elder@linaro.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <greg@kroah.com>
      0e3d0e8f
    • Alex Elder's avatar
      greybus: add a reference to pending operations · deb4b9ef
      Alex Elder authored
      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: default avatarAlex Elder <elder@linaro.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <greg@kroah.com>
      deb4b9ef