Resending as plain text; comments inlined. On Thu, Feb 7, 2019 at 11:39 AM Andy Shevchenko <andy.shevchenko@xxxxxxxxx> wrote: > > On Thu, Feb 7, 2019 at 9:04 PM Rafael J. Wysocki <rafael@xxxxxxxxxx> wrote: > > > > +Mika Westerberg > > +Andy Shevchenko > > +Hans de Goede > > Thanks, Rafael. > My comments below. > > > On Thu, Feb 7, 2019 at 7:59 PM <egranata@xxxxxxxxxx> wrote: > > > > > > From: Enrico Granata <egranata@xxxxxxxxxxxx> > > > > > > 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? In ChromeOS, we have a driver (cros_ec_lpc) which can run either on systems that directly expose the interrupt, or systems where the interrupt goes through a GPIO controller. On the former, firmware provides an Interrupt resource and platform_get_irq() finds it. On the latter, firmware provides a GpioInt resource and platform_get_irq does not find it. We could work around this in the driver by probing both paths, but since other subsystems seem to directly look for GpioInt resources, it seemed to us to make more sense to extend platform_get_irq() instead. > > > 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? Those drivers seem to only ever expect a GpioInt(). Our case is one where both are possible, depending on the system we're running on. We are trying not to put ad-hoc logic in the driver, but if you think that doing so would be our best course of action, please do let us know. > 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. Do you have any suggestions to write proper firmware tables to avoid this issue? > > -- > With Best Regards, > Andy Shevchenko
