All of lore.kernel.org
 help / color / mirror / Atom feed
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: Fri, 18 Nov 2011 23:00:53 +0200	[thread overview]
Message-ID: <4EC6C785.5010801@solonet.org.ua> (raw)
In-Reply-To: <74CDBE0F657A3D45AFBB94109FB122FF1740D74E87@HQMAIL01.nvidia.com>

On 11/18/2011 07:08 PM, Stephen Warren wrote:
> Denis Kuzmenko wrote at Thursday, November 17, 2011 1:47 PM:
>> Make s3c24xx LEDS driver use gpiolib.
>
> I made some slightly nit-picky
> comments below.

Thanks for looking my patch.

>> diff --git a/drivers/leds/leds-s3c24xx.c b/drivers/leds/leds-s3c24xx.c
> 
>>  static void s3c24xx_led_set(struct led_classdev *led_cdev,
>> -			    enum led_brightness value)
>> +				enum led_brightness value)
> 
> Seems unnecessary, but is probably fine.

That was made unintentionally - will fix in next version.

>>  {
>>  	struct s3c24xx_gpio_led *led = to_gpio(led_cdev);
>>  	struct s3c24xx_led_platdata *pd = led->pdata;
>>
>> -	/* there will be a short delay between setting the output and
>> -	 * going from output to input when using tristate. */
>> -
>> -	s3c2410_gpio_setpin(pd->gpio, (value ? 1 : 0) ^
>> -			    (pd->flags & S3C24XX_LEDF_ACTLOW));
>> -
>> -	if (pd->flags & S3C24XX_LEDF_TRISTATE)
>> -		s3c2410_gpio_cfgpin(pd->gpio,
>> -			value ? S3C2410_GPIO_OUTPUT : S3C2410_GPIO_INPUT);
>> +	/*
>> +	 * ensure value is 0 or 1 to use it with bitwise XOR (^)
>> +	 * (only 100% brightness is supported)
>> +	 */
>> +	value = value ? 1 : 0;
>> +
>> +	if (pd->flags & S3C24XX_LEDF_TRISTATE) {
>> +		if (value) {
>> +			/* invert value if S3C24XX_LEDF_ACTLOW is set */
>> +			value = (pd->flags & S3C24XX_LEDF_ACTLOW) ^ value;
>> +			gpio_direction_output(pd->gpio, value);
>> +		} else {
>> +			gpio_direction_input(pd->gpio);
>> +		}
>> +	} else {
>> +		/* invert value if S3C24XX_LEDF_ACTLOW is set */
>> +		value = (pd->flags & S3C24XX_LEDF_ACTLOW) ^ value;
>> +		gpio_set_value(pd->gpio, value);
>> +	}
> 
> I'd be tempted to simplify the new code a little:
> 
> 	/* invert value if S3C24XX_LEDF_ACTLOW is set */
> 	value = !!(pd->flags & S3C24XX_LEDF_ACTLOW) ^ !!value;
> 
> 	if (pd->flags & S3C24XX_LEDF_TRISTATE) {
> 		if (value)
> 			gpio_direction_output(pd->gpio, value);
> 		else
> 			gpio_direction_input(pd->gpio);
> 	} else {
> 		gpio_set_value(pd->gpio, value);
> 	}

I've almost broke my mind writing this part and you've repeated my
mistake: in line where 'value' is checked ( if(value) ) the 'value'
shouldn't be inverted independently of S3C24XX_LEDF_ACTLOW flag.
This because S3C24XX_LEDF_TRISTATE means "tristate to turn off"
(arch/arm/mach-s3c2410/include/mach/leds-gpio.h:18) - that produces all
of complexity. Hope my description is understandable (if not, I'm sorry
- my English is too bad for this).

>> @@ -76,7 +88,8 @@ static int s3c24xx_led_probe(struct platform_device *dev)
>>  	led = kzalloc(sizeof(struct s3c24xx_gpio_led), GFP_KERNEL);
>>  	if (led == NULL) {
>>  		dev_err(&dev->dev, "No memory for device\n");
>> -		return -ENOMEM;
>> +		ret = -ENOMEM;
>> +		goto err_kzalloc;
>>  	}
>
> That works fine, but isn't strictly necessary; no previous allocations
> have been made here that need to be undone.
> 

I tried to use same error handling approach in all code, but you are
right - I've missed that in this place we can return safely and not
loosing much of code readability. _But_ this violates approach of not
having multiple returns unless you *really* need this. Still in doubt...

>> @@ -91,12 +104,15 @@ static int s3c24xx_led_probe(struct platform_device
>> *dev)
>>  	/* no point in having a pull-up if we are always driving */
>>
>>  	if (pdata->flags & S3C24XX_LEDF_TRISTATE) {
>> -		s3c2410_gpio_setpin(pdata->gpio, 0);
>> -		s3c2410_gpio_cfgpin(pdata->gpio, S3C2410_GPIO_INPUT);
>> +		ret = gpio_request_one(pdata->gpio, GPIOF_IN, pdata->name);
>>  	} else {
>> -		s3c2410_gpio_pullup(pdata->gpio, 0);
>> -		s3c2410_gpio_setpin(pdata->gpio, 0);
>> -		s3c2410_gpio_cfgpin(pdata->gpio, S3C2410_GPIO_OUTPUT);
>> +		ret = gpio_request_one(pdata->gpio, GPIOF_OUT_INIT_LOW,
>> +												pdata->name);
>> +		s3c_gpio_setpull(pdata->gpio, S3C_GPIO_PULL_NONE);
>> +	}
> 
> I always prefer not to duplicate function calls, but rather to calculate
> the differing data (either directly in the call, or into a temporary
> variable first), so:
> 
> 	ret = gpio_request_one(pdata->gpio, 
> 				(pdata->flags & S3C24XX_LEDF_TRISTATE) ?
> 				GPIOF_IN : GPIOF_OUT_INIT_LOW,
> 				pdata->name);
> 
> 	if (!(pdata->flags & S3C24XX_LEDF_TRISTATE))
> 		s3c_gpio_setpull(pdata->gpio, S3C_GPIO_PULL_NONE);
> 
> 
>> +	if (ret < 0) {
>> +		dev_err(&dev->dev, "gpio_request failed\n");
>> +		goto err_gpio_request;
>>  	}
> 
> You should probably move that error check right after calling
> gpio_request_one()
> 

I see no big difference between those two variants, but:
  1. my code looks for more readable
  2. your code allows not to call 's3c_gpio_setpull' in case of
gpio_request fail which looks like the _only_ usable variant.

Besides that, I've made a mistake changing

s3c2410_gpio_pullup(pdata->gpio, 0)
to
s3c_gpio_setpull(pdata->gpio, S3C_GPIO_PULL_NONE)

because first variant actually means *enable* pull, trying first UP and,
if fail, DOWN direction. So pull-resistor is enabled in this case but in
some *random* direction.

The only use case for pull-resistor I see here is not to left pin
floating if someone configured _tristate_off_ LED on pin which actually
don't have it (LED or anything other connected). Considering this and a
fact that pullup is default enabled I think that it's safe to remove
it's configuration at all and left code in my variant. Or to add
pull-resistor enabling code for *opposite* case (S3C24XX_LEDF_TRISTATE).

-- 
Best regards, Denis Kuzmenko.

  reply	other threads:[~2011-11-18 20:59 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 [this message]
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
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=4EC6C785.5010801@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.