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

[Andy Shevchenko <andriy.shevchenko@linux.intel.com>]

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