linux-kernel - Re: [PATCH v8 0/5] auxdisplay: add support for TI LP5812 4x3 Matrix LED driver

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: <20250508150140.GS3865826@google.com>
Date: Thu, 8 May 2025 16:01:40 +0100
From: Lee Jones <lee@...nel.org>
To: Andy Shevchenko <andy.shevchenko@...il.com>
Cc: Nam Tran <trannamatk@...il.com>, andy@...nel.org, geert@...ux-m68k.org,
	pavel@....cz, robh@...nel.org, krzk+dt@...nel.org,
	conor+dt@...nel.org, christophe.jaillet@...adoo.fr, corbet@....net,
	devicetree@...r.kernel.org, linux-kernel@...r.kernel.org,
	linux-doc@...r.kernel.org, florian.fainelli@...adcom.com,
	bcm-kernel-feedback-list@...adcom.com,
	linux-rpi-kernel@...ts.infradead.org,
	linux-arm-kernel@...ts.infradead.org
Subject: Re: [PATCH v8 0/5] auxdisplay: add support for TI LP5812 4x3 Matrix
 LED driver

On Thu, 08 May 2025, Andy Shevchenko wrote:

> On Thu, May 8, 2025 at 5:27 PM Nam Tran <trannamatk@...il.com> wrote:
> > On Thu, 8 May 2025 Lee Jones wrote:
> > > On Thu, 08 May 2025, Andy Shevchenko wrote:
> > > > On Wed, May 7, 2025 at 7:42 PM Nam Tran <trannamatk@...il.com> wrote:
> 
> ...
> 
> > > > At least, based on the above it's my formal NAK from an auxdisplay perspective.
> > >
> > > This is fine.
> > >
> > > Just be aware, before you submit to LEDs again, that you need to use
> > > what is available in the LEDs subsystem to it's fullest, before
> > > hand-rolling all of your own APIs.  The first submission didn't use a
> > > single LED API.  This, as before, would be a big NACK also.
> >
> > Thanks for the clarification.
> >
> > Just to confirm — the current version of the driver is customized to allow
> > user space to directly manipulate LP5812 registers and to support the
> > device’s full feature set. Because of this, it doesn’t follow the standard
> > LED interfaces.
> 
> But why? What's wrong with the LED ABI? (see also below question
> before answering to this one)
> 
> > Given that, would it be acceptable to submit this driver under the misc subsystem instead?
> 
> But these are LEDs in the hardware and you can access them as 4
> individual LEDs, right?

Right.  Please work with the API you are offered in the first instance.
My first assumption is always that this driver isn't as special as you
think it might be.

-- 
Lee Jones [李琼斯]