linux-kernel - RE: [PATCH] pinctrl: indicate GPIO direction on single GPIO request

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

Date:	Mon, 14 Nov 2011 09:18:07 -0800
From:	Stephen Warren <swarren@...dia.com>
To:	Linus Walleij <linus.walleij@...ricsson.com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
CC:	Grant Likely <grant.likely@...retlab.ca>,
	Barry Song <21cnbao@...il.com>,
	Shawn Guo <shawn.guo@...escale.com>,
	Thomas Abraham <thomas.abraham@...aro.org>,
	Linus Walleij <linus.walleij@...aro.org>
Subject: RE: [PATCH] pinctrl: indicate GPIO direction on single GPIO request

Linus Walleij wrote at Monday, November 14, 2011 2:11 AM:
> When requesting a single GPIO pin to be muxed in, some controllers
> will need to poke a different value into the control register
> depending on whether the pin will be used for GPIO output or GPIO
> input. So pass this info along for the gpio_request_enable()
> function, we assume this is not needed for the gpio_free_disable()
> function for the time being.

I'm not sure this API change makes sense.

Functions gpio_direction_{input,output} already exist to configure the
direction of a GPIO, and drivers should already be using them. These have
to work to allow drivers to toggle the direction dynamically. Requiring
them to additionally pass this same information to the pinmux driver when
setting up the pinmux seems like extra redundant work.

Instead, shouldn't it work like this:

* If the pinmux driver implementation behind pinmux_request_gpio() needs
to know the direction when configuring the HW, default to input for safety;
that will prevent the SoC driving a signal on a GPIO that's driven by some
other device.

* Rely exclusively on gpio_direction_{input,output} to allow drivers to
configure the direction.

* If the pinmux HW needs programming in response to the gpio_direction_*
calls, have the GPIO and pinmux driver internally communicate to achieve
this.

Does that seem reasonable?

-- 
nvpublic

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