From: Denis Kuzmenko <linux@solonet.org.ua>
To: Stephen Warren <swarren@nvidia.com>
Cc: "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
Grant Likely <grant.likely@secretlab.ca>,
Linus Walleij <linus.walleij@linaro.org>,
Richard Purdie <rpurdie@rpsys.net>,
Wolfram Sang <w.sang@pengutronix.de>
Subject: Re: [PATCH] s3c/s3c24xx: arm: leds: Make s3c24xx LEDS driver use gpiolib
Date: Tue, 22 Nov 2011 02:28:22 +0200 [thread overview]
Message-ID: <4ECAECA6.7090109@solonet.org.ua> (raw)
In-Reply-To: <74CDBE0F657A3D45AFBB94109FB122FF174F08C2B4@HQMAIL01.nvidia.com>
On 11/22/2011 01:39 AM, Stephen Warren wrote:
> 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.
>
So what do you suggest? Leave original behavior?
I'd like to remove pull-related actions at all considering:
- power consumption
- we are both not able to find any sense in that code
- s3c2410_gpio_pullup looks like deprecated
- can't imagine situation where this change will break functionality
(of course when this code used to drive actually LED and not something else)
--
Best regards, Denis Kuzmenko.
next prev parent reply other threads:[~2011-11-22 0:26 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-11-17 20:47 [PATCH] s3c/s3c24xx: arm: leds: Make s3c24xx LEDS driver use gpiolib Denis Kuzmenko
2011-11-18 17:08 ` Stephen Warren
2011-11-18 21:00 ` Denis Kuzmenko
2011-11-18 21:44 ` Denis Kuzmenko
2011-11-18 21:59 ` Stephen Warren
2011-11-18 22:34 ` Denis Kuzmenko
2011-11-18 22:39 ` [PATCH v2] " Denis Kuzmenko
2011-11-18 22:44 ` [PATCH] " Stephen Warren
2011-11-18 23:16 ` Denis Kuzmenko
2011-11-21 18:07 ` Stephen Warren
2011-11-21 19:37 ` Denis Kuzmenko
2011-11-21 22:03 ` Stephen Warren
2011-11-21 22:52 ` Denis Kuzmenko
2011-11-21 23:39 ` Stephen Warren
2011-11-22 0:28 ` Denis Kuzmenko [this message]
2011-11-22 0:40 ` Stephen Warren
2011-11-18 21:47 ` Stephen Warren
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4ECAECA6.7090109@solonet.org.ua \
--to=linux@solonet.org.ua \
--cc=grant.likely@secretlab.ca \
--cc=linus.walleij@linaro.org \
--cc=linux-kernel@vger.kernel.org \
--cc=rpurdie@rpsys.net \
--cc=swarren@nvidia.com \
--cc=w.sang@pengutronix.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox