Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751705AbbEDSXQ (ORCPT ); Mon, 4 May 2015 14:23:16 -0400 Received: from exprod5og118.obsmtp.com ([64.18.0.160]:44441 "EHLO mail-la0-f53.google.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1751593AbbEDSXJ (ORCPT ); Mon, 4 May 2015 14:23:09 -0400 MIME-Version: 1.0 Reply-To: semen.protsenko@globallogic.com In-Reply-To: References: <1429637257-11055-1-git-send-email-semen.protsenko@globallogic.com> Date: Mon, 4 May 2015 21:23:06 +0300 Message-ID: Subject: Re: [PATCH 1/2] gpio: max732x: Propagate wake-up setting to parent irq controller From: Sam Protsenko To: Linus Walleij Cc: Alexandre Courbot , "linux-gpio@vger.kernel.org" , "linux-kernel@vger.kernel.org" Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1874 Lines: 36 On Mon, May 4, 2015 at 4:32 PM, Linus Walleij 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@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/