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]

Date:	Wed, 25 Mar 2015 14:25:05 +0200
From:	Mika Westerberg <mika.westerberg@...ux.intel.com>
To:	Linus Walleij <linus.walleij@...aro.org>
Cc:	Lars-Peter Clausen <lars@...afoo.de>,
	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 Wed, Mar 25, 2015 at 11:43:27AM +0200, Mika Westerberg wrote:
> On Wed, Mar 25, 2015 at 09:44:34AM +0100, Linus Walleij wrote:
> > On Tue, Mar 24, 2015 at 4:06 PM, Mika Westerberg
> > <mika.westerberg@...ux.intel.com> wrote:
> > 
> > > 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.
> > 
> > In the DT usecase we actually specify that in the DTS file
> > so we don't have the problem. Either the consumer accesses
> > the irqchip API with:
> > 
> > interrupts = <nn nn>;
> > 
> > or it accesses the GPIO API with:
> > 
> > gpios = <nn nn>;
> 
> OK, I see.
> 
> > so in that sense it is clear what is requested. Then the core
> > of course uses gpiochip_lock/unlock_as_irq() to handle the
> > case where bugs make a collision (like if both were specified
> > and both APIs tries to access the same resource).
> 
> Where in the core code gpiochip_lock/unlock_as_irq() is called for
> these? At least of_irq_get() doesn't seem to be doing that. Maybe I'm
> looking at the wrong place.

Answering my own question: of_irq_get() just translates the IRQ number
to the corresponding Linux IRQ number. Then when a driver calls
request_irq() irqchip callbacks for this GPIO controller (or generic
GPIO irqchip helpers) will lock the GPIO as IRQ.

I think we can do the same for ACPI GpioInts so that we introduce
acpi_gpio_irq_get() that translates from GpioInt to Linux IRQ
numberspace. Then we can do something like below in I2C core:

	if (client->irq <= 0) {
		int irq = -ENOENT;

                if (dev->of_node)
                        irq = of_irq_get(dev->of_node, 0);
                else if (ACPI_COMPANION(dev))
                        irq = acpi_gpio_irq_get(ACPI_COMPANION(dev), 0);

		if (irq == -EPROBE_DEFER)
                        return irq;
                if (irq < 0)
                        irq = 0;

                client->irq = irq;
	}

Now it has the drawback that the first GpioInt will not be available to
the driver anymore (as a GPIO since it is locked) but if DT already does
the same we should be fine.
--
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/