Rename and renumber the values for the AP ID service message
and related symbols to match the recently-updated spec.
Signed-off-by: Alex Elder <elder@linaro.org>
Signed-off-by: Greg Kroah-Hartman <greg@kroah.com>
We removed the DDB function messages from the spec as they are
not needed. Now remove it from the code.
Signed-off-by: Matt Porter <mporter@linaro.org>
Signed-off-by: Greg Kroah-Hartman <greg@kroah.com>
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>
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>
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>
A UniPro (short header) segment has a 5-bit field to represent a
CPort Id. In addition, the 7-bit L3 short header holds a UniPro
device id. There can be no more than 128 devices in a UniPro
network, but these two fields can be combined in ways to allow for
over 2000 CPorts within a single device. As a result, a device id
is represented with one byte, and a CPort Id within a device is
always representable with a two byte value.
This patch changes integral values that reresent CPort Ids so they
use type u16 consistently.
Separately, the contents of the gmod_cport structure were mostly
fabricated, with the cport_id field being the only one that's
meaningful. This patch gets rid of that structure, putting a
simple u16 to represent the CPort Id everywhere it had been used
before.
Signed-off-by: Alex Elder <elder@linaro.org>
Signed-off-by: Greg Kroah-Hartman <greg@kroah.com>
Two spots use the old "0.draft" version number for the Greybus
protocol specification. We've updated that to be 0.1.
Signed-off-by: Alex Elder <elder@linaro.org>
Signed-off-by: Greg Kroah-Hartman <greg@kroah.com>
Add a GPLv2 tag and reword some comments at the top of "greybus_desc.h"
and "svc_msg.h".
Signed-off-by: Alex Elder <elder@linaro.org>
Signed-off-by: Greg Kroah-Hartman <greg@kroah.com>
The Greybus spec has been updated to improve the efficiency of the
version major/minor information that had been previously carried in
every SVC message header. The version major/minor is now provided
as part of the handshake function.
Update the SVC msg header and handshake function payload definitions
and move the version major/minor validation into the SVC handshake
handling routine.
Signed-off-by: Matt Porter <mporter@linaro.org>
Signed-off-by: Greg Kroah-Hartman <greg@kroah.com>
The Greybus spec has been updated to clarify some of the original
intent of the SVC message definition. The svc_msg_header was:
struct svc_msg_header {
__u8 function;
__u8 message_type;
...
}
and is now
struct svc_msg_header {
__u8 function_id;
__u8 message_type;
...
}
to match the spec. The function_id carries enum svc_function_id values
and message_type is now clarified to be a session layer level field
that is simply "data" or "error".
Change all references of function type to function id. For now, don't
parse the message_type field but add the two allowable svc_msg_type enums.
Signed-off-by: Matt Porter <mporter@linaro.org>
Signed-off-by: Greg Kroah-Hartman <greg@kroah.com>
