linux-gpio.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Linus Walleij <linus.walleij@linaro.org>
To: Hans de Goede <hdegoede@redhat.com>
Cc: Bartosz Golaszewski <bgolaszewski@baylibre.com>,
	Mark Gross <markgross@kernel.org>,
	Andy Shevchenko <andy@kernel.org>,
	Daniel Scally <djrscally@gmail.com>,
	Laurent Pinchart <laurent.pinchart@ideasonboard.com>,
	platform-driver-x86@vger.kernel.org, linux-gpio@vger.kernel.org,
	Sakari Ailus <sakari.ailus@linux.intel.com>,
	Kate Hsuan <hpa@redhat.com>,
	linux-media@vger.kernel.org
Subject: Re: [PATCH 0/5] gpio/media/int3472: Add support for tps68470 privacy-LED output
Date: Wed, 7 Dec 2022 01:25:56 +0100	[thread overview]
Message-ID: <CACRpkdZZ01gTeWaU5GybiafDM3EnyEhyuEMTenusfV2s1NdfXQ@mail.gmail.com> (raw)
In-Reply-To: <e04eaaa0-1a5d-7f8f-9cd9-4a2117f83aab@redhat.com>

On Mon, Dec 5, 2022 at 4:01 PM Hans de Goede <hdegoede@redhat.com> wrote:

> An alternative approach, would be to add support for LED
> lookup tables to the LED class code (like we already have
> for GPIOs) and use this to allow tying a LED classdev to
> a struct device on non devicetree platforms.
>
> Given the problems with the swnode approach from above
> I believe that this would actually be better then
> the swnode approach.
>
> Lookup tables like this use device-names, so we don't need
> to have swnode-s ready for both the provider and the consumer
> at the time of adding the lookup table entry. Instead all
> that is necessary is to know the device-names of both
> the provider and the consumer which are both known in
> advance.

I think this looks like a good idea.

We attach other resources such as clocks, regulators,
DMA channels, GPIOs exactly this way. So why not LEDs?

As GPIO maintainer I every now and then get a suggestion
like this to "just let this pass as a GPIO because it makes
my life so much easier", but it is the same curse as the
input subsystem has: it is versatile and well engineered so
it starts to look like a golden hammer (everything start to
look like nails).

But we are two GPIO maintainers and right now Bartosz
does the majority of the work, and if he thinks it's the best
idea ever I will certainly reconsider.

Yours,
Linus Walleij

  parent reply	other threads:[~2022-12-07  0:26 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-11-28 21:44 [PATCH 0/5] gpio/media/int3472: Add support for tps68470 privacy-LED output Hans de Goede
2022-11-28 21:44 ` [PATCH 1/5] gpio: tps68470: Fix tps68470_gpio_get() reading from the wrong register Hans de Goede
2022-11-29 10:22   ` Andy Shevchenko
2022-11-29 11:27     ` Hans de Goede
2022-11-29 11:56       ` Andy Shevchenko
2022-11-29 12:19         ` Hans de Goede
2022-11-29 12:34           ` Andy Shevchenko
2022-11-29 12:59             ` Hans de Goede
2022-11-30 15:16   ` Dan Scally
2022-11-28 21:44 ` [PATCH 2/5] gpio: tps68470: Make tps68470_gpio_output() always set the initial value Hans de Goede
2022-11-29 10:24   ` Andy Shevchenko
2022-11-29 11:33     ` Hans de Goede
2022-11-30 16:04   ` Dan Scally
2022-11-28 21:44 ` [PATCH 3/5] gpio: tps68470: Add support for the indicator LED outputs Hans de Goede
2022-11-29 10:28   ` Andy Shevchenko
2022-11-29 11:32     ` Hans de Goede
2022-11-29 11:59       ` Andy Shevchenko
2022-11-29 12:20         ` Hans de Goede
2022-11-29 12:35           ` Andy Shevchenko
2022-11-28 21:44 ` [PATCH 4/5] media: ov8865: Add support for a privacy-led GPIO Hans de Goede
2022-11-28 21:44 ` [PATCH 5/5] platform/x86: int3472: Add support for the back privacy LED on Surface Go models Hans de Goede
2022-12-03  9:32 ` [PATCH 0/5] gpio/media/int3472: Add support for tps68470 privacy-LED output Linus Walleij
2022-12-03 12:28   ` Hans de Goede
2022-12-05 15:01     ` Hans de Goede
2022-12-05 21:26       ` Laurent Pinchart
2022-12-05 21:37         ` Hans de Goede
2022-12-07  0:25       ` Linus Walleij [this message]
2022-12-07 17:37         ` Hans de Goede
2022-12-05  9:18 ` Sakari Ailus

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=CACRpkdZZ01gTeWaU5GybiafDM3EnyEhyuEMTenusfV2s1NdfXQ@mail.gmail.com \
    --to=linus.walleij@linaro.org \
    --cc=andy@kernel.org \
    --cc=bgolaszewski@baylibre.com \
    --cc=djrscally@gmail.com \
    --cc=hdegoede@redhat.com \
    --cc=hpa@redhat.com \
    --cc=laurent.pinchart@ideasonboard.com \
    --cc=linux-gpio@vger.kernel.org \
    --cc=linux-media@vger.kernel.org \
    --cc=markgross@kernel.org \
    --cc=platform-driver-x86@vger.kernel.org \
    --cc=sakari.ailus@linux.intel.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).