linux-kernel - Re: [PATCH V1 2/3] Documentation: gpio: Add details of open-drain configuration

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Wed, 15 Feb 2012 23:25:41 +0100
From:	Linus Walleij <linus.walleij@...aro.org>
To:	Grant Likely <grant.likely@...retlab.ca>,
	Laxman Dewangan <ldewangan@...dia.com>
Cc:	dunlap@...otime.net, lrg@...com,
	broonie@...nsource.wolfsonmicro.com, linux-doc@...r.kernel.org,
	linux-kernel@...r.kernel.org, linux-tegra@...r.kernel.org,
	Stephen Warren <swarren@...dia.com>
Subject: Re: [PATCH V1 2/3] Documentation: gpio: Add details of open-drain configuration

On Mon, Feb 13, 2012 at 10:18 PM, Grant Likely
<grant.likely@...retlab.ca> wrote:

> Linus mentioned that this should be part of pinctrl instead of the gpio API,
> but I think there is an argument for making it part of the gpio API,
> particularly since open-drain is pretty much a universal concept that all
> gpio controllers can support (unlike driver strength)

Actually pinctrl is engineered to be used as back-end for gpiolib
so thinking about it I'm pretty happy with this arrangement, the gpiolib
driver can very well call down to pinctrl to have the actual setting
done if needed. So it's no big deal.

It is also a case for making some of the pin config business
generic, which I have failed at in the past.

> Have you though about support for lines that are pulled low instead of
> high?  Those aren't as common, but it is conceivable that some
> hardware would need it.

So if the idea is (if I get it correctly) that this thing is an input
sometimes and open drain/collector output sometimes, then
open source/emitter for the inverse situation is an equally valid
case right? In that case I think it'd be best to add both.

The COH901 driver for U300 supports open source/emitter
BTW.

Yours,
Linus Walleij
--
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/