linux-leds.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Uwe Kleine-König" <u.kleine-koenig@pengutronix.de>
To: Jeff LaBundy <jeff@labundy.com>
Cc: Jacek Anaszewski <jacek.anaszewski@gmail.com>,
	Pavel Machek <pavel@ucw.cz>, Dan Murphy <dmurphy@ti.com>,
	Thierry Reding <thierry.reding@gmail.com>,
	"linux-leds@vger.kernel.org" <linux-leds@vger.kernel.org>,
	"linux-pwm@vger.kernel.org" <linux-pwm@vger.kernel.org>
Subject: Re: [PATCH 3/3] leds: pwm: don't set the brightness during .probe
Date: Mon, 27 Jan 2020 08:41:21 +0100	[thread overview]
Message-ID: <20200127074121.n2qawknactfjqvkr@pengutronix.de> (raw)
In-Reply-To: <20200126194236.GC2569@labundy.com>

Hello Jeff,

On Sun, Jan 26, 2020 at 07:42:39PM +0000, Jeff LaBundy wrote:
> My only concern here is whether or not there happen to be some hardware
> out in the world whose PWM-related registers power on to a random state
> and unknowingly depended on brightness being forced to zero.

This might happen, and is (AFAIK) the same for other LED drivers.

> The other folks on the thread probably have some better view into this,
> but I wonder if the safest option would be to adopt the "default-state"
> property from leds/common.txt, and only forgo the call to led_pwm_set()
> if the property is set to "keep".

I think it would be sane to add support for parsing the default-state
property to the LED core. I was surprised to learn that this for now is
only implemented in a few LED drivers.

> I did test this and can confirm that the LED's state prior to the driver
> being loaded is preserved. However as you've warned, the brightness read
> back from user space is zero and does not match the actual brightness of
> the LED.

That is something that the core should handle, too. If there is no
.get_brightness callback and 0 is assumed, calling .set_brightness to 0
to ensure a right assumption sounds like the right thing to me.
 
> Understanding that it's more work, I wonder if this patch is not safe if
> we don't also add a brightness_get callback in case there were any cases
> where user space makes some decisions based on brightness == 0?
> 
> At any rate this patch does what is advertised, and so:
> 
> Tested-by: Jeff LaBundy <jeff@labundy.com>

Thanks for your feedback.

Best regards
Uwe

-- 
Pengutronix e.K.                           | Uwe Kleine-König            |
Industrial Linux Solutions                 | https://www.pengutronix.de/ |

      reply	other threads:[~2020-01-27  7:41 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-01-24 16:54 [PATCH 0/3] leds: pwm: some cleanups Uwe Kleine-König
2020-01-24 16:54 ` [PATCH 1/3] leds: pwm: simplify if condition Uwe Kleine-König
2020-01-26 18:55   ` Jeff LaBundy
2020-01-24 16:54 ` [PATCH 2/3] leds: pwm: convert to atomic PWM API Uwe Kleine-König
2020-01-26 19:15   ` Jeff LaBundy
2020-02-26 14:35     ` Pavel Machek
2020-02-26 14:55       ` Uwe Kleine-König
2020-01-24 16:54 ` [PATCH 3/3] leds: pwm: don't set the brightness during .probe Uwe Kleine-König
2020-01-26 19:42   ` Jeff LaBundy
2020-01-27  7:41     ` Uwe Kleine-König [this message]

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=20200127074121.n2qawknactfjqvkr@pengutronix.de \
    --to=u.kleine-koenig@pengutronix.de \
    --cc=dmurphy@ti.com \
    --cc=jacek.anaszewski@gmail.com \
    --cc=jeff@labundy.com \
    --cc=linux-leds@vger.kernel.org \
    --cc=linux-pwm@vger.kernel.org \
    --cc=pavel@ucw.cz \
    --cc=thierry.reding@gmail.com \
    /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;
as well as URLs for NNTP newsgroup(s).