[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20081027130343.GB14829@atrey.karlin.mff.cuni.cz>
Date: Mon, 27 Oct 2008 14:03:44 +0100
From: Pavel Machek <pavel@...e.cz>
To: Thomas Renninger <trenn@...e.de>
Cc: Eric Piel <eric.piel@...mplin-utc.net>, akpm@...ux-foundation.org,
burman.yan@...il.com, rpurdie@...ys.net,
LKML <linux-kernel@...r.kernel.org>,
Len Brown <len.brown@...el.com>,
Kay Sievers <kasievers@...e.de>, hmh@....eng.br
Subject: Re: leds-hp-disk vs lis3lv02d
> > OTOH it should
> > not block merge; both drivers still work and are useful.
> But for long-term the HPQ0004 specific things in the lids3v driver should get
> merged with your HP leds driver also registering for HPQ0004 and the lids3v
> specific things should get a separate driver which HPQ0004 driver makes use
> of?
Yep, that sounds sane.
> Pavel: I am also not sure whether it's a good idea to mis-use the HP's LED for
> mail notification or similar or to expose this one as a general LED. This LED
> is intended to be used with the disk parking feature by the vendor?
> I don't know the LED interface well, but if it's now possible that
> every mail
That's how LED interface works. This _is_ general LED.
Check permissions in /sys; root permissons should be needed to
blink the LED.
> or other app can reprogram the disk parking LED for it's own purposes, this
> sounds wrong. The LED can still be accessed and activated, e.g. when disk
> gets parked behind the OS'es back. If this is a nice hack to e.g. use LED for
> suspend debugging or similar, then it should be well hidden to the outside
> world.
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists