From: Mark Brown <broonie@opensource.wolfsonmicro.com>
To: Onkalo Samu <samu.p.onkalo@nokia.com>
Cc: ext Dmitry Torokhov <dmitry.torokhov@gmail.com>,
"linux-input@vger.kernel.org" <linux-input@vger.kernel.org>
Subject: Re: [PATCH 1/1] TWL4030 keypad: keypad lock / unlock
Date: Mon, 23 Nov 2009 13:54:36 +0000 [thread overview]
Message-ID: <20091123135435.GG24326@rakim.wolfsonmicro.main> (raw)
In-Reply-To: <1258977955.5272.37.camel@4fid08082>
On Mon, Nov 23, 2009 at 02:05:55PM +0200, Onkalo Samu wrote:
> twl4030 keypad is more or less connected to omap based systems and this
> kind of disabling and enabling feature is clearly targetted to embedded
There's rather a lot of embedded systems and off the shelf application
stacks for them so having an interface that isn't driver-specific is
also useful for them.
> systems. One more generic way could be to add ioctl to evdev driver
> which calls chip-specific driver for disabling / enabling the keypad.
> It is then up to chip specific driver to setup necessary callback
> functions which makes actual job. Does this sound bad?
Something along these lines which makes the user space interface part of
the common code, enabled if driver provides functions to implement the
behaviour does seem like a good approach.
sysfs might be easier to use than an ioctl(), though.
next prev parent reply other threads:[~2009-11-23 13:54 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-11-10 8:24 [PATCH 0/1] TWL4030 keypad: lock / unlock feature Samu Onkalo
2009-11-10 8:24 ` [PATCH 1/1] TWL4030 keypad: keypad lock / unlock Samu Onkalo
2009-11-10 13:43 ` Mark Brown
2009-11-10 17:26 ` Dmitry Torokhov
2009-11-11 9:57 ` Onkalo Samu
2009-11-11 10:08 ` Mark Brown
2009-11-23 12:05 ` Onkalo Samu
2009-11-23 13:54 ` Mark Brown [this message]
2009-11-25 14:22 ` Onkalo Samu
2009-11-25 14:46 ` Mark Brown
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20091123135435.GG24326@rakim.wolfsonmicro.main \
--to=broonie@opensource.wolfsonmicro.com \
--cc=dmitry.torokhov@gmail.com \
--cc=linux-input@vger.kernel.org \
--cc=samu.p.onkalo@nokia.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.