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: > > 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. > > 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
