linux-kernel - Re: [PATCH 0/3] auxdisplay: 7 segment LED display

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAHp75Vd3aza1192YpRHvi6y7oEsrAoYA3+Qcja7Fw22c9+xhRQ@mail.gmail.com>
Date: Tue, 27 Feb 2024 15:00:58 +0200
From: Andy Shevchenko <andy.shevchenko@...il.com>
To: Chris Packham <Chris.Packham@...iedtelesis.co.nz>, 
	"ojeda@...nel.org" <ojeda@...nel.org>, "robh+dt@...nel.org" <robh+dt@...nel.org>, 
	"krzysztof.kozlowski+dt@...aro.org" <krzysztof.kozlowski+dt@...aro.org>, 
	"conor+dt@...nel.org" <conor+dt@...nel.org>, "andrew@...n.ch" <andrew@...n.ch>, 
	"gregory.clement@...tlin.com" <gregory.clement@...tlin.com>, 
	"sebastian.hesselbarth@...il.com" <sebastian.hesselbarth@...il.com>, 
	"andy.shevchenko@...il.com" <andy.shevchenko@...il.com>, "geert@...ux-m68k.org" <geert@...ux-m68k.org>, 
	"pavel@....cz" <pavel@....cz>, "lee@...nel.org" <lee@...nel.org>, 
	"devicetree@...r.kernel.org" <devicetree@...r.kernel.org>, 
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>, 
	"linux-arm-kernel@...ts.infradead.org" <linux-arm-kernel@...ts.infradead.org>, 
	"linux-leds@...r.kernel.org" <linux-leds@...r.kernel.org>
Subject: Re: [PATCH 0/3] auxdisplay: 7 segment LED display

On Tue, Feb 27, 2024 at 10:43 AM Alexander Dahl <ada@...rsis.com> wrote:
> Am Mon, Feb 26, 2024 at 08:10:07PM +0000 schrieb Chris Packham:
> > On 27/02/24 05:04, Alexander Dahl wrote:
> > > Am Mon, Feb 26, 2024 at 10:34:20AM +1300 schrieb Chris Packham:
> > >> This series adds a driver for a 7 segment LED display.
> > >>
> > >> I'd like to get some feedback on how this could be extended to support >1
> > >> character. The driver as presented is sufficient for my hardware which only has
> > >> a single character display but I can see that for this to be generically useful
> > >> supporting more characters would be desireable.
> > >>
> > >> Earlier I posted an idea that the characters could be represended by
> > >> sub-nodes[1] but there doesn't seem to be a way of having that and keeping the
> > >> convenience of using devm_gpiod_get_array() (unless I've missed something).
> > >>
> > >> [1] - https://scanmail.trustwave.com/?c=20988&d=trbc5eARVo-5gepRnwbAKbQmiGk1bOSpqZDQx9bx7w&u=https%3a%2f%2flore%2ekernel%2eorg%2flkml%2f2a8d19ee-b18b-4b7c-869f-7d601cea30b6%40alliedtelesis%2eco%2enz%2f
> > > Read that thread out of curiosity and I'm sorry if I'm late to the
> > > party, but I wondered why this is limited to LEDs connected to GPIOs?
> > >
> > > Would it be possible to somehow stack this on top of some existing
> > > LEDs?  I mean you could wire a 7 segment device to almost any LED
> > > driver IC with enough channels, couldn't you?
> >
> > Mainly because the GPIO version is the hardware I have. I do wonder how
> > this might work with something like the pca9551 which really is just a
> > fancy version of the pca9554 on my board. A naive implementation would
> > be to configure all the pca9551 pins as GPIOs and use what I have as-is.
>
> My idea was to do it on top of the LED abstraction, not on top of the
> GPIO abstraction.  Currently you are using the GPIO consumer interface
> and group 7 gpios which are supplied by that pca9554 in your case, but
> could also be coming from a SoC or a 74hc595 etc.
>
> Why not put it a level of abstraction higher, and let it consume LEDs
> instead of GPIOs?  Your usecase would still be possible then.
>
> As far as I could see the concept of a LED consumer can be done, the
> leds-group-multicolor driver in
> drivers/leds/rgb/leds-group-multicolor.c does that, introduced with
> kernel v6.6 not so long ago.  It sets the sysfs entries of the LEDs
> part of the group to readonly so they are not usable on their own
> anymore and one would not disturb the grouped multicolor LED.
>
> This would allow to use LEDs as a 7 segment group driven by any LED
> driver including leds-gpio.

7-segment LEDs are not just a bunch of leds, they have explicit
meaning and using LED infrastructure is an obscuration of what's going
on (too many unrelated details are exposed, too hard to achieve what
user needs). In the auxdisplay we have already the concept of "line
display" with a 7-segment, or 14 (that are two main standards) with
respective character mapping in case somebody wants to print more than
hexadecimal digits on them. If I am mistaken, I would like to see the
concept in the example here on how user space will take care of
displaying (an arbitrary) data. Can you provide a draft of (user-side)
documentation before we even start going this direction?

> > Making a line display out of LED triggers might be another way of doing
> > it but not something I really want to pursue.
>
> Fair enough.  I just wanted to share my idea.  Didn't want to pressure
> you in any direction. :-)


-- 
With Best Regards,
Andy Shevchenko