1. 12 Dec, 2014 9 commits
  2. 10 Dec, 2014 2 commits
  3. 09 Dec, 2014 1 commit
  4. 08 Dec, 2014 1 commit
  5. 03 Dec, 2014 10 commits
    • Alex Elder's avatar
      greybus: record type in operation structure · 82b5e3fe
      Alex Elder authored
      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: default avatarAlex Elder <elder@linaro.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <greg@kroah.com>
      82b5e3fe
    • Alex Elder's avatar
      greybus: use null pointer for empty payload · 746e0ef9
      Alex Elder authored
      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: default avatarAlex Elder <elder@linaro.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <greg@kroah.com>
      746e0ef9
    • Alex Elder's avatar
      greybus: only record message payload size · 7cfa6995
      Alex Elder authored
      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: default avatarAlex Elder <elder@linaro.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <greg@kroah.com>
      7cfa6995
    • Alex Elder's avatar
      greybus: don't let i2c code assume non-null payload pointer · 7a9366aa
      Alex Elder authored
      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: default avatarAlex Elder <elder@linaro.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <greg@kroah.com>
      7a9366aa
    • Alex Elder's avatar
      greybus: set up connection->private properly · 93bbe859
      Alex Elder authored
      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: default avatarAlex Elder <elder@linaro.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <greg@kroah.com>
      93bbe859
    • Alex Elder's avatar
      greybus: fix an error message · 62749a05
      Alex Elder authored
      The error message printed by gb_operation_sync() if the operation
      fails is wrong.  Fix it.
      Signed-off-by: default avatarAlex Elder <elder@linaro.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <greg@kroah.com>
      62749a05
    • Alex Elder's avatar
      greybus: introduce gb_operation_request_send_sync() · c25572ca
      Alex Elder authored
      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: default avatarAlex Elder <elder@linaro.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <greg@kroah.com>
      c25572ca
    • Alex Elder's avatar
      greybus: make op_cycle atomic (again) · 4afb7fd0
      Alex Elder authored
      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: default avatarAlex Elder <elder@linaro.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <greg@kroah.com>
      4afb7fd0
    • Alex Elder's avatar
      greybus: get rid of pending operations list · afb2e134
      Alex Elder authored
      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: default avatarAlex Elder <elder@linaro.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <greg@kroah.com>
      afb2e134
    • Alex Elder's avatar
      greybus: don't use 0 as an operation id · 0ba02c4d
      Alex Elder authored
      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: default avatarAlex Elder <elder@linaro.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <greg@kroah.com>
      0ba02c4d
  6. 02 Dec, 2014 17 commits