1. 04 Oct, 2014 6 commits
  2. 03 Oct, 2014 20 commits
    • Matt Porter's avatar
      greybus: implement core module removal path · d7f9be48
      Matt Porter authored
      Implement gb_remove_module() by finding the gb_module to
      be removed via the supplied module_id. Add support for
      removing the actual device into greybus_remove_device()
      after all the subdevs are disconnected.
      Signed-off-by: default avatarMatt Porter <mporter@linaro.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <greg@kroah.com>
      d7f9be48
    • Matt Porter's avatar
      greybus: fix gb_add_module() by enabling the device_add() · 32dff13d
      Matt Porter authored
      Without the gb_module device being added, we have no parent
      device for any of the greybus subdevs to be added. Do the
      device_add() before creating subdevs as we need it then
      to register any children in the various greybus protocol
      drivers.
      Signed-off-by: default avatarMatt Porter <mporter@linaro.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <greg@kroah.com>
      32dff13d
    • Greg Kroah-Hartman's avatar
    • Greg Kroah-Hartman's avatar
    • Alex Elder's avatar
      greybus: record connection protocol · ad1c449e
      Alex Elder authored
      Record the protocol association with a connection when it gets
      created.
      Signed-off-by: default avatarAlex Elder <elder@linaro.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <greg@kroah.com>
      ad1c449e
    • Alex Elder's avatar
      greybus: get rid of functions now... · cd345074
      Alex Elder authored
      We decided yesterday that we would no longer support the notion of a
      "function."  Instead, a connection will simply exist between the AP
      and an interface on a module (and a CPort Id on each end).  What
      was previously considered the "function type" will now be handled
      as the "protocol" associated with the connection.
      
      Update gb_connection_create() to take just the interface and a cport
      id associated with that interface.
      
      Right now every module points back to a host device, so for now
      we'll establish the connection back to that.
      Signed-off-by: default avatarAlex Elder <elder@linaro.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <greg@kroah.com>
      cd345074
    • Alex Elder's avatar
      greybus: allocate connection host cport id · 9e8a6860
      Alex Elder authored
      Allocate a cport id from the host device whenever creating a
      connection.
      Signed-off-by: default avatarAlex Elder <elder@linaro.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <greg@kroah.com>
      9e8a6860
    • Alex Elder's avatar
      greybus: create host device cport id map · 1bb3c724
      Alex Elder authored
      A Greybus host device has a pool of CPort Ids it can use.  When we
      establish a connection with a CPort on another module we will need
      to allocate one from those that are available.
      
      This patch adds a bitmap to the greybus host device structure that
      allows cport ids to be allocated and freed as needed.
      Signed-off-by: default avatarAlex Elder <elder@linaro.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <greg@kroah.com>
      1bb3c724
    • Alex Elder's avatar
      greybus: October 1 updates · 63cc932b
      Alex Elder authored
      Update the definitions in "greybus_manifest.h" to reflect the
      changes to the Greybus specification made on October 1.
      
      They are:
          - renaming "device" to be "interface"
          - renumbering greybus descriptor type
          - eliminating the notion of a "function"
          - defining a CPort's protocol in the CPort descriptor
          - having a "class" take on the types previously used for "function"
          - renaming "serial number" to be "unique id" (for now)
          - relying on an interface's maximum cport id to determine how
            much device+cport address space the interface consumes
          - adding a simple class descriptor
          - renaming gb_interface->interface_id to be gb_interface->id
      
      This also reorders some things to match ordering in the document,
      and adds some commentary for the various structures.
      
      Since greybus_function_type is gone, we eliminate the "type" field
      from a function structure.  (Functions are going away, next.)
      Signed-off-by: default avatarAlex Elder <elder@linaro.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <greg@kroah.com>
      63cc932b
    • Alex Elder's avatar
      greybus: fix connection header declarations · b05890db
      Alex Elder authored
      Changes to the create/destroy connection functions were not properly
      reflected in the header file.  Fix that.  There's also no need to
      include anything other than "greybus.h".
      Signed-off-by: default avatarAlex Elder <elder@linaro.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <greg@kroah.com>
      b05890db
    • Alex Elder's avatar
      greybus: kill off old manifest code · 459164b1
      Alex Elder authored
      Now that the new manifest code is in place, delete the old stuff
      from "core.c".
      Signed-off-by: default avatarAlex Elder <elder@linaro.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <greg@kroah.com>
      459164b1
    • Alex Elder's avatar
      greybus: manifest cport descriptor parsing · c095bbcf
      Alex Elder authored
      Add support for parsing one or more cports descriptors in a module
      manifest.  There must be at least one for each interface, but we impose
      no limit on the number of interfaces associated with a module.
      Signed-off-by: default avatarAlex Elder <elder@linaro.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <greg@kroah.com>
      c095bbcf
    • Alex Elder's avatar
      greybus: manifest interface descriptor parsing · d88bfb5b
      Alex Elder authored
      Add support for parsing one or more interface descriptors in a module
      manifest.  There must be at least one, but we impose no limit on the
      number of interfaces associated with a module.
      Signed-off-by: default avatarAlex Elder <elder@linaro.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <greg@kroah.com>
      d88bfb5b
    • Alex Elder's avatar
      greybus: start improving manifest parsing · b09c94a1
      Alex Elder authored
      Currently the module manifest parsing code is sort of representative
      only and is not really very useful.
      
      This patch begins doing "real" parsing of the module manifest.
      It scans the module manifest to identify the descriptors it holds.
      It then verifies there's only one module descriptor found, and
      initializes new some fields in the gb_module structure based on what
      it contains (converting what's found to native byte order).
      Note that if anything unexpected is found or other errors occur when
      parsing the manifest, the parse fails.
      
      Because we now save this converted information when it's parsed we
      no longer have a greybus_descriptor_module struct within a struct
      gb_module.  And because we've already converted these values, we can
      do a little less work displaying values in sysfs.  (We also now show
      vendor, product, and version values in the right byte order.)  This
      eliminates the need for greybus_string(), so get rid of it.
      
      It also slightly simplifies the greybus module matching code.
      
      Move some existing parsing code into a new file, "manifest.c".
      Signed-off-by: default avatarAlex Elder <elder@linaro.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <greg@kroah.com>
      b09c94a1
    • Alex Elder's avatar
      greybus: introduce an operation abstraction · e88afa58
      Alex Elder authored
      This patch defines a new "operation" abstraction.  An operation is a
      request from by one end of a connection to the function (or AP) on
      the other, coupled with a matching response returned to the requestor.
      The request indicates some action to be performed by the target of
      the request (such as "read some data").  Once the action has
      completed the target sends back an operation response message.
      Additional data can be supplied by the sender with its request,
      and/or by the target with its resposne message.
      
      Each request message has a unique id, generated by the sender.
      The sender recognizes the matching response by the presence
      of this id value.  Each end of a connection is responsible
      for creating unique ids for the requests it sends.
      
      An operation also has a type, whose interpretation is dependent on
      the function type on the end of the connection opposite the sender.
      It is up to the creator of an operation to fill in the data (if any)
      to be sent with the request.
      
      Note that not all requests are initiated by the AP.  Incoming data
      on a module function can result in a request message being sent from
      that function to the AP to notify of the data's arrival.  Once the
      AP has processed this, it sends a response to the sender.
      
      Every operation response contains a status byte.  If it's value
      is 0, the operation was successful.  Any other value indicates
      an error.
      
      Add a defintion of U16_MAX to "kernel_ver.h".
      Signed-off-by: default avatarAlex Elder <elder@linaro.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <greg@kroah.com>
      e88afa58
    • Alex Elder's avatar
      greybus: introduce a connection abstraction · c68adb2f
      Alex Elder authored
      Within a UniPro network a pair of CPorts can be linked to form a
      UniPro Connection.  This patch creates a new abstraction to
      represent an AP CPort that is connected with a CPort used by a
      function within a Greybus module.
      Signed-off-by: default avatarAlex Elder <elder@linaro.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <greg@kroah.com>
      c68adb2f
    • Alex Elder's avatar
      greybus: define greybus function abstraction · ef0d2ba2
      Alex Elder authored
      Define new source files "function.h" and "function.c" to contain the
      definitions of the Greybus function abstraction.  A Greybus function
      represents an active entity connected to a CPort implemented by a
      Greybus interface.  A Greybus function has a type, which defines the
      protocol to be used to interact with the function.  A Greybus
      interface normally has at least two functions, but potentially many
      more.
      Signed-off-by: default avatarAlex Elder <elder@linaro.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <greg@kroah.com>
      ef0d2ba2
    • Alex Elder's avatar
      greybus: define greybus interface abstraction · 8c12cde3
      Alex Elder authored
      Define new source files "interface.h" and "interface.c" to contain
      the definitions of the Greybus interface abstraction.  A Greybus
      interface represents a UniPro device present in a UniPro module.
      For Project Ara, each interface block on a module implements a
      UniPro interface.
      Signed-off-by: default avatarAlex Elder <elder@linaro.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <greg@kroah.com>
      8c12cde3
    • Alex Elder's avatar
      greybus: isolate greybus module code · e1e9dbdd
      Alex Elder authored
      Define new source files "module.h" and "module.c" to separate the
      definitions of the Greybus module abstraction from other code.
      
      Rename "greybus_module" to be "gb_module", for brevity.  Do the same
      for a few other symbols with "greybus_module" in their names.  A few
      (like greybus_module_id) are more visible outside this kernel module
      so we'll keep their names more descriptive.
      
      Add a definition for U8_MAX in "kernel_ver.h" (it appeared in 3.14).
      Signed-off-by: default avatarAlex Elder <elder@linaro.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <greg@kroah.com>
      e1e9dbdd
    • Alex Elder's avatar
      greybus: descriptor type updates · ecf7d579
      Alex Elder authored
      Some more updates to the definition of a manifest descriptor.
          - We get rid of function descriptors.  The type of function is
            easily specified with the CPort it uses.
          - Add a new interface descriptor type.
          - Clean up the CPort descriptor structure, eliminating fields
            that serve no purpose and adding the function id field
      
      The sysfs stuff will be updated a little later to add entries
      for the Greybus interfaces associated with modules.
      
      Rearrange the order of a few things in "greybus_manifest.h".
      Signed-off-by: default avatarAlex Elder <elder@linaro.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <greg@kroah.com>
      ecf7d579
  3. 01 Oct, 2014 5 commits
  4. 30 Sep, 2014 9 commits