[PATCH RFC] gpio: loongson-64bit: Add back the support for gsi_idx_map

[PATCH RFC] gpio: loongson-64bit: Add back the support for gsi_idx_map

[Miao Wang via B4 Relay]

From: Miao Wang <shankerwangmiao@gmail.com>

This patch adds back the support for gsi_idx_map, which is used in the
ACPI DSDT table to describe the mapping between the GPIO line number to
the index of the interrupt number in the declared interrupt resources.

This property was removed in Loongson CPU Universal Specification for
Interface Between PC/Server System Firmware and Kernel v4.1 in November,
2023, but still in use in firmwares released this year. A sample of
an affected DSDT entry from a 3C6000 board I'm currently using is:

Device (GPO1) {
  Name (_HID, "LOON000F")
  Name (_CRS, ResourceTemplate () {
    QWordMemory ( // Omitted, not related
    )
    Interrupt (ResourceConsumer, Level, ActiveHigh, Exclusive, ,, ) {
      0x00000010, 0x00000011, 0x00000012, 0x00000013,
      0x00000014, 0x00000015, 0x00000016, 0x00000017,
    }
  Name (_DSD, Package (0x02) {
    ToUUID ("daffd814-6eba-4d8c-8a91-bc9bbf4aa301")
    Package (0x03) {
      Package (0x02) { "gpio_base", 0x50 } // Ignored by the driver
      Package (0x02) { "ngpios", 0x20 }
      Package (0x02) { "gsi_idx_map", Package (0x20) {
        0, 1, 2, 3, 4, 5, 6, 7,
        0, 1, 2, 3, 4, 5, 6, 7,
        0, 1, 2, 3, 4, 5, 6, 7,
        0, 1, 2, 3, 4, 5, 6, 7,
      }}
    }
  }
}

As can be seen in the DSDT entry, the mapping is essential for obtaining
the IRQ number from a GPIO line number. Otherwise, when IRQ is requested
for the line numbers largers than 7, it will fail with -ENXIO.

The code in this patch is mostly picked from the version 5 of Yinbo's
original patch.

Fixes: 7944d3b7fe86 ("gpio: loongson: add gpio driver support")
Signed-off-by: Miao Wang <shankerwangmiao@gmail.com>
---
 drivers/gpio/gpio-loongson-64bit.c | 25 +++++++++++++++++++++++++
 1 file changed, 25 insertions(+)

diff --git a/drivers/gpio/gpio-loongson-64bit.c b/drivers/gpio/gpio-loongson-64bit.c
index 0fdf15faa344d2db0a1cf52dc52c3f58aabef49c..bff7d70e7470ea930ba29504533f11fa92e17620 100644
--- a/drivers/gpio/gpio-loongson-64bit.c
+++ b/drivers/gpio/gpio-loongson-64bit.c
@@ -46,6 +46,8 @@ struct loongson_gpio_chip {
 	spinlock_t		lock;
 	void __iomem		*reg_base;
 	const struct loongson_gpio_chip_data *chip_data;
+	u16			*gsi_idx_map;
+	int			mapsize;
 };
 
 static inline struct loongson_gpio_chip *to_loongson_gpio_chip(struct gpio_chip *chip)
@@ -145,6 +147,12 @@ static int loongson_gpio_to_irq(struct gpio_chip *chip, unsigned int offset)
 		writeb(1, lgpio->reg_base + lgpio->chip_data->inten_offset + offset);
 	}
 
+	if (lgpio->gsi_idx_map != NULL) {
+		if (offset >= lgpio->mapsize)
+			return -EINVAL;
+		offset = lgpio->gsi_idx_map[offset];
+	}
+
 	return platform_get_irq(pdev, offset);
 }
 
@@ -326,6 +334,23 @@ static int loongson_gpio_init(struct platform_device *pdev, struct loongson_gpio
 		lgpio->chip.gc.to_irq = loongson_gpio_to_irq;
 	}
 
+	lgpio->mapsize = device_property_read_u16_array(&pdev->dev, "gsi_idx_map", NULL, 0);
+	if (lgpio->mapsize > 0) {
+		lgpio->gsi_idx_map = devm_kcalloc(&pdev->dev, lgpio->mapsize,
+						  sizeof(*lgpio->gsi_idx_map), GFP_KERNEL);
+		if (!lgpio->gsi_idx_map)
+			return -ENOMEM;
+
+		ret = device_property_read_u16_array(&pdev->dev, "gsi_idx_map",
+						     lgpio->gsi_idx_map, lgpio->mapsize);
+		if (ret != 0)
+			return dev_err_probe(&pdev->dev, ret, "failed to read gsi_idx_map\n");
+		dev_warn(&pdev->dev, "gsi_idx_map property is deprecated, consider upgrading your firmware\n");
+	} else {
+		lgpio->gsi_idx_map = NULL;
+		lgpio->mapsize = 0;
+	}
+
 	return devm_gpiochip_add_data(&pdev->dev, &lgpio->chip.gc, lgpio);
 }
 

---
base-commit: 4edcdefd4083ae04b1a5656f4be6cd83ae919ef4
change-id: 20260630-loongson-gpio-090bb159d0e4

Best regards,
-- 
Miao Wang <shankerwangmiao@gmail.com>

Re: [PATCH RFC] gpio: loongson-64bit: Add back the support for gsi_idx_map

[Bartosz Golaszewski]

