linux-kernel - Re: [patch 2.6.27-rc7] gpiolib: request/free hooks

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: <200809271129.07241.david-b@pacbell.net>
Date:	Sat, 27 Sep 2008 11:29:06 -0700
From:	David Brownell <david-b@...bell.net>
To:	"Magnus Damm" <magnus.damm@...il.com>
Cc:	"Andrew Morton" <akpm@...ux-foundation.org>,
	lkml <linux-kernel@...r.kernel.org>
Subject: Re: [patch 2.6.27-rc7] gpiolib: request/free hooks

On Saturday 27 September 2008, Magnus Damm wrote:
> 
> Looking good. I'm currently hacking on some pinmuxed gpio code for
> SuperH, and I'd like to use these request/free callbacks to select
> proper pinmux state.

I'm not so keen on that particular overloading, but I can
understand why it might be wanted on systems which have a
happy one-to-one mapping between GPIOs and pins.

If you do that, be ready to provide a pinmux-only interface
at some point when this "piggybacking" breaks something...

 
> I have one comment below though:
> 
> > --- a/drivers/gpio/gpiolib.c
> > +++ b/drivers/gpio/gpiolib.c
> > @@ -781,6 +785,7 @@ EXPORT_SYMBOL_GPL(gpiochip_remove);
> >  int gpio_request(unsigned gpio, const char *label)
> >  	...
> 
> The code above doesn't catch double gpio_request() user calls
> properly. Or rather, the user will receive an error but the
> chip->request() callback may get called twice.
> 
> What about modifying the gpiolib code to handle that? I think that
> sounds like a better idea than cover ing that case in the chip code...

Yeah.  Better to test-and-set the flag and then request, and backout
if it fails, than the other way.  Just who wrote that crap in the
first place?  Sigh.  (Notice it's done that way already in the code
path handling implicit requesting ... )

I'll send an updated patch along soonish.

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