On 15-01-21, 14:16, Arnd Bergmann via Stratos-dev wrote:

You need a driver in the guest though that understands the device specific signaling and additional data. Let's look at a moderately complex example I picked at random, drivers/leds/leds-lp8501.c:

I assume the idea would be to not replace the entire driver with a greybus specific one, but to reused as much as possible from the existing code. The driver has no interrupts but it needs to access a gpio line and some device specific configuration data, which it can get either from a platform_data or from DT properties.

Passing such a device through greybus then requires at least these steps:

• allocate a unique device:vendor ID pair
• create a lp8501 specific manifest binding for that ID
• for the host, create an lp8501 specific greybus host driver to
  • read the device tree in the host, convert into manifest format according to the binding
  • open the raw i2c device and gpio line from user space
  • create virtual devices for these two, describe them in the manifest
• for the guest, create an lp8501 greybus device driver for the vendor:device ID pair, to
  • interpret the manifest, convert data into lp55xx_platform_data
  • instantiate a gpio controller with one gpio line,
  • allocate a gpio number for that controller, add it to the platform data
  • instantiate a i2c host
  • instantiate a i2c device on that host, using the platform_data and the "lp8501" i2c_device_id string.

If a device has no DT properties or platform_data, and no gpio, reset, regulator, clock, or other dependendencies, some of the steps can be skipped, but at the minimum you still need device specific code in the guest to map the vendor:device ID to an i2c_device_id.

Right, I misunderstood it earlier when I thought you are talking about the controller.

Greybus takes care of how a i2c message gets transferred and gets translated to the host's controller driver, but the device sits above this layer.

The device (like i2c memory or touchscreen) has its own driver and protocols to follow, which don't have much to do with i2c (it can just be spi as well with almost exactly the same driver). i2c here is just a bus, as we have amba buses for ARM platforms (where we can directly access registers). And the end device's driver will be there at the guest and not host.

I don't think copying their properties to manifest adds any real value here. We should do that part over DT itself, as the guest is going to receive one from the host anyway. We just need to see how we divide this information between DT and manifests, or maybe we can make greybus work with DT as well (at the client side).

At this point I would also like to ask if we should also get this discussion going over the greybus-list, specially people like Greg KH and Johan Hovold, as any changes to greybus would require their approval as well anyway and they may be able to give some ideas as well.