From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-oa0-f47.google.com ([209.85.219.47]:56749 "EHLO mail-oa0-f47.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755563Ab3HWSpv (ORCPT ); Fri, 23 Aug 2013 14:45:51 -0400 Received: by mail-oa0-f47.google.com with SMTP id g12so1198873oah.34 for ; Fri, 23 Aug 2013 11:45:49 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: <52167E5D.6060802@wwwdotorg.org> References: <1377092334-770-1-git-send-email-larsi@wh2.tu-dresden.de> <1507189.CRWvzVJqTV@flatron> <521548E3.6010703@wwwdotorg.org> <52167E5D.6060802@wwwdotorg.org> Date: Fri, 23 Aug 2013 20:45:49 +0200 Message-ID: Subject: Re: [PATCH v2] gpio: interrupt consistency check for OF GPIO IRQs From: Linus Walleij Content-Type: text/plain; charset=ISO-8859-1 Sender: devicetree-owner@vger.kernel.org To: Stephen Warren Cc: Tomasz Figa , Lars Poeschel , Lars Poeschel , Grant Likely , "linux-gpio@vger.kernel.org" , "linux-kernel@vger.kernel.org" , "devicetree@vger.kernel.org" , Mark Rutland , Ian Campbell , Kumar Gala , Pawel Moll , Javier Martinez Canillas , Enric Balletbo i Serra , Jean-Christophe PLAGNIOL-VILLARD , Santosh Shilimkar , Kevin Hilman , Balaji T K , Tony Lindgren , Jon Hunter List-ID: On Thu, Aug 22, 2013 at 11:10 PM, Stephen Warren wrote: > On 08/21/2013 05:36 PM, Linus Walleij wrote: >> On Thu, Aug 22, 2013 at 1:10 AM, Stephen Warren wrote: >> [Me] >>>>> check if these in turn reference the interrupt-controller, and >>>>> if they do, loop over the interrupts used by that child and >>>>> perform gpio_request() and gpio_direction_input() on these, >>>>> making them unreachable from the GPIO side. >>> >>> What about bindings that require a GPIO to be specified, yet don't allow >>> an IRQ to be specified, and the driver internally does perform >>> gpio_to_irq() on it? I don't think one can detect that case. >> >> This is still allowed. Consumers that prefer to have a GPIO >> passed and convert it to IRQ by that call can still do so, >> they will know what they're doing and will not cause the >> double-command situation that we're trying to solve. > > Why not? There are certainly drivers in the kernel which request a GPIO > as both a GPIO and as an (dual-edge) interrupt, so that they can read > the GPIO input whenever the IRQ goes off, in order to determine the pin > state. This is safer against high-latency or lost interrupts. Yes? Are we talking past each other here? This is a perfectly OK thing to do as long as it is done like this: request_gpio(gpio); gpio_direction_input(gpio); request_irq(gpio_to_irq(gpio)); Pass only the GPIO in the device tree and this works just fine. The use case after that we do not interfer with. Yours, Linus Walleij