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

[Miao Wang <shankerwangmiao@gmail.com>]

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