CPort connections are being handled in the application layer connection
protocol and the layer 3 switch doesn't care about them. Also, the
switch doesn't care about a source device id when setting up the route
table. Reduce the message to just the necessary destination device ID.

As the SVC is aware of which switch port it found the module/interface
and assigned the device ID, we can simply tell the SVC to set a route
to the device ID it has reported to the AP as being active.
Signed-off-by: Matt Porter <mporter@linaro.org>
Signed-off-by: Greg Kroah-Hartman <greg@kroah.com>

The link up message is the event that tells the AP what device ID
has been assigned to a particular interface on a module during
enumeration. The link up is sent *only* after the hotplug event
for a particular module has been sent to the AP.

The link up payload must carry the Module ID and Interface ID
to uniquely identify the struct gb_interface to which the
Device ID has been assigned.

After processing of the link up message, the interface's device_id
field will contain the assigned Device ID so that the AP has the
information necessary to issue network route commands.
Signed-off-by: Matt Porter <mporter@linaro.org>
Signed-off-by: Greg Kroah-Hartman <greg@kroah.com>

Add support for getting a struct gb_interface from an
Interface ID.
Signed-off-by: Matt Porter <mporter@linaro.org>
Signed-off-by: Greg Kroah-Hartman <greg@kroah.com>

Add support for getting a struct gb_module from a
Module ID.
Signed-off-by: Matt Porter <mporter@linaro.org>
Signed-off-by: Greg Kroah-Hartman <greg@kroah.com>

We can't know that the greybus values and the kernel values for a number
of battery enumerated types will remain in sync.  And as theses are sent
by an external device from the kernel, we have to explicitly check these
values.
Reported-by: Viresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: Greg Kroah-Hartman <greg@kroah.com>

Signed-off-by: Greg Kroah-Hartman <greg@kroah.com>

This pulls in the battery driver work I did there.

The AP needs to know its assigned Device ID in order to establish
Greybus connections between CPorts. We could have pulled the Device
ID from the controller hardware in a driver specific manner, but
instead we define one generic message from the SVC to let the
AP know this information. Add this additional unipro management
message and handle it by setting the supplied Device ID in the
struct greybus_host_device. The greybus core will use this to
populate the source Device ID when establishing a connection
between the AP and another module's CPort.
Signed-off-by: Matt Porter <mporter@linaro.org>
Signed-off-by: Greg Kroah-Hartman <greg@kroah.com>

When a module gets destroyed all of its state and the state of its
interfaces and connections (etc.) need to be torn down.  This is
not now being done properly.  Add this teardown code.
Signed-off-by: Alex Elder <elder@linaro.org>
Signed-off-by: Greg Kroah-Hartman <greg@kroah.com>

The battery code was not stashing a copy of its private data
pointer.  It'll be needed in the next patch.
Signed-off-by: Alex Elder <elder@linaro.org>
Signed-off-by: Greg Kroah-Hartman <greg@kroah.com>

The function that computes the operation id for a connection is
wrongly using MOD rather than AND.  Fix that.
Signed-off-by: Alex Elder <elder@linaro.org>
Signed-off-by: Greg Kroah-Hartman <greg@kroah.com>

This adds support to talk to the battery to get the various requests
made to it, based on the battery protocol defined in the Greybus
Specification.
Signed-off-by: Greg Kroah-Hartman <greg@kroah.com>

With a few minor changes, ap_disconnect() can correctly handle
cleaning up even a partially initialized USB interface.  Make those
changes, and then use ap_disconnect() to simplify cleanup for all
the error paths in ap_probe().  Reset all fields as they're cleaned
up to facilitate debugging.
Signed-off-by: Alex Elder <elder@linaro.org>

The next patch has ap_probe() reference ap_disconnect().  To prepare
for that, move ap_disconnect() up in the file.

This is done as a separate commit to make it easier to see this move
involves no other change to that function.  This and the next commit
can be squashed if desired.
Signed-off-by: Alex Elder <elder@linaro.org>
Signed-off-by: Greg Kroah-Hartman <greg@kroah.com>

