From mboxrd@z Thu Jan 1 00:00:00 1970 From: thomas.petazzoni@free-electrons.com (Thomas Petazzoni) Date: Thu, 31 Aug 2017 11:39:35 +0200 Subject: linux-next regression caused by "gpiolib: request the gpio before querying its direction" In-Reply-To: <20170831092211.GP20805@n2100.armlinux.org.uk> References: <20170830112424.7a3a7c36@windsurf.lan> <3cce6903-d167-1bfc-38b4-1fdd7b3ff24b@codeaurora.org> <87ziah2m3f.fsf@free-electrons.com> <20170830161730.41919554@windsurf.lan> <20170831091812.6f7d417e@windsurf.lan> <20170831092211.GP20805@n2100.armlinux.org.uk> Message-ID: <20170831113935.38028ff8@windsurf.lan> To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org 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