From mboxrd@z Thu Jan 1 00:00:00 1970 From: Linus Walleij Subject: Re: [PATCH v3] gpio: interrupt consistency check for OF GPIO IRQs Date: Tue, 24 Sep 2013 10:31:41 +0200 Message-ID: References: <1377526030-32024-1-git-send-email-larsi@wh2.tu-dresden.de> <522FBED9.9000305@collabora.co.uk> <5230C7F6.3080803@wwwdotorg.org> <3653629.tapNZSuWhS@lem-wkst-02> <52373B34.4060709@wwwdotorg.org> <5240A2D3.20105@wwwdotorg.org> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Return-path: In-Reply-To: <5240A2D3.20105@wwwdotorg.org> Sender: linux-gpio-owner@vger.kernel.org To: Stephen Warren Cc: Lars Poeschel , Javier Martinez Canillas , Mark Brown , 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 , Tomasz Figa , Enric Balletbo i Serra , Jean-Christophe PLAGNIOL-VILLARD , Santosh Shilimkar , Kevin Hilman , Balaji T K , Tony Lindgren , Jon Hunter , joelf@ti.com, Laur List-Id: devicetree@vger.kernel.org On Mon, Sep 23, 2013 at 10:21 PM, Stephen Warren wrote: > On 09/23/2013 02:01 PM, Linus Walleij wrote: >> And how to you block the same line from being gpio_request()ed >> and set as output? > > To be honest, I really don't think this problem is terribly likely to > occur, so I'm really not convinced that it's worth putting a lot of > effort into solving it. I have a different opionion, I think this is important. As GPIO subsystem maintainer I need to be convinced of the integrity of the system. > If the problem does occur, it's trivial to see that this has happened by > looking at /proc/interrupts and /sys/kernel/debug/gpio, I basically want /sys/kernel/debug/gpio to say if a certain line is tied for IRQ. > That driver needs to maintain some state that indicates which of its > IRQs have been requested. Any time a GPIO request (I mean e.g. > set_output() not request_gpio)) comes in, the request needs to be > validated against that IRQ usage state. If there's a conflict, deny the > GPIO request. I think this should be done by gpiolib, and I think it is trivial given the right APIs. Putting it in the drivers will just create an array of similar-look Rube Goldberg-machines and code duplication. There is no point. > Now, it's quite possible that the code to maintain this state and > perform the checks will be similar/common across multiple drivers. If > so, by all means implement the code somewhere common, and have the > various irq_chip/gpio_chip drivers call into it. And this is what we should do in gpiolib. > The main thing is that all of this has to be driven/controlled/enabled > by the gpio_chip/irq_chip driver itself, not as some global/blanket > feature of the GPIO or IRQ subsystems. Sure. > Perhaps rather than having the gpio_chip/irq_chip drivers physically > implement a function which calls this common code, they could set some > flags/data/... in the struct gpio_chip/irq_chip indicating that they > desire the core code that implements the error-checking to be enabled. I think it should more be like a function they can call to flag a GPIO as used for IRQ. Yours, Linus Walleij