On Wed, Jul 28, 2021 at 1:11 PM Viresh Kumar <[email protected]> wrote: > > virtio-gpio is a virtual GPIO controller. It provides a way to flexibly > communicate with the host GPIO controllers from the guest. > > Note that the current implementation doesn't provide atomic APIs for > GPIO configurations. i.e. the driver (guest) would need to implement > sleep-able versions of the APIs as the guest will respond asynchronously > over the virtqueue. > > This patch adds the specification for it. > > Based on the initial work posted by: > "Enrico Weigelt, metux IT consult" <[email protected]>. > > Fixes: https://github.com/oasis-tcs/virtio-spec/issues/110 > Signed-off-by: Viresh Kumar <[email protected]>
Reviewed-by: Arnd Bergmann <[email protected]> I found one detail that could be improved if you can come up with a better way, or you just leave it: > +\begin{lstlisting} > +struct virtio_gpio_response { > + u8 status; > + u8 value[N]; > +}; > + > +/* Possible values of the status field */ > +#define VIRTIO_GPIO_STATUS_OK 0x0 > +#define VIRTIO_GPIO_STATUS_ERR 0x1 > +\end{lstlisting} > + > +All the fields of this structure are set by the device and read by the > driver. > + > +\begin{description} > +\item[\field{status}] of the GPIO message, > + \field{VIRTIO_GPIO_STATUS_OK} on success and > \field{VIRTIO_GPIO_STATUS_ERR} > + on failure. > + > +\item[\field{value}] is a message specific defined value. The value of N > (i.e. > + size of the \field{value} buffer in bytes) is 1 for most of the messages, > + except \field{VIRTIO_GPIO_MSG_GET_LINE_NAMES}, where it is set to the > value > + of \field{gpio_names_size} field. > +\end{description} I think the structure layout here is good, but I wonder if the description would be clearer if you define two separate structures, with a fixed-length structure for normal requests, and the variable-length structure for VIRTIO_GPIO_MSG_GET_LINE_NAMES. Arnd --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
