linux-kernel - Re: [PATCH 17/17] auxdisplay: ht16k33: Add segment display LED support

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <CAMuHMdWQOQmeoNP8po19m_Fo9d55ur68CqOORX-NGhkLbRAsGg@mail.gmail.com>
Date:   Fri, 25 Jun 2021 14:39:40 +0200
From:   Geert Uytterhoeven <geert@...ux-m68k.org>
To:     Pavel Machek <pavel@....cz>
Cc:     Robin van der Gracht <robin@...tonic.nl>,
        Rob Herring <robh+dt@...nel.org>,
        Miguel Ojeda <ojeda@...nel.org>,
        Paul Burton <paulburton@...nel.org>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        "open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS" 
        <devicetree@...r.kernel.org>,
        "open list:BROADCOM NVRAM DRIVER" <linux-mips@...r.kernel.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        linux-leds <linux-leds@...r.kernel.org>
Subject: Re: [PATCH 17/17] auxdisplay: ht16k33: Add segment display LED support

On Wed, Mar 24, 2021 at 9:31 AM Geert Uytterhoeven <geert@...ux-m68k.org> wrote:
> On Tue, Mar 23, 2021 at 9:40 PM Pavel Machek <pavel@....cz> wrote:
> > > 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/

> > > > > +     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@...ux-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