lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Thu, 15 Feb 2007 00:51:36 +0100 (CET)
From:	Németh Márton <nm127@...email.hu>
To:	Dmitry Torokhov <dmitry.torokhov@...il.com>
cc:	linux-input@...ey.karlin.mff.cuni.cz, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] input: extend EV_LED



Dmitry Torokhov <dmitry.torokhov@...il.com> wrote:

> On 2/14/07, Németh Márton <nm127@...email.hu> wrote:
> >
> >
> > Dmitry Torokhov <dmitry.torokhov@...il.com> írta:
> >
> > > On 2/11/07, Németh Márton <nm127@...email.hu> wrote:
> > > >
> > > > Extend EV_LED handling code so that it can handle not
> > > > only two states (on/off) but also others. For example
> > > > a LED can blink using hardware acceleration. The code
> > > > changed so that it is similar to the code at EV_SND.
> > > >
> > >
> > > Hi,
> > >
> > > I am not sure we would need this, could you explain what
> > are you
> > > trying to use input leds for?
> > >
> > > Generally speaking leds within input subsystem are
> > supposed to be very
> > > simple on/off objects, mostly for reporting state of input
> > devices
> > > (keyboards), I am not even sure that LED_MAIL and
> > LED_CHARGING make
> > > much sense here. For more compex
objects(blinking/different
> > > colors/different brightness) we have a separate LED
subsystem
> > > (drivers/leds).
> >
> > The background is that I own a Clevo notebook model D4J,
> > product D410J which has a mail led near to the other LEDs.
> > The mail LED in question has three known state: off, blink
> > slow (0.5Hz), and blink fast (1Hz).
> >
> > The mail LED can be programmed through the ports 0x60 and
> > 0x64. These ports belog to the i8042 controller, which is
> > operated by the input subsystem. To be able to access the
> > i8042 controller correctly, I need the spinlock i8042_lock
> > held, which is defined as static in
> > linux/drivers/input/serio/i8042.c .
> >
> > What I miss currently from the input subsystem is that the
> > EV_LED can only handle on/off state.
> >
> > I do not know the LED subsystem in detail, but I do not know
> > any possibility to access the i8042 from different subsystem
> > than the input subsystem.
> >
> > What do you think and recommend?
> >
> 
> I think you need to use leds framework for what you are
trying to do.
> I could export i8042_command() so you could access
keyboard controller
> from your driver.

I think exporting the i8042_command() would solve my
problem, so I could call:

retval = i8042_command(NULL, 0x0083);
retval = i8042_command(NULL, 0x0084);
retval = i8042_command(NULL, 0x008A);

as needed.

Which header file should the i8042_command() defined in?

        NMarci





______________________________________________________________________
Könyvszerda a Gabo, Akkord, Talentum, Ciceró Kiadókkal! 
Több mint 700 féle könyv 30% kedvezménnyel! 
http://www.bookline.hu/control/news?newsid=397&affiliate=frekszkar3435

-
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

Powered by Openwall GNU/*/Linux Powered by OpenVZ