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:	Tue, 3 May 2016 00:36:29 +0530
From:	Laxman Dewangan <ldewangan@...dia.com>
To:	Stephen Warren <swarren@...dotorg.org>,
	Linus Walleij <linus.walleij@...aro.org>
CC:	Alexandre Courbot <gnurou@...il.com>,
	Thierry Reding <thierry.reding@...il.com>,
	"linux-gpio@...r.kernel.org" <linux-gpio@...r.kernel.org>,
	"linux-tegra@...r.kernel.org" <linux-tegra@...r.kernel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH V5 0/4] gpio: tegra: Cleanups and support for debounce


On Tuesday 03 May 2016 12:14 AM, Stephen Warren wrote:
> On 05/02/2016 11:58 AM, Laxman Dewangan wrote:
>>
>>
>> Toggling OE bit is something emulating the open drain here.
>
> From the perspective of the external HW that's attached to the GPIO, I 
> believe there's no difference.
>
>> I think idea is that when we configure the pin in open drain then it
>> should be automatically handled by HW  when we want to set pin state
>> high or low. When we set low, the pin should be driven and when high
>> then it should be tristated input. We should not need any direction bit
>> setting.
>
> I don't imagine anything in the kernel cares, so long as the correct 
> logic level is present on the pin based on whatever GPIO API was last 
> called.
>
> I'd be very surprised if there wasn't hardware that could only 
> implement open-drain by this "emulation" method, so I'd be very 
> surprised if something prohibited that implementation style.
>

The emulation method implemented just to not drive high for open drain.
Recently, proper callback added for hw control for open drain and hence 
emulation method is not needed for such HW.

I think if HW support the callback to implement the open drain then use 
the HW method otherwise fallback to emulation method.


>> Otherwise, if pin is configured as open drain then:
>>
>> Set out = 0
>>
>> and when it need to set pin to high then oe = 0 else oe =1. Do not
>> toggle any other bits.
>>
>> On this case, we need to store that pin is configured as open drain so
>> that set_value should toggle OE instead of OUT.
>
> That sounds like a reasonable implementation.
>

Let me create the patch for review and further discussion.

>> Or do you want to have different implementation?
>

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