linux-kernel - Re: [PATCH] IIO: Adds ACPI support for ST gyroscopes

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <55119429.6070806@metafoo.de>
Date:	Tue, 24 Mar 2015 17:43:21 +0100
From:	Lars-Peter Clausen <lars@...afoo.de>
To:	Mika Westerberg <mika.westerberg@...ux.intel.com>
CC:	Linus Walleij <linus.walleij@...aro.org>,
	Robert Dolca <robert.dolca@...il.com>,
	Robert Dolca <robert.dolca@...el.com>,
	"linux-iio@...r.kernel.org" <linux-iio@...r.kernel.org>,
	Jonathan Cameron <jic23@...nel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	Hartmut Knaack <knaack.h@....de>,
	Peter Meerwald <pmeerw@...erw.net>,
	Denis CIOCCA <denis.ciocca@...com>,
	"linux-gpio@...r.kernel.org" <linux-gpio@...r.kernel.org>,
	Alexandre Courbot <gnurou@...il.com>
Subject: Re: [PATCH] IIO: Adds ACPI support for ST gyroscopes

On 03/24/2015 04:55 PM, Mika Westerberg wrote:
> On Tue, Mar 24, 2015 at 04:22:16PM +0100, Lars-Peter Clausen wrote:
>> Add Alexandre and linux-gpio to Cc.
>>
>> On 03/24/2015 04:06 PM, Mika Westerberg wrote:
>>> On Tue, Mar 24, 2015 at 02:57:49PM +0100, Linus Walleij wrote:
>>>> On Tue, Mar 24, 2015 at 2:38 PM, Lars-Peter Clausen <lars@...afoo.de> wrote:
>>>>> On 03/24/2015 02:26 PM, Robert Dolca wrote:
>>>>>> On Tue, Mar 24, 2015 at 2:17 PM, Lars-Peter Clausen <lars@...afoo.de>
>>>>>> wrote:
>>>>
>>>>>> In the ACPI description you specify one or more IRQ GPIO pins. In the
>>>>>> driver you request the GPIO pin using the index. In the ACPI 5.1
>>>>>> specification you can use named GPIOs instead of index.
>>>>>
>>>>>
>>>>> But is there a way to distinguish between IRQ GPIOs and non IRQ GPIOs? If it
>>>>> is clear that a certain GPIO is the IRQ for the device the I2C framework
>>>>> should take care of assigning the client->irq field, instead of doing it
>>>>> manually in each and every device driver.
>>>>
>>>> In the device tree case we have a mechanism where each
>>>> GPIO chip implements two API:s, one gpio_chip API and
>>>> one irqchip API.
>>>>
>>>> Then in the tree both the GPIO and IRQs can be assigned as
>>>> resources to clients, orthogonally. Usually this will only work
>>>> if there is a 1-to-1 correspondence between the GPIO lines
>>>> and available IRQ line triggers on the GPIO chip, but that is
>>>> indeed the most common. They will then usually also have
>>>> the same line offset numbers. In some odd cases I guess it
>>>> won't work this way.
>>>>
>>>> The I2C subsystem does this for the device tree case in
>>>> i2c_device_probe() like this:
>>>>
>>>>   if (!client->irq && dev->of_node) {
>>>>                  int irq = of_irq_get(dev->of_node, 0);
>>>>
>>>>                  if (irq == -EPROBE_DEFER)
>>>>                          return irq;
>>>>                  if (irq < 0)
>>>>                          irq = 0;
>>>>
>>>>                  client->irq = irq;
>>>>          }
>>>>
>>>> This is why the code does not contain any OF/DT
>>>> IRQ assignment code.
>>>>
>>>> However in the ACPI probe path I guess it doesn't
>>>> happen then?
>>>
>>> In ACPI we have two kind of GPIOs: GpioIo and GpioInt. The latter is
>>> used to describe GPIOs that can be used as interrupts.
>>>
>>> In order to translate a GpioInt to an interrupt number we would need to
>>> request the GPIO first here (in the I2C core), call gpiod_to_irq() to it
>>> and assign that to the client->irq.
>>
>> Maybe the API can be extended to support to translate a GPIO to a IRQ
>> without actually requesting the GPIO first.
>
> We still need to take care the the GPIO is properly requested and locked
> as IRQ. Otherwise something else (userspace for example) can mess this
> up.
>
>>>
>>> This has few problems that I have not yet figured out. Maybe someone
>>> here can suggest what to do:
>>>
>>>   1) Who is responsible in releasing the GPIO?
>>>   2) What if the driver wants to use that pin as a GPIO instead? The GPIO
>>>      is already requested by the I2C core.
>>>   3) We may have multiple GpioInts for devices like GPIO button array.
>>>      Which one we should pick, or should we let the driver to handle this
>>>      separetely?
>>
>> Well, we have the same issue with devicetree already. I'd say use the first
>> IRQ for client->irq and ignore the other ones for now.
>
> For devices like the button array above doing that leaves the driver
> wondering where the heck is one of my GPIOs :-) Perhaps we could to
> automatic translation if we find out that there is only one GpioInt for
> this device.

Btw. in the ACPI case client->irq is already initialized by 
acpi_dev_resource_interrupt() in the I2C core. Should the GpioInts just map 
onto this API as well?

- Lars

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/