search for: setup_msi_irq

...i.h > index 0892ea0..04c9ef6 100644 > --- a/arch/x86/include/asm/pci.h > +++ b/arch/x86/include/asm/pci.h > @@ -96,10 +96,10 @@ extern void pci_iommu_alloc(void); > #ifdef CONFIG_PCI_MSI > /* implemented in arch/x86/kernel/apic/io_apic. */ > struct msi_desc; > -int native_setup_msi_irqs(struct pci_dev *dev, int nvec, int type); > +int native_setup_msi_irqs(struct msi_irqs *msi, int nvec, int type); > void native_teardown_msi_irq(unsigned int irq); > -void native_restore_msi_irqs(struct pci_dev *dev); > -int setup_msi_irq(struct pci_dev *dev, struct msi_desc *msidesc,...

...i.h > index 0892ea0..04c9ef6 100644 > --- a/arch/x86/include/asm/pci.h > +++ b/arch/x86/include/asm/pci.h > @@ -96,10 +96,10 @@ extern void pci_iommu_alloc(void); > #ifdef CONFIG_PCI_MSI > /* implemented in arch/x86/kernel/apic/io_apic. */ > struct msi_desc; > -int native_setup_msi_irqs(struct pci_dev *dev, int nvec, int type); > +int native_setup_msi_irqs(struct msi_irqs *msi, int nvec, int type); > void native_teardown_msi_irq(unsigned int irq); > -void native_restore_msi_irqs(struct pci_dev *dev); > -int setup_msi_irq(struct pci_dev *dev, struct msi_desc *msidesc,...

...lude/asm/pci.h b/arch/x86/include/asm/pci.h index 0892ea0..04c9ef6 100644 --- a/arch/x86/include/asm/pci.h +++ b/arch/x86/include/asm/pci.h @@ -96,10 +96,10 @@ extern void pci_iommu_alloc(void); #ifdef CONFIG_PCI_MSI /* implemented in arch/x86/kernel/apic/io_apic. */ struct msi_desc; -int native_setup_msi_irqs(struct pci_dev *dev, int nvec, int type); +int native_setup_msi_irqs(struct msi_irqs *msi, int nvec, int type); void native_teardown_msi_irq(unsigned int irq); -void native_restore_msi_irqs(struct pci_dev *dev); -int setup_msi_irq(struct pci_dev *dev, struct msi_desc *msidesc, +void native_restor...

...r the maskable ones, and the other for the (MSI only) non-maskable ones. At once the implementation of those methods gets moved from io_apic.c to msi.c. Signed-off-by: Jan Beulich <jbeulich@suse.com> --- a/xen/arch/x86/hpet.c +++ b/xen/arch/x86/hpet.c @@ -312,7 +312,7 @@ static void __hpet_setup_msi_irq(struct { struct msi_msg msg; - msi_compose_msg(desc->irq, &msg); + msi_compose_msg(desc, &msg); hpet_msi_write(desc->action->dev_id, &msg); } --- a/xen/arch/x86/hvm/vmsi.c +++ b/xen/arch/x86/hvm/vmsi.c @@ -382,7 +382,7 @@ int msixtbl_pt_register(struct do...

Hi all, The series is a draft of generic MSI driver that supports PCI and Non-PCI device which have MSI capability. If you're not interested it, sorry for the noise. The series is based on Linux-3.16-rc1. MSI was introduced in PCI Spec 2.2. Currently, kernel MSI driver codes are bonding with PCI device. Because MSI has a lot advantages in design. More and more non-PCI devices want to use

Hi all, The series is a draft of generic MSI driver that supports PCI and Non-PCI device which have MSI capability. If you're not interested it, sorry for the noise. The series is based on Linux-3.16-rc1. MSI was introduced in PCI Spec 2.2. Currently, kernel MSI driver codes are bonding with PCI device. Because MSI has a lot advantages in design. More and more non-PCI devices want to use

Hi Ingo, Here''s the chunk of patches to add Xen Dom0 support (it''s probably worth creating a new xen/dom0 topic branch for it). A dom0 Xen domain is basically the same as a normal domU domain, but it has extra privileges to directly access hardware. There are two issues to deal with: - translating to and from the domain''s pseudo-physical addresses and real machine