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]
Date:	Wed, 28 May 2008 02:01:24 -0700
From:	David Brownell <david-b@...bell.net>
To:	Haavard Skinnemoen <haavard.skinnemoen@...el.com>
Cc:	Ben Nizette <bn@...sdigital.com>,
	linux-kernel <linux-kernel@...r.kernel.org>,
	kernel@...32linux.org
Subject: Re: Latest gpio gumph

On Wednesday 28 May 2008, Haavard Skinnemoen wrote:
> > 
> >  * gpio_direction_output() should disable the pullups just like
> >    at32_select_gpio(... AT32_GPIOF_OUTPUT) does, for consistency
> >    between those alternative initialization paths.
> 
> But then we need to keep track of whether pullups used to be enabled so
> that we can re-enable it in gpio_direction_input(), don't we?

"Need"?  I'd figure that changing direction like that would be
uncommon without something determining signal level (like an
external driver or pullup) ... and if nothing did so, then it'd
be important to use the AVR32-private API with pullup control.


> I can't see the harm of keeping the pullup enabled while the port is
> configured as output. For consistency, I'd rather honor the pullup flag
> in at32_select_gpio() regardless of AT32_GPIOF_OUTPUT.

I guess I don't like the idea of facilitating the constant current
waste that implies if output is being driven low.  Even if it's not
a huge current waste!  (These pullups being a lot weaker than I'd
have expected, at typically 190 kOhm.)  No big deal here I guess.

For an open drain output it's probably less of an issue, unless
there are too many pullups.


> >  * On the odd chance some code uses a pin as a GPIO IRQ without
> >    calling gpio_request() or gpio_direction_input(), the debug
> >    dump should still show its pin status.
> 
> Hmm. I guess that makes sense, though I would be lying if I said I care
> all that much. I think gpiolib is going pretty far to accommodate buggy
> drivers that don't call gpio_request() as it is.

For diagnostic/debug code, I'd say it's reasonably useful to cope
with buglets like that. 

I actually observed that happening.  Setup code was passing the irq
to the driver, and everything worked fine because the reset default
was fine.  I happened to notice that /sys/kernel/debug/gpio output
didn't match up to /proc/interrupts (bug) ... but it would have been
much faster to see the bug if the listing for that pin had a "?" label
showing that it hadn't been requested.

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

Powered by blists - more mailing lists