From mboxrd@z Thu Jan 1 00:00:00 1970 From: Suravee Suthikulpanit Subject: Re: [Patch Part2 v5 21/31] PCI/MSI: Enhance core to support hierarchy irqdomain Date: Sun, 9 Nov 2014 11:26:44 +0700 Message-ID: <545EED04.4090008@amd.com> References: <1415283644-2559-1-git-send-email-jiang.liu@linux.intel.com> <1415283644-2559-22-git-send-email-jiang.liu@linux.intel.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; Format="flowed" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <1415283644-2559-22-git-send-email-jiang.liu@linux.intel.com> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=m.gmane.org@lists.infradead.org To: Jiang Liu , Benjamin Herrenschmidt , Thomas Gleixner , Ingo Molnar , "H. Peter Anvin" , "Rafael J. Wysocki" , Bjorn Helgaas , Randy Dunlap , Yinghai Lu , Borislav Petkov , Grant Likely , Marc Zyngier , Yingjoe Chen , Matthias Brugger , Yijing Wang , Alexander Gordeev Cc: Tony Luck , Konrad Rzeszutek Wilk , Greg Kroah-Hartman , Joerg Roedel , x86@kernel.org, linux-kernel@vger.kernel.org, linux-acpi@vger.kernel.org, linux-pci@vger.kernel.org, Andrew Morton , linux-arm-kernel@lists.infradead.org List-Id: linux-acpi@vger.kernel.org Hi Gerry, Please see my comments / questions below. On 11/6/14 21:20, Jiang Liu wrote: > Enhance PCI MSI core to support hierarchy irqdomain, so the common > code could be shared among architectures. > > Signed-off-by: Jiang Liu > --- > Hi Thomas, > These changes are a temporary solution, I'm working on another > patch set which will refine these interfaces, especially kill > arch_msi_irq_domain_{set|get}_hwirq(). > Regards! > Gerry Would the change includes the struct irqdomain_msi_data proposed by Thomas here (https://lkml.org/lkml/2014/11/6/210)? > [...] > +static int msi_domain_alloc(struct irq_domain *domain, unsigned int virq, > + unsigned int nr_irqs, void *arg) > +{ > + int i, ret; > + irq_hw_number_t hwirq = arch_msi_irq_domain_get_hwirq(arg); > + > + if (irq_find_mapping(domain, hwirq) > 0) > + return -EEXIST; > + > + ret = irq_domain_alloc_irqs_parent(domain, virq, nr_irqs, arg); > + if (ret < 0) > + return ret; > + When executing irq_domain_alloc_irqs_parent(), it triggers the following warning message due to WARN_ON(desc->irq_data.chip == &no_irq_chip) ------------[ cut here ]------------ WARNING: CPU: 2 PID: 912 at kernel/irq/chip.c:734 __irq_set_handler+0x138/0x13c() Modules linked in: mlx4_core(+) rtc_efi efivarfs CPU: 2 PID: 912 Comm: modprobe Not tainted 3.18.0-rc3-p2v5+ #53 Call trace: [] dump_backtrace+0x0/0x16c [] show_stack+0x10/0x1c [] dump_stack+0x74/0x98 [] warn_slowpath_common+0x84/0xac [] warn_slowpath_null+0x14/0x20 [] __irq_set_handler+0x134/0x13c [] gic_irq_domain_map+0x4c/0xac [] gic_irq_domain_alloc+0x60/0x88 [] gicv2m_domain_alloc+0x30/0xa8 [] __irq_domain_alloc_irqs+0x144/0x30c [] gicv2m_setup_msi_irq+0xc0/0x118 [] arch_setup_msi_irq+0x34/0x60 [] arch_setup_msi_irqs+0x50/0xb0 [] pci_enable_msix+0x310/0x39c [] pci_enable_msix_range+0x34/0x9c .... However, I think if we call irq_domain_set_hwirq_and_chip() in the msi_create_irq_domain() as suggested by Thomas, that should also fix this issue. > + for (i = 0; i < nr_irqs; i++) { > + irq_domain_set_hwirq_and_chip(domain, virq + i, hwirq + i, > + domain->host_data, > + (void *)(long)i); > + __irq_set_handler(virq + i, handle_edge_irq, 0, "edge"); > + } Is there are a way to specify other type of handler besides edge? > [...] > +static void msi_domain_activate(struct irq_domain *domain, > + struct irq_data *irq_data) > +{ > + struct msi_msg msg; > + > + /* > + * irq_data->chip_data is MSI/MSI-X offset. > + * MSI-X message is written per-IRQ, the offset is always 0. > + * MSI message denotes a contiguous group of IRQs, written for 0th IRQ. > + */ > + if (irq_data->chip_data) > + return; Actually, I am a bit confused with this comment here. If you look at "/drivers/pci/msi.c: arch_setup_msi_irq()", it calls irq_set_chip_data(des->irq, chip) where chip is *msi_chip. It looks like if the arch uses this API, it would conflict with what you have here where the irq_data->chip_data would be not NULL at the logic above, and would always return. Thank you, Suravee