linux-kernel - Re: [RFC PATCH V2] acpi/irq: Add stacked IRQ domain support to PCI interrupt link

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 for Android: free password hash cracker in your pocket

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

Date:   Wed, 18 Nov 2020 22:05:29 +0800
From:   Chen Baozi <chenbaozi@...tium.com.cn>
To:     Lorenzo Pieralisi <lorenzo.pieralisi@....com>
Cc:     Marc Zyngier <maz@...nel.org>, Guohanjun <guohanjun@...wei.com>,
        linux-kernel@...r.kernel.org, linux-acpi@...r.kernel.org,
        linux-pci@...r.kernel.org, Bjorn Helgaas <bhelgaas@...gle.com>,
        Ard Biesheuvel <ardb@...nel.org>,
        linux-arm-kernel@...ts.infradead.org
Subject: Re: [RFC PATCH V2] acpi/irq: Add stacked IRQ domain support to PCI
 interrupt link

Hi Lorenzo,

> On Nov 18, 2020, at 5:51 PM, Lorenzo Pieralisi <lorenzo.pieralisi@....com> wrote:
> 
> On Tue, Nov 17, 2020 at 09:42:14PM +0800, Chen Baozi wrote:
>> Some PCIe designs require software to do extra acknowledgements for
>> legacy INTx interrupts. If the driver is written only for device tree,
>> things are simple. In that case, a new driver can be written under
>> driver/pci/controller/ with a DT node of PCIe host written like:
>> 
>>  pcie {
>>    ...
>>    interrupt-map = <0 0 0  1  &pcie_intc 0>,
>>                    <0 0 0  2  &pcie_intc 1>,
>>                    <0 0 0  3  &pcie_intc 2>,
>>                    <0 0 0  4  &pcie_intc 3>;
>> 
>>    pcie_intc: legacy-interrupt-controller {
>>      interrupt-controller;
>>      #interrupt-cells = <1>;
>>      interrupt-parent = <&gic>;
>>      interrupts = <0 226 4>;
>>    };
>>  };
>> 
>> Similar designs can be found on Aardvark, MediaTek Gen2 and Socionext
>> UniPhier PCIe controller at the moment. Essentially, those designs are
>> supported by inserting an extra interrupt controller between PCIe host
>> and GIC and parse the topology in a DT-based PCI controller driver.
>> As we turn to ACPI, All the PCIe hosts are described the same ID of
>> "PNP0A03" and share driver/acpi/pci_root.c. It comes to be a problem
>> to make this kind of PCI INTx work under ACPI.
> 
> In this respect this patch is a minor detail. The major detail is how
> those host controllers are going to probe and initialize with ACPI and I
> am against merging this patch stand alone with no user before
> understanding what you really want to do with those host controller
> drivers in the ACPI world.
> 
> Side note, there is ongoing work for a generic interrupt MUX:
> 
> https://bugzilla.tianocore.org/show_bug.cgi?id=2995
> 
> If we ever come to support those MUXes with ACPI that must be a
> starting point, the binding above can be your first "user".
> 
> I still have reservations about bootstrapping the host controllers
> you mentioned in platforms with no firmware support whatsoever for
> PCI initialization (eg address decoders, link bring-up, etc. - the
> ACPI host bridge model relies on FW to carry out that initialization)
> with ACPI - I would like to see the whole picture first.

Frankly, I’m also waiting for my first “user” to be announced at the moment,
so that I can make the whole picture clearer. And it is why I mark this
patch as an RFC. 

Yes. I admit it is a little weird to add another interrupt controller
between the GIC and INTx device. But if it is not only about
initialization but also about hooking into the INTx processing (e.g.,
introduce an extra ack operation...), it seems we cannot only rely
on FW. I have looked for a FW solution without introducing a new
driver later but failed... I’m happy to be fixed if there is a pure
FW solution.

Thanks.

Baozi.