Received: by 10.223.176.5 with SMTP id f5csp519492wra; Fri, 2 Feb 2018 01:35:29 -0800 (PST) X-Google-Smtp-Source: AH8x224FI3tkOcAxogGYRMUcl15jTpFQEhPmft5LrMO+nG4wbj3x5GsKHMw/XBpAv4QHLF6dLZYr X-Received: by 10.98.71.146 with SMTP id p18mr1719094pfi.3.1517564128892; Fri, 02 Feb 2018 01:35:28 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1517564128; cv=none; d=google.com; s=arc-20160816; b=0m/1EeVL3nYnf39ap755PKX/TOiScRnDOv/YhO3FUPED1I5itjakaHZuwbPBPXKg5i mbTwO/rHGAHOFXfHvnkqYPuL6Yc+y7cM5Dxp7TR+GBorFqsdftR1dLum2h6DL0WpqVgJ hGMoMJCDQ2uXaBqv3pCSu536v4x+HU2W+5uWy33kF4xg6Gz2cB+8c8R+qp8i7a/7gwGN I3pmn/iw0LB6e0wZXRfOvf7pn8oc3qYiGHDGx1KyDTtbSM+fgKvuJXJ2QFwkyFo4bZPo 17gVLqJk9sqe10d4UOMpVA9TOPwZneZ2i+9yAAHcz0eSw5FVtbgniaq+maJye0IqH49d 3xjg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:mime-version:content-transfer-encoding :references:in-reply-to:date:cc:to:from:subject:message-id :arc-authentication-results; bh=tA8swH4X7sCLcvYQBLuKbWXjJrRW+yFmc9zIIVnn6ZQ=; b=yrdtW1EnnhAvnKIrFhxy3KnkfpQSA18xMbLKwehCm9wzesuwFYKKAEKLl11tnOB5cz HVdF8N9XPT0+UpqxNxHhoHbC87skozTgrFjf7o1RYeKlyZBNupgnW7bF9fp+4vWIbSXY Abs6DeKbOoH+WK5Hp3+6lecTirZX4D0NUeoJiZvKAbhD/8ApoMJq45ack7SyqlwGgJkn uj+kH9PoSinww9BYxfVsYmigec2ReqAimvA1q/4W0838jIInx1RozB+AazZlHByL+2HB xlwE+xrxdZHdEyh0Hvkb3JNFGecjtivej7/SNFwKWo+ENkbI7w3a3B16hR/K13Gej+Hn b3dw== ARC-Authentication-Results: i=1; mx.google.com; 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 Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id z8si1167494pgs.605.2018.02.02.01.35.13; Fri, 02 Feb 2018 01:35:28 -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; 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 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751981AbeBBJd6 (ORCPT + 99 others); Fri, 2 Feb 2018 04:33:58 -0500 Received: from mailgw01.mediatek.com ([210.61.82.183]:17520 "EHLO mailgw01.mediatek.com" rhost-flags-OK-FAIL-OK-FAIL) by vger.kernel.org with ESMTP id S1750805AbeBBJc6 (ORCPT ); Fri, 2 Feb 2018 04:32:58 -0500 X-UUID: 783c2ddcd2084a4c82e8cdfc52963c33-20180202 Received: from mtkexhb01.mediatek.inc [(172.21.101.102)] by mailgw01.mediatek.com (envelope-from ) (mhqrelay.mediatek.com ESMTP with TLS) with ESMTP id 1656164961; Fri, 02 Feb 2018 17:32:50 +0800 Received: from mtkcas07.mediatek.inc (172.21.101.84) by mtkmbs01n1.mediatek.inc (172.21.101.68) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Fri, 2 Feb 2018 17:32:50 +0800 Received: from [172.21.77.33] (172.21.77.33) by mtkcas07.mediatek.inc (172.21.101.73) with Microsoft SMTP Server id 15.0.1210.3 via Frontend Transport; Fri, 2 Feb 2018 17:32:50 +0800 Message-ID: <1517563970.24622.9.camel@mtkswgap22> Subject: Re: [PATCH 1/2] of_pci_irq: add a check to fallback to standard device tree parsing From: Ryder Lee To: Rob Herring CC: "open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS" , Lorenzo Pieralisi , Arnd Bergmann , Benjamin Herrenschmidt , "linux-kernel@vger.kernel.org" , , , Bjorn Helgaas , "Frank Rowand" , "moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE" Date: Fri, 2 Feb 2018 17:32:50 +0800 In-Reply-To: References: <31c765c53e85e41bfc001d110d69e46c9967f4e7.1516961656.git.ryder.lee@mediatek.com> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.2.3-0ubuntu6 Content-Transfer-Encoding: 7bit MIME-Version: 1.0 X-MTK: N Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, 2018-01-31 at 10:02 -0600, Rob Herring wrote: > On Wed, Jan 31, 2018 at 1:41 AM, Ryder Lee wrote: > > A root complex usually consist of a host bridge and multiple P2P bridges, > > and someone may express that in the form of a root node with many subnodes > > and list all four interrupts for each slot (child node) in the root node > > like this: > > > > pcie-controller { > > ... > > interrupt-map-mask = <0xf800 0 0 7>; > > interrupt-map = <0x0000 0 0 {INTx} &{interrupt parent} ...> > > 0x0800 0 0 {INTx} &{interrupt parent} ...>; > > > > pcie@0,0 { > > reg = <0x0000 0 0 0 0>; > > ... > > }; > > > > pcie@1,0 { > > reg = <0x0800 0 0 0 0>; > > ... > > }; > > }; > > > > As shown above, we'd like to propagate IRQs from a root port to the devices > > in the hierarchy below it in this way. However, it seems that the current > > parser couldn't handle such cases and will get something unexpected below: > > > > pcieport 0000:00:01.0: assign IRQ: got 213 > > igb 0000:01:00.0: assign IRQ: got 212 > > > > There is a device which is connected to 2nd slot, but the port doesn't share > > the same IRQ with its downstream devices. The problem here is that, if the > > loop found a P2P bridge, it wouldn't check whether the reg property exists > > in ppnode or not but just pass the subordinate devfn to of_irq_parse_raw(), > > thus the subsequent flow couldn't correctly resolve them. > > > > Fix this by adding a check to fallback to standard device tree parsing. > > > > Signed-off-by: Ryder Lee > > --- > > Please refer to the previous discussion thread: https://patchwork.ozlabs.org/patch/829108/ > > --- > > drivers/of/of_pci_irq.c | 14 ++++++++++++-- > > 1 file changed, 12 insertions(+), 2 deletions(-) > > > > diff --git a/drivers/of/of_pci_irq.c b/drivers/of/of_pci_irq.c > > index 3a05568..e445866 100644 > > --- a/drivers/of/of_pci_irq.c > > +++ b/drivers/of/of_pci_irq.c > > @@ -86,8 +86,18 @@ int of_irq_parse_pci(const struct pci_dev *pdev, struct of_phandle_args *out_irq > > out_irq->np = ppnode; > > out_irq->args_count = 1; > > out_irq->args[0] = pin; > > - laddr[0] = cpu_to_be32((pdev->bus->number << 16) | (pdev->devfn << 8)); > > - laddr[1] = laddr[2] = cpu_to_be32(0); > > + > > + if (!dn && ppnode) { > > I would think whether you have a child device in DT or not is > irrelevant. If it's the bridge address you need to look at for > resolving interrupts, that would be true regardless. > > > + const __be32 *addr; > > + > > + addr = of_get_property(ppnode, "reg", NULL); > > + if (addr) > > + memcpy(laddr, addr, 3); > > Can't you just adjust pdev to be ppdev in this case and then use the > existing code to set laddr? Okay, I will try it out and and see if the code gets better or worse. > Please copy the powerpc list on this. I worry that touching this > function will break something. > BTW, this code is moving to drivers/pci/ in 4.16. Sure. I will loop more people in next version. Thanks > _______________________________________________ > Linux-mediatek mailing list > Linux-mediatek@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/linux-mediatek