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] [day] [month] [year] [list]
Date:	Tue, 13 May 2008 08:53:42 +0100
From:	"Hennerich, Michael" <Michael.Hennerich@...log.com>
To:	"Mike Frysinger" <vapier.adi@...il.com>,
	"David Brownell" <david-b@...bell.net>
Cc:	"Bryan Wu" <cooloney@...nel.org>,
	"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



>-----Original Message-----
>From: Mike Frysinger [mailto:vapier.adi@...il.com]
>Sent: Montag, 12. Mai 2008 19:00
>To: David Brownell
>Cc: Bryan Wu; pHilipp Zabel; dbrownell@...rs.sourceforge.net;
>dmitry.torokhov@...il.com; linux-kernel@...r.kernel.org; Michael
Hennerich
>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 12:54 PM, David Brownell wrote:
>> On Monday 12 May 2008, Bryan Wu wrote:
>>  > 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?
>>
>>  No; it's a Blackfin-specific design flaw, one that I've not seen
>>  in any other chip's GPIO support.  So it should stay in the Blackfin
>>  support code.  (Possibly even specialized for the specific chips
>>  which have that flaw/erratum.)
>
>afaik, it was a design flaw, not an erratum ... newer parts have the
>situation rectified.  but Michael would be able to comment more
>authoritatively on the topic.  we already have the logic to only make
>the swap for parts that need it.
>-mike

I agree with all. This hack patch shouldn't be discussed here. I must
have overseen this while we discussed what to send upstream.

Please disregard.

-Michael

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