On Thu, Oct 21, 2021 at 7:34 AM Viresh Kumar <viresh.kumar at linaro.org> wrote:> On 20-10-21, 18:10, Andy Shevchenko wrote: > > On Wednesday, October 20, 2021, Viresh Kumar <viresh.kumar at linaro.org> > > wrote:...> > > + case IRQ_TYPE_NONE: > > > + type = VIRTIO_GPIO_IRQ_TYPE_NONE; > > > + break; > > > > IIRC you add dead code. IRQ framework never calls this if type is not set. > > Yes, but it is allowed to call > > irq_set_irq_type(irq, IRQ_TYPE_NONE); > > and the irq framework won't disallow it AFAICT.That's true, but how you may end up in this callback with a such? What the meaning of that call to the user? ...> > > struct virtio_gpio_config { > > > __le16 ngpio; > > > __u8 padding[2]; > > > @@ -44,4 +56,17 @@ struct virtio_gpio_response_get_names { > > > __u8 value[]; > > > }; > > > > > > +/* Virtio GPIO IRQ Request / Response */ > > > +struct virtio_gpio_irq_request { > > > + __le16 gpio; > > > +}; > > > + > > > +struct virtio_gpio_irq_response { > > > + __u8 status; > > > +}; > > > > > I?m wondering if those above should be packed. > > You are talking about the newly added ones or the ones before ? > > In any case, they are all already packed (i.e. they have explicit > padding wherever required) and properly aligned. Compiler won't add > any other padding to them.Is it only for 64-bit to 64-bit communications? If there is a possibility to have 32-bit to 64-bit or vice versa communication you have a problem. -- With Best Regards, Andy Shevchenko
On 21-10-21, 12:42, Andy Shevchenko wrote:> On Thu, Oct 21, 2021 at 7:34 AM Viresh Kumar <viresh.kumar at linaro.org> wrote: > > On 20-10-21, 18:10, Andy Shevchenko wrote: > > > IIRC you add dead code. IRQ framework never calls this if type is not set. > > > > Yes, but it is allowed to call > > > > irq_set_irq_type(irq, IRQ_TYPE_NONE); > > > > and the irq framework won't disallow it AFAICT. > > That's true, but how you may end up in this callback with a such? > What the meaning of that call to the user?I can see few calls like this in the kernel (mostly from irq-providers only), but yeah sure I can drop it. We will error out if it ever gets called and so can get it back later if required.> > > > struct virtio_gpio_config { > > > > __le16 ngpio; > > > > __u8 padding[2]; > > > > @@ -44,4 +56,17 @@ struct virtio_gpio_response_get_names { > > > > __u8 value[]; > > > > }; > > > > > > > > +/* Virtio GPIO IRQ Request / Response */ > > > > +struct virtio_gpio_irq_request { > > > > + __le16 gpio; > > > > +}; > > > > + > > > > +struct virtio_gpio_irq_response { > > > > + __u8 status; > > > > +}; > > > > > > > I?m wondering if those above should be packed. > > > > You are talking about the newly added ones or the ones before ? > > > > In any case, they are all already packed (i.e. they have explicit > > padding wherever required) and properly aligned. Compiler won't add > > any other padding to them. > > Is it only for 64-bit to 64-bit communications?That's what I have been looking at.> If there is a possibility to have 32-bit to 64-bit or vice versa > communication you have a problem.This should work as well. The structure will get aligned to the size of largest element and each element will be aligned to itself. I don't see how this will break even in case of 32/64 bit communication. -- viresh