From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
To: Michael Hanselmann <linux-kernel@hansmi.ch>
Cc: linuxppc-dev@ozlabs.org, johannes@sipsolutions.net,
rpurdie@rpsys.net, linux-kernel@killerfox.forkbomb.ch
Subject: Re: [PATCH] Keyboard backlight driver for Oct 2005 PowerBooks
Date: Mon, 28 Aug 2006 09:11:03 +1000 [thread overview]
Message-ID: <1156720264.8433.362.camel@localhost.localdomain> (raw)
In-Reply-To: <20060827230714.GA12569@hansmi.ch>
On Mon, 2006-08-28 at 01:07 +0200, Michael Hanselmann wrote:
> On Mon, Aug 28, 2006 at 08:34:23AM +1000, Benjamin Herrenschmidt wrote:
> > Why would we need a driver ? Userland can emit PMU commands directly...
>
> Drivers are there to abstract hardware. Userland shouldn't know about
> hardware specific commands (PMU commands in this case).
This is a bit of a broad statement :) If I were to follow you, thinks
like USB scanner or printer drivers should all be in the kernel :)
Well... they happen not to be.
Only drivers providing services to the kernel itself (block,
network, ...) or doing things like direct DMA, interrupts, etc... that
aren't useable from an exposed userland interfaces need to be in the
kernel.
> It would make it much simpler for programs to use these devices, because
> not each of them has to implement everything needed to locate the device
> and control it.
Then the best is to do a library.
> pbbuttonsd supports both the I²C and PMU variant. The code is a mess
> there and a generic driver would help to clean it up. And yes, I'm
> partly responsible for it, since I supplied the original patch for the
> PMU keyboard backlight support in pbbuttonsd.
>
> Maybe controlling the keyboard backlight could be moved to its own
> program anyway, because the algorithm used by pbbuttonsd isn't appealing
> to all people. But those are just ideas.
Yeah, separate program or library would do the trick just fine. Also,
your driver doesn't handle reading the light sensors, does it ?
> Oh, and using the LED class allows users to attach it to some trigger.
> Maybe someone wants to use it as the IDE LED. :-)
That would be just insane :)
> > At least, if we do a driver, it should provide a common interface to
> > both PMU and i2c based LMUs
>
> Yeah, I figured after sending it. You'll hear again from me once I got
> my hands on an I²C backlight. Something like the AMS driver would be
> nice.
I still think this has little to do in the kernel ...
Ben.
next prev parent reply other threads:[~2006-08-27 23:11 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-08-27 12:30 [PATCH] Keyboard backlight driver for Oct 2005 PowerBooks Michael Hanselmann
2006-08-27 22:34 ` Benjamin Herrenschmidt
2006-08-27 23:07 ` Michael Hanselmann
2006-08-27 23:11 ` Benjamin Herrenschmidt [this message]
2006-08-27 23:24 ` Michael Hanselmann
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=1156720264.8433.362.camel@localhost.localdomain \
--to=benh@kernel.crashing.org \
--cc=johannes@sipsolutions.net \
--cc=linux-kernel@hansmi.ch \
--cc=linux-kernel@killerfox.forkbomb.ch \
--cc=linuxppc-dev@ozlabs.org \
--cc=rpurdie@rpsys.net \
/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).