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] [day] [month] [year] [list]

Message-ID: <5728CAD2.9050701@wwwdotorg.org>
Date:	Tue, 3 May 2016 09:59:14 -0600
From:	Stephen Warren <swarren@...dotorg.org>
To:	Laxman Dewangan <ldewangan@...dia.com>,
	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 05/02/2016 01:06 PM, Laxman Dewangan wrote:
>
> 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.

I don't see any benefit to that. It makes the code more complex without 
enabling any more features.

For reference, on Tegra124 and earlier, very few pins have open-drain 
control in HW (pinmux) whereas you can emulate it in the GPIO module for 
any pin. In Tegra210 and Tegra186, many pins have open-drain control in 
HW (pinmux) yet a good number still don't, yet you can still emulate 
this in the GPIO module for any pin.