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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <CAJZ5v0iML=6Eo0PAeGQeD=0g1QUzgX8-FKOUOCojoT2tNMvYjQ@mail.gmail.com>
Date:   Wed, 18 Nov 2020 14:50:49 +0100
From:   "Rafael J. Wysocki" <rafael@...nel.org>
To:     Ard Biesheuvel <ardb@...nel.org>
Cc:     Bjorn Helgaas <helgaas@...nel.org>,
        Chen Baozi <chenbaozi@...tium.com.cn>,
        Hanjun Guo <guohanjun@...wei.com>,
        Marc Zyngier <maz@...nel.org>,
        Bjorn Helgaas <bhelgaas@...gle.com>,
        ACPI Devel Maling List <linux-acpi@...r.kernel.org>,
        PCI <linux-pci@...r.kernel.org>,
        Linux ARM <linux-arm-kernel@...ts.infradead.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Lorenzo Pieralisi <lorenzo.pieralisi@....com>
Subject: Re: [RFC PATCH V2] acpi/irq: Add stacked IRQ domain support to PCI
 interrupt link

On Wed, Nov 18, 2020 at 2:46 PM Ard Biesheuvel <ardb@...nel.org> wrote:
>
> On Tue, 17 Nov 2020 at 19:57, Bjorn Helgaas <helgaas@...nel.org> wrote:
> >
> > Nit: please don't just make up random styles for the subject.  Run
> > "git log --oneline" on the file and/or the directory and try to follow
> > the existing convention.  Using random styles adds noise to the
> > system.
> >
> > 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.
> >
> > If I understand correctly, we previously ignored the Resource Source
> > field of an Extended Interrupt Descriptor in the _PRS method of
> > PNP0C0F PCI Interrupt Link devices, and this patch adds support for
> > it.
> >
> > If that's true, this has nothing to do with DT, other than DT being
> > another way to describe the same topology, and the above details
> > really aren't relevant to this patch.
> >
> > > 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.
> >
> > s/All the PCIe/all the PCIe/
> >
> > But this paragraph should probably just go away in favor of something
> > about implementing Resource Source support.
> >
> > > Therefore, we introduce an stacked IRQ domain support to PCI interrupt
> > > link for ACPI. With this support, we can populate the ResourceSource
> > > to refer to a device object that describes an interrupt controller.
> > > That would allow us to refer to a dedicated driver which implements
> > > the logic needed to manage the interrupt state. With this patch,
> > > those PCI interrupt links can be supported by describing the INTx
> > > in ACPI table as the following example:
> >
> > "Stacked IRQ domain" sounds like a detail of how you're implementing
> > support for the Resource Source field for PCI Interrupt Links.
> >
> > I don't know what the dedicated driver refers to.  This *should* be
> > all generic code the follows the ACPI spec (which is pretty sketchy in
> > this area).  But I assume that there's no special driver needed for
> > devices like \SB.IXIU, and the logic associated with the interrupt
> > controller is in the AML associated with IXIU.  It would probably be
> > useful to mention the relevant methods in the IXIU methods in the
> > example below.
> >
>
> As I understand it, the intent is to provide a driver for \SB.IXIU
> that acknowledges the legacy INTx interrupts in a SoC specific way,
> and I don't see how AML could be involved here.
>
> That also explains why the routines are exported to modules - the IXIU
> driver could be modularized.

OK, but every new symbol export requires an in-the-tree user or the
patch is basically not applicable.