Received: by 2002:ac0:946b:0:0:0:0:0 with SMTP id j40csp237154imj; Thu, 7 Feb 2019 03:35:17 -0800 (PST) X-Google-Smtp-Source: AHgI3IaGuCdYhcp8naaLs6vkaNZTqyTczHmaZJQFVxJhEf7alDct/5x1XrVgHw+4krhuaizYHcDh X-Received: by 2002:a63:eb0c:: with SMTP id t12mr13939305pgh.105.1549539317660; Thu, 07 Feb 2019 03:35:17 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1549539317; cv=none; d=google.com; s=arc-20160816; b=YZO3BlincpEyTFy08B5+hjY6+EVwWERl6xwxJeqvR/hT6D/SeMI6WMkYED5W96mgE0 SDY5fLtywDh3mzap7bOACzeS10gvmV/Q1SKLJOyQ8CoT/5Wvq6mO0hnu/nmB+aIr+DF9 zSYQHXL7woBN0vpvgKX7dHZkS8EJb5xVKbuOjWaey2sfPweG4PB8O41BFcdheE+GZM4z 9/4AHGAUbQithenrgO6k2s2wNoq1acVDomS9NC/wVbZR3b+Y82o3P72pXbk5OoMXptdz 6pRGAEp5YQj8w+Lc6kxmpzN+/tZRJBcHL4UYbjDFylYdKP+wcH4uk23mqUuQVBVfkeYH fULQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:dkim-signature; bh=hDnQR6WIzJqxZvFm5EvH1nkw9aQ+DyUIIB3b8SxGyWA=; b=fq4XChDjFlaZwYDHoCHmZZc8P6qB8ycX/8pGK/7sXdmUcrFwnc6421V/OLinBvzIS4 W0NMwTAL7+9H9NQkW+ZDda7VcMPX3z3SvUGkig2N8/sX1oqBjxfbgHCaHw+Kb3PtkikB u1LjnL0RPuTOD8cjIepOmI2iAl2RB+U7jZ2GAfxMX7GTtQBS2/uPReh5w6QyYGM6UWAl Gpw6qU5cTaclia0KwhQlD94Ssrv/7DAk9g4kc2gyAapFzvNPqTfe/2SGOfe4bx2HWXni ciQR2o0uIsn7uZuhTy9vQKeC9L7D+of+styQOo9Rft/2RrVRIi+iErxMVA7+QmOGQy5V P3iw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@ti.com header.s=ti-com-17Q1 header.b=Fx7uHaxw; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=QUARANTINE sp=NONE dis=NONE) header.from=ti.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id m14si8544997pgd.326.2019.02.07.03.35.01; Thu, 07 Feb 2019 03:35:17 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@ti.com header.s=ti-com-17Q1 header.b=Fx7uHaxw; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=QUARANTINE sp=NONE dis=NONE) header.from=ti.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727058AbfBGLcf (ORCPT + 99 others); Thu, 7 Feb 2019 06:32:35 -0500 Received: from lelv0142.ext.ti.com ([198.47.23.249]:46048 "EHLO lelv0142.ext.ti.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726579AbfBGLc2 (ORCPT ); Thu, 7 Feb 2019 06:32:28 -0500 Received: from lelv0265.itg.ti.com ([10.180.67.224]) by lelv0142.ext.ti.com (8.15.2/8.15.2) with ESMTP id x17BWFwV030934; Thu, 7 Feb 2019 05:32:15 -0600 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ti.com; s=ti-com-17Q1; t=1549539135; bh=hDnQR6WIzJqxZvFm5EvH1nkw9aQ+DyUIIB3b8SxGyWA=; h=From:To:CC:Subject:Date:In-Reply-To:References; b=Fx7uHaxwY8cTuhb0luiuIft+GR057u2kiD9kJurFsoD+dvnAhuF20392/asVBsQHQ G7oOu3CRqfWfkLWtuen7zDMtDmVzT7ZgAyzPiXjRvfwdZoq9fZcKSxcck9QHKinzAZ +wMJO9JgQ7X0vny9UhsU3y5wrVMSB+pDlp49yv2k= Received: from DLEE109.ent.ti.com (dlee109.ent.ti.com [157.170.170.41]) by lelv0265.itg.ti.com (8.15.2/8.15.2) with ESMTPS id x17BWFB2017077 (version=TLSv1.2 cipher=AES256-GCM-SHA384 bits=256 verify=FAIL); Thu, 7 Feb 2019 05:32:15 -0600 Received: from DLEE111.ent.ti.com (157.170.170.22) by DLEE109.ent.ti.com (157.170.170.41) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1591.10; Thu, 7 Feb 2019 05:32:15 -0600 Received: from dflp32.itg.ti.com (10.64.6.15) by DLEE111.ent.ti.com (157.170.170.22) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_RSA_WITH_AES_256_CBC_SHA) id 15.1.1591.10 via Frontend Transport; Thu, 7 Feb 2019 05:32:15 -0600 Received: from a0393678ub.india.ti.com (ileax41-snat.itg.ti.com [10.172.224.153]) by dflp32.itg.ti.com (8.14.3/8.13.8) with ESMTP id x17BVxao026282; Thu, 7 Feb 2019 05:32:12 -0600 From: Kishon Vijay Abraham I To: Murali Karicheri , Lorenzo Pieralisi CC: Kishon Vijay Abraham I , Bjorn Helgaas , Jingoo Han , Gustavo Pimentel , , , Subject: [PATCH v2 4/9] PCI: keystone: Use hwirq to get the IRQ number offset Date: Thu, 7 Feb 2019 16:39:19 +0530 Message-ID: <20190207110924.30716-5-kishon@ti.com> X-Mailer: git-send-email 2.17.1 In-Reply-To: <20190207110924.30716-1-kishon@ti.com> References: <20190207110924.30716-1-kishon@ti.com> MIME-Version: 1.0 Content-Type: text/plain X-EXCLAIMER-MD-CONFIG: e1e8a2fd-e40a-4ac6-ac9b-f7e9cc9ee180 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org ks_pcie_msi_irq_handler() uses 'virq' to get the IRQ number offset. This offset is used to get the correct MSI_IRQ_STATUS register corresponding to the IRQ line that raised the interrupt. There is no guarantee that 'virq' assigned for consecutive hardware IRQ will be contiguous. And this might get us an incorrect IRQ number offset. Fix it here by using 'hwirq' to get the IRQ number offset. Since we don't store the 'virq' numbers of all the IRQ numbers, stop checking if irq count is greater than MAX_MSI_HOST_IRQS and remove MAX_MSI_HOST_IRQS. Link: https://lkml.kernel.org/r/bb081d21-7c03-0357-4294-7e92d95d838c@arm.com Signed-off-by: Kishon Vijay Abraham I --- drivers/pci/controller/dwc/pci-keystone.c | 24 ++++++++++++----------- 1 file changed, 13 insertions(+), 11 deletions(-) diff --git a/drivers/pci/controller/dwc/pci-keystone.c b/drivers/pci/controller/dwc/pci-keystone.c index b1d01751c1af..a404fad12bdf 100644 --- a/drivers/pci/controller/dwc/pci-keystone.c +++ b/drivers/pci/controller/dwc/pci-keystone.c @@ -74,7 +74,6 @@ #define ERR_IRQ_ALL (ERR_AER | ERR_AXI | ERR_CORR | \ ERR_NONFATAL | ERR_FATAL | ERR_SYS) -#define MAX_MSI_HOST_IRQS 8 /* PCIE controller device IDs */ #define PCIE_RC_K2HK 0xb008 #define PCIE_RC_K2E 0xb009 @@ -89,7 +88,7 @@ struct keystone_pcie { u32 device_id; struct device_node *legacy_intc_np; - int msi_host_irqs[MAX_MSI_HOST_IRQS]; + int msi_host_irq; int num_lanes; u32 num_viewport; struct phy **phy; @@ -547,9 +546,9 @@ static int ks_pcie_establish_link(struct keystone_pcie *ks_pcie) static void ks_pcie_msi_irq_handler(struct irq_desc *desc) { - unsigned int irq = irq_desc_get_irq(desc); + unsigned int irq = desc->irq_data.hwirq; struct keystone_pcie *ks_pcie = irq_desc_get_handler_data(desc); - u32 offset = irq - ks_pcie->msi_host_irqs[0]; + u32 offset = irq - ks_pcie->msi_host_irq; struct dw_pcie *pci = ks_pcie->pci; struct device *dev = pci->dev; struct irq_chip *chip = irq_desc_get_chip(desc); @@ -607,6 +606,7 @@ static int ks_pcie_config_msi_irq(struct keystone_pcie *ks_pcie) struct device *dev = ks_pcie->pci->dev; struct device_node *np = ks_pcie->np; struct device_node *intc_np; + struct irq_data *irq_data; int irq_count; int irq; int ret; @@ -628,19 +628,21 @@ static int ks_pcie_config_msi_irq(struct keystone_pcie *ks_pcie) goto err; } - if (irq_count > MAX_MSI_HOST_IRQS) { - dev_warn(dev, "Too many MSI interrupt lines defined %u\n", - irq_count); - irq_count = MAX_MSI_HOST_IRQS; - } - for (i = 0; i < irq_count; i++) { irq = irq_of_parse_and_map(intc_np, i); if (!irq) { ret = -EINVAL; goto err; } - ks_pcie->msi_host_irqs[i] = irq; + + if (!ks_pcie->msi_host_irq) { + irq_data = irq_get_irq_data(irq); + if (!irq_data) { + ret = -EINVAL; + goto err; + } + ks_pcie->msi_host_irq = irq_data->hwirq; + } irq_set_chained_handler_and_data(irq, ks_pcie_msi_irq_handler, ks_pcie); -- 2.17.1