linux-kernel - Re: [PATCH v3 1/2] Documentation: bindings: add dt doc for Rockchip PCIe controller

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <da207bdc-738f-f2b1-7026-e368355936e9@rock-chips.com>
Date:	Thu, 16 Jun 2016 16:01:12 +0800
From:	Wenrui Li <wenrui.li@...k-chips.com>
To:	Arnd Bergmann <arnd@...db.de>, Shawn Lin <shawn.lin@...k-chips.com>
Cc:	Bjorn Helgaas <bhelgaas@...gle.com>,
	Marc Zyngier <marc.zyngier@....com>, linux-pci@...r.kernel.org,
	linux-kernel@...r.kernel.org, linux-rockchip@...ts.infradead.org,
	Heiko Stuebner <heiko@...ech.de>,
	Doug Anderson <dianders@...omium.org>,
	Rob Herring <robh+dt@...nel.org>, devicetree@...r.kernel.org,
	Thomas Petazzoni <thomas.petazzoni@...e-electrons.com>
Subject: Re: [PATCH v3 1/2] Documentation: bindings: add dt doc for Rockchip
 PCIe controller



在 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?

>
>