linux-kernel - RE: [PATCH] s3c/s3c24xx: arm: leds: Make s3c24xx LEDS driver use gpiolib

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: <74CDBE0F657A3D45AFBB94109FB122FF174F08C246@HQMAIL01.nvidia.com>
Date:	Mon, 21 Nov 2011 14:03:26 -0800
From:	Stephen Warren <swarren@...dia.com>
To:	Denis Kuzmenko <linux@...onet.org.ua>
CC:	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	Grant Likely <grant.likely@...retlab.ca>,
	Linus Walleij <linus.walleij@...aro.org>,
	Richard Purdie <rpurdie@...ys.net>,
	Wolfram Sang <w.sang@...gutronix.de>
Subject: RE: [PATCH] s3c/s3c24xx: arm: leds: Make s3c24xx LEDS driver use
 gpiolib

Denis Kuzmenko wrote at Monday, November 21, 2011 12:38 PM:
> On 11/21/2011 08:07 PM, Stephen Warren wrote:
> > Denis Kuzmenko wrote at Friday, November 18, 2011 4:17 PM:
> >> On 11/19/2011 12:44 AM, Stephen Warren wrote:
...
> >>> OK, I see the need for a pull of some kind (although aren't there meant
> >>> to be ESD protection diodes for this purpose; relying on what are probably
> >>> pretty weak pullup/down resistors doesn't seem like it will provide much
> >>> protection at all).
> >>
> >> I don't mean pull as any kind of good protection. But it's much better
> >> to have it than not.
> >
> > Hmm. I'm not entirely convinced. If the board already has a pull-up/down,
> > it seems like it won't really make much difference to ESD, and you can't
> > make any assumptions in the core driver about whether such an external
> > resistor is already present. In fact, adding another pull resistor inside
> > the SoC in parallel will reduce the overall resistance, and increase wasted
> > power.
> >
> 
> 	I don't think it's a real protection. It's rather "mistake-proofing"
> (Poka-Yoke).
> 	You are right, I didn't considered additional pulls (however I can't
> imagine tristate LED usage with additional external pull) and power
> consumptions.
> 	I was just wondering, why was pull needed in previous implementation.
> Additional ESD protection was the only thing I could imagine. I don't
> think it's needed there and I'm OK to remove pull-related code.
> 	So I'll remove it, test and send patch V3?

I don't see any pulls being configured in the original code at all,
unless some of the s3c2410_* function have unexpected side-effect. The
only related thing is in probe:

        /* no point in having a pull-up if we are always driving */

        if (pdata->flags & S3C24XX_LEDF_TRISTATE) {
..
        } else {
                s3c2410_gpio_pullup(pdata->gpio, 0);

which I assume disables an pull in the case where the pin is always driven.

So, yes, I'd say submit v3 without any pull manipulation at all.

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