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: Windows password security audit tool. GUI, reports in PDF.

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

Date:	Tue, 9 Jun 2015 19:22:31 +0200
From:	Samuel Thibault <samuel.thibault@...-lyon.org>
To:	Dmitry Torokhov <dmitry.torokhov@...il.com>
Cc:	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

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.

> > > +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?

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