Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756093AbbESO26 (ORCPT ); Tue, 19 May 2015 10:28:58 -0400 Received: from mail-ob0-f177.google.com ([209.85.214.177]:36689 "EHLO mail-ob0-f177.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1756060AbbESO2z (ORCPT ); Tue, 19 May 2015 10:28:55 -0400 MIME-Version: 1.0 In-Reply-To: <20150518110214.GC28127@localhost> References: <1431696321-7257-1-git-send-email-grygorii.strashko@linaro.org> <20150518110214.GC28127@localhost> Date: Tue, 19 May 2015 16:28:55 +0200 Message-ID: Subject: Re: [PATCH] gpiolib: debugfs: display gpios requested as irq only From: Linus Walleij To: Johan Hovold Cc: Grygorii Strashko , 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: 3349 Lines: 83 On Mon, May 18, 2015 at 1:02 PM, Johan Hovold wrote: > On Fri, May 15, 2015 at 04:25:21PM +0300, grygorii.strashko@linaro.org wrote: >> GPIOs 192-223, platform/48051000.gpio, gpio: >> gpio-203 (vtt_fixed ) out hi requested > > This is backwards. All gpios *should* be requested. *If* we are to > include not-requested gpios in the debug output, then it is those pins > that need to be marked as not-requested. It depends, really. As concluded in earlier discussions when we introduced gpiochip_[un]lock_as_irq() the gpiolib and irqchip APIs are essentially orthogonal. At one point I was suggesting that any driver using a GPIO for IRQ should first request the gpio line with gpiod_get() and then use gpio_to_irq() on the descriptor. Always. However as it turns out (and after being hammered down by the DT and ACPI people for this stance) I changed opinion, because even if that stringence would be nice, it doesn't abstract the hardware well enough for drivers that "just need an IRQ". These don't care of whether a line to the primary IRQ controller or a dedicated external IRQ pin or some cascaded GPIO chip is providing the IRQ, they just want their IRQ resource. If I would persist in my stance that the API must be used like so it would have implications on how HW descriptions such as DT or ACPI describe their resources and essentially put requirements out to other operating systems than Linux using DT or ACPI to do it the same way for this reason. That would be unreasonable. So it was deemed these resource APIs need to be orthogonal. The same would apply to any other resource that is similar to a GPIO and an IRQ line, don't know what a good example would be. So to atleast try to safeguard from a scenario such as - Client A requests IRQ from the irqchip side of the API and sets up a level active-low IRQ on it - Client B request the same line as GPIO - Client B sets it to output and drivers it low. - Client A crashes in an infinite IRQ loop as that line is not hammered low and will generate IRQs until the end of time. I introduced the gpiochip_[un]lock_as_irq() calls so we could safeguard against this. Notably that blocks client A from setting the line as output. I hope. I thought this would mean the line would only be used as IRQ in this case, so I could block any gpiod_get() calls to that line but *of course* some driver is using the IRQ and snooping into the GPIO value at the same time. So can't simplify things like so either. Maybe I'm smashing open doors here... Anyway to get back to the original statement: > This is backwards. All gpios *should* be requested. *If* we are to > include not-requested gpios in the debug output, then it is those pins > that need to be marked as not-requested. This is correct, all GPIOs accessed *as gpios* should be requested, no matter if they are then cast to IRQs by gpiod_to_irq or not. However if the same hardware is used as only "some IRQ" through it's irqchip interface, it needs not be requested, but that is by definition not a GPIO, it is an IRQ. Yours, Linus Walleij -- 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/