lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <5387AD34.8060408@linux.intel.com>
Date:	Thu, 29 May 2014 14:57:08 -0700
From:	eric ernst <eric.ernst@...ux.intel.com>
To:	Linus Walleij <linus.walleij@...aro.org>,
	Mika Westerberg <mika.westerberg@...ux.intel.com>,
	Mathias Nyman <mathias.nyman@...ux.intel.com>,
	Andy Shevchenko <andriy.shevchenko@...ux.intel.com>
CC:	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	Mark Gross <mark.gross@...el.com>,
	"Holmberg, Hans" <hans.holmberg@...el.com>
Subject: Re: [PATCH 1/1] PINCTRL: Warn if direct IRQ GPIO set to output

On 14-05-29 06:44 AM, Linus Walleij wrote:
> On Tue, May 27, 2014 at 9:26 PM,  <eric.ernst@...ux.intel.com> wrote:
>
>> From: Eric Ernst <eric.ernst@...ux.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@...ux.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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