On Thu, May 8, 2025 at 5:27 PM Nam Tran <trannamatk@xxxxxxxxx> 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@xxxxxxxxx> 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? -- With Best Regards, Andy Shevchenko
