linux-kernel - Re: [PATCH 1/3] Input: export LEDs as class devices in sysfs

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20150609173203.GG6338@dtor-ws>
Date:	Tue, 9 Jun 2015 10:32:03 -0700
From:	Dmitry Torokhov <dmitry.torokhov@...il.com>
To:	Samuel Thibault <samuel.thibault@...-lyon.org>,
	Pavel Machek <pavel@....cz>,
	Pali Rohár <pali.rohar@...il.com>,
	linux-input@...r.kernel.org, linux-kernel@...r.kernel.org,
	rpurdie@...ys.net, Greg Kroah-Hartman <gregkh@...uxfoundation.org>
Subject: Re: [PATCH 1/3] Input: export LEDs as class devices in sysfs

On Tue, Jun 09, 2015 at 07:22:31PM +0200, Samuel Thibault wrote:
> Dmitry Torokhov, le Tue 09 Jun 2015 09:49:35 -0700, a écrit :
> > > > +	[LED_NUML]	= { "num-lock", VT_TRIGGER("kbd-numlock") },
> > > > +	[LED_CAPSL]	= { "caps-lock", VT_TRIGGER("kbd-capslock") },
> > > > +	[LED_SCROLLL]	= { "scroll-lock", VT_TRIGGER("kbd-scrollock") },
> > > 
> > > I'd tend to think we'd want to harmonize the user-visible LED names and
> > > kbd trigger names, i.e. use "numlock", "capslock" and "scrollock" in
> > > both case (or something else, but the same for LED and trigger). In my
> > > patch I simply used the corresponding LED or kbd macro names, but there
> > > is probably no strong reason to this, while there is probably a good
> > > reason to choose coherent and nice user-visible names.
> > 
> > I can do either "num_lock - kbd-num-lock" or "numlock - kbd-numlock"
> > with slight preference to the 1st. What is your preference?
> 
> I'd prefer numlock - kbd-numlock.

OK.

> 
> > > > +static enum led_brightness input_leds_brightness_get(struct led_classdev *cdev)
> > > > +{
> > > > +	struct input_led *led = container_of(cdev, struct input_led, cdev);
> > > > +	struct input_dev *input = led->handle->dev;
> > > > +
> > > > +	return test_bit(led->code, input->ledbit) ? LED_FULL : LED_OFF;
> > > 
> > > This always returns LED_FULL, whatever the current state of the LED, is
> > > that really what we want?  Userspace will be surprised to read 255 from
> > > sysfs whatever it writes to it (with actual proper effect on the LED).
> > 
> > Right, I will change it to 0 and led->max_brightness (which I will set
> > to 1).
> 
> Well, that won't fix the issue I'm having, see below.
> 
> > > Simply not defining input_leds_brightness_get and letting the LED core
> > > manage the value does get a proper "brightness" sysfs file behavior, is
> > > there a reason not to do that?
> > 
> > Yes, we want LED sysfs show correct result if state is altered via
> > EV_LED/LED_* event. Basically the led bit state is the source of truth
> > here.
> 
> Ok, I understand that. But it happens that your code does not work! It
> is always 255 (or will be 1 with the modifications you mention above).
> input->ledbit is whether the LED exists or not, not its state, right?
> Did your perhaps mean input->led in input_leds_brightness_get instead of
> input->ledbit?

Yep. I'll change it.

-- 
Dmitry
--
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/