summaryrefslogtreecommitdiff
path: root/drivers/pinctrl/core.h
diff options
context:
space:
mode:
authorStephen Warren <swarren@nvidia.com>2012-03-03 00:05:44 +0400
committerLinus Walleij <linus.walleij@linaro.org>2012-03-05 14:19:49 +0400
commit57b676f9c1b7cd84397fe5a86c9bd2788ac4bd32 (patch)
treee07d87bba28678aa80d9325a9c48eac0f57a7fe2 /drivers/pinctrl/core.h
parent962bcbc57aa244eeb1176fa2e9f65ac865cca68a (diff)
downloadlinux-57b676f9c1b7cd84397fe5a86c9bd2788ac4bd32.tar.xz
pinctrl: fix and simplify locking
There are many problems with the current pinctrl locking: struct pinctrl_dev's gpio_ranges_lock isn't effective; pinctrl_match_gpio_range() only holds this lock while searching for a gpio range, but the found range is return and manipulated after releading the lock. This could allow pinctrl_remove_gpio_range() for that range while it is in use, and the caller may very well delete the range after removing it, causing pinctrl code to touch the now-free range object. Solving this requires the introduction of a higher-level lock, at least a lock per pin controller, which both gpio range registration and pinctrl_get()/put() will acquire. There is missing locking on HW programming; pin controllers may pack the configuration for different pins/groups/config options/... into one register, and hence have to read-modify-write the register. This needs to be protected, but currently isn't. Related, a future change will add a "complete" op to the pin controller drivers, the idea being that each state's programming will be programmed into the pinctrl driver followed by the "complete" call, which may e.g. flush a register cache to HW. For this to work, it must not be possible to interleave the pinctrl driver calls for different devices. As above, solving this requires the introduction of a higher-level lock, at least a lock per pin controller, which will be held for the duration of any pinctrl_enable()/disable() call. However, each pinctrl mapping table entry may affect a different pin controller if necessary. Hence, with a per-pin-controller lock, almost any pinctrl API may need to acquire multiple locks, one per controller. To avoid deadlock, these would need to be acquired in the same order in all cases. This is extremely difficult to implement in the case of pinctrl_get(), which doesn't know which pin controllers to lock until it has parsed the entire mapping table, since it contains somewhat arbitrary data. The simplest solution here is to introduce a single lock that covers all pin controllers at once. This will be acquired by all pinctrl APIs. This then makes struct pinctrl's mutex irrelevant, since that single lock will always be held whenever this mutex is currently held. Signed-off-by: Stephen Warren <swarren@nvidia.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Diffstat (limited to 'drivers/pinctrl/core.h')
-rw-r--r--drivers/pinctrl/core.h10
1 files changed, 4 insertions, 6 deletions
diff --git a/drivers/pinctrl/core.h b/drivers/pinctrl/core.h
index e1dfdb3c144f..8808f25a07d4 100644
--- a/drivers/pinctrl/core.h
+++ b/drivers/pinctrl/core.h
@@ -9,6 +9,8 @@
* License terms: GNU General Public License (GPL) version 2
*/
+#include <linux/mutex.h>
+#include <linux/radix-tree.h>
#include <linux/pinctrl/pinconf.h>
struct pinctrl_gpio_range;
@@ -22,7 +24,6 @@ struct pinctrl_gpio_range;
* this radix tree
* @gpio_ranges: a list of GPIO ranges that is handled by this pin controller,
* ranges are added to this list at runtime
- * @gpio_ranges_lock: lock for the GPIO ranges list
* @dev: the device entry for this pin controller
* @owner: module providing the pin controller, used for refcounting
* @driver_data: driver data for drivers registering to the pin controller
@@ -35,7 +36,6 @@ struct pinctrl_dev {
struct pinctrl_desc *desc;
struct radix_tree_root pin_desc_tree;
struct list_head gpio_ranges;
- struct mutex gpio_ranges_lock;
struct device *dev;
struct module *owner;
void *driver_data;
@@ -52,7 +52,6 @@ struct pinctrl_dev {
* @usecount: the number of active users of this pin controller setting, used
* to keep track of nested use cases
* @pctldev: pin control device handling this pin control handle
- * @mutex: a lock for the pin control state holder
* @groups: the group selectors for the pinmux device and
* selector combination handling this pinmux, this is a list that
* will be traversed on all pinmux operations such as
@@ -63,7 +62,6 @@ struct pinctrl {
struct device *dev;
unsigned usecount;
struct pinctrl_dev *pctldev;
- struct mutex mutex;
#ifdef CONFIG_PINMUX
struct list_head groups;
#endif
@@ -75,14 +73,12 @@ struct pinctrl {
* @name: a name for the pin, e.g. the name of the pin/pad/finger on a
* datasheet or such
* @dynamic_name: if the name of this pin was dynamically allocated
- * @lock: a lock to protect the descriptor structure
* @owner: the device holding this pin or NULL of no device has claimed it
*/
struct pin_desc {
struct pinctrl_dev *pctldev;
const char *name;
bool dynamic_name;
- spinlock_t lock;
/* These fields only added when supporting pinmux drivers */
#ifdef CONFIG_PINMUX
const char *owner;
@@ -99,3 +95,5 @@ static inline struct pin_desc *pin_desc_get(struct pinctrl_dev *pctldev,
{
return radix_tree_lookup(&pctldev->pin_desc_tree, pin);
}
+
+extern struct mutex pinctrl_mutex;