All of lore.kernel.org
 help / color / mirror / Atom feed
From: Javier Martinez Canillas <javier.martinez@collabora.co.uk>
To: Ezequiel Garcia <elezegarcia@gmail.com>
Cc: linux-leds@vger.kernel.org, linux-omap@vger.kernel.org,
	linux-arm-kernel@lists.infradead.org,
	linux-kernel@vger.kernel.org
Subject: Re: [RESEND PATCH] leds: leds-gpio: set devm_gpio_request_one() flags correctly
Date: Mon, 31 Dec 2012 14:08:27 +0100	[thread overview]
Message-ID: <50E18E4B.7000107@collabora.co.uk> (raw)
In-Reply-To: <CALF0-+XM4EZJHU360AUAUFBPctwO81JQ7kUiH12V2n6x7wCXfA@mail.gmail.com>

On 12/21/2012 06:06 PM, Ezequiel Garcia wrote:
> On Fri, Dec 21, 2012 at 12:07 PM, Javier Martinez Canillas
> <javier.martinez@collabora.co.uk> wrote:
>> commit a99d76f leds: leds-gpio: use gpio_request_one
>>
>> changed the leds-gpio driver to use gpio_request_one() instead
>> of gpio_request() + gpio_direction_output()
>>
>> Unfortunately, it also made a semantic change that breaks the
>> leds-gpio driver.
>>
>> The gpio_request_one() flags parameter was set to:
>>
>> GPIOF_DIR_OUT | (led_dat->active_low ^ state)
>>
>> Since GPIOF_DIR_OUT is 0, the final flags value will just be the
>> XOR'ed value of led_dat->active_low and state.
>>
>> This value were used to distinguish between HIGH/LOW output initial
>> level and call gpio_direction_output() accordingly.
>>
>> With this new semantic gpio_request_one() will take the flags value
>> of 1 as a configuration of input direction (GPIOF_DIR_IN) and will
>> call gpio_direction_input() instead of gpio_direction_output().
>>
>> int gpio_request_one(unsigned gpio, unsigned long flags, const char *label)
>> {
>> ..
>>         if (flags & GPIOF_DIR_IN)
>>                 err = gpio_direction_input(gpio);
>>         else
>>                 err = gpio_direction_output(gpio,
>>                                 (flags & GPIOF_INIT_HIGH) ? 1 : 0);
>> ..
>> }
>>
>> The right semantic is to evaluate led_dat->active_low ^ state and
>> set the output initial level explicitly.
>>
>> Signed-off-by: Javier Martinez Canillas <javier.martinez@collabora.co.uk>
>> ---
>>
>> This makes LEDs to work again on my IGEPv2 board (TI OMAP3 based SoC).
>>
>> I sent this patch before but then realized that I only cc'ed to linux-leds.
>> So, I'm resending the patch cc'ing linux-omap,linux-arm-kernel and LKML to
>> reach a broader audience and have more people review/test the patch.
>>
>> Sorry for the noise if someone got it twice.
>>
>>  drivers/leds/leds-gpio.c |    5 +++--
>>  1 files changed, 3 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/leds/leds-gpio.c b/drivers/leds/leds-gpio.c
>> index 1885a26..a0d931b 100644
>> --- a/drivers/leds/leds-gpio.c
>> +++ b/drivers/leds/leds-gpio.c
>> @@ -127,8 +127,9 @@ static int create_gpio_led(const struct gpio_led *template,
>>                 led_dat->cdev.flags |= LED_CORE_SUSPENDRESUME;
>>
>>         ret = devm_gpio_request_one(parent, template->gpio,
>> -                       GPIOF_DIR_OUT | (led_dat->active_low ^ state),
>> -                       template->name);
>> +                                   (led_dat->active_low ^ state) ?
>> +                                   GPIOF_OUT_INIT_HIGH : GPIOF_OUT_INIT_LOW,
>> +                                   template->name);
>>         if (ret < 0)
>>                 return ret;
>>
>> --
>> 1.7.7.6
>>
> 
> Without this patch my IGEP v2 LEDs were dead,
> and this patch brings them back.
> 
> Tested-by: Ezequiel Garcia <ezequiel.garcia@free-electrons.com>
> 
> Thanks,
> 
>     Ezequiel
> 

Hello,

Any news on this?

GPIO LEDs support is still not working on latest mainline kernel and other
people report that this patch solves the issue for them.

Thanks a lot and best regards,
Javier

