Re: [PATCH v2] leds: ledtrig-morse: send out morse code

[Jacek Anaszewski]

Hi All,

On 07/04/2018 08:19 PM, Pavel Machek wrote:
> Hi!
>
> > On Wed, Jul 04, 2018 at 08:53:05AM +0200, Pavel Machek wrote:
> > > As I stated before, I don't think morse encoder belongs in kernel.
> >
> > On the opposite, I think that the kernel needs to be a bit more autonomous
> > when it comes to reporting its own issues. Being able to report a panic
> > when userland cannot be accessed for example is the reason why we've seen
> > various features such as blinking keyboard LEDs for this.
>
> Being able to report panics by blinking would be nice... but proposed
> patch does NOT do that.

Actually we do have already drivers/leds/trigger/ledtrig-panic.c.

> > > LED pattern trigger should be merged, instead.
> >
> > Well, just like we have LED and LED triggers in the kernel, I think having
> > a generic way to use patterns could be nice and in this case Morse could be
> > one such pattern, but if that means it's limited to userland to configure
> > it then it sadly voids all of its benefits.
>
> Proposed patch is already limited to configuration from userland... so
> it does not have any benefits.

We could turn this piece of code into a lib and make it usable by
both kernel/panic.c (similar to panic_blink) as well by
the ledtrig-morse.c.

> If special "panic blinking" mode is wanted -- I guess that would make
> sense.
>
> But
>
> a) trigger may not be right infrastructure for that; triggers need
> quite a lot kernel to be working, as they run in separate threads --
> panic blinking probably should be mdelay / brightness set / mdelay,
> and probably limited to LEDs that can be accessed without sleeping.
>
> b) we may want trigger to be used for something else (Caps lock? HDD
> activity?)  when not panicked. Thus, again, trigger is not exactly
> suitable. (It might make sense to blink many/all LEDs simultaneously
> to make it super obvious to the user).
>
> 									Pavel

--
Best regards,
Jacek Anaszewski