From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754129AbcFPJX1 (ORCPT ); Thu, 16 Jun 2016 05:23:27 -0400 Received: from mout.kundenserver.de ([212.227.126.133]:54478 "EHLO mout.kundenserver.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754000AbcFPJVT convert rfc822-to-8bit (ORCPT ); Thu, 16 Jun 2016 05:21:19 -0400 From: Arnd Bergmann To: Wenrui Li Cc: Shawn Lin , Bjorn Helgaas , Marc Zyngier , linux-pci@vger.kernel.org, linux-kernel@vger.kernel.org, linux-rockchip@lists.infradead.org, Heiko Stuebner , Doug Anderson , Rob Herring , devicetree@vger.kernel.org, Thomas Petazzoni Subject: Re: [PATCH v3 1/2] Documentation: bindings: add dt doc for Rockchip PCIe controller Date: Thu, 16 Jun 2016 11:22:02 +0200 Message-ID: <5324957.LqZqpRHMK9@wuerfel> User-Agent: KMail/5.1.3 (Linux/4.4.0-22-generic; KDE/5.18.0; x86_64; ; ) In-Reply-To: References: <1466041821-1649-1-git-send-email-shawn.lin@rock-chips.com> <5811436.gqkV56Lax5@wuerfel> MIME-Version: 1.0 Content-Transfer-Encoding: 8BIT Content-Type: text/plain; charset="UTF-8" X-Provags-ID: V03:K0:t+uAzCso/JPssR5yHyfIPmV5d73fhLQr78giyh6GMBrFjBhTnnF 9RX7EGbZDuXwx5y2w/NUq1ja0AhkCTOJgdYb+2dgDIyYSG6Kmvfsc8m+zmfCC86neshHSNC gOrS8J2dfYYCmI1ODDVss0iPGC5xttfXguJrIY2HMkXfqFKW12jh8WI/5v/S4CUmjk+nbEL XjVir/wt6QIZryMwsgXXQ== X-UI-Out-Filterresults: notjunk:1;V01:K0:aKyEacMRzhw=:rf088BujdnhNpyBGbTxRTM WPchZy4yKgpb96qW2ug4QClc0s1dnoNy+r3HhLGRayR98Mvuj1ICecwITh3vlEDkhryOXjOop QYfaj5sVyjq/S9FjGsW7nRUx0Ug/yBHAlgyADZ9xVEzl+/XZGqhd3LFLVTx2rU3qSqrmyCs7u r/fRzAas/xmlbbEucubCMQbQsmX4CodY/soCkypYw3PW5Jxc1QxUWjPgpg2Uc6ZB/WLPSMcok 8Dl4bfurAlTgKxeUI7kSFgyNlbJdF8/X0h16NGzHB8i+Xi1Iq3Qbu72BEx3rjdGp1S9ehWla7 pHpH+LvJRd9znF2Fe3lrOW9rantqIIjwU7fJJyVcv/1+SFAwneZaE1lOzUZPBuwnzdN0Xy3eZ pRSfeSmZla2thTHDH22qtwT6Pq2KThsJs3Jvkh/wzRS6JPmDJKKxo8SaBbylo/xyUHbr/sVMv 3i2P3y/Z1QYArOc62B4SgMlwOWMiTsnr10FWpit97kpjUHlFIDEtFK28z7rNuFy1rZ56OQ4y3 YmxZ3uR2d8vlt4rzjCXXLMMmvfqNHGL+UVu5jxVfmDaL7me8asvTqVYXxPusJsadmUfXhmx0Q VxOM+ySHiD2E77IvayEest1j5IOdH3+MykSK0EK2AF/02BDcfViVB4WZKZ+DMaOBgSR6Ideb0 7rEAs0vLbERbH/N5gwnbCg80T3lV5yH9zANMuMM52YMMao3o5tLw30VHNxS1aT+jnPq1lKvNc wsP3tUrStjamu0r3 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thursday, June 16, 2016 4:01:12 PM CEST Wenrui Li wrote: > 在 2016/6/16 15:00, Arnd Bergmann 写道: > > On Thursday, June 16, 2016 9:50:21 AM CEST Shawn Lin wrote: > > > >> + reset-names = "core", "mgmt", "mgmt-sticky", "pipe"; > >> + phys = <&pcie_phy>; > >> + phy-names = "pcie-phy"; > >> + pinctrl-names = "default"; > >> + pinctrl-0 = <&pcie_clkreq>; > >> + #interrupt-cells = <1>; > >> + interrupt-controller; > >> + interrupt-map-mask = <0 0 0 7>; > >> + interrupt-map = <0 0 0 1 &pcie0 1>, > >> + <0 0 0 2 &pcie0 2>, > >> + <0 0 0 3 &pcie0 3>, > >> + <0 0 0 4 &pcie0 4>; > >> +}; > >> > > > > One thing that came up in the review of the new Marvell PCIe driver is that it's > > most likely invalid for a device node to have both "interrupt-controller" > > and "interrupt-map" properties. I originally thought this was a nice way to > > handle embedded irqchips within the PCIe host, but it only really works > > by coincidence with the current kernel, and only as long as the hwirq number > > of the irqchip matches the integer representation of the irq line in the root > > bridge (which it does in the example above). > > > > For that driver we concluded that it would be less of a hack to have the > > irqchip as a child node of the PCIe host after all (just not with > > device_type="pci" of course), and that makes the translation work as > > expected. > > > > Arnd > > > > Original driver have an irqchip as child node. But Marc suggested don't > need an intermediate node here. > Now the conclusion is to retain the child node? That is at least my view of the situation, sorry for the mixed messages you have been getting. Marc, Rob, do you agree with my finding? If we want to allow having both interrupt-map and interrupt-controller in the same node, we need to rewrite both the irq parsing function and have extend the DT binding for the interrupt-map to explain what we actually expect to happen in that case. At the moment, we walk up the tree until we find either an interrupt-map or an interrupt-controller property, and use that to map the interrupt number. If we find an interrupt-controller, we ignore the interrupt-map. Arnd