From: Lee Jones <lee@kernel.org>
To: Linus Walleij <linus.walleij@linaro.org>
Cc: Pavel Machek <pavel@ucw.cz>,
linux-leds@vger.kernel.org, Arnd Bergmann <arnd@arndb.de>,
Tony Lindgren <tony@atomide.com>, Felipe Balbi <balbi@kernel.org>,
linux-omap@vger.kernel.org, linux-gpio@vger.kernel.org
Subject: Re: [PATCH v2] leds: Mark GPIO LED trigger broken
Date: Wed, 15 Mar 2023 15:14:14 +0000 [thread overview]
Message-ID: <20230315151414.GZ9667@google.com> (raw)
In-Reply-To: <20230314210059.419159-1-linus.walleij@linaro.org>
On Tue, 14 Mar 2023, Linus Walleij wrote:
> The GPIO LED trigger exposes a userspace ABI where a user
> can echo a GPIO number from the global GPIO numberspace into
> a file that will trigger a certain LED when active.
>
> This is problematic because the global GPIO numberspace is
> inherently instable. The trigger came about at a time when
> systems had one GPIO controller that defined hard-wired
> GPIOs numbered 0..N and this number space was stable.
>
> We have since moved to dynamic allocation of GPIO numbers
> and there is no real guarantee that a GPIO number will stay
> consistent even across a reboot: consider a USB attached
> GPIO controller for example. Or two. Or the effect of
> probe order after adding -EPROBE_DEFER to the kernel.
>
> The trigger was added to support keypad LEDs on the Nokia
> n810 from the GPIO event when a user slides up/down the
> keypad. This is arch/arm/boot/dts/omap2420-n810.dts.
> A userspace script is needed to activate the trigger.
> This will be broken unless the script was updated recently
> since the OMAP GPIO controller now uses dynamic GPIO
> number allocations.
>
> I want to know that this trigger has active users that
> cannot live without it if we are to continue to support it.
>
> Option if this is really needed: I can develop a new trigger
> that can associate GPIOs with LEDs as triggers using device
> tree, which should also remove the use of userspace custom
> scripts to achieve this and be much more trustworthy, if
> someone with the Nokia n810 or a device with a similar need
> is willing to test it.
>
> Cc: Arnd Bergmann <arnd@arndb.de>
> Cc: Tony Lindgren <tony@atomide.com>
> Cc: Felipe Balbi <balbi@kernel.org>
> Cc: linux-omap@vger.kernel.org
> Cc: linux-gpio@vger.kernel.org
>
> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
> ---
> ChangeLog v1->v2:
> - Be less intrusive and just mark the feature broken
> for now.
> ---
> drivers/leds/trigger/Kconfig | 1 +
> 1 file changed, 1 insertion(+)
Added Pavel's Suggested-by:
Applied, thanks
--
Lee Jones [李琼斯]
next prev parent reply other threads:[~2023-03-15 15:14 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-03-14 21:00 [PATCH v2] leds: Mark GPIO LED trigger broken Linus Walleij
2023-03-15 15:14 ` Lee Jones [this message]
2023-08-24 18:32 ` Jan Kundrát
2023-09-11 9:17 ` Linus Walleij
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=20230315151414.GZ9667@google.com \
--to=lee@kernel.org \
--cc=arnd@arndb.de \
--cc=balbi@kernel.org \
--cc=linus.walleij@linaro.org \
--cc=linux-gpio@vger.kernel.org \
--cc=linux-leds@vger.kernel.org \
--cc=linux-omap@vger.kernel.org \
--cc=pavel@ucw.cz \
--cc=tony@atomide.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 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.