We no longer keep copies of strings found in the manifuest in
a module's strings array, so we can get rid of the strings array.
Similarly, the new manifest parsing code sets up connections for
each cport id advertised for a module, so the cport array is
no longer needed either.
Signed-off-by: Alex Elder <elder@linaro.org>
Signed-off-by: Greg Kroah-Hartman <greg@kroah.com>

A struct gb_module has a bunch of fields from the earlier skeleton
code, where a module was assumed to possibly have one of every
type of device available on the GP Bridge.  The manifest parsing
code changed it so these things will be related to connection
endpoints, so these gb_module fields are no longer needed.

A few of these (battery and sdio) haven't been implemented the "new
way" yet, so just leave a bit of the code that was there commented
out for now.

Also, gb_tty seems to be partially implemented and I don't want to
remove that without knowing where it's headed, so that one stays.
Signed-off-by: Alex Elder <elder@linaro.org>
Signed-off-by: Greg Kroah-Hartman <greg@kroah.com>

Everything we do on greybus will involve an operation, so create a
slab cache for that frequently-allocated data structure.
Signed-off-by: Alex Elder <elder@linaro.org>
Signed-off-by: Greg Kroah-Hartman <greg@kroah.com>

Drop the USB device reference taken at the top of ap_probe() in the
event greybus_create_hd() fails.
Signed-off-by: Alex Elder <elder@linaro.org>
Signed-off-by: Greg Kroah-Hartman <greg@kroah.com>

Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: Greg Kroah-Hartman <greg@kroah.com>

core_param() takes four parameters instead of three and so results in this
compilation error:

greybus/core.c:25:33: error: macro "core_param" requires 4 arguments, but only 3 given
 core_param(nogreybus, bool, 0444);
                                 ^

Fix this by adding proper arguments to it.
Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: Greg Kroah-Hartman <greg@kroah.com>

Offset (or hwgpio num) is the offset within a gpiochip, not the
unique gpio namespace number. Adjust the error checking and use
of offset in our operation calls to fix this.
Signed-off-by: Matt Porter <mporter@linaro.org>
Signed-off-by: Greg Kroah-Hartman <greg@kroah.com>

Signed-off-by: Greg Kroah-Hartman <greg@kroah.com>

probably a cut and paste error got this unused status field. remove it.
Signed-off-by: Matt Porter <mporter@linaro.org>
Reviewed-by: Alex Elder <elder@linaro.org>
Signed-off-by: Greg Kroah-Hartman <greg@kroah.com>

Put the hard coded values in a function to make it easier to see what
needs to be done here.
Signed-off-by: Greg Kroah-Hartman <greg@kroah.com>

GPIO remove changed the api for 3.17 to try to make up for some
previously foolish design decisions.  Handle that in kernel_ver.h to
make the code simple.
Signed-off-by: Greg Kroah-Hartman <greg@kroah.com>

Signed-off-by: Greg Kroah-Hartman <greg@kroah.com>

If a gbuf completion indicates an error has occurred, report it.
Signed-off-by: Alex Elder <elder@linaro.org>
Signed-off-by: Greg Kroah-Hartman <greg@kroah.com>

Currently, if a USB urb completes with an error, that error status
is not transferred back to the gbuf that it's associated with.  For
inbound data there's not a lot we can do about an error, but for
outbound data, this means there is no notification to the submitter
that something went wrong.

For outbound data copy the urb status directly back to the gbuf as
its status.  Follow USB's lead and set the status to -EINPROGRESS
while a gbuf is "in flight."  Assign a gbuf an initial status value
of -EBADR to help identify use of never-set status values.

When an inbound urb fails (SVC or CPort), currently the urb is just
leaked, more or less (i.e., we lose an urb posted to receive
incoming data).  Change that so such an error is reported, but
then re-submitted.
Signed-off-by: Alex Elder <elder@linaro.org>
Signed-off-by: Greg Kroah-Hartman <greg@kroah.com>

It is expected that i2c writes may fail, and in that case the driver
simply retries some number of times before actually treating it as a
failure.  Define a GB_OP_RETRY status, which is interpreted by the
i2c driver as an indication a retry is in order.  We just translate
that into an EAGAIN error passed back to the i2c core.
Signed-off-by: Alex Elder <elder@linaro.org>
Signed-off-by: Greg Kroah-Hartman <greg@kroah.com>

