From mboxrd@z Thu Jan 1 00:00:00 1970 From: swarren@wwwdotorg.org (Stephen Warren) Date: Thu, 11 Apr 2013 14:30:51 -0600 Subject: [PATCH 3/5] gpio/omap: Add DT support to GPIO driver In-Reply-To: References: <1329321854-24490-1-git-send-email-b-cousson@ti.com> <4F452484.5080503@gmail.com> <74CDBE0F657A3D45AFBB94109FB122FF17BD8BC6C1@HQMAIL01.nvidia.com> <4F47AD08.4030504@ti.com> <512D39DA.7020306@ti.com> <512D3AB1.1080202@wwwdotorg.org> <512D3EC2.6050408@ti.com> <20130302200524.D230F3E1571@localhost> <51391F41.5000303@ti.com> <514C79E1.4090106@wwwdotorg.org> <514CE0AB.6060207@ti.com> <515319D5.20105@wwwdotorg.org> <5155C902.7080207@wwwdotorg.org> <5165CB9D.1090202@wwwdotorg.org> Message-ID: <51671D7B.5060303@wwwdotorg.org> To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org On 04/10/2013 03:28 PM, Linus Walleij wrote: > On Wed, Apr 10, 2013 at 10:29 PM, Stephen Warren wrote: >> On 04/10/2013 12:12 PM, Linus Walleij wrote: > >>> If the information is there, whether to convert from IRQ to GPIO >>> or from GPIO to IRQ is a technicality and any order should be >>> feasible in some way? >> >> There isn't always a unique 1:1 mapping between GPIOs and IRQs. Put >> another way, a single GPIO would likely only ever trigger a single IRQ, >> but a single IRQ might easily be triggered by any number of GPIOs. This >> is exactly why the function irq_to_gpio() isn't something one should use >> any more. I think there was an effort to outright remove the API, >> although it doesn't look like that's entirely complete yet. I guess you >> know this given your mentions of problem with gpio_to_irq() later on, so >> I'm not quite sure what your paragraph above was supposed to mean. > > So the only reason I'm rambing on about this is that it breaks the I'm not sure I understand this paragraph; what is "it" in the line above. If "it" is this patch, then should "breaks" be re-establishes? > connection between GPIOs and their IRQs and at one point > I percieved it as there was going to be some IRQ -> GPIO lookup, > and it would sneak back in. But now I realize that may have been > supposed to be something local to the driver, in it's irqchip portions > and then it's actually no problem for the kernel at large. Yes, I believe the intention was for their to be a correlation between GPIOs and IRQs only with the individual gpio_chip/irq_chip drivers for those GPIOs/IRQs, and not exposed anywhere outside it. > Let's restate: I'm also after something fragile here. I assume you mean the opposite of that? > IIUC, it will be possible for a GPIO to be set up as input and used > as an IRQ without the GPIO subsystem knowing it. And it will be > possible for the GPIO subsystem to go in and request the same pin > and set it as output and e.g. bit-bang it. I wonder what happens then. Yes, I think that's possible now. If I recall the patch I'm replying to correctly, the idea was to add an "IRQ request" operation that would (internally to the GPIO/IRQ driver itself) map IRQ->GPIO, and call gpio_request(). That would then prevent exactly the situation you mention above.