[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <87sfmyzh4o.wl-maz@kernel.org>
Date: Mon, 18 Jul 2022 14:26:31 +0100
From: Marc Zyngier <maz@...nel.org>
To: Jianmin Lv <lvjianmin@...ngson.cn>
Cc: Robert Moore <robert.moore@...el.com>,
Thomas Gleixner <tglx@...utronix.de>,
linux-kernel@...r.kernel.org, loongarch@...ts.linux.dev,
Hanjun Guo <guohanjun@...wei.com>,
Lorenzo Pieralisi <lorenzo.pieralisi@....com>,
Jiaxun Yang <jiaxun.yang@...goat.com>,
Huacai Chen <chenhuacai@...ngson.cn>
Subject: Re: [PATCH V15 01/15] ACPICA: MADT: Add LoongArch APICs support
On Mon, 18 Jul 2022 13:28:11 +0100,
Jianmin Lv <lvjianmin@...ngson.cn> wrote:
>
>
>
> On 2022/7/17 上午2:10, Marc Zyngier wrote:
> > [+ Robert Moore]
> >
> > On Fri, 15 Jul 2022 08:05:37 +0100,
> > Jianmin Lv <lvjianmin@...ngson.cn> wrote:
> >>
> >> From: Huacai Chen <chenhuacai@...ngson.cn>
> >>
> >> LoongArch-specific interrupt controllers (similar to APIC) are added
> >> in the next revision of ACPI Specification (current revision is 6.4),
> >> which including CORE_PIC (CPUINTC), LIO_PIC (LIOINTC), EIO_PIC (EIOINTC),
> >> HT_PIC (HTVECINTC), BIO_PIC (PCHINTC), LPC_PIC (PCHLPC) and MSI_PIC
> >> (PCHMSI). This patch add their definition.
> >>
> >> ACPI changes of LoongArch-specific interrupt controllers have already
> >> been approved in the ECRs, and will be public in the next revision of
> >> ACPI Specification.
> >>
> >> Reference: https://mantis.uefi.org/mantis/view.php?id=2203
> >> Reference: https://mantis.uefi.org/mantis/view.php?id=2313
> >>
> >> Above links needs login(available for ASWG), so the following link(
> >> the ECR file for adding LoongArch APICs into ACPI spec) is provided
> >> for public:
> >>
> >> https://github.com/lvjianmin-loongson/acpica/blob/master/Add%20APIC%20Structures%20for%20Loongarch%20in%20MADT-rev3.pdf
> >>
> >> Signed-off-by: Jianmin Lv <lvjianmin@...ngson.cn>
> >> Signed-off-by: Huacai Chen <chenhuacai@...ngson.cn>
> >
> > Since the ACPI maintainers are unwilling to take this patch (for
> > undisclosed reasons), we need something to unblock this sorry
> > situation, as I don't think it is fair on the LoongArch folks to be
> > blocked for another cycle on this ground only.
> >
> > I'm proposing to replace this patch with the following, which will
> > allow the patches to be merged without breaking anything. Once the
> > ACPI support is updated, we'll be able to simply revert this patch.
> >
> > Thanks,
> >
> > M.
> >
> > From 43ec25d2dbde3c422cce430c9d5ec32fbe7b255c Mon Sep 17 00:00:00 2001
> > From: Marc Zyngier <maz@...nel.org>
> > Date: Sat, 16 Jul 2022 18:56:10 +0100
> > Subject: [PATCH] LoongArch: Provisionally add ACPICA data structures
> >
> > The LoongArch architecture is using ACPI, but the spec containing
> > the required updates still is in an unreleased state.
> >
> > Instead of preventing the inclusion of the IRQ support into the
> > kernel, add the missing bits to the arch-specific parts of
> > the ACPICA support.
> >
> > Once the ACPICA bits are updated to the version that supports
> > LoongArch, these bits can eventually be removed.
> >
> > Signed-off-by: Marc Zyngier <maz@...nel.org>
> > ---
> > arch/loongarch/include/asm/acpi.h | 138 ++++++++++++++++++++++++++++++
> > 1 file changed, 138 insertions(+)
> >
> > diff --git a/arch/loongarch/include/asm/acpi.h b/arch/loongarch/include/asm/acpi.h
> > index 62044cd5b7bc..6155e46098af 100644
> > --- a/arch/loongarch/include/asm/acpi.h
> > +++ b/arch/loongarch/include/asm/acpi.h
> > @@ -31,6 +31,144 @@ static inline bool acpi_has_cpu_in_madt(void)
> > extern struct list_head acpi_wakeup_device_list;
> > +/*
> > + * Temporary definitions until the core ACPICA code gets updated (see
> > + * 1656837932-18257-1-git-send-email-lvjianmin@...ngson.cn and its
> > + * follow-ups for the "rationale").
> > + *
> > + * Once the "legal reasons" are cleared and that the code is merged,
> > + * this can be dropped entierely.
> > + */
> > +#if (ACPI_CA_VERSION == 0x20220331 && !defined(LOONGARCH_ACPICA_EXT))
> > +
> > +#define LOONGARCH_ACPICA_EXT 1
> > +
> > +#define ACPI_MADT_TYPE_CORE_PIC 17
> > +#define ACPI_MADT_TYPE_LIO_PIC 18
> > +#define ACPI_MADT_TYPE_HT_PIC 19
> > +#define ACPI_MADT_TYPE_EIO_PIC 20
> > +#define ACPI_MADT_TYPE_MSI_PIC 21
> > +#define ACPI_MADT_TYPE_BIO_PIC 22
> > +#define ACPI_MADT_TYPE_LPC_PIC 23
> > +
> > +/* Values for Version field above */
> > +
> > +enum acpi_madt_core_pic_version {
> > + ACPI_MADT_CORE_PIC_VERSION_NONE = 0,
> > + ACPI_MADT_CORE_PIC_VERSION_V1 = 1,
> > + ACPI_MADT_CORE_PIC_VERSION_RESERVED = 2 /* 2 and greater are reserved */
> > +};
> > +
> > +enum acpi_madt_lio_pic_version {
> > + ACPI_MADT_LIO_PIC_VERSION_NONE = 0,
> > + ACPI_MADT_LIO_PIC_VERSION_V1 = 1,
> > + ACPI_MADT_LIO_PIC_VERSION_RESERVED = 2 /* 2 and greater are reserved */
> > +};
> > +
> > +enum acpi_madt_eio_pic_version {
> > + ACPI_MADT_EIO_PIC_VERSION_NONE = 0,
> > + ACPI_MADT_EIO_PIC_VERSION_V1 = 1,
> > + ACPI_MADT_EIO_PIC_VERSION_RESERVED = 2 /* 2 and greater are reserved */
> > +};
> > +
> > +enum acpi_madt_ht_pic_version {
> > + ACPI_MADT_HT_PIC_VERSION_NONE = 0,
> > + ACPI_MADT_HT_PIC_VERSION_V1 = 1,
> > + ACPI_MADT_HT_PIC_VERSION_RESERVED = 2 /* 2 and greater are reserved */
> > +};
> > +
> > +enum acpi_madt_bio_pic_version {
> > + ACPI_MADT_BIO_PIC_VERSION_NONE = 0,
> > + ACPI_MADT_BIO_PIC_VERSION_V1 = 1,
> > + ACPI_MADT_BIO_PIC_VERSION_RESERVED = 2 /* 2 and greater are reserved */
> > +};
> > +
> > +enum acpi_madt_msi_pic_version {
> > + ACPI_MADT_MSI_PIC_VERSION_NONE = 0,
> > + ACPI_MADT_MSI_PIC_VERSION_V1 = 1,
> > + ACPI_MADT_MSI_PIC_VERSION_RESERVED = 2 /* 2 and greater are reserved */
> > +};
> > +
> > +enum acpi_madt_lpc_pic_version {
> > + ACPI_MADT_LPC_PIC_VERSION_NONE = 0,
> > + ACPI_MADT_LPC_PIC_VERSION_V1 = 1,
> > + ACPI_MADT_LPC_PIC_VERSION_RESERVED = 2 /* 2 and greater are reserved */
> > +};
> > +
>
> Hi, Marc, I add #pragma here to make following structures align to 1
> byte as include/acpi/actbl2.h, or else, the MADT will not be parsed
> correctly.
If that's required, please add it.
Thanks,
M.
--
Without deviation from the norm, progress is not possible.
Powered by blists - more mailing lists