greybus: descriptor type updates

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: Alex Elder <elder@linaro.org>
Signed-off-by: Greg Kroah-Hartman <greg@kroah.com>
greybus: isolate greybus module code

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: Alex Elder <elder@linaro.org>
Signed-off-by: Greg Kroah-Hartman <greg@kroah.com>
greybus: define greybus interface abstraction

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: Alex Elder <elder@linaro.org>
Signed-off-by: Greg Kroah-Hartman <greg@kroah.com>
greybus: define greybus function abstraction

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: Alex Elder <elder@linaro.org>
Signed-off-by: Greg Kroah-Hartman <greg@kroah.com>
greybus: introduce a connection abstraction

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: Alex Elder <elder@linaro.org>
Signed-off-by: Greg Kroah-Hartman <greg@kroah.com>
greybus: introduce an operation abstraction

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: Alex Elder <elder@linaro.org>
Signed-off-by: Greg Kroah-Hartman <greg@kroah.com>
greybus: start improving manifest parsing

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: Alex Elder <elder@linaro.org>
Signed-off-by: Greg Kroah-Hartman <greg@kroah.com>
greybus: manifest interface descriptor parsing

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: Alex Elder <elder@linaro.org>
Signed-off-by: Greg Kroah-Hartman <greg@kroah.com>