linux-kernel - Re: [PATCH] Add LED pattern trigger

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]

Date:	Wed, 1 Jan 2014 15:51:32 -0800 (PST)
From:	David Lang <david@...g.hm>
To:	One Thousand Gnomes <gnomes@...rguk.ukuu.org.uk>
cc:	Joe Xue <lgxue@...mail.com>,
	"cooloney@...il.com" <cooloney@...il.com>,
	"rpurdie@...ys.net" <rpurdie@...ys.net>,
	"rob@...dley.net" <rob@...dley.net>,
	"milo.kim@...com" <milo.kim@...com>, "pavel@....cz" <pavel@....cz>,
	"linux-leds@...r.kernel.org" <linux-leds@...r.kernel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"linux-doc@...r.kernel.org" <linux-doc@...r.kernel.org>
Subject: Re: [PATCH] Add LED pattern trigger

On Wed, 1 Jan 2014, One Thousand Gnomes wrote:

>> whatever mechanism is created for toggling LEDs should be able to toggle
>> arbitrary GPIO pins, and there is a problem with the speed of the standard
>> access mechanisms in /sysfs. see this post on hackaday for an example
>>
>> http://hackaday.com/2013/12/07/speeding-up-beaglebone-black-gpio-a-thousand-times/
>
> The usage described is short human speed flashing patterns for things like
> "my brain fell out" from devices, not trying to do 1KHz PWM dimming.
> Dimming might actually be one case you want the kernel interface,
> although it'll kill your power management.

any high speed signalling would probably also need the kernel interface.

>> Also, since there are a number of cases where this is hardware accelerated, it
>> seems like there should be an abstration that userspace can use that doesn't
>> care if or how it's accelerated, setup the output and tell the system to do it
>> without worrying about the specific hardware details. Isn't that a large part of
>> what the kernel is supposed to be doing?
>
> Not usually. The kernel is supposed to be providing a consistent interface
> to hardware, not emulating bits you don't have. Now and then it does (Eg
> FPU emulation) but in general the job it does is "make all the network
> cards look the same" not "make pretend network cards out of string and
> cups". It's not a hard and fast rule in either direction. There are cases
> the kernel doesn't try and create a common interface for the hardware
> because the abstraction that can be done at kernel level would be
> nonsensical.

fair enough, would it make sense to redirect the discussion to focus on what a 
good interface would be for the cases where there is special hardware 
assistance? Then the discussion of if the same interface could/should be used to 
emulate harsdware when it isn't there can be a seprate discussion.

And while this use case the original developer had in mind was the 'I've lost my 
mind' notification to a human, I think it makes sense to consider other uses for 
repeating pattern toggling of GPIO ports.

David Lang
--
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/