[WIP] LoongArch: Add ACPI compatibility for LPC I/O space reservation

[elysia-best]

This patch adds essential compatibility support for ACPI-based systems running on older firmware. Some older computers with Kunlun firmware still rely on this mechanism and are unlikely to receive futher firmeware updates. This change ensures proper LPC I/O space reservation across for them.

[MingcongBai]

Eww. This probably calls for a better (even DMI-specific) quirk...

[xry111]

I don't think this patch can be merged as-is.

Both 7A1000 and 7A2000 manuals state that 0x18000000-0x1800ffff (64K) is for "LPC I/O", but this patch reserves 0x18000000-0x18003fff (16K). The only reference I can find about this 16K range is the 2K1000 ISA controller which is obviously unrelated to any desktop platform. The macro name ("ISA_IOSIZE") also seems something for 2K1000 now.

We need some detailed analysis of the issue and maybe some research on the ACPI specification.

[elysia-best]

Right, a fast search for ISA_IOSIZE shows that this marco was introduced in initial commits for LoongArch support at torvalds@7153c3c

It didn't explain why this marco should be 16K rather than 64K. Additionally, ISA_IOSIZE is also used in loongnix's patch for this issue. I agree that this issue needs more analysis :)

[elysia-best]

Add a DMI check for my tested board. This list can be extended in the futuer if more boards need this workaround.

[xry111]

If the issue isn't limited to BPI system (i.e. also reproducible with the correct UEFI boot process) we expect to make the quirk upstream. Then don't use legacy_boot.c which is not upstream.

I think adding it to arch/loongarch/pci/pci.c as a PCI quirk against some 7A1000/2000 device (which one??¹) would be better. Taking twinhead_reserve_killing_zone() in arch/x86/pci/fixup.c as an example.

Footnotes

1. I considered 0014:7a0c (the LPC controller which is supposed to use this memory range) but it's not enabled on all of my systems (so the PCI enumeration doesn't find it at all). Now I'm actually wondering if the problem is that LPC controller is not really supported by your firmware but it mistakenly enables the controller. Would you kindly prove or disprove my guess by running lspci on your system? ↩

[elysia-best]

running lspci on your system?

Sure, here is the output for that

(ssh)elysia@elysia-loong64-pc [ linux@aosc-6.17.7 ] ! lspci -vvv -s "00:17.0"
00:17.0 ISA bridge: Loongson Technology LLC 2K2000 / 7A1000/2000 Chipset LPC Controller (rev 01)
        Control: I/O+ Mem+ BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
        Status: Cap- 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
        Interrupt: pin A routed to IRQ 255
        NUMA node: 0

[elysia-best]

P.S. Crash log using unpatched kernel is uploaded here panic.log

[MingcongBai]

If the issue isn't limited to BPI system (i.e. also reproducible with the correct UEFI boot process) we expect to make the quirk upstream. Then don't use legacy_boot.c which is not upstream.

I think adding it to arch/loongarch/pci/pci.c as a PCI quirk against some 7A1000/2000 device (which one??1) would be better. Taking twinhead_reserve_killing_zone() in arch/x86/pci/fixup.c as an example.

Footnotes

1. I considered 0014:7a0c (the LPC controller which is supposed to use this memory range) but it's not enabled on all of my systems (so the PCI enumeration doesn't find it at all).  Now I'm actually wondering if the problem is that LPC controller is not really supported by your firmware but it mistakenly enables the controller.  Would you kindly prove or disprove my guess by running lspci on your system? [↩](#user-content-fnref-1-51f062ee28523434e3552b4035399ba3)

Any update on this?

[xry111]

My guess is if the firmware enables LPC, it should describe how it requires this memory range in DSDT like

        Device (LPC)
        {
            Name (_ADR, 0x00170000)  // _ADR: Address (PCI device 17 function 0)
            Name (_CRS, ResourceTemplate ()  // _CRS: Current Resource Settings
            {
                Memory32Fixed (ReadOnly,
                    0x18000000,         // Address Base
                    0x00010000,         // Address Length
                )
            })
        }

Are there any systems where LPC is enabled and AOSC can boot?

[elysia-best]

DSDT-ref.zip
DSDT.zip

Update: by using DSDT-ref, Linux 6.12.54 booted normally. Thus, I guess that there's something wrong with the configuration of IT8786 in DSDT, as the platform where DSDT-ref.zip was taken from did not have this chip.

Note: IT8786 is related to Device UAR1 to 3 and LPT, etc., in the original DSDT.

Edit 2026/3/1: By changing OperationRegion (ITE1, SystemIO, 0x2E, 0x02) to OperationRegion (ITE1, SystemMemory, 0x1800002E, 0x02)，kernel booted normally. This is exactly what this patch have done :(

Edit 2026/3/25: Forgot to upload updated dsdt file.
DSDT-original-patch-systemio.zip

[xry111]

DSDT-ref.zip DSDT.zip

Update: by using DSDT-ref, Linux 6.12.54 booted normally. Thus, I guess that there's something wrong with the configuration of IT8786 in DSDT, as the platform where DSDT-ref.zip was taken from did not have this chip.

Note: IT8786 is related to Device UAR1 to 3 and LPT, etc., in the original DSDT.

We observed this on a 3B6000M board too. Its vendor claims the support of community distro is "value-added service" and so refuses to help.