On Mon, 29 Jun 2026 23:05:28 +0200, Miao Wang via B4 Relay
<devnull+shankerwangmiao.gmail.com@kernel.org> said:
> From: Miao Wang <shankerwangmiao@gmail.com>
>
> This patch adds back the support for gsi_idx_map, which is used in the
> ACPI DSDT table to describe the mapping between the GPIO line number to
> the index of the interrupt number in the declared interrupt resources.
>
> This property was removed in Loongson CPU Universal Specification for
> Interface Between PC/Server System Firmware and Kernel v4.1 in November,
> 2023, but still in use in firmwares released this year. A sample of
> an affected DSDT entry from a 3C6000 board I'm currently using is:
>
> Device (GPO1) {
>   Name (_HID, "LOON000F")
>   Name (_CRS, ResourceTemplate () {
>     QWordMemory ( // Omitted, not related
>     )
>     Interrupt (ResourceConsumer, Level, ActiveHigh, Exclusive, ,, ) {
>       0x00000010, 0x00000011, 0x00000012, 0x00000013,
>       0x00000014, 0x00000015, 0x00000016, 0x00000017,
>     }
>   Name (_DSD, Package (0x02) {
>     ToUUID ("daffd814-6eba-4d8c-8a91-bc9bbf4aa301")
>     Package (0x03) {
>       Package (0x02) { "gpio_base", 0x50 } // Ignored by the driver
>       Package (0x02) { "ngpios", 0x20 }
>       Package (0x02) { "gsi_idx_map", Package (0x20) {
>         0, 1, 2, 3, 4, 5, 6, 7,
>         0, 1, 2, 3, 4, 5, 6, 7,
>         0, 1, 2, 3, 4, 5, 6, 7,
>         0, 1, 2, 3, 4, 5, 6, 7,
>       }}
>     }
>   }
> }
>
> As can be seen in the DSDT entry, the mapping is essential for obtaining
> the IRQ number from a GPIO line number. Otherwise, when IRQ is requested
> for the line numbers largers than 7, it will fail with -ENXIO.
>
> The code in this patch is mostly picked from the version 5 of Yinbo's
> original patch.
>
> Fixes: 7944d3b7fe86 ("gpio: loongson: add gpio driver support")
> Signed-off-by: Miao Wang <shankerwangmiao@gmail.com>

Cc'ing ACPI GPIO maintainers.

Bart

Re: [PATCH RFC] gpio: loongson-64bit: Add back the support for gsi_idx_map

[Andy Shevchenko]

On Tue, Jun 30, 2026 at 07:45:52AM +0000, Bartosz Golaszewski wrote:
> On Mon, 29 Jun 2026 23:05:28 +0200, Miao Wang via B4 Relay
> <devnull+shankerwangmiao.gmail.com@kernel.org> said:

> > This patch adds back the support for gsi_idx_map, which is used in the
> > ACPI DSDT table to describe the mapping between the GPIO line number to
> > the index of the interrupt number in the declared interrupt resources.
> >
> > This property was removed in Loongson CPU Universal Specification for
> > Interface Between PC/Server System Firmware and Kernel v4.1 in November,
> > 2023, but still in use in firmwares released this year. A sample of
> > an affected DSDT entry from a 3C6000 board I'm currently using is:

Oh my gosh, can somebody actually try to consult first with the Linux kernel
developers before adding non-standard and wrongly named properties, please?

> > Device (GPO1) {
> >   Name (_HID, "LOON000F")
> >   Name (_CRS, ResourceTemplate () {
> >     QWordMemory ( // Omitted, not related
> >     )
> >     Interrupt (ResourceConsumer, Level, ActiveHigh, Exclusive, ,, ) {
> >       0x00000010, 0x00000011, 0x00000012, 0x00000013,
> >       0x00000014, 0x00000015, 0x00000016, 0x00000017,
> >     }
> >   Name (_DSD, Package (0x02) {
> >     ToUUID ("daffd814-6eba-4d8c-8a91-bc9bbf4aa301")
> >     Package (0x03) {
> >       Package (0x02) { "gpio_base", 0x50 } // Ignored by the driver

Yes, it's non-standard property. It's a broken one in terms of the style.
See DT binding documentation.

> >       Package (0x02) { "ngpios", 0x20 }
> >       Package (0x02) { "gsi_idx_map", Package (0x20) {
> >         0, 1, 2, 3, 4, 5, 6, 7,
> >         0, 1, 2, 3, 4, 5, 6, 7,
> >         0, 1, 2, 3, 4, 5, 6, 7,
> >         0, 1, 2, 3, 4, 5, 6, 7,
> >       }}
> >     }
> >   }
> > }
> >
> > As can be seen in the DSDT entry, the mapping is essential for obtaining
> > the IRQ number from a GPIO line number. Otherwise, when IRQ is requested
> > for the line numbers largers than 7, it will fail with -ENXIO.

This doesn't look good. Why can't we simply hardcode the proper behaviour based
on the _HID? The gsi_idx_map seems quite regular and periodic, do you have some
other examples with different mapping?

> > The code in this patch is mostly picked from the version 5 of Yinbo's
> > original patch.

> Cc'ing ACPI GPIO maintainers.

Thanks, Bart!

-- 
With Best Regards,
Andy Shevchenko

Re: [PATCH RFC] gpio: loongson-64bit: Add back the support for gsi_idx_map

[Miao Wang]

> 2026年6月30日 20:07，Andy Shevchenko <andriy.shevchenko@linux.intel.com> 写道：
> 
> On Tue, Jun 30, 2026 at 07:45:52AM +0000, Bartosz Golaszewski wrote:
>> On Mon, 29 Jun 2026 23:05:28 +0200, Miao Wang via B4 Relay
>> <devnull+shankerwangmiao.gmail.com@kernel.org> said:
> 
>>> This patch adds back the support for gsi_idx_map, which is used in the
>>> ACPI DSDT table to describe the mapping between the GPIO line number to
>>> the index of the interrupt number in the declared interrupt resources.
>>> 
>>> This property was removed in Loongson CPU Universal Specification for
>>> Interface Between PC/Server System Firmware and Kernel v4.1 in November,
>>> 2023, but still in use in firmwares released this year. A sample of
>>> an affected DSDT entry from a 3C6000 board I'm currently using is:
> 
> Oh my gosh, can somebody actually try to consult first with the Linux kernel
> developers before adding non-standard and wrongly named properties, please?

Inferred from the time when gsi_idx_map was removed from the spec, I believe
that the removal might be because the maintainers suggestion against introducing
gsi_idx_map. However, the firmwares "in the wild" have not followed the change.

>>> Device (GPO1) {
>>>  Name (_HID, "LOON000F")
>>>  Name (_CRS, ResourceTemplate () {
>>>    QWordMemory ( // Omitted, not related
>>>    )
>>>    Interrupt (ResourceConsumer, Level, ActiveHigh, Exclusive, ,, ) {
>>>      0x00000010, 0x00000011, 0x00000012, 0x00000013,
>>>      0x00000014, 0x00000015, 0x00000016, 0x00000017,
>>>    }
>>>  Name (_DSD, Package (0x02) {
>>>    ToUUID ("daffd814-6eba-4d8c-8a91-bc9bbf4aa301")
>>>    Package (0x03) {
>>>      Package (0x02) { "gpio_base", 0x50 } // Ignored by the driver
> 
> Yes, it's non-standard property. It's a broken one in terms of the style.
> See DT binding documentation.

To clarify, I agree that this property should be redundant and ignored by
the driver and global gpio numbers should be assigned dynamically by the
kernel.

>>>      Package (0x02) { "ngpios", 0x20 }
>>>      Package (0x02) { "gsi_idx_map", Package (0x20) {
>>>        0, 1, 2, 3, 4, 5, 6, 7,
>>>        0, 1, 2, 3, 4, 5, 6, 7,
>>>        0, 1, 2, 3, 4, 5, 6, 7,
>>>        0, 1, 2, 3, 4, 5, 6, 7,
>>>      }}
>>>    }
>>>  }
>>> }
>>> 
>>> As can be seen in the DSDT entry, the mapping is essential for obtaining
>>> the IRQ number from a GPIO line number. Otherwise, when IRQ is requested
>>> for the line numbers largers than 7, it will fail with -ENXIO.
> 
> This doesn't look good. Why can't we simply hardcode the proper behaviour based
> on the _HID? The gsi_idx_map seems quite regular and periodic, do you have some
> other examples with different mapping?

According to the manual, the gpio controllers in HID LOON0007 and LOON000F are
actually embedded into the CPU chip and the interrupt lines are hard wired so
that all the gpio lines of the gpio controller share in total 8 irqs such that
the i-th line is wired to the (i%8)-th irq. So the mapping for these two models
are fixed. I have no idea about the behavior of other kinds of controllers, which
should be answered by Loongson personales.

So far, there are known to be 2 styles of DSDT entries. One is defined by
the latest Firmware Spec, to list all the irq numbers in _CRS, e.g. Name (_CRS,
ResourceTemplate () { Interrupt () { 0x10, 0x11, .., 0x17, 0x10, 0x11, ..., 0x17,
... (in total ngpios entries) } }). The other is defined by the previous Firmware
spec, to use the property `gsi_idx_map` to map the gpio line number to the irq
number listed in the ResourceTemplate. The former should now be compatible with
the current implementation of the driver in the kernel, while the later not. I
believe that although being abandoned by the spec, the later should also be
considered and supported by the driver, since it is used by the firmwares in the
wild.

Looking forward to your advice on this.

>>> The code in this patch is mostly picked from the version 5 of Yinbo's
>>> original patch.
> 
>> Cc'ing ACPI GPIO maintainers.
> 
> Thanks, Bart!
> 
> -- 
> With Best Regards,
> Andy Shevchenko

Cheers,

Miao Wang

Re: [PATCH RFC] gpio: loongson-64bit: Add back the support for gsi_idx_map

[Andy Shevchenko]

On Tue, Jun 30, 2026 at 08:42:43PM +0800, Miao Wang wrote:
> > 2026年6月30日 20:07，Andy Shevchenko <andriy.shevchenko@linux.intel.com> 写道：
> > On Tue, Jun 30, 2026 at 07:45:52AM +0000, Bartosz Golaszewski wrote:
> >> On Mon, 29 Jun 2026 23:05:28 +0200, Miao Wang via B4 Relay
> >> <devnull+shankerwangmiao.gmail.com@kernel.org> said:
> > 
> >>> This patch adds back the support for gsi_idx_map, which is used in the
> >>> ACPI DSDT table to describe the mapping between the GPIO line number to
> >>> the index of the interrupt number in the declared interrupt resources.
> >>> 
> >>> This property was removed in Loongson CPU Universal Specification for
> >>> Interface Between PC/Server System Firmware and Kernel v4.1 in November,
> >>> 2023, but still in use in firmwares released this year. A sample of
> >>> an affected DSDT entry from a 3C6000 board I'm currently using is:
> > 
> > Oh my gosh, can somebody actually try to consult first with the Linux kernel
> > developers before adding non-standard and wrongly named properties, please?
> 
> Inferred from the time when gsi_idx_map was removed from the spec, I believe
> that the removal might be because the maintainers suggestion against introducing
> gsi_idx_map. However, the firmwares "in the wild" have not followed the change.

But what is the outcome of not using that mapping. Do you have something wrong
or not working?

> >>> Device (GPO1) {
> >>>  Name (_HID, "LOON000F")
> >>>  Name (_CRS, ResourceTemplate () {
> >>>    QWordMemory ( // Omitted, not related
> >>>    )
> >>>    Interrupt (ResourceConsumer, Level, ActiveHigh, Exclusive, ,, ) {
> >>>      0x00000010, 0x00000011, 0x00000012, 0x00000013,
> >>>      0x00000014, 0x00000015, 0x00000016, 0x00000017,
> >>>    }
> >>>  Name (_DSD, Package (0x02) {
> >>>    ToUUID ("daffd814-6eba-4d8c-8a91-bc9bbf4aa301")
> >>>    Package (0x03) {
> >>>      Package (0x02) { "gpio_base", 0x50 } // Ignored by the driver
> > 
> > Yes, it's non-standard property. It's a broken one in terms of the style.
> > See DT binding documentation.
> 
> To clarify, I agree that this property should be redundant and ignored by
> the driver and global gpio numbers should be assigned dynamically by the
> kernel.
> 
> >>>      Package (0x02) { "ngpios", 0x20 }
> >>>      Package (0x02) { "gsi_idx_map", Package (0x20) {
> >>>        0, 1, 2, 3, 4, 5, 6, 7,
> >>>        0, 1, 2, 3, 4, 5, 6, 7,
> >>>        0, 1, 2, 3, 4, 5, 6, 7,
> >>>        0, 1, 2, 3, 4, 5, 6, 7,
> >>>      }}
> >>>    }
> >>>  }
> >>> }
> >>> 
> >>> As can be seen in the DSDT entry, the mapping is essential for obtaining
> >>> the IRQ number from a GPIO line number. Otherwise, when IRQ is requested
> >>> for the line numbers largers than 7, it will fail with -ENXIO.
> > 
> > This doesn't look good. Why can't we simply hardcode the proper behaviour based
> > on the _HID? The gsi_idx_map seems quite regular and periodic, do you have some
> > other examples with different mapping?
> 
> According to the manual, the gpio controllers in HID LOON0007 and LOON000F are
> actually embedded into the CPU chip and the interrupt lines are hard wired so
> that all the gpio lines of the gpio controller share in total 8 irqs such that
> the i-th line is wired to the (i%8)-th irq. So the mapping for these two models
> are fixed. I have no idea about the behavior of other kinds of controllers, which
> should be answered by Loongson personales.

OK.

> So far, there are known to be 2 styles of DSDT entries. One is defined by
> the latest Firmware Spec, to list all the irq numbers in _CRS, e.g. Name (_CRS,
> ResourceTemplate () { Interrupt () { 0x10, 0x11, .., 0x17, 0x10, 0x11, ..., 0x17,
> ... (in total ngpios entries) } }). The other is defined by the previous Firmware
> spec, to use the property `gsi_idx_map` to map the gpio line number to the irq
> number listed in the ResourceTemplate. The former should now be compatible with
> the current implementation of the driver in the kernel, while the later not. I
> believe that although being abandoned by the spec, the later should also be
> considered and supported by the driver, since it is used by the firmwares in the
> wild.

This is clear. What's unclear is the necessity of adding this mapping. Is that
mapping shuffled in an arbitrary way?

Second question, why one can't update firmware to fix this to follow the
specification? From above DSDT I do *not* see the need in this mapping.
Everything can be simply deducted from the number of Interrupt() resources
and ngpios at run-time without touching the property.

> Looking forward to your advice on this.
> 
> >>> The code in this patch is mostly picked from the version 5 of Yinbo's
> >>> original patch.

-- 
With Best Regards,
Andy Shevchenko

Re: [PATCH RFC] gpio: loongson-64bit: Add back the support for gsi_idx_map

[Miao Wang]

Hi,

> 2026年7月1日 15:36，Andy Shevchenko <andriy.shevchenko@linux.intel.com> 写道：
> 
> On Tue, Jun 30, 2026 at 08:42:43PM +0800, Miao Wang wrote:
>>> 2026年6月30日 20:07，Andy Shevchenko <andriy.shevchenko@linux.intel.com> 写道：
>>> On Tue, Jun 30, 2026 at 07:45:52AM +0000, Bartosz Golaszewski wrote:
>>>> On Mon, 29 Jun 2026 23:05:28 +0200, Miao Wang via B4 Relay
>>>> <devnull+shankerwangmiao.gmail.com@kernel.org> said:
>>> 
>>>>> This patch adds back the support for gsi_idx_map, which is used in the
>>>>> ACPI DSDT table to describe the mapping between the GPIO line number to
>>>>> the index of the interrupt number in the declared interrupt resources.
>>>>> 
>>>>> This property was removed in Loongson CPU Universal Specification for
>>>>> Interface Between PC/Server System Firmware and Kernel v4.1 in November,
>>>>> 2023, but still in use in firmwares released this year. A sample of
>>>>> an affected DSDT entry from a 3C6000 board I'm currently using is:
>>> 
>>> Oh my gosh, can somebody actually try to consult first with the Linux kernel
>>> developers before adding non-standard and wrongly named properties, please?
>> 
>> Inferred from the time when gsi_idx_map was removed from the spec, I believe
>> that the removal might be because the maintainers suggestion against introducing
>> gsi_idx_map. However, the firmwares "in the wild" have not followed the change.
> 
> But what is the outcome of not using that mapping. Do you have something wrong
> or not working?

Yes. As shown in the DSDT entry, when the mapping is given by the firmware, the
number of given interrupts in _CRS does not equal to ngpios. In my example,
ngpios is 32, but the number of interrupts given in _CRS is 8, and the request
for irq on gpio lines whose number larger than 8 will fail with -ENXIO. To
clarify, the entry is taken from the firmware I am currently using, and the
firmware is released on February this year.

>>>>> Device (GPO1) {
>>>>> Name (_HID, "LOON000F")
>>>>> Name (_CRS, ResourceTemplate () {
>>>>>   QWordMemory ( // Omitted, not related
>>>>>   )
>>>>>   Interrupt (ResourceConsumer, Level, ActiveHigh, Exclusive, ,, ) {
>>>>>     0x00000010, 0x00000011, 0x00000012, 0x00000013,
>>>>>     0x00000014, 0x00000015, 0x00000016, 0x00000017,
>>>>>   }
>>>>> Name (_DSD, Package (0x02) {
>>>>>   ToUUID ("daffd814-6eba-4d8c-8a91-bc9bbf4aa301")
>>>>>   Package (0x03) {
>>>>>     Package (0x02) { "gpio_base", 0x50 } // Ignored by the driver
>>> 
>>> Yes, it's non-standard property. It's a broken one in terms of the style.
>>> See DT binding documentation.
>> 
>> To clarify, I agree that this property should be redundant and ignored by
>> the driver and global gpio numbers should be assigned dynamically by the
>> kernel.
>> 
>>>>>     Package (0x02) { "ngpios", 0x20 }
>>>>>     Package (0x02) { "gsi_idx_map", Package (0x20) {
>>>>>       0, 1, 2, 3, 4, 5, 6, 7,
>>>>>       0, 1, 2, 3, 4, 5, 6, 7,
>>>>>       0, 1, 2, 3, 4, 5, 6, 7,
>>>>>       0, 1, 2, 3, 4, 5, 6, 7,
>>>>>     }}
>>>>>   }
>>>>> }
>>>>> }
>>>>> 
>>>>> As can be seen in the DSDT entry, the mapping is essential for obtaining
>>>>> the IRQ number from a GPIO line number. Otherwise, when IRQ is requested
>>>>> for the line numbers largers than 7, it will fail with -ENXIO.
>>> 
>>> This doesn't look good. Why can't we simply hardcode the proper behaviour based
>>> on the _HID? The gsi_idx_map seems quite regular and periodic, do you have some
>>> other examples with different mapping?
>> 
>> According to the manual, the gpio controllers in HID LOON0007 and LOON000F are
>> actually embedded into the CPU chip and the interrupt lines are hard wired so
>> that all the gpio lines of the gpio controller share in total 8 irqs such that
>> the i-th line is wired to the (i%8)-th irq. So the mapping for these two models
>> are fixed. I have no idea about the behavior of other kinds of controllers, which
>> should be answered by Loongson personales.
> 
> OK.
> 
>> So far, there are known to be 2 styles of DSDT entries. One is defined by
>> the latest Firmware Spec, to list all the irq numbers in _CRS, e.g. Name (_CRS,
>> ResourceTemplate () { Interrupt () { 0x10, 0x11, .., 0x17, 0x10, 0x11, ..., 0x17,
>> ... (in total ngpios entries) } }). The other is defined by the previous Firmware
>> spec, to use the property `gsi_idx_map` to map the gpio line number to the irq
>> number listed in the ResourceTemplate. The former should now be compatible with
>> the current implementation of the driver in the kernel, while the later not. I
>> believe that although being abandoned by the spec, the later should also be
>> considered and supported by the driver, since it is used by the firmwares in the
>> wild.
> 
> This is clear. What's unclear is the necessity of adding this mapping. Is that
> mapping shuffled in an arbitrary way?

According to the partial information I currently have, I don't think the mapping
would shuffle arbitrarily.

> Second question, why one can't update firmware to fix this to follow the
> specification? From above DSDT I do *not* see the need in this mapping.
> Everything can be simply deducted from the number of Interrupt() resources
> and ngpios at run-time without touching the property.

I have no idea why on the firmware side the spec was not followed for three
years. When ignoring this mapping, there would be a problem if the number
of given Interrupt() resources is less than ngpios. When this mapping is
referred, there will be a ground truth for which irq number a gpio line
belongs to. To be specific, suppose the number of Interrupt() resources
is m and ngpios is n. In the current spec, where m equals to n, such ground
truth also exists. However, when m is less than n and this mapping is
ignored, the mapping will become ambiguous. Should the irq number be i%m
for gpio line i, or i%8 and reject the irq requests when m is less than 8?

Cheers,

Miao Wang

Re: [PATCH RFC] gpio: loongson-64bit: Add back the support for gsi_idx_map

[Andy Shevchenko]

On Wed, Jul 01, 2026 at 04:07:43PM +0800, Miao Wang wrote:
> > 2026年7月1日 15:36，Andy Shevchenko <andriy.shevchenko@linux.intel.com> 写道：
> > On Tue, Jun 30, 2026 at 08:42:43PM +0800, Miao Wang wrote:
> >>> 2026年6月30日 20:07，Andy Shevchenko <andriy.shevchenko@linux.intel.com> 写道：
> >>> On Tue, Jun 30, 2026 at 07:45:52AM +0000, Bartosz Golaszewski wrote:
> >>>> On Mon, 29 Jun 2026 23:05:28 +0200, Miao Wang via B4 Relay
> >>>> <devnull+shankerwangmiao.gmail.com@kernel.org> said:

...

> >>>>> This patch adds back the support for gsi_idx_map, which is used in the
> >>>>> ACPI DSDT table to describe the mapping between the GPIO line number to
> >>>>> the index of the interrupt number in the declared interrupt resources.
> >>>>> 
> >>>>> This property was removed in Loongson CPU Universal Specification for
> >>>>> Interface Between PC/Server System Firmware and Kernel v4.1 in November,
> >>>>> 2023, but still in use in firmwares released this year. A sample of
> >>>>> an affected DSDT entry from a 3C6000 board I'm currently using is:
> >>> 
> >>> Oh my gosh, can somebody actually try to consult first with the Linux kernel
> >>> developers before adding non-standard and wrongly named properties, please?
> >> 
> >> Inferred from the time when gsi_idx_map was removed from the spec, I believe
> >> that the removal might be because the maintainers suggestion against introducing
> >> gsi_idx_map. However, the firmwares "in the wild" have not followed the change.
> > 
> > But what is the outcome of not using that mapping. Do you have something wrong
> > or not working?
> 
> Yes. As shown in the DSDT entry, when the mapping is given by the firmware, the
> number of given interrupts in _CRS does not equal to ngpios. In my example,
> ngpios is 32, but the number of interrupts given in _CRS is 8, and the request
> for irq on gpio lines whose number larger than 8 will fail with -ENXIO. To
> clarify, the entry is taken from the firmware I am currently using, and the
> firmware is released on February this year.

Right, so with the given example everything can be done without using the (now)
unspecified property. Do you have more examples of DSDT of these platforms?

> >>>>> Device (GPO1) {
> >>>>> Name (_HID, "LOON000F")
> >>>>> Name (_CRS, ResourceTemplate () {
> >>>>>   QWordMemory ( // Omitted, not related
> >>>>>   )
> >>>>>   Interrupt (ResourceConsumer, Level, ActiveHigh, Exclusive, ,, ) {
> >>>>>     0x00000010, 0x00000011, 0x00000012, 0x00000013,
> >>>>>     0x00000014, 0x00000015, 0x00000016, 0x00000017,
> >>>>>   }
> >>>>> Name (_DSD, Package (0x02) {
> >>>>>   ToUUID ("daffd814-6eba-4d8c-8a91-bc9bbf4aa301")
> >>>>>   Package (0x03) {
> >>>>>     Package (0x02) { "gpio_base", 0x50 } // Ignored by the driver
> >>> 
> >>> Yes, it's non-standard property. It's a broken one in terms of the style.
> >>> See DT binding documentation.
> >> 
> >> To clarify, I agree that this property should be redundant and ignored by
> >> the driver and global gpio numbers should be assigned dynamically by the
> >> kernel.
> >> 
> >>>>>     Package (0x02) { "ngpios", 0x20 }
> >>>>>     Package (0x02) { "gsi_idx_map", Package (0x20) {
> >>>>>       0, 1, 2, 3, 4, 5, 6, 7,
> >>>>>       0, 1, 2, 3, 4, 5, 6, 7,
> >>>>>       0, 1, 2, 3, 4, 5, 6, 7,
> >>>>>       0, 1, 2, 3, 4, 5, 6, 7,
> >>>>>     }}
> >>>>>   }
> >>>>> }
> >>>>> }
> >>>>> 
> >>>>> As can be seen in the DSDT entry, the mapping is essential for obtaining
> >>>>> the IRQ number from a GPIO line number. Otherwise, when IRQ is requested
> >>>>> for the line numbers largers than 7, it will fail with -ENXIO.
> >>> 
> >>> This doesn't look good. Why can't we simply hardcode the proper behaviour based
> >>> on the _HID? The gsi_idx_map seems quite regular and periodic, do you have some
> >>> other examples with different mapping?
> >> 
> >> According to the manual, the gpio controllers in HID LOON0007 and LOON000F are
> >> actually embedded into the CPU chip and the interrupt lines are hard wired so
> >> that all the gpio lines of the gpio controller share in total 8 irqs such that
> >> the i-th line is wired to the (i%8)-th irq. So the mapping for these two models
> >> are fixed. I have no idea about the behavior of other kinds of controllers, which
> >> should be answered by Loongson personales.
> > 
> > OK.
> > 
> >> So far, there are known to be 2 styles of DSDT entries. One is defined by
> >> the latest Firmware Spec, to list all the irq numbers in _CRS, e.g. Name (_CRS,
> >> ResourceTemplate () { Interrupt () { 0x10, 0x11, .., 0x17, 0x10, 0x11, ..., 0x17,
> >> ... (in total ngpios entries) } }). The other is defined by the previous Firmware
> >> spec, to use the property `gsi_idx_map` to map the gpio line number to the irq
> >> number listed in the ResourceTemplate. The former should now be compatible with
> >> the current implementation of the driver in the kernel, while the later not. I
> >> believe that although being abandoned by the spec, the later should also be
> >> considered and supported by the driver, since it is used by the firmwares in the
> >> wild.
> > 
> > This is clear. What's unclear is the necessity of adding this mapping. Is that
> > mapping shuffled in an arbitrary way?
> 
> According to the partial information I currently have, I don't think the mapping
> would shuffle arbitrarily.
> 
> > Second question, why one can't update firmware to fix this to follow the
> > specification? From above DSDT I do *not* see the need in this mapping.
> > Everything can be simply deducted from the number of Interrupt() resources
> > and ngpios at run-time without touching the property.
> 
> I have no idea why on the firmware side the spec was not followed for three
> years. When ignoring this mapping, there would be a problem if the number
> of given Interrupt() resources is less than ngpios. When this mapping is
> referred, there will be a ground truth for which irq number a gpio line
> belongs to. To be specific, suppose the number of Interrupt() resources
> is m and ngpios is n. In the current spec, where m equals to n, such ground
> truth also exists. However, when m is less than n and this mapping is
> ignored, the mapping will become ambiguous. Should the irq number be i%m
> for gpio line i, or i%8 and reject the irq requests when m is less than 8?

My suggestion is to restore the logic in the code for the above-like mappings.

You count Interrupt() resources, you have 'ngpios' property. Now, when you
do need to map an IRQ line, you simply do it in a way of

	IRQ line % amount of Interrupt() resources

It will give you the same without reading that property. I believe that's why
the specification removed the need, because in this case it's not needed and
may be easily derived from the existing information.

Can somebody from Loongson shed a light on what's going on here?

-- 
With Best Regards,
Andy Shevchenko

Re: [PATCH RFC] gpio: loongson-64bit: Add back the support for gsi_idx_map

[Miao Wang]

Hi,

> 2026年7月1日 16:37，Andy Shevchenko <andriy.shevchenko@linux.intel.com> 写道：
> 
> On Wed, Jul 01, 2026 at 04:07:43PM +0800, Miao Wang wrote:
>>> 2026年7月1日 15:36，Andy Shevchenko <andriy.shevchenko@linux.intel.com> 写道：
>>> On Tue, Jun 30, 2026 at 08:42:43PM +0800, Miao Wang wrote:
>>>>> 2026年6月30日 20:07，Andy Shevchenko <andriy.shevchenko@linux.intel.com> 写道：
>>>>> On Tue, Jun 30, 2026 at 07:45:52AM +0000, Bartosz Golaszewski wrote:
>>>>>> On Mon, 29 Jun 2026 23:05:28 +0200, Miao Wang via B4 Relay
>>>>>> <devnull+shankerwangmiao.gmail.com@kernel.org> said:
> 
> ...
> 
>>>>>>> This patch adds back the support for gsi_idx_map, which is used in the
>>>>>>> ACPI DSDT table to describe the mapping between the GPIO line number to
>>>>>>> the index of the interrupt number in the declared interrupt resources.
>>>>>>> 
>>>>>>> This property was removed in Loongson CPU Universal Specification for
>>>>>>> Interface Between PC/Server System Firmware and Kernel v4.1 in November,
>>>>>>> 2023, but still in use in firmwares released this year. A sample of
>>>>>>> an affected DSDT entry from a 3C6000 board I'm currently using is:
>>>>> 
>>>>> Oh my gosh, can somebody actually try to consult first with the Linux kernel
>>>>> developers before adding non-standard and wrongly named properties, please?
>>>> 
>>>> Inferred from the time when gsi_idx_map was removed from the spec, I believe
>>>> that the removal might be because the maintainers suggestion against introducing
>>>> gsi_idx_map. However, the firmwares "in the wild" have not followed the change.
>>> 
>>> But what is the outcome of not using that mapping. Do you have something wrong
>>> or not working?
>> 
>> Yes. As shown in the DSDT entry, when the mapping is given by the firmware, the
>> number of given interrupts in _CRS does not equal to ngpios. In my example,
>> ngpios is 32, but the number of interrupts given in _CRS is 8, and the request
>> for irq on gpio lines whose number larger than 8 will fail with -ENXIO. To
>> clarify, the entry is taken from the firmware I am currently using, and the
>> firmware is released on February this year.
> 
> Right, so with the given example everything can be done without using the (now)
> unspecified property. Do you have more examples of DSDT of these platforms?

Sorry, I only possess limited number of loongarch devices.

>>>>>>> Device (GPO1) {
>>>>>>> Name (_HID, "LOON000F")
>>>>>>> Name (_CRS, ResourceTemplate () {
>>>>>>>  QWordMemory ( // Omitted, not related
>>>>>>>  )
>>>>>>>  Interrupt (ResourceConsumer, Level, ActiveHigh, Exclusive, ,, ) {
>>>>>>>    0x00000010, 0x00000011, 0x00000012, 0x00000013,
>>>>>>>    0x00000014, 0x00000015, 0x00000016, 0x00000017,
>>>>>>>  }
>>>>>>> Name (_DSD, Package (0x02) {
>>>>>>>  ToUUID ("daffd814-6eba-4d8c-8a91-bc9bbf4aa301")
>>>>>>>  Package (0x03) {
>>>>>>>    Package (0x02) { "gpio_base", 0x50 } // Ignored by the driver
>>>>> 
>>>>> Yes, it's non-standard property. It's a broken one in terms of the style.
>>>>> See DT binding documentation.
>>>> 
>>>> To clarify, I agree that this property should be redundant and ignored by
>>>> the driver and global gpio numbers should be assigned dynamically by the
>>>> kernel.
>>>> 
>>>>>>>    Package (0x02) { "ngpios", 0x20 }
>>>>>>>    Package (0x02) { "gsi_idx_map", Package (0x20) {
>>>>>>>      0, 1, 2, 3, 4, 5, 6, 7,
>>>>>>>      0, 1, 2, 3, 4, 5, 6, 7,
>>>>>>>      0, 1, 2, 3, 4, 5, 6, 7,
>>>>>>>      0, 1, 2, 3, 4, 5, 6, 7,
>>>>>>>    }}
>>>>>>>  }
>>>>>>> }
>>>>>>> }
>>>>>>> 
>>>>>>> As can be seen in the DSDT entry, the mapping is essential for obtaining
>>>>>>> the IRQ number from a GPIO line number. Otherwise, when IRQ is requested
>>>>>>> for the line numbers largers than 7, it will fail with -ENXIO.
>>>>> 
>>>>> This doesn't look good. Why can't we simply hardcode the proper behaviour based
>>>>> on the _HID? The gsi_idx_map seems quite regular and periodic, do you have some
>>>>> other examples with different mapping?
>>>> 
>>>> According to the manual, the gpio controllers in HID LOON0007 and LOON000F are
>>>> actually embedded into the CPU chip and the interrupt lines are hard wired so
>>>> that all the gpio lines of the gpio controller share in total 8 irqs such that
>>>> the i-th line is wired to the (i%8)-th irq. So the mapping for these two models
>>>> are fixed. I have no idea about the behavior of other kinds of controllers, which
>>>> should be answered by Loongson personales.
>>> 
>>> OK.
>>> 
>>>> So far, there are known to be 2 styles of DSDT entries. One is defined by
>>>> the latest Firmware Spec, to list all the irq numbers in _CRS, e.g. Name (_CRS,
>>>> ResourceTemplate () { Interrupt () { 0x10, 0x11, .., 0x17, 0x10, 0x11, ..., 0x17,
>>>> ... (in total ngpios entries) } }). The other is defined by the previous Firmware
>>>> spec, to use the property `gsi_idx_map` to map the gpio line number to the irq
>>>> number listed in the ResourceTemplate. The former should now be compatible with
>>>> the current implementation of the driver in the kernel, while the later not. I
>>>> believe that although being abandoned by the spec, the later should also be
>>>> considered and supported by the driver, since it is used by the firmwares in the
>>>> wild.
>>> 
>>> This is clear. What's unclear is the necessity of adding this mapping. Is that
>>> mapping shuffled in an arbitrary way?
>> 
>> According to the partial information I currently have, I don't think the mapping
>> would shuffle arbitrarily.
>> 
>>> Second question, why one can't update firmware to fix this to follow the
>>> specification? From above DSDT I do *not* see the need in this mapping.
>>> Everything can be simply deducted from the number of Interrupt() resources
>>> and ngpios at run-time without touching the property.
>> 
>> I have no idea why on the firmware side the spec was not followed for three
>> years. When ignoring this mapping, there would be a problem if the number
>> of given Interrupt() resources is less than ngpios. When this mapping is
>> referred, there will be a ground truth for which irq number a gpio line
>> belongs to. To be specific, suppose the number of Interrupt() resources
>> is m and ngpios is n. In the current spec, where m equals to n, such ground
>> truth also exists. However, when m is less than n and this mapping is
>> ignored, the mapping will become ambiguous. Should the irq number be i%m
>> for gpio line i, or i%8 and reject the irq requests when m is less than 8?
> 
> My suggestion is to restore the logic in the code for the above-like mappings.
> 
> You count Interrupt() resources, you have 'ngpios' property. Now, when you
> do need to map an IRQ line, you simply do it in a way of
> 
> IRQ line % amount of Interrupt() resources
> 
> It will give you the same without reading that property. I believe that's why
> the specification removed the need, because in this case it's not needed and
> may be easily derived from the existing information.

Yes, but actually from the hardware specs, the mapping between gpio lines and
the irq lines is actually taking modulo of 8. If the given number of Interrupt()
is 8, this will be right. What if the given number of Interrupt() is not 8, say
9 or anything else? I think to be fail-safe, when the amount of Interrupt()
resources is less than ngpios, we should only allow 8 Interrupt()'s given.

> Can somebody from Loongson shed a light on what's going on here?
> 

Re: [PATCH RFC] gpio: loongson-64bit: Add back the support for gsi_idx_map

[Andy Shevchenko]

On Wed, Jul 01, 2026 at 04:56:11PM +0800, Miao Wang wrote:
> > 2026年7月1日 16:37，Andy Shevchenko <andriy.shevchenko@linux.intel.com> 写道：
> > On Wed, Jul 01, 2026 at 04:07:43PM +0800, Miao Wang wrote:
> >>> 2026年7月1日 15:36，Andy Shevchenko <andriy.shevchenko@linux.intel.com> 写道：
> >>> On Tue, Jun 30, 2026 at 08:42:43PM +0800, Miao Wang wrote:
> >>>>> 2026年6月30日 20:07，Andy Shevchenko <andriy.shevchenko@linux.intel.com> 写道：
> >>>>> On Tue, Jun 30, 2026 at 07:45:52AM +0000, Bartosz Golaszewski wrote:
> >>>>>> On Mon, 29 Jun 2026 23:05:28 +0200, Miao Wang via B4 Relay
> >>>>>> <devnull+shankerwangmiao.gmail.com@kernel.org> said:

...

> >>>>>>> This patch adds back the support for gsi_idx_map, which is used in the
> >>>>>>> ACPI DSDT table to describe the mapping between the GPIO line number to
> >>>>>>> the index of the interrupt number in the declared interrupt resources.
> >>>>>>> 
> >>>>>>> This property was removed in Loongson CPU Universal Specification for
> >>>>>>> Interface Between PC/Server System Firmware and Kernel v4.1 in November,
> >>>>>>> 2023, but still in use in firmwares released this year. A sample of
> >>>>>>> an affected DSDT entry from a 3C6000 board I'm currently using is:
> >>>>> 
> >>>>> Oh my gosh, can somebody actually try to consult first with the Linux kernel
> >>>>> developers before adding non-standard and wrongly named properties, please?
> >>>> 
> >>>> Inferred from the time when gsi_idx_map was removed from the spec, I believe
> >>>> that the removal might be because the maintainers suggestion against introducing
> >>>> gsi_idx_map. However, the firmwares "in the wild" have not followed the change.
> >>> 
> >>> But what is the outcome of not using that mapping. Do you have something wrong
> >>> or not working?
> >> 
> >> Yes. As shown in the DSDT entry, when the mapping is given by the firmware, the
> >> number of given interrupts in _CRS does not equal to ngpios. In my example,
> >> ngpios is 32, but the number of interrupts given in _CRS is 8, and the request
> >> for irq on gpio lines whose number larger than 8 will fail with -ENXIO. To
> >> clarify, the entry is taken from the firmware I am currently using, and the
> >> firmware is released on February this year.
> > 
> > Right, so with the given example everything can be done without using the (now)
> > unspecified property. Do you have more examples of DSDT of these platforms?
> 
> Sorry, I only possess limited number of loongarch devices.

Yeah, we definitely need some input from Loongson people.

> >>>>>>> Device (GPO1) {
> >>>>>>> Name (_HID, "LOON000F")
> >>>>>>> Name (_CRS, ResourceTemplate () {
> >>>>>>>  QWordMemory ( // Omitted, not related
> >>>>>>>  )
> >>>>>>>  Interrupt (ResourceConsumer, Level, ActiveHigh, Exclusive, ,, ) {
> >>>>>>>    0x00000010, 0x00000011, 0x00000012, 0x00000013,
> >>>>>>>    0x00000014, 0x00000015, 0x00000016, 0x00000017,
> >>>>>>>  }
> >>>>>>> Name (_DSD, Package (0x02) {
> >>>>>>>  ToUUID ("daffd814-6eba-4d8c-8a91-bc9bbf4aa301")
> >>>>>>>  Package (0x03) {
> >>>>>>>    Package (0x02) { "gpio_base", 0x50 } // Ignored by the driver
> >>>>> 
> >>>>> Yes, it's non-standard property. It's a broken one in terms of the style.
> >>>>> See DT binding documentation.
> >>>> 
> >>>> To clarify, I agree that this property should be redundant and ignored by
> >>>> the driver and global gpio numbers should be assigned dynamically by the
> >>>> kernel.
> >>>> 
> >>>>>>>    Package (0x02) { "ngpios", 0x20 }
> >>>>>>>    Package (0x02) { "gsi_idx_map", Package (0x20) {
> >>>>>>>      0, 1, 2, 3, 4, 5, 6, 7,
> >>>>>>>      0, 1, 2, 3, 4, 5, 6, 7,
> >>>>>>>      0, 1, 2, 3, 4, 5, 6, 7,
> >>>>>>>      0, 1, 2, 3, 4, 5, 6, 7,
> >>>>>>>    }}
> >>>>>>>  }
> >>>>>>> }
> >>>>>>> }
> >>>>>>> 
> >>>>>>> As can be seen in the DSDT entry, the mapping is essential for obtaining
> >>>>>>> the IRQ number from a GPIO line number. Otherwise, when IRQ is requested
> >>>>>>> for the line numbers largers than 7, it will fail with -ENXIO.
> >>>>> 
> >>>>> This doesn't look good. Why can't we simply hardcode the proper behaviour based
> >>>>> on the _HID? The gsi_idx_map seems quite regular and periodic, do you have some
> >>>>> other examples with different mapping?
> >>>> 
> >>>> According to the manual, the gpio controllers in HID LOON0007 and LOON000F are
> >>>> actually embedded into the CPU chip and the interrupt lines are hard wired so
> >>>> that all the gpio lines of the gpio controller share in total 8 irqs such that
> >>>> the i-th line is wired to the (i%8)-th irq. So the mapping for these two models
> >>>> are fixed. I have no idea about the behavior of other kinds of controllers, which
> >>>> should be answered by Loongson personales.
> >>> 
> >>> OK.
> >>> 
> >>>> So far, there are known to be 2 styles of DSDT entries. One is defined by
> >>>> the latest Firmware Spec, to list all the irq numbers in _CRS, e.g. Name (_CRS,
> >>>> ResourceTemplate () { Interrupt () { 0x10, 0x11, .., 0x17, 0x10, 0x11, ..., 0x17,
> >>>> ... (in total ngpios entries) } }). The other is defined by the previous Firmware
> >>>> spec, to use the property `gsi_idx_map` to map the gpio line number to the irq
> >>>> number listed in the ResourceTemplate. The former should now be compatible with
> >>>> the current implementation of the driver in the kernel, while the later not. I
> >>>> believe that although being abandoned by the spec, the later should also be
> >>>> considered and supported by the driver, since it is used by the firmwares in the
> >>>> wild.
> >>> 
> >>> This is clear. What's unclear is the necessity of adding this mapping. Is that
> >>> mapping shuffled in an arbitrary way?
> >> 
> >> According to the partial information I currently have, I don't think the mapping
> >> would shuffle arbitrarily.
> >> 
> >>> Second question, why one can't update firmware to fix this to follow the
> >>> specification? From above DSDT I do *not* see the need in this mapping.
> >>> Everything can be simply deducted from the number of Interrupt() resources
> >>> and ngpios at run-time without touching the property.
> >> 
> >> I have no idea why on the firmware side the spec was not followed for three
> >> years. When ignoring this mapping, there would be a problem if the number
> >> of given Interrupt() resources is less than ngpios. When this mapping is
> >> referred, there will be a ground truth for which irq number a gpio line
> >> belongs to. To be specific, suppose the number of Interrupt() resources
> >> is m and ngpios is n. In the current spec, where m equals to n, such ground
> >> truth also exists. However, when m is less than n and this mapping is
> >> ignored, the mapping will become ambiguous. Should the irq number be i%m
> >> for gpio line i, or i%8 and reject the irq requests when m is less than 8?
> > 
> > My suggestion is to restore the logic in the code for the above-like mappings.
> > 
> > You count Interrupt() resources, you have 'ngpios' property. Now, when you
> > do need to map an IRQ line, you simply do it in a way of
> > 
> > IRQ line % amount of Interrupt() resources
> > 
> > It will give you the same without reading that property. I believe that's why
> > the specification removed the need, because in this case it's not needed and
> > may be easily derived from the existing information.
> 
> Yes, but actually from the hardware specs, the mapping between gpio lines and
> the irq lines is actually taking modulo of 8. If the given number of Interrupt()
> is 8, this will be right. What if the given number of Interrupt() is not 8, say
> 9 or anything else? I think to be fail-safe, when the amount of Interrupt()
> resources is less than ngpios, we should only allow 8 Interrupt()'s given.

But if amount is 6 or 5? I think it should be considered as a FW bug.
I would go KISS and probably just use modulo 8 unconditionally and
if something happens, we will get a report and hence will act accordingly.

> > Can somebody from Loongson shed a light on what's going on here?

-- 
With Best Regards,
Andy Shevchenko

Re: [PATCH RFC] gpio: loongson-64bit: Add back the support for gsi_idx_map

[Xi Ruoyao]

On Wed, 2026-07-01 at 12:45 +0300, Andy Shevchenko wrote:
> On Wed, Jul 01, 2026 at 04:56:11PM +0800, Miao Wang wrote:
> > > 2026年7月1日 16:37，Andy Shevchenko <andriy.shevchenko@linux.intel.com> 写道：
> > > On Wed, Jul 01, 2026 at 04:07:43PM +0800, Miao Wang wrote:
> > > > > 2026年7月1日 15:36，Andy Shevchenko <andriy.shevchenko@linux.intel.com> 写道：
> > > > > On Tue, Jun 30, 2026 at 08:42:43PM +0800, Miao Wang wrote:
> > > > > > > 2026年6月30日 20:07，Andy Shevchenko <andriy.shevchenko@linux.intel.com> 写道：
> > > > > > > On Tue, Jun 30, 2026 at 07:45:52AM +0000, Bartosz Golaszewski wrote:
> > > > > > > > On Mon, 29 Jun 2026 23:05:28 +0200, Miao Wang via B4 Relay
> > > > > > > > <devnull+shankerwangmiao.gmail.com@kernel.org> said:
> 
> ...
> 
> > > > > > > > > This patch adds back the support for gsi_idx_map, which is used in the
> > > > > > > > > ACPI DSDT table to describe the mapping between the GPIO line number to
> > > > > > > > > the index of the interrupt number in the declared interrupt resources.
> > > > > > > > > 
> > > > > > > > > This property was removed in Loongson CPU Universal Specification for
> > > > > > > > > Interface Between PC/Server System Firmware and Kernel v4.1 in November,
> > > > > > > > > 2023, but still in use in firmwares released this year. A sample of
> > > > > > > > > an affected DSDT entry from a 3C6000 board I'm currently using is:
> > > > > > > 
> > > > > > > Oh my gosh, can somebody actually try to consult first with the Linux kernel
> > > > > > > developers before adding non-standard and wrongly named properties, please?
> > > > > > 
> > > > > > Inferred from the time when gsi_idx_map was removed from the spec, I believe
> > > > > > that the removal might be because the maintainers suggestion against introducing
> > > > > > gsi_idx_map. However, the firmwares "in the wild" have not followed the change.
> > > > > 
> > > > > But what is the outcome of not using that mapping. Do you have something wrong
> > > > > or not working?
> > > > 
> > > > Yes. As shown in the DSDT entry, when the mapping is given by the firmware, the
> > > > number of given interrupts in _CRS does not equal to ngpios. In my example,
> > > > ngpios is 32, but the number of interrupts given in _CRS is 8, and the request
> > > > for irq on gpio lines whose number larger than 8 will fail with -ENXIO. To
> > > > clarify, the entry is taken from the firmware I am currently using, and the
> > > > firmware is released on February this year.
> > > 
> > > Right, so with the given example everything can be done without using the (now)
> > > unspecified property. Do you have more examples of DSDT of these platforms?
> > 
> > Sorry, I only possess limited number of loongarch devices.
>
> 
> Yeah, we definitely need some input from Loongson people.
> 
> > > > > > > > > Device (GPO1) {
> > > > > > > > > Name (_HID, "LOON000F")
> > > > > > > > > Name (_CRS, ResourceTemplate () {
> > > > > > > > >  QWordMemory ( // Omitted, not related
> > > > > > > > >  )
> > > > > > > > >  Interrupt (ResourceConsumer, Level, ActiveHigh, Exclusive, ,, ) {
> > > > > > > > >    0x00000010, 0x00000011, 0x00000012, 0x00000013,
> > > > > > > > >    0x00000014, 0x00000015, 0x00000016, 0x00000017,
> > > > > > > > >  }
> > > > > > > > > Name (_DSD, Package (0x02) {
> > > > > > > > >  ToUUID ("daffd814-6eba-4d8c-8a91-bc9bbf4aa301")
> > > > > > > > >  Package (0x03) {
> > > > > > > > >    Package (0x02) { "gpio_base", 0x50 } // Ignored by the driver
> > > > > > > 
> > > > > > > Yes, it's non-standard property. It's a broken one in terms of the style.
> > > > > > > See DT binding documentation.
> > > > > > 
> > > > > > To clarify, I agree that this property should be redundant and ignored by
> > > > > > the driver and global gpio numbers should be assigned dynamically by the
> > > > > > kernel.
> > > > > > 
> > > > > > > > >    Package (0x02) { "ngpios", 0x20 }
> > > > > > > > >    Package (0x02) { "gsi_idx_map", Package (0x20) {
> > > > > > > > >      0, 1, 2, 3, 4, 5, 6, 7,
> > > > > > > > >      0, 1, 2, 3, 4, 5, 6, 7,
> > > > > > > > >      0, 1, 2, 3, 4, 5, 6, 7,
> > > > > > > > >      0, 1, 2, 3, 4, 5, 6, 7,
> > > > > > > > >    }}
> > > > > > > > >  }
> > > > > > > > > }
> > > > > > > > > }
> > > > > > > > > 
> > > > > > > > > As can be seen in the DSDT entry, the mapping is essential for obtaining
> > > > > > > > > the IRQ number from a GPIO line number. Otherwise, when IRQ is requested
> > > > > > > > > for the line numbers largers than 7, it will fail with -ENXIO.
> > > > > > > 
> > > > > > > This doesn't look good. Why can't we simply hardcode the proper behaviour based
> > > > > > > on the _HID? The gsi_idx_map seems quite regular and periodic, do you have some
> > > > > > > other examples with different mapping?
> > > > > > 
> > > > > > According to the manual, the gpio controllers in HID LOON0007 and LOON000F are
> > > > > > actually embedded into the CPU chip and the interrupt lines are hard wired so
> > > > > > that all the gpio lines of the gpio controller share in total 8 irqs such that
> > > > > > the i-th line is wired to the (i%8)-th irq. So the mapping for these two models
> > > > > > are fixed. I have no idea about the behavior of other kinds of controllers, which
> > > > > > should be answered by Loongson personales.
> > > > > 
> > > > > OK.
> > > > > 
> > > > > > So far, there are known to be 2 styles of DSDT entries. One is defined by
> > > > > > the latest Firmware Spec, to list all the irq numbers in _CRS, e.g. Name (_CRS,
> > > > > > ResourceTemplate () { Interrupt () { 0x10, 0x11, .., 0x17, 0x10, 0x11, ..., 0x17,
> > > > > > ... (in total ngpios entries) } }). The other is defined by the previous Firmware
> > > > > > spec, to use the property `gsi_idx_map` to map the gpio line number to the irq
> > > > > > number listed in the ResourceTemplate. The former should now be compatible with
> > > > > > the current implementation of the driver in the kernel, while the later not. I
> > > > > > believe that although being abandoned by the spec, the later should also be
> > > > > > considered and supported by the driver, since it is used by the firmwares in the
> > > > > > wild.
> > > > > 
> > > > > This is clear. What's unclear is the necessity of adding this mapping. Is that
> > > > > mapping shuffled in an arbitrary way?
> > > > 
> > > > According to the partial information I currently have, I don't think the mapping
> > > > would shuffle arbitrarily.
> > > > 
> > > > > Second question, why one can't update firmware to fix this to follow the
> > > > > specification? From above DSDT I do *not* see the need in this mapping.
> > > > > Everything can be simply deducted from the number of Interrupt() resources
> > > > > and ngpios at run-time without touching the property.
> > > > 
> > > > I have no idea why on the firmware side the spec was not followed for three
> > > > years. When ignoring this mapping, there would be a problem if the number
> > > > of given Interrupt() resources is less than ngpios. When this mapping is
> > > > referred, there will be a ground truth for which irq number a gpio line
> > > > belongs to. To be specific, suppose the number of Interrupt() resources
> > > > is m and ngpios is n. In the current spec, where m equals to n, such ground
> > > > truth also exists. However, when m is less than n and this mapping is
> > > > ignored, the mapping will become ambiguous. Should the irq number be i%m
> > > > for gpio line i, or i%8 and reject the irq requests when m is less than 8?

It's not true for the HID LOON000D (7A2000 GPIO controller) which is
also handled by this driver.  In that controller, each of GPIO 0-3 has
one dedicated IRQ line but the others GPIOs (4-55) share one IRQ line. 
See https://github.com/AOSC-Tracking/linux/commit/31bd7e208e5b for how I
worked it around downstream.  IIUC reading gsi_idx_map should resolve
the issue for LOON000D as well.

We can also hard code i % 8 or MIN(i, 4) but then we'd need to check the
HID.  I can live with either way.

But in either way I'd want to keep the big sticking-out warning, like
"gsi_idx_map property is deprecated, consider upgrading your firmware"
in this patch.  If we use the hard coded logic it can be "having
Interrupt() resources less than ngpios is deprecated, consider upgrading
your firmware."

Some vendors of Loongson-based board firmwares have a bad tendency to
only issue a firmware update if the OEM pays them for some money like
$100,000 and the OEMs are often reluctant to pay.  Loongson itself does
things better: their own board products receive periodical firmware
update for free.  But Loongson itself does not produce laptops so the
laptops based on Loongson CPU often ships a firmware from such a rogue
vendor, and if the laptop uses a I2C-HID touchpad it will not work
without the LOON000D hack as HID-over-I2C have to use a GPIO as
interrupt source.  Then the users cannot use the upstream kernel.

Yes we should try to punish the rouge vendors (maybe even changing the
warning to "please avoid any product from this firmware vendor in the
future": I do recommend the users to avoid one particular firmware
vendor whenever I have to explain this issue to a frustrated user who
just found the touchpad is not working).  But IMO we shouldn't banish
the users to some "commercial" distros with downstream patches: we'd be
actually "awarding" those rogue firmware vendors by pushing the users to
a commercial solution, as the commerical distro vendors are likely
affiliated with the rogue firmware vendors on the stock market.

-- 
Xi Ruoyao <xry111@xry111.site>

Re: [PATCH RFC] gpio: loongson-64bit: Add back the support for gsi_idx_map

[Andy Shevchenko]

On Mon, Jul 06, 2026 at 01:55:57AM +0800, Xi Ruoyao wrote:
> On Wed, 2026-07-01 at 12:45 +0300, Andy Shevchenko wrote:
> > On Wed, Jul 01, 2026 at 04:56:11PM +0800, Miao Wang wrote:
> > > > 2026年7月1日 16:37，Andy Shevchenko <andriy.shevchenko@linux.intel.com> 写道：
> > > > On Wed, Jul 01, 2026 at 04:07:43PM +0800, Miao Wang wrote:
> > > > > > 2026年7月1日 15:36，Andy Shevchenko <andriy.shevchenko@linux.intel.com> 写道：
> > > > > > On Tue, Jun 30, 2026 at 08:42:43PM +0800, Miao Wang wrote:
> > > > > > > > 2026年6月30日 20:07，Andy Shevchenko <andriy.shevchenko@linux.intel.com> 写道：
> > > > > > > > On Tue, Jun 30, 2026 at 07:45:52AM +0000, Bartosz Golaszewski wrote:
> > > > > > > > > On Mon, 29 Jun 2026 23:05:28 +0200, Miao Wang via B4 Relay
> > > > > > > > > <devnull+shankerwangmiao.gmail.com@kernel.org> said:

...

> > > > > > > > > > This patch adds back the support for gsi_idx_map, which is used in the
> > > > > > > > > > ACPI DSDT table to describe the mapping between the GPIO line number to
> > > > > > > > > > the index of the interrupt number in the declared interrupt resources.
> > > > > > > > > > 
> > > > > > > > > > This property was removed in Loongson CPU Universal Specification for
> > > > > > > > > > Interface Between PC/Server System Firmware and Kernel v4.1 in November,
> > > > > > > > > > 2023, but still in use in firmwares released this year. A sample of
> > > > > > > > > > an affected DSDT entry from a 3C6000 board I'm currently using is:
> > > > > > > > 
> > > > > > > > Oh my gosh, can somebody actually try to consult first with the Linux kernel
> > > > > > > > developers before adding non-standard and wrongly named properties, please?
> > > > > > > 
> > > > > > > Inferred from the time when gsi_idx_map was removed from the spec, I believe
> > > > > > > that the removal might be because the maintainers suggestion against introducing
> > > > > > > gsi_idx_map. However, the firmwares "in the wild" have not followed the change.
> > > > > > 
> > > > > > But what is the outcome of not using that mapping. Do you have something wrong
> > > > > > or not working?
> > > > > 
> > > > > Yes. As shown in the DSDT entry, when the mapping is given by the firmware, the
> > > > > number of given interrupts in _CRS does not equal to ngpios. In my example,
> > > > > ngpios is 32, but the number of interrupts given in _CRS is 8, and the request
> > > > > for irq on gpio lines whose number larger than 8 will fail with -ENXIO. To
> > > > > clarify, the entry is taken from the firmware I am currently using, and the
> > > > > firmware is released on February this year.
> > > > 
> > > > Right, so with the given example everything can be done without using the (now)
> > > > unspecified property. Do you have more examples of DSDT of these platforms?
> > > 
> > > Sorry, I only possess limited number of loongarch devices.

> > Yeah, we definitely need some input from Loongson people.

^^^^

> > > > > > > > > > Device (GPO1) {
> > > > > > > > > > Name (_HID, "LOON000F")
> > > > > > > > > > Name (_CRS, ResourceTemplate () {
> > > > > > > > > >  QWordMemory ( // Omitted, not related
> > > > > > > > > >  )
> > > > > > > > > >  Interrupt (ResourceConsumer, Level, ActiveHigh, Exclusive, ,, ) {
> > > > > > > > > >    0x00000010, 0x00000011, 0x00000012, 0x00000013,
> > > > > > > > > >    0x00000014, 0x00000015, 0x00000016, 0x00000017,
> > > > > > > > > >  }
> > > > > > > > > > Name (_DSD, Package (0x02) {
> > > > > > > > > >  ToUUID ("daffd814-6eba-4d8c-8a91-bc9bbf4aa301")
> > > > > > > > > >  Package (0x03) {
> > > > > > > > > >    Package (0x02) { "gpio_base", 0x50 } // Ignored by the driver
> > > > > > > > 
> > > > > > > > Yes, it's non-standard property. It's a broken one in terms of the style.
> > > > > > > > See DT binding documentation.
> > > > > > > 
> > > > > > > To clarify, I agree that this property should be redundant and ignored by
> > > > > > > the driver and global gpio numbers should be assigned dynamically by the
> > > > > > > kernel.
> > > > > > > 
> > > > > > > > > >    Package (0x02) { "ngpios", 0x20 }
> > > > > > > > > >    Package (0x02) { "gsi_idx_map", Package (0x20) {
> > > > > > > > > >      0, 1, 2, 3, 4, 5, 6, 7,
> > > > > > > > > >      0, 1, 2, 3, 4, 5, 6, 7,
> > > > > > > > > >      0, 1, 2, 3, 4, 5, 6, 7,
> > > > > > > > > >      0, 1, 2, 3, 4, 5, 6, 7,
> > > > > > > > > >    }}
> > > > > > > > > >  }
> > > > > > > > > > }
> > > > > > > > > > }
> > > > > > > > > > 
> > > > > > > > > > As can be seen in the DSDT entry, the mapping is essential for obtaining
> > > > > > > > > > the IRQ number from a GPIO line number. Otherwise, when IRQ is requested
> > > > > > > > > > for the line numbers largers than 7, it will fail with -ENXIO.
> > > > > > > > 
> > > > > > > > This doesn't look good. Why can't we simply hardcode the proper behaviour based
> > > > > > > > on the _HID? The gsi_idx_map seems quite regular and periodic, do you have some
> > > > > > > > other examples with different mapping?
> > > > > > > 
> > > > > > > According to the manual, the gpio controllers in HID LOON0007 and LOON000F are
> > > > > > > actually embedded into the CPU chip and the interrupt lines are hard wired so
> > > > > > > that all the gpio lines of the gpio controller share in total 8 irqs such that
> > > > > > > the i-th line is wired to the (i%8)-th irq. So the mapping for these two models
> > > > > > > are fixed. I have no idea about the behavior of other kinds of controllers, which
> > > > > > > should be answered by Loongson personales.
> > > > > > 
> > > > > > OK.
> > > > > > 
> > > > > > > So far, there are known to be 2 styles of DSDT entries. One is defined by
> > > > > > > the latest Firmware Spec, to list all the irq numbers in _CRS, e.g. Name (_CRS,
> > > > > > > ResourceTemplate () { Interrupt () { 0x10, 0x11, .., 0x17, 0x10, 0x11, ..., 0x17,
> > > > > > > ... (in total ngpios entries) } }). The other is defined by the previous Firmware
> > > > > > > spec, to use the property `gsi_idx_map` to map the gpio line number to the irq
> > > > > > > number listed in the ResourceTemplate. The former should now be compatible with
> > > > > > > the current implementation of the driver in the kernel, while the later not. I
> > > > > > > believe that although being abandoned by the spec, the later should also be
> > > > > > > considered and supported by the driver, since it is used by the firmwares in the
> > > > > > > wild.
> > > > > > 
> > > > > > This is clear. What's unclear is the necessity of adding this mapping. Is that
> > > > > > mapping shuffled in an arbitrary way?
> > > > > 
> > > > > According to the partial information I currently have, I don't think the mapping
> > > > > would shuffle arbitrarily.
> > > > > 
> > > > > > Second question, why one can't update firmware to fix this to follow the
> > > > > > specification? From above DSDT I do *not* see the need in this mapping.
> > > > > > Everything can be simply deducted from the number of Interrupt() resources
> > > > > > and ngpios at run-time without touching the property.
> > > > > 
> > > > > I have no idea why on the firmware side the spec was not followed for three
> > > > > years. When ignoring this mapping, there would be a problem if the number
> > > > > of given Interrupt() resources is less than ngpios. When this mapping is
> > > > > referred, there will be a ground truth for which irq number a gpio line
> > > > > belongs to. To be specific, suppose the number of Interrupt() resources
> > > > > is m and ngpios is n. In the current spec, where m equals to n, such ground
> > > > > truth also exists. However, when m is less than n and this mapping is
> > > > > ignored, the mapping will become ambiguous. Should the irq number be i%m
> > > > > for gpio line i, or i%8 and reject the irq requests when m is less than 8?
> 
> It's not true for the HID LOON000D (7A2000 GPIO controller) which is
> also handled by this driver.  In that controller, each of GPIO 0-3 has
> one dedicated IRQ line but the others GPIOs (4-55) share one IRQ line. 
> See https://github.com/AOSC-Tracking/linux/commit/31bd7e208e5b for how I
> worked it around downstream.  IIUC reading gsi_idx_map should resolve
> the issue for LOON000D as well.
> 
> We can also hard code i % 8 or MIN(i, 4) but then we'd need to check the
> HID.  I can live with either way.
> 
> But in either way I'd want to keep the big sticking-out warning, like
> "gsi_idx_map property is deprecated, consider upgrading your firmware"
> in this patch.  If we use the hard coded logic it can be "having
> Interrupt() resources less than ngpios is deprecated, consider upgrading
> your firmware."

But I am not sure it would work for the case you just described. I don't
remember if duplicates are allowed in the _CRS for the same device, id est
Interrupt(foo) repeated as many times as you need.

> Some vendors of Loongson-based board firmwares have a bad tendency to
> only issue a firmware update if the OEM pays them for some money like
> $100,000 and the OEMs are often reluctant to pay.  Loongson itself does
> things better: their own board products receive periodical firmware
> update for free.  But Loongson itself does not produce laptops so the
> laptops based on Loongson CPU often ships a firmware from such a rogue
> vendor, and if the laptop uses a I2C-HID touchpad it will not work
> without the LOON000D hack as HID-over-I2C have to use a GPIO as
> interrupt source.  Then the users cannot use the upstream kernel.
> 
> Yes we should try to punish the rouge vendors (maybe even changing the
> warning to "please avoid any product from this firmware vendor in the
> future":

We (Linux kernel) are grown from that type of nagging. The polite way is to
dev_warn(dev, FW_BUG) or similar. But this should be confirmed by Loongson.

> I do recommend the users to avoid one particular firmware
> vendor whenever I have to explain this issue to a frustrated user who
> just found the touchpad is not working).  But IMO we shouldn't banish
> the users to some "commercial" distros with downstream patches: we'd be
> actually "awarding" those rogue firmware vendors by pushing the users to
> a commercial solution, as the commerical distro vendors are likely
> affiliated with the rogue firmware vendors on the stock market.

Right.

So, let me state again, we need an input from Loongson on clarification on what
to do with the property. Because what I read from your reply is that property
must stay and specification update was a wrong move.

-- 
With Best Regards,
Andy Shevchenko

Re: [PATCH RFC] gpio: loongson-64bit: Add back the support for gsi_idx_map

[Miao Wang]

Hi,

> 2026年7月6日 13:19，Andy Shevchenko <andriy.shevchenko@linux.intel.com> 写道：
> 
> On Mon, Jul 06, 2026 at 01:55:57AM +0800, Xi Ruoyao wrote:
>> On Wed, 2026-07-01 at 12:45 +0300, Andy Shevchenko wrote:
>>> On Wed, Jul 01, 2026 at 04:56:11PM +0800, Miao Wang wrote:
>>>>> 2026年7月1日 16:37，Andy Shevchenko <andriy.shevchenko@linux.intel.com> 写道：
>>>>> On Wed, Jul 01, 2026 at 04:07:43PM +0800, Miao Wang wrote:
>>>>>>> 2026年7月1日 15:36，Andy Shevchenko <andriy.shevchenko@linux.intel.com> 写道：
>>>>>>> On Tue, Jun 30, 2026 at 08:42:43PM +0800, Miao Wang wrote:
>>>>>>>>> 2026年6月30日 20:07，Andy Shevchenko <andriy.shevchenko@linux.intel.com> 写道：
>>>>>>>>> On Tue, Jun 30, 2026 at 07:45:52AM +0000, Bartosz Golaszewski wrote:
>>>>>>>>>> On Mon, 29 Jun 2026 23:05:28 +0200, Miao Wang via B4 Relay
>>>>>>>>>> <devnull+shankerwangmiao.gmail.com@kernel.org> said:
> 
> ...
> 
>>>>>>>>>>> This patch adds back the support for gsi_idx_map, which is used in the
>>>>>>>>>>> ACPI DSDT table to describe the mapping between the GPIO line number to
>>>>>>>>>>> the index of the interrupt number in the declared interrupt resources.
>>>>>>>>>>> 
>>>>>>>>>>> This property was removed in Loongson CPU Universal Specification for
>>>>>>>>>>> Interface Between PC/Server System Firmware and Kernel v4.1 in November,
>>>>>>>>>>> 2023, but still in use in firmwares released this year. A sample of
>>>>>>>>>>> an affected DSDT entry from a 3C6000 board I'm currently using is:
>>>>>>>>> 
>>>>>>>>> Oh my gosh, can somebody actually try to consult first with the Linux kernel
>>>>>>>>> developers before adding non-standard and wrongly named properties, please?
>>>>>>>> 
>>>>>>>> Inferred from the time when gsi_idx_map was removed from the spec, I believe
>>>>>>>> that the removal might be because the maintainers suggestion against introducing
>>>>>>>> gsi_idx_map. However, the firmwares "in the wild" have not followed the change.
>>>>>>> 
>>>>>>> But what is the outcome of not using that mapping. Do you have something wrong
>>>>>>> or not working?
>>>>>> 
>>>>>> Yes. As shown in the DSDT entry, when the mapping is given by the firmware, the
>>>>>> number of given interrupts in _CRS does not equal to ngpios. In my example,
>>>>>> ngpios is 32, but the number of interrupts given in _CRS is 8, and the request
>>>>>> for irq on gpio lines whose number larger than 8 will fail with -ENXIO. To
>>>>>> clarify, the entry is taken from the firmware I am currently using, and the
>>>>>> firmware is released on February this year.
>>>>> 
>>>>> Right, so with the given example everything can be done without using the (now)
>>>>> unspecified property. Do you have more examples of DSDT of these platforms?
>>>> 
>>>> Sorry, I only possess limited number of loongarch devices.
> 
>>> Yeah, we definitely need some input from Loongson people.
> 
> ^^^^
> 
>>>>>>>>>>> Device (GPO1) {
>>>>>>>>>>> Name (_HID, "LOON000F")
>>>>>>>>>>> Name (_CRS, ResourceTemplate () {
>>>>>>>>>>>  QWordMemory ( // Omitted, not related
>>>>>>>>>>>  )
>>>>>>>>>>>  Interrupt (ResourceConsumer, Level, ActiveHigh, Exclusive, ,, ) {
>>>>>>>>>>>    0x00000010, 0x00000011, 0x00000012, 0x00000013,
>>>>>>>>>>>    0x00000014, 0x00000015, 0x00000016, 0x00000017,
>>>>>>>>>>>  }
>>>>>>>>>>> Name (_DSD, Package (0x02) {
>>>>>>>>>>>  ToUUID ("daffd814-6eba-4d8c-8a91-bc9bbf4aa301")
>>>>>>>>>>>  Package (0x03) {
>>>>>>>>>>>    Package (0x02) { "gpio_base", 0x50 } // Ignored by the driver
>>>>>>>>> 
>>>>>>>>> Yes, it's non-standard property. It's a broken one in terms of the style.
>>>>>>>>> See DT binding documentation.
>>>>>>>> 
>>>>>>>> To clarify, I agree that this property should be redundant and ignored by
>>>>>>>> the driver and global gpio numbers should be assigned dynamically by the
>>>>>>>> kernel.
>>>>>>>> 
>>>>>>>>>>>    Package (0x02) { "ngpios", 0x20 }
>>>>>>>>>>>    Package (0x02) { "gsi_idx_map", Package (0x20) {
>>>>>>>>>>>      0, 1, 2, 3, 4, 5, 6, 7,
>>>>>>>>>>>      0, 1, 2, 3, 4, 5, 6, 7,
>>>>>>>>>>>      0, 1, 2, 3, 4, 5, 6, 7,
>>>>>>>>>>>      0, 1, 2, 3, 4, 5, 6, 7,
>>>>>>>>>>>    }}
>>>>>>>>>>>  }
>>>>>>>>>>> }
>>>>>>>>>>> }
>>>>>>>>>>> 
>>>>>>>>>>> As can be seen in the DSDT entry, the mapping is essential for obtaining
>>>>>>>>>>> the IRQ number from a GPIO line number. Otherwise, when IRQ is requested
>>>>>>>>>>> for the line numbers largers than 7, it will fail with -ENXIO.
>>>>>>>>> 
>>>>>>>>> This doesn't look good. Why can't we simply hardcode the proper behaviour based
>>>>>>>>> on the _HID? The gsi_idx_map seems quite regular and periodic, do you have some
>>>>>>>>> other examples with different mapping?
>>>>>>>> 
>>>>>>>> According to the manual, the gpio controllers in HID LOON0007 and LOON000F are
>>>>>>>> actually embedded into the CPU chip and the interrupt lines are hard wired so
>>>>>>>> that all the gpio lines of the gpio controller share in total 8 irqs such that
>>>>>>>> the i-th line is wired to the (i%8)-th irq. So the mapping for these two models
>>>>>>>> are fixed. I have no idea about the behavior of other kinds of controllers, which
>>>>>>>> should be answered by Loongson personales.
>>>>>>> 
>>>>>>> OK.
>>>>>>> 
>>>>>>>> So far, there are known to be 2 styles of DSDT entries. One is defined by
>>>>>>>> the latest Firmware Spec, to list all the irq numbers in _CRS, e.g. Name (_CRS,
>>>>>>>> ResourceTemplate () { Interrupt () { 0x10, 0x11, .., 0x17, 0x10, 0x11, ..., 0x17,
>>>>>>>> ... (in total ngpios entries) } }). The other is defined by the previous Firmware
>>>>>>>> spec, to use the property `gsi_idx_map` to map the gpio line number to the irq
>>>>>>>> number listed in the ResourceTemplate. The former should now be compatible with
>>>>>>>> the current implementation of the driver in the kernel, while the later not. I
>>>>>>>> believe that although being abandoned by the spec, the later should also be
>>>>>>>> considered and supported by the driver, since it is used by the firmwares in the
>>>>>>>> wild.
>>>>>>> 
>>>>>>> This is clear. What's unclear is the necessity of adding this mapping. Is that
>>>>>>> mapping shuffled in an arbitrary way?
>>>>>> 
>>>>>> According to the partial information I currently have, I don't think the mapping
>>>>>> would shuffle arbitrarily.
>>>>>> 
>>>>>>> Second question, why one can't update firmware to fix this to follow the
>>>>>>> specification? From above DSDT I do *not* see the need in this mapping.
>>>>>>> Everything can be simply deducted from the number of Interrupt() resources
>>>>>>> and ngpios at run-time without touching the property.
>>>>>> 
>>>>>> I have no idea why on the firmware side the spec was not followed for three
>>>>>> years. When ignoring this mapping, there would be a problem if the number
>>>>>> of given Interrupt() resources is less than ngpios. When this mapping is
>>>>>> referred, there will be a ground truth for which irq number a gpio line
>>>>>> belongs to. To be specific, suppose the number of Interrupt() resources
>>>>>> is m and ngpios is n. In the current spec, where m equals to n, such ground
>>>>>> truth also exists. However, when m is less than n and this mapping is
>>>>>> ignored, the mapping will become ambiguous. Should the irq number be i%m
>>>>>> for gpio line i, or i%8 and reject the irq requests when m is less than 8?
>> 
>> It's not true for the HID LOON000D (7A2000 GPIO controller) which is
>> also handled by this driver.  In that controller, each of GPIO 0-3 has
>> one dedicated IRQ line but the others GPIOs (4-55) share one IRQ line. 
>> See https://github.com/AOSC-Tracking/linux/commit/31bd7e208e5b for how I
>> worked it around downstream.  IIUC reading gsi_idx_map should resolve
>> the issue for LOON000D as well.
>> 
>> We can also hard code i % 8 or MIN(i, 4) but then we'd need to check the
>> HID.  I can live with either way.
>> 
>> But in either way I'd want to keep the big sticking-out warning, like
>> "gsi_idx_map property is deprecated, consider upgrading your firmware"
>> in this patch.  If we use the hard coded logic it can be "having
>> Interrupt() resources less than ngpios is deprecated, consider upgrading
>> your firmware."
> 
> But I am not sure it would work for the case you just described. I don't
> remember if duplicates are allowed in the _CRS for the same device, id est
> Interrupt(foo) repeated as many times as you need.
> 
>> Some vendors of Loongson-based board firmwares have a bad tendency to
>> only issue a firmware update if the OEM pays them for some money like
>> $100,000 and the OEMs are often reluctant to pay.  Loongson itself does
>> things better: their own board products receive periodical firmware
>> update for free.  But Loongson itself does not produce laptops so the
>> laptops based on Loongson CPU often ships a firmware from such a rogue
>> vendor, and if the laptop uses a I2C-HID touchpad it will not work
>> without the LOON000D hack as HID-over-I2C have to use a GPIO as
>> interrupt source.  Then the users cannot use the upstream kernel.
>> 
>> Yes we should try to punish the rouge vendors (maybe even changing the
>> warning to "please avoid any product from this firmware vendor in the
>> future":
> 
> We (Linux kernel) are grown from that type of nagging. The polite way is to
> dev_warn(dev, FW_BUG) or similar. But this should be confirmed by Loongson.
> 
>> I do recommend the users to avoid one particular firmware
>> vendor whenever I have to explain this issue to a frustrated user who
>> just found the touchpad is not working).  But IMO we shouldn't banish
>> the users to some "commercial" distros with downstream patches: we'd be
>> actually "awarding" those rogue firmware vendors by pushing the users to
>> a commercial solution, as the commerical distro vendors are likely
>> affiliated with the rogue firmware vendors on the stock market.
> 
> Right.
> 
> So, let me state again, we need an input from Loongson on clarification on what
> to do with the property. Because what I read from your reply is that property
> must stay and specification update was a wrong move.
> 

If Interrupt() repeated in _CRS is allowed, then I don't think it is a wrong
move, but we are considering about existing hardware and firmware which are
not following this change. If repeated Interrupt() is not allowed, then this
would be another story.

Cheers,

Miao Wang

Re: [PATCH RFC] gpio: loongson-64bit: Add back the support for gsi_idx_map

[Xi Ruoyao]

On Mon, 2026-07-06 at 19:43 +0800, Miao Wang wrote:
> Hi,
> 
> > 2026年7月6日 13:19，Andy Shevchenko <andriy.shevchenko@linux.intel.com> 写道：
> > 
> > On Mon, Jul 06, 2026 at 01:55:57AM +0800, Xi Ruoyao wrote:
> > > On Wed, 2026-07-01 at 12:45 +0300, Andy Shevchenko wrote:
> > > > On Wed, Jul 01, 2026 at 04:56:11PM +0800, Miao Wang wrote:
> > > > > > 2026年7月1日 16:37，Andy Shevchenko <andriy.shevchenko@linux.intel.com> 写道：
> > > > > > On Wed, Jul 01, 2026 at 04:07:43PM +0800, Miao Wang wrote:
> > > > > > > > 2026年7月1日 15:36，Andy Shevchenko <andriy.shevchenko@linux.intel.com> 写道：
> > > > > > > > On Tue, Jun 30, 2026 at 08:42:43PM +0800, Miao Wang wrote:
> > > > > > > > > > 2026年6月30日 20:07，Andy Shevchenko <andriy.shevchenko@linux.intel.com> 写道：
> > > > > > > > > > On Tue, Jun 30, 2026 at 07:45:52AM +0000, Bartosz Golaszewski wrote:
> > > > > > > > > > > On Mon, 29 Jun 2026 23:05:28 +0200, Miao Wang via B4 Relay
> > > > > > > > > > > <devnull+shankerwangmiao.gmail.com@kernel.org> said:
> > 
> > ...
> > 
> > > > > > > > > > > > This patch adds back the support for gsi_idx_map, which is used in the
> > > > > > > > > > > > ACPI DSDT table to describe the mapping between the GPIO line number to
> > > > > > > > > > > > the index of the interrupt number in the declared interrupt resources.
> > > > > > > > > > > > 
> > > > > > > > > > > > This property was removed in Loongson CPU Universal Specification for
> > > > > > > > > > > > Interface Between PC/Server System Firmware and Kernel v4.1 in November,
> > > > > > > > > > > > 2023, but still in use in firmwares released this year. A sample of
> > > > > > > > > > > > an affected DSDT entry from a 3C6000 board I'm currently using is:
> > > > > > > > > > 
> > > > > > > > > > Oh my gosh, can somebody actually try to consult first with the Linux kernel
> > > > > > > > > > developers before adding non-standard and wrongly named properties, please?
> > > > > > > > > 
> > > > > > > > > Inferred from the time when gsi_idx_map was removed from the spec, I believe
> > > > > > > > > that the removal might be because the maintainers suggestion against introducing
> > > > > > > > > gsi_idx_map. However, the firmwares "in the wild" have not followed the change.
> > > > > > > > 
> > > > > > > > But what is the outcome of not using that mapping. Do you have something wrong
> > > > > > > > or not working?
> > > > > > > 
> > > > > > > Yes. As shown in the DSDT entry, when the mapping is given by the firmware, the
> > > > > > > number of given interrupts in _CRS does not equal to ngpios. In my example,
> > > > > > > ngpios is 32, but the number of interrupts given in _CRS is 8, and the request
> > > > > > > for irq on gpio lines whose number larger than 8 will fail with -ENXIO. To
> > > > > > > clarify, the entry is taken from the firmware I am currently using, and the
> > > > > > > firmware is released on February this year.
> > > > > > 
> > > > > > Right, so with the given example everything can be done without using the (now)
> > > > > > unspecified property. Do you have more examples of DSDT of these platforms?
> > > > > 
> > > > > Sorry, I only possess limited number of loongarch devices.
> > 
> > > > Yeah, we definitely need some input from Loongson people.
> > 
> > ^^^^
> > 
> > > > > > > > > > > > Device (GPO1) {
> > > > > > > > > > > > Name (_HID, "LOON000F")
> > > > > > > > > > > > Name (_CRS, ResourceTemplate () {
> > > > > > > > > > > >  QWordMemory ( // Omitted, not related
> > > > > > > > > > > >  )
> > > > > > > > > > > >  Interrupt (ResourceConsumer, Level, ActiveHigh, Exclusive, ,, ) {
> > > > > > > > > > > >    0x00000010, 0x00000011, 0x00000012, 0x00000013,
> > > > > > > > > > > >    0x00000014, 0x00000015, 0x00000016, 0x00000017,
> > > > > > > > > > > >  }
> > > > > > > > > > > > Name (_DSD, Package (0x02) {
> > > > > > > > > > > >  ToUUID ("daffd814-6eba-4d8c-8a91-bc9bbf4aa301")
> > > > > > > > > > > >  Package (0x03) {
> > > > > > > > > > > >    Package (0x02) { "gpio_base", 0x50 } // Ignored by the driver
> > > > > > > > > > 
> > > > > > > > > > Yes, it's non-standard property. It's a broken one in terms of the style.
> > > > > > > > > > See DT binding documentation.
> > > > > > > > > 
> > > > > > > > > To clarify, I agree that this property should be redundant and ignored by
> > > > > > > > > the driver and global gpio numbers should be assigned dynamically by the
> > > > > > > > > kernel.
> > > > > > > > > 
> > > > > > > > > > > >    Package (0x02) { "ngpios", 0x20 }
> > > > > > > > > > > >    Package (0x02) { "gsi_idx_map", Package (0x20) {
> > > > > > > > > > > >      0, 1, 2, 3, 4, 5, 6, 7,
> > > > > > > > > > > >      0, 1, 2, 3, 4, 5, 6, 7,
> > > > > > > > > > > >      0, 1, 2, 3, 4, 5, 6, 7,
> > > > > > > > > > > >      0, 1, 2, 3, 4, 5, 6, 7,
> > > > > > > > > > > >    }}
> > > > > > > > > > > >  }
> > > > > > > > > > > > }
> > > > > > > > > > > > }
> > > > > > > > > > > > 
> > > > > > > > > > > > As can be seen in the DSDT entry, the mapping is essential for obtaining
> > > > > > > > > > > > the IRQ number from a GPIO line number. Otherwise, when IRQ is requested
> > > > > > > > > > > > for the line numbers largers than 7, it will fail with -ENXIO.
> > > > > > > > > > 
> > > > > > > > > > This doesn't look good. Why can't we simply hardcode the proper behaviour based
> > > > > > > > > > on the _HID? The gsi_idx_map seems quite regular and periodic, do you have some
> > > > > > > > > > other examples with different mapping?
> > > > > > > > > 
> > > > > > > > > According to the manual, the gpio controllers in HID LOON0007 and LOON000F are
> > > > > > > > > actually embedded into the CPU chip and the interrupt lines are hard wired so
> > > > > > > > > that all the gpio lines of the gpio controller share in total 8 irqs such that
> > > > > > > > > the i-th line is wired to the (i%8)-th irq. So the mapping for these two models
> > > > > > > > > are fixed. I have no idea about the behavior of other kinds of controllers, which
> > > > > > > > > should be answered by Loongson personales.
> > > > > > > > 
> > > > > > > > OK.
> > > > > > > > 
> > > > > > > > > So far, there are known to be 2 styles of DSDT entries. One is defined by
> > > > > > > > > the latest Firmware Spec, to list all the irq numbers in _CRS, e.g. Name (_CRS,
> > > > > > > > > ResourceTemplate () { Interrupt () { 0x10, 0x11, .., 0x17, 0x10, 0x11, ..., 0x17,
> > > > > > > > > ... (in total ngpios entries) } }). The other is defined by the previous Firmware
> > > > > > > > > spec, to use the property `gsi_idx_map` to map the gpio line number to the irq
> > > > > > > > > number listed in the ResourceTemplate. The former should now be compatible with
> > > > > > > > > the current implementation of the driver in the kernel, while the later not. I
> > > > > > > > > believe that although being abandoned by the spec, the later should also be
> > > > > > > > > considered and supported by the driver, since it is used by the firmwares in the
> > > > > > > > > wild.
> > > > > > > > 
> > > > > > > > This is clear. What's unclear is the necessity of adding this mapping. Is that
> > > > > > > > mapping shuffled in an arbitrary way?
> > > > > > > 
> > > > > > > According to the partial information I currently have, I don't think the mapping
> > > > > > > would shuffle arbitrarily.
> > > > > > > 
> > > > > > > > Second question, why one can't update firmware to fix this to follow the
> > > > > > > > specification? From above DSDT I do *not* see the need in this mapping.
> > > > > > > > Everything can be simply deducted from the number of Interrupt() resources
> > > > > > > > and ngpios at run-time without touching the property.
> > > > > > > 
> > > > > > > I have no idea why on the firmware side the spec was not followed for three
> > > > > > > years. When ignoring this mapping, there would be a problem if the number
> > > > > > > of given Interrupt() resources is less than ngpios. When this mapping is
> > > > > > > referred, there will be a ground truth for which irq number a gpio line
> > > > > > > belongs to. To be specific, suppose the number of Interrupt() resources
> > > > > > > is m and ngpios is n. In the current spec, where m equals to n, such ground
> > > > > > > truth also exists. However, when m is less than n and this mapping is
> > > > > > > ignored, the mapping will become ambiguous. Should the irq number be i%m
> > > > > > > for gpio line i, or i%8 and reject the irq requests when m is less than 8?
> > > 
> > > It's not true for the HID LOON000D (7A2000 GPIO controller) which is
> > > also handled by this driver.  In that controller, each of GPIO 0-3 has
> > > one dedicated IRQ line but the others GPIOs (4-55) share one IRQ line. 
> > > See https://github.com/AOSC-Tracking/linux/commit/31bd7e208e5b for how I
> > > worked it around downstream.  IIUC reading gsi_idx_map should resolve
> > > the issue for LOON000D as well.
> > > 
> > > We can also hard code i % 8 or MIN(i, 4) but then we'd need to check the
> > > HID.  I can live with either way.
> > > 
> > > But in either way I'd want to keep the big sticking-out warning, like
> > > "gsi_idx_map property is deprecated, consider upgrading your firmware"
> > > in this patch.  If we use the hard coded logic it can be "having
> > > Interrupt() resources less than ngpios is deprecated, consider upgrading
> > > your firmware."
> > 
> > But I am not sure it would work for the case you just described. I don't
> > remember if duplicates are allowed in the _CRS for the same device, id est
> > Interrupt(foo) repeated as many times as you need.
> > 
> > > Some vendors of Loongson-based board firmwares have a bad tendency to
> > > only issue a firmware update if the OEM pays them for some money like
> > > $100,000 and the OEMs are often reluctant to pay.  Loongson itself does
> > > things better: their own board products receive periodical firmware
> > > update for free.  But Loongson itself does not produce laptops so the
> > > laptops based on Loongson CPU often ships a firmware from such a rogue
> > > vendor, and if the laptop uses a I2C-HID touchpad it will not work
> > > without the LOON000D hack as HID-over-I2C have to use a GPIO as
> > > interrupt source.  Then the users cannot use the upstream kernel.
> > > 
> > > Yes we should try to punish the rouge vendors (maybe even changing the
> > > warning to "please avoid any product from this firmware vendor in the
> > > future":
> > 
> > We (Linux kernel) are grown from that type of nagging. The polite way is to
> > dev_warn(dev, FW_BUG) or similar. But this should be confirmed by Loongson.
> > 
> > > I do recommend the users to avoid one particular firmware
> > > vendor whenever I have to explain this issue to a frustrated user who
> > > just found the touchpad is not working).  But IMO we shouldn't banish
> > > the users to some "commercial" distros with downstream patches: we'd be
> > > actually "awarding" those rogue firmware vendors by pushing the users to
> > > a commercial solution, as the commerical distro vendors are likely
> > > affiliated with the rogue firmware vendors on the stock market.
> > 
> > Right.
> > 
> > So, let me state again, we need an input from Loongson on clarification on what
> > to do with the property. Because what I read from your reply is that property
> > must stay and specification update was a wrong move.
> > 
> 
> If Interrupt() repeated in _CRS is allowed, then I don't think it is a wrong
> move, but we are considering about existing hardware and firmware which are
> not following this change. If repeated Interrupt() is not allowed, then this
> would be another story.

If repeated Interrupt() is not allowed (I'm unsure yet if it's allowed
too) we can still use the hard coded logic like m % 8 or MIN(m, 4)
instead of gsi_idx_map.  AFAIK these mappings are hard-wired in the chip
(i.e. not programmable by the firmware) so having the _HID is enough.


-- 
Xi Ruoyao <xry111@xry111.site>

Re: [PATCH RFC] gpio: loongson-64bit: Add back the support for gsi_idx_map

[Miao Wang]

> 2026年7月6日 22:26，Xi Ruoyao <xry111@xry111.site> 写道：
> 
> On Mon, 2026-07-06 at 19:43 +0800, Miao Wang wrote:
>> Hi,
>>> 
>>> Right.
>>> 
>>> So, let me state again, we need an input from Loongson on clarification on what
>>> to do with the property. Because what I read from your reply is that property
>>> must stay and specification update was a wrong move.
>>> 
>> 
>> If Interrupt() repeated in _CRS is allowed, then I don't think it is a wrong
>> move, but we are considering about existing hardware and firmware which are
>> not following this change. If repeated Interrupt() is not allowed, then this
>> would be another story.
> 
> If repeated Interrupt() is not allowed (I'm unsure yet if it's allowed
> too) we can still use the hard coded logic like m % 8 or MIN(m, 4)
> instead of gsi_idx_map.  AFAIK these mappings are hard-wired in the chip
> (i.e. not programmable by the firmware) so having the _HID is enough.

So will this PoC work? When irq resources cannot be fetched directly, try
to use a static backup mapping instead.

diff --git a/drivers/gpio/gpio-loongson-64bit.c b/drivers/gpio/gpio-loongson-64bit.c
index 0fdf15faa344..5de05c61cc82 100644
--- a/drivers/gpio/gpio-loongson-64bit.c
+++ b/drivers/gpio/gpio-loongson-64bit.c
@@ -24,6 +24,12 @@ enum loongson_gpio_mode {
 	BYTE_CTRL_MODE,
 };
 
+enum loongson_gpio_mapping_mode {
+	MAPPING_NONE,
+	MAPPING_MODULO,
+	MAPPING_CLAMP,
+};
+
 struct loongson_gpio_chip_data {
 	const char		*label;
 	enum loongson_gpio_mode	mode;
@@ -37,6 +43,7 @@ struct loongson_gpio_chip_data {
 	unsigned int		intsts_offset;
 	unsigned int		intdual_offset;
 	unsigned int		intr_num;
+	enum loongson_gpio_mapping_mode mapping_mode;
 	irq_flow_handler_t	irq_handler;
 	const struct irq_chip	*girqchip;
 };
@@ -130,11 +137,23 @@ static int loongson_gpio_set(struct gpio_chip *chip, unsigned int pin, int value
 	return 0;
 }
 
+static unsigned int loongson_gpio_backup_irq_mapping(const struct loongson_gpio_chip_data *chip_data,
+						     unsigned int pin)
+{
+	if (chip_data->mapping_mode == MAPPING_MODULO)
+		return pin % chip_data->intr_num;
+	else if (chip_data->mapping_mode == MAPPING_CLAMP)
+		return MIN(pin, chip_data->intr_num - 1);
+
+	return pin;
+}
+
 static int loongson_gpio_to_irq(struct gpio_chip *chip, unsigned int offset)
 {
 	unsigned int u;
 	struct platform_device *pdev = to_platform_device(chip->parent);
 	struct loongson_gpio_chip *lgpio = to_loongson_gpio_chip(chip);
+	int irq;
 
 	if (lgpio->chip_data->mode == BIT_CTRL_MODE) {
 		/* Get the register index from offset then multiply by bytes per register */
@@ -145,7 +164,13 @@ static int loongson_gpio_to_irq(struct gpio_chip *chip, unsigned int offset)
 		writeb(1, lgpio->reg_base + lgpio->chip_data->inten_offset + offset);
 	}
 
-	return platform_get_irq(pdev, offset);
+	irq = platform_get_irq_optional(pdev, offset);
+	if (irq == -ENXIO && lgpio->chip_data->intr_num != 0) {
+		irq = platform_get_irq(pdev, loongson_gpio_backup_irq_mapping(lgpio->chip_data, offset));
+	} else if (irq < 0) {
+		irq = platform_get_irq(pdev, offset);
+	}
+	return irq;
 }
 
 static void loongson_gpio_irq_ack(struct irq_data *data)
@@ -430,6 +455,8 @@ static const struct loongson_gpio_chip_data loongson_gpio_ls3a5000_data = {
 	.in_offset = 0xc,
 	.out_offset = 0x8,
 	.inten_offset = 0x14,
+	.intr_num = 8,
+	.mapping_mode = MAPPING_MODULO,
 };
 
 static const struct loongson_gpio_chip_data loongson_gpio_ls7a_data = {
@@ -439,6 +466,8 @@ static const struct loongson_gpio_chip_data loongson_gpio_ls7a_data = {
 	.in_offset = 0xa00,
 	.out_offset = 0x900,
 	.inten_offset = 0xb00,
+	.intr_num = 5,
+	.mapping_mode = MAPPING_CLAMP,
 };
 
 /* LS7A2000 chipset GPIO */
@@ -468,6 +497,8 @@ static const struct loongson_gpio_chip_data loongson_gpio_ls3a6000_data = {
 	.in_offset = 0xc,
 	.out_offset = 0x8,
 	.inten_offset = 0x14,
+	.intr_num = 8,
+	.mapping_mode = MAPPING_MODULO,
 };
 
 static const struct of_device_id loongson_gpio_of_match[] = {