As I'm planning to add some other protocols,
create a folder to store all protocols sources.

Signed-off-by: Alexandre Bailon <abailon@baylibre.com>

Currently, all controllers' sources are in main sources folder.
Move sources to a dedicated folder.

Signed-off-by: Alexandre Bailon <abailon@baylibre.com>

The current status set in the response to GB_SVC_TYPE_INTF_SET_PWRM
is not the one expected by Greybus.
Set status to GB_SVC_SETPWRM_PWR_LOCAL.

Signed-off-by: Alexandre Bailon <abailon@baylibre.com>

We are creating and openning a connection but we are
never destroying it.
Register the connection_destroy callback.

Signed-off-by: Alexandre Bailon <abailon@baylibre.com>

gbridge has been written to work with the latest version
of greybus available at the beginning of the project.
But greybus has been updated and merge to kernel.
Update gbridge to work with the latest version of greybus.

Signed-off-by: Alexandre Bailon <abailon@baylibre.com>

Add the macro REQUEST_NO_HANDLER() to define an operation handler
without a callback. This will let us add new SVC operations without
to have to implement them.
Operation registered with REQUEST_NO_HANDLER() are not supposed
to be used by the kernel in the current state, but if the kernel
does, then gbridge will print an error.

Signed-off-by: Alexandre Bailon <abailon@baylibre.com>

SVC operation are dispatched in SVC driver by switch case block.
It works fine but it is hard to figure out which operation handler
is complete, which one is just a stub method or which one is missing.
In addition, it's not really scalable. By example, to print then of
operation that failed, we will have to add and maintain another switch
case block that print operation name (instead of operation type).
Use new struct to register a callback and some other information about
operation.
Register all operation in an array and get the operation handler from it.
In the case of failure, the operation dispatcher will be able get some
additional information from the operation handler and give some details
about the error.

Signed-off-by: Alexandre Bailon <abailon@baylibre.com>

Update log helpers to print errors in red and warnings in yellow.
It should make more easier to see errors and warnings when they printed
between greybus operation dump.

Signed-off-by: Alexandre Bailon <abailon@baylibre.com>

UART is not intended for production. The code is pretty bad and
I don't plan to update it.
Actually, it just make more easier to bring up support of Greybus
to a new OS by using UART.

Signed-off-by: Alexandre Bailon <abailon@baylibre.com>

interface_recv() is using the cport_id to get the connection
struct. But unlike hd_cport_id which are unique for Greybus,
some interface may use the same cport id.
So to get the right connection struct, we must use both
the interface and cport_id.
Update cport_id_to_connection() to use both cport_id and intf.

Signed-off-by: Alexandre Bailon <abailon@baylibre.com>

Some controller may require some arguments such as device name.
In that situation, the controller could not be registered from
register_controllers() function.
Make register_controller() public.

Signed-off-by: Alexandre Bailon <abailon@baylibre.com>

Currently, there is two supported controller: TPC/IP and bluetooth.
Add some options to enable or disable them at build time.

Signed-off-by: Alexandre Bailon <abailon@baylibre.com>

Currently, without GB_SVC_TYPE_ROUTE_CREATE and GB_SVC_TYPE_ROUTE_DESTROY,
Greybus won't correctly work.
Add these two operations.

Signed-off-by: Alexandre Bailon <abailon@baylibre.com>

Currently, when gbridge exit, it doesn't remove the SVC.
When gbridge will run again, it won't be able to initialize
the SVC because Greybus doesn't expect a new SVC to registered.
Greybus doesn't support SVC ho unplug, so to fix it, we have unload
greybus hd driver.
Use the GB_NL_C_HD_RESET to unload and then load the hd driver.

Signed-off-by: Alexandre Bailon <abailon@baylibre.com>

Greybus keep sending ping to SVC while gbridge has exited,
causing a watchdog bite. It doesn't have any effects,
but it is better to avoid by disabling the watchdog before to exit.

Signed-off-by: Alexandre Bailon <abailon@baylibre.com>

