1. 15 Jun, 2015 5 commits
    • Alex Elder's avatar
      greybus: esX: use one byte to encode cport ids in header · 4bc1389d
      Alex Elder authored
      We now limit the maximum value for both host and module CPort ids,
      and we know they can always be represented in a single byte.
      
      Make use of this by using only one of the two pad bytes for encoding
      the CPort id in a message header.
      
      (Note that we have never used a CPort higher than 255.  Encoding
      such a small CPort id in little endian 2-byte format has the same
      result as what is done here.)
      Signed-off-by: default avatarAlex Elder <elder@linaro.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@google.com>
      4bc1389d
    • Alex Elder's avatar
      greybus: reserve host cport id 0 · 88d18a97
      Alex Elder authored
      For ES1 and ES2, we use pad bytes in an operation message header to
      encode the CPort ID used for transferring the message.  The pad
      bytes should otherwise be zero, and we ensure this as the message
      is passed to or from the upper layer.
      
      If host-side CPort ID 0 is used, we have no way of knowing whether
      the CPort field has been "packed" into the header.
      
      To allow detection of this, reserve host CPort id 0.  Update
      cport_id_valid() to treat 0 as invalid.
      
      (CPort ID 0 is reserved by one of the UniPro standards.  We'll
      assume for now that we never use it for Greybus.)
      Signed-off-by: default avatarAlex Elder <elder@linaro.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@google.com>
      88d18a97
    • Alex Elder's avatar
      greybus: rename HOST_DEV_CPORT_ID_MAX · fb690ca9
      Alex Elder authored
      We limit the number of host-side CPorts to a fixed maximum (which
      is less than the 4096 that UniPro allows).  This patch imposes a
      similar limit on the CPort IDs defined by modules (signaling an
      error if one too large is found in a manifest).
      
      It seems reasonable to use the same value for both limits.  Change
      the name of the constant that defines the host limit and use it for
      both.  Update cport_id_valid() to enforce the maximum.
      
      (Ultimately we should impose a limit like this; this change is being
      made in preparation for supporting multiple connections over a
      single CPort.)
      Signed-off-by: default avatarAlex Elder <elder@linaro.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@google.com>
      fb690ca9
    • Alex Elder's avatar
      greybus: esX: encapsulate packing cport id into header · d29b3d63
      Alex Elder authored
      For the ES1 and ES2 host interfaces we encode the CPort ID over
      which the message should be sent within the message itself.  The
      CPort ID is recorded in unused pad bytes found in the operation
      message header in order to avoid introducing misaligned messages.
      
      This patch defines some helper routines to abstract this activity.
      Signed-off-by: default avatarAlex Elder <elder@linaro.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@google.com>
      d29b3d63
    • Alex Elder's avatar
      greybus: introduce cport_id_valid() · 821c620a
      Alex Elder authored
      Define a public predicate that defines whether a CPort ID is valid.
      
      Use it in the message_send() routine, and make the message reported
      more accurately reflect the error.  Also use it to check whether the
      CPort ID in a received message is valid; if it is not, just drop the
      message.
      
      Get rid of local variable "buffer" in message_send(); it adds no
      value.
      Signed-off-by: default avatarAlex Elder <elder@linaro.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@google.com>
      821c620a
  2. 12 Jun, 2015 7 commits
  3. 11 Jun, 2015 3 commits
  4. 10 Jun, 2015 12 commits
  5. 09 Jun, 2015 3 commits
  6. 08 Jun, 2015 7 commits
  7. 04 Jun, 2015 3 commits