All of lore.kernel.org
 help / color / mirror / Atom feed
From: LABBE Corentin <clabbe@baylibre.com>
To: Daniel Thompson <daniel.thompson@linaro.org>
Cc: lee.jones@linaro.org, jingoohan1@gmail.com,
	dri-devel@lists.freedesktop.org, linux-fbdev@vger.kernel.org,
	linux-kernel@vger.kernel.org, khilman@baylibre.com,
	Jean-Jacques Hiblot <jjhiblot@ti.com>,
	Pavel Machek <pavel@ucw.cz>
Subject: Re: [PATCH] backlight: led_bl: Add support for an "enable" GPIO
Date: Tue, 2 Nov 2021 22:42:16 +0100	[thread overview]
Message-ID: <YYGwuCmORnjFRHMk@Red> (raw)
In-Reply-To: <20211102112514.75v7evbdp4ccyyt5@maple.lan>

Le Tue, Nov 02, 2021 at 11:25:14AM +0000, Daniel Thompson a écrit :
> On Tue, Nov 02, 2021 at 11:19:42AM +0000, Daniel Thompson wrote:
> > On Tue, Nov 02, 2021 at 10:04:55AM +0000, Corentin LABBE wrote:
> > > From: Jean-Jacques Hiblot <jjhiblot@ti.com>
> > > 
> > > This patch adds support for an "enable GPIO".
> > 
> > Before taking this kind of change is there a good reason why backlight
> > should manage the GPIO? I thought that the LED subsystem was a sub
> > system for LEDs (not LED controllers). In other words if you direct
> > that the LED be lit up then isn't it the LED driver's job to manage
> > the GPIO and ensure that it lights up?
> 
> Sorry... I should have paid more attention to my sense of déjà vu with
> this patch.
> 
> This approach was discussed and rejected when we first introduced the
> led_bl driver:
> https://lore.kernel.org/linux-leds/20190705100851.zn2jkipj4fxq5we6@devuan/
> 

Hello

I am sorry, I didnt checked if the patch was already submitted or not.

Regards

WARNING: multiple messages have this Message-ID (diff)
From: LABBE Corentin <clabbe@baylibre.com>
To: Daniel Thompson <daniel.thompson@linaro.org>
Cc: linux-fbdev@vger.kernel.org, jingoohan1@gmail.com,
	linux-kernel@vger.kernel.org, dri-devel@lists.freedesktop.org,
	Pavel Machek <pavel@ucw.cz>,
	khilman@baylibre.com, Jean-Jacques Hiblot <jjhiblot@ti.com>,
	lee.jones@linaro.org
Subject: Re: [PATCH] backlight: led_bl: Add support for an "enable" GPIO
Date: Tue, 2 Nov 2021 22:42:16 +0100	[thread overview]
Message-ID: <YYGwuCmORnjFRHMk@Red> (raw)
In-Reply-To: <20211102112514.75v7evbdp4ccyyt5@maple.lan>

Le Tue, Nov 02, 2021 at 11:25:14AM +0000, Daniel Thompson a écrit :
> On Tue, Nov 02, 2021 at 11:19:42AM +0000, Daniel Thompson wrote:
> > On Tue, Nov 02, 2021 at 10:04:55AM +0000, Corentin LABBE wrote:
> > > From: Jean-Jacques Hiblot <jjhiblot@ti.com>
> > > 
> > > This patch adds support for an "enable GPIO".
> > 
> > Before taking this kind of change is there a good reason why backlight
> > should manage the GPIO? I thought that the LED subsystem was a sub
> > system for LEDs (not LED controllers). In other words if you direct
> > that the LED be lit up then isn't it the LED driver's job to manage
> > the GPIO and ensure that it lights up?
> 
> Sorry... I should have paid more attention to my sense of déjà vu with
> this patch.
> 
> This approach was discussed and rejected when we first introduced the
> led_bl driver:
> https://lore.kernel.org/linux-leds/20190705100851.zn2jkipj4fxq5we6@devuan/
> 

Hello

I am sorry, I didnt checked if the patch was already submitted or not.

Regards

  reply	other threads:[~2021-11-02 21:42 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-11-02 10:04 [PATCH] backlight: led_bl: Add support for an "enable" GPIO Corentin LABBE
2021-11-02 10:04 ` Corentin LABBE
2021-11-02 11:19 ` Daniel Thompson
2021-11-02 11:19   ` Daniel Thompson
2021-11-02 11:25   ` Daniel Thompson
2021-11-02 11:25     ` Daniel Thompson
2021-11-02 21:42     ` LABBE Corentin [this message]
2021-11-02 21:42       ` LABBE Corentin

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=YYGwuCmORnjFRHMk@Red \
    --to=clabbe@baylibre.com \
    --cc=daniel.thompson@linaro.org \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=jingoohan1@gmail.com \
    --cc=jjhiblot@ti.com \
    --cc=khilman@baylibre.com \
    --cc=lee.jones@linaro.org \
    --cc=linux-fbdev@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=pavel@ucw.cz \
    /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.