On Tue, Dec 8, 2020 at 8:12 AM Viresh Kumar via Stratos-dev stratos-dev@op-lists.linaro.org wrote:

Hi Guys,

There are offline discussions going on to assess the possibility of re-using the Linux kernel Greybus framework for Virtio [1] use case, where we can control some of the controllers on the back-end (Host), like SPI, I2C, GPIO, etc, from front-end (VM), using the already well defined Greybus specification [2].

The Greybus specification and kernel source was initially developed for Google's Project ARA [3], and the source code was merged into mainline kernel long time back (in drivers/greybus/ and drivers/staging/greybus/). You can find more information about how Greybus works in this LWN article [4].

Greybus broadly provides two distinct features:

• Device discovery: at runtime, with the help of a manifest file (think of it like DT, though it has a different format). This helps the user of the hardware to identify the capabilities of the remote hardware, which it can use.

• Remote control/operation: of the IPs present on the remote hardware, using firmware/OS independent operations, these are already well defined for a lot of device types and can be extended if required.

We wanted to share this over email to get some discussion going, so it can be discussed later on the call.

Alex Elder (Cc'd) is one of the Maintainers of the Greybus core in Linux Kernel and I worked on a wide variety of stuff and maintain some of it. Both of us worked in project ARA and would like to see Greybus being used in other applications and would like to contribute towards it.

I think the main capability this would add compared to having a simple virtio device per bus is that you can have a device that is composed of multiple back-ends, e.g. an i2c slave plus a set of GPIOs are tied together for one functionality, this is something we did not discuss in the call today. The downside is that for each remote device, we'd still need to add a binding and a driver to make use of it.

The alternative is to use a device tree to describe these to the guest kernel at boot time. The advantage is that we only need a really simple drivers for each type of host controller (i2c, spi, ....), and describing the actual devices works just as before, using the existing DT bindings to pass bind the attached device to a driver and add auxiliary information with references to other devices (gpio, irq, device settings), at the cost of needing to configure them at boot time.

Arnd