From: "Dmitry Torokhov" <dmitry.torokhov@gmail.com>
To: "Andi Kleen" <ak@suse.de>
Cc: "Indan Zupancic" <indan@nul.nu>,
"Linus Torvalds" <torvalds@linux-foundation.org>,
"Stephen Hemminger" <shemminger@linux-foundation.org>,
"Andrew Morton" <akpm@linux-foundation.org>,
linux-kernel@vger.kernel.org, bwalle@suse.de
Subject: Re: blink driver power saving
Date: Mon, 2 Jul 2007 09:42:04 -0400 [thread overview]
Message-ID: <d120d5000707020642j752ca814l501aaa543f9babcf@mail.gmail.com> (raw)
In-Reply-To: <200707021439.27357.ak@suse.de>
[-- Attachment #1: Type: text/plain, Size: 2206 bytes --]
On 7/2/07, Andi Kleen <ak@suse.de> wrote:
>
> > > Perhaps one of you geniuses who all hate it can find a better way to
> > > solve the "video output dead after kexec; but need visual feedback to the user
> > > while crash dumping" problem. I'm waiting for your patches.
> > >
> >
> > I don't don't like it ;) Unfortunately too many people end up enabling
>
> Yes that's pretty weird. I admit I hadn't expected
> that problem. blink is equivalent to "annoy me" and it
> is a mystery why so many people should willingly ask their computer to
> annoy them.
>
> Or perhaps they update their configs with yes | make oldconfig?
>
> User psychology can be mysterious.
>
> I wonder if the kernel offered a CONFIG_FORMAT_FILESYSTEMS_AT_BOOT
> how many people would enable that @) Might be an interesting experiment
> for next April.
>
Heh ;) That could be interesting.
> > it and having issues with their keyboards.
>
> Forcing a suitable slow rate should fix that shouldn't it? We need
> that anyways to stop the "setleds DOS".
>
I already have a patch that throttles AT keyboard when switching LED
state. However there is another problem - i8042's interrupt hanler is
racing with panic_blink polling the keyboar controller and they both
don;t quite like that.
> > Can we have it depend on
> > DEBUG_KERNEL?
>
> Yes that would be probably a good idea; even though it is technically
> not correct: the debug kernel doesn't try to debug itself. But anyways,
> it's probably the best place.
>
> > And probably KEXEC as well?
>
> The kcrash kernel doesn't necessarily need to have kexec enabled by
> itself.
>
OK.
> > Another option would be for it not use panic_blink. Do your kexec
> > kernels have atkbd support enabled? You could write an new "blink"
> > input handler that would latch to keyboards supporting leds and blink
> > by sending EV_LED events.
>
> Yes that would be probably a better implementation. Also hook something
> for USB keyboards. iirc Bernhard Walle (cc'ed) was looking at that.
>
I was thinking about something like the atached (untested and sorry
for using attachment). It shoudl blink just one led (numLock) on any
keyboard that has such LED (and allows to control it).
--
Dmitry
[-- Attachment #2: blink.c --]
[-- Type: text/plain, Size: 2852 bytes --]
/*
* Debug driver that continuosly blink LEDs on keyboards
*
* Copyright (c) 2007 Dmitry Torokhov
*/
/*
* This program is free software; you can redistribute it and/or modify it
* under the terms of the GNU General Public License version 2 as published
* by the Free Software Foundation.
*/
#include <linux/module.h>
#include <linux/input.h>
#include <linux/slab.h>
#include <linux/workqueue.h>
#include <linux/init.h>
MODULE_AUTHOR("Dmitry Torokhov <dtor@mail.ru>");
MODULE_DESCRIPTION("Blink driver");
MODULE_LICENSE("GPL");
struct blinker {
struct delayed_work work;
struct input_handle handle;
int state;
};
static void blink_task_handler(struct work_struct *work)
{
struct blinker *blinker = container_of(work, struct blinker, work.work);
blinker->state = !blinker->state;
input_inject_event(&blinker->handle, EV_LED, LED_NUML, blinker->state);
schedule_delayed_work(&blinker->work, msecs_to_jiffies(250));
}
static void blink_event(struct input_handle *handle, unsigned int type,
unsigned int code, int down)
{
/*
* This is a very rare handler that does not process any input
* events; just injects them.
*/
}
static int blink_connect(struct input_handler *handler, struct input_dev *dev,
const struct input_device_id *id)
{
struct blinker *blinker;
struct input_handle *handle;
int error;
blinker = kzalloc(sizeof(struct blinker), GFP_KERNEL);
if (!blinker)
return -ENOMEM;
INIT_DELAYED_WORK(&blinker->work, blink_task_handler);
handle = &blinker->handle;
handle->dev = dev;
handle->handler = handler;
handle->name = "blink";
handle->private = blinker;
error = input_register_handle(handle);
if (error)
goto err_free_handle;
error = input_open_device(handle);
if (error)
goto err_unregister_handle;
schedule_delayed_work(&blinker->work, 0);
return 0;
err_unregister_handle:
input_unregister_handle(handle);
err_free_handle:
kfree(handle);
return error;
}
static void blink_disconnect(struct input_handle *handle)
{
struct blinker *blinker = handle->private;
cancel_rearming_delayed_work(&blinker->work);
input_close_device(handle);
input_unregister_handle(handle);
kfree(blinker);
}
static const struct input_device_id blink_ids[] = {
{
.flags = INPUT_DEVICE_ID_MATCH_EVBIT | INPUT_DEVICE_ID_MATCH_LEDBIT,
.evbit = { BIT(EV_LED) },
.keybit = { [LONG(LED_NUML)] = BIT(LED_NUML) },
},
{ }
};
static struct input_handler blink_handler = {
.event = blink_event;
.connect = blink_connect,
.disconnect = blink_disconnect,
.name = "blink",
.id_table = blink_ids,
};
static int __init blink_handler_init(void)
{
return input_register_handler(&blink_handler);
}
static void __exit blink_handler_exit(void)
{
input_unregister_handler(&blink_handler);
flush_scheduled_work();
}
module_init(blink_handler_init);
module_exit(blink_handler_exit);
next prev parent reply other threads:[~2007-07-02 13:42 UTC|newest]
Thread overview: 39+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-07-02 11:43 Indan Zupancic
2007-07-02 11:51 ` Andi Kleen
2007-07-02 12:29 ` Indan Zupancic
2007-07-02 12:31 ` Dmitry Torokhov
2007-07-02 12:39 ` Andi Kleen
2007-07-02 12:56 ` Bernhard Walle
2007-07-02 13:42 ` Dmitry Torokhov [this message]
2007-07-02 13:43 ` Dmitry Torokhov
2007-07-02 20:19 ` Bernhard Walle
2007-07-04 21:47 ` Pavel Machek
2007-07-05 5:25 ` Dmitry Torokhov
2007-07-02 23:08 ` Pavel Machek
2007-07-03 5:42 ` Dmitry Torokhov
2007-07-04 21:40 ` Pavel Machek
2007-07-04 21:57 ` Pavel Machek
2007-07-04 22:11 ` Pavel Machek
2007-07-05 5:38 ` Dmitry Torokhov
2007-07-12 9:10 ` Pavel Machek
2007-07-13 0:42 ` Jiri Kosina
2007-07-04 22:32 ` Pavel Machek
2007-07-04 22:46 ` Linus Torvalds
2007-07-04 22:59 ` Pavel Machek
[not found] ` <alpine.LFD.0.98.0707041610530.9434@woody.linux-foundation.org>
2007-07-04 23:20 ` Pavel Machek
2007-07-03 7:12 ` Bernhard Walle
2007-07-04 19:37 ` Pavel Machek
2007-07-05 20:30 ` Bill Davidsen
[not found] <8CaWr-2o4-19@gated-at.bofh.it>
[not found] ` <8Cfjl-PJ-33@gated-at.bofh.it>
[not found] ` <8CfW1-1TX-23@gated-at.bofh.it>
[not found] ` <8ChEo-4yy-1@gated-at.bofh.it>
2007-07-02 13:11 ` Bodo Eggert
-- strict thread matches above, loose matches on Subject: below --
2007-07-01 16:50 Stephen Hemminger
2007-07-01 18:07 ` Linus Torvalds
2007-07-01 21:29 ` Andi Kleen
2007-07-01 22:14 ` Linus Torvalds
2007-07-01 23:59 ` Andi Kleen
2007-07-02 15:51 ` Linus Torvalds
2007-07-02 16:59 ` Alan Cox
2007-07-02 17:50 ` Stephen Hemminger
2007-07-02 19:03 ` Dmitry Torokhov
2007-07-02 19:08 ` Andi Kleen
2007-07-02 23:18 ` Pavel Machek
2007-07-01 21:26 ` Andi Kleen
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=d120d5000707020642j752ca814l501aaa543f9babcf@mail.gmail.com \
--to=dmitry.torokhov@gmail.com \
--cc=ak@suse.de \
--cc=akpm@linux-foundation.org \
--cc=bwalle@suse.de \
--cc=indan@nul.nu \
--cc=linux-kernel@vger.kernel.org \
--cc=shemminger@linux-foundation.org \
--cc=torvalds@linux-foundation.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®