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: <CACRpkdaOQ-onkgQJSyoVEQNtkZ9nF_4z=9jNdU-tug-TwvAAkQ@mail.gmail.com>
Date:	Tue, 24 Mar 2015 14:57:49 +0100
From:	Linus Walleij <linus.walleij@...aro.org>
To:	Lars-Peter Clausen <lars@...afoo.de>
Cc:	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>
Subject: Re: [PATCH] IIO: Adds ACPI support for ST gyroscopes

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?

Yours,
Linus Walleij
--
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