Re: [patch 08/16] genirq: Introduce callback irq_chip.irq_write_msi_msg
From: Thomas Gleixner
Date: Tue Nov 18 2014 - 05:19:17 EST
On Tue, 18 Nov 2014, Yun Wu (Abel) wrote:
> On 2014/11/12 21:43, Thomas Gleixner wrote:
> > struct irq_chip {
> > @@ -359,6 +360,7 @@ struct irq_chip {
> > void (*irq_release_resources)(struct irq_data *data);
> >
> > void (*irq_compose_msi_msg)(struct irq_data *data, struct msi_msg *msg);
> > + void (*irq_write_msi_msg)(struct irq_data *data, struct msi_msg *msg);
>
> Hmm... It's really weird.
> I don't think it's the interrupt controllers' responsibility to write messages
> for all the endpoint devices since the methods of configuring message registers
> may different between these devices. And theoretically, the endpoint devices
> themselves should take the responsibility to configure their message registers.
> To say the least, the write_msg callback here still need to call some certain
> interfaces provided by the corresponding device.
>
> There would be lots of ARM new devices capable of sending message
> based interrupts to interrupt controllers, does all the drivers of
> the devices need to expose a write_msg callback to interrupt
> controllers?
Well, writing the message _IS_ part of the interrupt controller.
So in order to enable non PCI based MSI we want to have generic
infrastructure with minimal per device/device class callbacks and of
course you need to provide that callback for your special device.
We already have non PCI based MSI controllers in x86 today and we need
to handle the whole stuff with tons of copied coded extra for each of
those. So consolidating it into common infrastructure allows us to get
rid of the pointless copied code and reduce the per device effort to
the relevant hardware specific callbacks. irq_write_msi_msg being one
of those.
Thanks,
tglx
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/