On Wed, Mar 03, 2021 at 04:45:09PM +0800, Shawn Guo wrote:

On Wed, Mar 03, 2021 at 10:06:53AM +0200, Andy Shevchenko wrote:

quoted

Since the mapping of those wake IRQs is totally platform specific, it needs a
platform driver. On above mentioned x86 platforms we have a one you may take as
an example (good or bad it's another story):
drivers/platform/x86/intel_int0002_vgpio.c.

I think you will need something like this somewhere in ARM platform
infrastructure in the Linux kernel.

Well, you have the Virtual GPIO controller defined in ACPI as device
"INT0002", but we do not have such a thing.  I'm not sure it makes much
sense to create a baseless driver.

It has similarities and differences. In your case you need to have somewhere
some piece of the code that will do proper things, but it shouldn't be GPIO
ACPI layer.

quoted

That said, I don't see that those numbers are "broken", they have their own
meaning and specific mapping to the real GPIOs and it's so platform specific,
that we can't treat it as a quirk.

Those numbers have their own meaning only for Windows.  It's OS specific
rather than platform specific.

Platform is a combination of hardware, PCB and uC firmwares. AFAIU that
platform was never designed for use in Linux, correct? So, it is not the same
as any other platform on the same SoC.

Snapdragon platform manual has explicit
numbering of every single GPIO pin.  Those broken numbers in ACPI table
violate the hardware specification and are *broken* to Linux which
implements GPIO driver properly.

No, they are not broken. They have a specific (Windows way) meaning. There is
no quirk implied.

-- 
With Best Regards,
Andy Shevchenko