linux-kernel - Re: [PATCH 1/2] gpio: add pin biasing and drive mode to gpiolib

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, 20 Apr 2011 16:32:38 +0100
From:	Alan Cox <alan@...rguk.ukuu.org.uk>
To:	Linus Walleij <linus.walleij@...aro.org>
Cc:	Haojian Zhuang <haojian.zhuang@...il.com>,
	Kyungmin Park <kmpark@...radead.org>,
	linux-kernel@...r.kernel.org,
	Grant Likely <grant.likely@...retlab.ca>,
	linux-arm-kernel@...ts.infradead.org,
	Ben Nizette <bn@...sdigital.com>,
	Lee Jones <lee.jones@...aro.org>
Subject: Re: [PATCH 1/2] gpio: add pin biasing and drive mode to gpiolib

> Even if some people are only muxing pins that can also be used as GPIO,
> this is not always the case. We can shunt out the same pins to be used as
> I2C or SPI for example, that means this cannot be handled in a GPIO
> driver since it has nothing to do with GPIO pins at all.

It sounds very much to me like it belongs in the GPIO driver. That is the
one piece of code which knows what it is doing for all this configuration.

Whether all of this is exposed by the GPIO midlayer is another question,
certainly the GPIO midlayer/library doesn't want to be involved in the
finer details of such goings on.

The other approach to muxing I posted seems to handle this fine

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