| Message ID | alpine.DEB.2.11.1411181133080.3909@nanos (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
On Tuesday 18 November 2014 11:34:37 Thomas Gleixner wrote: > To support MSI irq domains we want a generic data structure for > allocation, but we need the option to provide an architecture specific > version of it. So instead of playing #ifdef games in linux/msi.h we > add a generic header file and let architectures decide whether to > include it or to provide their own implementation and provide the > required typedef. Acked-by: Arnd Bergmann <arnd@arndb.de> for merging the asm-generic file > I know that typedefs are not really nice, but in this case there are no > forward declarations required and it's the simplest solution. I must be missing the obvious: what problem does the typedef solve that you would have with just a struct? Arnd
On Tue, 18 Nov 2014, Arnd Bergmann wrote: > On Tuesday 18 November 2014 11:34:37 Thomas Gleixner wrote: > > To support MSI irq domains we want a generic data structure for > > allocation, but we need the option to provide an architecture specific > > version of it. So instead of playing #ifdef games in linux/msi.h we > > add a generic header file and let architectures decide whether to > > include it or to provide their own implementation and provide the > > required typedef. > > Acked-by: Arnd Bergmann <arnd@arndb.de> > > for merging the asm-generic file > > > I know that typedefs are not really nice, but in this case there are no > > forward declarations required and it's the simplest solution. > > I must be missing the obvious: what problem does the typedef solve > that you would have with just a struct? It's not obvious. :) The irqdomain stuff is pretty device tree centric, but the new stacked irqdomains are to be used by x86 as well. So we made some of the interfaces opaque, i.e. void *allocation_arg. Now MSI is a bit differnet as it cannot be decribed by DT, so we want a proper generic data structure for it and of course we want to have a type for it. Now x86 has a bit more convoluted requirements where we prefer for simplicity reasons to reuse the allocation data structure which we have alredy for the non MSI cases, so it can be handed down to the opaque interfaces as well. So we have the generic: struct msi_alloc_info { .... }; and struct x86_alloc_info { ... }; So we either can do in x86: struct msi_alloc_info { struct x86_alloc_info info; }; or use a typedef which maps x86_alloc_info to msi_alloc_info_t. I think the typedef is more sane in that case. Thanks, tglx
On Tuesday 18 November 2014 11:59:39 Thomas Gleixner wrote: > On Tue, 18 Nov 2014, Arnd Bergmann wrote: > > > On Tuesday 18 November 2014 11:34:37 Thomas Gleixner wrote: > > > To support MSI irq domains we want a generic data structure for > > > allocation, but we need the option to provide an architecture specific > > > version of it. So instead of playing #ifdef games in linux/msi.h we > > > add a generic header file and let architectures decide whether to > > > include it or to provide their own implementation and provide the > > > required typedef. > > > > Acked-by: Arnd Bergmann <arnd@arndb.de> > > > > for merging the asm-generic file > > > > > I know that typedefs are not really nice, but in this case there are no > > > forward declarations required and it's the simplest solution. > > > > I must be missing the obvious: what problem does the typedef solve > > that you would have with just a struct? > > It's not obvious. :) > > The irqdomain stuff is pretty device tree centric, but the new stacked > irqdomains are to be used by x86 as well. So we made some of the > interfaces opaque, i.e. void *allocation_arg. > > Now MSI is a bit differnet as it cannot be decribed by DT, so we want > a proper generic data structure for it and of course we want to have a > type for it. > > Now x86 has a bit more convoluted requirements where we prefer for > simplicity reasons to reuse the allocation data structure which we > have alredy for the non MSI cases, so it can be handed down to the > opaque interfaces as well. > > So we have the generic: > > struct msi_alloc_info { > .... > }; > > and > > struct x86_alloc_info { > ... > }; > > So we either can do in x86: > > struct msi_alloc_info { > struct x86_alloc_info info; > }; > > or use a typedef which maps x86_alloc_info to msi_alloc_info_t. > > I think the typedef is more sane in that case. > Ok, makes sense. Arnd
diff --git a/include/asm-generic/msi.h b/include/asm-generic/msi.h new file mode 100644 index 000000000000..61c58d8878ce --- /dev/null +++ b/include/asm-generic/msi.h @@ -0,0 +1,32 @@ +#ifndef __ASM_GENERIC_MSI_H +#define __ASM_GENERIC_MSI_H + +#include <linux/types.h> + +#ifndef NUM_MSI_ALLOC_SCRATCHPAD_REGS +# define NUM_MSI_ALLOC_SCRATCHPAD_REGS 2 +#endif + +struct msi_desc; + +/** + * struct msi_alloc_info - Default structure for MSI interrupt allocation. + * @desc: Pointer to msi descriptor + * @hwirq: Associated hw interrupt number in the domain + * @scratchpad: Storage for implementation specific scratch data + * + * Architectures can provide their own implementation by not including + * asm-generic/msi.h into their arch specific header file. + */ +typedef struct msi_alloc_info { + struct msi_desc *desc; + irq_hw_number_t hwirq; + union { + unsigned long ul; + void *ptr; + } scratchpad[NUM_MSI_ALLOC_SCRATCHPAD_REGS]; +} msi_alloc_info_t; + +#define GENERIC_MSI_DOMAIN_OPS 1 + +#endif
To support MSI irq domains we want a generic data structure for allocation, but we need the option to provide an architecture specific version of it. So instead of playing #ifdef games in linux/msi.h we add a generic header file and let architectures decide whether to include it or to provide their own implementation and provide the required typedef. I know that typedefs are not really nice, but in this case there are no forward declarations required and it's the simplest solution. Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Cc: Jiang Liu <jiang.liu@linux.intel.com> Cc: Tony Luck <tony.luck@intel.com> Cc: linux-arm-kernel@lists.infradead.org Cc: Bjorn Helgaas <bhelgaas@google.com> Cc: Grant Likely <grant.likely@linaro.org> Cc: Marc Zyngier <marc.zyngier@arm.com> Cc: Yijing Wang <wangyijing@huawei.com> Cc: Yingjoe Chen <yingjoe.chen@mediatek.com> Cc: Borislav Petkov <bp@alien8.de> Cc: Matthias Brugger <matthias.bgg@gmail.com> Cc: Alexander Gordeev <agordeev@redhat.com> Cc: Arnd Bergmann <arnd@arndb.de>