linux-kernel - Re: [PATCH v6 4/5] PCI: add PCI controller for keystone PCIe h/w

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] [day] [month] [year] [list]

Date:	Tue, 22 Jul 2014 15:00:23 -0400
From:	Murali Karicheri <m-karicheri2@...com>
To:	Rob Herring <robherring2@...il.com>
CC:	Arnd Bergmann <arnd@...db.de>,
	"linux-arm-kernel@...ts.infradead.org" 
	<linux-arm-kernel@...ts.infradead.org>,
	"linux-pci@...r.kernel.org" <linux-pci@...r.kernel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	Russell King <linux@....linux.org.uk>,
	Grant Likely <grant.likely@...aro.org>,
	Rob Herring <robh+dt@...nel.org>,
	Mohit Kumar <mohit.kumar@...com>,
	Jingoo Han <jg1.han@...sung.com>,
	Bjorn Helgaas <bhelgaas@...gle.com>,
	Pratyush Anand <pratyush.anand@...com>,
	Richard Zhu <r65037@...escale.com>,
	Kishon Vijay Abraham I <kishon@...com>,
	Marek Vasut <marex@...x.de>, Pawel Moll <pawel.moll@....com>,
	Mark Rutland <mark.rutland@....com>,
	Ian Campbell <ijc+devicetree@...lion.org.uk>,
	Kumar Gala <galak@...eaurora.org>,
	Randy Dunlap <rdunlap@...radead.org>
Subject: Re: [PATCH v6 4/5] PCI: add PCI controller for keystone PCIe h/w

On 07/22/2014 11:37 AM, Rob Herring wrote:
> On Fri, Jul 18, 2014 at 2:50 PM, Arnd Bergmann<arnd@...db.de>  wrote:
>> On Friday 18 July 2014 14:31:39 Rob Herring wrote:
>>>> +
>>>> + Example:
>>>> +       pcie_msi_intc: msi-interrupt-controller {
>>>> +                       interrupt-controller;
>>>> +                       #interrupt-cells =<1>;
>>>> +                       interrupt-parent =<&gic>;
>>>> +                       interrupts =<GIC_SPI 30 IRQ_TYPE_EDGE_RISING>,
>>>> +<GIC_SPI 31 IRQ_TYPE_EDGE_RISING>,
>>>> +<GIC_SPI 32 IRQ_TYPE_EDGE_RISING>,
>>>> +<GIC_SPI 33 IRQ_TYPE_EDGE_RISING>,
>>>> +<GIC_SPI 34 IRQ_TYPE_EDGE_RISING>,
>>>> +<GIC_SPI 35 IRQ_TYPE_EDGE_RISING>,
>>>> +<GIC_SPI 36 IRQ_TYPE_EDGE_RISING>,
>>>> +<GIC_SPI 37 IRQ_TYPE_EDGE_RISING>;
>>>> +       };
>>>> +
>>>> +pcie_intc: Interrupt controller device node for Legacy irq chip
>>>> +       interrupt-cells: should be set to 1
>>>> +       interrupt-parent: Parent interrupt controller phandle
>>>> +       interrupts: GIC interrupt lines connected to PCI Legacy interrupt lines
>>>> +
>>>> + Example:
>>>> +       pcie_intc: legacy-interrupt-controller {
>>>> +               interrupt-controller;
>>>> +               #interrupt-cells =<1>;
>>>> +               interrupt-parent =<&gic>;
>>>> +               interrupts =<GIC_SPI 26 IRQ_TYPE_EDGE_RISING>,
>>>> +<GIC_SPI 27 IRQ_TYPE_EDGE_RISING>,
>>>> +<GIC_SPI 28 IRQ_TYPE_EDGE_RISING>,
>>>> +<GIC_SPI 29 IRQ_TYPE_EDGE_RISING>;
>>>> +       };
>>> This seems wrong. Legacy interrupts should be described with
>>> interrupt-map and then PCI child devices have a standard interrupt
>>> specifier.
>>>
>>> I'm not sure about MSIs, but I would think they would have a standard
>>> format too.
>>>
>> IIRC, it's actually the correct way to do this here: the problem is that
>> the PCI IRQs are not directly connected to the GIC, but instead there is
>> a nested irqchip that has each PCI IRQ routed to it and that requires
>> an extra EOI for each interrupt.
>>
>> The interrupt-map in the PCI host points to this special irqchip rather
>> than to the GIC.
> Okay, if there is still an interrupt-map property, then I agree. This
> wasn't clear in the example.
Rob,

There is and is described in designware DT documentation. This documentation
refers to that and also describe DT bindings specific to Keystone. Could you
Ack this based on this?

Murali
>
> Rob

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/