Hi, On 19.02.22 14:37, Heiner Kallweit wrote: > On 19.02.2022 14:27, Miguel Ojeda wrote: >> On Sat, Feb 19, 2022 at 2:13 PM Heiner Kallweit <hkallweit1@xxxxxxxxx> wrote: >>> >>> This series adds support for the Titanmec TM1628 7 segment display >>> controller. It's based on previous RFC work from Andreas Färber. >>> The RFC version placed the driver in the LED subsystem, but this was >>> NAK'ed by the LED maintainer. Therefore I moved the driver to >>> /drivers/auxdisplay what seems most reasonable to me. >> >> Could you please link to the discussion and/or summarize the rationale >> behind the NAK? >> > > +Pavel > > I didn't find an explicit reason, but I suppose Pavel sees this driver as > one that makes use of the LED subsystem, but doesn't belong to it. > In the following mail he's expressing his opinion that the driver should > be best placed under auxdisplay. > > https://lore.kernel.org/linux-arm-kernel/20200226130300.GB2800@xxxxxxxxxx/ And I disagreed. It does not fit with the other drivers in auxdisplay that were operating on a much higher level. I'd also like to point out that I did implement the map_to_7segment API, as was suggested, as you will find in my tree - which you may have missed, referencing only the RFC patchset and putting your authorship on it exclusively? A move from one directory to another should not warrant my author and SoB getting removed from the actual driver. Given that we need to manage a buffer with bits per segment or LED symbol, one idea that I haven't found time for yet was to implement it as framebuffer or drm device instead. (And most Realtek platforms got broken by removing the adjustable text base defines.) Regards, Andreas -- SUSE Software Solutions Germany GmbH Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Ivo Totev HRB 36809 (AG Nürnberg)
