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