[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <74CDBE0F657A3D45AFBB94109FB122FF174F08C2B4@HQMAIL01.nvidia.com>
Date: Mon, 21 Nov 2011 15:39:32 -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 3:52 PM:
...
> > 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.
> >
>
> Actually, "s3c2410_gpio_pullup(pdata->gpio, 0);" enables pull in the
> same way I've done that. Here is it's code:
So it does. That's extremely non-obvious if not broken.
Anyway, I guess that means that your patch V1 is at least a pure conversion
of the code from custom functions to gpiolib, even if what it was and still
is doing doesn't make much sense to me.
--
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/
Powered by blists - more mailing lists