On a disconnect we can also have a status of -EPROTO. This results in
a flood of error messages due to the -EAGAIN handling of unsupported
status results. Fix this by also returning status when we have -EPROTO.
Signed-off-by: Matt Porter <mporter@linaro.org>
Signed-off-by: Greg Kroah-Hartman <greg@kroah.com>
In order to easily integrate into the Android build, include
an Android.mk.
Signed-off-by: John Stultz <john.stultz@linaro.org>
Signed-off-by: Greg Kroah-Hartman <greg@kroah.com>
We didn't use them, so drop it.
Also some other checkpatch cleanups while I was in there.
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
We had a lock, but we never used it, so move it to be per-hd, like the
idr structure is.
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Even if we successfully parse a manifest we are returning
failure. Instead, we now proudly proclaim success.
Signed-off-by: Matt Porter <mporter@linaro.org>
Signed-off-by: Greg Kroah-Hartman <greg@kroah.com>
Without this, null-testing the return value of this function is
broken.
Signed-off-by: Marti Bolivar <mbolivar@leaflabs.com>
Reviewed-by: Alex Elder <elder@linaro.org>
Signed-off-by: Greg Kroah-Hartman <greg@kroah.com>
The internal struct manifest_desc needs the data payload, rather
than the entire descriptor with header to be populated into the
data field. Also fix two places where the parser was trying to
extract the entire descriptor with header for the data payload
field.
Signed-off-by: Matt Porter <mporter@linaro.org>
Signed-off-by: Greg Kroah-Hartman <greg@kroah.com>
Last time I tried to kill off gbuf->context my efforts were shot
down. Now that I've got the connection infrastructure in place,
maybe I'll have more luck getting rid of gbuf->hdpriv.
The only place it's used is to stash the es1_ap_dev structure
pointer in the buffer. But that information is now available
through the buffer's connection, so we don't need to use the
hdpriv field any more.
So get rid of it, and use hd_to_es1(gbuf->connection->hd) to
get at what we need.
Signed-off-by: Alex Elder <elder@linaro.org>
Signed-off-by: Greg Kroah-Hartman <greg@kroah.com>
GEt rid of __alloc_gbuf(), now that it's used in only one place.
Signed-off-by: Alex Elder <elder@linaro.org>
Signed-off-by: Greg Kroah-Hartman <greg@kroah.com>
Change the "direction" flag field of a gbuf to be a Boolean called
"outbound".
Add a Boolean outbound flag to alloc_gbuf_data(), and use it for
allocating the data buffer for gbufs for data being transferred in
either direction.
Update free_gbuf_data() accordingly--letting the host device
driver's gbuf data free function handle all of them.
Signed-off-by: Alex Elder <elder@linaro.org>
Signed-off-by: Greg Kroah-Hartman <greg@kroah.com>
Switch to using the connection rather than the host device as
the locus for doing Greybus buffer allocation. A connection
encapsulates both the host device (whose driver is what's required
for allocation) and the *destination* cport id. Record the
connection a gbuf is associated with rather than the host module and
(unspecified) cport id.
Signed-off-by: Alex Elder <elder@linaro.org>
Signed-off-by: Greg Kroah-Hartman <greg@kroah.com>
Look up the connection that an incoming message is associated with.
This is the start of making message handling oriented toward the
the connection rather than the cport.
Signed-off-by: Alex Elder <elder@linaro.org>
Signed-off-by: Greg Kroah-Hartman <greg@kroah.com>
Add a function that looks up a connection given the host device
pointer an the host cport id. This will be used to determine which
connection an incoming message is associated with.
Replace the list tracking host device connections with a red-black
tree so lookup can scale and be done quickly.
Signed-off-by: Alex Elder <elder@linaro.org>
Signed-off-by: Greg Kroah-Hartman <greg@kroah.com>
One data structure and a few fields in another one are no longer
used, and were not removed when they should have been.
Signed-off-by: Alex Elder <elder@linaro.org>
Signed-off-by: Greg Kroah-Hartman <greg@kroah.com>
Define a function that prints error information about a Greybus
connection in a standard format. This adopts the convention that
[M:I:C] represents the "path" the connection represents--specifying
the module id, the interface number on that module, and the
connection id on that interface.
Signed-off-by: Alex Elder <elder@linaro.org>
Signed-off-by: Greg Kroah-Hartman <greg@kroah.com>
This will be used for driver-specific data for whatever drives the
other end of the connection.
Signed-off-by: Alex Elder <elder@linaro.org>
Signed-off-by: Greg Kroah-Hartman <greg@kroah.com>
The type of an operation belongs in the operation header, which
shouldn't be touched by users of the interface. So specify it
at operation creation time.
Signed-off-by: Alex Elder <elder@linaro.org>
Signed-off-by: Greg Kroah-Hartman <greg@kroah.com>
A Greybus buffer has both a transfer_buffer_size field, which is the
size in bytes of the transfer buffer, and an actual_length field,
which is the number of bytes in that buffer that are actually
consumed. The user of the buffer--and not the buffer allocation
method--should be setting the actual_length field.
Stop setting the actual length on the es1-ap-usb alloc_gbuf_data
method. And *do* set it in gb_operation_create(), where we can
presume the operation being allocated will consume all the bytes
requested.
Signed-off-by: Alex Elder <elder@linaro.org>
Signed-off-by: Greg Kroah-Hartman <greg@kroah.com>
The code that was setting up a module was not properly initializing
the module data structure. Fixing this required a little rework.
Now gb_add_module() (which the host device pointer and module id)
allocates and initializes the structure, and passes it to
gb_manifest_parse() for populating it further.
Signed-off-by: Alex Elder <elder@linaro.org>
Signed-off-by: Greg Kroah-Hartman <greg@kroah.com>
The ida mechanism for allocating ids may be overkill but it works.
Don't preallocate the id 0 for control. That should be done
when initializing connections based on the manifest anyway.
Signed-off-by: Alex Elder <elder@linaro.org>
Signed-off-by: Greg Kroah-Hartman <greg@kroah.com>
These were inadvertently not fixed when the type name was changed.
Signed-off-by: Alex Elder <elder@linaro.org>
Signed-off-by: Greg Kroah-Hartman <greg@kroah.com>
Fix some omissions found in the code.
- initialize and use the host device connections list
- rename the interface connections list (was "functions")
- use the interface connections list
- define a spinlock protecting the connections lists
- declare gb_operation_submit() in "operation.h"
And the cport id map lock is per-host device, it's shared across all
host devices. There's no need for one in struct greybus_host_device.
Signed-off-by: Alex Elder <elder@linaro.org>
Signed-off-by: Greg Kroah-Hartman <greg@kroah.com>
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: Matt Porter <mporter@linaro.org>
Signed-off-by: Greg Kroah-Hartman <greg@kroah.com>
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: Matt Porter <mporter@linaro.org>
Signed-off-by: Greg Kroah-Hartman <greg@kroah.com>
Record the protocol association with a connection when it gets
created.
Signed-off-by: Alex Elder <elder@linaro.org>
Signed-off-by: Greg Kroah-Hartman <greg@kroah.com>
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: Alex Elder <elder@linaro.org>
Signed-off-by: Greg Kroah-Hartman <greg@kroah.com>
Allocate a cport id from the host device whenever creating a
connection.
Signed-off-by: Alex Elder <elder@linaro.org>
Signed-off-by: Greg Kroah-Hartman <greg@kroah.com>
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: Alex Elder <elder@linaro.org>
Signed-off-by: Greg Kroah-Hartman <greg@kroah.com>
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: Alex Elder <elder@linaro.org>
Signed-off-by: Greg Kroah-Hartman <greg@kroah.com>
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: Alex Elder <elder@linaro.org>
Signed-off-by: Greg Kroah-Hartman <greg@kroah.com>
Now that the new manifest code is in place, delete the old stuff
from "core.c".
Signed-off-by: Alex Elder <elder@linaro.org>
Signed-off-by: Greg Kroah-Hartman <greg@kroah.com>
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: Alex Elder <elder@linaro.org>
Signed-off-by: Greg Kroah-Hartman <greg@kroah.com>
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>
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>
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>
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>
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>
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>
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>
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>
Fix a simple cut and paste error that was reporting a serial
number header size error rather than a cport descriptor size
error.
Signed-off-by: Matt Porter <mporter@linaro.org>
Signed-off-by: Greg Kroah-Hartman <greg@kroah.com>
The Greybus spec was updated to remove some unused fields from the
CPort descriptor definition. Remove them from the structure so
we don't fail manifest parsing.
Signed-off-by: Matt Porter <mporter@linaro.org>
Signed-off-by: Greg Kroah-Hartman <greg@kroah.com>
The Project ARA MDK states that a single module can have more than
one interface block (up to 2 at the moment). An interface block
consists of two bidirectional UniPro lanes (along with power and
detect lines), and effectively represents a UniPro Device (with
an id in the range 0-127).
The service messages currently use "module_id" everywhere, even
though in a lot of cases we really need to be talking about device
ids. The easiest case of this to see is the "set route" request
directed at a switch; a switch has no notion of modules, just
UniPro devices.
Signed-off-by: Alex Elder <elder@linaro.org>
Signed-off-by: Greg Kroah-Hartman <greg@kroah.com>
