Re: [PATCH 0/6] auxdisplay: Add support for the Titanmec TM1628 7 segment display controller

[Andreas Färber <afaerber@xxxxxxx>]

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)