Re: [virtio-dev] Re: [virtio-comment] [PATCH v2] virtio-gpio: add formal specification

[Arnd Bergmann <arnd@linaro.org>]

On Wed, Jun 30, 2021 at 7:30 PM Viresh Kumar <viresh.kumar@linaro.org> wrote:
>
> On 30-06-21, 17:55, Enrico Weigelt, metux IT consult wrote:
> > On 30.06.21 17:22, Viresh Kumar wrote:
> > > + All the people from previous version (Please cc them yourself while sending a
> > > new version, these are the people interested in this stuff).
>
> Adding them again, not sure why they got dropped after your email.

Thanks.

> > > I don't see the improvements suggested for the config structure, nothing about
> > > features, no interrupt support. You just reformatted the stuff and that's all.
> >
> > Don't worry, I haven't forgotten that. But that's something I'd *really*
> > like to have as optional features (so not all hardware is mandated to
> > implement that all) and i'd like to get the mandatory base finished,
> > before specifying the optional features like interrupt controller.
> >
> > Let's discuss the optional features separately, feel free to share your
> > thoughts here.
>
> What about the changes to the config structure to make it efficient,
> easily extendable, etc Or the Free Msg, etc? These views are already
> shared in details for the earlier version and I shouldn't be expected
> to explain them again.
>
> Over that, if you don't want to implement interrupts in your version
> (I can surely send a patch for that), then you need to drop the
> half-hearted interrupt support, i.e.  VIRTIO_GPIO_MSG_DEVICE_LEVEL, as
> that is not the right way of implementing interrupts. This will make
> the specification as well as Linux or backend code messy, as we would
> be required to support interrupts in two ways in this case based on
> irq-feature. If you want to support interrupts, then you need to do
> them properly, else don't add them at all.

Agreed, interrupt support is obviously something that can not be
retrofitted easily if you don't get it right from the start.

> Please reply to the issues raised in the previous version itself now
> and close them there. And please don't proceed with a new version
> unless there is a clear consensus in favor or otherwise. It just ends
> up wasting a lot of time for everyone.

+1

      Arnd