WARNING: multiple messages have this Message-ID (diff)
From: javier.martinez@collabora.co.uk (Javier Martinez Canillas)
To: linux-arm-kernel@lists.infradead.org
Subject: [RESEND PATCH] leds: leds-gpio: set devm_gpio_request_one() flags correctly
Date: Mon, 31 Dec 2012 14:08:27 +0100	[thread overview]
Message-ID: <50E18E4B.7000107@collabora.co.uk> (raw)
In-Reply-To: <CALF0-+XM4EZJHU360AUAUFBPctwO81JQ7kUiH12V2n6x7wCXfA@mail.gmail.com>

On 12/21/2012 06:06 PM, Ezequiel Garcia wrote:
> On Fri, Dec 21, 2012 at 12:07 PM, Javier Martinez Canillas
> <javier.martinez@collabora.co.uk> wrote:
>> commit a99d76f leds: leds-gpio: use gpio_request_one
>>
>> changed the leds-gpio driver to use gpio_request_one() instead
>> of gpio_request() + gpio_direction_output()
>>
>> Unfortunately, it also made a semantic change that breaks the
>> leds-gpio driver.
>>
>> The gpio_request_one() flags parameter was set to:
>>
>> GPIOF_DIR_OUT | (led_dat->active_low ^ state)
>>
>> Since GPIOF_DIR_OUT is 0, the final flags value will just be the
>> XOR'ed value of led_dat->active_low and state.
>>
>> This value were used to distinguish between HIGH/LOW output initial
>> level and call gpio_direction_output() accordingly.
>>
>> With this new semantic gpio_request_one() will take the flags value
>> of 1 as a configuration of input direction (GPIOF_DIR_IN) and will
>> call gpio_direction_input() instead of gpio_direction_output().
>>
>> int gpio_request_one(unsigned gpio, unsigned long flags, const char *label)
>> {
>> ..
>>         if (flags & GPIOF_DIR_IN)
>>                 err = gpio_direction_input(gpio);
>>         else
>>                 err = gpio_direction_output(gpio,
>>                                 (flags & GPIOF_INIT_HIGH) ? 1 : 0);
>> ..
>> }
>>
>> The right semantic is to evaluate led_dat->active_low ^ state and
>> set the output initial level explicitly.
>>
>> Signed-off-by: Javier Martinez Canillas <javier.martinez@collabora.co.uk>
>> ---
>>
>> This makes LEDs to work again on my IGEPv2 board (TI OMAP3 based SoC).
>>
>> I sent this patch before but then realized that I only cc'ed to linux-leds.
>> So, I'm resending the patch cc'ing linux-omap,linux-arm-kernel and LKML to
>> reach a broader audience and have more people review/test the patch.
>>
>> Sorry for the noise if someone got it twice.
>>
>>  drivers/leds/leds-gpio.c |    5 +++--
>>  1 files changed, 3 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/leds/leds-gpio.c b/drivers/leds/leds-gpio.c
>> index 1885a26..a0d931b 100644
>> --- a/drivers/leds/leds-gpio.c
>> +++ b/drivers/leds/leds-gpio.c
>> @@ -127,8 +127,9 @@ static int create_gpio_led(const struct gpio_led *template,
>>                 led_dat->cdev.flags |= LED_CORE_SUSPENDRESUME;
>>
>>         ret = devm_gpio_request_one(parent, template->gpio,
>> -                       GPIOF_DIR_OUT | (led_dat->active_low ^ state),
>> -                       template->name);
>> +                                   (led_dat->active_low ^ state) ?
>> +                                   GPIOF_OUT_INIT_HIGH : GPIOF_OUT_INIT_LOW,
>> +                                   template->name);
>>         if (ret < 0)
>>                 return ret;
>>
>> --
>> 1.7.7.6
>>
> 
> Without this patch my IGEP v2 LEDs were dead,
> and this patch brings them back.
> 
> Tested-by: Ezequiel Garcia <ezequiel.garcia@free-electrons.com>
> 
> Thanks,
> 
>     Ezequiel
> 

Hello,

Any news on this?

GPIO LEDs support is still not working on latest mainline kernel and other
people report that this patch solves the issue for them.

Thanks a lot and best regards,
Javier

  reply	other threads:[~2012-12-31 13:08 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-12-21 15:07 [RESEND PATCH] leds: leds-gpio: set devm_gpio_request_one() flags correctly Javier Martinez Canillas
2012-12-21 15:07 ` Javier Martinez Canillas
2012-12-21 17:06 ` Ezequiel Garcia
2012-12-21 17:06   ` Ezequiel Garcia
2012-12-31 13:08   ` Javier Martinez Canillas [this message]
2012-12-31 13:08     ` Javier Martinez Canillas

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=50E18E4B.7000107@collabora.co.uk \
    --to=javier.martinez@collabora.co.uk \
    --cc=elezegarcia@gmail.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-leds@vger.kernel.org \
    --cc=linux-omap@vger.kernel.org \
    /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.