mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
To: Kishon Vijay Abraham I <kishon@ti.com>
Cc: Murali Karicheri <m-karicheri2@ti.com>,
	Bjorn Helgaas <bhelgaas@google.com>,
	Jingoo Han <jingoohan1@gmail.com>,
	Gustavo Pimentel <gustavo.pimentel@synopsys.com>,
	linux-pci@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
	linux-kernel@vger.kernel.org, marc.zyngier@arm.com
Subject: Re: [PATCH v3 3/9] PCI: keystone: Use hwirq to get the legacy IRQ number offset
Date: Thu, 14 Feb 2019 10:31:38 +0000	[thread overview]
Message-ID: <20190214103138.GA24593@e107981-ln.cambridge.arm.com> (raw)
In-Reply-To: <8028b0e2-ac32-4e36-c87d-6f4818f34301@ti.com>

[CC'ed MarcZ]

On Thu, Feb 14, 2019 at 10:27:19AM +0530, Kishon Vijay Abraham I wrote:
> Hi Lorenzo,
> 
> On 13/02/19 10:27 PM, Lorenzo Pieralisi wrote:
> > On Wed, Feb 13, 2019 at 06:56:23PM +0530, Kishon Vijay Abraham I wrote:
> >> ks_pcie_legacy_irq_handler() uses 'virq' to get the IRQ number offset.
> >> This offset is used to get the correct 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.
> >>
> >> Link: https://lkml.kernel.org/r/bb081d21-7c03-0357-4294-7e92d95d838c@arm.com
> >> Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
> >> ---
> >>  drivers/pci/controller/dwc/pci-keystone.c | 17 +++++++++++++----
> >>  1 file changed, 13 insertions(+), 4 deletions(-)
> >>
> >> diff --git a/drivers/pci/controller/dwc/pci-keystone.c b/drivers/pci/controller/dwc/pci-keystone.c
> >> index e8b1d8eca78e..d35ac712a9f8 100644
> >> --- a/drivers/pci/controller/dwc/pci-keystone.c
> >> +++ b/drivers/pci/controller/dwc/pci-keystone.c
> >> @@ -87,7 +87,7 @@ struct keystone_pcie {
> >>  	struct dw_pcie		*pci;
> >>  	/* PCI Device ID */
> >>  	u32			device_id;
> >> -	int			legacy_host_irqs[PCI_NUM_INTX];
> >> +	int			legacy_host_irq;
> >>  	struct			device_node *legacy_intc_np;
> >>  
> >>  	int			msi_host_irqs[MAX_MSI_HOST_IRQS];
> >> @@ -582,11 +582,11 @@ static void ks_pcie_msi_irq_handler(struct irq_desc *desc)
> >>   */
> >>  static void ks_pcie_legacy_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);
> >>  	struct dw_pcie *pci = ks_pcie->pci;
> >>  	struct device *dev = pci->dev;
> >> -	u32 irq_offset = irq - ks_pcie->legacy_host_irqs[0];
> >> +	u32 irq_offset = irq - ks_pcie->legacy_host_irq;
> > 
> > I think you should use the plain hwirq number (that if I understand
> > correctly range in [0,3]) and drop legacy_host_irq.
> 
> The hwirq is [80, 83] for Keystone. We store legacy_host_irq (for Keystone it
> is 80) to get the correct offset in the range [0, 3].

IIUC the _parent_ hw_irq number should be what you need here, Marc (if
he has time) can correct me if I am wrong (or what I am suggesting is
a violation of IRQ domain bstraction usage).

> > 
> > See below.
> > 
> >>  	struct irq_chip *chip = irq_desc_get_chip(desc);
> >>  
> >>  	dev_dbg(dev, ": Handling legacy irq %d\n", irq);
> >> @@ -657,6 +657,7 @@ static int ks_pcie_config_legacy_irq(struct keystone_pcie *ks_pcie)
> >>  	struct device_node *np = ks_pcie->np;
> >>  	struct device_node *intc_np;
> >>  	int irq_count, irq, ret, i;
> >> +	struct irq_data *irq_data;
> >>  
> >>  	intc_np = of_get_child_by_name(np, "legacy-interrupt-controller");
> >>  	if (!intc_np) {
> >> @@ -677,7 +678,15 @@ static int ks_pcie_config_legacy_irq(struct keystone_pcie *ks_pcie)
> >>  			ret = -EINVAL;
> >>  			goto err;
> >>  		}
> >> -		ks_pcie->legacy_host_irqs[i] = irq;
> >> +
> >> +		if (!ks_pcie->legacy_host_irq) {
> >> +			irq_data = irq_get_irq_data(irq);
> >> +			if (!irq_data) {
> >> +				ret = -EINVAL;
> >> +				goto err;
> >> +			}
> >> +			ks_pcie->legacy_host_irq = irq_data->hwirq;
> > 
> > This depends on DT property ordering and may well be wrong. On top
> > of that as I said above I do not think it is even needed.
> 
> right, it depends on the ordering of the entries in the "interrupts" property.
> Right now we have something like below
> 
>                                interrupts = <GIC_SPI 48 IRQ_TYPE_EDGE_RISING>,
>                                         <GIC_SPI 49 IRQ_TYPE_EDGE_RISING>,
>                                         <GIC_SPI 50 IRQ_TYPE_EDGE_RISING>,
>                                         <GIC_SPI 51 IRQ_TYPE_EDGE_RISING>;
> 
> And changing the order will make legacy_host_irq store the wrong hwirq. With
> this patch we solve the problem of assuming virq to be contiguous for
> contiguous hwirq however we do expect the hwirqs to be populated in the DT in
> the correct order.
> 
> Ordering entries within a property is also followed in other
> properties like "reg" where the drivers use platform_get_resource with
> index as argument. I'm not sure if there's a way to get rid of the
> ordering requirement in DT for the "interrupts" property.

I am not sure there is an ordering requirement in place but hopefully we
should not need it, see above.

The 1:1 relationship between GIC-IRQ<->PCI-host-bridge-controller-IRQ is
what the kernel IRQ domain abstraction is there to implement, so a
reverse look-up should be feasible without adding anything else, lest
we duplicate IRQ domain data structures.

Thanks,
Lorenzo

  reply	other threads:[~2019-02-14 10:31 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-02-13 13:26 [PATCH v3 0/9] PCI: DWC/Keystone: MSI configuration cleanup Kishon Vijay Abraham I
2019-02-13 13:26 ` [PATCH v3 1/9] PCI: keystone: Cleanup interrupt related macros Kishon Vijay Abraham I
2019-02-13 13:26 ` [PATCH v3 2/9] PCI: keystone: Add separate functions for configuring MSI and legacy interrupt Kishon Vijay Abraham I
2019-02-13 13:26 ` [PATCH v3 3/9] PCI: keystone: Use hwirq to get the legacy IRQ number offset Kishon Vijay Abraham I
2019-02-13 16:57   ` Lorenzo Pieralisi
2019-02-14  4:57     ` Kishon Vijay Abraham I
2019-02-14 10:31       ` Lorenzo Pieralisi [this message]
2019-02-14 12:46         ` Marc Zyngier
2019-02-21  9:18         ` Kishon Vijay Abraham I
2019-02-13 13:26 ` [PATCH v3 4/9] PCI: keystone: Use hwirq to get the MSI " Kishon Vijay Abraham I
2019-02-13 13:26 ` [PATCH v3 5/9] PCI: keystone: Cleanup ks_pcie_msi_irq_handler and ks_pcie_legacy_irq_handler Kishon Vijay Abraham I
2019-02-13 13:26 ` [PATCH v3 6/9] PCI: dwc: Add support to use non default msi_irq_chip Kishon Vijay Abraham I
2019-02-13 13:26 ` [PATCH v3 7/9] PCI: keystone: Use Keystone specific msi_irq_chip Kishon Vijay Abraham I
2019-02-13 13:26 ` [PATCH v3 8/9] PCI: dwc: Remove Keystone specific dw_pcie_host_ops Kishon Vijay Abraham I
2019-02-13 13:26 ` [PATCH v3 9/9] PCI: dwc: Do not write to MSI control registers if the platform doesn't use it Kishon Vijay Abraham I

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20190214103138.GA24593@e107981-ln.cambridge.arm.com \
    --to=lorenzo.pieralisi@arm.com \
    --cc=bhelgaas@google.com \
    --cc=gustavo.pimentel@synopsys.com \
    --cc=jingoohan1@gmail.com \
    --cc=kishon@ti.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pci@vger.kernel.org \
    --cc=m-karicheri2@ti.com \
    --cc=marc.zyngier@arm.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®