[lkml]   [2010]   [Jun]   [3]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [PATCH] panic: keep blinking in spite of long spin timer mode

    On Wed, 2 Jun 2010 11:34:46 -0700 Andrew Morton wrote:

    > The whole panic-blink setup seems rather poorly thought out.
    > Would it not be better if a call to (*panic_blink)() were to simply set
    > the state of the LED and then return? So callers can do
    > int state = 0;
    > for ( ; ; ) {
    > (*panic_blink)(state);
    > state ^= 1;
    > mdelay(MSEC_PER_SEC);
    > }
    > ?

    Your proposal is rather simpler than the current patch, indeed.

    I carefully went into the proposal:

    - With this implementation, the time to call to mdelay() needs to be
    variable in order to change the speed of blinking.
    - It is not desirable that the period to call to touch_nmi_watchdog()
    or touch_softlockup_watchdog() depends on the speed of blinking.
    - We would like to leave the room that can be implemented as not only
    a simple blinking but also as a so-called morse blinking which con-
    tains useful information when kernel panics.

    That being the reason, I will keep the current implementation that the
    time to call mdelay() is a short constant (as 1ms usually).

    BTW, there are some sanity checks or something in panic_blink_enter(),
    which need not exist there, so I have moved them to appropriate place.

    Thank you for the suggestion. See you next PATCH v2.

    TAMUKI Shoichi

     \ /
      Last update: 2010-06-03 23:53    [W:0.034 / U:55.540 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site