First cut.
Signed-off-by: Alex Elder <elder@linaro.org>
Signed-off-by: Greg Kroah-Hartman <greg@kroah.com>

This patch adds the i2c driver, based on the use of Greybus operations
over Greybus connections.  It basically replaces almost all of what
was previously found in "i2c-gb.c".

When gb_connection_device_init(connection) is called, any connection
that talks the GREYBUS_PROTOCOL_I2C is passed to gb_i2c_device_init()
to be initialized.

Initialization involves verifying the code is able to support the
version of the protocol.  For I2C, we then query the functionality
mask, and set the retry count and timeout to default values.

After that, we set up the i2c device and associate it with the
connection.  The i2c_algorithm methods are then implemented
by translating them into Greybus operations.
Signed-off-by: Alex Elder <elder@linaro.org>
Signed-off-by: Greg Kroah-Hartman <greg@kroah.com>

The original CPort message handlers are not needed.  All incoming
data is passed to handlers based on the protocol used over the
connection over which the data was transferred.  So get rid of the
old CPort handler code.
Signed-off-by: Alex Elder <elder@linaro.org>
Signed-off-by: Greg Kroah-Hartman <greg@kroah.com>

At this point all incoming messages are handled by the operation
code, so this obviates the need for the gbuf workqueue.
Signed-off-by: Alex Elder <elder@linaro.org>
Signed-off-by: Greg Kroah-Hartman <greg@kroah.com>

Set up the infrastructure for initializing connections based on
their protocol.
Signed-off-by: Alex Elder <elder@linaro.org>
Signed-off-by: Greg Kroah-Hartman <greg@kroah.com>

Create a work queue to do the bulk of processing of received
operation request or response messages.
Signed-off-by: Alex Elder <elder@linaro.org>
Signed-off-by: Greg Kroah-Hartman <greg@kroah.com>

Give the operation layer a chance to examine incoming data so that
it can handle it appropriately.

Treat the data as an operation message header.  If it's a response,
look up the operation it's associated with.  If it's not, create a
new operation.  Copy the incoming data into the request or response
buffer.  The next patch adds a work queue to pick up handling
the request or response from there.

Get rid of gb_operation_submit().  Instead, we have two functions,
one for sending an operation's request message, the other for
sending an operation's response message.

Not fully functional yet, still just filling things in...
Signed-off-by: Alex Elder <elder@linaro.org>
Signed-off-by: Greg Kroah-Hartman <greg@kroah.com>

Add a red-black tree indexed by operation id to a connection to
allow pending operations (whose requests are in-flight) to be
found when their matching response is recieved.

Assign the id at the time an operation is inserted, and update
the operation's message header(s) to include it.

Rename gb_connection_op_id() to be more consistent with the
naming conventions being used elsewhere.

(Noting now that this may switch to a simple list implementation
based on Greg's assertion that lists are faster than red-black trees
for up to a few hundred entries.)
Signed-off-by: Alex Elder <elder@linaro.org>
Signed-off-by: Greg Kroah-Hartman <greg@kroah.com>

We need to track both request messages and response messages in
operations.  So add another gbuf (and payload pointer) field to
the operation structure, and rename them to indicate which one
is which.  Allow the creator specify the size of the response
buffer; just leave it a null pointer if the size is 0.

Define a new helper function gb_operation_gbuf_create() to
encapsulate creating either a request or a response buffer.

Any buffer associated with a connection will (eventually) have been
created as part of an operation.  So stash the operation pointer in
the gbuf as the context pointer.  Whether a buffer is for the
request or the response can be determined by pointer comparison.
Signed-off-by: Alex Elder <elder@linaro.org>
Signed-off-by: Greg Kroah-Hartman <greg@kroah.com>

Upcoming patches are going to set up devices based on what is
discovered in the module manifest.  Get rid of the hard-coded
initialization done by gb_init_subdevs(), along with other related
code.
Signed-off-by: Alex Elder <elder@linaro.org>
Signed-off-by: Greg Kroah-Hartman <greg@kroah.com>