1. 21 Nov, 2014 6 commits
    • Alex Elder's avatar
      greybus: dynamically allocate requests and responses · c08b1dda
      Alex Elder authored
      Have an operation's request and response messages be dynamically
      allocated rather than embedded in an operation.
      Signed-off-by: default avatarAlex Elder <elder@linaro.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <greg@kroah.com>
      c08b1dda
    • Alex Elder's avatar
      greybus: rename message buffer fields · 0a4e14a8
      Alex Elder authored
      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: default avatarAlex Elder <elder@linaro.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <greg@kroah.com>
      0a4e14a8
    • Alex Elder's avatar
      greybus: have greybus allocate its own buffers · 8b337308
      Alex Elder authored
      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: default avatarAlex Elder <elder@linaro.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <greg@kroah.com>
      8b337308
    • Alex Elder's avatar
      greybus: complete overflow responses · 8d55f4c6
      Alex Elder authored
      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: default avatarAlex Elder <elder@linaro.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <greg@kroah.com>
      8d55f4c6
    • Alex Elder's avatar
      greybus: fix a timeout race · e8b48d15
      Alex Elder authored
      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: default avatarAlex Elder <elder@linaro.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <greg@kroah.com>
      e8b48d15
    • Alex Elder's avatar
      greybus: drop a now-empty structure · 5e689957
      Alex Elder authored
      One structure, gb_gpio_activate_response, was not deleted even
      though it now has no contents.  Delete it.
      Signed-off-by: default avatarAlex Elder <elder@linaro.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <greg@kroah.com>
      5e689957
  2. 20 Nov, 2014 12 commits
  3. 19 Nov, 2014 11 commits
  4. 18 Nov, 2014 11 commits