Received: by 10.223.176.5 with SMTP id f5csp147189wra; Mon, 5 Feb 2018 18:40:48 -0800 (PST) X-Google-Smtp-Source: AH8x227kk1BRP76bwiZTLSKDXXV6fR050FargojLbDPcAyhvnsh/oXrigOPZ8rvWrvwRzxlhF3+2 X-Received: by 10.99.188.2 with SMTP id q2mr687959pge.67.1517884848202; Mon, 05 Feb 2018 18:40:48 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1517884848; cv=none; d=google.com; s=arc-20160816; b=FEd8lHaw2xIsrCSIqosvTQnwHpJI6TfdAWNcY4IKaKx8QLbnEqlWAlzyAy19hI3OY8 Cmk+OTac0/T//kjnuQy2Bbp1iaoDuJ0Ccwb1hdnLoONDTQvenMpsKlVcbBUapxSYyY+y 2FNnEJEyAqowz2EL5HtkXpvAWkhrzOG0idiu17WXvLySBd6as1GccLDBncHlopI6b78M FNCqs5dX2k25XR2qLzQwQZZv4yUNGeW2/FRULSt6oU3R6BzfuSLJ5QnIVguGW62SK7Xf jWPK5Frm9qsnXgBL6/GLNm9afuQJ3LtYwjMr3DgqDBXTcy0ldbnZWew3YSCS+tsTAyuH ydsQ== 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=8D4RAVSSAtrFv5oDjeN7vf6iyp0Vwqp9IYPC+A2H4f4=; b=k7DfQxVSMJZluLPR5HASB7PMSlUlXA5H+s55bHA1te6hU0KmsnW+BzJOetwfNPW79u FFLnm9R6MqCpAJuvTytIcP5l5B4+JWE2WVum0bCIsHZgySj3tgwHpRQB1IKb03Jmpeiy jacmu9UuSaBBZ0FDIi0HqgqmDAscetdrtdh0+L0C4plryLQ+23AqPvcP5axAAx7UVTy3 jPYwESxRyyFozmtvuUCDsCpV+7Mv1PnknrSOQRlr/Gj5UYup8u4ny8dDfh80V3bScveo w7yi3cKiuPtmIcaxaRY9Saz2sA/LC2PIps97QDh1gntSvvLLudt4Xb6gy9uWhlZM4sQh 2icg== 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 g30si2679280pgn.394.2018.02.05.18.40.31; Mon, 05 Feb 2018 18:40:48 -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 S1752493AbeBFCjO (ORCPT + 99 others); Mon, 5 Feb 2018 21:39:14 -0500 Received: from mailgw02.mediatek.com ([210.61.82.184]:3684 "EHLO mailgw02.mediatek.com" rhost-flags-OK-FAIL-OK-FAIL) by vger.kernel.org with ESMTP id S1752141AbeBFCjI (ORCPT ); Mon, 5 Feb 2018 21:39:08 -0500 X-UUID: 12113ef83dfd429e835f985cb5f1107e-20180206 Received: from mtkexhb01.mediatek.inc [(172.21.101.102)] by mailgw02.mediatek.com (envelope-from ) (mhqrelay.mediatek.com ESMTP with TLS) with ESMTP id 1598667747; Tue, 06 Feb 2018 10:38:59 +0800 Received: from mtkcas07.mediatek.inc (172.21.101.84) by mtkmbs02n2.mediatek.inc (172.21.101.101) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Tue, 6 Feb 2018 10:38:58 +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; Tue, 6 Feb 2018 10:38:58 +0800 Message-ID: <1517884738.16010.27.camel@mtkswgap22> Subject: Re: [PATCH 1/2] of_pci_irq: add a check to fallback to standard device tree parsing From: Ryder Lee To: Benjamin Herrenschmidt CC: Rob Herring , "open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS" , Lorenzo Pieralisi , Arnd Bergmann , "linux-kernel@vger.kernel.org" , , , "Bjorn Helgaas" , Frank Rowand , "moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE" Date: Tue, 6 Feb 2018 10:38:58 +0800 In-Reply-To: <1517866584.2312.140.camel@kernel.crashing.org> References: <31c765c53e85e41bfc001d110d69e46c9967f4e7.1516961656.git.ryder.lee@mediatek.com> <1517563970.24622.9.camel@mtkswgap22> <1517866584.2312.140.camel@kernel.crashing.org> 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 Tue, 2018-02-06 at 08:36 +1100, Benjamin Herrenschmidt wrote: > On Fri, 2018-02-02 at 17:32 +0800, Ryder Lee wrote: > > 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. > > I don't really understand the problem explanation here. Something > doesn't look right as you shouldn't have to change that function, but I > just don't get what you a > > Cheers, > Ben. > I think the code should look at the bridge address <0x0800 ...> we list in bindings for resolving interrupts in this case, but it seems like it use the 'pdev->defvn << 8' which is not really we want and will lead to mismatch. interrupt-map-mask = <0xf800 0 0 7>; interrupt-map = <0x0000 0 0 1 ...>, <0x0000 0 0 2 ...>, <0x0000 0 0 3 ...>, <0x0000 0 0 4 ...>, 0x0800 0 0 1 ...>, 0x0800 0 0 2 ...>, 0x0800 0 0 3 ...>, 0x0800 0 0 4 ...>; ... pcie@1,0 { reg = <0x0800 0 0 0 0>; ... }; Or, alternatively, we could add a interrupt-map property in both child and root node to solve this. The below example is my original version as I don't want to change that function either. interrupt-map-mask = <0xf800 0 0 0>; interrupt-map = <0x0000 0 0 0 ...>, 0x0800 0 0 0 ...>; ... pcie@1,0 { reg = <0x0800 0 0 0 0>; #interrupt-cells = <1>; interrupt-map-mask = <0 0 0 0>; interrupt-map = <0 0 0 0 ...>; ... }; However, I can't find any other similar case in documentation. Thanks.