linux-kernel - Re: [PATCH 1/1] [INPUT/KEYPAD] gpio keypad: Replace current blackfin specific pfbutton driver with kernel generic gpio key driver

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:	Mon, 12 May 2008 22:42:41 +0800
From:	"Bryan Wu" <cooloney@...nel.org>
To:	"Mike Frysinger" <vapier.adi@...il.com>
Cc:	"pHilipp Zabel" <philipp.zabel@...il.com>,
	dbrownell@...rs.sourceforge.net, dmitry.torokhov@...il.com,
	linux-kernel@...r.kernel.org,
	"Michael Hennerich" <michael.hennerich@...log.com>
Subject: Re: [PATCH 1/1] [INPUT/KEYPAD] gpio keypad: Replace current blackfin specific pfbutton driver with kernel generic gpio key driver

On Mon, May 12, 2008 at 8:47 PM, Mike Frysinger <vapier.adi@...il.com> wrote:
>
> On Mon, May 12, 2008 at 8:11 AM, Bryan Wu <cooloney@...nel.org> wrote:
>  > On Mon, May 12, 2008 at 7:42 PM, Mike Frysinger <vapier.adi@...il.com> wrote:
>  >> On Mon, May 12, 2008 at 7:27 AM, pHilipp Zabel
>  <philipp.zabel@...il.com> wrote:
>  >>  > On Mon, May 12, 2008 at 12:17 PM, Bryan Wu <cooloney@...nel.org> wrote:
>  >>  >> From: Michael Hennerich <michael.hennerich@...log.com>
>  >>  >>
>  >>  >>  It's an actual deficiency in the hardware that we can't address,
>  >>  >>  so it needs to be worked around in software.
>  >>  >>
>  >>  >>  Signed-off-by: Michael Hennerich <michael.hennerich@...log.com>
>  >>  >>  Signed-off-by: Bryan Wu <cooloney@...nel.org>
>  >>  >>  ---
>  >>  >>   drivers/input/keyboard/gpio_keys.c |   15 ++++++++++++++-
>  >>  >>   1 files changed, 14 insertions(+), 1 deletions(-)
>  >>  >>
>  >>  >>  diff --git a/drivers/input/keyboard/gpio_keys.c
>  >>  b/drivers/input/keyboard/gpio_keys.c
>  >>  >>  index bbd00c3..d856eb9 100644
>  >>  >>  --- a/drivers/input/keyboard/gpio_keys.c
>  >>  >>  +++ b/drivers/input/keyboard/gpio_keys.c
>  >>  >>  @@ -26,6 +26,18 @@
>  >>  >>
>  >>  >>   #include <asm/gpio.h>
>  >>  >>
>  >>  >>  +#if defined(CONFIG_BLACKFIN) && !defined(BF548_FAMILY)
>  >>  >>  +
>  >>  >>  +/*
>  >>  >>  + * On some Blackfin CPUs reading edge triggered
>  >>  >>  + * GPIOs doesn't return the current value
>  >>  >>  + */
>  >>  >
>  >>  > If this is a generic problem, shouldn't this be addressed inside
>  gpio_get_value?
>  >>
>  >>  it's an issue only when the GPIO is an interrupt source and the
>  >>  trigger condition is set to both rising and falling.  but i guess your
>  >>  point is that in gpio_get_value(), we can check to see if these
>  >>  conditions are met and if so, temporarily fiddle things there ?
>  >>
>  >>  Michael: that sounds reasonable, what do you think ?
>  >
>
> > IMO, maybe it is feasible for fix this in generic GPIO layer, or will
>  > break other things?
>
>  where are you referring to ?  i think what's being proposed is to move
>  these checks to arch/blackfin/kernel/bfin_gpio.c ... any call to
>  gpio_get_value() under these circumstances will need the edge sense
>  toggle ...
>  -mike
>

Right. I mean the generic GPIO layer in Blackfin port, not the common code.

And on the other hand, maybe there are also other hardware which has similar
issue as Blackfin. So the common GPIO layer can take care of this, how
do you think, David?

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