linux-kernel - RE: [PATCH] pinctrl: Add explicit gpio_disable_free pinmux

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:	Wed, 9 Nov 2011 08:28:14 -0800
From:	Stephen Warren <swarren@...dia.com>
To:	Linus Walleij <linus.walleij@...ricsson.com>,
	Linus Walleij <linus.walleij@...aro.org>
CC:	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	Barry Song <21cnbao@...il.com>,
	Shawn Guo <shawn.guo@...escale.com>,
	Sascha Hauer <s.hauer@...gutronix.de>,
	David Brown <davidb@...eaurora.org>,
	Grant Likely <grant.likely@...retlab.ca>,
	Rongjun Ying <Rongjun.Ying@....com>,
	Linaro Dev <linaro-dev@...ts.linaro.org>
Subject: RE: [PATCH] pinctrl: Add explicit gpio_disable_free pinmux_op

Stephen Warren wrote at Friday, October 21, 2011 12:26 PM:
> Some pinctrl drivers (Tegra at least) program a pin to be a GPIO in a
> completely different manner than they select which function to mux out of
> that pin. In order to support a single "free" pinmux_op, the driver would
> need to maintain a per-pin state of requested-for-gpio vs. requested-for-
> function. However, that's a lot of work when the core already has explicit
> separate paths for gpio request/free and function request/free.
>
> So, add a gpio_disable_free op to struct pinmux_ops, and make pin_free()
> call it when appropriate.

LinusW,

Does this patch look good?

> When doing this, I noticed that when calling pin_request():
> 
>     !!gpio == (gpio_range != NULL)
> 
> ... and so I collapsed those two parameters in both pin_request(), and
> when adding writing the new code in pin_free().
> 
> Also, for pin_free():
> 
>     !!free_func == (gpio_range != NULL)
> 
> However, I didn't want pin_free() to know about the GPIO function naming
> special case, so instead, I reworked pin_free() to always return the pin's
> previously requested function, and now pinmux_free_gpio() calls
> kfree(function). This is much more balanced with the allocation having
> been performed in pinmux_request_gpio().
> 
> Signed-off-by: Stephen Warren <swarren@...dia.com>

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