linux-kernel - Re: [RFC] gpio/omap: auto-setup a GPIO when used as an IRQ

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] [day] [month] [year] [list]

Message-ID: <20130924152703.GL2684@atomide.com>
Date:	Tue, 24 Sep 2013 08:27:03 -0700
From:	Tony Lindgren <tony@...mide.com>
To:	Javier Martinez Canillas <javier.martinez@...labora.co.uk>
Cc:	Linus Walleij <linus.walleij@...aro.org>,
	Santosh Shilimkar <santosh.shilimkar@...com>,
	Kevin Hilman <khilman@...aro.org>,
	Stephen Warren <swarren@...dotorg.org>,
	Lars Poeschel <larsi@....tu-dresden.de>,
	Grant Likely <grant.likely@...aro.org>,
	Mark Rutland <mark.rutland@....com>,
	Ian Campbell <ian.campbell@...rix.com>,
	Kumar Gala <galak@...eaurora.org>,
	Pawel Moll <pawel.moll@....com>,
	Tomasz Figa <tomasz.figa@...il.com>,
	Enric Balletbo i Serra <eballetbo@...il.com>,
	Jean-Christophe PLAGNIOL-VILLARD <plagnioj@...osoft.com>,
	Balaji T K <balajitk@...com>,
	Jon Hunter <jgchunter@...il.com>,
	"linux-gpio@...r.kernel.org" <linux-gpio@...r.kernel.org>,
	Linux-OMAP <linux-omap@...r.kernel.org>,
	"devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [RFC] gpio/omap: auto-setup a GPIO when used as an IRQ

* Javier Martinez Canillas <javier.martinez@...labora.co.uk> [130923 22:49]:
> On 09/23/2013 10:15 PM, Linus Walleij wrote:
> > <javier.martinez@...labora.co.uk> wrote:
> > - When a second caller calls omap_gpio_request() it should
> >   be OK as well, but only if the flags corresponds to the
> >   previously enabled input mode. Else it should be
> >   disallowed.
> > 
> > - The same should happen for _set_gpio_direction() if a pin
> >   previously set up for IRQ gets a request to be used as
> >   output.
> > 
> > If this cannot be tracked in the driver, it is certainly a candidate
> > for something that gpiolib should be doing. And then I'm open to
> > solutions to how we can do that.
> > 
> 
> Ok, this can be tracked in the driver, will add it when posting v2 soon.
> 
> > If this needs to be applied pronto to fix the regression I'm
> > happy with that too, if we add a big boilerplate stating the above
> > problem and that it needs to be *fixed* at some point.

In the mainline kernel, the regression is happening at least for
smsc911x using boards, so that's omap3-igep.dtsi and omap3-tobi.dts
currently. Also MMC card detection for omap4 is failing. Then
of course there are tons of boards where we don't have the .dts
files in the mainline kernel yet.

So maybe let's do a minimal fix for the -rc cycle first?

Then the extra checks can be queued for the next merge window
if it gets too intrusive.

> > But in either case I want this to be tested on OMAP1 before
> > I apply it, as in a Tested-by tag.
> >
> 
> Agreed. Even though this is a fix for a long standing issue I prefer it to be
> tested extensively than applying the patch in a rush just to learn that causes
> regressions and have to be reverted as it happens last time.
> 
> So as you said let's wait until we have a few Tested-by tags by people using
> different OMAP platforms specially OMAP1.

Yup.

Regards,

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