linux-kernel - RE: [PATCH 1/3] irq: If an IRQ is a GPIO, request and configure it

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: <74CDBE0F657A3D45AFBB94109FB122FF049F171EC1@HQMAIL01.nvidia.com>
Date:	Thu, 4 Aug 2011 20:53:34 -0700
From:	Stephen Warren <swarren@...dia.com>
To:	Mark Brown <broonie@...nsource.wolfsonmicro.com>
CC:	Thomas Gleixner <tglx@...utronix.de>, Liam Girdwood <lrg@...com>,
	Chris Ball <cjb@...top.org>,
	"ccross@...roid.com" <ccross@...roid.com>,
	"olof@...om.net" <olof@...om.net>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"linux-arm-kernel@...ts.infradead.org" 
	<linux-arm-kernel@...ts.infradead.org>,
	"alsa-devel@...a-project.org" <alsa-devel@...a-project.org>,
	"linux-mmc@...r.kernel.org" <linux-mmc@...r.kernel.org>,
	"linux-tegra@...r.kernel.org" <linux-tegra@...r.kernel.org>
Subject: RE: [PATCH 1/3] irq: If an IRQ is a GPIO, request and configure it

Mark Brown wrote at Thursday, August 04, 2011 6:02 PM:
> On Thu, Aug 04, 2011 at 05:00:18PM -0600, Stephen Warren wrote:
> 
> > +	} else {
> > +		gpio = irq_to_gpio(irq);
> > +		if (gpio_is_valid(gpio)) {
> > +			ret = gpio_request(gpio, new->name);
> > +			if (ret < 0)
> > +				goto out_mask;
> > +			ret = gpio_direction_input(gpio);
> > +			if (ret < 0)
> > +				goto out_mask;
> > +		}
> 
> If you treat failures as an error what happens when a driver is using a
> GPIO as both an interrupt and a GPIO?  For example a driver which
> monitors the level on a GPIO and uses edge triggered IRQs to be notified
> of state changes.

Well, things break. This is essentially the problem I was describing in
the PATCH 0 email, just with a slightly different motivation.

I suppose that an alternative here would be to simply ignore any errors
from gpio_request. This might have the benefit of removing the need for
the other two patches I posted in the series. However, it seems a little
dirty; one benefit of the IRQ code calling gpio_request and honoring
errors would be to detect when some completely unrelated code had a bug
and had called gpio_request on the GPIO before. Such detection would be
non-existent if we don't error out on gpio_request. Perhaps some mechanism
is needed to indicate that the driver has explicitly already called
gpio_request for a legitimate shared purpose, and only then ignore
errors?

--
nvpublic

--
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/