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

[Miao Wang <shankerwangmiao@gmail.com>]

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?
>