Re: [PATCH 1/1] PINCTRL: Warn if direct IRQ GPIO set to output

[eric ernst <eric.ernst@linux.intel.com>]

On 14-05-29 06:44 AM, Linus Walleij wrote:
> On Tue, May 27, 2014 at 9:26 PM,  <eric.ernst@linux.intel.com> wrote:
>
>> From: Eric Ernst <eric.ernst@linux.intel.com>
>>
>> For Baytrail, you should never set a GPIO set to direct_irq
>> to output mode.  When direct_irq_en is set for a GPIO, it is
>> tied directly to an APIC internally, and making the pad output
>> does not make any sense. Assert a WARN() in the event this happens.
>>
>> Signed-off-by: Eric Ernst <eric.ernst@linux.intel.com>
> Can I get some ACK from the author's of this driver on Eric's patch?
>
> Eric, you *are* aware of what the gpio_lock_as_irq() and
> gpio_unlock_as_irq() in the .irq_request_resources are doing
> right? Is this patch just some extra safety measure?
>
> Yours,
> Linus Walleij
Linus, thanks for the feedback.

I do see the usage for gpio_lock_as_irq() and gpio_unlock_as_irq(), 
though I'm not sure if this would help me in this scenario.  I am adding 
an extra safety measure, as an attempt to check exactly how the GPIO pin 
was configured, possibly before kernel, before changing the direction to 
output.

In my situation, a device attached via GPIO will act as an IRQ, but also 
toggled as output during setup in order to communicate with the device 
(ugly device, i know).  Specifically for this pincntrl device on 
Baytrail, we need to make sure that if the pin were ever to be used for 
IO, that direct IRQ is not set in its config register (ie - don't handle 
the IRQ via the APIC).  This check and WARN is to look for that 
situation, and provide a caution to the user that what they're asking 
for isn't necessarily what they will be getting.
Thanks,
Eric