LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
From: Jean Delvare <khali@linux-fr.org>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Dax Kelson <dax@gurulabs.com>,
	linux-kernel <linux-kernel@vger.kernel.org>
Subject: Re: Linus' laptop and Num lock status
Date: Sun, 18 Feb 2007 17:19:40 +0100	[thread overview]
Message-ID: <20070218171940.68a4c44d.khali@linux-fr.org> (raw)
In-Reply-To: <Pine.LNX.4.64.0702141130340.20368@woody.linux-foundation.org>

Hi Linus,

On Wed, 14 Feb 2007 11:32:34 -0800 (PST), Linus Torvalds wrote:
> On Wed, 14 Feb 2007, Jean Delvare wrote:
> > On x86, the BIOS led state can be read from byte 0x97 the BIOS RAM. The
> > BIOS RAM is mapped at 0x400 so all we need to do is to one byte from
> > RAM (offset 0x497). This is how Suse's hwinfo does.
> 
> Heh. Shows just how much I ever used DOS and BIOS.

Well, I didn't know about it either before I was told about how hwinfo
was able to retrieve the information.

> > But maybe the first question to ask is: why is the BIOS setting lost in
> > the first place? Why is the kernel resetting the led state?
> 
> Ehh. Silly question. "Those flags, they do nothing."
> 
> The kernel needs to know what they are in order to react correctly to 
> them. And since you can't read them from hardware, the only way to know 
> what they are (if you don't know about BIOS magic areas) is to SET THEM.
> 
> Which is what the kernel has traditionally always done.

OK, it makes sense, thanks for clarifying this point.

Would it be acceptable to add some code in the kernel to read the
settings from the BIOS where possible, and have the kernel write these
settings rather than the default "all LEDs disabled"?

The problem is that I don't know how we can know for sure whether there
is BIOS RAM to read from, or not. Now that some x86-based system use
EFI instead of a traditional BIOS, I guess we can't just assume that
x86 or x86-64 implies there's a BIOS.

-- 
Jean Delvare

  parent reply	other threads:[~2007-02-18 16:19 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-02-14 18:56 Dax Kelson
2007-02-14 19:12 ` Linus Torvalds
2007-02-14 19:19   ` Dax Kelson
2007-02-14 19:21   ` Jean Delvare
2007-02-14 19:32     ` Linus Torvalds
2007-02-14 21:34       ` Dax Kelson
2007-02-14 21:58         ` Jan Engelhardt
2007-02-15  0:06           ` Krzysztof Halasa
2007-02-20 13:57             ` Helge Hafting
2007-02-15  0:31           ` Alan
2007-02-18 16:19       ` Jean Delvare [this message]
2007-02-15 14:34     ` H. Peter Anvin
2007-02-18 16:04       ` Jean Delvare
2007-02-18 17:32         ` H. Peter Anvin
2007-02-18 18:06           ` Randy Dunlap
2007-02-19  0:26             ` H. Peter Anvin
2007-02-18 17:54         ` Randy Dunlap
2007-02-14 19:26   ` Arjan van de Ven
2007-02-15 14:25   ` H. Peter Anvin

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=20070218171940.68a4c44d.khali@linux-fr.org \
    --to=khali@linux-fr.org \
    --cc=dax@gurulabs.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=torvalds@linux-foundation.org \
    --subject='Re: Linus'\'' laptop and Num lock status' \
    /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

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).