linux-kernel - Re: [PATCH V8 02/10] irqchip/loongson-pch-pic: Add ACPI init support

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: <CAAhV-H6VFaRtiyhgq-vDQPUbiAtf9L1M6ZNyeApTu11O9JCXnw@mail.gmail.com>
Date:   Fri, 24 Dec 2021 15:31:53 +0800
From:   Huacai Chen <chenhuacai@...il.com>
To:     Marc Zyngier <maz@...nel.org>
Cc:     Huacai Chen <chenhuacai@...ngson.cn>,
        Thomas Gleixner <tglx@...utronix.de>,
        LKML <linux-kernel@...r.kernel.org>,
        Xuefeng Li <lixuefeng@...ngson.cn>,
        Jiaxun Yang <jiaxun.yang@...goat.com>
Subject: Re: [PATCH V8 02/10] irqchip/loongson-pch-pic: Add ACPI init support

Hi, Marc,

On Mon, Dec 20, 2021 at 8:13 PM Marc Zyngier <maz@...nel.org> wrote:
>
> On Fri, 17 Dec 2021 04:45:24 +0000,
> Huacai Chen <chenhuacai@...il.com> wrote:
> >
> > Hi, Marc,
> >
> > On Thu, Dec 16, 2021 at 11:06 PM Marc Zyngier <maz@...nel.org> wrote:
> > >
> > > On Thu, 16 Dec 2021 12:53:48 +0000,
> > > Huacai Chen <chenhuacai@...ngson.cn> wrote:
> > > >
> > > > We are preparing to add new Loongson (based on LoongArch, not compatible
> > > > with old MIPS-based Loongson) support. LoongArch use ACPI other than DT
> > > > as its boot protocol, so add ACPI init support.
> > > >
> > > > PCH-PIC/PCH-MSI stands for "Interrupt Controller" that described in
> > > > Section 5 of "Loongson 7A1000 Bridge User Manual". For more information
> > > > please refer Documentation/loongarch/irq-chip-model.rst.
> > > >
> > > > Signed-off-by: Huacai Chen <chenhuacai@...ngson.cn>
> > > > ---
> > > >  drivers/irqchip/irq-loongson-pch-pic.c | 108 ++++++++++++++++++-------
> > > >  1 file changed, 81 insertions(+), 27 deletions(-)
> > >
> > > [...]
> > >
> > > >
> > > > +#ifdef CONFIG_ACPI
> > > > +
> > > > +struct irq_domain *pch_pic_acpi_init(struct irq_domain *parent,
> > > > +                                     struct acpi_madt_bio_pic *acpi_pchpic)
> > >
> > > Who is calling this? This works the opposite way from what the arm64
> > > irqchips are doing. Why? I have the ugly feeling that this is called
> > > from the arch code, bypassing the existing infrastructure...
> > Yes, this is called from the arch code and a bit ugly, but I can't
> > find a better way to do this.
> >
> > Is the "existing infrastructure" declare the irqchip init function
> > with  IRQCHIP_ACPI_DECLARE and the arch code only need to call
> > irqchip_init()? Then we have a problem: our irqchips have a 4 level
> > hierachy and the parent should be initialized before its children. In
> > FDT world this is not a problem, because of_irq_init() will sort
> > irqchip drivers to ensure the right order. But in ACPI world,
> > acpi_probe_device_table just call init functions in the linking order.
> > If we want to control the order, it seems we can only sort the drivers
> > in drivers/irq/Makefile. But I don't think this is a good idea...
> >
> > If there are better solutions, please let me know. Thanks.
>
> We have the exact same thing on the arm64 side, and we don't need of
> this to be arch specific:
>
> - The MADT table describes the root interrupt controller, and it is
>   probed via IRQCHIP_ACPI_DECLARE().
>
> - Each children controller is declared in ACPI as a *device*, and is
>   both an interrupt producer and an interrupt consumer. Normal probe
>   deferral rules apply. See irq-mbigen.c for an example of how this is
>   done.
Thank you for your suggestions, I have tried but failed. It seems
there are some differences between irq-mbigen.c and our irqchips.
Because our irqchips are mandatory while mbigen is optional. If we
declare our irqchips as devices, they are initialized in the initcall
phase, which is too late for pci devices.

Huacai

>
> With that, you can remove all the probing order management from your
> arch code and let the standard Linux driver model take over.
>
>         M.
>
> --
> Without deviation from the norm, progress is not possible.