linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Philip Graham Willoughby <pgw99@doc.ic.ac.uk>
To: Andries Brouwer <aebr@win.tue.nl>
Cc: John Bradford <john@grabjohn.com>, linux-kernel@vger.kernel.org
Subject: Re: PATCH : LEDs - possibly the most pointless kernel subsystem ever
Date: Tue, 29 Jul 2003 22:34:58 +0100	[thread overview]
Message-ID: <20030729213458.GA21517@bodmin.doc.ic.ac.uk> (raw)
In-Reply-To: <20030729203745.GA2221@win.tue.nl>

On 2003-07-29 22:37:45 +0000, Andries Brouwer wrote:
> On Tue, Jul 29, 2003 at 09:38:52PM +0100, John Bradford wrote:
> 
> > Ah, I just thought, for debugging purposes we could have LEDs for:
> > 
> > * BKL taken
> > * Servicing interrupt
> > * Kernel stack usage > 2K
> 
> Ever tried keyboard.c:register_leds() ?

Nope -- I have just hacked together a driver to expose the keyboard leds
vie my leds interface (see below), _but_ register_leds is not an exported
symbol, not is it declared in <linux/keyboard.h> (on 2.4.21 anyway), so
you'll need to make some modifications if you want to actually use it.

Also, I'm not sure if there is a way of unregistering leds you register
in this way -- I've done a bodge job thus far, but you take your life in
your hands when you unload this module (in other words, don't). 

Regards,

Philip Willoughby

Systems Programmer, Department of Computing, Imperial College, London, UK
-- 
echo bzidd@nfo.ho.co.se | tr "bizndfohces" "pwgd9ociaku"
Why reinvent the wheel?                 Because we can make it rounder...

#include <linux/module.h>
#include <linux/kernel.h>
#include <linux/errno.h>
#include <linux/leds.h>
#include <linux/sched.h>
#include <linux/keyboard.h>
#include <linux/spinlock.h>
#include <asm/current.h>

static unsigned int keybleds;
static spinlock_t keybleds_lock = SPIN_LOCK_UNLOCKED;

static void
release (void * ignored)
{
  MOD_DEC_USE_COUNT;
}

static void
reserve (void * ignored)
{
  MOD_INC_USE_COUNT;
}

static void
set_state (unsigned int idx, unsigned char state, void *ignored)
{
  spin_lock(&keybleds_lock);
  keybleds &= ~(1 << idx);
  keybleds |= state & (1<<idx);
  spin_unlock(&keybleds_lock);
}

static unsigned char
get_state (unsigned int idx, void * ignored)
{
  unsigned char rv;
  spin_lock(&keybleds_lock);
  rv = (unsigned char)(keybleds & (1 << idx));
  spin_unlock(&keybleds_lock);
  return rv;
}

static struct linux_leds_info kbleds = {
get_state:get_state,
set_state:set_state,
reserve:reserve,
release:release,
count:3,
data:NULL,
drivername:THIS_MODULE,
};

static int __init
init_keyb_leds (void)
{
  register_leds(0, 0, &keybleds, 1);
  register_leds(0, 1, &keybleds, 2);
  register_leds(0, 2, &keybleds, 4);
  return leds_add (&kbleds);
}

static void __exit
cleanup_keyb_leds (void)
{
  register_leds(0, 3, NULL, 0);
  register_leds(0, 1, NULL, 0);
  register_leds(0, 2, NULL, 0);
  register_leds(0, 2, NULL, 0);
}

module_init(init_keyb_leds);
module_exit(cleanup_keyb_leds);

MODULE_LICENSE("GPL");
MODULE_AUTHOR("Philip Graham Willoughby <pgw@alumni.doc.ic.ac.uk>");
MODULE_DESCRIPTION("This module exposes the keyboard LEDs through the generic LEDs interface");
MODULE_SUPPORTED_DEVICE("Keyboards");
EXPORT_NO_SYMBOLS;


  reply	other threads:[~2003-07-29 21:38 UTC|newest]

Thread overview: 36+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-07-29 20:38 PATCH : LEDs - possibly the most pointless kernel subsystem ever John Bradford
2003-07-29 20:37 ` Andries Brouwer
2003-07-29 21:34   ` Philip Graham Willoughby [this message]
2003-07-29 20:40 ` Randolph Bentson
2003-07-29 21:15   ` Ryan Flowers
2003-07-29 20:43 ` Eli Carter
2003-07-30  6:09   ` Tomas Szepe
2003-07-30  6:37   ` Helge Deller
  -- strict thread matches above, loose matches on Subject: below --
2003-07-30 18:50 John Bradford
2003-07-30 16:08 John Bradford
2003-07-30 17:44 ` Pavel Machek
2003-07-30 18:50   ` Marc Giger
2003-07-30 19:05     ` Herbert Pötzl
2003-07-30 22:22     ` Brian McGroarty
2003-07-30 18:56   ` Herbert Pötzl
2003-07-30 19:02     ` Pavel Machek
2003-07-30 19:06     ` Marc Giger
2003-07-30 19:16       ` Herbert Pötzl
2003-07-31  8:31 ` jw schultz
2003-07-30 15:50 John Bradford
2003-07-30 12:27 "Andrey Borzenkov" 
2003-07-29 19:15 John Bradford
2003-07-29 19:51 ` Tim Hockin
2003-07-29 20:09 ` Joel Jaeggli
2003-07-29 21:20 ` Kent Borg
2003-07-29 21:44   ` Philip Graham Willoughby
2003-07-30 21:44     ` Mike Jagdis
2003-07-30 12:15 ` Pavel Machek
2003-07-29 15:17 Philip Graham Willoughby
2003-07-29 18:00 ` Pavel Machek
2003-07-30 11:45   ` Jamey Hicks
2003-07-30 12:27     ` Pavel Machek
2003-07-30  6:36 ` CaT
2003-07-30 13:00   ` Andries Brouwer
2003-07-30 13:20     ` CaT
2003-07-30 23:28 ` Greg KH

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=20030729213458.GA21517@bodmin.doc.ic.ac.uk \
    --to=pgw99@doc.ic.ac.uk \
    --cc=aebr@win.tue.nl \
    --cc=john@grabjohn.com \
    --cc=linux-kernel@vger.kernel.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;
as well as URLs for NNTP newsgroup(s).