[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20190212090835.GD7875@lahna.fi.intel.com>
Date: Tue, 12 Feb 2019 11:08:35 +0200
From: Mika Westerberg <mika.westerberg@...ux.intel.com>
To: egranata@...omium.org
Cc: hdegoede@...hat.com, dtor@...omium.org, andy.shevchenko@...il.com,
rafael@...nel.org, gregkh@...uxfoundation.org,
enric.balletbo@...labora.com, linux-kernel@...r.kernel.org,
gwendal@...omium.org, linux-acpi@...r.kernel.org,
briannorris@...omium.org, andriy.shevchenko@...ux.intel.com,
egranata@...gle.com
Subject: Re: [PATCH v2] driver: platform: Support parsing GpioInt 0 in
platform_get_irq()
On Mon, Feb 11, 2019 at 11:01:12AM -0800, egranata@...omium.org wrote:
> From: Enrico Granata <egranata@...omium.org>
>
> 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. This requires drivers to
> either have to support only one possible IRQ resource, or to have code
> in place to try both as a failsafe.
>
> While there is a possibility of ambiguity for devices that exposes
> multiple IRQs, it is easy and feasible to support the common case
> of devices that only expose one IRQ which would be of either type
> depending on the underlying system's architecture.
>
> This commit adds support for parsing a GpioInt resource in order
> to fulfill a request for the index 0 IRQ for a platform device.
>
> Signed-off-by: Enrico Granata <egranata@...omium.org>
Reviewed-by: Mika Westerberg <mika.westerberg@...ux.intel.com>
Powered by blists - more mailing lists