From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andy Shevchenko Subject: Re: [PATCH] driver: platform: Add support for GpioInt() ACPI to platform_get_irq() Date: Thu, 7 Feb 2019 21:39:25 +0200 Message-ID: References: <20190207185917.167829-1-egranata@google.com> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Return-path: In-Reply-To: Sender: linux-kernel-owner@vger.kernel.org To: "Rafael J. Wysocki" Cc: egranata@google.com, Greg Kroah-Hartman , Enric Balletbo i Serra , Linux Kernel Mailing List , Gwendal Grignou , Dmitry Torokhov , ACPI Devel Maling List , Brian Norris , Enrico Granata , Mika Westerberg , Andy Shevchenko , Hans de Goede List-Id: linux-acpi@vger.kernel.org On Thu, Feb 7, 2019 at 9:04 PM Rafael J. Wysocki wrote: > > +Mika Westerberg > +Andy Shevchenko > +Hans de Goede Thanks, Rafael. My comments below. > On Thu, Feb 7, 2019 at 7:59 PM wrote: > > > > From: Enrico Granata > > > > ACPI 5 added support for GpioInt resources as a way to provide > > information about interrupts mediated via a GPIO controller. > > > > Several device buses (e.g. SPI, I2C) have support for retrieving > > an IRQ specified via this type of resource, and providing it > > directly to the driver as an IRQ number. > > This is not currently done for the platform drivers, as platform_get_irq() > > does not try to parse GpioInt() resources. And why is this a problem? > > This commit adds that functionality. How that can override the configuration / BIOS flavour when driver needs to register an interrupt out of GpioIo() resource? P.S. Have you looked at drivers/platform/x86/i2c-multi-instantiate.c and intel_cht_int33fe.c? They are the only drivers which needs something like this for now and I would rather say it's a bad BIOS decision to write a table like that. -- With Best Regards, Andy Shevchenko