On Thu, Jan 19, 2017 at 1:11 PM, Andy Shevchenko <andriy.shevchenko@xxxxxxxxxxxxxxx> wrote: > On Thu, 2017-01-19 at 12:48 +0300, Mika Westerberg wrote: >> When a GPIO driver is backed by a pinctrl driver the GPIO driver >> sometimes needs to call the pinctrl driver to configure certain >> things, >> like whether the pin is used as input or output. In addition to this >> there are other configurations applicable to GPIOs such as setting >> debounce time of the GPIO. >> >> To support this we introduce a new function pinctrl_gpio_set_config() >> that can be used by gpiolib based driver to pass configuration >> requests >> to the backing pinctrl driver. > > >> + mutex_lock(&pctldev->mutex); >> + pin = gpio_to_pin(range, gpio); >> + ret = pinconf_set_config(pctldev, pin, configs, >> ARRAY_SIZE(configs)); >> + mutex_unlock(&pctldev->mutex); > > Does gpio_to_pin() require to be under lock? All other callers do that because: commit 9b77ace409e1419c331209c4c8eb2c8bc990e9fd Author: Axel Lin <axel.lin@xxxxxxxxxx> Date: Mon Aug 19 10:07:46 2013 +0800 pinctrl: core: Add proper mutex lock in pinctrl_request_gpio This one is missed in commit 42fed7ba "pinctrl: move subsystem mutex to pinctrl_dev struct". I think this fixes the race between pin_free() and pin_request() calls. It protects accessing the members of pctldev->desc. (e.g. update desc->mux_usecount, desc->gpio_owner, desc->mux_owner, etc) Current code grabs pctldev->mutex before calling pinmux_free_gpio(), but did not grab the mutex while calling pinmux_request_gpio(). Signed-off-by: Axel Lin <axel.lin@xxxxxxxxxx> Signed-off-by: Linus Walleij <linus.walleij@xxxxxxxxxx> Yours, Linus Walleij -- To unsubscribe from this list: send the line "unsubscribe linux-gpio" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html