Add some basic instruction to build and use gbridge.
The instructions must be completed with instructions
to setup a module and instruction about Greybus itself
(how it works, sysfs entries, etc).

Signed-off-by: Alexandre Bailon <abailon@baylibre.com>

Add a summary about how the TCP/IP controller is working in README.

Signed-off-by: Alexandre Bailon <abailon@baylibre.com>

Explain that the cport number is stored in greybus header.
That particullary important because other controller like
TPC/IP can open one communication channel per cport,
and doesn't need to keep it in the header.

Signed-off-by: Alexandre Bailon <abailon@baylibre.com>

The TCP/IP controller was able to send a SVC hotplug operation to Greybus
before we get the host name, the IP and the port of the module.
Send the hotplug to Greybus only once avahi have completed the resolve
operation.

Signed-off-by: Alexandre Bailon <abailon@baylibre.com>

When an error happen during a read operation,
the thread continuously try to read again, and break down the performances.
If something is going wrong during a read operation,
exit the thread instead of trying to read again.

Signed-off-by: Alexandre Bailon <abailon@baylibre.com>

Add the TCP/IP controller to connect to module through TCP/IP.
Currently, a module is detected by using avahi.
To be discovered, the module must register a service of type "_greybus._tcp".
The TCP/IP controller will create one socket per connection,
and use an unique port number to open each of them.

Signed-off-by: Alexandre Bailon <abailon@baylibre.com>

Currently, the read of data commming from module is made at interface level.
It is required for controller that only support one stream per interface.
But controllers may have one stream per connection and so,
we can create a thread to wait and read incoming data for each connection.

Signed-off-by: Alexandre Bailon <abailon@baylibre.com>

Currently, the connection between the host and a module
can only be created after the module has been detected or
during the interface create. For some controller, we don't
have the choice because they only have a stream that need
to open before any other operation.
But some controller (e.g. TPC/IP) can use more than one stream.
Add connection_create() and connection_destroy() callbacks to
let that kind of controller create more than one connection.

Signed-off-by: Alexandre Bailon <abailon@baylibre.com>

The event is mainly used for module detection.
The controller create a thread to run the loop and generate
the hotplug and hot unpulg events.
But an event loop may prevent the application to exit,
because it use methods that prevent thread to be cancelled.
Add a new callback that will be called before to cancel the
thread to put the event loop in a cancellable state.

Signed-off-by: Alexandre Bailon <abailon@baylibre.com>

Explain what is GBridge and,
speak a litle about the architecture.

Signed-off-by: Alexandre Bailon <abailon@baylibre.com>

The bluetooth controller only support one HCI controller.
It continuously scan devices and automatically add any device
with GREYBUS in its name.
Currently, the controller doesn't support hot remove.

Signed-off-by: Alexandre Bailon <abailon@baylibre.com>

Add the controller HAL in order to add support of Greybus
to different type of device such as bluetooth or Wi-Fi.
SVC and Greybus (through Netlink) use interface and cport,
and the controller HAL will convert it in some way to be
compatible with bluetooth, Wi-Fi, etc.

Signed-off-by: Alexandre Bailon <abailon@baylibre.com>

The TAILQ_FOREACH_SAFE () macro doesn't seems
to be always present.
Define it if it is not already defined.

Signed-off-by: Alexandre Bailon <abailon@baylibre.com>

Add a limited implementation of SVC protocol.
Most of the code has been generated and is obviously incomplete.
But it's enough to register the SVC and respond to ping.

Signed-off-by: Alexandre Bailon <abailon@baylibre.com>

Add the method pr_dump to dump greybus operations.

Signed-off-by: Alexandre Bailon <abailon@baylibre.com>

Netlink is used to communicate with the greybus kernel.
Add a preliminary support of netlink.

Signed-off-by: Alexandre Bailon <abailon@baylibre.com>

This application connects to greybus netlink host device.
The main is goal is to give a way to resgister
a host device driver in user space.

Signed-off-by: Alexandre Bailon <abailon@baylibre.com>