All of lore.kernel.org
 help / color / mirror / Atom feed
From: Pavel Machek <pavel@ucw.cz>
To: Juergen Borleis <jbe@pengutronix.de>
Cc: linux-leds@vger.kernel.org,
	"Uwe Kleine-König" <u.kleine-koenig@pengutronix.de>,
	linux-kernel@vger.kernel.org,
	"Greg Kroah-Hartman" <gregkh@linuxfoundation.org>,
	kernel@pengutronix.de
Subject: Re: [PATCH] leds: trigger/tty: Use led_set_brightness() to support all use cases
Date: Mon, 3 May 2021 12:16:50 +0200	[thread overview]
Message-ID: <20210503101650.GC6621@amd> (raw)
In-Reply-To: <20210503092542.14497-1-jbe@pengutronix.de>

[-- Attachment #1: Type: text/plain, Size: 1078 bytes --]

On Mon 2021-05-03 11:25:42, Juergen Borleis wrote:
> Using led_set_brightness_sync() only works for LEDs which are connected
> via some kind of external bus like I²C or SPI. But it doesn't work for
> the simple use case of directly connected LEDs via GPIOs.

Really? I'd need to check.

> Because this function only honors the led_classdev::brightness_set_blocking
> callback. But the LED-GPIO driver registers the
> led_classdev::brightness_set member if the GPIO can be modified directly
> and thus, TTY triggers fail silently with -ENOTSUPP.
> 
> With the previously used led_set_brightness() it works for both use cases.
> This function first checks for the simple case where the GPIO can be changed
> without additional overhead, and if it fails, does the modification via a
> workqueue.

Yeah, but that is not what we want. We are already running in the
workqueue.

We really should have a API that can be called from process context,
and just simply sets the brightness.

Best regards,
								Pavel
-- 
http://www.livejournal.com/~pavelmachek

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]

  reply	other threads:[~2021-05-03 10:16 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-05-03  9:25 [PATCH] leds: trigger/tty: Use led_set_brightness() to support all use cases Juergen Borleis
2021-05-03 10:16 ` Pavel Machek [this message]
2023-01-09  8:43 ` Uwe Kleine-König
2024-02-23 14:22   ` Lee Jones
2024-02-23 14:24     ` Lee Jones

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=20210503101650.GC6621@amd \
    --to=pavel@ucw.cz \
    --cc=gregkh@linuxfoundation.org \
    --cc=jbe@pengutronix.de \
    --cc=kernel@pengutronix.de \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-leds@vger.kernel.org \
    --cc=u.kleine-koenig@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.