diff options
author | Stephen Warren <swarren@nvidia.com> | 2012-03-02 13:05:44 -0700 |
---|---|---|
committer | Linus Walleij <linus.walleij@linaro.org> | 2012-03-05 11:19:49 +0100 |
commit | 57b676f9c1b7cd84397fe5a86c9bd2788ac4bd32 (patch) | |
tree | e07d87bba28678aa80d9325a9c48eac0f57a7fe2 /drivers/pinctrl/core.h | |
parent | 962bcbc57aa244eeb1176fa2e9f65ac865cca68a (diff) | |
download | op-kernel-dev-57b676f9c1b7cd84397fe5a86c9bd2788ac4bd32.zip op-kernel-dev-57b676f9c1b7cd84397fe5a86c9bd2788ac4bd32.tar.gz |
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.h | 10 |
1 files changed, 4 insertions, 6 deletions
diff --git a/drivers/pinctrl/core.h b/drivers/pinctrl/core.h index e1dfdb3..8808f25 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; |