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]
Message-ID: <CAJOTznUNrx7oytz+J7hkvBOARHEFK9etsK86uTWYxdm2p-sqtw@mail.gmail.com>
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