Re: [PATCH 17/17] auxdisplay: ht16k33: Add segment display LED support
From: Geert Uytterhoeven
Date: Fri Jun 25 2021 - 08:39:55 EST
On Wed, Mar 24, 2021 at 9:31 AM Geert Uytterhoeven <geert@xxxxxxxxxxxxxx> wrote:
> On Tue, Mar 23, 2021 at 9:40 PM Pavel Machek <pavel@xxxxxx> wrote:
> > > CC linux-leds (which I intended, but forgot to add)
> > >
> > > cover letter at
> > > https://lore.kernel.org/linux-devicetree/20210322144848.1065067-1-geert@xxxxxxxxxxxxxx/
> > > > > + 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.
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@xxxxxxxxxxxxxx
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