linux-kernel - Re: [PATCH 1/2] gpio: max732x: Propagate wake-up setting to parent irq controller

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 for Android: free password hash cracker in your pocket

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

Date:	Mon, 4 May 2015 21:23:06 +0300
From:	Sam Protsenko <semen.protsenko@...ballogic.com>
To:	Linus Walleij <linus.walleij@...aro.org>
Cc:	Alexandre Courbot <gnurou@...il.com>,
	"linux-gpio@...r.kernel.org" <linux-gpio@...r.kernel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 1/2] gpio: max732x: Propagate wake-up setting to parent
 irq controller

On Mon, May 4, 2015 at 4:32 PM, Linus Walleij <linus.walleij@...aro.org> wrote:

> Are these real, observed issues?

The issue was observed for PCF857x expander (not by me), and it's described in
this commit: b80eef95beb04760629822fa130aeed54cdfafca .

It seems to me that the issue is real. But we need some really particular
hardware configuration and particular use-case to reproduce it. As I understand
from commit message (for mentioned commit), this issue was catch on
system with "arch/arm/boot/dts/sh73a0-kzm9g-reference.dts" device tree file.
As you can see from that file, there is a keyboard ("gpio-keys") connected
to PCF8575 expander. In order to wake system up from keyboard event (key
pressed), parent interrupt controller ("interrupt-parent" field in "pcf8575"
node) should has the same wake-up settings as PCF8575 has.

So this issue may affect other expanders (like MAX732X) as well. I haven't
tested if it's true (only validated that everything works fine with this patch).
I'm now in the middle of building my own PCB with MAX7325 chip for testing
such things (since I was relocated from project where I had board with MAX732X).

> Patch applied, but it seems we need a general approach to
> cover a few GPIO drivers with this kind of thing.
>
> Is this how we should always do it?

I think so (well, at least it seems to be correct for GPIO expanders). But I'd
verify each particular driver to be completely sure that it's really needed and
it wouldn't create some new issues. MAX732X chip seems to be very similar to
PCF857X one, so in this particular case I'm sure that this patch is a good thing
to have.
--
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/