From mboxrd@z Thu Jan 1 00:00:00 1970 From: Javier Martinez Canillas Subject: Re: [PATCH 3/5] gpio/omap: Add DT support to GPIO driver Date: Wed, 27 Feb 2013 21:05:35 +0100 Message-ID: References: <1329321854-24490-1-git-send-email-b-cousson@ti.com> <1329321854-24490-4-git-send-email-b-cousson@ti.com> <4F44FA56.7020000@gmail.com> <4F44FC37.2000701@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> <512D3FE6.1010300@wwwdotorg.org> <512D490B.70900@ti.com> <512D4FC4.2060505@wwwdotorg.org> <512D5C58.4090500@ti.com> <512E4781.8050701@wwwdotorg.org> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Return-path: Received: from mail-ie0-f177.google.com ([209.85.223.177]:60056 "EHLO mail-ie0-f177.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752183Ab3B0UF4 (ORCPT ); Wed, 27 Feb 2013 15:05:56 -0500 Received: by mail-ie0-f177.google.com with SMTP id 16so1119255iea.22 for ; Wed, 27 Feb 2013 12:05:56 -0800 (PST) In-Reply-To: <512E4781.8050701@wwwdotorg.org> Sender: linux-omap-owner@vger.kernel.org List-Id: linux-omap@vger.kernel.org To: Stephen Warren Cc: Jon Hunter , Stephen Warren , Kevin Hilman , "devicetree-discuss@lists.ozlabs.org" , "linux-omap@vger.kernel.org" , "linux-arm-kernel@lists.infradead.org" , Linus Walleij , Grant Likely On Wed, Feb 27, 2013 at 6:50 PM, Stephen Warren wrote: > On 02/26/2013 08:57 PM, Javier Martinez Canillas wrote: >> On Wed, Feb 27, 2013 at 2:07 AM, Jon Hunter wrote: >>> >>> On 02/26/2013 06:13 PM, Stephen Warren wrote: >>>> On 02/26/2013 04:45 PM, Jon Hunter wrote: > ... >>>>> One issue I see is that by not calling gpio_request, then potentially >>>>> you could have someone request a gpio via gpio_request() and someone >>>>> trying to use it as an interrupt source via request_irq(). Now obviously >>>>> that represents a bug because there is only one physical gpio, but I >>>>> gather it is something we need to protect against. >>>> >>>> I'm not sure it's really that much of an issue, but presumably the >>>> solution is for a combined GPIO+IRQ driver to simply call gpio_request >>>> internally from within some irq_chip function. It looks like struct >>>> irq_chip doesn't have a request/free, but perhaps they could be added to >>>> solve this? >>> >>> Yes I was wondering if we could do something like that. That would work, >>> may be that's what we should propose. >> >> Something like that would definitely solve the GPIO request issue but >> we still have the issue that the current OMAP GPIO controller binding >> does not support #interrupt-cells = <2>. > > The binding documentation in > Documentation/devicetree/bindings/gpio/gpio-omap.txt indicates that it > does. If this doesn't work in practice, it's a driver bug that can > presumably be easily fixed. And no need to change any ABI definitions:-) > indeed :-) In fact I think that some documentation bits were borrowed from the NVIDIA Tegra GPIO controller bindings but it was never implemented in the OMAP GPIO driver to parse the second interrupt-cell which should specify the flags. > BTW, I notice in that binding document that the description of the two > cells for #interrupt-cells is actually part of the description of the > "interrupt-controller" property; it should be moved up one line really. Right, will submit a patch to fix this. Best regards, Javier