Thread (15 messages) 15 messages, 8 authors, 2017-08-31

linux-next regression caused by "gpiolib: request the gpio before querying its direction"

From: Thomas Petazzoni <hidden>
Date: 2017-08-31 09:57:54
Also in: linux-gpio

Possibly related (same subject, not in this thread)

Hello,

On Thu, 31 Aug 2017 10:22:12 +0100, Russell King - ARM Linux wrote:
What about hardware which you can configure for some alternate function
but still monitor the pin via GPIO, even though it's not mux'd as GPIO.

For instance, you may have a timer block which can capture on both
edges of an external event signal, which needs the pin to be muxed for
that function.  However, you need to read the state of the pin, and
that is only available through GPIO.  Muxing the pin to be a GPIO just
because someone requests the GPIO is, imho, ill thought-out and breaks
some use cases.

IMHO, the pinmux settings should always be specified in DT, and that's
what we should be using everywhere, not doing broken backdoor games like
"the gpio is being requested, it's obvious that we want this pin to be
a gpio" - that really doesn't follow.
Agreed.

Thomas
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help