linux-kernel - Re: [PATCH V5 0/4] gpio: tegra: Cleanups and support for debounce

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: <5727A535.2060808@nvidia.com>
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?
>