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]
Message-Id: <1238491138.5936.86.camel@jani-desktop>
Date:	Tue, 31 Mar 2009 12:18:58 +0300
From:	Jani Nikula <ext-jani.1.nikula@...ia.com>
To:	ext Ben Nizette <bn@...sdigital.com>
Cc:	"david-b@...bell.net" <david-b@...bell.net>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"juha.yrjola@...idboot.com" <juha.yrjola@...idboot.com>
Subject: Re: [RFC PATCH 0/3] GPIO switch framework

Hi Ben, and thanks for your feedback.

On Sun, 2009-03-22 at 07:25 +0100, ext Ben Nizette wrote:
> On Fri, 2009-03-20 at 15:50 +0200, Jani Nikula wrote:
> > Hi -
> > 
> > This RFC patchset is a pretty straightforward adaptation of OMAP GPIO
> > switch framework for mainline integration.
> > 
> > The GPIO switch framework allows reporting and changing GPIO switches
> > via sysfs, with debouncing and sysfs/in-kernel notifications for input
> > switches.
> 
> OK, so what does this do that /sys/class/gpio/gpioN doesn't currently do
> apart from debouncing?  And the output being a string rather than a
> simple value (which IMO might be better suited to userspace
> interpretation anyway).

In addition to debouncing, there's sysfs and in-kernel notifications.

To hide potential changes in hardware from userspace, there's naming of
the sysfs entries (e.g. /sys/class/gpio/switch-foo) and a flag for
inverting the value.

> I've got a patch, little abandoned at the bottom of my queue, which adds
> poll(2) compatibility to the gpiolib sysfs entries [1] and extending
> this patch to do debouncing as well would be almost trivial.

Your patch certainly looks promising, and indeed overlaps with my work.
Debouncing could be easily added, and perhaps symbolic links to provide
names for the switches.

However, if I didn't miss anything, your patch allows setting up the
notification through sysfs only, and there's no way of doing it from
kernel side. Also, I'd need debounced callback notifications.

> I guess what I'm getting at is that this seems like it solves a problem
> which has been pretty much solved elsewhere since the OMAP boys wrote
> this.

It's been only partially solved by your patch, and as you say yourself,
it's still at the bottom of your queue. There's also the gpio-keys
(pointed out by Philipp Zabel elsewhere in this thread), but that's
input only and lacks in-kernel notifications. AFAIK the input layer is
also pretty fixed in what can be reported. So I am not convinced this
has been solved elsewhere.

Do you have any plans to resume work on your patch?


BR,
Jani.


> 	--Ben.
>  
> [1] http://marc.info/?l=linux-kernel&m=122454305213792&w=2


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