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:	Mon, 30 Mar 2015 12:52:54 +0300
From:	Mika Westerberg <mika.westerberg@...ux.intel.com>
To:	Linus Walleij <linus.walleij@...aro.org>
Cc:	Octavian Purdila <octavian.purdila@...el.com>,
	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 Fri, Mar 27, 2015 at 11:36:25AM +0100, Linus Walleij wrote:
> On Fri, Mar 27, 2015 at 11:06 AM, Mika Westerberg
> <mika.westerberg@...ux.intel.com> wrote:
> > On Thu, Mar 26, 2015 at 06:28:19PM +0200, Octavian Purdila wrote:
> 
> >> For the sleep case I think the GPIO controller needs to do the pin
> >> enable and set input direction operation in it's irq_bus_sync_unlock.
> >
> > I wonder how DT handles all this? Is it the boot firmware that sets up
> > the pins accordingly or is there something we are missing?
> 
> DT systems mostly do not have firmware for power usecases, they
> handle it all using pin control. I would more say that is a feature of
> all-SW systems without power-firmware ideas, without ACPI and
> without PSCI (well PSCI systems do not care about much more
> than CPU power down in firmware anyway...)

OK, thanks.

In case of ACPI (where firmware does lot more) it is supposed to
configure pins based on what is connected, if the firmware knows that.
Due to bugs in the boot firmware that obviously does not happen in all
cases (like this one).

If we want to support requesting IRQ directly through irqchip interface
on ACPI systems there needs to be some way the GPIO/pinctrl core can use
to turn the pin as input, GPIO mode.

Octavian's patch does that but not sure if it is good idea for non-ACPI
systems as they already work. We could also do the same in GPIO/irqchip
drivers but there is no guarantee for the caller that it is done. IMHO
safest option is to explictly request the GPIO, turn it input and then
convert the GPIO to interrupt. That way we know the pin is configured
just like we expect.
--
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/