On Wed, Mar 24, 2021 at 9:31 AM Geert Uytterhoeven [off-list ref] wrote:

On Tue, Mar 23, 2021 at 9:40 PM Pavel Machek [off-list ref] wrote:

quoted

quoted

CC linux-leds (which I intended, but forgot to add)

cover letter at
https://lore.kernel.org/linux-devicetree/20210322144848.1065067-1-geert@linux-m68k.org/ (local)

quoted

quoted

quoted

quoted

+     err = ht16k33_brightness_set(priv, seg->led.brightness);
      if (err)
              return err;

The LED class can pretty much do what the backlight class can and more.

Maybe we can stop registering a backlight device in the fbdev case and
register a led device for both. This makes the code cleaner and drops
a dependency but will break backwards compatibility.

I'd prefer a single solution that covers both use cases, but I'm not
sure about the 'breaking backwards compatibility' consequence...

For new drivers, breaking compatibility should not be a problem.

The dot-matrix support is part of the existing driver, thus subject to
backwards compatibility.
Perhaps we can register the LED device for both, and build the backlight
device on top of the LED device, like "led-backlight" does.  Would that
work? Or can't the LED no longer be controlled from sysfs (e.g.
triggers) if it is in use by a backlight driver?

Using "led-backlight", the backlight can no longer be controlled from
sysfs, precluding the use of other triggers incl. hardware blinking.
But a normal LED can be used as a backlight, with ledtrig-backlight,
so that is the most flexible option, but only if no backwards
compatibility is to be considered.


Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds