Hi Linus, On 10-06-21, 22:46, Linus Walleij wrote: > Hi Viresh! > > thanks for working on this, it's a really interesting driver. > > My first question is conceptual: > > We previously have Geerts driver for virtualization: > drivers/gpio/gpio-aggregator.c > > The idea with the aggregator is that a host script sets up a > unique gpiochip for the virtualized instance using some poking > in sysfs and pass that to the virtual machine. > So this is Linux acting as virtualization host by definition. > > I think virtio is more abstract and intended for the usecase > where the hypervisor is not Linux, so this should be mentioned > in the commit, possibly also in Kconfig so users immediately > know what usecases the two different drivers are for. Well, not actually. The host can actually be anything. It can be a Xen based dom0, which runs some proprietary firmware, or Qemu running over Linux. It is left for the host to decide how it wants to club together the GPIO pins from host and access them, with Linux host userspace it would be playing with /dev/gpiochipN, while for a raw one it may be accessing registers directly. And so the backend running at host, needs to pass the gpiochip configurations and only the host understand it. The way I test it for now is by running this with Qemu over my x86 box, so my host side is indeed playing with sysfs Linux. > Possibly both could be used: aggregator to pick out the GPIOs > you want into a synthetic GPIO chip, and the actual talk > between the hypervisor/host and the guest using virtio, even > with linux-on-linux. Not sure if I understand the aggregator thing for now, but we see the backend running at host (which talks to this Linux driver at guest) as a userspace thing and not a kernel driver. Not sure if aggregator can be used like that, but anyway.. > Yet another usecase would be to jit this with remoteproc/rpmsg > and let a specific signal processor or real-time executive on > another CPU with a few GPIOs around present these to > Linux using this mechanism. Well that would certainly interest > Bjorn and other rpmsg stakeholders, so they should have > a look so that this provides what they need they day they > need it. (CCed Bjorn and also Google who may want this for > their Android emulators.) I am not very clear on the rpmsg thing, I know couple of folks at project Stratos were talking about it :) @Alex, want to chime in here for me ? :) > On Thu, Jun 10, 2021 at 2:16 PM Viresh Kumar <viresh.kumar@xxxxxxxxxx> wrote: > > > +static const char **parse_gpio_names(struct virtio_device *vdev, > > + struct virtio_gpio_config *config) > > I really like this end-to-end plug-and-play that even provides > the names over virtio. The credit goes to Enrico for this :) > I think my patch to the gpiolib to make it mandatory for names to > be unique per-chip made it in, but please make that part of the spec > so that we don't get the problem with non-unique names here. Oh, that's nice. I will surely do that. > I suppose the spec can be augmented later to also accept config > settings like open drain pull up/down etc but no need to specify > more than the basic for now. That's the plan. > But to be able to add more in the future, the client needs some > kind of query mechanism or version number so the driver can > adapt and not announce something the underlying virtio device > cannot do. Do we have this? A bitmask for features, a version > number that increase monotonically for new features to be > presented or similar? > > Because otherwise we have to bump this: > +#define VIRTIO_ID_GPIO 41 /* virtio GPIO */ > > every time we add something new (and we will). Yes, Virtio presents features for this. The patch 2/3 already uses one for IRQs. We won't need to bump up the IDs :) -- viresh _______________________________________________ Virtualization mailing list Virtualization@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linuxfoundation.org/mailman/listinfo/virtualization
